This is so wrong on so many levels... Don't listen to this guy.
C is useful to learn, but it's essentially a glorified cross-platform assembler, not much else.
essentially a glorified cross-platform assembler, not much else.
You are a fucking idiot. I can return the "This is so wrong on so many levels... Don't listen to this guy." assessment right back at you right here. You're obviously biased against C if you try to downplay it that much.
If anything, higher levels of abstractions, automatic memory management and safe language semantics (e.g. avoiding mutations and manual handling of concurrency) results in fewer bugs, not more.
If you're manually handling shit, the bugginess is obviously contingent on how well you write your code. If you are shit, it's tons of bugs. If you are properly good, zero bugs. Relying on automatic garbage collection (ie. regularly scanning memory for what's no longer being used and removing it) is easily inferior to manual memory management when it comes to efficiency because with manual memory management you tell the program to remove the memory the moment it is no longer used instead of having a garbage collector (which is in and of itself overhead) and waiting for it to get around to it (until it does, the memory that outlived its purpose sits there, wasted), and not understanding memory management is a great way to get memory leaks. Certainly, if you never aspire beyond mediocrity, you will praise all the handholding convenience you can get. Regardless, my point is only that
learning by relying on crutches to handle problems for you results in writing shitty code. The problem isn't that you
have to do shit manually, but that you
should understand how these things work so you can keep that into account when you write code, or you
will end up writing shit logic that is buggy and inefficient.
I'm not saying you have to program in C either. Only that it makes a better starting point since it forces you to learn and engage with a lot of things that higher level languages do not. If you do not see the value in that, that says a lot about you.
Some higher level language constructs are almost impossible to handle correctly with manual memory management (e.g. closures). But even with complex object graphs, you will eventually end up writing your own half-assed GC algorithm that walks the object graph etc.
This is basically whining that lower-level languages are bad because they aren't higher-level languages. You do shit differently in C. If you want higher-level bells and whistles on top of your C, go write C++. lambda support is right there. Or use some other language if you love automated garbage collection so much (which is frankly overrated and in C++ you can just use RAII), knock yourself out. But if your complaint is "I don't like writing C-style logic so when I try to hamfist methods from higher-level languages into C it gets awkward therefore C is a shit language" then that says more about you than C. Right now you basically went into the realm of bitching that C is not an object-oriented language as a reason why C sucks, and odds are your problems originated with you learning shitty habits in a language that isn't C and being unable to break them when you started writing C and trying to force those concepts into it.
So no wonder you hate C so much and rage that it's just a "glorified cross-platform assembler" (as bone-headedly wrong as that statement obviously is). You obviously had shitty experiences trying to use C with programming concepts C is not designed for.
Ideally, you'd learn C just to have an idea about what the machine is doing, and something high level to know about the possibilities.
I actually agree with this, except I'd like to note that C is in fact a high-level programming language. It's just that compared to the ridiculously high-level languages that are around nowadays more recent programmers have taken to calling it a low-level one. Certainly, compared to most of what is used now, it is on the lower-level side of things, but strictly speaking "low-level" refers to assembly and the like.
The order doesn't really matter, but I'd say go for the high level language first, like Racket (it will be much more fun, and if you end up just learning a single language, it's better if it's a high level one).
I'd say the order obviously does matter. Case in point: You. You clearly started on a higher-level language and then got frustrated moving to C where you had to do things more manually. It's better to work your way up from C than the other way around.
Also, "game engines" is a big topic. AAA rendering engines, yes, they are written in C++ (because of industry inertia and a lack of vastly better alternatives, not because those devs all really love C++). But for non-AAA games, especially if not 3D, I'd say C/C++ is overkill nowadays, you're just complicating your life for no real benefit.
Nice attempt at shitting on C++. There are real reasons why people prefer to program game engines in C++ though. In particular, it's good at mixing lower-level and higher-level methods of doing things, which is fucking important because in a game engine there are plenty of times when you need a segment of logic to run as fast as possible (because performance matters in videogames and the difference in efficiency can be massive when you manually optimize) and other times when you may prefer high-level features.
But it's true that if performance is not a concern you can do fine without using C++.
Anyway, Rincewind is obviously biased against C and C++ and has likely had poor experiences from trying to use them the wrong way, so take his comments on this topic with a solid grain of salt.
In my view you got things mixed up and actually I'm the level headed guy who's saying C/C++ has their place, even though they're a bit shit 
