Rust - ist das hier um zu bleiben?

cppbert schrieb:
> Das würde ich jetzt nicht einfach so sage - warum sollte Rust dafür
> ungeeignet sein - als Sprache?

Es ist nicht ungeeignet.
Aber es gibt geeignetere Sprachen.
Nicht alles, was möglich ist, ist auch sinnvoll.

Rust hat ein sehr strenges und komplex zu bedienendes Typsystem. Ein 
Großteil des Entwicklungsaufwands bei Rust-Programmen fließt in das 
Design der Datentypen, Methoden und Traits. All dies muss 
zusammenspielen, sonst kommt man insbesondere bei Rust in Teufels Küche. 
Hacks, die das Typsystem hintergehen, sind in Rust nicht ohne weiteres 
(= unsafe Rust) möglich. Einfach mal mit einem Pointer um sich werfen, 
wie man es aus C++ kennt, kann man in Rust nicht. Und das ist gut so.

Wenn ich mathematische Probleme löse, dann will ich eines ganz gewiss 
nicht: Mich mit dem Typsystem herumschlagen.
Das ist der Einsatz, wo Sprachen wie Python (+ Numpy) groß sind.

Jörg W. schrieb:
>> Das ist der Einsatz, wo Sprachen wie Python (+ Numpy) groß sind.
>
> Allerdings eben als interpretierte Sprache zwar schnell im Design, u.U.
> aber doch mit Geschwindigkeitseinbußen in der Ausführung.

Wenn der interpretierte Teil eines Python+Numpy-Programms ein Problem 
wird, dann machst du in 99% der Fälle etwas sehr sehr falsches.

> Wenn man große
> Datenmengen numerisch behandeln muss, kann es also sinnvoll sein, einen
> Python-Prototypen später in was anderem nachzuschreiben.

Kann vorkommen. Aber sehr selten.
Dann meinetwegen auch in Rust.
Aber nicht von vorne herein schon.

Jörg W. schrieb:
> Die Typisierung musste ich übrigens auch in C abhandeln

Die Rust-Typisierung mit C-Typisierung zu vergleichen ist schon etwas 
ulkig.

Das Rust Typsystem verhält sich zum C Typsystem wie ein Daimler zu einem 
Tretroller.

Jörg W. schrieb:
>> Die Rust-Typisierung mit C-Typisierung zu vergleichen ist schon etwas
>> ulkig.
>
> Kann sein, aber möglicherweise kennst du auch bloß schlechtes C.

Hä?
Ich spreche von der Sprache C, die im ISO-Standard definiert ist. Ich 
denke nicht, dass die schlecht oder gut ist. Sie ist, wie sie ist.

Das Typsystem der Sprache C ist überhaupt nicht direkt vergleichbar mit 
Rust.
Das Rust-Typsystem ist von der Komplexität her etwa in der Liga des 
C++-Typsystems, um für dich einen Vergleich zu schaffen, den du 
eventuell nachvollziehen kannst.
Aber auch dieser Vergleich ist eigentlich nicht zutreffend wegen der 
ganzen C-Altlasten in C++. Und weil Rust Features hat, die es in C++ gar 
nicht gibt. Das Konzept von Lifetimes gibt es weder in C, noch in C++. 
Wenn man ein Rust-Programm schreibt, ist man aber gezwungen sich mit 
Lifetimes (und allen anderen Eigenschaften des komplexen Typsystems) 
auseinanderzusetzen.

Und das ist eben der Punkt. Wenn ich ein mathematisches Problem lösen 
möchte, dann stehen mir diese Dinge erst einmal im Weg.
Wenn das Problem dann gelöst und verstanden ist, dann kann ich immer 
noch darüber nachdenken, ob es sinnvoll ist, das Programm in einer 
Sprache wie Rust neu zu schreiben.
Bei Verwendung von einfachen Sprachen wie Python bleibt mehr 
Hirnkapazität für das zu lösende Problem über. Mit dem Nachteil, dass 
mehr Programmierfehler erst (sehr viel) später auffallen. Teilweise erst 
nach der Auslieferung des Programms. Es ist ein Abwägen von Prioritäten.

Es ist erklärtes Ziel der Rust-Entwickler den Entwicklungsprozess eines 
Rust-Programms deutlich zu vereinfachen. Und das ist auch gut und 
notwendig.
Aber dort sind wir leider noch nicht am Ziel angekommen. Und ich sehe 
nicht, wie wir jemals an die Entwicklungsperformance von Python auch nur 
im Ansatz anknüpfen können. Aber das ist eigentlich auch nicht 
notwendig. Jede Sprache für seinen Zweck.

MaWin schrieb:
> Es ist nicht ungeeignet.
> Aber es gibt geeignetere Sprachen.
> Nicht alles, was möglich ist, ist auch sinnvoll.

ich arbeite an einem Projekt das locker 500.000 Lines nur Mathecode 
beinhaltet um Maschinen zu steuern, teilweise nearly Echtzeit - da will 
ich kein Python, ist in diesem Projekt alles mit C++ realisiert

Es kommt eben drauf an

Jörg W. schrieb:
> Aber C ist auch nicht bloß "mal einen Pointer herumwerfen", wie du das
> darstellst. Zumindest nicht, wenn man es ordentlich macht.

du bist immer noch ein wenig zu kritisch - mitlerweile sollte dir klar 
sein das MaWin ein nicht ganz unbeschriebenes Blatt ist, sich auskennt 
und manchmal ein wenig überspitzt schreibt

Jörg W. schrieb:
> Ich habe nur manchmal die Befürchtung, dass er von ein paar schlechten
> C-Programmierern auf die Qualität aller C-Programme schließt.

Die "paar" schlechten C-Programmierer.
Da sind sie wieder.
Wenn man ein C-Programm richtig schreibt, ist es auch ein korrektes 
Programm.
Ich stimme dir vollkommen zu.

Aber du hast es ja bereits selbst erkannt, worum es Rust geht:

Jörg W. schrieb:
> Dass bei letzterem Rust einen deutlichen Vorteil hat (die Bedingung
> "wenn man es ordentlich macht" kann man dort nicht umgehen), ist
> unbestritten.

Und das zwingt den Programmierer halt Hirnressourcen dafür aufzuwenden, 
die dann natürlich nicht anderweitig zur Verfügung stehen.
In vielen Fällen mag der zusätzliche Aufwand gerechtfertigt sein. In 
vielen aber auch nicht.
Das muss man abwägen.
Rust ist kein Allheilmittel.
Aber es ist eben auch ein mächtiges Werkzeug, das viele C/C++-Programme 
ablösen kann und sollte.

Mombert H. schrieb:
> Meinst du damit ein definierte Lifetime von Objekten oder die *rustc
> Lifetimes*™?

Mombert, dir antworte ich übrigens nicht mehr, falls du es noch nicht 
gemerkt hast.
Befasse sich bitte erst einmal mit den Grundlagen von Rust. Und höre auf 
zu trollen.

Mombert H. schrieb:
> MaWin schrieb:
>> Das Konzept von Lifetimes gibt es weder in C, noch in C++.
> Meinst du damit ein definierte Lifetime von Objekten oder die *rustc
> Lifetimes*™?

allen hier ist klar was Stack Objekte und RAII etc. ist - darum ging es 
nicht
- Lifetime ist bei Rust eine Eigenschaft des Typ-Systems eben nicht nur 
Heap oder Scope

cppbert schrieb:
> du bist immer noch ein wenig zu kritisch - mitlerweile sollte dir klar
> sein das MaWin ein nicht ganz unbeschriebenes Blatt ist, sich auskennt
> und manchmal ein wenig überspitzt schreibt

Hier geht es aber eigentlich um Daniel und die Frage, ob die kognitive 
Dissonanz-Bearbeitung berechtigt ist, oder nicht.
Ich bin mir nicht sicher.

Auf der anderen Seite werden Programmiersprachen tatsächlich oft 
überbewertet.
Know How, Algorithmen, Motivation sind auch sehr wichtig. Ohne 
Motivation geht nix.

Warum stellt Daniel die Frage, ob Rust bleibt? Möchte er Kernelhacker 
werden?

Vor dem Hintergrund der Multicore Nutzung steht Rust ganz gut da.

Aber ich glaube nicht, dass eine Diskussion sehr weit führt. Es ist 
vielleicht hilfreicher, seine Lieblingsprogramme nach Rust zu 
übersetzen, und dann zu schauen, was man selber davon hat.
Sinnvollerweise aber möglichst da, wo Rust seine Stärken hat.

rbx schrieb:
> Warum stellt Daniel die Frage, ob Rust bleibt? Möchte er Kernelhacker
> werden?

welcher Daniel? hat er die Frage aufgemacht?

Dieser Post hier ist eher so eine Sammlung an Rust Diskussionen die alle 
paar Monate mal wieder aufflammen, weiter betrieben von anderen

Jörg W. schrieb:
> Ich habe nur manchmal die Befürchtung, dass er von ein paar schlechten
> C-Programmierern auf die Qualität aller C-Programme schließt.

eigentlich bist du es der immer wieder davon ausgeht das er keinen oder 
einen schlechten Überblick hat und dann in Detail-Diskussionen verfällt 
weil du ihn (löblicherweise) belehren willst - aber das ist so gut wie 
nie wirklich nötig

leider schließen sich dann auch recht schnell viele anderen an und alle 
Antworten driften total in die Off-Topic Richtung - immer und immer 
wieder

aber jetzt gerade ist deine Argumentation fein - Sternchen für dich :)

Ich bin wirklich sehr gespannt wann Rust im Linux-Kernel aktiv wird - 
also dem Protoypen-Status entwächst und auch von vielen anderen 
Linux-Entwicklern begutachtet wird (ich weiss das nicht jeder an allem 
arbeitet)

weiss jemand ob das Asynchron-Konzept im Kernel (natürlich mit 
Kernel-Backend) Anwendung finden wird oder ist das ein zu "komplexes" 
Konzept für die Kernel-Ebene?

Ein T. schrieb:
> Tatsächlich sind große Teile von numpy, scipy & Co. in nativen Sprachen
> wie C, C++ und Fortran implementiert. Performance ist daher in der Regel
> kein Thema, dessentwegen man Python-Prototypen in anderen Sprachen
> reimplementieren müßte.

wie gesagt es gibt die richtigen Gründe es zu tun und es nicht zu tun, 
kommt absolut auf das Projekt und die Umgebung des Projektes an - in 
meinen Hochlast und Resourcen-Beschränkten Projekten geht es einfach 
nicht in anderen schon

> Auch Python selbst ist schneller als sein Ruf. Für ein Projekt habe ich
> mal einen Bag-of-Words-Algorithmus mit Boost::Python entwickelt, der
> sich am Ende als viel langsamer herausgestellt hat als die native
> Python-Implementierung.

was jetzt in keinster Weise bedeutet das native Python schnell ist - es 
kann so viele Gründe geben warum das bei dir so war das es als Argument 
schwerlich dienen kann

Vergleichen wir doch mal Rust mit C.


Rust - Eisenoxid - Fe₂O₃

Eigentlich nur für 2 Sachen gut: Eisenherstellung / zutat in Thermit, 
und als Braunrotes Farbpigment.

Meistens bereitet es aber Probleme. Eisen rostet, und wird brüchig. 
Rostige schrauben lassen sich nicht rein / raus drehen. Und wenn rostige 
Sachen im regen steht, färbt es alles darum rum Rot ein. Es gibt auch 
nichts wichtiges, was man aus Rost selbst herstellen würde, nur der 
Eisenanteil ist interessant.

Normalerweise versucht man, zu verhindern, dass dinge Rosten. Wir haben 
Stahl erfunden, Rostschutzmittel, Lacke, etc. um dem Rost Herr zu 
werden. Aber ganz vernichten konnten wir ihn nie. Es gibt immer noch 
Dinge, die vor sich hin rosten, und so schnell ändert sich daran auch 
nichts...
Rust - ist das hier um zu bleiben?
Ja, sieht leider so aus.


C - Kohlenstoff

Unglaublich nützlich. Plastik und Polymere brauchen Kohlenstoff. 
Pythons, Menschen,  etc. sind Kohlenstoffbasierte Lebewesen. Jegliche 
organische Chemie basiert auf Kohlenstoff. Kohlenstoff ist auch geeignet 
als Schmiermittel. Es kann für Transistoren verwendet werden. Und als 
Nono Röhrchen kann man damit extrem stabile Fäden herstellen. Und es ist 
auch beliebt zum Schreiben, in Bleistiften. In der Forschung und als 
schmuck ist es auch begehrt, als Diamanten. Es gibt sicher noch weitere 
Anwendungsgebiete. Ein wahrere Alleskönner.

C ist also klar besser als Rust.

Ob Python schnell ist, kommt auch auf die Perspektive an. Python wurde 
schnell zu Hackers Liebling, nicht etwa eine der funktionalen Sprachen.

