Comment by brabel
12 days ago
I've been learning Unison [1] and I highly recommend. It's a Haskell-like language, but with some really interesting ideas around how code should be managed and distributed. They also use use algebraic effects (represented with "abilities" in Unison) instead of Monads, which gives some interesting advantages [2].
[1] https://www.unison-lang.org/
[2] https://www.unison-lang.org/docs/fundamentals/abilities/for-...
Have you written anything in Unison yet? To me Unison feels extremely ahead of its time. They clearly thought things through and aren't afraid to challenge the status quo. Maybe a bit too much ahead of its time even...
I fear `ucm` a little. You mean I can't version my things with git? How do I... ehh, do anything? And how is the deployment story if one chooses not to use the Unison cloud?
To be honest, all I've done was try the weekly challenges that the Unison team publishes on Twitter :D
I just like the very light syntax that it got from Haskell, but without the need for Monads and the "ugly" monad operators you need to juggle, replaced by abilities which IMHO are much more elegant.
They are focusing on writing cloud-services and apparently their offering is already pretty good, so if I ever need a clouse service I am tempted to use Unison (for anything not very critical, at least until I gain confidence in it): https://www.unison.cloud/our-approach/
And I love ucm and think it may be very close to what the future will look like (which is why I do agree it's ahead of our time). It's already possible to work with Unison but still have proper code review: https://www.unison-lang.org/docs/tooling/project-workflows/#...
Here's an example change: https://share.unison-lang.org/@unison/base/contributions/42/...
But currently, I believe you do need to pull the branch locally and then load diffs with ucm into your favourite diff tool to properly see what's been changed (which is not ideal , and I believe they are working on making this easier, we'll see).
Can you or someone else familiar with Unison tell us what specific things about Unison feel ahead of its time? I don't know Unison so these things will be a good motivation for me to learn Unison.
Unison tries to swallow the whole elephant all at once, which is probably what the author is getting at.
* `ucm` is like a coding assistant that sits with you the whole time. You don't grep through code to find snippets or anything, you use `ucm`. It does a whole lot more, but that's just the trivial example.
* You need `ucm` because Unison stores code as a syntax tree, not text. This is awesome because versioning/dependency conflicts/rename issues just go away. This is not awesome because nothing else knows how to understand this: other source control systems will just not work.
* It's really trying to drag functional coding into this decade and what we use code for in production. It's not trying to be Haskell which is a great language, but doesn't (to me) feel like it was designed to do something like a simple web app.
* It is supposed to do distributed cloud computing without modification (this smells like where the VC money came from), but again, you have to use their platform because other clouds don't understand Unison.
The list goes on.
Each individual piece of Unison I think is really great. I love the `ucm` model of having an assistant sit next to you the whole time. What I don't love is that there is just _so much_ learning placed on the developer. To understand Unison, you need to understand a lot of what they're doing, a lot of what they are doing is novel, and so you have to eat the whole elephant that they are. I don't know if there was a path where they could have eaten the elephant one bite at a time, but it really makes the onboarding onerous.