> > But it would have bad ergonomics and still end up with a SecurityManager equivalent because a DSL for permissions is more convenient than doing it all in code.
>
> This might be the core contention. I don't know if using actual capabilities in a language would have problematically bad ergonomics. You'd probably be passing more arguments to functions. But haskell seems to manage ok despite needing to pass IO to functions that need it. Capabilities seem similarly inconvenient. I think I'd need to see it tried. I agree - I might need to try it myself.
One of the common objections I hear to Bluefin is "isn't it too inconvenient to pass around capabilities everywhere?". Perhaps surprisingly, no, I haven't found it remotely inconvenient. I find it liberating, actually.
In Bluefin, IOE (which allows you to do I/O, i.e. what Haskell's IO also allows you to do) is an argument, and therefore not a color under your interpretation.
I think nextaccountic is not technically fully correct, but he/she is at least correct in the most important part: Safe Haskell is not really practical.
But if you don't want an ironclad guarantee and instead you're content with making wrong code obviously wrong even if it's not formally verified, then I recommend Haskell with a capability system (what the Haskell world calls an "effect system"). As far is I'm concerned there are two practical choices in 2026, Bluefin (mine) and effectful (one of Bluefin's inspirations)
How does this compare to Spritely Goblins? I had a good chat with Christine about it at a conference. She said "Ah, you've been infected with the capabilities virus too. My condolences."
Interesting, I have not heard of Spritely Goblins! But neither Bluefin nor effectful could be described as distributed capability systems/effect systems, so I don't think they're comparable.
On infection, I think it's a bit like being infected by mitochondria :)
People don’t say "Haskell makes it impossible to write bugs"! You may have heard "if it compiles it works" which is somewhat tongue in cheek, but also true for a sufficiently loose interpretation of "works" in a way it is not true for languages with a less strong and flexible type system.
That looks really cool. Can you narrow Bluefin.IO to reads/writes separately? One of the things I've worked on is the ability to allow code to read files, even specific files, but deny writes.
Yes! It started as an implementation of the effect system I always wanted: effects passed on the value level, rather than implicitly on the type level. Once I'd done that I realise that it was actually a capability system (and that was the better way of describing it, because more people already know what a "capability system" is).
Here you go! It's a complete document, but I'll continue to edit it over the next few days before I announce it. I'd love to hear any thoughts you have.
I mean, there's certainly silly money involved, but there's surely no credible doubt that AI is already really good at many valuable tasks.
So if there's a crash, doesn't that just leave us with a bunch of useful AI hardware whose costs have been written off? I wouldn't have thought that much changes what social impacts AI is going to have.
reply