Forum: PC-Programmierung Rust - ist das hier um zu bleiben?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von DPA (Gast)


Lesenswert?

MaWin schrieb:
> Weder Java noch Python bieten zum Beispiel die Garantie der Abwesenheit
> von Data-Races.

Ja schon, aber es gibt viele sehr einfache Wege, diese zu vermeiden. Das 
Problem hat man ja nur, wenn man threads verwendet, und mit mehreren 
Threads auf die selben Daten zugreift. In der Praxis braucht man das nur 
selten wirklich. Meistens braucht man überhaupt keine Threads.

Bei python ist meistens async-await eine sehr gute Alternativen.
Je nachdem kann man ein Programm auch mehrfach starten, wenn das zu 
verarbeitende untereinander unabhängig ist.
Und in Java ist es extrem einfach, lock guards zu machen. Eigentlich 
muss man da meistens nur nicht vergessen, die richtigen Methoden / 
Blöcke mit "synchronized"  oder "synchronized(objekt)" zu kennzeichnen.

Zudem ist noch zu beachten, dass man den Ablauf auch falsch machen kann, 
ohne klassische Data-Races. z.B. Kannst du trotzdem festlegen, dass ein 
Bankomat Geld ausgibt, und dass er es vom Kontobetrag abzieht, ohne 
festzulegen, das erst das eine, und dann erst das andere passiert. Du 
kannst in Rust dann halt nicht gleichzeitig auf den Kontobetrag 
zugreifen, und es ist etwas schwerer, das so derart falsch zu machen, 
aber derartige Race-Conditions kannst du trotzdem erzeugen. Ist halt 
dann kein Data-Race mehr, sondern ein falscher Ablauf, aber kein 
bisschen weniger schlimm. Es ist wie überall, die Entwickler werden 
einfach neue Wege finden, Dinge falsch zu machen.

von MaWin (Gast)


Lesenswert?

DPA schrieb:
> Ja schon, aber es gibt viele sehr einfache Wege, diese zu vermeiden.

Und genau das ist der Unterschied. Jede Sprache hat Mittel und Wege 
diese Fehlerklasse zu vermeiden. In Rust ist es gar nicht möglich 
diesen Fehler zu machen.

> Das
> Problem hat man ja nur, wenn man threads verwendet, und mit mehreren
> Threads auf die selben Daten zugreift. In der Praxis braucht man das nur
> selten wirklich.

Ja, weil es in vielen Sprachen extrem schwierig ist überhaupt Threads zu 
verwenden. (Ab C++11 ist es wenigstens in C++ recht einfach geworden).
In Rust ist es hingegen sehr einfach Threads zu verwenden. Sehr viele 
Rustprogramme nutzen Threads.

DPA schrieb:
> Bei python ist meistens async-await eine sehr gute Alternativen.

Das kann Rust natürlich auch.
Und zusätzlich kann es die Coroutinen auch noch in OS-Threads ausführen. 
Eben weil die Sprache Thread-safety erzwingt, ist dies transparent und 
ohne spezielle Vorkehrungen des Entwicklers möglich. Das kann Python 
nicht.

DPA schrieb:
> Eigentlich
> muss man da meistens nur nicht vergessen, die richtigen Methoden /
> Blöcke mit "synchronized"  oder "synchronized(objekt)" zu kennzeichnen.

In Rust kann man das gar nicht falsch machen, weil man gar keinen 
Zugriff auf die Daten bekommt, wenn man das Locking falsch macht.

DPA schrieb:
> aber derartige Race-Conditions kannst du trotzdem erzeugen.

Das ist richtig.
Hat aber auch niemand behauptet, dass Rust gleich alle Probleme löst.

von Carsten P. (r2pi)


Lesenswert?

MaWin schrieb:
> Es geht aber darum, dass Rust diese Konzepte erzwingt und noch viel
> weiter treibt (Lifetimes) als z.B. C++.

Sagte ich doch, das tun Rust, Python, NanoFramework und sicher noch ein 
paar andere. Und wie andere ebenfalls sagten, ist das nur eins der 
Einfallstore für clevere Hacker. Es gilt der Satz des indischen Weisen: 
Die größte Sicherheitslücke bei IT-Systemen sitzt vor dem Bildschirm und 
klickt auf Links.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
> MaWin schrieb:
>> Es geht aber darum, dass Rust diese Konzepte erzwingt und noch viel
>> weiter treibt (Lifetimes) als z.B. C++.
>
> Sagte ich doch, das tun Rust, Python, NanoFramework und sicher noch ein
> paar andere.

Lifetimes sind ein Alleinstellungsmerkmal von Rust. Mit fällt spontan 
gar keine andere Sprache ein, die das auch kann. Im Nachhinein ist das 
auch praktisch nicht in eine bestehende Sprache einbaubar.

> ist das nur eins der Einfallstore für clevere Hacker.

UB/AOOB und Data Races sind nicht nur "irgendein Einfallstor", sondern 
es sind die Fehlerklassen, die für den Großteil der Sicherheitslücken in 
C/C++-Software verantwortlich sind.

> Die größte Sicherheitslücke bei IT-Systemen sitzt an der Tastatur.

Eben.
Und deshalb sollte man Sprachen so designen, dass schwerwiegende Fehler 
gar nicht oder nur schwer möglich sind und im Fehlerfall nicht 
eskalierbar sind.

von Carsten P. (r2pi)


Lesenswert?

MaWin schrieb:
>> ist das nur eins der Einfallstore für clevere Hacker.
> UB/AOOB und Data Races sind nicht nur "irgendein Einfallstor"

Wo habe ich "irgendein Einfallstor" geschrieben? Zitiere mich bitte 
richtig.

von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
> MaWin schrieb:
>>> ist das nur eins der Einfallstore für clevere Hacker.
>> UB/AOOB und Data Races sind nicht nur "irgendein Einfallstor"
>
> Wo habe ich "irgendein Einfallstor" geschrieben? Zitiere mich bitte
> richtig.

Ich habe dich richtig zitiert. Und zwar so:

> ist das nur eins der Einfallstore für clevere Hacker.

von Einer (Gast)


Lesenswert?

Olaf schrieb:
> Das Problem hier ist aber das man fremden Source in eigenen Programmen
> benutzt und der nicht fehlerfrei ist.

Dieser Satz lässt sehr tief blicken.

Du implizierst nämlich, dass fremder Code mehr Fehler enthalten würde, 
als eigener Code. Und genau dieser Mindset ist die Grundlage für 
Software-Fehler, inkl. Sicherheitslücken.

Witzig dabei, dass gerade dieser Mindset immer wieder bei 
Embedded-Leuten zu finden ist, und in aktueller Zeit gerade unzählige 
Embedded-Systeme mit scheunentorartigen Sicherheitslücken glänzen.

Witzig dabei auch, dass die "große" Softwarebranche(n) diesem Irrglauben 
vor etwa 25 Jahren auch aufgesessen ist, und brutal lernen musste, wie 
falsch dieser Mindset war.

Tragisch dabei, dass wieder bewiesen wird, das Gruppe B nicht aus den 
historischen Fehlern der Gruppe A lernt, sondern die gleichen Fehler 
selbst durchleben will. Scheint irgendwie zum Mensch zu gehören.

von Onkel Darwin (Gast)


Lesenswert?

> Und deshalb sollte man Sprachen so designen, dass schwerwiegende Fehler
> gar nicht oder nur schwer möglich sind und im Fehlerfall nicht
> eskalierbar sind.

Naja. Man sollte eines dabei im Auge behalten. Es wird immer mehr in 
Sprachen programmiert, die Anwendern und Entwicklern ermöglichen, in 
kürzester Zeit, d.h. ohne zeitaufwändige Einarbeitung lauffähigen 
Programmcode zu generieren. Wo steht da Rust z.B. im Vergleich mit bei 
vielen beliebten Programmierdialekten?

Zitat von cppbert

> Die Syntax ist nicht ganz leicht und keine Programmiersprache der Welt
> vollbringt Wunder

Wer (der es nicht muss) "quält" 1) sich schon freiwillig mit Zeugs rum, 
für das sich auch bereits bewährte Alternativen anbieten? Vor allem wenn 
letztere sich bereits lange in Entwicklung und damit ziemlich in hohem 
Maße gereift sind.

Wo stehen denn z.B. die noch vor gar nicht so langer Zeit gehypten 
Sprachen wie go und Nim?

Man hört Nim-mer viel ..

Dem Linuxer mag es genügen wenn sein Code ihm ausgabemäßig die Konsole 
befüttert. Unter Windows haben es die Allermeisten aber gerne, wenn sich 
die App(likation) wohl aufgeräumt und im modernen Design dem Auge des 
Anwenders erschließt - nicht nur am Desktop, sondern am Tablet, am 
Smartphone, auf der Smartwatch usw.

Mahnende Beispiele, die das (aufgeräumte GUI-Design) offensichtlich 
nicht bieten, sind hier aus dem CAD-Bereich jüngst genannt worden 
(verschrobene Bedienweise) bzw. wie man es besser macht oder sein kann 
ebenfalls.

Vielleicht will dort Rust aber auch gar nicht hin. Vielleicht hat es der 
an Rust Interessierte mit GUI nicht so, weil ihm das zu "doof" erscheint 
und er sich lieber mit anderem befasst.

Für Quantenalgorithmen gibt es Q-Sharp. Für KI listet die Computerwoche 
vom Nov. 21 Python, C++, JAVA, R, Julia und andere. Da ist weit und 
breit nix von Rust zu lesen.

1) extra in Anführung für die Fanboys ;)

von Olaf (Gast)


Lesenswert?

> Du implizierst nämlich, dass fremder Code mehr Fehler enthalten würde,
> als eigener Code. Und genau dieser Mindset ist die Grundlage für
> Software-Fehler, inkl. Sicherheitslücken.

Nein keineswegs. Du implizierst in deiner schlichten Gedankenwelt ein 
eigene Erkenntnis und baust daraus ein falsches Weltbild das du mir 
ueberstuelpen willst.

Fremder Code kann im Rahmen gemittelter Programmiererfaehigkeit nur 
genauso gut/schlecht sein wie der eigene wenn er von relativ wenigen 
Leuten verwendet wird. Er koennte bezueglich Fehler aber auch sehr viel 
besser sein wenn er von sehr vielen Leuten verwendet wird die alle zur 
Verbesserung beitragen.

Es gibt damit aber auch Probleme:

1. Finde ich eine Luecke/Fehler in einem fremden Code kann ich das dann 
sofort bei vielen Geraeten ausnutzen. Und im Embeddedbereich kannst du 
nicht rumlaufen und den Leuten erzaehlen das die jedes Geraet  einmal im 
Monat updaten muss wie z.B bei Handysoftware.

2. Die Gruende viel fremden Code zu benutzen sind gleichzeitig gute 
Gruende den eben nicht genau zu untersuchen. Das wird ja schon jemand 
anderes gemacht haben. .-)

3. Gerade im Embeddedbereich passen unterschiedliche Programmierstile 
nicht immer perfekt zusammen. Das erhoeht die Resourcenanforderungen. 
Also mehr Strom oder teurere Controller.

4. Eine Tendenz jeden Kram in ein Geraet einzubauen und so die 
Funktionalitaet aufzublasen. Das kann natuerlich ein Vorteil sein, es 
ist aber auf jedenfall auch ein Nachteil.

Jetzt schickt sich Rust ja an C zu verdraengen. Das wuerde ich 
tendenziell positiv finden, ich sehe durchaus den Nachteil von C. 
Allerdings gefaellt mir nicht der Mindset in den Entwicklerhirnen hinter 
Rust. (Erfinden von neuen Woertern fuer alten Wein (z.b crates!), 
Propagierung anderer Buildsysteme obwohl sowas unabhaengig von einer 
Sprache zu sein hat, Internetbezug/AutoUpdates)

Olaf

von MaWin (Gast)


Lesenswert?

Onkel Darwin schrieb:
> Es wird immer mehr in
> Sprachen programmiert, die Anwendern und Entwicklern ermöglichen, in
> kürzester Zeit, d.h. ohne zeitaufwändige Einarbeitung lauffähigen
> Programmcode zu generieren. Wo steht da Rust z.B. im Vergleich mit bei
> vielen beliebten Programmierdialekten?

Das ist eine Anforderung, die einer strengen Typisierung halt 
widerspricht.
Wenn du Rapid Prototyping oder quick & dirty haben möchtest, nimm Python 
oder etwas ähnliches.

> Wer (der es nicht muss) "quält" 1) sich schon freiwillig mit Zeugs rum

Rust ist sehr C-ähnlich. Wer C kennt, findet sich schnell in Rust 
zurecht.

> für das sich auch bereits bewährte Alternativen anbieten? Vor allem wenn
> letztere sich bereits lange in Entwicklung und damit ziemlich in hohem
> Maße gereift sind.

Soso. In ziemlich hohem Maße gereift also. Die ständigen UB-basierten 
Sicherheitslücken reifen wohl mit.

> Wo stehen denn z.B. die noch vor gar nicht so langer Zeit gehypten
> Sprachen wie go und Nim?

Go hat einen völlig anderen Zweck als Rust. Das steht nicht wirklich in 
Konkurrenz.
Nim kenne ich nicht.

> Vielleicht will dort Rust aber auch gar nicht hin. Vielleicht hat es der
> an Rust Interessierte mit GUI nicht so, weil ihm das zu "doof" erscheint
> und er sich lieber mit anderem befasst.

Es ist überhaupt kein Problem GUI-Anwendungen in Rust zu schreiben. Zum 
Beispiel mit GTK.
Das ist sicher nicht der Hauptzweck von Rust, aber es geht gut.
Es wird ständig behauptet man könne Rust nicht für GUI-Applikationen 
einsetzen. Das ist ganz einfach falsch.

von MaWin (Gast)


Lesenswert?

Olaf schrieb:
> kannst du
> nicht rumlaufen und den Leuten erzaehlen das die jedes Geraet  einmal im
> Monat updaten muss wie z.B bei Handysoftware.

Auf meinem Mobiltelefon kommen täglich Updates rein.

> Erfinden von neuen Woertern fuer alten Wein (z.b crates!)

Welches Wort hättest du denn verwendet?

> Propagierung anderer Buildsysteme

Welches Buildsystem hättest du denn genommen?

> obwohl sowas unabhaengig von einer Sprache zu sein hat

Cargo ist unabhängig von der Sprache Rust.

> Internetbezug

Niemand zwingt dich Cargo online zu nutzen.
Du kannst problemlos alle crates lokal vorhalten. Statt der 
Versionsnummer gibst du einfach den relativen Pfad zum Crate in 
Cargo.toml an. Einfacher gehts kaum.

> AutoUpdates

Was soll das sein?

von Carsten P. (r2pi)


Lesenswert?

MaWin schrieb:
>> ist das nur eins der Einfallstore für clevere Hacker.

"eins" ist nicht "irgendein".

Nur zur Kenntnisnahme, auch auf die Gefahr hin, dass ich mich 
wiederhole: Ich halte "C" heutzutage für gar nichts mehr geeignet, weil 
es für alle möglichen Domains bessere Alternativen gibt. Würde heute 
noch wer ein neues Betriebssystem from scratch schreiben, würde er das 
sicher nicht in purem "C" machen, außer vielleicht die 
allerallerrudimentärsten Funktionen, die nötig sind, um einen gemanagten 
Kernel hochzuziehen, und danach zur Laufzeit diese rudimentären 
Funktionen auch gleich wieder entladen.

von HabMut (Gast)


Lesenswert?

Onkel Darwin schrieb:
> Wer (der es nicht muss) "quält" 1) sich schon freiwillig mit Zeugs rum,
> für das sich auch bereits bewährte Alternativen anbieten? Vor allem wenn
> letztere sich bereits lange in Entwicklung und damit ziemlich in hohem
> Maße gereift sind.

Was verstehst du unter bewährte Alternativen? Wenn ich Multithreading 
nutzen will, nützt es mir nicht viel das es C oder C++ schon so lange 
gibt. Ich müsste mich da für längere Zeit einarbeiten, bevor ich stabile 
Software entwickeln kann. Und danach musst du trotzdem immer aufpassen 
dass du trotz Erfahrung keine Fehler machst.
Bei Rust arbeitest du dich auch einmal mühsam in die neuen Konzepte ein 
aber danach garantiert dir der Compiler dass bestimmte schwerwiegende 
Fehler ausgeschlossen sind.

Onkel Darwin schrieb:
> Wo stehen denn z.B. die noch vor gar nicht so langer Zeit gehypten
> Sprachen wie go und Nim?
>
> Man hört Nim-mer viel ..

Bevor Python oder Java erfolgreich wurden, gab es auch andere 
Programmiersprachen die gescheitert sind. Das Sprachen kommen und gehen 
sagt nicht viel über Rust aus.

Was deine konkreten Beispiele angeht: Go wird immer noch genutzt aber 
kann aus Performance Gründen C++ nicht überall ersetzen. Ich denke es 
war auch nicht das Ziel damit Sprachen wie C++ in der gesamten Industrie 
zu ersetzen.
Und Nim? Ich hörte davon, aber ich glaube Nim bei weitem nicht so weit 
wie Rust bisher.

von Gerhard O. (gerhard_)


Lesenswert?

Ob Rust in der Industrie Fuß fassen wird hängt wahrscheinlich doch stark 
davon ab ob sich die Platzhirsche der Compilertoolfirmen wie IAR & Co. 
der Sprache annehmen werden und sie unterstützen wollen.

Deshalb nehme ich an, daß Rust genau wie andere Sprachen offiziell von 
den relevanten Standardorganisationen anerkannt werden muß. Letztens 
hängt Adoption auch von zusätzlicher notwendiger Industrie Bürokratie 
ab. Der embedded Bereich muß auch besonders berücksichtigt werden. Auch 
Debugging und Simulation sind wahrscheinlich wichtige Gesichtspunkte.

Dazu kommt, daß in vielen Firmen die Entwickler nicht unbedingt 
durchsetzen können welche Sprachen für Produktentwicklung verwendet 
werden sollen. Deshalb nehme ich an, daß man geduldig sein werden muß um 
zu erleben wie sich die Adoption ausspielen wird. Die Inertia der 
Menschen ist oft der wirkliche Hinderungsgrund warum neue Paradigmen so 
lange brauchen um Fuß zu fassen.

Erschwerend für eine Adoption werden dann manche Kunden auch darauf 
bestehen ein komplettes Rust Entwicklungspackage wie z.B. IAR Workbench 
für Rust bestellen zu können wo die praktischen Berücksichtigungen der 
realen Welt vorhanden sind. Bis dahin wird man schon abwarten müssen. 
Die Geeks mögen von Rust verzaubert sein, trotzdem fürchte ich, daß 
gerade das nicht genug ist.

OK. Jetzt dürft ihr auf mich hauen wenn ihr könnt:-)

: Bearbeitet durch User
von Carsten P. (r2pi)


Lesenswert?

So, jetzt auch mal meine Meinung zu Rust an sich, nicht das "Ja, du hast 
geschrieben: dies; ich sage dazu: das!"

Prinzipiell finde ich die Idee von Rust sehr gut. Vom Konzept her wäre 
Rust gut geeignet gerade im Embedded-Bereich auf kleinen Controllern, wo 
die Projekte ja schon aus Speichergründen nicht unbedingt ausufern, und 
die Art der Ressourcen-Verwaltung in Rust in ein riesiger Fortschritt. 
Traits gefallen mir auch, die fördern eine klare Trennung von Daten und 
Methoden. In der klassischen Objektorientierung, die ja akademisch immer 
noch so gelehrt wird, sind Daten und Methoden immer brav in einer Klasse 
verpackt, aber in der Praxis ist das nur noch Ballast (Stichwort 
"Puppet-Player-Pattern", TDA, OCP).

