So don't use STL
Indeed, No True Scotsman would use STL with C++.
clang-tidy and Cppcheck and flaw finder and Sonarqube
The last job I had where I had to use C/C++, we automatically ran an expensive static analysis tool every time we checked in code. I'd estimate that it only found about half of the potential segfaults, and it made up for that by finding twice as many false positives.
ve never seen a software distribution mechanism as careless and sloppy as NPM. Bazillions of dependencies and no signing of packages. [
... ]
Rust's cargo packaging system is almost exactly the same way. And the last time I looked, Go's packaging was very similar. And package signing won't help if the maintainer's key/cert has been exfiltrated and cracked.
This is what you get when you embrace DLL Hell -- the idea that you should pin your program to a single specific revision of a library, rather than, y'know, doing the engineering work to ensure that, as an app author, you're relying only on documented behavior; and, as a library author, to be responsible for creating backward compatibility for old apps linking to old entry points. Sticking to that principle lets you update shared system libraries with the latest enhancements and bug fixes, while remaining relatively sure none of the old clients will break.
"Sometimes you have to break backward compatibility." Agreed, but the interval between those breaks should be measured in years, not days.
The "rules" of mutable collections in STL state that collections may not be mutated while being iterated.
Nope. If I had used st::list instead of std::vector, it would have been perfectly fine and officially supported. (Assuming I changed "i+10" to "i+11" in order to make the algorithm actually terminate, although that change wouldn't affect the vector crash.).
The problem is that there are dozens of different rules you have to remember to apply to the different types of lists and iterators. And that's only talking about that one topic. There are hundreds of other rules covering a multitude of language aspects that you have to mentally apply against every single line of code you write, many of which can potentially cause memory corruption.
You don't need the language to enforce memory safety to program memory-safe. The most important thing is, for example, to never touch raw pointers. C++ makes it very easy to avoid this. Rust forces you to avoid it, but just because C++ gives you the loaded gun, it doesn't mean you have to use it. In particular not on your own foot.
That is a dangerous misconception. You don't need to use any pointers to get memory errors in C++:
#include <stdio.h>
#include <vector>
int main() {
std::vector<int> v = {1, 2, 3, 4, 5, 6, 7, 8, 9};
for (auto i : v) {
if (i % 2 == 0) {
v.push_back(i + 10);
}
printf("%d\n", i);
}
return 0;
}
$ g++ -Wall -pedantic t.cpp
$ echo $?
0
$./a.out
1
2
-947527061
1600570778
5
6
7
8
9
languages like Rust exist to put ignorant programmers in straight jackets for their own good
Are you seriously trying to suggest that never allocating memory is not also a "straight jacket"?
You seem to be saying that a currently existing bowdlerized version C++ is safe for close-world problems. Possibly so, but that still leaves C++ unsuitable for open-world problems. That makes C++ only suitable for niche applications. Why learn it?
If you just use Rust or any other memory safe language, you won't have to worry about what kind of "world" you're writing for, or about choosing from a range of increasingly dangerous "profiles".
For that you would want to focus on free energy and food replicators because once you have that, there's not much reason to work anymore.
No matter what, you're still going to need someone in a red shirt to duck into the circuit bays and reverse the polarity.
Someone didn't live through the loss of the floppy drive, DB9 ports, and parallel ports.
In my day, to plug in a mouse: We took the box apart, installed a proprietary bus card, and then tried to figure out non-conflicting spots for the I/O and IRQ jumpers. Then we typed a bunch of gibberish into AUTOEXEC.BAT. And we liked it!
Not at all. Free citizens picking lettuce on a corporate-owned ranch is the American Dream!
It's better than medieval serfdom was because you're FREE!!! You could even prove it by wearing a giant bald eagle and flag T-shirt while you work!!!
A whole bunch of opportunities have recently opened up to US citizens for picking lettuce.
At least Nixon had the class not to force his minions to take all of the credit for the Apollo missions in their press releases.
That's what Trump did here: Same as usual he took all of the credit for other peoples' work.
You wonder why he gets under peoples' skin? It's because essentially everything he does is some kind of asshole move like this.
Yeah, that's why everyone gives Nixon credit for putting a man on the moon.
If you spend time with the higher-tier (paid) reasoning models, you’ll see they already operate in ways that are effectively deductive (i.e., behaviorally indistinguishable) within the bounds of where they operate well. So not novel theorem proving. But give them scheduling constraints, warranty/return policies, travel planning, or system troubleshooting, and they’ll parse the conditions, decompose the problem, and run through intermediate steps until they land on the right conclusion. That’s not "just chained prediction". It’s structured reasoning that, in practice, outperforms what a lot of humans can do effectively.
When the domain is checkable (e.g., dates, constraints, algebraic rewrites, SAT-style logic), the outputs are effectively indistinguishable from human deduction. Outside those domains, yes it drifts into probabilistic inference or “reading between the lines.” But to dismiss it all as “not deduction at all” ignores how far beyond surface-level token prediction the good models already are. If you want to dismiss all that by saying “but it’s just prediction,” you’re basically saying deduction doesn’t count unless it’s done by a human. That’s just redefining words to try and win an Internet argument.
BLISS is ignorance.
