Unison Cloud

Hi, one of the Unison creators here. We've held off working on FFI until the JIT compiler[1] is completed since FFI is closely connected to the runtime.

There's some interesting subtleties with FFI in a distributed programming language, so I'll ramble about that here in case it's interesting to you. :)

So, in Unison, all values are serializable, including functions and their dependencies. This is a key superpower that enables a lot of the neat stuff we do. As long as those functions are written in pure Unison, we can easily serialize them, deploy them on the fly, etc. But when we add an FFI, the story changes - the sender may have some C library in their environment, and that library may not exist at the recipient node. The two nodes could be different platforms, one Mac, one Linux, and the library may have been written specifically for Linux, say!

So when we add FFI, we will likely be doing it in a different way than most languages. Functions that use FFI will have this tracked in the their type, using our effect system. You'll be able to use whatever C libraries you want in your local computations, but if you want to sent those values around, you need to be sending them to a place that supports that same set of FFI effects, since the C library and its dependencies can't literally be deployed on the fly in the same way as pure Unison code. In our cloud platform, nodes are typed based on what effects they support and we'll probably add a way to create new node pools that have access to whatever C libraries you want.

In "regular" programming, we're not used to thinking about "the execution environment" as a thing that's represented explicitly within the program. Instead, there's an assumed execution environment (which includes the set of native libraries, etc) and you get runtime errors if you run a program and some of the assumed execution environment is missing (like a shared library, say). For the most part, people have been okay with this, but it's already somewhat of a problem for languages that target the browser and the backend. The language may be statically typed, but now the type system is not tracking some key information - namely, is this a function I can call here (if I'm expecting this code to compile to JS) or is it a function that only can be called for backend code? In a distributed setting with heterogeneous nodes with different capabilities, this problem is even more pronounced, which is why we track this information in the types and plan to do so once we add FFI.

Hope that was interesting!

[1]: https://www.unison-lang.org/blog/jit-announce/ is an early progress report, and I think we're finally shipping something in the next month!

Unison user here - you might be right about having to learn the provider's ins and outs, the same way that if you're on AWS, you need to learn AWS lingo.

But with Unison Cloud, most of the complicated API is written as a library in Unison itself[0]. This `cloud` library is technically optional (and editable), and you can build and share your own abstractions as you like, so you don't have that hard rough edge between AWS APIs and your own code.

[0]: https://share.unison-lang.org/@unison/cloud/code/releases/9....

Proprietary as in you write your code for Unison Cloud, and have to rewrite the infra parts if you decide to self host.

This is why infra is decoupled from code and you need things like "deployments".

Is this 21st century COBOL? Some language with some open-spec, made actually to be running in some very closed environment via interactive environment, with no source control?

I've been using Unison over Christmas.

I'm not affiliated with the company at all.

I built the start of a very basic site with Unison and HTMX.

https://cross-stitch-alphabet.netlify.app

In my day job I'm a Rails developer. I've been consistently frustrated at how few languages are truly composable and been getting increasingly disillusioned with mainstream languages.

So that's my context.

The not so great:

The language and principles are hard to learn. I've had to throw away what I already know about a lot of programming.

Coding inside ucm requires a very different mentality to how we build software.

The tooling is still early days and has many rough edges.

Performance is currently poor but will get much better shortly.

Abilities are incredible but demand the user to be very familiar with recursion.

Like many on here, I have lots of questions. It's not clear how migrations will work. I don't understand BTrees. If unison corp goes under what happens to my code?

Now for the good.

Unison is, hands down, the most radically joyful language I've ever used.

It's caused me to realise that most tools we use in software are faulty primitive compared with what they could be.

The fact is that even the benefits in the marketing of Unison are a scratching the surface of what's possible in this language.

For example, by spending a few hours I made the basics of an end to end testing library that emulates HTMX with local function calls.

This, if fleshed out, would mean the holy grail for me - fast cacheable end to end tests that do not require a browser to be spun up.

The possibilities are mind boggling.

I was utterly delighted with the deploy in a single function feature, something I'm now never going to be able to go back from having.

And deploying a database with schema in two lines is just jaw dropping.

Every time I use Rails now it's clear how much better our coding experience could be.

By building in Unison you get ports and adapters for free. Never have to wait for a test suite again. No infrastructure as code. No JSON. No yaml. Bliss.

In summary, it's radical. Would I run a production system on it yet? Nope.

Would I watch it keenly until it amasses a bit more momentum? You bet.

I believe whether unison succeeds or fails, this is the future of programming.

Oh and they're a delightful group of people to be around. The discord community has been beyond supportive to me whilst learning the language.