Von C zu Rust wechseln?

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.

dot

Ethon schrieb:

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.

vector data(len); würde als Definition einer lokalen Variable geparsed (sofern len kein Typ ist). Lediglich vector data(); ist eine Funktionsdeklaration.

Wenn das eine Variablendeklaration sein soll, dann fehlt mir da noch der Typ, z.B.:

vector<int> data(len);

und an dem <int> ist eindeutig zu erkennen, dass das eine Variable und keine Funktion sein soll.

Und

vector data();

ist eindeutig als Funktion zu erkennen, genauso wie

vector data(int bla);

und der Einwand von dot ist korrekt.
len muss schon ein selbstdefinierter Datentyp sein, damit so eine Deklaration Sinn macht:

vector data(len)

Also ich sehe jetzt nicht, dass hier Mehrdeutigkeit entsteht und ein Keyword notwendig wäre.

dot

Nun, Ethon wollte wohl auf den Most Vexing Parse anspielen, dem wir alle wohl schon mindestens einmal auf den Leim gegangen sind; passiert mir ab und zu auch noch...

Außerdem meldet das auch der Compiler:

compiliert:

#include <iostream>
#include <vector>
using namespace std;

int main()
{
    int len = 10;
    vector<int> data(len);

    for (vector<int>::iterator i = data.begin(); i != data.end(); ++i)
    {
      cout << *i << endl;
    }
    return 0;
}

compiliert nicht:

#include <iostream>
#include <vector>
using namespace std;

int main()
{
    int len = 10;
//    vector<int> data(len);
    vector data(len);

    for (vector<int>::iterator i = data.begin(); i != data.end(); ++i)
    {
      cout << *i << endl;
    }
    return 0;
}

g++ test.cpp -o test.bin
test.cpp: In function ‘int main()’:
test.cpp:9:12: error: missing template arguments before ‘data’
     vector data(len);
            ^
test.cpp:9:12: error: expected ‘;’ before ‘data’
test.cpp:11:36: error: ‘data’ was not declared in this scope
     for (vector<int>::iterator i = data.begin(); i != data.end(); ++i)

dot schrieb:

Nun, Ethon wollte wohl auf den Most Vexing Parse anspielen, dem wir alle wohl schon mindestens einmal auf den Leim gegangen sind; passiert mir ab und zu auch noch...

Okay, aber das klingt schon sehr gestellt. So würde ich zumindest nicht programmieren.

Aussagen wie "Das würde ich nie machen" sind genau das Problem. Es gibt eben viele Programmierer da draußen, die nicht die Experten-Ahnung ihrer Sprache haben und die auch keine Zeit oder Lust haben sich bis auf alle Ewigkeit nur mit dem Werkzeug beschäftigen zu müssen, um all die Ausnahmen und Regeln kennen zu lernen.

Motiv? schrieb:

dot schrieb:

Nun, Ethon wollte wohl auf den Most Vexing Parse anspielen, dem wir alle wohl schon mindestens einmal auf den Leim gegangen sind; passiert mir ab und zu auch noch...

Okay, aber das klingt schon sehr gestellt. So würde ich zumindest nicht programmieren.

wie würdest du denn beim Aufruf des Konstruktors eines stl-containers mit Ordnungsrelation das Funktionsobjekt übergeben wenn nicht als ( ..., Order()) ?

Ethon

Ich hatte es relativ häufig und habe mich immer erstmal geärgert.

Ich habe auch mal das Rust Tutorial durchgemacht und so sehr ich den Gedanken an automatisch sichere Software mag. Ich brauche meine Strukturen auf denen ich rumschrubben kann und auch meine hängenden Zeiger finde ich in der Regel recht schnell. Auch wenn das mit den Zeigern immer verteufelt wird, was bestimmt nicht unbegründet ist. Ich liebe meine rohen Zeiger einfach. Da weiß ich was ich habe und sehe was passiert, wenn es nicht zu chaotisch programmiert wurde.

Aber ich bin auch kein Maßstab, da meine Programme kleine überschaubare Ein-Mann-Sachen, mit ein bis fünfzig Dateien, sind.