
Looking at your program’s structure in Go 1.7 - tptacek
https://pauladamsmith.com/blog/2016/08/go-1.7-ssa.html
======
jevinskie
This sort of visualization would be nice for LLVM IR! The Go implementation is
located here:
[https://github.com/golang/go/blob/master/src/cmd/compile/int...](https://github.com/golang/go/blob/master/src/cmd/compile/internal/gc/ssa.go)

~~~
qznc
Why not use a proper graph?
[http://pp.ipd.kit.edu/firm/GraphSnippets](http://pp.ipd.kit.edu/firm/GraphSnippets)

~~~
chewxy
Because you will end up with unwieldly graphs like these:

[https://twitter.com/chewxy/status/433807908875145216](https://twitter.com/chewxy/status/433807908875145216)

[https://twitter.com/chewxy/status/433811541373116416](https://twitter.com/chewxy/status/433811541373116416)

This is from an old JITting Javascript engine I wrote in Go... a simple
program like this:

    
    
        function clamp(x, min, max) {
     	y = 2
     	if (x < min) {
     		x = min
     	} else if (x > max) {
     		x = max
     	}
     	return x
        }
    

can generate pngs that are thousands of pixels wide and high (depending on
what the nodesep and ranksep were set).

I wish I did think of the visualization that Go uses. That's fantastic
compared to graphs

~~~
qznc
Graphviz/dot sucks. Here is yComp for the same function:
[https://imgur.com/a/5eP9k](https://imgur.com/a/5eP9k)

The blocks and red edges represent the control flow graph and I can easily see
the two if structures.

It lets you zoom. Mouseover nodes to get more details.

------
deallocator
I must admit I was kind of hoping they'd fixed their horrible requirements for
your directory structure, interesting article nonetheless

~~~
thewhitetulip
If you mean the $GOPATH directory notation, then I beg to differ, it is one of
the favorite things about Go for me, because it is the repo which has all my
Go code.

For other languages I have a `code` folder which has individual language
folders and it contains project. Go has it by default.

~~~
Spiritus
That's what sucks though. I don't want a "gocode" folder and a "code" folder.
It also doesn't fit very well in a monorepo with mixed languages.

We had a small benchmark tool written in Go. And people simply couldn't build
it, they always came to me after banging their head trying.

This is basically what all of them did:

    
    
        $ cd <folder with all their projects and code>
        $ git clone <repo>
        $ cd <repo>
        $ go build
    

And obviously it failed because it wasn't in a "src" folder (it was in a git,
projects or code folder) nor had the $GOPATH environment variable set. But
worst was probably the missing import path structure, i.e.
"github.com/<company>/<repo>" that people simply just didn't get.

They just want to clone anywhere and run "go build".

~~~
mseepgood
> But worst was probably the missing import path structure, i.e.
> "github.com/<company>/<repo>" that people simply just didn't get.

You obviously didn't vendor your dependencies in your project's vendor
directory.

~~~
bigdubs
Vendoring doesn't work outside $GOPATH

~~~
mixedCase
Don't work outside $GOPATH. Set a temporary one if you want a completely
isolated environment for one-off building purposes.

~~~
stouset
Then what's even the point in the first place?

~~~
mixedCase
Development. Which is why I said "for one-off builds".

