Hendrik

59 days ago

Entwicklung: Warum Rust die Antwort auf miese Software und Programmierfehler ist
Die Ideen und die Lösungen von Rust
INHALTSVERZEICHNIS

(Bild: Callum Bainbridge / Shutterstock.com)
Und hier kommt der Teil, der Rust so bemerkenswert macht. Die haben sich das angesehen und sich entschieden, dass sie kurzfristig Schmerzen aushalten wollen, wenn die Codebasis dadurch insgesamt sicherer wird. Sie haben sich C++ angesehen, die aktuelle Plattform von Firefox, und gesehen, dass das Design praktisch überall nicht "fail safe" ist. Wenn der Compiler smart genug ist, kann er dich warnen, aber der unklare Teil, bei dem der Compiler noch nicht schlau genug ist, da "failed" er unsafe und gibt keine Warnung aus. Schlimmer noch: Wenn der Compiler schlauer wird und mehr Codestellen bemängelt, dann schalten die meisten Programmierer lieber das Warnlevel herab oder ignorieren die Warnungen alle. Und auch dass man an etwas const dranschreiben muss, ist ein "fail unsafe".


Anzeige
Rust macht das so, dass man für einen 32 Bit Integer ohne Vorzeichen "u32" schreibt – aber der ist dann per Default const! Wer nicht const will, muss "mut u32" schreiben. Wenn der Programmierer den Tippaufwand scheut, dann ist das Ergebnis nicht schlechterer Code, der trotzdem vom Compiler akzeptiert wird, und dann vielleicht im Feld bricht, sondern der Compiler kann den Code direkt ablehnen. Kurzfristig ist das schmerzhaft. Rust macht es trotzdem.

Natürlich ist das nicht das Ende der Dinge, die Rust anders macht. Eine andere Rust-Idee muss hier noch gezeigt werden: Das Konzept von Ownership.

Es kann nur einen geben ...
Nehmen wir an, wir haben einen Container mit Werten drin. Wir rufen irgendeine Funktion auf, die damit etwas machen soll. In C++ schreibt man das einfach so hin, ohne darüber nachdenken zu müssen, wer jetzt eigentlich für den Container zuständig ist. Irgendjemand muss ja den Container freigeben, wenn man damit fertig ist. Übergibt man den Container nur als Eingabe für eine Operation an diese Funktion oder übergibt man ihn permanent und macht danach selber nichts mehr damit? Wenn die Funktion fertig ist, wer gibt dann den Container frei?

In vielen einfachen Programmen spielt diese Frage keine große Rolle. Das Hauptprogramm instanziiert alles und gibt am Ende alles frei. Für Codemonster wie einen Webbrowser funktioniert das aber so nicht, da braucht man bessere Konzepte. Das häufigste Konzept in Webbrowsern ist Reference Counting. Niemand ist Eigentümer. Der Container zählt selber, wie viele Referenzen es auf ihn gibt, und wenn der Wert 0 erreicht, gibt er sich selbst frei. Das funktioniert leidlich, aber es macht es praktisch unmöglich, belastbare Aussagen über den Code zu machen.

Entwicklung: Warum Rust die Antwort auf miese Software und Programmierfehler ist

heise.de

Die 2000er- und 2010er-Jahre sind goldene Zeiten für neue Programmiersprachen. Es gab eine veritable kambrische Explosion der Vielfalt.