Gleam is really interesting to me, because it's built on top of the BEAM runtime, but as far as I can tell, it does very little with the actor model that is the star attraction of BEAM/Erlang. There's a (non-built-in?) package that exposes some of the OTP and concurrency tools available, but it doesn't look widely used or recommended on the website. The linked recommends a talk that I hadn't seen before (and unfortunately can't watch right now on my phone!) but other than that there seems to be very sparse documentation available. Searching for "gleam OTP" mainly seems to produce a myriad of alternative OTP implementations and not much in the way of explanations or examples of common patterns or anything like that.

Some of this is obviously going to be the newness of Gleam, but I remember when Elixir was still brand new, and the OTP integration was one of the biggest selling points there, and a big part of their documentation and the ecosystem in general. Whereas with gleam, it almost seems like they're embarrassed of the runtime's distributed heritage? Whereas to me it seems like the OTP and the actors model in general would be the biggest selling point for a language like this.

Does anyone have any insight into why this is, or what concurrency practically feels like in gleam?

▲

widdershins 2 days ago | parent | next [-]

The OTP package is not built-in because that would prevent Gleam being compiled to other targets, namely Javascript. This is a big draw for the language, and it's worth pulling out BEAM-specific stuff into packages for this reason.

I think Louis and the Gleam community are very serious about supporting OTP, but there are still open research questions around typing parts of OTP.

The parts of OTP that Gleam supports are still very useful, compatible with Erlang/Elixir, and very much used. And they have the benefit of being statically typed [1].

There's no embarrasement about Gleam's primary runtime being the BEAM, it's right there on the front page, above the fold! [2]

[1] https://github.com/bcpeinhardt/learn_otp_with_gleam [2] https://gleam.run/

▲

throwaway920102 2 days ago | parent | prev | next [-]

Because Gleam compiles to Erlang, it can seamlessly integrate with the larger BEAM ecosystem, including existing Erlang and Elixir OTP applications and libraries.

@external decorator: This escape hatch allows Gleam code to call functions defined in Erlang or Elixir modules. While it bypasses Gleam's type checks for the function call, it provides a powerful way to leverage the full capabilities of the existing OTP ecosystem.

I believe the biggest reason it's hard to replicate OTP fully and quickly is Gleam's type system (but I could be wrong).

▲

worthless-trash 2 days ago | parent | prev | next [-]

From my understanding distributed (cross machine) typed message passing is hard.

	▲	MrJohz 2 days ago \| parent [-]
		Doesn't Erlang/Elixir solve this by having every function do its own parsing (via pattern matching) and then failing fast if something goes wrong? That seems intuitively like a good approach to take — you can't make any real guarantees across machine boundaries, but you can use structural typing at the edges to ensure that the data coming across the boundaries has the right shape.

▲

drekipus 2 days ago | parent | prev [-]

They want to keep otherlangs as a compile target