Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Looking at your program’s structure in Go 1.7

pauladamsmith.com

Post reply on HN
Print view View original

21–30 of 54 posts

Re: Looking at your program’s structure in Go 1.7

#21

Post by bassislife »

thewhitetulip wrote: post #3
deallocator wrote: post #2

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

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.

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.

Re: Looking at your program’s structure in Go 1.7

#23

Post by saturn_vk »

bschwindHN wrote: post #8
thewhitetulip wrote: post #3

Earlier quoted context omitted.

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.

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.

Its almost exactly the same as gradle java projects. Each module there has a 'src' directory where all code and whatnot lives. And nothing's stopping you from having a one-liner bash script that sets up the base as the GOPATH and then running `go build`/

Re: Looking at your program’s structure in Go 1.7

#25

Post by jevinskie »

qznc wrote: post #24
jevinskie wrote: post #22

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

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

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.

Re: Looking at your program’s structure in Go 1.7

#26

Post by wtbob »

bschwindHN wrote: post #8
thewhitetulip wrote: post #3

Earlier quoted context omitted.

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.

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.

> But Go has to be special and use a special directory or else it throws a hissy fit.

I just set GOPATH=$HOME, and then all my source (Go & otherwise) is in ~/src, all my binaries (Go & otherwise) are in ~/bin, &c. It works really well for me. So some of the subdirectories of ~/src are a bit funkily-named: no big deal.

Re: Looking at your program’s structure in Go 1.7

#27

Post by icholy »

bigdubs wrote: post #6
mseepgood wrote: post #5

Earlier quoted context omitted.

> But worst was probably the missing import path structure, i.e. "github.com/ / " that people simply just didn't get. You obviously didn't vendor your dependencies in your project's vendor directory.

Vendoring doesn't work outside $GOPATH

Why is this the case?

Re: Looking at your program’s structure in Go 1.7

#28

Post by mixedCase »

bigdubs wrote: post #6
mseepgood wrote: post #5

Earlier quoted context omitted.

> But worst was probably the missing import path structure, i.e. "github.com/ / " that people simply just didn't get. You obviously didn't vendor your dependencies in your project's vendor directory.

Vendoring doesn't work outside $GOPATH

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

Re: Looking at your program’s structure in Go 1.7

#29

Post by mixedCase »

rcarmo wrote: post #12
grncdr wrote: post #11

Earlier quoted context omitted.

You can always symlink a project located in your GOPATH to your `projects` directory.

It's brittle and confusing nonetheless. Having to set up Go on all the machines I use is a pain I could do without.

How many machines do you develop in? go getting and ln -s in your code folder isn't exactly an ardous, confusing task.

Re: Looking at your program’s structure in Go 1.7

#30

Post by stouset »

mappu wrote: post #16
Spiritus wrote: post #4

Earlier quoted context omitted.

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 $ git clone $ cd $ go build And obviously it failed because it wasn't in a "src" folder (it w…

Consider checking in the whole gopath to the VCS, and supply a makefile that calls `GOPATH=$(pwd) go build`. You see this for Java projects where the whole source code is nested half a dozen folders deep (src/com/foo/bar/baz/myproject/...) so i don't think it's unfamiliar.

Yes, there are silly workarounds. The whole point is that it's a PITA to work with and breaks many common workflows for scant few actual benefits. Especially now that `godep` is in wide use, which just artificially creates the go workspace structure from in-tree dependencies anyway.
Post reply on HN