Thanks to the Erlang runtime Gleam is very reliable in production, and I know of two companies that use it in production, one of which use it as their primary language.
The main problem is that it’s a very new ecosystem, so there’s a shortage of documentation and libraries. You’ll likely be using Erlang or Elixir libraries a lot, so it helps to be familiar with them.
Straightforward interop is one of the main goals of Gleam, and we’ve had great success. Interop between Gleam and Erlang in my opinion works better than interop between Erlang and Elixir for example. It’s very easy to use Gleam from other BEAM languages and to use other BEAM languages from Gleam.
As an Erlang library OTP is very usable, and we have our own type safe version of OTP that is fully compatible.
Ecto, Phoenix, and LiveView are not fully usable from other BEAM languages because they make heavy use of Elixir’s metaprogramming features. This is a shame, but it is out of our control. They are not usable from Erlang either.
It is possible to use Gleam (or Erlang) alongside them though, so long as Elixir glue code is used to interface with them directly. This game emulator project has the virtual machine written in Gleam with the UI written in LiveView + Pheonix.
Additionally I think Gleam can do better than Ecto and Phoenix. They are untyped, while a future Gleam alternative would be fully type safe.
Albeit not being pure, does it have holes or partial functions in the type system? Or every function is safe and every error detected at compile time?
There are no crashing functions in the standard library, though like in Elm is it possible to write functions that diverge by creating an infinite loop.
You can write functions that crash using the
assert keyword if you want to opt-in to the Erlang behaviour.
Exhaustiveness checking is still WIP but once we have that we will have the same level of safety as Elm,
Do you work full time on the project?
I have done for a year or two, but recently I ran out of money and had to find employment.