Von C zu Rust wechseln?

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...

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.

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...

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.

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.

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.

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.

Ich denke vielen C++ Leuten geht es gar nicht um mehr Sicherheit und auch nicht darum, dass der Compiler schon viele Fehler im Vorfeld ausmerzt. Ich bin aber sehr erstaunt dass einige hier das Potential der Sprache erkennen. So etwas gab es in der Form noch nie. Die meisten verteidigen einfach nur ihr C++ und zwar aus egoistischen Gründen, weil es ihnen zu wieder ist C++ ein Stück weit abzugeben.

Dabei muss man sich doch nur die Entwicklung ab Mitte der 90er anschauen. C++ wurde in immer mehr Bereichen ersetzt und nun ist halt auch einer der letzten Domänen dran, nämlich die Systemprogrammierung. Wenn es nicht Rust ist, dann einen andere Sprache. LLVM macht es einfach viele neue Frontend für neue Sprachen zu entwickeln.

Alles was einen C-Schnittstelle hat, wird in den neuen Sprachen verwendet werden können. Es ist also für eine ziemlich reibungslose Übergangszeit gesorgt.

Ob Rust sich da viel vom C und C++ Kuchen schnappen kann werden wir sehen. Eine Sprache wird es sicher irgendwann tun. Ich möchte nicht länger auf die Willkür von "guten" Programmierern angewiesen sein, je mehr Fehler vom Compiler entdeckt werden können um so besser.

Rust ist in meinen Augen ein Meilenstein in der IT-Geschichte.

Ethon

Rust ein Meilenstein? Jetzt wird's peinlich.
Rust hat nichts neues, nur etwas striktere Regeln, herp-derp.

Was Sicherheit angeht ist Rust ein Furz verglichen mit Whiley ( http://whiley.org ).

krümelkacker

Über Tellerrand geschaut schrieb:

Denn wenn es nur an der Sicherheit liegen würde, dann hätte sich Ada95 schon längst gegen C++ behaupten können.

Kennst Du Dich mit Ada aus? Vielleicht auch mit einer neueren Inkarnation? Ich nicht. Wenn ja, verrat uns doch mal bitte, ob/wie Ada Speichersicherheit garantieren kann. Das würde mich schon interessieren. Ich konnte da nur auf die Schnelle nichts zu finden außer einem Kommentar, dass sich Speichersicherheit und die Verwendung von Zeigern in Ada ausschließen würden.

Ü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.

Das ist auch schon das schlimmste Beispiel, was es gibt. Und alle sind sich einig darüber, dass diese Syntax unschön ist. Es war allerdings auch kein Unfall. Man hat lange hin und her überlegt, wie das aussehen könnte. Das Problem sind Mehrdeutigkeiten, die man vermeiden will. Ein C++ Compiler muss schon größere Verränkungen machen, um den kleiner-als Operator von der öffnenden spitzen Klammer in expression contexts zu unterscheiden. Diese Kontextabhängigkeit wollte man einfach in Rust nicht. Und eckige Klammern für Compilezeit-Parameter (wie es z.B. bei Scala der Fall ist) müssen vom Indexoperator unterschieden werden (den es in Scala gar nicht gibt). In Rust hast Du aber immer noch die Type Deduction. Das heißt, in vielen Fällen musst Du sowas gar nicht schreiben. Die from_str -Funktion ist auch nicht mehr ganz aktuell. Das könnte heute z.B. so aussehen:

fn main() {
    let mut v: Vec<i32> = Vec::new();
    if let Some(value) = "42".parse() {
        v.push(value); // Verwendungsbeispiel, wo Type Deduction greift
    } else {
        println!("Konnte den String nicht parsen");
    }
    println!("Liste: {:?}", v);
}

Über Tellerrand geschaut schrieb:

Dann schon eher D, denn das ist wesentlich näher am C Syntax Stil.

D gibt es ja schon eine Weile. Bin damit aber nie warm geworden. Es war mir zu ähnlich zu all dem, was es schon vorher gab und die anderen Features haben mich nicht vom Hocker gerissen. Das mit deinem „wesentlich“ halte ich für übertrieben. Dass man

let i: i32 = 23;
let j = 42;

statt

i32 i = 0;
auto j = 42;

schreibt, ist jedenfalls eine sehr leichte Umgewöhnung. Dagegen sieht mir Haskell sehr viel kryptischer aus mit meinem Java/C/C++ Background.

Mir fehlen in diesem Thread irgendwie die Graustufen. Natürlich wird man heutzutage nicht ernsthaft ein Linux Kernel Modul in Rust schreiben (außer vieleicht als proof-of-concept, welchen es allerdings schon gibt). Und natürlich werden nicht von heute auf morgen viele C++ Programmierer Rust benutzen. Ich würde nicht mal soweit gehen und behaupten wollen, dass Rust in 10 Jahren irgend eine wichtige Rolle spielen wird. Das ist einfach alles zu ungewiss. Zum einen gibt eben dieses “good enough”-Problem. Die Leute werden auch in 20 Jahren wahrscheinlich noch das alte JPEG Format zum Speichern von Fotos benutzen, weil es „gut genug“ ist, obwohl es spätestens dann bessere Alternativen geben wird. Zum anderen sehe ich im Bereich der generischen Programmierung bei Rust noch Lücken, die nerven und gefüllt werden müssten. Umgekehrt kann ich auch nicht nachvollziehen, wie der eine oder andere sich bzgl Rust so querstellen kann. Ich finde die Einschätzungen zum Potential von Rust von Leuten, die Rust gar nicht ausprobiert haben, auch nicht besonders interessant, ehrlich gesagt.

krümelkacker schrieb:

Über Tellerrand geschaut schrieb:

Denn wenn es nur an der Sicherheit liegen würde, dann hätte sich Ada95 schon längst gegen C++ behaupten können.

Kennst Du Dich mit Ada aus? Vielleicht auch mit einer neueren Inkarnation?

Nein, allerdings kenne ich jemand der Ada an der Uni in Stuttgart verwenden musste und der hat mir darüber berichtet und mir das gesagt, dass für Ada im Bezug auf sicheren Code sehr viel gemacht wurde.

Ada wird mit diesen Features der Sicherheit allerdings auch beworben und wurde auch genau aus diesem Grund entwickelt, eine sichere Sprache für die Luft- und Raumfahrtindustrie* zu sein.:
http://www.adaic.org/advantages/
http://de.wikipedia.org/wiki/Ada_(Programmiersprache)#F.C3.A4higkeiten_der_Sprache
https://www.youtube.com/watch?v=3e-BGblAMC4

* Was übrigens der Grund sein dürfte, dass diese Sprache an der Uni in Stuttgart so eine breite Verwendung hat. Luft- & Raumfahrttechnik wird dort nämlich auch gelehrt.

Hier hat jemand auch etwas zu Ada geschrieben (bei den Antworten gucken):
http://security.stackexchange.com/questions/55723/are-there-secure-languages