[dom96]

> The thing is, programs that can be also written in GC powered languages, often don't need unsafe at all

That's true, though it's worth noting that they do still need unsafe for the FFI. Often this is where the memory safety issues arise in GC languages. So no language is truly "memory safe".

[pjmlp]

Which is why in some OS written in memory safe systems languages, like Burroughs, still being sold by Unisys as ClearPath MCP, any use of unsafe code blocks taints the binary.

Execution is only allowed after the OS admin adds the executable to a specific process white list.

This is similar to how some managed runtimes work, and the Java ecosystem is moving forwards it.

Currently it only triggers a warning, however in the future JNI and Panama will be disabled by default, and like with ClearPath MCP, it is up to the person installing the application to enable the unsafe layer explicitly.

Another example is the capabilities approach on WASM runtimes, here again the one executing the platform takes ownership on enabling unsafe behaviours.

[inigyou]

That's probably because the OS itself didn't have great defenses, right? We have permissioned virtual memory now.

[pjmlp]

It surely did, MMU were already a thing.

The customers that still buy such systems, care about security as the feature above anything else.

As you can see, the marketing is all about security.

https://www.unisys.com/product-info-sheet/ecs/clearpath-mast...