6 ms·

Even though the title might disappoint, it's super interesting to see where Firefox is going. I can't wait for 2017!

by mxstbr 10y ago

osullivj 10y ago
Looking forward to it too; this is a big deal because it will put a Rust implementation on many millions of desktops. I'm totally fed up with CPU and memory hogging browser bloat on my laptop. My dev env runs so much better when I kill all Chrome processes. I know that the article is only talking about the render engine, and not JavaScript, which I suspect is the main browser bloat culprit , but I'm still hopeful. Bring on the Rust JS engine I say!
- hvidgaard 10y ago
  It's not going to change that. No matter how efficient you make the JS engine, crappy JS will still steal all your ressouces.
  - osullivj 10y ago
    Yes. However, a crappy, leaky, JS engine running crappy JS code will steal all resources even quicker. I hope a JS engine built with Rust smart ptrs will be less leaky than one built in C/C++. In my experience, hand rolled memory pooling systems can be very leaky.
    - gsnedders 10y ago
      There's no plan to write a new JS engine at Mozilla, FWIW.
      - Cshelton 10y ago
        And they shouldn't...let's move forward... to WASM (Web Assembly)! Which, also posted on front page of HN recently, a user's medium blog on compiling Rust to WASM. https://medium.com/@chicoxyzzy/compiling-rust-to-webassembly-guide-411066a69fde#.r8qex53c3 https://medium.com/@chicoxyzzy/compiling-rust-to-webassembly...
        gsnedders 10y ago
        Except, like, JS isn't going to die any time soon, and realistically, implementing a new JS or WASM VM isn't actually that interesting to do: the big risk in a JITing VM that Rust cannot save you from is behaviour of your JITed code, which makes memory safety far harder to enforce.
        Cshelton 10y ago
        Right, JS isn't going anywhere. But once WASM is able to run everywhere, anybody attempting to make high performance web apps would ideally want to write it in WASM. A lot of what JS does on the web is plenty fast and won't really benefit much from JS being multi-threaded/faster. Sites using JS to run simple scripts or to fire api calls/etc. will continue to use JS, no reason to use WASM. Also, I believe WASM is truly compiled code and not JIT ran? I may be wrong...but pretty sure that was the whole point of creating it. Native app performance in the browser... that will take a big bite out of the app stores that take a good cut of revenue and control what can and can not be in the store. And sure, WASM can also have memory safety problems, especially with C/C++ being the primary languages to target WASM from. But that's also where Rust would shine, making it much more safe when compiled to WASM.
        gsnedders 10y ago
        WASM isn't machine code: if it were, it wouldn't be universal which is a fundamental requirement of the web. (Well, okay, it's compiled code—it is, after all, compiled from C/C++/etc., but in the same way JS is compiled to byte code in VMs today.) As such, there's a further compilation step needed from WASM to machine code to get near-native performance out of it. The existing WASM implementations do a mixture of JITing code at load-time and JITing code at first-call, depending on the size of the WASM blob, AFAIK. The gain performance wise over asm.js is primarily in parse-time, as far as I'm aware. WASM VM itself is perfectly possible to be memory safe: WASM code cannot read outside of the memory allocated to it (and malloc/free are implemented on top of that memory allocated to the VM, hence there's memory safety at the VM level). The big problems come when you need to guarantee your JIT code doesn't violate memory safety, and that's something Rust's type system cannot (currently) solve. You need guarantees that the generated code will never have any memory access errors, and will never race for memory reads/writes, because it's running with the privilege of the VM, not the limited powers of the WASM code running within it.
    - mccr8 10y ago
      We have extensive leak checking in our testing for Firefox, so hopefully the JS engine is not "very leaky". One part of Quantum, which does not have anything to do with Rust, is to figure out how we can spend less time running unimportant JS (like maybe in a background tab), which will hopefully reduce CPU usage.
    - Cshelton 10y ago
      I wonder if it would be possible to write a JS engine in Rust that would essentially make multi-threading JS possible... Use Rust's concurrency safety to pass resources around threads running JS. Doing this without making any changes to JS. Of course Node would then also be obsolete...
      - yazaddaruvala 10y ago
        I consider the lack of parallelism[0] in JavaScript as a feature of JavaScript. [0] Note: parallelism is not the same as concurrency.
        Manishearth 10y ago
        JS does have proper parallelism, workers can run on separate threads and could be run on separate processors. There aren't as many primitives for dealing with cross-worker communication, but some exist and it's usable.
        yazaddaruvala 10y ago
        JavaScript does not have parallelism! Browsers implement web workers and a "system call" which lets users initialize them through JS. A different implementation/deployment environment like Node does not have web workers. Through native modules, Node can have parallelism, but this is not a part of the language and Node isn't subject to implement web workers to be considered "running JavaScript". However, regardless of this JavaScript continues to have concurrency without parallelism. It would have been more accurate for my last message to have said: "I consider the lack of parallelism in JavaScript a feature given that it continues to have concurrency by default". Similarly, I'd argue that C does not have parallelism (just system calls ...), but C doesn't even have concurrency. As such I do not consider the lack of parallelism a feature of C.
        Manishearth 10y ago
        I guess. I was thinking from the POV of web browsers.
    - ibotty 10y ago
      Js engines are really fast. The stuff they run is bad.
  - geodel 10y ago
    Yes, nowadays I think it is a fact of life like death, taxes etc.
  - flukus 10y ago
    I'm hoping it spurs a resurgence in real desktop apps, then we shouldn't have to worry about bloated javascript.
    - hvidgaard 10y ago
      I think people forget the rather overwhelming amount of crappy bloated desktop apps we had (and still have). There isn't anything inheriently bad with JavaScript. Webapps have strong points, and weak points, and should be used where it makes sense. But the developers developing bloated code are most visible in the last shiny thing, which happens to be web and JavaScript. Before that it was mobile apps.