Was mich (das ist natürlich immer Geschmackssache) in vielen Punkten 
stört, ist die Syntax. Die sieht mir inkonsistent aus.

Zum Einen ist es im Zeitalter der großen IDEs (seien es VS xyz, sei es 
Eclipse) absolut sinnfrei, ein Wörtchen wie "function" abzukürzen.

Zum Zweiten, so gut ich es finde, dass Curlys zwangsweise sind (guter 
Stil in jeder Curly-Sprache heutzutage), kommt dann das Weglassen von 
runden Klammern wie etwas komplett Gegensätzliches daher und scheint ein 
gewisses Anbiedern an Python und sonstige Whitespace-Sprachen zu sein.

Moderne Programmiersprachen sind nicht mehr auf Tipp-Effizienz, sondern 
auf klare Syntax ausgelegt UND stören nicht mehr mit künstlichen 
Störenfrieden wie * und &. C# ist z.B. mindestens so "C"-Style wie Rust, 
verzichtet aber auf solche Stolpersteine komplett, ebenso auf :, :: und 
-> außer in unsafe-Bereichen. Moderne Programmiersprachen achten viel 
mehr auf Lesbarkeit als der olle Kram von "damals, als alles besser war" 
(eigentlich ja doch schrecklicher). Oder mag wirklich jemand die 
Sternchen-Orgien in "C" bei Funktionszeigern oder die ollen & und -> in 
C++?

Ein nicht besonders großes, aber hübsches Syntax-Gimmick ist, dass es 
keinen Unterschied mehr zwischen for- und for-each-Schleifen gibt. 
Braucht kein Mensch, richtig so. Das konnte schon lange wirklich mal 
weg! ^^

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

Gerhard O. schrieb:
> Ob Rust in der Industrie Fuß fassen wird hängt wahrscheinlich doch stark
> davon ab ob sich die Platzhirsche der Compilertoolfirmen wie IAR & Co.
> der Sprache annehmen werden und sie unterstützen wollen.

Und warum sollten sie? Welcher z.B. Industriekunde würde das fordern 
bzw. kaufen?
Solche Modesprachen existieren nur in ganz kleinen Blasen irgendwelcher 
akademischen Brainfucks und OO-Hipstern die auf jeden Quatsch 
aufspringen und eine smarte Saftpresse zuhause haben.

Gerade die Mitglieder dieser Gruppen verkennen die reale Situation und 
können anscheinend schlecht einordnen, wie irrelevant Rust im wirklichen 
Leben, da wo Geld verdient wird, eigentlich ist.

von Oliver S. (oliverso)


Lesenswert?

Olaf schrieb:
> Er koennte bezueglich Fehler aber auch sehr viel
> besser sein wenn er von sehr vielen Leuten verwendet wird die alle zur
> Verbesserung beitragen.

Finde den Fehler...

Es gibt sehr viel Code, der von sehr vielen Leuten verwendet wird. Es 
gibt aber nur sehr, sehr, sehr wenig Code, der von sehr vielen Leuten 
verwendet wird, die da auch alle zur Verbesserung beitragen.

Und die Frage, ob mehr Fehler in wenig genutzer Software besser sind, 
als wenige in viel genutzer, dürfte noch nicht endgültig ausdiskutiert 
sein.

Oliver

von Carsten P. (r2pi)


Lesenswert?

Cyblord -. schrieb:
> Gerade die Mitglieder dieser Gruppen verkennen die reale Situation und
> können anscheinend schlecht einordnen, wie irrelevant Rust im wirklichen
> Leben, da wo Geld verdient wird, eigentlich ist.

Da ist was dran, aber ich sage bewusst: leider. Wenn man sich die ganze 
Smart-Home-Szene ansieht, wo es sicher bald schon für Klospülungen ne 
App gibt (kennt noch wer diesen unsäglichen Werbespruch von Apple? "Ach, 
dafür gibt's doch bestimmt auch ne App!"), und wenn man das dann mal auf 
den Automotive-Bereich abstrahiert, dann Herzlichen Glückwunsch!

Das ist so ein bisschen wie in der alten Zeit mit Dampfloks: "Was labern 
die da über Elektrifizierung! Ich steh hier mit 1000 Tonnen am Haken an 
der Steigung, und die Räder drehen durch!"

Ob es nun Rust wird oder ne andere Sprache mit zeitgemäßen Konzepten, 
ist mir relativ. Andererseits bin ich faul, und wenn ich die Wahl 
zwischen Rust und Python haben müsste, würde ich eher Rust nehmen, weil 
sie mir vertrauter aussieht aka schneller vom Lernen zur Produktion. Ich 
bin (anders als andere hier) kein Fanboy, aber alleine schon das 
Ressourcen-Konzept ist ne bedenkenswerte Sache.

Das Argument "das hilft mir doch aber jetzt nicht!" ist ein Zeichen von 
mangelnder Planung und vor allem von einer Mischung aus zu vielen 
Aufträgen und zu niedrigen Stunden-/Projektpreisen. Und ja, ich weiß, 
wie knifflig bis unmöglich es ist, ner Kundin beizubiegen, dass sie auch 
was davon hat, wenn wir verlässlicheren Code schreiben, der gleich beim 
ersten Release einigermaßen stabil läuft.

(Bevor mich wer disst: Unternehmen sind meist "Gellschaften" (GmbH, 
AG...), drum "sie".)

: Bearbeitet durch User
von Gerhard O. (gerhard_)


Lesenswert?

Cyblord -. schrieb:
> Gerhard O. schrieb:
>> Ob Rust in der Industrie Fuß fassen wird hängt wahrscheinlich doch stark
>> davon ab ob sich die Platzhirsche der Compilertoolfirmen wie IAR & Co.
>> der Sprache annehmen werden und sie unterstützen wollen.
>
> Und warum sollten sie? Welcher z.B. Industriekunde würde das fordern
> bzw. kaufen?
> Solche Modesprachen existieren nur in ganz kleinen Blasen irgendwelcher
> akademischen Brainfucks und OO-Hipstern die auf jeden Quatsch
> aufspringen und eine smarte Saftpresse zuhause haben.
>
> Gerade die Mitglieder dieser Gruppen verkennen die reale Situation und
> können anscheinend schlecht einordnen, wie irrelevant Rust im wirklichen
> Leben, da wo Geld verdient wird, eigentlich ist.

Das sehe ich möglicherweise positiver als Du. Ich bin der Meinung, daß 
man Rust fairerweise einfach Zeit lassen muß um Fuß fassen zu können. 
Das geht deshalb nicht so schnell weil noch viele Erfahrungen in der 
realen Welt gesammelt werden müssen. Um im weiteren Bereich verwendet zu 
werden ist Standard Adoptierung hier absolut notwendig; geht aber nicht 
so schnell. Bis dahin werde ich mit Interesse die Entwicklung mit 
offenen Augen verfolgen. Bei C und C++ war es auch nicht viel anders.

von Oliver S. (oliverso)


Lesenswert?

Carsten P. schrieb:
> Und ja, ich weiß,
> wie knifflig bis unmöglich es ist, ner Kundin beizubiegen, dass sie auch
> was davon hat, wenn wir verlässlicheren Code schreiben, der gleich beim
> ersten Release einigermaßen stabil läuft.

Was der zwar zunächst Geld spart, das die dann später doppelt wieder 
ausgibt, wenn der ganze Kram wegen Unwartbarkeit auf Grund einer 
Exotenprogrammiersprache in die Tonne gekloppt werden muß.

Ich will jetzt nicht sagen, daß Rust dieses Schicksal droht, aber es ist 
noch nicht übern Berg.

Oliver

von Gerhard O. (gerhard_)


Lesenswert?

Gehört nicht unbedingt zum Thema und ist O.T., aber hier ist noch ein 
allgemeiner Aspekt der mir Sorgen macht:

Wegen der Komplexität und Device Intercommunication moderner verbundener 
Anwendungen werden sehr oft Teile der Anwendung mit eingebunden 
komplexen externen Ressourcen verwendet die nicht immer im Quellenformat 
zur Überprüfung erhältlich sind. Oft müssen BT, WLAN und Ähnliches 
funktionieren weil die Kunden alles über Smartphone und Internet steuern 
wollen. Erschwerend kommt dazu, daß nicht alle Programmierer Genies sind 
und man sich schwer tut Probleme oder Sicherheitslücken zu erkennen bzw. 
Diagnostizieren zu können.

Wenn das tatsächlich so ist, dann ist Produktentwicklung fast immer ein 
riskante Sache und die Sprache vielleicht nur sekundär wichtig. Auch 
wenn Rust z.B. schwerer durch böswillige Elemente zu hintergehen ist, 
können die eingebundenen extern entwickelten Ressourcen alle durch die 
Sprache gegebene Robustheit wieder total zunichte machen. Um bessere 
externe Sicherheit zu erzielen müssten die Probleme an der Wurzel 
angefasst werden.

Ob man dann in C++ oder Rust programmiert ist so gesehen nicht mehr so 
wichtig. Was notwendig ist, externe Stacks zu finden, die robust genug 
sind, Attacken gehörig zu erschweren. Wie man den Rest der Anwendung 
kodiert ist dann nicht mehr so kritisch wenn man nicht gerade groben 
Unfug macht. Ob ich hier mit meinen Ausführungen etwas angeschnitten 
habe was wichtig ist, kann ich praktisch nicht so gut beurteilen weil 
ich in Sachen "Verbundenheit" nicht viel mache und ihr müsst es 
wahrscheinlich besser wissen wie man sichere verbundene Apps und Geräte 
realisiert.

Noch am Rande, man sieht in den Medien und Reklame immer öfters wie man 
Smartphones zur Bedienung, Öffnung der Autoschlösser usw. anpreist. 
Ehrlich gesagt mir wäre es zu blöd jedesmal ein Handy suchen und 
bedienen zu müssen um in mein Auto einsteigen zu können. Es mag sich 
zwar sexy ansehen, aber irgendwie finde ich ist dieser ganze Trend 
überzogen. Ein Handy mag in gewissen Situationen auf diese Weise 
nützlich sein, aber nicht um jeden Preis alles vernetzen zu wollen. 
Gerade diese Sachen verursachen die meisten Sicherheitslücken.

von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
> kommt dann das Weglassen von
> runden Klammern wie etwas komplett Gegensätzliches daher

Du kannst ja runde Klammern nutzen, wenn du das möchtest. Der 
Rust-Compiler hindert dich nicht daran. Du musst nur die Warnung 
abschalten. Eine Zeile in der compiler-config.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Syntax hat man schnell gelernt. Man schaut einmal auf ein Script, dann 
kennt man die Syntax. Das selbe einfach mit anderen Klammern / Keywords 
schreiben, das ist einfach.

Aber plötzlich ändern müssen, wie man ein Programm schreibt, die 
Herangehensweise ändern müssen, und plötzlich gewisse Sachen nicht mehr 
so lösen zu können, wie man das immer überall sonst gemacht hat - das 
ist nicht einfach.

C -> Python ist ersteres.

C -> Rust ist letzteres.

Beim Umstieg zu Rust kommt noch dazu, oft weiss man, das ist in Ordnung, 
aber dann sollte man das eigentlich auch noch dem Compiler beweisen. Da 
fängt dann wahre Frustration an. Ich und der Compiler - wir haben beide 
starke Meinungen, wie wir das lieber umgesetzt sehen wollen...

von Carsten P. (r2pi)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Ich und der Compiler - wir haben beide starke Meinungen,
> wie wir das lieber umgesetzt sehen wollen...

Das ist jetzt nicht böse gemeint, eher als "frohes neues Jahr"... Dann 
schreib dir doch deinen eigenen Compiler! ;-)

von Carsten P. (r2pi)


Lesenswert?

MaWin schrieb:
> Carsten P. schrieb:
>> kommt dann das Weglassen von
>> runden Klammern wie etwas komplett Gegensätzliches daher
>
> Du kannst ja runde Klammern nutzen, wenn du das möchtest. Der
> Rust-Compiler hindert dich nicht daran. Du musst nur die Warnung
> abschalten. Eine Zeile in der compiler-config.

Gut zu wissen. Ist echt mal ein Thema zum sich näher mit beschäftigen, 
und die nächsten Tage finde ich immer wieder mal ein bisschen Leerlauf. 
Nennt sich "nicht existenter Urlaub", aber das Thema interessiert mich 
jetzt echt.

Frage an dich Fachperson: Wenn ich eine Rust-Lib "von woanders" aufrufen 
will, dann genauso wie ne C/C++-Lib?

von Olaf (Gast)


Lesenswert?

> Dazu kommt, daß in vielen Firmen die Entwickler nicht unbedingt
> durchsetzen können welche Sprachen für Produktentwicklung verwendet
> werden sollen.

Ich sehe du hast Industrieerfahrung. .-)

Wenn man die Frage aus dem Subject beantworten moechte dann sollte man 
sich vielleicht mal fragen wie kam es im Embeddedbereich zu dieser 
EXTREMEN C Dominanz. Irgendwie war die Sprache irgendwann da, irgendwie 
hat sie jeder verwendet und keiner hat es je diskutiert. Das hat mich 
auch immer gewundert.

Und noch erstaunlicher, C ist da mittlerweile seit 20Jahren dominant. Da 
kam noch nie jemand der Gedanke das man was anderes verwenden koennte. 
Das ist vollkommen anders als auf dem PC.

Daher denke ich das Rust und jede andere Sprache zumindest im 
Embeddedbereich eine lustige Modeerscheinung bleiben wird. Aehnlich wie 
FORTH oder Pearl. Es ist einfach so das die ganze Industrie extrem 
konservativ ist. Ich bin mir sicher das wir noch die 100Jahrfeier von 
4-20mA und C erleben werden. :-D

Olaf

von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
> Frage an dich Fachperson: Wenn ich eine Rust-Lib "von woanders" aufrufen
> will, dann genauso wie ne C/C++-Lib?

Du kannst in Rust Symbole und Strukturen mit C-Layout und C-Linkage 
anlegen. Wenn es das ist, was du meinst.

von MaWin (Gast)


Lesenswert?

Olaf schrieb:
> Pearl

Meinst du Perl? Das wird leider sehr massiv in der Embedded-Entwicklung 
verwendet. Aber ich denke bei Perl haben mittlerweile viele Leute 
verstanden, dass es nicht mehr zeitgemäß ist. Sogar die Perl-Entwickler 
scheinen das wohl verstanden zu haben und bauen die Sprache nun nach 
modernen Mustern um.

> Ich bin mir sicher das wir noch die 100Jahrfeier von
> 4-20mA und C erleben werden. :-D

Ja, da bin ich mir leider auch sicher.

von Carsten P. (r2pi)


Lesenswert?

Gerhard O. schrieb:
> Gehört nicht unbedingt zum Thema und ist O.T., aber hier ist noch ein
> allgemeiner Aspekt der mir Sorgen macht:
>
> Wegen der Komplexität und Device Intercommunication moderner verbundener
> Anwendungen werden sehr oft Teile der Anwendung mit eingebunden
> komplexen externen Ressourcen verwendet die nicht immer im Quellenformat
> zur Überprüfung erhältlich sind.

Im Ernst, Gerhard, wenn das OT ist, ist das ganze Forum OT. Es gibt 
derzeit wohl kaum ein überall heißer diskutiertes Thema in der ganzen 
IT-Branche als genau das da!

Deswegen verbaue ich nirgendwo auch nur zwei Devices ("Dinge" im Sinne 
von IoT), ohne dass ich einen Knoten dazwischen habe, der die Kisten 
überwacht. Bei uns ist es geschäftlich und bei mir ist es privat auch 
so, dass kein Teil verwendet wird, das fröhlich über http oder noch 
tiefer im Layer unverschlüsselte Daten in die Welt posaunen darf, es sei 
denn, es sitzt zB wie ein einfacher Sensor so nah am nächsten Knoten, 
den wir wieder unter Kontrolle haben, dass du schon die Leitung anritzen 
müsstest, um da was abzugreifen.

Ich konstruiere mal ein gar nicht so fiktives Beispiel: Du bist ein 
Einbrecher. Du hast die nötige technische (durchaus legal beschaffbare 
und auch nicht großartig aufs Konto schlagende) Hardware. Du willst 
natürlich wissen, wann wer zuhause ist. Das ganze Zuhause der Leute, die 
du ausrauben willst, ist natürlich super "smart" (eigentlich steindoof). 
Das Licht wird geschaltet, etwa im Flur, über gaaaanz smarte, übers WLAN 
angeschlossene Lichtschalter. Ja, die Daten sind verschlüsselt, die 
Hersteller sind ja nicht ganz bekloppt. Nur haben sie was vergessen.

Also hältst du deine WLAN-Antenne da aufs Haus, fischst die Pakete ab, 
und stellst fest, dass OIZ324867yyxdf "Aus" bedeutet und 6jhgbsd76345r4 
"Ein". Klingt harmlos. Nun stellst du auch fest, weil die Alarmanlage 
vom selben Hersteller und auch übers WLAN ("dafür gibt's doch bestimmt 
ne App!") läuft, dass 9786dfkjhTX&% "Alarm ein" und PIUz876r54gh "Alarm 
aus" bedeuten. Jetzt kannst du ja mal probieren, mit derselben IP (weil 
du natürlich im Promisk-Modus gelauscht hast) das Signal "Lampe ein" zu 
schicken". Wenn das geht, könnte ja vielleicht auch "Alarm aus" 
funktionieren. Da musst du überhaupt nicht wissen, was die Daten 
wirklich bedeuten. Der Trick ist übrigens schon weit verbreitet bei 
Auto-Dieben, die einfach das Signal des Funk-Schlüssels aufzeichnen und 
wiedergeben.

Würde der entsprechende Coder auf die Idee gekommen sein, einen 
Timestamp mit zu verschlüsseln, wäre das alles hinfällig. Aber wie man 
weiß, ist dem nicht so. Vielleicht, weil er nicht weit genug denkt, 
vielleicht aber auch, weil sein Chef im gesagt hat, dass bei 100.000 
gebauten Autos 10 Cent für den uC schon seinen Bonus ausmachen.

Stromzähler sind übrigens für so eine Schwachstelle bereits vom CCC und 
anderen aufmerksamen Leuten ausgemacht. Die senden gerne den Zählerstand 
ans EVU, und mit ein paar gar nicht so geheimen Tricks kriegt man von 
außen raus, wann der Stromverbrauch hoch und wann niedrig ist. 
Angenommen, bei entsprechenden Stückzahlen kosten ein AtTiny45 45 und 
ein AtMega328 328 Cent. Da kannst du dir ja vorstellen, was der 
Controller beim Kunden sagt, wenn du mit Datensicherheit anfängst, 
während der an den Bonus denkt.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
> Der Trick ist übrigens schon weit verbreitet bei
> Auto-Dieben, die einfach das Signal des Funk-Schlüssels aufzeichnen und
> wiedergeben.

Replay-Attacks funktionieren seit 20 Jahren nicht mehr bei 
Autoschlüsseln und bei allen anderen Arten von Crypto-Funkschaltern.

Und es ist hier völlig Off-Topic.

von Carsten P. (r2pi)


Lesenswert?

MaWin schrieb:
> Carsten P. schrieb:
>> Frage an dich Fachperson: Wenn ich eine Rust-Lib "von woanders" aufrufen
>> will, dann genauso wie ne C/C++-Lib?
>
> Du kannst in Rust Symbole und Strukturen mit C-Layout und C-Linkage
> anlegen. Wenn es das ist, was du meinst.

