4 ms·

Let me preface this by saying I like Go. I do. But as much respect as I have for Rob Pike (which, again, I do), he doesn't understand the systems programming sp

by cletus 2y ago

Let me preface this by saying I like Go. I do. But as much respect as I have for Rob Pike (which, again, I do), he doesn't understand the systems programming space. Go was originally pitched as a systems programming language, a better C, like you said. But it isn't. It is, however, a better Python (IMHO). The reason it's not a better C is that it's a garbage-collected language and it has a runtime overhead. As such, Go doesn't really have predcitable performance. It's easy to blow up memory usage (as it is on any GC language) eg goroutines. So Go just doesn't suit a typical systems or embedded application. Yes, you can use a subset of Go to avoid dynamic allocation and GC in general but really, what's the point in that? Why it's a better Python (again, IMHO) is that Python has all the same negatives but has a few more, most notably that it is dynamically typed or, as I like to put it, you need to write unit tests for spelling mistakes. I've come to abhor dynamic typing as a truly horrendous false economy. Go doesn't have that problem. Go does need to be compiled but it's a simple language and that compilation is incredibly fast. My one criticism is that I find Go's unbuffed channels to be a less elegant coordination mechanism to cooperative async/await in other langauges. But YMMV. Some evidence to back this up is that, at least while I was still at Google, Go projects on google3 were cannibzlizing Python projects and nothing else really.

Capricorn2481 2y ago
Python also has some positives that Go doesn't have, like iterators without the community freaking out about them. It's obviously way more ergonomic to use Python, and if you want types, Pyright works very well. My issue with Go is that it's not low level enough to be good for systems programming but it's not high level enough to avoid boilerplate.
- nkozyra 2y ago
  > My issue with Go is that it's not low level enough to be good for systems programming but it's not high level enough to avoid boilerplate. That's really interesting because in general I find Go faster to work in than Python. Python has great flexibility but even production code I read is littered with noise that I don't see with Go applications. Other than error propagation - which is more a style choice than boilerplate - I find doing something in Go results in fewer lines of code and less spaghetti logic. I'm a bit too dug in on Rust to spend a ton of time replacing it with Zig and my use cases frankly could be handled by a Go app without much worry about performance. But one thing Rust has is boilerplate out the wazoo.
  - Capricorn2481 2y ago
    I have heard this anecdote a few times but I don't understand it. Even ignoring error handling in Go, I feel like everything is noticeably more verbose and noisy than something like Python. A language that prioritizes readability is intriguing to me, but I just haven't experienced that with Go. Not that I haven't seen messy Python code (I sure have). The best Go code is gonna look better than the worst Python. But on average, it seems like complicated flows can be written very elegantly and readably in Python and look ugly in Go.
    - etse 2y ago
      Go isn't pretty to look at, but I feel so much more confident in a successful Go build than starting up Python–not knowing when exceptions will throw or crash until it's run is frustrating. I'm sure Rust folks feel exponentially more safety than Go at compile time, but the jump from Python to Go is dramatic for me.
adamors 2y ago
As someone who used to write a lot of Ruby and now has started to write some Go, I feel like you nailed it. Go is compiled language for people coming from dynamic languages. The type inference is good enough and the compilation types are also quite fast.
mark_undoio 2y ago
> Go was originally pitched as a systems programming language, a better C, like you said. I've always understood this claim as a particular (rather restricted) interpretation of "systems" code - meaning network servers, basically (maybe also CLI applications?) I'd always thought of "systems" as including things like writing standard libraries, kernels and embedded code. But I guess there is a decent slice of other systemsy stuff that Go is good for. Whereas something like Zig feels like it could really be a better systems programming language in general that C, in all of its different application areas.
- stouset 2y ago
  > I've always understood this claim as a particular (rather restricted) interpretation of "systems" code This is basically the retcon that the golang community has settled on but it's frankly not true. When go was originally being promoted it was heavily advertised as a systems language suitable for writing low-level programs. Nowhere was it caveated that "systems language" means something different from what everyone understood a "systems language" to be at the time. Only when it more or less failed to gain traction in that space did this get redefined to mean "network servers that mostly just shuffle bytes around and CLI applications".

by cletus 2y ago

Capricorn2481 2y ago

Python also has some positives that Go doesn't have, like iterators without the community freaking out about them. It's obviously way more ergonomic to use Python, and if you want types, Pyright works very well. My issue with Go is that it's not low level enough to be good for systems programming but it's not high level enough to avoid boilerplate.

nkozyra 2y ago
> My issue with Go is that it's not low level enough to be good for systems programming but it's not high level enough to avoid boilerplate. That's really interesting because in general I find Go faster to work in than Python. Python has great flexibility but even production code I read is littered with noise that I don't see with Go applications. Other than error propagation - which is more a style choice than boilerplate - I find doing something in Go results in fewer lines of code and less spaghetti logic. I'm a bit too dug in on Rust to spend a ton of time replacing it with Zig and my use cases frankly could be handled by a Go app without much worry about performance. But one thing Rust has is boilerplate out the wazoo.
- Capricorn2481 2y ago
  I have heard this anecdote a few times but I don't understand it. Even ignoring error handling in Go, I feel like everything is noticeably more verbose and noisy than something like Python. A language that prioritizes readability is intriguing to me, but I just haven't experienced that with Go. Not that I haven't seen messy Python code (I sure have). The best Go code is gonna look better than the worst Python. But on average, it seems like complicated flows can be written very elegantly and readably in Python and look ugly in Go.
  - etse 2y ago
    Go isn't pretty to look at, but I feel so much more confident in a successful Go build than starting up Python–not knowing when exceptions will throw or crash until it's run is frustrating. I'm sure Rust folks feel exponentially more safety than Go at compile time, but the jump from Python to Go is dramatic for me.

adamors 2y ago

As someone who used to write a lot of Ruby and now has started to write some Go, I feel like you nailed it. Go is compiled language for people coming from dynamic languages. The type inference is good enough and the compilation types are also quite fast.

mark_undoio 2y ago

> Go was originally pitched as a systems programming language, a better C, like you said. I've always understood this claim as a particular (rather restricted) interpretation of "systems" code - meaning network servers, basically (maybe also CLI applications?) I'd always thought of "systems" as including things like writing standard libraries, kernels and embedded code. But I guess there is a decent slice of other systemsy stuff that Go is good for. Whereas something like Zig feels like it could really be a better systems programming language in general that C, in all of its different application areas.

stouset 2y ago
> I've always understood this claim as a particular (rather restricted) interpretation of "systems" code This is basically the retcon that the golang community has settled on but it's frankly not true. When go was originally being promoted it was heavily advertised as a systems language suitable for writing low-level programs. Nowhere was it caveated that "systems language" means something different from what everyone understood a "systems language" to be at the time. Only when it more or less failed to gain traction in that space did this get redefined to mean "network servers that mostly just shuffle bytes around and CLI applications".