13 ms·

Unison Cloud

281 points by dcre 3y ago

beefman 3y ago
"Unison Cloud is now generally available" https://twitter.com/unisonweb/status/1755266140924784738 https://twitter.com/unisonweb/status/1755266140924784738
adverbly 3y ago
Congrats! I haven't tried unison, but it sounded like magic when I first heard about it here: https://www.youtube.com/watch?v=Adu75GJ0w1o https://www.youtube.com/watch?v=Adu75GJ0w1o (Worth a watch - Rúnar is awesome)
surprisetalk 3y ago
Whoa, 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?
- _delirium 3y ago
  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/ https://www.unison-lang.org/docs/the-big-idea/ I see the unison.cloud service itself as more of a first large-scale demo of what you can build on that idea (which will hopefully also fund it). But the underlying language is open source and I think could have legs in a bunch of possible applications.
  - surprisetalk 3y ago
    Thanks! Yeah, my language is content-addressable too, which is why I'm interested in how it's being used in the wild. [1] https://scrapscript.org https://scrapscript.org I'm excited to see how it progresses beyond "first large-scale demo"!
  - RadiozRadioz 3y ago
    In a weird way, it's what JDSL wanted to be https://thedailywtf.com/articles/the-inner-json-effect https://thedailywtf.com/articles/the-inner-json-effect
    - pdimitar 3y ago
      I need a full liter of unsee juice to recover after reading this.
    - rizky05 3y ago
      [dead]
  - azeirah 3y ago
    Joe Armstrong can finally be happy :D
    - losvedir 3y ago
      Ha, indeed. For context[0]. That's stuck with me ever since I read it, and I immediately saw that Unison kind of ran with that idea, when I came across it many years ago. I've always been interested and following on the sidelines, but haven't tried it out yet. Maybe now is the time. [0] https://erlang.org/pipermail/erlang-questions/2011-May/058768.html https://erlang.org/pipermail/erlang-questions/2011-May/05876...
- ParetoOptimal 3y ago
  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.
  - kentonv 3y ago
    > My gut tells me Cloudflare workers are some type of low-code solution. Cloudflare Workers hosts servers written in JavaScript / Wasm.
  - paint 3y ago
    [dead]
- posix86 3y ago
  On their website, they explain that they attempt to lift the idea of a programming language describing computation within a single process to computation across services, made of different processes, connected e.g. via the internet. Which sounds incredibly ambitious, but might be where we're headed.
fuddle 3y ago
Is Unison something I can easily self host? I wouldn't want to be vendor locked to Unison Cloud.
- ok_dad 3y ago
  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.
  - eweise 3y ago
    The language is free to use.
    - ok_dad 3y ago
      Yes but what’s a language without a deployment strategy?
      - eweise 3y ago
        Not familiar with its deployment strategy. I assumed it could built into a binary but maybe not.
      - badelectron 3y ago
        Since this announcement is about Unison Cloud, it might not be clear for people who aren't familiar with the Unison language that you can run Unison programs without Unison Cloud. So much like just about any other language you can put a Unison program in a Docker container, deploy it via AWS Lambda, etc. Unison Cloud is kind of an "easy mode" for scalable and distributed deployment with support for typed durable storage, the option to expose public HTTP/websocket endpoints, etc. Here is an example of containerizing a Unison program: https://github.com/ceedubs/containerized-unison-program https://github.com/ceedubs/containerized-unison-program And here is a library that makes it easy to create an AWS Lambda out of a Unison function: https://share.unison-lang.org/@gfinol/lambda-runtime https://share.unison-lang.org/@gfinol/lambda-runtime
rywalker 3y ago
Similar to https://www.ubicloud.com/ https://www.ubicloud.com/ ?
- dcre 3y ago
  ...no
- dmd 3y ago
  In that they both start with 'u', yes.
mhitza 3y ago
I wonder if Unison Cloud is built with the Unison language, that would prove language maturity in my eyes.
- pchiusano 3y ago
  Yes, it is! Of course there's other technologies involved but the core services for our compute fabric and storage layer are pure Unison[1]. A number of open source libraries in the Unison ecosystem were developed via us eating our own dogfood while developing Unison Cloud. Same with evolution of the language and tooling, which we've continued improving. We have a few things still in Haskell which we'll probably move into Unison eventually. [1]: Just to clarify, our storage layer wraps DynamoDB in an interesting way to provide the transactional API we wanted - we didn't literally implement our own cloud database on top of just the file system and some VMs. :)
satvikpendem 3y ago
I don't "get" Unison the language, could someone explain how it's different than other languages? Is it something like tRPC combined with serverless, but at a language level?
- rlmark 3y ago
  I'll give it a shot; I think it's helpful to separate the Unison programming language from the Unison Cloud platform, as they're distinct things even though the features of one (the language) enable and are integrated with the other (the Cloud, which operationalizes the language for web apps and other cloud compute jobs). Unison's core difference is that your code is not stored as regular text files; instead your functions and types are stored as a hash of their AST. This enables nice dependency management workflow and makes things like renaming functions trivial. The thing to remember is that your functions are programmatically tracked. Based on that core difference we built a platform that can deploy those arbitrary hashes (and all their dependencies) to different locations in a cluster, and we created a Unison library so that folks can describe how their code should be shipped across cloud computing resources. So you have Unison code describing and orchestrating Unison services.
