7 ms·

I didn't care in the last post and I don't care about this one either. I care about my productivity, I care about my team's productivity, and I care about getti

I didn't care in the last post and I don't care about this one either. I care about my productivity, I care about my team's productivity, and I care about getting stuff shipped. Those are the things I care about, and go works great for that. If you care about those things too, and you're using go, you shouldn't stop using go. My whole career people have been telling me to stop using languages or tools I've been productive with. I've built successful companies where everything was written in python, the whole time people on HN telling me how I was using a lowly language because of things like whitespace significance or strings that were not unicode by default. If you care about other stuff, fine. If you don't think go works for you, don't use go. Just stop telling people who are using go (and other productive languages) to stop using them because of obscure language design issues or obscure API choices that people rarely encounter day to day. That isn't what matters to most people, and it's actually bad advice. The problem is that there are a ton of less experienced people reading stuff on HN (just as I once was) who will take this to heart but have nothing actionable to gain from it, except to think they're a bad developer using a bad language. They aren't, and they're not.

tomlin 4y ago
I think your POV works in your very specific world view. As a head of an agency, hiring a developer that knows mainline languages serves a lot of good in hiring, keeping teams happy, and low turnover. We've all seen the agencies that hop on a new, hip language - only to go up in flames 6 months later because they couldn't find talent for their narrow viewpoint. This isn't an argument against Go, moreso that your perspective is objectively elitist.
greybox 4y ago
I don't think that the author is telling anyone to stop using Go. They are suggesting that there should be a better alternative, and there are lessons to be learnt. I don't think we should be so cynical as to just lie down and accept that some things are just too hard to get right
- oxnrtr 4y ago
  Especially when other languages got them right.
nightski 4y ago
I mean, this is Hacker News. Not corporate programmer news. Building a successful company has very little to do with tech choices. But that doesn't mean we shouldn't discuss these things as tinkerers and hackers.
- bombcar 4y ago
  > Building a successful company has very little to do with tech choices. This is what Hacker News doesn't want to hear, and so needs to hear. Like obsessing over the school supply list at the beginning of the year and getting everything perfect; it's not the whole of success, nor is it even really a huge part. But it can be fun.
  - zanellato19 4y ago
    So many companies succeed _despite_ their tech choices and so many fail also despite their tech choices. In the end, even at mostly software companies, if you don't have a good sales model, a good sales team, a good marketing team, its likely you will out of business soon.
    - bombcar 4y ago
      Two step profit plan: 1. Get a sales team that could sell shit on a stick. 2. Get a programming team that can do a bit better than shit on a stick.
busterarm 4y ago
I use Go. I'm not a Rustacean. I've also used a whole bunch of things that are not Go. In reading this article, I'm finding myself agreeing with 100% of the author's criticisms. I've seen every specific problem mentioned be a thing that bogs companies I've worked for down and erode productivity. A lot of time the ops peoples' (aka: my) productivity specifically. I haven't worked at a single company where teams of developers using Golang have been able to get the basic networking stuff right. "Why are my TCP connections not closing? Why am I encountering port exhaustion?" Go's frustrating inability to inter-op matters quite a lot at the end of the day. GRPC and protobufs are f'in messy and full of footguns. Thing is, I've been around the block. I know that these problems don't have to be problems. We have a tremendously bad tendency in this field to join cargo cults. When looking for my next gig, if the company is big enough, I'm likely to start seeing Go as a negative, unless they've got that Tailscale kind of expertise.
- Thaxll 4y ago
  "Why are my TCP connections not closing? Why am I encountering port exhaustion?" This has nothing to do with Go. You're implying Go has a bug in its TCP implementation which I assume is false. Networking works just fine in Go and it's actually easy to use. https://pkg.go.dev/net https://pkg.go.dev/net Edit: I'm getting downvoted but please share with TCP issues in Go.
  - Diggsey 4y ago
    > You're implying Go has a bug in its TCP implementation which I assume is false. No, the parent is implying that Go's TCP implementation is easy to use incorrectly. Specifically in ways which cause the aforementioned issues.
    - Thaxll 4y ago
      I need examples, I used it for TCP/UDP and HTTP and beside the gotcha that clients have infinite timeout I don't see anything.
      - 4y ago