Ja, genau, das meinte ich, also so, dass ich sie von außen mit anderen 
Sprachen aufrufen kann wie ne "C"-Lib.

von Nop (Gast)


Lesenswert?

Olaf schrieb:

> Und noch erstaunlicher, C ist da mittlerweile seit 20Jahren dominant.

1) Es gibt C-Compiler für jedes Target.
2) Es ist kein Problem, C-Entwickler zu finden.
3) C ist relativ einfach.

Der dritte Punkt ist insofern relevant, als daß das eigentliche Coding 
oftmals nur ein kleiner Teil der Arbeit ist, für den man nicht extra 
einen Coding-Spezialisten einstellen würde, den man aber für eine 
komplizierte Sprache bräuchte.

von Carsten P. (r2pi)


Lesenswert?

MaWin schrieb:
> Carsten P. schrieb:
>> Der Trick ist übrigens schon weit verbreitet bei
>> Auto-Dieben, die einfach das Signal des Funk-Schlüssels aufzeichnen und
>> wiedergeben.
>
> Replay-Attacks funktionieren seit 20 Jahren nicht mehr bei
> Autoschlüsseln und bei allen anderen Arten von Crypto-Funkschaltern.

Komisch, dass die Mediatheken voll davon sind, und die sind damals, vor 
20 Jahren, natürlich deswegen mit ner 16:9 Arri aufgenommen worden, als 
noch niemand an HD dachte, damit es heute authentisch wirkt... ^^

So viele kluge Sachen du manchmal schreibst, MaWin, manchmal schießt du 
deiner Glaubwürdigkeit selbst ins Knie ;-)

von Carsten P. (r2pi)


Lesenswert?

Nop schrieb:
> 3) C ist relativ einfach.

Definiere "relativ" ^^

Wir wissen alle, dass das totaler Quatsch ist. Aus Sicht eines BWLers 
vielleicht. Aber technisch gesehen ist blankes "C" genauso "einfach" wie 
Assembler.

Wenn du schonmal ernsthafte (das heißt kommerziell in großen Stückzahlen 
verwendete und sicherheitstechnisch relevante) Software entwickelt als 
mit einem Nicht-Coder als Vorgesetztem, Kunden oder whatnot, weißt du, 
wie schnell aus der mal eben hin geschnodderten "Machbarkeitsstudie" ein 
Denkmal wird, das nicht mehr gemeißelt, sondern nur noch angemalt wird.

Ich jedenfalls erinnere mich sehr gut daran, dass ich vor uff... knapp 
30 Jahren? meinem damaligen Chef zeigte, wie man von nem PERL-Script im 
Sekunden-Takt Texte an nen Webbrowser (der hieß damals noch Netscape 
Navigator) schickt, bis er verstanden hatte, dass man daraus nen Chat 
bauen könnte, und der musste dann natürlich in ner Woche fertig sein. 
Sowas wie ne Anmeldung (ohne E-Mail-Prüfung, keine Zeit) hab ich dann 
nach Feierabend dazu gecodet. Das Ding ist weit gewachsen, aber an echte 
Sicherheit, also echte Authentifizierung hat damals keine Sau gedacht. 
Und die Fehler in dem hin gerotzten Code wurden natürlich gnadenlos 
aufgedeckt. Aber selbst dann fand mein Chef, nö, das tut's, das bringt 
Geld, keine Zeit, weiter zum nächsten Projekt.

Heute sind manche Chefs anders und sensibler für solche Themen. Aber 
eben nicht alle, und genau da entstehen die @MaWin "irgendwelchen 
Scheunentore".

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> Der dritte Punkt ist insofern relevant, als daß das eigentliche Coding
> oftmals nur ein kleiner Teil der Arbeit ist, für den man nicht extra
> einen Coding-Spezialisten einstellen würde, den man aber für eine
> komplizierte Sprache bräuchte.

Das ist richtig. Jedoch ist das Debugging in C relativ kompliziert.
Rust dreht das herum. Das Coden ist etwas schwieriger. Dafür ist das 
Debugging aber deutlich einfacher und beschränkt sich nur noch auf 
logische Fehler.

It works, if it compiles. Das ist zwar natürlich etwas überspitzt 
ausgedrückt, aber es steckt doch ein großer Teil Wahrheit drin.
Deshalb macht außerdem auch deutlich mehr Spaß.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Olaf schrieb:
> Und noch erstaunlicher, C ist da mittlerweile seit 20Jahren dominant. Da
> kam noch nie jemand der Gedanke das man was anderes verwenden koennte.

Davor wurden Controller halt vorrangig in Assembler programmiert. C war 
da schon mal eine mächtige Verbesserung, weil man mit vergleichsweise 
geringen Einbußen an Laufzeiteffizienz eine drastische Verbesserung der 
Coding-Effizienz erzielen kann und (auch wenn hier alle über C 
dahingehend unken) ganz gewiss auch eine drastische Verbesserung der 
Sicherheit. Wer sich (durchaus zu Recht) über die Sicherheitslücken 
beklagt, die mit C möglich sind, der sollte sich einfach mal 
vergegenwärtigen, wie das alles mit Assemblercode aussähe. ;-)

Nun wiederum, einen einmal etablierten Platzhirsch zu vertreiben, ist 
keine so leichte Aufgabe. So groß dürfte der Leidensdruck, C an dieser 
Stelle abzulösen, bei vielen Programmierern im Embedded-Bereich *) nicht 
sein. Gerhard hat ja viele Punkte genannt. Die Verheiratung einer 
Sprache mit einem eigenen Buildsystem dürfte einem solchen Ansinnen auch 
nicht gerade förderlich sein.

*) Ich meine hier mit "Embedded" nicht so'n Highlevel-Kram wie 
Smartphone & Co. Alles, was mit einem fetten Betriebssystem daher kommt, 
ist in dieser Hinsicht ja eher PC-mäßig. Ich meine den wirklichen 
Lowlevel-Kram, der bis vor 30 Jahren komplett in Assembler war (8051 
waren die ersten, bei denen dann jemand mit Compilern angetreten war).

von Nop (Gast)


Lesenswert?

MaWin schrieb:

> Das ist richtig. Jedoch ist das Debugging in C relativ kompliziert.

Kann ich nicht bestätigen. Zumal man embedded sowieso noch nen 
MISRA-Checker drüberlaufen läßt, womit etliche Konstrukte angemeckert 
werden, die gerne verkehrt gemacht werden.

Da man embedded auch etliche Sachen meistens schlichtweg nicht benutzt, 
wie z.B. dynamische Speicherallozierung, sind die damit einhergehenden 
Fehler natürlich auch ausgeschlossen.

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> Kann ich nicht bestätigen.

Hast du schon einmal Rust probiert um einen Vergleich zu bekommen?

> Zumal man embedded sowieso noch nen
> MISRA-Checker drüberlaufen läßt, womit etliche Konstrukte angemeckert
> werden, die gerne verkehrt gemacht werden.

Und jetzt stelle dir Rust wie einen Misra-Checker auf Steroiden vor. Der 
deutlich mehr Dinge prüft, weil sie erst durch die Sprache Rust prüfbar 
werden. Der dir auch noch Vorschläge macht, wie du die Warnungen und 
Fehler beheben kannst.
Meistens stimmen die Vorschläge auch, oder sie lenken einen wenigstens 
eindeutig auf die richtige Lösung hin.

> dynamische Speicherallozierung, sind die damit einhergehenden
> Fehler natürlich auch ausgeschlossen.

Dynamische Speicherverwaltung ist nur ein winziger Teil der Dinge, die 
Rust deutlich besser beherrscht als C (und auch besser als C++. 
Double-Free/Use-after-free ist in Rust nicht möglich).
Außerdem gelten die Rust Speicherkonzepte auch für statische Allokation 
und Stackallokation.

von Oliver S. (oliverso)


Lesenswert?

Carsten P. schrieb:
>> Replay-Attacks funktionieren seit 20 Jahren nicht mehr bei
>> Autoschlüsseln und bei allen anderen Arten von Crypto-Funkschaltern.
>
> Komisch, dass die Mediatheken voll davon sind,

Bei Crypto-Funkschaltern mag das so sein. Der Angriff auf Autos 
funktioniert ganz anders. Und weil das tatsächlich seit Jahren duch alle 
Mediakanäle getrieben wurde, sollte das jeder problemlos auseinander 
halten können.

Oliver

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Die Verheiratung einer Sprache mit einem eigenen Buildsystem

Das ist, wie mehrfach schon gesagt, nicht wahr.
Du kannst Rust ohne weiteres und insbesondere im Embedded-Bereich auch 
mit Make oder jedem anderen Tool verwenden.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Double-Free/Use-after-free ist in Rust nicht möglich).

Solche checks sind ja toll. Genauso wie das Prüfen von Arraygrenzen. Das 
benötigt aber Code zur Laufzeit. Den kann auch Rust nicht wegzaubern. 
D.h. da läuft dann ständig irgendwelcher Code für JEDEN Arrayzugriff und 
es müssen ständig Datenstrukturen im Speicher mitgeführt werden, um 
solche Dinge abfangen zu können.

In der System- und Embedded-Entwicklung will und kann man das aber 
meistens nicht.

: Bearbeitet durch User
von Nop (Gast)


Lesenswert?

MaWin schrieb:

> Hast du schon einmal Rust probiert um einen Vergleich zu bekommen?

Ich habe keine speziellen Debugging-Probleme in C festgestellt, die 
überhaupt einer Lösung bedürften. Wenn, dann klemmt es algorithmisch, 
aber das wäre in jeder programmiersprache so.

> Und jetzt stelle dir Rust wie einen Misra-Checker auf Steroiden vor.

Schön, aber der Leidensdruck ist schlichtweg nicht da. Wozu eine 
deutlich kompliziertere Sprache, wenn es das angebliche Horrordebugging 
in C tatsächlich nicht gibt?

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
>> Double-Free/Use-after-free ist in Rust nicht möglich).
> Solche checks sind ja toll. Genauso wie das Prüfen von Arraygrenzen. Das
> benötigt aber Code zur Laufzeit.

Nein, benötigt es nicht.
Das prüfen von Allokationen passiert komplett zur Compilezeit und das 
Prüfen von Arraygrenzen auch zu einem sehr großen Teil.

> D.h. da läuft dann ständig irgendwelcher Code für JEDEN Arrayzugriff

Nein.
Wenn der Array-Index nicht beliebig sein kann, dann wird das zur 
Compilezeit aufgelöst.

Außerdem braucht man in Rust deutlich seltener Arrays, als in C.
Mit Rust-Enums zum Beispiel kann man viele Dinge tun, die man in C mit 
C-Enums und Arrays machen würde.

> und es müssen ständig Datenstrukturen im Speicher mitgeführt werden

Ständig nicht. Aber teilweise natürlich schon. Ein Slice ist zum 
Beispiel ein Zeiger und eine Länge.
Aber das ist in C auch nicht anders. An den Stellen, wo du in Rust ein 
Slice verwendest, würdest du in C einen Pointer und ein Längen-Integer 
manuell mitschleppen.

Rust hat hier praktisch keinen Laufzeitnachteil gegenüber C.

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> Schön, aber der Leidensdruck ist schlichtweg nicht da. Wozu eine
> deutlich kompliziertere Sprache, wenn es das angebliche Horrordebugging
> in C tatsächlich nicht gibt?

Ja, dann ist doch alles gut.
Niemand zwingt dich.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:

> Nein, benötigt es nicht.
> Das prüfen von Allokationen passiert komplett zur Compilezeit und das
> Prüfen von Arraygrenzen auch zu einem sehr großen Teil.

Ahso alles zur Compilezeit. Also wenn es dynamische Allokation gibt, 
dann muss man auch Grenzen zur Laufzeit prüfen.

> Wenn der Array-Index nicht beliebig sein kann, dann wird das zur
> Compilezeit aufgelöst.

Und wenn deine Tante Eier hätte wäre sie dein Onkel. Der konkrete Index 
kann jederzeit von einer Eingabe zur Laufzeit abhängen.

> Rust hat hier praktisch keinen Laufzeitnachteil gegenüber C.

Jaja bla blubb. Erzähls deinen Hipster-Freunden.

Es gibt nur zwei Möglichkeiten: Entweder du kannst relativ ungestört 
direkt in den Speicher reingreifen oder jeder Fetzen Speicher ist 
abgesichert, was aber Datenstrukturen und Code braucht, der Checks 
ausführt.
Das kann man nicht wegdiskutieren.

: Bearbeitet durch User
von Nop (Gast)


Lesenswert?

Cyblord -. schrieb:

> Und wenn deine Tante Eier hätte wäre sie dein Onkel. Der konkrete Index
> kann jederzeit von einer Eingabe zur Laufzeit abhängen.

Praktisches Beispiel: eine for-Schleife über alle Deine 
Temperatursensoren, deren Werte in einem Array stecken. Da kann der 
Compiler durchaus statisch ermitteln, ob das Array mit ausreichender 
Größe deklariert ist.

von Cyblord -. (cyblord)


Lesenswert?

Nop schrieb:
> Cyblord -. schrieb:
>
>> Und wenn deine Tante Eier hätte wäre sie dein Onkel. Der konkrete Index
>> kann jederzeit von einer Eingabe zur Laufzeit abhängen.
>
> Praktisches Beispiel: eine for-Schleife über alle Deine
> Temperatursensoren, deren Werte in einem Array stecken. Da kann der
> Compiler durchaus statisch ermitteln, ob das Array mit ausreichender
> Größe deklariert ist.

Das kann jedes PCLINT finden. Was bringt ein statisches Beispiel? Ein 
einziges dynamisches Beispiel und du brauchst den Check zur Laufzeit.

Deshalb ist diese Sicherheit eben kein Verdienst von Rust, sondern muss 
in jedem Fall erkauft werden. Die Sprachdefinition und die möglichen 
Checks zur Compilezeit sind Kindergarten. Statische Codeanalyse wurde 
schon vor ner Weile erfunden.

: Bearbeitet durch User
von Nop (Gast)


Lesenswert?

Cyblord -. schrieb:

> Das kann jedes PCLINT finden.

Aber nicht, wenn Du das Array als Parameter einer Funktion übergibst, 
womöglich noch in einer anderen TU, weil es in C dann zu einem Pointer 
ohne Längeninformation verflacht.

von Cyblord -. (cyblord)


Lesenswert?

Nop schrieb:
> Cyblord -. schrieb:
>
>> Das kann jedes PCLINT finden.
>
> Aber nicht, wenn Du das Array als Parameter einer Funktion übergibst,

Doch ganz sicher.

> womöglich noch in einer anderen TU, weil es in C dann zu einem Pointer
> ohne Längeninformation verflacht.


Ja und wie sieht dein statischer Check aus, wenn ich einen Index über 
UART empfange?

von Nop (Gast)


Lesenswert?

Wobei es natürlich bessere statische Code-Checker für C gibt, die auch 
interprozedurale Analyse können - aber PC-Lint speziell kann es halt 
nicht.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Also wenn es dynamische Allokation gibt,
> dann muss man auch Grenzen zur Laufzeit prüfen.

Ja. Genau wie in C.

> Der konkrete Index
> kann jederzeit von einer Eingabe zur Laufzeit abhängen.

In dem Fall musst du das in C auch prüfen.

> Das kann man nicht wegdiskutieren.

Ja, doch.
Rust ist halt sehr viel ausdrucksreicher als C. Die Enums habe ich ja 
bereits genannt. Die sind halt zur Compilezeit komplett prüfbar. Man 
kann in Rust halt Dinge ausdrücken, die in C gar nicht möglich sind.

Und wenn es dann wirklich diese eine Stelle gibt, die sooooooooooo 
performancekritisch ist und es dort auch gar nicht möglich ist das in 
Rust zu formulieren ohne Performanceoverhead, dann hat man immer noch 
die Möglichkeit von Unsafe-Rust. Da kannst du dich nach Herzenslust mit 
ungeprüfter C-Pointerarithmetik austoben.
Aber es kommt praktisch nicht vor, dass das notwendig ist, weil man 
eigentlich alles in Rust performant ausdrücken kann.
Performance ist ein Designziel von Rust!

> Jaja bla blubb. Erzähls deinen Hipster-Freunden.

Mit dem Argument hast du mich jetzt natürlich überzeugt ;)

von Cyblord -. (cyblord)


Lesenswert?

Nop schrieb:
> Wobei es natürlich bessere statische Code-Checker für C gibt, die auch
> interprozedurale Analyse können - aber PC-Lint speziell kann es halt
> nicht.

Ja dann nimmst Klocwork.

Rust brauch ich dafür immer noch nicht. Und wie dynamische Indizes ohne 
zusätzlichen Code und Daten geprüft werden kannst du sicher aufzeigen.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> In dem Fall musst du das in C auch prüfen.

Nein, ich KANN. Ich muss aber nicht. Vor allem wird kein Zwangsweise 
Code erzeugt der das prüft.

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> Praktisches Beispiel: eine for-Schleife über alle Deine
> Temperatursensoren, deren Werte in einem Array stecken. Da kann der
> Compiler durchaus statisch ermitteln, ob das Array mit ausreichender
> Größe deklariert ist.

Ja, sogar in C geht das meistens.
In Rust geht es aber öfter, weil Arrays vernünftig typisiert sind und 
nicht so ein Unfug mit Array-Pointer-Decay gemacht wird.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Ja und wie sieht dein statischer Check aus, wenn ich einen Index über
> UART empfange?

Es gibt ihn nicht. Genauso wenig, wie es ihn in C gibt.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> In Rust geht es aber öfter, weil Arrays vernünftig typisiert sind und
> nicht so ein Unfug mit Array-Pointer-Decay gemacht wird.

Dann kann Rust wohl keine Objekte/Strukturen serialisieren? Oder wie 
wandle ich sowas in ein Byte-Array um es z.B. über einen UART zu senden? 
Kann Rust beim Deserialisieren (Empfang über UART) prüfen ob das Objekt 
den korrekten Typ hat?
Und das auch noch ohne zusätzlichen Speicher?

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Nein, ich KANN. Ich muss aber nicht.

Ja, genau. Das ist ja das Problem.

> Vor allem wird kein Zwangsweise Code erzeugt der das prüft.

In Unsafe-Rust kannst du auch ungeprüfte Zugriffe verwenden, wenn du 
unbedingt scharf auf Sicherheitslücken bist.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Dann kann Rust wohl keine Objekte/Strukturen serialisieren?

Wie kommst du jetzt darauf?

https://crates.io/crates/serde

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
> In Unsafe-Rust kannst du auch ungeprüfte Zugriffe verwenden, wenn du
> unbedingt scharf auf Sicherheitslücken bist.

Tja in C will man eben relativ viel Freiheit mit einigermaßen 
ordentlichen Datentypen, Strukturen und Kontrollmechanismen.

Wer das nicht will, nimmt C#, Java oder halt Rust.
Nur kommen diese ganzen Checks eben nicht ohne Code und Daten zur 
Laufzeit aus. Darum geht es mir. Es ist nicht die tolle Sprache die 
irgendwas sicher macht, sondern die Unmengen an automatisch erzeugtem 
Code.
Deshalb wird es C nicht ablösen. Weil man genau deshalb C verwendet um 
das nicht zu haben.
Es gab schon genug Versuche mit Java auf Embedded. Und viele ähnliche 
Scherze. Am Ende ist das alles nur viel aufgeblasener Code um ein paar 
Zeilen produktiv Code in einem sicheren Setting zu schreiben.

von Nop (Gast)


Lesenswert?

Cyblord -. schrieb:

> Es gab schon genug Versuche mit Java auf Embedded.

