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

121–130 of 197 posts

Re: Shipping Rust code in Firefox

#121

Post by dbaupp »

madmax96 wrote: post #117
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.

>Go has made changes post-1.0 that were more aggressive >than anything Rust has done, such as changing the size of int. Changing the size of int shouldn't be a breaking change in Go since pointer arithmetic isn't allowed and everyone should use fixed-size variables when you're relying on this behavior. Even if this isn't true, Go's release note says: >The language allows the implementation to choose whether >the int…

> Changing the size of int shouldn't be a breaking change in Go since pointer arithmetic isn't allowed and everyone should use fixed-size variables when you're relying on this behavior.

Theoretically one should be using fixed-sized variables, but people may not realise they're relying on a particular behaviour. One of the whole points for using a language like Go over, say, C is that humans are imperfect and so having the computer assist is good, and this imperfection penetrates into all aspects of the software process. With a tasty name like "int" and being generally the default type, I'm sure a lot of code uses it when fixed sized types may be better.

> The only thing that changed was the implementation, not the language.

This is somewhat irrelevant: it still results in code not compiling or possibly changing behaviour, because people in fact have to use an implementation of Go, they don't write in an abstract idealised version of it. Rust's breaking changes are generally the same sort of thing (undocumented implementation details, changing the implementation to match the long-stated desired behaviour and bug fixes), but they still result in people's code not compiling or changing behaviour and so need to be handled as such.

Re: Shipping Rust code in Firefox

#122

Post by themihai »

steveklabnik wrote: post #118
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…

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

Re: Shipping Rust code in Firefox

#123

Post by pcwalton »

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…

> 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 change" that is primarily concerned with the practical effect of changes we make. Go does not consider these changes "breaking". Using Go's definition (changes to the language definition), we have no "breaking changes".

If we were to change the size of int (something we will not do, by the way, due to the practical effects of making such a change), then we would list it under "breaking changes", even if we were technically allowed to do it. That's because we care about the practical effects of our changes, not just the letter of the language definition.

> Many Rust packages only work with specific Rust versions(i.e. nightly).

Because they are explicitly opting into unstable features that are carefully marked as such. We can't stop packages from doing that. Nor can any other language.

> The rust ecosystem(std lib, tools etc) is also way behind Go in terms of stability.

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

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

Because it's nice to keep your compiler up to date and to target different platforms?

Re: Shipping Rust code in Firefox

#124

Post by comex »

Dylan16807 wrote: post #61
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.

A JIT doesn't have to be any less safe than compiling Rust code.

No, but to be safe enough it has to be more safe than the Rust compiler, because the latter doesn't get run on untrusted code (with the result automatically executed)[1]. If bounds checks exist in the compiler IR, they're subject to optimization, which is very helpful for performance but also risky, as incorrect optimizations can easily cause memory unsafety. Optimizer bugs in modern backends are rarely encountered in practice, but from a security perspective, that's like saying your C++ program never crashes in practice: it helps, but it doesn't prove the absence of bugs that can only be triggered by pathological inputs; such bugs in fact tend to be quite common.

I've never tried to find an optimizer bug in LLVM, but I have found more than one in V8, so I have some idea what I'm talking about.

[1] More specifically, this doesn't happen in situations where correctness of the generated code is relied on to provide safety guarantees. There are several websites that will compile and run Rust code for you, but none of them try to ban unsafe code, or filesystem/syscall access for that matter, at the language level; rather, their security model relies entirely on the OS sandbox the process runs in. Google's PNaCl uses (or used to use?) LLVM on untrusted code, but AFAIK the output of LLVM, the machine instructions, are still run through the NaCl validator, so getting LLVM to miscompile something wouldn't accomplish much. (NaCl also runs both LLVM itself and the untrusted code in an OS sandbox.)

Re: Shipping Rust code in Firefox

#125

Post by pcwalton »

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.

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

Re: Shipping Rust code in Firefox

#126

Post by binarycrusader »

steveklabnik wrote: post #28
radarsat1 wrote: post #20

Does this imply anything regarding rust compiler package for distros? To support the Firefox build, all distros will have to have good rust compiler packages now, right? (I'm sure the status is already not bad, I haven't checked recently..) If it becomes something dependable, infrastructure-wise, like Java, this might mark the beginning of a more serious uptake.

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.

Re: Shipping Rust code in Firefox

#127

Post by ChuckMcM »

ffggvv wrote: post #106
ChuckMcM wrote: post #92

This is awesome. Now we just need a rust based flash player :-)

Or we should get rid of flash already.

I see it more like the Chesterson's Fence argument. Flash exists, and continues to plague us, because it met a need for developers that wasn't met in other ways. If that need still exists, rather than remove Flash (can the capability with it) and replace it with the same capability but with a much reduced attack surface.

I think that would be an excellent project for someone, if you should both show all of Flash's capabilities implemented in Rust and that the result was safer it would be an excellent endorsement of Rust. It could also illuminate end user features which can never be made safe. Also good for the overall body of web knowledge.

Re: Shipping Rust code in Firefox

#128

Post by snuxoll »

Manishearth wrote: post #109
avita1 wrote: post #78

Earlier quoted context omitted.

That's not a complete comparison though -- sbt only downloads the platform-independent jars and minuscule launcher scripts. It's still on the user to install a JRE globally. An analogue for rust would be something that detects the platform at runtime and then downloads a statically linked (?) binary that works on that platform. It can also exploit the ivy cache as the Scala compiler is just a library as far as SBT is…

Distros are okay with a single starting binary for compilers. Gcc does this, for example. Rust would publish a single bootstrap binary, and distros would build the next compiler with that (and publish), and build the next one with the one that they just built, and so on. Multiple platforms would just involve cross compiling the first time.

The problem, historically, with Rust is that each release was built with the latest nightly, so you had to bootstrap each new version. Now they've changed to using the previous compiler release to bootstrap, so you can bring a binary in for the first build of a package then immediately rebuild with your bootstrapped binary and continue on from there for eternity.

Re: Shipping Rust code in Firefox

#129

Post by mkesper »

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?

Re: Shipping Rust code in Firefox

#130

Post by steveklabnik »

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.

What if I would like to guarantee this property for my own code? As well as testing each nightly as they come out, in case something accidentally breaks, so it can be fixed before a release? This tooling assists greatly with that.

(And dbaupp is correct that it's not always about testing; not all of the OS dev features are in stable yet, so nightly is the only option for that kind of project.)

Post reply on HN