[bloppe]

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-language client libraries that handle transport, de-/serialization, native typing, etc.

3. "typed storage" isn't this basically an ORM? I suppose it's more general since it doesn't have to be relational, but ORM ideas could just as easily be adapted to JSON blob stores using something like protobuf.

Also, storing Unison code in a database, keyed by the hash of that code, sounds a lot like using Bazel with a shared remote cache.

I'm not saying Unison isn't cool, but to win me over I'd need you to compare Unison to all these existing technologies and really spell out what differentiates Unison and what makes it better.

[delfinom]

For me besides those 3 it's also "what happens if unison fails to attract the funding it needs and shuts down next month, do I get fucked by the proprietary solution that was made a critical part of my own business?"

[biggestlou]

You sure are doom and gloom about something that was released today

[biggestlou]

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.

[turtlebits]

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.

[pchiusano]

The language is open source. See this reply re: self-hosting https://news.ycombinator.com/item?id=39293568

[turtlebits]

Proprietary as in you write your code for Unison Cloud, and have to rewrite the infra parts if you decide to self host.

This is why infra is decoupled from code and you need things like "deployments".

[actionfromafar]

You can't self-host Unison?

[fulafel]

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

[pchiusano]

No worries!

It is true that tech exists that try to make all 3 of those items easier. YMMV, but having used these technologies myself and now having used Unison + Unison Cloud, all I can say is that the Unison experience is quite different overall.

The details matter. A bicycle and a motorcycle share some common principles but that doesn't mean they're "about the same". The fine details of execution and polish can matter too: Slack is different than IRC, Dropbox was different than the million other backup services. Also, bringing a number of things in a cohesive way can lead to big improvements in the experience when it's done well.

Getting into specifics a bit, I don't think deployment with a function call is well handled by existing technologies, because of the reasons discussed in the post. In the absence of Unison's features, there is inevitably some sort of out-of-band packaging step or "setting up the environment with the right dependencies" as a precondition, instead of calling a function and having it Just Work.

Re: RPC, Unison remote calls can pass around arbitrary values, including functions and values containing functions. This Just Works. There's also no generated code which needs to be somehow integrated into your build and no boilerplate converting from the "wire format" objects to your actual domain objects you want to work with.

My experience with ORMs is they are overly opinionated / magical and provide insufficient control for many projects. So every project I've worked on ends up not using ORMs in favor of a layer of boilerplate for talking to the storage layer... which still can't store functions or even sum types properly! And it's not typechecked, either. Using our cloud's storage, I get to use whatever data structures I want, can write my own easily if needed, and I can store any value at all including functions and again it Just Works. And access is typechecked. It's pretty great!

When you put all these things together in a single cohesive programming environment, with a common type system and language, uniform composition, a set of tools all meant to work well together, you really start to see how different it is! It already feels like a huge step up, and will only keep getting better and better as we build out Unison and our cloud platform.

All that said, I'm kind of doubtful that abstract arguments like this will be convincing. Instead, I'd just try Unison out for a low-risk project and decide for yourself if the details are making a big difference for you.

Hope that is helpful! :) If you do decide to play around with it, feel free to come by the Discord https://unison-lang.org/discord to get help, ask silly questions, etc. We are here to help and it's a nice community.

[kunley]

It is so funny to defend serverless with it's all crappy configuration, slow dev cycle and vendor lock-in.