I think they have other issues, for example, they have no FFI. I think focusing on the business is actually a pretty decent idea. Trying to make money will force them to focus on things that are important to users and not get distracted bike-shedding on things that I would if I were them (like typeclasses).

Yeah, the core ideas sound great, but if the only way code can be published and imported is via their cloud platform, that would be a hard pass for me.

Glancing at their docs, I see mentions of Unison Share, which is also hosted on unison-lang.org.

So I would appreciate this being clarified upfront in all their marketing and documentation.

Ah, I do see the BYOC option you mention. It still requires a unison.cloud account and an active subscription, though...

> Unison seems well-designed for this use case because it seems like you could easily run untrusted Unison code without worrying about it escaping its sandbox due to the ability system. (Although this obviously requires that you typecheck the code before running it. And I don't know if Unison does that, but maybe it does.)

Indeed we do, and we use this for our Unison Cloud project [1]. With unison cloud we are inviting users to ship code to our Cloud for us to execute, so we built primitives in the language for scanning a code blob and making sure it doesn't do IO [2]. In Unison Cloud, you cannot use the IO ability directly, so you can't, for example, read files off our filesystem. We instead give you access to very specific abilities to do IO that we can safely handly. So for example, there is a `Http` ability you can call in Cloud to make web requests, but we can make sure you aren't hitting anything you shouldn't

I'm also excited about using this specifically for games. I've been thinking about how you could make a game in unison cloud and another user could contribute to the game by implementing an ability as a native service, which just becomes a native function call at runtime. I started working on an ECS [3] a while back, but I haven't had a chance to do much with it yet.

[1] https://unison.cloud [2] https://share.unison-lang.org/@unison/base/code/releases/7.4... [3] https://share.unison-lang.org/@stew/ecs

Congrats on 1.0! I've been interested in Unison for a while now, since I saw it pop up years ago.

As an Elixir/Erlang programmer, the thing that caught my eye about it was how it seemed to really actually be exploring some high level ideas Joe Armstrong had talked about. I'm thinking of, I think, [0] and [1], around essentially a content-addressable functions. Was he at all an influence on the language, or was it kind of an independent discovery of the same ideas?

[0] https://groups.google.com/g/erlang-programming/c/LKLesmrss2k...

[1] https://joearms.github.io/published/2015-03-12-The_web_of_na...

I've been following Unison for a long time, congrats on the release!

Unison is among the first languages to ship algebraic effects (aka Abilities [1]) as a major feature. In early talks and blog posts, as I recall, you were still a bit unsure about how it would land. So how did it turn out? Are you happy with how effects interact with the rest of the language? Do you like the syntax? Can you share any interesting details about how it's implemented under the hood?

[1]: https://www.unison-lang.org/docs/fundamentals/abilities/

What is the data you actually store when caching a successful test run? Do you store the hash of the expression which is the test, and a value with a semantics of "passed". Or do you have a way to hash all values (not expressions/AST!) that Unison can produce?

I am asking because if you also have a way to cache all values, this might allow to carry some of Unison's nice properties a little further. Say I implement a compiler in Unison, I end up with an expression that has a free variable, which carries the source code of the program I am compiling.

Now, I could take the hash of the expression, the hash of the term that represents the source code, i.e., what the variable in my compiler binds to, and the hash of the output. Would be very neat for reproducibility, similar to content-addressed derivations in Nix, and extensible to distributed reproducibility like Trustix.

I guess you'll be inclined to say that this is out of scope for your caching, because your caching would only cache results of expressions where all variables are bound (at the top level, evaluating down). And you would be right. But the point is to bridge to the outside of Unison, at runtime, and make this just easy to do with Unison.

Feel free to just point me at material to read, I am completely new to this language and it might be obvious to you...

I'm curious about how the persistence primitives (OrderedTable, Table, etc) are implemented under the hood. Is it calling out to some other database service? Is it implemented in Unison itself? Seems like a really interesting composable set of primitives, together with the Database abstraction, but having a bit of a hard time wrapping my head around it!

Congratulations and amazing job! I've loosely followed Unison for years; hitting 1.0 is a big deal.

Unison has many intriguing features, the foremost being hashed definitions. It's an incredible paradigm shift.

It does seem like a solution searching for a problem right now though.

Who is this language targeted at and who is using it in production besides Unison Cloud?

Really cool project. To be honest, I think I don't fully understand the concept of a content addressed language. Initially I thought this was another BEAM language, but it seems to run on its own VM. How does Unison compare to BEAM languages when it comes to fault tolerance? What do you think is a use case that Unison shines that Erlang maybe falls short?

Hello! Yes I am curious, how does one deal with cycles in the code hash graph? Mutually recursive functions for example?

Hi there, and congrats on the launch. I've been following the project from the sidelines, as it has always seemed interesting.

Since everything in software engineering has tradeoffs, I have to ask: what are Unison's?

I've read about the potential benefits of its distributed approach, but surely there must be drawbacks that are worth considering. Does pulling these micro-dependencies or hashing every block of code introduce latency at runtime? Are there caching concerns w.r.t. staleness, invalidation, poisoning, etc.? I'm imagining different scenarios, and maybe these specific ones are not a concern, but I'd appreciate an honest answer about ones that are.

First, congratulations for the 1.0 milestone.

Then, a pretty basic question: I see that Unison has a quite radical design, but what problem does this design solves actually?

about time that gets a 1.0 release

That's still the case in Unison! This particular post doesn't dive into the codebase format, but the core idea is the same: Unison hashes your code by its AST and stores it in a database.

No, Unison has its own native version control, and a code sharing platform at https://share.unison-lang.org

The tool you use to interact with the code database keeps track of the changes in an append-only log - if you're familiar with git, the commands for tracking changes echo those of git (push, pull, merge, etc) and many of them integrate with git tooling.

The projects in a codebase can absolutely be shared and versioned as well. Here's a log of release artifacts from a library as an example: https://share.unison-lang.org/@unison/base/releases.

https://www.unison-lang.org/docs/the-big-idea/ might be a good starting point!

For interesting usage - we built Unison Cloud (a distributed computing platform) with the Unison language and also more recently an "AWS Kinesis over object storage" product. It's nice for distributed systems, though you can also use it like any other general-purpose language, of course.

In terms of core language features, the effect system / algebraic effects implementation is something you may not have seen before. A lot of languages have special cases of this (like for async I/O, say, or generators), but algebraic effects are the uber-feature that can express all of these and more.