Yeah, but as far as I understand that’s not a C vulnerability. It wasn’t added. C just exposes how the underlying CPU works.
If you could avoid exposing dangerous memory quirks but still retain the same power… well, you’d have invented Rust. Rust is a better language than C, I agree with that.
Okay, but how do you code on a CPU without directly interfacing the CPU at some point? Python and JavaScript both rely on things written in mid-level languages. There’s a difference between a bad tool and one that just has limitations inherent to the technology.
Like, to echo the meme a bit, it’s not a totally straight comparison. They have different roles.
Yes, also Rust. It wasn’t an option until recently though.
The times when C or C++ is worth it definitely isn’t always, but I’m not sure I’d class much of OS programming and all embedded and high-performance computing as small. If you have actual hard data about how big those applications are relative to others, I’d be interested.
Also, it’s a nitpick, but I’d personally say a footgun has to be unforeseeable, like literal shoe guns being added to a video game where guns were previously always visible. Once you understand pointers C is reasonably consistent, just hard and human-error-prone. The quirks follow from the general concepts the language is built on.
once you understand C++ the pitfalls of C++ are reasonably consistent
All of C++? That’s unreasonable, it’s even in the name that it’s very expansive. Yes, if you already know a thing, you won’t be surprised by it, that’s a tautology.
C is more than just pointers, obviously, but the vast majority of the difficulty there is pointers.
there are like what, 3 operating systems these days? assume those are all written entirely in c and combine them and compare that to all code ever written
Plus all previous operating systems, all supercomputer climate, physics and other science simulations, all the toaster and car and so on chips using bespoke operating systems because Linux won’t fit, every computer solving practical engineering or logistics problems numerically, renderers…
Basically, if your computational resources don’t vastly exceed the task to be done, C, Rust and friends are a good choice. If they do use whatever is easy to not fuck up, so maybe Python or Haskell.
True, but AFAIK they all sucked really bad. If you needed to make something that preformed back then you wrote in assembly.
FORTRAN might be a good counterexample. It’s pretty fast, and I’m not actually sure if it’s memory safe; it might be. But, it’s definitely very painful to work with, having had the displeasure.
JavaScript is also not fine.
C++ apparently has a lot of footguns if you use too many parts of it. C and orthodox C++ are fine.
people say this but C is significantly more batshit than javascript
oh you used
scanf? one of the basic functions of our language? sorry that’s got a buffer overflow vulnerability so now your application is compromisedYeah, but as far as I understand that’s not a C vulnerability. It wasn’t added. C just exposes how the underlying CPU works.
If you could avoid exposing dangerous memory quirks but still retain the same power… well, you’d have invented Rust. Rust is a better language than C, I agree with that.
exposing the machinations of the underlying CPU with no regard for safety is like, the definition of a footgun
Okay, but how do you code on a CPU without directly interfacing the CPU at some point? Python and JavaScript both rely on things written in mid-level languages. There’s a difference between a bad tool and one that just has limitations inherent to the technology.
Like, to echo the meme a bit, it’s not a totally straight comparison. They have different roles.
a footgun isn’t inherently bad, it just implies a significant amount of risk
yes, if you need the ability to code on a low level, maybe C is necessary, but the times where that is actually necessary is smol
also rust
Yes, also Rust. It wasn’t an option until recently though.
The times when C or C++ is worth it definitely isn’t always, but I’m not sure I’d class much of OS programming and all embedded and high-performance computing as small. If you have actual hard data about how big those applications are relative to others, I’d be interested.
Also, it’s a nitpick, but I’d personally say a footgun has to be unforeseeable, like literal shoe guns being added to a video game where guns were previously always visible. Once you understand pointers C is reasonably consistent, just hard and human-error-prone. The quirks follow from the general concepts the language is built on.
once you understand C++ the pitfalls of C++ are reasonably consistent
there are like what, 3 operating systems these days?
assume those are all written entirely in c and combine them and compare that to all code ever written
All of C++? That’s unreasonable, it’s even in the name that it’s very expansive. Yes, if you already know a thing, you won’t be surprised by it, that’s a tautology.
C is more than just pointers, obviously, but the vast majority of the difficulty there is pointers.
Plus all previous operating systems, all supercomputer climate, physics and other science simulations, all the toaster and car and so on chips using bespoke operating systems because Linux won’t fit, every computer solving practical engineering or logistics problems numerically, renderers…
Basically, if your computational resources don’t vastly exceed the task to be done, C, Rust and friends are a good choice. If they do use whatever is easy to not fuck up, so maybe Python or Haskell.
There were memory-safe languages long before C was invented, though; C was widely considered “dangerous” even at the time.
True, but AFAIK they all sucked really bad. If you needed to make something that preformed back then you wrote in assembly.
FORTRAN might be a good counterexample. It’s pretty fast, and I’m not actually sure if it’s memory safe; it might be. But, it’s definitely very painful to work with, having had the displeasure.
What’s the point of having a function in the standard library if the universal recommendation is to never use it?
Is that the recommendation? This is the first time I’ve actually seen it discussed.
I’m wondering at this point if a new, different stdlib would be better. Or just use Rust.