5 ms·

> I have an irrational hatred for the Go language Do you mind sharing why?

serverholic 5y ago
Not the same person but I share his sentiment. Go is terribly designed from a language perspective. It's weird and doesn't follow normal language conventions. The tooling and package manager is terrible. Eventually I think it'll be seen as the next PHP. A language that people love to hate.
- eyelidlessness 5y ago
  I haven’t written any Go, but having read through some tutorials I find this a little hard to believe. Besides, Node has already been the next PHP, in terms of reputation and ridicule, for almost its entire lifespan. I do expect Go will become more esoteric over time, but mostly because it’s a Google thing (with all the unpredictability that implies), and because it overlaps a couple rapidly evolving use case targets.
  - azurelake 5y ago
    It's not. For the niche it has found success in (infra type backend stuff), it's by far the best option available. `if err != nil` is a godsend in that world.
    - ciupicri 5y ago
      What's so great about `if err != nil` ?
      - linkdd 5y ago
        In theory: explicit error handling. An error should be taken care of immediately, or propagated with some additional context. Returning the error instead of throw/catch makes this explicit and forces the developer to think about it. In practice: a lot of boilerplate code. Rust does this better with the Result type and the ? operator.
        eyelidlessness 5y ago
        From a pragmatic perspective, the theoretical advantage is real (typed exceptions are better than not having them, just as explicit nullables are better than implicit). Theoretically Result and Option are just recognized names, which I don’t mean to discount but they’re effectively union types with pattern recognition privileges.
      - dmitshur 5y ago
        I like the “opportunity for correction” and “code proportionality” points brought up in https://medium.com/@shazow/code-boilerplate-is-it-always-bad-934827efcfc7 https://medium.com/@shazow/code-boilerplate-is-it-always-bad....
- linkdd 5y ago
  I think the only reason Go was adopted is because Google was behind and pushing it. But the result is that today, the ecosystem is huge. Implementing a kubectl plugin in Go is far easier than in other languages. Many things are in fact simpler with Go thanks to its vast stdlib and ecosystem. I hate it, and yet... It's still useful to me.
  - dotancohen 5y ago
    Go is terrific for multithreaded apps. Or multithreaded scripts. But if I know that I'm going to be running everything in a single thread I wouldn't even consider Go.
    - linkdd 5y ago
      > Go is terrific for multithreaded apps. Yes, true. But so is Erlang/Elixir.
      - dotancohen 5y ago
        Thank you. I've never used Erlang though I understand that it's philosophy is well suited to high-uptime applications such as servers, which I do work on. I will definitely give it a test drive.
    - Gwypaas 5y ago
      I would say it works as long as you don't need any major coordination outside of a few channels. As soon as you get into mutex territory you happily end up shooting yourself in the foot hoping that go test -race caught the bug someone else introduced. Or you spend unnecessary time implementing some concurrent safe type trying to hide the synchronization behind a pretty interface. At work we have a split code base between rust and go, using go to interface with the world due to better ecosystem while using rust for the heavy lifting of business logic in an extremely concurrent implementation. Even though the rust side is more complex it is much easier to work with and refactor leading to fewer bugs. The language simply gives so much for free, when you get over the first humps of a slow start. The Rust cycle of 1. make it work, 2. handle errors, 3. encode invariants in the type system to prevent inadvertent refactors is simply magical.
- pirate787 5y ago
  PHP powers a vast part of the web ecosystem, is far more accessible to learn and deploy than Go, and the language is greatly improved and even loved by many.
- eloisius 5y ago
  > It's weird and doesn't follow normal language conventions Maybe this is a key ingredient in successful languages. Just warty and anachronistic enough that users learn a lot of unique patterns that keep them glued to the language.
linkdd 5y ago
My biggest annoyance is that the Go language is full of implicit conventions/behaviors: - interface implementation is implicit - "export" is based on the function/type/member name (first letter uppercase) - private functions/types/members are private within a package not a single file - ... This is painful because when you read a single file, you need to know about the rest of the code. This makes it very hard to get started with a new codebase, especially a huge codebase. The other annoyances I have are just petty, like "if err != nil", zero-values, or the fact that VS Code still does not support Go projects in subdirectories (I like to open my whole "devel" folder).
- yzmtf2008 5y ago
  > interface implementation is implicit Fun fact: this is true for python too! https://stackoverflow.com/questions/40764347/python-subclasscheck-subclasshook https://stackoverflow.com/questions/40764347/python-subclass...
- iljya 5y ago
  > VS Code still does not support Go projects in subdirectories This is annoying, but there is a workaround: add each folder with a go.mod file individually starting with the most nested ones first. So add each project separately, then add the root dir.
  - linkdd 5y ago
    Unpractical for me, my "devel" folder is organized as follow: |-+ orga (github, gitlab, other) | |-+ domain (infra, business, research, ...) | | |-+ repo-name VS Code do not support hierarchies of projects in a workspace, so I would just have a huge list of `project-name` where project-name would be manually renamed to `orga/domain/repo-name`.

