Should Gleam support implicit error propagation through async chains or require explicit Result unwrapping at each await point

Question

Async Error Propagation Design QuestionGleam's async/await syntax compiles to JavaScript Promises, enabling asynchronous operations with a familiar syntax for JavaScript developers. The language uses a message-passing concurrency model where async tasks communicate via channels rather than shared memory.Async functions in Gleam can return Result types, requiring explicit error handling through pattern matching. The compiler enforces that all async functions have explicit return types, preventing implicit Promise handling.This creates a tension in concurrent contexts: when chaining multiple async operations that can fail, developers must unwrap Results at each await point, potentially leading to verbose code. However, explicit unwrapping provides clear error handling boundaries and prevents silent failures.Which approach better serves Gleam's philosophy of making errors explicit while maintaining ergonomic async code? Does the current requirement for explicit Result unwrapping at each await point create unnecessary boilerplate, or does it provide valuable safety guarantees? Should the language evolve to support implicit error propagation through async chains while maintaining the ability to handle errors explicitly when needed?

Tasadduq Burney · Answer

Direct answer
Require explicit Result unwrapping at each await point. Implicit error propagation through async chains should be an explicit opt-in mechanism, not the default behavior of await.

Confirmed facts
Gleam's error model is built around the explicit Result type with Ok and Error variants, handled through pattern matching rather than exceptions for ordinary control flow. The compiler requires explicit return types for async functions.

Likely explanation
Implicit await error propagation would behave like an early return or throw across async boundaries. That hides where failures are handled, makes retry and timeout boundaries less visible, and complicates interaction between Erlang process supervision and JavaScript Promise semantics. Ergonomic gains are better achieved through explicit Result combinators and helper functions while keeping error boundaries visible.

Version and target uncertainty
Async support and target semantics differ between Gleam's Erlang and JavaScript backends and may change between releases. The claim that async/await compiles to JavaScript Promises should be verified against the current compiler before relying on it.

Recommended steps

Run gleam --version to confirm the installed compiler release.
Read the release notes and standard-library documentation for async/await, Promise interop, and Result combinators.
Build a minimal chain of two async functions returning Result on both Erlang and JavaScript targets and confirm whether an intermediate Error stops at its await point or propagates automatically.
Search Gleam language proposals or issue tracker discussion for async error propagation or a try operator to see whether the idea is accepted, rejected, or open.

Missing diagnostic detail
Which Gleam version and target—Erlang or JavaScript—are you using? This determines whether async/await is available and how Result values interop with Promises, so it changes the recommendation.

Ergonomic alternative
Use explicit Result combinators such as and_then and map, or small helper functions, to reduce repetition without making failure paths invisible at await boundaries.

Should Gleam support implicit error propagation through async chains or require explicit Result unwrapping at each await point

Async Error Propagation Design Question

1 answer

Direct answer

Confirmed facts

Likely explanation

Version and target uncertainty

Recommended steps

Missing diagnostic detail

Ergonomic alternative

Your perspective belongs here.

0 question comments