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.

Even just a really rough "here our requests per second compared to Django, express.js and asp.net" Would be great to get a rough read on where it sits among other choices for web stuff.

More generally, I do hope this goes well for unison, the ideas being explored are certainly fascinating.

I just hope it one day gets a runtime/target that's more applicable to non web stuff. I find it much easier to justify using a weird language for a little CLI tool then for a large web project.

Very happy to see it finally hit 1.0

But the question is when that future will be.

Part of the beauty of these sorts of systems is just that the context of what your system actually does is in one system, you aren't dealing with infra, data, and multi-service layers

Maybe that means it is a much better foundation for AI coding agents to work in? Or maybe AI slows it down? we continue to try and throw more code at the problem instead of re-examining the intermediate layers of abstraction?

I really don't know, but I do really want to learn more about is how the unison team is getting this out in the market. I do think that projects like this are best done outside of a VC backed model... but you do eventually need something sustainable, so curious how the team things about it. Transparently, I would love to work on a big bet like this... but it is hard to know if I could have it make financial sense.

With all that, a huge congrats to the team. This is a truly long-term effort and I love that.

It’s a huge, all-or-nothing proposition. You have to adopt the language, the source control, and figure out the hosting of it, all at once. If you don’t like one thing in the whole stack, you’re stuck. So, I suspect all those interesting ideas will not go anywhere (at least directly; maybe they get incorporated elsewhere).

But I don't see any references to it anymore.

[1] A look at Unison: a revolutionary programming language:

https://renato.athaydes.com/posts/unison-revolution.html

I tried the unison vscode extension btw and despite ucm being on the path now it says: "Unison: Language server failed to connect, is there a UCM running? (version M4a or later)". I also seem to be required to close my ucm cli in order to run vscode because it says that the database is locked otherwise. And I guess there is no debugger yet? It just seems weird that I don't really know where my "project" even is or what this project model conceptually is. It seems like I just put all my unison code somewhere next to the compiler, it loads everything by default into the compiler and I merely do db updates into some kind of more permanent sqlite storage perhaps but then why do I even do that, wouldn't I still just put the .u files into a git repository? There is also no mention of how this language runtime works or performs, I'm assuming fully memory managed but perhaps slow because I'm seeing an interpreter mentioned?

I think you also really need a web based playground where you show off some of these benefits of unison in small self contained snippets because just reading through some examples is pretty hard, it's a very different language and I can't tell what I'm looking at as a lifelong C/Java/etc. tier programmer. Sure you explain the concepts but I'm looking for a far more hands on: "run this ability code, look: here is why this is cool because you are prevented from making mistakes thanks to ..." or "this cannot possibly error because thanks to abilities ..." instead of so much conceptual explanation: https://www.unison-lang.org/docs/fundamentals/abilities/usin...

https://github.com/bcpierce00/unison