6 ms·

Go code often reinvents/reimplements a lot of things from scratch, reintroducing problems that have been addressed long ago in other systems. It's like this ne

by kerng 7y ago

Go code often reinvents/reimplements a lot of things from scratch, reintroducing problems that have been addressed long ago in other systems. It's like this new trend, let's rewrite everything in Go to be cool. Financially makes little to no sense.

inopinatus 7y ago
Let’s not just target Go with that sentiment, it applies almost universally, just in varying degree. Counterpoint: how is anyone supposed to learn, if not from their mistakes? We might worry about the blast radius, but there’s no compression algorithm for experience.
- rimliu 7y ago
  Another option is to learn from the mistakes of others.
  - gfxgirl 7y ago
    The problem is you don't even know where to learn about the mistakes of others until you make the mistake yourself and in making the mistake you get some clue was to what to search for that then uncovers the mistakes of others.
    - kerkeslager 7y ago
      I've found that when I ask others what mistakes I should avoid, they tend to answer the question. Another way to discover any mistakes is to ask people why they didn't do certain things which you think are good ideas. Often that reveals that they did do that, and it turned out poorly.
  - bregma 7y ago
    People rarely post their mistakes to stack overflow.
    - pjmlp 7y ago
      They surely write papers about it. I bet anyone at Google is able to access ACM, SIGPLAN, HOPL, IEEE, USENIX papers.
- account42 7y ago
  Most programming language implementations don't try to avoid using libc.
- bregma 7y ago
  OK. Rust, too.
- kerkeslager 7y ago
  Well, for one, you can learn from other people's mistakes, which is better than learning from your own, because then you don't have to feel the pain. Go is a deserving target for this criticism because the language itself deliberately made a lot of the mistakes other language communities made and learned from, like weak typing[1] and naive garbage collection algorithms. Literally if you opened an undergraduate textbook on either topic you'd see much better ways to do things. But early adopters argued vehemently that Go was simple and didn't need those things. It does seem like Go is learning from their mistakes here: they've introduced precise garbage collection and it seems like some form of generic or template types are inbound in the next few releases. Perhaps in a few years Go will be a language I am willing to work in. But it would have been nice if a new language which already had these problems worked out had become popular, instead Go, which has reached popularity through hype rather than technical merit[2]. Tracking the history of template/generic types has been somewhat humorous: you can almost see it in this article[3] where the author starts in with the title "Who needs generics!", goes on to describe some frankly horrible ways to get around the lack of generics (it's amazing how complex Go's simplicity can be!) and finally backpedals in an update ("I am the last one to balk at the idea of generics in Go."). I don't mean this to be picking on the author here though--I've seen this history played out on other blogs and in the comments of Hacker News as well. [1] Before you flame me on this, ask yourself if you can articulate the difference between strong and static types, because if you can't, you don't have the prerequisite knowledge to have an opinion on this. [2] It's worth noting that the decisions made in Go probably have merit within the context of Google. The problem is that most Go users aren't at Google, and have different problems than Google, so the tradeoffs made by Go are nonsensical for their use cases. [3] https://appliedgo.net/generics/ https://appliedgo.net/generics/
  - deleted 7y ago
    [deleted]
  - inopinatus 7y ago
    The question was and is rhetorical. People don’t inwardly digest the mistakes of others. And anthropomorphising a language? Most peculiar. None of this makes NIH a less than widespread phenomenon. The readers of this forum often do know their type theory. Gatekeeping otherwise won’t go over well, it just reads like an arrogant insult from someone utterly lacking in self-awareness and accustomed to presuming themselves the smartest person in the room with the only relevant opinion. Ironically, given the subtopic, much like Google often does.
nuclearnice1 7y ago
> It's like this new trend, let's rewrite everything in Go to be cool. Financially makes little to no sense. Ha. This is maybe the archetypal software dev story. React? Java once? C++ for OO?
iknowstuff 7y ago
I.e. https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/ https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild...
fnord77 7y ago
guess what other shiny new language is doing that, too...
- jeltz 7y ago
  Zig?
  - fnord77 7y ago
    I was thinking Rust, but in reality it's probably all of them :)
