Developer Voices

This week we take a look at what you can do with a GPU when you get away from just using it to draw polygons. Agnès Leroy has spent most of her career programming, optimizing and converting programs to run on that oh-so-curious piece of specialised processing hardware, and we go through all the places that journey has taken her. From simulating the flow of fluids in hydroelectric powerstations, to figuring out how to make a new approach to encryption run fast enough to make it practical…

–

Become a Developer Voices supporter! https://patreon.com/DeveloperVoices

A Fully Homomorphic Encryption Scheme (pdf): https://crypto.stanford.edu/craig/craig-thesis.pdf

CUDA platform: https://developer.nvidia.com/cuda-zone

Rust-CUDA: https://github.com/Rust-GPU/Rust-CUDA

And in case anyone was wondering, A List of Hydroelectric Power Stations in France: https://en.wikipedia.org/wiki/Category:Hydroelectric_power_stations_in_France

–

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Kris on Twitter: https://twitter.com/krisajenkins

OCaml has one of the best-loved compilers available, and parts of it are surprisingly pluggable, so it’s not surprising that someone would eventually try to wed OCaml with JavaScript and the web browser. In fact, the ecosystem has gone further, and there are now a bevvy of options for people who want to write OCaml and run it in the browser, or want to write OCaml in the browser, or want to write something that looks like JavaScript but runs OCaml on the backend.

Joining me to explore the OCaml-meets-JavaScript world is Antonio Montiero. He’s a key maintainer/contributor for Melange and ReasonML, as well as several other interesting OCaml web projects.

We kick off by discussing the benefits of OCaml and how it clicked with him personally, before we dive into how and why the compiler is being adapted and tweaked to take it to a whole new audience of web-hungry developers.

–

Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices

Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join

Sponsor Antonio’s Work: https://github.com/sponsors/anmonteiro/

–

The OCaml Platform: https://ocaml.org/platform

OCaml on Discord: https://discuss.ocaml.org/t/ocaml-discord-server/1884

ReasonML: https://reasonml.github.io/en/

What is Melange? https://melange.re/v4.0.0/what-is-melange.html

Melange for React Devs: https://react-book.melange.re/

The Melange Playground: https://melange.re/v4.0.0/playground/

js_of_ocaml: https://github.com/ocsigen/js_of_ocaml

FUN OCaml Conference: https://fun-ocaml.com/

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Kris on Twitter: https://twitter.com/krisajenkins

Mapping is a hugely complex task to take on. Even if you moved as much of the data-management as you can out to 3rd-party services, you’d still have a tonne of work to do weaving together map tiles, routing information, GPS data, points of interest, search and more. And as if that wasn’t enough, you’d probably want that software to work on a whole range of platforms, so you have to build something that works on iOS, Android and more. It’s little wonder that the space is dominated by a few closed-source projects owned by huge companies with near-limitless resources.

But that doesn’t mean the problem can’t be cracked as an open-source project. This week we look at the open source map library Ferrostar. Joining me to discuss it is the project’s lead developer, Ian Wagner, as we explore the problem space and dive down into Ferrostar’s architecture: A core Rust library serving a suite of custom UI shells written in Kotlin, Swift, WASM and TypeScript.

Along the way there are tips for anyone attempting to build a map, or wanting to interop Rust with other languages.

–

Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices

Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join

Ferrostar on Github: https://github.com/stadiamaps/ferrostar

Ferrostar user guide: https://stadiamaps.github.io/ferrostar/

MapLibre: https://maplibre.org/

Project OSRM: https://project-osrm.org/

Dioxus (Rust UI framework): https://dioxuslabs.com/

Slint: https://slint.dev/

UniFFI (repo): https://github.com/mozilla/uniffi-rs

UniFFI (user guide): https://mozilla.github.io/uniffi-rs/latest/

Beeline (navigation device): https://beeline.co/

Ian on Mastodon: https://fosstodon.org/@ianthetechie

Ian on Twitter: https://x.com/ianthetechie

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Kris on Twitter: https://twitter.com/krisajenkins

The terminal might be the most used development tool in history. So it’s a little odd that it hasn’t changed that much in the decades since the terminal first came into being. Is the terminal a “completed” project? Or are there new ways to look at it that might make it even more useful?

This week’s guest—Zach Lloyd—is convinced the terminal is ripe for a new approach that’s more than just a new coat of paint. And in this episode we dive into what that approach is, what he’s trying to do with the Warp Terminal, and how it’s put together using a combination of Rust and GPU shaders.

