Von C zu Rust wechseln?

Na auf jeden Fall mal einer der da ein wenig am Ball bleiben will. Was die Sprache mir bringt werde ich ja auch erst sehen.

@Mechanics:
Ja, wenn man das "nur" vom beruflichen Aspekt sieht, dann kann ich dich gut verstehen. Meine Zeit als Berufsprogammierer ist vorbei und ich mache das nur noch als Hobby und da sind mit natürlich große Projekte, alter Code etc total egal. Als ich noch so etwas als Job gemacht hatte, da hatte ich aber auch kaum noch Lust privat was zu machen. Der Job hat fast meine ganze Freude an der Programmierung gekillt, was ich sehr schade fand. Alles musste immer Sinn ergeben und so weiter. Das ist jetzt zum Glück wieder anders und ich habe meine kindliche Neugier + viel Zeit wieder gewonnen.

krümelkacker

Rustiger schrieb:

Na auf jeden Fall mal einer der da ein wenig am Ball bleiben will. Was die Sprache mir bringt werde ich ja auch erst sehen.

Haha! Wenn Du mehr von der Sorte haben willst, dann bist Du hier aber eher falsch. Schau mal bei reddit vorbei. Ich häng’ da inzwischen öfters rum als hier.

Hey, danke für den Tipp. Ich bin schon fleißig am Links sammeln, Notizen machen und natürlich am Lernen und Ausprobieren.

Ich habe dort gerade was von einem 151-byte static Linux binary in Rust gelesen. Es geht also wirklich ziemlich runter bis auf LowLevel in unsafe Blocks und wenn man will mit Assembler.
Aber erst einmal muss ich mich an die neue Syntax gewöhnen, aber der Mensch ist ja ein Gewohnheitstier und meidet große Veränderungen, da muss man bewusst erst einmal gegensteuern und einfach machen, machen, machen. Wenn man flexibel genug ist und es liebt über den Tellerrand zu schauen, dann geht dass irgendwann ins Blut über und C und C++ sind dann fremd, altbacken und unnötig^^

Ich lese gerade die 30-min Intro für Rust und ist es wirklich so einfach in C++ ein SegFault zu bekommen ohne Warnung vom Compiler?

#include<iostream>
#include<vector>
#include<string>

int main() {
    std::vector<std::string> v;
    v.push_back("Hello");
    std::string& x = v[0];
    v.push_back("world");
    std::cout << x;
}

$ g++ hello.cpp -Wall -Werror
$ ./a.out
Segmentation fault (core dumped)

Nathan

Rustiger schrieb:

Ich lese gerade die 30-min Intro für Rust und ist es wirklich so einfach in C++ ein SegFault zu bekommen ohne Warnung vom Compiler?

Jup. Aber ist dokumentiert also RTFM oder so.

Edit: Wobei man bestimmt Compiler so verbessern könnte, dass die ähnliche Checks wie Rust machen.

volkard

krümelkacker schrieb:

Rustiger schrieb:

Na auf jeden Fall mal einer der da ein wenig am Ball bleiben will. Was die Sprache mir bringt werde ich ja auch erst sehen.

Haha! Wenn Du mehr von der Sorte haben willst, dann bist Du hier aber eher falsch. Schau mal bei reddit vorbei. Ich häng’ da inzwischen öfters rum als hier.

Jo.
Hier gibt es einige Leute, die Rust-Diskussionen gegenüber ablehnend stehen. Weil hier regelmäßig Fanboys reinschneien und alle Leute von irgendwas Neuem missionieren wollen, Rust war da auch recht oft dabei. Da wenig neuer Gehalt ist, wird das Alte halt schlechtgeredet. Woche für Woche, endlos.

volkard

Rustiger schrieb:

Ich lese gerade die 30-min Intro für Rust und ist es wirklich so einfach in C++ ein SegFault zu bekommen ohne Warnung vom Compiler?

Sowas nervt einfach nur. An den Haaren herbeigezogener Unfug, der in der Praxis gar nicht vorkommt.

War mir aber schon beim ersten Posting klar, daß "Rustiger" nur eine Werbeveranstaltung ist.
"Tellerrand" "altbacken" und so weiter. => Troll.

Ich habe auch nichts anderes in einem C++-Forum erwartet. Aber ist schon geil, wenn trotz Container und Referenzen, mal ganz schnell sein Segfautz entsteht und in der Realität findet man so etwas viel schwieriger, das ist auch nicht besser als die void* Fehler in C. Bei Rust kannst du nun einmal garantieren, dass nur in unsafe Codeblöcken so ein Blödsinn passieren kann. Bei C++ kann das überall sein.

