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

101–110 of 117 posts

Re: How to start a Go project in 2018

#101

Post by heavenlyhash »

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…

Try this: https://github.com/warpfork/gof

It's pretty easy to declare a GOPATH that's local to your project. I've been quietly doing it for years. The linked repo is just one short shell script that helps do it (on any project; you don't even have to commit the script, and it doesn't change how anyone else develops).

Frankly, I think every highly-productive gopher outside the Google offices uses some form or another of this. It's unpopular to say it and goes against "the community" zeitgeist, but many people will admit it in private if you ask around.

My biggest complaint about the current state of Go dependency management is actually the vendor dir. We never needed it; project-local GOPATH is enough in the first place. Now, we just get the headaches when both exist and are in conflict, or one provides something that should've been in the other (not a problem, until you push, and someone else on the team has to tell you that you didn't vendor enough...)

Re: How to start a Go project in 2018

#102

Post by jerf »

KyeRussell wrote: post #99
jerf wrote: post #97

Earlier quoted context omitted.

With all due respect to the Python community, and without intending this as an insult per se, if this really is the "current recommendation", the Python community is in no position to be criticizing the Go community on this point. This is about the fourth answer I've heard in the past 10 years. I've been programming off and on in Python for at least 15 years and I've never heard of this tool. Out of morbid curiosity,…

Am I meant to justify all Python-related decisions because I choose to work with it? Does my using Python (or even my membership in 'The Python Community') disqualify me from critiquing on other languages and development environments? What does your comment add to the discussion other than snark and aggression?

A correction to people claiming that Python's obviously got a better solution to dependency management than Go, a solution so "obvious" that a Python programmer of 15+ years hasn't heard of it yet. (No, I'm not actively programming in Python right now, but if it's so obvious and concrete I should still have known about it. I was up-to-date on best practices as of a couple of years ago!)

You aren't obligated to do anything; the question is open to anybody.

Re: How to start a Go project in 2018

#103

Post by ovao »

brunoluiz wrote: post #88
ovao wrote: post #44

Earlier quoted context omitted.

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)

If your application requires multiple servers running multiple domains, you're probably better off with a microservice architecture.

Re: How to start a Go project in 2018

#104

Post by mixmastamyk »

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?

You don't. Perhaps they need to fit a square peg into a rectangular hole.

Re: How to start a Go project in 2018

#105

Post by MehdiHK »

Can_Not wrote: post #92
rubenv wrote: post #77

Earlier quoted context omitted.

It's a blessing when you want to start a new project while offline (e.g. on a plane or train). All your usual dependencies are already there, ready to use. Not that it justifies any pain, just found it to be a pleasant side-effect. Sometimes it's worthwhile to just give in and try something new, even if you don't like it. You might discover unexpected advantages. Then go back to what you prefer and apply those lesson…

You could have a global cache folder instead of a global vendor folder.

Exactly. Both yarn and npm cli support this for nodejs.

Re: How to start a Go project in 2018

#106

Post by rco8786 »

Can_Not wrote: post #91
rco8786 wrote: post #87

Earlier quoted context omitted.

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.

How is it the opposite of npm?

All of the reasons I listed...?

Re: How to start a Go project in 2018

#107

Post by mixmastamyk »

jerf wrote: post #102
KyeRussell wrote: post #99

Earlier quoted context omitted.

Am I meant to justify all Python-related decisions because I choose to work with it? Does my using Python (or even my membership in 'The Python Community') disqualify me from critiquing on other languages and development environments? What does your comment add to the discussion other than snark and aggression?

A correction to people claiming that Python's obviously got a better solution to dependency management than Go, a solution so "obvious" that a Python programmer of 15+ years hasn't heard of it yet. (No, I'm not actively programming in Python right now, but if it's so obvious and concrete I should still have known about it. I was up-to-date on best practices as of a couple of years ago!) You aren't obligated to do any…

The original post says golang should be a bit better starting twenty years later.

Pipenv has only existed a year or two, qed.

Re: How to start a Go project in 2018

#109

Post by d4l3k »

dijit wrote: post #74
Zekio wrote: post #67

Earlier quoted context omitted.

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

You havent refuted my point. People take a stance that docker can run untrusted code without actually looking at what they have to do for that to be true.

I haven't taken the stance that all docker containers can run untrusted code, but I've certainly done my best to harden my docker containers as much as possible. If you took a look at that write up I cover it.

I run with the flags: --net=none --cap-drop=all --cpus=1 --read-only --tmpfs=/tmp:rw,size=1g,mode=1777,noexec

This gives it no way to communicate with the outside world and drops all capabilities so it's not allowed to interact with the kernel at all. Setting CPU limit to be 1 also prevents DOS attacks internally.

I also run the process under the nobody user which entirely avoids the "container root is system root" issue.

I'm also only sort of running "untrusted" code. I'm running tensorflow models which can do arbitrary computation but are more secure than just running raw code.

Re: How to start a Go project in 2018

#110

Post by goobynight »

dingo_bat wrote: post #69

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.

They're opinionated because they're designed to be used by large teams building large software for a corporation.

In these environments, you usually end up with an opinion anyway, so they built it right in, so people could skip the debate stage.

Post reply on HN