Von C zu Rust wechseln?

[Marthog]

Shade Of Mine schrieb:

dh es ist unmöglich in Rust schlechten Code zu schreiben?

Nein. Rust versucht nicht alles gegen mutwillige Zerstoerung abzudichten, sondern noch so viel Freiheit wie moeglich zu lassen. Man kann schon noch reference-counter mit cycles schreiben oder innerhalb von unsafe-Bloecken raw pointer oder data races zulassen. Es ist ist dafuer gemacht, Fluechtigkeitsfehler zu vermeiden.

Ethon schrieb:

Und diese "C++ ist unsicher"-Jammerei geht mir auch auf den Keks. Das stammt aus Zeiten, in dem man Software in C++ geschrieben hat, die heute zurecht in Java geschrieben wird. C++ taugt sowieso nur noch in Expertendomänen wirklich und die wissen wie man sicheres C++ schreibt.

Sichere Software und Java ist aber ein ziemlicher Widerspruch. In jedem Ausfuehrungsschritt kann man eine Nullreference haben. In C++ dagegen hat man wenigstens richtige Objekte und es ist gerantiert, dass sie existieren, solange man keine (smart-)pointer hat.

[Jodocus]

Speicherfehler sind sowas von 90er. Es gibt viel schlimmere Probleme wie Deadlocks und Race conditions und es sieht nicht so aus, als ob Rust da großartig neue Ideen mitbringt, um diese Probleme zu vermeiden.
Wenn man C++ gelernt und genug Selbstdisziplin dafür aufgewendet hat, sind die paar zusätzlichen Constraints von Rust für mich noch kein Grund, umzusteigen. Wenn Rust nicht wirklich was anderes (besseres) bietet, als was ich mit C++ schon habe, dann ist es wohl eher für Neueinsteiger interessant.

Ich sehe ehrlich gesagt auch kein Land für Sprachen wie Go, Rust, D und wie sie alle heißen, die neuen Systemsprachen numero uno zu werden. Die Tatsache, dass sich C damals durchsetzen konnte, war Unix. Dass C++ an vielen Stellen C den Rang ablaufen konnte war die 99%-tige Kompatibilität zwischen beiden.

Weder ein Kernel ist in Rust geschrieben, noch ist es kompatibel. Eine Rendering-Engine für einen Webbrowser reicht imho nicht, um es wirklich als Systemprogrammiersprache zu etablieren. Vielleicht in der Java/C#/D-Ecke.

[Über Tellerrand geschaut]

Rustiger schrieb:

Besser kann man das gar nicht beschreiben

Von der Sprache her, ist Rust jetzt schon vollwertiger C++ Ersatz. Jetzt liegt es "nur" noch an der Community. Ab der Finalversion ab März/April wird sich zeigen wie viel den Leuten die Sicherheit wirklich wert ist und ob sie Sicherheit gegen ihr gewohntes, aber unsicheres C++ eintauschen werden.

Der Übermut in das Vertrauen in die eigenen Programmierfähigkeiten ist bei Programmierern sehr groß, so dass sie eher bezüglich Sicherheit gefährliche Sprache in Kauf nehmen, aber dafür eine schöne Syntax haben.

Denn wenn es nur an der Sicherheit liegen würde, dann hätte sich Ada95 schon längst gegen C++ behaupten können.
Die Syntax von Ada mag aber nicht jeder und nicht jeder will vor einem Funktionsblock ein begin und später end schreiben.

Das gleiche Problem wird auch Rust haben, schau dir mal die Syntax an:

let i = from_str::<uint>("42");

das ist doch ein Griff ins Klo, so wie man sich da verbiegen muss.

Der Gedanke, eine Sprache zu haben, die ohne GC Speichersicherheit bietet ist zwar schön, aber beim Coden will sich niemand verrenken, weswegen eine Sprache, die sich nicht an die C Syntax anlehnt, wenig Erfolg haben wird.

Ada wurde nicht erfolgreich und bei Rust denke ich, dass es genauso wenig Chancen hat.
Dann schon eher D, denn das ist wesentlich näher am C Syntax Stil.

[Marthog]

Über Tellerrand geschaut schrieb:

Das gleiche Problem wird auch Rust haben, schau dir mal die Syntax an:

let i = from_str::<uint>("42");

das ist doch ein Griff ins Klo, so wie man sich da verbiegen muss.

Musst du nicht immer. In den meisten Faellen reicht wohl

let i = from_str("42");

