Von C zu Rust wechseln?

Das ist der große Unterschied: Man KANN in C++ Speichersicher programmieren, man kann es aber NICHT garantieren. In Rust kann man es IMMER garantieren, außer halt in den unsage Blocks. C++ ist aus der Sicht von Rust ein einziger unsafe-Block. Menschen machen IMMER Fehler. Bei Rust hilft der Compiler, solche Fehler erst gar nicht aufkommen zu lassen.

Der Rustcompiler ist selbst in Rust geschrieben und Speicherfehler sind da wirklich äußerst unwahrscheinlich. In C++ ist es sehr unwahrscheinlich ein C++ Programm zu schreiben das keine Speicherfehler enthält. Je komplexer das C++ Programm wird, desto mehr solcher Fehler werden sich einschleichen. In Rust ist es egal wie komplex oder groß das Projekt wird, oder wie firm die Leute in Punkto Speichersicherheit sind. Der Compiler lässt solche Fehler gar nicht erst zu und das ist der große Punkt.

Javaprogramme sollen, so ich gelesen habe, auch nicht so 100% frei von Speicherlecks sein. Da habe ich aber zu wenig Ahnung von.

C++ wird ja hier immer so verteidigt weil eben der Compiler so viele Fehler abfängt. Rust ist nun noch eine Tick schärfer und kann Dinge erkennen zu die ein C++ Compiler nie in der Lage sein kann.

Jodocus

In C++ ist es sehr unwahrscheinlich ein C++ Programm zu schreiben das keine Speicherfehler enthält. Je komplexer das C++ Programm wird, desto mehr solcher Fehler werden sich einschleichen. In Rust ist es egal wie komplex oder groß das Projekt wird, oder wie firm die Leute in Punkto Speichersicherheit sind. Der Compiler lässt solche Fehler gar nicht erst zu und das ist der große Punkt.

Nein. Sowas ist, wenn man konsequent Smart-Pointer/RAII verwendet, ausgeschlossen.

Ethon

Ja. Am besten Guidelines etablieren und ein Senior Dev macht einen Code Review. Fertig.

Ethon

Rust ist nun noch eine Tick schärfer und kann Dinge erkennen zu die ein C++ Compiler nie in der Lage sein kann.

An was denkst du da?

Marthog

Jodocus schrieb:

Nein. Sowas ist, wenn man konsequent Smart-Pointer/RAII verwendet, ausgeschlossen.

Was ist mit dangling references, out of bounds und Race conditions?

Ethon

Marthog schrieb:

Jodocus schrieb:

Nein. Sowas ist, wenn man konsequent Smart-Pointer/RAII verwendet, ausgeschlossen.

Was ist mit dangling references, out of bounds und Race conditions?

Dangling References lassen sich zb durch die Verwendung von shared_ptr vermeiden.
Out of bounds mit boundchecks.
Channels kannst du auch in C++ implementieren.

Swordfish

Gedankenexperiment:

Hey Leute, ich habe eben angefangen, programmieren zu Lernen. Als Sprache habe ich mir dafür Rust ausgesucht, weil es so schön neu und hip ist. Gibt es irgendeinen Grund von Rust auf C umzusteigen?

Ethon

Ja. Kein Mensch programmiert in Rust. Mit C steht dir die halbe Welt offen, mit Rust garnichts.

Swordfish

Oh, wenn das so ist, dann werd' ich wohl besser C lernen anstatt Rust. Vielen Dank, Ethon!

Ethon

:p

Hey Leute, ich habe eben angefangen, programmieren zu Lernen. Als Sprache habe ich mir dafür C++ ausgesucht, weil es so schön neu und hip ist. Gibt es irgendeinen Grund von C++ auf C umzusteigen?

krümelkacker

Nochmal schrieb:

Hey Leute, ich habe eben angefangen, programmieren zu Lernen. Als Sprache habe ich mir dafür C++ ausgesucht, weil es so schön neu und hip ist. Gibt es irgendeinen Grund von C++ auf C umzusteigen?

Ja. C ist automatisch einfacher, weil der Sprachkern viel kleiner ist. Dinge wie RAII braucht kein Mensch; denn man kann auch leckfrei in C programmieren.

Swordfish

ich lecke aber gerne ... ähm. nein. vergesst den letzten Satz bitte wieder ...

