8 ms·

> Every few years someone gets me to try Go out again and I discover, yet again, that it's still struggling with problems that were solved before it existed. It

> Every few years someone gets me to try Go out again and I discover, yet again, that it's still struggling with problems that were solved before it existed. It's a shame that this language has stolen so much mind share from more deserving languages. Go steals the mindshare because it focuses on the important problems that other languages neglect in part or in full: performance, tooling, ecosystem, simplicity, readability, learning curve, etc. Much important software has been built in fully dynamic languages (never mind a 99% type-safe language like Go), but it’s a lot harder to build in a language that lacks important libraries or is prohibitively slow or for whom it is hard to find/train developers, or whose tooling is poor, or which is difficult to read/maintain, or etc. So yes, Go is now looking at generics because it’s tackled the more important problems. Not because it was the most important problem and the developers were just too stupid to understand.

ctopher7 5y ago
- dgb23 5y ago
  I‘m sure there are better reasons for people liking Go other than what you described. This reads like a general dismissal.
  - Guthur 5y ago
    Nope, as a language Go adds nothing and sometimes feels like it gives even less. Where Go has been a success is tooling. The tooling is pretty decent and helps a lot. But that could be added to pretty much any language ecosystem
    - masklinn 5y ago
      > But that could be added to pretty much any language ecosystem Though it annoyingly is not. The profiling with integrated stack, line, and memory / alloc profiler seems especially nice. Though it’s made progress (especially with the rise of flamegraph-type visualisation) the ecosystems I navigate seem to remain a hodge-podge of disparate tools.
    - Cthulhu_ 5y ago
      Go apologist here. Go doesn't work because it adds something to existing languages, but because it keeps things away. In 30 years time, Go codebases built today will still be around, while Java, Javascript, Scala or Ruby codebases will have been rebuilt multiple times over or removed entirely, because they drowned in their own complexity and their developers' own cleverness. That said, for me it's not so much Go itself, but the mindset that comes with it of writing dumb and verbose but obvious code. I've reduced 15-line for loops into clever functional oneliners, but maybe all I needed was a `range` instead of a `for i = 0` style loop all along, because I need a lot more time and mental energy to understand the functional oneliner than a `for x in range` loop.
      - kaba0 5y ago
        That’s a bit bold coming from a relatively young language, given that Java has codebases close to 25 years old. Also, repeating the same code many times due to lack of expressiveness is not the epitome of long-lived software. Essential complexity is non-reducable, the only way we can deal with it is through abstractions.
        throwaway894345 5y ago
        Some of us were around when Java was young and can compare a 5yo Go codebase with a 5yo Java codebase :) > Also, repeating the same code many times due to lack of expressiveness is not the epitome of long-lived software. Essential complexity is non-reducable, the only way we can deal with it is through abstractions Repetition is not a big deal in a local context (e.g., error handling or for loops), and Go is rarely repetitive in larger contexts. Gratuitous abstraction is a much greater danger than extra keystrokes IMHO.
  - ctopher7 5y ago
    I don't hate go for the language itself. I understand the point of using go, especially if you have a company with hundreds or thousands of software engineer. It is really good for building microservices, because to me the learning curve is not steep hence everybody who just learn it, could already make contributions to the codebase. what I don't understand are the fans who are really trying to overglorify go as "language of the future" that could be a C replacement.
- throwaway894345 5y ago
  I gave a reasoned argument and you responded with ad hominem. I don’t think it’s the “Go fans” who are toxic. We merely disagree, and that’s okay.
kaba0 5y ago
There is absolutely nothing mentioned in your comment that Java or C# didn’t already do better 10 years ago, let alone now. The only somewhat redeeming quality of go is virtual threads, but that is not even the reason like 90% of its user base uses it for.
- mahesh-hegde 5y ago
  AOT compiler; single binary; standard library and package ecosystem well suited for a subset of programming tasks, while being much lightweight and less verbose than Java / C#. Would not pick Go to make a website. But it's probably best tool to make a simple HTTP server or command line tool that deals with files or network.
  - pjmlp 5y ago
    Java has AOT compilers since 2000, they just weren't free beer. .NET was released with AOT compiler, although it only did dynamic linking (NGEN). Mono always supported AOT compilation, just like the C# dialects for Singularity, Midori, and .NET Native for Windows 10 UWP.
    - mahesh-hegde 5y ago
      > Java has AOT compilers since 2000, they just weren't free beer. "just" Tell me how me, a student in India with a cheap plastic laptop running Linux, could get straightforward access to some AOT compiler produced by some commercial company in north pole or somewhere. Open source compilers got popular for a reason. Now we have graalvm, but getting something running with graalvm is not always straightforward. Even with a full framework like quarkus I have had to use escape hatches @RegisterForReflection. Usability matters. And Go was built from day 1 with AOT in mind. And lastly Go has better built-in / first-party supported APIs for file I/O, networking etc.. Subjective thing, I guess. When I want to make a database backed website, I reach for spring boot or vert.x; But Go wins for CLI stuff. I don't know much about C# because I primarily work on Linux.
      - 5y ago
