The main reason for using a BEAM language is to leverage multicore/concurrency conveniently and reliably. Gleam's OTP seems not as mature as that of Erlang or Elixir. If you want to write simple programs, then Gleam seems okay. If you want mature multicore or concurrent use, then I would think twice.
Here is a critical review of the officially listed limitations of Gleam's OTP:
1. Lack of Support for Named Processes: This is a significant limitation because named processes are essential for easy reference and communication between different parts of the system. Without support, developers might resort to workarounds that could lead to errors and inefficiencies.
2. Untyped Global Mutable Variables: The use of untyped global mutable variables introduces potential risks, such as runtime errors and unpredictable behavior, especially since they can be uninitialized. This undermines the type safety and reliability generally expected in functional programming environments.
3. Limited Actor Abstractions: The current scarcity of actor abstractions could restrict developers from implementing more complex or varied concurrency patterns, limiting the utility of the library until more abstractions are added.
4. Unsupported OTP System Messages: Dropping unsupported system messages can lead to unexpected behavior and bugs that are difficult to trace. Full support for OTP system messages is crucial for reliable and predictable actor-based concurrency.
5. Uniform Shutdown Period for Supervisors' Children: Not having different shutdown periods for child processes, especially for child supervisors, can lead to improper shutdowns and potential data loss or corruption. This deviates from the behavior in Erlang and Elixir, where more granular control is available.
6. Limited Testing: The lack of extensive testing, both in unit tests and real-world applications, indicates that the library might be unstable or have undiscovered bugs. This could affect its adoption and reliability in production environments.
Here is a critical review of the officially listed limitations of Gleam's OTP:
1. Lack of Support for Named Processes: This is a significant limitation because named processes are essential for easy reference and communication between different parts of the system. Without support, developers might resort to workarounds that could lead to errors and inefficiencies.
2. Untyped Global Mutable Variables: The use of untyped global mutable variables introduces potential risks, such as runtime errors and unpredictable behavior, especially since they can be uninitialized. This undermines the type safety and reliability generally expected in functional programming environments.
3. Limited Actor Abstractions: The current scarcity of actor abstractions could restrict developers from implementing more complex or varied concurrency patterns, limiting the utility of the library until more abstractions are added.
4. Unsupported OTP System Messages: Dropping unsupported system messages can lead to unexpected behavior and bugs that are difficult to trace. Full support for OTP system messages is crucial for reliable and predictable actor-based concurrency.
5. Uniform Shutdown Period for Supervisors' Children: Not having different shutdown periods for child processes, especially for child supervisors, can lead to improper shutdowns and potential data loss or corruption. This deviates from the behavior in Erlang and Elixir, where more granular control is available.
6. Limited Testing: The lack of extensive testing, both in unit tests and real-world applications, indicates that the library might be unstable or have undiscovered bugs. This could affect its adoption and reliability in production environments.