Language Reliability, Round 2

Several people accused my last post of being a thinly-veiled troll. Well... yes. But I was also serious.

Thanks to davidw, who reminded me that Erlang does in fact both exist and run high-performance, high-reliability systems. I haven't looked at it very closely, though; I suspect it may have other overriding disadvantages, possibly including the most common one: incompatibility with pre-existing code. "100% Pure Java" my bum.

To the accusations that I was unclear in my requirements for "reliability" and "high-performance", I guess I can clarify a bit. My company makes highly reliable backup software. Imagine your job was to manage the mission-critical backups for a 1000-person company, and in case of any failure, you had to be able to get back up and running again within 24 hours. First of all, can a program written in one of these scripting languages deal with the massive quantities of data involved - hundreds of gigabytes, millions of files? Would your backup even finish every night? Can you trust your backups to be reliable?

This is an honest question, and when I ask myself, the answer is no. I've just never seen a program written in one of these languages that I would trust with my mission-critical data. So I ask you the same: have you seen programs in these non-C/C++ languages that are actually this fast and reliable? I haven't. I would love to hear some examples.

Monopolize this!

If we end up extending XPLC's IDL compiler to support Java and .NET, I'm going to call the result .NIT (dot Net Integration Technologies). Just try and stop me.

Soul Sucking

This weekend I've been hacking the win32 port of WvStreams to work more smoothly. It already works, but the unit testing framework didn't compile, so I had my suspicions that it didn't all work. Sure enough, I fixed the few minor bugs in the unit testing framework, and next thing you know - failing unit tests everywhere.

So first of all, yay for unit tests. Automated magic bug pinpointers, they are. A busy weekend of hacking got the failure count down to zero where it should be, and sure enough - all the WvStreams demo apps work way better now.

Anyway, since I would hardly want to resort to using Visual C++, and since the unit tests are kind of most convenient when used with GNU Make, I thought: let's see how much of this I can do on my Linux system.

Ha. So I now know all about mingw32 (a wonderful system). I also know more than I'd like to know about msvcrt.dll's fd-to-handle mapping (a terrible system). And it all runs correctly under WINE (a truly horrendous pile of puke).

Oh well, if nothing else, I guess I can extend my UniConf demo. Now I can run a UniConfDaemon under wine, exporting the Windows registry over TCP so I can connect to it from a Linux box, replicate it into my Maildir, point gconfd at that, and then configure KDE through gconf. If all that put together doesn't crash, I guess something doesn't suck.

Related Question

If you're doing _read(0,buf,sizeof(buf)) in a thread in win32, does anybody know how, from another thread, to get _read() to back out gently and return? I wouldn't even mind closing fd#0 in order to do this, but stunningly, close() blocks forever because _read() is blocking while in a critical section. Argh. I'm sure there has to be a way to do this.

I used to think the Worse is Better guy was just making an idle example. But good old EINTR - holy cow. How I miss you!

Irony

Tomorrow, I'm giving a presentation on how to write/debug code more quickly. And I spent the weekend working around Windows quirks. Sigh.