How I Start: Go (2014) | Hacker News Reader

How I Start: Go (2014)

howistart.org

226 pointsianrtracey121 comments

I agree that Go makes programming simple, in a matter of less than 6months, I learned how to write a webapp in Go just by using the standard library, later, I wrote a guide to teach how to write webapps in Go without using a framework, using an example based approach

https://github.com/thewhitetulip/web-dev-golang-anti-textboo...

> Go makes programming simple

Go is simple for simple tasks that fit Go type system, and yes the single formatting standard and the linting helps with readability.

Go is a pain in the ass for complex tasks that don't fit go type system, like de-serializing polymorphic data or working with XML. But at the end of the day, the lack of polymorphism in the language makes complex things way more complex than they should be. Finally, Go relies way to much on runtime behavior for a statically typed language.

These are quite unsubstantiated claims. Go is used in many a non-trivial program, such as Kubernetes, Docker, Google internal projects, and so on, and the one denominator among these is the plethora of data formats they need to work with.

His claim isn't necessarily wrong, and neither is yours.

I find dynamically-typed languages easier to work with when dealing with (de)serialization, it's just that Go isn't too horrible at that to warrant abandoning it and losing out on its other niceties in favor of a different stack.

I mean, everything sucks at something, and Go's type-system isn't....great....but it's "good enough" to where you just kind of curl your lips in slight disapproval sometimes instead of tearing your hair out.

> "I agree that Go makes programming simple, in a matter of less than 6months, I learned how to write a webapp in Go just by using the standard library"

I've met non-technical people who were able to make a webapp in PHP after 6 days with just the standard library and the O'Reilly Head First book.

6 months? that's a lot of time.

It isn't if you add learning web dev from scratch. I had never ever worked with webdev before

So then you have nothing to compare it to, and you can't say that Go made things simpler or faster than if you had started making web apps in say, python.

I had tried my hand with Django and flask, just read the tutorials, and for 6-7 months, I was still reading tutorials, and every 6 months a new version of framework would come up, and I'd be upgrading stuff. I would write views without understanding what they really mean.

Maybe I learned Python webdev in a wrong way, so, compared to that, Gonwas a cakewalk.

So you don't think the background knowledge you gained about web dev in 6-7 months of studying python helped you pick it up faster in Go?

> for 6-7 months, I was still reading tutorials, and every 6 months a new version of framework would come up

So, according to you, the invention of ONE new python framework caused you to rewrite everything you had been working on? What frameworks did you switch between? Why?

