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.