> The vast majority of all code you write will not invoke UB
That's a bit like saying “the vast majority of the haystack doesn't contain any needles”.
> most people tend to stick to an 'easy' subset of syntax
I'm not sure I understand what you mean. Undefined behavior has nothing to do with syntax. It's strictly a semantic issue.
> It used to be that people used dynamic memory allocation to beat C with, but that is just a resource management issue. TBH, this is not rocket science.
If I understand correctly, the objection isn't that it's rocket science, but rather that you get little help from your tools if you do it wrong. Memory debuggers will only tell you about memory management bugs that manifest themselves in a particular program run. If a bug will only manifest itself under conditions that are hard to replicate, you're out of luck.
Of course, none of this is an indictment of manual memory management per se, or suggests that garbage collection is a universally good solution. But manual memory management has usability issues, which fortunately being addressed in more modern language designs like Rust.
> If you need dynamic memory allocation, you had damn well better know how to use it properly.
Sure, but are better compile-time diagnostics too much to ask for? Notice that compile time diagnostics don't introduce any runtime performance penalty.
> Another example is performance; saying that a language comes within a factor of 2 of C's performance and therefore is fast is absolutely ridiculous. a factor of 2 is huge.
No disagreement here.
> so what would normally be UB is actually DB in most cases,
As far as I can tell, the trend among C and C++ compiler writers is to optimize programs very aggressively under the assumption that UB simply will never happen, rather than to turn UB into DB.
> its defined by the compiler and hardware that we're intimately familiar with.
Well, “works on this machine” isn't good enough for most of us.
You're correct.... the vast majority of the haystack doesn't contain any needles, thats the point. And you also know where the needles tend to be and stay away from that area.
I'm not implying that UB doesn't exist, simply saying that using C is a different mindset.
If you use C, you dont just use the language, you use the language, the toolchain and the machine, you're familiar with the whole stack, quite often down to the metal.
The point about memory management is that memory management is just case of the general problem, i.e. resource management. resource management is a skill you need to have if you're a softie and making it easier in one specific case (RAM) is not a generic solution. Better that you learn how to do it properly then apply that knowledge in all situations (files, RAM, power, etc).
e.g. where is the GC-equivalent for power management? or file handles? its the same problem in a different domain.
> The point about memory management is that memory management is just case of the general problem, i.e. resource management.
Wholeheartedly agree. I'm aware that GC is no solution for this problem. But I'm not arguing in favor of GC - I'm arguing in favor or making manual resource management safer, for example, like Rust does. Resource management is every single bit as manual as in C - the only difference is that the compiler yells if you do it wrong.
That's a bit like saying “the vast majority of the haystack doesn't contain any needles”.
> most people tend to stick to an 'easy' subset of syntax
I'm not sure I understand what you mean. Undefined behavior has nothing to do with syntax. It's strictly a semantic issue.
> It used to be that people used dynamic memory allocation to beat C with, but that is just a resource management issue. TBH, this is not rocket science.
If I understand correctly, the objection isn't that it's rocket science, but rather that you get little help from your tools if you do it wrong. Memory debuggers will only tell you about memory management bugs that manifest themselves in a particular program run. If a bug will only manifest itself under conditions that are hard to replicate, you're out of luck.
Of course, none of this is an indictment of manual memory management per se, or suggests that garbage collection is a universally good solution. But manual memory management has usability issues, which fortunately being addressed in more modern language designs like Rust.
> If you need dynamic memory allocation, you had damn well better know how to use it properly.
Sure, but are better compile-time diagnostics too much to ask for? Notice that compile time diagnostics don't introduce any runtime performance penalty.
> Another example is performance; saying that a language comes within a factor of 2 of C's performance and therefore is fast is absolutely ridiculous. a factor of 2 is huge.
No disagreement here.
> so what would normally be UB is actually DB in most cases,
As far as I can tell, the trend among C and C++ compiler writers is to optimize programs very aggressively under the assumption that UB simply will never happen, rather than to turn UB into DB.
> its defined by the compiler and hardware that we're intimately familiar with.
Well, “works on this machine” isn't good enough for most of us.