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


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


Lesenswert?

🐧 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.

von Cyblord -. (cyblord)


Lesenswert?

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.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

@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"

von Cyblord -. (cyblord)


Lesenswert?

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.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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?

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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?

von Cyblord -. (cyblord)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von Cyblord -. (cyblord)


Lesenswert?

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.

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

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.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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?

von MaWin O. (mawin_original)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von Cyblord -. (cyblord)


Lesenswert?

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.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von Cyblord -. (cyblord)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von MaWin O. (mawin_original)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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?

von Rolf M. (rmagnus)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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"

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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"?

von MaWin (Gast)


Lesenswert?

🐧 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?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

🐧 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

von cppbert (Gast)


Lesenswert?

🐧 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?

von cppbert (Gast)


Lesenswert?

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

von DPA (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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)

von Cyblord -. (cyblord)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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
int i_in, i_out;
2
for(i_in=0,i_out=0; i_out < length; i_in++){
3
  unsigned char ch = 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?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Edit: Ich meinte "i_in < length". Zu schnell getippt...

von Cyblord -. (cyblord)


Lesenswert?

> 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.

: Bearbeitet durch User
von 🐧 DPA 🐧 (Gast)


Lesenswert?

Ich denke mit einem Callback könnte man sowas sicher abstrahieren, als C 
code würde das so aussehen:
1
struct optional {
2
  bool empty;
3
  uint8_t value;
4
}
5
void inplace_replace(const size_t length, uint8_t slice[length], struct optional (*const transformer)(const uint8_t input)){
6
  for(size_t i_in=0,i_out=0; i_in < length; i_in++){
7
    const struct optional out = transformer(slice[i_in]);
8
    if(out.empty) slice[i_out++] = out.value;
9
  }
10
}

Das müsste doch so ähnlich auch in Rust machbar sein. Gibts da schon was 
in der Rust Standard Library oder so für so eine inplace_replace 
Funktion?

von cppbert (Gast)


Lesenswert?

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

von Kaj (Gast)


Lesenswert?

Ich schmeiß einfach mal nom in den Raum:
https://github.com/Geal/nom

Parser die nom nutzen:
https://github.com/Geal/nom#parsers-written-with-nom

https://github.com/Geal/nom#technical-features
1
zero-copy:
2
If a parser returns a subset of its input data, it will return a 
3
slice of that input, without copying
4
5
safe parsing: 
6
nom leverages Rust's safe memory handling and powerful types, and 
7
parsers are routinely fuzzed and tested with real world data. So far, 
8
the only flaws found by fuzzing were in code written outside of nom
9
10
speed: 
11
Benchmarks have shown that nom parsers often outperform many 
12
parser combinators library like Parsec and attoparsec, some regular 
13
expression engines and even handwritten C parsers

von cppbert (Gast)


Lesenswert?

Kaj schrieb:
> Ich schmeiß einfach mal nom in den Raum:

warum?

von cppbert (Gast)


Lesenswert?

🐧 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

von cppbert (Gast)


Lesenswert?

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

von Cyblord -. (cyblord)


Lesenswert?

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.

: Bearbeitet durch User
von cppbert (Gast)


Lesenswert?

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?

von cppbert (Gast)


Lesenswert?

🐧 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

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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?

von cppbert (Gast)


Lesenswert?

so? https://gcc.godbolt.org/z/8KGPPc35f
1
fn _main() {
2
  let mut buffer: [u8; 23] = [0; 23];
3
  let bla = true;
4
  let mut i_out = 0usize;
5
  for i_in in 0..buffer.len() 
6
  {
7
        let _ch = buffer[i_in];
8
        if bla { buffer[i_out] = 123; }
9
        i_out+=1;
10
  }
11
}

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

von DPA (Gast)


Lesenswert?

Interressant. Dann sind gewisse Formen von Aliasing ja doch möglich.

von Cyblord -. (cyblord)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

🐧 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.

von MaWin (Gast)


Lesenswert?

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.html
https://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.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> 100% memory safe

Gibts dafür ne Definition?

von DPA (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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.

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

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?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von 2⁵ (Gast)


Lesenswert?

[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.

von MaWin (Gast)


Lesenswert?

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.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

🐧 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?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

Ok, ich gebs auf. Du definierst dir deine eigene Definition von Aliasing 
zurecht, nur um Recht zu behalten.

von cppbert (Gast)


Lesenswert?

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

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

🐧 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?

von MaWin (Gast)


Lesenswert?

1
let person1 = "DPA";
2
let person2 = "DPA";
3
// 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.

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

🐧 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?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

🐧 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?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

🐧 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

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

🐧 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?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

🐧 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 :)

von MaWin (Gast)


Lesenswert?

🐧 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?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

🐧 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?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

🐧 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.

von cppbert (Gast)


Lesenswert?

🐧 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

von MaWin (Gast)


Lesenswert?

🐧 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.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

🐧 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

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

🐧 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

von MaWin (Gast)


Lesenswert?

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.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

🐧 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.

von cppbert (Gast)


Lesenswert?

🐧 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

von cppbert (Gast)


Lesenswert?

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 :)

von Thomas W. (goaty)


Lesenswert?

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...

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

wenn man viel mit C++ Tuples, Variants, Lambdas macht fühlt man sich 
gleich zuhause - auch wenn Rust gar nicht aus der Welt kommt

von cppbert (Gast)


Lesenswert?

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

von DPA (Gast)


Lesenswert?

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).

