'Who Needs Rust's Borrow-Checking Compiler Nanny? C++ Devs Aren't Helpless' (babaei.net) 139
"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"?
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"?
Like a bandaid (Score:5, Insightful)
Re:Like a bandaid (Score:5, Funny)
Re: Like a bandaid (Score:2)
Re: Like a bandaid (Score:2)
Re: (Score:2)
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)
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.
Re: (Score:2)
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.
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)
Re:Like a bandaid (Score:4, Insightful)
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)
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: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Don't use static memory allocations unless you have full control of main().
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:3)
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
Re: (Score:2)
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?
Re: (Score:3)
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.
Re: Like a bandaid (Score:2)
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)
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.
Re: (Score:2)
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
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: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
Re: (Score:3)
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:3)
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)
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".
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:Like a plastic knife. (Score:5, Funny)
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:2)
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...
Re:Like a plastic knife. (Score:5, Interesting)
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:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Half of the programmers writing mission-critical code are worse than average.
Re:Like a bandaid (Score:4, Funny)
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)
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: Falling off the bandwagon because I'm drunk (Score:2)
My daughter wrote a programming language, but she does development in MUMPS so I think that's obscure enough she doesn't have to claim her invention.
Re: (Score:2)
Re: (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:2)
Can you link us to any stats to back up that claim? Or are you just making it up for fun?
Re: (Score:2)
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.
Re: Like a bandaid (Score:2)
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.
Re: (Score:2)
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.
Re: Like a bandaid (Score:2)
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.
Re: (Score:2)
I think the idea is that you don't need Rust if you write C++ properly, and you don't need C++ if you write C properly.
The problem in this line of thinking is that we could just make the compiler default to treat all warnings as errors, and both c and c++ would be as safe as rust.
Load the source to damn near any C or C++ project, hit compile and then look at all the warnings that are ignored. The default in Rust (IIRC) is everything is an error, like it was PHP or Javascript.
Where you get into the fuzzy mid
Re:Like a bandaid (Score:4, Insightful)
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.
You can use C++ one way or another (Score:5, Interesting)
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:You can use C++ one way or another (Score:4, 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)
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)
Re: (Score:2)
Luckily, Rust changes all those container issues from SHOULD to MUST.
Re: (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.
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.
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)
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]
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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++
Re: You can use C++ one way or another (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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
As the traditional saying goes (Score:5, Funny)
(cribbed from https://www-users.york.ac.uk/~ss44/joke/foot.htm [york.ac.uk], but widely circulated in the 90s)
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: (Score:2)
Leaks are the least of my worries (Score:4, Insightful)
Vibes (Score:4, Interesting)
C++ isn't fun, Rust isn't a must. (Score:2)
Re: C++ isn't fun, Rust isn't a must. (Score:2)
Re: (Score:2)
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)
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...
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)
No problem, you can do all that in Rust as well. (Score:3)
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.
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.
My experience (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
I would hope that anybody writing software like this nowadays uses C with formal verification.
Re: (Score:2)
That is indeed what formal methods are for. That is why I'm all in favour having languages that are friendly to such automated analysis. That is why I think it's a great idea to put some of what formal methods do into the very language. So that it is your face, all the time, as you edit and compile. And that is why I like Rust.
They're going to be building a new ATC system (Score:2)
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?
BTW Rust does not prevent memory leaks (Score:2)
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.
Is this new to C/C++ devs. If so I'm shocked. (Score:2)
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
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.
Re: Awesome! MAGA applied to programming languag (Score:2)
If not on an embedded system... why? Not being snarky there are just zero times I've ever even thought I might need to do that.
Re: (Score:2)
I mostly do embedded programming, and I've noticed lately the Rust people have been trying hard to sell their oil to us... but they keep making all their normal promises. And obviously we'd have to run "unsafe" all the time anyway, so those promises wouldn't be realized.
In fact, when doing systems programming for servers, the prevalence of that magical oil is why I don't even consider Rust. The culture just seems to have a toxic dose of flavor-aid. Instead, if I want some safety I just use Golang.
Re: Awesome! MAGA applied to programming languag (Score:2)
That would seem to be the perfect use case for C (though I don't know that much about it).
Re: Awesome! MAGA applied to programming langua (Score:2)
Why? Two use cases come to mind that lie just above "embedded"
If you need to interact with memory-mapped hardware.
If you need to pass around large data volumes between processes and shared memory in a Large TLB'd region is the only reasonable way to do it (okay not quite bare hardware addresses but as close as you're likely to get in userland).
Re: (Score:2)
Calling a programming language "woke" is absurd. What on Earth do you mean by it?
Of course you can easily get access to physical memory by address in Rust. Please learn something about what you are speaking before you speak. Just for fun I have been writing some Rust that does exactly that all the time. No annoying lifetime checked references but raw pointers everywhere. Guess what? That code looks mostly a lot like C. But I can also use a lot of other high-level Rust language conveniences.