
The Go Programming Language by Brian W. Kernighan, Alan Donovan - davecheney
http://www.amazon.com/Programming-Language-Addison-Wesley-Professional-Computing/dp/0134190440/
======
vezzy-fnord
What made Go click for me is a simple realization: it's a language made by
systems people, not by PL researchers.

Everything makes sense after that. The language in isolation is boring and
perhaps even anachronistic: a modern ALGOL dialect with first-class green
threads.

But as many people have said, the tooling and the libraries are simply top-
notch. This is unsurprising: the people behind Go all have experience with
things such as Research Unix, Plan 9 and just infrastructure in general.
They've been instrumental in shaping up the lower level workings of our
present systems, so they're intimately aware of those aspects. 9P, Acme, rio,
the Acid debugger, the Plan 9 compiler collection... among other tools,
reflect that their brilliance is in engineering rather than science.

But more importantly: these people are experts in managing complexity and
_integrating_ things. Thus, in isolation, Go's components look bland and
uninteresting. Cumulatively, they form a unique experience. Hence why Go has
such a strong culture of "pragmatism" that a lot of PL geeks scoff at.

So I've pretty much stopped thinking of Go the language, but rather Go the
toolchain.

------
eric_bullington
I've not been a huge fan of Go (more of a Rust person). However, seeing these
authors, I'm now itching to get my hands on a copy of this book and give Go
another shot.

I wish I didn't have to wait until the summer for it!

Edit: Also, I realize it's unfair to compare Rust to Go, since they really
fill two different PL niches. I actually think there is plenty of room for
both languages. By my statement above, I just meant that I'm more drawn to
Rust's functionally-influenced approach than Go's modern take on the
imperative paradigm.

