I love Rust. I've lost track of the number of times I've stared at a chunk of C++ code, considered how much nicer it would look in Rust, and sighed. At the beginning of this project, we did consider whether it was the right place to use Rust.
There are no existing JS-compatible regexp crates. BurntSushi's regex crate is great, but finite automata don't do backreferences, which is a dealbreaker for JS. After this code landed, somebody brought https://github.com/ridiculousfish/regress to my attention. It looks promising, but still has a long way to go before it's production-ready, and it didn't exist when we made our decision.
If we had written our own replacement, it would likely have been Rust. SpiderMonkey has a lot of cross-cutting issues (GC especially) that make it hard to replace individual C++ components with Rust, but the regexp engine has a pretty clean API boundary. It's the same reason that it was feasible to swap in Irregexp in the first place.
Ultimately we decided that writing a new engine wasn't the best use of time. A regexp engine is a complicated beast. Writing a new high-performance, JS-compatible engine in Rust could have been person-years of effort, with a long tail of corner cases and performance issues. We haven't had many memory safety bugs in regexp code. As sstangl points out in a sibling comment (hi Sean!), doing JIT compilation undermines some of Rust's safety guarantees.
When it comes down to it, the regexp engine is not a place where SpiderMonkey is looking to push the state of the art. We have to be reasonably fast and feature-complete, but beyond that nobody is going to notice marginal gains. There are higher-leverage opportunities elsewhere.
So another up and coming crate in this space is Raph Levien's fancy-regex [0] which uses a hybrid model to support back references. No idea how compatible the syntaxes are.
JIT engines like this one don't receive much benefit from being rewritten in a memory-safe language. Errors typically occur in the generated machine code, not in the compiler itself. The benefit would be small.
There's more benefits to Rust than just it's memory safety. It being a non-GCed language with ADTs is a big one, and that's been nice for the couple JITs I've written in Rust.
And the partial memory safety over the metadata around the actual JITed code is a big win as well.
Yes, Rust doesn't get you there 100%, but IMO it gets you closer than C or C++.
Having used both (and in the space for writing JITs particularly), C++'s support is very weak in the space of ADTs. Like most things in C++ you _can_ reach it with straight jacketing yourself in a particular way, with 80/20 static analysis rules backing that and 20% manual code review, but it's difficult to maintain.
Rust gives you that more or less by default and for free wrt tooling. It's sort of the classic "Rust makes you write the C++ you should have been writing all along", which makes it a net win IMO.
Given the fact that Mozilla is the primary sponsor of Rust, and Rust has been sneaking its way into Chrome as well, I'd say the authors of those browsers disagree with you.
I'm not them, but I suspect that they're slowly switching not because of its slightly better abstract data types but because it offers better memory safety.
Those are one and the same. The ADTs are how the shape and validity of the data is described to the compiler in a lot of cases. Rust wouldn't be able to be memory safe without it.
C++'s ADTs are easy to subvert even accidently; Rust's can't be without explicitly calling it out as unsafe.
It allows you to describe transformations of state in a formal set theoretical way. You should check out formally verified software like CompCERT and sel4 and their heavy use ADTs internally to achieve that. Rust obvs isn't full formally verified but it's a neat 80/20 in that direction.
That's exactly the point I wanted to make (but failed to) a couple months ago [1] - that for the (few) tasks you'd use C for (such as writing language runtimes) Rust might not be a good fit. If it isn't a good fit for regexp, it might not be a good fit for JavaScript either.
It’s not that rust wasn’t a good fit. It’s that writing a regex engine from scratch in rust to be integrated into their c++ code base wasn’t the right choice for them when compared against integrating an existing c++ solution.
