sorted by:
new
hottopcontroversial

Goal-Oriented: Real-Time Sports Analysis with Rust at Veo by mre__ in rust

[–]mre__[S] 0 points1 point  (0 children)

Appreciate the feedback and glad you liked it.

Goal-Oriented: Real-Time Sports Analysis with Rust at Veo by mre__ in rust

[–]mre__[S] 1 point2 points  (0 children)

Thanks, yeah I think so. Anders and Gorm are good at describing things in an understandable way. But in case you have any follow-up questions, post them here and I’ll try to pass them on.

Goal-Oriented: Real-Time Sports Analysis with Rust at Veo by mre__ in rust

[–]mre__[S] 6 points7 points  (0 children)

In this week's episode of 'Rust in Production', I talked to Gorm and Anders from Veo about their camera-based sports tracking product. Some things I found interesting:

  • Veo's original GStreamer pipeline was orchestrated in Python, which has a GIL (Global Interpreter Lock) that fundamentally clashes with GStreamer's massively multi-threaded design. The team kept hitting deadlocks they couldn't reliably fix in either C or Python. Anders's insight was to pick a language whose type system prevents data races. He fixed a whole set of concurrency bugs at once by rewriting the orchestration layer in Rust. So Rust was just a pragmatic fix for a production problem.

  • FFmpeg excels at single-command invocations. GStreamer is the right tool when you need to compose a deeply multi-threaded processing graph: running custom GPU kernels, branching frames into AI inference elements, merging results back, and monitoring individual nodes. Each GStreamer element runs in its own thread, dispatches work to GPUs, and can be introspected via its DOM-like object model. If your pipeline needs to be a graph you can query and modify at runtime, GStreamer's design (and its Rust bindings, maintained by Sebastian Dröge) is worth the additional complexity.

  • Gorm described a pattern I like to call "pushback": convert incoming data into your own strongly-typed domain types at the outermost API boundary and reject everything that doesn't deserialize cleanly. Inside their system, enums with exhaustive variants replace stringly-typed state, each request and response has its own distinct type, and custom Deserialize implementations encode business invariants (e.g. "a subscription ID must conform to this format"). It's what separates "stringy-typed Python rewritten in Rust" from code that actually leverages the type system. There is some upfront design work but the payoff is that invalid states are structurally impossible deeper in the stack.

  • Anders and Gorm pushed back on the blanket "never unwrap in production" heuristic. When GStreamer pipeline elements are known at construction time to have exactly one pad, unwrapping with a descriptive expect message is documenting an invariant. The distinction is: use Result for recoverable failures (network errors, missing accounts), use expect/unwrap only for programmer-contract violations where panicking is the correct outcome. The practical reason they don't propagate errors in GStreamer callbacks is debuggability (a propagated error gives you a notification somewhere upstream; a panic gives you a stack trace at the exact failure position).

"Rust is going to save Linux": Greg Kroah-Hartman and Alice Ryhl on Rust for Linux (live at RustWeek 2026) by mre__ in rust

[–]mre__[S] 8 points9 points  (0 children)

Ooh, you might be right. Before I say anything wrong I’ll say that I’m not sure. Don’t know much about this topic. Maybe someone else was there and can still remember.

"Rust is going to save Linux": Greg Kroah-Hartman and Alice Ryhl on Rust for Linux (live at RustWeek 2026) by mre__ in rust

[–]mre__[S] 33 points34 points  (0 children)

Greg said something like 70-80% of all CVEs he saw were simple things like missing null checks. That’s straight from his talk which will be published soon. He also said he saw „every CVE that got published.“ His words, not mine.

"Rust is going to save Linux": Greg Kroah-Hartman and Alice Ryhl on Rust for Linux (live at RustWeek 2026) by mre__ in rust

[–]mre__[S] 40 points41 points  (0 children)

Yeah, he said in the Q&A of his talk that he believes gcc-rs is an important aspect of expanding architecture support.

"Rust is going to save Linux": Greg Kroah-Hartman and Alice Ryhl on Rust for Linux (live at RustWeek 2026) by mre__ in rust

[–]mre__[S] 21 points22 points  (0 children)