Das Problem dabei war doch wohl vielmehr der GC, und den hat Rust nicht. 
Das Problem von Rust ist IMO eher, daß es zu kompliziert ist - und wenn 
die Leute, die embedded C verwenden, bislang eine kompliziertere Sprache 
gewollt hätten, dann hätten sie schon längst auf C++ umgestellt. 
Insofern ist Rust eher ein potentieller Ersatz für C++, nicht für C.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
>> Dann kann Rust wohl keine Objekte/Strukturen serialisieren?
>
> Wie kommst du jetzt darauf?
>
> https://crates.io/crates/serde

Natürlich bietet Rust diese Funktionalität, aber der Punkt ist, wenn du 
ein Objekt in einen Bytestrom verwandelst, dann hast du auch keine 
Sicherheit mehr. Außer du baust mit zusätzlichen Daten wieder was drum 
rum.
Nichts anderes passiert in C wenn man direkt in den Speicher einer 
Struktur oder eines Arrays reingreift. Und manchmal muss man das eben, 
z.B. mit angesprochenen Fall um das über UART zu senden.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Nur kommen diese ganzen Checks eben nicht ohne Code und Daten zur
> Laufzeit aus. Darum geht es mir.

Ja. Darum geht es dir.

Es ist aber falsch.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Nichts anderes passiert in C

Schön, dass du es doch noch eingesehen hast.
Rust ist in diesem Aspekt nicht langsamer als C.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
> Cyblord -. schrieb:
>> Nur kommen diese ganzen Checks eben nicht ohne Code und Daten zur
>> Laufzeit aus. Darum geht es mir.
>
> Ja. Darum geht es dir.
>
> Es ist aber falsch.

Dann zeig auf, wie ein dynamischer Index ohne Laufzeit und Daten von 
Rust geprüft wird.

Minimalbeispiel:
1
int a[100];
2
int x=receiveUART();
3
int d=a[x];

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
> Rust ist in diesem Aspekt nicht langsamer als C.

Dann kann Rust in diesem Aspekt auch nicht sicherer sein.
Laufzeitchecks gibt es nicht umsonst. Kann es nicht geben.

: Bearbeitet durch User
von DPA (Gast)


Lesenswert?

Wenn du z.B. ein Array a[n] und eins b[m] hast, und dann eins c[n+m], 
musst du nicht wissen, was n und m sind, um zu wissen, dass c[0:n] und 
c[n:m] darin liegen.
Wenn du das für c[i] wissen willst, und du weist nichts über i (z.B. 
user gibt es ein) muss gecheckt werden ob es platz hat. Aber das muss 
man dann auch in c. Man braucht nur genug Metadaten beim Kompilieren.

von Carsten P. (r2pi)


Lesenswert?

Cyblord -. schrieb:
> In der System- und Embedded-Entwicklung will und kann man das aber
> meistens nicht.

Ich lese mich ja gerade in Rust ein wenig ein, weil ich mir die Zeit 
dafür nehme. Erstens ist es natürlich mit nem (verschmerzenswerten) 
Overhead (das meiste passiert zur Compile-Zeit) verbunden, aber meine 
Antwort auf deine Aussage lautet unabhängig von der Programmiersprache:

Wer das nicht WILL, wird irgendwann (sehr bald) den Bach runter gehen. 
Embedded ist nicht Zuse in der Neuzeit. Die Anforderungen gerade im 
Embedded-Bereich sind Sicherheit, Sicherheit, und bevor ich es vergesse: 
Sicherheit!

Es liegt natürlich an deinem Naturelle, ob du damit leben kannst, dass 
dein Auftraggeber nach ein paar Toten und Schwerverletzten wegen einer 
falschen Programmierung von Airbags zigtausend Autos in die Werkstatt 
zurück rufen musst. Wenn du schlau warst, hast du jede Haftung 
ausgeschlossen im Vertrag...

Wessen Maxime in diesem Bereich nur billig, billig! uuuund billig! ist, 
wird sich eher früher als später wundern, wenn er mit Klagen überrissen 
wird.

Diese "ich weiß schon, was ich mache"-Attitüde ist einfach Mist. Ein 
Embedded-Coder hier, der seinen kompletten Code mit Unit-Tests 
überzieht? Test-driven? Clean Code anyone? Im Ernst, wenn die Produkte 
weiter nur auf billig, billig gebaut werden, darf sich niemand wundern, 
wenn die genauso miesen, aber nur halb so teuren Sachen aus China den 
Markt dumpen.

von Carsten P. (r2pi)


Lesenswert?

Cyblord -. schrieb:
> Minimalbeispiel:
>
>
1
> int a[100];
2
> int x=receiveUART();
3
> int d=a[x];
4
>

Du prüfst also nicht, ob x > 100 ist? Oh, wow, ich hoffe, du 
programmierst keine Airbags... Achso, es ging um Rust. Jepp, das kriegt 
Rust hin, zur Übersetzungszeit bereits, weil es den Rückgabewert von 
receiveUART() prüft und dann feststellt, ob er die Array-Grenze 
überschreiten kann.

Das könnte ein entsprechender "C"-Compiler aber auch, so ne 
Schlampigkeit feststellen ^^

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

Carsten P. schrieb:

> Du prüfst also nicht, ob x > 100 ist?

Es ging ja darum dass Rust dies anscheinend ohne Overhead automatisch 
prüft.

> Achso, es ging um Rust. Jepp, das kriegt
> Rust hin, zur Übersetzungszeit bereits, weil es den Rückgabewert von
> receiveUART() prüft und dann feststellt, ob er die Array-Grenze
> überschreiten kann.

Erstaunlich. Es kann in die Zukunft sehen welcher Wert über den UART 
reinkommt?

von Oliver S. (oliverso)


Lesenswert?

Carsten P. schrieb:
> Es liegt natürlich an deinem Naturelle, ob du damit leben kannst, dass
> dein Auftraggeber nach ein paar Toten und Schwerverletzten wegen einer
> falschen Programmierung von Airbags zigtausend Autos in die Werkstatt
> zurück rufen musst. Wenn du schlau warst, hast du jede Haftung
> ausgeschlossen im Vertrag...

Nur mal nebenbei gefragt, da es Airbags ja nun doch schon eine ganze 
Weile gibt: wie oft ist das denn bisher weltweit mal vorgekommen?

Oliver

von Cyblord -. (cyblord)


Lesenswert?

Oliver S. schrieb:
> Nur mal nebenbei gefragt, da es Airbags ja nun doch schon eine ganze
> Weile gibt: wie oft ist das denn bisher weltweit mal vorgekommen?

Die sind wohl alle in Rust programmiert ;-)

von Nop (Gast)


Lesenswert?

Oliver S. schrieb:

> Nur mal nebenbei gefragt, da es Airbags ja nun doch schon eine ganze
> Weile gibt: wie oft ist das denn bisher weltweit mal vorgekommen?

Speziell bei Airbags nun nicht, aber das Beispiel des Toyota Camry ist 
ja bekannt, und da gab es Tote. Das lag allerdings nicht an einem 
C-Fehler, sondern an unzureichender Stackanalyse, und zu allem Überfluß 
hat man den Stack auch noch nach unten hin auf die globalen Daten (oder 
den Heap) zuwachsen lassen. Das könnte wohl auch in Rust passieren, weil 
der Rust-Compiler sich auf eine korrekte Umgebung genauso verläßt wie 
ein C-Compiler.

Das jünste Beispiel mit den Boeing-Abstürzen wiederum war auch kein 
C-Fehler, sondern ein Fehler im Systemdesign. Der Maximalausschlag des 
Höhenruders wurde nachträglich deutlich vergrößert, und dann hätte man 
das System nicht mehr mit nur einem Sensor betreiben dürfen. Hat man 
aber, obwohl man sogar physikalisch zwei Sensoren hatte, weil man den 
dann erhöhten Zertifizierungsaufwand einsaparen wollte.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Cyblord -. schrieb:
> Es ging ja darum dass Rust dies anscheinend ohne Overhead automatisch
> prüft.

Naja: es prüft mit einem vergleichbaren Overhead. Wenn der Test statisch 
machbar ist, hast du ihn zur Compilezeit, keine Frage. Lässt er sich nur 
zur Laufzeit ausführen, dann müsstest du ihn für ein sicheres C- (oder 
Assembler-)Programm dort ebenfalls zur Laufzeit durchführen, daher 
sollte der Overhead vergleichbar sein.

von Carsten P. (r2pi)


Lesenswert?

Cyblord -. schrieb:
> Carsten P. schrieb:
>
>> Du prüfst also nicht, ob x > 100 ist?
>
> Es ging ja darum dass Rust dies anscheinend ohne Overhead automatisch
> prüft.
>
>> Achso, es ging um Rust. Jepp, das kriegt
>> Rust hin, zur Übersetzungszeit bereits, weil es den Rückgabewert von
>> receiveUART() prüft und dann feststellt, ob er die Array-Grenze
>> überschreiten kann.
>
> Erstaunlich. Es kann in die Zukunft sehen welcher Wert über den UART
> reinkommt?

Ja, natürlich. Der Index von a ist maximal 99. Wenn receiveUART() ein 
uint8 zurückgibt, ist der größte Wert dort 255, also größer als 99.

Das ist doch kein Hexenwerk...

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
>> Rust ist in diesem Aspekt nicht langsamer als C.
>
> Dann kann Rust in diesem Aspekt auch nicht sicherer sein.
> Laufzeitchecks gibt es nicht umsonst. Kann es nicht geben.

Ja, Ok. Ich habs verstanden. Du willst ganz offensichtlich nur 
provozieren und stellst dich bewusst dumm.
Ich beende das Spiel an dieser Stelle.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> und zu allem Überfluß
> hat man den Stack auch noch nach unten hin auf die globalen Daten (oder
> den Heap) zuwachsen lassen. Das könnte wohl auch in Rust passieren,

Nein, kann es natürlich nicht.
Rust ist memory-safe. Das gilt selbstverständlich auch für den Stack.

Jörg W. schrieb:
> Naja: es prüft mit einem vergleichbaren Overhead. Wenn der Test statisch
> machbar ist, hast du ihn zur Compilezeit, keine Frage.

Wenigstens einer, der es verstanden hat. Ist aber auch gar nicht so 
schwer eigentlich :)

Beitrag #6930470 wurde von einem Moderator gelöscht.
von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Rust ist memory-safe. Das gilt selbstverständlich auch für den Stack.

Echt? Der Compiler weiß beim Übersetzen, daß der Stack auf dem Target zu 
klein ist? Glaube ich nicht.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Echt? Der Compiler weiß beim Übersetzen, daß der Stack auf dem Target zu
> klein ist?

Das hat niemand behauptet.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Das hat niemand behauptet.

Doch, hast Du gerade. Alternativ, was wahrscheinlicher ist, hast Du das 
von mir beschriebene Problem nicht verstanden.

von Carsten P. (r2pi)


Lesenswert?

Nop schrieb:
> Echt? Der Compiler weiß beim Übersetzen, daß der Stack auf dem Target zu
> klein ist? Glaube ich nicht.

Wissen tue ich es auch nicht, aber was hält den Compiler, auch bei 
genügend präzise angegebenen Targets als Cross-Compiler, davon ab, das 
zur Übersetzung zu wissen, wie groß der Stack werden darf? Wir reden 
hier von Embedded, ich jedenfalls, nicht von virtualisierten Maschinen 
auf virtualisierenden Servern.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Doch, hast Du gerade.

Bitte? Du weißt schon, dass man in einem Forum alles nachlesen kann und 
somit beweisen kann, dass ich es nicht behauptet habe?

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:
> Nop schrieb:
>> Doch, hast Du gerade.
>
> Bitte? Du weißt schon, dass man in einem Forum alles nachlesen kann und
> somit beweisen kann, dass ich es nicht behauptet habe?

Hast Du, und zwar hier:

MaWin O. schrieb:
> Nein, kann es natürlich nicht.
> Rust ist memory-safe. Das gilt selbstverständlich auch für den Stack.

Du hast dabei nicht berücksichtigt, daß ein Stacküberlauf gar nicht im 
Fokus des Compilers sein kann, weil der Compiler nichts von der 
Stackdimensionierung weiß. Das wird erst beim Linken klar, und dann 
reden wir über LLVM, nicht mehr von Rust.

Der Rust-Compiler verläßt sich genauso wie ein C-Compiler darauf, daß 
das Environment so funktioniert, wie es das sollte.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Carsten P. schrieb:
> aber was hält den Compiler, auch bei genügend präzise angegebenen
> Targets als Cross-Compiler, davon ab, das zur Übersetzung zu wissen, wie
> groß der Stack werden darf?

Einerseits call trees, die von äußeren Einflüssen (beispielsweise 
Eingabegrößen) abhängen, andererseits natürlich Rekursionen. Bei 
Rekursionen kann er bestenfalls eine worst-case-Annahme treffen (wenn 
beispielsweise durch den Datentyp, der die Rekursion steuert, eine 
maximale Rekursionstiefe ermittelbar ist), aber die kann natürlich 
meilenweit über im praktischen Betrieb auftretenden realen Anforderungen 
dann liegen. Dann ist es zwar sicher, aber u.U. derart überalloziert, 
dass es auf der realen Maschine nicht mehr nutzbar ist, weil sie gar 
nicht so viel Speicher für den Stack bereitstellen kann.

Für eine virtual-memory-Architektur spielt das nicht so'ne große Geige 
(der Stack ist ja dann nur VM, und wenn der real nicht ausgenutzt wird, 
muss er nicht durch realen Speicher abgedeckt werden), aber auf einem 
kleinen Controller kann das ein Problem werden.

Sowas kann auch keine Sprache in sich absichern, wenn man derartige 
Probleme hat. Man kann dann höchstens Monte-Carlo-Simulationen 
durchspielen, die für typische Szenarien ermitteln, wieviel STack 
tatsächlich gebraucht wird. In einem realen System würde mann dann in 
irgendeiner Form eine "Notbremse" einbauen die greift, wenn sich 
herausstellt, dass der allozierte Stack doch mal nicht reicht (geht 
natürlich am einfachsten, wenn die Zielarchitektur eine MMU dafür 
anbietet).

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Der Rust-Compiler verläßt sich genauso wie ein C-Compiler darauf, daß
> das Environment so funktioniert, wie es das sollte.

Nein, das ist halt ganz einfach falsch.
Rust geht in ein Panic (und damit in ein Recovery) bei einem 
Stacküberlauf.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Rust geht in ein Panic (und damit in ein Recovery) bei einem
> Stacküberlauf.

Das tut er unter Linux, weil das Betriebssystem und die Runtime da noch 
mitspielen. Embedded und bare metal wird das so nichts werden. Abgesehen 
davon wäre das auch kaum besser, wenn mitten während der 
Fahrzeugregulierung das Programm einfach mal neu startet.

von Carsten P. (r2pi)


Lesenswert?

Jörg W. schrieb:
> Einerseits call trees, die von äußeren Einflüssen (beispielsweise
> Eingabegrößen) abhängen, andererseits natürlich Rekursionen.

Japp. Korrekt. Anders als andere (einer) hier, behaupte ich auch nicht, 
dass sowas nicht möglich ist. Ich sage nur, dass ein gut geschneiderter 
Compiler sehr viel davon verhindern kann. Natürlich kannst du jede 
Laufzeit und jeden Compiler mit böser Absicht oder (wie du sagtest, 
Eingaben) genügend hilflosen Anwendern (Coder, die deinen Code linken, 
sind auch Anwender) in die Knie zwingen.

Da fehlt aber gerade in der Hardware noch eine Menge Hirnschmalz, gerade 
bei kleinen uCs, also dass sie Threads von sich aus ausknipsen, wenn sie 
gewisse Stack-Grenzen überschreiten.

Außer manchen (einem) behauptet ja aber auch niemand, dass Rust die 
einzige und perfekte Sprache/Laufzeit ist. Rust setzt an typischen 
Fehlerquellen an, wo ein Compiler bereits rein grätschen kann, und das 
ist, finde ich, ein sehr guter Ansatz. Natürlich wäre es süß, wenn auch 
ein AtTiny ne VM Umgebung herstellen könnte, aber dann würde er nicht 30 
Cent, sondern 5 Euro mindestens kosten. So dumm ich das Argument selber 
finde, so sehr zieht es doch einerseits durch den Kostendruck aus 
anderen Regionen dieser Welt ALS AUCH vom Gerede mancher Entwickler, 
dass das alles kein Problem sei.

von Oliver S. (oliverso)


Lesenswert?

Nop schrieb:
> das Beispiel des Toyota Camry ist
> ja bekannt, und da gab es Tote. Das lag allerdings nicht an einem
> C-Fehler, sondern an unzureichender Stackanalyse, und zu allem Überfluß
> hat man den Stack auch noch nach unten hin auf die globalen Daten (oder
> den Heap) zuwachsen lassen.

Hm. Du hast doch dafür sicherlich eine Quelle. Meines Wissens nach ist 
die ganze Sache dort sehr viel komplexer gewesen, und ist bis heute 
nicht abschließend geklärt.

> Das jünste Beispiel mit den Boeing-Abstürzen wiederum war auch kein
> C-Fehler, sondern ein Fehler im Systemdesign.

So war das wohl.

Rust mag ja einige haarsträubende Ecken von C(++) umschiffen, aber die 
Fehler, die in diesen realen Projekten gemacht wurden, hätte das auch 
nicht verhindert.

Oliver

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Das tut er unter Linux, weil das Betriebssystem und die Runtime da noch
> mitspielen. Embedded und bare metal wird das so nichts werden.

Weil du das sagst?
Warum genau soll Rust nicht prüfen können, ob der Stack überläuft?

> Abgesehen
> davon wäre das auch kaum besser, wenn mitten während der
> Fahrzeugregulierung das Programm einfach mal neu startet.

Ja doch. Ein Neustart ist 1000 mal besser, als UB durch 
Memory-Corruption.
Neustarts von Steuergeräten während der Fahrt passieren "ständig" (d.h. 
öfter als du denkst).

von Nop (Gast)


Lesenswert?

Oliver S. schrieb:

> Hm. Du hast doch dafür sicherlich eine Quelle.

Die Google-Stichworte lauten wenig überraschend:
toyota camry stack overflow
Da findest Du jede Menge dazu. Es war jedenfalls eine der Ursachen.

> Rust mag ja einige haarsträubende Ecken von C(++) umschiffen, aber die
> Fehler, die in diesen realen Projekten gemacht wurden, hätte das auch
> nicht verhindert.

Richtig. Das kann man Rust natürlich nicht ankreiden, aber es sind halt 
mal zwei Beispiele mit Toten, wo "wir machen alles in Rust" nichts 
geholfen hätte. Insofern sollte man da auch nicht übermütig werden.

Wenn ich hier dann im Kontext von embedded-Entwicklung lese, Rust habe 
keine potentiellen Stackprobleme (haben auch C-Programme übrigens unter 
Linux nicht - die werden auch beendet), sieht das schon stark nach 
Risiko-Kompensation aus, was wiederum ein Risiko darstellt.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Warum genau soll Rust nicht prüfen können, ob der Stack überläuft?

Weil Rust explizit auf Geschwindigkeit und "kein Runtime-Overhead" 
entwickelt wurde, und bei jedem Dekrementieren des Stackpointers vorher 
einen Runtime-Check zu machen wäre ein erheblicher Runtime-Overhead. Die 
Speichersicherheit bezieht sich auf die Anwendung und nicht darauf, daß 
das Environment außerhalb des Rust-Programms ein Problem hat.

