I'm not sure I agree with the amount of hyperbole in the original post, but you must be joking if you want to claim that browsers or OSes are "safe" in the Rust sense of the word.

Use after frees and numerous other memory bugs are discovered all the time in C/C++ programs (including kernels and browsers). This isn't an imaginary problem. Then combine multithreading and you've got a whole extra level of possible issues. Rust does solve many of these problems, and you can prove it does so mathematically.

I understand why people don't like the use of the term "safe" because it feels like a value judgement. But I think people's egos really should be a bit less fragile when discussing language choices.

> Then just delete your entire OS or at least your browser, don't force yourself to use C and C++ software.

With RedoxOS you actually could do that in the near future once it supports some more hardware. The kernel and entire userland (with graphics) is written in Rust. And they did it in 2 years. If nothing else you have to admit that there are some very talented engineers using Rust.

Your point being exactly what? Don't put words in my mouth because I never claimed C and C++ are as safe as Rust, just that they are good enough for millions, including you, to rely on daily with their lives and that Rust itself relies on some C++ (LLVM). I'd even say that yes, C is the least friendly and most spartan language and C++ is the most complex and hard language that are in wide use nowdays but that wasn't the OP's claim. The OP's claim was ridiculous and on the level of opinion people have of Java applets ("totally unsafe", "useless", etc.). These people who have such opinions of them don't run them in their browsers so you should not run any C or C++ on your machine either or you are clearly overdramatizing.

Mathematical provability and technical excellence has sadly little to do with adoption - see where JavaScript, Erlang, Haskell, OCalm, Modula, etc. ended up and tell me every language got what it deserved based on its own merit.

Fanboying over Rust and RedoxOS (it being impressive or not is besides the point) won't fix all that "doable if stars align C" and "humanly impossible C++ that has UB even after few lines" code out there in the government, power plants (including nuclear), infrastructure, stores, embedded, banks, ...

Egos have nothing to do with it. I dislike JavaScript, Java and C# personally (not for any technical reasons but due to my tastes) but if I've seen someone saying the are useless and everything written in them is broken I'd call BS. I'm similarly fond of Free Pascal with LCL for personal GUI toys but if someone said it'll take over the world and destroy Qt and GTK+ behemoths I'd also call BS. Hell, I'd defend your precious little Rust if someone said something stupid about it.

There's factual critique (which I have lots of myself and I don't recommend C or C++ to new hobbyist programmers but Python3), there's personal taste (that you mustn't camouflage as technical opinions) and then there's pedal to the metal "I hate the language so it's totally useless and no human can use it" BS like the OP's comment.

Rust supposedly targets C and C++ programmers so it shouldn't be acceptable to shit all over their tools and by extension their work, telling them they are stupid for liking these languages and are doing everything wrong as an engineer. The fact that such BS is disallowed in official Rust spaces is really telling of how idiotic and ridiculous it is: https://news.ycombinator.com/item?id=14755394

Regarding my initial outburst, I'd like to clarify that it was specifically against a comment claiming that rewriting C code in ("modern" or not, whatever) C++ is the safest choice if someone is worried about security of a C codebase. I didn't actually even say a word about Rust. The C vs. C++ claim there was already enough to make me want to cry loud.

Ah, but I never called to delete any C/C++-based code! That's a strawman from you here. Also, especially I didn't say it's impossible to write anything substantial and/or useful in C++, oh, most certainly it is! But truly, I did and do claim it's humanly impossible to write anything safe in those. As to doing a programmer's job wrong, sorry if you got such impression. Wasn't my intention. C++ is powerful, and in many cases, the gains of using it overpower the risks. As to endangering people, now that's a different topic, and there are measures to protect people possible even in case of unreliable systems. But anyway that's really niche, your Windows/Linux/OSX laptop/PC won't really endanger people until you start hitting them with it, to first approximation. In the other case, like medical software, logic bugs can be I suppose orders of magnitude more dangerous to people than UB-related etc. bugs.

I'm not saying C++ kills people. But I am saying it is producing inherently buggy software, on some level. I'd say it this way: improvements that Rust, Idris, Haskell & many other new languages (and also some old ones, actually, like reportedly Modula, Ada, etc.) try to bring to the table, are similar to what procedural programming or type systems brought over assembly. Resisting those improvements is... strange to me.

