I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc.
-
Hah, I'm not Amos and I don't have a kuma, but here's my take on Iterator semantics from my blog:
And my take on Iterator trait naming:
IMO the big painful one is that iterators in Rust only have a type `Item` for the item they yield. They don't have a type `Output` for the type they return, which is hard-coded to always be unit.
-
@fasterthanlime support a "slow but correct" mode. Rust's tradeoff is "fight the compiler hard, but resulting code is fast and correct". I'd like an option for "less compiler fighting, slower is OK, less correct is not OK". Something like "implicitly wrap all my shit with garbage collection". I'd like Go-level performance with rust-level correctness.
@lutzky @fasterthanlime I would very much like a garbage-collected language that shares the Rust standard library and has first-class interop with Rust libraries.
I have no idea if it’s possible though.
-
I think I may have accidentally come up with a drinking game
If someone mentions function coloring, you have to finish your glass
Unfortunately the ecosystem is split between colored functions and coloured functions
-
I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc. what would you fix?
(*one per reply, multiple replies per household are allowed)
@fasterthanlime How has nobody else mentioned the orphan rule yet?
-
@arichtman @yosh told ya
-
@arichtman @pndc yeah exactly the fix is unsoundness so..
-
I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc. what would you fix?
(*one per reply, multiple replies per household are allowed)
@fasterthanlime
let mut → var -
@arichtman @fasterthanlime It's not quite the same thing because the languages approach traits and the problems solved by traits differently, but Scala handles this by (massive handwave over the details) giving the implementations a name, which has to be imported by the code which uses it. That way there doesn't need to be One True Implementation which limits where it can be defined. The flip side is that it needs to be imported by all library users and isn't automatically available, but since Scala code tends to wildcard-import from libraries, this is not particularly onerous.
-
I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc. what would you fix?
(*one per reply, multiple replies per household are allowed)
@fasterthanlime I have a dang *list*, but let's start with the pettiest one:
The value of { a(); b(); } should be whatever b returns, not ().
If you want to throw away the value returned by b you should have to write { a(); b(); (); }.
Leaving off the semicolon on the last expression in a block should be a *syntax error*, except when you wouldn't have to put a semicolon after that expression if it wasn't the last expression in the block.
-
I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc. what would you fix?
(*one per reply, multiple replies per household are allowed)
@fasterthanlime Algebraic effects?
-
@poliorcetics @cyberia @fasterthanlime
Tuples are anonymous structs. To my knowledge anonymous enums have not been accepted; I agree they would be nice.
@yosh @poliorcetics @cyberia @fasterthanlime sometimes an anonymous struct with named fields would be nice, like for a one-off return type. but i usually eat the verbosity and make it a named struct, so it’s not where i’d spend language complexity budget first
-
I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc. what would you fix?
(*one per reply, multiple replies per household are allowed)
@fasterthanlime I'd like some syntax sugar like in Scala: o.map(_.toString())
-
@fasterthanlime I'd like some syntax sugar like in Scala: o.map(_.toString())
@yanns they use `_` for that? huh! been a while since my EPFL days
-
I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc. what would you fix?
(*one per reply, multiple replies per household are allowed)
@fasterthanlime As someone who learnt #Rust but didn’t stick with it, get rid of * / & syntax and use in / out / inout keywords on the parameter instead. It’s a noob thing but #C’s pointer syntax has always struck me as needlessly confusing and requiring too much micro-management through a code base. Rust was too much up-front architecting and not enough proving an idea works and cleaning up afterwards for me
-
@arichtman @fasterthanlime It's not quite the same thing because the languages approach traits and the problems solved by traits differently, but Scala handles this by (massive handwave over the details) giving the implementations a name, which has to be imported by the code which uses it. That way there doesn't need to be One True Implementation which limits where it can be defined. The flip side is that it needs to be imported by all library users and isn't automatically available, but since Scala code tends to wildcard-import from libraries, this is not particularly onerous.
@arichtman @fasterthanlime In my own hypothetical Rust replacement which I don't expect to write any time soon, I would definitely be stealing quite hard from Scala. Other things: square brackets for trait parameters so we don't get weird parses from angle brackets and generally improving ergonomics, it basically having stable
fn_traitsso a collection or other container type can just be called directly to perform a lookup without the noise of.getor whatever, implicit parameters so some common parameter (e.g. a database handle) can bubble through the call stack without explicitly adding it to every function call, and perhaps its dependent functions/methods. But those are another three things… -
@yosh @poliorcetics @cyberia @fasterthanlime sometimes an anonymous struct with named fields would be nice, like for a one-off return type. but i usually eat the verbosity and make it a named struct, so it’s not where i’d spend language complexity budget first
@simon @yosh @poliorcetics @fasterthanlime yeah, often I find that if I'm returning multiple values from a function, either the thing returned is a useful grouping elsewhere in the program and therefore deserves a name, or the function is overburdened and can be split up
-
@simon @yosh @poliorcetics @fasterthanlime yeah, often I find that if I'm returning multiple values from a function, either the thing returned is a useful grouping elsewhere in the program and therefore deserves a name, or the function is overburdened and can be split up
@cyberia @simon @yosh @poliorcetics something something stockholm syndrome (with all due respect)
-
@cyberia @simon @yosh @poliorcetics something something stockholm syndrome (with all due respect)
@fasterthanlime @simon @yosh @poliorcetics ha, I think it's a pretty useful prompt that the code is getting messy and could be refactored, but sure
-
@fasterthanlime I have a dang *list*, but let's start with the pettiest one:
The value of { a(); b(); } should be whatever b returns, not ().
If you want to throw away the value returned by b you should have to write { a(); b(); (); }.
Leaving off the semicolon on the last expression in a block should be a *syntax error*, except when you wouldn't have to put a semicolon after that expression if it wasn't the last expression in the block.
@zwol @fasterthanlime That one is also on my list!
Do you have your list somewhere?
My list (syntax-only) is https://soc.me/languages/design-mistakes-in-rust. -
@fasterthanlime @simon @yosh @poliorcetics ha, I think it's a pretty useful prompt that the code is getting messy and could be refactored, but sure
@cyberia @simon @yosh @poliorcetics Right, I don't mean that as like an insult saying you're incapable of imagining things outside of the tools you're currently allowed to use. I'm just saying that I've caught myself coming up with excuses for the limitations of the language I use because I know those limitations are not going to be lifted... and therefore, it's easier to imagine that they make sense than to imagine that I'm suffering for no good reason is the long version of what I was trying to say.
