Von C zu Rust wechseln?

[Ethon]

Was ist denn großartig da außer Boost?
Entwicklungsumgebungen sind auch eher mies. Da ginge bei der viel einfacheren Sprache Rust besser.
Meiner Erfahrung nach sind 99% aller C++-Bibliotheken Müll, weil die Macher irgendwelche Grundprinzipien der Sprache noch nicht verstanden haben. Und wenn man etwas wirklich wichtiges schreibt, macht man es in C oder mit C-APIs.

Wegen der Software, die in C oder C++ angefangen wurde, und jetzt halt da ist und gerne erweitert und gewartet werden möchte.

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

Weil es sich im in C geschriebenen Kernel fremdartig anfühlt und man auch einiges an Bindings zu Kernel APIs und vor allem Makros pflegen müsste.

Es ist schön, wenn in deinem Umfeld nur Experten arbeiten, die wissen, was sie tun. Das ist aber eher ungewöhnlich.

Vor schlechten Programmieren schützt auch Rust nicht.

[Rustiger]

Ethon schrieb:

Vor schlechten Programmieren schützt auch Rust nicht.

Doch, genau das tut Rust bei allen Speicherfehlern, die C++ einfach durchwinkt. Setze dich doch endlich mal mit der Sprache auseinander. Du kennt ja den Spruch: "Wenn man keine Ahnung hat, einfach mal die ... halten".

[Shade Of Mine]

Rustiger schrieb:

Ethon schrieb:

Vor schlechten Programmieren schützt auch Rust nicht.

Doch, genau das tut Rust bei allen Speicherfehlern, die C++ einfach durchwinkt. Setze dich doch endlich mal mit der Sprache auseinander. Du kennt ja den Spruch: "Wenn man keine Ahnung hat, einfach mal die ... halten".

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

[Rustiger-Versteher]

Shade Of Mine schrieb:

Rustiger schrieb:

Ethon schrieb:

Vor schlechten Programmieren schützt auch Rust nicht.

Doch, genau das tut Rust bei allen Speicherfehlern, die C++ einfach durchwinkt. Setze dich doch endlich mal mit der Sprache auseinander. Du kennt ja den Spruch: "Wenn man keine Ahnung hat, einfach mal die ... halten".

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

Was Rustiger meinte war, dass es in Rust unmöglich ist Speicherfehler zu programmieren. Das hat er auch so direkt geschrieben, aber ich weiß, dass es dir nicht darum ging, ihn zu verstehen...

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