pjmlp 5y ago
I bet that if the Docker and Kubernetes ecosystem was born today, Rust would be used instead. We are already seeing the transition happening, e.g. Deis Labs: https://deislabs.io/posts/still-rusting-one-year-later/ https://deislabs.io/posts/still-rusting-one-year-later/ > Given the team’s background in many Go projects, we often hear something like this: “Well, what about Go? Do you regret moving to Rust? What do you miss from Go?” Addressing this in the context of our discussion of Rust felt like a smart decision.
- throwaway894345 5y ago
  Of course there’s no way to know for sure, but I would be more inclined to use Rust for projects where the domain is well-understood; however, Kubernetes was (and to an extent, still is) experimental and rapidly evolving. It would be painful to have to do all of that iteration in the presence of a borrow-checker. And yeah, I understand the purported benefits of having a robust type checker protecting you in a refactor. That said, Kubernetes isn’t a monolith so it doesn’t need to be all-or-nothing, and one component that would likely be well-suited to Rust is etcd.
  - pjmlp 5y ago
    Naturally that was an what-if, my comment was based on what we see happening with CNCF projects evolution.
- ilovecaching 5y ago
  You clearly have no idea what Rust is for, or who the target audience is. Application developers do not need a non-GCed language, and anyone who argues for the added complexity and noise (because Rust makes it so easy you'll say) is actually just looking for something cool to learn and push at the office. I get it, you don't want to write Go, it's too simple for the 1%er programmers. I've been a kernel developer for several decades now and it's time for something like Rust to come along, and despite the fact that I wish it had a stable ABI and that it doesn't solve the problem of C's simplistic ABI or the code that will continue to be written in C, I hope it succeeds in making things at least a little bit better for driver authors. But that's what Rust is for, it's a systems programming language.
kerkeslager 5y ago
Sorry, but I just don't buy it. Performance just isn't the problem people say it is. I've done a lot of Python development over the last 12 years, and in that time, I've run into lots of performance problems, but none that would have been easier to solve in Go and none that were particularly hard to solve in Python. In most cases you're just offloading onto libraries (i.e. Pandas or MPT). I've dipped into C a handful of times, but that was more of a "could" than a "had to". I'll give you a point on tooling--Go's tooling is pretty good. There are a bunch of languages with good tooling these days, but compiling easily to a single binary blob is still a pretty winning feature. But usually that sort of stuff is automated out in the first week of development anyway--is that really enough to justify choosing a language? Ecosystem? I'm not impressed. There are like 10 languages with healthier, more active ecosystems. "Simplicity" is generally a pretty bad argument, because what's simple is so subjective. My observation is that simple problems are simple in Go, which makes it a great language for demos, but if you actually try to solve complex problems with it, the language completely lacks features with sufficient abstraction to make complex problems simpler. Where other languages you end up spending 20% of time solving 80% of problems, and 80% of time solving 20% of problems, with Go it's more like you spend slightly less, 15% of time solving 80% of problems because of the simplicity, and then you spend 300% of time solving the other 20% because the actual hard stuff is much harder in Go. Readability: this sort of goes back to the simplicity thing. Sure, go has less boilerplate than some languages, but that only matters for the simple stuff. If you get into, say, a complex networking algorithm, Go code is going to get lost in all the nonsense of making sure threads share memory properly. I won't argue that, for example, Erlang's syntax isn't a bit ugly, but I can explain my networking code in Erlang to someone who doesn't know Erlang fairly easily because of message passing. Learning curve: beating a dead horse here, but just because it's easier to learn to solve simple problems in go, doesn't mean it's easier to learn how to solve professional-level problems with go, let alone industry-leading problems which actually constitute the competitive advantage of a business. Go steals the mindshare because people saw Google were using it and mistakenly thought that if Google were using it, it must be good, even though almost nobody has the same problems as Google. > So yes, Go is now looking at generics because it’s tackled the more important problems. Not because it was the most important problem and the developers were just too stupid to understand. Just to be clear, I didn't call anyone stupid: on the contrary, I think the developers fell into a trap that is particularly dangerous to smart people: we think that because we're smart, we already know the best way to do things. That's not stupid, it's ignorant. I don't mean that to be insulting although I'm sure you'll take it that way, but I'll say that ignorance is fixable. It's telling that in your post you just spit out a bunch of buzzwords without any comparison to any other languages, which is pretty much how Go got here: Go developers generally only think Go is great because they've never used other decent languages. If you're coming from C, then you can be forgiven for thinking Go is the bees knees, but that's comparing a 50 year old programming language with a 10 year old one--C has lots of problems, but there are historical reasons for those problems. Go has problems that Gophers don't even know are problems, because they've never spent enough time working in a language that actually solves those problems. And there's no excuse for it, because Go has no historical reason for not solving those problems: a lot of them were solved by other languages before Go existed, and the developers were either ignorant of the existing solutions or thought they knew better (and definitely didn't, in my experience).

