171–180 of 323 posts
Earlier quoted context omitted.
Can we get a version of Rust that swaps lifetimes and ownership for a GC and a JS-style event loop? I love the DX of the language, but I don't always need to squeeze out every microsecond of performance at the cost of fighting the borrow checker.
https://ocaml.org/
Earlier quoted context omitted.
IMO rust started at this from the wrong direction. Comparing to something like zig which just cannot panic unless the developer wrote the thing that does the panic, cannot allocate unless the developer wrote the allocation, etc. Rust instead has all these implicit things that just happen, and now needs ways to specify that in particular cases, it doesn't.
Huh? It seems to me that in these respects the two languages are almost identical. If I tell the program to panic, it panics, and if I divide an integer by zero it... panics and either those are both "the developer wrote the thing" or neither is.
Rust tries to prevent developers from doing bad things, then has to include ways to avoid these checks for cases where it cannot prove that bad things are actually OK. Zig (and many others such as Odin, Jai, etc.) allow anything by default, but surface the fact that issues can occur in its API design. In practice the result is the same, but Rust needs to be much more complex both to do the proving and to allow the developers to ignore its rules.
[1]: https://ziglang.org/documentation/0.15.2/std/#std.math.divEx...
Earlier quoted context omitted.
I feel you, but hear me out. OP is right. I've wanted pretty much everything he's talking about here for years, I just never thought of all of this in as quite a formal way as he has. We need the ability to say "this piece of code can't panic". It's super important in the domains I work in. We also need the ability to say "this piece of code can't be non-deterministic". It's also super important in the domains I work…
Perhaps there are similarities to Scala, from my anecdotal observation. Coming from Java and doing the Scala coursera course years ago, it feels like arriving in a candy shop. All the wonderful language features are there, true power yours to wield. And then you bump into the code lines crafted by the experts, and they are line for line so 'smart' they take a real long time to figure out how the heck it all fits toge…
Thing is, the alternative to "smart" code that packs a lot into a single line is code where that line turns into multiple pages of code, which is in fact worse for understanding. At least with PL features, you only have to put in the work once and you can grok how they're meant to be used anywhere.
Earlier quoted context omitted.
The lack of use cases in that document is a concern. They're all "nice to have" features, but is the payoff there for real work? The "effects" section mentions properties useful for a proof system. But it's not part of a proof system. If it were, most of those could be found automatically by static analysis, without bothering the programmer. (I was doing that decades ago in a very early proof of correctness system.)…
I would also have liked to see some motivational examples, but I think the most interesting upside of an effect system is composability. Rust is actually really unique among imperative languages in its general composability - things just compose really well across most language features. The big missing pieces for composability are higher-kinded types (where you could be generic over Option, Result, etc.), and effect…
Earlier quoted context omitted.
You know what, I’ve heard people say this and thought “OK, maybe these other languages with GCs and huge runtimes really do something magical to make async a breeze”. But then I actually tried both TypeScript and C#, and no. Writing correct async code in those languages is not any nicer at all. What the heck is “.ConfigureAwait(false)”? How fun do you really think debugging promise resolution is? Is it even possible…
In .NET 11 C# async management moved to the runtime, mostly eliminating heap allocations and also bringing clean stack traces. You really only need to think about ConfigureAwait(false) when building shared libraries or dealing with UI frameworks (even there you mostly don't need it).
Earlier quoted context omitted.
Apparently you missed Swift. Linux kernel adoption of Rust hasn't been a smooth ride, exactly because of its type system among C folks. It is only happening because the likes of Google and Microsoft want to see it through.
Swift is not really for systems level programming like Rust and interestingly some projects like Ladybird have moved away from Swift towards Rust.
It is all over the place in Swift documentation, WWDC sessions, and even last week on Meet the Team session, regarding on how to write safe systems programming code on Apple platforms.
Ladybird should focus on what language they actually want to deliver something.
Earlier quoted context omitted.
You know what, I’ve heard people say this and thought “OK, maybe these other languages with GCs and huge runtimes really do something magical to make async a breeze”. But then I actually tried both TypeScript and C#, and no. Writing correct async code in those languages is not any nicer at all. What the heck is “.ConfigureAwait(false)”? How fun do you really think debugging promise resolution is? Is it even possible…
Try golang, where they did the only sane thing: everything is async from the very beginning, no function colouring
Reposting my comment from Reddit, I had some Scala 3 feelings when reading the vision, I hope Rust doesn't gets too pushy with type systems ideas. That is how we end with other ecosystems doubling down in automatic memory management with a good enough ownership model for low level coding, e.g. Swift 6, OxCaml, Chapel, D, Linear Haskel, OCaml effects,... Where the goal is that those features are to be used by experts,…
Doubt Rust will ever get to implicit hell of Scala 2. If for anything, Rust isn't married to C as Scala is to Java.