Unison 1.0 • Hacker News Board

Re: Unison 1.0

#81

Post by tasuki » Wed, Nov 26, 2025, 7:12 AM UTC

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?

Maybe it's encrypted? I'm sure if you do any programming, you send code over the network and execute it about all the time!

Re: Unison 1.0

#82

Post by jarbus » Wed, Nov 26, 2025, 7:14 AM UTC

This is so so, cool, but I feel like most of the features are lost once you need to use complex dependencies that aren’t in unison.

Re: Unison 1.0

#83

Post by ofrzeta » Wed, Nov 26, 2025, 7:14 AM UTC

jonym wrote: post #11

I'm so old, I thought this was about Panic's Usenet client Unison.

There's also the Unison sync tool but it's at 2.53.7.

Re: Unison 1.0

#84

Post by ndsipa_pomu » Wed, Nov 26, 2025, 7:37 AM UTC

ofrzeta wrote: post #83

jonym wrote: post #11

I'm so old, I thought this was about Panic's Usenet client Unison.

There's also the Unison sync tool but it's at 2.53.7.

I thought this was about the Unison sync tool when I clicked on it.

Re: Unison 1.0

#85

Post by scuff3d » Wed, Nov 26, 2025, 8:47 AM UTC

rlmark wrote: post #43

imiric wrote: post #34

Earlier quoted context omitted.

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…

These seem to be mostly related to difficulties around adapting to a new programming model. Which is understandable, but do you have examples of more concrete tradeoffs?

For example, I don't think many would argue that for all the upsides a functional language with immutable state offers, performance can take a significant hit. And if can make certain classes of problems trickier, while simplifying others.

Surely with a model this unique, with the payoffs come costs.

Re: Unison 1.0

#86

Post by etorreborre » Wed, Nov 26, 2025, 9:21 AM UTC

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?

[dead]

Re: Unison 1.0

#87

Post by vinnyhaps » Wed, Nov 26, 2025, 10:49 AM UTC

I remember the day Rúnar told me he was going to work on this new language called Unison.

I have always thought it was an amazing project to set out on, and was paving the way for a new kind of paradigm. Super proud to see them release a 1.0 and I would love to say Unison is my go-to language in the near future!

Re: Unison 1.0

#88

Post by tasuki » Wed, Nov 26, 2025, 1:31 PM UTC

pchiusano wrote: post #45

spooky_deep wrote: post #32

Earlier quoted context omitted.

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…

> What are you wanting to accomplish more broadly with the integration?

For me that would be:

- not lose my stuff

- share with friends

- let others contribute

Re: Unison 1.0

#89

Post by instig007 » Wed, Nov 26, 2025, 2:15 PM UTC

If you ever need this kind of stuff, you'll be better off building your own distributed interface by using plain regular GHC Haskell and https://haskell-distributed.github.io/

Re: Unison 1.0

#90

Post by rssoconnor » Wed, Nov 26, 2025, 5:30 PM UTC

stewoconnor wrote: post #75

rssoconnor wrote: post #65

Earlier quoted context omitted.

How do you deal with "branded" types, if you know what I mean. Edit: I mean structurally identical types that are meant to be distinct. As I recall Modula 3 used a BRANDED keyword for this.

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…

How does the implementation of unique types works? It seems you need to add some salt to the hashes of unique type data, but where does the entropy come from?