tasuki 4y ago
I believe that you are perfectly productive with Go, the article hasn't claimed otherwise. I used to be quite productive with PHP. That does not mean PHP is a good language. > The problem is that there are a ton of less experienced people reading stuff on HN (just as I once was) who will take this to heart but have nothing actionable to gain from it, except to think they're a bad developer using a bad language. They aren't, and they're not. You are replying to an article mentioning many of Go's problems, without rebuking any of the article's points. Perhaps these poor people are using a bad language? (Also perhaps some people reading this are "bad developers", whatever that means? Perhaps I am! What does that matter?)
seba_dos1 4y ago
The article's author has written and shipped tons of quality Go code that is still used in production by many people, myself included. Sometimes, a poor language is a good tool for specific task despite of being generally a poor language. Sometimes, knowing and liking a bad language makes you use it for tasks it's not suited for. Go is in the same category as JavaScript and PHP there, which have their valid uses, but also a lot of valid reasons to stay away from. You only learn how and when to choose them once you become experienced enough in several languages to notice the differences between them over long term usage and project maintenance.
kretaceous 4y ago
As a beginner learning Go for the past 3 weeks, thanks for the last paragraph. I was looking into a new language to learn outside of JS and Python. I wanted to learn a hot language. I did some digging between Rust and Go and found out that Go is more suitable for web backends, CLI apps, etc. while Rust was more of a contender to C/C++, as it was primarily was made to be used as a memory-safe, correct, strict language to write low level software. I don't generally involve myself in the latter so I chose Go. I definitely want to learn Rust someday but is it worth it if I don't get into that low level of things? What are Go's and Rust's target applications according to readers here?
- NIckGeek 4y ago
  Rust is a general purpose programming language. It can do low level systems programming but it's also highly capable of doing web backends, web frontends (wasm), game design, small utility scripts, etc. A big thing people learning Rust do my mistake is to try and use all of the low level features straight away. Rust has tools like Rc, RefCell, Arc, and RwLock that let you have a garbage collected language (well, reference counted) and not worry about any of the low level memory management details. See things like https://ggez.rs/ https://ggez.rs/ for games and https://www.arewewebyet.org/ https://www.arewewebyet.org/ for web stuff. Although honestly I think if you're looking for a "hot" backend web language I'd say Elixir is the more well designed one than Go.
  - kretaceous 4y ago
    With your and the sibling commenters comment, I've made up my mind: I'll definitely learn Rust one day and make stuff with it when I have proper time and I'm not learning anything else. Thanks for the insights!
- Karrot_Kream 4y ago
  Rust is indeed a general purpose programming language, but unlike the sibling poster I'm not going to sell it for low-level systems programming _and_ other things just because it can and has some (hit-or-miss depending on the domain) crates for them. Rust is a complex language and its APIs tend to reflect the underlying domain complexity nearly 1:1. It also does not have a GC. Rust interops with native code well. When you're writing code that needs to be very correct especially in complicated problem domains, Rust is a great language to reach for because it bubbles up that underlying complexity so well. If you really need the lack of GC pausing then Rust is also IMO much better than most other non-GC languages in common use (c.f. C, C++). If you need C interop, then Rust is great. If you're a fan of writing elegant abstractions, Rust is also a great tool as its macro processor and language constructs make it easy to write abstractions (compared to other imperative languages at least). But its use for other areas is, IMO, a bit fraught. Go is a lot more opinionated as a language. Its stdlib hides the complexity for certain interfaces. It has a simple-to-use concurrency model that the whole language opts into. It compiles quickly. It produces a no-nonsense static binary and has a great cross-compilation story. Go code is repetitive but simple to read. Go's tooling is stellar and because of how easy it is to write third-party tooling, people often build useful tools for themselves. I find it really easy to hack on or debug other Go projects if needed. Overall, Go is opinionated, and if the applications you're writing and the style you're writing them in fall into Go's opinions then you'll love it. If you don't like Go's style, you'll hate it. Go is my go-to (pun not intended lol) language for hobby coding because when coding as a hobby I'm often working on a constrained problem and don't need Rust's complexity. To offer a concrete example, the OP in his previous blog post wrote a diatribe about Go's filepath handling on Windows, but when I recently used Rust to write something that templated a few filenames, the whole thing took incredibly long. The complexities of Rust filepaths accurately reflect all the edge cases available for different platforms but was ridiculous overkill for my simple app that I was hacking on that was only ever going to run on a single Linux x64 platform. IMO to just "get things done" use Go. If you find yourself fighting Go's idioms, then Go isn't for you. If you really enjoy writing elegant abstractions, Go isn't for you. If you need to go deep into an API that Go simplifies and will spend most of your logic doing just that, then Go isn't for you. If you can't tolerate the GC pauses then Go isn't for you. Otherwise just use Go to get stuff done.
