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.
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?