VirusNewbie 3y ago
Looks really cool. I hope they wrap their language with a variant of python or typecript or something, as I think a lot of the former programmers would embrace this type of deployment model. I'm just not sure they'd want to learn haskell style syntax.
- pchiusano 3y ago
  Hi, one of the Unison creators here. We've talked about adding pluggable syntax[1]. It's in principle straightforward (the code is already stored in a database as its abstract syntax tree, not text) and I imagine a future version of Unison could let you pick from a variety of syntaxes. But we haven't gotten to it yet. [1] https://github.com/unisonweb/unison/issues/499 https://github.com/unisonweb/unison/issues/499 ... that said, the language semantics and libraries are still going to be different, so even if we have a python-ish or typescript-y syntax, there'll still be new things to learn. :)
  - actionfromafar 3y ago
    I think you guys are a self-selected bunch of very smart people, also unafraid to break ground and try something new - so you may underestimate how much a familiar syntax means to us plebs. For instance, Erlang always intrigued me, but Elixir (familiar syntax but with Erlang semantics for those who don't know) was what made me really consider the Erlang ecosystem.
    - pchiusano 3y ago
      Thanks for this feedback. We will get there!
LeoPanthera 3y ago
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 https://github.com/bcpierce00/unison
- Szpadel 3y ago
  I also assumed that this is related with this sync and I had problem with understanding this project by assuming this is some cloud extension of it
- monkey26 3y ago
  A great tool I still use everyday.
- amanzi 3y ago
  I'm old enough that I thought this was related to the old mainframe/UNIX company from the 90s!
  - ttepasse 3y ago
    I'm somewhere in the middle and remember it as a Newsnet Client for Mac OS from Panic: https://blog.panic.com/the-future-of-unison/ https://blog.panic.com/the-future-of-unison/
- lenkite 3y ago
  I too thought it was some new-fangled cloud storage-sync platform based on Unison sync.
haolez 3y ago
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.
- zawodnaya 3y ago
  The language and all the libraries are open source. The storage layer API is open-source as well though the implementation is proprietary, as is the implementation of other parts of Unison Cloud (like the part that actually hosts your Unison code on AWS).
jevoten 3y ago
To me, the most interesting aspect is the Unison language, specifically how it does away with code-as-text, and instead uses a structured database, so one is dealing directly with the AST: https://www.unison-lang.org/docs/the-big-idea/ https://www.unison-lang.org/docs/the-big-idea/ (It is not the only language to do so - see old.reddit.com/r/nosyntax) I hope this catches on, because parsing strings of text is a monumental waste of complexity.
- sp33der89 3y ago
  This, plus abilities[1](what Unison calls algebraic effects), make Unison such a joy to work with, it's a very pleasant experience. You can get straight to the business logic. I also hope it catches on, but Unison right now really gives a pleasant experience. [1]: https://www.unison-lang.org/docs/fundamentals/abilities/ https://www.unison-lang.org/docs/fundamentals/abilities/
duckman1 3y ago
[dead]
suralind 3y ago
OK, maybe this is a silly question, but if a function that is written once always refer to the same hash as when it was written, how do you update functions? For example, if I have function A that calls function B, in today's languages updating function B would just work (A will call updated function). My understanding is that updated function B (we can call it B'), would not be used.
- stewoconnor 3y ago
  Unison developer here! Let's say you have some term: B = "Hello " and it hashes to #a3yx. Lets say you also have funcion: A = B ++ "world" which hashes to #c7c1 when we store the A function, we actually store it as: #c6c7 = #a3yx ++ "world" Then later if you update the definition of B: B = "Hello, " and that function hashes to, #5e2b, when you tell unison to update B from #a3yx => #5e2b, it will look for all of the places that used to reference #a3yx, like your A function, and will see if those functions still typecheck with the replacement. If so, they are automatically updated. If not, we pretty print the definitions that didn't to a file for you to manually fix.
  - alephaleph 3y ago
    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?
    - stewoconnor 3y ago
      for us, A and B are the same Term since they have the same hash, they are just two different alias for that hash, so if you update either, you are effectively updating both. In fact if you had the function: double x = x + x and you were to rewrite it to be: double addend = addend + addend Unison would say "this is the same function, no update needed" as it produces the same AST
    - rlmark 3y ago
      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 the function name as metadata and the actual implementation as the identity of the function.
ch0ic3 3y ago
Exciting! I was wondering when this would be released given the website said (until a few days ago it seems) it would be ready in Dec 2023
borland 3y ago
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.
- parentheses 3y ago
  ++ 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 3y ago
    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 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/ https://eugenkiss.github.io/7guis/ or https://todomvc.com/ 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?
sroussey 3y ago
Pretty cool stuff. Anyone ever make a babel plugin that would check for identical function definitions?
- zephraph 3y ago
  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).
  - sroussey 3y ago
    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!
dang 3y ago
Related. Others? Unison Language - https://news.ycombinator.com/item?id=37500406 https://news.ycombinator.com/item?id=37500406 - Sept 2023 (1 comment) Unison Language and Platform Roadmap - https://news.ycombinator.com/item?id=36333409 https://news.ycombinator.com/item?id=36333409 - June 2023 (23 comments) A look at Unison: a revolutionary programming language - https://news.ycombinator.com/item?id=34307552 https://news.ycombinator.com/item?id=34307552 - Jan 2023 (84 comments) The Unison language – a new approach to Distributed programming - https://news.ycombinator.com/item?id=33638045 https://news.ycombinator.com/item?id=33638045 - Nov 2022 (113 comments) Unison Programming Language - https://news.ycombinator.com/item?id=27652677 https://news.ycombinator.com/item?id=27652677 - June 2021 (131 comments) Unison: A Content-Addressable Programming Language - https://news.ycombinator.com/item?id=22156370 https://news.ycombinator.com/item?id=22156370 - Jan 2020 (12 comments) The Unison language - https://news.ycombinator.com/item?id=22009912 https://news.ycombinator.com/item?id=22009912 - Jan 2020 (141 comments) Unison – A statically-typed purely functional language - https://news.ycombinator.com/item?id=20807997 https://news.ycombinator.com/item?id=20807997 - Aug 2019 (25 comments) Unison: a next-generation programming platform - https://news.ycombinator.com/item?id=9512955 https://news.ycombinator.com/item?id=9512955 - May 2015 (128 comments)
ThinkBeat 3y ago
This looks to me like some real innovation. I am looking forward to digging into this. Combining a custom language with a custom cloud, seems to be something they have leveraged to make some great strides.
- alfanick 3y ago
  Yup great for business, horrible for users - just get lock in and keep paying. But great business idea.
jakjak123 3y ago
Tbh this is not the worst idea I've seen. I hope you can make it, because I would have a hard time justifying such an experimental platform and idea as a foundation for a company.
niffydroid 3y ago
I was thinking the UK Union unison when I saw the title
paint 3y ago
[dead]
roboben 3y ago
Seems like half the unison team is here in this thread. Congrats, looking forward to try it out!
rsync 3y ago
Unison friends: Is there an rclone handler/recipe extant, or in the works, that would facilitate inter-cloud data transfer ? Asking for a friend ...
- rlmark 3y ago
  There is not, at present, an rclone library, but this would be a welcome addition to our open source cloud libraries. Perhaps your friend would like to write such a utility! :-)
