Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rob Pike interview

evrone.com

Post reply on HN
Print view View original

91–100 of 273 posts

Re: Rob Pike interview

#91

Post by cletus »

riazrizvi wrote: post #69
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 Very interesting, can you elaborate with an example?

So I wanted to find a good source for this and interestingly came across this article from 2011, titled "Go to C: Could Go Replace C?" [1] (HN submission [2]) and this point came up even then [3].

I also found there are subsets of Go aimed at filling this use case because of the GC issue [4] (eg Emgo [5], TinyGo [6]).

The Fuchsia Language Policy [7] also points to this. Fun fact: the networking stack in Fuchsia was written in Go because of Dave Crawshaw, who was (and I assume still is) a big Go advocate. I got into an argument with him once about stop-the-world GC pauses in Go. Anyway, the Fuchsia project has largely been unhappy with this ever since because there is an overhead to using Go that essentially you can't get rid of. Using memory and object pools can solve many but not all problems. And at some point I suspect they'll replace the networking stack with something not written in Go.

[1]: http://www-cs-students.stanford.edu/~blynn/c2go/

[2]: https://news.ycombinator.com/item?id=2535206

[3]: https://news.ycombinator.com/item?id=2535386

[4]: https://github.com/golang/go/issues/29147

[5]: https://github.com/ziutek/emgo

[6]: https://github.com/tinygo-org/tinygo

[7]: https://www.reddit.com/r/golang/comments/f92nkc/golang_is_no...

Re: Rob Pike interview

#92

Post by rakoo »

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…

> it was (and is, IMHO) a better Python

And in my opinion, it is a better Java. It succeeds in the niche where Java is used today: big softwares, shared by numbers of teams, working on different timezones and in different languages, and with varying degrees of skill.

Go is so stubborn it takes the fun out of programming and ironically that's a good thing: when code can't be tied to anything personal, it is much more easily shared with anyone who works on it. I have found that writing Go itself is definitely tedious, sometimes boring, and the fun is not there; _however_, fun is had when you have a working binary that is statically compiled, reasonably devoid of bugs and surprisingly performant. You take joy in actually using pieces of software, not in fine-tuning your formatting rules.

The language itself is boring, but it's the same boring for everyone and it happens to be working well so you tend to focus more on the solution than on the intricacies. This, IMO, is the success of Go

Re: Rob Pike interview

#93

Post by takeda »

gorgoiler wrote: post #60
empath75 wrote: post #28

Earlier quoted context omitted.

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

I'm Python you can also define types in the annotations, and with IDE that understands them it will catch errors, have working autocomplete and make it very easy to refactor.

Re: Rob Pike interview

#94

Post by CameronNemo »

greyman wrote: post #74
bfrog wrote: post #44

Earlier quoted context omitted.

Go has no expressiveness to it. You end up either with a large pile of copy pasted code, code generators, or massively error prone runtime introspection. Go blows up the entire idea of Don't Repeat Yourself. The language actively encourages it.

> Go blows up the entire idea of Don't Repeat Yourself. Yes, this is true. I programm in Go professionally, about 50% of my work time (other half is python). But in many cases, I have found that copying the same code to other places doesn't have that much negative consequences as one would believe.

Refactoring becomes intensely burdensome, often to the point that it is avoided at all costs. Not a great situation when you need to iterate on a design.

Re: Rob Pike interview

#95

Post by throwaway894345 »

cletus wrote: post #52
k__ wrote: post #41

Earlier quoted context omitted.

"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 paus…

This comment is transparently trying to incite a flame war, but I'll try to take it on a more productive tangent.

> eg stop-the-world GC pauses, a longstanding issue that any experienced Java engineer could commiserate at length about

This is a really interesting example, because it shows the lack of nuance in the anti-GC position. By your logic, because Java's 100ms GC pause times have been problematic (and yes, I'm aware that Java's upcoming GC will boast significantly improved pause times and that it's theoretically possible to tune a Java GC for low pause times even if no one has managed it in production) Go's 5us pause times will be equally problematic. Because a pause is a pause, right--why should we muddy the waters with considerations like "duration"?

Single- or double-digit microsecond pause times completely change the conventional wisdom about the kinds of applications GC is suitable for. There are still lots of hard real time applications that Go's GC won't be suited for, but there are many soft real time applications for which Go would be fine (or at least the issues will be libraries or support for target architecture/platform and not GC).

Re: Rob Pike interview

#96

Post by mgummelt »

blablabla123 wrote: post #71
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…

> 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. Already with the release of Go 1 it was quite clear that Go has its best fit as a Server language. I don't think the usage of a language can really be planned. But looking at the previous works of the language authors, it's clear that they worked on solutions for…

> Already with the release of Go 1 it was quite clear that Go has its best fit as a Server language.

CLIs as well. Before Go, how did you build a native CLI in a garbage collected language?

Re: Rob Pike interview

#97

Post by cletus »

mgummelt wrote: post #84
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…

> 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. What exactly do you mean by systems programming? Many successful databases (Cassandra, Kafka, ElasticSearch) are built on the JVM.

I guess "systems programming" is an ambiguous term here like I personally wouldn't call something "systems programming" just because it's server-side.

What I mean is things that are basically kernel-level or embedded.

Re: Rob Pike interview

#98

Post by magila »

zozbot234 wrote: post #47
k__ wrote: post #41

Earlier quoted context omitted.

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

Rust used to be a GC-based language too - very similar to Go in fact. They didn't abandon GC until sometime prior to the 1.0 release, well after Go first came out.

Early on Rust had optional GC boxing before it morphed into Rc/Arc, it never required GC of heap allocated objects like Go/Java/C# et al. Deterministic resource management has always been the default with Rust.

Re: Rob Pike interview

#99

Post by nostrademons »

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…

Go was always intended for writing the type of networked application servers that are common in Google's infrastructure. [I was at Google when it was released - I thought you were too?]

It's succeeded at basically the same niche that it was intended for. The difference, as another commenter points out, is Rob Pike's ignorance of how the world outside of Bell Labs & Google had changed. In the 80s you would've built networked microservices in C. In the 2010s you built them in Python or Node.JS. Hence if you have a new language that's a success in the microservice application-server market, it will end up cannibalizing Python and Node.JS, not C. Python cannibalized Java in the 2010s and late 00s, and Java cannibalized C in the 2000s and late 90s.

Go is still inferior to Python in prototyping, in web development, and in data-science. (I used it for the former 2 while still at Google, and decided it wasn't an upgrade.) But it's superior for production microservices, and that's an increasingly large market these days.

Re: Rob Pike interview

#100

Post by mgummelt »

dehrmann wrote: post #88
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…

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

static types, native builds, cross-platform builds
Post reply on HN