
What Sucks About Erlang (2008) - jxub
http://damienkatz.net/2008/03/what_sucks_abou.html
======
losvedir
I think it says something that erlang is still relatively successful and
popular _despite_ all that. In particular, it means it just _nailed_ its
semantic fundamentals: message-passing, functional, actor-based concurrency
with supervision trees and all the OTP goodies.

I think it's no wonder that Elixir is having the success it is. It fixes
literally every single issue on this page (many of which still exist in
erlang), _plus_ you get all the good stuff.

~~~
latch
We've been using Elixir almost exclusively for a couple years, and I can't
speak highly enough about it. There are clearly problems where beam is ill-
suited, but otherwise, I almost feel religious about it.

I've worked for many years with many other languages and runtimes, but beam,
OTP and Elixir (and the synergy between them) are better tools. As a
foundation, message passing and isolation are the only realistic weapons I've
seen against most common causes of technical debt (coupling). It isn't a
silver bullet, but it tries hard to help you. And, importantly, it's
approachable.

Another way to look at it is that it delivers many of the same benefits of
SOA/microservices, without the significant infrastructure/deploy/devops
overhead.

~~~
__sr__
Is Elixir being used extensively outside Silicon Valley? Can you list some
well known success stories? Looking at job listings and open source projects,
it doesn’t seem to be widely used. In fact, I don’t know anyone outside
Silican Valley who has built anything non-trivial in Elixir.

I am not saying it is bad. But I’d like to know about it before I dive in.

~~~
lostcolony
Not publicly documented, but CNN's ingest scheduling system (basically the
backend that says "at this time, record this incoming feed, on this encoder,
associate it with this metadata", and all the ensuing complexity that comes
with finding a free encoder, responding in the event of hardware failure,
allowing users to plan recordings that there isn't space for, etc) is in
Erlang. Because it needed to be bullet proof; if it goes down, CNN doesn't
record incoming video.

Had Elixir been mature at the time, we would have used it instead.

~~~
forgottenpass
That's interesting. Do you guys have to build a lot of custom tooling in TV?
Are CNN's requirements particularly novel compared to other stations with live
programming and remote feeds?

~~~
lostcolony
I've since left, but yes and no. Video at that scale requires some unique
hardware, which in turn requires some unique software. But for broadcasters of
that scale, many of the problems are the same.

We actually had, prior to this system, been relying on one built by a French
company, that cost hundreds of thousands, possibly millions, per year in
licensing. Updates were infrequent, often included regressions, but it mostly
worked.

This started as a way to get some of the smaller bureaus to have some basic
functionality, and grew into a system that was deployed to every bureau,
eventually replacing what we had in Atlanta (that previously mentioned
system). It was extremely popular, and the business stakeholders even
characterized it as the biggest success they've had from our department.

One of our group's VPs showed it at an industry trade show, just offhandedly,
and an exec from another broadcaster indicated regret of having just signed a
deal to purchase the aforementioned system above, rather than attempting to
roll their own (seeing the success CNN had).

It's not a key differentiator for CNN, but they also don't have software sales
as a core competency. So they have basically best of breed software sitting
there unnoticed. _shrug_ C'est la vie.

It also has the benefit of, since it's Erlang, largely just working without
issue. There's not many there still with Erlang knowledge, but that isn't
really much issue for another 20 years if it continues just working without
issue.

------
HumanDrivenDev
Programming discussions would be much better if everyone could be this
critical of their favourite programming languages.

There are languages everyone is happy for you to criticize online. Then there
are a small few that cause people to lose their shit when you offer a
critique. It's really sad - you really shouldn't be so personally invested in
a tool you didn't write.

~~~
6nf
'You can divide programming languages into two groups - those that people
complain about, and those that nobody uses'

~~~
HumanDrivenDev
C# is widely used, but it's a bit of a sacred cow.

~~~
moomin
C#’s a weird one: it’s widely used, but still unpopular. It’s got genuinely
large problems (like the anemic OS ecosystem) but when considered as a
language on its own, it’s been ahead of the game in its class.

