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

31–40 of 117 posts

Re: How to start a Go project in 2018

#31

Post by sixo »

faitswulff wrote: post #15
KyeRussell wrote: post #3

It feels like a slight failure that things like this are necessary, especially for a new language. As a Python developer, I am no stranger to slightly ridiculous packaging / environment woes. However Go has 19 years on Python. I understand that they are different languages and ostensibly serve different purposes, but it feels like a shortcoming to me - based on the little Go experience I've had.

> As a Python developer, I am no stranger to slightly ridiculous packaging / environment woes. Speaking of which, what is the best way to start a python project in 2018, now? Python's version and dependency management is my least favorite aspect of the language.

Based on this recent blog post that's been passed around, Pipenv. https://jacobian.org/writing/python-environment-2018/

Re: How to start a Go project in 2018

#32

Post by digianarchist »

KyeRussell wrote: post #3

It feels like a slight failure that things like this are necessary, especially for a new language. As a Python developer, I am no stranger to slightly ridiculous packaging / environment woes. However Go has 19 years on Python. I understand that they are different languages and ostensibly serve different purposes, but it feels like a shortcoming to me - based on the little Go experience I've had.

Indeed. There are now many useless repos on Github that are basically unbuildable because dependency lockfiles do not exist for them.

I've got to figure out which version was out during the last commit and then pin it. Absolute nightmare.

Re: How to start a Go project in 2018

#33

Post by navd »

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?

Re: How to start a Go project in 2018

#34

Post by osteele »

ospider wrote: post #24

`dep` is actually a good tool and suppose to be the official tool. But out of no reason, `vgo` came out and said to be deprecating `dep`. I don't really understand how the Go team make decisions.

> I don't really understand how the Go team make decisions.

If you haven’t yet read it, start here: https://blog.golang.org/versioning-proposal

Re: How to start a Go project in 2018

#35

Post by latchkey »

lucidone wrote: post #29

The biggest blocker in getting me to give Go a shot is it forcing a certain directory structure on me, and the lack of Gemfile or package.json equivalent. Has this been solved? I really want to use Go because of everything I've heard, but I can't stand how $GOPATH forces a directory structure on me.

It bugs you for about 20 minutes as you question why this isn't like other languages you used before, and then you get over it. If that is your only stumbling block to learning a new language, I think you can overcome it pretty easily.

Re: How to start a Go project in 2018

#36

Post by simula67 »

> 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 of UNIX as an IDE ( grep, find etc ). Most Unices have a folder called /usr/src [1] where sources are stored. When you want to build a package, you cd into it ( say 'cd /usr/src/make') and then say 'make && make install' and it builds and installs the packages to your /usr/bin.

I am assuming, Google's internal monorepo, which is derived from Perforce [2] encourages you to keep the /usr/src under source control. Since Piper is not released to the public and most people now use git, GOPATH was probably conceived as a way to relocate '/usr/src/' to another location. This is probably why 'go install' ( which probably mimics 'make install' ) installs everything at 'GOPATH/bin'. If this is true, I think we have a mental model on Go's directory structure.

Hopefully someone can tell me if I am off base.

[1] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

[2] https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...

Re: How to start a Go project in 2018

#37

Post by dsymonds »

> To search for anything about Go in your search engine of choice use the word golang rather than go when searching. For example to search for how to open a file I would search for golang open file.

This seems to be a recurring chestnut, but I would have expected the author to actually test it. If I search for [go open file], 8 of the first 10 results on Google show useful information.

Re: How to start a Go project in 2018

#39

Post by sigjuice »

slrz wrote: post #23
nostalgeek wrote: post #8

Earlier quoted context omitted.

GOPATH is going away with vgo so it wasn't really good at all as it forced the developer to adopt a specific folder organization. The fact that go maintainers acknowledged this issue is a sign they are ready to move the language forward.

> forced the developer to adopt a specific folder organization Well, so does C (and basically everything else). Alternatively, you can pass tons of -I and -L flags to your compiler calls but you can do that with Go, too. The point of GOPATH was to make this unnecessary because everything can be deduced from the source code and its location within the file system.

You have it backwards. C doesn't restrict where I can keep my source tree.

Re: How to start a Go project in 2018

#40

Post by shabbyrobe »

ospider wrote: post #24

`dep` is actually a good tool and suppose to be the official tool. But out of no reason, `vgo` came out and said to be deprecating `dep`. I don't really understand how the Go team make decisions.

Go in general seems to be powered by a general principle of "Was it invented here?", which undoubtedly stems from its plan9 roots as an upstart reinvention of Unix. The software community tends to treat the "not invented here" phenomenon as detrimental but I think in the case of Go, the willingness of the team to reject the status quo has been a significant contributor to its success and utility.

But for all the good this attitude brings (and I would definitely regard it as a net benefit) there have been some pretty huge missteps too, and the Go team's prioritisation of things like type aliases or the half-finished plugin architecture over those missteps leads many to ask reasonable questions about how those priorities are decided.

GOPATH is a long-acknowledged mistake and a lot of community effort and consensus-building work has gone into finding a solution. vgo was a bit of an ambush and has left a lot of people confused and bewildered, especially after a huge amount of community goodwill and momentum was built up around dep. That was a price Russ Cox decided to pay with vgo, which was his prerogative. Now we just need to wait and see whether it was worth it, which will take some time.

Post reply on HN