Rust - ist das hier um zu bleiben?

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

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?

Cyblord -. schrieb:
> Deine Aussage war bisher dass Rust Code automatisch sicher ist.
> Jetzt lernen wir: Außer da eben da wo er nicht sicher ist. Also da wo
> ich nicht einfach statisch zur Kompilierzeit prüfen kann.
> Und deshalb machst du so ein Fass für Rust auf?

das hat er nie gesagt nur für die geschlossenen Teile, die nicht wenig 
sind weil nicht alles in einem Kernel oder Applikation durchdringt in 
jeder Zeile Code den Kernel- oder User-Space

Rust ist safe so lange du nicht in eine andere Welt wechselst - das ist 
niemals eine Anforderung an Rust gewesen - wenn du darauf rumreiten 
willst das du es so verstanden hast ist es eben so, aber leider keine 
sinnvolle Diskussion

Cyblord -. schrieb:
> Aber dann sag mir wie Rust den Code in meinem obigen Beispiel sicher
> macht. Und zwar ohne Laufzeitoverhead.

gar nicht - weil es das für Durchdringunsschichten nicht kann und nicht 
will - das muss du Hand anlegen - kein Pro-Rust entwickler stellt das in 
frage der Gewinn ist woanders

Cyblord -. schrieb:
> MaWin O. schrieb:
>> In Rust ist diese ganze Array- und Index-Popelei sowieso nur selten
>> notwendig. Es gibt dort deutlich einfachere und sichere Konzepte wie
>> z.B. Iteratoren.
>
> Das nächste No-Go für embedded. Solche Konzepte sind für PC ja ok. Aber
> sie zeigen dass Rust auf Embedded noch ganz eigene Probleme hat.

Warum sollte das für embedded ein No-Go sein?
Langsam denke ich das du nicht sehr viel Ahnung hast - was auch deine 
bisherigen Post erklären könnte

Nicht mal ein C++-Iterator ist in embedded in jeglich Form ein Problem - 
weil so wie bei Rust ein Value-based Konzept

Versuch doch mal nur das Problem mit Iterator und embedded zu erklären - 
vielleicht verstehen wir dann endlich mal was du nicht verstehst

Cyblord -. schrieb:
> Wo finde ich den Gewinn wenn mein Array an dieser Stelle überläuft? Wo
> steckt hier der totale Vorteil von Rust? Irgendwo muss er doch sein.

die Linux-Kernel Entwickler akzeptieren Rust als erste weitere 
Programmiersprache neben C (nachdem C++ vor Jahren schon massiv 
abgelehnt wurde) weil die so viel Langeweile habe und Linus dafür 
bekannt ist immer die neusten Hype-Sprachen in den Linux Kernel 
aufzunehmen

Erklär uns doch mal warum das passiert - unter der Annahme das die nicht 
alle völlig bescheuert sind

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

Cyblord -. schrieb:
>> ich hab dich nett
>
> Äh nein. Mir Ahnungslosigkeit zu unterstellen fällt nicht unter nett. Es
> ist der typische Deppen-Abschluss einer Diskussion.

Jetzt beantworte doch einfach die Frage warum das Iterator-Konzept von 
Rust für embedded so untragbar ist und was die Gründe dafür sind warum 
du denkst das Rust überhaupt in Linux akzeptiert wurde - ich 
entschuldige mich auch dafür ein wenig ausfallend gewesen zu sein

Cyblord -. schrieb:
> 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?

Rolf M. schrieb:
> Ich hab
> lediglich gesagt, dass seine Argumente dagegen nicht stichhaltig wirken.

Ja. Und eine Begründung bleibst du uns weiterhin schuldig.
Alleine darum ging es mir.

Dass dir Linus Meinung nicht passt, habe ich verstanden.
Warum das so ist, habe ich nicht verstanden.

Rolf M. schrieb:
> Zu memcpy hab ich überhaupt nichts gesagt.

Ja, das habe ich dann verwechselt, weil das ein Gast war, der in genau 
die gleiche Tröte wie du geblasen hat.
Sinnloses Abladen von: Määh ich finde Linus Aussage blöd.

Ok, ich habe jetzt noch einmal nachgeschaut.

Rolf M. schrieb:
>> Da muss man nur anschauen, was Linus von C erwartet hat und welche
>> "features" er da haben wollte. (z.B. memcpy ganz durch memmove ersetzen
>> und weiterer Blödsinn)
>
> Nachdem ich die Gründe, die er gegen C++ im Kernel vorgebracht hat,
> gelesen habe, kann ich ihn in der Hinsicht eh nicht mehr ernst nehmen.

Schon komisch, dass du genau auf die memcpy-Sache antwortest und jetzt 
behauptest nie etwas dazu gesagt zu haben.
Du bist unehrlich.

Rolf M. schrieb:
> Nein, du legst es offenbar einfach darauf an, mich misszuverstehen.

Wir alle zusammen legen es darauf an, das scheint hier echt 
Forums-Kultur zu sein - Fehleannahmen, Empfindlichkeiten etc.

aber warum machen wir jetzt nicht einfach ein Reset und kommen wieder 
aufs technische zurück und hören auf so zu "menscheln"

Tatsächlich ist doch schon längst alles gesagt worden. Mittlerweile ist 
das doch längst nur noch ein Webethread für die Rust Fanatiker. Wenn ich 
gekonnt hätte, hätte ich den längst geschlossen. Am Anfang hatte man 
noch Vorteile, echte Nachteile & Problematische Aspekte diskutiert. Aber 
das ist schon längst wieder unter den uninteressanten "alles toll, alles 
sicher, schau, neue Features, schau, jetzt mehr Rust dort" Beiträgen 
begraben, und wird eh von keinem mehr gelesen.

Rolf M. schrieb:
> Um die konkrete Funktion ging es gar nicht.

Gut, dass wir uns dann doch einig sind.

Und wie sieht es mit einer Antwort aus?
Warum glaubst du, dass Linus nicht in der Lage ist 
Grundlagenentscheidungen zu treffen?
Ich kenne Linus Entscheidungen als sehr pragmatisch und sehr 
praxisorientiert.
Bei Entscheidungen über C++, memcpy und Rust und vielem mehr.
Der Erfolg gibt ihm Recht und seine Argumente sind für mich gut 
nachvollziehbar.

Also nun Butter bei die Fische:
Warum kannst du ihn "eh nicht mehr ernst nehmen"?

🐧 DPA 🐧 schrieb:
> "alles toll, alles
> sicher, schau, neue Features, schau, jetzt mehr Rust dort"

Und wo ist das Problem?
Ich schreibe sowohl über Vor- und Nachteile von Rust.

Ich stelle hier zu 90% eh nur Unwahrheiten von Leuten, die 
offensichtlich nie mit der Sprache gearbeitet haben, richtig.

> uninteressanten

Warum diskutierst du trotzdem mit?

Naja, Linus wird auch langsam alt. Klare ansagen kann er auch nicht mehr 
machen, die SJW haben ihn einmal kräftig unter den Bus geworfen und so 
entschärft (wobei etwas weniger erfolgreich als bei RMS). Die Maintainer 
grosser Subsysteme sind auch schon etwas ausser Kontrolle, so macht z.B. 
Intel immer mal wieder was, wo sie dann schnell einen Release 
nachschieben müssen (letztens 
https://www.phoronix.com/news/Intel-iGPU-Avoid-Linux-5.19.12, davor ging 
mal plötzlich ältere FW nicht mehr, usw.) Eigentlich sollten das die 
diversen Maintainerschichten vorher abfangen. Und mit Greg Kroah-Hartman 
ist auch schon ein Linus-Ersatz vorhanden.

Ich denke, Linus hat die Zügel längst abgegeben.

🐧 DPA 🐧 schrieb:
> Aber
> das ist schon längst wieder unter den uninteressanten "alles toll, alles
> sicher, schau, neue Features, schau, jetzt mehr Rust dort" Beiträgen
> begraben, und wird eh von keinem mehr gelesen.

das ist schon irgendwie verständlich was du sagst - aber am Anfang hiess 
es immer das wird nichts weil es kein GCC Frontend dafür gibt, und weil 
es eh nicht relevant wird, keine Standard existiert, und das es auch gar 
niemand braucht weil C++ das schon alles perfekt kann und,und,und

jetzt zieht Rust als erste weitere Sprachen in den Linux-Kernel ein (von 
dem wir denke ich alles wissen wie gross, relevant der ist und auch wie 
viele Entwickler daran arbeiten) und schon ist irgendwie klar das es die 
Linux-Kernel-Entwickler es auch nicht blicken - und das Microsoft und 
google usw. nachziehen ist ja auch nur eine allgem. blöde Idee weil die 
ihren Kram nicht unter Kontrolle bringen - aber komischerweise sind das 
die Zugpferde für alle C++ Sachen die in den letzten 15 Jahren gemacht 
wurden (pushen des C++ Standards, Sanitizer und und und)

keiner sagt das Rust die Lösung aller Problem zu 100% ist (und das hat 
MaWin auch noch nie so global für alle Kontexte vermittel)
aber zumindest eine nette Disukssion-Grundlage könnte es sein

und dann kommen hier die Python, Javascript, C und C++ Entwickler und 
lassen sich (oft) ohne Background über irgendwelche Details aus und alle 
werden irgendwie sehr schnell sehr emotional - warum auch immer

🐧 DPA 🐧 schrieb:
> Und mit Greg Kroah-Hartman
> ist auch schon ein Linus-Ersatz vorhanden.

aber der supportet doch auch pro-aktiv die Rust intergration - hat eines 
der ersten Linux-Beispiele mit dem Integrator entwickelt - also i don't 
care Linus, aber Greg hat schon viel früher mit Rust angefangen - so 
what?

und niemand hier ist so dumm zu glaube das ein schneller Einzug oder die 
Nutzung von Rust von mehreren Big-Playern irgendeine Qualitäts oder 
Perfektions-Relevanz hat, da geht es nur darum das sowas wie mit dem 
Linux-Kernel bisher einfach noch nie passiert ist und das entweder ein 
riesen Fehler ist oder eben eine sinnvolle Entscheidung - als 
Echtwelt-Gegenargument zu der ganzen Es-ist-perfekt-wie-es-ist-Fraktion

cppbert schrieb:
> aber der supportet doch auch pro-aktiv die Rust intergration

Ja eben. Ich sag ja:

🐧 DPA 🐧 schrieb:
> Ich denke, Linus hat die Zügel längst abgegeben.

