111–116 of 116 posts
Earlier quoted context omitted.
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?
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.
It's a common approach in language design to require this though. Rust has made very similar design choices due to its (current) lack of stable ABIs. IIRC some hash of the compiler version is included in built libraries and prevents accidental linking. You need to rebuild the world for every toolchain upgrade.
Earlier quoted context omitted.
(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?
I had to dig for the distributed part but it's outlined here: https://www.unison-lang.org/articles/distributed-datasets/
But the only runtime available for this sort of application seems to be the "unison cloud" that is a hosted service.
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 one thing identified as “the big idea” of Unison seems to me to be conceived as a solution to a distributed computing problem that incidentally also solves a number of problems that are issues outside of distributed computing (but also within distributed computing, such that fleshing out how it can solve them enhances unison as distributed computing solutions as well as providing side benefits.)