Live data from Hacker News

Mozilla Welcomes the Rust Foundation

blog.mozilla.org

51–60 of 184 posts

Re: Mozilla Welcomes the Rust Foundation

#51

Earlier quoted context omitted.

I started following it when he first started working on it back then, but I actually lost (some) interest once it became more about the memory safety features. It's not that I don't think the borrow checker etc. stuff is really awesome. I just find the original concept very appealing and incremental. Essentially an OCaml for systems level programming. A sane C++. I feel like Rust is making its moves slowly into that…

I'm just curious, feature-wise, what keeps OCaml from being an OCaml for systems level programming?

I'm sure for some uses it would be fine. But typically the concern is garbage collection. Manual memory allocation and the ability to deal directly with pointers etc. is important for driver and OS development, as well as embedded systems work.

Re: Mozilla Welcomes the Rust Foundation

#52
post #44
post #34

Earlier quoted context omitted.

The quote says that a parallel CSS engine in C++ was hard to get right in their case.

The post's claim is: > C++ simply wasn't usable for writing a parallel CSS engine. That's a stronger claim than that C++ was hard to get right. It's a claim that the language is not up to the task.

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!) pretty much requires a language in which iteration and refactoring can be done more quickly than in assembly.

Maybe the confusion on your part is that you think "CSS" is a static set of requirements, so if you put in enough effort to implement it once you're then done? Unfortunately, that's not how it works in practice.

Re: Mozilla Welcomes the Rust Foundation

#53

Isn’t a million dollar yearly budget really low considering how rich those companies are? That’s like 4 full time engineers. Not even a 5 a side football team.

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

With 401k, healthcare, I have heard that a million bucks gets you 3 engineers. Or in the case of layoffs you get a million dollars worth of savings per year per 3 engineers laid off.

Re: Mozilla Welcomes the Rust Foundation

#54

Isn’t a million dollar yearly budget really low considering how rich those companies are? That’s like 4 full time engineers. Not even a 5 a side football team.

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

> I've never known anyone (in coding) to be paid > £100k (~$140k) - but then maybe I move in the wrong circles!

In London, >£100k is easy for contractors but I think you'd have to have some managerial responsibilities to get that as a perm (team lead or upwards.) But I may also be moving in the wrong circles...

Re: Mozilla Welcomes the Rust Foundation

#55

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

They don't explicitly state that the rewrite is better? They just mention that they reduced the amount of code from 160,000 to 85,000 lines. Using competing teams for this purpose seems like a waste of money to me.

It could very much be from the second system effect though. A rewrite in C++ from a competing team would provide a control for that.

As many others have mentioned though, the real kicker is that they did attempt a rewrite twice in C++ aiming for the features of the rust one; those didn't work out.

Re: Mozilla Welcomes the Rust Foundation

#56

Earlier quoted context omitted.

I started following it when he first started working on it back then, but I actually lost (some) interest once it became more about the memory safety features. It's not that I don't think the borrow checker etc. stuff is really awesome. I just find the original concept very appealing and incremental. Essentially an OCaml for systems level programming. A sane C++. I feel like Rust is making its moves slowly into that…

I'm just curious, feature-wise, what keeps OCaml from being an OCaml for systems level programming?

OCaml is a GC language. It does have a fairly direct translation into assembly though, and is not a pure functional language.

Re: Mozilla Welcomes the Rust Foundation

#57
post #39

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 entirely a myth that unsafe is needed to get speed boosts in Rust. Usually, the standard library, as well as other crates, offer optimal performance without resorting to unsafe code. (If we go pedantic, Vec and other primitives do rely on unsafe, but the point is as an application developer you don't have to write unsafe code yourself.)

Unsafe rust exists for a reason. There are cases where perfectly safe code cannot be expressed according to Rust's ownership rules, and an escape hash is needed. Of course the "average" developer probably should not resort to unsafe as a rule of thumb.

Also regarding the standard library, as far as I understand it's not entirely true that it never resorts to unsafe rust. For example, I understand that the standard library makes use of specialization, which remains an unstable feature because of a soundness hole in the implementation.

Re: Mozilla Welcomes the Rust Foundation

#58

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

They tried to do it in C++ twice before the Rust. So what you’re asking for sorta kinda happened.

I didn't know that! Thanks for that context, it makes their claim far more interesting in my books.

Re: Mozilla Welcomes the Rust Foundation

#59

Earlier quoted context omitted.

I started following it when he first started working on it back then, but I actually lost (some) interest once it became more about the memory safety features. It's not that I don't think the borrow checker etc. stuff is really awesome. I just find the original concept very appealing and incremental. Essentially an OCaml for systems level programming. A sane C++. I feel like Rust is making its moves slowly into that…

I'm just curious, feature-wise, what keeps OCaml from being an OCaml for systems level programming?

The GC and the GIL.

Re: Mozilla Welcomes the Rust Foundation

#60
post #34

Earlier quoted context omitted.

The quote says that a parallel CSS engine in C++ was hard to get right in their case.

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.

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 shows that for the Firefox user base as of end of Jan 2021 54% of users had 2 cores and 34% had 4 cores.

Post reply on HN