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

61–70 of 197 posts

Re: Shipping Rust code in Firefox

#61

Post by Dylan16807 »

snuxoll wrote: post #58
gregwtmtno wrote: post #36

Earlier quoted context omitted.

> I wonder if Firefox will slowly become written in mostly Rust. I doubt that will ever happen. Small parts of Firefox, yes, but the browser is enormous. I think I once read that even Servo, which is a showcase for Rust, has more C/C++ code in it than Rust code, largely because it uses Firefox's JS engine.

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.

Re: Shipping Rust code in Firefox

#62

Post by steveklabnik »

snuxoll wrote: post #59
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.

Now that Rust can properly bootstrap from previous versions I can see most distros getting it packaged soon(TM), unfortunately the Fedora 25 change window ends today and since rust/cargo will require new packaging guidelines unless someone really steps up to the plate (I don't have time today) it won't make it in until F26.

Ah, bummer. How long between Fedora releases?

Re: Shipping Rust code in Firefox

#63

Post by snuxoll »

steveklabnik wrote: post #62
snuxoll wrote: post #59

Earlier quoted context omitted.

Now that Rust can properly bootstrap from previous versions I can see most distros getting it packaged soon(TM), unfortunately the Fedora 25 change window ends today and since rust/cargo will require new packaging guidelines unless someone really steps up to the plate (I don't have time today) it won't make it in until F26.

Ah, bummer. How long between Fedora releases?

6 months, all that needs to get in is a proposal (first alpha is a month away so there's plenty of time to flesh it out). We can still package rustc without needing a change, but cargo would be delayed if there isn't a proposal on the wiki before the end of day.

Re: Shipping Rust code in Firefox

#64

Post by Esau »

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 don't have a problem with telemetry, provided it is opt-in.

Re: Shipping Rust code in Firefox

#65

Post by arc_of_descent »

arc_of_descent wrote: post #39

The headline is really wrong. Mozilla is shipping compiled and executable code to us. Now, if its Perl, I can confidently say I'm shipping Perl code to you. Small nitpick, I know :)

Why am I being down voted? Is my comment not relevant at all to the topic? Why not just ignore my comment or reply with the advice?

We need that new moderator quickly! :)

Re: Shipping Rust code in Firefox

#66

Post by madmax96 »

steveklabnik wrote: post #27
madmax96 wrote: post #18

Super exciting! I followed Rust at the beginning and I was pleased with the design goals of the language. However, I wasn't thrilled with the pre-1.0 documentation, and even after 1.0 there were breaking changes to the language. Hopefully this is a sign of Rust's maturity. I'll have to look at it again:>) EDIT: s/from/at/

Which post-1.0 breaking changes were you worried about? This is technically correct, but we've managed it in a way that's been hopefully painless to deal with, and the community survey seemed to agree.

The compiler has been fantastic emitting warnings about future language changes and I have appreciated it. The Rust compiler's messages (in general) are some of the highest quality I've seen, actually. The Rust Devs have done a superb job at documenting the changes. I'm more complaining that breaking changes to a non-beta language leave a bad taste in my mouth. Sure, they do have to happen sometimes, but it seems that this should be rarer than it has been so far with Rust.

So I haven't worried about anything per se, but breaking changes are mildly irritating to me. Without a doubt the utility value of some of these changes has been worth it (specifically RFC 1214, which was ironically one of the most major and definitely necessary). I'm not involved enough to be able to speak about other changes.

EDIT: I should also add that the software I work on professionally doesn't use any language that Rust competes with directly. Rust doesn't offer me professional utility so it's easy for me to complain about one thing and ignore all the benefits of Rust. If I were in a situation where I was contemplating using C++, Rust, or maybe Go, I think I would still choose Rust. It's far ahead of its competitors and gets a lot of things right.

Re: Shipping Rust code in Firefox

#67

Post by swsieber »

larsberg wrote: post #9
mkroman wrote: post #5

I'm curious why rust-url still hasn't been shipped with firefox yet. https://bugzilla.mozilla.org/show_bug.cgi?id=1151899

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

Re: Shipping Rust code in Firefox

#68

Post by guelo »

bluejekyll wrote: post #17

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.

Re: Shipping Rust code in Firefox

#69

Post by haberman »

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.

It seems safe to say that a JIT-trace -> Rust -> machine code compilation pipeline will probably never be fast enough to satisfy the requirements of a high-performance JIT compiler.

Re: Shipping Rust code in Firefox

#70

Post by steveklabnik »

madmax96 wrote: post #66
steveklabnik wrote: post #27

Earlier quoted context omitted.

Which post-1.0 breaking changes were you worried about? This is technically correct, but we've managed it in a way that's been hopefully painless to deal with, and the community survey seemed to agree.

The compiler has been fantastic emitting warnings about future language changes and I have appreciated it. The Rust compiler's messages (in general) are some of the highest quality I've seen, actually. The Rust Devs have done a superb job at documenting the changes. I'm more complaining that breaking changes to a non-beta language leave a bad taste in my mouth. Sure, they do have to happen sometimes, but it seems tha…

Cool, thanks. I mostly want to make sure we don't have any blind spots here; this is an issue we care about deeply. I think it's also important to remember that even languages which are known for "no breaking changes" do introduce breaking changes. Take Java for example, known for being an exemplar in this space.

  > However, implementation of some Java SE 8 features required changes that could
  > cause code that compiled with Java SE 7 to fail to compile with Java SE 8.
http://www.oracle.com/technetwork/java/javase/8-compatibilit...

Especially in a statically-typed language, technically breaking changes are a fact of life. The key is to make them as minimal as possible, so that you don't struggle to update.

(Oh, and glad to hear you like the errors: we're actually working on making them even better. Elm is really leading the way here...)

Post reply on HN