4 ms·

We've been using Go at work for 2.5 years now and it has become my primary language of use at this point in time. I hate it. I hate it like hell. It's like they

by idop 9y ago

We've been using Go at work for 2.5 years now and it has become my primary language of use at this point in time. I hate it. I hate it like hell. It's like they decided to take all the things that make other languages good - such as safety, brevity, intuitiveness, versioning and proper project structuring - and threw them out the window. As far as I'm concerned the good things about Go (large community, fairly efficient generated executables) do not outweigh the bad. We've spent so much time fixing obscure bugs and behaviors that betray everything we've learned in the languages we used previously in our careers that it was really not worth it. And we still do. Finding developers is also an issue, as most developers do not really want to learn a new language, and Go is still not that common in enterprises (I used to be like that myself, but I've learned long ago that this shouldn't be such a big factor when thinking about a new job). You can make the case that we're simply not good enough developers or Go is just not a good fit for the type of developers we are. Maybe. But the choices made in designing this language, and its popularity, absolutely baffle me.

JepZ 9y ago
Well, somehow this sounds to me like you are doing it wrong. Yes, you probably heard that before, but when you say things like 'proper project structuring' I think that you probably try to do something in a way that it is not meant to be used. But at the same time you probably have good reason to try that, as that was the way you did it in the past (with other languages). So while Go allows you to quickly learn to write code, it is a much harder challenge to learn how to structure you code in simple small packages. In the end that brings a lot of benefits (testing is easier), but if you try to create a project with very few packages you will go through lot of pain due to the lack of structure. Its very similar with interfaces. Programmers coming from other languages mostly ignore them in the beginning and it takes a while until they understand that exporting types from a package is a failure and that interfaces would have been a much better choice. In my opinion, the key to successful Go development is building many small, well tested library packages while using interfaces a lot.
- idop 9y ago
  Appreciate the comment. I was largely referring to very large projects. When it comes to smaller projects, but really any Go project, we've moved to the structural recommendations in the Go documentation a long time ago, which did improve things a bit, but really there are almost no good examples out there for really large projects. Your point about interfaces is mostly correct though, and we're progressively learning to utilize them better.
dpflan 9y ago
"We've spent so much time fixing obscure bugs and behaviors that betray everything we've learned in the languages we used previously in our careers that it was really not worth it." That sounds very frustrating; I'm sorry your day-to-day became consumed by such things. Would you mind providing an example of such an "obscure bug and behavior"?
- idop 9y ago
  I wouldn't call it my day-to-day, but sure, here are some examples: 1. We have a client component that makes HTTP requests to a server component of ours. We've had production downtime issues in the server caused by filehandle exhaustion. Turns out the client was creating a new HTTP connection for every request rather than reusing connections, and it did that because Go expects you to read the response body in its entirety even if you don't need it, otherwise connections aren't reused. And in many of the cases we thought that we were reading the body in its entirety, for example in locations where the JSON decoder was reading and decoding the response, but sometimes it simply did not really read it in full, despite definitely parsing the entire JSON structure returned from the server. A "bad" net/http client can easily bring down a net/http server. 2. We've had several instances of severe memory leaks, with the Go garbage collector not releasing or reusing memory ever. These were sometimes very difficult to track down with the available Go profiling tools (pprof for example), and even more difficult to understand. And in some of these cases we're still not even sure we understand despite fixing the issues, mostly because our code is not different than examples in the Go documentation itself. For example, we had functions that read a stream of bytes into a byte slice, then cast that byte slice into a string and return it. We would intuitively think that the memory allocated for that byte slice would be released, but apparently the casting performed constitutes an active reference of the data (rather than a copy of it), so the data is not marked for garbage collection. But the most obscure part is that it was never released, even after the cast data had no more references to it. Memory management in Go is very hard for us to reason, despite the language claiming that developers needn't worry about this subject as it is handled for them. This is just the top my head, I can bring more.
  - dpflan 9y ago

by idop 9y ago

JepZ 9y ago

Well, somehow this sounds to me like you are doing it wrong. Yes, you probably heard that before, but when you say things like 'proper project structuring' I think that you probably try to do something in a way that it is not meant to be used. But at the same time you probably have good reason to try that, as that was the way you did it in the past (with other languages). So while Go allows you to quickly learn to write code, it is a much harder challenge to learn how to structure you code in simple small packages. In the end that brings a lot of benefits (testing is easier), but if you try to create a project with very few packages you will go through lot of pain due to the lack of structure. Its very similar with interfaces. Programmers coming from other languages mostly ignore them in the beginning and it takes a while until they understand that exporting types from a package is a failure and that interfaces would have been a much better choice. In my opinion, the key to successful Go development is building many small, well tested library packages while using interfaces a lot.

idop 9y ago
Appreciate the comment. I was largely referring to very large projects. When it comes to smaller projects, but really any Go project, we've moved to the structural recommendations in the Go documentation a long time ago, which did improve things a bit, but really there are almost no good examples out there for really large projects. Your point about interfaces is mostly correct though, and we're progressively learning to utilize them better.

dpflan 9y ago

"We've spent so much time fixing obscure bugs and behaviors that betray everything we've learned in the languages we used previously in our careers that it was really not worth it." That sounds very frustrating; I'm sorry your day-to-day became consumed by such things. Would you mind providing an example of such an "obscure bug and behavior"?

idop 9y ago
I wouldn't call it my day-to-day, but sure, here are some examples: 1. We have a client component that makes HTTP requests to a server component of ours. We've had production downtime issues in the server caused by filehandle exhaustion. Turns out the client was creating a new HTTP connection for every request rather than reusing connections, and it did that because Go expects you to read the response body in its entirety even if you don't need it, otherwise connections aren't reused. And in many of the cases we thought that we were reading the body in its entirety, for example in locations where the JSON decoder was reading and decoding the response, but sometimes it simply did not really read it in full, despite definitely parsing the entire JSON structure returned from the server. A "bad" net/http client can easily bring down a net/http server. 2. We've had several instances of severe memory leaks, with the Go garbage collector not releasing or reusing memory ever. These were sometimes very difficult to track down with the available Go profiling tools (pprof for example), and even more difficult to understand. And in some of these cases we're still not even sure we understand despite fixing the issues, mostly because our code is not different than examples in the Go documentation itself. For example, we had functions that read a stream of bytes into a byte slice, then cast that byte slice into a string and return it. We would intuitively think that the memory allocated for that byte slice would be released, but apparently the casting performed constitutes an active reference of the data (rather than a copy of it), so the data is not marked for garbage collection. But the most obscure part is that it was never released, even after the cast data had no more references to it. Memory management in Go is very hard for us to reason, despite the language claiming that developers needn't worry about this subject as it is handled for them. This is just the top my head, I can bring more.
- dpflan 9y ago