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 types: first class non-moveable and non-droppable traits.
-
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 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.
-
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 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.
-
I think I may have accidentally come up with a drinking game
If someone mentions function coloring, you have to finish your glass
@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 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