Along the way we look at what LLMs could do to improve the terminal experience, where the boundary lies between terminal and shell, and where Go has solved some problems and created others over at Warp HQ.

–

Become a Supporter on Patreon: https://patreon.com/DeveloperVoices

Become a Supporter on YouTube: https://www.youtube.com/@developervoices/join

Warp Homepage: https://app.warp.dev/referral/VQGWW3

VT100 Information: https://vt100.net/

Game of Life in Rust: https://github.com/krisajenkins/game-of-life-rust

Zed (Text editor in Rust): https://zed.dev/

Flutter: https://flutter.dev/

The Painter’s Algorithm: https://en.wikipedia.org/wiki/Painter%27s_algorithm

Zach on LinkedIn: https://www.linkedin.com/in/zachlloyd/

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Kris on Twitter: https://twitter.com/krisajenkins

–

0:00 Intro

2:22 Why Create A New Terminal?

7:28 Blurring the Lines Between Terminal and Shell

16:04 How Do You Build A Terminal Program?

24:55 Implementing a Terminal in Rust

30:32 Rust Frameworks for GPU Shaders

40:04 Will Any Of This Go Open Source?

42:49 Managing a Mixture of Rust and Go

47:52 What’s the DX of Warp?

51:43 Integrating LLMs into the Terminal

1:05:58 Outro

A language’s AST—it’s abstract syntax tree—is nearly always a hidden implementation detail. It’s not treated as part of the language, but merely the intermediate step between parsing and compiling. But this week’s guest aims to flip that relationship on its head...

Peter Saxton joins me to talk about EYG - an AST-first language that defines the fundamental capabilities first, and then stretches out from there to surface syntax and final execution.

The result is something that can teach us a lot about how a typed, functional programming language works; how an extensible effects system works; and could make writing a new programming language as easy as defining the syntax you want, and parsing that into EYG's AST.

--

EYG Homepage: https://github.com/crowdhailer/eyg-lang

TinyGo: https://tinygo.org/

Become a Supporter on Patreon: https://patreon.com/DeveloperVoices

Become a Supporter on YouTube: https://www.youtube.com/@developervoices/join

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Kris on Twitter: https://twitter.com/krisajenkins

DuckDB’s become a favourite data-handling tool of mine, simply because it does so many small things well. It can read and write a huge number of data formats; it can infer schemas automatically when you just want to move quickly; and it can interface with most languages, run like lightning on the desktop or be embedded into a webpage. I’m a huge fan.

But I’m not nearly as knowledgeable as this week’s two fans, Simon Aubury and Ned Letcher, who’ve just written a book on all the many ways you can use DuckDB and all the hidden tricks and tips that help you make the most of this. So in this episode we’re taking a practical look at DuckDB, what problems it can solve at work, and how to start getting the most out of it.

–

Getting Started with DuckDB (book): https://packt.link/byKYt

DuckDB episode with Hannes Mühleisen: https://youtu.be/pZV9FvdKmLc

DuckDB: https://duckdb.org/

dplyr, the data-manipulation language: https://dplyr.tidyverse.org/

duckplyr, DuckDB’s ‘native’ version: https://github.com/duckdblabs/duckplyr

Substrait: https://substrait.io/

Observable (Markdown+DuckDB=Reports): https://observablehq.com/framework/

DuckDB’s “friendly” SQL: https://duckdb.org/docs/sql/dialect/friendly_sql.html

Community Extensions: https://community-extensions.duckdb.org/

DuckCon #5: https://duckdb.org/2024/08/15/duckcon5.html

Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices

Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join

Simon on Twitter: https://x.com/SimonAubury

Ned on Twitter: https://x.com/nletcher

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Kris on Twitter: https://twitter.com/krisajenkins

RRWeb is based on a simple idea: If you capture all the DOM events in a browser session, and when they happened, you could play it back later. Play it back for diagnosing error conditions, for understanding your user’s journey, or for creating demo videos that can be edited element-by-element instead of frame-by-frame.

Unfortunately, the simple idea gets tricky when you try to implement, for a whole host of browser specific glitches, differences, and places where the HTML5 spec ran out. It’s exactly the kind of project where might want to use it, but you want someone else to maintain it!

