Podcasts about Functional programming

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubRead the full transcription of the interview hereMarcin Moskala - Fullstack Kotlin Developer, Founder of Kt. Academy & Author of "Effective Kotlin", et al.Nicola Corti - Staff Android Engineer at Meta, React Native Core Team Member & Open Source LoverRESOURCESMarcinhttps://x.com/marcinmoskalahttps://kt.academyhttps://github.com//marcinmoskalahttps://www.instagram.com/cortinicoNicolahttps://x.com/cortinicohttps://ncorti.comhttps://github.com/cortinicohttps://www.linkedin.com/in/cortinicoLinkshttps://developer.android.com/develop/ui/compose/kotlinhttps://detekt.devhttps://www.abreslav.comhttps://kt.academy/article/ek-compositionhttps://kt.academy/article/books-kotlin-for-developers-readyDESCRIPTIONIn this episode of the "GOTO Book Club", Nicola Corti talks to Marcin Moskala, author of "Effective Kotlin", to unravel the inspiration, evolution, and community impact of his work.Moskala reflects on his decade-long journey with Kotlin, revealing how his book bridges the gap between Java-centric practices and Kotlin's idiomatic potential. The discussion spans essential topics like factory functions, composition over inheritance, and the iterative process behind curating best practices tailored to Kotlin's strengths.Marcin also highlights the "Kotlin for Developers" series and his Give IT Forward initiative, showcasing his commitment to empowering developers and fostering accessible programming education worldwide.RECOMMENDED BOOKSMarcin Moskala • Effective KotlinMarcin Moskala • Kotlin EssentialsMarcin Moskala • Functional KotlinMarcin Moskala • Kotlin CoroutinesMarcin Moskala • Advanced KotlinMarcin Moskala & Igor Wojda • Android Development with KotlinVenkat Subramaniam • Programming KotlinBlueskyTwitterInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Mark Ericksen, creator of the Elixir LangChain framework, joins the Elixir Wizards to talk about LLM integration in Elixir apps. He explains how LangChain abstracts away the quirks of different AI providers (OpenAI, Anthropic's Claude, Google's Gemini) so you can work with any LLM in one more consistent API. We dig into core features like conversation chaining, tool execution, automatic retries, and production-grade fallback strategies. Mark shares his experiences maintaining LangChain in a fast-moving AI world: how it shields developers from API drift, manages token budgets, and handles rate limits and outages. He also reveals testing tactics for non-deterministic AI outputs, configuration tips for custom authentication, and the highlights of the new v0.4 release, including “content parts” support for thinking-style models. Key topics discussed in this episode: • Abstracting LLM APIs behind a unified Elixir interface • Building and managing conversation chains across multiple models • Exposing application functionality to LLMs through tool integrations • Automatic retries and fallback chains for production resilience • Supporting a variety of LLM providers • Tracking and optimizing token usage for cost control • Configuring API keys, authentication, and provider-specific settings • Handling rate limits and service outages with degradation • Processing multimodal inputs (text, images) in Langchain workflows • Extracting structured data from unstructured LLM responses • Leveraging “content parts” in v0.4 for advanced thinking-model support • Debugging LLM interactions using verbose logging and telemetry • Kickstarting experiments in LiveBook notebooks and demos • Comparing Elixir LangChain to the original Python implementation • Crafting human-in-the-loop workflows for interactive AI features • Integrating Langchain with the Ash framework for chat-driven interfaces • Contributing to open-source LLM adapters and staying ahead of API changes • Building fallback chains (e.g., OpenAI → Azure) for seamless continuity • Embedding business logic decisions directly into AI-powered tools • Summarization techniques for token efficiency in ongoing conversations • Batch processing tactics to leverage lower-cost API rate tiers • Real-world lessons on maintaining uptime amid LLM service disruptions Links mentioned: https://rubyonrails.org/ https://fly.io/ https://zionnationalpark.com/ https://podcast.thinkingelixir.com/ https://github.com/brainlid/langchain https://openai.com/ https://claude.ai/ https://gemini.google.com/ https://www.anthropic.com/ Vertex AI Studio https://cloud.google.com/generative-ai-studio https://www.perplexity.ai/ https://azure.microsoft.com/ https://hexdocs.pm/ecto/Ecto.html https://oban.pro/ Chris McCord's ElixirConf EU 2025 Talk https://www.youtube.com/watch?v=ojL_VHc4gLk Getting started: https://hexdocs.pm/langchain/gettingstarted.html https://ash-hq.org/ https://hex.pm/packages/langchain https://hexdocs.pm/igniter/readme.html https://www.youtube.com/watch?v=WM9iQlQSFg @brainlid on Twitter and BlueSky Special Guest: Mark Ericksen.

Connor Rigby joins the Elixir Wizards to talk about Blue Heron BLE (Bluetooth Low Energy) support for Elixir apps. Blue Heron implements the BLE specs in pure Elixir, leveraging binary pattern matching and concurrent message processing to handle Bluetooth protocols. Unlike most solutions that require C ports or NIFs, Blue Heron runs entirely in user space, so it works seamlessly in both Nerves-based embedded projects and (eventually) desktop Elixir applications. We discuss how Nerves development differs from building Phoenix apps. Connor shares challenges he's experienced with hardware compatibility, where some chips only partially implement the spec, and he discusses the surprisingly deep (but sometimes incomplete) world of BLE device profiles. His tip for anyone entering the BLE space: read the official spec instead of trusting secondhand blog posts. Tools like Nerves LiveBook give you hands-on examples, so you can get a BLE prototype running on a Raspberry Pi and your phone in no time. Key topics discussed in this episode: Blue Heron origins and “bird” naming convention BLE vs. Bluetooth Classic: core differences Pure Elixir implementation—no C dependencies Binary pattern matching for packet parsing Hardware transport options: UART, SPI, USB, SDIO GenServer patterns in Nerves vs. Phoenix Linux requirement and power-consumption trade-offs GATT (Generic Attribute Table) implementation patterns SQLite integration for Nerves apps Hardware chip quirks and spec compliance Manufacturer-specific commands and workarounds BLE device profiles and spec gaps Security Management Profile (SMP) for encryption Device connection and pairing workflows Web vs. embedded development differences Where to get started: hardware recommendations and docs Links mentioned: https://github.com/ConnorRigby/ https://github.com/blue-heron/ https://nerves-project.org/ BLE (Bluetooth Low Energy) https://en.wikipedia.org/wiki/BluetoothLowEnergy https://developer.apple.com/ibeacon/ https://learnyousomeerlang.com/building-otp-applications Linux https://www.linux.org/ HCI (Host Controller Interface) https://en.wikipedia.org/wiki/Hostcontrollerinterface Circuits UART Library https://hexdocs.pm/circuitsuart/readme.html SPI (Serial Peripheral Interface) https://github.com/elixir-circuits/circuitsspi SDIO (Secure Digital Input Output https://en.wikipedia.org/wiki/SDIO Raspberry Pi https://www.raspberrypi.com/ Coral SoM Dev Board https://coral.ai/products/dev-board/ BeagleBone Single-Board Linux Computer https://www.beagleboard.org/boards/beaglebone-black https://www.bluetooth.com/bluetooth-resources/intro-to-bluetooth-gap-gatt/ Genservers https://hexdocs.pm/elixir/1.12/GenServer.html https://hexdocs.pm/ecto/Ecto.html https://github.com/elixir-sqlite/ectosqlite3 https://github.com/nerves-livebook/nerveslivebook Special Guest: Connor Rigby.

In this episode of Beam Radio, Andrew Ek and Bruce Tate welcome Zach Daniel to discuss his journey with Elixir, the impact of the Ash framework, and the introduction of Igniter, a code generation and patching tool. We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts: Twitter: @akoutmos @ektastrophe @meryldakin @redrapids Bluesky @akoutmos.bsky.social @ektastrophe.bsky.social @lawik.bsky.social @RedRapids.bskysocial Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

In the Season 14 premiere, hosts Dan Ivovich and Sundi Myint chat with Isaac Yonemoto, creator of the Zigler library, to explore how Zigler brings Zig's performance and safety to Elixir through Native Implemented Functions (NIFs). Isaac walks through the core design of Zigler and how it auto-generates the Elixir-to-Zig bridge, enforces type safety, and exposes multiple execution modes (normal, dirty, threaded). The conversation covers real-world applications, from SIMD-powered token selection for LLM hardware acceleration to OTP-style fault tolerance in low-level code. Isaac shares his own journey: stepping back from professional software work to launch a biotech startup focused on reducing drug manufacturing costs while continuing to maintain Zigler and even leveraging Elixir for bioinformatics pipelines. Topics discussed in this episode: What is the Zigler library and what does it do? What does it mean to run a "dirty NIF"? Async mode is temporarily removed from Zig (therefore, yielding NIFs is temporarily deprecated in Zigler) Zigler's three execution modes (normal, dirty, and threaded) and how you switch modes with a single config change Isaac's journey from professional software work to launching a biotech startup How Isaac leverages Elixir in bioinformatics pipelines at his startup LLM hardware acceleration using Zigler NIFs and SIMD-powered token picking Fault-tolerant load balancing of NIF workloads via OTP principles Transparent handling and recovery from hardware failures through monitoring Potential future memory-safety features in Zig and their implications The Elixir-based borrow-checker prototype: purpose and design Unit-checking for scientific computations to enforce correctness New OS support in Zigler 0.14: macOS, Windows, and FreeBSD Inline Zig code authoring directly within Elixir modules Isaac's commitment to maintain Zigler through its 1.0 release (...and beyond?) Links mentioned: https://github.com/E-xyza/zigler https://github.com/ziglang/zig https://vidalalabs.com/ Zig Programming Language: https://ziglang.org/ https://obsidian.md/ https://hexdocs.pm/elixir/macros.html https://erlang.org/documentation/doc-4.7.3/doc/extensions/macros.html A Deep Dive Into the Elixir AST: https://dorgan.ar/posts/2021/04/theelixirast/ https://www.erlang.org/doc/system/nif.html https://nodejs.org/en Llama Open-Source LLM: https://www.llama.com/ Mixtral Open-Source LLM: https://mistral.ai/news/mixtral-of-experts https://Fly.io SIMD: https://en.wikipedia.org/wiki/Singleinstruction,multiple_data https://opentrons.com/ CI/CD: https://en.wikipedia.org/wiki/CI/CD https://hexdocs.pm/zigler/Zig.html http://www.x.com/DNAutics https://bsky.app/profile/dnautics.bsky.social

In this episode, Conor and Ben chat about algorithms / combinators in C++26 Senders and Receivers.Link to Episode 235 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)SocialsADSP: The Podcast: TwitterConor Hoekstra: Twitter | BlueSky | MastodonBen Deane: Twitter | BlueSkyShow NotesDate Generated: 2025-05-13Date Released: 2025-05-23C++26 Senders and ReceiversThe Evolution of Functional Programming in C++ - Abel Sen - C++Online 2024C++23 std::flat_mapCppNorth 2023: Composition Intuition - Conor HoekstraC++Now 2023: Applicative: the Forgotten Functional Pattern - Ben DeaneC++Now 2019: Ben Deane “Identifying Monoids: Exploiting Compositional Structure in Code”C++ std::optional::and_thenHaskell joinIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

Andy is convinced that functional programming isn't boring. Listen to find out if he's right!   Functional Programming & Haskell Beautiful Racket Functional Programming & Haskell – Computerphile         Support us on Patreon and get an ad-free RSS feed with early episodes sometimes   See our contact page for ways to get... Read More

Andy is convinced that functional programming isn't boring. Listen to find out if he's right!   Functional Programming & Haskell Beautiful Racket Functional Programming & Haskell – Computerphile         Support us on Patreon and get an ad-free RSS feed with early episodes sometimes   See our contact page for ways to get... Read More

