Comment by mediocregopher | Hacker News Reader

Comment by mediocregopher | Hacker News Reader

I have used erlang in a number of large projects over the last couple years and for the most part I'm in agreement with the author about both the benefits and drawbacks of erlang (when people ask me about erlang I always say "erlang is great for anything that requires a lot of moving pieces and doesn't require the code to actually look nice or be readable"). I have a couple of other drawbacks I think should probably get mentioned:

Logging is..... strange. The recommendation is to use SASL, which writes your logs in a binary format that only another erlang library can properly read. SASL has some nice features, like auto-rotation and such, but I'd much rather have my logs get spit out in plaintext and just logrotate like I do with everything else. One of these days I'm going to write a proper erlang logger.

Rebar is strange. It's erlang's deployment tool thing, kind of like leinengen but much less intuitive. I tried getting used to it but found it just made testing more difficult and made setup a chore. I opted instead to just steal the makefiles from the mochiweb project and call it a day.

Records have easily the most annoying syntax of any language construct I've ever used. And god forbid you want nested records, have fun with your full solid line of selection syntax. Bleh.

Which isn't to say it's all bad, here's some other awesome things about erlang that I don't see pointed out often:

Polymorphic anonymous functions

The pattern matching is amazing. When I go back to other languages that claim to support pattern matching it feels like I've lost both your feet and replaced them with suction cups. There's no pattern matching like erlang pattern matching.

Hot-swapping of code. Somewhat unintuitive, and has weird behavior in certain cases, but still definitely better then restarting the server that thousands of clients have long-running connections on

Records. Their syntax is horrible, but their usefulness is infinite. They're basically just syntactic sugar on top of tuples that make them easier to manage and extend.

There's more for both sides, but I'll leave it at that. It's a great language, I highly recommend everyone take a stab at it. Even if you hate the syntax it's good exposure to thinking about how to code concurrently.

There is one massive thing that I picked up from using Erlang that you failed to mention and I think should be pointed out. I have applied it in various ways outside of Erlang with a large amount of success (and the habit has caused no end to frustrations when dealing with external libraries, particularly on the JVM). If there is an error of some sort, but it can be recovered from, is a potentially anticipated scenario, etc. and can be handled at the point of occurrence, handle it. If it can't be handled, return a response indicating an error. If it is an exceptional condition, blow up and let the next level higher deal with it if it can, and so on. You can enumerate any number of ways that something can fail, but you will never catch all of them. However, exceptions are not an error communication device, they represent a condition that cannot be handled where they occurred.

It didn't really sink in fully for me until I had to write my first full non-trivial Erlang application from start to finish. However, once it clicked, every piece of code I wrote was significantly more predictable, easy to reason about and had significantly less bugs.

If you want to see pattern-matching taken to its logical extreme, check out bondi[1]. This is a rather researchy language based entirely around pattern matching; the core idea is to use pattern matching as "a new foundation for computation".

[1]: http://bondi.it.uts.edu.au/

Patterns are extended in several important ways. In total, this lets patterns be extremely generic; you can write code that is polymorphic over virtually any data you care to throw at it.

The language is heavily influenced by OCaml and supports both functional and OO-style code. It has static typing, which I think is very nice.

As a disclaimer, I've never used the language itself. I did read a book[2] about its design and played around with some variations on the lambda calculus leading up to the language itself. I also completely skipped over the OO sections of the book because I am a little tired of OO these days :P.

[2]: http://www.springer.com/computer/theoretical+computer+scienc...

This is probably the second or third time I have come across this language in an HN comment. Every time I see it, I click the link, and try to click the links on bondi.it.uts.edu.au, only to get 403 FORBIDDEN responses from any link whose path starts with `~/cbj/`.

> erlang is great for anything that requires a lot of moving pieces and doesn't require the code to actually look nice or be readable"

Sorry, but this is such a BS claim. Yes, there are bits of Erlang syntax which are ugly. Yes, you can write absolutely unreadable Erlang code, just like in any other language. But the whole point is that Erlang is extremely expressive for the problems in question - distribution and fault tolerance. It allows you to write code which is multitudes shorter than in (almost) any other language. Your code ends up being very succinct which is a huge benefit because of clarity/maintenance/etc.

For some extremely elegant code go look around at basho[1] and 99s[2] code. In particular, riak_core and cowboy. These are works of art!

