Systems programming in languages other than C?

Simple question. What is the latest research into doing the sort of tasks usually done in C/C++ with something else? I'll list three areas I think are important.

1) Ability to interface directly with hardware (i.e. can you write an OS in it)
2) Ability to create compiled binaries and both static and shared libraries
3) Modern features like garbage collection that don't slow the whole thing down to a crawl

I'm aware of OCaml, which seems to fulfill at least #2 and #3 and I know about the House project in Haskell. The latter seems not to have been worked on in about 2 years though. I also know about the D language which seems like a better C++ but not a real departure from what's been going on for 30+ years. More generally, is any significant research into radical new OS concepts going on and what sort of languages are they using?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Singularity Project

Have you seen the MS Singularity project?

Sounds interesting

I don't mean to sound harsh but, while there are some nice concepts there, I expect the results will just vanish into the black hole of their next version of Windoze. I'm also suspicious of the abstract instruction set thing. That means the whole system runs on a virtual machine so you're going to burn cash paying for extra clock cycles to support that. I suppose JIT could largely fix that though. Then you will have the usual MS bloat on top of that. Overall, it sounds like a great way to keep Intel and AMD share prices high. I'm more interested in languages that just compile down to machine code but without the Disco era quirks of C. I'm also interested in OSS, not giving Gates free labor.

Well if you're so set...

First of all, I've done some OS programming in Object Pascal using the Free Pascal compiler. Yes, it's easily possible. You just need to write a malloc for the System unit and fill in a bunch of dummy I/O functions that the linker removes as dead code later on. After that, you get OS programming with classes, exceptions, and dynamic arrays!

Of course, if nothing satisfies you, you could always throw your ideas in on my proposal.

Unfortunately, you do sound harsh

