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…
The Unison language – a new approach to Distributed programming
51–60 of 116 posts
Re: The Unison language – a new approach to Distributed programming
#52Earlier 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.
Re: The Unison language – a new approach to Distributed programming
#53I 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?
Re: The Unison language – a new approach to Distributed programming
#54Earlier 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?
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…
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
#56Earlier 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?
Re: The Unison language – a new approach to Distributed programming
#57Earlier quoted context omitted.
Would this not work just as well with a lisp or even JS?
How about wasm? Interop de lux
Re: The Unison language – a new approach to Distributed programming
#58Re: The Unison language – a new approach to Distributed programming
#59Re: The Unison language – a new approach to Distributed programming
#60How 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?