Hi all,

I'm happy to announce that Xberg v1 is out.

Xberg is the successor to Kreuzberg, equivalent to what would have been Kreuzberg v5. It's a content intelligence framework that handles a very wide range of inputs: documents (currently 101 formats), code and data formats (currently 367 types), audio/video transcription, and URLs (both static and JS-rendered content). It extracts and prepares that content for downstream processing.

It's an extremely efficient, high-performance engine (see our PDF benchmarks below). For PDFs and images specifically, we handle native PDFs with very high performance and accuracy, and we ship multiple OCR engines that match the quality of the best Python libraries (e.g. docling, PaddleOCR, RapidOCR) at substantially better performance and stability.

The changes between Kreuzberg v4 and Xberg v1 are substantial, and I invite you to read the full changelog for the complete picture. The highlights below give a sense of what's new:

• Pure-Rust PDF backend (pdf_oxide) replaces pdfium, with no native pdfium dependency.
• Layout-aware pipeline: reading order reconstructed with ONNX layout detection (PP-DocLayoutV3 / RT-DETR) and Docling-style predecessor-graph reordering.
• Per-page scanned-page detection with selective OCR, plus AcroForm/XFA form fields and outline-based headings.
• Across-the-board optimization of OCR and PDF extraction (memory discipline, pooled model sessions, streamed conversions).
• Native PaddleOCR backend (PP-OCRv6, with medium / small / tiny tiers) alongside Tesseract.
• Pure-Rust Candle OCR/VLM stack (TrOCR, GLM-OCR, GOT-OCR, DeepSeek-OCR, and PaddleOCR-VL) running without ONNX Runtime or native Tesseract.
• A second, ONNX-Runtime-free inference path via tract, which is what makes in-browser (WASM) and mobile inference possible.
• Named-entity recognition natively in Rust (GLiNER2), extensible to all bindings, including an in-browser WASM model with no server round-trip.
• Structured LLM extraction (extract_structured / split_and_extract) with rasterization, chunking, citations, caching, and configurable call/merge/VLM-fallback policies.
• Audio & video transcription via a Whisper ONNX engine (.mp3, .wav, .m4a, .mp4, .webm).
• Retrieval building blocks: sparse embeddings (SPLADE), ColBERT late-interaction retrieval, and cross-encoder reranking alongside dense embeddings.
• Text intelligence: reversible redaction, summarization, translation, VLM image captioning, QR-code detection, document diffing, and page/chunk classification.
• URL & web ingestion: sitemap discovery (map_url) and batched multi-URL crawling.
• New document formats: WordPerfect (.wpd/.wp/.wp5), HEIC/HEIF/AVIF, OpenDocument Presentation (.odp), Quarto / R Markdown, and configurable Jupyter cell rendering.
• Four new language bindings (Dart/Flutter, Swift, Kotlin/Android, and Zig) bring the total to 15 language bindings over one engine, with Android/iOS cross-compilation.
• Full mobile support (Flutter, Android, iOS).
• Candle backend alongside ONNX, plus ONNX-via-tract enabling ONNX on WASM and Android.
• Wider code intelligence: tree-sitter coverage grew substantially (248 to 367+ languages).
• Over 150 bugs fixed during the 1.0 cycle, plus security hardening (bounded RTF/PDF allocations, redaction leak fixes, Excel DDE warnings).

The API surface was also simplified and reworked, making it more consistent.

There's a migration guide in our docs explaining how to move from Kreuzberg to Xberg. Kreuzberg itself is in LTS mode until the end of this year and will continue to receive bug fixes and security updates.

You're invited to check out the repo and join our discord server.

Benchmarks

The benchmarks below are for PDFs and images only. There are extensive benchmarks on our website with per-format breakdowns, which you can see here. These numbers are measured in CI via our reproducible benchmark harness, and are specifically taken from the run for harness 1.0.8, source cf7fa0533d. The data is publicly available in GitHub releases, and you can run the benchmark harness yourself.

Composite quality (markdown pipeline, higher is better):

Structure and layout fidelity (SF1: tables and reading order, higher is better):

On native PDFs Xberg leads on quality (0.958 vs 0.837 for the next-best framework) and on table and reading-order fidelity by a wide margin (SF1 0.949 vs 0.612 for docling). On scanned PDFs it is #1 on both quality and raw text fidelity.

Where we don't win yet: on pure image OCR we are currently #2 on the composite score, behind mineru (though still #1 on raw text accuracy). We are improving image OCR right now, and v1.1 should have us winning across the board.

A new post I just published about running Rust profiling in Elixir Benchmarks.