DPA schrieb:
> cppbert schrieb:
>> aber der supportet doch auch pro-aktiv die Rust intergration
>
> Ja eben. Ich sag ja:
>
> 🐧 DPA 🐧 schrieb:
>> Ich denke, Linus hat die Zügel längst abgegeben.

das stimmt auch nicht weil er ist auch sehr aktiv an der Integration 
beteiligt und freut sich ja (laut der letzten Keynote) darauf die Syntax 
zu lernen und richtig damit zu arbeiten (und das wird er - weil wir ihn 
kennen, er ist kein Man der leeren Worte, war er nie)

Cyblord -. schrieb:
> cppbert schrieb:
>> das stimmt auch nicht weil er ist auch sehr aktiv an der Integration
>> beteiligt und freut sich ja (laut der letzten Keynote) darauf die Syntax
>> zu lernen und richtig damit zu arbeiten (und das wird er - weil wir ihn
>> kennen, er ist kein Man der leeren Worte, war er nie)
>
> Das klingt als wenn die KP eine Pressemitteilung über Xi rausbringt.
> Oder in Nord-Korea über Kim geredet wird.

ja schon - aber es ist doch trotzdem Realität das die beiden führenden 
Köpfe der Linux-Entwicklung das machen und google, Amazon und andere 
grosse das aktiv mit tragen - ich nehme einfach an das dir klar ist wie 
stark die grossen 5 von einem funktionierendem Linux abhängig sind

btw: du hast immer noch nicht erklärt warum das Rust Iteratoren Konzept 
eine No-go für embedded ist - wird langsam Zeit

Am Anfang des Threads, 2019, war die Frage:
> Rust - ist das hier um zu bleiben?

Damals war Rust noch in so gut wie keinem relevanten Produkt vertreten.
Viele Sachen waren unklar. Viele Features fehlten.

Heute, 2022, würde ich sagen:

> Rust - Das ist hier um zu bleiben!

Heute sind immer noch viele Sachen unklar. Viele Features fehlen immer 
noch.
Aber es hat sich enorm was getan.
Viele Fragen wurden geklärt und viele Features wurden hinzugefügt. Man 
hat begonnen an einer Referenzdoku zu arbeiten. Alternative Compiler 
nähern sich rasant dem praktischen Nutzen. Rust auf Embedded 
funktioniert einfach mittlerweile (mit unstable compilern). Etc, etc...

Und politisch ist Rust von vielen Firmen und großen Projekten als gute 
Alternative anerkannt und wird aktiv genutzt. Diese Akzeptanz breitet 
sich immer weiter aus und ist selbstverstärkend.

Hinter Rust steht ein ganz anderes Moment als hinter all den anderen 
neuen Sprachen der letzten 20 Jahre. Das liegt natürlich auch daran, 
dass Rust viele der guten Features der Sprachen der letzten 20 Jahre 
vereinen konnte. Das liegt aber auch daran, dass Rust Dinge kann, die 
andere Sprachen nicht können und wahrscheinlich auch nie können werden.

Und das Allerbeste: Wenn ihr Rust scheiße findet und es nicht verwenden 
wollt, dann verwendet es einfach nicht. So einfach ist das tatsächlich.

Es gibt gar keinen Grund hier wild herumzuspekulieren und dabei seine 
eigene völlige Unkenntnis komplett preiszugeben.
Ihr merkt das natürlich selbst nicht. Das ist klar.

Während ihr euch dann weiterhin mit C eure Bufferoverflows 
implementiert, habe ich stattdessen Spaß mit Rust.

Denn Rust macht tatsächlich Spaß. Und ich muss zugeben, dass ich das 
vorher auch nicht gedacht hätte.

Irgendwann wird Rust von einer noch besseren Sprache abgelöst werden. 
Und da freue ich mich jetzt schon drauf.

MaWin O. schrieb:
> Genau. Zum Glück kann man in Rust ja immer memcpy nutzen, weil es kein
> Aliasing gibt. Man hat also immer den Performancevorteil.

Bei aliasing geht es ja nur darum, dass man nicht mit einem 
Pointer/Referenz auf Speicher schreibt, und mit einem anderen Pointer im 
selben Scope das selbe dann wieder liest, oder? Aliasing wäre dann eine 
etwas schwächere Garantie, als dass 2 Pointer nicht auf den selben 
Speicherbereich zeigen.

In C verarbeite ich buffer manchmal inplace, nach dem Schema:

1

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?

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

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?

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

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

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

warum?

🐧 DPA 🐧 schrieb:
> Bei aliasing geht es ja nur darum, dass man nicht mit einem
> Pointer/Referenz auf Speicher schreibt, und mit einem anderen Pointer im
> selben Scope das selbe dann wieder liest, oder?

Aliasing Probleme sind auch

std::vector<int> v{1,2}
int* a = &v[0];
v.push(20);
v.push(30);
v.push(40);
v.push(50);
-> wegen copy-on-resize im std::vector is a relativ sicher dangling

passiert aber genau so mit realloc in C

Cyblord -. schrieb:
> Da passt dann die Empfehlung für memmove schon exakt ins Bild.

das war von Linus für den Linux-Kernel, für den C code, null Bezug zu 
Rust

Cyblord -. schrieb:
> cppbert schrieb:
>> das war von Linus für den Linux-Kernel, für den C code, null Bezug zu
>> Rust
>
> Aber hallo, von DEM Linus der jetzt doch voll auf Rust abfährt.
> Außerdem geht es eben um das Mindset hinter so einer Empfehlung. Da ist
> die Sprache egal.

du hast immer noch nicht erklärt warum das Rust Iteratoren Konzept
eine No-go für embedded ist - brauchst du vielleicht noch ein bisschen 
mehr Zeit?

🐧 DPA 🐧 schrieb:
> int i_in, i_out;
> for(i_in=0,i_out=0; i_out < length; i_in++){
>   unsigned char ch = buffer[i_in];
>   ...
>   if(bla) buffer[i_out++] = 123;
> }
> length = i_out;

ich sehe da keine Probleme mit Rust, wo sind da Aliasing Probleme?
In dem Beispiel ist doch alles nur Value-based, keine Pointer die 
irgendwie invalidieren

Mit i_in und i_out lese / schreibe ich vom selben buffer. Man könnte die 
quasi als 2 Pointer im selben Scope betrachten. Dennoch ist 
sichergestellt, dass ich nie mit dem einen das lese, was ich mit dem 
anderen schreibe.

Die Sache ist also punkto aliasing komplett sicher, aber ich weiss 
nicht, wie man das mit safe Rust macht / abbildet (oder ob das überhaupt 
geht). Da fehlt mir etwas die Erfahrung. Aber vielleicht kann es ja 
jemand mit dieser Erfahrung hier übersetzen, sofern es möglich ist?

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

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

🐧 DPA 🐧 schrieb:
> Sprich, i_in wird bei jedem Durchlauf inkrementiert, i_out aber nicht
> (und auch höchstens einmal), damit ist immer i_in <= i_out garantiert,
> und es ist sichergestellt, dass beim schreiben nach buffer[i_out] nie
> etwas überschrieben wird, was danach mit i_in gelesen wird. Das müsste
> also eigentlich statisch erkennbar sein.

Mit Indexen gibt es eh kein Aliasing. Weder in C noch in Rust.

🐧 DPA 🐧 schrieb:
> Kann man dieses Pattern, diesen Konstraint, in safe Rust bereits
> effektiv abdecken

Klar.

Cyblord -. schrieb:
> Bei allem was wir hier inzwischen über Rust lesen, solltest du Speicher
> im Überfluss haben.
> In-Place kann da gar nichts gehen.

Kompletter Unsinn. Das ist genau wieder so ein Beitrag, wo du dich als 
komplett ahnungslos im Bezug auf Rust outest. "kann gar nicht gehen". 
Soso.
Wieso fragst du nicht stattdessen "kann das gehen?"? Falsches als Fakt 
hinzustellen und dann beleidigt sein wenn man korrigiert wird, das ist 
das größte Problem an diesem Thread.

In-Place hat überhaupt gar nichts mit Aliasing zu tun.

Wenn man eine mutable-Referenz hat, kann man damit natürlich machen, was 
man will. Lesen, Schreiben, in beliebiger Reihenfolge auf beliebigen 
Indexen.

Cyblord -. schrieb:
> Außerdem geht es eben um das Mindset hinter so einer Empfehlung.

Was meinst du damit?

🐧 DPA 🐧 schrieb:
> Die Sache ist also punkto aliasing komplett sicher, aber ich weiss
> nicht, wie man das mit safe Rust macht / abbildet

Ziemlich ganz genau so, wie du es auch in C schreibst.
Das unterscheidet sich nur syntaktisch minimalst und 
logisch/algorithmisch überhaupt nicht.

🐧 DPA 🐧 schrieb:
> Man könnte die quasi als 2 Pointer im selben Scope betrachten

Es sind aber keine 2 Pointer. Und es sind keine 2 Referenzen.
In Rust gibt es eine ganz klare Unterscheidung zwischen Referenzen und 
Indexen.

In Rust gibt es keine schwammigen Linien zwischen Pointern, Referenzen, 
Arrays, Indexen.
Das sind vier völlig verschiedene Datentypen, zwischen denen explizit 
konvertiert werde muss, wenn das denn gewünscht ist. In der Regel ist 
das aber nicht notwenig oder sogar unsafe.

Sowas wie Arrays, die in Pointer zerfallen oder Indexzugriffe, die 
eigentlich nur Syntaxzucker für Pointerarithmetik sind gibt es in Rust 
gar nicht. Indexzugriffe sind Indexzugriffe über die ganz klar 
definierten Index und IndexMut Traits.

Cyblord -. schrieb:
> DPA schrieb:
>> Interressant. Dann sind gewisse Formen von Aliasing ja doch möglich.

Nein. Indexe sind keine Aliase.

https://doc.rust-lang.org/std/ops/trait.Index.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.

Logisch sind die Konzepte aber äquivalent, unabhängig von der 
Programmiersprache. Ob ich 2 Pointer oder 2 Indexe habe, im moment des 
Zugriffs wird genau die selbe Stelle geladen / geschrieben.

Damit lässt sich dann in Rust auch ein logisches äquivalent zu memmove 
abbilden, halt dann mit Indexen, statt Pointern.

Cyblord -. schrieb:
>> 100% memory safe
> Gibts dafür ne Definition?