von cppbert (Gast)


Lesenswert?

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

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


Lesenswert?

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
  auto foop = (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.

von cppbert (Gast)


Lesenswert?

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)

von MaWin (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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

von Peter K. (os2fan2)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von Kaj (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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... ;-)

von foo (Gast)


Lesenswert?

>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

von MaWin (Gast)


Lesenswert?

foo schrieb:
> Der Rust Compiler umarmt einen und tröstet einen wenn man einen Fehler
> gemacht hat!

:)

Nur mal so als Beispiel:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1c37c420e4f69cc62c6bf1272793321c

Ich wüsste jetzt nicht, wie man das noch verständlicher und besser 
machen könnte.

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


Lesenswert?

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 …

von Kaj (Gast)


Lesenswert?

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:
1
let c: i32 = 42;
2
let d = 42 as i32;

von MaWin (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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
1
Rust:
2
let c: i32 = 42;
3
4
Pascal:
5
    c: integer = 42;

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


Lesenswert?

Kaj schrieb:

> So kann man es ja in Rust auch machen:
>
1
> let c: i32 = 42;
2
> let d = 42 as i32;
3
>

Finde ich zumindest besser lesbar als die Unterstriche.

von cppbert (Gast)


Lesenswert?

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

von let (Gast)


Lesenswert?

Kaj schrieb:
> So kann man es ja in Rust auch machen:

Nicht zu vergessen:
1
let e = 42i32;

von MaWin (Gast)


Lesenswert?

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.

von Kaj (Gast)


Lesenswert?

Jörg W. schrieb:
> Finde ich zumindest besser lesbar als die Unterstriche.
Bei Konstanten und globalen Variablen muss man es sogar so angeben:
1
const VAR: Type = value;
2
static var: Type = value;

von cppbert (Gast)


Lesenswert?

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?

von Cyblord -. (cyblord)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Wie würdest du denn eine Variable mit Type Inferrence ohne let
> definieren

Ich will schon gar keine Type Inference machen.

von MaWin (Gast)


Lesenswert?

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?

von cppbert (Gast)


Lesenswert?

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?

von Cyblord -. (cyblord)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Nur das NOTWENDIGE tippen.

Eben. Warum dann kein Type Inferrence?
1
let a: i32 = 1; // Typ wahrscheinlich nicht notwendig.
2
let b: i32 = 2; // Typ sicher nicht notwendig
3
let c: i32 = a + b; // Typ sicher nicht notwendig
4
//...

von cppbert (Gast)


Lesenswert?

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?

von MaWin (Gast)


Lesenswert?

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ß.

von MaWin (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

> Announcing Rust 1.65.0

https://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.

von cppbert (Gast)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

Es gibt noch ein bisschen Optimierungsbedarf mit der Stack-Nutzung

wird aber schon aktiv von Patrick Walton (Rust Entwickler bei Facebook) 
getrackt
1
The main goal is removing replacing pointless stack-to-stack copies with simply mutating in-place on the stack correctly in the first place.
2
Due to some mix of:
3
4
* Rust code relying more on copies than C++ (for esample, harder to make something uninitialized and fill it in)
5
* LLVM missing optimizations that rust relies on heavier than C++
6
* No real guarantees around RVO / NRVO

https://arewestackefficientyet.com/

https://news.ycombinator.com/item?id=33637092

von MaWin (Gast)


Lesenswert?

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.html


cppbert 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.

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> Aber sicherlich ist es etwas, das behoben werden muss.

also eher Potenzial als Problem :)

von rbx (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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?

von cppbert (Gast)


Lesenswert?

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 :)

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


Lesenswert?

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).

