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

121–130 of 273 posts

Re: Rob Pike interview

#121

Post by cletus »

harikb wrote: post #79
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…

> garbage collection made any systems language a nonstarter. Unless you want to bucket all systsme programming in to one bucket, I will say this #1 If your goal is to make the most efficient and fast code (garbage collected or not), it is not clear gc-less languages are always better. Sometimes, not free-ing the memory at the first possible time will actually be good for you overall. #2 If you are writing anything wi…

> #1 If your goal is to make the most efficient and fast code (garbage collected or not), it is not clear gc-less languages are always better. Sometimes, not free-ing the memory at the first possible time will actually be good for you overall.

Which is why languages like C++ let you write and use your own allocators. There are lots of reasons to do this (eg word alignment).

And while I agree that it's certainly possible that delayed freeing may be beneficial I'm not convinced it's a problem in practice, at least when you compare it to how often common GC problems are (eg memory leaking (admittedly also a problem with manual allocation), out-of-control process memory growth and STW pauses).

#2 If you are writing anything with serious mem usage in Go, you will optimize for allocations using sync.Pool or some other form of reuse.

True, and I mentioned this in another comment: the idea that you can get around many GC issues by using object and memory pools.

> Heck, some of my Java code works faster than even my Go code.

Why should that be surprising? The JVM at this point has >25 years of engineering effort into it and (IMHO) it doesn't get half the credit it deserves from the devotees of the latest flavour of the month.

Re: Rob Pike interview

#122

Post by riazrizvi »

cletus wrote: post #91
riazrizvi wrote: post #69

Earlier quoted context omitted.

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

So there's some conflict, but mainly the problem is that GC is a critical problem in real-time systems that cannot have performance interrupts. Languages for these applications need to be able to bypass GC.

Re: Rob Pike interview

#123

Post by throwaway894345 »

searchableguy wrote: post #61
smt88 wrote: post #27

Earlier quoted context omitted.

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.

And I know many small and medium level go projects being rewritten in rust. Maybe rust is the future. Deno comes to mind.

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.

Re: Rob Pike interview

#124

Post by linuxftw »

REALiSTiC wrote: post #9

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

> What about ALL the other components NOT written in Go?

Those components are either being rewritten in go, or packaged as containers to run on infrastructure that is written in Go.

Re: Rob Pike interview

#125

Post by 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.

Re: Rob Pike interview

#126

Post by throwaway894345 »

centimeter wrote: post #68
nappy-doo wrote: post #32

Earlier quoted context omitted.

use a better editor. VSCode, vim with vimgo, emacs with whatever those apes use.

I shouldn't need an industrial-strength editing engine to efficiently express my ideas. (And don't, if I'm using a nice expressive language.)

Generally speaking, Go is one of the easiest languages to write with a simple text editor. Rust is among the hardest due to its complexity and demanding static analysis. This isn't a bad thing, and tools like rust-analyzer make writing Rust a lot easier. But rust-analyzer is amazing technology from the future; hardly an ordinary text editor plugin.

Re: Rob Pike interview

#127

Post by cletus »

throwaway894345 wrote: post #95
cletus wrote: post #52

Earlier quoted context omitted.

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…

> This is a really interesting example, because it shows the lack of nuance in the anti-GC position.

I wouldn't call my position strictly anti-GC. I would simply say that GC isn't the panacea it's made out to be and it is at least in part a false economy for at least three reasons:

1. You may need to tune your VM/GC parameters (as you mention). There's a cost to this;

2. GC can make it harder to identify memory leaks (which are still a problem through, for example, dangling references). I've worked on C++ systems where we instrumented many things including process size, which was basically just a flat line. As soon as it wasn't, you knew there was a problem. And this was for a server that read about ~6GB/second off a NIC.

3. Crashing a program due to accessing unallocated memory tends to give a more immediate signal of a problem, which is more often than not better for development.

Re: Rob Pike interview

#128

Post by jrockway »

lostmsu wrote: post #78
jrockway wrote: post #36

Earlier quoted context omitted.

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

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.

80% of AWS existed before Go was invented. Why would they rewrite that stuff? They're already #1. They have nothing to gain and everything to lose.

I think to get an idea of what mindshare looks like, you have to look at people that started from nothing today. These are the people that are making architecture decisions with an eye to the future, growth, and immediate productivity. When you're inside a huge org, you have to think about what is easiest to integrate with, and what skills you can get from other teams. At a company that's 80% Java, that's Java. It would be insane to switch, and likely to fail.

Re: Rob Pike interview

#129

Post by rsj_hn »

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.

Many people consider "systems programming" to be close to the hardware stuff that is not visible by users. Userland code would generally not fall into this category, with the weird proviso that some OSs put a lot of GUI code into the kernel (cough windows cough). In this traditional classification, a database is considered an "app". The "find" command is an app. People log in and use the DB and the find command. The Bash shell would be an app. If a user is using it, it's an app.

If it is not user visible but exists to manage app access to hardware resources, it's a system. So a memory management system would not be an app. Neither would power management or IO or a scheduler. But these systems might have administrative apps that admins login and use (like Microsoft's "Control Panel" app -- to control settings for the system code. Similarly some apps might have their own memory management system. But the principle still applies.

I understand there is definition creep as more and more layers sit between the user and the hardware, so todays application code might, in some cases, be viewed as tomorrow's system code, but this is the original meaning.

Re: Rob Pike interview

#130

Post by 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://www.typescriptlang.org/docs/handbook/generics.html, https://docs.swift.org/swift-book/LanguageGuide/Generics.htm..., 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....

Post reply on HN