Skip to content
Developer Voices cover art

Kris Jenkins

Developer Voices

A Technology , News and Tech News podcast

Good podcast? Give it some love!

About the show

Deep-dive discussions with the smartest developers we know, explaining what they're working on, how they're trying to move the industry forward, and what we can learn from them. You might find the solution to your next architectural headache, pick up a new programming language, or just hear some good war stories from the frontline of technology. Join your host Kris Jenkins as we try to figure out what tomorrow's computing will look like the best way we know how - by listening directly to the developers' voices.

Newest episodes

Why Lisp Thrives In The Age Of AI (with Cameron Barré)

1 hr 39 min

Earlier this year it looked like AI might kill programming language innovation. Coding agents were at their best in the mainstream languages with decades of training data, which made the barrier to adopting anything new higher than ever. That's changed. With the right skills files, an agent will write Haskell or Gleam as happily as Java, and that flips the situation on its head: it's never been cheaper to take a new language, or a new architecture, out for a test drive. All we need is ideas worth trying. So this week I'm joined by an enthusiastic proponent of a language, an architecture and a library you might want to try. Cameron Barré is a long-time Clojure programmer and the author of Grain, an open-source library for building event-sourced information systems. We start with what makes a system simple or complex, and the difference between essential and accidental complexity. Then we look at why Cameron thinks Lisp is an excellent choice for expressing both code and constraints, and why a live REPL might matter even more to an agent than it does to a human. From there we get into event modeling, an architecture so simple to understand that even a clanker can get it right, and how Grain uses Clojure macros to turn a handful of primitives (commands, events, views and todo processors) into a DSL that stops agents drifting from the architecture. If you've been looking for an excuse to revisit Lisp or event sourcing, or you're wondering what a language should give us now that agents write most of the code, this is a tour of a different way of thinking: power where you need it, constraints where you don't, and cheap enough to try for yourself. --- Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join Grain: https://github.com/ObneyAI/grain Cameron's Clojure/Conj 2026 Talk - Building Simple Systems in the World of Natural Language Programming: https://www.youtube.com/wa...

How Would You Type-Check 30 Million Lines of PHP? (with Julien Verlaguet)

2 hr 21 min

How would you manage 30 million lines of PHP? You can't rewrite it - you'd be fired long before you delivered. That was the problem facing Facebook around 2011, and their answer was to add a type system, giving birth to the Hack language. But adding types to PHP turned out to be the easy part. The hard part was building a type checker that developers used to "edit, save, refresh" would actually tolerate. So how do you type-check tens of millions of lines of code fast enough that nobody notices? Julien Verlaguet co-designed Hack at Facebook, and has spent the fifteen years since chasing a better way to build incremental systems. We start with the internals of Hack's language server - forked OCaml workers, a shared immutable heap, lock-free dependency tracking, and the months spent hunting non-deterministic bugs. From there we follow the thread to Skip, a language designed around tracking mutability in the type system, with stops at why Haskell's monads and "reactive Java" didn't fit, functors vs type classes, and Skip's bang operator for working with immutable objects. Then it's on to the Skip reactive framework: eager vs lazy collections, a garbage collector without long pauses, a reactive SQL database that didn't find a market, TypeScript bindings, and Skipper, an AI coding agent built on a sound version of TypeScript. If you're interested in compilers, language design, or building real-time systems that stay fast as they grow, Julien has plenty of hard-won lessons to share. --- Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join SkipLabs: https://skiplabs.io/ Skip Framework Docs: https://skiplabs.io/docs Skip on GitHub: https://github.com/SkipLabs/skip Skiplang: https://skiplang.com/ Skipper Launch Announcement: https://skiplabs.io/blog/press_release Hack: https://hacklang.org/ HHVM: https://hhvm.com/ OCaml: https://ocaml.org/ OCaml Functors: https://ocaml.org/d...

DuckDB And The Burden of Success (with Hannes Mühleisen)

1 hr 46 min

Building something people actually want is supposed to be the happy ending. But it arrives with a bill attached: feature requests you didn't ask for, pull requests you'd rather not maintain forever, users demanding the one thing you swore you'd never build, and — if you're unlucky — a company where the sales team quietly starts deciding what engineering works on. DuckDB has spent the last two and a half years working through that list. So how do you stay a database engineering team when success keeps trying to turn you into something else? Hannes Mühleisen, co-creator of DuckDB, is back to talk through the answers they've landed on. Their fix for unwanted pull requests was an extension mechanism, which then forced them to make every part of the engine pluggable — including the parser, which meant ripping out 20,000 lines of Postgres' yacc grammar and rewriting SQL parsing on top of PEG. Their fix for the users demanding client-server was Quack, a protocol designed by people who'd already published a paper on why every existing database wire protocol is wrong. And their answer to Apache Iceberg, after three years of implementing it, was DuckLake: throw out the Avro-and-JSON metadata files and keep the metadata in a database, on the grounds that the Iceberg REST catalog has a Postgres in it anyway. Which brings us to the news Hannes breaks in this episode: DuckDB Labs is being acquired by AWS, while the DuckDB Foundation, the project and its licence stay where they are. There's the question of why a profitable, self-funded, 30-person company in Amsterdam would take that deal, what commitments you write into the contracts when you're worried today's promises might outlive today's management, and what it's actually like to have a boss again after five years without one. If you're curious how an open source project keeps its technical soul once the enterprise arrives — or you just want to know why parsing SQL is harder than parsing almost anything else — Hannes has some...

Similar podcasts

All episodes

Why Lisp Thrives In The Age Of AI (with Cameron Barré)

1 hr 39 min

Earlier this year it looked like AI might kill programming language innovation. Coding agents were at their best in the mainstream languages with decades of training data, which made the barrier to adopting anything new higher than ever. That's changed. With the right skills files, an agent will write Haskell or Gleam as happily as Java, and that flips the situation on its head: it's never been cheaper to take a new language, or a new architecture, out for a test drive. All we need is ideas worth trying. So this week I'm joined by an enthusiastic proponent of a language, an architecture and a library you might want to try. Cameron Barré is a long-time Clojure programmer and the author of Grain, an open-source library for building event-sourced information systems. We start with what makes a system simple or complex, and the difference between essential and accidental complexity. Then we look at why Cameron thinks Lisp is an excellent choice for expressing both code and constraints, and why a live REPL might matter even more to an agent than it does to a human. From there we get into event modeling, an architecture so simple to understand that even a clanker can get it right, and how Grain uses Clojure macros to turn a handful of primitives (commands, events, views and todo processors) into a DSL that stops agents drifting from the architecture. If you've been looking for an excuse to revisit Lisp or event sourcing, or you're wondering what a language should give us now that agents write most of the code, this is a tour of a different way of thinking: power where you need it, constraints where you don't, and cheap enough to try for yourself. --- Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join Grain: https://github.com/ObneyAI/grain Cameron's Clojure/Conj 2026 Talk - Building Simple Systems in the World of Natural Language Programming: https://www.youtube.com/wa...

How Would You Type-Check 30 Million Lines of PHP? (with Julien Verlaguet)

2 hr 21 min

How would you manage 30 million lines of PHP? You can't rewrite it - you'd be fired long before you delivered. That was the problem facing Facebook around 2011, and their answer was to add a type system, giving birth to the Hack language. But adding types to PHP turned out to be the easy part. The hard part was building a type checker that developers used to "edit, save, refresh" would actually tolerate. So how do you type-check tens of millions of lines of code fast enough that nobody notices? Julien Verlaguet co-designed Hack at Facebook, and has spent the fifteen years since chasing a better way to build incremental systems. We start with the internals of Hack's language server - forked OCaml workers, a shared immutable heap, lock-free dependency tracking, and the months spent hunting non-deterministic bugs. From there we follow the thread to Skip, a language designed around tracking mutability in the type system, with stops at why Haskell's monads and "reactive Java" didn't fit, functors vs type classes, and Skip's bang operator for working with immutable objects. Then it's on to the Skip reactive framework: eager vs lazy collections, a garbage collector without long pauses, a reactive SQL database that didn't find a market, TypeScript bindings, and Skipper, an AI coding agent built on a sound version of TypeScript. If you're interested in compilers, language design, or building real-time systems that stay fast as they grow, Julien has plenty of hard-won lessons to share. --- Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join SkipLabs: https://skiplabs.io/ Skip Framework Docs: https://skiplabs.io/docs Skip on GitHub: https://github.com/SkipLabs/skip Skiplang: https://skiplang.com/ Skipper Launch Announcement: https://skiplabs.io/blog/press_release Hack: https://hacklang.org/ HHVM: https://hhvm.com/ OCaml: https://ocaml.org/ OCaml Functors: https://ocaml.org/d...

DuckDB And The Burden of Success (with Hannes Mühleisen)

1 hr 46 min

