
Google's ‘Gopher Team’ - suchabag
http://www.wired.com/wiredenterprise/2013/07/gopher/
======
Robin_Message
No they don't. One guy started a major rewrite of a broken piece of
infrastructure, and "the Go team [which he is part of] now regularly
volunteers to help other teams with small projects", so as to learn more about
how Go can replace and augment existing systems.

This headline is so far beyond journalism as to be a joke. It's just making
shit up for the sake of having a "story".

I can imagine it now. They heard "gopher", thought of another animal, then
thought about how awesome some of the coders on the Go team are (look at the
blinking lights!), and BAM! invented an elite squadron of coders who fix
whatever problem you have based on a combination of the navy Seals and the
A-team.

~~~
eliben
Yep. I wouldn't surprised to see this article come from some other outlet; I
did not think it's already time to add Wired to the "yellow media" bucket
(though last week's article about LLVM being the last thread holding Google
and Apple together just about did it)

~~~
girvo
Wired really depends on the author, IMO. I still enjoy Threat Level

------
edw519
_If code doesn’t receive constant love it turns to shit,_

I would prefer "If _bad_ code doesn't receive constant love it turns to shit"

I am aware of thousands of examples of heavily used commercial software that
hasn't been touched in 5, 10, 15, even 20 years because it just works and
always has. Properly designed and written scalable software can last
indefinitely with little or no modification, even through geometric changes.

But I like OP's quote. I think it should become part of every code reviewer's
checklist:

    
    
      Will this turn to shit without constant love?
      No:  Pass.
      Yes: Then fix it now.

~~~
acqq
It doesn't work that way. The underlying assumptions change. The program can
be perfect but still not matching what becomes necessary in a few years. The
example they write about is exactly such a kind. Sometime in 2007 it was
apparently slow to access files from the distributed storage on Google.
Therefore, a Python script was written to fetch these files to some local
disks. Python was obviously enough since that process was slow. Then, another
program, written in C++ was to deliver the files from the local disks to the
clients. The C++ program was then "sub-optimally" maintained, simply because
it wasn't on the critical path for the company. There weren't even the good
test cases to verify correctness of the changes.

Still, until 2013 a lot of assumptions based on which the program was written
changed completely: Accessing files from the distributed storage became
faster. The typical computer which is to deliver the data seems to have much
more free RAM, allowing using RAM for caching purposes instead of the local
hard disk. The nature of the load changed so much that accessing the local
hard disk became the bottleneck anyway. Which is not so surprising: one disk
seek is still around 10 ms, which means as soon as you can't deliver something
from RAM you can deliver only up to 100 items from the disk per second, when
they are not in the same block of data.

Don't tell me you have to write the program for "all possible assumptions."
Unless you have unlimited time, you write it to solve the problem under
existing assumptions. Once they change, you change the implementation.

Moreover, to achieve the changes related to the underlying assumptions, Go
wasn't needed in the current example, but it was the most convenient approach
for Brad, who is by the way obviously an extraordinary programmer.

What I agree with you is that if the program is bad even under the initial
assumptions, it's certainly something that should be observed and tracked by
the good manager: he must know that he can't rely on such program and that
whenever the program gets any heavier load, the problems will happen.

~~~
dman
Not all software operates at scale. The backwards compatibility fostered by
posix and wintel has meant many such applications have been silently doing
their jobs for many years without (m)any changes.

~~~
acqq
Yes, when the underlying assumptions don't change and the program is already
good it will remain good. The point is that the changes of the underlying
assumptions can make even the once perfect program one that's suddenly
unusable and it's impossible to cover all future possibilities. Targeting
realistically is the only way to make the good program at the start.