Findest du sicher in der Rust-Referenz.
Darunter fallen: Kein UB, kein Use-After-Free und keine Data Races.

DPA schrieb:
> Logisch sind die Konzepte aber äquivalent

In diesem Fall schon. Ja. Wenn man in C denkt.

> unabhängig von der
> Programmiersprache. Ob ich 2 Pointer oder 2 Indexe habe, im moment des
> Zugriffs wird genau die selbe Stelle geladen / geschrieben.

Das ist halt die C-Denkweise. In Safe-Rust gibt es gar keine 
Pointerarithmetik. (Ja ja, Arithmetik gibts schon, aber man kann das 
Ergebnis nicht dereferenzieren).

Somit erübrigt sich die Frage in Rust, ob Pointerarithmetik das gleiche 
wäre wie Indexarithmetik. Diese Frage kann man wenn dann überhaupt nur 
in Unsafe-Rust stellen und beantworten.

DPA schrieb:
> Damit lässt sich dann in Rust auch ein logisches äquivalent zu memmove
> abbilden, halt dann mit Indexen, statt Pointern.

Ein äquivalent zu memmove ist, wie mehrfach schon gesagt, in Rust 
überhaupt gar nicht notwendig. Rust kopiert alles mit memcpy, weil es 
kein Aliasing gibt. (Kein mutable Aliasing. Aliasing auf Immutables gibt 
es natürlich. Aber da kann halt auch niemand drauf schreiben).

Und ob du jetzt deinen InPlace-Algorithmus oder etwas anderes schreibst, 
das hat doch gar nichts mit memmove zu tun.
Ein InPlace-Algorithmus hat doch per Definition immer nur ein Ownership. 
Also auch nur eine mutable-Referenz. Zwei Mutable-Referenzen gehen in 
Rust nicht. Aber die braucht man auch gar nicht. (Auch nicht in C.)

Irgendwie kommt es mir vor, als würden wir da aneinander vorbei reden.

MaWin schrieb:
> Das ist halt die C-Denkweise. In Safe-Rust gibt es gar keine
> Pointerarithmetik.

Nein, mein Argument ist ein rein logisches. Welche Terminologie oder 
Semantik Rust oder C dort verwenden, ist irrelevant.

Der Rest mag ja alles stimmen. Aber fundamental logisch betrachtet, ist 
und bleibt es ein spezieller Fall von erlaubtem Aliasing. Auch wenn die 
Rust läute das nicht so nennen und nicht wahr haben wollen.

PS: Klar, das ist hier sinnvoll (also ein feature, kein bug), und mit 
vernachlässigbaren negativen Implikationen. Es geht mir hier um logische 
Konsistenz bei der Betrachtung & Argumentation über des Systems, und 
nicht darum, ein praktisches Problem heraufzubeschwören, wo keines ist.

Cyblord -. schrieb:
> Am Ende wird alles zu ASM Code und da gibts dann wieder direkte (und
> indirekte) Pointer auf den Speicher.

> Also was soll so ein Geschwätz?

Es zeigt sehr schön, dass du keine Ahnung davon hast, wie Sprachen 
definiert sind.
Rust arbeitet, genau wie C auch, auf Basis eines virtuellen 
Maschinenmodell. In welches asm das dann irgendwann einmal übersetzt 
wird, spielt überhaupt keine Rolle. Weder in Rust, noch in C.

Es ist Rust als Sprache völlig egal, ob das Backend das Programm in Code 
für Maschinen mit oder ohne Pointer übersetzt. (Ja, ich weiß, dass es da 
cornercases gibt. (vgl. Cheri-Architektur). Aber keine dieser 
Cornercases führen zu UB oder Verlust von Rust-Garantien. Und daran wird 
gearbeitet.)

Erst nachdem Rust seine Sicherheitsgarantien statisch geprüft hat, wird 
die Kontrolle an LLVM übergeben. Dieser generiert dann irgendwann Code 
draus. Mit Rust hat das aber nichts mehr zu tun.

Die paar wenigen verbliebenen Sicherheitsgarantien, die Rust nicht 
statisch prüfen kann, resultieren dann in entsprechendem asm-Code, der 
zur Laufzeit die Dinge prüft.

[Linus ist gegen C++ im Kernel aber für Rust]

Der Grund dafür ist doch relativ einfach: Linus war schon immer ein 
Assembler Hacker und hat halt irgendwann (pragmatisch) C als Assembler 
Ersatz akzeptiert. Er denkt aber immer noch als Assembler Hacker, d.h. 
bei Änderungen in C sieht er relativ schnell den Assembler Code, den den 
Compiler generiert, vor sich. Das kann er (und auch viele andere C 
Hacker) bei C++ nicht mehr so gut. C++ ist standardisiert, mit einem 
Zulassen von C++ wurden die ganzen teilweise obskur wirkenden C++ 
Formulierungen in den Kernel Einzug halten. Die Schnittmenge sehr guter 
Kernel Hacker und sehr guter C++ Programmierer ist nicht so groß. Wer 
soll denn verantwortungsvoll den neuen C++ Code im Kernel reviewen? Die 
"alte" Kernel-Hacker-Gilde eher nicht.
Einzelne C++ Features auszuschließen würde die Sache nicht besser 
machen, würde wohl in einem größeren Krieg enden. Aber ein paar Features 
wird man ausschließen müssen...
Nun ist aber Linus pragmatisch genug, um zu sehen, dass der Kernel auch 
eine Weiterentwicklung in Bezug auf Programmiersprache braucht. Rust hat 
dabei gegenüber C++ ein paar pragmatische Vorteile

a) bringt Sprachfeatures mit, die gut in den Bereich Betriebssystem 
passen

b) gleichzeitig klein genug, um es in vernünftiger Zeit zu lernen

c) Weit genug weg von C um keinen C/C++ Mischmasch entstehen zu lassen

d) gleichzeitig neu genug, um noch Einfluss auf die Sprachkonzepte zu 
nehmen um diese sinnvoll für Systemprogrammierung/Embedded zu entwickeln

e) Es gibt kaum Linux-Rust-Hacker, die Linus/die ganzen alten Linux 
Hacker zeigen würden, dass er bei Rust keine Ahnung hat bzw. es ist zzt. 
noch kein Problem, wenn ein "gestandener" Programmierer wenig Ahnung von 
Rust hat.

f) Geht die Sache mit Rust schief, kann man zur Not Rust besser als C++ 
wieder loswerden.

Cyblord -. schrieb:
> Per welcher Definition?

Der Rust-Definition. Ich habe jetzt echt keine Lust für dich zu googlen.

🐧 DPA 🐧 schrieb:
> ist und bleibt es ein spezieller Fall von erlaubtem Aliasing.

Das ist und bleibt Quatsch. Sowohl in C als auch in Rust.
Aliasing ist ein Konzept, das auf Typebene stattfindet. Indexierung ist 
ein Konzept, das auf Typ und auf Codeebene stattfindet.

In Rust sind Typ- und Codeebene viel besser getrennt als in C.

Eine Referenz ist kein Pointer.
Ein Pointer ist keine Adresse.
Eine Adresse ist keine Zahl (sieht man bei Cheri schön).
Ein Index hat mit Pointertypen und Referenztypen gar nichts zu tun.
Ein Index ist eine Zahl.

Das sind alles unterschiedliche Konzepte, die C vermischt und Rust aber 
(fast) alle strikt voneinander trennt.
Mehr kann ich dazu leider nicht mehr sagen.

Es ist simpel. Der Zugriff auf etwas braucht eine Referenz im 
allgemeinen sinne irgendwelcher Form darauf. Ob das ein Handle, ein 
Pointer, oder eine Kombination davon ist, ist da erstmal egal. Hat man 
es mit 2 Referenzen zutun, die auf das selbe verweisen, und man auf 
diese zugreift, hat man es mit aliasing im allgemeinen sinne zutun.

Es ist sinvoll, solche Konzepte verallgemeinert (unabhängig einer 
konkreten Sprache) betrachtet zu können, um Sprachunabhängig logische 
Überlegungen zu Situationen, welche diese involvieren, machen zu können. 
Und das hat hier ja auch sehr gut funktioniert. Jetzt kennen wir den 
gesamten Sachverhalt in Bezug auf Rust viel genauer, inklusive wie Rust 
diesen betrachtet.

🐧 DPA 🐧 schrieb:
> Es ist simpel. Der Zugriff auf etwas braucht eine Referenz im
> allgemeinen sinne irgendwelcher Form darauf. Ob das ein Handle, ein
> Pointer, oder eine Kombination davon ist, ist da erstmal egal. Hat man
> es mit 2 Referenzen zutun, die auf das selbe verweisen, und man auf
> diese zugreift,

Korrekt.
Wenn man einen Pointer hat und mit zwei unterschiedlichen Indexe auf 
unterschiedliche Elemente zugreift, dann sind das unterschiedliche 
Elemente. Also kein Aliasing.
Auch in C nicht.

Verstehst du es nun?

Die Kombination Pointer + Index ist in den 2 Stellen als eine Referenz 
auf etwas im allgemeinen Sinne zu betrachten. Es spielt keine rolle, ob 
Rust oder C das als Aliasing bezeichnen. Im allgemeinen sinne ist es 
aber genau das.

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

Cyblord -. schrieb:
> DPA schrieb:
>> Interressant. Dann sind gewisse Formen von Aliasing ja doch möglich.
>
> Rust ist 100% sicher, außer in den Welten in denen es nicht sicher ist.

du hast immer noch nicht beschreiben warum das Rust Iterator-Konzept ein 
No-go für embedded ist

langsam denke ich schon das du recht anhnungslos bis, oder einfach nicht 
in der Lage bist gemachte Statements zu begründen

Ohne ein allgemeines Konzept von Aliasing wäre es nicht möglich, darüber 
unabhängig von der Programmiersprache nachzudenken, und diese zu 
vergleichen. Programmiersprachen verwenden und benennen die selben sowie 
die verschiedensten Konzepte und Variationen davon, ziemlich beliebig. 
Es ist ziemlich einschränkend, wenn man nichts unabhängig von der 
Sprache konzeptualisieren kann/darf.

🐧 DPA 🐧 schrieb:
> Ohne ein allgemeines Konzept

Ja. DPA. Du hast Recht. In allen Punkten.
Nach deiner Definition gibt es Aliasing in Rust. Nach deiner Definition 
gibt es alles, was du zurechtdefinierst in Rust.

