[HN Gopher] Rust in Android: move fast and fix things
___________________________________________________________________
Rust in Android: move fast and fix things
Author : abraham
Score : 220 points
Date : 2025-11-13 18:32 UTC (4 hours ago)
(HTM) web link (security.googleblog.com)
(TXT) w3m dump (security.googleblog.com)
| mk89 wrote:
| This is the bomb that sank C++ in 2026.
|
| Have fun justifying that Rust is "also" unsafe, with the right
| tools you can achieve the same in C++, if you're a great dev you
| can do even better, etc.
| gchamonlive wrote:
| I personally have zero interest in these feud wars. I'm only
| glad there are more quality options for Devs to develop safer
| system tools.
| beeflet wrote:
| rust has other advantages. I think cargo is better than cmake.
| I think the syntax is better, I think the way dependencies and
| modules are handled is better.
|
| It can be annoying to write "safe" code, but once it meets a
| certain standard I can be confident in multithreaded
| applications I write.
|
| I would like to use rust to write android apps. I don't really
| like the whole android studio java thing.
| gpm wrote:
| > I think cargo is better than cmake
|
| I expect that Google is using neither of these for most of
| their own code, but rather their own build system (which I
| think is the same between the languages).
|
| I absolutely agree if you aren't Google though.
| petcat wrote:
| Yeah my understanding is that google has some sort of God
| program they use that can compile anything and has 10,000
| command line options.
| kridsdale1 wrote:
| It's https://en.wikipedia.org/wiki/Bazel_(software)
| kridsdale1 wrote:
| Google3 uses Blaze which is an internal Bazel. And it's
| fantastic. I like Facebook's BUCK too but it's basically
| the same thing.
|
| If I were to go to another company I'd promote using either
| of the above.
| vlovich123 wrote:
| What does Android do for Rust?
| ncruces wrote:
| Android uses Soong:
| https://source.android.com/docs/setup/build
|
| Proprietary code uses the internal version of Bazel:
| https://bazel.build/
| johnisgood wrote:
| I dislike Rust, but I would definitely prefer it over the
| "Android Studio Java / Kotlin thing", for sure.
| mk89 wrote:
| I cannot like Rust syntax, sorry.
|
| For me the ideal syntax is C/Go, just to be clear what I
| like.
|
| But I agree that the tooling that cargo introduced is a
| breath of fresh air in a world dominated by huge makefiles,
| libraries copied in the repository (I know, there is Conan,
| vcpkg etc)...
| dontlaugh wrote:
| All three have very similar syntax when compared even to
| something like Python or Ruby, let alone ML or Haskell.
| Seems like a spurious complaint.
| gf000 wrote:
| I mean, Rust is quite a different category than C or Go,
| if this is the 3 languages you reference.
|
| Rust has plenty of syntax coming straight from ML (okay,
| not straight, probably through OCaML)
|
| Pattern matching, destructuring, expressions everywhere,
| etc are stuff that C/Go never even heard about.
| baq wrote:
| No need to like it. It isn't brainfck and does the job.
| MBCook wrote:
| I don't disagree, that's part of why I like Swift so much.
| Rust looks very C++ to me.
|
| But if I was working in C++ and had a choice of C++ or
| Rust, I'd go Rust based on this.
| mk89 wrote:
| Agree! Swift I forgot to mention. What a nice and elegant
| language.
| claudiug wrote:
| in the beginning I also hate it, but now is fine.
| guywithahat wrote:
| Go is such a great language. If your code base doesn't mind
| garbage collection and doesn't depend on some external
| library, everyone should really look at go. Great
| multithreading, memory safe, great error handling, and a
| familiar syntax for people coming from C++/Java/etc.
| gf000 wrote:
| > If your code base doesn't mind garbage collection and
| doesn't depend on some external library, everyone should
| really look at go
|
| I mean, at that point pretty much every language would be
| a decent choice.
| ViewTrick1002 wrote:
| > Great multithreading
|
| Until you stumble upon the countless footguns. At least
| they generally don't lead to memory unsafety, just
| garbage data.
|
| _Data Race Patterns in Go_
|
| https://www.uber.com/blog/data-race-patterns-in-go/
| mkehrt wrote:
| > great error handling
|
| Go get this completely wrong! It use a tuple rather than
| an enum for potential errors. This means you can forget
| to check errors and just use the invalid (nil?) return
| value from the function.
|
| On the other hand, rust uses the Either enum to force you
| to handle the error. Alternatively you can use the ?
| operator to pass it to the calling function, which is
| reflected in the enclosing function's type.
| ikety wrote:
| Yep Rust approach won. Pretty much every new language is
| adopting Result style errors and it's been adapted to
| plenty of existing languages.
|
| It's a product of functional programming, and for me I
| can't see how you would ever want to handle errors
| outside of the functional programming railway-oriented
| style. For me it's just superior.
| tux3 wrote:
| >I think cargo is better than cmake
|
| That is an understatement. I can't think of a build system
| that has spawned more attempts to find something better than
| CMake has.
|
| There have been so many people trying to make their own C/C++
| build system and/or package manager out of sheer spite for
| CMake that it's frankly hard to keep track.
|
| In fairness to them and to CMake, it's not a simple problem
| to solve. To truly know CMake is to wish you didn't, that way
| someone else would have to maintain it.
| bluGill wrote:
| You seem to forget about autotools. Cmake is ugly but I'll
| take it over autotools.
| danudey wrote:
| As an end user: at least with autotools it's easy for me
| to see the available configuration options with
| ./configure --help in a nicely readable way. cmake has
| -LAH but it's still... kind of awful.
|
| At least it knows how to use ninja though.
| WhyNotHugo wrote:
| Cargo is absolutely awful. It might be better than cmake, but
| it still the worst part about Rust. It's completely opaque,
| and intermixes a huge pile of different functionality.
|
| Distributing Rust software is the pain that it is mostly
| because of how Cargo works. It's pretty much impossible to
| sanely distribute something that isn't a headache for
| downstream to consume.
| ModernMech wrote:
| I think you have to expand on your reasoning, because the
| opposite seems to be true when it comes to projects like
| uv. People love the single-file executable -- easy to just
| compile that for a platform and have your users download
| it. It seems like the uv project is having a good time with
| that model, so I think they show it's not "impossible".
| Maybe they're doing something different I'm not aware of?
| Or maybe your use case is different, so what's impossible
| about your situation?
| quantummagic wrote:
| Isn't it also the npm model?
| tick_tock_tick wrote:
| I mean we know for sure Rust is unsafe there is whole bug
| tracker dedicated to all the ways it's unsafe. My favorite is
| that you can cast any lifetime to static no matter how short it
| actually is in 100% safe Rust.
|
| (doesn't mean it's not an improvement on C++)
| ViewTrick1002 wrote:
| The unsound bug tracker is were my heart gets all warm and
| fuzzy in Rust land.
|
| All the ways to coerce and poke the implementation of what
| should be safe constructs to produce unexpected garbage - and
| people spending time fixing the issues because they are
| treated as bugs.
|
| It's like the best possible advertisement for "we enable
| soundness and correctness for all your programs."
|
| https://github.com/rust-
| lang/rust/issues?q=state%3Aopen%20la...
| j-krieger wrote:
| This doesn't 'cast' anything. The compiler prevents this
| because it would allow references that outlive their owners.
| Freely 'casting' only works for data that is static in nature
| anyways, at which point a coercion is taking place. Any other
| way involves `std::mem::transmute` or `Box::leak` and the
| like.
| tick_tock_tick wrote:
| Here is a nice segfault in perfectly legal safe Rust
| https://play.rust-
| lang.org/?version=stable&mode=debug&editio...
|
| I'd call it casting thought technically maybe it's not you
| might want to call it something else? You don't need
| transmute or leak. The issue is only 10 years old now
| https://github.com/rust-lang/rust/issues/25860
| dwattttt wrote:
| Yes, that's an existing soundness hole in the compiler.
| You won't accidentally code it up yourself though.
|
| If the bar is "deliberately malicious code results in a
| segfault", get back to me when they fix
| memcpy(0x10000, 0x20000, 0x10);
|
| EDIT: and even that's being charitable; the Rust issue is
| viewed as a compiler bug which should be fixed.
| krukah wrote:
| I think referencing the well-known cases in cve-rs[1] is
| quite a bad faith effort. Of course if you try reeeally hard
| to write unsound code, you can write unsound code. An edge
| case in the type system downstream of lifetime variance rules
| is simply not something that matters in any practical attempt
| to write safe software. I find the tracker interesting since
| it probes the boundary of the compiler, but it says absolute
| nothing to the effect of "Rust is unsafe".
|
| [1] https://github.com/Speykious/cve-rs
| ActorNightly wrote:
| Id like to see dev time in Rust vs C++, but generally, I sort
| of agree. If you use modern C++ with all its features, Rust is
| generally a better alternative.
|
| That being said, it would be pretty easy to implement some
| pointer semantics even in C that can do 95% of what Rust does.
| masklinn wrote:
| Most of these is confirmation of easily observable reality, but
| the 4x difference in rollback rates, jesus christ.
| anttiharju wrote:
| I found it interesting that the rollback rate remained more or
| less constant despite size differences.
| bla3 wrote:
| If they use Rust for new code and C++ changes are all in old
| code, this could be explained just by older code being more
| risky to change.
| nixpulvis wrote:
| Funny, another commenter on this post was saying the
| opposite, that Rust was likely being used to just port
| existing features and that was easier because there were
| probably good tests for it already.
|
| If you've actually written considerable amounts of Rust and
| C++, these statistics don't require justification. In my
| opinion it's completely expected that Rust code is easier to
| write correctly.
| kridsdale1 wrote:
| I'd say the same applies for Swift vs ObjC.
|
| Let's end the C era.
| girvo wrote:
| While the C calling convention continues to rule
| operating systems and FFIs, I think it'll continue to
| limp along. Hopefully one day that can be fixed, it's
| annoying that C is what I have to reach for to call
| SomeLib no matter what language I'm using
| manmal wrote:
| Apple should have modernized ObjC instead of making Swift
| the lingua franca. Both speed of iteration and
| flexibility (on which web-stack-rivaling productivity
| features would have been possible) are gone forever.
|
| Swift Concurrency is a tire fire that not even their
| async-algorithms team can use completely correctly, and
| useful feature like typed throws are left half finished.
| The enormous effort the constant further bastardization
| of Swift takes, is at least in part the reason for the
| sorry state dev tooling is in. Not even a 4T dollar
| company can make a reliable SwiftUI preview work, in
| their own IDE. Variadic generics (a seemingly pure
| compiler feature) crash at runtime if you look at them
| the wrong way. Actors, the big light tower of their
| structured concurrency, are unusable because calls to
| them are unordered. They enforce strict concurrency
| checking now, but the compiler is too dumb to infer
| common valid send patterns; and their solution to make
| this abomination work in real codebases? Intro a default
| that lets _everything_ in a module run on the main thread
| per default!
|
| </rant>
| ModernMech wrote:
| Swift has so many issues they would honestly be better
| off just moving to Rust rather than fix Swift. Seriously.
| The fact that it's so easy to get the compiler to spend
| exponential time resolving types that it very often just
| shits the bed and begs you to rewrite your code for it to
| stand a chance is shameful coming from, as you say, a $4T
| company. Points to deep problems with Swift.
| kridsdale1 wrote:
| I don't disagree with anything you said.
| danudey wrote:
| As a relatively novice programmer who's worked in tech for
| decades but not as a software developer: I take issue with
| the idea that you need to write considerable amounts of
| Rust and C++ for these statistics to be expected. In fact,
| despite Rust's initial vertical learning curve I'd say that
| any junior developer trying to implement anything with any
| degree of complexity at all in Rust and C++ would see the
| benefits.
|
| At the very least, the fact that IDE integration can tell
| you all kinds of stuff about what you're doing/doing wrong
| and why accelerates things greatly when you're starting
| out.
| nixpulvis wrote:
| Oh I totally agree with you.
|
| The logic in my comment wasn't that you need to have
| written considerably amounts of code to be expecting
| this, just that to not be expecting this would make me
| think you hadn't. If that makes sense.
|
| On your second point, I think IDE integration for C++ is
| similar as it is for Rust. Just Rust errors and tooling
| are a million times better regardless of IDE.
| nicoburns wrote:
| I think they're comparing new code in Rust vs new code in
| C++.
| MBCook wrote:
| We all knew rust was safer. It was the 1000x number that
| surprised me.
|
| Which is more that rust isn't _that safe_ in my mind, it's that
| bugs are _that prevalent_. I never would have guessed that.
|
| That 4x rate is very impressive too.
|
| Great seeing all this data from a large big complicated
| codebase.
| ActorNightly wrote:
| The issue with most codebases is nobody thinks about starting
| out with acceptance testing system.
|
| The way it should work is that before even writing code, you
| design a modular acceptance system that runs full suite of
| tests or a subset based on what you are working on.
|
| This is essentially your contract for software. And on a
| modular level, it means that it scopes down the contracts to
| the individual sub systems. And things like memory and cpu
| runtime constraints are a part of this.
|
| If you have this, you basically replace what the Rust compiler
| is doing for you with tests. Memory leaks are caught. However,
| as a benefit, you also can verify changes in the dev cycle with
| things like performance degradation, all in the same system.
| ikety wrote:
| I'm not sure that nobody thinks of this. We just have a
| finite amount of time. Usually with a solid approach, you get
| solid performance. Fixing a performance related bug rarely
| when it comes up, is still a time savings over designing this
| kind of rigorous process from scratch, and getting everyone
| on board with it.
|
| Getting rid of a whole host of bugs due to the compiler is a
| big deal because you won't have to design this extra
| acceptance system or deal with keeping an entire organization
| disciplined by it. If you can solve this seamlessly I think
| that's an interesting product that others would be very
| interested in.
| pjmlp wrote:
| Note that Google still doesn't have official support for using
| Rust in Android userspace, though.
|
| Despite all pluses on the blog, NDK only supports C and C++
| tooling, same on Android Studio, and it is up to the community to
| do the needful work, if anyone feels like using Rust instead.
| quotemstr wrote:
| Nobody's stopping you from using the NDK to compile Rust
| though. Android's ABI is just an ABI like any other. The system
| doesn't care if you built an .so using Rust or anything else so
| long as it plays by the rules.
| pjmlp wrote:
| Some people rather reach out for first party support, instead
| of filling in the gaps for the big boys.
| dwattttt wrote:
| By first party support, would you be expecting a Rust
| toolchain shipped in the NDK, or maybe Rust bindings
| shipped in the NDK?
|
| I could see the latter, although I'd still question whether
| they should be special cased in terms of a Rust dependency
| compared to bindings being hosted on crates.io.
|
| Or maybe they should ship scripts that shell out to an
| existing Rust toolchain.
| pjmlp wrote:
| I expect Rust being documented here,
|
| https://developer.android.com/ndk
|
| I expect the whole Rust build process being part of
| Android Studio, including mixed language debugging
| between Java, Kotlin and Rust.
|
| I expect all NDK APIs to have Rust bidding crates.
|
| I expect that Android developer forums also care to
| support devs using Rust.
|
| And anything else that I forgot to mentioned, that is
| provided for Java, Kotlin, C and C++.
| flohofwoe wrote:
| The Android NDK just barely supports C and C++ either,
| unless you're ok with 1990's tooling standards. The whole
| thing feels like it's maintained by two dudes locked in a
| Google basement somewhere. I doubt they have the capacity
| to deal with Rust support in the NDK, unless there's a
| big strategic change in Android tooling.
| eggy wrote:
| Don't forget this list of expectations for SPARK [1] too,
| if you want even safer, high-integrity, and formally
| verified code on Android!
|
| [1] https://www.adacore.com/about-spark
| iknowstuff wrote:
| I think we can indeed forget about it.
| petcat wrote:
| At this point I feel like it's no longer an uphill climb to get
| Rust into foundational, mission-critical code adoption. The
| benefits are so obvious. Maybe it's just a lingering religious
| war?
|
| In any case, I'm glad we're seeing more and more evidence and
| case-studies of why "rewrite it in Rust" isn't just a meme.
| vbarrielle wrote:
| But the approach here is "write new code in rust", not rewrite.
| gpm wrote:
| Eh, I don't think it's actually one or the other. Google has
| taken on rewriting some more problematic components in rust.
| See for example:
|
| Binder kernel driver: https://git.kernel.org/pub/scm/linux/ke
| rnel/git/torvalds/lin...
|
| Media codecs: https://www.androidauthority.com/android-16-in-
| process-softw...
| GeekyBear wrote:
| This is also happening at Microsoft:
|
| > Rewriting SymCrypt in Rust to modernize Microsoft's
| cryptographic library
|
| https://www.microsoft.com/en-us/research/blog/rewriting-
| symc...
| nicoburns wrote:
| Yeah, there's also a freetype replacement
| https://github.com/googlefonts/fontations
|
| I think they're trying to avoid rewriting things for no
| reason though. The things being rewritten tend to have a
| history of security problems or other issues that would be
| cause for a rewrite even if it wasn't in Rust.
| VWWHFSfQ wrote:
| Sure, but at a macro level the approach is still to "rewrite"
| Android subsystems in Rust. Just slowly.
| wiseowise wrote:
| Google rewrote Android's Bluetooth stack in Rust.
| robocat wrote:
| Also mentioned: Chromium: Parsers for PNG,
| JSON, and web fonts have been replaced with memory-safe
| implementations in Rust
| danudey wrote:
| Go look at the comments on any Phoronix article involving Rust
| in any way and you'll see that it's 80% rust haters making all
| the same arguments every Rust hater makes. You can implement
| the same safety features in C++ and assembly if you know what
| you're doing! You can still write bugs in Rust! I know someone
| who tried to learn rust and he accidentally deleted his home
| directory so everyone may as well stick to C!
|
| It's all nonsense, but it would be hilarious if it weren't so
| ignorant.
| ActorNightly wrote:
| >It's all nonsense,
|
| How is any of that wrong?
| ActorNightly wrote:
| Rust makes sense in the case of Android, where the kernel and
| software is rolled by Google. In the same way that Java made
| sense for a lot of the backend services in 2010s despite its
| drawbacks before Node and Python got major improvements in
| speed and compute became cheaper.
|
| That however is a very niche case where Rust is applicable. The
| anti-rust people (like me) aren't saying that Rust is bad. We
| are just arguing against its adoption for everything.
|
| When you see shit like "[...] should be rewritten in Rust
| because memory safe", it shows that people have no idea what
| memory safety even is. There is this dumb belief stemming from
| lack of proper CS education that any code you write can just
| randomly have memory safety issues.
|
| The downsides of Rust is that its ownership semantics are often
| cumbersome to write, which slows down development. Rust is also
| still evolving because of the stuff that happens under the
| hood. And for a lot of things, where network latency is
| dominant and cpu cycles are spent sleeping waiting for
| responses to come back, you don't need natively compiled code
| in lieu of python or node that are way more flexible and faster
| to develop in.
|
| So in most cases, Rust is not applicable, when you can write
| perfectly memory safe code faster.
| iknowstuff wrote:
| > There is this dumb belief stemming from lack of proper CS
| education that any code you write can just randomly have
| memory safety issues.
|
| lol. this take is hilarious in the face of the article you
| are commenting on. holy cognitive dissonance.
|
| > The downsides of Rust is that its ownership semantics are
| often cumbersome to write
|
| skill issue
| pizlonator wrote:
| This isn't control for confounding factors.
|
| For example: folks are more likely to rewrite stuff that is well-
| understood, and stuff that is well-understood is going to have
| shorter review times and lower rollback rate.
|
| That gnarly horrid mess that only a few greybeards grok and has
| massive test coverage, a long tail of requirements enforced by
| tests and experience, and a culture of extreme rigor? Longer
| reviews, more rollbacks, and less likely to be rewritten.
| littlestymaar wrote:
| > That gnarly horrid mess that only a few greybeards grok and
| has massive test coverage, a long tail of requirements enforced
| by tests and experience, and a culture of extreme rigor? Longer
| reviews, more rollbacks, and less likely to be rewritten.
|
| I'd say that this is likely the _most_ likely to be rewritten
| actually, because high test coverage is a massive enabler in
| such a rewrite, and because having a project that "only a few
| greybeards grok" sounds like a big organizational liability.
|
| That being said, and while I'm pretty convinced that Rust bring
| massive benefits, I agree with you that these measurements
| shouldn't be taken as if it was a rigorous scientific proof.
| It's more of one additional anecdotal evidence that Rust is
| good.
| pizlonator wrote:
| > It's more of one additional anecdotal evidence that Rust is
| good.
|
| But that means it's likely to be the worst kind of science:
|
| - Group of people agree that Rust is good. This is a belief
| they hold.
|
| - Same group of people feel the need to search for argument
| that their belief is good.
|
| - The group does "science" like this.
|
| And then the rest of us have a data point that we think we
| can trust, when in reality, it's just cherry picked data
| being used to convey an opinion.
| dwattttt wrote:
| > And then the rest of us have a data point that we think
| we can trust, when in reality, it's just cherry picked data
| being used to convey an opinion.
|
| Calling what Google did here "science" and cherry picked is
| quite a disservice. It's observational data, but do you
| have any objection to the methodology they used? Or just
| (assumed?) bad vibes?
| pizlonator wrote:
| In science, you go out of your way to control for
| confounding factors.
|
| This isn't that.
| gpm wrote:
| > In science, you go out of your way to control for
| confounding factors.
|
| There's tons of observational science done in a very
| similar fashion to the article where there is simply no
| way to control for confounding factors for the same
| reason that there is simply no way to properly control
| for it in the data available.
| dwattttt wrote:
| Having been close to someone who went through the PhD
| process to a career in research, this is a sadly common
| but romantic and incorrect view of science as practiced
| in the world today.
| gf000 wrote:
| Going out of your way would involve committing unethical
| experiments, which is absolutely frowned upon by
| scientists.
|
| And many experiments are simply impossible to do in a
| manner that completely removed every outside factors. But
| that doesn't mean that an experiment's results are
| immediately bad.
| gpm wrote:
| The first chart does in fact a compelling reason to believe the
| effect is not that at all. If the "easy" code was predominantly
| being rewritten you would expect to % new memory unsafe code
| and % memory safety vulnerabilities to scale at different rates
| as the difficult to work on areas remained in C and kept
| causing new memory vulnerabilities.
|
| Personal experience also provides a compelling reason, my
| experience is absolutely that people are more inclined to
| rewrite the things that are causing trouble in a new language.
|
| It's not a blinded randomly controlled trial of course, it's
| observational data. You can't be completely sure there isn't a
| confounding factor that explains the data, but it seems far
| more likely than not that it is a real effect.
| pizlonator wrote:
| I would expect memory safety vulns to be dropping in most
| C/C++ projects due to better practices
| j-krieger wrote:
| You would be severely disappointed.
| Ar-Curunir wrote:
| This contradicts what Google has reported about their own
| code, which is that most vulnerabilities are in new code
| pizlonator wrote:
| I don't see a contradiction between the statement that
| vulns in C++ code are generally on a downward trajectory,
| and the statement that most vulns are in new code.
| j-krieger wrote:
| This article is mostly about new code.
| schuyler2d wrote:
| That is somewhat mitigated by grouping comparisons of S/M/L
| change sizes.
|
| It _would_ be interesting to group changes by line-deletions,
| say to indicate rewrites (and size of them)
| littlestymaar wrote:
| > Chromium: Parsers for PNG, JSON, and web fonts have been
| replaced with memory-safe implementations in Rust, making it
| easier for Chromium engineers to deal with data from the web
|
| I find this surprising, isn't Wuffs[1] (also made by Google) an
| even better fit for this particular use-case? (It has compile-
| time _spatial_ memory safety, where Rust has compile-time
| temporal safety but runtime spatial safety, with bound checking).
|
| Obviously for general-purpose system programming, Rust is a no-
| brainer and I'm happy to see Google pursuing their rustification
| of Android.
|
| [1]: https://github.com/google/wuffs
| gpm wrote:
| I don't find it surprising, just from barriers to adoption:
| "Wuffs programs take longer for a programmer to write, as they
| have to explicitly annotate their programs with proofs of
| safety" is a hard sell (even if it has obvious value) and "you
| have to learn and integrate yet another language just for
| parsing files" is a hard sell too.
|
| Which isn't to say that it shouldn't be adopted (having not
| used it I really don't know), just that it's not surprising
| that it's having difficulty gaining traction.
| nicoburns wrote:
| If you're parsing untrusted data, then some level of runtime
| checking is unavoidable. And Rust's pretty good at letting you
| encode "I already checked this and therefore don't need to
| check it again" into the type system.
| meisel wrote:
| The graphs aren't showing up for me on the site unless I click on
| them
| tracker1 wrote:
| Don't let Lunduke Journal see this post, he might have an
| annurism.
| delusional wrote:
| I don't understand the graphs presented here. On the first graph
| showing "New Memory Unsafe Code" and "Memory safety Vulns" we
| don't have any steady state. The amount of both "unsafe code" and
| "memory safety vulns" had apparently already been dropping before
| 2019. None the matter though, we see a great big drop at 2022 in
| both.
|
| Then in the next graph, showing "Rust" and "C++", we see that the
| amount of C++ code written in 2022 actually increased, with rust
| not really having gained any significant momentum.
|
| How can one possibly square those two pieces of data to point at
| rust somehow fixing the "memory safety vulns"? Somehow an
| increase in C++ code led to a decrease in the amount of both "New
| Memory Unsafe Code" and "Memory safety Vulns".
|
| Also "this approach isn't just fixing things, but helping us move
| faster." is an AI red flag.
| gpm wrote:
| > How can one possibly square those two pieces of data to point
| at rust somehow fixing the "memory safety vulns"? Somehow an
| increase in C++ code led to a decrease in the amount of both
| "New Memory Unsafe Code" and "Memory safety Vulns".
|
| The first graph considers <memory unsafe> vs <memory safe>
| languages, while the second graph considers C++ vs Rust.
| There's more languages than just those two in the first graph.
|
| Moreover the first graph is in percentage terms, while the
| second graph is in absolute terms.
|
| In 2022 it appears a bunch of memory safe non-rust code was
| added. Java/python/...
|
| > Also "this approach isn't just fixing things, but helping us
| move faster." is an AI red flag.
|
| That's a perfectly human phrasing lol.
| tcfhgj wrote:
| > How can one possibly square those two pieces of data to point
| at rust somehow fixing the "memory safety vulns"?
|
| The code base contains Kotlin and Java as well
| stocksinsmocks wrote:
| I'm a little perplexed why every time something in rust
| compiles, there's a blog post about it. I was under the
| impression Ada, especially when using provers, has been around
| much longer and is more robust. I just can't decide if the
| massive Rust evangelism budget is a red flag or just a curious
| sociological case study, but I wish I knew the truth.
| mycocola wrote:
| I use rust for gamedev (not bevy). I'm unlikely to consider
| anything else exactly because of stability and throughput.
| habibur wrote:
| 5 million Rust LOC One potential memory safety
| vulnerability found Rust is 0.2 vuln per 1 MLOC.
| Compared to C and C++ : 1,000 memory safety
| vulnerabilities per MLOC.
|
| Key take.
| petcat wrote:
| Rust is truly a marvel of engineering. A breakthrough. Such a
| thing is so very rare in computer science.
| Cyph0n wrote:
| Absolutely crazy.. I never expected that the difference would
| be so drastic.
| belval wrote:
| Isn't that a lot though, that means 1 memory safety
| vulnerability per 1000 lines of code, that seems hard to
| believe.
| darknavi wrote:
| It's not _that_ hard to believe if you start spraying smart
| pointers everywhere.
| pityJuke wrote:
| There are certain places of the internet where any mention of
| rewriting in Rust is met with scorn and ire. And while, like
| any technical decision, there are pros and cons, I cannot see
| why in the face of astounding evidence like this, you would
| completely dismiss it.
|
| And I say this as someone who has never written a line of Rust
| in their life (some day I'll find the time).
| ModernMech wrote:
| The thing about Rust is you pay for everything up front, and the
| dividends come later. You pay first to learn it, which is not
| easy. Then you pay every time you have to compile your code,
| which can kill development momentum. When you are learning, often
| times this manifests as a moment where you have to completely
| rearchitect your approach because plowing forward is too costly.
| It's at this point a lot of people say "Rust is too hard!" and
| they give up.
|
| But if you stick it out, as Google has, the dividend is that more
| often than with other languages, you are not paying these costs
| continually but instead reaping dividends on the long run.
|
| First of all, Rust has the Haskell-like property that (as long as
| the logic is sound) if your code compiles, it usually runs just
| fine. This is why testing speeds up, because all of the edge
| cases that are explored during testing were already accounted for
| by the compiler.
|
| It also translates into easier refactoring, where you can make
| sweeping changes in the codebase and feel confident that you can
| put it all back together again.
|
| And then there's the fact that the programs themselves are
| _fast_. How many times has uv been brought up here and the #1
| remark people have is "wow it's so fast!". Fast is a feature,
| and your users benefit from it every time they run your code.
|
| It's hard to find that nexus of features in other languages.
| Usually they are just as fast and hard to write as Rust, without
| the safety guarantees. Or they are just as safe as Rust, but
| without the speed. And that's why Rust has hit a sweet spot where
| other languages can't quite get it.
| vatsachak wrote:
| Yeah, I use Rust at work and it's a boon.
|
| It's so easy to bake in proofs/invariants into types, yet you
| still retain control of the memory model.
|
| One of the main features of Rust is the community, there are so
| many great packages
|
| Something that will replace/build on Rust in the future is a
| language based on Two Level Type theory, where you have zero
| cost abstractions with a language that can do full dependent
| type theory
| ModernMech wrote:
| I'm glad you said that because that's exactly where my
| research is ^_^
| vatsachak wrote:
| https://andraskovacs.github.io/pdfs/2ltt_icfp24.pdf
|
| I think that something like this is the endgame practical
| programming language
| duped wrote:
| I think Rust is easier to learn than C++
| ModernMech wrote:
| I agree with you as long as you don't know C++ first. I
| actually teach C++ and Rust to students who only know Java,
| and they have a _much_ easier time picking up Rust. It 's the
| people who approach Rust with C++ idioms who have the wort
| time with it. It comes down to the tooling, especially Cargo
| being the one-stop-shop for everything Rust. Another poster
| here laments that Cargo is too overloaded with disjoint
| functionality, but that's actually a benefit for a lot of
| learners.
| iagooar wrote:
| Rust has been such a "pain" to learn - at least compared to
| other, more straight-forward languages. But boy does it feel good
| when you know that after a few back and forths with the compiler,
| the code compiles and you know, there is not much that is going
| to go wrong anymore.
|
| Of course, I am exaggerating a bit - and I am not even that
| experienced with Rust and I know, you can build semantically
| broken Rust and no compiler safety line is going to save you.
|
| But after coding with Ruby, JS/TS and Python - it feels
| refreshing to know that as long as your code compiles, it
| probably is 80-90% there.
|
| And it is fast, too.
| imron wrote:
| That's my favorite feature. Rust turns runtime errors into
| compile time errors.
|
| All that fighting with the compiler is just fixing runtime bugs
| you didn't realize were there.
| ikety wrote:
| I'm interested in what scenarios you don't get this same
| feeling when writing TS code? I of course agree with Ruby, JS,
| and Python.
| regular_trash wrote:
| Not parent comment, but TS is generally safe if you have
| types correct at system borders, but very scary when you
| don't. Some of the most impactful bugs I've seen are because
| a type for an HTTP call did not match the structure of real
| data.
|
| Also, many built in functions do not have sufficient
| typesafey like Object.entries() for instance
| vjerancrnjak wrote:
| The worst offender is toString which has different types
| between objects and is everywhere by default.
| josephg wrote:
| One big source of bugs in TS is structural sharing. Like,
| imagine you have some complex object that needs to be
| accessed from multiple places. The obvious, high performance
| way to share that object is to just pass it around and keep a
| reference to it wherever you need it. But this is dangerous.
| It's easy to later forget that the object is shared, and
| mutate it in one place without considering the implications
| for other parts of your code.
|
| I've made this mistake in TS more times than I'd like to
| admit. It gives rise to some bugs that are very tricky to
| track down. The obvious ways to avoid this bug are by making
| everything deeply immutable. Or by cloning instead of
| sharing. Both of these options aren't well supported by the
| language. And they can both be very expensive from a
| performance pov. I don't want to pay that cost when it's not
| necessary.
|
| Typescript is pretty good. But it's very normal for a TS
| program to type check but still contain bugs. In my
| experience, far fewer bugs slip past the rust compiler.
___________________________________________________________________
(page generated 2025-11-13 23:00 UTC)