5 ms·
This is actually the point where Rust starts to frustrate me a little bit. Not because Rust is doing anything wrong here, but because the first well-known lang
by bunderbunder 1y ago
This is actually the point where Rust starts to frustrate me a little bit.
Not because Rust is doing anything wrong here, but because the first well-known language to really get some of these things right also happens to be a fairly low-level systems language with manual memory management.
A lot of my colleagues seem to primarily be falling in love with Rust because it's doing a good job at some basic things that have been well-known among us "academic" functional programming nerds for decades, and that's good. It arguably made inroads where functional programming languages could not because it's really more of a procedural language, and that's also good. Procedural programming is a criminally underrated and misunderstood paradigm. (As much as I love FP, that level of standoffishness about mutation and state isn't any more pragmatic than OOP being so hype about late binding that every type must support it regardless of whether it makes sense in that case.)
But they're also thoroughly nerdsniped by the borrow checker. I get it, you have to get cozy with the borrow checker if you want to use Rust. But it seems like the moral opposite of sour grapes to me. The honest truth is that, for most the software we're writing, a garbage collected heap is fine. Better, even. Shared-nothing multithreading is fine. Better, even.
So now we're doing more and more things in Rust. Which I understand. But I keep wishing that I could also have a Rust-like language that just lets me have a garbage collector for the 95% of my work where the occasional 50ms pause during run-time just isn't a big enough problem to justify a 50% increase in development and maintenance effort. And then save Rust for the things that actually do need to be unmanaged. Which is maybe 5% of my actual work, even if I have to admit that it often feels like 95% of the fun.
- legobmw99 1y agoBased on the rest of your comment I suspect you're already familiar, but a decent candidate for "Rust with a GC" is OCaml, the language the first Rust compiler was written in.
- bunderbunder 1y agoIt's close. Perhaps there's an interesting conversation to be had about why OCaml hasn't taken over the world the way Rust has. The toolchain might be a first candidate. Rust's toolchain feels so very modern, and OCaml's gives me flashbacks to late nights trying to get my homework done on the department's HP-UX server back in college.
- sn9 1y agoCan I interest you in some Moonbit? https://www.moonbitlang.com/blog/first-announce https://www.moonbitlang.com/blog/first-announce
- int_19h 1y agoWith any new language, the first question one has to ask is, "what are the guarantees that it'll still be around in 5 years?".
- bunderbunder 1y agoFor paid work, sure. But if it's for hobbies or even side hustles then I don't see any harm in prioritizing fun.
- sn9 1y agoAlways true, but they've made a remarkable amount of progress since the language was announced, and have some experienced people leading the project.
- Starlevel004 1y ago> Not because Rust is doing anything wrong here, but because the first well-known language to really get some of these things right also happens to be a fairly low-level systems language with manual memory management. It also has half implementations of all the useful features (no distinct enum variant types, traits only half-exist) because you have to code to the second, hidden language that it actually compiles to.
- whytevuhuni 1y agoYeah, I've hit the enum variant type issue myself (e.g. a function guaranteed to return one of the variants), but in practice it hasn't been that big of an issue. There's also std::mem::discriminant [1] which helps a bit. What do you mean by traits only half-existing? [1] https://doc.rust-lang.org/stable/std/mem/fn.discriminant.html https://doc.rust-lang.org/stable/std/mem/fn.discriminant.htm...
- int_19h 1y agoWell, Rust is specifically targeting the "C++ and thereabouts" bucket, so they need the borrow checker to make all those nifty abstractions zero-cost or nearly so. If that's not the goal and you really are perfectly fine with GC, then the baseline wouldn't be C++ but rather e.g. C# and Java. At which point you'd look at F# and Kotlin. Or even C# itself, which has been acquiring more and more FP-like languages over the years.
- klipilicica 1y agoI suggest taking a look at Gleam. It's a fairly new language but it's gaining traction. https://gleam.run/ https://gleam.run/
- pjmlp 1y agoPersonally I am more of an D, Delphi, Modula-3, Oberon kind of systems language kind of person, and currently I would say C# with Native AOT is good enough for me. Eventually Java with Valhala + GraalVM, if it ever comes to be. I would already be happy with Go, if it wasn't for their anti-intelectual attitude regarding programming language design.