Von C zu Rust wechseln?

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.

dot

Ethon schrieb:

Keinen GC zu haben ist doch ein Nachteil.

Hab noch kein Beispiel gesehen, wo das ein Nachteil gewesen wäre, im Gegenteil. Zumindest meiner Erfahrung nach macht die Abwesenheit eines GC fundamentale Dinge wie Ressourcenverwaltung wesentlich einfacher und führt zu wesentlich beserer Softwarequalität, z.B. weil man von Anfang an gezwungen wird, gewisse Eigenschaften des zu lösenden Problems im Design zu addressieren (z.B. solche, die sich in Besitzfragen äußern), die durch die Anwesenheit des GC so lange verschleiert würden, bis sie still und heimlich zu einem ausreichend großen Monster herangewachsen sind.

Der einzige mir bewusste "Nachteil" ist, dass man tatsächlich fähige Programmierer braucht. Ohne die wird man aber früher oder später Probleme haben, die Dimensionen annehmen, die die zunächst vermeintlich gesparte Zeit relativieren. Freut mich zu sehen, dass die Welt langsam aber doch aufzuwachen scheint...

Ethon

Och, wenn man beide Seiten der Medaille kennt, zb weil man lange C++ programmiert hat, dann weiß man auch wie man einen gc richtig nutzt.
Ich programmiere gerne mit gc.

dot

Ethon schrieb:

Och, wenn man beide Seiten der Medaille kennt, zb weil man lange C++ programmiert hat, dann weiß man auch wie man einen gc richtig nutzt.
Ich programmiere gerne mit gc.

Einer meiner größeren Fehler bisher, aus denen ich sehr viel lernen durfte, war, ein bestimmtes Projekt auf Wunsch des Kunden in C# zu schreiben. Ich hatte keine Ahnung wie vielfältig die Welt der Probleme, die GC in einem komplexeren Projekt (in dem Fall eine kleine CAD Anwendung) verursachen kann, doch ist. Jetzt weiß ich es allerdings besser und bastel bestenfalls ein sehr komplexes GUI (aus praktischen Gründen, auch wenn dieses eventbasierte zusammenpappen von Dingens einfach nur furchtbar ist) aber niemals die Business Logic dahinter in Sprachen mit GC. Hätte ich das damals schon so gemacht, wäre die resultierende Anwendung nicht nur performanter (die Performance von C# hat sich in dem Fall sogar als gerade noch ausreichend herausgestellt, wobei es dank GC massive Speicherprobleme gibt), sondern vor allem auch wesentlich einfacher (im Sinne von weniger und vor allem weniger komplizierter Code) und als indirekte Folge davon viel stabiler...

Diese Erfahrung bescherte mir auch meinen ersten Kontakt mit C++/CLI und der Illusion vom wunderbaren Universum der Sprachen in denen die Welt mit und die Welt ohne GC friedlich koexistieren. Ich hab mich mit D nicht wirklich beschäftigt, aber zumindest auf den ersten Blick sehe ich auch dort weder etwas Neues noch irgendwelche Anzeichen einer sinnvollen Antwort auf die Frage, wie man diese beiden Dinge auf produktive Art kombinieren könnte. Meine Theorie: Die beiden Dinge sind wie Tag und Nacht und schließen sich rein prinzipiell gegenseitig aus. Die Entwickler von Rust und Swift haben das offenbar auch verstanden...

Mechanics

krümelkacker schrieb:

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.

Hmm, ein bisschen weit hergeholt Es ist auch nicht unbedingt so, dass mir egal wäre, wie "effizient" ein Werkzeug ist. Sagen wir mal so, ich hätt überhaupt kein Lust, Visual Basic zu programmieren, auch wenn ich es wahrscheinlich könnte, ohne es explizit zu lernen (hab schon sehr oft gesehen und was angepasst). Ich hab auch gern Scala gelernt und benutzt, als ich Java programmiert habe. Da habe ich aber die entscheidenden Vorteile gesehen, die mir Scala gegenüber Java bietet. Und es hatte kaum Nachteile, ich konnte das in bestehenden Java Projekten verwenden, nur die IDE Unterstützung war nicht ganz ausgereift. Bei Rust habe ich einfach keine wirklich relevanten Vorteile, dafür habe ich etliche Nachteile. Das reicht einfach nicht, um mein Interesse zu wecken.

