- Lack of developers
- Considered hard to learn
- Concern over current level of adoption (risk, cost, reliance on scarce resources)
- Convincing managers is hard
- Dissatisfaction with libraries, documentation, and tooling -- often cited as barriers to adoption
In light of Garret's informative work, I wanted to reflect on my personal reasons for using languages other than the Erlang/Elixir stack. To clarify, I love Erlang. I think the programming model is brilliant. Implementing objects as actors that run concurrently makes a lot of sense to me. Due to the wonderful syntax and implementation, the overhead for using the actors is very low -- little more complicated than calling a method in an object-oriented language.
Erlang's approach to structuring code offers a nice balance between functional and object-oriented programming paradigms. The use of actors provides instances which encapsulate their own state and local namespaces like objects. However, the combination of dynamic typing and code organized into functions and modules makes it easy to reuse code in a manner similar to mixins. Erlang completely avoids the class hierarchy of inheritance-baseed object-oriented languages and separates the concept of identity and code organization. As a result, Erlang completely avoids the brittle and complex design patterns required by objected-oriented languages, while avoiding the complexities and frustrations of purer functional languages.
So why do I rarely ever use the Erlang/Elixir ecosystem? Simply put, the lack of onramps.
Ruby became popular because of Rails. Node.js used web developers' pre-existing comfort with Javascript as an onramp. Python is easy to get started with, scales, and has a huge ecosystems of specialized libararies, especially due to its ability to easily integrate with C. Scala and Clojure are attractive to users already using Java and the JVM and can tap into the wide range of existing libraries. And lastly, Go is backed by Google, providing great advertising and immediate exposure to a ton of internal developers who can battle test and evangelize the language.
Building onramps is key to language adoption. Elixir/Erlang, D, Ceylon, and Rust have all struggled with this, resulting in slower adoption than their peers.
My work for the last few years has spanned a few different areas:
- Modeling & Simulation -- development and implementation of mathematical models for studying the physics of molecules
- Data Science -- analysis of large data sets in physics, chemistry, and bioinformatics
- Data storage and processing systems for scientific data
- RPG game
By and large, most of my work has been in the form of contributions to existing projects which don't use Erlang/Elxir. Since changing languages for an existing project isn't an option (or even a smart choice in most cases), none of these projects could serve as onramps.
What about for new projects, from scratch? All of my new projects have been data science projects. Converting data from one file format to another. Combining datasets. Visualization of datasets. Computing statistics. None of these are strong areas for Erlang/Elixir, but they are for Python.
Python makes it really easy to start with small scripts or an interactive session (especially with iPython Notebook) since there is no project setup required. Python also scales to large applications -- as a result, I don't have to worry about changing languages down the road since my project won't outgrow Python. As a strong, general-purpose language with a large, high-quality ecosystem, Python is suitable for almost any task or project, no matter how specialized. As a result, I rarely ever have a need to leave the Python ecosystem.
Erlang/Elixir projects require a bit more overhead to setup. The Erlang/Elixir language is not ideal for projects requiring lots of data manipulation, math, graphics, or low-latency performance (games). Erlang/Elixir certainly doesn't have the necessary breadth of libraries to support general-purpose tasks. They are good at one thing and one thing only: distributed, fault-tolerant systems.
I'm starting to become interested in Scala. Why? My new job at Red Hat involves working with and hacking on software built in Java and Scala -- existing projects are serving as onramps.
I'm also curious about Julia. Why? Julia has the iJulia Notebook similar to iPython Notebook, making it really easy to get started with. Like Python, Julia also has a large set of libraries for data analysis and visualization, made possible through easy integration with C and Fortran, which makes it well-suited to many of the projects I work on. The appropriateness for my work provides an onramp.
In my mind, if Erlang and Elixir want to grow, the community needs to identify ways to expand the scope of Erlang and Elixir to other potential use cases so that there are a larger number of natural onramps.
RJ, the results of this survey do not address "Why Not Erlang". There were five questions:
ReplyDelete1. What is your general impression of Erlang?
2. For what situations would you consider using Erlang?
3. What challenges do you see in adopting Erlang for a project?
4. What languages or frameworks would you consider as alternatives to Erlang?
5. What about Erlang or its ecosystem (libraries, community, governance, etc) would you change?
Lack of on ramps or other barriers to learning or adoption do not represent, in my opinion, a good reason for not using something. If your problem requires a particular set of features and a language, tool, or framework has those features, you should use it, even if it's hard.
The survey results show, sensibly, that people consider Erlang for back end systems (in the tag cloud this shows up as "Servers"). The respondents generally understood that Erlang is well suited for long running, unattended applications that need to keep running and optionally scale.
You don't list those features in the things you work on. In fact you list the things that Erlang is not ideally suited for.
"Why not Erlang" because "it's hard" is nonsense. The question was "what challenges do you face". "It's hard" is a legitimate challenge, but certainly no reason to use Python, Ruby, Node.js, etc. when Erlang is a better fit for the problem.
I think the gist of this post is much closer to "Why not Erlang? When It's Not The Right Tool For The Job". It's less catchy and certainly less controversial, but I think it's what you're saying here.
Garrett,
ReplyDeleteThanks for taking the time to respond and the clarification! Yes, "not the right tool" versus other general-purpose languages would be my thesis statement.
I hope to see Erlang/Elixir become the right tool for a wider-range of applications, though. It's gaining in popularity and has a good shot for becoming the "go to" language for servers.
But if it doesn't start to penetrate other areas, especially areas where programmers can get hooked earlier on, it may end up like LISP. Everybody talks about LISP but few people use it.
LISP's main legacy has been its influence on other languages in the ecosystem. E.g., garbage collection, dynamic typing, etc. Erlang is starting to have a similar effect with Akka and actors in Rust. However, without support in the runtime, not all the benefits of Erlang can be achieved. I hope that new languages will be more successful at adopting Erlang features.
There's a scala notebook attempt as well https://github.com/Bridgewater/scala-notebook I don't know how mature it is but you might want to take a look at it
ReplyDelete