▲ 280 points
back
113 comments
I think they are making a mistake that's common in this sort of project: trying too many new things at once!
They already have a very innovative way of managing source code, with a database of definitions that keeps the hash of the syntax tree instead of actual source. That's a very neat idea that solves many problems (read their docs to understand why).
But instead of developing that well enough so that it works with source control tools, IDEs, can be deployed easily and painlessly on existing infrastructure... no, they decided to ALSO solve distributed computing, a really, really complex space with a pretty crowded space of solutions... and seem to be focusing on that now instead of the "original" ideas. Looks like a huge issue with scope creep to me... unless they are kind of pivoting to distributed computing now only because the original ideas were not attractive enough for people to embrace it, but I have not heard of anything like that, everyone seems to be pretty vibed by those things.
The two areas of managing source code and distributed computing are not as disjunct as you make them in the context of Unison. They follow from the underlying principle of addressing functions not by their name but by a hash of their normalized syntax tree (ie their code).
There are a bunch of cool implications for distributed computing, namely that you can easily distribute fine grained parts of your application across servers and that you can cache the result of expensive calculations.
To be fair, for a while they were ALSO working on their own graphical source editor that allowed for type-correct transformations and assisted refactorings. They put that on the back burner specifically because they are trying to focus on fewer things :)
I think the distributed computing problem is pretty related once you have "content-addressable" source code. Agreed that it's a lot of work but I hope it pans out!
I thought that was sort of Paul's goal, to explore a bunch of new ideas and paradigms. I doubt he's under any illusions that this language, qua this language, is going to see wide adoption or need to have all of its features really ironed out with a fixed/stable API. But I could be wrong!
You have it backwards. The source code management (as a marketable feature) came at least one year and maybe two years after the distributed computing parts. The earliest Unison demos (circa 2016) were "build a distributed google crawler in just a few lines of code". I think the hashes were always a component, but not part of the real messaging for quite awhile.
Sounds like `Opa!`, which was a language plus a meteor-like framework. The language itself was really nice with some interesting type-level features, but the built-in framework was the selling point. But all that ultimately got in the way for doing anything that wasn't built into it, which ended up being pretty much anything beyond toy prototypes. The language got dragged down because of it.
That said, it came out around the same time CoffeeScript did, and nobody uses CoffeeScript anymore either. So probably the fate was inevitable regardless of whether the framework was included in the language or not.
If we want to set sail on the ocean, we do not take a basket and start work to stop it from leaking. We build a boat.
> I think they are making a mistake that’s common in this sort of project: trying too many new things at once!
The one thing identified as “the big idea” of Unison seems to me to be conceived as a solution to a distributed computing problem that incidentally also solves a number of problems that are issues outside of distributed computing (but also within distributed computing, such that fleshing out how it can solve them enhances unison as distributed computing solutions as well as providing side benefits.)
> read their docs to understand why
hard pass. but thanks for the suggestion. I'll start with the home page and the examples and most likely end there.
The reason for the source code structure is because of what it enables for distributed computing.
It makes it simple to transparently ship the code (not just data) around to any worker node. The point of Unison Cloud is to disappear the difference between AWS EC2 and Lambda.
That is the perfect programming language landing page.
The Hello World example introduces one of their concepts that you might not see every day, then they show a little algorithm, then a practical "stuff you need to get work done" example.
I got an immediate sense that the language has some familiar "ML family" type features (like F# or Scala) but also some distinctive aspects.
Oops I posted something similar to this. Agree completely.
This project hashing of sourcecode (or AST) in the interpreter is a really powerful idea
I plan to use it for a slightly different purpose. I want to implement an interpreter that is multithreaded similar to Java or Erlang that can send objects between shared memory without marshalling or copying.
I had a talk with someone on HN https://news.ycombinator.com/item?id=32907523 about python's Global Interpreter Lock and we talked about how objects are marshalled between subinterpreters due to object identity. The identity of an object is defined at creation time as the hash of that object.
If the hash of the object was the sourcecode, two interpreters could load the same Object hierarchy and send data by hash reference.
I wrote a multithreaded interpreter that uses message passing to send integers and program counters to jump to code in other threads
This is at https://GitHub.com/samsquire/multiversion-concurrency-contro...
Iirc pony langs messages could work like that.
Discussion from
- a year ago https://news.ycombinator.com/item?id=27652677
- 8 years ago https://news.ycombinator.com/item?id=9512955
Thanks! Macroexpanded:
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 Language March Update - https://news.ycombinator.com/item?id=19528189 - March 2019 (1 comment)
Unison: a next-generation programming platform - https://news.ycombinator.com/item?id=9512955 - May 2015 (128 comments)
- Function definitions stored in a content-addressed database.
- Dependency management handled the same way the Nix handles it.
- Some kind of object storage system that uses content-addressable structures as the schema.
- Hyperlinked codebase.
- Human-readable function names as (essentially) git tags.
These ideas are all pretty nice. A dedicated IDE for this language would be a lot of fun to work with. The debugging story likewise seems like it will be pretty solid. I'm not sold on the zero config storage layer: basic object retrieval is different than schema prepared for query performance. I'd like to learn more about the concurrency and synchronization story.
I think that content addressability works really well for code, at the bottom layer. But in order to be practical, you typically need:
Naming and resolvers, in order to be human friendly. This isn't easy to get right, but we have a lot of prior art in dependency management systems.
Persistence layers with GC, like cache and db. You're gonna want to fetch and prefetch in ways that are quite advanced. You don't want to be be blocked in a critical section by network fetching the leftpad function.
On a tangential note--do you like this home page as much as I do? It really draws me in as a programmer. I like all the code examples up front, and their mission statement ("A new approach to distributed programming/No more writing encoders and decoders at every network boundary") seems to be quite clear. To me one of the best landing pages I've run across.
This strikes me as a compiler and IDE feature, rather than a reason to have a separate programming language.
What does having a separate language give us as opposed to taking say, Kotlin, and having a compiler that stores the AST/whatever in a database and does all the interesting goodies?
Or is that the end goal, but we're using a basic language to test it out and work out all the quirks before writing a compiler for existing languages?
"Each Unison definition is identified by a hash of its syntax tree." [0]
I remember many years ago, i had the same idea on how to correctly version a dependency.
Does Unison have stack traces? Using the hash of the ast as the only identifier seems like it would lose some useful runtime debugging information.
How do Unison abilities handle non-commutative abilities (i.e. abilities where the order in which one applies handlers matters). Does it just assume that abilities are commutative? Or rely on the programmer to make sure that handlers are applied in an order that makes sense?
It is up to the code handling the abilities to decide in which order to handle the abilities (or to handle them all at once).
I can't think of any cases where it would make a difference in which order they were handled, however. Can you?
I think perhaps it might in the case where abilities themselves were able to make requests of other abilities, but that's not something allowed by our type system currently
The latter.
I had to dig for the distributed part but it's outlined here: https://www.unison-lang.org/articles/distributed-datasets/
But the only runtime available for this sort of application seems to be the "unison cloud" that is a hosted service.
>Other tools try to recover structure from text; Unison stores code in a database
Just like VisualAge in the last century. Sign me up, that was great stuff.
Smalltalk had a lot of good ideas!
I loved it, except that it seemed to periodically corrupt the source code database which was an absolute nightmare.
Does anyone have a comparison with Darklang/ecosystem and it's goals?
Some of the things mentioned sound similar, at a high level.
I really like the idea of Unison, but unfortunately when I went to try it out, it was much slower than even Python. I hope they can make it performant!
In one of our most recent blog posts we talked about the progress we are making on just-in-time native compilation:
https://www.unison-lang.org/blog/jit-announce/
We are expecting to be a monumental speedup for us. We have some promising results so far, but we haven't yet ported all of the runtime.
How does the runtime manage different levels of trust between clients?
How does the language grapple with code injection vulnerabilities? If I want to be able to receive data from an untrusted entity, but not code, how do I make sure they're not submitting code to my server to unpack and execute?
You can simply expose an HTTP endpoint that receives the data. You wouldn't want to expose the internode protocol endpoint to the internet.
That said, it wouldn't be as bad as it sounds. Unison is a purely functional language, so if you don't explicitly provide the ability to e.g. do arbitrary I/O, then other nodes will not be able to send you code that does I/O. It will not type-check.
Can someone please ELI 5 for me how to get started?
I downloaded and ran it, it created folders NOT where I told it to, and started.... but no command I type seems to result in anything other than an error message.
How can I get it to add 5+5, without using an external editor?
You're not going to just be able to write code into ucm (unison code manager) because it's not a repl. You'll need some sort of text editor to actually write the code it will then add to the codebase.
https://www.unison-lang.org/learn/quickstart/
If this quick start tutorial doesn't work for you then there's a bug on unison's end.
I’m excited for ideas like this to become mainstream. Today’s approaches to heterogeneous and distributed computing are how I imagine single core computing was 40 years ago. You have to manually manage practically everything. Instead, let the compiler or interpreter or whatever figure out where to actually run it (CPU vs ALU vs GPU vs remote machine #42), what to keep in what part of cache (L1 vs L2 vs RAM vs disk vs S3), etc.
We have, though. Spark, for example, does this in just about every language. It's been around for ages, is liberally licensed, and deployed at scale in thousands of enterprises.
Sanjay already had a somewhat similar approach in managing the scheduling of concurrent RPCs, i.e., RPCs are enqueued, and a scheduler looks at the RPCs and figure out windowed batching order to optimize for the overall execution time (here the concurrent RPCs are interdependent).
That sounds like a slightly different problem. Unison looks like any function can transparently cross network boundaries versus the efficient scheduling and dispatching of concurrent rpcs.
An answer to the question "what useful thing has been build with Haskell"?
' - is used to denote a delayed computation.
This is hard to see / easy to miss. What it this trend to abbreviate everything down to a shortest. What is wrong with delayed keyword for example
Nil nove sub sole ?
It reeks of COOLs (Concurrent Object Oriented Languages).
Here's an example of the mid 90s:
https://distrinet.cs.kuleuven.be/projects/CORRELATE/
how is this different from apache beam? also, any orgs using this at scale?
It smells like Haskell. Perhaps more human-friendly. Nice.
No description on the home page, the documentation, Github page ... mentions that this is a Haskell-like language inspired by Haskell. No credit to Haskell while the code base is 99.6% Haskell!
I LOVE the idea but the language itself is so ugly I don’t want to learn it. It looks really ugly. Sorry.
Is this the same language from the how to create a programming language book?