Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Programming

'Who Needs Rust's Borrow-Checking Compiler Nanny? C++ Devs Aren't Helpless' (babaei.net) 148

"When Rust developers think of us C++ folks, they picture a cursed bloodline," writes professional game developer Mamadou Babaei (also a *nix enthusiast who contributes to the FreeBSD Ports collection). "To them, every line of C++ we write is like playing Russian Roulette — except all six chambers are loaded with undefined behavior." But you know what? We don't need a compiler nanny. No borrow checker. No lifetimes. No ownership models. No black magic. Not even Valgrind is required. Just raw pointers, raw determination, and a bit of questionable sanity.
He's created a video on "how to hunt down memory leaks like you were born with a pointer in one hand and a debugger in the other." (It involves using a memory leak tracker — specifically, Visual Studio's _CrtDumpMemoryLeaks, which according to its documentation "dumps all the memory blocks in the debug heap when a memory leak has occurred," identifying the offending lines and pointers.)

"If that sounds unreasonably dangerous — and incredibly fun... let's dive into the deep end of the heap."

"The method is so easy, it renders Rust's memory model (lifetimes, ownership) and the borrow checker useless!" writes Slashdot reader NuLL3rr0r. Does anybody agree with him? Share your own experiences and reactions in the comments.

And how do you feel about Rust's "borrow-checking compiler nanny"?

'Who Needs Rust's Borrow-Checking Compiler Nanny? C++ Devs Aren't Helpless'