Das, was Du als Beispiel brachtest, wird vom OS bereitgestellt, was das 
Programm dann abbricht. Es geht hier aber um embedded und bare metal, 
nicht um Linuxanwendungen.

> Ja doch. Ein Neustart ist 1000 mal besser

Bei nennenswertem Tempo mit aktiver ASR wäre ein Neustart ebenso fatal.

von MaWin O. (mawin_original)


Lesenswert?

https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=6ba3452d2c1eeb9b3c9c3f3fa236b77a

> thread 'main' has overflowed its stack
> fatal runtime error: stack overflow

Komisch, gell?
Wo Rust das doch angeblich gar nicht erkennen kann?

von Nop (Gast)


Lesenswert?

Ach ja, abgesehen davon weiß der Rust-Compiler gar nicht, wie groß der 
Stack überhaupt ist. Unter Linux ist das Sache des Betriebssystems, und 
bare metal wird das erst beim Linken klar - und dann reden wir über 
LLVM, lange nach dem Rust-Compiler.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Weil Rust explizit auf Geschwindigkeit und "kein Runtime-Overhead"
> entwickelt wurde, und bei jedem Dekrementieren des Stackpointers vorher
> einen Runtime-Check zu machen wäre ein erheblicher Runtime-Overhead.

Nein, wäre es nicht.
Das wäre eine einzige Abfrage pro Funktion. Im Mittel deutlich weniger.

> Die Speichersicherheit bezieht sich auf die Anwendung

Ja eben. Die Anwendung macht die Allokation.
Könnte die Anwendung durch Speicherallokation UB hervorrufen, wäre das 
"unsound". Unsoundness und UB gibt es in Rust nicht.

> Das, was Du als Beispiel brachtest, wird vom OS bereitgestellt,

Nein.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Ja eben. Die Anwendung macht die Allokation.

Denk mal drüber nach, wieso das überhaupt ein Runtime-Fehler ist und 
nicht ein Compiletime-Fehler, obwohl die Stack-Allokation in Deinem 
Beispiel ja offensichtlich statisch ist.

Das kommt daher, daß man über Guardpages geht, was auf Kernel-Level ein 
Segfault ist - blöd halt, wenn man gar keine Pages (und auch keinen 
Kernel) hat, weil wir hier über embedded-Controller reden.

von Nop (Gast)


Lesenswert?

Aus demselben Grund wird übrigens ein C-Programm mit Stackoverflow unter 
Linux ebenfalls problemlos beendet.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Denk mal drüber nach, wieso das überhaupt ein Runtime-Fehler ist und
> nicht ein Compiletime-Fehler, obwohl die Stack-Allokation in Deinem
> Beispiel ja offensichtlich statisch ist.

Ich habe nie gesagt, dass das ein Compiletime-Fehler ist.

> Das kommt daher, daß man über Guardpages geht, was auf Kernel-Level ein
> Segfault ist - blöd halt, wenn man gar keine Pages (und auch keinen
> Kernel) hat,

Es ist völlig unerheblich, ob ein Kernel existiert oder nicht.
Die x86/x64-Implementiertung nutzt eine Guardpage. Das ist ein 
MMU-Feature.
Das heißt aber nicht, dass man zwingend einen Kernel braucht.
Und es heißt auch nicht, dass man eine MMU braucht.
Man kann auch eine Memory-Protection-Unit verwenden. Oder wenn man die 
nicht hat, kann man den Stack in einen anderen ungültigen Bereich 
wachsen lassen.

Sicher wirds auch irgendwelche Architekturen geben, die gar keine Traps 
bereitstellen für sowas. Aber selbst dort kann der Compiler 
selbstverständlich eine architekturspezifische Abrage machen.

Macht Rust das derzeit bei allen Architekturen? Nein, denn...

> weil wir hier über embedded-Controller reden.

Wir reden hier hauptsächlich über Rust.
Dass Rust derzeit noch nicht "fertig" ist für alle Embeddedsysteme 
(kleiner als Raspberry Pi), schrieb ich ja bereits.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:

> Dass Rust derzeit noch nicht "fertig" ist für alle Embeddedsysteme
> (kleiner als Raspberry Pi), schrieb ich ja bereits.

Jaja, aber wir schwadronieren schon mal vorsorglich vom Ersetzen von C 
durch Rust.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Macht Rust das derzeit bei allen Architekturen? Nein, denn...

... es ist kein Teil des Rust-Sprachstandards. Oh wait - Rust HAT ja gar 
keinen Sprach-Standard, sondern ist das, was auch immer der einzige 
Rust-Compiler gerade tut. Wodurch man übrigens nichtmal einen 
Compiler-Bug von einem Feature unterscheiden kann, denn gegen welche 
Spec sollte man das auch prüfen.

> Dass Rust derzeit noch nicht "fertig" ist für alle Embeddedsysteme
> (kleiner als Raspberry Pi), schrieb ich ja bereits.

Mit anderen Worten: Dir war klar, daß Dein Beispiel embedded gar nicht 
funktionieren würde, aber Du hast es trotzdem mal versucht - ich hätte 
es ja schlucken können, ne?

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Dir war klar, daß Dein Beispiel embedded gar nicht
> funktionieren würde, aber Du hast es trotzdem mal versucht

Ach komm...
Es wurde behauptet, dass Rust sowas grundsätzlich nicht erkennen kann.
Und das ist halt falsch.

Cyblord -. schrieb:
> Jaja, aber wir schwadronieren schon mal vorsorglich vom Ersetzen von C
> durch Rust.

Wir? Du?
Ich jedenfalls nicht. Kannst du ja gerne nachlesen.

Ich habe schon mehrfach betont, dass es mir egal ist, was ihr nutzt.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Es wurde behauptet, dass Rust sowas grundsätzlich nicht erkennen kann.
> Und das ist halt falsch.

Mit derselben Logik wäre das bei C auch kein Problem gewesen: unter 
Linux wird auch ein C-Programm bei einem Stackoverflow abgebrochen. 
Dummerweise war es aber kein Linuxsystem.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Mit derselben Logik wäre das bei C auch kein Problem gewesen

Richtig. Ich habe nicht behauptet, dass C das nicht auch kann.
Ihr wart aber diejenigen, die behauptet haben, Rust könne das nicht.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Ihr wart aber diejenigen, die behauptet haben, Rust könne das nicht.

Was Du ja dann ja auch eingestanden hast, nachdem Du erstmal den 
Unterschied zwischen bare metal und einem Linuxrechner verstanden hast.

Im Übrigen könnte man sich selbstverständlich auch einen hypothetischen 
C-Compiler denken, der vor jedem SP-Dekrement erstmal einen 
Runtime-Check macht. Hätte, hätte, Fahrradkette.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Was Du ja dann ja auch eingestanden hast

Oh bitte. Höre einfach damit auf mir Dinge in den Mund zu legen, die ich 
nie gesagt habe. Ok?
Man kann das hier alles nachlesen. Ok?
Gut.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Oh bitte. Höre einfach damit auf mir Dinge in den Mund zu legen, die ich
> nie gesagt habe. Ok?

Dann hör einfach auf, halbgaren Quatsch zu erzählen und mit unsinnigen 
Beispielen zu "belegen", die nur darauf bauen, daß andere nicht genauer 
hinsehen.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Dann hör einfach auf, halbgaren Quatsch zu erzählen

Ja, genau. Höre du bitte auf damit. Ok? Die Diskussion ging nicht von 
mir aus. Ich habe nicht die Behauptung mit dem unbehandelbaren 
Stackoverflow (a.k.a. halbgarer Quatsch) ins Spiel gebracht.

von Oliver S. (oliverso)


Lesenswert?

Nop schrieb:
> Die Google-Stichworte lauten wenig überraschend:
> toyota camry stack overflow
> Da findest Du jede Menge dazu.

Eben nicht, daher frage ich ja. Ein Stack Overflow war eine der 
denkbaren Ursachen, neben einer Zillion anderen, die aus der Komplexität 
des Systems resultieren. Immerhin war das ein zweikanaliges 
Sicherheitssystem.

Da das Verfahren aber abgeschlossen ist, wird’s dazu auch keine neuen 
Erkenntnisse geben.

Oliver

von Nop (Gast)


Lesenswert?

Oliver S. schrieb:

> Eben nicht

Du mußt die Links natürlich auch schon anklicken. ;-) Etwa diesen hier:
https://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-the-foot-with-stack-overflow/

von Olaf (Gast)


Lesenswert?

> Olaf schrieb:
> > Pearl

> Meinst du Perl?

Nein, ich meinte schon Pearl. Sonst haette es wohl kaum als Embedded 
Beispiel aus der Anfangszeit von C getaugt.

Olaf

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Nop schrieb:
> Im Übrigen könnte man sich selbstverständlich auch einen hypothetischen
> C-Compiler denken, der vor jedem SP-Dekrement erstmal einen
> Runtime-Check macht.

Geht eigentlich nur, wenn die CPU-Architektur das hergibt (also 
letztlich durch eine MMU). Wenn man das mit Maschinenbefehlen manuell 
bewerkstelligen will, wird es nicht nur schnarchlangsam, sondern man hat 
gute Chancen, dass man schon mal irgendein Register auf den Stack pushen 
muss, um überhaupt erstmal Platz für den Test zu haben …

Dann ist es aber ganz unabhängig von der Sprache implementierbar (auch 
auf Controllern mit MMU, aber das sind halt nicht mehr die 
allerkleinsten).

Da kommt einem aber sofort wieder "Steinbach's guideline of systems 
programming" in den Sinn … die klingt zwar hart, aber wenn man auf einem 
Controller gar keinen sinnvollen Ausweg hat, weil man nur noch zwischen 
Pest (undefined behaviour) und Cholera (spontaneous reboot) wählen kann, 
dann hat man im konkreten Fall eh ein Problem.

von Nop (Gast)


Lesenswert?

Jörg W. schrieb:
> Wenn man das mit Maschinenbefehlen manuell
> bewerkstelligen will, wird es nicht nur schnarchlangsam

Ein Laden, ein Vergleich und ein bedingter Sprung pro Funktion, sofern 
der Stackframe am Funktionsanfang komplett aufgebaut wird. Der Overhead 
wäre schon deutlich.

> sondern man hat
> gute Chancen, dass man schon mal irgendein Register auf den Stack pushen
> muss, um überhaupt erstmal Platz für den Test zu haben …

Das wäre leicht abzufrühstücken, indem nicht getestet wird, ob der Stack 
überschritten sein wird, sondern eine bestimmte minimale Reserve bleibt. 
Die könnte man dann für register spill im Funktions-Prolog des nächsten 
Levels nutzen.

> aber wenn man auf einem
> Controller gar keinen sinnvollen Ausweg hat, weil man nur noch zwischen
> Pest (undefined behaviour) und Cholera (spontaneous reboot) wählen kann,
> dann hat man im konkreten Fall eh ein Problem.

Das kann man aber mit statischer Stackanalyse in den Griff kriegen. Der 
Calltree ist größenteils bekannt, dann noch Interrupts in 
worst-case-Schachtelung, und ein paar Calls, die über Funktionszeiger 
gehen können. Bei den Projektgrößen, die man auf MMU-losen Systemen so 
hat, ist das kein Problem.

Bei uns ist das in Prozeß-Checklisten als vorgeschriebener Teil jedes 
Software-Releases durchzuführen. Ohne Stackanalyse gibt's kein Release, 
auch nicht für Software ohne Sicherheitsrelevanz. Im Ernstfall wäre es 
nämlich langwierig und damit teuer, sporadischen Problemen im Feld 
nachzuspüren, und sowas würde mit dem Zeitplan laufender Projekte 
kollidieren.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Das wäre leicht abzufrühstücken
> Das kann man aber mit statischer Stackanalyse in den Griff kriegen.

Das ist ja erstaunlich, wie schnell du von

- das geht gar nicht!
- Das kann der Compiler prinzipiell nicht, weil Linker und überhaupt ist 
das gar nicht bekannt wie groß der Stack ist!
- Rust kann das überhaupt nicht!
- Du unterstellst mir bewusste Irreführung.

dich wandelst zu:
> Das wäre leicht abzufrühstücken
> Das kann man aber mit statischer Stackanalyse in den Griff kriegen.

von Oliver S. (oliverso)


Lesenswert?

Nop schrieb:
> Oliver S. schrieb:
>
>> Eben nicht
>
> Du mußt die Links natürlich auch schon anklicken. ;-) Etwa diesen hier:
> 
https://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-the-foot-with-stack-overflow/

Habe ich. Und sogar gelesen. Die darin zitierte Untersuchung und auch 
den Foliensatz kannte ich schon vorher.

Da steht drin, daß ein Stackoverflow eine wahrscheinliche Ursache 
gewesen sein könnte, und als Bewies wird angeführt, daß die Misra nicht 
eingehalten haben. Bewiesen ist der Fehler nicht, und schon gar keine 
schuldige Codestelle identifiziert. Es steht auch drin, daß auch 
Hardwarefehler, kippende Bits, und ein Haufen anderer schöner Dinge die 
Ursache hätten sein können. Andere Untersuchungen zeigen, daß auch deren 
real-time-Annahmen auf die Kante genäht waren, usw.

Toyota sagt, daß deren fail safe System all diese Fehler abgefangen 
hätte, kann das aber auch nicht beweisen.

Fest steht mir, daß Rust an all dem nichts geändert hätte. Die Probleme 
liegen alle oberhalb der von Rust eingezogenen Sicherheitsebene.

Oliver

von MaWin O. (mawin_original)


Lesenswert?

Oliver S. schrieb:
> Fest steht mir, daß Rust an all dem nichts geändert hätte. Die Probleme
> liegen alle oberhalb der von Rust eingezogenen Sicherheitsebene.

Ja, das ist ziemlich wahrscheinlich.
Es geht bei Rust ja erst einmal auch nicht um Safety, sondern um 
Security.
Das sind zwei grundverschiedene Dinge, auch wenn die Ursachen für 
Safety-Fehlfunktionen denen von Security-Fehlfunktionen ähneln können. 
Im Systemdesign unterscheiden die Gegenmaßnahmen sich aber erheblich.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> - Das kann der Compiler prinzipiell nicht, weil Linker und überhaupt ist
> das gar nicht bekannt wie groß der Stack ist!

Es war im Kontext von "Speichersicherheit ohne Runtime-Overhead". Du 
wirst Dich erinnern, daß dies eines der zentralen Rust-Features ist. Das 
ist auch der Grund, wieso Rust unter Linux auf Guard-Pages setzt, die 
keinen Overhead verursachen, solange kein Stackoverflow passiert.

Mit Runtime-Overhead kann man das natürlich in jeden Compiler einbauen, 
aber das ist dann kein Rust-Feature, sondern jede C-Implementation 
könnte das auch tun. Insofern ist es auch da korrekt, wenn man sagt, daß 
Rust als Sprache da gar nichts garantiert, ebensowenig wie C.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> "Speichersicherheit ohne Runtime-Overhead". Du
> wirst Dich erinnern, daß dies eines der zentralen Rust-Features ist.

Niemand hat behauptet, dass Speichersicherheit grundsätzlich ohne 
Runtime-Overhead in Rust realisiert ist. Und schon gar nicht, dass dies 
ein zentrales Rust-Feature ist.
Bitte bleibe bei der Wahrheit. Man kann hier alles nachlesen, was du im 
Nachhinein falsch verdrehst.

Speichersicherheit mit wenig Runtime-Overhead, im Mittel vergleichbar 
mit dem Overhead, den man in korrekten C-Programmen auch hätte. Das ist 
eines der zentralen Rust-Features. Und nichts anderes wurde hier gesagt.

von Nop (Gast)


Lesenswert?

Oliver S. schrieb:
> und als Bewies wird angeführt, daß die Misra nicht
> eingehalten haben.

Das war schon ein bißchen mehr als nur MISRA-Mißachtung.

> Bewiesen ist der Fehler nicht

Derartige Fehler kann man auch schwerlich beweisen, weil es sehr 
seltene, sporadische Fehler sind. Sonst wäre das bei Testfahrten schon 
aufgefallen.

> und schon gar keine schuldige Codestelle identifiziert.

Bei Stackoverflow gibt es in dem Sinne auch keine schuldige Codestelle, 
wenn man die Stackdimensionierung selber nicht als solche durchgehen 
läßt, weil es z.B. bei Interrupts sehr davon abhängt, in welcher 
zeitlichen Abfolge sie mit Blick auf ihre Priorisierung anfallen und in 
welcher Tiefe des ISR-Calltrees der nächste Interrupt eintrifft.

Das ist übrigens auch der Grund, wieso "den Stack vorher mit einem 
Testmuster füllen, das System laufen lassen und gucken, bis wo der Stack 
genutzt wurde" keine brauchbare Verifikationsmethode darstellt. Das 
ergibt nämlich nur eine untere Schranke für den Stackbedarf. Damit kann 
man lediglich die ohnehin fällige worst-case-Analyse einem 
Plausibilitäts-Check unterziehen.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Niemand hat behauptet, dass Speichersicherheit grundsätzlich ohne
> Runtime-Overhead in Rust realisiert ist.

Was bare metal und Stackoverflow angeht, ist sie sogar überhaupt nicht 
implementiert, wie Du nach diversen Versuchen des Rauswindens dann 
eingestanden hast. Sie ist also ganz offensichtlich nicht Teil der 
Sprache selber.

> Speichersicherheit mit wenig Runtime-Overhead, im Mittel vergleichbar
> mit dem Overhead, den man in korrekten C-Programmen auch hätte.

Ein korrektes C-Programm braucht keinerlei Stacküberprüfung zu machen, 
weil eine dem C-Standard entsprechende Umgebung compilerseitig 
vorausgesetzt wird. Also genauso wie bei Rust und bare metal.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> nach diversen Versuchen des Rauswindens dann eingestanden hast.

Das kannst du mehrfach behaupten, aber es stimmt halt nicht.
Du kannst hier im Thread nachlesen, wie ich schon vor einiger Zeit 
gesagt habe, dass Rust derzeit noch nicht auf kleinen Embedded-Systemen 
stabil ist. Das gilt nach wie vor.
Und das war lange bevor du deine Nebelkerzen zum Stackoverflow gezündet 
hast.

> Ein korrektes C-Programm braucht keinerlei Stacküberprüfung zu machen,
> weil eine dem C-Standard entsprechende Umgebung compilerseitig
> vorausgesetzt wird. Also genauso wie bei Rust und bare metal.

Wo ist dann dein Problem?

Es wurde hier behauptet, dass ein Rustprogramm grundsätzlich keine 
Stackprüfung machen könne. Ich habe bewiesen, dass es doch eine Prüfung 
macht. Du hast halt Unrecht gehabt. Passiert jedem mal. Nicht schlimm.

Ich habe nichts über C gesagt. Ich habe nicht gesagt, was besser und was 
schlechter ist.

Beitrag #6930724 wurde von einem Moderator gelöscht.
von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb im Beitrag #6930724:
> Leider schon wieder gelogen.

Warum greifst du mich persönlich an?

> Der resultierende Segfault im Kernel ist ohne OS-Unterstützung so nicht drin.

Selbstverständlich ist das ohne Kernelunterstützung implementierbar.
Glaubst du der Kernel wäre etwas magisches, was irgendwas aus dem Hut 
zaubert?

Es ist sogar ohne MMU-Unterstützung implementierbar, wenn die Hardware 
minimalste Protection-Mechanismen hat.
Und es ist auch ohne MPU implementierbar, wenn man den Stack so 
platzieren kann, dass beim Überlauf ein Zugriff auf einen ungültigen 
Bereich stattfindet und dieser ein Trap auslöst.
Und es ist auch ohne Trap lösbar, indem man alle Stackveränderungen ganz 
einfach prüft.

