4 ms·

Forgive me the heresy, but when I look at this example: helloWorld.deploy : '{IO, Exception} () helloWorld.deploy = Cloud.main do h = sketchy underlin

by 9dev 3y ago

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 3y ago
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.
ultra_nick 3y ago
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.
rlmark 3y ago
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.
- mike_d 3y ago
  > 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 3y ago
    You've never run into issues where unclear, undocumented, misunderstood or inconsistent interfaces were a significant contributing factor?
  - ParetoOptimal 3y ago
    > 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-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
  - fwip 3y ago
    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.
- 9dev 3y ago
  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.
refried_ 3y ago
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.

by 9dev 3y ago

benpacker 3y ago

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.

ultra_nick 3y ago

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.

rlmark 3y ago

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.

mike_d 3y ago
> 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 3y ago
  You've never run into issues where unclear, undocumented, misunderstood or inconsistent interfaces were a significant contributing factor?
- ParetoOptimal 3y ago
  > 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-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
- fwip 3y ago
  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.
9dev 3y ago
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.

refried_ 3y ago

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.