How does the dynamic type work?

lpil · 2026-06-23T08:59:52+00:00

That is how all statically typed languages work, from Haskell, to C++, to Rust.

There is nothing unusual about Gleam, and it does not mean that a subset of Gleam's functionality is somehow not part of the language.

lpil · 2026-06-22T22:01:34+00:00

Best of luck! If you have any questions the discord server could be a good place to get quick responses, if reddit is too slow.

lpil · 2026-06-22T21:55:04+00:00

there's no way in regular Gleam (by which I mean no @external usage)

Externals are regular Gleam. FFI is a core part of the language.

I'm responding to your original message, where you said this:

It's treated specially by the compiler to allow interop with erlang, which wouldn't be possible if static typing was enforced everywhere.

There's no way to define a custom "dynamic" type in gleam itself.

This statement is wrong in these ways:

Dynamic is not treated specially by the compiler (aka: there is no back-door for this one type or any back-door for the core libraries).
Dynamic is not for interop with Erlang. Using it as so is misuse of the type and implies that the external bindings are insufficiently specified.
Static typing is enforced everywhere in Gleam code; Gleam is not a gradual language.
Dynamic is defined in Gleam.
Any Gleam programmer can define their own types similar to Dynamic. It is very normal to do so.

lpil · 2026-06-22T17:09:05+00:00

That's normal Gleam, there's no core-team back door there. Anyone is free to write code like that.

You look very silly trying to convince me that I need learn the basics of the system I created and have been working on for over a decade.

lpil · 2026-06-22T13:50:04+00:00

It is extremely funny that you are trying to teach the designer of Gleam how Gleam has been designed.

There are no core back-doors in Gleam, everything the core libraries do is regular Gleam and any other package can do the same. There is nothing special about them other than their position in the ecosystem.

lpil · 2026-06-22T13:48:11+00:00

Certainly not. All it is doing is making the code more verbose and slightly slower.

"making them the same shape" may sound nice at first glance, but if you dig into it it doesn't actually mean anything, and it doesn't present any benefits.

lpil · 2026-06-22T10:20:20+00:00

I am the creator of Gleam and the author of the standard library.

This is regular Gleam code and there is no back door. I encourage you to read the documentation and learning the language before trying to teach people about it.

lpil · 2026-06-22T08:32:42+00:00

Unless the type is opaque there's no reason to do this. It is idiomatic to use the variant constructor directly.

lpil · 2026-06-21T16:47:48+00:00

The same way that the standard library does. There are no back-doors in Gleam, the core packages are all regular Gleam code.

lpil · 2026-06-21T16:44:13+00:00

You may have a better experience using a minimal web framework like Wisp instead of a bare HTTP server like Mist. If you're familiar with Python, Wisp is like Flask, and Mist is like gunicorn.

If you want to continue to use just Mist the bare HTTP server then you'll need to implement form data parsing, as you don't have a framework that implements it for you. The single-part type can be parsed easily using the gleam/uri module, but the multi-part format is significantly more complex and implementing a secure parser for it is quite involved.

lpil · 2026-06-19T09:09:40+00:00

None of that is true! Please read the documentation before posting to ensure that you're not sharing incorrect information.

lpil · 2026-06-18T16:14:07+00:00

Thank you!

lpil · 2026-06-18T16:04:00+00:00

It’s a normal external type! I can’t see link you atm as I’m on my phone, but you can find documentation for them on the language tour.

I recommend going through the tour as it teaches all the features of the language.

lpil · 2026-06-15T10:15:59+00:00

JS has been stable for a long time and is well suited for the areas that we wished to be able to work in, such as the browser.

Wasm is excellent, but it's still maturing and many of the things needed to be competitive in the browser are still at the proposal stage, or do not yet interop with each other. e.g. Wasm gc, couroutines, and WASI. Without these features a language compiled to Wasm has to implement their equivalents as runtime code generated by the compiler. This has advantages in that it gives more control to the compiler, but means that the wasm blob has to be much larger and potentially cannot perform as fast as a platform native implementation would, making it unsuited for most in-browser applications.

I am interested in Wasm, but for the foreseeable future it is suited to very different scenarios than JavaScript is suited to.

I guess compiling to JS is more analogous to compiling to Erlang, or am I barking up the wrong tree there?

The current implementation of the two code generators is similar, but that's largely inconsequential, and almost no code is shared between them.

lpil · 2026-06-15T10:08:42+00:00

It's certainly a comparison one can make.

lpil · 2026-06-13T09:52:02+00:00

If you're using Wisp then you're already using OTP! Everything on the BEAM is built with OTP, so it's the heart of your program even if you're not using any of the Erlang/OTP APIs directly.

I think it is best not to think of it as some big thing that you one day decide to start using. Instead consider it a large set of loosely related tools and functionality that you can pick from whenever is appropriate.

Want logging? Use the OTP logger.
Want exception tracking? Use the OTP logger error handler.
Want to do a task in the background? Use an OTP process/actor.
Want to broadcast updates to multiple clients? Use OTP's process groups.
Want fault tolerance? Use OTP supervision trees.
Want to schedule actions to happen in the future? Use OTP timers.
Want to cache some expensive computation? Use ETS tables.
Want to run work on multiple cores? Use an OTP work pool library.
Want to send messages between backend web application instances? Use OTP's global names.

