'Who Needs Rust's Borrow-Checking Compiler Nanny? C++ Devs Aren't Helpless' (babaei.net)
- Reference: 0177448167
- News link: https://developers.slashdot.org/story/25/05/11/1759213/who-needs-rusts-borrow-checking-compiler-nanny-c-devs-arent-helpless
- Source link: https://www.babaei.net/blog/rust-devs-think-we-are-hopeless-lets-prove-them-wrong-with-cpp-memory-leaks/#a-_crtdumpmemoryleaks-demonstration
> 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 [2]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 [3]_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 [4]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"?
[1] https://www.babaei.net/blog/rust-devs-think-we-are-hopeless-lets-prove-them-wrong-with-cpp-memory-leaks/#a-_crtdumpmemoryleaks-demonstration
[2] https://www.youtube.com/watch?v=mmUAdCzrdmQ
[3] https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/crtdumpmemoryleaks?view=msvc-170
[4] https://www.slashdot.org/~NuLL3rr0r
Like a bandaid (Score:4, Insightful)
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?
Re:Like a bandaid (Score:4, Funny)
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.
Re: Like a bandaid (Score:1)
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?
Re: Like a bandaid (Score:2)
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.
Re: (Score:2)
Wouldn't it be better to learn not to cut yourself so you don't need lifetime protection from yourself?
Re: (Score:2)
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.
Re: (Score:2)
> 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: (Score:2)
uhm he's being sarcastic...
Re: (Score:3)
> 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: (Score:1)
I've been doing this long enough to know that I'm not perfect, and I'd rather my tools tell me about bugs ahead of time. Especially when the cost is small enough to be imperceptible.
Re:Like a bandaid (Score:4, Insightful)
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).
Re: Like a bandaid (Score:2)
Why wouldn't you use new if the memory remains allocated for the lifetime of the program? Not all dynamic memory is transient.
Re: (Score:2)
> 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?
Re: Like a bandaid (Score:2)
Because it's simple. Why would I use a fucking smart/unique pointer if ownership and deletion are not an issue?
Re: Like a bandaid (Score:2)
There is a class of bugs related to static destruction order that can be avoided by never destroying global objects.
Re: (Score:2)
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 :)
Re: (Score:2)
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).
Re: (Score:2)
One competent developer, given enough time, can create code in C++ that does not need a software nanny. My experience is that many competent software developers working on the same project with the usual deadlines leave a trail of bugs behind them. Many being silly memory misuse errors. Never mind all that CEO's need a yacht nonsense.
Like a plastic knife. (Score:2)
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:3)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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!
Re: (Score:3)
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.
Re: (Score:2)
> 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.
Re: (Score:3)
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.
Re: (Score:3)
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.
Falling off the bandwagon because I'm drunk (Score:2)
We all know that the more popular something is, the less cool it is. You want to be a cool coder guy and not an unhip normie, right?
Even C++ is almost too popular for me to admit to using it in some circles. These days I try to convince people that I only write in my own custom dialect of ML and SmallTalk. With a meta-verification stage in Spin and TypeScript.
Re: (Score:2)
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.
You can use C++ one way or another (Score:3)
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.
Re: (Score:3, Informative)
> 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.)
Re: You can use C++ one way or another (Score:2)
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.
Re: (Score:2)
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.
Re: You can use C++ one way or another (Score:2)
If a container could potentially be used that way, then you SHOULD build in thread safety or use a lock-free data structure. Similarly, if you intend to begin using a pre-existing container, analyzing the risks of doing so SHOULD be the first step.
Re: (Score:2)
"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.
Re: (Score:2)
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
As the traditional saying goes (Score:5, Funny)
> 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 [1]https://www-users.york.ac.uk/~ss44/joke/foot.htm [york.ac.uk], but widely circulated in the 90s)
[1] https://www-users.york.ac.uk/~ss44/joke/foot.htm
Re: (Score:1)
Nonsense. The dozen instances shoot themselves in the head, ideally in a multi-threaded way so as to more efficiently shoot themselves on modern multi-core processors. The trick is not to have the parent thread wait for them to report for them to report back as they are all dead and simply timeout and then memory leak. It's much more efficient all round.
Re: (Score:2)
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.
Re: As the traditional saying goes (Score:1)
C, C++, asm: get your gun, shoot a deer, bring it back, skin it, butcher it, cook it, have delicious venison for dinner.
Java/Python/Rust/whatever: order a prepared meal online and congratulate yourself on your culinary sense for having the correct wine on hand to pair it with.
Leaks are the least of my worries (Score:3)
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:3, Interesting)
In upcoming times of vibe coding and what not, better have more nannies than less.
C++ isn't fun, Rust isn't a must. (Score:2)
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
Re: C++ isn't fun, Rust isn't a must. (Score:2)
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.
nanny ? (Score:4, Insightful)
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...
Awesome! MAGA applied to programming languages! (Score:1)
Who cares about the outcomes though, right? Rust is woke!
Re: Awesome! MAGA applied to programming language (Score:1)
Rust *is* woke as I recall. But the real problem is that sometimes you need to access physical memory by address and not have a zillion bullshit software checks happen each time.
Such tools are useful, but do not work that way (Score:1)
First of all: that only works in debug builds/modes.
Secondly: during runtime, memory is initialized with something like 0xEEEEEEEE for "empty" as in allocated but not initialized memory.
Third: freed memory is filled with 0xDEADDEAD or 0xDDDDDDD.
So while the program is running, you stumble over double frees and uninitialized memory easy, not so easy over leaks.
Fourth: to find leaks, the code is required to free all memory on (during) program termination. Under the assumption, that the same "free logic" is ca
Oh that would NEVER happen to ME (Score:3)
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.
Re: (Score:2)
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
Classic enthusiast statement (Score:2)
Let's make programming more fun by making it harder!
No problem, you can do all that in Rust as well. (Score:2)
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
A real man/woman (Score:1)
This idea that coding was a task for a real man or woman who were not lazy and capable of avoiding the pitfalls of the particular language they were using is and was never true. When you release a tool to the world that by its very use has the capacity of compromising security it will, of course, result in compromised security. So any effort to develop tools that prevent security flaws as part of the development process are superior for the general development community. Maybe that's not the case for some p
Oh whatever (Score:1)
My code works because I know what I'm doing, not because I'm wearing a straitjacket masquerading as a general purpose programming language.
On a related note, it is entirely possible to write buggy trash that crashes or introduces privilege escalation bugs or credential leaks in a "safe" language by using flawed logic that compiles wonderfully.
Re: (Score:2)
A lot of those bugs spawn from design decisions from the same era as C.
In band signalling with special characters being the big one. Proper escaping is like not screwing up frees and pointer arithmetic, too much to ask for on average.
Multiplayer games are riddled with exploits (Score:2)
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.
Can you mod article flamebait? (Score:2, Interesting)
n/t