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

121–130 of 158 posts

Re: Unison Cloud

#121

Post by turtlebits »

biggestlou wrote: post #117
bloppe wrote: post #85

Earlier quoted context omitted.

Not trying to pour cold water, but the "3 requirements" post seems to address straw man problems. There are existing solutions to each problem. 1. "Deployment should be like calling a function" isn't that the mantra of serverless? e.g. GCP Cloud Run or AWS Lambda? This is also becoming much more streamlined with server-side WASM e.g. wasmCloud. 2. "Calling services should be easy" this is what protobuf is for; cross-…

Well, the key difference is that using all those things together is very quickly going to ensnare you in a big pile of goo. That you can forgo all of that and just write functions without having to build them into Wasm or any other format with any kind of build tool is the difference. That you get typed data storage without running a DB. That there is no “deployment” whatsoever.

Until you screw yourself with vendor lock in on a proprietary language.

It's at least a pile of goo that you can take to other providers or host yourself.

Re: Unison Cloud

#122

Post by fulafel »

mike_d wrote: post #93
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…

I think this sums it up: "a lot of the work you end up doing is not programming." Programmers will happily hire a lawyer or a receptionist, but will code themselves into a fury and invent programming languages to avoid admitting they suck at ops and should hire someone. Let's just call it what it is: the cloud is ego driven outsourcing. Nobody wants to admit they need an ops person, so they just pay for 1 millionth o…

Most programs are written in a context where hiring someone is not an option.

Re: Unison Cloud

#123

Post by fulafel »

bloppe wrote: post #85
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…

Not trying to pour cold water, but the "3 requirements" post seems to address straw man problems. There are existing solutions to each problem. 1. "Deployment should be like calling a function" isn't that the mantra of serverless? e.g. GCP Cloud Run or AWS Lambda? This is also becoming much more streamlined with server-side WASM e.g. wasmCloud. 2. "Calling services should be easy" this is what protobuf is for; cross-…

For 1 and 2 it's far from that. These are not first class supported things in PLs and can't be well hidden by libraries. Maybe an embedded DSL could do it in a language that supports them well, ala Electric Clojure...

Re: Unison Cloud

#125

Post by steve_adams_86 »

pradn wrote: post #66
steve_adams_86 wrote: post #62

Apologies if this is a dumb question, and maybe it applies to other services I may already use, but: What if Unison language and the Cloud have a vulnerability. Would you suddenly have a large network of services that could be readily exploited? This sort of "infrastructure monoculture" situation gives me the heebie-jeebies, but I'm admittedly pretty dumb when it comes to security. I imagine that with my Google Cloud…

This problem exists with all shared code. Shared code, shared fate. You hope that with more eyes on a library, it'll be more secure. It may also mean vulnerabilities have a higher blast radius. You have to choose where you want to lie on the balance. Spectre and Log4J - problems on widely deployed tech (Intel CPUs, Java services).

Very good point at the end; the lower level you go, the broader (and likely more severe) your vulnerabilities will be. I suppose in this case my concerns aren't warranted, or at least not worth placing before more immediate and obvious concerns. i.e., I could write shitty code a lot more easily than Unison could compromise their language and infrastructure.

Re: Unison Cloud

#126

Post by actionfromafar »

turtlebits wrote: post #121
biggestlou wrote: post #117

Earlier quoted context omitted.

Well, the key difference is that using all those things together is very quickly going to ensnare you in a big pile of goo. That you can forgo all of that and just write functions without having to build them into Wasm or any other format with any kind of build tool is the difference. That you get typed data storage without running a DB. That there is no “deployment” whatsoever.

Until you screw yourself with vendor lock in on a proprietary language. It's at least a pile of goo that you can take to other providers or host yourself.

You can't self-host Unison?

Re: Unison Cloud

#127

Post by max_hoffmann »

I’ve been waiting for this since the first talk about Unison. Love the huge progress you have made and congrats to the public release of Unison Cloud!

Question: Is it possible to set the region of the database/storage? Or is there any timeframe when this can be configured? For GDPR reasons I cannot use hosting that doesn’t support storage in the EU.

Re: Unison Cloud

#128

Post by HenriTEL »

That's very refreshing and there must be a lot of work behind the scene to properly update services and their dependencies without outages. I'm also curious about how database migrations are dealt with.

I'll keep following that space as they have well identified the problem and its root causes. The CNCF is happy of their "ever-growing global community", reaching 173 projects and over 220,000 contributors. Good for them.

Re: Unison Cloud

#129

Post by actionfromafar »

adastra22 wrote: post #109
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…

> 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 and hard to go back once you've experienced it. I am basically never waiting around for my code to compile - once code has been parsed and typechecked once, by anyone, it's not touched again unt…

Absolutetely, but speaking as someone who has tried to get ccache to work in Azure pipelines properly...

I mean, ccache worked. But it wasn't exactly faster. Have to try again with a permanent memcached. Also, it's fiddly with paths, the absolute paths have to be the same, so if you run more than one build agent on a machine, those agent aren't going to cache each other's stuff. The "dropbox = rsync + ftp" meme is pretty beaten up, but maybe it applies here. :-)

Re: Unison Cloud

#130

Post by actionfromafar »

pchiusano wrote: post #17
VirusNewbie wrote: post #10

Looks really cool. I hope they wrap their language with a variant of python or typecript or something, as I think a lot of the former programmers would embrace this type of deployment model. I'm just not sure they'd want to learn haskell style syntax.

Hi, one of the Unison creators here. We've talked about adding pluggable syntax[1]. It's in principle straightforward (the code is already stored in a database as its abstract syntax tree, not text) and I imagine a future version of Unison could let you pick from a variety of syntaxes. But we haven't gotten to it yet. [1] https://github.com/unisonweb/unison/issues/499 ... that said, the language semantics and librari…

I think you guys are a self-selected bunch of very smart people, also unafraid to break ground and try something new - so you may underestimate how much a familiar syntax means to us plebs.

For instance, Erlang always intrigued me, but Elixir (familiar syntax but with Erlang semantics for those who don't know) was what made me really consider the Erlang ecosystem.

Post reply on HN