October 6th, 2024

Gleam Is Pragmatic

Drew Olson discusses the Gleam programming language, which merges Haskell and OCaml features, supports immutable data, simplifies callbacks, and enhances usability with custom types, showing promise for functional programming.

Read original articleLink Icon
CuriositySkepticismEnthusiasm
Gleam Is Pragmatic

Drew Olson shares his experiences with the Gleam programming language, highlighting its pragmatic design choices that combine the strengths of Haskell and OCaml while minimizing their downsides. Gleam is a strongly-typed functional programming language targeting the BEAM and JavaScript, featuring immutable data structures and allowing untracked side effects. Olson appreciates Gleam's use expressions, structural equality for all types, and the absence of ad-hoc polymorphism. He provides examples demonstrating Gleam's syntax, including optional type annotations, first-class functions, and the use of the |> operator for function pipelines. The article also discusses monadic-style APIs in Gleam, showcasing how the language simplifies callback-based programming through the use construct, which flattens nested callbacks. Olson compares Gleam's handling of custom types with Haskell and OCaml, noting Gleam's ease of use without requiring additional boilerplate for custom types in dictionaries. He concludes that Gleam's design decisions make it a promising option for both newcomers and experienced functional programmers, expressing enthusiasm for its future development.

- Gleam combines features from Haskell and OCaml, offering a pragmatic approach to functional programming.

- The language supports immutable data structures and allows untracked side effects.

- Gleam simplifies callback-based programming with its use expressions, reducing complexity.

- Custom types in Gleam can be used without additional boilerplate, enhancing usability.

- Olson expresses optimism about Gleam's potential for functional programming enthusiasts.

AI: What people are saying
The comments on the article about the Gleam programming language reveal several key themes and points of discussion.
  • Users express curiosity about Gleam's integration with Erlang and whether Erlang's error messages affect Gleam programming.
  • There are concerns regarding the documentation for JavaScript support and the clarity of package compatibility.
  • Some commenters find the syntax and features of Gleam, such as the `use` statement, intriguing but confusing.
  • Critiques focus on the need for manual serialization/deserialization and the necessity of importing basic libraries, which some view as impractical.
  • Comparisons to other languages like F# and concerns about missing features, such as partial application and native code compilation, are also discussed.
Link Icon 17 comments
By @jazzypants - 3 months
> I won’t fall into the trap of trying to define Monads in this post. Instead, let’s talk about monadic-style APIs – that is, APIs that allow you to do a bunch of things one after another, with the ability to use the result of a previous computation in the next computation, and also allows some logic to happen between steps.

Am I crazy, or did he just give a really good definition of monads in programming? I think that it benefits by not letting itself get bogged down in Category Theory nomenclature which doesn't actually matter when programming.

By @atemerev - 3 months
The greatest power of BEAM-based languages is the fully preemptive actor model. Nobody else supports it. This is a superpower, the solution of most problems with concurrent programming.

In Erland and Elixir, actors and actor-based concurrency hold the central place in the corresponding ecosystems, well supported by extensive documentation.

In Gleam, actors and OTP are an afterthought. They are there somewhere, but underdocumented and abandoned.

By @skybrian - 3 months
Gleam's 1.0 release was in May and it's still adding major features.

JavaScript support looks interesting. Browsing the package repo, I don't see how to tell which packages are supported on Erlang's VM, when compiling to JavaScript, or both. JavaScript-specific documentation seems pretty thin so far?

By @patte - 3 months
This is a very concise overview! I have made a small example chat app [1] to explore two interesting aspects of gleam: BEAM OTP and compilation to javascript (typescript actually). If anyone is interested...

[1]: https://github.com/patte/gleam-playground

By @rossng - 3 months
The `use` syntax is interesting - don't recall seeing anything similar before. But I'm struggling to understand how exactly it is executed and a glance at the Gleam docs didn't help.

Is the `use` statement blocking (in which case it doesn't seem that useful)? Or does it return immediately and then await at the point of use of the value it binds?

By @fire_lake - 3 months
Gleam looks nice but if an F# comparisons was added, I think that would come out ahead based on the authors priorities.
By @steve_adams_86 - 3 months
Wow, this is a great overview. I’ve been playing with Gleam a bit and this was really helpful. I’ll definitely refer to this later.

I’d like to dig into the OTP library (I’m curious if anyone has worked with it much?) and create a state chart library with it, but I’m still firmly in the “I don’t totally get it” camp with a few parts of Gleam. I don’t deny that it’s pragmatic. Maybe it’s more so that I’m not up to speed on functional patterns in general. I was for years, but took a hiatus to write code for a game engine and supporting infrastructure. It was so Wild West, but I kind of liked it in the end. Lots of impure, imperative code, haha.

By @beanjuiceII - 3 months
tried gleam but the fact i have to manually serialize/deserialize things, pretty annoying, that doesn't seem very pragmatic
By @Degorath - 3 months
I understand why the `use` syntax is preferable for its generalizability to many different "callback style" things, but the whole construct of `use foo <- result.try(bar())` is so much worse than defining let* in ocaml and being able to write `let* foo = bar() in`...
By @amelius - 3 months
> Running on the battle-tested Erlang virtual machine that powers planet-scale systems such as WhatsApp and Ericsson, Gleam is ready for workloads of any size.

Does a Gleam programmer in practice need to deal with Erlang? Do Erlang error messages leak through?

By @d--b - 3 months
Doesn’t it compare mostly to F#, rather than Haskell or OCaml? The examples in the post really look like F# to me
By @ogogmad - 2 months
Is there a way to implement matrix arithmetic with nice syntax (for instance, "A + B" to add two matrices A and B) in Gleam? The lack of ad-hoc polymorphism might paradoxically be a blessing.
By @vivzkestrel - 3 months
newbie here, how does gleam compare to golang, rust and python?
By @behnamoh - 3 months
It's not pragmatic if you have to import these basic libs:

```

import gleam/dict.{type Dict}

import gleam/int

import gleam/io

import gleam/result

import gleam/string

```

By @zombot - 3 months
The syntax doesn't look like it supports partial application? Big no-no. Also, no compilation to native code. Another big no-no.