tedmielczarek

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/

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!

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/

I haven't personally used Replay, but from my experience using rr (a native debugger that also provides time-traveling features) being able to replay execution both backwards and forwards in time on a whim is amazing. These tools excel at diagnosing bugs that are hard to reproduce, because you only have to reproduce the bug once under the debugger and then you can endlessly replay that execution until you figure it out. As Jason said above, you can retroactively add print statements in places that would be useful, without having to waste time trying to reproduce the bug again!

roc (the original author of rr) founded a company to build an even more compelling product on top of rr called Pernosco. They have some mind-blowing demos I'd recommend you check out: https://pernos.co/ .

Being able to easily answer questions like "where did the value in this variable come from, and when did it get set?" makes debugging a wildly different experience.

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.

Rust was originally built with green threads. The RFC that proposed removing them has an extremely detailed explanation of why the change was made pre-1.0: https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b...

I think this has proven itself to be the right decision. It's one of the main reasons that Rust works so well alongside other languages—there's very little default Rust runtime that complicates interop. There are also lots of programming scenarios for which green threads are not the right tool, and Rust accommodates those.

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".

Having worked with him at Mozilla I can assure you that he is familiar with Rust. I'm as much of a Rust fanboy as anyone, but "rewrite it in Rust" is not a simple process, and there are many tradeoffs involved. That being said, I think Rust will continue to improve on this front. Things like the GCC Rust frontend work are promising avenues to expand Rust's reach in terms of supported platforms, and tooling like c2rust will make rewrites simpler. There are also techniques like `RLBox` now that allow compiling C code to WebAssembly and running it in a sandbox which offer mitigation strategies without a full rewrite.

The biggest limitation for embedded Rust development tends to be "does LLVM support your CPU?" If not you may be able to hack something together but you're not going to have a great time. If so, there's still a broad range of experiences between "people are actively writing Rust for this board and there are tons of crates exposing the hardware with nice APIs" and "you can get Rust code running on this board". I'm not an embedded developer but I've dabbled enough in the space to believe that Rust is going to do very well there. The development experience is so bad for most existing cases and there aren't a lot of other viable options (unlike for folks writing desktop or server software).

Here's the thing these arguments always miss: writing C/C++ is like writing your entire Rust program using unsafe. Sure, unsafe Rust code will always exist and can cause memory safety bugs. It's a lot easier to verify a few unsafe blocks in a Rust program than it is to keep all of your C++ program's invariants in your head and manually make sure you don't violate them.

Having been significantly involved in the work to integrate Rust into Firefox I can say that while it's definitely nontrivial it's absolutely worthwhile. Every C++ developer I knew at Mozilla that took the time to learn Rust wound up being impressed with it and preferring to write Rust over C++.

