4 ms·

I think that would help, but in my opinion, Erlang's syntax and overall projected surface has always been its biggest hurdle to wide adoption. You can have the

I think that would help, but in my opinion, Erlang's syntax and overall projected surface has always been its biggest hurdle to wide adoption. You can have the most amazing, powerful language ever, but it still won't receive popular adoption if you're too strange and you can only attract a certain type of highly-skilled senior devs. 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.) [1] https://facebook.github.io/reason/ https://facebook.github.io/reason/

davidw 10y ago
As a long-time Erlang user, I think the above is a lot closer to why people always seemed to have some trouble with it. Lots of little weird things. 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!).
- lobster_johnson 10y ago
  That's a great point — there's an impedance mismatch between Erlang and the rest of the world. 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.
- derefr 10y ago
  I think it's a mind-expanding experience to set up an Erlang release on an "immutable infrastructure" system like CoreOS, with the Erlang "ssh" application enabled (instead of using ERTS's remsh system), and then keep that system up for weeks/months by doing maintenance through said SSH REPL. It becomes very clear, when you do so, that Erlang really is its own little sandboxed OS, and that the "Erlang Runtime System" is really a kind of standalone virtualization system for running that OS on other OSes. 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.)
  - lliamander 10y ago
    I feel like Robert Virding once said that Erlang-as-OS was more or less one of their original plans (I wish I could remember the source, but it was during a discussion of the Erlang JCL mode in the REPL). EDIT: found the link http://erlang.org/pipermail/erlang-questions/2011-October/061447.html http://erlang.org/pipermail/erlang-questions/2011-October/06...
derefr 10y ago
Oh, sure, there are plenty of things getting in the way of developers being excited about using Erlang and thus deciding, in a bottom-up sense, to build more stuff in Erlang. 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.
- lobster_johnson 10y ago
  But did it have to become niche? I think Erlang could very well have branched out to become a more even general-purpose language, rather than doubling down on distributed computing to the exclusion of more quotidian tasks. 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 http://www.tbray.org/ongoing/When/200x/2007/09/22/Erlang
  - 10y ago

davidw 10y ago

As a long-time Erlang user, I think the above is a lot closer to why people always seemed to have some trouble with it. Lots of little weird things. 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!).

lobster_johnson 10y ago
That's a great point — there's an impedance mismatch between Erlang and the rest of the world. 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.
derefr 10y ago
I think it's a mind-expanding experience to set up an Erlang release on an "immutable infrastructure" system like CoreOS, with the Erlang "ssh" application enabled (instead of using ERTS's remsh system), and then keep that system up for weeks/months by doing maintenance through said SSH REPL. It becomes very clear, when you do so, that Erlang really is its own little sandboxed OS, and that the "Erlang Runtime System" is really a kind of standalone virtualization system for running that OS on other OSes. 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.)
- lliamander 10y ago
  I feel like Robert Virding once said that Erlang-as-OS was more or less one of their original plans (I wish I could remember the source, but it was during a discussion of the Erlang JCL mode in the REPL). EDIT: found the link http://erlang.org/pipermail/erlang-questions/2011-October/061447.html http://erlang.org/pipermail/erlang-questions/2011-October/06...

derefr 10y ago

Oh, sure, there are plenty of things getting in the way of developers being excited about using Erlang and thus deciding, in a bottom-up sense, to build more stuff in Erlang. 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.

lobster_johnson 10y ago
But did it have to become niche? I think Erlang could very well have branched out to become a more even general-purpose language, rather than doubling down on distributed computing to the exclusion of more quotidian tasks. 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 http://www.tbray.org/ongoing/When/200x/2007/09/22/Erlang
- 10y ago