Why is Rust being used to replace parts of the JavaScript web ecosystem like minification (Terser), transpilation (Babel), formatting (Prettier), bundling (webpack), linting (ESLint), and more?
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
thread::spawn();
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.
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).
It’s statically compiled and isn’t dependent on system binaries and won’t break if there if the system has the wrong version like C/C++, allowing you to distribute it as a single binary without any other installation steps
Still produces fairly small binaries unlike languages like Java or C# (because of the VM)
Is a modern language with a good build system (It’s like night and day compared to CMake)
And I just like how the language works (errors as values etc.)
It’s statically compiled and isn’t dependent on system binaries and won’t break if there if the system has the wrong version like C/C++, allowing you to distribute it as a single binary without any other installation steps
You can do that with C++ too.
Still produces fairly small binaries unlike languages like Java or C# (because of the VM)
I mean, the jars are actually pretty small; but also I really don’t get the storage argument. I mean we live in a world where people happily download a 600 MB discord client.
Is a modern language with a good build system (It’s like night and day compared to CMake)
Meson exists … as do others.
And I just like how the language works (errors as values etc.)
Fair enough; though why? What’s wrong with exceptions?
I work in a code base where I can’t use exceptions because certain customers can’t use exceptions, and I regularly wish I could because errors as values is so tedious.
Is a modern language with a good build system (It’s like night and day compared to CMake)
Meson exists … as do others.
But they are not the default option. And your new job may not use them.
And I just like how the language works (errors as values etc.)
Fair enough; though why? What’s wrong with exceptions?
Exceptions is a non standard exit point. And by “non standard” I’m not talking about the language but about its surprise appearance not specified in the prototype. Calling doublefoo(); you don’t know if you should try/catch it, against which exceptions, is it an internal function that may throw 10 level deep ?
By contrast fnfoo() ->Result<f64, Error> in rRst tell you the function may fail. You can inspect the error type if you want to handle it. But the true power of Result in Rust (and Option) is that you have a lot of ergonomic ways to handle the bad case and you are forced to plan for it so you cannot use a bad value thinking it’s good:
foo().unwrap() panic in case of error (see also expect)
foo().unwrap_or_default() to ignore the error and continue the happy path with 0.0
foo().unwrap_or(13.37) to use your default
foo()? to return with the error and let the parent handle it, maybe
Checked exceptions require a function to declare the exceptions it can throw. The caller function must then catch and handle the exception, or the exception would bubble up a level, in which case the caller must also include that exception among the exceptions it declares that it can throw. I don’t know if C++ does this, but Java/C# do. It sounds exactly like Rust’s system except with different syntax.
But they are not the default option. And your new job may not use them.
Who cares if it’s the default? If it’s the best tool, use it.
It’s silly to have a reason for “going Rust” be the build system, especially in the context of something as new as a WASM context where basically any project is going to be green field or green field adjacent.
Exceptions is a non standard exit point. And by “non standard” I’m not talking about the language but about its surprise appearance not specified in the prototype. Calling double foo(); you don’t know if you should try/catch it, against which exceptions, is it an internal function that may throw 10 level deep ?
And that’s a feature not a bug; it gets incredibly tedious to unwrap or forward manually at every level.
By contrast fn foo() -> Result<f64, Error> in rRst tell you the function may fail. You can inspect the error type if you want to handle it. But the true power of Result in Rust (and Option) is that you have a lot of ergonomic ways to handle the bad case and you are forced to plan for it so you cannot use a bad value thinking it’s good:
Has Golang fizzled? It has struck me as too primitive, but basically on the right track.
My biggest issue with Golang by far is the close tie to Google. They are not our friendly innovator, time and time again they make decisions that will help them earn more ad money, and nothing else. And they have a lobg history of releasing something and then never fix the issues with it, and then more or less abandon it.
Other than that there are afaik some other issues with go, I’m not an expert but from what I hear the GC is quite aggressive and you can’t tell it to run when you want. Doing something time sensitive? Well, bad luck. GC time!
The GC in Go is fantastic IMO since it runs in a separate thread. I used it since 1.0 (switched our product from node.js), and dealt with all the the pain of an imprecise GC (fixed in 1.5?) and all the little improvements to arrive at it’s current state.
The main issues I have with it are pretty core to the language, unfortunately, such as:
interface{} is basically a void*, but since it’s a fat pointer, it can hold nil without itself being nil, which can happen by accident
runtime reflection is a bad habit, but it’s unfortunately really common
it’s really easy to deadlock by making stupid mistakes; if it had automatic unlocking based on scope (like Rust, or something like Python’s context managers), we could solve this, but defer just isn’t good enough
no destructors - with destructors, we could build a solution to deadlocks
Maybe they fixed some of those issues, idk, I haven’t used it for several years. I did use it for about 10 years though.
I assume you’re talking about runtime. AddCleanup()? That’s certainly nice, but it’s not the same as a destructor since it only runs at GC time. It’s useful for cleaning up data used by a shared library or something (e.g. something malloc’d by a C lib), but it only solves part of the problem.
I’m talking about scope guards. In Rust, here’s how you deal with mutexes:
{
letvalue = mutex.Lock();
... use value ...
// mutex.Unlock() automatically called
}
The closest thing in Go is defer():
mutex.Lock()
defer mutex.Unlock()
That works most of the time, but it doesn’t handle more complex use cases, like selectively unlocking a mutex early while still guaranteeing it eventually gets unlocked.
Rust fixes this with the Drop trait, so basically I can drop something early conditionally, but it’ll get dropped automatically when going out of scope. For example:
Without the last line, this prints c, b, a, i.e. stack order. With the last line, it instead prints b, c, a, because I drop b early.
This is incredibly useful when dealing with complex logic, especially with mutexes, because it allows you to cleanly and correctly handle edge cases. Things are dropped at block scope too, giving even more control of semantically releasing things like locks.
That said, 1.24 added WASM, which is really cool, so thanks for encouraging me to look at the release notes.
Thanks for taking the time to explain it. Indeed the new runtime method does not guarantee when the resource will be cleaned, so something like that Drop trait would be quite useful
Rust is the best language for writing WASM in, so you can write Rust and run it in the browser without transpiling to JS.
Rust isn’t just about speed or GC pauses. Its type system is amazing and allows you to encode things that you cannot in any other mainstream language.
It’s so incredibly well designed, it fewla like that clip from Ricky and Morty where Morty feels what standing on a truly even plane feels like then has a panic attack when he leaves. Rust rethought everything from scratch, and isn’t just some new syntax or fancy compiler tricks. No null, no exceptions, no inheritance, new typing capabilities, etc.
Go made some pretty poor design choices, and now even Google is choosing Rust for a lot of stuff instead.
I think there’s room for a rust-lite language that is GCed. Something with a functional-style type system and that compiles to machine code.
Roc is a candidate for this language. Basically Elm that compiles to machine code, but with a number of tweaks to make it work for more than just a web front end. Like Elm, the type system is haskell like, but simplified.
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.
Go is fine, but it has its flaws. I prefer Rust because:
()is semantically different), so no surprises with contractsIt takes longer to learn, but I’m about as productive with both now.
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
thread::spawn();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.
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).
I usually pick Rust for CLI tools because:
You can do that with C++ too.
I mean, the jars are actually pretty small; but also I really don’t get the storage argument. I mean we live in a world where people happily download a 600 MB discord client.
Meson exists … as do others.
Fair enough; though why? What’s wrong with exceptions?
I work in a code base where I can’t use exceptions because certain customers can’t use exceptions, and I regularly wish I could because errors as values is so tedious.
But they are not the default option. And your new job may not use them.
Exceptions is a non standard exit point. And by “non standard” I’m not talking about the language but about its surprise appearance not specified in the prototype. Calling
double foo();you don’t know if you should try/catch it, against which exceptions, is it an internal function that may throw 10 level deep ?By contrast
fn foo() -> Result<f64, Error>in rRst tell you the function may fail. You can inspect the error type if you want to handle it. But the true power of Result in Rust (and Option) is that you have a lot of ergonomic ways to handle the bad case and you are forced to plan for it so you cannot use a bad value thinking it’s good:foo().unwrap()panic in case of error (see alsoexpect)foo().unwrap_or_default()to ignore the error and continue the happy path with 0.0foo().unwrap_or(13.37)to use your defaultfoo()?to return with the error and let the parent handle it, maybeThat sounds a lot like how checked exceptions work, though with some terser handling syntax.
First time I hear about checked exceptions. How do you use them ? Are you forced to handle them explicitly ? Is the handling checked at compile time ?
Checked exceptions require a function to declare the exceptions it can throw. The caller function must then catch and handle the exception, or the exception would bubble up a level, in which case the caller must also include that exception among the exceptions it declares that it can throw. I don’t know if C++ does this, but Java/C# do. It sounds exactly like Rust’s system except with different syntax.
Who cares if it’s the default? If it’s the best tool, use it.
It’s silly to have a reason for “going Rust” be the build system, especially in the context of something as new as a WASM context where basically any project is going to be green field or green field adjacent.
And that’s a feature not a bug; it gets incredibly tedious to unwrap or forward manually at every level.
You can do this in C++ https://en.cppreference.com/w/cpp/utility/expected (and as I said, if you feel so inclined, turn off exceptions entirely); it’s just not the “usual” way of doing things.
That’s most of any programming of today for me.
If it can’t be grasped in a couple of days - then na-ah.
I can patch something I need working which doesn’t, written in C.
autotools ftw
My biggest issue with Golang by far is the close tie to Google. They are not our friendly innovator, time and time again they make decisions that will help them earn more ad money, and nothing else. And they have a lobg history of releasing something and then never fix the issues with it, and then more or less abandon it.
Other than that there are afaik some other issues with go, I’m not an expert but from what I hear the GC is quite aggressive and you can’t tell it to run when you want. Doing something time sensitive? Well, bad luck. GC time!
Guess who’s one of the rounders of the Rust Foundation…
The GC in Go is fantastic IMO since it runs in a separate thread. I used it since 1.0 (switched our product from node.js), and dealt with all the the pain of an imprecise GC (fixed in 1.5?) and all the little improvements to arrive at it’s current state.
The main issues I have with it are pretty core to the language, unfortunately, such as:
interface{}is basically avoid*, but since it’s a fat pointer, it can holdnilwithout itself beingnil, which can happen by accidentdeferjust isn’t good enoughMaybe they fixed some of those issues, idk, I haven’t used it for several years. I did use it for about 10 years though.
Not sure if that’s what you are referring to as destructors, but they added a new way to have code run at resource collection in go 1.24
I assume you’re talking about
runtime. AddCleanup()? That’s certainly nice, but it’s not the same as a destructor since it only runs at GC time. It’s useful for cleaning up data used by a shared library or something (e.g. something malloc’d by a C lib), but it only solves part of the problem.I’m talking about scope guards. In Rust, here’s how you deal with mutexes:
{ let value = mutex.Lock(); ... use value ... // mutex.Unlock() automatically called }The closest thing in Go is
defer():mutex.Lock() defer mutex.Unlock()That works most of the time, but it doesn’t handle more complex use cases, like selectively unlocking a mutex early while still guaranteeing it eventually gets unlocked.
Rust fixes this with the
Droptrait, so basically I can drop something early conditionally, but it’ll get dropped automatically when going out of scope. For example:struct A(String); impl Drop for A { fn drop(&mut self) { println!("dropping {}", self.0) } } fn main() { let a = A("a".into()); let b = A("b".into()); let c = A("c".into()); drop(b); }Without the last line, this prints c, b, a, i.e. stack order. With the last line, it instead prints b, c, a, because I drop b early.
This is incredibly useful when dealing with complex logic, especially with mutexes, because it allows you to cleanly and correctly handle edge cases. Things are dropped at block scope too, giving even more control of semantically releasing things like locks.
That said, 1.24 added WASM, which is really cool, so thanks for encouraging me to look at the release notes.
Thanks for taking the time to explain it. Indeed the new runtime method does not guarantee when the resource will be cleaned, so something like that Drop trait would be quite useful
Go made some pretty poor design choices, and now even Google is choosing Rust for a lot of stuff instead.
I think there’s room for a rust-lite language that is GCed. Something with a functional-style type system and that compiles to machine code.
Roc is a candidate for this language. Basically Elm that compiles to machine code, but with a number of tweaks to make it work for more than just a web front end. Like Elm, the type system is haskell like, but simplified.
There’s already Swift, which isn’t garbage collected, but the ref. counting does the same in practice.
The only problem with Rust and Swift, Kotlin etc. in my opinion is that they keep growing and getting more complex with no signs of stopping.