Von C zu Rust wechseln?

[Realität]

hustbaer schrieb:

Realität schrieb:

Heartbleed war möglich, weil malloc selbst implementiert wurde, was nichts mit Geschwindigkeit zu tun hatte.

Wie kommst du darauf dass das nix mit Geschwindigkeit zu tun gehabt hat?

Ok, hier habe ich wohl Mist erzählt. Ich hatte das irgendwie in Erinnerung, dass das mit Features zusammenhing, was ich aber nicht durch Recherche nachvollziehen konnte.
Der Punkt ist: Eine eigene Implementierung war letztendlich Mist. Man macht so etwas nicht. Nichtsdestotrotz: Wenn man für ausgewählte Stellen unsichere Implementierungen haben will, dann geht das mit rust auch, aber so etwas ist nicht die Regel, sondern die Ausnahme. Das ist der entscheidende und eklatante Unterschied!

[cooky451]

Marthog schrieb:

An geschwindikeitskritischen Stellen wird man wahrscheinlich auf memcpy und damit unsafe-Bloecke zurueckgreifen.

Moment mal, ich verfolge das hier nur am Rande, aber bis jetzt schien es mir so als wuerde die "Speichersicherheit" von Rust durch Sprachmittel zur Compilezeit garantiert werden, warum sollte man also einen unsafe Block brauchen um effizient Speicher zu kopieren?

[Nathan]

Realität schrieb:

Der Punkt ist: Eine eigene Implementierung war letztendlich Mist. Man macht so etwas nicht.

Eigene Implementierung? Doch.

Nichtsdestotrotz: Wenn man für ausgewählte Stellen unsichere Implementierungen haben will, dann geht das mit rust auch, aber so etwas ist nicht die Regel, sondern die Ausnahme. Das ist der entscheidende und eklatante Unterschied!

Der Unterschied ist komplett irrelevant. Unabhängig vom Default, manche Programmierer werden unsafe verwenden, wie ich schon sagte. Das sind dann auch die, die rohe, besitzende Pointer in C++ verwenden. Solange Rust unsafe anbietet, werden es manche verwenden. Das ist simple Psychologie.

Nochmal: Gute Programmierer schreiben immer guten Code, schlechte Programmierer immer schlechten. Die Programmiersprache hat damit nichts zutun.
Und dieses C++ Gebashe ua. von NewHope nervt einfach nur. Es ist genauso gut möglich in C++ sichere Programme zu schreiben, wie in Rust unsichere. Punkt.

[Marthog]

Realität schrieb:

Nichtsdestotrotz: Wenn man für ausgewählte Stellen unsichere Implementierungen haben will, dann geht das mit rust auch, aber so etwas ist nicht die Regel, sondern die Ausnahme. Das ist der entscheidende und eklatante Unterschied!

Das Projekt war wohl auch ziemlich vermuellt. LibreSSL hat in wenigen Wochen 90,000 Zeilen ersatzlos geloescht und bei OpenSSL hat man wohl auch oft selber workarounds geschrieben, statt Bugs in irgendwelchen Libraries zu melden und dadurch sehr viel unnoetigen Muell implementiert. Vor dummen Projectmanagern schuetzt auch Rust nicht.

[Realität]

Wer in rust ständig unsafe benutzt, kann gleich bei C++ bleiben. Das wäre die falsche Zielgruppe. qed.

[Swordfish]

Wer in C++ ständig rohe besitzende Zeiger benutzt, kann gleich bei C bleiben. Das wäre die falsche Zielgruppe.

[müssen]

cooky451 schrieb:

Marthog schrieb:

An geschwindikeitskritischen Stellen wird man wahrscheinlich auf memcpy und damit unsafe-Bloecke zurueckgreifen.

Moment mal, ich verfolge das hier nur am Rande, aber bis jetzt schien es mir so als wuerde die "Speichersicherheit" von Rust durch Sprachmittel zur Compilezeit garantiert werden, warum sollte man also einen unsafe Block brauchen um effizient Speicher zu kopieren?

