C++ Creator Rebuts White House Warning (infoworld.com) 258
An anonymous reader quotes a report from InfoWorld: C++ creator Bjarne Stroustrup has defended the widely used programming language in response to a Biden administration report that calls on developers to use memory-safe languages and avoid using vulnerable ones such as C++ and C. In a March 15 response to an inquiry from InfoWorld, Stroustrup pointed out strengths of C++, which was designed in 1979. "I find it surprising that the writers of those government documents seem oblivious of the strengths of contemporary C++ and the efforts to provide strong safety guarantees," Stroustrup said. "On the other hand, they seem to have realized that a programming language is just one part of a tool chain, so that improved tools and development processes are essential."
Safety improvement always has been a goal of C++ development efforts, Stroustrup stressed. "Improving safety has been an aim of C++ from day one and throughout its evolution. Just compare the K&R C language with the earliest C++, and the early C++ with contemporary C++. My CppCon 2023 keynote outlines that evolution," he said. "Much quality C++ is written using techniques based on RAII (Resource Acquisition Is Initialization), containers, and resource management pointers rather than conventional C-style pointer messes." Stroustrup cited a number of efforts to improve C++ safety. "There are two problems related to safety. Of the billions of lines of C++, few completely follow modern guidelines, and peoples' notions of which aspects of safety are important differ. I and the C++ standard committee are trying to deal with that," he said. "Profiles is a framework for specifying what guarantees a piece of code requires and enable implementations to verify them. There are documents describing that on the committee's website -- look for WG21 -- and more are coming. However, some of us are not in a mood to wait for the committee's necessarily slow progress."
Profiles, Stroustrup said, "is a framework that allows us to incrementally improve guarantees -- e.g., to eliminate most range errors relatively soon -- and to gradually introduce guarantees into large code bases through local static analysis and minimal run-time checks. My long-term aim for C++ is and has been for C++ to offer type and resource safety when and where needed. Maybe the current push for memory safety -- a subset of the guarantees I want -- will prove helpful to my efforts, which are shared by many in the C++ standards committee." Stroustrup previously defended the safety of C++ against the NSA, which recommended using memory-safe languages instead of C++ and C in a November 2022 bulletin.
Safety improvement always has been a goal of C++ development efforts, Stroustrup stressed. "Improving safety has been an aim of C++ from day one and throughout its evolution. Just compare the K&R C language with the earliest C++, and the early C++ with contemporary C++. My CppCon 2023 keynote outlines that evolution," he said. "Much quality C++ is written using techniques based on RAII (Resource Acquisition Is Initialization), containers, and resource management pointers rather than conventional C-style pointer messes." Stroustrup cited a number of efforts to improve C++ safety. "There are two problems related to safety. Of the billions of lines of C++, few completely follow modern guidelines, and peoples' notions of which aspects of safety are important differ. I and the C++ standard committee are trying to deal with that," he said. "Profiles is a framework for specifying what guarantees a piece of code requires and enable implementations to verify them. There are documents describing that on the committee's website -- look for WG21 -- and more are coming. However, some of us are not in a mood to wait for the committee's necessarily slow progress."
Profiles, Stroustrup said, "is a framework that allows us to incrementally improve guarantees -- e.g., to eliminate most range errors relatively soon -- and to gradually introduce guarantees into large code bases through local static analysis and minimal run-time checks. My long-term aim for C++ is and has been for C++ to offer type and resource safety when and where needed. Maybe the current push for memory safety -- a subset of the guarantees I want -- will prove helpful to my efforts, which are shared by many in the C++ standards committee." Stroustrup previously defended the safety of C++ against the NSA, which recommended using memory-safe languages instead of C++ and C in a November 2022 bulletin.
Welcome (Score:3, Funny)
Re:Welcome (Score:5, Insightful)
Well, for one, it wasn't them "micromanaging", it was saying "a lot of bugs are caused by mismanaging C and C++ code, we aren't going to stop you, but it's probably a good idea to use languages that don't have that risk."
For another, frankly:
"My long-term aim for C++ is and has been for C++ to offer type and resource safety when and where needed"
Soft words like "aim" and "when and where needed" really soften the case that C++ should fall in that "blessed" category.
"eliminate most range errors relatively soon -- and to gradually introduce guarantees into large code bases through local static analysis and minimal run-time checks"
Again "soon"-ish, and invoking the fact you can, optionally, fire some static analysis at a codebase to catch a lot of these sorts of issues.
In short, C++ has done some work to provide *a* way through with mostly reasonable guarantees, but it requires a very careful and thorough development discipline. This is in short supply in the average software development team.
"Much quality C++ is written"
Another big "if", newly written, quality written C++.
Re: Welcome (Score:3, Informative)
Politicians, and their administrator henchmen, have no business 'directing' private industry to use or not use a certain technology like a particular programming language.
Do they have an opinion on COCOL usage? Because word has it the government still has a ton of legacy COBOL code running on IRS computers...
Aren't these the same folks that tried to force every defense contractor to code in ADA? How'd that work out?
No, I won't take technical "advice" from the folks that struggled to implement a healthcare i
Re: (Score:2)
Re: Welcome (Score:2)
I honestly agree that C++ should be a niche deployment. And generally people should move to languages that actively encourage safer designs even at the cost of performance or time to delivery.
"Just use it right" isn't a proper response without the context of how easy that is to do. C++ is a great example as it has a "make everyone happy" mentality and thus there are multiple ways to do the same thing which means multiple ways to screw it up. It also means an unnecessary amount of mental load for devs and _
Re: (Score:3)
That is my feeling as well. C++ is useful when you need something that can be a high and a low level language at the same time. But that's pretty rare, because you can almost always use higher-level languages for the bulk of the code, and drop down to C or Rust for the spots where something close to bare-metal performance is needed (e.g., when you aren't waiting for a network packet, a piece of user input, or some spinning ferric oxide.)
I've needed to drop to C only once in my very long career, and that w
Re: (Score:2)
The phrasing "when and where needed" is pretty poor in that type and resource safety are probably needed in about
Re:Welcome (Score:4, Insightful)
In short, C++ has done some work to provide *a* way through with mostly reasonable guarantees, but it requires a very careful and thorough development discipline. This is in short supply in the average software development team.
Teams that lack development discipline will write unsecure and unmaintainable code irrespective of the programming language they use.
Re: (Score:2)
In short, C++ has done some work to provide *a* way through with mostly reasonable guarantees, but it requires a very careful and thorough development discipline. This is in short supply in the average software development team.
Then perhaps companies, trainers, and institutions, should be focusing on correcting that human deficiency so that the results can benefit all software development and programming languages, instead of just hand waving away a very serious attitude problem with the humans that is causing real harm.
Re:Welcome (Score:5, Interesting)
In rust, (much like in Java or C# to a lesser extent for that matter), the default is safe. If you want unsafe, you can. Therefore, most of what you will find in StackOverflow for example is safe. Also, static analysis tool that specifically look for "unsafe" is probable already going a long way to secure your codebase.
In C or C++, the default is that a buffer overflow is often akin to a security issue. Most of what you can find online needs to be carefully understood in order to avoid an insecure mess. Static analysis needs to be carefully crafted and maintained to meet lesser safetiness than Rust, C# or Java.
There are no absolutes though. You can have security issues with Java/Rust/C#. But most of the security issues that comes naturally with C and C++ are simply not there unless you specifically enable them. That makes a lot of difference.
Re:Welcome (Score:5, Insightful)
There is an important difference between a language where you can write safe code and a language where you can't write dangerous code. Some people in the C++ community seem to be wilfully ignorant of this distinction.
There is also an important difference between a practical language with escape hatches where the use of those escape hatches can be easily audited and one where it can't. If you can audit your entire codebase for potentially unsafe code and ensure any such code is carefully reviewed when it can't be avoided then that is very much better than having millions of lines of code where something unsafe could just be lurking anywhere. Again some in the C++ community seem to deliberately ignore this distinction.
Re: (Score:2)
There's an important difference between making honest mistakes and learning from them, vs. demanding that some machine perfectly correct what ever garbage was scrawled into a text file without a care in the world. If you can't be bothered to ensure your code is correct to the best of your ability without having some machine do it for you implicitly, you shouldn't
Re: (Score:3)
Everyone makes mistakes, no matter how good they are. Adopting defensive practices and tools that have designed out certain failure modes produces better outcomes, in software development as in many other fields. The evidence for this is overwhelming and arguing that we shouldn't need to compensate for human failings because developers should be perfect and not make mistakes in the first place is not a credible position.
Re: (Score:3)
You are basically arguing against seat belts. "I don't crash, so why should I use a seat belt?!"
Answer: because other people crash all the fucking time, and you aren't the only person working in a git repo.
Re: (Score:2)
And I've never used "unsafe" in C#, not in 20 years of using the language.
Most people never have and never will.
Re: (Score:2)
I've inherited unsafe C#, but haven't ever needed to write any myself. I have done a very tiny bit of C, called from C#, to interface with bespoke hardware that would have been otherwise difficult to control from a non-hard-realtime OS.
Most of the rest was to wrap calls around the Win32 API, and, ironically, I found that the managed framework was quite capable of similar functionality via safe, managed code.
Also, a lot of that old code did things like using ints rather than IntPtrs, or otherwise assuming a
Re: Welcome (Score:2)
rust has the unsafe keyword so it will still produce unsafe code.
Though even unsafe rust offers a lot more safety guarantees than even the best C++ static analyzer can.
Re: (Score:2)
rust has the unsafe keyword so it will still produce unsafe code.
Don't underestimate the impact of having to type "unsafe" before you do something. That makes a developer think twice and recognize just how bad it would be if they make a mistake inside "unsafe" and will seek to avoid it. If you ultimately have to resort to unsafe, so be it, but it is likely to be tiny chunks of code if at all, and many will never use the unsafe keyword.
and look at exceptions - the claim is no exception will be ignored again, but in practice they often are
A bit beside the point, but exceptions are never really ignored, they cause an abort of at least some significant chunk of code. An "igno
Re: (Score:2)
Don't underestimate the impact of having to type "unsafe" before you do something.
I never understood why the Windows boot process required you to go out of your way to do a 'safe' boot that disabled the NIC and disabled all the insecure drivers. They should have required you to type 'unsafe boot' in order to enable the NIC.
Re: Welcome (Score:3)
You've got a very poor understanding of what "safe mode" means if you think these are remotely comparable. It means safe as in fail-safe. As in, a failure has already occurred, and we're just spinning up the bare minimum so we can diagnose what went wrong.
Unsafe in rust doesn't mean you've either encountered or are expecting a failure. It means you're lowering a few (but not all) guard rails to allow for more flexibility. Despite that, unsafe rust is still safer than ordinary C++.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Re: (Score:3, Interesting)
Looks like Brandon is now a coding expert, eh?
He might be, since in this case his advice is perfectly valid.
"But Derp! Derp! I can write perfect C++!!!!"
Just shut up.
Re: (Score:2)
Re: (Score:3, Funny)
There is a lot in common here between Rust and Trump. You hear a good spiel when trying to be sold on them. But you ask "so, I see a few problems with your product, let's discuss the practicality of this" and they say "oh, I think you didn't hear me the first time, let me repeat the rambling." Again you ask "but here are some serious drawbacks to your proposals, how will they be addressed?" Then you get the stare. A long stare. And the response is "What are you, some kind of traitor? You like having me
Re: Welcome (Score:2)
I think him, like all die-hard C++ developers, are suffering from the sunk-cost fallacy. His biggest argument against abandoning C++ seems to be "but think of the existing code!" I think that's doublespeak for "I've spent my entire life on this thing, I'm not giving it up now! I'll get it right this time I promise! The fourth decade is the charm!"
And naturally you've got people like The Evil Atheist that have this fear of basically starting over in another camp while they've got years or possibly decades of
Re: (Score:2)
Re: (Score:2)
First time?
Re: (Score:2)
It's a suggestion spurned by the scale of recent security issues, not an order handed down on high. Geez! And a good one.
Re: (Score:2)
Not new, read up on ADA and MULTICS which were foundation of secure computing, that industry ignored
They have likely been updated/replaced but behind closed doors
C/C++ have done a lot of great things, but good security is not one of them
Possible vs. Enforced (Score:5, Insightful)
You can write great, safe code in C++. It's possible I did so many years ago.
You can also write unsafe code in C++ and the average developer is very average.
Re: (Score:2)
You can also write unsafe code in Rust, and to do all the things you can do with C++, you will sometimes have to.
This doesn't mean that people shouldn't use Rust, I don't frankly have a strong opinion on that. The only part of this debate I do have a strong opinion on is that I would have liked to see it not become part of Linux until there were more compilers and tools available. But these days it doesn't affect me much because amd64 has won and is dominant, and that's the only non-ARM platform I use now,
Re:Possible vs. Enforced (Score:5, Insightful)
You can also write unsafe code in Rust,
And this is where a bit of human psychology comes into play. Sure, both Rust and C++ provide "safe" and "unsafe" approaches. However in C++, you have to be "told" which ways are safe or unsafe. Rust constrains that behavior explicitly to "unsafe" blocks, so you have to know damn well the implications of what you are doing, rather than potentially casually doing things the unsafe way without having to face that reality.
Re: (Score:2)
FWIW, I find Rust multiprocessing much more confusing than C++, which means I'm more likely to make undetected mistakes. Ir you want safe multiprocessing, choose Erlang. There you need to go out of your way to do something unsafe, but at the cost of nearly everything being immutable.
Re: Possible vs. Enforced (Score:2)
There is a balance. The objective isn't to make it a challenge to write safe or unsafe code. If many people can naturally gravitate to one set of implementations and the many many other people who will follow them to maintain said results also gravitate to similar coding practices... then it's a good general purpose language. Additionally a mediocre fresher should be able to come up to speed pretty quickly in syncing with the seniors.
There are _plenty_ of languages that meet these requirements including p
Re: Possible vs. Enforced (Score:2)
I don't think you know human psychology as well as you think.
If a warning was effective no-one would smoke or suffer fireworks injuries for instance.
Re: (Score:2)
And this is where a bit of human psychology comes into play. Sure, both Rust and C++ provide "safe" and "unsafe" approaches. However in C++, you have to be "told" which ways are safe or unsafe. Rust constrains that behavior explicitly to "unsafe" blocks, so you have to know damn well the implications of what you are doing, rather than potentially casually doing things the unsafe way without having to face that reality.
If they were marked in C++ so you knew would it be ok then?
Personally I don't place much stock in "safe" vs "unsafe" in general purpose languages from a standpoint of human psychology because real world implications are not embodied in constraints imposed by general purposes languages. If the compiler barks you should be really careful about that unsafe block over there because memory but hey this block over here which results in melted steel when not done in the correct sequence is not marked for safety b
Re: (Score:3)
Worse.
In C++ you can write unsafe code without even realising you've done so.
In Rust, you have to explicitly type the word "unsafe". And if that doesn't clue you in, nothing will.
Re:Possible vs. Enforced (Score:5, Insightful)
Exactly this. If an average developer is a risk—which they absolutely are—you can make them a lot less dangerous by putting guardrails on their work. They can’t be trusted to put up their own guardrails with C++ (because they’re either too incompetent or too proud to do so), but if Rust or other memory-safe languages have those guardrails in place by default, you can trust that most of those developers will be using them.
Bonus points to anyone here who realizes that they are a far more average (or bad) programmer than they’d like to admit. The Dunning-Kruger Effect is strong, and time and again in nearly any field I’ve ever participated in, it’s the people making the most mistakes who protest most loudly about the introduction of safety measures to protect against their mistakes. More times than I’d like, I’ve heard someone make a complaint along the lines of “it takes the skill out of it” when we make a safe choice the default one.
Re:Possible vs. Enforced (Score:5, Insightful)
Professionals in fields like flying recognise that no-one is perfect and operate defensively to mitigate the risk. That's why we have checklists and copilots and why everyone in the cockpit shuts up at certain critical times except for very specific commentary. It's also why a lot of time and money is spent on designing very clear, very efficient controls and displays for cockpits.
It's bizarre that anyone would still argue even the best C++ programmer in the world won't pick the wrong type of smart pointer and end up with an ownership bug some time. Plenty of good programmers used to have null pointer dereferencing bugs, too, but for some reason we don't get so many of those in languages that don't have null pointers.
Re: (Score:2)
Re: Possible vs. Enforced (Score:2)
As every C++ good developer will tell you, only the bad developers are capable of making mistakes.
Re: (Score:2)
EVERY developer is a risk. People are always making mistakes. But I'm not convinced that Rust improves things. I do agree that C++ needs some changes that would break backwards compatibility, but Rust doesn't appear, to me, to be the right answer.
One example of a change that I think C++ needs is for variables to be by default local to the thread where they are created. Another is for non-const functions to be marked so that they can be called by functions external to the class. (i.e. without doing somet
Re: (Score:2)
Re: (Score:2)
Really the list of "p[itfalls" are very small and obvious if you understand the machine at a low enough level.
See, that right there is the problem. We'd have to go back decades before we'd be able to find a time when that knowledge was common among the average developers. And yet they're being asked to work on systems that were created before they were born. I was born in '83 and that knowledge was already fading by the time I was cutting my teeth. My first professional work was a space industry internship where I worked on FORTRAN systems, so of course I made mistakes. Meanwhile, my mentor that summer had initiale
Re:Possible vs. Enforced (Score:5, Insightful)
You can write great, safe code in C++. It's possible I did so many years ago.
You can also write unsafe code in C++ and the average developer is very average.
Its also the case that almost all the average developers consider themselves above average.
Re: (Score:2)
Yes. But it's much more difficult to be sure you've done so in a multi-processing program. Variable sharing between threads should need to be explicitly requested. And there needs to be intermediate levels between public, protected, and private. Also friends needs to be more carefully handled.
That said, I'm still wrapping my head around just when a function that can't be declared const can be used, so I'm not really an expert. If I don't want a particular class to have direct access to the private vari
Re: (Score:2)
It's possible to do the first, but only a limited number of people actually can, and, I'm not either one of them.
I'd be able to do a passable job of writing modern C++.
But working with other developers whose subset of C++ is different from mine and/or each other's? Probably not so much. Because the entire language is MUCH too bit to fit into my head.
Programmer competence vs tools (Score:2)
If you have problems like variables not being initialized prior to use, or bounds not being checked, you have an incompetent programmer and no matter how smart you make a tool, a fool will always out-stupid it.
This is a bit like complaining that an airplane will allow the pilot to land without using his flaps or lowering his landing gear; an incompetent pilot should not be flying in the first place, and a competent pilot may NEED the flaps and/or landing gear to be under his total control (not automated as
You can have my C (Score:2)
Because : C doesn't cause buffer overflows, *I* am the one who's coding buffer overflows, dammit !
Re: You can have my C (Score:4, Funny)
Well, would you be happier if we eliminated you instead of the language that allows you to introduce these vulnerabilities?
Developing programs vs engineering solutions (Score:2)
The more I write code the more I find that when developing prototypes I want the highest level language with the most hand holding. Python has become my go to for developing quick prototypes and proof of functionality, partially because it is easy to develop a quick program, along with the wide library support. C++ is when python is not fast enough, or the environment demands it, and an efficient solution has to be engineered around the constraints of the system.
I haven't used Rust yet as most of what we'
Re: (Score:3)
The counterargument is that if you're writing code before you're designing the solution, you're setting yourself up for trouble.
Why is it that every other engineering discipline designs their product first, then builds it, but software seems to have this idea of building it first?
Sure this is a reductionist observation, but my experience is that probably 80% of software problems are due to "write code first" instead of "think about it and design it first, then implement the design in code."
There's definitel
Re: (Score:2)
The counterargument is that if you're writing code before you're designing the solution, you're setting yourself up for trouble.
Why is it that every other engineering discipline designs their product first, then builds it, but software seems to have this idea of building it first?
Sure this is a reductionist observation, but my experience is that probably 80% of software problems are due to "write code first" instead of "think about it and design it first, then implement the design in code."
There's definitely a continuum of prototype vs design. Both a benefit and detriment of software is that it allows very cheap "prototyping" - the problem is the prototype is often then shipped as the product.
No other industry tends to ship prototypes to end customers, because prototypes are not robust.
I don't know why so many software folks - and software management in particular - are afraid of engineering discipline.
I think this is the main point, prototypes are excellent reference for developing the release program, but the prototype should never be released. And you are correct, there are two approaches to developing a final program, engineer it up front and produce a good clean program from the start, or experiment with a prototype until it works and then write the final program based on the prototype. Any program developed through experimentation will be buggy and cause problems if released.
Re: (Score:3)
Re: (Score:2)
You need to work on a waterfall project, which follows roughly in your ideas on engineering discipline, and then report back.
Re: (Score:3)
I've worked on and delivered at least a dozen "waterfall" projects - and just like any other development model, there's no such thing as "pure" waterfall.
"Iterative waterfall" is a practical reality. I don't know why people aren't aware of this? Is it just not common knowledge? Is there just tribal stigma? Basically there's a lot of advantage to having just enough waterfall with just enough iterative/agile. Going all-in either way is generally problematic.
Re: (Score:2)
As a C developer (Score:5, Insightful)
As a (very long time) C developer, I'd like to assure the White House that every company building software in C is doing so "for a reason", meaning - it was deemed the best (or the only) appropriate tool for the job. Literally no company today (or in the last 20 years) chose to work with C for fun, convenience, or buzzword factor. (OTOH C is fun and convenient to me, but I am not a business).
Re: (Score:2)
Not "the only" appropriate tool. Anything you can do in C, you could do in assembler. Unless you count "number of available developers" and "time to complete the work" as constraints, which I guess is reasonable. But in that case why aren't you arguing for Python. (Or if there are space constraints, Forth.)
I like LOTS of languages. Currently I'm trying C++. (Of course, since I like lots of languages, my depth of expertise in any of them is limited. But I'd pick C++ over Rust for anything.)
Re: (Score:2)
Re: (Score:3)
That reason often seems to be entrenchment and simplicity.
There are more C developers, C is available for most platforms and it is easy to create a compiler for a new chip. It's a small spec language.
These are certainly pragmatic considerations.
But in terms of technical merits and long term considerations, a switch is necessary.
You may comfortably retire with C, but the new generation is less enthusiastic about taking it up. Rust is a much nicer language that learns from C and C++ issues.
Re: (Score:2)
Is the language more important than the process? (Score:3)
C and its derivatives have enjoyed popularity because of the low-level access to hardware provided. That same functionality has also led to a huge number of security holes and exploits.
Other languages, many of which are already considered "safer" for development of critical software (e.g. Ada [adacore.com]), already exist. However, most of them are relegated to niche markets, and efforts to expand their acceptance have been met by resistance. The cost barrier to entry for Ada, for example, is simply prohibitive for many development teams.
Perhaps more emphasis should be placed on the development process, instead of the specific language used for development. If, for example, teams creating critical software (and the term "critical" is left to the interpretation of the reader) were to follow the JPL "Power Of Ten" development rules, [wikipedia.org] the specific language being used for development wouldn't matter. Take away avenues for safety and security issues to enter the code, instead of relying on the compiler to catch and flag those avenues.
That's as far as I go.
Re: (Score:3)
C and its derivatives have enjoyed popularity because of the low-level access to hardware provided. That same functionality has also led to a huge number of security holes and exploits.
Other languages, many of which are already considered "safer" for development of critical software (e.g. Ada [adacore.com]), already exist. However, most of them are relegated to niche markets, and efforts to expand their acceptance have been met by resistance. The cost barrier to entry for Ada, for example, is simply prohibitive for many development teams.
Perhaps more emphasis should be placed on the development process, instead of the specific language used for development. If, for example, teams creating critical software (and the term "critical" is left to the interpretation of the reader) were to follow the JPL "Power Of Ten" development rules, [wikipedia.org] the specific language being used for development wouldn't matter. Take away avenues for safety and security issues to enter the code, instead of relying on the compiler to catch and flag those avenues.
That's as far as I go.
Good developers will follow processes and develop code using best practices. Bad developers will abuse processes, but can't get around a compiler that enforces good coding standards. Good developers are a recurring cost for a company, compilers that enforce good coding standards are (usually) a one time cost. At least that is how I think it is all happening.
Re: (Score:2)
I learned Ada back in college in 1994. But it's OOP implementation uses Objective-C style syntax that I cannot abide. It also seems really more bureaucratic than most people would want to deal with. Can't think of another word to describe it.
Re: (Score:2)
Yeah, but that's the justification... (Score:3)
Of the billions of lines of C++, few completely follow modern guidelines, and peoples' notions of which aspects of safety are important differ.
That's the justification, Bjarne. C++ puts all the choices in the hands of the developer and expects them to know and understand and agree to all of the modern guidelines. Whether it is time, laziness, not wanting to refactor tons of code or the fact that modern guidelines change as the underlying platform changes, there's many reasons why there are billions of lines of C++ that don', won't or can't comply.
When you start from a language like Rust, those options and choices are taken away from the developer, they must conform to a good programming practice, and code from those languages will be inherently safer than the C++ equivalent.
Re: (Score:2)
Yeah, Bjarne is acting like a child. Or a father protecting a child.
Re: (Score:2)
Re: (Score:2)
You have a MUCH higher opinion of Rust than I do. If I believed your arguments I'd say that everything should be written in Erlang, or possibly Scheme. (Or one of the other functional languages.)
Maybe instead ... (Score:2)
Agree, maybe instead of requiring specific technology the problem of poor coding quality and numerous exploits might be solved with more emphasis on math and CS starting from HS, you know, like almost all the Asia is doing, as - surprise, surprise - e.g. Rust compiler originally was written in OCaml, which on the other hand was written in C.
Re: (Score:3)
Yeah, that sounds easy.
Or we could just hurt the C++ creator's widdle feelings and use a language that makes doing bad stuff hard not easy...
emacs vs. vi (Score:4, Funny)
While the government is weighing in on computer nerd holy wars, they should issue a statement as to whether one ought to use emacs or vi.
Re: (Score:2)
Re: (Score:3)
If they're serious about it, all they have to do is say "We won't purchase any applications unless they are written in Rust." But that didn't make Ada popular.
Net title (Score:3)
"C++ Creator Rebuts WH Warning with new Hallucinations about Memory Safety"
Timeline (Score:4, Informative)
More accurately, the predecessor to C++ was designed in 1979. The full timeline:
1979 Development on C with Classes begun
1982 Development on C++ begun
1985 C++ released
1986 Zortech C++ for DOS released
1992 Microsoft C/C++ 7.0 released
Cobol (Score:2)
Welcome to Bell Labs of the late 1970's (Score:2)
I joined BTL in 1977 and worked there until 1991. I learned Unix there and first heard about C++ when it was called "C with Classes". In the 1980's I contributed to and supervised projects that used both C and C++.
What Bjarne Stroustrup doesn't recognize but I hear so very clearly in his written comments is an old "Center 127" mantra. (For those who don't know, Center 127 was the internal organization that developed Unix; it's where all the famous names worked. I didn't work in 127 but in telephony devel
Politicians should NOT.. (Score:2)
...dictate technical choices, and technical decisions should NOT become political
Yeah, I know it happens all the time, and causes lots of problems as clueless bureaucrats get in the way of experts
I get both sides. I really do. (Score:2)
I think it makes sense for commodity programming to be done in safe languages. It's just a good idea - especially for non-seasoned devs. And people can go 25 years in their careers and still be bland. Lots of people never escape their little bubbles of Access / Oracle F&R / whatever, and they shouldn't be trusted to turn out safe C++.
But... C++ should absolutely continue to have a role. I mean, the fact that Joe Jackass can't be trusted to drive a Bugatti doesn't mean they should stop making them. But s
C++ is unsafe by default (Score:2)
Outside of something like Rust's unsafe {...} block, the C++ language should forbid anything that is unsafe, like accessing C-style arrays, rather than a class that overrides [] and is such that invalid array accesses can be caught at compile time.
That is, all pointers should be some managed pointer, all array accesses should be bounds checked, preferably at compile time, and all code capable of creating such a pointer should either be marked unsafe or be verifiable by the compiler to create a valid object.
A point in C++ favor (Score:2)
When you know something could be dangerous you're more cautious, when you think something is safe you can actually be in greater danger from carelessness.
Airplanes are the safest means of transportation because people are more afraid of plane crashes than car accidents. That's because the media splashes every plane crash all over the news. Meanwhile car accidents get no mention. If every car accident was headline news and people were deathly afraid to step in a vehicle, cars and roads would be extremely saf
Trying to make it Political BS (Score:2)
NSA issued this guidance months ago, the White House is just echoing it. If you don't think the NSA has the brains and research to back it up you are sadly mistaken. Stroustrup can't let go of his life's work. Long Live Rust!!
Re: (Score:2)
They've been pushing IPv6 internally also...there's someone causing waves and at risk of losing all power in 2025.
In the case of IPv6, having two separate security stacks is the main thing holding it up. Well other than a lot of the devices still not supporting it even in 2024. Another 10 years minimum I would guess.
Re: (Score:2)
"...some policy wonk" - you mean the head of the Office of the National Cyber Director, the former head of the NSA, and someone who spent 17 years working at the CIA?
I see your ad hominem attack and raise to you the possibility that in the course of his career he knows far more about this topic than you do. I assume that based on the fact that you didn't even attempt to address the content of the discussion.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
I concur.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
But in this case it looks like the senior government people are on the right side of the debate. It's the "engineers" defending demonstrably risky languages like C++ who are trying to promote their own preferences as being safe enough despite all evidence to the contrary.
Re: (Score:2)
Re: (Score:2)
So you replaced ad hominem with appeal to authority and still haven't addressed any of the points made by the white house itself? You're not very good at this whole "compelling argument" thing are you...
I hope that person who wrote "I concur" didn't lull you into a false sense of security. You absolutely do deserve a flaming.
Re: to be fair... (Score:3)
So, I need to program my accounting system in Rust because a former CIA operative and former head of the NSA says so? Is *that* really your argument?
You may want to step away from the discussion for a bit and re-visit your position.
Og, wait, Huawei, along with MS, Google, Amazon, Meta, and others are 'Platinum Sponsors" of the rust foundation - doesn't that just give you a nice, warm fuzzy feeling?
Why not let developers pick their own tools? Oh yeah, "Government knows better!"
Re: (Score:2)
To be fair C and C++ really do have problems. I'm just not convinced that Rust is a suitable alternative. (I could make as good a case for Erlang, and I don't use it. Possibly even for Scheme.)
Re: (Score:2)
Re: (Score:2)
Yeah, I'm sure you have no clue whatsoever what's mean my memory saftety IRT Rust. None whatsoever.