> If this is true, there is nothing that forces you to write classes in C++. You have all the freedom to write only in functions and structs.
Functions and structs is not much freedom. But you're quite right: nothing forces you to write in C++.
> I think C++ is not going "to go" anywhere and is here to stay for a long, long time, and have it's place in programming language "pantheon" similar to C.
Sure. Or COBOL, or any other number of languages in which massive legacy codebases have been written. At best, one avoids them in their own work.
> Restrictive language is a good way of preventing bugs, but in C++ you can just select what language features you are gonna use and have similar result.
Even when you whittle down the feature list far beyond what you can still reasonably expect to be even remotely productive with, simple matters like uninitialized variables can still go uncaught if your compiler can't catch every single use case and you don't wade through a slew of false positives with maximum warnings and warnings as errors. One is forced to use time-expensive static code analysis, enforced by CI build process, to begin to even remotely approach the general runtime safety of something like C#.
These options are extremely useful when you're stuck with a C++ codebase, but I wouldn't describe it so casually, as if they were quick and simple to implement and enforce.
Functions and structs is not much freedom. But you're quite right: nothing forces you to write in C++.
> I think C++ is not going "to go" anywhere and is here to stay for a long, long time, and have it's place in programming language "pantheon" similar to C.
Sure. Or COBOL, or any other number of languages in which massive legacy codebases have been written. At best, one avoids them in their own work.
> Restrictive language is a good way of preventing bugs, but in C++ you can just select what language features you are gonna use and have similar result.
Even when you whittle down the feature list far beyond what you can still reasonably expect to be even remotely productive with, simple matters like uninitialized variables can still go uncaught if your compiler can't catch every single use case and you don't wade through a slew of false positives with maximum warnings and warnings as errors. One is forced to use time-expensive static code analysis, enforced by CI build process, to begin to even remotely approach the general runtime safety of something like C#.
These options are extremely useful when you're stuck with a C++ codebase, but I wouldn't describe it so casually, as if they were quick and simple to implement and enforce.