Live data from Hacker News

Unison 1.0

unison-lang.org

51–60 of 98 posts

Re: Unison 1.0

#51

Earlier quoted context omitted.

Erlang is great and was one inspiration for Unison. And a long time ago, I got a chance to show Joe Armstrong an early version of Unison. He liked the idea and was very encouraging. I remember that meant a lot to me at the time since he's a hero of mine. He had actually had the same idea of identifying individual functions via hashes and had pondered if a future version of Erlang could make use of that. We had a fun…

Very dumb question - sending code over the network to be executed elsewhere feels like a security risk to me? I’m also curious how this looks with browser or mobile clients. Surely they’re not sending code to the server?

Not a dumb question at all! Unison's type system uses Abilities (algebraic effects) for functional effect management. On a type level, that means we can prevent effects like "run arbitrary IO" on a distributed runtime. Things that run on shared infrastructure can be "sandboxed" and prevented with type safety.

The browser or mobile apps cannot execute arbitrary code on the server. Those would typically call regular Unison services in a standard API.

Re: Unison 1.0

#52
post #47

So, there are a whole bunch of interesting ideas here, but… It’s a huge, all-or-nothing proposition. You have to adopt the language, the source control, and figure out the hosting of it, all at once. If you don’t like one thing in the whole stack, you’re stuck. So, I suspect all those interesting ideas will not go anywhere (at least directly; maybe they get incorporated elsewhere).

While I'm sure the creators would love to see their work become commercially successful and widespread, I don't think that a very interesting criteria to judge what's essentially cool computer science research.

Fair enough.

Re: Unison 1.0

#53
post #46

Earlier quoted context omitted.

Unison code is published on https://share.unison-lang.org/ which is itself open source (it's a Haskell + postgres app), as is the language and its tooling. You can use Unison like any other open source general-purpose language, and many people do that. (We ourselves did this when building Unison Cloud - we wrote Unison code and deployed that within containers running in AWS.) The cloud product is totally separate and…

I see, thanks. It's reassuring to know that I can use all language features without relying on any of your infrastructure.

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/

Re: Unison 1.0

#54
post #47

So, there are a whole bunch of interesting ideas here, but… It’s a huge, all-or-nothing proposition. You have to adopt the language, the source control, and figure out the hosting of it, all at once. If you don’t like one thing in the whole stack, you’re stuck. So, I suspect all those interesting ideas will not go anywhere (at least directly; maybe they get incorporated elsewhere).

You can gradually adopt Unison, it's not all or nothing. It's true that when programming in Unison, you use Unison's tooling (which is seriously one of the best things about it), but there are lightweight ways of integrating with existing systems and services and that is definitely the intent.

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:

https://news.ycombinator.com/item?id=46051750 (you can use Unison like any other open source general-purpose language)

https://news.ycombinator.com/item?id=46051939 (you can integrate Unison's tooling with git)

There can be enormous value in creating multiple pieces of tech all designed to work really well together. We've done that for Unison where it made sense while also keeping an eye on ease of integration with other tech.

Re: Unison 1.0

#55
post #47

So, there are a whole bunch of interesting ideas here, but… It’s a huge, all-or-nothing proposition. You have to adopt the language, the source control, and figure out the hosting of it, all at once. If you don’t like one thing in the whole stack, you’re stuck. So, I suspect all those interesting ideas will not go anywhere (at least directly; maybe they get incorporated elsewhere).

You can gradually adopt Unison, it's not all or nothing. It's true that when programming in Unison, you use Unison's tooling (which is seriously one of the best things about it), but there are lightweight ways of integrating with existing systems and services and that is definitely the intent. We ourselves make use of this sort of thing since (for instance) Unison Cloud is implemented mostly in Unison but uses Haskel…

Cool, those things are going to ease adoption.

Re: Unison 1.0

#56

Also, hi, I'm one of the language creators, feel free to ask any questions here!

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 kin…

Thanks!

I am not 100% sure the origin of the idea but I do remember being influenced by git and Nix. Basically "what if we took git but gave individual definitions a hash, rather than whole working trees?" Then later I learned that Joe Armstrong had thought about the same thing - I met Joe and talked with him about Unison a while back - https://news.ycombinator.com/item?id=46050943

Independent of the distributed systems stuff, I think it's a good idea. For instance, one can imagine build tools and a language-agnostic version of Unison Share that use this per-definition hashing idea to achieve perfect incremental compilation and hyperlinked code, instant find usages, search by type, etc. It feels like every language could benefit from this.

Re: Unison 1.0

#57
Oh, so this is not the bidirectional file synchronization tool huh? Name collisions are inevitable, but unison (the sync tool) has been around and in use since 1998, so this one feels especially egregious.

Re: Unison 1.0

#58

I have been following Unison for a veeery long time. Ever since those blog posts on Paul's personal website. It has been more than 10 years already so this is a great milestone. But I am just a bit disappointed. I love programming languages. I follow every programming language, even some you probably have never heard of. I have witnessed the rise of Rust, Go, Zig and others. At the age and level of polish that Unison…

Hi. I don't know if you'll see this (I'm banned, so someone will have to upvote me if you have showdead off), but I would like to know what languages you personally like the most, or which ideas do you think a perfect language should have?

Re: Unison 1.0

#59
post #3

Has anyone used this, any cool ideas?

I tried it once, but a core feature I needed (running code asynchronously on a timer) didn't seem to be available in the free version.

Re: Unison 1.0

#60

Also, hi, I'm one of the language creators, feel free to ask any questions here!

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…

(All Unison values can also be decompiled into an AST anyway.)
Post reply on HN