Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unison Cloud

unison.cloud

Post reply on HN
Print view View original

61–70 of 158 posts

Re: Unison Cloud

#61

Post by winkelwagen »

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

Re: Unison Cloud

#62

Post by steve_adams_86 »

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.

Re: Unison Cloud

#63

Post by 59nadir »

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

Re: Unison Cloud

#64

Post by posix86 »

surprisetalk wrote: post #4

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?

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.

Re: Unison Cloud

#66

Post by pradn »

steve_adams_86 wrote: post #62

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…

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

Re: Unison Cloud

#67

Post by neom »

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

Re: Unison Cloud

#69

Post by rlmark »

rsync wrote: post #53

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

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! :-)
Post reply on HN