1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › Google: Chrome…

Es führt kein Weg an Rust vorbei

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Es führt kein Weg an Rust vorbei

    Autor: Steffo 22.09.21 - 10:30

    Die Anforderungen und auch die Programme werden immer komplexer. Mit Sprachen, die vor vielen Jahrzehnten designt wurden und die Schwächen im Kern nicht ausgemerzt werden können, ist keine sichere und stabile Software zu erreichen.

  2. Re: Es führt kein Weg an Rust vorbei

    Autor: dangi12012 22.09.21 - 10:43

    Also Flugzeuge und Atomkraftwerke und dein Betriebssystem sind glücklich mit C++. Man kann programme auch so schreiben das nie ein new oder malloc gebraucht wird. Das ist meistens auch der schnellere und stabilere code.



    1 mal bearbeitet, zuletzt am 22.09.21 10:44 durch dangi12012.

  3. Re: Es führt kein Weg an Rust vorbei

    Autor: herc 22.09.21 - 11:03

    ich frage mich auch was, wenn man nur modernes C++ nutzt (z.b. shared_ptr, lock_guards, also das RAII prinzip konsequenz durchzieht)? https://en.cppreference.com/w/cpp/language/raii

    interessant wäre eine analyse, ob man - wenn man nur die modernen funktionen von c++ nutzt - eine zumindest halbwegs vergleichbare sicherheit im vergleich zu rust erreichen kann? oder geht das prinzipiell nicht auf dem gleichen level?

  4. Re: Es führt kein Weg an Rust vorbei

    Autor: Atomic 22.09.21 - 11:04

    dangi12012 schrieb:
    --------------------------------------------------------------------------------
    > Also Flugzeuge
    War in der Boing 737 Max 9 nicht ein Softwareproblem ursächlich?
    IMHO wird da auch viel ADA verwandt.

    > und dein Betriebssystem sind glücklich
    Linux ist z.B. in C geschrieben

    Bei den Kernkraftwerken bist du dir da sicher?

    > mit C++. Man kann programme auch so schreiben das nie ein new oder malloc
    > gebraucht wird. Das ist meistens auch der schnellere und stabilere code.
    Man kann sich auch den Arm abschneiden, wenn man abnehmen will (garantiert kein JoJo Effekt!)
    aber ob das eine gute Idee ist? ALs ich vor Äonen von C auf C++ umgestiegen bin kam mir das in allen Fällen wie eine Verbesserung vor, aber heute finde ich C++ nur noch komplex und häßlich. Wenn laut Stroustroup eine kleine elegante Sprache in C++ verborgen ist dann sagt das viel.

    Ich habe (gerade auch in der letzten Zeit) viele Leute erlebt, wo ich mich frage, wie die es in die IT geschafft haben, von daher glaube ich das die Anzahl der Leute, die es wirklich drauf haben in C++ guten, wartbaren und fehlerfreien Code schreiben können deutlich kleiner ist als die Nachfrage. Wenn die es bei Google, wo die Qualität vermutlich überdurchschnittlich ist, nicht in den Griff bekommen dann finde ich deine Aussage deutlich zu überoptimistisch.
    Ob Rust die Lösung ist weiß ich nicht (keine Erfahrung).
    Ich persönlich genieße managed Runtimes und Garbage Collection. Und wenn es wirklich gilt ganz enge Latenzen einzuhalten gilt kann ich immer noch ohne new arbeiten "Das ist meistens auch der schnellere und stabilere code."

  5. Re: Es führt kein Weg an Rust vorbei

    Autor: ultim 22.09.21 - 11:34

    Atomic schrieb:
    --------------------------------------------------------------------------------
    > dangi12012 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Also Flugzeuge
    > War in der Boing 737 Max 9 nicht ein Softwareproblem ursächlich?

    Doch, der Fehler hatte aber nichts mit Speicherverwaltung zu tun, und Rust würde aber dort helfen.

  6. Re: Es führt kein Weg an Rust vorbei

    Autor: knabba 22.09.21 - 11:45

    Steffo schrieb:
    --------------------------------------------------------------------------------
    > Die Anforderungen und auch die Programme werden immer komplexer. Mit
    > Sprachen, die vor vielen Jahrzehnten designt wurden und die Schwächen im
    > Kern nicht ausgemerzt werden können, ist keine sichere und stabile Software
    > zu erreichen.
    Sehe ich auch so. Man schiebt das Problem nur in die Zukunft. Das erzeugt dann wertlosen Code wenn man ihn dann doch umschreiben muss.
    Ich habe C auch gerne programmiert aber man muss dann einfach in den sauren Apfel beißen und neu lernen und den Code neu schreiben.

  7. Re: Es führt kein Weg an Rust vorbei

    Autor: nuclear 22.09.21 - 11:57

    Ach und du hast immer die extra Ressourcen überall? Zum Beispiel auf einem Mikrocontroller?
    Und was ist mit C++ denn falsch, wenn man Smart Pointer verwendet? Damit umgehst du beeile Speicherlücken direkt.

    Klar wenn man die gesamte Entwicklung der Sprache in den letzten zehn Jahren raus lässt, dann ist die Sprache zu alt. Wenn man aber die neuen Features nutzt, dann ist es echt kein Problem und läuft schnell und sicher.

    Ich denke eher es ist ein Problem der Entwickler die sich einfach nicht fortbilden wollen und somit wäre auch Rust ebenfalls raus.

  8. Re: Es führt kein Weg an Rust vorbei

    Autor: ultim 22.09.21 - 12:05

    Steffo schrieb:
    --------------------------------------------------------------------------------
    > Die Anforderungen und auch die Programme werden immer komplexer. Mit
    > Sprachen, die vor vielen Jahrzehnten designt wurden und die Schwächen im
    > Kern nicht ausgemerzt werden können, ist keine sichere und stabile Software
    > zu erreichen.

    C++ heute ist aber auch nicht dasselbe C++ wie vor zwei Jahrzehnten. Schreibst du modernes C++-Kod, nicht im alten Stil von 2000, sondern Kod wo du moderne Features von der Sprache und vom stdlib konsequent einsätzt, dann ist es einfach in C++ Speicherfehler zu vermeiden. Klar man muss diese (neu)lernen. Aber mit Rustkenntnissen ist man auch nicht geboren.

  9. Re: Es führt kein Weg an Rust vorbei

    Autor: ultim 22.09.21 - 12:44

    herc schrieb:
    --------------------------------------------------------------------------------
    > ich frage mich auch was, wenn man nur modernes C++ nutzt (z.b. shared_ptr,
    > lock_guards, also das RAII prinzip konsequenz durchzieht)?
    > en.cppreference.com
    >
    > interessant wäre eine analyse, ob man - wenn man nur die modernen
    > funktionen von c++ nutzt - eine zumindest halbwegs vergleichbare sicherheit
    > im vergleich zu rust erreichen kann? oder geht das prinzipiell nicht auf
    > dem gleichen level?

    Eben, dann geht es mit C++ auch sehr gut und sicher.

    Nur, vollständigkeitshalber muss ich sagen, shared_ptr ist gerade nicht die Lösung und ist ein schlechtes Beispiel. Mit shared_ptr weisst du immer noch nicht wer der eigentliche Owner sein soll, und bekommst ausserdem ganz leicht Zirkuläre Referenzen. Beide Phänomene führen dann meist zu Speicherleaks. shared_ptr ist nur die Notlösung für ganz spezielle Fälle, darf aber nicht der Standardhammer sein. Die richtige Antwort lautet unique_ptr (und Paramter-Passing über normale Pointer, falls kein Ownership-Transfer stattfindet). Zusammen mit anderen Werkzeugen wie RAII, std::array+vector, string_view, Iteratoren, range-based for, Referenzen, usw. hat man dann potenzielle Speicherprobleme sehr gut im Griff.

    Nur leider sind die meisten von diesen Sachen erst ein paar Jahre alt, und eine ganze Generation von C++-Entwicklern muss jetzt umgeschult werden. Und dann haben wir noch das Problem vom "existing Kod". Beide dieser Probleme (Umschulung und existing Code) hat man aber ganz gleich mit Rust auch. Mit Rust aber ist sowohl der Umschulungsaufwand sowie der Rewriteaufwand wesentlich größer, und es gibt noch zusätzliche Probleme, wie das nicht-Existenz von Tooling, Standards, Kompatibilität, Collective Knowledge, Tauglichkeit für Safety-Critical (siehe aktuelle Diskussionen und Arbeiten zu "fallible Allocation" zum Beispiel), der generell viel höhere Entwicklungsaufwand für neues Kod, usw. Ein Teil dieser Probleme kann mit der Zeit natürlich ausgeschmerzt werden. Erst dann sollten wir aber die wichtige Software umschreiben, nicht früher.



    2 mal bearbeitet, zuletzt am 22.09.21 13:01 durch ultim.

  10. Re: Es führt kein Weg an Rust vorbei

    Autor: sre 22.09.21 - 13:39

    Ich halte es für Falsch einfach zu sagen "unique_ptr" ist richtig, "shared_ptr" ist falsch.
    Ja zirkukläre Referenzen sind schnell ein Problem wenn man shared smartpointer nutzt (weil die refcounts halt nie 0 werden).
    Aber das sind sie auch in allen Sprachen mit GC (python, java, you name it).
    Schließlich ist ein smart_ptr mit seinem refcount im Kern nichts anderes als eine art "pointer-atomare garbage collection").

    Zur Vermeidung von use-after-free sind shared_ptr sehr wohl ein valides Mittel.
    Außerdem ist ihre grundlegende Verwendung der normaler Pointer sehr viel ähnlicher.
    Davon abgesehen gibt es mehr als genug Fälle in denen es eben keinen einzelnen "owner" gibt sondern ein "delete after use".
    Das dürften auch die Fälle sein in denen es am häufigsten zu use-after-free Problemen kommt.
    Bei ownership-transfers verliert man schnell mal den Überblick ob vielleicht noch jemand anders zugreifen wollen könnte.

    In einem existierenden Projekt unique_ptr umzusteigen ist obendrein in der Regel mit erheblich mehr Anpassungsaufwand verbunden da er nicht kopiert werden darf, etc. Hier muss dann jeder owner-ship transfer mit std::move realisiert werden. Es erzeugt dann einfach mehr code wie eigentlich notwendig.

    Einen shared_ptr hingegen kann man im Idealfall einfach "einsetzen", die zugehörigen "delete" entfernen (oder mit ptr.reset() leeren) und glücklich werden.

    Ich selbst arbeite viel an einem Projekt mit einen c++ Kern und einer integrierten Python runtime, da würde man mit unique-pointern verrückt werden.

    Ich persönlich bin froh wenn ich nicht wissen muss wem genau ein Pointer jetzt gehören MUSS sondern weiß, dass der pointer selbst weiß wann er gehen darf.
    Natürlich gibt es sehr valide Einsatzszenarien für unique_ptr, aber am Ende sollte ein Entwickler selbst wissen wann welche der Optionen die Ideale ist, denn auch ein weak_ptr kann oft eine sehr gute Wahl sein.

    Nachtrag: Tippfehler und Unklarheiten korrigiert..



    5 mal bearbeitet, zuletzt am 22.09.21 13:53 durch sre.

  11. Re: Es führt kein Weg an Rust vorbei

    Autor: sre 22.09.21 - 13:40

    PS: Lieber ein memleak wie eine Sicherheitslücke!



    2 mal bearbeitet, zuletzt am 22.09.21 13:45 durch sre.

  12. Re: Es führt kein Weg an Rust vorbei

    Autor: FlowPX2 22.09.21 - 13:56

    Das Problem ist das Software über viele Jahre wächst, oftmals übernimmt man den Code von den Vorgängern. Und die Vorgänger haben den Code im besten Fall so geschrieben, wie es damals einfach best practice war, aber wahrscheinlich eher nicht, jeder von uns kennt große Software Projekte.
    Aber man kann auch nicht einfach den kompletten Code mal schnell auf den aktuellen Stand bringen, sowas dauert Jahre bei großen Projekten.
    Der Vorteil von Rust ist, man wird gezwungen sauberen Code zu schreiben, bei C++ selbst wenn man sich an modernes C++ orientiert ist es immer noch einfach schlechten Code zu schreiben.
    Google wird sicherlich nicht die schlechtesten Entwickler haben, es wird einen guten Grund geben, warum sie mit Rust experimentieren, statt einfach zu sagen wir halten uns an den neuen C++ Standard und alles wird gut.

    Wenn ich die Wahl zwischen C++ und Rust habe würde ich Rust bevorzugen, leider werden wenige Rust Entwickler noch gesucht und es gibt noch viele Bibliotheken die einfach Fehlen, weshalb man aktuell noch oft auf vorhandene C oder C++ Libraries zurückgreifen muss, sobald es eine komplexere Anwendung wird.

    Aber Rust gibt beim Entwickeln ein gutes Gefühl, es ist gut Strukturiert, der Compiler ist mega hilfsbereit mit seinen Aussagen. Hardware nahe Entwicklung ist gut möglich obwohl es sich kaum so hardware nah anfühlt (positiv gemeint).

  13. Re: Es führt kein Weg an Rust vorbei

    Autor: sre 22.09.21 - 14:07

    Ich verstehe voll und ganz was du meinst.
    Und Rust ist ja unterm Strich ziemlich "unumstritten".

    Auch wenn ich bisher noch keine Zeit gefunden habe mich endlich mal ausgiebig damit zu beschäftigen.

  14. Re: Es führt kein Weg an Rust vorbei

    Autor: M.P. 22.09.21 - 16:06

    Ein Compiler-Switch, der es unmöglich macht "unmodernen" C++-Code zu schreiben. wäre interessant ...

    Ein altes C++ Schlachtross von Programmierer fällt sonst im Stress doch wieder in alte Gewohnheiten zurück...

  15. Re: Es führt kein Weg an Rust vorbei

    Autor: fingolfin 22.09.21 - 20:15

    sre schrieb:
    --------------------------------------------------------------------------------
    > Ich halte es für Falsch einfach zu sagen "unique_ptr" ist richtig,
    > "shared_ptr" ist falsch.
    > Ja zirkukläre Referenzen sind schnell ein Problem wenn man shared
    > smartpointer nutzt (weil die refcounts halt nie 0 werden).
    > Aber das sind sie auch in allen Sprachen mit GC (python, java, you name it).

    Das ist schlicht falsch, und ein Unterschied zwischen RefCounting und "echtem" GC: in letzterem (wie es auch in Java verwendet wird) stellen zirkuläre Referenzen kein Problem da.

  16. Re: Es führt kein Weg an Rust vorbei

    Autor: Steffo 22.09.21 - 20:28

    An die Leute, die mit dem Modernes-C++-Ist-Aber-Genau-So-Gut-Quatsch kommen:

    https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

    Darüber hinaus würde Google nicht über Rust nachdenken, wenn sie ihre Probleme mit modernem C++ hinbekommen würden. Gleiches gilt für Microsoft.

    Weiter verhindert Rust Data Races zur Compilezeit! Das kann keine andere (Mainstream-)Sprache.
    Das undefinierte Verhalten in C++ ist ebenfalls ein Problem, das viele C++ Verfechter nicht wirklich wahrnehmen.

  17. Re: Es führt kein Weg an Rust vorbei

    Autor: Steffo 22.09.21 - 20:30

    nuclear schrieb:
    --------------------------------------------------------------------------------
    > Ach und du hast immer die extra Ressourcen überall? Zum Beispiel auf einem
    > Mikrocontroller?

    Das musst du mir nun erklären. - Ich bin gespannt...

    > Und was ist mit C++ denn falsch, wenn man Smart Pointer verwendet? Damit
    > umgehst du beeile Speicherlücken direkt.

    https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

    > Ich denke eher es ist ein Problem der Entwickler die sich einfach nicht
    > fortbilden wollen und somit wäre auch Rust ebenfalls raus.

    C++ mit seinen ganzen Altlasten, wo Neues einfach draufgeklatscht wird und seinem undefiniertem Verhalten, ist deutlich komplexer zu händeln.

  18. Re: Es führt kein Weg an Rust vorbei

    Autor: ultim 23.09.21 - 06:34

    Steffo schrieb:
    --------------------------------------------------------------------------------
    > An die Leute, die mit dem Modernes-C++-Ist-Aber-Genau-So-Gut-Quatsch
    > kommen:
    >
    > https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

    Das sind ziemlich blöde Beispiele gegen C++. "Modernes C++ verwenden" heisst nicht, dass zB. in C++17 man keinen Fehler mehr machen kann egal wie stark man versucht. Es bedeutet, wenn man die Werkzeuge versteht und richtig einsetzt. dann vermeidet man die Fehler. Und die Beispiele in dem von dir gelinktem Artikel zeigen wenig Verständnisse von den Features:

    1. Bzgl shared_ptr: Da müsste man als Programmierer gefragt haben, warum habe ich den Pointer überhaupt als shared_ptr bekommen? Natürlich weil der Caller über den Lifetime des Objekts mir keine Garantien macht! Also warum erhöhe ich den Reference-Count nicht wenn ich den Wert später brauche? Der Satz "And yes, people really do write code that handles std::shared_ptr<T>&, often as an attempt to avoid additional increment and decrements on the reference count." ist komplett falsch platziert und irreführend. Denn man verwendet std::shared_ptr<T>& natürlich nur um shared_ptrs zu Funktionen als Parameter zu übergeben, und das wäre hier in f() auch kein Problem gewesen.

    2. Bzgl. std::optional<T>: Der Punkt von std::optional ist eben dass es vlt. keinen Wert enthält, und diese Intention wird klar durch std::optional kommuniziert. Warum checkt der Autor das also nicht mit .has_value()? Nur damit er seinen falschen Punkt forcieren kann. Aber man muss sich daran gar nicht erinnern den Wert vorher zu checken. Man verwendet normalerweise eben die .value() oder value_or() Funktionen, die keinen Speicherfehler ergeben auch wenn das Optional gerade leer ist. Dazu müsste man aber das Feature kennen und nicht nur einen blöden Artikel schreiben, der zeigt wie schlecht man die Sprache kennt.

    3. Bzgl. std::span<T>: Was will er hier zeigen? Dass wenn man span als eine Art Container verwendet dann überprüft span die Bounds nicht? spans dienen als Adapter zu stdlib Algorithmen und Containern. Mit anderen Worten, im Gegensatz zB zu Smart Pointers sind spans überhaupt kein Safety-Feature, sondern ein Komfort-Feature. Wenn der Autor versucht, ein span als ein Safety-Feature zu verwenden, dann hat er wenig Ahnung wozu das Feature dient.

    Man kann einem den besten Hammer in die Hände geben, wenn er absichtlich versucht, den Nagel nicht zu treffen, oder nicht einmal lernen will was Nägel sind, dann ist ein Hammer in seinen Händen, unüberraschend, hoffnungslos. Natürlich *kann* man in modernem C++ auch Fehler machen. Wird aber echt schwierig wenn man die Features versteht und richtig einsetzt und für den Zweck dem sie dienen. Ja man muss diese Features lernen, das stimmt. Ist immer noch 1000x mal weniger Aufwand als Rust.

  19. Re: Es führt kein Weg an Rust vorbei

    Autor: sre 23.09.21 - 12:58

    fingolfin schrieb:
    --------------------------------------------------------------------------------
    > Das ist schlicht falsch, und ein Unterschied zwischen RefCounting und
    > "echtem" GC: in letzterem (wie es auch in Java verwendet wird) stellen
    > zirkuläre Referenzen kein Problem da.

    Es ist nicht falsch, nur vereinfacht und von mir aus auch unvollständig erklärt. Aber es als Falsch zu deklarieren ist jetzt auch nicht viel besser...

    Ja, eine gute GC hat obendrein noch einen sog. "cycle detector".
    Der primäre Mechanismus ist trotzdem ganz normales RefCounting (egal ob java oder python). In Java und Python arbeitet der "cycle detector" nach dem "unreachable" Prinzip.
    Er kann den Refcount also auch NUR dann auf 0 setzen, wenn die Instanz nicht mehr anderweitig erreichbar ist.

    Trotzdem gibt es mehr als genug memleaks weil eine Instanz durch eventuell überbordende zikruläre Abhängigkeiten in alle Richtungen eben nicht unreachable wird.
    Passiert super schnell wenn man an den entscheidenen Stellen keine WeakReference nutzt.

    Von all dem abgesehen sind solche Probleme normalerweise mit entsprechenden Tools recht einfach zu finden.
    In python kannst du sowas z.B. mit einem einfachen print lösen in welchem du dir alle Abhängikeiten einer Instanz ausgeben lässt.

    Ist das in "memory safe" Sprachen wie Rust besser gelöst?
    Natürlich!
    Können wir deshalb ab sofort alle aufhören irgendwas in C/C++ zu programmieren und so tun als hätte es das nie gegeben?
    Natürlich nicht!

    Nachtrag: Was ich damit eigentlich sagen möchte: Auch eine ausgereifte GC schützt nicht davor, dass man über die korrekte Anwendung und die Gefahren zirkulärer Abhängigkeiten bescheid wissen muss. Sonst hätten nämlich WeakReferences keine Existenzberechtigung.



    4 mal bearbeitet, zuletzt am 23.09.21 13:08 durch sre.

  20. Re: Es führt kein Weg an Rust vorbei

    Autor: Steffo 23.09.21 - 15:03

    Sorry, aber die Punkte, die der Autor da anführt, habe ich so schon in Produktivcode gesehen!
    Sogar Linter wie clang-tidy schlagen einen vor ein const ref bei Smartpointern zu machen, wenn man den als read-only nutzt..
    Gerade die, die sagen, modernes C++ sei so sicher, kommen mit dem Argument, dass modernes C++ und statische Code-Analyse genau so sicher sei wie Rust. - Ist es nicht. Ich weiß das selbst aus meinem Alltag mit C++.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Digitalisierungsexperte (Smart Factory) und Lean Manager (m/w/d)
    Knauf Gips KG, Iphofen bei Würzburg
  2. IT Manager / Digitalisierungsarchitekt (m/w/d)
    Siedlungswerk GmbH, Stuttgart
  3. KIS-Betreuer iMedOne (m/w/d)
    Helios IT Service GmbH, Leipzig
  4. DevOps Engineer (m/f/d) for Embedded Software Integration
    Elektrobit Automotive GmbH, Erlangen

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 19,99€
  2. 36,99€
  3. PC, PS5, PS4, Xbox, Switch


Haben wir etwas übersehen?

E-Mail an news@golem.de