tedmielczarek

I've heard about this being a known issue with cars from other manufacturers, so I can believe it. It's interesting that nobody thought to include a way to let the vehicle know it should stop trying to communicate to handle a potential end-of-service situation like this. It's fairly common for people to keep cars for more than a decade, they're a really expensive necessity for many.

I'd encourage you to read up on the component model. The talk by Luke Wagner linked in other comments is incredibly informative if you can make time to watch it. It's not about replacing WASI, it's about providing a coherent model for both implementing APIs like WASI and also providing structure and tooling for integrating codebases together in a sensible way using WebAssembly.

I saw him give this talk at a work event and I fully agree, it's incredibly informative and he presents the material in an engaging way!

We achieved this for Firefox macOS builds years ago. (Greg was there for that work as well. ) You do need to have an SDK accessible, but storing one internally and using it in CI was deemed acceptable. The impact on CI build times was hard to overstate.

We were already building our own clang binaries for various reasons, so it was mostly a matter of making an SDK available and ensuring that the right compiler options were passed in (since running clang on macOS sets a bunch of defaults that you don't get even if you pass -target x86_64-apple-darwin).

A lot of the weird bits in the Breakpad codebase were definitely from us finding extremely broken minidumps from Firefox users in the wild and then me tweaking the code to see if we could get something out of it so we had a chance at diagnosing the issue.

I integrated Breakpad into Firefox to replace the old closed-source Talkback implementation, we shipped it in Firefox 3. I suspect (but would have to ask Mark Mentovai to confirm) that Breakpad was probably written for use in the not-yet-publicly-announced Chrome. If so, that would mean that we shipped it first. :) I probably still have commit access to Breakpad, although I haven't contributed to it in years.

Original rust-minidump author here: I started out by doing a pretty straightforward port of Breakpad into Rust, which I had just started learning at the time. I figured that learning a new language by porting a codebase I was intimately familiar with for a content area that I knew extremely well would make it so only the new language was the hard part. (It worked out well!) I did try to make the API more idiomatic Rust in places, since there are parts of Breakpad's API that are fairly C++-centric. I was also using Rust 1.0 originally, so it didn't quite have all the niceties available in the current Rust release.

All that being said, I would choose Rust over C++ for any new development anywhere. If my boss told me we had to use C++ for a new project I would actually quit. I've worked on plenty of C++ codebases (including Firefox) in my career. Sure, you can write bad code in any language, but C and C++ are just bad languages.

(I also ported Mozilla's sccache tool from the original Python implementation to Rust, which was a fun exercise. The Rust version is in production use in a wide variety of places, and AFAIK is still the only ccache-like tool that can cache Rust compilation.)

You're right on the mark here. I saw rr used at Mozilla to diagnose and fix flaky tests that failed just often enough in CI to make life miserable, but were nigh-impossible to reproduce in a local development environment. Being able to take that to the next level and collaboratively investigate a bug using a recording that captures it is game-changing technology from the future.

Imagine a world where instead of ignoring, skipping, or marking "known failure" on all those flaky tests your CI hits (we all have them) you could capture recordings of them, and then actually investigate and fix them! That world is possible!

This seems like a very sensible approach. If you're using Rust in an existing Python codebase you might also be interested in trying out PyOxidizer, which has a few nice advantages and tackles distributing the resulting application as a single-file binary as well.

I think Zig is really interesting and has a lot of great ideas, some of which I hope Rust takes inspiration from. They've also done some difficult engineering work to make parts of the development experience feel amazing, like bundling clang and libc implementations for a variety of platforms so that cross-compiling works out-of-the-box. The Zig cross-compiling story is the best I've ever seen of any language, bar none.

That being said, I do think Rust's memory safety story is a game-changer for systems programming. We seem to be in a programming language boom, with lots of new and interesting languages being developed. I hope some of them iterate on the concepts that Rust has developed so we can do even better in the future! I don't think anyone involved in Rust would claim that it's the best we can do, or it solves every problem perfectly.

I agree with you but I don't think that entirely refutes the original point. Baking does require more precision on average than cooking, but bread recipes don't give you the information you would need to be precise. Adjusting for things like local temperature and humidity or the way your oven bakes are important to the outcome but they're never mentioned in recipes. What you're describing as "intuition" sounds to me like knowledge of those factors, some sense of measuring their impact (even if just by feel) and how to adjust a recipe as needed to account for them. I think we'd do a service to the world by pushing for recipes that are less "follow these directions exactly" and more "here are the techniques this dish uses and how to work with them".