C is not going away.
Although newer languages (Java, C#, Perl, PHP, Python, Ruby, ...) are eclipsing C in usage and vitality, C is not going away. In fact, C programs will comprise the core of our computing environment for the foreseeable future. 95% of the code running on your desktop today (2006) is written in C, or its relative, C++ (e.g., the OS, your mail client and web browser). There are a number of reasons for this, but they all boil down to this: C gives programmers control over resources.
Cyclone is a language for C programmers who want to write secure, robust programs. It’s a dialect of C designed to be safe: free of crashes, buffer overflows, format string attacks, and so on. Careful C programmers can produce safe C programs, but, in practice, many C programs are unsafe. Our goal is to make all Cyclone programs safe, regardless of how carefully they were written. Cyclone "feels" like programming in C: Cyclone tries to give programmers the same control over data representations, memory management, and performance that C has.
If you know me well, you probably know that I'm not a huge fan of C++. Though made with the best of intentions and containing many good concepts, C++ just has too many warts to be a good successor. Java does what C++ should have done, but much more cleanly and maintainably. In fact, the problem with C++ is not that it does too little, but that it does far too much. As I quoted someone several years ago:
"If you must use the wrong language for the job, I'd rather see you use C than C++. It's true that C gives you enough rope to hang yourself. But so does C++, and it also comes with a premade gallows and a book on knot tying." "
Cyclone looks very interesting. I particularly like the fact that if you want to, you can tell the compiler to auto-check your pointers for NULL, or for bounds. In fact I think I'd probably start out making all my pointers Cyclone "?"-style (bounds and NULL checked) and only change them if a profiler run suggested that a certain part of my code was slow. Programmers generally never, ever have any clue about what part of their code is slow. The parts we think are slow almost never are. Without running a profiler, you are absolutely shooting in the dark - at something that probably isn't even in the same room with you.
Even in the rare case when you guess correctly about where your code is slow, the best solution is almost never to make small tweaks to pointer arithmetic. I believe I once read that spending months recoding your entire program in hand-optimized assembly would yield, at most, a 30% speedup. On the average, more like 5-15%. On the other hand, going back to your Knuth books and selecting a better algorithm... will often speed your code up 150-300%.
And even then, if you don't profile your code both before and after, you'll never know how much speed you gained from any given tweak. When it comes to performance testing, your choices are either to profile and have enough data to figure out what actually helps... or to not profile and just flail around randomly, with no clue whether you're actually making any real progress.