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

141–150 of 273 posts

Re: Rob Pike interview

#141

Post by anthk »

cletus wrote: post #105
mav3rick wrote: post #86

Earlier quoted context omitted.

If you didn't know you should have clarified before making such sweeping statements. Who knew writing an OS would count as systems programming experience.

"writing an OS" is a sweeping, unsupported and inaccurate statement. You can be involved in Linux and, say, write the ext4 filesystem or Wifi drivers. Those are pretty low-level. You could also write shell utilities like ls in probably anything where you're just using OS APIs. Is that low-level? I would say not.

The C, Unix and AWK creators know nothing on low-level stuff.

Please, kid.

Re: Rob Pike interview

#142

Post by msla »

throwaway894345 wrote: post #31
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 th…

> Out of curiosity, which components are you thinking about?

I could start listing off OS kernels, and then I'll move on to device drivers and hypervisors.

"The Cloud" is enabled by the fact we can efficiently separate applications and users running on the same hardware. The software which ultimately enables this is not written in Go... or Rust... or C++... or any other "hyped" language, but it is still an essential part of any cloud service.

Re: Rob Pike interview

#144

Post by dnautics »

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…

> 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 programmer anymore

(I myself am an aging out programmer, that ironically just got started, so take that as you will)

But my observation is from 5 years ago and things may have changed.

Re: Rob Pike interview

#145

Post by hashamali »

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…

Hm, not sure I agree with some of those criticisms:

1) I don't think Go is in the Java (pre 8) realm of verbosity, but I concede it's not as compact as say Python. 2) Technically you can write single return Go but idiomatic Go leans towards immutability so it's not recommended. 3) I've run into the lack of generics a few times, but personally haven't been too hampered by it. This is an entirely valid complaint, hopefully support will be added soon! 4) Some would argue this is a feature. ;) 5) This was more true a few years ago. Now with Go Modules for package management and VSCode + Go extension with full debugger freely available, tooling is much improved.

Re: Rob Pike interview

#146

Post by dnautics »

throwaway894345 wrote: post #138
bfrog wrote: post #42

Earlier quoted context omitted.

Liking Go has nothing to do with being a quality software engineer. Go itself is probably the least software engineering friendly language out there. The goal of a computer language is to express your thoughts and instructions into something a machine can understand. Full stop. Go is absolutely terrible at letting you the human express what you want the machine to do. It has compile time type checks, but then fails t…

> Go itself is probably the least software engineering friendly language out there My experience with software engineering went from "the language (type system, grammar, syntax, etc) is super important!" to "the language is one of the least important considerations in choosing a language". The more important features are tooling and ecosystem. I don't want to have to learn a new configuration language or imperative D…

> Go is a great language for software engineering

Is it though? While tests in go are not terrible, to be a truly effective software engineer (vs just a programmer or dev) you want a very good test and documentation story, and there are languages out there with far, far, better tests and documentation primitives than Go.

Re: Rob Pike interview

#147

Post by wutbrodo »

eropple wrote: post #22
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 would entreat you to not be afraid of Golang. To be frank its adoption speaks to a desire to make software that does not require (or, often, benefit from "staff SWE" skills). Treat it as what it is, a jumped-up, terser, and in some ways gutted Java, and give it another go. It is designed, to a fault--and this is a little pejorative, I absolutely do not enjoy writing Golang because of it--to be not that hard .

This is my impression too. I was at Google when Golang v1 was released, and my friends and I were hobbyist language geeks and decided to play around with it.

We were....not fans. We were already in the habit of writing extremely clean and healthy code[1], and having a language hand-holding and hectoring us into doing things in its narrow, specific way was just too much of a hit to productivity. Now that I work in a C++ codebase full of very smart domain experts but light on engineering expertise, I can appreciate Go's value in certain circumstances, but if you're lucky enough to work with a talented and experienced engineering team, Go is a pain in the ass for anything but beginners.

[1] A habit I'm paradoxically trying to unlearn a little at my newer company, due to being on a different point on the short-term velocity/long-term health spectrum

Re: Rob Pike interview

#148

Post by linuxftw »

batiste wrote: post #59
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.

Just take the time to learn it, it's really trivial once you take the time to learn the basic types. You have lists, dictionaries (maps), and primitives. It could not be easier.

Re: Rob Pike interview

#149

Post by 5cott0 »

zerpelin68 wrote: post #125

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 language designed to be opaque to casual examination

Is this really the case? I thought the prevailing wisdom is that Go was designed to be as simple as possible so newbs can pick it up faster. I find Go to be quite easy to read and follow along with even though I've never written a line of it. Rust on the other hand...

Re: Rob Pike interview

#150

Post by Insanity »

dvirsky wrote: post #136
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…

> Go is not the tool of choice for experienced professional programmers [citation needed]

it's turning into a bit of a theme by people not used to Go to claim this I guess..
Post reply on HN