[erlang-questions] erlang sucks
Tue Mar 11 09:43:30 CET 2008
2008/3/10, Mats Cronqvist <mats.cronqvist@REDACTED>:
> Damien Katz ( of couchDB fame) has written a blog post about the warts
> of erlang.
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
- 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?
More information about the erlang-questions