I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc.
-
@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"
@graydon Graydon nooooo you were not meant to find this thread
-
@graydon Graydon nooooo you were not meant to find this thread
@graydon mmmm but honestly I think rust should have more sigils, green threads, and a gc (/s)
-
@graydon mmmm but honestly I think rust should have more sigils, green threads, and a gc (/s)
@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!
-
@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!
@fasterthanlime obviously for April fools I should announce a vibe-coded Rust Classic
-
@fasterthanlime obviously for April fools I should announce a vibe-coded Rust Classic
@graydon my YT channel is all yours
-
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 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.
-
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 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.
-
@graydon my YT channel is all yours
@fasterthanlime @graydon I'm looking forward to that
-
@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.
@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).
-
Unfortunately the ecosystem is split between colored functions and coloured functions
@fasterthanlime Les partisans des fonctions vertes et des vertes fonctions restent irréconciliables…
-
@fasterthanlime Les partisans des fonctions vertes et des vertes fonctions restent irréconciliables…
@PierreLebeaupin schtroumpf alors!
-
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'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
-
R relay@relay.infosec.exchange shared this topic
