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.

LFE used to compile to core Erlang, but it now also compiles to abstract forms.

https://github.com/lfe/lfe/blob/387d0aa1092bdda0ca17481869e8...

https://github.com/lfe/lfe/blob/387d0aa1092bdda0ca17481869e8...

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

Aye, I am saying that jumping from Rust to Gleam isn't easy because the languages are so different. "How do I do X in Gleam like I would in Rust" is one of the most common categories of support question from newcomers who assumed they were similar.

It can take a moment to understand that things are done quite differently in the two languages due to being so different: https://gleam.run/frequently-asked-questions/#How-does-Gleam...

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.

I don't think that's the case, Rust and Gleam have almost nothing in common beyond having static type systems, and those type systems are very different too.

https://gleam.run/frequently-asked-questions/#How-does-Gleam...

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.

It's a general purpose programming language, like OCaml, Python, or Scheme. It's not intended for any specific business domain.

JavaScript is useful in lots of places, and even if one compile target is especially good for in-browser user interfaces that doesn't mean that language is specifically intended for user interface development.

Go's garbage collection isn't well suited for an immutable language like Gleam, so the performance would likely be disappointing compared to other targets.

Gleam is not ostensibly intended for building user interfaces.

I don't think your "it is source as you can convert it back into source" argument holds water as all the Erlang formats can be decompiled into Erlang source code, including the final bytecode itself.

I think you're overthinking the cost of compiling to source, and also underestimating how common it is.

The only thing that would be needed for this is for 2 flags to be passed to the Erlang compiler. It would be very trivial!

We did not (and still don't) have an internal Erlang AST representation in the compiler. Previously we did have a Gleam AST -> printing algebra -> Erlang source pipeline, now we construct a buffer of bytes with the data encoded as Erlang Term Format.

Source was the previous target as at the time Erlang Abstract Terms was not established as the go-to format (Core Erlang was more popular but it did not have a stable API outside of the BEAM, so Gleam's in-Rust compiler could not construct it), and due to the newness of the language having an "escape hatch" where one could abandon Gleam and eject to Erlang was highly valuable. It also meant we could use the Erlang build tool until the Gleam one was ready for use.

This regularly happens with Microsoft's GitHub. You can also opt to not use Bluesky for authentication.

Yes, frustration with GitHub outages certainly made me start to look elsewhere.

I wish! Alas, the Gleam project continues to be under-funded and we have not got a single penny from any venture capital company.

If anyone would like to give me a large amount of money in exchange for my publishing a mirror on your git forge, please get in touch ;)

While the way that Tangled is funded is not my preference, I see great potential in atproto for improving the internet. This and and a lot of interest in the Gleam community for the protocol made me decide it was a good place to host a mirror of the Gleam repository.

Sorry, I don’t know what you mean.

No no, you misunderstand. It doesn't mean the same thing as you imply with your previous comment.

Writing is contextual, if one only looks at the literal then one misses the other half of the meaning. Unfortunately your proposed change has added context that undermine your honourable and well-intentioned message.

Because that means something else.

> Black and White lives matter, but that's not what Glean is signalling.

It is! citation: I wrote it.