Erlang devs wish it was as popular as Javascript when it used XMLHttpRequest. It's less popular than Lua today, which has no package manager. That means somethi

Erlang devs wish it was as popular as Javascript when it used XMLHttpRequest. It's less popular than Lua today, which has no package manager. That means something is very wrong. > The main objection is familiarity: “It doesn’t look like Java!” I think the point is somewhat moot. It doesn't matter what the zealots think. It's not moot, because there are people born every day that will think it. This will be a response to the language, every day, until we're both long-dead. It matters enough that it drove people to dedicate time to develop entirely new syntax (eg elixir), as mentioned. Given the myriad of languages that use a functional style, Erlang is just not special, excepting the unique syntax which makes it unfamiliar and elixir that just makes a bit more user friendly. Maybe, just maybe, it is partly about the syntax. The Erlang tooling is primitive. I don't want to develop another toolchain and have to do with the gaps, thx. Yes it's a chicken-vs-egg thing, but without support for a new language, you wont see a lot of adoption. The semantics are less efficient. Now the context needs to be carried around or in another set of terms, or worse another event queue, or worse overloaded fns? When a for-loop has to be broken up into 2 fns, you've made things worse at the smallest scale. I then have to communicate the naming and choices to future developers? This makes debugging, design and code reviews harder/more divisive. I can read through a couple functions and understand what a c-like program does, even if it's in Python or PHP or Java or C (most of the time). Saying they are different in details, is missing the point. I don't have to know how data is split up because everything is either a structure or a scalar, serially processed and in static locations for reading...until you hit a DB. Hitting a single async store is complicated enough that it has caused developers headaches for decades. Introducing easy queues as a solution, is handing out footguns. The complexity introduced into event-driven applications, limits the practical complexity of application development in practice, by orders of magnitude (bottlenecks and race conditions). Sloppy programming is jr friendly. Raising the developer performance expectations higher, is worse for adoption. Perl died on this hill. Years after I last used Erlang to replace a Java chat client from 5000 lines to single page Erlang module, then got a job writing it (2009), I would not recommend it to anyone. I did try cracking open another person's project in 2012ish and that was not fun. At least we have Kafka.