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

61–70 of 117 posts

Re: How to start a Go project in 2018

#61

Post by baby »

tazjin wrote: post #56
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.

> However Go has 19 years on Python Go explicitly dismisses everything learned by the programming language (and tooling) community at large because its authors "know better". There really isn't much to say about Go anymore in my opinion, other than answering the title of this post with "Don't".

What tooling are they dismissing? Default tooling is pretty much inexistant in other languages.

Re: How to start a Go project in 2018

#62

Post by dijit »

d4l3k wrote: post #53
reacharavindh wrote: post #48

Earlier quoted context omitted.

Serious question: Why do you need Docker for a Go project? Cant you build it, and copy the binaries over to the host you want to run it on?

There's definitely use cases for Docker with Go that mostly revolve around running untrusted code or wanting to be able to set tight restrictions on CPU usage, memory etc. Though you could also just do the latter via cgroups. Another use case might be if you have extra files that need to be deployed with the binary as well. I wrote up some documentation about this for my use case just in case I ever have to go back a…

>There's definitely use cases for Docker with Go that mostly revolve around running untrusted code.

Please don't run untrusted code in Docker, it's not designed for security.

https://security.stackexchange.com/questions/107850/docker-a...

Re: How to start a Go project in 2018

#63

Post by imjasonmiller »

tyrankh wrote: post #10

Couple of quick notes from my phone, as a googler gopher: - IIRC package management was historically left to the community to solve for, rather than the go maintainers mandating how package mgmt should be done. Many languages have followed this model. I've never heard of it having to do anything with our mono repo model. The community never ended up standardizing on a model; since then, the go team has endorsed godep…

If I may ask, how do you handle the use of other languages within a project that uses Go? I am new to Go, so it might be a silly question.

I currently have a project that uses Node and React for the front-end and Go for streaming and scraping large .xml + .json data due to its great standard library.

With Node I can start a project wherever I would like — e.g. D:/work/node_project. Go seems to be much more opinionated on that? I opted to follow Go’s preferred directory structure and include npm related packages there, but feel I am not following best practices. Ideally, I would like to have one directory for my projects.

I will take a good look at vgo this afternoon. It removing the need for GOPATH sounds interesting. Thank you.

Re: How to start a Go project in 2018

#64

Post by apk17 »

reacharavindh wrote: post #48
nemothekid wrote: post #14

Earlier quoted context omitted.

I've been using `scratch` final builds .- FROM golang:1.10 WORKDIR /go/src/bitbucket.code.company-name.com.au/scm/code COPY ./ ./ RUN CGO_ENABLED=0 go build -a -installsuffix cgo -o /dist/main . FROM scratch COPY --from=0 /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ COPY --from=0 /go/src/bitbucket.code.company-name.com.au/scm/code/dist/main / ENTRYPOINT ["/main"] It requires a bit more "magic", but is a smaller…

Serious question: Why do you need Docker for a Go project? Cant you build it, and copy the binaries over to the host you want to run it on?

Unified deployment with your non-go containers.

Also, port and volume mapping, so the container/go binary does not need to know physical/host pathnames to data files.

Re: How to start a Go project in 2018

#65

Post by mathw »

jrockway wrote: post #47
sigjuice wrote: post #39

Earlier quoted context omitted.

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

I mean, the C toolchain has plenty of baked-in paths where it expects to find something. If project foo depends on project bar, project foo is not automatically going to look at ../bar when building. You either set that up manually, or you put everything in /usr/include and /usr/lib. "Set that up manually" usually consists of an m4 script that takes 15 minutes to run as it tries to look for all the dependencies ("./c…

But at least that makes it no harder to ask for a specific version of something.

Go not having version locks for dependencies by default is a major failing. Fortunately it looks like that will be changing.

Re: How to start a Go project in 2018

#66

Post by mathw »

nunez wrote: post #9

It’s a good thing that Go is such a good language, because getting started with it is downright PAINFUL compared to Ruby or Python.

It's so painful to get started that I'm not at all convinced the okay-ish language experience is worth it. I feel like Go was on the verge of something brilliant but managed to miss it by a couple of significant areas.

Re: How to start a Go project in 2018

#67

Post by Zekio »

dijit wrote: post #62
d4l3k wrote: post #53

Earlier quoted context omitted.

There's definitely use cases for Docker with Go that mostly revolve around running untrusted code or wanting to be able to set tight restrictions on CPU usage, memory etc. Though you could also just do the latter via cgroups. Another use case might be if you have extra files that need to be deployed with the binary as well. I wrote up some documentation about this for my use case just in case I ever have to go back a…

>There's definitely use cases for Docker with Go that mostly revolve around running untrusted code. Please don't run untrusted code in Docker, it's not designed for security. https://security.stackexchange.com/questions/107850/docker-a...

Docker containers can run in other places where they are secure, IIRC then Joyent has way to do this in their cloud

Re: How to start a Go project in 2018

#68

Post by coldtea »

baby wrote: post #61
tazjin wrote: post #56

Earlier quoted context omitted.

> However Go has 19 years on Python Go explicitly dismisses everything learned by the programming language (and tooling) community at large because its authors "know better". There really isn't much to say about Go anymore in my opinion, other than answering the title of this post with "Don't".

What tooling are they dismissing? Default tooling is pretty much inexistant in other languages.

>What tooling are they dismissing?

A proper package manager, like cargo, npm, pip, composer, maven and the like, for one.

Re: How to start a Go project in 2018

#69

Post by dingo_bat »

I tried to get into rustlang and golang but both of the languages are so opinionated about how I should structure my workspace, how I should manage dependencies that I gave up. I'm used to cmake and C/C++ where I can do whatever I lik, however I like. I have to give go a try again after reading TFA.

Re: How to start a Go project in 2018

#70

Post by zimbatm »

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 set a different GOPATH per project, and then checkout the project deep into that root. This is not convenient as a developer and as a software packager. Or give in and having to resolve dependencies that work with all the current projects. Given that Go doesn't really do package versioning, finding the right set of commits that all work together is a exponential nightmare.

Now that since Go 1.6 each project can have its own vendor/ folder, GOPATH shouldn't be required. I should be able to checkout the project where I want and then have the tools look into the vendor/ folder to resolve any dependencies. Please change it that way. The reason govendor and all these tools are complicated is because of this GOPATH madness. Synching dependencies between GOPATH and vendor/ should only be a problem for Google, not the rest of us.

Post reply on HN