Live data from Hacker News

The Unison language – a new approach to Distributed programming

unison-lang.org

51–60 of 116 posts

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

#51
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…

If we want to set sail on the ocean, we do not take a basket and start work to stop it from leaking. We build a boat.

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

#52
post #23

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.

Agreed, I think it's great to have really cutting-edge, highly experimental sort of research languages that explore new paradigms. Doesn't mean you have to like the language, but I think it's good that some people are doing this kind of work as a going concern and not just some repo that was pushed up once somewhere and languishes. He's got some interesting ideas in there related to effects system, etc.

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

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

What's an example of a pretty language?

I don't think this language is ugly and it is indeed hard to say which language is objectively beautiful, but I personally have always disliked syntax that uses the ' operator for some reason. It's small - it looks like a piece of dirt on the screen, which makes it hard to read. I imagine the same arguments could apply to the '.' or ',' operators, though ' tends to appear around whitespace, while ./, around characters, so there's at least some contextual information around them.

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

#54

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?

The key idea is that Unison code is in a sort of "normal form", such that e.g. what names you give things doesn't matter at all.

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

#55

- Function definitions stored in a content-addressed database. - Dependency management handled the same way the Nix handles it. - Some kind of object storage system that uses content-addressable structures as the schema. - Hyperlinked codebase. - Human-readable function names as (essentially) git tags. These ideas are all pretty nice. A dedicated IDE for this language would be a lot of fun to work with. The debugging…

I think that content addressability works really well for code, at the bottom layer. But in order to be practical, you typically need:

Naming and resolvers, in order to be human friendly. This isn't easy to get right, but we have a lot of prior art in dependency management systems.

Persistence layers with GC, like cache and db. You're gonna want to fetch and prefetch in ways that are quite advanced. You don't want to be be blocked in a critical section by network fetching the leftpad function.

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

#56

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?

Well, it could be done in JS or Lisp. You'd have to replace all the references to dependencies in every function with a hash of the implementation of the referenced function and use some kind of global lookup table (which would need to be a distributed hash table or something). But this would be slow, so you'd need a compiler or some kind of processor to inline stuff and do CPS transforms, and by that time you've basically implemented a janky version of Unison.

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

#57
post #44

Earlier quoted context omitted.

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

How about wasm? Interop de lux

An issue with exchanging WASM is you'll have to do either dynamic or static linking of dependencies. Unison works around this by having all definitions share a global address space (and the address of any given code in that space is the hash of its syntax tree), so there is no linking step. Or rather, the linking is done trivially by the hashing.

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

#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?

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

#60

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?

The latter.
Post reply on HN