I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc.
-
@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. -
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 orphan rule.
-
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 Just stuff I remember now, there was more:
1. `Arc<>::clone()` gives me goosebumps
-
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 Just stuff I remember now, there was more:
2. lack of declaration distinction between dyn safe and dyn non-safe traits, so compiler cannot restrict us before use
-
@fasterthanlime I think I'd allow anonymous structs/enums. Often I find myself reaching to create an enum field inside a struct and it's annoying having to make a whole separate named declaration for it.
@cyberia @fasterthanlime My toy language has tuples, which are like in rust, and variants, which are anonymous enums where the constructors are numbered rather than named.
I also defined my enums as just enums, not enums of structs.
-
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 Hottest take here. I would get rid of multi argument functions. We already have tuples. Every function should take one argument and return one value.
-
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 Replace Pin<T> by &pin T.
-
@fasterthanlime I think I’d just make tokio part of the standard and avoid the async function colouring problem. Then spend time on the compiler to be smart about the actually necessary async inclusion vs compiling to sync
@tribaal @fasterthanlime I think other languages promised that, and they could not deliver on these promises.
-
@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!!)
@simonomi @fasterthanlime I don't feel they add much benefit on top of named arguments ... is there a good argument to not spend that language complexity elsewhere?
-
@fasterthanlime the orphan rule.
@vbfox what's the alternative?
-
@simonomi @fasterthanlime I don't feel they add much benefit on top of named arguments ... is there a good argument to not spend that language complexity elsewhere?
@soc @fasterthanlime by "named arguments" do you mean something akin to python-style kwargs? or maybe LSP inlay of argument names at callsites?
a lot of the value of argument labels comes from them being manditory and chosen by the callee. i really value Swift's API design tenet of "clarity at the point of use", and even the simple aesthetic change of going from `sayHi(person)` to `sayHi(to: person)` can make a big difference IMO
-
@soc @fasterthanlime by "named arguments" do you mean something akin to python-style kwargs? or maybe LSP inlay of argument names at callsites?
a lot of the value of argument labels comes from them being manditory and chosen by the callee. i really value Swift's API design tenet of "clarity at the point of use", and even the simple aesthetic change of going from `sayHi(person)` to `sayHi(to: person)` can make a big difference IMO
@soc @fasterthanlime aside from clarity, being able to 'overload' on argument labels is really really nice, and Rust deals with a lot of same-method-but-with-try/mut-instead already