beltsazar 4y ago
> I didn't care in the last post and I don't care about this one either. I care about my productivity, I care about my team's productivity, and I care about getting stuff shipped. Those are the things I care about, and go works great for that. If your definition of "productivity" is the time spent in programming, I think you and the author are not in disagreement. The point that the author makes is that using a language with sophisticated type systems prevents some categories of bugs to happen in the first place. That means less time spent in debugging and fixing the code.

tomlin 4y ago

I think your POV works in your very specific world view. As a head of an agency, hiring a developer that knows mainline languages serves a lot of good in hiring, keeping teams happy, and low turnover. We've all seen the agencies that hop on a new, hip language - only to go up in flames 6 months later because they couldn't find talent for their narrow viewpoint. This isn't an argument against Go, moreso that your perspective is objectively elitist.

greybox 4y ago

I don't think that the author is telling anyone to stop using Go. They are suggesting that there should be a better alternative, and there are lessons to be learnt. I don't think we should be so cynical as to just lie down and accept that some things are just too hard to get right

oxnrtr 4y ago
Especially when other languages got them right.

nightski 4y ago

I mean, this is Hacker News. Not corporate programmer news. Building a successful company has very little to do with tech choices. But that doesn't mean we shouldn't discuss these things as tinkerers and hackers.

bombcar 4y ago
> Building a successful company has very little to do with tech choices. This is what Hacker News doesn't want to hear, and so needs to hear. Like obsessing over the school supply list at the beginning of the year and getting everything perfect; it's not the whole of success, nor is it even really a huge part. But it can be fun.
- zanellato19 4y ago
  So many companies succeed _despite_ their tech choices and so many fail also despite their tech choices. In the end, even at mostly software companies, if you don't have a good sales model, a good sales team, a good marketing team, its likely you will out of business soon.
  - bombcar 4y ago
    Two step profit plan: 1. Get a sales team that could sell shit on a stick. 2. Get a programming team that can do a bit better than shit on a stick.

busterarm 4y ago

I use Go. I'm not a Rustacean. I've also used a whole bunch of things that are not Go. In reading this article, I'm finding myself agreeing with 100% of the author's criticisms. I've seen every specific problem mentioned be a thing that bogs companies I've worked for down and erode productivity. A lot of time the ops peoples' (aka: my) productivity specifically. I haven't worked at a single company where teams of developers using Golang have been able to get the basic networking stuff right. "Why are my TCP connections not closing? Why am I encountering port exhaustion?" Go's frustrating inability to inter-op matters quite a lot at the end of the day. GRPC and protobufs are f'in messy and full of footguns. Thing is, I've been around the block. I know that these problems don't have to be problems. We have a tremendously bad tendency in this field to join cargo cults. When looking for my next gig, if the company is big enough, I'm likely to start seeing Go as a negative, unless they've got that Tailscale kind of expertise.

Thaxll 4y ago
"Why are my TCP connections not closing? Why am I encountering port exhaustion?" This has nothing to do with Go. You're implying Go has a bug in its TCP implementation which I assume is false. Networking works just fine in Go and it's actually easy to use. https://pkg.go.dev/net https://pkg.go.dev/net Edit: I'm getting downvoted but please share with TCP issues in Go.
- Diggsey 4y ago
  > You're implying Go has a bug in its TCP implementation which I assume is false. No, the parent is implying that Go's TCP implementation is easy to use incorrectly. Specifically in ways which cause the aforementioned issues.
  - Thaxll 4y ago
    I need examples, I used it for TCP/UDP and HTTP and beside the gotcha that clients have infinite timeout I don't see anything.
    - 4y ago

tasuki 4y ago

I believe that you are perfectly productive with Go, the article hasn't claimed otherwise. I used to be quite productive with PHP. That does not mean PHP is a good language. > The problem is that there are a ton of less experienced people reading stuff on HN (just as I once was) who will take this to heart but have nothing actionable to gain from it, except to think they're a bad developer using a bad language. They aren't, and they're not. You are replying to an article mentioning many of Go's problems, without rebuking any of the article's points. Perhaps these poor people are using a bad language? (Also perhaps some people reading this are "bad developers", whatever that means? Perhaps I am! What does that matter?)

seba_dos1 4y ago

