<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Architecture on VisorCraft News</title><link>https://www.visorcraft.com/news/tags/architecture/</link><description>Recent content in Architecture on VisorCraft News</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Sat, 15 Aug 2026 10:00:00 -0500</lastBuildDate><atom:link href="https://www.visorcraft.com/news/tags/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Why We Picked Rust for Desktop Apps in 2026</title><link>https://www.visorcraft.com/news/2026/08/why-we-picked-rust-for-desktop-apps-in-2026/</link><pubDate>Sat, 15 Aug 2026 10:00:00 -0500</pubDate><guid>https://www.visorcraft.com/news/2026/08/why-we-picked-rust-for-desktop-apps-in-2026/</guid><description>&lt;p&gt;Desktop software fails in boring, predictable ways, and most of those failures are decided the day you pick the implementation language, long before the first user ever files a bug: the crash reporter fills up with use-after-free in a callback nobody remembered to disconnect, the installer balloons because the runtime has to come along for the ride, the UI hitches because a background task was never actually background, and the Linux build rots because the one person who understood the makefiles left. We have shipped eight pieces of desktop software and supporting libraries whose cores are all Rust, and none of those failure modes is theoretical to us, because we paid for several of them in earlier stacks before moving, so this is the post about what changed between 2020 and now that made Rust the default answer for new desktop work, and the places where it still makes us pay.&lt;/p&gt;</description></item></channel></rss>