I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc.
-
@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
@tribaal @fasterthanlime I think other languages promised that, and they could not deliver on these promises.
-
@fasterthanlime Swift-style argument labels! IMO the most underrated feature that literally every programming language would be better off with (clearer APIs with no downside!!)
@simonomi @fasterthanlime I don't feel they add much benefit on top of named arguments ... is there a good argument to not spend that language complexity elsewhere?
-
@fasterthanlime the orphan rule.
@vbfox what's the alternative?
-
@simonomi @fasterthanlime I don't feel they add much benefit on top of named arguments ... is there a good argument to not spend that language complexity elsewhere?
@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
-
@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
@soc @fasterthanlime aside from clarity, being able to 'overload' on argument labels is really really nice, and Rust deals with a lot of same-method-but-with-try/mut-instead 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 this one is a bit tongue-in-cheek, but i think nearly every programmer/language designer has something to learn from the Swift API design guidelines. if Rust could just steal that in its entirety (and probably improve upon it!) that'd be perfect
Swift.org
Swift is a general-purpose programming language built using a modern approach to safety, performance, and software design patterns.
Swift.org (swift.org)
-
@tribaal @fasterthanlime I think other languages promised that, and they could not deliver on these promises.
@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)
-
Unfortunately the ecosystem is split between colored functions and coloured functions
@fasterthanlime maybe we can try to get the ecosystem united by compromising and spelling it coulored from now on?
-
@vbfox what's the alternative?
There are various ways we could relax it a little. Allow top-level crates to implement arbitrary traits for arbitrary types. Allow libraries to opt-in to having new impls for their traits/types. In general, I'd love to see it become possible to integrate crate A with crate B using crate AB, rather than A or B; that would remove a major scaling issue and source of lock-in in the ecosystem. -
@vbfox what's the alternative?
@fasterthanlime naming of trait implementations then an explicit way to bring one of them into scope (“use” ?) and a way to specify them per-callsite.
The current syntax would be the equivalent of allowing anonymous implementations that are automatically applicable to any scope where no other named implementation has been specified.
impl Clone as MyClone for u32 {
use lib::MyClone;
// or
let x: u32 + MyClone = 42; -
@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