Golang is a popular language now, and there are going to be frameworks coming out all the time. There are already lots of Golang webdev frameworks. Imagine if you were starting with Go now, and you learned something like Revel (https://revel.github.io/) before learning how to make web apps with the standard library. Or imagine you spent 6 months learning a framework and then decided to jump to a new one when another one came out.

Also, from perusing the introduction to your Golang book, it seems like you were lacking knowledge of HTTP and other standards. I find that it's very difficult for anyone to learn web development without at least understanding a little bit about HTTP first. Only once you understand how all web development is the same, can you evaluate the ways that different languages do the job of writing HTTP servers.

>So you don't think the background knowledge you gained about web dev in 6-7 months of studying python helped you pick it up faster in Go?

No, the thing is, while I was studying Django, I wasn't learning how to write webapps, I was learning the framework. As I said earlier, I might have gone in the wrong way to learn. I didn't find a book which taught me what I wanted to learn, they all either were too abstract or taught a framework, thus, I started to write my guide, which assumes no background knowledge.

> the invention of ONE new python framework

Did I say that?

>Imagine if you were starting with Go now, and you learned something like Revel

The whole point behind my tutorial was to teach newcomers how to write webapps without using a framework.

> Also, from perusing the introduction to your Golang book, it seems like you were lacking knowledge of HTTP and other standards

I don't claim to know each and every aspect of HTTP and other standards, my book was about the journey I had while learning webdev and Go without using a framework, everyday there are new programmers trying to write webservers in Go, and I felt that there was a need of a book which taught by example.

> Only once you understand how all web development is the same, can you evaluate the ways that different languages do the job of writing HTTP servers.

True, with Go, it was no hassle to write webapps because Go has built in http library and it is a compiled language, thus my shift from Django to Go.

> Did I say that?

No, not exactly, but you complained that "for 6-7 months, I was still reading tutorials, and every 6 months a new version of framework would come up," can you explain what you meant by this? You say you were learning Django, why did you not stick with that? What new frameworks came out that made you stop learning Django?

> True, with Go, it was no hassle to write webapps because Go has built in http library and it is a compiled language, thus my shift from Django to Go.

See, these are the kind of statements I take issue with. interpreted languages are incredibly popular in web development because of how much easier they are to get started with than compiled languages. Not that I think AOT compilation makes a language bad for web development, but you seem to be asserting that Go is better for web dev and easier to learn because it is compiled and has a built in http library (python has one too! (https://docs.python.org/2/library/httplib.html) and if it's too low level for you, the documentation even points you to the open source requests library, which is the standard in the python community).

> As I said earlier, I might have gone in the wrong way to learn.

Yes, this is the point I'm trying to make. You're comparing apples to oranges when you say that Go makes web development easy to pick up compared to Python when you didn't really try to learn web development in Python, you tried to learn a high level framework without knowing anything about HTTP, a recipe for disaster in Python OR Golang (the point I was trying to make by referencing Revel).

6 months isn't anything. I've been programming in Go professionally for over 6 years and I still learn new things on a regular basis. There's a great essay by Peter Norvig on this subject called Teach Yourself Programming in Ten Years. http://norvig.com/21-days.html

1. setting GOPATH as $HOME made me uncomfortable, I don't see why anyone would want to pollute his/her home directory with bin, pkg, and src folders.

2. in his example, `go get github.com/your-username/hello` also automatically compile the thing into a binary in `$GOPATH/bin`. Is that correct?

I like to do this for my main Go path (I use per-project ones as needed), since I want ~/bin and ~/src (the former is where all of my personal binaries go, and the latter is where all of my personal source trees go). I guess I don't really mind that there's a ~/pkg — I might mind quite a bit more if I ever used a GUI file manager, but I never do that.

I don't think GOPATH as $HOME is a common thing (even back then).

A lot more people uses $HOME/go as GOPATH. So much so that $HOME/go is the default in Go 1.8.

To answer 2) yes, you're correct. If there is a main package that exists at `github.com/your-username/hello`, a go get will leave the resulting binary in $GOPATH/bin.

that whole thing is so subversion.

Aren't people annoyed by URL imports? e.g.:

import "http://www.geocities.com/bla/packagebla"

i.e. I don't want to mention some 3rd party irrelevant company name, and especially its URL in my source code.

I saw a comment recently that suggested URL imports are only meant for quick-start, hacky or stuff that won't be deployed somewhere. If you want a given version instead of the tip of master, for example, you're meant to retrieve them separately and set your GOPATH to that directory.

This is called vendorising your dependencies and is done because you can't/shouldn't rely on the third party server being available and serving the same version of the source code to build your code.

Java broke that barrier a long time ago with com.sun.whatever and com.google.whatever, etc.

Those names don't change when you move the code from Subversion, to Github, to Gitlabs, to Mercurial, to cool SV startup offering SCM services.

That's true. But the complaint was sullying his/her code with third party names.

But the reason you don't want to mention a third party is precisely because you may want to change that third party.

And if you start maintaining a redirect on a site you control, what happens when you let the domain die because you never use it?

The amount of HN people who have a personal domain listed in their profile that is dead because life got in the way is surprisingly high (including me until recently).

>And if you start maintaining a redirect on a site you control, what happens when you let the domain die because you never use it?

Right. Either you trust that Github or whomever will always be there or you manage your own domain, or you vendorise and put your dependencies in tree. There are benefits and drawbacks to each approach. It's not magic and we're all adults.

Vendoring doesn't work when the moment to update a package arrives and the upstream has changed SCM repository.

There is no way to avoid doing code changes in order to update the code that was vendored, this assuming that it isn't a binary package to start with.

It does work. You head to `$GOPATH/src/github.com/coolpeople/coolpackage` and then do `git remote set-url origin https://gitlab.com/coolpeople/coolpackage`.

New uses of go get will not work, but it's not impossible to work this way. Alternatively, you use find . -name \*.go -exec sed -i 's:github.com/coolpeople/coolpackage:gitlab.com/coolpeople/coolpackage:' {} +`.

You should use a vanity name such rsc.io/pdf which provides some meta data where the code is and how to fetch it. I personally like the import syntax.

More about this here https://golang.org/doc/go1.4#canonicalimports

It isn't a proper solution, because it requires package authors to take the additional effort of doing it.

About as much extra effort as it's saving the end users (devs) from having to find and download the package in the first place. And you could just tell your users to download from your site and stick it in their gopath, so it's literally just an enhancement over the model you are wanting, just allows an author to spend a few minutes to save every user some time...

When a package author changes the SCM repository location of a Java package available on any Maven like repository, I don't have to do anything.

And he/she also don't have do any extra work so that I can keep using the same package names.

And there is literally nothing preventing that from functioning with Go. All you are complaining about is that the central "package repository" doesn't exist yet, where as my point is that Go has given you all the tools to build a central or distributed repository as you choose. You seem to be most upset that people are just using GitHub cause it's free and it works, and how is that different then any other central repository?

URLs are part of package name and there is no guarantee they will survive a repository change unless the package author has taken the effort to use canonical imports.

As for being upset, not really, unless my boss requires me to use Go, I don't plan using it again.

In practice the author rarely changes the import domain/url so it's not really an nuisance. There are tools to fix imports if the unlikely case actually happens. I value the fact that I don't need config files to make it work more than this small possible inconvenience. There is also a `alias` feature in the upcoming version which allows the author to make the transition from one path to another even easier for clients. https://godoc.org/golang.org/x/tools/refactor/rename

It's more like

    import "geocities.com/bla/packagebla"

which, IMO, is totally fine, Java has popularized putting some variant of the URL in the package name.

For me, it means that all dependencies are declared by origin, meaning you don't need to track where they come from , the origin is the import.

It also avoids naming collision. If it's open source, just fork it and voila!

I think it stupid, not merely annoying. In my own projects I have to import "github.com/.." of sibling packages in the same project or go get breaks for my users.

One of the most stupid engineering decisions I've seen in years, imo.

What’s the problem with importing github.com/… in your projects, aside from possibly not being appealing to your personal taste?

The principal question is what is the benefit of this monumental facepalm.

Data provenance.

Now explain your side.

You don't have to change #include paths in C++ (or Java imports) code when you move your project from github to bitbucket.

Have you looked at the build system of a C++ project lately? Or a Java project? It's not like that's some super-elegant not-at-all-rolling-catastrophe of a system.

Java and Node, for example, don't solve anything - to get something that builds sensibly they both entirely depend on "external service" being always available and enforcing naming (see the leftpad fiasco). C/C++ are the source of the term "dependency hell".

I've had to deal with CMake as well as automake/autoconf at work recently and I'll take Go's system of fetching/building any day over the Wild West that is the C/C++ eco-system.

It's an artifact of a tool. The same after-thought tool could have just dropped a mapping line in a .gotool file somewhere:

    $ go get whois etcd
    github.com/coreos/etcd

But no. We need to put that in every freaking file and thus transit from information to noise.

You could ask failed kickstarter projects Haunts: The Manse Macabre what the problem is. Just last week I compiled some 25 year old, K&R style C code and it worked. Will any go code compile in 10 years? 1 year?

https://www.kickstarter.com/projects/2066438441/haunts-the-m...

Vendor it, and your code will always compile.

It is interesting to me that this feature has evoked such passion and feeling. To me it is a few extra characters and easily managed at the top of a file. It generally will take at least one line of code to import some other package or library. It isn't as terse as say C or C++ nor is it as flexible as Python's import system. Of all the things that bother me about a particular language, this just never bubbled to the surface for me.

(Vendoring and package management are different issues)

It is not a matter of just a few characters. It is a conflation of logical identity (URI) with location (URL). Engineering 101.

https://github.com/coreos/etcd/blob/master/lease/leasehttp/h...

What could possibly justify having to use that import line in a sibling package of the same code?

If you fork a go package with subfolders, you will be in for some trouble. Your fork is still importing the original subpackages, because they are referenced by their absolute (original) address. You don't want to rename the imports in the entire fork because you still want to merge/pull request with the original. So your fork needs to live in a folder that uses the original name, not your fork's name (that local repo will have two remotes, the original and yours). This is a pretty annoying and error prone disconnect, especially for people wanting to use your fork; they need to do the same type of workarounds.

<< I don't want to mention some 3rd party irrelevant company name, and especially its URL in my source code

Then don't use a irrelevant company name. Use your own name e.g. rsc.io/pdf . See more here https://golang.org/doc/go1.4#canonicalimports

I am the more by depending on external source -- as in needing the source for every library used to be able to build.

EDIT: yes, besides aesthetics, the main (and more important) reason is the dependency on some disposable online resource.

If you are using code hosted there, then you are dependent on that online resource, whether you write their name in your code or note.

1) it's Github, so "disposable" is a fair mental leap and 2) fork and/or vendor the dependencies if you're worried.

I like it.

1) I know exactly where the package came from:

