The Unison language
unisonweb.org
The Unison language
1–10 of 144 posts
Re: The Unison language
#2Content-addressed, immutable code? Reminds me of https://thedailywtf.com/articles/the-inner-json-effect
Re: The Unison language
#3Reading the tour[1], I got the impression of being struck by something not that surprising, but still fundamentally groundbreaking.
Beyond just the idea of a global program store (which I hope has space for some virtualenv equivalent), the cleverness of effect handlers as a first-class language feature is very exciting.
Once the type system is more mature, this could easily be the next kind of Haskell - a language which redefines modern ideas of good programming.
Re: The Unison language
#4Algebraic effect handlers no doubt seem to be the future of getting side-effects under control in programming languages, much like in the way of what immutability has done for data.
My (admittedly little) experience with Unison though is that it's far from ready for the spotlight however. Much of the docs 404, and joining their discord mostly resulted in the advice to wait for future releases.
I wish Microsoft would invest in something like the koka language https://github.com/koka-lang/koka. Perhaps the idea of content-addressable / immutable code could find a place too, but I think it's less critical.
Re: The Unison language
#5Reading the tour[1], I got the impression of being struck by something not that surprising, but still fundamentally groundbreaking. Beyond just the idea of a global program store (which I hope has space for some virtualenv equivalent), the cleverness of effect handlers as a first-class language feature is very exciting. Once the type system is more mature, this could easily be the next kind of Haskell - a language wh…
Since it took me a while to find it, the relevant documentation is under "Abilities and Ability Handlers" [1]
[1] https://www.unisonweb.org/docs/language-reference#abilities-...
Re: The Unison language
#6Kudos to them for not using the buzzword, but if you believe in the notion that 'blockchain is just a fancy buzzword that gives developers the ability to get managers to agree to larger budgets to clean up tech debt', this is.. blockchain programming.
One problem I did find: Somewhat deeper into the tour, the tour makes the claim:
> a Unison codebase can be versioned and synchronized with Git or any similar tool and will never generate a conflict in those tools.
This is pratically speaking of course not true: If you have some unison codebase, whilst under the hood it's all hashes, that doesn't change the simple fact that if 2 people both check out the exact same code, and then both people make a change to how the software operates, where that change is conflicting (say, I make the green 'OK' button now red, and you make it blue), you.. have a conflict. That is a fundamental property of this interaction; no language bells and whistles can ever change this fact.
So, what does happen in unison? Is it 'last committer' wins? That'd be a bit problematic. A conflict in your version control system, _IF_ it is representative of the fact that there was an actual conflict (as above with the button and the conflicting colours), is a good thing, not a bad thing.
Re: The Unison language
#7Algebraic effect handlers no doubt seem to be the future of getting side-effects under control in programming languages, much like in the way of what immutability has done for data. My (admittedly little) experience with Unison though is that it's far from ready for the spotlight however. Much of the docs 404, and joining their discord mostly resulted in the advice to wait for future releases. I wish Microsoft would…
I've pondered using IPFS as a backend for content-addressable, immutable code blocks. That idea seems to fit in with the concept of structured or syntaxless programming, to assemble blocks into systems. Here's a list of the latter. https://www.reddit.com/r/nosyntax/
Re: The Unison language
#8Kudos to them for not using the buzzword, but if you believe in the notion that 'blockchain is just a fancy buzzword that gives developers the ability to get managers to agree to larger budgets to clean up tech debt', this is.. blockchain programming. One problem I did find: Somewhat deeper into the tour, the tour makes the claim: > a Unison codebase can be versioned and synchronized with Git or any similar tool and…
> It is append-only: once a file in the .unison directory is created, it is never modified or deleted, and files are always named uniquely and deterministically based on their content.
That's how conflicts are avoided.
Re: The Unison language
#9Maybe I've been out of the game or something. But I don't think saying everything is "content-addressed" can land as such of a big mic-drop moment when I've never heard the term or the concept in my life and the front page does absolutely nothing to explain it beyond that.
------ EDIT: My tone here is a little more antagonistic that I meant (proofread kids, don't just check for spelling and publish) but my first impression was a kind of "buzzword-y" vibe. I've looked a bit more and the authors seem genuinely passionate about shaking things up and trying something completely different, which I can respect. I'll leave it up as is because I still think my issue are legitimate, but the tone is a little off and I apologize. ------
Let's take my discovery path so far as an example:
> Functional language: cool cool. I know what that is. Immutable: also cool. Content-addressable: no clue. Saying it'll simplify code bases and eliminate dependency and "no builds" is supposed to sound amazing, but it really doesn't land when I have no clue what the premise is.
> Alright, that's it for the front page. No code examples, nothing linking the currently known to this new paradigm-shifting stuff. K. Let's try the docs.
> The Welcome is the state of the project without saying anything about the language itself. Roadmap isn't gonna help Quickstart! Let's look there.
This amount of effort for discovery isn't very helpful for me. I found a selection of talks elsewhere on the site. One of them is labeled "This is a longer (40 min) introduction to the core ideas of Unison and probably the best talk to start with." That might be a nice link for the front page.
I unfortunately don't have anymore time to look at this this morning, but the first 5 or so minutes of the talk say waaaaaaaaay more than the first however long I spent. Honestly, I think all of that information (code examples, linking core ideas to what we already know, basis of comparison) could be on the front page.
The tl:dr I can glean from it is:
It's kinda like Haskell, but every definition is turned into AST and put in a hash table. Any references are secretly references to the table, so changing a definition is making a new hash and changing the reference, and renaming is changing the reference to name table.
Also, everything is append instead of rewrite, which makes all kinds of stuff cleaner, like versioning and refactoring.
Pretty neat idea, I just don't really like how long it took me to come to that knowledge. I don't know how well it would scale or be usable in a real world scenario, but I also have never used Haskell or any functional language in a "real world" scenario so I'm not the best one to ask.
Re: The Unison language
#10Kudos to them for not using the buzzword, but if you believe in the notion that 'blockchain is just a fancy buzzword that gives developers the ability to get managers to agree to larger budgets to clean up tech debt', this is.. blockchain programming. One problem I did find: Somewhat deeper into the tour, the tour makes the claim: > a Unison codebase can be versioned and synchronized with Git or any similar tool and…
" I make the green 'OK' button now red, and you make it blue"
I did not fully read the introduction yet, but in my mind, in a truly content-addressed system this is not a conflict: you have the hash of a main() function which ultimately makes the button red, and the other guy has a main() function that makes the button blue. No conflict in the physical sense. Yes, philosophycally there is a conflict, which is resolved by you deciding which main() function you find more useful.