Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Unison language

unisonweb.org

Post reply on HN
Print view View original

11–20 of 144 posts

Re: The Unison language

#11

Post by the_duke »

nadam wrote: post #10
rzwitserloot wrote: post #6

Kudos 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 resolve…

Of course there are still conflicts everywhere.

Developer A makes the button red, developer B changes the label from "OK" to "Accept", both inside the same function.

You can't just pick one or the other, you have to combine the changes.

Or two developers add two different fields to a type. Or ...

Sadly the docs only have placeholders for "Concurrent work and resolving edit conflicts" and "Pull requests and collaboration". Would be very interesting to read the developers thoughts on this.

The system seems to support patches, forking and merging.

Re: The Unison language

#13

Post by nadam »

the_duke wrote: post #11
nadam wrote: post #10

Earlier quoted context omitted.

" 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 resolve…

Of course there are still conflicts everywhere. Developer A makes the button red, developer B changes the label from "OK" to "Accept", both inside the same function. You can't just pick one or the other, you have to combine the changes. Or two developers add two different fields to a type. Or ... Sadly the docs only have placeholders for "Concurrent work and resolving edit conflicts" and "Pull requests and collaborat…

Hmmm, interesting. It is getting a bit philosophical: you can view it as a conflict. But you can also view it as: hm we have these nice 2 main functions. Let's create a merged one. Kind of what was previously conflict resolution becomes part of regular programming... A slight perspective change.

Re: The Unison language

#14

Post by tasogare »

alipang wrote: post #4

Algebraic 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 wish Microsoft would invest in something like the koka language

Given the ML-like syntax of Unison, it would be nice to see F# taking some of the key ideas.

Re: The Unison language

#15

Post by mbrock »

nadam wrote: post #13
the_duke wrote: post #11

Earlier quoted context omitted.

Of course there are still conflicts everywhere. Developer A makes the button red, developer B changes the label from "OK" to "Accept", both inside the same function. You can't just pick one or the other, you have to combine the changes. Or two developers add two different fields to a type. Or ... Sadly the docs only have placeholders for "Concurrent work and resolving edit conflicts" and "Pull requests and collaborat…

Hmmm, interesting. It is getting a bit philosophical: you can view it as a conflict. But you can also view it as: hm we have these nice 2 main functions. Let's create a merged one. Kind of what was previously conflict resolution becomes part of regular programming... A slight perspective change.

Mostly they are just not relying on Git for conflict detection and resolution, but bringing it up into the Unison system itself, in order to deal with it more gracefully and intelligently.

Re: The Unison language

#17

Post by goranmoomin »

A TLDR for the tour[0] based on my understanding (please fix me if I’m wrong):

Unison is a functional language that treats a codebase as an content addressable database[1] where every ‘content’ is an definition. In Unison, the ‘codebase’ is a somewhat abstract concept (unlike other languages where a codebase is a set of files) where you can inject definitions, somewhat similar to a Lisp image.

One can think of a program as a graph where every node is a definition and a definition’s content can refer to other definitions. Unison content-addresses each node and aliases the address to a human-readable name.

This means you can replace a name with another definition, and since Unison knows the node a human-readable name is aliased to, you can exactly find every name’s use and replace them to another node. In practice I think this means very easy refactoring unlike today’s programming languages where it’s hard to find every use of an identifier.

I’m not sure how this can benefit in practical ways, but the concept itself is pretty interesting to see. I would like to see a better way to share a Unison codebase though, as it currently is only shareable in a format that resembles a .git folder (as git also is another CAS).

[0]: https://www.unisonweb.org/docs/tour

[1]: https://en.wikipedia.org/wiki/Content-addressable_storage

[2]: https://github.com/unisonweb/quickstart

PS: The website is very well made, but I would like to comment that there should be two buttons on the top front page, the tour and installation, as I think most people want to have a glimpse of the PL before installing. I, at least was puzzled because I thought the button was a link to an introduction of the language.

Re: The Unison language

#19

Post by the_duke »

emmanueloga_ wrote: post #16

"Unison: a new distributed programming language" by Paul Chiusano [1] 1: https://www.youtube.com/watch?v=gCWtkvDQ2ZI

This talk highlights the benefits and interesting features of Unison much better than the docs.

Highly recommended.

Re: The Unison language

#20

Post by tasogare »

Avi-D-coder wrote: post #18

I really like the idea, I like the language, but the world will not be rewritten in Unison. A web assembly FFI story is needed for Unison to succeed.

Is this satire? Web assembly has no real adoption on the browser yet, is waiting for a standard I/O interface on the desktop to be useful and is itself the nth iteration of an old concept.
Post reply on HN