Building something people actually want is supposed to be the happy ending. But it arrives with a bill attached: feature requests you didn't ask for, pull requests you'd rather not maintain forever, users demanding the one thing you swore you'd never build, and — if you're unlucky — a company where the sales team quietly starts deciding what engineering works on. DuckDB has spent the last two and a half years working through that list. So how do you stay a database engineering team when success keeps trying to turn you into something else? Hannes Mühleisen, co-creator of DuckDB, is back to talk through the answers they've landed on. Their fix for unwanted pull requests was an extension mechanism, which then forced them to make every part of the engine pluggable — including the parser, which meant ripping out 20,000 lines of Postgres' yacc grammar and rewriting SQL parsing on top of PEG. Their fix for the users demanding client-server was Quack, a protocol designed by people who'd already published a paper on why every existing database wire protocol is wrong. And their answer to Apache Iceberg, after three years of implementing it, was DuckLake: throw out the Avro-and-JSON metadata files and keep the metadata in a database, on the grounds that the Iceberg REST catalog has a Postgres in it anyway. Which brings us to the news Hannes breaks in this episode: DuckDB Labs is being acquired by AWS, while the DuckDB Foundation, the project and its licence stay where they are. There's the question of why a profitable, self-funded, 30-person company in Amsterdam would take that deal, what commitments you write into the contracts when you're worried today's promises might outlive today's management, and what it's actually like to have a boss again after five years without one. If you're curious how an open source project keeps its technical soul once the enterprise arrives — or you just want to know why parsing SQL is harder than parsing almost anything else — Hannes has some...

The Enterprise AI Gap (with James Brown)

1 hr 1 min

My guest this week is James Brown, an engineering lead at Schroders, and that's a useful vantage point — asset managers carry all the regulation and organisational weight of a bank, mixed with the first-to-market pressure of a startup. James starts with his own "Claude mania": months of agents running around the clock, and the wave of anxiety that hit him one morning walking to the shop without one running at home. From there, Clair — the plugin he's building to give coding agents proximal awareness of each other, using git orphan branches as a zero-infrastructure message bus; why AI behaves like oxygen in a room full of tiny fires; what "going well" actually measures inside a regulated firm; and why he thinks team sizes won't change, even when the number of teams does. There's a darker thread running under all of it. The collapse in junior hiring, the advice we no longer know how to give a 20-year-old, dark factories and evolutionary harnesses that might make the AI's ideas better than ours, and the burnout James expects to be our dominant topic for the next couple of years. If AI is working beautifully on your side projects but landing with a thud at work, James has some honest answers — including several about what he doesn't know yet. --- Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join Clair (James's multi-agent proximity plugin): https://github.com/JBJamesBrownJB/clair Clair product docs: https://github.com/JBJamesBrownJB/clair/blob/main/docs/product.md James's blog: https://medium.com/@jameskinnahbrown "Milk, Eggs and Claude Mania": https://medium.com/@jameskinnahbrown/milk-eggs-and-claude-mania-49f445c5a77e Schroders: https://www.schroders.com/ Claude Code: https://www.claude.com/product/claude-code Agent Skills & progressive disclosure: https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview Git orphan branches (git checkout --orphan...

What If Every SQL Query Could Update Incrementally? (with Lalith Suresh)

1 hr 5 min

There's a problem that's bugged the database industry since the 1980s: you run an expensive query over millions of rows, cache the result, and then a single new row arrives. Logically that's one small update, but most engines throw the cached answer away and recompute everything from scratch. Some will handle changes incrementally, but only for "simple" queries - and the rules for what counts as simple are arbitrary and brittle. So can you incrementally maintain *any* SQL query, no matter how complex? For decades the answer was no. Then an award-winning paper called DBSP proved that the answer is yes - all queries are simple enough. Joining me to explain how that works is Lalith Suresh, CEO of Feldera, the company built on top of DBSP. We start with the problem itself, then trace how a group of VMware researchers arrived at it from the unlikely direction of Kubernetes and network control planes. Lalith walks through Z-sets, the weighted data structure that turns database changes into something you can add and subtract, and the four DBSP operators - including one borrowed straight from digital signal processing - that let you compile any SQL program into an incremental version deterministically. Along the way we get into which operations need state and which don't, how the delta join falls out for free, building a standalone query engine with its own storage layer and Calcite front-end, backfills as the real Achilles heel, and how this all differs from stream processors like Kafka Streams and Flink. If you've ever fought with materialized views that won't refresh, watched a nightly batch job recompute three years of data to capture last night's changes, or you're just curious how one elegant bit of maths unifies batch and stream processing, Lalith has some genuinely satisfying answers. There's an MIT-licensed open source edition and a sandbox at try.feldera.com if you want to play along. --- Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Sup...

What's Worth Knowing In AI Right Now? (with Henry Garner)

1 hr 40 min

AI is changing the way we all build software — that much seems clear. But the landscape is moving so fast that even the people paid to keep up are struggling. MCP or skills? Fine-tune or just prompt? LangChain or let a thousand agents loose? With almost 70 competing technologies and a shelf life of maybe six months on any advice, how do you figure out what's actually worth your time? Henry Garner is CTO of JUXT, a consultancy with about 150 senior engineers working at the coalface of AI-assisted development, including building AI platforms for tier-one banks. JUXT publishes a quarterly AI Radar — 68 technologies rated and reviewed — and Henry's been watching his own team go through the full adoption arc, from "spicy autocomplete" skepticism through to building Byzantine-fault-tolerant distributed systems over a weekend with Claude. Along the way we cover MCP vs skills, Conway's Law for LLMs, neurosymbolic AI and the unexpected return of Prolog, the "Ralph Wiggum loop" for getting agents to converge on correct implementations, and Allium — a new behavioral specification language Henry's co-authored that sits between human prose and TLA+, aiming to give LLMs just enough structure to pin down what a system should do without falling into waterfall thinking. If you're trying to make sense of the AI tooling landscape, or you've hit that wall where your agents keep drifting away from what you actually wanted, Henry's thesis — velocity through clarity of intent — might well help out yours. --Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join JUXT: https://www.juxt.pro/ JUXT AI Radar: https://www.juxt.pro/ai-radar/ Allium on GitHub: https://github.com/juxt/allium Allium Documentation: https://juxt.github.io/allium/Composition at a Distance (Henry's blog post): https://www.juxt.pro/blog/composition-at-a-distance/ A New Vocabulary for an Old Problem (Henry's blog post): ht...

Asciinema: Terminal Recording Done Right (with Marcin Kulik)

1 hr 26 min

I have a theory that only bad projects get finished — good ones keep finding new things to do. Asciinema is a case in point. What started as a way to share terminal sessions with friends has, over 14 years, grown into a full suite of tools covering recording, hosting, playback, and live streaming — and been rebuilt multiple times along the way. So what does it actually take to record and replay a terminal session faithfully in a browser? Joining us for this conversation is Marcin Kulik, Asciinema's creator. The project's architecture has passed through almost every interesting corner of software engineering: a Python recorder built around pseudo-terminals (PTY), a ClojureScript terminal emulator for the browser that hit performance limits with immutable data structures and garbage collection pressure, a move to Rust compiled to WebAssembly, a Go experiment that didn't last, and a new Rust CLI for concurrent live streaming backed by an Elixir/Phoenix server that calls Rust code via NIFs. The same Rust terminal emulator library now powers all three components — the browser player, the server, and the CLI. If you've ever looked at those terminal animations embedded in a README and wondered what's underneath them, or if you're interested in how a passionate open-source developer navigates 14 years of language changes and rewrites, this conversation has plenty to offer. --- Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join Asciinema: https://asciinema.org Asciinema Docs: https://docs.asciinema.org Asciinema CLI (GitHub): https://github.com/asciinema/asciinema Asciinema Player (GitHub): https://github.com/asciinema/asciinema-player Asciinema Server (GitHub): https://github.com/asciinema/asciinema-server AVT - Rust terminal emulator library: https://github.com/asciinema/avt vt-clj - the original ClojureScript terminal emulator: https://github.com/asciinema/vt-clj Paul...

Building the SpacetimeDB Database, Game-First (with Tyler Cloutier)

1 hr 41 min

Eighteen months ago, Tyler Cloutier appeared on the show with what sounded like an ambitious (some might say crazy) plan: build a new distributed database from scratch, then use it to power a massively multiplayer online game. That's two of the hardest problems in software, tackled simultaneously. But sometimes the best infrastructure comes from solving your own impossible problems. The game, Bitcraft, has now launched on Steam. SpacetimeDB has hit version 1.0. And Tyler returns to share what actually happened when theory met production reality. We cover the launch day performance disasters (including a cascading failure caused by logging while holding a lock), why single-threaded execution running entirely from L1 cache can outperform sophisticated multi-threaded approaches by two orders of magnitude, and how the database's reducer model - borrowed from functional programming - enables zero-downtime code deployments. We also get into how SpacetimeDB is expanding beyond games with TypeScript support and React hooks that make building real-time multiplayer web apps surprisingly simple. If you're building anything where multiple users need to see the same data update in real time - which, as Tyler points out, describes most successful applications from Figma to Facebook - SpacetimeDB's approach of treating every app as a multiplayer game might be worth understanding. -- Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join SpacetimeDB: https://spacetimedb.com/ SpacetimeDB on GitHub: https://github.com/clockworklabs/SpacetimeDB Our previous episode with Tyler: https://youtu.be/roEsJcQYjd8Clockwork Labs: https://clockworklabs.io/ Bitcraft Online: https://bitcraftonline.com/ Bitcraft on Steam: https://store.steampowered.com/app/3454650/BitCraft_Online WebAssembly: https://webassembly.org/ Flecs (ECS for C/C++): https://www.flecs.dev/flecs/ TigerBeetle: https://tigerbeetl...