aus und die Type-inference bestimmt dir das uint automatisch aus dem Kontext (davon abgesehen, dass uint jetzt usize heisst).
Wenn man es doch explizit angeben muss, bevorzuge ich

let i: usize = from_str("42");

[Über Tellerrand geschaut]

TyRoXx schrieb:

Ethon schrieb:

"]
Ich weiß nur sehr sicher dass bei uns niemand anfangen wird Linux Treiber in Rust zu schreiben.

Warum nicht? An fehlenden Bibliotheken kann es ja nicht liegen, denn die verwendet man bei Linux kaum.

Weil kein Kernel Entwickler einen Treiber in den offiziellen Linux Kernel Code aufnehmen würde, der in einer anderen Sprache als C geschrieben wurde.

Wildwuchs im Linux Kernel, ein Sammelsurium an Codeschnipseln in unterschiedlichen Sprachen, die will keiner.

Wer seine Closed Treiber in etwas anderes als C schreiben will, der kann das ja gerne probieren, aber in den Open Source Zweig kommt so etwas bestimmt nicht rein.

[Zeus]

Jodocus schrieb:

Weder ein Kernel ist in Rust geschrieben, noch ist es kompatibel. Eine Rendering-Engine für einen Webbrowser reicht imho nicht, um es wirklich als Systemprogrammiersprache zu etablieren. Vielleicht in der Java/C#/D-Ecke.

Troll weniger
https://github.com/charliesome/rustboot

Es würden schon Kernel in Managed Language geschrieben...

[fredder]

Jodocus schrieb:

Speicherfehler sind sowas von 90er. Es gibt viel schlimmere Probleme wie Deadlocks und Race conditions und es sieht nicht so aus, als ob Rust da großartig neue Ideen mitbringt, um diese Probleme zu vermeiden.

lol?
Rust garantiert dir, dass dein Programm keine Race conditions hat, wenn es kompiliert. (Ausser du zwingst es explizit auf.)

[Shade Of Mine]

Marthog schrieb:

Shade Of Mine schrieb:

dh es ist unmöglich in Rust schlechten Code zu schreiben?

Nein.

Exakt.
Keine Sprache schützt vor schlechten Programmieren.

Fehler kann man überall machen und Rust wird seine eigenen Fallstricke haben. Gute Programmierer schreiben mit jeder Sprache guten Code, schlechte Programmierer schreiben mit jeder Sprache schlechten Code.

[Shade Of Mine]

fredder schrieb:

Jodocus schrieb:

Speicherfehler sind sowas von 90er. Es gibt viel schlimmere Probleme wie Deadlocks und Race conditions und es sieht nicht so aus, als ob Rust da großartig neue Ideen mitbringt, um diese Probleme zu vermeiden.

lol?
Rust garantiert dir, dass dein Programm keine Race conditions hat, wenn es kompiliert. (Ausser du zwingst es explizit auf.)

Schau dir mal an was eine Race Condition ist und warum du das Problem auch in Rust haben kannst.

[fredder]

Shade Of Mine schrieb:

fredder schrieb:

Jodocus schrieb:

Speicherfehler sind sowas von 90er. Es gibt viel schlimmere Probleme wie Deadlocks und Race conditions und es sieht nicht so aus, als ob Rust da großartig neue Ideen mitbringt, um diese Probleme zu vermeiden.

lol?
Rust garantiert dir, dass dein Programm keine Race conditions hat, wenn es kompiliert. (Ausser du zwingst es explizit auf.)

Schau dir mal an was eine Race Condition ist und warum du das Problem auch in Rust haben kannst.

Genau genommen werden nur Data Races verboten.

[Jodocus]

Zeus schrieb:

Jodocus schrieb:

Weder ein Kernel ist in Rust geschrieben, noch ist es kompatibel. Eine Rendering-Engine für einen Webbrowser reicht imho nicht, um es wirklich als Systemprogrammiersprache zu etablieren. Vielleicht in der Java/C#/D-Ecke.

Troll weniger
https://github.com/charliesome/rustboot

Es würden schon Kernel in Managed Language geschrieben...

Toll! Dieser Kernel ist ungefähr genauso relevant wie der, den mein Kumpel in der Garage in PHP programmiert hat.
Nochmal: C hat sich durchgesetzt, weil Unix in C programmiert ist und als das beste damalige Betriebssystem Vorbild aller Weiterentwicklungen war, mitsamt C. Wenn Mozilla jetzt einen Rust-Browser programmiert, dann ist das ja ganz nett, aber hat sicher bei weitem nicht die selbe Bedeutung wie z.B. Unix. C++ ist nun mal Erbe dieser Entwicklung und wenn etwas C++ ablösen will, dann muss es entweder eine direkte, kompatible Weiterentwicklung sein (mitsamt aller Probleme, die C++ noch von C mitschleppt plus die C++-Probleme) oder etwas bahnbrechend neues wie es damals Unix war. Und Rust ist weder das eine, noch das andere Totgeburt wie D.

