r/elixir

i work at a mid size marketing agency and we have about 200 youtube videos. client case study recordings, internal strategy sessions, conference talks from our founders, onboarding walkthroughs for new hires. all unlisted and shared through notion. nobody can find anything because the only way to search is by video title which is usually something useless like "Q3 strategy call sept 14."

i've been looking for an excuse to build something real in phoenix liveview so i used this.

the app is a single liveview page. search box at the top, results below. as you type, results update live through the socket. each result shows the video title, date, speaker, and a snippet of the transcript around the matching text with the match highlighted. click the result and it opens the youtube video.

the backend is postgres with full text search. tsvector on the transcript column, GIN index, ts_headline for the snippet extraction. the liveview handles the search with a debounce on the phx-change event so it's not hammering postgres on every keystroke. i set it to 250ms which feels right. fast enough that it seems instant but not so aggressive that it fires on every character.

for pulling the actual transcripts i use transcript api:

npx skills add ZeroPointRepo/youtube-skills --skill youtube-full

i wrote a mix task for ingestion. give it a youtube url and it pulls the transcript, parses it, and inserts it into the database. added a --file flag so i could point it at a text file with all 200 urls and let it run through them. the whole ingestion took maybe 3 minutes.

the thing that sold my coworkers on it was the liveview search. i demoed it in a meeting and people immediately started shouting out search terms to try. someone typed in a client name and found every video where that client was discussed. someone else searched for "attribution modeling" and found a conference talk from 2022 that nobody remembered existed.

the codebase is small. one liveview module, one context module with the search query, the mix task for ingestion, and two templates. maybe 300 lines of elixir total. deployed it on fly.io on the free tier since it's just internal and the traffic is light.

the part i keep coming back to is how well liveview fits this use case. server rendered search with live updates over websockets and zero javascript. the search box, the debounce, the result list, the highlighting, all just liveview. i would have needed react or vue for this in any other framework.

I was in the Golang subreddit speaking about my new business and they got mad because I told them that the BEAM is better than Golang in certain problem sets. I built a Golang SDK just for them so they could get the reliability the BEAM could offer in serverless, and they downvoted my post. So I was curious what you guys think. I'm open to all criticism and feedback, but I truly cannot imagine any design coming close. I may have learned the BEAM with AI after getting laid off, but I feel like my years of operations work with Java, Golang, and Python stacks in serverless make me more pissed off than you all. Lol JK, I just wanted to get you excited for the design. I promise I'm humble.

If you have no idea what the internet was like before TCP — to send a file over the internet you had to know C. It was a huge pain in the ass. If you missed a chunk of data you had to rewrite the program. Every developer had their own custom retry logic. Everyone just sent packets as fast as possible with no appreciation for pacing. Then a small team — Vint Cerf and Bob Kahn — wrote TCP and it became the most foundational algorithm of the entire internet. We built the modern web, APIs, and databases on top of that algorithm. Sending email became trivial.

One more story that is important before my design: before Ericsson, in order to make a call there was a human switch operator. If the switch was full, the caller would be rejected. It didn't matter if the caller had an emergency — the model was first come, first served. Ericsson built the runtime to deal with concurrent processes with isolation boundaries that would make sure telecom systems were resilient to crashes.

Now on to my design. Agent retry storms are coming for everyone's APIs. A human being might visit 10–30 websites and call APIs maybe 20 times. The Cloudflare CEO said it plainly at SXSW this year: "Your agent will often go to a thousand times the number of sites a human would — it might go to 5,000 sites. And that's real traffic, and that's real load." Those agents will call APIs as fast as possible. The APIs will throw 429s, which inspires the servers to send more requests. The servers of the API will slow down, which will inspire clients to send more until it crashes. The fleet of machines that was over capacity at N machines will find only a ticking time bomb before N-1 machines handle the same capacity. The autoscalers will provision new machines and warm up — but crash before the entire fleet is down.

Enter EZThrottle. The same way Ericsson absorbs bursts of call requests and routes them to the best switch, EZThrottle queues, paces, and reroutes API calls past partial outages — in both directions. It protects the APIs you call and the API you run. It solves the noisy neighbor problem by giving each user their own queue. When it receives a 500, it uses the Fly.io network to send directly to another region to see if it works over there. It's what Cloudflare is for inbound traffic, but for your outbound API calls. Stripe, Google, OpenAI, and your gateway server could all be having partial outages and EZThrottle will fight to get each call through. No cold starts. No performance choking on retry storms. No spiky traffic — just smooth, predictable requests sent at the pace the API can actually handle. The resilience of the BEAM in your non-BEAM services.

I've linked the actual writeups below, but tell me — have you ever seen a more elegant architecture on the BEAM?

https://ezthrottle.network/blog/making-failure-boring-again
https://ezthrottle.network/blog/serverless-2-rip-operations
https://ezthrottle.network/blog/a-queue-per-user-at-scale

