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

[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

[fasterthanlime@hachyderm.io]

@arichtman @yosh This is going to be a very, very, very, very long thread.

[fasterthanlime@hachyderm.io]

@chosunone So you want mutability of fields to be controlled at declaration site and not binding site. What's the... Can you give me a for instance?

[lutzky@ohai.social]

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

[chosunone@pleroma.chosunone.io]

@fasterthanlime lots of syntax sugar for pinned things