10 ms·

It definitely is ambitious! A multi-year effort. This post https://www.unison.cloud/our-approach/ https://www.unison.cloud/our-approach/ talks more about why s

It definitely is ambitious! A multi-year effort. This post https://www.unison.cloud/our-approach/ 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 innovate" is: if you can get a 10x or more improvement in some important dimension by doing things differently, it can absolutely be worth it. This is the philosophy we've applied in developing Unison over the years. I am generally happy to learn something new if I know that I'll be getting something substantial out of it. Of course it can be hard to tell from the outside if the benefits really are worth the changes. I'm not sure what to say about that, other than try it out with something low risk and decide for yourself. Besides the distributed programming / cloud stuff, I'll give a couple other examples where we gain advantages by doing things differently: 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 until it's changed. This has saved me countless hours compared to other static languages. And I don't have to give up static typing to get this. This sort of content-addressed caching also plays out for testing - for pure tests (which are deterministic), Unison has a test result cache keyed by the hash of the test code. This also saves countless hours - imagine never needing to rerun the same tests over and over when nothing's changed! (And having certainty that the cache invalidation is perfect so you don't need to do a "clean build just to be sure") Also replied here re: self-hosting https://news.ycombinator.com/item?id=39293568 https://news.ycombinator.com/item?id=39293568

dmix 3y ago
So as an end user it's kind of like a more cohesive version of https://deno.com/ https://deno.com/ for infra, where you buy into a runtime + comes prepacked with DBs (k/v stores), scheduling, and deploy stuff? > 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 until it's changed. Interesting. Whats it like upgrading and managing dependencies in that code? I'd assume it gets more complex when it's not just the Unison system but 3rd party plugins (stuff interacting with the OS or other libs).
- pchiusano 3y ago
  Yes, I think Deno's a decent analogue for what we're doing, though the Unison language provides some additional superpowers that we find essential. The https://www.unison.cloud/our-approach/ https://www.unison.cloud/our-approach/ post has more details on why the language "needs" to change to get certain benefits. (This is not a knock against Deno, btw, I think it's an awesome project!) > Interesting. Whats it like upgrading and managing dependencies in that code? I'd assume it gets more complex when it's not just the Unison system but 3rd party plugins (stuff interacting with the OS or other libs). In Unison, there's an all-in-one tool we call the Unison Codebase Manager (UCM) which can typecheck and run your code and talk to the code database (we use SQLite for this). The workflow is that you have your text editor / VS code open, and UCM in another terminal, watching for changes. So if you want to edit a definition, say, here's the workflow - 1. `edit blah` brings code into a scratch file, pretty-printed. You make your changes and get that compiling. 2. You type `update` in UCM, and it tries to propagate this change throughout your project. If it can, you're done. If it can't (say because you've changed a type signature), UCM puts the minimum set of definitions in your scratch file. You get this compiling, then do `update` again and you're done. It's quite nice! The scratch files are very ephemeral and not the source of truth. For library dependency upgrades the process is similar: you fetch the new version, then use `upgrade` to say "I want my project to exclusively use the new version". If everything's compatible, you're done. If there's incompatible changes, UCM creates a scratch file with the minimum set of things to get compiling. One interesting benefit is you can have multiple versions of the same library in use in your project. Unison doesn't care if you do this (though it can get confusing so people tend to consolidate). But there are cases where we've made good use of the ability to reference multiple "incompatible" library versions within a project.
bloppe 3y ago
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 3y ago
  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 3y ago
    You sure are doom and gloom about something that was released today
- biggestlou 3y ago
  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 3y ago
    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.
mike_d 3y ago
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.
- dr_kiszonka 3y ago
  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)
- fulafel 3y ago
  Most programs are written in a context where hiring someone is not an option.
adastra22 3y ago
> 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 until it's changed. So… ccache?
- actionfromafar 3y ago
  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. :-)

dmix 3y ago

So as an end user it's kind of like a more cohesive version of https://deno.com/ https://deno.com/ for infra, where you buy into a runtime + comes prepacked with DBs (k/v stores), scheduling, and deploy stuff? > 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 until it's changed. Interesting. Whats it like upgrading and managing dependencies in that code? I'd assume it gets more complex when it's not just the Unison system but 3rd party plugins (stuff interacting with the OS or other libs).

pchiusano 3y ago
Yes, I think Deno's a decent analogue for what we're doing, though the Unison language provides some additional superpowers that we find essential. The https://www.unison.cloud/our-approach/ https://www.unison.cloud/our-approach/ post has more details on why the language "needs" to change to get certain benefits. (This is not a knock against Deno, btw, I think it's an awesome project!) > Interesting. Whats it like upgrading and managing dependencies in that code? I'd assume it gets more complex when it's not just the Unison system but 3rd party plugins (stuff interacting with the OS or other libs). In Unison, there's an all-in-one tool we call the Unison Codebase Manager (UCM) which can typecheck and run your code and talk to the code database (we use SQLite for this). The workflow is that you have your text editor / VS code open, and UCM in another terminal, watching for changes. So if you want to edit a definition, say, here's the workflow - 1. `edit blah` brings code into a scratch file, pretty-printed. You make your changes and get that compiling. 2. You type `update` in UCM, and it tries to propagate this change throughout your project. If it can, you're done. If it can't (say because you've changed a type signature), UCM puts the minimum set of definitions in your scratch file. You get this compiling, then do `update` again and you're done. It's quite nice! The scratch files are very ephemeral and not the source of truth. For library dependency upgrades the process is similar: you fetch the new version, then use `upgrade` to say "I want my project to exclusively use the new version". If everything's compatible, you're done. If there's incompatible changes, UCM creates a scratch file with the minimum set of things to get compiling. One interesting benefit is you can have multiple versions of the same library in use in your project. Unison doesn't care if you do this (though it can get confusing so people tend to consolidate). But there are cases where we've made good use of the ability to reference multiple "incompatible" library versions within a project.

bloppe 3y ago

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 3y ago
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 3y ago
  You sure are doom and gloom about something that was released today
biggestlou 3y ago
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 3y ago
  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.

mike_d 3y ago

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.

dr_kiszonka 3y ago
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)
fulafel 3y ago
Most programs are written in a context where hiring someone is not an option.

adastra22 3y ago

> 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 until it's changed. So… ccache?

actionfromafar 3y ago
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. :-)