Will Turso Be The Better SQLite? (with Glauber Costa)

1 hr 51 min

SQLite is embedded everywhere - phones, browsers, IoT devices. It's reliable, battle-tested, and feature-rich. But what if you want concurrent writes? Or CDC for streaming changes? Or vector indexes for AI workloads? The SQLite codebase isn't accepting new contributors, and the test suite that makes it so reliable is proprietary. So how do you evolve an embedded database that's effectively frozen? Glauber Costa spent a decade contributing to the Linux kernel at Red Hat, then helped build Scylla, a high-performance rewrite of Cassandra. Now he's applying those lessons to SQLite. After initially forking SQLite (which produced a working business but failed to attract contributors), his team is taking the bolder path: a complete rewrite in Rust called Turso. The project already has features SQLite lacks - vector search, CDC, browser-native async operation - and is using deterministic simulation testing (inspired by TigerBeetle) to match SQLite's legendary reliability without access to its test suite. The conversation covers why rewrites attract contributors where forks don't, how the Linux kernel maintains quality with thousands of contributors, why Pekka's "pet project" jumped from 32 to 64 contributors in a month, and what it takes to build concurrent writes into an embedded database from scratch. -- Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join Turso: https://turso.tech/ Turso GitHub: https://github.com/tursodatabase/turso libSQL (SQLite fork): https://github.com/tursodatabase/libsql SQLite: https://www.sqlite.org/ Rust: https://rust-lang.org/ ScyllaDB (Cassandra rewrite): https://www.scylladb.com/ Apache Cassandra: https://cassandra.apache.org/ DuckDB (analytical embedded database): https://duckdb.org/ MotherDuck (DuckDB cloud): https://motherduck.com/ dqlite (Canonical distributed SQLite): https://canonical.com/dqlite TigerBeetle (deterministic simulation t...

Can Google's ADK Replace LangChain and MCP? (with Christina Lin)

1 hr 5 min

How do you build systems with AI? Not code-generating assistants, but production systems that use LLMs as part of their processing pipeline. When should you chain multiple agent calls together versus just making one LLM request? And how do you debug, test, and deploy these things? The industry is clearly in exploration mode—we're seeing good ideas implemented badly and expensive mistakes made at scale. But Google needs to get this right more than most companies, because AI is both their biggest opportunity and an existential threat to their search-based business model. Christina Lin from Google joins us to discuss Agent Development Kit (ADK), Google's open-source Python framework for building agentic pipelines. We dig into the fundamental question of when agent pipelines make sense versus traditional code, exploring concepts like separation of concerns for agents, tool calling versus MCP servers, Google's grounding feature for citation-backed responses, and agent memory management. Christina explains A2A (Agent-to-Agent), Google's protocol for distributed agent communication that could replace both LangChain and MCP. We also cover practical concerns like debugging agent workflows, evaluation strategies, and how to think about deploying agents to production. If you're trying to figure out when AI belongs in your processing pipeline, how to structure agent systems, or whether frameworks like ADK solve real problems versus creating new complexity, this episode breaks down Google's approach to making agentic systems practical for production use. -- Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join Google Agent Development Kit Announcement: https://developers.googleblog.com/en/agent-development-kit-easy-to-build-multi-agent-applications/ ADK on GitHub: https://google.github.io/adk-docs/ Google Gemini: https://ai.google.dev/gemini-api Google Vertex AI: https://cloud...

Building Observable Systems with eBPF and Linux (with Mohammed Aboullaite)

1 hr 11 min

How do you monitor distributed systems that span dozens of microservices, multiple languages, and different databases? The old approach of gathering logs from different machines and recompiling apps with profiling flags doesn't scale when you're running thousands of servers. You need a unified strategy that works everywhere, on every component, in every language—and that means tackling the problem from the kernel level up. Mohammed Aboullaite is a backend engineer at Spotify, and he joins us to explore the latest in continuous profiling and observability using eBPF. We dive into how eBPF lets you programmatically peek into the Linux kernel without recompiling it, why companies like Google and Meta run profiling across their entire infrastructure, and how to manage the massive data volumes that continuous profiling generates. Mohammed walks through specific tools like Pyroscope, Pixie, and Parca, explains the security model of loading code into the kernel, and shares practical advice on overhead thresholds, storage strategies, and getting organizational buy-in for continuous profiling. Whether you're debugging performance issues, optimizing for scale, or just want to see what your code is really doing in production, this episode covers everything from packet filters to cultural changes in service of getting a clear view of your software when it hits production. --- Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join eBPF: https://ebpf.io/ Google-Wide Profiling Paper (2010): https://research.google.com/pubs/archive/36575.pdf Google pprof: https://github.com/google/pprof Continuous Profiling Tools: Pyroscope (Grafana): https://grafana.com/oss/pyroscope/ Pixie (CNCF): https://px.dev/ Parca: https://www.parca.dev/ Datadog Continuous Profiler: https://www.datadoghq.com/product/code-profiling/ Supporting Technologies: OpenTelemetry: https://opentelemetry.io/ Grafana: htt...

Solving Git's Pain Points with Jujutsu (with Martin von Zweigbergk)

1 hr 11 min

Git might be the most ubiquitous tool in software development, but that doesn't mean it's perfect. What if we could keep Git compatibility while fixing its most frustrating aspects—painful merges, scary rebases, being stuck in conflict states, and the confusing staging area? This week we're joined by Martin von Zweigbergk, creator of Jujutsu (JJ), a Git-compatible version control system that takes a fundamentally different approach. Starting from a simple idea—automatically snapshotting your working copy—Martin has built a tool that reimagines how we interact with version control. We explore the clever algebra behind Jujutsu's conflict handling that lets you store conflicts as commits and move freely through your repository even when things are broken. We discuss why there's no staging area, how the operation log gives you powerful undo/redo capabilities, and why rebasing becomes trivially easy when you can edit any commit in your history and have changes automatically propagate forward. Whether you're a Git power user frustrated by interactive rebases, someone who's lost work to a botched merge, or just curious about how version control could work differently, this conversation offers fresh perspectives on a tool we all take for granted. And if you're working with large monorepos or game development assets, Martin's vision for the future of Jujutsu might be exactly what you've been waiting for. --- Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join Jujutsu (JJ): https://github.com/martinvonz/jj Jujutsu Documentation: https://martinvonz.github.io/jj/ Git: https://git-scm.com/ Mercurial: https://www.mercurial-scm.org/ Rust: https://www.rust-lang.org/ Watchman: https://facebook.github.io/watchman/ Google Piper: https://research.google/pubs/why-google-stores-billions-of-lines-of-code-in-a-single-repository/ Kris on Bluesky: https://bsky.app/profile/krisajenkins.bs...

Getting New Technology Adopted (with Dov Katz)

1 hr 5 min

Getting new technology adopted in a large organization can feel like pushing water uphill. The best tools in the world are useless if we're not allowed to use them, and as companies grow, their habits turn into inertia, then into "the way we've always done things." So how do you break through that resistance and get meaningful change to happen? This week's guest is Dov Katz from Morgan Stanley, who specializes in exactly this challenge - driving developer productivity and getting new practices adopted across thousands of developers. We explore the art of organizational change from every angle: How do you get management buy-in? How do you build grassroots developer enthusiasm? When should you use deterministic tools like OpenRewrite versus AI-powered solutions? And what role does open source play in breaking down the walls between competing financial institutions? Whether you're trying to modernize a legacy codebase, reduce technical debt, or just get your team to try that promising new tool you've discovered, this conversation offers practical strategies for navigating the complex dynamics of enterprise software development. Because sometimes the hardest part of our job isn't writing code - it's getting permission to write better code. --- Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join Morgan Stanley: https://www.morganstanley.com/ OpenRewrite: https://docs.openrewrite.org/ Spring Framework: https://spring.io/ Spring Integration: https://spring.io/projects/spring-integration Apache Camel: https://camel.apache.org/ FINOS (FinTech Open Source Foundation): https://www.finos.org/ Linux Foundation: https://www.linuxfoundation.org/ Moderne (Code Remix conference organizers): https://www.moderne.io/ Code Remix Conference: https://www.moderne.io/events Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social Kris on Mastodon: http://mastodon.social/@krisaje...

From Unit Tests to Whole Universe Tests (with Will Wilson)

1 hr 12 min

How confident are you when your test suite goes green? If you're honest, probably not 100% confident - because most bugs come from scenarios we never thought to test. Traditional testing only catches the problems we anticipate, but the 3am pager alerts? Those come from the unexpected interactions, timing issues, and edge cases we never imagined. In this episode, Will Wilson from Antithesis takes us deep into the world of autonomous testing. They've built a deterministic hypervisor that can simulate entire distributed systems - complete with fake AWS services - and intelligently explore millions of possible states to find bugs before production. Think property-based testing, but for your entire infrastructure stack. The approach is so thorough they've even used it to find glitches in Super Mario Brothers (seriously). We explore how deterministic simulation works at the hypervisor level, why traditional integration tests are fundamentally limited, and how you can write maintainable tests that actually find the bugs that matter. If you've ever wished you could test "what happens when everything that can go wrong does go wrong," this conversation shows you how that's finally becoming possible. --- Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join Antithesis: https://antithesis.com/ Antithesis testing with Super Mario: https://antithesis.com/blog/sdtalk/ ...and with Metroid: https://antithesis.com/blog/2025/metroid/ MongoDB: https://www.mongodb.com/ etcd (Linux Foundation): https://etcd.io/ Facebook Hermit: https://github.com/facebookexperimental/hermit RR (Record-Replay Debugger): https://rr-project.org/ T-SAN (Thread Sanitizer): https://clang.llvm.org/docs/ThreadSanitizer.html Toby Bell's Strange Loop Talk on JPL Testing: https://www.youtube.com/results?search_query=toby+bell+strange+loop+jpl Andy Weir - Project Hail Mary: https://www.goodreads.com/book/show/54493...