------
general_failure
I hope all journalism majors are sitting up and reading this carefully. This
is how you make a nice imaginative story out of a small interview. A good
story/link bait needs something in desperate need ('lousy code'). Then it
needs a hero ('gopher team'). Then it needs a title which will catch people's
attention (people can't help reading about 'google'). Creative journalism at
it's best.

In case it isn't clear, the only store here is that one guy wrote Google's
download server in Go because it was not working well. That's it, that's the
only story. Google doesn't send some task force or anything like that.

------
outside1234
Its totally untrue that Google uses open source first before writing something
themselves. Literally, the whole infrastructure is custom google goop and it
can take a noogler months before they can do the most basic task.

You can see this in the response to "we can't serve files correctly" in that
there was to rush in write new code in a Google language (Go), as if there
weren't thousands of existing ways to solve this with an open source component
already.

------
stuartcoope
These slides from Brad Fitzpatrick himself on the subject were a lot more
informative:

[http://talks.golang.org/2013/oscon-
dl.slide](http://talks.golang.org/2013/oscon-dl.slide)

~~~
inaudible
Thanks. This form of internet journalism really irritates me, trying
desperately to create a compelling narrative out of fairly dry technical
parts, only to end abruptly to some upbeat testimonial - it reads more like a
poorly written press release.

------
will118
Discussion from 2 days ago:
[https://news.ycombinator.com/item?id=6110398](https://news.ycombinator.com/item?id=6110398)

------
ancarda
I really don't understand why dl.google.com isn't just running Nginx or some
web server. It's just serving files. Why does it need software written in
house?

~~~
skriticos2
Nginx was built with 'single server' architecture in mind while Google
generally operates on a 'distributed everything' architecture. This involves
stuff like distributed file systems/data stores. My guess is it's not
compatible with the single file system interfaces of Nginx. Also note that
dl.google.com serves stuff on a massively bigger scale than the majority of
the rest of the internet. On that scale I'd guess they face some rather
uncommon challenges and bottlenecks that can only be addressed by custom
software.

~~~
x1024
True, but a static-file server _should_ be trivially scalable. That is,
scalable by placing it behind a load balancer(or using any number of
alternative methods that don't acutally touch the server itself). Even if the
server implements Access Control, it should still be trivially scalable.

Also, nginx doesn't have such...interesting ideas as the custom server:
[http://talks.golang.org/2013/oscon-
dl.slide#19](http://talks.golang.org/2013/oscon-dl.slide#19)

I mean, if by "rather uncommon challenges" you're referring to the "what are
threads?" design philosophy of the original... then yeah, it does require
"custom software".

------
16s
Have any heavy C++ devs switched to go? What's the major advantage/compelling
reason to switch? It seems to me that Go is more comparable to Python/Ruby and
Java on the Web, but maybe I'm wrong.

~~~
ihsw
* No circular dependencies (big win here)

* Package importing is easy and a first-class language structure

* Fast compiles (related to no circular dependencies)

One of the more controversial features is no inheritance -- only composition.
It's an interesting break from vertical/horizontal inheritance schemes.

------
VikingCoder
"The team was able to make many improvements to the way the language handles
clustering and file transfers."

Either the journalist had no business writing this sentence, or the people who
designed Go put things in the language that should have been in the libraries.
Or both.

------
WestCoastJustin
I think this was initially reported in 2012 [1], because I remember reading
about it a while ago. While I was Googling about for the link, I came across
the "dl.google.com: Powered by Go" slide deck [2].

[1] [http://grokbase.com/t/gg/golang-nuts/12asyfnbea/go-nuts-
dl-g...](http://grokbase.com/t/gg/golang-nuts/12asyfnbea/go-nuts-dl-google-
com-now-served-by-go)

[2] [http://talks.golang.org/2013/oscon-
dl.slide#1](http://talks.golang.org/2013/oscon-dl.slide#1)

------
osth
"If code doesn't receive constant love, it turns to shit."

But it sounds like this code was receiving "love", only the "love" was coming
from run-of-the-mill "just get it to work" C++ programmers.

I guess we need context to understand Fitzpatrick's statement. Perhaps he just
means code at Google.

Are there any examples of code that has survived for many years without
"constant love"? Netcat has not received "constant love" over the years. It
hasn't turned to shit. Neither has the original awk. I can think of many other
examples. These programs have proven to need very little maintenance.

I posit that simple programs that are well written do not need "constant
love". They only need love when there's a bug. And there are plenty of
programs that are in constant use where no bug has been discovered for many
years. The bugs were vetted and fixed early on, decades ago.

Hence I disagree with Fitzpatrick.

------
coldcode
Maybe they should take a look at feedburner.

------
contol-m
They should really dispatched to fix the Google Drive Client program for Mac.
It consistently maxes out a CPU even when there is no sync going on. I can
consistently reproduce this issue on all Macs I own.

------
MaysonL
Ah, the joys of language PR. Alan Kay was right when he bemoaned the eternal
pop culture of programming.