Comments Filter:
  • Like a bandaid (Score:5, Insightful)

    by wed128 ( 722152 ) on Sunday May 11, 2025 @02:05PM (#65368881)
    Cool, so you have a tool to stop the bleeding after you've cut yourself. Wouldn't it be better to not cut yourself at all?
    • by evil_aaronm ( 671521 ) on Sunday May 11, 2025 @02:30PM (#65368929)
      I didn't RTFA, in the time-honored tradition of upstanding /. readers, but I got a tongue-in-cheek sense from the summary. And with that, I agree. Used to be, programming was for manly men, or womanly women - looking at Grace Hopper, here, among others - and you got by with the help of your wits, a manual, and a bit of grit and pluck. When the masses adopted programming, things changed, just like, say, driving: it used to be the province of talented people, and if you weren't good enough, you sat on the sidelines and watched. Now, everyone and their dog can "program," debasing a once proud skill, and just like the driving analogy, it isn't necessarily for the better. We're at a point where we need to remove power and freedom from these activities, and enforce tighter restrictions, because power and freedom are dangerous in the hands of the "wrong" people: ie. everyone who isn't an expert. As a long-time experienced developer, I don't need guard rails and hand-holding. Give me make and gcc, and gtfo of my way. And if I cut myself? Eh, it happens, and it's my own fault: I'm not going to blame the tools. If I'm smart, I'll actually learn from the mistake and not let it happen again.
      • Obviously I would never make a mistake, just some other folks. And of course I would never use their code. So what should I fear?
      • I don't think simply double checking pointer references and memory limits has much to do with gender. It's too bad that so many people failed to do it that we need another whole language to hold their hands.
      • I don't need guard rails and hand-holding. Give me make and gcc, and gtfo of my way.

        I use a Makefile even when I use Rust or Go or React because when I haven't looked at a project for a while, the Makefile remembers how to build and run the project.

      • Re:Like a bandaid (Score:5, Interesting)

        by tlhIngan ( 30335 ) <slashdot&worf,net> on Sunday May 11, 2025 @10:28PM (#65369565)

        Rust is not immune to memory leaks. Indeed, the Rust documentation says you can create memory leaks in Rust [mit.edu].

        But memory leaks are safe - they're just memory blocks that aren't referenced anymore and sit around clogging up your program.

        Rust doesn't serve to protect against memory leaks. It serves to protect against memory errors. Things that you might do accidentally, like a double-free. Or accidentally run off the end of a buffer. Or other strange errors like pointers to out of scope memory blocks.

        And no matter how careful your coding, you can inadvertently create it, usually through some tricky set of if/then/else statements. Indeed I found one in my code - or rather, a static code checker did by pointing out the exact set of circumstances where I might end up with a double-free. I couldn't prove that those circumstances would never happen, and it was a trivial fix to implement. (Some people hate setting free'd pointers to NULL, but free(NULL) is actually a safe operation by the spec).

        Errors are almost always caused by tricky sections of code. That's why we have things like static and dynamic code checkers and other tools to help us. The only reason Rust is around is as an alternative - you can do C/C++ and use the code checkers to validate your code, or you can use Rust. What you choose depends on many factors, and using one or the other may not necessarily be a time savings or an effort savings. They're options.

        Just like in the Linux kernel. It's basically straight C. You don't need to use Rust, but if you're writing a driver, it is an option if you're wanting to avoid common dynamic memory scenarios. For some people, if you're writing a complex driver, not having to worry about a class of bugs means they can concentrate more on the driver core itself. For others, well, they know the kernel inside and out and thus can avoid the common traps.

        • Rust is not immune to memory leaks. Indeed, the Rust

          I would have just mentioned std::mem::leak. But more importantly, look at the code: You're basically not going to do that by accident; they literally create a reference counter of a linkedlist of a refcell, and then point to that from inside another reference counter. That's literally 5 pointers worth of indirection. And even then, you're still not done yet. Angle of sphere is the only person I can think of who would do something like this on accident.

    • by dfghjk ( 711126 )

      Wouldn't it be better to learn not to cut yourself so you don't need lifetime protection from yourself?

      • Absolutely right. That's why circular saws should never have guards. Also if pilots didn't have proximity warning radar, I'm sure they would learn to avoid each other and the ones that didn't would trouble us far less.

        • Absolutely right. That's why circular saws should never have guards. Also if pilots didn't have proximity warning radar, I'm sure they would learn to avoid each other and the ones that didn't would trouble us far less.

          Well yeah except for the whole ummm "passengers dying" thing, but that's just collateral damage.

      • Re:Like a bandaid (Score:4, Insightful)

        by bsolar ( 1176767 ) on Sunday May 11, 2025 @03:14PM (#65369001)

        Wouldn't it be better to learn not to cut yourself so you don't need lifetime protection from yourself?

        If you are handling sharp blades frequently enough it's only a matter of time until you will make a mistake, even if you know how not to make that mistake. Only relying on training to avoid mistakes is not a good idea.

        As example, butchers definitely know how not to cut themselves, but many still wear chain-mail protection because they know mistakes happen and that the additional layer of protection can make the difference.

    • Re:Like a bandaid (Score:5, Insightful)

      by serviscope_minor ( 664417 ) on Sunday May 11, 2025 @02:36PM (#65368935) Journal

      Yes. On the other hand I've not had a leak in C++ side forever. Other memory errors, sure but a leak? No.

      About the only way to get leaks now is if you are using raw new and delete, but why do that? The built-in facilities will now handle everything up to but not including mutable cyclic graphs and I'm fairly sure in that case you need reachability analysis, regardless of the language (though many have that built in in the GC).

      • Why wouldn't you use new if the memory remains allocated for the lifetime of the program? Not all dynamic memory is transient.

        • Why wouldn't you use new if the memory remains allocated for the lifetime of the program? Not all dynamic memory is transient.

          Why would you use new in that case?

          • Because it's simple. Why would I use a fucking smart/unique pointer if ownership and deletion are not an issue?

            • I'd probably use an std:: vector if it's variable size, side you then get the benefit of known length. Otherwise it'll go on the stack.

            • You're missing my point. If the memory remains allocated for the lifetime of the program, then declare it as static (in main?) and let it live on the stack instead of the heap. No need for new.

              • Memory management hygiene is still important when multiple people work on a single large projects, or when you're implementing a library which will be used by who knows who, who knows where.

                Don't use static memory allocations unless you have full control of main().

                • Fair enough. But we're talking about memory that remains allocated for the lifetime of the program. That's not something a library would/should do. It implies that the memory is allocated in main, or a closely-held function called by it.

                  I'd argue that it's better to avoid the heap if you know the memory is allocated from the program's start to finish. The heap is for dynamic memory that is used and released, used and released, and so on. The only situation where you'd need to use the heap is if the size of

              • by Viol8 ( 599362 )

                And if you dont know how much memory you require before startup? You know, when doing obscure unusual things like loading global data...

                FFS, talk about no clue.

            • by Jeremi ( 14640 )

              Because it's simple. Why would I use a fucking smart/unique pointer if ownership and deletion are not an issue?

              There's code where you have proven (to your own satisfaction) that a memory leak doesn't exist or doesn't matter, via a manual analysis of how your program works... and then there's code where you don't have to do any whole-program-analysis to prove that, because you can see via trivial keyhole inspection that a memory leak isn't possible, regardless of what the rest of the program does or doesn't do.

              Replacing a bare use of the new operator with a smart/unique pointer (or stack allocation or static variable

              • by Viol8 ( 599362 )

                Thats just a load of word salad by someone who doesn't really understand programming or memory. Do you have any clue how and when memory leaks happen?

            • Because if you always use std::______ for memory, you never have to think, "Is this a situation where it is safe?" And you might get it wrong. Or someone might refactor so that you become wrong, but they didn't notice you used "new". More importantly, your reviewers and future developers never have to stop and ask, "Is the bug I'm looking for because of this weird 'new' call?" One pattern everywhere avoids a host of risk.

          • There is a class of bugs related to static destruction order that can be avoided by never destroying global objects.
      • by kertaamo ( 16100 )

        Funny thing is that a memory leak is not regarded as "unsafe" in Rust. Only all those other memory use errors you say you have made. Perhaps you need Rust :)

        • Only all those other memory use errors you say you have made.

          I was commenting specifically on the narrow points made in the article and comments, which was weirdly about memory leaks. I was trying to avoid a C++ vs Rust pissing contest (since we'd lose either way to Ada/SPARK weenies).

      • I've not had a leak in C++ side forever.

        So you are perfect then. Congratulations, you're the only one. Could also be a bit of self delusion and never writing anything particularly sophisticated but never mind that.

        • I don't think you understand it know C++ very well. You get leaks if you use raw new and delete. But why works you every use them? I cannot remember the last time I used the low level facilities. You also get leaks if you get raw resources from a C library, but I've always been anal about putting those inside an RAII wrapper (which today may be as simple as a unique PTR with a lambda deallocate).

          I routinely test my choice in CI with valgrind, and it doesn't leak.

          I'm not the only one. If you are getting leak

    • You won't cut yourself in Rust because it's a plastic knife. I'd rather use a bowie knife that can do the job I want it to do. That's why programming takes skill, understanding, and training.

      C doesn't tell you where you can go or what you can do. C doesn't look at your code and tell you "Sorry, I can't do that Dave". C will just always, always open the fucking pod bay doors when you tell it to.

      Rust is like building a stairway pedestrian overpass over every intersection, even country roads. You can get

      • Re: (Score:2, Interesting)

        Rust is very definitely not a plastic knife. It's as sharp and powerful as anything out there. It's main disadvantage is being very complex and hard to use. Rust programming takes skill, understanding, and training to an even greater extent than most other languages. In return, you get memory safety at very close to zero overhead. For most projects, you're better off using a language that sacrifices a little speed to get easier memory safety. That includes recent ones like Kotlin and Swift, as well as

        • by Uecker ( 1842596 )

          Rust programmers definitely use "unsafe" a lot for challenging problems where the want to achieve the same speed as C. So the idea that Rust gets you the speed in C with memory safety is a bit of an exaggeration. For many problems, you either get the speed of C with unsafe Rust or you get memory safety with safe Rust. I agree though that it nice that you have this in the same language.

          A lot of the popularity of Rust seems to be that you can quickly assemble programs by using other peoples code. This has se

          • The reason for using unsafe is rarely speed. It's usually either for interfacing with external libraries, or for dealing with unusual situations where the compiler isn't smart enough to prove something is safe, even though it really is.

            Compare how memory management works in a few languages.

            Swift: All objects are allocated on the heap and managed with reference counting. This provides easy memory safety, but adds overhead to every assignment.

            Rust: Objects can be allocated either on the stack or the heap, e

            • by Uecker ( 1842596 )

              I understand what unsafe is, thank you. The point is that in many scenarios where you need speed you end up in "unusual situations where the compiler isn't smart enough to prove something is safe".

        • by kertaamo ( 16100 )

          C++ is very definitely not a plastic knife. It's as sharp and powerful as anything out there. It's main disadvantage is being very complex and hard to use. C++ programming takes skill, understanding, and training to an even greater extent than most other languages.

          At least Rust tries to help you.

          • by serviscope_minor ( 664417 ) on Sunday May 11, 2025 @05:03PM (#65369161) Journal

            C++ is very definitely not a plastic knife.

            It's a knife with a sharp blade where the handle is also the blade. Double knives FTW!

            • It's a knife with a sharp blade where the handle is also the blade.

              So, a scalpel forged from a single piece of metal?

              That's the danger of trying to be too clever...

            • C++ is very definitely not a plastic knife.

              It's a knife with a sharp blade where the handle is also the blade. Double knives FTW!

              I'm afraid I'm going to have to call "nonsense" on this. Using a lame metaphor does not excuse people of their personal responsibility to not write code that's functionally just three bugs in a trenchcoat. nor will using Rust stop them from doing so.

              Per example, the code for the cat utility is dead simple. Anyone reasonably competent should be able to audit that code to be 100% sure it's safe within a few hours, and yes I'm including time to go look at the reference manual for every single instruction bec

      • by test321 ( 8891681 ) on Sunday May 11, 2025 @04:13PM (#65369071)

        You have been elected mayor of the city, but a single toddler fatality might make you lose next elections. You build overpasses on every intersections.
        Or: you were promoted from software developer to manager. You can't tell if the developers on the team are good, but you suspect they are not as the company code has a history of memory management issues. You're being told to do better this time or lose the job. You choose to mandate Rust.

        • by bsolar ( 1176767 )

          Or: you were promoted from software developer to manager. You can't tell if the developers on the team are good, but you suspect they are not as the company code has a history of memory management issues. You're being told to do better this time or lose the job. You choose to mandate Rust.

          Rust would prevent a bad developer from writing unsafe code (assuming no unsafe), but said developer would still have to understand how to write functioning Rust code. Rust is not easy to learn in that respect.

          IMHO if you don't have good developers you are screwed anyway, but if you can choose probably giving them something with garbage collection is the best option in terms of balancing safety and productivity.

          • Rust would prevent a bad developer from writing unsafe code (assuming no unsafe)

            That's not true, though. It means you won't have any memory leaks, but there are a LOT of other ways code can be unsafe.

          • Correct you still need good developers. But good developers are still human. Even the best developers crap out insecure code from time to time. It may shock you to know that even the best tradesmen have first aid kits with bandaids.

            Humans suck at being perfect.

    • by OrangeTide ( 124937 ) on Sunday May 11, 2025 @03:05PM (#65368989) Homepage Journal

      The pain and suffering that every C++ developer experiences elevates C++ programming from a simple tech job to a high art.

      It's like a master cabinetmaker that is missing a few fingers. You know that guy has learned from tough lessons.

      • by Sique ( 173459 )
        And still, more people buy at IKEA, where you can mount everything with a Philips screwdriver and that funny Allen key you get in the bag with the hardware.
    • by bjoast ( 1310293 )
      Indeed. Even if you don't use a language with explicit lifetimes, lifetimes as an abstract concept has to always be considered and understood by the programmer. The difference is that if you use a language where you are forced to explicitly handle lifetimes, it can provide compile time guarantees of certain safety properties.
    • Cool, so you have a tool to stop the bleeding after you've cut yourself. Wouldn't it be better to not cut yourself at all?

      Indeed. If you ever find a human that doesn't accidentally cut themselves, let me know. Until then we keep bandaids in the cupboard. Likewise show me a C++ dev who has never made a mistake, and I'll show you a million compromised lines of code that have led to all manner of security problems.

      You cant beat human nature. We are quite useless and dumb, and our only hope is to one day be replaced by robots.

      • You cant beat human nature

        That probably explains why languages that offer increased safety don't result in less bugs, but just bugs in different places.

        • by kertaamo ( 16100 )

          Can you link us to any stats to back up that claim? Or are you just making it up for fun?

        • Your post is non-sequitur. You're saying safety isn't increased and instead citing bug quantities in different places. The location of a bug very much implicates its safety. Breaches of memory safety very much improve total security. Not all bugs are equal, not all *places* bugs can arise are equal.

          Memory safety. Memory is a key word. Rust doesn't make claims about total safety. You can't leave off that word, it changes the meaning dramatically.

      • I've never once cut myself with a blade. Sure, learning from your own mistakes is solid, but learning from others' mistakes is so much better. I didn't need to cut myself to know I should be careful with a tool that can cut me.

        • I've never once cut myself with a blade.

          Yes my robot overlord. Incidentally I've never once shot myself with a nailgun. I don't use it on a daily basis though. Risk is a concept which involves the likelihood that you're in a situation to harm yourself.

          Go ask your wife if she's ever cut herself while cooking.

          • I cook for my girlfriend.

            Use appropriate tools. Follow appropriate precautions. Accidents are almost always actually someone's fault. They don't magically come down with the force of God.

  • by ffkom ( 3519199 ) on Sunday May 11, 2025 @02:18PM (#65368909)
    The good thing about C++ is that it does not force a single "paradigm" on you, as so many programming languages do. You can do bit-banging, pointer arithmetic and self-modifying code, but you don't have to - if you are afraid of shooting yourself in the foot, just stick with some standard library structures and never touch a pointer. I am not inclined to glorify one or the other approach, both have their time and place.

    The only complaint I have with C++ is that its developer was so eager to be backward-compatible with C in its early days, that the syntax readability suffered somewhat. But the long-term evolution of C++ is also a plus, those not just programming for fun can really benefit from a mature language that remains available through the decades.

    Whether Rust will earn such merits is still open.
    • by Waffle Iron ( 339739 ) on Sunday May 11, 2025 @02:32PM (#65368931)

      if you are afraid of shooting yourself in the foot, just stick with some standard library structures and never touch a pointer.

      Two words: Iterator invalidation.

      You don't need any pointers to shoot yourself in the foot with C++.

      (Of course, most of the self-appointed C++ cowboys on this site aren't aware that iterators could even be an issue.)

      • If you're trying to mutate a container while you iterate, you SHOULD be paying closer than usual attention. It's an inherently risky sort of operation.
        • Sure, as a developer, you SHOULD never write any bugs.

          Good luck with that.

          BTW, the mutation and iteration could very well be happening in completely different parts of the application, written by different developers who aren't even aware of each other's code.

        • If you're trying to mutate a container while you iterate, you SHOULD be paying closer than usual attention. It's an inherently risky sort of operation.

          Probably because it's just a bad idea all around. Precisely why the borrow checker doesn't allow it (this breaks the twice mutably borrowing rule.) In my experience, even in languages other than rust, there are always better ways of mutating a collection without doing it WHILE you're actually iterating over it.

    • by dfghjk ( 711126 )

      "The only complaint I have with C++ is that its developer was so eager to be backward-compatible with C in its early days..."

      The very existence of C++ was predicated on backward-compatibility with C, C++ started as a preprocessor for C.

      • Now said developer himself complains about C++ developers using too much C in their code, as if he's blaming that on its (deservedly) bad reputation. Suck a crock. Drew Devault said it best:

        C++
        Pros: none
        Cons: ill-defined, far too big, Object Oriented Programming, loads of baggage, ecosystem that buys into its crap, enjoyed by bad programmers.

        https://drewdevault.com/2019/0... [drewdevault.com]

    • Please be kind, I am not a serious C++ developer myself. The thing I understand about C++ is that it evolves over time. The conference talks I have watched on stream tells me there is so much out of date info out there. Even what was a good idea decades ago, like design patterns, may become a hurdle with "modern" C++. Presenters are then trying their best to get people on "modern" C++ but they need to fight against what was consider good in the past. I frown at the vision of many LLM based tools using out o
    • The good thing about C++ is that it does not force a single "paradigm" on you, as so many programming languages do.

      That's sort of true, but inevitably you need to work with other people's code, and they choose a paradigm and you have to work with it.

    • I would argue that the backward compatibility with C (and with itself mostly) is C++'s saving grace. Most languages out there (I include Rust in this) are toys.

      A toy can be fun, insightful, really powerful, whatever. But a non-toy will be around in 25 years, doing the same job it does today. You can build a project with a non-toy over 25 years and it will work. It can have new features, become faster, etc. But what makes the language a non-toy is extreme backwards compatibility and careful standards.

      C++

      • 25 years seems pretty arbitrary, but there are several languages that old that are still in commercial use. C# will even be there in a couple years.

        • 25 years is a reasonable age for a successful company. It represents approximately one human generation. Long enough, if the company is successful, to have an established product line that appeals to two generations, and have an internal need to maintain and expand their software stack. By all means, use 30.
      • by kertaamo ( 16100 )

        I find your definition of "toy" language rather extreme.

        By your definition of "toy language" C itself was a toy when created. By your definition C could only have became a non-toy language 25 years after it was created.

        OK, then. Rust became a real project in 2009. That's 16 years ago. By your definition Rust will become a non-toy language in 2036. I will wager that Rust will be greatly in use in 2036.

        Don't get me wrong. I think C is great. Small and perfectly formed (almost). About the minimum required of a

      • A toy can be fun, insightful, really powerful, whatever. But a non-toy will be around in 25 years, doing the same job it does today.

        So you would consider Python and PHP to be non-toy languages, right? They've both been around for 30+ years.

    • The good thing about C++ is that it does not force a single "paradigm" on you, as so many programming languages do.

      Except in C++, you're going to object orient whether you want to or not. In the case of C++, that also means vtables everywhere, even when they're not needed, which also has a runtime cost. Unless of course, your cpp files are, at the end of the day, as C as they can be, and naturally, you're not using the C++ standard library. In which case, why did you choose C++ for your project again?

      The only complaint I have with C++ is that its developer was so eager to be backward-compatible with C in its early days, that the syntax readability suffered somewhat

      And nowadays he complains that C++ developers choose to put too much C in their code. The irony of him choosing to base h

  • by Samantha Wright ( 1324923 ) on Sunday May 11, 2025 @02:30PM (#65368925) Homepage Journal

    C++: You accidentally create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical care is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying "that's me, over there."

    (cribbed from https://www-users.york.ac.uk/~ss44/joke/foot.htm [york.ac.uk], but widely circulated in the 90s)

    • by PPH ( 736903 )

      Rust: You take out your trusty S&W Model 36 to shoot your foot. But then discover that the key for the Hillary Hole has yet to be developed.

  • by mileshigh ( 963980 ) on Sunday May 11, 2025 @02:37PM (#65368939)
    Leaks are the least of the bad things that pointers can do, e.g. reusing deleted memory, exceeding bounds, flat-out corrupt memory access, etc. _CrtDumpMemoryLeaks is useful but very limited. Address sanitizers are an improvement, but right I'm working on what's clearly a memory access problem and yet the address sanitizer is happy.
  • Vibes (Score:4, Interesting)

    by arnowa ( 640300 ) on Sunday May 11, 2025 @02:37PM (#65368945) Homepage
    In upcoming times of vibe coding and what not, better have more nannies than less.
  • An issue with C++ is how confidently people defend it's shortfalls. Listen, C++ has a lot of perks, but it has downsides too. C++'s memory issues are unpleasant to deal with, and it makes writing & debugging code quite annoying. I was working on a project a while back where I kept running into errors that required debug time. I'd guesstimate 90% of my time was chasing down weird memory issues, some of which didn't even throw an error and resulted in logic bugs instead. Granted, that might be because I'm
    • I wrote by own C++ frameworkin a former job starting out as C++98 with smart pointers from boost. We rarely had memory problems . The trick besides smart pointers: No multithreading. Instead we had maybe 10+ programs running communicating with sockets in the embedded Linux system running 24/7. Each program was build around a eventloop, where the sockets where served non-blocking.
    • Rust is also filled with unsafe blocks of code where the safety guarantee is "trust me bro".

      I'd say it's more like "hold my beer"

  • nanny ? (Score:4, Insightful)

    by Tom ( 822 ) on Sunday May 11, 2025 @03:13PM (#65368999) Homepage Journal

    So you don't need a nanny compiler. Fine by me, C and assembler were among the first programming languages I learnt.

    But when you follow that up by "and here's our nanny memory leak checker instead..." and you don't notice the irony, I'm not sure if I want to trust you with my pointers if one redirect throws you off...

  • by Sarusa ( 104047 ) on Sunday May 11, 2025 @03:36PM (#65369027)

    The fact that there are so many memory leak and bounds overflow vulnerabilities with C++ programs that are actually out there is something you just can't sweep away.

    Sure, YOU are the perfect C++ programmer and YOU would never write a memory leak or bounds overflow, but you are obviously in the tiny minority (and you're not as good as you think about this, neither am I). And memory leaks are not even worst thing, they usually don't (though they can) lead to immediate predictable exploit, like, oh - the opposite of a memory leak, accessing something that's already deleted. Or stack overflow. So many others.

    Imagine if we could harness with turbines the full power of all the C++ programmers who are deathly afraid of having to learn any other language (because C++ is so arcane and convoluted it takes years to fully learn, they think other languages are the same) and spend all their time posting about how safe C++ Ackshually is, we might be able to power one AI datacenter. And I say this as someone who's been programming C++ for 30 years, but learned other languages as they came along because I know its problems. Python, C#, Rust, Lisp, bash, they all have their place. So does C/C++ - I still use it for embedded firmware, and would use it for writing a game engine, but right tool for the right job.

    • by Uecker ( 1842596 )

      Memory leaks are not even something Rust guarantees to prevent.

      There is certainly a lot of bad C++ and C code out there. This may improve somewhat if everybody moves to Rust, but I guess bad programmers would still create a mess by overusing "unsafe" to get the job done. And the supply chain disaster Rust brings with it will also not exactly help.

      The repeated "oh that would NEVER happen to me" smear against C and C++ is still not appropriate IMHO. While mistakes can happen to everybody, memory issues are

  • Let's make programming more fun by making it harder!
  • C++ guys think they have all the fun of fighting their code with debuggers and sanity checkers at run time. No problem you can have all that fun in Rust as well. See "What if Rust was worse than C" https://www.youtube.com/watch?v=5MIsMbFjvkw&t=6444s

    It's simple just follow the rules of Crust:

    1. Make all functions unsafe. Putting the burden of memory safety on the programmer.
    2. Use raw pointers only. Thus removing all that annoying borrow checker nonsense.
    3. Do not use the Rust standard library. Of course not, that requires use of references and hence the borrow checker, etc.
    4. Make all pointers mutable as much as possible. Thus ensuring C like behaviour.
    5. Ensure all structs are C-Compatible Representations. Use #[repr(C)]. To ensure predictable memory layout and compatibility with C.

    It's a lot of fun. I already have Vector and String and a linked list in Crust. Fast compile times, no problem.

  • Even without user run servers, user authored content can be used to exploit multiplayer games too.

    Multiplayer games should be as security focused as any other software open to the internet. If you have to find a bug from its behaviour before you can fix it, there's far more you'll never find.

  • I wrote code for an air traffic communications system. This stuff had to be reliable.

    The code ran on the metal - no operating system - which helped. I devised my own memory allocation strategy, used the MMU to leave unmapped pages between allocations in the hope that bugs would show up sooner rather than later, took extreme care with casts and pointers and blah, blah, blah.

    And one day I came within 12 hours of forcing a major airport to close because I had made a booboo.

    For cases where it really does matter

    • by dskoll ( 99328 )

      I agree. I'm not going to learn Rust, for the same reason as you... I'm retired. But if I were starting out now or in the middle of my career, I'd definitely learn it. It does seem to be gathering momentum as the way of the future, and any additional safety a language can offer should be embraced.

    • by Uecker ( 1842596 )

      I would hope that anybody writing software like this nowadays uses C with formal verification.

  • They're going to be building a new air traffic control system [transportation.gov]. Bidders from big defense contractors and large software companies submit bids. They'll staff up to provide bodies to do the work. What language do you want them to work in?

  • As explained in The Rust Programming Language book, Rust doesn't indeed prevent memory leaks (although it makes them difficult to achieve). What the language prevents (unless you use unsafe code) are memory errors like accessing dangling pointers, double free, etc. It also prevents data races, but not memory leaks.

  • I was so busy reading the comments here and countering the anti-Rust misinformation that only now I read the article.

    That is great but is it new?

    Over 15 year sago I was tasked with finding a memory leak in an embedded Linux C++ application, after the product was in production and the original dev team disbanded. There were no memory sanitisers at the time and they would not work on our little embedded system anyway. Using a debugger was fruitless. I ended up overriding malloc() and free() such that I could

There are two ways to write error-free programs; only the third one works.

Working...