Ist das nun ausreichend, damit du mit dem Unfug aufhörst?

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.

MaWin schrieb:
> Aber schön, dass wir nun auch DPA's Definition von Aliasing kennen.

Ich glaube DPA driftet gerade zur guten Seite der Macht (mit ein wenig 
unklaren Aussagen, aber er versuchts) - bisschen weniger agro reicht 
auch

🐧 DPA 🐧 schrieb:
> Es spielt keine rolle, ob
> Rust oder C das als Aliasing bezeichnen. Im allgemeinen sinne ist es
> aber genau das.

Aliasing ist ein Sprachkonzept - das kann jede Sprache für sich 
definieren oder nicht - das ist kein allgmeines Hardwarekonzept - oder 
hab deine Aussage falsch verstanden?

MaWin schrieb:
> Nach DPA's "allgemeinen Aliasing-Definition" wäre das also Aliasing.

Das hängt in dem konkreten Beispiel von der Implementierung, und davon 
was "machewas" macht, ab. Oder zumindest würde es das dann, wenn man 
darauf zugriffe, aber in dem Beispiel weiss man das ja nicht. Angenommen 
es handelt sich um Rust (der selbe Code ist auch in ein paar anderen 
Sprachen, z.B. JS gültig), wäre es aber immerhin nicht mut (in rust 
Terminologie), immerhin weiss man also, das da nicht reingeschrieben 
wird, womit das ganze dann in dem Beispiel auch wieder keine grosse 
Rolle mehr spielen dürfte.

🐧 DPA 🐧 schrieb:
> MaWin schrieb:
>> Nach DPA's "allgemeinen Aliasing-Definition" wäre das also Aliasing.
>
> Das hängt in dem konkreten Beispiel von der Implementierung, und davon
> was "machewas" macht, ab. Oder zumindest würde es das dann, wenn man
> darauf zugriffe, aber in dem Beispiel weiss man das ja nicht. Angenommen
> es handelt sich um Rust (der selbe Code ist auch in ein paar anderen
> Sprachen, z.B. JS gültig), wäre es aber immerhin nicht mut (in rust
> Terminologie), immerhin weiss man also, das da nicht reingeschrieben
> wird, womit das ganze dann in dem Beispiel auch wieder keine grosse
> Rolle mehr spielen dürfte.

Was möchtest du uns sagen? dein genanntes Beispiel ist in allen Sprachen 
die C/JS/Rust/Java/C#-Artig sind Aliasing frei - geht es hier immer noch 
um Aliasing?

cppbert schrieb:
> 🐧 DPA 🐧 schrieb:
>> Es spielt keine rolle, ob
>> Rust oder C das als Aliasing bezeichnen. Im allgemeinen sinne ist es
>> aber genau das.
>
> Aliasing ist ein Sprachkonzept - das kann jede Sprache für sich
> definieren oder nicht - das ist kein allgmeines Hardwarekonzept - oder
> hab deine Aussage falsch verstanden?

Das Aliasing Konzept dient dazu, über Dinge Rückschlüsse ziehen zu 
können, wie z.B. ob der Compiler lese / schreibzugriffe umsortieren und 
wegoptimieren kann, ohne das Verhalten zu ändern. Aber es ist auch 
nützlich, um über Situationen argumentieren zu können, wo gleichwertige 
Referenzen ungültig werden. Unter diesen Gesichtspunkten kann man 
Aliasing verallgemeinert betrachten & definieren, als rein abstraktes 
Konzept. Man muss nur schauen, worauf kommt es tatsächlich an? Es ergibt 
sich dann quasi von selbst.

cppbert schrieb:
> Was möchtest du uns sagen? dein genanntes Beispiel ist in allen Sprachen
> die C/JS/Rust/Java/C#-Artig sind Aliasing frei - geht es hier immer noch
> um Aliasing?

In dem Beispiel von MaWin gibt es diverse Compiler, die die Strings 
zusammenfassen, weil sie die selben sind. Unter diesen umständen könnten 
die 2 Referenzen sich auf das selbe Objekt beziehen, und es gibt fälle, 
wo das relevant ist.

🐧 DPA 🐧 schrieb:
> cppbert schrieb:
>> 🐧 DPA 🐧 schrieb:
>>> Es spielt keine rolle, ob
>>> Rust oder C das als Aliasing bezeichnen. Im allgemeinen sinne ist es
>>> aber genau das.
>>
>> Aliasing ist ein Sprachkonzept - das kann jede Sprache für sich
>> definieren oder nicht - das ist kein allgmeines Hardwarekonzept - oder
>> hab deine Aussage falsch verstanden?
>
> Das Aliasing Konzept dient dazu, über Dinge Rückschlüsse ziehen zu
> können, wie z.B. ob der Compiler lese / schreibzugriffe umsortieren und
> wegoptimieren kann, ohne das Verhalten zu ändern. Aber es ist auch
> nützlich, um über Situationen argumentieren zu können, wo gleichwertige
> Referenzen ungültig werden. Unter diesen Gesichtspunkten kann man
> Aliasing verallgemeinert betrachten & definieren, als rein abstraktes
> Konzept. Man muss nur schauen, worauf kommt es tatsächlich an? Es ergibt
> sich dann quasi von selbst.

das ist bekannt, wer es noch nicht weiß der kann: 
https://en.wikipedia.org/wiki/Aliasing_(computing) durchlesen

> cppbert schrieb:
>> Was möchtest du uns sagen? dein genanntes Beispiel ist in allen Sprachen
>> die C/JS/Rust/Java/C#-Artig sind Aliasing frei - geht es hier immer noch
>> um Aliasing?

> In dem Beispiel von MaWin gibt es diverse Compiler, die die Strings
> zusammenfassen, weil sie die selben sind. Unter diesen umständen könnten
> die 2 Referenzen sich auf das selbe Objekt beziehen, und es gibt fälle,
> wo das relevant ist.

das würden (manche Compiler) nur dann machen wenn die imutable sind - 
dann gibt es auch kein schreiben und daher auch kein Konfliktpotenzial

cppbert schrieb:
> das würden (manche Compiler) nur dann machen wenn die imutable sind -
> dann gibt es auch kein schreiben und daher auch kein Konfliktpotenzial

Das ist bei rust der Default. Wobei ich nicht weiss, ob rust Compiler 
die Strings zusammenfassen, und ich auch nicht weiss, ob Rust das 
definiert oder nicht.

Ein fall, wo so etwas aber Konfliktpotenzial bietet, ist bei 
Vergleichen. Falls die Sprache eine Möglichkeit bietet, Referenzen zu 
vergleichen, und die in dem fall dann gleich wären. Wenn diese 
Voraussetzungen gegeben sind, kann man gewisse Fehler machen.

🐧 DPA 🐧 schrieb:
> cppbert schrieb:
>> das würden (manche Compiler) nur dann machen wenn die imutable sind -
>> dann gibt es auch kein schreiben und daher auch kein Konfliktpotenzial
>
> Das ist bei rust der Default.

weil die beiden immutable sind

> Wobei ich nicht weiss, ob rust Compiler
> die Strings zusammenfassen, und ich auch nicht weiss, ob Rust das
> definiert oder nicht.

also weisst du irgendwie gar nichts genaues dazu :)

> Ein fall, wo so etwas aber Konfliktpotenzial bietet, ist bei
> Vergleichen. Falls die Sprache eine Möglichkeit bietet, Referenzen zu
> vergleichen, und die in dem fall dann gleich wären. Wenn diese
> Voraussetzungen gegeben sind, kann man gewisse Fehler machen.

das klingt so als vermutest du eine Lücke im Rust Konzept, oder
driften wir gerade in ein anderes Thema?

cppbert schrieb:
> das klingt so als vermutest du eine Lücke im Rust Konzept, oder
> driften wir gerade in ein anderes Thema?

Nein, Rust wird das schon richtig machen. Das ist nur einfach eine 
Allgemeine Sichtweise, wie ich solche Sachen betrachte, und wie ich über 
solche Dinge generell nachdenke.

Vielleicht kommt das wirklich auch ein wenig vom Arbeiten mit C. Da muss 
man, neben der Sprachsyntax, Semantik, usw. auch diese allgemeinen 
Konzepte alle immer im Überblick haben, sonst kann man dort Fehler 
machen. Im Umkehrschluss hiesse das dann, dass wen Rust einem dies 
abnimmt, ... Aber öffnen wie diese Büchse der Pandora mal lieber nicht.

🐧 DPA 🐧 schrieb:
> cppbert schrieb:
>> das klingt so als vermutest du eine Lücke im Rust Konzept, oder
>> driften wir gerade in ein anderes Thema?
>
> Nein, Rust wird das schon richtig machen. Das ist nur einfach eine
> Allgemeine Sichtweise, wie ich solche Sachen betrachte, und wie ich über
> solche Dinge generell nachdenke.

Jetzt wirst du zu esotherisch... oder besser gesagt du verwässerst deine 
Klarheit

das ist hier auch oft das Problem: Konkrekte, kleine Themen werden nicht 
auf ihrem Level diskutiert und dann fängt irgendwann so eine allgmeine. 
Sprachdesign-Welle an und am Ende gibt es kein Ergebnis - bis MaWin 
irgendeine Neuigkeit einstellt und dann geht das wieder von vorne los :)

🐧 DPA 🐧 schrieb:
> Das hängt in dem konkreten Beispiel von der Implementierung, und davon
> was "machewas" macht, ab.

Ah. Komisch. Eben war es noch möglich eine allgemeine Definition zu 
haben. Plötzlich ist sie nicht mehr allgemein.

Du hast völlig Recht, dass es von der Sprache abhängt.
Dann lasse mich das mal etwas präziser formulieren: Ein 
Pointer-Aliasing, wie es C definiert, gibt es in Rust für 
mutable-Referenzen nicht.
Würdest du da mitgehen?

🐧 DPA 🐧 schrieb:
> Ein fall, wo so etwas aber Konfliktpotenzial bietet, ist bei
> Vergleichen. Falls die Sprache eine Möglichkeit bietet, Referenzen zu
> vergleichen, und die in dem fall dann gleich wären. Wenn diese
> Voraussetzungen gegeben sind, kann man gewisse Fehler machen.

Es gibt in Rust keine zwei Referenzen, die auf das gleiche Objekt 
zeigen, wenn eine oder mehrere davon mutable sind. Das versuchen wir dir 
hier seit Stunden beizubringen.

