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

91–100 of 144 posts

Re: The Unison language

#91

Post by aidenn0 »

steve_taylor wrote: post #8
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…

> 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.

So I append X to my file and you append Y to your file, do we not have a conflict?

Re: The Unison language

#93

Post by capableweb »

aidenn0 wrote: post #91
steve_taylor wrote: post #8

Earlier quoted context omitted.

> 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.

So I append X to my file and you append Y to your file, do we not have a conflict?

Yes and no. Yes as in, if you'd like them to be merged into a new one, then you'll have to resolve a conflict. But no as in, you both appended different data, so you both have new files from the original one, as you're dealing with immutable data.

Re: The Unison language

#94

Post by capableweb »

the_duke wrote: post #19
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.

The video is from Sep 15, 2019 and still more useful than their website? Anyone have a transcript to link?

Re: The Unison language

#95

Post by frenchyatwork »

elcomet wrote: post #63
vidarh wrote: post #59

Earlier quoted context omitted.

Syntax stops me from even considering some languages, because to a lot of us it is important. I spend most of working hours reading code; as a result how easy it is to read is important not just for my productivity, but for my overall happiness in life. A small sample on the front page will not tell me if a language is good enough, but it can give me an idea if it's worth spending more time reading up on it or not.

Syntax is something you become used to in a few hours. But it's not what's the most important and will make your time more efficient in the end.

2000 years ago, they didn't have spaces or punctuation in writing. We could try dropping them again, and people would adjust after a few hours, but that doesn't mean that the spaces and punctuation don't provide value.

Re: The Unison language

#97

Post by ed »

zubairq wrote: post #89
nadam wrote: post #43

I find the content-addressed, name-independent, immutable (kind of blockchainy) approach to source code very interesting. On the other hand this seems to be rather orthogonal to other (semantic) aspects of the language. I wonder what would happen if we would change one thing at a time to test the idea: create something like unison based on an existing popular programming language. (python, javascript, java, etc...) A…

I have done exactly that with a language called Pilot. It is not pure JS but based on JavaScript and all code is content addressable and indexed by the sha256 of the code

Google isn't turning up much. Is the project open source? Would love to take a look.

Re: The Unison language

#98

Post by war1025 »

Maybe I'm missing something, but this seems like it would get unwieldy very quickly for anything more serious than toy examples.

Even the toy examples I'm having trouble following along with.

The benefit of code-as-text is that you can navigate the text without knowing what you are looking for.

This seems to take the opposite approach of making it very easy to look things up assuming you know ahead of time what you are looking for.

That is something that a good usage of grep or some more sophisticated IDE integration will already take care of for you.

The only thing I could see this being potentially useful for is "notebook" style computation, where you are really only using the language to do things like structured math calculations.

What am I missing here?

Re: The Unison language

#99

Post by tracnar »

thethimble wrote: post #92

Does anyone know how concurrency is handled on Unison? I couldn't find any references in the docs.

There's an example in this talk: https://youtu.be/gCWtkvDQ2ZI?t=1903

Basically you can quote code (like in Lisp) and pass it to an executor (thread, remote server, ...).

The main difference is that thanks to the immutability, you can also have a protocol which shares efficiently all the dependencies required to execute the code (like a git pull).

It also uses an effect system, so the implementation does not need to decide which executor to use, it only uses an interface called an "ability", and the caller can choose the implementation.

Re: The Unison language

#100

Post by rzwitserloot »

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…

If it works precisely as you say, then most likely the last committer wins, and that's bad.

The most hopeful case is that there is ONE place that isn't 'strictly append only', and that's, for lack of a better term, the 'main pointer'. Which hash is the actual state of the app as it should be compiled and deployed right now?

Then THAT conflict, together with tooling to diff 2 different hashes, should swiftly lead to figuring it out.

But then you're still kinda hosed; how do you merge 2 nodes? It sounds like you can't; you can only pick one. With git, you can do a text merge.

I get the beauty of AST based storage and reasoning, but, hey, trying to use git to merge 2 versions of a word doc together is also a disaster, so it sounds like it'd be the same here.

In that sense, unison is worse than your average (text based) language, not better.

That's not actually a downside though; it's different. If I demerited the language for this, that's akin to complaining about a delicious roasted bell pepper because it doesn't taste anything like an onion.

But I do find it a spot irksome that the otherwise well written tour is implying something here that doesn't appear to be true. Perhaps I'm merely misinterpreting it and reading more into that sentence than is implied.

Post reply on HN