Hacker News Reader

Comment by behnamoh | Hacker News Reader

I'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?

View on HN

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.

How is it hosted if you don't mind saying

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

Fair, but you usually don't run your project on both, unless you're writing a library.

Pick the target that makes sense for your project and stick with it :)

JS/TS isn't my favourite language, but it's pretty decent these days. If I'm picking a different language and targeting the web, it's probably because I want to run the same code natively as well.

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.

Same here, I've only been using it for a bit and have 100% been ignoring the JS part and the only time where I felt I needed to think about it for a moment was when I was writing a patch for someone else's code that did not ignore it, so basically when contributing to a library you might have to do extra work.

Of course I can't say if anyone ever made any decisions based on the other target that would have repercussions for me only using the BEAM.

Reply on news.ycombinator.com