Welcome to GigaElixir Gazette, your 5-minute digest of Elixir ecosystem news that actually matters 👋.

. WEEKLY PICKS .

🎮 MMO Framework Proves C++ Dogma Wrong: 10K Entities @ 8ms Ticks

Everyone says you need C++ for real-time game servers. Alex66's open-source MMO framework just demolished that myth: 10,000 entities ticking at 8ms average, P99 under 12ms, full broadcast at 5.2 MB/s. The breakthrough? Killing a 68ms serialization bottleneck by fusing tick + serialize while data's hot in L1 cache. Architecture uses bucket-parallel tick loops (chunk entities across schedulers, not Task-per-entity), ETS spatial grids for O(1) neighbor queries, and :maps.from_list (9x faster than Map.put in reduces). Hybrid model: players as processes, NPCs as data in zone state. Crash recovery in 4.6ms. The "10K goblin stress test" runs without breaking a sweat.

Read more →

🔮 Vector DB Built on BEAM Challenges Python's ML Stack Dominance

The real test: does BEAM's process model choke on vector math, or can it actually compete with Python's ML stack? elix_db answers with collections, exact k-NN search (cosine/L2/dot product), HNSW-style indexing, and Nx batch re-ranking-all leveraging Elixir's concurrency for vector ops. No heavy dependencies. File persistence survives restarts. Optional HTTP API for integration. Author "vibecoded" it to prove you don't need Python for semantic search and RAG apps. Searches fly on a laptop.

Read more →

📊 Production Observability Guide Challenges "BEAM is a Black Box" Myth

Engineers from JVM/Go/Node ask: "Can I really observe Elixir in production?" This guide proves the BEAM isn't a black box-it's the opposite. Observer connects to live nodes and exposes every process's memory, message queue length, and reduction count in real-time. No third-party tools required. The supervision tree visualizes exactly how processes link for fault tolerance. Combined with OpenTelemetry and Prometheus integration, you get both deep runtime introspection and standards-based instrumentation. The BEAM was designed for observability from day one-lightweight processes mean every unit of work is visible to the runtime. SRE principles meet a runtime that actually wants you to look inside.

Read more →

📅 Google Calendar Clone Built Entirely in LiveView (No React Required)

Clinic management platform needed Google Calendar-style scheduling. Built it entirely in Phoenix LiveView: recurring appointments, drag-and-drop with JS hooks, multi-user views, overlap validation, CSS-based positioning. The performance trick? Using phx-update strategically and optimistic updates for drag operations. Data model handles recurring events, the UI stays fast at scale. Proof that complex interactive UIs don't need React-LiveView handles state management, real-time updates, and multi-user coordination without shipping a JavaScript framework.

Read more →

🎯 Corex Ships Accessible UI Components Without the JavaScript Framework Tax

Corex wraps Zag.js state machines in ergonomic Phoenix components-accessible, unstyled, no Node.js build process required. Works with both Controllers and LiveView. The architecture challenge: adapting interactive components to Phoenix's server-rendered model without fighting conventions. Solution: Vanilla JS integration with LiveView hooks, controllable from client or server. Accordions, triggers, content-all expressed through slots and nested components, never inferred from attributes. The pitch: battle-tested accessibility and state management without the framework overhead.

Read more →

Stop Blocking Mount: LiveView's Provider Pattern Kills 3-Second Page Loads

The Provider pattern isn't just React nostalgia-it's the answer to LiveView's mount-blocking problem that nobody talks about. When you jam async operations into mount/3, you're forcing users to stare at blank screens while your database does its thing. The naive approach loads similar products synchronously, blocking the entire page render for a search operation that has zero impact on above-the-fold content.

The Breakthrough

The breakthrough here is assign_async combined with :let slots. By moving data loading into a LiveComponent and exposing results via render_slot(@inner_block, %{items: ...}), you decouple data fetching from page rendering. The parent LiveView mounts instantly, the provider component handles its own loading states, and you get granular control over what data gets exposed to children. This is compositional LiveView done right.

Production-Ready State Handling

What makes this pattern production-ready is the explicit loading/no_results state handling. Most tutorials skip this part, leaving you with flash-of-unstyled-content bugs in production. The provider owns its entire lifecycle-loading skeleton, error states, empty results-while the parent stays blissfully unaware. You can drop this component anywhere without coordinating mount logic.

The real power move? That map you pass to render_slot controls your API surface. Need to add query metadata later? Just add another key. Want to expose pagination state? One line change. You've built a contract between provider and consumer that's explicit, typed (via slot attrs), and impossible to break silently.

Remember:

• Use assign_async in LiveComponents, not mount/3-async operations in mount block the entire page render

• The :let slot directive with render_slot(@inner_block, %{data: ...}) creates provider contracts that expose exactly what children need

• Handle loading/error/empty states inside the provider component-parent LiveViews should never coordinate async state

• Control your API surface with the map you pass to render_slot-adding fields later is a one-line change, not a refactor

. TIRED OF DEVOPS HEADACHES? .

Deploy your next Elixir app hassle-free with Gigalixir and focus more on coding, less on ops.

We're specifically designed to support all the features that make Elixir special, so you can keep building amazing things without becoming a DevOps expert.

See you next week,

Michael

P.S. Forward this to a friend who loves Elixir as much as you do 💜