ctopher7 5y ago

dgb23 5y ago
I‘m sure there are better reasons for people liking Go other than what you described. This reads like a general dismissal.
- Guthur 5y ago
  Nope, as a language Go adds nothing and sometimes feels like it gives even less. Where Go has been a success is tooling. The tooling is pretty decent and helps a lot. But that could be added to pretty much any language ecosystem
  - masklinn 5y ago
    > But that could be added to pretty much any language ecosystem Though it annoyingly is not. The profiling with integrated stack, line, and memory / alloc profiler seems especially nice. Though it’s made progress (especially with the rise of flamegraph-type visualisation) the ecosystems I navigate seem to remain a hodge-podge of disparate tools.
  - Cthulhu_ 5y ago
    Go apologist here. Go doesn't work because it adds something to existing languages, but because it keeps things away. In 30 years time, Go codebases built today will still be around, while Java, Javascript, Scala or Ruby codebases will have been rebuilt multiple times over or removed entirely, because they drowned in their own complexity and their developers' own cleverness. That said, for me it's not so much Go itself, but the mindset that comes with it of writing dumb and verbose but obvious code. I've reduced 15-line for loops into clever functional oneliners, but maybe all I needed was a `range` instead of a `for i = 0` style loop all along, because I need a lot more time and mental energy to understand the functional oneliner than a `for x in range` loop.
    - kaba0 5y ago
      That’s a bit bold coming from a relatively young language, given that Java has codebases close to 25 years old. Also, repeating the same code many times due to lack of expressiveness is not the epitome of long-lived software. Essential complexity is non-reducable, the only way we can deal with it is through abstractions.
      - throwaway894345 5y ago
        Some of us were around when Java was young and can compare a 5yo Go codebase with a 5yo Java codebase :) > Also, repeating the same code many times due to lack of expressiveness is not the epitome of long-lived software. Essential complexity is non-reducable, the only way we can deal with it is through abstractions Repetition is not a big deal in a local context (e.g., error handling or for loops), and Go is rarely repetitive in larger contexts. Gratuitous abstraction is a much greater danger than extra keystrokes IMHO.
- ctopher7 5y ago
  I don't hate go for the language itself. I understand the point of using go, especially if you have a company with hundreds or thousands of software engineer. It is really good for building microservices, because to me the learning curve is not steep hence everybody who just learn it, could already make contributions to the codebase. what I don't understand are the fans who are really trying to overglorify go as "language of the future" that could be a C replacement.
throwaway894345 5y ago
I gave a reasoned argument and you responded with ad hominem. I don’t think it’s the “Go fans” who are toxic. We merely disagree, and that’s okay.

kaba0 5y ago

There is absolutely nothing mentioned in your comment that Java or C# didn’t already do better 10 years ago, let alone now. The only somewhat redeeming quality of go is virtual threads, but that is not even the reason like 90% of its user base uses it for.

mahesh-hegde 5y ago
AOT compiler; single binary; standard library and package ecosystem well suited for a subset of programming tasks, while being much lightweight and less verbose than Java / C#. Would not pick Go to make a website. But it's probably best tool to make a simple HTTP server or command line tool that deals with files or network.
- pjmlp 5y ago
  Java has AOT compilers since 2000, they just weren't free beer. .NET was released with AOT compiler, although it only did dynamic linking (NGEN). Mono always supported AOT compilation, just like the C# dialects for Singularity, Midori, and .NET Native for Windows 10 UWP.
  - mahesh-hegde 5y ago
    > Java has AOT compilers since 2000, they just weren't free beer. "just" Tell me how me, a student in India with a cheap plastic laptop running Linux, could get straightforward access to some AOT compiler produced by some commercial company in north pole or somewhere. Open source compilers got popular for a reason. Now we have graalvm, but getting something running with graalvm is not always straightforward. Even with a full framework like quarkus I have had to use escape hatches @RegisterForReflection. Usability matters. And Go was built from day 1 with AOT in mind. And lastly Go has better built-in / first-party supported APIs for file I/O, networking etc.. Subjective thing, I guess. When I want to make a database backed website, I reach for spring boot or vert.x; But Go wins for CLI stuff. I don't know much about C# because I primarily work on Linux.
    - 5y ago

pjmlp 5y ago

