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

31–40 of 118 posts

Re: Stages of learning Go, with code examples

#31

Post by zak_mc_kracken »

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.

The absence of generics makes it so that Go's composability is through copy/pasting your code while changing the types. There's even a tool to do the copy/pasting for you.

Technically, it's composability, just not the best kind.

Re: Stages of learning Go, with code examples

#32

Post by skj »

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…

This strategy means you depend on the upstream to keep the version stable. In general, URLs do not imply a stable version.

Vendoring your deps is currently the only certain way to get stable versioning.

Re: Stages of learning Go, with code examples

#33

Post by DanWaterworth »

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.

> You probably were sarcastic

I don't know that sarcastic is the correct word, but I certainly wasn't completely serious. Maybe "playfully antagonistic".

I suppose the problem I have here is, if I was designing a language, and composability was a stated goal, then I wouldn't have come up with Go.

> a brilliant article from Rob Pike about using and composing functions to create flexible APIs

I'm sorry, but that API is not something to be proud of.

Re: Stages of learning Go, with code examples

#34

Post by skj »

zak_mc_kracken wrote: post #31
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.

The absence of generics makes it so that Go's composability is through copy/pasting your code while changing the types. There's even a tool to do the copy/pasting for you. Technically, it's composability, just not the best kind.

Generics and composability are orthogonal concepts, to me. I'm not really sure what sort of composability you're talking about. Can you provide an example for me to rip apart?

Re: Stages of learning Go, with code examples

#35

Post by pjc50 »

apunic wrote: post #29
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. 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 c…

We really don't need any more binary package managers - that should be the responsibility of the platform you're deploying on. dpkg/rpm/etc on Linux systems, MSI on Windows, APK on Android, etc.

Re: Stages of learning Go, with code examples

#37

Post by NateDad »

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

Earlier quoted context omitted.

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 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 better to use something like godep to insulate you from them anyway, right?

The official solution to versioning is separate URLs. If you mean something more complicated like automatic resolution of different version specifications (e.g. ver >= 1.2), then no, nothing exists like that. But generally all you need is "project A uses version foo, and project B uses version bar", and Go supports that just fine.

Re: Stages of learning Go, with code examples

#38

Post by [deleted] »

apunic wrote: post #29
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. 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 c…

[deleted]

Re: Stages of learning Go, with code examples

#39

Post by lucaspiller »

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…

A lot of the work I do involves legacy Ruby software. Fortunately there has always been (well, since Ruby got popular) Rubygems which is equivalent to gopkg.in - I have been burned a couple of times though when authors have removed old libraries. For the last few years Bundler (http://bundler.io/) which uses Rubygems has been the standard way to lock versions of libraries, and before that vendoring was widely used.

When you pick up the maintenance of an old application you have to reinstall the dependencies from scratch if you aren't using vendoring or Bundler. Each method has their advantages and disadvantages, but both are much better than praying that the library author hasn't introduced a breaking change in a release since the library was last used.

Although it isn't the same when you are deploying Go applications, development has exactly the same issues as Ruby without locking the dependencies.

Re: Stages of learning Go, with code examples

#40

Post by howeman »

apunic wrote: post #29
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. 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 c…

The Go tool does do installation and upgrading. There's not really any configuring, and it'd be hard to do removal in any reasonable manner given how GOPATH works. What the Go tool does not do is isolate you from breaking changes upstream. For that you need someone you trust (which could be the package author or a copy of the code in gopkg.in), or be willing to fix breaking changes (which I do quite often).
Post reply on HN