The article's author has written and shipped tons of quality Go code that is still used in production by many people, myself included. Sometimes, a poor language is a good tool for specific task despite of being generally a poor language. Sometimes, knowing and liking a bad language makes you use it for tasks it's not suited for. Go is in the same category as JavaScript and PHP there, which have their valid uses, but also a lot of valid reasons to stay away from. You only learn how and when to choose them once you become experienced enough in several languages to notice the differences between them over long term usage and project maintenance.

kretaceous 4y ago

As a beginner learning Go for the past 3 weeks, thanks for the last paragraph. I was looking into a new language to learn outside of JS and Python. I wanted to learn a hot language. I did some digging between Rust and Go and found out that Go is more suitable for web backends, CLI apps, etc. while Rust was more of a contender to C/C++, as it was primarily was made to be used as a memory-safe, correct, strict language to write low level software. I don't generally involve myself in the latter so I chose Go. I definitely want to learn Rust someday but is it worth it if I don't get into that low level of things? What are Go's and Rust's target applications according to readers here?

NIckGeek 4y ago
Rust is a general purpose programming language. It can do low level systems programming but it's also highly capable of doing web backends, web frontends (wasm), game design, small utility scripts, etc. A big thing people learning Rust do my mistake is to try and use all of the low level features straight away. Rust has tools like Rc, RefCell, Arc, and RwLock that let you have a garbage collected language (well, reference counted) and not worry about any of the low level memory management details. See things like https://ggez.rs/ https://ggez.rs/ for games and https://www.arewewebyet.org/ https://www.arewewebyet.org/ for web stuff. Although honestly I think if you're looking for a "hot" backend web language I'd say Elixir is the more well designed one than Go.
- kretaceous 4y ago
  With your and the sibling commenters comment, I've made up my mind: I'll definitely learn Rust one day and make stuff with it when I have proper time and I'm not learning anything else. Thanks for the insights!
Karrot_Kream 4y ago
Rust is indeed a general purpose programming language, but unlike the sibling poster I'm not going to sell it for low-level systems programming _and_ other things just because it can and has some (hit-or-miss depending on the domain) crates for them. Rust is a complex language and its APIs tend to reflect the underlying domain complexity nearly 1:1. It also does not have a GC. Rust interops with native code well. When you're writing code that needs to be very correct especially in complicated problem domains, Rust is a great language to reach for because it bubbles up that underlying complexity so well. If you really need the lack of GC pausing then Rust is also IMO much better than most other non-GC languages in common use (c.f. C, C++). If you need C interop, then Rust is great. If you're a fan of writing elegant abstractions, Rust is also a great tool as its macro processor and language constructs make it easy to write abstractions (compared to other imperative languages at least). But its use for other areas is, IMO, a bit fraught. Go is a lot more opinionated as a language. Its stdlib hides the complexity for certain interfaces. It has a simple-to-use concurrency model that the whole language opts into. It compiles quickly. It produces a no-nonsense static binary and has a great cross-compilation story. Go code is repetitive but simple to read. Go's tooling is stellar and because of how easy it is to write third-party tooling, people often build useful tools for themselves. I find it really easy to hack on or debug other Go projects if needed. Overall, Go is opinionated, and if the applications you're writing and the style you're writing them in fall into Go's opinions then you'll love it. If you don't like Go's style, you'll hate it. Go is my go-to (pun not intended lol) language for hobby coding because when coding as a hobby I'm often working on a constrained problem and don't need Rust's complexity. To offer a concrete example, the OP in his previous blog post wrote a diatribe about Go's filepath handling on Windows, but when I recently used Rust to write something that templated a few filenames, the whole thing took incredibly long. The complexities of Rust filepaths accurately reflect all the edge cases available for different platforms but was ridiculous overkill for my simple app that I was hacking on that was only ever going to run on a single Linux x64 platform. IMO to just "get things done" use Go. If you find yourself fighting Go's idioms, then Go isn't for you. If you really enjoy writing elegant abstractions, Go isn't for you. If you need to go deep into an API that Go simplifies and will spend most of your logic doing just that, then Go isn't for you. If you can't tolerate the GC pauses then Go isn't for you. Otherwise just use Go to get stuff done.

beltsazar 4y ago

> I didn't care in the last post and I don't care about this one either. I care about my productivity, I care about my team's productivity, and I care about getting stuff shipped. Those are the things I care about, and go works great for that. If your definition of "productivity" is the time spent in programming, I think you and the author are not in disagreement. The point that the author makes is that using a language with sophisticated type systems prevents some categories of bugs to happen in the first place. That means less time spent in debugging and fixing the code.