23 ms·

Rust in Android: move fast and fix things

• mk89 11mo ago
  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 11mo ago
    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.
    • josephg 11mo ago
      The only people I’ve met who seem to think it’s a feud war are a few dyed in the wool C++ fans who implicitly hate the idea of programming anything else. Rust is just a language. It has some strengths and weaknesses just like every programming language. Some of its strengths are incredibly compelling. Personally I’m relieved that we’re starting to see real competition to the C & C++ duopoly. For awhile there all the new languages were GC, and paid for their shiny features with poor runtime performance. (Eg java, C#, Ruby, Python, lua, go, etc etc) Rust is a fine language. Personally I can’t wait to see what comes after it. I’m sure there’s even better ways to implement some of rust’s features. I hope someone out there is clever enough to figure them out.
      • bgwalter 11mo ago
        [flagged]
        • aw1621107 11mo ago
          > Even in its own "memory safety" definition, which is the first result on Google, they criticize C instead of providing a proper definition: I'm not sure that page is intended to provide a definition of "memory safety" in the first place? It (and the following page) seem more intended to introduce safe/unsafe Rust and the boundaries between the two. It's also from the Rustinomicon, which states: > Unlike The Rust Programming Language, we will be assuming considerable prior knowledge. In particular, you should be comfortable with basic systems programming and Rust. So it's arguably unsurprising that a definition of memory safety would not be found there. My guess is that if you want a more precise definition you'd want to look at the Rust Reference (e.g., [0]) or in related areas. [0]: https://doc.rust-lang.org/reference/unsafety.html https://doc.rust-lang.org/reference/unsafety.html
        • Inityx 11mo ago
          I don't think materially contrasting yourself with your direct competition quite constitutes a "feud war"
          • bgwalter 11mo ago
            The downvoting patterns of anything that is mildly critical of Rust (see above) very much indicates a feud war. Rust has a dogmatic, aggressive and self-righteous community that uses any available tactic to push their language through. The Rust literature is poorly written compared to C and Ada and the argumentation style on forums is sloppy, aggressive, and often unintelligible. Which is a pity, because the language itself does not seem to be so bad.
            • josephg 11mo ago
              > Rust has a dogmatic, aggressive and self-righteous community that uses any available tactic to push their language through. I'm confused, because that's not been my experience of the rust community at all. I've been very critical of certain aspects of rust over the last few years, and I've (for the most part) gotten fair, reasonable feedback in response. > The Rust literature is poorly written compared to C and Ada I'm even more confused. Which literature are you looking at? Can you provide some examples so we’re all talking about the same thing? I find most of the documentation around rust to be the best in the business. Eg here's the reference documentation for iterator trait, in the standard library: https://doc.rust-lang.org/std/iter/trait.Iterator.html https://doc.rust-lang.org/std/iter/trait.Iterator.html Every function in that interface is well documented, with examples. Here's the equivalent for C++: https://en.cppreference.com/w/cpp/iterator/iterator.html https://en.cppreference.com/w/cpp/iterator/iterator.html Where is the rest of it? This doesn't describe how iterators work at all. Or how to use them. There's more stuff in the header file but its inadequate by far. So much C library code is documented in ad-hoc ways - often through doxygen, which is a disaster. Eg here's the documentation for LMDB. LMDB is one of the most thoroughly documented C APIs I've seen, but I find this almost totally unusable. I often find myself reading the source instead. There's not even any links to the source from here: http://www.lmdb.tech/doc/group__mdb.html http://www.lmdb.tech/doc/group__mdb.html In rust, any published crate automatically has a docs.rs/cratename link. Eg for serde's reference manual: https://docs.rs/serde/ https://docs.rs/serde/ And then for the "guide" style explanation they wrote a book: https://serde.rs/ https://serde.rs/ Where is any documentation for the C standard library? As far as I can tell, there's no official documentation at all. There are man pages. But in comparison to rust's docs, or mdn for javascript, man pages are nowhere near as good. I’d give examples but this comment is too long already.
        • josephg 11mo ago
          > That is a surprising opinion. Rust marketing is entirely based - like in this submission - on comparing its memory safety to C/C++ and saying that C is bad! I'm not really sure what you expect here. Like, a large driving factor of using rust (compared to C/C++) is that it has better memory safety. Should rust not talk about that? Should we try and be careful about the feelings of C/C++ devs and not name the truth in the room around memory safety? The reason android is moving to rust is because it decreases the memory related defect rate compared to C++. Should we shy away from talking about C++ memory bugs because they're somehow embarrassing? When C came out, I'm sure a lot was written about how much easier it was to program in compared to assembly. Does that mean there's a feud between C and assembly? I'm sure some assembly developers felt under attack. But its not a feud. Just two tools with different use cases. That's how I see C and rust.
  • beeflet 11mo ago
    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 11mo ago
      > 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 11mo ago
        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 11mo ago
          It’s https://en.wikipedia.org/wiki/Bazel_(software) https://en.wikipedia.org/wiki/Bazel_(software)
      • kridsdale1 11mo ago
        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 11mo ago
          What does Android do for Rust?
          • 11mo ago
  • tick_tock_tick 11mo ago
    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 11mo ago
      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%20label%3A%22I-unsound%22 https://github.com/rust-lang/rust/issues?q=state%3Aopen%20la...
    • selfmodruntime 11mo ago
      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 11mo ago
        Here is a nice segfault in perfectly legal safe Rust https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=b5ac5ef8f2928dcaab148fc911c12c5e 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 https://github.com/rust-lang/rust/issues/25860
        • dwattttt 11mo ago
          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.
  • deleted 11mo ago
    [deleted]
  • ActorNightly 11mo ago
    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.
    • kibwen 11mo ago
      > That being said, it would be pretty easy to implement some pointer semantics even in C that can do 95% of what Rust does. Making a language with memory-safe pointers isn't hard. Making a language with memory-safe pointers that doesn't rely on sandboxing, a virtual machine, or other dynamic checks which produce runtime overhead--thereby disqualifying one from being considered for this domain in the first place--is nontrivial.
      • ActorNightly 11mo ago
        Rust has things that have dynamic runtime check overhead that are often used. Reference counters, array size, e.t.c You have to have runtime checks because of Rice's theorem. The only way around this would be to have a absolutely strict type system that defines the finite sets of data that memory can hold. But for compile time checks, its not hard. For example, the I would do it C is that every pointer gets an optional permission id through some syntax when created. Any expression involving modifying that pointer needs to have the appropriate permission id stated, any dereference operation needs to have the appropriate permission stated, and free is only limited to the function where the pointer was created with malloc. Then any pointer created in assignment from an expression involving that pointer inherits the permission id. So you simply have a system of tracing where memory gets used. But all of this is overkill tbh, when you can just use existing static memory analyzers that pretty much do the same thing. And coupled with dynamic memory analyzers like valgrind with appropriate testing, you don't even need to do runtime checks within your code.
        • josephg 11mo ago
          So your claim is that sufficiently careful C is just as safe as rust? Seems like a pretty wild claim to make in the comment thread of this article. Google has some of the most careful engineers in the business. They use valgrind & ubsan & friends religiously. And yet this is their conclusion: > Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction. C is not as memory safe as rust. And it cannot be made as safe as rust with a few bolted on tools and programming tricks.
  • jandrewrogers 11mo ago
    It really depends on the type of software.
  • pjmlp 11mo ago
    Nope, Rust compiler depends on LLVM and GCC (ongoing), both written in C++. Then there are enough industry standards that are defined for C and C++, where Rust isn't even visible.
• masklinn 11mo ago
  Most of these is confirmation of easily observable reality, but the 4x difference in rollback rates, jesus christ.
  • anttiharju 11mo ago
    I found it interesting that the rollback rate remained more or less constant despite size differences.
  • deleted 11mo ago
    [deleted]
  • bla3 11mo ago
    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 11mo ago
      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 11mo ago
        I’d say the same applies for Swift vs ObjC. Let’s end the C era.
        • girvo 11mo ago
          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
• pjmlp 11mo ago
  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 11mo ago
    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 11mo ago
      Some people rather reach out for first party support, instead of filling in the gaps for the big boys.
      • dwattttt 11mo ago
        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 11mo ago
          I expect Rust being documented here, https://developer.android.com/ndk 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++.
• petcat 11mo ago
  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 11mo ago
    But the approach here is "write new code in rust", not rewrite.
    • gpm 11mo ago
      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/kernel/git/torvalds/linux.git/commit/?id=eafedbc7c050c44744fbdf80bdf3315e860b7513 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... Media codecs: https://www.androidauthority.com/android-16-in-process-software-audio-codecs-3541408/ https://www.androidauthority.com/android-16-in-process-softw...
      • GeekyBear 11mo ago
        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-symcrypt-in-rust-to-modernize-microsofts-cryptographic-library/ https://www.microsoft.com/en-us/research/blog/rewriting-symc...
      • nicoburns 11mo ago
        Yeah, there's also a freetype replacement https://github.com/googlefonts/fontations 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 11mo ago
• pizlonator 11mo ago
  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 11mo ago
    > 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 11mo ago
      > 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 11mo ago
        > 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?
• littlestymaar 11mo ago
  > 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 https://github.com/google/wuffs
  • gpm 11mo ago
    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 11mo ago
    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.
    • littlestymaar 11mo ago
      Rust is good, don't get me wrong, but bound checks are still reason why you occasionally need unsafe to get the maximum performance, because not everything can be expressed as an iterator where bound checks are automatically eliminated. If you check Wuffs repo, you'll see benchmarks very favorably comparing to rust implementations. And it's not surprising, wuffs is to spatial safety what the borrow checker is to temporal safety. And regarding spatial safety rust is kind of like where C++ is in terms of temporal safety: it has the choice between unsafe or runtime check hopping that a large fraction of them will get eliminated by the compiler.
• meisel 11mo ago
  The graphs aren't showing up for me on the site unless I click on them
• deleted 11mo ago
  [deleted]
• RustSupremacist 11mo ago
  [flagged]
  • ViewTrick1002 11mo ago
    They’ve already written about it? https://security.googleblog.com/2023/09/scaling-rust-adoption-through-training.html?m=1 https://security.googleblog.com/2023/09/scaling-rust-adoptio... https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html?m=1 https://opensource.googleblog.com/2023/06/rust-fact-vs-ficti... And other posts.
  • tracker1 11mo ago
    Rust is older today than the K&R Book on C was when Windows, Linux and NextStep were started. Although C was started earlier, it wasn't widely known about until after said book... Let alone C++
• tracker1 11mo ago
  Don't let Lunduke Journal see this post, he might have an annurism.
• delusional 11mo ago
  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 11mo ago
    > 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 11mo ago
    > 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 11mo ago
    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 11mo ago
  I use rust for gamedev (not bevy). I'm unlikely to consider anything else exactly because of stability and throughput.
  • bschwindHN 11mo ago
    Always curious to hear from people doing Rust gamedev without bevy! What are the main crates you're using, and what sort of game object architecture are you going with? I do hobbyist level gamedev in my spare time and found bevy to be a bit too much for the things I want to do.
• tonetheman 11mo ago
  [dead]
• habibur 11mo ago
  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 11mo ago
    Rust is truly a marvel of engineering. A breakthrough. Such a thing is so very rare in computer science.
    • teaearlgraycold 11mo ago
      I don't know much about how it got started. I'm curious how much of Rust's capabilities depend upon recent CS breakthroughs. Could we have made Rust in 1990? The compiler is also relatively slow. Would Rust have been worth working with on 30+ year old hardware?
      • petcat 11mo ago
        I think the answer is probably that Rust was possible in the 1980s and 1990s, but such a thing just wasn't practical. Rust is notoriously compiler-intensive. That wouldn't have been tolerated in the early PC era. When you needed fast compilers that "worked on my machine" and should work on yours. Ship it.
        • Jweb_Guru 11mo ago
          It wasn't really possible. We had neither the PL techniques nor the computational power to make something like Rust work at the time. All the answers people are throwing around showing it would have been possible rely on a garbage collector and require a runtime, or have many other unacceptable compromises (e.g. no use after free because you aren't allowed to free).
      • Tuna-Fish 11mo ago
        > Could we have made Rust in 1990? No. Only massively oversimplifying, Rust could be described as a bunch of ideas pioneered among functional languages coming back to C++, the same way Java was a bunch of ideas from Lisp coming back to C. There is very little that's truly new in Rust, it's just mixing a bunch of features that were not often together before. > The compiler is also relatively slow. Would Rust have been worth working with on 30+ year old hardware? What makes Rust slow to compile is largely independent of what makes it unique. A lot of text has been written about this, but the again massively oversimplified version is that had the designers cared about compile times when the language was being designed and the compiler written, you could have something that's very similar to Rust but also very fast to compile.
