I'll keep it on my radar, because at an intellectual level it seems pretty interesting. But this smells a bit of "fun computer science, not terribly useful software engineering."<p>Firstly, my experience with Haskell left me pretty skeptical of pure programming languages. They're just that much harder to grok; debugging becomes harder (though it looks like this language has log functions, so it's not <i>totally</i> pure FP?), `for` loops are just easier to think about than folding, etc.<p>But beyond that, the problems this language tries to address just don't seem like the real problems I face. Let's take a few:<p>• distributed programming: shipping bits of opcode (whether it's machine code, Java bytecode, etc) is easy. The hard part is knowing <i>which</i> bits to distribute where, especially when they have to operate on shared state. I don't see how hashing ASTs helps with that.<p>• no builds: I mean sure, that's nice I guess. But tbh, I spend very little of my day or mental energy waiting for compilation.<p>• dependency conflicts: The bad ones of these don't arise from name conflicts — those are easy to get around. The bigger problems are things like two dependencies that each depend on different versions of the same library, and you want them to communicate: you want DepA to talk to DepB via some object defined in DepC that they both use, but DepA and DepB use different and incompatible versions of DepC. Hashing doesn't seem to fix this.<p>Now, that doesn't mean people shouldn't learn this, especially if they find it interesting. I don't use Haskell at all, but I think I'm a better programmer for having learned it, because it made me think of things in a new way. This language could well be similar — but I don't see it replacing mainstream languages.