ahmedfromtunis 3y ago
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, req): name = req.GET.get("name") return f"<p>hello {name}!</p>" def deploy(self): from PyCloud import cloud project = cloud.create_project(self) project.deploy() # main.py from .app import App app = App() url = app.deploy()
- benpacker 3y ago
  Yep, that’s right. Modal (https://modal.com 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
  - ahmedfromtunis 3y ago
    I never heard of them before, but they offer is amazing -- even though I don't think I'll be using anytime soon.
davedx 3y ago
It's crazy but it just might work! Even if I never use this, it's incredibly refreshing to see a genuinely new approach to delivering applications. Some of this feels subtly like Smalltalk. Some very interesting ideas here: https://www.unison.cloud/our-approach/ https://www.unison.cloud/our-approach/
- jadbox 3y ago
  I feel the same. My initial reaction is that I like the vision, but I feel there is probably a compromise to build these mechanics into a library for many languages, rather than requiring the DC burden of picking up a new 'better cloud' centric language. Perhaps I just haven't developed an appreciation for language capabilities yet.
ildjarn 3y ago
Has anyone used Unison instead of Spark? Seems like a natural fit to me.
- rlmark 3y ago
  We wrote an article speaking to this use case here: https://www.unison-lang.org/articles/distributed-datasets/ https://www.unison-lang.org/articles/distributed-datasets/ It's a bit of a deep dive into some of the building blocks of the Remote ecosystem - so it talks quite a bit about how you'd implement something like Spark itself in Unison, but you can see how running data aggregations would work on the Cloud.
- stewoconnor 3y ago
  We recently did a series of blog posts exploring how our remote programming model makes us a good fit for writing distributed map - reduce like programs. https://www.unison-lang.org/articles/distributed-datasets/ https://www.unison-lang.org/articles/distributed-datasets/ One of the real strengths of individual parts of your program being content addressed, and our ability system that lets us track side effects, we can have a programming model where you only need to talk abstractly about where your data is, and how you'd like to operate on it, and then we have the ability to have our cluster gossip about parts of your program that need to be shipped to where parts of your data is. One node can ask another node "please apply this function to the data you have" and the other node can gossip to get any missing definitions it needs for that function. You never have to talk about serialization or network connections or software distribution, we know how to move data for you, move code for you, and in some cases even cash partial program results.
winkelwagen 3y ago
I tried it a couple of times, but the showstopper for me was the hosting model was the show stopper. I think the premise of the language and platform has so many amazing aspects that are very exciting to me. But it also i had a hard time imagining pitching this together with unison cloud to my team. All the components together at this moment in time. A very big investment into an ecosystem. Hope some smart developers would take the learning and try to integrate it with existing languages like clojure. Still going to follow what unison is doing because it is so exciting
steve_adams_86 3y ago
Apologies if this is a dumb question, and maybe it applies to other services I may already use, but: What if Unison language and the Cloud have a vulnerability. Would you suddenly have a large network of services that could be readily exploited? This sort of "infrastructure monoculture" situation gives me the heebie-jeebies, but I'm admittedly pretty dumb when it comes to security. I imagine that with my Google Cloud Run instance running who-knows-what language on maybe some framework, the opportunities to zero in on an exploit are fewer than when an attacker can know exactly what's running, what it's running on, and perhaps even have the ability to enumerate to find instances off of pro plans since they may often use auto-generated names from hyphen-separated common words. If the sandboxing of instances is poor, it seems like it could be a huge problem. Again, I have no idea what I'm talking about. Mostly curious to learn more, not criticize.
- pradn 3y ago
  This problem exists with all shared code. Shared code, shared fate. You hope that with more eyes on a library, it'll be more secure. It may also mean vulnerabilities have a higher blast radius. You have to choose where you want to lie on the balance. Spectre and Log4J - problems on widely deployed tech (Intel CPUs, Java services).
  - steve_adams_86 3y ago
    Very good point at the end; the lower level you go, the broader (and likely more severe) your vulnerabilities will be. I suppose in this case my concerns aren't warranted, or at least not worth placing before more immediate and obvious concerns. i.e., I could write shitty code a lot more easily than Unison could compromise their language and infrastructure.
59nadir 3y ago
This is about the Unison language but I think it's relevant. I was checking out the FAQ for Unison and noticed this: https://www.unison-lang.org/docs/usage-topics/general-faqs/#does-unison-have-an-ffi https://www.unison-lang.org/docs/usage-topics/general-faqs/#... > Unison does not currently support a Foreign Function Interface, for invoking code written in other languages. > Your programs can interact with the outside world via the `IO` ability, and this includes interaction via network sockets - so you can interact with code written in other languages if that code can expose a network interface, for example as a web service. We'd like to improve on this position in the future. So far so good, I guess. They're trying to do something that makes sense in the future. They then go on to outline how they're apparently going to expose specific parts of what you might want to use, like `GPU` as an ability/effect...? What do I do when I just want to execute some of my C code and don't want to jump through hoops to do so? I get that this maybe falls apart entirely because of the idea of content-addressable functions, but can't an FFI binding be the hash of its name and inputs and output or something? Maybe I'm misunderstanding their plan with regards to FFI solutions. In the end I'd like to just have something like this with both static and dynamic libraries: ModuleName = foreign import c [libmodule.a, otherlib.so] ModuleName.OpaqueCoolType a = OpaqueCoolType a ModuleName.has : a -> OpaqueCoolType a -> Bool
- pchiusano 3y ago
  Hi, one of the Unison creators here. We've held off working on FFI until the JIT compiler[1] is completed since FFI is closely connected to the runtime. There's some interesting subtleties with FFI in a distributed programming language, so I'll ramble about that here in case it's interesting to you. :) So, in Unison, all values are serializable, including functions and their dependencies. This is a key superpower that enables a lot of the neat stuff we do. As long as those functions are written in pure Unison, we can easily serialize them, deploy them on the fly, etc. But when we add an FFI, the story changes - the sender may have some C library in their environment, and that library may not exist at the recipient node. The two nodes could be different platforms, one Mac, one Linux, and the library may have been written specifically for Linux, say! So when we add FFI, we will likely be doing it in a different way than most languages. Functions that use FFI will have this tracked in the their type, using our effect system. You'll be able to use whatever C libraries you want in your local computations, but if you want to sent those values around, you need to be sending them to a place that supports that same set of FFI effects, since the C library and its dependencies can't literally be deployed on the fly in the same way as pure Unison code. In our cloud platform, nodes are typed based on what effects they support and we'll probably add a way to create new node pools that have access to whatever C libraries you want. In "regular" programming, we're not used to thinking about "the execution environment" as a thing that's represented explicitly within the program. Instead, there's an assumed execution environment (which includes the set of native libraries, etc) and you get runtime errors if you run a program and some of the assumed execution environment is missing (like a shared library, say). For the most part, people have been okay with this, but it's already somewhat of a problem for languages that target the browser and the backend. The language may be statically typed, but now the type system is not tracking some key information - namely, is this a function I can call here (if I'm expecting this code to compile to JS) or is it a function that only can be called for backend code? In a distributed setting with heterogeneous nodes with different capabilities, this problem is even more pronounced, which is why we track this information in the types and plan to do so once we add FFI. Hope that was interesting! [1]: https://www.unison-lang.org/blog/jit-announce/ https://www.unison-lang.org/blog/jit-announce/ is an early progress report, and I think we're finally shipping something in the next month!
ildjarn 3y ago
Can Unison code be stored in a Git repo as text?
- rlmark 3y ago
  We used to support git backed codebase hosting a while ago, before we launched our own remote hosting platform https://share.unison-lang.org/ 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.
  - ildjarn 3y ago
    It might be tough for Unison to be an island outside of GitHub, although I see the benefits.
    - rlmark 3y ago
      Totally fair, there are definitely tradeoffs.
neom 3y ago
"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-profit corporation intended to produce a public benefit and operate in a responsible and sustainable manner. A PBC must be managed in a way that balances the interests of the stockholders, the company’s key stakeholders, and a specific public benefit that the company commits to in its charter." https://www.cooleygo.com/faq-delaware-public-benefit-corporations/ https://www.cooleygo.com/faq-delaware-public-benefit-corpora...
- refried_ 3y ago
  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.
  - neom 3y ago
    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. =)
