Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stages of learning Go, with code examples

sourcegraph.com

Post reply on HN
Print view View original

21–30 of 118 posts

Re: Stages of learning Go, with code examples

#21

Post by NateDad »

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 a different version, you need a different repo. There are some tools to mitigate this, so that you can get away with a different branch per version (see http://gopkg.in), which can make it a little nicer for the maintainer to deal with multiple branches. To the consumer, it still looks like a different repo (i.e. every different version is a different URL to a repo).

Note that because Go is a compiled language, the only time versioning comes into play is a development time. As long as your developers are using the right version, you never have to worry about versions during deployment.

Now, if you're concerned that your project depends on code repos from external sources, then there are several tools that can insulate you from third parties doing stupid stuff. The most complete and best one is called godep, which basically has two modes - reliable and paranoid. The reliable mode insulates you from changes made to a repo you depend on by recording the exact VCS revision your project is using and always checks out that commit. That way, if an upstream repo checks in a breaking change, it won't affect you (and you control when you update to newer commits in that repo). Paranoid mode actually copies all the code from your dependencies into your own repo. This insulates you from upstream repos getting deleted. And of course, this gives you the ability to test out upstream changes before integrating them into your project. The tool makes it easy to copy all of your dependencies at once with a single command, so it's not a huge hassle to do (which it would be if you had to do it by hand).

Re: Stages of learning Go, with code examples

#22

Post by NateDad »

grey-area wrote: post #16
bonn1 wrote: post #9

Earlier quoted context omitted.

Thanks. And how can I define the version of the module which should be imported?

You can't. You are expected to vendor for dependable builds. This has upsides and downsides. It does completely sidestep version dependencies hell and encourages you to think carefully about which dependencies you package. It does that by making you manually responsible for keeping dependencies up to date if you distribute other people's code with your own. So, in answer to your original question, no go doesn't final…

Yes, you can. The URL is the version. If you want a different version, you need a different url.

For example, when I released v1 of my package "lumberjack" you imported it with

    import "github.com/natefinch/lumberjack"
When I updated it to v2, I had to change the url. Luckily there's http://gopkg.in to make this easy, so for v2 it's

    import "gopkg.in/natefinch/lumberjack.v2"
Note that the above url actually redirects to the v2 branch of the same github repo.

Re: Stages of learning Go, with code examples

#23

Post by Intermernet »

[deleted] wrote: post #18

[deleted]

By "functional", do you mean "The language functions for my needs" or "A Functional programming [1] language"?

I'm pretty sure Go was never designed to be the latter, and the former is a matter of personal preference.

[1]: http://en.wikipedia.org/wiki/Functional_programming

Re: Stages of learning Go, with code examples

#25

Post by moe »

1_player wrote: post #17
DanWaterworth wrote: post #13

> Phase 4 (the expert): You understand the design choices and motivations behind the language. You grok the philosophy of simplicity and composability. In what way is Go code composable?

You probably were sarcastic, but in case you are not there's a brilliant article from Rob Pike about using and composing functions to create flexible APIs: http://commandcenter.blogspot.co.uk/2014/01/self-referential... There is countless proof about Go's composability through functions and interface, but I keep coming back to that one document.

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 looks like then...uh... No thanks.

Re: Stages of learning Go, with code examples

#26

Post by cjslep »

moe wrote: post #25
1_player wrote: post #17

Earlier quoted context omitted.

You probably were sarcastic, but in case you are not there's a brilliant article from Rob Pike about using and composing functions to create flexible APIs: http://commandcenter.blogspot.co.uk/2014/01/self-referential... There is countless proof about Go's composability through functions and interface, but I keep coming back to that one document.

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#embedding

Re: Stages of learning Go, with code examples

#27

Post by moe »

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…

go generate

Ugh. Sounds like Go is turning into a language that I'll want to avoid in the future. There is no excuse for code generators. Friends don't let friends generate code.

I think embedding [0] is the real big composability win in Go.

This looks indeed more sensible.

Re: Stages of learning Go, with code examples

#28

Post by eddieroger »

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'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 scenario should be well prevented, 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.

Re: Stages of learning Go, with code examples

#29

Post by apunic »

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. Honestly, the main reason [...] is because you're deploying source code to your production environment

Not sure if I would agree with that. A full-fledged package manager automates the process of installing, upgrading, configuring and removing software packages in a consistent manner. Dependency management and semantic versioning is an important part to provide this consistency. Wether you deploy source code or binaries does not make any difference why a package manager is always good to have.

Re: Stages of learning Go, with code examples

#30

Post by grey-area »

NateDad wrote: post #22
grey-area wrote: post #16

Earlier quoted context omitted.

You can't. You are expected to vendor for dependable builds. This has upsides and downsides. It does completely sidestep version dependencies hell and encourages you to think carefully about which dependencies you package. It does that by making you manually responsible for keeping dependencies up to date if you distribute other people's code with your own. So, in answer to your original question, no go doesn't final…

Yes, you can. The URL is the version. If you want a different version, you need a different url. For example, when I released v1 of my package "lumberjack" you imported it with import "github.com/natefinch/lumberjack" When I updated it to v2, I had to change the url. Luckily there's http://gopkg.in to make this easy, so for v2 it's import "gopkg.in/natefinch/lumberjack.v2" Note that the above url actually redirects t…

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 explicitly allow for versioning in the way the parent requested and there is no official solution to this.

Post reply on HN