- Zig: Let's have a simple language with as few footguns as possible and make good code easy to write. However we value explicitness and allow the developer to do anything they need to do. C interoperability is a primary feature that is always available. We have run time checks for as many areas of undetermined behaviour as we can.

- Rust: let's make the compiler the guardian of what is safe to do. Unless the developer hits the escape hatch, we will disallow behaviour to keep the developer safe. To allow the compiler to reason about safety we will have an intricate type system which will contain concepts like lifetimes and data mobility. This will get complex sometimes so we will have a macro system to hide that complexity.

Zig is a lot simpler than Rust, but I think it asks more of it's developer.

All of these extensions are mandatory in the RVA22 and RVA23 profiles and so will be implemented on any up to date RISC-V core. It's definitely worth setting your compiler target appropriately before making comparisons.

That's what happens when you vibe code your app.

Knowing which is being spoken or heard is going to be hard.

It killed an aspect of it. The film processing in the darkroom. Even before digital cameras were ubiquitous it was standard to get a scan before doing any processing digitally. Chemical processing was reduced the minimum necessary.

I think this is backwards. Knowing that a signal is the clock, reset, data valid, adder result is far more important than the gate that drove it. The gates barely need names. Sadly, I think starting with that concept leads to a rather different language.

Labour generally has a "paternalistic authoritarianism" to they way they govern, but this is dialed to 11.

There's more than that. Zig has leak detecting memory allocators as well, but they only detect the leak if it happens. Nobody had a reliable reproduction method until recently.

You'll always get something like this:

``` 00000000 : 00 01 02 03 04 05 06 07 00000008 : 08 09 0A 0B 0C 0D 0E 0F ```

On a big-endian machine, when you wrote 0x1234 to address 0x0000000 you got:

``` 00000000 : 12 34 02 03 04 05 06 07 00000008 : 08 09 0A 0B 0C 0D 0E 0F ```

On a little-endian machine you have to either do mental gymnastics to reorder the bytes, or set the item size to match your data item size.

``` 00000000 : 34 12 02 03 04 05 06 07 00000008 : 08 09 0A 0B 0C 0D 0E 0F ```

If we wrote the bytes with the LS byte on the right (just as we do for bits) then it wouldn't be an issue.

``` 00000000 : 07 06 05 04 03 02 12 34 00000008 : 0F 0E 0D 0C 0B 0A 09 08 ```

Depends on the service, but tracking everything a user does may not be an option in terms of data retention laws

Not like Rust does, no, but that's the point. It brings both non-nullable pointers and bounded pointers (slices). They solve a lot of problem by themselves. Tracking allocations is still a manual process, but with `defer` semantics there are many fewer foot guns.

> I kind of doubt the Linux maintainers would want to introduce a third language to the codebase.

The jump from 2 to 3 is smaller than the jump from 1 to 2, but I generally agree.