This was back in a brief period when Erlang was being hyped by people as a potential Next Big Thing. Unfortunately it never really got that much momentum though, until Elixir and Phoenix came along.
Now that I think of it, Canonical's push toward "snaps" (sandboxed and vendored—but not fully containerized—software bundles, as a package format) might bring a flourishing of Erlang-based application software, given that it's much more compatible with Erlang's style of release-management.
The release process I've used for Erlang before packaged things up into a folder with everything you needed to run.
edit: There's this (abandoned, for reference): http://www.oocities.org/erlang_journal/sae.html
I also played around with an idea of bunding the release into a self extracting bundled executable too https://gist.github.com/tsloughter/d62aad6d67b263e69275376b1...
I'm not a fan of Elixir's quasi-Ruby syntax — I think something closer to Go or Nim would have served it better — but it's certainly a step in the right direction.
The Erlang toolchain has a ton of ergonomic issues that could have been polished down a long time ago, but haven't been. Erlang simply feels oddly quirky and antiquated for anyone used to modern GNU tools or modern REPLs.
For example: Lack of Readline support (needs rlwrap to be usable, at least on Ubuntu), lack of GNU-style long options, the obnoxious ctrl-C behaviour that doesn't respect Unix conventions and gives you a prompt with confusing options (quick, what's the difference between "abort" and "kill"?) that seem aimed at developers and are completely wrong if you're just a user of an Erlang tool. (Couldn't they have relegated this to USR1 or something instead of INT, like a normal program?) On the server, the epmd process is a thorn in the side of any system administrator. Erlang devs also seem to think that emitting Erlang stack traces is a good replacement for proper English error messages, and if you're not an Erlang dev, you haven't seen stack traces until you've seen the kind of monstrous, obscure, deeply nested contextual dumps that Erlang programs can produce.
And so on. Little things, but important things that can completely kill the joy when you're a potential adopter.
Erlang shouldn't need Elixir to modernize, but there's probably very little incentive within the community to change quirks that they're all used to dealing with by now.
(I encountered similar issues with OCaml, which has many parallels to Erlang: Quirky, odd syntax, antiquated toolchain, etc. Facebook's cleanup effort [1] looks very promising.)
Part of this is that Erlang kind of wants to be its own little world - something that it shares to some degree with Lisp and Smalltalk (images!).
It doesn't just have its own syntax, it has its own idiosynchratic, somewhat alien way of doing almost everything that is already established on Unix. The difference feels almost as stark as Linux vs. Windows.
Honestly, I think that if Ericsson was just starting to build Erlang today, it'd look less like a self-contained emulator, and more like a virtual-machine image. (Or more than one: maybe an Erlang unikernel image ala Erlang-on-Xen, and then companion POSIX VMs to spawn ports on, making the Erlang cluster into its own Kubernetes-alike.)
EDIT: found the link http://erlang.org/pipermail/erlang-questions/2011-October/06...
But I think Erlang's use-case isn't really the type of software developers get excited about developing, either way. The type of software Erlang is "best at" (and where it would reduce codebase size the most) is exactly the type of big Enterprise-y bloatware-apps and business-process servers that make Java's market-share so large.
Because Enterprise software gets designed top-down, how excited developers are to be using the (dictated) language aren't very relevant. How easy the language is to learn is relevant; how many engineers you can either hire or train to code in the language is relevant. But whether they enjoy their day-to-day lives writing in the language isn't, really.
Thus, I think, why things like deployability are more important to Erlang: for the type of software projects Erlang would be good for, considerations like deployability (and maintainability, remote debugging, easy hot-patching, etc.) are what guide language choice. Erlang wins on most of those fronts (as it should: its OTP framework is effectively "30 years of ops best-practices constraining development"), but for various reasons, [non-embedded] deployment has always been a pain-point.
Sure, Erlang will never be able to compete with certain languages such as C and C++ for many use cases. But I often grab Go to create small command-line tools, or do some minor parallel data processing where a lighter language like Ruby will not do well. There's nothing in Erlang that conceptually prevents it from being a general-purpose language; it's just that its ergonomics don't really "scale down" to the stupid, simple stuff.
I remember, years ago, trying to write a basic parallel non-OTP log-processing pipeline for some log files, thinking Erlang would be ideal... and being surprised at the number of roadblocks I had to deal with. Around the same time, Tim Bray went through the same process, but spent a lot more effort on it than I [1].
[1] http://www.tbray.org/ongoing/When/200x/2007/09/22/Erlang
(Though, even in that setup, there's no way to get an effect equivalent to requiring un-bundled gems from your script in Ruby.)
For whatever reason they didn't do much in the way to create and maintain modern tooling to make on-boarding easier, which would have facilitated increased adoption, and lead to more revenue potential. Neither relx, nor rebar, nor erlang.mk, etc. were born out of said commercial entity, despite those kinds of things being perfect candidates for a services company to produce to make their own lives and the lives of potential new users easier.
There have been some huge high-profile Erlang use cases that would normally feed a Silicon Valley/Hacker News style hype-cycle, but somehow those came and went with almost nothing to show for it. It almost feels like if Elixir hadn't shown up on the scene to attract new users and splinter off a chunk of the massive Ruby community that the Erlang side of the world would all but dead already. Sometimes I wonder how it is one goes about blowing a 15+ year technology lead and 10 years of huge and publicly visible wins, but that's sorta what's happened.
In the curation of said community there's also been an overtone of nostalgia for "the good old days" & "yeah, that part is supposed to be painful", and a sort of long-running tone deafness around on-boarding, usability, general-developer-ecosystem-friendliness, etc. complaints that certainly could have had a lot more done to be ameliorated by the commercial entities who stood to gain the most by Erlang having broader adoption.
Frankly, much like Elixir breathing a bit of new life into aura around Erlang, if it weren't for people like Fred, Tristan, Alisdair, Garrett and a few others (who again aren't part of the core supports for Erlang commercially) being really passionate against all odds about making Erlang easier to use, and to explore new use cases, and to meticulously and engagingly document all of it... Erlang would probably be dead already.
All of which might be overly harsh, but I'm having a very acute existential crisis around Erlang at the moment. I love it. I love developing in it. I love introducing it to teams and projects. And as time goes on I feel rapidly and increasingly more guilty about that given the decline it seems to be in and has been in if I'm being honest with myself in retrospect.
Blargh :-(
edit: look at the increasingly dwindling sponsors list of Erlang Factory San Francisco over the last several years as an indicator of the above rant/cry-for-help.
That's what I mean by "deployability": the hell that is trying to convert your Erlang release into a distro package so that users can simply "apt-get install" it and have the distro maintain it for you; and so other software packages can declare package-level dependencies on it.
The reason that true static binaries ala Go would be better, is simply that it would stop the distro maintainers from messing with everything to quite the same degree. In such a setup, there wouldn't be a "system Erlang runtime", because Erlang would just be a baked-in part of /usr/bin/riak or /usr/bin/ejabberd. (Which wouldn't stop distros from making Erlang SDK packages for things like an Elixir package to depend on, but they wouldn't be involved at all in the dependency tree of the Erlang-release-derived packages on the system.)
Of course, when people install your software "manually", you can distribute it however you like—a zip of an Erlang release, like a Java JAR, is already quite a convenient format for such installations all on its own. But when people want to install something that depends on your software (like, say, OpenStack depends on RabbitMQ), they don't want to spend nearly as much time thinking about your package. They don't know you exist, and they don't want to know you exist—they want the distro to handle that detail for them. So you're stuck fighting the distro. (And things like OpenStack are stuck doing non-distro-packaged releases to avoid the problem.)
Which brings me back to my original point: "snaps" are promising not because they sandbox packages, but because they're a countervailing philosophical movement on how software should be packaged. A distro that supports snaps is a distro that has made room in its heart for packages that don't want to break things down into little FHS-arranged dep-graph-divided bits. It gives them an out, a place to put these packages rather than just denying them outright.
Programmers writing dynamic websites are likely to post questions on Stack Overflow. Questions on Stack Overflow create mindshare, mindshare attracts more serious programmers who can improve the ecosystem by writing generic network services. Language prospers, cycle repeats.
JavaScript is the most popular language on Stack Overflow and React is the fastest growing technology.
Without the dynamic website programmers the cycle short circuits and you end up with a terrible "new user experience" from lack of answered beginner questions and lack of interest building on the non-existent ecosystem.