The math reveals a distinct 'wear many hats' culture. Since many respondents identify with multiple roles simultaneously, the total exceeds 100%, confirming that Architects and CTOs in this ecosystem often remain hands-on coders.

It is a highly experienced crowd. Juniors represent a tiny fraction, while over a third of respondents hold Lead positions, suggesting Elixir is adopted mostly by veterans rather than as a first language.

The United States (22.6%), Germany (7.6%) and Brazil (6%) are the three largest clusters in the survey, with a strong tail across the rest of Europe and the Americas.

Poland, the UK, Sweden, Switzerland, the Netherlands and Mexico each contribute 2–4% of responses, showing that Elixir has meaningful pockets of adoption in many mid-sized markets.

Long tail participation from dozens of other countries confirms that the Elixir ecosystem is globally distributed, even if hiring markets and community events are still concentrated in a handful of regions.

Almost all respondents have hands-on experience with Elixir, so the rest of the survey reflects input from people who actually worked with the language.

The small number of non-Elixir respondents means beginner-level challenges or first-contact impressions are likely underrepresented.

This also makes the dataset unusually consistent — answers come from a community with direct exposure rather than from observers or people evaluating the language from the outside.

The median of five years may reflect the period when Elixir and Phoenix reached broader stability, so a large portion of the community could have joined around that time.

The presence of respondents with more than ten years of experience aligns with Elixir's age and suggests that early adopters remain active — which fits with the senior-heavy roles visible in earlier questions.

The wide distribution from one to eight years indicates that adoption may have grown steadily rather than in a single wave, matching how Elixir tends to spread through engineering teams rather than hype cycles.

The median professional experience of more than thirteen years suggests that many respondents entered Elixir after already spending a sizable part of their careers in other ecosystems.

This may help explain the strong representation of senior and decision-making roles seen earlier — Elixir tends to attract people with enough industry background to evaluate runtimes, concurrency models or operational reliability.

The wide range, reaching up to forty-plus years, indicates that Elixir is used by developers who have witnessed several generations of backend technologies; this perspective may shape the preferences and expectations expressed in later questions.

The distribution is clearly skewed toward higher self-ratings, which aligns with earlier answers showing that many respondents have several years of Elixir or general software experience.

An average of about seven suggests that most people answering this survey are already comfortable with the language and the BEAM model, rather than being at the very beginning of their Elixir journey.

Given Elixir’s age, this bias toward more confident users likely reflects who sticks with the ecosystem long term and is engaged enough to respond to a community survey.

The senior-heavy distribution is consistent with earlier answers showing long professional experience and strong Elixir proficiency, suggesting the survey mainly reached engineers who already operate in advanced roles.

The relatively large Staff/Principal group may reflect the type of organizations that adopt Elixir — often teams where technical leadership has freedom to choose runtime and architecture, rather than environments driven purely by mainstream stacks.

The small number of junior developers could point to slower entry-level adoption, which may later connect with questions about hiring challenges or learning resources.

People are coming to Elixir for its concurrency and fault tolerance, but they stick around for the joy of programming. The data confirms that Elixir hits a sweet spot between raw performance and developer speed, making it a go-to for companies that need to scale efficiently with smaller teams.

It’s clearly a deliberate choice by engineers—very few are forced into it by legacy stacks or corporate policy—though the ecosystem still has plenty of room to grow in areas like AI.

The ratings confirm that Elixir delivers exactly where it claims to: Concurrency, Fault Tolerance, and Reliability are the clear winners. What’s vital here is that 'Joy of Programming' sits right at the top with them. It implies that the language isn't just effective at keeping servers running; it’s actually pleasant to work with, which isn't always a given with robust industrial tools.

The community is realistic about the trade-offs, though. 'Performance' gets a more varied score than Concurrency, likely because developers distinguish between high throughput and raw number-crunching speed. AI/ML mostly lands in the neutral zone—people see the potential, but it’s not yet a primary strength compared to the established backend capabilities.

The strong concentration of 4–5 ratings may connect with what respondents value most about Elixir — especially concurrency, reliability and overall productivity, which were near the top in the earlier question about why they chose the language.

Teams using Elixir might be benefiting from fewer operational blockers or simpler concurrency patterns, which could contribute to faster delivery in environments where those factors normally slow teams down.

Mid-range responses show that not every project experiences clear time-to-market gains; this could depend on the maturity of the surrounding tooling or the type of system being built rather than the language alone.

Elixir clearly pays off when it comes to time-to-market. With over 75% of respondents reporting a positive impact, and an impressive 4.1 average rating, it’s safe to say the language isn't just fun to write—it actually helps teams get products out the door faster.

