[Veuxdo]

I'm a bit biased, but I feel diagrams-as-code should use a stateless, declarative language (like json or yaml) and not a programming language. Programming languages have so much functionality that just doesn't apply to the output you're generating.

I guess the argument is "I already know Go" (or Python etc.). But you probably already know json (yaml), too. And if not, it won't take long to learn.

[taeric]

Depends heavily on the diagram?

I go farther, all told. I think any sort of diagram should almost certainly be process/pipeline based. Parts can be generated by a declarative markup, certainly. But you need a pipeline to "hand tune" things or you will end with diagrams that are clearly generated by a program. Fine for some things, sure. But there is a reason most of the diagrams that you remember the looks of were bespoke authored in a much more graphical environment.

[smoyer]

If this was used as a generator, you could include actual type names, godoc comments (on mouse over for smarter image formats), etc. In this case, it's the fact that the rest of the code could provide context.

[sn9]

I've used python for graphviz just because I wanted some looping for many-to-one or one-to-many relationships and the auto-complete that comes from anything with an LSP or Python mode.

Honestly I'd use it just for the auto-complete.

(Admittedly, I didn't look too hard for dedicated editing environments that could do it for DOT files specifically. I just wanted to make something real quick.)

[cle]

There are times when it's very useful to have programmatic bindings for diagrams, I've used them multiple times when I want to create a diagram that represents the structure of some code, auto-generate a state machine diagram based on the code, etc. These are very handy because you don't need to keep documentation up-to-date.

[datadeft]

Like D2? I love it.

https://play.d2lang.com/

[HyperSane]

Loops are way too useful, which is why I prefer actual programming languages over declarative solutions.