The "goto" keyword is similarly dangerous. I've seen very good arguments for leaving it out, and generally poor arguments for keeping it in a language. "I can use it safely" is not a good argument, because it's just like Jim Jefferies' standup routine linked above: "Why should I have my guns taken away from me?"
An example of a good argument for structured programming is the talk "The Forgotten Art of Structured Programming - Kevlin Henney [C++ on Sea 2019]": https://www.youtube.com/watch?v=SFv8Wm2HdNM
Similarly, this article makes a very good argument that concurrent or async code is essentially the "goto spaghetti reinvented, but even worse", and that Structured Concurrency is the solution: https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
Rust could comparatively easily implement goto, and it’d be unconditionally safe (as regards memory safety). I’d even honestly like it to, mostly just because it’s possible rather than because it’d be useful—most prominent goto patterns can be expressed better in other ways in Rust, e.g. RAII (destructors) instead of goto cleanup, and break/continue let you emulate any structured uses of goto. (I live in hope that https://github.com/rust-lang/rust/issues/48594 will one day land, so you can use break to skip the remainder of a labelled block, no loop required.)
You wouldn't be able to goto into or out of most (all?) blocks that would change ownership, for example.
Rust currently checks borrows using control-flow graphs (though I believe the plan is for that to change, and the replacement might make life harder for implementing goto, I don’t know). Rust’s mid-level intermediate representation (MIR) actually has goto. In a control-flow graph, goto is just adding new edges, and it’s comparatively simple to make it work.
And about async code: Have fun writing bare metal code with that. Because, you know, your compiler will spit gotos anyway, and unlike gotos you write, you'll have little control over that.
Everyone agrees about loops, try catch for goto err; is near ubiquitous, defer and context managers are popular for goto cleanup;, throw is setjmp up the stack, coroutines are setjmp for multitasking.
Well, Google has 100s of millions of lines of C++ that power much of the internet. They certainly have no intention of getting rid of this code, and have deemed the tradeoff worthwhile. Yes, in theory this C++ codebase might not be the most reliable or secure, but their practices are certainly scalable and battle tested. Not saying it is easy, but it is certainly possible to build an ecosystem around C++ with fuzzers/linters/whatever to reach an "acceptable" level in practice.
> Meanwhile, huge amounts of quite safe Java and C# code keep happily ticking along -- exposed to the internet -- often needing patches only for the C/C++ modules that they include as a part of some framework!
Not necessarily. Plenty of null pointer exceptions in production Java code that bring down systems. Yes, they are "safe" but I don't think the tens of millions of customers affected appreciate such subtle nuances: the consequences are the same for them.
I agree that there can be more severe consequences due to the lack of "safety" from exploits, privilege escalation, and what not. But with stuff like sandboxing, the broader ecosystem, etc the decision isn't as simple as your argument might suggest.
https://source.android.com/devices/tech/debug/tagged-pointer...
https://security.googleblog.com/2019/08/adopting-arm-memory-...
https://threatpost.com/google-arm-android-bugs-memory-taggin...
https://source.android.com/devices/tech/debug/hwasan
Google also paid for the effort to remove C99's VLAs from the Linux kernel.
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Ki...
Google is also the company that started the effort to adopt Rust in the Linux kernel.
https://security.googleblog.com/2021/04/rust-in-linux-kernel...
So they definitely know how much money it costs them to keep C and C++ around, and are taking actions to reduce that monetary cost related to fixing security bugs.
On the other hand, they just introduced the Android Game Development Kit, with C and C++ APIs.
Brilliant observation!
Even smart and careful programmers make mistakes, though, and they don't use goto for laughs. Likewise, even a novice programmer can probably use it safely in a small function.
I can have disciplined new hires, but they don't know what they don't know yet about what is at stake.
The problem with languages like C and C++ is that that the "happy path" is unsafe, unstructured, or an unexpected footgun. There's article after article written about how compilers do bizarre optimisations based on undefined behaviour.
Everyone writing a significant volume of C code is writing code littered with gotos, because as Linus said, it's the only terse way to handle error conditions in C. In C#, Java, and Rust there are structured and safe ways to handle errors (exceptions and the '?' operator). No need for liberally sprinkling code with goto.
Linus rightly makes the claim that "nothing is as good as C" at performance, or low-level control. In the past, this was entirely correct. But these days, even high-level VM-based languages like C# are acquiring features that give C++ a run for its money, and Rust is very close to C++ in performance but much safer.
[1] Memory safe at least. Most C# code is also unlikely to leak resources, unlike most C/C++ code.
> We keep lowering the bar for technical prowess, it seems; if something has the potential to be used "wrong", high-minded designers remove the offending syntax rather than find or train competent programmers. This is why Java removes pointers (among other things) -- it's not that pointers aren't useful or efficient, it's that they require discipline from programmers.
It turns out that "discipline doesn't scale", and programmers have not been able to write substantial amounts of reliable and secure software using pointers. Not Linus, not the BSD maintainers, not the OpenSSL team, not anyone. Not even with C++20 and a tool bag full of fuzzers and linters.
Meanwhile, huge amounts of quite safe Java and C# code keep happily ticking along -- exposed to the internet -- often needing patches only for the C/C++ modules that they include as a part of some framework!
One thing I've learned in my old age is that speed limits aren't there for you. They're there for the bad drivers. If you raise the speed limit, more accidents will happen, even if you can handle the speed. More accidents will happen to you, even if you never personally crash your car. Other people can hit you! https://youtu.be/a9UFyNy-rw4?t=179
In the same way, we programmers don't exist in a vacuum. We use vastly more code written by other people than we have written ourselves. Even Linus has personally touched less than 1% of the code it takes to start up a web browser on Linux and load a web page from a Linux web server. See the "30 million line problem": https://caseymuratori.com/blog_0031
To summarise: I've learned that the ecosystem matters, and that we have to optimise for the average case, because that's where the majority are in a Bell curve.