<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: diondokter</title><link>https://news.ycombinator.com/user?id=diondokter</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Mon, 15 Jun 2026 18:45:14 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=diondokter" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by diondokter in "Async Rust never left the MVP state"]]></title><description><![CDATA[
<p>Yes, but I can't share the codebases since they're our client's and proprietary. But there aren't a lot of big embedded codebases that are also open source</p>
]]></description><pubDate>Tue, 05 May 2026 11:52:21 +0000</pubDate><link>https://news.ycombinator.com/item?id=48021213</link><dc:creator>diondokter</dc:creator><comments>https://news.ycombinator.com/item?id=48021213</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48021213</guid></item><item><title><![CDATA[New comment by diondokter in "Async Rust never left the MVP state"]]></title><description><![CDATA[
<p>Various prominent people have said years after that .await was the correct choice after all</p>
]]></description><pubDate>Tue, 05 May 2026 11:49:52 +0000</pubDate><link>https://news.ycombinator.com/item?id=48021186</link><dc:creator>diondokter</dc:creator><comments>https://news.ycombinator.com/item?id=48021186</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48021186</guid></item><item><title><![CDATA[New comment by diondokter in "Async Rust never left the MVP state"]]></title><description><![CDATA[
<p>In open source I guess there's two types of work:
1. features
2. maintenance<p>You can 'sell' new features. They cost money to create, but they solve real problems. Those problems also cost money and if that's more than the cost of creating the feature, companies are willing to put in money (generally).<p>Maintenance is harder. But there are now some maintainer funds! Like the one from RustNL: <a href="https://rustnl.org/maintainers/" rel="nofollow">https://rustnl.org/maintainers/</a>
These are broader ongoing work and backed by many orgs chipping in a little bit.<p>Idk if it's the best model, but at least it seems to kinda work</p>
]]></description><pubDate>Tue, 05 May 2026 09:50:09 +0000</pubDate><link>https://news.ycombinator.com/item?id=48020194</link><dc:creator>diondokter</dc:creator><comments>https://news.ycombinator.com/item?id=48020194</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48020194</guid></item><item><title><![CDATA[New comment by diondokter in "Async Rust never left the MVP state"]]></title><description><![CDATA[
<p>So on the title, I picked this because it's simply the truth. Since async landed in 2019 or so, not much has changed.<p>Yes, we can have async in traits and closures now. But those are updates to the typesystem, not to the async machinery itself.
Wakers are a little bit easier to work with, but that's an update to std/core.<p>As I understand it, the people who landed async Rust were quite burnt out and got less active and no one has picked up the torch. (Though there's 1 PR open from some google folk that will optimize how captured variables are laid out in memory, which is really nice to have)
Since I and the people I work with are heavy async users, I think it's maybe up to me to do it or at least start it. Free as in puppy I guess.<p>So yeah, the title is a little baitey, but I do stand behind it.</p>
]]></description><pubDate>Tue, 05 May 2026 09:40:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=48020127</link><dc:creator>diondokter</dc:creator><comments>https://news.ycombinator.com/item?id=48020127</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48020127</guid></item><item><title><![CDATA[New comment by diondokter in "Async Rust never left the MVP state"]]></title><description><![CDATA[
<p>Hi, author here. I mention in the blog that I've tried to quickly hack two of the simplest optimizations in the compiler and it resulted in 2%-5% binary size savings in real embedded (async) codebases. And a quick and probably deeply flawed synthetic benchmark on the desktop showed a 3% perf increase.<p>So yes, it does really matter. Keep in mind that optimizations stack. We're preventing LLVM from doing it's thing. So if we make the futures themselves smaller, LLVM will be able to optimize more. So small changes really compound.</p>
]]></description><pubDate>Tue, 05 May 2026 09:07:58 +0000</pubDate><link>https://news.ycombinator.com/item?id=48019910</link><dc:creator>diondokter</dc:creator><comments>https://news.ycombinator.com/item?id=48019910</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48019910</guid></item></channel></rss>