Live data from Hacker News

How to start a Go project in 2018

boyter.org

71–80 of 117 posts

Re: How to start a Go project in 2018

#71

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.

>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.

The second is a problem. The first is bike-shedding (and Go doesn't really force anything -- you could just use e.g. a Makefile, and have your Go files wherever you want. You only need to follow the directory structure convention if you want go build, go install etc to work out of the box).

Re: How to start a Go project in 2018

#72
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 a good thing that Go is such a good language

Well, not that good. Decent would be the best one could say. It has many special cases and warts, and lacks a few very standard features. But let's not get into that here.

>because getting started with it is downright PAINFUL compared to Ruby or Python

If you mean regarding package management, maybe. In other terms, not really painful at all. It's one of the easiest languages to just download, code, and build your code -- you can even cross-compile with like 2 extra ENV settings.

Re: How to start a Go project in 2018

#73
post #66
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.

Painful to get started in which way?

Is this about being used to dynamic programming and not groking types and "pointers" in Go?

About the tooling?

About the lack of certain features like generics?

Re: How to start a Go project in 2018

#74
post #67
post #62

Earlier quoted context omitted.

>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

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.

Re: How to start a Go project in 2018

#76
post #68
post #61

Earlier quoted context omitted.

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.

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

Re: How to start a Go project in 2018

#77
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…

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 lessons there.

Everything would be much better if we all kept an open mind and learned from each-others experiences. It might not always be obvious, but things are usually a certain way for a good reason. Might not be the best or right reason in the long run, but there's always some lesson to be learned.

Re: How to start a Go project in 2018

#78

Nice summary. The biggest pain with Go is the dependency management. I initially started to commit the whole vendor folder for each project, but lately I only commit the Gopkg.lock and Gopkg.toml Both those approaches bothered me over time and I'm still undecided about what's the best way to do this. I know some projects only commit their Gopkg.toml (and not lock) with some explicit dependencies.

This is not a "Go thing" though. The only difference is that in most go projects vendoring the whole folder is actually quite easy.

I've just started to check in vendor/ for my current project. It's nice to know that all the code is "locked" in git and that a git clone is all you need to get all the dependencies. OTHE, it creates more work and force you to take a more active role in dealing with dependencies. But it gives you more control.

Re: How to start a Go project in 2018

#79
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…

And in an astonishing piece of timing, the author of dep has posted an analysis of vgo: https://news.ycombinator.com/item?id=17063724

Re: How to start a Go project in 2018

#80

I'd add: One you set it up, document exactly that setup in readme. If you use something specific for dep management, document it. If not, document it. Document how to run tests. Document everything... At work I often run into issues with "random project X on GitHub" and do a bit of drive-by fixes. But many times when I find some Go project, I have no idea how to get from a fresh repo to running tests. And if that req…

I'd say this is true for all projects tbf; set up a readme, type what you need to know and how to run the project in dev mode. Shouldn't take more than five minutes to type out, or copy / pasted from another project.
Post reply on HN