"Unison: a new distributed programming language" by Paul Chiusano

What Hacker News said

Strong rec reggieband · 2020-01 · on “The Unison language”

I recently came across Unison through YouTube recommending me a series of videos from the "Strange Loop" channel [1]. The fundamental idea of uniquely addressing functions based on a hash of their AST is mind-blowing to me. Immediately my mind started to consider many of the possible paths such an idea could lead down, many of which are clearly tickling the minds of many of the commenters in this thread. My first thought was the same insight from von Neumann architectures: code is data. So I thought of package repositories with URLs corresponding to hashes of function definitions. [LINK] could represent a specific function. A process/server could spin up completely dumb other than bootstrapp

Strong rec umvi · 2021-06 · on “Unison Programming Language”

I had a really hard time wrapping my mind around this just reading the website alone. If you are in the same boat, watch the first 10 minutes of this video at 1.5x speed: [this video] and it will make so, so much more sense. ...and if you are like me you'll probably need to read this twitter thread to get the answer to your #1 question: [LINK] Basically the core idea (or one of the core ideas) is instead of a function (like fib(n) which returns nth Fibonacci number) being identified by its name (fib) as is the case with most traditional languages, it's instead identified by a hash of its implementation.

Strong rec dietr1ch · 2023-01 · on “A look at Unison: a revolutionary programming language”

Looking at the comments it seems that this talk might be a better introduction than just skimming at the landing page. [this video] I watched that in 2020 or so and got amazed at how much a seemingly simple idea could work it's way into the core of a language. What I recall is this, The main new idea is turning codebases into a content-addressed store, this needs some new tooling, but makes a couple of interesting things possible, * Having different versions of the "same" function. They are actually different functions anyway, so you can do things like partial library upgrades when there's breaking changes. Large migrations like python 2 to 3 wouldn't take O(10yr). * Formatting is not a thing any

Recommends j1mr10rd4n · 2020-05 · on “Deno Is a Browser for Code”

I was just racking my memory and searching through my library of interesting links to find exactly this! Paul Chiusano gave a nice introductory talk at strangeloop last year: [this video]

Recommends nerdponx · 2021-03 · on “Semantic Versioning Will Not Save You”

Not necessarily the same thing, but have you looked into the Unison project at all? Unison is an open source functional programming language based on a simple idea with big implications: code is content-addressed and immutable. Homepage: [LINK] Strange Loop talk: [this video]

Recommends sullyj3 · 2021-08 · on “Defunctionalization: Everybody does it, nobody talks about it (2019)”

This seems like exactly the sort of issue the Unison language is trying to tackle. They want straightforward execution of distributed computations using the same language, with no friction across machine boundaries, no sacrificing composibility. The article mentions: > remote procedure calls with higher-order functional arguments would require serializing those functions, which is not easy to do safely or efficiently. This is exactly what Unison is designed to do. Code is not stored as text, but is stored in a serialized AST form and identified by hash. Therefore, transmission between nodes is trivial. The language is still a work in progress, but it's making rapid strides. Here's an explana

Recommends nimos · 2023-06 · on “Unison Language and Platform Roadmap”

[this video] This video is a little old but I remember finding it really interesting and I think dives into it a bit.

Cites tracnar · 2020-01 · on “The Unison language”

There's an example in this talk: [this video] Basically you can quote code (like in Lisp) and pass it to an executor (thread, remote server, ...). The main difference is that thanks to the immutability, you can also have a protocol which shares efficiently all the dependencies required to execute the code (like a git pull). It also uses an effect system, so the implementation does not need to decide which executor to use, it only uses an interface called an "ability", and the caller can choose the implementation.