The Gleam Programming Language
Overall impressions & experience
- Many commenters find Gleam attractive: simple, well‑designed FP, strong static types, ADTs,
Result/Option, pattern matching, immutability, and a good LSP. - Some report substantial joy using it (sometimes after burnout or frustration with other languages); others bounce off the “invented rules” and FP style, preferring more mainstream languages.
Serialization and boilerplate
- A key pain point is lack of built‑in or standard derive‑style serialization (especially JSON); users dislike hand‑writing encoders/decoders for many types.
- There are mentions of codegen tools, but no consensus “good” library, especially for discriminated unions.
- This ties into the lack of macros and ad‑hoc polymorphism, which makes ergonomic, generic serialization libraries harder.
Types, distributed systems, and Gleam’s stance
- Long subthread debates whether HM‑style type systems lose value in distributed/networked contexts with partial failure and uncertainty.
- One side argues static types devolve into “everything is Optional,” becoming dynamic typing with extra ceremony.
- Others counter that types help define invariants, localize uncertainty at boundaries (e.g. deserialization), and allow compilers to enforce checks.
- Gleam is noted as explicitly not trying to make distributed message passing fully type‑safe; it treats external messages as dynamic data to handle at the boundary.
Polymorphism, macros, and ecosystem / interop
- From an Elixir perspective, lack of ad‑hoc polymorphism and macros is a blocker for some (e.g. JSON, filesystem, logging).
- Others see the absence as beneficial, reducing “magic” and indirection.
- Debate over ecosystem access: technically Gleam can call any BEAM function, but you must write
@externalbindings with type signatures; some see this as friction versus Elixir’s seamless interop.
Targets: BEAM and JS
- Some worry dual targets dilute focus; others like sharing code between server (BEAM) and client (JS).
- Differences in semantics (e.g.
Intas arbitrary precision on BEAM vs JS number, recursion limits) mean most projects pick one target in practice.
Tooling, debugging, and REPL
- No native REPL yet; users approximate with “dev modules,”
gleam run, theechokeyword, and Erlang shell tools. - Some miss REPL‑driven Elixir/Erlang workflows; others find existing debugging options acceptable.
Performance and role vs Go/Erlang
- Runtime performance is essentially BEAM performance: slower than Go in raw throughput but strong for highly concurrent, I/O‑heavy workloads.
- Some question why to choose Gleam over Elixir for BEAM work; others emphasize type safety and ergonomics as the differentiator.
Community and politics
- Several comments note a visible political/values stance in the project/community.
- Some see this as positive (clear norms, excluding abusive behavior); others see it as a red flag or potential for echo‑chamber dynamics.