Chase Granberry

#bigquery #streaminganalytics #logsaremetrics #structuredlogging @elixirlang @elixirphoenix #myelixirstatus

you mean there is nuance in the compute storage separation discourse? strange

wait wut

Email > Slack I’ll fight for this one

@simpsoka No way my mom is target market!

@chasers Are you calling me a boomer chase?

Been thinking about an email interface to Slack for boomers

@zeeg Have it hallucinate tools in the background maybe it’ll give you ideas for new ones!!

Pushed a change to the Sentry MCP that bridges the gap between embedded agents (~subagents) and composable tools. All `search_` tools now run an LLM across the query input, meaning they support structured params + natural language, and the LLM can pull in all the various tool calls to course correct it as needed. If you notice any wacky behaviors here let me know. This is all pretty greenfield!

Until now, LiveVue supported only two SSR modes: ➡️ Vitejs-based (for development) ➡️ Nodejs (for production) Now I'm introducting a third one: ✅ QuickBeam It's running QuickJS as NIF, which is more performant. Now a default mode! Thanks @dan_note for contribution!

@SamRose I’ve wanted an excuse to

Are elixir folks out there still actively using and working with github.com/lucaong/cubdb ?

erlang_quic 1.3.0 is out. First production-ready release. Pure-Erlang QUIC + HTTP/3, zero C deps. - RFC 9000 / 9001 + 9114 / 9204 - Priorities, datagrams, CONNECT - -proto_dist quic for clusters - OTP 27+ github.com/benoitc/erlang…

@badlogicgames PI is now over 50% of agent usage at Shopify internally.

@bradgessler Why not an Elixir agent?

I have to figure out a way to spin up and manage 1,000-10,000 8GB servers in 2 weeks. Leaning towards an Elixir app that provisions them on various clouds & installs a go agent on them that connects up to said Elixir app. What should I look at? What am I going to regret?

wat

This is my first big Elixir project. I reached for it because I needed to manage the state of a lot of docker compose clusters to run the dev servers and docker containers to run agents. The supervisor tree was crucial to getting it working.

pure implementation of QUIC in erlang performs well now . github.com/benoitc/erlang…

Reach 1.5.0 — effect classification accuracy went from 11% to 89%. The analyzer couldn't tell 𝚁𝚎𝚙𝚘.𝚒𝚗𝚜𝚎𝚛𝚝!() from 𝙴𝚗𝚞𝚖.𝚖𝚊𝚙(). Now it can. What changed: — Alias/import resolution. 𝚊𝚕𝚒𝚊𝚜 𝙵𝚘𝚘.𝙱𝚊𝚛 then 𝙱𝚊𝚛.𝚌𝚊𝚕𝚕() was invisible to coupling analysis. Multi-alias 𝚊𝚕𝚒𝚊𝚜 𝙵𝚘𝚘.{𝙰, 𝙱} and 𝚒𝚖𝚙𝚘𝚛𝚝 too — Cross-module effect inference. Pure functions recognized transitively across modules — Plugin 𝚌𝚕𝚊𝚜𝚜𝚒𝚏𝚢_𝚎𝚏𝚏𝚎𝚌𝚝/𝟷 callback for all 8 built-in plugins. 𝚁𝚎𝚙𝚘.𝚊𝚕𝚕 → read, 𝚁𝚎𝚙𝚘.𝚒𝚗𝚜𝚎𝚛𝚝! → write, 𝚊𝚜𝚜𝚒𝚐𝚗 → pure — On Elixir 1.19+ reads compiler-inferred types from ExCk BEAM chunk 7 new commands: 𝚌𝚘𝚞𝚙𝚕𝚒𝚗𝚐, 𝚑𝚘𝚝𝚜𝚙𝚘𝚝𝚜, 𝚍𝚎𝚙𝚝𝚑, 𝚎𝚏𝚏𝚎𝚌𝚝𝚜, 𝚋𝚘𝚞𝚗𝚍𝚊𝚛𝚒𝚎𝚜, 𝚡𝚛𝚎𝚏, 𝚌𝚘𝚗𝚌𝚞𝚛𝚛𝚎𝚗𝚌𝚢. All take a path filter: 𝚖𝚒𝚡 𝚛𝚎𝚊𝚌𝚑.𝚑𝚘𝚝𝚜𝚙𝚘𝚝𝚜 𝚕𝚒𝚋/𝚖𝚢_𝚊𝚙𝚙/ Tested on 7 real codebases (up to 817 files). Zero crashes, 30% faster. github.com/dannote/reach/…

PgQue v0.1.0 is out. PgQ -- the Postgres queue system built at Skype 20 years ago for 1B-user-scale workloads -- repackaged for the managed-Postgres era. One SQL file. No C extension. No external daemon. pg_cron to tick. Why bother reviving a 2007 architecture? Every major Postgres queue in production today uses some flavor of SKIP LOCKED + UPDATE/DELETE. It works under light load. When you have more data and higher load, it degrades predictably. Then you get posts like these: - Brandur at Heroku, 2015: 60k job backlog in one hour from a single open transaction - PlanetScale, 2026: death spiral at 800 jobs/sec - River issue #59, awa issue #169 and so on, Oban's partitioning work, PGMQ's autovacuum tuning guide and duct-taping with pg_partman The core issue is how Postgres MVCC is implemented and how we deal with it. Dead tuples in the hot path, xmin horizon pinned, vacuum falling behind, query performance quickly degrades. This happens every time you run pg_dump, execute an analytical query, or have a lagging/unused logical replication slot. PgQ solved this in 2007 with snapshot-based batching and TRUNCATE rotation -- zero dead tuples in the event path, by design. But PgQ needed a C extension and an external daemon. Which means it doesn't run on RDS, Aurora, Cloud SQL, AlloyDB, Supabase, or Neon -- i.e., where most Postgres lives now. PgQue closes that gap. 💎 Pure SQL + PL/pgSQL (PgQ engine) 👩‍💻 \i sql/pgque.sql -- you're done 🕑 pg_cron replaces pgqd (optional, recommended) 💻 Python, Go, TypeScript client examples shipped 💙 Apache 2.0 Trade-off: end-to-end event delivery latency is up to a second, it depends on ticking frequency. If you need sub-3ms job dispatch, use River, Oban, or graphile-worker (and avoid anything that blocks xmin horizon). If you need high-throughput event streaming with fan-out inside Postgres -- Kafka-shaped, without Kafka and dealing with transactional outbox implementation -- this is the right shape of tool. Kudos to Marko Kreen and Skype engineers who implemented this decades ago, for the original PgQ, and to Alexander Kukushkin whose recent "Rediscovering PgQ" talk brought this quiet corner of the Postgres ecosystem back into view. Stars, issues, PRs, and honest criticism all welcome. Link 👇

for the erlang, elixir, and gleam fans - you can now use DOs to create and manage supervision hierarchies of child DOs 😎

The untold engineering story here is that this is powered by JS scripts that customers can author to validate and transform an event as it comes in. We built that by compiling JS to wasm via javy and executing wasm in elixir via wasmex (with some tight execution guarantees as it's on the critical path). I know sandboxes are all the rage right now, but elixir really is incredible for this sort of thing.

This looks nice!!

Wait we pronounce SWE as “suhhweee”??