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

131–140 of 197 posts

Re: Shipping Rust code in Firefox

#131

Post by steveklabnik »

binarycrusader wrote: post #126
steveklabnik wrote: post #28

Earlier quoted context omitted.

We've been doing a lot of work in this area, and some distros already have packages. Debian testing, for example. Currently, I believe that this functionality is optional, so distros aren't required to actually ship it just yet.

Great, because rust is not yet supported on all of the platforms that FireFox itself runs on (nevermind packaged), and that would put many in an unfortunate position.

Which ones are you concerned about? I personally haven't paid attention to the exact diff here.

In the past, we've explicitly added platform support for this reason, Windows XP comes to mind.

Re: Shipping Rust code in Firefox

#132

Post by dbaupp »

themihai wrote: post #122
steveklabnik wrote: post #118

Earlier quoted context omitted.

> Why do you need rustup if Rust is so backward compatible? For one, testing on various versions of Rust. For example, I have a kernel project that's pinned to a particular nightly version, while the rest of my projects build on stable. Rustup makes this Just Work.

Well, that's my point! You shouldn't need to test various versions of Rust if you there is a strong backward compatibility policy. I might be mistaken but my feeling is that most of the rust devs are using the nightly version thus the reason of a tool to debug/test different versions.

He didn't say he was "testing" with nightly: some experimental features only work on nightly (which, being experimental, the features may change in breaking ways, but that's why people have to opt-in to using a nightly) and so if one of your project needs one of these features, you can use rustup to get nightly for just that project and the stable releases for the rest of your work.

A staged release cadence with different levels of surety gives people the ability to play with features as they're developed to make sure those features solve the problems they're trying to solve (in the best way) by giving time for real-world experimentation and feedback. A feature can graduate from nightly-only to stable, and it then has a strong backwards compatibility requirement. The nightly experimentation period is valuable to get those features perfected before people can start relying on them more broadly.

Re: Shipping Rust code in Firefox

#133

Post by Manishearth »

themihai wrote: post #116
pcwalton wrote: post #108

Earlier quoted context omitted.

Rust has the same policy. It might appear differently because we're very up front about any change that might possibly break any code, even theoretically. We don't make any changes that we think actually break code, except for blatant bug fixes. Go has made changes post-1.0 that were more aggressive than anything Rust has done, such as changing the size of int.

I'm sorry to say but you must be delusional. Can you list the these `aggressive` breaking changes? There were only 7 releases since go1 and I fail to find any breaking change in the language specification. On the other side each Rust release has a fat list with "BREAKING CHANGES". Many Rust packages only work with specific Rust versions(i.e. nightly). The rust ecosystem(std lib, tools etc) is also way behind Go in te…

> Why do you need rustup if Rust is so backward compatible

To cross compile. To have quick toolchain updates. To get bleeding edge compiler improvements (e.g. speed) quickly. To test out new features. To help find bugs in the compiler.

One very common use case of rustup is to use clippy. Clippy is a developer tool which hooks directly into the compiler and uses all sorts of private APIs, an inherently unstable thing. It only works on nightly. Lots of people write their code to work on stable, but want to use this tool so they use rustup. Note that no language has a stable way of hooking into the compiler.

Very few rust packages only work with nightly. Care to provide some examples?

Re: Shipping Rust code in Firefox

#134

Post by themihai »

pcwalton wrote: post #123
themihai wrote: post #116

Earlier quoted context omitted.

I'm sorry to say but you must be delusional. Can you list the these `aggressive` breaking changes? There were only 7 releases since go1 and I fail to find any breaking change in the language specification. On the other side each Rust release has a fat list with "BREAKING CHANGES". Many Rust packages only work with specific Rust versions(i.e. nightly). The rust ecosystem(std lib, tools etc) is also way behind Go in te…

> Can you list the these `aggressive` breaking changes? Changing the size of int. Changing methods to introspect the type of their arguments and do things differently. And so on. > There were only 7 releases since go1 and I fail to find any breaking change in the language specification. On the other side each Rust release has a fat list with "BREAKING CHANGES". Because we have a very specific definition of "breaking…

