The Unison Programming Language
unisonweb.org
The Unison Programming Language
1–10 of 134 posts
Re: The Unison Programming Language
#2Submission inspired by https://news.ycombinator.com/item?id=27651197 , I guess
Re: The Unison Programming Language
#3They mention using git to version Unison code, and point out how there'll practically never be any version conflicts because of the immutable / append-only nature of the language.
Doesn't that mean that the git repository will only ever grow, and that old code will stick around forever? I hope I'm misunderstanding because that would be unfortunate if true.
Re: The Unison Programming Language
#4They mention using git to version Unison code, and point out how there'll practically never be any version conflicts because of the immutable / append-only nature of the language. Doesn't that mean that the git repository will only ever grow, and that old code will stick around forever? I hope I'm misunderstanding because that would be unfortunate if true.
Seems like an intended design feature. That doesn't mean you have to keep all those old versions in every copy of the repository; you could always fetch only versions you need, for instance.
Re: The Unison Programming Language
#5They mention using git to version Unison code, and point out how there'll practically never be any version conflicts because of the immutable / append-only nature of the language. Doesn't that mean that the git repository will only ever grow, and that old code will stick around forever? I hope I'm misunderstanding because that would be unfortunate if true.
Isn't that true of any Git repository? The internal object store keeps every version of every file that has ever existed (unless you rewrite history).
In practice, Git's content-addressable storage and delta compression make it work fairly well for all but the largest repositories.
Re: The Unison Programming Language
#6I had a really hard time wrapping my mind around this just reading the website alone. If you are in the same boat, watch the first 10 minutes of this video at 1.5x speed: https://www.youtube.com/watch?v=gCWtkvDQ2ZI
and it will make so, so much more sense.
...and if you are like me you'll probably need to read this twitter thread to get the answer to your #1 question: https://twitter.com/unisonweb/status/1173942974381744134
Basically the core idea (or one of the core ideas) is instead of a function (like fib(n) which returns nth Fibonacci number) being identified by its name (fib) as is the case with most traditional languages, it's instead identified by a hash of its implementation.
Re: The Unison Programming Language
#7> Unison definitions are identified by content. Each Unison definition is some syntax tree, and by hashing this tree in a way that incorporates the hashes of all that definition's dependencies, we obtain the Unison hash which uniquely identifies that definition.
Very cool core concept. Reminds me of some things Rich Hickey has said about the idea of versioning dependencies at the function level
That said: I wonder if this idea would make more sense as static analysis on an existing language. It would have to be trivial to enumerate all code that might influence a function's behavior; so something totally pure like Haskell or Elm
Re: The Unison Programming Language
#8There is nice blog post summing up what's cool about Unison[1]
Re: The Unison Programming Language
#9There is nice blog post summing up what's cool about Unison[1] [1] https://jaredforsyth.com/posts/whats-cool-about-unison/
Thank you, that helped explain pretty well what abilities are. I felt like I was kind of starting to get what the language was about, then I hit the abilities section and I had no idea what it was talking about.
Re: The Unison Programming Language
#10This looks pretty well done. It doesn’t seem like a gimmick; they’ve made a lot of good choices beyond the core conceit of content-addressable code.
One thing I didn’t see skimming the language reference page: is there any sort of typeclass mechanism?