hedora 3y ago
I was hoping this was like rsync.net, but for unison: https://github.com/bcpierce00/unison https://github.com/bcpierce00/unison Trademarks are hard.
prima-facie 3y ago
Ah I thought this was related to the trusty old Unison two-way file synchronisation tool and my heart skipped a beat. https://github.com/bcpierce00/unison/ https://github.com/bcpierce00/unison/
9dev 3y ago
Forgive 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 infrastructure layer, that makes total sense to me. But then, you’re just shifting complexity from the developer to your cloud service, and hide it behind a proprietary platform (which I don’t mind, all the best for your business!). And I don’t really understand how that will make things better, all things considered. Could someone explain this to me?
- benpacker 3y ago
  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.
- ultra_nick 3y ago
  Unison is a distributed programming language. YAML config files and Hadoop/Kafka/Kubernetes/etc are additions for non-distributed programming languages. Unison is a grand simplification of everything into one system so that future programmers don't have to put up with our crap.
- rlmark 3y ago
  Hi there! There's definitely an overhead to learning a new language but by describing your cloud infrastructure with an actual programming languages you reap the benefits of type-safety, testability, and code reuse, etc. You're spot on with shifting the complexity to the cloud layer; our thought was that it would free up time for dev teams to focus on other layers of their application. Maybe I'm misinterpreting your question though, I'm happy to annotate that code snippet with a walk-through.
Havoc 3y ago
What is the main advantage of this over the classic big cloud function offerings? Sounds like developer experience possibly?
- rlmark 3y ago
  The developer experience would be one of the main advantages. Unison cloud was custom built to run Unison's language without extra steps like building packages, syncing dependencies across nodes, etc. Also, interactions with other cloud platforms typically aren't described in a programming language which is shared between the infrastructure management layer and the application layer. The draw-back is that the Cloud runs the Unison programming language specifically.
k8svet 3y ago
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.
- badelectron 3y ago
  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 identified by their hashes, so there's no (realistic) way that names can collide. Otherwise, Unison and Nix feel pretty different to me. Nix is generally a build-time language for arbitrary runtimes, while Unison is a general purpose language for a specific runtime. Nix takes on the really ambitious goal of wrangling ancient projects built with Makefiles and ambient environments into deterministic builds. Through the heroic effort of derivation authors, they've managed to make it work. But it requires those maintainers to do lots of careful manual tracking of dependencies, pre-build source patches, overriding build steps, etc. Unison takes a much more constrained approach: if we start with a language that is content-addressed at its core and keep running with this idea, where do we end up? One nice outcome of this is that you never need to manually track dependency versions, hashes, etc; the language does that for you. The "tough" part is also there, but feels different. To me the Nix expression language is straightforward, but I find it difficult to wrap my head around nontrivial derivations. To answer questions like "what attributes and build steps can/should I override" I feel like I have to dig through the layers of the implementation. In Unison a powerful static type system and UIs (both local and Unison Share) that support clicking through to any term/type make it easier for me to digest code. The "tough" parts of Unison generally stem from the young ecosystem: fewer existing libraries, a codebase manager that is under active development and not nearly as stable as git, etc. If nothing else Unison is worth a try just because it is so different than most other languages/ecosystems. PS if you are interested in usin Nix to install the Unison codebase manager or to package a program written in Unison these repos might be useful (disclaimer I'm ceedubs): https://github.com/ceedubs/unison-nix/ https://github.com/ceedubs/unison-nix/ https://github.com/ceedubs/unison-nix-snake/ https://github.com/ceedubs/unison-nix-snake/
flying_sheep 3y ago
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
- pests 3y ago
  Many of those are already handled.
- zawodnaya 3y ago
  Or like a whole language to handle them
ilikebits 3y ago
I'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/ 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.
- rlmark 3y ago
  Nice, a structural editor throwback reference! :-) I'll speak to point 1! We aim to add FFI as a fast follow on to the native compilation work that is underway. The work on the JIT compiler opens the door to FFI so that's on the roadmap soon.
sixbrx 3y ago
Unison looks like a neat functional language. Do abilities subsume the role of type classes also (without any "effects")? If so, would there be a loss of efficiency for using pure abilities in this way (since a "handler" needs to interpret the ops)? Sorry I've only had a brief look so I'm not sure this makes sense. Edit: Shorter: do you have type classes
- Quekid5 3y ago
  Abilities are typed effects, effectively. At least, that's how I understand it. (In a less jokey way: Abilities should be thought of as capabilities, and capabilities are what enable you to do I/O, read from a DB, etc. So they are 'effects' in the Pure FP sense.) Not sure about the type classes thing.
- badelectron 3y ago
  Short version: no type classes (yet) Longer version: Building upon what Quekid5 mentioned, Unison abilities are an implementation of what is referred to as algebraic effects in programming language literature. They represent capabilities like IO, state, exceptions, etc. They aren't really a replacement for type classes, though in some cases you can shoehorn abilities in where you might otherwise use a type class. For someone coming from a Haskell background, I think that abilities are closer to a replacement for monad transformers. But in my opinion they are much more ergonomic. Discusson of type classes comes up a lot. Here is a long-standing GitHub issue: https://github.com/unisonweb/unison/issues/502 https://github.com/unisonweb/unison/issues/502 For what it's worth, I've written Unison quite a lot over the past few years and while I've missed type classes at times, I think that reading unfamiliar code is easier without them. There's no implicit magic; you can see exactly what is being passed into a function. So far I've been happy with a bit more verbosity for the sake of readability.
- zawodnaya 3y ago
  Unison doesn't have type classes yet, no
bushwald 3y ago
I'm excited about Unison as a language so I'm glad to see something that will hopefully give it some additional forward momentum
udev4096 3y ago
Looks like just another serverless offering
max_hoffmann 3y ago
I’ve been waiting for this since the first talk about Unison. Love the huge progress you have made and congrats to the public release of Unison Cloud! Question: Is it possible to set the region of the database/storage? Or is there any timeframe when this can be configured? For GDPR reasons I cannot use hosting that doesn’t support storage in the EU.
HenriTEL 3y ago
That's very refreshing and there must be a lot of work behind the scene to properly update services and their dependencies without outages. I'm also curious about how database migrations are dealt with. I'll keep following that space as they have well identified the problem and its root causes. The CNCF is happy of their "ever-growing global community", reaching 173 projects and over 220,000 contributors. Good for them.
nickstinemates 3y ago
winglang is a lot more interesting.
devaiops9001 3y ago
I strongly dislike marketing material that tries to normalize gross incompetency around complexity problems that don't actually exist.
- ParetoOptimal 3y ago
  If you gave examples of what you meant, others might be able to understand and discuss what you mean.
  - devaiops9001 3y ago
    I have been involved in so many projects where AWS, Google Cloud, OpenStack, or Kubernetes (on metal) was used. I'd have to think a bit hard on how to articulate this well, but I see the page linked on this HN thread and it just screams "utter horse shit" to me. Someone who finds AWS so hard to use is either not reading documentation or not comprehending it and probably shouldn't be coding in the first place.
