lpil

No AST was ever used for that. Printing algebra was used in the past, and the new Erlang binary and textual generators both work by appending to a buffer. Your assertion that we need an AST has never been correct. From my point of view it would be wasteful and slow for the compiler to construct this AST just to then consume it to push bytes to a buffer.

RE punctuation, the book-keeping required for the binary format is no less work than for the textual format. All these formats are similarly easy to implement, though the ones that are not human readable are more challenging to debug.

Right, and I’m explaining that my multiple years of experience teaching and helping newcomers that an expectation of similarity to Rust frequently results in difficulty, and that it is beneficial to downplay any perceived link.

The old one had an inferior implementation, but that is unrelated to the output format. We also have a new Erlang source code generator that is used predominantly in the compiler test suite, and it too is superior.

This shows only the base syntax and has nothing of the language functionality, so is incapable of showing overlap between the languages.

Yes, exactly my point! Being a Rust user doesn’t mean you are going to prefer or even understand Gleam.

The title says it no longer compiles to Erlang source. That's true, it now compiles to an IR of the Erlang compiler.

The ML family clearly inspired Rust greatly, but the end result is very different.

For that sort of compilation target more flexibility is beneficial, so C, Wasm, LLVM IR, Cranelift IR etc are better than Go, Nim, and D in my opinion.

> cross portability/small binaries/fast compiled language which is fast to compile

You don't need native compilation to build fast single file executables for a program, there's ways one can achieve this with Gleam today. Bundling the BEAM into your Gleam application executable with something like Gleepack is one option, and this will produce smaller executables than Go will by default for many applications.

It's very possible that I'm misunderstanding you! I'm mostly just saying that Gleam is very unlike Rust, so if you pick it or avoid it for Rust related reasons you may not be making the most informed decision.

The languages that Gleam is most like might be Standard ML, OCaml, Elm, and F#.

I think a Rust programmer is more likely to prefer Gleam to Elixir, but I don't think there is much link between Gleam and Rust, and I especially do not thing that Gleam should only be considered over Elixir if you are already a Rust programmer.

Surprisingly yes! JavaScript's allocator and garbage collection system is quite well suited to immutable programming.

Rust is a very poor compile target as the compiler is slow and not commonly available, and the aspects of Rust that make it good for humans to write make it a poor choice for compilers to target. With humans the produced code is verified, but with a compiler the compiler is what is to be verified, so the inflexibility of Rust are largely a hindrance compared to other native compilation targets.

Gleam is a simple functional programming language which leans into static typing , friendly tooling, and a one-way-to-do-it style. You'd want to use it if you enjoy the programming experience it provides.