8 ms·

I Want Off Mr. Golang's Wild Ride (2022)

71 points by wheresvic4 3y ago

dankobgd 3y ago
i knew it was about rust before i even opened this
Sukera 3y ago
(2020)
- layer8 3y ago
  (2022) with the update
gnfargbl 3y ago
I have created and maintain a 130k SLOC Go codebase over the last four years or so, and there are a number of things about Go that irritate the shit out of me. I still get bitten by taking the address of a loop temporary on a surprising basis, for example, even though I am acutely aware of the issue. Or, I haven't really found any use for generics yet, because (as best I can tell) it's impossible to specialise and pretty much every potential use-case I have found for generics so far seems to boil down to lots of shared functions and a few specialised functions. None of those real irritations are addressed in this article, which seems to be an extended complaint that Go isn't as portable between Linux and Windows as the author would like it to be. If you're unfamiliar with Go and attempting to evaluate the language, there's not much in here that I could recommend one way or the other. You would be better spending the time on doing the Tour of Go, then reading one of the various "pitfalls" articles.
- afavour 3y ago
  > seems to be an extended complaint that Go isn't as portable between Linux and Windows as the author would like it to be I don't think that's true. The author is using that lack of portability as an example of what they think is wrong with Go: > And they're symptomatic of the problems with "the Go way" in general. The Go way is to half-ass things. > The Go way is to patch things up until they sorta kinda work, in the name of simplicity. And I get the point they're making. The issue isn't that file permissions don't work consistently cross-platform in Go, it's that they can't work consistently cross-platform in anything but rather than add complexity Go has papered over the cracks. If that's an acceptable approach in a core file API who knows how often it's employed elsewhere in the runtime? The following section the post shows this mindset as implemented in monotime and the many potential footguns the official implementation introduces.
  - Joker_vD 3y ago
    > The issue isn't that file permissions don't work consistently cross-platform in Go, it's that they can't work consistently cross-platform in anything but rather than add complexity Go has papered over the cracks. Interestingly enough, C of all languages had enough sense to not require permissions as an argument for fopen(3).
deleted 3y ago
[deleted]
papichulo2023 3y ago
More like a multiplatoform Go vs Rust comparation. Tbh I wouldnt pick Go if the software needs to run on Windows.
progbits 3y ago
Previous discussion with 400 comments: https://news.ycombinator.com/item?id=31191700 https://news.ycombinator.com/item?id=31191700
andrewfromx 3y ago
Like all languages you can make a mess or make something wonderful. It's also really hard to remove your own bias from the project itself and the drama (or lackthereof). I happen to love go, honey moon started in 2016 and hasn't stopped for me yet. Today's commits: https://github.com/andrewarrow/settle-down/tree/main/app https://github.com/andrewarrow/settle-down/tree/main/app Start at welcome_controller.go and follow the flow. Notice no structs for the sake of structs I make heavy use of map[string]any which serializes to json so nicely without any `json` modifiers.
tikhonj 3y ago
The April 2022 update at the end of the article has a good short summary: > If you're looking to reduce the whole discourse to "X vs Y", let it be "serde vs crossing your fingers and hoping user input is well-formed". It is one of the better reductions of the problem: it really is "specifying behavior that should be allowed (and rejecting everything else)" vs "manually checking that everything is fine in a thousand tiny steps", which inevitably results in missed combinations because the human brain is not designed to hold graphs that big. My pet theory is that this corresponds to the "two cultures" of software engineering: do you value up-front work and abstraction to reduce cognitive load and debugging, or would you rather (try to) pay more attention and spend more time debugging to reduce how much you have to learn and think up-front? Go seems pretty firmly in the latter camp. That's exactly why I am not interested in the language either, despite the various things it gets right.
- frodowtf 3y ago
  I don't see how creating abstractions reduces the cognitive load. You create new concepts before you even need them + once you notice that the abstraction was wrong, now it's much harder to reverse.
  - tikhonj 3y ago
    Abstractions reduce cognitive load because they let us consolidate multiple bits of information into a single concept.
    - stouset 3y ago
      I think the fundamental disconnect here between people who appreciate abstraction and those who are seemingly in perpetual fear of it is that we rarely guide engineers on how to make good abstractions. You hear complaints ad nauseam about how abstractions are always leaky, they are confusing, etc. And yet here I am typing this into a text box displayed in a web browser running on top of an operating system and countless libraries, rendered from a mix of content of HTML, Javascript, and CSS source which was delivered over TLS-wrapped HTTP using TCP sockets routed over an IPv4 connection which was repeatedly translated back and forth into Ethernet frames, all on a machine which schedules the execution of binary blobs compiled from a multitude of languages to the AArch64 instruction set onto any number of virtual cores while carefully managing resources like permanent storage, processor cache, random-access memory, guided by electrical signals from a keyboard which are decoded into meaningful glyphs according to my configured layout and character set, all displayed upon an OLED film based upon an HDMI-encoded signal transmitted over a bundle of wires. Which is to say we spend every day comfortably resting upon a truly mind-boggling tower of abstraction layers which—for the most part—work pretty well. So not only clearly can it be done, but it also must be done in order to provide anything like the computing experiences we expect and rely on in day to day life. Rather than shy from abstraction because bad abstractions are bad, we should spend more effort on learning how to design and promote good abstractions, since they are something upon which our entire profession is inescapably built.
