So we put functional purity in your programming so you can program functionally pure while you program functionally pure programs.
I just took a better look at Unison. It's an interesting functionally pure language that stores supercombinators (the "variables" of functional pure programming) as SHA3-512 hashes of their content. This essentially means that functions cannot change. You might say that any possible function already exists, and functions are merely known or unknown. I'm assuming there are no hash conflicts, but the odds of one happening with 512-bit SHA3 hashes are rather low.
Unison makes the act of programming more-or-less functionally pure (there is no state to change and we don't produce output that might be non-deterministic). Their claim is that this is useful when dealing with renames, serialization, version conflicts in dependencies and concurrency with multiple nodes (non-shared MIMD).
The language has a lot of potential, but I wouldn't be me if I didn't criticize a definite improvement over the status quo. In particular, I see issues arise with side-effects, which will be necessary at some point.
Let's look at dependency version conflicts first. Under functional purity, versions don't matter one bit; just give each tool their own version of a dependency. Hashes-as-identifiers is not really necessary, any way to specify a version would work. On the other hand, if we do have side-effects, different versions of the same dependency might conflict with each other in unexpected ways.
Then there's non-shared MIMD. The proposed system would allow for easy live updates, but there's a catch. The concurrency presented here is one where one nodes passes an expression for evaluation to another node. This is a known possibility under functional purity. It may be useful for number-crunching computation, but data-flow languages and DSLs seem better suited to that problem. In regular business applications, I doubt this form of concurrency is going to yield great results. When we send an expression for evaluation to a different node, we want the expected cost of computation to be higher than the cost of communication, or there would not be any point to it. I don't encounter many such computations, unless they are statefull, as with database lookups, but that would make this form of concurrency unsafe. I'd be happy to be proven wrong though.
The improvements in renames and serialization look solid to me, but they don't seem like big issues compared to the cost of switching language.
All in all, Unison definitely looks interesting, but I am not yet convinced it's going to be the "next big thing" in FP land, or that it's going to get imperative programmers to learn FP.
Top comments (0)