Gleam Is Pragmatic

Original Article ↗ Hacker News Discussion ↗

Manual serialization and validation

  • Several commenters find Gleam’s manual JSON encode/decode ergonomics annoying and “un‑pragmatic,” especially compared to macro/codegen systems (Rust Serde, C# source generators, Elm-like derives).
  • Others defend explicit ser/de at boundaries as safer and more predictable, arguing that automatic serialization often appears to work while hiding subtle issues.
  • Distinction is made between serialization and validation: you can still need explicit validation (e.g., string length, domain rules) even with typed decoding.
  • Third‑party Gleam packages aim to improve ergonomics, but this is seen as a known pain point.

OTP, actors, and BEAM integration

  • Some argue Gleam under-emphasizes OTP and actors compared to Erlang/Elixir, calling documentation thin and the OTP library “experimental.”
  • The OTP library maintainer responds that it is not abandoned, is production‑used, but APIs may still evolve; conceptual “zen of OTP” is left to Erlang resources.
  • Debate over reimplementing OTP abstractions vs directly binding to Erlang’s: critics see a reimplementation as “not pragmatic,” advocates say it’s required for type safety.
  • Consensus: Gleam runs on BEAM, uses the same primitives, and aims to provide type‑safe APIs without sacrificing interop, though docs and examples are still maturing.

Imports, stdlib design, and operators

  • Some find having to import basic modules like gleam/int, gleam/string, gleam/io non‑pragmatic, since most modules use them.
  • Others argue uniform “always import what you use” simplifies the language and tooling; the language server can auto‑insert imports.
  • Questions arise about lack of methods and reliance on functions + pipelines; defenders say avoiding multiple styles (methods vs pipelines) improves readability.
  • Operator choices like <> for string concatenation and |> for piping spark debate; some dislike clashes with other languages’ conventions, others see them as inherited or intentional.

use syntax, monads, and control flow

  • use is described as syntactic sugar for continuation‑passing style, similar to constructs in Koka, OCaml let*, F# let!, and async/await patterns.
  • Opinions split: some see it as a powerful, general abstraction for async/effects; others find it less pleasant than alternative syntaxes but acknowledge it improves readability over deep callback nesting.
  • Discussion touches on monadic “railway‑oriented” style as a practical teaching vehicle, though several note it’s only one application of monads, not a full definition.

Learning curve, productivity, and language comparisons

  • Multiple commenters report struggling to become productive in FP (Elm, Gleam), despite long experience in imperative languages; they often fall back to Go/Rust/TS.
  • Suggestions include exercises, community resources, and small problems to internalize FP patterns.
  • Gleam is compared to Rust (similar syntax, ADTs, but GC + immutability), Go (simplicity and concurrency focus), and F# (very similar feel for some).
  • Partial application is supported via function captures with _, contrary to one initial complaint.
  • Some miss native code generation and ad‑hoc polymorphism for things like matrix arithmetic; how pleasant that would be in Gleam remains unclear.

JavaScript target, FFI, and errors

  • JS/TS compilation is seen as attractive; tooling like embedding Gleam in Vue SFCs exists.
  • FFI docs are acknowledged as thin but the language is simple enough that reading other packages is workable.
  • Most common runtime needs (FS, IO) are covered; FFI is mainly for runtime‑specific features when no library exists.
  • Pure Gleam code rarely forces direct Erlang usage; however, when calling Erlang/Elixir, their error messages do surface, though Gleam’s tooling tries to pretty‑print them.