boarnoah 3y ago
Doesn't rust suffer from the same, way too wide dependency web? I feel like its an unfortunate consequence of having a good package manager which encourages proliferation of too many very small dependencies.
- layer8 3y ago
  This doesn’t need to be the case. It didn’t happen with Perl (CPAN) and Java (Maven), for example.
  - moojd 3y ago
    Do those allow multiple versions of the same dependency? With npm and cargo (as opposed to composer, etc.) you are never forced to resolve those types of conflicts so you can just keep installing dependencies forever without ever having to trim the tree.
- Thaxll 3y ago
  Actually Go does not suffer from that problem since it has a wide std lib, the original post took a liberate example of something that is not common.
- CoastalCoder 3y ago
  I'm new to Rust, and I noticed this just the other day. I was playing with some Rust-based blockchain system, and the number of external dependencies pulled in (recursively) to build the code truly amazed me. I don't really know, but I'm guessing that a similar C++ project would have required many fewer dependencies. Maybe a C++ code base would tend rely on a small number of big libraries? Or maybe a C++ code base would (for some reason) be more inclined to use binary libraries provided by already-installed Debian packages?
  - Night_Thastus 3y ago
    As a C++ dev, I generally see few but often large dependencies. Boost used to be a large one, but it's less relevant these days with C++11 and onward. There are others like QT, Eigen, GoogleTest, FFMpeg, Intel's OneAPI, etc. Sometimes I see single-header libraries you can just drop in, other times I see large Cmake projects that you add as a dependency to compile when your project compiles. I've never seen the kind of dependency chaining that languages like JS or Go show.
Gordonjcp 3y ago
Mostly this article seems to be whining about Go's file handling being more based around Unix-y stuff, and not really being suitable for Windows file systems. So what? If you don't use it as intended, it might not do what you want. Don't use it on unsupported niche operating systems.
winstonprivacy 3y ago
Ah, Go. I wrote a whole networking stack in it a few years back. I admit, I did get an incredible amount of performance from a very limited bit of hardware with it. However, it was dependency and module hell. Even the Go expert couldn't get it figured out enough to make it compile every time. I'm really glad I got off that ride.
- no_wizard 3y ago
  I wonder if proper vendor support helps with this or not, its relatively recent to Go
