My very controversial opinion is that C is obsolete for new programming projects. For example, everything that C can do, C++ can do and better/safer/faster. Rust is also getting there (if not there already). C is not Pareto optimal anymore.
Rust (and collectivelly all languages that claim to replace C, or just have a significant cult following insisting that everything be rewritten in them) are fine languages on their own merit but I can't see them replacing C any time soon. The main problem with these is that they were designed by people who don't like C. People who do like C would probably love a "safer" alternative to it and similar to it, but languages like Rust just aren't appealing for the same use-cases. The only language that kind of works for this is Go, which was written by people who, on the whole, do like C.
You can also find examples for the other way around, too: Web browsers are all written in (mostly) C++ for example.
Games are another example. John Carmack also admitted that switching from C to C++ was the right thing to do for Doom 3:
"Today, I do firmly believe that C++ is the right language for large, multi-developer projects with critical performance requirements, and Tech 5 is a lot better off for the Doom 3 experience." http://fabiensanglard.net/doom3/interviews.php
> Top 4 kernels are written in C: NT, Mach, Linux, BSD.
Parts of NT are written in C++ btw.
1) It is doing a disservice to the students to tell them that you won't use much of what you are made to learn.
2) A nontrivial amount of people will attempt to use it seriously anyway, sometimes with disastrous results.
3) It usually indicates teacher laziness and/or disinteredness in finding alternative ways to teach.
4) Surprisingly often, when you are not supposed to use X, it is actually useless to learn X. (That is NOT the case in this situation -- there are reasons to learn C -- but the students can't know that unless told so.)
5) There are almost always better alternatives. I have never been unable to find a Y which fulfills the same criteria as X, yet in addition is also usable for serious things. It's just that sometimes you have to look a little harder for it.
In other words, I think it is a teacher's categorical responsibility to find a means to teach what they want in a way that is practically applicable by the students right away. And failing to do so should be taken as a strong hint that what they want to teach may not be the thing they should teach.
I wouldn't say this if I didn't firmly believe that you can teach most things in a way that grants the student immediate practical applications. And I don't say this in a political way -- of course everyone should have the liberty to teach whatever useless thing they want in whatever shitty manner they cn come up with. I'm viewing it more as requirements on any teacher who wants to call themselves good, or tell themselves they are doing their students a service and improving mankind.
Rust (and maybe Go) do seem like very good long-term replacements for C, but imho it's too early to say that. Until there's a "full stack" of software (OS to user-space/desktop), you still kinda need to know C if you want to be able to understand how your whole computer works.
AFAICT, Rust was created to be a safer C, and Go was created to be a faster Python; completely separate domains.
That would surprise me; Go has little in common with Python.
But also because it makes it easier to deal with asynchronous actions and has facilities for higher level programming should there be room for it.