Joining us this week is Justin Halsall—a chief contributor to rrweb—to teach us about some of the more barren corners of the browser spec, how he’s fought through them, and what the benefits are on the other side…

–

RRWeb homepage: https://www.rrweb.io/

RRWeb on Github: https://github.com/rrweb-io/rrweb

RecordOnce: https://recordonce.com/

Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices

Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join

Justin on Twitter: https://x.com/juice10

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Kris on Twitter: https://twitter.com/krisajenkins

–

0:00 Intro

3:10 What is rrweb Doing?

6:12 Beginning With A Naive Implementation

9:49 Supporting Canvas Tags

13:05 Exotic HTML 5 Tags Like Midi

14:31 The Internal Data Format

17:39 How Reliable Can This Be In Practice?

23:04 Cross-Browser Support

24:32 Exploring The Use Cases

30:17 Privacy Issues

33:46 Analyzing User Interactions En-Masse

36:40 Is The Spec Greater Than The Tool?

38:20 The Practical Benefits Of Contributing To Open Source

44:45 Updating Recordings After The Website Changes

49:55 Playing Well (Or Badly) With Popular Frameworks

53:21 The Runtime Burden

54:17 What's Coming In The Future?

1:01:02 Outro

The ZigLang team have put an astonishing amount of effort into making Zig work an effective tool for compiling C across different architectures. Work that benefits the Zig language, but also has a chance to benefit languages like Python and Rust. Or indeed, any language that uses native C libraries somewhere in its stack.

So this week we’re joined by Loris Cro of the Zig team to dive into how you make a reliable, cross-platform toolchain that can compile C anywhere it finds it. And in doing so, 

–

Zig Homepage: https://ziglang.org/

Zig on Github: https://github.com/ziglang/zig

MingW for Windows: https://www.mingw-w64.org/

All Your Codebase: https://allyourcodebase.com/

Ziglang on PyPi: https://pypi.org/project/ziglang/

Shout out to Whitequark: https://pypi.org/user/whitequark/

Darling: https://www.darlinghq.org/

WineHQ: https://www.winehq.org/

PyPi Stats: https://pypistats.org/packages/__all__

The Zine static site generator: https://zine-ssg.io/

The Zine source code: https://github.com/kristoff-it/zine

Loris’ website: https://kristoff.it/

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Kris on Twitter: https://twitter.com/krisajenkins

Back in 2012, José Valim started building Elixir to as a way to have his ideal programming language running on the same platform as Erlang. Fast-forward 12 years and it’s become build anything from distributed infrastructure to notebooks and websites.

In this week’s Developer Voices, José joins us to tell the history of Elixir in a series of design choices. Which features mattered to him in the early days, and which ones excite him most now. What’s going on under the hood to make Elixir tick, and what does its future hold?

–

Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices

Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join

Elixir Homepage: https://elixir-lang.org/

Elixir Docs: https://elixir-lang.org/docs.html

Numerical Elixir: https://github.com/elixir-nx

Phoenix: https://phoenixframework.org/

Livebook: https://livebook.dev/

José’s Livebook & Elixir Presentation: https://www.youtube.com/watch?v=pas9WdWIBHs

Comparing Elixir & Erlang Variables: https://dashbit.co/blog/comparing-elixir-and-erlang-variables

Gleam on the BEAM: https://youtu.be/RntfkL8lUY4

José on Github: https://github.com/josevalim

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Kris on Twitter: https://twitter.com/krisajenkins

There’s huge pressure on Python at the moment to get faster, ideally without changing at all. One increasingly–popular way of achieving that impossible task is to push the performance critical code down into C, C++, or Rust. And this week we’re focussing on the Python route, as we take a look at PyO3.

David Hewitt’s the principal committer to PyO3, and he joins us to go through the easy parts, the hard parts, and the works in progress, giving us an insight into how Python and Rust work under the hood, and quite how much work it takes to make them work as one.

–

PyO3 User Guide: https://pyo3.rs/v0.22.0/

PyO3 on Github: https://github.com/PyO3/pyo3

Polars: https://pola.rs/

Tokio: https://tokio.rs/

Trio: https://trio.readthedocs.io/

Robyn: https://github.com/sparckles/Robyn

Faster CPython: https://github.com/faster-cpython

Maturin: https://www.maturin.rs/

–

David on Mastodon: https://fosstodon.org/@davidhewitt

David on Twitter: https://x.com/davidhewittdev

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Kris on Twitter: https://x.com/krisajenkins