Von C zu Rust wechseln?

[Realität]

Es ist eine Riesenunterschied ab man alles als Libs zu einer Sprache hinzufügen muss, oder ob alles in einer Sprache fest eingebaut ist und auch vom Compiler sicher gestellt wird, dass weder Anfänger noch Profis in der Hinsicht je eine Fehler machen können. Rust ist in meinen Augen aus den Unzulänglichkeiten von C++ entstanden und in diesen Bereichen von Natur aus besser. Ob es ankommt werden wir sehen. Auf jeden Fall ist es von Embedded bis zur Webapp einsetzbar und jedes Projekt das man mit C oder C++ machen kann ist auch für Rust geeignet.

Hier wird behauptet C++ habe keine derartigen Unzulänglichkeiten, oder da muss der Programmierer halt aufpassen. Dieses Aufpassen wird schwieriger je mehr Leute an einem Projekt arbeiten und je größer das Projekt wird. Bei Rust ist es egal wie viele Leute daran arbeiten, ob es Profis oder Rookies sind und auch wenn das Projekt ein Windows oder Linux sein sollte. Eine bestimmte, sehr relevante, Art von Fehler kann nie auftreten. Wenn man solche Fehler vermutet, dann braucht man nur in den unsafe-Blöcken nach schauen und nicht im gesamten Projekt. Was meint ihr wie viel Arbeitszeit und Stress so eine Sprache spart und wie viel mehr Sicherheit sie mit Zero-Costs einem schenkt.

Keine neue Sprache zuvor hat mich derart vom Hocker gerissen wie Rust. Die Sicherheit nur dem Entwickler zu überlassen ist wirklich sehr sehr dumm, aber es gingt bis jetzt nicht anderes C++ hat das vieles besser als C gemacht und Rust macht vieles besser als C++. Es gibt nun einmal auch in der IT eine Evolution und von zehn neuen Sprachen ist mal eine dabei, die dann die Herrschaft übernimmt, obwohl die C++ eh nur noch sehr wenig eingesetzt wird. Eigentlich nur in Programme die absolute Performance brauchen, bei allen anderen Projekten greift man sehr sehr gerne zu besseren Lösungen.

[Fytch]

Realität schrieb:

[...]obwohl die C++ eh nur noch sehr wenig eingesetzt wird.

Interessant.

[Swordfish]

Was asfdlol?? Hast du noch nicht mitbekommen, daß C++ selbst im hpc längst nicht mehr stand der dinge ist!?

[SLx64]

Swordfish schrieb:

Was asfdlol?? Hast du noch nicht mitbekommen, daß C++ selbst im hpc längst nicht mehr stand der dinge ist!?

Nur so aus Interesse - was ist denn dort so Stand der Dinge?

[dot]

FORTRAN 77... :p

[Fytch]

Swordfish schrieb:

Was asfdlol?? Hast du noch nicht mitbekommen, daß C++ selbst im hpc längst nicht mehr stand der dinge ist!?

Bisschen was habe ich letztens mitbekommen. In meinem Chip.de-Magazin stand, dass nun vor allem die NASA auf Java und Rust setzt. Stimmt das?
Ich überlege mir derzeit auch zu wechseln, da mir in C++ immer wieder doofe Speicherfehler passieren. An dieser Knacknuss war ich gestern den ganzen Tag dran:

int* Datas = new int(0);
try
{
	std::cin >> *reinterpret_cast<int*>(&Datas);
}
catch(...)
{
	std::cerr << "Fehler aufgetreten, Programm wird terminiert!" << std::endl << std::endl;
	delete Datas;
	return -1;
}
f(*Datas);
delete Datas;

In Java oder in Rust wäre mir das nicht passiert...

[DreiFragen]

asfdlol schrieb:

int* Datas = new int(0);
try
{
	std::cin >> *reinterpret_cast<int*>(&Datas);
}
catch(...)
{
	std::cerr << "Fehler aufgetreten, Programm wird terminiert!" << std::endl << std::endl;
	delete Datas;
	return -1;
}
f(*Datas);
delete Datas;

Zwei Fragen:
1. Was war der Fehler?
2. Wieso castest du überhaupt und wieso benutzt du ein & auf einen Pointer?
3. Wieso hast du überhaupt ein new gemacht? Hättest du doch auch auf dem Stack anlegen können, oder?

[dot]

http://38.media.tumblr.com/130a600b1a179d207c5a6e0a74ee7288/tumblr_mn09x5O9Ef1qdz44io1_500.jpg

[Grund]

Der Grund, weshalb rust erfolgreich sein wird, ist, dass genügend Leute an den Erfolg glauben. D. h., sie werden die Programmiersprache einfach nutzen. Es existiert ja schon jetzt ein brauchbares Buildsystem. Es fängt also schon mit der Tool-Chain an. Außerdem gibt es eine llvm-Integration. Und das Interesse hier im Forum ist auch ein Anzeichen dafür, dass manche C++ endlich abgelöst sehen wollen.

[Ethon]

Also wird Rust so erfolgreich wie Prolog und Haskell? Wobei, die taugen als Lehrsprachen von daher werden sie durch Universitäten verbreitet, Rust taugt dafür eher schlecht.

[Grund]

Du scheinst es nicht verstanden zu haben. Rust taugt als C++ Ersatz. :p

[Ethon]

Und du meinst man hat Lust auf eine neue Krankheit, die man mit sich herumschleppen muss?

[Nathan]

