seems rust's biggest win was improving other languages toolchains and bringing increased productivity to those languages.
1. Banning shared, mutable data. You can't change data that other code might be reading. This is a huge win for threading and multiple CPUs, but it's a dramatic departure from other popular languages.
2. Knowing how data is laid out in memory. This is classic "systems programming" stuff, and it's also present in C, C++, Zed, etc. This usually goes along with making memory allocation visible (though not always in C++). This is a big win for performance.
If you wanted to build a "scripting language" version of Rust, you could probably lose (2). Languages like Haskell are even stricter than Rust, but they hide the details of memory layout. But then you need to decide whether to keep or lose (1). If you keep it, your language will have good threading, but users will need to think about ownership and borrowing. If you lose (1), then your language won't feel very much like Rust.
It would be an interesting intellectual exercise! But actually turning it into a popular scripting language would probably require the same luck and the same 10 years of work that most successful languages need to get real traction.
Not really no. I work on an interpreted language runtime in Rust professionally and it's still a huge help even if you're still eating perf pain on the interpreted language itself for the same reasons everyone else does. There's more benefit to Rust than you're really capturing here but that's to be expected, it's a short comment.
Here are some other things we get from using Rust for interpreted languages:
- The `unsafe` parts are relatively limited in scope and we have much better and more automated verification tools for `unsafe`, especially WRT undefined behavior
- Being able to make large architectural changes and work through them mechanically/quickly because of the type-checking and borrow-checking is absurdly powerful for any project, all the more so in this context.
- The library ecosystem for Rust has been fantastic for all kinds of projects but it's especially good for PL runtimes.
- LLMs are a lot better at Rust than other programming languages. I have a lot of experience using LLMs in a variety of domains and programming languages and it's far better at Rust than anything else that's expressly about programming. Arguably it's even better at Terraform and Ansible but I consider that a different category. Controversial point maybe but I get tremendous yield out of it.
- It's not just that Rust is fast. It is on par w/ C/C++ all else being equal. What's significant here is that it is a _lot_ quicker/easier to hit the 80/20 perf targets as well as the bleeding edge performance frontier in a Rust application than it is in C and C++. A lot of C and C++ projects leave performance on the table either because it's too hard to make the ownership model human-maintainable/correct or because it would be too much work to refactor for the hoped-for perf yield. Not as much an issue in Rust. You can gin up hypothetical perf improvements in Rust with gpt-5 lickety-split and the types/borrowck will catch most problems while the agent is iterating.
Shared, mutable data aren't really banned, we use it strategically in our Rust interpreter, it's just not default-permitted. Aliasing is precisely the distinction between a safe reference and an unsafe pointer in Rust. Aliasing a mutable pointer in Rust isn't UB, it's just `unsafe`. OTOH, aliasing a mutable reference _is_ UB and not allowed in Rust. Miri will catch you if you do this.
On top of all that, you have some nice kit for experimenting with JIT like Cranelift.
I am a huge Rust fan, but never really got a chance to write it in the modern LLM era. It makes absolute sense that the borrow checker would make LLM agent-driven refactors easier.
What do you need a scripting language for that's different than using Rust?
Cargo only recompiles the crates that you edit, after the first build of the dependent crates it's quick to iterate.
Compilation is not the bottleneck, it's the human (me) in the loop that's doing the thinking and typing.
The productivity boost comes from Rust's strong type system and ownership (much better than MyPy) which practically ensures that if it compiles, it will work. There's a lot less troubleshooting/debugging of my Rust "scripts" than when I wrote Python.
Thanks for giving Raku a test drive (https://raku.org)
While Raku can access all the perl CPAN modules and Python modules via Inline::Perl5 and Inline::Python, I agree native modules are also a good indication of the level of "adoptability" of a language.
I would say that Raku is currently ready for "bleeding edge" and "early-adopters" but not for "early-main" (terms from Crossing the Chasm)
For example, there are three pretty nice actively maintained web framework libraries:
- Cro (also HARC stack that uses Cro)
- Hummingbird
- Web::App
Similar stories for each of the domains you mention: https://chatgpt.com/share/68c67f75-d654-8009-9c8d-fdb1081869...
It's a small thing in the Rust community but it's pretty huge in the world simply because there are so many Python developers (and also because of the extreme magnitude of improvement). Probably wouldn't have happened without Rust.
Ripgrep, fd, tokei, Just, zellij, uv, and so forth. Porting languages has given the opportunity to remove some of the cruft decided on a whim in the 70s. None of these are world changing, but they do make life easier than the originals.
Rust (or Go) are about the only popular languages around that can meet the spec. That Rust will always be theoretically more performant than GC Go makes it the more attractive option for re-imagining some of these bedrock utilities.
Granted, not all of them are popular, but that is how Rust started off, too, right?
---
Ada would have been great as it is quite mature and used for serious and critical software, but lacks the "cool factor" that Rust has.
I would like to add, that there is clearly a disconnect between technical merit and adoption. Ada is a perfect example of this. It has been around since the 1980s with:
* Stronger safety guarantees than Rust in many ways (stricter type system, built-in contracts, formal verification support)
* Proven track record in safety-critical systems (aerospace, defense, medical devices)
* Native compilation with no runtime overhead
* Mature toolchain and decades of real-world deployment
* ... and much more.
If safety was truly the driving factor, Ada should have dominated systems programming decades ago. But it didn't, and that reveals what's really going on.
I believe that Rust was chosen over Ada because of:
* Timing - arrived when web developers were ready to try systems programming
* Community building - excellent documentation, welcoming culture, modern package manager[1]
* Aesthetic appeal - syntax familiar to C/Java/JavaScript developers
* Marketing narrative - "systems programming without fear", i.e. fuckton of hype
Ada had superior safety for decades but lacked the cultural momentum. It was associated with DoD contracts and enterprise software, not cool indie CLI tools.
[1] Ada has Alire now as its modern package manager.
I wonder why, too. Now, you can give me a reply for why you think that is, which you could have done without this comment, or you can just keep adding noise to this thread. Up to you.
Whereas anyone who uses Python would have heard of uv and why it’s much faster than other tools.
But even if you're not wrong, a major mission of Rust was to be a safer C/C++, and language tooling used to be dominated by those languages.