> You can do reasonable metaprogramming in Erlang with the syntax_tools and stdlib interfaces.
You can also do concurrency in Ruby. It is not the same as doing concurrency in Erlang though. The same way doing metaprogramming with syntax tools, parse transforms and what not is nowhere close to a macro system.
> I've looked at OTP the Elixir way and I do not see any real boilerplate reduction.
So please look again? Take a look at Elixir's agents or tasks and explain how it doesn't lead to more readable and cleaner code than the GenServer equivalent in Erlang for the cases they fit. You could maybe point other criticism but saying "no real boilerplate reduction" just shows you didn't really try or care to give it a try.
> It is a jarring conceptual mismatch to put Smalltalk-ish Ruby syntax over a language that eschews excessive monkey patching and dynamism like Erlang.
This sentence is specially ironic given that Erlang inherits from Prolog, which is quite different semantically from Erlang, instead of using the more tradicional ML families. Also Erlang is pretty much a very dynamic language.
I am a Haskell developer, I hate Ruby syntax and I programmed Erlang for a year. I would still choose Elixir over Erlang any day mostly because of the tooling, typeclass like polymorphism and the new abstractions (Task and Agent).
The same way doing metaprogramming with syntax tools, parse transforms and what not is nowhere close to a macro system.
I'd wager that's because no one has written tooling to make it compelling to the common programmer. Same with release management for a long time, and hot code reloading. I'd understand if you said that basic substitution macros are nowhere close to actual AST macros, but Erlang has far more than that.
Take a look at Elixir's agents or tasks and explain how it doesn't lead to more readable and cleaner code than the GenServer equivalent in Erlang for the cases they fit.
Those are sugar. It's not like you can't define your own behaviors in Erlang. People do it all the time, there's so many good libraries that go beyond stock OTP. I should really switch an entire language because of default libraries?
This sentence is specially ironic given that Erlang inherits from Prolog, which is quite different semantically from Erlang
Only traces. The Prolog influence of Erlang is severely overrated by a lot of people these days.
Also Erlang is pretty much a very dynamic language.
It ain't no Smalltalk. The runtime is very dynamic, and the typing is loose, but the Erlang language itself not so much, which I think is a strength.
I am a Haskell developer, I hate Ruby syntax and I programmed Erlang for a year.
> I'd understand if you said that basic substitution macros are nowhere close to actual AST macros, but Erlang has far more than that.
Fair point.
> Those are sugar. It's not like you can't define your own behaviors in Erlang. People do it all the time, there's so many good libraries that go beyond stock OTP.
There is a very strong point in providing those as default. If Erlang didn't ship with a gen_server, we would see hundreds of different gen_server implementations and no real consensus. By providing one, all Elixir developers are familiar with it.
In a way, you could define everything Elixir provides as a sugar, after all, it runs in the same VM. Sure, an Erlang library could provide all unicode manipulation functions... but having it all sorted out for me is a great deal. The same way Erlang solves many other things which makes it attractive to many.
That leads me to...
> I should really switch an entire language because of default libraries?
No. But if it provides a really good standard library altogether (unicode, structs, enumerable, etc) with an excellent tooling and powerful abstractions (like protocols), then surely yes.
But if it provides a really good standard library altogether (unicode, structs, enumerable, etc) with an excellent tooling and powerful abstractions (like protocols), then surely yes.
I can't comment on excellent tooling. Language-specific package managers never tend to be excellent, which is why I appreciate the limited scope of a tool like rebar.
Again, you are overvaluing a language based on the libraries it exports, rather than on its true a priori merits. Some languages are designed for intense extensibility and expressiveness, like Forth. An argument based on laundry listing abstractions to dissuade someone from using it would be rightfully dismissed as nonsense, since it is their prerogative to define the threshold of abstraction they need.
Furthermore, I've noticed that people who tend to promote languages based on the mere reductionist listing of abstractions tend to not understand those abstractions well themselves, treating it as dark wizardry.
Erlang is definitely malleable to reasonable extensibility. See Erlando which adds Miranda/Haskell-like monadic patterns to Erlang.
Except I am not. What would be Erlang really without OTP? Would you really want to implement all the building blocks in every new project? You are dismissing the importance behind stdlib while defending a language that is known specially because of its standard library (Erlang/OTP).
Also rebar3 is pretty much the same in scope as Mix (elixir tool). Which proves the point you are criticizing Elixir while using the same criteria to praise Erlang.
I am not saying Elixir is better or worse, just pointing you are extremely biased in your comments.
You can also do concurrency in Ruby. It is not the same as doing concurrency in Erlang though. The same way doing metaprogramming with syntax tools, parse transforms and what not is nowhere close to a macro system.
> I've looked at OTP the Elixir way and I do not see any real boilerplate reduction.
So please look again? Take a look at Elixir's agents or tasks and explain how it doesn't lead to more readable and cleaner code than the GenServer equivalent in Erlang for the cases they fit. You could maybe point other criticism but saying "no real boilerplate reduction" just shows you didn't really try or care to give it a try.
> It is a jarring conceptual mismatch to put Smalltalk-ish Ruby syntax over a language that eschews excessive monkey patching and dynamism like Erlang.
This sentence is specially ironic given that Erlang inherits from Prolog, which is quite different semantically from Erlang, instead of using the more tradicional ML families. Also Erlang is pretty much a very dynamic language.
I am a Haskell developer, I hate Ruby syntax and I programmed Erlang for a year. I would still choose Elixir over Erlang any day mostly because of the tooling, typeclass like polymorphism and the new abstractions (Task and Agent).