Inwieweit ein Setup schnell ist, etwa für Statistikübersichten, 
Data-Mining Zeugs, Visualisierung für dies und das, ist vielleicht 
nochmal eine andere Frage. Aber bestimmt keine unwichtige.

Ein Setup für Mikrocontroller vor allem bei Parallelprogrammierung wäre 
interessant, oder eben auch ein Setup für Spiele auf Linux, welche die 
Parallelität ausnutzen.
Bei Spielen spielen aber auch Skriptsprachen eine Rolle, Lua oder 
Javascript z.B.
Dann gibt es noch verschiedenen "Engines" z.B. für Physik, das muss man 
auch noch alles unter einen Hut bekommen.
Und ja, die Gameengines selber sind aus mehrererlei Hinsicht 
überholungsbedürftig.

Rust ist diesbezüglich eine große Chance. Im Weg steht das Umdenken.

Mombert H. schrieb:
> - Niemand der im Jahre 20XX "altes FORTRAN" schreibt, wechselt zu Python
> und schreibt dort Python. Das wird im besten Fall PYTRAN77.

Ziemlich guter Einwand.

DPA schrieb:
> C ist also klar besser als Rust.

Die erste gute Erklärung warum C wirklich besser ist :)

Danke

rbx schrieb:
> Ein Setup für Mikrocontroller vor allem bei Parallelprogrammierung wäre
> interessant, oder eben auch ein Setup für Spiele auf Linux, welche die
> Parallelität ausnutzen.
> Bei Spielen spielen aber auch Skriptsprachen eine Rolle, Lua oder
> Javascript z.B.
> Dann gibt es noch verschiedenen "Engines" z.B. für Physik, das muss man
> auch noch alles unter einen Hut bekommen.
> Und ja, die Gameengines selber sind aus mehrererlei Hinsicht
> überholungsbedürftig.

das klingt wie eine Wunschlisten, Hoffnungssammlung ohne richtigen 
Hintergrund

Rust kann das ganze vielleicht ein wenig homogenisieren und natürlich 
stark seine Stärken in Sicherer-Programmierung ausspielen - aber dadurch 
wird sonst nichts wirklich einfacher, ein ~8Mio Lines of Code pure 
Unreal Engine oder mindestens 10-20Mio Zeilen Code von GTA5 werden damit 
auch nicht magisch viel weniger oder einfacher - auch Projekt-Teams mit 
mehr als 100 Entwickler sind nicht ständig am Dependencies Resolven 
sondern kümmern sich mehr oder minder nur um den Game-Code, was absolut 
nicht bedeuten soll das Rust nicht super viel helfen kann - aber deine 
Auflistung ist trotzdem komisch

oder was meinst du?

DPA schrieb:
> Rust - Eisenoxid - Fe₂O₃
>
> Eigentlich nur für 2 Sachen gut: Eisenherstellung / zutat in Thermit,
> und als Braunrotes Farbpigment.

Der Nutzen scheint auch eher für Kenner zu sein, also Leute, die es 
wirklich wissen wollen:
https://www.deutschlandfunknova.de/nachrichten/magnetische-nanopartikel-mit-smartem-rost-gegen-mikroplastik

Die Geschichte ist aber auch schon alt, und so wohl mehr für 
interessante Nachrichten geeignet, als tatsächlich coole Hilfe für echte 
Nöte.

cppbert schrieb:
> oder was meinst du?
Hinsichtlich einer komischen hoffnungsverlorenen Perspektive ohne 
richtiges Hintergrundverständnis auf meinen Beitrag finde ich es bei 
einem so wackeligen Thema so wie hier ziemlich erbärmlich, auf der 
Persönlichkeitsebene herumzueiern.

Von Idealisierung der Programmiersprache hatte ich auch nichts gesagt, 
sondern nur dass die funktionale Programmierung nicht gut verstanden 
wird, was ja verständlich ist, denn der Code ist fremdartig, und kaum 
einer ist damit aufgewachsen, oder hat Fachzeitschriften und Bücher 
gewälzt mit funktionalen Sprachen, um Sachen auszuprobieren.
Das ist aber heute echt ein Problem.

Mein Punkt ist, dass das bessere Verständnis der funktionalen 
Programmierung und auch das Verständnis von so Geschichten wie Rust 
nicht verkehrt ist.

Alternativ könnte ich auch Werbung für Modula 3 machen - Für einen 
aktuelleren Blick über den Tellerrand ist Rust viel besser geeignet.

rbx schrieb:
> cppbert schrieb:
>> oder was meinst du?
> Hinsichtlich einer komischen hoffnungsverlorenen Perspektive ohne
> richtiges Hintergrundverständnis auf meinen Beitrag finde ich es bei
> einem so wackeligen Thema so wie hier ziemlich erbärmlich, auf der
> Persönlichkeitsebene herumzueiern.

Bitte nicht so empfindlich sein (erbärmlich und Persönlichkeitsebene war 
hier gar nichs)
dein Text von oben ist einfach maximal Interpretierungsfähig und die 
Kernaussage dahinter ist mir immer noch unklar, stört mich aber auch 
nicht

rbx schrieb:
> Von Idealisierung der Programmiersprache hatte ich auch nichts gesagt,
> sondern nur dass die funktionale Programmierung nicht gut verstanden
> wird, was ja verständlich ist, denn der Code ist fremdartig, und kaum
> einer ist damit aufgewachsen, oder hat Fachzeitschriften und Bücher
> gewälzt mit funktionalen Sprachen, um Sachen auszuprobieren.
> Das ist aber heute echt ein Problem.

vielleicht ist das mein Problem - warum gehst du auf das fehlende 
Verständnis für Funktionale Sprachen ein wenn es hier um die Imperative 
Sprache Rust geht?

> oder eben auch ein Setup für Spiele auf Linux,
> welche die Parallelität ausnutzen.

das ist eine Sache der Spiele-Implementierung - egal in welcher Sprache, 
wenn du keine Threads/Asyncs nutzt ist dein Multicore eben ungenutzt - 
da kann Rust oder jede andere Sprache nichts dran ändern - und es gibt 
doch einen Haufen gut skalierende Software für Linux, Spiele sind da 
nichts besonderes

> Bei Spielen spielen aber auch Skriptsprachen eine Rolle, Lua oder
> Javascript z.B.

geht es dir um die Einfachheit der Integration?

...

> Und ja, die Gameengines selber sind aus mehrererlei Hinsicht
> überholungsbedürftig.

in welcher Hinsicht?

cppbert schrieb:
> das ist eine Sache der Spiele-Implementierung - egal in welcher Sprache,
> wenn du keine Threads/Asyncs nutzt ist dein Multicore eben ungenutzt -
> da kann Rust oder jede andere Sprache nichts dran ändern

Das ist prinzipiell richtig.

Rust macht die Nutzung von mehreren Kernen aber deutlich einfacher, als 
andere Sprachen. Und dazu noch garantiert frei von Data Races.
Die Threading-Primitive ansich sind schon sehr einfach zu verwenden. 
Aber viele Crates bauen dort noch einfacherere APIs drum herum.


Und Async-Rust lässt sich auch mit ein paar Handgriffen auf mehreren 
Kernen parallel rechnen. Das kenne ich so von keiner anderen Sprache.

Deshalb denke ich schon, dass Rust an der Verbreitung der 
Multicorenutzung etwas ändert.

MaWin schrieb:
> Rust macht die Nutzung von mehreren Kernen aber deutlich einfacher, als
> andere Sprachen. Und dazu noch garantiert frei von Data Races.
> Die Threading-Primitive ansich sind schon sehr einfach zu verwenden.
> Aber viele Crates bauen dort noch einfacherere APIs drum herum.

Da hast du definitiv recht, aber gute skaliebarkeit und "sinnvolle" 
Parallelität immer noch ein Herausforderung, obwohl bei Rust viele 
technische Probleme gar nicht mehr passieren können

Ein T. schrieb:
> Ja, keine Frage. Ich mein', ja, ich find' Rust ja auch toll und finde es
> deswegen sehr schade, daß es sich vermutlich nicht durchsetzen wird.

Es gibt gab noch nie einen so ernsthaften Versuch eine bessere 
alternative zu C oder C++ zu erschaffen, ja, viele andere 
Programmiersprachen - aber keine Systemprogrammiersprachen das ist 
relativ einmalig, noch dazu ist es das erste mal in der Linux Geschichte 
das eine andere Sprache als C überhaupt diskutiert wird, das ist alles 
andere als nicht durchsetzen, was absolut nicht bedeutet das jeder ab 
morgen Rust macht, aber selbst wenn es noch 10 Jahre dauert wäre das 
Lichtgeschwindigkeit für eine Systemprogrammiersprache

cppbert3 schrieb:
> aber selbst wenn es noch 10 Jahre dauert wäre das Lichtgeschwindigkeit

und ich meine nicht bis jeder es nutzt und alle 300 Billionen Zeile 
C/C++ vollständig portiert sind, das ist schwachsinn sondern einen 
etablierteren Zustand

In Systemprogrammierung oder tief embedded hat bisher gar nichts, nicht 
mal minimal am C/C++ Thron gekratzt, das es sich überhaupt lohnen würde 
es anzuschauen, unabhängig von Wille und Bock

cppbert3 schrieb:
> noch dazu ist es das erste mal in der Linux Geschichte
> das eine andere Sprache als C überhaupt diskutiert wird

C++ wurde mehrfach kurz diskutiert und immer direkt abgeschmettert.

Und außerdem ist die halbe Kernelfunktionalität ja heute in (e)BPF 
programmiert. ;)

Ne ohne Spaß jetzt: Ich sehe das auch so, dass Rust der erste 
ernstzunehmende Versuch ist C direkt zu ergänzen und langfristig 
weitgehend zu ersetzen.

Ein T. schrieb:
> Systementwicklung als solche ist ja schon eine Nische

Es ist die Nische, die C heute besetzt.
C ist aus allen anderen Bereichen bereits praktisch verdrängt worden.

> Ja, ich weiß, man kann C in Rust einbinden, verliert dann aber
> einige seiner wesentlichen Vorzüge.

Man verliert nicht wirklich etwas.
Was meinst du damit?

> Und wer mal erlebt hat, wie vehement
> sich manche gestandene und erfahrene Entwickler dagegen sträuben

Ja. Das ist das Hauptproblem.

> und ähnlich fehlschlagen
> könnte wie weiland der Versuch, C++ in den Linux-Kernel zu integrieren.

Linux-Rust ist deutlich weiter als jeder vorhergehende 
C++-Linux-Versuch.

> aber
> selbst wenn es erfolgreich ist, ist die Entwicklung von
> Kernelkomponenten für Linux ja auch immer noch ein Nischending.

Linux ist eine der Kernkomponenten, die die Welt am Laufen halten.
Ich würde das jetzt nicht als Nische bezeichnen.

Ein T. schrieb:
> Nischending.

Man könnte auch sagen "gesucht" (nicht zufliegend..).

Wie etwa bei der Cuda-Schnittstelle:
https://github.com/Rust-GPU/Rust-CUDA

rbx schrieb:
> Ein T. schrieb:
>> Nischending.
>
> Man könnte auch sagen "gesucht" (nicht zufliegend..).
>
> Wie etwa bei der Cuda-Schnittstelle:
> https://github.com/Rust-GPU/Rust-CUDA

ich verstehe nie so wirklich was du sagen willst - ist eine Rust-CUDA 
Wrapper jetzt nicht Nische, oder Nische?

Cyblord -. schrieb im Beitrag #7132840:
> MaWin schrieb:
>> Linux ist eine der Kernkomponenten, die die Welt am Laufen halten.
>> Ich würde das jetzt nicht als Nische bezeichnen.
>
> Klar, Linux als Nabel der Welt. Im Nerd-Kinderzimmer sicher richtig.

jetzt komm schon, entweder trollst du äußerst gut oder hast absolut 
keine Ahnung - wenn Linux morgen von der Bildfläche verschwindet 
funktioniert so gut wie nichts mehr auf dieser Welt - nur so als Info in 
der Azure-Cloud von Microsoft sind ca. 80% Linux Server drin, fast alle 
Amazon AWS Instanzen sind Linux, fast alle Super-Computer laufen mit 
Linux, bis auf Apple fast alle Handys, alle Cloud-Systeme, Netflix, 
Amazon, Facebook, google, Whatsapp können nicht mal ansaztweise ohne, 
die Liste hört nicht auf - Microsoft ist definitiv der Desktop-König, 
aber Linux ist uneinholbar der Server und Konsumer-Devices-König - egal 
ob dir das bewusst ist
Was denkst du warum Microsoft einen Linux Extension WSL für Windows 
anbietet, oder eine eigene Linux-Distro hat?

und ich bin definitiv kein Linux-Nerd - ich muss nur hin und wieder 
dafür Software schreiben und laufe nicht mit geschlossenen Augen durch 
die Welt

