Mozilla should've finished rewriting Firefox completely in Rust to give them an Unique Selling Point. They didn't because of management's hubris to build their own mobile operating system to take on Google (its largest financier). Google probably warned them that it would pull back its money if FirefoxOS managed to grab any significant market share. So it was destined to fail from day one.
I'm surprised they didn't integrate their own internet search engine into Firefox. But the contract with Google probably prohibits it and Google would immediately pull the plug on Firefox if it got wind of it anyway.
>Mozilla should've finished rewriting Firefox completely in Rust to give them an Unique Selling Point. They didn't because of management's hubris to build their own mobile operating system to take on Google (its largest financier).
Firefox is like 25 million lines of code. Incredibly complex code, much of it decades old and wrapped in layers of legacy architectural patterns (see XUL, XBL), with severe backwards compatibility considerations (if you break existing websites or people's extensions, they might switch and not come back).
You suggest that NOT rewriting all of that in a couple of years is "hubris"?!? Rust 1.0 didn't happen until 2015 mind you, and Firefox OS was canceled in 2016. The timeline doesn't even make sense.
This kind of nonsense is why I can't take HN seriously when it comes to discussions about Mozilla. Criticisms are perfectly fine (and there are plenty of legitimate criticism to make) but people just abandon all logic when it comes to them for some reason and upvote mindless drivel because Mozilla Bad.
FYI, there are more than 6 million lines of Rust in Firefox, so it's not like it hasn't been happening.
Porting code from one language to another is much faster than writing it from scratch. I'm currently porting my own code from Python to C++ and it's a snap.
Mozilla could've chosen to port the C++ code to Rust, but they didn't because they had other "frivolous" priorities.
People seem to underestimate what a (even somewhat) large codebase entails. Even switching the compiler version is serious effort. Replacing the compiler can already be unfeasible, but apparently, switching the whole language seems to be super simple from the outside.
Simple it ain't, but it's certainly doable if you have hundreds of developers working on it. It will reduce maintenance further down the line especially as far as vulnerabilities are concerned.
Hundreds of developers? Have you ever written professional software? There is no way a coordinated effort across hundreds of engineers is going to be efficient enough to do a port like this. Also, with most legacy software you can't port modules to test if your port is working. It becomes, mostly, an all-or-nothing kind of thing and with 25 million lines of code that's going to take a huge amount of effort and time.
Yes, I've worked on software projects with large numbers of developers. And it's feasible if the work is split up in independent projects that only require the API to be agreed on.
Exactly the type of work seen in a web browser, which has many interconnected but independent parts.
I also believe that if you have enough unit test coverage you can tackle any project, no matter how large. This is, however, lacking in most projects. Many only pay lip service to unit testing.
Then maybe I should tell them what they shouldn't do: waste their money on management and other projects not directly related to improving the Firefox browser.
I'm surprised they didn't integrate their own internet search engine into Firefox. But the contract with Google probably prohibits it and Google would immediately pull the plug on Firefox if it got wind of it anyway.