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


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


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

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


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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.

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


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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?

von MaWin (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von Mombert H. (mh_mh)


Lesenswert?

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*™?

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


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

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


Lesenswert?

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
von MaWin (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von rbx (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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?

von Ein T. (ein_typ)


Lesenswert?

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
von Ein T. (ein_typ)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von DPA (Gast)


Lesenswert?

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.

von rbx (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

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

Danke

von cppbert (Gast)


Lesenswert?

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?

von rbx (Gast)


Lesenswert?

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.

von rbx (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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?

von cppbert (Gast)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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.

von cppbert3 (Gast)


Lesenswert?

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

von Ein T. (ein_typ)


Lesenswert?

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

von Ron T. (rontem)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von cppbert3 (Gast)


Lesenswert?

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

von cppbert3 (Gast)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von rbx (Gast)


Lesenswert?

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.
von cppbert (Gast)


Lesenswert?

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?

von Ron T. (rontem)


Lesenswert?

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?

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

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


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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

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


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

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


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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.

von DPA (Gast)


Lesenswert?

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

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


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von Mombert H. (mh_mh)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von DPA (Gast)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?

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!

von DPA (Gast)


Lesenswert?

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?

von Mombert H. (mh_mh)


Lesenswert?

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
von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von Mombert H. (mh_mh)


Lesenswert?

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?

von cppbert (Gast)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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

Garantierte Memory-Safety.

von MaWin (Gast)


Lesenswert?

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

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

von cppbert (Gast)


Lesenswert?

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

von Mombert H. (mh_mh)


Lesenswert?

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?

von DPA (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von Mombert H. (mh_mh)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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)

von MaWin (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

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


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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

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


Lesenswert?

Mombert H. schrieb:
> Denn auch C braucht eine Runtime

Wobei diese schon sehr minimalistisch ist: Ausnullen von .bss, 
Initialisieren von .data, Setzen des Stackpointers.

von cppbert (Gast)


Lesenswert?

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?

von rbx (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

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


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

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


Lesenswert?

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

von Mombert H. (mh_mh)


Lesenswert?

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
von cppbert (Gast)


Lesenswert?

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

von DPA (Gast)


Lesenswert?

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.

von Kaj (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von DPA (Gast)


Lesenswert?

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

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


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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!

von Jemand (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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.
von rbx (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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?

von Programmierer (Gast)


Lesenswert?

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.

von cppbert3 (Gast)


Lesenswert?

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?

von MaWin (Gast)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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.

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


Lesenswert?

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.

von Vincent H. (vinci)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von Bernd W. (berndwiebus) Benutzerseite


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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)

von rbx (Gast)


Lesenswert?

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

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

von DPA (Gast)


Lesenswert?

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.

von DPA (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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?

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?


von Programmierer (Gast)


Lesenswert?

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?

von MaWin (Gast)


Lesenswert?

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.

von Daniel A. (daniel-a)


Lesenswert?

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.

von rbx (Gast)


Lesenswert?

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.
von XY M. (xym)


Lesenswert?

Ach herrje... was nicht passt wird passend gemacht?
Kritik unerwünscht!

von cppbert3 (Gast)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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.

von Drüsensekretfermentat (Gast)


Angehängte Dateien:

Lesenswert?

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

von ein bisschen Programmierer (Gast)


Lesenswert?

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

von Ron T. (rontem)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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.
von Kaj (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

🐧 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

von MaWin (Gast)


Lesenswert?

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.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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

von Dergute W. (derguteweka)


Lesenswert?

Moin,

<heisemode>Juhuu, das ist das Ende von Linux</heisemode>

scnr,
WK

von S. R. (svenska)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

🐧 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

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von rbx (Gast)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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

Falsch.
In Rust sehr einfach.

von cppbert (Gast)


Lesenswert?

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

von rbx (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von rbx (Gast)


Lesenswert?

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

von ein lupenreiner Demokrat (Gast)


Lesenswert?

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)

von Rolf M. (rmagnus)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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?

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


Lesenswert?

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
von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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?

von MaWin (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

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


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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

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


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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.

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


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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!

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


Lesenswert?

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.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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

von Cyblord -. (cyblord)


Lesenswert?

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
von Cyblord -. (cyblord)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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

von Cyblord -. (cyblord)


Lesenswert?

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.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Die Randbedingungen sind in dem Fall die Annahmen, die man sicherstellen 
muss. Genau da muss man hinsehen. Genau das ist es ja.

von MaWin O. (mawin_original)


Lesenswert?

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.

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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