Because all the software projects outsourced to India would come to a grinding halt.

If you wrote a program in 'C' 40 years ago using libc calls, chances are it will still compile and run on just about any platform today with no more than very minor source code tweaks; 40 years ago nobody had even thought of Java. My own experience using Java software is one of frustration with incompatibilities between the different runtime versions. In general I avoid software written in Java.
Java made sense when compilers were proprietary and expensive. Now that compilers are ubiquitous and free, Java is a solution looking for a problem.

Under U.S. capitalism journalists must write stories which generate revenue; be it from subscriptions, advertising, or political interests. A demographic trend of pandering to aging and selfish baby-boomers has seriously undermined the availability of legitimate journalism. Unfortunately I have no clue how a solution would actually occur, but things may get better as the boomers die off.

When investments like government securities pay back more interest than the central bank "prime" lending rate, then all investment banks have to do to make money is borrow some from the central bank and use it to buy securities. This will work until investors lose faith that securities will be paid back with interest.

Who, you ask, is on the hook to pay back government securities? Why taxpayers are, of course; and national debt is astronomical. The upshot is this: our economic growth is predicated on the notion that the taxpayers will continue to service the growing interest on our national debt going forward.

I remember learning to code in C on the Amiga, using the Lattice compiler. It came with hypertext documentation for libc, and header files for the Amiga OS. Access to this information launched my career as a software engineer and proved far more representative of how software development works these days than what was available on the PC at the time. I was spared from segmented memory access requirements, and instead got to focus on more important software development issues.

OOP can be a great help for complex data, but is often used simply for its own sake. Multi-threading is another tar pit naive OOP programmers fall into, being used to solve problems which are far more reliably solved by singly threaded approaches like non-blocking I/O. If you fully understand what needs to happen on the computer during program execution, then coding software in "c" goes rather quickly.
There is nothing that prevents you from OOP coding in "c". If you can't code your OOP in "c", it means you don't understand what "c++" is doing.

when the Linux kernel developers start using Visual Studio. Until then, I'm sticking with vim.

I agree with your comment. Everything you need to learn programming is readily available on the Web, including reams of source code from open source projects. The real issue is, given modern software tools, there is little need for "warm body" coders who do not also understand computer science. Gaining a working understanding of computer science is an enormous endeavor, and no 16 week boot camp is going to help much. If you did not demonstrate aptitude for math and science in school, your chances as a coder are slim. If you aren't willing to dig deep and put in tons of time, you are unlikely to find a job coding.

OS kernels are still all written in 'C', even though they must be orders of magnitude more reliable than applications, and very efficient. Perhaps the best way to improve the reliability of software is to first evaluate the most reliable software.

Bad programmers will write buggy code in any language. The idea that a programming language can prevent the programmer from doing counterproductive work is simply bogus. In my own experience I've found that am something like 3x to 5x faster coding robust object oriented projects in plain C than in C++, though I have been coding in C++ since 1992 (C since 1988).
It takes about 20 years to gain a reasonably comprehensive knowledge of what can be accomplished with the primitives available in 'C'. Adding more primitives (C++) creates more ambiguity (especially #$%^& templates) and slows down the process of understanding somebody else's code.

I am happy to pay a fair price for content, but am unwilling in any scenario to be subjected to invasive advertising. Netflix is a good example of an ad-free subscription based library of video content.
One of the early promises of the Web was micropayments, remember that? It has yet to happen because the cost of a secure financial transaction is simply too high. I think the best answer is subscription aggregators, who provide access to a libraries of content and track which customers are accessing said content. At the end of the month, the subscription aggregator sends a single payment to each content provider, which represents the sum of all accesses that month.

"couldn't care less ..."
THANK YOU for saying what you mean to say, and not the opposite!

A few years ago I had an issue in a multi-threaded program where using printf()'s caused the problem to go away. In order to track the problem down, I ended up writing messages to a buffer in RAM, and dumping the buffer to stdout after the problem occurred.

Over my 30 year career, I cannot believe how many 'C' programmers I've come across who are unfamiliar with the assert() macro. This macro is essential for trapping all invalid assumptions! Usually it's as simple as:

if ( ! functionWhichCanFail(a,b,c) ) assert(0);

Run your program from the debugger, and it will stop when the assert(0) is encountered, giving you full and convenient access to everything needed to hunt down the issue.

Exceptions are possible in C. See the documentation for setjmp() and longjmp().

That said, exceptions are just "kicking the can down the road" for error handling. If a function call can fail, then you should check the return code. If you don't want to write with proper error reporting/recovery code immediately, there is always the assert() macro, e.g.:

if(func_which_might_fail() == ERROR_OCCURRED) assert(0);

If assert(0) gets called the program will stop immediately, and you can inspect the problem in detail with a debugger. Easy peasy.