stewoconnor

aha yeah! good question! We have two different types of type declarations, and each has its own keyword: "structural" and "unique". So you can define two different types as as

structural type Optional a = Some a | None structural type Maybe a = Just a | Nothing

and these two types would get the same hash, and the types and constructors could be used interchangeably. If you used the "unique" type instead:

unique type Optional a = Some a | None uniqte type Maybe a = Just a | Nothing

Then these would be totally separate types with separate constructors, which I believe corresponds to the `BRANDED` keyword in Modula 3.

Originally, if you omitted both and just said:

type Optional a = Some a | None

The default was "structural". We switched that a couple of years ago so that now the default is "unique". We are interestingly uniquely able to do something like this, since we don't store source code, we store the syntax tree, so it doesn't matter which way you specified it before we made the change, we can just change the language and pretty print your source in the new format the next time you need it.

> congrats on the release

Thank you!

> 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?

No regrets! This Abilities system is really straightforward and flexible. You find yourself saying that you don't miss monads, if you were already of the FP affiliation. But were glad that it means that you don't have to understand why a monad is like a burrito to do FP.

> Do you like the syntax?

So this one is very loaded. Yes we LOVE the syntax and it is very natural to us, but that is because most of us that are working on the language had either already been fluent in haskell, or at least had gotten to at least a basic understanding to the point of of "I need to be able to read these slides". However we recognize that the current syntax of the language is NOT natural to the bulk of who we would like to be our audience.

But here's the super cool thing about our language! Since we don't store your code in a text/source code representation, and instead as a typechecked AST, we have the freedom to change the surface syntax of the language very easily, which is something we've done several times in the past. We have this unique possibility that other languages don't have, in that we could have more than one "surface syntax" for the language. We could have our current syntax, but also a javascript-like syntax, or a python-like syntax.

And so we have had lots of serious discussions recently about changing the surface syntax to something that would be less "weird" to newcomers. The most obvious one being changing function application from the haskell style "function arg1 arg2" style to the more familier "c?" like style of "function(arg1, arg2)". The difficulties for us will be trying to figure out how to map some of our more unique features like "what abilities are available during function application" onto a more familiar syntax.

So changing the syntax is something that we are seriously considering, but don't yet have a short term plan for.

yeah, unison cloud is like the "heroku for functions" if you wanna not think about how deployments work. But you can just run unison programs standalone or in a docker container or whatever: https://www.unison-lang.org/docs/usage-topics/docker/

> 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

I think Alvaro's at the Unison conference was a pretty cool demonstration of what you can do with the style of algebraic effects (called "abilities" in unison)

https://www.youtube.com/watch?v=u5nWbXyrC8Y

He implements an erlang style actor system, and then by using different handlers for the algebraic effects, he can "run" the actor system, but also optionally make a live diagram of the actor communications.

It's possible that we no longer remember ALL of the evidence we had when we drafted this letter, but the letter links to two first hand accounts of wrongdoing. I also have also talked to multiple other women in the community that say that Jon was someone that women generally knew to warn each other about since there were enough believable accounts of his wrongdoing.

we absolutely did this to protect the scala community and we weren't scared and didn't jump the gun. People had been talking about him as being problematic for years before the open letter

This was absolutely not based on hearsay. We made our decision to sign the letter based on direct evidence, not hearsay. The open letter links directly to evidence which is not hearsay.

I signed the letter and I fully stand by everything it says. I have talked to Yifan and I feel sorry for her and believe her.

It was well known, and well discussed that women in the scala community knew to warn other women about Jon Pretty. I have heard this both directly and indirectly from multiple prominent women in the Scala community.

Yes this is unfortunately a problem that comes up with our current system. We had to solve this early on by distinguishing "unique" types form "structural" types. For types it is obvious that you want to make sure that these types generate a unique hash, even if they are the same structure:

type UserName = UserName Text type Password = Password Text

since the entire point in introducing types here is to actually declare them as different from one another.

But for other it might actually be beneficial to recognize that they are the same type, for example:

type Optional a = None | Some a type Maybe a = Nothing | Just a

To allow for both, you can prefix type with either "structural" or "unique" depending on what behavior you want (unique is the default). We have tossed around the idea of also introducing unique terms which would let you terms like yours as unique terms that should be salted, and let the current behavior of "structural"? terms be the default. The reality is that this hasn't been such a big problem that it has made it to the top of our list yet ;)

We recently did a series of blog posts exploring how our remote programming model makes us a good fit for writing distributed map - reduce like programs.

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

One of the real strengths of individual parts of your program being content addressed, and our ability system that lets us track side effects, we can have a programming model where you only need to talk abstractly about where your data is, and how you'd like to operate on it, and then we have the ability to have our cluster gossip about parts of your program that need to be shipped to where parts of your data is. One node can ask another node "please apply this function to the data you have" and the other node can gossip to get any missing definitions it needs for that function.

You never have to talk about serialization or network connections or software distribution, we know how to move data for you, move code for you, and in some cases even cash partial program results.

for us, A and B are the same Term since they have the same hash, they are just two different alias for that hash, so if you update either, you are effectively updating both.

In fact if you had the function:

double x = x + x

and you were to rewrite it to be:

double addend = addend + addend

Unison would say "this is the same function, no update needed" as it produces the same AST

Unison developer here! Let's say you have some term:

B = "Hello "

