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

The Unison language – a new approach to Distributed programming

unison-lang.org

Post reply on HN
Print view View original

101–110 of 116 posts

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

#101

Post by dwohnitmok »

stewoconnor wrote: post #82
dwohnitmok wrote: post #79

Earlier quoted context omitted.

> 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 wit…

Thanks for the reply :) > 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? I mean, not necessarily. Something that handles a `'{Abort} a` doesn't necessarily produce an `Optional a`. It could produce a Boolean, it could produce an Int, whatever. This is really up to the handler. But I still d…

Maybe I'm misunderstanding how abilities work, but I think I can break Exception.bracket with this right?

I think if I pass something that has e.g. `{Abort, Exception, IO}` to `bracket` and then handle Exception before Abort, my Abort handler can break out of `bracket` before the finalizer action can run.

More generally I must always process any ability with a "bracket"-like function last to prevent this from happening right? And if I have multiple abilities that all have "bracket"-like functions they can step on each other's toes?

Even more generally I think any sort of "scoped" function in an ability has this problem.

This theoretically seems scary (imagine you have some big complicated action that does some bracket deep under the covers to e.g. release file handles; if I handle abilities in the wrong order the file handles might not ever be released, even if I have individually reasonable ability-handler pairs that locally don't do anything silly), but I'm not sure practically how often this comes up, and how much "just always handle Exception last" fixes that (i.e. how unlikely it is for any other ability to have a bracket function).

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

#102

Post by galaxyLogic »

iamevn wrote: post #16
thefaux wrote: post #8

Earlier quoted context omitted.

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.

While hashes are the primary identifier, things also generally have names associated with them. (Unless you deliberately remove the names that is.)

Sounds oddly much like git. Git-commits are identified by hashes.

And git commits "are" (versions of) programs.

So what does Unison have that git does not?

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

#103

Post by zawodnaya »

dwohnitmok wrote: post #101
stewoconnor wrote: post #82

Earlier quoted context omitted.

Thanks for the reply :) > 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? I mean, not necessarily. Something that handles a `'{Abort} a` doesn't necessarily produce an `Optional a`. It could produce a Boolean, it could produce an Int, whatever. This is really up to the handler. But I still d…

Maybe I'm misunderstanding how abilities work, but I think I can break Exception.bracket with this right? I think if I pass something that has e.g. `{Abort, Exception, IO}` to `bracket` and then handle Exception before Abort, my Abort handler can break out of `bracket` before the finalizer action can run. More generally I must always process any ability with a "bracket"-like function last to prevent this from happeni…

This is true, if you write `bracket` for e.g. `Exception`, then you can break out of the bracket with `abort` if your bracket doesn't handle aborts.

So if you want to be really sure of resource cleanup, you should use something like the `Resource` ability to acquire resources:

https://share.unison-lang.org/@runarorama/code/latest/namesp...

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

#104

Post by cwalv »

msla wrote: post #63
jupp0r wrote: post #49

Earlier quoted context omitted.

The two areas of managing source code and distributed computing are not as disjunct as you make them in the context of Unison. They follow from the underlying principle of addressing functions not by their name but by a hash of their normalized syntax tree (ie their code). There are a bunch of cool implications for distributed computing, namely that you can easily distribute fine grained parts of your application acr…

> They follow from the underlying principle of addressing functions not by their name but by a hash of their normalized syntax tree (ie their code). The first time the language or compiler changes such that the same code generates a different syntax tree they'd have to do something pretty fancy to avoid rebuilding the world. (That, plus all the usual caveats about what happens when old hash algorithms meet malicious…

Also if you change one very low level function (maybe something in the runtime, Unicode handling etc.) you'd also have to recompile the world. In some ways it's nice to reference things by a name, and let the implementation change without needing to care about the details. It's semver's raison d'etre

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

#105

Post by dwohnitmok »

zawodnaya wrote: post #103
dwohnitmok wrote: post #101

Earlier quoted context omitted.

Maybe I'm misunderstanding how abilities work, but I think I can break Exception.bracket with this right? I think if I pass something that has e.g. `{Abort, Exception, IO}` to `bracket` and then handle Exception before Abort, my Abort handler can break out of `bracket` before the finalizer action can run. More generally I must always process any ability with a "bracket"-like function last to prevent this from happeni…

This is true, if you write `bracket` for e.g. `Exception`, then you can break out of the bracket with `abort` if your bracket doesn't handle aborts. So if you want to be really sure of resource cleanup, you should use something like the `Resource` ability to acquire resources: https://share.unison-lang.org/@runarorama/code/latest/namesp...

Got it. But you're locked into IO and Exception then and can't use any other abilities right? I guess you could always convert back and forth at the `run` boundary.

Also I would suggest removing Exception.bracket from base then, or at least changing the file handle example for Exception.bracket, since it seems a tad dangerous.

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

#106

Post by [deleted] »

stewoconnor wrote: post #88
actionfromafar wrote: post #80

Earlier quoted context omitted.

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 l…

I'm not totally up to date on lisp and don't know anything about PicoLisp, so forgive me if there is stuff I'm missing :) but lemme try: Lets say you wrote a imaginary program to sum a column in a csv: (defun my-program () (let* ((raw-data) (s3-load-file "htpps://...")) ((parsed) (csv-parse raw-data)) ((column1) (csv-column parsed 1)) (mean column1)) In this pretend program we are using some 3rd party s3 library to f…

[deleted]

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

#107

Post by actionfromafar »

stewoconnor wrote: post #88
actionfromafar wrote: post #80

Earlier quoted context omitted.

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 l…

I'm not totally up to date on lisp and don't know anything about PicoLisp, so forgive me if there is stuff I'm missing :) but lemme try: Lets say you wrote a imaginary program to sum a column in a csv: (defun my-program () (let* ((raw-data) (s3-load-file "htpps://...")) ((parsed) (csv-parse raw-data)) ((column1) (csv-column parsed 1)) (mean column1)) In this pretend program we are using some 3rd party s3 library to f…

I'm not saying there exists a Lisp with a turn-key distributed cloud runtime. Like the sibling answer, I'm saying, it's not super complicated. Instead of loading an .so file the regular way, load it via hash.

The car/cdr nature of Lisp makes it almost uniquely suited to distributed runtime IMHO.

As for your last sentence, this touches on compilation. Solve this, and you solve also dependency detection and compilation. I feel there are so many things which could/should converge at some point in the future. IDE / version control, distributed compute, storage.

An AST (or source) program could have a hash, which is corresponding in a cache to a compiled or JIT-ed version of that compilation unit, and various eval results of that unit etc etc. So many things collapse into one once your started to treat everything as key/value.

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

#108

Post by pharmakom »

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…

Is Unsion committed to pure functions in order to support this?

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

#109

Post by mikewarot »

Can someone please ELI 5 for me how to get started?

I downloaded and ran it, it created folders NOT where I told it to, and started.... but no command I type seems to result in anything other than an error message.

How can I get it to add 5+5, without using an external editor?

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

#110

Post by iamevn »

mikewarot wrote: post #109

Can someone please ELI 5 for me how to get started? I downloaded and ran it, it created folders NOT where I told it to, and started.... but no command I type seems to result in anything other than an error message. How can I get it to add 5+5, without using an external editor?

You're not going to just be able to write code into ucm (unison code manager) because it's not a repl. You'll need some sort of text editor to actually write the code it will then add to the codebase.

https://www.unison-lang.org/learn/quickstart/

If this quick start tutorial doesn't work for you then there's a bug on unison's end.

Post reply on HN