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

111–120 of 197 posts

Re: Shipping Rust code in Firefox

#111

Post by steveklabnik »

Manishearth wrote: post #107
steveklabnik wrote: post #104

Earlier quoted context omitted.

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

This is including the cargo cache dir?

I built Servo last week, I ran "git fetch upstream && git reset --hard upstream/master && git submodule update" and then "tokei .". So, unless Servo puts its cache in the dir, I would guess not, no.

Re: Shipping Rust code in Firefox

#112

Post by Manishearth »

steveklabnik wrote: post #111
Manishearth wrote: post #107

Earlier quoted context omitted.

This is including the cargo cache dir?

I built Servo last week, I ran "git fetch upstream && git reset --hard upstream/master && git submodule update" and then "tokei .". So, unless Servo puts its cache in the dir, I would guess not, no.

I think by default servo does put the cache in the dir. So yeah, this would be an accurate estimate.

Though not all that rust code is written specifically for servo, and a lot of that C/++ code is winapi and skia. winapi is autogenerated, and skia isn't used by default anymore iirc.

Re: Shipping Rust code in Firefox

#113

Post by Sylos »

penagwin wrote: post #10

AHHH Telemetry! I feel like there is a group of people who freak out to any form of telemetry, I just wanted to highlight them using it to track bugs. It's super beneficial to any form of changes, especially something like switching an entire language for a component.

I think a big portion of those people come from the fact that it's essentially impossible to verify what each and every piece of telemetry does. And ultimately, you as a user don't directly gain anything from enabling it / leaving it enabled, so it's perfectly reasonable to stay ignorant in this case.

Re: Shipping Rust code in Firefox

#114

Post by themihai »

steveklabnik wrote: post #97
themihai wrote: post #89

Earlier quoted context omitted.

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

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.

Re: Shipping Rust code in Firefox

#115

Post by steveklabnik »

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.

Sure. My point is that this is similar to what we guarantee: the compiler used to compile some code, and now it won't. As they say, "It has therefore been disallowed in Go 1.4, which is a breaking change, although very few programs will be affected." Our breaking changes have been similar.

Re: Shipping Rust code in Firefox

#116

Post by themihai »

pcwalton wrote: post #108
themihai wrote: post #89

Earlier quoted context omitted.

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

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 terms of stability. Why do you need rustup if Rust is so backward compatible? I'm not saying that Go is a better language than Rust but the its ecosystem and dev experience is definitely superior.

Re: Shipping Rust code in Firefox

#117

Post by madmax96 »

pcwalton wrote: post #108
themihai wrote: post #89

Earlier quoted context omitted.

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

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 type and uint types are 32 or 64 bits. [1]
The only thing that changed was the implementation, not the language.

[1] https://golang.org/doc/go1.1#int

Re: Shipping Rust code in Firefox

#118

Post by steveklabnik »

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

Re: Shipping Rust code in Firefox

#119

Post by dbaupp »

dymk wrote: post #102
Esau wrote: post #64

Earlier quoted context omitted.

I don't have a problem with telemetry, provided it is opt-in.

This makes telemetry effectively useless for developers though, unless a big intrusive "Click here to opt in" button is presented during startup. Nobody is going to enable it on their own accord.

Last time I installed Firefox (a month or two ago) it in fact did pop-up a button asking if you wanted to send telemetry back to Mozilla.

Re: Shipping Rust code in Firefox

#120

Post by pcwalton »

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.

All of the "breaking changes" in Rust have been of this form.

We're very up front about any possible breakage. When we talk about "breaking changes", we mean "a change that shouldn't be breaking, but could be breaking if code was relying on this bug/implementation-specific behavior". Those types of changes—changes that might cause breakage in practice but do not change the language definition—are often not considered "breaking changes" in Go. But in Rust we often call them "breaking changes", because we are concerned first and foremost about the practical considerations of changes we make, not just whether we are technically allowed to make them per the letter of the law.

Post reply on HN