
Rob Pike interview - Evrone
https://evrone.com/rob-pike-interview
======
vpner
> Although it's far from certain, after over a decade of work it looks like a
> design for parametric polymorphism, what is colloquially but misleadingly
> called generics...

What exactly is misleading about generics?

The psychology of thought leaders is fascinating. The term generics is
colloquially understood to mean parametric polymorphism and here's Pike
redefining the term to draw some distinction that doesn't really exist just to
remain self-consistent.

Come to think of it, this is a really common pattern. If you've made remarks
that you must now backtrack then refine terms until your old writing doesn't
seem to contradict your current stance because you can just say people were
using the terms wrong and you were right.

Some results for searching "generics": [https://docs.microsoft.com/en-
us/dotnet/csharp/programming-g...](https://docs.microsoft.com/en-
us/dotnet/csharp/programming-guide/generics/),
[https://www.typescriptlang.org/docs/handbook/generics.html](https://www.typescriptlang.org/docs/handbook/generics.html),
[https://docs.swift.org/swift-
book/LanguageGuide/Generics.htm...](https://docs.swift.org/swift-
book/LanguageGuide/Generics.html), [https://doc.rust-lang.org/rust-by-
example/generics.html](https://doc.rust-lang.org/rust-by-
example/generics.html). If you search for "Wadler generics" then a book about
generics in Java is the first result: [https://www.amazon.com/Java-Generics-
Collections-Development...](https://www.amazon.com/Java-Generics-Collections-
Development-Process/dp/0596527756).

~~~
steveklabnik
(Also, once Rust gets specialization, our generics will no longer be
parametric.)

~~~
vpner
I don't think Go's proposed system is parametric either. It's not clear to me
how their contracts actually map to generics so I have no idea if Pike is
telling the truth or just "thought leading".

------
REALiSTiC
What a wild generalization. I skimmed the article, and I see his point in "Go
was designed by people working at Google to make it easier to write Google-
relevant software, in particular network-resident servers", but that doesn't
mean Docker and Kubernetes (and other tools that enable communicating
with/usage of cloud infrastructure) being written in Go made it become the de-
facto standard, and especially not "the language of cloud infrastructure".
What about ALL the other components NOT written in Go?

~~~
jrockway
Go certainly has a lot of mindshare in this space, and that can't be ignored.
Some components of my production infrastructure I've used over the last year:
cert-manager, concourse-ci, docker-registry, cilium, coredns, loki, grafana,
prometheus, jaeger, influxdb, kubernetes, open-policy-agent; all those are Go.
It's at the point where if you're in the business of writing software to run
software, you're kind of surprised if you show up at some Github repo and it's
not written in Go.

But, the joy of 2020-era design is that nothing is forcing you to use Go.
Everything is coupled with network APIs these days, so you can generate your
protocol buffers for whatever language you want and write your chunk in that.
You don't have to look at the success of Go in this space, think "but I don't
like it", and leave the field. You can do whatever you want. But, I do think
it's accurate to say that Go has a lot of mindshare in this sphere of the
Universe. It is what it is.

~~~
lostmsu
Huh? I am sure 80%+ of AWS is Java and probably 90%+ of Azure is C#. I doubt
it is going to change any time soon. Kubernetes is but one successful cloud
product out of Google, and it just happened to be written in Go. There are
even rumors in that thread about it starting as Java.

~~~
khuey
Go is reasonably big on the open source side of the cloud space.

~~~
lostmsu
Not sure what you mean by "open source side" of the cloud space. PostgreSQL is
still C, and Mongo is still C++ + Node.js.

~~~
tapirl
The two don't belong to "cloud infrastructure".

~~~
lostmsu
The conversation is about "cloud space".

Also, by restricting to open source you dropped 2 biggest and successful
players.

------
juskrey
* in companies that are using Go for cloud infrastructure

------
gorgoiler
Go is the language that made me realize I’m not much of a production quality
software engineer.

Normally I would be quite happy riffing with ideas in Ruby or Python, and just
running my code and iterating trying to figure out what to do.

When I tried this in Go, every time I wanted to change the shape of my code to
try doing things slightly differently I had to do a lot of work to get the
code to compile again.

I feel like a professional coder wouldn’t hit that road block because they’d
have a better idea what they were doing in the first place.

I have scurried back to Ruby with my amateur tail between my legs, but I hope
to try Go again some day and find a style that’s a bit more forgiving of my
not-Staff-SWE skills.

~~~
jpgvm
This isn't true at all.

Go is not the tool of choice for experienced professional programmers for
exactly this reason.

The ability to quickly refactor code is very important and Go fails at it
horribly for a number of reasons. 1) sheer verbosity. 2) multiple return makes
altering function signatures tedious. 3) no generics mean code is written in
hard to refactor styles out of the box 4) poor reflection support 5) poor
tooling compared to professional grade languages (Java/C#/etc)

I could go on but long story short it's not you, it's the tool.

These issues can be overcome by remaining vigilant but for the most part they
are part of the accepted "cost" of Go.

Which is to mean you pay them in return for a language that is very easy to
learn (albeit hard to master because of the above problems), has a great
runtime and has reasonable out of the box performance and memory footprint and
stellar compile times.

These tradeoffs can actually be right for some teams, i.e larger ones with
less experienced engineers that can afford to spend more cycles doing busy
work refactorings.

However it's often a poor fit for small teams trying to work on software that
is evolving quickly and can benefit from features of more powerful languages.

~~~
dnautics
> Go is not the tool of choice for experienced professional programmers for
> exactly this reason.

that's really funny, because I always thought of Go as the language that
programmers who were aging out flocked to because it has

1) google-cred