~~~
TazeTSchnitzel
K&R had some wonderfully tricky exercises. This should be fun. (Assuming I
don't give up again!)

Edit: Hmm, perhaps I should dust off that copy of K&R and continue from where
I left off? :D

~~~
eric_bullington
I've actually used some of the exercises from K&R when learning other
languages, they're so good.

This should be a _lot_ of fun.

------
sesteel
Go, with its simplicity, is a gift from the generation of masters to today's
professionals, but many of today's professionals appear too ignorant to see
the wisdom of the language. It used to drive me crazy when I would read
negative comments in r/programming and HN, but I don't even pay attention to
the negative comments anymore. The adoption is far better than I was afraid it
was going to be.

~~~
matthewmacleod
I think it's rather the height of hubris to accuse your contemporaries of
being "ignorant" because they disagree with your assessment of this particular
tool.

Go is an interesting shift in language design, basically discarding many
modern trends and techniques and returning to a much simpler paradigm. It's a
totally valid approach with lots of merit — complexity can be a killer. In
addition, the concurrency primitives, decent stdlib and tooling make Go pretty
great to use in some respects. It's likely to be well-supported for a long
time and is a suitable tool for many tasks.

On the flipside, using it often feels like a bit of a slog. Error handling is
simple (good) but repetitive (bad). Keeping generics out of the language
avoids complexity (good) but results in repetitive and awkward code (bad).
Lack of features like pattern matching and higher-order functions makes some
code irritatingly tedious to read and write. And so on.

Point is, it's perfectly valid to look at these decisions and say "I don't
like Go because it is missing these features", as much as it's valid to say
"The simplicity of Go is a useful feature". Ignorance is not a prerequisite
for disagreement.

So please have some respect for opinions which differ from your own, and think
about offering something a little more constructive than insults.

~~~
mavelikara
In an essay titled "Why Pascal is Not My Favorite Programming Language"[1]
Brian W. Kernighan wrote:

    
    
      The size of an array is part of its type
      If one declares
    
         var     arr10 : array [1..10] of integer;
                 arr20 : array [1..20] of integer;
    
      then arr10 and arr20 are arrays of 10 and 20 integers
      respectively. Suppose we want to write a procedure 'sort' to 
      sort an integer array. Because arr10 and arr20 have 
      different types, it is not possible to write a single 
      procedure that will sort them both.
    
      The place where this affects Software Tools particularly,
      and I think programs in general, is that it makes it 
      difficult indeed to create a library of routines for doing 
      common, general-purpose operations like sorting. 
    

People who complain about the lack of generics in Go are making the same
argument that Kernighan made against Pascal viz. that it is tedious to write
library code in the language.

EDIT: Also it is not uncommon for a feature that is deemed essential by some
to be thought of as adding too much complexity by others. For example,

    
    
      "I've seen [visual] editors like that, but I don't 
      feel a need for them. I don't want to see the state 
      of the file when I'm editing."
    

said Ken Thompson [2] when comparing line editors like ed to visual editors
like vi or emacs.

[1]: [http://www.lysator.liu.se/c/bwk-on-
pascal.html](http://www.lysator.liu.se/c/bwk-on-pascal.html)

[2]:
[http://web.archive.org/web/20080103071208/http://www.dcs.qmu...](http://web.archive.org/web/20080103071208/http://www.dcs.qmul.ac.uk/~george/history/)

~~~
NateDad
[http://golang.org/pkg/sort/#Sort](http://golang.org/pkg/sort/#Sort)

So, something like that?

Interfaces, man. They're better than you think.

~~~
coldtea
Yeah, fuck this type safety and performance thing...

~~~
NateDad
It's type safe and there's little performance hit. Please note that the
"Interface" there is _not_ "interface{}" ... it is a somewhat unfortunately
named interface:
[http://golang.org/pkg/sort/#Interface](http://golang.org/pkg/sort/#Interface)

The Go authors were following a practice that seemed like a good idea at
first, and they've now admitted was probably a mistake... i.e. if your package
is mostly about a single interface, name the package something informative,
and call the interface type "Interface". This works relatively well from
calling code, since it'll be referenced as "sort.Interface", but it makes the
documentation for the type potentially confusing.

~~~
pcwalton
It's not very friendly to the optimizer though. In order to achieve the same
performance as a templated generic version by eliminating vtable dispatch, the
optimizer needs to (1) convert the recursive sort function to a loop; (2)
inline the sort function; (3) promote the interface to the stack via escape
analysis; (4) SROA the interface; (5) constant-propagate the SROA'd functions
to their use sites; (6) inline the now-constant functions. You need a pretty
powerful optimization framework with a well-tuned pipeline like GCC or LLVM in
order to do all of that.

------
jgrahamc
Oh. Thank goodness for that.

Now I can resist every publisher that wants me to write a book on Go, and tell
myself that was OK to do because I'd never write as good a book as those two.

~~~
vixen99
What modesty!

~~~
jgrahamc
What you call modesty I call self-awareness.

------
sgt
For those of you who are not familiar with "The C Programming Language" (also
written by Kernighan), see: [http://www.amazon.com/C-Programming-
Language-2nd/dp/01311036...](http://www.amazon.com/C-Programming-
Language-2nd/dp/0131103628/ref=sr_1_1?s=books&ie=UTF8&qid=1425561072&sr=1-1&keywords=the+c+programming+language)

------
aikah
I have mixed feelings about Go.

For those who didn't try it yet here are the biggest advantages of Go:

\- it's totally easy to learn and can be mastered in a day

\- it's fast and typesafe

\- the concurrency model is great,no question

\- I personally like the error system, no exceptions but you can still "bubble
up" errors with multiple return types

\- it has, in my opinion a comprehensive standard library,you can even do
websockets and image compression with it.

The draw backs :

\- no generics clearly the biggest drawback, which means a lot of copy and
paste

\- the lack of idiomatic way to deal with dependencies(no defacto package
manager)

I think the ease of use justifies Go adoption in any team. It doesn't replace
ruby or python for web programming ( little value in coding a CMS in Go ,
rails makes more sense),but when it comes to backend or webservices, it's a
killer tool.

compared to java, it's as fast and consumes WAY less memory.

~~~
CatDevURandom
> which means a lot of copy and paste

Again, I don't think Go is perfect but on my list of wants, generics are not
in the top 5. Can you qualify "a lot" in a real project you've worked on?
Because after writing a good chunk (over 50k lines) of Go code, I haven't felt
the sting as much as I hear it complained about.

> the lack of idiomatic way to deal with dependencies(no defacto package
> manager

Again, is this really a big deal? There's plenty of options, and if you are
shipping any-type of commercial product you are going to want to be vendoring
your dependencies in-house anyway. In which case, depending on something like
NPM/remote maven repos is not a viable options anyway.

~~~
rubiquity
> _Again, I don 't think Go is perfect but on my list of wants, generics are
> not in the top 5._

Would you mind sharing your top 5 wants? I'm interested.

~~~
CatDevURandom
Sure! In order:

A Debugger.

Better IDE options.

Binary sizes small enough to use for embedded programming.

Pauseless Garbage Collector.

Less awkward variable declaration.

~~~
bsg75
> A Debugger

[https://golang.org/doc/gdb](https://golang.org/doc/gdb) (some limitations
IIRC)

[https://github.com/derekparker/delve](https://github.com/derekparker/delve)
(a work in progress, but promising)

------
chrisallick
I was a bit surprised by the length. Not a huge difference, but one of the
best things about the K&R book was how short it was. But, I too have been been
curious to look into Go. This might be the excuse I needed.

~~~
henesy
I'd say any length increase would be justified, Go does have a pretty large
standard library...

------
rdegges
YES. I read and re-read the original K&R (The C Programming Language) book
many times as a child. It's one of my favorite tech books ever written: clear,
concise, challenging, useful.

I've recently started writing more and more code in Go, for simple performance
reasons, and it'd be amazingly great to relive the K&R wonders of my childhood
with a new language =)

Just pre-ordered a copy, can't wait.

------
meddlepal
I look forward to the time when Go adds generics and all the people who told
me that you don't need generics in Go start telling me how awesome and super-
duper useful generics are.

~~~
dilap
Here's rsc (one of the core Go dev's page) on generics.

[http://research.swtch.com/generic](http://research.swtch.com/generic)

They do believe it's a useful feature, they just don't think the tradeoffs
justify it yet. (People who loudly clamor for generics tend to ignore these
tradeoffs.)

~~~
marvy
Unfortunately, that thing is a false trichotomy. The fact is, choosing option
1 does not save you from the consequences of options 2 and 3. The reason is
that the programmer now has to make a choice between boxing things manually,
or implementing the same algorithm multiple times, just as the compiler would
have done. So in reality there is a dichotomy: slow compiles, or slow
runtimes.

~~~
dilap
Definitely some truth to this, but in practice, the fact that you have to
manually do things means that you'll make decent choices -- you'll use
interfaces for most stuff, and specialize the stuff that needs to be concrete,
and life will be OK, if a bit clumsy.

With generics, it's easy to end up in a situation where just by instantiating
some simple-seeming class, you get a whole giant pile of stuff, more than any
sane programmer would create by hand.

(I wish I had it at hand, but there was an excellent post from a .NET/CLR guy
a while back that went into all the crazy stuff that got instantiated just by
creating one specialization of List<T>, the associated performance overheads,
and the things the compiler and runtime tried to do to avoid those.)

~~~
sigmaml
You should, however, note that Go does not have inheritance. That single
difference reduces the `crazy stuff' by an order of magnitude. In addition,
not having inheritance also means that you do not need to take variance into
account, which further reduces the complexity significantly.

------
kylek
Awesome. For those who don't know, Kernighan is the "k" in "awk" :)

~~~
sp332
Also the "K" in "K&R"
[https://en.wikipedia.org/wiki/The_C_Programming_Language](https://en.wikipedia.org/wiki/The_C_Programming_Language)

~~~
nsnick
Also, the K in Kernighan Lin (Graph min cut) and the Lin-Kernighan heuristic
(Traveling salesman)

------
wsloth514
It's Brian Kernighan, enough said. I am sold.

~~~
cdnsteve
I actually have to say I wasn't familiar with this author having never spent
time in C. After some Googling I'm excited to see he's fellow Canadian and
looks to be a pioneer in computing as well. It also seems he's worked with Rob
Pike, another fellow Canadian :)

------
cyber1
Good news! I think Go is the best alternative between C speed and simplicity
of Python!

------
chiph
320 pages vs. 274 for the 2nd edition of _The C Programming Language_. Not
bad, considering how much more "stuff" Go has in it vs. K&R C.

------
frou_dh
Anyone know if Kernighan has written a lot of Go code himself, or is he
onboard more for his technical writing skills?

(There's the Bell Labs connection of course)

~~~
zaphar
Kernighan is one of the core authors of the language. So I'd say it's for more
than just his technical writing skills.

~~~
frou_dh
No he isn't. Thompson gets slighted the same way by everyone thinking K&R
_created_ C, when that was T&R.

They may all be greybeards but they are in fact distinct people!

------
waitingkuo
That's really a good news. "The C Programming Language" is one of my favourite
book. This should the next one!

------
pjmorris
"Good Programming is not learned from generalities, but by seeing how
significant programs can be made clean, easy to read, easy to maintain and
modify, human-engineered, efficient, and reliable, by the application of
common sense and good programming practices. Careful study and imitation of
good programs leads to better writing." \- [1]

I'm a huge fan, have nearly everything Kernighan's been involved with, and
have profited greatly from his writing. I look forward to picking up the Go
book, and modernizing a bit.

[1] 'Software Tools', Brian Kernighan, P.J. Plauger, 1976

------
tempodox
In my personal view, I find it disappointing that someone like Brian
Kernighan, as a co-author of C, only got as far as Go. I would have loved it
much more to see him working on a language like Rust, that actually seems to
point to the future of programming languages (or does its best at it), while
Go looks like a stopgap and a dead end right from the beginning.

Go seems a fine piece of engineering in so far as it directly implements
Google politics & some of their technical interests, but it's of little use
outside of that, despite all the hype. A pity, really.

~~~
kibwen
Go and Rust are allies, not enemies. Rust is a language driven by a goal, not
by blind ideology, and that goal is to make the world a safer place by
leveraging memory safety in a low-level context. Given that Go is _also_
memory safe in its default configuration, any C or C++ service that is
rewritten in Go still has the effect of making the world a safer place.

Programming languages are a means, not the end!

~~~
pjmlp
That I agree.

Regardless of I and others might think about Go's design, every user
application that gets written in Go instead of C or C++ (assuming C like code
instead of proper safe C++14), is an improvement on the current torrent of CVE
exploits.

------
LVB
It has been a long time since I bought a hardcopy programming book. Alternate
forms of documentation and a Safari subscription have replaced these semi-
frequent purchases. And although I can't argue against the practicality and
economics of this new way, it certainly evokes none of the excitement of
getting the new language book home, cracking the binding, and spending the
rest of the evening curled up on the couch.

Go has been my most used new language and the timing of this book is good. I'm
looking forward to adding it to my (real) bookshelf.

------
crncosta
I would like to take a glance. Does any one know where is the Table of
Content? Thanks.

~~~
danieldk
[http://www.informit.com/store/go-programming-
language-978013...](http://www.informit.com/store/go-programming-
language-9780134190440)

Seems like a no-nonsense approach like the K&R book. I am sold already :).

------
FanaHOVA
The book is the #1 Best Seller in Computer Programming Languages and it's not
even been released yet.. wow! I'm studying their C book right now for a
university class, probably going to pick this one up right after.

------
rjammala
Thanks Dave for the link. I just pre-ordered the book :-)

------
signa11
for folks who don't know it (yet), here is the toc:
[http://www.informit.com/store/go-programming-
language-978013...](http://www.informit.com/store/go-programming-
language-9780134190440)

------
zapf
No Kindle edition? :-(

~~~
BinaryIdiot
Considering this thing doesn't release until August 2015 I think they have
plenty of time to add one.

------
touristtam
Honest question here: Why do I need a book about Go when all the doc is living
online? that just feels so 90's.

------
ChuckMcM
Too bad you can't buy it in a Kindle edition, I would have bought that.

------
enahs-sf
All the fun of The C Programming Language with none of the K&R braces!

------
e12e
Am I blind, or is there only a paperback edition, no digital version?

------
dsuth
Great, now I have to learn Go to justify getting this book!

------
xasos
Does anyone know if they are selling a digital version?

~~~
tjl
Considering that it's not currently for sale, there's no digital version. That
said, the publisher typically has had digital versions in the past so I'd
expect there to be one when it's finally available for sale.

------
chrisdotcode
There's a common saying that, "Everything about Go is great - except the
language".

I guess a book written by Kernighan himself shows how wonderful the ecosystem
is.

~~~
GUNHED_158
It's in no way "common" saying!

------
ProfOak_
So when do we start calling this K&D?

------
wyc
Well, goodbye $40.

