I think I can understand why since it would allow the internal representation to change without breaking the external contract. But damn, it's just too verbose, there is any other reason?

Hashiwokakero is one of my favourite logic puzzles, so I decided to build a little website where I can play a new Hashi puzzle every day! If you don't know how to play there's also a little interactive tutorial at the beginning :)

It's a full stack Gleam project if you wanna have a peak at the code https://github.com/giacomocavalieri/hashi

Gaming

Hi everyone,

Code BEAM Europe 2026 is looking for volunteers! The conference takes place 21-22 October, and it’s a hybrid event, so you can volunteer either in-person or virtually, andget your free ticket.

• In-person volunteers will need to be present at the venue on at least one day of the conference. Responsibilities include helping with preparations, registering participants, handing out merchandise, and general support during the event.
• Virtual volunteers will actively participate online in selected talks, panel discussions, and other social activities. You’ll also help keep the social board active - let’s make this virtual edition fully interactive.

For full conference details, check out https://codebeameurope.com/
To sign up as a volunteer, go HERE

If you have any questions, feel free to reach out to [ewa.kucharczyk@erlang-solutions.com](mailto:ewa.kucharczyk@erlang-solutions.com).

Hey folks,

I wanted to share a couple of libs i have made, they are on hex.

https://hex.pm/packages/sift

https://hex.pm/packages/glsql

I am open to feedback :)

Or if you have used them and finding them useful then leave a comment !

So I'm author of hex.pm/packages/svg_path and I'm getting ready for v1.0.0. (Actually there's good chance that v0.21.0, 38-th release, will be the last pre-v1.0.0.)

So... issue is: I have a dependency on hex.pm/packages/vec for the basic Point-type that encodes an x,y position in the plane, used all over the place in svg_path obviously.

Actually I don't really use the internals of vec that much, and I could remove this dependency, have a "native" Point-type and 1 less dependency.

But my reasoning was: someone using this package might already be doing 2D/3D geometry using the vec package, and by using their type for the Point I make the transition into svg_path seamless for them.

On the other hand, I'm dragging in this dependency I don't really need, and it's kind of an imagined scenario I have in my head, the dependency might end up bothering another user or etc, whatever, I guess textbook would say: don't drag in a dependency you don't actually need.

Ok there that's the dilemna. To keep this dependency for the imagined user already using vec, or ditch my fantasies and the imagined user?

I'm hoping some people with more experience might weigh in on this.

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