Building Render: Inside a Modern Cloud Platform (with Anurag Goel)

1 hr 24 min

How would you build a Heroku-like platform from scratch? This week we're diving deep into the world of cloud platforms and infrastructure with Anurag Goel, founder and CEO of Render. Starting from the seemingly simple task of hosting a web service, we quickly discover why building a production-ready platform is far more complex than it appears. Why is hosting a Postgres database so challenging? How do you handle millions of users asking for thousands of different features? And what's the secret to building infrastructure that developers actually want to use? We explore the technical challenges of building enterprise-grade services—from implementing reliable backups and high availability to managing private networking and service discovery. Anurag shares insights on choosing between infrastructure-as-code versus configuration, why they built on Go, and how they handle 100 billion requests per month. Plus, we discuss the impact of AI on platform adoption: Are LLMs already influencing which platforms developers choose? Will hosting platforms need to actively support agentic workflows? And what does the future hold for automated debugging? Whether you're curious about building your own platform, want to understand what really happens behind your cloud provider's dashboard, or just enjoy hearing war stories from the infrastructure trenches, this episode has something for you. – Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join Render: https://render.com/ Render’s MCP Server (Early Access): https://render.com/docs/mcp-server Pulumi: https://www.pulumi.com/ Victoria Metrics: https://victoriametrics.com Loki: https://vector.dev/docs/reference/configuration/sinks/loki/ Vector: https://vector.dev/ Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenki...

InfluxDB: The Evolution of a Time Series Database (with Paul Dix)

1 hr 49 min

How hard is it to write a good database engine? Hard enough that sometimes it takes several versions to get it just right. Paul Dix joins us this week to talk about his journey building InfluxDB, and he's refreshingly frank about what went right, and what went wrong. Sometimes the real database is the knowledge you pick up along the way.... Paul walks us through InfluxDB's evolution from error logging system to time-series datasbase, and from Go to Rust, with unflinching honesty about the major lessons they learnt along the way. We cover technical details like Time-Structure Merge Trees, to business issues like what happens when your database works but your pricing model is broken. If you're interested in how databases work, this is full of interesting details, and if you're interested in how projects evolve from good idea to functioning business, it's a treat. -- Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join InfluxData: https://www.influxdata.com/ InfluxDB: https://www.influxdata.com/products/influxdb/ DataFusion: https://datafusion.apache.org/ DataFusion Episode: https://www.youtube.com/watch?v=8QNNCr8WfDM Apache Arrow: https://arrow.apache.org/ Apache Parquet: https://parquet.apache.org/ BoltDB: https://github.com/boltdb/bolt LevelDB: https://github.com/google/leveldb RocksDB: https://rocksdb.org/ Gorilla: A Fast, Scalable, In-Memory Time Series Database (Facebook paper): https://www.vldb.org/pvldb/vol8/p1816-teller.pdf Paul on LinkedIn: https://www.linkedin.com/in/pauldix/ Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Beyond AI Hype, What Will Developers Actually Use? (with Zach Lloyd)

1 hr 18 min

If AI coding tools are here to stay, what form will they take? How will we use them? Will they be just another window in our IDE, will they push their way to the centre of our development experience, displacing the editor? No one knows, but Zach Lloyd is making a very interesting bet with the latest version of Warp. In this deep dive, Zach walks us through the technical architecture behind agentic development, and how it's completely changed what he & his team have been building. Warp has gone from a terminal built from scratch, to what they're calling an "agentic development environment" - a tool that weaves AI agents, a development, a shell and a conversation into a single, unified experience. This may be the future or just one possible path; regardless it's a fascinating glimpse into how our tools might reshape not just how we code, but how we experience programming itself. Whether you're all-in on agentic coding, a skeptic, or somewhere in between, AI is here to stay. Now's the time to figure out what form it's going to take. # Support Developer Voices - Patreon: https://patreon.com/DeveloperVoices - YouTube: https://www.youtube.com/@DeveloperVoices/join -- Episode Links - Warp Homepage: https://warp.dev/ - Warp Pro Free Month (promo code WARPDEVS25): https://warp.dev/ - Previous Warp Episode: https://youtu.be/bLAJvxUpAcg - SWE-bench: https://www.swebench.com/ - TerminalBench: https://github.com/microsoft/TerminalBench - Model Context Protocol (MCP): https://modelcontextprotocol.io/ - Claude Code: https://claude.ai/code - Anthropic Claude: https://claude.ai/ - VS Code: https://code.visualstudio.com/ - Cursor: https://cursor.sh/ - Language Server Protocol (LSP): https://microsoft.github.io/language-server-protocol/ # Connect - Zach on LinkedIn: https://www.linkedin.com/in/zachlloyd/ - Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social - Kris on Mastodon: http://mastodon.social/@krisajenkins - Kris on LinkedIn: https://www.linkedin.com/in/krisjenki...

The $500 Billion Integration Problem, And One Possible Solution (with Marty Pitt)

1 hr 31 min

Ever wondered why data integration is still such a nightmare in 2025? Marty Pitt has built something that might finally solve it. TaxiQL isn't just another query language - it's a semantic layer that lets you query across any system without caring about field names, API differences, or where the data actually lives. Instead of writing endless mapping code between your microservices, databases, and APIs, you describe what your data *means* and let TaxiQL figure out how to get it. In this conversation, Marty walks through the “All Powerful Spreadsheet” moment that sparked TaxiQL, how semantic types work in practice, and why this approach might finally decouple producers from consumers in large organizations. We dive deep into query execution, data lineage, streaming integration, and the technical challenges of building a system that can connect anything to anything. If you've ever spent months mapping fields between systems or maintaining brittle integration code, this one's for you. – Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join – TaxiLang Homepage: https://taxilang.org/ TaxiLang Playground: https://playground.taxilang.org/examples/message-queue-and-database Taxi Lang GitHub repository: https://github.com/taxilang/taxilang OpenAPI Specification (formerly Swagger): https://swagger.io/specification/ YOW! Conference - Australian software conference series: https://yowconference.com/ Spring Framework Kotlin support: https://spring.io/guides/tutorials/spring-boot-kotlin/ Ubiquitous Language (DDD Concept): https://martinfowler.com/bliki/UbiquitousLanguage.html Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ – 0:00 Intro

Making Software Crash Before It Breaks (with Isaac Van Doren)

57 min

At 23, Isaac is already jaded about software reliability - and frankly, he's got good reason to be. When your grandmother can't access her medical records because a username change broke the entire system, when bugs routinely make people's lives harder, you start to wonder: why do we just accept that software is broken most of the time? Isaac's answer isn't just better testing - it's a whole toolkit of techniques working together. He's advocating for scattering "little bombs" throughout your code via runtime assertions, adding in the right amount of static typing, building feedback loops that page you when invariants break, and running nightly SQL queries to catch the bugs that slip through everything else. All building what he sees as a pyramid of software reliability. Weaving into that, we also dive into the Roc programming language, its unique platform architecture that tailors development to specific domains. Software reliability isn’t just about the end user experience - Roc feeds in the idea we can make reliability easier by tailoring the language domain to the problem at hand. – Isaac’s Homepage: https://isaacvando.com/ Episode on Property Testing: https://youtu.be/wHJZ0icwSkc Property Testing Walkthrough: https://youtu.be/4bpc8NpNHRc Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Isaac on LinkedIn: https://www.linkedin.com/in/isaacvando/ Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Making Apache Kafka Diskless (with Filip Yonov & Josep Prat)

1 hr 29 min

How do you retrofit a clustered data-processing system to use cheap commodity storage? That’s the big question in this episode as we look at one of the many attempts to build a version of Kafka that uses object storage services like S3 as its main disk, sacrificing a little latency for cheap, infinitely-scalable disks. There are several companies trying to walk down that road, and it’s clearly big business - one of them recently got bought out for a rumoured $250m. But one of them is actively trying to get those changes back into the community, as are pushing to make Apache Kafka speak object storage natively. Joining me to explain why and how are Josep Prat and Filip Yonov of Aiven. We break down what it takes to make Kafka’s storage layer optional on a per-topic basis, how they’re making sure it’s not a breaking change, and how they plan to get such a foundational feature merged. – Announcement Post: https://aiven.io/blog/guide-diskless-apache-kafka-kip-1150 Aiven’s (Temporary) Fork, Project Inkless: https://github.com/aiven/inkless/blob/main/docs/inkless/README.md Kafka Improvement Process (KIP) Articles: KIP-1150: https://cwiki.apache.org/confluence/display/KAFKA/KIP-1150%3A+Diskless+Topics KIP-1163: Diskless Core: https://cwiki.apache.org/confluence/display/KAFKA/KIP-1163%3A+Diskless+Core KIP-1164: Topic Based Batch Coordinator: https://cwiki.apache.org/confluence/display/KAFKA/KIP-1164%3A+Topic+Based+Batch+Coordinator KIP-1165: Object Compaction for Diskless: https://cwiki.apache.org/confluence/display/KAFKA/KIP-1165%3A+Object+Compaction+for+DisklessSupport Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Filip on LinkedIn: https://www.linkedin.com/in/filipyonov Josep on LinkedIn: https://www.linkedin.com/in/jlprat/ Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://...

