I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc.
-
@chosunone @fasterthanlime I think this just comes down to making the borrow checker (static analysis) more intelligent so that you can have more granular *borrows*, right?
Actually marking the fields as mutable or immutable doesn’t make much sense to me either, so I guess you’re suggesting either new syntax when borrowing or else a smarter borrow checker?
(It’s a tension point to be sure but I don’t hit it very often)
@ianthetechie
@fasterthanlime
It's not just that. It's a guarantee that a field can never change on a structure despite other fields being mutable even with a mutable borrow existing on the entire structure. It's also useful for providing an api with public fields that shouldn't be mutated. To do that now you have to make a public getter on a private field, and then that prevents mutable borrows of the structure. -
@soc @fasterthanlime which language tried to abscond the “runtime machinery” if possible at compile time? Genuine question. I know at least one language without function colouring problem for async, but to my knowledge it always includes a runtime (golang)
@tribaal @fasterthanlime Zig tried to build a sufficiently smart compiler, and it turned out they couldn't cheat Rice's theorem.
The attempt was unceremoniously abandoned after people kept poking holes into the compiler's heuristics.
-
@soc @fasterthanlime by "named arguments" do you mean something akin to python-style kwargs? or maybe LSP inlay of argument names at callsites?
a lot of the value of argument labels comes from them being manditory and chosen by the callee. i really value Swift's API design tenet of "clarity at the point of use", and even the simple aesthetic change of going from `sayHi(person)` to `sayHi(to: person)` can make a big difference IMO
@simonomi @fasterthanlime See https://en.wikipedia.org/wiki/Named_arguments.
I don't feel like Swift's approach is a good investment of language complexity.
Not that restraint was something the language exercises in any case, but I think the feature only exists in Swift because Objective-C had it already.
-
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 syntax: angle brackets doing double duty as a kind of bracket and binary operator is a thing no language should have ever borrowed from c++, and the resultant turbofish pride is silly.
-
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 semantics: I would add a pipeline operator. I think it would simplify a lot of common expressions.
-
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!