2) familiar algol syntax

3) close enough to C++ to make a run for it

4) (systems-wise) safe enough to make it worth it

5) hip enough that you don't seem like an aging out programmer anymore

(I myself am an aging out programmer, that ironically just got started, so
take that as you will)

But my observation is from 5 years ago and things may have changed.

~~~
cy_hauser
I had always thought the same thing about high use by aging out coders. Don't
know how representative it is but the just released Go annual survey results
seem to show that isn't the case.

~~~
pjmlp
We are busy keeping Java, .NET and C++ codebases running.

------
qppo
This interview was refreshing to read and the comment section far too toxic
for the content.

~~~
ppipada
Generally speaking, hackernews comments related to Go have become toxic since
last year or so. For some reason people seem to actually display hate.

------
pitterpatter
Clearly doesn't know Azure is held together with tape made of C# and
powershell :P

~~~
vmchale
also hdl, no?

------
rootsudo
Really? Outside Google, I'm not aware of major orgs that use GO.

I see the same .net C# stack, python, Ruby...... Java and PHP.

~~~
kjksf
How hard are you looking?

Facebook, Dropbox, Uber, Apple and literally thousands of other companies, big
and small, use Go.

~~~
apta
And those companies generally use C++, Java, etc. in a much larger capacity.

~~~
tapirl
This not true for new companies, for example, Dropbox and Uber.

~~~
apta
Those are more the exception than the norm, and their decisions to do so come
at significant costs.

~~~
tapirl
At least from what I know, Go is an important factor making
Dropbox/Uber/Cloudflare succeed. Go is absolutely not an exception in
successful startups.

~~~
apta
I know people in at least one of the companies you mentioned, and things look
very different on the inside. They succeeded despite of the language, not
because of it.

~~~
tapirl
Surely, "it is not because of", every language is ok. But experienced
programmers will choose the most suitable (most efficient, either in runtime
performance and development speed/quality) one they think.

------
vmchale
the language of choice for people who enjoy writing a sort function five
times.

~~~
kubanczyk
Actually - writing the copy loops for arrays a hundred times.

The sorts are in stdlib.

~~~
_ph_
copy is also a standard function.

------
brobdingnagians
This sounds like him trying to do PR to get everyone thinking everyone else is
already doing it so they try to catch up. Act like something is true to make
it true when everyone jumps on the bandwagon.

~~~
smt88
I disagree. I've noticed that a lot of infra tools that would have been
written in Python 5 years ago are now in Go.

I know Docker is written in Go, and I believe the Kubernetes ecosystem uses it
heavily, so those are compelling evidence for Pike's argument by themselves.

~~~
searchableguy
And I know many small and medium level go projects being rewritten in rust.
Maybe rust is the future.

Deno comes to mind.

~~~
throwaway894345
These tend to be applications with very high performance requirements,
including Deno. It seems to me that the choice between Go and Rust is
_generally_ a matter of whether you value iteration velocity more than peak
performance or correctness.

------
servercobra
A few fellow OpenStack developers and I half-jokingly suggested we rewrite
some or all the services in Go. Python gets to be a bit hard to deal with at
that scale.

~~~
fcantournet
I used to work at an Openstack shop (small public cloud) We considered this
several times, very much not-jokingly. Ultimately the investments never came.
At least for Swift the object-server was re-written in go as an alternative
implementation.

~~~
servercobra
Heh ours started out as "We should rewrite Nova and Neutron and then
Ironic..." That's awesome that Swift was. I always felt like Swift was one of
the more solid services, but maybe that's because I rarely had to deal with
it.

We actually did write and deploy a small Go rescue agent for bare metal
machines in Ironic. I'm not sure if that every got upstreamed though.

------
DevopsQuestions
What are the chances of Rust or another language coming to the fore for cloud
infra?

~~~
jpgvm
Reasonably high. There is a good deal of frustration with Go from experienced
programmers that worked with it for several years and grew tired of the tedium
involved.

