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

Shipping Rust code in Firefox

hacks.mozilla.org

Post reply on HN
Print view View original

81–90 of 197 posts

Re: Shipping Rust code in Firefox

#81

Post by Cshelton »

madmax96 wrote: post #66
steveklabnik wrote: post #27

Earlier quoted context omitted.

Which post-1.0 breaking changes were you worried about? This is technically correct, but we've managed it in a way that's been hopefully painless to deal with, and the community survey seemed to agree.

The compiler has been fantastic emitting warnings about future language changes and I have appreciated it. The Rust compiler's messages (in general) are some of the highest quality I've seen, actually. The Rust Devs have done a superb job at documenting the changes. I'm more complaining that breaking changes to a non-beta language leave a bad taste in my mouth. Sure, they do have to happen sometimes, but it seems tha…

I'm curious, do you have a language in mind that has been better than Rust as far as breaking changes go after the 1.0 stable release? An example? Rust has been far above most languages/libraries that I've found in dealing with breaking changes. The complaint here seems pretty empty to me. (Complaining for the sake of complaining)

Re: Shipping Rust code in Firefox

#82

Post by steveklabnik »

bluejekyll wrote: post #79
snuxoll wrote: post #58

Earlier quoted context omitted.

SpiderMonkey is probably a long-term target for a Rust replacement or oxidization over time, but considering it is a JIT there's certain classes of issues Rust couldn't help with since native code generation is inherently unsafe.

How about starting with WebAssembly... should have less scope.

The people who would work on these two things are pretty disjoint, or at least, I'm not aware of any SpiderMonkey people working on our wasm support. So it's not really an either-or kind of proposition.

Re: Shipping Rust code in Firefox

#83

Post by nickpsecurity »

pcwalton wrote: post #76
Dylan16807 wrote: post #71

Earlier quoted context omitted.

Going the long way is just a 'proof of concept' sort of thing. You could design a high-performance JIT around equivalent safety mechanisms, and even prove the tricky parts.

JavaScript's memory model is incompatible with that of Rust anyhow. You would want something like typed assembly language (Google this--it's a fertile research area). Very researchy though, with uncertain payoff. But note that a lot of security problems are not in the jitcode but rather in C++ implementations of JS objects and in the compiler itself.

BOOM! Typed, assembly language is exactly what I was going to recommend! TALC assembly, Chlipala's Bedrock, and Microsoft's CoqASM are Google keywords to use for anyone following along.

CakeML or Verisoft's C0 could be useful for assembly generation but not as sure there. Tough constraints in JIT. Edited to add Myreen's JIT that I just remembered.

http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=F58...

Re: Shipping Rust code in Firefox

#84

Post by nickpsecurity »

swsieber wrote: post #67
larsberg wrote: post #9

Earlier quoted context omitted.

There are a couple of big pieces of work here: 1) Making the "cargo vendor" story work better. rust-url has a bunch of dependencies, and you have to get them all in-tree. 2) More security review & planning. URL parsing is scary! And we'd want to ship & run it alongside the C++ one to check for places where rust-url is not fully web compatible, but there are major privacy issues in reporting back anything more than "1…

It would be cool for #2 that if a difference was detected, firefox would try to test and generate a general case (or a minimal case) - substituting out sensitive information. I guess sort of like fuzzy testing...

That's a great idea. They should consider doing that even if the initial code mighg be convoluted a bit.

Re: Shipping Rust code in Firefox

#85

Post by cpeterso »

kevincox wrote: post #33
Manishearth wrote: post #24

Earlier quoted context omitted.

IIRC the telemetry involved here was only run on the nightly/developer edition versions. Or something like that. The restrictions on telemetry on release versions are pretty stringent. It's possible this was measured on release, I'm not aware of the details, but I suspect it wasn't.

From my understanding release is opt-in only. (My understanding is based upon whenever I install Firefox it promts me to enable telemetry, which is disabled by default)

