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 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.
-
@fasterthanlime Marking fields as mutable on a struct, immutable by default
@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?
-
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 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.
-
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 lots of syntax sugar for pinned things -
@poliorcetics @cyberia @fasterthanlime
Tuples are anonymous structs. To my knowledge anonymous enums have not been accepted; I agree they would be nice.
@yosh @cyberia @fasterthanlime tuple are a sad replacement for what C allows for example.
Found the rust rfc, 2102
-
@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?
@fasterthanlime When I borrow `self` mutably, it ends up locking down the entire self from immutable borrows, but really I just want certain fields to be locked down. Some fields will never be mutably borrowed and so I should allow immutable borrows to self that only access those fields. Basically in the direction of field projection. -
@fasterthanlime Redeclaring a variable of the same name should be an error.
@chebra @fasterthanlime in case you're not already aware (and haven't found this to be insufficient), Clippy has the shadow_* family of lints that address this.
-
@lizzy what properties would the remake have?
@fasterthanlime it should allow distros to package crates separately (even if they are ultimately statically linked together), shouldn't force download at build time (many distros network-sandbox their build environment). the only way to do this currently is downloading the crates ahead of time, running a checksum and then adding a fake repository locally to overwrite crates.io. it should also be able to allow specifying external C dependencies properly because crates vendoring C code is hell for packagers. it should be less reliant on lockfiles and the ecosystem should ideally have less 0.x packages and less very small trivial creates like is_docker that bloat the dependency graph.
cargo obviously is quite convenient for upstream devs because it becomes very easy to add dependencies and so on, and for the most part, cargo could still function similarly for developers but also be more aware of distribution models that aren't "just vendor everything by downloading it from a centralized repository at build time". meson using subprojects and wrapfiles shows how a good compromise could work.
as is a lot of packagers and distro people have zero enthusiasm for rust because it essentially makes their life hell (hence also creating opposition to something like the python cryptography rewrite in rust), and I think that is quite sad because Rust as a language has a lot useful features for developers. -
@fasterthanlime it should allow distros to package crates separately (even if they are ultimately statically linked together), shouldn't force download at build time (many distros network-sandbox their build environment). the only way to do this currently is downloading the crates ahead of time, running a checksum and then adding a fake repository locally to overwrite crates.io. it should also be able to allow specifying external C dependencies properly because crates vendoring C code is hell for packagers. it should be less reliant on lockfiles and the ecosystem should ideally have less 0.x packages and less very small trivial creates like is_docker that bloat the dependency graph.
cargo obviously is quite convenient for upstream devs because it becomes very easy to add dependencies and so on, and for the most part, cargo could still function similarly for developers but also be more aware of distribution models that aren't "just vendor everything by downloading it from a centralized repository at build time". meson using subprojects and wrapfiles shows how a good compromise could work.
as is a lot of packagers and distro people have zero enthusiasm for rust because it essentially makes their life hell (hence also creating opposition to something like the python cryptography rewrite in rust), and I think that is quite sad because Rust as a language has a lot useful features for developers.@lizzy Okay, I see where you're coming from. Unfortunately, it covers a lot more ground than just cargo, but yeah.
-
@fasterthanlime it should allow distros to package crates separately (even if they are ultimately statically linked together), shouldn't force download at build time (many distros network-sandbox their build environment). the only way to do this currently is downloading the crates ahead of time, running a checksum and then adding a fake repository locally to overwrite crates.io. it should also be able to allow specifying external C dependencies properly because crates vendoring C code is hell for packagers. it should be less reliant on lockfiles and the ecosystem should ideally have less 0.x packages and less very small trivial creates like is_docker that bloat the dependency graph.
cargo obviously is quite convenient for upstream devs because it becomes very easy to add dependencies and so on, and for the most part, cargo could still function similarly for developers but also be more aware of distribution models that aren't "just vendor everything by downloading it from a centralized repository at build time". meson using subprojects and wrapfiles shows how a good compromise could work.
as is a lot of packagers and distro people have zero enthusiasm for rust because it essentially makes their life hell (hence also creating opposition to something like the python cryptography rewrite in rust), and I think that is quite sad because Rust as a language has a lot useful features for developers.@fasterthanlime by the way, ironically, distros are also facing issues with security caused by rust, because if there is a vulnerability found in one crate, they can't simply bump that crate (and potentially trigger a rebuild for all its dependencies), but instead they either have to wait for upstream devs to update their lockfiles or individually patch every single lockfile in every single project and make sure that it still works 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 I'm not sure what the right solution is, but self references that "move" with the struct. So if you move a struct, any self references get updated. Maybe a non-trivial runtime penalty, but just make it possible. I don't like reinventing pointers for referencing items in a collection I own.