Ron T. schrieb:
> Ist das nicht Ausdruck ständiger Unzufriedenheit mit dem Vorhandenen?
> Ist das nicht Ausdruck der Unmöglichkeit einer "perfekten" Sprache?

nur wenn man aus der applikativen Richtung schaut, also Java, .Net, 
Python usw. - im der Systemprogrammiersprachen Welt gab und gib es kaum 
bis gar keine Bewegung seit jahrzehnten, darum ist Rust auch was anderes 
als eine "weitere" Sprache

Ron T. schrieb:
> Weil Programmiersprachen vielleicht doch sehr auf den individuellen
> Geschmack (und individuelle Problemlösungen) angewiesen sind?

hört sich ja so an als wäre einen Neue Sprache keine riesen Zeit und 
Geld-Investition, das ist alles sehr Aufwändig und wird nicht einfach 
mal so gemacht

klarweise gibt es aber wirklich sehr viel "Versuche" die meist schnell 
wieder unrelevant werden, oder Sache die nur für Nischen relevant sind 
und einfach nie für den Mainstream gedacht sind

> Warum sprießen immerfort neue Sprachpilze aus dem Boden?

welche von denen haben länger gehalten und eine relevanz erreicht?
Alles Sprache die einfach so sprießen haben für die meisten Entwickler 
null bedeutung und sind einfach egal - ob sie aus Spass existieren oder 
nicht
- Es gibt kein Globales-Programmiersprachen-Mana das davon weniger wird 
bis nix mehr da ist, genau so wenig wie das n Kompiler nur die Resourcen 
verschwenden weil man sich ja auf einen konzentrieren könnte - ABER wenn 
die Menschen das so nicht wollen/interessiert ist das eine sinnlose 
Rechnung :)

> Ist das nicht Ausdruck ständiger Unzufriedenheit mit dem Vorhandenen?
> Ist das nicht Ausdruck der Unmöglichkeit einer "perfekten" Sprache?

so denken nur Anfänger - das kann und ist keine relevante Triebfeder
- unfährt genauso blöde wie 
wir-müssem-alles-dann-neuschreiben-sonst-ist-es-nicht-perfekt, 
nur-wenn-es-in-einer-Sprache-geschrieben-ist-ists-auch-gut Mentalität - 
alles total überholte Denke die man ein wenig Aufweichen kann

die meisten Menschen erwarten von einer neuen Programmiersprache 
dramatische Verbesserung ala - jetzt kann jeder das neue Doom39 
schreiben weil alles automatisch geht - aber das ist nie so - es gibt 
nur inkrementelle Verbesserung oder Micro-Revolutionen UND die werden 
dann meistens kaum verstanden weil mehr als 50% der Entwickler eh 
einfach nur die Sprache nutzt die der Chef befohlen hat :)

Mentalität, Erfahrung und die darauf basierenden Bedürfnisse sind so 
vielschichtig das es kaum möglich ist irgendwie einen direkt 
Begreifbaren Nenner zu finden - aber stehenbleiben war noch nie gut

Ich kann mir schwerlich vorstellen das wir in 200 Jahren (falls es uns 
da noch gibt) noch C/C++ Code schreiben - maximal pflegen wir noch ein 
paar Zeilen irgendwo auf dem Mars :)

und nicht das ich falsch Verstanden werden - ich über die letzten 25 
Jahre  bisher mehrere x Million Zeilen Code, Multiplatform, C++ Projekte 
begonnen,
angeleitet und betreut (nebst .Net, Java, Python...) - ich kenne mich 
ein wenig aus :)

Ich finde es auch super wie viele Entwickler (damit meine ich nicht 
unbedingt die anwesenden hier) und auch besonders Nicht-Entwickler, oder 
(die schlimmste Form) Pseudo-Entwickler sich über die vielfalt an 
Programmiersprachen aufregen obwohl sie nie wirklich Kontakt dazu haben 
- warum stresst Leute deren Existenz nur im geringsten und speziell die 
Leute mit dem geringsten Einfluss und technologischer Breite? so ein 
bisschen wie die Katholische Kirche und Neuerungen - die existenz ist 
schon bedrohlich :)

Jörg W. schrieb:
> die Zahl der Speicherlecks und Sicherheitsprobleme ist immer noch
> recht erheblich.

Wie sieht diese "Statistik" denn für die Rust-Komponenten aus? Das ist 
ja, worauf es ankommt.
(Und Rust verhindert keine Speicherlecks, sondern erschwert sie nur.)

MaWin schrieb:
> (Und Rust verhindert keine Speicherlecks, sondern erschwert sie nur.)

weil Speicherlecks für Systemprogrammierung (Hardware mapped Speicher 
usw.) nötig sein können - einer der wenigen Anwendungsfälle :)

cppbert schrieb:
> MaWin schrieb:
>> (Und Rust verhindert keine Speicherlecks, sondern erschwert sie nur.)
>
> weil Speicherlecks für Systemprogrammierung (Hardware mapped Speicher
> usw.) nötig sein können - einer der wenigen Anwendungsfälle :)

UND man muss das auch gezielt sagen sonst gibt es keine ungewollten 
Leaks:

std::mem::forget
Box::leak
Box::into_raw bei unsafe

cppbert schrieb:
>> weil Speicherlecks für Systemprogrammierung (Hardware mapped Speicher
>> usw.) nötig sein können - einer der wenigen Anwendungsfälle :)
>
> UND man muss das auch gezielt sagen sonst gibt es keine ungewollten
> Leaks:

Naja, der Grund ist eher, dass man Speicherlecks prinzipiell gar nicht 
100% verhindern kann.
Man kann in Rust ein Speicherleck ohne diese explizit leckenden 
Funktionen bauen, indem man eine Referenzschleife baut. So eine 
Referenzschleife ist dann von außen nicht mehr referenziert, aber erhält 
sich selbst weiterhin am Leben. Es ist damit ein Leck.

Die explizit leckenden Funktionen wie forget waren früher unsafe. Man 
hat dann aber erkannt, dass man auch ohne diese Funktionen Speicher 
lecken konnte. Und dann hat man forget safe gemacht.

Trotzdem ist es extrem schwierig versehentlich in Rust Speicher zu 
lecken.

MaWin schrieb:
> Man kann in Rust ein Speicherleck ohne diese explizit leckenden
> Funktionen bauen, indem man eine Referenzschleife baut.

Enttäuschend. Dass nichteinmal Rust es schafft, Memory Safty & 
praktische Brauchbarkeit unter einen Hut zu bringen... Den Level an 
Sicherheit krieg ich mit C++ smart Pointern auch...

DPA schrieb:
> MaWin schrieb:
>> Man kann in Rust ein Speicherleck ohne diese explizit leckenden
>> Funktionen bauen, indem man eine Referenzschleife baut.
>
> Enttäuschend. Dass nichteinmal Rust es schafft, Memory Safty &
> praktische Brauchbarkeit unter einen Hut zu bringen... Den Level an
> Sicherheit krieg ich mit C++ smart Pointern auch...

MaWin spricht von Cyclic Leaks - das bekommst du auch mit C++ 
Smartpointer hin - macht eben niemand - das lässt sich nicht "lösen" 
ohne das du eine Funktionale Programmiersprache nutzt

Mombert H. schrieb:
> cppbert schrieb:
>> DPA schrieb:
>>> MaWin schrieb:
>>>> Man kann in Rust ein Speicherleck ohne diese explizit leckenden
>>>> Funktionen bauen, indem man eine Referenzschleife baut.
>>>
>>> Enttäuschend. Dass nichteinmal Rust es schafft, Memory Safty &
>>> praktische Brauchbarkeit unter einen Hut zu bringen... Den Level an
>>> Sicherheit krieg ich mit C++ smart Pointern auch...
>>
>> MaWin spricht von Cyclic Leaks - das bekommst du auch mit C++
>> Smartpointer hin - macht eben niemand - das lässt sich nicht "lösen"
>> ohne das du eine Funktionale Programmiersprache nutzt
>
> Eben, keine Pluspunkte für rusts Memory Safty an dieser Stelle.

Das lässt sich in einer Imperative (Statefull-Sprache) nicht lösen (also 
.Net, Java, C, C++, und,und,und)
das ist kein KO-Kriterium für Rust - wer das nicht verstehe kann/will 
sollte sich Kommentare echt sparen, das wirkt nicht besonders Inteligent 
oder Erfahren was die Hintergründe bei allen von uns verwendeten 
Programmiersprachen sind

Wieder so eine sinnfreie Argumentation - wenn es nicht 100% Sicherheit 
erreicht mache ich mit meinen <10% weiter wie bisher, gleiche 
Argumentation wie bei der Corona-Impfung - wenn die nicht 100% wirkt 
warum soll ich es dann machen - weil sie eben 30-50% wirkt, oder der 
Sicherheitsgurt: Der garantiert auch keine 100% Sicherheit - dann kann 
ich den ja auch weg lassen

cppbert schrieb:
> <10%

.Net, Java, C++

cppbert schrieb:
> .Net, Java, C, C++, und,und,und

...

> mache ich mit meinen <10% weiter

.Net, Java, C++ (unter Verwendung von smart Pointen, wie heutzutage 
üblich), und <10%. lol.

Viel glück in Java einen use after free zu generieren, das ist da 
mindestens so gut wie rust, das zu verhindern. Rust mag beim Threading 
ein paar Vorteile haben, in der Theorie. Aber wenn du glaubst, die 
Alternativen wären derart unsicher, liegst du schlicht komplett falsch.

cppbert schrieb:
> warum stresst Leute deren Existenz nur im geringsten und speziell die
> Leute mit dem geringsten Einfluss und technologischer Breite?

Weil es an ihrem Weltbild zerrt.

Die allermeisten Menschen möchte einfache, simple Erklärungen wie die 
Welt funktioniert. Dann haben sie das Gefühl sie verstünden die Welt und 
könnten sich ein Urteil bilden, eine Meinung haben und mitdiskutieren.

Komplexität schreckt die meisten Menschen ab. Darum wird Komplexität 
verleugnet. Endstadium: Verschwörungstheorie.

DPA schrieb:
> unter Verwendung von smart Pointen

Ich weiß, dass ich einem Troll antworte. Aber das Thema generell ist es 
schon wert noch einmal zu betrachten.

C++ Smart Pointer sind eine tolle Sache. Ich nutze sie in C++ auch 
gerne.
Aber was, wenn ich an einer Stelle vergesse sie zu verwenden? In Rust 
wird die Verwendung erzwungen.

Außerdem sind die Rust-Mechanismen (Referenzen, Pointer und Lifetimes) 
deutlich ausdrucksstärker und mächtiger als C++ Smart Pointers. Und auch 
besser zur Compilezeit prüfbar, durch die Rust-Referenzregeln und 
Lifetimes, die es in C++ beide nicht gibt.

MaWin schrieb:
> Aber was, wenn ich an einer Stelle vergesse sie zu verwenden?

Du tippst ausversehen "*" statt std::shared_ptr<> usw. ein? Komplett 
unabsichtlich?

> In Rust wird die Verwendung erzwungen.

Es gibt doch unsafe und raw pointer, wer verhindert, dass du die genauso 
"versehentlich" einsetzt?

MaWin schrieb:
> Außerdem sind die Rust-Mechanismen (Referenzen, Pointer und Lifetimes)
> deutlich ausdrucksstärker und mächtiger als C++ Smart Pointers. Und auch
> besser zur Compilezeit prüfbar, durch die Rust-Referenzregeln und
> Lifetimes, die es in C++ beide nicht gibt.

Ok, beim Threading ganz nützlich. Aber abgesehen davon sehe ich nur 
einen geringen Nutzen. Und dem gegenüber steht, mit dem borrow Checker 
kämpfen zu müssen. Was hab ich den nun wirklich davon?

DPA schrieb:
> cppbert schrieb:
>> .Net, Java, C, C++, und,und,und

Da ging es um den Zyklus in der Referenzierung - gut da sind die GC 
Sprachen teilweise in der Lage zu aber wenn wir von Rust sprechen geht 
es eingentlich eher um C/C++

> Viel glück in Java einen use after free zu generieren, das ist da
> mindestens so gut wie rust, das zu verhindern. Rust mag beim Threading
> ein paar Vorteile haben, in der Theorie. Aber wenn du glaubst, die
> Alternativen wären derart unsicher, liegst du schlicht komplett falsch.

das sagt niemand und das ist hier auch immer der Irrglaube - die meisten 
Rust-Befürworter mögen die "Steigerung" der Sicherheit die andere Seite 
geht immer irgendwie davon aus man sich nicht auskennt, als wenn 
Smart-Pointer-Verwendung in C++ überhaupt in den letzten +15 Jahren 
jemals zur Diskussion standen - auch wenn Sie erst mit C++11 wirklich 
richtig schön implementierbar wurden, wir waren noch in den 90er als die 
Smartpointer relevant wurden, das ist ein alter Hut und trotzdem kann 
bis heute mit 3 von 10 Entwicklern immer doch darüber diskutieren ob man 
die einsetzen sollte - die Frage stellt sich bei Rust nicht - da ist das 
implizit

