Re: Microsoft should improve its recruting procedures...
> A lot of time and and a lot of changes have been made from the first implentation of C++. Do you believe an old, simple implementation could still work?
(NOTE I have cut out "and any OO language" from that quote, and will say why soon)
Yes. For "modern" C++, yes, I definitely do believe "an old, simple implementation could still work" because, ta-da, it DOES! The VMT is still there. What do you believe has changed?
For "any OOPL" - yup; the other OOP mechanisms still work. Why would message-passing, the other Great OOP Way, have broken? Please provide some examples, 'cos I am *always* happy to learn about programming language internals (preferably not just more irritants caused by ambiguous syntax, 'cos that is important to let people write unambiguous code but isn't really novel, just overly complex sticking plaster over features that just growed).
> for the simple reason that writing an OO compiler is far more complex
No, it really isn't. Templates are *much* harder to get right than C++ style statically bound objects, and polymorphism is just syntactic sugar, not much harder than other sugar like the "for" loop. Injecting constructor/destructor calls needed a tweak to the linker, to handle initialisation of static instances (for early compilers).
Exception handling is a separate issue - it interacts with destructor invocations because it needs to have an unwind stack for the exception handler to walk. Getting the kinks out of the mechanisms took work for the C++ guys to get right *BUT* that has all been sorted out and the mechanisms published - including how it had problems interacting with iritants that arise from the fact C++ still supports C'isms that let you bypass the proper stuff.
> How do you handle C++ exceptions in Rust
Is there something especial in C++ exceptions, compared to other languages that provide exceptions? Ada, etc? Or do you feel that *any* exceptions mechanism is going to break Rust's memory ownership properties? If Rust *wanted* exceptions, it could have them. BUT would that be a good idea?
The choice to avoid exceptions in Rust was, to my understanding, that although languages like Ada provided them to "be good for critical military applications" experience with, bluntly, C++ code in the wild, demonstrates that that just ain't the case. The fact that any sane person could think that having a hash table trip an exception when it doesn't contain a key, instead of returning a null/false/nope entry makes it abundantly clear that milspec code must be kept exception-free.
Yes, obviously, translating C++ code that insists on using exceptions as a means of implementing the application logic into a language without exceptions is decidely non-trivial. As in, the only sensible way to do it is to clean up the C++ first. Which, if you want to use a machine to do the translation, means you need that as a clean-up first, before any attempt at translation. And that clean-up probably invilves getting in some really good human programmers. And probably means the translation, done well, is probably too expensive. But that won't stop idiots flinging LLMs at the problem, which will fail.
> I've seen many developers unable to graps OO
I'd put the lack of OOP being built directly into other languages onto that - people not wanting it, not grokkking it - more than fundamental difficulty of implementation. Assuming (yes, yes, big assumption) that, when you start your new language, you begin by learning *how* to implement a language, from lexers onwards, then statically-linked OOP is all well-defined, pros and cons. Just RTFM.