fredder schrieb:

lol?
Rust garantiert dir, dass dein Programm keine Race conditions hat, wenn es kompiliert. (Ausser du zwingst es explizit auf.)

Beispiel bitte! Das bezweifle ich stark. Mag sein, dass der Rust-Compiler speziell data races aufspüren kann, aber sicher nicht andere race conditions. Finde ich aber wenig interessant, denn wenn man über sein Software-Design nachgedacht hat, weiß man von vornherein, welche Daten zwischen Threads geteilt werden und mit Mutexen synchronisiert werden müssen. Wenn man Mutexe vergisst, hat man ganz woanders Probleme.
Die ganzen anderen Races/Deadlocks bleiben.

[Zeus]

Jodocus schrieb:

Zeus schrieb:

Jodocus schrieb:

Weder ein Kernel ist in Rust geschrieben, noch ist es kompatibel. Eine Rendering-Engine für einen Webbrowser reicht imho nicht, um es wirklich als Systemprogrammiersprache zu etablieren. Vielleicht in der Java/C#/D-Ecke.

Troll weniger
https://github.com/charliesome/rustboot

Es würden schon Kernel in Managed Language geschrieben...

Toll! Dieser Kernel ist ungefähr genauso relevant wie der, den mein Kumpel in der Garage in PHP programmiert hat.
Nochmal: C hat sich durchgesetzt, weil Unix in C programmiert ist und als das beste damalige Betriebssystem Vorbild aller Weiterentwicklungen war, mitsamt C. Wenn Mozilla jetzt einen Rust-Browser programmiert, dann ist das ja ganz nett, aber hat sicher bei weitem nicht die selbe Bedeutung wie z.B. Unix. C++ ist nun mal Erbe dieser Entwicklung und wenn etwas C++ ablösen will, dann muss es entweder eine direkte, kompatible Weiterentwicklung sein (mitsamt aller Probleme, die C++ noch von C mitschleppt plus die C++-Probleme) oder etwas bahnbrechend neues wie es damals Unix war. Und Rust ist weder das eine, noch das andere Totgeburt wie D.

Das ist keine sachliche Argumentation...

[Rustiger]

Das hier sind alles garantierte Features, da gibt es kein 99% der Fälle das ist 100%. Da braucht man keinen guten Programmierer, der Speicherfehler oder Data Races vermeiden vermag, das macht der Compiler zu 100%.

- zero-cost abstractions
- move semantics
- guaranteed memory safety
- threads without data races
- trait-based generics
- pattern matching
- type inference
- minimal runtime
- efficient C bindings

Ich glaube auch nicht, dass es ein großes Projekt in C++ gibt wo keine Speicherfehler vorhanden sind. Das ist doch auch der Hauptgrund warum Mozilla das C++ Gecko in den Müll wirft um es mit einer bessere Systemsprache neu zu machen. Sie haben aus den Fehlern gelernt. Ewig ein Sprache mit Flicken zu versehen, macht sie auch nicht schöner und beseitigt alte Probleme nur mit Disziplin der Programmierer. Dann kann man aber auch gleich in C entwickeln, das geht auch sicher wenn man genug aufpasst.

Aber es wird nie ein Mensch genau aufpassen, ein Compiler hingegen schon.

[fredder]

Jodocus schrieb:

Beispiel bitte! Das bezweifle ich stark. Mag sein, dass der Rust-Compiler speziell data races aufspüren kann, aber sicher nicht andere race conditions.

Um es klar zu stellen, es sind nur Data Races.

Finde ich aber wenig interessant, denn wenn man über sein Software-Design nachgedacht hat, weiß man von vornherein, welche Daten zwischen Threads geteilt werden und mit Mutexen synchronisiert werden müssen. Wenn man Mutexe vergisst, hat man ganz woanders Probleme.

Und? Nur weil man es weiss, heisst nicht, dass man es überall auch richtig macht. Wenn ich mir über das Ownership im Klaren bin und weiss, wann es Exceptions gibt, dann kann ich auch mit new/delete fahren und brauche keine Smartpointer.