🐧 DPA 🐧 schrieb:
> Vielleicht kommt das wirklich auch ein wenig vom Arbeiten mit C. Da muss
> man, neben der Sprachsyntax, Semantik, usw. auch diese allgemeinen
> Konzepte alle immer im Überblick haben, sonst kann man dort Fehler
> machen. Im Umkehrschluss hiesse das dann, dass wen Rust einem dies
> abnimmt,

Völlig richtig. Endlich hast du es verstanden.

> ... Aber öffnen wie diese Büchse der Pandora mal lieber nicht.

Warum nicht?
Könnte es zu Erkenntnis führen?

MaWin schrieb:
> 🐧 DPA 🐧 schrieb:
>> Das hängt in dem konkreten Beispiel von der Implementierung, und davon
>> was "machewas" macht, ab.
>
> Ah. Komisch. Eben war es noch möglich eine allgemeine Definition zu
> haben. Plötzlich ist sie nicht mehr allgemein.

Die Definition ist trotzdem noch allgemein. Das konkrete Beispiel ist es 
nicht. Und nachfolgend habe ich dann ja genauer beschrieben, unter 
welchen umständen es dort zu Aliasing kommen kann, bei diesem Beispiel.

Wenn ich sage, es gibt grüne Wände, und du sagst, dort ist eine Wand, 
ist die Grün? Dann kann ich allgemein schlussfolgern, dass die 
Möglichkeit besteht, dass die Wand grün sein könnte. Das macht meine 
Aussage nicht weniger Allgemein, und es macht Beschreibung nicht weniger 
spezifisch. Ich kann nichts genaueres sagen, aber ich kann doch etwas 
dazu sagen.
Und beim vorherigen Beispiel, konnte ich doch schon sehr viel dazu 
sagen.

MaWin schrieb:
> Ein
> Pointer-Aliasing, wie es C definiert, gibt es in Rust für
> mutable-Referenzen nicht.
> Würdest du da mitgehen?
>
> 🐧 DPA 🐧 schrieb:
>> Ein fall, wo so etwas aber Konfliktpotenzial bietet, ist bei
>> Vergleichen. Falls die Sprache eine Möglichkeit bietet, Referenzen zu
>> vergleichen, und die in dem fall dann gleich wären. Wenn diese
>> Voraussetzungen gegeben sind, kann man gewisse Fehler machen.
>
> Es gibt in Rust keine zwei Referenzen, die auf das gleiche Objekt
> zeigen, wenn eine oder mehrere davon mutable sind.

das sind Beispiele für grosse Unterschiede zu bestehenden 
Programmiersprachen (C,C++,Java,C#), aber da sich die wenigsten mit 
diesen Details überhaupt auskennen können sie die Bedeutung sehr einfach 
als unrelevant empfinden

🐧 DPA 🐧 schrieb:
> Die Definition ist trotzdem noch allgemein. Das konkrete Beispiel ist es
> nicht. Und nachfolgend habe ich dann ja genauer beschrieben, unter
> welchen umständen es dort zu Aliasing kommen kann, bei diesem Beispiel.

aber eben nicht in Rust und darum geht doch hier, oder?

MaWin schrieb:
> Ein Pointer-Aliasing, wie es C definiert, gibt es in Rust für
> mutable-Referenzen nicht.
> Würdest du da mitgehen?

Wieso sollte ich? Ich habe nie von Pointer-Aliasing, wie es C definiert, 
geredet, sondern mich auf das zugrundeliegende abstrakte Konzept 
bezogen. Du fährst dich so darauf fest, das nur im Kontext einer 
spezifischen Sprache betrachten zu wollen.

cppbert schrieb:
> aber eben nicht in Rust und darum geht doch hier, oder?

Doch, die ist genau so anwendbar. Das C und Rust seine eigene 
Terminologie und eigene Definitionen vom Begriff haben, ist da nicht 
relevant.

MaWin schrieb:
>> ... Aber öffnen wie diese Büchse der Pandora mal lieber nicht.
>
> Warum nicht?
> Könnte es zu Erkenntnis führen?

Was passiert mit Piloten, die immer nur den Autopiloten Fliegen lassen? 
Sie verlernen es, selbst zu fliegen.

🐧 DPA 🐧 schrieb:
> Du fährst dich so darauf fest,

Nein. Du redest dich hier raus.

> das nur im Kontext einer
> spezifischen Sprache betrachten zu wollen.

Es geht hier um Rust.

🐧 DPA 🐧 schrieb:
> Doch, die ist genau so anwendbar.

Ja. Wie gesagt, unter deiner Definition gibt es "Aliasing" in Rust.

🐧 DPA 🐧 schrieb:
> Wieso sollte ich? Ich habe nie von Pointer-Aliasing, wie es C definiert,
> geredet, sondern mich auf das zugrundeliegende abstrakte Konzept
> bezogen. Du fährst dich so darauf fest, das nur im Kontext einer
> spezifischen Sprache betrachten zu wollen.

das ist aber kein "abstraktes" sondern ein Sprachen-Konzept - das kannst 
du nicht allgemein definieren - das Rust-Design ist extra so definiert 
das Aliasing über das Typ-System nicht ausdrückbar ist, Bedeutet: Rust 
supportet kein Aliasing

🐧 DPA 🐧 schrieb:
> Was passiert mit Piloten, die immer nur den Autopiloten Fliegen lassen?
> Sie verlernen es, selbst zu fliegen.

Rust ist kein Autopilot.
Rust ist ein permanenter Fluglehrer, der ständig neben dem Piloten sitzt 
und Pilotenfehler sofort korrigiert, bevor sie zu Flugfehlern führen.

cppbert schrieb:
> das ist aber kein "abstraktes" sondern ein Sprachen-Konzept

Du hat doch selbst auf 
https://en.wikipedia.org/wiki/Aliasing_(computing) verlinkt, wo das auch 
allgemein gehalten, mit Beispielen in mehreren Sprachen, ist.

Natürlich gibt es das als allgemeines, abstraktes Konzept.

cppbert schrieb:
> 🐧 DPA 🐧 schrieb:
>> Wieso sollte ich? Ich habe nie von Pointer-Aliasing, wie es C definiert,
>> geredet, sondern mich auf das zugrundeliegende abstrakte Konzept
>> bezogen. Du fährst dich so darauf fest, das nur im Kontext einer
>> spezifischen Sprache betrachten zu wollen.
>
> das ist aber kein "abstraktes" sondern ein Sprachen-Konzept - das kannst
> du nicht allgemein definieren - das Rust-Design ist extra so definiert
> das Aliasing über das Typ-System nicht ausdrückbar ist, Bedeutet: Rust
> supportet kein Aliasing

aber natürlich kannst du Aliasing-Probleme in unsafe erzeugen - weil du 
da (sehr eingeschränkt) C-Semantik hast - aber wir reden nicht von 
unsafe weil das der geringste Teil des Projektes sein sollte und niemals 
schlimmer ist als was man mit C machen kann

🐧 DPA 🐧 schrieb:
> cppbert schrieb:
>> das ist aber kein "abstraktes" sondern ein Sprachen-Konzept
>
> Du hat doch selbst auf
> https://en.wikipedia.org/wiki/Aliasing_(computing) verlinkt, wo das auch
> allgemein gehalten, mit Beispielen in mehreren Sprachen, ist.
>
> Natürlich gibt es das als allgemeines, abstraktes Konzept.

natürlich - aber nicht ohne Sprachebezug - somit nicht mehr 
allgemein/abstrakt

cppbert schrieb:
> 🐧 DPA 🐧 schrieb:
>> cppbert schrieb:
>>> das ist aber kein "abstraktes" sondern ein Sprachen-Konzept
>>
>> Du hat doch selbst auf
>> https://en.wikipedia.org/wiki/Aliasing_(computing) verlinkt, wo das auch
>> allgemein gehalten, mit Beispielen in mehreren Sprachen, ist.
>>
>> Natürlich gibt es das als allgemeines, abstraktes Konzept.
>
> natürlich - aber nicht ohne Sprachebezug - somit nicht mehr
> allgemein/abstrakt

Doch, auch ohne Sprachebezug. Wie fängt der Artikel an? Mit  "In 
*computing*". Nicht mit "In Rust" oder mir "In C". Es gibt in dem 
Artikel auch konkrete Beispiele, aber eben, als Beispiele, nicht als 
Definition.

🐧 DPA 🐧 schrieb:
> Doch, auch ohne Sprachebezug. Wie fängt der Artikel an? Mit  "In
> *computing*". Nicht mit "In Rust" oder mir "In C". Es gibt in dem
> Artikel auch konkrete Beispiele, aber eben, als Beispiele, nicht als
> Definition.

Du hast ganz doll recht - so lange du nicht wieder von Aliasing in 
zusammenhang mit (Safe)Rust sprichst, weil es das dort nicht gibt

cppbert schrieb:
> aber wir reden nicht von
> unsafe weil das der geringste Teil des Projektes sein sollte und niemals
> schlimmer ist als was man mit C machen kann

Genau. In der Praxis ist der allerkleinste Teil des Projekts unsafe. In 
den allermeisten meiner Projekte ist gar kein unsafe drin. Und das ist 
nicht nur bei mir so.

Wenn man allerdings unsafe-Rust-Code schreibt, dann ist das deutlich 
anspruchsvoller korrekt zu tun, als normales C zu schreiben. Vor allem 
wenn man so Dinge wie Pointer oder Transmutation verwendet oder bewusst 
gegen RAII verstößt.

Der Grund dafür ist, dass man alle Dinge beachten muss, die man in C 
auch beachten muss. Und zusätzlich muss man noch sicherstellen, dass die 
Rust-Safety-Garantien eingehalten werden. Und zwar auch im restlichen 
Safe-Code.
Unsafe-Codeabschnitte können Auswirkungen auf Safe-Code haben. Safe-Code 
darf nicht unsafe werden durch unsafe-Code.

MaWin schrieb:
> 🐧 DPA 🐧 schrieb:
>> Was passiert mit Piloten, die immer nur den Autopiloten Fliegen lassen?
>> Sie verlernen es, selbst zu fliegen.
>
> Rust ist kein Autopilot.
> Rust ist ein permanenter Fluglehrer, der ständig neben dem Piloten sitzt
> und Pilotenfehler sofort korrigiert, bevor sie zu Flugfehlern führen.

Bei dem konkreten Flugzeugmodell, versteht sich. Da lernt er dieses 
spezifische Modell zu bedienen. Mehr aber auch nicht.

Und manchmal braucht man einen kleinen Crash, ein kleines Desaster, um 
wirklich zu verstehen, warum man tun muss was man tun muss.

cppbert schrieb:
> Du hast ganz doll recht - so lange du nicht wieder von Aliasing in
> zusammenhang mit (Safe)Rust sprichst, weil es das dort nicht gibt

Dann verstehst du das allgemeine Konzept selbst für sich genommen wohl 
noch nicht richtig.

🐧 DPA 🐧 schrieb:
> Bei dem konkreten Flugzeugmodell, versteht sich. Da lernt er dieses
> spezifische Modell zu bedienen. Mehr aber auch nicht.

Mit dem Erlernen von Rust habe ich mindestens soviel über C/C++ gelernt, 
wie über Rust. Und ich habe vorher über 20 Jahre C/C++ entwickelt.

🐧 DPA 🐧 schrieb:
> cppbert schrieb:
>> Du hast ganz doll recht - so lange du nicht wieder von Aliasing in
>> zusammenhang mit (Safe)Rust sprichst, weil es das dort nicht gibt
>
> Dann verstehst du das allgemeine Konzept selbst für sich genommen wohl
> noch nicht richtig.

ich denke gut genug - da die Definitionen logisch und simpel sind 
verstehe ich nicht was daran überhaupt unverständlich sein soll

cppbert schrieb:
> ich denke gut genug - da die Definitionen logisch und simpel sind
> verstehe ich nicht was daran überhaupt unverständlich sein soll

aber vielleicht helfen mir da meine geballten 30 Jahren C/C++, Assembler 
und Reverse-Engineering Erfahrung :)

