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

91–100 of 158 posts

Re: Unison Cloud

#91

Post by ultra_nick »

9dev wrote: post #76

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

Unison is a distributed programming language.

YAML config files and Hadoop/Kafka/Kubernetes/etc are additions for non-distributed programming languages. Unison is a grand simplification of everything into one system so that future programmers don't have to put up with our crap.

Re: Unison Cloud

#92

Post by rlmark »

9dev wrote: post #76

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

Hi there! There's definitely an overhead to learning a new language but by describing your cloud infrastructure with an actual programming languages you reap the benefits of type-safety, testability, and code reuse, etc.

You're spot on with shifting the complexity to the cloud layer; our thought was that it would free up time for dev teams to focus on other layers of their application.

Maybe I'm misinterpreting your question though, I'm happy to annotate that code snippet with a walk-through.

Re: Unison Cloud

#93

Post by mike_d »

pchiusano wrote: post #50
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…

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 of an ops person every time someone visit their website.

Re: Unison Cloud

#94

Post by jadbox »

davedx wrote: post #58

It's crazy but it just might work! Even if I never use this, it's incredibly refreshing to see a genuinely new approach to delivering applications. Some of this feels subtly like Smalltalk. Some very interesting ideas here: https://www.unison.cloud/our-approach/

I feel the same. My initial reaction is that I like the vision, but I feel there is probably a compromise to build these mechanics into a library for many languages, rather than requiring the DC burden of picking up a new 'better cloud' centric language. Perhaps I just haven't developed an appreciation for language capabilities yet.

Re: Unison Cloud

#95

Post by rlmark »

ilikebits wrote: post #86

I've been following Unison since almost the beginning (back in the structure editor days!). It's a very cool project, https://www.unison.cloud/our-approach/ is a great read, and the Unison language (especially their formulation of effect handlers as "abilities") is very cool. There are two specific things here that make me reluctant to use Unison Cloud in my own work: 1. It doesn't look like there's any FFI or way to…

Nice, a structural editor throwback reference! :-) I'll speak to point 1! We aim to add FFI as a fast follow on to the native compilation work that is underway. The work on the JIT compiler opens the door to FFI so that's on the roadmap soon.

Re: Unison Cloud

#96

Post by mike_d »

rlmark wrote: post #92
9dev wrote: post #76

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

Hi there! There's definitely an overhead to learning a new language but by describing your cloud infrastructure with an actual programming languages you reap the benefits of type-safety, testability, and code reuse, etc. You're spot on with shifting the complexity to the cloud layer; our thought was that it would free up time for dev teams to focus on other layers of their application. Maybe I'm misinterpreting your…

> you reap the benefits of type-safety, testability, and code reuse, etc.

If you treat infrastructure as a problem that has to be solved by code, obviously you'll run into code specific issues like type safety. In the real world I've never root caused a production issue back to that.

Re: Unison Cloud

#97

Post by pests »

flying_sheep wrote: post #81

Distributed function call isn't that simple. You will soon have various issues like authentication, authorization, compatibility between versions, throttling, retry (e.g. transient error), and so on :-/ The list is so long we could probably write a book about these

Many of those are already handled.

Re: Unison Cloud

#98

Post by rlmark »

Havoc wrote: post #78

What is the main advantage of this over the classic big cloud function offerings? Sounds like developer experience possibly?

The developer experience would be one of the main advantages. Unison cloud was custom built to run Unison's language without extra steps like building packages, syncing dependencies across nodes, etc. Also, interactions with other cloud platforms typically aren't described in a programming language which is shared between the infrastructure management layer and the application layer. The draw-back is that the Cloud runs the Unison programming language specifically.

Re: Unison Cloud

#99

Post by rlmark »

ildjarn wrote: post #87
rlmark wrote: post #83

Earlier quoted context omitted.

We used to support git backed codebase hosting a while ago, before we launched our own remote hosting platform https://share.unison-lang.org/ and it had several downsides. 1. Unison terms are stored as hashes so checking in a binary file wasn't very ergonomic and didn't really enable much in terms of collaboration. If we store our code as text on the file system, we have less information than what's tracked in the Un…

It might be tough for Unison to be an island outside of GitHub, although I see the benefits.

Totally fair, there are definitely tradeoffs.

Re: Unison Cloud

#100

Post by tikhonj »

mike_d wrote: post #96
rlmark wrote: post #92

Earlier quoted context omitted.

Hi there! There's definitely an overhead to learning a new language but by describing your cloud infrastructure with an actual programming languages you reap the benefits of type-safety, testability, and code reuse, etc. You're spot on with shifting the complexity to the cloud layer; our thought was that it would free up time for dev teams to focus on other layers of their application. Maybe I'm misinterpreting your…

> you reap the benefits of type-safety, testability, and code reuse, etc. If you treat infrastructure as a problem that has to be solved by code, obviously you'll run into code specific issues like type safety. In the real world I've never root caused a production issue back to that.

You've never run into issues where unclear, undocumented, misunderstood or inconsistent interfaces were a significant contributing factor?
Post reply on HN