~~~
GordonS
It may be unpopular with the HN crowd, but that's more by proxy, in so far as
a Microsoft stack in general is unpopular here.

C# is however _very_ popular in the enterprise world. I've been using it for
work and side projects alike for many years, and personally I love it.

~~~
Const-me
Not just enterprise.

Mainstream uses for .NET are windows desktop software (WPF & XAML are the best
GUI toolkits for the platform), videogames (Unity3D is quite popular), cross
platform mobile development (Xamarin).

Now when .NET Core supports ARM Linux, it also works well for some embedded
applications, but I don’t know whether somewhere except me does that.

------
ams6110
Erlang's statement separators seem to me more like English. I don't hear a lot
of complaints about commas, semicolons, and periods in English and I don't
find it an issue in Erlang.

~~~
segmondy
I was going to rage on the author, but I'll just let it go.

"," means AND.

";" means OR.

"." ends the rules.

In Algol based languages ";" ends each statement. To apply OR or AND
conditions between statements, you then need to use if/then/switch conditions.

~~~
tom_mellior
This could still be simpler without losing anything: It's kind of redundant to
use ";" at the end of rules that are followed by another rule for the same
function. Erlang could just use "." here as well. The parser could still tell
that another rule for the same function follows by seeing if another rule for
the same function follows ;-)

(Prolog, which influenced this part of Erlang syntax an many others, does it
this simpler way. It still sucks if you want to comment out the last line of a
clause, or switch the last line of a clause with some other line.)

~~~
triska
In Prolog, there is a neat technique that lets you "comment out" any goal of a
clause, including the last one, in a completely uniform way.

The trick is to define * as a prefix operator, and then define the predicate (
* )/1 to _generalize away_ its argument. You only need two lines to do it:

    
    
        :- op(920,fy, *).
        *_.
    

Now, you can put * in front of any goal to "remove" it. For example:

    
    
        pred :-
             true,
             * false.
    

With this definition, ?- pred. succeeds.

In Erlang, you cannot easily replicate this. You can try _parse
transformations_ to rewrite code at compilation time:

