Looking at the comments it seems that this talk might be a better introduction than just skimming at the landing page.<p><a href="https://www.youtube.com/watch?v=gCWtkvDQ2ZI">https://www.youtube.com/watch?v=gCWtkvDQ2ZI</a><p>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,<p>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,<p>* 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).<p>* Formatting is not a thing anymore. This goes further than just having a formatter as there's really no format nor names you can't personalize locally without affecting anybody.<p>* Similarly, renaming is free, so you can come up with better names in the future and chanting it just needs a tweak to the canonical name for the function.<p>* Functions are serialiazable, which makes it possible to send them to remote nodes for execution without any concerns about their deus, since a function is now more of a Merkle tree, so if there's any difference the client would know and be able to ask for missing dependencies<p>* The tool to manage your function repo might seem like a burden to some, but once you realize that having this as a first class tool that understands the language you can propose safe mass refactoring of code you don't own.
This looks attractive at first but it has one show-stopping problem AFAICT: if it turns out that a function has a bug, you can't fix it by changing the function definition. You have to create a new function <i>and then change every single call site from the old definition to the new one</i>.<p>Maybe there is a solution to this problem, but a cursory review of the language description didn't turn one up. It seems like a Really Hard Problem because there is nothing that can structurally distinguish between a new function that is created for its own sake, and a new function that is intended to be a bug-fixed (or otherwise enhanced) version of an old one.<p>Maybe a unison aficionado can enlighten me?
I worked using an object oriented database, where all code was stored as the AST as versioned objects in the database. Problems that I remember that might be relevant:<p>1. To “install” code into another instance, you usually exported your code as a massive text file from your dev server as source code, then import the source code as text into your production server. You could do individual functions, but that had a high risk of ending up with a pet with different code than your dev server. Version control was a mess.<p>2. We just ended up putting source code (without comments) directly onto production servers. That happened to turn out well for the client, and turn out badly for the development company (who owned the code).<p>3. Syntax or semantic changes to the language were a bitch when the database version needed an upgrade. Any existing code was migrated, from the old objects to the new objects, which sometimes caused problems.<p>4. Limited IDE. You had to use the IDE that came with the database, and various code transforms, global refactors, or normal development actions were unavailable. The primary other option was to export a complete syntax tree as text, make changes, then re-import (uggggh).<p>5. Debugging was hell.<p>Obviously Unison is a very different beast, but some of the above problems were a result of having the AST be the source of truth: problems which have the potential to apply to Unison too.
My experience with Unison so far has been limited to learning the basics and doing a few exercises on Exercism.io (big kudos to whoever added the Unison track there, it's a really great way to get your hand dirty with a new language!).<p>Coming from Haskell/other functional programming languages background, I have found many things familiar. Unison can be an improvement and an opportunity to do better this time.<p>What I still find lacking:<p>- developer experience and tooling: there's no language server (is it even possible for Unison?) or an easy development environment. I found myself confined to the usual vim+tmux+"repl" combo. A VSCode plugin that I tried was pretty basic, even though it showed the structure of code base and libraries nicely. Even Haskell is more pleasant with haskell-language-server these days.<p>- discoverability of library functions: skimming through modules, reading docs, trying to figure out what to use. Type-aware search (like Hoogle) is a great idea, but it does not replace the ergonomics of having context-specific completions. Having dot-namespaces relevant to a specific object (in OOP/Go/Rust style) makes this so much easier for me.
> Unison does away with builds. Completely!<p>> It has a canonical representation for all code,<p>Isn't generating that canonical representation the build step?<p>> The important thing is that now, I can actually compile and run this program<p>Now I'm confused whether there is or isn't a build step.
> As I write this in early 2023, finally, I think it has reached a level of maturity where it’s actually usable for real work, so I decided to write about my impressions using the language for something non-trivial.<p>For what non-trivial you used Unison for? Are you allowed to write about it?<p>Is that those examples in this Unison introduction article, or something else?
It will be interesting to see how it handles transitive dependencies through a supply chain you don’t control. Same issue as “this 3rd party npm package depends on an insecure version of X” but at a function level.
Integrate this with IPFS (or other DHT) and you have a distributed code database with the possibility of massively parallel builds.<p>(Assuming I understand the claims properly)
I started designing my own functional dataflow language to simplify distributed programming. It looks like I can stop.<p>Does Unison execute its DAG of functions concurrently by default?
> tests that run every single build even when nothing checked by them has changed<p>Oh yes, because we can always be sure that a change in one place will never cause a test in another place to fail.
Or just use your existing language of choice, but incorporate Nix (which is based on the same idea), or go all-in and use NixOS (or Guix, very honorable mention) to get the same ideas all the way to the bare metal of the hardware (which IMHO is where the reach of this idea belongs, it is that good)<p>For example, there are tools that convert traditional lockfiles to nix flakes.<p>Nix is more intimidating than it actually is. It’s basically JSON with pure functions and some syntactical-sugar shorthands that end up being very nice.<p>“Flakes” are basically lockfiles for Nix. Before Flakes, Nix still used hashed dependencies though. So everything you install with it is more or less guaranteed to also automatically pull in everything it needs to run, without conflicting with the needs of anything else.