* Can't insist that epmd be started separately (`erl -no_epmd` won't start epmd but it also won't start epmd's gen_server)
* Can't swap out epmd because while `erl -epmd_module foo` is there, `net_kernel:epmd_module()` is barely used. (Although I don't think its interface is documented anyway)
* No built-in way to hook UNIX signals
* While the documentation itself is pretty good, it's presentation is lacking and it's difficult to quickly correct mistakes as you run into them
* It can be difficult to reason about when a shared binary will be garbage collected
* OS packaging (I'm thinking of Debian/Ubuntu) of Erlang and Erlang apps tends to be more harmful than helpful (old packages, namespace conflicts, etc)
To them I'd add:
* No agreed upon build tool (rebar while prevalent isn't universally accepted)
* Community libraries often have no support for upgrades or aren't packaged properly for releases
* Can't upgrade SSL if you're using it as a carrier
* No standard code format tool like gofmt (yes I know about erl_tidy, no it doesn't provide the same functionality as gofmt or it'd see similar use)
* Not enough infrastructure around built around edoc; where's the godoc or godoc.org work-a-likes? (yes I know about erldocs.com, it's no godoc.org)
I've seen this explanation in a few places and while I don't discount it entirely, I find it difficult to believe it's the sole factor at play; primarily because of the dearth of other third-party accessible services that build on AppleID (CalDAV and IMAP/SMTP are the only ones that come to mind).
Microsoft's DNS server was forked from BIND 4, Merchant Server was an acqusition that run on Python in it's first incarnation and as dalke mentions various networking infrastructure came from the BSDs.
The Wikipedia article on Microsoft's DNS server states that bind 4 was not used, and that the Microsoft's DNS server was fully written by Microsoft. Sadly, it doesn't have a source, so it kind of leaves the question open.
That sort of glitch sounds like the kind of thing Dropbox does (did?) from time to time because it's not aware of bundles. (For those unaware, on OS X many files are actually folders, eg: http://en.wikipedia.org/wiki/Rich_Text_Format_Directory)
I (a go noob) somehow got the impression that you're supposed to version your API when writing go libraries. ie, your library should be github.com/501/foo/v1 rather than github.com/501/foo. Can any go users comment on whether that's expected practice?
You can if you want, and some folk do, but that's really outside the scope of the language itself and much more about your project management, revision control, and so on.
The easiest way is just to keep your master always in a stable, clean state. Tools like git flow help with that.
Besides that, people who criticize go get's behaviour of checking out the latest revision resp. the go1 or go1.1 tag (if available) seem to forget that you're always free to populate your $GOPATH the way you like. You don't need go get for that.
I suspect you got this erroneous impression due branches based on the version of Go they are compatible with.
Many projects maintain branches named for the Go version they are compatibile with, and the 'go get' tool automatically fetches the appropriate branch.
Collating all the tradeoffs and bugbears would benefit both the existing community and newcomers. Things that bug me that immediately come to mind:
* No public bug tracker
* epmd's security (or lack thereof)
* Can't insist that epmd be started separately (`erl -no_epmd` won't start epmd but it also won't start epmd's gen_server)
* Can't swap out epmd because while `erl -epmd_module foo` is there, `net_kernel:epmd_module()` is barely used. (Although I don't think it's interface is documented anyway)
* No built-in way to hook UNIX signals
* While the documentation itself is pretty good, it's presentation is lacking and it's difficult to quickly correct mistakes as you run into them
* It can be difficult to reason about when a shared binary will be garbage collected
* OS packaging (I'm thinking of Debian/Ubuntu) of Erlang and Erlang apps tends to be more harmful than helpful (old packages, namespace conflicts, etc)
* No public bug tracker
* epmd's security (or lack thereof)
* Can't insist that epmd be started separately (`erl -no_epmd` won't start epmd but it also won't start epmd's gen_server)
* Can't swap out epmd because while `erl -epmd_module foo` is there, `net_kernel:epmd_module()` is barely used. (Although I don't think its interface is documented anyway)
* No built-in way to hook UNIX signals
* While the documentation itself is pretty good, it's presentation is lacking and it's difficult to quickly correct mistakes as you run into them
* It can be difficult to reason about when a shared binary will be garbage collected
* OS packaging (I'm thinking of Debian/Ubuntu) of Erlang and Erlang apps tends to be more harmful than helpful (old packages, namespace conflicts, etc)
To them I'd add:
* No agreed upon build tool (rebar while prevalent isn't universally accepted)
* Community libraries often have no support for upgrades or aren't packaged properly for releases
* Can't upgrade SSL if you're using it as a carrier
* No standard code format tool like gofmt (yes I know about erl_tidy, no it doesn't provide the same functionality as gofmt or it'd see similar use)
* Not enough infrastructure around built around edoc; where's the godoc or godoc.org work-a-likes? (yes I know about erldocs.com, it's no godoc.org)
[1] https://news.ycombinator.com/item?id=5801706