Mozilla already tried re-writing the CSS engine in C++ before. They failed. C++ simply wasn't usable for writing a parallel CSS engine.

"This top-down structure is ripe for parallelism; however, since styling is a complex process, it’s hard to get right. Mozilla made two previous attempts to parallelize its style system in C++, and both of them failed. But Rust’s fearless concurrency has made parallelism practical!"

https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-I...

This blog from Mozilla [1] explains why rendering CSS is such a complex process.

[1] https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en...

Thanks for sharing, even though it's from 2017 it was an interesting read.

2017 is when Stylo first shipped by default in Firefox. It's not like everything has rotted since then!

On the contrary, probably very few things changed since in Stylo.

It it could be written in rust then it could absolutely be rewritten in C++ as well, especially if it was already written in C. That said I find doing concurrent/async programming much more enjoyable/quicker in rust. Too bad it's not as widespread as c++.

> They failed. C++ simply wasn't usable for writing a parallel CSS engine.

WebKit has CSS engine is written in C++. Chromium has one too.

It’s not currently parallel though, right? That part is critical to the point being made.

After all, Gecko had a C++ implementation too. Nobody is suggesting that any implementation is literally impossible.

And Firefox had one too. But it wasn't parallel. That's what is being discussed here.

So you are telling me that a parallel CSS engine can't be usable if written in C++ but large scale particle/molecule simulators, AAA game engines and other high-fidelity simulator environments are 100% C++ codebases?

Having worked in a AAA engine, with some of the things I saw done to make the performance tradeoffs I wouldn't want that code style anywhere near a security sensitive domain like the browser.

Wait until you see the things that are done in browsers to make them fast.

Typically simulators don't benefit much from extremely fine-grained parallelism; while you likely can simulate each entities behavior in parallel, and then step the world, you don't have fine-grained dependencies within one step (and likely many entities computations have predictable and balanced computational costs, further simplifying parallelism). AAA games were certainly until recently renowned for their poor usage of parallelism, though perhaps there are exceptions - but remember, large scale data-parallelism akin to simulations isn't the problem; it's problematic once there are dependency cycles and/or parallelism needs to be particularly fine-grained.

Finally, many games and simulators are written in clearly, clearly sub-"optimal" fashion. Games are about fun; not necessarily about extracting maximal possible performance - and compared to browsers, even to minor players like Firefox, even large games have limited usage and especially limited lifetime usage, and they're likely less sensitive to security issues too. As a result, when a game's usage of of parallelism has a few very unlikely race conditions that might not be a show-stopper - whereas it could be an exploitable flaw in browsers.

All in all, it's extremely plausible that games+sims aren't quite as dramatically impacted by C++'s risks as a browser's styling engine is. It's perhaps no coincidence that the language was pretty much designed for it.

The quote says that a parallel CSS engine in C++ was hard to get right in their case.

The post's claim is:

> C++ simply wasn't usable for writing a parallel CSS engine.

That's a stronger claim than that C++ was hard to get right. It's a claim that the language is not up to the task.

When the time cost of getting it right and _keeping_ it right exceeds the amount of time actually available in a day, the result is equivalent to "the language is not up to the task".

I mean, you can implement anything you want in assembly, in theory. In practice, the cost of iteration tends to be high enough that implementing things with somewhat rapidly changing requirements (which includes CSS, to be clear!) pretty much requires a language in which iteration and refactoring can be done more quickly than in assembly.

Maybe the confusion on your part is that you think "CSS" is a static set of requirements, so if you put in enough effort to implement it once you're then done? Unfortunately, that's not how it works in practice.

The fact that we disagree does not imply "confusion on my part".

> When the time cost of getting it right and _keeping_ it right exceeds the amount of time actually available in a day, the result is equivalent to "the language is not up to the task".

Again, this is referring to the particular approach that the Mozilla team took to the problem. If anything, one of the most valid criticisms of C++ is that the API is too large, and it has too many tools to work with at the expense of clarity. C++ allows you to express just about anything, and I do not think the standard of evidence has been met that the problem of writing a CSS engine could not be expressed in C++ in a way which would be both performant and maintainable.

C++ has been used for many complex, high-profile projects which are widely used. There is nothing magical about CSS which creates problems C++ is incapable of solving.

