July 5th, 2024

Programming in Unison

Unison is a MIT-licensed programming language emphasizing immutability and database-based code storage. It simplifies distributed programming, supports easy renaming, and enhances testability and security. Challenges include limited interoperability and tooling development.

Read original articleLink Icon
Programming in Unison

Unison is a unique MIT-licensed programming language developed since 2013, focusing on immutability and storing code in a database rather than text files. It simplifies distributed programming and aims to streamline the development of distributed systems and web applications. Unison's distinctive feature is storing code in a machine-readable format, allowing for easy renaming without breaking functionality and enabling different versions of the same library to coexist seamlessly. The language uses abilities to manage code dependencies and interactions with the outside world, enhancing testability and security. Unison Cloud offers a platform for running Unison programs in the cloud, supported by a custom Cloud ability. Despite its innovative design, Unison faces challenges such as limited interoperability with other languages and the need to develop new tooling due to its database storage approach. The language is still in active development, with a focus on comprehensive documentation and maintaining backward compatibility. While Unison's future adoption remains uncertain, it showcases a novel approach to software development emphasizing collaboration with the compiler and unique code management techniques.

Link Icon 6 comments
By @sp33der89 - 3 months
Pleasant surprise to see Unison mentioned!

The developer experience in Unison(and Unison Cloud) has been wonderful for me. I try to write as much in it as possible, for hobby projects or side projects for friends and family.

Abilities(what Unison calls algebraic effects) are really ergonomic too use in practice, the learning curve is a lot lower than a IO monad datatype, and it reads just like Python when putting it to practice! Code-in-a-database means I don't have to fumble with long compilation times and Git, it brings joy to just hacking on to something in the weekend, because I just get to write code.

The article mentions its drawbacks, and they are real, especially FFI imo. The Unison team mentioned they are planning to include FFI, and it's going to be interesting to see what gets compromised.

But no other language (currently) hits this sweet spot of abstractions(not too little not too much) with an enjoyable DX, for me.

Docs being first class, go-to-definition and all that is one of my favorite things to show off when mentioning Unison: https://share.unison-lang.org/@unison/base

By @EdiX - 3 months
I've never used unison but I've used other, more traditional, REPL-based languages (think, Mathematica or Common Lisp with SLIME). To me one of the biggest problems with that style of programming is that sometimes code that you have changed on disk persists in the memory image, in the form of closures, creating unexplainable "ghost bugs" that disappear when you restart the REPL (or worse, that will only appear after you restart the REPL).

This system with making code immutable and storing it into a database makes me think somebody noticed how much of a footgun this behavior of REPLs is and thought... "mmmmhh what if we added a second barrel to the gun so that you can be sure to always shoot your own feet?"

By @pchiusano - 3 months
Hi there, I'm one of the creators of Unison, feel free to AMA!
By @LegionMammal978 - 3 months
Suppose that a codebase has two different functions with two different purposes, but they currently have the same implementation. (Say, the "factorial" function is used to implement that operator in a user-facing REPL, but also some growable-array implementation happens to use a factorial function for its allocation policy.) Then if one function starts needing a different implementation (e.g., a new allocation policy), then how do you reliably separate the two in this model? It would seem like there is no way to disambiguate a function apart from its current implementation.