und btw: ohne ASAN würde man in C++ auch keine Use-After-Free so einfach 
finden - wenn man nicht alles zubaut mit Smart-Pointern, aber das dieser 
Luxus auch er wenige Jahre existiert und es immer noch sehr viele 
Entwickler gibt die denke das man Sanitizer gar nicht braucht erschreckt 
mich

und btw: die Sanitizer sind von Google, welche sagen sie bekommen das 
mit C++ und ihren Hochgeschultet Entwicklern nicht hin - trotz 
Smart-Pointer, bei fast 1Mrd. Zeilen C++, welche die selben sind die 
auch Rust in den Kernel pushen

aber das ist hier allen ja klar - so lange man nicht zwischen den Zeilen 
den Anfänger vermutet und entsprechen kontert

Mombert H. schrieb:
> Du überreagierst etwas ... nichts von dem was du unterstellst hast, habe
> ich geschrieben. Ich habe nichts von KO-Kriterium geschrieben und ich
> habe nicht Argumentiert. Ich habe jediglich geschrieben, dass es an
> dieser Stelle keine Pluspunkte für rust gibt.

Sorry - du hast absolut recht, ich dich wirklich falsch verstanden

DPA schrieb:
> Du tippst ausversehen "*" statt std::shared_ptr<> usw. ein? Komplett
> unabsichtlich?

das ist wieder viel zu detailiert - du, ich und MaWin benutzen alle 
schon garantiert lange und kontinuilierich Smart-Pointer - das steht 
ausser Frage sonst bräuchte keiner von uns hier irgenwie mitreden

Rust macht den Unterschied as ein Goßteil der üblichen Smart-Pointer 
Verschmutzung deiner Schnistellen ins Type-System verschoben wird - das 
ist ein nicht zu kleiner Teil des Codes - und stören Smart-Pointer auch 
nicht - aber wenn ich Sie nicht schreiben muss und noch Ausdrucksstärker 
sein kann, warum nicht?

btw: ich habe noch nicht erlebt das ein guter C++ Entwickler probleme 
hatte mit dem Borrow-Checker, der forciert nur Struktur-Strategien die 
eh üblich sind, nur die Drauf-los-Bastel-Fraktion die noch viel 
ausprobieren muss tut sich damit schwer - aber wer will die den in 
seinem Code rumorgeln lassen
das ist z.B. genau der Teil der Entwickler die tunlichst die Finger von 
Kernelentwicklung lassen sollten

und die ganze Argumentation endet irgendwie immer in - mir reicht der 
Vorteil nicht, ich mag das nicht, unrelevant für mich, ungebraucht von 
mir - das ist in Ordnung aber ist keine ordentliche Diskussion möglich 
wenn jemand der keinen Sinn an dem Ownership-Modell sieht und 
Smart-Pointer als ausreichende Lösung empfindet gegen einen 
Rust-nett-Finder argumentiert
Das ist so wie wenn ein Milch-Trinker mit einem Wiskey-Liebhaber 
diskutiert - das kommt nichts bei raus...

DPA schrieb:
> Was hab ich den nun wirklich davon?

Garantierte Memory-Safety.

Mombert H. schrieb:
> Ich weiß nicht wie man das vergessen soll

Komisch, wo dann ständig die ganzen Memory-Safety-Bugs herkommen.

Mombert H. schrieb:
> Da sind wir wieder bei PYTRAN77. Glaubst du wirklich, dass Entwickler,
> die es in C++ nicht hinbekommen (weil unfähig oder unwillig) konsistent
> Smart-Pointer einzusetzen, zu rust wechseln und alle Probleme sind
> verschwunden? Wo sollen da plötzlich die zusätzlichen Gehirnzellen oder
> der Wille herkommen?

Nein nicht alle, das wäre dumme zu denken, aber Sie können sich mehr auf 
die logischen oder strukturellen Probleme konzentrieren - damit haben 
die ja auch schon Probleme :) - was bringt es uns Sie damit zusätzlich 
zu belasten (mal außen vor gelassen das es noch viel C++ gibt und die 
das eh machen müssen)

und wie gesagt - ich kann sehr gute C++ Software schreiben, ich kämpfe 
nicht mit C++ Probleme, oder ich habe genug Erfahrung das richtige zu 
tun - aber ich verstehe, wenn ich teilweise in +100 Entwickler-Teams 
sitze das meine eigenen Bedürfnisse und Fähigkeite nicht automatisch für 
das Team relevant sind
und DAS ist der Unterschied - der Maßstab bei dem Rust-Features anfangen 
mehr Bedeutung zu bekommen - jedes mal wenn einer aus der 
Ich-Perspektive Argumentiert sitzt er alleine da und denk nicht an das 
Team und die Million von Entwicklern die auf der Welt verteilt sind - 
dafür werden bessere Programmiersprachen entwickelt - unabhängig davon 
ob die angenommen werden oder wegen sinnlosigkeit sterben

Mombert H. schrieb:
> MaWin schrieb:
>> Mombert H. schrieb:
>>> Ich weiß nicht wie man das vergessen soll
>> Komisch, wo dann ständig die ganzen Memory-Safety-Bugs herkommen.
> Vielleicht haben sie sich gegen Smart-Pointer entschieden? Es gibt noch
> alternativen zum Vergessen.

Das könnte man vermutlich ganz einfach mit einem Linter fixen, der 
einfach keine normalen Pointer akzeptiert. Dann setzt man das als git 
hook im Repo, um es zu erzwingen. Und schon sind 99% der Probleme weg.

Mombert H. schrieb:
> Vielleicht weil sie in ihren C++-Regeln*Prefer* to have single, fixed
> owners for dynamically allocated objects. Prefer to transfer ownership
> with smart pointers.
> zu viele "prefer" haben?

und wir sind wieder bei dem die haben wohl schlechte Regeln oder 
schlechte Mitarbeiter Argumentation - google investiert viel Zeit und 
Geld in seine Mitarbeiter, was sollen die sonst noch tun - auf bessere 
Zeiten hoffen? damit ihre zig tausend Entwickler so gut werden das die 
Testabteilung:Weltbevölkerung bei denen keine Fehler mehr findet, das 
ist irrglaube in diesem Dimensionen, deswegen haben die google Leute die 
Sanitizer entwickelt und dann nach ein paar Jahren festgestellt das es 
immer noch nicht reicht - welche Firma die nicht so gross ist betreibt 
denn noch so einen Aufwand um besser zu werden?

Die Realität ist: Es wird zu wenig getestet, die Projekte werden immer 
komplexer, das erschwert das testen weiter, TDD ist nicht die Lösung, 
bessere Mitarbeitet ist der feuchte Traum jeden Abteilungsleiters und 
der menschliche Faktor ist schwierig zu kontrollieren - vielleicht in 
den 15 Mann Buden in denen wir alle mal hin und wieder gearbeitet haben 
aber nicht für zig-tausend Entwickler - und das bedeutet nicht das wir 
alle und alle Firmen ständig leakend und abstürzenden C++ Programme 
schreiben - absolut nicht

DPA schrieb:
> Mombert H. schrieb:
>> MaWin schrieb:
>>> Mombert H. schrieb:
>>>> Ich weiß nicht wie man das vergessen soll
>>> Komisch, wo dann ständig die ganzen Memory-Safety-Bugs herkommen.
>> Vielleicht haben sie sich gegen Smart-Pointer entschieden? Es gibt noch
>> alternativen zum Vergessen.
>
> Das könnte man vermutlich ganz einfach mit einem Linter fixen, der
> einfach keine normalen Pointer akzeptiert. Dann setzt man das als git
> hook im Repo, um es zu erzwingen. Und schon sind 99% der Probleme weg.

wir nutzen doch schon alle Linter bis zum Umfallen, und git, perforce, 
svn Hooks ein für jeden Scheiss - die sau-teueren und die freeware, open 
source sachen - man findet immer und immer wieder Sachen, die Menge geht 
nicht runter - es ist immer noch stark an der eingetragenen 
Quelltextmenge fest zu machen - und das scheint bei vielen Firmen der 
Fall zu sein - ob du das so kennst ist eine andere Sachen, aber es 
existiert

DPA schrieb:
> Und schon sind 99% der Probleme weg.

Wenn man sich am Riemen reißt und alles richtig programmiert, dann sind 
sogar 100% der Probleme weg. Einfach keine Fehler machen und alles ist 
gut.

Der Vorteil von Rust ist, dass diese Fehler dort gar nicht möglich sind.

Mombert H. schrieb:
> Nur weil sie in rust dazu gezwungen werden es richtig zu machen, heißt
> nicht, dass sie es automatisch sofort richtig machen können. rust nimmt
> einem nicht die Arbeit ab, es richtig zu machen. Man wird nur dazu
> gezwungen es auf die rust-Art zu machen, die in den allermeisten Fällen
> zu mehr Sicherheit führt.

Das hört sich eingezwänger als als es tatsächlich ist

> Es ist auch nicht so, als wäre es in C++ wirklich schwierig es richtig
> zu machen, wenn man es will.

"man will" ist und bleibt das Kernproblem das man versucht (irgendwie) 
zu adressieren - wenn man das als sinnlos empfindet bringt Rust an 
dieser Stelle einfach nicht viel - weil es kein Problem gibt - oder 
Probleme nicht reduziert werden können (die Natur der Sache)

cppbert schrieb:
> Das hört sich eingezwänger als als es tatsächlich ist

Genau. Der Rust-Compiler gibt einem sehr gute Hinweise und die 
Compilerfehlerdokumentation ist auch sehr hilfreich. Das ist gar nicht 
vergleichbar mit den kryptischen Kram, den GCC und MSVC so rauswerfen.

In der Regel steht die Lösung für das Problem, oder ein Vorschlag, der 
der Lösung bereits sehr nahe kommt, in der rustc-Fehlermeldung mit drin. 
Und wenn nicht, dann findet man in der zugehörigen, direkt vom Compiler 
verlinkten, Dokumentation eine genaue Erklärung, warum das nicht gut 
ist, was man da tut.

cppbert schrieb:
> "man will" ist und bleibt das Kernproblem das man versucht (irgendwie)
> zu adressieren - wenn man das als sinnlos empfindet bringt Rust an
> dieser Stelle einfach nicht viel

Es geht über den reinen Willen hinaus.
Rust hat einfach einige sehr unschöne Altlasten nicht, die C/C++ 
mitbringt. Zum Beispiel Integer-Promotion, Typbalancierung und implizite 
Typwandlungen gibt es alle in Rust nicht. Und Bugs ausgelöst durch diese 
Altlasten haben wohl die meisten Programmierer einmal versehentlich 
gemacht.
Es ist insgesamt viel schwieriger solche grundlegenden und nicht direkt 
offensichtlichen Fehler zu machen.

Und diese ganze Smart-Pointer Aussage ist auch ohne Relevanz wenn wir 
von C sprechen - oder will hier ernsthaft jemand behaupten das er jemals 
diese fiesen Macro-basierte Smart-Pointer libs für C genutzt hat?

im Embedded-Breich ist C eben z.B. auch deswegen stark weil es definitiv 
gar keine Runtime Braucht, im gegensatz zu C++ wegen Execptions (die auf 
dem Heap landen) - das ist z.B. auch ein Grund warum sich C++ da so 
nicht durchsetzt

Rust hat diese Nachteile nicht - genau wie C keine Runtime nötig (gut so 
lange man auf Standard-Async verzichtet) und trotzdem hat man dort die 
Sicherheit
die mit sonst manuell eingebrachten Smart-Pointern

Mombert H. schrieb:
> cppbert schrieb:
>> im Embedded-Breich ist C eben z.B. auch deswegen stark weil es definitiv
>> gar keine Runtime Braucht, im gegensatz zu C++ wegen Execptions (die auf
>> dem Heap landen) - das ist z.B. auch ein Grund warum sich C++ da so
>> nicht durchsetzt
> Bist du sicher, dass das der Grund ist? Oder ist es vielleicht nur ein
> Vorwand der "Ich will nicht"-Fraktion?

ja das auf jeden Fall auch

> Denn auch C braucht eine Runtime, wenn man die ganze Sprache nutzen will

die Sprache kommt ohne Runtime aus - oder meinst du die Standard 
Library?

cppbert schrieb:
> ich verstehe nie so wirklich was du sagen willst

Das ist jetzt aber nicht mein Problem :)

cppbert schrieb:
> ist eine Rust-CUDA
> Wrapper jetzt nicht Nische, oder Nische?

Das mit dem "Gesucht" war ergänzend zum Nischenargument gemeint, und 
würde zusammen mit dem Nischen-Vorwurf in DPAs Runterwertungsschublade 
passen.