Trotzdem haben sie sich als nützlich herausgestellt, da weniger Code und Garantie vom Compiler. Genau das ist auch bei Rust der Fall.

Die ganzen anderen Races/Deadlocks bleiben.

Eher nicht. C++ ist eine zurückgebliebene Sprache, bei der Multithreading so gut wie keinen Support hat. std::thread ist wie rohes new/delete. Manchmal braucht man es roh, aber es sollte quasi immer vermieden werden.

Multithreading betreibt man mit Tasks (Fibers). C++ hat da auch was, aber std::async ist unbrauchbar und std::future lahm (kein effizientes chainen).

Rust bietet da:
- Gute Bibliotheken
- Notwendige Sprachunterstützung

C++ hat für ersteres third-party Bibliotheken, aber sprachmässig ist es zurückgeblieben.

[Jodocus]

Zeus schrieb:

Jodocus schrieb:

Zeus schrieb:

Jodocus schrieb:

Weder ein Kernel ist in Rust geschrieben, noch ist es kompatibel. Eine Rendering-Engine für einen Webbrowser reicht imho nicht, um es wirklich als Systemprogrammiersprache zu etablieren. Vielleicht in der Java/C#/D-Ecke.

Troll weniger
https://github.com/charliesome/rustboot

Es würden schon Kernel in Managed Language geschrieben...

Toll! Dieser Kernel ist ungefähr genauso relevant wie der, den mein Kumpel in der Garage in PHP programmiert hat.
Nochmal: C hat sich durchgesetzt, weil Unix in C programmiert ist und als das beste damalige Betriebssystem Vorbild aller Weiterentwicklungen war, mitsamt C. Wenn Mozilla jetzt einen Rust-Browser programmiert, dann ist das ja ganz nett, aber hat sicher bei weitem nicht die selbe Bedeutung wie z.B. Unix. C++ ist nun mal Erbe dieser Entwicklung und wenn etwas C++ ablösen will, dann muss es entweder eine direkte, kompatible Weiterentwicklung sein (mitsamt aller Probleme, die C++ noch von C mitschleppt plus die C++-Probleme) oder etwas bahnbrechend neues wie es damals Unix war. Und Rust ist weder das eine, noch das andere Totgeburt wie D.

Das ist keine sachliche Argumentation...

Das ist auch kein Argument. Sachlich ist der Thread nach 10 Seiten schon lange nicht mehr. Ich habe nur meine Ansicht ggü. Rust kundgetan. Und fast alle Rust-Fanboys hier unterschätzen Kompatibilität gewaltig.

[fredder]

Jodocus schrieb:

Das ist auch kein Argument. Sachlich ist der Thread nach 10 Seiten schon lange nicht mehr. Ich habe nur meine Ansicht ggü. Rust kundgetan. Und fast alle Rust-Fanboys hier unterschätzen Kompatibilität gewaltig.

Kompatibilität ist gewährleistet.
Du kannst in Rust C-Funktionen exportieren und importieren.
Genau das gleiche wird übrigens sehr oft in C++ gemacht.

Es ist nur keine Source-Kompatibilität gegeben.

[Über Tellerrand geschaut]

Jodocus schrieb:

Nochmal: C hat sich durchgesetzt, weil Unix in C programmiert ist und als das beste damalige Betriebssystem Vorbild aller Weiterentwicklungen war, mitsamt C.

Es hat sich auch durchgesetzt, weil es geringe Speicheranforderungen für den Compiler stellte und somit auch auf schwachen Maschinen im Vergleich zu den anderen Sprachen gut umsetzbar war, was damals bei der damaligen Hardware ein sehr starkes Argument war.

Man hat z.B. bei der Zuweisung den Doppelpunkt eingespart,
aus:
int i := 10;
wurde
int i = 10;

und das sparte 1 Byte pro Zuweisung.

[Marthog]

Jodocus schrieb:

Beispiel bitte! Das bezweifle ich stark. Mag sein, dass der Rust-Compiler speziell data races aufspüren kann, aber sicher nicht andere race conditions. Finde ich aber wenig interessant, denn wenn man über sein Software-Design nachgedacht hat, weiß man von vornherein, welche Daten zwischen Threads geteilt werden und mit Mutexen synchronisiert werden müssen. Wenn man Mutexe vergisst, hat man ganz woanders Probleme.
Die ganzen anderen Races/Deadlocks bleiben.

