Live data from Hacker News

Shipping Rust code in Firefox

hacks.mozilla.org

151–160 of 197 posts

Re: Shipping Rust code in Firefox

#151

Earlier quoted context omitted.

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

> Compiler changes are the norm in Rust.

Compiler changes are the norm everywhere? I'm not sure what you're trying to say here.

> This looks like a breaking change on a stable API. Am I wrong?

Yes and no.

Rust's policy on breaking changes is that changes that can be fixed by properly qualifying an implicit path are not breaking. Otherwise, adding any method to anything would be a breaking change. In this case, you can use the UFCS syntax to disambiguate.

So it's an "allowed" kind of breakage because not allowing this means freezing the stdlib.

(Go doesn't have this issue due to lack of generics, overloading, and interface-based overloading. Edit: actually, go does too, due to inheritance, but that is easier to avoid and isolate. In rust you can always write client code that breaks if the stdlib adds a method, anywhere. This is true for most typed languages).

Anything that has the chance of practically breaking things is still run through crater (which tests impact on the ecosystem) and as you can see that PR had minimal impact.

Re: Shipping Rust code in Firefox

#152
post #68

Will this include iOS devices too? This is great news for the language as it's going to help make sure a wider array of architectures are supported. Awesome work!

Firefox for iOS is just a wrapper around webkit since Apple refuses to allow any alternate engines.

IIRC, technically alternate (rendering) engines are allowed but you can only execute downloaded code using the system's webkit/JSC (and if you didn't you'd be restricted to a straight interpreter).

Re: Shipping Rust code in Firefox

#153

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…

> I'm sorry to say but you must be delusional

Please don't include things like this in comments.

Re: Shipping Rust code in Firefox

#154

Earlier quoted context omitted.

No, it works for other repostiories. Probably Github uses cloc. I downloaded the code (over 500MB, insane!) and cloc throws an error.

> and cloc throws an error tokei is a similar program that's parallel, and written in Rust. It takes 11 seconds to run on my machine, and shows https://gist.github.com/steveklabnik/b4ede6f13c9d609edc61d74... (using a gist since the output is huge, and see Manish's comment as well)

Neat. Problem with code in Rust, resolved by project in Rust :)

Re: Shipping Rust code in Firefox

#155

Earlier quoted context omitted.

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.

Well, LLVM doesn't work well on SPARC yet, so anyone on a SPARC-based system would be affected (yes, I know the number of people running FireFox on SPARC is relatively small, although it certainly numbers in the thousands).

And until recently, as another example, rust didn't quite work yet on Solaris (amd64); thankfully, a community member stepped up and has been actively working on that port.

Re: Shipping Rust code in Firefox

#156

Earlier quoted context omitted.

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.

Well, LLVM doesn't work well on SPARC yet, so anyone on a SPARC-based system would be affected (yes, I know the number of people running FireFox on SPARC is relatively small, although it certainly numbers in the thousands). And until recently, as another example, rust didn't quite work yet on Solaris (amd64); thankfully, a community member stepped up and has been actively working on that port.

Cool thanks! As always, so much work to do...

Re: Shipping Rust code in Firefox

#158

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.

Firefox builds are also reproducible, so does this mean that stable Rust will generally be reproducible as well?

Re: Shipping Rust code in Firefox

#159
post #106

Earlier quoted context omitted.

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

> Flash exists, and continues to plague us, because it met a need for developers that wasn't met in other ways.

Emphasis on "met". I've yet to come across a function that can be built in Flash, but not in HTML 5. In fact, I'm not using flashplayer at all anymore and I don't suffer. (There are a few video sites that are still Flash-only, but `mpv --ytdl` works around that very nicely.)

Come to think of it, this is actually not true. At work, I have to use Flash Player for exactly one thing: Adobe Connect. I wonder why they didn't move to Flash yet. ;)

Re: Shipping Rust code in Firefox

#160

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.

Firefox builds are also reproducible, so does this mean that stable Rust will generally be reproducible as well?

We put in a lot of work for reproducible builds, I'm not aware of anything obvious that would make it not so right now. If we're not, please file bugs! We've fixed them in the past.
Post reply on HN