This all is very interesting, but how do you write to/read from an absolute memory location and/or HW port ? Without being able to do it you can't write a device driver and hence an OS kernel.

Maybe this indicates a difference in our idea of what "system programming" is. But I think type strictness is a poor feature for a system programming language.

For OS's (and similar style projects) inheritance (including multiple inheritance) is a very useful feature.

You frequently have a structure X, part of which is a sub structure Y. In system programming (as in many other kinds of programming) you often what to be able to access members of Y using a pointer to X without the distraction (or maintenance problem) of specifying that those members are in the Y part of X.

In system programming (much more than in other kinds of programming) you often want to use a pointer to Y combined with outside knowledge that this particular Y is specific substructure of X, and from those compute the pointer to X. In C++ if that Y is any base class of X, you just static cast it. In C or C++, if Y is a named substructure of X, you can use some ugly address arithmetic and casting to get the X pointer. In C++ you could cleanly hide the ugly parts of that in a template. In C, you would need a less clean macro to hide the ugly parts.

Templating is a powerful feature in system programming. In what I called "extreme C programming" above, one tends to use a lot of macros for things that should look and act like functions, but need some flexibility or efficiency that a function can't provide. In C++, you almost never need to use a macro for that. Instead you use a template. The general advantages of templates over macros for such purposes are too varied, large and significant to do justice to them here.

Polymorphism by virtual functions are also a powerful tool for system programming that is syntactically clean in C++, and needs a syntactically ugly "roll your own" approach in C.

At the lowest level of that kind of thing, there are always a few stubborn spots where you need to drop to assembly code.

C and C++ have more flexible pointer type casts (than most languages), which eliminates a few places where you might have needed to drop to assembly. Gnu extensions to C and C++ also have powerful syntax for dropping to assembly level inline, rather than calling a function written in pure assembly.

Those are convenience features of C and C++ when coding an OS or a device driver. But ultimately, most of an OS or device driver is higher level code and doesn't need that. If some other language needs to be supplemented with a few pure assemble functions, that doesn't make it a bad system programming language. (If it can't even call pure assembly functions, that does make it a bad system programming language).

We have already discussed this to death, but templates are essentially undebuggable because C++ standard does not prescribe any means of debugging them. IMO undebuggability of templates is a great feature for C++ programmers job security, but it's a different issue.

OTOH, type strictness in general allows to catch more errors at compile time.

First, please understand that my comment was NOT a recommendation of a language to be used for an OS project. My point only was that your choice of language was almost irrelevant: almost any language could be made to work - with enough effort.

That being said, data "type" is inferred from the type of data passed to the function. Consider the example in my post: The factorial function "fact" was defined as a simple recursion. Then it was passed the first ten integers, and the values collected in a vector that was printed. I then passed in a "bigint" value (100L) which has a much bigger range that a simple int, and the function used, and returned, a "bigint" result.

One can define functions with different actions for different types of arguments. (The "::" qualifier is used for this.) For example:is a fragment from the multiple precision floating point library definition of the mpfr data type, where this part is describing the conversion to mpfr values of various standard data types. (Oh, it may be worth noting that this library is just an interface to the standard mpfr library, and the, e.g., mpfr_from_double, etc., functions are just pointers to (or, if you wish, calls to) the library functions defined (in part) like this:From this you can see a suggestion of how pure could be used with pointers to specific memory locations.

Oh, F.Y.I., pure is available in the Fedora repositories as an RPM. (Well, the Fedora 19 repo - I haven't checked the older ones.)

Is there anyone still running a Lisp machine? The impression given by the wiki article is that the last attempts died out in the 80s.

I think a Lisp machine would be cool if there was one that could be used remotely, or one that I could afford to buy.

From the above examples I see that the language can have "C" stuff bindings. I do not see a way to use pointers pointing to an absolute location directly in the language.

There are languages (e.g. Modula-2, probably Modula-3) that do have pointers. In Modula-2 there is a special module (IIRC called "System") for the "dangerous" stuff related to untyped direct memory access.

Going back to the original question...
...and trying to be a bit realistic I would say as well "C++" and nothing else.
The requirements of "low-level" and "incredibly portable" might be a conflict and you probably cannot have both. Maybe the understanding of "low-level" is different from person to person... .

Does the alternative language have to be one that already exists? It seems to me that the OP is asking essentially the same question Dennis Ritchie asked himself when he crafted his solution to the same problem. Being the adventurous sort in these kinds of things, I'd be tempted to follow Ritchie's lead, and try to write my own. I'm not as smart as he, and have too much C in my DNA to come up with anything that would be a significant departure from C, so I'd probably fail. If I could hire someone to accomplish the job for me, the spec would probably look a lot like C, but with a small-ish number of runtime safety nets built in, such as null/uninitialized pointer dereference checks, array bounds checking, etc. I might be tempted to make these optional at compile time, so many pointer bugs can be quickly killed, and the resulting code optimized to not include the safety nets. I'd probably make it have the ability to specify unambiguously how primitive data types are arranged, and how they behave, and their sizes. The idea would be to make the data types exactly match the target native architecture. This probably flies in the face of portability; see, I told you I wasn't smart enough to get it right.
I wonder if anyone else can add to the shopping list...

--- rod.

Just a comment: think about Commodore 64 or ZX Spectrum, you can now simulate all those things and you can write that simulation in (almost) any language you want. So you can implement those OSs for example in MS Visual Basic...

Hold on, there. A lot of languages rely on services provided by the OS's on which they run. Extrapolating from a simulator running on an OS, to an actual OS seems like a huge leap. I don't disagree that some languages (Forth, as mentioned earlier) are capable of producing/becoming an OS, but Visual BASIC doesn't seem like on of them.
Sun workstations used Forth for their bootloader/ROM monitor. From that, I conclude that it could probably have been expanded to be a full-on OS.
--- rod.

Show me how in Visual Basic you read a disk sector. You don't have an OS yet, i.e. for ypur point to be valid you need to be able to do this not performing any system call.

Also, show me how in Visual Basic you perform task switching.

Hey Sergei, why did you take it so serious? C64 and the Spectrum was not able to perform task switches and there was no disk to read those sectors (just some serial-like i/o line). So if you want to think about my post just please define what does really the word OS mean? And those simulators exist and able to run those quite old programs....

https://en.wikipedia.org/wiki/Operating_system .

If you really want to follow Ritchie's lead, I'd suggest starting, as he did, with B or BCPL. But it is a non-trivial task.

What?! Heavens No!. I'd write an assembler in machine code toggled in with switches, so I could use the assembler to write a compiler! In the cold. And wind. Up hill. Both ways...

--- rod.