4 ms·
There's always been a lot of disfunction with the way the Go team does stuff. These same points about Gerrit were made more broadly years ago. Gerrit was viewed
by kodah 4y ago
There's always been a lot of disfunction with the way the Go team does stuff. These same points about Gerrit were made more broadly years ago. Gerrit was viewed as an arbitrary barrier to getting changes in. They vowed to make it better and as far as I'm aware, not much has changed.
The same human processes broke down when Google acquired GoDoc and rewrote it using proprietary Google tech. I watched employees argue down people concerned with the effects of taking something fundamentally open and making it fundamentally closed, and subsequently making it dependent on GCP infrastructure.
This just skims the surface of what's gone on over the years. Generally, if you're frustrated by the way Go does stuff, I'd say you need to realize that their internal priorities trump external ones and that cannot be shifted.
- klabb3 4y agoI don't disagree, but you're, imo, cherry picking. Go started out as a language with many flaws for people outside of Google. The absolute awful GOPATH based dep management was made for monorepos, for instance. As time went by, they added unglamorous tooling and fixes that just makes Go a pleasure to work outside of Google, in more domains than originally intended. Compare that with C# or Objective C.
- klooney 4y agoAs a Python person, GOPATH always made a lot of sense to me. It's just a one variable virtualenv.
- marcosdumay 4y agoVirtualenvs do make some sense for interpreted languages, but are far from the best solution to the problem. Other compiled languages resolve their dependencies without any special configuration. Or, if you want to use non-shared dependencies, with project-wide configuration, not system-wide.
- klooney 4y agoMy other point of reference is rubygems, which is strictly worse and has lots of weird pollution issues.
- kcartlidge 4y ago> Compare that with C# or Objective C. As a dev using both Go and C# I'm not entirely sure what you mean? C# is great to work with outside Microsoft, it has lots of non-MS code in it, has masses of unglamorous tooling and fixes, and is used across a load of domains. I don't know about Objective C (that's not my bag) but I'm really missing the point re C#.
- KyeRussell 4y agoMore to the point, Objective C is wrapped up in decades and decades of weird history. Swift is a more apt comparison, with much more alike.