Wie könnte ein C-Nachfolger aussehen?

Man verwendet heute C kaum noch für Applikationsentwicklung, aber wenn wir uns anschauen, welche Software wir täglich dauernd verwenden, ist ein großer Teil davon in C oder eventuell in C++ geschrieben, z.B. gängige Betriebssysteme (Linux, MS-Windows,…), Web-Browser, die meisten Datenbanken, die meisten Editoren, die meisten Office-Programme, die meisten Fenstersysteme, viele Bildverarbeitungsprogramme, u.s.w.

Was könnten die Gründe sein, daß man für diese Zwecke C verwendet? Vielleicht die relative Nähe an der Assemblersprache kombiniert mit der richtigen Abstraktion und einigen nützlichen Library-Funktionen? Vielleicht der direkte Zugriff auf Betriebssystem-APIs? Das einigermaßen gut vorhersehbare Zeitverhalten? Oder einfach die vorhandene Codebasis? Und C-Programme sind schnell. Aber nur wenn man genügend Zeit zum Entwickeln hat. Die C-Syntax hat sich zum de-facto-Standard für viele Programmiersprachen entwickelt.

Diese Vorteile will man natürlich beibehalten. Daher scheiden als direkte Nachfolger Sprachen mit einer hohen Abstrahierung, einem kommplizierten Laufzeitsystem mit Garbage Collection u.s.w. aus. Natürlich wurde C in der Applikationsentwicklung durch Java, Scala, C#, Ruby, Perl, PHP, Python, JavaScript u.s.w. teilweise verdrängt. Gerade deswegen braucht man die Features dieser Sprachen nicht einfach in C zu übernehmen, denn wenn man das will, kann man diese Sprachen statt C verwenden.

Vielleicht will also niemand einen C-Nachfolger? Kann sein, aber es gibt doch ein paar Dinge, die man besser machen könnten und die vielleicht einen Nachfolger, aber sicher nicht einen ganzen Zoo von Nachfolgern rechtfertigen würden:

• Bessere arithmetische Operationen auf den primitiven Typen: Durchreichung von nützlichen Assembler-Features wie Addtion mit Carry, Multiplikation mit einem Ergebnis von der doppelten Länge der Faktoren.
• Echte Zeichenketten mit einfach handhabbarer nativer Unterstützung für verschiedene Zeichensatzcodierungen (UTF-8, ISO-8859-*, ISO-646-irv, UTF-16,…)
• Bessere Unterstützung für Thread-Safety.
• Vielleicht eine bessere Fehlerbehandlung
• So etwas wie ein Schlüsselwort „unsafe“, bei dessen Benutzung C-übliche Dinge wie Casts von Zahlen auf Pointer, indizieren von Arrays außerhalb von deren Bereich u.s.w. möglich sind. Ohne das Schlüsselwort werden diese Operationen nicht unterstützt oder führen zu Laufzeitfehlern.
• Mehrfache Rückgabewerte bei Funktionsaufrufen

Einen C-Nachfolger, der nicht Link-Compatibilität zu C bietet, könnte man natürlich vergessen. Man möchte ja auf jeden Fall die bestehende Code-Basis und die Libraries weiterhin benutzen können.

Wird es so etwas geben? Ich weiß es nicht, es sieht natürlich im Moment nicht danach aus und man behilft sich damit, Dinge, die in C nicht gut gehen, stattdessen in anderen Sprachen zu entwickeln. Wir sehen es ja an dem ähnlichen Beispiel Ceylon, das einen Java-ähnlichen Java-Ersatz bieten soll und dabei einige unglaublich ärgerliche Design-Fehler von Java vermeidet. Wenn Ceylon einmal ausgereift ist, ist es wahrscheinlich absurd, noch Dinge in Java zu entwickeln, aber wenn man schon wechselt, kann man auch zu moderneren Sprachen wie
Ruby, Scala oder Clojure wechseln. So halten sich ärgerliche Designfehler in Programmiersprachen länger als eigentlich nötig.

Es hilft viel, für die Aufgabe das passende Werkzeug zu verwenden, aber es ist sicher gut, auch einmal darüber nachzudenken, wie man einige dieser Werkzeuge verbessern könnte.