Dang, when I made this silly, little comment about FP, I didn't expect to get corrected by a legend in the field!

Thanks for taking the time to respond.

Smalltalk (and Dart) also have "cascading" which is method chaining with special supporting syntax e.g. in ST you'd send four different messages to the same object with something like

    scene add: sprite; 
          add: otherSprite;
          setBackGround: stage;
          start

It's a style I really enjoy, and it's definitely not exclusive to one language or paradigm, exactly. I see it as more of less of a kind with pipelines in Unix shells, too.

In Scala, a language with OOP heritage and support, plus lots of functional programming features, some of the most common methods you use in such chains are monads.

Your point on unnesting is apt but don't you mean functor instead of monoid?

It is not abandoned, I am the maintainer. The documentation covers the APIs of the package but not the “zen” of the wider OTP framework, for that the official OTP documentation and existing books are recommended.

It is a very young language that may explain the why

Sorry, the end of my comment is quite reductive. Compiling to JS is pretty nice.

Don't be so modest!! You are the creator of the Gleam language as well.

Hi! Good to hear. Why it is not mentioned anywhere on the main site?

I believe go yields after every function exit. Erlang does the same, but there are no loops (you must use tailcall) so you can't lock up the CPU with a while(true).

It does. However, its actor implementation is not built upon Erlang/OTP, and currently is “experimental” and not even mentioned on the main site.

Hmm, it definitely looks more interesting in combination with effect handlers. Still not sure I find it super compelling in Gleam vs just not using callbacks.

That was way more than a solution for callback hell. With some plumbing, you could get Continuation monad working! With no further support from the language, too. I really miss LiveScript, it's a shame its development stopped. If only it could emit TypeScript, it would still have a chance to fight back, I think.

Ha, ok so I gotta give one of these "that's a really strange thing to get hung up on" responses.

