[borland]

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 sure it'd be worth it. Good luck to them though for being ambitious.

[pchiusano]

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

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

[mike_d]

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]

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]

Most programs are written in a context where hiring someone is not an option.

[dmix]

So as an end user it's kind of like a more cohesive version of 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]

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

[adastra22]

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

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

[jweir]

It is very experimental as well. An interesting language, but say good by to tried and true tooling since the code exists as records in database, not files.

This could lead some huge advantages, and new obstacles.

I played with the language for about a week and found it intriguing. And it seems to approach tackling Joe Armstrong's question "Why do we need modules at all?" -> https://erlang.org/pipermail/erlang-questions/2011-May/05876...

[christophilus]

This is the Joe Armstrong idea I was trying to remember a while back when we were discussing NPM and micro-dependency madness.

[paxys]

The point of the effort is the new language. Hosting and the rest are added on top of it. So yes, if you just want to host some code you shouldn't be rewriting all of it in Unison. But if you are already a user of the language then this is a good framework for you.

[parentheses]

++

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.

[seagreen]

The odd thing is unison started purely as a language. Now there's a platform.

I often find the best way to understand complex things is to dig all the way back to when they were being thought up. In this case there's a blog post from 2017 that I still find useful when thinking about Unison:

https://pchiusano.github.io/2017-01-20/why-not-haskell.html

Key quote:

Composability is destroyed at program boundaries, therefore extend these boundaries outward, until all the computational resources of civilization are joined in a single planetary-scale computer

