Code is not stored in multiple, seemingly unrelated text files in Unison. It’s stored in an actual database. One that you can only append to, … code is already stored in its type-checked, AST (Abstract Syntax Tree) form in that database, linked to other definitions by its hash.
At first thought this made me worry about my disk filling up with every version of every dependency ever — like when I installed the “only 3kb!” Preact library and node.js ate more than a gigabyte of space — but then I realized it’ll be deduplicated. And presumably Unison’s package manager would only download the exact functions being used, right?
All that, and algebraic effects too … I might have to get over my phobia of scary functional languages and try it.
I haven’t used node/npm much. In some ways they’re nice, but the explosion of dependencies is scary. Not just that using one library downloaded hundreds of modules, but that npm helpfully informs me that dozens of them have serious security issues and I should update them.
npm performs deduplication to the extent that it’s possible. You’ll end up with duplicates of different versions of a package if other dependencies don’t agree on which versions are acceptable. This seems like a decent compromise to me given how much of a pain manually resolving dependency conflicts can be in e.g. python, and how cheap disk space is. Do other package managers handle this in a better way?
About 15 years ago, I was working on an early version of CoreObject and persisted to disk every message (including arguments) that was sent to a model object so that you could completely replay the history of the object, with periodic snapshots to you didn’t have to replay the whole history. It really surprised me how tiny this was. After compression, it was basically free for text files. It also composed really well with non-destructive editing models. For things like images and videos, the history of the changes was tiny in comparison to the initial data and so it made sense to always store documents in this format.
We planned on using CoreObject as the model for language ASTs in Ètoilè, but never quite got that far before the project fizzled out.
…working with namespaces and forks, pulls, merges is confusing with git…
On the one hand, I recall reading somewhere that the idea of Unison (and Unison Share in particular) is to make Git mostly redundant since the AST is the basis of a version of some codebase and the human-written source is relatively ancillary. On the other hand, there are occasions where using Git is unavoidable. Case in point: Unison’s Exercism track. (Side note: They wrote the exercises themselves and multiple contributors have posted their own solutions, both of which are excellent.)
In spite of the confusion with the code manager (ucm), I still love the Unison language itself. The fact that ucm was apparently the hardest part of the language for me and the author to wrap our heads around is a testament to the design of the rest of it. I found the language itself to be a lot like Elm with the key differences of built-in algebraic effects—what they call abilities—and standalone binary compiler output. I also suspect that no matter how much the language’s authors improve ucm, there will still be some work on us, the language’s students, to understand its concepts.
At first thought this made me worry about my disk filling up with every version of every dependency ever — like when I installed the “only 3kb!” Preact library and node.js ate more than a gigabyte of space — but then I realized it’ll be deduplicated. And presumably Unison’s package manager would only download the exact functions being used, right?
All that, and algebraic effects too … I might have to get over my phobia of scary functional languages and try it.
Yes -
npmwarps the mind to think that packages have to be duplicated dozens of times locallyI haven’t used node/npm much. In some ways they’re nice, but the explosion of dependencies is scary. Not just that using one library downloaded hundreds of modules, but that npm helpfully informs me that dozens of them have serious security issues and I should update them.
npm performs deduplication to the extent that it’s possible. You’ll end up with duplicates of different versions of a package if other dependencies don’t agree on which versions are acceptable. This seems like a decent compromise to me given how much of a pain manually resolving dependency conflicts can be in e.g. python, and how cheap disk space is. Do other package managers handle this in a better way?
About 15 years ago, I was working on an early version of CoreObject and persisted to disk every message (including arguments) that was sent to a model object so that you could completely replay the history of the object, with periodic snapshots to you didn’t have to replay the whole history. It really surprised me how tiny this was. After compression, it was basically free for text files. It also composed really well with non-destructive editing models. For things like images and videos, the history of the changes was tiny in comparison to the initial data and so it made sense to always store documents in this format.
We planned on using CoreObject as the model for language ASTs in Ètoilè, but never quite got that far before the project fizzled out.
Sounds like the “fast-save” format in some early versions of MS Word.
On the one hand, I recall reading somewhere that the idea of Unison (and Unison Share in particular) is to make Git mostly redundant since the AST is the basis of a version of some codebase and the human-written source is relatively ancillary. On the other hand, there are occasions where using Git is unavoidable. Case in point: Unison’s Exercism track. (Side note: They wrote the exercises themselves and multiple contributors have posted their own solutions, both of which are excellent.)
In spite of the confusion with the code manager (
ucm), I still love the Unison language itself. The fact thatucmwas apparently the hardest part of the language for me and the author to wrap our heads around is a testament to the design of the rest of it. I found the language itself to be a lot like Elm with the key differences of built-in algebraic effects—what they call abilities—and standalone binary compiler output. I also suspect that no matter how much the language’s authors improveucm, there will still be some work on us, the language’s students, to understand its concepts.