3 ms·

In practice, golang is quite verbose (yes, more than Java) and its error handling is error prone. It has weak abstractions, and lack of proper enums also lend t

by apta 6y ago

In practice, golang is quite verbose (yes, more than Java) and its error handling is error prone. It has weak abstractions, and lack of proper enums also lend to more verbose and error prone code. Monitoring is poor compared to the JVM/.NET, and performance is worse in general. It has very questionable, if not outright bad design decisions (e.g. they wanted to save on keywords so they don't have public/private, so changing the visibility of a variable or function now results in a huge diff if it's used in many places). The list is too long to elaborate on in a few paragraphs.

cpuguy83 6y ago
> so changing the visibility of a variable or function now results in a huge diff if it's used in many places) You can create an exported version of the function (calling into the unexported one), no diff except the new function. But also just updating all the callsights is usually not a huge issue, especially if you are using an IDE such as GoLand.
- apta 6y ago
  > You can create an exported version of the function These are the kinds of hacks that show that golang wasn't really designed for "programming in the large", despite their claims. I've used goland, and the actual renaming is generally fine (it means it works correctly when needed). However, that doesn't mean that there isn't a lot of friction
  - cpuguy83 6y ago
    I don't agree with the term "hack" here. Different is not "hack". I maintain some very large codebases. This has never been an issue. If one decides to export a function, the only callers of that function will be from within the package it was defined in already. Even within a package, how many call sites will there actually be and do they need to use the exported version of the function? I'm not saying it's good, or bad, just that in my (fairly extensive) experience it has not been a problem. I do recognize that some people may have problems with it, though.
    - apta 6y ago
      My experience has been otherwise, it's been extremely friction-inducing and I had to go out of my way to split up diffs into smaller ones in order to make it clear what was going on. A language like Java or C# would have just had a single line difference (`-private +public`) and be done.

by apta 6y ago

cpuguy83 6y ago

> so changing the visibility of a variable or function now results in a huge diff if it's used in many places) You can create an exported version of the function (calling into the unexported one), no diff except the new function. But also just updating all the callsights is usually not a huge issue, especially if you are using an IDE such as GoLand.

apta 6y ago
> You can create an exported version of the function These are the kinds of hacks that show that golang wasn't really designed for "programming in the large", despite their claims. I've used goland, and the actual renaming is generally fine (it means it works correctly when needed). However, that doesn't mean that there isn't a lot of friction
- cpuguy83 6y ago
  I don't agree with the term "hack" here. Different is not "hack". I maintain some very large codebases. This has never been an issue. If one decides to export a function, the only callers of that function will be from within the package it was defined in already. Even within a package, how many call sites will there actually be and do they need to use the exported version of the function? I'm not saying it's good, or bad, just that in my (fairly extensive) experience it has not been a problem. I do recognize that some people may have problems with it, though.
  - apta 6y ago
    My experience has been otherwise, it's been extremely friction-inducing and I had to go out of my way to split up diffs into smaller ones in order to make it clear what was going on. A language like Java or C# would have just had a single line difference (`-private +public`) and be done.