[eternalban]

> Whichever way you want to look at it one thing the Go team can't say is that writing an OS is a "non-systems" problem.

I do agree with that. (Perhaps it would be helpful to apply the high/low qualifier to systems languages?)

> Ideally these would be disjoint sets (in my opinion) but consider this: ASM -> C -> C++ -> Java -> ... looks like a continuum if you're writing any kind of Java code, but there's a sharp discontinuity in there if you're writing (say) a boot loader.

Food for thought. I am not arguing for needless complexity (in a language) as far as the boot up phase is concerned. As far as I understand it, the loader has its critical, but short lived, life-cycle role to play and then it is out of the way. Arguably, it is distinct from the OS. Can we not continue to write them in ASM/C and load operating systems that are written in a more "modern" language?

[smosher]

Personally I'd sooner map the somewhat fuzzier concept of "applications language" onto that supposed continuum instead. It would put Go in a clearer category, since it seems to compete with Java and Python better than it does with C.

I still don't imagine an OS being written in a non-systems application language, since you've got drivers and performance critical subsystems to write and things like GC to worry about from the apps-only languages.

[pjmlp]

Have a look at Spin or Native Oberon, just to name two operating systems written in GC enabled languages.

Before C existed, there were already operating systems written in PL/I and ALGOL, which provide better type safety and memory management as C or C++.

Unix and C success has regressed what meant to be a proper systems programming language.

There is even a paper from Adele Goldberg about this phenomena, unfortunately I cannot recall the title now.