(With the open sourcing of the language I doubt it will be one computer anymore, but it's an interesting window into the original idea)

Personally I find there's a lot to this. It's interesting that we're really, really good at composing code within a program. I can map, filter, loop and do whatever I want to nested data structures with complete type safety to my heart's content. My editor's autocompleting, docs are showing up on hover, it's easy to test, all's well.

But as soon as I want cron involved, and maybe a little state-- this is all wrecked. Also deployment gets more annoying as they talk about a lot.

So I think Unison always had to have a platform to support bringing this stuff into the language, even though they built the language first.

I'd love to hear some opinions from outside Unison about how they like using this language, tooling and hosting.

I'd like to hear this too.

Also, it would be great if there was something like https://eugenkiss.github.io/7guis/ or https://todomvc.com/ for platforms that we could use to compare Unison, AWS, etc etc. Or is there already a 7GUIs for platforms that I don't know about?

[jcwilk]

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.

[joyfulcoder]

I've been using Unison over Christmas.

I'm not affiliated with the company at all.

I built the start of a very basic site with Unison and HTMX.

https://cross-stitch-alphabet.netlify.app

In my day job I'm a Rails developer. I've been consistently frustrated at how few languages are truly composable and been getting increasingly disillusioned with mainstream languages.

So that's my context.

The not so great:

The language and principles are hard to learn. I've had to throw away what I already know about a lot of programming.

Coding inside ucm requires a very different mentality to how we build software.

The tooling is still early days and has many rough edges.

Performance is currently poor but will get much better shortly.

Abilities are incredible but demand the user to be very familiar with recursion.

Like many on here, I have lots of questions. It's not clear how migrations will work. I don't understand BTrees. If unison corp goes under what happens to my code?

Now for the good.

Unison is, hands down, the most radically joyful language I've ever used.

It's caused me to realise that most tools we use in software are faulty primitive compared with what they could be.

The fact is that even the benefits in the marketing of Unison are a scratching the surface of what's possible in this language.

For example, by spending a few hours I made the basics of an end to end testing library that emulates HTMX with local function calls.

This, if fleshed out, would mean the holy grail for me - fast cacheable end to end tests that do not require a browser to be spun up.

The possibilities are mind boggling.

I was utterly delighted with the deploy in a single function feature, something I'm now never going to be able to go back from having.

And deploying a database with schema in two lines is just jaw dropping.

Every time I use Rails now it's clear how much better our coding experience could be.

By building in Unison you get ports and adapters for free. Never have to wait for a test suite again. No infrastructure as code. No JSON. No yaml. Bliss.

In summary, it's radical. Would I run a production system on it yet? Nope.

Would I watch it keenly until it amasses a bit more momentum? You bet.

I believe whether unison succeeds or fails, this is the future of programming.

Oh and they're a delightful group of people to be around. The discord community has been beyond supportive to me whilst learning the language.

[KPGv2]

Hello! I'm a user of Unison. Been toying with it off and on since I heard about it maybe spring of last year from a Reddit post on the functionalprogramming sub.

As a somewhat stay-at-home dad I was looking to do something fun with programming, and ideally something where I could make an early impact. About the same time, I read about Tree Sitter Grammars and was looking at Lapce, a Rust IDE in its early stages, and uses TSGs for syntax highlighting.

So I ended up learning everything about the Unison syntax, going so far as to learn me a Haskell for great good to produce the TSG for Unison.

About that time, Unison started opening up early testers of Cloud. I passed because I hadn't really written much code in Unison. I'd just been writing the TSG (in C++ and JS).

But then I picked a project: write an implementation of Philips Hue's bridge API in Unison. In the process, I learned about server-sent events and wrote a library for that and released it on Unison Share, which I think of as a mix of Github and NPM (or Maven, or pypi, etc.). I also wrote a MimeType typings library.

I can't speak to the cloud stuff yet, and when I do use it, I won't have much to compare it to because my ops exposure in my profession (as a stay at home dad, haha) is limited.

That's my background, and here are my thoughts:

First, the Local UI for browsing your code and documentation is hands down the best I've ever seen. Everything you write is browsable there, and has hyperlinks to everything else. It's so money. And there's a `Doc` type as well, so you can write something like

  {{
    The first parameter of {term Internal} represents a count, and the second parameter represents a distance in 1-space.
  }}
  type Foo = Internal Nat Int

Then you can `add` and `Foo` will be stored in the current namespace, but so will `Foo.doc`, which is the content inside `{{ ... }}`. You can then delete this code from your scratch file and never think about it again.

If you browse the Local UI (you type `ui` in your `ucm` instance and it auto-loads in a browser), you can easily view the type, the doc above it, and you can click `Nat` or `Int` to be taken to the definitions of these in the base library, located at `lib.base` (`lib` is like your dependencies, like `node_modules` in JS, e.g.).

Say you later want to add a third type parameter. `edit Foo` and the current definition will be pretty printed to your scratch file. Then you can edit it, and run `update`. Anything relying on this type that can be migrated to the new definition will, and anything that can't automatically be migrated will get dumped to your scratch file for you to update manually. Once you have no more errors in your scratch file, `update` will finish it.

This feels a lot like the process of `git rebase --continue` until everything is consistent. Except here it's the code itself that `ucm` understands, not text data that `git` doesn't understand beyond "this is text with conflicts."

From one `ucm` instance, I can switch between projects. No managing folders on my computer in `/Users/foo/workspace/foo-project`, etc.

Anyway, the long and short is that once I got used to working this way, I immediately wished this existed for TypeScript as well, bc that's what I do so much of my work in. The doc generation is incredible, the source browsing is so good, and the process of updating my code is really slick. A few versions ago, it was less so, but it's been improved since then and now I really like it.

Pushing code is as easy as `push`. You can create releases of your libraries or applications by going to Unison Share, finding your project, and navigating through the simple "cut a release" wizard.

There are even types for License, CopyrightHolder, etc. so metadata about your application can be done in code. For example, the license for my mimeType library is

  LICENSE : License
  LICENSE = License [copyrightHolders.kpg] [Year 2024] mit

The type for `License` is defined as `License [CopyrightHolder] [Year] LicenseType. There are pre-configured license types in the base library, and `mit` is one of them.

I find this to be a nice addition as well, although for many this is something to be ignored. But I like the idea of encapsulating so much of a project in code rather than in things like a `package.json` file that is brittle.

The one other thing I'd like to mention is abilities. It was hard to wrap my head around them at first. I'm really familiar with monadic programming. My coworkers might say I'm too in love with it :) Wrapping my head around abilities was hard at first. They're kind of like...monads, DI, and interfaces all sort of mixed together. But there's essentially two components: the ability, and the ability handler. The ability is like you defining an interface. Any handler needs to know how to handle any of the "requirements" of the ability. For example, you might write an application that communicates with an api for example.com as

  ability Example where
    getAll : '{Example} [Foo]
    get : FooId -> {Example} Foo

You're somewhat defining an interface that handlers need to conform to (i.e., they must have code that handles each of the "ability requirements"). Your handler then essentially converts your abilities to more fundamental ones, or removes them completely. You're generally working your way, in an application, down to only IO and Exception abilities (there's probably some cloud abilities I am not familiar with), which UCM handles natively.

Your handler is like the implementation of an interface.

From there, you can write code using anything in that ability, and so long as some ancestor function call wraps all that in a handler, everything just works. It kind of acts like injecting your handler as a dependency of everything that is a descendant function of the handler.

I don't know if I'm effectively communicating how this works, but it makes sense for me. Those are the analogues I'm familiar with that I used to understand the ability system.

Now that I feel comfortable with it, it's pretty cool!

Edit: My final thoughts is that the language is really nice to use (though there are some things from TypeScript I miss, they're very few, and it's certainly superior to something like Java IME). It's nice the VCS and documentation/code browser is built in. Being able to push to a repo, again built into the ucm program, is convenient. Everything is wrapped up nicely. And the company behind the language is extremely online and repsonsive. I've gotten so much help from them. I wish I could speak to the cloud offerings, but I haven't worked with it yet.

[zawodnaya]

There is source control on https://share.unison-lang.org/

[__MatrixMan__]

Is a language built around a pretty exciting idea. I'd drop quite a lot to go work in Unison, if only to see what the world looks like through that lens.

Tinkering on the weekends just isn't the same.