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
Unison Cloud
81–90 of 158 posts
Re: Unison Cloud
#82Earlier quoted context omitted.
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 t…
Is the term merely the hash of its contents, or does it also include the module space? If it's just the hash of its contents, how do you deal with functions which have the same implementation now but shouldn't always - e. g.:
serviceA.requiredHeaders key = Dictionary.of "X-API-KEY" key
serviceB.apiKeyHeader apiKey = Dictionary.of "X-API-KEY" apiKey
Re: Unison Cloud
#83Can Unison code be stored in a Git repo as text?
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 Unison tooling, since the plain text version isn't aware of its dependencies. 2. Unison's versioning system is more syntactically aware than Git's since its granularity is based on the definition of your functions and types, not incidental changes like whitespace or newlines.
You can of course, bring all the Unison code for a program into a text file (you write Unison code in your regular editor) and then check it in, but that's not as nice of a workflow than the one that's supported directly.
Re: Unison Cloud
#84"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.
Re: Unison Cloud
#85It 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…
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.
Re: Unison Cloud
#86I'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 shell out to other tools within Unison Cloud. I understand that this is necessary to provide the desired static guarantees, but the lack of an escape hatch for using pre-existing code makes this a really hard sell.
2. Typed storage is excellent! What are its performance characteristics? In my experience, gaining expressiveness in storage systems often requires trading away performance because being able to store more kinds of values means we have fewer invariants to enable performance optimizations. How do migrations work? I've always found online migrations to be a major pain point, especially because data rapidly becomes very heavy. (At a glance, it looks like storage is key-value with some DIY indexing primitives, and I couldn't find anything about migration.)
The approach article asks "Why is it so complicated, anyway?". My guess would be that:
1. For small projects where you can toss together NextJS and SQLite and throw it onto Hetzner, it really _isn't_ that complicated.
2. For large projects where with large amounts of data, high availability requirements, and very large scale, performance and operability matters a lot, and none of these all-in-one systems have yet to demonstrate good performance and operability at scale.
3. There really is not that much demand for projects between these two sizes.
Re: Unison Cloud
#87Can Unison code be stored in a Git repo as text?
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.
Re: Unison Cloud
#88Forgive 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…
I haven’t used the service or language, but I imagine if you’re familiar with it, the above snippet feels like Typscript does to me.
From their written materials, it looks like the thing you’re missing is that this is a single source of truth.
For most systems, I change my code, build and push a container, and then have to update the YAML to make sure it addresses the right container, and then push that. Obviously a lot of us have that all automated, but I don’t know anyone for whom that automation is easy and never needs to be escaped.
Again, I’m not a user of the platform, but as a user of what they are innovating on top of I can see what they are going for.
Re: Unison Cloud
#89Earlier quoted context omitted.
This may be more of a comp. sci. answer than you're looking for, but the thing I find most unique is the content-addressed functional language underlying it. Content-addressed meaning that definitions can be identified with "a hash of the AST", which is used as the building block for distributed programming: https://www.unison-lang.org/docs/the-big-idea/ I see the unison.cloud service itself as more of a first large-…
In a weird way, it's what JDSL wanted to be https://thedailywtf.com/articles/the-inner-json-effect
[dead]
Re: Unison Cloud
#90Here'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