To be clear here, while Servo is a wonderful project and was definitely pivotal in making sure that Rust was useful for building real-world software, calling it "widely-used" is a bit of a stretch. The individual crates that were written to implement pieces of Servo have found widespread adoption, but Servo itself was not something that had millions of users. (n.b.: we did ship Servo's style engine in Firefox as part of Quantum, but that was just one piece of Servo.)

Mobile development still has some unfortunate features, like Apple's App Store guidelines limiting the types of apps you're allowed to distribute there, and ever-changing requirements that mean that apps that don't get updated for newer OS releases (even if the app is otherwise fine) get removed from the app store.

Even with that, mobile is where all the users are nowadays. Traditional desktop/laptop computing is not a growth market. If you want to build software that lots of people will use you want to build it for mobile platforms. Smartphones are also ridiculously overpowered at this point, so you do have the resources to make pretty compelling experiences unlike with what you'd think of as a traditional embedded system.

I believe so, yes, but we have customers that wanted to ship their apps as bitcode (for reasons I'm not aware of) so we need to include bitcode in our framework to support that.

> Have you considered the recent alternative, smol [1]?

I've been reading Stjepan's articles and am very interested in what he's doing but we haven't seriously looked into alternatives yet. He reached out to me after this post went live and I've promised to follow up!

> Do you have any plans to share source or build scripts for the glue components?

We'd like to open source bits of our work that are separable and useful to others but often glue code and build scripts fall way short of that because they're very much tied into our specific arrangement. I'm not sure there's much there that's novel in any event, it's mostly just using the set of crates I list in the post in the standard ways.

> How have you been able to incorporate native functionality such as media codecs and screen capture with shared logic written in Rust?

We don't handle video currently AIUI so we haven't had to deal with codecs. We primarily try to put platform-specific integration code in the platform-native part of the codebase, which is ObjC for iOS and Java for Android, and transform things down to a more straightforward form like byte buffers to hand off to Rust.

> Has Rust worked well when you also need to integrate with runtimes such as React Native or Flutter?

We have some React Native support and it hasn't been any worse than supporting the other toolkits we support. I don't think we have Flutter support in a place where I could speak usefully about it.

I think the build system side is still a bit rough around the edges. It's not hard to get something working, as your examples show, but I haven't seen a solution that feels really well-integrated yet. I'm hoping that tools like bazel/buck/pants continue to get more useful and can provide that kind of experience.

Thanks for the feedback! You're right that describing our usage a bit better might have helped clarify our thinking. For the record: the FullStory product is a session record and replay tool for both web and mobile. We record details about how your users interact with your site or app and you can watch replays of them as well as get analytics across sessions. Privacy is important to us, which you can read about here: https://bionic.fullstory.com/private-by-default-mobile-analy...

The bulk of what we're doing in Rust is data serialization, along with business logic, part of which is a state machine and part of which is applying specific rules to app content. We did have fully native implementations of this in our prototype. Supporting two parallel implementations would be way harder for us than supporting our Rust implementation. It's hard enough to support the code that's platform-specific by necessity!

I think like so many things we tend to turn programming language discussions into something akin to discussing religion. I really like Rust but that doesn't have to take anything away from other languages. I'll have to take a look at Nim at some point, it sounds like it has a lot of nice qualities! I really love that we're in what feels like an explosion of new and exciting languages to work with. I don't think Rust is the pinnacle of language design, so having more languages explore the space of possibilities is great!

With all that being said, when it comes to choosing a language for use in a business context the popularity of the language absolutely does matter. It has an impact on your ability to hire programmers, find packages to solve the problems you have in the language ecosystem, and have tooling that meets your needs, just to name a few. Now there is definitely a chicken-and-egg problem here as someone mentioned in another comment, in that you need adoption to drive adoption.

I'd advise you to try not to take these things personally. If you love Nim focus on doing cool things with Nim and making the Nim community a great place to be.

I don't think this really solves any problems for us unfortunately. The core of the bitcode problem is that you need the rustc you're using to have the exact same version of LLVM as the Xcode toolchain you're using, since bitcode is a not-entirely-stable internal LLVM format. Cross-compiling to most mobile platforms is actually pretty straightforward with Rust.

I don't think there's a bright line dividing systems programming problems between GC and non-GC languages. We use Go extensively at FullStory and it works great for a large class of problems. Rust has a compelling story for spaces where GC makes life harder or just isn't feasible. I will say that Rust being usable without GC does seem to put it in a better position around interoperability than languages with a GC, since composing language runtimes and GCs properly is a really challenging problem.

(Hi!) I agree the bitcode situation with Rust is painful. Our SDK isn't open source so we're able to sidestep a lot of that pain but we still do have to be mindful of interop issues with the LLVM version we use to build our SDK and the XCode version our customers use to build their apps. It would be nice if Apple and LLVM committed to some bitcode stability guarantees that would make a this easier to handle.

> Sounds like they could have had the same things with a much easier language like Nim. Unless they are using a lot of Rust exclusive features?

I admit that I don't have more than a passing familiarity with Nim. Rust certainly isn't the only language targeting this niche nowadays, but it has done a lot of things right and we're not the only ones using it. There's no perfect language, they all have positives and negatives. Rust is still new enough that the ease of hiring developers can be a negative, so choosing an even younger language would further exacerbate that problem. Rust also has enough usage these days that we can get a lot of things from crates.io without having to write them ourselves. I don't know how Nim compares but it's pretty hard to get there without having enough adoption. Finally, Rust has had a bit of a trial by fire in terms of making it usable for integrating into existing codebases and shipping production code to users. I was at Mozilla and helped lead part of the Firefox Quantum work to integrate Rust into Firefox. We ran into a number of issues that we surfaced with the Rust team. Those issues generally were fixed in upstream Rust so everyone using Rust benefited from that work. I don't think that's too high of a bar for other languages to clear but it's a lot easier to recommend Rust knowing it has been through that already.

> How true is this?

I joined FullStory in December and some of my first changes to the codebase were large refactors, well before I understood how everything worked. None of them caused any major regressions that I'm aware of. My experience over 5 years of using Rust is that if you make the compiler happy you are pretty likely to have working code.