Since this announcement is about Unison Cloud, it might not be clear for people who aren't familiar with the Unison language that you can run Unison programs without Unison Cloud. So much like just about any other language you can put a Unison program in a Docker container, deploy it via AWS Lambda, etc. Unison Cloud is kind of an "easy mode" for scalable and distributed deployment with support for typed durable storage, the option to expose public HTTP/websocket endpoints, etc.
I use both Unison and Nix (and I work on Unison Cloud).
The "oh-so-good" aspect that comes from content-addressed dependencies is definitely there. I've spent a lot of time debugging runtime issues on the JVM because two libraries that I depend on disagree on what version of a common dependency should be on my classpath. This is not something you ever experience with Unison. In the runtime every term and type are identified by their hashes, so there's no (realistic) way that names can collide.
Otherwise, Unison and Nix feel pretty different to me. Nix is generally a build-time language for arbitrary runtimes, while Unison is a general purpose language for a specific runtime.
Nix takes on the really ambitious goal of wrangling ancient projects built with Makefiles and ambient environments into deterministic builds. Through the heroic effort of derivation authors, they've managed to make it work. But it requires those maintainers to do lots of careful manual tracking of dependencies, pre-build source patches, overriding build steps, etc.
Unison takes a much more constrained approach: if we start with a language that is content-addressed at its core and keep running with this idea, where do we end up? One nice outcome of this is that you never need to manually track dependency versions, hashes, etc; the language does that for you.
The "tough" part is also there, but feels different. To me the Nix expression language is straightforward, but I find it difficult to wrap my head around nontrivial derivations. To answer questions like "what attributes and build steps can/should I override" I feel like I have to dig through the layers of the implementation. In Unison a powerful static type system and UIs (both local and Unison Share) that support clicking through to any term/type make it easier for me to digest code. The "tough" parts of Unison generally stem from the young ecosystem: fewer existing libraries, a codebase manager that is under active development and not nearly as stable as git, etc.
If nothing else Unison is worth a try just because it is so different than most other languages/ecosystems.
PS if you are interested in usin Nix to install the Unison codebase manager or to package a program written in Unison these repos might be useful (disclaimer I'm ceedubs):
Don't have much to say other than I really love and appreciate this answer. This confirms my suspicions that I'm going to like Unison a lot. I get your point, but embracing the "try to imagine a better world, even if it does mean repackaging every piece of Linux software" part of Nix makes it easy for me to see that while Unison is different, the re-imagining gets you things you didn't even know you wanted.
Building upon what Quekid5 mentioned, Unison abilities are an implementation of what is referred to as algebraic effects in programming language literature. They represent capabilities like IO, state, exceptions, etc. They aren't really a replacement for type classes, though in some cases you can shoehorn abilities in where you might otherwise use a type class.
For someone coming from a Haskell background, I think that abilities are closer to a replacement for monad transformers. But in my opinion they are much more ergonomic.
For what it's worth, I've written Unison quite a lot over the past few years and while I've missed type classes at times, I think that reading unfamiliar code is easier without them. There's no implicit magic; you can see exactly what is being passed into a function. So far I've been happy with a bit more verbosity for the sake of readability.
Here is an example of containerizing a Unison program: https://github.com/ceedubs/containerized-unison-program
And here is a library that makes it easy to create an AWS Lambda out of a Unison function: https://share.unison-lang.org/@gfinol/lambda-runtime