necovek 7y ago
You lose a lot of allure of Go if "the world" is not implemented in it (mostly safety) — I think that is the core reason everything is reimplemented in Go. Of course, the real reason is the same reason even Go exists — we always think we can do something better the next time :) But hindsight is not 20/20 when it comes to software development.

by kerng 7y ago

inopinatus 7y ago

Let’s not just target Go with that sentiment, it applies almost universally, just in varying degree. Counterpoint: how is anyone supposed to learn, if not from their mistakes? We might worry about the blast radius, but there’s no compression algorithm for experience.

rimliu 7y ago
Another option is to learn from the mistakes of others.
- gfxgirl 7y ago
  The problem is you don't even know where to learn about the mistakes of others until you make the mistake yourself and in making the mistake you get some clue was to what to search for that then uncovers the mistakes of others.
  - kerkeslager 7y ago
    I've found that when I ask others what mistakes I should avoid, they tend to answer the question. Another way to discover any mistakes is to ask people why they didn't do certain things which you think are good ideas. Often that reveals that they did do that, and it turned out poorly.
- bregma 7y ago
  People rarely post their mistakes to stack overflow.
  - pjmlp 7y ago
    They surely write papers about it. I bet anyone at Google is able to access ACM, SIGPLAN, HOPL, IEEE, USENIX papers.
account42 7y ago
Most programming language implementations don't try to avoid using libc.
bregma 7y ago
OK. Rust, too.
kerkeslager 7y ago
Well, for one, you can learn from other people's mistakes, which is better than learning from your own, because then you don't have to feel the pain. Go is a deserving target for this criticism because the language itself deliberately made a lot of the mistakes other language communities made and learned from, like weak typing[1] and naive garbage collection algorithms. Literally if you opened an undergraduate textbook on either topic you'd see much better ways to do things. But early adopters argued vehemently that Go was simple and didn't need those things. It does seem like Go is learning from their mistakes here: they've introduced precise garbage collection and it seems like some form of generic or template types are inbound in the next few releases. Perhaps in a few years Go will be a language I am willing to work in. But it would have been nice if a new language which already had these problems worked out had become popular, instead Go, which has reached popularity through hype rather than technical merit[2]. Tracking the history of template/generic types has been somewhat humorous: you can almost see it in this article[3] where the author starts in with the title "Who needs generics!", goes on to describe some frankly horrible ways to get around the lack of generics (it's amazing how complex Go's simplicity can be!) and finally backpedals in an update ("I am the last one to balk at the idea of generics in Go."). I don't mean this to be picking on the author here though--I've seen this history played out on other blogs and in the comments of Hacker News as well. [1] Before you flame me on this, ask yourself if you can articulate the difference between strong and static types, because if you can't, you don't have the prerequisite knowledge to have an opinion on this. [2] It's worth noting that the decisions made in Go probably have merit within the context of Google. The problem is that most Go users aren't at Google, and have different problems than Google, so the tradeoffs made by Go are nonsensical for their use cases. [3] https://appliedgo.net/generics/ https://appliedgo.net/generics/
- deleted 7y ago
  [deleted]
- inopinatus 7y ago
  The question was and is rhetorical. People don’t inwardly digest the mistakes of others. And anthropomorphising a language? Most peculiar. None of this makes NIH a less than widespread phenomenon. The readers of this forum often do know their type theory. Gatekeeping otherwise won’t go over well, it just reads like an arrogant insult from someone utterly lacking in self-awareness and accustomed to presuming themselves the smartest person in the room with the only relevant opinion. Ironically, given the subtopic, much like Google often does.

nuclearnice1 7y ago

> It's like this new trend, let's rewrite everything in Go to be cool. Financially makes little to no sense. Ha. This is maybe the archetypal software dev story. React? Java once? C++ for OO?

iknowstuff 7y ago

I.e. https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/ https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild...

fnord77 7y ago

guess what other shiny new language is doing that, too...

jeltz 7y ago
Zig?
- fnord77 7y ago
  I was thinking Rust, but in reality it's probably all of them :)

necovek 7y ago

You lose a lot of allure of Go if "the world" is not implemented in it (mostly safety) — I think that is the core reason everything is reimplemented in Go. Of course, the real reason is the same reason even Go exists — we always think we can do something better the next time :) But hindsight is not 20/20 when it comes to software development.