I have to admit this broke my brain. This is the first time I'm hearing about content addressable languages, and once you get over that barrier, a distributed language doesn't seem far fetched.
As a big fan of functional programming, is this something that is going to just end up being an esoteric language? Don't get me wrong, I absolutely love the vision of the authors, but after being bitten by the Elm bug and that crashing and burning, I'm just cautious of getting invested in new languages and tools.
Interesting idea, but isn't code addressable already in most languages?
We call them modules/libraries and we pip/npm install them from Github and you can keep track of changes/versions/PRs.
Content addressable has a very specific meaning: https://en.wikipedia.org/wiki/Content-addressable_storage
Modules and libraries are addressable based on their names or URI:s.
"Unison eliminates name conflicts. Many dependency conflicts are caused by different versions of a library "competing" for the same names. Unison references defintions by hash, not by name, and multiple versions of the same library can be used within a project." https://www.unison-lang.org/docs/what-problems-does-unison-s...
"Here's the big idea behind Unison, which we'll explain along with some of its benefits:
Each Unison definition is identified by a hash of its syntax tree.
Put another way, Unison code iscontent-addressed. Here's an example, the increment function on Nat:
increment : Nat -> Nat increment n = n + 1
While we've given this function a human-readable name (and the function Nat.+ also has a human-readable name), names are just separately stored metadata that don't affect the function's hash. The syntax tree of increment that Unison hashes looks something like:
increment = (#arg1 -> #a8s6df921a8 #arg1 1)
Unison uses 512-bit SHA3 hashes, which have unimaginably small chances of collision.
If we generated one million unique Unison definitions every second, we should expect our first hash collision after roughly 100 quadrillion years! " https://www.unison-lang.org/docs/the-big-idea/
Seems like identifying your library with a git tag would drop that risk to zero.
I guess what I'm not understanding here is the utility. Why is it useful to include multiple versions of a library in a project? Is this a limitation I've been coding around without knowing it?
One reason for multiple versions of a library in a project is that the project wants to use 2 different dependencies, which themselves depend on incompatible versions of a third library.
ok, yep, that's one I've had myself. Thanks.
Have you ever had problem where two of your dependencies are each using a different version of the same library? Or have you ever wanted to incrementally upgrade an API so that you don’t have to change your entire code base in one fell swoop? That is where things like Unison or scrapscript can make it very easy.
Ok, I can see "incremental upgrade" as a use-case. Thanks.
Tags are not immutable.
I recommend reading the benefits section in the Unison docs[0].
0: https://www.unison-lang.org/docs/the-big-idea/#benefits
I think it is something like Hoogle for haskell but instead of looking for the types of the functions you look for a hash of some kind of canonical encoding of the definition, so it is like an encoded knowledge graph but you should have to give rules in order to construct that graph in a canonical way.
Edited: What I thought was wrong, anyway the idea of above could be useful for something like copilot to complete definitions.
Content-addressable, not code addressable. It's kind of like global, distributed memoization (IIUC).
edit: not memoization, just hashing the AST of a function.
Content is by definition content addressable. x = 42 is a hardlink to every other instance of x = 42 if you will. What this does is more compact and practical content addressing, like Nix or Git. But realizing that there are always more than one way of expressing the same logic (with different hashes no matter how you canonicalize) makes me doubt it is a killer feature.
That does not sound like it could make any money though...
In case you don't know about this, this is kind of what they are trying to achieve: https://www.unison-lang.org/
I still don't get it, could someone smarter than me explain?
helloWorld : '{IO, Exception} () helloWorld _ = printLine "Hello World"
The example above is followed by explanation "{IO, Exception} indicates which abilities the program needs to do I/O and throw exceptions." Well, which abilities does it need then? No idea.
Abilities called IO and Exception.
I am sure you are familiar with effect systems and algebraic effects, right? Abilities are what algebraic effects are called in Unison: https://www.unison-lang.org/docs/fundamentals/abilities/
So, in Haskell you would have IO monad and Exception monad, but in Unison you have an IO ability and an Exception ability.
If you want to know more: https://www.unison-lang.org/docs/language-reference/abilitie... and: Convent, L., Lindley, S., McBride, C. and McLaughlin, C., 2020. Doo bee doo bee doo. Journal of Functional Programming, 30, p.e9. https://arxiv.org/pdf/1611.09259.pdf
Probably not, based on their question!
These are pretty esoteric concepts. I think it was one of a few bullet points on "other interesting ideas" in the functional programming portion of my programming languages course, and I doubt that most working programmers have taken an academic PL course like that at all.
But effects are indeed an awesome concept, and thanks for the excellent links! The parent is one of today's lucky 10,000: https://xkcd.com/1053/
As a junior that did not do CS at uni, a lot of stuff around here goes right over my head. I often do feel that I might never catch up. I just about understand what functional programming is in terms of a one line definition let alone any concepts that fall under it. To be fair, I only really use Object Oriented.
Thank you!
It is not about smartness, but it is probably you not having encountered these concepts before.
Thank you, this looks awesome. I already have a use case in mind, so will explore unison since it seems more mature.
Nothing crashed and burned. Elm is in a state where it’s fully usable and has all the futures you need. I use it every day!
Since it’s a DSL to create HTML + JS + CSS websites, you still get all the new features of browsers!
I think, even though I can absolutely see the arguments for doing so, locking down the compiler to no longer accept external native extensions was a huge mistake community wise, since a lot of the people advocating for Elm were the sort of early adopter who really really wants an escape hatch because they're in the habit of getting into situations where they need one no matter what tools they're using.
Certainly that describes me, and when all the people who seemed to be like me got told to go sit on a cactus by the Elm core developers and bailed out to work with something else, my experiments got pretty much immediately shelved and Elm moved into the "interesting place to steal ideas from, actively hostile to my actually using it" category.
This may be unfair, but I'm pretty sure it's a reasonable description of what -did- happen, fair or not.
Except for the compiler bugs, lack of self hosted package management, improvements to tooling, etc. I use it regularly too, but it is frustrating to see it in a state of decay.
They can definitely claim the above points and more are not goals, and Evan absolutely has every right to do so. But don’t be surprised when devs see it as dead.