Hacker News Reader

To clarify: for the moment, there is no project to rewrite SpiderMonkey in Rust. However, any bit of SpiderMonkey that needs to be rewritten will be rewritten in Rust if possible, and new features that can be written in Rust will generally be written in Rust.

Note that not everything can be easily rewritten in Rust due to the existence of lots of C++ code using macros and templates. Getting such to interact with any other language than C++ is painful.

(I'm in the SpiderMonkey team)

I understand how this might be cool and exciting for the Rust community, and even for the enginnering team who might be more inclined to work in a Rust codebase.

I worry that every risk taken to improve Rust, might have a severe cost by alienating Firefox userbase, and with that Mozilla get into troubled waters.

But as you have clarified, inner pieces are being slowly replaced, which is not as bad as rewrite the whole thing from scratch in Rust, while at the same time, leaving the current C++ codebase without any improvement.

Anyway, from the enginnering perspective, kudo for you guys, for being able to make the browser work with all this complication going on under the hood.

Hope it all works out even with all the complication, challenges and risks taken, as we all need good players like Mozilla to lead us to a better future, as we rely more and more on technology to improve our daily lives.

There's already a JIT for JS coded in Rust:

https://blog.mozilla.org/javascript/2017/10/20/holyjit-a-new...

The overall goal is to have Firefox recoded in Rust, why would a JavaScript interpreter be left out?

https://wiki.mozilla.org/Oxidation

That's the whole point of Oxidation.

Of course they can do it. I just dont think is a clever move for them to do it.

Firefox is having a hard time to compete with Chrome, and they took too long pursuing other goals, and just remembering one key feature they took a lot of time to implement, was making Firefox a the multi-process browser as Chrome.

I mean, you would be ditching all this effort, rewriting it in Rust, spending key resources only to have some parity with the same browser you already had in C++, spending years, and loosing more market share, as Chrome can spend this time in optimization and features.

For the record, i think Rust is what will save Mozilla, but it must reinvent itself. Do the best they can with the firefox codebase they have, and use Rust for new projects.

Like, creating Cloud, backend system software, and reinvent itself like Ubuntu is doing right now.

They have to be very strategic and pragmatic right now. Two big moonshots, Firefox OS and Rust, and only one of them has paid out their time and resources.

If they want to bet in more moonshots, great, but they must do it in "blue ocean" places, being more innovative on where they should use Rust, were Rust can shine.

I just think that from a strategic (and even technical) point of view, they are just spending precious resources, while at the same time eroding even more their browser market share.

I see, I think we agree with each other, we are looking at things from a different angle is all. Thanks for the clarification, I do want Mozilla to succeed, we need other similar orgs to come out and be willing to compete with tech giants like Google as well, maybe Apache, but they're too busy being a giant corporate project dumping ground I suppose.

The only thing that will save Mozilla is Google coming under legal scrutiny for their privacy abuses or monopoly power.

Otherwise Mozilla lives because Google allows it and they allow it because it's mostly irrelevant and it's making itself even more irrelevant through stupidity like the MrRobot mini-scandal.

> There's already a JIT for JS coded in Rust:

To clarify: it's a proof of concept, not a full JIT for JS. If you want to follow that project, it lives here: https://github.com/nbp/holyjit.

> Javascript VM´s these days are fairly complex beasts with huge amount of man-hour and expertise.

You know what else is a MASSIVE time and money sink? C/C++.

Combining 2 big and nasty complex stuff you get something even bigger.

----

I don't say to blind rewrite. Is know to be:

> an exercize in vanity and why not say it, stupidity.

But this must take in account TIME. Right now, is not the time for a rewrite, but is better to have it planned.

----

I'm not naive saying this. This is my life (as a rewriter of codebases for several years and many projects). I'm moving a medium sized ERP project to Rust. In parts, too. Focusing in data exchange, yes. But if we don't do it, then the complexity behind will kill us.

Depends, using WinUI, Qt or Gtkmm is way faster than Gtk-rs, regarding productivity.

The topic of rewrite, i think it depends a lot of the context. Some things might make perfect sense for a rewrite, but i still think that a very optimized with huge amount of man-hour piece of sophisticated and complex C++ codebase like Spidermonkey VM are not one of those things.

Theres no gain in clear performance, unless theres a better algorithm being implemented, no clear gain in productivity, as C++ and Rust are both equaly complex beasts, and with not much gain in security, if you already implemented in "modern c++" and are using smart pointers, including in API´s and moves correctly.

The other gains in security/safety that you might have with Rust, are maybe lost if you think that the C++ codebase have been used and tested in every possible scenario, so a lot of bugs are corrected, and if you think that given this is a Jit VM you will have to use Rust´s unsafe{} in a lot of places, i still think, giving the context, that is not a smart thing to do, and it will be more like a trophy to Rust, but without a more pragmatic and realistic approach to the matter, not focusing properly on results.

Not much gain, you will end with a worse and more buggy JIT in the end, and will have to spend more years, only to get parity to the VM you already had in the first place.

That is correct, in the SHORT time. The thing with rust is that it provide safety guarantee FOREVER.

Is like null. You can write null-safe code in any language... as long your developers become "compilers" and by discipline make sure EVERY LINE is null safe. But when your lang do it for you, is a problem that get solved.

C++ demand a lot of attention to details that are unnecessary in rust. This is where the gain come.

Couldn’t you say much the same thing about Firefox as a whole?

I think so, but with the Javascript VM i think this is more clear, to the spot.

As far as i know, the web rendering engine of Firefox in C++ were pretty old, coded in old c++ style. So in this particular case a rewrite would have some leverage.

The thing is, in the end, i dont know if this part C++, part Rust codebase wont start to create more problems than it solves.

Should the layout and rendering engine be rewritten in C++ or Rust? They decided to go with Rust, and now they will be forced to continue replacing C++ codebases with Rust, for consistency, workforce, etc..

In the end they will fight a lot to recode the browser, and meanwhile the competion can optimize, inovate and create more features.

Rust will gain a lot for sure, but not Firefox, not Mozilla. And with this Mozilla will be in a place where it will need to bet everything in Rust, as its only chance of survival.

End users dont care what technology go on their browsers, they care about perception, and its not clear that a browser will work better just because its in Rust as compared to C++ which is already a high performance language. (Maybe they will spend less resources in tests or in correcting bugs, but thats pretty much it)

Firefox is much better now than it was before? Yes, but my point is it could have been this better version of itself sooner, if they did not use Firefox to fight Rust´s cruzade to relevancy.

A project is done when no one is willing to work on it anymore.

We are all employees, not owners. Decisions that look good on paper won't stop people from finding a new job if the consequences of that decision are more than you want to deal with. And won't the new person want to rewrite it anyway? Now we have a rewrite being done by a person who has no idea why all the weird code is so weird.

So the trick isn't rewrite or no rewrite, the trick is how do we make the rewrite give us things we couldn't have without it. Employee retention is important but as you say that's not enough for the board or the users.

And rewriting in phases avoids the worst aspects of rewrites, which are sometimes undertaken in bad faith (intentionally on unintentionally). Some groups I've seen seem to enjoy the fact that you get to write a lot of code without thinking too hard, and management doesn't pester you about deadlines too hard for the first six months. Those are not good reasons for a rewrite, and they usually end pretty badly. But by then the developers have been at the company long enough that the duration looks good on their resume.