Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla Welcomes the Rust Foundation

blog.mozilla.org

Post reply on HN
Print view View original

81–90 of 184 posts

Re: Mozilla Welcomes the Rust Foundation

#81

Post by oblio »

skohan wrote: post #44
dmos62 wrote: 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.

If the tool exceeds human ability in practice, then yes.

I mean, we can blame the humans all we want, but that won't take us anywhere.

Look at what happened to airplane safety and car safety when we stopped blaming the pilot/driver. Fatalities plummeted.

Re: Mozilla Welcomes the Rust Foundation

#82

Post by oblio »

bzbarsky wrote: post #60
johnnycerberus wrote: post #37

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.

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 need to plan for that.

Re: Mozilla Welcomes the Rust Foundation

#83

Post by oblio »

xpe wrote: post #47
btown wrote: post #25

Earlier quoted context omitted.

A brief reminder that Mozilla paid its top executive, Mitchell Baker, $2.4m in 2018. http://calpaterson.com/mozilla.html

This also exists in the broader context of tremendous growth in CEO pay over recent decades. There are widespread claims that executive pay is inflated. In one sentence: > Importantly, rising CEO pay does not reflect rising value of skills, but rather CEOs’ use of their power to set their own pay. Source: https://www.epi.org/publication/ceo-compensation-2018/ I find these arguments persuasive.

That happens every time this is allowed. I can't remember the last time our Parliament voted to reduce their own salaries :-))

Re: Mozilla Welcomes the Rust Foundation

#84

Post by oblio »

bennyp101 wrote: post #41
justsomeuser wrote: post #31

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

If you're in a big Western city or can relocate, you can definitely find better circles ;-)

Re: Mozilla Welcomes the Rust Foundation

#85

Post by oconnor663 »

skohan wrote: post #57
mdup wrote: post #39

Earlier quoted context omitted.

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

> 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_, most programs have no performance reason to reach for unsafe in regular code. That's true in my experience.

Re: Mozilla Welcomes the Rust Foundation

#86

Post by simias »

skocznymroczny wrote: post #66
cmrdporcupine wrote: post #28

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…

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 with better adoption and no GC on the other (C++/Rust in particular).

While I personally find D interesting and vastly better designed than some of the competition (cough go cough) it's very hard for me to imagine it getting big in the mainstream without some massive industry backing.

Re: Mozilla Welcomes the Rust Foundation

#87

Post by simias »

raverbashing wrote: post #70
cmrdporcupine wrote: post #28

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…

Yeah agreed. While they're improving some of the usability around it, it is still a bit hard to understand. But I think it is beating C++ at its own race. The C++ weirdness is just... Bureaucratic and verbose. Rust is clunky at times but even then it is smoother than C++

C++ has massive adoption and billion of lines of codes in active use. IMO Rust is already superior syntax-wise in almost every area but C++ is going nowhere any time soon.

I'm sure some C++ codebases will outlive everybody posting in this thread.

Re: Mozilla Welcomes the Rust Foundation

#88

Post by pianoben »

justsomeuser wrote: post #31

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.

That's like one, _maybe_ two full-time developers in SV, at least of the sort you'd want to steward a project like Rust, plus a tiny bit left over to maintain the rest of the foundation.

Re: Mozilla Welcomes the Rust Foundation

#89

Post by miked85 »

nickelcitymario wrote: post #17

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

Re: Mozilla Welcomes the Rust Foundation

#90

Post by gsnedders »

zimpenfish wrote: post #54
bennyp101 wrote: post #41

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

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

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

It's possible, but unusual, for base salaries for individual contributors to be over £100k, especially if you look at both FAANG/adjacent companies and financial firms (both investment banking and at hedge funds). If you include bonuses and stock compensation, those same groups can relatively easily hit £100k.

Post reply on HN