import "geocities.com/bla/packagebla"

import "packagebla"

2) Easy to determine if the package is official, internal, or external (gofmt).

However, what is lacking is a unified vendoring standard. They will address this shortly.

So, why not:

  mkdir $GOPATH/src/mystuff

  git clone https://github.com/foo/bar 
  # may be switch to a branch here while you're at it

  mv bar $GOPATH/src/mystuff/bar

Now in your Go program

  import "mystuff/bar"

The whole "URL import" is not a "feature of Go", it's an artifact of "go get", just a tool to make it easier to pull code from github or whatever.

I think this explains some of the confusion I've had reading posts below.

If package `github.com/foo/bar` imports a nested package, say, `github.com/foo/bar/baz`, this will break as it will be trying to look for said package in `$GOPATH/src/github.com/foo/bar/baz`.

Nope, not annoyed at all

1. I know precisely where a package is coming from.

2. When vendored, I know precisely in which directory a package is stored.

3. I actually want to know if a random no-name library is introduced by developers, so I can google it. URL looking import is a nice feature in this case.

So I can't just put my code in ~/Projects like with every other programming language I've ever used?

https://getgb.io/ if you want to.

Create the folder ~/Projects/go and use it as gopath, I recommend a vendoring tool to prevent cluttering.

Most tutorials (all? I had to RTFM) outright omit how to use gopath. Especially with forks.

