zawodnaya

Yes, unison detects this condition when it occurs and tells you about it.

Or like a whole language to handle them

Unison doesn't have type classes yet, no

The language and all the libraries are open source. The storage layer API is open-source as well though the implementation is proprietary, as is the implementation of other parts of Unison Cloud (like the part that actually hosts your Unison code on AWS).

There is source control on https://share.unison-lang.org/

It’s a binary-encoded merkle tree

It’s bytecode

The UCM tool propagates the changes for you automatically. It also creates a patch that you can distribute with your release to update any dependents automatically.

If the change can’t be made automatically because it breaks stuff, then UCM guides you through propagating manually.

You’d have to do this manual propagation in any language. Unison is a little nicer about it than most languages, since it just tells you what needs an update (and will suggest an order in which to make the updates) instead of giving you type errors or test failures.

Yeah, Unison doesn’t just infer the types, it will add type signatures automatically to top-level definitions.

Yes, Unison is a purely functional language.

This is true, if you write `bracket` for e.g. `Exception`, then you can break out of the bracket with `abort` if your bracket doesn't handle aborts.

So if you want to be really sure of resource cleanup, you should use something like the `Resource` ability to acquire resources:

https://share.unison-lang.org/@runarorama/code/latest/namesp...

The latter.

An issue with exchanging WASM is you'll have to do either dynamic or static linking of dependencies. Unison works around this by having all definitions share a global address space (and the address of any given code in that space is the hash of its syntax tree), so there is no linking step. Or rather, the linking is done trivially by the hashing.

Well, it could be done in JS or Lisp. You'd have to replace all the references to dependencies in every function with a hash of the implementation of the referenced function and use some kind of global lookup table (which would need to be a distributed hash table or something). But this would be slow, so you'd need a compiler or some kind of processor to inline stuff and do CPS transforms, and by that time you've basically implemented a janky version of Unison.

Good news: the surface syntax of Unison is totally arbitrary and can in practice be swapped out. There's currently only one (Haskell-like) syntax, but in future I imagine there will be others. So you can imagine on https://share.unison-lang.org a little dropdown that lets you select what syntax you want to see the code in.

You can simply expose an HTTP endpoint that receives the data. You wouldn't want to expose the internode protocol endpoint to the internet.

That said, it wouldn't be as bad as it sounds. Unison is a purely functional language, so if you don't explicitly provide the ability to e.g. do arbitrary I/O, then other nodes will not be able to send you code that does I/O. It will not type-check.

Smalltalk had a lot of good ideas!

Well, there is a relationship. The relationship is specifically that Unison nodes can communicate code with one another unambiguously by exchanging hashes.

What's an example of a pretty language?

Well, Spark does allow you to accomplish distributed workloads for certain forms of computation. But it's limited to those forms of computations (streaming, map-reduce). It also has a large operational footprint. It's also lamentable that distributed code that uses Spark looks nothing like its non-distributed counterpart.

Something very much like Spark map-reduce can be implemented in ~100 lines of Unison code:

https://www.unison-lang.org/articles/distributed-datasets/

Some videos on Unison's capabilities over and above Spark:

Distributed programming overview: https://www.youtube.com/watch?v=ZhoxQGzFhV8

Collaborative data structures (CRDTs): https://www.youtube.com/watch?v=xc4V2WhGMy4

Distributed data types: https://www.youtube.com/watch?v=rOO2gtkoZ3M

Distributed global optimization with genetic algorithms: https://www.youtube.com/watch?v=qNShVqSbQJM

In practice it's a lot less annoying than navigating a file hierarchy and looking in text files that have a lot of things other than what you're looking for.

See also https://share.unison-lang.org/ where you can look at the base library, and some (contributed?) libraries as well.

This is the right idea. Conceptually there are conflicts which get resolved in the Unison tooling, but you will never get Git conflicts.

Unison is in alpha testing, so it's not used anywhere yet.

This may not be a very useful method for IMDB. If you follow this method you will be watching a lot of documentaries and movies made before 1970.