256
Rust is Eating JavaScript
(leerob.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 16 Feb 2025
256 points (94.4% liked)
Technology
65882 readers
1298 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
The JS tooling universe has always seemed like a Lovecraftian hellscape to me. I've managed to stay away from it so far, but if I were caught in it, of course I'd be trying to escape any way I could. It sounds like Rust's attraction here has been as a viable escape corridor rather than anything about Rust per se.
In particular, I get that everyone wants their code to be faster, and I get that certain bloaty apps (browsers) need to get their memory footprint under control, and a few niche areas (OS kernels, realtime control) can't stand GC pauses. Other than that though, what is the attraction of Rust for stuff like tooling? As opposed to a (maybe hypothetical) compiled, GC'd language with a good type system and not too much abstraction inversion (Haskell's weakness, more or less).
Has Golang fizzled? It has struck me as too primitive, but basically on the right track.
Rust seems neat from a language geek perspective, but from what I can tell, it requires considerable effort from the programmer handle a problem (manual storage reclamation) that most programs don't really have. I do want to try it sometime. So the Rust question is intended as more inquisitive/head scratching rather than argumentative.
I think once you get into rust you just have a hard time going back, and it doesn't feel "hard" anymore. I can practically rust as easily as I can python for scripting and for API servers.
Rust really only gets hard when doing library development IMO. That's when you need lifetimes and well chosen types. But that's also why Rust libraries are superb.
I had the impression Rust doesn't handle concurrency particularly well, at least no better than Python, which does it badly (i.e. with colored functions). Golang, Erlang/Elixir, and GHC (Haskell) are way better in that regard, though they each have their own unrelated issues. I had believed for a while that Purescript targeting the Erlang VM and with all the JS tooling extirpated might be the answer, but that was just a pipe dream and I don't know if it was really workable.
Rust makes multi threading very easy you can just use
But rust makes Async difficult because it's naturally stackless so you need to create your own scheduler or use someone else's like Tokio. Also, people have a bad habit of conflating async with concurrency which makes it more confusing.
Sure you can spawn threads but now you have all the hazards of shared memory and locks, giving the 2.0 version of aliasing errors and use-after-free bugs. Also, those are POSIX threads, which are quite heavyweight compared to the in-process multitasking of Golang etc. So I would say that's not really an answer.
Go routines are certainly special and hard to match, but rust has all the normal abstractions of a language like C, just with a borrow checker so you can avoid memory leaks, write after read, etc.
What exactly are the hazards of shared memory and locks? The ownership system and the borrow checker do a pretty good job at enforcing correct usage, and if you are clever you can even guarantee no deadlocks (talk at rustconf 2024 about the fuchsia network stack).
Have you tried Gleam?
No I haven't, I'll take a look at it, though I felt suspicious of "task.async" as shown on the front page of gleam.run.
I don't know but I don't think rust has that problem. In fact I've always thought its data ownership paradigm is literally the most optimal approach to concurrency and parallelism. I really love using rayon in rust for instance.
True, but of course it's always a trade-off. At a certain point I have to defer to your judgment, at least until I've written some Rust code. But I've written a fair amount of C++ and a little bit of Ada and don't find them all that convenient compared to Python or Haskell or whatever. We'll see. ;)
IME a language is as good as its package manager and libraries, and cargo is great.