Unfortunately, you do sound harsh. I'd hope that we'd be able to discuss languages and related research in a civilised way here without gratuitous Microsoft-bashing (and I'd hope that we were all mature enough to avoid cutesy insults like "Windoze"). There are plenty of other forums on the web where you can take that sort of thing, thank you very much; I don't much care for it in LtU.

As regards Singularity, their language of choice (Sing#) is interesting in itself: contract-based (from Spec#) with the addition of message-passing channels to support concurrency. It supports low-level code generation while maintaining CLR-style type safety.

As regards that low-level code generation, CIL instructions are compiled at installation time with a portable compiler optimised for hardware-management code generation. The kernel provides GC and a managed heap, but otherwise the various bits of managed code end up running directly on the metal. It's a useful compromise between an abstract VM (making the development model simpler) and direct machine code execution.

Singularity does rely on an assembly-code interrupt manager; but its services are available to other components, allowing device drivers to be written in managed code, among other things.

And you just sound arrogant

There was nothing gratuitous or uncivilized in my post. I just don't have much interest in MS's model of development and said as much. I'll call Windoze Windoze if I damn well please. It's a common slang term at this point as every one knows.

Rants and bashing

I regard Wolf Logan's response to you as being to the point about both the substance of MS's singularity project, and about the non-constructive nature of the common "Windoze" slang term.

The various labs that make up Microsoft Research have been the source of much material of interest in programming languages, and LtU should be a place where these Microsoft researchers should feel happy participating. This is not because LtU takes any kind of stand against free software, but because LtU is above all a place that is about bringing attention to and discussing interesting material related to programming languages.

And there is relevant LtU policy:

6. Off-topic subjects The following subjects are considered off-topic:

(a) Rants and "bashing": In general, rants and "bashing" of corporations, languages, and paradigms is off-topic here. However, criticism that is relevant to the subject of programming languages is acceptable, if it is offered in a professional manner, with an appropriate amount of detail and/or references.


I agree with Chris and Wolf.

I'm not ranting

I made it clear that I felt there *was* interesting research going on there. I even pointed out that JIT could eliminate most of the performance hit from the VM. I was speculating, however, about the likely future fate of this research given what I know about MS in the past. Since my interest in this topic has to do with the future trends in OSes and systems languages and not particularly with any desire to make my own OS I feel such speculations WERE very much on topic. Apparently, such futurological musings are not welcome here.

Who knows what will become of singularity?

Like many industrial research labs that have come on gone; being studied by MS Research doesn't mean that a given technology will be productized. I don't like MS all that much either--mainly for their behavior as a business entity--but that doesn't mean that their research efforts, many of which are excellent, should be ignored or dismissed.

I have no idea what will become of Singularity. It may form the core of some future OS offering--goodness knows MS needs to do something different, as the monolithic OS market is in grave danger--at some point the OEM bubble will burst and then what do you do? It may remain in the labs, interesting technology but not become productized. It may become part of a MS product offering, but not be the core of one. The underlying technology may be productized by someone else.

On the contrary, musings are

On the contrary, musings are the point of much of LtU; nobody objected to your original question regarding non-C operating systems.

As others have already stated, there are certainly a variety of OSs not written in C. I might take the opportunity to point out that, of course, what language a thing in written in has little to do with how close to the metal the end result is executed. This is why we have JITters, and why such things as the Dynamic Language Runtime are interesting in their approach in taking traditionally interpreted languages and allowing them to exist in a realm where their programs may be piece-wise compiled.

Lisaac and Ada

Well, there's always Ada which fits your 3 points.

I've heard about Isaac but I don't know if it has GC (I don't like much its syntax myself byt YMMV):


The thing about Ada is that's it's a fairly old language (I was wondering about the bleeding edge stuff mostly) and it's been pigeon-holed as an American DOD fetish, mainly because it largely is. It's really too bad though that Ada didn't come along just a few years earlier, as I think we'd now have all our system software written in it.

Ada is continuously being

Ada is continuously being updated. They recently released the spec for Ada 2005, and the GNAT gcc compiler supports most of it already IIRC.

Keep in mind that Ada

Keep in mind that Ada implementations do not have to provide GC.

Well, don't some?

I was looking at this a while ago. Everyone says the Ada spec allows for GC to exist, but it doesn't specify a GC. I saw a few sites that talked about extensions to certain implementations of Ada to support GC.[1]

Also, there is apparently an Ada on JVM implementation that uses Java's GC.


Limbo is another

I think limbo meets all 3 criteria.
I'm not sure it's modern though. 1995 was a while ago.
it was used to write inferno

Oberon/Oberon2 was used to write several Operating systems.

and of course Bitc eventually.

D anyone?

The things I've tried so far in D indicate that it fulfills all 3 requirements. Further, it has some nice things like templates finally done right, some type inference, delegates, complex and imaginary (separate, that's right) numbers, and linking with C, and with C++ to some extent, and other features.


D is quite nice. I have it installed here along a zillion other languages. It really does seem to be "C++ done right". I guess I was just interested in finding out how far "out" you can get with a language and still be able to write a network card driver in it (that remains responsive of course). I'm interested in whether there's something fundamental about C and C derived languages or whether it's all just arbitrary. What do aliens write their OSes in, that sort of thing.

D anyone?

The things I've tried so far in D indicate that it fulfills all 3 requirements. Further, it has some nice things like templates finally done right, some type inference, delegates, complex and imaginary (separate, that's right) numbers, and linking with C, and with C++ to some extent, and other features.

How about CL?

You could look at how a kernel is written in Common Lisp: Movitz. Satisfies (1) and (3) from your list, and (2), if you meant to say that it should be compiled to native code.


Very interesting. I'm gonna download this. Hard to beat the sheer coolness of Lisp.

Modula 2+ & Modula 3

Both where used to write OS's for DEC firefly

Or Oberon.

Or Oberon.


Have you looked at our BitC work?

I'll check this out too

Seems well documented too. I like that. Also the emphasis on being able to apply formal reasoning to OSes seems the right direction to go. I liked that emphasis in Haskell. My main criticism is that rsync is a bit user unfriendly and there don't seem to be tarballs or anything else to download. Also the current code doesn't compile (Linux, AMD64 dual core) Go Hopkins BTW, my mom used to work at the JHU hospital.

Preparing a release this week.

Preferred mechanism is actually to pull via mercurial these days. The rsync thing is just a way to guarantee a clean tree. We're actually prepping a pre-release this week, so the ease of access situation is about to change.

Compiling bitC

I just got what I think is your latest release via rsync (I don't have Hg) It needed a couple dependencies I didn't have that the configure script didn't tell me about. They were the ici stuff (uchar.h) and the Boehm gc package. Also I had to symlink x86_64 to the i386 directory to get it to find mkclosure.c. Compiled alright after that. This is on an AMD64 of course.

That symlink won't work. We

That symlink won't work. We need to implement make_closure for x86_64. As of right now it's all i386 only. Hopefully fix that this weekend. Other fixes are in progress, which is why the release hasn't happened yet. Always good to have your feedback, though.

Just an update on this

As with any release, there is always a laundry list of open issues that you race to close before the release. We've had some significant issue resolutions in the past few days. Given that they don't look hard, the plan is now to implement some of those before the release. So it will be a few weeks more.


I think Cyclone meets your requirements for a language.
  • Cyclone is like C: it has pointers and pointer arithmetic, structs, arrays, goto, manual memory management, and C’s preprocessor and syntax.
  • Cyclone adds features such as pattern matching, algebraic datatypes, exceptions, region-based memory management, and optional garbage collection.
  • Cyclone is safe: pure Cyclone programs are not vulnerable to a wide class of bugs that plague C programs: buffer overflows, format string attacks, double free bugs, dangling pointer accesses, etc.
As for interesting OS concepts, I liked Synthesis: An Efficient Implementation of Fundamental Operating System Services .
This dissertation shows that operating systems can provide fundamental services an order of magnitude more efficiently than traditional implementations. It describes the implementation of a new operating system kernel, Synthesis, that achieves this level of performance. The Synthesis kernel combines several new techniques to provide high performance without sacrificing the expressive power or security of the system. The new ideas include:
  • Run-time code synthesis --- a systematic way of creating executable machine code at runtime to optimize frequently-used kernel routines --- queues, buffers, context switchers, interrupt handlers, and system call dispatchers --- for specific situations, greatly reducing their execution time.
  • Fine-grain scheduling --- a new process-scheduling technique based on the idea of feedback that performs frequent scheduling actions and policy adjustments (at submillisecond intervals) resulting in an adaptive, self-tuning system that can support real-time data streams.
  • Lock-free optimistic synchronization --- is shown to be a practical, eficient alternative to lock-based synchronization methods for the implementation of mulitprocessor operating system kernels.
  • An extensible kernel design that provides for simple expansion to support new kernel services and hardware devices while allowing a tight coupling between the kernel and the applications, blurring the distinction between user and kernel services.
The result is a significant performance improvement over traditional operating system implementations in addition to providing new services.

Run-time code synthesis ---

Run-time code synthesis --- a systematic way of creating executable machine code at runtime to optimize frequently-used kernel routines --- queues, buffers, context switchers, interrupt handlers, and system call dispatchers --- for specific situations, greatly reducing their execution time.

Now that's damned interesting! :) An OS that self-optimizes at run-time.

That's a cool reference.

That's a cool reference. Thanks! These days, though, it looks like the task of getting another OS up and running - I mean with adequate functionality to interest people - seems like a daunting task. Do you think there is an incremental path to getting these concepts down into current OSes such as linux?

Virtualization helps

If you have early support for running another OS in a sandbox, then maybe you don't need the exhaustive feature set. If you provide features in your OS that require system-wide architecture - data privacy, safety, roll-back ability, or the optimizations mentioned above - then maybe you can attract the community that will be needed for a more complete OS.

(Edit: In case it wasn't clear - while you asked about migrating e.g. linux to a new architecture, my response is just about an evolutionary path to a new OS.)

Issues with Cyclone

It's valid to ask: "why did we do BitC given Cyclone". The answers are that Cyclone has some difficulties with exact data structure representation (fat pointers), and it doesn't have a formally specified semantics. BitC, of course, doesn't have a full semantics either. The difference is that we understand BitC well enough to have a hope of specifying one. We hope. :-)

A more serious issue with Cyclone is that it guarantees dynamic safety rather than static safety. When your pacemaker halts because null pointers are bad for you, how much comfort will that be?

Null pointers

are impossible in bitC I take it? Sounds like you have a static typing system like Haskell.

some interesting ideas in TUNES

Some interesting ideas have been discussed at length on TUNES website (but not much has been implemented).


Didn't IBM use PL/I for systems programming? And a variant, PL/0 was used on the Space Shuttle iirc.

IBM's PL/I dialects, HAL/S

IBM's PL/I dialects include the following:
PL/S - Programming Language for Systems
PL/AS - Programming Language for Advanced Systems, an enhanced PL/S
PL/DS - Programming Language for Distributed Systems
PL/X - Programming Language eXtended, an enhanced PL/AS
PL.8 - a PL/I derivative developed at IBM Yorktown and currently used for Z series firmware. It consists of about 80% of PL/I.

Bitsavers has several PL/S manuals and the others are described in the IBM Journal of Research and Development.

HAL/S, which is used to program the Space Shuttle's AP-101 computers, is an XPL derivative. XPL was defined in A Compiler Generator by W. M. McKeeman. Gary Kildall's PL/M is another XPL descendant.

Bitsavers also has a manual for HAL/S.

PL/I - used for Multics

The Multics system ("", "") was programmed in PL/I (and a bit of assembler). It was one of the first OSes programmed in a high-level language of any kind, and remained in commercial use up until 2000. Also, many design ideas which ended up in Unix started in Multics (since the Bell Labs researchers who created the original Unix had been on the Multics project).


There's also Osker in Haskell.

Nitro (a recent PhD dissertation)

I found the following interesting: Thesis Proposal Nitro: A low-level functional programming language

Unfortunately the final dissertation is not available on-line.

RE: Systems programming in languages other than C?

Well ... how about Forth?


As done by these folks,
An interesting benifit is that you do not need to have hardware based protection between kernel and user modes.

Statically compiled languages

Shouldn't most statically compiled languages be suitable (other than GC)? Heck, Modula-2+ has a GC and you can access the hardware. (Note that I despise Modula-2. It was what I was taught in first year University [in Canada]. Converting cardinals to integers. OH, the pain!).

Unfortunately not

One of the significant weaknesses of most of the modern, type-safe languages is that they have inadequate expressiveness for representation-level data types. For systems programming, data layout is prescriptive rather than descriptive.

High-level Views on

High-level Views on Low-level Representations is relevant here, as they describe how to support bit-level data using algebraic constructor forms and pattern matching. However, they don't support bit-level forms on structures larger than a word IIRC, where BitC does.


I guess I should throw this in.


While it doesn't have much usage, prescheme is a lisp designed in particular to do the tasks that C is normally used for. it doesn't have garbage collection, however I'd argue that a systems programming language shouldn't either. The nice part is you still get full scheme macro support, thus gaining alot of lisp's advantages in a statically typed, manually memory managed environment.


Lisaac always looked interesting to me (Objective-C meets Eiffel I guess) but its syntax is eye-curdling.