The Unison language – a new approach to Distributed programming • Hacker News Board

Re: The Unison language – a new approach to Distributed programming

#71

Post by woojoo666 » Thu, Nov 17, 2022, 10:26 PM UTC

dang wrote: post #13

anthropodie wrote: post #6

Discussion from - a year ago https://news.ycombinator.com/item?id=27652677 - 8 years ago https://news.ycombinator.com/item?id=9512955

Thanks! Macroexpanded: Unison Programming Language - https://news.ycombinator.com/item?id=27652677 - June 2021 (131 comments) Unison: A Content-Addressable Programming Language - https://news.ycombinator.com/item?id=22156370 - Jan 2020 (12 comments) The Unison language - https://news.ycombinator.com/item?id=22009912 - Jan 2020 (141 comments) Unison – A statically-typed purely functional language - https://news.ycombi…

And the one from 8 years ago:

Unison: a next-generation programming platform - https://news.ycombinator.com/item?id=9512955 - May 2015 (128 comments)

Re: The Unison language – a new approach to Distributed programming

#72

Post by xwowsersx » Thu, Nov 17, 2022, 10:28 PM UTC

jrumbut wrote: post #23

xwowsersx wrote: post #17

Earlier quoted context omitted.

I thought that was sort of Paul's goal, to explore a bunch of new ideas and paradigms. I doubt he's under any illusions that this language, qua this language, is going to see wide adoption or need to have all of its features really ironed out with a fixed/stable API. But I could be wrong!

Then that flips it back to being very cool that he is putting his energy into carrying a few batons far enough for others to pick them up.

> carrying a few batons far enough for others to pick them up.

I love that metaphor btw. Gonna use that.

Re: The Unison language – a new approach to Distributed programming

#73

Post by stewoconnor » Thu, Nov 17, 2022, 10:31 PM UTC

pharmakom wrote: post #40

zawodnaya wrote: post #35

Earlier quoted context omitted.

Well, there is a relationship. The relationship is specifically that Unison nodes can communicate code with one another unambiguously by exchanging hashes.

Would this not work just as well with a lisp or even JS?

(I'm the a Unison employee that works mostly on distributed computing)

There are a few things about unison that make this easier:

* content addressed code * unison can serialize any closure

I can ask for a serialized version of any closure, and get back something that is portable to another runtime. So in a function, I can create a lambda that closes over some local variables in my function, ask the runtime for the code for this closure and send it to a remote node for execution. It won't be a serialized version of my entire program and all of its dependencies, it will be a hash of a tree, which is a tree of other hashes.

The remote node can inspect the tree and ask for or gossip to find out the definitions for whatever hashes in that tree it doesn't already know about. It can inspect the node for any forbidden hashes (for example, you can'd do arbitrary IO), then the remote node can evaluate the closure, and return a result.

In other langauges, perhaps you can dynmically ship code around to be dynamically exeecuted, but you aren't going to also get "and of course ship all the transitive dependencies of this closure as needed" as easily as we are able to.

Re: The Unison language – a new approach to Distributed programming

#74

Post by stewoconnor » Thu, Nov 17, 2022, 10:35 PM UTC

thefaux wrote: post #8

revskill wrote: post #4

"Each Unison definition is identified by a hash of its syntax tree." [0] I remember many years ago, i had the same idea on how to correctly version a dependency. [0]: https://www.unison-lang.org/learn/the-big-idea/

Does Unison have stack traces? Using the hash of the ast as the only identifier seems like it would lose some useful runtime debugging information.

Yes, we have stack traces. You might see some hashes in the middle of the stack traces, but whenever we do have a name, we'll show you the name. So if you are calling into an anonymous clousure, but functions in your call stack will typically have names available

Re: The Unison language – a new approach to Distributed programming

#75

Post by jupp0r » Thu, Nov 17, 2022, 10:36 PM UTC

msla wrote: post #70

stewoconnor wrote: post #68

Earlier quoted context omitted.

(Unison Developer here), yes we've done two such migrations this year. It has typically meant that we have an "are you ready to upgrade" message when you start up and the migration took less than a minute on my pretty large codebase. It's not a big deal

It's a solved problem technically, certainly, but assuming all of the relevant source code will always be available ignores some social and legal issues.

It's a common approach in language design to require this though. Rust has made very similar design choices due to its (current) lack of stable ABIs. IIRC some hash of the compiler version is included in built libraries and prevents accidental linking. You need to rebuild the world for every toolchain upgrade.

Re: The Unison language – a new approach to Distributed programming

#76

Post by stewoconnor » Thu, Nov 17, 2022, 10:42 PM UTC

vitiral wrote: post #33

mgax wrote: post #15

