I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc.
-
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 make non-zero cost abstractions with good-enough performance tradeoffs for most use cases a first class citizen
-
@fasterthanlime make non-zero cost abstractions with good-enough performance tradeoffs for most use cases a first class citizen
@piegames @fasterthanlime replace 'fn' keyword by 'fun' - Kotlin got it right !
-
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 Have one way to convert between types. Differences between as, into, from, to_, ...
-
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 standard library associated types are named in an uniform way: `Error`. No `Err` anymore anywhere!
-
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 syntax for traits: in my head, "I am writing a struct implementing this trait", not "this trait is also implemented by my struct".
-
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 redo cargo from scratch, it doesn't work for anyone except upstream developers and it is the reason for 95% of the hate that rust gets. -
@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 IIRC this has been an accepted rfc for a long time and nobody has implemented it. Or maybe it was just about unions ?
-
@fasterthanlime redo cargo from scratch, it doesn't work for anyone except upstream developers and it is the reason for 95% of the hate that rust gets.@fasterthanlime another problem is architecture support, which is mostly related to LLVM and not having multiple implementations, so I would fix that there is no proper spec and no alternative compiler.
-
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 separate ownership semantics syntax from memory layout.
Box<> feels dirty because so much typing, but so much of the time you don't need stuff directly embedded
-
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 a higher priority on editor experience when considering language designs
(sorry that’s not exactly what you asked, haha - my point being that a programming language is not its spec, it’s also everything that surrounds it, and the spec should be guided by that. IMO, early on, rust focused too much on compiler-in-a-terminal experience and not enough on compiler-in-a-editor. getting better though!)
-
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 Redeclaring a variable of the same name should be an error.
-
@fasterthanlime a higher priority on editor experience when considering language designs
(sorry that’s not exactly what you asked, haha - my point being that a programming language is not its spec, it’s also everything that surrounds it, and the spec should be guided by that. IMO, early on, rust focused too much on compiler-in-a-terminal experience and not enough on compiler-in-a-editor. getting better though!)
@khyperia no that's valid
-
@fasterthanlime redo cargo from scratch, it doesn't work for anyone except upstream developers and it is the reason for 95% of the hate that rust gets.
@lizzy what properties would the remake have?
-
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)
Relax the restrictions for making traits object-safe (or dyn compatible or whatever). I'm sure there are underlying technical limitations in play, but it'd be nice to have the (easy) option of saying, "Hey, I'm willing to accept some overhead in exchange for some convenience here."
-
@cyberia @fasterthanlime IIRC this has been an accepted rfc for a long time and nobody has implemented it. Or maybe it was just about unions ?
@poliorcetics @cyberia @fasterthanlime
Tuples are anonymous structs. To my knowledge anonymous enums have not been accepted; I agree they would be nice.
-
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 things I would fix about Rust are the things I am working on hah.
If I could wave a wand tho I'd probably use it to fix the Iterator and Future traits. Not because they are impossible to fix now, but doing that now will be incredibly tedious work.
-
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 Proper generator syntax -
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 Marking fields as mutable on a struct, immutable by default -
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 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
-
@arichtman @yosh This is going to be a very, very, very, very long thread.
