Comparatively to a modern Delphi/FreePascal it is just very limited. This might be what someone is looking for in that Pascal land but is not my cup of tea.
Talking about language obviously. Not the whole computer system
Talking about language obviously. Not the whole computer system
Search Joe Duffy's keynote at one of Rustconf, towards the end he mentions that even proven wrong with Midori running in front of them, the Windows team was telling him it wasn't possible.
By the way, F-Secure ships security keys with firmware written in bare metal Go.
There is actually already a GC which works well with C++ and is also used by some of the mentioned languages: https://www.hboehm.info/gc/. Personally I think the C++ specification is already far too big and complex (so why adding even more stuff). A lot of GC languages were more or less successfully used to develop operating systems (even Lisp, Smalltalk and Java). From my point of view Oberon is not particularly suited for this purpose, but obviously it was used to implement the Oberon system (using some dark corners of the SYSTEM module and undocumented language features).
And A2 is much more pleasant to use.
This is why it is my favourite version of Oberon linage.
Now it is mostly nostalgia, so it gets down to use Go, .NET Native, D, Nim, Swift, whatever, to reach similar goals.
As for C++ GCs, the approaches taken by Unreal C++, C++/CLI and C++/CX are quite alright.
However the whole language politics at Microsoft seem to have placed C++/CLI and C++/CX on the extinction path, and C++/WinRT is surely not a replacement for anyone that enjoys productivity over a renewed ATL experience.
"Insight ETHOS: On object-orientation in operating systems"
http://dx.doi.org/10.3929/ethz-a-000666071
Scattered across the sections there are some remarks on some of the issues that lack of untraced references, or the existing finalization mechanisms were cause of attrition.
In Active Oberon those complains are no longer valid.
By the way, the author is relatively well know in research area nowadays.
Also posted it on HN today: https://news.ycombinator.com/item?id=27855767.
Currently the compiler generates LuaJIT bytecode (the VM is integrated with the IDE); a .Net CLI backend is work in progress, and an LLVM version is planned.
Apparently many forget C was on that role as well.
> At some level they all rely on massive libraries written in C
What? How does your "C++ product [that] does not use a single explicit allocation" actually manage memory?