Gleam: a type safe language on the Erlang VM

Original Article ↗ Hacker News Discussion ↗

A new statically typed, ML-style language for the Erlang VM, Gleam aims to combine strong type safety with the BEAM’s famously robust concurrency and fault-tolerance, while also compiling to JavaScript. Commenters praise its clean syntax, Hindley–Milner type system, Rust-based compiler, and growing ecosystem, but raise questions about OTP maturity, testing tools, and the long‑term hiring risks of betting on a niche language versus mainstream stacks like C#, Java, or TypeScript. The project’s explicit political stance on its website also prompts debate over whether such messaging belongs in technical tooling.

Overall sentiment about Gleam and BEAM

  • Many commenters are enthusiastic: type-safe ML-style language on the BEAM, JS compilation, good community, growing ecosystem.
  • Some see it as a strong alternative to Rescript and a nice complement to Phoenix/LiveView.
  • A few are BEAM‑curious but hesitant to run it in production, viewing BEAM as a “black box”; others counter that BEAM has excellent introspection and debugging tools and is often easier to inspect than Node/JVM.

Type system and language design

  • Type system is Hindley–Milner, closer to OCaml than Haskell: algebraic data types, generics, type aliases; no type classes, no purity.
  • Some find it “barebones” and would like structural/set-theoretic types; others ask what real problems that would solve.
  • Pattern matching is seen as strong; syntax generally praised as clean.
  • Labelled arguments are widely discussed: some find them delightful and good for readability and API design; others see extra complexity and redundancy.
  • Pipe operator behavior (auto-inserting as first arg) is controversial: some like brevity, others feel it reduces clarity.
  • Lack of function overloading vs Elixir is briefly lamented.

OTP, ecosystem, and interop

  • Native OTP support is via gleam_otp and gleam_erlang; described as experimental but already used in production, including a webserver reported faster than Cowboy.
  • All underlying OTP is still accessible via FFI.
  • Rust NIFs and ports are available (via tools like Rustler), but require care to fit BEAM’s process/scheduler model.

Tooling, implementation language, and compilers in Rust

  • Gleam is written in Rust and cited as a strong example of a Rust-based language implementation.
  • Thread discusses pros/cons of Rust vs Haskell/OCaml for compiler work: Rust ecosystem (parsers, LSP, diagnostics, incremental tooling) is praised, but some find Rust’s enums/ownership awkward for ASTs.

Language choice, hiring, and “non‑mainstream” stacks

  • One view: using niche BEAM languages in ordinary businesses harms hiring and may force costly rewrites; mainstream stacks (C#, Java, Python, TypeScript, maybe Go) are “safer.”
  • Counter‑view: hire for ability, teach the language; Erlang/Elixir are simple to learn, and non‑mainstream stacks can attract higher‑caliber developers. Several anecdotes claim Elixir hiring and onboarding are not difficult.

Use cases and “typed scripting” debate

  • Some want Gleam as a typed scripting option; others argue BEAM and explicit types are a poor fit for quick scripts compared to string‑centric shells, but excellent for larger distributed systems.

Testing story

  • Testing currently centers on gleeunit, which also works on the JS target.
  • It’s intentionally minimal; mocks are deliberately not supported, with a preference for dependency injection. Some users would like more guidance or features.

Community guidelines and politics

  • Project site explicitly states social/political positions (e.g., anti‑racist/anti‑fascist, pro‑trans rights).
  • This sparks a side debate: some see it as appropriate expression of project values; others find it polarizing and say they will avoid or discourage use because of it. Both sides accuse the other of “bringing politics” into technical spaces.