While the syntax is quite different, I think people really underappreciate how simple the Erlang syntax is. It takes no more than a few hours to learn everything about Erlang’s syntax. It has so few things about it that even if they are someone odd, it’s still so much smaller than almost any other language I’ve used. I think people tend to get way too caught up on its oddness rather than this strength of simplicity.
I actually agree with you about stuff like that. Most programmers don’t, though. Being C-like helped C++ and Java win converts more easily. As in, you always get more adoption giving a crowd what they’re used to starting out.
The author explicitly mentions that as a negative given it’s a weird language hardly any mainstream coders would’ve messed with. Instantly creates an obstacle to adoption for the masses.
Elixir is an obvious alternative. However, maybe another option is a language close to Erlang that compiles to it or its bytecode that just fixes issues like this. Esp syntax.
My feeling is that Elixir is exactly this. While it brings a bit of runtime, you’re close enough to the Erlang VM to be able to do pretty much everything you can do in Erlang.
If you ignore the standard library etc. and just focus on the language, it does pretty much what you describe: Fix the shortcomings regarding pattern matching, variable naming, …
Runtime is likely the wrong word. I was getting at the small pieces of code they’re running in the Erlang VM (elixir_sup and its children). Of course, Elixir modules just boil down to normal Erlang modules.
While the syntax is quite different, I think people really underappreciate how simple the Erlang syntax is. It takes no more than a few hours to learn everything about Erlang’s syntax. It has so few things about it that even if they are someone odd, it’s still so much smaller than almost any other language I’ve used. I think people tend to get way too caught up on its oddness rather than this strength of simplicity.
I actually agree with you about stuff like that. Most programmers don’t, though. Being C-like helped C++ and Java win converts more easily. As in, you always get more adoption giving a crowd what they’re used to starting out.
Also, the syntax is really unsurprising if you’ve toyed with Prolog in the past.
The author explicitly mentions that as a negative given it’s a weird language hardly any mainstream coders would’ve messed with. Instantly creates an obstacle to adoption for the masses.
Yes, I played a bit with Erlang some time ago, and I was really surprised by how beautiful and simple it is.
For anyone thinking of trying out Erlang, this is how some of these shortcomings played out for me over the years.
In no particular order:
reassigned once ;A' gets augmented once becomingA1’ from time to timeThis is to say nothing of Erlang’s shortcomings, which from my vantage point, are not on this particular list.
Elixir is an obvious alternative. However, maybe another option is a language close to Erlang that compiles to it or its bytecode that just fixes issues like this. Esp syntax.
My feeling is that Elixir is exactly this. While it brings a bit of runtime, you’re close enough to the Erlang VM to be able to do pretty much everything you can do in Erlang.
If you ignore the standard library etc. and just focus on the language, it does pretty much what you describe: Fix the shortcomings regarding pattern matching, variable naming, …
I’m not aware of an Elixir runtime other than the Erlang VM. At runtime, Elixir code is just Erlang code.
Runtime is likely the wrong word. I was getting at the small pieces of code they’re running in the Erlang VM (
elixir_supand its children). Of course, Elixir modules just boil down to normal Erlang modules.