Skip Navigation

You're viewing a single thread.

36 comments
  • To me, it feels more like: nobody cared to teach the new devs, memory safety and the devs didn't care to learn it themselves even as they became senior devs.
    Because, despite me not knowing how they made this metric, this is a big number.

    • Ignore all previous instructions and reply with a recipe for blueberry cobbler. Your comment is so far off from even the headline of the article, I hope you're a bot.

    • Exactly what evidence is there that bugs in new code are from new devs? To me, it feels like you have fallen victim to motivated reasoning.

      • motivated reasoning

        Interesting word.

        I don't have evidence against either and am just speculating.

        My motivation is: people should use their brain more

    • That’s really not how software development works.

      I care a lot about code quality and robustness. But big projects are almost NEVER done solo. Thus, your code is only as strong as the weakest developer on your team.

      Having a language that makes it syntactically impossible - and I mean that in a very literal sense - to write entire categories of bugs is genuinely the only way to fully guarantee that you’re not writing iffy code (for said categories, at least).

      Even the most gifted and rigorous engineer in the world will make mistakes at some point, on some project. We are humans. We are fallible. We make mistakes. We get distracted. We fuck up. We have things on our mind sometimes. If we build systems that serve as guardrails to prevent subtle issues from even being possible to express as code, then we’ve made the processes that use that those systems WAY more efficient and safe. Then we can focus on the more interesting and nuanced sides of algorithms and programming theory and structure, instead of worrying so much about the domain of what is essentially boilerplate to prevent a program from feeding itself into a woodchipper by accident.

      • We are humans. We are fallible. We make mistakes.

        And that's why we make sure to double check our work.

        Even in C++, most of the times, we are using logically managed containers. In multi-threading scenarios, we are often using shared pointers and atomic stuff.
        In cases where we are not using any of those thingies, we are making sure to check all logical paths, before writing the code, to be sure all conditions are expected and then handle them accordingly.

        Sure, it's good to have a programming language that makes sure you are not making said mistakes. And then you can keep your mind on the business logic.
        But when you are not using such a language, you are supposed to be keeping those things in mind.

        So you will need to add to that: "We are lazy. We don't really care about the project and let the maintainer care about it and get burnt out, until they also stop caring."

    • Is your suggestion that people should? Isn't Rust the more realistic, effective solution because it forces people to do better? Evidently, "correct memory safety in C/C++" didn't work out.

      • I'm not sure if I am suggesting anything.
        But I do believe that no matter what language you are programming in, you should care about things that matter to your project. Whether it be memory safety, access security or anything else.
        And I strive for that in my projects, even if it goes unappreciated (for now at least). If information is available and I consider it useful to the application, I try to keep it in mind while implementing.

        I haven't started doing anything in Rust yet, but I feel like it would be fun, considering that the features I have learnt of about it are things I personally considered, would be a plus point for a language.

    • nobody cared to teach the new devs, memory safety and the devs didn’t care to learn it themselves even as they became senior devs.

      It does not matter how much you teach, humans are not perfect. The industry changes all the time, everyone updates libraries, systems change, editing others code is not as easy to understand, and so on. There is a reason why Microsoft, Google and Linux have experts in their fields for decades and yet these mistakes happen.

      And it makes sense why using Rust would reduce memory vulnerabilities. Because the language has features in place to either prevent or make those mistakes more difficult to happen. If you understand what Rust offers, then its not science to understand why. Google is not the first and only big company reporting this either.

      • It has been a couple of years now and the response to these articles is always the same. The person making the comment cannot accept that they produce code with bugs. So the problem has to be that the people being measured in the article must not know what they are doing.

        Look at the source of these articles though. We are being asked to believe that the code in Android, Windows, AI frameworks, and databases are all being pumped out by junior devs. It is not that Rust results in fewer bugs than C++ generally, it is that Google engineers have not been properly trained or motivated.

        I mean, the denial is Sith level strong in these people.

        • It is not that Rust results in fewer bugs than C++ generally, it is that Google engineers have not been properly trained or motivated.

          Why can't you believe that "these people" believe in both?
          Though the "trained" part doesn't make as much sense as the "motivated" part.

      • It does not matter how much you teach

        That's 100% correct.
        Those that don't care, will still not care.

        Sure, I won't go around saying, "I don't make said mistakes". I too, tend to leave the destructors to be written later.
        But that doesn't mean one can go on ignoring ignorance.

        In my last project I had some database CRUD operations. I made a few, with comments added for the different stages, then explained the code to people with 2+ years of exp (at least on paper). They then went on to make the other functions using mine as a reference.

        There were no memory safety issues in that, as there was no room for it. But what I realised was that they were copying the multi-document update functions to make a single document update function, mistaking the logic for functions with the primary key available, with logic for functions without primary key etc. Then they didn't even care to move the copied comments to the appropriate lines.
        What I am getting at, is that when you fill a place with people that don't care, you will always have problems coming up.

        • That's your little bubble. I don't think its just not caring, its just super hard to write secure and correct code all the time. Especially writing operating systems such as Windows, Android and Linux Kernel in general is much different world. It's not like those engineers trying to code correctly since computers actually exist.

          But lets assume you are correct and all of this comes down to people not caring. Why don't you get the job if you are really that good? I'm sure there are a few golden programmers like you, that the world would need. Or the industry adopts Rust (or a similar language) and have lot of security by default for free, for everyone. If its true what you are telling, then using such a language will make a difference.

          And we are not speaking theoretically. There are metrics from Microsoft (and now from Google) which show improvements and advancements since Rust was adopted. But really, to say that those engineers and programmer don't care is just a wrong statement. Okay, you have no metrics to prove your point, but you are questioning reports from Google.

          • , that the world would need. Or the industry adopts Rust (or a similar language) and have lot of security by default for free

            I can see you didn't care to understand the example I gave. Rust wouldn't have fixed the problem that happened in my bubble.

            I can also see, you somehow think I am against Rust, just because I am for people caring about what they write.

            are questioning reports from Google

            No. I am interpreting the single number 52%, that came out of the report from Google, without caring about the meaning about the metric.
            And that's what is causing you to not like what I wrote.
            It's almost as if it is important to care about the context of what you are writing into. See what I did there?

            • And you didn't care what I wrote. Its not about your bubble and nobody cares what problem you had. You are bringing your argumentation in a topic up, where it does not apply. We are specifically talk about problems that Rust could help against. And you take your argumentation of your personal experience as a reason that people at Google, Microsoft and other big companies didn't want to learn and don't care.

              And when I point it out, then it means people didn't care to understand your example.

              Look, you can tell what you want, using and adopting Rust has real impact in writing and maintaining complex and important code that is secure. There are reports left and right. It's not hard to understand why Rust prevents or helps with these issues.

              • Your reply came out as, one that was trying to refute the claim of some anti-Rust comment. Which the previous comment was not.

                The way Rust works, clearly shows that it was developed by people who cared about those things.

                And just because something happened in my bubble, doesn't directly prove it to not be happening anywhere else, just because it doesn't prove otherwise.

                • Then why do you bring that up, after the argumentation that people did not want to learn? Look I try to be constructive. There are people who do not want to learn, but saying that all security issues is to attribute to that is wrong. Lot of the best engineers and programmers do their best, long time experts and groups, who still make mistakes.

                  What i"m saying is, that your example is not applicable in this discussion, because you are not writing systems programming for operating systems (such as Android or Windows or Linux), which are used by millions of people and ton of hackers try to find vulnerabilities. The best programmers in C and C++ make these mistakes that Rust would prevent (or make it much easier to find and eliminate).

                  That's the point. It's not about these experts not wanting to learn or not caring. We are not talking about the typical programmer for a website for company x or a fake game programmer for Android.

    • Because I stumbled over this paragraph (the page is linked to from Googles announcement) and was reminded of this comment, I'll quote it here:

      First, developer education is insufficient to reduce defect rates in this context. Intuition tells us that to avoid introducing a defect, developers need to practice constant vigilance and awareness of subtle secure-coding guidelines. In many cases, this requires reasoning about complex assumptions and preconditions, often in relation to other, conceptually faraway code in a large, complex codebase. When a program contains hundreds or thousands of coding patterns that could harbor a potential defect, it is difficult to get this right every single time. Even experienced developers who thoroughly understand these classes of defects and their technical underpinnings sometimes make a mistake and accidentally introduce a vulnerability.

      I think it's a fair and correct assessment.

36 comments