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

Unison Cloud

unison.cloud

Post reply on HN
Print view View original

71–80 of 158 posts

Re: Unison Cloud

#71

Post by pchiusano »

dmix wrote: post #55
pchiusano wrote: post #50

Earlier quoted context omitted.

It definitely is ambitious! A multi-year effort. This post https://www.unison.cloud/our-approach/ talks more about why such radical changes were necessary to achieve what we wanted. (In particular check out the "3 requirements of the dream" section, which walks through what the programming language needs to support to be able to do things like "deploy with a function call.") My general take on "when and where to inno…

So as an end user it's kind of like a more cohesive version of https://deno.com/ for infra, where you buy into a runtime + comes prepacked with DBs (k/v stores), scheduling, and deploy stuff? > by storing Unison code in a database, keyed by the hash of that code, we gain a perfect incremental compilation cache which is shared among all developers of a project. This is an absolutely WILD feature, but it's fantastic an…

Yes, I think Deno's a decent analogue for what we're doing, though the Unison language provides some additional superpowers that we find essential. The https://www.unison.cloud/our-approach/ post has more details on why the language "needs" to change to get certain benefits. (This is not a knock against Deno, btw, I think it's an awesome project!)

> Interesting. Whats it like upgrading and managing dependencies in that code? I'd assume it gets more complex when it's not just the Unison system but 3rd party plugins (stuff interacting with the OS or other libs).

In Unison, there's an all-in-one tool we call the Unison Codebase Manager (UCM) which can typecheck and run your code and talk to the code database (we use SQLite for this). The workflow is that you have your text editor / VS code open, and UCM in another terminal, watching for changes.

So if you want to edit a definition, say, here's the workflow -

1. `edit blah` brings code into a scratch file, pretty-printed. You make your changes and get that compiling.

2. You type `update` in UCM, and it tries to propagate this change throughout your project. If it can, you're done. If it can't (say because you've changed a type signature), UCM puts the minimum set of definitions in your scratch file. You get this compiling, then do `update` again and you're done. It's quite nice! The scratch files are very ephemeral and not the source of truth.

For library dependency upgrades the process is similar: you fetch the new version, then use `upgrade` to say "I want my project to exclusively use the new version". If everything's compatible, you're done. If there's incompatible changes, UCM creates a scratch file with the minimum set of things to get compiling.

One interesting benefit is you can have multiple versions of the same library in use in your project. Unison doesn't care if you do this (though it can get confusing so people tend to consolidate). But there are cases where we've made good use of the ability to reference multiple "incompatible" library versions within a project.

Re: Unison Cloud

#72

Post by stewoconnor »

alephaleph wrote: post #60
stewoconnor wrote: post #24

Earlier quoted context omitted.

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

What happens if you have two terms that are incidentally equivalent: A = "Hello " B = "Hello " C = A ++ "world" D = B ++ "world" and then you update the definition of A but not B?

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

Re: Unison Cloud

#74

Post by rlmark »

alephaleph wrote: post #60
stewoconnor wrote: post #24

Earlier quoted context omitted.

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

What happens if you have two terms that are incidentally equivalent: A = "Hello " B = "Hello " C = A ++ "world" D = B ++ "world" and then you update the definition of A but not B?

At the point when you've written a term which is incidentally equivalent to another, the Unison codebase manager tool tells you that you're adding a term that is identical and lists its name. You can still technically perform the addition if you really want at that point, but most folks don't want two aliases for the same function floating around. If you do end up adding it, updating A would also update B. Think of the function name as metadata and the actual implementation as the identity of the function.

Re: Unison Cloud

#75

Post by rlmark »

ildjarn wrote: post #59

Has anyone used Unison instead of Spark? Seems like a natural fit to me.

We wrote an article speaking to this use case here: https://www.unison-lang.org/articles/distributed-datasets/ It's a bit of a deep dive into some of the building blocks of the Remote ecosystem - so it talks quite a bit about how you'd implement something like Spark itself in Unison, but you can see how running data aggregations would work on the Cloud.

Re: Unison Cloud

#76

Post by 9dev »

Forgive me the heresy, but when I look at this example:

  helloWorld.deploy : '{IO, Exception} ()
  helloWorld.deploy = Cloud.main do 
    h = sketchy underlinedeployHttp !  Environment.default helloWorld
    ServiceName.assign
      (ServiceName.create "hello-world") h
Then how am I not just swapping YAML gobbledygook for Unison gobbledygook here..?

I understand the general idea of expanding the scope of programmable code onto the infrastructure layer, that makes total sense to me. But then, you’re just shifting complexity from the developer to your cloud service, and hide it behind a proprietary platform (which I don’t mind, all the best for your business!). And I don’t really understand how that will make things better, all things considered.

Could someone explain this to me?

Re: Unison Cloud

#77

Post by stewoconnor »

ildjarn wrote: post #59

Has anyone used Unison instead of Spark? Seems like a natural fit to me.

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.

Re: Unison Cloud

#78

Post by Havoc »

What is the main advantage of this over the classic big cloud function offerings?

Sounds like developer experience possibly?

Re: Unison Cloud

#79

Post by k8svet »

I feel like my alter ego wrote this same comment a year ago, but if there's any Nix users that are also Unison users, I'd love to hear your thoughts.

This feels like some of the tough-but-oh-so-good nature of Nix, applied to general programming. But I haven't had a chance to try Unison much.

Re: Unison Cloud

#80

Post by __MatrixMan__ »

borland wrote: post #31

It looks like to use this product, I have to learn an entirely new programming language (which appears to be a weird mashup of Python and Haskell), a whole set of entirely new API's, I can only host my stuff on their for-pay cloud infrastructure, and I can't use source control? That's a lot of very high hurdles to clear. Even if this magically solved all my scaling and distributed system problems forever, I'm not sur…

Is a language built around a pretty exciting idea. I'd drop quite a lot to go work in Unison, if only to see what the world looks like through that lens.

Tinkering on the weekends just isn't the same.

Post reply on HN