3 ms·

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, c

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.

hinkley 7y ago
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.

hinkley 7y ago

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.