[edit: I noticed I wasn't allowed to reply to some comments downstream a while before. I think this may be some kind of a signal for me to just STFU and drop the ball; even if not, I decide to just treat it so, I've said more than enough words already probably. Actually, biggest outburst of my posts on HN ever. I'm starting to think I might be having some kind of a PTSD w.r.t. C++. Anyone knows of some good therapy centers for recovering C++ veterans? :) ]

You can write large C++ programs that are quite safe, using only higher level abstractions (no pointers or explicit memory management). This doesn't require any fancy new C++; code written to C++98 (first ISO C++ standard) will do it just fine.

For exmaple, in C++, we can put two strings together to make a new string without worrying about whether we have a buffer large enough to hold the result, and whether null termination is ensured and so on, or whether or not the original source strings are damaged in the process (they are not), or whether that memory will disappear when we return to the caller. It's just str1 + str2.

I'm no C++ advocate, bu the fact is C++ code can look like a scripting language and be safe like one. C++ also has tools for isolating and managing the C-like semantics that a C++ program might contain.

So even to clump together C and C++ as "C/C++" is not well considered. There isn't a "C/C++" language. If you post a message about C/C++ in the comp.lang.c newsgroup, put on your flame-proof asbestos underwear first.

Higher level constructs like iterators, references and smart pointers are all relatively easy to misuse. It is definitely possible to have safe abstractions like std::string's + and they're one reason why C++ is an improvement over C, but there's still many other dangerous edges that are nearly impossible for a human to keep track of at scale.

There are things in the C++ standard library that are not very well designed, yes.

For instance, erasing from some containers causes undefined behavior if iterators that were created before the deletion continue to be used.

Some of the various smart pointers for managing memory are not so smart; they have been redesigning new ones and deprecating old ones so many times now. It used to be "your code isn't exception safe: use auto_ptr, you dolt!". Then, "you idiot, don't use auto_ptr, use this instead" and so on.

You can avoid all that by defining your own classes that do just what you need, use only the safe stuff from the standard (like the aforementioned strings) and write yourself a perfectly memory-safe, leak-free C++ program.

Even the modernest pointers unique_ptr and shared_ptr are dangerous (use after free/move and, e.g., ease of data-racing in the data, respectively). The problems with them are relatively fundamental to C++ and its idioms. The classes you define will need to avoid using fundamental C++ features like references too: anything pointer-like can lead to problems (including `this`)

The "you (and the standard library, including the completely new parts) are holding it wrong" defence is tired, when it is so ridiculously easy to do so: it is okay and important to acknowledge that a tool is powerful but also has a pile of hard-to-avoid sharp edges.

I fully agree, but you cannot oblige everyone that touches the code to have the same care, and so the typical "C with C++ compiler" idioms sneak in, thus decreasing overall safety.

This is specially the case in the majority of enterprise software that doesn't use any kind of static validation tooling, or CI builds.

> you cannot oblige everyone that touches the code to have the same care

If you can't enforce that certain rules be enforced in a C++ program, you also can't enforce that someone won't sneak C++ modules into a code base written in another, safer language.

> doesn't use any kind of static validation tooling, or CI build

Or, also: a review tool for rejecting stuff that is against the project's explicit coding guidelines.

> you also can't enforce that someone won't sneak C++ modules into a code base written in another, safer language.

In Java and .NET projects you can easily ensure that, and that is a common scenario in some of our customers.

The machines are provided locked down by IT with the project sanctioned tools, including the configuration for in-house Maven and NuGET repositories.

No native code compiler gets installed, servers are configured to disallow unsafe code.

Any library not available requires a change request to the IT team.

With that environment and people, we could easily enforce C++ rules in the same way.

Stuff you don't want in C++ code can be rejected by a pre-commit hook which scans code. That header can't be #include-ed, that crazy operator can't be used, etc.

Also, with open source compilers, you can implement your own warnings. (Been there, done that; in the role of an embedded distro/kernel/toolchain person some years ago, I hacked g++ with custom warnings).

If there is something we don't want in C++, and it doesn't "grep" well, we may be able to diagnose its presence in the compiler and treat that as an error.

Not really, the part you are missing is that it is easier and cheaper not to have C or C++ compilers available at all.

No, what I mean that if those same people were running a C++ shop rather than a Java shop, they could be equally and just as effectively draconian in their enforcement.

Ah I get your point, but static analysers and sanitizers aren't able to find all unsafe issues, specially if binary dependencies are involved.

This is why on Solaris there is OS support via SPARC instructions to enforce bounds and valid pointer use, for example.

That's actually why I call BS on anyone who says "C/C++" while claiming to be a (former) C++ high level user (dabbling in it doesn't count, I dabbled Java, C# and PHP but it's not even on my CV because I don't consider myself anywhere near production level in them) and try to use "C and C++" myself. See: http://www.stroustrup.com/bs_faq.html#C-slash

The call for removal of C++ is implicit or do you now say we keep extremely unsafe (in your eyes) software around and put our lives on the line? Lives and livelihoods do depend on C and C++ software in nuclear, medical, governmental, financial, etc. and somehow millions are not dying due to all this unsafe software. No software is 100% safe, even Erlang (another dear of HN but one that is enjoyed in a more civil environment than the "Go Rust, Fuck C++") is just "nine nines" reliable.

You made C++ sound as bad as Java applets or something similar. Obviously anyone saying Java applets are unsafe, bad, etc. is telling you between the verses to not run any, ever. The words you used were very strong and made it sound like everything is buggy as hell while the bugs are minor and few and far between (relatively speaking, there are lots in some places but your browser and OS is not crashing or leaking your data to hackers on a daily basis, the situation is nowhere near tragic).

Saying C and C++ are unsafe basically shitted on every programmer ever that picked them for anything important, kernel makers, browser makers, server makers, languages VM makers - all idiots, endangering people and property, writing unsafe software!