Ich sehe nicht wozu man memcpy braucht? Rust hat auch sowas wie PODs und jede Kopie wird dann zu memcpy.

Nathan schrieb:

Nochmal: Gute Programmierer schreiben immer guten Code, schlechte Programmierer immer schlechten. Die Programmiersprache hat damit nichts zutun.

Ja, bleib du bei Assembler.

Und dieses C++ Gebashe ua. von NewHope nervt einfach nur. Es ist genauso gut möglich in C++ sichere Programme zu schreiben, wie in Rust unsichere. Punkt.

Die Erfahrung hat gezeigt, dass es keine sicheren grösseren Programme gibt. Java Programme haben aber z.B. grundsätzlich weniger Probleme als C-Programme. Die Programmiersprache hilft nachweisbar.

[cooky451]

müssen schrieb:

Ich sehe nicht wozu man memcpy braucht? Rust hat auch sowas wie PODs und jede Kopie wird dann zu memcpy.

Genau sowas meinte ich. Solange der Compiler das ordentlich optimiert (aka nicht einen call fuer jedes einzelne copy generiert oder so, was kein grosses Problem sein sollte), gibt es an der Stelle doch ueberhaupt keinen Grund fuer einen unsafe Block, was das Performance-Argument von Marthog komplett entkraeftet.

müssen schrieb:

Java Programme haben aber z.B. grundsätzlich weniger Probleme als C-Programme. Die Programmiersprache hilft nachweisbar.

Ja? Gibt's da eine Statistik?

[Realität]

Swordfish schrieb:

Wer in C++ ständig rohe besitzende Zeiger benutzt, kann gleich bei C bleiben. Das wäre die falsche Zielgruppe.

Blödsinn. Weshalb hat Struppi damals C++ erfunden?!
Rohe Zeiger benutzt man heute außerdem noch für Legacy-Code.

[Nathan]

Realität schrieb:

Rohe Zeiger benutzt man heute außerdem noch für Legacy-Code.

Rohe, besitzende Zeiger. Nicht rohe Zeiger an sich.

[Marthog]

müssen schrieb:

Ich sehe nicht wozu man memcpy braucht? Rust hat auch sowas wie PODs und jede Kopie wird dann zu memcpy.

Wenn du ein Array mit zur Laufzeit gegebener Groesse anlegen und dann Daten da rein kopieren willst, machst du das idealerweise mit memcpy, wobei in dem Fall auch dein Klassendesign sowohl in C++ als auch in Rust falsch ist.

cooky451 schrieb:

Moment mal, ich verfolge das hier nur am Rande, aber bis jetzt schien es mir so als wuerde die "Speichersicherheit" von Rust durch Sprachmittel zur Compilezeit garantiert werden, warum sollte man also einen unsafe Block brauchen um effizient Speicher zu kopieren?

Wie ich bereits ausgefuehrt habe, ist es ist es sowohl in Rust als auch in C++ guter Stil, statt einem voralloziierten Speicherblock die fertige vector- bzw Vec-Klasse zu nehmen und mit einem iterator einzufuegen. In beiden Sprachen ist das sicher, generischer und sollte geschwindigkeitsmaessig einem memcpy in etwa gleich kommen.

müssen schrieb:

Java Programme haben aber z.B. grundsätzlich weniger Probleme als C-Programme. Die Programmiersprache hilft nachweisbar.

Bei der letzten grossen messung kam das Gegenteil raus. In C++ werden memory leaks und aehnliche Fehler meistens bereits durch das design vermieden und ausserdem sind die Bugfixes deutlich schneller draussen. Letzteres wahrscheinlich weil es ernster genommen wird oder die Programmierer im Debuggen besser sind.

Realität schrieb:

Swordfish schrieb:

Wer in C++ ständig rohe besitzende Zeiger benutzt, kann gleich bei C bleiben. Das wäre die falsche Zielgruppe.

Blödsinn. Weshalb hat Struppi damals C++ erfunden?!