Java's Cutting Edge Comeback (with Josh Long)

1 hr 24 min

Java’s has been evolving faster than any 30 year old language has a right to do, and there’s probably no-one more pleased about it than my guest this week - Josh Long. He’s a Java & Kotlin programming, a JVM enthusiast in general, and an advocate for Spring, and he has chapters full of news about what’s been happening in Javaland over the past few years. Everything from new threading models to C interop changes, custom primitives to high performance computing and all the ways in which Java is modernising for age of AI workloads. If you’re out of touch with the latest in the JVM, or don’t know how much its changed, Josh’s brain is full of all the news you need to catch up. – Project Valhalla (Value Objects): https://openjdk.org/projects/valhalla/ Project Panama (JVM’s new native code support): https://openjdk.org/projects/panama/ Jextract: https://github.com/openjdk/jextract Spring Initializer: http://start.spring.io/ Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

The State & Future of Apache Kafka (with Anatoly Zelenin)

1 hr 12 min

I’m joined this week by one of the authors of Apache Kafka In Action, to take a look at the state of Kafka, event systems & stream-processing technology. It’s an approach (and a whole market) that’s had at least a decade to mature, so how has it done? What does Kafka offer to developers and businesses, and which parts do they actually care about? What have streaming data systems promised and what have they actually delivered? What’s still left to build? – Apache Kafka in Action: https://www.manning.com/books/apache-kafka-in-action Pat Helland, Data on the Inside vs Data on the Outside: https://queue.acm.org/detail.cfm?id=3415014 Out of the Tar Pit: https://curtclifton.net/papers/MoseleyMarks06a.pdf Martin Kleppmann, Turning the Database Inside-Out: https://martin.kleppmann.com/2015/11/05/database-inside-out-at-oredev.html Data Mesh by Zhamak Dehghani: https://www.amazon.co.uk/Data-Mesh-Delivering-Data-Driven-Value/dp/1492092398 Quix Streams: https://github.com/quixio/quix-streams XTDB: https://xtdb.com/ Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Anatoly’s Website: https://zelenin.de/ Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins

DataFusion - The Database Building Toolkit (with Andrew Lamb)

1 hr 32 min

Building a database is a serious undertaking. There are just so many parts that you have to implement before you even get to a decent prototype, and so many hours of work before you could begin working on the ideas that would make your database unique. Apache DataFusion is a project that hopes to change all that, but building an extensible, composable toolkit of database pieces, which could let you build a viable database extremely quickly, and then innovate from that starting point. And even if you’re not building a database, it’s a fascinating project to explain how databases are built. Joining me to explain it all is Andrew Lamb, one of DataFusion’s core contributors, and he’s going to take us through the whole stack, how it’s built and how you could use it. Along the way we cover everything from who’s building interesting new databases and how you manage a large, open-source Rust project. – DataFusion Homepage: https://datafusion.apache.org/ DataFusion on Github: https://github.com/apache/datafusion DataFusion Architecture (with diagrams!): https://youtu.be/NVKujPxwSBA?si=tw9ACxlbdpBuVsnv&t=1045 Datalog: https://docs.racket-lang.org/datalog/ Tokio: https://tokio.rs/ Andrew’s Homepage: http://andrew.nerdnetworks.org/ Andrew’s Blog Post about Tokio: https://thenewstack.io/using-rustlangs-async-tokio-runtime-for-cpu-bound-tasks/ Velox: https://velox-lib.io/ Arroyo: https://www.arroyo.dev/ Synnada: https://www.synnada.ai/ LanceDB: https://lancedb.com/ SDF+DBT: https://docs.sdf.com/integrations/dbt/integrating Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Jupyter's Architecture Unpacked (with Afshin Darian & Sylvain Corlay)

1 hr 29 min

Jupyter’s become an incredibly popular programming and data science tool, but how does it actually work? How have they built an interactive language execution engine? And if we understand the architecture, what else could it be used for? Joining me to look inside the Jupyter toolbox are Afshin Darian and Sylvain Corlay, two of Jupyters long-standing contributors and project-steerers. They’ve going to take us on a journey that starts with today’s userbase, goes through the execution protocol and ends with a look at what Jupyter will be in the future - an ambitious framework for interactive, collaborative applications and more. – Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Jupyter Homepage: https://jupyter.org/ Jupyter Xeus: https://github.com/jupyter-xeus/xeus Jupyter AI: https://github.com/jupyterlab/jupyter-ai Jupyter CAD: https://github.com/jupytercad/JupyterCAD Jupyter GIS: https://github.com/geojupyter/jupytergis/ Jupyter GIS Announcement: https://blog.jupyter.org/real-time-collaboration-and-collaborative-editing-for-gis-workflows-with-jupyter-and-qgis-d25dbe2832a6 QGIS: https://qgis.org/ ZeroMQ: https://zeromq.org/ Sylvain on LinkedIn: https://www.linkedin.com/in/sylvaincorlay Darian on LinkedIn: https://www.linkedin.com/in/afshindarian Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Nix, The Build-Everything Language (with Julian Arni)

1 hr 20 min

Ever since we invented makefiles, the programming world has been wrestling with the problem of building software stacks reliably. This week we’re going to look at one of the most ambitious solutions available - Nix. Nix tries to do everything from invoking your compiler to installing your language, and even providing your operating system. But how does it work in theory, and how well does it work in practice? Joining me to discuss is Julian Arni, a Nix-enthusiast and creator of a build/test/deploy service called Garnix. Nix has been one of my go-to tools for years - I hope it’ll find its way into your stack. – Nix Overview: https://nixos.org/explore/ Nix Tutorial: https://nix.dev/tutorials/first-steps/ Nix Flakes: https://nixos.wiki/wiki/Flakes The Nix Package List: https://search.nixos.org/packages Garnix.IO: https://garnix.io/ Julian’s NixCon Talk, Call by Hash: https://www.youtube.com/watch?v=fU9ogB9hZZA Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Graphite: Image Editing as a Syntax Tree (with Keavon Chambers & Dennis Kobert)

1 hr 17 min

Graphite is a new image editor with an interesting architecture - it’s a classic UI-driven app, an image-manipulation language, and a library of programmable graphics primitives that any Rust coder could use, extend or add to. The result is something that you can use like Photoshop or Inkscape, or make use of in batch pipelines, a bit like ImageMagick. Joining me to discuss it are Keavon Chambers & Dennis Kobert, who are hammering away on building a project that’s potentially as demanding as Photoshop, but with a more ambitious architecture. How can they hope to compete? Perhaps in the short term by doing what regular image And is the future of image editing modular? – Graphite Homepage: https://graphite.rs/ Graphite Web Version: https://editor.graphite.rs/ Graphite on Github: https://github.com/GraphiteEditor/GraphiteSigned Distance Fields: https://jasmcole.com/2019/10/03/signed-distance-fields/ Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

ReScript: A Better Typed JavaScript? (with Gabriel Nordeborn)

1 hr 32 min

ReScript is a strongly-typed programming language that compiles to JavaScript, and that puts it squarely in competition with TypeScript. So why would a JavaScript developer choose to learn it next? What does it offer that makes it a tempting proposition? And how are the ReScript developers making life easier for anyone who wants to make the switch? To answer all these questions and more, I’m joined this week by Gabriel Nordeborn, one of ReScript’s compiler contributors.  -- ReScript: https://rescript-lang.org/ ReScript & React: https://rescript-lang.org/docs/react/latest/introduction Reanalyze: https://github.com/rescript-lang/reanalyze Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Gabriel on BlueSky: https://bsky.app/profile/did:plc:c55mqp6e6r24rrrypkmx7ker Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

A universal query engine in Rust (with Predrag Gruevski)

1 hr 15 min

Trustfall is a library based on a simple question - what happens if we can query absolutely anything? If you could join REST APIs and databases with filesystems and dockerfiles? It’s possible in theory because those are all just datasources. Predrag Gruevski is trying to make it easy by building a universal query engine, with pluggable datasources, all in Rust. This week we dive into Trustfall to figure out how it works. How do you model nearly anything as a datasource? How do you make it easy to extend? And what does it take to optimize a query that’s going to be spread out over multiple systems and potentially multiple servers? Questions, questions, questions - all about the act of asking our systems questions. 😃 – Trustfall Source: https://github.com/obi1kenobi/trustfall Cargo Semver Checks: https://crates.io/crates/cargo-semver-checks How to Query Almost Everything: https://predr.ag/querying/ SemVer In Rust (talk): https://predr.ag/blog/semver-in-rust-tooling-breakage-and-edge-cases/#cargo-semver-checks-lints-are-database-queries-in-disguise Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins

Raspberry Pi Hardware & A Lisp Brain (with Dimitris Kyriakoudis)

1 hr 34 min

