Looking at your program’s structure in Go 1.7

https://pauladamsmith.com/blog/2016/08/go-1.7-ssa.html

by tptacek • 10 years ago

238 53 10 years ago

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

thewhitetulip4• 10 years ago

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.

Spiritus2• 10 years ago

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

bschwindHN2• 10 years ago

It's opinionated, and not the good kind. Some people like having simply a `projects` directory with all coding projects inside. For almost any language, I can clone into this directory and run the associated build scripts. But Go has to be special and use a special directory or else it throws a hissy fit.

Aside from that, I do enjoy the language a fair amount.

Manishearth• 10 years ago

This forces me to use a single clone. I can't work on multiple features simultaneously in different build dirs.

This is incompatible with path dependencies. When I was working on the YCM goto support for Go I had to rewrite all the imports in godef to be path imports because you can't go build packages with github deps outside of gopath. This rewriting had to be done in each file (and forced us to fork the package).

We wanted to use godef as a local folder because YCM wants to be able to pin to a version, usually via a submodule. `go get <github>` will be affected by silent updates.

Having everything in $GOPATH has the advantage that all your go code is in one place, but it's not much of an advantage because it's not flat -- you have to `cd github.com/<someusername>/<reponame>` whereas my regular `code` folder has a flat structure, with subfolders only for special cases (e.g. projects with multiple linked repos or whatever).

There are tons of disadvantages, which totally overshadow the minor advantage of automatically giving you a `code` folder -- something which is super easy to do without the "help" of GOPATH.

Fortunately a lot of these things get solved by vendoring, glide, and friends. Bare GOPATH is still terrible.

bassislife• 10 years ago

It's problematic for dependency management. It's almost perfect but what would be better would be to be able to switch easily between different $GOPATH. One per project.

We can already create multiple ones.

sleepydog• 10 years ago

I've simply started using $GOPATH for everything. Even my non-Go projects live under $GOPATH/src/<url-to-repo> . I know many people are very particular about the way they work but I did not have any trouble adapting to this, and in the end I found it much easier to manage my projects.

My only problem now is that I have so many projects checked out that it's hard to remember which ones I am contributing to vs which ones were checked out as a dependency. I think I can address that by setting GOPATH to ~/thirdparty:$GOPATH or something, but it hasn't bothered me enough yet.

mappu2• 10 years ago

I've come around to GOPATH after hating it originally. It forces you to be somewhat explicit about your package relationships, the package's name, how it finds everything it imports, and how other packages see it. It's doubly important in a language where packages are the compiler's translation unit. The fact is that every language has these problems, GOPATH only makes you confront them - in a standard way, whereas in other languages, you would run into and make a different ad-hoc solution for every project.

C++ is a great example of a model to avoid (pkg-config handles dependencies, except use autoconf for crossplatform, except cmake is newer and supports windows, except then you should use cmake modules instead of p-c, not to mention qt having its own qmake, ...).

Chaining GOPATHs with : can be very useful (just like PATH).

You can use `gb` if you want a "typical" one-folder-per-project workflow.

jacques_chester• 10 years ago

GOPATH is an obnoxious neighbour. Most other systems try to play nice.

The fact is that every language has these problems

Other languages solve them with proper module or library systems.

Rubygems + Bundler is still the standout in this field. Based on my day job, bundler still better at the basic job of "get the stuff I need" and "keep the stuff I need" than any of Pip, NPM, Godep, Composer, Conda and I forget the rest.

whereas in other languages, you would run into and make a different ad-hoc solution for every project.

It depends on the language. Ruby and NodeJS have clearly dominant single systems. Rust has one by design. Python is a bit of a mess but Pip seems dominant, with Conda for scientific packages. PHP has Composer, which makes a lot of things tolerable, but not great. Go package managers are not really settled, between Godep, Go vendoring and Glide.

stouset5• 10 years ago

Except make, cmake, and autotools handle a completely separate problem which `GOPATH` has nothing to do with.

Yes, being able to `go get` is great. Except `GOPATH` doesn't make it any more or less possible, especially now that `godep` is widely used. And that breaks down completely when you actually need to build something that consists of more than just go source. Protos, multi-language projects, etc.

jevinskie2• 10 years ago

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

qznc3• 10 years ago

Why not use a proper graph? http://pp.ipd.kit.edu/firm/GraphSnippets

jevinskie2• 10 years ago

Is SSA form not already a proper graph? I would agree that the visualization would benefit from a toggle between pure textual representation and one that includes the graph structure with textual basic blocks. LLVM already has graphviz output so perhaps a dot2html utility with some SSA smarts added would do the trick.

jasonwatkinspdx• 10 years ago

Because the boxes and arrows style visualization becomes a horrific mess quite quickly when dealing with anything beyond toy examples. Look at the diagram for a 4 line for loop in your link, then think about what a 200 line function looks like.

chewxy• 10 years ago

Because you will end up with unwieldly graphs like these:

https://twitter.com/chewxy/status/433807908875145216

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

pcwalton• 10 years ago

-print-after-all combined with the graphviz visualizer is very loosely similar.

Looking at your program’s structure in Go 1.7

Related Stories