Um OOP und generische Konzepte in C einzubauen und trotzdem noch codekompatibilitaet zu C zu halten. Nach eigener Aussage sei es sehr einfach, eine gute Sprache zu designen und nur wegen der Kompatibilitaet C++ so erfolgreich gewesen.

[ipsec]

Nathan schrieb:

Gute Programmierer schreiben immer guten Code, schlechte Programmierer immer schlechten. […] Es ist genauso gut möglich in C++ sichere Programme zu schreiben, wie in Rust unsichere. Punkt.

Das ist richtig. Aber daraus folgt keine der folgenden Aussagen:
- Code, den ein guter Programmierer in Rust schreibt, ist genau so gut wie der, den er in C++ schreibt.
- Code, den ein schlechter Programmierer in C++ schreibt, ist genau so schlecht wie der, den er in Rust schreibt.
- Der durchschnittliche Programmierer schreibt mit C++ genau so guten Code wie mit Rust.
- Der durchschnittliche Programmierer schreibt mit C++ genau so sicheren Code wie mit Rust.
- Der durchschnittliche Programmierer macht genau so viele Fehler in Rust wie in C++.
- Ein durchschnittliches C++-Programm ist genau so sicher wie ein durchschnittliches Rust-Programm (z.B. bezüglich Speicherfehler).
- C++ ist in puncto Sicherheit genau so gut wie Rust.

Insofern liefert deine Aussage keinen Mehrwert zu der Diskussion, weil eben nicht irgendein Vergleich zwischen C++ und Rust abgeleitet werden kann.

[QutaschMitSoße]

So ein Unsinn. Du hast rein gar nichts von Rust verstanden.

[großbuchstaben]

Marthog schrieb:

In C++ werden memory leaks und aehnliche Fehler meistens bereits durch das design vermieden

