The research site of Mozilla, covering Rust, browser engineering, machine learning, and policy reports on browser choice and operating systems.
HN commenters cite it for work like CRLite, DeepSpeech, and Firefox Translation, noting Mozilla has fewer resources than larger AI labs.
> The only big thing I can think of is the safety of compile-time type checking to ensure you won't end up with some kind of runtime error from mismatched types. Is there something I'm missing?
It's this but designs in statically typed languages with more expressive type systems tend to push a lot of the logic into the type system so you can't use APIs incorrectly. This isn't exclusive to Rust but I do have a few examples:
The Glium OpenGL wrapper puts a lot of effort into moving errors to compile time. The overview[1] explains a bunch of them.
[1] https://github.com/glium/glium#why-should-i-use-glium-instead-of-raw-opengl-calls
The Servo project uses the type system to tie rust code into the spidermonkey garbage collector so it can't be misused[2].
[2] https://research.mozilla.org/2014/08/26/javascript-servos-only-garbage-collector/
More abstractly, one of the more unique features of Rust's type system (linear types) is the ability to be sure a reference is destroyed. This makes Rust particularly good at describing state machines that are compile-time checked. Using standard OOP terms, each state is a class and its methods are the valid transitions. You can't take an invalid transition because the method is missing. You can do this in any language, though it tends to be only done in statically typed languages and it's awkward in Python. What makes Rust unique is that calling the method will consume the instance so you can't accidentally make a transition twice. Trying…
This article like many others is full of fallacies.
Image formats are not used wisely: [1] is PNG not JPEG and [2] is JPEG not PNG.
> I found that setting quality (mozjpeg) to 70 produces good enough images for the most part, but your mileage may vary.
You can get away with this setting for hidpi sizes but 1x will look horrible [1]. If you care about quality, the mileage is actually 75-95.
> (Pngquant) quality level of 65-80 to provide a good compromise between file size and image quality
Again, it may only be applied to hidpi sizes, and it will easily ruin any gradients or previously quantized images.
Pngquant is a great color quantization tool but it does not actually perform any lossless PNG optimizations, which can save you at least 5% more, and up to 90% in some cases.
All of these tools will also blindly strip metadata (but it's not guaranteed!) along with color profiles and Exif Orientation resulting in color shifts and image transformations respectively.
Most importantly, none of them are good enough for automatic lossy compression. Guetzli is the closest but it still has some severe issues [3]. I'm also trying to build a real thing, and it is hard.
> there’s value in using WebP formats where possible
WebP lossless and WebP lossy are quite different formats. WebP lossy being always 4:2:0 is not a good replacement for JPEG [4] especially at higher quality. On the contrary WebP lossless has evolved into a decent alternative for PNG including lossy…
> There is no signal to developers that an implementation is flawed, and so mistakes can happen without being noticed. That is, until a new version of the protocol is deployed and your implementation fails, but by then the code is deployed and it could take years for everyone to upgrade.
> If a protocol is designed with a flexible structure, but that flexibility is never used in practice, some implementation is going to assume it is constant.
Perhaps this is a naive thought. I remember several years ago Mozilla announced its experimental browser rendering engine (Servo) passed Acid 2 tests [1]. So why can't we come together and create such standard tests so that server implementers and middlebox implementers are encouraged to include them as part of their QA score?
I know this is an optional. There is no mandate, but it sounds like a start. Isn't there some network vendor organization the major players are part of?
[1]: https://research.mozilla.org/2014/04/17/another-big-milestone-for-servo-acid2/
Hm, are there any cases of two GC'd languages that interop well that were not designed to interop from day one (that is, JVM languages don't count)?
The only one that comes to mind is https://research.mozilla.org/2014/08/26/javascript-servos-only-garbage-collector/ , which is Rust (pre-1.0) and JavaScript, but that somewhat doesn't count because Rust isn't really a GC'd language. (This article was written about a year after the special syntax for garbage-collected references was removed and Gc<T> became just a thing in the standard library, and about a month before that type was also removed because it wasn't a very good GC.)
It seems to me that if you make your GC a purely refcounting system this is easier: you just need to specify how to incref and decref objects, and put a well-known function in the vtable for destroying and deallocating the object. I'd guess that's how things like GObject or Qt bindings in Python or similar languages work.
Mozilla did release DeepSpeech[0] and Firefox Translation[1] (the latter of which they included in Firefox, to offer client-side webpage translations.)
They definitely have fewer resources than OpenAI, and they do not produce SOTA research (their publications have plummeted to 1/year anyway[2]). So the only way for them to make progress is to seek government grants or make challenges like these.
This challenge is unlikely to be profitable for the winning team: the expected value of winnings are likely around $1K when taking into account the probability that another team gets a better rank, but ML research projects are often more expensive (recently, Alpaca spent upwards of $600 on computation alone; and of course pretraining large models is much more expensive). So the main gain will be publicity.
[0]: https://github.com/mozilla/deepspeech
[1]: https://github.com/mozilla/firefox-translations/
[2]: https://research.mozilla.org/
While it may not be an explicit goal, everything I’ve read implies that, for example the heading in this wiki on oxidization: https://wiki.mozilla.org/Oxidation
> Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.
And then there is the Rust page on Mozilla’s site:
> Mozilla also utilizes Rust in many of its core initiatives including Servo and key parts of Firefox.
https://research.mozilla.org/rust/
Where “key parts” is a link to the project quantum announcement: https://medium.com/mozilla-tech/a-quantum-leap-for-the-web-a3b7174b3c12
> Initially, Quantum will share a couple of components with Servo, but as the projects evolve we will experiment with adopting even more.