Rust has some obstacles to overcome to supplant Go on a wider scale though.
Namely compile time and learning curve - especially in relation to concurrency
and async which are key features to replacing Go as it's main draw is it's
green runtime.

~~~
throwaway894345
I'm not seeing that. It seems like there's lots of enthusiasm to use Rust, but
that people can't justify choosing it over Go probably because Rust is quite a
lot more tedious than Go and its strong performance and correctness guarantees
aren't worth the tradeoff for very many applications. I'm hopeful that things
like rust-analyzer will help close that gap, but I don't think it will ever
completely close much less reverse.

~~~
jpgvm
This is true. It's worth remembering why Go got it's shot though which is at
the time of Docker being written it was originally written in Python. A few
members of the container/orchestration community pushed to try writing it in
Golang as Golang was also new and combining the enthusiasm of 2 communities
was likely to result in greater success (turned out to be correct).

On the other hand Rust hasn't had an oportunity for a killer app, in fact it's
main sponsor project Servo/Firefox is pretty much the opposite. It's a
browser, the definition of a complex and slow moving behemoth of a project.

I attribute Rust's slow takeoff compared to Go mostly to this phenomenon.

After Docker was written in Go and started popularising containers outside of
the lxc/openvz/other hardcore guys doing their own stuff directly on top of
the kernel APIs then it was only natural that stuff would want to integrate
with Docker and using the same language was a way to capture some of that
enthusiasm. This resulted in software like Flynn, Deis and Kubernetes all
picking Golang. The resulting network effect is very strong.

To some degree this is also down to the strength of the Go standard library.
It has an excellent HTTP and TLS stack, encoding/decoding etc. All of this
made it a good fit to write software that is fundamentally fairly "dumb" quite
quickly. i.e software the mostly shuffles bytes from one socket to another.

Rust will most likely not find such a killer app so I think people need to be
realistic about how long it will take Rust to find a marketshare. The big
difference though is one can actually make good arguments to use Rust over
C/C++ where you can't in most cases for Go. C is the largest software
ecosystem right now and Rust is best positioned to take some of this market
share away.

~~~
pjmlp
Rust's killer app will come from OS vendors support, like Microsoft and
ironically Google (Fuschia and Crostini).

However while I like Rust, it seems that it will become more of a C++
companion than a replacement, as it will take quite some time to get a
foothold on systems where C++ is finally replacing C as of the last decade.

------
wdroz
Because of kubernetes, the "language" of cloud infrastructure is YAML...

~~~
batiste
Lord I hate YAML. 10 years after seeing for the first time I still haven't
memorised the intricacies and feel unsafe modifying any file.

~~~
linuxftw
Just take the time to learn it, it's really trivial once you take the time to
learn the basic types. You have lists, dictionaries (maps), and primitives. It
could not be easier.

~~~
dnautics
I think the real problem is that yaml encourages you to make things
declarative (which is 99% of the time a good thing) but sometimes hiding
complexity is the wrong thing, and so when you have clashing declarations, the
imperative resolution path is not necessarily explicit, and hidden behind an
operations layer that you can't really see or reason about.

For some reason YAML seems to be an attractive option to try to implement
things that really should be imperative in a declarative sense. Other
configuration languages are either semi-imperative (like the hashicorp stuff)
or don't do that (I haven't seen TOML configs that do some of the thing that
YAML does). My best guess is it's purely cultural, because that trend started
with ansible, which, not to denigrate - in many ways did very good things.

The trouble is that 1% of the time always hits at a very inopportune time.

~~~
linuxftw
Markup languages are by their nature declarative. Take HTML, for example.
You're providing a set of instructions for some other, smarter program to
create some output based on your declarative input.

YAML is no different. You encode some configuration, something else makes it
so.

Ansible kind of muddied things up because it looks like you're doing
imperative things in YAML, but actually, you're doing declarative things and
Ansible is interpreting your YAML in some particular way.

------
zerpelin68
It's funny how everything that bell labs alums have touched has influenced
computing in a way that isn't publicly acked and how the network and namespace
ideas in plan9 and inferno have become foundational to cloud native infra.
Pikes assertions in a couple cases are just wrong or exemplify naivete
however. He is surprised by how a language designed to be opaque to casual
examination, statically compiled and used in a majority of high profile cloud
native applications (where the install is often download and run a go binary
as part of an un-examined curl | sh pipeline) is happily used for malware?
Also interesting how designers of languages who are formerly avid critics of
PL become reticent and opposed to negativity as authors. Finally he touts the
'hard' problem of concurrency that GO offers an unanticipated solution for as
if OpenMP hasn't been around as a functional approach since 98 for concurrent
programming in the HPC and scientific domains.

~~~
5cott0
> a language designed to be opaque to casual examination

