Live data from Hacker News

Rob Pike interview

evrone.com

221–230 of 273 posts

Re: Rob Pike interview

#221
post #210

Earlier quoted context omitted.

In general good "experienced professional programmers" don't have one "tool of choice" but their tool of choice varies by what they're doing. I would choose Go for a lot of things, but not for everything.

Whilst I generally agree with this it's definitely the case that experience leads you to prefer certain tools over others even when they may both be usable for a specific task. i.e Go is relatively well suited for a simplistic web service. But even if I don't expect to need to extend it I would still prefer to write it in something that is more extension friendly than Go. Therein lies the problem. Go actually isn't b…

If you consider all the trade-offs (performance / simplicity / security / etc), and you need to create robust RPC services, whether microservices or outward facing API frontends - Go (to me at least) will be the best choice considering all aspects (C++ may be faster but harder to write/debug in, Java more widely adopted but a nightmare in every other aspect, Python easier but slower and less stable, etc etc).

Think about successful tools use Go - they would have been a nightmare in some aspect in most other languages. Can you imagine Kubernetes in Java? Docker in Python? It shines where it shines for a reason.

Re: Rob Pike interview

#222
post #215
post #198

Earlier quoted context omitted.

Better Java 1.0, yes. Better Java 14, definitely not.

Better as a tool, not as a language. By being uninteresting it removes focus on itself so we can better focus on what also matters: designing, measuring, documenting, fixing what is not code nor software

Java has been doing that for 25 years, still don't see how it is better than Java.

I stop copy pasting code and using code generators around 15 years ago.

Re: Rob Pike interview

#223
post #197

Earlier quoted context omitted.

Go is what Java 1.0 could have been, however we are already on Java 14.

I usually note that it matches up pretty favorably with Java 1.4, and now there are some ten-percent jokes to be made...

I see what you did there. :)

Re: Rob Pike interview

#224
post #111

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…

That is my exact observation as well, whenever I go to use and examine a piece of narrow and self-contained piece of Open Source software I'm not surprised to find the good ones are often written in Go. Some things that come to mind are Hashicorp Nomad, nsqd, InfluxDB/Telegraf, restic, etc. I think the common thread here, and what separates this from internal tools a la "Amazon is 90% Java" is that these tools are Op…

Yeah, because we all know how Google has stayed honest to their "Do no evil" motto. /s

Re: Rob Pike interview

#225
post #25

Earlier quoted context omitted.

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) po…

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

3) Would be true when comparing with pre-C++98, back when C++ compilers shipped pre-processor based macros for writing generic code, and used something like TObject as interface{}.

Re: Rob Pike interview

#226

Earlier quoted context omitted.

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

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.

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

Re: Rob Pike interview

#227
post #210

Earlier quoted context omitted.

Whilst I generally agree with this it's definitely the case that experience leads you to prefer certain tools over others even when they may both be usable for a specific task. i.e Go is relatively well suited for a simplistic web service. But even if I don't expect to need to extend it I would still prefer to write it in something that is more extension friendly than Go. Therein lies the problem. Go actually isn't b…

If you consider all the trade-offs (performance / simplicity / security / etc), and you need to create robust RPC services, whether microservices or outward facing API frontends - Go (to me at least) will be the best choice considering all aspects (C++ may be faster but harder to write/debug in, Java more widely adopted but a nightmare in every other aspect, Python easier but slower and less stable, etc etc). Think a…

> Can you imagine Kubernetes in Java?

Yes, I can, that is how it was originally prototyped and due to pressure of Go advocates on the team it got rewritten in Go.

However given that Go type system isn't as advanced as Java, the result wasn't the best one.

"The clusterfuck hidden in the Kubernetes code base"

https://archive.fosdem.org/2019/schedule/event/kubernetesclu...

"Fixing the Kubernetes clusterfuck"

https://fosdem.org/2020/schedule/event/kubernetes/

Re: Rob Pike interview

#228
post #178

Earlier quoted context omitted.

I thought Uber was node.js company (to the point that they had to rewrite existing solid projects, because they weren't in node.js) As for Dropbox I was convinced primary language was Python.

DropBox: https://news.ycombinator.com/item?id=11284051 Their switch from Python to Go was pretty well documented on their engineering blog, but I can't find it, other than comments on HN like the one above.

They are also using Rust nowadays.

Just like they use JavaScript, Swift, Java and Kotlin for mobile development.

Re: Rob Pike interview

#229
post #27

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.

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.

Kubernetes was prototyped in Java and it isn't as if the Go rewrite was without pain.

"The clusterfuck hidden in the Kubernetes code base"

https://archive.fosdem.org/2019/schedule/event/kubernetesclu...

Also they are quite heavy users of //go:generate.

Re: Rob Pike interview

#230
post #65

Earlier quoted context omitted.

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

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

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.

Post reply on HN