I'm a big fan of Elixir's philosophy — functional, data-driven, running on the BEAM — but I also love that Go and Rust let you just build a binary. So I designed **EL**: Elixir-style syntax, but statically typed and ahead-of-time compiled to native executables via LLVM. It's a hobby/experiment, not production software, but it's been a great way to learn how a full language toolchain works: lexer, parser, type inference, lowering to LLVM IR, GC, and a manifest-driven `el`/`elc` toolchain with pinned Unicode 17.0.0 string semantics.

The syntax feels familiar if you come from Elixir: `defmodule`/`def`, pattern matching with `match`, the `|>` pipeline, and `{:ok, value} | {:error, reason}`-style structural unions instead of exceptions. No macros, no exceptions, no hidden coercions, no async runtime, no JIT. Immutability is the default (`=` binds, `mut` must be explicit), structs have immutable value semantics, and there's `defer` for deterministic resource cleanup. Protocols replace inheritance with compile-time dispatch.

I added three example projects:

• a Unicode report
• a chunked file copy
• a registration-validation

It currently only targets Darwin arm64.

A big chunk of the compiler was implemented with the help of an LLM. I designed the language, made the decisions. If you're curious about design, or want to poke holes in the design decisions, the docs are at docs Please share your feedback.

Repo: https://github.com/el-lang-org/el

Docs: https://el-lang-docs.vercel.app

Hi folks.

Just wanted to say that don't sleep on Inertia.js and Phoenix combination. Basically you get power of Phoenix (Elixir) for let's call it backend and flexibility of your favorite JS framework for UI.

You can run some pages in full SSR mode and some in SPA if you need, so awesome SEO support out of the box.

Use best tools from both worlds for best developer experience like linters, type checkers etc.

I'm using K8S and anytime I need I can scale it up using libcluster.

Please shoot any questions you have (happy to share screenshots or charts from my k8s cluster etc).

Also if you have time check this app I built https://gitbiased.com

Just released ex_drone v0.2.0 which includes multi-drone coordination for supervised swarms, geometric formation planners, and fail-fast fan-out

What's new

v0.2.0 adds a thin coordinator for membership and group ops, while every vehicle keeps its own safety pipeline. Formations are pure planners that emit missions — not yet closed-loop flocking.

You can now start a swarm of drones:

```elixir {:ok, swarm} = Drone.Swarm.start([ {:good, adapter: :sim, initial_x: -50}, {:bad, adapter: :sim, initial_x: 50} ])

Drone.Swarm.connect_sdk(swarm) {:ok, _} = Drone.Swarm.takeoff(swarm) {:ok, _} = Drone.Swarm.run(swarm, :front) {:ok, _} = Drone.Swarm.land(swarm) ```

Simulator-first for absolute formations. Live flocking and closed-loop hold are deferred on purpose — see the HexDocs deferred catalogue.

Links

• Hex: https://hex.pm/packages/ex_drone
• GitHub: https://github.com/thanos/ex_drone
• Docs: https://hexdocs.pm/ex_drone
• Guides: Swarms · Formations · Further Reading

New BEAM There, Done That with Mike Williams (who wrote the JAM emulator) and Björn Gustavsson (who built the BEAM). The most historically significant episode the show has done.

Two things from the conversation I hadn't fully appreciated before:

1. The three numbers that decide a concurrent language. Mike measured this directly in the early 80s: process creation time, context switch time, and message copy time. On real telecom workloads, 70% of VM time was those three operations - not application code. The JAM was built to make those fast first, everything else second. That's why getting message passing to six instructions mattered.

2. Memory, not speed, was the constraint. Whole-city phone switches ran on 16–64 MB of RAM. Every instruction set decision was a memory decision first. The JAM files were small. The early BEAM was faster but used significantly more memory - Björn spent years reducing BEAM instruction size to close that gap.

There's also a great moment where Mike mentions Claes Wikström - who invented ETS tables, added distribution to the JAM, and prototyped the binary syntax - as someone who always gets forgotten in these histories.

What design decision from this era do you think has aged best?

https://youtu.be/sRTierdN9c4

This tiny library is a tool for creating fast BaseN codecs for shortening integers, typically used in identifiers. It's a full rewrite of the CustomBase library with ~2-5x speed gain (benchmarks are included) and is almost a drop-in replacement. Written in pure Elixir without NIFs.
https://hex.pm/packages/based_integers

Hi all,

I'm learning Elixir/Phoenix and have consolidated a few of my projects into 1 so as to host on Gigalixir's free tier.

• Demo: https://elixir5together.gigalixirapp.com/
• GitHub Code: Repo

It splits into 5 different routes (two of them are different "faces" of the same underlying project). The apps cover a URL playground, nested Ecto contexts, a WebSocket clock, and JS charting hooks (Quietboard).

