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

201–210 of 273 posts

Re: Rob Pike interview

#201

Post by CameronNemo »

steveklabnik wrote: post #199
CameronNemo wrote: post #196

Earlier quoted context omitted.

Here are the 58 open source cloudflare projects written in Go: https://github.com/cloudflare?q=&type=source&language=go Compared to the 11 projects they have released in Rust: https://github.com/cloudflare?q=&type=source&language=rust

Yes, we (Cloudflare) use much more Go than Rust. But we do use a lot of both. There are teams that work exclusively in either language, there are teams that do none, and there are teams that do both. (My team actually uses Go, and almost ended up using some Rust, but decided in the end not to, for good reasons.)

>decided in the end not to, for good reasons

Care to elucidate?

Re: Rob Pike interview

#202

Post by wst_ »

sleepydog wrote: post #194
dnautics wrote: post #146

Earlier quoted context omitted.

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

Can you name a few? Genuine question. I've only really written a lot of tests in Python and Go, and I really dislike the python tests I've had to write. I don't think it's so much the language itself, but that python is so flexible with the mocking you can do that it enables code that is really tedious to test. With Go you have much more limited ability to mock things, so there are added constraints for code to be te…

Must be a matter of preference but this is exactly what I hate about godoc. I'd love to use markdown or any other structure, really. Just a wall of plain text is sometimes good, but most of the time bad idea for readability. And the idea of starting each godoc comment with function/variable name is terrible. YMMV.

Re: Rob Pike interview

#203

Post by steveklabnik »

CameronNemo wrote: post #201
steveklabnik wrote: post #199

Earlier quoted context omitted.

Yes, we (Cloudflare) use much more Go than Rust. But we do use a lot of both. There are teams that work exclusively in either language, there are teams that do none, and there are teams that do both. (My team actually uses Go, and almost ended up using some Rust, but decided in the end not to, for good reasons.)

>decided in the end not to, for good reasons Care to elucidate?

Contrary to what you'll hear a lot of folks say on the internet, there are use cases where Go and Rust overlap. My team has a lot of experience in Go, but not much in Rust. It would be useful to gain some experience, as Rust is growing in the org, and we may need to contribute to some Rust codebases in the future.

We needed to start a new service, and there was an initial prototype of the beginning of that written in Rust. Then, the pandemic happened. This means priorities shift. It makes more sense to not try to learn new things while trying to ship new things when there's so many other things going on. Additionally, it was going to be a bit harder to do it in Rust because there were already some useful code lying around in Go for some things that we'd have to port.

I am a PM these days so I have no real bearing on these decisions, but I support my team in their choices, and told them that I would no matter what. I obviously love Rust, but it's not the end-all be-all of languages, and I think the right call was probably made.

Re: Rob Pike interview

#204

Post by SllX »

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.

My friend, my comrade in arms, I have a link[1] for you. If you read only one of these papers, then please just read the first one, but please note the author credits on almost all of them.

[1] http://doc.cat-v.org/plan_9/4th_edition/papers/

EDIT: In the past half hour, the original website went down, I don't think it is related to my link. Here is a different link with the same contents:

https://9p.io/sys/doc/

Re: Rob Pike interview

#205

Post by dehora »

losingthefight wrote: post #171
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…

I am going to disagree pretty heavily with this. You don't give any explanations, evidence, or mention your experience, so let me lead with mine before I explain where I think you are wrong. I cut my teeth in the 90s with C, and have professionally used PHP, Python, Java, C#, Javascript (both server and client side), and have been using Go as my main choice for the past 4 years. I've worked on teams as small as 1 up…

Great to see an answer that provides context and reason for a language preference. By way of reflection on your answers:

1) This is hit and miss for me. I have to read Go code frequently: not every day or even week, and sometimes under incident pressure. It's less verbose than Java/C#/JavaScript, more verbose than Python/Ruby/Scala. But it's sufficiently verbose to require, for me, cognitive discipline to not skim (ie, "I've been skimming, need to go back up" awareness). So when I'm reading go I put my Java/C#/JavaScript hat on not my Python/Ruby/Scala hat. Not a big problem, but it was so, so close to being in the latter camp. For me then, its regularity claims are something of a wash such that I'd like to see some supporting empirical data or summation of anecdote that it does in fact optimise well here and make good engineering tradeoffs.

2) The problem (I think) is being being to skip by the returned values. It's better than return codes in C, but you're not absolutely required to handle them. I suspect trying to patch structured returns onto an algol-like is a dead end, and if we want structured returns, we want to use a language that really induces us to 'process it forward' eg via map/flatmap/case handling, rather than adding ceremony around if. I think Go made sensible and realistic choices here.

3) Lack of generics are a pain, but a pain for writers. Go does not optimise for that concern, except afaict for its core language creators who have escape valves. The conspiracy theorist in me says Go was wait and see on generics (and exceptions, and objects) as a function of when it was incepted, and may now reasonably conclude that generics are here to stay so the language will need to solve for them, but objects and exceptions were good holds. ie, I don't completely buy it required a decade to figure it out, but could buy it took a decade to observe generics are not going away.

4) In Go, this seems to be satisfied by codegen and templated YAML. I wonder if this is generational, in that the need for reflection might be lessened because of how work on cloud/virtualised systems happens (networked services handling data in and out, with regular deployments).

5) Agree. GoLand I find a great tool for reading and delving into programs, and VSCode is a fantastic 'every day carry' for code.

Re: Rob Pike interview

#206

Post by ori_b »

cletus wrote: post #121
harikb wrote: post #79

Earlier quoted context omitted.

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

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

You're aware that the Go allocator is written in Go, right?

Re: Rob Pike interview

#207

Post by patrickaljord »

takeda wrote: post #109
patrickaljord wrote: post #23

Earlier quoted context omitted.

Jaeger, prometheus, envoy, coredns, etcd, containerd, notary, linkerd, drone.io, helm, linkerd, grafana, traefik, caddy, gitea, rancher, moby/docker etc.

Didn't check others, but envoy I'm 100% sure is in C++

Oops, sorry got that one wrong indeed.

Re: Rob Pike interview

#208

Post by dvirsky »

Insanity wrote: post #150
dvirsky wrote: post #136

Earlier quoted context omitted.

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

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.

Re: Rob Pike interview

#209

Post by zerpelin68 »

5cott0 wrote: post #149
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...

opaque to casual examination means that you simply cannot read the code. You would think that a statically compiled binary blob wouldn't be handled as if it was a perl script, but it is.

Re: Rob Pike interview

#210

Post by jpgvm »

dvirsky wrote: post #208
Insanity wrote: post #150

Earlier quoted context omitted.

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

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 better than other tools at most things so if you don't actually have a tool of choice than Go is rarely the best choice assuming you are comfortable with a large range of tools.

Building a database? C++/Rust (arguably JVM) are better choices. Building a correctness critical piece of software? Rust/Haskell are likely better choices if this is your main constraint. Building a big data pipeline? JVM language of choice is probably the clear winner because of sheer ecosystem momentum. Building a large web application? JVM/C# are miles ahead of the competition here. Building a bunch of microservices? This is probably one case where Go actually does reasonably well, if you work hard architecturally to constraint to complexity of each service it can do OK here. Unfortunately, just OK. JVM/C# probably still beat it out here because of better tooling. Building a kernel? C/C++/Rust/D/Zig. GC is a non-starter. Building a browser? See above.

Once again, I could go on. Go can be used for lots of these but all of the tools above are better for each of these domains. So if you are an experienced professional with a wide array of languages at your disposal what are you going to pick Go for?

Post reply on HN