5 ms·

I feel like trying to use a "dumb" declarative config language for everything is part of the problem. The domain is not simple enough for that, so you end up w

I feel like trying to use a "dumb" declarative config language for everything is part of the problem. The domain is not simple enough for that, so you end up with all kinds of weird scripts around it all, or other templating/codegen solutions, plus all kinds of ad-hoc conventions that are extremely easy to break and very annoying to navigate. Having a full blown statically typed language like TypeScript - where things can reference each other strongly (not just by names and other strings), naming conventions can be encoded in functions (or even enforced by types), and structures on every level (even your project-specific ones) have a well-defined and checked schema - would help a lot in my opinion. Maybe deno could find a use in this niche.

scrollaway 6y ago
You're (accidentally, I think?) describing Pulumi in striking detail. https://www.pulumi.com/ https://www.pulumi.com/
- realharo 6y ago
  Kind of. From a brief look, it looks very framework-y and all-or-nothing (though I could be wrong, they do have a page about gradual adoption at least https://www.pulumi.com/docs/guides/adopting/ https://www.pulumi.com/docs/guides/adopting/). I was picturing something more low level and less opinionated, though I can only guess how such a thing would perform in practice. Not even necessarily a specific product, just the adoption of workflows that use already existing tools (e.g. the various API client libraries - for AWS, Kubernetes, git, docker registry, etc.) to achieve this. I realize that that could lead to reinventing the wheel, and eventually an in-house framework anyway, but it feels a lot more comfortable to start there, as you can design things closer to your exact needs. Pulumi definitely looks interesting though.
codebeaker 6y ago
It sounds like you're describing HashiCorp's HCL2 and Terraform Configs which are at least a graph. I find using AWS without Terraform to be nearly impossible.
- happymellon 6y ago
  Terraform, or Troposphere, or cfn-modules/Widdix, or CDK. Cloudformation as a JSON/YAML vanilla config is just awful, and really exposes the inconsistancies between the different services.
arvinsim 6y ago
Yep. I prefer to use language files over JSON or YAML files if I can.
akhilcacharya 6y ago
...like CDK? https://docs.aws.amazon.com/cdk/latest/guide/home.html https://docs.aws.amazon.com/cdk/latest/guide/home.html
moltar 6y ago
Have you seen aws-cdk or pulumi? Does exactly that with TypeScript to boot :)
londt8 6y ago
Scripts which generate the config also have their own problems. Check out Dhall, it attempts to solve this.
- realharo 6y ago
  Reminds me a bit of jsonnet (https://jsonnet.org/ https://jsonnet.org/) which didn't catch on much as far as I can tell. I see very little practical value in a DSL like this. Using an existing language with an extensive ecosystem and great tooling was half the point of wanting TypeScript in the first place. Most of the "risks" can be handled with just a few eslint rules, tests (e.g. all outputs must satisfy a set of constraints), and code review. Especially when the moment you need to do more than just generate config files (e.g. fetch some information from an external service, or even write an imperative script for the occasional task), you'd have to switch to a different langauge and all its tooling - where you can't just import the exact same type definitions, etc.
huijzer 6y ago
This also sounds like the Nix language (https://nixos.org/ https://nixos.org/).

scrollaway 6y ago

You're (accidentally, I think?) describing Pulumi in striking detail. https://www.pulumi.com/ https://www.pulumi.com/

realharo 6y ago
Kind of. From a brief look, it looks very framework-y and all-or-nothing (though I could be wrong, they do have a page about gradual adoption at least https://www.pulumi.com/docs/guides/adopting/ https://www.pulumi.com/docs/guides/adopting/). I was picturing something more low level and less opinionated, though I can only guess how such a thing would perform in practice. Not even necessarily a specific product, just the adoption of workflows that use already existing tools (e.g. the various API client libraries - for AWS, Kubernetes, git, docker registry, etc.) to achieve this. I realize that that could lead to reinventing the wheel, and eventually an in-house framework anyway, but it feels a lot more comfortable to start there, as you can design things closer to your exact needs. Pulumi definitely looks interesting though.

codebeaker 6y ago

It sounds like you're describing HashiCorp's HCL2 and Terraform Configs which are at least a graph. I find using AWS without Terraform to be nearly impossible.

happymellon 6y ago
Terraform, or Troposphere, or cfn-modules/Widdix, or CDK. Cloudformation as a JSON/YAML vanilla config is just awful, and really exposes the inconsistancies between the different services.

arvinsim 6y ago

Yep. I prefer to use language files over JSON or YAML files if I can.

akhilcacharya 6y ago

...like CDK? https://docs.aws.amazon.com/cdk/latest/guide/home.html https://docs.aws.amazon.com/cdk/latest/guide/home.html

moltar 6y ago

Have you seen aws-cdk or pulumi? Does exactly that with TypeScript to boot :)

londt8 6y ago

Scripts which generate the config also have their own problems. Check out Dhall, it attempts to solve this.

realharo 6y ago
Reminds me a bit of jsonnet (https://jsonnet.org/ https://jsonnet.org/) which didn't catch on much as far as I can tell. I see very little practical value in a DSL like this. Using an existing language with an extensive ecosystem and great tooling was half the point of wanting TypeScript in the first place. Most of the "risks" can be handled with just a few eslint rules, tests (e.g. all outputs must satisfy a set of constraints), and code review. Especially when the moment you need to do more than just generate config files (e.g. fetch some information from an external service, or even write an imperative script for the occasional task), you'd have to switch to a different langauge and all its tooling - where you can't just import the exact same type definitions, etc.

huijzer 6y ago

This also sounds like the Nix language (https://nixos.org/ https://nixos.org/).