7 ms·

Every time I read a critique of Go, I feel the same way: I'm still going to continue to use it anyways. The reason why I am going to continue to use it anyways

• pif 2y ago
  > I choose a language that I feel works well for me Which is the wisest choice for everyone. Golang is only a problem when a manager imposes it on you.
  • vasco 2y ago
    "Manager imposes it on you" just means you work in a team rather than alone. You can pick whatever you like for side projects, of course you're going to use whatever your team uses otherwise.
    • pif 2y ago
      [flagged]
      • Cthulhu_ 2y ago
        > which casts a doubt about developers actually liking it I'm self-aware enough that I'm not clever enough for the likes of C++ or Rust; I wish more people were as aware of their own limitations. Managers have a long-term responsibility about a codebase too. "Clever" developers have no place in professional software development, imo.
    • pif 2y ago
      [flagged]
      • pif 2y ago
        > People tend to forget that Golang was created on purpose for poor programmers. Ergo: if you actually like it, you must not be that great a developer.
        • eru 2y ago
          Probably, yes. Though that's an empiric finding, and doesn't follow logically from the premises.
      • bckr 2y ago
        I don’t think this implies it can’t be the right tool for the job, even when everyone on the team is a good programmer. I don’t think it implies that you can’t write good programs in it.
      • stavros 2y ago
        If it was created on purpose for poor programmers, it seems to have been created to enable poor programmers to write the poor code they wanted to write, instead of making it impossible for poor programmers to write any code. I guess that's the difference, if you want code, no matter the quality, you have one choice, if you want code that's correct, you have another.
  • imjonse 2y ago
    More generally, when it's not well suited for the problem to be solved. Eager coworkers anticipating Google level traffic may want to write the system in Go and multiple microservices when a simple FastAPI server would do.
  • guappa 2y ago
    Plenty of software engineers don't know any better themselves
  • AnimalMuppet 2y ago
    Only a problem when a manager imposes it on you for a program where it doesn't fit well.
• tonfreed 2y ago
  Exactly. Every programming language is a tool in your toolbox, and you should choose the appropriate one for the job at hand. For me, that's Go around 95% of the time. I have no need to worry about a 24 byte overhead for a slice allocation, if I did have to worry about that, I'd probably use C or Rust.
  • Cthulhu_ 2y ago
    And since Go is so readable, theoretically getting the core functionality out and rewriting it in a more specialized language would be fairly straightforward. And while it's an investment in time and effort to rewrite a chunk, at least you know what you're writing already. But that's a point made in the article, that Go is also good for prototyping. But there's a few languages good for that, e.g. Ruby which powered a lot of the HN startups in their early days until parts needed to be rewritten for performance / scalability. But writing a new, unproven product in a high performance, high difficulty language from the get-go is cargo cult; you hope you will need the performance and correctness offered by the language. Meanwhile, halfbaked hack jobs like Facebook and Twitter exploded in popularity and revenue, and while their performance issues gave their developers headaches, at least they knew what problems they had and had to solve instead of guessing and hoping.
    • zozbot234 2y ago
      > And since Go is so readable, theoretically getting the core functionality out and rewriting it in a more specialized language would be fairly straightforward. You'll have to rewrite your whole program (or at least factor out the "core" part you care about into a separate binary and talk to it via IPC or network) because Golang has terrible FFI as pointed out by OP.
• monksy 2y ago
  > Go does not succeed in, because they are probably going to be complaining about it for the rest of their lives. A lot of people really don't like Go because they have experienced other language features. Go has taken an arrogant stance at trying to make the decision about what features you might need and has given you a very small amount of things to work with.
  • pmezard 2y ago
    And a lot of people using Go have experienced other language features as well and either decided against them or that the whole tradeoff was not worth it. I will keep very fast compilation times and decade long backward compatibility over a lot of your features. Because those are features too.
    • Cthulhu_ 2y ago
      I mean I miss some language features for sure, but the problem with adding language features is that it adds long-term inconsistency. Take a Go codebase from 10 years ago and it should look mostly the same as it would if it was rewritten in modern Go. Do the same with Java and across generations you'd go from straight for loops, to generic iterators and their for-each syntactic sugar, to for-comprehensions, streams and their functional programming style, to whatever Java is up to in 2024, I stopped paying attention years ago.
  • Cthulhu_ 2y ago
    Counterpoint, other languages - notably Javascript, Scala, PHP, maybe Java - have taken the stance that they adopt other languages' features, not because the language needs it, but because developers were clamoring for it. Which led to added complexity, because they kept adding more and more ways to solve a problem or structure an application, which led to every codebase being so different from the next that the amount of transferable skills and knowledge became less and less. Scala is the worst offender for that IMO. One frequent praise one hears of Go is that a developer can open any codebase and immediately understand what's happening. Go is readable and stable, which are critical for code for the long term.
