Hacker News Reader

Comment by skohan | Hacker News Reader

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

View on HN

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

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

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

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

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.

Reply on news.ycombinator.com