Daniel A. schrieb: > Nutzer von Gentoo & co. tun mir jetzt schon leid. Die tun mir schon länger leid. Nicht erst, seit es Rust gibt. SCNR.
MaWin schrieb: > Jörg W. schrieb: >> dann dürfte der Punkt >> erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen >> geschriebener Bibliotheken nicht mehr so wichtig ist. > > Warum sollte man den Punkt anstreben wollen? "unsafe" > Was hat das überhaupt mit Rust zu tun? Rust ist gut interoperabel mit > anderen Sprachen. By Design. "unsafe" > In Gegensatz zu C. C ist nur mit C > kompatibel. Deshalb muss sich der Rest der Welt darum kümmern mit C > kompatibel zu sein. Und das tut Rust sehr gut. Heute. "unsafe"
Jörg W. schrieb: > Für Rust wurde ja zumindest gesagt, dass es mit einer C-Umwelt klar > kommt. Muss es eigentlich auch, denn bis mal alles Wichtige in Rust > verfügbar ist, werden schon noch ein paar Jahrzehnte vergehen. "zumindest gesagt" "muss es eigentlich" wurde schon sooo oft hier geschrieben - warum vermuten/fabulieren? Rust kann direkt mit C gelinkt werden
MaWin schrieb: > Jörg W. schrieb: >> dann dürfte der Punkt >> erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen >> geschriebener Bibliotheken nicht mehr so wichtig ist. > > Warum sollte man den Punkt anstreben wollen? Es war die Antwort auf deine Frage. Wenn du der Meinung bist, dass das gar nicht anstrebenswert ist, dann hättest du dir deine Frage auch sparen können. > In Gegensatz zu C. C ist nur mit C > kompatibel. Wenn du derartige Äußerungen weglassen würdest, würde das deiner Glaubwürdigkeit gut zu Gesicht stehen. So tust du Rust einfach keinen Gefallen, weil sich jeder sagt: "Wenn deren Fanboys alle so sind, will ich damit nichts zu tun haben."
cppbert3 schrieb: > wurde schon sooo oft hier geschrieben - warum vermuten/fabulieren? Ich vermute oder fabuliere nicht, habe es nur selbst nicht verifiziert. Daher als Aussage anderer kenntlich gemacht. Aber darum ging es gar nicht, sondern um deine Behauptung, dass es keine Intention gewesen wäre, dass C via Linker mit anderen Sprachen zusammen arbeitet. Die entbehrt jeglicher Grundlage.
Mombert H. schrieb: > MaWin schrieb: >> Jörg W. schrieb: >>> dann dürfte der Punkt >>> erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen >>> geschriebener Bibliotheken nicht mehr so wichtig ist. >> >> Warum sollte man den Punkt anstreben wollen? > "unsafe" >> Was hat das überhaupt mit Rust zu tun? Rust ist gut interoperabel mit >> anderen Sprachen. By Design. > "unsafe" >> In Gegensatz zu C. C ist nur mit C >> kompatibel. Deshalb muss sich der Rest der Welt darum kümmern mit C >> kompatibel zu sein. Und das tut Rust sehr gut. Heute. > "unsafe" das ist doch jedem absolut klar, oder? und selbst wenn nicht, 5min Rust Doku lesen und aufhören zu vermuten wie soll Rust den bitte externe Abhängigkeiten safe einbinden? Rust ist eine Systemsprache die nicht an jeder Ecke Prüfcode einbaut und auch nur deshalb überhaupt für Kernel-Entwicklung und High-Performanz relevant sein kann diese episch tiefen Diskussionen über Kompiletime/Statische-Prüfbarkeit usw. scheitert hier häufig daran das irgendwelche Leute denke das Safe-Rust meint das alles geprüft wird oder Safe-Rust meint es sollte dann aber auch keine Fehler mehr geben - das ist doch Mathematisch/Systemisch gar nicht möglich - und auch die Rust Leute können nicht die Natur der Software-Probleme per se lösen sondern nur stark abschwächen viele Leute finde "abschwächen" ist schon toll genug - auch wenn viele der Pro-Entwickler hier das 0 nachvollziehen können - weil ihr Code ja keine Fehler hat, oder ihre Team-Mitglieder alle gleich gut sind,...
Jörg W. schrieb: > Aber darum ging es gar nicht, sondern um deine Behauptung, dass es keine > Intention gewesen wäre, dass C via Linker mit anderen Sprachen zusammen > arbeitet. Die entbehrt jeglicher Grundlage. das ist doch jedem Entwickler 100% klar, oder? warum hier immer alle davon ausgehen das der Gesprächspartner nur 30% von der Medaille kennt? Genau diese Denke führt hier zu diesen endlosen Tiefen-Diskussionen über banale Themen - Kompiletimeprüfung, Sanitizer, Zertifizierung, Entwicklungsprozesse - das sind alles alte Hüte die jeder kann und macht - und wenn man das dann so überdeutlich ausdrückt kommt hier jeder und erklärt wie relevant die Themen sind - als wäre das irgendjemanden nicht klar Es ist nur einfach völlig unrelevant für den jetzigen Entwicklungstand von Rust - und war es auch vor Jahrzehnten für C/C++ und alle anderen jungen Programmiersprachen und jetzt hört doch bitte auf immer in diesen Micro-Themen zu rotieren
Jörg W. schrieb: >> In Gegensatz zu C. C ist nur mit C kompatibel. > Wenn du derartige Äußerungen weglassen würdest, würde das deiner > Glaubwürdigkeit gut zu Gesicht stehen. Ach? Mit welchen Sprachen ist C denn so kompatibel? Und wie sieht das C-Konstrukt aus, mit dem man z.B. angibt, dass Funktion X ein zur Sprache Y kompatibles ABI erhalten soll? Ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind, und nicht umgekehrt? Jörg W. schrieb: > So tust du Rust einfach keinen > Gefallen, weil sich jeder sagt: "Wenn deren Fanboys alle so sind, will > ich damit nichts zu tun haben." Wenn ein Programmierer seine Wahl der Programmiersprache von pseudonymen Posts von MaWin auf Mikrocontroller.net abhängig macht, dann ist diesem Programmierer eh nicht mehr zu helfen.
cppbert3 schrieb: > das ist doch jedem absolut klar, oder? > und selbst wenn nicht, 5min Rust Doku lesen und aufhören zu vermuten Könntest du kurz erklären was jedem klar ist? Und was die Doku damit zu tun hat? Ich verstehe nicht was du hier sagen willst. cppbert3 schrieb: > wie soll Rust den bitte externe Abhängigkeiten safe einbinden? Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg. Was du mit dem Rest deiner Tirade ausdrücken willst, weiß ich auch nicht.
Mombert H. schrieb: > cppbert3 schrieb: >> das ist doch jedem absolut klar, oder? >> und selbst wenn nicht, 5min Rust Doku lesen und aufhören zu vermuten > Könntest du kurz erklären was jedem klar ist? Und was die Doku damit zu > tun hat? Ich verstehe nicht was du hier sagen willst. das externe Abhängigkeiten unsafe eingebunden werden muessen klar ist - sonst müsste Rust entweder sau langsam sein (wegen Prüfungen) oder irgendein magisches Konzept haben unsafes safe zu machen > cppbert3 schrieb: >> wie soll Rust den bitte externe Abhängigkeiten safe einbinden? > Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg. jetzt verstehe ich dich nicht - d.h. alles in Rust schreiben??? wie soll ich sonst die Abhängigkeiten los werden? > Was du mit dem Rest deiner Tirade ausdrücken willst, weiß ich auch > nicht. ist nicht so schlimm, dauert noch ein bisschen
Mombert H. schrieb: > Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg. Nein, "müssen" sie nicht. Warum sollten sie das "müssen"? Eine externe Bibliothek ist exakt genau so zu handhaben, wie unsafe-Blöcke in Rust. Da gibt es sogar ein Buch drüber, wenn du wissen willst, wie das geht: https://doc.rust-lang.org/nomicon/ (work in progress) Es ist doch völlig weltfremd anzunehmen, dass plötzlich alle Software der Welt nur noch in Rust geschrieben werden wird.
cppbert3 schrieb: > sonst müsste Rust entweder sau langsam sein (wegen Prüfungen) Ich dachte wir hätten abschließend geklärt, dass Safe-Rust im Mittel nicht langsamer ist als äquivalenter sicherer C-Code? Das ist ein Rust-Designziel.
cppbert3 schrieb: > Mombert H. schrieb: >> cppbert3 schrieb: >>> das ist doch jedem absolut klar, oder? >>> und selbst wenn nicht, 5min Rust Doku lesen und aufhören zu vermuten >> Könntest du kurz erklären was jedem klar ist? Und was die Doku damit zu >> tun hat? Ich verstehe nicht was du hier sagen willst. > > das externe Abhängigkeiten unsafe eingebunden werden muessen klar ist - > sonst müsste Rust entweder sau langsam sein (wegen Prüfungen) oder > irgendein magisches Konzept haben unsafes safe zu machen Ok, was genau hat das mit dem ursprünglich (und natürlich von dir ausgelassenen) Beitrag zu tun, auf den du geantwortet hast? >> cppbert3 schrieb: >>> wie soll Rust den bitte externe Abhängigkeiten safe einbinden? >> Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg. > > jetzt verstehe ich dich nicht - d.h. alles in Rust schreiben??? > wie soll ich sonst die Abhängigkeiten los werden? Wtf? >> cppbert3 schrieb: >> Was du mit dem Rest deiner Tirade ausdrücken willst, weiß ich auch >> nicht. > > ist nicht so schlimm, dauert noch ein bisschen ...
MaWin schrieb: > cppbert3 schrieb: >> sonst müsste Rust entweder sau langsam sein (wegen Prüfungen) > > Ich dachte wir hätten abschließend geklärt, dass Safe-Rust im Mittel > nicht langsamer ist als äquivalenter sicherer C-Code? Das ist ein > Rust-Designziel. das ist mir klar - ich fragte mich nur weiso Mombert H. überall unsafe geschrieben hatte in seinem Post - als wäre das was schlechtes, und dann meinte wir müssen die "Abhängigkeiten los werden" - aber laut seinem letzten Post "ohne neu schreiben in Rust" - keine Ahnung was er überhaupt meint
Mombert H. schrieb: >> das externe Abhängigkeiten unsafe eingebunden werden muessen klar ist - >> sonst müsste Rust entweder sau langsam sein (wegen Prüfungen) oder >> irgendein magisches Konzept haben unsafes safe zu machen > Ok, was genau hat das mit dem ursprünglich (und natürlich von dir > ausgelassenen) Beitrag zu tun, auf den du geantwortet hast? > >>> cppbert3 schrieb: >>>> wie soll Rust den bitte externe Abhängigkeiten safe einbinden? >>> Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg. >> >> jetzt verstehe ich dich nicht - d.h. alles in Rust schreiben??? >> wie soll ich sonst die Abhängigkeiten los werden? > Wtf? ich habe direkt auf einen Post geantwortet wo du überall "unsafe" hingeschrieben hast und ich mich gewundert hatte wie man sonst externen Code einbinden soll auf den das Rust Sicherheitskonzept keinen Einfluss hat dann kam dein Kommentar mit den "deswegen müssen die Abhängigkeiten ja weg" womit ich völlig verloren bin und dachte du meinst das die externen Abhängigkeiten in Rust geschrieben werden müssen - weil ich sonst nicht verstehe was das "Abhängigkeiten ja weg" in diesem Kontext sonst bedeuten könnte
MaWin schrieb: > ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind Nein, sind sie nicht. Mit deiner Argumentation ist wohl jede Sprache nur mit sich selbst kompatibel, denn sie kennt Konstrukte, die sich nicht in einer anderen ausdrücken lassen. Ein Pascal-Array-Argument kannst du beispielsweise in C nicht ausdrücken, denn es übergibt außer der Adresse auch seinen Indexbereich an den Aufgerufenen. Eine variadische Argumentliste in C wirst du wiederum in Pascal nicht aufgedröselt bekommen. Kompatibilität ist folglich immer der kleinste gemeinsame Nenner zwischen beiden Seiten.
cppbert3 schrieb: > ich fragte mich nur weiso Mombert H. überall unsafe > geschrieben hatte in seinem Post - als wäre das was schlechtes, Ja. Das ist richtig. Unsafe-Codeteile, unter die auch externe Bibliotheken fallen, sind nicht schlecht. Es ist gar nicht so, dass Rustentwickler jetzt plötzlich losrennen und alle Unsafe-Teile eliminieren wollen. Ganz im Gegenteil. Unsafe-Code ist in Ordnung. Es bedeutet nur, dass dieser Code erheblich mehr Review und Testing erfahren muss. Es ist ja auch gar nicht alles in Safe-Rust formulierbar, was formuliert werden muss. Je näher man an die Hardware kommt, desto mehr unsafe-Blöcke werden notwendig werden. Das Ziel ist es jedoch, diese unsafe-Blöcke in entsprechenden Safe-Rust-Modulen zu wrappen. Und genau das passiert auch mit externen Bibliotheken.
MaWin schrieb: > Ach? Mit welchen Sprachen ist C denn so kompatibel? > Und wie sieht das C-Konstrukt aus, mit dem man z.B. angibt, dass > Funktion X ein zur Sprache Y kompatibles ABI erhalten soll? Wie soll den C die Datentypen und sonstigen Eigenheiten zukünftiger Sprachen unterstützen? Und wozu? C ist sehr alt, stabil, simpel, und bietet alles nötige, damit andere Programme mit ihm interoperieren können. Das ABI ist auch überall relative stabil und gut definiert. Zusammen mit seiner Verbreitung ist es daher heute mit so ziemlich jeder Sprache kompatibel. Oft verwendet man es sogar, um verschiedene Sprachen verbinden zu können. Es bietet sich in seiner jetzigen Form und Verbreitung dafür gerade zu an. Auch wenn es dank historischer & designtechnischer Gründe diese Interopabilität quasi gratis bekommen hat, das ändert aber nichts daran, dass sie vorhanden ist. Ausserdem, ist die ABI von Rust für die diversen Platformen mittlerweile endlich mal Stabil & Dokumentiert? Wobei, da müsste man vermutlich erst mal die Sprache selbst standardisieren? Wie soll man denn so damit überhaupt vollständig kompatibel sein können, im sinne von all seine Datentypen und APIs direkt nutzen können? Man könnte das also umkehren. C erlaubt es anderen Sprachen recht einfach, zu ihm kompatibel zu sein. Aber ist das bei Rust überhaupt möglich?
Jörg W. schrieb: > MaWin schrieb: >> ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind > > Nein, sind sie nicht. > > Mit deiner Argumentation ist wohl jede Sprache nur mit sich selbst > kompatibel, denn sie kennt Konstrukte, die sich nicht in einer anderen > ausdrücken lassen. Ein Pascal-Array-Argument kannst du beispielsweise in > C nicht ausdrücken, denn es übergibt außer der Adresse auch seinen > Indexbereich an den Aufgerufenen. Eine variadische Argumentliste in C > wirst du wiederum in Pascal nicht aufgedröselt bekommen. > > Kompatibilität ist folglich immer der kleinste gemeinsame Nenner > zwischen beiden Seiten. MaWin wollte sicherlich eher zum Ausdruck bringen das der Teil den wir alle kennen von C der meistgenutzte gemeinsame Nenner ist an dem sich viele orientieren - und ja das passt auch für vieles von Pascal - aber man spricht dann trotzdem oft von der C Kompatibilität - obwohl auch Sprachen die älter sind als C schon "C-Kompatible" waren Aber wie immer die Frage: Ist das wirklich Themen relevant?
Jörg W. schrieb: >> ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind > Nein, sind sie nicht. Krass, wie du krampfhaft versuchst deine falsche Argumentation aufrecht zu erhalten. C++ ist also nicht kompatibel zu C? extern "C"? Rust ist also nicht kompatibel zu C? Auch wenn man structs und Funktionen explizit die C-ABI geben kann? > Kompatibilität ist folglich immer der kleinste gemeinsame Nenner > zwischen beiden Seiten. Und C trägt aktiv exakt gar nichts dazu bei kompatibel zu irgendetwas zu sein. C ist einfach nur C, so wie es ist. C ist der kleinste gemeinsame Nenner, weil seine ABI so primitiv ist und weil es schlicht älter ist als alle anderen aktiv genutzten Sprachen. Es gibt kein C-Konstrukt, mit dem man die ABI auf die einer anderen Sprache anpassen kann.
MaWin schrieb: > Es ist gar nicht so, dass > Rustentwickler jetzt plötzlich losrennen und alle Unsafe-Teile > eliminieren wollen. Ganz im Gegenteil. Unsafe-Code ist in Ordnung. Es > bedeutet nur, dass dieser Code erheblich mehr Review und Testing > erfahren muss. viele denken man müsste alles nach Rust portieren keine Ahnung wo dieser (schon dem Wahnsinn nahe stehendem) Irrglaube herkommt sowas kenne ich nur von Anfängern oder Nur-eine-Sprach-Evangelisten (die zum Glück immer weniger im Business anzutreffen sind)
Daniel A. schrieb: > Es bietet sich in seiner jetzigen Form und > Verbreitung dafür gerade zu an. deswegen wird es ja auch direkt von Rust supportet, weil das schon so viele sprechen :) Daniel A. schrieb: > Aber ist das bei Rust überhaupt > möglich? gerade nicht weil die höherwertigen Konzepte sich recht schwerlich durch eine ABI pressen lassen ohne die Performanzvorteile zu verlieren - wie bekommt man ein Kompiletime Ownership-Konzept durch eine Library/Dll-Grenze - nicht so einfach Ich könnte mir vorstellen das sie eine Rust zu Rust ABI hinbekommen aber eine Rust zu C ABI mit allen Rust-Features wird echt schwer ist aber vergleichbar mit den Schwierigkeiten C++, C#, Java Konzepte mit C zu verbinden
MaWin schrieb: > Jörg W. schrieb: >>> ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind >> Nein, sind sie nicht. > > Krass, wie du krampfhaft versuchst deine falsche Argumentation aufrecht > zu erhalten. > C++ ist also nicht kompatibel zu C? extern "C"? > Rust ist also nicht kompatibel zu C? Auch wenn man structs und > Funktionen explizit die C-ABI geben kann? Jörg hat technisch schon recht mit seinem kleinsten gemeinsamen Nennen was die Datenbereite/Typen angeht (das ist aber eher ein Hardware-Standard) aber spätestens bei Calling-Conventions hat MaWin recht - da ist es das C-Standard(Subset) mit cdecl das supported wird oder auch z.B. die typischen C-Strings die meisten Sprachen sprechen auch explizit von C Kompatibilität ansonsten sind alle Sprache erstmal nur zu sich selbst kompatibel (oder dem C-Standard-Subset) im Detail geht es bei der Kompatiblität nur um die Stabilität der ABI - ob die sich jetzt C oder whatever schimpft ist unrelevant
cppbert3 schrieb: > Ich könnte mir vorstellen das sie eine Rust zu Rust ABI hinbekommen also z.B. gibt es zwei Rust DLLs (A und B) die unterschiedliche Heaps haben und wenn die B-DLL Heap-Daten von der A-DLL ownen will das es dann eine besondere Form von Big/Fat-Pointer oder sowas gibt und es laut der ABI klar ist das es dann Performanprobleme geben kann wenn die Heap-Daten Löschung an A delegiert werden muss - oder eine Art Copy-on-transfer-Konzept Alles nicht sehr einfach und schwer generisch definierbar (soll es leicht sein, performant sein, etc.) ähnlich wie der Design-Trouble mit Async - nur noch viel komplizierter
cppbert3 schrieb: > also z.B. gibt es zwei Rust DLLs (A und B) die unterschiedliche Heaps > haben das Problem ist vergleichbar mit std::vector über DLL-Grenze mit unterschiedlichen Heaps aber ich habe immer noch die Hoffnung das Rust hier auch irgendwann mal mit einem besseren Konzept kommt als wie bisher: -Alles nur per Value -Alles auf eine C-artige API runterbrechen -Alles mit Interfaces auf dem Heap/Ref-Counted ohne unterschiedliche Heaps gibt es keine Probleme
cppbert3 schrieb: > obwohl auch Sprachen die älter sind als C schon "C-Kompatible" waren FORTRAN übergibt alles in einer Parametertabelle, alle Parameter sind dort per Referenz übergeben – zumindest das FORTRAN, was älter ist als C. (Auf der PDP-11 wurde die Adresse der Tabelle in R5 übergeben.) Weiß nicht, ob sie inzwischen auch andere Aufrufkonventionen haben. Mit üblichen C-Konventionen ist das nicht kompatibel … > Aber wie immer die Frage: Ist das wirklich Themen relevant? Sicher nicht, aber ich habe die Diskussion, alles würde sich nur nach C richten müssen, auch nicht begonnen.
Jörg W. schrieb: >> Aber wie immer die Frage: Ist das wirklich Themen relevant? > > Sicher nicht, aber ich habe die Diskussion, alles würde sich nur nach C > richten müssen, auch nicht begonnen. aber sie auch nicht gestoppt - und jetzt auch noch ne Uralt PDP-11 mit ins Feld geworfen :)
Jörg W. schrieb: >> Aber wie immer die Frage: Ist das wirklich Themen relevant? > > Sicher nicht, aber ich habe die Diskussion, alles würde sich nur nach C > richten müssen, auch nicht begonnen. und dir haben die 2.98% die sich nicht nach C richten gereicht um die Diskussion weiter zu befeuern - meinetwegen auch 13.445% aber mehr gestehe ich dir da nicht an Relevanz zu :)
Hallo, cppbert3 schrieb: > und jetzt hört doch bitte auf immer in diesen Micro-Themen zu rotieren Was sind denn dann für dich "Macro-Themen" über die man diskutieren sollte? rhf
Roland F. schrieb: > Was sind denn dann für dich "Macro-Themen" über die man diskutieren > sollte? Rust-Macros, zum Beispiel. Sehr spannendes Thema.
Ich war jetzt mal ein paar Wochen weg und ein interessanteste Punkt der Diskussion war für mich, dass (a) der Rust-Compiler fehlerfrei ist (d.h. entsprechend der Sprachdefinition arbeitet); (b) die vielen Compilerversionen und -änderungen daher irrelevant sind; (c) man in Rust garnicht fehlerhaft programmieren kann, weil die Sprache Fehler schon vorher verhindert; (d) die Kompatiblität zu älteren Sprachstandards (nach Spezifikation) ausschließlich durch den Compiler sichergestellt wird; (e) Cargo und Rust überhaupt nichts miteinander zu tun haben. Ich hab nichts gegen Rust. Nur gegen tightly-coupled-garbage.
bevor hier wieder alle schreien https://www.golem.de/news/open-source-entwickler-sabotiert-eigene-vielfach-genutzte-npm-pakete-2201-162299.html das ist natürlich eine Gefahr - aber ich denke trotzdem das Rust oder auch npm oder auch vcpkg dafür einen dauerhaft sinnvolle Lösung finden müssen in diesem Fall ist aber scheinbar ein "verlässlicher" auf die dunkle Seite der Macht konvertiert - um so mehr das passiert um so eher gibt es sinnvolle Diskussionen wie man automatische und sichere Depenency-Management bauen kann mir ist klar das es keine 100% Lösung gibt, aber vielleicht ergeben sich ja zwitter-Strategien die doch ganz gut funktionieren
cppbert3 schrieb: > das ist natürlich eine Gefahr - aber ich denke trotzdem das Rust oder > auch npm oder auch vcpkg dafür einen dauerhaft sinnvolle Lösung finden > müssen Naja, ich glaube diese Lösung, so gut das eben geht, bietet crates.io bereits. Zitat Artikel: > durch das Löschen von Paketen. Das geht auf crates.io nicht. Natürlich ist man grundsätzlich davon abhängig, dass ein Entwickler nicht durchdreht und plötzlich Mist baut. Aber auf crates.io gilt das nur für neue Versionen. Wenn man bereits eine Version verwendet, dann garantiert crates.io, dass genau diese Version dauerhaft und unverändert bereitgestellt werden wird. Daran kann auch der Autor nichts ändern. Das zusammen mit Cargo.lock bedeutet, dass es nicht passieren kann, dass die eigene SW sich plötzlich anders verhält oder gar Schadsoftware einfließen kann. Um neue Dependency-Versionen einzupflegen, ist immer eine bewusste Interaktion des Entwicklers per cargo update notwendig.
cppbert3 schrieb: > um so mehr das passiert um so eher gibt es > sinnvolle Diskussionen wie man automatische und sichere > Depenency-Management bauen kann Erst machen - dann denken. Sehr gut.
MaWin O. schrieb: > Aber auf crates.io gilt das > nur für neue Versionen. Wenn man bereits eine Version verwendet, dann > garantiert crates.io, dass genau diese Version dauerhaft und unverändert > bereitgestellt werden wird. Daran kann auch der Autor nichts ändern. Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen und Urhaberrechte eingehalten werden? Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird?
Mombert H. schrieb: > Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen > und Urhaberrechte eingehalten werden? Ehm, warum sollte es? > Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird? Das ist, wie immer, das Problem des Autors. Also sollte er so etwas nicht tun. Deine Nebelkerze habe ich als solche erkannt.
Mombert H. schrieb: > Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen > und Urhaberrechte eingehalten werden? Nein. Es ist Aufgabe des Paketautors, seinen Code zu schreiben, zu paketieren und zu veröffentlichen. Das Repository hat damit nichts zu tun. Es ist Aufgabe aller Nutzer des Paketes, das Paket selbst sowie sämtliche zukünftigen Updates auf Lizenzverstöße, Fehler, Böswilligkeit und andere Rechtswidrigkeiten zu überprüfen, bevor sie in der eigenen Software verwendet werden. Praktisch also ein "update all please", gelegentlich gefolgt von "run my testsuite", wie man bei npm gerade schön sieht. (Sind ja nicht alle direkt betroffen. Nur viele.) Dieses Problem (oder ein Äquivalent) besteht grundsätzlich bei allen auf schnelle Releasezyklen ausgelegten Systemen. Cargo und crates.io sind da nicht besser oder schlechter, und die Grundidee kritisieren zählt in großen Teilen der Informatik als Gotteslästerung. MaWin O. schrieb: >> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird? > Das ist, wie immer, das Problem des Autors. Also sollte er so etwas > nicht tun. Falsch. Es ist ein Problem des Nutzers des Pakets, nicht des Autors des Pakets. Und wenn Pakete tatsächlich nicht gelöscht werden können, dann ist das sowieso ein interessantes Phänomen. Vielleicht brauchen wir, wie von cppbert3 vorgeschlagen, einfach mehr Sabotage. Damit kriegen wir die Probleme alle klein.
S. R. schrieb: > Vielleicht brauchen wir, wie von cppbert3 vorgeschlagen, einfach mehr > Sabotage. Damit kriegen wir die Probleme alle klein. Pass auf, was du dir wünschst! Beitrag "Re: Rust - ist das hier um zu bleiben?"
S. R. schrieb: >> Das ist, wie immer, das Problem des Autors. Also sollte er so etwas >> nicht tun. > Falsch. Es ist ein Problem des Nutzers des Pakets, nicht des Autors des > Pakets. Falsch? Es ist vielmehr das Problem des Autors und des Nutzers. Deshalb war meine Aussage nicht falsch, sondern richtig. > und die Grundidee kritisieren zählt in > großen Teilen der Informatik als Gotteslästerung. An einer sachlichen Diskussion ist jeder interessiert. > Dieses Problem (oder ein Äquivalent) besteht grundsätzlich bei allen auf > schnelle Releasezyklen ausgelegten Systemen. Cargo und crates.io sind da > nicht besser oder schlechter Cargo ist auf vieles ausgelegt. Aber mit Sicherheit nicht auf die schnelle Änderungen von Dependency-Versionen. Ganz im Gegenteil. Cargo lockt the Dependency-Versionen, wie ich bereits beschrieben habe, fest.
MaWin O. schrieb: > Mombert H. schrieb: >> Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen >> und Urhaberrechte eingehalten werden? > Ehm, warum sollte es? >> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird? > Das ist, wie immer, das Problem des Autors. Also sollte er so etwas > nicht tun. S. R. schrieb: > Es ist Aufgabe aller Nutzer des Paketes, das Paket selbst sowie > sämtliche zukünftigen Updates auf Lizenzverstöße, Fehler, Böswilligkeit > und andere Rechtswidrigkeiten zu überprüfen, bevor sie in der eigenen > Software verwendet werden. Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn dort veröffentliche Software gegen geltendes Recht verstößt?
Mombert H. schrieb: > MaWin O. schrieb: >> Mombert H. schrieb: >>> Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen >>> und Urhaberrechte eingehalten werden? >> Ehm, warum sollte es? >>> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird? >> Das ist, wie immer, das Problem des Autors. Also sollte er so etwas >> nicht tun. > > S. R. schrieb: >> Es ist Aufgabe aller Nutzer des Paketes, das Paket selbst sowie >> sämtliche zukünftigen Updates auf Lizenzverstöße, Fehler, Böswilligkeit >> und andere Rechtswidrigkeiten zu überprüfen, bevor sie in der eigenen >> Software verwendet werden. > > Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn > dort veröffentliche Software gegen geltendes Recht verstößt? ob crates.io durch sein Verhalten Rechtsbruch begeht hat doch mit der Sprache Rust absolut gar nicht zu tun - oder um was geht es dir? wie handhaben das vpckg, Conan, npm und die vielen anderen Package Manager - find das doch mal raus und berichtet hier
cppbert3 schrieb: > Mombert H. schrieb: >> MaWin O. schrieb: >>> Mombert H. schrieb: >>>> Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen >>>> und Urhaberrechte eingehalten werden? >>> Ehm, warum sollte es? >>>> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird? >>> Das ist, wie immer, das Problem des Autors. Also sollte er so etwas >>> nicht tun. >> S. R. schrieb: >>> Es ist Aufgabe aller Nutzer des Paketes, das Paket selbst sowie >>> sämtliche zukünftigen Updates auf Lizenzverstöße, Fehler, Böswilligkeit >>> und andere Rechtswidrigkeiten zu überprüfen, bevor sie in der eigenen >>> Software verwendet werden. >> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn >> dort veröffentliche Software gegen geltendes Recht verstößt? > ob crates.io durch sein Verhalten Rechtsbruch begeht hat doch mit der > Sprache Rust absolut gar nicht zu tun - oder um was geht es dir? Was willst du jetzt mit der Sprache, oder ist cargo und crates.io plötzlich doch Teil der Sprache? > wie handhaben das vpckg, Conan, npm und die vielen anderen Package > Manager - find das doch mal raus und berichtet hier Sie werden Pakete, die gegen die Regeln verstoßen, löschen. Aber das geht ja laut MaWin auf crates.io nicht.
Mombert H. schrieb: >> ob crates.io durch sein Verhalten Rechtsbruch begeht hat doch mit der >> Sprache Rust absolut gar nicht zu tun - oder um was geht es dir? > Was willst du jetzt mit der Sprache, oder ist cargo und crates.io > plötzlich doch Teil der Sprache? >> wie handhaben das vpckg, Conan, npm und die vielen anderen Package >> Manager - find das doch mal raus und berichtet hier > Sie werden Pakete, die gegen die Regeln verstoßen, löschen. Aber das > geht ja laut MaWin auf crates.io nicht. wenn dich Rust interessiert dann diskutier das Lösch-Problem direkt mit den crates.io Leuten ansonsten spar es dir doch mit MaWin zum rum zu spielen, was bringt das hier?
Mombert H. schrieb: > Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn > dort veröffentliche Software gegen geltendes Recht verstößt? Nein. Das hat auch niemand geschrieben. Mombert H. schrieb: > Sie werden Pakete, die gegen die Regeln verstoßen, löschen. Aber das > geht ja laut MaWin auf crates.io nicht. Nicht von AUTOR selbst löschbar. Lies bitte meine Beiträge richtig. Selbstverständlich haben die Administratoren von crates.io für den absoluten Sonderfall, dass jemand rechtswidriges Material hochlädt, immer noch den superuser-Zugriff auf die Datenbank.
MaWin O. schrieb: > Mombert H. schrieb: >> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn >> dort veröffentliche Software gegen geltendes Recht verstößt? > Nein. Das hat auch niemand geschrieben. > Mombert H. schrieb: >> Sie werden Pakete, die gegen die Regeln verstoßen, löschen. Aber das >> geht ja laut MaWin auf crates.io nicht. > > Nicht von AUTOR selbst löschbar. Lies bitte meine Beiträge richtig. Und was passiert, wenn der AUTOR sich and die Administatoren von crates.io wendet und sagt, "Ich habe nicht die Rechte an dieser Software. Bitte löscht sie."?
Mombert H. schrieb: > Und was passiert, wenn der AUTOR sich and die Administatoren von > crates.io wendet und sagt, "Ich habe nicht die Rechte an dieser > Software. Bitte löscht sie."? Ich weiß es nicht, aber da wird sicher nach vernünftigem menschlichem Ermessen drauf reagiert. Und damit beende ich jetzt diese absolut dümmliche und nicht zielführende Diskussion.
@MaWin O. mich würde interessieren wie du das Thema ABI siehst (die C-ABI können wir - deswegen würde ich die mal komplett ausblenden) -wie könnte eine "echte" Rust-ABI aussehen/was sind Herausforderungen Kann es eine echte Rust-ABI geben oder wird das genau so ein Problem wie mit C++ und dem nicht C-Rest? -irgendeine Vorstellung wie Dlls/Shared Object (mit nicht gemeinsam genutzten (Shared-CRT) Heaps diese Rust-ABI nutzen könnten) mögliche Herausforderung: Owner-Ship-Transfer ueber Heap-Grenzen? gibt es da irgendwelche Vorstellungen in der Community? das Thema "echte" ABI und shared objects wird ja noch relativ stark auf "wir können ja C konform sein reduziert" oder denkst du das Rust eher als Inside/Inline-Implementierung genutzt werden wird und es einfach nicht so viel Austausch über die oben genannten Grenzen geben wird weil alles direkt verlinkt ist?
ein paar Beispiele was so lange wir nicht von nur ein paar Value-Types reden ein Problem ist - z.B. in C++ Lib1(std::vector<x>*) <-> Lib2(std::vector<TypeX>*) (oder DLLs mit shared Heaps) Probleme: -Release/Debug Layout Unterschied beim vector DLL ohne shared Heaps Dll1(std::vector<x>*) <-> Dll2(std::vector<TypeX>*) Probleme: -Release/Debug Layout unterschied beim vector -vector delete muss an den richtigen Heap gehen und solche Sachen Java und C# usw. haben solchen Probleme nicht weil deren Runtime oder die eingeschränkten Generics solche ABI Probleme gar nicht erzeugen können, es gibt kein echtes Binary-Linking
MaWin O. schrieb: > Es ist vielmehr das Problem des Autors und des Nutzers. Deshalb war > meine Aussage nicht falsch, sondern richtig. Es ist mein Problem, fremden Code unverifiziert auszuführen. Ob der fremde Code überhaupt da hätte sein dürfen, ist ein separates Problem. Jemandem, der auf einer gleichrangigen Kreuzung von rechts kommt, muss ich die Vorfahrt gewähren - auch dann, wenn er rückwärts und falschrum aus einer Einbahnstraße kommt. Dass er das selbst nicht darf, ist nicht mein Problem. Wenn eine Firma ein illegales Paket einbindet und damit Geld verdient, dann wird die Firma angeklagt und nicht derjenige, der das Paket illegalerweise irgendwo hochgeladen hat. Das fällt unter "due diligence". >> Dieses Problem (oder ein Äquivalent) besteht grundsätzlich bei allen auf >> schnelle Releasezyklen ausgelegten Systemen. Cargo und crates.io sind da >> nicht besser oder schlechter > > Cargo ist auf vieles ausgelegt. Aber mit Sicherheit nicht auf die > schnelle Änderungen von Dependency-Versionen. Besser lesen. Ich schrieb "Releasezyklen". Du hast inzwischen mehrfach wiederholt festgestellt, dass Cargo nicht automatisch deine Versionsnummern aktualisiert, das ist angekommen. Aber in der Realität macht man regelmäßig ein Update und fertig ist - und genau diesen Schritt vereinfacht Cargo, wie auch jeder andere Paketmanager. Oft macht man das Update sogar automatisch (für nightlies, wann immer ein Update auftritt, etc.), der Sicherheit(slücken) wegen. Wir leben in einer Welt, in der Abhängigkeiten oft genug im Lockstep aktualisiert werden müssen, damit das Gesamtsystem noch funktioniert. Besonders, wenn alle Abhängigkeiten statisch in das Programm geklebt werden und ohnehin alles neu gebaut werden muss. Oder willst du ernsthaft argumentieren, dass man Code nie aktualisieren müsste und das deswegen kein Problem ist? Wirklich? Mombert H. schrieb: > Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn > dort veröffentliche Software gegen geltendes Recht verstößt? Nein. Aber vor Gericht landet erstmal der Nutzer der Pakete, der dann wiederum crates.io auf Schadensersatz verklagen kann. Ich bin mir sicher, das Regelwerk von crates.io wird den Schaden dann an den Autor weiterreichen.
Beitrag #6940915 wurde von einem Moderator gelöscht.
S. R. schrieb: > Mombert H. schrieb: >> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn >> dort veröffentliche Software gegen geltendes Recht verstößt? > > Nein. Aber vor Gericht landet erstmal der Nutzer der Pakete, der dann > wiederum crates.io auf Schadensersatz verklagen kann. Ich bin mir > sicher, das Regelwerk von crates.io wird den Schaden dann an den Autor > weiterreichen. Du bist dir sicher? Basiert dein sicher auf deinem Bauchgefühl oder kann man das irgendwo nachlesen? Also beide Teile, dass der Nutzer zuerst vor Gericht landet und dass der Nutzer gegenüber der Plattform einen Anspruch auf Schadensersatz hat. Wenn ich mir da z.B. "illegale" Tauschbörsen für Musik und Filme angucke, läuft das anders.
S. R. schrieb: > Aber in der Realität macht man regelmäßig ein Update und fertig ist - > und genau diesen Schritt vereinfacht Cargo, wie auch jeder andere > Paketmanager. Oft macht man das Update sogar automatisch (für nightlies, > wann immer ein Update auftritt, etc.), der Sicherheit(slücken) wegen. du hast vollkommen recht - Rust Cargo erschafft durch die Einfachheit schneller diese Dependency Probleme (auch wenn es kein Autoupgrade gibt) aber was ist die Antwort auf das Problem? einfach niemals Package Systeme einsetzen? Ich finde der grossen Vorteil ist das ich lokal in meiner Firma mein eigenes Repository aufbauen kann (in das ich Prozess-Sicher update) und innerhalb meiner Firma ist dann eine "gewisse" Sicherheit da und ja wir alle arbeiten seit Jahren mit Dependencies und wissen wie das geht (von händischen bis selbst-gestricktem CMAke/Batch/Python Scripten ist alles probiert und im Einsatz) und welche Fallstricke lauern - aber trotzdem finde ich das man das Deployment irgendwie vereinfachen muss - auch wenn der aktuelle Cargo Stand vielleicht noch nicht perfekt ist finde ich das Cargo eine gute Diskussion-Grundlage bietet um diese Punkte für die Zukunft zu verbessern ganz unabhängig von der Sprache Rust
Mombert H. schrieb: > S. R. schrieb: >> Mombert H. schrieb: >>> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn >>> dort veröffentliche Software gegen geltendes Recht verstößt? >> >> Nein. Aber vor Gericht landet erstmal der Nutzer der Pakete, der dann >> wiederum crates.io auf Schadensersatz verklagen kann. Ich bin mir >> sicher, das Regelwerk von crates.io wird den Schaden dann an den Autor >> weiterreichen. > Du bist dir sicher? Basiert dein sicher auf deinem Bauchgefühl oder kann > man das irgendwo nachlesen? Also beide Teile, dass der Nutzer zuerst vor > Gericht landet und dass der Nutzer gegenüber der Plattform einen > Anspruch auf Schadensersatz hat. Wenn ich mir da z.B. "illegale" > Tauschbörsen für Musik und Filme angucke, läuft das anders. die Antwort ist dann einfach - man darf gar nichts machen, oder? also kein Cargo kein crates.io - die User müssen das 100% selbst machen Rechtssicherheit ist ein unklar handhabbares Thema das man nie abschließen sauber lösen kann - das ist auch jedem klar - tausend Probleme - aber als Lösung einfach gar nichts machen? was ist das Ziel deiner Kritik?
Microsoft managed in vcpkg auch tausend fremde Dependencies genau nach dem gleichen Schema wie crates.io und NPM ist mitlerweile auch von Microsoft - also noch viel mehr solcher Dependencies Ignorieren die deine Sorgen einfach nur deshalb weil die 1000 Anwälte drauf werfen können wenn es Probleme gibt? Einfache Frage: Was macht Microsoft anders als crates.io oder sind die einfach genau so unbedarft?
cppbert3 schrieb: > die Antwort ist dann einfach - man darf gar nichts machen, oder? > also kein Cargo kein crates.io - die User müssen das 100% selbst machen Das ist ein ziemlich weiter Bogen, den du von MaWins "man kann Pakete nicht löschen" zu "man darf garnichts machen" spannst. cppbert3 schrieb: > Rechtssicherheit ist ein unklar handhabbares Thema das man nie > abschließen sauber lösen kann - das ist auch jedem klar - tausend > Probleme - aber als Lösung einfach gar nichts machen? Darum ging es mir nie. Es ging immer nur um "man kann nichts löschen" cppbert3 schrieb: > was ist das Ziel deiner Kritik? Welche Kritik meinst du genau? cppbert3 schrieb: > Microsoft managed in vcpkg auch tausend fremde Dependencies > genau nach dem gleichen Schema wie crates.io > [...] > Einfache Frage: Was macht Microsoft anders als crates.io oder sind die > einfach genau so unbedarft? Ich wusste nicht, dass jeder auf vcpkg.io Pakete veröffentlichen kann. Kann man sie dort löschen?
cppbert3 schrieb: > -wie könnte eine "echte" Rust-ABI aussehen/was sind Herausforderungen > Kann es eine echte Rust-ABI geben oder wird das genau so ein Problem wie > mit C++ und dem nicht C-Rest? Ja, das ist ein sehr spannendes und sehr komplexes Thema, von dem ich leider viel zu wenig Ahnung habe, um einen qualifizierten Kommentar absondern zu können. :) Aus meinem Bauchgefühl heraus wird eine Library-ABI deutlich eingeschränkter sein müssen, als die statisch gebauten Crate-Schnittstellen. Ich gehe erst einmal davon aus, dass gar keine Compiletime-Ownershiptransfers stattfinden werden, sondern eher etwas zur Laufzeit wie Arc/RefCell(+threadsafety). Wenn du da eine funktionierende Lösung findest, hast du damit sicher das Jobticket direkt zu Google und Konsorten gewonnen. ;)
MaWin O. schrieb: > Wenn du da eine funktionierende Lösung findest, hast du damit sicher das > Jobticket direkt zu Google und Konsorten gewonnen. ;) funktionierend ist nicht das Problem - generisch und performant genug ist die Herausforderung
Mombert H. schrieb: > cppbert3 schrieb: >> Rechtssicherheit ist ein unklar handhabbares Thema das man nie >> abschließen sauber lösen kann - das ist auch jedem klar - tausend >> Probleme - aber als Lösung einfach gar nichts machen? > Darum ging es mir nie. Es ging immer nur um "man kann nichts löschen" aber was soll MaWin mit dieser Info anfangen - das wäre doch eher was für eine Diskussion mit den crates.io Leuten, oder? MaWin hat mehrfach und deutlich gesagt - es ist noch viel im Fluss - und ja nicht alles was crates.io/Cargo macht ist absolut perfekt - das kann keine Sprache/Environment sein und so hirnlos kann kein Entwickler sein um das zu glauben aber was du machst ist auf Details rumreiten - auch wenn du das so nicht wahrnimmst - und es ist nicht klar zu welchem Zweck du das machst MaWin juckt deine Argumentation null - und die crates.io/Cargo Leute hören sie nur wenn du sie auch dort vorträgst Selbst wenn du bei MaWin ein Umdenken erreichst hat das immer noch nichts mit der Rust Sprache an sich zu tun - und über die will er reden - nicht über die Infrastruktur (obwohl die Klarweise wichtig ist - aber eben hier und jetzt nicht relevant ist) und wenn du deine Crate/crates.io Problematik nicht gewillt bist an der richtigen Stellen vorzutragen ist das genauso nur verschwendete Zeit die crates.io Probleme/Strategien sind vollständig entkoppelt von Rust als Sprache - auch wenn sie sehr nahe zusammenstehen - aber ob crates.io das Prinzip genau so beibehält oder noch x mal ändert ist völlig ungewiss
cppbert3 schrieb: > funktionierend ist nicht das Problem - generisch und performant genug > ist die Herausforderung Ja, das ist mir schon klar. Das wollte ich damit ausdrücken. Aber wenn man die Möglichkeiten der ABI einschränkt, sehe ich jetzt nicht unbedingt, warum das ein Performanceproblem sein sollte. Alle anderen dynamischen Sprachmerkmale ((A)Rc/RefCell/trait-objects/...etc...) sind ja schließlich auch in der Regel kein Performanceproblem. Und wenn doch, dann muss man das Feature halt anders implementieren oder statisch linken. Ich würde das erst einmal als Sonderfälle kategorisieren.
Mombert H. schrieb: > MaWin schrieb: >> Nop schrieb: >>> Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt >> >> Qualität ist die Abwesenheit von Kundenreklamationen. > > Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik. You made my day! =DDDDDD
Beitrag #6942606 wurde von einem Moderator gelöscht.
Beitrag #6942639 wurde von einem Moderator gelöscht.
Beitrag #6942647 wurde von einem Moderator gelöscht.
Beitrag #6942657 wurde von einem Moderator gelöscht.
Beitrag #6942669 wurde von einem Moderator gelöscht.
Es gibt eine neue Version: https://blog.rust-lang.org/2022/01/13/Rust-1.58.0.html > Captured identifiers in format strings Sehr nett. Ein Schritt weiter in Richtung Python-style-f-strings. > More #[must_use] in the standard library Sinnvoll. Kann C++ das eigentlich auch? (ohne Compiler-Extension).
MaWin schrieb: >> More #[must_use] in the standard library > > Sinnvoll. Kann C++ das eigentlich auch? (ohne Compiler-Extension). Ja, mit dem Attribut
1 | [[nodiscard]] |
Siehe https://en.cppreference.com/w/cpp/language/attributes/nodiscard
:
Bearbeitet durch User
Mombert H. schrieb: >> Nein. Aber vor Gericht landet erstmal der Nutzer der Pakete, der dann >> wiederum crates.io auf Schadensersatz verklagen kann. Ich bin mir >> sicher, das Regelwerk von crates.io wird den Schaden dann an den Autor >> weiterreichen. > Du bist dir sicher? Basiert dein sicher auf deinem Bauchgefühl oder > kann man das irgendwo nachlesen? Also beide Teile, dass der Nutzer > zuerst vor Gericht landet und dass der Nutzer gegenüber der Plattform > einen Anspruch auf Schadensersatz hat. Für ungeeignete Nutzung von Software hat mein Arbeitgeber durchaus schon einige Klagen abbekommen (ob gerechtfertigt oder nicht weiß ich nicht). Ist halt ein einfaches Ziel. Wo die Software ursprünglich herkam, interessierte den Kläger (und die Rechtskosten) dafür erstmal nicht. Was den Schadenersatz angeht, so schrieb ich was von "verklagen kann", nicht von "Anspruch auf Schadensersatz". Vor Gericht und auf hoher See, und so. > Wenn ich mir da z.B. "illegale" > Tauschbörsen für Musik und Filme angucke, läuft das anders. In Deutschland gab es vor einigen Jahren ja große Abmahnwellen von diversen Anwaltsagenturen, und die gingen auch großflächig gegen die Nutzer und nicht gegen die Tauschplattformen. Zumal letztere ein großes Interesse daran haben, nicht rechtlich auffindbar zu sein... cppbert3 schrieb: > du hast vollkommen recht - Rust Cargo erschafft durch die Einfachheit > schneller diese Dependency Probleme (auch wenn es kein Autoupgrade gibt) > aber was ist die Antwort auf das Problem? einfach niemals Package > Systeme einsetzen? Abhängigkeiten reduzieren, soweit möglich und sinnvoll. Also nicht "viel hilft viel", wie das diese ganzen Paketmanager begünstigen (und vermutlich auch wollen, denn daraus folgt deren Existenzberechtigung). Wenn jede Abhängigkeit erstmal Aufwand ist, dann überlegt man vorher, was man tut. Nachdenken kostet Zeit, und wenn die Zeit durch die Prozesse hinreichend stark verkürzt wird, dann findet kein Nachdenken mehr statt. Das empfinde ich als ein Problem. Andere wahrscheinlich nicht, denn "der Genosse wird sich schon was dabei gedacht haben". > auch wenn der aktuelle Cargo Stand vielleicht noch nicht perfekt ist > finde ich das Cargo eine gute Diskussion-Grundlage bietet um diese > Punkte für die Zukunft zu verbessern Mit Cargo selbst habe ich keine Probleme, nur mit dessen Grundidee (die ebenso auch für alle anderen Paketmanager zutrifft; dass npm gelegentlich explodiert, dürfte in erster Linie an dessen extremer Verbreitung liegen). Mein Problem mit Rust heißt aber Cargo, weil das eben keine getrennten oder auch nur sinnvoll trennbaren Technologien sind. Genausowenig, wie systemd von dem, was dessen Autoren "systemd umbrella" nennen oder wie einen C-Präprozessor von einem C-Compiler. cppbert3 schrieb: > Ignorieren die deine Sorgen einfach nur deshalb weil die 1000 Anwälte > drauf werfen können wenn es Probleme gibt? Ich kann mir gut vorstellen, dass Microsoft solche Probleme allein deshalb ignorieren kann, weil sie einerseits genug Anwälte für eine kompetente Verteidigung haben und andererseits genug Anwälte und Technologien haben, um jeden, der sie plattmachen will, selbst plattzumachen. Das ist übrigens auch der Grund, warum Microsoft vor einigen Jahrzehnten anfing, alles was geht zu patentieren (vorher lehnten sie Patente ab und ließen auch eher nichts patentieren): Um damit Angreifer plattmachen zu können. > Einfache Frage: Was macht Microsoft anders als crates.io oder sind die > einfach genau so unbedarft? Der Unterschied zwischen crates.io, Github, npm oder irgendwas anderem ist... in der Hinsicht nicht vorhanden. Die sind allesamt nicht Primärziele, was die illegale Nutzung (im Hinblick auf die Lizenzbedingungen) angeht. Sie verbreiten allerdings die Software weiter, was ebenfalls ein Teil der Lizenzbedingungen ist - und das prüfen sie durchaus (oder sollten es im Eigeninteresse). Github tut das beispielsweise.
:
Bearbeitet durch User
S. R. schrieb: > einige Klagen abbekommen > Anspruch auf Schadensersatz > Abmahnwellen > Tauschplattformen > npm > C-Präprozessor > Microsoft > illegale Nutzung > Lizenzbedingungen Es geht hier im Thread um die Programmiersprache Rust.
MaWin schrieb: > Es geht hier im Thread um die Programmiersprache Rust. Ich habe auf mir gestellte Fragen geantwortet.
Eine neue Rust-Version ist raus: https://blog.rust-lang.org/2022/02/24/Rust-1.59.0.html Das neue Hauptfeature wird wohl für die meisten die Stabilisierung von inline-assembly sein. Aber auch available_parallelism ist ganz nett und man ist nicht mehr auf die Verwendung von externen Crates an dieser Stelle unbedingt angewiesen.
ich fand die Inline Assembler Syntax am Anfang doch ein wenig gewöhnungsbedürftig (im Vergleich zu VC Inline asm unter x86 (unter x64 geht das ja auch schon nicht mehr)) oder würde man damit auch z.B. solche mehrseitigen SIMD Sin/Cos Implementierungen wie z.B. in der glibc inline machen?
cppbert schrieb: > ich fand die Inline Assembler Syntax am Anfang doch ein wenig > gewöhnungsbedürftig (im Vergleich zu VC Inline asm unter x86 (unter x64 > geht das ja auch schon nicht mehr)) Ich habe mir die Rust-Asm noch nicht genauer angeschaut. Deshalb bin ich interessiert daran, welche Kritikpunkte du hast. Auf den ersten Blick sieht Rust-Asm ja sehr an Gnu-GCC-Asm angelehnt aus. Und die finde ich eigentlich ganz gut. Wenn man einmal die Constraints auswendig gelernt und verstanden hat. > oder würde man damit auch z.B. solche mehrseitigen SIMD Sin/Cos > Implementierungen wie z.B. in der glibc inline machen? Klar. Denke schon. Wozu auch sonst? Für Einzeiler gibt es oft Intrinsics.
Rustc-GCC kann sich nun selbst kompilieren: https://lwn.net/Articles/889989/ > so this work will eventually allow programs to be built for a number of architectures that are not supported by rustc
Carsten P. schrieb: > HabMut schrieb: >> C Programme beinhalten häufig vermeidbare Sicherheitslücken die die >> Sicherheit von IT Systemen gefährden. > > Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber > "sicher" keine sicherheitsrelevanten großen Systeme. Ich kenne genau > einen sehr versierten "plain C"-Entwickler, dem ich meine Bedürfnisse > nach einer Software anvertrauen würde, und der verwendet eine selbst > entwickelte GC, da ist nix mit malloc(). strcpy() und free(). Läuft seit > der ersten Version sogar auf S7-Steuerungen. GC in Purem C? Wozu C native auf S7? Zeig mal wie das geht bzw. wo das steht, daß es geht. Wäre mir neu. > > Traue keiner Runtime ohne verwaltetem Speicher! Und traue gar keinem > System ohne eine Runtime/einem Framework! Das gilt für Linux wie für > Windows wie für Android wie für iOS. Und wo ist der Sinn? Das ist alles Software und kann tierische Fehler enthalten. Also sollte man einem Betriebssystem schon mal nicht vertrauen, aber der Javaapplikation die darauf läuft schon?
Rust 1.60.0 ist raus: https://blog.rust-lang.org/2022/04/07/Rust-1.60.0.html Punkte, die ich interessant finde: - Source-based Code Coverage - (A)Rc::new_cyclic: Verbessert die Handhabung von zyklischen/selbstreferenzierenden Datenstrukturen. - Vec::spare_capacity_mut: Kann ein Effizienzgewinn sein, wenn doppelte Initialisierungen vermieden werden können. Benötigt aber wahrscheinlich in den meisten (allen?) Fällen auch eine Zeile unsafe-Rust.
MaWin schrieb: > - Source-based Code Coverage ich finde es sehr gut das solche Dinge sehr stark integriert werden (schön wäre jetzt noch ein sehr Kompiler/Toolchain naher Parser und Refactoring-Service/Lib/whatever den externe Tools nutzen können) Contra: -es fehlen sicherlich dann ein paar Features die in gcov/und anderen Tools vorhanden sind - aber wachsen kann es ja jederzeit Pro: -egal wie gut oder schlecht - es gibt einen Standard den alle rustc/cargo Nutzer gemeinsam haben -wer mit C/C++, Platform- und Compilerübergreifend viel mit Coverage zu tun hat wir sich freuen das es vielleicht möglich ist auf eine gut und immer funktionierende Lösung zu kommen
cppbert schrieb: > (schön wäre jetzt noch ein sehr Kompiler/Toolchain naher Parser und > Refactoring-Service/Lib/whatever den externe Tools nutzen können) > > Contra: > -es fehlen sicherlich dann ein paar Features die in gcov/und anderen > Tools vorhanden sind - aber wachsen kann es ja jederzeit Ich kann dir leider nicht ganz folgen. Rust coverage basiert auf den Standard-LLVM-Coveragetools. https://llvm.org/docs/CommandGuide/llvm-profdata.html https://llvm.org/docs/CommandGuide/llvm-cov.html
Dann ist eher die frage wie der gcc-rustc dann coverage implementieren wird und wie schnell sich die beiden compiler angleichen damit man beide gleich nutzen kann In der c/cpp Welt speziell unter Windows gibt es x Lösungen die inkompatibel sind und jede Lösung hat irgendeine andere schwäche die dann projektbezogen auftreten, eine einheitliche Lösung egal auf welchem backend basierend ist da ein grosser Gewinn
cppbert3 schrieb: > Dann ist eher die frage wie der gcc-rustc dann coverage implementieren > wird und wie schnell sich die beiden compiler angleichen damit man beide > gleich nutzen kann Ja. Aber die Frage ist dann eher: Was sind die Unterschiede zwischen LLVM und GCC, was Coverage angeht? Mit Rust hat das dann erst einmal wenig zu tun.
Carsten P. schrieb: > Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber > "sicher" keine sicherheitsrelevanten großen Systeme. Und wenn das Betriebssystem selber in C geschrieben ist? Und der Compiler, den du dazu nutzt, auch? Das soll es ja gerüchteweise geben ;) Oliver
Oliver S. schrieb: > Carsten P. schrieb: >> Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber >> "sicher" keine sicherheitsrelevanten großen Systeme. > > Und wenn das Betriebssystem selber in C geschrieben ist? Und der > Compiler, den du dazu nutzt, auch? Ja, es wird gerne vergessen, dass praktisch so gut wie jedes Programm, das auf einem Rechner läuft, auf einen Unterbau in C aufsetzt.
MaWin schrieb: > cppbert3 schrieb: >> Dann ist eher die frage wie der gcc-rustc dann coverage implementieren >> wird und wie schnell sich die beiden compiler angleichen damit man beide >> gleich nutzen kann > > Ja. Aber die Frage ist dann eher: Was sind die Unterschiede zwischen > LLVM und GCC, was Coverage angeht? Mit Rust hat das dann erst einmal > wenig zu tun. er geht mir nur darum das ich finde das Rust als Komplettpaket es schafft alle Entwickler Feature-Technisch an einen Tisch zu bringen - nicht das einfach technisch geht sondern auch dieser Vereinheitlichungscharakter
Rolf M. schrieb: > Oliver S. schrieb: >> Carsten P. schrieb: >>> Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber >>> "sicher" keine sicherheitsrelevanten großen Systeme. >> >> Und wenn das Betriebssystem selber in C geschrieben ist? Und der >> Compiler, den du dazu nutzt, auch? > > Ja, es wird gerne vergessen, dass praktisch so gut wie jedes Programm, > das auf einem Rechner läuft, auf einen Unterbau in C aufsetzt. Auch wenn die Replik inhaltlich richtig ist: ich sehe das ähnlich wie Carsten P. Ich verdiene zwar mein Geld mit (systemnaher) C-Programmierung, aber Userspace-Programme würde ich ohne Not heute nicht mehr in C schreiben wollen. Man will ja irgendwann auch fertig werden.
Rolf M. schrieb: > Oliver S. schrieb: >> Carsten P. schrieb: >>> Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber >>> "sicher" keine sicherheitsrelevanten großen Systeme. >> >> Und wenn das Betriebssystem selber in C geschrieben ist? Und der >> Compiler, den du dazu nutzt, auch? > > Ja, es wird gerne vergessen, dass praktisch so gut wie jedes Programm, > das auf einem Rechner läuft, auf einen Unterbau in C aufsetzt. das vergisst doch niemand hier in dieser Diskussion und das selbe haben vorher die Assembler-Programmierer gesagt als C eingeführt wurde, und davor noch die, welche Kabeln programmiert haben... Der Spruch kommt von den Java hatern, weil die VM ja auch auf C/C++ basiert - aber das trifft hier nur unzureichend weil Rust als Systemsprache mit C/C++ auf einer Ebenen steht es ändert nur nichts an den Pro-Argumenten für Rust - und es juckt niemanden ob die Pro-Argumente nicht für alle so gelten, sonst dürfte man ja gar nichts schreiben
cppbert schrieb: > Der Spruch kommt von den Java hatern, weil die VM ja auch auf C/C++ > basiert - aber das trifft hier nur unzureichend weil Rust als > Systemsprache mit C/C++ auf einer Ebenen steht Es ging darum, dass diese Aussage nicht stimmt: Carsten P. schrieb: > Kleine Tools kann man gerne auf jedem OS in C schreiben, aber > "sicher" keine sicherheitsrelevanten großen Systeme. Denn in der realen Welt setzt aktuell so gut wie jedes sicherheitsrelevante große System auf einen Kern in C auf.
Moin, Rolf M. schrieb: > Denn in der realen Welt setzt aktuell so gut wie jedes > sicherheitsrelevante große System auf einen Kern in C auf. Jepp. Und dann passieren halt auch noch z.b. so Schoten, dass es fuer polkit (BLFS-Book: "Polkit is a toolkit for defining and handling authorizations. It is used for allowing unprivileged processes to communicate with privileged processes.") eine javascript-engine braucht (also aktuell ein Teil der firefox-sourcen), die dann ihrerseits wieder ein rustc zum Bauen braucht... Und der ganze Kack mit ich-weiss-nicht-wieviel-LOC soll dann sicher sein? Gruss WK
Dergute W. schrieb: > polkit ´ > Und der ganze Kack mit ich-weiss-nicht-wieviel-LOC soll dann sicher > sein? Nein. Niemand mit Verstand behauptet, dass polkit gut und/oder sicher ist. Mit Rust - dem Thema des Threads - hat das allerdings nichts zu tun.
Wer etwas mehr über negative Aspekte von Rust und Cargo lernen möchte, ohne gleich in (falsche) Vermutungen und FUD abzudriften, dem kann ich diese Lektüre empfehlen: https://www.bunniestudios.com/blog/?p=6375
Release: Rust 1.61.0 https://blog.rust-lang.org/2022/05/19/Rust-1.61.0.html Es scheinen viele Detailänderungen eingegangen zu sein. Man kann jetzt recht komfortabel mit Termination einen Returncode von Main zurückgeben.
Achja. Und außerdem funktioniert endlich das AVR8-Target wieder mit der neusten nightly-Version.
Rust-Frontend kommt offiziell in die GCC https://www.golem.de/news/programmiersprache-rust-frontend-kommt-offiziell-in-die-gcc-2207-166831.html
Kaj schrieb: > Rust-Frontend kommt offiziell in die GCC Das ist ein ganz wichtiger Schritt. Ohne diesen Schritt ist die breite Verwendung besonders auf Nicht-PC-Plattformen nicht denkbar.
MaWin schrieb: > Kaj schrieb: >> Rust-Frontend kommt offiziell in die GCC > > Das ist ein ganz wichtiger Schritt. Ohne diesen Schritt ist die breite > Verwendung besonders auf Nicht-PC-Plattformen nicht denkbar. Aber da Rust ohne Cargo niemand verwendet, bringt das allein auch nicht viel. IMO ist Rust schon tot. Genau so wie Go. Kotlin lebt nur noch wegen Android Apps. Im prof. Embedded Umfeld kommen solche Hypes ohnehin nicht vor. Das ist was für Medieninformatiker mit Nebenfach Sportgymnastik.
:
Bearbeitet durch User
Cyblord -. schrieb: > IMO ist Rust schon tot. zum Glück haben sich ein paar Linux-Kernel Entwickler bereit erklärt die archivarische Aufgabe zu übernehmen - damit man später seinen Kindern noch was davon zeigen kann :)
Cyblord -. schrieb: > Aber da Rust ohne Cargo niemand verwendet, bringt das allein auch nicht > viel. Wo genau soll das Problem sein? Man wird Cargo (und alle anderen Tools und Programme) natürlich mit gccrs übersetzen können.
Es gibt ja immer noch keinen authoritativen standard, und stattdessen wird das clang verhalten dafür missbraucht. Machen gcc und clang was anders, macht es also per definition gcc falsch. Gcc ist deshalb dazu verdammt, per definition immer die verbuggte hinterherhinkende Version zu bleiben. Eine echte Alternative / Konkurrenz, kann es so nicht werden. Solange es keinen authoritativen standard gibt, ist das gcc ein rust frontend hat, also nur auf dem Papier was wert, in der Praxis aber irrelevant.
DPA schrieb: > Solange es keinen authoritativen standard gibt, ist das gcc ein > rust frontend hat, also nur auf dem Papier was wert, in der Praxis aber > irrelevant. Genau so, wie alle Python-Implementierungen irrelevant sind, weil es keinen "authorativen Standard" gibt?
MaWin schrieb: > alle Python-Implementierungen Mal von Micro-Python abgesehen, gibt es denn da überhaupt mehr als eine Implementierung?
Jörg W. schrieb: > Mal von Micro-Python abgesehen, gibt es denn da überhaupt mehr als eine > Implementierung? Dann google doch mal. Es gibt dutzende große Pythonimplementierungen.
MaWin schrieb: > DPA schrieb: >> Solange es keinen authoritativen standard gibt, ist das gcc ein >> rust frontend hat, also nur auf dem Papier was wert, in der Praxis aber >> irrelevant. > Genau so, wie alle Python-Implementierungen irrelevant sind, weil es > keinen "authorativen Standard" gibt? Ich weiß nicht wie das anderswo ist. In meinem Arbeitsumfeld ist nur CPython relevant. Ich kenne niemanden, der etwas anderes in seinen Produkten einsetzt. In den letzten Jahren wurden in mehreren Projekten sogar explizit mehrere andere Implementationen vom Kunden verboten.
MaWin schrieb: > Jörg W. schrieb: >> Mal von Micro-Python abgesehen, gibt es denn da überhaupt mehr als eine >> Implementierung? > > Dann google doch mal. > Es gibt dutzende große Pythonimplementierungen. "Other Implementations … Note that most of these projects have not yet achieved language compliance" Allerdings hat Python zumindest eine Language Reference: https://docs.python.org/3/reference/index.html einschließlich einer kompletten Grammatikdokumentation: https://docs.python.org/3/reference/grammar.html
Es gibt auch noch: https://peps.python.org/pep-0000/ Änderungen werden also nicht einfach nur in der Implementierung umgesetzt, sondern erstmal vorgeschlagen & diskutiert.
Daniel A. schrieb: > Änderungen werden also nicht einfach nur in der Implementierung > umgesetzt, sondern erstmal vorgeschlagen & diskutiert. Das ist bei Rust identisch. Bitte zurück zum Thema. Hier geht es um Rust. Jörg W. schrieb: > Note that most of these projects have not yet achieved language > compliance" Dummes Blah.
MaWin schrieb: >> Note that most of these projects have not yet achieved language >> compliance" > > Dummes Blah. Ah ja. Stammt halt nur aus dem Python-Wiki.
Jörg W. schrieb: > Stammt halt nur aus dem Python-Wiki. Aus dem C-Python-Wiki. Wieso sollte das eine verlässliche Quelle über den Zustand von anderen Implementierungen sein? Gib deine Rechthaberei bitte auf. Es gibt sehr viele komplette und stabile Python-Implementierungen. Ich zähle sie hier bewusst nicht auf, weil das Thema des Threads nicht Python ist und das jeder in Google finden kann.
MaWin schrieb: > Wieso sollte das eine verlässliche Quelle über den Zustand von anderen > Implementierungen sein? Weil auch von C-Python letztlich die Sprachdefinition stammt. Wenn ich jetzt einen Rust-Compiler schreibe und sage, er sei Rust compliant, würdest du das als verlässliche Quelle akzeptieren, nur weil ich das so sage?
Jörg W. schrieb: > Wenn ich jetzt einen Rust-Compiler schreibe und sage, er sei Rust > compliant, würdest du das als verlässliche Quelle akzeptieren, nur weil > ich das so sage? Ach komm. Das ist doch dummes Geschwätz. Du hast weder Ahnung von Python, noch von Rust. Das ist offensichtlich.
Du musst es ja wissen. Und nur, weil du dich jetzt aufregst, dass über Python diskutiert wird: das war dein Einwand.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > das war dein Einwand. Nein. Ich habe nur einen Vergleich gebracht. Dass ihr Knalltüten jetzt gleich Python in Frage stellt, hätte ich mir allerdings denken können. Dinge in Frage stellen, von denen man Null Ahnung hat, ist ja euer Hobby.
Du disqualifizierst dich soeben für jegliche ernsthafte Diskussionen. Rust tust du mit deinem Auftreten gewiss keinen Gefallen.
Jörg W. schrieb: > Rust tust du mit deinem Auftreten gewiss keinen Gefallen. Wie wäre es denn, wenn du mal wieder zum Thema zurückkommen würdest? Ich kann nicht sehen, wie ich Rust schade, wenn ich Unwahrheiten über Python richtigstelle.
MaWin schrieb: > Bitte zurück zum Thema. > Hier geht es um Rust. MaWin schrieb: > Genau so, wie alle Python-Implementierungen irrelevant sind, weil es > keinen "authorativen Standard" gibt? Hauptsache nicht an die eigenen Regeln halten ;-) MaWin schrieb: > Es gibt sehr viele komplette und > stabile Python-Implementierungen. Ich zähle sie hier bewusst nicht auf, > weil das Thema des Threads nicht Python ist und das jeder in Google > finden kann. Schön, dass es sie gibt, und dass du glaubst, dass sie komplett und stabil sind. Aber wer nutzt sie?
Jörg W. schrieb: > Mal von Micro-Python abgesehen, gibt es denn da überhaupt mehr als eine > Implementierung? Einfach mal Google benutzen und ein paar Minuten lesen, wenn man von einem Thema schon keine Ahnung hat, ist zu viel verlangt? Ja, es gibt einige. Auch Du kannst das herausfinden, wenn Du willst, trotz Deinem "Moderator"-Emblem. Jörg W. schrieb: > Ah ja. > > Stammt halt nur aus dem Python-Wiki. Wenn Du Dir schon fremde Aussagen zu eigen machst, wäre ein Zitat und ein Link auf die Quelle angebracht, findest Du nicht auch? Darüber hinaus, als ob irgendwelche halb-verwaisten Wikis eine besondere Relevanz hätten. Einfach auf den jeweiligen Projektseiten nachlesen, welchen Stand das jeweilige Projekt hat, übersteigt Dein Interesse? Jörg W. schrieb: > Rust tust du mit deinem Auftreten gewiss keinen Gefallen. Was hat das Verhalten eines Forumsbenutzer mit der Reputation von Rust zu tun? So viel wie Dein Verahlten hier mit der Reputation dieses Forums?
Experte schrieb: >> Stammt halt nur aus dem Python-Wiki. > > Wenn Du Dir schon fremde Aussagen zu eigen machst, wäre ein Zitat und > ein Link auf die Quelle angebracht, findest Du nicht auch? Weißt du, wofür die Anführungszeichen gut sind? Bestimmt nicht, um mir etwas "zu eigen" zu machen. Den Link kann man doch ganz einfach herausfinden, indem man das Zitat bei Google einkippt. Das ist die Methode, die ihr mir nahe gelegt habt. https://wiki.python.org/moin/PythonImplementations > Darüber hinaus, als ob irgendwelche halb-verwaisten Wikis eine besondere > Relevanz hätten. Was bringt dir das, auf so einem Niveau zu diskutieren? Habe ich (oder jemand anders hier) irgendwo die Projektseiten von Rust als "halb-verwaist" diffamiert? Leute, auf dem Niveau bedarf es wohl keiner weiteren Diskussionen.
Jörg W. schrieb: > Was bringt dir das, auf so einem Niveau zu diskutieren? Jörg, ich respektiere dich sehr als Experten auf dem Gebiet C und AVR-C. Aber von Rust und Python hast du offensichtlich leider keinerlei Ahnung. Das zeigst du hier leider sehr eindrucksvoll. Wenn hier über > Niveau geredet wird, dann solltest du es auch selbst einhalten. Effektiv zu behaupten von Python gäbe es nur eine einzige breit genutzte vollständige Implementierung, ist einfach nur lächerlich. Deine Aussagen hier beweisen nur, dass du noch nie mit Python und Rust gearbeitet hast, was über ein Hello World oder ein schnell dahingehacktes Script hinausgeht.
MaWin schrieb: > Effektiv zu behaupten von Python gäbe es nur eine einzige breit genutzte > vollständige Implementierung, ist einfach nur lächerlich. Ich habe getan, was du empfohlen hast, und danach gegoogelt. Da bin ich beim Python-Wiki rausgekommen, welches dann jemand hier als "halb-verwaist" diffamiert. Was soll das? > Deine Aussagen > hier beweisen nur, dass du noch nie mit Python und Rust gearbeitet hast, > was über ein Hello World oder ein schnell dahingehacktes Script > hinausgeht. Du irrst, gewaltig, was Python angeht. Über Rust habe ich nichts geschrieben.
MaWin schrieb: > Effektiv zu behaupten von Python gäbe es nur eine einzige breit > genutzte vollständige Implementierung, ist einfach nur lächerlich. Wir können uns darauf einigen, dass es eine (oder vielleicht zwei) Standardimplementation gibt sowie viele weitere, die nur in ihren Ecken des Internets verbreitet sind. > Deine Aussagen hier beweisen nur, dass du noch nie mit Python > und Rust gearbeitet hast, was über ein Hello World oder ein schnell > dahingehacktes Script hinausgeht. Deine Aussagen beweisen auch nicht viel mehr. Nur, dass du mehr Zeit für Diskussionen übrig hast. Merkt man z.B. an sowas: MaWin schrieb: > Dass ihr Knalltüten jetzt gleich Python in Frage stellt, hätte ich mir > allerdings denken können. Riecht nach unpassendem Diskussionsstil.
S. R. schrieb: > Wir können uns darauf einigen Nein. Weil es Quatsch ist. > Riecht nach unpassendem Diskussionsstil. Ich möchte überhaupt nicht über Python diskutieren, sondern hatte es nur als Vergleich angebracht. Und damit beende ich mein Mitwirken an der Python-Diskussion hier. Hier geht es um Rust.
MaWin schrieb: > Hier geht es um Rust. Nun gut, dann können wir ja auch wieder zum Anfang der Diskussion - diesmal ohne Python-Vergleich - zurückkehren: DPA schrieb: > Es gibt ja immer noch keinen authoritativen standard, und > stattdessen wird das clang verhalten dafür missbraucht. > Machen gcc und clang was anders, macht es also per definition > gcc falsch. Gcc ist deshalb dazu verdammt, per definition > immer die verbuggte hinterherhinkende Version zu bleiben. > Eine echte Alternative / Konkurrenz, kann es so nicht > werden. Solange es keinen authoritativen standard gibt, > ist das gcc ein rust frontend hat, also nur auf dem Papier > was wert, in der Praxis aber irrelevant. Also?
S. R. schrieb: > Also? Es ist halt völliger Unsinn. Keinerlei Begründung und ich soll jetzt die Gegenbegründung finden? Na gut. > stattdessen wird das clang verhalten dafür missbraucht. Kannst du es vielleicht mal ausführen, was "das clang-Verhalten" überhaupt sein soll? Was hat clang überhaupt mit Rust zu tun? Meinst du LLVM? Welche Teile von Rust sind nur so, weil LLVM das vorgibt? Und warum ist das ein Missbrauch? S. R. schrieb: > macht es also per definition gcc falsch Richtig. Wo ist das Problem? > immer die verbuggte [...] zu bleiben. Warum? Können GCC-Entwickler keine Bugs fixen? > Solange es keinen authoritativen standard gibt, > ist das gcc ein rust frontend hat, also nur auf dem Papier > was wert, in der Praxis aber irrelevant. Wie kommst du zu der Schlussfolgerung?
MaWin schrieb: > Wie kommst du zu der Schlussfolgerung? Hab ich doch schon asführlich aufgeführt. Das llvm rustc Ding ist authoritativ. Szenario: gcc und rustc machen was anders. Resultat: Per definition muss rustc der compiler sein, der es richtig macht, und gcc der Compiler, der den Bug hat. Die Programme werden natürlich auch das rustc verhalten voraussetzen. Ausserdem, jede Änderung und Erweiterung heist, dass beide Compiler was anders machen, also gcc was falsch macht. Wie man es auch dreht und wendet, gcc kann so nicht relevant werden, und kann niemals besser als clang sein, per definition. Wenn es nicht relevant werden kann, ist es in der Praxis irrelevant. Das folgt alles logisch daraus, dass das llvm rustc Ding authoritativ ist, und eben nicht ein Standard. Es ist im vornherein als perfekt festgelegt, und perfekter als perfekt kann man halt nicht werden. Ich hoffe, diesmal konntest du mir folgen. Ich habe die ganze logik Kette a also b also c, nochmal angegeben. Aber ich kann dich natürlich nicht zwingen, den Gedankengang nachzuvollziehen.
DPA schrieb: > Resultat: Per definition muss rustc der compiler sein, der es richtig > macht, und gcc der Compiler, der den Bug hat. Richtig. Wo ist das Problem? > Die Programme werden natürlich auch das rustc verhalten voraussetzen. Richtig. Wo ist das Problem? > Ausserdem, jede Änderung und Erweiterung heist, dass beide Compiler was > anders machen, also gcc was falsch macht. Richtig. Ansonsten implementiert GCC nicht Rust, sondern etwas anderes. Das können sie gerne machen, aber dann ist es nicht Rust. Gccrs wollen Rust implementieren. Wo ist das Problem? > gcc kann so nicht relevant werden Warum? Ich verstehe nicht, wie du das schlussfolgern kannst. Wenn gccrs 99% von rustc's Verhalten implementiert, dann sind sie relevant. Wieso sollten sie es nicht sein? > kann niemals besser als clang sein, per definition. (Was hat clang hier wieder zu suchen?) GCC kann nur besser sein, wenn sie etwas implementieren, was nicht Rust ist? Das ist gar nicht das Ziel von gccrs. Sie wollen Rust implementieren. > Das folgt alles logisch daraus, dass das llvm rustc Ding authoritativ > ist, Richtig. Wo ist das Problem? > Es ist im vornherein als perfekt festgelegt Nein, das ist nicht richtig. Rust enthält sehr viele nicht implementierte Dinge und auch viele undefinierte Dinge (unstable). Und das ist im Entwicklungsprozess ziemlich gut eingebettet. Bei diesen Dingen hat dann weder rustc noch gccrs "recht". Aber wenn gccrs Rust implementieren will, dann werden sie sich mit den rustc Entwicklern abstimmen müssen. Wo ist das Problem? > Ich hoffe, diesmal konntest du mir folgen. Leider nicht. Ich sehe nicht, wo hier der Nachteil bei gccrs sein soll und warum es deshalb zum Scheitern verurteilt sein soll. Nach deiner Logik dürfte es immer nur einen Standard und/oder eine Sprachimplementierung geben. Das ist doch Unsinn. In der Praxis sind die wenigsten Sprachen offiziell standardisiert. Trotzdem sind sie erfolgreich und es gibt oft mehrere Implementierungen. Ich glaube ihr habt eher Angst vor Umbrüchen und Neuem. Rust ist hier. Und es wird nicht wieder gehen, nur weil ihr die Augen verschließt. Gccrs ist ein weiterer wichtiger Schritt dieses zu manifestieren.
MaWin schrieb: > Ich glaube ihr habt eher Angst vor Umbrüchen und Neuem. Nein. Die Kritik ist nicht daran, dass es die Sprache gibt und dass Leute sie verwenden (ich kenne auch ganz persönlich jemanden, der davon begeistert ist). (Ja, es gibt hier auch Leute, die der Meinung sind, die würde nichts taugen. Ich gehöre nicht dazu, und auch die Kritik von DPA behauptet nicht sowas.) Die Kritik ist, dass sie es bis heute nicht geschafft haben, eine formale Definition aufzuschreiben. Es gibt eine "Reference", aber die schreibt gleich als erstes, dass sie "incomplete" ist, und eine formale Definition will sie gar nicht sein. So ist das alles irgendwie mit Beispielen beschrieben statt mit einer formalen Syntax. Auch steht da sowas drin: "Finally, this book is not normative. It may include details that are specific to rustc itself, and should not be taken as a specification for the Rust language. We intend to produce such a book someday, and until then, the reference is the closest thing we have to one." Das ist, was DPA meinte: rustc ist damit de facto das Normativ. Sicher war das auch mit C eine Weile so, dass es nur einen implementierten Compiler gab. Der war aber auch vor 50 Jahren (kannst du bei Dennis Ritchie nachschlagen) bereits begleitet von einer formalen Sprachbeschreibung. Es konnte also jemand anders nur auf Basis der Beschreibung einen eigenen Compiler (oder anderweitigen Parser) schreiben. Aus alldem konnte man schließlich (ja, hat auch eine Weile gedauert) einen wohldefinierten Standard ableiten. Nochmal: ich gehe durchaus davon aus (auf der Basis dessen, was ich von anderen gehört habe), dass die Sprache Potenzial hat. Aber wenn man eine Sprache implementiert, die eine gewisse Bedeutung bekommen soll, dann muss man sich auch dem formalen Kram widmen und nicht nur neue Features hacken. Python ist da (wie ich oben mal schrieb) weiter. OK, ist auch älter, ist akzeptiert.
Jörg W. schrieb: > Die Kritik ist, dass sie es bis heute nicht geschafft haben, eine > formale Definition aufzuschreiben. Ja gut. Das ist richtig. Damit reiht Rust sich in 99% aller Sprachen ein. Scheint wohl kein allzu großes Problem zu sein. Für welche Sprachen gibt es überhaupt eine offizielle Standardisierung? Python, Matlab. Alles Sprachen kurz vor dem Bankrott. Niemand verwendet sie. Denn sie haben ja keine offizielle Standardisierung. Unsinn. > Sicher war das auch mit C eine Weile so Ach? Das ist ja ein Ding. Und trotzdem ist C so erfolgreich? Wie kommt denn das? Ist ja völlig unmöglich. > Der war aber auch vor 50 Jahren Das ist ja ein Ding. Und jetzt rechne mal nach, wie alt moderne Sprachen wie Rust sind. Und dann rechne einmal nach, wann C seinen ersten Standard bekam. > dann muss man sich auch dem formalen Kram widmen Gut. Dann ist ja alles in Butter. Die Rust-Entwicklung ist einem starken formellen Prozess unterlegen. > und nicht nur neue Features hacken. Passiert nur in deine Fantasie. > Python ist da (wie ich oben mal schrieb) weiter. Unsinn. Befasse dich einmal bitte mit der Rust-Entwicklung, bevor du sie bewertest. Danke.
MaWin schrieb: > Für welche Sprachen gibt es überhaupt eine offizielle Standardisierung? Recht viele, auch wenn die nicht überall öffentlich von einem Standardisierungsgremium abgesegnet worden ist. > Python, Matlab. Alles Sprachen kurz vor dem Bankrott. Niemand verwendet > sie. Denn sie haben ja keine offizielle Standardisierung. Nun, das Debakel um Python 2 und Python 3 tat ihrer Beliebtheit nun ganz sicher nicht helfen (und wir hadern damit noch immer). Eine sehr bekannte Sprache, der ihre fehlende Standardisierung - und damit die normative Macht der Implementation - zum Verhängnis geworden ist, wäre Perl. So aus der Ferne sieht das bei PHP ähnlich aus, und beide Sprachen sind inzwischen mehr tot als lebendig. > Das ist ja ein Ding. Und jetzt rechne mal nach, > wie alt moderne Sprachen wie Rust sind. > Und dann rechne einmal nach, wann C seinen ersten Standard bekam. Die formale Definition von C ist wesentlich älter als ihr erster Standard. Und zumindest ich trenne auch noch zwischen der Standardbibliothek und der Sprachdefinition selbst, aber da gibt es sicher auch andere Ansichten. > Gut. Dann ist ja alles in Butter. > Die Rust-Entwicklung ist einem starken > formellen Prozess unterlegen. Und am Ende des Prozesses steht ein "der Compiler hat Recht".
S. R. schrieb: > Und am Ende des Prozesses steht ein "der Compiler hat Recht". Ziemlicher Quatsch. Wie wäre es, wenn ihr euch Rust und den Entwicklungsprozess einmal anschaut?
MaWin schrieb: > Jörg W. schrieb: >> Die Kritik ist, dass sie es bis heute nicht geschafft haben, eine >> formale Definition aufzuschreiben. > > Ja gut. Das ist richtig. > Damit reiht Rust sich in 99% aller Sprachen ein. > Scheint wohl kein allzu großes Problem zu sein. > > Für welche Sprachen gibt es überhaupt eine offizielle Standardisierung? Es gibt auch noch was zwischen kar keiner Definition der Sprache und einem ISO-Standard. > Python, Matlab. Alles Sprachen kurz vor dem Bankrott. Niemand verwendet > sie. Denn sie haben ja keine offizielle Standardisierung. Sie haben aber eine formale Definition. >> Python ist da (wie ich oben mal schrieb) weiter. > > Unsinn. Befasse dich einmal bitte mit der Rust-Entwicklung, bevor du sie > bewertest. Hier ist die formale Definition von Python: https://docs.python.org/3/reference/index.html Wo ist das Äquivalent für Rust?
:
Bearbeitet durch User
Rolf M. schrieb: > Hier ist die formale Definition von Python: > I chose to use English rather than formal specifications for everything except syntax and lexical analysis. This should make the document more understandable to the average reader, but will leave room for ambiguities. Consequently, if you were coming from Mars and tried to re-implement Python from this document alone, you might have to guess things and in fact you would probably end up implementing quite a different language. [...] If you would like to see a more formal definition of the language, maybe you could volunteer your time — or invent a cloning machine :-). "formale Spezifikation"
Jemand schrieb: > [...] Lustig, dass du gerade den Satz übersprungen hast: "On the other hand, if you are using Python and wonder what the precise rules about a particular area of the language are, you should definitely be able to find them here."
MaWin schrieb: > Damit reiht Rust sich in 99% aller Sprachen ein. Nein. > Für welche Sprachen gibt es überhaupt eine offizielle Standardisierung? Es ging nicht um offizielle Standardisierung, sondern wenigstens mal selbst eine formale Sprachdefinition aufzuschreiben. Python beispielsweise hat sowas, habe ich dir geschrieben. Es geht auch nicht um "kurz vor dem Bankrott", sondern darum, dass sowas eine sinnvolle Basis dafür ist, dass jemand anders eine unabhängige Implementierung vornimmt. Aber du drehst uns die Worte im Munde rum, für dich sind wir die Bösen, die nur das neue scheuen, nur weil wir nicht 100 % in deine Lobpreisung einstimmen. Das ist keine Diskussionsbasis.
Jörg W. schrieb: > nur weil wir nicht 100 % in deine Lobpreisung einstimmen. Meine Lobpreisung existiert nur in deiner Fantasie. Ich sehe durchaus die Schwächen von Rust und habe das auch schon mehrfach hier geschrieben. Und ja, das Fehlen einer vollständigen formellen Sprachdefinition ist ein Teil davon. Ich stimme euch lediglich nicht dabei zu, dass das ein riesiges Problem ist. > Python beispielsweise hat sowas, habe ich dir geschrieben. Das ist genau so unvollständig, wie die Dokumentation von Rust. Trotzdem ist Python extrem erfolgreich. Komisch, gell?
MaWin schrieb: > Ich stimme euch lediglich nicht dabei zu, dass das ein riesiges Problem > ist. Das Thema kam nur im Zusammenhang damit hoch, dass den Thread jemand wieder hochgeholt hat um zu erzählen, dass das jetzt in GCC drin ist. Für eine unabhängige Compiler-Implementierung ist es vielleicht nicht ein "riesiges" Problem, aber zumindest aus Sicht mehrerer Leute hier durchaus ein Problem. Um nicht mehr und nicht weniger ging es. > Das ist genau so unvollständig, wie die Dokumentation von Rust. Kann gut sein, aber es ist ein Anfang, den Rust (an der Stelle) sich noch nicht die Mühe gemacht hat zu gehen. Eine derartige Unvollständigkeit würde natürlich wiederum erklären, warum die Alternativ-Implementierungen teilweise eben auch in der Vollständigkeit hinter CPython hinterher hinken – womit indirekt bewiesen ist, dass eine fehlende saubere und vollständige formale Beschreibung eben für alternative Implementierungen durchaus ein Problem sein kann. Wie geschrieben: darum, ob die Sprache selbst nun gut oder schlecht oder brauchbar ist oder nicht, ging's hier gerade gar nicht.
Jörg W. schrieb: > aber es ist ein Anfang, den Rust (an der Stelle) sich > noch nicht die Mühe gemacht hat zu gehen. Das ist natürlich auch mal wieder Quatsch. Die Rust Features werden alle in Issues/RFCs beschrieben und entwickelt. Und es gibt auch Bücher, die diese Informationen zusammentragen. https://doc.rust-lang.org/stable/unstable-book/the-unstable-book.html https://rustc-dev-guide.rust-lang.org/getting-started.html https://doc.rust-lang.org/nomicon/
Jörg W. schrieb: > darum, ob die Sprache selbst nun gut oder schlecht oder > brauchbar ist oder nicht, Ach. Das ist ja ein Ding. Da muss ich mich wohl falsch erinnern. Mal sehen... Cyblord -. schrieb: > IMO ist Rust schon tot. Ach, wohl doch nicht.
MaWin schrieb: > Jörg W. schrieb: >> darum, ob die Sprache selbst nun gut oder schlecht oder >> brauchbar ist oder nicht, > > Ach. Das ist ja ein Ding. Da muss ich mich wohl falsch erinnern. > Mal sehen... Was schmeißt du fremde Zitate in meine Argumentation? Klar gibt es Doku, hat keiner bestritten. Aber der Ansatz, einen alternativen Compiler zu entwickeln, geht halt normalerweise nicht über das Studium von Prosa oder gar Sourcecode eines anderen Compilers, sondern über eine formale Sprachdefinition. Wenn es die nicht gibt, wird der alternative Compiler irgendwie immer der zweite Sieger bleiben. Mehr war hier nicht als Argumentation (wenn man von solchen Blasen absieht, wie du zitiert hast – ich weiß bloß nicht, warum du dich über solcherart begründungslos hingeworfene Meinungsäußerungen derart aufregst).
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Was schmeißt du fremde Zitate in meine Argumentation? Weil nicht nur du und ich an der Diskussion teilnahmen. Der zitierte Satz war der Ausgangspunkt der ganzen Diskussionskette, deren Teil auch du bist. > Aber der Ansatz, einen > alternativen Compiler zu entwickeln, geht halt normalerweise nicht über > das Studium von Prosa oder gar Sourcecode eines anderen Compilers, > sondern über eine formale Sprachdefinition. Offensichtlich geht es halt doch auch anders. > Wenn es die nicht gibt, wird der alternative Compiler irgendwie immer > der zweite Sieger bleiben. Für dich. Und das darfst du gerne so sehen. Ich sehe das anders. > ich weiß bloß > nicht, warum du dich über solcherart begründungslos hingeworfene > Meinungsäußerungen derart aufregst). Wo genau rege ich mich auf?
MaWin schrieb: >> Wenn es die nicht gibt, wird der alternative Compiler irgendwie immer >> der zweite Sieger bleiben. > > Für dich. > Und das darfst du gerne so sehen. > Ich sehe das anders. Du hast ja schon mehrfach (Auch gerade wieder im benachbarten Thread Beitrag "Komplexe typedef struct mit 0 initialisieren") gezeigt, dass du dich nicht wirklich dafür interessierst, wie die Sprache etwas definiert. Hauptsache der Compiler schluckt es.
Mombert H. schrieb: > Auch gerade wieder im benachbarten Thread Kannst du bitte aufhören hier den Thread zuzumüllen? Danke.
Wo kommt denn bitte diese ganze altmodische, absolutistische (Ein Standard, Ein Kompiler, Ein Entscheider) Denkweise her? Es ist doch keines der komplexen Systeme die wir heute verwenden so enstanden? Und der Entwicklungsprozess war deswegen nicht besser oder schlechter - das ist eben Evolution in komplexen Systemen - und dazu zählen auch Programmiersprachen bestes Beispiel die Programmiersprache(n): C/C++ - von der wir hoffentlich alle Wissen das sie einer doch noch immer einflussreichsten Sprachen der Welt ist Es gab über Jahrzehnte nur ein paar Player auf dem Kompilermarkt - Microsoft, GCC, Intel, ... die waren auch alle gar nicht so super kompatible - jeder hat sich so weit wie möglich am Marktstärksten (nicht unbedingt am Standard) orientiert, Microsoft hat Micro-Details in "sein" C++ eingebaut wo es nur ging das waren Jahrzehnte des unklaren driftens - da war die Frage immer erst "Mit welchem C++ Kompiler wurde das gebaut" Und wer die Erfahrung nicht gemacht hat weil zu Jung oder nicht in dem Business war kann hier so gut wie gar keinen Senf zu abgeben und das C++ Konsortium konnte das so gut wie nicht unter kontrolle halten dann kam der LLVM/Clang - das Geschrei war laut - "noch ein Kompiler, noch mehr Probleme, können wir uns nicht auf einen konzentrieren, Blababla..." aber es kam auch: -der LLVM/Clang wurde so gut das der GCC mal wieder kämpfen musste und wieder besser wurde -beide haben sich unglaublich beschleunigt in besserer Diagnose, Support von neueren Standards, weniger Sonderfeatures die wirklich nicht sind portierbar sind und,und,und -selbst Microsoft musste sich dem ganzen beugen und hat wieder richtig konstruktiv begonnen an der Sprache und dem Kompilern mitzuarbeiten das alles weil "nur" ein neuere Kompiler aufgetaucht ist - ohne Clang wäre das wohl alles nicht passiert niemand der offenen Auges durch die C/C++ Branche wandelt kann das nur im entfernsteten Bestreiten - die letzten Jahren sind wirklich erstaunlich weil endlich mal wieder richtige Evolution passiert ist - der geistige GCC "Fork" machte Konkurrenz und hat den Markt einfach mal wieder wach gerüttelt das ist typische evolutionäre Entwicklung wie sie für komplexe System nötig ist - das schadet nicht - dauert nur länger als wenn der einzge König/Firma/Konsortium von oben die perfekten Vorgaben macht - die Systeme sind viel zu umfangreich geworden als das so etwas nur noch im Ansatz sinnvoll funktioniert - und das haben alle Grossen der Branche schon lange verstanden und arbeite (Achtung Buzword) "Agil" an Lösungen - so lange bis sich der richtige Standard durch Leistung und Überleben herauskristalisiert, bis der auch wieder unrelevant wird die meisten Argumente sind völlig sinnfrei weil sich sowiso die Systeme durchsetzen die passen - ob UNS das dann immer passt ist eine andere Frage und ein Sprachstandard in der 1. Stunde hat auch Javascript nicht verhindern können :)
und die besten Flitzpiepen sind die welche Denken das sich Linus und Greg Kroah-Hartman und andere unbedacht eine Sprache in ihren Kernel holen die dann ihr Lebenswerk verschlechtert so Idioten-Argumente wie: -ob die wissen das Rust gar nicht mit dem gcc kompiliert werden kann -das Cargo dann alle Kernel-Dependecies dann aus dem Internet holen muss -man doch lieber go nehmen sollte usw. das ist so unglaublich naiv das es schon weh tut
cppbert schrieb: > das ist so unglaublich naiv das es schon weh tut So ist das halt, wenn man sich für den größten Sprachexperten der Welt hält. Da werden dann schon einmal gerne Sprachen totgesagt, die weltweit gerade steil gehen. Was dem Mikrocontroller.net-Experten nicht gut genug ist, kann auch nix sein. > -ob die wissen das Rust gar nicht mit dem gcc kompiliert werden kann > -das Cargo dann alle Kernel-Dependecies dann aus dem Internet holen muss Exakt dies. Diese zwei Fragen wurden vor Jahren bereits von den Kernelexperten diskutiert und verstanden.
oder jetzt wo der Linus das erstmal eine andere Programmiersprache für den Kernel präsentiert bekommt ist er blöderweise anr Rust geraten, der kann das bestimmt null einschätzen - die anderen beteiligten bestimmt auch nicht - die wurden bestimmt überredet, so hilflos... das ist mehr oder minder der überspitzte Inhalt der meisten Diskussionen - als hätten die Kernel-Entwickler so mehr oder minder zufällig ~30Mio Zeilen Code zusammengeschraubt die unsere Welte mehr oder minder am Laufen hält :)
MaWin schrieb: > Exakt dies. Diese zwei Fragen wurden vor Jahren bereits von den > Kernelexperten diskutiert und verstanden. dieses Argument schlägt alle Rekorde - es ist seit Jahren unrelevant weil man es machen kann wie man will - und die Kernel-Leute machen das auch so aber es kommt immer und immer und immer wieder hoch
Und der fehlende Sprachstand juckt Microsoft, Amazon und x andere null, nicht mal das GCC Steering Committee interessiert das
MaWin schrieb: > Wo genau rege ich mich auf? "Dummes Blah.", "ihr Knalltüten" – bestimmt findet sich noch mehr. Unterstellte Lernunwilligkeit: "Ich glaube ihr habt eher Angst vor Umbrüchen und Neuem.", obwohl man was ganz anderes kritisiert. cppbert schrieb: > Es gab über Jahrzehnte nur ein paar Player auf dem Kompilermarkt - > Microsoft, GCC, Intel Es gab deutlich mehr, du beschreibst nur die PC-Welt. Fängt ja schon damit an, dass C++ als erstes durch CFront implementiert worden war, initial völlig außerhalb der PC-Welt. Die anderen waren und sind auch nicht so schräg drauf wie beispielsweise Microsoft, die erst nach Jahrzehnten überhaupt mal einen neuen Standard akzeptieren können. Bis auf notwendigerweise nicht von einem Standard abdeckbare Dinge (wie Interrupts) konnte und kann man beispielsweise klaglos Programme für Microcontroller von GCC und IAR compilieren lassen. Die C++-Welt mag da mit ihrem Featurismus anders ticken, für C ist die Entwicklung eher langsam vonstatten gegangen. Aber natürlich, Entwicklung gab es immer, und der übliche Weg bei internationalen Standards ist es, dass das Standardisierungsgremium Dinge übernimmt, die sich bereits in der Praxis bewährt haben, statt sich Dinge selbst auszudenken. Trotzdem gab es da immer eine gemeinsame Basis, die recht gut beschrieben war und ist (und das auch schon vor dem ersten C-Standard, sonst hätte es beispielsweise einen GCC nie geben können – der kam zwei Jahre vor dem ersten offiziellen Standard heraus).
Jörg W. schrieb: > sonst hätte es beispielsweise einen GCC nie geben können – > der kam zwei Jahre vor dem ersten offiziellen Standard heraus Was? Das ist ja ungeheuerlich! Wie kann das sein? Das ist doch völlig unmöglich Compiler ohne Standard zu entwickeln, habe ich hier gelernt.
Jörg W. schrieb: > cppbert schrieb: > >> Es gab über Jahrzehnte nur ein paar Player auf dem Kompilermarkt - >> Microsoft, GCC, Intel > > Es gab deutlich mehr, du beschreibst nur die PC-Welt. Ja das hatte ich vergessen zu erwähnen, aber das ist ja auch ein grosser Teil des Markts > Die C++-Welt mag da mit ihrem Featurismus anders ticken, für C ist die > Entwicklung eher langsam vonstatten gegangen. Aber natürlich, > Entwicklung gab es immer, und der übliche Weg bei internationalen > Standards ist es, dass das Standardisierungsgremium Dinge übernimmt, die > sich bereits in der Praxis bewährt haben, statt sich Dinge selbst > auszudenken. Trotzdem gab es da immer eine gemeinsame Basis, die recht > gut beschrieben war und ist (und das auch schon vor dem ersten > C-Standard, sonst hätte es beispielsweise einen GCC nie geben können – > der kam zwei Jahre vor dem ersten offiziellen Standard heraus). Bei C ist das auch viel einfacher weil die Sprach recht ausdrucksschwach ist, ganz neutral ausgedrueckt Wenn es in der Praxis keine guten Lösungen gibt muss man sich neues ausdenken, auch wenn viele gar keine Probleme sehen die man angreifen sollte/könnte Es hört sich leider oft so an als würden hier viele glauben das ein zur zeit nicht bestehender Standard automatisch irgendwie zu Chaos führt der irgendwie nicht mehr kontrollierbar wäre, genauso wie ein zweiter Kompiler, das ist zu drastisch gedacht und Realitätsfern, wer sollte interesse an sowas haben und zu welchem Zweck (mal die Schattenregierung ausser vor gelassen) Wie gesagt das GCC Steering Comittee stört das gerade nicht sonderlich und viele andere auch nicht, wiso sind die nicht so kritisch?
cppbert3 schrieb: > auch wenn viele gar keine Probleme sehen die man angreifen sollte/könnte Das ist ungefähr der selbe Prozentsatz der auch keine Sanitizer braucht oder nutzt :)
cppbert3 schrieb: > cppbert3 schrieb: > >> auch wenn viele gar keine Probleme sehen die man angreifen sollte/könnte > > Das ist ungefähr der selbe Prozentsatz der auch keine Sanitizer braucht > oder nutzt :) Was nicht bedeutet das logische Fehler nicht auch ein grosser Teil der üblichen Fehler sind
MaWin schrieb: > Jörg W. schrieb: >> sonst hätte es beispielsweise einen GCC nie geben können – >> der kam zwei Jahre vor dem ersten offiziellen Standard heraus > > Was? Das ist ja ungeheuerlich! > Wie kann das sein? Das ist doch völlig unmöglich Compiler ohne Standard > zu entwickeln, habe ich hier gelernt. Du hast bis jetzt den Unterschied zwischen einer formalen Sprachdefinition und einem (irgendwie "offiziellen", ISO oder was auch immer) Standard noch nicht verstanden, obwohl dir nun bereits mehrere Leute versucht haben, diesen zu verdeutlichen. Dafür titulierst du andere als Knalltüten und was weiß ich nicht was.
Jörg W. schrieb: > Du hast bis jetzt den Unterschied zwischen einer formalen > Sprachdefinition und einem (irgendwie "offiziellen", ISO oder was auch > immer) Standard noch nicht verstanden, obwohl dir nun bereits mehrere > Leute versucht haben, diesen zu verdeutlichen. > Dafür titulierst du andere als Knalltüten und was weiß ich nicht was. Weil hier die Leute so auf Microdetails achten und dann darauf rumreiten Und nochmal das GCC Steering Committee stört es nicht, warum jemanden hier? Oder besser warum ist das nur hier ein Argument?
cppbert3 schrieb: > Oder besser warum ist das nur hier ein Argument? Ob das "nur hier" eins ist, weiß ich nicht. Ich habe auch keine Idee, was die GCC-Leute so bewegt und was sie als Kriterien für irgendwelche Frontends haben. Schätzungsweise wird die aktuell erlangte Popularität von Rust schon dazu beigetragen haben, das dort offiziell mit aufzunehmen.
Jörg W. schrieb: > Du hast bis jetzt den Unterschied zwischen einer formalen > Sprachdefinition und einem (irgendwie "offiziellen", ISO oder was auch > immer) Standard noch nicht verstanden, obwohl dir nun bereits mehrere > Leute versucht haben, diesen zu verdeutlichen. Ahh. Jetzt verstehe ich! Diese formale Sprachdefinition ist also der Teil, der eine erfolgreiche Sprache von einem Fehlschlag unterscheidet. Endlich erklärt mir das mal jemand. Jetzt solltet ihr das auch noch Mozilla, Linus, Microsoft und vielen anderen Stümpern erklären. > Dafür titulierst du andere als Knalltüten und was weiß ich nicht was. Ich bitte um Entschuldigung. Ich wusste bisher nicht, dass Mozilla, Linus, Microsoft und die vielen anderen Stümper in Wahrheit die merkbefreiten Knalltüten sind und nicht die Mitglieder des Mikrocontroller.net-Forums. cppbert3 schrieb: > Weil hier die Leute so auf Microdetails achten und dann darauf rumreiten So ist das nun einmal, wenn man sich mit der Materie nicht auskennt. Dann pickt man sich irgendein Detail raus und reitet darauf herum und erklärt den gccrs mal eben für gescheitert. Jörg W. schrieb: > Ob das "nur hier" eins ist, weiß ich nicht. Das kann ich dir auch nicht sagen. Aber für Mozilla, Linus, Microsoft und die vielen anderen Stümper, ist es offenbar kein Argument. Jörg W. schrieb: > Schätzungsweise wird die aktuell erlangte Popularität > von Rust schon dazu beigetragen haben Wie kam es überhaupt zu dieser Popularität? So ganz ohne formale Sprachdefinition.
Jörg W. schrieb: > cppbert3 schrieb: > >> Oder besser warum ist das nur hier ein Argument? > > Ob das "nur hier" eins ist, weiß ich nicht. Ich habe auch keine Idee, > was die GCC-Leute so bewegt und was sie als Kriterien für irgendwelche > Frontends haben. Schätzungsweise wird die aktuell erlangte Popularität > von Rust schon dazu beigetragen haben, das dort offiziell mit > aufzunehmen. gilt das deiner Meinung nach auch für den Linux-Kernel? Was sagt das über die Entscheidungsqualtät der an diesen Projekten beteiligten Personen aus?
MaWin schrieb: > Diese formale Sprachdefinition ist also der Teil, der eine erfolgreiche > Sprache von einem Fehlschlag unterscheidet. Du erzählst schon wieder völligen Unfug, um mal mit deinen Worten zu reden – vielleicht verstehst du so eine Sprache ja besser, denn keiner (von den ernsthaften Diskutanten) hat behauptet, dass Rust ein Fehlschlag sei. Mit dir zu diskutieren, erweist sich wiederholt schlicht als sinnlos, du drehst alles so herum, dass du dich maximal drüber aufregen kannst. Ich sollte meine Zeit besser darauf verwenden, was Vernünftiges zu tun, vielleicht endlich mal wieder VHDL anzusehen zum Beispiel. Das wäre mir beispielsweise aktuell wichtiger als Rust.
Und ja MaWin kann patzig sein, ihr seit das aber auch irgendwie, GUT IST
cppbert3 schrieb: > gilt das deiner Meinung nach auch für den Linux-Kernel? Beides dürfte miteinander im Zusammenhang stehen. Linux möchte GCC (während bspw. Apple extra den Clang gepusht hat, um von GCC wegzukommen), und für GCC ist es wiederum ein wesentliches Anwendungsfeld. ps: Andererseits ist natürlich für Linux ein anwendungsfähiger Compiler das wesentliche Kriterium, nicht irgendeine formale Sprachdefinition, das ist wohl keine Frage. Dürfte im Gegenzug den Druck auf GCC erhöht haben, sich der Sprache zu widmen.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > MaWin schrieb: > >> Diese formale Sprachdefinition ist also der Teil, der eine erfolgreiche >> Sprache von einem Fehlschlag unterscheidet. > > Du erzählst schon wieder völligen Unfug, um mal mit deinen Worten zu > reden – vielleicht verstehst du so eine Sprache ja besser, denn keiner > (von den ernsthaften Diskutanten) hat behauptet, dass Rust ein > Fehlschlag sei. Das sagt er nur überspitzt und alle anderen reagieren wieder mit Microdetails, das kann sehr wirklich nervig sein, was leider auch ein wenig typisch für das Forum ist
cppbert3 schrieb: > Das sagt er nur überspitzt Naja, andere würden es als sehr persönliche Beleidigung empfinden, wenn sie als "Knalltüten" bezeichnet werden, nur weil sie eine andere Meinung haben als er.
Jörg W. schrieb: > cppbert3 schrieb: > >> Das sagt er nur überspitzt > > Naja, andere würden es als sehr persönliche Beleidigung empfinden, wenn > sie als "Knalltüten" bezeichnet werden, nur weil sie eine andere Meinung > haben als er. Du machst es schon wieder, lass doch dieses Satz-Sezieren, das ist deiner unwürdig
Jörg W. schrieb: > du drehst alles so herum Ich verdrehe hier die Tatsachen? Sehr interessante Sichtweise. > dass du dich maximal drüber aufregen kannst. Wie bereits mehrfach gesagt: Ich rege mich hier überhaupt nicht auf. Ich amüsiere mich prächtig. > Du erzählst schon wieder völligen Unfug Ach. Sag bloß. Könnte das daran liegen, dass das nicht ganz ernst gemeint war und bewusst so formuliert war? cppbert3 schrieb: > Das sagt er nur überspitzt und alle anderen reagieren wieder mit > Microdetails, Du hast es gut erkannt. ;)
Jörg W. schrieb: > cppbert3 schrieb: > >> gilt das deiner Meinung nach auch für den Linux-Kernel? > > Beides dürfte miteinander im Zusammenhang stehen. Linux möchte GCC > (während bspw. Apple extra den Clang gepusht hat, um von GCC > wegzukommen), und für GCC ist es wiederum ein wesentliches > Anwendungsfeld. > ps: Andererseits ist natürlich für Linux ein anwendungsfähiger Compiler > das wesentliche Kriterium, nicht irgendeine formale Sprachdefinition, > das ist wohl keine Frage. Dürfte im Gegenzug den Druck auf GCC erhöht > haben, sich der Sprache zu widmen. Ich finde es wiederum erstaunlich wie wenig Frontend man nur braucht um ins main repo zu kommmen, aber trotzdem ist es gut, das wird schlussendlich eine Menge mehr Entwickler an die Sprache bringen, sie muss gequält werden damit was gutes entstehen kann
MaWin schrieb: > Jörg W. schrieb: > >> du drehst alles so herum > > Ich verdrehe hier die Tatsachen? Sehr interessante Sichtweise. Du musst aber auch mal aufhören Öl ins Feuer zu schütten :)
cppbert3 schrieb: > aber trotzdem ist es gut, das wird > schlussendlich eine Menge mehr Entwickler an die Sprache bringen, sie > muss gequält werden damit was gutes entstehen kann Genau so ist es. Alles dies wird passieren. Was garantiert nicht passieren wird ist das, was hier im Forum postuliert wird. Gccrs wird nicht die zweite unbedeutende Geige spielen. Gccrs wird nicht in endlosen Grabenkämpfen zu strict aliasing ertrinken. Es wird Meinungsverschiedenheiten geben. Und das ist etwas Gutes! Denn nur durch das Lösen von Meinungsverschiedenheiten kann wirkliche Weiterentwicklung entstehen. Das gilt auf für Forumsmitglieder. Die "guten alten Zeiten", wo man sich erst einmal um eine formale Sprachdefinition kümmerte, sind vorbei. Genauer gesagt, gab es diese Zeiten nie. Moderne Sprachen sind so komplex, dass es erst einmal wichtiger ist sie praktisch nutzbar zu machen, als irgendein furztrockenes Dokument zu erstellen, das niemandem weiterhilft. Und falls ihr dennoch der Meinung seid, dass man jetzt direkt eine Sprachdefinition braucht: Rust ist Open Source. Also bitte. Oder ihr müsst euch von dieser Denkweise lösen.
MaWin schrieb: > Gccrs wird nicht in endlosen Grabenkämpfen zu strict aliasing ertrinken. Dann bekommt der gcc auch mal endlich die Möglichkeit über x Versionen strict aliasing Fehler im Kompiler zu finden, genau so wie der LLVM leiden musste
cppbert3 schrieb: > das wird schlussendlich eine Menge mehr Entwickler an die Sprache > bringen Da vermute ich, dass der Einfluss von Linux größer ist als der von GCC. Den Leuten, die die Sprache benutzen wollen, ist das vermutlich mittelmäßig egal, solange es mindestens einen brauchbaren (und freien) Compiler gibt, die könn(t)en also auch ohne GCC prima damit arbeiten. Die Affinität zu einem bestimmten Compiler hat ja eher religiöse, äh, lizenzpolitische Gründe (Apple -> kein GPL, Linux -> unbedingt GPL).
Jörg W. schrieb: > Die Affinität zu einem bestimmten Compiler hat ja eher religiöse, äh, > lizenzpolitische Gründe (Apple -> kein GPL, Linux -> unbedingt GPL). Das schon aber sehr lange Zeit war der Kernel aber auch voll mit GCC Spezialitäten (so viel zu wohldefinierten Standards), ich glaube es ist immer nicht so einfach den Kernel mit Clang zu bauen, oder
MaWin schrieb: > Jetzt solltet ihr das auch noch Mozilla, Linus, Microsoft und vielen > anderen Stümpern erklären. Ich wäre gern die Fliege an der Wand, wenn du Linus ins Gesicht als Stümper bezeichnest... > Dann pickt man sich irgendein Detail raus und reitet darauf herum und > erklärt den gccrs mal eben für gescheitert. Gescheitert ist das falsche Wort. Aber der Einfluss - außerhalb von Linux - dürfte wesentlich geringer bleiben, bis es eine Spezifikation gibt. > Wie kam es überhaupt zu dieser Popularität? > So ganz ohne formale Sprachdefinition. Wie bei Javascript, ebenfalls eine der besten Programmiersprachen, die dieser Planet jemals hervorgebracht hat. Jörg W. schrieb: > Den Leuten, die die Sprache benutzen wollen, ist das vermutlich > mittelmäßig egal, solange es mindestens einen brauchbaren (und freien) > Compiler gibt, die könn(t)en also auch ohne GCC prima damit arbeiten. Viele Sprachen haben nur genau einen relevanten Compiler (bzw. alle anderen sind effektiv Forks - mangels gebrauchbarer Spezifikation) und sie werden trotzdem benutzt. Wer sich in die Abhängigkeit begeben will, den kann man daran nicht hindern. Suizid ist schließlich auch nicht strafbar. > Die Affinität zu einem bestimmten Compiler hat ja eher religiöse, äh, > lizenzpolitische Gründe (Apple -> kein GPL, Linux -> unbedingt GPL). Nicht nur, die Geldflüsse wären da auch zu betrachten. Wo das Geld in Massen hinströmt, da wollen alle anderen auch hin. Erstmal anstellen, wenn man eine Warteschlange sieht, egal warum.
cppbert3 schrieb: > Das schon aber sehr lange Zeit war der Kernel aber auch voll mit GCC > Spezialitäten (so viel zu wohldefinierten Standards), ich glaube es ist > immer nicht so einfach den Kernel mit Clang zu bauen, oder Der Kernel hat aber auch nie behauptet, in C geschrieben zu sein. Und er wird sicher auch nie behaupten, in Rust geschrieben zu sein. Aus den gleichen Gründen.
Jörg W. schrieb: > Den Leuten, die die Sprache benutzen wollen, ist das vermutlich > mittelmäßig egal, solange es mindestens einen brauchbaren (und freien) > Compiler gibt, die könn(t)en also auch ohne GCC prima damit arbeiten. Nein. Es gibt ganz praktische Vorteile von GCC. Beispielsweise das enorm viel breitere Spektrum an unterstützten Architekturen. Das bedeutet zwar nicht, dass Gccrs automatisch auch alle diese unterstützt, aber es bereitet die notwendige Basis dafür. Das ist der Schlüssel für Rust-Embedded. > Linux -> unbedingt GPL Die Bindung von Linux an GCC hat rein technische Gründe. Sie fußt in der enormen Nutzung von GCC-Extensions in Linux. Das Linux-clang-Projekt ist (war? Ich weiß den aktuellen Zustand nicht) ein enorm großes Projekt.
Achja, falls das hier manchen nicht klar ist: GCC + Rust gibt es in zwei Varianten. 1) Rust-Frontend in GCC. Darum ging es hier im Gespräch hauptsächlich. 2) GCC als codegen backend von rustc. Beide werden aktiv entwickelt und beide sind wichtig für die Sprache. (1) ist ein eigenständiges Projekt und (2) ist (wird) Teil vom ursprünglichen Rust-Compiler.
S. R. schrieb: > MaWin schrieb: > >> Jetzt solltet ihr das auch noch Mozilla, Linus, Microsoft und vielen >> anderen Stümpern erklären. > > Ich wäre gern die Fliege an der Wand, wenn du Linus ins Gesicht als > Stümper bezeichnest... Alles nur halb zu lesen ist hier echt Standard im Forum, es ging darum das Linus Rust im Kernel akzeptiert und da Rust ja nicht gut ist es nur an Linus schlechtigkeit liegen kann das er die Sprache akzeptiert Nur damit auch du es peilst: MaWin ist Pro Rust UND Pro Linux/Linus :)
S. R. schrieb: > cppbert3 schrieb: > >> Das schon aber sehr lange Zeit war der Kernel aber auch voll mit GCC >> Spezialitäten (so viel zu wohldefinierten Standards), ich glaube es ist >> immer nicht so einfach den Kernel mit Clang zu bauen, oder > > Der Kernel hat aber auch nie behauptet, in C geschrieben zu sein. > Und er wird sicher auch nie behaupten, in Rust geschrieben zu sein. > Aus den gleichen Gründen. Und mit diese Microrelevanzaussage konter ich jetzt wie?
cppbert3 schrieb: > ich glaube es ist immer nicht so einfach den Kernel mit Clang zu bauen Clang hat allerdings von vornherein überall versucht, ein kompletter GCC-Ersatz zu sein und von daher auch allerlei GCC-Erweiterungen übernommen. MaWin schrieb: > Es gibt ganz praktische Vorteile von GCC. Beispielsweise das enorm viel > breitere Spektrum an unterstützten Architekturen. Ja, sicher, aber die, die jetzt Rust einsetzen, werden das schätzungsweise vorranging auf solchen Architekturen tun, für die es llvm-Backends gibt. llvm-Backends gibt's ja schließlich auch für alles Mögliche inzwischen. Im "deeply embedded" (also echte Microcontroller, keine miniaturisierten Allroundmachinen wie Raspberry etc.) hat man ja schon Mühe, mal jemanden zu finden, der wenigstens C++ akzeptieren würde. Sehe ich in den diversen Jobs meiner letzten Jahre, selbst an Stellen, wo ein OO-Ansatz durchaus günstig wäre, findet man kaum Kundschaft, der das als Argument für C++ ausreichend ist. Bis Rust dort ankommt (und damit jenseits dessen, was llvm als Backends hat), wird noch 'ne Menge Wasser Rhein und Elbe herunter fließen.
MaWin schrieb: > Das Linux-clang-Projekt ist (war? Ich weiß den aktuellen Zustand nicht) > ein enorm großes Projekt. Interessanterweise schien bei FreeBSD der Aufwand doch recht überschaubar. Bei denen ist nun schon seit einigen Jahren Clang als Standard dabei – und ein Kernel hat logischerweise auch dort 'ne ganze Reihe von Compiler-Erweiterungen benutzt.
Jörg W. schrieb: > Clang hat allerdings von vornherein überall versucht, ein kompletter > GCC-Ersatz zu sein und von daher auch allerlei GCC-Erweiterungen > übernommen. Trotzdem hat es Jahre gedauert bis das richtig ging
Jörg W. schrieb: > und ein Kernel hat logischerweise auch dort 'ne ganze > Reihe von Compiler-Erweiterungen benutzt. Linux nutzt wesentlich mehr GCC-Spezialitäten als BSD. Linux verwendet auch GCC-Plugins. Die Grundfunktionalität (ein funktionierendes Linux-System) lässt sich schon länger mit clang erzeugen. Aber alle Features gingen zumindest bis vor ein paar Jahren noch nicht. Wie es aktuell ist, weiß ich nicht. Jörg W. schrieb: > Clang hat allerdings von vornherein überall versucht, ein kompletter > GCC-Ersatz Die Worte "überall" und "kompletter" würde ich hier weglassen und durch sowas wie "weitgehend" ersetzen. Selbst auf ABI-Ebene ist LLVM nicht vollständig kompatibel. (128Bit Integers). Was aber eher als ein Bug angesehen wird. Jörg W. schrieb: > Ja, sicher, aber die, die jetzt Rust einsetzen, werden das > schätzungsweise vorranging auf solchen Architekturen tun, für die es > llvm-Backends gibt. Auch für die Leute, die jetzt Rust einsetzen, bringt jeder weitere Compiler nur Vorteile. Second Source. Bessere Sprachdefinition. Bessere Testabdeckung. > llvm-Backends gibt's ja schließlich auch für alles > Mögliche inzwischen. Es kommt auch auf die Qualität der Backends an. Das AVR-Backend in clang ist nicht wirklich gut. Da will man GCC haben (Ja, das ist vielleicht ein schlechtes Beispiel, weil GCC-AVR auch nicht mehr wirklich weiterentwickelt wird. Aber besser als clang ist es). Jörg W. schrieb: > Bis Rust dort ankommt (und damit jenseits > dessen, was llvm als Backends hat), wird noch 'ne Menge Wasser Rhein und > Elbe herunter fließen. Das ist richtig. Aber das ist kein Problem, was Rust lösen kann. Das muss sich in den Betonköpfen der Nutzer-Projektentscheider lösen. C++ wäre ein Schritt in die richtige Richtung. Aber bitte mit wenig OOP. Sonst muss man die wieder abtrainieren, wenn man zu Rust wechselt ;)
MaWin schrieb: > Nein. Es gibt ganz praktische Vorteile von GCC. Beispielsweise das enorm > viel breitere Spektrum an unterstützten Architekturen. Das bedeutet zwar > nicht, dass Gccrs automatisch auch alle diese unterstützt, aber es > bereitet die notwendige Basis dafür. Alternativ portiert man diese Architekturen nach LLVM. Das ist wegen der GPL sowieso der bevorzugte Weg für viele Firmen, wenn sie den Aufwand überhaupt treiben wollen. > Die Bindung von Linux an GCC hat rein technische Gründe. > Sie fußt in der enormen Nutzung von GCC-Extensions in Linux. Ja und nein. Clang will aus lizenztechnischen Gründen ein vollwertiger Ersatz sein und implementiert daher auch alle relevanten GCC-Extensions. Technische Gründe gibt es daher keine mehr, und die politischen Gründe werden auch weniger, weil viel Geld in bestimmte Richtungen fließt. > Das Linux-clang-Projekt ist (war? Ich weiß den aktuellen > Zustand nicht) ein enorm großes Projekt. Sämtliche Android-Kernel werden ausschließlich mit Clang gebaut. Google hat außerdem die letzten Jahre sehr viel (erfolgreich) investiert, um die Unterschiede zum Mainline-Kernel zu reduzieren. Dazu kommt, dass so gut wie alle Mitstreiter am Kernel heutzutage dafür bezahlt werden. Ein großer Teil der betroffenen Firmen kommen aus dem Embedded-Bereich und dort ist Android-Kompatiblität wichtig. Also baut der Code auch mit clang (und dessen Forks) bzw. wird nur damit getestet. Das von dir genannte Projekt war vor allem deswegen kompliziert, weil (a) clang damals einige GCC-Extensions nicht kannte; (b) der Kernel nicht nur GCC-Extensions benutzt, sondern auch gezielt GCC-Verhalten ausgenutzt hat; (c) der Kernel "fix clang-issue"-Patches ablehnt, wenn sie keine Bugs fixen oder die Performance mit GCC sinkt. cppbert3 schrieb: > Nur damit auch du es peilst: MaWin ist Pro Rust UND Pro Linux/Linus :) Ich bin nicht doof. MaWin ist einfach nur der bessere Troll. :( cppbert3 schrieb: >> Der Kernel hat aber auch nie behauptet, in C geschrieben zu sein. >> Und er wird sicher auch nie behaupten, in Rust geschrieben zu sein. >> Aus den gleichen Gründen. > > Und mit diese Microrelevanzaussage konter ich jetzt wie? Warum willst du da kontern? Linux ist schlicht nicht in C geschrieben, sondern in (einem Subset von) GCC-C. Portabilität und Compilerabhängigkeit sind schlicht irrelevant. Clang implementiert auch GCC-C (identifiziert sich auch als GNU-C), weil Google (und andere) dafür gesorgt haben. Deswegen ist es trotzdem kein C, aber in der Lage, den Kernel zu bauen. Ich sehe keinen Grund, warum der Kernel das Thema Rust irgendwie anders handhaben sollte. Der Rust-Code im Kernel wird kein echtes Rust sein, sondern schlicht GCC-Rust (oder Kernel-Rust oder wie man das nennen mag). Inwieweit die auseinander laufen oder sogar inkompatibel zueinander werden, werden wir in der Zukunft sehen. Jörg W. schrieb: > Interessanterweise schien bei FreeBSD der Aufwand doch recht > überschaubar. Bei denen ist nun schon seit einigen Jahren Clang als > Standard dabei – und ein Kernel hat logischerweise auch dort 'ne ganze > Reihe von Compiler-Erweiterungen benutzt. FreeBSD (wie auch die Geschwister) hat ein eigenes Interesse, von GPL-Abhängigkeiten wegzukommen, nicht zuletzt durch Apple. Viel habe ich nicht in BSD-Code geblättert, aber was ich gesehen habe, hat mir im Allgemeinen recht gut gefallen und sah auch stärker nach Standard-C aus als der Linux-Code. Entsprechend dürfte die Abhängigkeit auch schwächer (besser abstrahiert) gewesen sein.
S. R. schrieb: > FreeBSD (wie auch die Geschwister) hat ein eigenes Interesse, von > GPL-Abhängigkeiten wegzukommen, nicht zuletzt durch Apple. Apple hat zwar mal den Anfang mit FreeBSD gemacht, aber macht seither sein eigenes Ding. Insofern ist FreeBSD (und insbesondere dessen verwendeter Compiler) für sie kaum relevant. Kommt hinzu, dass der Kernel eh Mach ist und kein BSD. > Viel habe ich nicht in BSD-Code geblättert, aber was ich gesehen habe, > hat mir im Allgemeinen recht gut gefallen und sah auch stärker nach > Standard-C aus als der Linux-Code. Entsprechend dürfte die Abhängigkeit > auch schwächer (besser abstrahiert) gewesen sein. Das ist gut möglich, hat durchaus auch historische Gründe. BSD wollte schon immer portabel sein (und NetBSD ist daraus entstanden, weil Bill Jolitz teilweise auf Portabilität verzichtet hatte, um auf der von ihm anvisierten 80386-Plattform besser/schneller voran zu kommen), der Code war damit auch vor 30 Jahren schon sehr generisch. Linux war erstmal nur 80386, und hat sich von da aus zu einem portablen System entwickelt. (Als ich vor Jahrzehnten mal in deren Floppytreiber geschaut habe, war beispielsweise sowas wie der DMA-Kanal fix per #define reincompiliert. In einem 386BSD hätte man auch damals schon mehr als einen Floppycontroller mit verschiedenen Hardwareparametern installieren können.)
Cyblord -. schrieb: > Die Komplexität in der SW Entwicklung entsteht nicht durch die > Programmiersprache. Die Sprache hat sogar entscheidenden Einfluss. Und weil die sprachbedingte Komplexität über die Jahrzehnte so ausartet wird kaum eine der genannten Sprachen richtig Zukunft haben. Die gehört schlicht anderer Hardware inklusive intelligenterer Programmierformen- um hier mal KI ins Gedächtnis zu rufen.
:
Bearbeitet durch User
Ron T. schrieb: > um hier mal KI ins Gedächtnis zu rufen. KI als Lösung zur Komplexitätsreduktion. Wow. Echt gut getrollt.
Steam macht einen echt netten Service für Skyrim. Die installierten Mods werden immer wieder "automagisch" auf den neuesten Stand gebracht. Diese Mods haben aber immer bestimmte eigene Probleme, da kann Steam nicht viel machen. Man ist gut beraten, jedes einzelne Mod für sich auszuprobieren, um fatale Veränderungen wirklich mitzubekommen. Viele bevorzugen aber ein 300 Mod Setup zum Start - aus welchem Grund auch immer - denn die "Vanilla" Version, also Skyrim ohne Mods ist schon toll. Mit vielen Mods als Standard kann man erstmal nicht so gut sehen, wenn man Probleme hat, wo sie herkommen. Dann gibt es noch in der normalen Vanillaversion gewisse Probleme, aber man kann einiges mit dem Creation Kit und den Glitches abfangen bzw. ausbügeln, und natürlich mit der ein oder anderen Modifikation. Klar, man hätte sich noch ein paar Runden Qualitätssicherungen gefreut - Aber das ist halt irgendwie auch die Handschrift von Bethesda, dass die Dinge so sind wie sie sind. Die Rust Entstehung ist interessant. Gehässigerweise könnte man fragen, ein neuer Lisp-Dialekt? Früher gab es mal f2c. Heute dann c2r? Fortran hat seine Stärken in der mathematischen Performance. C ist Systemnäher, Basic, die kleine Schwester von Fortran, war weniger systemnah, dafür aber fast überall verfügbar und man konnte es für viele Dinge einsetzen. Python ist gewissermaßen in die Fußstapfen von Basic getreten. Rein von der Werkzeug-Betrachtung her scheint Rust echt gut zu sein. Programmierkulturtechnisch: schwierige funktionale Programmierung. Es gibt auch die "Lösung" "Funktionalität" in C++ zu importieren. Stichwort: funktionale C++ Programmierung. Wenn man auf die 60er Jahre schaut, dann eierte die Funktionale Programmierung/Lisp und ähnliche immer so mit, spielten aber - auch bei der Parallelisierung - meist nur die 2. oder 3. Geige - oder noch weiter hinten. Das ist bei Rust ein wenig anders. Mit z.B. Haskell einen Compiler zu entwickeln - das ist eine wirklich sehr gute Möglichkeit, sowas zu tun. Nicht dumm.. Nach hinten raus steht immer noch die Frage im Raum, lieber in C++ machen, oder nicht? Ich denke, man sollte beides können. Grundsätzlich doof ist, wenn die funktionalen Hintergründe nicht verstanden werden. Es ist halt eine Übungssache. Und deswegen mag ich Haskell, obwohl es da z.B. mit dem ghc oder dem Drumherum (mal so mal so - wie denn jetzt?) oder der fehlenden Hardwarenähe auch recht problematisch zugeht. Beim Lernen stört das aber erstmal nicht so. Rust ist der pragmatische Ansatz. https://mariusschulz.com/blog/fast-searching-with-ripgrep
Auch wenn ich nicht ganz schlau draus werde was du mit dem Post sagen möchtest, ist er trotzdem irgendwie positiv Die starken Funktionalen Bezüge in deinem Post kann ich nicht zuordnen den Rust ist wie C, C++ und viele andere eine imperative Programmiersprache ohne Funktionale Basis
Hallo, cppbert3 schrieb: > ... den Rust ist wie C, C++ und viele andere eine imperative > Programmiersprache ohne Funktionale Basis Wie ist dann in https://de.wikipedia.org/wiki/Rust_(Programmiersprache) das Programmierbespiel zur Berechnung der Fakultät zu verstehen? Zitat: "Alternativ erlaubt es Rust, das Problem im Sinne der funktionalen Programmierung anzugehen. Sogenannte Iterators bieten eine Möglichkeit, iterierbare Objekte zu verarbeiten. So lässt sich die Fakultät mit Hilfe des Iterators (1..=i) und dessen Methode product()[31] wie folgt darstellen..." rhf
rbx schrieb: > Python ist gewissermaßen in die Fußstapfen von Basic getreten. Naja, meine These lautet: Der Erfolg von Python wird überbewertet. Python ist heute nur wegen Numpy und dem ganzen KI-Kram so populär. Und Numpy entstand weil in den 1990er Mathworks mit ihrer Lizenzpolitik zu Matlab durchdrehte. Zusätzlich kam später IPython aka Jupyter dazu. Damit verfestigte sich Python im akademischen Sektor, einer Nische. Da aus der akademischen Welt auch die Entwicklung KI und Maschinelearning getrieben wurde, wurde natürlich das dort benutzte Python als Scriptsprache dafür verwendet. Denn genau das ist Python nämlich: Eine Script-Sprache für Numpy und die ganzen Maschinelearning-Plattformen. Kaum einer wählt Python als Sprache für ein Projekt der Sprache selbst wegen, sondern weil er eben Numpy oder ein Maschinelearning-Paket benutzen will. Und die allermeisten Scripte die in diesem Bereich mit Python gebastelt werden, haben nur ein paar hundert Zeilen oder niedrige vierstellige Anzahl von Zeilen. Python ist der Nachfolger von Perl: Plattform für Wegwerf-Programme. Egal. Zurück zu Rust: rbx schrieb: > Programmierkulturtechnisch: schwierige funktionale Programmierung. Naja, die Masse muss erst funktionale Programmierung verinnerlichen. Bei OO war das nicht anders. Das hat auch Jahrzehnte gedauert, bis die "Hardcore-Imperativisten" in der Minderheit waren. Aber OO hat seinen Zenit weit überschritten. Natürlich hat OO ein Riesenmomentum, weil in der Zwischenzeit der Softwaresektor explodiert ist. Wenn man sich aber anschaut, wie die vielen Neulinge witzigerweise über Javascript mit funktionalen Paradigmen "infiziert" werden, und welchen Boom Haskell vor ca. 15 Jahren erfuhr, und wie dieser Boom z.B. C++ und andere Sprachen, darunter sicherlich auch Rust, danach beeinflusst hat, hat der Siegeszug der Funktionalen Paradigmen schon längst begonnen. Haskell ist toll, aber teilweise doch ziemlich akademisch und letztendlich für die Massenanwendung zu heftig. Und genau da breitet sich Rust nun aus. Rust ist (etwas) anspruchsvoller als viele aktuelle Massensprachen, aber ein merkliches Stück einfacher als z.B. Haskell. Das ist glaub ein gute Mischung. Irgendwo habe ich mal gelesen: Rust sei das Haskell für die Praxis, oder so ähnlich. Dem stimme ich zu 100% zu. Rust ist durch und durch eine imperative Sprache, allerdings lassen sich funktionale Konzepte und Paradigmen sehr gut damit verwenden bzw. umsetzen, weil es u.a. auch Summen-Datentypen hat. Fehlende Summen-Datentypen halte ich für das größte Manko vieler Sprachen. (Und es wird ja in immer mehr Sprachen versucht, das irgendwie nachträglich reinzubasteln. Selbst Python versucht es inzwischen irgendwie mit seinem Structural Pattern Matching.) Dazu, finde ich, ist bei Rust die Standardbibliothek außerordentlich gut gelungen. Ob es nun einen Standard in einer vergleichbaren Form zu einem beliebigen anderen Sprachstandard gibt, ist meiner Meinung nach nebensächlich. Es gibt immer verschiedene Anwendungsgruppen von Software-Technologie. Es gibt Gruppen die nehmen neue Entwicklungen sehr früh auf und setzen sie produktiv und gewinnbringend ein, und andere Gruppen warten, bis es für jeden Furz der Technologie 100 Seiten ISO-Spezifikation gibt. Diese Gruppen hinken immer Jahrzehnte der Entwicklung hinterher. Sie sind aber auch kein Innovatoren und für Entwicklungen in der Software-Branche völlig bedeutungslos.
Programmierer schrieb: > Python ist heute nur wegen Numpy und dem ganzen KI-Kram so populär. Das hat sicher auch meiner Meinung nach massiv dazu beigetragen. Aber ganz unabhängig davon ist natürlich der Interpreter, in dem man schnell mal einen Konstrukt eines größeren Scripts "vortesten" kann, ein sehr praktisches Hilfsmittel. Auch bei uns in der Industrie ist daher Python jenseits der Firmware ziemlich häufig im Einsatz. (Matlab sicher auch, aber mehr im tatsächlichen Mathematik-Umfeld.) C, C#, C++, Java, Rust :) macht an der Stelle keiner.
Rust erlaubt genau so wie C++ Funktional-artige Programmierung, aber Haskell ist Kilometer von Funktional-"artig" weg - Haskell ist vollwertig Funktional der Vergleich Rust und Haskell macht keinen Sinn - aber scheinbar gibt es hier welche die da eine Ähnlichkeit sehen, es ist aber trotzdem eine ganz andere Art der Programmierung, deswegen die nicht so hohe durchdringung des Marktes
Programmierer schrieb: > Damit verfestigte sich Python im akademischen Sektor, einer Nische. Einer Nische? Interessant. Programmierer schrieb: > Denn genau das ist Python nämlich: Eine Script-Sprache für Numpy und die > ganzen Maschinelearning-Plattformen. Kaum einer wählt Python als Sprache > für ein Projekt der Sprache selbst wegen, sondern weil er eben Numpy > oder ein Maschinelearning-Paket benutzen will. Und die allermeisten > Scripte die in diesem Bereich mit Python gebastelt werden, haben nur ein > paar hundert Zeilen oder niedrige vierstellige Anzahl von Zeilen. Worauf basiert diese Einschätzung? Ich kenne niemanden, der (nur) wegen numpy zu Python gewechselt ist. numpy hat nicht viele Vorteile gegenüber Fortran und vermutlich genauso viele Nachteile. Das deutlich wichtigere Python Projekt ist matplotlib.
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 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).
Mombert H. schrieb: > Programmierer schrieb: >> Damit verfestigte sich Python im akademischen Sektor, einer Nische. > Einer Nische? Interessant. Off-Topic-Alarm: Es geht hier um Rust, bleibt dabei
cppbert schrieb: > Es geht hier um Rust, bleibt dabei Gibt's denn ein Eispack/Linpack-Frontend in Rust?
Jörg W. schrieb: > Gibt's denn ein Eispack/Linpack-Frontend in Rust? Keine Ahnung. Das ist überhaupt nicht das Einsatzgebiet von Rust. Nimm Python. Rust ist eine Systems Programming Language.
Jörg W. schrieb: > cppbert schrieb: >> Es geht hier um Rust, bleibt dabei > > Gibt's denn ein Eispack/Linpack-Frontend in Rust? ich kenne nur https://nalgebra.org/ mit Lapack Bindings - keine Ahnung ob das was taucht
MaWin schrieb: > Keine Ahnung. > Das ist überhaupt nicht das Einsatzgebiet von Rust. > Nimm Python. > > Rust ist eine Systems Programming Language. Das würde ich jetzt nicht einfach so sage - warum sollte Rust dafür ungeeignet sein - als Sprache?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.