You are right about the compiler changes but even so you can't compare 1-2 compiler BK with Rust which has language changes as well. Compiler changes are the norm in Rust.

>> The parts of the Rust standard library that are marked stable have remained completely backwards compatible, in both interface and implementation.

This looks like a breaking change on a stable API. Am I wrong? https://github.com/rust-lang/rust/pull/28811

Re: Shipping Rust code in Firefox

#135

Post by Manishearth »

themihai wrote: post #114
steveklabnik wrote: post #97

Earlier quoted context omitted.

This is not true: > Although we expect that the vast majority of programs will > maintain this compatibility over time, it is impossible to > guarantee that no future change will break any program. https://golang.org/doc/go1compat It's extremely similar to our attitude, and that of Java, etc: > Of course, for all of these possibilities, should they arise, > we would endeavor whenever feasible to update the specificat…

methodonpointerotpointer is not a breaking change if you read the specs. Rust doesn't even have a formal language specification.

Rust has rfcs, and many of the "breaking changes" are in places where the implementation didn't follow the RfC. Others were in things that were never intended to compile. Its effectively the same thing.

Re: Shipping Rust code in Firefox

#136

Post by themihai »

pcwalton wrote: post #123
themihai wrote: post #116

Earlier quoted context omitted.

I'm sorry to say but you must be delusional. Can you list the these `aggressive` breaking changes? There were only 7 releases since go1 and I fail to find any breaking change in the language specification. On the other side each Rust release has a fat list with "BREAKING CHANGES". Many Rust packages only work with specific Rust versions(i.e. nightly). The rust ecosystem(std lib, tools etc) is also way behind Go in te…

> Can you list the these `aggressive` breaking changes? Changing the size of int. Changing methods to introspect the type of their arguments and do things differently. And so on. > There were only 7 releases since go1 and I fail to find any breaking change in the language specification. On the other side each Rust release has a fat list with "BREAKING CHANGES". Because we have a very specific definition of "breaking…

Does Rust have a formal specification?

Re: Shipping Rust code in Firefox

#137

Post by 9mit3t2m9h9a »

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

Another question is that determining what is sensitive information is a bit complicated… But there is an option of asking the user to edit URL to find anonymous enough form of the bug trigger. Maybe after doing some basic fuzzing (like replacing runs of alphanumerics with random runs of alphanumerics of the same length, if possible).

Re: Shipping Rust code in Firefox

#138

Post by amenod »

mkesper wrote: post #129
jgraham wrote: post #94

Not in the same league as the mp4 parser shipping to all Firefox users, but GeckoDriver [1], a Mozilla-authored standalone binary for interacting with Firefox via the WebDriver protocol (e.g. using Selenium) is also written in Rust and shipping, possibly to as many as hundreds of users ;) Overall the experience of using Rust for that project has been pretty great; the original requirements for a language were "able t…

How did you handle the Python to rust knowledge transition? Do you know any helpful guides?

Not OP, but first few chapters of http://rustbyexample.com/ seem much less steep than The Book (to me). Would also appreciate other guides... (coming from C / Java / PHP / Python myself)

Re: Shipping Rust code in Firefox

#139

Post by themihai »

pcwalton wrote: post #125
themihai wrote: post #122

Earlier quoted context omitted.

Well, that's my point! You shouldn't need to test various versions of Rust if you there is a strong backward compatibility policy. I might be mistaken but my feeling is that most of the rust devs are using the nightly version thus the reason of a tool to debug/test different versions.

> You shouldn't need to test various versions of Rust if you there is a strong backward compatibility policy. Can you specify, in particular, what you think Rust is not doing that it should be doing?

I would like the code developed now to work with all subsequent rust releases until 2.0 so that I can take advantage of improvements to the compiler and std libraries without any additional effort. A small effort may effort may be required if there were security/critical bugs.

Re: Shipping Rust code in Firefox

#140

Post by dman »

nickpsecurity wrote: post #83
pcwalton wrote: post #76

Earlier quoted context omitted.

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

CoqASM looks interesting! Is it publicly available anywhere?
Post reply on HN