Alles Neue ist böse und früher war alles besser und C++ ist ganz toll blablabla. Rust wird auch seine Achillesfersen haben, aber C++ hat eine ganze Menge davon und die kann man nicht einfach wegdiskutieren. Also man kann schon, deswegen ist C++ aber nicht automatisch sicherer, sondern nur wenn man 1001 Regeln befolgt, was eh kaum einer macht, weil er C++ gar nicht gut genug kennt. Und die neuen Flicken alle paar Jahren machen keine neue Sprache daraus, sie bleibt mit den Altlasten auch per Konzept schon unsafe.

Hier sollte doch jeder wissen, was an C++ toll ist und was totaler Mist. Was spricht dagegen es besser zum machen? Ich denke Rust ist ein Anfang in diese Richtung. Ich kann mich auch irren, aber ich glaube nicht dass C++ oder auch C bis in alle Ewigkeit das Fundament aller Systeme bilden wird.

Von mir aus könnte ihr den Thread hier auch dicht machen. Wenn ich jetzt schon die Troll-Keule schwingen hören, nur weil ich was negatives über die Gottheit C++ geschrieben habe. dann macht dies jeder Vergleich mit Rust hinfällig. Rust ist nun einmal mit dem Ziel erstellt worden C und auch C++ ersetzen zu können und da ist ein Vergleich nun mal angebracht. Aber anscheinend nicht in diesem Forum hier.

Also bye bye und C++ ist einfach toll, nicht zu ersetzen und wird ewig bestehen und den Rest kennt hier ja vom Tischgebet, oder was auch immer...

volkard

Dir gehts gar nicht um Rust, sondern Du willst nur C++ niedermachen. Viel Spaß.

Hab da auch einen Punk:
Andauernd passieren mir Fehler wie

int main() {
	[](void(*_)()){_();}(0);//segfault
}

und die würden in Prolog nicht passieren. Darum sollten alle jetzt sofort nach Prolog umsteigen.

Nathan

Rustiger schrieb:

Ich habe auch nichts anderes in einem C++-Forum erwartet. Aber ist schon geil, wenn trotz Container und Referenzen, mal ganz schnell sein Segfautz entsteht und in der Realität findet man so etwas viel schwieriger, das ist auch nicht besser als die void* Fehler in C. Bei Rust kannst du nun einmal garantieren, dass nur in unsafe Codeblöcken so ein Blödsinn passieren kann. Bei C++ kann das überall sein.

Der beschriebene Fehler tritt aber nicht auf, schließlich sollte jeder wissen, was bei einem Wachstum eines vectors passiert und dementsprechend auch etwaige Pointer oder Referenzen beachten. Ich gebe bspw. in solchen Fällen lediglich die Indicies der Elemente heraus oder sorge dafür, dass der vector nicht wächst. Oder nehme eine andere Datenstruktur.
Der Fehler an sich, ist blöd, aber auftreten tut der extrem selten.

ipsec

volkard schrieb:

Sowas nervt einfach nur. An den Haaren herbeigezogener Unfug, der in der Praxis gar nicht vorkommt.

Hierbei handelt es sich offenbar um ein Minimalbeispiel, um das grundlegende Problem zu verdeutlichen. Natürlich ist in diesem Fall der Fehler offensichtlich und so würde das niemand schreiben. Aber ich denke schon, dass es in der Praxis vorkommt, dass zu langlebige Referenzen und Pointer auf Elemente eines Vektors angelegt werden.

Anfängern passiert das sicherlich häufiger, erst recht, wenn sie von Sprachen wie Java kommen, weil sie gar nicht mit dem Problem rechnen. Erfahrene C++-Programmierer sind natürlich für solche Sachen sensibilisiert und vermeiden die meisten Fehler. Aber trotzdem kann es komplexere Fälle geben, z.B. wenn eine Lib unerwartet einen übergebenen Pointer intern speichert. Natürlich kann man sowas schlecht mit einem 5-Zeilen-Beispiel verdeutlichen.

Grundsätzlich ist es in C++ nun mal sehr einfach möglich, dangling Pointer oder Referenzen zu erzeugen. Auch in Anbetracht der Tatsache, dass das sicher jedem schon mal passiert ist, finde ich es überzogen, das als praxisfernen Unfug abzutun. Durch Erfahrung und Disziplin kann man diese Fehler minimieren, aber je komplexer das System wird, desto schwieriger kann man sie ausschließen.