Also wenn man sich diesen Benchmarkvergleich ansieht, dann ist Rust nicht besonders schnell.
C++ ist hier immer noch eine der schnellsten Sprache, aber an der Spitze steht mit einem Geschwindigkeitsvorteil von > 16 % gegenüber C++ D und das auch noch bei den wenigsten Zeilen Code, was für eine starke Ausdrucksstärke und auch wenig Arbeit für den Coder bedeutet.

Obwohl D hier also rein von den Zahlen am besten abschneidet wird es in der Praxis immer noch kaum benutzt, wie soll da Rust überhaupt nur eine Chance haben, wenn Rust von den drei Sprachen am langsamsten ist und der SLOC Wert auch kein großer Sprung gegenüber C++ ist?

https://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/

Hier gibt's mal eine Debatte zu C++, D, Rust und Go von den Profis (ihr kennt sie sicher alle, wenn ihr euch die Leute anschaut):

https://www.youtube.com/watch?v=BBbv1ej0fFo

krümelkacker

Also wenn man sich diesen Benchmarkvergleich ansieht, dann ist Rust nicht besonders schnell.

Verwechsle nicht Sprachen mit deren Implementierungen. Vom Sprachdesign her gibt es keine Gründe für Deine Beobachtung.

Obwohl D hier also rein von den Zahlen am besten abschneidet wird es in der Praxis immer noch kaum benutzt, wie soll da Rust überhaupt nur eine Chance haben, wenn Rust von den drei Sprachen am langsamsten ist und der SLOC Wert auch kein großer Sprung gegenüber C++ ist?

Ich kenne keine andere Sprache, die Speichersicherheit erreicht, ohne dabei auf Garbage Collection oder ausbremsende Checks zu setzen. Das ist es, was Rust für mich interessant macht. Du tickst da anscheinend anders. Und das ist ja auch okay.

Wenn man als D Programmierer wirklich über den Tellerrand guckt, dann kann da u.a. so etwas bei heraus kommen:
http://blog.dicebot.lv/2015/01/thoughts-about-rust-from-d-programmer.html

Ich hoffe, ich konnte Dir mit dieser Antwort helfen.

Ich hoffe, dass viel Software in Rust Stück für Stück neu geschrieben wird. Java hatte seine Sicherheitslücken auch nur C++ zu verdanken, wird Zeit dass man solche Sprachen nicht mehr bei sicherheitsrelevanten Programme einsetzt. Auch wenn der Umstieg viele Jahre oder Jahrzehnte dauert, er MUSS kommen.

Ethon

Ich finde es interessant dass Rust trotz llvm backend so abkackt. LLVM ist ja doch schon sehr ausgereift was Optimierungen etc angeht. Hätte C-gleich Performance erwartet.

SecurityFirst schrieb:

Ich hoffe, dass viel Software in Rust Stück für Stück neu geschrieben wird. Java hatte seine Sicherheitslücken auch nur C++ zu verdanken, wird Zeit dass man solche Sprachen nicht mehr bei sicherheitsrelevanten Programme einsetzt. Auch wenn der Umstieg viele Jahre oder Jahrzehnte dauert, er MUSS kommen.

blablabla.

Marthog

Ethon schrieb:

Ich finde es interessant dass Rust trotz llvm backend so abkackt. LLVM ist ja doch schon sehr ausgereift was Optimierungen etc angeht. Hätte C-gleich Performance erwartet.

Der Artikel ist von August 2013 und bis zur Implementierung von unboxed Closures war Rust total langsam.
Es entspricht auch fast keine Zeile noch gueltigem Rust.

EDIT: Hier gibt es z.B. was neues.

krümelkacker schrieb:

Ich kenne keine andere Sprache, die Speichersicherheit erreicht, ohne dabei auf Garbage Collection oder ausbremsende Checks zu setzen.

Was ist mit funktionalen Programmiersprachen wie Haskell & Co?

In der Luftfahrt und im Militärbereich setzt man AFAIK oft Ada ein und das wurde so weit ich weiß darauf optimiert, dass der erzeugte Code stabil läuft.
Wie wird bei Ada Speichersicherheit erreicht?

Wenn man als D Programmierer wirklich über den Tellerrand guckt, dann kann da u.a. so etwas bei heraus kommen:
http://blog.dicebot.lv/2015/01/thoughts-about-rust-from-d-programmer.html

Ich werde es mir noch durchlesen.