Gut, dann brauche ich ja nicht zu rust zu wechseln (hatte ich eh' nicht vor)

[Marthog]

großbuchstaben schrieb:

Gut, dann brauche ich ja nicht zu rust zu wechseln (hatte ich eh' nicht vor)

Ich habe das trotzdem gemacht, weil ich das Programmieren einfacher finde. Keine unnoetigen move-Aufrufe oder copy-constructors, automatische Generierung einfacher Operationen wie Vergleiche, Debug-Print, pattern matching statt grosser if-verzweigungen, bloecke als expressions, array-referenzen in die Sprache eingebaut, enums statt Variant, viel einfachere und maechtigere iteratoren, eingebaute tuples, type inference, bessere Fehlermeldungen, bessere Standard-library, einfaches Multithreading, besseres Errorhandling und viel weniger Debuggen.

[krümelkacker]

Marthog schrieb:

Ich habe das trotzdem gemacht, weil ich das Programmieren einfacher finde. Keine unnoetigen move-Aufrufe oder copy-constructors, automatische Generierung einfacher Operationen wie Vergleiche, Debug-Print, pattern matching statt grosser if-verzweigungen, bloecke als expressions, array-referenzen in die Sprache eingebaut, enums statt Variant, viel einfachere und maechtigere iteratoren, eingebaute tuples, type inference, bessere Fehlermeldungen, bessere Standard-library, einfaches Multithreading, besseres Errorhandling und viel weniger Debuggen.

Ich mag auch cargo als Build- und Abhängigkeitsmanagement-Tool und das Ökosystem drumherum. Hab sogar jetzt mal ein kleines crate auf crate.io hochgeladen: crc24 für die Berechnung von CRC-24 Prüfsummen nach IETF RFC2440.

[Kaum ne Woche Weg]

Seid ihr eigentlich immer noch nicht fertig mit der Rust Diskussion?

[Nathan]

krümelkacker schrieb:

Ich mag auch cargo als Build- und Abhängigkeitsmanagement-Tool und das Ökosystem drumherum.

Sowas gibts aber auch für C++: biicode.com

[großbuchstaben]

Marthog schrieb:

Ich habe das trotzdem gemacht, weil ich das Programmieren einfacher finde. Keine unnoetigen move-Aufrufe

hab' ich mit C++ auch nicht.

Marthog schrieb:

oder copy-constructors,

hab' ich mit C++ auch nicht, jedenfalls keine unnötigen, und wenn sie nötig sind, dann bin ich eigentlich eher froh, daß ich sie explizit machen muß.

Marthog schrieb:

automatische Generierung einfacher Operationen wie Vergleiche, Debug-Print,

Debug-print hört sich ungefähr nach dem an, was ich mit do-it-yourself Protokoll-Klassen mache

Marthog schrieb:

pattern matching statt grosser if-verzweigungen,

große if-Verzweigungen habe ich nicht, selten mal zweistufig. Tiefe if-Bäume halte ich nur in Ausnahmesituationen für guten Programmierstil.

Marthog schrieb:

viel einfachere und maechtigere iteratoren,

in C++ kann ich Iterator-Klassen selbst definieren, mehr Flexibilität kann ich mir nicht vorstellen.

Marthog schrieb:

eingebaute tuples,

"eingebaut" ist weniger flexibel als entsprechende Klassen in der standard lib. Dito mit syntaktischen Erweiterungen. Die C++-Strategie "eher die standard lib als die Syntax erweitern" ist schön flexibel, da im Bedarfsfall austauschbar.

Marthog schrieb:

type inference,

auto

Marthog schrieb:

bessere Fehlermeldungen,

das würde ich mir bei Template-Code öfter wünschen. Aber erstens wechsle ich deswegen nicht die Sprache, und außerdem werden die "concepts" (war glaub' schon bei C++0x im Gespräch, hat es aber leider nicht in C++11 geschafft) hier wohl Verbesserungen bringen, da die Anforderungen an Typ-Parameter verexplifiziert werden, was den Compiler früher erkennen läßt, ob eine Template-Instanziierung zulässig sein wird.

Marthog schrieb:

bessere Standard-library,

mir fehlt in der C++11 Standard lib erstmal nichts, im Gegenteil, ich finde sie mit smart pointer, threads u.v.a. recht üppig ausgestattet.

Marthog schrieb:

einfaches Multithreading,

darüber ließe sich diskutieren. Aber ob man das in die Sprach-Syntax einbauen soll, ist diskussionswürdig - mit einer entsprechend ausgestatteten standard lib ist man flexibel und könnte wahlweise aus Prozessebene, aus Threadebene, aus noch-mehr-lightweight- oder Coroutine-Ebene auswählen, was man braucht.

Marthog schrieb:

besseres Errorhandling und viel weniger Debuggen.

ich entwickle täglich C++ und brauche den Debugger fast nie. Mein Entwicklungsstil ist "erst denken, dann tippen, dann testen" und kostet mich typischerweise weniger Zeit als "erst tippen, dann testen, dann debuggen, dann denken, dann neu tippen"

[ipsec]

Ich gehe bewusst nur auf zwei einzelne Punkte ein:

großbuchstaben schrieb:

"eingebaut" ist weniger flexibel als entsprechende Klassen in der standard lib. Dito mit syntaktischen Erweiterungen. Die C++-Strategie "eher die standard lib als die Syntax erweitern" ist schön flexibel, da im Bedarfsfall austauschbar.

Ich mag den C++-Ansatz auch sehr und finde es unschön, wenn andere Sprachen mit Features vollgeknallt werden, die man genau so gut als Bibliothek anbieten könnte. Allerdings hat die Strategie auch Nachteile, etwa schlechtere Integration. Beispiel: bevor es Lambdas gab, nahm man oft boost::lambda (inzwischen sogar Teil des Standards). Und im Prinzip ist es auch eine tolle Idee, dass man sich anonyme Funktionen mit _1 * 2 , _1 + _1 o.ä. bauen kann. Aber z.B. sqrt(_1) geht nicht. Offenbar fand man die Einschränkungen groß genug, um Lambdas als Sprachfeature aufzunehmen.

großbuchstaben schrieb:

Marthog schrieb:

type inference,

auto

Auto ist deutlich weniger mächtig als type inference. Type inference erlaubt das inferieren des Typs einer Variable auch daraus, wie sie später benutzt wird.