Also "Nische" + "Gesucht".

Dass der Link auch zweideutig gemeint war, hast du nicht mitbekommen - 
möglicherweise, weil du den etwas zu ernst genommen hast.

Mombert H. schrieb:
> Für mich gehört die Standard Bibliothek zur Sprache. Beide werden in
> einem Dokument mit der überschrift "Programming languages — C" definiert
> und nicht streng getrennt.

auf embedded kann es aber sein das du die Runtime komplett ersetzen 
willst, das geht mit C und Rust - aber nicht mit C++ - weil du die 
Exceptions nur vermeiden kannst aber da ist die Runtime trotzdem (oder 
kann man das mitlerweile auch entfernen? aber dann wieder 
Kompiler-Spezifisch)

z.B. der Linux Kernel nutzt ja auch seine "eigene" Standard-Library weil 
er die GlibC klarerweise nicht nutzen kann

Mombert H. schrieb:
> Wie schafft man es z.B. eine stdarg.h oder
> float.h zu erstellen

ja das wird schwierig - one aligment-Wissen wird das nix - ok mit C11 
bekommt man das alignof noch raus usw. aber bastelig ist es definitiv

Wie ist in Rust eigentlich die async / await Geschichte implementiert?

Mein momentaner Wissensstand ist, dass async Funktionen analog zu 
co-routinen sind / man das eine mittels dem anderen implementieren kann. 
co-routinen, und damit async funktionen, bräuchten damit einen 
zusätzlichen Stack.

Ist das bei Rust auch so, braucht der Aufruf jeder async funktion einen 
eigenen Stack? Oder wurde da eine bessere Methode gefunden, das 
umzusetzen?

Ich kenne async-await hauptsächlich von javascript und python her, es 
ist unglaublich praktisch. Falls ich mal meine eigene Programmiersprache 
entwickle, würde ich so ein feature auch wollen. Aber ich will nicht 
wirklich den Preis, den Speicher & Adressraum für mehrere Stacks, 
zahlen. Insbesondere wenn man auf tausende Sachen wartet, wie verhindert 
man da dass das enorm Speicher verbraucht? Und wie verhindert man, dass 
sich die Stacks in die quere kommen? Ich konnte das bisher noch nicht 
heraus finden.

DPA schrieb:
> Wie ist in Rust eigentlich die async / await Geschichte implementiert?
https://rust-lang.github.io/async-book/01_getting_started/02_why_async.html

1

Async in Rust vs other languages

2

3

Although asynchronous programming is supported in many languages, some details vary across implementations. Rust's implementation of async differs from most languages in a few ways:

4

5

[...]

6

7

Async is zero-cost in Rust, which means that you only pay for what you use. Specifically, you can use async without heap allocations and dynamic dispatch, which is great for performance! This also lets you use async in constrained environments, such as embedded systems.

8

9

[...]

...und die Runtime für Async ist austauchbar - damit man keinen Standard 
für alle definiert der dann in der Systemprogrammierung eh nie passt :)

das macht das ganze aber ein bisschen komplizierter, weil man die Wahl 
zwischen verschiedenen Backends die nicht unbedingt von den Rust-Leuten 
selber kommen - das stört die Alles-aus-einer-Hand-Fraktion ein wenig

> Async is zero-cost in Rust, which means that you only pay for what you use.

Das ist ja gute Werbung, aber mich interessiert: Was heisst das, und wie 
geht das? Nehmen wir gerade mal das Beispiel auf der Seite:

1

async fn get_two_sites_async() {

2

    // Create two different "futures" which, when run to completion,

3

    // will asynchronously download the webpages.

4

    let future_one = download_async("https://www.foo.com");

5

    let future_two = download_async("https://www.bar.com");

6

7

    // Run both futures to completion at the same time.

8

    join!(future_one, future_two);

9

}

Um mal zu illustrieren, was mir unklar ist, nehmen wir mal folgenden 
execution flow, und nur einen Stack an:

1

get_two_sites_async

2

  join!

3

    future_one (download_async)

4

      ruft ne funktion auf

5

        muss auf IO warten

6

          future_two (download_async)

7

            ruft ne funktion auf

8

              muss auf IO warten

9

    future_one wird fortgesetzt

10

      ruft ne funktion auf  >>> (Wo landet das jetzt auf dem Stack?)

11

    future_one ist fertig

12

              future_two (wird fortgesetzt)  >>> (Wo liegt das jetzt auf dem Stack? Ist da jetzt einfach ne lücke, wo future_one war?)

Wie haben die das gelöst? Wie geht das?
Oder gibt es da 2 Stacks, auch in rust, und zero-cost heisst da nur 
Bestmöglich, statt effektiv gratis?

cppbert schrieb:
> ...und die Runtime für Async ist austauchbar - damit man keinen Standard
> für alle definiert der dann in der Systemprogrammierung eh nie passt :)

Ok, heisst das, dass halt die Runtime den Kompromiss machen müssen, und 
dort die Kosten entstehen, mehrere Stacks zu brauchen, während die API 
selbst prinzipiell schon zero-cost wäre?

DPA schrieb:
> cppbert schrieb:
>> ...und die Runtime für Async ist austauchbar - damit man keinen Standard
>> für alle definiert der dann in der Systemprogrammierung eh nie passt :)
>
> Ok, heisst das, dass halt die Runtime den Kompromiss machen müssen, und
> dort die Kosten entstehen, mehrere Stacks zu brauchen, während die API
> selbst prinzipiell schon zero-cost wäre?

ja ich glaube das es so ist - aber vielleicht kann MaWin uns da mehr 
erleuchten - Rust versucht so viel wie möglich mit Move oder 
trivial-Copy zu machen - vielleicht heisst das hier auch 
Nearly-Zero-Copy

das ist mir im Detail auch noch nicht klar wie die das machen - ich gehe 
auch davon aus das man n Stacks haben muss

ich hab auch gelesen das die Runtime nicht notwendigerweise alles mit 
Threads machen muss - also auch so co-routine Style im Hintergrund 
moeglich, weil eben die Kleinst-Systeme vielleicht nur ein paar 
statische Puffer am auf denen sie operieren dürfen

Ich fordere Tiefen-Erleuchtung!

DPA schrieb:
> Wie haben die das gelöst? Wie geht das?
> Oder gibt es da 2 Stacks, auch in rust, und zero-cost heisst da nur
> Bestmöglich, statt effektiv gratis?

Eine Async-Funktion in Rust unterbricht ihre Ausführung nur an 
.await-Stellen, dazwischen arbeitet sie grundsätzlich synchron. Zur 
Fortsetzung muss die Runtime wieder die poll-Methode aufrufen. Von jeder 
Unterbrechung bis zur Fortsetzung liegen die benötigten lokalen 
Variablen im Future-Objekt selbst. Die Größe des Future-Objekts ist 
statisch bekannt, da alle lokale Variablen eine bekannte Größe haben 
müssen. Als Konsequenz sind jedoch rekursive async-Aufrufe nicht in sich 
geschlossen möglich; dort kommt man um die Nutzung des Heaps meist nicht 
herum.
Die Async-Sprachintegration ist im Grunde Syntaxzucker zur Erstellung 
von Zustandsautomaten (->Future).
Die Anzahl der benötigten Stacks beläuft sich also auf genau die Anzahl 
der Async-Worker-Threads.

https://www.reddit.com/r/rust/comments/w4cwvj/how_much_zerocost_is_async/

>
> Async functions desugar to something that looks a bit like an enum, with each 
variant representing a section between await points (and the associated state it 
needs).
>
> There's no reason for anything to be heap allocated, because the entire 
structure is known at compile time. You can put a future on the heap if you want, 
but you can just use impl Future if you don't want to (this is what an async fn 
does).
>
>There is one major exception: traits. Async functions in traits are currently not 
possible, but something quite similar can be achieved using the async-trait crate. 
This performs some of the same rewriting that the compiler does with regular async 
functions, but for various reasons, it needs to allocate futures on the heap.
>
>However, this restriction is expected to be lifted. Generic associated types 
(GATs) are one of the key blockers, and are close to being stabilized, but there 
are still some unresolved issues. However, it's possible that GATs can be used to 
implement "async fn in traits" before they are stabilized as a user-facing 
feature.
>

Jörg W. schrieb:
> auf einem Controller wird man wohl oder
> übel vorab Stacks definieren müssen.

Kommt drauf an, auf dem Raspi könnte man auch OS-Ressourcen benutzen. 
Fragen könnte man sich, wie die Rust-Entwickler das mit der intensiven 
Cachenutzung und dem Alignment hinbekommen haben.
Man kann aber ahnen, worauf es hinausläuft.
Besondere Bibliotheken, bzw. Unterstützung für Embedded soll es auch 
geben.

Wer Assembler kennt, und C, der weiß auch, dass vieles einfach über 
Zeiger läuft.
(oder Basic, goto xy)
Speichermanagement mit statischen Variablen stelle ich mir auch nicht 
sonderlich schwierig vor.

Hinzu kommt, dass bei so Compilergeschichten und Programmiersprachen 
vieles letztendlich über C läuft, da braucht man sich über "kostenlose" 
Unterfunktionen in C nicht wundern.
Parameterübergabe kann man sich ja mal in Haskell ansehen - Ich bin da 
sicher nicht der einzige, dem es diesbezüglich ein wenig an Pragmatik 
fehlt.

Wenn im Hexeditor zwischen zwei Funktionen zuviel Platz erkennbar ist - 
nun, dafür hat man ja auch einen Hexeditor :)

Die eine gute Analogie wäre: neues Motorrad, viel PS und schnell, 
Superhandling, aber Elektroantrieb.

Mir würde der gute Sound fehlen, aber es gibt auch Leute, die fragen 
nach dem Ölverbrauch ;)

rbx schrieb:

hier gibt es ordentlich Klärungsbedarf - du hast mich wieder mal 
verwirrt

> Kommt drauf an, auf dem Raspi könnte man auch OS-Ressourcen benutzen.

was sind OS-Ressourcen beim Raspi? irgendwelche In-Kernel Bereiche, ist 
das nicht Raspi-OS nicht einfach Linux, da kenn ich sowas nicht

> Fragen könnte man sich, wie die Rust-Entwickler das mit der intensiven
> Cachenutzung und dem Alignment hinbekommen haben.

was meinst du mit hinbekommen?

> Wer Assembler kennt, und C, der weiß auch, dass vieles einfach über
> Zeiger läuft.
> (oder Basic, goto xy)

das ist doch der 90% Fall, oder?
und welche Gemeinsamkeit haben Zeiger und goto?

> Hinzu kommt, dass bei so Compilergeschichten und Programmiersprachen
> vieles letztendlich über C läuft, da braucht man sich über "kostenlose"
> Unterfunktionen in C nicht wundern.

was sind "kostenlose" Unterfunktionen bei C?

> Parameterübergabe kann man sich ja mal in Haskell ansehen - Ich bin da
> sicher nicht der einzige, dem es diesbezüglich ein wenig an Pragmatik
> fehlt.

hat Haskell Parameterübergabe ähnlichkeit zu Async-Stacks?

> Wenn im Hexeditor zwischen zwei Funktionen zuviel Platz erkennbar ist -
> nun, dafür hat man ja auch einen Hexeditor :)

Für was ist denn der Platz? Normalerweise doch für gar nichts ausser 
Alignment, oder was meinst du?

Async/Await benötigt in keiner Programmiersprache eigene Stacks pro 
"Warte-Stelle" oder Async-Funktion.

Der Witz an Async/Await ist doch genau der, dass das nur Syntax-Zucker 
für Callbacks ist. Async/Await sind eben genau keine Threads, weder 
OS-Threads noch Green-Threads.

Ganz Allgemein macht ein Compiler aus

1

  funtion a() {

2

    teil_vorher();

3

    ergebnis = await async_funtion();

4

    teil_nachher();

5

  }

zwei Funktionen, und der Teil nach dem await() wird eine 
Callback-Funktion der async-Funktion:

Also etwa:

1

  funtion a_impl() {

2

    teil_vorher();

3

    async_funktion_impl(&a_weiter_impl);

4

  }

5

6

  funktion a_weiter_impl(ergebnis_von_async_funktion) {

7

    teil_nachher();

8

  }

Natürlich kommt da noch ein wenig Brimborium dazu, und in manchen 
Sprachen, z.B. Rust, wird noch etwas mehr gemacht. Aber das Grundprinzip 
ist immer gleich: Keine Threads, sondern nur eine State-Maschine die mit 
Callbacks implementiert ist.

Programmierer schrieb:
> Async/Await benötigt in keiner Programmiersprache eigene Stacks
> pro "Warte-Stelle" oder Async-Funktion.
> Der Witz an Async/Await ist doch genau der, dass das nur Syntax-Zucker
> für Callbacks ist. Async/Await sind eben genau keine Threads, weder
> OS-Threads noch Green-Threads.

