Unison is one of the most exciting programming languages to me, and I'm a huge programming language nerd. A language with algebraic effects like Unison's really needs to hit the mainstream, as imo it's "the next big thing" after parametric polymorphism and algebraic data types. And Unison has a bunch of other cool ideas to go with it too.

This isn't really what they're going for, but I think it can potentially be a very interesting language for writing game mods in. One thing about game mods is that you want to run untrusted code that someone else wrote in your client, but you don't want to let just anyone easily hack your users. Unison seems well-designed for this use case because it seems like you could easily run untrusted Unison code without worrying about it escaping its sandbox due to the ability system. (Although this obviously requires that you typecheck the code before running it. And I don't know if Unison does that, but maybe it does.) There are other ways of implementing a sandbox, and Wasm is fairly well suited for this as well. But Unison seems like another interesting point in the design space.

Still on the subject of Game Dev, I also think that the ability system might be actually very cool for writing an ECS. For those who don't know, an ECS basically involves "entities" which have certain "components" on them, and then "systems" can run and access or modify the components on various entities. For performance, it can be very nice to be able to run different systems on different threads simultaneously. But to do this safely, you need to check that they're not going to try to access the same components. This limits current ECS implementations, because the user has to tediously tell the system scheduler what components each system is going to access. But Unison seems to have some kind of versatile system for inferring what abilities are needed by a given function. If it could do that, then accessing a component could be a an ability. So a function implementing a system that accesses 10 components would have 10 abilities. If those 10 abilities could be inferred, it would be a huge game changer for how nice it is to use an ECS.

> Unison seems well-designed for this use case because it seems like you could easily run untrusted Unison code without worrying about it escaping its sandbox due to the ability system. (Although this obviously requires that you typecheck the code before running it. And I don't know if Unison does that, but maybe it does.)

Indeed we do, and we use this for our Unison Cloud project [1]. With unison cloud we are inviting users to ship code to our Cloud for us to execute, so we built primitives in the language for scanning a code blob and making sure it doesn't do IO [2]. In Unison Cloud, you cannot use the IO ability directly, so you can't, for example, read files off our filesystem. We instead give you access to very specific abilities to do IO that we can safely handly. So for example, there is a `Http` ability you can call in Cloud to make web requests, but we can make sure you aren't hitting anything you shouldn't

I'm also excited about using this specifically for games. I've been thinking about how you could make a game in unison cloud and another user could contribute to the game by implementing an ability as a native service, which just becomes a native function call at runtime. I started working on an ECS [3] a while back, but I haven't had a chance to do much with it yet.

[1] https://unison.cloud [2] https://share.unison-lang.org/@unison/base/code/releases/7.4... [3] https://share.unison-lang.org/@stew/ecs