The lack of negative experiences is just as telling. Less than 5% of users felt Elixir slowed them down. Even the neutral group (about 20%) suggests that at worst, Elixir maintains the status quo, but for the vast majority, it acts as a significant accelerator for delivery cycles.

Documentation and books dominate as learning resources: about 90% of respondents rely on HexDocs and over two thirds on books or e-books, showing that Elixir’s strong official docs and book culture still anchor how people learn.

Community spaces are the next layer: discussion boards such as ElixirForum plus blogs, conference talks and recorded presentations are widely used.

Video and audio formats (YouTube, screencasts, podcasts) play an important but secondary role, giving people alternative ways to absorb concepts or follow along with live coding and talks.

Roughly 4% explicitly mention AI / LLM tools, and smaller groups point to chat communities, coding exercises, courses and reading existing codebases—suggesting that newer learning patterns are emerging, but classical documentation-first learning is still the norm.

Most respondents follow Elixir news through focused ecosystem channels such as Elixir Forum, newsletters and blogs.

Larger social platforms like X, Reddit and Bluesky play a secondary role and may be used for quick discovery rather than deep technical updates.

Smaller clusters such as Mastodon, Telegram or private chat groups show that parts of the community rely on more decentralised or conversational spaces for staying informed.

Only a few responses reference aggregators like Hacker News or niche sources, suggesting that Elixir news typically spreads more through dedicated community channels than through general tech hubs.

It’s time to bury the myth that Elixir is just a destination for ex-Rubyists. While Ruby remains a strong feeder (43%), it is significantly overshadowed by TypeScript and JavaScript (64.5%). This shift suggests that Elixir has become a top contender for full-stack developers who want a backend that can actually handle the complexity of the modern web, rather than just being a niche upgrade for Rails developers.

What’s equally interesting is the lack of 'lateral moves'. Very few people are coming from other functional languages like Haskell, Clojure, or Scala. Instead, the vast majority are migrating from the heavy hitters of the imperative world—Python, Java, PHP, and C#. For most of these engineers, Elixir isn't just a new syntax; it is likely their first real entry into functional programming, proving the language is approachable enough to win over the mainstream crowd.

Visual Studio Code is by far the most common choice, which fits the wider industry trend.

Neovim, Vim, Emacs and Helix form a large group of terminal- and keyboard-driven editors, while Zed and Cursor represent more modern, GUI-based setups, with Cursor in particular standing out as an AI-first code editor.

IntelliJ-based tools and RubyMine cover a smaller but visible segment, likely representing teams coming from JVM or Ruby backgrounds that keep their existing IDE workflows.

Smaller entries such as Windsurf and various niche editors show that experimentation with newer or more specialised tools is happening, but they remain marginal compared to the VS Code and Neovim ecosystem.

Almost everyone uses mix format, and a large majority also relies on Credo, which may indicate that basic formatting and style checks are considered a standard part of Elixir workflows.

Dialyxir adoption is close to half of respondents, suggesting that gradual, type-like checking is important in practice even before the gradual type system fully lands in the language.

Security- and reliability-oriented tools like Sobelow are present but not universal, which could mean that deeper static analysis is more common in certain kinds of projects than across the entire ecosystem.

The long tail of tools in Other shows some experimentation, but the day-to-day static analysis stack in Elixir appears to be concentrated around a small core: mix format, Credo and Dialyxir.

Most respondents pair Elixir with TypeScript or JavaScript and shell scripting, which fits a picture where Elixir often sits in a web or services stack with JS frontends and CLI or ops tooling around it.

Python, Rust, Go and C/C++ appear frequently alongside Elixir, suggesting that teams mix it with data tooling, systems components or performance-sensitive pieces rather than using it as a single-language stack.

Compared with the “before switching” question, Ruby and PHP are much more common as prior languages than as current companions, which may indicate that many teams migrate away from those stacks when adopting Elixir.

A non-trivial group reports using almost no other languages with Elixir, while smaller clusters around Dart and Gleam show that some developers experiment with modern FP or typed languages next to their Elixir codebases.

Among respondents who care about interoperability, Rustler, C NIFs and Ports form the main toolbox, which matches the earlier picture of many teams combining Elixir with Rust, C/C++ and Python in the same systems.

Pythonx and Zigler show that some developers prefer language-specific wrappers around NIFs instead of writing raw C, which may lower the barrier to mixing Elixir with systems or data-processing code.

Tools like Hologram and AtomVM appear lower on the list mainly because they are new technologies. These projects focus on bringing Elixir to the browser and frontend environments. While their current adoption is limited due to their early stage, they point to a specific trend: developers are beginning to explore running Elixir code client-side, beyond its traditional backend role.

