Stages of learning Go, with code examples

https://sourcegraph.com/blog/live/gopherconindia/112025389257

by beliu • 11 years ago

170 111 11 years ago

Animats• 11 years ago

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

campoy3• 11 years ago

As the speaker I couldn't agree more, actually check slide 39 https://speakerdeck.com/campoy/gophercon-india-evolution-of-...

nexneo• 11 years 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-service...

CatDevURandom• 11 years ago

Where are you reading into that?

cicero• 11 years 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.

bonn14• 11 years 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?

bbrazil2• 11 years 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.

bonn14• 11 years ago

And do these package managers provide a full ecosystem where all Go libraries/modules are available like e.g. npm does?

ansible2• 11 years ago

We prefer to use version control, and vendor libraries in our project instead. This is language-agnostic, and allows us to have repeatable builds without extra tools.

I've written up a tutorial about it using git-subtree:

https://github.com/jamesgraves/example-go-app

StevePerkins• 11 years ago

Does this not wholly preclude the possibility of vendors shipping a library without source?

NateDad12• 11 years ago

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

eddieroger• 11 years ago

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.

apunic• 11 years ago

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.

copsarebastards7• 11 years ago

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.

tveita3• 11 years ago

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.

orkoden• 11 years ago

An example for a dependency management package manager for a compiled language is [cocoa pods](http://cocoapods.org) for Objective-C. It's really popular with iOS and OS X developers.

Or look at [cabal](https://www.haskell.org/cabal/) for Haskell. It's a package manager that doubles as build system.

It helps when you use external open source projects and want to update it to a new version. With go you have to keep track of you external dependencies and their versions on your own.

theseoafs• 11 years ago

So the "solution" to Go's package management is just statically linking every library you use?

EugeneOZ4• 11 years ago

You really need to look at Cargo in rustlang to see what good package manager can do and how it improves development.

EugeneOZ4• 11 years ago

Please somebody explain me how to manage next situation without manual copying of code and forking repos (in other words, we need to still be able get updates for minor versions from repositories).

GOROOT/

pkg

src/

   lib1  

   app1

   app2

And app1 requires lib1 version 3.x, app2 requires lib1 version 1.x. What can we do?

Also, on whole this page https://golang.org/cmd/go/ I can't find ANY info, about how to fetch exact version from repo, not the master branch. In Go world all master branches are for stable code only, not for development? And all tools have only one version?

ptio• 11 years ago

https://github.com/pote/gpm

erikb• 11 years ago

As far as I know the system is different. You pull your requirements from repos recursively. It's maybe slower but in exchange it's more lightweight. For most cases it shouldn't be a kill reason. So what's the problem with that?

PS: I'm no go developer either. But the way it pulls in requirements was a nice idea in my eyes.

SEJeff• 11 years ago

Your questions was serious and not a troll, so I upvoted it. It seems like vendoring really is the "accepted upstream method" for solving this problem.

Even the Fedora packagers for golang apps are asking to relax the requirement on unbundling vendored things for golang as there is no sane way to handle versions other than git commit hashes.

Skunkleton• 11 years 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?

EugeneOZ4• 11 years ago

And how you follow minor version updates with your forked repos?

DanWaterworth2• 11 years 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?

campoy3• 11 years ago

There's long articles and talks about the topic. Check this one: https://vimeo.com/53221560

1_player• 11 years 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...

There is countless proof about Go's composability through functions and interface, but I keep coming back to that one document.

moe2• 11 years 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.

zak_mc_kracken2• 11 years ago

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.

DanWaterworth2• 11 years ago

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.

runeb• 11 years ago

Can someone recommend some good books on Go?

ardan-bkennedy• 11 years 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• 11 years ago

http://dave.cheney.net/resources-for-new-go-programmers

kingmanaz• 11 years 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.

copsarebastards7• 11 years 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

coldtea3• 11 years 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• 11 years 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.

waps• 11 years ago

Are you making the argument that Go is finally the magic language that can make bad devs write good code ?

Let me be the realist here : it isn't.

Go is just a very young language that, for the moment, only has developers that are curious and therefore either good or willing to learn. This has the additional consequence that for the moment the mailinglist is very helpful. History teaches us that both effects have nothing to do with the language and are temporary (unless the language never sees any "real" acceptance, like Haskell).

You can look messages from some years back showing the same sentiment for Delphi, Visual Basic, Java, Python (especially Python had lots of people making this argument), ... And when those messages were posted, they were true. It didn't last long for any of them.

But people would struggle without Visual Studio debugging and a big run button.

Sadly this is being used as an excuse for making language with substandard (to put it mildly) debugging facilities and editors.

And of course, like for every other argument, the Go team itself is just being extremely arrogant about this. "Why do you want this ?" type responses, or just dead silence, or outright declaring the people asking the question to be substandard developers or some such.

pashields• 11 years ago

Idiomatic means "using expressions that are natural to a native speaker." It's very possible, but not idiomatic, to write functional Java (pre-8). It's often more verbose and difficult to follow because there is no real notion of higher level functions or composition, let alone immutable data structures. The guava wiki has a good example of this: https://code.google.com/p/guava-libraries/wiki/FunctionalExp....

That doesn't mean that idiomatic practices are always virtuous, but non-idiomatic code is only virtuous because it overcomes an inherent mismatch between what the user wants and what the language provides. With many languages (certainly js, java, c++) we see non-idiomatic practices guide changes to the language and then be replaced. Java gained functions to avoid the abuse of anonymous inner classes. ES6 is stealing from transpiled javascript languages left and right.

Making idiomatic code virtuous is the goal of creators and maintainers. Writing idiomatic code means that you have chosen languages, frameworks, and libraries that are closely aligned with the code you need to write and the style you want to write it in.

loudmax• 11 years ago

Where does this idiotic idea cames from that being "idiomatic" is some kind of virtue?

I can't say for sure, but I'm guessing it probably came from years of experience working on the sorts of projects that Go was designed to address. Go is really geared toward large distributed projects with a lot of contributors. In that context, it makes sense to value some sort of conformity. It may not always result in the most efficient code, but it makes the code much more maintainable and accessible to newcomers. Once you're familiar with idioms you don't need to spend so much time figuring out what a new piece of code is trying to accomplish.

You seem to argue that since old PHP and javascript code had terrible coding practices, therefore Go shouldn't try to enforce any particular type of practice. I don't see that your conclusion follows from that premise. Now if you're arguing that good coding practices arise from the community, that's well and good. Idioms can change and I expect that idiomatic Go code in 2020 will be different from idiomatic Go code today. That doesn't mean there isn't value to writing idiomatic Go code today.

I haven't actually seen any cargo cultists explicitly say that no one should be writing in other programming languages for any project. That would be a pretty stupid sentiment, although I shouldn't be too surprised if some people felt that way. Go's strength is really on server side code where storage is cheap and network and I/O latency is a bigger issue than CPU or memory utilization. If you're developing for that kind of environment, there's a lot to be said for using Go. And while you're at it, you'll save yourself and anyone else who's working with your code a lot of hassle if you follow best practices and write idiomatic code most of the time. If you're in a specific situation where you can get better performance or whatever by deviating from the standards, then go for it, but leave some comments explaining your choices to anyone else who has to maintain your code.

If I'm going to write a one-off script to process a million lines of text, I'm probably going to write it in Perl, not Go (and yeah I know it's 2015). My Perl code will follow TMTOWTDI whatever-the-heck-works practices. If I'm already writing Go for something, and others might want to peek at my code, then I will make an effort to make my code idiomatic.

MetaCosm2• 11 years ago

Where does this idiotic idea cames from that being "idiomatic" is some kind of virtue?

Because being able to communicate is a virtue. That is all idioms are, a way to improve communication. By being well understood in a given community or sub-set of a community, they create a lot of value and a type of short-hand for understanding code.

Idioms are not static unchanging things -- they are flexible, adaptable, constantly changing tools that assist in understanding language (both spoken and programmed).

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.

Seems like your problem is with bad idioms, you seem to be a fan of the Play style -- both are just idioms, a simple way to improve communication.

The de-facto idiom of PHP before 2010 was messy code.

That isn't even an idiom. An idiom is a well understood part of a language and community. "Messy code" isn't an idiom, it is just messy code. There is no value gained from it, it has no short-hand value and it is not well understood across a community.

It started getting more coherent after that, but the preffered idiom now (e.g. for Zend, Synmphony, Laravel) is still a tedious, verbose...

But well understood by those in the space, a Laravel person can see another Laravel persons code and "get it" very quickly because they speak in the same idioms. It might be ugly to you, but it is useful to the community. Rails has its idioms, Django as well...

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.

Idioms are about communities more than languages, JS toolkits vary rather wildly in what they consider idiomatic.

In all of those cases, if they have stuck to the same "idiomatic" way from the start, it would have been worse.

Again, idioms are about what those native in the language or toolkit understand and can expect others to understand, they have never been (nor are intended to be) static, they are a reflection of what a community understands. They are shorthand.

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.

Go has a very strong core set of idioms that Go developers understand and expect. Breaking them has a significant cost to all future readers of the code and should be done only if it adds value in some ways. But a lot of questions in Go are far from settled, error returns as interfaces, concrete types or strings. I would be interested in explicit examples rather than vague cargo cult claims.

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.

"different but convenient" can to be looked at in two different ways. The first is for you, the original developer. It is more convenient for you... but what about the next 5 (or 50) developers who are unfamiliar with the idioms in play, it will radically slow them down as they lack the shorthand to quickly understand it. Go is about programming at scale (in terms of people) and something that benefits one while slowing down all others is going to be looked down on. Of course, there are valid reasons, it is faster, it is lighter, it is X. But when you diverge from the norm, you better be willing to explain it in a comment, both the what and the why.

coldtea3• 11 years ago

Seems like your problem is with bad idioms, you seem to be a fan of the Play style -- both are just idioms, a simple way to improve communication.

No, my problem, is with the pre-supposed and agreed upon set of idioms ("idiomatic Go", "idiomatic Java", "idiomatic Python").

I'm not even against what those idioms contain per se, as individual items.

"different but convenient" can to be looked at in two different ways. The first is for you, the original developer. It is more convenient for you... but what about the next 5 (or 50) developers who are unfamiliar with the idioms in play, it will radically slow them down as they lack the shorthand to quickly understand it.

Well, the reverse can be true.

Java programmers familiar with the circa-2004 idiomatic BS over-reliance of GoF patterns and deep class hierarchies created code that was "idiomatc Java EE" but difficult to undertand, overengineered, and inflexible.

Someone coding unidiomatic Java (e.g. Play) and giving the project to them, they'd instantly understand what its going on -- even better than someone giving them an "idiomatic Java EE" monstrocity.

Go is about programming at scale (in terms of people) and something that benefits one while slowing down all others is going to be looked down on

People keep saying that, but most Go projects I've seen are made by only few of people, maybe even a couple. Plus, people complain about even single-developer Go projects being "unidiomatic".

Programming at scale, like big 3D games, Photoshop, the Linux Kernel, Webkit etc, is still done in C/C++, with no sign of this changing.

tgeery• 11 years ago

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

politician2• 11 years 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

[2] https://golang.org/ref/spec#Import_declarations

NateDad12• 11 years 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.

politician2• 11 years 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/

kylequest• 11 years 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).

Stages of learning Go, with code examples

Related Stories