hckrnws
This is an interesting writeup, albeit not quite what I was hoping for. I love Elixir and have been following Gleam for a while now, so I clicked through hoping this was talking about Gleam baking this into their ecosystem a bit better. I was a little disappointed to see it's ultimately talking about how to build a Gleam project and then use the resulting build ecosystem to create a binary (Gleam -> JS -> JS build tool, or Gleam -> escript -> elixir-burrito).
It would have been interesting to see some high level commentary from the author on the results of each one on top of the general workflow. Build time, binary size, startup time, whatever.
I am theoretically in love with Gleam - it ticks so many boxes. However, I really want to be able to make CLI applications...packaging up JS is not it.
I saw there is an early stage WASM project[0] which has me hopeful. Performance is not a requirement - equivalent to Python is totally fine, I just want that beautiful Gleam syntax.
Rightly or wrongly, I'd like to see Gleam as a Go competitor for Web apps and CLI apps.
Unfortunately, easy cross-compilation to relatively static binaries is a "must" for me. Now that Go gives it to me, I won't really entertain a competitor that doesn't provide a "static build" option.
So I'm glad to see this exists, even though it looks pretty janky!
I did it with Tauri. ~14MB Windows, macOS, and Linux exe, browser app, iOS, and Android.
Would be great to be able to seamlessly bundle a Gleam app for the Erlang target alongside the BEAM in a single binary, like Burrito but without the extra Elixir code. The BEAM is smaller than most JS engines, you could get a binary of 30-40 MB I believe -- still a fair amount, but much smaller than bun/deno compile.
ratio of upvotes to comments is oddly high...
bUn Is NoT "FaSTeR" tHan NoDe #5732368444
Crafted by Rajat
Source Code