Swordfish schrieb:

fn foo ( bar : uint ) -> uint
finde ich eher eine Verschlimmbesserung gegen
unsigned foo( unsigned bar )
...

Mich würde eher das Motiv interessieren, dass die Erfinder von Rust hier hatten.

Warum sollte man eine Funktion mit einem Keyword namens fn beginnen?
Bisher habe ich jede Funktion in C Syntax, wie man sie bei C, Java oder C++ vorfindet, auf Anhieb erkannt und das der Rückgabewert am Anfang steht, mag vielleicht einen Anfänger verwirren, aber das hat man irgendwann intus, so dass es einem nicht mehr auffällt.

Wenn ich etwas wichtig finde, ist, dass man bei Sprachen mit dynamischen Typen einen Keyword voransetzt, dass aussagt, dass hier eine neue Variable definiert wird. Da macht so etwas schon Sinn.
Aber bei Funktionen ist es mir nicht klar, denn wenn eine Funktion nur aufgerufen wird, dann erkennt man das bei C sofort, weil der Rückgabewert dann nicht angegeben wird.
Bei PHP erkennt man dagegen nicht, ob eine Variable neu definiert wird, oder bereits existiert. So etwas ist übel bei Tippfehlern, deswegen machen Keywörter da Sinn.

Dass bei der Parameterübergabe der Typ vor dem Bezeichner steht, finde ich auch doof.

Und dafür

->

muss ich mich auf einer deutschen Tastatur verrenken.
Weswegen ich die Lösung mit "Rückgabewert vor dem Funktionsnamen" wie in C deswegen auch besser finde.

Die Module und ihre Verschachtelbarkeit gefallen mir allerdings:

http://rustbyexample.com/mod.html

Mechanics schrieb:

Außerdem interessieren mich einfach "große" Projekte. Ich mag nicht in kleinen Firmen arbeiten, die an kleinen Projekten basteln. Ich will in sehr großer Software mit sehr vielen Komponenten rumwühlen. Sowas entsteht nicht von heut auf morgen und sowas entsteht selten von Grund auf neu. Das ist meist Software, die schon lang auf dem Markt ist. Und deswegen ist die wahrscheinlich in C++ geschrieben

In bestehender Software rumzuwühlen ist ja auch viel einfacher und macht mehr Spaß als bei 0 beginnen zu müssen und alles selber designen zu müssen.

Tyrdal

Ich empfinde das als genau umgekehrt.

DasNeue schrieb:

Rust ist halt ein erster Versuch C und C++ komplett abzulösen.

Nö, D war schon vorher da. So wie noch viele weitere Sprachen.

Tyrdal schrieb:

Ich empfinde das als genau umgekehrt.

Neu anfangen zu müssen ist halt sehr low Level und man sieht erst mal für viele Monate nichts.

Bei bestehender Software sieht man aber etwas und mit jedem weiteren Feature wird die Software leistungsfähiger und besser und die neuen Features sind man nach recht kurzer Implementierungszeit.

Und bei Computerspielen gilt das wahrscheinlich noch mehr als bei Anwendungssoftware & Co.

Ich finde gerade dieses Neuanfangen sehr spannend und je mehr ich mich in Rust einarbeite, desto mehr gefällt es mir. Mein Wissen über andere Programmiersprachen ist ja deswegen nicht einfach weg. Wie ich schon schrieb, ich finde den Weg den Rust geht richtig und das unterstütze ich. Aber erst einmal muss ich lernen und ausprobieren. Wem der Weg zum Ziel kein Spaß macht, der sollte es eh bleiben lassen.

Ethon

Ich finde das function keyword nicht blöd da dadurch Mehrdeutigkeiten wegfallen. C++ hat ja auch das Problem dass

vector data(len);

nicht als Variable sondern als Funktion geparst wird. Finde ich hässlich, das function keyword gefällt wird.