There was a lot of work on this around the turn of the century

A minor gripe: that’s the same thing everybody kept saying the last time this became a popular research topic twenty years ago. It’s probably the same thing everybody on the iAPX 432 team said to each other 40+ years ago - I wasn’t around for that one. There are interesting ideas in the space, but prematurely declaring them the Next Big Thing helps nobody.

IMO the biggest challenge with bringing something like capabilities to Erlang-land would be the mismatched execution model: capabilities assume that code has no access by default but the BEAM explicitly rejects even isolating nodes from each other, nevermind processes on a single node. There’s been some discussion about filtering/firewalling but it’s a tough problem, especially to retrofit onto an existing runtime.

Re: Austral specifically, a couple things jumped out reading through the examples + issues:

• “no exceptions” is only technically true, as there are no user-observable exceptions and no mechanism for cleaning user-defined things up when something goes wrong. There’s still PLENTY of places that call abort and hard-exit from the OS process though, and even just writing a + b could lead to a runtime abort if the numbers are large…

• the first place that users might reasonably expect to encounter capabilities is when they want to print to the terminal, but Austral works around that because it would be too verbose

• another place to encounter capabilities might be when directly manipulating memory (for instance, type-punning with memmove) but that’s also side-stepped with a specific “are you importing the Memory module?” check

• borrowing is powerful, but also brings plenty of edge-cases. For instance, in the example “capability-based file API”, what happens if a Path value is created using the borrowed result of Get_Filesystem but the Path is still in-scope after Release_Filesystem has been called? Should a call to Read_File succeed, or crash? Can/should the compiler catch this? It may not even be an error - for instance, I could imagine a capabilities API where best-practice was to derive smaller capabilities at the beginning of a program and then discard the root capability, similar to how setuid programs “drop root” as soon as it’s no longer needed.

Based on the examples + the tutorial around capability-based security, my vibe is that Austral is a language where there could be interesting design possibilities; it seems like a reasonable foundation. But there’s a LOT of capital-H Hard design work still to come to make a usable API that avoids things like “pass your RootCapability to this random code, trust me bro” actually happen.

While a topic I need to take more time to explore, object capabilities sure are something we’re very interested to use in Bonfire (an Elixir toolkit for building federated/ActivityPub apps). Would love to see more activity in this space!