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

91–100 of 116 posts

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

#91

Post by daxfohl »

brabel wrote: post #10

I think they are making a mistake that's common in this sort of project: trying too many new things at once! They already have a very innovative way of managing source code, with a database of definitions that keeps the hash of the syntax tree instead of actual source. That's a very neat idea that solves many problems (read their docs to understand why). But instead of developing that well enough so that it works wit…

Sounds like `Opa!`, which was a language plus a meteor-like framework. The language itself was really nice with some interesting type-level features, but the built-in framework was the selling point. But all that ultimately got in the way for doing anything that wasn't built into it, which ended up being pretty much anything beyond toy prototypes. The language got dragged down because of it.

That said, it came out around the same time CoffeeScript did, and nobody uses CoffeeScript anymore either. So probably the fate was inevitable regardless of whether the framework was included in the language or not.

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

#92

Post by bigcat12345678 »

Sanjay already had a somewhat similar approach in managing the scheduling of concurrent RPCs, i.e., RPCs are enqueued, and a scheduler looks at the RPCs and figure out windowed batching order to optimize for the overall execution time (here the concurrent RPCs are interdependent).

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

#93

Post by msla »

stewoconnor wrote: post #77
msla wrote: post #70

Earlier quoted context omitted.

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?

One issue I was thinking of was companies that distribute code in binary form only, not ASTs or anything which could be used to steal their thoughts. The other issue was in reverse, however: A binary-only package is unmaintained and lists as dependencies hashes that no longer exist because they're the hashed versions of ASTs that, for one reason or another, the compiler won't generate, even if the source still exists. Versioning and archiving would help this case, at least.

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

#94

Post by dang »

woojoo666 wrote: post #71
dang wrote: post #13

Earlier quoted context omitted.

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)

whoa, the macroexpander (me) must have a bug. Added to the list now. Thanks!

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

#95

Post by bhawks »

bigcat12345678 wrote: post #92

Sanjay already had a somewhat similar approach in managing the scheduling of concurrent RPCs, i.e., RPCs are enqueued, and a scheduler looks at the RPCs and figure out windowed batching order to optimize for the overall execution time (here the concurrent RPCs are interdependent).

That sounds like a slightly different problem. Unison looks like any function can transparently cross network boundaries versus the efficient scheduling and dispatching of concurrent rpcs.

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

#96

Post by ghc »

nerdponx wrote: post #30
renox wrote: post #28

Earlier quoted context omitted.

I disagree, there's no real relationship between 'content addressable' source code and distributed computing. Also I don't think that you need to create a new language to have 'content addressable' source code distribution.. Creating yet another language ensure that this will get nowhere, too bad.

My impression is that the original use case was distributed computing, and the content-addressable stuff took on a life of its own after that.

This is completely correct. Unison was always a distributed computing project, even when it was just an idea.

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

#97

Post by ghc »

brabel wrote: post #10

I think they are making a mistake that's common in this sort of project: trying too many new things at once! They already have a very innovative way of managing source code, with a database of definitions that keeps the hash of the syntax tree instead of actual source. That's a very neat idea that solves many problems (read their docs to understand why). But instead of developing that well enough so that it works wit…

You have it backwards. The source code management (as a marketable feature) came at least one year and maybe two years after the distributed computing parts. The earliest Unison demos (circa 2016) were "build a distributed google crawler in just a few lines of code". I think the hashes were always a component, but not part of the real messaging for quite awhile.

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

#98

Post by muricula »

stewoconnor wrote: post #89
zawodnaya wrote: post #43

Earlier quoted context omitted.

You can simply expose an HTTP endpoint that receives the data. You wouldn't want to expose the internode protocol endpoint to the internet. That said, it wouldn't be as bad as it sounds. Unison is a purely functional language, so if you don't explicitly provide the ability to e.g. do arbitrary I/O, then other nodes will not be able to send you code that does I/O. It will not type-check.

Yes, we additionally have functions builtin to the runtime that let you evaluate a term before you evaluate it to make sure it doesn't call any "forbidden" functions. So in our cloud runtime, we blacklist EVERY IO function, then we can in our cloud runtime give you back the ability to do, for example, http requests, but not any other network IO. We won't let you open arbitrary files, but we'll provide ephemeral / per…

Re the http endpoint, that's well and good, it just requires serialization and deserialization to a different protocol at the endpoint, which the docs led me to believe you wanted to avoid.

There is probably an opportunity here to do interesting work around authenticating and validating computations from remote clients.

A word of caution -- javascript engines routinely get hacked, and once attackers can execute native code in the engine process they can call syscalls and have all of the rights of the underlying process. It may be useful to have some form of sandboxing of the language runtime for clients exposed to the internet or intranet. Additionally, Java & Ruby web servers routinely suffer from code injection when deserializing objects, which it seems like your language may be prone to as well.

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

#99

Post by ModernMech »

klabb3 wrote: post #48
toolslive wrote: post #20

Nil nove sub sole ? It reeks of COOLs (Concurrent Object Oriented Languages). Here's an example of the mid 90s: https://distrinet.cs.kuleuven.be/projects/CORRELATE/

Object oriented? Unison looks pretty functional to me. And I don't see the content addressability, which is arguably the most important part. Anyway, you'll very rarely see completely novel ideas in this space. Good combinations, compromises and applications matters a lot. Look at your favorite applied Merkle tree tool.

> Good combinations, compromises and applications matter a lot

An understatement — I’d say when it comes to language design, this is pretty much the whole game right here.

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

#100

Post by nanomonkey »

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…

In lisp there are symbols and lists. The symbols could be pointers to content addressable hashes, or in-lined content. So in the namespace you could require the library by its content addressable hash, and give it a symbol definition, or just refer to the hash itself.
Post reply on HN