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.
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.
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.
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.
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...
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.
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.
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....
Whatever gobbledygook you’re writing to specify how your system works, a programming language is better than a markup file.
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?