Sometimes people are surprised that our muvm stack for Asahi Linux runs everything as emulated x86/x86_64 code, including the whole Mesa graphics driver. Yes, an Apple GPU driver compiled for Intel! That must be slow, right?

But... Rosetta on macOS does the same exact thing!

Why do we know? A few reasons, but one important one is that Apple implemented some custom x86 compatibility features in the M1 CPU as global, privileged switches, which cannot be changed without going through the kernel (which is too slow to do often). This means that a Rosetta process on macOS can only run x86_64 code (under a purpose-built emulator), it is not compatible with standard ARM64 code! In particular, NEON behavior is different in an incompatible way.

This is also why FEX can't use that particular feature, because it does rely on standard ARM64 infrastructure and libraries, and those would not work in that mode. We'd need a statically compiled FEX with it and every dependency built with a custom compiler ABI/mode. On the flip side, FEX does support running the GPU driver and a few other cherry-picked things as native ARM64 code, and we'll support that eventually.

I believe the M4 implements a standardized version of this x86 compatibility feature, which does allow changing the behavior at runtime efficiently so it can be used by FEX with mixed emulated x86_64 and native arm64 code.

@erincandescent Maybe we should call them "single-threaded memory safety" and "concurrent memory safety"?

It's a pretty big distinction though, because most complex programs these days are multithreaded! Having single-threaded memory safety is definitely better than not, but can't really provide any hard guarantees once you throw threads in the mix.

I've seen this one come up a few times in PL threads too... despite what some believe, Go is not a memory safe language!

Specifically, Go is not memory safe if your program uses goroutines. Go does not protect against data races, which trigger UB and memory unsafety.

See: https://go.dev/doc/faq#atomic_maps
Also: https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html

This is unlike Java, Python, and I think C# too, which do guarantee no UB or memory safety issues even if you don't handle concurrency properly.

Safe Rust is technically in the same camp, but better in practice because it tends to push you towards writing race-free code.

On the Zig vs. Rust debate, people like to focus on memory safety, but Rust's RAII is just as important to writing clean, maintainable code.

There is something truly magical about seeing my GPU driver cleaning up dozens of nested GPU and host objects when the GPU job completes. Always exactly then, never too early, never too late, never leaking anything. That's all thanks to RAII and automatic Drop calls.

`defer foo.deinit()` really doesn't cut it. You have to explicitly write it, and it only works if all code paths free the object at the end. `errdefer` is just a special case, and then the only way to know if you forgot it is by testing with a leak checker. And then the deinit function has to manually deinit all child objects.

All this stuff is just done automatically in Rust. Most of my types don't even implement Drop, or only do something trivial there, because the compiler recursively dropping objects is 99% of the work.

It's *knowing* the compiler is on your side and taking care of all this that makes it magical. If you have to write out the code by yourself, that's more work, and a huge chance for bugs. The compiler is doing some very complex tracking to figure out what to drop when and where. You'd have to do that all in your head correctly without its help.