71–80 of 197 posts
Earlier quoted context omitted.
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.
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.
For the produced binary packages (rpms, debs) it won't matter that much; although it will reduce build dependencies for source packages and give more consistent builds, even if your distribution comes with an _ancient_ version.
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.
SBT (scala) bootstraps itself in the same way. I think we're going to be seeing more of that going forward. For the produced binary packages (rpms, debs) it won't matter that much; although it will reduce build dependencies for source packages and give more consistent builds, even if your distribution comes with an _ancient_ version.
Earlier quoted context omitted.
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.
Going the long way is just a 'proof of concept' sort of thing. You could design a high-performance JIT around equivalent safety mechanisms, and even prove the tricky parts.
Earlier quoted context omitted.
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.
Going the long way is just a 'proof of concept' sort of thing. You could design a high-performance JIT around equivalent safety mechanisms, and even prove the tricky parts.
Earlier quoted context omitted.
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.
Going the long way is just a 'proof of concept' sort of thing. You could design a high-performance JIT around equivalent safety mechanisms, and even prove the tricky parts.
But note that a lot of security problems are not in the jitcode but rather in C++ implementations of JS objects and in the compiler itself.
Earlier quoted context omitted.
If you look on the Mozilla bug tracker you can look at a number of tickets open for integrating servo components into Firefox. For example Gecko is gaining support for Servo's style engine so maybe CSS will be the first large component merged. I wonder if Firefox will slowly become written in mostly Rust.
> 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.
Not in the core project: https://github.com/servo/servo
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.
SBT (scala) bootstraps itself in the same way. I think we're going to be seeing more of that going forward. For the produced binary packages (rpms, debs) it won't matter that much; although it will reduce build dependencies for source packages and give more consistent builds, even if your distribution comes with an _ancient_ version.
An analogue for rust would be something that detects the platform at runtime and then downloads a statically linked (?) binary that works on that platform. It can also exploit the ivy cache as the Scala compiler is just a library as far as SBT is concerned.
Isn't that a deal breaker? I would assume that downloading and checking in the binary for a whole compiler for 3+ platforms is untenable.
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.
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 :)