alfanick 3y ago
Is this 21st century COBOL? Some language with some open-spec, made actually to be running in some very closed environment via interactive environment, with no source control?

281 points by dcre 3y ago

"Unison Cloud is now generally available" https://twitter.com/unisonweb/status/1755266140924784738 https://twitter.com/unisonweb/status/1755266140924784738

adverbly 3y ago

Congrats! I haven't tried unison, but it sounded like magic when I first heard about it here: https://www.youtube.com/watch?v=Adu75GJ0w1o https://www.youtube.com/watch?v=Adu75GJ0w1o (Worth a watch - Rúnar is awesome)

surprisetalk 3y ago

Whoa, 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?

_delirium 3y ago
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/ https://www.unison-lang.org/docs/the-big-idea/ I see the unison.cloud service itself as more of a first large-scale demo of what you can build on that idea (which will hopefully also fund it). But the underlying language is open source and I think could have legs in a bunch of possible applications.
- surprisetalk 3y ago
  Thanks! Yeah, my language is content-addressable too, which is why I'm interested in how it's being used in the wild. [1] https://scrapscript.org https://scrapscript.org I'm excited to see how it progresses beyond "first large-scale demo"!
- RadiozRadioz 3y ago
  In a weird way, it's what JDSL wanted to be https://thedailywtf.com/articles/the-inner-json-effect https://thedailywtf.com/articles/the-inner-json-effect
  - pdimitar 3y ago
    I need a full liter of unsee juice to recover after reading this.
  - rizky05 3y ago
    [dead]
- azeirah 3y ago
  Joe Armstrong can finally be happy :D
  - losvedir 3y ago
    Ha, indeed. For context[0]. That's stuck with me ever since I read it, and I immediately saw that Unison kind of ran with that idea, when I came across it many years ago. I've always been interested and following on the sidelines, but haven't tried it out yet. Maybe now is the time. [0] https://erlang.org/pipermail/erlang-questions/2011-May/058768.html https://erlang.org/pipermail/erlang-questions/2011-May/05876...
ParetoOptimal 3y ago
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.
- kentonv 3y ago
  > My gut tells me Cloudflare workers are some type of low-code solution. Cloudflare Workers hosts servers written in JavaScript / Wasm.
- paint 3y ago
  [dead]
posix86 3y ago
On their website, they explain that they attempt to lift the idea of a programming language describing computation within a single process to computation across services, made of different processes, connected e.g. via the internet. Which sounds incredibly ambitious, but might be where we're headed.

fuddle 3y ago

Is Unison something I can easily self host? I wouldn't want to be vendor locked to Unison Cloud.

ok_dad 3y ago
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.
- eweise 3y ago
  The language is free to use.
  - ok_dad 3y ago
    Yes but what’s a language without a deployment strategy?
    - eweise 3y ago
      Not familiar with its deployment strategy. I assumed it could built into a binary but maybe not.
    - badelectron 3y ago
      Since this announcement is about Unison Cloud, it might not be clear for people who aren't familiar with the Unison language that you can run Unison programs without Unison Cloud. So much like just about any other language you can put a Unison program in a Docker container, deploy it via AWS Lambda, etc. Unison Cloud is kind of an "easy mode" for scalable and distributed deployment with support for typed durable storage, the option to expose public HTTP/websocket endpoints, etc. Here is an example of containerizing a Unison program: https://github.com/ceedubs/containerized-unison-program https://github.com/ceedubs/containerized-unison-program And here is a library that makes it easy to create an AWS Lambda out of a Unison function: https://share.unison-lang.org/@gfinol/lambda-runtime https://share.unison-lang.org/@gfinol/lambda-runtime

rywalker 3y ago

Similar to https://www.ubicloud.com/ https://www.ubicloud.com/ ?

dcre 3y ago
...no
dmd 3y ago
In that they both start with 'u', yes.

mhitza 3y ago

I wonder if Unison Cloud is built with the Unison language, that would prove language maturity in my eyes.

pchiusano 3y ago
Yes, it is! Of course there's other technologies involved but the core services for our compute fabric and storage layer are pure Unison[1]. A number of open source libraries in the Unison ecosystem were developed via us eating our own dogfood while developing Unison Cloud. Same with evolution of the language and tooling, which we've continued improving. We have a few things still in Haskell which we'll probably move into Unison eventually. [1]: Just to clarify, our storage layer wraps DynamoDB in an interesting way to provide the transactional API we wanted - we didn't literally implement our own cloud database on top of just the file system and some VMs. :)

satvikpendem 3y ago

I don't "get" Unison the language, could someone explain how it's different than other languages? Is it something like tRPC combined with serverless, but at a language level?

rlmark 3y ago
I'll give it a shot; I think it's helpful to separate the Unison programming language from the Unison Cloud platform, as they're distinct things even though the features of one (the language) enable and are integrated with the other (the Cloud, which operationalizes the language for web apps and other cloud compute jobs). Unison's core difference is that your code is not stored as regular text files; instead your functions and types are stored as a hash of their AST. This enables nice dependency management workflow and makes things like renaming functions trivial. The thing to remember is that your functions are programmatically tracked. Based on that core difference we built a platform that can deploy those arbitrary hashes (and all their dependencies) to different locations in a cluster, and we created a Unison library so that folks can describe how their code should be shipped across cloud computing resources. So you have Unison code describing and orchestrating Unison services.

VirusNewbie 3y ago

Looks really cool. I hope they wrap their language with a variant of python or typecript or something, as I think a lot of the former programmers would embrace this type of deployment model. I'm just not sure they'd want to learn haskell style syntax.

