Gleam doesn't compile to Erlang source anymore

Change in Gleam’s Erlang Backend

• Gleam now emits Erlang “abstract forms” (the Erlang compiler AST/IR) instead of human-readable Erlang source.
• Several commenters note this is the same representation widely used in the BEAM ecosystem (including Elixir and parse transforms).
• One commenter initially criticizes the old choice to generate text source instead of abstract forms, calling it redundant and error-prone.
• A core contributor explains the original decision: at the time, abstract forms weren’t the clear “standard,” Core Erlang’s API wasn’t stable for an external Rust compiler, and emitting source gave an escape hatch to Erlang and let them piggyback on Erlang’s build tools.
• Now Gleam writes Erlang Term Format directly; there’s still an Erlang source generator, mostly for tests.

“Transpiler” vs Compiler

• The article’s point that “transpiler” isn’t inherently pejorative prompts debate.
• Some note that the old pipeline was indeed worse, but due to implementation, not because it produced source.
• Others argue that if you can pretty-print abstract forms back to Erlang text, the distinction between “AST” and “source” is partly semantic.

Targets, Use Cases, and Interop

• Gleam is described as a general-purpose, statically typed, ML-like functional language aimed at simplicity, safety, and good tooling.
• Primary server target: BEAM (Erlang VM). Secondary target: JavaScript, mainly for web/front-end or other JS-hosted contexts (e.g., Lustre web apps).
• One commenter questions why JS is a target if Gleam isn’t “for UI”; others reply that JS is broadly useful beyond UIs and that having one language across server, SSR, and typed front end is attractive.
• Interop with Elixir is possible but not “seamless” due to different type systems.

Native / Other Backends

• Some wish Gleam compiled to a native target (e.g., Rust, Go, C, Wasm, LLVM IR).
• A core contributor argues:
  • Rust is a poor compile target: slow compiler, not widely installed, and its design for human authors doesn’t map well to being a backend IR.
  • Go’s GC and goroutine model aren’t ideal for Gleam’s immutable, process-based style.
  • Lower-level IRs (C, Wasm, LLVM, Cranelift) would be more appropriate if a native route were pursued.
• Workarounds like bundling the BEAM into a single executable (e.g., via Gleepack) can already yield small, portable binaries.

Language Comparisons and Learning Curve

• Comparisons: Gleam is repeatedly likened more to OCaml/Standard ML/Elm/F# than to Rust.
• Some think Rust users may find Gleam syntax and pattern matching approachable; others warn that conceptual expectations from Rust (ownership, borrowing) don’t transfer and can cause confusion.
• Erlang vs Elixir vs Gleam:
  • Gleam: typed, minimal, no macros, no pattern matching in function heads (a trade-off for simplicity).
  • Erlang: praised for matchers/guards and surprisingly pleasant syntax by some.
  • Elixir: valued for macros, OTP integration, excellent REPL, and mature web framework; preferred by some Rust users despite Gleam’s static typing.

Community, Ecosystem, and Adoption

• Multiple comments praise the Gleam community as exceptionally friendly, including live streams and educational talks.
• Users report good experiences building real projects (e.g., web APIs/services, apps via Gleam + Lustre + Tauri).
• Some see Gleam becoming their default stack; others lament not having work projects to use it.
• One commenter worries that, in an era of LLM-based coding, “LLM friendliness” might gate adoption of niche languages, which they find discouraging.

Miscellaneous Side Threads

• Detailed tangent on comma usage and grammar norms in English; consensus: style varies, and most people don’t care much outside formal contexts.
• Short discussion about integrating Gleam-generated code with tools like the WhatsApp Erlang debugger; considered trivial if compile flags are passed.
• Brief criticism of Gleam’s branding as looking “like girl toys,” with pushback from others who find this insecurity odd or irrelevant.