I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc.

[cyberia@tilde.zone]

@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.

[piegames@flausch.social]

@fasterthanlime make non-zero cost abstractions with good-enough performance tradeoffs for most use cases a first class citizen

[dmerej@mamot.fr]

@piegames @fasterthanlime replace 'fn' keyword by 'fun' - Kotlin got it right !

[latenightowl@social.linux.pizza]

@fasterthanlime Have one way to convert between types. Differences between as, into, from, to_, ...

[musicmatze@social.linux.pizza]

@fasterthanlime standard library associated types are named in an uniform way: `Error`. No `Err` anymore anywhere!

[latenightowl@social.linux.pizza]

@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".

[lizzy@social.vlhl.dev]

@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.

[poliorcetics@social.treehouse.systems]

@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 ?

[lizzy@social.vlhl.dev]

@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.

[willhbr@ruby.social]

@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

[khyperia@mas.to]

@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!)

[chebra@mstdn.io]

@fasterthanlime Redeclaring a variable of the same name should be an error.

[fasterthanlime@hachyderm.io]

@khyperia no that's valid

[fasterthanlime@hachyderm.io]

@lizzy what properties would the remake have?

[d2718@hachyderm.io]

@fasterthanlime

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."

[yosh@toot.yosh.is]

@poliorcetics @cyberia @fasterthanlime

Tuples are anonymous structs. To my knowledge anonymous enums have not been accepted; I agree they would be nice.

[yosh@toot.yosh.is]

@fasterthanlime

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.

[chosunone@pleroma.chosunone.io]

@fasterthanlime Proper generator syntax

[chosunone@pleroma.chosunone.io]

@fasterthanlime Marking fields as mutable on a struct, immutable by default

[tribaal@hachyderm.io]

@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