Ratings cluster strongly around 7–8, which suggests that most respondents see Elixir’s interoperability as solid but not flawless.

The average slightly above seven lines up with the previous question, where many developers reported familiarity with NIFs, Ports and Rustler, but far fewer with newer or more specialised tools.

Lower scores are rare, but the relatively small share of 9–10 answers may indicate that there is still room to simplify interop, especially for teams that are not comfortable writing NIFs or managing mixed-language builds.

The community’s requests focus heavily on three main ecosystems: Python, JavaScript/TypeScript, and Rust. These top choices reflect practical gaps in the current Elixir landscape. Developers likely want Python for better access to data science and AI libraries, and JavaScript for tighter integration with frontend tools.

Rust remains a top priority despite existing tools like Rustler, suggesting a continued demand for easy, high-performance system-level integration. The significant drop-off in votes for languages like Go or Java shows that users are prioritizing specific functional capabilities (AI, UI, Performance) over general enterprise interoperability.

Most respondents use Elixir in monolithic systems, often alongside monorepos and DDD.

Event-driven patterns are also common, while more specialised styles like event sourcing and CQRS appear in a smaller subset of projects, suggesting these are used where teams deliberately lean into BEAM’s process model instead of as a default choice.

Serverless is rare, which is consistent with current platform support for BEAM and indicates that Elixir is still primarily deployed as stateful services rather than short-lived functions.

Phoenix is effectively the default web framework for Elixir, and the very high adoption of LiveView suggests that many teams are comfortable with server-driven UIs rather than splitting work across separate frontend stacks.

Ash and Absinthe appear as mid-sized ecosystems on top of Phoenix, which may indicate interest in higher-level APIs (resource-oriented or GraphQL) when projects grow in complexity.

Nerves and Commanded are used by a smaller subset of respondents, matching earlier answers about event-sourcing patterns and embedded use cases: important niches rather than mainstream usage.

Most respondents use Ash primarily as a domain modeling and policy layer, which matches its design as a resource-oriented DSL rather than a classic web framework.

CRUD/admin and API generation are also common, suggesting that teams lean on Ash to standardise data access and expose resources consistently instead of hand-rolling controllers or GraphQL schemas.

Realtime usage is noticeably lower, which may mean that Ash is more often paired with Phoenix and LiveView for interactive features than used as the main entry point for realtime workflows.

The small set of “Other” answers points to experimentation around TypeScript, UI modeling and AI-related scenarios, but these are still early compared to the core domain-and-policy use cases.

The two most common reasons for not using Ash are simply not having a clear need yet and lack of awareness, which suggests that limited exposure and timing matter more than strong negative opinions.

A large group prefers hand-crafted Ecto/Phoenix and is wary of Ash’s DSL-heavy approach, echoing several free-text comments about abstraction, magic and lock-in rather than concrete technical blockers.

Learning curve and documentation gaps appear as secondary concerns; combined with the earlier results on Ash usage, this may indicate that onboarding material and examples for incremental adoption could have a noticeable impact.

Performance worries are relatively rare, so hesitation seems to be more about ergonomics, control and migration from existing codebases than about runtime characteristics.

Most respondents rate the gradual type system as important (4 or 5), but there is also a sizeable neutral group at 3, which suggests that the community is interested but not uniformly focused on types as a top priority.

Given that around half of respondents already use Dialyxir and other static analysis tools, this distribution may reflect a shift toward stronger guarantees while still keeping Elixir’s dynamic workflow for parts of the codebase.

Low scores are relatively rare, indicating that even developers who are not actively waiting for the type system today generally do not see it as harmful to the language’s direction.

Most respondents aren’t looking for a radical reinvention of how we write Elixir. They mainly want the new type system to smooth out the rough edges we already feel today: to be a clear improvement over Dialyzer and to power better IDE and IntelliSense support.

Right after that come safety and reliability concerns: catching more bugs earlier and making debugging easier.

Type annotations and nicer syntax are appreciated, but they’re secondary. What really matters is practical, fast feedback while coding and refactoring

In the free-text answers, developers often mention refactoring, LSP performance, and compile-time checks for things like LiveView.

Livebook is by far the most commonly used tool, which fits its role as the central place where many Elixir developers work with data, experiments, and ML-related workflows.

The next group consists of tools from the Nx ecosystem — Kino, Nx, Bumblebee, Explorer, Axon and EXLA/ROCm. These results show that a noticeable part of the community is using Elixir’s own ML and numerical libraries, not only external services.

