What’s the major thing that Erlang/OTP (or Elixir) needs for greater adoption?
Resources that target young people or beginner (we already have some, but more, and more widespread).
Advertising outside the Elixir circle (Chris McCord asked the other day what podcasts would be a good fit for that).
Python has a major edge in France, being defined as the reference language (teached at high school and engineering schools), and as such it sets the frame.
For now, when I mention Elixir around me, although there is interest, the feedback is that it seems like a great language for connoisseurs and people with special needs (e.g. very high concurrency), which most people have no need for.
I personally think it's a great language overall, including from a maintenance point of view, and I try to advertise it as such.
Source: a dad with a 15-yo son who is totally into programming, and quickly saw that Python is everywhere together with Javascript (from a YouTube / blog posts / discord point of view). He doesn't understand why I "bother" with Elixir :-)
1. Lack of strong typing. Dynamic typing is great on 10,000 line projects with two developers. Once you reach 50,000 lines and have a little developer turnover, it stops being fun. And dynamic typing also usually means far less IDE support. I'm spoiled; I want auto-complete.
2. Elixir is amazing for UIs like Discord, where your users interact in real time. If each of your users lives in their own little world, Elixir's greatest strengths have less chance to shine.
Right now, TypeScript is a no-brainer, because React is the dominant choice for UIs, and using the same language on both client and server is a win. And frankly, TypeScript's lovely, even if the ecosystem is a constantly-churning trash fire. So for a variety of commercial projects, TypeScript is a responsible choice. Typed Python, C#, Java, Kotlin, Swift or Rust all have compelling use cases, too.
But given stronger typing and an project that needed Elixir's strong support for distributed systems, I'd definitely consider Elixir.
So I want to put on my consultant/lead engineer hat for this discussion. :-) I've worked for years in Ruby, Lisp, Scheme and other untyped languages, and shipped some fairly large projects.
Any project where you can rightfully say "I've built it" is small enough that dynamic typing can be a pretty pleasant strategy. (I'd miss good auto-completion, though.)
But when I walk onto a project with 5-20 engineers and 5 years of code, dynamic typing typically makes everything slow and painful. "We need to update two major Rails versions and deal with 40 supporting libraries. What's the plan for making sure everything still works? We have OK test coverage, but can we pull half the team for 2 weeks to work through the breakage?"
Or perhaps you reach a scale where you need to onboard a bunch of junior developers or data scientists. Here, static typing helps people get up to speed, it encourages them to refactor aggressively, and it limits breakage caused by miscommunication.
50,000 to 250,000 lines of statically-typed code maintained by a 5 person team with normal turnover can make for a very pleasant project. But in that size range, I really don't enjoy dynamic typing. It's doable, but I can really feel the difference.
I am extremely optimistic that Elixir could support excellent static types. And if it does, I'd definitely consider it for a wider range of projects.
> The power of a type system, the expressiveness of functional programming, and the reliability of the highly concurrent, fault tolerant Erlang runtime, with a familiar and modern syntax.
Haven't used it, but I'd like to hear about others experience.
https://elixir-lang.org/blog/2023/09/20/strong-arrows-gradua...
- Ericsson (they designed Erlang) is using it for its mobile products/networks. Approx 40% of all mobile traffic worldwide goes through Ericsson's infra.
- WhatsApp used/uses Erlang - again millions (billions?) of users
- Bet365 / Klarna use Erlang - millions of users
- from OSS, RabbitMQ, is written in Erlang
I could go on... Erlang has great adoption, but it's probably smaller than, e.g. Python, due to Erlang's specific applications.
in the programming community as a whole erlang/elixir are not very common.
it's important to ack this distinction becuase we still have a hill to climb with spreading awareness for OTP.
1. Not enough companies sharing their experience - most companies want to lead and not follow. There has been a lot of success with Elixir but too often I've heard companies not wanting to indicate they're using Elixir out of concern that it will tip off their competition (I've heard this from two companies now, big ones) or they just don't have a culture of sharing. The most impactful case study on Elixir was one of the first, the Bleacher Report case study https://www.erlang-solutions.com/case-studies/bleacher-repor.... They did an excellent job of articulating the direct business value of transitioning from Rails to Phoenix. We need more of these stories shared
2. Lack of talent - this is a chicken or egg problem but one thing that comes up quite often. If there were more companies actively hiring in Elixir there would be more devs learning Elixir but companies are reluctant to hire for Elixir because there aren't enough devs. Most of the courses/guides are aimed at transitioning Senior level talent. At DockYard through our Academy https://academy.dockyard.com/ we decided to tackle this from the opposite end and commit to producing high quality junior Elixir engineers.
3. Higher price point for talent - the recent Stack Overflow surveys regularly rank Elixir at the top for cost. Personally I think this stat is being influenced by the fact that Elixir has a higher % of more Senior level talent so the average salary will be skewed higher. But that nuance doesn't come through in the cost rankings. If true then as the ecosystem's talent pool starts to normalize we should see this cost average out.
4. Lack of off-the-shelf solutions - Objectively Elixir is faster to build and less costly to maintain than nearly every other tech stack I've ever used. However, because it is so easy to build something we have developed a culture of "just make it from scratch" too often. When newbies ask "how do I do X" questions like auth or something else in another tech stack that they can simply add a node module or a Ruby gem in Elixir most times we lack those pre-built solutions. So the actual build cost is higher because we can't simply drop that solution in and accelerate the dev process.
I've been selling Elixir services for almost a decade at this point and I'm still very bullish on Elixir. We, along with many others, have been trying to close these gaps. It's happening but the most impact anyone reading this can make that is using Elixir is to share your experiences. Write blog posts. Publish case studies. Indicate the reduction in cost, faster times to market, etc... these are the data points that are going to be most compelling and important in the coming decade.