I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc.
-
@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.
-
@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.
@fasterthanlime bonus points if it's reversible. That is, I'd like to stick #[!author_is_lazy_just_gc_everything] on the top, and:
1. Write new code like the lazy bastard I am
2. Be able to go "oh shit, ot does need to be fast" later, remove it, receive the justice of compiler errors
3. Decide "this fast code needs maintenance but I am lazy" - stick the #[!thing] on top on preexisting, correct rust code, and only then add stuff. -
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.
@zwol @fasterthanlime Oh, I agree on that!
I have put that in a non-Rust-specific article here:
https://soc.me/languages/unary-operators-are-unnecessary -
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 fix whatever language/compiler defects cause async streams to be SO BAD to create.
-
@zwol @fasterthanlime Oh, I agree on that!
I have put that in a non-Rust-specific article here:
https://soc.me/languages/unary-operators-are-unnecessary@soc @fasterthanlime I cannot agree with dropping prefix unary negation operators. Too much of a divergence from math notation.
And I think dereference does need an operator, not a method, I just think it belongs on the right. I'm not sure about enreference (unary &); it feels natural to put it on the left but maybe that's 40 years of C talking.
Rust has a thing where sometimes you have to write &*(expr) or *&(expr) and all of *those* cases should be intrinsic methods, yeah.
-
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 Linear types (I believe that term is correct; the term is sometimes used for Rust's existing model, but that's more properly "affine").
So you could define a type that instead of having a destructor, is required to be passed to a function consuming it instead of allowing it to fall out of scope.
-
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.
@zwol @fasterthanlime I'm fine with the idea of requiring explicit parentheses, though I prefer a more conservative approach of
- fixing broken precedences inherited from C, and
- having fewer binary operators in general, and
- subsequently having fewer precedence levelsApplying all that, one ends up with ~5 precedence levels and <10 operators (not including comparison operators):
Language Design: Binary Operators are Overused
TL;DR: Use methods.
(soc.me)
That kinda solves all my concerns I have with binary operators.
-
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 Probably throw out the whole rather useless `PartialOrd`/`Ord` and `PartialEq`/`Eq` hierarchies, then pick better names, then implement all replacement traits for floats.
-
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 Swift-style argument labels! IMO the most underrated feature that literally every programming language would be better off with (clearer APIs with no downside!!)
-
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 would add a compiler-supported `declaration_of!(some-struct-or-trait-name)` macro that is replaced with the trait declaration (aka the trait def without code blocks) or the struct declaration (struct field definitions and a list of all implemented traits).
that way it would be possible to auto-generate struct proxies, e.g. when composing multiple types or for newtypes.
