5 ms·

The problem with Go is that, while the language and compiler are excellent, Google doesn't a lot care about tooling & ecosystem. Why? They have their own in-hou

The problem with Go is that, while the language and compiler are excellent, Google doesn't a lot care about tooling & ecosystem. Why? They have their own in-house tooling (which is of course both highly specific to Google's use case and closed of for the public). This in itself isn't bad, but the problem it causes is that the Googlers (who do not experience the pain that other users of the language do) are still the majority voice in any decision. Maybe not in numbers, but definitely in weight. There have been a number of changes pushed through that make sense in Google's use case but not for general development use. Stuff like declaring a folder named "internal" special where it wasn't before. Perfectly understandable in Google's internal uniform codebase, where nearly every package is understood and the world is small. Not a smart change to make a few years into the 1.0 compatibility freeze though, since you can bet that a lot (I even dare say a majority) of 'regular' developers won't know about this and might run into problems because of this at one point or another. This is just a small example that I can recall out of the top of my head but my worry is that this is happening more often with a lot of features. Counterarguments from Googlers are usually along the line of "Go has X contributors, only Y of which are Googlers", but that is not the full truth. The top 5 contributors are still employed by Google. If you read the golang-dev mailing list, especially when it comes to discussions about tooling and ecosystem, you'll see that the Googlers have an overwhelming voice and will not shy away from flat-out rejecting criticism to proposals that might be nice for Google's use case but cause ambiguity and complexity for other developers. Having said that, I still love the language and design. I just whished they shied away from magic comments and half-baked solutions for dependency management.

teddyh 11y ago
I tried to argue this five months ago when Go 1.4 was released: https://news.ycombinator.com/item?id=8733705 https://news.ycombinator.com/item?id=8733705 I was severely downvoted and did not get many who agreed with me.
- deleted 11y ago
  [deleted]
Spiritus 11y ago
>Stuff like declaring a folder named "internal" special where it wasn't before. Where can I read more about this?
NateDad 11y ago
They did a lot of research on the "internal" folder name and after downloading every github repo that contained go code, they found only a handful of repos that used a folder called internal. Don't think they went into that blind and just assumed no one used the name.
- castell 11y ago
  Many "internal" code bases don't reside on GitHub or are marked as "private". I do like Go lang, but some of their decisions are weird.
zaphar 11y ago
The problem with Go is that, while the language and compiler are excellent, Google doesn't a lot care about tooling & ecosystem. Why? They have their own in-house tooling (which is of course both highly specific to Google's use case and closed of for the public). This is the most bizarre criticism of go I have ever heard. Go has the best tooling of any language I have ever used bar none. A cursory look at: https://godoc.org/golang.org/x/tools/cmd https://godoc.org/golang.org/x/tools/cmd shows a list of tools I've been wanting in Java and C# for years and they practically come out of the box for go. * Automated refactoring that is editor agnostic? check. * Editor agnostic built in documentation tool/server? check. * Editor agnostic Code analyzers/oracles? check. Go's core dev team is many things but saying they don't care about tooling and ecosystem is a gross misrepresentation. They may not care about your specific IDE or preferred language design but they most definitely care about making tooling available to everyone regardless of IDE/editor choice.
- tomjen3 11y ago
  Eclipse has had those things for years for Java. Yeah that is not editor agnostic but when you sit down and learn a platform learning an IDE isn't a big deal. Speaking of which I do not see any official recommendation of an IDE for Go.
  - fixermark 11y ago
    That's the point---rather than create a tooling ecosystem that forces a particular IDE choice upon developers, Go is aiming for a set of minimally-sufficiently-powerful tools that IDEs can hook into. Learning an IDE isn't a big deal, but it isn't, say, preferable to not having to learn one. I know Eclipse, but I avoid using it in all contexts where I can---it's slow, its project model borders on filesystem hostility (and still sometimes requires a "throw up your hands and delete a bunch of dotfiles" solution to fixing breakages in it), and even after years of refactoring and improvements it will still go "out to lunch" on garbage collection and force a pause in my process that most IDEs will not. Being forced to use Eclipse would be a hindrance for me in picking up Go (and I think a similar argument can be made for being forced to use (X|X element of IDEs) across all developers).
tree_of_item 11y ago
> The problem with Go is that, while the language and compiler are excellent, Google doesn't a lot care about tooling & ecosystem. I'd say you got this exactly backwards. The language is mediocre, but the tooling and ecosystem are great. The `go` command in particular is something I really want in other languages: no messing around with build files or monsters like `cabal`.
- likeclockwork 11y ago
  "[Go] is a great [ecosystem], lacking only a decent [programming language."

teddyh 11y ago

I tried to argue this five months ago when Go 1.4 was released: https://news.ycombinator.com/item?id=8733705 https://news.ycombinator.com/item?id=8733705 I was severely downvoted and did not get many who agreed with me.

deleted 11y ago
[deleted]

Spiritus 11y ago

>Stuff like declaring a folder named "internal" special where it wasn't before. Where can I read more about this?

NateDad 11y ago

They did a lot of research on the "internal" folder name and after downloading every github repo that contained go code, they found only a handful of repos that used a folder called internal. Don't think they went into that blind and just assumed no one used the name.

castell 11y ago
Many "internal" code bases don't reside on GitHub or are marked as "private". I do like Go lang, but some of their decisions are weird.

zaphar 11y ago

tomjen3 11y ago
Eclipse has had those things for years for Java. Yeah that is not editor agnostic but when you sit down and learn a platform learning an IDE isn't a big deal. Speaking of which I do not see any official recommendation of an IDE for Go.
- fixermark 11y ago
  That's the point---rather than create a tooling ecosystem that forces a particular IDE choice upon developers, Go is aiming for a set of minimally-sufficiently-powerful tools that IDEs can hook into. Learning an IDE isn't a big deal, but it isn't, say, preferable to not having to learn one. I know Eclipse, but I avoid using it in all contexts where I can---it's slow, its project model borders on filesystem hostility (and still sometimes requires a "throw up your hands and delete a bunch of dotfiles" solution to fixing breakages in it), and even after years of refactoring and improvements it will still go "out to lunch" on garbage collection and force a pause in my process that most IDEs will not. Being forced to use Eclipse would be a hindrance for me in picking up Go (and I think a similar argument can be made for being forced to use (X|X element of IDEs) across all developers).

tree_of_item 11y ago

> The problem with Go is that, while the language and compiler are excellent, Google doesn't a lot care about tooling & ecosystem. I'd say you got this exactly backwards. The language is mediocre, but the tooling and ecosystem are great. The `go` command in particular is something I really want in other languages: no messing around with build files or monsters like `cabal`.

likeclockwork 11y ago
"[Go] is a great [ecosystem], lacking only a decent [programming language."