[1]: https://github.com/basho [2]: https://github.com/extend

> It allows you to write code which is multitudes shorter than in (almost) any other language.

It's not clear if you're making that claim only for 'distribution and fault tolerance'. In that case, I don't know enough to say. For pretty much anything else, I'm sure that Erlang is much more verbose than Ruby.

What makes you sure of that?

Having read a lot of Erlang and a lot of Ruby code.

Here are actual numbers:

http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

Downvoting, by the way, won't change the numbers or the relative verbosity of Erlang, even if it makes you feel better.

The "actual numbers" are numbers for a lot of numerical code like computing pi digits, spectral norms, n-body simulation. That fact that you show those representative as typical Erlang programs shows that you don't know what typical Erlang programs are used for or just trolling. (And either one of those could result in downvoting).

I know what Erlang is used for (my name appears in the acknowledgements here: http://www.amazon.com/dp/B002L4EXHY/?tag=dedasys-20#reader_B... as a reviewer ), and the language shootout is a convenient benchmark site, nothing more. I never claimed it was anything else, did I?

Ruby isn't exactly a whiz in the number crunching department either: it's significantly slower than Erlang and certainly not 'meant for that', and yet, its code is more concise.

If you are saying Erlang is only concise for problems that it was meant for (and excels at), fair enough.

I'd also say that my preference is for languages that do lots of things pretty well rather than one thing really well and other things not so great. It's frustrating in some ways, because for some things Erlang is absolutely brilliant.

I didn't downvote you, I asked you a question. I have an opinion on the relative verbosity of Erlang, and was interested in hearing an explanation of yours.

But thanks for projecting your insecurities on me.

You can't downvote the people responding to your comments, so it's obvious it was not you. The comment was directed at whoever.

Yes, I am only claiming that it results in shorter code for the code which deals with problems in that specific domain. In general -- obviously not! But the overall gain is still significant. I don't care if e.g. some library dealing with some specific type of string manipulation is longer in Erlang than in other languages. This is a completely isolated modular component of the whole system. It does not prevent me from understanding the important bits. I do care if the core components are bloated, but are only describing some very simple behaviour.

Depends a lot on what you are trying to write, how much fault handling code you need and the size of your program. Programming languages which are "verbose" for small programs may not necessarily be it for large complex bodies of code.

In my experience it also tend towards what you are trying to do.

> For some extremely elegant code go look around at basho[1] and 99s[2] code. In particular, riak_core and cowboy. These are works of art!

We're hiring [1]!

[1]: http://bashojobs.theresumator.com/

I second the love for code hot-swapping. That's a beautiful part of the soft-realtime OTP environment that I miss a lot. Lager also helps to mitigate the logging pain a bit.

I constantly missed Haskell's pattern matching whenever I used Erlang's. Same idea, but H-M typing and laziness make me feel less like every pattern match is a bomb that triggers on every refactoring.

Edit: Oh! And how can I forget the joy that is Erlang's binary type DSL! That thing should be everywhere regexes are.

> And how can I forget the joy that is Erlang's binary type DSL!

They're definitely awesome. Many people are weirded out when I note that bit-munging in C looks like dog vomit, and so do the Perl-inspired pack and unpack (imported by Ruby and Python)

>There's no pattern matching like erlang pattern matching

Really? I'd imagine Haskell's is even better being lazy.

Not to mention the sort of things Prolog is capable of.

Thinking about making a game recently, current choice for backend will probably end up being Clojure or Erlang.

Erlang does have binary patterns on the both of those. Of course you could put something together (I'd especially be curious to see what you could come up with in Prolog) but the go-to solutions in Haskell are binary and cereal, which lack the terse clarity. Beyond that I'd say they're pretty par, maybe a slight advantage to Haskell for the under-utilized view patterns extension.

I liked Erlang's binary patterns so much I copied them for OCaml:

https://code.google.com/p/bitstring/

Would say that Lager is the preferred approach to Erlang logging at the moment: https://github.com/basho/lager

I'll also recommend you check out Elixir (http://elixir-lang.org/).

We have mix (http://elixir-lang.org/getting_started/mix.html) that is very much inspired by leiningen.

If you like records, we have dynamic records with pattern matching and now exrecord (https://github.com/yrashk/exrecord) for record upgrades.

You can perhaps check out https://github.com/basho/lager when it comes to logging.

Reply on news.ycombinator.com