Ok aber wie kann ich dann Async Funktionen wirklich parallel laufen 
lassen, also in verschiedenen Threads, um wirklich auf mehrere Kerne zu 
skalieren, oder gibt es dafür etwas ganz anderes, oder ist meine 
Threadingdenke zu antiquiert/eingefahren nach den vielen Jahren?

Programmierer schrieb:
> Async/Await sind eben genau keine Threads

Wie bereits gesagt:
In Rust können async-Tasks auch auf Threads laufen.

https://docs.rs/tokio/1.20.0/tokio/runtime/index.html#multi-thread-scheduler

Das Rust-Typsystem mit seiner inhärenten Thread-safety macht es möglich.

MaWin schrieb:
> Wie bereits gesagt:
> In Rust können async-Tasks auch auf Threads laufen.

Exakt. Das ist eine Besonderheit bei Rust, die durch das verwendete 
Memory-Modell erst möglich wird.


cppbert3 schrieb:
> Ok aber wie kann ich dann Async Funktionen wirklich parallel laufen
> lassen, also in verschiedenen Threads,

Async/Await als Konzept hat erstmal nichts mit Threads zu tun und laufen 
(eigentlich) niemals "parallel". Das ist eine Rust-Besonderheit. In 
anderen Sprachen ist das nicht möglich.

> um wirklich auf mehrere Kerne zu skalieren

Async/Await ist für den IO-Bound-Fall gedacht, dass also Dein Programm 
durch die IO-Bandbreite begrenzt wird, und nicht durch die 
CPU-Bandbreite.
Das ist in einem einfachen Programm der Fall, während es große Dateien 
verarbeitet und während dessen z.B. einen Spinner auf der Konsole 
anzeigt, oder ein paar Dateien aus dem Internet heruntergeladen werden.
Oder bei einem Server, der 20.000 Clients gleichzeitig irgendwelche 
HTML-Seiten ausliefert.

Threads wiederum sind für CPU-Bound-Fälle ideal. D.h. das Programm muss 
etwas berechnen, z.B. Primzahlen oder eine numerische Lösung finden z.B. 
eine elektronische Schaltung simulieren. Da ist die CPU der Bremsklotz, 
und nicht IO.

Async/Await ist sehr leichtgewichtig, da eben keine mehrfachen Stacks 
vorhanden sind oder Daten zwischen CPU-Kernen hin- und her- kopiert 
werden müssen inkl. Cache-Pollution etc.

Natürlich sind die meisten Programme selten rein IO-Bounded. So müssen 
die Daten die ausgegeben oder empfangen werden, irgendwie generiert oder 
verarbeitet werden, also CPU-Ressourcen sind notwendig.

Und hier kommt eben das Memory-Modell von Rust zur Hilfe, das es eben 
ermöglicht, die CPU-Anteile doch auf Threads und somit CPU-Cores zu 
verteilen. Aber wie gesagt, das ist eine Extra-Spezialität von der Du 
aus Sicht des Programmiermodels nichts mitbekommst.

> oder ist meine
> Threadingdenke zu antiquiert/eingefahren nach den vielen Jahren?

Die meiste "Parallelisierung" in den meisten Programmen ist nicht 
CPU-bounded, sonder IO-bounded. Klassiker: Download von Dateien aus dem 
Internet. Dazu benötigt es keine Threads, das ist reine 
Ressourcenverschwendung und birgt in fast allen Programmiersprachen auch 
noch große Gefahren für Programmierfehler.

Jörg W. schrieb:
> Programmierer schrieb:
>> Threads wiederum sind für CPU-Bound-Fälle ideal.
>
> Das würde ich überhaupt nicht so sehen. Das ist Parallelisierung, am
> besten über mehrere CPUs. Threads waren und sind ganz viel benutzt
> worden, um das Handling der IOs zu vereinfachen: ich habe einen Thread,
> der auf der seriellen Schnittstelle wartet, bis was reinkommt, einen,
> der die GUI bedient und wartet, bis dort irgendein Event angekleckert
> kommt, etc. pp.
>
> OK, stimmt schon, dafür muss man eigentlich nicht unbedingt einen
> kompletten Thread aufmachen mit eigenem Stack, weil während der
> IO-Wartezeit ja sowieso nichts auf diesem passieren würde. Lässt sich ja
> auch ganz klassisch komplett ohne Threads handhaben (siehe select()),
> ist dann eben nur im Code unhandlicher.

die meisten Betriebssysteme können ja recht viele Operationen auch 
asynchron, aber die Schicht die darüber liegt ist dann oft leider wieder 
synchron und dann braucht man extra einen Thread damit man das 
unblockierend laufen lassen kann - also sind Threads manchmal wirklich 
nur eine selbstgemachte (weil asynchron-Features ignoriend) oder 
Framework-arbeitet-leider-nur-synchron Notwendigkeit, wie viel Potential 
da schon verblasen wird

Bernd W. schrieb:
> Darum sollte man versuchen Komplexität, wenn sie nicht unbedingt
> erforderlich ist, zu meiden.

Komplexität ist ein Biest:

1

Person + Wissensstand + Erfahrung + aktueller Fokus => Komplexitätsgefühl

da die vier Faktoren so unglaublich Variant sind ist Komplexität eher so 
als Random-Value zu sehen - die sich in jedem Kopf, zu jeder Zeit völlig 
anders darstellt und deswegen auch Programmiersprache-Diskussionen so 
ungelaublich schwer sind

Was für den einen komplex ist kann trotzdem die besser Lösung sein weil 
er einfach den Themenkomplex nicht überblickt - immer die grosse Gefahr

viele stapeln gerne klein - nicht weil das so richtig ist sondern weil 
sie gar nicht anders können - rein kognitiv - das macht technische 
Kommunikation oft sehr schwierig - wenn man nicht nurn bissle SQL und 
GUIs macht (da ist es oft einfach nicht so relevant)

cppbert schrieb:
> und welche Gemeinsamkeit haben Zeiger und goto?

Nicht unbedingt für JavaScript-Gurus verständlich.

Das einzige, was mich an async in den meisten Sprachen stört, ist, dass 
man async Funktionen explizit als solche markieren muss. Das erschwert 
es dann, sync und async effektiv zu kombinieren. Dann muss man sehen, 
macht man alle Funktionen async, die eine Funktion mit io beinhalten 
könnte, dass man mit einem await später auf sie warten kann, oder wartet 
man halt synchron auf das io, oder splittet man es anderweitig weiter 
auf und speichert die Futures in irgend einer Queue oder so.

Wenn man einfach sagen könnte, mach das zeug jetzt Asynchron, ohne alle 
Funktionen dazwischen async zu machen, das wäre cool...

Ich glaube zig macht das anders / so ähnlich, muss ich mir nochmal 
ansehen. Wobei, vermutlich ist deren Method auch nicht wirklich besser / 
hat auch Problemchen.

cppbert schrieb:
> viele stapeln gerne klein - nicht weil das so richtig ist sondern weil
> sie gar nicht anders können - rein kognitiv

Nein, die haben einfach mehr Erfahrung. Wenn ein Programm, in seiner 
Gesamtheit, nicht einfach verständlich ist, ist es nicht gut wartbar. 
Viele vergessen ihre geniale Lösung auch selbst gerne. Nö, gute 
Programme sind nie Komplex, gute Programme sind simpel. Und man muss 
kein Genie sein, um komplexen Mist zu verzapfen. Wirkliche Erfahrung, 
wahres Können, braucht man, um auf die einfachen Lösungen zu kommen. 
Meistens sind das auch die besten.

rbx schrieb:
> cppbert schrieb:
>> und welche Gemeinsamkeit haben Zeiger und goto?
>
> Nicht unbedingt für JavaScript-Gurus verständlich.

für niemanden verständlich was du damit sagen wolltest
den Rest der Fragen einfach mal ignoriert?

DPA schrieb:
> cppbert schrieb:
>> viele stapeln gerne klein - nicht weil das so richtig ist sondern weil
>> sie gar nicht anders können - rein kognitiv
>
> Nein, die haben einfach mehr Erfahrung. Wenn ein Programm, in seiner
> Gesamtheit, nicht einfach verständlich ist, ist es nicht gut wartbar.

selbst gute wartbarkeite ist Ansichtssache - es gibt sogar Leute die 
viele Funktionen vermeiden weil sie die Zerlegung von Algorithmen als zu 
kompliziert empfinden

> Viele vergessen ihre geniale Lösung auch selbst gerne. Nö, gute
> Programme sind nie Komplex, gute Programme sind simpel. Und man muss
> kein Genie sein, um komplexen Mist zu verzapfen. Wirkliche Erfahrung,
> wahres Können, braucht man, um auf die einfachen Lösungen zu kommen.
> Meistens sind das auch die besten.

100% ACK - aber ob man das wirklich gut kann merkt man erst wenn man mal 
mehrfach verantworlich war ein paar 100k Zeilen Code zu erschaffen und 
wartbar zu halten - zusammen mit x Entwicklern - alles andere bleibt 
irgendwie einfach, lokal, der eigene Mist

oder wir reden eben von lokaler Algorithmik - die ist ist wenigstens 
ungefährlich weil von ihrer Art her einfach gut zu entkoppeln, auch wenn 
der 1., 2. und dritte Versuch Müll war kann man das gut und schnell 
bereinigen, architektonische Fehler, Designschwächen die 
Skalierungsprobleme verursachen sind viel schlimmer zu beheben, aber das 
machen eh nur die wenigsten

und dann noch die vielen Entwickler die es nicht mal gebacken bekommen 
wengstens die rudimentärste Entkopplung ihres Code zu schaffen um 
Unit-testbar zu sein(oder zu bleiben) und wenn sie von Design sprechen 
vornehmlich die Anordnung von if und else meinen :)

DPA schrieb:
> Wenn man einfach sagen könnte, mach das zeug jetzt Asynchron, ohne alle
> Funktionen dazwischen async zu machen, das wäre cool...

Ich wüsste nicht, wie das gehen soll.
Wenn Unterfunktionen asynchron sind, dann werden die aufrufenden 
Funktionen natürlich auch automatisch asynchron. Und deshalb muss man 
sie dann als solche markieren. Denn sonst wäre bei deren Aufruf nicht 
klar, ob man sie synchron oder asynchron aufrufen muss.

MaWin schrieb:
> Ich wüsste nicht, wie das gehen soll.
> Wenn Unterfunktionen asynchron sind, dann werden die aufrufenden
> Funktionen natürlich auch automatisch asynchron.

Allgemein gesprochen, unabhängig von realen Programmiersprachen, stimmt 
das so nicht ganz.

Die Async-Markierung bedeutet nur, dass die Funktion das Ergebnis nicht 
direkt zurück liefert, sondern (im Idealfall) sofort zurückkehrt und ein 
Future-Objekt, Promise, Task o.ä. zurück liefert.

Die Programmiersprache bietet mit einer Async-Markierung natürlich noch 
zusätzlich irgendwelche Unterstützung, so dass man bestimmte Dinge nicht 
von Hand machen muss, und schränkt evtl. bestimmte Verwendung der 
Asnyc-Funktion ein.

Aber rein prinzipiell könnte synchroner Code ein Future-Objekt pollen, 
und das Future-Objekt würde dann irgendwann sagen, dass das Ergebnis 
vorhanden ist. Dann könnte der synchrone Code das Ergebnis vom 
Future-Objekt abholen.

Allerdings ist mir auf die Schnelle keine Programmiersprache bekannt, wo 
das so möglich ist. Das Problem dabei wäre nämlich, dass Async-Code 
natürlich normale Funktionen aufrufen könnte, der intern ein Polling von 
Async-Code macht, der wiederum normalen Code aufruft, der intern ein 
Polling von Async-Code macht, der wiederum....

Es ist klar, auf was das heraus laufen würde, oder?

Programmierer schrieb:
> Aber rein prinzipiell könnte synchroner Code ein Future-Objekt pollen,
> und das Future-Objekt würde dann irgendwann sagen, dass das Ergebnis
> vorhanden ist. Dann könnte der synchrone Code das Ergebnis vom
> Future-Objekt abholen.
>
> Allerdings ist mir auf die Schnelle keine Programmiersprache bekannt, wo
> das so möglich ist.

Das ist in Rust natürlich möglich.
Man kann zum Beispiel mit cassette (https://crates.io/crates/cassette), 
einer minimalen async-Runtime, ohne Weiteres ein Future pollen. Das geht 
natürlich auch mit vielen anderen Runtimes, oder man kann es auch selbst 
implementieren.

Aber so hatte ich die Anforderung von DPA nicht verstanden.
Ich hatte es eher so verstanden, dass man normale Funktionen und async 
wild mischt und die Sprache das dann irgendwie auf magische Weise 
"richtig" machen soll. Das würde natürlich dazu führen, dass die Sprache 
selbstständig im Hintergrund async-Eventloops aufziehen muss. Niemand 
würde mehr durchblicken. Ich hätte vielleicht schreiben sollen: Ich 
wüsste nicht, wie das sinnvoll gehen soll.

> Es ist klar, auf was das heraus laufen würde, oder?

Eben. :)
Ich wüsste nicht, wie das sinnvoll automatisch von der Sprache aus gehen 
soll.
Zu Fuß implementieren kann man diesen Fall aber.

