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 @external bindings 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. Int as 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, the echo keyword, 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.