[HN Gopher] Unison Cloud
___________________________________________________________________
Unison Cloud
Author : dcre
Score : 182 points
Date : 2024-02-07 16:59 UTC (6 hours ago)
(HTM) web link (www.unison.cloud)
(TXT) w3m dump (www.unison.cloud)
| beefman wrote:
| "Unison Cloud is now generally available"
|
| https://twitter.com/unisonweb/status/1755266140924784738
| adverbly wrote:
| 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
| (Worth a watch - Runar is awesome)
| surprisetalk wrote:
| 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 wrote:
| 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-
| 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 wrote:
| 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
|
| I'm excited to see how it progresses beyond "first large-
| scale demo"!
| RadiozRadioz wrote:
| In a weird way, it's what JDSL wanted to be
| https://thedailywtf.com/articles/the-inner-json-effect
| pdimitar wrote:
| I need a full liter of unsee juice to recover after reading
| this.
| azeirah wrote:
| Joe Armstrong can finally be happy :D
| losvedir wrote:
| 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/05876...
| ParetoOptimal wrote:
| 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 wrote:
| > My gut tells me Cloudflare workers are some type of low-
| code solution.
|
| Cloudflare Workers hosts servers written in JavaScript /
| Wasm.
| posix86 wrote:
| 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 wrote:
| Is Unison something I can easily self host? I wouldn't want to be
| vendor locked to Unison Cloud.
| ok_dad wrote:
| 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 wrote:
| The language is free to use.
| kemiller wrote:
| You can self host, yes, though you'll probably be inventing a
| lot of wheels.
| pchiusano wrote:
| Hi, one of the Unison creators here. The Unison language is
| open source (MIT licensed) and there's an open source library
| ecosystem (see https://share.unison-lang.org/) like most
| languages. If you just want to run some Unison code on a VM
| then that's free and works like any other language. You can do
| this today (we do this ourselves for the implementation of
| Unison Cloud!). There's also a local single machine interpreter
| of the cloud API for easy local testing.
|
| The "real" cloud platform providing the fancy distributed
| compute and storage fabric, deployment with a function call,
| etc, isn't open source - selling this product in various forms
| is how we are sustainable as a business.
|
| If you're at a company and want to deploy "Unison Cloud in a
| box" on your own infra or in your own VPC then that's something
| that's doable and I'd love to talk more - feel free to email
| hello@unison.cloud.
|
| If you're just an individual wanting to do cloud stuff at small
| scale on your own infra, that's probably harder for us to
| support right now. I'd recommend just using the free tier or
| starter tier of our public cloud. Even if we had some sort of
| free self-hosting option for cloud, there's economies of scale
| you'd miss out on so it could easily be more expensive anyway!
|
| Not to mention, time is valuable https://www.unison-
| lang.org/blog/developer-productivity-real... We've built a
| nicely managed public cloud that eliminates huge swaths of
| tedious work. If you're happy to pay for that, then it's a good
| fit. If you prefer to self-host all the things, even for
| personal-use scale, then I totally understand that but Unison
| Cloud probably isn't the best fit right now.
|
| Hope that helps!
| satvikpendem wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
|
| ... 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. :)
| rywalker wrote:
| Similar to https://www.ubicloud.com/ ?
| dcre wrote:
| ...no
| dmd wrote:
| In that they both start with 'u', yes.
| mhitza wrote:
| I wonder if Unison Cloud is built with the Unison language, that
| would prove language maturity in my eyes.
| pchiusano wrote:
| 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. :)
| LeoPanthera wrote:
| 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
| Szpadel wrote:
| 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
| haolez wrote:
| 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 wrote:
| 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 wrote:
| 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/
|
| (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 wrote:
| 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/
| suralind wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| svieira wrote:
| Is the term _merely_ the hash of its contents, or does it
| also include the module space? If it 's just the hash of
| its contents, how do you deal with functions which have
| the same implementation now but shouldn't always - e. g.:
| serviceA.requiredHeaders key = Dictionary.of "X-API-KEY"
| key serviceB.apiKeyHeader apiKey =
| Dictionary.of "X-API-KEY" apiKey
|
| If they hash to the same thing and I update
| `serviceA.requiredHeaders` (because the vendor changed
| from `X-API-KEY` to `X-VENDOR-API-KEY`) do I have to know
| that these are two different services in order to review
| the change and untangle these two methods or is there a
| way to mark these as "structurally equivalent but
| semantically distinct"?
| svieira wrote:
| You update all the callers of B that you can see from your
| codebase. If `B` is a library then you publish an out-of-band
| notice that `B` is deprecated and they should switch to `B'`.
| It's the most extreme form of static linking you can think of
| (which is really nice for stability, not nice for speed-to-
| deploy-a-change).
| rlmark wrote:
| That's a great question! (I work for Unison, full disclosure.)
|
| The process for upgrading Unison code is that if you have a
| function A that calls B, and you update B in some way, as long
| as the change is type-preserving it will automatically be
| propagated to all the sites in your project where B is called.
| If the change is not type-preserving (for example, if you added
| a parameter) the tooling itself will direct you to resolve all
| the places where B is applied. So as you change code locally,
| you're continually keeping your codebase in sync; A will always
| be calling the updated function.
|
| Here's an example from our docs: https://www.unison-
| lang.org/docs/usage-topics/workflow-how-t...
| ch0ic3 wrote:
| 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 wrote:
| 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 wrote:
| ++
|
| 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 wrote:
| _The odd thing is unison started purely as a language. Now
| there 's a platform._
|
| I often find the best way to understand complex things is to
| dig all the way back to when they were being thought up. In
| this case there's a blog post from 2017 that I still find
| useful when thinking about Unison:
|
| https://pchiusano.github.io/2017-01-20/why-not-haskell.html
|
| Key quote:
|
| _Composability is destroyed at program boundaries, therefore
| extend these boundaries outward, until all the computational
| resources of civilization are joined in a single planetary-
| scale computer_
|
| (With the open sourcing of the language I doubt it will be
| one computer anymore, but it's an interesting window into the
| original idea)
|
| Personally I find there's a lot to this. It's interesting
| that we're really, really good at composing code within a
| program. I can map, filter, loop and do whatever I want to
| nested data structures with complete type safety to my
| heart's content. My editor's autocompleting, docs are showing
| up on hover, it's easy to test, all's well.
|
| But as soon as I want cron involved, and maybe a little
| state-- this is all wrecked. Also deployment gets more
| annoying as they talk about a lot.
|
| So I think Unison always had to have a platform to support
| bringing this stuff into the language, even though they built
| the language first.
|
| _I 'd love to hear some opinions from outside Unison about
| how they like using this language, tooling and hosting._
|
| I'd like to hear this too.
|
| Also, it would be great if there was something like
| https://eugenkiss.github.io/7guis/ or https://todomvc.com/
| for platforms that we could use to compare Unison, AWS, etc
| etc. Or is there already a 7GUIs for platforms that I don't
| know about?
| zawodnaya wrote:
| There is source control on https://share.unison-lang.org/
| pchiusano wrote:
| It definitely is ambitious! A multi-year effort.
|
| This post https://www.unison.cloud/our-approach/ talks more
| about why such radical changes were necessary to achieve what
| we wanted. (In particular check out the "3 requirements of the
| dream" section, which walks through what the programming
| language needs to support to be able to do things like "deploy
| with a function call.")
|
| My general take on "when and where to innovate" is: if you can
| get a 10x or more improvement in some important dimension by
| doing things differently, it can absolutely be worth it. This
| is the philosophy we've applied in developing Unison over the
| years. I am generally happy to learn something new if I know
| that I'll be getting something substantial out of it. Of course
| it can be hard to tell from the outside if the benefits really
| are worth the changes. I'm not sure what to say about that,
| other than try it out with something low risk and decide for
| yourself.
|
| Besides the distributed programming / cloud stuff, I'll give a
| couple other examples where we gain advantages by doing things
| differently: by storing Unison code in a database, keyed by the
| hash of that code, we gain a perfect incremental compilation
| cache which is shared among all developers of a project. This
| is an absolutely WILD feature, but it's fantastic and hard to
| go back once you've experienced it. I am basically never
| waiting around for my code to compile - once code has been
| parsed and typechecked once, by anyone, it's not touched again
| until it's changed. This has saved me countless hours compared
| to other static languages. And I don't have to give up static
| typing to get this.
|
| This sort of content-addressed caching also plays out for
| testing - for pure tests (which are deterministic), Unison has
| a test result cache keyed by the hash of the test code. This
| also saves countless hours - imagine never needing to rerun the
| same tests over and over when nothing's changed! (And having
| certainty that the cache invalidation is perfect so you don't
| need to do a "clean build just to be sure")
|
| Also replied here re: self-hosting
| https://news.ycombinator.com/item?id=39293568
| dmix wrote:
| So as an end user it's kind of like a more cohesive version
| of https://deno.com/ for infra, where you buy into a runtime
| + comes prepacked with DBs (k/v stores), scheduling, and
| deploy stuff?
|
| > by storing Unison code in a database, keyed by the hash of
| that code, we gain a perfect incremental compilation cache
| which is shared among all developers of a project. This is an
| absolutely WILD feature, but it's fantastic and hard to go
| back once you've experienced it. I am basically never waiting
| around for my code to compile - once code has been parsed and
| typechecked once, by anyone, it's not touched again until
| it's changed.
|
| Interesting. Whats it like upgrading and managing
| dependencies in that code? I'd assume it gets more complex
| when it's not just the Unison system but 3rd party plugins
| (stuff interacting with the OS or other libs).
| pchiusano wrote:
| Yes, I think Deno's a decent analogue for what we're doing,
| though the Unison language provides some additional
| superpowers that we find essential. The
| https://www.unison.cloud/our-approach/ post has more
| details on why the language "needs" to change to get
| certain benefits. (This is not a knock against Deno, btw, I
| think it's an awesome project!)
|
| > Interesting. Whats it like upgrading and managing
| dependencies in that code? I'd assume it gets more complex
| when it's not just the Unison system but 3rd party plugins
| (stuff interacting with the OS or other libs).
|
| In Unison, there's an all-in-one tool we call the Unison
| Codebase Manager (UCM) which can typecheck and run your
| code and talk to the code database (we use SQLite for
| this). The workflow is that you have your text editor / VS
| code open, and UCM in another terminal, watching for
| changes.
|
| So if you want to edit a definition, say, here's the
| workflow -
|
| 1. `edit blah` brings code into a scratch file, pretty-
| printed. You make your changes and get that compiling.
|
| 2. You type `update` in UCM, and it tries to propagate this
| change throughout your project. If it can, you're done. If
| it can't (say because you've changed a type signature), UCM
| puts the minimum set of definitions in your scratch file.
| You get this compiling, then do `update` again and you're
| done. It's quite nice! The scratch files are very ephemeral
| and not the source of truth.
|
| For library dependency upgrades the process is similar: you
| fetch the new version, then use `upgrade` to say "I want my
| project to exclusively use the new version". If
| everything's compatible, you're done. If there's
| incompatible changes, UCM creates a scratch file with the
| minimum set of things to get compiling.
|
| One interesting benefit is you can have multiple versions
| of the same library in use in your project. Unison doesn't
| care if you do this (though it can get confusing so people
| tend to consolidate). But there are cases where we've made
| good use of the ability to reference multiple
| "incompatible" library versions within a project.
| bloppe wrote:
| Not trying to pour cold water, but the "3 requirements" post
| seems to address straw man problems. There are existing
| solutions to each problem.
|
| 1. "Deployment should be like calling a function" isn't that
| the mantra of serverless? e.g. GCP Cloud Run or AWS Lambda?
| This is also becoming much more streamlined with server-side
| WASM e.g. wasmCloud.
|
| 2. "Calling services should be easy" this is what protobuf is
| for; cross-language client libraries that handle transport,
| de-/serialization, native typing, etc.
|
| 3. "typed storage" isn't this basically an ORM? I suppose
| it's more general since it doesn't have to be relational, but
| ORM ideas could just as easily be adapted to JSON blob stores
| using something like protobuf.
|
| Also, storing Unison code in a database, keyed by the hash of
| that code, sounds a lot like using Bazel with a shared remote
| cache.
|
| I'm not saying Unison isn't cool, but to win me over I'd need
| you to compare Unison to all these existing technologies and
| really spell out what differentiates Unison and what makes it
| better.
| paxys wrote:
| The point of the effort is the new language. Hosting and the
| rest are added on top of it. So yes, if you just want to host
| some code you shouldn't be rewriting all of it in Unison. But
| if you are already a user of the language then this is a good
| framework for you.
| jweir wrote:
| It is very experimental as well. An interesting language, but
| say good by to tried and true tooling since the code exists as
| records in database, not files.
|
| This could lead some huge advantages, and new obstacles.
|
| I played with the language for about a week and found it
| intriguing. And it seems to approach tackling Joe Armstrong's
| question "Why do we need modules at all?" ->
| https://erlang.org/pipermail/erlang-questions/2011-May/05876...
| __MatrixMan__ wrote:
| Is a language built around a pretty exciting idea. I'd drop
| quite a lot to go work in Unison, if only to see what the world
| looks like through that lens.
|
| Tinkering on the weekends just isn't the same.
| sroussey wrote:
| Pretty cool stuff. Anyone ever make a babel plugin that would
| check for identical function definitions?
| zephraph wrote:
| 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).
| dang wrote:
| Related. Others?
|
| _Unison Language_ -
| https://news.ycombinator.com/item?id=37500406 - Sept 2023 (1
| comment)
|
| _Unison Language and Platform Roadmap_ -
| 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 - Jan 2023 (84
| comments)
|
| _The Unison language - a new approach to Distributed
| programming_ - https://news.ycombinator.com/item?id=33638045 -
| Nov 2022 (113 comments)
|
| _Unison Programming Language_ -
| https://news.ycombinator.com/item?id=27652677 - June 2021 (131
| comments)
|
| _Unison: A Content-Addressable Programming Language_ -
| https://news.ycombinator.com/item?id=22156370 - Jan 2020 (12
| comments)
|
| _The Unison language_ -
| 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 - Aug 2019 (25
| comments)
|
| _Unison: a next-generation programming platform_ -
| https://news.ycombinator.com/item?id=9512955 - May 2015 (128
| comments)
| ThinkBeat wrote:
| 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.
| jakjak123 wrote:
| 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 wrote:
| I was thinking the UK Union unison when I saw the title
| roboben wrote:
| Seems like half the unison team is here in this thread. Congrats,
| looking forward to try it out!
| rsync wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Yep, that's right. Modal (https://modal.com) is actually what
| you're describing with Python, but Modal is just the compute
| layer (Unison is going for the whole cloud), and Modal isn't
| doing anything to handle version alignment across service
| boundaries
| davedx wrote:
| 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/
| ildjarn wrote:
| Has anyone used Unison instead of Spark? Seems like a natural fit
| to me.
| rlmark wrote:
| We wrote an article speaking to this use case here:
| 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 wrote:
| 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/
|
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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).
| 59nadir wrote:
| 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/#...
|
| > 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
| ildjarn wrote:
| Can Unison code be stored in a Git repo as text?
| rlmark wrote:
| We used to support git backed codebase hosting a while ago,
| before we launched our own remote hosting platform
| https://share.unison-lang.org/ and it had several downsides.
|
| 1. Unison terms are stored as hashes so checking in a binary
| file wasn't very ergonomic and didn't really enable much in
| terms of collaboration. If we store our code as text on the
| file system, we have less information than what's tracked in
| the Unison tooling, since the plain text version isn't aware of
| its dependencies. 2. Unison's versioning system is more
| syntactically aware than Git's since its granularity is based
| on the definition of your functions and types, not incidental
| changes like whitespace or newlines.
|
| You can of course, bring all the Unison code for a program into
| a text file (you write Unison code in your regular editor) and
| then check it in, but that's not as nice of a workflow than the
| one that's supported directly.
| ildjarn wrote:
| It might be tough for Unison to be an island outside of
| GitHub, although I see the benefits.
| neom wrote:
| "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-corpora...
| refried_ wrote:
| 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.
| hedora wrote:
| I was hoping this was like rsync.net, but for unison:
|
| https://github.com/bcpierce00/unison
|
| Trademarks are hard.
| wooptoo wrote:
| 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/
| 9dev wrote:
| 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 wrote:
| 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.
| Havoc wrote:
| What is the main advantage of this over the classic big cloud
| function offerings?
|
| Sounds like developer experience possibly?
| k8svet wrote:
| 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.
| flying_sheep wrote:
| 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
| ilikebits wrote:
| 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/ 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.
___________________________________________________________________
(page generated 2024-02-07 23:00 UTC)