[http://erlang.org/doc/man/compile.html](http://erlang.org/doc/man/compile.html)

In Elixir, defining otherwise unused operators is generally discouraged:

[https://hexdocs.pm/elixir/master/operators.html](https://hexdocs.pm/elixir/master/operators.html)

For exchanging lines, an editor macro may be useful for Erlang and also for
Prolog.

------
odammit
I disagreed up until the docs section.

I like all the other things he critiqued!!1!

Rearranging: the punctuation helps you think about how you’re rearranging. You
can’t copy/paste around in any function and expect it it work!

The records comparison to a struct is unfair. He could have patterned matched
on the record instead of destructuring and accessed the attributes of the
record.

Immutability! Fuck yeah! I tend to name subsequent variables with the mutation
that was applied to them. It’s wordy.

Name = “wayne”

NameCapitalized = ...

Now get off my lawn!

------
facetube
CouchDB. It's rare that a piece of software is bad enough to give its language
and runtime a bad name, but it's actually that bad.

~~~
lallysingh
I've tried to use it. I hadn't realized it was erlang based, but now I respect
erlang less

~~~
brightball
I haven’t used it personally, but I looked at it enough to know that its goals
are different from most DBs.

Isn’t it supposed to be mainly REST based and have a goal of being able to
sync multiple nodes with expected connection loss in between?

I’ve never needed that on a project but it seems like it would work for some
use cases. I hear good things about PouchDB.

~~~
HumanDrivenDev
I don't quite get pouchdb. Do you need to store multiple revisions of the same
document in a browser database? Locks/transactions seem like a better approach
here for writing to data client side.

~~~
brightball
The main point is to sync server side data to a client side database,
smoothly, so that the application can continue to function offline and then
resync once the connection is re-established.

Couch has always been good at this use case where systems on both ends may
have changed in the disconnect time.

~~~
jinjin2
Realm looks like a much more modern solution to that problem.

~~~
brightball
Not familiar with Realm

------
plainOldText
I turned to Erlang a few years ago as I wanted to experiment with more exotic
languages. Then I discovered Elixir and never looked back. It’s a truly
enjoyable, expressive and productive language. I highly recommend it.

------
dixel
> Instead you are forced to do something like this:
    
    
      if
        Logging ->
        log("Something happened");
        true -> ok
      end
    

For this particular use-case there is much more elegant way in Erlang:

    
    
      Logging andalso log("Something happened");
    

Even though I agree that the syntax and the concepts are unfamiliar for the
general audience, I mainly see those arguments as the main reason to learn the
language rather than put it away since it's sometimes the only way to learn
something new. Regarding the "alien" syntax and expressing my point of view, I
think Erlang syntax is usable, very simple and sometimes prevents you from
doing "too fancy" things. Erlang's main areas are fault tolerant, high
throughput applications and network protocols. Once it's declared as the focus
- I wouldn't punch the ecosystem too much for the syntax but rather just use
another tool for solving the problems that require more expressive programming
languages. On the critics of the areas of focus I'd recommend the work done by
Fred Herbert, the author of Learn you some Erlang for Great Good
([http://learnyousomeerlang.com/](http://learnyousomeerlang.com/)). There is a
book on pitfalls while maintaining Erlang platform at large scale:
[http://www.erlang-in-anger.com/](http://www.erlang-in-anger.com/)

~~~
jlouis
Another good trick is to never log:

    
    
        report(Msg) -> hopefully_traced.
    

You can then add a trace probe to your report/1 function and this allows you
to have debug information when you need it.

------
phoe-krk

        f(X) ->
          X1 = foo(X),
          X2 = bar(X1),
          baz(X2).
    

If I use the pointless variable names like that, sure, I run into trouble, but
this means I'm a shitty programmer who cares little about program readability.

    
    
        f(X) ->
          fooedX = foo(X),
          baredX = bar(fooedX),
          baz(baredX).
    
        f(X) ->
          fooedX = foo(X),
          fabedX = fab(fooedX),
          baredX = bar(fabedX),
          baz(baredX).
    

Or just

    
    
        f(X) ->
          baz(bar(fab(foo(x)))).

~~~
cygned
I am not an Erlang programmer, but that style of programming bothered me, too.
This _variable per function application_ is a code smell in my point of view
and should be handled with function composition or partial application (not
sure how Erlang handles these, though).

~~~
jxub
Elixir has pipes for this, effectively solving this painpoint.

------
tilt_error
You have Erlang the programming language, Erlang the system (OTP, philosophy),
and even Erlang the eco system (including Elixir).

Personally I like Erlang the language, but it is still Erlang the system that
truly shines.

It says a lot of Erlang the system that we’re fondly criticizing the language,
warts and all. Erlang is all about pragmatism and we hand it over to the
academy (the Swedish one, notch, notch, know what I mean?) to dwell on the
Important Details about ‘.’, ‘,’ and ’;’ ;)

------
rdtsc
It's a 10 year old blog post from the creator of CouchDB who then later
declared the project dead despite it already having a vibrant open source
community with multiple users and contributors. Then went on to create another
project that had a similar name but was a merge of a bunch of other
technologies which lead to endless confusion years on after the fact.

[http://damienkatz.net/2012/01/the_future_of_couchdb.html](http://damienkatz.net/2012/01/the_future_of_couchdb.html)

Yes, of course the argument should stand on its own despite the author's other
claims or blog posts, so let's review some claims:

> Because Prolog sucks ass for building entire applications.

There have been entire applications written in Prolog. Attacking syntax is is
just silly. Had Prolog used statements and not expressions or ; instead of . I
doubt we'd would have a seen a lot more or less applications in Prolog.

> But that hasn't deterred Erlang from stealing it's dynamite syntax.

The syntax is consistent. That's the point. It has relatively few syntax and
semantic rules. It has strong types and behaves consistently, comparing say,
with "this" in Javascript. js has semicolons but it behave inconsistently
sometimes. You'd have to explain why {} + [] = 0 for example. Picking on js
here since the author used js as an example of a "good" language.

> editing code is much harder than conventional languages.

Have not found this to be true. It is a bit harder. But not much harder and
not a show stopper. You can't randomly copy and paste code and reorder
statements because compiler will not like it. That's probably a good thing.
Variables being immutable is helping when inserting a new function call in the
middle, you have to think well if that modified value is suitable for the
operations that follow below.

> If Expressions

There are 6 paragraphs talking about the "if" expression. "if" is not even
used that often and focusing on it just because it has the same name as the
"if" statement from Algol (C) type languages is a waste of time.

Use "case" instead or even better multiple function clause heads. Yes, you
can't do an early return so you have to explicitly handle every case. I see it
as a good thing. You can cheat and say "_ -> ...DefaultValue" but it will
stand and be obvious what's happening to the reader.

> You Say String of Characters, I Say List of Integers

Or list of unicode code points... You have a choice to use binaries instead of
lists of integers. They are closer to the traditional strings in other
languages. This is a better explanation of how they work:
[https://medium.com/@jlouis666/erlang-string-
handling-7588daa...](https://medium.com/@jlouis666/erlang-string-
handling-7588daad8f05)

> but it's surprisingly limited and verbose, requiring you to state the type
> of the record for each reference in the code.

Since the blog was written Erlang got maps other languages call them dicts or
hash tables for example.

All in all I'd say syntax is often what people talk about but it is closer to
bike shedding. It is easy to argue about because it's right there and everyone
can see a . instead of a ;. It would better to talk about the semantics of the
language, sending messages, concurrency, modeling applications as a set of
communicating processes, supervision trees etc.

~~~
tom_mellior
Minor points:

> Had Prolog used statements and not expressions or ; instead of .

Prolog uses "goals", which are a _lot_ more like statements than they are like
expressions. Also, Prolog doesn't use ; to separate the clauses ("rules") of a
predicate, it uses . to terminate each one.

But I agree that whether or not Prolog sucks for building entire applications
has nothing to do with these points.

------
moomin
Reminder that there exists a BEAM fork of PureScript.

[https://github.com/purerl/purescript](https://github.com/purerl/purescript)

------
pulsarpietro
Is it right to say that Erlang and Prolog are actually that close as stated at
the beginning of the article ?

As far as I am aware Erlang does not run the unification algorithm and it is
very different, you can, for instance, assign variables.

I don't think it is right to compare the two as close languages as it is
claimed but I would be interested in your opinion

~~~
Tomte
It's true that Erlang is not a logic-based language like Prolog, but the first
implementation of Erlang was written in Prolog.

~~~
pulsarpietro
what is it written in now ?

~~~
Tomte
In C.

------
hoodoof
I seem to recall the author of the old post ditched Erlang at some later
point.

------
kuon
That is why I love elixir, the power of erlang with a better syntax. Of course
elixir is not perfect, but it is really good at making erlang better.

~~~
segmondy
Elixir doesn't have a better syntax than Erlang, it has a syntax that you can
relate to and a syntax that makes sense to you. The first time I encountered
Erlang I said Meh! After doing serious development in Prolog for a year,
Erlang clicked! The first version of Erlang was implemented in Prolog and
retained Prolog's syntax. There's reason behind the madness. As I mentioned in
my other comment, "," and ";" signify OR and AND. One of the great thing about
OR and AND is that they can be greatly parallelized. We haven't seen the last
of Prolog & Erlang. With multicores being a thing, the language of the future
is going to look more like them. The last serious research I saw done on these
where in the 90's. So that annoying syntax is going to allow programs to gain
performance advantage with more cores without being rewritten. The only thing
that needs to change will be the run time. BEAM for Erlang and WAM for prolog.

~~~
kuon
I should have been more precise. I'd say elixir makes erlang more accessible
and easier to work with, not "better" as they are two different beasts with
two different focus.

