Does anyone know which parts are open source and which parts are proprietary? Discarding the obvious hosting service. For example: is the storage layer, mentioned in the landing page, open source? I'm tempted to use it, even as a hosting service.
Unison Cloud
41–50 of 158 posts
Re: Unison Cloud
#42Combining a custom language with a custom cloud, seems to be something they have leveraged to make some great strides.
Re: Unison Cloud
#43I 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
Re: Unison Cloud
#44Re: Unison Cloud
#45Re: Unison Cloud
#46Is Unison something I can easily self host? I wouldn't want to be vendor locked to Unison Cloud.
I would even pay a few bucks (one time, not a subscription) to license this software for use. I would love to use Unison for my personal projects, but I'm not about to get locked-in to something, I'd rather build something myself that was worse than this than get locked in for personal projects. I know it has a free tier now , but in the future that may not exist.
Re: Unison Cloud
#47Whoa, I just started building something similar for scrapscript! Curious: Who is the target demographic for this service? Hobbyists? I'm also interested in what benefits unison touts specifically. Is the only reason to choose unison over Cloudflare's workers the conveniences of functional typing and other ergonomics?
Unison is an actual language with many cutting edge features. Im fairly sure Unison was created for a mix of practical and theoretical concerns, especially the intersection thereof. My gut tells me Cloudflare workers are some type of low-code solution.
Re: Unison Cloud
#48Re: Unison Cloud
#49Earlier 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-…
Joe Armstrong can finally be happy :D
[0] https://erlang.org/pipermail/erlang-questions/2011-May/05876...
Re: Unison Cloud
#50It 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…
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