Azure-CTO: „Es ist an der Zeit, keine neuen Projekte mehr in C/C++ zu starten“
(twitter.com/markrussinovich)- Wenn ein Szenario unbedingt eine Sprache ohne GC erfordert, sollte man Rust verwenden
- Aus Gründen der Sicherheit und Zuverlässigkeit
- Die Branche sollte C/C++ als veraltete Sprachen deklarieren
55 Kommentare
Selbst Leute, die Rust bisher gelobt und genutzt haben, sagen, dass sie beim Kontakt mit
asyncplötzlich ernüchtert sind. Es gibt sogar Stimmen, die fragen, ob man mit Rust besser gar keine Bibliotheken schreiben sollte, weil es zu komplex, zu heikel und zu schwierig sei. Solche Beschwerden tauchen inzwischen ebenfalls auf.Es gibt also auch Leute, die ihn schlechtreden, ohne überhaupt zu wissen, wer Mark Russinovich ist ... Er ist der Autor der Sysinternals Tool Suite und des Buchs Windows Internals ... Er ist jemand, der durch Reverse Engineering von Windows Tools gebaut hat und später Microsoft Fellow wurde ...
Ein Beitrag, der die Probleme von eingefleischten Rust-Fans in einem kurzen Video auf die Schippe nimmt
https://twitter.com/cmuratori/status/1367627549816152064?lang=en
Rust hat noch nicht einmal eine offizielle Spezifikation ....
Für C++ gibt es zwar formal eine offizielle Spezifikation, aber alle Implementierungen (
gcc,clang, ...) sind unvollständig.Das ist eine verbreitete Argumentation, aber aus der Perspektive von jemandem, der viele Spezifikationen tatsächlich gelesen und auch mehrfach implementiert hat, weiß ich ehrlich gesagt nicht, welche Bedeutung es an sich haben soll, ob es eine Spezifikation gibt oder nicht.
Für „Spezifikationen“ gibt es verschiedene Strategien. Es gibt Methoden, die das äußerlich beobachtbare Verhalten beschreiben, und solche, die das interne Verhalten beschreiben; außerdem unterscheiden sie sich darin, ob natürliche Sprache verwendet wird oder maschinenlesbare Methoden wie Pseudocode oder mathematische Definitionen. Dokumente wie die Sprachreferenzen von Python oder Rust sind Spezifikationen, die das äußerlich beobachtbare Verhalten in natürlicher Sprache beschreiben. Ein in ISO-Standards und Ähnlichem häufig zu sehender Ansatz ist dagegen eine Spezifikation, die das interne Verhalten in natürlicher Sprache beschreibt. Dabei gibt es keine Garantie dafür, dass dieses interne Verhalten mit dem Ansatz realer Implementierungen übereinstimmt; stattdessen wird es so definiert, dass der Standard erfüllt ist, wenn eine hypothetische Implementierung auf Basis dieses internen Verhaltens und eine reale Implementierung nach außen hin gleich funktionieren, also observationally equivalent sind. ECMAScript wird zwar in natürlicher Sprache beschrieben, aber seine tatsächliche Struktur ist praktisch auf dem Niveau von in natürlicher Sprache geschriebenem Pseudocode; und es gibt auch Fälle wie WebAssembly, das internes Verhalten sowohl als natürlichsprachige Spezifikation als auch als mathematische Definition bereitstellt.
Aus Sicht der Implementierung sind natürlichsprachige Spezifikationen letztlich alle ähnlich. Da natürlichsprachige Spezifikationen getrennt von der tatsächlichen Implementierung erstellt werden müssen, kann es natürlich vorkommen, dass sich beide voneinander entfernen, und Fehler sind ebenfalls häufig. Ob äußerlich beobachtbares Verhalten leichter zu implementieren ist oder internes Verhalten leichter zu implementieren ist, hängt von der jeweiligen Situation ab; aus Sicht von Programmiersprachen gibt es keinen zwingenden Grund, sich eindeutig für die eine oder die andere Seite zu entscheiden. In diesem Sinne verfügt Rust bereits über eine Spezifikation, und es ist richtig, dass diese Spezifikation genügend Informationen liefert, sodass auch andere alternative Implementierungen entstehen können.
Falls Sie die Reife eines Standards einfach daran festmachen möchten, ob er bereits ein ISO-Standard geworden ist oder nicht, kann ich Ihnen mitteilen, dass ich im ISO/IEC 18181-1 JPEG XL-Standard etwa 100 Bugs gefunden habe (und dass sich deshalb das 2nd amendment verzögert) ...
Auf Hacker News gab es auch mehr als 800 Kommentare dazu … auch hier ist die Diskussion hitzig.
https://news.ycombinator.com/item?id=32905885
Vielen Dank für Ihren Einsatz.
Andererseits ... ich habe einen Text gelesen, in dem davor gewarnt wurde, wenn etwas angegriffen wird, das jemand mag, bei der Deutung der Reaktion dieser Person alles auf ihren Charakter zurückzuführen, und ich fand das einen guten Gedanken, weil es in der realen Situation vermutlich schwer ist, eine solche Haltung zu bewahren.
Einen Tweet-Kommentar fand ich besonders eindrucksvoll.
Am Ende schreiben die Leute Rust-Code auf die „unsafe“ Art. - gekürzt - Rust war nie dafür gedacht, diese zu ersetzen.
An diesem Punkt füge ich einen Link ein, über den man herausfinden kann, wer Mark Russinovich ist.
https://en.m.wikipedia.org/wiki/Mark_Russinovich
Noch ein Wort dazu. Leute, die bei der Verwendung von C++ ständig Fehler machen und Bugs produzieren, sagen dann: Hey, das taugt nichts, wechseln wir doch zu Rust, das heutzutage so angesagt ist … Da muss man sich angeblich nicht um Speicherfehler kümmern … Solche Leute sind genau gleich. Auch mit Rust werden sie ähnliche Bugs erzeugen … und dann gibt es wieder viele, die sagen werden: Welche Sprache sollen wir als Nächstes lernen und ausprobieren? Es sind Leute, die in C++ nicht einmal Pointer-Dereferenzierung richtig beherrschen, die Rust so in den Himmel loben.
Solche Leute werden einfach all das ignorieren, was bei Rust als Stärke angeführt wird – Ownership, Referenzen, Borrowing –, weil es schon beim Kompilieren Fehler wirft und lästig ist, und dann einfach
unsafedazumischen und es hemmungslos so benutzen, als wäre es C++.Warum lebt man überhaupt, wenn man sowieso sterben wird?
Das ist eine Argumentation auf fast genau demselben Niveau.
Es fühlt sich an, als würde man die Behauptung sehen, Sicherheitsgurte und Ampeln hätten keinen besonderen Sinn, weil diejenigen, die Unfälle bauen, ohnehin keinen Sicherheitsgurt anlegen und auch Ampeln ignorieren.
Man kann zwar behaupten, dass gute Leute unabhängig von allem gute Arbeit leisten und schlechte Leute unabhängig von allem schlechte Arbeit, aber wenn man dieser Logik folgt, kommt eine Diskussion über den Nutzen von Werkzeugen gar nicht erst zustande.
Das Problem ist, dass die Sprache viel zu schwer zu benutzen ist, also stimmt die Aussage schon.
Wenn es Visual Rust gibt, erkenne ich es am Emoticon ._.k
C/C++ scheint jetzt wirklich den Status von Latein zu bekommen. Für die akademische Bildung sollte es zwar jeder lernen, aber es zu meistern ist fast unmöglich, und weil es aus einem alten System stammt, gibt es aus heutiger Sicht auch viele unvernünftige Aspekte ...
Es ist interessant, dass Sprachen, in denen alles unsafe ist, problemlos verwendet werden, während Sprachen, in denen man unsafe nur eingeschränkt nutzen kann, angeblich absolut nicht in Frage kommen.
Ich halte das für eine Art Stockholm-Syndrom.
The Spirit of C
Meiner persönlichen Meinung nach stimmt schon Punkt 1 nicht, haha. Menschen sind von Natur aus fehleranfällig ...
Bei C++ reicht es im Grunde, Smart Pointer und Memory Pools aktiv zu verwenden …
Ich denke, dass man Pointer überraschend oft gar nicht direkt anfassen muss.
Ich glaube, thread-sicherer Code hängt am Ende von den Fähigkeiten des Programmierers selbst ab.
Egal welche Sprache man verwendet: Wenn die Fähigkeiten nicht gut genug sind,
sieht man entweder sicheren, aber leistungsschwachen Code oder riskanten Code.
Es ist doch viel zu beängstigend, die Fähigkeiten von Programmierern mit dem Fahren eines Autos oder dem Steuern eines Flugzeugs zu betrauen....
Thread-safe Code ist letztlich eine Frage der Fähigkeiten des Programmierers <- Ich halte diese Sichtweise für gefährlich, denn Memory- / Thread-Sicherheit bedeutet nicht einfach nur, dass ein Programm abstürzt oder langsamer wird, sondern kann sich zu einer Sicherheitslücke entwickeln. Deshalb sollte man das meiner Meinung nach nicht den Fähigkeiten einer einzelnen Person überlassen.
Es wurden verschiedene Methoden erforscht, um das im Vorfeld zu verhindern, und sie sind gereift und in Sprachen wie Rust oder anderen Tools entstanden. Ich finde, die Auswirkungen von Software auf den Alltag sind inzwischen viel zu groß geworden, um darauf zu verzichten und stattdessen dem Einzelnen die Schuld zu geben.
Menschen machen nun einmal Fehler, weil sie Menschen sind, und selbst die klügsten Programmierer machen zwangsläufig Fehler. Auch Speicherfehler entstehen letztlich aus solchen Fehlern ...
Heutzutage ist es vielleicht der bessere Ansatz, nicht darauf zu setzen, dass man es von selbst gut macht, sondern von vornherein eine Umgebung bereitzustellen, in der Fehler schwerer zu machen sind.
Wenn wir in unserem Unternehmen Rust verwenden wollen, ist
unsafeverboten. Nur mit einer solchen Regel kann man überhaupt versuchen, der auf Sprachebene unterstützten Sicherheit einmal zu vertrauen. Aber ist das wirklich sinnvoll?Natürlich gibt es in Unternehmen, die Rust einsetzen, wohl die Übereinkunft,
unsafenur zu verwenden, wenn es wirklich notwendig ist. Ich würde Ihnen aber eher empfehlen, direkt selbst in Rust zu programmieren ... Ob und wie oft Sie tatsächlichunsafeverwenden müssen, werden Sie wohl erst herausfinden, wenn Sie es selbst ausprobiert haben, oder?Bekannte Bibliotheken wie tokio waren ebenfalls mit
unsafegeradezu übersät.Es gibt hier ziemlich viele Kommentare, die eine Alles-oder-nichts-Sicht vertreten und meinen: Wenn es nicht komplett „all“ ist, dann hat es überhaupt keinen Wert.
Es gibt jedoch den Vorteil, dass man
unsafeundsafeexplizit unterscheiden und voneinander isolieren kann und dass jemand, der sonst 100 Speicherfehler verursachen würde, vielleicht nur noch 10 verursacht. Trotzdem heißt es dann: Es gibt ja trotzdemunsafe/ Speicherfehler treten weiterhin auf => also ist es gegenüber C++ letztlich nicht besser. Ich bin mir nicht sicher, ob diese Herangehensweise ein realistisches Urteil ist 😅Von der Anzahl der Kommentare her schon, aber ...
Es scheint eher so zu sein, dass einfach eine Person mit einer Alles-oder-nichts-Meinung sehr viele Kommentare geschrieben hat ... und das trifft es wohl besser.
Ich stimme diesem Kommentar ebenfalls zu. Je stärker man etwas dichotomisch betrachtet, desto mehr schadet man am Ende nur sich selbst.
In der Praxis wägt man Vor- und Nachteile ab und entscheidet sich letztlich für das, was insgesamt den größten Nutzen bringt. Ich denke, dass sich die Einsatzbereiche von Rust nach und nach erweitern, weil die Vorteile von Rust groß sind, sofern man aufgrund der Besonderheiten der Branche nicht gerade jetzt zwingend C/C++ verwenden muss.
Die Leute, die zu Rust wechseln, sind ja auch nicht dumm — wenn sie Rust ausprobiert haben und es sich im Ergebnis gegenüber C++ als besser erweist, dann werden sie es eben weiter benutzen, haha.
Nichts ... Alles
Wahrscheinlich gibt es inzwischen nur noch wenige, die nicht zustimmen würden, dass Rust das nächste C++ ist. Immerhin wurde es sogar im Linux-Kernel als offizielle Sprache übernommen.
Allerdings ist es fraglich, ob Rust wirklich eine einfach zu nutzende Sprache ist ... Dank der statischen Analyse, die Speicherfehler schon im Vorfeld verhindern soll, sind die Compile-Zeiten ziemlich schmerzhaft, und weil Semantiken wie Ownership schwer zu verstehen sind, erfordert es deutlich mehr Lernaufwand als universelle Sprachen wie Python oder Java.
Die Kompilierzeit dürfte vor allem an LLVM selbst liegen. Da Facebook daran arbeitet, die Instruction Selection in LLVM zu verbessern, wird sich die Lage wohl bessern.
Wenn man nachschaut, stimmt das tatsächlich. Ich dachte, dass viel Zeit für typenbezogene Prüfungen rund um Ownership draufgeht, aber das LLVM-Backend ist wohl ziemlich groß..
Als Rust zum ersten Mal erschien, war ich sehr interessiert und habe mich ein wenig damit beschäftigt ... aber als ich
unsafegesehen habe, habe ich es sofort wieder aufgegeben. Ich konnte mich einfach nicht vernünftig davon überzeugen, warum ich das lernen und einsetzen sollte. Letztlich muss man bei auch nur etwas komplexeren Programmen ohnehinunsafeverwenden. Aber dann ist die Stabilität, mit der Rust so sehr prahlt, doch dahin. Warum sollte man das benutzen?Bei Rust braucht man
unsafeeigentlich nur für Low-Level-Programmierung; bei der Entwicklung gewöhnlicher Anwendungen kann man praktisch davon ausgehen, dass man es kaum verwenden muss.Und selbst wenn innerhalb eines
unsafe-Blocks ein Speicherproblem auftritt, hat das den Vorteil, dass die Sprache garantiert, dass sich die problematische Stelle innerhalb desunsafe-Blocks befindet, was das Debugging erleichtert.Wenn Sie bei
unsafefragen: „Warum sollte man so etwas verwenden?“, sollte man dann nicht von vornherein auch kein C/C++ verwenden?Auch C++ entwickelt sich weiter, und wenn man ohnehin
unsafeverwenden würde, nimmt man am Ende lieber einfach C++. Ich spüre einfach nicht wirklich die Notwendigkeit, extra Rust zu lernen und einzusetzen.Nicht für jede Rust-Programmierung ist
unsafeerforderlich.Derart sorgfältige Speicheroperationen, die
unsafenötig machen, sind in der Regel in die Bibliotheksentwicklung ausgelagert, daher denke ich, dass man auf der Anwendungsebene – wo vermutlich die größte Nachfrage besteht – kaum Gelegenheit haben wird,unsafezu verwenden.Es stimmt zwar, dass sich auch C++ ständig weiterentwickelt, aber das Legacy-Erbe für die Abwärtskompatibilität ist einfach zu schmerzhaft. Wenn Sie sich schon über ein einziges
unsafebeschweren, würden Ihnen vermutlich alle Funktionen von C++ missfallen, hahaDeshalb wird
unsafeauch nicht empfohlen.Wenn man
safeverwendet, ist alles sicherer als bei C/C++, wo praktisch allesunsafeist.https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf
Ohne das vage Konstrukt
unsafekönnte Rust vielleicht eine echte Alternative zu C++ werdenIch wünschte, FFI wäre ein bisschen benutzerfreundlicher gewesen … Ich erinnere mich noch daran, wie schmerzhaft es war, komplexe Strukturen über FFI mit externen Bibliotheken auszutauschen.
Sogar Rust-zu-Rust ist nicht gerade einfach.. https://github.com/rodrimati1992/abi_stable_crates
Vor dem Hintergrund, dass Microsoft Rust aktiv unterstützt, wirkt diese Aussage wie eine ganz natürliche Fortsetzung dieser Entwicklung.
Sogar der sture Torvalds hat Rust übernommen, also sehe ich keinen Grund, weiterhin unbedingt eine Sprache zu verwenden, die auch immer weniger Leute lernen.
Speicherbezogene Bugs verschwinden nicht einfach dadurch, dass man Rust verwendet. Menschen, die Bugs produzieren, werden mit jeder Sprache massenhaft Bugs erzeugen. C++ wird völlig problemlos und effizient genutzt, also was soll da abgeschafft werden? Damit hat er wirklich leichtfertig eine bombastische Aussage gemacht, die im Ernstfall einen Krieg auslösen könnte.
Zu behaupten, dass C/C++ völlig problemlos und effizient eingesetzt wird, ist schwierig, denn historisch sind bereits zahllose speicherbezogene Bugs in C/C++ aufgetreten, und vermutlich treten sie auch jetzt gerade irgendwo auf. (Immerhin konnten dadurch viele PL/SE-Forscher ihren Lebensunterhalt verdienen.)
Laut der Ankündigung von Microsoft sind 70 % der Sicherheitslücken speicherbezogene Bugs (https://zdnet.com/article/…)
Eine Untersuchung im Chromium-Projekt kam zu einem ähnlichen Ergebnis (https://www.chromium.org/Home/chromium-security/memory-safety/): Auch dort waren fast 70 % speicherbezogene Bugs.
Ich habe irgendwo einmal einen älteren Artikel gesehen, in dem stand, dass die meisten Bugs im Windows-Kernel speicherbezogene Fehler sind und dass diese Fehler in den Teilen, die in Rust entwickelt werden, drastisch zurückgegangen sind..
Dass die Sprache von ihrem Grunddesign her aktiv
readonly-ähnliche Nutzung fördert und dadurch sprachseitig sicherer als C++ ausgelegt ist, lässt sich wohl kaum bestreiten. Allerdings taucht dadurch auch das zuvor kaum bekannte Konzept des Ownership auf, was das Programmieren schwieriger macht.Außerdem gibt es auch noch den Performance-Vorteil, dass statistisch gesehen selbst eher grob geschriebener Rust-Code schneller läuft als sehr gut entworfener C++-Code.
Da hat wohl jemand etwas gesagt, das einen kleinen Sturm auslösen könnte. lol
Persönlich finde ich, dass sich C++ dadurch, dass es schon so alt ist, wegen der Rückwärtskompatibilität selbst ausbremst und sich nur langsam modern weiterentwickelt.
Außerdem gibt es, weil man strikte Rückwärtskompatibilität beibehält und gleichzeitig moderne Dinge einbaut, einfach zu viele verschiedene Wege, dieselbe Aufgabe zu erledigen, was meiner Meinung nach für Einsteiger eher eine zusätzliche Hürde darstellt.
Ich denke inzwischen auch, dass Rust besser ist als C++. Die Zeiten, in denen man sich die Augen rot gesucht hat, um Bugs rund um Speicherverwaltung zu finden, sollten jetzt wirklich vorbei sein.
Ja, genau … Wenn es sich um ein Entwicklungsprojekt handelt, das bei null startet, gibt es keinen besonderen Grund, ausgerechnet C++ zu wählen …
Stimme voll zu
Selbst wenn ich Rust verwenden möchte, nutze ich es höchstens ergänzend; im beruflichen Alltag gibt es dafür bei mir noch kaum Einsatzmöglichkeiten.
Deshalb werde ich auch nicht richtig damit vertraut, und wenn ich es kurz aus der Hand lege, vergesse ich es wieder...
Ich würde es zwar wirklich gern verwenden, weil es mir gefällt... hehe
Leute, die nie auch nur einmal einen Memory Pool zur effizienten Nutzung des Heaps geschrieben haben, reden ständig groß von Rust, haha.
Der Azure CTO ist natürlich keine Meinung, die so maßgeblich wäre, dass sie den Industriestandard repräsentiert, und selbst auf Microsoft beschränkt ist das keinesfalls eine Position, die den Standpunkt von Microsoft vertritt; am Ende ist es wohl nichts weiter, als dass bei ihm plötzlich irgendwas ausgebrochen ist und er einfach seine subjektiven Gedanken herausposaunt ... Wenn Leute schon C++ nicht richtig beherrschen, werden sie es dann mit Rust plötzlich richtig machen? Jedenfalls ist das hier wieder voll von Leuten, die nur große Sprüche klopfen.
Schon Ihr Tonfall offenbart unverblümt Ihre Geschmacklosigkeit. Viel Erfolg.