I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc.
-
@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. -
@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.
@aru Thanks, didn't know, that sounds like it could be enough for me.
-
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)
I think I may have accidentally come up with a drinking game
If someone mentions function coloring, you have to finish your glass
-
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 Better handling of
&so I don’t ever have to call.as_ref(), and similar syntax forimpl AsRef<Thing>so I don’t have to care about whether it’s anRcor anArcor whatever. -
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
Futureshould be a wrapper aroundPin<Box<dyn FutureImpl>>. It would cost almost nothing and make a lot of async stuff way easier.(Bonus points if
Pingoes away entirely. The wrapper also wins because if we do get a better way to handle pinning, it could be removed in an edition upgrade.) -
@fasterthanlime Redeclaring a variable of the same name should be an error.
@chebra @fasterthanlime this is actually really useful for doing things like temporary mutability, where after you are done changing something you "lock" it by redeclaring it but without the mutability modifier. -
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 want coloured function, user coloured and compiler enforced.
For example would be nice to mark functions as "blocking" (for whatever definition of blocking) and avoid them to be used by async unless enforced.
In embedded, in an interrupt, no other code can run or only other interrupt with higher priority if reentrant interrupt are supported and enabled.
this allow to call some simplified locking functions, but also you cant call locking that may hang... -
Hah, I'm not Amos and I don't have a kuma, but here's my take on Iterator semantics from my blog:
And my take on Iterator trait naming:
IMO the big painful one is that iterators in Rust only have a type `Item` for the item they yield. They don't have a type `Output` for the type they return, which is hard-coded to always be unit.
-
@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.
@lutzky @fasterthanlime I would very much like a garbage-collected language that shares the Rust standard library and has first-class interop with Rust libraries.
I have no idea if it’s possible though.
-
I think I may have accidentally come up with a drinking game
If someone mentions function coloring, you have to finish your glass
Unfortunately the ecosystem is split between colored functions and coloured functions
-
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 How has nobody else mentioned the orphan rule yet?
-
@arichtman @yosh told ya
-
@arichtman @pndc yeah exactly the fix is unsoundness so..
-
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
let mut → var -
@arichtman @fasterthanlime It's not quite the same thing because the languages approach traits and the problems solved by traits differently, but Scala handles this by (massive handwave over the details) giving the implementations a name, which has to be imported by the code which uses it. That way there doesn't need to be One True Implementation which limits where it can be defined. The flip side is that it needs to be imported by all library users and isn't automatically available, but since Scala code tends to wildcard-import from libraries, this is not particularly onerous.
