On the point of whether type-safety and “let it crash” can coexist… in my experience Erlang and Elixir are different from some other dynamic languages that make it easy to miss logical bugs, through the pervasive use of structural bindings and in-band error reporting. The typical Erlang/Elixir program is very dense with destructuring which means error locality is much better than something like Python or Ruby, where wrongly shaped data can live quite long before reaching a spot where an assumption fails. The very cool work happening in the Elixir compiler these days bringing stricter type checking to existing Elixir programs without modification of program text is broadly possible because of this feature of the language design.
My takeaway after trying out Gleam (as a heavy Elixir user) was that Gleam solves problems that BEAM users don’t really have, using tools that non-BEAM-users may find inaccessible in their native languages. I agree with OP that it’s going to be really interesting to see how this dynamic evolves over time.
as a hitherto non-BEAM user who has tried out Gleam a bit now, coming off of spending a bunch of time on a couple Haskell projects, I sort of have the OTP stuff as a thing that’s in the background as a thing I could try sometime but so far BEAM is an implementation detail that I am assuming is somehow making stuff like the web server I’m using more robust. But as I’m becoming increasingly a type dork, I always want to be able to build my programs around ADTs. And yet for various reasons I have so far avoided trying to write servers in Haskell. Gleam’s choices to be impure (no monads, no managed effects [for now?]), uncurried, and discourage ML/Haskell things like point-free style are all slightly vexing to me, but they seem like sensible choices for Gleam.
So to me I think the proposition of the language (as distinct from what lpil might subjectively intend) is not something like “bring a good language to the BEAM finally” it’s more like exploring a particular point in the ML-family design space that is closer to what a Ruby or Python web dev might find immediately comprehensible. Running on the BEAM is nice but is not essential to what the language is. (Indeed, trivially so, b/c it targets JS also, including browsers.)
lpil commented somewhere that they see additional targets for Gleam (beyond BEAM and JS) as something that’s unlikely to be prioritized for the next decade. I am sure stabilization of gleam/otp is coming and even before that I think I will want to give actors a try. I’m not smart enough for most concurrency models but I think I can understand passing typed, immutable messages between actors.
As another recovering Haskller, Gleam sort of has do notation. The use keyword is essentially the continuation monad, which can of course implement any other monad. Truth be told, it was seeing the use keyword that made me try Gleam in the first place.
Obviously, it’s not exactly the same as having first class support, but it’s closer than any other languages I’ve tried (caveat that I have not tried OCaml yet).
Very interesting article, I did not know that the OTP part of Gleam is not stable.
I had to search what is require_method in the use example. It’s not defined in the blog post and the Gleam documentation also introduces its usage before its definition.
This is the first time I’ve heard of such a programming language. It’s somewhat similar to Rust and, as I see it, unlike Erlang, it doesn’t have atoms, but I could be wrong, but I don’t see them. The article in the “erlang interop” section talks about this, I think
On the point of whether type-safety and “let it crash” can coexist… in my experience Erlang and Elixir are different from some other dynamic languages that make it easy to miss logical bugs, through the pervasive use of structural bindings and in-band error reporting. The typical Erlang/Elixir program is very dense with destructuring which means error locality is much better than something like Python or Ruby, where wrongly shaped data can live quite long before reaching a spot where an assumption fails. The very cool work happening in the Elixir compiler these days bringing stricter type checking to existing Elixir programs without modification of program text is broadly possible because of this feature of the language design.
My takeaway after trying out Gleam (as a heavy Elixir user) was that Gleam solves problems that BEAM users don’t really have, using tools that non-BEAM-users may find inaccessible in their native languages. I agree with OP that it’s going to be really interesting to see how this dynamic evolves over time.
as a hitherto non-BEAM user who has tried out Gleam a bit now, coming off of spending a bunch of time on a couple Haskell projects, I sort of have the OTP stuff as a thing that’s in the background as a thing I could try sometime but so far BEAM is an implementation detail that I am assuming is somehow making stuff like the web server I’m using more robust. But as I’m becoming increasingly a type dork, I always want to be able to build my programs around ADTs. And yet for various reasons I have so far avoided trying to write servers in Haskell. Gleam’s choices to be impure (no monads, no managed effects [for now?]), uncurried, and discourage ML/Haskell things like point-free style are all slightly vexing to me, but they seem like sensible choices for Gleam.
So to me I think the proposition of the language (as distinct from what lpil might subjectively intend) is not something like “bring a good language to the BEAM finally” it’s more like exploring a particular point in the ML-family design space that is closer to what a Ruby or Python web dev might find immediately comprehensible. Running on the BEAM is nice but is not essential to what the language is. (Indeed, trivially so, b/c it targets JS also, including browsers.)
lpil commented somewhere that they see additional targets for Gleam (beyond BEAM and JS) as something that’s unlikely to be prioritized for the next decade. I am sure stabilization of
gleam/otpis coming and even before that I think I will want to give actors a try. I’m not smart enough for most concurrency models but I think I can understand passing typed, immutable messages between actors.As another recovering Haskller, Gleam sort of has
donotation. Theusekeyword is essentially the continuation monad, which can of course implement any other monad. Truth be told, it was seeing theusekeyword that made me try Gleam in the first place.Obviously, it’s not exactly the same as having first class support, but it’s closer than any other languages I’ve tried (caveat that I have not tried OCaml yet).
Yah I should’ve written “no IO monad”
In your code snippets some of the capital letters (outside of strings) are coloured a dark red.
eg in “F” and “I” in the following bit of code
Is that a quirk of the syntax highlighter? If not then what does it indicate?
I know, it’s a bug in chroma, or rather in chroma’s Gleam spec (reported here)
Very interesting article, I did not know that the OTP part of Gleam is not stable.
I had to search what is
require_methodin theuseexample. It’s not defined in the blog post and the Gleam documentation also introduces its usage before its definition.This is the first time I’ve heard of such a programming language. It’s somewhat similar to Rust and, as I see it, unlike Erlang, it doesn’t have atoms, but I could be wrong, but I don’t see them. The article in the “erlang interop” section talks about this, I think