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

41–50 of 54 posts

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

#41

Post by IshKebab »

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.

What if I don't use Makefiles, because I live in the 21st century?

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

#42

Post by _0w8t »

mseepgood wrote: post #5
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…

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

Even if one vendors the external dependencies, the code that uses them must still be on GOPATH or the compiler would not find them. This is at least with go 1.6.

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

#43

Post by jasonwatkinspdx »

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

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.

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

#44

Post by tartley »

IshKebab wrote: post #41
mappu wrote: post #16

Earlier quoted context omitted.

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.

What if I don't use Makefiles, because I live in the 21st century?

That's like saying "I don't use wheels, because I don't live in the prehistoric era when they were invented."

Some tools are fundamental. A tool to solve the problem of executing dependant tasks is one of them.

Solutions to these fundamental problems tend to be implemented early on. Some of those early solutions were poor, and have fallen out of use. Some of them were good, and have been refined in the intervening years, and hence are still with us.

A good tool to solve a fundamental problem is still useful, no matter how old it is.

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

#45

Post by duai »

stcredzero wrote: post #39
stouset wrote: post #33

Earlier quoted context omitted.

This is inane. The approach GP is talking about lets any developer manage the space above their project however they care to . The `GOPATH` approach forces this one structure upon you. It's like arguing that marriage equality violates your right to believe a marriage is between one man and one woman. One side is arguing that folks should be able to decide what's best for themselves, the other is saying it must be the…

The `GOPATH` approach forces this one structure upon you. That's basically the point. It's like arguing that marriage equality violates your right to believe a marriage is between one man and one woman. No, it's more like the Pythonic "There's one way to do it."

> No, it's more like the Pythonic "There's one way to do it."

Nope, because it's "There should be one obvious way to do it." and you can still do the non-obvious way if you prefer.

It doesn't force anything upon you.

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

#46

Post by qznc »

jasonwatkinspdx wrote: post #43
qznc wrote: post #24

Earlier quoted context omitted.

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

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.

I do use the tool which created the images for large functions (100.000 nodes was the max) and with zoom, search, etc it is fine. With graphviz it sucks, though.

Unfortunately, our yComp tool is not Free Software. http://pp.ipd.kit.edu/firm/yComp

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

#47

Post by sleepydog »

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.

I've simply started using $GOPATH for everything. Even my non-Go projects live under $GOPATH/src/ . 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.

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

#48

Post by josephearl »

saturn_vk wrote: post #23
bschwindHN wrote: post #8

Earlier quoted context omitted.

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`/

I don't think it is at all same. You can clone a Gradle-based project anywhere (e.g. /projects), cd into that directory and run `gradle build` and it will work. There is no `GRADLE_PATH` or similar environment variable determining where all your Gradle-based projects must live.

The `src` folder you are talking about is a sub-directory inside a Gradle based project. This is entirely configurable within the Gradle build script, you can use multiple sub-directories for your source code or even the same directory as the build script if you wish. The reason Gradle uses a single `src` sub-directory by default is that it follows the Maven Standard Directory Layout.

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

#49

Post by thewhitetulip »

stouset wrote: post #31
thewhitetulip wrote: post #10

Earlier quoted context omitted.

I agree on the point where it doesn't work well with mix languages. we can, however use `go get` rather than manually doing a git clone. I understand it'd be a pain to have Go setup, but once it is setup, it is great, When I write Go programs I do `$ cd /go/src/github.com/thewhitetulip/Tasks` `$ Tasks go build -o tasks` `$ Tasks ./tasks`

How is this different from any other language where you "just" run `cd path/to/project; (make || rake || pants || cargo)`? This isn't special, and it's not something the go workspace makes possible.

This is different because $GOPATH is a requirement of the language and in _other_ languages, you have to manually clone the repos in the correct root folder which you store all your code into.

Go allows you to do a go get reponame and it'll do the git clone stuff for you.

that is nothing short of amazing as far as code management is concerned. I love it.

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

#50

Post by thewhitetulip »

Spiritus wrote: post #4
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.

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…

On another note, I suggest you work around this limitation, you can write a benchmark in Go in the $GOPATH of your company or anything and then use `go install` to install it to the $PATH of your machine, so you can call the benchmark directly. This will separate the codebases.

Otherwise you can write the other language code in the $GOPATH itself.

Post reply on HN