I'm curious to know what the parent meant, as well. My understanding, which is incomplete admittedly, is that Gleam's type system lives in Gleam and isn't carried over into the produced Erlang/BEAM code, since BEAM has no concept of types, etc.

Gleam also has an OTP implementation[1] available, which includes Actors and the like. My understanding is that every BEAM language must implement OTP themselves, so there's nothing unusual here.

[1] https://hexdocs.pm/gleam_otp/

Gleam's type system is the root cause of the problem. Please see my reply to the parent of your post.

It has been a while since I looked at Gleam. Some things may have changed. However, the last time I used Gleam, I was forced to switch back to Elixir because Gleam:

• Lacks support for named processes.

• Has limited actor abstractions.

• Doesn't support OTP system messages.

• Has implemented supervisors in a way that can lead to improper shutdowns, data loss, and deviations from the expected BEAM behavior.

• Doesn't support pattern matching directly in function definitions. Instead, it requires you to use case statements.

• Doesn't support global mutable variables because it has no way to track variable types and state changes when BEAM modifies these variables, which is one of the hallmark features of BEAM.

• Doesn't support hot code reloading.

All of these features, which are readily available in Erlang and Elixir, are far more important to me than static typing. I've used statically typed languages like C, C++, C#, and Java, and dynamically typed languages like Python, Ruby, and Elixir throughout my 30+ years career. I've never once lamented not having static types, nor have I ever jumped for joy when I do. For me, static vs. dynamic typing is largely irrelevant and doesn't affect my work one way or the other.