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

[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

[poliorcetics@social.treehouse.systems]

@yosh @cyberia @fasterthanlime tuple are a sad replacement for what C allows for example.

Found the rust rfc, 2102

[chosunone@pleroma.chosunone.io]

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

[aru@hachyderm.io]

@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@social.vlhl.dev]

@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@hachyderm.io]

@lizzy Okay, I see where you're coming from. Unfortunately, it covers a lot more ground than just cargo, but yeah.

[lizzy@social.vlhl.dev]

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

[chosunone@pleroma.chosunone.io]

@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@mstdn.io]

@aru Thanks, didn't know, that sounds like it could be enough for me.

[fasterthanlime@hachyderm.io]

I think I may have accidentally come up with a drinking game

If someone mentions function coloring, you have to finish your glass

[samir@mastodon.functional.computer]

@fasterthanlime Better handling of & so I don’t ever have to call .as_ref(), and similar syntax for impl AsRef<Thing> so I don’t have to care about whether it’s an Rc or an Arc or whatever.

[samir@mastodon.functional.computer]

@fasterthanlime Future should be a wrapper around Pin<Box<dyn FutureImpl>>. It would cost almost nothing and make a lot of async stuff way easier.

(Bonus points if Pin goes 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.)