Hacker News Reader

Comment by cedws | Hacker News Reader

I've been interested in Gleam, but I didn't realise it just transpiles to Erlang, I thought it compiled directly to BEAM bytecode. Bit of a turnoff to be honest, I really don't want to deal with transpilation.

View on HN

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.

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.

Gleam used to compile to Core Erlang (Erlang Intermediate Representation) but looks like it now compiles to pretty-printed Erlang.

https://blog.lambdaclass.com/an-interview-with-the-creator-o...

The relevant quote:

> The Gleam compiler has had a few full rewrites. The previous version compiled to BEAM bytecode via Core Erlang, which is an intermediate representation with the Erlang compiler, but the current version compiles to regular Erlang source code that has been pretty-printed. This has a few nice advantages such as providing an escape hatch for people who no longer wish to use Gleam, and enabling Erlang/Elixir/etc projects to use libraries written in Gleam without having to install the Gleam compiler.

Pretty good reasoning in my opinion.

It makes perfect sense to target erlang and not BEAM directly as allows erlang compiler to optimize the code for the newer BEAM runtime with newer fancier opcodes.

Yes, unfortunately transpilation comes with real downsides. Up until recently, logger events, error messages and stacktraces were displayed in Erlang formatting. It has improved in few cases, but not all, and the line numbers in stacktraces do not align with the source code. And if you want to use a REPL, you must use Erlang/JS ones, etc.

Although if you want to get into Erlang/BEAM and static types are a requirement, I still strongly recommend checking it out. :)

This is fine in practice as unexpected runtime errors are rare in Gleam. I’ve yet to have any in any and I’ve been using it in production for years.

It would be great if the BEAM had a source map like system so it can have the same high quality runtime errors and debugger support that JS has, but I think that’s unlikely to ever happen.

A REPL would be nice, but there hasn’t been enough demand to motivate any work so far. Language server features are overwhelming the majority of demand when it comes to tooling.

What do you mean by deal with transpiration? Elixir and LFE also both compile to Erlang and then run the BEAM compiler to generate bytecode. Erlang is the only BEAM language which goes to bytecode directly today.

Transpilation usually refers to the fact the target of your compiler is another language source code, which then has to be parsed again. Which leads to issues such as mismatched lines in stacktraces at runtime. Elixir and LFE use the same compiler tooling as Erlang, but the source is parsed just once, and all line information pertains to the original Elixir/LFE source code.

Gleam also uses that same compiler tooling, though it does not embed the line information presently.

Yes, it all goes through the same pipe, but we enter the pipe through different places, which leads to different outcomes. You get different limitations and results depending if your input is Erlang source (Gleam), Erlang AST (Elixir), or Core Erlang AST (which is what LFE used in the past but I am not sure if it is still the case).

Exactly! Beyond line numbers in stack traces it’s all the same.

Reply on news.ycombinator.com