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

31–40 of 273 posts

Re: Rob Pike interview

#31

Post by throwaway894345 »

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…

I feel like "Go has become the language of cloud infrastructure" is a bit of an inflammatory headline for this forum--I'm sure there are many cloud infrastructure components which aren't written in Go. The ones I think of tend to be AWS services that are written in Java or a handful of odds-and-ends things in Rust like AWS's Firecracker or some of CloudFlare's high performance networking systems. But especially in the open source world, there seems to be a lot of cloud infrastructure written in Go, and it seems to be accelerating. So in a sense I can understand saying "Go is the language of cloud infrastructure", but that framing seems unlikely to yield any interesting conversation.

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

Out of curiosity, which components are you thinking about?

Re: Rob Pike interview

#32

Post by nappy-doo »

jpgvm wrote: post #25
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…

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…

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

Re: Rob Pike interview

#33

Post by throwanem »

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…

Speaking as a professional with 15 years of career in software engineering under his belt: don't be so hard on yourself.

I mean, I don't typically prototype or iterate on ideas in Typescript, either; I do that in Javascript, and reserve strong typing for when I know what I need to build, and it's just a matter of doing so in a way that's reliable, maintainable, and secure.

The point is that flexibility and strictness both have value, and it's more worth knowing which is more useful at a given point in a project's lifespan than trying to be dogmatic about one or the other.

Re: Rob Pike interview

#34

Post by jpgvm »

nappy-doo wrote: post #32
jpgvm wrote: 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…

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

This helps but doesn't solve the core issues. I generally use Goland whenever editing Go code (as I am currently doing sigh) but even with such a powerful IDE the language is the main limiting factor in carrying out refactorings (which again, I'm doing right now).

Re: Rob Pike interview

#35

Post by floren »

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

Re: Rob Pike interview

#36

Post by jrockway »

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…

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.

Re: Rob Pike interview

#37

Post by alexeldeib »

q3k wrote: post #14
DevopsQuestions wrote: post #7

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

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.

Re: Rob Pike interview

#40

Post by zozbot234 »

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…

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

Ha. Try Rust if you like a challenge: at least you will get outstanding compiler diagnostics while refactoring, and far better performance as an end result.

Post reply on HN