3 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

• tomjen3 12y 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 12y 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).
    • tomjen3 12y ago
      >Learning an IDE isn't a big deal, but it isn't, say, preferable to not having to learn one. Everything else being equal, perhaps you are right. However by blessing one as the official editor the tools can be written to work with that rather than the lowest common denominator. This will make it more difficult for alternatives which is a cost, but I do believe the upside is worth it - unfortunately I can't prove it.
  • zaphar 12y ago
    It isn't a big deal for you maybe. But I work in many different languages in a day. Switching IDE's/editors is a context switch I shouldn't have to make. Go is one small step in that direction. You don't see an official recommendation because it's not necessary. Pretty much anything you use is going to have comparable functionality due to the work of the go team. Which is how I know that the Go team cares about tooling.
    • tomjen3 12y ago
      >Pretty much anything you use is going to have comparable functionality due to the work of the go team. Even so you force every new developer to look around to find whatever he wants, which makes getting started more difficult. Lets just say that I am a fan of the IntelliJ platform. Which plugin would I install to use with Go?
  • zaphar 12y ago
    For the record I don't think you deserve to be downvoted like this. You stated a valid opinion. Go is not meeting a need you have and thus the value proposition for you is not the same as mine. This appears to be a case of people downvoting because they disagree not due to the quality of your comment.
    • tomjen3 12y ago
      Thanks, but don't worry. I should have known better than attacking peoples choice of editors.
• rudolf0 12y ago
  The thing that really baffles me is that Go/Google have invested so much into tooling for the language, yet didn't bother to implement official tools for the most important feature of any language: package and dependency management. I've heard this explained as "everyone at Google just points their imports at Git repo HEADs", which is valid for a self-contained organization like that, but seems very closed-minded considering they want this language to be adopted universally.
  • zaphar 12y ago
    This is admittedly a shortfall of go. However it's one that is fairly easy to rectify later and one the community is quite capable of solving itself.
  • shoo 11y ago
    I guess I agree with you, that from some kind of evolutionary perspective, having yet another language-specific package and dependency management system, this time for Go, might be a good way to boost popularity / uptake of Go. The system doesn't necessarily need to be a good idea, just quick and easy to use. On the other hand, I think that dependency management isn't really a language specific problem, and it is silly to have different incompatible language-specific solutions for it. E.g. I work mainly with Python, that has popular python-specific packaging tools, yet those tools cannot express dependencies of python libraries upon e.g. native libraries. The python-specific tools are convenient on a pure-python project, for multi-language projects it feels more like an anti-pattern than a solution, particularly if you end up having to use many different packaging ecosystems / tools. I think google's approach makes more sense in the context of an organisation where some kind of uniform approach can be imposed, and particularly where there are uniform approaches to code quality / test coverage / continuous integration. To be clear -- I have never worked at google, this is my external perception. I have worked somewhere where there are simultaneous software projects with wildly varying levels of code quality / test coverage / continuous integration, this does not seem to agree with very well with the source-control-based "import from HEAD" in one big repository. The organisation is currently transitioning from this approach to more decentralised many-repository approach linked with language specific package management. I do not think this change is a clear improvement, but it does make some things easier.
• jmgao 12y ago
  Does go even have a usable debugger yet?
  • zaphar 12y ago
    Depends on your definition I guess. I don't debug that often but when I have had to I've found the GDB debugger to be good enough for my purposes.