Dimitris Kyriakoudis is a researcher, programmer and musician who's combining all three talents to build dedicated music hardware. Specifically a device called the µseq, which reads Lisp programs and uses them to drive synthesizers to make music. In this episode we go through the full platform that he's building, from soldering resistors to an RPi chip, up through writing a Lisp interpreter, to the design ideas that make Lisp a good choice for composing both software and music. – uSeq Homepage: https://www.emutelabinstruments.co.uk/useq/ Emute Lab’s Homepage: https://www.emutelab.org/ Buy a uSeq: https://www.signalsounds.com/emute-lab-instruments-useq-live-coding-voltage-generator-eurorack-module/ Build a uSeq (DIY Kit): https://www.thonk.co.uk/shop/emute-lab-useq/ SICP (book): https://en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs Machina Bristronica (expo): https://machinabristronica.uk/ Sonic Pi: https://sonic-pi.net/ Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins – 0:00 Intro 2:20 What is µseq? 5:40 Live Coding As Another Instrument 17:42 Why Choose Lisp? 25:03 Different Dialects For Different Musical Tasks? 32:34 Live Coding As Academic Research 44:11 How Do You Fabricate Production Hardware? 49:00 The Triple-E Triangle 1:09:53 How Well Has This Theory Worked Out? 1:20:01 What's This Like To Play Live? 1:25:17 Comparisons With Sonic Pi 1:33:06 Outro

Software Systems Aren't Just Software (with Diana Montalion)

1 hr 50 min

If you want to build really large software systems well, you have to stop thinking of them as just software systems. Beyond a certain size, everything your software touches becomes part of the wider system. You’re part of the system, your users are part of the system, and every other employee & department & priority eventually forms part of that system. And that can make it incredibly difficult to make changes, or even to understand which changes will actually matter. That might be overwhelming, but there's hope. Understanding how systems work and how to improve them is something that can be learnt, and improved at. So in the pursuit of better systems understanding, I’m joined this week by Diana Montalion, coder, architect, and author of Learning Systems Thinking. She takes us through how she sees systems, and how we can get better at discovering and understanding our own systems, as we both chew through some difficult systems we’ve worked on in the hope of figuring out how to do it better next time… – Learning Systems Thinking (book): https://www.amazon.co.uk/Learning-Systems-Thinking-Essential-Professionals-ebook/dp/B0D9KWZRT2 Diana’s Website: https://montalion.com/ Scientific Management (Tailorism): https://en.wikipedia.org/wiki/Scientific_management Jay Wright Forrester: https://en.wikipedia.org/wiki/Jay_Wright_Forrester Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Diana on LinkedIn: https://www.linkedin.com/in/dianamontalion/ Diana on YouTube: https://www.youtube.com/@dianamontalion Kris on BlueSky: https://bsky.app/profile/krisajenkins.bsky.social Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Building Fyrox: A Rust Game Engine (with Dmitry Stepanov)

1 hr 43 min

To kick off 2025 we’re looking at Fyrox a game engine built in Rust, largely by one person - Dmitry Stepanov. For an individual project, it’s covered an incredible amount of ground, covering the rendering and animation features you’d expect from a game engine, with some features that might surprise you - like Rust scripting support with hot-reloading. As we dive into Fyrox, Dmitry explains what it takes to build a game engine, why he chose Rust (and why he’s happy with the choice), and how one person can hope to build a project of that size. – Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Fyrox Homepage: https://fyrox.rs/ The Fyrox Book: https://fyrox-book.github.io/ Rapier Physics Engine: https://rapier.rs/ The Mine (on Steam): https://store.steampowered.com/app/898980/The_Mine/ Dmitry’s Engine: https://github.com/mrDIMAS/DmitrysEngine GJK Collision Detection Algorithm: https://en.wikipedia.org/wiki/Gilbert%E2%80%93Johnson%E2%80%93Keerthi_distance_algorithm WPF: https://en.wikipedia.org/wiki/Windows_Presentation_Foundation PICO-8: https://www.lexaloffle.com/pico-8.php Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins

Testing TVs At Scale With Elixir (with Dave Lucia)

1 hr 16 min

Integration testing is always a tricky thing, fraught with problems setting up the right environment and attempting to control the system’s state. That’s particularly true when you’re dealing with a mix of software and hardware, and even worse when you don’t have control of what the hardware can do. This week I’m joined by Dave Lucia of TVLab’s, who’s building systems for testing television software at scale, and it’s a problem that needs a huge variety of techniques to crack it. He’s using cameras, real time video processing, Erlang & Elixir and a host of other tools to make it possible to test a fleet of televisions on demand. Sometimes good systems revolve around a single big idea; this time it’s a large combination of solutions, coordinated by the BEAM, that gets the job done. -- TVLabs: https://tvlabs.ai/ Flipper Zero: https://flipperzero.one ATSC 3.0 “NextGen TV”: https://en.wikipedia.org/wiki/ATSC_3.0 Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Programming As An Expressive Instrument (with Sam Aaron)

1 hr 50 min

Sam Aaron is the creator of Sonic Pi, one of the most unusual software platforms you’ll encounter. It’s a live-coding playground for making music. A tool that lets you write code that defines sounds and musical phrases, and build up a hole program that plays anything from a short bleep to a whole nightclub set. And Sam’s creator has been using it live for years, weaving drum & bass nights out of thin air, all driven by the Ruby-esque he writes. In this episode we go through Sam’s career path and design journey as we look at what it takes to make a programming language with enough expressivity and productivity to produce music at the speed of Sam’s imagination. -- Sam’s Sonic Pi Course: https://www.patreon.com/posts/new-introductory-115404746 Sonic Pi: https://sonic-pi.net/ SuperCollider: https://supercollider.github.io/ Overtone: https://github.com/overtone/overtone Power Gloves: https://en.wikipedia.org/wiki/Power_Glove Web Audio API: https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API Tau5: https://www.patreon.com/posts/announcing-sonic-112605951 Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Elm & The Future of Open Source (with Evan Czaplicki)

50 min

Evan Czaplicki—the creator of the Elm programming language —joins me to discuss the state and future of Elm, the friendly, type-safe functional programming language. On many fronts Elm has been a huge success: it’s been popular with new and seasoned programmers alike; it’s helped push several language ideas into the mainstream; it’s been a key part of several successful software businesses and he even found himself employed as a kind of Language Designer in Residence. And yet, the material rewards of a successful open-source project were…lacking. Was he naive? Can an open-source developer stay true to open-source principles and still make a decent living? Is open source being exploited by commercial software businesses? These topics and more tumble out of what has to be the first question in the podcast: What’s happening with Elm? -- Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join ElmLang: https://elm-lang.org/ The Economics Of Programming Languages: https://www.youtube.com/watch?v=XZ3w_jec1v8 Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Programmers, ADHD, And How To Manage Them Both (with Chris Ferdinandi)

1 hr 39 min

This week we’re going to look at the most essential piece of firmware in a programmer’s toolkit - the brain. I’m joined by Chris Ferdinandi to explore what it’s like to be a programmer with ADHD. It’s an unusual topic for the channel, but the more I spoke to him, the more I wanted to know what coding is like when your brain is wired differently, how we can work more effectively with people with ADHD, and critically, how you manage coders with ADHD. And the answer to that comes full circle, in understanding how coders with ADHD manage themselves… – ADHDFTW Homepage: https://adhdftw.com/developer-voices/ Do I Have ADHD? https://adhdftw.com/do-i-have-adhd/ Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Chris on Mastodon: https://mastodon.social/@cferdinandi Chris on BlueSky: https://bsky.app/profile/cferdinandi.bsky.social Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on BlueSky: https://bsky.app/profile/krisajenkins.bsky.social

MicroServices For Better And Worse (with Ian Cooper and James Lewis)

47 min

What have we learned from more than a decade of deploying microservices? Was it a good idea? Are we any better at figuring out what a microservice is, or where its boundaries lie? Does splitting things up create fragmentation problems? And is it too late to put the genie back in the bottle? This week we’re going to look at all these questions and more as we reflect on the lessons learnt from this big architectural idea. This interview was recorded live at GOTO Copenhagen, with two microservice experts and thinkers: James Lewis of Thoughtworks and Ian Cooper of JustEat.  – Residuality Theory: https://leanpub.com/residuality Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Ian on Mastodon: https://mastodon.social/@ICooper@hachyderm.io James on BlueSky: https://bsky.app/profile/boicy.bsky.social Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on BlueSky: https://bsky.app/profile/krisajenkins.bsky.social Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins

Pony: High-Performance, Memory-Safe Actors (with Sean Allen)

1 hr 13 min

Pony is a language born out of what should be a simple need - actor-style programming with C performance. On the face of it, that shouldn’t be too hard to do. Writing an actor framework isn’t trivial, but it’s well-trodden ground. The hard part is balancing performance and memory management. When your actors start passing hundreds of thousands of complex messages around, either you need some complex rules about who owns and frees which piece of memory, or you just copy every piece of data and kill your performance. Pony’s solution is a third way - a novel approach to memory management called reference capabilities. In this week’s Developer Voices, Sean Allen joins us from the Pony team to explain what reference capabilities are, how Pony uses them in its high-performance actor framework, and how they implement a garbage collector without stop-the-world pauses. The result is a language for performant actors, and a set of ideas bigger than the language itself… – Pony: https://www.ponylang.io/ The Pony Tutorial: https://tutorial.ponylang.io/ The Pony Playground: https://playground.ponylang.io/ Azul Garbage Collector: https://www.azul.com/products/components/pgc/ Shenandoah Garbage Collector: https://wiki.openjdk.org/display/shenandoah/Main A String of Ponies (Distributed Actors Paper): https://www.doc.ic.ac.uk/~scb12/publications/s.blessing.pdf Garbage Collection with Pony-ORCA: https://tutorial.ponylang.io/appendices/garbage-collection.html – Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins

