<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: androidcode</title><link>https://news.ycombinator.com/user?id=androidcode</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Wed, 13 May 2026 21:05:53 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=androidcode" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by androidcode in "Rust in Android: move fast and fix things"]]></title><description><![CDATA[
<p>no_std for instance does not protect the stack completely. That means that, if you for instance have a simple stack-overflow bug in a Rust program when using no_std, even if the program has absolutely no usage of the unsafe keyword, you can get undefined behavior.<p>And one does not even need esoteric code to trigger stack-overflows, dependent on coding style, a simple recursive call that has bugs like proper lack of constraints relative to resources or bugged infinite recursive calls without tail-call optimization, can do it.</p>
]]></description><pubDate>Sun, 16 Nov 2025 18:18:01 +0000</pubDate><link>https://news.ycombinator.com/item?id=45947155</link><dc:creator>androidcode</dc:creator><comments>https://news.ycombinator.com/item?id=45947155</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45947155</guid></item><item><title><![CDATA[New comment by androidcode in "Rust in Android: move fast and fix things"]]></title><description><![CDATA[
<p>Wrong, for any reasonable definition of memory safety, languages like Java and Javascript are memory safe. Java has escape hatches, but the necessity and prevalence of those escape hatches are way, way less than that of Rust. Consider for instance a standard library implementation of a collection in Java and Rust. In Java, there would typically AFAIK rarely ever be even a single usage of escape hatches. For Rust, the collection implementations in the Rust standard library are typically riddled with the unsafe keyword, even for simple collections. Java handles performance by generally relying on JIT.<p>This is not a theoretical exercise. <a href="https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/" rel="nofollow">https://materialize.com/blog/rust-concurrency-bug-unbounded-...</a> .<p>AWS started an initiative to formally verify the Rust standard library, based on volunteer effort and maybe bounties. I think that is interesting, but I looked once at one of the issues for tracking what they had verified, and as I remember, even though they had marked it as fully verified, the main person verifying had called to attention in a post that he had not verified everything that the issue covered.<p>And even for memory-unsafe languages like Rust, there are trade-offs.</p>
]]></description><pubDate>Sun, 16 Nov 2025 18:13:42 +0000</pubDate><link>https://news.ycombinator.com/item?id=45947120</link><dc:creator>androidcode</dc:creator><comments>https://news.ycombinator.com/item?id=45947120</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45947120</guid></item><item><title><![CDATA[New comment by androidcode in "Rust in Android: move fast and fix things"]]></title><description><![CDATA[
<p>Yes, so something like a modernization profile for C++ would make it easier to enforce, and would not require external tools. But it ultimately does not change that C++ is not C, and that the blog is deeply misleading. Nor does it change that Google Android source code appears to have significant issues.<p>> as if there isn't any other memory safe language.<p>But Rust is obviously not a memory safe programming language. Unsafe's prevalence and difficulty, no_std, and arguably also the bugs and holes in the type system of Rust that have not been fixed for many years by now, make this clear.</p>
]]></description><pubDate>Fri, 14 Nov 2025 10:29:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=45925627</link><dc:creator>androidcode</dc:creator><comments>https://news.ycombinator.com/item?id=45925627</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45925627</guid></item><item><title><![CDATA[New comment by androidcode in "Rust in Android: move fast and fix things"]]></title><description><![CDATA[
<p>BTW; Do you know if it is possible to track new comments to Hacker News threads?</p>
]]></description><pubDate>Fri, 14 Nov 2025 09:21:31 +0000</pubDate><link>https://news.ycombinator.com/item?id=45925280</link><dc:creator>androidcode</dc:creator><comments>https://news.ycombinator.com/item?id=45925280</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45925280</guid></item><item><title><![CDATA[New comment by androidcode in "Rust in Android: move fast and fix things"]]></title><description><![CDATA[
<p>That argument can be applied to unsafe Rust as well. There are code reviews, coding standards and other checks for a reason.<p>Though, I suppose something like C++ profiles, just for modernization, might make it much easier to enforce and track that modern C++ is used.</p>
]]></description><pubDate>Fri, 14 Nov 2025 09:18:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=45925253</link><dc:creator>androidcode</dc:creator><comments>https://news.ycombinator.com/item?id=45925253</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45925253</guid></item><item><title><![CDATA[New comment by androidcode in "Rust in Android: move fast and fix things"]]></title><description><![CDATA[
<p>The blog post has a number of issues, including mixing C and C++. And Android C++ source code is often filled with C-style code, especially the older the code, and is not always that good in several aspects.<p>As an example, from <a href="https://android.googlesource.com/device/generic/trusty/+/c3f3bcf29f3e162c9b077a5b9b24333336a73d23%5E%21/#F0" rel="nofollow">https://android.googlesource.com/device/generic/trusty/+/c3f...</a><p>Many of the files in that commit have a lot of C-style code, yet are classified as C++. C and C++ are very different programming languages, and memory safety is arguably significantly easier to achieve in practice in C++ than in C, yet in the blog post, C++ is blamed for C-style code, and C and C++ are not differentiated.<p>Compare and contrast with <a href="https://android.googlesource.com/device/generic/goldfish/+/df69b9ece1a47c19a0bb3877a58760dd68d0d4fc/hals/radio/AtResponse.cpp" rel="nofollow">https://android.googlesource.com/device/generic/goldfish/+/d...</a> . That source code file has much more modern C++. Though even then, it contains goto, and modern C++ code reviews would normally not accept goto in my experience. I do not understand what Google Android is doing when its developers are using goto. Could they not have used lambdas in those places where they are using goto? The mixture of std::string_view and goto, modern and yuck, is disconcerting.<p>On a different topic, how much of the new Rust code is vendored dependencies? Is Fuchsia included?<p>Maybe the real value for Google Android that Rust holds, is that it mostly prevents C-style code from being written. And Rust does not support goto, and while I think an argument could be made that goto is OK to include in a toolbox, its usage should be very, very, very, very rare. Why does somewhat modern Google Android C++ allow goto?<p>I am not impressed by Google Android's C++ code quality. Are Google Android developers, independent of language, significantly below average?<p>C++ does have baggage, cruft and issues. But having strange C++ code (like goto) and also blaming C++ for C-style code, does not help paint an honest and accurate image. And if Google Android's C++ code review process accepts goto willy-nilly, I do not consider Google Android to be at all credible on any subject related to code quality, memory safety and security in any programming language.</p>
]]></description><pubDate>Fri, 14 Nov 2025 09:00:11 +0000</pubDate><link>https://news.ycombinator.com/item?id=45925158</link><dc:creator>androidcode</dc:creator><comments>https://news.ycombinator.com/item?id=45925158</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45925158</guid></item></channel></rss>