porter VS dhall-lang

This is just a concept. AFAIK only one implemented this concept is Microsoft's project porter: https://github.com/getporter/porter

For porter I am talking about this project https://porter.run/ and NOT this https://porter.sh/

Porter

As far as I know the tool is used at least in Microsoft. The classic use case is where you want to install an application and also define the infrastructure as well (i.e cluster + db + lb + app). You can see the examples here https://github.com/getporter/porter/tree/main/examples

Check https://cnab.io/ and https://porter.sh/

I'm closely tracking an effort by Microsoft that aims to do a lot of what you're describing since I find myself bridging between these tools and deploying stacks that span tools and roles. [CNAB](https://cnab.io/) and the front-running implementation, [Porter](https://porter.sh/), enable one-step infra deployments, packaged as a single OCI-compatible container, with any number of steps, using the best tools for each of those steps. Think of using aws-cli for some initialization step (create or verify presence of a state bucket), applying some terraform to create infra, and finishing with a helm chart to complete deployment of app components. Each stage in a bundle packages not only the code to run it but also the execution binary of the tool that runs it. The spec and porter are still a moving target but it's a promising space and a nice adjacent evolution of the current state of tooling.

Cool, it's great to know that it isn't abandoned.

I'm not sure why you'd say that their business model was a success. They were bought by Microsoft for Azure. I guess I wonder if a PaaS company can survive without getting the profits off renting the machines to people. Amazon, Google, and Microsoft all have PaaS options based around the idea that it comes bundled with the compute, not as a standalone open-source thing for you to use on any platform.

I guess the question is whether Porter's business plan is "make enough that a company that owns a cloud wants to buy us". Oracle could probably use a nice PaaS platform and team. Maybe DigitalOcean would like to beef up their PaaS offering by acqui-hiring a team with proven knowledge.

Poking around https://deislabs.io, it's interesting to see that they have a project called "Porter" which seems to be unrelated to the "Porter" being launched here: https://porter.sh. They aren't quite the same, but they both have "easily run your app" goals.

There is already this from Microsoft https://github.com/getporter/porter

Fail to see how this is any different than Dhall (https://dhall-lang.org/) other than it produces plists too.

Kubernetes config is a decent example. I had ChatGPT generate a representative silly example -- the content doesn't matter so much as the structure:

https://gist.github.com/cstrahan/528b00cd5c3a22e3d8f057bb1a7...

Now consider 100s (if not 1000s) of such files.

I haven't given Pkl an in depth look yet, but I can say that the Industry Standard™ of "simple YAML" + string substitution (with delicate, error prone indentation -- since YAML is indentation sensitive) is easily beat by any of:

- https://jsonnet.org/

- https://nickel-lang.org/

- https://nixos.org/manual/nix/stable/language/index.html

- https://dhall-lang.org/

- (insert many more here, probably including Pkl)

There are underpowered languages / tools, that can only solve a problem for which they are intended poorly. But not all limited tools are like that.

Say, eBPF is prominently not Turing-complete, which allows to guarantee that a eBPF program terminates, and even how soon. Still eBPF is hugely useful in its area.

Or, say, regular expressions are limited to regular languages; in particular, they famously [1] cannot process recursive structures, like trees. Still tools like grep / ag / rg are mightily useful.

Yes, I agree that YAML is underpowered for proper k8s configuration! But it's also too powerful for its own good in other aspects [2]. I wish Google used Dhall [3] or their own purely functional config language (FCL? I already forgot the name) instead of YAML; sadly, they did not.

[1]: https://stackoverflow.com/a/1732454/223424

[2]: https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr...

[3]: https://dhall-lang.org/

Dhall: Dhall is a programmable configuration language that combines features like JSON, functions, types, and import capabilities. Its style leans towards functional programming, so if you're familiar with functional-style languages such as Haskell, you might find Dhall to be quite intuitive.

I've been thinking along these lines but more 'strongly validated' than statically typed in the sense that you'd be better off being able to load the entire config and then produce a list of problems (and should be able to offer good editor support if done correctly).

Though https://dhall-lang.org/ demonstrates that you can statically type quite a lot of configuration to great advantage, which appears to be programmatically embeddable in multiple languages per https://docs.dhall-lang.org/howtos/How-to-integrate-Dhall.ht...

> Where practical is in the sense of an engineer (or in their terms, a CS practitioner),

Configuration processing. E.g. I'd like my yamls to be decidable, though I'd settle for guaranteed to halt[1].

[1] https://dhall-lang.org/

Maybe you'd like jsonnet: https://jsonnet.org/

I find it particularly useful for configurations that often have repeated boilerplate, like ansible playbooks or deploying a bunch of "similar-but" services to kubernetes (with https://tanka.dev).

Dhall is also quite interesting, with some tradeoffs: https://dhall-lang.org/

A few years ago I did a small comparison by re-implementing one of my simpler ansible playbooks: https://github.com/retzkek/ansible-dhall-jsonnet

And to checkout Dhall: https://dhall-lang.org/