4 ms·

Interestingly, I think this is related to Go's success, much to the chagrin of its functional-programming detractors. While there might be a dozen or more ways

Interestingly, I think this is related to Go's success, much to the chagrin of its functional-programming detractors. While there might be a dozen or more ways to write a subroutine in Haskell or Lisp, there is more or less one way in Go. Further, the route in Go is probably not as elegant (according to popular opinion, anyway) than in functional languages, so fewer are tempted to improve upon it. That said, contrary to this article, Go isn't harder to develop in than Lisp; it's likely easier because there is one way to solve any given problem, and that way is usually quite straightforward. This isn't meant as a "Go is better than Lisp" post; I can appreciate each for its strengths. This is just marveling at the nuances of psychology and it's impact on the technical domain.

pmoriarty 9y ago
Similar things were said in favor of Python over Perl, back in the day. Python had the "there's one way to do it" motto, directly in opposition to Perl's "there's more than one way to do it". In reality, one only need look at the many different package management attempts to see how Python failed at living up to its own aspirations. If more evidence is needed, take a look at the packages themselves, and you'll see lots and lots of duplication of effort and incompatible ways of doing the same thing. Perl's CPAN was widely reviled by Python fans for having lots of cruft collected over the decades, and not knowing if the package one uses is the "right way to do it", and Python's "one way to do it" approach was supposed to be a solution to that. Well, it didn't work out that way. There are now tons of crufty Python packages, with similar quality control issues. I think this is merely a result of a language becoming popular and having a robust community of developers. Developers like to re-implement things and write them from scratch, whether just for their own education or amusement, or for geek cred, or to look good on a resume, or because they finally want to write it "the right way" (of which everyone seems to have a different opinion on). Then they abandon packages when they're no longer interested or when something else takes priority. Happens all the time. If Go hasn't had something like this happen to it yet, it could be because of some visionary design that somehow avoided these issues, or it could be that it's just not as old and popular yet.
- weberc2 9y ago
  Go simply isn't as flexible as Python. It's statically typed with no generics, so there is no "for loop vs map/filter/reduce" or "imperative vs functional" conversation to be had. This is categorically different than Python vs Perl, because Python's simplicity boasts were based on the discipline of the community as opposed to technical rails, as in Go's case.
- m3talsmith 9y ago
  Regarding Go and package management, I'd say that Go doesn't have that issue yet because there really is no package management outside of using mercurial or got repositories. They are working on vendorizing those in a one way fashion and expect, as a Go programmer, that there will be am explosion of drift in due time. As you stated, "I think this is merely a result of a language becoming popular and having a robust community of developers." I couldn't have put it more succinctly.

pmoriarty 9y ago

Similar things were said in favor of Python over Perl, back in the day. Python had the "there's one way to do it" motto, directly in opposition to Perl's "there's more than one way to do it". In reality, one only need look at the many different package management attempts to see how Python failed at living up to its own aspirations. If more evidence is needed, take a look at the packages themselves, and you'll see lots and lots of duplication of effort and incompatible ways of doing the same thing. Perl's CPAN was widely reviled by Python fans for having lots of cruft collected over the decades, and not knowing if the package one uses is the "right way to do it", and Python's "one way to do it" approach was supposed to be a solution to that. Well, it didn't work out that way. There are now tons of crufty Python packages, with similar quality control issues. I think this is merely a result of a language becoming popular and having a robust community of developers. Developers like to re-implement things and write them from scratch, whether just for their own education or amusement, or for geek cred, or to look good on a resume, or because they finally want to write it "the right way" (of which everyone seems to have a different opinion on). Then they abandon packages when they're no longer interested or when something else takes priority. Happens all the time. If Go hasn't had something like this happen to it yet, it could be because of some visionary design that somehow avoided these issues, or it could be that it's just not as old and popular yet.

weberc2 9y ago
Go simply isn't as flexible as Python. It's statically typed with no generics, so there is no "for loop vs map/filter/reduce" or "imperative vs functional" conversation to be had. This is categorically different than Python vs Perl, because Python's simplicity boasts were based on the discipline of the community as opposed to technical rails, as in Go's case.
m3talsmith 9y ago
Regarding Go and package management, I'd say that Go doesn't have that issue yet because there really is no package management outside of using mercurial or got repositories. They are working on vendorizing those in a one way fashion and expect, as a Go programmer, that there will be am explosion of drift in due time. As you stated, "I think this is merely a result of a language becoming popular and having a robust community of developers." I couldn't have put it more succinctly.