pchiusano 3y ago
Hi, one of the Unison creators here. We've talked about adding pluggable syntax[1]. It's in principle straightforward (the code is already stored in a database as its abstract syntax tree, not text) and I imagine a future version of Unison could let you pick from a variety of syntaxes. But we haven't gotten to it yet. [1] https://github.com/unisonweb/unison/issues/499 https://github.com/unisonweb/unison/issues/499 ... that said, the language semantics and libraries are still going to be different, so even if we have a python-ish or typescript-y syntax, there'll still be new things to learn. :)
- actionfromafar 3y ago
  I think you guys are a self-selected bunch of very smart people, also unafraid to break ground and try something new - so you may underestimate how much a familiar syntax means to us plebs. For instance, Erlang always intrigued me, but Elixir (familiar syntax but with Erlang semantics for those who don't know) was what made me really consider the Erlang ecosystem.
  - pchiusano 3y ago
    Thanks for this feedback. We will get there!

LeoPanthera 3y ago

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 https://github.com/bcpierce00/unison

Szpadel 3y ago
I also assumed that this is related with this sync and I had problem with understanding this project by assuming this is some cloud extension of it
monkey26 3y ago
A great tool I still use everyday.
amanzi 3y ago
I'm old enough that I thought this was related to the old mainframe/UNIX company from the 90s!
- ttepasse 3y ago
  I'm somewhere in the middle and remember it as a Newsnet Client for Mac OS from Panic: https://blog.panic.com/the-future-of-unison/ https://blog.panic.com/the-future-of-unison/
lenkite 3y ago
I too thought it was some new-fangled cloud storage-sync platform based on Unison sync.

haolez 3y ago

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.

zawodnaya 3y ago
The language and all the libraries are open source. The storage layer API is open-source as well though the implementation is proprietary, as is the implementation of other parts of Unison Cloud (like the part that actually hosts your Unison code on AWS).

jevoten 3y ago

To me, the most interesting aspect is the Unison language, specifically how it does away with code-as-text, and instead uses a structured database, so one is dealing directly with the AST: https://www.unison-lang.org/docs/the-big-idea/ https://www.unison-lang.org/docs/the-big-idea/ (It is not the only language to do so - see old.reddit.com/r/nosyntax) I hope this catches on, because parsing strings of text is a monumental waste of complexity.

sp33der89 3y ago
This, plus abilities[1](what Unison calls algebraic effects), make Unison such a joy to work with, it's a very pleasant experience. You can get straight to the business logic. I also hope it catches on, but Unison right now really gives a pleasant experience. [1]: https://www.unison-lang.org/docs/fundamentals/abilities/ https://www.unison-lang.org/docs/fundamentals/abilities/

duckman1 3y ago

[dead]

suralind 3y ago

OK, maybe this is a silly question, but if a function that is written once always refer to the same hash as when it was written, how do you update functions? For example, if I have function A that calls function B, in today's languages updating function B would just work (A will call updated function). My understanding is that updated function B (we can call it B'), would not be used.

stewoconnor 3y ago
Unison developer here! Let's say you have some term: B = "Hello " and it hashes to #a3yx. Lets say you also have funcion: A = B ++ "world" which hashes to #c7c1 when we store the A function, we actually store it as: #c6c7 = #a3yx ++ "world" Then later if you update the definition of B: B = "Hello, " and that function hashes to, #5e2b, when you tell unison to update B from #a3yx => #5e2b, it will look for all of the places that used to reference #a3yx, like your A function, and will see if those functions still typecheck with the replacement. If so, they are automatically updated. If not, we pretty print the definitions that didn't to a file for you to manually fix.
- alephaleph 3y ago
  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?
  - stewoconnor 3y ago
    for us, A and B are the same Term since they have the same hash, they are just two different alias for that hash, so if you update either, you are effectively updating both. In fact if you had the function: double x = x + x and you were to rewrite it to be: double addend = addend + addend Unison would say "this is the same function, no update needed" as it produces the same AST
  - rlmark 3y ago
    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 the function name as metadata and the actual implementation as the identity of the function.

ch0ic3 3y ago

Exciting! I was wondering when this would be released given the website said (until a few days ago it seems) it would be ready in Dec 2023

borland 3y ago

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.

parentheses 3y ago
++ 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 3y ago
  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 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/ https://eugenkiss.github.io/7guis/ or https://todomvc.com/ 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?

sroussey 3y ago

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

zephraph 3y ago
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).
- sroussey 3y ago
  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!

dang 3y ago

Related. Others? Unison Language - https://news.ycombinator.com/item?id=37500406 https://news.ycombinator.com/item?id=37500406 - Sept 2023 (1 comment) Unison Language and Platform Roadmap - https://news.ycombinator.com/item?id=36333409 https://news.ycombinator.com/item?id=36333409 - June 2023 (23 comments) A look at Unison: a revolutionary programming language - https://news.ycombinator.com/item?id=34307552 https://news.ycombinator.com/item?id=34307552 - Jan 2023 (84 comments) The Unison language – a new approach to Distributed programming - https://news.ycombinator.com/item?id=33638045 https://news.ycombinator.com/item?id=33638045 - Nov 2022 (113 comments) Unison Programming Language - https://news.ycombinator.com/item?id=27652677 https://news.ycombinator.com/item?id=27652677 - June 2021 (131 comments) Unison: A Content-Addressable Programming Language - https://news.ycombinator.com/item?id=22156370 https://news.ycombinator.com/item?id=22156370 - Jan 2020 (12 comments) The Unison language - https://news.ycombinator.com/item?id=22009912 https://news.ycombinator.com/item?id=22009912 - Jan 2020 (141 comments) Unison – A statically-typed purely functional language - https://news.ycombinator.com/item?id=20807997 https://news.ycombinator.com/item?id=20807997 - Aug 2019 (25 comments) Unison: a next-generation programming platform - https://news.ycombinator.com/item?id=9512955 https://news.ycombinator.com/item?id=9512955 - May 2015 (128 comments)

ThinkBeat 3y ago

This looks to me like some real innovation. I am looking forward to digging into this. Combining a custom language with a custom cloud, seems to be something they have leveraged to make some great strides.

alfanick 3y ago
Yup great for business, horrible for users - just get lock in and keep paying. But great business idea.

jakjak123 3y ago

Tbh this is not the worst idea I've seen. I hope you can make it, because I would have a hard time justifying such an experimental platform and idea as a foundation for a company.

niffydroid 3y ago

I was thinking the UK Union unison when I saw the title

paint 3y ago

[dead]

roboben 3y ago

Seems like half the unison team is here in this thread. Congrats, looking forward to try it out!

rsync 3y ago

Unison friends: Is there an rclone handler/recipe extant, or in the works, that would facilitate inter-cloud data transfer ? Asking for a friend ...

rlmark 3y ago
There is not, at present, an rclone library, but this would be a welcome addition to our open source cloud libraries. Perhaps your friend would like to write such a utility! :-)

ahmedfromtunis 3y ago

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, req): name = req.GET.get("name") return f"<p>hello {name}!</p>" def deploy(self): from PyCloud import cloud project = cloud.create_project(self) project.deploy() # main.py from .app import App app = App() url = app.deploy()

