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

11–20 of 116 posts

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

#11

Post by dack »

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…

To be fair, for a while they were ALSO working on their own graphical source editor that allowed for type-correct transformations and assisted refactorings. They put that on the back burner specifically because they are trying to focus on fewer things :)

I think the distributed computing problem is pretty related once you have "content-addressable" source code. Agreed that it's a lot of work but I hope it pans out!

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

#12

Post by junon »

6gvONxR4sf7o wrote: post #7

I’m excited for ideas like this to become mainstream. Today’s approaches to heterogeneous and distributed computing are how I imagine single core computing was 40 years ago. You have to manually manage practically everything. Instead, let the compiler or interpreter or whatever figure out where to actually run it (CPU vs ALU vs GPU vs remote machine #42), what to keep in what part of cache (L1 vs L2 vs RAM vs disk vs…

We have, though. Spark, for example, does this in just about every language. It's been around for ages, is liberally licensed, and deployed at scale in thousands of enterprises.

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

#13

Post by dang »

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.ycombinator.com/item?id=20807997 - Aug 2019 (25 comments)

Unison Language March Update - https://news.ycombinator.com/item?id=19528189 - March 2019 (1 comment)

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

#16

Post by iamevn »

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.

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

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

#17

Post by xwowsersx »

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…

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!

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

#18

Post by cmollis »

junon wrote: post #12
6gvONxR4sf7o wrote: post #7

I’m excited for ideas like this to become mainstream. Today’s approaches to heterogeneous and distributed computing are how I imagine single core computing was 40 years ago. You have to manually manage practically everything. Instead, let the compiler or interpreter or whatever figure out where to actually run it (CPU vs ALU vs GPU vs remote machine #42), what to keep in what part of cache (L1 vs L2 vs RAM vs disk vs…

We have, though. Spark, for example, does this in just about every language. It's been around for ages, is liberally licensed, and deployed at scale in thousands of enterprises.

spark is great for distributed computation.. also has about a million config switches and is generally kind of 'bulky'. EMR makes management a lot easier, but you still have to fiddle with num executors, memory, etc. But it has been 'through the wars' and is generally pretty solid on some pretty large data sets. Once you get it conf'd it's pretty good. The best part is just writing the scala code to run the job.. admittedly, it would be great to use something a bit lighter for certain workloads.

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

#19

Post by samsquire »

This project hashing of sourcecode (or AST) in the interpreter is a really powerful idea

I plan to use it for a slightly different purpose. I want to implement an interpreter that is multithreaded similar to Java or Erlang that can send objects between shared memory without marshalling or copying.

I had a talk with someone on HN https://news.ycombinator.com/item?id=32907523 about python's Global Interpreter Lock and we talked about how objects are marshalled between subinterpreters due to object identity. The identity of an object is defined at creation time as the hash of that object.

If the hash of the object was the sourcecode, two interpreters could load the same Object hierarchy and send data by hash reference.

I wrote a multithreaded interpreter that uses message passing to send integers and program counters to jump to code in other threads

This is at https://GitHub.com/samsquire/multiversion-concurrency-contro...

Post reply on HN