pchiusano

The tooling takes a little getting used to but it’s extremely powerful. Here are a few benefits you’ll see -

UCM keeps a perfect incremental compilation cache as part of its codebase format, so you’re generally never waiting for code to build. When you pull from remote, there’s nothing to build either.

Pure tests are automatically cached rather than being run over and over.

Switching branches is instantaneous and doesn’t require recompiling.

Renaming is instantaneous, doesn’t break downstream usages, and doesn’t generate a huge text diff.

All code (and code diffs) are hyperlinked when rendered, supporting click through to definition.

I don’t know if you saw these getting started guides, they might be helpful -

We ourselves make use of this sort of thing since (for instance) Unison Cloud is implemented mostly in Unison but uses Haskell for a few things.

Related:

> sending code over the network to be executed elsewhere feels like a security risk to me?

I left out many details in my explanation and was just describing the core code syncing capability the language gives you. You can take a look at [2] to see what the core language primitives are - you can serialize values and code, ask their dependencies, deserialize them, and load them dynamically.

To turn that into a more industrial strength distributed computing platform, there are more pieces to it. For instance, you don't want to accept computations from anyone on the internet, only people who are authenticated. And you want sandboxing that lets you restrict the set of operations that dynamically loaded computations can use.

Within an app backend / deployed service, it is very useful to be able to fork computations onto other nodes and have that just work. But you likely won't directly expose this capability to the outside world, you instead expose services with a more limited API and which can only be used in safe ways.

I'll mention a couple things that might be relevant - you could have the git repo reference a branch or an immutable namespace hash on Unison Share. And as part of your git repo's CI, pull the Unison code and compile and/or deploy it or whatever you need to do.

There's support for webhooks on Unison Share as well, so you can do things like "open a PR to bump the dependency on the git repo whenever a new commit is pushed to branch XYZ on Unison Share".

Basically, with webhooks on GH and/or Unison Share and a bit of scripting you can set up whatever workflow you want.

    > crypto.hash Sha3_256 (x -> x + 1)
    ⧩
    0xs704e9cc41e9aa0beb70432cff0038753d07ebb7f5b4de236a7a0a53eec3fdbb5

We only do this caching for pure tests (which are deterministic and don't need to be re-run over and over), enforced by the type system. You can have regular I/O tests as well, and these are run every time. Projects typically have a mix of both kinds of tests.

It is true that you can only hash things which are "closed" / have no free variables. You might instead hash a function which takes its free variables as parameters.

Overall I think Unison would be a nice implementation language for really anything that needs to make interesting use of hashing, since it's just there and always available.