In the limit, you could implement a DSL in C++ that would allow you to implement CSS.

Or you could implement Rust in C++.

As you say, you can do whatever you want in C++. The only question is how much time and effort it would take and whether it's worth it.

I will note that the people who worked on the Firefox style system had plenty of experience working on complex, high-profile C++ projects. Every single one of them that I've talked to agreed that for the specific thing they were doing here Rust allowed much faster development of code with fewer bugs (especially as measured by how many issues the fuzzers found) than their past experience with C++ had been.

If your point is that the claim should be "parallelizing the style system in C++ was impossible within the schedule and manpower constraints Firefox was operating under" rather than the simpler "was impossible" claim, then sure, as a purely logical-statement matter. But in practice there are always schedule and manpower constraints.

Can I prove mathematically that some other team would not have been able to achieve the same results in the same amount of time with C++? No, I can't; such a proof would be quite difficult to construct. I do have the empirical observation that there used to be at least four fairly different modern non-parallel CSS implementations out there written in C++ (Gecko, WebKit, Blink, Edge), and that one of them has disappeared (Edge), one was parallelized in Rust, and the remaining two remain in C++ and non-parallel, even though people generally agree that parallelizing them would be good and so forth.

Maybe it's just that none of the organizations involved are any good at writing C++ code. Maybe it's that doing this in C++ is hard enough that it's not worth the effort. Maybe it's something else. What is your hypothesis on the matter?

> parallelizing the style system in C++ was impossible within the schedule and manpower constraints Firefox was operating under

So my main issue with this claim is that we are talking about proving the negative. Not to get too pedantic, but the reasoning seems to be:

1. Mozilla tried and failed to build a parallel CSS engine in C++

2. Mozilla succeeded in building a parallel CSS engine in Rust

3. Therefore, it is impossible to implement a parallel CSS engine in C++ (under the constraints Mozilla was under).

This is simply not a valid argument. Evidence that something did not happen is not proof that it could not happen.

There are plenty of claims I would accept:

- The Mozilla team found Rust much better than C++ for solving their problem

- Many of the problems the team was running into with C++ were completely eliminated by the constraints provided by Rust

But saying this problem is impossible to solve in C++ is an extraordinary claim which needs extraordinary evidence. C++ is an extremely flexible and powerful language, to say that no one could ever design a solution to this problem using C++ requires a very limited imagination.

> there used to be at least four fairly different modern non-parallel CSS implementations out there written in C++ (Gecko, WebKit, Blink, Edge), and that one of them has disappeared (Edge), one was parallelized in Rust, and the remaining two remain in C++ and non-parallel, even though people generally agree that parallelizing them would be good and so forth.

This is a very small sample size. If I have to give a hypothesis, I can imagine that having a very large, very mature code base like Firefox would have placed a lot of design constraints on any rewrite of the CSS engine. I can imagine that working within this framework, there may have been many problems related to concurrency and data ownership which ended up eating a lot of time and energy in C++, and the team saw a huge productivity boost categorically eliminating these problems. But I simply do not believe it's the case that it's not possible to decompose the problems a CSS engine has to solve into a set of concurrent data structures and operations, which could be expressible in either Rust or C++.

That's all fair, and your hypothesis is pretty much spot-on in terms of what happened. The huge productivity boost was basically key to the success of the project.

I'm not sure whether the argument now comes down to "it would have been possible to gain that sort of productivity boost in C++ too, with the right design" or "it would have been possible to implement a new CSS engine without this sort of productivity boost". If it's the former, then you're right that one can't prove a negative. If it's the latter, then I think that's where the "schedule and manpower constraints" come in.

If the tool exceeds human ability in practice, then yes.

I mean, we can blame the humans all we want, but that won't take us anywhere.

Look at what happened to airplane safety and car safety when we stopped blaming the pilot/driver. Fatalities plummeted.

Parallelism is hard in both Rust and C++. When I think about low level parallelism, like in the case of rendering, I believe that Safe Rust will only get you so far perfomance-wise. To get the best speed you will still need unsafe. I'm wondering how their engine fares compared to Chrome.

It's entirely a myth that unsafe is needed to get speed boosts in Rust. Usually, the standard library, as well as other crates, offer optimal performance without resorting to unsafe code.