- ComputerGuru 10y ago
  Rust is neither faster nor more efficient than C++.... its benefits lie elsewhere.
  - callahad 10y ago
    While literally true, Rust's benefits make it easier to write safe, parallel code, which often directly translate into greater speed and efficiency.
  - barrkel 10y ago
    It's more subtle than that. Different languages promote different idioms, in particular via their standard library. C++ is particularly unusual in that you don't get much out of the box, and in older projects even things like strings and containers are often custom-built. The combination of language and library provide affordances that make some idioms easier to represent, and others harder. This influences the design of code written in the language. Clumsy idioms generally don't get far, even if they would be more performant or provide some other benefits, like promote easier concurrency. And sometimes there's a tension: e.g. mutable structures tend to be more performant but harder to add parallelism to, and harder to reason about (leading to more copying than strictly necessary). Rust in particular has different ideas here. I think the jury is still out on whether Rust will in practice tend to promote code that is faster or slower than C++. Of course any given project in Rust could be rewritten in C++ to be just as fast, or perhaps faster. But that's not what happens in the real world. Human factors matter, path dependence matters, affordances matter.
  - Cshelton 10y ago
    Rust should be just as fast as C++ and C. Benchmarks are hard of course because optimizations and such. But if Rust is significantly slower, than it is a bug.
    - ComputerGuru 10y ago
      I think you may have misunderstood my comment, as I did not mean to disparage Rust's speed nor imply it was slower than C/C++. Rust, at best, can match C/C++. But Rust cannot be faster than C/C++; therefore, by function of simply being rewritten in rust (and not because it was rewritten), that does not, in and of itself, make the resulting executables faster.

Even though the title might disappoint, it's super interesting to see where Firefox is going. I can't wait for 2017!

by mxstbr 10y ago

Even though the title might disappoint, it's super interesting to see where Firefox is going. I can't wait for 2017!

Looking forward to it too; this is a big deal because it will put a Rust implementation on many millions of desktops. I'm totally fed up with CPU and memory hogging browser bloat on my laptop. My dev env runs so much better when I kill all Chrome processes. I know that the article is only talking about the render engine, and not JavaScript, which I suspect is the main browser bloat culprit , but I'm still hopeful. Bring on the Rust JS engine I say!

