Is Erlang a concise language from a programmer's point of view?

Question

Where does Erlang fall into the spectrum of conciseness between, say, Java / .net at the less compressed end of the spectrum and Ruby / Python at the more compressed end of the spectrum? I have a problem with RSI, so brevity is especially important to me for health reasons.

Answer 1

Compatibility as a language function is poorly defined and probably not homogeneous. Different languages ​​may be more or less concise depending on the problem.

Erlang as a functional language can be very concise, outside of Ruby or Python. In particular, pattern matching often replaces if statements, recursion, and lists can replace loops.

For example, Java will have something like this:

String foobar(int number){ if (number == 0) { return "foo"; } else if (number == 1) { return "bar"; } throw new Exception(); } 

whereas Erlang code would look like this:

 foobar(0) -> "foo"; foobar(1) -> "bar". 

Except that it is inalienable because there is no suggestion to enter another, then 0 or 1. This creates a problem that is well suited for developing the Erlang style.

In general, everything that you could define as a transformation would go especially well with a functional language and could be written very briefly. Because of the many fanatics of functional languages, it is argued that any programming problem is a transformation.

Answer 2

Erlang allows you to implement functionality in very few lines of code compared to my experience in Java and Python. Only Smalltalk or Scheme came close to me in the past. You only have small overheads, but you tend to speak identifiers for modules, functions, variables and atoms. They make the code more readable. And you have a lot of normal, curly and square braces. So it depends on your keyboard layout, how convenient it is. You must try.

MUE

Answer 3

Erlang is surprisingly concise, especially if you want to achieve performance and reliability.

Erlang is laconic even in comparison with Haskell:

http://thinkerlang.com/2006/01/01/haskell-vs-erlang-reloaded.html

And surprisingly fast (and reliable) even when compared to C ++:

http://www.erlang.se/euc/06/proceedings/1600Nystrom.ppt

(18 times less SLOC is not surprising).

In any case, it always depends on your preferences and the goal that you want to achieve.

Answer 4

You have to spend some time writing code to understand the erlang sweet spot, as well as all other new tools, DHT, doc stores, mapreduce frameworks, hadoop, GPU, scala, ... If you try to make, say, applications like SIMD for outside of the sweet spot, you are likely to end up with a paradigm and writing detailed code, while if you run into problems requiring server and middleware scaling smoothly up and down, it flows naturally. (And the growth of scala in its sweet spot is inevitable, I think too)

A good thing to look for is Tim Bray's extensive search experiment (distilling large Apache log files) from a couple of years ago and how he was disappointed with erlang.

I usually do not recommend investing a lot of things in Alioth's shootout, given that you inevitably end up comparing really good and bad code, but if you need to put in the amount of LOC, erlang vs. C, ruby ​​then

http://shootout.alioth.debian.org/u32q/erlang.php