>all I see is someone pushing the problem further under the carpet, into the runtime.
How often are there bugs in language runtimes that cause vulnerabilities in programs that are exploitable by users putting in different data into an otherwise secure program? (I'm not talking about the case where the runtime has a sandbox that breaks when the user loads bad code into it; this is a use-case C/C++ don't even try to address so that would be comparing different things. I'm talking about cases where someone is running a program that communicates over the network and the program's own code is written correctly, but a problem in the runtime makes it so the program is vulnerable to remote code execution.) The main example I can think of like that was Shellshock, which was horrible, but I would never have held up Bash as an example of a safe language. Bash has always been on my short list next to C and C++ of languages to avoid because of how easy and common it is to make mistakes that are practically unnoticeable in review.
>On the other hand I DO agree that 'junior' programming will always be a problem, regardless of the matter, and pretty much, regardless of the language.
Junior developers can write a buggy mess in any language. C/C++ are practically the only popular languages where a junior developer can accidentally write a backdoor in average-looking code that doesn't use any APIs.
I can tolerate some bugs in my software sometimes, but exploitable bugs are an entirely different thing to me.
How often are there bugs in language runtimes that cause vulnerabilities in programs that are exploitable by users putting in different data into an otherwise secure program? (I'm not talking about the case where the runtime has a sandbox that breaks when the user loads bad code into it; this is a use-case C/C++ don't even try to address so that would be comparing different things. I'm talking about cases where someone is running a program that communicates over the network and the program's own code is written correctly, but a problem in the runtime makes it so the program is vulnerable to remote code execution.) The main example I can think of like that was Shellshock, which was horrible, but I would never have held up Bash as an example of a safe language. Bash has always been on my short list next to C and C++ of languages to avoid because of how easy and common it is to make mistakes that are practically unnoticeable in review.
>On the other hand I DO agree that 'junior' programming will always be a problem, regardless of the matter, and pretty much, regardless of the language.
Junior developers can write a buggy mess in any language. C/C++ are practically the only popular languages where a junior developer can accidentally write a backdoor in average-looking code that doesn't use any APIs.
I can tolerate some bugs in my software sometimes, but exploitable bugs are an entirely different thing to me.