deleted 3y ago
[deleted]
divan 3y ago
I see "How to complain about Go" (2015) [1] needs an update. [1] https://medium.com/@divan/how-to-complain-about-go-349013e06d24 https://medium.com/@divan/how-to-complain-about-go-349013e06...
nvy 3y ago
Meta: does flagging and vouching work differently for links than for comments? This account has enough karma for flagging, and I can see the title of this submission is prefixed with [Flagged] but I don't have an option to Vouch. How does that work? I flag/vouch pretty rarely so I'm not always sure.
- jsnell 3y ago
  I think vouch not appearing might be a bug when somebody flags + unflags (I accidentally flagged, then unflagged, and it didn't revert the "flagged" state. Not showing vouch could be related). I've emailed dang.
Night_Thastus 3y ago
The more I read about Rust, the more I've come to respect it. I still think: * It's a specialized tool not suitable for all (or even most) projects * It needs a bit more time to both develop as a language and ecosystem But it's clear that it's not half-assed and a lot of thought went into it. Interesting to hear about Go's development as well. It was starting to pick up when I was in college, and now it's had a few more years. Bit disappointing to see it's so messy.
nunez 3y ago
Great article. This opinionation runs deep into the Kubernetes ecosystem as well (one of, if not the, biggest Golang project out there). Here is an example: https://github.com/kubernetes/kubernetes/issues/53533 https://github.com/kubernetes/kubernetes/issues/53533
nunez 3y ago
I'm surprised the author didn't talk about error handling in Go. That is, by far, my biggest pet peeve with the language. Most languages have try/catch patterns, but Go opted for multivariate returns and a discrete error type...without pattern matching! At least 20% of Golang code I look at is the if err != nil pattern, which is a crazy amount of repetitive boilerplate. I don't think the must pattern is a good alternative either in many cases.

71 points by wheresvic4 3y ago

dankobgd 3y ago

i knew it was about rust before i even opened this

Sukera 3y ago

(2020)

layer8 3y ago
(2022) with the update

gnfargbl 3y ago

I have created and maintain a 130k SLOC Go codebase over the last four years or so, and there are a number of things about Go that irritate the shit out of me. I still get bitten by taking the address of a loop temporary on a surprising basis, for example, even though I am acutely aware of the issue. Or, I haven't really found any use for generics yet, because (as best I can tell) it's impossible to specialise and pretty much every potential use-case I have found for generics so far seems to boil down to lots of shared functions and a few specialised functions. None of those real irritations are addressed in this article, which seems to be an extended complaint that Go isn't as portable between Linux and Windows as the author would like it to be. If you're unfamiliar with Go and attempting to evaluate the language, there's not much in here that I could recommend one way or the other. You would be better spending the time on doing the Tour of Go, then reading one of the various "pitfalls" articles.

afavour 3y ago
> seems to be an extended complaint that Go isn't as portable between Linux and Windows as the author would like it to be I don't think that's true. The author is using that lack of portability as an example of what they think is wrong with Go: > And they're symptomatic of the problems with "the Go way" in general. The Go way is to half-ass things. > The Go way is to patch things up until they sorta kinda work, in the name of simplicity. And I get the point they're making. The issue isn't that file permissions don't work consistently cross-platform in Go, it's that they can't work consistently cross-platform in anything but rather than add complexity Go has papered over the cracks. If that's an acceptable approach in a core file API who knows how often it's employed elsewhere in the runtime? The following section the post shows this mindset as implemented in monotime and the many potential footguns the official implementation introduces.
- Joker_vD 3y ago
  > The issue isn't that file permissions don't work consistently cross-platform in Go, it's that they can't work consistently cross-platform in anything but rather than add complexity Go has papered over the cracks. Interestingly enough, C of all languages had enough sense to not require permissions as an argument for fopen(3).

deleted 3y ago

[deleted]

papichulo2023 3y ago

More like a multiplatoform Go vs Rust comparation. Tbh I wouldnt pick Go if the software needs to run on Windows.

progbits 3y ago

Previous discussion with 400 comments: https://news.ycombinator.com/item?id=31191700 https://news.ycombinator.com/item?id=31191700

andrewfromx 3y ago

Like all languages you can make a mess or make something wonderful. It's also really hard to remove your own bias from the project itself and the drama (or lackthereof). I happen to love go, honey moon started in 2016 and hasn't stopped for me yet. Today's commits: https://github.com/andrewarrow/settle-down/tree/main/app https://github.com/andrewarrow/settle-down/tree/main/app Start at welcome_controller.go and follow the flow. Notice no structs for the sake of structs I make heavy use of map[string]any which serializes to json so nicely without any `json` modifiers.

tikhonj 3y ago

The April 2022 update at the end of the article has a good short summary: > If you're looking to reduce the whole discourse to "X vs Y", let it be "serde vs crossing your fingers and hoping user input is well-formed". It is one of the better reductions of the problem: it really is "specifying behavior that should be allowed (and rejecting everything else)" vs "manually checking that everything is fine in a thousand tiny steps", which inevitably results in missed combinations because the human brain is not designed to hold graphs that big. My pet theory is that this corresponds to the "two cultures" of software engineering: do you value up-front work and abstraction to reduce cognitive load and debugging, or would you rather (try to) pay more attention and spend more time debugging to reduce how much you have to learn and think up-front? Go seems pretty firmly in the latter camp. That's exactly why I am not interested in the language either, despite the various things it gets right.

frodowtf 3y ago
I don't see how creating abstractions reduces the cognitive load. You create new concepts before you even need them + once you notice that the abstraction was wrong, now it's much harder to reverse.
- tikhonj 3y ago
  Abstractions reduce cognitive load because they let us consolidate multiple bits of information into a single concept.
  - stouset 3y ago
    I think the fundamental disconnect here between people who appreciate abstraction and those who are seemingly in perpetual fear of it is that we rarely guide engineers on how to make good abstractions. You hear complaints ad nauseam about how abstractions are always leaky, they are confusing, etc. And yet here I am typing this into a text box displayed in a web browser running on top of an operating system and countless libraries, rendered from a mix of content of HTML, Javascript, and CSS source which was delivered over TLS-wrapped HTTP using TCP sockets routed over an IPv4 connection which was repeatedly translated back and forth into Ethernet frames, all on a machine which schedules the execution of binary blobs compiled from a multitude of languages to the AArch64 instruction set onto any number of virtual cores while carefully managing resources like permanent storage, processor cache, random-access memory, guided by electrical signals from a keyboard which are decoded into meaningful glyphs according to my configured layout and character set, all displayed upon an OLED film based upon an HDMI-encoded signal transmitted over a bundle of wires. Which is to say we spend every day comfortably resting upon a truly mind-boggling tower of abstraction layers which—for the most part—work pretty well. So not only clearly can it be done, but it also must be done in order to provide anything like the computing experiences we expect and rely on in day to day life. Rather than shy from abstraction because bad abstractions are bad, we should spend more effort on learning how to design and promote good abstractions, since they are something upon which our entire profession is inescapably built.

boarnoah 3y ago

Doesn't rust suffer from the same, way too wide dependency web? I feel like its an unfortunate consequence of having a good package manager which encourages proliferation of too many very small dependencies.

layer8 3y ago
This doesn’t need to be the case. It didn’t happen with Perl (CPAN) and Java (Maven), for example.
- moojd 3y ago
  Do those allow multiple versions of the same dependency? With npm and cargo (as opposed to composer, etc.) you are never forced to resolve those types of conflicts so you can just keep installing dependencies forever without ever having to trim the tree.
Thaxll 3y ago
Actually Go does not suffer from that problem since it has a wide std lib, the original post took a liberate example of something that is not common.
CoastalCoder 3y ago
I'm new to Rust, and I noticed this just the other day. I was playing with some Rust-based blockchain system, and the number of external dependencies pulled in (recursively) to build the code truly amazed me. I don't really know, but I'm guessing that a similar C++ project would have required many fewer dependencies. Maybe a C++ code base would tend rely on a small number of big libraries? Or maybe a C++ code base would (for some reason) be more inclined to use binary libraries provided by already-installed Debian packages?
- Night_Thastus 3y ago
  As a C++ dev, I generally see few but often large dependencies. Boost used to be a large one, but it's less relevant these days with C++11 and onward. There are others like QT, Eigen, GoogleTest, FFMpeg, Intel's OneAPI, etc. Sometimes I see single-header libraries you can just drop in, other times I see large Cmake projects that you add as a dependency to compile when your project compiles. I've never seen the kind of dependency chaining that languages like JS or Go show.

Gordonjcp 3y ago

Mostly this article seems to be whining about Go's file handling being more based around Unix-y stuff, and not really being suitable for Windows file systems. So what? If you don't use it as intended, it might not do what you want. Don't use it on unsupported niche operating systems.

winstonprivacy 3y ago

Ah, Go. I wrote a whole networking stack in it a few years back. I admit, I did get an incredible amount of performance from a very limited bit of hardware with it. However, it was dependency and module hell. Even the Go expert couldn't get it figured out enough to make it compile every time. I'm really glad I got off that ride.

no_wizard 3y ago
I wonder if proper vendor support helps with this or not, its relatively recent to Go

deleted 3y ago

[deleted]

divan 3y ago

I see "How to complain about Go" (2015) [1] needs an update. [1] https://medium.com/@divan/how-to-complain-about-go-349013e06d24 https://medium.com/@divan/how-to-complain-about-go-349013e06...

nvy 3y ago

Meta: does flagging and vouching work differently for links than for comments? This account has enough karma for flagging, and I can see the title of this submission is prefixed with [Flagged] but I don't have an option to Vouch. How does that work? I flag/vouch pretty rarely so I'm not always sure.

jsnell 3y ago
I think vouch not appearing might be a bug when somebody flags + unflags (I accidentally flagged, then unflagged, and it didn't revert the "flagged" state. Not showing vouch could be related). I've emailed dang.

Night_Thastus 3y ago

The more I read about Rust, the more I've come to respect it. I still think: * It's a specialized tool not suitable for all (or even most) projects * It needs a bit more time to both develop as a language and ecosystem But it's clear that it's not half-assed and a lot of thought went into it. Interesting to hear about Go's development as well. It was starting to pick up when I was in college, and now it's had a few more years. Bit disappointing to see it's so messy.

nunez 3y ago

Great article. This opinionation runs deep into the Kubernetes ecosystem as well (one of, if not the, biggest Golang project out there). Here is an example: https://github.com/kubernetes/kubernetes/issues/53533 https://github.com/kubernetes/kubernetes/issues/53533

nunez 3y ago

I'm surprised the author didn't talk about error handling in Go. That is, by far, my biggest pet peeve with the language. Most languages have try/catch patterns, but Go opted for multivariate returns and a discrete error type...without pattern matching! At least 20% of Golang code I look at is the if err != nil pattern, which is a crazy amount of repetitive boilerplate. I don't think the must pattern is a good alternative either in many cases.