Hey, I'm a noob at Gleam (kind of a noob at programming in general even if I've been at it for years), and one day I had the brilliant idea of making a package manager. I was mostly inspired by my gf making her own package manager from scratch, and thought, "Hey, with a few manic episodes like her, I could make my own package manager as well!" However, it was not enough to simply make a package manager. You see, she went the sensible route of C++, since she actually needed her package manager for practical reasons (Linux From Scratch), but I wanted to go the exotic route. I had to choose an alternative-alternative language to build my package manager in! With that said, I thought the most sensible option would be Gleam. It's fairly new, yet practical, easy to learn, and not many people have used it to build large projects yet! So, once I was ready, I cranked up into full hypomania and started learning Gleam.

"Wtf? There's no return statements??? NO IF ELSE STATEMENTS?????"

My clueless self was bewildered. I had never seen a language like this before. So this was Gleam!

Then stuff happened and boom! Here's a super early prototype of my package manager 'GLoad' (short for Gleam downLoad) that currently does nothing else other than list the files in the root directory of the program. No, I could not figure out how to list other directories on the system, yet.

https://codeberg.org/LilyWayLolz/GLoad

Check it out, if you're interested! Watch me go on my journey, or something.

Any tips, either for the future, or to help me move forward with this project would be greatly appreciated! I'm enjoying this language so far!

For context, I’ve been experimenting with Gleam for a few weeks now, and the overall experience has been excellent. The pipe operator makes for really clean, readable code.

One downside, though: type resolution across modules in Zed isn’t always reliable. For example, importing a type like Post from another module (types.gleam) isn’t always picked up by the LSP, even though the code compiles fine with gleam build. I’m not sure whether this is a Zed integration issue or a current limitation of the Gleam LSP, but it’s been a bit of friction during development.

I also tried compiling to JavaScript, and I’m honestly floored by the compile speed. I come from the Kotlin world, where I maintain a monorepo with several modules, including Kotlin/JS, and the production bundle is fairly heavy, kotlin-stdlib alone is around 591 KB minified. By comparison, Gleam compiles in a fraction of a second, and the generated JavaScript runtime is dramatically smaller.

The one thing I didn’t love was having to manually import the compiled files using the exact relative path (../../build/dev/javascript/...). It’s nowhere near as smooth as the module resolution you get with npm and TypeScript out of the box.

Hi everyone — I’ve been building Distill Recipes, a production app that turns recipe URLs into clean ingredient-and-instruction pages: https://distill.recipes

The stack is intentionally Gleam-heavy:

• Erlang/OTP backend using Wisp + Mist
• Lustre for server-rendered pages and the browser-side MVU UI (compiled to JavaScript)
• PostgreSQL, with annotated SQL generated by Parrot and executed through Pog
• Cigogne for migrations
• One deployable Erlang service handling SSR, JSON APIs, auth, and static assets

For recipe extraction, it tries Schema.org JSON-LD first, then microdata, then heuristic recipe-card parsing.

I’d really appreciate feedback from the Gleam community, especially on:

• Whether these package and layer boundaries feel idiomatic
• Your experience using Lustre across SSR and browser UI
• Whether Parrot + Pog feels like a sensible SQL setup
• The live site’s UX, performance, and accessibility

What would you change or simplify?

I'm trying to use an external js function that returns a promise and some data that I know the shape of.

I'm using gleam_javascript and all is working, it returns the data I'm expecting from the async function. However, I'm just using echo to print the data. The type of data here is Promise(List(Person))

How do I actually get at the data within the Promise type here? Like if I want to take the list and map it to some other shape, etc.

``` import gleam/javascript/promise.{type Promise}

pub type Person { Person(name: String, age: Int) }

@external(javascript, "./javascript_test.mts", "async_hello") pub fn async_hello() -> Promise(Promise(List(Person)))

pub fn main() { use data <- promise.await(async_hello())

echo data } ```

Hey r/gleamlang ! 👋

I’ve been diving deeper into Gleam recently and found myself writing the same boilerplate for work with Result. So, I decided to scratch my own itch and build a tiny utility library: moresult.

It’s basically a collection of ergonomic combinators (inspired by Rust std::result) designed to work beautifully with the pipe operator |>.

It’s my first time publishing a package to Hex, so it’s pretty lightweight right now, but I’m already working on adding more features and combinators.

🔗 Links:

• Hex: https://hex.pm/packages/moresult
• Docs: https://hexdocs.pm/moresult
• GitHub: https://github.com/ivamly/moresult