Beitrag #6930740 wurde von einem Moderator gelöscht.
Beitrag #6930742 wurde von einem Moderator gelöscht.
Beitrag #6930744 wurde von einem Moderator gelöscht.
Beitrag #6930751 wurde von einem Moderator gelöscht.
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Nop schrieb:
> Der Calltree ist größenteils bekannt, dann noch Interrupts in
> worst-case-Schachtelung, und ein paar Calls, die über Funktionszeiger
> gehen können.

Klappt halt so nur, solange die Stacknutzung nicht zu stark von den 
(nicht exakt vorhersagbaren) Eingabedaten abhängt.

Klar, alles was statisch machbar ist, ist eh immer am einfachsten.

Im Zweifelsfalle, wenn man Sicherheit braucht, darf dann aber eben auch 
die Hardware weder von der Geschwindigkeit noch vom Speicherausbau „auf 
Kante genäht“ sein.

Aber ja, mit Rust hat das alles jetzt nichts mehr zu tun. :-)

Kann schon sein, dass Rust auch in diesem Bereich künftig noch an Boden 
gewinnt, aber im Moment sehe ich das noch nicht um die Ecke lugen. Ein 
Auftraggeber, für den ich letztens gearbeitet habe (mit durchaus sehr 
experimentierfreudigen Entwicklern), hatte es für eine Embedded-Lösung 
auf deutlich höherem Niveau (embedded Linux auf größerer STM-Plattform) 
initial in Erwägung gezogen, aber dann doch wieder verworfen und 
herkömmlich in C++ gearbeitet. Bei denen ist auch funktionale Sicherheit 
ein Thema, und der ganze Krams muss dann durch eine Zertifizierung 
durch.

von Nop (Gast)


Lesenswert?

Jörg W. schrieb:

> Klappt halt so nur, solange die Stacknutzung nicht zu stark von den
> (nicht exakt vorhersagbaren) Eingabedaten abhängt.

Der Trick ist, daß man ja nicht die exakte Nutzung braucht, sondern nur 
eine verläßliche obere Schranke. Daher kann man die Eingabedaten mehr 
oder weniger ignorieren und geht einfach den Calltree durch, auch wenn 
der u.U. so in derser Kombo nicht unbedingt passieren kann.

> Im Zweifelsfalle, wenn man Sicherheit braucht, darf dann aber eben auch
> die Hardware weder von der Geschwindigkeit noch vom Speicherausbau „auf
> Kante genäht“ sein.

Klar, also beim Stackverbrauch wird ja auch immer noch ein wenig Reserve 
gefordert.

> Aber ja, mit Rust hat das alles jetzt nichts mehr zu tun. :-)

Nur noch am Rande. ;-)

> Bei denen ist auch funktionale Sicherheit
> ein Thema, und der ganze Krams muss dann durch eine Zertifizierung
> durch.

Da wird man dann noch so einiges an Lösungen brauchen, mindestens was 
für statement coverage.

Mehr Sorgenfelder sehe ich darin, daß es nur einen einzigen Compiler 
gibt, der zugleich auch noch der Sprachstandard ist, so daß man nichtmal 
einen Compilerbug von einem Sprachfeature unterscheiden kann. 
Kommerzieller Support ist auch nicht drin. Ein zertifizierter Compiler 
ist in weiter Ferne, und ohne ISO-Standard sehe ich den auch nicht.

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

Bzgl. gelöschte Beiträge: Bitte freundlich bleiben, andere der Lüge zu 
bezichtigen ist kein Teil einer sachlichen Diskussion.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Nop schrieb:
> ohne ISO-Standard sehe ich den auch nicht

Ein ISO-Standard wiederum ist ein ganz schön großer Haufen an Arbeit, 
die keinerlei "Hack value" hat. Einfach nur Arbeit, administrativ, 
editorisch.

Aber man könnte ihn – anders als bei Pascal – ja an den realen Features 
des existierenden Compilers fest machen. :)

von Jemand (Gast)


Lesenswert?

Nop schrieb:
> Ein zertifizierter Compiler
> ist in weiter Ferne

Sind eigentlich zertifizierte Compiler tatsächlich messbar besser? Oder 
nutzt man die nur der Zertifizierung und dem dazugehörigen Haftungszeug 
wegen?

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Huch, hier war ja richtig was los die Tage...

Nop schrieb:
> Mehr Sorgenfelder sehe ich darin, daß es nur einen einzigen Compiler
> gibt, der zugleich auch noch der Sprachstandard ist, so daß man nichtmal
> einen Compilerbug von einem Sprachfeature unterscheiden kann.
> Kommerzieller Support ist auch nicht drin. Ein zertifizierter Compiler
> ist in weiter Ferne, und ohne ISO-Standard sehe ich den auch nicht.

Ja, und dagegen hilft auch das gebetsmuehlenhafte Vortragen von "Nein, 
man muss ja kein Cargo nehmen..." auch von allen hier auftretenden 
MaWins nicht wirklich.

Es aendern sich die Compilerversionen noch schneller als gute Entwicker 
ihre Unterhosen und Socken wechseln - ich glaub' bei sowas sollte auch 
der Diplom-Informatiker mit Fachrichtung Projektkasper doch mal kurz ins 
Gruebeln kommen, wie er dann, wenn er sowas aus Sicherheitsgruenden 
einsetzt, Probleme seinen Scheffs verkaufen will...

Gruss
WK

von MaWin (Gast)


Lesenswert?

Dergute W. schrieb:
> Es aendern sich die Compilerversionen noch schneller

Und warum ist das schlecht?

Ist gcc auch schlecht, weil es relativ oft Releases macht?
https://gcc.gnu.org/releases.html

Wenn du bei einem alten Compiler bleiben willst, dann bleibe halt bei 
einem alten Compiler. Warum auch nicht, wenn er deinen Code übersetzen 
kann? Niemand hat etwas dagegen.

> Ja, und dagegen hilft auch das gebetsmuehlenhafte Vortragen von "Nein,
> man muss ja kein Cargo nehmen..."

Was hat jetzt Cargo genau mit Zertifizierung und ISO-Standard zu tun. 
Würde mich sehr interessieren, wenn du das einmal genauer erklärst.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Dergute W. schrieb:
> Es aendern sich die Compilerversionen noch schneller als gute Entwicker
> ihre Unterhosen und Socken wechseln

Das würde sich übrigens ganz schnell geben, wenn man ein 
Standardisierungsgremium dafür aufbaut. Nur mal so, für den nächstes 
Jahr zu veröffentlichen C-Standard (C23) war Annahmeschluss für die 
letzten Papers, die neue Features einbringen können, im Oktober 2021. Im 
Laufe dieses Jahrs werden diese noch zu Ende gefeilt, und ab Sommer 2022 
muss dann der eigentliche Formalismus für die Standardisierungsgremien 
(ISO, IEC, INCITS) in die Wege geleitet werden, damit der Standard 
nächstes Jahr fertig ist.

Dabei ist die WG14 noch insgesamt recht wenig bürokratisch: bei den 
normalen Sitzungen gibt es keine formalen Abstimmungen (ballot), sondern 
nur Meinungsumfragen (straw polls), bei denen die Mehrheit der 
Anwesenden (also auch Gäste) entscheidet, da die jeweils Anwesenden als 
Expertengremium gehandhabt werden. Ergebnisse werden natürlich nur dann 
angenommen, wenn diese Umfragen eine hinreichend klare Linie ergeben, 
ansonsten muss der Antrag ggf. umformuliert und neu gestellt werden.

von MaWin (Gast)


Lesenswert?

Jemand schrieb:
> Sind eigentlich zertifizierte Compiler tatsächlich messbar besser?

Besser, im Sinne von technisch weniger Bugs, ist ja gar nicht das Ziel 
einer Zertifizierung. So etwas enorm komplexes in einem 
Zertifizierungs-Regelwerk abzubilden, sodass keine Bugs mehr drin sein 
können, ist natürlich nicht möglich.
Es geht vielmehr darum, dass der Verkauf das Zertifikat-Label auf das 
Produkt drucken darf und die QM-Abteilung ruhiggestellt wird.
Durch einen zertifizierten Compiler wurde noch nie auch eine einzige 
Fehlfunktion verhindert. Ganz im Gegensatz zum Testen und Bugfixen (des 
Compilers). Das verhindert Bugs. Leider verhindert oft genug gerade die 
Zertifizierung das Bugfixen des Compilers, weil dann müsste er ja 
neuzertifiziert werden. Was dann oft genug in Workarounds in Produktcode 
ausufert, um Compilerbugs zu umschiffen. Das ist dann "billiger".

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Nur mal so, für den nächstes
> Jahr zu veröffentlichen C-Standard (C23) war Annahmeschluss für die
> letzten Papers, die neue Features einbringen können,

Das ist nur nötig, weil C kaum Mechanismen und Regelwerke hat, Features 
vollständig rückwärtskompatibel einzubauen. Im Gegensatz zu Rust. Links 
dazu habe ich bereits gepostet.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

MaWin schrieb:
> Das ist nur nötig

Sorry, aber du erzählst gerade Unsinn. Das hat mit C absolut nichts zu 
tun, sondern mit der Wirkungsweise von Standardisierungsgremien.

(Außerdem beweist deine Aussage über Nicht-Rückwärtskompatibilität von C 
höchstens, dass du diese Sprache nicht einmal kannst, geschweige denn 
ihre Standards. Aber der Thread hier ist natürlich nicht für die 
Diskussion über C da.)

: Bearbeitet durch Moderator
von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Das hat mit C absolut nichts zu
> tun, sondern mit der Wirkungsweise von Standardisierungsgremien.

Natürlich. Der C-Standard hat mit C absolut gar nichts zu tun. "Es gibt 
nichts zu sehen hier! Gehen Sie weiter!"

> dass du diese Sprache nicht einmal kannst

Ich muss mich hier nicht rechtfertigen.

Aber vielleicht du? Wie gut kennst du Rust?

Ja, Rust hat keine formelle Standardisierung. Das bestreitet niemand.
Aber Rust hat sehrwohl wirkungsvolle Mechanismen und Features 
vollständig rückwärtskompatibel zu diskutieren und zu stabilisieren.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Außerdem beweist deine Aussage über Nicht-Rückwärtskompatibilität von C

Außerdem habe ich das nie gesagt. Lies meine Posts, bitte.

von Nop (Gast)


Lesenswert?

MaWin schrieb:

> Es geht vielmehr darum, dass der Verkauf das Zertifikat-Label auf das
> Produkt drucken darf und die QM-Abteilung ruhiggestellt wird.

Dieselbe Argumentation kann man auch bei der zertifizierten 
Produktsoftware selber anbringen. Als Schlußfolgerung bleiben dann z.B. 
Flugzeuge, die nach Agil-Yolo entwickelt wurden. Wird bestimmt ein 
Verkaufs-Hit.

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> Als Schlußfolgerung bleiben dann z.B. Flugzeuge,

Das ist korrekt.

Auch in Flugzeugen werden Bugs ausschließlich durch Tests und in 
Design-Reviews/Prozessen gefunden und gefixt. Niemals aber durch eine 
Zertifizierung des Compilers.

Standardisierte Entwicklungsprozesse sind es, as Safety schafft. Nicht 
Zertifizierung von Entwicklungstools.

von Nop (Gast)


Lesenswert?

MaWin schrieb:

> Standardisierte Entwicklungsprozesse sind es, as Safety schafft. Nicht
> Zertifizierung von Entwicklungstools.

Dann darfst Du bei den höheren Anforderungsleveln als Hersteller gerne 
selber beweisen, daß der Maschinencode Deinem Sourcecode entspricht. 
Viel Spaß dabei, diese Kosten zu stemmen, und das für jedes Projekt und 
jedes Update erneut. Mit Testen alleine kommst Du da nämlich nicht 
durch.

von Nop (Gast)


Lesenswert?

... überdies ist der Widerspruch offensichtlich: bei Produkten helfen 
standardisierte Entwicklungsprozesse, die überhaupt die Basis für die 
Produkt-Zertifizierung sind, der Produktqualität - aber für Compiler 
gilt das natürlich nicht. Ja nee, ist klar.

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> überhaupt die Basis für die
> Produkt-Zertifizierung sind, der Produktqualität - aber für Compiler
> gilt das natürlich nicht.

Eine Produktzertifizierung hilft der Produktqualität genau so, wie eine 
Compilerzertifizierung der Compilerqualität hilft.
Nämlich gar nicht.
Solle klar sein.

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> Dann darfst Du bei den höheren Anforderungsleveln als Hersteller gerne
> selber beweisen, daß der Maschinencode Deinem Sourcecode entspricht.

Wie hilft mir die Zertifizierung dabei? Also technisch jetzt. Nicht 
rechtlich, durch das Verschieben der Verantwortung.

von Nop (Gast)


Lesenswert?

MaWin schrieb:

> Eine Produktzertifizierung hilft der Produktqualität genau so, wie eine
> Compilerzertifizierung der Compilerqualität hilft.
> Nämlich gar nicht.

Aber sicher doch. Deswegen werden Flugzeuge ja zertifiziert. Weil's 
nichts bringt. Daß die Luftfahrt massiv sicherer geworden ist, ist halt 
Zufall. Jedenfalls in Deinem Paralleluniversum.

Kleiner Denkanstoß: hätte man bei der 737-Max die Prozesse tatsächlich 
befolgt, wären die Flieger nicht abgestürzt. Hätte die FAA ihren Job 
gemacht und nicht effektiv Boeing sich selbst beliebige Zertifikate 
ausstellen lassen, dann wären die Prozesse auch befolgt worden.

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> Kleiner Denkanstoß: hätte man bei der 737-Max die Prozesse tatsächlich
> befolgt, wären die Flieger nicht abgestürzt.

Ich habe bereits gesagt, dass Entwicklungsprozesse absolut und 
unbestritten zur Qualität beitragen (bzw. dessen Grundlage ist).
Im Gegensatz zu Compilerzertifizierungen. Die helfen nur den 
Zertifizierungsunternehmen.

Aber du wirst mir sicher wieder die Worte im Munde herumdrehen. Es ist 
alles nachlesbar und dokumentiert hier im Forum.

von Nop (Gast)


Lesenswert?

MaWin schrieb:

> Ich habe bereits gesagt, dass Entwicklungsprozesse absolut und
> unbestritten zur Qualität beitragen (bzw. dessen Grundlage ist).

Was Du irgendwie nicht verstehst: Du bekommst keine Zertifizierung ohne 
den Nachweis entsprechender Entwicklungsprozesse. Das ist der Zweck 
einer Zertifizierung. Dementsprechend wirkt das bei Compilern ganz 
genauso wie bei anderen Produkten auch.

In Deinem Paralleluniversum murkst man sich irgendeinen Mist zurecht, 
geht damit zu einem Zertifizierungsunternehmen, bekommt irgendeinen 
Wisch und ist zertifiziert. Kein Wunder, daß Du den Sinn nicht 
begreifst.

von Carsten P. (r2pi)


Lesenswert?

MaWin schrieb:
> Es geht vielmehr darum, dass der Verkauf das Zertifikat-Label auf das
> Produkt drucken darf und die QM-Abteilung ruhiggestellt wird.

Also, MaWin mit oder ohne O, ich habe bisher einiges Nachdenkenswertes 
von dir gelesen, auch ein paar kluge Einwände, aber das ist jetzt echt 
mal kompletter Schwachsinn.

Das, was du hier gerade schwafelst, ist, als wären Schuhgrößen, weil sie 
genormt und innerhalb der EU durch Standards diese Normen 
vereinheitlicht wurden, Unsinn. Also, du sagst, Normen, Zertifizierungen 
dieser Normen sind egal. Das würde z.B. bedeuten, dass du heute in 
München wohnst z.B., dort in einem Laden Schuhe in der Größe 42 kaufen 
kannst, im Laden nebenan knapp noch, irgendwas zwischen 41 und 43, dann 
ziehst du um nach Hamburg, dort heißen die Schuhgrößen Alpha, Beta, 
Gamma und Omikron, und aufgrund der Geschichte mit der Hanse sind die 
Tragweiten mit kyrillischen Buchstaben ausgezeichnet.

Selbstverständlich gibt es in Hamburg Normen für Sohlen, die aber nur im 
Stadtgebiet von Hamburg und in einigen, aber nicht allen anderen 
Hansestädten gelten, was die Sicherheit angeht, falls sich die Sohle 
löst und du dir auf dem nicht weiter genormten Kopfsteinpflaster das 
Kinn brichst.

Wenn du die Idee der Normen grundsätzlich ablehnst, ist das deine Sache. 
Wenn du aber die Idee der Zertifizierung entlang dieser Normen ablehnst, 
möchte ich nichtmal auf der Rückbank eines Taxis neben dir sitzen.

von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
>
> Also, du sagst, Normen, [...] dieser Normen sind egal.
>
> Wenn du die Idee der Normen grundsätzlich ablehnst

Wo habe ich das gesagt? Bitte zitieren.

> Wenn du aber die Idee der Zertifizierung [...] ablehnst

Ich sprach ausschließlich von der Zertifizierung von Compiler-Tools. 
Denn ebenjene bringen keinen Qualitätsgewinn. Die Compiler sind 
bereits sehr sehr gut. Compilerfehler treten praktisch nicht auf. Und 
das ist nicht der Verdienst der Zertifizierungen, sondern von Tests. 
Zertifizierungen im Compilerbereich bringen nur Nachteile, indem sie 
einen an ebenjene zertifizierte Compilerversion ketten. Auch wenn diese 
Version Bugs enthält.

Von nichts anderem sprach ich. Es ging auch nicht um 
Produktzertifizierungen. Es ging auch nicht um genormte Prozesse und 
Produktnormen. Und auch nicht um irgendetwas beliebiges anderes. Das 
entspringt alles deiner Fantasie.

Bitte bei der Wahrheit bleiben. Es ist alles hier nachlesbar, was ich 
geschrieben habe. Es bringt überhaupt nichts, mir etwas anzudichten, was 
ich nie geschrieben habe.
Danke.

von MaWin (Gast)


Lesenswert?

Und außerdem hat das überhaupt nichts mehr mit Rust zu tun.
Wenn du den Rustcompiler zertifizieren willst, kannst du das gerne tun. 
Niemand hindert dich daran.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

MaWin schrieb:
> Wenn du den Rustcompiler zertifizieren willst, kannst du das gerne tun.

Gegen was willst du den denn zertifizieren, wenn es keinen Standard 
gibt?

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Gegen was willst du den denn zertifizieren, wenn es keinen Standard
> gibt?

Das bleibt dir überlassen. Vielleicht gegen deinen Wocheneinkaufszettel?
An der Compilerqualität ändert es jedenfalls nichts. Egal, gegen was 
zertifiziert wird.

von Gerhard O. (gerhard_)


Lesenswert?

Vielleicht muß man nur geduldig sein. Gut Ding braucht Weil. War bei 
anderen Sprachen nicht anders.

Ich habe mir deren Webseite angesehen und gelesen, daß eine STM32 Bord 
unter Rust praktisch demonstriert wird. Hat jemand von Euch damit schon 
herum gespielt?

Wie gut wird sich Rust für kleinere uC bewähren? Gibt es Gründe warum 
Rust nicht auf kleinen 8-Bittern laufen wird? Oder ist da C/C++ momentan 
doch noch die beste Wahl.

Ich bin an Rust schon etwas interessiert. Nur habe ich wenig Motivation 
Pionierarbeit oder mich mit schwierigen Problemen herumschlagen zu 
müssen. Normalerweise liegt es mir daran mit iC Probleme zu lösen 
anstatt lösen zu müssen. Ich bin sicher, daß sich in ein paar Jahren die 
augenblicklichen Wogen legen werden und man Platform gerechte Lösungen 
finden wird.