Hinzu kommt noch, dass zusätzliche Sicherheit die Programmierung in der Regel für den Programmierer angenehmer gestaltet, auch wenn tatsächlich im Ergebnis wenig konkrete Fehler verhindert werden. Ähnliche Überlegungen könnte man zum Beispiel zu const anstellen. Wenn C++ kein const hätte, würden deswegen die Programme nicht automatisch fehlerhafter werden. Man müsste sich halt beim Programmieren mehr Gedanken machen, welche Objekte man verändern darf und welche nicht. Für externe Interfaces müsste das zusätzlich dokumentiert werden. Alles in allem aber durchaus machbar und nicht deutlich mehr Aufwand. Wenn jetzt jemand eine Sprache vorstellen würde, in der man Objekte const machen kann und als Motivation ein kurzes C++-Programm angibt, in dem ein Objekt fälschlicherweise manipuliert wird, würdest du das vielleicht auch als praxisfern abtun, weil niemand das so schreiben würde. Aber auf const verzichten möchtest du auch nicht, oder?

Mechanics

Rustiger schrieb:

@Mechanics:
Ja, wenn man das "nur" vom beruflichen Aspekt sieht, dann kann ich dich gut verstehen.

Nicht nur aus beruflicher Sicht. Ich interessiere mich auch noch privat für die Programmierung (auch wenn ich nach der Arbeit nicht mehr viel machen kann). Nur wil ich mich daheim erst recht auf die Projekte konzentrieren, die mich interessieren. Und deswegen ist mir die Sprache dabei relativ egal, ich will sie in einer Sprache schreiben, die ich schon kann, für die es Bibliotheken gibt und wo ich weiß, dass Compiler und IDE funktionieren. Ich verschwende doch nicht das bisschen Freizeit, dass ich noch habe, um mich mit einer neuen Programmiersprache rumzuärgern.

Mechanics schrieb:

Rustiger schrieb:

@Mechanics:
Ja, wenn man das "nur" vom beruflichen Aspekt sieht, dann kann ich dich gut verstehen.

Nicht nur aus beruflicher Sicht. Ich interessiere mich auch noch privat für die Programmierung (auch wenn ich nach der Arbeit nicht mehr viel machen kann). Nur wil ich mich daheim erst recht auf die Projekte konzentrieren, die mich interessieren. Und deswegen ist mir die Sprache dabei relativ egal, ich will sie in einer Sprache schreiben, die ich schon kann, für die es Bibliotheken gibt und wo ich weiß, dass Compiler und IDE funktionieren. Ich verschwende doch nicht das bisschen Freizeit, dass ich noch habe, um mich mit einer neuen Programmiersprache rumzuärgern.

So kann man auch die IT-Evolution zum erliegen bringen. Würden das mehr Leute so sehen, dann gäbe es nur noch Programmiersprachen die immer wieder weiteren Flicken bekommen...bähhh!

P.S.: Welche Entwickler kennt denn nur ein oder zwei Programmiersprachen?

krümelkacker

JustEvo schrieb:

So kann man auch die IT-Evolution zum erliegen bringen. Würden das mehr Leute so sehen, dann gäbe es nur noch Programmiersprachen die immer wieder weiteren Flicken bekommen...bähhh!

Zu faul zu sein, sich was neues anzugucken, ist ja eigentlich auch normal. Das will ich keinem ankreiden. Ich hüpfe auch nicht auf jeden Zug. Es ist eben eine Kosten-Nutzen-Rechnung mit Ungenauigkeiten, weil man das, was man lernen würde, ja vorher nicht so gut einschätzen kann. Habe neulich erst 'n netten Artikel gelesen, der zu diesem Thema passt: Why your F# evangelism isn't working.

Mechanics schrieb:

Nicht nur aus beruflicher Sicht. Ich interessiere mich auch noch privat für die Programmierung (auch wenn ich nach der Arbeit nicht mehr viel machen kann). Nur wil ich mich daheim erst recht auf die Projekte konzentrieren, die mich interessieren. Und deswegen ist mir die Sprache dabei relativ egal, ich will sie in einer Sprache schreiben, die ich schon kann, für die es Bibliotheken gibt und wo ich weiß, dass Compiler und IDE funktionieren. Ich verschwende doch nicht das bisschen Freizeit, dass ich noch habe, um mich mit einer neuen Programmiersprache rumzuärgern.

