Kind of, you are forgetting the startup that ETHZ sponsored with Component Pascal and the fact that Oberon (the OS) was actively used at ETHZ IT department, not only for teaching. :)
Apparently, it didn't lead to a sustainable business model. (Well, they seem to have made it work for a surprisingly long time.) But eventually the company abandoned the product and made it available for free: http://www.oberon.ch/blackbox.html
Also, I think there is still quite an active community around BlackBox in Russia. Unfortunately, I don't speak Russian and cannot really provide any links to their forums, etc.
That has been the problem with Wirth languages, he has written on an essay that he was kind of naïve to think that people would care for quality and flock to Algol derived languages.
The Russians are quite active in all Oberon derived languages, not only CP.
That's true, but my point is that for the official compiler (as opposed to Component Pascal) the justification for being strict in terms of keeping complexity low was different than it would be for a commercial compiler:
Wirth needed to be able to explain the entirety of the compiler to students more than he needed it to generate the fastest possible code.
(That said, several of his students have written papers on adding various optimisations to the Oberon compilers, with good results)
While I am a big fan of Oberon, and Wirth ideas, I think the best design was the Active Oberon one, but Wirth had not much to do with it.
However Oberon-07 is a very good approach for a systems programming language, with GC, targeted at low end devices, pitty that other than Astrobe, it is largely ignored by the IoT hype.
I've never liked Active Oberon, because it doesn't feel like a Wirthian language anymore. It tries to be simple by adding just one concept, the "object", but it's a huge and complicated concept that conflates data, algorithm, concurrency, and synchronization. It's much more complicated than anything else in the language and it duplicates parts of the record and procedure abstractions.
I think the designers of golang followed a more Wirthian approach with goroutines and channels, because those are orthogonal extensions to the rest of the language, and they each have a single well-defined purpose.
I wasn't aware of the other improvements. Thanks! I agree that interfaces and untraced pointers / resources are good and useful.
I haven't quite decided yet on annotations. I'm assuming you mean things like {ACTIVE} and {EXCLUSIVE}? {EXCLUSIVE} is probably nice to have because you can't forget to release the lock. I'm less convinced of {ACTIVE}.