MaWin schrieb:
> Zu Fuß implementieren kann man diesen Fall aber.

Überhaupt kommt man nicht umhin, selber Gehirnschmalz einzusetzen, und 
das nicht zu knapp. Das bringt die Parallel-Programmierung so mit sich.
Hier und da kommt man in Bereiche, wo man meint, nö, ich habe echt 
keinen Bock mehr mich länger geistig so anzustrengen - man muss halt 
auch lange nachdenken, und hat dann diesbezüglich Ausdauerprobleme.
Da freut man sich dann auch über gewisse, schon ganz gut ausgetretende 
Pfade.

Manchmal ist es aber auch so, da kann man nach Workflows Ausschau halten 
oder nach einfachen Rezepten. Ich finde das Kochbuch von Rust gar nicht 
so schlecht. Ich erinnere mich an die JavaScript Tutorials von Netscape. 
Die waren auch echt nicht schlecht.
Ähnlich gut erscheint Rust

Eine wenig fühle ich mich bei der Diskussion auch an die Haskell Monaden 
erinnert. Man könnte ja meinen, man muss erst ein Mathestudium 
abschließen, um Monaden sinnvoll verarbeiten zu können.
Auswendiglernen der wichtigsten Handgriffe geht aber auch. Man muss halt 
nicht überall mitreden können.

Auf Stackoverflow gab es eine nette Linkempfehlung zu Rust Async:

https://ryhl.io/blog/async-what-is-blocking/

Für Komplexität gibt es zumindest noch eine bewährte Alternative zum 
Liegenlassen: schrittweise herangehen.

XY M. schrieb:
> Ach herrje... was nicht passt wird passend gemacht?
> Kritik unerwünscht!

Naja, 9 gelöschte Post sind auch hier jetzt nicht Standard, wohl ein 
wenig in der Wortwahl vergriffen derjenige

Version 1.63.0 ist raus:

https://blog.rust-lang.org/2022/08/11/Rust-1.63.0.html

- std::thread::scope: Sehr nützlich. Das vereinfacht die Threading-API 
noch einmal mehr, weil das join-handling automatisiert wird. Und es 
ermöglicht dem Compiler übergebene Referenzen statisch zu prüfen. Es gab 
schon crates, die das ermöglicht haben, aber nun ist es in der std-lib 
drin.

- const Mutex init: Auch eine gute Vereinfachung der Mutex-API. Macht 
das externe crate lazy_static in vielen Fällen unnötig.

Beide Änderungen führen zum Wegfall von diversen Runtime-Checks und 
erhöhen damit (minimal) die Performance.

Rust gibt's auch zum Frühstück!

Programmierer schrieb:
> Die allermeisten Menschen möchte einfache, simple Erklärungen wie die
> Welt funktioniert. Dann haben sie das Gefühl sie verstünden die Welt und
> könnten sich ein Urteil bilden, eine Meinung haben und mitdiskutieren.

Das hieße dann im Umkehrschluss, wer die Welt nicht in all ihrer 
Komplexität versteht sollte keine Meinung über sie haben und sich das 
mitdiskutieren ersparen. Dann sollte die Menschheit aber kollektiv das 
Schweigen lernen, denn KEINER aber absolut KEINER ist allein im Stande 
die Welt gänzlich zu verstehen, ob beim Klimawandel, bei der Verteilung 
von Reichtum und Armut oder den großen Fragen der Zukunft, wie die 
Menschheit künftig ihr Dasein gestalten soll, ohne dass es für ganze 
Landstriche ins Desaster führt (bzgl. Lebensqualität, Ressourcen, 
Bildungschancen etc.).

> Komplexität schreckt die meisten Menschen ab.

Die meisten Menschen brauchen die Komplexität vieler Hintergründe auch 
gar nicht en Detail zu verstehen, um damit umgehen zu können. Du musst 
nicht verstehen wie ein Otto-Motor genau funktioniert, um Auto fahren zu 
können. Du musst (um beim Thema anzuknüpfen) auch nicht genau verstehen 
wie ein Compiler funktioniert, um ein lauffähiges Programm zu schreiben. 
Es genügt zu wissen, wie man einen übersetzbaren Quelltext schreibt und 
wie man daraus ein startbares Programm übersetzt. Dazu gibt es Tools.

> Darum wird Komplexität
> verleugnet. Endstadium: Verschwörungstheorie.

Das ist eine andere Schiene. Verschwörungstheorien bilden sich dort wo 
Menschen das Vertrauen in ihre (hoffentlich) demokratischen 
Institutionen verloren haben. Ich würde nicht pauschal unterstellen, 
dass dort immer alle unterkomplex denken (für einige mag das zutreffen, 
aber nicht für alle). Bei vielen ist es einfach die Angst vor zu starker 
Veränderung, die die Leute umtreibt, gepaart mit dem Unvermögen der uns 
regierenden die "Komplexität" auf verstehbare, vermittelbare Sätze 
herunterzubrechen, anstatt zu schweigen oder den Leuten das Gefühl zu 
vermitteln selber die Dinge nicht richtig zu verstehen und daraus 
fragwürdige Handlungen abzuleiten.

Aber wie gesagt, das ist eine andere Schiene (politisch) und gehört 
nicht in diesen Thread.

Ich hab mal gerade in ein Tutorial von Rust reingeschaut. Bis hierhin 
war's zumindest unterhaltsam ;).

https://www.youtube.com/watch?v=xYgfW8cIbMA

Next steps for Rust in the kernel
https://lwn.net/Articles/908347/

Der Artikel ist leider noch sobscriber-only. Solange zitiere ich einmal 
hier den Kern:

> At the 2022 Linux Kernel Maintainers Summit, Miguel Ojeda updated the group on 
the status of the project with the goal of reaching a conclusion on when this 
merge might happen. The answer that came back was clear enough: Rust in the kernel 
will be happening soon indeed.
> There was little suspense on that front; Linus Torvalds spoke up at the 
beginning of the session to say that he plans to accept the Rust patches for the 
6.1 kernel (likely to be released in mid-December) unless he hears strong 
objections.

>  There is currently an ongoing effort to write a specification for Rust for 
safety-critical systems that will lead to a standard-like document. At the moment, 
though, Ojeda said, the developers of the GCC-based gccrs Rust compiler are 
finding the current documentation to be vague at times. Often, behavior is 
specified as "whatever the rustc compiler does". That is "not good", he said, but 
there is a path forward.

>  It has often been said that the merging of Rust into the kernel tree will be 
done on an experimental basis; if it doesn't work out, it can be removed again.

> Torvalds added that Rust isn't that terrible in the end; "it's not Perl".

Ich hoffe die bekommen das "Pinning" Problem gut gelöst - oder ist das 
schon (sauber) vom Tisch?

https://news.ycombinator.com/item?id=32864598
https://lwn.net/SubscriberLink/907876/ac0afc756df0ec71/

Ich finde es sehr gut das Rust jetzt vielleicht (zu)schnell in den 
Kernel kommt weil dann ein grosser Zwang besteht bestehende 
Probleme/Schwächen im Grossen Kreis zu klären

mehr Szenarien = mehr Möglichkeit an Schwächen zu arbeiten

cppbert schrieb:
> Ich hoffe die bekommen das "Pinning" Problem gut gelöst - oder ist
> das
> schon (sauber) vom Tisch?

Gelöst ist das nicht.
Aber es bedeutet lediglich, dass es derzeit ein paar mehr unsafe-Blöcke 
an den Schnittstellen zur C-Welt gibt. Oder an den wenigen Stellen, wo 
ein memcpy nicht wegoptimiert werden kann und dieses memcpy zu viele 
Schmerzen bereitet.

Das Problem ist auch nicht, dass das im Einzelfall nicht immer lösbar 
wäre. Aber es gibt derzeit nicht eine wirklich saubere Universallösung 
für alle Fälle.
(Wobei ich diese Procmakro-Lösung eigentlich gar nicht so schlecht 
finde. Da gibt es im Rust-Universum deutlich hässlichere Procmakros.)

Volvo bringt Rust in die Auto-Software

Das Rust-Team bei Volvo will die Nutzung der Sprache in der 
Auto-Software deutlich ausweiten. Bis hin zu sicherheitskritischen 
Anwendungen.

https://www.golem.de/news/programmierung-volvo-bringt-rust-in-die-auto-software-2209-168520.html

Auch wenn die Diskussionen mit Linus wie üblich etwas harsch wirken 
finde ich es super das sich die Rust Leute (der kleine Teil der 
Community der sich damit bisher beschäftigt) jetzt den Anforderungen 
eines Mainstream Kernels aussetzen

https://lkml.org/lkml/2022/9/19/1250

Egal wie die Integration verläuft sind das alles wichtige Impulse für 
die Sprachentwicklung

Muss man dann eigentlich Rust zum Kompilieren des Kernels haben, oder 
kann man all das Rust Zeugs auch in der config abwählen?

🐧 DPA 🐧 schrieb:
> Muss man dann eigentlich Rust zum Kompilieren des Kernels haben,
> oder
> kann man all das Rust Zeugs auch in der config abwählen?

ich denke nicht das die Kernel-Entwickler Rust gleich für alle 
Entwickler Zwangsausrollen werden, es wird bestimt modulorientiert sein 
- sonst das wäre ja totales Chaos bei >3000 aktiven Entwicklern

Nun ist es soweit. Die Rusthasser müssen sich nach einem alternativen 
Betriebssystem umsehen.

https://lwn.net/Articles/910762/

There have been a lot of significant changes merged into the mainline 
for the 6.1 release, but one of the changes that has received the most 
attention will also have the least short-term effect for users of the 
kernel: the introduction of support for the Rust programming language. 
No system with a production 6.1 kernel will be running any Rust code, 
but this change does give kernel developers a chance to play with the 
language in the kernel context and get a sense for how Rust development 
feels. Perhaps the most likely conclusion for most developers, though, 
will be that there isn't yet enough Rust in the kernel to do much of 
anything interesting.

Am Anfang stehen und schon Feiern? Schauen wir mal, was aus Linux in ein 
paar Jahren geworden ist. Ob Rust dann immer noch drin ist, ob Linux 
noch lebt, etc. Da kann viel passieren.

🐧 DPA 🐧 schrieb:
> ob Linux noch lebt, etc. Da kann viel passieren.

Dein Getrolle war auch schon einmal besser. Gib dir bitte wieder mehr 
Mühe!

🐧 DPA 🐧 schrieb:
> Am Anfang stehen und schon Feiern? Schauen wir mal, was aus Linux
> in ein
> paar Jahren geworden ist. Ob Rust dann immer noch drin ist, ob Linux
> noch lebt, etc. Da kann viel passieren.

genau das ist doch das Ziel und auch die Strategie - einfach 
ausprobieren, wenn es nix ist kommt Rust ganz schnell wieder raus, was 
aber trotzdem kein scheitern der ganzen Sprache bedeutet, es hat ja auch 
keine anderen Sprache bisher im Kernel einzug gehalten

und sollte Rust dem Kernel erhalten bleiben und die Modul-Anzahl wachsen 
wird es immer noch genau so viele Leute im Internet geben die das alles 
nicht gut finden, selbst wenn alle Top-Kernel Entwickler sagen das ist 
die geilste Scheisse ever, hat das auch keine Relevanz - also schauen 
wir einfach ob es was wird und Rust an der Kernel-Herausforderung wächst 
oder scheitert

Hier der Teil der Key-Note mit Linus wo er über die Rust Integration 
spricht:

https://www.youtube.com/watch?v=sLimmpZWRNI&t=1144s

nicht ganz super ernsthaft aber pragmatisch - es wird auch
kurz über die clang/LLVM abhängigkeit gesprochen, 1min nach Start

und über die Ängste die mit der Einführung einer neuen Sprache 
einhergehen und auch das wenn es schief geht das es eben schamvoll 
entfernt werden wird...

aber ich hab wirklich selten Linus so euphorisch(für seine Verhältnisse) 
über eine Programmiersprache sprechen hören - er freut sich darauf die 
Rust-Syntax zu lernen

Es wird die härteste und beste Herausforderung für Rust - wir werden 
sehen wie es sich schlägt und die harsch Linus damit umgehen wird

S. R. schrieb:
> Ich würde ja eher sagen: Schauen wir mal, wieviel Rust in ein paar
> Jahren real im Kernel drin ist. Wenn sich das auf ein paar Treiber
> weniger Firmen beschränkt, dann war's viel Hype um nichts.

Man könnte schon fast eine Vorhersage versuchen.

