6 ms·

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 d

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.

codewright 14y ago
>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.
- fusiongyro 14y ago
  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.
  - rwmj 14y ago
    I liked Erlang's binary patterns so much I copied them for OCaml: https://code.google.com/p/bitstring/ https://code.google.com/p/bitstring/
tel 14y ago
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.
- masklinn 14y ago
  > 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)
tikhonj 14y ago
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/ 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+science/book/978-3-540-89184-0 http://www.springer.com/computer/theoretical+computer+scienc...
- paul-woolcock 14y ago
  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/`.
devinus 14y ago
I'll also recommend you check out Elixir (http://elixir-lang.org/ http://elixir-lang.org/). We have mix (http://elixir-lang.org/getting_started/mix.html 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 https://github.com/yrashk/exrecord) for record upgrades.
ismarc 14y ago
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.
hjalle 14y ago
You can perhaps check out https://github.com/basho/lager https://github.com/basho/lager when it comes to logging.
timClicks 14y ago
Would say that Lager is the preferred approach to Erlang logging at the moment: https://github.com/basho/lager https://github.com/basho/lager
yfyf 14y ago
> 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 https://github.com/basho [2]: https://github.com/extend https://github.com/extend
- davidw 14y ago
  > 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.
  - pessimizer 14y ago
    What makes you sure of that?
    - davidw 14y ago
      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&lang=hipe&lang2=yarv 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.
      - rdtsc 14y ago
        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).

codewright 14y ago

>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.

fusiongyro 14y ago
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.
- rwmj 14y ago
  I liked Erlang's binary patterns so much I copied them for OCaml: https://code.google.com/p/bitstring/ https://code.google.com/p/bitstring/

tel 14y ago

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.

masklinn 14y ago
> 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)

tikhonj 14y ago

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/ 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+science/book/978-3-540-89184-0 http://www.springer.com/computer/theoretical+computer+scienc...

paul-woolcock 14y ago
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/`.

devinus 14y ago

I'll also recommend you check out Elixir (http://elixir-lang.org/ http://elixir-lang.org/). We have mix (http://elixir-lang.org/getting_started/mix.html 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 https://github.com/yrashk/exrecord) for record upgrades.

ismarc 14y ago

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.

hjalle 14y ago

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

timClicks 14y ago

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

yfyf 14y ago

> 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 https://github.com/basho [2]: https://github.com/extend https://github.com/extend

davidw 14y ago
> 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.
- pessimizer 14y ago
  What makes you sure of that?
  - davidw 14y ago
    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&lang=hipe&lang2=yarv 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.
    - rdtsc 14y ago
      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).