Around a quarter of respondents mention using external models through APIs, so mixing Elixir tooling with hosted ML services is still a typical setup.

Very few respondents chose “None”, which suggests that most people answering this question already use at least one ML-related tool in the Elixir ecosystem.

Claude Code is by far the most used tool, with over 55% of respondents choosing it. This suggests that for Elixir developers, Anthropic's models currently give better results than the competition. GitHub Copilot and Cursor are next in line, but they are clearly less popular choices here.

It is also worth noting the Elixir-specific tools in the top five: Tidewave and Phoenix.new. Tidewave is nearly twice as popular as Phoenix.new possibly suggesting that developers prefer a solution that allows them to hook into existing projects and support local development. The rest of the list, like Codex or Windsurf, has much smaller adoption.

Anthropic is the overwhelming favorite here, with nearly 84% of developers choosing Claude. It has a massive lead over OpenAI (32%), which confirms that for Elixir code, Claude’s models are delivering much better results than GPT.

The rest of the field is very small. Google’s Gemini is used by about 12% of the group, but other options, including open models like Llama or Mistral, are barely visible. It seems the community prefers powerful, hosted models over running local open-source alternatives.

There is a clear gap between adoption and actual impact. While previous questions showed that nearly everyone uses AI tools, the average productivity rating sits right in the middle at 3.01. This suggests that while developers are actively using AI, the results for Elixir are often just 'okay' rather than game-changing.

The opinions are very evenly split. The largest group is the neutral one (29%), and the number of people who find AI very helpful is roughly balanced by those who find it unhelpful. It implies that for Elixir, AI is currently a hit-or-miss experience—useful for some tasks, but struggling to deliver consistent value across the board.

The data shows a clear split: AI is mostly used for repetitive, low-level tasks. Generating boilerplate (65%), writing tests, and documentation are the top use cases. It seems developers trust AI to handle the tedious parts of coding, but rely less on it for complex logic.

This explains the moderate satisfaction rating from the previous question. When it comes to advanced Elixir concepts like OTP (18%) or system architecture (25%), usage drops significantly. AI isn't yet consistent in solving the hard problems — it's mostly speeding up the easy ones, which limits its overall impact on heavy-duty engineering.

AWS is the most common hosting option for Elixir, with Fly.io not far behind, which suggests that many teams either stay on the dominant general-purpose cloud or choose a BEAM-friendly PaaS when they want less infrastructure work.

DigitalOcean and Hetzner form a strong mid-tier, together with a noticeable share of private clouds and bare-metal VMs, indicating that cost control and direct machine access are still important for a sizeable part of the community.

Kubernetes is used by about one in ten respondents, while classic PaaS options like Heroku and Gigalixir, plus newer platforms like Render, occupy smaller but still relevant niches.

The long tail of Vultr, UpCloud, Scaleway, AlwaysData, Northflank and many smaller VPS or home-lab setups shows that Elixir deployments are quite diverse, but the bulk of workloads still run on a mix of AWS-style clouds and relatively simple VM-based hosting.

We included this question to test if Elixir's main selling points—scalability and distributed computing—translate into massive server fleets in reality. The results provide interesting data: over 80% of production systems run on just 1 to 5 nodes. Despite the capability to scale horizontally across huge clusters, the vast majority of deployments are actually quite compact.

This could imply that many Elixir applications are still in the early stages of their lifecycle or operating on a smaller market scale. However, it could be also a testament to the language's efficiency—since a single Elixir node can handle massive concurrency, teams often simply don't need a large number of servers to handle production traffic.

Most respondents lean on OTP-native primitives first: job processors like Oban or Exq, built-in BEAM distribution and Phoenix PubSub are the dominant ways of spreading work across processes and nodes.

Roughly a third of teams complement these with external queues and streams (RabbitMQ, Kafka, SQS, etc.) or Broadway/GenStage, which fits the picture of Elixir systems sitting in larger polyglot architectures where events flow through shared infrastructure.

Orchestration tools such as Kubernetes, ECS, Nomad or Fly.io are present but not universal, which matches earlier answers showing many deployments running only a handful of nodes on relatively simple hosting setups.

Only a minority uses distributed state, CRDTs or custom protocols, suggesting that advanced multi-node coordination is important for some workloads but is not yet a common requirement across the wider Elixir community.

Almost nine out of ten respondents are currently employed, so the survey mostly reflects the perspective of people active in the job market.

The remaining group includes students, people between jobs, and others not currently employed, but they are a clear minority in this dataset.

Over half of respondents work in organizations up to 50 people, which reinforces the picture of Elixir being popular in small product teams, agencies and startups.

