A look at Unison: a revolutionary programming language

> 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).

That wouldn't quite work, though, as Python 2 and 3 have mutually-incompatible ideas of what a sequence of bytes (string/binary) is; Unison solves the problem of references to code, but apparently not what happens when identically-typed data has different meaning between versions. At least, that's not answered in the video.

IIRC jonathan edwards had similar ideas in subtext (https://www.subtext-lang.org/)

all node based, name was just a property, changing it would reflect in all instanciations

This sounds almost like Dion. It would be cool to be able to feed the AST to a compiler backend like gcc/llvm and map to C's semantics.

* https://dion.systems/gallery.html

I stopped reading when they cried in joy at the ability to auto infer types instead of writing them. This has always led, in my limited experience, to unreadable code after 2 weeks.

Why do people want to write short leetcode, Ill never get it.

Well, you can say the same about git right? If you need to change an old commit, then you'd need to re-create all the commits that depend on it. Which is true, but something we leave to tools. In git we can just rebase or absorb.

In terms on how to distinguish functions, you could just have some suffix, like foo@base and foo@local.

I played a bit with Unison before, but I don't think I tried this. I'm sure it's a non-issue though because it's not hard to imagine how tools would help here.

I’m no aficionado but I believe this is handled by the code manager and not the language

https://www.unison-lang.org/learn/ucm-commands/#moveterm

Not a unison aficionado, but I believe this is an OK problem to have given that we already have to deal with a (weaker) variant of the same problem in every other PL: if your dependency has a bug, you/dependency vendors have to create a new version of that dependency and then change every single module that depends on it. The scale might be different, but the nature of this Really Hard Problem appears to be the same in both cases.

Also, it seems like a solution to the really nasty problem of changing transitive dependencies.

If the change you've made did not modify the type of the function, then updating all usages of that function is as simple as running "patch".

If you run "todo" it will show you everything that needs to be updated (thought it doesn't force you to update anything).

If you change the type of the function, you'll need to update all usages one by one, or choose to leave some usages with the old function (which may be desirable in some circumstances, e.g. where the bug you fix is never reached from that caller and you want to be maximally backwards-compatible)... UCM will show you everywhere you need to do that... you can get all references to a function before you modify it as well by running "dependents my-fun".

Here's a relevant excerpt from "The big idea" article linked in this one:

> In Unison, changing what names are mapped to which hashes is done with structured refactoring sessions, rather than the typical approach of just mutating text files in place and then fixing a long list of misleading compile errors and failed tests. A Unison codebase is never in a broken state, even midway through a refactoring.

> If your codebase is like a skyscraper, the typical approach to refactoring is like ripping out one of the foundational columns. The skyscraper collapses in a pile of rubble (a long list of misleading compile errors), and you attempt to rebuild a standing skyscraper from that rubble.

> The Unison approach is to keep the existing skyscraper around and just copy bits of it over to a new skyscraper, using a magic cloning tool. The codebase is never in a broken state. All your code is runnable. It's just that, midway through, you may not have fully constructed the second skyscraper and cut over all the names. Unison keeps track of that and gives you a tidy todo list to work through.

If there's tooling that can do this efficiently it sounds like it can be a win since all changes in implementation details become explicit and can potentially be more easily tracked.

It's trivial to find every possible call site of a function in a Unison codebase.

I agree that patching other people's code is not always possible, or easy. On the other hand, you can patch your own library using indirections to the new version.

The UCM tool propagates the changes for you automatically. It also creates a patch that you can distribute with your release to update any dependents automatically.

If the change can’t be made automatically because it breaks stuff, then UCM guides you through propagating manually.

You’d have to do this manual propagation in any language. Unison is a little nicer about it than most languages, since it just tells you what needs an update (and will suggest an order in which to make the updates) instead of giving you type errors or test failures.

1. A Unison codebase is a persistent shared data structure, which should be easy to integrate deeply with something like git or borrow ideas from it. Conceptually, it's just like a git repository.

2. It's possible to add an additional compilation step to generate (potentially obfuscated) machine code for a Unison AST. The same point applies to Javascript/Python or JVM bytecode.

3. Data migrations are an open question, yes. Still, Unison is a pure functional programming language and might do this much better than an imperative OOP language. Especially if you model your data as a shared persistent data structure too (like Clojure).

4. This is true, all the textual tools go out of the window without some kind of a translation layer. There are possible workaround like exposing a codebase as a FUSE filesystem. On the other hand, the codebase-as-AST makes it trivial to do code transforms, global refactors, etc, in a Lisp-style macro way, with its pros and cons.

5. I agree that debugging and execution observability is a must. The idea here seems to be "let's have a Haskell-like language that does not need much debugging in the first place". I am a bit skeptical of this approach in general, but it does make a lot of debugging go away.

Thanks for sharing your experience, many of the points are valid for Unison.

Good news, there is now a language server!

https://www.unison-lang.org/learn/usage-topics/editor-setup/

JavaScript doesn't have a build step either. sounds like it is interpreted and you reference methods by hash instead of by name. sorta?

I had the same confusion and re-read the article. Best I can understand, what they're trying to say is that it could be used without a build step in the sense that you could just manipulate the database's AST-like structure directly instead of compiling code, and it would be basically incrementally "compiling" each unit as you edit instead of interpreting a code file. But of course that's not a very ergonomic way to do it so there is a language on top, that they used as an example to show off the language.

I can see this being useful for implementing alternative editing interfaces besides just writing code textually. For example, flow-based visual programming or something like that. Adding and connecting nodes in a visual interface would each be small updates to the database, and then there would never be a "build step" because the database you've been editing is already the AST that could either be interpreted or compiled. So it only really does away with the parser, but that doesn't seem revolutionary to me, other languages can already do that. I might be missing something still.

You can think of it as an incremental build step but the crucial key that Unison's content addressing gives you is that canonical representation only needs to be generated once, ever.

So for example if someone publishes a library, no new build step would ever be required for consumers of that library.

Even with CI/CD there would be no build step because the very act of merging one's code into another codebase operates on canonical representations and so they never need to be regenerated.

Their slack is on the free tier, so I couldn't find a direct quote within the last 90 days, but this comes up from time to time. Last I heard it's not on the roadmap but there's interest.

I didn't think of it as paralell builds so much as a big patchwork quilt where some patches are data and others are code and you can kind of wander around and see which data is related to which other data through which functions.

I’m working on a low core project that is already using content addressable source code that is stored in IPFS at https://github.com/yazz/yazz so it can be done

Not when it's referentially transparent. In that case, there's no need to run the tests if a function or its children haven't changed. Of course, in that's the case, the tests are probably fast enough that running then won't matter much.

If you're working with pure functions, you can always be sure of this.

Removing layers of abstraction is necessary for building greater things on top. Not that Nix isn't better than what exists currently, just ideally the OS/language disconnect can be resolved, in line with Dan Ingalls. TBH I'm not really sold on Unison as a language, but the idea is certainly intriguing. Would be a lot more interesting if it was as at home in the browser as it is on unix - as it stands I don't see a real use case for it. Perhaps a killer app will come along, but I think for a language to succeed with this idea it will have to be a lot more pragmatic (aka further from Haskell). Time will tell.

can someone tell me what this is? this instinct to "one-up" posts?

"forget that, try this!"

"that's nothing, look at my favorite thing!"

this is rampant all the time in all posts no matter what they're about on this site and I do not understand it.

Root comments reminiscing about The Old Days also steal thunder from the topic and I don't understand why people do it.

start a post about Your Favorite Thing if you want to go on about it; please stop hijacking other threads because you wanna talk about Your Favorite Thing. let people talk about This Thing...

As someone who could reasonably be called a Nix zealot, who has just had to spelunk through far too many layers of abstraction and infrastructure to get some custom TLS certificates recognized on a macOS+Nix setup, I welcome attempts to simplify the stack rather than wrap everything.

Nix is great when you're on the happy path and its ability to offer a near-perfect reproducible environment right off the bat is unparalleled, I can't think of anything else that does nearly as well. But there are plenty of ways to fall off of the happy path, and when that happens it can be a fairly lonely or worrying experience.

Unison looks like it takes the whole development experience and owns it, and that allows for faster experimentation across layers of the stack. I think the implementation is pretty neat and I really hope they continue working on it.

> Nix is more intimidating than it actually is.

The intimidation is about learning it. That there is no (AFAIK) existing guide that is good enough to make it less intimidating. IE. it shouldn't be intimidating once someone writes a good intro to it.

Does anyone know a good introduction to Nix that uses the new better 'flake' based tooling? Just something simple, like to install a single package or setup a docker container.

It seems like Unison can reasonably memoize computations at a much more granular level than Nix. It bears some commonality with Skiplang.

When you use your nix-wrapped language of choice, do you nixify your unit tests so that their results are in the cache and don't need to be reran except partially when necessary?

AFAIK that's atypical, but if you've got it working please share a link.

Until Nix gets some kind of concept approximating interfaces such that the compiler can tell me "hey, you're missing this field to meet this interface" or "the shape of the argument for this thing is blah", it will remain a horrible experience in the same way that an exotic Ruby codebase is a horrible experience.

Everything is based on convention or code you have to go spelunking for.

Nix does not implement the same features of Unison at all.