Re: the C code, Emacs will happily let you ignore your own config settings. Just turn off anything labeled "electric" and nothing will happen automatically. And don't press tab, that will reindent the current line.
You definitely needed to be on evil-mode or a framework (like Doom) based on it. The key bindings with ctl, alt, etc. are the least important part of Emacs but sadly, the part everyone thinks of first...
This really captures the power of Emacs for people with Lisp skills. For coders with strong habits of high-level thinking it's a real force multiplier. Why shouldn't we apply the same analysis and effort to our productivity tools we do to our "output"?
It is probably easier to write correct concurrent code now, thanks to the new features he mentions. However, as always plenty of rope is provided, and the old programs are still valid (and have the same semantics). I couldn't say how it compares to Rust, but "better now" seems pretty accurate.
Git submodules work pretty great for this IMO. Rather than incorporate a snapshot of the source, pick a commit hash. Still frozen at a point in time, but you get to move which one you're using (or point to your own fork!) whenever you like.
I doubt anyone is willing to pay 2x performance for their C code to be more friendly. If they were, why are they writing in C?
To me this is the fundamental issue with the friendly/boring C proposals. The whole reason to use C/C++ anymore is for performance, in return for which you are responsible for certain things - like using only defined behavior.
If you are writing e.g. crypto code, why not use a higher level language that provides more checks and guarantees, and is generally easier to reason about? Or segregate the performance-critical "engine" type code into C++ and use something higher level for everything else?
I do love war stories, but I think the OP has missed something:
After the meeting one of the managers told me that it was really our job to come up with projects that the customer wanted to buy, not the other way around. And it usually couldn't just be a general project for minor improvements, it'd need clear and ideally measurable goals
I think the OP has misunderstood the nature of consulting. This is exactly what needs to be done to convince X to spend some of their cash on having Y do work for them. You need to make a business case, with concrete duration, cost, goals, and benefits. That this system is a mess is really not in dispute by anyone... but no one will pay to improve it "just because".
Because properly handling overflow if you're using signed values involves UB, it's super hard to get it right. Even Apple has struggled with it: http://www.slashslash.info/2014/02/undefined-behavior-and-ap...
If you get it wrong you can also see your program's behavior change with the compiler optimization level, which is incredibly frustrating (and causes a lot of "the compiler is buggy!" beliefs).
For anyone who is curious about the intended use of exceptions in C++ I recommend Jon Kalb's two-part tutorial on exceptions from CppCon 2014. First video is here: https://www.youtube.com/watch?v=W7fIy_54y-w
Compiling with exceptions turned off is highly unusual. If you do that, you're not really writing C++ anymore, as it's a fundamental part of the language. Exceptions are the mechanism provided for indicating that it was impossible to construct an object, and to trigger appropriate cleanup actions.
I'm curious about that last bit. I occasionally hear this argument that size_t being unsigned is a bad thing. Presumably the standard library designers would claim that a size cannot be negative, so this is appropriate. Why, in your view, should that be a signed quantity?