Architecting a Rust Game Engine (with Alice Cecile)

1 hr 18 min

This week we take a look at Bevy, a new game engine written in Rust. And in particular, we look at a core component of Bevy that has something to teach you even if you never write a game: its Entity Component System, or ECS. An ECS is an approach to managing complex systems with large numbers of moving parts, that takes some inspiration from the Relational Database world, and a little from Functional Programming to build something entirely unique and surprisingly high-performance. Joining us to explain all is Alice Cecile. She’s part of the Bevy foundation, which is charting a course from data-management and rendering tool to fully-featured game development environment. A journey they’ve made huge progress on, but still expect to take another decade to come to full fruition. We look at the core ECS, and the wider project-management approaches they need to make the journey. – Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Bevy: https://bevyengine.org/ Bevy Examples: https://bevyengine.org/examples/ Flecs (C++): https://github.com/SanderMertens/flecs Tiny Glade (game): https://store.steampowered.com/app/2198150/Tiny_Glade/ Alice on Mastodon: https://mastodon.gamedev.place/@alice_i_cecile Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins

Writing a CAD Language in Rust (with Adam Chalmers)

1 hr 22 min

Given how many languages have been written in C over the years, it’s not surprising to see new languages being written in Rust. What is surprising about this week’s guest is the domain he’s writing for: Computer Aided Design (CAD). Could Rust be sneaking its way into the CAD world too? Joining me to discuss the design and implementation of a CAD programming language is Adam Chalmers. He works at Zoo, developing KCL - a language that looks like JavaScript, runs on Rust, and offers users a seamless hybrid experience of both coding and point-and-click modelling. So, how does that all fit together? In this episode we look at the design and implementation of a programming language in Rust; how KittyCAD creates that hybrid environment for text-based programming and point-and-click modelling; and how we can learn to write our own Rust-interpreted languages. – Adam’s Blog: https://adamchalmers.com/ Adam’s Guide To Writing Parsers: https://www.youtube.com/watch?v=QF3kMyzMC40 Zoo’s Modelling App: https://zoo.dev/modeling-app Mechanical CAD: https://zoo.dev/blog/mechanical-cad-yesterday-today-and-tomorrow A Lego brick in KCL: https://zoo.dev/docs/kcl-samples/lego Winnow: https://docs.rs/winnow/latest/winnow/ Nom: https://docs.rs/nom/latest/nom/ Factorio: https://www.factorio.com/ Satisfactory: https://store.steampowered.com/app/526870/Satisfactory/ Crafting Interpreters: https://craftinginterpreters.com/ Coding in Antarctica: https://brr.fyi/ Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Adam on Mastodon: https://mastodon.social/@adam_chal@hachyderm.io Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins

Text User Interfaces in Rust (with Orhun Parmaksız)

1 hr 6 min

For some kinds of application, there is no faster or cheaper way to build a user interface than in the terminal. Sure, it’s not going to suit every kind of user out there, but for those of us that are happy on the command line, rich Text User Interfaces (or TUIs) open all the exploration and discoverability benefits of a GUI are a fraction of the development time. This week we’re looking at a Rust TUI library with the excellent name ‘ratatui’. We’re joined by Orhun Parmaksız, one of the lead developers and a huge TUI enthusiast on a quest to see how far Text UIs can be pushed. – Ratatui: https://ratatui.rs/ Ratatouille Tutorials: https://ratatui.rs/tutorials/ Tui Realm: https://github.com/veeso/tui-realm Awesome Ratatui: https://github.com/ratatui/awesome-ratatui RTL SDR: https://www.rtl-sdr.com/about-rtl-sdr/ Rust Snake AI: https://github.com/bones-ai/rust-snake-ai-ratatui SystemCtl-Tui: https://github.com/rgwood/systemctl-tui GitU: https://github.com/altsem/gitu …and GitUi: https://github.com/extrawurst/gitui GitCliff Changelog Tool: https://git-cliff.org/ ATAC (Postman in the Terminal): https://github.com/Julien-cpsn/ATAC BubbleTea (TUIs in Golang): https://github.com/charmbracelet/bubbletea Imgcat (images in the terminal): https://github.com/danielgatis/imgcat TachyonFX: https://github.com/junkdog/tachyonfx ASCIITheatre: https://ascii.theater/ Rio Terminal: https://raphamorim.io/rio/ – Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins

Designing The Lustre Web Framework (with Hayleigh Thompson)

1 hr 4 min

Lustre is a web framework that takes a lot of inspiration from Elm, some from React, and a surprising amount from Erlang’s actor model, to provide a library that blurs the lines between executing on the client, or on the server. Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join – Lustre: https://hexdocs.pm/lustre/index.html Gleam: https://gleam.run/ Join the Gleam Community: https://gleam.run/community/ Processing (AV Framework for Java): https://processing.org/ Vue.js: https://vuejs.org/ Svelte: https://svelte.dev/ Elm: https://elm-lang.org/ Elm Table: https://package.elm-lang.org/packages/gribouille/elm-table/5.3.0/ Hayleigh on Twitter: https://x.com/hayleighdotdev Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins

Faust: A Programming Language For Sound (with Romain Michon)

1 hr 18 min

I’m always interested in what factors shape the design of a programming language. This week we’re taking a look at a language that’s wholly shaped by its need to support a very specific kind of program - audio processing. Anything from creating a simple echo sound effect, to building an entire digital instrument based on a 17th-century harpsichord. The language in question is Faust, and this week we’re joined by Romain Michon, who works on and teaches Faust, as we look at how it’s designed, what kind of programmers it's for, and how it does the job of turning audio-pipeline definitions into executable code. And one of the surprising parts of that compilation strategy is the decision to have it compile to multiple targets, from the expected ones like C and Rust, to the exotic destination of FPGAs (Field Programmable Gate Arrays). FPGAs are like reprogrammable circuit boards, and Romain dives into Faust’s attempts to go from a high-level description of an audio program, all the way down to instructions that tell a chip exactly how it should wire itself. So rather aptly for a technology podcast, we start this week with what your ear can hear and go all the way down to logic gates and circuit boards… – Try Faust in the Browser: https://faustide.grame.fr/ Faust Online Course: https://www.kadenze.com/courses/real-time-audio-signal-processing-in-faust/info FPGAs: https://en.wikipedia.org/wiki/Field-programmable_gate_array VHDL: https://en.wikipedia.org/wiki/VHDL Verilog: https://en.wikipedia.org/wiki/Verilog Grame: https://www.grame.fr/ The (Strawberry Jam) Gramophone: https://www.grame.fr/articles/gramophone Gramophone Workshops: https://www.grame.fr/evenements/atelier-gramophones-65ca16b19fec4 Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Tw...

GPUs, from Simulation to Encryption (with Agnès Leroy)

1 hr 3 min

This week we take a look at what you can do with a GPU when you get away from just using it to draw polygons. Agnès Leroy has spent most of her career programming, optimizing and converting programs to run on that oh-so-curious piece of specialised processing hardware, and we go through all the places that journey has taken her. From simulating the flow of fluids in hydroelectric powerstations, to figuring out how to make a new approach to encryption run fast enough to make it practical… – Become a Developer Voices supporter! https://patreon.com/DeveloperVoices A Fully Homomorphic Encryption Scheme (pdf): https://crypto.stanford.edu/craig/craig-thesis.pdf CUDA platform: https://developer.nvidia.com/cuda-zone Rust-CUDA: https://github.com/Rust-GPU/Rust-CUDA And in case anyone was wondering, A List of Hydroelectric Power Stations in France: https://en.wikipedia.org/wiki/Category:Hydroelectric_power_stations_in_France – Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins

The State of Full-Stack OCaml (with António Monteiro)

1 hr 27 min

OCaml has one of the best-loved compilers available, and parts of it are surprisingly pluggable, so it’s not surprising that someone would eventually try to wed OCaml with JavaScript and the web browser. In fact, the ecosystem has gone further, and there are now a bevvy of options for people who want to write OCaml and run it in the browser, or want to write OCaml in the browser, or want to write something that looks like JavaScript but runs OCaml on the backend. Joining me to explore the OCaml-meets-JavaScript world is Antonio Montiero. He’s a key maintainer/contributor for Melange and ReasonML, as well as several other interesting OCaml web projects. We kick off by discussing the benefits of OCaml and how it clicked with him personally, before we dive into how and why the compiler is being adapted and tweaked to take it to a whole new audience of web-hungry developers. – Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Sponsor Antonio’s Work: https://github.com/sponsors/anmonteiro/ – The OCaml Platform: https://ocaml.org/platform OCaml on Discord: https://discuss.ocaml.org/t/ocaml-discord-server/1884 ReasonML: https://reasonml.github.io/en/ What is Melange? https://melange.re/v4.0.0/what-is-melange.html Melange for React Devs: https://react-book.melange.re/ The Melange Playground: https://melange.re/v4.0.0/playground/ js_of_ocaml: https://github.com/ocsigen/js_of_ocaml FUN OCaml Conference: https://fun-ocaml.com/ Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins

