Hacker News Reader

Comment by 9dev | Hacker News Reader

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?

View on HN

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.

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.

I guess what I'm wondering about is whether that really reduces overall complexity, or just externalises it. Despite all the pitfalls, the current "Cloud" ecosystem is comprised mainly of interoperable Open Source software. If we replace that stack with a proprietary blackbox… does that actually help the ecosystem as a whole? Or will we see similar offerings in other programming languages, until we're back to square one (in that you'll have to learn the ins and outs of every language's "cloud service")?

That's probably a bit too philosophical and nothing a company should have to worry about. Again, I think you're doing great work here, I'm just unsure whether this is the best solution for the overarching problem.

Unison user here - you might be right about having to learn the provider's ins and outs, the same way that if you're on AWS, you need to learn AWS lingo.

But with Unison Cloud, most of the complicated API is written as a library in Unison itself[0]. This `cloud` library is technically optional (and editable), and you can build and share your own abstractions as you like, so you don't have that hard rough edge between AWS APIs and your own code.

[0]: https://share.unison-lang.org/@unison/cloud/code/releases/9....

> you reap the benefits of type-safety, testability, and code reuse, etc.

If you treat infrastructure as a problem that has to be solved by code, obviously you'll run into code specific issues like type safety. In the real world I've never root caused a production issue back to that.

You've never run into issues where unclear, undocumented, misunderstood or inconsistent interfaces were a significant contributing factor?

> like type safety. In the real world I've never root caused a production issue back to that.

Your definition of type safety might not include validation + using the type to carry proof of that validation throughout the life of the program.

For examples see:

https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

Type safety isn't a code-specific issue, it's a feature.

A YAML configuration file missing a required key, or a misspelling, or a disallowed mixing of parameters, are all things that can be solved by type-safety, rather than getting a deploy-time or run-time error.

Quick answer: In YAML I can’t define a reusable function, and sometimes I wish I could, for example.

Whatever gobbledygook you’re writing to specify how your system works, a programming language is better than a markup file.

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.

Reply on news.ycombinator.com