benpacker 3y ago
Yep, that’s right. Modal (https://modal.com 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
- ahmedfromtunis 3y ago
  I never heard of them before, but they offer is amazing -- even though I don't think I'll be using anytime soon.

davedx 3y ago

It's crazy but it just might work! Even if I never use this, it's incredibly refreshing to see a genuinely new approach to delivering applications. Some of this feels subtly like Smalltalk. Some very interesting ideas here: https://www.unison.cloud/our-approach/ https://www.unison.cloud/our-approach/

jadbox 3y ago
I feel the same. My initial reaction is that I like the vision, but I feel there is probably a compromise to build these mechanics into a library for many languages, rather than requiring the DC burden of picking up a new 'better cloud' centric language. Perhaps I just haven't developed an appreciation for language capabilities yet.

ildjarn 3y ago

Has anyone used Unison instead of Spark? Seems like a natural fit to me.

rlmark 3y ago
We wrote an article speaking to this use case here: https://www.unison-lang.org/articles/distributed-datasets/ https://www.unison-lang.org/articles/distributed-datasets/ It's a bit of a deep dive into some of the building blocks of the Remote ecosystem - so it talks quite a bit about how you'd implement something like Spark itself in Unison, but you can see how running data aggregations would work on the Cloud.
stewoconnor 3y ago
We recently did a series of blog posts exploring how our remote programming model makes us a good fit for writing distributed map - reduce like programs. https://www.unison-lang.org/articles/distributed-datasets/ https://www.unison-lang.org/articles/distributed-datasets/ One of the real strengths of individual parts of your program being content addressed, and our ability system that lets us track side effects, we can have a programming model where you only need to talk abstractly about where your data is, and how you'd like to operate on it, and then we have the ability to have our cluster gossip about parts of your program that need to be shipped to where parts of your data is. One node can ask another node "please apply this function to the data you have" and the other node can gossip to get any missing definitions it needs for that function. You never have to talk about serialization or network connections or software distribution, we know how to move data for you, move code for you, and in some cases even cash partial program results.

winkelwagen 3y ago

I tried it a couple of times, but the showstopper for me was the hosting model was the show stopper. I think the premise of the language and platform has so many amazing aspects that are very exciting to me. But it also i had a hard time imagining pitching this together with unison cloud to my team. All the components together at this moment in time. A very big investment into an ecosystem. Hope some smart developers would take the learning and try to integrate it with existing languages like clojure. Still going to follow what unison is doing because it is so exciting

steve_adams_86 3y ago

Apologies if this is a dumb question, and maybe it applies to other services I may already use, but: What if Unison language and the Cloud have a vulnerability. Would you suddenly have a large network of services that could be readily exploited? This sort of "infrastructure monoculture" situation gives me the heebie-jeebies, but I'm admittedly pretty dumb when it comes to security. I imagine that with my Google Cloud Run instance running who-knows-what language on maybe some framework, the opportunities to zero in on an exploit are fewer than when an attacker can know exactly what's running, what it's running on, and perhaps even have the ability to enumerate to find instances off of pro plans since they may often use auto-generated names from hyphen-separated common words. If the sandboxing of instances is poor, it seems like it could be a huge problem. Again, I have no idea what I'm talking about. Mostly curious to learn more, not criticize.

pradn 3y ago
This problem exists with all shared code. Shared code, shared fate. You hope that with more eyes on a library, it'll be more secure. It may also mean vulnerabilities have a higher blast radius. You have to choose where you want to lie on the balance. Spectre and Log4J - problems on widely deployed tech (Intel CPUs, Java services).
- steve_adams_86 3y ago
  Very good point at the end; the lower level you go, the broader (and likely more severe) your vulnerabilities will be. I suppose in this case my concerns aren't warranted, or at least not worth placing before more immediate and obvious concerns. i.e., I could write shitty code a lot more easily than Unison could compromise their language and infrastructure.

59nadir 3y ago

This is about the Unison language but I think it's relevant. I was checking out the FAQ for Unison and noticed this: https://www.unison-lang.org/docs/usage-topics/general-faqs/#does-unison-have-an-ffi https://www.unison-lang.org/docs/usage-topics/general-faqs/#... > Unison does not currently support a Foreign Function Interface, for invoking code written in other languages. > Your programs can interact with the outside world via the `IO` ability, and this includes interaction via network sockets - so you can interact with code written in other languages if that code can expose a network interface, for example as a web service. We'd like to improve on this position in the future. So far so good, I guess. They're trying to do something that makes sense in the future. They then go on to outline how they're apparently going to expose specific parts of what you might want to use, like `GPU` as an ability/effect...? What do I do when I just want to execute some of my C code and don't want to jump through hoops to do so? I get that this maybe falls apart entirely because of the idea of content-addressable functions, but can't an FFI binding be the hash of its name and inputs and output or something? Maybe I'm misunderstanding their plan with regards to FFI solutions. In the end I'd like to just have something like this with both static and dynamic libraries: ModuleName = foreign import c [libmodule.a, otherlib.so] ModuleName.OpaqueCoolType a = OpaqueCoolType a ModuleName.has : a -> OpaqueCoolType a -> Bool

pchiusano 3y ago
Hi, one of the Unison creators here. We've held off working on FFI until the JIT compiler[1] is completed since FFI is closely connected to the runtime. There's some interesting subtleties with FFI in a distributed programming language, so I'll ramble about that here in case it's interesting to you. :) So, in Unison, all values are serializable, including functions and their dependencies. This is a key superpower that enables a lot of the neat stuff we do. As long as those functions are written in pure Unison, we can easily serialize them, deploy them on the fly, etc. But when we add an FFI, the story changes - the sender may have some C library in their environment, and that library may not exist at the recipient node. The two nodes could be different platforms, one Mac, one Linux, and the library may have been written specifically for Linux, say! So when we add FFI, we will likely be doing it in a different way than most languages. Functions that use FFI will have this tracked in the their type, using our effect system. You'll be able to use whatever C libraries you want in your local computations, but if you want to sent those values around, you need to be sending them to a place that supports that same set of FFI effects, since the C library and its dependencies can't literally be deployed on the fly in the same way as pure Unison code. In our cloud platform, nodes are typed based on what effects they support and we'll probably add a way to create new node pools that have access to whatever C libraries you want. In "regular" programming, we're not used to thinking about "the execution environment" as a thing that's represented explicitly within the program. Instead, there's an assumed execution environment (which includes the set of native libraries, etc) and you get runtime errors if you run a program and some of the assumed execution environment is missing (like a shared library, say). For the most part, people have been okay with this, but it's already somewhat of a problem for languages that target the browser and the backend. The language may be statically typed, but now the type system is not tracking some key information - namely, is this a function I can call here (if I'm expecting this code to compile to JS) or is it a function that only can be called for backend code? In a distributed setting with heterogeneous nodes with different capabilities, this problem is even more pronounced, which is why we track this information in the types and plan to do so once we add FFI. Hope that was interesting! [1]: https://www.unison-lang.org/blog/jit-announce/ https://www.unison-lang.org/blog/jit-announce/ is an early progress report, and I think we're finally shipping something in the next month!

ildjarn 3y ago

Can Unison code be stored in a Git repo as text?

rlmark 3y ago
We used to support git backed codebase hosting a while ago, before we launched our own remote hosting platform https://share.unison-lang.org/ 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.
- ildjarn 3y ago
  It might be tough for Unison to be an island outside of GitHub, although I see the benefits.
  - rlmark 3y ago
    Totally fair, there are definitely tradeoffs.

neom 3y ago

"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-profit corporation intended to produce a public benefit and operate in a responsible and sustainable manner. A PBC must be managed in a way that balances the interests of the stockholders, the company’s key stakeholders, and a specific public benefit that the company commits to in its charter." https://www.cooleygo.com/faq-delaware-public-benefit-corporations/ https://www.cooleygo.com/faq-delaware-public-benefit-corpora...

refried_ 3y ago
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.
- neom 3y ago
  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. =)

hedora 3y ago

I was hoping this was like rsync.net, but for unison: https://github.com/bcpierce00/unison https://github.com/bcpierce00/unison Trademarks are hard.

