[dlock17]

This seemed like nuclear overkill for most problems I can think of.

And where it should be used, I can't imagine you can't find a pre existing language (Cuelang maybe) instead.

I was expecting a section at the end where they demonstrate which services need a new language written just for it's configuration, but nope, just general examples.

Also, this should have a (2022) in the title.

[tony-allan]

I think that a Domain Specific Language without the scaffolding of a language like python to generate test data is a great use case.

You have a specific DSL to generate test data and store code written using your DSL with your test cases.

You then have a security model that separates the responsibilities of the test team from that of other developers. The team can generate many test cases in a secure environment. You could then seek community input into your test processes with having to worry about rogue code.

[jerf]

It is nuclear overkill for most problems you can think of.

But when you hit a problem that you need something like this for... you need something like this. The attempts to get around it or avoid it or do some unbelievably hacky thing leads to piles and piles of terrible, terrible code.

In 2024, though, I do try very hard to embed my DSLs in an existing serialization. It doesn't always work out, but, the case they show of directly embedding an AST into YAML is a worst-case scenario. In real life I've done things like specify a particular field carries an expr[1] expression to do that sort of thing, and then the structure of the rest of the file just follows normal serialization format.

[1]: https://github.com/expr-lang/expr , but I'm sure many static languages have something like this. If you don't know one, it's a good tool to put in the belt in case you ever need it.

[dlock17]

To be clear, my problem isn't with requiring a single DSL, it's with writing so many DSL's at work that there's need for a DSL writing framework to crap them out even faster.

At what point do you sit back and ask, is there a way to reduce complexity here? Is it not until you're joining a team where the last guy made dozens of DSL's for all his tools?

That was the main reason I was expecting more than a few real world use cases rather than generalized examples and no examples from their workplace.

[randomdata]

> is there a way to reduce complexity here?

Yes, you can generate your test data in the host language. That dramatically reduces upfront complexity.

But that doesn't come free. Now it is not easily transferrable to other languages. If you recall rsc's somewhat recent talk on testing, they benefited greatly by being able to use similar DSLs from other projects in tests to ensure feature parity. It can be a huge boon to have your test data scripts in an "agnostic" language for 30 years down the line when you are no longer working in the same environment.

Tradeoffs, as always.

> I was expecting more than a few real world use cases

Maybe that's the only use-case they know of? The project was clearly built for a specific purpose.

That's not to say that it cannot be found useful elsewhere, but that doesn't mean they have found it to be. If someone else finds it useful in other applications, I'm sure they'll write their own document about it. That's what the web is for, after all.

[0xCMP]

I wouldn't think of it for generating configuration. The example given implies they use it for fuzzing program inputs. It's purpose in the article is simple: generate a CSV with two columns and floats.

However, a DSL could be made to do anything. Generate particular kinds of PDFs, Excel files, intentionally incorrect CSV/TSV files, zipbombs, and etc.

All that is required is to wire it up in the Go side of things and then write a script to make use of it.

[randomdata]

> Also, this should have a (2022) in the title.

Is there something about the current state of world that has invalidated some or all of the content in the article?

[danmur]

Why have a title at all?

[kubectl_h]

> I was expecting a section at the end where they demonstrate which services need a new language written just for it's configuration, but nope, just general examples.

Heh that was my first instinct as to why they built this as well but more for providing ergonomic ways to generate k8s objects for complex gitlab specific CRDs.