lpil

Multiple of such tools exist and have done for years. Serde isn’t a Rust-core project, and similarly the Gleam alternatives are not Gleam-core.

No, it means that one specific package only offers bindings to certain parts. It’s the documentation for one library, not the language.

You can generate those conversions, most people do.

But also, you shouldn’t think of it as writing the same type twice! If you couple your external API and your internal data model you are greatly restricting your domain modelling cability. Even in languages where JSON serialisation works with reflection I would recommend having a distinct definition for the internal and external structure so you can have the optimal structure for each context, dodging the “lowest common decimator” problem.

It’s discouraged to pass around structs of functions to replicate type classes in Gleam. Instead the preference is to not type class style patterns in your projects, favouring a concrete style instead.

Gleam does have generics.

Gleam has always had generics! There’s no Gleam version without them

I think you might mean “ad hoc polymorphism” rather than “dynamic dispatch”. Gleam, C, Erlang, etc have the latter, not so much the former.

Gleam uses regular OTP, it doesn’t have a distinct OTP inspired framework. Source: I’m the author of Gleam.

Hi, I’m the creator of Gleam!

The comment you are replying to is correct, and you are incorrect.

All OTP APIs are usable as normal within Gleam, the language is designed with it in mind, and there’s an additional set of Gleam specific additions to OTP (which you have linked there).

Gleam does not have access to only a subset of OTP, and it does not have its own distinct OTP inspired OTP. It uses the OTP framework.

Gleam has first class functions, so it has dynamic dispatch.

Both of type classes and interfaces desugar to high order functions, so anything you write with them can be written with first class functions, though with a less concise API.

> The BEAM hooks into so many system libraries, you must compile it on every flavor of linux instead of just unpacking a tarball.

This isn't true, one can statically compile the BEAM for Linux exactly the same as the JVM. Here's an example: https://github.com/yoshi-monster/static_erlang/

No, the VM is functional and immutable so you cannot implement things like `while` on it efficiently. It is highly optimised for the functional immutable style of programming.

The JS backend is mature, but the Erlang backend and accompanying ecosystem is very small compared to Gleam.

Parser combinators are very slow in languages without a sufficiently optimising compiler, I wouldn't recommend them here.

In Gleam pattern matching and the "splitter" package is the go-to for text parsing.

Looks like it silently discards the message on failure, your users would likely be thankful for error logging otherwise debugging that defect in production will be very challenging.

> It’s SPA-first, which seems like a very strange decision to make in 2025.

It’s not! Lustre is very flexible and can be used in many different ways, including LiveView style server components. It’s not limited to SPA.

Yes, for sure. Both the JVM and the CLR have some native binary compilation options that, while less popular, are certainly suitable for production. The similar project for the BEAM unfortunately stalled and is no longer being developed.

It's all production ready and in use by businesses and open source projects today!

The language tour covers _the language_ rather than the concurrency framework, so you'd look to the Erlang and Gleam OTP documentation to learn about the framework. Erlang and Elixir have a similar documentation split, for example, the most popular book teaching Erlang, LYSE, has the first half about the language and the second half about the framework.

> it seems like it's mainly a statically typed language that just happens to be on the BEAM and that it isn't necessarily looking to solve the "static type the messages" in Erlang and Elixir. Is that correct?

Not quite! Gleam does have a type-safe derivate of the OTP framework, while maintaining full compatibility with the original untyped OTP. When writing a Gleam application that runs on the Erlang VM you will be using typed actors and messages.

> I'm just trying to get a sense of the language's origins and where it's going compared to Elixir and its gradual typing story.

Elixir and Gleam's respective type systems are about as different as you can get while still being type systems. The difference is so large that they offer completely distinct advantages and development experiences, so people who especially value and enjoy one are unlikely to find the other to their liking. I believe this is a real strength! It means that the BEAM ecosystem offers a wider range of programming styles, and so it can attract and serve a wider range of developers, growing the ecosystem as a whole. BEAM languages work together closely.

> if I know and like F#, Elixir, and Rust, what is the selling point of Gleam?

I could give you a list of technical benefits to picking Gleam, but really I think this sort of technology choice is very personal. You may find Gleam to be a language that you enjoy and are productive with, and if that's the case then it's a great tool for you! Your use of Rust, F# suggests you'll appreciate the programming style, and your use of Elixir suggests you'll appreciate using the same BEAM runtime, so perhaps give it a try.

No, the VM needs to be installed on the machine, similar to C#, Java, Python, etc.

There have been some projects for creating self-extracting executable archives for the VM, and some projects for compiling BEAM programs to native code, but nothing has become well established yet.

Thank you, you are very kind. I am extremely proud of the community, they are wonderful lot.

Thank you, very kind.

> It shouldn't be that blatantly ideological from the get go. It's just another programming language, not a political platform.

It's first and foremost a community, and it's important for communities to have clear a code of conduct and moderation of that code.

There are lots of languages without community, Gleam is not one of those.

> Gleam seems to have a lot of obvious influences from Rust, and the creator is a rust dev.

Hi! That's me!

Gleam the language doesn't have any Rust influence really. It's a happy accident that some of the syntax ended up looking the same, but that's likely due to both being inspired by similar languages such as OCaml and the C family. Most the syntax and the semantics predate Gleam's compiler being rewritten in Rust.

The build tool is a rip-off of Cargo for sure though.

If you've examples of code you have in Elixir that you could not express well in Gleam I would be very happy to help you out with that.

The two languages are almost the same at the value level, so code should translate across well.

Yes, they are very different. It's not splitting the ecosystem though as the vast majority of Gleam programmers are not former Elixir, Erlang, or LFE programmers, it's people coming from other ecosystems.

Gleam grows the BEAM ecosystem by bringing people in from elsewhere who were not interested in writing Elixir, Erlang, or LFE.

> I must admit that I find that fairly bizarre. What do you imagine the source of that lack of desire is?

They're just very different languages to work with. The programming experience is very different.

It’s certainly ready for use! The HTTP server made with it is used in production and was the fastest server available on the BEAM for some time, though Elixir’s Bandit has overtaken since then.

Aye, but this is the same as Elixir; it doesn't have full support for OTP and you are expected to use Erlang modules when you want the rest.

RE named processes, that's coming in the next release, and there's already multiple registry modules implemented in Gleam, including one funded by the Erlang Ecosystem Foundation.

It’s not limited in Gleam. All existing Erlang and Elixir OTP modules are usable in Gleam, and there’s also an additional set of Gleam OTP modules which provide type safety guarantees for a subset of OTP functionality.

Hi, I'm the designer of Gleam!

Beyond being functional and sharing a runtime I don't think Elixir and Gleam have much in common at all. Our recent developer survey showed that the majority of Gleam programmers were not Elixir users and largely were not attracted to that language.

Gleam isn't different from Erlang or Elixir in this case, all three languages implement OTP in "user land" rather than being part of the language. The only difference is how this OTP code gets distributed from the core team to you. In Gleam the BEAM ecosystem package manager is used, Elixir and Erlang leave it up to the operating system package manager, a docker container, or some other solution.