Von C zu Rust wechseln?



  • Jetzt ist die beste Zeit zu Rust zu wechseln, weil man sich jetzt noch in die Sprache einbringen kann.



  • Klartext schrieb:

    Jetzt ist die beste Zeit zu Rust zu wechseln, weil man sich jetzt noch in die Sprache einbringen kann.

    Noe. Mit der alpha 2 ist das meiste soweit stable. Beim meisten Kram kann danach nur noch hinzugefuegt, aber keine bestehende API mehr geaendert werden.



  • was ich mir von C++ in Zukunft wünsche sind ganz andere Sachen. Mit Speicherlecks, segmentation faults, exception-safety etc habe ich nämlich keinerlei Probleme. Ist u.a. eine Frage der systematischen Herangehensweise. Eine GC brauche ich nicht. Im Gegenteil, die Abwesehenheit einer solchen zwingt mich, von Anfang die wichtigen Fragen zu beantworten ("wen gehört diese Resource? - Wann wird sie freigegeben? ..." usw)

    aber das ABI - ich muß oft viel Zeit in Portabilitäts- und Interoperabilitätsfragen investieren: Object Formate, name mangling. Static linking. Aufrufformate. usw.

    Solche Probleme sind oft so knifflig, daß die eigentliche C++-Programmierung für mich fast schon wie Urlaub wirkt.

    Ich würde mir mehr Interoperabilität als extern "C" wünschen, aber es gibt ja bereits einen proposal für extern "abi". Vielleicht in C++14? C++17? Für mich ist so etwas jedenfalls bedeutend wichtiger als etwa eine GC.



  • großbuchstaben schrieb:

    Ich würde mir mehr Interoperabilität als extern "C" wünschen, aber es gibt ja bereits einen proposal für extern "abi". Vielleicht in C++14? C++17? Für mich ist so etwas jedenfalls bedeutend wichtiger als etwa eine GC.

    C++14 ist doch schon draußen und das nächste ist C++18.



  • großbuchstaben schrieb:

    was ich mir von C++ in Zukunft wünsche sind ganz andere Sachen. Mit Speicherlecks, segmentation faults, exception-safety etc habe ich nämlich keinerlei Probleme.

    Alle komplexeren C++-Projekte haben damit aber Probleme, weil Menschen eben Fehler machen. Gerade in diesen Hackerzeiten ist jeder Exploit einer zu viel.



  • großbuchstaben schrieb:

    Mit Speicherlecks, segmentation faults, exception-safety etc habe ich nämlich keinerlei Probleme. Ist u.a. eine Frage der systematischen Herangehensweise. Eine GC brauche ich nicht. Im Gegenteil, die Abwesehenheit einer solchen zwingt mich, von Anfang die wichtigen Fragen zu beantworten ("wen gehört diese Resource? - Wann wird sie freigegeben? ..." usw)

    Naja, zum Teil ist C++ in der Hinsicht selbstdokumentierend durch die Unterscheidung zwischen "RAII-Typen" und rohen Zeigern/Referenzen. Es gibt aber genug Stellen hier und da, wo man keinen Ownership-Transfer haben will, sondern irgend einem Fetzen Code eine Resource ausleihen will. Das wird spätestens dann fehleranfällig, wenn so eine Leihgabe dem Aufruf-Stack entflieht und z.B. in irgendeiner anderen Datenstruktur gespeichert wird. Du musst Dir in so einer Situation überlegen, wie Du garantieren kannst, dass diese Leihgaben nicht ungültig werden. Oder Du wechselst zu Shared-Ownership in solchen Situationen, um es schwieriger zu machen, Mist bzgl baumelnden Zeigern zu bauen. Shared ownership bringt aber auch seine eigenen Nachteile mit. Ich finde, da wo C++ mit RAII aufgehört hat, macht Rust mit dem „Borrowing“-Konzept weiter. Das ist eine Sache, die dem Compiler bekannt ist, weil es Teil des Typsystems ist. Dementsprechend gibt es einen „Borrow Checker“ im Compiler, der sicherstellt, dass es keine Baumelnden Zeiger gibt. Das ist mir lieber als in C++ darauf zu vertrauen, dass ich beim Design keinen Mist gebaut habe und doch zu lange an einem Zeiger festgehalten habe.

    Abgesehen davon, gibt es in Rust genug andere Nettigkeiten/Vereinfachungen gegenüber C++. Zum Beispiel ist das Design der Standardbibliothek vorbildlich. Du kannst eine HashMap<String, SonstWas> abfragen, ohne erst einen temporären String konstuieren zu müssen. Ein &str geht da z.B. auch, was die sichere Version von const char* oder string_view ist. Man muss sich auch nicht mit Dingen wie begin/end rumschlagen. Die Sache mit den Iteratoren ist in Rust sehr ergonomisch.

    Im Endeffekt ist Rust eine Sprache, die die guten Dinge aus diversen Sprachen zu übernehmen versucht, ohne dabei dieselben Fehler zu machen. Und im Vergleich zu dem, was es sonst noch so auf dem Markt in diesem Sektor der „Low-Overhead“-Sprachen gibt, ist ihr das IMHO gut gelungen. Ich weiß, das hört sich wahrscheinlich genauso an, wie das, was mir Leute erzählen, wenn sie mir erklären wollen, wie cool doch D ist. Das überzeugt mich nämlich nicht. Nicht soweit, dass ich D ausprobieren wollen würde. Damit will nur sagen, dass es Spracheigenschaften gibt, die man selbst erfahren muss. Und das beschränkt sich nicht nur auf Rust.

    Nachtrag: Was mir noch aufgefallen ist, dass Rust es mir erlaubt, ausgeliehene Referenzen wie „normale Werte“ zu behandeln. Diese Art der Referenzen kam mir erst sehr komisch vor und ich konnte mir nicht verkneifen, zu denken, dass das eine blöde Idee ist. Aber das sehe ich jetzt anders. In Rust kann man nichts falsch machen, wenn man eine Referenz stellvertretend als einen „Wert“ betrachtet – also auch im Sinne der Wertesemantik. Nicht nur ist die Sache mit der Lebenszeit des Dings, worauf sich so eine Referenz bezieht, kein Problem, sondern auch das Aliasing. Wenn die Aliasing-Regeln in Rust nicht so streng wären, würde es nämlich nicht funktionieren, so zu tun, als würden sich Referenzen wie Werte verhalten. Ich find' das extrem cool, weiß aber nicht, wie ich das richtig rüberbringen kann, so dass man mich auch versteht. 🙂



  • krümelkacker schrieb:

    Es gibt aber genug Stellen hier und da, wo man keinen Ownership-Transfer haben will, sondern irgend einem Fetzen Code eine Resource ausleihen will. Das wird spätestens dann fehleranfällig, wenn so eine Leihgabe dem Aufruf-Stack entflieht und z.B. in irgendeiner anderen Datenstruktur gespeichert wird. Du musst Dir in so einer Situation überlegen, wie Du garantieren kannst, dass diese Leihgaben nicht ungültig werden. Oder Du wechselst zu Shared-Ownership in solchen Situationen, um es schwieriger zu machen, Mist bzgl baumelnden Zeigern zu bauen. Shared ownership bringt aber auch seine eigenen Nachteile mit. Ich finde, da wo C++ mit RAII aufgehört hat, macht Rust mit dem „Borrowing“-Konzept weiter.

    👍 Sehr schoen gesagt, ich bin drauf und dran mal ein Projekt mit Rust zu schreiben, momentan habe ich nur eine grobe Idee der Sprache, aber alles was ich so gelesen habe hoert sich ziemlich gut an.


Anmelden zum Antworten