While I do agree there should be less "activation energy" for the newbies to enter the Erlang community (https://www.youtube.com/watch?v=Djv4C9H9yz4), I don't think "identify ways to expand the scope of Erlang and Elixir to other potential use cases" is the way to go. Each language has its strength and weakness, being highly concurrent and fault-concurrent is the design goal of erlang/elixir, and erlang/elixir achieves that. Making them a general-purpose language seems a bad idea to me (think message-passing a large size of message in a non-concurrent situation where the shared-memory should be used. it just deteriorate the performance of the general-purpose program). Being able to built a great concurrent system is enough to make a language become popular in industry, the problem is really not about more use cases, but is how to make the barrier of entry lower. Also, it does matter to have a warming community, like most of Ruby communities I know.
The last thing Erlang needs is to be overrun by a million wanna-be hotshots/ninjas/cut-and-paste programmers. Erlang has a reputation and that reputation is in part because by the time people discover Erlang they actually need it.
The last thing Erlang needs is to be overrun by a million wanna-be hotshots/ninjas/cut-and-paste programmers.
If the message you're going for is "don't sacrifice the goals of the language to appeal to a broader audience," I agree. But I don't think there's much value to be found in that kind of elitist attitude. Python, ruby, JavaScript etc are powerful, fun, easy to learn, and useful, and their wide adoption has lead to them being higher-performance, having boatloads of useful libraries, and improved them as languages. A language is not hurt by more people using it, even if those people are "wanna-bes" (whatever that means).
Comments
While I do agree there should be less "activation energy" for the newbies to enter the Erlang community (https://www.youtube.com/watch?v=Djv4C9H9yz4), I don't think "identify ways to expand the scope of Erlang and Elixir to other potential use cases" is the way to go. Each language has its strength and weakness, being highly concurrent and fault-concurrent is the design goal of erlang/elixir, and erlang/elixir achieves that. Making them a general-purpose language seems a bad idea to me (think message-passing a large size of message in a non-concurrent situation where the shared-memory should be used. it just deteriorate the performance of the general-purpose program). Being able to built a great concurrent system is enough to make a language become popular in industry, the problem is really not about more use cases, but is how to make the barrier of entry lower. Also, it does matter to have a warming community, like most of Ruby communities I know.
The last thing Erlang needs is to be overrun by a million wanna-be hotshots/ninjas/cut-and-paste programmers. Erlang has a reputation and that reputation is in part because by the time people discover Erlang they actually need it.
If the message you're going for is "don't sacrifice the goals of the language to appeal to a broader audience," I agree. But I don't think there's much value to be found in that kind of elitist attitude. Python, ruby, JavaScript etc are powerful, fun, easy to learn, and useful, and their wide adoption has lead to them being higher-performance, having boatloads of useful libraries, and improved them as languages. A language is not hurt by more people using it, even if those people are "wanna-bes" (whatever that means).
"Languages have positive network externalities":
http://www.welton.it/articles/programming_language_economics