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).
Looking at their browser, I wouldn't.
> 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?
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).
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.
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 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++.
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.
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_...
- 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.)
The second is the claim I would dispute. The former may be true.
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.
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.
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.
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.
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.
By this measure, anything that is higher level than manually flipping bits in a binary is an inferior language.
If you combined it with a strong theorem proof language.
But then, that's a large part of what Rust is so . . .
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.