Live data from Hacker News

Unison Cloud

unison.cloud

111–120 of 158 posts

Re: Unison Cloud

#111
post #79

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.

I use both Unison and Nix (and I work on Unison Cloud). The "oh-so-good" aspect that comes from content-addressed dependencies is definitely there. I've spent a lot of time debugging runtime issues on the JVM because two libraries that I depend on disagree on what version of a common dependency should be on my classpath. This is not something you ever experience with Unison. In the runtime every term and type are ide…

Don't have much to say other than I really love and appreciate this answer. This confirms my suspicions that I'm going to like Unison a lot. I get your point, but embracing the "try to imagine a better world, even if it does mean repackaging every piece of Linux software" part of Nix makes it easy for me to see that while Unison is different, the re-imagining gets you things you didn't even know you wanted.

Re: Unison Cloud

#112

Here's some context for those who, like me, never heard about Unison before: This service is apparently directed at developers using a programming language called Unison ― hence the name: Unison Cloud. As I understand it , this is akin to launching a service called Python Cloud (by the PSF, as part of the language?) where Python developers can deploy their apps as a function call: # app.py class App: def get(self, re…

Yep, that’s right. Modal ( https://modal.com ) is actually what you’re describing with Python, but Modal is just the compute layer (Unison is going for the whole cloud), and Modal isn’t doing anything to handle version alignment across service boundaries

I never heard of them before, but they offer is amazing -- even though I don't think I'll be using anytime soon.

Re: Unison Cloud

#113
post #67

"Unison Computing, a Delaware public benefit corp. Our mission: advance what is possible with software and work to make software creation more delightful and accessible to all. " Never heard of a public benefit corp before, but in looking it up, seems like a cool thing. Wonder if Unison Cloud falls under that also... "What is a Delaware public benefit corporation? A Delaware public benefit corporation (PBC) is a for-…

The short version is that a regular corporation is required to operate in a way that maximizes shareholder profits; whereas a public benefit corp is allowed to take other factors into consideration too.

I like what you're doing. I was heavily involved in building DigitalOcean and thought often about a lot of what you're working on. Good luck, I think you're doing great work. =)

Re: Unison Cloud

#115
post #93

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…

You are right, but wouldn't it be lovely to have a programming language to reduce our reliance on lawyers? (e.g., some logic language in a civil law system)

Re: Unison Cloud

#116

I know there's only so many names in the world but this is going to completely ruin searches for the Unison file synchronizer: https://github.com/bcpierce00/unison

I'm old enough that I thought this was related to the old mainframe/UNIX company from the 90s!

Re: Unison Cloud

#117
post #85

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

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.

Re: Unison Cloud

#118
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-…

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?"

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

Re: Unison Cloud

#119
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…

++ The odd thing is unison started purely as a language. Now there's a platform. I'd love to hear some opinions from outside Unison about how they like using this language, tooling and hosting.

I'm not associated with Unison Computing and I haven't yet had a chance to use it for a professional project but learning the language and exploring their approach to tooling has been an absolute thrill.

I actually found out about Unison because from my own side projects I came to the conclusion that strongly typed, hash-addressed functions were a super compelling approach to highly modular and maintainable programming - especially in the context of LLM-generated code because refactorings and new function generation require very limited context - something desirable for humans but especially for LLMs with limited context. After digging around for something that did this I found Unison and have now mostly abandoned my own tooling because Unison is so much more mature and has such competent people behind the wheel.

There is a learning curve for sure, not just with the tooling but also the language. It's a challenging language steeped in advanced software engineering principles, but I would 100% rather spend my time honing my fundamental understanding of my craft rather than learning another 20 AWS tools which are going to go out of style in 12 months. After becoming mildly proficient in Unison I feel like I have such a broader understanding of programming in general even though I've been a full time backend coder for 15+ years.

As for the tooling, it does what it needs to and does it well with very competent folks discussing and debating the minutia daily. It's a small team and that keeps them nimble with major improvements taking place each month.

Today I'd say that it excels at microservices, things you might otherwise consider a traditional serverless function for, but gives you way more agility and brevity to tweak the application in a surgical and controlled way which is more aligned with the behavior rather than text files. Something just feels very right about storing the AST as-is and manipulating it more directly.

Tomorrow, as more supporting libraries get built and interfaces to outside of Unison get developed, anything's possible really - I'm personally certain that we'll see some amount of continued shift towards making ASTs the source of truth so I see learning about it and following the software as an investment in myself and my future capabilities regardless of whether the future software ends up being Unison or something like it. Unison is going out of their way to do all the right things even if it's not always the most practical thing given the current corroded state of web engineering in general, so I'm eager to get in on that as much as possible.

Re: Unison Cloud

#120

Pretty cool stuff. Anyone ever make a babel plugin that would check for identical function definitions?

I've been wondering the same! Haven't really had the time to dig into stable content addressing (and I assume the loose semantics of something like JavaScript would make that exceedingly hard).

Maybe? At the AST level, it can might be complicated I guess, but not really. At runtime JIT though… yeah sure. The various expressions of the same AST are bountiful.

But I would love to run an analysis on every npm module published, and find the same AST subexpressions, functions, etc. Do the same thing: remove the identifiers and hash the AST parts. Even go back and see how people named the same function in different ways!

Post reply on HN