4 ms·

I've had to use go occasionally and it feels like the language is designed to stop me from achieving my goals. The standard library is unimpressive (to be gene

by guappa 2y ago

I've had to use go occasionally and it feels like the language is designed to stop me from achieving my goals. The standard library is unimpressive (to be generous), it has plenty of footguns like C but none of its flexibility. Also for some reason parenthesis AND \n are required. So you get the worse of C and python there.

aftbit 2y ago
You're intended to run gofmt on every save. golang is designed to be a sort of straight-jacket that forces everyone to write code in the same way (style etc) so that the junior devs can understand it clearly.
- grey-area 2y ago
  And so that people (of any level) don't bikeshed over silly things like tabs and spaces or { and newlines. I really like this about go - that it formats code for you, and miss it in other languages where we have linters but not formatters, which is a terrible idea IMO.
  - School-Cotton 2y ago
    What mainstream languages don’t have formatters nowadays? Rust has rustfmt, C and related languages have clang-tidy, python has Black…
    - grey-area 2y ago
      I mean built in that everyone uses. There are of course third party formatters.
      - School-Cotton 2y ago
        You can force everyone on a project to use a formatter just as easily in any of those languages as you can in Go, with a few lines in your CI job definitions. Whether they're third-party or not is irrelevant.
        Mawr 2y ago
        It's not irrelevant, it's the entire point. The whole Go ecosystem uses a single formatter. There's no need to force anyone, everyone just uses gofmt. You will not be able to replicate that level of ubiquity easily at all.
        School-Cotton 2y ago
        Not really true because you have both gofmt and gofumpt, and gofmt can be run with -s or not, and also lots of projects are using separate linters to enforce maximum line length.
        mikeschinkel 2y ago
        But true enough.
        guappa 2y ago
        Not true. Because after running go fmt and pushing our CI fails because of other stylistic concerns that are checked by another tool.
        mikeschinkel 2y ago
        You can only force everyone on a project to use a formatter if you are the one who has the authority to decree what will be done on the team. OTOH, if you are but a team member and you join a team where the manager does not think common formatting is important, then you get f*ck all. So being built-in, idiomatic and expected cannot be over-appreciated.
  - mistrial9 2y ago
    that's your preference but not universal
    - grey-area 2y ago
      My only preference is not to have to think about whitespace etc. I guess others who feel differently certainly wouldn't like Go, and that's ok!
- guappa 2y ago
  Why are you talking about go fmt? I'm talking about parser of the go language If I write if x { bla } it will not compile, because the { needs to be on the same line as the X (for no reason whatsoever).
danudey 2y ago
> The standard library is unimpressive (to be generous) Coming from Python, this is one of the major things that I just can't get past with golang (despite having to use it for work). The standard library has a lot of really interesting/impressive/useful things to cover niche cases, but is missing a lot of what I would consider basic functionality that I keep running into requiring me to go get an external module to solve the problem. Then, on top of that, the documentation for external modules is extremely terrible. In many cases the best you can get is API documentation in the form of "these are the functions, this is what they take and return" with no explanation of what those values need to be, what the function does with them, and so on; a simple list of functions. In others, there is that plus example code which doesn't work because it hasn't been updated since the last time backwards-incompatible changes were made so you end up down a rabbit hole of trying to debug someone else's wrong code. The only thing letting me write effective golang at this point is that VSCode can autocomplete a lot of method calls, API calls, and so on, and then tell me what parameters they need, but even then I'm just guessing about what function might exist and what it might be called. The language itself is okay and the more I use it the more I understand why they implemented all the stuff I hate (like a lack of proper error handling leading to half of my lines of code being boilerplate `if err != nil` blocks), but if the tooling around it wasn't so good no one would take it remotely seriously.

by guappa 2y ago

aftbit 2y ago

You're intended to run gofmt on every save. golang is designed to be a sort of straight-jacket that forces everyone to write code in the same way (style etc) so that the junior devs can understand it clearly.

grey-area 2y ago
And so that people (of any level) don't bikeshed over silly things like tabs and spaces or { and newlines. I really like this about go - that it formats code for you, and miss it in other languages where we have linters but not formatters, which is a terrible idea IMO.
- School-Cotton 2y ago
  What mainstream languages don’t have formatters nowadays? Rust has rustfmt, C and related languages have clang-tidy, python has Black…
  - grey-area 2y ago
    I mean built in that everyone uses. There are of course third party formatters.
    - School-Cotton 2y ago
      You can force everyone on a project to use a formatter just as easily in any of those languages as you can in Go, with a few lines in your CI job definitions. Whether they're third-party or not is irrelevant.
      - Mawr 2y ago
        It's not irrelevant, it's the entire point. The whole Go ecosystem uses a single formatter. There's no need to force anyone, everyone just uses gofmt. You will not be able to replicate that level of ubiquity easily at all.
        School-Cotton 2y ago
        Not really true because you have both gofmt and gofumpt, and gofmt can be run with -s or not, and also lots of projects are using separate linters to enforce maximum line length.
        mikeschinkel 2y ago
        But true enough.
        guappa 2y ago
        Not true. Because after running go fmt and pushing our CI fails because of other stylistic concerns that are checked by another tool.
      - mikeschinkel 2y ago
        You can only force everyone on a project to use a formatter if you are the one who has the authority to decree what will be done on the team. OTOH, if you are but a team member and you join a team where the manager does not think common formatting is important, then you get f*ck all. So being built-in, idiomatic and expected cannot be over-appreciated.
- mistrial9 2y ago
  that's your preference but not universal
  - grey-area 2y ago
    My only preference is not to have to think about whitespace etc. I guess others who feel differently certainly wouldn't like Go, and that's ok!
guappa 2y ago
Why are you talking about go fmt? I'm talking about parser of the go language If I write if x { bla } it will not compile, because the { needs to be on the same line as the X (for no reason whatsoever).

danudey 2y ago

> The standard library is unimpressive (to be generous) Coming from Python, this is one of the major things that I just can't get past with golang (despite having to use it for work). The standard library has a lot of really interesting/impressive/useful things to cover niche cases, but is missing a lot of what I would consider basic functionality that I keep running into requiring me to go get an external module to solve the problem. Then, on top of that, the documentation for external modules is extremely terrible. In many cases the best you can get is API documentation in the form of "these are the functions, this is what they take and return" with no explanation of what those values need to be, what the function does with them, and so on; a simple list of functions. In others, there is that plus example code which doesn't work because it hasn't been updated since the last time backwards-incompatible changes were made so you end up down a rabbit hole of trying to debug someone else's wrong code. The only thing letting me write effective golang at this point is that VSCode can autocomplete a lot of method calls, API calls, and so on, and then tell me what parameters they need, but even then I'm just guessing about what function might exist and what it might be called. The language itself is okay and the more I use it the more I understand why they implemented all the stuff I hate (like a lack of proper error handling leading to half of my lines of code being boilerplate `if err != nil` blocks), but if the tooling around it wasn't so good no one would take it remotely seriously.