That's what I'm calling capabilities at the application level (where you say "this .jar can't access the network"), rather than at the language level (where you say "this function wasn't given access to the network as an argument"). I don't think any widely known language has tried capabilities at the language level. (The language not widely known that does it is E.)
The real power will come when you can mix them. In one direction, that looks like `main()` not getting passed a `Network` object because the ".jar" wasn't granted network access. In the other direction, that looks like the system C library you invoked failing to access the network because when you invoked it from Java you failed to provide a `Network` object, so it was automatically sandboxed to not be able to access the network.
Emily took the approach of restricting a subset of OCaml, which they were running on Windows machines. No idea how tough it would be to get it running on a modern version.
Also for OCaml, the MirageOS unikernel is neat - develop on Linux etc., then recompile configured as a virtual machine with only the drivers (network, filesystem) needed by that one app. - https://mirage.io/
> That's what I'm calling capabilities at the application level (where you say "this .jar can't access the network"), rather than at the language level (where you say "this function wasn't given access to the network as an argument")
it wasn't, it was done at the type and classloader level
Seems like it is more oriented for LLM inference where it has ~80% higher memory bandwidth and ~30% higher memory and tensor core performance, and 100% increase in PCIe bandwidth.
Performance dont scale linearly especially in the same node. If you could get a top range Intel / AMD / Apple CPU to get 20% increase in performance for a 30% incase in power it is a massive win.
tomcat also gave different privilege levels to different parts of the classpath
nice idea, but didn't seem to work in practice