Stages of learning Go, with code examples • Hacker News Board

Re: Stages of learning Go, with code examples

#41

Post by copsarebastards » Wed, Feb 25, 2015, 3:15 PM UTC

NateDad wrote: post #21

bonn1 wrote: post #5

Just wondering, does Go finally has a package manager with proper versioning of modules? Edit: Somebody is heavily downvoting me on every reply, I would love to know why. I like Go and want to get into it since a few months but the missing package manager held me off. So what is wrong about my question?

You really don't need a package manager for Go. Honestly, the main reason you need them for node, python, etc is because you're deploying source code to your production environment. You don't do that with Go. You deploy a binary, which has everything wrapped up in itself. Think of it as a self-contained virtualenv that requires zero effort on your part :) In Go, code is packaged via source control repos. If you want…

> You really don't need a package manager for Go.

"You really don't need X for Go" is becoming the Go community catchphrase. And they're right: I won't need anything for Go because I wouldn't use a language whose community actively resists improvement.

I could respect that Go doesn't have a package manager, generics, etc., if the Go community took more of a "if you want it, develop it" approach. But instead, the core development team has made it unclear whether they would even accept some of these features. I get that compilation performance is a high priority, but they've missed the big picture, that developer time also matters.

The following exemplifies the problem:

> Note that because Go is a compiled language, the only time versioning comes into play is a development time.

Oh, that won't affect me at all; development time is only like 90% of the life of a project.

Re: Stages of learning Go, with code examples

#42

Post by tveita » Wed, Feb 25, 2015, 3:19 PM UTC

NateDad wrote: post #21

bonn1 wrote: post #5

Just wondering, does Go finally has a package manager with proper versioning of modules? Edit: Somebody is heavily downvoting me on every reply, I would love to know why. I like Go and want to get into it since a few months but the missing package manager held me off. So what is wrong about my question?

You really don't need a package manager for Go. Honestly, the main reason you need them for node, python, etc is because you're deploying source code to your production environment. You don't do that with Go. You deploy a binary, which has everything wrapped up in itself. Think of it as a self-contained virtualenv that requires zero effort on your part :) In Go, code is packaged via source control repos. If you want…

I would classify godep as a package manager in the same vein as bundler, pip, npm, etc., and in my experience it is absolutely essential if you still want your Go code to compile a month after you wrote it.

I think the bit about source versus binary deployment is a bit of a red herring. It's not like any true Scotsman is deploying by running pip update in production either. As a developer you want to have code that compiles at all times. Having a binary you can't reproduce or change isn't going to be much comfort.

If you're going to use third party libraries there is no reliable way to judge the stability of either the libraries you use directly or all your transitive dependencies. Pull in enough dependencies and the chance of a conflict approaches one. Some of your dependencies will get updated and some of them won't, and soon enough you'll have a hard time finding any combination of versions that will compile.

Dependency management is not optional, but unfortunately Go makes it easy to hurt yourself by providing climbing holds without a safety harness. It isn't obvious to new programmers that they should use godep before they come back to an older project and it won't compile anymore.

Re: Stages of learning Go, with code examples

#43

Post by copsarebastards » Wed, Feb 25, 2015, 3:37 PM UTC

cjslep wrote: post #26

moe wrote: post #25

Earlier quoted context omitted.

There is countless proof about Go's composability through functions and interface I can't tell if you're serious or sarcastic yourself. The article proposes this snippet, presumably copy/pasted for every option: // Verbosity sets Foo's verbosity level to v. func Verbosity(v int) option { return func(f *Foo) option { previous := f.verbosity f.verbosity = v return Verbosity(previous) } } If that's what Go composability…

> presumably copy/pasted for every option To be fair, there is "go generate" now that can generate functions that would otherwise require tedious copy/pasting. If you are familiar with the preprocessor in C++ expanding template definitions, this tool can provide similar functionality but is more generalized. I think embedding [0] is the real big composability win in Go. [0] https://golang.org/doc/effective_go.html#em…

> To be fair, there is "go generate" now that can generate functions that would otherwise require tedious copy/pasting. If you are familiar with the preprocessor in C++ expanding template definitions, this tool can provide similar functionality but is more generalized.

Comparing to C++ templates is a rather generous comparison. C++ templates provide a rich type system that allows type checking and prevents errors, and integrates with the rest of C++'s type system.

Go generate is a lot closer to C/C++ macros, the only improvement being that the generation is done in a turing-complete language instead of by text substitution.

In C-like languages this problem is typically solved with generics, but the go team has decided to ignore 20+ years of language development and try the same thing that didn't work so many times that it motivated the creation of generics.

"But," you say, "Generics slow down compilation!" To which I respond that the first step to compiling code is creating code that does something worth compiling.

Re: Stages of learning Go, with code examples

#44

Post by jerf » Wed, Feb 25, 2015, 3:38 PM UTC

eddieroger wrote: post #28

NateDad wrote: post #21

Earlier quoted context omitted.

You really don't need a package manager for Go. Honestly, the main reason you need them for node, python, etc is because you're deploying source code to your production environment. You don't do that with Go. You deploy a binary, which has everything wrapped up in itself. Think of it as a self-contained virtualenv that requires zero effort on your part :) In Go, code is packaged via source control repos. If you want…

I'm on board with this answer, and it makes sense to me, but it's competing in my head with the idea of always being able to do a clean build from master that could deploy whenever. Let's say you have a catastrophic failure and lose your binary repo and need to rebuild (and your backups, etc - it's an example) - if your dependencies have changed in the meanwhile, you can't redeploy to where you were. Obviously that s…

"but that doesn't feel like a legitimate excuse to not have some safeguard in place to make sure your build environment doesn't change on you."