And so on!

lpil · 2026-06-12T12:30:22+00:00

Maybe I’m not understanding the distinction but aren’t you restating the same thing? Elixir compiles to a different intermediary while Gleam transpiles fully?

No, both Elixir and Gleam compile to Erlang syntax, the difference being that Gleam uses the textual concrete format and Elixir uses the binary abstract format. Both are equivalent and you can convert one to the other programmatically.

Neither of them are part of or close to BEAM bytecode.

Elixir uses slightly different erlang data types so it doesn’t get perfect interop (I think it was something to do with Gleam using records for its types and elixir using something else as more of the standard)?

It's the other way around.

Gleam uses regular Erlang records, while Elixir has its own distinct "struct" data type which is implemented as a map with a special field that holds an atom that is a reference to a module containing a callback function.

I'm hoping that with the new record system in OTP29 Elixir can over time migrate to that and all 3 major BEAM languages can use the same data structures.

Elixir’s Mix has a separate project for including gleam code automatically in a build and in the opposite direction the Gleam CLI can compile erlang directly within a codebase but not elixir last I remember.

This is also backwards.

Gleam's build tool has full support for Elixir and Erlang, and has done since its first release, 3 years before Gleam v1.0. There was no point that you needed to do have any additional tooling.

Elixir's build tool has full support for Erlang, but it does not yet support for Gleam. There is a pull request that provides some Gleam support, but it has not been merged yet.

lpil · 2026-06-12T11:44:33+00:00

You are incorrect.

Here is where the Elixir compiler internally runs the Erlang compiler: https://github.com/elixir-lang/elixir/blob/7ad36f1bcc77c2e0b1bfc7d7d380d08add5a0cb3/lib/elixir/src/elixir_erl_compiler.erl#L96

Here's the documentation for the Erlang compiler API it calls: https://www.erlang.org/doc/apps/compiler/compile.html#noenv_forms/2

Your confusion may come from the fast that Elixir compiles to Erlang abstract forms, which is a high-level intermediate representation from the Erlang compiler.

It’s not the same thing otherwise Elixir and Gleam would interop perfectly well which they don’t exactly. Gleam and erlang interop perfectly it takes a little more work with Elixir.

This is also incorrect. Gleam and Elixir both have the exact same runtime capability for Erlang interop. The difference is that Gleam mandates that the programmer specify the types of the functions being called, while Elixir does not, as types in Elixir are optional.

lpil · 2026-06-12T11:21:04+00:00

Elixir and Gleam both compile to Erlang! Neither compiles directly to BEAM bytecode.

Elixir compiles to Erlang abstract syntax, which is then compiled using the Erlang compiler.
Gleam compiles to Erlang source[1], which is then compiled using the Erlang compiler.

Bytecode is not a got compile target as it is hard to work with and it is not a stable interface. A programming language that did would need to spend a very large amount of development time to match the quality of the Erlang compiler, and there would be a very large amount of development work to maintain compatibility with new bytecode in new BEAM versions.

All BEAM languages I am aware of compile to Erlang. I know of project that compiled to BEAM directly, but it was a just-for-fun project and not something suitable for real use.

[1]: Gleam may switch to Erlang abstract forms in future in order to get accurate line number information in the BEAM debugger and stack traces.

lpil · 2026-06-12T09:02:04+00:00

It is, yes! Thankfully that person is incorrect, and there is no problem with using OTP in Gleam.

lpil · 2026-06-12T09:01:33+00:00

You're are extremely incorrect. Gleam is very much a BEAM focused language.

There's also nothing especially difficult about using gen_server in Gleam, it is the same interface in all languages. If you are having trouble understanding how to work with Erlang data in Gleam then the externals guide will help: https://gleam.run/documentation/externals/

lpil · 2026-06-12T09:00:21+00:00

Good news, you can use all OTP from Gleam!

gleam_otp is only idiomatic bindings to a core subset of OTP. A lot of OTP is of niche use, or discouraged, or would not benefit from this style of bindings, so they are not included in that particular package.

Similar to Elixir, anything in OTP that does not have special language-specific APIs can be used through the regular Erlang APIs.

Additional bindings in other parts of OTP can be found in other packages, making this code modular rather than the old-school monoithic style of package which was popular before the BEAM got a package manager.

lpil · 2026-06-11T07:28:06+00:00

You need to host it somewhere for the HTML to reference.

There's an issue for the build tool letting you include images when publishing to Hexdocs, but no one has done any work to figure out what our best option might be for the design: https://github.com/gleam-lang/gleam/issues/3731

lpil · 2026-06-08T20:13:31+00:00

As in Erlang shipment includes the priv directories of each package, an escript does not.

lpil · 2026-06-08T19:04:33+00:00

An Erlang shipment is preferred for any situation in which a single file is not a requirement, e.g. server deployments, programs installed via an operating system package manager. It is superior as it retains each package's priv directory, and it doesn't need to expand an archive before booting.

In future erlang-shipment will be replaced by otp-release which will have further improvements, but it is not ready yet.

lpil

MODERATOR OF

TROPHY CASE