I bet that if the Docker and Kubernetes ecosystem was born today, Rust would be used instead. We are already seeing the transition happening, e.g. Deis Labs: https://deislabs.io/posts/still-rusting-one-year-later/ https://deislabs.io/posts/still-rusting-one-year-later/ > Given the team’s background in many Go projects, we often hear something like this: “Well, what about Go? Do you regret moving to Rust? What do you miss from Go?” Addressing this in the context of our discussion of Rust felt like a smart decision.

throwaway894345 5y ago
Of course there’s no way to know for sure, but I would be more inclined to use Rust for projects where the domain is well-understood; however, Kubernetes was (and to an extent, still is) experimental and rapidly evolving. It would be painful to have to do all of that iteration in the presence of a borrow-checker. And yeah, I understand the purported benefits of having a robust type checker protecting you in a refactor. That said, Kubernetes isn’t a monolith so it doesn’t need to be all-or-nothing, and one component that would likely be well-suited to Rust is etcd.
- pjmlp 5y ago
  Naturally that was an what-if, my comment was based on what we see happening with CNCF projects evolution.
ilovecaching 5y ago
You clearly have no idea what Rust is for, or who the target audience is. Application developers do not need a non-GCed language, and anyone who argues for the added complexity and noise (because Rust makes it so easy you'll say) is actually just looking for something cool to learn and push at the office. I get it, you don't want to write Go, it's too simple for the 1%er programmers. I've been a kernel developer for several decades now and it's time for something like Rust to come along, and despite the fact that I wish it had a stable ABI and that it doesn't solve the problem of C's simplistic ABI or the code that will continue to be written in C, I hope it succeeds in making things at least a little bit better for driver authors. But that's what Rust is for, it's a systems programming language.

kerkeslager 5y ago

Sorry, but I just don't buy it. Performance just isn't the problem people say it is. I've done a lot of Python development over the last 12 years, and in that time, I've run into lots of performance problems, but none that would have been easier to solve in Go and none that were particularly hard to solve in Python. In most cases you're just offloading onto libraries (i.e. Pandas or MPT). I've dipped into C a handful of times, but that was more of a "could" than a "had to". I'll give you a point on tooling--Go's tooling is pretty good. There are a bunch of languages with good tooling these days, but compiling easily to a single binary blob is still a pretty winning feature. But usually that sort of stuff is automated out in the first week of development anyway--is that really enough to justify choosing a language? Ecosystem? I'm not impressed. There are like 10 languages with healthier, more active ecosystems. "Simplicity" is generally a pretty bad argument, because what's simple is so subjective. My observation is that simple problems are simple in Go, which makes it a great language for demos, but if you actually try to solve complex problems with it, the language completely lacks features with sufficient abstraction to make complex problems simpler. Where other languages you end up spending 20% of time solving 80% of problems, and 80% of time solving 20% of problems, with Go it's more like you spend slightly less, 15% of time solving 80% of problems because of the simplicity, and then you spend 300% of time solving the other 20% because the actual hard stuff is much harder in Go. Readability: this sort of goes back to the simplicity thing. Sure, go has less boilerplate than some languages, but that only matters for the simple stuff. If you get into, say, a complex networking algorithm, Go code is going to get lost in all the nonsense of making sure threads share memory properly. I won't argue that, for example, Erlang's syntax isn't a bit ugly, but I can explain my networking code in Erlang to someone who doesn't know Erlang fairly easily because of message passing. Learning curve: beating a dead horse here, but just because it's easier to learn to solve simple problems in go, doesn't mean it's easier to learn how to solve professional-level problems with go, let alone industry-leading problems which actually constitute the competitive advantage of a business. Go steals the mindshare because people saw Google were using it and mistakenly thought that if Google were using it, it must be good, even though almost nobody has the same problems as Google. > So yes, Go is now looking at generics because it’s tackled the more important problems. Not because it was the most important problem and the developers were just too stupid to understand. Just to be clear, I didn't call anyone stupid: on the contrary, I think the developers fell into a trap that is particularly dangerous to smart people: we think that because we're smart, we already know the best way to do things. That's not stupid, it's ignorant. I don't mean that to be insulting although I'm sure you'll take it that way, but I'll say that ignorance is fixable. It's telling that in your post you just spit out a bunch of buzzwords without any comparison to any other languages, which is pretty much how Go got here: Go developers generally only think Go is great because they've never used other decent languages. If you're coming from C, then you can be forgiven for thinking Go is the bees knees, but that's comparing a 50 year old programming language with a 10 year old one--C has lots of problems, but there are historical reasons for those problems. Go has problems that Gophers don't even know are problems, because they've never spent enough time working in a language that actually solves those problems. And there's no excuse for it, because Go has no historical reason for not solving those problems: a lot of them were solved by other languages before Go existed, and the developers were either ignorant of the existing solutions or thought they knew better (and definitely didn't, in my experience).