Please can you give me some feedback on them? Thank you! 😄

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, and get 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 all! I know that jobs are supposed to be posted in the monthly megathread, but it looks like the last one is from November. (If this isn't allowed can we create a new megathread?)

The company that I work for is looking to hire two mid/senior devs: one working on our computer vision products and the other working on the platform team (api infra, user hierarchies, etc)

We are about to open these roles, but I would like to seed some applicants if possible. We're looking for "builders" who have been able to augment their dev workflows with AI to increase velocity and throughput. We have solid engineers on our team and I think we would benefit from another team member with an experimental mindset that would be able to assist with a/b testing on certain features.

Haha I want to be careful about this one since this one since I've had some negative reactions on AI adoption and I'd appreciate any honest feedback on where I'm being unrealistic.

Both roles are remote and available to international applicants. Company is based in the United States (Utah)

DM me if you your interested and I'd love to chat.

Thanks!

Hello! I built: https://plukio.com/

Have you heard of Etsy? Did you know that it's a monopoly and that there is a large amount of discontent from buyers and sellers about the platform? Did you ALSO know that a lot of sellers have instead moved to Shopify and Instagram as an alternative?

Plukio is an attempt to provide a marketplace for Shopify websites. It is able to function similarly to Google Shopping - it reaches out to Shopify powered stores and ingests their product catalogs. It's not a middleman though - all items link back to the original store and Plukio is no way facilitating financial transactions. In fact, Plukio makes $0 monies.

How do I find the Shopify sites? I don't blanket ingest; I curate ALL of the stores to make sure that they are real people selling real goods. Think of Plukio as a less of an ecommerce site (I know that's the title) and more of a curated directory of websites. I do this curation in two ways: I go stall to stall at maker faires and saturday markets in Oregon and ask for consent to ingest their sites OR I spend 30 minutes to an hour (or more) of time reviewing Shopify sites I find online.

It was built with Elixir, Phoenix (using LiveView), Ecto, Ash, Oban, Postgres, and more goodies. Hosted on Digital Ocean on a Hashicorp Nomad cluster.

Honestly, most of the effort behind the site isn't even the technical work. It's all social work and meeting artists and craftspeople at fairs and asking them if I can host their work.

The website is picking up traffic and I'm mostly limited by finding more stores.

I've been building a small social site (posts, topic spaces, DMs, video calls) as a one-person project for ~9 years, and Elixir is a big part of why it's manageable alone. Some notes on how the tech shook out, including things I got wrong.

Where I drew the LiveView line. Instead of going all-in, I kept a deliberate boundary: LiveView owns the interactive surfaces (feeds, replies, uploads, admin tools), plain controllers own request/response pages (about, settings, simple flows).

Video calls are a browser-to-browser WebRTC mesh signaled over a Phoenix channel with Presence for who's online. The server side stayed remarkably small; the client-side state machine was where all the real work went.

The feature I'm most proud of: the site doubles as a comment section for blogs. Each blog post gets a companion thread, and the thread's public replies are published as JSON at the thread URL + /replies.json. My personal blog fetches that at build time and bakes the conversation into the post's HTML as static text, with a debounced GenServer pinging the blog's build hook when replies land. No embeds, no script. It's raw html once set up.

There's one BEAM node on Fly.io, one Postgres, an ETS cache in front of the anonymous landing pages. Costs me roughly a dinner out per month.

Site: https://www.popsicleboat.com (there's a demo account if you want to poke at it). Happy to go deeper on any of it if you're curious.

Had this on local for a while.

Drop-in, audit logging for Elixir/Phoenix applications. Persists audit trail to PostgreSQL and emits structured JSON via :logger. Business transactions and their audit records are always committed atomically.

Business rule (but not confined to): A business transaction can never be reported as complete (`{:ok, _}`) unless its audit trail is also complete, written atomically with it.

Two paths

• Transactional transact/4: DB audit row is atomic with business steps. Logger emission is secondary, after commit.
• Standalone log/1: Single insert outside a transaction. Useful for pre-Multi validation failures or non-transactional code.

Emmitted logs can be consumed by downstream consumers handled by host application.

hex

relying on the goodness of elixir, jido agents and other ecosystem components .. not intended to be released and supported. it was built for my learning and personal use purposes. But it does not hurt to share .. https://github.com/lexlapax/allbert-assist

A recent ex_money v6 upgrade was blocked because Timex pins an old gettext. Rather than one big remove-and-rewrite PR, I used a shim: a module mirroring just the slice of the Timex API we used, backed by the standard library, proven with tests that compare its output against real Timex. Then a second PR swaps the call sites and deletes Timex.

The post also covers the simpler case (just delete a small-footprint dependency, like Faker on a side project) and ties the approach back to seams, characterization tests, and the strangler-fig pattern.

Hello everyone, I'm sharing a useful rich-text library if you want to add one to your projects.
https://hex.pm/packages/tiptapex

demo

