Since Volvo was mentioned in the parent comment, did you know that if you buy a new Volvo you can get two free plane tickets to Gothenburg + one night's hotel stay to go pick it up at the Volvo factory? You can drive it around Europe for a while and then they will ship it back to the US for you. AFAIK it doesn't cost extra, it just adds some lead time as well as time waiting for your car to get to you after you fly home: https://www.volvocars.com/us/l/osd-tourist/
Our family did nearly exactly this when I was a child in the 80s, just subbing in Volkswagen and Dusseldorf IIRC. It was some months later when the car actually arrived on the west coast of the US, but my parents seemed to think it worthwhile.
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.
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.)
> Sure, you can write bad code in any language, but C and C++ are just bad languages.
Let's give them credit for what we've achieved using them.
I would definitely pick Rust over C++ any time, I respect C++ for all the cool things it gave us.
I wish I could upvote this more than once :) The unsung heroes out there are the developers who takes over a garbage dump of a system and turn it around. That is way harder than writing a system from scratch.
Yep makes sense. My point was that the developers matter more than the language. However you are absolutely right that good developers with a better language will do better.
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!
I mentioned this in a different thread, but I'd recommend you take a look at Pernosco, a debugging tool written by the original author of rr: https://pernos.co/about/callees/
reply