Rob Pike interview • Hacker News Board

Re: Rob Pike interview

#51

Post by seneca » Thu, Apr 30, 2020, 4:15 PM UTC

cletus wrote: post #26

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 unintenti…

A couple of nitpicks.

> More to the point, users of [Kubernetes] don't really use Go as a result, right?

Yeah, they do actually. The vast majority of tooling in the Kubernetes space is also written in Go. I don't know about etcd.

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

I might be missing what you're saying here, but Goland has been around for a decent while now, and the full IntelliJ plugin has as well. Before that, Atom or vi with some plugs I've since forgotten the name of worked well enough.

I agree with your overall points though, especially on dependency management.

Re: Rob Pike interview

#52

Post by cletus » Thu, Apr 30, 2020, 4:16 PM UTC

k__ wrote: post #41

cletus wrote: post #26

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 unintenti…

"anyone who had done any systems programming at all knew that garbage collection made any systems language a nonstarter." This is quite funny. I remember when Go was released its creators were all like "GC is good enough now" and then Rust came around the corner blowing that whole premise out of the window.

I guess every language has its devotees. Go is no exception. My own personal experience with talking to more than a few of these people were that they tended to be a bit... naive and overly optimistic, which is fine, but often the lessons of history were ignored.

The way I like to put it is Go devotees operate under 2 rules:

1. Whatever your complaint about Go is, it's totally not a problem (eg stop-the-world GC pauses, a longstanding issue that any experienced Java engineer could commiserate at length about);

2. Even if it is a problem--which remember it is not--it's totally fixed in Go 1.(N+1) where 1.N is the current version.

Re: Rob Pike interview

#53

Post by throwaway894345 » Thu, Apr 30, 2020, 4:16 PM UTC

alexeldeib wrote: post #37

q3k wrote: post #14

Earlier quoted context omitted.

Not great as is. Rust does not have a comprehensive story for CSP concurrency like Go has. It does have a fair share of libraries/ecosystems (like Tokio), but not having something built in means that you have to hunt for the right set of libraries to work together. Meanwhile, in Go, every single library will just work with its concurrency model out of the box.

I write in Go daily and I've been ramping up on Rust. While CSP isn't built into the language, Crossbeam, Flume, and others are more than enough to fill the gap. If anything, I find Rust returns flexibility to me in programming choice that Go made me forget I had. There are places where library support in Go is still richer, but language support has been stellar across the board in Rust.

I write Go daily, and I don't think CSP really panned out. For most applications, I find it's much easier to use a mutex and standard threading tooling than channels/CSP. That might be an artifact of how channels are implemented and their many hidden error cases--perhaps a better channel implementation could change the calculus. There are lots of reasons to prefer Go to Rust IMO, but I don't think CSP is among them.

Re: Rob Pike interview

#54

Post by [deleted] » Thu, Apr 30, 2020, 4:16 PM UTC

cletus wrote: post #26

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 unintenti…

[deleted]

Re: Rob Pike interview

#55

Post by zozbot234 » Thu, Apr 30, 2020, 4:17 PM UTC

jpgvm wrote: post #12

DevopsQuestions wrote: post #7

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

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.

Concurrency and async in Rust has improved a lot as of late. See https://areweasyncyet.rs for an overview of this space.

Re: Rob Pike interview

#56

Post by throwaway894345 » Thu, Apr 30, 2020, 4:17 PM UTC

patrickaljord wrote: post #23

renewiltord wrote: post #5

Through kube and terraform? Are there other major tools?

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

And pretty much everything that Hashicorp has built since vagrant.

Re: Rob Pike interview

#57

Post by pacala » Thu, Apr 30, 2020, 4:17 PM UTC

cletus wrote: post #26

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 unintenti…

There is 'kernel device driver' kind of systems, and there is 'kubernetes module' kind of systems. Most of the modern infrastructure work happens for the latter use-case. GC is a very reasonable choice, provided you know what you're doing.

Re: Rob Pike interview

#58

Post by frank2 » Thu, Apr 30, 2020, 4:17 PM UTC

cletus wrote: post #43

floren wrote: post #35

Earlier quoted context omitted.

> 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. Yeah, Rob Pike and Brian Kernighan definitely lacked experience in C and systems programming.

AFAIK Brian Kernighan was never involved with the development of Go. He just likes to try new things and wrote a book about it. Rob Pike is probably most famous for his involvement in Plan9 (prior to this). I honestly don't know what this experience entailed.

Mostly systems programming. In particular, he wrote its graphics system, then rewrote it, then rewrote it again. He led Plan 9 for many years. So, he has plenty of experience in systems programming.

What he seems to lack IMHO is sufficient curiosity about computing innovations not produced by him or the prestigious institutions he has worked for (Bell Labs, Google).

Re: Rob Pike interview

#59

Post by batiste » Thu, Apr 30, 2020, 4:18 PM UTC

wdroz wrote: post #10

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

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.

Re: Rob Pike interview

#60

Post by gorgoiler » Thu, Apr 30, 2020, 4:18 PM UTC

empath75 wrote: post #28

gorgoiler wrote: post #11

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 fee…

> I had to do a lot of work to get the code to compile again. That's fine, in most cases, writing python code, you find out that you fucked up when you run the script. Compiler errors catch whole classes of errors that you ordinarily wouldn't find unless you ran the code.

My experience was that I would have an idea for a new model and change my code. Later on I would find that new model would be flawed, but only after fixing compiler type errors in many different places when all I really needed to find was that one error that showed my model was flawed.

I should add that it’s heartening Pike actually acknowledges this in the interview, regarding limited typing and how it helps playfulness in languages like Python and Ruby.