Erlang and Elixir don't overload the `+` operator. In fact, they don't overload ANY operators. If you can forgive the syntactic choice of the operator itself (which I think it pretty fair considering Erlang predates Postgres by a decade and F# by two decades), this allows them to be dynamic while maintaining a pretty high level of runtime type safety. For example, one of the "subtle bugs" people refer to when criticizing dynamic languages (even strongly typed dynamic languages) is the following would work when both args are given strings or numbers:

    function add(a, b) { a + b }

    def add(a, b), do: a + b

One thing I hate about F# and SQL is that they use <> as a "not equals" operator. In Haskell, <> is the binary operator of any Semigroup instance.

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

Erlang doesn't use <> for concatenation so it's odd to name it in this comment, like that language and its developers have anything to do with your complaint. If it upsets you so much, lay it at the feet of the actual groups that chose <> for concatenation instead.

Well binaries are <<>> so that's consistent at least. And <<>> is quotation marks in several languages, including French.

I don't like languages that use > a lot simply because if I accidentally paste a code snippet in my Bash shell it is likely to pipe to some file.

Also, <> was != in BASIC, I believe.

PS: Don't paste this comment in your shell.

F# inherits <> from ML, which inherits it from Algol, which invented it. But that was actually a bad idea, since it deviates from mathematical practice. To follow math, it would be better to use != as in C and those inspired by it, or /= as in Haskell. Or maybe even =/= if you really want to go for the mathy looking notation.

Elixir uses <> as an operator for concatenation of binaries, (which does form a monoid of course), not to be confused with how Haskell uses <> as a binary operator of a Monoid, but for sure inspired by it. And Gleam picked it up from them, probably, to use for a special case of a list monoid, String. And Haskell created <> for Monoid, because it would be too confusing to use multiplication sign for the binary operation like mathematicians do. It would not be ok in programming context.

Then Gleam (and others) use “|>” when piping with “|” would make more sense, except that’s a bit wise OR, not to be confused with “||” which is… string concatenation (in Postgres).

All the more reason to include it in the comparison.

The creation of a list in the Gleam example is a choice, you could replace 'list' with 'iterator' and it would be lazy.

Or maybe your "no one else is smart/brave enough to say it" wrapper detracted from your message.

Additionally, throwing yet more syntax/features at a language to make it pseudo-functional doesn't appeal to everyone. A grab bag of features doesn't an appealing language make (for some).

C# is indeed adopting some functional techniques from F#, but C# is still so bogged down with imperative cruft that the resulting combination of styles is a mess.

Incredible, thank you so much! This is exactly what I need.

I agree. I've been trying to learn functional programming for years. My brain just doesn't get it. And I've actually built a non-trivial web app in Elm, and started trying to write one in Gleam and I was very very slow and unproductive. Eventually I gave up and wrote the whole thing in Go + TS for the frontend.

For Gleam I was trying to write the whole FE + BE in the same language - I really like that it can be compiled to JS, and I'm honestly sick of the whole React + seven thousand dependencies game, so I was using Lustre (an Elm-like library for Gleam). And again, I've programmed an app in Elm, after a lot of hair pulling, and in the end I didn't enjoy it that much.

I've gone through tutorials and I don't understand things like types having different wildly unrelated constructors, currying (I didn't notice much currying in Gleam but really disliked it in Elm, I cannot follow past the first or second arrow). For writing the front end of the app, I would make _zero_ progress unless referring to other Github projects (and it was hard to find any since Gleam was so new). Anyway, if someone has a book or something that can teach me this stuff it would be great. I want to use the OTP and a single language for FE/BE that's not JS. I'm not dumb, I've been programming since I was a little kid, but maybe I'm too stuck in imperative models.

Yeah FP can for sure take some getting used to before it clicks! I think a great resource for that is Gleam's Exercism track (https://exercism.org/tracks/gleam), not only will it teach you the language but by starting with small-ish exercises it can definitely help grokking FP concepts

And if you feel like you're stuck and need help Gleam's Discord is a great place to ask questions :)

i dont think manual ser/de is common at all, and languages like dart where it was used is a massive pain point for people so much that they are adding macros to the language and the first macro they add is for serialization. whats not explicit about saying hey i have a struct this is the data i expect, serialize/deseralize in this shape, validation is a another but separate concern. in javascript you are not doing anything manually so i'm not sure why thats an example?

You either trust the input or you don't. If you don't trust your input you need validation like Zod anyway. Parsing untrusted data without validation in Rust or Go is not much better than in JS. You get the basic types checked, but that's all. You need to validate at the boundaries with Rust or Go just the same as with JS. It seems to me that many bloggers of new trendy languages are not aware of validation. A value for name is a string, but how about the length?

Could you say something about the cases where you did need to write Erlang code?

What kind of cases? Were you already proficient in Erlang and its ecosystem?

That, ah, doesn't quite answer the question about error messages.

I believe the comparison to C# is incorrect. Given what the article highlights, the direct competitor to Gleam is going to be F#. By virtue of using .NET, it offers an order of magnitude better performance, significantly cheaper per-process/task cost and equally capable overall concurrency primitives. A much bigger ecosystem with many polished libraries too.

I'd rather use an external job scheduler and message queue, eg in kubernetes, rather than build it into the language runtime. With a message queue and horizontal pod autoscaling you can very quickly build an easy distributed workload with (at least to me) little effort in any language

I can understand having to import the "dirty" parts of the stdlib, like I/O, or the "heavy" parts, like Unicode or timezones. But why force someone to import every single type? Most functional languages have a prelude that covers the types every non-trivial program uses: booleans, numbers, strings, collections.

It's not that it's wrong—at least I don't think so. It's that it's an example of a choice that is not pragmatic.

I suppose we should agree on what "pragmatic" even means, since it has become something of a cliché term in software engineering. To me, it roughly means "reflective of common and realistic use as opposed to possible or theoretical considerations".

So is having to import basic functionality a pragmatic design? I would argue no. Having to import basic functionality for integers, strings, and IO is not pragmatic in the sense that most realistic programs will use these things. As such, the vast majority of ordinary programs are burdened by extra steps that don't appear to net some other benefit.

Importing these very basic functionalities appeals to a more abstract or theoretical need for fine-grained control or minimalism. Maybe we don't want to use integers or strings in a certain code module. Maybe we want to compile Gleam to a microcontroller where the code needs to be spartan and freestanding.

These aren't pragmatic concerns in the context of the types of problems Gleam is designed to address.

To give a point of comparison, the Haskell prelude might be considered a pragmatic design choice, as can be seen from the article. It is a bundle of common or useful functionality that one expects to use in a majority of ordinary Haskell programs. One doesn't need to "import" the prelude; it's just there.

I don't personally find Gleam's design choice a bad one, and while GP was a bit flippant, I do agree that it is not an example of a pragmatic design choice.

It's the namespace that belongs to the core team. It couldn't be just `string` etc as that would collide with existing Erlang modules.

Other Gleam libraries will use other namespaces.

EDIT: quick note, this is a tangent; Gleam does support partial application with `_` and it works with pipelines as well.

> This is not how it works in curried languages, however. In curried languages with a |> operator, the first expression still returns "Hello, World!" but the second one returns "World!Hello, " instead. This can be an unpleasant surprise for beginners, but even experienced users commonly find that this behavior is less useful than having both of these expressions evaluate to the same thing.

The upside (on the curried side) is that you can define `|>` as a normal function (even without lazy semantics, as in OCaml.) How much of an "upside" this is will vary, but note that this generalizes to many other operators that can be added. The rest is a matter of API design, i.e., the order of arguments and the use of named arguments (and/or other syntax sugar.) For example, in the case of the post's example:

    "Hello, "
    |> Str.concat "World!"

    "Hello, "
    |> Str.concat ~rest:["World!"]

    - infix macros
    - infix functions in curried languages
    - special, hardcoded |> operator
    - beating your language black and blue until you get a work-alike (like with implicits in Scala)

I don't even think curried functions by default is a good idea, but that article really made me support them. Richard Feldman is usually so reasonable, what happened? That's the worst argument I've seen in a while.