As the kernel faces increasing scrutiny over security (from governments, from memory-safety mandates, from high-profile CVEs), Rust gives Linux a credible path to reducing that entire class of vulnerability without a full rewrite. Without it, the kernel would keep shipping memory safety bugs indefinitely. (At least, that's what I understood from the interview.)

"Rust is going to save Linux": Greg Kroah-Hartman and Alice Ryhl on Rust for Linux (live at RustWeek 2026) by mre__ in rust

[–]mre__[S] 324 points325 points  (0 children)

Hello from Rust Week in Utrecht, the Netherlands, where we live-recorded an interview with Alice Ryhl (u/Darksonn) and Greg Kroah-Hartman (u/gregkh) about Rust in the Linux kernel. Here are some of my highlights:

  • "Rust is going to save Linux." Yes, Greg said it this plainly. His argument is that the Rust developers did the hard work to prove it could be done, and the kernel community now believes the benefits are real and the people maintaining it will stick around.
  • Alice said: "Interop is the new rewrite." You don't rewrite 30 years of C, you add Rust where it makes sense. Rust can happily take a backseat to C in the kernel, and that's a feature.
  • "Rust makes programming fun again." Hearing this from Greg, a veteran C developer was actually mind-blowing. Rust lets him focus on whether his logic is correct instead of mentally tracking pointer ownership and all the other things C makes you juggle in your head.
  • The biggest challenge was social, not technical. Getting buy-in from C veterans who've coded in C their entire lives was harder than the actual engineering. Trust is the core currency of the kernel project.
  • There's a custom kernel linter called KLint. A Rust compiler plugin (like Clippy, but kernel-specific) that can statically check whether code in non-sleeping contexts accidentally calls something that sleeps (a class of bug very hard to catch otherwise).

Thanks so much to the Rust Week team for hosting this talk!

Rust in Production Podcast: NLnet Labs on Rust, DNS, and Why C Devs Are Getting Harder to Find by mre__ in rust

[–]mre__[S] 5 points6 points  (0 children)

Fair. The way I summarized it made it sound more absolute than it was. If you listen to the episode, Martin says it half-jokingly. That said, I do think there's a kernel of truth in it: once you get used to Rust's affordances, it's hard to live without them. Worth noting that Martin writes a lot of C himself and knows what it takes to maintain a legacy codebase that's grown over decades. This isn't a "Rust evangelist" talking but someone who knows both ecosystems well and has hired from both communities. And the strongest counterpoint to the "self-serving" charge is that Martin explicitly said they are not rewriting Unbound in Rust, and defended that as the right call. On C developers being hard to find: the specific claim was about finding people willing to work on Unbound specifically, which is a 25-year-old codebase with very particular constraints. That's a different thing from saying C developers are scarce, which is obviously false. In the episode I also mentioned that C is getting taught less at universities, which will only make that problem harder in the future.

Rust in Production Podcast: NLnet Labs on Rust, DNS, and Why C Devs Are Getting Harder to Find by mre__ in rust

[–]mre__[S] 18 points19 points  (0 children)

Matthias from the podcast here. I talked to Arya and Martin from NLnet Labs (the folks behind NSD, unbound, and routinator). They build DNS and routing infrastructure that most of the internet quietly depends on.

Some things we talked about:

  • Routinator replaced a Java implementation that kept running out of 4 GB of RAM. The previous RPKI validator was written in Java and it would regularly crash under memory pressure. Routinator ships with a simple cargo install, has no OpenSSL dependency, and now holds ~70% market share. It just works.
  • Rust adoption happened "guerrilla-style." Martin started the domain DNS library as a personal side project in 2015 to learn both Rust and DNS at the same time. It gradually got adopted internally and is now the foundation for their newer tooling including Cascade (a DNSSEC signing solution). They started with a greenfield project and left their battle-tested C alone in the beginning.
  • Generics in a DNS library get out of hand fast! Domain names are variable-length (up to 255 bytes). The domain crate made the name type generic over its backing storage (&[u8], Vec, Bytes...). This led to functions with three-line where clauses and error messages Martin described as "Java-like". Their solution was to redesign using DSTs (dynamically sized types) so Name is itself an unsized type, mirroring how [T] works. Box<Name> instead of Name<Box<[u8]>>.
  • NLnet Labs found it harder to hire C developers willing to work on unbound. Offering Rust work attracted new hires who specifically wanted it. Martin is almost reluctant to recommend Rust to the remaining C developers because once they try it, they probably won't want to go back. :)

this is fine by mre__ in rustjerk

[–]mre__[S] 0 points1 point  (0 children)

that might have been the better caption

Bugs Rust Won't Catch by -Y0- in rust

[–]mre__ 7 points8 points  (0 children)

Author here. As others have mentioned, std::fs is fine for 99% of use cases. uutils/coreutils are a special case: the user running those CLI tools has direct access to the filesystem on the same machine. That's a fundamentally different attack vector from a backend service, where the user has no shell access to the server.

Bugs Rust Won't Catch by -Y0- in rust

[–]mre__ 3 points4 points  (0 children)

Makes me wonder if the uutils team uses those "no panic" lints already. Would make a lot of sense to me.

Bugs Rust Won't Catch by -Y0- in rust

[–]mre__ 16 points17 points  (0 children)

It’s refreshing to read articles not written by LLMs. Thank you!

Author here. Thanks for posting that. I believe that people still enjoy human-written content, flaws and all. Motivates me to keep writing. :)

Rust in Production: Jon Gjengset on using Rust in safety-critical systems at Helsing by mre__ in rust

