Looking at your program’s structure in Go 1.7 • Hacker News Board

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

#31

Post by stouset » Tue, Aug 16, 2016, 4:31 PM UTC

thewhitetulip wrote: post #10

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…

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.

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

#32

Post by stouset » Tue, Aug 16, 2016, 4:32 PM UTC

mixedCase wrote: post #28

bigdubs wrote: post #6

Earlier quoted context omitted.

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.

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

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

#33

Post by stouset » Tue, Aug 16, 2016, 4:39 PM UTC

themartorana wrote: post #18

rcarmo wrote: post #12

Earlier quoted context omitted.

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

Then don't? This is just being opinionated in the other direction and declaring yours the right one.

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 their way. One of these perspectives forces their preferences on the other. And it's not the GP.

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

#34

Post by pcwalton » Tue, Aug 16, 2016, 4:40 PM UTC

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

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

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

#35

Post by stouset » Tue, Aug 16, 2016, 4:44 PM UTC

mappu wrote: post #15

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

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

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.

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

#36

Post by 0xdeadbeefbabe » Tue, Aug 16, 2016, 4:54 PM UTC

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.

If you choose to vendor part of stdlib like http then boom diamond dependency problem approaches.

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

#37

Post by twblalock » Tue, Aug 16, 2016, 5:02 PM UTC

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.

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

You shouldn't have to!

A good dependency management system will produce reproducible builds via dependency versioning without any need to "vendor" anything.

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

#38

Post by mixedCase » Tue, Aug 16, 2016, 5:22 PM UTC

stouset wrote: post #32

mixedCase wrote: post #28

Earlier quoted context omitted.

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

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

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

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

#39

Post by stcredzero » Tue, Aug 16, 2016, 6:14 PM UTC

stouset wrote: post #33

themartorana wrote: post #18

Earlier quoted context omitted.

Then don't? This is just being opinionated in the other direction and declaring yours the right one.

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

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

#40

Post by IshKebab » Tue, Aug 16, 2016, 6:38 PM UTC

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…

I agree. I think the real problem is that they are using environment variables for this. Environment variables just aren't user friendly, especially on Windows.

It would be better if Go just downloaded all `go get` packages to some default fixed directory (%appdata%/go or whatever), and then the code the people manually download/write could live anywhere.