(If we go pedantic, Vec and other primitives do rely on unsafe, but the point is as an application developer you don't have to write unsafe code yourself.)

It's not entirely a myth. There are situations where you can't get the compiler to emit optimal code using only safe Rust. You can go a very long way with only safe Rust (and i do!), but not everywhere.

There are also situations where you cannot get a C++ compiler to emit optimal code without resorting to intrinsics or inline Assembly. 99% of Rust and C++ code performs well without going that deep.

Unsafe rust exists for a reason. There are cases where perfectly safe code cannot be expressed according to Rust's ownership rules, and an escape hash is needed. Of course the "average" developer probably should not resort to unsafe as a rule of thumb.

Also regarding the standard library, as far as I understand it's not entirely true that it never resorts to unsafe rust. For example, I understand that the standard library makes use of specialization, which remains an unstable feature because of a soundness hole in the implementation.

> Also regarding the standard library, as far as I understand it's not entirely true that it never resorts to unsafe rust.

I think you're misunderstanding the parent comment. The stdlib constantly resorts to unsafe code. Tons of methods like `split_at_mut` and `make_ascii_uppercase` are just safe wrappers around an unsafe one-liner.

Rather, the observation is that _with the benefit of the stdlib and common crates_, most programs have no performance reason to reach for unsafe in regular code. That's true in my experience.

I agree that most developers don't need to bother with unsafe code, and will not pay a performance penalty for staying within safe rust. My only point is that it's not necessary to be so dogmatic as to say that no-one should ever write a line of unsafe rust.

For instance, if you read the rust book, they make references to times you might want to use unsafe:

> Borrowing different parts of a slice is fundamentally okay because the two slices aren’t overlapping, but Rust isn’t smart enough to know this. When we know code is okay, but Rust doesn’t, it’s time to reach for unsafe code.

Agreed. My guess is that folks tend to talk past each other on these questions, and that the important details aren't really controversial.

In my experience most of the time I had to use unsafe was to bind unsafe interface (think something like making raw OpenGL bindings for instance, you'll have unsafe code all over the place and you'll have write your own safe wrappers around it). Performance-wise I very rarely find myself having to compromise, although there are times where I have to write "smarter", more complicated code to get good performance without unsafe.

I just looked at the code of a pretty heavily optimized program I've been working on for a few months, I have exactly one instance of unsafe in the code:

   pub const GPIO_ID: StreamId = StreamId(unsafe { NonZeroU16::new_unchecked(0xf610) });

I need the unsafe because at the moment the language is not smart enough to understand that 0xf610 is obviously non-zero and that I can build a NonZeroU16 from it without fail (at least I don't know how to express this in static expression at the moment). This has no performance implications whatsoever.

For that last one: it's much faster in many cases, because Chrome's engine is not parallelized.

Back when I was last measuring this, stylo's single-thread performance was comparable to Chrome's or a bit faster in some cases. Parallelized performance was much better.

That said, actual hardware in the wild has a surprisingly low level of hardware parallelism in practice. https://data.firefox.com/dashboard/hardware shows that for the Firefox user base as of end of Jan 2021 54% of users had 2 cores and 34% had 4 cores.

> That said, actual hardware in the wild has a surprisingly low level of hardware parallelism in practice. https://data.firefox.com/dashboard/hardware shows that for the Firefox user base as of end of Jan 2021 54% of users had 2 cores and 34% had 4 cores.

True, but that's probably about to change soon. Look at the ARM stuff about to enter the arena.

I wouldn't bet on us using just 2-4 cores 10 years from now. And we need to plan for that.

Well, right, that's why the Firefox CSS implementation actually aims to be parallelized and has been for years. I'm just saying that the wins from that on current hardware are not as large as one would hope. And that the increase in number of cores has not been increasing nearly as fast as one would like, in devices that most people actually own.

Yeah, it's a chicken and egg problem. Old software doesn't use many cores, and even new, single threaded one doesn't (Javascript, Python, Ruby, etc.).

Because software doesn't really need many cores, no need to create CPUs with many, many cores.

I imagine the cycle's going to break at some point, after all we can only ignore having many cores for so long. Especially that now even mobile devices routinely have at least 4 cores.

Mobile devices in the field typically have _more_ cores that desktop devices. The Firefox hardware report is strongly influenced by there being a lot more desktop than mobile Firefox users.

As you note, the modal number of cores on mobile has been 4-6 for a while now.

I remember reading that Chromium's engine is slower sometimes because it follows the standard more strictly. https://codeberg.org/teddit/teddit/issues/24#issuecomment-16...

Fwiw, I've seen a number of cases of the other way around: the WebKit/Chrome CSS implementation had some shortcuts for performance reasons that caused them to not follow the spec, where Firefox did.

The link you posted just indicates that Firefox rendered the page faster than Chrome; did it render it _wrong_?

One other note: the linked issue here is layout, not the CSS system per se; this part is not parallelized in Gecko and is still in C++, not in Rust.

It's not really scientific but if you look at the language benchmark game Rust is generally toe-to-toe with C++ without requiring any unsafe code.

Here's a random example: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Rust is pretty damn close to the fastest C++ version without any unsafe (but using a bunch of generic libraries which may have unsafe code, to be perfectly fair).

Note that the winning C++ entry is also vastly more complex code and I wouldn't want to have to maintain that.

The n-body benchmark is even more in Rust's favour: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Here Rust wins the benchmark without unsafe or non-std dependencies. I also find the code very readable and natural looking.

Disclaimer: I love Rust so much that I wish that I could marry it, I'm obviously thoroughly biased.

The n-body benchmark is slower due to a a bug in GCC's vectorization compared to Clang/LLVM.

You do not need to write unsafe code yourself in order to parallelize Rust code.

Nobody cares if any of those are exploitable, but browsers are literally the os for a lot of people and needs to be secure.

In my experience all of those simulators and game engines have really egregious bugs that go undetected. C++ is fine if you don't need correctness (which is actually most of the time, in practice).

AAA game engines don’t need to securely execute arbitrary malicious code downloaded from the internet.

AAA games usually have the shoddiest code.

> C++ simply wasn't usable for writing a parallel CSS engine.

I think it can be said that Mozilla was able to use Rust to achieve what they failed to with achieve with C++. It's not justified to claim that C++ is/was not suitable for this purpose.

C++ offers direct, low-level control over memory, and C++ can be used to implement anything which can be implemented in Rust. Maybe Rust has certain advantages which made this problem a lot easier to solve for Mozilla, and I'm certainly happy to have Rust in the language landscape, but another team with other processes may have been able to use C++ to achieve similar goals.

One thing that software developers frequently forget to do is to be humble.

It is entirely possible that the best developers on this planet using the best tools and methodologies, processes, whatever, are just not smart enough to do some things.

Considering how many things we have achieved, we should just acknowledged this human attribute: imperfection.

If our tools require us to be perfect, maybe they're just not good tools for some goals.

I'd be shocked if Mozilla didn't have some of the best C++ programmers on the planet, and if they failed a few times, that's a pretty strong argument against C++.

Who knows, maybe they'll be proven wrong and another team working purely in C++ will achieve goals such as theirs. I wouldn't bet on it (though C++ is evolving so who knows how C++ will look like in 20-30 years, never say never).

> I'd be shocked if Mozilla didn't have some of the best C++ programmers on the planet,

Looking at their browser, I wouldn't.

> If our tools require us to be perfect, maybe they're just not good tools for some goals.

> if they failed a few times, that's a pretty strong argument against C++.

Well, they're migrating (at least part of) the codebase to Rust, in a lot of places because of security. Make your own conclusion, I guess?

The claim was that it couldn't be done, as in not possible. Not that it's not a lot easier because of ground up design for concurrency in rust, maybe even an order or two of magnitude easier. However to claim it can't be done in C++ at all is silly. To claim it couldn't be done by the team working on it with the given time frame and resources is a legit claim however.

> C++ offers direct, low-level control over memory, and C++ can be used to implement anything which can be implemented in Rust. Maybe Rust has certain advantages which made this problem a lot easier to solve for Mozilla, and I'm certainly happy to have Rust in the language landscape, but another team with other processes may have been able to use C++ to achieve similar goals.

You could say the same thing about assembly programming or some language that uses GOTOs instead of structured control constructs ... or Brainfuck. Given infinite time and resources, you can implement anything in any language.

Claims about this or that language being unsuitable for a problem aren't really about stuff like Turing completeness, it's more about practical software engineering problems (e.g. does the language provide the right kind of support to the developers allow them to implement the required functionality in a reasonable amount of time with a reasonably small amount of bugs with the budget available).

> You could say the same thing about assembly programming or some language that uses GOTOs instead of structured control constructs ... or Brainfuck.

I think this a reduction of the argument to the point of absurdity. C++ and Rust are certainly much more similar in terms of form and capability than C++ and brainfuck.

> Claims about this or that language being unsuitable for a problem aren't really about stuff like Turing completeness, it's more about practical software engineering problems (e.g. does the language provide the right kind of support to the developers allow them to implement the required functionality in a reasonable amount of time with a reasonably small amount of bugs with the budget available).

I agree. C++ may very well have been unsuitable for Mozilla at the time they adopted Rust. What I take issue with is the general claim that C++ is not suitable for a parallel CSS engine at all. This is a very strong claim, and I do not believe one team coming to this conclusion for them is enough evidence to conclude this in general.

> C++ and Rust are certainly much more similar in terms of form and capability than C++ and brainfuck.

From the point of view of somebody creating a highly interdependent parallel system, no, it's the other way around. On the features that matter to parallel systems, C++ is much closer to brainfuck than it's to Rust.

> I agree. C++ may very well have been unsuitable for Mozilla at the time they adopted Rust. What I take issue with is the general claim that C++ is not suitable for a parallel CSS engine at all. This is a very strong claim, and I do not believe one team coming to this conclusion for them is enough evidence to conclude this in general.

I know very little about rust, so take this with a grain of salt. It's possible that writing the CSS engine in C++ would require too many custom classes, containers, and build tools outside of the STL than equivalent code in Rust. For example, fast mutexes and mutex safety are not a standard part of C++ but vital to fast parallel C++ code, and the semantics of mutexes are thus very hard to get right. Static checkers for specific mutex implementations can decrease the risk of deadlocks and races but these are additions to C++. If rust provides primitive mutexes with static checking for correctness or other language features (maybe refcell or similar) then it might be worth using rust to stay within the standard language features instead of building add-ons for C++.

A steak knife makes a poor scalpel but with enough effort you could probably perform a kidney transplant with one. It would just take 5 times at long and the patient would be at serious risk of bleeding out the entire time.

You could in theory write the CSS engine in assembly too. A theoretical team, somewhere, could probably manage it. But given better options, it is not a reasonable thing to do.

You mean Mozilla, the organization that has maintained a 6 million LOC[1] C++ codebase continuously for nearly 20 years?

If they can't pull it off with C++, I don't care who can, C++ is not the right tool for the job and you can file writing such a thing in it as an esoteric programming challenge, together with template Tetris.

1. https://www.openhub.net/p/firefox/analyses/latest/languages_...

What language is the CSS engine used by Chrome or Safari written in?

Two points:

- how does the performance of those fare against Stylo?

- the developer of Chrome is so insanely rich that only a tiny tiny fraction of their budgets in practice finance all of Firefox.

Summary: Mozilla manages to make an equally good or better CSS engine with a lower budget?

(I admit Google might be running the Chrome team on a shoestring but my bet is they don't as coming in a position were they can kill ad blocking really would be a fantastic strategic advantage for them and would be worth billions a year.)

Saying Rust allowed Mozilla to achieve a better result for less money is a much softer claim than saying C++ is an unsuitable language choice for this problem, which is what I was responding to.

The second is the claim I would dispute. The former may be true.

You are absolutely welcome to dispute it, but the fact of the matter is that an engineering team with the expertise, history and resources to write at least two iterations of a CSS processor did their homework and chose to rewrite it in Rust, realizing significant performance gains across a smaller code-base. The advantage to that team being Mozilla is that alot of the discussions that lead to these implementations are captured in meeting documents, bugzilla tickets, other places, like this blog post explaining why and how they got the gains they did: https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en...

If you want to dispute the claims, do the research, otherwise it's just your opinion against the actual implementation that is shipping to millions of devices.

The fact that Mozilla used Rust for Stylo is not evidence that C++ is not usable to solve this problem.

If you give a C++ programmer infinite tape they will be able to write this program in finite time, is that all you're saying?

No, I am saying there is nothing intrinsic to the problem of a CSS engine that makes it intractable in C++. C++ is the most used language for highly parallel, HPC applications. I don't see why there is anything magical about CSS which would prevent a c++ solution from also existing here.

I'm not arguing that Rust was not the best choice here for Mozilla. I personally would also rather work with Rust than C++ in almost all cases. But to claim that C++ is not usable to solve this problem, based on the fact that Mozilla decided to use Rust instead is not a sound argument.

Yes, but that reads like a put down for Mozilla. That hypothetically a team of guys earning like half a million a year in a big hedge fund could be recruited to build precisely a parallel CSS engine if they work in it for a year or two is not a good argument for using C++ for this either.

It's not a put-down to Mozilla at all. I'm sure they chose Rust for very good reasons, and they achieved a great result. I'm not even arguing that C++ should be used for this. I'm just saying it's absurd to claim that C++ could not be used for this if you really wanted to.

Is it a parallel CSS engine like Stylo?

I agree that the claim made by the parent might have been a bit too strong and not backed by enough evidence, but saying that C++ can technically do the same thing as Rust is not really getting us anywhere. You can say the same thing for ASM.

Can, in practice, a team write and maintain a modern CSS engine in pure assembly? In theory yes, in practice I expect the overhead to be massive.

I think the key feature of Rust for such an application is "fearless concurrency". Writing concurrent code in C or C++ feels like walking a tightrope, in Rust I know that I can lean on the compiler to tell me when I'm doing something wrong. Sure, you can still have data races, but in my experience they're generally pretty simple to debug when they happen because the type system and borrow checker force you to have very explicit data dependency graphs.

I avoid threads like the plague in C and C++, but in Rust I never hesitate if I feel like spawning a worker might improve performance or make the overall architecture simpler.

C offers direct, low-level control over memory, and C can be used to implement anything which can be implemented in C++. Maybe C++ has certain advantages which made this problem a lot easier to solve for Mozilla, and I'm certainly happy to have C++ in the language landscape, but another team with other processes may have been able to use C to achieve similar goals.

Assembly offers direct, low-level control over memory, and assembly can be used to implement anything which can be implemented in C++. Maybe C++ has certain advantages which made this problem a lot easier to solve for Mozilla, and I'm certainly happy to have C++ in the language landscape, but another team with other processes may have been able to use assembly to achieve similar goals.

The biggest advantage of Rust is that the liner types and the borrow checker forces one to structure the application in a way that is much more manageable long-term and less error-prone even with occasional sprinkle of unsafe code.

Surely one can code in such style in C++, but it is very unnatural there with a lot of boilerplate, so one just would not consider it typically.

You mean "affine types". Linear types are required to be used while Rust allows one to manually drop a type. This allows you to get the next state and do nothing with it while a linear type would compel you to move to the next state.

Yes, I meant affine types.

> C++ offers direct, low-level control over memory, and C++ can be used to implement anything which can be implemented in Rust.

By this measure, anything that is higher level than manually flipping bits in a binary is an inferior language.

Finally! The one person who understands why I still enter bytes manually via switches on my Altair! /s

Quality-minded as we are we faithfully transcribe coin flips until the tests are passing!

I did not claim that C++ is a superior language.

Assembly offers direct, low-level control over memory, and assembly can be used to implement anything which can be implemented in C++. Maybe C++ has certain advantages which made this problem a lot easier to solve for Mozilla, and I'm certainly happy to have C++ in the language landscape, but another team with other processes may have been able to use assembly to achieve similar goals.

I am certain you are right and C++ could be used.

If you combined it with a strong theorem proof language.

But then, that's a large part of what Rust is so . . .

Any language can be used to implement a program written in any other language, and there is a simple proof for that - every program is a finite automaton and every finite automaton can be implemented using while and switch constructs.

In this case possibly the best use of C++ was to write the LLVM compiler which could then be used to implement a DSL (Rust) that is better suited to the problem at hand.

> Mozilla already tried re-writing the CSS engine in C++ before. They failed

Blaming the tool for own failure to do the job isn't all that persuasive.

> C++ simply wasn't usable for writing a parallel CSS engine.

It might be not so much the proof of C++ deficiency as simply another manifestation of mismanagement of the browser development by Mozilla Foundation.

> But Rust’s fearless concurrency has made parallelism practical!"

Because nobody ever wrote concurrent systems in C++?

> Because nobody ever wrote concurrent systems in C++?

> Blaming the tool for own failure to do the job isn't all that persuasive.

I would argue it is persuasive if switching to a new tool lead to success. What would be the point of continuing to try the thing that's not working?

However you might describe the present state of firefox, "success" is unlikely to be one of the adjectives.

Stylo is a technical success, regardless of how you feel about Firefox.

They tried to do it in C++ twice before the Rust. So what you’re asking for sorta kinda happened.

I didn't know that! Thanks for that context, it makes their claim far more interesting in my books.

Making two teams compete like that is a horrible idea. Both teams know that no matter how hard they work, their work may be thrown away. I've heard horror stories like this in a post mortem about the development of Sonic 3D for Saturn back then for example. There were two teams tasked with making a sequel, and only the better one would be released. Management's idea was that it was supposed to be a flagship title and had to be good. Both teams worked themselves to exhaustion and almost everyone quit the company, the rest got fired due to failure.

Even if the above doesn't happen, it is hard to say what you learn from two teams. Maybe one team is worse. Maybe one team got lucky because the serious bug was 1 in a million and not found, while the other spent weeks tracking down a similar level of complexity bug that happened every time and so had to be fixed... I can come up with more.

The only thing fair is to give one team 6 months (ideally with a couple contractors who are experts to teach them best practices) to try the new thing. Less than 6 months and they are not far enough along the learning curve to make any useful statements. If you want a work done comparison you need to give half your teams (minimum 20 teams, ask a statistician for more details if you want to go lower or could go higher) that 6 months, and then after that give them a year to use the new one in real work, and compare that final year.

Totally fair @eska and @bluGill. I really wasn't thinking in terms of "This is the right way to manage a project." I was simply trying to identify some way to do a better and more accurate comparison between Rust and C++.

You're perfectly right that it would be awful to be pitched against each other in this way.

So I recant my suggestion, but maintain my critique about using lines of code in a single project as somehow validating a language choice. There are too many variables. And, more to the point, the refactored code will almost always be much better, regardless of the language selected.

Deathmatch programming doesn't sound very pleasant.

But I hope most people here don't feel a morale hit when their code gets tossed. Inherently, I understand the desire for one's creative work to live on, but that's essentially incompatible with this industry. And I also have found much joy in turning-down/deleting existing services I've written. My team celebrates these events and it's always fun to give that high-maintenance service a viking funeral.

They don't explicitly state that the rewrite is better? They just mention that they reduced the amount of code from 160,000 to 85,000 lines.

Using competing teams for this purpose seems like a waste of money to me.

It could very much be from the second system effect though. A rewrite in C++ from a competing team would provide a control for that.

As many others have mentioned though, the real kicker is that they did attempt a rewrite twice in C++ aiming for the features of the rust one; those didn't work out.

> Using competing teams for this purpose seems like a waste of money to me.

You're not wrong! My point was more that we can't take this single data point as proof of Rust's superiority.

> Using competing teams for this purpose seems like a waste of money to me.

That's not how it was done.

You're making some big assumptions here and I don't think you even realise it.

> Refactored code is almost always radically better

Sometimes it is, but it is hardly the rule. New issues will always be introduced. Also, some developers get into an endless cycle of unnecessary refactoring just to use the latest and greatest of some library or framework for no real technical reason.

I'm not saying refactoring is always worthwhile (it usually isn't, in my experience anyway).

But the refactor is generally done with the benefit of hindsight of all the things you would have done differently if only you'd known then what you know now.

It's like saying that the second draft or edited manuscript of a novel isn't going to be better than the initial draft. Of course it's better the second time. In theory, you fixed what was wrong with the first one and implemented new and/or improved ideas.

If your refactored code is worse than the original, I feel like you're doing something wrong.

Refactoring can also leave the code better off while simultaneously leaving the business much worse off. Just ask Netscape.

Is there a comparison of Stylo to the Chromium/Blink equivalent somewhere? Performance, complexity, etc?

Have there been security issues in Stylo?

Actually that's a really good question :) . I would be interested if Rust's vaunted security advantages panned out. I know anything can have bugs but still it would be interesting.