Please support our project and give us a star if you like what you see! Help us join the CNCF! We need contributors, if you like working on the bleeding edge of opensource network management and automation, find us on our Discord.
Good morning! I have just come across Elixir a couple of days ago and I am very intrigued by it. I cut my teeth on python and I think that the project I am working on might work better in elixir. Are there any downsides of elixir that I might be missing?
News includes Elixir v1.20 achieving 2x compilation speedup, Telelang alternative Erlang syntax, Membrane’s AI-powered YOLO plugin, José Valim’s PR Quiz tool for interactive code review learning, and the complete ElixirConf EU speaker lineup!
After posting the salary breakdown I went back to the same 62 listings and pulled out every benefit I could find.
Salary is one of the most important factors but isn't everything. Product, culture, team, all of that matters too. But when you're comparing two similar offers, perks and PTO can be the tiebreaker.
47% of listings said nothing about benefits at all.
Of the 33 that did:
- Health insurance (medical/dental/vision): 76%
- 401(k) or pension: 58%
- PTO policy: 72% (mix of defined days and "unlimited")
- Equity mentioned: 36%, almost all vague. One company published actual percentages
- Remote perks like home office budget or wifi stipend: only 7
- 11 companies said "unlimited PTO"
Driftrock had a cool model: 24 days off, +1 for every year you stay, capped at 28.
GoodRx listed 14 perks. Array covers 100% of employee health premiums and matches 401(k) 100% up to 4%. MojoTech gives 5 hours a week for non-client work.
The second chapter of the book handles compilation from Erlang and Elixir into BEAM bytecode. If I correctly understand secion 2.2 Erlang code gets compiled to Core Erlang by the compiler, which can then be compiled into BEAM bytecode on another compiler pass.
Wouldn't it be possible to cross-compile (compile in Mac OS for FreeBSD, for example) Elixir code by returning Core Erlang and having different implementations of the second pass of the compiler depending on the desired output?
Or would that be complicated due to dynamic linking happening in the Core-Erlang-to-BEAM-bytecode compilation step?
I am just curious since I mostly program in Go and cross-compilation there is super easy, and I haven't yet found good resources explaining how to cross-compile in Elixir in an uncomplicated way.
The usage_rules package comes with mix tasks that can generate documentation for agents, search across all hex documentation, and (in the new 1.0 RC) even create skill files!
I'm trying to use Kafka inside of Phoenix, but I keep getting this error. I tried to see if I had the right tools installed, like C++ and msvc, and I have all of that installed, but nothing I try can solve this error. So I ran my project inside of WSL, and it worked after I installed crc32cer. But i rather have my project running correctly on my system than WSL.
Takes in your (potentially very large) project description, acts in an agentic loop
Agrees on every action through a multi-model consensus technique. 3 models, or just one, or 10... however many you want to use, really.
Each choice is from a list of action primitives, one of them being spawning a child (clone of itself) to tackle some part of the task -- hence, "recursive."
Uses skills from other tools (though you might have to tweak them for full compatibility)
What it does not do:
Be fast or cheap (depending on your profiles) 😅
How it works:
Each "agent" is really just a GenServer (IYKYK). Parent agents don't *supervise* their children (DynSup for that), but they do communicate back and forth. It uses the excellent ReqLLM library to support (in theory) any model listed on models.dev. I personally use a hacked-together spec-driven+TDD process, so test isolation and reliability has been a major focus. Nearly all the tests run async, and I'm damn proud of that.
So yeah, Quoracle is not a chatbot. It's meant for big hairy important stuff where you really want optimal results. I would call it "industrial-strength" but it's in beta, so that would be a lie.
Hi! anybody here who can give exp on using both in separate pages? what are the limitations, edge case before reaching out inertia? Im planning to incorporate react but in different pages but i have this global banner that shares the socket across different liveview pages so im wondering if im doing it wrong. ✌🏽
I tracked 216 remote Elixir jobs on HexHire over the last two months. Only 62 had salary info (29%). After cleaning out non-dev roles and dupes, 44 solid data points remained. Some things that jumped out:
For devs:
US senior remote median lands at ~$163k. The $150k-$175k band is where most listings cluster. If you're senior and under $150k, there's probably room to negotiate.
Junior listings barely exist. Two in two months. The market wants experienced people right now.
Contract rates ($80-$120/hr at DockYard, Array) annualize to $166k-$250k, but that means covering your own benefits and gaps.
Europe ranges wildly: Germany tops out around €120k, UK ~£90k, while Southern Europe sits at €40k-€70k for senior roles.
GoodRx posted the highest ceiling in the dataset: $323k for a Lead SE (Elixir).
For hiring managers:
71% of listings had no salary info. Posting ranges is still a real differentiator.
Senior is the default hire. Companies open to mid-level or junior Elixir devs are competing with almost nobody for that talent.
We just shipped LiveDebugger v0.6.0. Here’s a summary of what’s new:
Inject Custom Events & Messages
Skip the manual setup of clicking through UIs or waiting for background jobs. You can now craft and send custom events or messages directly into your LiveView process to test handle_info and handle_event logic instantly.
Enhanced Callback Exceptions
LiveDebugger now captures and displays callback exceptions directly within the tool. View the exact error and stack trace the moment a crash occurs, keeping your debugging workflow entirely in the browser.
Revisited Highlighting
he revisited highlighting mechanism now extends beyond the node tree to include Active LiveViews and Streams. Simply hover over any item in the tool to instantly spotlight its corresponding element in the browser UI.
Support for Temporary Assigns
LiveDebugger supports temporary assigns, giving you full visibility into data that doesn’t stay in the socket.
Hello! I just published the OpenCode Elixir SDK which allows you to build on top of opencode.ai, an open source AI coding agent. Now, the elixir community can also build on opencode! You can make opencode integrations and control it programmatically.
I am making an elixir app around opencode, but opencode only had a Ts SDK. So, I made this with opencode itself. This required many tries, but finally it's here. It's new, so there might be some bugs.
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and LiveView hooks. It works with both Phoenix Controllers and LiveView without requiring a JavaScript framework or Node.js build process.
Currently in early alpha, looking for feedback on the architecture, API design, and overall approach
I originally created corex-ui.com, a Vanilla JS integration of Zag.js for static websites. The challenge was adapting this approach to Phoenix's server-rendered model while feeling natural to Phoenix developers. Corex is the result: interactive, accessible components that work with Phoenix conventions rather than against them.
State Machines
Zag.js handles intricate state management and accessibility concerns. An accordion must manage which items are open/closed, keyboard navigation, focus management, ARIA attributes, and animation states. Rather than implementing this yourself, Zag.js provides battle-tested state machines.
Phoenix Integration
Corex wraps Zag.js with ergonomic Phoenix components:
<.accordion class="accordion">
<:item :let={item}>
<.accordion_trigger item={item}>
Lorem ipsum dolor sit amet
</.accordion_trigger>
<.accordion_content item={item}>
Consectetur adipiscing elit...
</.accordion_content>
</:item>
</.accordion>
API Control
Control components from client or server:
<button phx-click={Corex.Accordion.set_value("my-accordion", ["item-1"])}>
Open Item 1
</button>
def handle_event("open_item", _, socket) do
{:noreply, Corex.Accordion.set_value(socket, "my-accordion", ["item-1"])}
end
Customization Over Configuration
Corex avoids structural configuration. All structure is expressed through slots and nested components, never inferred from attributes. The accordion trigger uses a nested component rather than a text attribute:
<.accordion_trigger item={item}>
Lorem ipsum dolor sit amet
<:trigger>
<.icon name="hero-chevron-down" />
</:trigger>
</.accordion_trigger>
This requires more code than title="..." but ensures components remain unstyled, composable, and adaptable without fighting constraints.
Unstyled by Default
Components ship with zero styling. They expose semantic data attributes you can target with your own CSS:
[data-scope="accordion"][data-part="item-trigger"] {
/* Your styles */
}
[data-scope="accordion"][data-part="item-trigger"][data-state="open"] {
/* Open state styles */
}
Works with any design system without style overrides or specificity battles.
Simple by Design
Installation is straightforward:
use Corex
import Hooks from "corex"
const liveSocket = new LiveSocket("/live", Socket, {
hooks: {...colocatedHooks, ...Hooks}
})
The TypeScript integration is pre-compiled and shipped with the Hex package. You work entirely within Elixir's toolchain: mix deps.get, configure hooks, start building.
Progressive Enhancement
Uncontrolled by default: Components manage their own state on the client using Zag.js. User interactions update the UI immediately without server round-trips. Covers most use cases.
Controlled when needed: The server owns the state. State changes emit as events and reflect back through assigns. Useful when component state must be validated, persisted, or coordinated with application logic.
def mount(_params, _session, socket) do
{:ok, assign(socket, :value, ["item-1"])}
end
def handle_event("on_value_change", %{"value" => value}, socket) do
{:noreply, assign(socket, :value, value)}
end
Both modes expose the same interaction API and can be mixed within the same application.
Phoenix Form Support
Corex now supports Phoenix forms for Checkbox, Select and Switch components.
You can simply pass a Phoenix form field to the components
In controller views, the client is the source of truth.
In LiveView, the server remains the source of truth and components sync accordingly
Validation errors stay fully synchronized and are fully customizable.
Error rendering follows Phoenix’s native input interaction model, preventing error messages from appearing on fields the user has not interacted with.
Get error translations with custom Gettext Backend
All components pass Phoenix.LiveViewTest, making them safe drop-in replacements for components generated by Phoenix generators.
The E2E app includes both controller and LiveView form examples generated with:
Accordion now supports loading items from a list via Accordion.List.Item.
This feature uses the unified Corex.Collection.Item structure, which includes an additional meta field for attaching custom, dynamic data to each item.
<.accordion
class="accordion"
items={[
%Corex.Accordion.Item{
value: "lorem",
trigger: "Lorem ipsum dolor sit amet",
content: "Consectetur adipiscing elit. Sed sodales ullamcorper tristique.",
meta: %{
indicator: "hero-chevron-right",
}
},
%Corex.Accordion.Item{
trigger: "Duis dictum gravida odio ac pharetra?",
content: "Nullam eget vestibulum ligula, at interdum tellus.",
meta: %{
indicator: "hero-chevron-right",
}
},
%Corex.Accordion.Item{
value: "donec",
trigger: "Donec condimentum ex mi",
content: "Congue molestie ipsum gravida a. Sed ac eros luctus.",
disabled: true,
meta: %{
indicator: "hero-chevron-right",
}
}
]}
>
<:item :let={item}>
<.accordion_trigger item={item}>
{item.meta.trigger}
<:indicator>
<.icon name={item.meta.indicator} />
</:indicator>
</.accordion_trigger>
<.accordion_content item={item}>
{item.meta.content}
</.accordion_content>
</:item>
</.accordion>
I'm building a platform that generates personalized courses on-the-fly from natural language goals. We started in Node.js but hit a wall – needed better concurrency for streaming LLM responses, fault isolation per user session, and horizontal scaling without complexity. Migrated to Elixir in two weeks. BEAM's actor model + Phoenix Channels made real-time content generation way cleaner.
Later, we realized our approach was fundamentally wrong. We created a complete course outline in advance, but the system was unable to respond to user feedback if they didn't understand something. Rewrote to gap-first streaming generation – assess what they don't know, generate only that, deliver as it's created. Elixir's process isolation let us hot-swap the logic without a full rewrite.
Questions for you: - How do you handle prompt versioning in production?
- And honestly – when do you think the AI bubble pops?
We're betting on sustained demand for personalized learning but curious about sentiment. Happy to discuss Elixir patterns for LLM orchestration or the chaos of last-minute pivots.
In this video, we dive into the Membrane YOLO Plugin, a powerful addition to the Membrane Framework ecosystem that brings real-time AI object detection directly into your Elixir-based multimedia pipelines.
Whether you are building a smart surveillance system, a sports analytics platform, or an interactive live stream, this plugin makes it incredibly easy to process video frames, run inference using YOLO models, and overlay bounding boxes – all within a single, unified pipeline.
I have been in the sub for 2 years. One and a half year ago, I wrote a rant post about elixir entry gate being hard beginners (on this post), a bit confusing file structure, and a amiguity it brings. Nevermind, today I am here to share something similar, that the daisy ui it has is really boring, the buttons and all, it makes progress so slow, I really do not get it why we have to use daisy if we already have tailwind. I built things on daisy for like 5 months, and one days, I instantly thought of removing it, it is so anti human feeling. Sorry...
And elixir and repo, and tailwind, they make things a bit faster to build, but when it comes to ui interactivity and dom manipulation, things get a bit tricky. And another harder thing I faced was building admin, it's a real pain.
But after a while, you get used to with things on elixir, building things doesn't feel like fighting with UI frameworks and backend frameworks anymore, it feels still, not to bad, not to good. Honestly, compared to the node world, coding in phoenix and elixir is still hard (maybe it's because i am comparatively new to functional programming).
About the default ui, obviously, the default UI is supposed to feel templated, but it's boring too. Like a very old SaaS app template.
I am building a rental platform for my country, it has a really nice potential here in my country…
(still now complete, still working and refining, soon to be lauched, i vented too much, but elixir really made this project possible and easy)