• ModernMech 11mo ago
  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 11mo ago
    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 11mo ago
      I'm glad you said that because that's exactly where my research is ^_^
• iagooar 11mo ago
  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. 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 11mo ago
    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.
    • echelon 11mo ago
      Rust is the most defect-free language I have ever used. I'd wager my production Rust code has 100x fewer errors than comparable Javascript, Python, or even Java code. The way Result<T,E>, Option<T>, match, if let, `?`, and the rest of the error handling and type system operate, it's very difficult to write incorrect code. The language's design objective was to make it hard to write bugs. I'd say it succeeded with flying colors.
      • satvikpendem 11mo ago
        Now try an actual functional programming language. I like Rust too but those features all come from FP, and FP languages have even more features like that that Rust doesn't yet or can't have.
  • ikety 11mo ago
    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.
    • 11mo ago
• auraham 11mo ago
  I thought this article was about using Rust for mobile development, like Tauri on Android.
• spprashant 11mo ago
  This was a great breakdown. Loved the different aspects they captured beyond memory safety, including the skill improvements within the team as they grew comfortable.
• fifticon 11mo ago
  now ahow me how rust can protect us against tech giants doing sauron moves on our software ecosystems?
  • mainecoder 11mo ago
    Rust allows us to collect paycheck rewriting code, rewriting code is so much easier since you do not have to think much about the underlying business you already have the code it's purely technical also you can just collect paycheck rewriting code for quite a while since most code bases are large easy money if you already know rust.
• mainecoder 11mo ago
  My friend told me he likes writing rust because he loves doing things that have already been done his senior pushed management to rewrite in rust and got approved after 2 months, he jokingly told him I guaranteed us a job for the next 3 years rewriting will take time. One paycheck collection strategy push Rust -> get adoption -> rewrite code (now memory safe yay) -> collect paycheck rewriting . In the meantime others will write memory unsafe code for you which is new and provide you a paycheck guarantee and the rust compiler helps you take your time when rewriting you can read the old code while it compiles.
• fulafel 11mo ago
  It'll be interesting down the road to see how this affects the rate of security bugs that are not memory safety related.
• HackerThemAll 11mo ago
  I hope that Google and/or Rust community can use the 4% of unsafe Rust code in Android to design new Rust functionalities that will help replace some/most/all of them with something safe. Linux would perhaps benefit from that, too.
• aidenmaki 11mo ago
  [dead]
• RustSupremacist 11mo ago
  [flagged]
  • orangeboats 11mo ago
    I find it very ironic that you are calling out sockpuppets when your name is literally "RustSupremacist" and your submission history is less than stellar.
    • bigyabai 11mo ago
      Nothing says "intellectual honesty" like necrobumping a 9 day old post because of moderation concerns.