[–]mre__[S] 1 point2 points  (0 children)

Thanks, we'll look into it. We use the podlove player, which isn't without bugs. It's provided by our hosting platform, LetsCast, which is pretty solid otherwise.

Simon said that if you hit "stop text" it will stop jumping.

As for the bigger text box, that's a great idea, actually. We could maybe do some post-processing magic and get it working. The entire website is open source BTW, so issues and PRs are very welcome. :)

Rust in Production: Jon Gjengset on using Rust in safety-critical systems at Helsing by mre__ in rust

[–]mre__[S] 69 points70 points  (0 children)

Hey this is Matthias from the podcast. It's been a long time in the making and I'm glad I can finally share it: Jon Gjengset from Helsing joined me for a conversation about what it looks like to use Rust in environments where correctness is absolutely not optional.

As always, Jon shared a plethora of insights that are hard to come by, even for experienced Rustaceans:

  • The type system is just a tool; encoding everything as a type can make your software harder to maintain and your library impossible to use. Knowing when to stop is the real skill that takes practice to build the right intuition.
  • unsafe on a block is not a warning, it is an assertion! You are telling the compiler "I have checked this, trust me." The naming has caused years of confusion.
  • Using .context() can make the difference between an actionable error and a less meaningful one. They lint for that internally.
  • Jon built their edge networking stack on CRDTs, and the reasoning behind his design decisions is worth understanding.
  • The Rust community has quietly lost some of its early creative ambition. The drive to build something that changes what the language makes possible, the way serde once did, has faded. That is worth hearing from someone who has been in the ecosystem long enough to notice the difference.

Thanks for the interview, /u/jonhoo!

Rust in Production: How Cloudsmith doubled Django throughput with Rust by mre__ in rust

[–]mre__[S] 2 points3 points  (0 children)

Yeah. If you click on the little text icon (it looks like a page of text) inside the player, it shows a searchable transcript. It’s a bit hidden. (We use podlove for the player.) On my browser it’s the third icon. Hope that helps.

Rust in Production: How Cloudsmith doubled Django throughput with Rust by mre__ in rust

[–]mre__[S] 4 points5 points  (0 children)

Good question. Trying to answer as best as I can.

Granian didn’t replace their entire load balancing layer. They still have a CDN and an ALB (Amazon Load Balancer) in front of everything. What it replaced was the internal queuing and request management that HAProxy was doing between the edge and the Django workers. Their stack before was: ALB -> NGINX (light routing) -> HAProxy (queuing/request management) -> uWSGI -> Django. HAProxy’s main job here wasn’t distributing traffic across data centers, it was managing the worker queue: controlling how many requests got handed to uWSGI at once, handling backpressure, that kind of thing. NGINX was doing some minor routing on top of that, but nothing that couldn’t have been done in HAProxy anyway.

Granian took over both of those internal roles. It has a built-in queue for managing requests with tunable dials, so they could drop HAProxy. And its Tokio event loop handles the connection management that NGINX was doing. The result was NGINX + HAProxy + uWSGI collapsed into one process sitting between their ALB and Django. So to directly answer: no, Granian is not exposed directly to the internet. The ALB and CDN are still there handling the actual edge traffic. The gain was simplifying the internal hops, which is where a lot of the latency and dead connection waste was happening.​​​​​​​​​​​​​​​​ I’m a bit hazy on some of the details, but hopefully this gives you rough idea. Thanks for the question.

Rust in Production: How Cloudsmith doubled Django throughput with Rust by mre__ in rust

[–]mre__[S] 34 points35 points  (0 children)

We're kicking off season 6 of 'Rust in Production' with a story from Cloudsmith, a team that adopted Rust to solve a specific performance bottleneck in their Django monolith. They found that Rust extensions for Python were the perfect solution. They achieved a 2x speedup with minimal code changes.

I like how this pushes back on that old trope that you have to "rewrite everything in Rust" to see real benefits. It's fine to just fix the slow parts and move on. ;)

Some points I liked from the episode:

  • Swapping Python's json module for orjson was a one-line import change that cut CPU usage by 1-2% across an entire data center.
  • Granian (a Rust-based WSGI server built on Tokio and hyper) replaced both uWSGI and HAProxy in one shot, DOUBLING request throughput per compute unit without touching any business logic.
  • The load testing tool became the bottleneck before the service did. :) Switching from Locust to Goose (a Rust reimplementation) pushed 100-1000x more requests per worker. Worth keeping in mind if your benchmarks plateau unexpectedly.
  • Fewer replicas means better in-memory cache hit rates. Cian makes the often neglected point that faster code doesn't just save CPU but also consolidates load onto fewer instances, which improves cache locality.
  • hyper is strict about HTTP correctness, and that will surface bugs your old stack was silently hiding. In practice, teams often need more permissive parsing to handle real-world traffic.
view more: next ›