Thomas W. schrieb:
> Mache gerade das Rust Buch durch (doc.rust-lang.org/book), und bis
> Kapitel 6 war es ja noch ok, aber jetzt wird´s schon etwas seltsam:

enum ist ein Sum-Type - also ein Variant/Union Type
primär ist die Syntax dazu zu da die Mehrfägkeit zu bekommen ohne das 
auch mehr Probleme bei der Anwendung entstehen

bei Union darfst du nicht zwischen den Membern lesend/schreiben springen 
sonst UB und bei std::variant musst du entweder einen Visitor bauen oder 
casten - beides ist nicht schön

match vereint sicher die C++ enum und std::variant Features - auch wenn 
der Enum-Sumtype bei Rust aber eher aus dem OCaml Ursprung kommt

die meisten empfinden genau das Enum-Sumtype Feature als DAS Rust 
Feature was sie am meisten lieben - manche erst nach eine gewissen 
Warmwerdzeit

und auch die "Patterns" sind der absolute Hammer - nicht das es nicht 
auch anders geht aber die eleganz das alles auf so wenig zu reduzieren 
finde ich schön

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

Thomas W. schrieb:
> Mache gerade das Rust Buch durch (doc.rust-lang.org/book), und bis
> Kapitel 6 war es ja noch ok, aber jetzt wird´s schon etwas seltsam:
> - enum kann jede Variante andere Daten halten, aber ich komm nicht mehr
> dran außer mit match.
> - Match muß aber alle Varianten abdecken also gibt es "other =>" oder
> auch "_ =>" , naja ob das lesbarer wird?
> - Damit man das nicht braucht gibts das "if let", das ist ja total
> abstrus. Let weist eigentlich einer Variable etwas zu, jetzt steht
> daneben ein "Pattern". Kann ich nicht mehr als lesbar bezeichnen...

was du nicht vergessen darfst ist das das alle per default immutable ist 
- also in C++ gesagt "alles ist const" - das ist ein riesen Vorteil der 
Sprache und erzwigt implizit auch ein saubere, mehrheitliche 
State-freieres arbeiten

aber ich verstehe es wenn jemand nicht stark aus dieser const/state-less 
Welt kommt (am besten noch aus einer gar typelosen Welt) das diese 
ganzen Konzepte vereint schon sich schon ein wenig "unhandlich" 
anfühlen, weil man den Mehrwert wie implizite const-correctness 
vielleicht bisher gar nie genutzt hat oder das einem gänzlich fremd ist

wenn jemand z.B. viel mit Multithreading und C++ macht ist der Einstieg 
vergleichsweise einfacher weil Rust die sinnvollen Konzepte aus dem 
Bereich schon forciert

Ich mochte bei C, das man immer die Typen angeben musste. Da wusste man 
immer auf einen Blick, womit man es zu tun hat. Was ich auch noch etwas 
speziell finde, ist das man so Zeugs machen kann 'let x=1; let 
x="abc";', da muss man also auch noch die richtige finden. Ok, 
vermutlich helfen IDEs da einem weiter (wobei ich kein Fan von IDEs 
bin).

DPA schrieb:
> Ich mochte bei C, das man immer die Typen angeben musste. Da
> wusste man
> immer auf einen Blick, womit man es zu tun hat. Was ich auch noch etwas
> speziell finde, ist das man so Zeugs machen kann 'let x=1; let
> x="abc";', da muss man also auch noch die richtige finden. Ok,
> vermutlich helfen IDEs da einem weiter (wobei ich kein Fan von IDEs
> bin).

da geben ich dir recht ist vergleichbar mit C++/Java/C# auto/var
sollte man wirklich nicht zu excessive nutzen sonst blickt man nichts 
mehr
es kommt aber ganz darauf an - in manchen stellen z.B. bei generischer 
Programmierung kanst du das teilweise einfach nicht - deswegen das 
Sprachfeature

aber ich finde es trotzdem gut das man

let x = 1;
let x: u32 = 1
let x = 1u32
let x: u32 = 1u32

schreiben kann - wenn man denn will

und das ist auch das coole und besondere an Rust

Die schaffen es die Basis Konzepte von fast allen System(und auch 
Hochs)sprachen unter einen Hut (Zero-Cost, Constness/Immuateable by 
default, Movesemantic by default, No-GC, No-Runtime) zu bringen und 
dennoch applikationsfreundlich zu bleiben

jeder andere Sprachenversuch hat bisher einen oder mehrere dieser 
Ansprüchen fallen lassen weil die es konzeptionell nicht in ein Design 
rein bekommen haben - das ist ein Novum

auch wenn ich wirklich verstehe das die meisten gar keine Ahnung von den 
obigen Basis-Konzepten haben und auch deren relevanz kaum bis gar nicht 
einschätzen können - in Bezug auf Sicherheit, Performanz und Generic 
(also eben nur wie in vielen Sprachen nur einen Aspekt davon)

cppbert schrieb:
> da geben ich dir recht ist vergleichbar mit C++/Java/C# auto/var
> sollte man wirklich nicht zu excessive nutzen sonst blickt man nichts
> mehr

Ich finde es ist nicht vergleichbar mit C++, weil Rust die Typangabe 
durch den Programmierer auf Funktionsschnittstellen-, struct-, static- 
und const-var-Ebene forciert. Type inferrence findet nur innerhalb von 
Funktionen statt. (Lambdas sind eine optionale Ausnahme).

Wenn ein Typ vom Compiler hergeleitet wird, dann sieht man in der Regel 
die Quelle der Herleitung auf der gleichen Bildschirmseite.
Und wenn man das immer noch unübersichtlich findet, dann kann man jeder 
Variablen selbstverständlich auch einen expliziten Typen geben.

Bei der Herleitung passiert so gut wie nie etwas Unerwartetes in Rust.
Der Grund dafür ist das sehr strikte Typsystem.
Im Gegensatz zu C++. Da hat man implizite Konvertierungen und 
Promotionsregeln. Das macht es manchmal sehr schwer zu sagen, welchen 
Typ eine Variable wirklich hat.
Das ist in Rust anders.

Wenn man sehr generischen Code schreibt, dann kann es schon manchmal 
schwerer werden den Typ von Variablen zu erkennen. Aber auch das ist 
meist nicht schlimm. Denn wenn man diese Variable, oder einen davon 
errechneten Variable, dann aus der Funktion rückgibt oder in ein struct 
schreibt, dann bricht der Compiler durch fehlende implizite 
Konvertierungsmechanismen bei einem Typ-mismach an.

cppbert schrieb:
> in manchen stellen z.B. bei generischer
> Programmierung kanst du das teilweise einfach nicht - deswegen das
> Sprachfeature

Doch. Bei generischer Programmierung hat man in Rust immer einen 
generischen Typen. Den kann man dann auch angeben, wenn man möchte. Muss 
man aber eher selten.
Aber ich mache es schon manchmal. Vor allem, wenn ein impl mehrere 
generische Typen hat.

Ein generischer Typ ist nicht nur ein Platzhalter. Es ist ein Typ mit 
ganz klar definierten statisch festgelegten Eigenschaften.

Generische Typen sind, anders als in C++, in Rust stark constrained.
Man muss in Rust generische Typen mit der where-clause soweit 
einschränken, dass alle tatsächlich durchgeführten Operationen auf 
ebenjenen Typ abgedeckt sind. Wenn man das nicht macht, kann man 
überhaupt nichts mit dem Typ machen. Wenn man zwei Variablen generischen 
Typs addiert, dann muss dieser generische Typ im where-clause auf das 
Add-Trait eingeschränkt sein. d.h. der Typ kann nur einer sein, der auch 
tatsächlich exakt dieses Trait implementiert. Das wird alles schon bei 
der Implementierung der generischen Funktion festgezurrt. (In C++ wird 
das fast alles erst viel später bei der Instanziierung aufgelöst).
Bei der Instanziierung wird dann wiederum festgezurrt, dass der 
tatsächliche Typ auch tatsächlich alle geforderten Traits implementiert.
Ein generischer Typ monomorphiert immer bei der Instanziierung in genau 
einen konkreten tatsächlichen Typ.

MaWin schrieb:
> cppbert schrieb:
>> da geben ich dir recht ist vergleichbar mit C++/Java/C# auto/var
>> sollte man wirklich nicht zu excessive nutzen sonst blickt man nichts
>> mehr
>
> Ich finde es ist nicht vergleichbar mit C++, weil Rust die Typangabe
> durch den Programmierer auf Funktionsschnittstellen-, struct-, static-
> und const-var-Ebene forciert. Type inferrence findet nur innerhalb von
> Funktionen statt. (Lambdas sind eine optionale Ausnahme).

ja sorry das vergesse ich immer - im Ergebnis verhält es sich ähnlich, 
aber es ist doch viel strikter

