501

I've posted these before[1]:

* 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

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.

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)

There's nothing whiny about it. They're explaining to their customers what happened which is a part of their job.

I don't think it's anything out of the ordinary. Attacks happen quite regularly, most are mitigated quickly and quietly.

Actually I think I may have first picked it up from this vclock library: http://labix.org/vclock

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?

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)

That will produce a list of 2 funs. I think you meant:

    [ N + 1 || N <- [1,2] ].

XPC services implemented in golang would be very handy - here's hoping iOS 7 gains full XPC support.

This ticket might interest you: http://code.google.com/p/go/issues/detail?id=837

Maybe one day it'll come. If on that day iOS has gained a public XPC API I'll be quite the happy camper.