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: > Mombert H. schrieb: >> numpy hat nicht viele Vorteile gegenüber Fortran > Der wesentliche Vorteil ist, dass man als Frontend zum alten > FORTRAN-Kram eine benutzbare Programmiersprache bekommt, die man auch im > 21. Jahrhundert einigermaßen verstehen kann. ;-) Ich bin mir nicht sicher, wie genau du das meinst. Aber: - Niemand der im Jahre 20XX "altes FORTRAN" schreibt, wechselt zu Python und schreibt dort Python. Das wird im besten Fall PYTRAN77. - Python hat genügend Fallstricke und unschöne Ecken. Da muss sich modernes Fortran nicht verstecken, wenn es ums numbercrunshen geht. - Wenn z.B. numpy nicht bietet was man braucht muss man am Ende trotzdem C oder Fortran einsetzen + den ganzen Interface-Hokuspokus (dazu aus der aktuellen numpy-Doku:
1 | The default build system for F2PY has traditionally been the through the enhanced numpy.distutils module. This module is based on distutils which will be removed in Python 3.12.0 in October 2023; setuptools does not have support for Fortran or F2PY and it is unclear if it will be supported in the future. Alternative methods are thus increasingly more important. |
- Ich stoppe besser hier, bevor ich stundenlang die Vor- und Nachteile von Python, Fotran und C++ beim Lösen von numerischen Problemen aufliste. MaWin bekommt bestimmt schon einen hochroten Kopf, weil ich bis jetzt kein rust erwähnt habe. > Ich denke, das ist genau der Punkt an dieser Stelle, und letztlich auch > der, womit Matlab gepunktet hat (zumindest im Ursprung, mittlerweile > eher mit Toolboxes für jede Lebenslage). Python hat viele Pluspunkte. Einer der wichtigsten Punkte ist, dass Fortran eine Sackgasse ist. Wenn man seinen Abschluss hat, kann man in 95% der Fälle sein Fortran-Wissen direkt vergessen, weil man es nie wieder benutzen wird. Es ist Fachwissen und kein Werkzeug.
MaWin 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 man große Datenmengen numerisch behandeln muss, kann es also sinnvoll sein, einen Python-Prototypen später in was anderem nachzuschreiben. Ich habe auch schon Python-Prototypen in C nachgeschrieben, für ARM-MCU, im Zusammenhang mit der ARM DSP Library. Insofern kann so eine Betrachtung nicht ganz unsinnig sein, die Portierung eines Prototypen von Python nach Rust zu machen. Die Typisierung musste ich übrigens auch in C abhandeln, nur "mit einem Pointer herum zu werfen" löst ja an sich erstmal noch kein Problem.
MaWin schrieb: > Einfach mal mit einem Pointer um sich werfen, > wie man es aus C++ kennt, kann man in Rust nicht. Und das ist gut so. Da sind wir wieder bei FORTRAN vs. Fortran, wenn das deine C++ Sicht ist ;-). MaWin schrieb: > 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. Gut, dass das nicht alle so sehen :-)
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.
MaWin schrieb: > Die Rust-Typisierung mit C-Typisierung zu vergleichen ist schon etwas > ulkig. Kann sein, aber möglicherweise kennst du auch bloß schlechtes C.
MaWin schrieb: > Das Rust Typsystem verhält sich zum C Typsystem wie ein Daimler zu einem > Tretroller. Also C ist ein Kinderspielzeug oder energiesparendes Kurzstreckenfahrzeug und rust eine Protzkarre?
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
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*™?
MaWin schrieb: > Das Typsystem der Sprache C ist überhaupt nicht direkt vergleichbar mit > Rust. Habe ich auch nicht behauptet. Aber C ist auch nicht bloß "mal einen Pointer herumwerfen", wie du das darstellst. Zumindest nicht, wenn man es ordentlich macht. Dass bei letzterem Rust einen deutlichen Vorteil hat (die Bedingung "wenn man es ordentlich macht" kann man dort nicht umgehen), ist unbestritten. Und klar, Python oder Matlab sind da pragmatischer, in der Beziehung halt wirklich eher wie BASIC.
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
Ich habe nur manchmal die Befürchtung, dass er von ein paar schlechten C-Programmierern auf die Qualität aller C-Programme schließt. Logischerweise hat natürlich Rust von Problemen existierender Sprachen gelernt, wofür sonst hätte es überhaupt einer neuen Programmiersprache bedurft?
:
Bearbeitet durch Moderator
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?
Jörg W. schrieb: > MaWin 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 man große > Datenmengen numerisch behandeln muss, kann es also sinnvoll sein, einen > Python-Prototypen später in was anderem nachzuschreiben. 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. 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.
:
Bearbeitet durch User
cppbert schrieb: > 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 500 kLOC Mathcode hören sich zunächst nach viel an, bis man feststellt, in welcher Sprache sie geschrieben sind... ;-) Nein, im Ernst: auch Python läßt sich in nativen Code kompilieren, vor allem Mathcode (think numba). Zudem gibt es andere Interpreter wie Pypy mit JIT-Compiler, die in vielen Anwendungsfällen viel schneller sind als die Referenzimplementierung.
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
cppbert schrieb: > 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 Für mich klingt das, hüstel, eher wie "ich habe eine Lösung und jetzt hätte ich bitte gerne ein Problem dafür".
Ein T. schrieb: > Für mich klingt das, hüstel, eher wie "ich habe eine Lösung und jetzt > hätte ich bitte gerne ein Problem dafür". Eine Parole die über vielen Innovationen und kreativen Einfällen moderner Sprachen stehen könnte.
Ron T. schrieb: > Ein T. schrieb: >> Für mich klingt das, hüstel, eher wie "ich habe eine Lösung und jetzt >> hätte ich bitte gerne ein Problem dafür". > > Eine Parole die über vielen Innovationen und kreativen Einfällen > moderner Sprachen stehen könnte. 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.
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.
cppbert3 schrieb: > 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, Aber ja doch, die Sprachen der PASCAL-Familie. Die haben zwar immer noch viele Freunde, aber durchgesetzt... eher nicht, oder? > 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 Systementwicklung als solche ist ja schon eine Nische, und... ich wünschte, es wäre anders, aber jede neue Sprache steht heute immer zunallererst vor dem Problem, daß es eine existierende Infrastruktur gibt. Ja, ich weiß, man kann C in Rust einbinden, verliert dann aber einige seiner wesentlichen Vorzüge. Und wer mal erlebt hat, wie vehement sich manche gestandene und erfahrene Entwickler dagegen sträuben, ihre lieb gewonnene Sprache und ihre Erfahrungen aufzugeben, mithin: wie sehr auch Entwickler Menschen und damit Gewohnheitstiere sind... Jo, die Aufnahme in den Linux-Kernel ist eine Art Ritterschlag, wenngleich sie bis dato noch ein Versuch ist und ähnlich fehlschlagen könnte wie weiland der Versuch, C++ in den Linux-Kernel zu integrieren. Insofern heißt es erstmal abwarten, ob das erfolgreich sein wird -- aber selbst wenn es erfolgreich ist, ist die Entwicklung von Kernelkomponenten für Linux ja auch immer noch ein Nischending.
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
Beitrag #7132840 wurde von einem Moderator gelöscht.
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?
Würde gern mal die Frage in den Raum stellen warum sich über das Thema so trefflich diskutieren lässt? Weil Programmiersprachen vielleicht doch sehr auf den individuellen Geschmack (und individuelle Problemlösungen) angewiesen sind? Warum sprießen immerfort neue Sprachpilze aus dem Boden? Ist das nicht Ausdruck ständiger Unzufriedenheit mit dem Vorhandenen? Ist das nicht Ausdruck der Unmöglichkeit einer "perfekten" Sprache?
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 :)
Ein T. schrieb: >> Es gibt gab noch nie einen so ernsthaften Versuch eine bessere >> alternative zu C oder C++ zu erschaffen, > > Aber ja doch, die Sprachen der PASCAL-Familie. Die sind eher zeitgleich entstanden, und zumindest von der Entstehung her hatten beide sehr unterschiedliche Prämissen: Niklaus Wirth wollte eine schöne Sprache für die Lehre erschaffen (das ist Pascal ganz zweifellos), Brian Kernighan und Dennis Ritchie wollten eine Sprache erschaffen, die das mühevolle Coden eines Betriebssystems in Assembler ablösen kann (auch das ist ihnen ganz offensichtlich gelungen). Insofern sind beide nebeneinander aufgewachsen, mit einer gewissen Konkurrenz, und Pascal hat viele Erweiterungen erfahren, aber C hatte natürlich im System-Umfeld die besseren Karten, die dann auch standardisiert worden sind. An Firefox sieht man aber, dass es noch ein langer Weg sein wird: obwohl er ja meines Wissens eine der treibenden Kräfte hinter Rust war (und ist), die Zahl der Speicherlecks und Sicherheitsprobleme ist immer noch recht erheblich. Aber was ich lesen konnte, sind es wohl auch erst 20 %, die in Rust geschrieben sind.
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: >> die Zahl der Speicherlecks und Sicherheitsprobleme ist immer noch >> recht erheblich. > > Wie sieht diese "Statistik" denn für die Rust-Komponenten aus? Keine Ahnung, ob es da eine gibt.
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 :) In einem Firefox sind sie aber eher unnötig. ;-)
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...
MaWin schrieb: > Trotzdem ist es extrem schwierig versehentlich in Rust Speicher zu > lecken. Was ich natürlich angesichts des sonstigen Fiaskos bei Firefox für ein mehr als wichtiges Feature halte. Meinen Computer kann ich mittlerweile wochen- und monatelang (und rein technisch gesehen sogar jahrelang) durchlaufen lassen, nur der Firefox braucht immer mal einen "Reboot".
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
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.
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.
Programmierer schrieb: > Komplexität schreckt die meisten Menschen ab. Darum wird Komplexität > verleugnet. Stop! So wollte ich nicht verstanden werden. Niemand leugnet daß Programmierung oft komplexe Probleme lösen muß und daher nicht immer einfach ist. Hier aber ging es um die Frage warum die Bewertung der einzelnen Sprache so endlos diskutierbar ist und warum da täglich neue entstehen (müssen). Außerdem: Die Programmierung der Sachlage angemessen möglichst einfach und die Werkzeuge dazu möglichst geeignet zu halten hat nichts mit Verleugnung sondern eher mit Vernunft zu tun. Mal umgekehrt die Frage: Zieht Komplexität vielleicht manche Menschen an und sie versuchen diese zu mehren? Computerprogrammierung scheint sich ja hierfür besonders anzubieten!
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?
cppbert schrieb: > Mombert H. schrieb: >> 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 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. Und natürlich ist dieses spezielle Problem in "Imperative (Statefull-Sprache)" lösbar. Ein garbage collector kann durchaus für alle Objekte prüfen, ob sie nur durch eine "Referenzschleife" am Leben erhalten werden. Wenn mit Referenzschleife etwas anderes gemeint ist, dann klärt mich auf. MaWin schrieb: > 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. Ich weiß nicht wie man das vergessen soll. Du musst ja aktiv etwas anderes machen als den Smart-Pointer zu benutzen. Das ist eine bewusste Entscheidung.
:
Bearbeitet durch User
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
cppbert schrieb: > 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 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? cppbert schrieb: > 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 Vielleicht weil sie in ihren C++-Regeln
1 | *Prefer* to have single, fixed owners for dynamically allocated objects. *Prefer* to transfer ownership with smart pointers. |
zu viele "prefer" haben?
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...
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
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. An dieser Stelle muss ich dich an einen deiner früheren Beiträge erinneren. MaWin schrieb: > Mombert, dir antworte ich übrigens nicht mehr, falls du es noch nicht > gemerkt hast. Hast du vergessen, dass du mir nicht mehr antwortest, oder hast du dich anders entschieden?
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
cppbert schrieb: > 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) 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. Es ist auch nicht so, als wäre es in C++ wirklich schwierig es richtig zu machen, wenn man es will.
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
cppbert schrieb: > das ist z.B. auch ein Grund warum sich C++ da so nicht durchsetzt Wobei man auf Exceptions ja durchaus auch verzichten kann, wenn das das einzige Problem wäre. Andererseits sind sie natürlich nett, wenn man sie hat, weil man sich dann so ein error code passing über 5 Etagen sparen kann.
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? Denn auch C braucht eine Runtime, wenn man die ganze Sprache nutzen will und man kommt in C++ ohne Exceptions aus, wenn man nicht die ganze Sprache nutzt. Und das gleiche gilt für rust, wie du selbst feststellst ("gut so lange man ..."). > 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: > Denn auch C braucht eine Runtime Wobei diese schon sehr minimalistisch ist: Ausnullen von .bss, Initialisieren von .data, Setzen des Stackpointers.
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.
Jörg W. schrieb: > Mombert H. schrieb: >> Denn auch C braucht eine Runtime > > Wobei diese schon sehr minimalistisch ist: Ausnullen von .bss, > Initialisieren von .data, Setzen des Stackpointers. Ich hätte jetzt noch die Buchführung für malloc und Co aufgelistet, aber das ist optional. cppbert schrieb: > 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? 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.
Mombert H. schrieb: > Ich hätte jetzt noch die Buchführung für malloc und Co aufgelistet, aber > das ist optional. Viele mögen es im (deeply) embedded nicht, wenngleich ich das nicht immer nachvollziehen kann. ;-) Ja, könnte man dazu zählen. > 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. Zumal der Compiler ja auch implizites Wissen darüber haben darf und beispielsweise ein "strlen("Hi")" direkt durch die Konstante 2 ersetzen darf.
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
cppbert schrieb: > Linux Kernel nutzt ja auch seine "eigene" Standard-Library Ist ja egal, das ist dann alles "the implementation". Wichtig ist ja nur, dass sie zumindest die Teile, die wirklich benutzt werden, dann auch so implementiert, wie es der Sprachstandard will. Also "strlen("Hi")" sollte in der geänderten Version nicht gerade 42 zurück geben. ;-)
cppbert schrieb: > 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) Die C-Runtime unabhängig vom Compiler zu ersetzen, dürfte ne interessante Aufgabe sein. Wie schafft man es z.B. eine stdarg.h oder float.h zu erstellen, ohne auf die Eigenheiten des Compilers einzugehen?
:
Bearbeitet durch User
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: > 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? Wäre jetzt auch meine Vermutung. Ich wüsste zumindest nicht, wie man für threading mehrere Stacks vermeiden will. In einem VM-System kann natürlich jeder seinen eigenen VM-Bereich bekommen, der sich dann auch automatisch vergrößern lässt, auf einem Controller wird man wohl oder übel vorab Stacks definieren müssen.
DPA schrieb: > Oder gibt es da 2 Stacks, auch in rust, und zero-cost heisst da nur > Bestmöglich, statt effektiv gratis? Ich wüsste nicht wie man alles auf einem Stack realisieren könnte. Dafür müsste jedes mal wenn der Stack manipuliert wird, ein riesen Aufwand getrieben werden. Oder der Stack, den jeder async sieht hat eine festgelegte maximale Größe, die beim Aufruf festgelegt wird.
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. >
Beitrag #7134604 wurde vom Autor gelöscht.
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.
rbx 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. Ich schrieb: Controller. Ein Rapsberry Pi ist kein Microcontroller mehr. Wenn ich da ein (komplettes, nicht irgendwie herunter getunetes) Linux oder BSD drauf laufen lassen kann (selbst Windows hatte sich ja dran versucht), dann ist das Ding in der Art und Weise, wie es programmiert wird, letztlich ein PC. Dass er noch ein paar GPIOs rausgeführt hat, ändert nichts grundsätzlich dran. 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.
DPA schrieb: > C - Kohlenstoff > > Unglaublich nützlich... Lustig, Google kam wohl mit einer ähnlichen Analogie auf: Carbon Language - An experimental successor to C++ https://github.com/carbon-language/carbon-lang
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
Hallo Programmierer. Programmierer schrieb: > Komplexität schreckt die meisten Menschen ab. Darum wird Komplexität > verleugnet. Endstadium: Verschwörungstheorie. Das ist richtig! Allerdings sollte man auch erwähnen, das Komplexität darum abschreckt, weil Komplexität die meisten Menschen überfordert. Darum sollte man versuchen Komplexität, wenn sie nicht unbedingt erforderlich ist, zu meiden. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
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: > 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. So hatte ich das eigentlich nicht im sinn. Ich dachte das eher so, dass async & await quasi der default sind, und man explizit angeben muss, wenn man das furture Objekt will. Das ist stärker als immer sofort das Future-Objekt zu pollen, den dann kann man später immernoch mehrere Funktionen parallelisieren. Irgendwo müsste man immernoch synchron warten, was aber kein problem sein sollte, man kann ja einfach in einer tread lokalen Variable oder so speichern, ob das gerade das "oberste" await ist, oder nicht. Das alles liese sich sicher auch abi-massig transparent gestalten, braucht vermutlich nur ein wrapper symbol und ein paar andere Tricksereien, nur kenne ich leider auch noch keinen Weg, das ohne coroutinen oder heap allocations, also Zusatzkosten, zu machen, denn dann müsste man das ja so lösen, dass man die Limitationen von rekursiven aufrufen usw. nicht hat. Also ich weiss nicht, ob es einen Weg gibt, das beste aller Welten zu kriegen, aber wenn es irgendwie ginge, das so zu machen, das währe für mich quasi der Heilige Gral. Ich weiss, dass zig die Funktionen selbst nicht als async definiert, sondern man beim Aufruf angibt, ob man eine future will. Aber ich weiss nicht, ob die das so wie von Programmierer angegeben machen, oder so wie ich das gerne hätte. Das muss ich mir mal genauer ansehen.
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.
Beitrag #7136148 wurde von einem Moderator gelöscht.
Beitrag #7136150 wurde von einem Moderator gelöscht.
Beitrag #7136151 wurde vom Autor gelöscht.
Beitrag #7136155 wurde von einem Moderator gelöscht.
Beitrag #7136157 wurde von einem Moderator gelöscht.
Beitrag #7136160 wurde von einem Moderator gelöscht.
Beitrag #7136164 wurde von einem Moderator gelöscht.
Beitrag #7136173 wurde von einem Moderator gelöscht.
Beitrag #7136176 wurde von einem Moderator gelöscht.
Beitrag #7136180 wurde von einem Moderator gelöscht.
Ach herrje... was nicht passt wird passend gemacht? Kritik unerwünscht!
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.
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
Die Welt ist zweifelsohne komplex. Daran lässt sich nichts ändern. Die Komplexität der Bedienung von Technik oder Programmierwerkzeugen /sprachen liegt aber in menschlichen Händen. Daran lässt sich durchaus was ändern.
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.)
Beitrag #7200277 wurde von einem Moderator gelöscht.
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!
Moin, <heisemode>Juhuu, das ist das Ende von Linux</heisemode> scnr, WK
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.
🐧 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 ;)
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. Es soll wohl eher als Qualitätsmerkmal dienen: Wenn es nicht gut wäre, würde es im Kernel doch nicht verwendet werden. > 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.
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.
MaWin schrieb: > 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. Frei nach Nietzsche: "Gegen Rust hat man keine Argumente, man hat /dev/null".
MaWin schrieb: > 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? Warum sollte ich beleidigt sein? Ich bin lediglich der Ansicht, dass seine Argumente gegen C++ ziemlich an den Haaren herbeigezogen wirken. Er ist ja nun durchaus auch bekannt dafür, sich manchmal etwas zu sehr von Emotionen treiben zu lassen. Deshalb bin ich bei manchen Aussagen von ihm etwas vorsichtig.
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?
MaWin schrieb: > Das ist für mich eine nutzlose Information, solange du das nicht > begründest. 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. Außerdem ist der C-Standard eh sehr, sehr zurückhaltend mit dem Entfernen alter Funktionen, daran wird auch ein Herr Torvalds nichts ändern. Der einzige Fall, der mir gerade in den Sinn kommt, dürfte gets() sein – aus gutem Grund, aber auch nur nach einer sehr langen Phase der deprecation (der eigentlich eine noch längere Phase vorangegangen ist, in denen so ziemlich jeder davor gewarnt hat, die Funktion überhaupt zu benutzen).
:
Bearbeitet durch Moderator
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.
MaWin schrieb: > Der Kernel verwendet überhaupt keine stdlib. Warum diskutiert Linus dann überhaupt über memmove() und memcpy()? Oder hat der Kernel vielleicht doch eine Standard(ähnliche) Bibliothek? Es ist doch völlig schnuppe, wer diese Bibliothek geschrieben hat. Entscheidend ist, ob sie die Funktionen (oder einige davon) des Standards bereitstellt. MaWin schrieb: > Denn in Rust können Speicherbereiche niemals überlappen und gleichzeitig > drauf zugegriffen werden. 🐧 DPA 🐧 schrieb: > Naja, memmove hat doch auch seine Grenzen, wo heutzutage ein Buffer ja > mehrfach gemappt sein kann. Yup … daran wird vermutlich auch Rust nicht viel ändern können.
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ß.
MaWin schrieb: > Mehrfaches Mapping und gleichzeitiger Zugriff ist nicht möglich in Rust. Es ging mir (und DPA) nicht um irgendwelche Elemente einer Sprache, sondern um das VM Mapping der CPU. Damit kann man immer Aliase erzeugen, denn dieses Konstrukt ist vollständig außerhalb des Einflussbereichs irgendeiner Programmiersprache. Dementsprechend kann man, wenn man an der Stelle nicht sauber drauf achtet, sowohl die Eigentümerschafts-Annahmen von Rust gefährden genauso wie halt (das war das ursprüngliche Argument) Annahmen, die eine memmove()-Implementierung intern trifft.
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.
cppbert schrieb: > 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? Außerhalb einer sehr überschaubaren Nerd-Blase, juckt es doch wirklich niemanden was Linus zum Thema C sagt oder meint.
MaWin schrieb: > Eine Begründung gab es leider nicht. Genauer gesagt: Begründungen interessieren dich nicht. Lassen wir das, hat mit Rust eh nichts zu tun.
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!
MaWin schrieb: > Wo soll diese Begründung denn gewesen sein? Zitat bitte! Ich dachte, du wüsstest den Unterschied zwischen beiden? Die Performance. Sicher nicht auf jeder Architektur gleichermaßen. Aber wie du schon festgestellt hast, hat das mit Rust eh nichts zu tun, weil dieses durch seine Eigentümerschaft so eine Unterscheidung nicht benötigt.
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.
Jörg W. schrieb: > Ich dachte, du wüsstest den Unterschied zwischen beiden? Die > Performance Ach komm. Du trollst doch. Noch einmal extra für dich: Es ging nicht um die Technik hinter memcpy/memmove. Es ging um den politischen Umgang von Linus damit und um die Einschätzung dieses Umgangs als Blödsinn.
🐧 DPA 🐧 schrieb: > Der Kernel managt auch Userspace Ressourcen. Und Userspace kann > nun mal > Speicher mehrfach mappen. Es ist auch in C überhaupt nicht vorgesehen direkt auf Userspace-Speicher zuzugreifen. Das führt im besten Fall zu einem Crash. Im schlimmsten Fall funktioniert es manchmal und führt dann zu Securityproblemen. In Rust ist es gar nicht möglich solche verbotenen Aktionen zu programmieren. > 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 Nein. Man kann sie nicht vergessen. Das ist der entscheidende Unterschied. Man kann in Rust kein funktionierendes Programm schreiben, das Speicherfehler hat. Solche Programme kompilieren schon zu 90% gar nicht erst. Und das gilt auch für Kernelcode.
Jörg W. schrieb: > Ich dachte, du wüsstest den Unterschied zwischen beiden? Die > Performance. Sicher nicht auf jeder Architektur gleichermaßen. Außerdem arbeitet memmove auf einem temporären Speicherblock. Das ist ein riesen Unterschied zu memcpy. Gerade auf kleinen und sehr kleinen Controllern. Das ist auch so ein Umstand den die Rust-Boys immer so gerne vergessen: Was für den PC gut ist, kann für den kleinen Controller katastrophal sein. Die ganzen Sicherheitsfeatures kommen mit einem Preisschild. Die sind nicht umsonst.
:
Bearbeitet durch User
MaWin O. schrieb: > Nein. Man kann sie nicht vergessen. Das ist der entscheidende > Unterschied. Man kann in Rust kein funktionierendes Programm schreiben, > das Speicherfehler hat. Solche Programme kompilieren schon zu 90% gar > nicht erst. Erklär mal bitte grob wie der Compiler erkennt, wenn jemand zur Laufzeit (z.B. sagen wir mal per UART), entscheidet, er möchte nun 50 Byte senden, mein Programm die 50 Bytes allokiert und dann aber 51 Byte rein schreibt. Ich meine, klar, teure Checks zur Laufzeit, inkl. die dafür notwendigen Strukturen für die Arraygrößen usw. kann man haben. Will man nur im Embedded Umfeld so gut wie nicht. Aber zur Kompilierzeit? Geht halt nicht. Daher ist das alles Geschwurbel. Mit religiösem Eifer vorgetragen. Da können die Zeugen Jehovas noch was von lernen.
Cyblord -. schrieb: > Das ist > ein riesen Unterschied zu memcpy. Gerade auf kleinen und sehr kleinen > Controllern. Genau. Zum Glück kann man in Rust ja immer memcpy nutzen, weil es kein Aliasing gibt. Man hat also immer den Performancevorteil. > Das ist auch so ein Umstand den die Rust-Boys immer so > gerne vergessen: Was für den PC gut ist, kann für den kleinen Controller > katastrophal sein. Merkste selbst, gell? > Die ganzen Sicherheitsfeatures kommen mit einem > Preisschild. Die allermeisten Sicherheitsfeatures von Rust sind zero cost. Und die wenigen übrigen sind mit sehr sehr geringen Runtimekosten verbunden. Im Vergleich zwischen zwischen einem korrekten C/C++ Programm (also mit notwendigen Sicherheitschecks) und einem Rust-Programm ist die Performance identisch.
MaWin O. schrieb: > Nein. Man kann sie nicht vergessen. Das ist der entscheidende > Unterschied. Man kann in Rust kein funktionierendes Programm schreiben, > das Speicherfehler hat. Garantien basieren immer auf Annahmen. Solange diese alle erfüllt sind, ist alles gut. Sobald das nicht mehr der Fall ist, hat man Probleme. Wie bei meinem memmove Beispiel oben. Das ist ein wichtiger Teil davon, wie man Sicherheitslücken findet. Und im Kernel wird man auch für solche Spezialfälle die Augen offen halten müssen. Ein "kann eh nicht passieren", funktioniert nicht besonders gut um mögliche Probleme zu finden.
Cyblord -. schrieb: > Aber zur Kompilierzeit? Geht halt nicht. Das hat niemand jemals behauptet. In Rust wird die immer notwendige Laufzeitprüfung lediglich von der Sprache forciert. Das Endergebnis ist das gleiche, wenn man die notwendige Abfrage in C nicht vergisst. > Mit religiösem Eifer vorgetragen. Sehe ich genau so.
🐧 DPA 🐧 schrieb: > Ein "kann eh nicht passieren", funktioniert nicht besonders gut > um mögliche Probleme zu finden. Wenn etwas nicht passieren kann, weil die Randbedingungen es forcieren, dann kann es auch keine Probleme geben. Einfache Logik.
MaWin O. schrieb: >> Aber zur Kompilierzeit? Geht halt nicht. > > Das hat niemand jemals behauptet. Ach nicht? > Solche Programme kompilieren schon zu 90% gar > nicht erst. > In Rust wird die immer notwendige Laufzeitprüfung lediglich von der > Sprache forciert. Das Endergebnis ist das gleiche, wenn man die > notwendige Abfrage in C nicht vergisst. In C implementiert aber normalerweise niemand Laufzeitchecks für JEDEN Zugriff. Genau das bräuchtest du aber um 100% Sicherheit zu haben. Du musst bei JEDEM Zugriff auf das Array, egal ob lesend oder schreibend, Code ablaufen lassen. Dazu brauchst du Speicher wo die Informationen zu jedem Array drin stehen. Dieser Code prüft dann für JEDEN ZUGRIFF ob der innerhalb der Grenzen stattfindet. Vergleiche das mal mit einem data[55]=x und dann erzähle nochmal was von Zero-Cost.
Die Randbedingungen sind in dem Fall die Annahmen, die man sicherstellen muss. Genau da muss man hinsehen. Genau das ist es ja.
Cyblord -. schrieb: > In C implementiert aber normalerweise niemand Laufzeitchecks für JEDEN > Zugriff. Nein. Das ist Unsinn. Man braucht genau einen einzigen Check ganz am Anfang der Verarbeitungskette. Genau wie in C auch. Unnötige Checks fügt der Compiler nicht ein. Und wenn der Compiler die nicht-Notwendigkeit nicht beweisen kann, dann hat man halt einen zusätzlichen Check. Das ist absolut vernachlässigbar. Viele Performancemessungen zeigen genau das. Du hängst dich hier an einem Detail auf. Wenn du wirklich irgendeine Stelle findest, bei der dieser eine Maschinenzyklus dich wirklich stört, kannst du an dieser einen Stelle ja gerne unsafe-Rust verwenden. Der Rest des Programms bleibt trotzdem safe. Im Gegensatz zu einem C-Programm, wo alles unsafe ist. Moderne Compiler sind etwas schlauer als dein K&R-Compiler. Stichwort LTO.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.