• wokwokwok 2y ago
  > I guess I feel bad for people who are particularly sensitive to the areas that Go does not succeed in, because they are probably going to be complaining about it for the rest of their lives. Well, that’s a stellar endorsement of the article, because that’s literally the point they’re making. You’ll use go. …and then regret it. …but by then it’ll be too late, and you’re stuck with it. I think the author makes a compelling argument, which is very difficult to counter, that it is a bad choice and you will regret having it in production in many of the explicitly listed cases, and in many professional situations where companies that are not technically competent use unsuitable tech. Companies should stick to boring tools. …but, for personal projects? Sure, go for it.
  • dgellow 2y ago
    Go is as boring of a tool as it gets. Which is why I will happily use it
  • jchw 2y ago
    There's no tool boring enough to prevent any chance of regret. At the end of the day, it's really, really difficult to anticipate where your pain points will actually wind up in the real world. In practice, I've had lots of really good production success with Go and not too much heartache about the choice. Since adopting it personally (in around 2014) almost every company I've gone to work since has used Go in some capacity and that capacity was usually growing because it was working for them. Will you regret choosing Go? Maybe. Or, maybe not.
    • coldtea 2y ago
      >There's no tool boring enough to prevent any chance of regret. I'm not so sure. I know C programmers that swear by it, warts and all, with absolutely zero regrets for using it e.g. in the embedded space.
      • jchw 2y ago
        If anyone tells you C is "boring", that's just plain and simple bullshit. C gives you undefined behavior, buggy compilers (yes even for simple C code, MSVC is especially bad at plain C but there are other offenders) and the world's worst standard library for manipulating strings. Using C in embedded development is probably OK, even if you have to suffer with whatever crappy vendor compiler you are stuck with, but that's only considering the pretty severe limitations that very resource-constrained embedded development typically has (e.g. no dynamic allocation.) C is only as boring as you force it to be, and you really have to force it to be. That said... the thing about the embedded space is that most of it is C, always will be, and may continue to be for the foreseeable future. It's really hard to really know what you have to regret if all you've ever known is C.
• surgical_fire 2y ago
  I sort of like Go. The explicit error handling is a little obnoxious sometimes, but it's just a way to get things done. Otherwise I see its simplicity as a strength. It is very ergonomic, easy to pick up, and generally performs pretty well. I perhaps wouldn't pick it for every scenario, but there are plenty of scenarios where it would be a good tool. Then again, I sort of like Java and Python too, two languages I am proficient enough at. All of those are good tools for what they intend to be. I don't understand why people get so passionate about programming languages. They are tools. You may like soke more than others, but that doesn't invalidate the ones you don't like.
  • coldtea 2y ago
    >I don't understand why people get so passionate about programming languages. They are tools. Because when you're a professional programmer, tools are a huge part of what you do and how you do it, same like a race driver would need to be passionate about cars. It's just that for an e.g. carpenter, tools are more or less standadized and simple enough to evaluate. If saws and hammers and routers had as much variety as programming language tooling, and were as multi-faceted to evalute, carpenters would be absolutely obsessed with using the good ones - even more so than they already are.
    • lexicality 2y ago
      I think if you tried to tell a professional carpenter that you'd replaced the contents of their toolbox with the equivalent pieces from a discount hardware store you'd be looking for your teeth on the floor. I certainly wouldn't give up my electronic hardware repair tools without a struggle, it took me years to find ones that I like!
    • surgical_fire 2y ago
      > Because when you're a professional programmer, tools are a huge part of what you do and how you do it, same like a race driver would need to be passionate about cars. I am a professional programmer. Have been one for more than two decades. And perhaps for professionalism, I think there is no space for passion when it comes to choosing the tools of the trade. Passion would make me pick unsuitable tools because well, I would be passionate. Passionate people don't tend to make rational decisions. I would expect a professional carpenter to be the same. They may have preferences due to familiarity, positive experiences, etc and so forth. But passion?
• coldtea 2y ago
  >I like the explicit error handling everywhere Then you're doing yourself a disfavor by using Go. In other languages it would be even more explicit, mandatory, and automatically checked whether it's handled!
• lenkite 2y ago
  I like Go, but after writing/reading so much Go code, I get nightmares from `if err != nil` demons punching me in the face. There were so many nice suggestions made to fix this, but there are some extremely conservative and extremely loud-spoken community members who killed all the proposals with vitriolic feedback. Now, the Go team has given up the battle for improving error handling since they are psychologically afraid of these folks. Every Go developer survey has results where the community overwhelmingly votes to improve error handling, but a few extremists have derailed all progress.