Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unison 1.0

unison-lang.org

Post reply on HN
Print view View original

41–50 of 98 posts

Re: Unison 1.0

#41

Post by pchiusano »

imiric wrote: post #37
proglangenjoyer wrote: post #27

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…

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

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 optional.

Maybe we'll have a page or a reference somewhere to make the lines more clear.

Re: Unison 1.0

#42

Post by shay_ker »

pchiusano wrote: post #24
SwiftyBug wrote: post #14

Earlier quoted context omitted.

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?

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?

Re: Unison 1.0

#43

Post by rlmark »

imiric wrote: post #34
pchiusano wrote: post #2

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

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

Great question.

There are indeed tradeoffs; as an example, one thing that trips folks up in the "save typed values without encoders" world is that a stored value of a type won't update when your codebase's version of the type updates. On its face, that should be a self-evident concern (solvable with versioning your records); but you'd be surprised how easy it is to `Table.write personV1` and later update the type in place without thinking about your already written records. I mention this because sometimes the lack of friction around working with one part of Unison introduces confusion where it juts against different mental models.

Other general tradeoffs, of course, include a team's tolerance for newness and experimentation. Our workflow has stabilized over the years, but it is still off the beaten path, and I know that can take time to adjust to.

I hope others who've used Unison will chime in with their tradeoffs.

Re: Unison 1.0

#44

Post by losvedir »

pchiusano wrote: post #2

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

Re: Unison 1.0

#45

Post by pchiusano »

spooky_deep wrote: post #32
aryairani wrote: post #15

Earlier quoted context omitted.

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

What’s a good way to include Unison code in a more traditional Git monorepo?

That depends. What are you wanting to accomplish more broadly with the integration?

I'll mention a couple things that might be relevant - you could have the git repo reference a branch or an immutable namespace hash on Unison Share. And as part of your git repo's CI, pull the Unison code and compile and/or deploy it or whatever you need to do.

There's support for webhooks on Unison Share as well, so you can do things like "open a PR to bump the dependency on the git repo whenever a new commit is pushed to branch XYZ on Unison Share".

Basically, with webhooks on GH and/or Unison Share and a bit of scripting you can set up whatever workflow you want.

Feel free to come by the Discord https://unison-lang.org/discord if you're wanting to try out Unison but not sure how best to integrate with an existing git repo.

Re: Unison 1.0

#46

Post by imiric »

pchiusano wrote: post #41
imiric wrote: post #37

Earlier quoted context omitted.

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

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.

Re: Unison 1.0

#47

Post by drob518 »

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).

Re: Unison 1.0

#48

Post by pchiusano »

shay_ker wrote: post #42
pchiusano wrote: post #24

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?

Mobile or browser clients talk to a Unison backend services over HTTP, similar to any other language. Nothing fancy there.[1]

> sending code over the network to be executed elsewhere feels like a security risk to me?

I left out many details in my explanation and was just describing the core code syncing capability the language gives you. You can take a look at [2] to see what the core language primitives are - you can serialize values and code, ask their dependencies, deserialize them, and load them dynamically.

To turn that into a more industrial strength distributed computing platform, there are more pieces to it. For instance, you don't want to accept computations from anyone on the internet, only people who are authenticated. And you want sandboxing that lets you restrict the set of operations that dynamically loaded computations can use.

Within an app backend / deployed service, it is very useful to be able to fork computations onto other nodes and have that just work. But you likely won't directly expose this capability to the outside world, you instead expose services with a more limited API and which can only be used in safe ways.

[1] Though we might support Unison compiling to the browser and there have already been efforts in that direction - https://share.unison-lang.org/@dfreeman/warp This would allow a Unison front end and back end to talk very seamlessly, without manual serialization or networking

[2] https://share.unison-lang.org/@unison/base/code/releases/7.4...

Re: Unison 1.0

#49

Post by sp33der89 »

proglangenjoyer wrote: post #27

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…

When it comes to the comparison with other languages like Zig, Rust and Go, I disagree. I think it's because it hits its """new weird thing""" budget really quickly with Abilities and code in a database.

The Share project is open source, in contrast to GitHub, which is also popular despite having forms of locked-inness in practice as well.

I'm saying this not to negate the vibes you feel, but I'd rather people try it out and maybe see how their favorite language could benefit from different design decisions.

Re: Unison 1.0

#50

Post by indolering »

drob518 wrote: 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.
Post reply on HN