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