z.b. erzeugt auto nicht ungewillt Kopien - was bei C++ immer mal gern 
passiert oder häufig von Anfängern falsch gemacht wird - da Rust 
implizit moved und nur explizit kopiert kann das in Rust gar nicht 
passieren

> cppbert schrieb:
>> in manchen stellen z.B. bei generischer
>> Programmierung kanst du das teilweise einfach nicht - deswegen das
>> Sprachfeature
>
> Doch. Bei generischer Programmierung hat man in Rust immer einen
> generischen Typen. Den kann man dann auch angeben, wenn man möchte. Muss
> man aber eher selten.
> Aber ich mache es schon manchmal. Vor allem, wenn ein impl mehrere
> generische Typen hat.
>
> Ein generischer Typ ist nicht nur ein Platzhalter. Es ist ein Typ mit
> ganz klar definierten statisch festgelegten Eigenschaften.
>
> Generische Typen sind, anders als in C++, in Rust stark constrained.
> Man muss in Rust generische Typen mit der where-clause soweit
> einschränken, dass alle tatsächlich durchgeführten Operationen auf
> ebenjenen Typ abgedeckt sind.

ja sorry - ich meinte eher das du keinen expliziten "Basis"-Typ angeben 
kannst (oder es recht wenig sinn macht) - und ja die where clausen 
(vergleichbar mit C++ Konzepts) verhindern zwangsweise die typischen C++ 
Template-Error-Wolken

Ein wichtiger weiterer Punkt, warum Type Inference in Rust viel besser 
nachvollziehbar ist, als in C++:
Es gibt keine Methoden- und Funktionsüberladungen und keine 
Klassenhierarchien.
Es ist viel einfacher nachzuvollziehen, was tatsächlich aufgerufen wird. 
Das klassische OOP-Problem, wo eine Methode 10 mal abgeleitet und auch 
noch 5 mal überladen ist, existiert in Rust nicht.

Es ist zwar manchmal nicht ganz auf den ersten Blick zu erkennen, zu 
welchem Trait ein Funktionsaufruf gehört. Aber in der Doku, die man mit 
Cargo aus jedem Stück Rust-Code generieren kann, wird dem Entwickler das 
dann gut und eindeutig erklärt. Dazu ist es nicht notwendig, dass jemand 
das manuell irgendwo dokumentiert.

Und wenn man dann immer noch nicht weiß, welchen Typ eine Variable hat, 
dann kann man den Rust-Compiler ganz einfach fragen:

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

Als Fan von Pascal/Delphi und weniger von C, beobachte ich die 
Entwicklung auch mi Interesse.
Auch im Freepascal Forum gibt es dazu gerade eine Vergleichsdiskussion, 
ob und wie sich Rust von Pascal unterscheidet
https://forum.lazarus.freepascal.org/index.php/topic,54311.0.html

Peter K. schrieb:
> Auch im Freepascal Forum gibt es dazu gerade eine Vergleichsdiskussion,

letzer Post vom "April 25, 2021, 09:56:15 AM" ist aber nicht so aktuell

MaWin schrieb:
> Und wenn man dann immer noch nicht weiß, welchen Typ eine Variable hat,
> dann kann man den Rust-Compiler ganz einfach fragen:
>
> 
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2d69f5a260259c365c4e0ac0913eff0e

An so Informationen kommt man bei C++ auch nur mit kleinen Tricks :)
ich hoffe das Rust in dem Bereich sehr viel stärker aus den C++ Fehlern 
lernt und die Fähigkeiten generischer zu programmieren auch mit den 
entsprechenden Tools unterfüttert um das einfach/schnell 
wartbar/verständlich zu halten

cppbert schrieb:
> An so Informationen kommt man bei C++ auch nur mit kleinen Tricks :)

Das macht bei Rust der rust-analyser. Der Zeigt bei jeder Variablen den 
Typ an. Gibt es als Plugin für VSCode.

cppbert schrieb:
> ich hoffe das Rust in dem Bereich sehr viel stärker aus den C++ Fehlern
> lernt und die Fähigkeiten generischer zu programmieren auch mit den
> entsprechenden Tools unterfüttert um das einfach/schnell
> wartbar/verständlich zu halten

Ja also, ich sag mal so. Diesen Trick braucht man so gut wie nie. Aber 
wenn, dann ist es hilfreich zu wissen.

Generell ist der Rustcompiler sehr viel besser in der Fehlerausgabe als 
z.B. der g++.
Der Rustcompiler gibt bekannte Typinformationen zwar aus, aber überhäuft 
den Programmierer in der Regel nicht mit ellenlangen Typbeschreibungen 
(g++ ist da auch schon besser geworden).
In der Regel gibt der Rustcompiler sogar eine Vorschlag, was der 
Programmierer vermutlich meinte. Oft ist das sogar schon richtig oder 
fast richtig oder gibt einem wenigstens einen Schubs in die richtige 
Richtung.
Und dann hat jeder Compilerfehler auch noch eine eigene ID und einen 
Link auf eine manpage/website, wo der Fehler und seine möglichen Gründe 
noch einmal genauer und mit Beispielen beschrieben wird.

Vom Fehlerdiagnoseverhalten ist der Rustcompiler so ziemlich das Beste, 
was ich kenne.

>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

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.

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;

Jörg W. schrieb:
> Aber nur, weil du gefragt hast …

Leider wieder auf eine Frage geantwortet, die gar nicht gestellt wurde.
Es ging um die Fehlermeldungen.

Jörg W. schrieb:
> Ich hätte daher sowas wie
>   let c = i32: 42;
>
> lesbarer gefunden, um den Typ einer Zahl zu benennen. (Ja, erinnert an
> Pascal. ;-)

Sorry aber das erinnert niemanden an Pascal weil der Typ bei Pascal doch 
immer rechts vom Doppelpunkt steht ;-)
Rust entspricht bis auf das "let" exakt der Pascal-schreibweise

1

Rust:

2

let c: i32 = 42;

3

4

Pascal:

5

    c: integer = 42;

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

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

Nicht zu vergessen:

1

let e = 42i32;

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.

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;

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

kann einer sagen warum "const x = 123i32" nicht genug ist?

cppbert schrieb:
> kann einer sagen warum "const x = 123i32" nicht genug ist?

Weil man dann Type Inferrence bemühen müsste, was in einigen Fällen 
(nicht in diesem) interessante Probleme gibt. z.B. zyklische 
Typabhängigkeiten.

Es ist eine Designentscheidung, dass alle toplevel-APIs ohne Type 
Inferrence typisiert werden müssen.
Damit gewinnt man eine vollständige Kontextunabhängigkeit auf dieser 
Ebene.

In Rust ist es sehr wichtig, dass die Größe von Typen bekannt ist, oder 
dass bekannt ist, dass die Größe dynamisch ist. Unbekannte Größen sind 
ein Problem und müssen so schnell wie möglich vom Compiler aufgelöst 
werden.

Cyblord -. schrieb:
> Ich hätte auch nicht gedacht dass jemand nochmal ernsthaft das alte
> Basic-Style "let" aufwärmt. Aber hey, die Rustler kennen da nix.

Wie würdest du denn eine Variable mit Type Inferrence ohne let 
definieren und dabei auch zwischen Definition und Zuweisung 
unterscheiden? Mir fällt da spontan keine Möglichkeit ein, außer 
Keyword.

Cyblord -. schrieb:
> Ich will schon gar keine Type Inference machen.

Interessant. Eben sagtest du noch:

Cyblord -. schrieb:
> Weil geschwätzige Syntax wieder im Trend liegt?

Was denn nun? Lieber mehr oder lieber weniger tippen?

Cyblord -. schrieb:
> cppbert schrieb:
>> kann einer sagen warum "const x = 123i32" nicht genug ist?
>
> Weil geschwätzige Syntax wieder im Trend liegt?
> Ich hätte auch nicht gedacht dass jemand nochmal ernsthaft das alte
> Basic-Style "let" aufwärmt. Aber hey, die Rustler kennen da nix.

wann erklärst du jetzt wirklich mal endlich warum die Rust-Iteratoren 
ein No-Go für embedded sind?

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

//...

Cyblord -. schrieb:
> Nur das NOTWENDIGE tippen. Und dazu gehört der Typ. Dazu gehört aber
> kein let und kein func.

als wenn das bei Algorithmen-Entwicklung irgendeine relevanz hat, oder 
jemals gehabt hätte ausser in irgendeiner Wurstbude die auch {} bei if 
weglässt weil das so viel spart aber die halbe Manschaft kann nicht mal 
10-Finger schreiben :)

btw: du denkst noch an die Iteratoren und die No-Go Aufklärung?

Cyblord -. schrieb:
> Dazu gehört aber kein let und kein func.

Da haben wir ja noch einmal Glück gehabt, denn 'func' gibt es in Rust 
nicht.

Btw: An der Aufklärung der Iteratorenfrage wäre ich auch noch sehr 
interessiert. Du scheinst da etwas zu wissen, was ich nicht weiß.

Ein schöner Artikel über Rust und Standardisierung:

https://blog.m-ou.se/rust-standard/

> To better understand how to give a more useful definition, we first need to
> understand how Rust evolves. What “Rust” means changes regularly, as we are
> constantly working on improvements. Every six weeks, we release a new stable
> version of the compiler, each time changing what “Rust” means.

> Announcing Rust 1.65.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.

MaWin schrieb:
>> Generic associated types (GATs)
>
> Yay! Kann man nicht in ein paar Worten erklären :)

magst du es mal versuchen? am besten mit möglichem C++ Bezug

cppbert schrieb:
> magst du es mal versuchen? am besten mit möglichem C++ Bezug

Einen C++-Bezug kann ich leider nicht bringen. Da kenne ich mich nicht 
gut genug mit C++ aus.

Grundsätzlich gesagt ist es eine relativ "einfache" (aus 
Programmierersicht) Erweiterung eines bestehenden Features.

Man kann in Rust Typen mit Traits assoziieren.
Was heißt das?
Das typische Beispiel, wie es auch im Announcement vorkommt, ist ein 
Iterator-Trait:

1

trait Iterator {

2

    type Item;

3

    fn next(&mut self) -> Option<Self::Item>;

4

}