Jemima Abu, Senior Product Engineer at CAIS, joins the podcast to unpack her no-fluff approach to functional programming in JavaScript. From why predictable code matters to how higher-order functions like map and reduce can save your sanity, Jemima breaks down real-world lessons on purity, immutability, and when it's okay to not be a functional purist. Links https://v3.jemimaabu.com https://www.jemimaabu.com https://www.linkedin.com/in/jemimaabu https://x.com/jemimaabu https://github.com/jemimaabu We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Jemima Abu.

A fabulous converstation with Davide Bettio and Paul Guyot about AtomVM - the Erlang virtual machine for IoT devices. https://www.atomvm.net/ https://github.com/bettio https://github.com/pguyot We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts: Bluesky @akoutmos.bsky.social @ektastrophe.bsky.social @lawik.bsky.social @RedRapids.bskysocial Twitter: @akoutmos @ektastrophe @meryldakin Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

In this episode of Beam Radio, hosts Andrew Ek and Lars Wikman welcome Josh Price from Alembic. They discuss the recent AlchemyConf, the value of smaller conferences, and the importance of community in the Elixir ecosystem. Josh shares insights on how Ash simplifies the process of building applications, integrates with AI, and future-proofs projects. We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts: Bluesky @akoutmos.bsky.social @ektastrophe.bsky.social @lawik.bsky.social @RedRapids.bskysocial Twitter: @akoutmos @ektastrophe @meryldakin @redrapids Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

