Live data from Hacker News

Shipping Rust code in Firefox

hacks.mozilla.org

141–150 of 197 posts

Re: Shipping Rust code in Firefox

#141

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.

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

Testing nightly makes sense.

>>What if I would like to guarantee this property for my own code?

I think that should be an exception if the backward compatibility is to be trusted.

Re: Shipping Rust code in Firefox

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

I don't think I have any specific resources to recommend, sorry.

I wrote most of the initial implementation of geckodriver and mostly learnt Rust from reading the official book, writing some small patches for Servo, and working on this project (of course); pretty much the same advice you would get coming from any other language.

I just chatted with one of the other major contributors to the project who said that he was able to learn on the job by reading the existing code, looking up concepts in the book or via web searches, and asking questions when necessary; although some parts of Rust undoubtedly have a significant learning curve it is empirically possible to contribute to an existing project without a significant amount of upfront study. This arguably isn't too different from learning most languages, although you are going to need to read up on the rules around e.g. references and borrowing sooner than you would need to look something up if you took the same approach to writing your first Python.

The type system and borrow checker mean that the compiler will tell you if you're doing something wrong which is both a blessing and a curse; it can be dispiriting to get dozens of compile errors when you are getting started, but once you have satisfied the compiler it's possible to be more confident that your code won't break in ways that are relatively common in Python (e.g. missing or broken code for error handling).

So I'm not sure that I answered your question, but in practice it didn't seem to be a major problem. Of course in a different environment — one where people were less enthusiastic about learning a technology their colleagues were raving about, for example — you might have a different experience.

Re: Shipping Rust code in Firefox

#143

Earlier quoted context omitted.

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

Testing nightly makes sense. >>What if I would like to guarantee this property for my own code? I think that should be an exception if the backward compatibility is to be trusted.

Right, but humans are fallible. Bugs happen. It's a good idea to test early and often, just to make sure: Travis runs are extremely cheap. Better to catch accidents before they make it into an actual release. More testing doesn't hurt anyone.

Re: Shipping Rust code in Firefox

#144

Earlier quoted context omitted.

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

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

Rust is doing exactly that.

Re: Shipping Rust code in Firefox

#145
post #140

Earlier quoted context omitted.

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?

Not that Im aware of. They might privately license it if asked. I mainly bring it up as something worth cloning by FOSS team given there's plenty details in paper. Meanwhile, look up Magnus Myreen's publications and software as they're on a row with verified everything.

Re: Shipping Rust code in Firefox

#146

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…

> Rust which has language changes as well

Rust doesn't have backwards incompatible language changes.

> This looks like a breaking change on a stable API.

No. It is a method addition. It is breaking only in the sense that code that didn't explicitly invoke the previous "as_ref" method might call this new method instead. It's the moral equivalent of:

    type A struct { ... }

    type B struct {
        A
    }

    func (a ﹡A) Foo() {}
and then a later version of Go adds a method:

    func (b ﹡B) Foo() {}
Such that code that called Foo() on an instance of ﹡B might call the new method instead. Go can make those changes.

Re: Shipping Rust code in Firefox

#147

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…

Does Rust have a formal specification?

It has a language definition. Neither Rust not Go have a formal semantics.

Re: Shipping Rust code in Firefox

#148

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.

> methodonpointerotpointer is not a breaking change if you read the specs.

It's not a breaking change according to Go's definition of breaking changes, by which Rust hasn't had any breaking change either.

> Rust doesn't even have a formal language specification.

Neither does Go, the spec is not a formal specification (and the first phrase of the intro states that it's a reference manual).

Re: Shipping Rust code in Firefox

#149

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…

Rust uses a much stricter definition of breaking change than does Go. As discussed elsewhere in this thread, Go changed the size of integers. While this is technically allowed by the language (it wasn't previously specified), and it shouldn't break conforming code, it can break code that depended on the previous size.

The Rust maintainers would have considered this a breaking change. The Go maintainers did not. This isn't to say either side is right or wrong, just that they are measuring different things.

Additionally, the Rust maintainers have been exceedingly cautious whenever making these types of changes. They literally download, compile, and test all published crates to look for indications that such a change might actually break existing code. In the very few cases it has, they've worked with crate authors to incorporate fixes.

The very low bar Rust sets for determining what is a breaking change directly reflects the extreme regard they have for this issue.

Post reply on HN