151–160 of 184 posts
> Mozilla used Rust to build Stylo, the CSS engine in Firefox (replacing approximately 160,000 lines of C++ with 85,000 lines of Rust). I would have loved to see two competing teams rewrite it, one in C++ and the other in Rust. Saying that the rewrite is better does nothing to say WHY it's better. Refactored code is almost always radically better, even when it's in the same language, for reasons that might be insulti…
> Mozilla used Rust to build Stylo, the CSS engine in Firefox (replacing approximately 160,000 lines of C++ with 85,000 lines of Rust). I would have loved to see two competing teams rewrite it, one in C++ and the other in Rust. Saying that the rewrite is better does nothing to say WHY it's better. Refactored code is almost always radically better, even when it's in the same language, for reasons that might be insulti…
> Refactored code is almost always radically better Sometimes it is, but it is hardly the rule. New issues will always be introduced. Also, some developers get into an endless cycle of unnecessary refactoring just to use the latest and greatest of some library or framework for no real technical reason.
I see the Rust Foundation being more important than the Mozilla Foundation in 5-10 years.
John Carmack @ID_AA_Carmack
https://twitter.com/id_aa_carmack/status/1293227109738061826...
Earlier quoted context omitted.
> Also regarding the standard library, as far as I understand it's not entirely true that it never resorts to unsafe rust. I think you're misunderstanding the parent comment. The stdlib constantly resorts to unsafe code. Tons of methods like `split_at_mut` and `make_ascii_uppercase` are just safe wrappers around an unsafe one-liner. Rather, the observation is that _with the benefit of the stdlib and common crates_, m…
I agree that most developers don't need to bother with unsafe code, and will not pay a performance penalty for staying within safe rust. My only point is that it's not necessary to be so dogmatic as to say that no-one should ever write a line of unsafe rust. For instance, if you read the rust book, they make references to times you might want to use unsafe: > Borrowing different parts of a slice is fundamentally okay…
Earlier quoted context omitted.
> 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
Earlier quoted context omitted.
For that last one: it's much faster in many cases, because Chrome's engine is not parallelized. Back when I was last measuring this, stylo's single-thread performance was comparable to Chrome's or a bit faster in some cases. Parallelized performance was much better. That said, actual hardware in the wild has a surprisingly low level of hardware parallelism in practice. https://data.firefox.com/dashboard/hardware show…
I remember reading that Chromium's engine is slower sometimes because it follows the standard more strictly. https://codeberg.org/teddit/teddit/issues/24#issuecomment-16...
The link you posted just indicates that Firefox rendered the page faster than Chrome; did it render it _wrong_?
One other note: the linked issue here is layout, not the CSS system per se; this part is not parallelized in Gecko and is still in C++, not in Rust.
Earlier quoted context omitted.
For that last one: it's much faster in many cases, because Chrome's engine is not parallelized. Back when I was last measuring this, stylo's single-thread performance was comparable to Chrome's or a bit faster in some cases. Parallelized performance was much better. That said, actual hardware in the wild has a surprisingly low level of hardware parallelism in practice. https://data.firefox.com/dashboard/hardware show…
> That said, actual hardware in the wild has a surprisingly low level of hardware parallelism in practice. https://data.firefox.com/dashboard/hardware shows that for the Firefox user base as of end of Jan 2021 54% of users had 2 cores and 34% had 4 cores. True, but that's probably about to change soon. Look at the ARM stuff about to enter the arena. I wouldn't bet on us using just 2-4 cores 10 years from now. And we…
Earlier quoted context omitted.
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". I mean, you can implement anything you want in assembly, in theory. In practice, the cost of iteration tends to be high enough that implementing things with somewhat rapidly changing requirements (which includes CSS, to be clear!) prett…
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…
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?
Earlier quoted context omitted.
> That said, actual hardware in the wild has a surprisingly low level of hardware parallelism in practice. https://data.firefox.com/dashboard/hardware shows that for the Firefox user base as of end of Jan 2021 54% of users had 2 cores and 34% had 4 cores. True, but that's probably about to change soon. Look at the ARM stuff about to enter the arena. I wouldn't bet on us using just 2-4 cores 10 years from now. And we…
Well, right, that's why the Firefox CSS implementation actually aims to be parallelized and has been for years. I'm just saying that the wins from that on current hardware are not as large as one would hope. And that the increase in number of cores has not been increasing nearly as fast as one would like, in devices that most people actually own.
Because software doesn't really need many cores, no need to create CPUs with many, many cores.
I imagine the cycle's going to break at some point, after all we can only ignore having many cores for so long. Especially that now even mobile devices routinely have at least 4 cores.
Earlier quoted context omitted.
I guess that depends on where the engineers are, and how much they are paid - I've never known anyone (in coding) to be paid > £100k (~$140k) - but then maybe I move in the wrong circles! So you could certainly get more than 4 engineers on board, plus some project managers etc
The UK is, from what I've seen, a really low-paying market for IT and software engineering. At the big FAANG companies, you can make more than that as a new graduate (pre-tax, cash compensation only). I don't like generalizing on the FAANGs, because they are not the majority of the market, but even outside of NYC/Silicon Valley, developers can clear $140k after a few years of experience.
Healthcare, vacation time and better work/life compensate that ( for some).