He described a problem people use monads to solve, not monads themselves.

Haskell people do talk about monadic vs. applicative combinators that are different by whether you can use the results of a previous step on the next ones. But that doesn't have a direct relation with the actual definition of those.

But yes, if you are teaching a programming language that uses monads to someone, you will probably want to explain the problem they solve, not the actual structures. As most things in math, the structures become obvious once you understand the problem.

Not really. The big important part of monads is flattening/unnesting the output.

Basically, if you can convert a `Foo<T>` into a `Foo<U>` by applying a function `T -> U`, it's a monoid. Think `map` or `fold`.

But if you can convert a `Foo<T>` into a `Foo<U>` by applying a function `T -> Foo<U>`, it's a monad. Flattening is "some logic", but not any logic, it's inherent to `Foo<>` itself.

No, this isn’t a good description of monads. It merely describes a case that shows up sometimes.

Yin the OOP world I’ve seen this pattern called chaining : usually either method or object chaining.

One thing I dislike with erlang based languages (both gleam and elixir) is that they use “<>” for string concatenation.

In F#, “<>” is the equivalent of “!=“. Postgres also uses <> for inequality so my queries and f# code have that consistency.

The author links to a blog post talking about railway oriented programming in f#.. it might be fair to assume they are aware of f#

I converted the example on the Gleam home page [0] to F#:

    let spawn_task i =
        async {
            let n = string i
            printfn $"Hello from {n}"
        }

    // Run loads of threads, no problem
    seq { 0..200_000 }
        |> Seq.map spawn_task
        |> Async.Parallel
        |> Async.RunSynchronously
        |> ignore

[0]: https://gleam.run/

I brought up the next logical step in pragmatism, which is that c# is adopting a lot of f# things and hence on a solid path to becoming the pragmatic language du jour, however my comment is currently at -4, probably flagged. To be fair I did skip a half-step. Maybe rabid fanboys but unlikely, probably just passionate posters that don’t see where things are headed.

It is syntax sugar for CPS [1].

[1]: https://en.wikipedia.org/wiki/Continuation-passing_style

EDIT: I believe prior art is Koka's with statement: https://koka-lang.github.io/koka/doc/book.html#sec-with

It really reminds me of LiveScript's "back-calls" [1], which were a solution for callback hell in JS.

1: https://livescript.net/#:~:text=Backcalls%20are%20very%20use...

The equivalent in F# is let! (F# computation expressions are quite powerful); in rust the ? operator. Other languages have similar features.

It's syntactic sugar, but the readability is worth it

You can do something similar in OCaml (as an operator defined at the library level, not a specialized new syntax): https://github.com/yawaramin/letops/blob/6954adb65f115659740...

Everything after the line containing '<-' happens in a callback.

Since it's a callback, I assume it's up to the function whether to call it, when to call it, and how many times to call it, so this can implement control statements.

I would guess that it also allows it to be async (when the callback isn't called until after an I/O operation).

I think it's similar to koka's 'with'.

https://koka-lang.github.io/koka/doc/book.html#sec-with

Most people use the OTP lib! There's this super useful intro repo: https://github.com/bcpeinhardt/learn_otp_with_gleam

I've tried to get my head around functional programming and also OTP but I also just never got my head around it.

Functional programming seems too limiting and OTP seems more complicated than I would have hoped for a supposedly distributed concurrency system.

I'm sure it's just a skill issue on my part. Right now I'm way too rust-brained. I've heard lots of things about gleam being good for productivity but I don't feel unproductive writing web apps in Rust but I felt every unproductive trying to write a non-trivial web app in gleam

Isn’t manual ser/de pretty common? I like it personally. Being explicit at program boundaries usually means far fewer bugs inside the program. In JS I can pile whatever JSON I want into an object, but eventually I need to throw Zod or something at it to tame the crazy.

Maybe a generic “pile this data into this value and pretend it’s safe” tool might be nice for prototyping.

I agree that the stdlib decoder functions aren't the most ergonomic, but I think people are aware it's a pain point and there is development in that are, these two packages for example:

https://hexdocs.pm/decode

https://hexdocs.pm/toy/

This is one of the complaints people have with Elm too. Json.Encode/Decode is a pain

This is the biggest reason I cooled a bit on Gleam and whenever I want to do some backend stuff I'd much rather use Rust (using serde to convert to structs) or Elixir (put it in dynamic maps).

I wish Gleam would implement some kind of macro system, making a serde-like package possible.

This is exactly what I want from Gleam. It does seem to be under documented and abandoned. Is there any understanding of why? Like you say, this seems like a super power. I see so much potential. A language that’s ergonomic, pragmatic as the author says, great performance, low-ish barrier to entry, etc. It seems like it could be an awesome tool for building highly reliable software that’s not so difficult to maintain.

this is Gleam OTP package https://github.com/gleam-lang/otp

I agree it's underdocumented but doesn't seem abandoned (has commits in last week)

Are there any articles that do a deeper dive into this? I ask because straight up I've been curious about Gleam, but not enough to do a really deep dive because Elixir is too good and, like Erlang, is a very special kind of dynamic language that doesn't leave me feel too lacking.

As I understand it, there have been a few "high profile" attempts to bring static typing to Erlang, all of which gave up when it came to typing messages. Your comment essentially confirms my bias, but is Gleam making real strides in solving this, or is it poised to merely cater to those who demand static-typing with curly braces--everything-else-be-dammed?

I understand things best by comparing across different languages so don’t take this the wrong way but I wonder if you can help me understand: If say I start a goroutine in Go and give it a channel to use as a mailbox, concurrency in Go is cooperative but it’ll automatically use OS threads and yield whenever it reads from the channel. Does Erlang/OTP do something different? If so what does it do and what are the advantages? Or is it more that the library and ecosystem are built around this model?

Gleam runs on the BEAM

Why not?

What's wrong with a standard library the bits of which you want you choose to import?