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

[megmac@social.treehouse.systems]

@fasterthanlime semantics: I would add a pipeline operator. I think it would simplify a lot of common expressions.

[megmac@social.treehouse.systems]

@fasterthanlime types: first class non-moveable and non-droppable traits.

[megmac@social.treehouse.systems]

@fasterthanlime and not what you asked but I think function coloring is not only fine, but desirable. Where I think rust has gone wrong in async is in the main libraries trying way too hard to pretend that an async executor is some ambient global thing that you can pretend you don't know about, and it creates an expectation of magic that can't be met.

Async functions are ultimately just a shorthand for state machines. They have uses even in otherwise not "async" code. But you need to know when you're interacting with a state machine and when you're not.

[megmac@social.treehouse.systems]

@fasterthanlime oh and governance: almost(*) any implemented rfc should be either accepted and stabilized or removed altogether after a reasonable discussion period in order to eliminate the bifurcated world where compiler and stdlib developers get to use features that languish for years (now some of them coming on a decade) in bikeshedding hell.

I call this the "shit or get off the pot rule." If I feature is important enough to use, it is important enough to stabilize.

(*) a separate category of feature flag should be established for the few things that are deep compromises that should never be stabilized but are necessary for the compiler to use.

[graydon@types.pl]

@fasterthanlime I'll need to make a parallel drinking game for "things that rust literally already had at one point in its evolution but then people decided they didn't want it after all"

[fasterthanlime@hachyderm.io]

@graydon Graydon nooooo you were not meant to find this thread

[fasterthanlime@hachyderm.io]

@graydon mmmm but honestly I think rust should have more sigils, green threads, and a gc (/s)

[graydon@types.pl]

@fasterthanlime anonymous/structural types, square brackets for type parameters, in/out/inout parameter modes, uniform final-semicolons, a casual gc subheap, mut qualifiers on fields, generators ... folks just love the classic oldies!

[graydon@types.pl]

@fasterthanlime obviously for April fools I should announce a vibe-coded Rust Classic

[fasterthanlime@hachyderm.io]

@graydon my YT channel is all yours

[aiono@mastodon.social]

@fasterthanlime optional GC support. Maybe the heal allocation can be an effect. This way when you have realtime constraints you can force a function to not to trigger a GC cycle.

[pierrelebeaupin@mastodon.gougere.fr]

@fasterthanlime Honestly at this point the only thing I got is the remarks in the last part of https://without.boats/blog/pinned-places/ ("For the next language"): you should be able to obtain an exclusive reference to a self-referential struct.

[hetoug@fosstodon.org]

@fasterthanlime @graydon I'm looking forward to that

[pierrelebeaupin@mastodon.gougere.fr]

@chosunone @fasterthanlime Since these references couldn't interoperate with regular ones (cf "offset pointers" in https://without.boats/blog/pin/ ), the general consensus seems to be that such a language feature would bring little value when compared to directly working with indexes (in place of references or pointers).

[pierrelebeaupin@mastodon.gougere.fr]

@fasterthanlime Les partisans des fonctions vertes et des vertes fonctions restent irréconciliables…

[fasterthanlime@hachyderm.io]

@PierreLebeaupin schtroumpf alors!

[rdeaton@infosec.exchange]

@fasterthanlime I'd go for removal of the orphan rule for binaries. While I wish the justification wasn't as strong for libraries, I understand it and can get behind it, but for a binary target, I'd be fine with an opt-in "I'm an adult and drop the orphan rule, I'll accept any breakage that comes as a result" flag in Cargo.toml