and it hashes to #a3yx. Lets say you also have funcion:

A = B ++ "world" which hashes to #c7c1

when we store the A function, we actually store it as:

#c6c7 = #a3yx ++ "world"

Then later if you update the definition of B:

B = "Hello, "

and that function hashes to, #5e2b, when you tell unison to update B from #a3yx => #5e2b, it will look for all of the places that used to reference #a3yx, like your A function, and will see if those functions still typecheck with the replacement. If so, they are automatically updated. If not, we pretty print the definitions that didn't to a file for you to manually fix.

Yes, we additionally have functions builtin to the runtime that let you evaluate a term before you evaluate it to make sure it doesn't call any "forbidden" functions.

So in our cloud runtime, we blacklist EVERY IO function, then we can in our cloud runtime give you back the ability to do, for example, http requests, but not any other network IO. We won't let you open arbitrary files, but we'll provide ephemeral / persistent block storage through some other runtime ability.

This could also be used to do something like blacklist functions with known security vulnerabilities to catch people that aren't applying their patches!

I'm not totally up to date on lisp and don't know anything about PicoLisp, so forgive me if there is stuff I'm missing :) but lemme try:

Lets say you wrote a imaginary program to sum a column in a csv:

(defun my-program () (let* ((raw-data) (s3-load-file "htpps://...")) ((parsed) (csv-parse raw-data)) ((column1) (csv-column parsed 1)) (mean column1))

In this pretend program we are using some 3rd party s3 library to fetch some data, some other 3rd party CSV library to extract the data. Now I want to run this on some other remote node. I know I can just sent that sexp to the remote node and have it eval it, but that is only going to work if the right versions of the S3 and CSV library are already in that runtime.

I want to be able to write a function like:

(defun remote-run (prog) (....))

That can take ANY program and ship it off to some remote node and have that remote node calculate the result and ship the answer back. I don't know of some way in lisp you could ask the runtime to give you a program which includes your calculation and the s3 functions and the csv functions.

In unison, I can just say `(seialize my-program)` and get back a byte array which represents exactly the functions we need to evaluate this closure. When the remote site tries to load those bytes into their runtime, it will either succeed or fail with "more information needed" with a list of additional hashes we need code for, and the two runtimes can recurse through this until the remote side has everything needed to load that value into the runtime so that it can be evaluated to a result.

Then, of course, this opens us up to the ability for us to be smart in places and say "before you try running this, check the cache to see if anyone ran this closure recently and already knows the answer"

In one of our most recent blog posts we talked about the progress we are making on just-in-time native compilation:

https://www.unison-lang.org/blog/jit-announce/

We are expecting to be a monumental speedup for us. We have some promising results so far, but we haven't yet ported all of the runtime.

Thanks for the reply :)

> if it's handled by `Choose.toList` and then `Abort.toOptional` in that order you end up with `Optional [a]` whereas if you do in the other order you have `[Optional a]` right?

I mean, not necessarily. Something that handles a `'{Abort} a` doesn't necessarily produce an `Optional a`. It could produce a Boolean, it could produce an Int, whatever. This is really up to the handler. But I still don't see how you produce a "bug" because you can dispatch the requests to abilities in either order. You couldn't, for example, ever produce a (well-typed) situation where a call to abort doesn't abort, or a call to Choose.toList would fail to produce a list. (Perhaps if toList were allowed to also use {Abort} but it is not)

It is up to the code handling the abilities to decide in which order to handle the abilities (or to handle them all at once).

I can't think of any cases where it would make a difference in which order they were handled, however. Can you?

I think perhaps it might in the case where abilities themselves were able to make requests of other abilities, but that's not something allowed by our type system currently

The relevant sourcecode is not available, we don't store any source code. All the relevant dependences MUST be availble in AST form though.

I don't know what the social and legal issues might possibly be, though I might be missing somehting, what do you have in mind there?

Its certainly a turn-off for some. One thing that we have as a potential future effort would be to enable an alternate surface syntax. Since we store an AST insteead of source code, we could create a parser/pretty printer for another surface syntax. Then a user of the language who would prefer something that looked like python could switch our website's renderer to output the python like syntax!

Yes, we have stack traces. You might see some hashes in the middle of the stack traces, but whenever we do have a name, we'll show you the name. So if you are calling into an anonymous clousure, but functions in your call stack will typically have names available

(I'm the a Unison employee that works mostly on distributed computing)

There are a few things about unison that make this easier:

* content addressed code * unison can serialize any closure

I can ask for a serialized version of any closure, and get back something that is portable to another runtime. So in a function, I can create a lambda that closes over some local variables in my function, ask the runtime for the code for this closure and send it to a remote node for execution. It won't be a serialized version of my entire program and all of its dependencies, it will be a hash of a tree, which is a tree of other hashes.

The remote node can inspect the tree and ask for or gossip to find out the definitions for whatever hashes in that tree it doesn't already know about. It can inspect the node for any forbidden hashes (for example, you can'd do arbitrary IO), then the remote node can evaluate the closure, and return a result.

In other langauges, perhaps you can dynmically ship code around to be dynamically exeecuted, but you aren't going to also get "and of course ship all the transitive dependencies of this closure as needed" as easily as we are able to.

(Unison Developer here), yes we've done two such migrations this year. It has typically meant that we have an "are you ready to upgrade" message when you start up and the migration took less than a minute on my pretty large codebase. It's not a big deal