Bad tutorials then.

Right, but if all of the tutorials are bad, it kind of points to a problem elsewhere.

That people aren't RTFM-ing?

No - that the ecosystem or decisions are difficult to understand or communicate effectively.

Setting an environment variable is trivial, and becoming aware of this requirement also trivial. It's all but spoon-fed here [0] and here [1].

I've never encountered anyone -- both online and offline -- who has had trouble with this beyond "huh, I didn't know I had to do that. Duly noted".

Until now, that is. You are making a mountain out of a molehill ... nay, an anthill.

[0] https://golang.org/doc/install

[1] https://golang.org/doc/code.html

https://golang.org/doc/install

This is the official installation document. If you have problems finding proper tutorials, there is also

https://tour.golang.org

which also links to the previous document on install instructions.

Must be some shit tutorials. The ones I read were great. Did you just take "some-random-guy"'s blog at face value? There's an official Go home-page full of beginner guides.

This is what I've ended up doing, and it still drives me absolutely batty. Typically I'd group together all of the code and assets for a project in one place; any Go code has to exist in this separate namespace for no convincing reason.

It's fine, I can work around it, but it's still quite annoying.

I think I am in the same boat -- Go file layout model seems to be for multiple projects written in Go instead of (my typical case) a multi-language project with a component in Go.

It is not really a big deal, I can overcome it with some simlinks and conventions, but this is not elegant; I hope a model to support this better will be added sometime.

>any Go code has to exist in this separate namespace for no convincing reason.

The convincing reason is that you get several automated behaviors in fetching, installing and building this way.

If you don't care for those, you can use whatever path you like for your code, and a custom makefile for building.

Just don't expect "go build", "go install" etc to work.

Something I pretty much do and have heard from other Go people that they do this also, is to just keep all my projects in the GOPATH. Whether they be written in Go or not. It essentially gives you an organised structure based on git URLs, so it's always easy to find anything. I use $HOME/go, and have projects in there written in a bunch of languages.

I do this. It's actually a pretty good way to organize code in general, not just Go. Still dumb that they force it on you.

Setting up GOPATH, when _starting_ Go projects, has been one of the top frictions for newcommers. That why Cloudflare came up with a solution: https://github.com/cloudflare/hellogopher.

> Hellogopher: "just clone and make" your conventional Go project

I was frustrated with the directory convention as well. What I did was set up the Go directory structure, and then created a symlink to for my projects directory in the Go directory structure. I was already using a directory convention that followed the GitHub/user/project convention, and it seems to work fine. Use at your own risk :)

It may seem to work fine, but it doesn't. Symlinks are not officially supported by any of the Go tooling. Your setup is working by accident, and may break with any future release.

I absolutely love Howistart, but some of their tutorials are getting a little dated. This one uses Go 1.3, whereas 1.8 is now GA, and there has been a lot of progress around vendorizing dependencies.

For those of us who are new to go, can you say a little more about how this might be different if it was updated for 2017? (Or if it is involved, perhaps a link?)

There would be no substantial changes, as this project has little to no interaction with the GOPATH, and doesn't use any dependencies. It's a testament to the stability of the language.