Not the same person but I share his sentiment. Go is terribly designed from a language perspective. It's weird and doesn't follow normal language conventions. The tooling and package manager is terrible. Eventually I think it'll be seen as the next PHP. A language that people love to hate.

eyelidlessness 5y ago
I haven’t written any Go, but having read through some tutorials I find this a little hard to believe. Besides, Node has already been the next PHP, in terms of reputation and ridicule, for almost its entire lifespan. I do expect Go will become more esoteric over time, but mostly because it’s a Google thing (with all the unpredictability that implies), and because it overlaps a couple rapidly evolving use case targets.
- azurelake 5y ago
  It's not. For the niche it has found success in (infra type backend stuff), it's by far the best option available. `if err != nil` is a godsend in that world.
  - ciupicri 5y ago
    What's so great about `if err != nil` ?
    - linkdd 5y ago
      In theory: explicit error handling. An error should be taken care of immediately, or propagated with some additional context. Returning the error instead of throw/catch makes this explicit and forces the developer to think about it. In practice: a lot of boilerplate code. Rust does this better with the Result type and the ? operator.
      - eyelidlessness 5y ago
        From a pragmatic perspective, the theoretical advantage is real (typed exceptions are better than not having them, just as explicit nullables are better than implicit). Theoretically Result and Option are just recognized names, which I don’t mean to discount but they’re effectively union types with pattern recognition privileges.
    - dmitshur 5y ago
      I like the “opportunity for correction” and “code proportionality” points brought up in https://medium.com/@shazow/code-boilerplate-is-it-always-bad-934827efcfc7 https://medium.com/@shazow/code-boilerplate-is-it-always-bad....
linkdd 5y ago
I think the only reason Go was adopted is because Google was behind and pushing it. But the result is that today, the ecosystem is huge. Implementing a kubectl plugin in Go is far easier than in other languages. Many things are in fact simpler with Go thanks to its vast stdlib and ecosystem. I hate it, and yet... It's still useful to me.
- dotancohen 5y ago
  Go is terrific for multithreaded apps. Or multithreaded scripts. But if I know that I'm going to be running everything in a single thread I wouldn't even consider Go.
  - linkdd 5y ago
    > Go is terrific for multithreaded apps. Yes, true. But so is Erlang/Elixir.
    - dotancohen 5y ago
      Thank you. I've never used Erlang though I understand that it's philosophy is well suited to high-uptime applications such as servers, which I do work on. I will definitely give it a test drive.
  - Gwypaas 5y ago
    I would say it works as long as you don't need any major coordination outside of a few channels. As soon as you get into mutex territory you happily end up shooting yourself in the foot hoping that go test -race caught the bug someone else introduced. Or you spend unnecessary time implementing some concurrent safe type trying to hide the synchronization behind a pretty interface. At work we have a split code base between rust and go, using go to interface with the world due to better ecosystem while using rust for the heavy lifting of business logic in an extremely concurrent implementation. Even though the rust side is more complex it is much easier to work with and refactor leading to fewer bugs. The language simply gives so much for free, when you get over the first humps of a slow start. The Rust cycle of 1. make it work, 2. handle errors, 3. encode invariants in the type system to prevent inadvertent refactors is simply magical.
pirate787 5y ago
PHP powers a vast part of the web ecosystem, is far more accessible to learn and deploy than Go, and the language is greatly improved and even loved by many.
eloisius 5y ago
> It's weird and doesn't follow normal language conventions Maybe this is a key ingredient in successful languages. Just warty and anachronistic enough that users learn a lot of unique patterns that keep them glued to the language.

linkdd 5y ago

My biggest annoyance is that the Go language is full of implicit conventions/behaviors: - interface implementation is implicit - "export" is based on the function/type/member name (first letter uppercase) - private functions/types/members are private within a package not a single file - ... This is painful because when you read a single file, you need to know about the rest of the code. This makes it very hard to get started with a new codebase, especially a huge codebase. The other annoyances I have are just petty, like "if err != nil", zero-values, or the fact that VS Code still does not support Go projects in subdirectories (I like to open my whole "devel" folder).

yzmtf2008 5y ago
> interface implementation is implicit Fun fact: this is true for python too! https://stackoverflow.com/questions/40764347/python-subclasscheck-subclasshook https://stackoverflow.com/questions/40764347/python-subclass...
iljya 5y ago
> VS Code still does not support Go projects in subdirectories This is annoying, but there is a workaround: add each folder with a go.mod file individually starting with the most nested ones first. So add each project separately, then add the root dir.
- linkdd 5y ago
  Unpractical for me, my "devel" folder is organized as follow: |-+ orga (github, gitlab, other) | |-+ domain (infra, business, research, ...) | | |-+ repo-name VS Code do not support hierarchies of projects in a workspace, so I would just have a huge list of `project-name` where project-name would be manually renamed to `orga/domain/repo-name`.