It depends. When I have a good idea of what I want to draw, and I want to put it in a document, I like to use TiKZ in LaTeX because it is fairly easy (depending on the domain) to produce something pretty that is consistent with the style of the document and easy to change if the surrounding text is edited. The overhead of going through an external diagramming tool is often not worth it in this case, unless it's a quick one-off note.

If I want to get an overview of a data structure, I like to write code that generates dot, which I then render using graphviz. I have successfully used that for debugging a few times.

When I use diagrams as a tool for thinking, I prefer paper and pencil, or, if I need to make many changes, yEd. I also use the latter for system diagrams (I prefer loosely following the C4 ontology) or for quick dissemination of ideas to colleagues when we can't be in front of the same physical whiteboard.

The only text-based diagramming tool that I use for thinking is plantUML, although I have only used it for sequence diagrams.

I don't have a lot of experience with using embedded DSLs for diagramming. I have used 'diagrams' in Haskell which is nice, although knowing the host language didn't mean that it was faster to learn the DSL compared to, say, graphviz or plantUML. It doesn't take a lot of time to learn the syntax of these things, it's all about learning how the primitives work and how they can be combined. An EDSL is mostly convenient if you need to programmatically generate the diagrams from data structures, since you can call the diagram library directly and avoid icky string interpolation.

> What's the benefit of coding a visual diagram over drawing it?

I'd think the biggest benefit is that it would be easier to reproduce the diagram, iterate on it and save revisions of it in standard tools. It would also allow flexibility in that reproduction which would be super handy if you were creating a lot of similar diagrams.

And the most obvious one is simply you don't have to draw it. Some people find drawing diagrams to be extremely tedious but still need to do it frequently.

If you have "infrastructure as code" you could as well have diagrams of the infrastructure generated from that code too and go-diagrams is one brick to build that.

> What's the benefit of coding a visual diagram over drawing it?

TLDR: You want to communicate abstract relationships with a picture. How the picture is drawn usually isn't as important.

For example, say you want to visualize a graph (the nodes and edges kind). You would like to tell the computer:

1. Here's the definition of my graph.

2. Draw it in a clear, visually appealing way.

Point 2 encompasses things like spacing, layout, color, etc. I would much prefer an algorithm to make those decisions for me, assuming it's decent. They're boring implementation detail.

That said, imo Go is a poor choice for specifying such abstract relationships because of its verbosity. I'd rather use dot directly, or a more concise DSL.

That’s great if it works. I’ve yet to see a tool give me the same diagram layout I as a human can work out in roughly 20 minutes of trial and error. Not to say tools with auto layout aren’t helpful, but most of the diagram DSLs I’ve used have the ability to add constraints that will affect diagram layout which generally accomplish the same thing: have the human intervene in the diagram layout to create a better layout.

Note I’m not even talking about colours and spacing, I know computers can do a better job at that. I’m simply talking about how the graph is laid out and the decisions humans can make about what is still easy to read or which lines are more important than the other lines. Sometimes — often — the layout algorithm isn’t given all the information, the human doing the layout can re-interpret the graph data in real-time.

The best layout system, I imagine, is one that makes layout even easier for humans to control—but still puts the human in full, graphical control, at least as a form of data-entry. The problem I often have with visual tools is they make it hard to “add to the diagram” in a way that feels natural. I often wish I had a command that would push multiple objects out of the way, or a command to align some boxes to a grid such that I could add more to a “list”. I also wish I had a tool that would change the diagram as I zoom in and out, for diagrams that need progressively more detail, and so on. Maybe Miro or similar would do the trick, but then I’ve less visual control.

I think there’s a lot of room for improvement in diagramming tools but there’s also a steep learning curve perhaps. The easiest tool I’ve found to use interactively, personally, is OmniGraffle and I’ve heard Visio has some of what I’m looking for, yEd is nice too, but ultimately each tool has its limits, often because they’re designed around building one graph or diagram disconnected from the rest. The Brain or WebBrain is a nice data graphing tool but isn’t designed around producing diagrams. Often the beat we can do, it seems, is embed multiple diagrams within a document or to use layers to show and hide more detail manually, but then those layers need to me maintained manually also.