Das passt echt zu deinem Namen. Dir ist das Werkzeug egal. Hauptsache, du kannst es bedienen und da kommt was hinten bei raus… Und da ist jetzt auch nichts schlechtes dran. Dem einen oder anderen ist aber vielleicht auch wichtig, wie „effizient“ so ein neues Werkzeug ist, auch wenn er das erst erlernen müsste, wobei das Erlernen ja auch Spaß bringen kann und nicht nur/unbedingt ein Rumärgern bedeuten muss.

volkard schrieb:

Hier gibt es einige Leute, die Rust-Diskussionen gegenüber ablehnend stehen. Weil hier regelmäßig Fanboys reinschneien und alle Leute von irgendwas Neuem missionieren wollen, Rust war da auch recht oft dabei.

Ich finde das nicht schlimm, wenn man in einem allgemeineren Unterforum, was "Rund um die Programmierung" heißt, solche Themen anreißt. Du bist da IMHO nur zu empfindlich und stolz. Es fällt Dir anscheinend schwer, Leute, die sich auch kritisch zu C++ äußern, nicht reflexartig in die Feind-Schublade zu stecken. Das hat auch Fanboi-Züge und ist keine gute Voraussetzung für gehaltsvolle Gespräche.

Aber ich stimme Dir zu, dass es ab einem gewissen Punkt des Meinungsaustauschs, zumindest zwischen denselben Leuten, langweilig wird, weil alles gesagt wurde und man sich nur noch im Kreis dreht.

volkard schrieb:

Andauernd passieren mir Fehler wie
int main() {
	[](void(*_)()){_();}(0);//segfault
}
und die würden in Prolog nicht passieren. Darum sollten alle jetzt sofort nach Prolog umsteigen.

Das ist wieder so ein im-Kreis-dreh-Moment. Ich bin mehrfach auf ähnliche Kommentare (als krümelkacker oder kkaw) eingegangen, habe Beispiele gebracht, die nicht so offensichtlich falsch waren und u.a. auch in freier Wildbahn zu finden sind, habe erklärt, was in realem Code zu Problemen führen kann. Und damit meine ich guten, “modernen” Code, der so aussieht, als ob jemand C++ verstanden hätte, auch für Dich. Ich weiß auch, dass solche Fehler bei 'nem guten C++ Programmierer recht selten sind. Ich habe damit auch so gut wie keinen Ärger in C++! Aber es hat trotzdem etwas befreiendes, in Rust mit Referenzen zu arbeiten, weil man weiß, dass der Compiler einem bzgl potentiell baumelnden Referenzen hilft (im Sinne von "wird zu 100,0% ausgeschlossen"!). Es ist Newbie-freundlich. Und es ist etwas schönes, in der Hinsicht selbstdokumentierende Schnittstellen zu haben. Bei einer Funktion, die eine Referenz zurückgibt, weiß man ganz genau, wie lang sie gültig sein wird, ganz ohne Doku. Das ist auch prima für Bibliotheksentwickler, die eine falsche Benutzung nach Möglichkeit verhindern wollen. Und das ist ja wohl eher die Regel: Du hast überdurchschnittlich gute Programmierer, die Bibliotheken bauen und eher durchschnittliche Programmierer, die solche Bibliotheken benutzen.

Zumal es "gute und moderne" C++-Programmierer kaum zu geben scheint. Hier war einmal einer der C++ für einen Job lernen wollte und dort wurde gesagt, dass er ca. ein Jahr braucht, um C++ mit einem guten Buch(was wohl selten ist) und dem Forum hier zu lernen. Aus ihm würde dann, auch durch die Hilfe im Forum hier, mit hoher Wahrscheinlichkeit ein besser c++-Programmierer als die Berufsprogrammierer, die er so kennt.

Man KANN in C++ sicher programmieren. Die Sprache kann dies aber NICHT garantieren, das ist das was zählt. Nur auf die Fehlerfreiheit und auf Top-Kenntnisse der Sprache C++ zu setzen, sehe ich als ziemlich riskant an und viele andere auch, sonst gäbe es heute nicht so viele erfolgreiche Sprachen neben C++.

Sicherheit nur vom Programmierer abhängig zu machen, ist sehr kurzsichtig. Ich finde es gut, dass es immer wieder neue Programmiersprachen gibt. Die IT wird nun einmal immer besser und dazu gehört es Neues zu entwickeln und auszuprobieren.

