Comment by behnamoh

My “intro to gleam” was a lustre form for my blog, where people could submit feedback. So I was able to create a neatly separated client module in Gleam and compile it to JavaScript so I can insert it in my static blog page. The server part was a separate gleam module with erlang as a target. They shared models and some constants with a “shared” module - just like the tutorial.

I find this kind of explicit separation very powerful. It also removes some of the anxiety if something will end up in a client bundle when it’s supposed to be server only.

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

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.