Von C zu Rust wechseln?

welche Nische ist denn offen, die eine weitere Sprache wie Rust besetzen kann?

wenn eine neue Sprache eine der wohletablierten C, java, C++ verdrängen könnte, dann würde das wohl kaum von heute auf morgen geschehen.

Gibt es mehrere Sprachen für ähnliche Zwecke, dann koexistieren die oft nebeneinander her, die älteren verlieren nach und nach an Zuspruch, die neuen gewinnen allmählich an Zuspruch. Das kann Jahrzehnte dauern, man denke mal an cobol und fortran, beide mit Wurzeln in den 1950er Jahren, und beide immer noch im Einsatz, obwohl für beide Einsatzbereiche seit langem C, java, C++ (neben zahlreichen Spezialsprachen) bereitstehen.

angesichts der riesigen Codebasis von C, java, C++, die sich in Jahrzehnten angehäuft hat, und angesichts der großen Menge an Libraries, Literatur und Entwicklern würde ich vermuten, daß die Ablösung einer dieser Sprachen ein eher langsamer Prozess sein würde.

vielleicht kommt die Ablösung von C, java, C++ erst mit dem Durchbruch von anderen Paradigmen als OOP, etwa dem funktionalen und dem logischen.

Erlang gibt es heute schon (eigentlich schon länger). Funktional, entwicklungsgeschichtlich eine gewisse Nähe zu Prolog, und passenderweise für nebenläufige Systeme der nach-Moore-Ära geeignet, würde gut zu meiner Vermutung passen.

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.

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp

krümelkacker

Über Tellerrand geschaut schrieb:

Was ist mit funktionalen Programmiersprachen wie Haskell & Co?

Hau rein. Nur zu. Das ist jetzt nichts, was ich zu den "low overhead"-Sprachen (C, C++, Rust) zählen würde.

Über Tellerrand geschaut schrieb:

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?

Wird sie denn erreicht? Gibt's da Zeiger? Schließen sich diese beiden Dinge in Ada aus? Ich weiß es nicht. Mir ist jedenfalls nicht bekannt, dass Ada das Konzept der Lebenszeiten kennt und dass Zeiger solche Lebenszeitparameter als Teil des Typs haben, wie es in Rust der Fall ist, womit zur Übersetzungszeit ausgeschlossen werden kann, dass ein Zeiger ungültig wird. Viele andere Möglichkeiten, das zu gewährleisten kenne ich nicht: (1) Garbage Collection (nur der GC räumt das weg, was wirklich nicht mehr erreicht werden kann) oder auch (2) Runtime Checking à la Clang's Address Sanatizer. Und beides bedeutet einen Overhead.

Ada 2012 soll sich wie C++11 auch „gemausert“ haben. Aber ich finde zum Thema Speichersicherheit nichts überzeugendes, zumindest nicht ohne die Sprache jetzt zu lernen. Ich habe nicht den Eindruck, dass die Sprache zur Übersetzungszeit ausschließen kann, dass es keine baumelnden Zeiger im Programm geben wird.

großbuchstaben schrieb:

welche Nische ist denn offen, die eine weitere Sprache wie Rust besetzen kann?

Also, dafür, dass dieser Thread hier schon 10 Seiten überschritten hat und dass es so Dinge wie Suchmaschinen gibt, finde ich die Frage ein bisschen ignorant. Ist doch ganz einfach: Rust will ein besserer C++ Ersatz sein, der es wie C++ auf "zero cost abstraction" aber zusätzlich auch auf Speichersicherheit und Threadsicherheit abgesehen hat. Und warum will es das sein? Weil es immer noch viel zu viele Sicherheitslücken in C und C++ Software gibt, die es mit Speichersicherheit nicht gegeben hätte. Und wie es sich für einen C++ Ersatz gehört, will man den Leuten Garbage-Collection ersparen ohne dabei Zeiger zu verbieten. Weder Performance noch Speichersicherheit sind in Isolation ein Alleinstellungsmerkmal. Aber die Kombination dieser Eigenschaften in einer Sprache ist, soweit ich das beurteilen kann, einzigartig (wobei Rust in der Hinsicht von Cyclone's „region pointers“ inspiriert ist).

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. Die IT würde ein gutes Stück sicherer dadurch werden.

Lasst den Compiler für euch arbeiten, das sind doch immer einer der großen C++-Sprüche hier. Mal schauen was dran ist wenn eine andere Sprache da weit mehr drauf hat.

Also schreibt Bindings, IDEs etc. und dann nach und nach Libs ersetzen.
https://crates.io/

Ethon

C++ wird wegen dem benutzt was schon da ist und nicht weil es eine tolle Sprache wäre. Bei Rust ist noch nichts da und die Sprache hat absolut nicht das Potential irgendwo Java oder C# zu ersetzen.
Wer soll damit bitte etwas anfangen, realistisch betrachtet?
Ich weiß nur sehr sicher dass bei uns niemand anfangen wird Linux Treiber in Rust zu schreiben.

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.

TyRoXx

Ethon schrieb:

C++ wird wegen dem benutzt was schon da ist und nicht weil es eine tolle Sprache wäre.

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.

Ethon schrieb:

Bei Rust ist noch nichts da und die Sprache hat absolut nicht das Potential irgendwo Java oder C# zu ersetzen.
Wer soll damit bitte etwas anfangen, realistisch betrachtet?

Rust möchte gar nicht Java oder C# ersetzen, sondern C++ und damit auch C.
Ein guter C++-Programmierer erkennt, dass Rust nicht viel mehr macht als die vielen ungeschriebenen Gesetze von C++ in eine neue Sprache zu gießen, wo die Tools diese Gesetze kennen. Die strikte Befolgung der Gesetze führt auch in C++ zu sicherem Code, aber der Compiler hilft einem dabei nicht und lässt ganz viel Mist durchgehen.

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.

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.

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

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.

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?

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.

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");

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.