[erlang-questions] erlang sucks

[Ulf Wiger]

2008/3/10, Mats Cronqvist <mats.cronqvist@REDACTED>:
>   Damien Katz ( of couchDB fame) has written a blog post about the warts
>  of erlang.
>  (http://damienkatz.net/2008/03/what_sucks_abou.html)

There are several threads in the article (and comments) perhaps worthy
of discussion here at EQ.

My general impression of the article is that while I agree that the
complaints are valid, the reader comes away from it with the distinct
impression that Damien Katz would be content if he never had to
touch Erlang again, despite the contention that he could fill a book
with the things he likes about it - much like everyone now "knows"
that Erlang sucks at file I/O, since it did in the original Wayfinder
experiments, and it was noted in a blog article.

So, I'm inclined to agree with Tobbe. Someone reading the article, who
might have been interested in checking out Erlang, might well be
persuaded not to do so. I don't think that was the author's intention.

Still, the blogosphere is free, thankfully, so - on to the complaints.

- I'd like to try (= see someone else implement) an indentation-sensitive
  front-end to the compiler, but perhaps ROK's suggestion that a full stop
  can be used in place of a semicolon would cause less uproar.

- With the bit syntax improvements in R12B, and EEP9, I think we're starting
  to come close to the foundations of an alternative string handling library.
  When we get there, we'll surely be able to see further.

- I don't agree that Erlang is bad for writing test suites. On the contrary,
  I think Erlang is, on the whole, just about the best test automation
  environment in existence, especially if you include QuickCheck.
  The problem with numbering variables is real, but can be addressed
  with a change of programming style (which is both a good thing and
  a very bad thing, depending on your POV). The advantage of immutable
  variables far outweighs this inconvenience, anyway, even though I
  guess that this particular issue is much less of a problem in currying
  languages.

- The gripe about records, well, is well-founded, but also ground well covered.
  Perhaps we should finally do something about it?

- I agree with Klacke on the out-of-memory issue. I once complained about it,
  but have long-since decided that exit(1) is most likely the best option in
  general. It is possible that one could allow for a callback, or specification,
  that could guide the VM in releasing memory, in the cases where this
  would be a reasonable thing to do. Perhaps before killing processes, one
  could have a go at removing memory fragmentation, which would appear
  as a very expensive GC. But Erlang does already have options for plugging
  in a more aggressive memory allocator, which works harder to avoid
  fragmentation in the first place. It also has quite a battery of features for
  implementing sophisticated load control, e.g. barring new jobs if there
  doesn't seem to be enough memory left.

- Regarding the uneven documentation, I'd like to point out that docbuilder
  allows people to write alternative documentation that has the same look
  and feel as the Erlang/OTP documentation. This is new as of OTP R12B.

- One comment dismissed Erlang as a specialized language.  I think this
  reflects the idea that concurrency is something that you only use when
  it's really needed, and something to avoid otherwise. I'd like to turn the
  tables and suggest that languages that are very good at sequential
  processing, but suck at concurrency, are the specialized ones. So many
  interesting applications require strong concurrency support, and as it
  turns out, message-passing lightweight concurrency is a modeling
  paradigm in its own right at least as powerful as OO. Perhaps we can
  improve at getting this message across?

BR,
Ulf W