Live data from Hacker News

Create system diagrams with Go

github.com

51–60 of 70 posts

Re: Create system diagrams with Go

#51

What's the benefit of coding a visual diagram over drawing it? I was at first thinking of automated verification rules that force your diagram to commute over a set of rules you specify but even drawing tools can specify this. Any people who diagram a lot have an opinion on this?

> 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.

Re: Create system diagrams with Go

#52
I have gotten really used to drawing all my technical diagrams with Inkscape (system arch, sequence diagrams, product roadmaps, etc).

Granted, it's labor intensive and hard to justify the learning curve just for technical diagrams but I find that once you have built the muscle memory and a good mental map, it's not that slow (and encourages concision and good abstraction to make the diagram simpler) and superior to auto-generated layouts because it gives me the flexibility to make prominent what deserves to be prominent (objects, paths) and complete control over styling. I also hate it when adding a single element might change the auto-optimized layout entirely.

I wonder what folks who use (go-)diagrams at scale think of this. Maybe my solution is untenable for large enough projects.

Re: Create system diagrams with Go

#53

Every time I have to create a diagram I struggle. If I want something quick and dirty the options are out there. But if I want to create a diagram for a serious project, I have trouble. Ideally, I would love a solution that integrated with templates and allowed me to define my diagrams at a "higher-level". It should also integrate with Latex to look consistent. Does anyone know of a better alternative to TikZ for my…

PlantUML may be of interest for some kinds of diagrams. https://plantuml.com/

Looks promising! Especially the Activity Diagram. Although these diagrams don't look too modern -that base style could see a refresh- it would do the trick just fine for me!

Re: Create system diagrams with Go

#54
post #52

I have gotten really used to drawing all my technical diagrams with Inkscape (system arch, sequence diagrams, product roadmaps, etc). Granted, it's labor intensive and hard to justify the learning curve just for technical diagrams but I find that once you have built the muscle memory and a good mental map, it's not that slow (and encourages concision and good abstraction to make the diagram simpler) and superior to a…

One thing I like about textual diagramming tools (in code like this project or in a markup dsl) is I can version control and diff changes.

Re: Create system diagrams with Go

#55
post #52

I have gotten really used to drawing all my technical diagrams with Inkscape (system arch, sequence diagrams, product roadmaps, etc). Granted, it's labor intensive and hard to justify the learning curve just for technical diagrams but I find that once you have built the muscle memory and a good mental map, it's not that slow (and encourages concision and good abstraction to make the diagram simpler) and superior to a…

One thing I like about textual diagramming tools (in code like this project or in a markup dsl) is I can version control and diff changes.

Fair! Do you build workflows around the diffs themselves (collaborate, review, update)? I can already put my svgs in version control and have history/versions. But I've never felt compelled to look at a textual diff of viz code.

Re: Create system diagrams with Go

#56
post #51

What's the benefit of coding a visual diagram over drawing it? I was at first thinking of automated verification rules that force your diagram to commute over a set of rules you specify but even drawing tools can specify this. Any people who diagram a lot have an opinion on this?

> 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 spac…

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.

Re: Create system diagrams with Go

#57
post #52

I have gotten really used to drawing all my technical diagrams with Inkscape (system arch, sequence diagrams, product roadmaps, etc). Granted, it's labor intensive and hard to justify the learning curve just for technical diagrams but I find that once you have built the muscle memory and a good mental map, it's not that slow (and encourages concision and good abstraction to make the diagram simpler) and superior to a…

I've made diagrams for my talks in both style (with code and with Inkscape or, these days, Lucidchart). Writing code to generate diagrams had a much larger setup cost but once I had it going, iterating on the diagrams became much easier.

I had a talk about radix trees[1] where I wrote some Haskell code that could take trees and generate diagrams from them. Getting the code right in the first place took a few hours but in this case it was clearly worth it in hindsight for two reasons:

1. I ended up with a lot of tree diagrams. Once the code was working, the marginal cost of adding an extra diagram went way down and I think that improved the talk as a whole.

2. Code made it much easier to iterate on my examples. I had an extended example[2] that I changed several times; if I had had to manually redo the diagrams for it each time, I would not have bothered.

These days, this trade-off (up-front vs ongoing costs) makes the decision reasonably easy. If I'm going to be making a single diagram and I don't expect to change it much, I'll do it manually; if I'm going to be making a series of similar or related diagrams or if I expect to iterate on the diagrams a lot, I'll write some code for them. So far, I haven't regretted following this approach in either case :).

[1]: https://jelv.is/talks/lambda-world-2018/slides.html#/sec-tit...

[2]: https://jelv.is/talks/lambda-world-2018/slides.html#/slide-o...

Re: Create system diagrams with Go

#58
post #57
post #52

I have gotten really used to drawing all my technical diagrams with Inkscape (system arch, sequence diagrams, product roadmaps, etc). Granted, it's labor intensive and hard to justify the learning curve just for technical diagrams but I find that once you have built the muscle memory and a good mental map, it's not that slow (and encourages concision and good abstraction to make the diagram simpler) and superior to a…

I've made diagrams for my talks in both style (with code and with Inkscape or, these days, Lucidchart). Writing code to generate diagrams had a much larger setup cost but once I had it going, iterating on the diagrams became much easier. I had a talk about radix trees[1] where I wrote some Haskell code that could take trees and generate diagrams from them. Getting the code right in the first place took a few hours bu…

Thanks for this! Ceating multiple slightly different diagrams manually is indeed a painpoint.

Re: Create system diagrams with Go

#59

What's the benefit of coding a visual diagram over drawing it? I was at first thinking of automated verification rules that force your diagram to commute over a set of rules you specify but even drawing tools can specify this. Any people who diagram a lot have an opinion on this?

> 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.

Re: Create system diagrams with Go

#60
post #14
post #11

Earlier quoted context omitted.

It's written in GO! :P

Is this tool beyond creating diagrams? If not, I don’t grasp the point of porting, writing the diagram is like scripting, for which python is arguably a better choice. I hope this isn’t a trend similar to Atwood's Law: “Any application that can be written in JavaScript, will eventually be written in JavaScript.”

Its a funny law but ultimately people like using the tools and languages they know. And most languages are good. So id expect youd see most things ported to most languages excepting where they are prohibitivley expensive. Also making things is fun.
Post reply on HN