Some things are easier now, like an automatic $GOPATH set to $HOME/go, or the ability of vendoring dependencies so you don't need to worry if companyx.com/project/package no longer exists.

Interestingly, the very first thing I've read, that is the environment setup contains instructions that I was told are incorrect by Golang people - one should not use brew to install Golang on macs, one should download the official package. The brew installation, for example, lacks the offline tour package, and who knows what else.

The brew formula is here:

https://github.com/Homebrew/homebrew-core/blob/master/Formul...

    url "https://storage.googleapis.com/golang/go1.8.src.tar.gz"
    mirror "https://fossies.org/linux/misc/go1.8.src.tar.gz"
    version "1.8"
    sha256 "406865f587b44be7092f206d73fc1de252600b79b3cacc587b74b5ef5c623596"

This checksum matches the one on the official download page:

https://golang.org/dl/

406865f587b44be7092f206d73fc1de252600b79b3cacc587b74b5ef5c623596

The Golang people could save a lot of headaches and fix whatever they see wrong in the formula so people can continue to use their package manager instead of being reduced to Windows style savagery.

Edit: looks like someone indeed tried to make an issue:

https://github.com/Homebrew/homebrew-core/issues/9272

If I understand, the Go team made the binary package install stuff not in the source tarball. That's doesn't sound like a good idea but they're some smart people; I'm sure they have some reasons. T'woud be nice if they helped bring brew in-line as well.

Homebrew is a perfectly acceptable, even preferred way to install Go on Macs. Who has told you otherwise? They are wrong, or are speaking from a very specific context.

After seeing URL string parsing in application code I would have expected to see at least some sort of discussion about third-party web frameworks.

Even a web framework isn't necessary. Most people get around that nastiness using gorilla/mux: https://github.com/gorilla/mux

Don't you worry, it's not done like that.

Either you use query params, or you use a library like gorilla, where you just insert pattern variables into the url.

Has anyone noticed an extreme explosion in languages? It seems like a good hobby project to create your own language and then evangelize evangelize evangelize.

I'm all for advancement, but this feels like overload. We have each of the big companies promoting their own languages. Microsoft: C# (and other flavors), Apple: Swift, Google: Go, Mozilla: Rust... I'm sure I could keep going, but that seems to be the trend lately. You can't be a big company and not have your own programming language.

So I guess the language changes for each domain. There is no longer the dream of a single language to unite all the plebes! Maybe it was a dream anyways.

I see what you're saying between Swift, Go, and Rust, but I'm not sure C# belongs in the same category. There are orders of magnitude more real-life lines of code implemented in C# than the other three combined. It's much more comparable to Java.

F# may be a better comparison.

Indeed, Microsoft wanted to use a modified Windows-centric version of Java called J++, but Sun wouldn't let them, so they created C#.

I think this is the future. There will always be a few main do-anything languages, but we're going to see languages that fit certain use cases becoming very common.

Historically languages were limited by their compilers and VMs. You ran Java or C++ because it took a large company to come up with a fast enough environment. Now we have the tools and experience that anyone can create a fast enough language in a few weeks.

Also historically, if you wanted your code to run faster, the answer was pretty much always to move to a lower level language. Java too slow? Use C++. C++ too slow? Use C and/or optimize choke points with assembly.

The tooling exists now that we can solve a lot of those same hard problems using languages and tools designed to solve them without reinventing the wheel in C or assembly.

I'm all for advancement, but this feels like overload. We have each of the big companies promoting their own languages. Microsoft: Visual Basic, Apple/NeXT: Objective-C, Bell Labs: C and C++, Sun: Java... I'm sure I could keep going, but that seems to be the trend lately. You can't be a big company and not have your own programming language.

By the way, C# has been around for 17 years.

True. And it's a beautiful language. I'm not necessarily knocking the other languages either. It's just that it seems that the fragmentation is becoming an issue, when all that development effort doesn't seem to necessarily be generating more value. I'm sure it's possible by all of this experimentation someone will stumble upon the next Javascript, or the next C. So there may be a benefit in the long run. Or maybe not.

It is really great that the latest Go version doesn't require setting the GOPATH

Reading the title I was really hoping this was story of a program loading and executing. And that the site had this documented for multiple languages.

Does anyone know of a resource like that? I understand it would be different in on each platform but a fun and interesting read either way.

It's 2017 and developers are still abbreviating variable names ('err', 'resp', etc. in the article). It's tragic that readability is still not seen as a priority by so many people.