I LOVE the idea but the language itself is so ugly I don’t want to learn it. It looks really ugly. Sorry.

It's ML syntax. I'm also not used to it, but many who are consider it beautiful.

Its certainly a turn-off for some. One thing that we have as a potential future effort would be to enable an alternate surface syntax. Since we store an AST insteead of source code, we could create a parser/pretty printer for another surface syntax. Then a user of the language who would prefer something that looked like python could switch our website's renderer to output the python like syntax!

Re: The Unison language – a new approach to Distributed programming

#77

Post by stewoconnor » Thu, Nov 17, 2022, 10:45 PM UTC

msla wrote: post #70

stewoconnor wrote: post #68

Earlier quoted context omitted.

(Unison Developer here), yes we've done two such migrations this year. It has typically meant that we have an "are you ready to upgrade" message when you start up and the migration took less than a minute on my pretty large codebase. It's not a big deal

It's a solved problem technically, certainly, but assuming all of the relevant source code will always be available ignores some social and legal issues.

The relevant sourcecode is not available, we don't store any source code. All the relevant dependences MUST be availble in AST form though.

I don't know what the social and legal issues might possibly be, though I might be missing somehting, what do you have in mind there?

Re: The Unison language – a new approach to Distributed programming

#78

Post by stewoconnor » Thu, Nov 17, 2022, 11:12 PM UTC

dwohnitmok wrote: post #58

How do Unison abilities handle non-commutative abilities (i.e. abilities where the order in which one applies handlers matters). Does it just assume that abilities are commutative? Or rely on the programmer to make sure that handlers are applied in an order that makes sense?

It is up to the code handling the abilities to decide in which order to handle the abilities (or to handle them all at once).

I can't think of any cases where it would make a difference in which order they were handled, however. Can you?

I think perhaps it might in the case where abilities themselves were able to make requests of other abilities, but that's not something allowed by our type system currently

Re: The Unison language – a new approach to Distributed programming

#79

Post by dwohnitmok » Thu, Nov 17, 2022, 11:34 PM UTC

stewoconnor wrote: post #78

dwohnitmok wrote: post #58

How do Unison abilities handle non-commutative abilities (i.e. abilities where the order in which one applies handlers matters). Does it just assume that abilities are commutative? Or rely on the programmer to make sure that handlers are applied in an order that makes sense?

It is up to the code handling the abilities to decide in which order to handle the abilities (or to handle them all at once). I can't think of any cases where it would make a difference in which order they were handled, however. Can you? I think perhaps it might in the case where abilities themselves were able to make requests of other abilities, but that's not something allowed by our type system currently

> I can't think of any cases where it would make a difference in which order they were handled, however. Can you?

Presumably

  someAction : '{Choose, Abort} a

if it's handled by `Choose.toList` and then `Abort.toOptional` in that order you end up with `Optional [a]` whereas if you do in the other order you have `[Optional a]` right?

N.B. the reason this is theoretically important is that `someAction` may be written with the assumption of e.g. certain short-circuiting behavior in mind and the "wrong" order of handlers might cause different short-circuiting behavior. In other words there's no consistent semantic interpretation you can assign to `someAction` even if you establish certain invariants that your abilities and ability handlers individually satisfy, since the global configuration of your ability handler changes what `someAction` means.

I think the jury is still out on whether this is a practical issue for any language that doesn't try to focus too hard on code having formal semantics (which is most real-world languages). I can definitely craft "real-looking" code that would be buggy depending on the order of handlers, but I'm not personally sure how much of a problem that actually would be for people familiar with the issue.

Re: The Unison language – a new approach to Distributed programming

#80

Post by actionfromafar » Thu, Nov 17, 2022, 11:53 PM UTC

stewoconnor wrote: post #73

pharmakom wrote: post #40

Earlier quoted context omitted.

Would this not work just as well with a lisp or even JS?

(I'm the a Unison employee that works mostly on distributed computing) There are a few things about unison that make this easier: * content addressed code * unison can serialize any closure I can ask for a serialized version of any closure, and get back something that is portable to another runtime. So in a function, I can create a lambda that closes over some local variables in my function, ask the runtime for the c…

In a simple Lisp machine, such as something resembling PicoLisp, I can't see why not - iff instead of car and cdr being just linear addresses in a memory, have them itself be hashes.

Since everything is made up from car and cdr, it's easy going from there. There is no difference between running locally, or anywhere. Just look up the data by request or gossip, as you said.

(For performance reasons, one might want to let a cons which represents "source" smaller than the size of a hash, be a literal representation instead of hashed. No need to do a lookup from a hash when you can have the code/data in the cons itself. Analoguous, don't zip a file when the resulting zip would be larger.)