"You really don't need X for Go" is becoming the Go community catchphrase. And they're right: I won't need anything for Go because I wouldn't use a language whose community actively resists improvement.
There's no language you couldn't construct a similar argument for, is there? Except maybe Perl. There's always going to be some capability favored by some loud person who's going to publicly disqualify some language for not having that feature.
Weird that in this case it's an equivalent of npm or Rubygems, which are nice tools for beginners but a complete pain in the ass for serious projects; essentially, you're disqualifying Golang for not reinventing DLL Hell like everyone else.
> which are nice tools for beginners but a complete pain in the ass for serious projects
I'd be interested in hearing more of your perspective here, because mine is the exact opposite. Newbie writing some small scripts? Don't worry about RubyGems. Writing a real project without Bundler? I think I'll pass...
I honestly don't care that much about package management: that's only symptomatic of the deeper issues with Go.
> Weird that in this case it's an equivalent of npm or Rubygems, which are nice tools for beginners but a complete pain in the ass for serious projects; essentially, you're disqualifying Golang for not reinventing DLL Hell like everyone else.
npm and RubyGems have two basic problems:
1. Curation of package sources.
2. People installing packages they shouldn't have.
Curation of package sources: notice that people don't complain nearly as much about dpkg/apt packages: they're curated much more carefully than npm/RubyGems packages (which is to say, they are curated).
People installing packages they shouldn't have: often the problems people run into with package management are self-inflicted. The adage is old: "Libraries from CPAN should not be treated as if they were part of the core." "Everyone else", as you say, is not experiencing DLL hell. I have zero difficulty with package management, because I use mature libraries and specify versions in my package configurations. There's no excuse to be experiencing DLL hell these days. The people who experience DLL hell are the ones who don't check in package configurations and then are surprised when the 0.1 alpha package they installed makes a breaking change and they don't know which version their code works with.
This is a problem in the Ruby community in particular because part of the draw of Ruby is "there's a package for everything". Newbie devs get caught up in the ecstatic frenzy of solving all their problems with gems without researching or testing those gems at all. But that's not a problem solved by Go's lack of a package manager, it's a problem solved by looking more carefully at what dependencies you introduce before introducing them.
There's no language you couldn't construct a similar argument for, is there? Except maybe Perl. There's always going to be some capability favored by some loud person who's going to publicly disqualify some language for not having that feature.
Weird that in this case it's an equivalent of npm or Rubygems, which are nice tools for beginners but a complete pain in the ass for serious projects; essentially, you're disqualifying Golang for not reinventing DLL Hell like everyone else.
Generics, I get. Package management?