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

Coming This Week to Gigalixir: We Are Solving the Erlang 28 Breakage Problem

Erlang 28 quietly broke database connections for future Elixir versions. 

We spotted it early and are in the process of solving it. New databases already work. Existing ones get migration paths. 

And we’re shipping GigalixirKit.ecto_config() to auto-generate the right connection config, every time. 

Oh, and we’re covering Google’s extra $400/month infra cost. Because that’s our job, not yours.

. WEEKLY PICKS .

🔬 Why Set-Theoretic Types Don't Need Annotations (José Explains):

The Elixir creator demolished the biggest objection to static typing in a comprehensive video with Elixir Wizards. Set-theoretic types that infer automatically without requiring a single annotation, rolling out in phases across v1.19/v1.20 with zero breaking changes. The CNRS academic collaboration is yielding practical results with performance profiling showing negligible overhead. The breakthrough reveals why Elixir can capture developers who want type safety without the annotation burden that makes other languages feel like bureaucracy.

Watch the video

🛠️ Igniter Proves Elixir Onboarding Doesn't Have to Suck:

Zach Daniel showcased how Igniter solves Elixir's fragmented onboarding through live coding at Subvisual. Composable installers that automatically refactor code, manage dependencies, and handle tedious setup work that typically scares away newcomers. Instead of manual integration hell, intelligent code generation eliminates the cognitive load preventing Elixir adoption. What matters here: the ecosystem finally has a solution to its complexity problem.

Explore the talk

📖 Apple Toolchain Proves Phoenix Scales to Enterprise (Source Available):

Fresh analysis shows how Tuist, Apple's productivity toolchain serving thousands of developers, made their entire Elixir/Phoenix server available under FCL-1.0-MIT. Real-world reference implementation from a team that started with zero Elixir experience and evolved to serve enterprise-level tooling. The key insight: transparency gives the community production-ready patterns that beat theoretical examples every time.

Browse the tool

💼 The Real Cost of Elixir's Broken Interview Culture:

A brutal Reddit discussion exposed Elixir's job market reality: $3000 "contest" coding challenges, 4-hour conversations with CTOs who then leave, and timed interviews worse than big tech for $40/hour contracts. One company demanded recreating their entire app in 72 hours. When your talent pool is limited, treating candidates like unpaid consultants building free prototypes is counterproductive and damages the ecosystem.

Join the discussion

📝 LiveView Eliminates the Real-Time Collaboration Complexity Tax:

New evidence suggests real-time collaborative editing with Phoenix LiveView - live typing, multiple cursors, user presence, and version history - no longer requires months-long engineering projects. What used to demand WebSocket expertise, complex state management, and sophisticated frontend architecture now reduces to server-side logic with minimal JavaScript. This explains why collaborative features are becoming accessible to any Phoenix team.

Read the tutorial

. PRO TIPS .

Hot Code Loading Beats Microservices for Client-Specific Features

Lucas Sifoni from Alzo cracked the code on building client-specific applications without falling into the microservices trap. While everyone else spins up separate services for custom features, Sifoni leverages Elixir's hot code loading capabilities to build modular, client-specific apps within a single monolithic codebase - and the technical details prove why this approach dominates.

Here's the breakthrough:

Sifoni deploys one instance per client, each capable of loading client-specific LiveView applications at runtime without stopping the system. These dynamic apps live in /alzo/lib/clients/apps/<client_name>/<app_name>, get compiled on-demand, and register their own background processes with DynamicSupervisors.

The genius is in the build-time isolation - all client code gets stripped via rm -rf alzo/lib/clients/apps before Docker builds, ensuring the main application never depends on runtime modules.

The technical constraints create powerful guarantees: dynamic apps can never depend on each other's presence, the main app can't accidentally couple to client code, and what would be integration tests between microservices become regular LiveView tests in a monolithic codebase. Sifoni packages client apps as tarballs using mix alzo.app.package <client>/<app>, uploads them through a super-admin panel, and loads them at runtime with proper lifecycle management.

Why this approach wins?

You get true isolation without operational nightmare. No service discovery, network calls, cascading failures, or distributed debugging complexity. Each client app implements the DynamicApp behavior and gets mounted by ApplicationLive as a LiveComponent, providing the modularity benefits of microservices with the testing and deployment simplicity of a monolith.

Remember, for hot code loading architecture:

1. Strip all dynamic code before build-time using automated removal scripts

2. Use DynamicSupervisors to manage client-specific background processes safely

3. Leverage LiveView's component isolation with AppEntry naming conventions

4. Package client apps as tarballs for easy deployment and version management

. 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 💜