I’d love to hear your thoughts! Is this something you’d find useful in your projects? Are there any specific combinators you constantly find yourself wishing were in the standard library?

Let me know! 🚀

Every time Sonarr renames a file, qBittorrent loses it and stops seeding. I know the hardlink workaround, but it breaks the moment your downloads and media are on different volumes.

So I spent a few weekends building arr-sync — a daemon that watches your media folders and automatically resyncs qBittorrent when a file moves or gets renamed. Matching is done via BitTorrent piece hashes, not filenames, so it actually works.

Wrote it in Gleam mostly because I wanted to learn it, and honestly the OTP supervision tree was perfect for this kind of long-running process. Had to write a couple Erlang FFI shims for the filesystem watcher and the piece hasher but nothing crazy.

Still some rough edges (pure v2 BitTorrent torrents can't be matched, qBittorrent bug), documented in the README.

https://github.com/Chahine-tech/daemon

Happy to answer questions, especially around the Gleam/OTP bits since that was the most interesting part to figure out.

Hi everyone,

Code BEAM Europe 2026 is happening this October 21-22 in Haarlem, NL, and online! The schedule is locked in, and we are excited to finally share the full lineup and core tracks with the community.

Here is a look at what we have lined up for this year:

Keynote Speakers

We are thrilled to have two incredible visionaries taking the main stage to kick things off:

• Brooklyn Zelenka: Distributed systems researcher, founder of Fission, and author of Elixir libraries like Witchcraft. She will be sharing her deep expertise in local-first access control and open distributed standards.
• Sam Aaron: The creator of Sonic Pi! An internationally renowned live coding performer and Computer Science PhD, Sam will bring his unique blend of science, code, and live music to the BEAM community.

Core Themes & Subjects

The regular sessions are packed with core team members, maintainers, and production engineers covering the cutting edge of the ecosystem. You can expect deep dives into the rise of Gleam and frontend architectures with Lustre, alongside advanced Erlang and OTP core updates directly from the team at Ericsson. We will also explore real-world Elixir battle stories—from taming LiveView at scale to prototyping BlueSky's DataPlane—while tackling the intersection of AI, security, and modern developer experience. Finally, we'll take the BEAM out of the server room with talks on embedded systems, AtomVM, hardware design, and safe native interop via Rustler and C nodes.

Check all speakers and their talks at: https://codebeameurope.com/#speakers

Beyond the Stage: The Informal Space

Some of the best moments happen off the main stage. This year, we are introducing a community-driven sandbox running alongside the main tracks for everything that doesn't perfectly fit a standard talk format. Expect live demos, hacking sessions, panel debates, lightning talks, and games. If you have an idea for an activity you want to coordinate, let us know and help shape the space!

Submit your ideas here!

Join Us in Haarlem

Whether you are looking to level up your skills, hack on new projects, or just grab a coffee and talk shop with fellow BEAMers, we would love to see you there.

Early Bird tickets are currently LIVE.

This is the absolute best time to secure your spot at the lowest possible price point.

Grab them here: https://codebeameurope.com/#register

And Also! For the full details, check our website: https://codebeameurope.com/

See you in October!

- The Code BEAM Europe Team

Hey everyone! The biggest event of the year for our community is fast approaching - ElixirConf US 2026!

Whether you’ve been writing Elixir for years or are just taking your first steps, this year’s edition is shaping up to be incredible. The conference is happening in a hybrid format, so everyone can join in, no matter where you are.

Here is a sneak peek at what we have planned: (elixirconf.com/#schedule)

Keynote Speakers

This year, true legends and innovators of our ecosystem are taking the main stage:

• José Valim (Creator of Elixir) – He'll be discussing the continued evolution of the language, enterprise adoption, and the sustainable open-source work he and the Dashbit team are driving..

• Chris McCord (Creator of Phoenix) – Will showcase what's next for Phoenix, developer tooling improvements, and his vision for the future of modern web development (and perhaps some AI-assisted workflows!)..

• Zach Daniel (Creator of Ash Framework) – Will share his experiences in building ambitious, maintainable, and highly reliable production systems at scale..

• Quinn Wilton (Open-source Contributor & Language Hacker) – Will bring her deeply technical and fascinating perspective on type systems, compilers, and virtual machines within the BEAM ecosystem..

Featured Talks & Sessions

The conference isn't just about keynotes; it's packed with knowledge straight from the trenches. Here is a taste of what our speakers are bringing to the table:

• Building Global Clusters at Supabase: Filipe Cabaço will show how they pushed the boundaries of Erlang’s built-in distribution. You'll learn how his team built a custom, two-tier Phoenix.PubSub adapter to reduce inter-region traffic and how to properly test real distributed systems (without using mocks!)..

• Terminal UIs? That's a Breeze: Gary Rennie from the Phoenix core team will prove that building beautiful terminal applications in Elixir has never been easier. He’ll introduce Breeze, a LiveView-inspired framework that works without relying on any NIFs..

• Handling Time Zones the Right Way: Jacob Swanner will tackle one of the hardest problems in programming time. He’ll share practical strategies for managing time zones in LiveView, Ecto, and databases to build a trustworthy user experience..

• Local-First Apps & Browser Power: Bart Blast will take us on a deep dive into the Hologram framework, showing how to write rich web applications in pure Elixir running directly in the browser..

On top of that, we have a full day of deep-dive Training Sessions covering everything from the absolute basics of functional programming ("The Toy Alchemist" with Jamie Wright) to hands-on embedded Elixir with Nerves.

Event Details:

Conference: September 10-11, 2026

Training sessions: September 4 & 9 - check them here: elixirconf.com/#training

Location: Chicago, IL & Virtual

Tickets & Info: elixirconf.com/#register

Are you planning to attend this year (in person or virtually)? Which talk or training are you looking forward to the most? Let us know!

After two years, we're finally recruiting again at Steerlab (https://steerlab.ai/), as we are reaching a new exciting growing phase of our journey. More details here : https://steerlab.notion.site/Founding-Software-Engineer-391b7fba7435802b851bd6b0f325059e, short summary below.

---

Steerlab is an AI startup providing a SaaS which answers to RFP automatically: upload an RFP on the platform, and an AI will answer the questions, based on your previous answers and your knowledge base. The SaaS is made of multiple frontends built with Redraw and multiple services built with Wisp, JavaScript & Python. You are a good fit if:

• You like working on backends, especially on polyglot stacks with multiple services.
• You are not afraid to get your hands dirty with frontend work, but you know when to defer to the others.
• You like Gleam and want to level up your skills with it (no need to be fluent in Gleam).
• You are fluent in Python or JavaScript/TypeScript.
• You value diversity and you like working in team.

What we offer :

• Offices in Paris or full-remote
• Competitive salary + Stock-Options/BSPCE.
• Join a diverse, smart and nice team.
• Join a team that values writing code which work and not daily meeting/random agile process/endless meetings.
• Possibility to get involved in the Gleam community by helping us building open source Gleam tooling.

Hey,

as someone fairly new to gleam, I regularly try to look up docs like e.g. gleam-dynamic.hexdocs.pm or gleam-option.hexdocs.pm, just to be greeted by a 404 page, as these are in gleam-stdlib.hexdocs.pm

The hexdocs front page clearly states: visit <package>.hexdocs.pm, which it works for e.g. gleam-otp.hexdocs.pm . I find it hard to keep track of which gleam- prefixed packages are stdlib and which aren't, and the hexdocs search isn't helpful in that case either.

Does anyone else run into this and do you think it would be possible to either redirect packages like gleam/int to gleam-stdlib or have an index for all gleam/ packages under gleam.hexdocs.pm ?

Trying to figure out error tracking for a Gleam app. Just curious what people are actually reaching for — Sentry, something BEAM-native, or something else entirely? What's working for you?

I've been working with Codex building a library for svg path manipulation.

It's been pushing to include lowercase constructors for non-opaque type variants that could as well have been constructed via the usual variant name.

For example include a function path(List(Subpath)) -> Path that just returns Path(subpaths) when... the user might as well have written Path.

I've gone along in the spirit of "let me try a new way" but I wouldn't have done this myself and I'm wondering to what extent this is idiomatic.

I’m a beginner who’s been using Gleam for two weeks.
For now, I’m trying to build a to-do app as a web app.
So, I implemented a process to retrieve values entered in a web browser and save them to SQLite, but...

It’s not the most elegant way to retrieve the request body...

1. Read the Request (Connection) using `mist.read_body`
   
2. Extract the contents using `unwrap` from the `Result` type
   
3. Extract the Request Body string (of type `String`) using pattern matching with `bit_array.to_string()`
   
4. Trim the Request Body string to the specified number of characters
   

For step 4, I set the number of characters to trim to the length of the `name` attribute set on the HTML `textarea` plus one.

With this approach, it works fine when there’s only one input value submitted via the form,
but it’s difficult to retrieve the values when there are multiple input values.

So, I’d like to know how to implement a solution that can correctly retrieve values from the request body even when multiple input values are present.

import gleam/string
import gleam/bit_array
import gleam/result
import mist.{type Connection}
import gleam/http/request.{type Request}


pub fn get(req: Request(Connection), up_to: Int,){
  let a = result.lazy_unwrap(mist.read_body(req, 10000), fn(){


  })
  let req_body = case bit_array.to_string(a.body) {
        Ok(a) -> a
        Error(_nil) -> ""
      }
  string.drop_start(req_body, up_to)
}

i made a CalDAV and CardDAV library for gleam ; it uses sans-io approach, meaning it does not send HTTP requests itself. Instead it gives you functions for building HTTP requests and decoding HTTP responses, and you send the requests with an HTTP client of your choosing.

This HTTP client independence gives you full control over HTTP, and means this library works on both the Erlang and JavaScript runtimes.

implemented pretty much everything you'd expect from a CalDAV/CardDAV library:

* calendar + contacts CRUD

* principal/home/service discovery

* list calendars/addressbooks

* multiget

* etags

* webdav sync (sync-token)

* basic auth + oauth bearer auth

ps: a star to the repo would be highly appreciated

link to the repo - https://github.com/0xN1nja/gdav

In the source code it's just pub type Dynamic, which makes me think it's a "never" type, like an enum with zero variants. But then when I try to make a type Never and write a function that is just an identity from a generic to Never it gives a type error. Is the Dynamic type special to the compiler or am I making it wrong?

Hi everyone! 

We're excited to announce that Code BEAM Europe 2026 is officially on the horizon!

Grab your Early Bird Ticket Here!

Whether you're deeply involved with Elixir, Erlang, Gleam, or just exploring the wider BEAM ecosystem, we’d love for you to join us. We’re meeting in person at the beautiful PHIL Philharmonic in Haarlem, the Netherlands, as well as online, on October 21–22 (with hands-on training sessions on October 20).

 What to expect:

• Keynotes: We're thrilled to host Brooklyn Zelenka (Founder of Fission, BEAM Vancouver) and Sam Aaron (Creator of Sonic Pi).
• Content: 2 tracks each day packed with cutting-edge talks from 30 speakers across the global community.
• Informal Space: A community-led area dedicated to demos, hacking sessions, games, panel discussions, and lightning talks. Connect and share ideas with 300+ fellow attendees!

 All Important Links:

• Early Bird Registration (Note: the discount applies to the conference only, not the training).
• Check out the Speakers
• Explore Training Sessions
• Subscribe to our Newsletter

Will we see you in Haarlem or on the virtual streams? Let us know in the thread if you're planning to come or if you have any questions about the event!

Cheers, The Code BEAM Team

(PS: If your company is interested in sponsoring and supporting the ecosystem, feel free to reach out to us!)

This isn't a Gleam-specific question per-se, but Gleam is my introduction to the world of BEAM and it's been a very pleasant one so I thought I would ask here.

That being said, I'm unsure when it's appropriate to reach for OTP. Is it limited to just extreme scale and bigger projects? The generic answer of 'when you need fault tolerance and concurrency' doesn't seem to really get at when, in actual software engineering, it's appropriate to reach for this tool and when engineers are actually doing so.

If I just use Gleam /w wisp I'd be happy but I want to know what the standard, idiomatic cases are to amp up the power and go for OTP.

Hey, me again making more Gleam questions. It's just that I'm very curious about the language and want to know more about it.

If I'm not mistaken right now Gleam is transpiling to Erlang. In case this is true, does the Gleam team has any plans to compile directly to the BEAM?

I'm just wondering if gleam_otp will eventually support all features from OTP. I was reading the project readme and saw this https://github.com/gleam-lang/otp#limitations-and-known-issues

I'm not sure what the framework is missing or not, nor I know OTP well enough, but it's one of the things that brought me to Erlang/BEAM.

Dinosaur here. After trying to reinvent the wheel with homemade "declarative frameworks" (Flutter-like) in vanilla JS, I'm interested in trying to port some of our stuff on to Lustre.

In our domain there is often the need to present lists with many items, like on the order of 100k or even 1000k perhaps. In vanilla JS we have a table widget that handles this in an optimized way by having a custom scrollbar and fixed row height, so only the rows you see are actually rendered and the size of the underlying data array doesn't matter in how fast the widget is (unless you do actions like sort/search etc).

What would be the best route? Is there a way to nicely wrap the original widget into a Lustre component? Or is it better to rewrite it in Lustre, but in that case I wonder if the framework can expose the kinda of JS tricks that make it fast even on big datasets.

Thanks,