The fact that Mozilla can not do a particular thing in particular way has zero value for others not in the same boat. I am not Mozilla. Do not know their problems and do not care. Maybe parallel CSS is too complex by nature. I can only relate to my own situation. My commercially deployed systems work and serve bazillion of clients with no problems.
I've also written systems in Rust, some embarrassingly parallel and some that are more complex than that. The embarrassingly parallel ones never took more than 10 minutes of effort to do. The more complex ones are harder but still possible.
I agree that your data point should also be assigned non-zero weight.
It is well above zero. But this is for very specific situation - parallel CSS.
I on the other hand had never had problem managing / mutating state in my multithreaded programs. I did have one situation with deadlock when interacting with Directshow signal processing. That was around 2002 I think. Took me one day to analyze and fix the code after the bug was reported. But Directshow is an incredibly complex piece with some weird behaviors. Other then that I do not recall any real problems. Btw that particular software was desktop application and written in Delphi, not even C++.
So yes to me the opinion of Mozilla's team is totally irrelevant. It is of course totally mutual but I suspect that my situation - C++ application servers is way more common than parallel CSS.
> Multithreading is just as "relatively" easy in other compiled languages.
Maybe that is true for your case, but broadly speaking it isn't true.
The quality of the tools one uses matters a lot.
https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-I...