Hacker News Reader

Comment by Ndymium | Hacker News Reader

Which part do you feel like would be an issue? When you run `gleam compile`, it will automatically call the Erlang compiler to finish the job.

I find it very handy that the intermediate Erlang (or JS) files are available in the build directory. It lets you easily see what form your code will take when compiled.

View on HN

Also prevents lock-in if you ever need to move away from gleam.

I don't think it's the transpile part that would the issue, it's the runtime aspect. If Gleam transpiles to Erlang/Javascript that's great but once you run the program, you have to potentially deal with runtime issues specific to those environments which you might not be familiar with.

It seems that Gleam is really useful for those who are already in either the Erlang/Javascript ecosystem.

On the contrary, it's a great first BEAM language to learn because of it's simplicity - both in terms of the grammar as well as it's tooling/compiler.

For me personally, the Javascript target is the least interesting bit - the BEAM/Erlang target is where it's at for backend work. The BEAM is fascinating and full of ideas that were once ahead-of-their-time but now are really coming into their own with compute performance having caught up.

Gleam is a strongly typed language, and is unapologetically very functional. Error handling in general is quite different than it would be on a normal stack-based language/vm. In my experience, the Erlang target doesn't make debugging any harder or more difficult than you would expect for an exception-less language.

The JS target is also very interesting to me. I like erlang fine and elixir's nascent type system is promising. But the frontend (and js fullstack for that matter) currently does not have a good alternative to typescript, and the ML type system is an especially good fit for it. Elm has too much reputational baggage and rescript/reason/bucklescript/whatever squandered its momentum and is floundering.

Very much so!

I've created Vleam[0] to convert an existing vue webapp[1] and so far it's a joy.

[0]: https://github.com/vleam/vleam

[1]: https://blog.nestful.app/p/why-i-rewrote-nestful-in-gleam

Another layer of abstraction, another thing to go wrong, another thing to rot.

But, you need a runtime. If Gleam had its own runtime, that would be another layer in a similar vein. Here Gleam is using Erlang (or a JS runtime) which is bound to be more supported and have a longer lifetime than something they cooked up themselves.

Besides, Gleam's original aim was basically "Erlang but static types", so the choice of Erlang as runtime was always there.

Reply on news.ycombinator.com