What is the current status quo of using processes in Gleam? When I've looked, the language tour doesn't even get to anything about processes, messaging, or OTP. I found it here https://hexdocs.pm/gleam_otp/0.1.1/index.html by searching Google, but it seems like it's almost an afterthought.
I'm curious if I've had the wrong impression of Gleam. My assumption was that it was bringing static types to the BEAM's processes and OTP, but it seems like it's mainly a statically typed language that just happens to be on the BEAM and that it isn't necessarily looking to solve the "static type the messages" in Erlang and Elixir. Is that correct?
I'm not saying either way is bad or good. I'm just trying to get a sense of the language's origins and where it's going compared to Elixir and its gradual typing story. For example, if I know and like F#, Elixir, and Rust, what is the selling point of Gleam?
Note that you linked to the 0.1.1 version of the gleam_otp documentation. The latest version resides at https://hexdocs.pm/gleam_otp/index.html and both gleam_erlang and gleam_otp have hit 1.0.0 already. It doesn't contain every feature yet (like dynamic supervisors) but it's usable (and I've rolled my own dynamic supervisor in the meantime).
It's all production ready and in use by businesses and open source projects today!
The language tour covers _the language_ rather than the concurrency framework, so you'd look to the Erlang and Gleam OTP documentation to learn about the framework. Erlang and Elixir have a similar documentation split, for example, the most popular book teaching Erlang, LYSE, has the first half about the language and the second half about the framework.
> it seems like it's mainly a statically typed language that just happens to be on the BEAM and that it isn't necessarily looking to solve the "static type the messages" in Erlang and Elixir. Is that correct?
Not quite! Gleam does have a type-safe derivate of the OTP framework, while maintaining full compatibility with the original untyped OTP. When writing a Gleam application that runs on the Erlang VM you will be using typed actors and messages.
> I'm just trying to get a sense of the language's origins and where it's going compared to Elixir and its gradual typing story.
Elixir and Gleam's respective type systems are about as different as you can get while still being type systems. The difference is so large that they offer completely distinct advantages and development experiences, so people who especially value and enjoy one are unlikely to find the other to their liking. I believe this is a real strength! It means that the BEAM ecosystem offers a wider range of programming styles, and so it can attract and serve a wider range of developers, growing the ecosystem as a whole. BEAM languages work together closely.
> if I know and like F#, Elixir, and Rust, what is the selling point of Gleam?
I could give you a list of technical benefits to picking Gleam, but really I think this sort of technology choice is very personal. You may find Gleam to be a language that you enjoy and are productive with, and if that's the case then it's a great tool for you! Your use of Rust, F# suggests you'll appreciate the programming style, and your use of Elixir suggests you'll appreciate using the same BEAM runtime, so perhaps give it a try.
The reason it's not in the language tour is because it's not part of the language itself. There's no async specific syntax or feature in the language itself. They all depend on the target since gleam can compile to erlang or javascript. If you compile to erlang you can use gleam_erlang and gleam_otp to leverage OTP. If you compile to javascript you use gleam_javascript and have to work with promises. It's definitely not just an afterthought and gleam_otp recently had a big 1.0 update.
Processes are part of the languages Elixir and Erlang.
They are primarily part of the BEAM which all these languages leverage. :)