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.
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/jextractSpring Initializer: http://start.spring.io/Support Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinKris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.socialKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
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-actionPat Helland, Data on the Inside vs Data on the Outside: https://queue.acm.org/detail.cfm?id=3415014Out of the Tar Pit: https://curtclifton.net/papers/MoseleyMarks06a.pdfMartin Kleppmann, Turning the Database Inside-Out: https://martin.kleppmann.com/2015/11/05/database-inside-out-at-oredev.htmlData Mesh by Zhamak Dehghani: https://www.amazon.co.uk/Data-Mesh-Delivering-Data-Driven-Value/dp/1492092398Quix Streams: https://github.com/quixio/quix-streamsXTDB: https://xtdb.com/Support Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinAnatoly's Website: https://zelenin.de/Kris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
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/datafusionDataFusion Architecture (with diagrams!): https://youtu.be/NVKujPxwSBA?si=tw9ACxlbdpBuVsnv&t=1045Datalog: 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/integratingSupport Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinKris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.socialKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
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/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinJupyter Homepage: https://jupyter.org/Jupyter Xeus: https://github.com/jupyter-xeus/xeusJupyter AI: https://github.com/jupyterlab/jupyter-aiJupyter CAD: https://github.com/jupytercad/JupyterCADJupyter 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-d25dbe2832a6QGIS: https://qgis.org/ZeroMQ: https://zeromq.org/Sylvain on LinkedIn: https://www.linkedin.com/in/sylvaincorlayDarian on LinkedIn: https://www.linkedin.com/in/afshindarianKris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.socialKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
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/FlakesThe Nix Package List: https://search.nixos.org/packagesGarnix.IO: https://garnix.io/Julian's NixCon Talk, Call by Hash: https://www.youtube.com/watch?v=fU9ogB9hZZASupport Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinKris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.socialKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
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/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinKris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.socialKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
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/introductionReanalyze: https://github.com/rescript-lang/reanalyzeSupport Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinGabriel on BlueSky: https://bsky.app/profile/did:plc:c55mqp6e6r24rrrypkmx7kerKris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.socialKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
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.
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_ProgramsMachina Bristronica (expo): https://machinabristronica.uk/Sonic Pi: https://sonic-pi.net/Support Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins–0:00 Intro2:20 What is µseq?5:40 Live Coding As Another Instrument17:42 Why Choose Lisp?25:03 Different Dialects For Different Musical Tasks?32:34 Live Coding As Academic Research44:11 How Do You Fabricate Production Hardware?49:00 The Triple-E Triangle1: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 Pi1:33:06 Outro
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/B0D9KWZRT2Diana's Website: https://montalion.com/Scientific Management (Tailorism): https://en.wikipedia.org/wiki/Scientific_managementJay Wright Forrester: https://en.wikipedia.org/wiki/Jay_Wright_ForresterSupport Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinDiana on LinkedIn: https://www.linkedin.com/in/dianamontalion/Diana on YouTube: https://www.youtube.com/@dianamontalionKris on BlueSky: https://bsky.app/profile/krisajenkins.bsky.socialKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
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/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinFyrox 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/DmitrysEngineGJK Collision Detection Algorithm: https://en.wikipedia.org/wiki/Gilbert%E2%80%93Johnson%E2%80%93Keerthi_distance_algorithmWPF: https://en.wikipedia.org/wiki/Windows_Presentation_FoundationPICO-8: https://www.lexaloffle.com/pico-8.phpKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
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.oneATSC 3.0 “NextGen TV”: https://en.wikipedia.org/wiki/ATSC_3.0Support Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinKris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.socialKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
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-115404746Sonic Pi: https://sonic-pi.net/SuperCollider: https://supercollider.github.io/Overtone: https://github.com/overtone/overtonePower Gloves: https://en.wikipedia.org/wiki/Power_GloveWeb Audio API: https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_APITau5: https://www.patreon.com/posts/announcing-sonic-112605951Support Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinKris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.socialKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
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/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinElmLang: https://elm-lang.org/The Economics Of Programming Languages: https://www.youtube.com/watch?v=XZ3w_jec1v8Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.socialKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
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/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinChris on Mastodon: https://mastodon.social/@cferdinandiChris on BlueSky: https://bsky.app/profile/cferdinandi.bsky.socialKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on BlueSky: https://bsky.app/profile/krisajenkins.bsky.social
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/residualitySupport Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinIan on Mastodon: https://mastodon.social/@ICooper@hachyderm.ioJames on BlueSky: https://bsky.app/profile/boicy.bsky.socialKris on Mastodon: http://mastodon.social/@krisajenkinsKris on BlueSky: https://bsky.app/profile/krisajenkins.bsky.socialKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
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/MainA String of Ponies (Distributed Actors Paper): https://www.doc.ic.ac.uk/~scb12/publications/s.blessing.pdfGarbage Collection with Pony-ORCA: https://tutorial.ponylang.io/appendices/garbage-collection.html–Support Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
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/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinBevy: https://bevyengine.org/Bevy Examples: https://bevyengine.org/examples/Flecs (C++): https://github.com/SanderMertens/flecsTiny Glade (game): https://store.steampowered.com/app/2198150/Tiny_Glade/Alice on Mastodon: https://mastodon.gamedev.place/@alice_i_cecileKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
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=QF3kMyzMC40Zoo's Modelling App: https://zoo.dev/modeling-appMechanical CAD: https://zoo.dev/blog/mechanical-cad-yesterday-today-and-tomorrowA Lego brick in KCL: https://zoo.dev/docs/kcl-samples/legoWinnow: 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/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinAdam on Mastodon: https://mastodon.social/@adam_chal@hachyderm.ioKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
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-realmAwesome Ratatui: https://github.com/ratatui/awesome-ratatuiRTL SDR: https://www.rtl-sdr.com/about-rtl-sdr/Rust Snake AI: https://github.com/bones-ai/rust-snake-ai-ratatuiSystemCtl-Tui: https://github.com/rgwood/systemctl-tuiGitU: https://github.com/altsem/gitu…and GitUi: https://github.com/extrawurst/gituiGitCliff Changelog Tool: https://git-cliff.org/ATAC (Postman in the Terminal): https://github.com/Julien-cpsn/ATACBubbleTea (TUIs in Golang): https://github.com/charmbracelet/bubbleteaImgcat (images in the terminal): https://github.com/danielgatis/imgcatTachyonFX: https://github.com/junkdog/tachyonfxASCIITheatre: https://ascii.theater/Rio Terminal: https://raphamorim.io/rio/–Support Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
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/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join–Lustre: https://hexdocs.pm/lustre/index.htmlGleam: 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/hayleighdotdevKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
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/infoFPGAs: https://en.wikipedia.org/wiki/Field-programmable_gate_arrayVHDL: https://en.wikipedia.org/wiki/VHDLVerilog: https://en.wikipedia.org/wiki/VerilogGrame: https://www.grame.fr/The (Strawberry Jam) Gramophone: https://www.grame.fr/articles/gramophoneGramophone Workshops: https://www.grame.fr/evenements/atelier-gramophones-65ca16b19fec4Support Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
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/DeveloperVoicesA Fully Homomorphic Encryption Scheme (pdf): https://crypto.stanford.edu/craig/craig-thesis.pdfCUDA platform: https://developer.nvidia.com/cuda-zoneRust-CUDA: https://github.com/Rust-GPU/Rust-CUDAAnd 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/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
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/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinSponsor Antonio's Work: https://github.com/sponsors/anmonteiro/–The OCaml Platform: https://ocaml.org/platformOCaml on Discord: https://discuss.ocaml.org/t/ocaml-discord-server/1884ReasonML: https://reasonml.github.io/en/What is Melange? https://melange.re/v4.0.0/what-is-melange.htmlMelange 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_ocamlFUN OCaml Conference: https://fun-ocaml.com/Kris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
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/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinFerrostar on Github: https://github.com/stadiamaps/ferrostarFerrostar 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-rsUniFFI (user guide): https://mozilla.github.io/uniffi-rs/latest/Beeline (navigation device): https://beeline.co/Ian on Mastodon: https://fosstodon.org/@ianthetechieIan on Twitter: https://x.com/ianthetechieKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
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/DeveloperVoicesBecome a Supporter on YouTube: https://www.youtube.com/@developervoices/joinWarp Homepage: https://app.warp.dev/referral/VQGWW3VT100 Information: https://vt100.net/Game of Life in Rust: https://github.com/krisajenkins/game-of-life-rustZed (Text editor in Rust): https://zed.dev/Flutter: https://flutter.dev/The Painter's Algorithm: https://en.wikipedia.org/wiki/Painter%27s_algorithmZach on LinkedIn: https://www.linkedin.com/in/zachlloyd/Kris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins–0:00 Intro2:22 Why Create A New Terminal?7:28 Blurring the Lines Between Terminal and Shell16:04 How Do You Build A Terminal Program?24:55 Implementing a Terminal in Rust30:32 Rust Frameworks for GPU Shaders40:04 Will Any Of This Go Open Source?42:49 Managing a Mixture of Rust and Go47:52 What's the DX of Warp?51:43 Integrating LLMs into the Terminal1:05:58 Outro
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-langTinyGo: https://tinygo.org/Become a Supporter on Patreon: https://patreon.com/DeveloperVoicesBecome a Supporter on YouTube: https://www.youtube.com/@developervoices/joinKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
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/byKYtDuckDB episode with Hannes Mühleisen: https://youtu.be/pZV9FvdKmLcDuckDB: https://duckdb.org/dplyr, the data-manipulation language: https://dplyr.tidyverse.org/duckplyr, DuckDB's ‘native' version: https://github.com/duckdblabs/duckplyrSubstrait: https://substrait.io/Observable (Markdown+DuckDB=Reports): https://observablehq.com/framework/DuckDB's “friendly” SQL: https://duckdb.org/docs/sql/dialect/friendly_sql.htmlCommunity Extensions: https://community-extensions.duckdb.org/DuckCon #5: https://duckdb.org/2024/08/15/duckcon5.htmlSupport Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinSimon on Twitter: https://x.com/SimonAuburyNed on Twitter: https://x.com/nletcherKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
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/rrwebRecordOnce: https://recordonce.com/Support Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinJustin on Twitter: https://x.com/juice10Kris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins–0:00 Intro3:10 What is rrweb Doing?6:12 Beginning With A Naive Implementation9:49 Supporting Canvas Tags13:05 Exotic HTML 5 Tags Like Midi14:31 The Internal Data Format17:39 How Reliable Can This Be In Practice?23:04 Cross-Browser Support24:32 Exploring The Use Cases30:17 Privacy Issues33:46 Analyzing User Interactions En-Masse36:40 Is The Spec Greater Than The Tool?38:20 The Practical Benefits Of Contributing To Open Source44:45 Updating Recordings After The Website Changes49:55 Playing Well (Or Badly) With Popular Frameworks53:21 The Runtime Burden54:17 What's Coming In The Future?1:01:02 Outro
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/zigMingW 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/zineLoris' website: https://kristoff.it/Kris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
Back in 2012, José Valim started building Elixir to as a way to have his ideal programming language running on the same platform as Erlang. Fast-forward 12 years and it's become build anything from distributed infrastructure to notebooks and websites.In this week's Developer Voices, José joins us to tell the history of Elixir in a series of design choices. Which features mattered to him in the early days, and which ones excite him most now. What's going on under the hood to make Elixir tick, and what does its future hold?–Support Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinElixir Homepage: https://elixir-lang.org/Elixir Docs: https://elixir-lang.org/docs.htmlNumerical Elixir: https://github.com/elixir-nxPhoenix: https://phoenixframework.org/Livebook: https://livebook.dev/José's Livebook & Elixir Presentation: https://www.youtube.com/watch?v=pas9WdWIBHsComparing Elixir & Erlang Variables: https://dashbit.co/blog/comparing-elixir-and-erlang-variablesGleam on the BEAM: https://youtu.be/RntfkL8lUY4José on Github: https://github.com/josevalimKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
There's huge pressure on Python at the moment to get faster, ideally without changing at all. One increasingly–popular way of achieving that impossible task is to push the performance critical code down into C, C++, or Rust. And this week we're focussing on the Python route, as we take a look at PyO3.David Hewitt's the principal committer to PyO3, and he joins us to go through the easy parts, the hard parts, and the works in progress, giving us an insight into how Python and Rust work under the hood, and quite how much work it takes to make them work as one.–PyO3 User Guide: https://pyo3.rs/v0.22.0/PyO3 on Github: https://github.com/PyO3/pyo3Polars: https://pola.rs/Tokio: https://tokio.rs/Trio: https://trio.readthedocs.io/Robyn: https://github.com/sparckles/RobynFaster CPython: https://github.com/faster-cpythonMaturin: https://www.maturin.rs/–David on Mastodon: https://fosstodon.org/@davidhewittDavid on Twitter: https://x.com/davidhewittdevKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://x.com/krisajenkins
Most message systems have an opinion on the right way to do inter-systems communication. Whether it's actors, queues, message logs or just plain ol' request response, nearly every tool has decided on The Right Way to do messaging, and it optimises heavily for that specific approach. But NATS is absolutely running against that trend. In this week's episode, Jeremey Saenz joins us to talk about NATS, the Cloud Native Computing Foundation's configurable message-passing and data-transfer system. The promise is a tool that can happily behave like a queue for one channel, a log like another and a request/response protocol for the third, all with a few client flags.But how does that work? What's it doing under the hood, what features does it offer, and what do we lose in return for that flexibility? Jeremy has all the answers as we ask, what is NATS really?–NATS on Github: https://github.com/nats-io/nats-serverNATS Homepage: https://nats.io/Getting Started with NATS: https://youtu.be/hjXIUPZ7ArMDeveloper Voices Episode on Benthos: https://youtu.be/labzg-YfYKwCNCF: https://www.cncf.io/The Ballerina Language: https://ballerina.io/Kris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkinsSupport Developer Voices via Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices via YouTube: https://www.youtube.com/@developervoices/join
Smalltalk is one of those programming languages that's lived out of the mainstream, but often referenced as an influence and an important part of programming history. It's the cornerstone of object-oriented programming, it was into message passing before actors were cool, and it blurs the line between operating system, programming language and personal notebook. But what is it?Joining us to discuss it is Juan Vuletich, the creator of one of Smalltalk's latest incarnations, Cuis. In this episode we cover Smalltalk's history, its design ideas, Cuis's unique implementation and what makes this modern implementation something special.Smalltalk is over 50 years old, but its vision of how computing could work has only begun. Let's see if we can mine some ideas from it to take us into the next generation of computing...--The Cuis Smalltalk Book: https://cuis-Smalltalk.github.io/TheCuisBook/Preface.htmlCuis on Github: https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-DevThe Cuis Community: https://cuis.st/communityA Short History of Cuis: https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/CuisHistory.mdMonticello VCS: https://wiki.squeak.org/squeak/1287Juan's Music Research: https://www.jvuletich.org/research.htmlBack to the Future - The Story of Squeak (pdf): https://dl.acm.org/doi/pdf/10.1145/263700.263754Kris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
This week we take a close look at the language Inko from two perspectives: The language design features that make it special, and the realities of being a language developer.Yorick Peterse joins us to discuss why he's building Inko, and which design sweetspots he's looking for. We begin with memory management, aiming for the kind of developer who wants control, but without the complexities of Rust. Then we look at the designing for concurrency with typed channels, and handling exceptions by removing them and leaning heavily into ADTs and pattern matching.Mixed in with all that is a discussion on the realities of being a programming language developer. How do you figure out how to implement your ideas? What tradeoffs do you make and what kind of programmer do you want to be most useful to? How do you teach people new ideas in programming, and how “different” can you make a language before it feels weird? And perhaps the hardest question of all: How do you fund a new programming language in 2024?–Inko's Homepage: https://inko-lang.org/Yorick's Homepage: https://yorickpeterse.com/Ownership You Can Count On (paper): https://inko-lang.org/papers/ownership.pdf“The Error Model”: https://joeduffyblog.com/2016/02/07/the-error-model/Kris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
I've often wondered how you build a text editor. Like many software projects, it's a simple idea at the core with an almost infinite scope for features. How do you build a solid foundation to expand on? Which features matter for launch? And how do you hope to satisfy the needs of every programmer, working in every language?My guest for this episode is Nathan Sobo. He's tackled this problem once before with the Atom editor, and he's back older & wiser with Zed - a new editor written completely from scratch in Rust. It has a modern UI, a wide spread of language support, and a completely different way of looking at team collaboration. But with so much ambition, what are Zed's priorities, and what's been left for a future version?--Zed Homepage: https://zed.dev/Segment Trees: https://en.wikipedia.org/wiki/Segment_treeRopes: https://en.wikipedia.org/wiki/Rope_(data_structure)Rust Executors: https://rust-lang.github.io/async-book/02_execution/04_executor.htmlMore about Roc: https://youtu.be/DzhIprQan68More about TigerBeetle: https://youtu.be/ayG7ltGRRHsKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
This week on Developer Voices we're talking to Ryan Worl, whose career in big data engineering has taken him from DataDog to Co-Founding WarpStream, an Apache Kafka-compatible streaming system that uses Golang for the brains and S3 for the storage. Ryan tells us about his time at DataDog, along with the things he learnt from doing large-scale systems migration bit-by-bit, before we discuss how and why he started WarpStream. Why re-implement Kafka? What are the practical challenges and cost benefits of moving all your storage to S3? And would he choose Go a second time around?--WarpStream: https://www.warpstream.com/DataDog: https://www.datadoghq.com/Ryan on Twitter: https://x.com/ryanworl Kris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
PostgreSQL is an incredible general-purpose database, but it can't do everything. Every design decision is a tradeoff, and inevitably some of those tradeoffs get fundamentally baked into the way it's built. Take storage for instance - Postgres tables are row-oriented; great for row-by-row access, but when it comes to analytics, it can't compete with a dedicated OLAP database that uses column-oriented storage. Or can it?Joining me this week is Philippe Noël of ParadeDB, who's going to take us on a tour of Postgres' extension mechanism, from creating custom functions and indexes to Rust code that changes the way Postgres stores data on disk. In his journey to bring Elasticsearch's strengths to Postgres, he's gone all the way down to raw datafiles and back through the optimiser to teach a venerable old dog some new data-access tricks. –ParadeDB: https://paradedb.comParadeDB on Twitter: https://twitter.com/paradedbParadeDB on Github: https://github.com/paradedb/paradedbpgrx (Postgres with Rust): https://github.com/pgcentralfoundation/pgrxTantivy (Rust FTS library): https://github.com/quickwit-oss/tantivyPgMQ (Queues in Postgres): https://tembo.io/blog/introducing-pgmqApache Datafusion: https://datafusion.apache.org/Lucene: https://lucene.apache.org/Kris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
The actor model is a popular approach to building scalable software systems. And isn't hard to understand when you're just reading about the beginner's examples. But how do you architect a complex design using the actor model? Which patterns work well? How do you think through it?Joining me to take us through it is Hugh McKee. Hugh's a total actor-model fan, and a Developer Advocate for Lightbend (the company that created the popular actor framework Akka). He takes us from his definition of actors to the designs he's worked on, the patterns he's found most useful, and the interesting meeting-point between actor-based designs and event-based ones.—Wikipedia - Actor Model: https://en.wikipedia.org/wiki/Actor_modelHugh's book, Designing Reactive Systems: https://go.lightbend.com/designing-reactive-systems-role-of-actor-modelHugh on Twitter: https://twitter.com/mckeeh3Hugh on LinkedIn: https://www.linkedin.com/in/mckeehughKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins
Bytewax is a curious stream processing tool that blends a Python surface with a Rust core to produce something that's in a similar vein to Kafka Streams or Apache Flink, but with a fundamentally different implementation. This week we're going to take a look at what it does, how it works in theory, and how the marriage of Python and Rust works in practice…–The original Naiad Paper: https://dl.acm.org/doi/10.1145/2517349.2522738Timely Dataflow: https://github.com/TimelyDataflow/timely-dataflowBytewax the Library: https://github.com/bytewax/bytewaxBytewax the Service: https://bytewax.io/PyO3, for calling Rust from Python: https://pyo3.rs/v0.21.2/Kris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins--#softwaredevelopment #dataengineering #apachekafka #timelydataflow
Mojo is the latest language from the creator of Swift and LLVM. It's an attempt to take some of the best techniques from CPU/GPU-level programming and package them up in a Python-compatible syntax.In this episode we explore why Mojo was created, and what it offers to Python programmers and non-Python programmers alike. How is it built for performance, and which performance features matter? What's its take on functional programming and type systems? And can it marry the high-level programming of Python with the low-level programming of LLVM/MLIR?If you're a Python programmer who needs better performance, a C programmer who expects more from a ‘scripting language', or just someone who'd be happier if Python had a first-class type system, Mojo might well be for you…–Mojo: https://www.modular.com/max/mojoMojo's Roadmap: https://docs.modular.com/mojo/roadmap.htmlThe Mojo Discord: https://discord.com/invite/modularMLIR: https://mlir.llvm.org/Chris's Talks: https://nondot.org/sabre/Resume.html#talksChris on Twitter: https://twitter.com/clattner_llvmKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins–#software #podcast #mojolang #ml #pythonml
Every database has to juggle the need to process new data and to query old data. That task falls to any system that “does stuff and remembers stuff”. But it's quite hard to really optimise one system for both use cases. There are different constraints on new and old data, and as a system gets larger and larger, those differences multiply to breaking point. That's something Twitter's engineers were figuring out in the 2010s.One solution that came up in those years was the Lambda Architecture. A two-pronged approach that recognises the divide between new and old data, and works hard to blend the two together seamlessly in userspace. But that seamless blending is easier said than done. It's nearly all bespoke work.What if you could get it off the shelf? Let someone else do the work of combining two different kinds of database into one neat package? That's the question of the week as we look at the recently open-sourced project Proton, and its attempt to be the Lambda Architecture in a box…–Proton Docs: https://docs.timeplus.com/protonProton Source: https://github.com/timeplus-io/protonTimeplus: https://www.timeplus.com/Kris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins–#podcast #softwareengineering #databases #dataengineering
Rust changed the discussion around memory management - this week's guest hopes to push that discussion even further.This week we're joined by Evan Ovadia, creator of the Vale programming language and collector of memory management techniques from far and wide. He takes us through his most important ones, including linear types, generation references and regions, to see what Evan hopes the future of memory management will look like.If you've been interested in Rust's borrow-check and want more (or want different!) then Evan has some big ideas for you to sink your teeth into.–Vale: https://vale.dev/The Vale Discord: https://discord.com/invite/SNB8yGHEvan's Blog: https://verdagon.dev/homeEvan's 7DRL Entry: https://verdagon.dev/blog/higher-raii-7drl7DRL: https://7drl.com/https://verdagon.dev/grimoire/grimoireWhat Colour Is Your Function?: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/42, the language: https://forty2.is/Verona Language: https://www.microsoft.com/en-us/research/project/project-verona/Austral language: https://austral-lang.org/Surely You're Joking, Mr Feynman! (book): https://www.goodreads.com/book/show/35167685-surely-you-re-joking-mr-feynmanEvan on Twitter: https://twitter.com/verdagonFind Evan in the Vale Discord: https://discord.com/invite/SNB8yGHKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins–#software #programming #podcast #valelang
The “big data infrastructure” world is dominated by Java, but the data-analysis world is dominated by Python. So if you need to analyse and process huge amounts of data, chances are you're in for a less-than-ideal time. The impedance mismatch will probably make your life hard somehow. So there are a lot of projects and companies trying to solve that problem. To bridge those two worlds seamlessly, and many of the popular solutions see SQL as the glue. But this week we're going to look at another solution - ignore Java, treat Kafka as a protocol, and build up all the infrastructure tools you need with a pure Python library. It's a lot of work, but in theory it would make Python the one language for data storage, analysis and processing, at scale. Tempting, but is it feasible? Joining me to discuss the pros, cons, and massive scope of that approach is Tomáš Neubauer. He started off doing real time data analysis for the Maclaren's F1 team, and is now deep in the Python mines effectively rewriting Kafka Streams in Python. But how? How much work is actually involved in porting those ideas to Python-land, and how do you even get started? And perhaps most fundamental of all - even if you succeed, will that be enough to make the job easy, or will you still have to scale the mountain of teaching people how to use the new tools you've built? Let's find out.– Quix Streams on Github: https://github.com/quixio/quix-streamsQuix Streams getting started guide: https://quix.io/get-started-with-quix-streamsQuix: https://quix.io/ Tomáš on LinkedIn: https://www.linkedin.com/in/tom%C3%A1%C5%A1-neubauer-a10bb144Tomáš on Twitter: https://twitter.com/TomasNeubauer0Kris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins --#podcast #softwaredevelopment #datascience #apachekafka #streamprocessing
Erlang wears three hats - it's a language, it's a platform, and it's an approach to making software run reliably once it's in production. Those last two are so interesting I sometimes wonder why those ideas haven't been ported to every language going. How much work would it be?This week we're going to dig right down into that question with Leandro Ostera. He's been working on Riot - a project to bring the best of Erlang's runtime system and philosophy to OCaml. But why OCaml? Is it possible to marry together OCaml's type system with Erlang's dynamic dispatch systems? And what is it about the recent release of OCaml5 that makes the whole project easier?–Leandro's Blog: https://www.abstractmachines.dev/Why Typing Erlang is Hard: https://www.abstractmachines.dev/posts/am012-why-typing-erlang-is-hard/Riot: https://riot.ml/Riot source: https://github.com/riot-ml/riotReasonML: https://reasonml.github.io/ReScript: https://rescript-lang.org/Leandro on Twitter: https://twitter.com/leosteraKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins--#podcast #softwaredevelopment #erlang #ocaml #softwaredesign
The likes of LinkedIn and Uber use Pinot to power some astonishingly high-scale queries against realtime data. The numbers alone would make an impressive case-study. But behind the headline lies a fascinating set of architectural decisions and constraints to get there. So how does Pinot work? How does it process queries? How are the various roles split across a cluster? And equally important - what does it *not* try to achieve.Joining me to go through the nuts and bolts of how Pinot handles SQL queries is Tim Berglund, veteran technology explainer of the realtime-data world. He takes us through Pinot step-by-step, covering the roles of brokers, servers, controllers and minions as we build up the picture of a query engine that's interesting in theory and massively performant in practice.–Apache Pinot: https://pinot.apache.org/Apache Pinot Docs: https://docs.pinot.apache.org/StarTree: https://startree.ai/Event Driven Design episode with Bobby Calderwood: https://youtu.be/V7vhSHqMxusTim on Twitter: https://twitter.com/tlberglundKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins–#podcast #softwaredevelopment #apachepinot #database #dataengineering #sql
TJ DeVries is a core contributor to Neovim and several of its most interesting sub-projects, and he joins us this week to go in depth into how Neovim got started, how it's structured, and what a truly programmable editor has to offer programmers who want the perfect environment.Along the way we look at what we can learn from Neovim's successful fork of the 30-year old codebase from Vim, how it still collaborates with the original project, and what putting Lua at the heart of the system has done for casual tinkerers and hardcore plugin writers alike.Not everyone will come away from this discussion wanting to switch editors, but I'm sure you'll get a newfound appreciation for digging deeper into the developer tools you use everyday.–Neovim: https://neovim.io/Neovim Kickstarter: https://github.com/nvim-lua/kickstart.nvimKickstarter walkthrough video: https://www.youtube.com/watch?v=m8C0Cq9Uv9oA directory of Neovim plugins: https://dotfyle.com/Vimscript's definition of true and false: https://vimhelp.org/eval.txt.html#BooleanTJ on Twitter: https://twitter.com/teej_dvTJ on Twitch: https://www.twitch.tv/teej_dvTJ on YouTube: https://www.youtube.com/@teej_dvKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins–#podcast #software #softwareengineering #dx
Done right, a Hackathon can be a fantastic place to be a programmer - you get time and space to build and learn, in a room full of like-minded people, with swag and prizes to sweeten the deal. It's a great way to pick up new ideas and run with them. But done wrong it can be a waste of time. What's the difference between a good hackathon and a bad one? What do the good ones do right, and what can we learn from that?This week we're talking about the Joy of Hacks with Major League Hacking Co-Founder Jon Gottfried. He's got over 10 years of experience building a Hackathon network that provides the right environment for “structured mucking about with computers”, so we're going to pick his brains.If you're ever attending a Hackathon, organising one, or looking for a way to build or contribute to your local programming community, Jon can help guide you to events that work.--Major League Hacking: https://mlh.io/Major League Hacking's 2024 Event Calendar: https://mlh.io/seasons/2024/eventsGames Week: https://events.mlh.io/events/10848 Jon on Mastodon: https://hachyderm.io/@jonmarkgoJon on LinkedIn: https://www.linkedin.com/in/jonmarkgoJon on Twitter: https://twitter.com/jonmarkgoKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkinsBonus link - The Great American Baking Show 2023: https://www.youtube.com/watch?v=IlWLSAKEedk--#software #podcast #programming #hackathon
One of the most promising techniques for software reliability is property testing. The idea that, instead of writing unit tests we describe some property of our code that ought to always be true, then have the computer figure out thousands of unit tests that try to break that rule.For example, you might say, “No matter which page you visit on my website, there should always be a login button or a logout button.” Then the test's job is to try to break that rule, but clicking around until it finds some combination of clicks fails that assertion. Like, maybe it finds the 404 page, and you realise it was missing the website's normal header.At its best, property testing takes far less work than unit testing, but is far more thorough, because it lets us write the rules and has the computer write the examples. The downside is, it often seems theoretical. It can be hard to apply property testing to real-world cases. Let's fix that.We're joined by Oskar Wickstrom, who's been building all kinds of different systems and bringing property testing with him wherever he goes. We discuss the basics of property testing, then he goes into the advanced and cunning techniques that go beyond the ordinary into testing databases, webpages and more. With a bit of thought, he can help us test a ten times as much code with a tenth of the effort.--Oskar's book, Property Testing a Screencast Editor [ebook]: https://leanpub.com/property-based-testing-in-a-screencast-editorQuickstrom: https://quickstrom.io/F# for Fun & Profit: Property Testing Series: https://fsharpforfunandprofit.com/series/property-based-testing/Linear Temporal Logic: https://en.wikipedia.org/wiki/Linear_temporal_logicThe Quickstrom Paper: https://arxiv.org/abs/2203.11532TodoMVC (One frontend app, many implementations): https://todomvc.com/Oskar on Twitter: https://twitter.com/owickstromKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins--#softwaredevelopment #podcast #programming #testdrivendevelopment #propertytesting
If you ever feel overwhelmed by the number of different programming languages, this week's episode might just offer you some solace, as we talk about an attempt to reunify many of the most popular languages by focussing on the bread & butter things that every language supports.I'm joined by Martin Johansen, who's been working on a new tool called Progsbase. With it, he's created a spec based on all the things programming languages can agree on, and is building a library that can cross-compile between them. Write a program in Java, and it can be automatically translated to PHP, Python and a great deal more.But how far can he take that idea? Is there really enough unity between these languages to build something universal? How do you bridge the divide between manual memory management languages like C and garbage-collected ones like Java? And what would it actually feel like to write code this way? Let's put Martin's plan under the spotlight and find out…–Martin on Twitter: https://twitter.com/martinfjKris on Twitter: https://twitter.com/krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Progsbase homepage: https://www.progsbase.com/The Spec: https://www.progsbase.com/docs/programs/The Progsbase library repository: https://repo.progsbase.com/The Bug Bounty: https://www.progsbase.com/bug-bounty/–#software #programming #podcast #programminglanguages
A lot of programming is split into the mechanical work of writing what you know, and the creative work of figuring out what you don't know. Wouldn't it be nice to automate the mechanical stuff away?Well the good news is we're already automating a lot of it. Every time you run a refactoring tool or a pretty-printer, you're handing boring work off to the computer. But how does that magic work, and how can we do more of it?This week we're joined by one of the authors of OpenRewrite—Jonathan Schneider—to learn how automated code-rewriting tools really work. From the basic approach to the hairy corner cases, to the reality of keeping developers happy with the subjective side of the results.It takes a lot of work to automate work away - this week we'll learn how the work gets done for us too.–OpenRewrite: https://docs.openrewrite.org/Supported Languages: https://docs.openrewrite.org/recipesModerne: https://www.moderne.io/Gradle Lint: https://github.com/nebula-plugins/gradle-lint-pluginChicory (Native JVM WASM): https://github.com/dylibso/chicoryCall Java from Haskell: https://github.com/tweag/inline-java#readmeCall Haskell from Java: https://github.com/nh2/call-haskell-from-anythingKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins–#podcast #software #programming #softwareengineering #refactoring #parsers