Rust in Production

The episode delivers consistent technical depth across multiple domains - GStreamer integration, Python-to-Rust migration, temporal workflows, async Rust, and type system design - with concrete architectural patterns. However, it occasionally drifts into philosophy and softer discussion that doesn't yield actionable operator insights, and some sections repeat well-known Rust principles without novel application.

“We constantly run into deadlocks. And we tried to solve it in C and we tried to solve it in Python. And we kept on running into these things. And then eventually, I just decided that since the whole idea of glib and GStreamer is that you can use it from any programming language, let's try and use it from a language that guarantees that there is no deadlocks.”

“We essentially have an API in front and we would be super strict about the types there and just reject anything that wasn't our thing. That couldn't deserialize into our specific types. And we then did a lot of work to like, okay, let's build a JSON schema, something like that. And do a lot of work on the error types.”

The episode covers solid technical choices (Rust for orchestration, strong typing at boundaries, temporal workflows) but these are not particularly contrarian or novel within the Rust ecosystem. The realization that Rust fills Python's traditional orchestration role is interesting, and the focus on type-driven design is well-executed, but both are increasingly mainstream. Few genuinely surprising takes or first-principles arguments emerge.

“What we're doing, like both of us, what we initially picked Rust for, right, for the temporal thing and what we use for Dixiemer, that is like the core of Python's domain because what Python is really for is for linking things made in other languages and other things together. Like Python is super good at that. ...And this is exactly like where you would expect to use Python...And now Rust is not just a different choice. It's also a choice that feels better once you start using it.”

“I find it this kind of work hard to do because you have a working backend and you tell people no you need to start introducing those stronger types you need to start from the very foundation because otherwise you still have the pressure from the outside incoming requests kind of leaking into the api”

Excellent guest quality. Anders is a 5.5-year staff developer at Veo who architected their real-time video processing pipeline migration from C++/Python to Rust and manages the embedded systems layer. Gorm led the backend rewrite in Rust and built the Temporal SDK integration from scratch. Both are practicing operators doing complex systems work at scale, not career podcasters or pure theorists. Their credibility is evidenced by concrete production decisions and technical depth.

“I work for Veo Technologies, and I started here five and a half years ago, and I'm a staff developer. Yeah, and I write software mostly for cameras and our video processing pipelines.”

“I had the seniority to say no this is how we do it...And I took that and built an SDK for us. So it wasn't like fully featured SDK. It was an SDK of the things that we needed.”

The episode includes solid specifics: 5.5-year tenure, timeline (fall 2020 start), concrete problems (8-hour SLA → real-time streaming), named libraries (GStreamer, CUDA, Jetson, Temporal), architectural patterns (pushback pattern, strong typing at API boundaries), and concrete code choices (50k+ lines, custom Temporal SDK, newtypes for IDs). However, it lacks concrete metrics on performance gains, deployment numbers, or specific business impact figures that would strengthen evidence claims.

“The only active component in the original Vero camera was a Raspberry Pi, and all it could do was upload the recorded videos from these two surveillance cameras...So in those days, there was an SLA of eight hours from you finished uploading before you could watch it.”

“We started from scratch, more or less. we looked at what the existing C++ and OpenGL program did, and then we said, let's build some GStreamer elements that can do the same...And then we ended up a really long phase of just testing, trying to get everything to be fast enough and iron out bugs”

The host asks thoughtful, follow-up questions that probe real technical trade-offs (GStreamer vs FFmpeg, C++ reluctance to Rust adoption, async complexity). However, the conversation often meanders into philosophical tangents about language community kindness and text adventure frameworks that don't advance operator learning. The host misses opportunities to press on specific pain points - e.g., no deep dive into the actual deadlocks they hit, or metrics on the migration effort. The tone is collegial but could be more sharply investigative.

“It's because FFmpeg is very good at just running one command and doing that. But if you sort of need to hook in and do complex nodes in the processing pipeline...then FFmpeg starts being easy. It stops being easy.”

“Did you have any connection points with the embedded team that also worked with Rust? Did you share any learnings or share any code?”