Looking at your program’s structure in Go 1.7
pauladamsmith.com
Looking at your program’s structure in Go 1.7
1–10 of 54 posts
Re: Looking at your program’s structure in Go 1.7
#2I must admit I was kind of hoping they'd fixed their horrible requirements for your directory structure, interesting article nonetheless
Re: Looking at your program’s structure in Go 1.7
#3I 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.
Re: Looking at your program’s structure in Go 1.7
#4I 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.
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
They just want to clone anywhere and run "go build".
Re: Looking at your program’s structure in Go 1.7
#5Earlier 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…
> 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.
Re: Looking at your program’s structure in Go 1.7
#6Earlier 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.
Vendoring doesn't work outside $GOPATH
Re: Looking at your program’s structure in Go 1.7
#7Earlier 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.
It didn't have any external dependencies, only multiple packages.
Re: Looking at your program’s structure in Go 1.7
#8I 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 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.
Re: Looking at your program’s structure in Go 1.7
#9Earlier 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.
I found vendor directories to be documented in a confusing way, so I'm not surprised.
https://golang.org/cmd/go/#hdr-Vendor_Directories
I think the example there is hard to follow. Perhaps with more standard package names, such as golang.org/x/net or a popular github.com package, instead of the made up foo, baz, quux and so on it would be easier to understand exactly what advantages vendoring gives you.
Re: Looking at your program’s structure in Go 1.7
#10Earlier 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 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`