Schön wäre es schon, wenn man ein Rust Entwicklungssystem hätte ohne 
große Überraschungen und mit guten Low-Level Support. So wie es halt bei 
allen anderen uC der Fall ist. Es scheint, momentan wäre die STM32 
Familie die einzige uC Familie die unterstützt wird.

Ich wäre sehr an praktischen Erfolgsberichten interessiert. Also z.B. 
"Ich baute mir ein Gadget mit Rust auf STM32" und Informationen über die 
Erfahrungen durchs Projekt hindurch.

Im Augenblick theoretisiert Ihr mir eigentlich zu viel und zu viele 
Generalitäten werden hin und her geworfen. Wenn Rust wirklich Fuß fassen 
sollen brauchen viele von uns doch konkrete Anhaltspunkte wie es anderen 
wagemutigeren Wegbereitern gegangen ist und wie man die anfänglichen 
Ungewissheiten beseitigen könnte. Es ist nicht genug wenn nur die Gurus 
und Genies unter Euch damit Erfolge erzielen. Wir sollten wirklich 
vermeiden "Fanboys" zu sein und uns anstatt gegenseitig so gut es geht 
mit Fakten untereinander helfen und Erfahrungen austauschen.

Was mich betrifft, hätte ich an Rust nur im uC embedded Bereich 
praktisches Interesse.

von MaWin (Gast)


Lesenswert?

Gerhard O. schrieb:
> Wie gut wird sich Rust für kleinere uC bewähren? Gibt es Gründe warum
> Rust nicht auf kleinen 8-Bittern laufen wird?

Es gibt einen experimentellen Rustcompiler für AVR8.
Er ist allerdings noch relativ weit vom Produktiveinsatz entfernt.
Aber als Proof-of-Concept taugt er.

> Ich bin an Rust schon etwas interessiert. Nur habe ich wenig Motivation
> Pionierarbeit oder mich mit schwierigen Problemen herumschlagen zu
> müssen.

Auf allem, was ARM-Cortex (Raspbery Pi) oder größer (bis PC) ist, ist 
die Pionierarbeit schon lange geleistet und Rust ist dort produktiv 
einsetzbar.

> STM32

Da kenne ich den Status leider nicht.

> Im Augenblick theoretisiert Ihr mir eigentlich zu viel

Ja, das sehe ich auch so. Viele Leute haben hier im Thread eine starke 
Meinung, aber fast niemand von diesen Leuten hat Rust einmal wirklich 
ausprobiert. Das wird offensichtlich aus den teilweise haarsträubenden 
Behauptungen.

> Wir sollten wirklich
> vermeiden "Fanboys" zu sein und uns anstatt gegenseitig so gut es geht
> mit Fakten untereinander helfen und Erfahrungen austauschen.

Volle Zustimmung.
Weniger Gefühle und Meinung. Mehr Fakten und Erfahrung.

von STMRust (Gast)


Lesenswert?

Gerhard O. schrieb:
> Ich habe mir deren Webseite angesehen und gelesen, daß eine STM32 Bord
> unter Rust praktisch demonstriert wird. Hat jemand von Euch damit schon
> herum gespielt?

Seit ca. 2 Jahren nutze ich ausschließlich Rust für alle meine STM32 
Hobby Projekte. Unter anderem habe ich Niklas G.'s USB-Tutorial als 
Übung auf Rust portiert (wenngleich das eine meiner ersten Rust-Aktionen 
war und noch um einiges mehr unsafe Code aufwies als nötig).
Cargo gefällt mir super, man muss nicht auf irgendwelche IDEs setzen die 
einem das Grundgerüst generieren, sondern mit paar Handgriffen (Target 
wählen, no-std deklarieren und PAC laden) baut "cargo build" einfach die 
binary für den STM. Einen Schritt weiter kann "cargo run" auch das ganze 
samt debug ausgaben ausführen, wenn man z.b. probe-run oder cargo-embed 
nutzt. Wenn ich mich an die Verrenkungen mit make oder cmake erinnere, 
war das um einiges aufwendiger.

Was mich vor allem zu Rust bekehrt hat ist das Pattern matching. Anfangs 
dachte ich match ist einfach nur "sowas ähnliches wie switch", aber es 
ist so viel mehr, vor allem macht es das Arbeiten mit enums (davon hat 
man ja oft welche) sehr viel übersichtlicher.
Insgesamt finde ich Rust Code mittlerweile viel angenehmer und einfacher 
zu lesen als C-Code, auch weil es dank rustfmt immer im gleichen Stil 
ist.

Der Einstieg in Rust auf STM32 ist einfach und es gibt mittlerweile sehr 
viele Beispiele, z.b. das Rust Embedded Book 
https://docs.rust-embedded.org/book/

von Carsten P. (r2pi)


Lesenswert?

Gerhard O. schrieb:
> Gut Ding braucht Weil.

Sei mir bitte nicht böse, Gerhard O., wenn ich dich nicht nur wörtlich, 
sondern Buchstabe für Buchstabe zitiere, denn "gut Ding braucht Weil!". 
Das ist ein sehr kluger Satz. Vielleicht hast du das "e" vergessen für 
deine Aussage, aber ich bleibe bei der, die du abgeschickt hast: "Gut 
Ding braucht Weil!".

Das ist in etwa das, etwas anders, aber auf den Punkt formuliert, was 
man Wissenschaft nennt, vor allem Naturwissenschaft.

Frage stets "Weil? Warum?"! Und lasse niemals locker, auch wenn dein 
Gegenüber genervt ist. Warum? Weil es nicht um dein Gegenüber geht, 
sondern um das Thema. Nicht um die Wahrheit an sich. Warum nicht? Weil 
es keine Wahrheit an sich gibt, sondern nur mehr oder weniger gute und 
überprüfbare Versuche, sich ihr anzunähern. Dass es eine einzige 
Wahrheit gibt, behaupten nur der Papst und Spaziergänger.

von MaWin (Gast)


Lesenswert?

STMRust schrieb:
> Seit ca. 2 Jahren nutze

Vielen Dank für den Beitrag. Endlich einmal jemand, der Rust auch 
wirklich ausprobiert hat.

> nutze ich ausschließlich Rust für alle meine STM32

Sehr interessant. Da habe ich jetzt auf jeden Fall etwas gelernt. Das 
sollte ich auch einmal ausprobieren.

von Nop (Gast)


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>> Gegen was willst du den denn zertifizieren, wenn es keinen Standard
>> gibt?
>
> Das bleibt dir überlassen. Vielleicht gegen deinen Wocheneinkaufszettel?

Dummes Gelaber - das selbstverständlich in den Bereichen, wo 
zertifizierte Tools gefordert werden, nicht akzeptiert wird.

> An der Compilerqualität ändert es jedenfalls nichts.

Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt, 
gegen den eventuelle Abweichungen festzustellen bzw. zu dem Konformität 
zu belegen wäre. Damit ist auch die Aussage von "sehr guter Qualität" 
nur eine leere Worthülse.

von Gerhard O. (gerhard_)


Lesenswert?

Carsten P. schrieb:
> Gerhard O. schrieb:
>> Gut Ding braucht Weil.
>
> Sei mir bitte nicht böse, Gerhard O., wenn ich dich nicht nur wörtlich,
> sondern Buchstabe für Buchstabe zitiere, denn "gut Ding braucht Weil!".
> Das ist ein sehr kluger Satz. Vielleicht hast du das "e" vergessen für
> deine Aussage, aber ich bleibe bei der, die du abgeschickt hast: "Gut
> Ding braucht Weil!".
>
Obwohl ich Dir im Weiteren vollkommen zustimme, habe ich mein Zitat nur 
im herkömmlichen Sinn gemeint, daß man eben Rust die Gelegenheit geben 
sollte erwachsen und reifer zu werden und daß das Zeit braucht. In zehn 
Jahren wird sich noch viel ergeben. So kann ich leider nicht das 
Kompliment annehmen:-)

Ich möchte vorerst mich mit der Entwicklungsumgebung befassen um die 
Werkzeuge unter Windows in den Griff zu bekommen. Eigenbau STM32 HW habe 
ich auch. Es ist mir wichtig die Tool Chain zum Laufen zu bringen. Die 
Sprache selber ist ja ziemlich intuitiv wenn man mal von den Pragmas 
absieht die man lernen muß. Da sehe ich für mich eher die größeren 
Schwierigkeiten. Dafür sind aber die Online Dokus da. Die Tricks wird 
man man sowieso in Kollaboration mit Mitstreitern lernen müssen und 
vielleicht miteinander teilen können.

: Bearbeitet durch User
von Gerhard O. (gerhard_)


Lesenswert?

An STMrust,

Vielen Dank für Deine Hinweise. Ich habe mir schon die embedded Doku 
angesehen.

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt

Qualität ist die Abwesenheit von Kundenreklamationen.

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> Nop schrieb:
>> Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt
>
> Qualität ist die Abwesenheit von Kundenreklamationen.

Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Mombert H. schrieb:

>> Qualität ist die Abwesenheit von Kundenreklamationen.
>
> Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik.

Musst du sie noch auf die Gesamtkundenzahl beziehen, dann passt das 
schon.

Könnte natürlich sein, dass C-Compiler dann dank ihrer großen Kundenzahl 
verdammt gut abschneiden. ;-)

von Mombert H. (mh_mh)


Lesenswert?

Jörg W. schrieb:
> Mombert H. schrieb:
>>> Qualität ist die Abwesenheit von Kundenreklamationen.
>> Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik.
> Musst du sie noch auf die Gesamtkundenzahl beziehen, dann passt das
> schon.
> Könnte natürlich sein, dass C-Compiler dann dank ihrer großen Kundenzahl
> verdammt gut abschneiden. ;-)
Vorher müsste man klären was genau mit Kunde gemeint ist. Wenn ich clang 
oder gcc nutze sehe ich mich nicht als Kunde. Nur wenn ich ifort nutze 
sehe ich mich aktuell als Kunde und das macht weniger als 5% meiner Zeit 
aus.

von MaWin (Gast)


Lesenswert?

Mombert H. schrieb:
> Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik.

Genau.
In Abwesenheit von Kunden spielt Qualität keine Rolle.
Außer in QM-Hirnen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Mombert H. schrieb:
> Vorher müsste man klären was genau mit Kunde gemeint ist.

Nenne sie von mir aus „aktive Nutzer“. Streng genommen müsstest du 
natürlich noch die Nutzungshäufigkeit mit einbeziehen, denn je häufiger 
du sie nutzt, um so größer die Wahrscheinlichkeit, mal auf ein Problem 
damit zu stoßen.

von MaWin (Gast)


Lesenswert?

Mombert H. schrieb:
> Wenn ich clang oder gcc nutze sehe ich mich nicht als Kunde.

Krass.
Das sagt mehr über dich aus, als über clang, gcc und den Rest der Welt.

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> Mombert H. schrieb:
>> Wenn ich clang oder gcc nutze sehe ich mich nicht als Kunde.
>
> Krass.
> Das sagt mehr über dich aus, als über clang, gcc und den Rest der Welt.
Dann erleuchte mal die Welt und gib uns deine Definiton von Kunde.

von MaWin (Gast)


Lesenswert?

Mombert H. schrieb:
> Dann erleuchte mal die Welt und gib uns deine Definiton von Kunde.

Legaler Nutzer laut Lizenz.

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> Mombert H. schrieb:
>> Dann erleuchte mal die Welt und gib uns deine Definiton von Kunde.
>
> Legaler Nutzer laut Lizenz.

Wenn ich in den Supermarkt gehe, bin ich also kein (evtl. potentieller) 
Kunde? Oder wie definierst du Lizenz?

von DPA (Gast)


Lesenswert?

Software beschaffen    -> Lizenz Vertrag

Im Laden was Einkaufen -> Kauf Vertrag

Sind beides Verträge, man denkt über letzteren nur nicht so, weil das 
meistens implizit ist. (Ich geb einfach den angeschriebenen Betrag, und 
allen ist klar, was die Konditionen sind)

Eigentlich nervig, dass das bei Software noch nicht simpler gestaltet 
wurde. Kundenschutz ist auch nicht existent. Wie Geräte heute zu 
Servicen werden, zum Kotzen. Rechtssysteme versagen beim Digitalen 
einfach komplett, lassen Unternehmen verlangen, tun und lassen, was sie 
wollen, und regulieren am falschen Ort, um positiven Technologieeinsatz 
zu erschweren / verhindern.

von Mombert H. (mh_mh)


Lesenswert?

DPA schrieb:
> Software beschaffen    -> Lizenz Vertrag
> Im Laden was Einkaufen -> Kauf Vertrag
Das bedeutet man kann Software nicht kaufen? Was ist mit Software, die 
ich nicht gekauft oder beschafft habe aber trotzdem nutze? Bin ich dann 
Kunde?

von DPA (Gast)


Lesenswert?

Mombert H. schrieb:
> DPA schrieb:
>> Software beschaffen    -> Lizenz Vertrag
>> Im Laden was Einkaufen -> Kauf Vertrag

> Das bedeutet man kann Software nicht kaufen?

Das ganze ist etwas kompliziert, ich überblicke das alles auch nicht.
Die kurze Version ist, Ja, man kann Software Kaufen, aber was heisst das 
eigentlich?

Man muss sich da überlegen, was man da unter kaufen versteht, bzw. was 
man eigentlich kaufen will. Man kann z.B. Lizenzen anbieten/kaufen. 
Damit kann man z.B. Nutzungsrechte an einer Software erwerben, aber auch 
andere Dinge festlegen.

Kann man zwar beim Kauf anderer Sachen auch machen, insbesondere bei 
anderen nicht physischen Sachen (Bilder, Filme, Musik (oft separat 
Aufzeichnung, Vorführung, Noten, Texte), etc.), ist das recht üblich. 
Ich bin mir nicht sicher, bis zu welchem Grad man das mit physischen 
Dingen machen kann, und wie genau das mit "geistigem Eigentum", 
Eigentumsrechten, Besitzrechten, usw. im Detail zusammenhängt & 
funktioniert, aber man kann überall einiges festlegen.