If your build process downloads anything from the Internet, your build environment can change on you. Networks can always fail. At best you can detect this occurring and have your build process scream and die, but it can't be fixed.

Note the complete lack of the word "Go" in the previous paragraph. If other languages provide package managers that make it easy to download code from the Internet during your build process, they are tempting you to do wrong things. You should be in personal possession of everything you need to do a full build, whatever that may be (source or otherwise). And, again, note the complete lack of the word "Go" in that sentence.

This has nothing to do with Go. If you are depending on package managers to download your code from external sites during a build, stop reading this right now and GO FIX THAT. Seriously. Someday it will bite you, hard.

And may Turing & Knuth help you if you're downloading packages with unpinned versions that can just upgrade to whatever they want, whenever they want.

Now I will actually use "Go" in a sentence. The fact that Go expects you to vendor your source I do not consider a problem with the language. The fact that it fails to ship with a blessed tool for doing so is a potentially legitimate criticism, but the fact that it fails to ship with a tool that begs you to do the easy, wrong thing is a feature, not a bug. I wouldn't be surprised that they eventually bless something out of the community. Godep seems to be the current leader. Personally I can't recommend or anti-recommend any of them, I've just been vendoring by hand since I'm only using a handful of libraries, and the cost/benefit hasn't worked out in favor of learning something to save me mere minutes of effort. I know where to find solutions if that ratio ever changes.

Re: Stages of learning Go, with code examples

#45

Post by ptio » Wed, Feb 25, 2015, 3:39 PM UTC

bonn1 wrote: post #5

Just wondering, does Go finally has a package manager with proper versioning of modules? Edit: Somebody is heavily downvoting me on every reply, I would love to know why. I like Go and want to get into it since a few months but the missing package manager held me off. So what is wrong about my question?

https://github.com/pote/gpm

Re: Stages of learning Go, with code examples

#46

Post by jerf » Wed, Feb 25, 2015, 3:44 PM UTC

copsarebastards wrote: post #41

NateDad wrote: post #21

Earlier quoted context omitted.

You really don't need a package manager for Go. Honestly, the main reason you need them for node, python, etc is because you're deploying source code to your production environment. You don't do that with Go. You deploy a binary, which has everything wrapped up in itself. Think of it as a self-contained virtualenv that requires zero effort on your part :) In Go, code is packaged via source control repos. If you want…

> You really don't need a package manager for Go. "You really don't need X for Go" is becoming the Go community catchphrase. And they're right: I won't need anything for Go because I wouldn't use a language whose community actively resists improvement. I could respect that Go doesn't have a package manager, generics, etc., if the Go community took more of a "if you want it, develop it" approach. But instead, the core…

The community does not resist improvement. The community asks that you acquire some experience, work with what is there, make sure that you understand it, then suggest improvements.

The community definitely does resist people who aren't even users loudly declaring exactly what it is that Go needs. I fear the community may have instinctively built up certain callouses that I'm not a big fan of, such as the near inability to have a sensible discussion about generics within the community due to the near inability to have a sensible discussion about generics outside of the community. It isn't all necessarily hunky-dory.

But if you haven't used Go, which is what it sounds like to me, you don't understand the current situation's cost/benefit analysis and are unlikely to be able to "just" "solve" the community's "problems" without such an understanding.

Step 1 of any engineering effort is identify the problem, and it can never be skipped, no matter how sure you are you can this time. If you're not a Go user, you've skipped this step.

Of course you're free to A: not be a Go user for any reason you choose and B: say whatever you like about Go from the outside. And I really mean that, quite deeply, not merely as a rhetorical flourish. There's too many languages to become expert in them all and we all must choose carefully according to our own knowledge and desires. My only point here is only that you shouldn't expect the community to be enthralled with the resulting commentary.

Re: Stages of learning Go, with code examples

#47

Post by grey-area » Wed, Feb 25, 2015, 3:45 PM UTC

NateDad wrote: post #37

grey-area wrote: post #30

Earlier quoted context omitted.

Sure it's possible with third party tools (in this case gopkg.in), and if all your required packages support this. As gopkg.in is a centralised service I'm not so keen on that solution (same problems and potential pitfalls as relying on say rubygems.org as a source of truth). There are multiple ways to solve these problems (vendoring is one, your solution another, godep another path), but the go get tool doesn't expl…

The point about gopkg.in being centralized is valid. You can run a copy yourself (it's open source), or you can use a more simplistic version that many people use which doesn't even require running a service, just serving some static HTML. This obviously only works for code you're maintaining. However, if you think code you're depending on isn't maintained by people you can trust not to break you, it's probably bette…

However, if you think code you're depending on isn't maintained by people you can trust not to break you, it's probably better to use something like godep to insulate you from them anyway, right?

That goes for most code at some point in time; as it evolves the behaviour changes in subtle ways. I do think the go team's insistence that packages should never break their API and remain effectively versionless is somewhat utopian.

The official solution to versioning is separate URLs.

I remember reading an off-hand comment from someone on the go team that you could just rename your package, however I don't think that's a very good idea, and this doesn't play nicely with many popular hosts like github. They have support for version tags on repos in go get, but only for golang versions so it is unused, which is a shame. So there's no official tooling for it. At present the majority of go code I've seen simply imports dependencies from github or similar without versioning and hopes for the best. Unless the other pkg author wants to version, that's all you can do unless you want to vendor (for large dependencies like net/html that can be impractical).

If you mean something more complicated like automatic resolution of different version specifications (e.g. ver >= 1.2), then no, nothing exists like that.

That's what the parent was asking for I think, and more than that something which applies to all pkgs. Personally I've chosen to minimise external dependencies, and vendor them in version control. It's simple, and it pus me in control of updating and versioning for code I use, not the package authors.