Basierend auf:

Berichte über Parallelitätsexpertise in den 50er und 60er Jahren:(sehr 
interessant)
"Funktionale Sprachen sind auch ein guter Ansatz" (aber nicht der 
bestimmende)

Haskell Hyperei (was war da eigentlich los (so zwischen 2008 und 2012)?)

C++ PDF zur Frage: C++ vs Haskell.

Die Antwort war:

wegen dem schwierigen Haskell Code lieber in C++ was machen.
Aber der Haskell Code in dem Pdf war eher plakativ ausgesucht.
Der Haskell-Code war nicht unbedingt schwierig, aber der sah stark 
danach aus, als wäre der das. Also eher kognitive Dissonanz 
(Ent-)Berieselung dabei.

Dann noch:
Frederik Vester (Lerntypen in "Denken, Lernen, Vergessen) und Israel 
Rosenfield ("Das Fremde, das Vertraute und das Vergessene")
Der Text von dem Rosenfield ist extrem erhellend - nicht unbedingt hier 
zum Thema, aber zu Bewusstseinsfragen und Integration an sich.
Dann noch ein wenig Chaosforschung.

Aus diesen zusammengefasst:

 Immer vom Vertrauten zum Unvertrauten. Nicht umgekehrt. Verhältnis 
empfindlich. Nicht zuviel neues aufeinmal.
BWL-Grundkurs geht auch noch: welche Alternativkosten?

Die Programmierung mit "funktionalen Sprachen" ist sehr abstrakt, und 
deswegen braucht man länger als für C und für C wurden früher 5-10 Jahre 
angesetzt. Das ist heute bestimmt anders, aber C hat Abstaktionen, die 
muss man auch erstmal verarbeiten - das dauert erstmal - und funktionale 
Sprachen dauern da noch viel länger - ganz abgesehen von dem (oft 
fehlenden) Drumherum in Richtung der Hardwareschnittstelle.

Wir haben dann:
- funktionale Programmiersprache, nicht sonderlich gut bekannt.
- recht anspruchsvoller, hoher Abstraktionsgrad (man braucht lange), 
gute Matheausbildung sicher auch nicht verkehrt.

- (professionelle Bibliotheken?)
- Parallelprogrammierung mit vielen Kernen: Schwierig.
- Plotten geht mit (Hilfe von) Octave viel besser.
- Pycuda-Math

Nun ist aber Parallelprogrammierhilfe schon dringender nötig als früher. 
Und C++ ist auch ein ganz schön dicker Brocken geworden.
Der gcc auch, und der raubt mir mit seinen Fehlermeldungen den letzten 
Nerv.

Gute Zeiten für Python?

Ich weiß gar nicht mehr, wann das war - als bei Cygwin ein Python-Packet 
mit dabei war.
Es war aber ein "Issue" ob mit dabei oder nicht. Ist noch nicht so lange 
her, vielleicht 8-10 Jahre.

Der Python-Einstieg ist mittlerweile ganz einfach in Linux, weil schon 
vorinstalliert - bzw. so ein wenig auf Basic-Spuren herumläuft.

Über den Status "eine gute Idee" (wie in den 60ern) ist Rust sicher 
hinausgekommen. Aber wie weit?

Linus hypt auch nur in dem Video oben.
Allerdings ist der auch nicht irgendwer ;)

rbx schrieb:
> - Parallelprogrammierung mit vielen Kernen: Schwierig.

Falsch.
In Rust sehr einfach.

Superpower von rbx? Haskell Bezüge in fast jedem Post :)

MaWin schrieb:
> rbx schrieb:
>> - Parallelprogrammierung mit vielen Kernen: Schwierig.
>
> Falsch.
> In Rust sehr einfach.

Danke für die "Optimierung"
Ich hatte noch im Hinterkopf: Wenn man das alles in Assembler machen 
müsste bei den Cells (Playstation usw) geht das ja noch - aber bei 100 
Threads? Da kann man dann eben schon für solche Entwicklungen wie Rust 
dankbar sein.

rbx schrieb:
> Danke für die "Optimierung"
> Ich hatte noch im Hinterkopf: Wenn man das alles in Assembler machen
> müsste bei den Cells (Playstation usw) geht das ja noch - aber bei 100
> Threads? Da kann man dann eben schon für solche Entwicklungen wie Rust
> dankbar sein.

sorry rbx - aber, wie so oft habe ich keine Ahnung was du vermitteln 
willst

was hat denn der 2006 Playstation3 Cell Chip hier für einen relevanz?

In C/C++ mit >100 Threads rumspielen war schon vor >15 Jahren, auch 
unter Windows völlig "normal" und Rust hat nur die Sicherheit deren 
Nutzung erhöht
ansonsten ist Multithreading definitiv schon lange nichts besonderes 
mehr

cppbert schrieb:
> was hat denn der 2006 Playstation3 Cell Chip hier für einen relevanz?

der wurde nicht per se mit Assembler programmiert sondern eher in C++ 
(mit Extensions)

https://www.codeproject.com/Articles/23733/Parallel-programming-on-PlayStation-3-Cell-archite

cppbert schrieb:
> In C/C++ mit >100 Threads rumspielen war schon vor >15 Jahren, auch
> unter Windows völlig "normal" und Rust hat nur die Sicherheit deren
> Nutzung erhöht

ich hab 2001 an einem System mit einer schlechten Architektur gearbeitet 
das
bei einem Volllauf Geräte in einer Chemie-Automation mit C++ gesteuert 
hat, Window 2000, Visual C++ 6, >400 Threads - weil jedes Gerät seinen 
eigenen Thread-Message-Queue hatte, war ineffizient aber damals auch 
kein Hexenwerk

oder meinst du Auto-Vektorisierung/Parallelisierung und solche Sachen? 
dann musst du das aber auch deutlich sagen - alles andere ist sonst nur 
Buzzword-Geplapper

cppbert schrieb:
> war ineffizient aber damals auch
> kein Hexenwerk

In dem c't - Jubiläumsheft 24/2008 gab es den Artikel "Playstation 
unportable".

https://www.heise.de/select/ct/archiv/2008/24/seite-276

Das Ergebnis der Programmierübungen auf dem Schrankteil war, dass 
Assemblerprogrammierung (auf dieser Kiste) deutlich effizienter ist - 
und möglichst vorzuziehen.

https://de.wikipedia.org/wiki/IBM_Roadrunner
(Ob Assemblerprogrammierung hier eine Rolle spielt, weiß ich nicht - 
aber es hilft vielleicht, das Argument oben etwas einfacher 
einzusortieren.)

Wird Rust besser, wenn die Sprache im Linuxkernel benutzt wird? Mehr 
akzeptiert und mehr verbreitet - ja, aber mit Sicherheit nicht besser.

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)

ein lupenreiner Demokrat schrieb:
> Wird Rust besser, wenn die Sprache im Linuxkernel benutzt wird? Mehr
> akzeptiert und mehr verbreitet - ja, aber mit Sicherheit nicht besser.

Selbstverständlich wird Rust dadurch besser, indem Features stabilisiert 
werden und neue für die OS-Entwicklung zwingend notwendige Features 
hinzugefügt werden. Es gibt auch eine Trackingliste für dies, falls es 
dich interessiert.

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.

Wie wäre es denn, wenn ihr Argumente vorbringt, statt beleidigt zu sein 
und alles als Blödsinn zu bezeichnen?
Ich weiß, das ist unüblich hier im Forum.

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.

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 und irgendwie 
memcpy besser als memmove findest. Das ist für mich eine nutzlose 
Information, solange du das nicht begründest.

Verstehst du jetzt das Problem?

Naja, memmove hat doch auch seine Grenzen, wo heutzutage ein Buffer ja 
mehrfach gemappt sein kann. Mappe ich die selbe Page auf 1000 und 2000, 
und mache dann z.B. ein memmove von 20 bytes von 2000 nach 1010, müsste 
man das wie ein memmove von 1000 nach 1010 behandeln, aber memmove wird 
nichts von dem Mapping wissen, und 1000 < 1010 aber 2000 > 1010, und 
peng.

Ich könnte mir gut vorstellen, das man da in einem Kernel mehr aufpassen 
muss, und memmove dann eher dazu führen könnte, das man sich in falscher 
Sicherheit wiegt, wenn man eigentlich hätte checken müssen, was da 
physisch gemappt war.
Ist aber nur reine Spekulation.

Jörg W. schrieb:
> Warum memcpy() und memmove() zwei getrennte Funktionen sind, sollte
> eigentlich sonnenklar sein: wenn der Programmierer bereits weiß, dass es
> keine Überlappung geben kann, kann man sich die Umständlichkeit eines
> memmove() schlicht sparen. Und in sehr, sehr vielen Fällen weiß er das.

das weiß hier jeder, auch MaWin

aber warum Linus dann memmove semantic in memcpy fordert ist komisch 
weil nicht so optimierbar/schnell ist - einfach nur weil damit mehr 
Probleme per se kompensiert werden?

Jörg W. schrieb:
> Warum memcpy() und memmove() zwei getrennte Funktionen sind, sollte
> eigentlich sonnenklar sein: wenn der Programmierer bereits weiß, dass es
> keine Überlappung geben kann, kann man sich die Umständlichkeit eines
> memmove() schlicht sparen. Und in sehr, sehr vielen Fällen weiß er das.

Ich weiß was memcpy und memmove sind.
Darum ging es nicht. Lies bitte worauf du antwortest auch einmal durch.

> Außerdem ist der C-Standard eh sehr, sehr zurückhaltend mit dem
> Entfernen alter Funktionen, daran wird auch ein Herr Torvalds nichts
> ändern.

Ehm. doch.
Der Kernel verwendet überhaupt keine stdlib.

Ich kann ja mal ein Argument liefern:

Die Diskussion memcpy vs. memmove ist ein Argument für Rust.
Denn in Rust können Speicherbereiche niemals überlappen und gleichzeitig 
drauf zugegriffen werden.
Deshalb kann der Compiler alles mit memcpy kopieren. Der Programmierer 
braucht sich darüber gar keine Gedanken zu machen.

Jörg W. schrieb:
> Yup … daran wird vermutlich auch Rust nicht viel ändern können.

Da liegst du leider komplett falsch mit deiner Vermutung.
Mehrfaches Mapping und gleichzeitiger Zugriff ist nicht möglich in Rust.
Aliasing ist auch nicht möglich in Rust.

Rust forciert, dass die Teilnehmer sich synchronisieren. Also das, was 
man in C auch machen muss um ein korrektes Programm zu bekommen.

Ich würde vorschlagen, dass du vielleicht erst einmal die Grundlagen von 
Rust lernst. Das macht auch ziemlich viel Spaß.

Jörg W. schrieb:
> Dementsprechend kann
> man, wenn man an der Stelle nicht sauber drauf achtet, sowohl die
> Eigentümerschafts-Annahmen von Rust gefährden

Im Rust Code muss man auf überhaupt nicht darauf achten.

Dass man das System außerhalb von Rust so einstellen und betreiben muss, 
dass die Anforderungen von Rust eingehalten werden, sollte 
selbstverständlich sein.
Das gilt auch für C. Wenn die Hardware sich nicht ans Maschinenmodell 
der jeweiligen Sprache hält, dann ist das natürlich ein Bug.

Fakt ist und bleibt, dass die Überlegung memcpy vs. memmove in Rust 
nicht existiert.

Aber ich weiß jetzt nicht, worauf du hinaus willst.
Zur Erinnerung: Es ging hier nicht um die Technik hinter memcpy/memmove, 
sondern um die politischen Entscheidungen von Linus. Es wurde 
kritisiert, dass Linus angeblich memmove statt memcpy generell bevorzugt 
und die Forumsteilnehmer hier das für Blödsinn halten. Eine Begründung 
gab es leider nicht.

Cyblord -. schrieb:
> Außerhalb einer sehr überschaubaren Nerd-Blase, juckt es doch wirklich
> niemanden was Linus zum Thema C sagt oder meint.

Wieder ein Beitrag ohne Inhalt und Argument.

Jörg W. schrieb:
> Genauer gesagt: Begründungen interessieren dich nicht.

Bitte was?
Herr Moderator, warum greifen sie mich nun persönlich an?

Wo soll diese Begründung denn gewesen sein? Zitat bitte!

Der Kernel managt auch Userspace Ressourcen. Und Userspace kann nun mal 
Speicher mehrfach mappen. Vermutlich wird das kein all zu grosses 
Problem sein, aber in gewissen Situationen wird man da sicher auch in 
Rust die Checks nicht vergessen dürfen, die man momentan noch in C 
macht, oder anderweitig abstrahieren. Wobei man da bei der UAPI etwas 
eingeschränkt ist, die soll nämlich stabil bleiben. Kommt halt drauf an, 
wo und in wie weit es später eingesetzt werden wird, ob man sich da noch 
damit auseinander setzen wird.