Du scheinst es nicht verstanden zu haben. Rust ist perfekt.

Ok, sorry, der musste sein.

[Swordfish]

@Ethon: Du musst blind sein. Rust ist der einzige weg in eine bessere Zukunft!

~@dot: yay!~

[Elliosso]

Wieviel Performance bzw. Rechenzyklen kostet denn diese ganze Sicherheit, die Rust bieten soll?

Was soll hier ein Entwickler machen, für den die Geschwindigkeit wichtig ist?

[hustbaer]

asfdlol schrieb:

An dieser Knacknuss war ich gestern den ganzen Tag dran:

int* Datas = new int(0);
try
{
	std::cin >> *reinterpret_cast<int*>(&Datas);
}
catch(...)
{
	std::cerr << "Fehler aufgetreten, Programm wird terminiert!" << std::endl << std::endl;
	delete Datas;
	return -1;
}
f(*Datas);
delete Datas;

In Java oder in Rust wäre mir das nicht passiert...

Wenn das kein Scherz ist, dann musst du ganz dringend eines von zwei Dingen tun:

1. Lern C++
2. Lass C++ bleiben

[krümelkacker]

Elliosso schrieb:

Wieviel Performance bzw. Rechenzyklen kostet denn diese ganze Sicherheit, die Rust bieten soll?

So gut wie gar nichts. Temporale Speichersicherheit ist eine Sache, die komplett zur Übersetzungszeit gewährleistet wird, also ohne Laufzeitchecks auskommt. Spatiale Speichersicherheit wird, falls nötig, über Laufzeitchecks erhalten. Wenn solche Checks irgendwo stattfinden, weil sie nicht wegoptimiert wurden, dann fallen sie trotzdem nicht besonders ins Gewicht, wenn man das mal mit SoftBound+CTS vergleicht; denn in Rust gibt es keine Zeigerarithmetik im herkömmlichen Sinne, die solche Checks kompliziert werden lassen würden (Shadow Tables und co). In Rust arbeitet man in der Hinsicht mit „Slices“. Das sind „fette Zeiger“, die nicht nur auf ein einzelnes Element sondern quasi auf einen ganzen Bereich zeigen, den man nur verkleinern darf. Das einfache Iterieren über ein Array ist z.B. genauso billig wie in C, wenn man das idiomatisch über Iteratoren macht.

Elliosso schrieb:

Was soll hier ein Entwickler machen, für den die Geschwindigkeit wichtig ist?

Was soll der schon machen? Deine Frage setzt voraus, dass Rust vom Sprachdesign her in der Hinsicht ein Problem hätte. Das hat es nicht. Diejenigen, denen Geschwindigkeit wichtig ist, werden nicht unbedingt ein Problem mit Rust haben. Und wenn sie z.B. über einen Profiler doch feststellen, dass das Bounds Checking an irgendeiner heißen Stelle wirklich stört, dann hoffe ich doch mal, dass in der Lage sind, diese Situation richtig zu bewerten. Zur Not gibt es eben noch get_unchecked , worüber man Slice-Elemente ohne Bounds-Checking in unsafe -Blöcken dereferenzieren kann. Das vergrößert natürlich die Angriffsfläche. Wenn man da etwas falsch macht, ist es hin mit den Sicherheitsgarantien.

Ich finde, das ist ein sehr guter Kompromiss. Die Stellen, wo man Fehler machen kann, die Löcher in die Speichersicherheit reißen würden, sind klar als solche zu erkennen ( unsafe -Blöcke) und sollten nur einen sehr kleinen Teil des kompletten Codes ausmachen, wenn es sie überhaupt in einem Projekt gibt. Es bietet sich auch eine automatisierte Vollstreckung einer Review-Policy an, die verlangt, dass ein zusätzlicher Reviewer nochmal über den Code rüber schaut, wenn ein unsafe -Block bei einer Änderung angefasst oder neu eingeführt wurde.

[hustbaer]

Mal ne GANZ doofe Frage: wie geht Rust mit Kopien von immutable Typen wie z.B. (hoffentlich) Strings um? Ref-Counting? Per Library oder eingebaut? Ganz was anderes?

[Marthog]

hustbaer schrieb:

Mal ne GANZ doofe Frage: wie geht Rust mit Kopien von immutable Typen wie z.B. (hoffentlich) Strings um? Ref-Counting? Per Library oder eingebaut? Ganz was anderes?

Wenn man nicht kopiert, sondern

let x = irgendeinString;

schreibt, wird das per move gemacht. Meistens benutzt man aber string-slices, diese bieten naemlich die gleichen operationen wie immutable strings und sind sowas wie std::string_view, aber besser in die Sprache integriert. String literale sind zum Beispiel string slices und so ersetzen sie const char* im Anwendercode komplett. Erst dann, wenn ein String kopiert wird (explizit mit .clone()), wird wirklich Speicher reserviert.
Alleine dadurch braucht man kaum noch kopien. Ansonsten ist vieles noch nicht fertig und so sind strings zur Zeit intern noch durch ein std::Vec<u8> repraesentiert. Ich vermute, dass mindestens small string optimization noch irgendwann kommen wird.

[hustbaer]

Ich meine wenn man ein immutable Objekt an mehrere Stellen übergibt.
Kopieren ist ja eher ineffizient, speziell wenn man dafür dynamisch Speicher besorgen muss.

Muss ja irgend einen Mechanismus geben es ohne Kopieren mehreren Stellen zugänglich zu machen.
=> wie?