Grob gesagt erreicht man damit, dass die Implementierung des Traits 
angeben kann, welcher Typ konkret verwendet werden soll (hier: Welchen 
konkreten Typ next() zurückgeben soll). Wenn man jetzt diesen Iterator 
für einen Typ implementiert, dann muss man den konkreten Typ der 
zurückgegebenen Elemente mit angeben. Somit weiß der Compiler bei der 
Verwendung dieses Iterators, welche konkreten Typen aus dem Iterator 
herausfallen. Im Trait selbst (in provided methods) kann man auch mit 
dem Typ arbeiten, allerdings nur auf abstrakter und nicht auf konkreter 
Ebene. (Man muss den Typ weiter einschränken mit Bounds).

Soweit so gut. Das alles gibt es schon sehr lange.

Nun ist neu, dass der assoziierte Typ auch generisch sein kann.
Das ist (IMO) hauptsächlich sinnvoll, wenn der assoziierte Typ eine 
Lifetimeangabe braucht. Lifetimes werden über den generic-Mechanismus 
gemacht. Das ist z.B. notwendig, wenn der Typ Referenzen einbettet.
Ohne GATs ist es nicht möglich dem assoziierten Typ eine Lebenszeit 
(außer `static) zu geben.
Damit waren bis jetzt associated Types auf owned-Typen beschränkt.

Mit GATs gibt es praktisch keine Beschränkung mehr.

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

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.

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

also eher Potenzial als Problem :)

ach sch..
Jetzt habe ich Text zum Text von weiter oben kopiert..von zu weit oben?

1

Standard Error

2

   Compiling playground v0.0.1 (/playground)

3

error[E0308]: mismatched types

4

 --> src/main.rs:4:17

5

  |

6

4 |     let z = x + y;

7

  |                 ^ expected `i32`, found `i64`

8

9

error[E0277]: cannot add `i64` to `i32`

10

 --> src/main.rs:4:15

11

  |

12

4 |     let z = x + y;

13

  |               ^ no implementation for `i32 + i64`

14

  |

15

  = help: the trait `Add<i64>` is not implemented for `i32`

16

  = help: the following other types implement trait `Add<Rhs>`:

17

            <&'a f32 as Add<f32>>

18

            <&'a f64 as Add<f64>>

19

            <&'a i128 as Add<i128>>

20

            <&'a i16 as Add<i16>>

21

            <&'a i32 as Add<i32>>

22

            <&'a i64 as Add<i64>>

23

            <&'a i8 as Add<i8>>

24

            <&'a isize as Add<isize>>

25

          and 48 others

26

27

Some errors have detailed explanations: E0277, E0308.

28

For more information about an error, try `rustc --explain E0277`.

29

error: could not compile `playground` due to 2 previous errors

Wieso macht eigentlich der ghci aus 0xa + 0xb  21 ??

Und auf Assemblerebene kann man sehr wohl ganz gut 32 Bit mit 64 Bit 
addieren. Vor diesem Hintergrund fragt man sich, was wohl mit fehlender 
"Implementation" gemeint ist.

Ich würde jetzt auch nicht von Umarmung sprechen -  mich erinnert das 
Szenario eher an Veräppelung.

rbx schrieb:
> Und auf Assemblerebene kann man sehr wohl ganz gut 32 Bit mit 64 Bit
> addieren.

Selbstverständlich.

Aber eben aus gutem Grund nicht im Rust-Typsystem.
Es zwingt dich explizit zu sein und eine Typumwandlung durchzuführen.
Und diese Entscheidung wie addiert werden soll, musst du natürlich auch 
in Asm treffen.
Soll i32 auf i64 aufgeblasen werden? Mit oder ohne sign extension? Soll 
auf i32 saturiert werden? Soll auf i32 abgeschnitten werden? All diese 
Fragen gilt es zu beantworten. Der Rust-Compiler rät das Ergebnis dieser 
Fragen nicht. Er fragt dich als Programmierer.

> Vor diesem Hintergrund fragt man sich, was wohl mit fehlender
> "Implementation" gemeint ist.

Es fehlt (ganz bewusst und gewollt) die Implementierung des 
Additions-Operators (Add-Trait) für i32 + i64.

rbx schrieb:
> Ich würde jetzt auch nicht von Umarmung sprechen -  mich erinnert das
> Szenario eher an Veräppelung.

Was genau ist denn an dieser Fehlermeldung nicht zu verstehen?

> error[E0308]: mismatched types
> error[E0277]: cannot add `i64` to `i32`

Alles was danach folgt ist nur eine weitere tiefergehende Erklärung, 
warum i32 und i64 nicht addiert werden können.

> Wieso macht eigentlich der ghci aus 0xa + 0xb  21 ??

Was ist ghci?
Warum soll 10 + 11 nicht 21 sein?

rbx schrieb:
> Und auf Assemblerebene kann man sehr wohl ganz gut 32 Bit mit 64 Bit
> addieren.

nur explizit - die ganze implizite Auto-Casting und Integer-Promotion 
Verhalten verursacht viele latente Fehler die schwer zu finden sind
auch z.B. Pointer == int == bool ist relativ böse

Rust zwingt zur hygiene - und die ist wirklich nötig, auch wenn viele 
davon nie was mitbekommen - weil die meisten Kämpfe in der Standardlib 
oder 3rd-Parties passieren

höchstwahrscheinlich kompilieren die meisten C/C++ Projekte gar nicht 
mehr wenn man sign-unsiged-mismatch-Warning-als-Error im gcc aktivert :)

MaWin schrieb:
> Was ist ghci?

in einem rbx Post darf ein Haskell-Bezug nicht fehlen :)

Jörg W. schrieb:
> cppbert schrieb:
>
>> höchstwahrscheinlich kompilieren die meisten C/C++ Projekte gar nicht
>> mehr wenn man sign-unsiged-mismatch-Warning-als-Error im gcc aktivert
>
> It depends.
> Seit die Warnung nun standardmäßig ein ist, dürfte das schon deutlich
> zur Verbesserung beigetragen haben. Ich habe schon viele Projekte
> gesehen, die eine zero-warning-policy fahren (kommerzielle wie
> Opensource).

Die Top Projekte schon aber dann wird die Luft schnell dünn

genauso wie ASAN,TSAN Nutzung und statische Codeanalyse, ich treffe 
immer wieder auf Fehler wegen fehlendem Tooleinsatz und Warninglevel

Beispiel: ASAN build von Qt 6.4 und Glib findet sofort eine 
Stackoverflow, faellt aber nur auf wenn man auch die GLib mit ASAN baut, 
TSAN Tests werden bei denen auch nicht über den CI-Server gemacht weil 
zu viel Aufwand/ Belastung für den Server

MaWin schrieb:
> Was ist ghci?

Würde ich sagen Glasgow Haskell Compiler Interpreter.

MaWin schrieb:
> Warum soll 10 + 11 nicht 21 sein?

Weil 0xa + 0xb nunmal 0x15 sind. Außerdem nicht mehr 4 Bit, sondern 
jetzt 8. Das ist alles viel Interpretationssache, z.B. auch, weil die 
Zahlen ab 8000 bei 16 Bit immer negativ sind - sofern man das braucht.

Wenn man schon eine Art künstlichen Prozessor programmiert, der viele 
mögliche Operationen mit Datentypen macht, dann sollte der auch 32Bit 
mit 64 Bit addieren können. Am Ende ist eher die Frage, wo speichere ich 
das Ergebnis?
Dann bräuchte man also nur einen Typen für 32Bit + 64Bit Additionen 
konstruieren, der selbstverständlich mindestens 64Bit hat.
Besser wäre natürlich eine noch größere Bitbreite, das ja auch 64 Bit 
bereits auf FFFF (überall) stehen kann. Da könnte man dann nur noch, bei 
64 Bit - falls überhaupt - ein Bool addieren.

Man kann sich ein Vorbild an der Kompatibilität der Hardware nehmen - 
und muss nicht alles ins absurdum führen, weil die Transparenz in 
Assembler eher unbekannt ist.

Bei so Diskussionen rund um Loop-Automatismen auf YT weiß ich jedenfalls 
eher nicht, ob ich nun lachen soll, oder weinen muss.

Das ist übrigens auch etwas (Loopautomatismen usw.) was bei Haskell 
anstößig ist. Da heißt es dann: das sieht aber furchtbar aus, da 
programmiere ich doch lieber C++.
Ich selber finde schon die vielen Möglichkeiten, die man in (PC) 
Assembler hat , etwas unübersichtlich.
Aber um sich einen Überblick zu verschaffen, muss man eben eine Liste 
machen, herumprobieren, Sourcecodes lesen oder Bücher zur 
Programmierkunst in Asm.
Das geht alles ganz gut ohne YT.
Das gleiche gilt für Loop-Automatismen in Haskell und wird für Rust auch 
nicht anders sein.

rbx schrieb:
> Wenn man schon eine Art künstlichen Prozessor programmiert, der viele
> mögliche Operationen mit Datentypen macht, dann sollte der auch 32Bit
> mit 64 Bit addieren können.

Nein. Wozu? Was würde das bringen?
Es ist viel einfacher und auch für die Programmiererin viel eindeutiger, 
wenn sie die Konvertierung explizit macht. Sie muss sich keine 1000 
Regeln merken. Alles steht explizit im Code.

1

let c = a as i64 + b;

Ich sehe das Problem nicht.
Rust bietet mit 'as' und 'into' sehr mächtige und bequeme 
Konvertierungstools.

> Am Ende ist eher die Frage, wo speichere ich das Ergebnis?

Die Fragen sind viel mehr die, die ich bereits oben formuliert habe. Wo 
es dann gespeichert wird, ergibt sich daraus (Type inference).

> Dann bräuchte man also nur einen Typen für 32Bit + 64Bit Additionen
> konstruieren, der selbstverständlich mindestens 64Bit hat.

Ach. Das ist selbstverständlich? Für mich nicht. Ich würde das als 
Programmierer gerne von Fall zu Fall entscheiden.

> Besser wäre natürlich eine noch größere Bitbreite

Die bietet Rust.

> Man kann sich ein Vorbild an der Kompatibilität der Hardware nehmen

Man kann es auch sein lassen.
Nicht einmal das Maschinenmodell von C stimmt mit irgendeiner realen 
Hardware auch nur annähernd überein.

> Assembler

Ich weiß ja nicht, was du ständig mit Assembly hast. Aber es ist 
offtopic. Assembly hat überhaupt kein Typsystem. Es ist somit gar nicht 
vergleichbar mit irgendeiner Hochsprache.

Rust definiert sich durch sein Typsystem.

> Bei so Diskussionen rund um Loop-Automatismen auf YT

Was sind "Loop-Automatismen"?