🐧 DPA 🐧 schrieb:> Die Randbedingungen sind in dem Fall die Annahmen, die man> sicherstellen> muss. Genau da muss man hinsehen. Genau das ist es ja.
Ja. Die muss man sicherstellen.
Und in C muss man zusätzlich noch jede einzelne Zeile auf UB
kontrollieren und Sicherstellen, dass kein UB auftritt.
MaWin O. schrieb:> Nein. Das ist Unsinn.> Man braucht genau einen einzigen Check ganz am Anfang der> Verarbeitungskette.
Wie soll das gehen? Und was ist eine Verarbeitungskette? Es geht um
einen Zugriff auf ein Element in einem Array.
> Du hängst dich hier an einem Detail auf.
Nö ich hänge mich an der Aussage auf, dass Rust auf magische und
kostenlose weise alles mögliche prüfen kann. Dass es allein durch die
Sprache selbst sicher wird. Meist zur Kompilierzeit und wenn dann mit
quasi null kosten zur Laufzeit.
Das ist deine Grundaussage zu Rust. Kein Detail. Und da hätte ich halt
mal gerne zu einem konkreten Beispiel eine Aussage wie Rust das machen
will.
> Wenn du wirklich irgendeine Stelle findest, bei der dieser eine> Maschinenzyklus dich wirklich stört,
Du prüfst Array Zugriffe mit EINEM Maschinenzyklus? Rust ist echt der
Hammer.
Cyblord -. schrieb:> Wie soll das gehen? Und was ist eine Verarbeitungskette? Es geht um> einen Zugriff auf ein Element in einem Array.
LTO + moderner Compiler.
> Nö ich hänge mich an der Aussage auf, dass Rust auf magische und> kostenlose weise alles mögliche prüfen kann.
Magie ist unbeteiligt.
MaWin O. schrieb:> Cyblord -. schrieb:>> Wie soll das gehen? Und was ist eine Verarbeitungskette? Es geht um>> einen Zugriff auf ein Element in einem Array.>> LTO + moderner Compiler.
Ach so. Dann sind meine Fragen natürlich beantwortet. Danke.
@Cyblord
Es geht MaWin nicht um Fremdeinflüsse die im Kernel durch Hardware und
User-Space auftauchen können - die sind ja nicht Teil von einem sicherem
Rust Code daher muss man dort genau so wie in C vorsichtig sein - aber
diese Vorsicht ist so gut wie nicht nötig wenn du dich dann irgendwann
in safem Rust-Code befindest (also weiter drinnen) - dann sorgt der
Kompiler für dich - so lange du nicht wieder an solche Grenzen zur
Hardware/User-Space kommst
Es ist mir unverständlich wie man nur im entferntesten, als erfahrerener
Entwickler glauben kann das ein andere Entwickler meinen könnte das es
da irgendwie eine Magische-Hochperformante Sicherungsschicht geben kann
- keine Sprache der Welt kann das und das hat hier auch noch nie
irgendjemand (auch nicht MaWin) behauptet - es wird immer nur sehr
intensiv so rausinterpretiert weil der andere das ja nicht wirklich im
Detail verstehen "kann"
cppbert schrieb:> Es geht MaWin nicht um Fremdeinflüsse die im Kernel durch Hardware und> User-Space auftauchen können - die sind ja nicht Teil von einem sicherem> Rust Code daher muss man dort genau so wie in C vorsichtig sein - aber> diese Vorsicht ist so gut wie nicht nötig wenn du dich dann irgendwann> in safem Rust-Code befindest (also weiter drinnen) - dann sorgt der> Kompiler für dich - so lange du nicht wieder an solche Grenzen zur> Hardware/User-Space kommst
Ach so na klar. Also der Benefit ist ein total sicherer Kernel. Der
natürlich auch nicht nach außen mit irgendwas reden darf, damit man den
Safe-Space nicht verlässt. Dann aber, dann kommt Rust voll zur Geltung.
Natürlich nicht User Space. Die Applikation juckt ja nicht.
Das mag ja im Bereich Linux-PC-Programmierung für irgendwen ein Benefit
darstellen. Wer weiß, es soll solche Leute geben.
Aber wenn man in Richtung Embedded und Mikrocontroller absteigt, findet
man immer weniger Kernel und immer mehr Applikation. Und dann stellt
sich, mal wieder, die Frage, warum soll man hier nun Rust nehmen?
Können wir also im Protokoll festhalten dass Rust im Bereich Embedded
nichts bringt? Sondern vor allem im Bereich Linux-Kernel-Nerdistan.
cppbert schrieb:> Es geht MaWin nicht um Fremdeinflüsse die im Kernel durch Hardware und> User-Space auftauchen können - die sind ja nicht Teil von einem sicherem> Rust Code daher muss man dort genau so wie in C vorsichtig sein - aber> diese Vorsicht ist so gut wie nicht nötig wenn du dich dann irgendwann> in safem Rust-Code befindest (also weiter drinnen) - dann sorgt der> Kompiler für dich - so lange du nicht wieder an solche Grenzen zur> Hardware/User-Space kommst
Gut erklärt. Vielleicht versteht es nun jemand. :)
Hinzu kommt noch:
Diese "Sicherheitsschichten" sind mit Hilfe von unsafe-Rust
implementiert und in der Regel sehr sehr dünn. Meistens sogar zero-cost.
Weil die meisten der Abfragen, sodenn welche notwendig sind, im C Code
eh schon vorhanden sein müssen. Es kommen nur äußerst selten zusätzliche
Lauzzeitabfragen rein.
Und falls Cyblord jetzt doch die eine hochkritische Stelle in seinem
Rustcode findet, wo eine Abfrage unnötigerweise generiert wird und es
wirklich wehtut, dann kann er genau an dieser Stelle selbstverständlich
eigenverantwortlich einen unchecked-Zugriff in unsafe-Rust machen. Gar
kein Problem und auch völlig legitim. Damit ist diese eine Stelle
performancemäßig entschärft und sämtliche andere Safetyprüfungen werden
weiterhin alle durchgeführt. Auch für diesen einen unchecked-Zugriff.
z.B. der Borrow-checker ist weiterhin aktiv. Der komplette restliche
Rustcode ist unbeeinflusst.
Cyblord -. schrieb:> Aber wenn man in Richtung Embedded und Mikrocontroller absteigt, findet> man immer weniger Kernel und immer mehr Applikation. Und dann stellt> sich, mal wieder, die Frage, warum soll man hier nun Rust nehmen?
Weil man heute ein sicheres und performantes Embedded-Programm komplett
in Safe-Rust schreiben kann. Stand der Technik heute auf ESP32 und
vielen weiteren gängigen Controllern.
Das alles mit äußerst geringem Overhead. Nur so als Beispiel: Das
komplette Zugriffsmanagement auf die Peripherie ist zu 99.9% statisch
geprüft. Es gibt lediglich eine einzige Laufzeitabfrage während der
Initialisierung. Und wenn man wollte, könnte man die auch noch
herausoperieren.
Multicoreentwicklung auf embedded Hardware ist mit Rust sehr elegant und
hat so gut wie keinen höheren Overhead als ein korrektes C-Programm
hätte. Locks, IRQ-disable oder atomics braucht man in C auch.
Probiere es doch einfach mal aus!
> Können wir also im Protokoll festhalten dass Rust im Bereich Embedded> nichts bringt?
Ungern. Denn es bringt, wie gesagt, enorme Vorteile.
Cyblord -. schrieb:> klar. Also der Benefit ist ein total sicherer Kernel. Der> natürlich auch nicht nach außen mit irgendwas reden darf
Das interpretiere ich natürlich nur als Trollversuch deinerseits.
MaWin O. schrieb:> Das alles mit äußerst geringem Overhead. Nur so als Beispiel: Das> komplette Zugriffsmanagement auf die Peripherie ist zu 99.9% statisch> geprüft.
Kunststück. Das IST ja auch alles statisch. Fehlerhafte Zugriffe
passieren aber, oh Wunder, im Speicher. Und meistens eben bei
dynamischem Speicher. Das ist statische Zugriffe leicht prüfen kann, ist
doch eine Binse.
Cyblord -. schrieb:> Kunststück. Das IST ja auch alles statisch. Fehlerhafte Zugriffe> passieren aber, oh Wunder, im Speicher. Und meistens eben bei> dynamischem Speicher. Das ist statische Zugriffe leicht prüfen kann, ist> doch eine Binse.
Ach. Eben hast du noch gesagt, dass Rust ein enormes Problem auf
Embedded hat.
Jetzt erkennst du, dass genau das Gegenteil der Fall ist.
Gut, dass auch du Erkenntnis erlangen kannst.
Dynamischen Speicher kann Rust übrigens auch zum allergrößten Teil
statisch prüfen. Lediglich dynamische Arrays nicht. Aber das kann C auch
nicht.
MaWin O. schrieb:> Ach. Eben hast du noch gesagt, dass Rust ein enormes Problem auf> Embedded hat.
Ja und ich habe ein KONKRETES Beispiel genannt wo ich das Problem sehe.
Da bist du bisher nicht drauf eingegangen.
Für statische Tests kann ich auch LINT nehmen. Da brauche ich keine neue
Sprache.
Deine Aussage war bisher dass Rust Code automatisch sicher ist.
Jetzt lernen wir: Außer da eben da wo er nicht sicher ist. Also da wo
ich nicht einfach statisch zur Kompilierzeit prüfen kann.
Und deshalb machst du so ein Fass für Rust auf?
Cyblord -. schrieb:> Ja und ich habe ein KONKRETES Beispiel genannt wo ich das Problem sehe.
Ich sehe auch bei mehrmaligem Lesen kein konkretes Beispiel. Könntest du
das noch einmal wiederholen, bitte?
Cyblord -. schrieb:> Deine Aussage war bisher dass Rust Code automatisch sicher ist.> Jetzt lernen wir: Außer da eben da wo er nicht sicher ist.
Dann hast du etwas gelernt, was hier nie gesagt wurde.
Rust-Code ist automatisch sicher. Punkt.
Cyblord -. schrieb:> Ach so na klar. Also der Benefit ist ein total sicherer Kernel. Der> natürlich auch nicht nach außen mit irgendwas reden darf, damit man den> Safe-Space nicht verlässt. Dann aber, dann kommt Rust voll zur Geltung.> Natürlich nicht User Space. Die Applikation juckt ja nicht.
habe nicht ich noch sonst jemand hier je behauptet - das ist deine
Interpretation, die Durchdringunsschichten sind immer gefährlich und
werden es auch bleiben - aber wenn der innere Code dann Safe ist habe
ich trotzdem einen Gewinn - wenn du den nicht sehen kannst bringt es
nichts mit dir über die Vorteile zu diskutieren, oder?
MaWin O. schrieb:> Cyblord -. schrieb:>> Ja und ich habe ein KONKRETES Beispiel genannt wo ich das Problem sehe.>> Ich sehe auch bei mehrmaligem Lesen kein konkretes Beispiel. Könntest du> das noch einmal wiederholen, bitte?Beitrag "Re: Rust - ist das hier um zu bleiben?">> Cyblord -. schrieb:>> Deine Aussage war bisher dass Rust Code automatisch sicher ist.>> Jetzt lernen wir: Außer da eben da wo er nicht sicher ist.>> Dann hast du etwas gelernt, was hier nie gesagt wurde.> Rust-Code ist automatisch sicher. Punkt.
Eigentlich haben wir gerade genau das Gegenteil gelernt.
Aber dann sag mir wie Rust den Code in meinem obigen Beispiel sicher
macht. Und zwar ohne Laufzeitoverhead.
Cyblord -. schrieb:> Deine Aussage war bisher dass Rust Code automatisch sicher ist.> Jetzt lernen wir: Außer da eben da wo er nicht sicher ist. Also da wo> ich nicht einfach statisch zur Kompilierzeit prüfen kann.> Und deshalb machst du so ein Fass für Rust auf?
das hat er nie gesagt nur für die geschlossenen Teile, die nicht wenig
sind weil nicht alles in einem Kernel oder Applikation durchdringt in
jeder Zeile Code den Kernel- oder User-Space
Rust ist safe so lange du nicht in eine andere Welt wechselst - das ist
niemals eine Anforderung an Rust gewesen - wenn du darauf rumreiten
willst das du es so verstanden hast ist es eben so, aber leider keine
sinnvolle Diskussion
Cyblord -. schrieb:> Aber dann sag mir wie Rust den Code in meinem obigen Beispiel sicher> macht. Und zwar ohne Laufzeitoverhead.
gar nicht - weil es das für Durchdringunsschichten nicht kann und nicht
will - das muss du Hand anlegen - kein Pro-Rust entwickler stellt das in
frage der Gewinn ist woanders
cppbert schrieb:> das hat er nie gesagt nur für die geschlossenen Teile, die nicht wenig> sind weil nicht alles in einem Kernel oder Applikation durchdringt in> jeder Zeile Code den Kernel- oder User-Space
Liegt das an mir dass ich kein Stück von diesem Gestammel verstehen?
> Rust ist safe so lange du nicht in eine andere Welt wechselst
Andere Welt. Soso.
> - das ist> niemals eine Anforderung an Rust gewesen
Natürlich nicht. Nicht sicher in einer anderen Welt. Und nicht in der
Anders-Welt. Aber in irgendeiner Welt bestimmt.
cppbert schrieb:> der Gewinn ist woanders
Wo finde ich den Gewinn wenn mein Array an dieser Stelle überläuft? Wo
steckt hier der totale Vorteil von Rust? Irgendwo muss er doch sein.
Cyblord -. schrieb:> Aber dann sag mir wie Rust den Code in meinem obigen Beispiel sicher> macht. Und zwar ohne Laufzeitoverhead.
Das habe ich bereits erklärt.
Der Rust-Code benötigt nicht mehr Checks als gleichwertig sicherer
C-Code.
Den Index musst du ein mal ganz am Anfang prüfen. In C muss man es und
in Rust wäre es sinnvoll, wenn man keine Panics haben will.
Weitergehende Indexchecks werden vom LLVM praktisch immer
herausoptimiert, solange die Codepfade statisch verfolgbar sind.
Und wenn nicht, dann steht dir wie bereits gesagt frei in genau diesen
Sonderfällen unchecked-Zugriffe in Unsafe-Rust zu machen.
In Summe hast du immer noch einen enormen Sicherheitsgewinn.
MaWin O. schrieb:> Den Index musst du ein mal ganz am Anfang prüfen.
Anfang von was? Wenn dann muss man den Index bei JEDEM ZUGRIFF prüfen.
Wie sonst soll das gehen?
Cyblord -. schrieb:> Anfang von was? Wenn dann muss man den Index bei JEDEM ZUGRIFF prüfen.> Wie sonst soll das gehen?
Am Anfang der Callchain. Dort, wo du den Index aus den untrusted-Daten
herausgepopelt hast.
Wenn der Index einmal < len(buffer) ist, dann ist er es im weiteren
Codeverlauf auch noch. Weitere Prüfungen finden nicht statt. Auch nicht
bei Mehrfachzugriffen.
Aber selbst wenn du alle Arrayzugriffe unchecked machst, was ohne
Weiteres trivial möglich ist, dann hast du immer noch alle restlichen
Vorteile und Sicherheiten von Rust. z.B. den Borrowchecker.
Empfehlenswert ist es natürlich nicht, weil der Performancegewinn
praktisch Null ist.
Aber die Wahl liegt bei dir.
In Rust ist diese ganze Array- und Index-Popelei sowieso nur selten
notwendig. Es gibt dort deutlich einfachere und sichere Konzepte wie
z.B. Iteratoren.
MaWin O. schrieb:> Wenn der Index einmal < len(buffer) ist, dann ist er es im weiteren> Codeverlauf auch noch.
Nur verwendet man nicht dauernd den gleichen Index.
MaWin O. schrieb:> In Rust ist diese ganze Array- und Index-Popelei sowieso nur selten> notwendig. Es gibt dort deutlich einfachere und sichere Konzepte wie> z.B. Iteratoren.
Das nächste No-Go für embedded. Solche Konzepte sind für PC ja ok. Aber
sie zeigen dass Rust auf Embedded noch ganz eigene Probleme hat.
Gleiches gilt natürlich für die Systemprogrammierung. Wieder mal führt
an C kein Weg vorbei. Wenn man nicht ständig und für alles enorme
Datenstrukturen mitführen will.
Cyblord -. schrieb:> Das nächste No-Go für embedded. Solche Konzepte sind für PC ja ok. Aber> sie zeigen dass Rust auf Embedded noch ganz eigene Probleme hat.
Iteratoren sind zero-cost im Vergleich zur indexbasierten Lösung.
Cyblord -. schrieb:> Nur verwendet man nicht dauernd den gleichen Index.
Dann musst du natürlich auch in C prüfen, ob dein Index noch in bounds
ist.
Arithmetik auf indices führt gerne zu Sicherheitsbugs. Gern gehabt,
kommt immer mal wieder rein. Erheitert uns ständig in der C-Welt.
Cyblord -. schrieb:> MaWin O. schrieb:>> In Rust ist diese ganze Array- und Index-Popelei sowieso nur selten>> notwendig. Es gibt dort deutlich einfachere und sichere Konzepte wie>> z.B. Iteratoren.>> Das nächste No-Go für embedded. Solche Konzepte sind für PC ja ok. Aber> sie zeigen dass Rust auf Embedded noch ganz eigene Probleme hat.
Warum sollte das für embedded ein No-Go sein?
Langsam denke ich das du nicht sehr viel Ahnung hast - was auch deine
bisherigen Post erklären könnte
Nicht mal ein C++-Iterator ist in embedded in jeglich Form ein Problem -
weil so wie bei Rust ein Value-based Konzept
Versuch doch mal nur das Problem mit Iterator und embedded zu erklären -
vielleicht verstehen wir dann endlich mal was du nicht verstehst
Cyblord -. schrieb:> Wo finde ich den Gewinn wenn mein Array an dieser Stelle überläuft? Wo> steckt hier der totale Vorteil von Rust? Irgendwo muss er doch sein.
die Linux-Kernel Entwickler akzeptieren Rust als erste weitere
Programmiersprache neben C (nachdem C++ vor Jahren schon massiv
abgelehnt wurde) weil die so viel Langeweile habe und Linus dafür
bekannt ist immer die neusten Hype-Sprachen in den Linux Kernel
aufzunehmen
Erklär uns doch mal warum das passiert - unter der Annahme das die nicht
alle völlig bescheuert sind
cppbert schrieb:> die Linux-Kernel Entwickler akzeptieren Rust als erste weitere> Programmiersprache neben C (nachdem C++ vor Jahren schon massiv> abgelehnt wurde) weil die so viel Langeweile habe und Linus dafür> bekannt ist immer die neusten Hype-Sprachen in den Linux Kernel> aufzunehmen
Also Beweis durch Autorität? Rust ist ja wirklich ne Kirche.
Es kann zwar niemand darlegen warum man bei Embedded/µC C durch Rust
ersetzen sollte, aber 100 Linux Entwickler können sich nicht irren.
> Langsam denke ich das du nicht sehr viel Ahnung hast - was auch deine> bisherigen Post erklären könnte
Natürlich. Wer nicht fest in eurem Glauben steht, hat halt keine Ahnung.
Cyblord -. schrieb:> Es kann zwar niemand darlegen warum man bei Embedded/µC C durch Rust> ersetzen sollte
Ach troll dich doch bitte. Das ist doch keine ernsthafte Diskussion.
Cyblord -. schrieb:> Also Beweis durch Autorität? Rust ist ja wirklich ne Kirche.> ...> Natürlich. Wer nicht fest in eurem Glauben steht, hat halt keine Ahnung.
sei doch nicht so extrem - ich hab dich nett nach einer Erklärung zu dem
Iterator/embedded Problem gebeten und eine Erklärung warum Linux das
jetzt akzeptiert - beides hast du nicht beantwortet und bist dan gleich
zum Glaubenskrieg-Argument gewechselt
cppbert schrieb:> ich hab dich nett
Äh nein. Mir Ahnungslosigkeit zu unterstellen fällt nicht unter nett. Es
ist der typische Deppen-Abschluss einer Diskussion.
Cyblord -. schrieb:>> ich hab dich nett>> Äh nein. Mir Ahnungslosigkeit zu unterstellen fällt nicht unter nett. Es> ist der typische Deppen-Abschluss einer Diskussion.
Jetzt beantworte doch einfach die Frage warum das Iterator-Konzept von
Rust für embedded so untragbar ist und was die Gründe dafür sind warum
du denkst das Rust überhaupt in Linux akzeptiert wurde - ich
entschuldige mich auch dafür ein wenig ausfallend gewesen zu sein
Cyblord -. schrieb:> Mir Ahnungslosigkeit zu unterstellen fällt nicht unter nett. Es> ist der typische Deppen-Abschluss einer Diskussion.
Es war lediglich eine Feststellung aufgrund deiner Aussagen hier.
Ahnungslosigkeit zu vermuten ist da noch das Harmlose. Ich würde
stattdessen eher vorsätzliche Trollerei vermuten.
Cyblord -. schrieb:> cppbert schrieb:>> ich hab dich nett>> Äh nein. Mir Ahnungslosigkeit zu unterstellen fällt nicht unter nett. Es> ist der typische Deppen-Abschluss einer Diskussion.
das Rust-Iteratoren-Konzept einfach so (ohne jegliche Erklärung bisher)
als untragbar für embedded zu bezeichnen ist nicht ein klein-wenig
Ahnungslos?
und von Glauben und Autorität zu sprechen wenn es darum geht das der
Linux Kernel das erste mal in seiner Geschichte eine weitere Sprache
akzeptiert ist differenziert?
Machen es solche Aussagen vielleicht ungewollt einfacher ein wenig an
deiner Erfahrung zu zweifeln?
MaWin schrieb:> Rolf M. schrieb:>> Warum sollte ich beleidigt sein? Ich bin lediglich der Ansicht, dass>> seine Argumente gegen C++ ziemlich an den Haaren herbeigezogen wirken.>> Weil...?> Du lieferst wieder keine Argumente und stattdessen nur Emotion.
Nein. Du interpretierst nur in meine Postings sehr viel rein, das da
nicht steht.
> Und dann kritisierst du genau das an Linus.>> So trägst du nichts zur Diskussion bei, außer dass ich nun weiß, dass du> wohl aus unbekannten Gründen gerne C++ im Kernel hättest
Nein, das weißt du nicht, du denkst es nur. Hab ich nie gesagt. Ich hab
lediglich gesagt, dass seine Argumente dagegen nicht stichhaltig wirken.
> und irgendwie memcpy besser als memmove findest.
Zu memcpy hab ich überhaupt nichts gesagt.
> Das ist für mich eine nutzlose Information, solange du das nicht> begründest.
Natürlich ist sie nutzlos, weil falsch.
Rolf M. schrieb:> Ich hab> lediglich gesagt, dass seine Argumente dagegen nicht stichhaltig wirken.
Ja. Und eine Begründung bleibst du uns weiterhin schuldig.
Alleine darum ging es mir.
Dass dir Linus Meinung nicht passt, habe ich verstanden.
Warum das so ist, habe ich nicht verstanden.
Rolf M. schrieb:> Zu memcpy hab ich überhaupt nichts gesagt.
Ja, das habe ich dann verwechselt, weil das ein Gast war, der in genau
die gleiche Tröte wie du geblasen hat.
Sinnloses Abladen von: Määh ich finde Linus Aussage blöd.
Ok, ich habe jetzt noch einmal nachgeschaut.
Rolf M. schrieb:>> Da muss man nur anschauen, was Linus von C erwartet hat und welche>> "features" er da haben wollte. (z.B. memcpy ganz durch memmove ersetzen>> und weiterer Blödsinn)>> Nachdem ich die Gründe, die er gegen C++ im Kernel vorgebracht hat,> gelesen habe, kann ich ihn in der Hinsicht eh nicht mehr ernst nehmen.
Schon komisch, dass du genau auf die memcpy-Sache antwortest und jetzt
behauptest nie etwas dazu gesagt zu haben.
Du bist unehrlich.
MaWin schrieb:> Schon komisch, dass du genau auf die memcpy-Sache antwortest
Auf welche "Sache" hätte ich denn sonst antworten sollen? Wenn da jetzt
z.B. strlen oder was weiß ich was statt memcpy gestanden hätte, wäre
meine Antwort dieselbe gewesen. Um die konkrete Funktion ging es gar
nicht. Denk dir den Teil in den Klammern einfach weg, der ist unwichtig.
> Du bist unehrlich.
Nein, du legst es offenbar einfach darauf an, mich misszuverstehen.
Rolf M. schrieb:> Nein, du legst es offenbar einfach darauf an, mich misszuverstehen.
Wir alle zusammen legen es darauf an, das scheint hier echt
Forums-Kultur zu sein - Fehleannahmen, Empfindlichkeiten etc.
aber warum machen wir jetzt nicht einfach ein Reset und kommen wieder
aufs technische zurück und hören auf so zu "menscheln"
Tatsächlich ist doch schon längst alles gesagt worden. Mittlerweile ist
das doch längst nur noch ein Webethread für die Rust Fanatiker. Wenn ich
gekonnt hätte, hätte ich den längst geschlossen. Am Anfang hatte man
noch Vorteile, echte Nachteile & Problematische Aspekte diskutiert. Aber
das ist schon längst wieder unter den uninteressanten "alles toll, alles
sicher, schau, neue Features, schau, jetzt mehr Rust dort" Beiträgen
begraben, und wird eh von keinem mehr gelesen.
Rolf M. schrieb:> Um die konkrete Funktion ging es gar nicht.
Gut, dass wir uns dann doch einig sind.
Und wie sieht es mit einer Antwort aus?
Warum glaubst du, dass Linus nicht in der Lage ist
Grundlagenentscheidungen zu treffen?
Ich kenne Linus Entscheidungen als sehr pragmatisch und sehr
praxisorientiert.
Bei Entscheidungen über C++, memcpy und Rust und vielem mehr.
Der Erfolg gibt ihm Recht und seine Argumente sind für mich gut
nachvollziehbar.
Also nun Butter bei die Fische:
Warum kannst du ihn "eh nicht mehr ernst nehmen"?
🐧 DPA 🐧 schrieb:> "alles toll, alles> sicher, schau, neue Features, schau, jetzt mehr Rust dort"
Und wo ist das Problem?
Ich schreibe sowohl über Vor- und Nachteile von Rust.
Ich stelle hier zu 90% eh nur Unwahrheiten von Leuten, die
offensichtlich nie mit der Sprache gearbeitet haben, richtig.
> uninteressanten
Warum diskutierst du trotzdem mit?
Naja, Linus wird auch langsam alt. Klare ansagen kann er auch nicht mehr
machen, die SJW haben ihn einmal kräftig unter den Bus geworfen und so
entschärft (wobei etwas weniger erfolgreich als bei RMS). Die Maintainer
grosser Subsysteme sind auch schon etwas ausser Kontrolle, so macht z.B.
Intel immer mal wieder was, wo sie dann schnell einen Release
nachschieben müssen (letztens
https://www.phoronix.com/news/Intel-iGPU-Avoid-Linux-5.19.12, davor ging
mal plötzlich ältere FW nicht mehr, usw.) Eigentlich sollten das die
diversen Maintainerschichten vorher abfangen. Und mit Greg Kroah-Hartman
ist auch schon ein Linus-Ersatz vorhanden.
Ich denke, Linus hat die Zügel längst abgegeben.
🐧 DPA 🐧 schrieb:> Aber> das ist schon längst wieder unter den uninteressanten "alles toll, alles> sicher, schau, neue Features, schau, jetzt mehr Rust dort" Beiträgen> begraben, und wird eh von keinem mehr gelesen.
das ist schon irgendwie verständlich was du sagst - aber am Anfang hiess
es immer das wird nichts weil es kein GCC Frontend dafür gibt, und weil
es eh nicht relevant wird, keine Standard existiert, und das es auch gar
niemand braucht weil C++ das schon alles perfekt kann und,und,und
jetzt zieht Rust als erste weitere Sprachen in den Linux-Kernel ein (von
dem wir denke ich alles wissen wie gross, relevant der ist und auch wie
viele Entwickler daran arbeiten) und schon ist irgendwie klar das es die
Linux-Kernel-Entwickler es auch nicht blicken - und das Microsoft und
google usw. nachziehen ist ja auch nur eine allgem. blöde Idee weil die
ihren Kram nicht unter Kontrolle bringen - aber komischerweise sind das
die Zugpferde für alle C++ Sachen die in den letzten 15 Jahren gemacht
wurden (pushen des C++ Standards, Sanitizer und und und)
keiner sagt das Rust die Lösung aller Problem zu 100% ist (und das hat
MaWin auch noch nie so global für alle Kontexte vermittel)
aber zumindest eine nette Disukssion-Grundlage könnte es sein
und dann kommen hier die Python, Javascript, C und C++ Entwickler und
lassen sich (oft) ohne Background über irgendwelche Details aus und alle
werden irgendwie sehr schnell sehr emotional - warum auch immer
🐧 DPA 🐧 schrieb:> Und mit Greg Kroah-Hartman> ist auch schon ein Linus-Ersatz vorhanden.
aber der supportet doch auch pro-aktiv die Rust intergration - hat eines
der ersten Linux-Beispiele mit dem Integrator entwickelt - also i don't
care Linus, aber Greg hat schon viel früher mit Rust angefangen - so
what?
und niemand hier ist so dumm zu glaube das ein schneller Einzug oder die
Nutzung von Rust von mehreren Big-Playern irgendeine Qualitäts oder
Perfektions-Relevanz hat, da geht es nur darum das sowas wie mit dem
Linux-Kernel bisher einfach noch nie passiert ist und das entweder ein
riesen Fehler ist oder eben eine sinnvolle Entscheidung - als
Echtwelt-Gegenargument zu der ganzen Es-ist-perfekt-wie-es-ist-Fraktion
cppbert schrieb:> aber der supportet doch auch pro-aktiv die Rust intergration
Ja eben. Ich sag ja:
🐧 DPA 🐧 schrieb:> Ich denke, Linus hat die Zügel längst abgegeben.
DPA schrieb:> cppbert schrieb:>> aber der supportet doch auch pro-aktiv die Rust intergration>> Ja eben. Ich sag ja:>> 🐧 DPA 🐧 schrieb:>> Ich denke, Linus hat die Zügel längst abgegeben.
das stimmt auch nicht weil er ist auch sehr aktiv an der Integration
beteiligt und freut sich ja (laut der letzten Keynote) darauf die Syntax
zu lernen und richtig damit zu arbeiten (und das wird er - weil wir ihn
kennen, er ist kein Man der leeren Worte, war er nie)
cppbert schrieb:> das stimmt auch nicht weil er ist auch sehr aktiv an der Integration> beteiligt und freut sich ja (laut der letzten Keynote) darauf die Syntax> zu lernen und richtig damit zu arbeiten (und das wird er - weil wir ihn> kennen, er ist kein Man der leeren Worte, war er nie)
Das klingt als wenn die KP eine Pressemitteilung über Xi rausbringt.
Oder in Nord-Korea über Kim geredet wird.
Cyblord -. schrieb:> cppbert schrieb:>> das stimmt auch nicht weil er ist auch sehr aktiv an der Integration>> beteiligt und freut sich ja (laut der letzten Keynote) darauf die Syntax>> zu lernen und richtig damit zu arbeiten (und das wird er - weil wir ihn>> kennen, er ist kein Man der leeren Worte, war er nie)>> Das klingt als wenn die KP eine Pressemitteilung über Xi rausbringt.> Oder in Nord-Korea über Kim geredet wird.
ja schon - aber es ist doch trotzdem Realität das die beiden führenden
Köpfe der Linux-Entwicklung das machen und google, Amazon und andere
grosse das aktiv mit tragen - ich nehme einfach an das dir klar ist wie
stark die grossen 5 von einem funktionierendem Linux abhängig sind
btw: du hast immer noch nicht erklärt warum das Rust Iteratoren Konzept
eine No-go für embedded ist - wird langsam Zeit
Am Anfang des Threads, 2019, war die Frage:
> Rust - ist das hier um zu bleiben?
Damals war Rust noch in so gut wie keinem relevanten Produkt vertreten.
Viele Sachen waren unklar. Viele Features fehlten.
Heute, 2022, würde ich sagen:
> Rust - Das ist hier um zu bleiben!
Heute sind immer noch viele Sachen unklar. Viele Features fehlen immer
noch.
Aber es hat sich enorm was getan.
Viele Fragen wurden geklärt und viele Features wurden hinzugefügt. Man
hat begonnen an einer Referenzdoku zu arbeiten. Alternative Compiler
nähern sich rasant dem praktischen Nutzen. Rust auf Embedded
funktioniert einfach mittlerweile (mit unstable compilern). Etc, etc...
Und politisch ist Rust von vielen Firmen und großen Projekten als gute
Alternative anerkannt und wird aktiv genutzt. Diese Akzeptanz breitet
sich immer weiter aus und ist selbstverstärkend.
Hinter Rust steht ein ganz anderes Moment als hinter all den anderen
neuen Sprachen der letzten 20 Jahre. Das liegt natürlich auch daran,
dass Rust viele der guten Features der Sprachen der letzten 20 Jahre
vereinen konnte. Das liegt aber auch daran, dass Rust Dinge kann, die
andere Sprachen nicht können und wahrscheinlich auch nie können werden.
Und das Allerbeste: Wenn ihr Rust scheiße findet und es nicht verwenden
wollt, dann verwendet es einfach nicht. So einfach ist das tatsächlich.
Es gibt gar keinen Grund hier wild herumzuspekulieren und dabei seine
eigene völlige Unkenntnis komplett preiszugeben.
Ihr merkt das natürlich selbst nicht. Das ist klar.
Während ihr euch dann weiterhin mit C eure Bufferoverflows
implementiert, habe ich stattdessen Spaß mit Rust.
Denn Rust macht tatsächlich Spaß. Und ich muss zugeben, dass ich das
vorher auch nicht gedacht hätte.
Irgendwann wird Rust von einer noch besseren Sprache abgelöst werden.
Und da freue ich mich jetzt schon drauf.
MaWin O. schrieb:> Genau. Zum Glück kann man in Rust ja immer memcpy nutzen, weil es kein> Aliasing gibt. Man hat also immer den Performancevorteil.
Bei aliasing geht es ja nur darum, dass man nicht mit einem
Pointer/Referenz auf Speicher schreibt, und mit einem anderen Pointer im
selben Scope das selbe dann wieder liest, oder? Aliasing wäre dann eine
etwas schwächere Garantie, als dass 2 Pointer nicht auf den selben
Speicherbereich zeigen.
In C verarbeite ich buffer manchmal inplace, nach dem Schema:
1
inti_in,i_out;
2
for(i_in=0,i_out=0;i_out<length;i_in++){
3
unsignedcharch=buffer[i_in];
4
...
5
if(bla)buffer[i_out++]=123;
6
}
7
length=i_out;
Sprich, i_in wird bei jedem Durchlauf inkrementiert, i_out aber nicht
(und auch höchstens einmal), damit ist immer i_in <= i_out garantiert,
und es ist sichergestellt, dass beim schreiben nach buffer[i_out] nie
etwas überschrieben wird, was danach mit i_in gelesen wird. Das müsste
also eigentlich statisch erkennbar sein.
Das ist recht nützlich, z.B. beim dekodieren von Hex zu Binär, aber auch
bei base64 kann man es machen. (Das habe ich erst letztens mal wieder
gemacht
https://github.com/Daniel-Abrecht/ml666/blob/ml666/src/json-token-emmiter.c#L151-L200
(da sollte ich eventuell noch ein par "restrict" keywords reinwerfen).
Kann man dieses Pattern, diesen Konstraint, in safe Rust bereits
effektiv abdecken, oder muss man da Speicher verschwenden?
> Kann man dieses Pattern, diesen Konstraint, in safe Rust bereits> effektiv abdecken, oder muss man da Speicher verschwenden?
Bei allem was wir hier inzwischen über Rust lesen, solltest du Speicher
im Überfluss haben.
In-Place kann da gar nichts gehen. Temporäres rumkopieren von Daten
(bezüglich Laufzeit gratis natürlich) und anlegen von massiven
Datenstrukturen (bezüglich Speicher gratis) für jeden Pups ist da mal
default. Da passt dann die Empfehlung für memmove schon exakt ins Bild.
Cyblord -. schrieb:> Bei allem was wir hier inzwischen über Rust lesen, solltest du Speicher> im Überfluss haben.
das sagt absolut niemand (keine Ahnung wo du das gelesen hast) -
Move-Semantic ist bei Rust der Default (im gegensatz zu C/C++ wo Kopie
der Defaul ist) - kopiert wird da recht wenig und ein grosses Ziele ist
Resourcen-Vebrauch auf C Niveau oder besser
btw: du hast immer noch nicht erklärt warum das Rust Iteratoren Konzept
eine No-go für embedded ist - wird langsam wirklich Zeit
🐧 DPA 🐧 schrieb:> Bei aliasing geht es ja nur darum, dass man nicht mit einem> Pointer/Referenz auf Speicher schreibt, und mit einem anderen Pointer im> selben Scope das selbe dann wieder liest, oder?
Aliasing Probleme sind auch
std::vector<int> v{1,2}
int* a = &v[0];
v.push(20);
v.push(30);
v.push(40);
v.push(50);
-> wegen copy-on-resize im std::vector is a relativ sicher dangling
passiert aber genau so mit realloc in C
Cyblord -. schrieb:> Da passt dann die Empfehlung für memmove schon exakt ins Bild.
das war von Linus für den Linux-Kernel, für den C code, null Bezug zu
Rust
cppbert schrieb:> das war von Linus für den Linux-Kernel, für den C code, null Bezug zu> Rust
Aber hallo, von DEM Linus der jetzt doch voll auf Rust abfährt.
Außerdem geht es eben um das Mindset hinter so einer Empfehlung. Da ist
die Sprache egal.
Cyblord -. schrieb:> cppbert schrieb:>> das war von Linus für den Linux-Kernel, für den C code, null Bezug zu>> Rust>> Aber hallo, von DEM Linus der jetzt doch voll auf Rust abfährt.> Außerdem geht es eben um das Mindset hinter so einer Empfehlung. Da ist> die Sprache egal.
du hast immer noch nicht erklärt warum das Rust Iteratoren Konzept
eine No-go für embedded ist - brauchst du vielleicht noch ein bisschen
mehr Zeit?
🐧 DPA 🐧 schrieb:> int i_in, i_out;> for(i_in=0,i_out=0; i_out < length; i_in++){> unsigned char ch = buffer[i_in];> ...> if(bla) buffer[i_out++] = 123;> }> length = i_out;
ich sehe da keine Probleme mit Rust, wo sind da Aliasing Probleme?
In dem Beispiel ist doch alles nur Value-based, keine Pointer die
irgendwie invalidieren
Mit i_in und i_out lese / schreibe ich vom selben buffer. Man könnte die
quasi als 2 Pointer im selben Scope betrachten. Dennoch ist
sichergestellt, dass ich nie mit dem einen das lese, was ich mit dem
anderen schreibe.
Die Sache ist also punkto aliasing komplett sicher, aber ich weiss
nicht, wie man das mit safe Rust macht / abbildet (oder ob das überhaupt
geht). Da fehlt mir etwas die Erfahrung. Aber vielleicht kann es ja
jemand mit dieser Erfahrung hier übersetzen, sofern es möglich ist?
die unterstriche vor _main und _ch sind nur dazu da um die unused-value
warnung zu unterdrücken
Rust schützt dich nicht davor das dein Algorithmus jetzt kreuz und quer
in deinem Array rumschreibt - nur das andere abhängigkeiten - andere
Funktionen ausserhalb einen Zustand erwarten können, Rust versucht nicht
deinen Algorithmus irgendwie zu validieren oder sonstige - falls das
hier die Frage ist
DPA schrieb:> Interressant. Dann sind gewisse Formen von Aliasing ja doch möglich.
Rust ist 100% sicher, außer in den Welten in denen es nicht sicher ist.
🐧 DPA 🐧 schrieb:> Sprich, i_in wird bei jedem Durchlauf inkrementiert, i_out aber nicht> (und auch höchstens einmal), damit ist immer i_in <= i_out garantiert,> und es ist sichergestellt, dass beim schreiben nach buffer[i_out] nie> etwas überschrieben wird, was danach mit i_in gelesen wird. Das müsste> also eigentlich statisch erkennbar sein.
Mit Indexen gibt es eh kein Aliasing. Weder in C noch in Rust.
🐧 DPA 🐧 schrieb:> Kann man dieses Pattern, diesen Konstraint, in safe Rust bereits> effektiv abdecken
Klar.
Cyblord -. schrieb:> Bei allem was wir hier inzwischen über Rust lesen, solltest du Speicher> im Überfluss haben.> In-Place kann da gar nichts gehen.
Kompletter Unsinn. Das ist genau wieder so ein Beitrag, wo du dich als
komplett ahnungslos im Bezug auf Rust outest. "kann gar nicht gehen".
Soso.
Wieso fragst du nicht stattdessen "kann das gehen?"? Falsches als Fakt
hinzustellen und dann beleidigt sein wenn man korrigiert wird, das ist
das größte Problem an diesem Thread.
In-Place hat überhaupt gar nichts mit Aliasing zu tun.
Wenn man eine mutable-Referenz hat, kann man damit natürlich machen, was
man will. Lesen, Schreiben, in beliebiger Reihenfolge auf beliebigen
Indexen.
Cyblord -. schrieb:> Außerdem geht es eben um das Mindset hinter so einer Empfehlung.
Was meinst du damit?
🐧 DPA 🐧 schrieb:> Die Sache ist also punkto aliasing komplett sicher, aber ich weiss> nicht, wie man das mit safe Rust macht / abbildet
Ziemlich ganz genau so, wie du es auch in C schreibst.
Das unterscheidet sich nur syntaktisch minimalst und
logisch/algorithmisch überhaupt nicht.
🐧 DPA 🐧 schrieb:> Man könnte die quasi als 2 Pointer im selben Scope betrachten
Es sind aber keine 2 Pointer. Und es sind keine 2 Referenzen.
In Rust gibt es eine ganz klare Unterscheidung zwischen Referenzen und
Indexen.
In Rust gibt es keine schwammigen Linien zwischen Pointern, Referenzen,
Arrays, Indexen.
Das sind vier völlig verschiedene Datentypen, zwischen denen explizit
konvertiert werde muss, wenn das denn gewünscht ist. In der Regel ist
das aber nicht notwenig oder sogar unsafe.
Sowas wie Arrays, die in Pointer zerfallen oder Indexzugriffe, die
eigentlich nur Syntaxzucker für Pointerarithmetik sind gibt es in Rust
gar nicht. Indexzugriffe sind Indexzugriffe über die ganz klar
definierten Index und IndexMut Traits.
Cyblord -. schrieb:> DPA schrieb:>> Interressant. Dann sind gewisse Formen von Aliasing ja doch möglich.
Nein. Indexe sind keine Aliase.
https://doc.rust-lang.org/std/ops/trait.Index.htmlhttps://doc.rust-lang.org/std/ops/trait.IndexMut.html
Indexe operieren auf einer Referenz (im Trait self genannt).
Diese Referenz darf und kann keinen Alias haben, wenn sie mutable ist.
Das wird vom Compiler statisch forciert.
> Rust ist 100% sicher, außer in den Welten in denen es nicht sicher ist.
Oder wenn du wieder einmal etwas nicht verstanden hast.
Safe-Rust ist 100% memory safe. Immer.
Logisch sind die Konzepte aber äquivalent, unabhängig von der
Programmiersprache. Ob ich 2 Pointer oder 2 Indexe habe, im moment des
Zugriffs wird genau die selbe Stelle geladen / geschrieben.
Damit lässt sich dann in Rust auch ein logisches äquivalent zu memmove
abbilden, halt dann mit Indexen, statt Pointern.
Cyblord -. schrieb:>> 100% memory safe> Gibts dafür ne Definition?
Findest du sicher in der Rust-Referenz.
Darunter fallen: Kein UB, kein Use-After-Free und keine Data Races.
DPA schrieb:> Logisch sind die Konzepte aber äquivalent
In diesem Fall schon. Ja. Wenn man in C denkt.
> unabhängig von der> Programmiersprache. Ob ich 2 Pointer oder 2 Indexe habe, im moment des> Zugriffs wird genau die selbe Stelle geladen / geschrieben.
Das ist halt die C-Denkweise. In Safe-Rust gibt es gar keine
Pointerarithmetik. (Ja ja, Arithmetik gibts schon, aber man kann das
Ergebnis nicht dereferenzieren).
Somit erübrigt sich die Frage in Rust, ob Pointerarithmetik das gleiche
wäre wie Indexarithmetik. Diese Frage kann man wenn dann überhaupt nur
in Unsafe-Rust stellen und beantworten.
DPA schrieb:> Damit lässt sich dann in Rust auch ein logisches äquivalent zu memmove> abbilden, halt dann mit Indexen, statt Pointern.
Ein äquivalent zu memmove ist, wie mehrfach schon gesagt, in Rust
überhaupt gar nicht notwendig. Rust kopiert alles mit memcpy, weil es
kein Aliasing gibt. (Kein mutable Aliasing. Aliasing auf Immutables gibt
es natürlich. Aber da kann halt auch niemand drauf schreiben).
Und ob du jetzt deinen InPlace-Algorithmus oder etwas anderes schreibst,
das hat doch gar nichts mit memmove zu tun.
Ein InPlace-Algorithmus hat doch per Definition immer nur ein Ownership.
Also auch nur eine mutable-Referenz. Zwei Mutable-Referenzen gehen in
Rust nicht. Aber die braucht man auch gar nicht. (Auch nicht in C.)
Irgendwie kommt es mir vor, als würden wir da aneinander vorbei reden.
MaWin schrieb:>> Logisch sind die Konzepte aber äquivalent>> In diesem Fall schon. Ja. Wenn man in C denkt.>>> unabhängig von der>> Programmiersprache. Ob ich 2 Pointer oder 2 Indexe habe, im moment des>> Zugriffs wird genau die selbe Stelle geladen / geschrieben.>> Das ist halt die C-Denkweise. In Safe-Rust gibt es gar keine> Pointerarithmetik. (Ja ja, Arithmetik gibts schon, aber man kann das> Ergebnis nicht dereferenzieren).
Am Ende wird alles zu ASM Code und da gibts dann wieder direkte (und
indirekte) Pointer auf den Speicher. Also was soll so ein Geschwätz?
Das ist keine "C Sicht", das ist die scheiß Realität.
MaWin schrieb:>>> 100% memory safe>> Gibts dafür ne Definition?>> Findest du sicher in der Rust-Referenz.
Du hast mich falsch verstanden. Wenn du sagst, Rust ist 100% Memory
Safe, dann muss du doch eine Liste von Konzepten im Kopf haben, welche
für dich die 100% darstellen. Und Rust deckt sich damit.
Aber du behauptest jetzt, genau das Set welches Rust bietet, entspricht
100%? Per welcher Definition?
MaWin schrieb:> Das ist halt die C-Denkweise. In Safe-Rust gibt es gar keine> Pointerarithmetik.
Nein, mein Argument ist ein rein logisches. Welche Terminologie oder
Semantik Rust oder C dort verwenden, ist irrelevant.
Der Rest mag ja alles stimmen. Aber fundamental logisch betrachtet, ist
und bleibt es ein spezieller Fall von erlaubtem Aliasing. Auch wenn die
Rust läute das nicht so nennen und nicht wahr haben wollen.
PS: Klar, das ist hier sinnvoll (also ein feature, kein bug), und mit
vernachlässigbaren negativen Implikationen. Es geht mir hier um logische
Konsistenz bei der Betrachtung & Argumentation über des Systems, und
nicht darum, ein praktisches Problem heraufzubeschwören, wo keines ist.
Cyblord -. schrieb:> Am Ende wird alles zu ASM Code und da gibts dann wieder direkte (und> indirekte) Pointer auf den Speicher.> Also was soll so ein Geschwätz?
Es zeigt sehr schön, dass du keine Ahnung davon hast, wie Sprachen
definiert sind.
Rust arbeitet, genau wie C auch, auf Basis eines virtuellen
Maschinenmodell. In welches asm das dann irgendwann einmal übersetzt
wird, spielt überhaupt keine Rolle. Weder in Rust, noch in C.
Es ist Rust als Sprache völlig egal, ob das Backend das Programm in Code
für Maschinen mit oder ohne Pointer übersetzt. (Ja, ich weiß, dass es da
cornercases gibt. (vgl. Cheri-Architektur). Aber keine dieser
Cornercases führen zu UB oder Verlust von Rust-Garantien. Und daran wird
gearbeitet.)
Erst nachdem Rust seine Sicherheitsgarantien statisch geprüft hat, wird
die Kontrolle an LLVM übergeben. Dieser generiert dann irgendwann Code
draus. Mit Rust hat das aber nichts mehr zu tun.
Die paar wenigen verbliebenen Sicherheitsgarantien, die Rust nicht
statisch prüfen kann, resultieren dann in entsprechendem asm-Code, der
zur Laufzeit die Dinge prüft.
[Linus ist gegen C++ im Kernel aber für Rust]
Der Grund dafür ist doch relativ einfach: Linus war schon immer ein
Assembler Hacker und hat halt irgendwann (pragmatisch) C als Assembler
Ersatz akzeptiert. Er denkt aber immer noch als Assembler Hacker, d.h.
bei Änderungen in C sieht er relativ schnell den Assembler Code, den den
Compiler generiert, vor sich. Das kann er (und auch viele andere C
Hacker) bei C++ nicht mehr so gut. C++ ist standardisiert, mit einem
Zulassen von C++ wurden die ganzen teilweise obskur wirkenden C++
Formulierungen in den Kernel Einzug halten. Die Schnittmenge sehr guter
Kernel Hacker und sehr guter C++ Programmierer ist nicht so groß. Wer
soll denn verantwortungsvoll den neuen C++ Code im Kernel reviewen? Die
"alte" Kernel-Hacker-Gilde eher nicht.
Einzelne C++ Features auszuschließen würde die Sache nicht besser
machen, würde wohl in einem größeren Krieg enden. Aber ein paar Features
wird man ausschließen müssen...
Nun ist aber Linus pragmatisch genug, um zu sehen, dass der Kernel auch
eine Weiterentwicklung in Bezug auf Programmiersprache braucht. Rust hat
dabei gegenüber C++ ein paar pragmatische Vorteile
a) bringt Sprachfeatures mit, die gut in den Bereich Betriebssystem
passen
b) gleichzeitig klein genug, um es in vernünftiger Zeit zu lernen
c) Weit genug weg von C um keinen C/C++ Mischmasch entstehen zu lassen
d) gleichzeitig neu genug, um noch Einfluss auf die Sprachkonzepte zu
nehmen um diese sinnvoll für Systemprogrammierung/Embedded zu entwickeln
e) Es gibt kaum Linux-Rust-Hacker, die Linus/die ganzen alten Linux
Hacker zeigen würden, dass er bei Rust keine Ahnung hat bzw. es ist zzt.
noch kein Problem, wenn ein "gestandener" Programmierer wenig Ahnung von
Rust hat.
f) Geht die Sache mit Rust schief, kann man zur Not Rust besser als C++
wieder loswerden.
Cyblord -. schrieb:> Per welcher Definition?
Der Rust-Definition. Ich habe jetzt echt keine Lust für dich zu googlen.
🐧 DPA 🐧 schrieb:> ist und bleibt es ein spezieller Fall von erlaubtem Aliasing.
Das ist und bleibt Quatsch. Sowohl in C als auch in Rust.
Aliasing ist ein Konzept, das auf Typebene stattfindet. Indexierung ist
ein Konzept, das auf Typ und auf Codeebene stattfindet.
In Rust sind Typ- und Codeebene viel besser getrennt als in C.
Eine Referenz ist kein Pointer.
Ein Pointer ist keine Adresse.
Eine Adresse ist keine Zahl (sieht man bei Cheri schön).
Ein Index hat mit Pointertypen und Referenztypen gar nichts zu tun.
Ein Index ist eine Zahl.
Das sind alles unterschiedliche Konzepte, die C vermischt und Rust aber
(fast) alle strikt voneinander trennt.
Mehr kann ich dazu leider nicht mehr sagen.
Es ist simpel. Der Zugriff auf etwas braucht eine Referenz im
allgemeinen sinne irgendwelcher Form darauf. Ob das ein Handle, ein
Pointer, oder eine Kombination davon ist, ist da erstmal egal. Hat man
es mit 2 Referenzen zutun, die auf das selbe verweisen, und man auf
diese zugreift, hat man es mit aliasing im allgemeinen sinne zutun.
Es ist sinvoll, solche Konzepte verallgemeinert (unabhängig einer
konkreten Sprache) betrachtet zu können, um Sprachunabhängig logische
Überlegungen zu Situationen, welche diese involvieren, machen zu können.
Und das hat hier ja auch sehr gut funktioniert. Jetzt kennen wir den
gesamten Sachverhalt in Bezug auf Rust viel genauer, inklusive wie Rust
diesen betrachtet.
🐧 DPA 🐧 schrieb:> Es ist simpel. Der Zugriff auf etwas braucht eine Referenz im> allgemeinen sinne irgendwelcher Form darauf. Ob das ein Handle, ein> Pointer, oder eine Kombination davon ist, ist da erstmal egal. Hat man> es mit 2 Referenzen zutun, die auf das selbe verweisen, und man auf> diese zugreift,
Korrekt.
Wenn man einen Pointer hat und mit zwei unterschiedlichen Indexe auf
unterschiedliche Elemente zugreift, dann sind das unterschiedliche
Elemente. Also kein Aliasing.
Auch in C nicht.
Verstehst du es nun?
Die Kombination Pointer + Index ist in den 2 Stellen als eine Referenz
auf etwas im allgemeinen Sinne zu betrachten. Es spielt keine rolle, ob
Rust oder C das als Aliasing bezeichnen. Im allgemeinen sinne ist es
aber genau das.
Cyblord -. schrieb:> DPA schrieb:>> Interressant. Dann sind gewisse Formen von Aliasing ja doch möglich.>> Rust ist 100% sicher, außer in den Welten in denen es nicht sicher ist.
du hast immer noch nicht beschreiben warum das Rust Iterator-Konzept ein
No-go für embedded ist
langsam denke ich schon das du recht anhnungslos bis, oder einfach nicht
in der Lage bist gemachte Statements zu begründen
Ohne ein allgemeines Konzept von Aliasing wäre es nicht möglich, darüber
unabhängig von der Programmiersprache nachzudenken, und diese zu
vergleichen. Programmiersprachen verwenden und benennen die selben sowie
die verschiedensten Konzepte und Variationen davon, ziemlich beliebig.
Es ist ziemlich einschränkend, wenn man nichts unabhängig von der
Sprache konzeptualisieren kann/darf.
🐧 DPA 🐧 schrieb:> Ohne ein allgemeines Konzept
Ja. DPA. Du hast Recht. In allen Punkten.
Nach deiner Definition gibt es Aliasing in Rust. Nach deiner Definition
gibt es alles, was du zurechtdefinierst in Rust.
Ist das nun ausreichend, damit du mit dem Unfug aufhörst?
// mache etwas mit den beiden Handles in der µC.net Personendatenbank.
4
db.machewas(person1, person2);
Nach DPA's "allgemeinen Aliasing-Definition" wäre das also Aliasing.
Schön.
Bringt leider niemandem was.
Leider komplett nutzlos in der Diskussion.
Komplett nutzlos bei der Betrachtung und Analyse von Aliasing (wie der
Rest der Welt es versteht) in Typsystemen.
Aber schön, dass wir nun auch DPA's Definition von Aliasing kennen.
MaWin schrieb:> Aber schön, dass wir nun auch DPA's Definition von Aliasing kennen.
Ich glaube DPA driftet gerade zur guten Seite der Macht (mit ein wenig
unklaren Aussagen, aber er versuchts) - bisschen weniger agro reicht
auch
🐧 DPA 🐧 schrieb:> Es spielt keine rolle, ob> Rust oder C das als Aliasing bezeichnen. Im allgemeinen sinne ist es> aber genau das.
Aliasing ist ein Sprachkonzept - das kann jede Sprache für sich
definieren oder nicht - das ist kein allgmeines Hardwarekonzept - oder
hab deine Aussage falsch verstanden?
MaWin schrieb:> Nach DPA's "allgemeinen Aliasing-Definition" wäre das also Aliasing.
Das hängt in dem konkreten Beispiel von der Implementierung, und davon
was "machewas" macht, ab. Oder zumindest würde es das dann, wenn man
darauf zugriffe, aber in dem Beispiel weiss man das ja nicht. Angenommen
es handelt sich um Rust (der selbe Code ist auch in ein paar anderen
Sprachen, z.B. JS gültig), wäre es aber immerhin nicht mut (in rust
Terminologie), immerhin weiss man also, das da nicht reingeschrieben
wird, womit das ganze dann in dem Beispiel auch wieder keine grosse
Rolle mehr spielen dürfte.
🐧 DPA 🐧 schrieb:> MaWin schrieb:>> Nach DPA's "allgemeinen Aliasing-Definition" wäre das also Aliasing.>> Das hängt in dem konkreten Beispiel von der Implementierung, und davon> was "machewas" macht, ab. Oder zumindest würde es das dann, wenn man> darauf zugriffe, aber in dem Beispiel weiss man das ja nicht. Angenommen> es handelt sich um Rust (der selbe Code ist auch in ein paar anderen> Sprachen, z.B. JS gültig), wäre es aber immerhin nicht mut (in rust> Terminologie), immerhin weiss man also, das da nicht reingeschrieben> wird, womit das ganze dann in dem Beispiel auch wieder keine grosse> Rolle mehr spielen dürfte.
Was möchtest du uns sagen? dein genanntes Beispiel ist in allen Sprachen
die C/JS/Rust/Java/C#-Artig sind Aliasing frei - geht es hier immer noch
um Aliasing?
cppbert schrieb:> 🐧 DPA 🐧 schrieb:>> Es spielt keine rolle, ob>> Rust oder C das als Aliasing bezeichnen. Im allgemeinen sinne ist es>> aber genau das.>> Aliasing ist ein Sprachkonzept - das kann jede Sprache für sich> definieren oder nicht - das ist kein allgmeines Hardwarekonzept - oder> hab deine Aussage falsch verstanden?
Das Aliasing Konzept dient dazu, über Dinge Rückschlüsse ziehen zu
können, wie z.B. ob der Compiler lese / schreibzugriffe umsortieren und
wegoptimieren kann, ohne das Verhalten zu ändern. Aber es ist auch
nützlich, um über Situationen argumentieren zu können, wo gleichwertige
Referenzen ungültig werden. Unter diesen Gesichtspunkten kann man
Aliasing verallgemeinert betrachten & definieren, als rein abstraktes
Konzept. Man muss nur schauen, worauf kommt es tatsächlich an? Es ergibt
sich dann quasi von selbst.
cppbert schrieb:> Was möchtest du uns sagen? dein genanntes Beispiel ist in allen Sprachen> die C/JS/Rust/Java/C#-Artig sind Aliasing frei - geht es hier immer noch> um Aliasing?
In dem Beispiel von MaWin gibt es diverse Compiler, die die Strings
zusammenfassen, weil sie die selben sind. Unter diesen umständen könnten
die 2 Referenzen sich auf das selbe Objekt beziehen, und es gibt fälle,
wo das relevant ist.
🐧 DPA 🐧 schrieb:> cppbert schrieb:>> 🐧 DPA 🐧 schrieb:>>> Es spielt keine rolle, ob>>> Rust oder C das als Aliasing bezeichnen. Im allgemeinen sinne ist es>>> aber genau das.>>>> Aliasing ist ein Sprachkonzept - das kann jede Sprache für sich>> definieren oder nicht - das ist kein allgmeines Hardwarekonzept - oder>> hab deine Aussage falsch verstanden?>> Das Aliasing Konzept dient dazu, über Dinge Rückschlüsse ziehen zu> können, wie z.B. ob der Compiler lese / schreibzugriffe umsortieren und> wegoptimieren kann, ohne das Verhalten zu ändern. Aber es ist auch> nützlich, um über Situationen argumentieren zu können, wo gleichwertige> Referenzen ungültig werden. Unter diesen Gesichtspunkten kann man> Aliasing verallgemeinert betrachten & definieren, als rein abstraktes> Konzept. Man muss nur schauen, worauf kommt es tatsächlich an? Es ergibt> sich dann quasi von selbst.
das ist bekannt, wer es noch nicht weiß der kann:
https://en.wikipedia.org/wiki/Aliasing_(computing) durchlesen
> cppbert schrieb:>> Was möchtest du uns sagen? dein genanntes Beispiel ist in allen Sprachen>> die C/JS/Rust/Java/C#-Artig sind Aliasing frei - geht es hier immer noch>> um Aliasing?> In dem Beispiel von MaWin gibt es diverse Compiler, die die Strings> zusammenfassen, weil sie die selben sind. Unter diesen umständen könnten> die 2 Referenzen sich auf das selbe Objekt beziehen, und es gibt fälle,> wo das relevant ist.
das würden (manche Compiler) nur dann machen wenn die imutable sind -
dann gibt es auch kein schreiben und daher auch kein Konfliktpotenzial
cppbert schrieb:> das würden (manche Compiler) nur dann machen wenn die imutable sind -> dann gibt es auch kein schreiben und daher auch kein Konfliktpotenzial
Das ist bei rust der Default. Wobei ich nicht weiss, ob rust Compiler
die Strings zusammenfassen, und ich auch nicht weiss, ob Rust das
definiert oder nicht.
Ein fall, wo so etwas aber Konfliktpotenzial bietet, ist bei
Vergleichen. Falls die Sprache eine Möglichkeit bietet, Referenzen zu
vergleichen, und die in dem fall dann gleich wären. Wenn diese
Voraussetzungen gegeben sind, kann man gewisse Fehler machen.
🐧 DPA 🐧 schrieb:> cppbert schrieb:>> das würden (manche Compiler) nur dann machen wenn die imutable sind ->> dann gibt es auch kein schreiben und daher auch kein Konfliktpotenzial>> Das ist bei rust der Default.
weil die beiden immutable sind
> Wobei ich nicht weiss, ob rust Compiler> die Strings zusammenfassen, und ich auch nicht weiss, ob Rust das> definiert oder nicht.
also weisst du irgendwie gar nichts genaues dazu :)
> Ein fall, wo so etwas aber Konfliktpotenzial bietet, ist bei> Vergleichen. Falls die Sprache eine Möglichkeit bietet, Referenzen zu> vergleichen, und die in dem fall dann gleich wären. Wenn diese> Voraussetzungen gegeben sind, kann man gewisse Fehler machen.
das klingt so als vermutest du eine Lücke im Rust Konzept, oder
driften wir gerade in ein anderes Thema?
cppbert schrieb:> das klingt so als vermutest du eine Lücke im Rust Konzept, oder> driften wir gerade in ein anderes Thema?
Nein, Rust wird das schon richtig machen. Das ist nur einfach eine
Allgemeine Sichtweise, wie ich solche Sachen betrachte, und wie ich über
solche Dinge generell nachdenke.
Vielleicht kommt das wirklich auch ein wenig vom Arbeiten mit C. Da muss
man, neben der Sprachsyntax, Semantik, usw. auch diese allgemeinen
Konzepte alle immer im Überblick haben, sonst kann man dort Fehler
machen. Im Umkehrschluss hiesse das dann, dass wen Rust einem dies
abnimmt, ... Aber öffnen wie diese Büchse der Pandora mal lieber nicht.
🐧 DPA 🐧 schrieb:> cppbert schrieb:>> das klingt so als vermutest du eine Lücke im Rust Konzept, oder>> driften wir gerade in ein anderes Thema?>> Nein, Rust wird das schon richtig machen. Das ist nur einfach eine> Allgemeine Sichtweise, wie ich solche Sachen betrachte, und wie ich über> solche Dinge generell nachdenke.
Jetzt wirst du zu esotherisch... oder besser gesagt du verwässerst deine
Klarheit
das ist hier auch oft das Problem: Konkrekte, kleine Themen werden nicht
auf ihrem Level diskutiert und dann fängt irgendwann so eine allgmeine.
Sprachdesign-Welle an und am Ende gibt es kein Ergebnis - bis MaWin
irgendeine Neuigkeit einstellt und dann geht das wieder von vorne los :)
🐧 DPA 🐧 schrieb:> Das hängt in dem konkreten Beispiel von der Implementierung, und davon> was "machewas" macht, ab.
Ah. Komisch. Eben war es noch möglich eine allgemeine Definition zu
haben. Plötzlich ist sie nicht mehr allgemein.
Du hast völlig Recht, dass es von der Sprache abhängt.
Dann lasse mich das mal etwas präziser formulieren: Ein
Pointer-Aliasing, wie es C definiert, gibt es in Rust für
mutable-Referenzen nicht.
Würdest du da mitgehen?
🐧 DPA 🐧 schrieb:> Ein fall, wo so etwas aber Konfliktpotenzial bietet, ist bei> Vergleichen. Falls die Sprache eine Möglichkeit bietet, Referenzen zu> vergleichen, und die in dem fall dann gleich wären. Wenn diese> Voraussetzungen gegeben sind, kann man gewisse Fehler machen.
Es gibt in Rust keine zwei Referenzen, die auf das gleiche Objekt
zeigen, wenn eine oder mehrere davon mutable sind. Das versuchen wir dir
hier seit Stunden beizubringen.
🐧 DPA 🐧 schrieb:> Vielleicht kommt das wirklich auch ein wenig vom Arbeiten mit C. Da muss> man, neben der Sprachsyntax, Semantik, usw. auch diese allgemeinen> Konzepte alle immer im Überblick haben, sonst kann man dort Fehler> machen. Im Umkehrschluss hiesse das dann, dass wen Rust einem dies> abnimmt,
Völlig richtig. Endlich hast du es verstanden.
> ... Aber öffnen wie diese Büchse der Pandora mal lieber nicht.
Warum nicht?
Könnte es zu Erkenntnis führen?
MaWin schrieb:> 🐧 DPA 🐧 schrieb:>> Das hängt in dem konkreten Beispiel von der Implementierung, und davon>> was "machewas" macht, ab.>> Ah. Komisch. Eben war es noch möglich eine allgemeine Definition zu> haben. Plötzlich ist sie nicht mehr allgemein.
Die Definition ist trotzdem noch allgemein. Das konkrete Beispiel ist es
nicht. Und nachfolgend habe ich dann ja genauer beschrieben, unter
welchen umständen es dort zu Aliasing kommen kann, bei diesem Beispiel.
Wenn ich sage, es gibt grüne Wände, und du sagst, dort ist eine Wand,
ist die Grün? Dann kann ich allgemein schlussfolgern, dass die
Möglichkeit besteht, dass die Wand grün sein könnte. Das macht meine
Aussage nicht weniger Allgemein, und es macht Beschreibung nicht weniger
spezifisch. Ich kann nichts genaueres sagen, aber ich kann doch etwas
dazu sagen.
Und beim vorherigen Beispiel, konnte ich doch schon sehr viel dazu
sagen.
MaWin schrieb:> Ein> Pointer-Aliasing, wie es C definiert, gibt es in Rust für> mutable-Referenzen nicht.> Würdest du da mitgehen?>> 🐧 DPA 🐧 schrieb:>> Ein fall, wo so etwas aber Konfliktpotenzial bietet, ist bei>> Vergleichen. Falls die Sprache eine Möglichkeit bietet, Referenzen zu>> vergleichen, und die in dem fall dann gleich wären. Wenn diese>> Voraussetzungen gegeben sind, kann man gewisse Fehler machen.>> Es gibt in Rust keine zwei Referenzen, die auf das gleiche Objekt> zeigen, wenn eine oder mehrere davon mutable sind.
das sind Beispiele für grosse Unterschiede zu bestehenden
Programmiersprachen (C,C++,Java,C#), aber da sich die wenigsten mit
diesen Details überhaupt auskennen können sie die Bedeutung sehr einfach
als unrelevant empfinden
🐧 DPA 🐧 schrieb:> Die Definition ist trotzdem noch allgemein. Das konkrete Beispiel ist es> nicht. Und nachfolgend habe ich dann ja genauer beschrieben, unter> welchen umständen es dort zu Aliasing kommen kann, bei diesem Beispiel.
aber eben nicht in Rust und darum geht doch hier, oder?
MaWin schrieb:> Ein Pointer-Aliasing, wie es C definiert, gibt es in Rust für> mutable-Referenzen nicht.> Würdest du da mitgehen?
Wieso sollte ich? Ich habe nie von Pointer-Aliasing, wie es C definiert,
geredet, sondern mich auf das zugrundeliegende abstrakte Konzept
bezogen. Du fährst dich so darauf fest, das nur im Kontext einer
spezifischen Sprache betrachten zu wollen.
cppbert schrieb:> aber eben nicht in Rust und darum geht doch hier, oder?
Doch, die ist genau so anwendbar. Das C und Rust seine eigene
Terminologie und eigene Definitionen vom Begriff haben, ist da nicht
relevant.
MaWin schrieb:>> ... Aber öffnen wie diese Büchse der Pandora mal lieber nicht.>> Warum nicht?> Könnte es zu Erkenntnis führen?
Was passiert mit Piloten, die immer nur den Autopiloten Fliegen lassen?
Sie verlernen es, selbst zu fliegen.
🐧 DPA 🐧 schrieb:> Du fährst dich so darauf fest,
Nein. Du redest dich hier raus.
> das nur im Kontext einer> spezifischen Sprache betrachten zu wollen.
Es geht hier um Rust.
🐧 DPA 🐧 schrieb:> Doch, die ist genau so anwendbar.
Ja. Wie gesagt, unter deiner Definition gibt es "Aliasing" in Rust.
🐧 DPA 🐧 schrieb:> Wieso sollte ich? Ich habe nie von Pointer-Aliasing, wie es C definiert,> geredet, sondern mich auf das zugrundeliegende abstrakte Konzept> bezogen. Du fährst dich so darauf fest, das nur im Kontext einer> spezifischen Sprache betrachten zu wollen.
das ist aber kein "abstraktes" sondern ein Sprachen-Konzept - das kannst
du nicht allgemein definieren - das Rust-Design ist extra so definiert
das Aliasing über das Typ-System nicht ausdrückbar ist, Bedeutet: Rust
supportet kein Aliasing
🐧 DPA 🐧 schrieb:> Was passiert mit Piloten, die immer nur den Autopiloten Fliegen lassen?> Sie verlernen es, selbst zu fliegen.
Rust ist kein Autopilot.
Rust ist ein permanenter Fluglehrer, der ständig neben dem Piloten sitzt
und Pilotenfehler sofort korrigiert, bevor sie zu Flugfehlern führen.
cppbert schrieb:> das ist aber kein "abstraktes" sondern ein Sprachen-Konzept
Du hat doch selbst auf
https://en.wikipedia.org/wiki/Aliasing_(computing) verlinkt, wo das auch
allgemein gehalten, mit Beispielen in mehreren Sprachen, ist.
Natürlich gibt es das als allgemeines, abstraktes Konzept.
cppbert schrieb:> 🐧 DPA 🐧 schrieb:>> Wieso sollte ich? Ich habe nie von Pointer-Aliasing, wie es C definiert,>> geredet, sondern mich auf das zugrundeliegende abstrakte Konzept>> bezogen. Du fährst dich so darauf fest, das nur im Kontext einer>> spezifischen Sprache betrachten zu wollen.>> das ist aber kein "abstraktes" sondern ein Sprachen-Konzept - das kannst> du nicht allgemein definieren - das Rust-Design ist extra so definiert> das Aliasing über das Typ-System nicht ausdrückbar ist, Bedeutet: Rust> supportet kein Aliasing
aber natürlich kannst du Aliasing-Probleme in unsafe erzeugen - weil du
da (sehr eingeschränkt) C-Semantik hast - aber wir reden nicht von
unsafe weil das der geringste Teil des Projektes sein sollte und niemals
schlimmer ist als was man mit C machen kann
🐧 DPA 🐧 schrieb:> cppbert schrieb:>> das ist aber kein "abstraktes" sondern ein Sprachen-Konzept>> Du hat doch selbst auf> https://en.wikipedia.org/wiki/Aliasing_(computing) verlinkt, wo das auch> allgemein gehalten, mit Beispielen in mehreren Sprachen, ist.>> Natürlich gibt es das als allgemeines, abstraktes Konzept.
natürlich - aber nicht ohne Sprachebezug - somit nicht mehr
allgemein/abstrakt
cppbert schrieb:> 🐧 DPA 🐧 schrieb:>> cppbert schrieb:>>> das ist aber kein "abstraktes" sondern ein Sprachen-Konzept>>>> Du hat doch selbst auf>> https://en.wikipedia.org/wiki/Aliasing_(computing) verlinkt, wo das auch>> allgemein gehalten, mit Beispielen in mehreren Sprachen, ist.>>>> Natürlich gibt es das als allgemeines, abstraktes Konzept.>> natürlich - aber nicht ohne Sprachebezug - somit nicht mehr> allgemein/abstrakt
Doch, auch ohne Sprachebezug. Wie fängt der Artikel an? Mit "In
*computing*". Nicht mit "In Rust" oder mir "In C". Es gibt in dem
Artikel auch konkrete Beispiele, aber eben, als Beispiele, nicht als
Definition.
🐧 DPA 🐧 schrieb:> Doch, auch ohne Sprachebezug. Wie fängt der Artikel an? Mit "In> *computing*". Nicht mit "In Rust" oder mir "In C". Es gibt in dem> Artikel auch konkrete Beispiele, aber eben, als Beispiele, nicht als> Definition.
Du hast ganz doll recht - so lange du nicht wieder von Aliasing in
zusammenhang mit (Safe)Rust sprichst, weil es das dort nicht gibt
cppbert schrieb:> aber wir reden nicht von> unsafe weil das der geringste Teil des Projektes sein sollte und niemals> schlimmer ist als was man mit C machen kann
Genau. In der Praxis ist der allerkleinste Teil des Projekts unsafe. In
den allermeisten meiner Projekte ist gar kein unsafe drin. Und das ist
nicht nur bei mir so.
Wenn man allerdings unsafe-Rust-Code schreibt, dann ist das deutlich
anspruchsvoller korrekt zu tun, als normales C zu schreiben. Vor allem
wenn man so Dinge wie Pointer oder Transmutation verwendet oder bewusst
gegen RAII verstößt.
Der Grund dafür ist, dass man alle Dinge beachten muss, die man in C
auch beachten muss. Und zusätzlich muss man noch sicherstellen, dass die
Rust-Safety-Garantien eingehalten werden. Und zwar auch im restlichen
Safe-Code.
Unsafe-Codeabschnitte können Auswirkungen auf Safe-Code haben. Safe-Code
darf nicht unsafe werden durch unsafe-Code.
MaWin schrieb:> 🐧 DPA 🐧 schrieb:>> Was passiert mit Piloten, die immer nur den Autopiloten Fliegen lassen?>> Sie verlernen es, selbst zu fliegen.>> Rust ist kein Autopilot.> Rust ist ein permanenter Fluglehrer, der ständig neben dem Piloten sitzt> und Pilotenfehler sofort korrigiert, bevor sie zu Flugfehlern führen.
Bei dem konkreten Flugzeugmodell, versteht sich. Da lernt er dieses
spezifische Modell zu bedienen. Mehr aber auch nicht.
Und manchmal braucht man einen kleinen Crash, ein kleines Desaster, um
wirklich zu verstehen, warum man tun muss was man tun muss.
cppbert schrieb:> Du hast ganz doll recht - so lange du nicht wieder von Aliasing in> zusammenhang mit (Safe)Rust sprichst, weil es das dort nicht gibt
Dann verstehst du das allgemeine Konzept selbst für sich genommen wohl
noch nicht richtig.
🐧 DPA 🐧 schrieb:> Bei dem konkreten Flugzeugmodell, versteht sich. Da lernt er dieses> spezifische Modell zu bedienen. Mehr aber auch nicht.
Mit dem Erlernen von Rust habe ich mindestens soviel über C/C++ gelernt,
wie über Rust. Und ich habe vorher über 20 Jahre C/C++ entwickelt.
🐧 DPA 🐧 schrieb:> cppbert schrieb:>> Du hast ganz doll recht - so lange du nicht wieder von Aliasing in>> zusammenhang mit (Safe)Rust sprichst, weil es das dort nicht gibt>> Dann verstehst du das allgemeine Konzept selbst für sich genommen wohl> noch nicht richtig.
ich denke gut genug - da die Definitionen logisch und simpel sind
verstehe ich nicht was daran überhaupt unverständlich sein soll
cppbert schrieb:> ich denke gut genug - da die Definitionen logisch und simpel sind> verstehe ich nicht was daran überhaupt unverständlich sein soll
aber vielleicht helfen mir da meine geballten 30 Jahren C/C++, Assembler
und Reverse-Engineering Erfahrung :)
Mache gerade das Rust Buch durch (doc.rust-lang.org/book), und bis
Kapitel 6 war es ja noch ok, aber jetzt wird´s schon etwas seltsam:
- enum kann jede Variante andere Daten halten, aber ich komm nicht mehr
dran außer mit match.
- Match muß aber alle Varianten abdecken also gibt es "other =>" oder
auch "_ =>" , naja ob das lesbarer wird?
- Damit man das nicht braucht gibts das "if let", das ist ja total
abstrus. Let weist eigentlich einer Variable etwas zu, jetzt steht
daneben ein "Pattern". Kann ich nicht mehr als lesbar bezeichnen...
Thomas W. schrieb:> Mache gerade das Rust Buch durch (doc.rust-lang.org/book), und bis> Kapitel 6 war es ja noch ok, aber jetzt wird´s schon etwas seltsam:
enum ist ein Sum-Type - also ein Variant/Union Type
primär ist die Syntax dazu zu da die Mehrfägkeit zu bekommen ohne das
auch mehr Probleme bei der Anwendung entstehen
bei Union darfst du nicht zwischen den Membern lesend/schreiben springen
sonst UB und bei std::variant musst du entweder einen Visitor bauen oder
casten - beides ist nicht schön
match vereint sicher die C++ enum und std::variant Features - auch wenn
der Enum-Sumtype bei Rust aber eher aus dem OCaml Ursprung kommt
die meisten empfinden genau das Enum-Sumtype Feature als DAS Rust
Feature was sie am meisten lieben - manche erst nach eine gewissen
Warmwerdzeit
und auch die "Patterns" sind der absolute Hammer - nicht das es nicht
auch anders geht aber die eleganz das alles auf so wenig zu reduzieren
finde ich schön
Thomas W. schrieb:> Mache gerade das Rust Buch durch (doc.rust-lang.org/book), und bis> Kapitel 6 war es ja noch ok, aber jetzt wird´s schon etwas seltsam:> - enum kann jede Variante andere Daten halten, aber ich komm nicht mehr> dran außer mit match.> - Match muß aber alle Varianten abdecken also gibt es "other =>" oder> auch "_ =>" , naja ob das lesbarer wird?> - Damit man das nicht braucht gibts das "if let", das ist ja total> abstrus. Let weist eigentlich einer Variable etwas zu, jetzt steht> daneben ein "Pattern". Kann ich nicht mehr als lesbar bezeichnen...
was du nicht vergessen darfst ist das das alle per default immutable ist
- also in C++ gesagt "alles ist const" - das ist ein riesen Vorteil der
Sprache und erzwigt implizit auch ein saubere, mehrheitliche
State-freieres arbeiten
aber ich verstehe es wenn jemand nicht stark aus dieser const/state-less
Welt kommt (am besten noch aus einer gar typelosen Welt) das diese
ganzen Konzepte vereint schon sich schon ein wenig "unhandlich"
anfühlen, weil man den Mehrwert wie implizite const-correctness
vielleicht bisher gar nie genutzt hat oder das einem gänzlich fremd ist
wenn jemand z.B. viel mit Multithreading und C++ macht ist der Einstieg
vergleichsweise einfacher weil Rust die sinnvollen Konzepte aus dem
Bereich schon forciert
Ich mochte bei C, das man immer die Typen angeben musste. Da wusste man
immer auf einen Blick, womit man es zu tun hat. Was ich auch noch etwas
speziell finde, ist das man so Zeugs machen kann 'let x=1; let
x="abc";', da muss man also auch noch die richtige finden. Ok,
vermutlich helfen IDEs da einem weiter (wobei ich kein Fan von IDEs
bin).
DPA schrieb:> Ich mochte bei C, das man immer die Typen angeben musste. Da> wusste man> immer auf einen Blick, womit man es zu tun hat. Was ich auch noch etwas> speziell finde, ist das man so Zeugs machen kann 'let x=1; let> x="abc";', da muss man also auch noch die richtige finden. Ok,> vermutlich helfen IDEs da einem weiter (wobei ich kein Fan von IDEs> bin).
da geben ich dir recht ist vergleichbar mit C++/Java/C# auto/var
sollte man wirklich nicht zu excessive nutzen sonst blickt man nichts
mehr
es kommt aber ganz darauf an - in manchen stellen z.B. bei generischer
Programmierung kanst du das teilweise einfach nicht - deswegen das
Sprachfeature
aber ich finde es trotzdem gut das man
let x = 1;
let x: u32 = 1
let x = 1u32
let x: u32 = 1u32
schreiben kann - wenn man denn will
DPA schrieb:> Ich mochte bei C, das man immer die Typen angeben musste.
Wenn ich mich recht erinnere, führt auch C gerade das
"auto"-Schlüsselwort in der C++-Bedeutung ein … das kann manchmal ja
auch sinnvoll sein. Oft genug sieht man sowas wie:
1
foo*foop=(foo*)arg;
wo der Typ zweimal auftauchen muss. Da ist ein
1
autofoop=(foo*)arg;
schneller überschaubar. Aber das kann schnell zu "obfuscation" führen,
weil der Autor des Codes ja völlig klar wusste, welchen Typ die rechte
Seite hat, nur jemand anders, der den Code lesen will, es erst auf die
eine oder andere Art recherchieren muss.
cppbert schrieb:> aber ich finde es trotzdem gut das man> let x = 1;> let x: u32 = 1> let x = 1u32> let x: u32 = 1u32> schreiben kann - wenn man denn will
Sinnvoll benutzt ist das sicher nützlich.
und das ist auch das coole und besondere an Rust
Die schaffen es die Basis Konzepte von fast allen System(und auch
Hochs)sprachen unter einen Hut (Zero-Cost, Constness/Immuateable by
default, Movesemantic by default, No-GC, No-Runtime) zu bringen und
dennoch applikationsfreundlich zu bleiben
jeder andere Sprachenversuch hat bisher einen oder mehrere dieser
Ansprüchen fallen lassen weil die es konzeptionell nicht in ein Design
rein bekommen haben - das ist ein Novum
auch wenn ich wirklich verstehe das die meisten gar keine Ahnung von den
obigen Basis-Konzepten haben und auch deren relevanz kaum bis gar nicht
einschätzen können - in Bezug auf Sicherheit, Performanz und Generic
(also eben nur wie in vielen Sprachen nur einen Aspekt davon)
cppbert schrieb:> da geben ich dir recht ist vergleichbar mit C++/Java/C# auto/var> sollte man wirklich nicht zu excessive nutzen sonst blickt man nichts> mehr
Ich finde es ist nicht vergleichbar mit C++, weil Rust die Typangabe
durch den Programmierer auf Funktionsschnittstellen-, struct-, static-
und const-var-Ebene forciert. Type inferrence findet nur innerhalb von
Funktionen statt. (Lambdas sind eine optionale Ausnahme).
Wenn ein Typ vom Compiler hergeleitet wird, dann sieht man in der Regel
die Quelle der Herleitung auf der gleichen Bildschirmseite.
Und wenn man das immer noch unübersichtlich findet, dann kann man jeder
Variablen selbstverständlich auch einen expliziten Typen geben.
Bei der Herleitung passiert so gut wie nie etwas Unerwartetes in Rust.
Der Grund dafür ist das sehr strikte Typsystem.
Im Gegensatz zu C++. Da hat man implizite Konvertierungen und
Promotionsregeln. Das macht es manchmal sehr schwer zu sagen, welchen
Typ eine Variable wirklich hat.
Das ist in Rust anders.
Wenn man sehr generischen Code schreibt, dann kann es schon manchmal
schwerer werden den Typ von Variablen zu erkennen. Aber auch das ist
meist nicht schlimm. Denn wenn man diese Variable, oder einen davon
errechneten Variable, dann aus der Funktion rückgibt oder in ein struct
schreibt, dann bricht der Compiler durch fehlende implizite
Konvertierungsmechanismen bei einem Typ-mismach an.
cppbert schrieb:> in manchen stellen z.B. bei generischer> Programmierung kanst du das teilweise einfach nicht - deswegen das> Sprachfeature
Doch. Bei generischer Programmierung hat man in Rust immer einen
generischen Typen. Den kann man dann auch angeben, wenn man möchte. Muss
man aber eher selten.
Aber ich mache es schon manchmal. Vor allem, wenn ein impl mehrere
generische Typen hat.
Ein generischer Typ ist nicht nur ein Platzhalter. Es ist ein Typ mit
ganz klar definierten statisch festgelegten Eigenschaften.
Generische Typen sind, anders als in C++, in Rust stark constrained.
Man muss in Rust generische Typen mit der where-clause soweit
einschränken, dass alle tatsächlich durchgeführten Operationen auf
ebenjenen Typ abgedeckt sind. Wenn man das nicht macht, kann man
überhaupt nichts mit dem Typ machen. Wenn man zwei Variablen generischen
Typs addiert, dann muss dieser generische Typ im where-clause auf das
Add-Trait eingeschränkt sein. d.h. der Typ kann nur einer sein, der auch
tatsächlich exakt dieses Trait implementiert. Das wird alles schon bei
der Implementierung der generischen Funktion festgezurrt. (In C++ wird
das fast alles erst viel später bei der Instanziierung aufgelöst).
Bei der Instanziierung wird dann wiederum festgezurrt, dass der
tatsächliche Typ auch tatsächlich alle geforderten Traits implementiert.
Ein generischer Typ monomorphiert immer bei der Instanziierung in genau
einen konkreten tatsächlichen Typ.
MaWin schrieb:> cppbert schrieb:>> da geben ich dir recht ist vergleichbar mit C++/Java/C# auto/var>> sollte man wirklich nicht zu excessive nutzen sonst blickt man nichts>> mehr>> Ich finde es ist nicht vergleichbar mit C++, weil Rust die Typangabe> durch den Programmierer auf Funktionsschnittstellen-, struct-, static-> und const-var-Ebene forciert. Type inferrence findet nur innerhalb von> Funktionen statt. (Lambdas sind eine optionale Ausnahme).
ja sorry das vergesse ich immer - im Ergebnis verhält es sich ähnlich,
aber es ist doch viel strikter
z.b. erzeugt auto nicht ungewillt Kopien - was bei C++ immer mal gern
passiert oder häufig von Anfängern falsch gemacht wird - da Rust
implizit moved und nur explizit kopiert kann das in Rust gar nicht
passieren
> cppbert schrieb:>> in manchen stellen z.B. bei generischer>> Programmierung kanst du das teilweise einfach nicht - deswegen das>> Sprachfeature>> Doch. Bei generischer Programmierung hat man in Rust immer einen> generischen Typen. Den kann man dann auch angeben, wenn man möchte. Muss> man aber eher selten.> Aber ich mache es schon manchmal. Vor allem, wenn ein impl mehrere> generische Typen hat.>> Ein generischer Typ ist nicht nur ein Platzhalter. Es ist ein Typ mit> ganz klar definierten statisch festgelegten Eigenschaften.>> Generische Typen sind, anders als in C++, in Rust stark constrained.> Man muss in Rust generische Typen mit der where-clause soweit> einschränken, dass alle tatsächlich durchgeführten Operationen auf> ebenjenen Typ abgedeckt sind.
ja sorry - ich meinte eher das du keinen expliziten "Basis"-Typ angeben
kannst (oder es recht wenig sinn macht) - und ja die where clausen
(vergleichbar mit C++ Konzepts) verhindern zwangsweise die typischen C++
Template-Error-Wolken
Ein wichtiger weiterer Punkt, warum Type Inference in Rust viel besser
nachvollziehbar ist, als in C++:
Es gibt keine Methoden- und Funktionsüberladungen und keine
Klassenhierarchien.
Es ist viel einfacher nachzuvollziehen, was tatsächlich aufgerufen wird.
Das klassische OOP-Problem, wo eine Methode 10 mal abgeleitet und auch
noch 5 mal überladen ist, existiert in Rust nicht.
Es ist zwar manchmal nicht ganz auf den ersten Blick zu erkennen, zu
welchem Trait ein Funktionsaufruf gehört. Aber in der Doku, die man mit
Cargo aus jedem Stück Rust-Code generieren kann, wird dem Entwickler das
dann gut und eindeutig erklärt. Dazu ist es nicht notwendig, dass jemand
das manuell irgendwo dokumentiert.
Und wenn man dann immer noch nicht weiß, welchen Typ eine Variable hat,
dann kann man den Rust-Compiler ganz einfach fragen:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2d69f5a260259c365c4e0ac0913eff0e
Als Fan von Pascal/Delphi und weniger von C, beobachte ich die
Entwicklung auch mi Interesse.
Auch im Freepascal Forum gibt es dazu gerade eine Vergleichsdiskussion,
ob und wie sich Rust von Pascal unterscheidet
https://forum.lazarus.freepascal.org/index.php/topic,54311.0.html
Peter K. schrieb:> Auch im Freepascal Forum gibt es dazu gerade eine Vergleichsdiskussion,
letzer Post vom "April 25, 2021, 09:56:15 AM" ist aber nicht so aktuell
MaWin schrieb:> Und wenn man dann immer noch nicht weiß, welchen Typ eine Variable hat,> dann kann man den Rust-Compiler ganz einfach fragen:>> https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2d69f5a260259c365c4e0ac0913eff0e
An so Informationen kommt man bei C++ auch nur mit kleinen Tricks :)
ich hoffe das Rust in dem Bereich sehr viel stärker aus den C++ Fehlern
lernt und die Fähigkeiten generischer zu programmieren auch mit den
entsprechenden Tools unterfüttert um das einfach/schnell
wartbar/verständlich zu halten
cppbert schrieb:> An so Informationen kommt man bei C++ auch nur mit kleinen Tricks :)
Das macht bei Rust der rust-analyser. Der Zeigt bei jeder Variablen den
Typ an. Gibt es als Plugin für VSCode.
cppbert schrieb:> ich hoffe das Rust in dem Bereich sehr viel stärker aus den C++ Fehlern> lernt und die Fähigkeiten generischer zu programmieren auch mit den> entsprechenden Tools unterfüttert um das einfach/schnell> wartbar/verständlich zu halten
Ja also, ich sag mal so. Diesen Trick braucht man so gut wie nie. Aber
wenn, dann ist es hilfreich zu wissen.
Generell ist der Rustcompiler sehr viel besser in der Fehlerausgabe als
z.B. der g++.
Der Rustcompiler gibt bekannte Typinformationen zwar aus, aber überhäuft
den Programmierer in der Regel nicht mit ellenlangen Typbeschreibungen
(g++ ist da auch schon besser geworden).
In der Regel gibt der Rustcompiler sogar eine Vorschlag, was der
Programmierer vermutlich meinte. Oft ist das sogar schon richtig oder
fast richtig oder gibt einem wenigstens einen Schubs in die richtige
Richtung.
Und dann hat jeder Compilerfehler auch noch eine eigene ID und einen
Link auf eine manpage/website, wo der Fehler und seine möglichen Gründe
noch einmal genauer und mit Beispielen beschrieben wird.
Vom Fehlerdiagnoseverhalten ist der Rustcompiler so ziemlich das Beste,
was ich kenne.
MaWin schrieb:> Generell ist der Rustcompiler sehr viel besser in der Fehlerausgabe als> z.B. der g++.
Das ist jetzt aber auch keine allzu große Herausforderung... ;-)
>keine allzu große Herausforderung
Der Rust Compiler umarmt einen und tröstet einen wenn man einen Fehler
gemacht hat!
https://youtu.be/vcFBwt1nu2U?t=2223
MaWin schrieb:> Ich wüsste jetzt nicht, wie man das noch verständlicher und besser> machen könnte.
Ich schon. ;-)
Der Unterstrich wird an vielen Stellen als Gruppierungszeichen genutzt
(auch wenn C++ und nun C sich für den Apostroph entschieden haben).
Ich hätte daher sowas wie
1
let c = i32: 42;
lesbarer gefunden, um den Typ einer Zahl zu benennen. (Ja, erinnert an
Pascal. ;-)
Aber nur, weil du gefragt hast …
Jörg W. schrieb:> Ich hätte daher sowas wie> let c = i32: 42;>> lesbarer gefunden, um den Typ einer Zahl zu benennen.
So kann man es ja in Rust auch machen:
Jörg W. schrieb:> Aber nur, weil du gefragt hast …
Leider wieder auf eine Frage geantwortet, die gar nicht gestellt wurde.
Es ging um die Fehlermeldungen.
Jörg W. schrieb:> Ich hätte daher sowas wie> let c = i32: 42;>> lesbarer gefunden, um den Typ einer Zahl zu benennen. (Ja, erinnert an> Pascal. ;-)
Sorry aber das erinnert niemanden an Pascal weil der Typ bei Pascal doch
immer rechts vom Doppelpunkt steht ;-)
Rust entspricht bis auf das "let" exakt der Pascal-schreibweise
Jörg W. schrieb:> Finde ich zumindest besser lesbar als die Unterstriche.
meinst du das Beipspiel von MaWin mit
let _: () = x;
das ist ein Spezial-Sonder-Case den du selten in freier Wildbahn sehen
wirst
Jörg W. schrieb:> Finde ich zumindest besser lesbar als die Unterstriche.
1
let a = 9_882_223_112;
2
let a = 9_882_223_112_i64;
3
let a = 9882223112_i64;
4
let a = 9882223112i64;
5
let a: i64 = 9882223112;
6
let a: i64 = 9_882_223_112;
7
//...usw...
Was davon jetzt besser lesbar ist, ist vollkommen dir überlassen. Du
kannst alle Schreibweisen verwenden. Unterstriche können fast beliebig
platziert und weggelassen werden.
Kaj schrieb:> Jörg W. schrieb:>> Finde ich zumindest besser lesbar als die Unterstriche.> Bei Konstanten und globalen Variablen muss man es sogar so angeben:const> VAR: Type = value;> static var: Type = value;
kann einer sagen warum "const x = 123i32" nicht genug ist?
cppbert schrieb:> kann einer sagen warum "const x = 123i32" nicht genug ist?
Weil geschwätzige Syntax wieder im Trend liegt?
Ich hätte auch nicht gedacht dass jemand nochmal ernsthaft das alte
Basic-Style "let" aufwärmt. Aber hey, die Rustler kennen da nix.
cppbert schrieb:> kann einer sagen warum "const x = 123i32" nicht genug ist?
Weil man dann Type Inferrence bemühen müsste, was in einigen Fällen
(nicht in diesem) interessante Probleme gibt. z.B. zyklische
Typabhängigkeiten.
Es ist eine Designentscheidung, dass alle toplevel-APIs ohne Type
Inferrence typisiert werden müssen.
Damit gewinnt man eine vollständige Kontextunabhängigkeit auf dieser
Ebene.
In Rust ist es sehr wichtig, dass die Größe von Typen bekannt ist, oder
dass bekannt ist, dass die Größe dynamisch ist. Unbekannte Größen sind
ein Problem und müssen so schnell wie möglich vom Compiler aufgelöst
werden.
Cyblord -. schrieb:> Ich hätte auch nicht gedacht dass jemand nochmal ernsthaft das alte> Basic-Style "let" aufwärmt. Aber hey, die Rustler kennen da nix.
Wie würdest du denn eine Variable mit Type Inferrence ohne let
definieren und dabei auch zwischen Definition und Zuweisung
unterscheiden? Mir fällt da spontan keine Möglichkeit ein, außer
Keyword.
Cyblord -. schrieb:> Ich will schon gar keine Type Inference machen.
Interessant. Eben sagtest du noch:
Cyblord -. schrieb:> Weil geschwätzige Syntax wieder im Trend liegt?
Was denn nun? Lieber mehr oder lieber weniger tippen?
Cyblord -. schrieb:> cppbert schrieb:>> kann einer sagen warum "const x = 123i32" nicht genug ist?>> Weil geschwätzige Syntax wieder im Trend liegt?> Ich hätte auch nicht gedacht dass jemand nochmal ernsthaft das alte> Basic-Style "let" aufwärmt. Aber hey, die Rustler kennen da nix.
wann erklärst du jetzt wirklich mal endlich warum die Rust-Iteratoren
ein No-Go für embedded sind?
MaWin schrieb:> Was denn nun? Lieber mehr oder lieber weniger tippen?
Nur das NOTWENDIGE tippen. Und dazu gehört der Typ. Dazu gehört aber
kein let und kein func.
Cyblord -. schrieb:> Nur das NOTWENDIGE tippen. Und dazu gehört der Typ. Dazu gehört aber> kein let und kein func.
als wenn das bei Algorithmen-Entwicklung irgendeine relevanz hat, oder
jemals gehabt hätte ausser in irgendeiner Wurstbude die auch {} bei if
weglässt weil das so viel spart aber die halbe Manschaft kann nicht mal
10-Finger schreiben :)
btw: du denkst noch an die Iteratoren und die No-Go Aufklärung?
Cyblord -. schrieb:> Dazu gehört aber kein let und kein func.
Da haben wir ja noch einmal Glück gehabt, denn 'func' gibt es in Rust
nicht.
Btw: An der Aufklärung der Iteratorenfrage wäre ich auch noch sehr
interessiert. Du scheinst da etwas zu wissen, was ich nicht weiß.
Ein schöner Artikel über Rust und Standardisierung:
https://blog.m-ou.se/rust-standard/> To better understand how to give a more useful definition, we first need to> understand how Rust evolves. What “Rust” means changes regularly, as we are> constantly working on improvements. Every six weeks, we release a new stable> version of the compiler, each time changing what “Rust” means.
> Announcing Rust 1.65.0https://blog.rust-lang.org/2022/11/03/Rust-1.65.0.html
Dieses Mal mit einem Feuerwerk an neuen großen Features.
> Generic associated types (GATs)
Yay! Kann man nicht in ein paar Worten erklären :)
> let-else statements
Noch elegantere Fehler- und Sonderfallbehandlung.
let-else verringert die Verschachtelungstiefen massiv.
> break from labeled blocks
Verringert auch Schachteltiefen und erhöht die Lesbarkeit für
Codeabläufe mit Abbruchbedingungen.
MaWin schrieb:>> Generic associated types (GATs)>> Yay! Kann man nicht in ein paar Worten erklären :)
magst du es mal versuchen? am besten mit möglichem C++ Bezug
cppbert schrieb:> magst du es mal versuchen? am besten mit möglichem C++ Bezug
Einen C++-Bezug kann ich leider nicht bringen. Da kenne ich mich nicht
gut genug mit C++ aus.
Grundsätzlich gesagt ist es eine relativ "einfache" (aus
Programmierersicht) Erweiterung eines bestehenden Features.
Man kann in Rust Typen mit Traits assoziieren.
Was heißt das?
Das typische Beispiel, wie es auch im Announcement vorkommt, ist ein
Iterator-Trait:
1
trait Iterator {
2
type Item;
3
fn next(&mut self) -> Option<Self::Item>;
4
}
Grob gesagt erreicht man damit, dass die Implementierung des Traits
angeben kann, welcher Typ konkret verwendet werden soll (hier: Welchen
konkreten Typ next() zurückgeben soll). Wenn man jetzt diesen Iterator
für einen Typ implementiert, dann muss man den konkreten Typ der
zurückgegebenen Elemente mit angeben. Somit weiß der Compiler bei der
Verwendung dieses Iterators, welche konkreten Typen aus dem Iterator
herausfallen. Im Trait selbst (in provided methods) kann man auch mit
dem Typ arbeiten, allerdings nur auf abstrakter und nicht auf konkreter
Ebene. (Man muss den Typ weiter einschränken mit Bounds).
Soweit so gut. Das alles gibt es schon sehr lange.
Nun ist neu, dass der assoziierte Typ auch generisch sein kann.
Das ist (IMO) hauptsächlich sinnvoll, wenn der assoziierte Typ eine
Lifetimeangabe braucht. Lifetimes werden über den generic-Mechanismus
gemacht. Das ist z.B. notwendig, wenn der Typ Referenzen einbettet.
Ohne GATs ist es nicht möglich dem assoziierten Typ eine Lebenszeit
(außer `static) zu geben.
Damit waren bis jetzt associated Types auf owned-Typen beschränkt.
Mit GATs gibt es praktisch keine Beschränkung mehr.
Und hier kommt auch schon der GAT fast-follower (in nightly):
async in Traits.
https://blog.rust-lang.org/inside-rust/2022/11/17/async-fn-in-trait-nightly.htmlcppbert schrieb:> Es gibt noch ein bisschen Optimierungsbedarf mit der Stack-Nutzung
Ja. Richtig. Haben wir hier ja auch schon besprochen.
Das ist aber tatsächlich weniger schlimm, als es sich erst anhört.
>Does this mean Rust is slower than C++?> No. You can always write your Rust code carefully to avoid copies.> Besides, all of this only comes out to a small percentage of the> total instruction count.
Aber sicherlich ist es etwas, das behoben werden muss.
ach sch..
Jetzt habe ich Text zum Text von weiter oben kopiert..von zu weit oben?
1
Standard Error
2
Compiling playground v0.0.1 (/playground)
3
error[E0308]: mismatched types
4
--> src/main.rs:4:17
5
|
6
4 | let z = x + y;
7
| ^ expected `i32`, found `i64`
8
9
error[E0277]: cannot add `i64` to `i32`
10
--> src/main.rs:4:15
11
|
12
4 | let z = x + y;
13
| ^ no implementation for `i32 + i64`
14
|
15
= help: the trait `Add<i64>` is not implemented for `i32`
16
= help: the following other types implement trait `Add<Rhs>`:
17
<&'a f32 as Add<f32>>
18
<&'a f64 as Add<f64>>
19
<&'a i128 as Add<i128>>
20
<&'a i16 as Add<i16>>
21
<&'a i32 as Add<i32>>
22
<&'a i64 as Add<i64>>
23
<&'a i8 as Add<i8>>
24
<&'a isize as Add<isize>>
25
and 48 others
26
27
Some errors have detailed explanations: E0277, E0308.
28
For more information about an error, try `rustc --explain E0277`.
29
error: could not compile `playground` due to 2 previous errors
Wieso macht eigentlich der ghci aus 0xa + 0xb 21 ??
Und auf Assemblerebene kann man sehr wohl ganz gut 32 Bit mit 64 Bit
addieren. Vor diesem Hintergrund fragt man sich, was wohl mit fehlender
"Implementation" gemeint ist.
Ich würde jetzt auch nicht von Umarmung sprechen - mich erinnert das
Szenario eher an Veräppelung.
rbx schrieb:> Und auf Assemblerebene kann man sehr wohl ganz gut 32 Bit mit 64 Bit> addieren.
Selbstverständlich.
Aber eben aus gutem Grund nicht im Rust-Typsystem.
Es zwingt dich explizit zu sein und eine Typumwandlung durchzuführen.
Und diese Entscheidung wie addiert werden soll, musst du natürlich auch
in Asm treffen.
Soll i32 auf i64 aufgeblasen werden? Mit oder ohne sign extension? Soll
auf i32 saturiert werden? Soll auf i32 abgeschnitten werden? All diese
Fragen gilt es zu beantworten. Der Rust-Compiler rät das Ergebnis dieser
Fragen nicht. Er fragt dich als Programmierer.
> Vor diesem Hintergrund fragt man sich, was wohl mit fehlender> "Implementation" gemeint ist.
Es fehlt (ganz bewusst und gewollt) die Implementierung des
Additions-Operators (Add-Trait) für i32 + i64.
rbx schrieb:> Ich würde jetzt auch nicht von Umarmung sprechen - mich erinnert das> Szenario eher an Veräppelung.
Was genau ist denn an dieser Fehlermeldung nicht zu verstehen?
> error[E0308]: mismatched types> error[E0277]: cannot add `i64` to `i32`
Alles was danach folgt ist nur eine weitere tiefergehende Erklärung,
warum i32 und i64 nicht addiert werden können.
> Wieso macht eigentlich der ghci aus 0xa + 0xb 21 ??
Was ist ghci?
Warum soll 10 + 11 nicht 21 sein?
rbx schrieb:> Und auf Assemblerebene kann man sehr wohl ganz gut 32 Bit mit 64 Bit> addieren.
nur explizit - die ganze implizite Auto-Casting und Integer-Promotion
Verhalten verursacht viele latente Fehler die schwer zu finden sind
auch z.B. Pointer == int == bool ist relativ böse
Rust zwingt zur hygiene - und die ist wirklich nötig, auch wenn viele
davon nie was mitbekommen - weil die meisten Kämpfe in der Standardlib
oder 3rd-Parties passieren
höchstwahrscheinlich kompilieren die meisten C/C++ Projekte gar nicht
mehr wenn man sign-unsiged-mismatch-Warning-als-Error im gcc aktivert :)
MaWin schrieb:> Was ist ghci?
in einem rbx Post darf ein Haskell-Bezug nicht fehlen :)
cppbert schrieb:> höchstwahrscheinlich kompilieren die meisten C/C++ Projekte gar nicht> mehr wenn man sign-unsiged-mismatch-Warning-als-Error im gcc aktivert
It depends.
Seit die Warnung nun standardmäßig ein ist, dürfte das schon deutlich
zur Verbesserung beigetragen haben. Ich habe schon viele Projekte
gesehen, die eine zero-warning-policy fahren (kommerzielle wie
Opensource).
Jörg W. schrieb:> cppbert schrieb:>>> höchstwahrscheinlich kompilieren die meisten C/C++ Projekte gar nicht>> mehr wenn man sign-unsiged-mismatch-Warning-als-Error im gcc aktivert>> It depends.> Seit die Warnung nun standardmäßig ein ist, dürfte das schon deutlich> zur Verbesserung beigetragen haben. Ich habe schon viele Projekte> gesehen, die eine zero-warning-policy fahren (kommerzielle wie> Opensource).
Die Top Projekte schon aber dann wird die Luft schnell dünn
genauso wie ASAN,TSAN Nutzung und statische Codeanalyse, ich treffe
immer wieder auf Fehler wegen fehlendem Tooleinsatz und Warninglevel
Beispiel: ASAN build von Qt 6.4 und Glib findet sofort eine
Stackoverflow, faellt aber nur auf wenn man auch die GLib mit ASAN baut,
TSAN Tests werden bei denen auch nicht über den CI-Server gemacht weil
zu viel Aufwand/ Belastung für den Server
MaWin schrieb:> Was ist ghci?
Würde ich sagen Glasgow Haskell Compiler Interpreter.
MaWin schrieb:> Warum soll 10 + 11 nicht 21 sein?
Weil 0xa + 0xb nunmal 0x15 sind. Außerdem nicht mehr 4 Bit, sondern
jetzt 8. Das ist alles viel Interpretationssache, z.B. auch, weil die
Zahlen ab 8000 bei 16 Bit immer negativ sind - sofern man das braucht.
Wenn man schon eine Art künstlichen Prozessor programmiert, der viele
mögliche Operationen mit Datentypen macht, dann sollte der auch 32Bit
mit 64 Bit addieren können. Am Ende ist eher die Frage, wo speichere ich
das Ergebnis?
Dann bräuchte man also nur einen Typen für 32Bit + 64Bit Additionen
konstruieren, der selbstverständlich mindestens 64Bit hat.
Besser wäre natürlich eine noch größere Bitbreite, das ja auch 64 Bit
bereits auf FFFF (überall) stehen kann. Da könnte man dann nur noch, bei
64 Bit - falls überhaupt - ein Bool addieren.
Man kann sich ein Vorbild an der Kompatibilität der Hardware nehmen -
und muss nicht alles ins absurdum führen, weil die Transparenz in
Assembler eher unbekannt ist.
Bei so Diskussionen rund um Loop-Automatismen auf YT weiß ich jedenfalls
eher nicht, ob ich nun lachen soll, oder weinen muss.
Das ist übrigens auch etwas (Loopautomatismen usw.) was bei Haskell
anstößig ist. Da heißt es dann: das sieht aber furchtbar aus, da
programmiere ich doch lieber C++.
Ich selber finde schon die vielen Möglichkeiten, die man in (PC)
Assembler hat , etwas unübersichtlich.
Aber um sich einen Überblick zu verschaffen, muss man eben eine Liste
machen, herumprobieren, Sourcecodes lesen oder Bücher zur
Programmierkunst in Asm.
Das geht alles ganz gut ohne YT.
Das gleiche gilt für Loop-Automatismen in Haskell und wird für Rust auch
nicht anders sein.
rbx schrieb:> Wenn man schon eine Art künstlichen Prozessor programmiert, der viele> mögliche Operationen mit Datentypen macht, dann sollte der auch 32Bit> mit 64 Bit addieren können.
Nein. Wozu? Was würde das bringen?
Es ist viel einfacher und auch für die Programmiererin viel eindeutiger,
wenn sie die Konvertierung explizit macht. Sie muss sich keine 1000
Regeln merken. Alles steht explizit im Code.
1
let c = a as i64 + b;
Ich sehe das Problem nicht.
Rust bietet mit 'as' und 'into' sehr mächtige und bequeme
Konvertierungstools.
> Am Ende ist eher die Frage, wo speichere ich das Ergebnis?
Die Fragen sind viel mehr die, die ich bereits oben formuliert habe. Wo
es dann gespeichert wird, ergibt sich daraus (Type inference).
> Dann bräuchte man also nur einen Typen für 32Bit + 64Bit Additionen> konstruieren, der selbstverständlich mindestens 64Bit hat.
Ach. Das ist selbstverständlich? Für mich nicht. Ich würde das als
Programmierer gerne von Fall zu Fall entscheiden.
> Besser wäre natürlich eine noch größere Bitbreite
Die bietet Rust.
> Man kann sich ein Vorbild an der Kompatibilität der Hardware nehmen
Man kann es auch sein lassen.
Nicht einmal das Maschinenmodell von C stimmt mit irgendeiner realen
Hardware auch nur annähernd überein.
> Assembler
Ich weiß ja nicht, was du ständig mit Assembly hast. Aber es ist
offtopic. Assembly hat überhaupt kein Typsystem. Es ist somit gar nicht
vergleichbar mit irgendeiner Hochsprache.
Rust definiert sich durch sein Typsystem.
> Bei so Diskussionen rund um Loop-Automatismen auf YT
Was sind "Loop-Automatismen"?
rbx schrieb:> Wieso macht eigentlich der ghci aus 0xa + 0xb 21 ??rbx schrieb:> MaWin schrieb:>> Warum soll 10 + 11 nicht 21 sein?>> Weil 0xa + 0xb nunmal 0x15 sind.
Und wo liegt das deiner Ansicht nach der Widerspruch?
Fragen wir doch einfach mal ghci, was der dazu meint:
1
ghci> compare 21 0x15
2
EQ
Um ganz sicher zu gehen, machen wir auch noch die Gegenprobe:
1
ghci> 21 == 0x15
2
True
Aber nicht nur in Haskell, sondern auch in Rust, C, C++, Java und Python
ist 0x15 = 21. Somit entspricht das Verhalten von Haskell dem Prinzip
der geringsten Überraschung, weswegen ich nicht verstehe, was daran
schlecht sein soll.
Yalu X. schrieb:> Somit entspricht das Verhalten von Haskell dem Prinzip> der geringsten Überraschung, weswegen ich nicht verstehe, was daran> schlecht sein soll.
Integer Promotion in jeder Form ist ein möglicher Fehler - in Normalfall
braucht man das sehr selten, weil man ja normalerweise nicht sinnlos
int32 und int64 in seinem Code mischt - oder es ist eben Schluri-Code
wenn du Kernel-Code schreibst musst du dir definitiv sicher sein das es
funktioniert und auch prüfen sonst gibt es Probleme - Rust forciert
schon mal das du solche Stellen immer deutlich im Code siehst auch wenn
es nur der Cast ist und sie nicht wie bei C und C++ nur mit Warnungen
belegt werden
Aber das ist auch eine Erfahrungs-Sache - oft neigen die unerfahrenen
eher zur einfachen aber schwächeren Schreibweisen weil die eben "so
schön einfach sind" - aber die Konsequenzen die sich aus vielen solchen
kleinen Sachen ergeben überblicken diese Entwickler meistens überhaupt
nicht - und das lässt
sich eben auch schlecht erklären - weil es immer einen "Maier Müller"
gibt der "damit" noch keine Probleme hatte
genau so könnten wir darüber diskutieren warum Java keinen
unsigned-Typen hat - weils dann eben so schön einfach ist, das Ende vom
Lied: es ist ein riesen Scheiss wenn man System-Programmierung macht
rbx schrieb:> MaWin schrieb:>> Assembly hat überhaupt kein Typsystem.>> Das stimmt nicht. Und wenn man weniger abstrahiert, kann man beim PC AVX> zum Addieren einsetzen
bedeutet nicht das Assembler ein Typsystem hat - das man als solches
Bezeichnen kann
btw: du Off-Topicst wieder in jede Richtung gleichzetig, SIMD, IDEs,
AVX...
cppbert schrieb:> btw: du Off-Topicst wieder in jede Richtung gleichzetig, SIMD, IDEs,> AVX...
Sehe ich nicht als offtopic. Rust ist ja gerade gut für sowas, Haskell
eben auch, was man damaliger tiefschürfender Literatur entnehmen konnte.
Ja gut, und rekursive Typen, oder Typen mit Baumstrukturen usw. sind in
Asm jetzt nicht typisch, allerdings brauchen solche Typsysteme auch eine
ganze Weile an Nachdenken und Üben, bevor sie Spaß machen.
Andererseits sind bei Asm die "Datentypen" eher die des Prozessors - so
gesehen stimmt das dann doch, dass es in Asm keine Typen gibt.
Eher gibt es Programmiertypen ;)
rbx schrieb:> Sehe ich nicht als offtopic.
Es ist vollkommen Offtopic und dein Geschreibsel über Asm+Typen ist
riesiger Unsinn. Deshalb kommentiere ich das jetzt auch nicht im Detail.
Du solltest dich dringend einmal in das Thema Typtheorie von Sprachen
in der Informatik einlesen.
Deine Post haben manchmal diesen komischen "Ich find das irgendwie
interessant hab aber keine Ahnung davon"-Stil
und wie ich schon sagte - Parallelsierung, Vektorisierung und auch AVX
sind völlige Daily-Business-Einsatzwerkzeuge in der C/C++
Software-Entwicklung wenn man nicht gerade Micro-Kontroller oder nur
Datenbanken programmiert - du schreibst darüber als wenn das was
neues/besonderes wäre - Rust macht das ganze nur sicherer - genutzt wird
das alles permanent seit Jahren, von sehr vielen Entwicklern
Memory Safe Languages in Android 13
https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html> Looking at vulnerabilities reported in the Android security bulletin,> which includes critical/high severity vulnerabilities reported through> our vulnerability rewards program (VRP) and vulnerabilities reported> internally, we see that the number of memory safety vulnerabilities> have dropped considerably over the past few years/releases.> From 2019 to 2022 the annual number of memory safety vulnerabilities> dropped from 223 down to 85.> In Android 13, about 21% of all new native code (C/C++/Rust) is in Rust.> There are approximately 1.5 million total lines of Rust code in AOSP> To date, there have been zero memory safety vulnerabilities discovered> in Android’s Rust code.
Yalu X. schrieb:> Man fragt sich nur, wie Apple selbst den Treiber ohne Rust hinbekommen> hat.
Es ist in C ja nicht unmöglich, nur besonders aufwändig und
fehleranfällig.
Kaj schrieb:> Es ist in C ja nicht unmöglich,
Der Titel des verlinkten Artikels "Rust-Magie macht Linux-Treiber für
Apple-GPU möglich" impliziert das aber fast :)
> nur besonders aufwändig und fehleranfällig.
Deswegen meine obige Frage:
Yalu X. schrieb:> Oder ist der Treiber mangels Rust-Magie so hingemurkst und verbugt,> dass er alle fünf Minuten abstürzt?
Das die meisten Apple-User mit ihrem Rechner sehr zufrieden zu sein
scheinen, gehe ich davon aus, dass sich die Fehleranfälligkeit in
akzeptablen Grenzen hält.
Yalu X. schrieb:> Das die meisten Apple-User mit ihrem Rechner sehr zufrieden zu sein> scheinen, gehe ich davon aus, dass sich die Fehleranfälligkeit in> akzeptablen Grenzen hält.
Ich habe festgestellt, dass ich doch lieber Diablo2 auf meiner Windows 8
Kiste spiele, als mich bei Linux darüber zu ärgern, dass der Maustreiber
bzw. die Maussteuerung bei Baldurs Gate2 total verkackt.
Interessanterweise gab es bei Open Solaris ganz gute Maus bzw. auch
Touchpad-Treiber bzw. -Steuerung. Das war etwas untypisch (für Unixe).
Wie konnte das sein?
Schwierig war dann aber auch noch den Rechner ohne Konsole
herunterfahren - oder die automatische Hardwareerkennung, die beim
Internetmodul versagte. ausgerechnet da..
Vor dem Hintergrund der Parallelfreundlichkeit von Rust kann man schon
sagen, Rust wird bleiben.
Der pragmatische Backround erinnert an JavaScript - ja und auch wenn
JavaScript gewöhnungsbedürftig ist - es hatte einen ganz guten Weg
gemacht - oder nicht?
Diablo2 ist eines der besten Computerspiele überhaupt, von richtig guten
Leuten programmiert. Das Spielmanagement bzw. auch Modding lief über
JavaScript.
Und das schon kurz nach der Jahrtausendwende, als JavaScript noch in
Kinderschuhen herumlief.
Hätte damals einer gefragt: Wird JavaScript bleiben? Ich hätte meine
Zweifel gehabt (aber unterm Strich nicht wirklich widersprochen) - die
hervorragenden Programmierer hatten den pragmatischen Weg gewählt.
rbx schrieb:> pragmatische Backround erinnert an JavaScript
Neben den Assoziations-Chaos-Sätzen die ungebremst aus deinem Gehirn
schwallen ist dein Javascript-Bezug echt das lustiges was du bisher
geschrieben hast :)
Außerdem bekommst du einen Bonuspunkt für einen haskellfreien Post
cppbert schrieb:> ist dein Javascript-Bezug echt das lustiges was du bisher geschrieben> hast
Der hat mich auch amüsiert.
Im deutschen Wikipedia stand auch lange Zeit drin, dass Python eine
Verwandtschaft mit der esoterischen Programmiersprache "Whitespace" hat,
weil die Einrückungen syntaktische Relevanz haben. ;-) Hat allerdings
inzwischen jemand heraus editiert.
MaWin schrieb:> Nimm bitte weniger davon.> Oder mehr.
Wie denn jetzt? Als das anfing mit JS, da hatte ich gemeint, das wäre
für nette Website-Gimmicks gut - aber sonst?
Punkt 1: begabte Programmierer (spricht für Rust)
Nun kam JS mit der Webentwicklung und wird zum Teil auch von der
getragen. Was hat Rust als Starthilfe?
Punkt 2: es gibt viele lästige Treiberprobleme in der Linux-Unix-World.
(spricht für Rust)
Grafik und Spiele ist dabei ein wichtiges Thema. Updates und Upgrades
nicht immer unproblematisch.
Punkt 3: mehr Spielspaß willkommen (spricht für Rust)
rbx schrieb:> Wie denn jetzt? Als das anfing mit JS, da hatte ich gemeint, das wäre> für nette Website-Gimmicks gut - aber sonst?>> Punkt 1: begabte Programmierer (spricht für Rust)>> Nun kam JS mit der Webentwicklung und wird zum Teil auch von der> getragen. Was hat Rust als Starthilfe?
Javascript hat einen völligen anderen Anwendungsbereich und ganz andere
Ziele als Rust, eine interpretierte, garbage-collectorte und typenlose
Sprache mit Rust zu vergleichen ist wie als wenn du sagt Chinesisch ist
wie Englisch, und für was braucht Rust Starthilfe? Diablo war auch keine
Starthilfe für Javascript - btw wünschen sich die meisten den schnellen
Tod von Javascript, selbst der Schöpfer - falls dir das engangen ist
> Punkt 2: es gibt viele lästige Treiberprobleme in der Linux-Unix-World.> (spricht für Rust)
Rust ist kein Heilmittel gegen schlecht gewarteten oder supporteten Code
- es ist nur schwerer ganz blöde Fehler zu machen, ob der Rust
Entwickler dann mit seinem Code Maus richtig supported ist was völlig
anderes und bei Solaris war dann wohl das Fehlermanagement und
Issue-Tracking besser - absolut gar keinen Bezug zu Rust
>> Grafik und Spiele ist dabei ein wichtiges Thema. Updates und Upgrades> nicht immer unproblematisch.>> Punkt 3: mehr Spielspaß willkommen (spricht für Rust)
Updates und Upgrades werden durch Rust nicht leichter oder einfacher -
wie kommst du auf sowas? genau so wirr wie dein
Parallelitäts-Geschreibsel
ganz wichtig: entweder merkst du wirklich nicht was für komische
Statements du hier abgibst oder du bist ein brillianter Troll
cppbert schrieb:> btw wünschen sich die meisten den schnellen Tod von Javascript, selbst> der Schöpfer - falls dir das engangen ist
Heute gibt's ja auch WebAssembly. Dafür kann man in allen möglichen
Sprachen (auch C und Rust) Code erzeugen, der dann direkt so im Browser
läuft.
Ich kann WebAssembly leider noch nicht verwenden. Der Grund ist recht
simpel: Ich brauche memory mapping. Momentan gibt es in WebAssembly nur
einen Memory pro Programm. Sachen wie der Ringbuffer Trick, Speicher
zwischen Prozessen hin und her schieben, etc. kann man damit also
vergessen, ausser man will die ganze zeit massenhavt Daten kopieren...
Und für multi threading wäre es auch nützlich, da braucht man nämlich
mehrere web worker mit einem shared memory.
Ich denke, wenn das da wäre, hätte man alles was es braucht, alle
beliebige Programme unverändert nach WebAssembly übersetzen zu können.
Es wäre echt cool, wenn man z.B. gleich ein Debian port für WebAssembly
haben könnte, man stelle sich das mal vor, man könnte einfach so,
libreoffice, mpv, krita, gnome-games, etc. im Browser einbinden.
Es fehlt so wenig! Es gibt auch schon ein Entwurf
(https://github.com/WebAssembly/multi-memory). So nah dran! Aber ich
fürchte, auch Jahre Später implementiert das noch keiner...
(https://webassembly.org/roadmap/#table-row-multimemory)
Kann für Rust jemadn ein gutes Einstiegsbuch empfehlen? Oder ändert sich
da eh noch alle Nase was und das macht keinen Sinn bzw. es gibt nichts
was sich lohnt zu lesen?
Ein komprimierter Einstieg würde mich schonmal interessieren
MaWin schrieb:> dass C++ vom alten Eisen ist
C++ kann ich tatsächlich auf meiner Windows ME Kiste nutzen (cygwin,
OpenWatcom), Haskell-Plattform wollte nicht (nur Hugs) und nun frag mal
dreimal, was da wohl mit Rust geht.
Oder gibt es eine nette Rust-Ide für FreeDOS?
Oder wenigstens was für Cygwin? Python ist schon vorgegangen, und wurde
willkommen geheißen. Nur ist das schon lange her.
Übersetzungsanleitung vielleicht für flat assembler?
Rust ist tatsächlich noch viel zu Linuxoid, und dann auch noch recht
Windows/DOS unfreundlich. Das war Haskell nicht, wenn auch in viele
Fettnäpfchen getreten oder kaum nutzbar da. DOS? Scheinbar nie gehört.
Aber Windows ist bei vielen schon vorinstalliert - und dann sind wir
auch schon bei der "Community":
Die gab es bei OpenWatcom auch, hatte sich aber nicht lange gehalten.
Modula 3 war auch so ein linuxoides Ding wo ist Modula 3 jetzt?
Die Linuxuidität und die Windows/DOS-Unfreundlichkeit geht nach ->
Nischenprodukt.
Webassembly dagegen wirkt nicht so problematisch, weder von der
Zugangsseite, noch von der Nutzerseite..
https://www.reddit.com/r/WebAssembly/comments/z8jyjk/super_nintendo_emulators_online_running_on_wasm/
Basic war damals überall zu finden, und in den Volkshochschulen gab es
Programmierkurse zu verschiedenen Programmiersprachen.
In den Schulen wurden noch lange Basic-Programmierkurse gelehrt. An den
Unis teilweise (und fragwürdigerweise) mit Java abgelöst. War Java jetzt
besser als Basic?
Auf jeden Fall wurden beide Sprachen bis in die kleinste Ecke
hineingepusht.
rbx schrieb:> DOS?
Naja, ehrlich, wer will sich heutzutage noch mit dem abscheulichen "real
mode" eine 8086 herumschlagen?
Ansonsten kann ich mir nicht vorstellen, dass das soooo
Windows-untauglich ist, denn schließlich ist inzwischen im Firefox einen
nennenswerter Anteil an Rust, und da es Firefox für Windows gibt, muss
er sich ja irgendwie dafür compilieren lassen haben …
Jörg W. schrieb:> Ansonsten kann ich mir nicht vorstellen, dass das soooo> Windows-untauglich ist,
Glaube ich jetzt auch nicht, aber warte mal..
1
Rust Visual C++ prerequisites
2
3
Rust requires a linker and Windows API
4
available.
5
6
These components can be acquired throug
7
8
1) Quick install via the Visual Studio
9
(free for individuals, academic uses
10
11
2) Manually install the prerequisites
12
(for enterprise and advanced users).
13
14
3) Don't install the prerequisites
15
(if you're targetting the GNU ABI).
Quick install von VS?
Das ging schon immer schnell, und braucht auch nur ganz wenig
Speicherplatz ;)
Naja, im Ernst, die sollten erstmal zusehen, dass sie was auf FreeDOS
hinbekommen - eventuell ersparen die sich die eine oder andere
Speichermacke/Ignoranz/Arroganz, whatever, und wäre das nicht zu hoffen?
Und warum jetzt nicht was für Tiny C?
Ich bleibe bei Nischenprodukt, und denke an Modula 3 - trotz der guten
Vorraussetzungen (s.o.).
Vielleicht ist das hier ja etwas, für die ganzen Leute, die (noch) nicht
von ihrer C++-Droge weg kommen (wollen oder können).
https://www.youtube.com/watch?v=ELeZAKCN4tY
Es ist ein sehr interessanter Vortrag darüber, wie man C++ sicherer (by
default) machen könnte.
Das hat jetzt zwar nicht direkt etwas mit Rust zu tun, aber das Ergebnis
sieht schon sehr Rust-ähnlich aus. In dieser hier C++2 genannten neuen
Sprache sind viele Defaults so eingestellt, wie sie in Rust auch zu
finden sind.
Natürlich ist es bei weitem nicht so safe wie Rust, aber es wäre eine
deutliche Verbesserung des völlig kaputten C++-Zustands, mit dem wir
heute leben müssen.
MaWin schrieb:> Natürlich ist es bei weitem nicht so safe wie Rust, aber es wäre eine> deutliche Verbesserung des völlig kaputten C++-Zustands, mit dem wir> heute leben müssen.
Nur, wer braucht das? Wer etwas anders machen will, kann doch Rust
nehmen (oder Python oder …).
Thread beobachten
Seitenaufteilung abschalten