prima-facie 3y ago

Ah I thought this was related to the trusty old Unison two-way file synchronisation tool and my heart skipped a beat. https://github.com/bcpierce00/unison/ https://github.com/bcpierce00/unison/

9dev 3y ago

Forgive 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 infrastructure layer, that makes total sense to me. But then, you’re just shifting complexity from the developer to your cloud service, and hide it behind a proprietary platform (which I don’t mind, all the best for your business!). And I don’t really understand how that will make things better, all things considered. Could someone explain this to me?

benpacker 3y ago
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.
ultra_nick 3y ago
Unison is a distributed programming language. YAML config files and Hadoop/Kafka/Kubernetes/etc are additions for non-distributed programming languages. Unison is a grand simplification of everything into one system so that future programmers don't have to put up with our crap.
rlmark 3y ago
Hi there! There's definitely an overhead to learning a new language but by describing your cloud infrastructure with an actual programming languages you reap the benefits of type-safety, testability, and code reuse, etc. You're spot on with shifting the complexity to the cloud layer; our thought was that it would free up time for dev teams to focus on other layers of their application. Maybe I'm misinterpreting your question though, I'm happy to annotate that code snippet with a walk-through.

Havoc 3y ago

What is the main advantage of this over the classic big cloud function offerings? Sounds like developer experience possibly?

rlmark 3y ago
The developer experience would be one of the main advantages. Unison cloud was custom built to run Unison's language without extra steps like building packages, syncing dependencies across nodes, etc. Also, interactions with other cloud platforms typically aren't described in a programming language which is shared between the infrastructure management layer and the application layer. The draw-back is that the Cloud runs the Unison programming language specifically.

k8svet 3y ago

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.

badelectron 3y ago
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 identified by their hashes, so there's no (realistic) way that names can collide. Otherwise, Unison and Nix feel pretty different to me. Nix is generally a build-time language for arbitrary runtimes, while Unison is a general purpose language for a specific runtime. Nix takes on the really ambitious goal of wrangling ancient projects built with Makefiles and ambient environments into deterministic builds. Through the heroic effort of derivation authors, they've managed to make it work. But it requires those maintainers to do lots of careful manual tracking of dependencies, pre-build source patches, overriding build steps, etc. Unison takes a much more constrained approach: if we start with a language that is content-addressed at its core and keep running with this idea, where do we end up? One nice outcome of this is that you never need to manually track dependency versions, hashes, etc; the language does that for you. The "tough" part is also there, but feels different. To me the Nix expression language is straightforward, but I find it difficult to wrap my head around nontrivial derivations. To answer questions like "what attributes and build steps can/should I override" I feel like I have to dig through the layers of the implementation. In Unison a powerful static type system and UIs (both local and Unison Share) that support clicking through to any term/type make it easier for me to digest code. The "tough" parts of Unison generally stem from the young ecosystem: fewer existing libraries, a codebase manager that is under active development and not nearly as stable as git, etc. If nothing else Unison is worth a try just because it is so different than most other languages/ecosystems. PS if you are interested in usin Nix to install the Unison codebase manager or to package a program written in Unison these repos might be useful (disclaimer I'm ceedubs): https://github.com/ceedubs/unison-nix/ https://github.com/ceedubs/unison-nix/ https://github.com/ceedubs/unison-nix-snake/ https://github.com/ceedubs/unison-nix-snake/

flying_sheep 3y ago

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

pests 3y ago
Many of those are already handled.
zawodnaya 3y ago
Or like a whole language to handle them

ilikebits 3y ago

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

rlmark 3y ago
Nice, a structural editor throwback reference! :-) I'll speak to point 1! We aim to add FFI as a fast follow on to the native compilation work that is underway. The work on the JIT compiler opens the door to FFI so that's on the roadmap soon.

sixbrx 3y ago

Unison looks like a neat functional language. Do abilities subsume the role of type classes also (without any "effects")? If so, would there be a loss of efficiency for using pure abilities in this way (since a "handler" needs to interpret the ops)? Sorry I've only had a brief look so I'm not sure this makes sense. Edit: Shorter: do you have type classes

Quekid5 3y ago
Abilities are typed effects, effectively. At least, that's how I understand it. (In a less jokey way: Abilities should be thought of as capabilities, and capabilities are what enable you to do I/O, read from a DB, etc. So they are 'effects' in the Pure FP sense.) Not sure about the type classes thing.
badelectron 3y ago
Short version: no type classes (yet) Longer version: Building upon what Quekid5 mentioned, Unison abilities are an implementation of what is referred to as algebraic effects in programming language literature. They represent capabilities like IO, state, exceptions, etc. They aren't really a replacement for type classes, though in some cases you can shoehorn abilities in where you might otherwise use a type class. For someone coming from a Haskell background, I think that abilities are closer to a replacement for monad transformers. But in my opinion they are much more ergonomic. Discusson of type classes comes up a lot. Here is a long-standing GitHub issue: https://github.com/unisonweb/unison/issues/502 https://github.com/unisonweb/unison/issues/502 For what it's worth, I've written Unison quite a lot over the past few years and while I've missed type classes at times, I think that reading unfamiliar code is easier without them. There's no implicit magic; you can see exactly what is being passed into a function. So far I've been happy with a bit more verbosity for the sake of readability.
zawodnaya 3y ago
Unison doesn't have type classes yet, no

bushwald 3y ago

I'm excited about Unison as a language so I'm glad to see something that will hopefully give it some additional forward momentum

udev4096 3y ago

Looks like just another serverless offering

max_hoffmann 3y ago

I’ve been waiting for this since the first talk about Unison. Love the huge progress you have made and congrats to the public release of Unison Cloud! Question: Is it possible to set the region of the database/storage? Or is there any timeframe when this can be configured? For GDPR reasons I cannot use hosting that doesn’t support storage in the EU.

HenriTEL 3y ago

That's very refreshing and there must be a lot of work behind the scene to properly update services and their dependencies without outages. I'm also curious about how database migrations are dealt with. I'll keep following that space as they have well identified the problem and its root causes. The CNCF is happy of their "ever-growing global community", reaching 173 projects and over 220,000 contributors. Good for them.

nickstinemates 3y ago

winglang is a lot more interesting.

devaiops9001 3y ago

I strongly dislike marketing material that tries to normalize gross incompetency around complexity problems that don't actually exist.

ParetoOptimal 3y ago
If you gave examples of what you meant, others might be able to understand and discuss what you mean.
- devaiops9001 3y ago
  I have been involved in so many projects where AWS, Google Cloud, OpenStack, or Kubernetes (on metal) was used. I'd have to think a bit hard on how to articulate this well, but I see the page linked on this HN thread and it just screams "utter horse shit" to me. Someone who finds AWS so hard to use is either not reading documentation or not comprehending it and probably shouldn't be coding in the first place.

alfanick 3y ago

Is this 21st century COBOL? Some language with some open-spec, made actually to be running in some very closed environment via interactive environment, with no source control?