You are both correct. :)

Firefox telemetry is opt-out on the Nightly, DevEdition, and Beta channels, but (mostly) opt-in on the Release channel. The opt-in telemetry from the Release channel has limited use because it is not representative of all users.

Here is a list of Firefox's telemetry measurements. Those that are opt-out on the Release channel are tagged "releaseChannelCollection": "opt-out". Adding a new opt-out measurement requires an additional privacy review.

https://hg.mozilla.org/mozilla-central/file/tip/toolkit/comp...

Re: Shipping Rust code in Firefox

#86

Post by hyperpape »

maxerickson wrote: post #54
hyperpape wrote: post #51

Earlier quoted context omitted.

I'd say it's nerdview that's going to be read by nerds, and that unlike the examples in that lovely post, it will be understood by the majority of people who read it.

Sure, it wasn't egregious, but I think the insider perspective idea has lots of explanatory power when it comes to the confusion Noseshine expressed and the surprise wyager responded to the confusion with.

Well, obviously we can disagree and I could be wrong, but I think Noseshine's response was a "man bites dog" situation. After thinking about it, I'd still expect the intended audience to see it.

Re: Shipping Rust code in Firefox

#87

Post by topspin »

alimbada wrote: post #57

Are there other improvements besides the security advantages from this? E.g. performance or memory usage?

Interesting question. One assumes they've achieved at least parity with the legacy code, so comparing these in detail would yield some useful insights.

Re: Shipping Rust code in Firefox

#88

Post by _uhtu »

Noseshine wrote: post #29
akerro wrote: post #13

Earlier quoted context omitted.

You did not think, they would replace VanillaJS with Rust, did you? ;)

What does "replace" have to do with it? Why do you invent the most illogical option possible - that I never uttered - to find a counter argument? Assuming that they ship another language in addition to Javascript would not be completely out of the question. While it seems that with WebAssembly that is no longer necessary, who knows what Mozilla, in search of future funding, may come up with to open new markets. They…

Wow you took that joke way too seriously my friend.

Re: Shipping Rust code in Firefox

#89

Post by themihai »

Cshelton wrote: post #81
madmax96 wrote: post #66

Earlier quoted context omitted.

The compiler has been fantastic emitting warnings about future language changes and I have appreciated it. The Rust compiler's messages (in general) are some of the highest quality I've seen, actually. The Rust Devs have done a superb job at documenting the changes. I'm more complaining that breaking changes to a non-beta language leave a bad taste in my mouth. Sure, they do have to happen sometimes, but it seems tha…

I'm curious, do you have a language in mind that has been better than Rust as far as breaking changes go after the 1.0 stable release? An example? Rust has been far above most languages/libraries that I've found in dealing with breaking changes. The complaint here seems pretty empty to me. (Complaining for the sake of complaining)

Go has better backward compatibility.(i.e. no breaking change after 1.0)

Re: Shipping Rust code in Firefox

#90

Post by cpeterso »

DCoder wrote: post #40
throwawayReply wrote: post #34

That telemetry graph looks odd, dates filtered from 2016/03/03 to 2016/04/07 but "Number of dates" is "3". So does that mean despite a billion samples between those dates, all samples fell on just three dates?

If you click on the image to see the interactive graph, under "Advanced settings" there's a switch "Date range variable: filter submissions by build date range or submission date range", which is set to "build date range". So those "3 dates" correspond to three different build dates.

The telemetry link in the article points to Firefox 45 data. Curiously, the error rates appear to be going up: Firefox 46's error rate is 0.10% and Firefox 47's error rate is 4.35%.

* Firefox 45: https://telemetry.mozilla.org/new-pipeline/dist.html#!measur...

* Firefox 46: https://telemetry.mozilla.org/new-pipeline/dist.html#!measur...

* Firefox 47: https://telemetry.mozilla.org/new-pipeline/dist.html#!measur...

Post reply on HN