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

How to start a Go project in 2018

boyter.org

Post reply on HN
Print view View original

81–90 of 117 posts

Re: How to start a Go project in 2018

#81

Post by send_computers »

zimbatm wrote: post #70

It's distasteful of Go to impose a filesystem layout. Any other language that I work with understands that dependencies should be self-contained within the project folder. Each project has it's own set of dependencies that have been tested to work together. The user can select where to checkout the project, or even have multiple copies of the same project lying around. To achieve the same thing with Go, one has to se…

This seems like a description of NPM in the node ecosystem, they are incrementally solving all these issues.

Re: How to start a Go project in 2018

#82

Post by ngrilly »

zimbatm wrote: post #70

It's distasteful of Go to impose a filesystem layout. Any other language that I work with understands that dependencies should be self-contained within the project folder. Each project has it's own set of dependencies that have been tested to work together. The user can select where to checkout the project, or even have multiple copies of the same project lying around. To achieve the same thing with Go, one has to se…

Work is ongoing to solve this: https://github.com/golang/vgo/. GOPATH won't be necessary anymore.

Re: How to start a Go project in 2018

#83

Post by strkek »

zimbatm wrote: post #70

It's distasteful of Go to impose a filesystem layout. Any other language that I work with understands that dependencies should be self-contained within the project folder. Each project has it's own set of dependencies that have been tested to work together. The user can select where to checkout the project, or even have multiple copies of the same project lying around. To achieve the same thing with Go, one has to se…

I made[1] a zsh hook some time ago that allowed you to have per-project GOPATH.

At the root of the project I just have to do `echo 'github.com/username/package' > .gopkg` and after that, for everything I do under that directory tree, GOPATH will be automatically set to something like `export GOPATH="$(dirname .gopkg)/.gopath"`.

I don't use zsh anymore though.

[1]: https://gist.github.com/strkek/294c2f5e6fe94b8303b5121266b27...

Re: How to start a Go project in 2018

#84

Post by Sir_Cmpwn »

I think this article is a little bit shortsighted. You should probably be studying vgo in 2018 instead of using the old and soon-to-be deprecated way. Of course, this being golang, I'm about to get a bunch of replies from people who think they know better suggesting that vgo is terrible and describe their stockholm-syndrome-like relationship with GOPATH.

vgo is the only reason I am willing to give Go the time of day in 2018.

Re: How to start a Go project in 2018

#85

Post by strkek »

jrockway wrote: post #46
simula67 wrote: post #36

> Go dependencies are a little odd the first time you run into them. I suspect this is because Google runs a mono-repo and as such the decisions around it were made with that in mind. I think the oddness is around the directory structure. It may also be because Go was developed by UNIX old hands. When UNIX was designed, it was not just for ordinary users, but also developers. When developing in UNIX, you can use all…

To be fair, go code at Google doesn't use the standard directory structure. I had all my go code in one directory and which files were part of which package was all defined in a build file. What exists in the public world of go was simply what the go team wanted for go and not a compromise to fit in with other systems at Google. I think the fact that you end up with what looks like a monolithic repository is just a c…

> In the end ~/go doesn't look a lot different than the @INC path that points to something in your home directory, or /usr/include, /usr/lib, and /usr/bin in a pure C system.

Well, yes and no, and that's the only thing I don't like about GOPATH: that your source code is not in GOPATH, but in `$GOPATH/src`.

I'm not against GOPATH per-se because I'm already used to other PATHs; I'm just against it not behaving like those other common PATH variables, like PATH, LD_LIBRARY_PATH, PYTHONPATH[1], etc. GOPATH introduces intermediary directories (src, pkg, bin), instead of going straight to the point and being only for source code.

I mean, there's `GOPATH` and also `GOBIN` which is just `$GOPATH/bin`. IMO it would make much more sense for GOPATH to be only source code, GOBIN to be only executables, and something like GOPKG for the current `$GOPATH/pkg`.

[1]: Yes I know venv is a thing, I'm just mentioning PYTHONPATH to illustrate my point.

Re: How to start a Go project in 2018

#86

Post by coldtea »

baby wrote: post #76
coldtea wrote: post #68

Earlier quoted context omitted.

> What tooling are they dismissing? A proper package manager, like cargo, npm, pip, composer, maven and the like, for one.

Except Cargo, none of these are default toolings and were made by the community.

Irrelevant, as I didn't say the Go team should build a package manager, just that Go lacks one.

And I mean a dominant one -- there's a few attempts for Golang. Default doesn't have to mean "core-team built". All the package managers I've mentioned are de-facto standards for their respective languages.

Re: How to start a Go project in 2018

#87

Post by rco8786 »

send_computers wrote: post #81
zimbatm wrote: post #70

It's distasteful of Go to impose a filesystem layout. Any other language that I work with understands that dependencies should be self-contained within the project folder. Each project has it's own set of dependencies that have been tested to work together. The user can select where to checkout the project, or even have multiple copies of the same project lying around. To achieve the same thing with Go, one has to se…

This seems like a description of NPM in the node ecosystem, they are incrementally solving all these issues.

That’s, like, the opposite of npm though. It does dependencies per project, versioning, and does not impose any filesystem restrictions. Not that it doesn’t have issues.

Re: How to start a Go project in 2018

#88

Post by brunoluiz »

ovao wrote: post #44
brunoluiz wrote: post #19

I was expecting a way to organise a golang folder structure for web apis (2018), as there are some old tutorials out there

The overall approach to folder structure can be a personal thing, and doesn't matter too much what you settle on. My own preference is for something like: github.com/ / |- main.go | |- config/ | |- db/ | |- server/ | |- router/ | |- handler/ | | |- get/ | | |- put/ etc. In this setup, the router sub-package might import handler/get, handler/put, and so on, returning a router, which can typically be passed as an http.…

But wouldn't be better to organize it in domains, together with clean architecture? Because if the application have too many domains, it can get a bit messy, doesn't it? (Although if a micro-service strategy is used this shouldn't be a problem)

Re: How to start a Go project in 2018

#89

Post by baby »

coldtea wrote: post #86
baby wrote: post #76

Earlier quoted context omitted.

Except Cargo, none of these are default toolings and were made by the community.

Irrelevant, as I didn't say the Go team should build a package manager, just that Go lacks one. And I mean a dominant one -- there's a few attempts for Golang. Default doesn't have to mean "core-team built". All the package managers I've mentioned are de-facto standards for their respective languages.

Irrelevant

Re: How to start a Go project in 2018

#90

Post by brunoluiz »

navd wrote: post #33
brunoluiz wrote: post #19

I was expecting a way to organise a golang folder structure for web apis (2018), as there are some old tutorials out there

Is this something that others are interested in as well? Btw what kind of info would you like to see in a write up about this?

I am always interested in how to organize the folder architecture in a way that, in the future, it will not get in front of the development team.

Example: MVC was one of the go-to choices some years ago with folders /models, /view and /controllers, where everything was put in it. But, nowadays we know that it can get messy, specially when there are too many domains. Besides that, MVC isn't appropriated for the REST world (the V is not suited for that).

Post reply on HN