I used to all kinds of syntax or absence of it, like in Lisp or Forth. So I have no problem with Erlang syntax itself, but with its verbosity and inconsistency.
1. Versbosity
Sorted by code verbosity level, Erlang is somewhere in between Java/C++/C# (more verbose) and Ruby/Python (less verbose). But closer to dynamic languages, since you don't need to specify the types.
OTP code is significantly more verbose than plain Erlang and adds some boilerplate code (which can be generated for you by tools, like emacs or rebar, but you still need to read it and maintain it).
When you adding dialyzer specs, code become even more verbose. Since you need to duplicate function and argument names in the specs. Even worse - you need to duplicate dialyzer specs in edoc specs, since edoc uses it's own specs.
You can write your own macros and parse-transforms to reduce verbosity, but they aren't 1st class citizens and will not work from shell.
Given said all that, you still can expect up to 1:10 SLOCs reduction, comparing to C++ or Java, for large real life distributed applications.
Heh, not so fast, that's not first class access. Python has this problem as well, in order to have a uniform higher-order accessor to Objects, Lists, and Dicts, etc. you need to hack together some ugly functions. It's also why OpenStruct exists in Ruby. Same problems in JavaScript. Et al.
Not to be a ML/Haskell weenie, but dynamic languages aren't the only ones that don't require writing out every single damn type. We've had type inference since 1982, thanks to Hindley and Milner, and you get free compiler-enforced testing that your function arguments are of the proper polymorphic type.
How are you getting 1:10 LOC ratio over C++? My Python code would be at most 3 times more dense than C++. C++ has some very expressive high level constructs (template tricks mostly), please do not put it into the same bin with Java. And even Java gets less verbose with annotations.
I am not too familiar with Erlang, but I am very familiar with Python and C++. And you put Erlang between Python and C++ by verbosity, so I made my conclusions accordingly.
Also, synchronization and locking (with mutexes) are not the only approach to parallelization in C++. You can immutable objects, futures and other high level concepts. But Erlang has to be really nice for the stuff it was designed for, I have no doubts about that.
1. Versbosity
Sorted by code verbosity level, Erlang is somewhere in between Java/C++/C# (more verbose) and Ruby/Python (less verbose). But closer to dynamic languages, since you don't need to specify the types.
OTP code is significantly more verbose than plain Erlang and adds some boilerplate code (which can be generated for you by tools, like emacs or rebar, but you still need to read it and maintain it).
When you adding dialyzer specs, code become even more verbose. Since you need to duplicate function and argument names in the specs. Even worse - you need to duplicate dialyzer specs in edoc specs, since edoc uses it's own specs.
You can write your own macros and parse-transforms to reduce verbosity, but they aren't 1st class citizens and will not work from shell.
Given said all that, you still can expect up to 1:10 SLOCs reduction, comparing to C++ or Java, for large real life distributed applications.
2. Inconsistency
Example of inconsistency:
All this can be written in modern languages as: