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.
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.
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.
The concurrency model in Go is also poorly suited to the BEAM's process model. Goroutines share a heap so you can't do a lot of things safely that processes can do. Having independent memory space for a process allows you to free it safely when work is done without GCing everything and you can also safely share data because you have a copy not a ref.
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.
What lower-level language do you think aside from rust which can be more helpful for the purposes of being a compile target, nim/D both support garbage collection and non garbage collection, so would languages like these be more preferable
I really love gleam and its community and I would really really love if gleam could be more like golang though, which can help it in compiling to machine code
gleam language but with the developer experience of golang (cross portability/small binaries/fast compiled language which is fast to compile) is honestly one of my fever dreams and I would love to know if it can ever be a reality!
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.
I don't get the impression that javascript is among Gleam's targets because of performance.
- server target: BEAM
- client target: js
Once you've covered those bases, you're kind of done.
If the server needs to do something special in an OS process... might as well let the OS mediate that interaction so that it can be fully generic, rather than trying to bend the language around whatever the unknown action might be.
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.
> I'd say if you know and like Rust, then Gleam should be easy to pick up
I think by sentiments like this, people mean if you know unions, records, and pattern matching then you'll more easily pick up another language that has unions, records, and pattern matching.
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.
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.
You said:
>I'd say if you know and like Rust, then Gleam should be easy to pick up but otherwise I'd try Elixir.
This is way too strong and narrow statement. Gleam is statically typed garbage collected language, closer to OCaml than Rust. Elixir if you like dynamically typed instead.
Nah, the gradual angle is not what makes a type system tricky to implement. Plus we have published a few papers discussing how we are typing Elixir and how our approach is sound.
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#.
You seem to be interpreting the statements as technical comparisons of the languages, but ch4s3 was (by my read) commenting on the overall ability of a programmer to jump from one language to another.
That is: they aren't similar languages on a technical level, but if you know Rust, you should be able to make the jump to Gleam pretty quickly.
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.
I use Rust and prefer Elixir over Gleam because Elixir has Lisp-style macros (Gleam doesn't), uses OTP directly, has the fantastic IEx REPL (Gleam has no counterpart), and has Phoenix, the best web framework I've ever used.
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.
> all the Erlang formats can be decompiled into Erlang source code
Nope, I'm not buying. This is roughly "any executable binary can be decompiled to C" which is kinda true, but we both know it's not how the real world works.
Compilation is lossy, parsing to AST is almost lossless.
> the cost of compiling to source
But now you paid this cost a second time. To build textual Erlang source programmatically, you need some kind of AST anyway, as I highly doubt you were using direct text templating. So you had an incomplete copy of Erlang Abstract Format, which is THE Erlang AST, but had to write your own pretty-printing.
If I were to implement code generation targeting BEAM in language X I would start with making some tool(in Erlang) to fetch abstract format definition from erl_parse typespecs and make code generator to X emitting matching definitions and ETF serialization code. It is relatively simple, it is unavoidable anyway, and it lets me avoid bothering with textual Erlang puctuation.
I just don't get it. It's not even fun!
Also I'm currently playing with idea of compiling Core Erlang via OCaml backend, there is a mirror problem - parsing of Core into OCaml terms. And no way I'm implementing proper lexing/parsing of Core, I'm going with ETF right from start.
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.
I use it mostly for web APIs / services, it's great for that!
Interop is not seamless since Elixir does not have the same static type system, but it is possible and that does help sometimes. When resizing images for example, I fall back to Elixir's bindings to libvips. I've also used Oban from Gleam in the past.
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.
Yeah. I know. I use it every day. That doesn't answer my question. Why would I want to write something in Gleam if I want it to run in a JavaScript engine? When would that ever make sense? Could you please just engage with me in good faith?
Multiple compilation targets require increased implementation complexity so you would think they would have a good reason for when you would compile to one target or the other. I couldn't find any information about it on their website, so I was hoping you would actually respond with something helpful rather than... that.
So, you started by making a pointed comment about that the language has no string interpolation when it's ostensibly for building UIs, so I'm not sure why you're surprised you're getting responses like mine or the one from lpil. Gleam is not ostensibly meant for building UIs just because it targets JS, and while you don't get string interpolation in the way you might get in other languages you can go pretty far with the <> syntax.
To answer your question about why you would use Gleam when you're running code in a JS engine, it's the same about any language that compiles down to another, such as Clojure, and you can take your pick of those reasons: preference, syntax, pragmatism, etc. I'm not sure what kind of answer you're looking for beyond that.
I'm looking for the intention behind it. They chose two compilation targets. That made things harder. They had a reason. That's what I'm asking about.
None of your reasons ("preference, syntax, pragmatism") fully explain the situation without more context. Whose preference? What syntax are users even seeing? Why is it pragmatic?
Compilation targets are generally chosen based on performance characteristics and where the code is actually expected to be run. If you're not expecting the code to run on the client, then there's no reason to use JavaScript. V8 performance is better when single-threaded, but then why use the actor model?
When I go to the ClojureScript website, they have a whole section about why they chose JavaScript as a compilation target[0]. Notably, it mentions the word "client" multiple times.
It's a general purpose language (as mentioned several times) and compiling to js eg. for lustre webapps (elm-ish). I've contributed to the js compiler once only and can't find a way to use more gleam at my job but I'd say having failsafe actor based erlang backend + ssr + rich strongly typed reactive frontend all in one language is really cool.
It seems your stuck on js-only for ui and somehow rejecting compile to js. If you don't wanna use it fine but I'm not sure what you're looking for in this thread...
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.
