By ByteBot
Gleam programming language hit 70% on Stack Overflow’s 2025 Developer Survey admiration ranking—second only to Rust’s 72%—despite appearing in the survey for the first time. This marks one of the strongest debut performances in the survey’s history. But here’s the paradox: only 1.1% of the 49,000 respondents actually use Gleam in production, while 70% of those who tried it want to continue. That 64x admiration-to-usage gap reveals something important about what developers want versus what they’re actually building with.
The timing matters. Gleam v1.0 only launched in March 2024, and recent Advent of Code discussions on Hacker News show developers actively experimenting with the language. The survey results align with a broader type safety trend: TypeScript overtook JavaScript on GitHub in August 2025, Rust maintains 72% admiration for nine consecutive years, and developers increasingly reject runtime errors in favor of compile-time guarantees. Gleam brings that same type safety philosophy to the Erlang Virtual Machine.
Why Developers Love Gleam: Type Safety Meets BEAM Concurrency
Gleam’s core value is simple: it brings compile-time type safety to the Erlang Virtual Machine (BEAM)—something Erlang and Elixir, both dynamically typed, don’t provide. Developers get WhatsApp-scale concurrency with millions of lightweight processes, plus Rust-quality type guarantees. That combination doesn’t exist elsewhere in the BEAM ecosystem.
The developer experience explains the 70% admiration score. One Advent of Code participant noted: “Gleam is easy to like quickly. The syntax is clean. The compiler is helpful, and the error messages are super duper good.” Error quality matters—Gleam’s compiler catches bugs at compile-time with messages compared to Rust’s high standard, not at production runtime like dynamic languages.
The learning curve is remarkably shallow. Creator Louis Pilfold designed Gleam so developers could “learn it in an afternoon” versus Rust taking months. The language has no null values, no exceptions, and one clear way to do things. Pattern matching includes exhaustiveness checking, so the compiler enforces handling all cases before code ships. The LSP integration works perfectly across VS Code, Zed, and other editors with squiggles, tooltips, and autoformatting out of the box.
The BEAM platform adds the killer feature: battle-tested concurrency. Gleam runs on the same virtual machine powering WhatsApp, Discord, and Ericsson’s telecom infrastructure. Actor-based concurrency with fault tolerance is built-in, scaling to millions of concurrent connections. Uniquely, Gleam compiles to both Erlang and JavaScript, enabling full-stack functional programming with the same type-safe language on backend and frontend.
The Admiration-Usage Gap: Why Gleam Isn’t Mainstream Yet
Despite 70% admiration, Gleam faces real adoption barriers in 2025. The ecosystem is immature. As one Advent of Code developer put it: “There’s generally not a lot of libraries available yet.” Elixir has Phoenix framework, Ecto ORM, and LiveView. Gleam has none of those. Developers can interoperate with Erlang and Elixir libraries—and it works—but it always feels better to use native Gleam packages. For advanced use cases, gaps exist: no Z3 bindings, limited tooling, must shell out to external solvers.
The job market reality is stark. Few companies are hiring Gleam developers in 2025. Production adoption sits at about 8% of Gleam users—remarkable for a language less than two years past v1.0, but still niche. Strand, a London marketing agency, is one of the few detailed public case studies. Mostly greenfield projects at startups are trying Gleam. Enterprise adoption is 3-5 years away, and developers face career risk betting on a language with minimal job openings today.
The “admired but not used” phenomenon isn’t new. Rust followed the same arc: 2015 v1.0 release, years of high admiration, finally mainstream production adoption around 2020. TypeScript took a similar 5-8 year journey from 2012 launch to overtaking JavaScript. The JetBrains 2025 Developer Ecosystem survey confirms this pattern—developers admire languages on side projects while companies adopt slowly. The 3x growth signal in Stack Overflow’s data (1.1% usage to 3.1% want to use) suggests Gleam is following that path.
When to Choose Gleam Over Elixir, Rust, or TypeScript
The Gleam versus Elixir decision is straightforward. Choose Gleam when starting a greenfield BEAM project and you need compile-time type safety guarantees. Choose Gleam if you’re tired of Elixir runtime type errors and prefer simpler languages with tighter static analysis. The refactoring safety alone matters—Gleam’s compiler catches breaking changes that Elixir discovers at runtime.
Stick with Elixir when you have existing production codebases, need the Phoenix ecosystem, or require mature libraries like Ecto and LiveView. Elixir’s metaprogramming capabilities don’t exist in Gleam by design. The talent pool is larger for Elixir, making hiring easier. Elixir isn’t going away—Gleam and Elixir can coexist, much like TypeScript and JavaScript.
Comparing across ecosystems clarifies Gleam’s niche. Rust offers systems programming with manual memory control, maximum performance, and WebAssembly support—but requires months to learn and years to master. TypeScript dominates web and Node.js with massive library ecosystems and gradual typing—but runs on JavaScript’s runtime platform. Gleam fills the gap: type-safe BEAM services where you need Erlang-level concurrency plus a modern type system, without Rust’s complexity or TypeScript’s platform constraints.
The Type Safety Mega-Trend Across Languages
Gleam’s 70% admiration isn’t an isolated signal. Developers across all ecosystems are choosing compile-time safety over runtime flexibility. TypeScript overtook JavaScript as GitHub’s number one language in August 2025 with 66% year-over-year growth. Rust has maintained 72% admiration for nine consecutive years as the most loved language. AI coding tools accelerate the trend—94% of AI-generated code errors are type-related, and TypeScript catches them at development time.
The pattern is consistent: runtime type errors are increasingly unacceptable in production systems. Developers are willing to learn new languages for type guarantees. Platform diversity emerges: TypeScript for web development, Rust for systems programming, Gleam for BEAM concurrency. Each brings compile-time safety to its respective ecosystem.
Gleam’s positioning mirrors TypeScript’s strategy. Just as TypeScript enhanced JavaScript with types while preserving the runtime platform, Gleam enhances BEAM with types while keeping Erlang’s battle-tested concurrency model. Both eliminate entire classes of bugs without abandoning proven infrastructure. The 64x admiration-to-usage gap isn’t a bug—it’s a leading indicator of where the BEAM ecosystem is heading.
Should You Learn Gleam in 2025?
The answer depends on your position. For developers already in the BEAM ecosystem, Gleam is worth exploring on greenfield projects. The type safety benefits are real, the learning curve is manageable, and interoperability with Elixir means you’re not abandoning existing infrastructure. For developers evaluating BEAM adoption, starting with Gleam over Elixir makes sense if compile-time guarantees matter more than ecosystem maturity.
For career positioning, Gleam is a calculated bet. The job market is minimal in 2025, but the 3x growth signal and historical precedent (Rust, TypeScript) suggest opportunities will emerge in 2-3 years. Side project experimentation carries low risk and high learning value. Production bets should wait for ecosystem maturation unless your team can build missing infrastructure.
The type safety trend is undeniable. Gleam scored 70% admiration in its first Stack Overflow appearance, demonstrating strong product-market fit among developers who value compile-time safety. Whether Gleam becomes the TypeScript of BEAM or remains a niche choice depends on ecosystem development over the next few years. The signal is clear: developers want type-safe BEAM, and Gleam is currently the only option delivering it.
