I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc.
-
@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.
-
@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.
@fasterthanlime @cyberia @simon @poliorcetics
Hear hear! We all deserve good things! Things can be better!
-
@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.
@fasterthanlime @simon @yosh @poliorcetics Sure - but this is a pattern I use in TypeScript as well which allows anonymous structs as function returns. In this case the restriction in Rust made me a better TS engineer, so it goes both ways. I would definitely agree with you in other contexts (like passing structs as parameters in C being messy meaning that people think it's an undesirable thing in general)
-
I think I may have accidentally come up with a drinking game
If someone mentions function coloring, you have to finish your glass
@fasterthanlime
Do I have to finish sync or async? -
@fasterthanlime When I borrow `self` mutably, it ends up locking down the entire self from immutable borrows, but really I just want certain fields to be locked down. Some fields will never be mutably borrowed and so I should allow immutable borrows to self that only access those fields. Basically in the direction of field projection.
@chosunone @fasterthanlime I think this just comes down to making the borrow checker (static analysis) more intelligent so that you can have more granular *borrows*, right?
Actually marking the fields as mutable or immutable doesn’t make much sense to me either, so I guess you’re suggesting either new syntax when borrowing or else a smarter borrow checker?
(It’s a tension point to be sure but I don’t hit it very often)
-
Unfortunately the ecosystem is split between colored functions and coloured functions
@fasterthanlime I frequently write both and TBH this isn’t even in my top 10 complaints
-
@yanns they use `_` for that? huh! been a while since my EPFL days
@fasterthanlime they used '_' for a lot of things, too much actually, bringing confusion. In Scala 3, they tried to reduce this, for example by using '*' for imports.
-
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 The `Index` trait would be able to returned owned smart pointers.
-
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 well my number one was fixed literally in my birthday in 1.88 with if let chaining. And that was a complaint from the first day I started writing Rust about 8 years ago
These days my biggest complaints are probably
1. The relatively clunky syntax for nested lookups in deeply optional trees like JSON structures.
2. The lack of a Swift style defer block. This can be emulated with scope/drop guards but a proper keyword would be so much nicer. -
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 List<T>, Collection<T>, Map<K, V> (https://github.com/bbqsrc/collections) -- and also that concrete methods override trait methods, not the other way around (related to the above, was a shitshow implementing this.)
-
@fasterthanlime The syntax for traits: in my head, "I am writing a struct implementing this trait", not "this trait is also implemented by my struct".
@latenightowl @fasterthanlime Agreed.
Though even if one stayed with the existing approach
> trait SomeTrait for Type
would be better than the
> impl SomeTrait for Type
Rust today uses.
-
Unfortunately the ecosystem is split between colored functions and coloured functions
This would honestly make a decent Twitch stream
-
@arichtman @pndc yeah exactly the fix is unsoundness so..
@fasterthanlime @arichtman @pndc invent a concept of restricted or external traits and go insane at the consequences
-
@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.
@samir @lutzky @fasterthanlime I have done experimental crimes in the past on this, and to a large extent this is possible.
The problem is of course the infinite number of edge cases and the fact that, in practice, you'd need to use the C ABI to have nice things. And the C ABI is the antithesis of nice things.
-
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)
The ability to be generic over const/mut references - I very often find myself writing get and get_mut methods for the same things. You can hack together a version of this with GATs but it really deserves dedicated syntax, or better yet a single system to abstract over mut-ness, async-ness and const-ness.
-
@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.@soc @fasterthanlime I've never written the whole thing down, no.
Looking at your list, I would also have proposed [] instead of <> for generics, and smushing :: into . by whatever means necessary. I'm indifferent to = instead of : for key/value pair literals. Many of the other things feel uncomfortable as a knee jerk reaction but maybe I could get used to them. I think you're wrong about what macros get used for.
-
@soc @fasterthanlime I've never written the whole thing down, no.
Looking at your list, I would also have proposed [] instead of <> for generics, and smushing :: into . by whatever means necessary. I'm indifferent to = instead of : for key/value pair literals. Many of the other things feel uncomfortable as a knee jerk reaction but maybe I could get used to them. I think you're wrong about what macros get used for.
Here's a few more things on my list but not yours:
The dereference operator (unary *) should be postfix. C got this wrong in 1970 and we've been paying for it ever since.
&& and || should have equal precedence and be non-associative wrt each other — this mandates what everyone actually does in practice, writing explicit parens whenever they are mixed.
#[path = "boo.rs"] mod foo; should be spelt mod foo = "boo.rs"; and it should be required for all out-of-line modules.