Is this really the case? I thought the prevailing wisdom is that Go was
designed to be as simple as possible so newbs can pick it up faster. I find Go
to be quite easy to read and follow along with even though I've never written
a line of it. Rust on the other hand...

~~~
zerpelin68
opaque to casual examination means that you simply cannot read the code. You
would think that a statically compiled binary blob wouldn't be handled as if
it was a perl script, but it is.

~~~
theshrike79
And Perl isn't opaque to casual examination? :D

------
renewiltord
Through kube and terraform? Are there other major tools?

~~~
patrickaljord
Jaeger, prometheus, envoy, coredns, etcd, containerd, notary, linkerd,
drone.io, helm, linkerd, grafana, traefik, caddy, gitea, rancher, moby/docker
etc.

~~~
takeda
Didn't check others, but envoy I'm 100% sure is in C++

~~~
patrickaljord
Oops, sorry got that one wrong indeed.

------
adtac
half the comments don't make any sense anymore because of the title change

~~~
leetrout
Yes. It was a drastic title change- I wish mods (dang?) would note the change
when it happens.

For others the original title was the title of the page:

Rob Pike interview: “Go has indeed become the language of cloud
infrastructure“

------
_wldu
Go is C for the cloud.

~~~
tapirl
Go is a C framework.

------
cletus
I have huge respect for Rob Pike but there's a bit of revisionist history
going on here.

Go was originally envisioned as a systems programming language. It was often
called "a better C". This exposed Rob Pike's lack of experience in the area
(IMHO) because anyone who had done any systems programming at all knew that
garbage collection made any systems language a nonstarter.

Where Go succeeded was completely unintentional (as as often the case): it was
(and is, IMHO) a better Python. Go hasn't attracted C, C++ or even Java
programmers. It attracted Python refugees. So it's no accident the touted use
cases ("cloud infrastructure") are _orchestration_ problems.

But at the same time, "cloud infrastructure" here refers to what, exactly?
Kubernetes? Etcd? I think those could've been written in anything. More to the
point, users of those don't really use Go as a result, right?

I think even Google found that internally Go was cannibalizing Python usage
and little else.

Lots of Go newbies bemoan the lack of generics. I was never one of them. It's
not the problem people think it is (IMHO). I'll be interested to see what this
solution is even if simply means we can stop having having this conversation
about Go not having generics. That alone is a win.

So I think there's two areas where Go screwed up. two big and one small.

The small one is the lack of IDE support. You don't need to write an IDE. You
just need to have sufficient integration into Jetbrains IDEs (at a minimum).

The first big problem--and it still is a problem--is the dependency
management, in that there wasn't a solution to this out of the gate (unlike,
say, Rust and Crate). Like I was shocked the first time I saw import
'github.com/some_random_user/...' I dare you to go look at any even moderately
sized Go project and unravel the levels of dependencies (including repeated
dependencies, which may or may not impact binary size, I'm not sure). It's
kind of a mess.

The second is, oddly, on concurrency or rather multi-core and multi-CPU
utilization. Aren't we still in the GOMAXPROCS environment variable era?
Really?

EDIT: adding this quote from Rob Pike in 2012 [1] as it's a first-hand account
of Go's original design goals:

> I was asked a few weeks ago, "What was the biggest surprise you encountered
> rolling out Go?" I knew the answer instantly: Although we expected C++
> programmers to see Go as an alternative, instead most Go programmers come
> from languages like Python and Ruby. Very few come from C++.

[1]: [https://commandcenter.blogspot.com/2012/06/less-is-
exponenti...](https://commandcenter.blogspot.com/2012/06/less-is-
exponentially-more.html)

~~~
dehrmann
> It attracted Python refugees

Honest question: other than parallelism and performance, what are the main
reasons someone would switch from Python to Go?

~~~
nostrademons
Single deployment binary, static typing, gofmt, and takes "there should be one
and only one obvious way to do it" even farther than Python. It's very easy
for new team members to ramp up on a Go codebase - formatting is standardized,
libraries are standardized, and the language encourages very simple readable
constructs (at the expense of brevity and abstraction, sometimes). That makes
it attractive for companies in their growth stage, where you're working in
teams but still have constraints on fast execution (CPU) and fast execution
(developer velocity).

IMHO Go is still inferior to Python for solo-developer projects.

~~~
cletus
100% this.

My personal view is that dynamically typed languages are largely falling out
of favour with Javascript being the one glaring exception (and even there if I
were starting a project today I'd use Typescript).

On the single deployment binary issue, let me just underline that point with
one word: virtualenv.

~~~
guggle
> On the single deployment binary issue, let me just underline that point with
> one word: virtualenv.

can you expand ?

------
WilliamEdward
A little biased don't you think?

~~~
vpner
You have to be careful with everything Pike says. It's not just limited to Go.

