tedmielczarek

Thank you for making that available! I understand why it's hard for upstream Rust to provide and I hope they'll find a solution eventually but until then not having to reinvent that wheel saved us a lot of time!

The latter is very achievable using the Relooper algorithm developed by Alon Zakai and described in the Emscripten paper: https://dl.acm.org/doi/10.1145/2048147.2048224

I don't think that's true. It was designed for its purpose by people that knew what they were doing based on experience gathered from implementing previous incremental steps including emscripten's original JavaScript output and asm.js (a formalization of some techniques emscripten employed). The design rationale is right there in the spec repository: https://github.com/WebAssembly/design/blob/master/Rationale....

It was built to be a better target than asm.js for compiled languages to run in JavaScript VMs and it seems to have succeeded on that front. That it's not a perfect fully-general bytecode format doesn't seem like a real knock against it, that's a much harder problem to solve. In any event it seems to be getting a lot more traction than any previous entries in the space, which is exciting!

gn is of course a meta-build system, the initials stand for "generate ninja". ninja does the actual build execution. The Firefox build system has a similar homegrown frontend called mozbuild, which generates Makefiles for the actual build.

A friend of mine has a similar project called PyOxidizer that's intended for building standalone executables with Python+Rust: https://pyoxidizer.readthedocs.io/en/stable/

His primary use for it is building distributable binaries for Mercurial, which is written primarily in Python.

It's not really written down anywhere but you can see the gory history of how we got it together in bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=921040

We used the MacOSX SDK from Xcode, packaged up into our internal file store for build machines to use and passed a bunch of compiler options that clang sets by default when you're compiling on macOS: https://searchfox.org/mozilla-central/rev/72e3388f74458d369a...

Getting DMG creation working was a bit of a hassle but we managed to get it done with some dmg/hfsplus tools from the iPhone jailbreak scene.

Hi! Post author here, happy to answer any questions. Part 2 of this blog post should be out next week, it'll get into some more specifics of how we're using Rust.

I dunno, personally I enjoy working with Matt and like that he feels this way about us. FWIW I don't really believe it's even possible to rank people based purely on talent. I worked with some incredibly talented engineers in my time at Mozilla and I came to realize that we all have our specialties and we work best by using our individual skills to work together. (I was a little fanboy-ish about working with Brendan Eich when I started but had my "aha" moment when he started asking me toolchain questions. :)

Very cool! Tangentially related, I looked into reimplementing `codesign` in Rust while I was at Mozilla. We wanted to see if we could take Apple hardware out of the loop for our release process after we had switched Mac Firefox builds to cross-compile from Linux. I got a bunch of code written and I'm pretty sure I could have made it work if I had gotten the go-ahead to spend time on it but then we heard about notarization and decided it wasn't worth the effort since Apple was going to require us to use their service anyway.

This mostly matches what I've come to believe over the course of my career with one slight tweak: also make sure that your code can handle the immediate next thing you know needs to be done. Don't try to plan any farther ahead than that because requirements change so often that you'll just waste time, but also don't write something so hacky that you'll have to do a bunch of rework to support the feature you know have to implement next week or month.

> For the very simple case of "I want a command-line option which specifies a path as an OsString", Rust’s way of doing things makes things hard. By comparison, in C++, I am used to dealing with paths as std::string on Unix and std::wstring or std::u16string on Windows, and this C++ approach is a lot easier.