NX provides a powerful framework for machine learning in Elixir and Lars, Andrew and Paulo Valente take a deep dive into it! Connect with Paulo on Bluesky - @polvalente.social Come join us! GigCityElixir and NervesConf US - May 8-10, Chattanooga, TN GigCityElixir.com (https://www.gigcityelixir.com/) Goatmire Elixir and NervesConf - Sept 10-12, Varburg, Sweden Goatmire.com (https://goatmire.com/) We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts: Twitter: @akoutmos @ektastrophe @meryldakin @redrapids Bluesky @akoutmos.bsky.social @ektastrophe.bsky.social @lawik.bsky.social @RedRapids.bskysocial Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

This week's episode contains segments on AI / ML Roadshow - India, SAP Developer Challenge March - SAP Community Escape House – AI, Functional Programming episodes on Hands-on SAP Dev, Flat Josh travels from Heidelberg to Philly and to NSQ SAP office, Code Connect – Call For Proposals closing on 10 March

In this conversation, Lars and Chris delve into the intersection of Elixir, data engineering, and data science. They explore the significance of data pipelines, the role of Elixir in transforming data, and the challenges faced in data processing. Find Chris on Bluesky (@cigrainger.bsky.social) and on the Elixir Forum. Keep up to date with our hosts: Bluesky @akoutmos.bsky.social @ektastrophe.bsky.social @lawik.bsky.social @RedRapids.bskysocial Twitter: @akoutmos @ektastrophe @meryldakin @redrapids Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

Jak and Lars have a delightful conversation about Gleam, the language's type safety, adoption and ecosystem growth. Find Jak: giacomocavalieri.me (giacomocavalieri.me) @giacomo_cava (https://x.com/giacomo_cava) We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts: Twitter: @akoutmos @ektastrophe @meryldakin @redrapids Bluesky @akoutmos.bsky.social @ektastrophe.bsky.social @lawik.bsky.social @RedRapids.bskysocial Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

In this conversation, Bruce, Andrew, and James discuss their experiences with Elixir programming, the importance of exploring and modeling in software development, and innovative educational approaches using Livebook. James E. Gray II @JEG2@genserver.social https://www.linkedin.com/in/james-edward-gray-ii/ Upcoming Conferences: https://codebeamamerica.com/ https://www.gigcityelixir.com/ https://goatmire.com/ Designing Elixir Systems with OTP (Gray/Tate) https://www.pragprog.com/titles/jgotp/designing-elixir-systems-with-otp/ We want to connect with you! Twitter: @BeamRadio1 Send us your questions #ProcessMailbox Keep up to date with our hosts: Twitter: @akoutmos @ektastrophe @meryldakin @redrapids Bluesky @akoutmos.bsky.social @ektastrophe.bsky.social @lawik.bsky.social @RedRapids.bskysocial Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

The panel chats about making Elixir easy to learn for devs from other languages and how to talk about Elixir in the greater development community. This the episode to share with all your friends that need to learn Elixir and companies that should be using it. https://peterullrich.com/ https://bsky.app/profile/peterullrich.com We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts: Twitter: @akoutmos @ektastrophe @meryldakin @redrapids Bluesky @akoutmos.bsky.social @ektastrophe.bsky.social @lawik.bsky.social @RedRapids.bskysocial Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

David MacQueen has worked at Bell Labs for around 20 years during it's Golden Age. Professor at Chicago University for 23 years. He is one of the designers of SML, one of the fathers of HOPE the programming language that introduced the notion of Algebraic Datatypes. So this interview was very special to me personally where I could get to hear all the stories about the dawn of Functional Programming as we know. And it is my great pleasure to have the honor to share it with you all. Links David's Website David's Github Luca Cardelli and the Early Evolution of ML The History of SML HOPE SML Website SML/NJ Website SML/NJ Github SML Family Website

For the Season 13 finale, Elixir Wizards Dan and Charles are joined by Spin42 Engineers Marc Lainez, Thibault Poncelet, and Loïc Vigneron to discuss their work retrofitting a 2007 VW Polo and creating an Open Vehicle Control System (OVCS). Using Elixir, Nerves, and Raspberry Pis, the team is reimagining vehicle technology to extend the lifespan of older cars and reduce waste—all while making the process approachable and open source. The Spin42 team shares the technical details behind OVCS and how they use Elixir and Nerves to interact with the CAN bus and build a Vehicle Management System (VMS) to coordinate various vehicle components. They dive into the challenges of reverse engineering CAN messages, designing a distributed architecture with Elixir processes, and ensuring safety with fail-safe modes and emergency shutoffs. Beyond the technical, the team discusses their motivation for the project—upgrading older vehicles with modern features to keep them on the road, building an open-source platform to share their findings with others, and above all-- to just have fun. They explore potential applications for OVCS in boats, construction equipment, and other vehicles, while reflecting on the hurdles of certifying the system for road use. If you've ever wondered how Elixir and Nerves can drive innovation beyond software, this episode is packed with insights into automotive computing, hardware development, and the collaborative potential of open-source projects. Topics Discussed in this Episode: Retrofitting a 2007 VW Polo with electric engines and modern tech Building an open-source Vehicle Control System (OVCS) using Elixir and Nerves Leveraging Elixir to interact with the CAN bus and parse proprietary messages Designing a Vehicle Management System (VMS) to coordinate vehicle components Developing custom hardware for CAN communication Creating a YAML-based DSL for CAN message and frame descriptions Building a distributed architecture using Elixir processes Ensuring safety with fail-safe modes and emergency shutoffs Using Flutter and Nerves to build a custom infotainment system Exploring autonomous driving features with a ROS2 bridge Developing remote control functionality with a Mavlink transmitter Testing OVCS features at scale with a Traxxas RC car (OVCS Mini) Challenges of certifying OVCS for road use and meeting regulatory requirements Encouraging community contributions to expand OVCS functionality Balancing open-source projects with contract work to sustain development The fun and fulfillment of experimenting with Elixir beyond traditional applications Links mentioned: https://www.spin42.com/ https://nerves-project.org/ Quadcopter https://github.com/Spin42/elicopter https://github.com/linux-can/can-utils https://docs.kernel.org/networking/can.html https://github.com/open-vehicle-control-system/cantastic https://github.com/commaai/opendbc https://en.wikipedia.org/wiki/CANbus#CANFD https://comma.ai/ https://en.wikipedia.org/wiki/CANFD https://webkit.org/wpe/ https://docs.nvidia.com/jetson/archives/r35.4.1/DeveloperGuide/text/SD/WindowingSystems/WestonWayland.html https://buildroot.org/ https://vuejs.org/ https://flutter.dev/ https://github.com/smartrent/elixirflutterembedder https://www.raspberrypi.com/products/raspberry-pi-5/ The Rabbit Pickup https://www.hemmings.com/stories/value-guide-1980-83-volkswagen-pickup https://www.expresslrs.org/software/mavlink https://industrial-training-master.readthedocs.io/en/melodic/source/session7/ROS1-ROS2-bridge.html https://github.com/ros2/rcl https://github.com/open-vehicle-control-system/traxxas Contact Marc, Thibault, and Loïc: info@spin42.com Special Guests: Loïc Vigneron, Marc Lainez, and Thibault Poncelet.

The Elixir Wizards welcome Jim Freeze, organizer of ElixirConf and creator of the Horizon library. Jim shares his journey from organizing Ruby conferences to founding and growing ElixirConf into the community cornerstone it is today. He reflects on the challenges of running a major conference, how COVID-19 shaped the event, and why the talks remain an evergreen resource for the Elixir ecosystem. We discuss Horizon, Jim's deployment library for Elixir and Phoenix applications with Postgres on FreeBSD. Driven by a need for simplicity and cost-effectiveness, Jim explains how Horizon minimizes external dependencies while delivering fault-tolerant and streamlined setups. He compares it to tools like Fly, Terraform, and Ansible, highlighting its low cognitive load and flexibility—key benefits for developers seeking more control over their deployment environments. Jim also unpacks the broader value of understanding and customizing your deployment stack rather than relying solely on managed services. He discusses the benefits of using FreeBSD, including its stability, security, and performance advantages, as well as its robust ZFS file system. Jim emphasizes the importance of coherent deployment workflows, community collaboration, and contributions to open-source projects like Horizon. He invites listeners to explore Horizon, share feedback, and own their deployments. Topics discussed in this episode: Jim Freeze's background organizing RubyConf and founding ElixirConf Reducing reliance on managed services and external dependencies Simplifying deployments with minimal tools and lower cognitive overhead The trade-offs of cutting-edge tools vs. stable, well-documented solutions The importance of customizing deployment tools to meet specific needs Addressing challenges with Tailwind compatibility Streamlining the FreeBSD installation process for Horizon users Community collaboration: contributing to open-source tools Jim's vision for Horizon: PKI support, hot standby features, and serverless potential Links mentioned Nine Minutes of Elixir (https://youtu.be/hht9s6nAAx8?si=ocrk1wQtGplSGL0B) https://www.youtube.com/@ElixirConf https://github.com/liveview-native https://github.com/elixir-nx/nx https://2024.elixirconf.com/ https://github.com/jfreeze/horizon https://hexdocs.pm/horizon/deploying-with-horizon.html#web-cluster-topology https://kamal-deploy.org/ https://fly.io/ https://aws.amazon.com/console/ https://www.digitalocean.com/ https://cloud.google.com/ https://www.cloudflare.com/ https://www.hetzner.com/ https://www.proxmox.com/en/ https://nginx.org/ https://github.com/openzfs/zfs Zettabyte File System https://en.wikipedia.org/wiki/ZFS https://www.postgresql.org/ https://www.terraform.io/ https://www.ansible.com/ https://docs.freebsd.org/ https://www.redhat.com/ https://ubuntu.com/ https://esbuild.github.io/ Listener's Survey: https://smr.tl/EWS13 Special Guest: Jim Freeze.

Zack Kayser and Ethan Gunderson, Software Engineers at Cars Commerce, join the Elixir Wizards to share their expertise on telemetry and observability in large-scale systems. Drawing from their experience at Cars.com—a platform handling high traffic and concurrent users—they discuss the technical and organizational challenges of scaling applications, managing microservices, and implementing effective observability practices. The conversation highlights the pivotal role observability plays in diagnosing incidents, anticipating system behavior, and asking unplanned questions of a system. Zack and Ethan explore tracing, spans, and the unique challenges introduced by LiveView deployments and WebSocket connections. They also discuss the benefits of OpenTelemetry as a vendor-agnostic instrumentation tool, the significance of Elixir's telemetry library, and practical steps for developers starting their observability journey. Additionally, Zack and Ethan introduce their upcoming book, Instrumenting Elixir Applications, which will offer guidance on integrating telemetry and tracing into Elixir projects. Topics Discussed: Cars.com's transition to Elixir and scaling solutions The role of observability in large-scale systems Uncovering insights by asking unplanned system questions Managing high-traffic and concurrent users with Elixir Diagnosing incidents and preventing recurrence using telemetry Balancing data collection with storage constraints Sampling strategies for large data volumes Tracing and spans in observability LiveView's influence on deployments and WebSocket behavior Mitigating downstream effects of socket reconnections Contextual debugging for system behavior insights Observability strategies for small vs. large-scale apps OpenTelemetry for vendor-agnostic instrumentation Leveraging OpenTelemetry contrib libraries for easy setup Elixir's telemetry library as an ecosystem cornerstone Tracing as the first step in observability Differentiating observability from business analytics Profiling with OpenTelemetry Erlang project tools The value of profiling for performance insights Making observability tools accessible and impactful for developers Links Mentioned https://www.carscommerce.inc/ https://www.cars.com/ https://hexdocs.pm/telemetry/readme.html https://kubernetes.io/ https://github.com/ninenines/cowboy https://hexdocs.pm/bandit/Bandit.html https://hexdocs.pm/broadway/Broadway.html https://hexdocs.pm/oban/Oban.html https://www.dynatrace.com/ https://www.jaegertracing.io/ https://newrelic.com/ https://www.datadoghq.com/ https://www.honeycomb.io/ https://fly.io/phoenix-files/how-phoenix-liveview-form-auto-recovery-works/ https://www.elastic.co/ https://opentelemetry.io/ https://opentelemetry.io/docs/languages/erlang/ https://opentelemetry.io/docs/concepts/signals/traces/ https://opentelemetry.io/docs/specs/otel/logs/ https://github.com/runfinch/finch https://hexdocs.pm/telemetry_metrics/Telemetry.Metrics.html https://opentelemetry.io/blog/2024/state-profiling https://www.instrumentingelixir.com/ https://prometheus.io/ https://www.datadoghq.com/dg/monitor/ts/statsd/ https://x.com/kayserzl https://github.com/zkayser https://bsky.app/profile/ethangunderson.com  https://github.com/open-telemetry/opentelemetry-collector-contrib Special Guests: Ethan Gunderson and Zack Kayser.

How it started and how it's going - an enlightening chat with Björn Gustavsson about Erlang/Elixir history. Read the Erlang/OTP blog (https://www.erlang.org/blog) We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts: Twitter: @akoutmos @ektastrophe @meryldakin @redrapids Bluesky @akoutmos.bsky.social @ektastrophe.bsky.social @lawik.bsky.social @RedRapids.bskysocial Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

AJ (Alykhan Jetha), CEO and CTO of Marketcircle, joins the Elixir Wizards to share his experience building and evolving Daylite, their award-winning CRM and business productivity app for Apple users. He details his experiences as a self-taught programmer and how Marketcircle has navigated pivots, challenges, and opportunities since its founding in 1999. AJ explains why they migrated Daylite's backend to Elixir, focusing on their sync engine, which demands high concurrency and fault tolerance. He highlights how Elixir has improved performance, reduced cloud costs, and simplified development with its approachable syntax and productive workflows. The conversation also touches on the technical hurdles of deploying native apps for Apple devices and the potential for integrating new technologies like LiveView Native to streamline cross-platform development. For technical founders, AJ emphasizes the importance of leveraging your strengths (“superpowers”), staying deeply connected to the development process, and finding stability in tools like Elixir amidst a rapidly evolving tech ecosystem. He also shares Marketcircle's roadmap for migrating more customers to Elixir-powered systems and explores the potential for new features in their native apps. Tune in for insights on building resilient systems, navigating technical and business challenges, and how Elixir is shaping Marketcircle's future. Topics discussed in this episode: AJ's journey as a self-taught programmer and entrepreneur Marketcircle's evolution since 1999 and lessons from their pivots Daylite's growth as a flagship product for Apple users Migrating to Elixir for high concurrency and fault tolerance How Elixir improved performance and reduced cloud costs The simplicity of Elixir and its impact on developer onboarding Challenges in managing a growing microservices architecture Insights into deploying native apps for the Apple ecosystem Exploring LiveView Native for future cross-platform development Advice for technical founders: leveraging your superpowers Staying connected to development to maintain system understanding The role of Elixir in improving development efficiency and stability Planning gradual customer migrations to an Elixir-powered backend Potential new features for Daylite's native apps Benefits of collaboration with the Elixir community #ElixirMullet -- native app in the front, Elixir in the back Navigating a rapidly evolving tech ecosystem as a founder Leveraging Elixir to future-proof Marketcircle's systems Balancing technical and business priorities in a startup environment AJ's thoughts on the future of Elixir in powering business tools Links mentioned: https://www.marketcircle.com/ Daylite.app https://www.nextcomputers.org/ https://www.digitalocean.com/ Python Async https://docs.python.org/3/library/asyncio.html https://github.com/sinatra/sinatra https://github.com/dependabot https://kafka.apache.org/ https://www.djangoproject.com/ https://github.com/socketry/falcon https://github.com/puma/puma https://www.swift.org/blog/announcing-swift-6/ https://en.wikipedia.org/wiki/Async/await https://www.ffmpeg.org/ https://www.sqlite.org/ https://github.com/commanded/commanded https://pragprog.com/titles/khpes/real-world-event-sourcing/ https://en.wikipedia.org/wiki/ShipofTheseus https://reactnative.dev/ https://www.electronjs.org/ https://en.wikipedia.org/wiki/WebOS https://www.linkedin.com/in/alykhanjetha/ https://bsky.app/profile/ajetha.bsky.social Special Guest: Alykhan Jetha.

Lars talks with Brian Underwood about EctoWatch, his library. "EctoWatch allows you to easily get notifications about database changes directly from PostgreSQL." Find more from Brian at Brian-underwood.codes (Brian-underwood.codes) We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts: Twitter: @akoutmos @ektastrophe @meryldakin @redrapids Bluesky @akoutmos.bsky.social @ektastrophe.bsky.social @lawik.bsky.social @RedRapids.bskysocial Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

Did you know the best way to bring down hackers is to punch them in the face? That if you don't have a seven screen set up you're a rogue amateur? Or that the best hackers have fins?This Episode we are joined by Simon Painter a senior software engineer with nearly 20 years of experience in the industry and author of the book Functional Programming with C#.In this episode, Hack The Movies! The Best And Worst Hacker Movies Part 2! Our regular programming has been hijacked to bring you a discussion on the best, and worst, hacker movies! In this episode we cover The Beekeeper (2024), Swordfish (2001), Jonny Mnemonic (1995), Paper Man (1971) and The Italian Job (1969).So boot up that modem, turn off the lights and enter the deepest darkest web of hacker forums, and try not overload your memory bank, as we explore this sometimes brilliant and sometimes bonkers sub-genre!Show NotesA Developer Goes to The Movies! Simon's fantastic history on how technology features in filmsPaper Man (1971)About SIMON PAINTERWith nearly 20 years of software engineering experience across various industries, Simon is a Senior Software Engineer at Talos360. Simon is also a Microsoft Most Valuable Professional (MVP) since 2023, an O'Reilly technical book author, and a public speaker at IT events worldwide.His core competencies include C#, JavaScript, React.js, and Microsoft Azure, as well as ITIL and computer security.LINKS FOR SIMON PaINTERSimon's WebsiteSimon's LinkedinSimon's Book, Functional Programming with C#

In this conversation, Lars, Zach, and Rebecca discuss the Ash framework and their upcoming book. They also touch on the Igniter tool. The book, titled 'Building Web Applications with Ash', will provide a comprehensive tutorial and reference for using Ash and is expected in beta by the end of the year with @pragprog We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts on Bluesky! @akoutmos.bsky.social @ektastrophe.bsky.social @lawik.bsky.social @RedRapids@bsky.social Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

Today on Elixir Wizards, indie developer Lucas Sifoni shares his experience prototyping a remote-controlled terrestrial telescope using Elixir, Nerves, Rust, and various hardware components. Lucas explains the basic components of a telescope, the challenges he faced during the development process, and the benefits of using Elixir and Nerves for hardware projects. Lucas emphasizes the importance of simulating hardware components and testing assumptions before working with physical devices, as well as the value of literate programming and executable blog posts for documenting and sharing the process. Lucas encourages listeners to explore Nerves and build their own hardware projects. He also gives a shout-out to the Nerves core team for their incredible work. Topics discussed in this episode: Challenges in optimizing wiring and PCB design for the prototype Benefits of Elixir and Nerves for hardware projects Communicating with Arduinos using serial connections and pattern matching Leveraging binary pattern matching and construction in Elixir for hardware Balancing educational value and real-world usability Learning CID software and parametric design for 3D printing components Growing interest in Nerves and hardware projects within the Elixir community Simulating hardware components and testing assumptions before physical implementation Literate programming and executable blog posts for documenting hardware projects Using Elixir's interoperability with Rust for performance-critical tasks Elixir's low fragmentation and high-quality libraries for various domains Potential for using Livebook in hardware projects, with some limitations Encouraging listeners to explore Nerves and build their own hardware projects Links mentioned https://lucassifoni.info/ https://www.rust-lang.org/ https://go.dev/ https://lisp-lang.org/ https://ubuntu.com/ https://hexdocs.pm/iex/IEx.html https://nerves-project.org/ https://lucassifoni.info/blog/prototyping-elixir-telescope-code-beam/ https://github.com/Lucassifoni/oiseaux https://hexdocs.pm/phoenixliveview/Phoenix.LiveView.html https://www.raspberrypi.com/ https://mangopi.org/ https://store.arduino.cc/products/arduino-nano https://elixir-circuits.github.io/ https://www.erlang.org/doc/apps/runtimetools/scheduler.html Binary pattern matching in Elixir with PNG parsing example https://zohaib.me/binary-pattern-matching-in-elixir/ Lucas' Code Beam Talk: https://www.youtube.com/watch?v=q7bleFzA11c https://github.com/membraneframework-labs https://github.com/talklittle/ffmpex https://studio.blender.org/training/3d-printing/ https://www.autodesk.com/products/fusion-360/personal https://en.wikipedia.org/wiki/Parametricdesign https://www.exem.fr/ https://www.kikk.be/exhibitions/collectif-lab212-nicolas-guichard-beatrice-lartigue/ https://livebook.dev/ https://github.com/elixir-nx/bumblebee https://github.com/rusterlium/rustlerhttps://www.youtube.com/watch?v=q7bleFzA11c Special Guest: Lucas Sifoni.

Today in the Creator's Lab, Tony Dang joins Elixir Wizards Sundi Myint and Owen Bickford to break down his journey of creating a local-first, offline-ready to-do app using Phoenix LiveView, Svelte, and CRDTs (Conflict-free Replicated Data Types). Tony explains why offline functionality matters and how this feature can transform various apps. He shares insights on different libraries, algorithms, and techniques for building local-first experiences and highlights the advantages of Elixir and Phoenix LiveView. Tony also shares his go-to tools, like Inertia.js for connecting Phoenix backends with JavaScript frontends, and favorite Elixir packages like Oban, Joken, and Hammer, offering a toolkit for anyone building powerful, adaptable applications. Topics discussed in this episode: Tony Dang's background from mechanical engineer to web developer Building an offline-enabled to-do app with Phoenix LiveView and Svelte CRDTs: Conflict-free Replicated Data Types for merging changes offline How to make a LiveView app work offline Sending full state updates vs. incremental updates for performance optimization Inspiring others through open-source projects and community contributions Learning vanilla Phoenix and Channels to understand LiveView better Handling stale CSRF tokens when reconnecting to a LiveView app offline Exploring service workers and browser APIs for managing offline connectivity Balancing the use of JavaScript and Elixir in web development Fostering a supportive and inspiring Elixir community Links mentioned: Working in Elevators: How to build an offline-enabled, real-time todo app (https://www.youtube.com/watch?v=PX9-lq0LL9Q) w/ LiveView, Svelte, & Yjs Tony's Twitter: https://x.com/tonydangblog https://liveview-svelte-pwa.fly.dev/ https://github.com/tonydangblog/liveview-svelte-pwa CRDT: https://en.wikipedia.org/wiki/Conflict-freereplicateddatatype PWA: https://en.wikipedia.org/wiki/Progressivewebapp https://github.com/josevalim/sync https://github.com/sveltejs/svelte https://github.com/woutdp/livesvelte https://github.com/yjs/yjs https://github.com/satoren/yex https://github.com/y-crdt/y-crdt https://linear.app/ https://github.com/automerge/automerge https://hexdocs.pm/phoenix/1.4.0-rc.1/presence.html Vaxine, the Rich CRDT Database for ElixirPhoenix Apps (https://www.youtube.com/watch?v=n2c5eWIfziY) | James Arthur | Code BEAM America 2022 https://github.com/electric-sql/vaxine Hybrid Logical Clocks https://muratbuffalo.blogspot.com/2014/07/hybrid-logical-clocks.html https://en.wikipedia.org/wiki/256(number) CSRF Tokens in LiveView https://hexdocs.pm/phoenixliveview/Phoenix.LiveView.html#getconnectparams/1 https://hexdocs.pm/phoenix/channels.html Authentication with Passkeys (https://www.youtube.com/playlist?list=PL8lFmBcH3vX-JNIgxW3THUy7REthSRFEI) Talk by Tony https://www.meetup.com/dc-elixir/ https://github.com/rails/rails https://github.com/facebook/react-native https://github.com/vuejs https://github.com/laravel/laravel https://hexdocs.pm/phoenixliveview/js-interop.html https://github.com/inertiajs https://github.com/inertiajs/inertia-phoenix https://savvycal.com/ https://github.com/wojtekmach/req https://github.com/oban-bg/oban https://github.com/joken-elixir/joken https://github.com/ExHammer/hammer Special Guest: Tony Dang.

Today on Elixir Wizards, Bryan Green shares how he transformed a vintage 1930s rotary phone into a fully functional cell phone using Elixir, Nerves, and a mix of hardware components. Bryan shares the highs and lows of his project, from decoding rotary dial clicks to troubleshooting hardware issues with LED outputs. He explains why Nerves was the perfect fit for this project, offering SSH access, over-the-air updates, and remote debugging. You'll also hear how Elixir's concurrency model helped him manage hardware inputs and outputs efficiently using GenStateMachine and Genservers. Elixir and Nerves really shine when modeling real-world systems. Bryan dives into how he used a finite state machine to track the phone's states and handled inputs from the rotary dial and hook switch via GPIO. For hardware enthusiasts, Bryan's advice is to embrace this “golden age” of DIY electronics. Whether you're experienced with embedded systems or just curious on where to start, Bryan's VintageCell can inspire you to tinker with a hardware engineering project. Key topics discussed in this episode: Advantages of functional programming and immutability in Elixir Building hardware projects using Adafruit components Why Nerves was the best choice for the VintageCell project Interpreting rotary dial clicks using GPIO and circuits.gpio Troubleshooting hardware issues with LED diagnostics Challenges in optimizing wiring and PCB design Benefits of Nerves: SSH access, OTA updates, and remote debugging Modeling real-world systems with Elixir and Nerves Implementing a finite state machine with GenStateMachine Managing input with Genservers for rotary dial and hook switch Leveraging community resources like Discord, Elixir Slack, and forums Practical advice for keeping hardware projects on track Potential applications from SMS servers to home automation Links mentioned: Vintage Cellphone: Bridging the Past and Future with Elixir (https://www.youtube.com/watch?v=U4hetzVpjmo) Seven Languages in Seven Weeks https://pragprog.com/titles/btlang/seven-languages-in-seven-weeks/ Seven More Languages https://pragprog.com/titles/7lang/seven-more-languages-in-seven-weeks/ Node.js https://github.com/nodejs https://nerves-project.org/ https://www.arduino.cc/ Adafruit Circuit Playground https://www.adafruit.com/category/965 Adafruit 3D Printed Star Trek Communicator https://learn.adafruit.com/3d-printed-star-trek-communicator Adafruit FONA 3G Cellular + GPS Breakout https://learn.adafruit.com/adafruit-fona-3g-cellular-gps-breakout/overview https://github.com/elixir-circuits/circuitsgpio Nerves SSH https://hex.pm/packages/nervesssh OTA (over-the-air) Updates with NervesHub https://www.nerves-hub.org/ https://github.com/kicad Waveshare 4G Hat for Raspberry Pi https://www.waveshare.com/sim7600e-h-4g-hat.htm https://hexdocs.pm/genstatemachine/GenStateMachine.html https://hexdocs.pm/elixir/GenServer.html https://www.sparkfun.com/ https://www.digikey.com/ USB-C Gadget Mode with Nerves https://github.com/nerves-project/nervessystemrpi4/issues/18 https://livebook.dev/ https://codestorm.me/ https://github.com/codestorm1/vintage_cell/ Special Guest: Bryan Green.

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

To kick off Elixir Wizards Season 13, The Creator's Lab, we're joined by Zach Daniel, the creator of Igniter and the Ash framework. Zach joins hosts Owen Bickford and Charles Suggs to discuss the mechanics and aspirations of his latest brainchild, Igniter—a code generation and project patching framework designed to revolutionize the Elixir development experience. Igniter isn't just about generating code; it's about generating smarter code. By leveraging tools like Sourcerer and Rewrite, Igniter allows developers to modify source code and batch updates by directly interacting with Elixir's AST instead of regex patching. This approach streamlines new project setup and package installations and enhances overall workflow. They also discuss the strategic implications of Igniter for the broader Elixir community. Zach hopes Igniter will foster a more interconnected and efficient ecosystem that attracts new developers to Elixir and caters to the evolving needs of seasoned Elixir engineers. Topics discussed in this episode: Advanced package installation and code generation improve the developer experience Scripting and staging techniques streamline project updates Innovative methods for smoother installation processes in Elixir packages High-level tools apply direct patches to source code Progressive feature additions simplify the mix phx.new experience Chaining installers and composing tasks for more efficient project setup Continuous improvement in developer experiences to boost Elixir adoption Encourage listeners to collaborate by sharing code generation patterns Introduction of a new mix task aimed at removing the "unless" keyword in preparation for Elixir 1.18 You can learn more in the upcoming book "Building Web Applications with Ash Framework" by Zach and Rebecca Links mentioned: https://smartlogic.io/ https://alembic.com.au/blog/igniter-rethinking-code-generation-with-project-patching https://hexdocs.pm/igniter/readme.html https://github.com/ash-project/igniter https://www.zachdaniel.dev/p/serialization-is-the-secret https://www.zachdaniel.dev/p/welcome-to-my-substack https://ash-hq.org/ https://hexdocs.pm/sourceror/readme.html https://smartlogic.io/podcast/elixir-wizards/s10-e09-hugo-lucas-future-of-elixir-community/ https://github.com/hrzndhrn/rewrite https://github.com/zachdaniel https://github.com/liveshowy/webauthn_components https://hexdocs.pm/elixir/Regex.html https://github.com/msaraiva/vscode-surface https://github.com/swoosh/swoosh https://github.com/erlef/oidcc https://alembic.com.au/ https://www.zachdaniel.dev/ Special Guest: Zach Daniel.

The panel explores Poka Yoke with Bryan Hunter - the concept of mistake-proofing and its application in Erlang and Elixir. Bryan Hunter [GigCityElixir24] Poka Yoke, STAMP and the BEAM (https://youtu.be/0-aJwz6oPow?si=5hTL8HwHiJfYQb4S) Engineering A Safer World (https://a.co/d/1iQdN70) by Nancy G. Leveson We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts on Twitter @akoutmos @lawik @meryldakin @RedRapids @smdebenedetto @StevenNunez and on Mastodon @akoutmos@fosstodon.org @lawik@fosstodon.org @redrapids@genserver.social @steven@genserver.social Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

What is a program? Your answer to this question will determine the paradigm through which you view programming. During this episode, you'll come to understand how things change once you develop an awareness of your paradigm, and what. To kick off this episode, Stephanie shares key insights she took from Planet Argon's 2024 Ruby on Rails survey and dives deeper into her history with Ruby on Rails. Next, we dive into the definition of a paradigm and unpack three different paradigms you might hold as a developer: procedural, object-oriented, and functional. Considering how each of these impacts the way that you might approach your work as a developer, and what you can learn from the ones that are less familiar to you. Joël describes his scripting style and evaluates the concept of pure functions and their place in development, and we close by digging deeper into how your paradigm might impact the code that you write. Tune in to hear all this and more. Key Points From This Episode: The EPI feature that Joël has started to build out for his client. Why Stephanie is excited about the results of Planet Argon's 2024 Ruby on Rails community survey. What a procedural program is: programming envisions a program as a series of instructions to a computer. Defining an object-oriented paradigm: programming envisions a program as the behavior that emerges from objects talking to each other. How a functional paradigm envisions a program as a series of data transformations. Alan Turing and Alonzo Church's approach to understanding this. How a lot of the foundations of computer science came to be built before we had computers. Using Ruby to make judgments and assessing whether or not this is a procedural habit. Why Joël describes his scripting style as being very procedural. Unpacking the meaning of functional programming. Evaluating the concept of pure functions. Considering how your paradigm may impact the Ruby code that you write. Links Mentioned in Today's Episode: 2024 Ruby on Rails Community Survey (https://railsdeveloper.com/survey/2024/) Church-Turing Thesis (https://ocw.mit.edu/courses/24-242-logic-ii-spring-2004/489f7e42fb619645158d7c21a8fb83ad_chuh_trng_thesis.pdf) Dynamic type systems are not inherently more open (https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/) What is Functional Programming? (blog.jenkster.com/2015/12/what-is-functional-programming.html) Blocks as an abstraction vs for loops (https://thoughtbot.com/blog/special-cases) Functional core imperative shell (https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell) Testing objects with a functional mindset
 (https://thoughtbot.com/blog/functional-viewpoints-on-testing-objectoriented-code) The Bike Shed (https://bikeshed.thoughtbot.com/) Joël Quenneville on LinkedIn (https://www.linkedin.com/in/joel-quenneville-96b18b58/) Support The Bike Shed (https://github.com/sponsors/thoughtbot)

Lars and Bruce have a fabulous chat with Marcel Fahle creator of Bold Video and Pidro, a classic multiplayer card game for iOS and Android. on X: @marcelfahle https://marcelfahle.net/ bold.video (https://bold.video/) Pidro card game (https://www.pidro.online/) We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts on Twitter @akoutmos @lawik @meryldakin @RedRapids @smdebenedetto @StevenNunez and on Mastodon @akoutmos@fosstodon.org @lawik@fosstodon.org @redrapids@genserver.social @steven@genserver.social Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

On this episode of Crazy Wisdom, I, Stewart Alsop, sit down with Ben Ford and Michael Greenberg for a dynamic conversation. Ben is the founder of Mission Control Dev, and Michael is the founder of Third Brain, a company focused on automating business operations. We explore a variety of topics, including the real meaning of "artificial intelligence," how AI is impacting various industries, and whether we truly have AI today. Michael introduces his concept of "Third Brain," a digital layer of operations, while Ben reflects on his military background and how it shapes his current work. Both offer unique perspectives on where technology is headed, especially around the future of knowledge work, digital transformation, and the human element in an increasingly automated world. Check out the links to learn more about Ben's Mission Control Dev and Michael's Third Brain.Check out this GPT we trained on the conversation!Timestamps00:00 Introduction to the Crazy Wisdom Podcast00:15 Meet the Guests: Ben Ford and Michael Greenberg01:04 Exploring Third Brain and Mission Control03:05 Debating Artificial Intelligence05:24 The Role of AI in Business Operations08:54 Challenges in Digital Transformation16:59 Implementing AI and Digital Operations29:12 Exploring Puzzle App: A New Tool for Documentation30:14 The Power of Graphs in Computer Science32:14 Infinite Dimensions and String Theory32:57 AI Systems and Social Media Content33:31 Wardley Mapping and Business Processes35:26 The Future of AI and Job Security35:49 AI Whisperers Meetup and Conference43:35 The Role of Subject Matter Experts in AI44:13 The Impact of AI on Learning and Careers55:09 Challenges in Implementing AI Chatbots57:10 Closing Thoughts and Contact InformationKey InsightsThe distinction between AI and true intelligence: Ben and Michael both agree that current AI, particularly large language models (LLMs), lacks true intelligence. While these systems are highly capable of pattern recognition and can execute specific workflows efficiently, they fall short of human-like intelligence due to their inability to form cognitive loops, embody real-world understanding, or have agency. AI today excels at capacity but not in truly autonomous thinking.Digital transformation is continuous, not a one-time event: The idea that digital transformation has failed was discussed, with Ben and Michael pointing out that the problem lies in the perception that digital transformation has a start and end point. In reality, businesses are constantly transforming, and the process is more about ongoing adaptation than achieving a static, “transformed” state. Success in this realm requires persistent updates and improvements, especially in operational structure.AI as an enabler, not a replacement: Both guests emphasized that AI should be seen as a tool that augments human capability rather than replaces it. AI can significantly enhance the capacity of knowledge workers, enabling them to focus on more creative or strategic tasks by automating routine processes. However, human oversight and strategic input are still essential, especially when it comes to structuring data and providing context for AI systems to function effectively.The future of work involves "AI whisperers": Stewart introduces the idea of "AI whisperers" — people skilled in communicating with and directing AI systems to achieve specific outcomes. This requires a high level of linguistic and operational understanding, suggesting that those who can finesse AI's capabilities with precision will be in high demand in the future workforce. This shift may see creative, word-focused individuals becoming increasingly critical players in business operations.Structured data is crucial for effective AI deployment: A major challenge in deploying AI for businesses is the lack of well-structured data. Many organizations lack the documentation or system integration needed to effectively implement AI, meaning much of the initial work revolves around organizing data. Without this foundational step, attempts at AI deployment—such as customer service chatbots—are prone to failure, as the AI systems are only as good as the data they're fed.Graphs as the framework for business processes: Ben and Michael both highlight the importance of graphs in modern operations. Graphs, as a way to map out relationships between different elements of a system, are key to understanding and implementing digital operations. This concept allows for the visualization and optimization of workflows, helping businesses better navigate the complexities of modern digital ecosystems.AI is accelerating, and businesses need to keep up: One of the key takeaways from the episode is the rapid pace of AI advancement and its effect on businesses. Companies that fail to incorporate AI tools into their operations risk being left behind. Ben points out that the train has already left the station, and businesses need to quickly adapt by leveraging AI to streamline their processes and maintain competitiveness in an increasingly automated world.

Johnny is founder and lead developer at Empyreal SDK. He is a seasoned Systems Engineer with a wealth of experience in enterprise-level technology. Prior to starting Empyreal, Johnny worked as a Software Engineer at a FAANG company. He brings a strong passion for programming, particularly in Rust, Python, and Functional Programming. --- Support this podcast: https://podcasters.spotify.com/pod/show/crypto-hipster-podcast/support

Sophie DeBenedetto and Steven Nunez chat with Ellie Fairholm and Josep Giralt D'Lacoste, authors of Engineering Elixir Applications. https://pragprog.com/titles/beamops/engineering-elixir-applications/ "After reading this book, you'll understand how to apply the BEAMOps principles in your daily work, creating reliable, scalable, and easy to understand applications in a cooperative team environment." - pragprog.com Ellie and Josep are giving a keynote at ElixirConf 2024. https://2024.elixirconf.com/#keynotes We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts on Twitter @akoutmos @lawik @meryldakin @RedRapids @smdebenedetto @StevenNunez and on Mastodon @akoutmos@fosstodon.org @lawik@fosstodon.org @redrapids@genserver.social @steven@genserver.social Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

Lars chats with Alex McLain and Jon Carstens about NervesConf 2024. @NervesConfUS @JonCarstens @RedwireLabs Nerves MeetUp: https://www.meetup.com/nerves/ We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts on Twitter @akoutmos @lawik @meryldakin @RedRapids @smdebenedetto @StevenNunez and on Mastodon @akoutmos@fosstodon.org @lawik@fosstodon.org @redrapids@genserver.social @steven@genserver.social Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

This Episode we are joined by Simon Painter a senior software engineer with nearly 20 years of experience in the industry and author of the book Functional Programming with C#.In this episode, Hack The Planet! The Best And Worst Hacker Movies Reviewed! Our regular programming has been hijacked to bring you a discussion on the best, and worst, hacker movies! In this episode we cover greats like Hackers, Sneakers, Jurassic Park and War Games, and not so great movies like The Net!So boot up that modem, turn off the lights and enter the deepest darkest web of hacker forums, and try not to accidentally trigger thermonuclear war, as we explore this sometimes brilliant and sometimes bonkers sub-genre!Disclaimer! This podcast is for educational purposes only and is distributed without profit. This Episode may contain copyrighted material whose use has not been specifically authorised by the copyright owner. We believe our use of such material constitutes fair use for the purpose of review, commentary, and critiqueWe Talked About A Lot Of Films In This Episode - Here's The List:Hacker MoviesHackers (1995)Sneakers (1992)The Net (1995)The Net 2.0 (2006)Jurassic Park (1993)Jumping Jack Flash (1986)Brazil (1985)The Italian Job (1969)War Games (1983)Electric Dreams (1984)Swordfish (2001)Mr Robot (TV(2015))Non-Hacker MoviesAmélie (2001)Blade Runner (1982)Blade Runner 2049 (2017)Arrival (2016)Dune Part 1 (2021)The Zone of Interest (2023)The Duke of Burgundy (2014)Flux Gourmet (2022)In Fabric (2018)Short Circuit (1986)Flight of the Navigator (1986)Metropolis (1927)Cliffhanger (1993)Tough Guys Don't Dance (1987)Cast Away (2000)The Fugitive (1993)Links to everything we discussed in this episode can be found in the show notes and if you liked the show, please do leave us a review.Follow us on all good podcasting platforms and via our YouTube channel, and don't forget to share on LinkedIn and in your teams.It really helps us spread the word and get high-quality guests, on future episodes. We hope you enjoyed this episode - See you next time, keep secure, and don't forget to ask yourself, ‘Am I the compromising position here?' Keywords: cybersecurity, movies, series end, hackers, war games, sneakers, filmSHOW NOTESSimon's Book, Functional Programming with C#Read Simon's Film Reviews on his websiteThe beautiful Leeds Cinema, The Hyde Park Picture HouseABOUT SIMON PAINTERWith nearly 20 years of software engineering experience across various industries, Simon is a Senior Software Developer at Müller UK & Ireland, one of the leading dairy companies in Europe. Simon is also a Microsoft Most Valuable Professional (MVP) since 2023, an O'Reilly technical book author, and a public speaker at IT events worldwide.His core competencies include C#, JavaScript, React.js, and Microsoft Azure, as well as ITIL and computer security.LINKS FOR SIMON PAINTERSimon's WebsiteSimon's Linkedin

Mark Erikson, Redux maintainer and a senior front-end engineer at replay.io discusses why Redux remains a powerful tool for state management in 2024, the evolution of Redux Toolkit, and the common pitfalls developers face. Links https://blog.isquaredsoftware.com https://twitter.com/acemarke https://github.com/markerikson https://stackoverflow.com/users/62937/markerikson https://linkedin.com/in/markerikson We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Mark Erikson.

Chris, Lars and Alex discuss Chris's journey into Elixir and using machine learning and AI in Elixir to build a product and a business. They also touch on the process of training models and the benefits of using Livebook. Chris Grainger https://www.amplified.ai We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts on Twitter @akoutmos @lawik @meryldakin @RedRapids @smdebenedetto @StevenNunez and on Mastodon @akoutmos@fosstodon.org @lawik@fosstodon.org @redrapids@genserver.social @steven@genserver.social Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

In this episode, the panel chats with Derrick Reimer, co-founder of SavvyCal. They discuss the advantages of using Elixir for bootstrapped SaaS businesses and how Elixir's functional programming paradigm aligns with modern development practices. Derrick shares his journey from Rails to Elixir and explains why he prefers the clarity and explicitness of Elixir over other languages. @Derrickreimer on X https://savvycal.com We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts on X @akoutmos @lawik @meryldakin @RedRapids @smdebenedetto @StevenNunez and on Mastodon @akoutmos@fosstodon.org @lawik@fosstodon.org @redrapids@genserver.social @steven@genserver.social Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

Bruce and Lars are live on stage (and mostly unedited) at GigCityElixir in Chattanooga Tennessee hosting a great conversation of GCE folks on stage for some "hot takes." Please note, this episode contains some explicit language. We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts on Twitter @akoutmos @lawik @meryldakin @RedRapids @smdebenedetto @StevenNunez and on Mastodon @akoutmos@fosstodon.org @lawik@fosstodon.org @redrapids@genserver.social @steven@genserver.social Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

In Elixir Wizards Office Hours Episode 8, hosts Sundi Myint and Owen Bickford lead an engaging Q&A session with co-host Dan Ivovich, diving deep into the nuances of DevOps. Drawing from his extensive experience, Dan navigates topics from the early days before Docker to managing diverse polyglot environments and optimizing observability. This episode offers insights for developers of all levels looking to sharpen their DevOps skills. Explore the realms of Docker, containerization, DevOps workflows, and the deployment intricacies of Elixir applications. Key topics discussed in this episode: Understanding DevOps and starting points for beginners Best practices for deploying applications to the cloud Using Docker for containerization Managing multiple programming environments with microservices Strategies for geographic distribution and ensuring redundancy Localization considerations involving latency and device specs Using Prometheus and OpenTelemetry for observability Adjusting scaling based on application metrics Approaching failure scenarios, including database migrations and managing dependencies Tackling challenges in monitoring setups and alert configurations Implementing incremental, zero-downtime deployment strategies The intricacies of hot code upgrades and effective state management Recommended learning paths, including Linux and CI/CD workflows Tools for visualizing system health and monitoring Identifying actionable metrics and setting effective alerts Links mentioned: Ansible open source IT automation engine https://www.ansible.com/ Wikimedia engine https://doc.wikimedia.org/ Drupal content management software https://www.drupal.org/ Capistrano remote server automation and deployment https://capistranorb.com/ Docker  https://www.docker.com/ Circle CI CI/CD Tool https://circleci.com/ DNS Cluster https://hex.pm/packages/dnscluster ElixirConf 2023 Chris McCord Phoenix Field Notes https://youtu.be/Ckgl9KO4E4M Nerves https://nerves-project.org/ Oban job processing in Elixir https://getoban.pro/ Sidekiq background jobs for Ruby https://sidekiq.org/ Prometheus https://prometheus.io/ PromEx https://hexdocs.pm/promex/PromEx.html GitHub Actions - Setup BEAM: https://github.com/erlef/setup-beam Jenkins open source automation server https://www.jenkins.io/ DataDog Cloud Monitoring https://www.datadoghq.com/ 

Join the panel for a fabulous talk with the one and only @lostkobrakai! We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts on Twitter @akoutmos @lawik @meryldakin @RedRapids @smdebenedetto @StevenNunez and on Mastodon @akoutmos@fosstodon.org @lawik@fosstodon.org @redrapids@genserver.social @steven@genserver.social Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

Today on Elixir Wizards Office Hours, SmartLogic Engineer Joel Meador joins Dan Ivovich to discuss all things background jobs. The behind-the-scenes heroes of app performance and scalability, background jobs take center stage as we dissect their role in optimizing user experience and managing heavy-lifting tasks away from the main application flow. From syncing with external systems to processing large datasets, background jobs are pivotal to successful application management. Dan and Joel share their perspectives on monitoring, debugging, and securing background jobs, emphasizing the need for a strategic approach to these hidden workflows. Key topics discussed in this episode: The vital role of background jobs in app performance Optimizing user experience through background processing Common pitfalls: resource starvation and latency issues Strategies for effective monitoring and debugging of task runners and job schedulers Data integrity and system security in open source software Background job tools like Oban, Sidekiq, Resque, Cron jobs, Redis pub sub CPU utilization and processing speed Best practices for implementing background jobs Keeping jobs small, focused, and well-monitored Navigating job uniqueness, locking, and deployment orchestration Leveraging asynctask for asynchronous operations The art of continuous improvement in background job management Links mentioned in this episode: https://redis.io/ Oban job processing library https://hexdocs.pm/oban/Oban.html Resque Ruby library for background jobs https://github.com/resque Sidekiq background processing for Ruby https://github.com/sidekiq Delayed Job priority queue system https://github.com/collectiveidea/delayed_job RabbitMQ messaging and streaming broker https://www.rabbitmq.com/ Mnesia distributed telecommunications DBMS https://www.erlang.org/doc/man/mnesia.html Task for Elixir https://hexdocs.pm/elixir/1.12/Task.html ETS in-memory store for Elixir and Erlang objects https://hexdocs.pm/ets/ETS.html Cron - https://en.wikipedia.org/wiki/Cron Donate to Miami Indians of Indiana https://www.miamiindians.org/take-action Joel Meador on Tumblr https://joelmeador.tumblr.com/ Special Guest: Joel Meador.

In Elixir Wizards Office Hours Episode 2, "Discovery Discoveries," SmartLogic's Project Manager Alicia Brindisi and VP of Delivery Bri LaVorgna join Elixir Wizards Sundi Myint and Owen Bickford on an exploratory journey through the discovery phase of the software development lifecycle. This episode highlights how collaboration and communication transform the client-project team dynamic into a customized expedition. The goal of discovery is to reveal clear business goals, understand the end user, pinpoint key project objectives, and meticulously document the path forward in a Product Requirements Document (PRD). The discussion emphasizes the importance of fostering transparency, trust, and open communication. Through a mutual exchange of ideas, we are able to create the most tailored, efficient solutions that meet the client's current goals and their vision for the future. Key topics discussed in this episode: Mastering the art of tailored, collaborative discovery Navigating business landscapes and user experiences with empathy Sculpting project objectives and architectural blueprints Continuously capturing discoveries and refining documentation Striking the perfect balance between flexibility and structured processes Steering clear of scope creep while managing expectations Tapping into collective wisdom for ongoing discovery Building and sustaining a foundation of trust and transparency Links mentioned in this episode: https://smartlogic.io/ Follow SmartLogic on social media: https://twitter.com/smartlogic Contact Bri: bri@smartlogic.io What is a PRD? https://en.wikipedia.org/wiki/Productrequirementsdocument Special Guests: Alicia Brindisi and Bri LaVorgna.

The BeamRadio panel chats all things Gleam with the core team Louis Pilford and Hayleigh Thompson! Gleam's approach to concurrency and its focus on type safety make it an interesting choice for Erlang/Elixir developers looking to leverage the benefits of static typing while maintaining the performance and concurrency model of the BEAM VM. The language's development is ongoing, with the community actively contributing to its growth and the expansion of its ecosystem. @louispilfold @hayleighdotdev @gleamlang https://gleam.run We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts on Twitter @akoutmos @lawik @meryldakin @RedRapids @smdebenedetto @StevenNunez and on Mastodon @akoutmos@fosstodon.org @lawik@fosstodon.org @redrapids@genserver.social @steven@genserver.social Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)

Joël talks about his difficulties optimizing queries in ActiveRecord, especially with complex scopes and unions, resulting in slow queries. He emphasizes the importance of optimizing subqueries in unions to boost performance despite challenges such as query duplication and difficulty reusing scopes. Stephanie discusses upgrading a client's app to Rails 7, highlighting the importance of patience, detailed attention, and the benefits of collaborative work with a fellow developer. The conversation shifts to Ruby's reduce method (inject), exploring its complexity and various mental models to understand it. They discuss when it's preferable to use reduce over other methods like each, map, or loops and the importance of understanding the underlying operation you wish to apply to two elements before scaling up with reduce. The episode also touches on monoids and how they relate to reduce, suggesting that a deep understanding of functional programming concepts can help simplify reduce expressions. Rails 7 EXPLAIN ANALYZE (https://www.bigbinary.com/blog/rails-7-1-adds-options-to-activerecord-relation-explain) Blocks, symbol to proc, and symbols arguments for reduce (https://thoughtbot.com/blog/blocks-procs-and-enumerable) Ruby tally (https://medium.com/@baweaver/ruby-2-7-enumerable-tally-a706a5fb11ea) Performance considerations for reduce in JavaScript (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce#when_to_not_use_reduce) Persistant data structures (https://www.youtube.com/watch?v=gTClDj9Zl1g) Avoid passing a block to map and reduce (https://thoughtbot.com/blog/avoid-putting-logic-in-map-blocks) Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire (https://ris.utwente.nl/ws/portalfiles/portal/6142049/meijer91functional.pdf) monoids (https://blog.ploeh.dk/2017/10/06/monoids/) iteration anti-patterns (https://thoughtbot.com/blog/iteration-as-an-anti-pattern) Joël's talk on “constructor replacement” (https://www.youtube.com/watch?v=dSMB3rsufC8) Transcript:  STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: I've been doing a bunch of fiddling with query optimization this week, and I've sort of run across an interesting...but maybe it's more of an interesting realization because it's interesting in the sort of annoying way. And that is that, using ActiveRecord scopes with certain more complex query pieces, particularly unions, can lead to queries that are really slow, and you have to rewrite them differently in a way that's not reusable in order to make them fast. In particular, if you have sort of two other scopes that involve joins and then you combine them using a union, you're unioning two sort of joins. Later on, you want to change some other scope that does some wares or something like that. That can end up being really expensive, particularly if some of the underlying tables being joined are huge. Because your database, in my case, Postgres, will pull a lot of this data into the giant sort of in-memory table as it's, like, building all these things together and to filter them out. And it doesn't have the ability to optimize the way it would on a more traditional relation. A solution to this is to make sure that the sort of subqueries that are getting unioned are optimized individually. And that can mean moving conditions that are outside the union inside. So, if I'm chaining, I don't know, where active is true on the outer query; on the union itself, I might need to move that inside each of the subqueries. So, now, in the two or three subqueries that I'm unioning, each of them needs to have a 'where active true' chained on it. STEPHANIE: Interesting. I have heard this about using ActiveRecord scopes before, that if the scopes are quite complex, chaining them might not lead to the most performant query. That is interesting. By optimizing the subqueries, did you kind of change the meaning of them? Was that something that ended up happening? JOËL: So, the annoying thing is that I have a scope that has the union in it, and it does some things sort of on its own. And it's used in some places. There are also other places that will try to take that scope that has the union on it, chain some other scopes that do other joins and some more filters, and that is horribly inefficient. So, I need to sort of rewrite the sort of subqueries that get union to include all these new conditions that only happen in this one use case and not in the, like, three or four others that rely on that union. So, now I end up with some, like, awkward query duplication in different call sites that I'm not super comfortable about, but, unfortunately, I've not found a good way to make this sort of nicely reusable. Because when you want to chain sort of more things onto the union, you need to shove them in, and there's no clean way of doing that. STEPHANIE: Yeah. I think another way I've seen this resolved is just writing it in SQL if it's really complex and it becoming just a bespoke query. We're no longer trying to use the scope that could be reusable. JOËL: Right. Right. In this case, I guess, I'm, like, halfway in between in that I'm using the ActiveRecord DSL, but I am not reusing scopes and things. So, I sort of have the, I don't know, naive union implementation that can be fine in all of the simpler use cases that are using it. And then the query that tries to combine the union with some other fancy stuff it just gets its own separate implementation different than the others that it has optimized. So, there are sort of two separate paths, two separate implementations. I did not drop down to writing raw SQL because I could use the ActiveRecord DSL. So, that's what I've been working with. What's new in your world this week? STEPHANIE: So, a couple of weeks ago, I think, I mentioned that I was working on a Rails 7 upgrade, and we have gotten it out the door. So, now the client application I'm working on is on Rails 7, which is exciting for the team. But in an effort to make the upgrade as incremental as possible, we did, like, back out of a few of the new application config changes that would have led us down a path of more work. And now we're kind of following up a little bit to try to turn some of those configs on to enable them. And it was very exciting to kind of, like, officially be on Rails 7. But I do feel like we tried to go for, like, the minimal amount of work possible in that initial big change. And now we're having to kind of backfill a little bit on some of the work that was a little bit more like, oh, I'm not really sure, like, how big this will end up being. And it's been really interesting work, I think, because it requires, like, two different mindsets. Like, one of them is being really patient and focused on tedious work. Like, okay, what happens when we enable this config option? Like, what changes? What errors do we see? And then having to turn it back off and then go in and fix them. But then another, I think, like, headspace that we have to be in is making decisions about what to do when we come to a crossroads around, like, okay, now that we are starting to see all the changes that are coming about from enabling this config, is this even what we want to do? And it can be really hard to switch between those two modes of thinking. JOËL: Yeah. How do you try to balance between the two? STEPHANIE: So, I luckily have been pairing with another dev, and I've actually found that to be really effective because he has, I guess, just, like, a little bit more of that patience to do the more tedious, mundane [laughs] aspects of, like, driving the code changes. And I have been riding along. But then I can sense, like, once he gets to the point of like, "Oh, I'm not sure if we should keep going down this road," I can step in a little bit more and be like, "Okay, like, you know, I've seen us do this, like, five times now, and maybe we don't want to do that." Or maybe being like, "Okay, we don't have a really clear answer, but, like, who can we talk to to find out a little bit more or get their input?" And that's been working really well for me because I've not had a lot of energy to do more of that, like, more manual or tedious labor [chuckles] that comes with working on that low level of stuff. So yeah, I've just been pleasantly surprised by how well we are aligning our superpowers. JOËL: To use some classic business speech, how does it feel to be in the future on Rails 7? STEPHANIE: Well, we're not quite up, you know, up to modern days yet, but it does feel like we're getting close. And, like, I think now we're starting to entertain the idea of, like, hmm, like, could we be even on main? I don't think it's really going to happen, but it feels a little bit more possible. And, in general, like, the team thinks that that could be, like, really exciting. Or it's easier, I think, once you're a little bit more on top of it. Like, the worst is when you get quite behind, and you end up just feeling like you're constantly playing catch up. It just feels a little bit more manageable now, which is good. JOËL: I learned this week a fun fact about Rails 7.1, in particular, which is that the analyze method on ActiveRecord queries, which allowed you to sort of get SQL EXPLAIN statements, now has the ability to pass in a couple of extra parameters. So, there are symbols, and you can pass in things like analyze or verbose, which allows you to get sort of more data out of your EXPLAIN query, which can be quite nice when you're debugging for performance. So, if you're in the future and you're on Rails 7.1 and you want sort of the in-depth query plans, you don't need to copy the SQL into a Postgres console to get access to the sort of fully developed EXPLAIN plan. You can now do it by passing arguments to EXPLAIN, which I'm very happy for. STEPHANIE: That's really nice. JOËL: So, we've mentioned before that we have a developers' channel on Slack here at thoughtbot, and there's all sorts of fun conversations that happen there. And there was one recently that really got me interested, where people were talking about Ruby's reduce method, also known as inject. And it's one of those methods that's kind of complicated, or it can be really confusing. And there was a whole thread where people were talking about different mental models that they had around the reduce method and how they sort of understand the way it works. And I'd be curious to sort of dig into each other's mental models of that today. To kick us off, like, how comfortable do you feel with Ruby's reduce method? And do you have any mental models to kind of hold it in your head? STEPHANIE: Yeah, I think reduce is so hard to wrap your head around, or it might be one of the most difficult, I guess, like, functions a new developer encounters, you know, in trying to understand the tools available to them. I always have to look up the order of the arguments [laughs] for reduce. JOËL: Every time. STEPHANIE: Yep. But I feel like I finally have a more intuitive sense of when to use it. And my mental model for it is collapsing a collection into one value, and, actually, that's why I prefer calling it reduce rather than the inject alias because reduce kind of signals to me this idea of going from many things to one canonical thing, I suppose. JOËL: Yeah, that's a very common use case for reducing, and I guess the name itself, reducing, kind of has almost that connotation. You're taking many things, and you're going to reduce that down to a single thing. STEPHANIE: What was really interesting to me about that conversation was that some people kind of had the opposite mental model where it made a bit more sense for them to think about injecting and, specifically, like, the idea of the accumulator being injected with values, I suppose. And I kind of realized that, in some ways, they're kind of antonyms [chuckles] a little bit because if you're focused on the accumulator, you're kind of thinking about something getting bigger. And that kind of blew my mind a little bit when I realized that, in some ways, they can be considered opposites. JOËL: That's really fascinating. It is really interesting, I think, the way that we can take the name of a method and then almost, like, tell ourselves a story about what it does that then becomes our way of remembering how this method works. And the story we tell for the same method name, or in this case, maybe there's a few different method names that are aliases, can be different from person to person. I know I tend to think of inject less in terms of injecting things into the accumulator and more in terms of injecting some kind of operator between every item in the collection. So, if we have an array of numbers and we're injecting plus, in my mind, I'm like, oh yeah, in between each of the numbers in the collection, just inject a little plus sign, and then do the math. We're summing all the items in the collection. STEPHANIE: Does that still hold up when the operator becomes a little more complex than just, you know, like, a mathematical operator, like, say, a function? JOËL: Well, when you start passing a block and doing custom logic, no, that mental model kind of falls apart. In order for it to work, it also has to be something that you can visualize as some form of infix operator, something that goes between two values rather than, like, a method name, which is typically in prefix position. I do want to get at this idea, though: the difference between sort of the block version versus passing. There are ways where you can just do a symbol, and that will call a method on each of the items. Because I have a bit of a hot take when it comes to writing reduce blocks or inject blocks that are more accessible, easier to understand. And that is, generally, that you shouldn't, or more specifically, you should not have a big block body. In general, you should be either using the symbol version or just calling a method within the block, and it's a one-liner. Which means that if you have some complex behavior, you need to find a way to move that out of this sort of collection operation and into instance methods on the objects being iterated. STEPHANIE: Hmm, interesting. By one-liner do you mean passing the name of the method as a proc or actually, like, having your block that then calls the method? Because I can see it becoming even simpler if you have already extracted a method. JOËL: Yeah, if you can do symbol to proc, that's amazing, or even if you can use just the straight-up symbol way of invoking reduce or inject. That typically means you have to start thinking about the types of objects that you are working with and what methods can be moved onto them. And sometimes, if you're working with hashes or something like that that don't have domain methods for what you want, that gets really awkward. And so, then maybe that becomes maybe a hint that you've got some primitive obsession happening and that this hash that sort of wants a domain object or some kind of domain method probably should be extracted to its own object. STEPHANIE: I'll do you with another kind of spicy take. I think, in that case, maybe you don't want a reduce at all. If you're starting to find that...well, okay, I think it maybe could depend because there could be some very, like, domain-specific logic. But I have seen reduce end up being used to transform the structure of the initial collection when either a different higher-order function can be used or, I don't know, maybe you're just better off writing it with a regular loop [laughs]. It could be clearer that way. JOËL: Well, that's really interesting because...so, you mentioned the idea that we could use a different higher-order function, and, you know, higher-order function is that fancy term, just a method that accepts another method as an argument. In Ruby, that just means your method accepts a block. Reduce can be used to implement pretty much the entirety of enumerable. Under the hood, enumerable is built in terms of each. You could implement it in terms of reduce. So, sometimes it's easy to re-implement one of the enumerable methods yourself, accidentally, using reduce. So, you've written this, like, complex reduce block, and then somebody in review comes and looks at it and is like, "Hey, you realize that's just map. You've just recreated map. What if we used map here?" STEPHANIE: Yeah. Another one I've seen a lot in JavaScript land where there are, you know, fewer utility functions is what we now have in Ruby, tally. I feel like that was a common one I would see a lot when you're trying to count instances of something, and I've seen it done with reduce. I've seen it done with a for each. And, you know, I'm sure there are libraries that actually provide a tally-like function for you in JS. But I guess that actually makes me feel even more strongly about this idea that reduce is best used for collapsing something as opposed to just, like, transforming a data structure into something else. JOËL: There's an interesting other mental model for reduce that I think is hiding under what we're talking about here, and that is the idea that it is a sort of mid-level abstraction for dealing with collections, as opposed to something like map or select or some of those other enumerable helpers because those can all be implemented in terms of reduce. And so, in many cases, you don't need to write the reduce because the library maintainer has already used reduce or something equivalent to build these higher-level helpers for you. STEPHANIE: Yeah, it's kind of in that weird point between, like, very powerful [chuckles] so that people can start to do some funky things with it, but also sometimes just necessary because it can feel a little bit more concise that way. JOËL: I've done a fair amount of functional programming in languages like Elm. And there, if you're building a custom data structure, the sort of lowest-level way you have of looping is doing a recursion, and recursions are messy. And so, what you can do instead as a library developer is say, "You know what, I don't want to be writing recursions for all of these." I don't know; maybe I'm building a tree library. I don't want to write a recursion for every different function that goes over trees if I want to map or filter or whatever. I'm going to write reduce using recursion, and then everything else can be written in terms of reduce. And then, if people want to do custom things, they don't need to recurse over my tree. They can use this reduce function, which allows them to do most of the traversals they want on the tree without needing to touch manual recursion. So, there's almost, like, a low-level, mid-level, high-level in the library design, where, like, lowest level is recursion. Ideally, nobody touches that. Mid-level, you've got reducing that's built out on top of recursion. And then, on top of that, you've got all sorts of other helpers, like mapping, like filtering, things like that. STEPHANIE: Hmm. I'm wondering, do you know of any performance considerations when it comes to using reduce built off a recursion? JOËL: So, one of the things that can be really nice is that writing a recursion yourself is dangerous. It's so easy to, like, accidentally introduce Stack Overflow. You could also write a really inefficient one. So, ideally, what you do is that you write a reduce that is safe and that is fast. And then, everybody else can just use that to not have to worry about the sort of mechanics of traversing the collection. And then, just use this. It already has all of the safety and speed features built in. You do have to be careful, though, because reduce, by nature, traverses the entire collection. And if you want to break out early of something expensive, then reduce might not be the tool for you. STEPHANIE: I was also reading a little bit about how, in JavaScript, a lot of developers like to stick to that idea of a pure function and try to basically copy the entire accumulator for every iteration and creating a new object for that. And that has led to some memory issues as well. As opposed to just mutating the accumulator, having, especially when you, you know, are going through a collection, like, really large, making that copy every single time and creating, yeah [chuckles], just a lot of issues that way. So, that's kind of what prompted that question. JOËL: Yeah, that can vary a lot by language and by data structure. In more functional languages that try to not mutate, they often have this idea of what they call persistent data structures, where you can sort of create copies that have small modifications that don't force you to copy the whole object under the hood. They're just, like, pointers. So, like, hey, we, like, are the same as this other object, but with this extra element added, or something like that. So, if you're growing an array or something like that, you don't end up with 10,000 copies of the array with, like, a new element every time. STEPHANIE: Yeah, that is interesting. And I feel like trying to adopt different paradigms for different tools, you know, is not always as straightforward as some wish it were [laughs]. JOËL: I do want to give a shout-out to an academic paper that is...it is infamously dense. The title of it is Functional Programming with Bananas, Lenses, and Barbed Wire. STEPHANIE: It doesn't sound dense; it sounds fun. Well, I don't about barbed wire. JOËL: It sounds fun, right? STEPHANIE: Yeah, but certainly quirky [laughs]. JOËL: It is incredibly dense. And they've, like, created this custom math notation and all this stuff. But the idea that they pioneered there is really cool, this idea that kind of like I was talking about sort of building libraries in different levels. Their idea is that recursion is generally something that's unsafe and that library and language designers should take care of all of the recursion and instead provide some of these sort of mid-level helper methods to do things. Reducing is one of them, but their proposal is that it's not the only one. There's a whole sort of family of similar methods that are there that would be useful in different use cases. So, reduce allows you to sort of traverse the whole thing. It does not allow you to break out early. It does not allow you to keep sort of track of a sort of extra context element if you want to, like, be traversing a collection but have a sort of look forward, look back, something like that. So, there are other variations that could handle those. There are variations that are the opposite of reduce, where you're, like, inflating, starting from a few parameters and building a collection out of them. So, this whole concept is called recursion schemes, and you can get, like, really deep into some theory there. You'll hear fancy words like catamorphisms and anamorphisms. There's a whole world to explore in that area. But at its core, it's this idea that you can sort of slice up things into this sort of low-level recursion, mid-level helpers, and then, like, kind of userland helpers built on top of that. STEPHANIE: Wow. That is very intense; it sounds like [chuckles]. I'm happy not to ever have to write a recursion ever again, probably [laughs]. Have you ever, as just a web developer in your day-to-day programming, found a really good use case for dropping down to that level? Or are you kind of convinced that, like, you won't really ever need to? JOËL: I think it depends on the paradigm of the language you're working in. In Ruby, I've very rarely needed to write a recursion. In something like Elm, I've had to do that, eh, not infrequently. Again, it depends, like, if I'm doing more library-esque code versus more application code. If I'm writing application code and I'm using an existing, let's say, tree library, then I typically don't need to write a recursion because they've already written traversals for me. If I'm making my own and I have made my own tree libraries, then yes, I'm writing recursions myself and building those traversals so that other people don't have to. STEPHANIE: Yeah, that makes sense. I'd much rather someone who has read that paper [laughs] write some traversal methods for me. JOËL: And, you know, for those who are curious about it, we will put a link to this paper in the description. So, we've talked about a sort of very academic mental model way of thinking about reducing. I want to shift gears and talk about one that I have found is incredibly practical, and that is the idea that reduce is a way to scale an operation that works on two objects to an operation that works on sort of an unlimited number of objects. To make it more concrete, take something like addition. I can add two numbers. The plus operator allows me to take one number, add another, get a sum. But what if I want to not just add two numbers? I want to add an arbitrary number of numbers together. Reduce allows me to take that plus operator and then just scale it up to as many numbers as I want. I can just plug that into, you know, I have an array of numbers, and I just call dot reduce plus operator, and, boom, it can now scale to as many numbers as I want, and I can sum the whole thing. STEPHANIE: That dovetails quite nicely with your take earlier about how you shouldn't pass a block to reduce. You should extract that into a method. Don't you think? JOËL: I think it does, yes. And then maybe it's, like, sort of two sides of a coin because I think what this leads to is an approach that I really like for reducing because sometimes, you know, here, I'm starting with addition. I'm like, oh, I have addition. Now, I want to scale it up. How do I do that? I can use reduce. Oftentimes, I'm faced with sort of the opposite problem. I'm like, oh, I need to add all these numbers together. How do I do that? I'm like, probably with a reduce. But then I start writing the block, and, like, I get way too into my head about the accumulator and what's going to happen. So, my strategy for writing reduce expressions is to, instead of trying to figure out how to, like, do the whole thing together, first ask myself, how do I want to combine any two elements that are in the array? So, I've got an array of numbers, and I want to sum them all. What is the thing I need to do to combine just two of those? Forget the array. Figure that out. And then, once I have that figured out, maybe it's an existing method like plus. Maybe it's a method I need to define on it if it's a custom object. Maybe it's a method that I write somewhere. Then, once I have that, I can say, okay, I can do it for two items. Now, I'm going to scale it up to work for the whole array, and I can plug it into reduce. And, at that point, the work is already basically done, so I don't end up with a really complex block. I don't end up, like, almost ending in, like, a recursive infinite loop in my head because I do that. STEPHANIE: [laughs]. JOËL: So, that approach of saying, start by figuring out what is the operation you want to do to combine two elements, and then use reduce as a way to scale that to your whole array is a way that I've used to keep things simple in my mind. STEPHANIE: Yeah, I like that a lot as a supplement to the model I shared earlier because, for me, when I think about reducing as, like, collapsing into a value, you kind of are just like, well, okay, I start with the collection, and then somehow I get to my single value. But the challenge is figuring out how that happens [laughs], like, the magic that happens in between that. And I think another alias that we haven't mentioned yet for reduce that is used in a lot of other languages is fold. And I actually like that one a lot, and I think it relates to your mental model. Because when I think about folding, I'm picturing folding up a paper like an accordion. And you have to figure out, like, what is the first fold that I can make? And just repeating that over and over to get to your little stack of accordion paper [laughs]. And if you can figure out just that first step, then you pretty much, like, have the recipe for getting from your initial input to, like, your desired output. JOËL: Yeah. I think fold is interesting in that some languages will make a distinction between fold and reduce. They will have both. And typically, fold will require you to pass an initial value, like a starting accumulator, to start it off. Whereas reduce will sort of assume that your array can use the first element of the array as the first accumulator. STEPHANIE: Oh, I just came up with another visual metaphor for this, which is, like, folding butter into croissant pastry when the butter is your initial value [laughs]. JOËL: And then the crust is, I guess, the elements in the array. STEPHANIE: Yeah. Yeah. And then you get a croissant out of it [laughs]. Don't ask me how it gets to a perfectly baked, flaky, beautiful croissant, but somehow that happens [laughs]. JOËL: So, there's an interesting sort of subtlety here that I think happens because there are sort of two slightly different ways that you can interact with a reduce. Sometimes, your accumulator is of the same type as the elements in your array. So, you're summing an array of numbers, and your accumulator is the sum, but each of the elements in the array are also numbers. So, it's numbers all the way through. And sometimes, your accumulator has a different type than the items in the array. So, maybe you have an array of words, and you want to get the sum of all of the characters and all the words. And so, now your accumulator is a number, but each of the items in the array are strings. STEPHANIE: Yeah, that's an interesting distinction because I think that's where you start to see the complex blocks being passed and reduced. JOËL: The complex blocks, definitely; I think they tend to show up when your accumulator has a different type than the individual items. So, maybe that's, like, a slightly more complicated use case. Oftentimes, too, the accumulator ends up being some, like, more complex, like, hash or something that maybe would really benefit from being a custom object. STEPHANIE: I've never done that before, but I can see why that would be really useful. Do you have an example of when you used a custom object as the accumulator? JOËL: So, I've done it for situations where I'm working with objects that are doing tally-like operations, but I'm not doing just a generic tally. There's some domain-specific stuff happening. So, it's some sort of aggregate counter on multiple dimensions that you can use, and that can get really ugly. And you can either do it with a reduce or you can have some sort of, like, initial version of the hash outside and do an each and mutate the hash and stuff like that. All of these tend to be a little bit ugly. So, in those situations, I've often created some sort of custom object that has some instance methods that allow to sort of easily add new elements to it. STEPHANIE: That's really interesting because now I'm starting to think, what if the elements in the collection were also a custom object? [chuckles] And then things could, I feel like, could be really powerful [laughs]. JOËL: There's often a lot of value, right? Because if the items in the collection are also a custom object, you can then have methods on them. And then, again, the sort of complexity of the reduce can sort of, like, fade away because it doesn't own any of the logic. All it does is saying, hey, there's a thing you can do to combine two items. Let's scale it up to work on a collection of items. And now you've sort of, like, really simplified what logic is actually owned inside the reduce. I do want to shout out for those listeners who are theory nerds and want to dig into this. When you have a reduce, and you've got an operation where all the values are of the same type, including the accumulator, typically, what you've got here is some form of monoid. It may be a semigroup. So, if you want to dig into some theory, those are the words to Google and to go a deep dive on. The main thing about monoids, in particular, is that monoids are any objects that have both a sort of a base case, a sort of empty version of themselves, and they have some sort of combining method that allows you to combine two values of that type. If your object has these things and follows...there's a few rules that have to be true. You have a monoid. And they can then be sort of guaranteed to be folded nicely because you can plug in their base case as your initial accumulator. And you can plug in their combining method as just the value of the block, and everything else just falls into place. A classic here is addition for numbers. So, if you want to add two numbers, your combining operator is a plus. And your sort of empty value is a zero. So, you would say, reduce initial value is zero, array of numbers. And your block is just plus, and it won't sum all of the numbers. You could do something similar with strings, where you can combine strings together with plus, and, you know, your empty string is your base case. So, now you're doing sort of string concatenation over arbitrary number of strings. Turns out there's a lot of operations that fall into that, and you can even define some of those on your custom object. So, you're like, oh, I've got a custom object. Maybe I want some way of, like, combining two of them together. You might be heading in the direction of doing something that is monoidal, and if so, that's a really good hint to know that it can sort of, like, just drop into place with a fold or a reduce and that that is a tool that you have available to you. STEPHANIE: Yeah, well, I think my eyes, like, widened a little bit when you first dropped the term monoid [laughs]. I do want to spend the last bit of our time talking about when not to use reduce, and, you know, we did talk a lot about recursion. But when do you think a regular old loop will just be enough? JOËL: So, you're suggesting when would you want to use something like an each rather than a reduce? STEPHANIE: Yeah. In my mind, you know, you did offer, like, a lot of ways to make reduce simpler, a lot of strategies to end up with some really nice-looking syntax [chuckles], I think. But, oftentimes, I think it can be equally as clear storing your accumulator outside of the iteration and that, like, is enough for me to understand. And reduce takes a little bit of extra overhead to figure out what I'm looking at. Do you have any thoughts about when you would prefer to do that? Or do you think that you would usually reach for something else? JOËL: Personally, I generally don't like the pattern of using each to iterate over a collection and then mutate some external accumulator. That, to me, is a bit of a code smell. It's a sign that each is not quite powerful enough to do the thing that I want to do and that I'm probably needing some sort of more specialized form of iteration. Sometimes, that's reduce. Oftentimes, because each can suffer from the same problem you mentioned from reduce, where it's like, oh, you're doing this thing where you mutate an external accumulator. Turns out what you're really doing is just map. So, use map or use select or, you know, some of the other built-in iterators from the enumerable library. There's a blog post on the thoughtbot blog that I continually link to people. And when I see the pattern of, like, mutating an external variable with each, yeah, I tend to see that as a bit of a code smell. I don't know that I would never do it, but whenever I see that, it's a sign to me to, like, pause and be like, wait a minute, is there a better way to do this? STEPHANIE: Yeah, that's fair. I like the idea that, like, if there's already a method available to you that is more specific to go with that. But I also think that sometimes I'd rather, like, come across that pattern of mutating a variable outside of the iteration over, like, someone trying to do something clever with the reduce. JOËL: Yeah, I guess reduce, especially if it's got, like, a giant block and you've got then, like, things in there that break or call next to skip iterations and things like that, that gets really mind-bending really quickly. I think a case where I might consider using an each over a reduce, and that's maybe generally when I tend to use each, is when I'm doing side effects. If I'm using a reduce, it's because I care about the accumulated value at the end. If I'm using each, it's typically because I am trying to do some amount of side effects. STEPHANIE: Yeah, that's a really good call out. I had that written down in my notes, and I'm glad you brought it up because I've seen them get conflated a little bit, and perhaps maybe that's the source of the pain that I'm talking about. But I really like that heuristic of reduce as, you know, you're caring about the output, as opposed to what's going on inside. Like, you don't want any unexpected behavior. JOËL: And I think that applies to something like map as well. My sort of heuristic is, if I'm doing side effects, I want each. If I want transformed values that are sort of one-to-one in the collection, I want map. If I want a single sort of aggregate value, then I want reduce. STEPHANIE: I think that's the cool thing about mixing paradigms sometimes, where all the strategies you talked about in terms of, you know, using custom, like, objects for your accumulator, or the elements in your collection, like, that's something that we get because, you know, we're using an object-oriented language like Ruby. But then, like, you also are kind of bringing the functional programming lens to, like, when you would use reduce in the first place. And yeah, I am just really excited now [chuckles] to start looking for some places I can use reduce after this conversation and see what comes out of it. JOËL: I think I went on a bit of an interesting journey where, as a newer programmer, reduce was just, like, really intense. And I struggled to understand it. And I was like, ban it from code. I don't want to ever see it. And then, I got into functional programming. I was like, I'm going to do reduce everywhere. And, honestly, it was kind of messy. And then I, like, went really deep on a lot of functional theory, and I think understood some things that then I was able to take back to my code and actually write reduce expressions that are much simpler so that now my heuristic is like, I love reduce; I want to use it, but I want as little as possible in the reduce itself. And because I understand some of these other concepts, I have the ability to know what things can be extracted in a way that will feel very natural, in a way that myself from five years ago would have just been like, oh, I don't know. I've got this, you know, 30-line reduce expression that I know is complicated, but I don't know how to improve. And so, a little bit of the underlying theory, I don't think it's necessary to understand these simplified reduces, but as an author who's writing them, I think it helps me write reduces that are simpler. So, that's been my journey using reduce. STEPHANIE: Yeah. Well, thanks for sharing. And I'm really excited. I hope our listeners have learned some new things about reduce and can look at it from a different light. JOËL: There are so many different perspectives. And I think we keep discovering new mental models as we talk to different people. It's like, oh, this particular perspective. And there's one that we didn't really dig into but that I think makes more sense in a functional world that's around sort of deconstructing a structure and then rebuilding it with different components. The shorthand name of this mental model, which is a fairly common one, is constructor replacement. For anyone who's interested in digging into that, we'll link it in the show notes. I gave a talk at an Elm meetup where I sort of dug into some of that theory, which is really interesting and kind of mind-blowing. Not as relevant, I think, for Rubyists, but if you're in a language that particularly allows you to build custom structures out of recursive types or what are sometimes called algebraic data types, or tagged unions, or discriminated unions, this thing goes by a bajillion names, that is a really interesting other mental model to look at. And, again, I don't think the list that we've covered today is exhaustive. You know, I would love it for any of our listeners; if you have your own mental models for how to think about folding, injecting, reducing, send them in: hosts@bikeshed.fm. We'd love to hear them. STEPHANIE: And on that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

This is the second time that we've managed to reach deep into Ericsson and pull out some of the developers that work on the runtime and the language and the standard libraries that we all rely on. We have two members from the Erlang OTP team with us today! We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts on Twitter @akoutmos @lawik @meryldakin @RedRapids @smdebenedetto @StevenNunez and on Mastodon @akoutmos@fosstodon.org @lawik@fosstodon.org @redrapids@genserver.social @steven@genserver.social Sponsored by Groxio (https://grox.io) and Underjord (https://underjord.io)