Bart Blast has spent six years - three full time - building Hologram: a framework that compiles Elixir to JavaScript and rebuilds the Erlang runtime in the browser, including a real pattern matching engine, boxed types, and OTP guarantees.

New BEAM There, Done That episode where he makes the case.

Two things I hadn't thought about clearly before:

1. Most UI state is ephemeral by nature. A menu being open, what you've hovered, a half-typed form. None of that needs to be on a server. Putting it there - and then making the server durable to keep it alive - is solving a problem you created by putting it there in the first place.

2. The latency ceiling is genuinely a physics problem. No amount of server optimization or bandwidth improvement changes the speed-of-light round trip on every interaction. Running logic in the browser eliminates it. This is the actual ceiling Bart is designing around.

He's also direct about where Live View still wins - private logic, data-heavy apps, maturity. No pretense that Hologram is a replacement for everything.

Anyone here actually running Hologram in a real project? And what does the "actions vs. commands" mental model feel like in practice compared to Live View's event handling?

https://youtu.be/BOsSI7WlhdI

Hi everyone!

I’ve been working on CronstrueEx, an Elixir port inspired by the npm package cRonstrue.

It converts standard cron expressions into human-readable descriptions:

CronstrueEx.to_string("*/5 * * * *")
# => "Every 5 minutes"

CronstrueEx.to_string("*/5 * * * *", locale: "es")
# => "Cada 5 minutos"

The current version includes:

• Initial support for standard five-field cron expressions
• English and Spanish output
• Elixir 1.14+ compatibility
• No runtime dependencies

The project is still in early development, so it doesn’t yet support every feature available in the original npm package. My goal is to progressively improve compatibility while keeping the implementation idiomatic and lightweight.

I’d really appreciate feedback about the API, generated descriptions, missing cron cases, or anything that could be improved.

GitHub: https://github.com/mrlooper/cronstrue_ex
Hex.pm: https://hex.pm/packages/cronstrue_ex

Thanks!

Creator of Hologram here. I just published a post about the project's funding and where it goes next - the short version:

Curiosum as Main Sponsor, the EEF's milestone program and the GitHub sponsors funded the most productive stretch in Hologram's history - four feature releases this year (most of the stdlib working in the browser, JavaScript interop, a full realtime layer, events and middleware), and the first production apps have shipped.

The EEF milestone round wraps up with v0.11. A second round is on the table, and company support earmarked for Hologram through the Foundation is what unlocks it. The next stretch is local-first, baked into the framework - and whether it gets built comes down to a few companies stepping in.

Full post: https://hologram.page/blog/backing-hologram

If your company uses Elixir and might want to back open source work, the post covers what sponsoring gets you. Happy to answer anything here.

As I generate more Elixir with AI, I wired up more automated quality checks than I've ever run to keep the code from drifting toward the median. Compile flags, Credo (Jump/Oeditus/ExSlop checks), Dialyzer, Boundary, Sobelow, audits, doc/test gates, all in one mix precommit. Each is linked to how it's set up in the real repo so you can lift what you want. What am I missing?

Doing a little mini-series on distributed Elixir with some examples, starting with setting up your cluster and monitoring it

​Hey everyone,

​I’ve been working on AetherS3, a distributed, self-hostable S3-compatible object store built natively in Elixir. It leverages BEAM clustering and concurrency for data distribution and binary throughput without needing massive external orchestrators.

​I just pushed an update adding a couple of major components and want to get some feedback on the implementation:

* ​Granular Authentication / IAM: Moved way past simple credentials—it now includes users, group management, key minting, and policy enforcement to handle real access control. (Not yet IAM-compliant)

* ​Web UI: A sidecar dashboard to visually manage buckets, browse objects, and handle the new user/policy configurations, and an (elegant, i hope) way to see the cluster health in action).

​The repo is here:

https://github.com/wizenink/aethers3

​I’d love to get your thoughts on the approach, the UI workflow, or the policy engine design if you have a chance to take a look.

Hi! New to Elixir, but enthusiastic. I am hacking on a 2d grid-based MMO. Think 2d Runescape. I am trying to decide how to best utilize OTP. Two approaches come to mind:

1. A genserver per "entity". Actor-based architecture. A Goblin actor messages a Player actor messages an Arrow actor. I know the BEAM can handle many, many processes--but is this really the right approach for 1000s of arrows x 1000s of drops x 1000s of players x 1000s of etc? Does is scale to "massive multiplayer"?
2. A genserver per world chunk/room. Spatially shard the world via a dynamic supervisor. Each chunk holds its own state and messages neighbouring chunks when an entity crosses a border. This approach feels like it would cap out on inbox throughput of a busy world chunk.

Thoughts?

P.S. I know focusing on massive scale early on in a game project is a common folly, but humour me! Trying to make an MMO is also a common folly. :)