hvidgaard 10y ago
It's not going to change that. No matter how efficient you make the JS engine, crappy JS will still steal all your ressouces.
- osullivj 10y ago
  Yes. However, a crappy, leaky, JS engine running crappy JS code will steal all resources even quicker. I hope a JS engine built with Rust smart ptrs will be less leaky than one built in C/C++. In my experience, hand rolled memory pooling systems can be very leaky.
  - gsnedders 10y ago
    There's no plan to write a new JS engine at Mozilla, FWIW.
    - Cshelton 10y ago
      And they shouldn't...let's move forward... to WASM (Web Assembly)! Which, also posted on front page of HN recently, a user's medium blog on compiling Rust to WASM. https://medium.com/@chicoxyzzy/compiling-rust-to-webassembly-guide-411066a69fde#.r8qex53c3 https://medium.com/@chicoxyzzy/compiling-rust-to-webassembly...
      - gsnedders 10y ago
        Except, like, JS isn't going to die any time soon, and realistically, implementing a new JS or WASM VM isn't actually that interesting to do: the big risk in a JITing VM that Rust cannot save you from is behaviour of your JITed code, which makes memory safety far harder to enforce.
        Cshelton 10y ago
        Right, JS isn't going anywhere. But once WASM is able to run everywhere, anybody attempting to make high performance web apps would ideally want to write it in WASM. A lot of what JS does on the web is plenty fast and won't really benefit much from JS being multi-threaded/faster. Sites using JS to run simple scripts or to fire api calls/etc. will continue to use JS, no reason to use WASM. Also, I believe WASM is truly compiled code and not JIT ran? I may be wrong...but pretty sure that was the whole point of creating it. Native app performance in the browser... that will take a big bite out of the app stores that take a good cut of revenue and control what can and can not be in the store. And sure, WASM can also have memory safety problems, especially with C/C++ being the primary languages to target WASM from. But that's also where Rust would shine, making it much more safe when compiled to WASM.
        gsnedders 10y ago
        WASM isn't machine code: if it were, it wouldn't be universal which is a fundamental requirement of the web. (Well, okay, it's compiled code—it is, after all, compiled from C/C++/etc., but in the same way JS is compiled to byte code in VMs today.) As such, there's a further compilation step needed from WASM to machine code to get near-native performance out of it. The existing WASM implementations do a mixture of JITing code at load-time and JITing code at first-call, depending on the size of the WASM blob, AFAIK. The gain performance wise over asm.js is primarily in parse-time, as far as I'm aware. WASM VM itself is perfectly possible to be memory safe: WASM code cannot read outside of the memory allocated to it (and malloc/free are implemented on top of that memory allocated to the VM, hence there's memory safety at the VM level). The big problems come when you need to guarantee your JIT code doesn't violate memory safety, and that's something Rust's type system cannot (currently) solve. You need guarantees that the generated code will never have any memory access errors, and will never race for memory reads/writes, because it's running with the privilege of the VM, not the limited powers of the WASM code running within it.
  - mccr8 10y ago
    We have extensive leak checking in our testing for Firefox, so hopefully the JS engine is not "very leaky". One part of Quantum, which does not have anything to do with Rust, is to figure out how we can spend less time running unimportant JS (like maybe in a background tab), which will hopefully reduce CPU usage.
  - Cshelton 10y ago
    I wonder if it would be possible to write a JS engine in Rust that would essentially make multi-threading JS possible... Use Rust's concurrency safety to pass resources around threads running JS. Doing this without making any changes to JS. Of course Node would then also be obsolete...
    - yazaddaruvala 10y ago
      I consider the lack of parallelism[0] in JavaScript as a feature of JavaScript. [0] Note: parallelism is not the same as concurrency.
      - Manishearth 10y ago
        JS does have proper parallelism, workers can run on separate threads and could be run on separate processors. There aren't as many primitives for dealing with cross-worker communication, but some exist and it's usable.
        yazaddaruvala 10y ago
        JavaScript does not have parallelism! Browsers implement web workers and a "system call" which lets users initialize them through JS. A different implementation/deployment environment like Node does not have web workers. Through native modules, Node can have parallelism, but this is not a part of the language and Node isn't subject to implement web workers to be considered "running JavaScript". However, regardless of this JavaScript continues to have concurrency without parallelism. It would have been more accurate for my last message to have said: "I consider the lack of parallelism in JavaScript a feature given that it continues to have concurrency by default". Similarly, I'd argue that C does not have parallelism (just system calls ...), but C doesn't even have concurrency. As such I do not consider the lack of parallelism a feature of C.
        Manishearth 10y ago
        I guess. I was thinking from the POV of web browsers.
  - ibotty 10y ago
    Js engines are really fast. The stuff they run is bad.
- geodel 10y ago
  Yes, nowadays I think it is a fact of life like death, taxes etc.
- flukus 10y ago
  I'm hoping it spurs a resurgence in real desktop apps, then we shouldn't have to worry about bloated javascript.
  - hvidgaard 10y ago
    I think people forget the rather overwhelming amount of crappy bloated desktop apps we had (and still have). There isn't anything inheriently bad with JavaScript. Webapps have strong points, and weak points, and should be used where it makes sense. But the developers developing bloated code are most visible in the last shiny thing, which happens to be web and JavaScript. Before that it was mobile apps.
ComputerGuru 10y ago
Rust is neither faster nor more efficient than C++.... its benefits lie elsewhere.
- callahad 10y ago
  While literally true, Rust's benefits make it easier to write safe, parallel code, which often directly translate into greater speed and efficiency.
- barrkel 10y ago
  It's more subtle than that. Different languages promote different idioms, in particular via their standard library. C++ is particularly unusual in that you don't get much out of the box, and in older projects even things like strings and containers are often custom-built. The combination of language and library provide affordances that make some idioms easier to represent, and others harder. This influences the design of code written in the language. Clumsy idioms generally don't get far, even if they would be more performant or provide some other benefits, like promote easier concurrency. And sometimes there's a tension: e.g. mutable structures tend to be more performant but harder to add parallelism to, and harder to reason about (leading to more copying than strictly necessary). Rust in particular has different ideas here. I think the jury is still out on whether Rust will in practice tend to promote code that is faster or slower than C++. Of course any given project in Rust could be rewritten in C++ to be just as fast, or perhaps faster. But that's not what happens in the real world. Human factors matter, path dependence matters, affordances matter.
- Cshelton 10y ago
  Rust should be just as fast as C++ and C. Benchmarks are hard of course because optimizations and such. But if Rust is significantly slower, than it is a bug.
  - ComputerGuru 10y ago
    I think you may have misunderstood my comment, as I did not mean to disparage Rust's speed nor imply it was slower than C/C++. Rust, at best, can match C/C++. But Rust cannot be faster than C/C++; therefore, by function of simply being rewritten in rust (and not because it was rewritten), that does not, in and of itself, make the resulting executables faster.