4 ms·

> You really don't need a package manager for Go. "You really don't need X for Go" is becoming the Go community catchphrase. And they're right: I won't need an

> You really don't need a package manager for Go. "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. I could respect that Go doesn't have a package manager, generics, etc., if the Go community took more of a "if you want it, develop it" approach. But instead, the core development team has made it unclear whether they would even accept some of these features. I get that compilation performance is a high priority, but they've missed the big picture, that developer time also matters. The following exemplifies the problem: > Note that because Go is a compiled language, the only time versioning comes into play is a development time. Oh, that won't affect me at all; development time is only like 90% of the life of a project.

jerf 12y ago
The community does not resist improvement. The community asks that you acquire some experience, work with what is there, make sure that you understand it, then suggest improvements. The community definitely does resist people who aren't even users loudly declaring exactly what it is that Go needs. I fear the community may have instinctively built up certain callouses that I'm not a big fan of, such as the near inability to have a sensible discussion about generics within the community due to the near inability to have a sensible discussion about generics outside of the community. It isn't all necessarily hunky-dory. But if you haven't used Go, which is what it sounds like to me, you don't understand the current situation's cost/benefit analysis and are unlikely to be able to "just" "solve" the community's "problems" without such an understanding. Step 1 of any engineering effort is identify the problem, and it can never be skipped, no matter how sure you are you can this time. If you're not a Go user, you've skipped this step. Of course you're free to A: not be a Go user for any reason you choose and B: say whatever you like about Go from the outside. And I really mean that, quite deeply, not merely as a rhetorical flourish. There's too many languages to become expert in them all and we all must choose carefully according to our own knowledge and desires. My only point here is only that you shouldn't expect the community to be enthralled with the resulting commentary.
- copsarebastards 12y ago
  > The community asks that you acquire some experience, work with what is there, make sure that you understand it, then suggest improvements. So what is it that you think people who want Go to have generics don't understand? You say that people should acquire some experience before criticizing Go, but you're only accepting a certain kind of experience. I've written tens of thousands of lines of code in similar languages without generics, and tens of thousands of lines of code in similar languages with generics, and there is no question which I would rather write. I have written a number of compilers and am well aware of the concerns and how to implement a performant compiler. Why is that experience not something you value? You're basically creating a chicken and egg problem: people who like Go will use it, and people who don't like Go won't, and what you're saying is that the latter won't be allowed to criticize Go. But people who don't like Go are the only ones who are going to ever criticize Go. And criticism is what anything needs to not suck. Don't talk to me about "acquiring experience" as an excuse to discard any experience that comes from outside your community. My core complaint about Go: the authors simply have ignored decades of compiler research. By deciding that only users of Go can criticize Go, you're deciding to only take feedback from people who would use Go, and the only people who would use Go are people who aren't aware of the last few decades of compiler research: people who think coroutines are a new idea and aren't sure whether generics are useful. As an outsider to the community, I wouldn't care if Go is crappy, except that I work in this industry, and if Go becomes popular enough, a situation will arise where I have to use Go or a language that imitates Go, or turn down a job because of it. Go being terrible and popular means that it affects the whole software industry negatively. Also, arguing that I need more Go experience to criticize Go is somewhat ridiculous in response to an article which says, "Being an advocate is not really a separate stage, but a role you can fill at any of the other stages." So you need Go experience to criticize Go, but you don't need Go experience to advocate for it? This is why I assert that Go's popularity is mostly hype.
  - bonn1 12y ago
    > By deciding that only users of Go can criticize Go This describes my feeling when going through the thread and reading that significant weaknesses of Go are not significant.
tptacek 12y ago
"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. Generics, I get. Package management?
- steveklabnik 12y ago
  > 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...
- copsarebastards 12y ago
  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.

jerf 12y ago

The community does not resist improvement. The community asks that you acquire some experience, work with what is there, make sure that you understand it, then suggest improvements. The community definitely does resist people who aren't even users loudly declaring exactly what it is that Go needs. I fear the community may have instinctively built up certain callouses that I'm not a big fan of, such as the near inability to have a sensible discussion about generics within the community due to the near inability to have a sensible discussion about generics outside of the community. It isn't all necessarily hunky-dory. But if you haven't used Go, which is what it sounds like to me, you don't understand the current situation's cost/benefit analysis and are unlikely to be able to "just" "solve" the community's "problems" without such an understanding. Step 1 of any engineering effort is identify the problem, and it can never be skipped, no matter how sure you are you can this time. If you're not a Go user, you've skipped this step. Of course you're free to A: not be a Go user for any reason you choose and B: say whatever you like about Go from the outside. And I really mean that, quite deeply, not merely as a rhetorical flourish. There's too many languages to become expert in them all and we all must choose carefully according to our own knowledge and desires. My only point here is only that you shouldn't expect the community to be enthralled with the resulting commentary.

copsarebastards 12y ago
> The community asks that you acquire some experience, work with what is there, make sure that you understand it, then suggest improvements. So what is it that you think people who want Go to have generics don't understand? You say that people should acquire some experience before criticizing Go, but you're only accepting a certain kind of experience. I've written tens of thousands of lines of code in similar languages without generics, and tens of thousands of lines of code in similar languages with generics, and there is no question which I would rather write. I have written a number of compilers and am well aware of the concerns and how to implement a performant compiler. Why is that experience not something you value? You're basically creating a chicken and egg problem: people who like Go will use it, and people who don't like Go won't, and what you're saying is that the latter won't be allowed to criticize Go. But people who don't like Go are the only ones who are going to ever criticize Go. And criticism is what anything needs to not suck. Don't talk to me about "acquiring experience" as an excuse to discard any experience that comes from outside your community. My core complaint about Go: the authors simply have ignored decades of compiler research. By deciding that only users of Go can criticize Go, you're deciding to only take feedback from people who would use Go, and the only people who would use Go are people who aren't aware of the last few decades of compiler research: people who think coroutines are a new idea and aren't sure whether generics are useful. As an outsider to the community, I wouldn't care if Go is crappy, except that I work in this industry, and if Go becomes popular enough, a situation will arise where I have to use Go or a language that imitates Go, or turn down a job because of it. Go being terrible and popular means that it affects the whole software industry negatively. Also, arguing that I need more Go experience to criticize Go is somewhat ridiculous in response to an article which says, "Being an advocate is not really a separate stage, but a role you can fill at any of the other stages." So you need Go experience to criticize Go, but you don't need Go experience to advocate for it? This is why I assert that Go's popularity is mostly hype.
- bonn1 12y ago
  > By deciding that only users of Go can criticize Go This describes my feeling when going through the thread and reading that significant weaknesses of Go are not significant.

tptacek 12y ago

"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. Generics, I get. Package management?

steveklabnik 12y ago
> 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...
copsarebastards 12y ago
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.