My introduction to C++ was C++ Builder, Turbo Pascal's spin off. It great for making desktop apps. I was horrified when I started using Visual C++ how unconnected and hard work it all was.
FWIW i had similar thoughts about Qt some time ago. For background, I do a lot of desktop stuff in Lazarus (which is very similar to Delphi but cross platform) so i have experience with that. At some point a few years ago i got a job at some gamedev company that used Qt for their tools and i was working on those. I remember spending a lot of time writing boilerplate code that Lazarus would do for me instantly or how some things felt more involved compared to how it was with LCL (Lazarus' framework).
One situation that stuck in my mind was when i used a separate program (Qt Designer) to create some UI for a custom panel in the editor and was writing both code to make the editor see the panel and wiring event handlers by hand, all the time feeling miserable thinking how Lazarus would do that for me without even needing to write any code so i could focus on the actual feature instead. Qt Designer feeling alpha software at best (it was buggy and otherwise trivial things like moving some controls to a new empty parents was hard to do - in comparison even wxFormDesigner, which i had used at a previous job where the engine there used wxWidgets, would allow you to do by drag-and-dropping and even scaled up the containers to make them easier to target).
I never used C++ Builder professionally but i do have a copy i bought off ebay some years ago and played around with it making a simple 3D mesh editor[0] and dungeon editor[1], among other things. I do wish i could use VCL in C++ projects, but i'd never recommend it these days considering how Delphi is treated by Embarcadero (stupidly high prices), let alone C++ Builder that always felt like a second class citizen - and TBH i'm not very keen on recommending a proprietary framework anyway.
I've long decided that the best you can get with C++ these days is Qt Creator.
The link is about the assembly details of the compiler code. But that still misses the point in a few important ways. And I'm not talking about the Turbo Pascals with the numbers 5 or higher, but about the first ones actually used, like the one for CP/M where the OS and the program all have to fit in 64 K. Turbo Pascal was more than a compiler fitting in that space: it contained editor, kept the source of the compiled program completely in RAM, and produced executable with one write to disk and just a few reads.
1) The fact that the author was very used to think in assembly is that he was able to generate a compiler to the native code that even without optimizing passes already "well behaves": not squeezing every drop possible for optimization but also making a lot of optimization passes not necessary. That's the "magic sauce" in being what was called "a single pass."
2) Description "a single pass" is actually somewhat imprecise when used by most who talk about it. The passes through something are necessary in compilers, the actual goal is making once the processing on the levels which hurts the whole compilation process the most.
3) So the major difference between the typical "production" compilers and Turbo Pascal was in later being able to fit "everything" in the RAM between the last edit and the production of the compiled code. If I remember correctly it didn't even have to write anything to the disk if one just needed to run the program(!) Only when one needed the executable the write happened.
So assembly was an important part of the story but at the time most of the professionals used assembly anyway, the speed vas result every other decision was also made to achieve minimal I/O (which also wasn't necessarily unique feature) while also being useful enough for the real programs (that was less unique) and comfortable (Wordstar-keys editor, jump to the error after compilation).
A lot of very good decisions combined, that was special. And finally, comparably cheap, too.
