Live data from Hacker News

Mozilla Welcomes the Rust Foundation

blog.mozilla.org

171–180 of 184 posts

Re: Mozilla Welcomes the Rust Foundation

#171

Earlier quoted context omitted.

So you are telling me that a parallel CSS engine can't be usable if written in C++ but large scale particle/molecule simulators, AAA game engines and other high-fidelity simulator environments are 100% C++ codebases?

Having worked in a AAA engine, with some of the things I saw done to make the performance tradeoffs I wouldn't want that code style anywhere near a security sensitive domain like the browser.

Wait until you see the things that are done in browsers to make them fast.

Re: Mozilla Welcomes the Rust Foundation

#172
post #86

Earlier quoted context omitted.

If you can stomach a GC enabled by default, a D is a good attempt at sane C++. The syntax is instantly familiar for a C++ programmer, and the templates are very similar to C++ (although saner).

I really feel like D is in a tough spot these days. In the early 2000 I remember being interested in it but I dismissed it because of the licensing issues that existed back then. Now it's sorted out but I think it crippled the language early on and now it's sandwiched between other "managed" languages with far better adoption and better support on one side (Java/JVM languages, C#, Go) and low level system language wi…

Rust hasn't had a much bigger adoption until a while ago. It had a better open source presence perhaps, but not necessarily adoption. It changed now obviously.

I guess the question is, does it really need to be mainstream to be usable? As long as it works for the usecases you need it for, popularity isn't a necessary factor.

I have to say though that D has some issues that prevent it's wider adoption, both historical and current. Some are obvious, such as unnecessary two standard libraries conflict (I missed out on it, but the OOP person in me would have preferred Tango over Phobos).

Re: Mozilla Welcomes the Rust Foundation

#173
post #119

Earlier quoted context omitted.

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 to…

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 the…

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

Re: Mozilla Welcomes the Rust Foundation

#174

Earlier quoted context omitted.

> Mozilla already tried re-writing the CSS engine in C++ before. They failed Blaming the tool for own failure to do the job isn't all that persuasive. > C++ simply wasn't usable for writing a parallel CSS engine. It might be not so much the proof of C++ deficiency as simply another manifestation of mismanagement of the browser development by Mozilla Foundation. > But Rust’s fearless concurrency has made parallelism p…

> Blaming the tool for own failure to do the job isn't all that persuasive. I would argue it is persuasive if switching to a new tool lead to success. What would be the point of continuing to try the thing that's not working?

However you might describe the present state of firefox, "success" is unlikely to be one of the adjectives.

Re: Mozilla Welcomes the Rust Foundation

#175
post #78
post #42

Earlier quoted context omitted.

> 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 t…

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 go…

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

Re: Mozilla Welcomes the Rust Foundation

#176

Earlier quoted context omitted.

> Mozilla already tried re-writing the CSS engine in C++ before. They failed Blaming the tool for own failure to do the job isn't all that persuasive. > C++ simply wasn't usable for writing a parallel CSS engine. It might be not so much the proof of C++ deficiency as simply another manifestation of mismanagement of the browser development by Mozilla Foundation. > But Rust’s fearless concurrency has made parallelism p…

https://en.wikipedia.org/wiki/Russell%27s_teapot

> Because nobody ever wrote concurrent systems in C++?

Re: Mozilla Welcomes the Rust Foundation

#177
post #173

Earlier quoted context omitted.

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 the…

> 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 imp…

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.

Re: Mozilla Welcomes the Rust Foundation

#178

Earlier quoted context omitted.

> Blaming the tool for own failure to do the job isn't all that persuasive. I would argue it is persuasive if switching to a new tool lead to success. What would be the point of continuing to try the thing that's not working?

However you might describe the present state of firefox, "success" is unlikely to be one of the adjectives.

Stylo is a technical success, regardless of how you feel about Firefox.

Re: Mozilla Welcomes the Rust Foundation

#179
post #118

Earlier quoted context omitted.

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

The n-body benchmark is slower due to a a bug in GCC's vectorization compared to Clang/LLVM.

Re: Mozilla Welcomes the Rust Foundation

#180
post #144
post #133

Earlier quoted context omitted.

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 a…

The fact that Mozilla used Rust for Stylo is not evidence that C++ is not usable to solve this problem.
Post reply on HN