> 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.
show comments
skybrian
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?
show comments
amelius
> 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?
show comments
patte
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...
Gleam looks nice but if an F# comparisons was added, I think that would come out ahead based on the authors priorities.
show comments
rossng
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?
show comments
steve_adams_86
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.
show comments
beanjuiceII
tried gleam but the fact i have to manually serialize/deserialize things, pretty annoying, that doesn't seem very pragmatic
show comments
atemerev
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.
show comments
d--b
Doesn’t it compare mostly to F#, rather than Haskell or OCaml? The examples in the post really look like F# to me
vivzkestrel
newbie here, how does gleam compare to golang, rust and python?
behnamoh
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
```
show comments
zombot
The syntax doesn't look like it supports partial application? Big no-no. Also, no compilation to native code. Another big no-no.
> 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.
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?
> 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?
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
Gleam looks nice but if an F# comparisons was added, I think that would come out ahead based on the authors priorities.
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?
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.
tried gleam but the fact i have to manually serialize/deserialize things, pretty annoying, that doesn't seem very pragmatic
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.
Doesn’t it compare mostly to F#, rather than Haskell or OCaml? The examples in the post really look like F# to me
newbie here, how does gleam compare to golang, rust and python?
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
```
The syntax doesn't look like it supports partial application? Big no-no. Also, no compilation to native code. Another big no-no.