'error' is a protected keyword in Go.

Nitpick: Syntactically speaking, it's not a keyword. But it is a universally defined type name, which means you can't use it as a variable name.

That's what I meant. If I didn't say it, it was because of a typo.

Then use another word; 'defect' and 'fault' are two acceptable synonyms I managed to look up in less than a minute.

I mean... is using 'err' really that big of a deal?

Given that errors and error handling itself is a very normal thing to come across in most projects, would the abbreviated `err` not seem more familiar than defect or fault, to you?

'response' is too large. Having too large lines is not great for readability.

I don't know about other people, but I read symbols not characters, and having those symbols be actual words makes them easier to parse.

In this case, it sounds like resp is commonly used, so that's not necessarily a problem. But in general, if a line is long enough that shaving a few characters off a symbol helps, it probably should be split up regardless.

I don't know why you were downvoted for this. I, for one, completely agree.

The article is from 2014

That's besides the point. Go and Rust developers still use abbreviations unnecessarily everywhere.

While I agree readability is key, you may find people who disagree about what constitutes "readable". I think the Go community in particular may be partially inspired by the philosophy outlined under "Variable names" in Rob Pike's "Notes on Programming in C":

https://www.lysator.liu.se/c/pikestyle.html

Quoting:

"Ah, variable names. Length is not a virtue in a name; clarity of expression is. A global variable rarely used may deserve a long name, maxphysaddr say. An array index used on every line of a loop needn't be named any more elaborately than i. Saying index or elementnumber is more to type (or calls upon your text editor) and obscures the details of the computation. When the variable names are huge, it's harder to see what's going on."

I don't agree with everything written therein, and it was written circa 1989. But in practice single letter variable names are used diligently and frequently in Go, they're convenient and don't break readability if you understand the (simple) convention.

We've learned a lot since 1989. And while clarity is more important than length, clarity has more dimensions than length.

For example, maxphysaddr we now write: max_phys_addr. And when it comes to loop indices, using single letter 'i' isn't practically searchable.

Also, our notion of iterators has progressed in the last 27 (gulp) years. Arrays these days are generally too abstract. There's a reason a block of values has been assembled. If they're pixels or bananas, the index can represent that, e.g. for( banana_idx = 0; banana_idx < bananas.num; banana_idx++ )

This is doubly important in blocks of code where multiple types are used, for example, a uint8_t for one index, a unit16_t for another. They need different variable names anyway, so make name them germane to their function.

"Amount to type" and especially "calls upon your text editor" are irrelevant to clarity.

Maybe it's because I program Go, but I don't find the use of err and resp diminish readability. I don't feel any cognitive hurdle when reading those code examples.

This is actually common convention for Go. One letter variables are used throughout the canonical examples, coupled with very short functions that cause this to make more sense.

Common convention doesn't make it automatically readable.

Every modern language should strive to be user friendly. Gone are the days when we were constrained by hardware limitations which caused us to adopt such practices in the first place.

One letter variable/parameter names is a despicable trend. Abbreviated function names are also rather vile in my eyes.

Go programmers have no trouble reading err and resp, since they're so standard.

Just like everything else, moderation is key.

* err, i, req, resp are so common in a lot of Go codebase that they become a convention themselves. So it's not that hard to read. Another example: Javascript's function(e) {}

* If a name is too long, it impedes readability as well, e.g. SimpleBeanFactoryAwareAspectInstanceFactory.

When programming in Go, err and resp are inarguably more readable than defect/fault or response would be.

Andrew Gerrand did a great talk a while back (I'll try to hunt it out) in which he talked about naming conventions. One of the things that stuck out for me, was when he said, if you're declaring a variable that is only going to be used very locally (i.e. within the next few lines or around there), then using a short name is preferred. So instead of 'response', you would simply use 'resp'. However if you're declaring something that may be used in a different part of the file, or Go package itself, go with something more verbose as to not confuse someone seeing it for the first time with no prior context. Also `error` is meaningful in Go, so `err` is used pretty much all the time.

Those names are conventions. Same as in languages like Haskell/Scala where type heavy code will have type names A, B, C, D.

It's a matter of getting used to, leater it's easy and fast to read.

Abbreviations I can think of right now are: w writer, r reader/request, i, j, k, ctx context, resp response, req request, err error, cli Client

(2014)

see Github project https://github.com/peterbourgon/how-i-start-go

and Twitter https://twitter.com/How_I_Start/status/506510262909030400

Reply on news.ycombinator.com