At the same time, a substantial minority comes from companies with 50–200 employees and even 1000+ staff, showing that Elixir is also present in larger environments, though not yet dominant there.

For most respondents Elixir is already a production technology: over 70% say their organization runs it in production, with only a small slice using it purely for R&D.

Roughly one quarter of organizations either do not use Elixir yet or have no plans to, which means there is still some headroom for adoption despite a strong production footprint.

Most Elixir teams are small: about 60% of respondents work in teams of five people or fewer, with 3–5 being the most common configuration.

Around a quarter report mid-sized teams between 6 and 20 people, while only a small fraction belong to very large Elixir groups of 21+ engineers.

Combined with the earlier organization-size question, this suggests that even in bigger companies Elixir is usually adopted by relatively compact, focused teams rather than giant departments.

The biggest blockers to Elixir adoption are skills and hiring: over half cite lack of in-house expertise and just over 30% worry about recruiting, which lines up with earlier results showing relatively small, specialised Elixir teams.

Around half say their company has already committed to another stack, often a mature JVM or JS ecosystem, and about a fifth mention migration or maintenance cost, suggesting that inertia of existing systems is a stronger barrier than technical doubts.

Concerns about the ecosystem itself, integration issues or pending management decisions affect smaller but still noticeable groups; many free-text answers also say Elixir simply hasn’t been seriously evaluated yet rather than being explicitly rejected.

Across all dimensions, most respondents pick 4 or 5, which suggests that teams who already use Elixir generally see a positive business impact.

The strongest signals are in reliability, scalability and developer morale: well over half of respondents give these areas the highest score, which fits earlier answers about fewer incidents and good productivity.

Cost reduction and faster time-to-market also lean positive, but with more 3-level responses, hinting that these benefits might depend more on the specific product or how the team is organised.

The answers cluster around the middle: most respondents rate hiring difficulty as 3, with a noticeable tail towards 4 and 5.

Only a small share reports that hiring is easy (1–2), which fits with earlier answers where lack of expertise and hiring concerns were common reasons for not adopting Elixir.

Taken together, this suggests that while hiring is not impossible, teams should still expect a narrower talent pool than for mainstream stacks and plan for training or internal upskilling.

Most Elixir hires still come through existing connections: roughly one third of answers mention personal networks, referrals or people who worked together before.

Community channels such as Elixir Slack, Forum, meetups and Elixir-specific job boards are the next most common source, followed closely by internal training programs and more traditional job ads.

Recruiters and headhunters are used almost as often as job ads, but many respondents combine several approaches and explicitly say they hire strong generalists from other stacks and then teach them Elixir.

About two thirds of respondents explicitly see Elixir as a competitive advantage, which lines up with earlier answers about better reliability, scalability and developer happiness.

Roughly one third sit in the “partially / hard to tell” bucket, suggesting that in many organisations Elixir is only one part of a larger stack or its benefits are hard to separate from other factors.

Very few people think Elixir is not an advantage at all, which indicates that once teams adopt it, they rarely see it as a drag on their business.

The open-ended responses highlight two primary areas of concern: business adoption and developer tooling. On the business side, respondents consistently point to the need for more job opportunities and better marketing to enterprise decision-makers. There is a recurring sentiment that while the technology is excellent, its niche status creates hiring challenges and limits career stability for developers.

Technically, the feedback is focused on the daily development workflow. A significant number of comments cite instability with the Language Server (LSP), slow compilation times, and a lack of advanced debugging tools compared to other ecosystems. Users also view the upcoming Type System as a critical necessity for maintaining larger codebases.

Regarding the ecosystem, the community prioritizes the maintenance of existing libraries over the creation of new ones. There are frequent mentions of 'abandonware' and a lack of mature integrations for standard enterprise services. While there is interest in expanding into AI and Mobile, the prevailing view is that the core foundations—tooling, documentation for advanced use cases, and library stability—need to be solidified first.

The most consistent request is for a stable, feature-complete Language Server (LSP). Developers express frustration with the current state of tooling, specifically citing the lack of reliable refactoring, debugging, and autocomplete features compared to other modern ecosystems.

On the frontend, there is a distinct gap in the LiveView ecosystem for high-quality, pre-built UI component libraries. Multiple respondents specifically request a 'Shadcn-like' library or a robust set of accessible components to speed up UI development without writing custom CSS from scratch.

Beyond tooling, the wish list is dominated by 'native' solutions that remove dependencies on other languages. This includes a strong demand for Elixir-native AI frameworks (specifically Agents and MCP servers), a solid Mobile/Desktop story, and better support for standard enterprise requirements like PDF generation, Kafka integration, and SOAP.