Its C-inspired programming language is also pretty primitive. I'd much rather have seen it built around scheme, lisp, or even a modern statically-typed language like OCaml, Haskell, or SML.
Moreover OSes designed with higher level languages tend to end up in a very different place even if they start with superficially similar assumptions—compare for example the early Lisp Machine OSes with TOPS-20, or ITS. "Everything's a filesystem" tends to mean "everything's a stream of bytes", which is in some ways a defeat for strong typing at the OS level for all that it can be convenient. I know I've had to write text level parsers for things like the output of multipath -ll (which is not standardized and is intended for human readibility and so changes radically every now and again, but is still the best source of some of that data). Now with Plan 9's FS structure you can arguably turn tree-structured data into a filesystem with files as the leaves, but this doesn't generalize well to non-tree-structured data.
That said I really like the OS, and I'm even willing to admit that Acme is pretty good (just not to my Emacs-tainted taste). But I can't imagine what a relational DB would look like in that idiom, unless it's "SQL query as filename". Individual tables, fine, but joins? Transactions?
It's not meant to be built around any language. If there's a language you want to use, just start using it. All you need is access to the system calls. The whole point of making everything a file system is so that you don't have to cram everything together in the same address space. There's no foreign function interfaces or calling conventions you have to deal with if you want to use a new language with the system. It's all reads and writes. Ocaml, Haskell, and ML all have read and write, so if you want to use a less primitive language, there's nothing stopping you.
Nonetheless, I might try a vm of plan9, for fun.
Notes here: http://the.taoofmac.com/space/blog/2014/05/04/2230#diving-in...
http://en.wikipedia.org/wiki/Object_Manager_(Windows)
Try out WinObj.exe (Microsoft): http://technet.microsoft.com/en-us/sysinternals/bb896657.asp... (best with admin privileges)
eg, you couldn't use Notepad to edit those NT objects, where as you could with Plan 9's design since.
Some of them are the limited MAX_PATH, which is defined as 260 characters, reserved characters in file names, 8.3 filename aliasing (fixed), etc. - see: http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
Unfortunately, the Windows shell (explorer.exe/shell32.dll & cmd.exe) are more limited than what you can do with Win32API. One can access the NT object tree from C/C++
You can use CreateFile(), ReadFile(), WriteFile(), etc. Win32API function to work on NT objects (not just files but real NT objects, the name is just inherited from Win16API) - http://msdn.microsoft.com/en-us/library/windows/desktop/aa36... , http://msdn.microsoft.com/en-us/library/windows/desktop/aa36... , http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
Some NT path examples:
"\\.\PhysicalDrive2" ... opens third physical drive
"\\.\C:\" ... opens the file system of the C: volume
"\\.\COM1" ... opens serial port 1
"\\.\pipe\pipename" ... opens named pipe
"\\.\mailslot\sample" ... open mailslot
"\\?\UNC\server\share" ... opens universal UNC path
"\\?\C:\" ... opens C:, you can exceed the MAX_PATH limits
Instead of further improving Win32API, as they have done like ReadFileEx() (http://msdn.microsoft.com/en-us/library/windows/desktop/aa36... ), Microsoft toys around with several dotNet API layers on top of Win32API and now a WinRT API that stills sits on top of the Win32 subsystem. Windows NT would support several subsystems (like there are POSIX, OS/2, Xbox subsystems for WinNT/ReactOS).
Berkeley sockets introduced in Win3.1 for Workgroups and later as WinSocks for IE 1 (based on Mosaic) came late (Bill Gates vision was the Microsoft Network based on Win95 GUI, later renamed was MSN as dial-up network): http://en.wikipedia.org/wiki/Berkeley_sockets , http://en.wikipedia.org/wiki/Microsoft_Network#MSN_Classic
It's actually very beautiful. It's just so damned simple. Despite Plan 9's huge codebase, if you open an arbitrary source file, chances are you can read and grok it in one sitting.
It's shocking especially if you're used to the needlessly complicated modern codebases of today (particularly ones that copiously use GLib, D-Bus, etc. on Linux), but once the initial shock dies down, it's a breath of fresh air.