Wem der Weg zum Ziel keinen Spaß macht, der lässt es halt bleiben. Mir persönlich macht es Spaß neue Sprachen auszuprobieren. Und auch darüber zu diskutieren macht Freude. Die Sprachen in ihren verschiedenen Aspekten zu vergleichen gehört zu diesem Entdecken dazu. Bis auf C++ hat man auch viele Sprachen in einem Monat so weit gelernt um eigene Projekte damit fahren zu können. Ich sehe das bei einigen Blogs in dem Rust z.B ein Path-Raytracer einmal in C++ und einmal in Rust entwickelt wurde und dann wurde zum Schluss verglichen. Der Speed war so ziemlich gleich, beide Sprachen hatten Vor- und Nachteile, aber am Ende hat dem Autor Rust besser gefallen.

SpracheX vs. SpracheY sollte immer ein fester Bestandteil eines Forums sein. Denn dieser Vergleich interessiert mich immer, wenn ich eine neue Sprache sehe. Wenn solche Unterhaltung dann aber gleich als Trollerei und Flamewar runter gebügelt werden, dann ist das echt ein Schlag ins Gesicht für die Meinungsfreiheit.

Wenn hier einer beweisen kann, dass C++ sicherer ist als Rust, dann soll er dies tun. Den anderen mit "Trollerei" zu diskreditieren ist allerdings unterste Schublade.

Vor allem macht es doch einen Riesenspaß was Neues zu lernen. Das Interesse an Programmierung im Jahre 2015 vor rausgesetzt.

Nachtrag:
Die Sprache ist nun einmal als Ersatz für C und C++ direkt so entwickelt worden und deswegen MUSS man sie auch damit immer wieder vergleichen können dürfen. Ob Rust erfolgreich wird oder nicht weiß keiner, es ist ja auch nichtmal Version 1.0 wirklich draussen. Ich finde es gut mal wieder einen Schritt in Richtung kompilierbare Sprache zu gehen und moderne Anforderungen einer heutigen nativen Sprache umzusetzen. Eine neue Sprache ohne VM und ohne GC, sondern mit RAII und unsafe-Blocks ist doch toll. Das Buildtool cargo finde ich auch spitze, ganz einfach libs veröffentlichen und Abhängigkeiten automatisch auflösen usw. Keine Header und Source-Dateien mehr. Gut der Syntax ist auch für mich sehr gewöhnungsbedürftig, aber nichts was man nicht lernen kann, so man denn will.

Ich finde Rust ist ein Weg in die richtige Richtung und so lohnt sich so etwas zu unterstützen. Gerade heute ist es wichtig wenn Software sicherer wird.

DasNeue schrieb:

Eine neue Sprache ohne VM und ohne GC, sondern mit RAII und unsafe-Blocks ist doch toll.

absolut - ohne VM und GC, das muß man sich mal vorstellen!

Aber gibt es da nicht eine Sprache mit RAII, mit ohne VM und ohne GC, die seit über 3 Jahrzehnten weit verbreitet ist, eine riesige Code- und Benutzerbasis hat, und gerade in den letzten Jahren stürmisch weiterenwickelt wird - die heißt irgendwas mit "C" und "plus" oder "11", komm' jetzt gerade nicht drauf

Ist ja richtig, C++11 bietet eine ganze Menge und da wurde viel Nützliches mit angebaut. Die Sprache ist aber nach wie vor unnötig kompliziert und per Standard unsafe. Die große Codebase wird auf lange Sicht der einzige Vorteil der Sprache bleiben. In andere Sprachen lassen sich aber auch sehr leicht C- Libs einbinden, was einen Übergang, bis genügend eigenen Libs vorhanden sind, leichter macht.

Rust ist halt ein erster Versuch C und C++ komplett abzulösen. In wie weit das gelingt werden so die nächsten fünf Jahre zeigen. Neue Sprachen brauchen immer eine ganze Weile um akzeptiert zu werden. Die Leute die sich jetzt damit beschäftigen sind wie Forscher auf einem neuen Planeten. Das ist anstrengend aber auch aufregend. Wenn man allerdings gleich von Vornherein alles Neue abschmettert, dann wird nie was Neues kommen und die Evolution bleibt stehen. C++ kann man nun einmal nicht mehr sicher bekommen, sonst wäre es nicht abwärtskompatibel. Alles hat seinen Preis, das All-in-One-Wunder gibt es nicht. Aber man kann so etwas ja versuchen zu bauen und vielleicht kommt man dem ja mit jeder neuen Sprache etwas näher.

Ich versuche jedenfalls alles um die Sprache bekannt zu machen, denn ich finde sie geht einen Schritt in die richtige Richtung.

Ethon

Keinen GC zu haben ist doch ein Nachteil.
Da ist D toll. Kombiniert beides.