[rlmark]

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.

[9dev]

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.

[fwip]

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

[mike_d]

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

[tikhonj]

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

[ParetoOptimal]

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

[fwip]

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.