13 ms·

Stages of learning Go, with code examples

170 points by beliu 12y ago

Animats 12y ago
It's a tool, not a religion. Don't try to turn it into a cult.
- campoy 12y ago
  As the speaker I couldn't agree more, actually check slide 39 https://speakerdeck.com/campoy/gophercon-india-evolution-of-a-gopher?slide=39 https://speakerdeck.com/campoy/gophercon-india-evolution-of-...
- deleted 12y ago
  [deleted]
- nexneo 12y ago
  And like all tools, use where it makes sense. I think that is Go's one of the strength, it's friendly to Polyglot setup. I gave talk that conveys similar sentiment. Slide: https://speakerdeck.com/nexneo/joy-of-single-purpose-services-in-go?slide=6 https://speakerdeck.com/nexneo/joy-of-single-purpose-service...
- CatDevURandom 12y ago
  Where are you reading into that?
- cicero 12y ago
  It's natural to get excited when you find a tool that fits you well and solves problems you had encountered with other tools. People are different, as are their needs, and so one person's excitement over a tool might not make sense to others. If you don't get someone else's enthusiasm, that is nothing to be afraid of.
bonn1 12y ago
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?
- Skunkleton 12y ago
  I don't have a ton of experience with go, just some one off internal tools development, only a few dependencies. That said, I chose to manage my dependencies manually by making a fork of the relevant repositories. Yeah, it would have been nice if the higher order dependencies were automatically resolved, but the whole thing went smoothly, and felt familiar since it had nothing to do with Go at all. Maybe the take away is that a language agnostic dependency manager is what would best benefit Go?
  - EugeneOZ 12y ago
    And how you follow minor version updates with your forked repos?
- bbrazil 12y ago
  The closest is godep, which lets you take snapshots. We're having lots of fun with this with Prometheus, quite a bit of work is ongoing to get it into Debian due to this for example.
  - bonn1 12y ago
    And do these package managers provide a full ecosystem where all Go libraries/modules are available like e.g. npm does?
    - campoy 12y ago
      All Go packages can be found on godoc.org Installed with "go get" And if you want to vendor the dependencies use godep.
      - bonn1 12y ago
        Thanks. And how can I define the version of the module which should be imported?
        12y ago
DanWaterworth 12y ago
> 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?
- campoy 12y ago
  There's long articles and talks about the topic. Check this one: https://vimeo.com/53221560 https://vimeo.com/53221560
- 1_player 12y ago
  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-functions-and-design.html 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.
  - moe 12y ago
    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.
    - cjslep 12y ago
      > 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 https://golang.org/doc/effective_go.html#embedding
deleted 12y ago
[deleted]
- unedjumacated 12y ago
  What if you start out with functional languages because non-functional ones are too difficult for you for variety of reasons?
- Intermernet 12y ago
  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 http://en.wikipedia.org/wiki/Functional_programming
runeb 12y ago
Can someone recommend some good books on Go?
- ardan-bkennedy 12y ago
  I am writing the Go In Action book. Send me an email to bill@ardanstudios.com and I will send you a few things on the book.
- percept 12y ago
  http://dave.cheney.net/resources-for-new-go-programmers http://dave.cheney.net/resources-for-new-go-programmers
- kingmanaz 12y ago
  Summerfield's "Programming in Go" is several years old but still the best I've come across. Below is a review regurgitated from Barnes and Noble if you're interested: ...The author spends his time away from the libraries, covering the core of the language. By the nature of this approach the matter is dense, but it also gives the author ample time to discuss best practices, for instance: "...[i]ncidentally it is a Go convention that functions that have channel parameters have the destination channels first, followed by the source channels [in the function definition]..." Many of these best practices stem from conventions found in Go's own source code, which happily, the author is well acquainted with. Learning a language by isolating its syntax and analysing idioms and conventions is effective for those willing to persevere, and "Programming in Go" abounds in such detail. Ideally, "Programming in Go" should be paired with a textbook which focuses on use-cases. Balbaert's "The Way to Go" is such a book, but sadly, is not nearly so well written as Summerfield's. In any case, "Programming in Go" is the book for those searching for a solid understanding of Go's fundamentals.