von Cppbert (Gast)


Lesenswert?

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

von Cppbert (Gast)


Lesenswert?

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

von rbx (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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"?

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von rbx (Gast)


Lesenswert?

MaWin schrieb:
> Assembly hat überhaupt kein Typsystem.

Das stimmt nicht. Und wenn man weniger abstrahiert, kann man beim PC AVX 
zum Addieren einsetzen, oder andere logische Operationen.
Blöd ist halt der Zugriff auf AVX. Aber logische Operationen mit 256 Bit 
sind schon sehr nett, wenn man weiß, wie man sowas nutzt.

https://www.intel.com/content/dam/develop/external/us/en/documents/36945

https://stackoverflow.com/questions/42938907/is-it-possible-to-use-simd-instructions-in-rust

Der Visual Studio Debugger war ja auch super, oder damals der 
Tasm-Debugger.
Wäre schön, wenn es sowas (oder vergleichbares) mal von diesen 
Funktional Programmiersprachen-Helden gäbe.

http://wiki.haskell.org/Research_papers/Parallelism_and_concurrency

Die Referenzen sind teilweise ganz gut, aber mittlerweile ziemlich alt.

Bei Haskell (ja, schon wieder..) muss man auch wissen, dass der Datentyp 
Double auf Performance getrimmt ist. So ähnlich wie früher Addieren mit 
AX. Oft gab es nur dieses eine Register.

Rust IDE wird wohl die gleiche sein, wie schon für Haskell:

https://github.com/rust-lang/rust-mode

von cppbert (Gast)


Lesenswert?

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...

von rbx (Gast)


Lesenswert?

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 ;)

von MaWin (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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.

von Kaj (Gast)


Lesenswert?


von Yalu X. (yalu) (Moderator)


Lesenswert?

Kaj schrieb:
> Asahi Linux: Rust-Magie macht Linux-Treiber für Apple-GPU möglich
> 
https://www.golem.de/news/asahi-linux-rust-magie-macht-linux-treiber-fuer-apple-gpu-moeglich-2211-170130.html

Man fragt sich nur, wie Apple selbst den Treiber ohne Rust hinbekommen
hat. Oder ist der Treiber mangels Rust-Magie so hingemurkst und verbugt,
dass er alle fünf Minuten abstürzt? Ich habe keinen Apple, deswegen kann
ich das nicht nachprüfen ;-)

von Kaj (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von rbx (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

rbx schrieb:
> ...

Nimm bitte weniger davon.
Oder mehr.
Jedenfalls stimmt die Menge nicht. Das ist klar.

von cppbert (Gast)


Lesenswert?

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

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


Lesenswert?

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.

von rbx (Gast)


Lesenswert?

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)

von cppbert (Gast)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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.

von Daniel A. (daniel-a)


Lesenswert?

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)

von A. B. (funky)


Lesenswert?

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

von Kaj (Gast)


Lesenswert?


von rust (Gast)


Lesenswert?


von MaWin (Gast)


Lesenswert?

Jetzt dürft ihr "denen" mal eure Meinung geigen:

https://blog.rust-lang.org/2022/12/05/survey-launch.html

von Dergute W. (derguteweka)


Lesenswert?

<heisemode>
Juhuu, das ist das Ende von Rust!!1!einself!
https://www.n-tv.de/politik/Horst-Seehofer-lernt-C--article23766893.html
</heisemode>

scnr,
WK

von MaWin (Gast)


Lesenswert?

Dergute W. schrieb:
> https://www.n-tv.de/politik/Horst-Seehofer-lernt-C--article23766893.html

Ach du meine Güte.
Seehofer lernt C++.

Noch eindeutigere Beweise dafür, dass C++ vom alten Eisen ist und am 
Ende seiner Lebenszeit angelangt ist, werden nicht mehr benötigt. ;)

von rbx (Gast)


Lesenswert?

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.

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


Lesenswert?

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 …

von rbx (Gast)


Lesenswert?

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.).

von MaWin (Gast)


Lesenswert?

Wieso werden offensichtliche Trolls wie rbx hier nicht gelöscht?

von MaWin (Gast)


Lesenswert?

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.

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


Lesenswert?

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 …).

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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