4 ms·

I have read many "criticism of Go" articles and this one is one of the most direct-to-the point. TL;DR: topics covered: 1. capitalization rules create inconsi

I have read many "criticism of Go" articles and this one is one of the most direct-to-the point. TL;DR: topics covered: 1. capitalization rules create inconsistent behavior 2. Structs do not explicitly declare which interfaces they implement. 3. No exceptions 4. A very good one: "Here’s far too much magical behavior. For example, if I name my source file i_love_linux.go, it won’t get compiled on my Mac. If I accidentally name a function init() it’ll get run automatically. (...) It’s fine for small projects but bites you on large ones, and Go was meant to address the problem of “programming in the large”." 5. Identifier name clashes 6. It’s difficult to generate Go code automatically due to the compiler being picky on imports, etc. 7. No ternary operator. 8. (complaint about sort.interface{} that could have been solved using generics) 9. "Import versioning and vendoring is terrible. " 10. No generics. 11. "The append() function modifies the array in-place when it can, and only returns a different array if it has no place left. You couldn’t ask for worse API design. How many bugs are caused by forgetting to assign the result? A lot, because initial testing may not trigger a resize." I would personally replace (6) with "absolutely no half-decent metaprogramming abilities (nor an expressive type system that could give you a workaround here.)"

kardianos 9y ago
1. Capitalization. Author cited they didn't want to change how they named things and it conflicted with Go export rules. Okay then. > 4. A very good one: "Here’s far too much magical behavior. For example, if I name my source file i_love_linux.go, it won’t get compiled on my Mac. If I accidentally name a function init() it’ll get run automatically. (...) It’s fine for small projects but bites you on large ones, and Go was meant to address the problem of “programming in the large”." 4. is great for large projects. Once you learn the convention, it is super easy to see which files are for which platforms. It makes it to navigate large trees. 6. Look at how protobufs do it. Easy to work around. 11. Understand how Go works, run go vet.
pdpi 9y ago
The capitalisation issue is the sort of thing you'd tell a junior developer to avoid in code review: By tying one design decision (what access levels are possible) to another (code style), they effectively made it impossible to cleanly change the design around the former, because the latter won't admit any more values.
- andyfleming 9y ago
  The language design choice to use capitalization instead of a public/private keywords is, in my opinion, a poor one. It seems like they've made choices to minimize keywords rather than be explicit and intuitive. I'm not saying that it can't be learned/taught. Also, IDEs like GoLand help, but at the end of the day the capitalization approach seems like an unnecessary annoyance
  - tschellenbach 9y ago
    Python does something similar with the _hidden __morehidden syntax. Some people will like the syntax, others won't. It doesn't really change anything about what you can achieve with Go.
  - pdpi 9y ago
    It's awkward but can absolutely be learned and taught. What makes it really idiotic is that the spec literally ties visibility to a single, specific unicode character class. This has the hilarious effect that, for example, Latin, Greek, Cyrillic identifiers are allowed to be public, but Arabic, Korean (Hangul) or Thai are not!
  - s17n 9y ago
    Nope, the point is consistency in large organizations. In other languages, teams develop naming conventions like these. Having them in the language reduces the overhead of reading a new codebase.
    - andyfleming 9y ago
      There's a difference between consistent code style and forced language conventions. Also, I'm not sure you'll be able to convince me that reading "public" and "private" add meaningful cognitive load to reading code.
      - s17n 9y ago
        Right, the difference is that the former isn’t real. When you have millions to billions of LoC developed by thousands to hundreds of thousands of developers anything not forced isn’t going to be consistent.
drdaeman 9y ago
You forgot URLs as import namespaces. It makes it literally impossible to swap one library for another (a rename or fork). A simple example that had caused tons of grief and had probably wasted lots of man-hours is when github.com/Sirupsen/logrus became github.com/sirupsen/logrus. Vendoring sort of works for simpler "I need a patched version of this" cases, but is not a real solution.

kardianos 9y ago

1. Capitalization. Author cited they didn't want to change how they named things and it conflicted with Go export rules. Okay then. > 4. A very good one: "Here’s far too much magical behavior. For example, if I name my source file i_love_linux.go, it won’t get compiled on my Mac. If I accidentally name a function init() it’ll get run automatically. (...) It’s fine for small projects but bites you on large ones, and Go was meant to address the problem of “programming in the large”." 4. is great for large projects. Once you learn the convention, it is super easy to see which files are for which platforms. It makes it to navigate large trees. 6. Look at how protobufs do it. Easy to work around. 11. Understand how Go works, run go vet.

pdpi 9y ago

The capitalisation issue is the sort of thing you'd tell a junior developer to avoid in code review: By tying one design decision (what access levels are possible) to another (code style), they effectively made it impossible to cleanly change the design around the former, because the latter won't admit any more values.

andyfleming 9y ago
The language design choice to use capitalization instead of a public/private keywords is, in my opinion, a poor one. It seems like they've made choices to minimize keywords rather than be explicit and intuitive. I'm not saying that it can't be learned/taught. Also, IDEs like GoLand help, but at the end of the day the capitalization approach seems like an unnecessary annoyance
- tschellenbach 9y ago
  Python does something similar with the _hidden __morehidden syntax. Some people will like the syntax, others won't. It doesn't really change anything about what you can achieve with Go.
- pdpi 9y ago
  It's awkward but can absolutely be learned and taught. What makes it really idiotic is that the spec literally ties visibility to a single, specific unicode character class. This has the hilarious effect that, for example, Latin, Greek, Cyrillic identifiers are allowed to be public, but Arabic, Korean (Hangul) or Thai are not!
- s17n 9y ago
  Nope, the point is consistency in large organizations. In other languages, teams develop naming conventions like these. Having them in the language reduces the overhead of reading a new codebase.
  - andyfleming 9y ago
    There's a difference between consistent code style and forced language conventions. Also, I'm not sure you'll be able to convince me that reading "public" and "private" add meaningful cognitive load to reading code.
    - s17n 9y ago
      Right, the difference is that the former isn’t real. When you have millions to billions of LoC developed by thousands to hundreds of thousands of developers anything not forced isn’t going to be consistent.

drdaeman 9y ago

You forgot URLs as import namespaces. It makes it literally impossible to swap one library for another (a rename or fork). A simple example that had caused tons of grief and had probably wasted lots of man-hours is when github.com/Sirupsen/logrus became github.com/sirupsen/logrus. Vendoring sort of works for simpler "I need a patched version of this" cases, but is not a real solution.