copsarebastards 12y ago
> Don’t wait until you become an expert in the language to make your voice heard. You can do anything! https://www.youtube.com/watch?v=gSjLiQxEZlM https://www.youtube.com/watch?v=gSjLiQxEZlM
coldtea 12y ago
Where does this idiotic idea cames from that being "idiomatic" is some kind of virtue? Idiomatic Java was the FactoryProxySingleton EE-wank fest from Apache, SUN, Spring and co. It was by changing those idioms around (e.g. how the Play framework wrote Java), that saner alternatives emerged. The de-facto idiom of PHP before 2010 was messy code. It started getting more coherent after that, but the preffered idiom now (e.g. for Zend, Synmphony, Laravel) is still a tedious, verbose, copy of the Java circa 2006 style (large class hierarchies, singletons, "Facades", DI, etc). Idiomatic JS pre-Cockford was ad-hoc BS. After Cockford it got a lot better, but then it changed again (can't say for the worse) with all sort of functional tricks and patterns that weren't in vogue before. In all of those cases, if they have stuck to the same "idiomatic" way from the start, it would have been worse. Within a single project, sure, enforce some idiomatic way of doing things. But within a whole language people should be able to experiment and not be called upon for being "unidiomatic" all the time. This is exceptially disturbing and often in Go, where there's some cargo cult in many advocates that they have found the be-all end-all way to code. It seems to me this push for "idiomatic" is also related to the Blub paradox. Blub programmers know a couple of ways of doing things (the "idioms" of their language) and cannot understand why someone might want to program with higher (or just different but convenient) concepts he learned in another language.
- disputin 12y ago
  The lower the standard of your team, the more you will appreciate idiomatic code. I don't work in SV, blue chips, or anywhere that could use Scala. A couple of us at my last place had a hard time moving the team from Source Safe to SVN, Git was out of the question. "What's the point of commit messages if you only commit every three months?" - not kidding, not a junior. Lines thousands of characters long, literally. I saw a pattern once. Once. CIO was one of these copy/paste VB devs, common in London, an unfair generalisation, but necessary as a warning sign. Some people become developers without any interest in development, completely oblivious to *nix/open source world, simply as a job, 9 - 5, and might have flipped a coin between development and accountancy. Some places don't give a shit about software development, or the idea of engineering - "just get it done!". Resharper, fxcop? Yeah, right. Degrees don't all teach compiler design, some just Java OO and a bit of Glassfish. If Go replaced C# in all of these arbitrary SMEs there would be far fewer WTFs. But people would struggle without Visual Studio debugging and a big run button. I'm being harsh, and seriously, not suggesting anything about MS devs, who include the world's best as well as the world's worst, but I find people on this site are often, to their fortune, oblivious to what working in the 99% can be like (the figurative 99%). Long live idioms, gofmt, golint.
tgeery 12y ago
If they just made the page wider, I might be able to read their code samples with minimal effort...
politician 12y ago
What do GOPATH, the project folder structure, package management, and package versioning all have in common? The go command. Not the linker, not the compiler -- the `make` replacement. If you want to fix the most broken parts of Go -- its ecosystem management tooling -- just replace your `go` command. I have, and I love working on a project with a proper top-level src folder, with vendor-able packages discoverable in a top-level lib folder pinned to known-good commits. There are literally dozens of go replacements, but the winning combination for me is using Goop [1], Makefiles, and symlinks to subvert `go get` and the naive way it parses import declarations [2]. [1] https://github.com/nitrous-io/goop https://github.com/nitrous-io/goop [2] https://golang.org/ref/spec#Import_declarations https://golang.org/ref/spec#Import_declarations
- NateDad 12y ago
  You don't have to replace the go command to do that. The only thing that needs the GOPATH and expects import paths to be URLs is "go get". You can very easily make a go project that uses all relative import paths and put it anywhere you like. Dependencies then just get copied into whatever path you like using whatever name you like. However, your code will be unusable by anyone who follows the normal Go way of coding, so you'll be missing out on working with the rest of the community. If you're writing proprietary software, that might not matter too much. But if you're writing open source code, it will be a huge hindrance to getting contributions from outsiders.
  - politician 12y ago
    > However, your code will be unusable by anyone who follows the normal Go way of coding. Well, that's not really true given the major projects using tools like Godeps [1], so while that argument certainly sounds good, it doesn't actually seem to be a problem in practice. [1] https://coreos.com/blog/godep-for-end-user-go-projects/ https://coreos.com/blog/godep-for-end-user-go-projects/
    - NateDad 12y ago
      Actually, CoreOS is using the version of godep that rewrites import paths, so that most developers can use "go get". The only time you need to use godep is when you're updating one of the vendored dependencies. That's actually the awesome thing about godep - it keeps your repo go-getable. > the simplicity it presents to regular contributors and users used to go get make it worth the additional effort
kylequest 12y ago
"If you think the Go standard library is not powerful enough to do what you want to do, you might be wrong." or not... The standard libraries are not perfect. They do have very useful building blocks, but they are far from complete or perfect. Take the http library, for example. There's no built-in context: type HandlerFunc func(ResponseWriter, Request) type Handler interface { ServeHTTP(ResponseWriter, Request) } This resulted in a complete mess when it comes to http middleware because everybody is solving the context problem their own way (including google itself).

170 points by beliu 12y ago

Animats 12y ago

It's a tool, not a religion. Don't try to turn it into a cult.

campoy 12y ago
As the speaker I couldn't agree more, actually check slide 39 https://speakerdeck.com/campoy/gophercon-india-evolution-of-a-gopher?slide=39 https://speakerdeck.com/campoy/gophercon-india-evolution-of-...
deleted 12y ago
[deleted]
nexneo 12y ago
And like all tools, use where it makes sense. I think that is Go's one of the strength, it's friendly to Polyglot setup. I gave talk that conveys similar sentiment. Slide: https://speakerdeck.com/nexneo/joy-of-single-purpose-services-in-go?slide=6 https://speakerdeck.com/nexneo/joy-of-single-purpose-service...
CatDevURandom 12y ago
Where are you reading into that?
cicero 12y ago
It's natural to get excited when you find a tool that fits you well and solves problems you had encountered with other tools. People are different, as are their needs, and so one person's excitement over a tool might not make sense to others. If you don't get someone else's enthusiasm, that is nothing to be afraid of.

bonn1 12y ago

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?

Skunkleton 12y ago
I don't have a ton of experience with go, just some one off internal tools development, only a few dependencies. That said, I chose to manage my dependencies manually by making a fork of the relevant repositories. Yeah, it would have been nice if the higher order dependencies were automatically resolved, but the whole thing went smoothly, and felt familiar since it had nothing to do with Go at all. Maybe the take away is that a language agnostic dependency manager is what would best benefit Go?
- EugeneOZ 12y ago
  And how you follow minor version updates with your forked repos?
bbrazil 12y ago
The closest is godep, which lets you take snapshots. We're having lots of fun with this with Prometheus, quite a bit of work is ongoing to get it into Debian due to this for example.
- bonn1 12y ago
  And do these package managers provide a full ecosystem where all Go libraries/modules are available like e.g. npm does?
  - campoy 12y ago
    All Go packages can be found on godoc.org Installed with "go get" And if you want to vendor the dependencies use godep.
    - bonn1 12y ago
      Thanks. And how can I define the version of the module which should be imported?
      - 12y ago

DanWaterworth 12y ago

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

campoy 12y ago
There's long articles and talks about the topic. Check this one: https://vimeo.com/53221560 https://vimeo.com/53221560
1_player 12y ago
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-functions-and-design.html 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.
- moe 12y ago
  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.
  - cjslep 12y ago
    > 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 https://golang.org/doc/effective_go.html#embedding

deleted 12y ago

[deleted]

unedjumacated 12y ago
What if you start out with functional languages because non-functional ones are too difficult for you for variety of reasons?
Intermernet 12y ago
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 http://en.wikipedia.org/wiki/Functional_programming

runeb 12y ago

Can someone recommend some good books on Go?

ardan-bkennedy 12y ago
I am writing the Go In Action book. Send me an email to bill@ardanstudios.com and I will send you a few things on the book.
percept 12y ago
http://dave.cheney.net/resources-for-new-go-programmers http://dave.cheney.net/resources-for-new-go-programmers
kingmanaz 12y ago
Summerfield's "Programming in Go" is several years old but still the best I've come across. Below is a review regurgitated from Barnes and Noble if you're interested: ...The author spends his time away from the libraries, covering the core of the language. By the nature of this approach the matter is dense, but it also gives the author ample time to discuss best practices, for instance: "...[i]ncidentally it is a Go convention that functions that have channel parameters have the destination channels first, followed by the source channels [in the function definition]..." Many of these best practices stem from conventions found in Go's own source code, which happily, the author is well acquainted with. Learning a language by isolating its syntax and analysing idioms and conventions is effective for those willing to persevere, and "Programming in Go" abounds in such detail. Ideally, "Programming in Go" should be paired with a textbook which focuses on use-cases. Balbaert's "The Way to Go" is such a book, but sadly, is not nearly so well written as Summerfield's. In any case, "Programming in Go" is the book for those searching for a solid understanding of Go's fundamentals.

copsarebastards 12y ago

> Don’t wait until you become an expert in the language to make your voice heard. You can do anything! https://www.youtube.com/watch?v=gSjLiQxEZlM https://www.youtube.com/watch?v=gSjLiQxEZlM

coldtea 12y ago

Where does this idiotic idea cames from that being "idiomatic" is some kind of virtue? Idiomatic Java was the FactoryProxySingleton EE-wank fest from Apache, SUN, Spring and co. It was by changing those idioms around (e.g. how the Play framework wrote Java), that saner alternatives emerged. The de-facto idiom of PHP before 2010 was messy code. It started getting more coherent after that, but the preffered idiom now (e.g. for Zend, Synmphony, Laravel) is still a tedious, verbose, copy of the Java circa 2006 style (large class hierarchies, singletons, "Facades", DI, etc). Idiomatic JS pre-Cockford was ad-hoc BS. After Cockford it got a lot better, but then it changed again (can't say for the worse) with all sort of functional tricks and patterns that weren't in vogue before. In all of those cases, if they have stuck to the same "idiomatic" way from the start, it would have been worse. Within a single project, sure, enforce some idiomatic way of doing things. But within a whole language people should be able to experiment and not be called upon for being "unidiomatic" all the time. This is exceptially disturbing and often in Go, where there's some cargo cult in many advocates that they have found the be-all end-all way to code. It seems to me this push for "idiomatic" is also related to the Blub paradox. Blub programmers know a couple of ways of doing things (the "idioms" of their language) and cannot understand why someone might want to program with higher (or just different but convenient) concepts he learned in another language.

disputin 12y ago
The lower the standard of your team, the more you will appreciate idiomatic code. I don't work in SV, blue chips, or anywhere that could use Scala. A couple of us at my last place had a hard time moving the team from Source Safe to SVN, Git was out of the question. "What's the point of commit messages if you only commit every three months?" - not kidding, not a junior. Lines thousands of characters long, literally. I saw a pattern once. Once. CIO was one of these copy/paste VB devs, common in London, an unfair generalisation, but necessary as a warning sign. Some people become developers without any interest in development, completely oblivious to *nix/open source world, simply as a job, 9 - 5, and might have flipped a coin between development and accountancy. Some places don't give a shit about software development, or the idea of engineering - "just get it done!". Resharper, fxcop? Yeah, right. Degrees don't all teach compiler design, some just Java OO and a bit of Glassfish. If Go replaced C# in all of these arbitrary SMEs there would be far fewer WTFs. But people would struggle without Visual Studio debugging and a big run button. I'm being harsh, and seriously, not suggesting anything about MS devs, who include the world's best as well as the world's worst, but I find people on this site are often, to their fortune, oblivious to what working in the 99% can be like (the figurative 99%). Long live idioms, gofmt, golint.

tgeery 12y ago

If they just made the page wider, I might be able to read their code samples with minimal effort...

politician 12y ago

What do GOPATH, the project folder structure, package management, and package versioning all have in common? The go command. Not the linker, not the compiler -- the `make` replacement. If you want to fix the most broken parts of Go -- its ecosystem management tooling -- just replace your `go` command. I have, and I love working on a project with a proper top-level src folder, with vendor-able packages discoverable in a top-level lib folder pinned to known-good commits. There are literally dozens of go replacements, but the winning combination for me is using Goop [1], Makefiles, and symlinks to subvert `go get` and the naive way it parses import declarations [2]. [1] https://github.com/nitrous-io/goop https://github.com/nitrous-io/goop [2] https://golang.org/ref/spec#Import_declarations https://golang.org/ref/spec#Import_declarations

NateDad 12y ago
You don't have to replace the go command to do that. The only thing that needs the GOPATH and expects import paths to be URLs is "go get". You can very easily make a go project that uses all relative import paths and put it anywhere you like. Dependencies then just get copied into whatever path you like using whatever name you like. However, your code will be unusable by anyone who follows the normal Go way of coding, so you'll be missing out on working with the rest of the community. If you're writing proprietary software, that might not matter too much. But if you're writing open source code, it will be a huge hindrance to getting contributions from outsiders.
- politician 12y ago
  > However, your code will be unusable by anyone who follows the normal Go way of coding. Well, that's not really true given the major projects using tools like Godeps [1], so while that argument certainly sounds good, it doesn't actually seem to be a problem in practice. [1] https://coreos.com/blog/godep-for-end-user-go-projects/ https://coreos.com/blog/godep-for-end-user-go-projects/
  - NateDad 12y ago
    Actually, CoreOS is using the version of godep that rewrites import paths, so that most developers can use "go get". The only time you need to use godep is when you're updating one of the vendored dependencies. That's actually the awesome thing about godep - it keeps your repo go-getable. > the simplicity it presents to regular contributors and users used to go get make it worth the additional effort

kylequest 12y ago

"If you think the Go standard library is not powerful enough to do what you want to do, you might be wrong." or not... The standard libraries are not perfect. They do have very useful building blocks, but they are far from complete or perfect. Take the http library, for example. There's no built-in context: type HandlerFunc func(ResponseWriter, Request) type Handler interface { ServeHTTP(ResponseWriter, Request) } This resulted in a complete mess when it comes to http middleware because everybody is solving the context problem their own way (including google itself).