alt Hacker NewsI'd rather them stick with ONE: JS or BEAM. Everytime a project claims it can do multiple things at once, it can't do either very well.
It's confusing too. Is Gleam suitable for distributed computing like Elixir/Erlang on BEAM? Would that answer change if I compile it to JS?
Replies
Gleam is technically as suitable for distributed computing as Erlang: since it compiles to Erlang, it can do anything that Erlang can. You can use Erlang and Elixir libraries and write FFI code to do things that would be unergonomic to do in Gleam. Sure the experience is different and if you want to embrace the guarantees of static typing, then the APIs will look different, like gleam_otp.
If you compile it to JS, then the guarantees change to JS's guarantees.
Personally I've felt that the JS target is a big plus and hasn't detracted from Gleam. Writing a full stack app with both sides being in Gleam and sharing common code is something I've enjoyed a lot. The most visible impact is that there's no target specific functions in the stdlib or the language itself, so Erlang related things are in gleam_erlang and gleam_otp, and e.g. filesystem access is a package instead of being in the stdlib. If you're just into Erlang, you don't need to interact with the JS target at all.
I've used gleam for a toy project in uni, and AoC
My main friction point is that the Int type maps to different concepts in erlang and js
In erlang it's a arbitrary precision Int
In js it the js number type, which is a 64bit float iirc.
Also recursion can hit limits way sooner in js.
For me, my code rarely ran in both js and erlang. But could be skillissue