FYI, you can convert an `OsStr` (or `OsString`) into a [`Path`](https://doc.rust-lang.org/std/path/struct.Path.html) with zero overhead and get all the useful things you want to do with paths: https://play.rust-lang.org/?version=stable&mode=debug&editio...

> Rust’s OsString design is too smart by half, and if I use env::args_os(), I can’t easily do simple tasks like "test if this string starts with '-'" or "split this string by the first '=', if it exists". As far as I can tell, the way to go is to convert OsString to Vec<u8>, do your processing there, and then convert back

For commandline arguments that you actually need to parse there's nothing wrong with asserting that you only accept valid Unicode, and then you can just use `to_str()`: https://doc.rust-lang.org/std/ffi/struct.OsStr.html#method.t...

If you have a `Vec<u8>` or `String` or whatever you can just treat it as an `OsStr` (with no overhead) because both of those (and a bunch of other things) implement `AsRef<OsStr>`: https://doc.rust-lang.org/std/path/struct.Path.html#method.n...

We're going off into the weeds here but in C this is implementation defined. In Rust you can use `#[no_std]` and the semantics are all well-defined. There's a thriving Rust embedded ecosystem that's doing just fine. Yes, the specifics of interfacing with hardware are platform-specific, but the language and the `core` bits (under `std`) are well-known.

Not in the language standard they don't, no. The C99 standard basically says "good luck with that":

"5.1.2.1 Freestanding environment

1. In a freestanding environment (in which C program execution may take place without any benefit of an operating system), the name and type of the function called at program startup are implementation-defined. Any library facilities available to a freestanding program, other than the minimal set required by clause 4, are implementation-defined.

2. The effect of program termination in a freestanding environment is implementation-defined."

There are obviously numerous embedded toolchains that provide facilities for writing C/C++ to target embedded systems but they're generally all doing nonstandard things and every one is its own unique fork of GCC.

The point isn't that it should be easy to do terrible broken things like this. The point is that you will encounter these things in the real world and have to deal with them in some way. Rust's OsStr[ing] let you do that. If you really have a burning need to create files whose paths are not valid Unicode you can do that in Rust but you will have to jump through some hoops. I don't see that as a problem.

I'm not sure there's a meaningful distinction to be drawn there for the vast majority of usage, to be honest. A language's standard library is generally considered to be part and parcel of the language. Everyone's first sample program is "Hello World" which involves printing text to standard output.

That being said, languages that do offer the ability to work without the standard library give you a lot of flexibility for places where you need it (like embedded systems). Rust has a pretty good story there. I don't think C or C++ really do.

There's an Embedded Rust working group currently, and they're doing some amazing things: https://github.com/rust-embedded/awesome-embedded-rust

James Munn gave a super interesting talk at this year's RustConf about some of the abstractions they're building for embedded systems: https://www.youtube.com/watch?v=t99L3JHhLc0

I think Rust is in a great position to become incredibly useful in the embedded space.

I checked and it's using Mozilla's DeepSpeech library: https://github.com/MozillaReality/FirefoxReality/blob/dee6f4...

which is here: https://github.com/mozilla/DeepSpeech

DeepSpeech is the actual voice recognition library, CommonVoice is a project to improve its accuracy by gathering more voice data.

Unfortunately the web platform has failed to provide a sensible way to embed HTML content, so images and videos are how people actually share things. You can take an image and save it to your device and share it to any social media service without doing anything special. You just can't get that experience with asciinema or any other sort of rich format. It's a real bummer.

I've met Chris and I told him that if I didn't live so far outside of the city I would be happy to pay him for service to my home. I have decent speeds through Comcast but their customer service is atrocious. Telcos have a monopoly in most areas and they know it and act accordingly.

The web is a complex platform, so it's definitely not hard to wind up using some feature that performs well in one browser but poorly in another. I don't know that it necessarily reflects badly on any individual browser--software is complex and it's hard to determine what combinations of web features will wind up being widely used. I do think it's a shame when this happens because sites don't get tested in anything but Chrome. There's no excuse when large companies release webapps and don't test in multiple browsers.

(Disclaimer: I work for Mozilla.)

I watched my kids figure out how to use a variety of Android and iOS devices they had never seen before when they were less than 2 years old, so I would argue that touchscreens are in fact more intuitive to use.

This is not entirely surprising, Rust's async I/O story isn't settled yet. tokio and futures exist, but there's some churn there that means it's a bit difficult to deal with at the moment. An RFC for async/await in Rust has been proposed and it's likely that that will be implemented this year, and then tokio should be reworked atop that, which should provide a good basis for things moving forward. It'll take some time for the crates ecosystem to settle around that, though.

> Why? Because underneath all that rust .... is an optimizing compiler, and it happens the author has decided to stay on the happy path of that.

There are two big differences here: 1) You're comparing "staying on the happy path" of a JIT compiler in the JS case, vs. an optimizing compiler in the Rust case. With the latter you can just compile your code and see what comes out and it tends to be fairly predictable. With the former, I'm not even sure there are tools to inspect the generated JIT code, and you're constantly walking the line of JS engines changing their heuristics and throwing you off the fast path. This was one of the primary motivations for the asm.js/WebAssembly work: the ability to get predictable performance.

2) Many of the optimizations mraleph performed were tricks to avoid allocation (which is normal optimization stuff, but more of a pain in GCed languages). In JS he winds up having to effectively write C-in-JS which looks pretty hairy. In Rust controlling allocation is a built-in language feature, so you can write very idiomatic code without heap allocation.

Software patents are bad and should be abolished.

We've had a blocklist in Firefox for specific DLLs that cause major issues (usually crashes) for ages: https://dxr.mozilla.org/mozilla-central/rev/574f4f58fe09dd59...

I assume Chrome is just planning to make that block everything that's not Google or Microsoft code, probably with a short whitelist of things that are necessary.

If you've got a specific site that this reproduces on that would be helpful. If you can also provide the model of the monitor you're using and the version of your OS that would help us track it down. Thanks!

Keep in mind that by parallelizing work the browser can finish the work it's doing faster, which means your CPU can spend more time idle, which is better for power consumption.

On the flip side, there's plenty of room for writing lots of shiny new stuff in Rust, which is a pretty unique Mozilla opportunity. :)

I live in rural Pennsylvania and Mozilla pays me quite well as a staff engineer, FWIW.

The redesigned Firefox for Android was roundly praised as the best Android browser for a while. (It's still very good!) It gained very little market share. Unfortunately it's very hard to compete with defaults these days without paying for distribution deals like Google is doing with Chrome.