Aber eventuell will man eine Software kaufen, im sinne von den Code & 
sämtliche Rechte daran kaufen. Das geht bis zu einem gewissen Grad auch. 
Wobei, in gewissen Ländern kann man gewisse Rechte nicht verkaufen oder 
aufgeben, und vieles ist je nach Land sehr anders geregelt. Darum kann 
man z.B. nicht einfach sagen "Ich geb all meine rechte auf, und gebe sie 
der Allgemeinheit", sondern braucht dafür Lizenzen wie CC0, die 
versuchen das nächst beste mögliche zu bieten 
(https://creativecommons.org/share-your-work/public-domain/cc0/). 
Ehrlich gesagt, ich wüsste gar nicht, wie ich eine Software jemand 
anderem verkaufen könnte, im sinne von alle möglichen Rechte daran.

> Was ist mit Software, die ich nicht gekauft oder beschafft habe aber trotzdem 
nutze?

Um diese nutzen zu können, brauchst du trotzdem eine Vertrag/Lizenz, die 
dir das erlaubt. Oft ist das aber auch ein bisschen wie wenn man sonst 
was Einkauft oder Verschenkt. Wenn ich meine eigene Software gratis 
anbiete, oder als Demo Version, reicht es vermutlich zu sagen, das ist 
Freeware / eine Demo Version, hier ist der Download. Aber normalerweise 
gibt es danach trotzdem noch irgend eine EULA, die genauer festhält, das 
die Konditionen für den Endnutzer sind. Es gibt da noch irgend einen 
Unterschied zwischen Endnutzer Lizenzen und anderen arten von Lizenzen. 
Die GPL z.B. ist keine Endnutzerlizenz. Die legt einfach fest, was man 
mit dem Code machen darf, und man muss ihr nicht explizit zustimmen, 
will man die Rechte, die sie einem gibt, muss man sich aber an sie 
halten. Wenn ich meinen Code dann gratis öffentlich auf GitHub stelle, 
mit der GPL Lizenz drin, gebe ich die Lizenz quasi gratis an andere. 
Aber ich könnte den Code auch ohne Lizenz veröffentlichen, dann dürfte 
ihn eigentlich keiner nutzen. Als Urheber kann ich Software beliebig 
lizenzieren, ich kann den Code also auch unter der / irgendeiner Lizenz 
lizenziert verkaufen. (Und die Lizenz legt dann auch Dinge fest, wie 
z.B. darf ich das weiterverkaufen).
Keine Ahnung, wann man Lizenzen explizit zustimmen muss und wann nicht, 
und wie das alles im Detail zusammen hängt. Vermutlich blickt da sowieso 
keiner durch.

Irgendwo hätte ich von der BM her noch ein Buch 
(https://www.booklooker.de/B%C3%BCcher/Thomas-Sutter-Somm+ZGB-OR-Schweizerisches-Zivilgesetzbuch-und-Obligationenrecht-mit-ZPO-SchKG-und/isbn/9783906186245), 
da steht auch irgendwo drin, wer (in der Schweiz) beim Verkauf von 
Dingen welche Rechte und Pflichten hat, was Eigentum und Besitz genau 
heist, wie man das Anwendet / was man in einem Vertrag anders regeln 
kann, usw. Theoretisch könnte ich dort im ZGB Teil, unter Sachenrecht, 
alles relevante zum kaufen und verkaufen von Dingen nachlesen (der teil 
ist gar nicht mal so lang), das dürfte zu einem teil auch auf Software 
zeug anwendbar sein. wobei dort das URG[1] (Urheberrecht) noch relevant 
sein dürfte, für all das zeug rund um geistiges Eigentum (ich glaube das 
fehlt in meinem Buch). Ja, da könnte ich nachlesen, wie das genau 
funktioniert. Könnte... Aber gilt ja eh nur in der Schweiz, bringt mir 
vermutlich eh nicht viel.

Wie auch immer, ob du jetzt eine Lizenz kaufst, oder die geschenkt 
bekommst, normalerweise bekommst du schon irgendwoher eine.



> Bin ich dann Kunde?

Gute frage. Ich bin mir nicht sicher, ob das irgendwo überhaupt formal 
definiert ist. Da kann ich nur meine eigene Sichtweise bringen.
Was bedeutet es wirklich, Kunde zu sein? Wenn ich dir was schenke, hast 
du vermutlich keine Garantie Ansprüche usw. In gewissen sinne bist du 
vermutlich schon ein Kunde, aber wer würde wen wann wirklich als Kunde 
betrachten? Ehrlich gesagt betrachte ich mich nicht als Kunde, wenn ich 
Zeugs geschenkt kriege. Und andere, die meinen Code gratis nutzen, (den 
ich nicht Verkaufe), sehe ich auch nicht als Kunde. Wenn mir Fehler 
gemeldet werden, und ich hab genug infos, fix ich die normalerweise 
schon. Aber wenn jemand echten Support für seine Probleme usw. will, nö, 
keine Lust. Das soll er sich woanders kaufen.

Also für mich ist man schon erst Kunde, sobald Geld fliesst.


[1] https://www.fedlex.admin.ch/eli/cc/1993/1798_1798_1798/de

von MaWin (Gast)


Lesenswert?

DPA schrieb:
> Bilder, Filme, Musik (oft separat Aufzeichnung, Vorführung, Noten, Texte

Vielen Dank für diesen riesigen Offtopic-Ausflug.
Dann können wir ja hoffentlich zum Threadthema zurückkommen. Ja?

von Mombert H. (mh_mh)


Lesenswert?

DPA schrieb:
> Das ganze ist etwas kompliziert
Ich stimme dir im Großen und ganzen zu und erwarte auch keine Antwort 
auf meine Fragen (ich hatte nur auf eine ernst gemeinte Antwort von 
MaWin auf die erste Frage gehofft ...). Ich möchte es an zwei Stellen 
aber noch etwas komplizierter machen ;-).

DPA schrieb:
>> Was ist mit Software, die ich nicht gekauft oder beschafft habe aber trotzdem 
nutze?
> Um diese nutzen zu können, brauchst du trotzdem eine Vertrag/Lizenz, die
> dir das erlaubt.
Um sie legal nutzen zu können. Wäre ich ein Kunde, wenn ich sie illegal 
nutzen würde? Was ist wenn mein Arbeitgeber der Käufer ist?

DPA schrieb:
> Ehrlich gesagt betrachte ich mich nicht als Kunde, wenn ich
> Zeugs geschenkt kriege. Und andere, die meinen Code gratis nutzen, (den
> ich nicht Verkaufe), sehe ich auch nicht als Kunde.
Das umgeht auch ein weiteres Problem. Wenn man Software für sich selbst 
entwickelt und nutzt, ist man dann sein eigener Kunde?

MaWin schrieb:
> DPA schrieb:
>> Bilder, Filme, Musik (oft separat Aufzeichnung, Vorführung, Noten, Texte
>
> Vielen Dank für diesen riesigen Offtopic-Ausflug.
> Dann können wir ja hoffentlich zum Threadthema zurückkommen. Ja?

Ich habe gedacht, die Qualität des rust-Compilers ist essenziell, um die 
Frage "Rust - ist das hier um zu bleiben?" zu beantworten. Und dafür 
müssen wir wohl erstmal klären was Kunden sind, denn:
MaWin schrieb:
> Nop schrieb:
>> Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt
>
> Qualität ist die Abwesenheit von Kundenreklamationen.

von MaWin (Gast)


Lesenswert?

Mombert H. schrieb:
> Und dafür müssen wir wohl erstmal klären

Es ist alles beantwortet. Deshalb werde ich dazu auch nichts mehr sagen.
Dass dir die Antworten nicht in den Kram passen, ist mir klar. Aber 
damit musst du dann wohl leben.

von cppbert3 (Gast)


Lesenswert?

In diesem Forum tummeln sich so dermaßen viele Leute die jeden kleinsten 
Satz dazu nutzen um eine riesen Off Topic Diskussion von der Leine zu 
lassen und dann ewig drauf rum zu reiten

Meistens wenn das Thema trivial oder irgendeine scheinbare nähe zu ihrem 
Fachgebiet aufweisst, oder man sich gar nicht mit dem Kern Topic 
auskennt und einfach nur quasseln will, Heise-Forumskultur in reinform

Es ist idiotisch gegen eine 5 Jahre alte Sprache zu wettern die keinem 
ein Haar krümmt und mehr oder minder bekannte Strategien besser 
integriert, so lange die nutzung nicht erzwungen wird ist jede 
Argumentation sinnfrei, wenn sich Rust trotz der ganzen schwächen 
etabliert ist die komplette Community ein der ihr euch befindet eben 
nicht klug, wenn Rust stirb ist nichts verloren

Diskutiert doch lieber mit MaWin über die Vor/Nachteile dieser oder 
jener Konstruktion von Rust als all die alten Kammellen die jeder kennt 
und versteht und nur ihr denkt das jemand die nicht genauso gut 
vestanden habt wie ihr durchzubeten/kauen

alte Kamellen:
-statische Codeanalyse reicht völlig aus
-Sanitizer machen alles perfekt
-schreib einfach guten Code dann ist auch ok
-ohne ISO standard kann ich nicht leben
-ohne zertifizierung kann ich nicht leben
-wenn es nicht von allen Herstellern unterstuetzt wird ist es nichts 
wert
-wenn es nicht jedes problem ob syntaktisch, ausdruckstaerke oder 
logisch löst ist es nix wert
-Es kompiliert langsam, also ist es nichts wert

Solche Kommentare können nicht von versierten und erfahrenen Entwickler 
mit grossen Team und Projekterfahrungen kommen denn das alles sind schon 
100% genutzte und bekannte probleme und wissen, nur der kleingeist denkt 
man müsse damit noch misionieren gehen, das ist alles ausgetretenes 
standardwissen, auch wenn manche das hier nicht verstehen weil ihre 
Welten so klein und überschaubar sind

Also reisst euch mal zusammen ihr Nörgelfritzen und bleibt bei der Sache

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ich kann mich gar nicht erinnern, dass hier jemand gegen Rust 
"gewettert" hätte.

Was kritisiert worden ist ist, dass man mit der neuen Sprache auch 
gleich mal noch das 43. neue Buildsystem etabliert und ziemlich stark 
verbandelt hat.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Was kritisiert worden ist ist, dass man mit der neuen Sprache auch
> gleich mal noch das 43. neue Buildsystem etabliert und ziemlich stark
> verbandelt hat.

Jörg, auch du warst gemeint mit:

cppbert3 schrieb:
> Meistens wenn das Thema trivial oder irgendeine scheinbare nähe zu ihrem
> Fachgebiet aufweisst, oder man sich gar nicht mit dem Kern Topic
> auskennt und einfach nur quasseln will, Heise-Forumskultur in reinform

Die Sache mit dem angeblich stark verbandelten Buildsystem ist bereits 
mehrfach beantwortet. Dir passt die Wahrheit nur nicht. Das akzeptiere 
ich. Nun akzeptiere doch auch du die Realität. Auch das zehnte 
Infragestellen wird zu den gleichen Antworten führen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

MaWin schrieb:
> Dir passt die Wahrheit nur nicht.

Mir ist sie (zumindest derzeit) schlicht egal.

Wenn ich aber eine Sprachbeschreibung sehe, die mir zugleich ein 
bestimmtes Buildsystem schmackhaft machen möchte ("Hello Cargo!" kommt 
gleich nach "Hello World!"), dann kannst du mir 10mal erzählen, die 
seien nicht verbandelt. Irgendwie sind sie es, sonst hätten sich die 
Autoren des Rust-Buchs nicht die Mühe gemacht, Cargo ein eigenes Kapitel 
zu widmen.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Wenn ich aber eine Sprachbeschreibung sehe, die mir zugleich ein
> bestimmtes Buildsystem schmackhaft machen möchte ("Hello Cargo!" kommt
> gleich nach "Hello World!"),

Ja, genau. Das erste Beispiel "Hello World" im Buch ist komplett ohne 
Cargo.
Komisch, gell? Wo man doch ohne Cargo praktisch nichts machen kann, weil 
es ja angeblich so stark verbandelt ist.

Mal ganz davon abgesehen, dass Cargo halt sehr gut ist und es vielleicht 
deshalb so gerne genutzt wird. Mit einer "starken Verbandelung" hat 
das nichts zu tun.

Aber was schreibe ich hier. Das ist alles ja schon mehrfach erklärt 
worden.

von Oliver S. (oliverso)


Lesenswert?

MaWin schrieb:
> Ja, genau. Das erste Beispiel "Hello World" im Buch ist komplett ohne
> Cargo.
> Komisch, gell?

"Hello World"- Beispiele für C kompilieren i.d.R. mit "gcc main.c -o 
main" oder so. Komplett ohne jedes Build-System. Auch komisch, oder?

Oliver

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> MaWin schrieb:
>
>> Dir passt die Wahrheit nur nicht.
>
> Mir ist sie (zumindest derzeit) schlicht egal.
> Wenn ich aber eine Sprachbeschreibung sehe, die mir zugleich ein
> bestimmtes Buildsystem schmackhaft machen möchte ("Hello Cargo!" kommt
> gleich nach "Hello World!"), dann kannst du mir 10mal erzählen, die
> seien nicht verbandelt. Irgendwie sind sie es, sonst hätten sich die
> Autoren des Rust-Buchs nicht die Mühe gemacht, Cargo ein eigenes Kapitel
> zu widmen.

Alte Kamelle: Buildsystemzwang, alles kommt aus dem Internet, Entwickler 
arbeiten nur noch mit third parties, validierungsproblematik

Wenn du so wie ich bei jedem Kunden ein anderes Buildsystem nutzen 
müsstes würde dich das vielleicht gar nicht mehr so stören, Rust schafft 
mit Cargo wenigstens eine gemeinsame Basis auch wenn es, was garantiert 
passieren wird nacher 2-3 Cargo clone geben wird, weil vielleicht doch 
zu viel fehlt wird ein grossteil diesen Pseudostandard verwenden und das 
ist, egal wie du es drehst und wendest erstmal keine absolut 
problematische Situation - und wenn es auch nur die Rust Entwickler 
zwingt ihre Sprache auch in einem buildsystem kontext zu betrachten

z.B. bei C++ warten wir alle auf Module, nur die meisten Buildsystem 
haben riesige Probleme auf Modulveraenderungen zu reagieren, weil es da 
keinen Standard gibt wie die intermediate Dateien heissen können usw. - 
weil sich die C++ Chairs immer schon einen dreck um die Infrastruktur um 
die sprache gekümmert haben, das ist z.B. auch der grund warum der 
Prepozessor so lange nicht teil des Standards war, die hatten keinen 
Bock auf die Verantwortung und haben das so weit wie möglich den 
Benutzern/Toolchainentwicklern aufgebürdet

Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit 
stark integrierten Buildsystemen auf den Markt geworfen wurden

von cppbert3 (Gast)


Lesenswert?

Oliver S. schrieb:
> MaWin schrieb:
>
>> Ja, genau. Das erste Beispiel "Hello World" im Buch ist komplett ohne
>> Cargo.
>> Komisch, gell?
>
> "Hello World"- Beispiele für C kompilieren i.d.R. mit "gcc main.c -o
> main" oder so. Komplett ohne jedes Build-System. Auch komisch, oder?
> Oliver

Das ist doch alles jedem bekannt, und das ist auch nichts was MaWin hier 
beschreitet oder als Argument für irgendwas verwendet

Was soll so ein Post bewirken?

von Oliver S. (oliverso)


Lesenswert?

cppbert3 schrieb:
> Das ist doch alles jedem bekannt, und das ist auch nichts was MaWin hier
> beschreitet oder als Argument für irgendwas verwendet

Doch, genau das war das Argument: Rust ist gar nicht mit Cargo 
verbandelt, weil das Hello-World-Beispiel im Buch ohne auskommt.

Oliver

von cppbert3 (Gast)


Lesenswert?

Oliver S. schrieb:
> cppbert3 schrieb:
>
>> Das ist doch alles jedem bekannt, und das ist auch nichts was MaWin hier
>> beschreitet oder als Argument für irgendwas verwendet
>
> Doch, genau das war das Argument: Rust ist gar nicht mit Cargo
> verbandelt, weil das Hello-World-Beispiel im Buch ohne auskommt.
> Oliver

Er hat doch nur bestätig das es gleichwertig ist, du kannst alles ohne 
und alles mit dem buildsystem machen, und das stand hier schon vor 
monaten und wird immer und immer wieder rausgekramt, wie langweilig

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

cppbert3 schrieb:
> Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit
> stark integrierten Buildsystemen auf den Markt geworfen wurden

Die haben ein integriertes Laufzeitsystem, insofern kannst du für die 
eher Python als Vergleich heranziehen als Rust, C oder FORTRAN.

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> cppbert3 schrieb:
>> Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit
>> stark integrierten Buildsystemen auf den Markt geworfen wurden
>
> Die haben ein integriertes Laufzeitsystem, insofern kannst du für die
> eher Python als Vergleich heranziehen als Rust, C oder FORTRAN.

über Laufzeitsystem haben wir hier doch bisher noch gar nicht 
gesprochen?

ich bezog mich eher drauf das es kein Link System gibt sondern der 
Quelltext mehr oder weniger direkt seine Abhängigkeiten vorschreibt - so 
wie mit Turbo Pascal in grauer Vorzeit

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

cppbert3 schrieb:
> ich bezog mich eher drauf das es kein Link System gibt sondern der
> Quelltext mehr oder weniger direkt seine Abhängigkeiten vorschreibt

Das ist aber durch das integrierte Laufzeitsystem ohnehin gesetzt. Daher 
der Vergleich mit Python.

Der Anspruch eines Systems, das mit einem Linker arbeitet, ist ja eher, 
dass man Komponenten von möglichst vielen verschiedenen Welten 
miteinander integrieren kann. (Womit ich nicht behaupten will, dass das 
bei Rust nicht gehen würde.)

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> Das ist aber durch das integrierte Laufzeitsystem ohnehin gesetzt. Daher
> der Vergleich mit Python.

ich verstehe den Bezug immer noch nicht - ich möchte nur zum Ausdruck 
bringen das Build-Unit Abhängigkeiten in anderen Sprachen wie C#, Java 
und z.B. auch Turbo Pascal schon teil des Sprachstandards sind also so 
eine Art Sprach-Integriertes Buildsystem und sich da auch keiner 
beschwert hat

bei C oder C++ (erst mit Modulen) gibt es so was gar nicht - ohne 
Preprozessor und Linker sind die einzelnen Build-Units völlig hilflos in 
der Luft umherfliegend - alles überentkoppelt weil C/C++ lange Zeit 
selbst das Konzept-von "Dateien" als zu grosse Abhängigkeit empfunden 
hat

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> Der Anspruch eines Systems, das mit einem Linker arbeitet, ist ja eher,
> dass man Komponenten von möglichst vielen verschiedenen Welten
> miteinander integrieren kann.

das war nicht die Grundintension bei C/C++ - da wollte man nur mit 
Gewalt jeden Kontakt zwischen den "Dateien" vermeiden, weil Dateien 
damals noch kein durchgesetztes Konzept waren und es eher darum ging den 
Prozess in möglichst viele Teilschritte zu zerlegen weil der geringe 
Speicher der damaligen System einfach zu schnelle an die grenze gestoßen 
ist - viele der heutigen Entwickler vergessen völlig wo das alles mal 
angefangen hat

von MaWin (Gast)


Lesenswert?

In einer perfekten Welt, die ich mir in meinem wirren Kopf so 
zusammenspinne, hätte ich auch gerne das eine perfekte Buildsystem, 
das mit allen Sprachen funktioniert und das alle Features genau so hat, 
wie jeder das will.

Leider ist das nicht die Realität.

Die Rustentwickler haben mit Cargo ein ziemlich gutes Buildsystem 
geschaffen, das viele Sachen sehr elegant löst. Standardisiertes 
Buildmanifest mit gutem Options- und Dependency-Management. Sehr schöne 
Integration von Unit-Tests, System-Tests und Beispielprogrammen. Sehr 
gute UX. Es funktioniert ganz einfach out of the box. Das sind so die 
Dinge, die mir spontan einfallen. Es gibt sicher noch viel mehr.

Und trotzdem ist es eben nicht fest verbandelt.
Es steht dem Entwickler frei, ob er dieses gute Angebot annimmt. Und 
natürlich nehmen die meisten Entwickler dieses Angebot an, weil es 
ganz einfach sehr gut funktioniert.

von Daniel A. (daniel-a)


Lesenswert?

cppbert3 schrieb:
> Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit
> stark integrierten Buildsystemen auf den Markt geworfen wurden

Die nutze ich privat einfach nicht. Früher in der Schule und bei der 
Arbeit gab es noch etwas Java, bis ich das später endlich alles ersetzen 
durfte.

Wobei, in Java kann man Dateien haben, die exklusiv für ein Interface 
sind. Und ich kann Code Kompilieren & Ausführen, der Interfaces nutzt, 
ohne dabei die Implementation kennen zu müssen (Ich kann sogar eine zur 
Runtime nachladen usw., und auch noch ziemlich simpel.) Und auch wenn 
die Klassen, die man importiert, zum Kompilieren vorhanden sein müssen, 
das ist glaube ich bei Java immerhin nicht rekursiv. Eigentlich hat Java 
das noch vergleichsweise gut gelöst. Und das Generics Konzept gefällt 
mir ehrlich gesagt auch recht gut, ziemlich inspirierend aus technischer 
Sicht wenn man sich harte Templates gewohnt ist.

von MaWin (Gast)


Lesenswert?

Daniel A. schrieb:
> Eigentlich hat Java
> das noch vergleichsweise gut gelöst. Und das Generics Konzept gefällt
> mir ehrlich gesagt auch recht gut,

Das ist sehr erfreulich.

Aber da es hier im Thread um Rust geht:
Wie gefallen dir Rust Generics denn so?

von cppbert3 (Gast)


Lesenswert?

Daniel A. schrieb:
> cppbert3 schrieb:
>> Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit
>> stark integrierten Buildsystemen auf den Markt geworfen wurden
>
> Die nutze ich privat einfach nicht. Früher in der Schule und bei der
> Arbeit gab es noch etwas Java, bis ich das später endlich alles ersetzen
> durfte.

wie gesagt - bei Java/C# und Konsorten ist das alles Teil des 
Sprachstandards - bei C/C++ nicht - und Rust nutzt einen Teil dieser 
Konzepte

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

cppbert3 schrieb:
>> Der Anspruch eines Systems, das mit einem Linker arbeitet, ist ja eher,
>> dass man Komponenten von möglichst vielen verschiedenen Welten
>> miteinander integrieren kann.
>
> das war nicht die Grundintension bei C/C++

Für C schon, denn das musste unbedingt mit Assemblercode kombiniert 
werden können, und FORTRAN war zu der Zeit vermutlich das, was heute C 
ist.

Für Rust wurde ja zumindest gesagt, dass es mit einer C-Umwelt klar 
kommt. Muss es eigentlich auch, denn bis mal alles Wichtige in Rust 
verfügbar ist, werden schon noch ein paar Jahrzehnte vergehen.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> denn bis mal alles Wichtige in Rust verfügbar ist

Was ist denn "alles Wichtige"?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>> denn bis mal alles Wichtige in Rust verfügbar ist
>
> Was ist denn "alles Wichtige"?

Alles, was täglich gebraucht wird.

Wenn du in der Lage bist, einen normalen Desktop-Computer mitsamt seiner 
"Zutaten" (Browser, Editor, Office, Bildbearbeitung, PDF-Viewer etc. 
pp.) und dem zugrunde liegenden Betriebssystem mit Rust zu bauen (also 
nicht nur theoretisch, sondern ganz praktisch), dann dürfte der Punkt 
erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen 
geschriebener Bibliotheken nicht mehr so wichtig ist.

Wobe, FORTRAN hängt uns ja selbst heute noch hinterher, numpy oder 
Matlab lassen da grüßen.

: Bearbeitet durch Moderator
von Daniel A. (daniel-a)


Lesenswert?

Jörg W. schrieb:
> Wenn du in der Lage bist, einen normalen Desktop-Computer mitsamt seiner
> "Zutaten" (Browser, Editor, Office, Bildbearbeitung, PDF-Viewer etc.
> pp.) und dem zugrunde liegenden Betriebssystem mit Rust zu bauen

Nutzer von Gentoo & co. tun mir jetzt schon leid. "emerge -uDN @world" - 
und jetzt warten wir mal einen Monat...

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> dann dürfte der Punkt
> erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen
> geschriebener Bibliotheken nicht mehr so wichtig ist.

Warum sollte man den Punkt anstreben wollen?
Was hat das überhaupt mit Rust zu tun? Rust ist gut interoperabel mit 
anderen Sprachen. By Design. In Gegensatz zu C. C ist nur mit C 
kompatibel. Deshalb muss sich der Rest der Welt darum kümmern mit C 
kompatibel zu sein. Und das tut Rust sehr gut. Heute.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.