[flagged]
Unison 1.0
21–30 of 98 posts
Re: Unison 1.0
#22Earlier quoted context omitted.
Hello! Yes I am curious, how does one deal with cycles in the code hash graph? Mutually recursive functions for example?
There's an algorithm for it. The thing that actually gets assigned a hash IS a mutually recursive cycle of functions. Most cycles are size 1 in practice, but some are 2+ like in your question, and that's also fine.
Does that algorithm detects arbitrary subgraphs with a cyclic component, or just regular cycles? (Not that it would matter in practice, I don't think many people write convoluted mutually recursive mess because it would be a maintenance nightmare, just curious on the algorithmic side of things).
Re: Unison 1.0
#23Also, hi, I'm one of the language creators, feel free to ask any questions here!
First, congratulations for the 1.0 milestone. Then, a pretty basic question: I see that Unison has a quite radical design, but what problem does this design solves actually?
Thank you!
Unison does diverge a bit from the mainstream in terms of its design. There's a class of problems around deploying and serializing code that involve incidental complexity and repetitive work for many dev teams (IDLs at service boundaries and at storage boundaries, provisioning resources for cloud infrastructure) and a few "everyday programming" pain points that Unison does away with completely (non-semantic merge conflicts, dependency management resolution).
We wrote up some of that here at a high level: https://www.unison-lang.org/docs/what-problems-does-unison-s...
But also, feel free to ask more about the technical specifics if you'd like.
Re: Unison 1.0
#24Also, hi, I'm one of the language creators, feel free to ask any questions here!
Really cool project. To be honest, I think I don't fully understand the concept of a content addressed language. Initially I thought this was another BEAM language, but it seems to run on its own VM. How does Unison compare to BEAM languages when it comes to fault tolerance? What do you think is a use case that Unison shines that Erlang maybe falls short?
Erlang is great and was one inspiration for Unison. And a long time ago, I got a chance to show Joe Armstrong an early version of Unison. He liked the idea and was very encouraging. I remember that meant a lot to me at the time since he's a hero of mine. He had actually had the same idea of identifying individual functions via hashes and had pondered if a future version of Erlang could make use of that. We had a fun chat and he told me many old war stories from the early days of Erlang. I was really grateful for that. RIP, Joe.
Re: distributed computing, the main thing that the content-adressed code buys you is the ability to move computations around at runtime, deploying any missing dependencies on the fly. I can send you the expression `factorial 4` and what I'm actually sending is a bytecode tree with a hash of the factorial function. You then look this up in your local code cache - if you already have it, then you're good to go, if not, you ask me to send the code for that hash and I send it and you cache it for next time.
The upshot of this is that you can have programs that just transparently deploy themselves as they execute across a cluster of machines, with no setup needed in advance. This is a really powerful building block for creating distributed systems.
In Erlang, you can send a message to a remote actor, but it's not really advisable to send a message that is or contains a function since you don't know if the recipient has that function's implementation. Of course, you can set up an Erlang cluster so everyone has the same implementation (analogous to setting up a Spark cluster to have the same version of all dependencies everywhere), but this involves setup in advance and it can get pretty fragile as you start thinking about how these dependencies will evolve over time.
A lot of Erlang's ideas around fault tolerance carry over to Unison as well, though they play out differently due to differences in the core language and libraries.
Re: Unison 1.0
#25Oh man, I first looked at this project what feels like _forever_ ago and remember thinking--almost verbatim, "Wow I wish I could see this 5 years from now", and lo and behold I suppose it has been about that long!
Very happy to see it finally hit 1.0
Re: Unison 1.0
#26Also, hi, I'm one of the language creators, feel free to ask any questions here!
What is the data you actually store when caching a successful test run? Do you store the hash of the expression which is the test, and a value with a semantics of "passed". Or do you have a way to hash all values (not expressions/AST!) that Unison can produce? I am asking because if you also have a way to cache all values, this might allow to carry some of Unison's nice properties a little further. Say I implement a…
Yes, we have a way of hashing literally all values in the language, including arbitrary data types, functions, continuations, etc. For instance, here, I'm hashing a lambda function:[1]
> crypto.hash Sha3_256 (x -> x + 1)
⧩
0xs704e9cc41e9aa0beb70432cff0038753d07ebb7f5b4de236a7a0a53eec3fdbb5
We only do this caching for pure tests (which are deterministic and don't need to be re-run over and over), enforced by the type system. You can have regular I/O tests as well, and these are run every time. Projects typically have a mix of both kinds of tests.
It is true that you can only hash things which are "closed" / have no free variables. You might instead hash a function which takes its free variables as parameters.
Overall I think Unison would be a nice implementation language for really anything that needs to make interesting use of hashing, since it's just there and always available.
[1]: https://share.unison-lang.org/@unison/base/code/releases/7.4... [2]: https://share.unison-lang.org/@unison/base/code/releases/7.4...
Re: Unison 1.0
#27I have been following Unison for a veeery long time. Ever since those blog posts on Paul's personal website. It has been more than 10 years already so this is a great milestone. But I am just a bit disappointed. I love programming languages. I follow every programming language, even some you probably have never heard of. I have witnessed the rise of Rust, Go, Zig and others. At the age and level of polish that Unison has I have seen far more traction for those languages that actually have become something. I personally believe the reason is how hard they are trying to push their impossible "business model" by making most of the things going on on the ecosystem locked in to their cloud. I know there is a BYOC oferring but that isn't enough. The vibes are just off for me.
Re: Unison 1.0
#28Also, hi, I'm one of the language creators, feel free to ask any questions here!
I'm curious about how the persistence primitives (OrderedTable, Table, etc) are implemented under the hood. Is it calling out to some other database service? Is it implemented in Unison itself? Seems like a really interesting composable set of primitives, together with the Database abstraction, but having a bit of a hard time wrapping my head around it!
Re: Unison 1.0
#29I genuinely think systems like Unison are "the future of computing"...
But the question is when that future will be.
Part of the beauty of these sorts of systems is just that the context of what your system actually does is in one system, you aren't dealing with infra, data, and multi-service layers
Maybe that means it is a much better foundation for AI coding agents to work in? Or maybe AI slows it down? we continue to try and throw more code at the problem instead of re-examining the intermediate layers of abstraction?
I really don't know, but I do really want to learn more about is how the unison team is getting this out in the market. I do think that projects like this are best done outside of a VC backed model... but you do eventually need something sustainable, so curious how the team things about it. Transparently, I would love to work on a big bet like this... but it is hard to know if I could have it make financial sense.
With all that, a huge congrats to the team. This is a truly long-term effort and I love that.
Re: Unison 1.0
#30Has anyone used this, any cool ideas?
https://www.unison-lang.org/docs/the-big-idea/ might be a good starting point! For interesting usage - we built Unison Cloud (a distributed computing platform) with the Unison language and also more recently an "AWS Kinesis over object storage" product. It's nice for distributed systems, though you can also use it like any other general-purpose language, of course. In terms of core language features, the effect syste…
I think Alvaro's at the Unison conference was a pretty cool demonstration of what you can do with the style of algebraic effects (called "abilities" in unison)
https://www.youtube.com/watch?v=u5nWbXyrC8Y
He implements an erlang style actor system, and then by using different handlers for the algebraic effects, he can "run" the actor system, but also optionally make a live diagram of the actor communications.