Multiplatform Maps Built As Layers on Rust (with Ian Wagner)

1 hr 1 min

Mapping is a hugely complex task to take on. Even if you moved as much of the data-management as you can out to 3rd-party services, you’d still have a tonne of work to do weaving together map tiles, routing information, GPS data, points of interest, search and more. And as if that wasn’t enough, you’d probably want that software to work on a whole range of platforms, so you have to build something that works on iOS, Android and more. It’s little wonder that the space is dominated by a few closed-source projects owned by huge companies with near-limitless resources. But that doesn’t mean the problem can’t be cracked as an open-source project. This week we look at the open source map library Ferrostar. Joining me to discuss it is the project’s lead developer, Ian Wagner, as we explore the problem space and dive down into Ferrostar’s architecture: A core Rust library serving a suite of custom UI shells written in Kotlin, Swift, WASM and TypeScript. Along the way there are tips for anyone attempting to build a map, or wanting to interop Rust with other languages. – Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Ferrostar on Github: https://github.com/stadiamaps/ferrostar Ferrostar user guide: https://stadiamaps.github.io/ferrostar/ MapLibre: https://maplibre.org/ Project OSRM: https://project-osrm.org/ Dioxus (Rust UI framework): https://dioxuslabs.com/ Slint: https://slint.dev/ UniFFI (repo): https://github.com/mozilla/uniffi-rs UniFFI (user guide): https://mozilla.github.io/uniffi-rs/latest/ Beeline (navigation device): https://beeline.co/ Ian on Mastodon: https://fosstodon.org/@ianthetechie Ian on Twitter: https://x.com/ianthetechie Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins

Building a New Terminal App (with Zach Lloyd)

1 hr 7 min

The terminal might be the most used development tool in history. So it’s a little odd that it hasn’t changed that much in the decades since the terminal first came into being. Is the terminal a “completed” project? Or are there new ways to look at it that might make it even more useful? This week’s guest—Zach Lloyd—is convinced the terminal is ripe for a new approach that’s more than just a new coat of paint. And in this episode we dive into what that approach is, what he’s trying to do with the Warp Terminal, and how it’s put together using a combination of Rust and GPU shaders. Along the way we look at what LLMs could do to improve the terminal experience, where the boundary lies between terminal and shell, and where Go has solved some problems and created others over at Warp HQ. – Become a Supporter on Patreon: https://patreon.com/DeveloperVoices Become a Supporter on YouTube: https://www.youtube.com/@developervoices/join Warp Homepage: https://app.warp.dev/referral/VQGWW3 VT100 Information: https://vt100.net/ Game of Life in Rust: https://github.com/krisajenkins/game-of-life-rust Zed (Text editor in Rust): https://zed.dev/ Flutter: https://flutter.dev/ The Painter’s Algorithm: https://en.wikipedia.org/wiki/Painter%27s_algorithm Zach on LinkedIn: https://www.linkedin.com/in/zachlloyd/ Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins – 0:00 Intro 2:22 Why Create A New Terminal? 7:28 Blurring the Lines Between Terminal and Shell 16:04 How Do You Build A Terminal Program? 24:55 Implementing a Terminal in Rust 30:32 Rust Frameworks for GPU Shaders 40:04 Will Any Of This Go Open Source? 42:49 Managing a Mixture of Rust and Go 47:52 What’s the DX of Warp? 51:43 Integrating LLMs into the Terminal 1:05:58 Outro

Building A Programming Language From Its Core (with Peter Saxton)

1 hr 1 min

A language’s AST—it’s abstract syntax tree—is nearly always a hidden implementation detail. It’s not treated as part of the language, but merely the intermediate step between parsing and compiling. But this week’s guest aims to flip that relationship on its head... Peter Saxton joins me to talk about EYG - an AST-first language that defines the fundamental capabilities first, and then stretches out from there to surface syntax and final execution. The result is something that can teach us a lot about how a typed, functional programming language works; how an extensible effects system works; and could make writing a new programming language as easy as defining the syntax you want, and parsing that into EYG's AST.-- EYG Homepage: https://github.com/crowdhailer/eyg-lang TinyGo: https://tinygo.org/ Become a Supporter on Patreon: https://patreon.com/DeveloperVoices Become a Supporter on YouTube: https://www.youtube.com/@developervoices/join Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins

Practical Applications for DuckDB (with Simon Aubury & Ned Letcher)

1 hr 8 min

DuckDB’s become a favourite data-handling tool of mine, simply because it does so many small things well. It can read and write a huge number of data formats; it can infer schemas automatically when you just want to move quickly; and it can interface with most languages, run like lightning on the desktop or be embedded into a webpage. I’m a huge fan. But I’m not nearly as knowledgeable as this week’s two fans, Simon Aubury and Ned Letcher, who’ve just written a book on all the many ways you can use DuckDB and all the hidden tricks and tips that help you make the most of this. So in this episode we’re taking a practical look at DuckDB, what problems it can solve at work, and how to start getting the most out of it. – Getting Started with DuckDB (book): https://packt.link/byKYt DuckDB episode with Hannes Mühleisen: https://youtu.be/pZV9FvdKmLc DuckDB: https://duckdb.org/ dplyr, the data-manipulation language: https://dplyr.tidyverse.org/ duckplyr, DuckDB’s ‘native’ version: https://github.com/duckdblabs/duckplyr Substrait: https://substrait.io/ Observable (Markdown+DuckDB=Reports): https://observablehq.com/framework/ DuckDB’s “friendly” SQL: https://duckdb.org/docs/sql/dialect/friendly_sql.html Community Extensions: https://community-extensions.duckdb.org/ DuckCon #5: https://duckdb.org/2024/08/15/duckcon5.html Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Simon on Twitter: https://x.com/SimonAubury Ned on Twitter: https://x.com/nletcher Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins

Recording and Replaying the Browser (with Justin Halsall)

1 hr 2 min

RRWeb is based on a simple idea: If you capture all the DOM events in a browser session, and when they happened, you could play it back later. Play it back for diagnosing error conditions, for understanding your user’s journey, or for creating demo videos that can be edited element-by-element instead of frame-by-frame. Unfortunately, the simple idea gets tricky when you try to implement, for a whole host of browser specific glitches, differences, and places where the HTML5 spec ran out. It’s exactly the kind of project where might want to use it, but you want someone else to maintain it! Joining us this week is Justin Halsall—a chief contributor to rrweb—to teach us about some of the more barren corners of the browser spec, how he’s fought through them, and what the benefits are on the other side… – RRWeb homepage: https://www.rrweb.io/ RRWeb on Github: https://github.com/rrweb-io/rrweb RecordOnce: https://recordonce.com/ Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join Justin on Twitter: https://x.com/juice10 Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins – 0:00 Intro 3:10 What is rrweb Doing? 6:12 Beginning With A Naive Implementation 9:49 Supporting Canvas Tags 13:05 Exotic HTML 5 Tags Like Midi 14:31 The Internal Data Format 17:39 How Reliable Can This Be In Practice? 23:04 Cross-Browser Support 24:32 Exploring The Use Cases 30:17 Privacy Issues 33:46 Analyzing User Interactions En-Masse 36:40 Is The Spec Greater Than The Tool? 38:20 The Practical Benefits Of Contributing To Open Source 44:45 Updating Recordings After The Website Changes 49:55 Playing Well (Or Badly) With Popular Frameworks 53:21 The Runtime Burden 54:17 What's Coming In The Future? 1:01:02 Outro

Zig as a Multi-OS Build System (with Loris Cro)

1 hr 19 min

The ZigLang team have put an astonishing amount of effort into making Zig work an effective tool for compiling C across different architectures. Work that benefits the Zig language, but also has a chance to benefit languages like Python and Rust. Or indeed, any language that uses native C libraries somewhere in its stack. So this week we’re joined by Loris Cro of the Zig team to dive into how you make a reliable, cross-platform toolchain that can compile C anywhere it finds it. And in doing so,  – Zig Homepage: https://ziglang.org/ Zig on Github: https://github.com/ziglang/zig MingW for Windows: https://www.mingw-w64.org/ All Your Codebase: https://allyourcodebase.com/ Ziglang on PyPi: https://pypi.org/project/ziglang/ Shout out to Whitequark: https://pypi.org/user/whitequark/ Darling: https://www.darlinghq.org/ WineHQ: https://www.winehq.org/ PyPi Stats: https://pypistats.org/packages/__all__ The Zine static site generator: https://zine-ssg.io/ The Zine source code: https://github.com/kristoff-it/zine Loris’ website: https://kristoff.it/ Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins

See all 109 episodes

–

0 ratings from members

5
4
3
2
1

Rate this podcast

Log in to rate and review the shows you listen to.

No reviews yet — be the first member to rate "Developer Voices".

This podcast, its content and its artwork are not owned by, affiliated with, or endorsed by Castquire.

Keep listening

Discover more podcasts like this.

Up next

  1. Nothing queued. Use + Queue on any episode to line it up.

0:00 0:00