Unison Language and Platform Roadmap(unison-lang.org)
unison-lang.org
Unison Language and Platform Roadmap
https://www.unison-lang.org/roadmap/
7 comments
Content-addressed ASTs make so many problems go away. No dependency hell. No merge conflicts. Fully incremental build, test, distribution, etc. Everyone can use their preferred formatting, or even their own syntax. I think the future of programming will involve this paradigm.
Just content-addressability isn’t enough, there should be also canonical forms, I.e.
h = hash(to_canonical_form(AST))
Preferably, there should be one-and-only-one way to perform or compute things, but modern PLs plagued by flexibility syndrome.
Also, the same should be done for the binaries, since the same AST may produce different binaries, unless you take into account all the compiler options, and runtime differences.
h = hash(to_canonical_form(AST))
Preferably, there should be one-and-only-one way to perform or compute things, but modern PLs plagued by flexibility syndrome.
Also, the same should be done for the binaries, since the same AST may produce different binaries, unless you take into account all the compiler options, and runtime differences.
I think this is impossible in theory (but maybe not in practice ;))
Determining if two programs are equivalent is generally as hard as running the programs for every input and comparing them.
Determining if two programs are equivalent is generally as hard as running the programs for every input and comparing them.
Yes, I'm talking about practical solutions, similarly like Halting Problem doesn't have a solution according to the CS, but there are practical solutions like the one used in Ethereum with its gas-based metering, or disallowing recursion or unbounded loops.
Some practical solutions:
- reduce code variability, by removing similar/alternative programming constructs / flexibility syndrome
- stick to a single programming paradigm
- remove syntactic sugar, or provide a clear rules to reduce it to a sugarless canonical form
- use a rich standard library (to avoid reimplementing the same functionality in different ways)
- use rich standard data types (to avoid definition of the similar types in different ways)
- sort every unordered construct, similarly how AWS signature sorts the keys before calculating the API call signature
- reduce the use of macros, custom eDSLs, or highly personalized code (by making writing this kind of code inconvinient)
- etc.
Some practical solutions:
- reduce code variability, by removing similar/alternative programming constructs / flexibility syndrome
- stick to a single programming paradigm
- remove syntactic sugar, or provide a clear rules to reduce it to a sugarless canonical form
- use a rich standard library (to avoid reimplementing the same functionality in different ways)
- use rich standard data types (to avoid definition of the similar types in different ways)
- sort every unordered construct, similarly how AWS signature sorts the keys before calculating the API call signature
- reduce the use of macros, custom eDSLs, or highly personalized code (by making writing this kind of code inconvinient)
- etc.
> no merge conflicts
In what sense?
I mean, in the following code
How does a content addressed AST solve the problem of having a different intent?
In what sense?
I mean, in the following code
# version 0
name = "bob"
# version 1
name = "alice"
# version 2
name = "clair"
How does a content addressed AST solve the problem of having a different intent?
Definitions are immutable. Changes to the codebase may add new definitions, but cannot change existing definitions. The codebase only grows larger as it is changed. To give an analogy, it's like having a git repo where the only change you can commit is to add new files; you will never have a conflict with such a restriction. However, Unison does make use of names. You can change 'name' to point to a new definition, but it does not affect existing definitions that depended on the old definition for 'name'.
https://www.unison-lang.org/learn/usage-topics/workflow-how-...
https://www.unison-lang.org/learn/usage-topics/workflow-how-...
I’m surprised I haven’t seen a Lisp with content-addressed ASTs, given that it already is authored at the AST level.
Do you have any follow up links on this topic by chance? I seem to have missed it in the docs.
https://www.youtube.com/watch?v=gCWtkvDQ2ZI&
This video is a little old but I remember finding it really interesting and I think dives into it a bit.
This video is a little old but I remember finding it really interesting and I think dives into it a bit.
I'd really, really love to read/hear more about Unison from the perspective of a Nix user/dev/enthusiast. And/or just a larger "example" app to chew on.
It's so unfortunate they decided to go with the Clojure/Haskell type syntax, as opposed to something friendlier like Elixir. A lot of people will not even try this language as a result. :(
The syntax is quite a bit like Haskell but that's mostly surface level here and imo it's quite it a bit simpler and easier to pick up. I'm curious what you mean by comparing it to Clojure when Unison is not really lispy at all.
Personally I found Unison easy to pick up the basics for despite being unfamiliar with Haskell beforehand (although underlying ideas of how to structure things took a bit of time for me to figure out).
Personally I found Unison easy to pick up the basics for despite being unfamiliar with Haskell beforehand (although underlying ideas of how to structure things took a bit of time for me to figure out).
Unison is neat, but who is paying for the infrastructure (now and in the future)?
Maybe I’m not understanding, but it seems like there’s a single global instance somewhere.
Maybe I’m not understanding, but it seems like there’s a single global instance somewhere.
Content-addressability means you don't need any infrastructure. You should be able to distribute code over IPFS for example.
There is no need for a central repository of any kind. Anyone can ship their own version of a library or program and there are no conflicts because they all have different content ids.
Unison language authors simply need to publish a hash of their latest release, and distribute the hash to users through any medium. Users can then retrieve the entire code base from its hash.
At least, this should be the goal, and content-addressability makes this feasible.
There is no need for a central repository of any kind. Anyone can ship their own version of a library or program and there are no conflicts because they all have different content ids.
Unison language authors simply need to publish a hash of their latest release, and distribute the hash to users through any medium. Users can then retrieve the entire code base from its hash.
At least, this should be the goal, and content-addressability makes this feasible.
Yeah, but the docs mention spinning up HTTP endpoints, so there is presumably a host somewhere.
Great points, though!
Great points, though!
So it's just...haskell but different?
As I understand it, part of the value proposition are the features that simplify distributed computation [0]. You define a function, and then you can refer to it by some internet global hash. The packaging reminds me a bit of Val Town, which has been featured here a few times [1].
[0] https://www.unison-lang.org/learn/the-big-idea/ [1] https://www.val.town/
[0] https://www.unison-lang.org/learn/the-big-idea/ [1] https://www.val.town/
Even on its own, that's hardly a "just" :P
But Unison is a lot more: it has a model that makes distributed computing feel like native code, and a content-addressed code representation system that solves a ton of tooling problems around versioning and deploying code. It's one of the most legitimately novel and powerful language projects I've ever seen, and I'm not saying that lightly.
But Unison is a lot more: it has a model that makes distributed computing feel like native code, and a content-addressed code representation system that solves a ton of tooling problems around versioning and deploying code. It's one of the most legitimately novel and powerful language projects I've ever seen, and I'm not saying that lightly.
It's completely different except for syntax.
Unison does not have monads, it has an effect system they call "abilities", which is quite innovative. Unison code is not stored in "textual" format, but directly in its AST form where everything has a content hash-address which is used to reference things everywhere. That's why they can take any function and send it for execution elsewhere in the cloud or whatever. It's also why there's no build system, and no dependency version conflict.
In summary, it's completely different than Haskell and most other languages, all you needed to do was visit the website and read a little bit to know that.
Unison does not have monads, it has an effect system they call "abilities", which is quite innovative. Unison code is not stored in "textual" format, but directly in its AST form where everything has a content hash-address which is used to reference things everywhere. That's why they can take any function and send it for execution elsewhere in the cloud or whatever. It's also why there's no build system, and no dependency version conflict.
In summary, it's completely different than Haskell and most other languages, all you needed to do was visit the website and read a little bit to know that.
> In summary, it's completely different than Haskell and most other languages, all you needed to do was visit the website and read a little bit to know that.
I did visit the website, observed an almost identical syntax to Haskell and left. Your comment is in bad faith.
I did visit the website, observed an almost identical syntax to Haskell and left. Your comment is in bad faith.
I remember when I last used Haskell a few years ago, quite a few packages on Hackage were broken, Cabal was a pain to deal with, and although Stack fixed things, it added to the complexity. I know things have improved since then, but I can't imagine how replacing the build system wouldn't improve things a lot.
They’ll have a difficult time attracting some users when the only chat option is proprietary and to join the “ecosystem” users must create a Microsoft GitHub account in order to sign-in. We’ve seen stories of accounts banned (like the star hacking situation) where a user could be entirely locked out of a community on Slack or Microsoft’s terms, not the community’s.
A look at Unison: a revolutionary programming language - https://news.ycombinator.com/item?id=34307552 - Jan 2023 (84 comments)
The Unison language – a new approach to Distributed programming - https://news.ycombinator.com/item?id=33638045 - Nov 2022 (113 comments)
Unison Programming Language - https://news.ycombinator.com/item?id=27652677 - June 2021 (131 comments)
Unison: A Content-Addressable Programming Language - https://news.ycombinator.com/item?id=22156370 - Jan 2020 (12 comments)
The Unison language - https://news.ycombinator.com/item?id=22009912 - Jan 2020 (141 comments)
Unison – A statically-typed purely functional language - https://news.ycombinator.com/item?id=20807997 - Aug 2019 (25 comments)
Unison: a next-generation programming platform - https://news.ycombinator.com/item?id=9512955 - May 2015 (128 comments)