New BEAM There, Done That episode with Florian Gilcher (Ferrous Systems) and Leandro Pereira (MDEx, BeaconCMS) dives into where Rust actually fits in Elixir systems — NIFs, ports, performance bottlenecks, and hybrid architectures.

case system do

  :cpu_bound -> Rust

  :distributed -> Elixir

  :both -> "why not both?"

end

Good discussion on when to stay on the BEAM vs when Rust genuinely helps instead of just adding complexity.

https://youtu.be/w5Pl09lpSmE

As the title suggests, I'm relatively new to elixir. I've read books and I've done some projects here and there. I've dedicated this year to getting my hands into elixir, and boy am I being radicalized lol. I love elixir, erlang/otp, the community, and the advancements. I actually just finished watching Chris McCord's 2025 keynote, inspired by a recent post about the DurableServer, good stuff. Anyway, onto the actual post.

Long story short, to try and test out elixir + wasm (using popcorn), I've decided implement the game Snake. I've also decided to do it with no coding agents. The first phase was to just create a genserver for something to use in iex, just to get the logic down. (Small aside: I tried to make a full TUI version of it, but elixir doesn't seem to have great TUI libs/support. I'm using iTerm2 if that helps.)

A part of the snake implementation is the logic to place the food pellet, this is the logic. The constraints are only that the pellet needs to be on the grid and it cannot land on the snake.

def move_food(%__MODULE__{grid_height: height, grid_width: width} = state) do
  new_food_spt =
    Enum.reduce_while(1..(height * width), nil, fn _, _ ->
      spt = %{x: Enum.random(0..width-1), y: Enum.random(0..height-1), direction: nil}

      if spt_full?(state, spt.x, spt.y) do
        {:cont, nil}
      else
        {:halt, spt}
      end
    end)

  if new_food_spt == nil do
    raise "No space for food?"
  end

  %{state | snake_food: new_food_spt}
end

defp spt_full?(%__MODULE__{snake_head: head, snake_tail: tail}, x, y)
   when x >= 0 and y >= 0 do
[head | tail] |> Enum.any?(fn spt -> spt.x == x and spt.y == y end)
end

spt is short for snake point, it's different from just a point as it also has a direction. In my head it reads as "spot."

This is the implementation I went with. As I'm new to elixir, I'm unsure if this is a good way to go about it. I know that this is a super small thing, and I don't need to have it hyper optimized, I'm mainly asking to see other implementations or any thoughts.

The idea here is to randomly generate a point, then check to see if the spot is already taken, if it is check again. Do this area-of-the-grid times.

I know this is super simple, but it feels wrong somehow to use reduce like this. Also, since the random point generator is random, it could technically try the same, taken, spot(s) for each iteration which would be a false representation. I just feel that it's ... so unlikely ... until you've properly "snaked" and have filled up the board lol. Should I add a "seen" situation within the reduce fn? Any thoughts? Implementations? Admonishments?

Hey folks,

Hologram UI is in the works - the official component library for Hologram (my full-stack Elixir framework that compiles Elixir to run in the browser) - and the waiting list is now open.

A common reaction when I mention this is: "Just generate it with an LLM."

But there's more to a good component than markup - accessibility, responsive design, cross-browser compatibility, and the dozen edge cases nobody remembers until someone hits them. And it's not just individual components, it's them working together: consistent API, shared design tokens, predictable behavior, reusable composition patterns. A library designed around Hologram's conventions gives you idiomatic components - not generic ones bolted on.

If rolling your own works, no reason to stop. But not everyone wants to spend time on components when they could be building their actual product.

What you get on the waiting list:

• Early access before the general launch
• Help shape what ships in v1 (input on which components get priority)
• Proceeds sustain Hologram's development

Join the waiting list: https://hologram.page/ui

Curious what you'd prioritize - what components do you find yourself rebuilding most often? Forms, modals, data tables, navigation? Would love to hear what your typical Hologram (or Elixir frontend in general) project actually needs.

Kubernetes scales compute. It doesn't solve fairness or spiky traffic. When an agentic burst hits your services, pods get hammered, one noisy tenant crowds out everyone else, and the autoscaler takes 2 minutes to respond while requests are already failing.

EZThrottle Local is a single BEAM node that queues inbound jobs in memory and drains them to your upstream at a pace the service controls — via response headers. Your service responds with X-EZTHROTTLE-RPS: 20 and the queue drains at 20 RPS. As Kubernetes scales up, you raise the number. No redeploy, no config change.

Each user gets their own independent pace when you need it. A premium user can run at 50 RPS while a free-tier user runs at 2, in parallel, without either affecting the other — opt-in via a single response header.

On a 32GB machine it holds 3–32 million jobs in memory. That's hours of buffer at most agentic workloads — enough for any autoscaler to catch up before a single request is dropped. Built on the BEAM so hot code reloads preserve the in-memory queue across deploys.

https://github.com/rjpruitt16/ezthrottle-local