Es ist bei Rust allgemein nicht moeglich, Daten zwischen Threads zu teilen. Ausnahmen sind channels, Arc (threadsafe shared_ptr) auf eine Konstante, Futures und ich glaube, auch ein paar threadsichere Datenstrukturen.
Man kann aber auch ein Mutex in einen Arc ablegen. Ansonsten muss man unsafe-Bloecke verwenden und selber synchronisieren. Letzteres wird verwendet, wenn man selber eine Library fuer "interthreadkommunikation" schreibt.
In normalen Anwendungscode teilen die Threads normalerweise keine veraenderbaren Daten, sondern schieben diese ueber channels hin- und her. Das Programm designed man so, wie man es als vernuenftiger Programmierer auch in C++ machen wuerde.
Genauso ist es uebrigens auch beim Klassendesign: Der Compiler zwingt einen dazu, seinen Rust-Code so zu schreiben, wie man guten C++-Code designen wuerde.

[TyRoXx]

Marthog schrieb:

Es ist bei Rust allgemein nicht moeglich, Daten zwischen Threads zu teilen. Ausnahmen sind channels, Arc (threadsafe shared_ptr) auf eine Konstante, Futures und ich glaube, auch ein paar threadsichere Datenstrukturen.
Man kann aber auch ein Mutex in einen Arc ablegen.

Die sind übrigens alle in Rust geschrieben, mit unsafe natürlich.
Das ist das schöne an Rust: Da, wo man es möchte, wird Rust mit dem unsafe -Schlüsselwort zu "C++" mit allen Möglichkeiten und Gefahren bezüglich Speicher.

[ipsec]

Jodocus schrieb:

Speicherfehler sind sowas von 90er. … Wenn man C++ gelernt und genug Selbstdisziplin dafür aufgewendet hat, sind die paar zusätzlichen Constraints von Rust für mich noch kein Grund, umzusteigen.

Ich denke, man sollte bei diesen Betrachtungen nicht nur auf die Fehler achten, die tatsächlich im Endprodukt verhindert werden. Als Beispiel, eine ganz alltägliche Situation: eine externe Lib liefert (z.B. bei einem Containerinterface) eine Referenz auf ein Objekt. Woher weiß man, wie lange man diese Referenz behalten darf? Antwort: man weiß es nicht, man muss in der Doku nachschlagen. Natürlich ist einem C++-Programmierer in der Regel bekannt, dass Referenzen ungültig werden können. Wenn man also eine Referenz ungewöhnlich lange am Leben halten will, wird man sich immer vergewissern, dass das auch möglich ist. Sollte man es vergessen, wird der Bug vermutlich beim Testen gefunden. Schlussendlich ist es also bei einigermaßen Kompetenz des Programmierers unwahrscheinlich, dass ein Dangling-Reference-Bug tatsächlich im fertigen Programm landet. Aber trotzdem, und das ist der entscheidende Punkt, fordert die Situation Aufwand und Nerven während des Programmierens.
In Rust kann man einfach drauf los programmieren und muss sich um solche Dinge keine Gedanken machen. Wenn man eine Referenz speichern möchte, tut man das. Und sollte es falsch sein, gibt es einen Compilerfehler. Dadurch erlebt man eine gewisse angenehme Entspannung beim Programmieren. Eine ähnliche Erfahrung habe ich z.B. bei dem Typsystem von Haskell im Vergleich zu dem von C++ gemacht.

Darüber hinaus wird in dem Thread der Schwerpunkt sehr auf die Speichersicherheit gelegt, Rust hat aber auch noch viele andere Annehmlichkeiten. Eine sehr schöne Sache, die das Programmieren in vielen Situationen vereinfacht, sind z.B. Sumtypen (bzw. allgemeiner algebraische Datentypen) in Verbindung mit Pattern-Matching.

Noch ein Wort zu dem schlechten Code:

Shade Of Mine schrieb:

Keine Sprache schützt vor schlechten Programmieren.

Fehler kann man überall machen und Rust wird seine eigenen Fallstricke haben. Gute Programmierer schreiben mit jeder Sprache guten Code, schlechte Programmierer schreiben mit jeder Sprache schlechten Code.

Das Argument scheint mir zu allgemein. Es klingt so, als wären alle Sicherheitsmechanismen einer Sprache (bis hin zum Typsystem an sich) nutzlos, weil gute Programmierer sie nicht brauchen und schlechte Programmierer trotzdem Mist machen. Natürlich kann man in Rust auch schlechten Code schreiben, aber wenn eine Sprache den Programmierer mehr davor schützt, ist das trotzdem positiv.