|
Anzeige
|
Rust - ist das hier um zu bleiben?
Gast
#7279212
Jörg W. schrieb: > Nur, wer braucht das? Wer etwas anders machen will, kann doch Rust > nehmen (oder Python oder …). Wie wäre es, wenn du dir das Video einmal anschaust, bevor du hier privilegiert trollst? Du hast die Frage nicht beantwortet. Aber willst du offenbar nicht. Da empfiehlt man nun schon mal, dass die Leute stattdessen doch lieber gleich was anderes machen sollten, isses dir auch nicht recht.
Gast
#7279368
Jörg W. schrieb: > Du hast die Frage nicht beantwortet. Wer diese Frage stellt, hat das Video nicht gesehen. Das ist offensichtlich. > Aber willst du offenbar nicht. Genau. Wozu auch? Die Frage hat gar nichts mit Rust oder dem Video zu tun. > Da empfiehlt man nun schon mal, dass die > Leute stattdessen doch lieber gleich was anderes machen sollten, isses > dir auch nicht recht. Ach. Du bist ja so großzügig. Du bist so ein großzügiger Troll, der hier nur nicht gelöscht wird, weil er Moderator ist. Soll ich dir mal was sagen? Hm? Gucke doch das Video. Wie wäre das? Dann weißt du auch, worum es geht, und dann musst du dich hier nicht immer weiter bis auf die Knochen blamieren. Peinlich, peinlich. MaWin schrieb: > Gucke doch das Video. Die 1,5 h Zeit würde ich, wenn schon, lieber in Rust investieren. Aber solange du einfach nur bei persönlichen Beschimpfungen bleiben willst, was soll's?
Gast
#7279551
@Jörg W. wenn es um C++2 geht - dann geht es eher darum das der Wechsel zwischen C++ und C++2 so absolut leicht und einfach sein soll wie möglich d.h. am besten 100% kompatibel - damit Firmen wie Microsft oder google die Mio/Mrd Zeilen von C++ haben leichter zwischen den Welten wandeln können ohne die geringsten Problem mit Kompiler/Toolchain etc. - bei solchen Codemengen, die ja täglich extrem wachsen sind auch mehrstufige Migrationen Richtung einfacher/fehlerfreier interessant die Leute müssen sich einfach mal die Dimensionen vorstellen: wenn 2000 oder mehr Entwickler an einem Codeberg arbeiten kann man teilweise im Sekundentakt die Repos wachsen sehen - das ist manchmal ganz schön beängstigen @MaWin: eine einfach kurze Antwort hätte gereicht - nicht jeder hier ist ein Troll und nicht alle sind einfach nur faul cppbert schrieb: > wenn es um C++2 geht - dann geht es eher darum das der Wechsel zwischen > C++ und C++2 so absolut leicht und einfach sein soll wie möglich d.h. am > besten 100% kompatibel Das ist mir durchaus beim Ansehen des Videos (und der ja teils euphorischen Kommentare) klar geworden. Ich fürchte trotzdem, dass das nicht viel bringt, und dass es sinnvoller ist, es so wie Firefox zu machen und stückweise Subsysteme neu zu implementieren. Dass das nicht von heute auf morgen gemacht ist, sieht man natürlich auch an Fifrefox.
Gast
#7279569
Jörg W. schrieb: > Ich fürchte trotzdem, dass das > nicht viel bringt, und dass es sinnvoller ist, es so wie Firefox zu > machen und stückweise Subsysteme neu zu implementieren. ja das Herb Sutter Beispiel ist ja nur ein Aufrüttler - was wäre wenn C++ sowas wie die Rust Editions hätte - was wäre möglich - Herb muss ja immer der am-weitesten-über-den-Tellerrand-schauer sein aber auch Carbon von Chandler Carruth ist nicht ganz uninteressant ich würde auch einfach neue Subsystem in Rust machen - aber ich muss auch keine 100Mio oder 2Mrd Zeilen Code unter Kontrolle halten - bei diesen Größenordnungen könnten Verbesserungen im niedrigen/sten Prozentbereich schon sehr viel bedeutung haben
Gast
#7279582
Jörg W. schrieb: > Das ist mir durchaus beim Ansehen des Videos (und der ja teils > euphorischen Kommentare) klar geworden. Ich fürchte trotzdem, dass das > nicht viel bringt, und dass es sinnvoller ist, es so wie Firefox zu > machen und stückweise Subsysteme neu zu implementieren. Das bestreitet niemand. Nicht einmal der Typ im Video. In einem Pony-Wunderland würde ich auch gerne mit dem Finger schnippen und alles in Rust neuschreiben. Aber das ist halt gar nicht das Thema. Das Thema war: Wie bringe ich moderne Eigenschaften von modernen Sprachen in C++ rein. Deine Antwort "nutze halt moderne Sprachen" ist in diesem Kontext Unfug. Eines der größten Probleme mit C++ ist, dass es nicht mit Altlasten aufräumen kann. C++ ist eine stinkende Müllhalde an legacy-Features, auf die oben drauf schön säuberlich leckere Früchte drapiert werden. Das ist der zentrale Punkt im Video. Das führt zwangsläufig dazu, dass neuer Schrottcode entwickelt wird, obwohl das verhinderbar wäre. Diesen Fakt kann man nicht einfach überbügeln mit: "Ja dann nutze halt Rust". Es muss dringend ein Umdenken passieren. Neue Software muss möglichst in neuen sicheren Sprachen entwickelt werden. Und bestehende Software muss Altlasten abwerfen. cppbert schrieb: > ja das Herb Sutter Beispiel ist ja nur ein Aufrüttler - was wäre wenn > C++ sowas wie die Rust Editions hätte - was wäre möglich - Herb muss ja > immer der am-weitesten-über-den-Tellerrand-schauer sein Das wurde als 'Epochs' bereits von Vittorio Romero vorgeschlagen und soweit ich mich erinnern kann mit großer Mehrheit vom Komitee abgelehnt. MaWin schrieb: > Eines der größten Probleme mit C++ ist, dass es nicht mit Altlasten > aufräumen kann. Eben deshalb halte ich das für keine sonderlich zielführende Idee, da noch weiter dran herum zu ändern. C++ hat sowieso schon eine Unmenge an Veränderungen in den letzten Jahrzehnten erfahren, dass da kaum einer noch durchblickt.
Gast
#7279629
Jörg W. schrieb: > Eben deshalb halte ich das für keine sonderlich zielführende Idee, da > noch weiter dran herum zu ändern. C++ hat sowieso schon eine Unmenge an > Veränderungen in den letzten Jahrzehnten erfahren, dass da kaum einer > noch durchblickt. Du scheinst das Video wirklich nicht geguckt oder verstanden zu haben. Anders ist das kaum zu erklären. Ich sehe einfach nicht, dass das die Welt retten würde.
Gast
#7279753
Zum Glück behauptet das ja auch niemand. Aber würde es sie verschlechtern? MaWin schrieb: > Aber würde es sie verschlechtern? Ist halt die Frage: wenn du Leuten noch weniger Anreiz gibst, stattdessen andere Sprachen in Erwägung zu ziehen, ist das dann schon eine Verschlechterung?
Gast
#7279793
Nein. Global ist das keine Verschlechterung, sondern eine Verbesserung. Und auch lokal ist es eine Verbesserung, wenn man in der Realität lebt, wo man eben eine riesige Codebasis hat, die niemand auf eine inkompatible Sprache umziehen wird. Das sind nun einmal Realitäten, mit denen wir leben müssen. Da ändert auch ein "Anreiz zur Migration" nichts dran. Im Ponyland. Ja. Dort wäre Cpp2 eine Verschlechterung. Ich lebe dort aber nicht. MaWin schrieb: > die niemand auf eine inkompatible Sprache umziehen wird Es geht ja nicht um "umziehen" (vor allem nicht sofort), ich hatte Firefox als Beispiel genannt.
Gast
#7279825
Jörg W. schrieb: > Es geht ja nicht um "umziehen" (vor allem nicht sofort) Ja doch. Genau darum geht es. Es geht darum bestehenden C++-Code mit Cpp2 zu übersetzen und Schritt für Schritt zu verbessern, bis man den Cpp2-only-Schalter umlegen kann. Die Rückwärtskompatibilität von Cpp2 ist Opt-In. Und dieses Opt-In würde man initial geben und Schrittweise zurückfahren. Ganz ähnlich, wie man das bei der Migration von C zu C++ tun kann. (Wie z.B. gcc es getan haben). Der Erste Schritt ist: Keine Codeänderung. Nur neuer Compiler. (Nur, dass es in C->C++-Fall keinen Opt-In-Schalter gibt). Und das geht eben mit einer inkompatiblen Sprache wie Rust gar nicht. Guck doch zur Abwechslung einmal das Video. MaWin schrieb: > Ganz ähnlich, wie man das bei der Migration von C zu C++ tun kann. (Wie > z.B. gcc es getan haben). Der Erste Schritt ist: Keine Codeänderung. Nur > neuer Compiler. C ist kein Subset von C++. C++ Leuten, die versuchen C zu schreiben, und die Sprache nicht kennen, mag es vielleicht so vor kommen. Aber echte C Programmierer kennen die Sprache und nutzen ihr Potential voll aus. Einfach einen C++ Compiler nehmen geht da erfahrungsgemäss nur selten. Zumindest bei meinem Code geht das eigentlich nie. Da habe ich sowohl Sachen, die in C++ gar nicht kompilieren würden, als auch solche, die in C wohldefiniert, und in C++ ub sind. Daniel A. schrieb: > C ist kein Subset von C++ Dann lass mal hören welche Teile von C nicht in C++ enthalten sind.
Gast
#7279842
Daniel A. schrieb: > C ist kein Subset von C++ In der Praxis halt schon. Die Unterschiede sind klein genug, um eine Compilermigration in den allermeisten Projekten mit minimalen Codeänderungen durchzuführen. Aber das ist hier off-topic. Das war nur ein Beispiel und ein Vergleich. Cyblord -. schrieb: > Daniel A. schrieb: >> C ist kein Subset von C++ > > Dann lass mal hören welche Teile von C nicht in C++ enthalten sind. https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B Cyblord -. schrieb: > Daniel A. schrieb: >> C ist kein Subset von C++ > > Dann lass mal hören welche Teile von C nicht in C++ enthalten sind. Da gibt es ganz elementare Sachen. z.B., wenn ich in C "struct bla" schreibe, dann ist nur "struct bla" definiert, aber bla nicht. Ich könnte dann sogar zeugs machen, wie "typedef int bla;", oder eine variable bla oder Funktion bla nennen, usw. Ein anderes Beispiel sind compound literale. Und bevor du jetzt sagst, "C++ hat die jetzt auch", die haben dort zusätzliche Einschränkungen. In C spielt es keine rolle, in welcher Reihenfolge ich die Dinger initialisiere. In C++ schon. Ein Klassiger sind auch die Cast regeln. "dingsbums* x = (dingsbums*)malloc(sizeof(*x));" ist in C ein absolutes noob no-go. Den cast lässt man gefälligst weg. Ein Beispiel für etwas, das nicht nur anders funktioniert, sondern es nur in C gibt: _Generic. Dann noch ein Beispiel, das in C gut funktioniert, aber in C++ ub ist:
Ich hätte noch mehr Beispiele, aber das dürfte fürs erste mal reichen. MaWin schrieb: > Es geht darum bestehenden C++-Code mit Cpp2 zu übersetzen und Schritt > für Schritt zu verbessern, bis man den Cpp2-only-Schalter umlegen kann. Ich habe nur meine Zweifel, dass just diese Organisationen mit riesigen C++-Codebasen die nötigen Ressourcen dafür aufzuwenden bereit sind. Denn es kostet Ressourcen, das alles durchzugehen. Das sehen wir doch schon an so einfachen Beispielen wie Compilerwarnungen über Mischen von signed und unsigned. Welches größere Projekt macht sich nachträglich die Mühe (die ja insbesondere auch irgendeine Finanzierung benötigt), sowas zu reparieren?
Gast
#7279885
Jörg W. schrieb: > Ich habe nur meine Zweifel, dass just diese Organisationen mit riesigen > C++-Codebasen die nötigen Ressourcen dafür aufzuwenden bereit sind. Denn > es kostet Ressourcen, das alles durchzugehen. Das sehen wir doch schon > an so einfachen Beispielen wie Compilerwarnungen über Mischen von signed > und unsigned. Völlig richtig. Und dann schlussfolgerst du, dass man stattdessen besser alles in Rust neuentwickeln soll? Das verstehe, wer will.
Gast
#7279892
DPA schrieb: > Rust - ist das hier um zu bleiben? Da Rust nun sehr alt ist, denke ich kann es weg! Daniel A. schrieb: > Ich hätte noch mehr Beispiele, aber das dürfte fürs erste mal reichen. Das ist denk ich der Punkt: Es ist nicht das eine große Feature, das in C++ fehlt, sondern viele Feinheiten, die es inkompatibel machen. Man muss auch bedenken, dass C++ ursprünglich mal C89 als Basis hatte. Inzwischen hat sich auch C weiterentwickelt. Vieles davon wurde in C++ auch nachgezogen, aber nicht alles, und auch nicht alles exakt gleich.
Gast
#7279920
Rolf M. schrieb: > Das ist denk ich der Punkt Nein. Der Punkt war, dass das nur ein Beispiel war. Ein Vergleich. Große Projekte haben diese Migration geschafft. Auch wenn die µC.net-Experten dies aufgrund der großen Unterschiede als praktisch unmöglich ansehen. Aber das ist nicht schlimm. Denn derzeit sind die Unterschiede zwischen Cpp2 und C++ noch genau 0, bei Compat-Opt-In. Die Situation bei C++->Cpp2 ist also noch besser, als bei C->C++. Und, nicht vergessen: Cpp2 ist ein Vorschlag. Eine Idee. Ein Verbesserungsvorschlag zur Inkrementellen Verbesserung des C++-Ökosystems. Es ist nicht: Ein fertiger Compiler. Ein Standard. Ein Zwang. Ein Keks. Ich finde es ist unbedingt notwendig C++-Altlasten über Bord zu werfen und trotzdem rückwärtskompatibel zu bleiben. Und das ist, was Cpp2 versucht vorzuschlagen und auch praktisch zu demonstrieren. Und das finde ich gut. Das ist ein wichtiger Schritt in die Richtung sicherer Sprachen, wie z.B. Rust.
Gast
#7279932
Ein wenig Rust-Soziologie: https://books.goalkicker.com Rust: A Language for the Next 40 Years - Carol Nichols https://www.youtube.com/watch?v=A3AdN7U24iU https://www.reddit.com/r/rust/comments/jb3ukm/we_need_to_talk_a bout_stackoverflow/ Richard Feldman — The Next Paradigm Shift in Programming https://www.youtube.com/watch?v=6YbK8o9rZfI (besonders spannend: die OO-Anfänge und Ideen. Viele Computer? großes Multirechnernetzwerk?) (Haskell Cabal/Stack, Rust Online - statt komplettes Offline-Packet zum Lesen und Arbeiten (auch für DOS) wie bei OpenWatcom.) https://de.wikipedia.org/wiki/Kognitive_Dissonanz#:~:text=Kognitive%20Dissonanz%20bezeichnet%20in%20der,Einstellungen%2C%20Wünsche%20oder%20Absichten). Da FP sehr abstrakt ist, braucht es eine ganze Weile bis es rutscht. Lerntechnisch ist es vielleicht hilfreicher für viele, C++ FP, oder JavaScriptFP oder Scala o.ä. zu nutzen. MaWin schrieb: > Rolf M. schrieb: >> Das ist denk ich der Punkt > > Nein. Der Punkt war, dass das nur ein Beispiel war. Ein Vergleich. > Große Projekte haben diese Migration geschafft. Natürlich ist die Migration machbar. Alleine schon die Wortwahl "Migration geschafft" zeigt aber doch, dass es doch etwas mehr ist als das Ersetzen von "gcc" durch "g++" im Makefile. Je nach Projekt kann der Aufwand zwischen relativ gering und sehr hoch variieren. Gemacht habe ich das auch schon, und dabei habe ich eben gemerkt, dass da der Teufel oft im Detail steckt. > Auch wenn die µC.net-Experten dies aufgrund der großen Unterschiede als > praktisch unmöglich ansehen. Das habe ich hier nirgends gelesen.
Gast
#7280017
Rolf M. schrieb: > Alleine schon die Wortwahl Ja, Rolf. Du hast Recht. In allen Punkten. Ich stimme dir voll und ganz zu. Was du sagst, ist die 100%ige Wahrheit. Das war lediglich ein Vergleich. Und du hast die Probleme bei diesem Vergleich sehr schön dargelegt. Ist es jetzt gut?
Gast
#7281628
Mal eine etwas andere Frage. C Compiler gibt es für 8086 Prozessoren zur genüge, die dann im 16 Bit Real Mode laufen und mit <= 640 KiB RAM auskommen. Wäre das auch mit Rust möglich, wenn man dafür einen Compiler entwickeln würde, oder ist dafür die Sprache schon zu komplex? Ja, man könnte den Code auch auf einer dicken Maschine compilieren, aber das ist hier nicht die Frage. Die Frage ist, ob ein Rust Compiler machbar wäre, der auf einem altem 8086 PC mit 640 KiB RAM läuft und zwar so, dass man nicht ständig auf der Festplatte Daten auslagern muss. Nano schrieb: > Die Frage ist, … was willst du damit? Fragt doch auch keiner nach einem C++-Compiler für CP/M. (Selbst C-Compiler für CP/M waren eher der Graus.) Nicht einmal GCC läuft auf diesem ollen Krempel. DJ-GCC lief nur im 32-Bit-Modus eines 80386.
Gast
#7281685
Jörg W. schrieb: > Nano schrieb: >> Die Frage ist, > > … was willst du damit? Ich will einfach nur wissen ob es bei der Komplexität von Rust ginge. Rust ist immerhin eine sehr moderne Sprache mit so Sachen wie Modulen. Während man sich bei C und C++ noch um Headerdateien anstatt Modulen abmühte. Einer der Gründe warum waren die Systemanforderungen für den Compiler. > Fragt doch auch keiner nach einem C++-Compiler für CP/M. (Selbst > C-Compiler für CP/M waren eher der Graus.) Typische CP/M Systeme hatten üblicherweise noch weniger RAM zur Verfügung. > Nicht einmal GCC läuft auf diesem ollen Krempel. DJ-GCC lief nur im > 32-Bit-Modus eines 80386. GCC nicht, aber dafür frühe Microsoft C und QuickC Versionen. Sowie sicherlich auch Turbo C und noch ein paar andere. Frühe Watcom C Versionen eventuell auch noch.
Gast
#7281816
Nano schrieb: > Die Frage ist, ob ein Rust Compiler > machbar wäre, der auf einem altem 8086 PC mit 640 KiB RAM läuft und zwar > so, dass man nicht ständig auf der Festplatte Daten auslagern muss. Ziemlich sicher nicht. Heutige Sprachen sind überhaupt nur möglich, weil genug Rechenleistung und Speicher für die Compiler zur Verfügung stehen. Auch modernes C kann man mit einem modernen optimierenden Compiler nicht auf einer 8086 mit 640k RAM compilieren.
Gast
#7282072
Nano schrieb: > Ich will einfach nur wissen ob es bei der Komplexität von Rust ginge. > Rust ist immerhin eine sehr moderne Sprache mit so Sachen wie Modulen. > Während man sich bei C und C++ noch um Headerdateien anstatt Modulen > abmühte. Einer der Gründe warum waren die Systemanforderungen für den > Compiler. nein sicher nicht - die Analyse braucht einfach zu viel Speicher - aber selbst C hat im Vergleich zu damaligen Assemblern schon viel mehr Resourcen gebraucht in den Anfängen von C mussten viele auch sicherliche ständig zwischen Disketten und Programmen wechseln um überhaupt was kompiliert zu bekommen aber als Cross-Compiler könnte es gehen - wenn jemand sich darauf konzentriert einen Optimizer dafür zu schreiben der dann auch ordentlich auf Realmode Segment/Offset Kram optimiert ist der aktuelle GCC IA 16 (https://github.com/tkchia/gcc-ia16) kann ja auch ordentlichen 8086 Code erzeugen und optimiert definitv besser als die Kompiler aus der Zeit und läuft sogar auf DOS - aber auch nur mit Extender und leider kein C++ :( cppbert schrieb: > aber selbst C hat im Vergleich zu damaligen Assemblern schon viel mehr > Resourcen gebraucht Üblich war eine Diskette mit den Tools, eine zweite mit den Dateien (Quellcode, Zwischendateien). Dauerte natürlich in der Tat ewig. Turbo-Pascal wurde seinem Namen dagegen gerecht, im Vergleich zu allen anderen Compilern der Zeit war es rasend schnell und brachte noch dazu die wohl erste IDE mit, die es gab. Im Vergleich zu heute dürfte die Optimierung nicht sonderlich großartig gewesen sein, aber für viele Fälle reichte es. Ich habe einen kompletten EPROMMer damit recht komfortabel bedient, nur die innere Schleife wurde dann durch handoptimierten Inline-Assembler ersetzt.
Gast
#7282604
cppbert schrieb: > Nano schrieb: >> Ich will einfach nur wissen ob es bei der Komplexität von Rust ginge. >> Rust ist immerhin eine sehr moderne Sprache mit so Sachen wie Modulen. >> Während man sich bei C und C++ noch um Headerdateien anstatt Modulen >> abmühte. Einer der Gründe warum waren die Systemanforderungen für den >> Compiler. > > nein sicher nicht - die Analyse braucht einfach zu viel Speicher - Danke für die Antwort. > aber > selbst C hat im Vergleich zu damaligen Assemblern schon viel mehr > Resourcen gebraucht > in den Anfängen von C mussten viele auch sicherliche ständig zwischen > Disketten und Programmen wechseln um überhaupt was kompiliert zu > bekommen Ja, das lag Anfangs aber an den Datenträgern. Mit Festplatten fiel das Diskette wechseln dann weg. Bliebe dann nur noch das Auslagern von Daten auf Festplatte während dem Compilevorgang von größeren Projekten. MaWin schrieb: > Ziemlich sicher nicht. > Heutige Sprachen sind überhaupt nur möglich, weil genug Rechenleistung > und Speicher für die Compiler zur Verfügung stehen. > > Auch modernes C kann man mit einem modernen optimierenden Compiler nicht > auf einer 8086 mit 640k RAM compilieren. Forth (2012) könnte vielleicht auf 8086 mit 640k RAM gehen. Auf die Schnelle habe ich dazu aber keine Infos gefunden, nur das gforth auf 386 läuft. https://gforth.org/ Supported systems i386 und Gforth EC(embedded) auch auf 8086. P.S. Das ist zwar off-topic. Aber das waren einige andere Beiträge vorher auch. :-) Frühe Compiler bestanden aus mehreren Einzelprogrammen, von denen jedes einen Teilschritt des Compiliervorgangs durchführte, weil man alles zusammen nicht gleichzeitig in den Speicher bekam. Das hat's natürlich auch nicht gerade schnell gemacht, weil die Zwischenergebnisse natürlich immer erst abgespeichert und dann wieder geladen werden mussten. So sind moderne Compiler aber nicht mehr aufgebaut, daher funktionieren die auf Systemen mit so begrenzten Ressourcen nicht.
Gast
#7282850
Rolf M. schrieb: > So sind moderne Compiler aber nicht mehr aufgebaut, daher funktionieren die auf > Systemen mit so begrenzten Ressourcen nicht. Jein. Auch bei den 2 rust compilern gibt es theoretisch noch object files. Aber ohne separate include Files mit dem Interface zeugs drinn muss der Compiler trotzdem die ganzen abhängigen quellen ansehen, und da kann schnell mal alles zusammen hängen. Kommt aber aufs selbe raus, finde ich nicht gut. Da können selbst moderate Systeme ganz schön ins schwitzen kommen. Der GCC kann übrigens auch noch pipes zwischen Compiler und Linker verwenden. So könnte man also theoretisch kompilieren und linken, ohne alles ins Dateisystem zu legen, und ohne alles auf einmal im RAM zu haben. Wobei, vermutlich bringt das heute auch nicht mehr viel, falls es überhaupt noch funktioniert... 🐧 DPA 🐧 schrieb: > Der GCC kann übrigens auch noch pipes zwischen Compiler und Linker > verwenden. Linker nicht, aber zwischen Compiler und Assembler. Präprozessor früher noch, aber das ist kein separater Prozess mehr. 🐧 DPA 🐧 schrieb: > So könnte man also theoretisch kompilieren und linken, ohne > alles ins Dateisystem zu legen, und ohne alles auf einmal im RAM zu > haben. Das ist beim gcc normal, siehe -save-temps Option. Wilhelm M. schrieb: > Das ist beim gcc normal, siehe -save-temps Option. -save-temps behält sie nur bei, erzeugt werden sie auch sonst. Aber das dürfte bei heutigen Betriebssystemen und Speichergrößen oft keine Rolle mehr spielen, weil die Zwischendateien im Cache bleiben. Windows ist allerdings mit vielen Dateioperationen spürbar langsam, und wenn man dann noch einen Virenchecker hat, der sich auch noch alle Zwischendateien ansehen möchte, dann hat man die Po-Karte gezogen. Moin, Jörg W. schrieb: > dann hat man die Po-Karte gezogen. Wenn du ein Po-Kartenspiel hast, und du ziehst eine Karte...Was erwartest du dann? ;-) scnr, WK Jörg W. schrieb: > Aber das dürfte bei heutigen Betriebssystemen und Speichergrößen oft > keine Rolle mehr spielen, weil die Zwischendateien im Cache bleiben. Bei *nix werden temporäre Dateien unter /tmp erzeugt, was typischerweise ein tmpfs o.ä. ist, für das keine Persistenz verlangt wird. Wilhelm M. schrieb: > Bei *nix werden temporäre Dateien unter /tmp erzeugt, was typischerweise > ein tmpfs o.ä. ist So typisch ist das nicht. Auf den Systemen, wo ich arbeite, ist es ein ganz normales Dateisystem (bzw. Bestandteil von /). Trotzdem geht es schnell, weil der Krempel noch komplett im RAM verfügbar ist, wenn die nächste Phase ihn wieder lesen will. Daher bringt -pipe nicht mehr so viel, wie das noch vor 20 Jahren der Fall war. Jörg W. schrieb: > So typisch ist das nicht. Dann sind Deine Systeme atypisch oder antiquarisch oder beides ;-)
Gast
#7283099
zurück zum Thema, Burschen! Du meinst, zur Frage, ob der Rust-Compiler auch temp files anlegt und ob man schneller wird, wenn man sie durch eine Pipe ersetzt? ;-) Gibt's eigentlich Geschwindigkeitsvergleiche zwischen *nix und Windows für den Rust-Compiler?
Gast
#7283127
Jörg W. schrieb: > Gibt's eigentlich Geschwindigkeitsvergleiche zwischen *nix und Windows > für den Rust-Compiler? Hinsichtlich der Installation mit Sicherheit ;)
Gast
#7283549
Rolf M. schrieb: > Frühe Compiler bestanden aus mehreren Einzelprogrammen, von denen > jedes > einen Teilschritt des Compiliervorgangs durchführte, weil man alles > zusammen nicht gleichzeitig in den Speicher bekam. Das hat's natürlich > auch nicht gerade schnell gemacht, weil die Zwischenergebnisse natürlich > immer erst abgespeichert und dann wieder geladen werden mussten. Das ist richtig. Präprozessor Compiler Assembler Linker und gegebenenfalls noch EXE2BIN (war Bestandteil von MS-DOS, wurde manchem MS Compiler aber auch mitgeliefert) > So sind > moderne Compiler aber nicht mehr aufgebaut, daher funktionieren die auf > Systemen mit so begrenzten Ressourcen nicht. Das ist korrekt. Bei LLVM wird sogar Bytecode für eine eigene CPU Maschine erzeugt und aus dem Bytecode wird dann erst der eigentliche Maschinencode für die Ziel CPU erstellt. Der Vorteil: Alle Sprachen generieren den Bytecode und aus diesem einen unified Bytecode kann man dann den eigentlichen Maschinencode für die Ziel CPU erstellen. Damit muss man die Arbeit für eine bestimmte Ziel CPU nur einmal machen und man kann alle Sprachen für diese nutzen. Umgekehrt gilt das gleiche. cppbert schrieb: > zurück zum Thema, Burschen! Ok, zweiter Versuch: Was kann Rust besser als Forth? https://gforth.org/ :-)
Gast
#7283623
Nano schrieb: > Bei LLVM wird sogar Bytecode für eine eigene CPU Maschine erzeugt Um noch einmal zum Thema des Threads zurück zu kommen: Bei Rust gibt es nicht nur einen solchen Zwischenschritt (IR), sondern mehrere: https://blog.rust-lang.org/2016/04/19/MIR.html Nano schrieb: > Präprozessor > Compiler > Assembler > Linker > und gegebenenfalls noch > EXE2BIN (war Bestandteil von MS-DOS, wurde manchem MS Compiler aber auch > mitgeliefert) Ich beziehe mich nur auf den Teil "Compiler". Dieser wurde in mehrere als getrennte Programme ausgeführte Einzelschritte zerlegt, wie z.B. lexikalische Analyse, Syntaxanalyse, Codegenerierung. MaWin schrieb: > Bei Rust gibt es nicht nur einen solchen Zwischenschritt (IR), sondern > mehrere: Wobei das jetzt eher ein Implementierungsdetail denn ein Sprachfeature sein dürfte, oder? Trifft man außerdem auch bei anderen Sprachen an. Lass mal den GCC mit -fdump-rtl-all laufen und erfreu dich dann an mehreren Dutzend Dateien, die die einzelnen Zwischenstufen repräsentieren. ;-)
Gast
#7283736
Jörg W. schrieb: > Wobei das jetzt eher ein Implementierungsdetail denn ein Sprachfeature > sein dürfte, oder? Bitte einfach einmal den verlinkten Artikel lesen. > Trifft man außerdem auch bei anderen Sprachen an. Ach. Wer hätte es gedacht. Habe ich ja auch nie in Frage gestellt. MaWin schrieb: > Um noch einmal zum Thema des Threads zurück zu kommen: Also doch wieder off-topic. "anderen Sprachen"... MaWin schrieb: > Bitte einfach einmal den verlinkten Artikel lesen. Ändert nichts dran, dass da Implementierungsdetails beschrieben werden.
Gast
#7283814
Jörg W. schrieb: > Ändert nichts dran, dass da Implementierungsdetails beschrieben werden. Genau so sieht es aus. Das Lesen hätte des Artikels hätte die Frage beantwortet, bevor du sie hier gestellt hast.
Gast
#7284013
MaWin schrieb: > Also doch wieder off-topic. > "anderen Sprachen"... Was willst du denn immer mit deinem "offtopic"? Wir sind hier nicht irgendwie Sprachdesigner von Rust, sondern es geht darum, welche Zukunft die Programmiersprache und seine Bereitstellung/Logistik/Schulung usw. hat. Beispielsweise, warum kann man Rust nicht einfach wie D auf Windows installieren? D braucht nur einen kleinen Ordner, und man kann sofort damit arbeiten, ganz easy. Nicht wirklich schwieriger als eine Tiny C Installation. Den oben verlinkten Artikel solltest du mal ausdrucken. Wenn man das macht, hat man schon einen halben Arztroman zusammen. Die FP Programmierung muss man (lange) pauken, wenn man nicht irgendwie mit Lisp (+ Emacs) groß geworden ist. Für Haskell braucht man eigentlich nur Notepad oder Papier und Bleistift. Aber so richtig gut unter Windows funzt der GHC bzw. die Haskell Plattform auch nicht, ziemliches Gewürge bei der Installation, und dann auch noch pingelig hinsichtlich der Windows-Version. - so dass man Haskell dann noch lieber auf Linux nutzen möchte. Bei Rust ganz ähnlich. Darüber sollten sich diese Rustentwickler mal ein paar Gedanken machen. D oder Tiny C sind diesbezüglich einfach viel besser, trotz der eingeschränkten Ressourcen. Und: Java? Java ist das abschreckende Beispiel bestimmter Entwicklungen. Python ja irgendwie auch - aber da gibt es wohl Wege, damit besser klarzukommen. Und Idris? Was soll ich mit Idris, ich möchte mit Haskell arbeiten. Ach sch..
Gast
#7284055
rbx schrieb: > Was willst du denn immer mit deinem "offtopic"? Weil es hier um Rust geht. Nicht um Haskell oder sonstige Sprachen. Damit ist 90% deines Beitrags wieder einmal off-topic. > Beispielsweise, warum kann man Rust nicht einfach wie D auf Windows > installieren? Du musst ein Exe herunterladen und doppelt draufklicken. Viel einfacher kann es nicht werden.
Gast
#7284098
Man nennt das über den eigenen Tellerrand schauen. Aber das kann man nach Rust ja nicht mehr...
Gast
#7285477
MaWin schrieb: > Du musst ein Exe herunterladen und doppelt draufklicken. > Viel einfacher kann es nicht werden. (nightly Build): Falsche Windowsversion..
Gast
#7285735
rbx schrieb: > (nightly Build): Falsche Windowsversion.. Was heißt das auf Deutsch?
Gast
#7285759
MaWin schrieb: > Was heißt das auf Deutsch? Das heißt, dass Tiny C oder D viel einfacher zu installieren sind. Einfach downloaden, eventuell noch auspacken, fertisch. Bei Rust: Warten, ...warten...warten...und wenn dann (so nach 30 Min) der Ordner fertig ist, z.B. könnte man diese Buch.exe anklicken und dann.. "Dieses Programm kann kann nicht auf Windows ausgeführt werden" - oder so ähnlich - typischerweise heißt das: Inkompatibles Windows. (-> lächerlich) (Und groß VS Studio vorher zu installieren, das dauert auch ziemlich lange und verbraucht ziemlich viel Speicherplatz. Warum nicht was mit mingw?) Wiederum lächerlich zu Tiny C, D, oder von mir aus auch Hugs. ( https://www.heise.de/download/product/hugs-98-40452 ) Hugs verarbeitet übrigens auch (im Gegensatz zum GHC) Literate-Programming. Schöne Sache. ( https://steamcommunity.com/app/252490/discussions/0/1745646819954096664/ )
Gast
#7285763
Troll bitte woanders. Das ist ganz offensichtlich ausgedachter Quatsch. Und das kann jeder nachprüfen, indem er selbst Rust installiert. Also was soll das?
Gast
#7285950
MaWin schrieb: > Und das kann jeder nachprüfen, indem er selbst Rust installiert. > Also was soll das? Auch jemand, der Windows 8.1. hat, oder XP oder Me? Das würde mich echt mal interessieren. Wenn hier einer trollt, dann kommt das von einem, der hier Rust lobpreist, obwohl noch vieles im Argen ist. Scheint ja für diesen Typen einfacher zu sein, mehr auf die Persönlichkeitseigenschaften zu schließen, wenn dem was nicht passt, als tatsächlich mal die Sachlage zu überblicken. Als ich das erste mal mit Modula 3 Bekannschaft machte, da hieß es, das wäre eine TOP-Programmiersprache. Ist die eigentlich auch. Aber die Logistik, die Linux-Pflicht, die Unibeschränktheit, die Bibs..
Gast
#7286257
rbx schrieb: > Auch jemand, der Windows 8.1. hat, oder XP oder Me? Das würde mich echt > mal interessieren. Rust unter Windows 7 habe ich selbst getestet, funktioniert. Und ja, die Installation ist nervig wegen dieser GB grossen Abhängigkeiten. Ich fürchte, das hat aber auch mit lizenzrechtlichen Dingen zu tun und es daher getrennt von MS geladen werden muss.
Gast
#7286365
Oliver R. schrieb: > Rust unter Windows 7 habe ich selbst getestet, funktioniert. Danke für den Hinweis. 32 oder 64 Bit? Ich habe 64 Bit Windows 8.1. Da lief dann aber nach der Installation nichts, also ist der ganze Ordner wieder in den Papierkorb gewandert, und der auch gleich geleert worden. Eventuell war der Nightly Build ein Fehler, möglicherweise funzt stable besser, mal sehen.
Gast
#7286375
Ich habe, angelockt durch diesen Thread her, jetzt einfach mal einen Test gemacht. Ein einfaches Hello World in Rust unter Linux aus dem Tutorial kopiert und kompiliert. Das Executable hat knapp 4 Megabyte. Also jetzt mal im Ernst, das ist doch ein schlechter Witz, oder? 4 MB für ein Programm, das "Hello, World!" auf der Konsole ausgibt? 🤯
Gast
#7286379
rbx schrieb: > Danke für den Hinweis. > 32 oder 64 Bit? War 64 Bit. Ist allerdings schon eine Weile her und der betreffende Rechner steht auch nicht bei mir. Ich würde auch bei stable bleiben solange nightly nicht explizit für bestimmten Code benötigt wird. Ansonsten verlierst du einen der Hauptvorteile von Rust, nämlich die Garantie, dass dein Code in allen zukünftigen (stable) Versionen kompilieren wird.
Gast
#7286381
Nachdenklicher schrieb: > 4 MB für ein Programm, > das "Hello, World!" auf der Konsole ausgibt? Bist du sicher, dass du im Release Mode kompiliert hast und auch keine Debug Symbole drin sind? Nachdenklicher schrieb: > Das Executable hat knapp 4 Megabyte. Schau dir die Ausgabe von "size <filename>" an, nicht die Größe im Dateisystem.
Gast
#7286388
Gerade getestet, das Hello World im Release Mode ohne Debug Symbole belegt unter Linux 289080 Bytes im Dateisystem. Man kann argumentieren, dass das immer noch viel ist und es gibt wohl Möglichkeiten da noch Platz einzusparen.
OK, Gegentest:
Gut, etwas kleiner. :-)
Aber so ist das mit Trivialbeispielen, sie sind völlig unrepräsentativ für die reale Welt.
Gast
#7286401
Wer etwas tiefer einsteigen will: https://github.com/johnthagen/min-sized-rust
Gast
#7286427
Jörg W. schrieb: > $ size helloworld > text data bss dec hex filename > 307914 12864 273 321051 0x4e61b helloworld Okay, das sieht bei mir auch so in der Art aus, mit Abweichungen um wenige Bytes. Aber:
Ich konnte es nicht aus der VM raus kopieren, eventuelle Tippfehler kommen vom Abschreiben. Woran liegt das dann, frage ich mich? Am Dateisystem ja wohl eher nicht, wenn der Sourcecode korrekt mit 45 Bytes angezeigt wird. Kompiliert ist es mit "rustc helloworld.rs". Ob das was mit Debug oder ohne ist, weiß ich nicht... 307914 vs 1839. Damit hat sich die Frage nach Rust für Embedded sowieso bereits erledigt. Wie schon vermutet, alles ein Phänomen im PC Bereich. Wo bei Speicher und Co. alles egal ist. Wie soll man mit so einem Footprint C für den Microcontrollerbereich mit wenigen MB oder gar kB Flash ablösen? Utopie trifft Wahnvorstellung.
Gast
#7286434
Ja. Die Größe der Rust-Binaries ist auf dem PC etwas größer als bei C. Das ist ein bekanntes Problem und daran wurde auch schon gearbeitet. Es wird jedoch offenbar nicht mit höchster Priorität verfolgt, da das ja nicht wirklich ein Problem ist. Ob ein Binary einer großen Applikation jetzt ein paar hundert kB größer ist oder nicht, spielt selten eine Rolle. Ich denke echt, dass es da wichtigere Probleme zu lösen gibt. > Und ja, die > Installation ist nervig wegen dieser GB grossen Abhängigkeiten. Ja. Das ist aber nur bei Windows so und der Grund ist Microsoft. Da ist Rust selbstverständlich auch nicht alleine. So gut wie jede etwas größere Applikation braucht diese RT unter Windows. Da kann Rust nun beim besten Willen nichts für und kann da auch nichts dran ändern.
Gast
#7286437
Cyblord -. schrieb: > Damit hat sich die Frage nach Rust für Embedded sowieso bereits > erledigt. Nö. Das ist ein reines PC-"Problem". > Utopie trifft Wahnvorstellung Vielleicht eher: Unwissenheit trifft Cyblord. MaWin schrieb: > Nö. Das ist ein reines PC-"Problem". Ach so. Gibts denn so ein Beispiel dann auch mal für zwei lauffähige Binaries für sagen wie mal nen STM32F103? > Da kann Rust nun beim besten Willen nichts für und kann da auch nichts > dran ändern. Wenn man nicht schwimmen kann, ist meistens nicht die Badehose schuld. Nachdenklicher schrieb: > Woran liegt das dann, frage ich mich? An allen möglichen weiteren sections im ELF-File, also Symboltabellen und Debug-Infos. Aber das ist doch für die praktische Anwendung komplett irrelevant: geladen wird das, was "size" dir anzeigt. Alles andere braucht Platz auf der Festplatte, mehr nicht. Cyblord -. schrieb: > 307914 vs 1839. Lässt allerdings komplett außer acht, dass das natürlich hier alles dynamisch gelinkte Binaries sind, d.h. ein nicht zu vernachlässigender Anteil an Code liegt in den shared libs. Jedoch sind diese natürlich, so der Name, eben "shared", d.h. alle Anwendungen nutzen das gemeinsam. (Das wäre bei "deeply embedded", also MCUs, anders.) Jörg W. schrieb: > Lässt allerdings komplett außer acht, dass das natürlich hier alles > dynamisch gelinkte Binaries sind, d.h. ein nicht zu vernachlässigender > Anteil an Code liegt in den shared libs. Jedoch sind diese natürlich, so > der Name, eben "shared", d.h. alle Anwendungen nutzen das gemeinsam. > (Das wäre bei "deeply embedded", also MCUs, anders.) Und was macht das C Programm hier anders als Rust? Und warum? Das muss ja auch auf dem bösen Windows laufen.
Gast
#7286457
Der Hauptgrund für die Binary-Größe auf Desktop-System ist die dazugelinkte Standard-Library. Embedded ist aber typischerweise "no-std", d.h. diese Problematik entfällt hier und die Binaries sind deutlich kleiner.
Gast
#7286460
Cyblord -. schrieb: > Ach so. Gibts denn so ein Beispiel dann auch mal für zwei lauffähige > Binaries für sagen wie mal nen STM32F103? Bestimmt. Google wieder kaputt? Ich habe schon Binaries für AVR8 kompiliert. Ein Rust-Programm mit leerer main() ist genau so groß wie ein C-Programm mit leerer main(). Es enthält dann in beiden Fällen nur die avr-libc-Boot- und Basisroutinen. Oliver R. schrieb: > Der Hauptgrund für die Binary-Größe auf Desktop-System ist die > dazugelinkte Standard-Library. Also ist die Standard Library für Rust nur bloat im Gegensatz zu der von C? Nochmal die Frage an dich: Warum hat ein C Programm unter Windows nicht die gleichen Probleme? Oliver R. schrieb: > Der Hauptgrund für die Binary-Größe auf Desktop-System ist die > dazugelinkte Standard-Library. Leuchtet allerdings dahingehend nicht ein, dass aus einer Library nur die Dinge gelinkt werden sollten, die auch tatsächlich benötigt werden. Es werden wohl eher Dinge wie ein Laufzeitsystem sein, die das aufblähen. Da ist dann die Frage, wieviel dieses Overheads eher statisch sind (also auch bei großen Programmen annähernd gleich groß bleiben), oder ob da was "mitwächst". Dass ein Helloworld kein sinnvoller Benchmark für die Größe eines erzeugten Binaries ist, sollte jedem klar sein. Jörg W. schrieb: > Dass ein Helloworld kein sinnvoller Benchmark für die Größe eines > erzeugten Binaries ist, sollte jedem klar sein. Warum das? Es gibt immerhin mal eine untere Grenze für die Binary Größe an.
Gast
#7286471
Cyblord -. schrieb: > Also ist die Standard Library für Rust nur bloat im Gegensatz zu der von > C? Nein. Aber sie ist per default statisch gelinkt. Unter C ist sie per default dynamisch gelinkt. Guck dir mal an, wie groß eine libc .so/.dll ist.
Gast
#7286479
Cyblord -. schrieb: > Warum das? Es gibt immerhin mal eine untere Grenze für die Binary Größe > an. Weil es völlig egal ist, ob das 1 kB, 10 kB oder ein paar 100 kB sind, seit niemand mehr mit Disketten arbeitet. Aber so kannst die Rust stdlib gerne dynamisch linken, wenn dich das stört. Es ist halt (noch) nicht die Standardeinstellung, weil das ABI (noch) nicht stabil ist.
Gast
#7286484
Cyblord -. schrieb: > Warum hat ein C Programm unter Windows > nicht die gleichen Probleme? Z.B. weil Rust einen Panic-Handler verwendet, während ein C Programm sich im Fall eines Absturzes einfach nur beendet. MaWin schrieb: > Weil es völlig egal ist, ob das 1 kB, 10 kB oder ein paar 100 kB sind, Genau DAS ist eben die fatale Einstellung der Rusties. Ich denke Rust hat fertig. Rust kann gehen. Cyblord -. schrieb: >> Dass ein Helloworld kein sinnvoller Benchmark für die Größe eines >> erzeugten Binaries ist, sollte jedem klar sein. > > Warum das? Weil es nichts sinnvolles macht. > Es gibt immerhin mal eine untere Grenze für die Binary Größe an. Nein, falls da wirklich printf drin ist (meist wird es der Compiler rauskicken), dann bläht das auch schon auf. Die untere Grenze wäre
MaWin schrieb: > Aber sie ist per default statisch gelinkt. Siehe oben, das allein erklärt das nicht. Auch bei statischem Linken wird aus einer Bibliothek nur rausgezogen, was benötigt wird. Es erscheint mir auch nach all den Beschreibungen über die Features von Rust völlig logisch, dass da etwas mehr an Laufzeitsystem dahinter steckt. Alle diese Überprüfungen, die nicht schon der Compiler machen kann, müssen ja schließlich irgendwo stecken. Das ist bei FORTRAN oder Pascal nicht anders. Komplett statisches Linken von Rust-Binaries scheint aber schon einiges an Aufwand zu sein, sonst hätte ich den Vergleich mal probiert. (Das zuweilen dokumentierte -C target-feature=+crt-static generiert trotzdem noch ein dynamisch gelinktes Binary, weil die Systembibliotheken dynamisch bleiben.) Jörg W. schrieb: > Leuchtet allerdings dahingehend nicht ein, dass aus einer Library nur > die Dinge gelinkt werden sollten, die auch tatsächlich benötigt werden. Kannst gerne dran arbeiten, wenn es dich so stört. Die Arbeit wird gerne angenommen. Tipp: Auf Embedded-Rust ist das natürlich auch genau so, weil dort die stdlib im (LTO-)Build direkt mitgebaut wird statt dazugelinkt wird. Das ist dann tatsächlich noch optimaler, als der C-Ansatz mit Link-Elision auf Funktionsbasis. > Es werden wohl eher Dinge wie ein Laufzeitsystem sein, die das > aufblähen. Jörg wieder einmal wild am spekulieren. Was soll das denn für ein Laufzeitsystem sein? Oliver R. schrieb: > Cyblord -. schrieb: >> Warum hat ein C Programm unter Windows >> nicht die gleichen Probleme? > > Z.B. weil Rust einen Panic-Handler verwendet, während ein C Programm > sich im Fall eines Absturzes einfach nur beendet. Ja und? Will ich jetzt aber nicht haben. Muss ich aber drin haben? Super. Ich stelle mir das schon vor: "Also Chef, wir brauchen den größeren und teureren Controller, weil Rust hat den Panic Handler immer mit drin. Was der bringt? Bei uns gar nichts. Ja ist halt trotzdem drin. Ok machen wir das Produkt teuer. Die Kunden haben ja auch was davon. Was genau? Äh Ich muss weg." MaWin O. schrieb: > Jörg W. schrieb: >> Leuchtet allerdings dahingehend nicht ein, dass aus einer Library nur >> die Dinge gelinkt werden sollten, die auch tatsächlich benötigt werden. > > Kannst gerne dran arbeiten, wenn es dich so stört. Das Verhalten, aus einer Library nur das rauszuziehen, was benötigt wird, hat nichts mit der Sprache zu tun, sondern ist eine Eigenschaft des Linkers. > Was soll das denn für ein Laufzeitsystem sein? Ich dachte, dass du mir das erklären kannst. Oliver R. hat ja zumindest einen Punkt gebracht, der in diese Richtung passt. Cyblord -. schrieb: > Ja und? Will ich jetzt aber nicht haben. Muss ich aber drin haben? Nein. Du kannst es soweit reduzieren, dass es nur ein abort()-Aufruf ist. Deine Entscheidung. Jörg W. schrieb: > Ich dachte, dass du mir das erklären kannst. Naja, du spekulierst hier wild herum über etwas, das es so nicht gibt.
Gast
#7286499
Cyblord -. schrieb: > Ja und? Will ich jetzt aber nicht haben. Muss ich aber drin haben? > Super. Du hast von Windows geredet. Da ist der standardmässig drin. MaWin O. schrieb: > Nein. > Du kannst es soweit reduzieren, dass es nur ein abort()-Aufruf ist. > Deine Entscheidung. Ah wieder mal was per default drin was kacke ist. I see. Cyblord -. schrieb: > Ah wieder mal was per default drin was kacke ist. I see. Es ist kacke ein Programm bei einem fatalen Problem vernünftig zu beenden und eine vernünftige Fehlermeldung auszugeben? Verstehe. MaWin O. schrieb: > Cyblord -. schrieb: >> Ja und? Will ich jetzt aber nicht haben. Muss ich aber drin haben? > > Nein. > Du kannst es soweit reduzieren, dass es nur ein abort()-Aufruf ist. > Deine Entscheidung. Dann zeig doch bitte mal, wie diese "deine Entscheidung" praktisch aussieht. Das (primitive) Codebeispiel ist oben. copy&paste einfach mal die nötigen Compileroptionen und das Ergebnis (wieder als Ausgabe von "size"). Das überzeugt deutlich mehr als eine wortreiche Erklärung "kann man doch alles abschalten". Bitte schalte es mal ab. MaWin O. schrieb: > Es ist kacke ein Programm bei einem fatalen Problem vernünftig zu > beenden und eine vernünftige Fehlermeldung auszugeben? > Verstehe. In den meisten Fällen bringt dir das gar nichts. Das Gerät geht halt nicht mehr. Egal welche Handler da angesprungen oder nicht angesprungen werden. Jörg W. schrieb: > Dann zeig doch bitte mal, wie diese "deine Entscheidung" praktisch > aussieht. Ach komm. Ist Google tatsächlich kaputt? Das ist doch lächerlich. Ich suche es jetzt garantiert nicht extra für dich raus, aber man muss ins Cargo.toml sowas wie panic=abort schreiben. Genauer habe ich es jetzt nicht im Kopf. Cyblord -. schrieb: > In den meisten Fällen bringt dir das gar nichts. Das Gerät geht halt > nicht mehr. Egal welche Handler da angesprungen oder nicht angesprungen > werden. Genau deshalb schaltet man diesen Handler auf Embedded ja auch ab. Wo ist eigentlich dein Problem? Gibt es bei Rust für Embedded-Architekturen nicht irgendsowas wie -ffreestanding? Oder irgendwas um Teile der Laufzeitumgebung nicht mitzulinken? Auf dem PC sind 3Mb Laufzeitgedöns vernachlässigbar (gesetzt dem Fall dass es nicht mitwächst und ein 100Mb-Exectuable auch nur 3Mb Bloat drin hat). Embedded sind diese 3Mb natürlich ein NoGo. Le X. schrieb: > Gibt es bei Rust für Embedded-Architekturen nicht irgendsowas wie > -ffreestanding? Oder irgendwas um Teile der Laufzeitumgebung nicht > mitzulinken? Selbstverständlich. Nennt sich #![no_std] Wurde natürlich auch schon gesagt. Le X. schrieb: > Embedded sind diese 3Mb natürlich ein NoGo. Gegebene Antworten hier nicht so lesen ist für mich ein NoGo. Ich wiederhole das jetzt nicht. MaWin O. schrieb: > Ach komm. Ist Google tatsächlich kaputt? > Das ist doch lächerlich. Ja, warum muss man ständig deine kruden Behauptungen selber googlen? Belege sie selbst oder nehme sie zurück. > Ich suche es jetzt garantiert nicht extra für dich raus, aber man muss > ins Cargo.toml sowas wie panic=abort schreiben. Genauer habe ich es > jetzt nicht im Kopf. Ja klar. Ist sicher echt trivial. > Genau deshalb schaltet man diesen Handler auf Embedded ja auch ab. > Wo ist eigentlich dein Problem? Dass die Beispiele ständig zeigen dass es nicht brauchbar ist und du ständig behauptest man könne das alles auch anders haben, aber den Beweis schuldig bleibst und auf google verweist. Argumentativ noch nackiger kann man sich ja nicht mehr machen als du hier gerade.
Gast
#7286529
Le X. schrieb: > Gibt es bei Rust für Embedded-Architekturen nicht irgendsowas wie > -ffreestanding? Oder irgendwas um Teile der Laufzeitumgebung nicht > mitzulinken? Das ist bei Rust "no-std", da wird nichts dazugelinkt und auch der Panic Handler muss explizit definiert werden. Cyblord -. schrieb: > Belege sie selbst oder nehme sie zurück. Ich werde weder das eine, noch das andere tun. Stirb doch einfach dumm, Cyblord. Wie wäre das? MaWin O. schrieb: > Stirb doch einfach dumm, Cyblord. Wie wäre das? Solange ich ohne Rust sterben darf ist alles ok. MaWin O. schrieb: > Jörg W. schrieb: >> Dann zeig doch bitte mal, wie diese "deine Entscheidung" praktisch >> aussieht. > > Ach komm. Ist Google tatsächlich kaputt? Ich habe auch nicht auf Google verwiesen, sondern Beispiele gezeigt, die man per copy&paste nachvollziehen kann. Aber lass man, helfen oder gar jemanden überzeugen willst du offenbar nicht. Jörg W. schrieb: > jemanden überzeugen willst du offenbar nicht. Ganz gut erkannt. Wenn du es nicht nutzen willst - und das willst du ganz offensichtlich nicht - dann lasse es halt. Kein Problem. MaWin O. schrieb: > Ganz gut erkannt. > Wenn du es nicht nutzen willst - und das willst du ganz offensichtlich > nicht - dann lasse es halt. Ich will es derzeit nicht nutzen (weil ich aktuell schlicht keine Anwendung für sowas habe). Ich mache aktuell auch bspw. kein C++. Deshalb stecke ich jetzt auch keinen Aufwand da rein, aber es täte mich interessieren, und wenn ich das mal irgendwo gesehen habe, speichere ich mir solche Tricks gedanklich ab. Deshalb wäre ich daran interessiert, von jemandem, der damit täglich umgeht (und daher schneller ist als ich), sowas zu erfahren. Von dir also offenbar nicht, dann lass es. Ich werde wohl lieber zu gegebener Zeit meinen Sohn danach fragen, das dürfte ergiebiger sein als so einen Sturkopf wie dich. Sorry, musste mal raus. Jörg W. schrieb: > Deshalb stecke ich jetzt auch keinen Aufwand da rein Ja, das merke ich. Das ist natürlich sehr klug mir den Aufwand aufzubürden und mich die Dokumentation durchsuchen zu lassen. Nur tue ich das nicht. > Deshalb wäre ich daran interessiert, > von jemandem, der damit täglich umgeht (und daher schneller ist als > ich), sowas zu erfahren. Ich habe dir alle Stichworte geliefert, mit denen du es findest. Der Rest liegt an dir. > das dürfte ergiebiger sein als so einen Sturkopf wie dich. Du bist ein ziemlich unverschämter Mensch, der direkt bockig wird, wenn andere Leute nicht nach deiner Pfeife tanzen. Damit musst du leider leben. MaWin O. schrieb: > Das ist natürlich sehr klug mir den Aufwand aufzubürden und mich die > Dokumentation durchsuchen zu lassen. Nun, du hast behauptet, dass du das schon gemacht hast, insofern nahm ich an, dass du nicht erst Google bemühen musst. Da lag ich wohl falsch. Wenn ich ansonsten genauso "bockig" wäre, wie du das behauptest, glaubst du, ich würde hier alle nasenlang Leuten bei den Problemen helfen, bei denen ich mich gut auskenne? Bei mir ergibt das Rust HelloWorld Beispiel:
Das C++ Beispiel ist unwesentlich kleiner:
Beides dynamisch gelinkt. Wilhelm M. schrieb: > Bei mir ergibt das Rust HelloWorld Beispiel: Das sieht doch gut aus. Kannst du jetzt noch die Build-Optionen dafür posten? Jörg W. schrieb: > Nun, du hast behauptet, dass du das schon gemacht hast, insofern nahm > ich an, dass du nicht erst Google bemühen musst. Richtig. Und ich habe ganz genau beschrieben, was ich gemacht habe und was ich noch im Kopf wusste. Wo ist eigentlich dein Problem? Statt hier mit mir zu diskutieren, hättest du schon lange "panic=abort" in Google eingeben können. Das wäre vermutlich zu einfach gewesen. Jörg W. schrieb: > Wilhelm M. schrieb: >> Bei mir ergibt das Rust HelloWorld Beispiel: > > Das sieht doch gut aus. > > Kannst du jetzt noch die Build-Optionen dafür posten?
Aber das haben die Rust-Experten hier ja sicher alles gewusst ;-) Und statisch ist Rust und C++ auch wieder vergleichbar.
Gast
#7286623
Weil hier nach Beispielen für STM32 gefragt wurde ein, hier ein typisches "Blinky": https://gitlab.com/jounathaen-projects/embedded-rust/blinky-rust Ergibt als Release Build
Moin, OK, damit kommt dann bei mir, wenn man sich das executable mittels ldd anguckt, noch eine weitere shared-lib dazu, die dann halt den Krempel, der vorher das binary so aufgeblasen hat, beinhalten wird. Bei so einem genialen Namen wie dann hier dafuer verwendet wird, freu' ich mich schon arg auf interoperabilitaet. Achja: Neben den ganzen lustigen, aber scheint's wohl etwas platzfressenden Gimmicks von rust wird natuerlich in allen Faellen immernoch zusaetzlich die libc gebraucht...
Gruss WK Wilhelm M. schrieb: > Und statisch ist Rust und C++ auch wieder vergleichbar. Hast du denn Rust statisch bekommen? Ich nicht, libc war trotzdem noch dynamisch, und das Netz verweist auf MUSL (oder so ähnlich). Dergute W. schrieb: > Bei so einem > genialen Namen wie dann hier dafuer verwendet wird, freu' ich mich schon > arg auf interoperabilitaet. Und deine konkrete Kritik ist jetzt was? > von rust wird natuerlich in allen Faellen > immernoch zusaetzlich die libc gebraucht... Selbstverständlich nicht. Aber das wurde hier mehrfach erklärt. Auch heute noch einmal. Deshalb wiederhole ich das jetzt nicht noch einmal. Auf einem PC ist die libc halt de-facto die Schnittstelle zum Betriebsystem. Auf Windows ganz offiziell und auf Linux praktisch auch. Direkte Syscalls macht niemand. Wenn man kein OS hat, dann braucht man die libc selbstverständlich nicht. (Auf AVR braucht man sie derzeit nur, weil sie noch niemand rausgeworfen hat und die paar benötigten Features in Rust neuimplementiert hat.). Dergute W. schrieb: > OK, damit kommt dann bei mir, wenn man sich das executable mittels ldd > anguckt, noch eine weitere shared-lib dazu, die dann halt den Krempel, > der vorher das binary so aufgeblasen hat, beinhalten wird. Das ist bei C++ auch so (und auch bei anderen Sprachen außer C). Nur C kommt (fast) nur mit der C-Lib aus. Alles andere braucht auch die C-Lib, weil das auf den meisten Systemen das POSIX-API realisiert. Daher auch bei einem Rust executable. Jörg W. schrieb: > Wilhelm M. schrieb: >> Und statisch ist Rust und C++ auch wieder vergleichbar. > > Hast du denn Rust statisch bekommen? Ich nicht, libc war trotzdem noch > dynamisch, und das Netz verweist auf MUSL (oder so ähnlich). Nicht vollständig wie bei C / C++ / .... Das bezieht sich bei Rust nur auf die Bib von Rust selbst. Aber ich bin kein Rust Experte ... Wenn ich mir ein
ansehe, dann weiß ich auch, warm das dann so groß ist ;-) Moin, MaWin O. schrieb: > Dergute W. schrieb: >> Bei so einem >> genialen Namen wie dann hier dafuer verwendet wird, freu' ich mich schon >> arg auf interoperabilitaet. > > Und deine konkrete Kritik ist jetzt was? Keine Kritik - ich schrieb doch: ich freue mich... :-) > Aber das wurde hier mehrfach erklärt. Auch heute noch einmal. Deshalb > wiederhole ich das jetzt nicht noch einmal. Tschuldigung, ich bin da halt etwas begriffstutzig. > Auf einem PC ist die libc halt de-facto die Schnittstelle zum > Betriebsystem. Auf Windows ganz offiziell und auf Linux praktisch auch. > Direkte Syscalls macht niemand. > Wenn man kein OS hat, dann braucht man die libc selbstverständlich > nicht. > (Auf AVR braucht man sie derzeit nur, weil sie noch niemand rausgeworfen > hat und die paar benötigten Features in Rust neuimplementiert hat.). Axo. Selbstverstaendlich. Wie kam ich nur auf das schmale Brett, das bei dem sicheren Rust vielleicht auch der ganze "unsichere, in boesem C geschriebene" Unterbau durch was eigenes, viel geileres, sichereres ersetzt worden haette sein koennen. Von der Groesse der "Rust-Laufzeitumgebung" vielleicht? Neeeein, ist sicher nur, weil ich halt so'n bissl langsamer im Denken bin. Gruss WK Dergute W. schrieb: > Neeeein, ist sicher nur, weil ich halt so'n bissl langsamer im Denken > bin. Gut erkannt.
Gast
#7286747
Cyblord -. schrieb: > 307914 vs 1839. > > Damit hat sich die Frage nach Rust für Embedded sowieso bereits > erledigt. Wie schon vermutet, alles ein Phänomen im PC Bereich. Wo bei > Speicher und Co. alles egal ist. > Wie soll man mit so einem Footprint C für den Microcontrollerbereich mit > wenigen MB oder gar kB Flash ablösen? Utopie trifft Wahnvorstellung. das liegt primär daran das Rust die Standardlib statisch linked - auf embedded sieht das ganz ganz anders aus btw: du wolltest noch erklären warum das Iterator-Konzept ein No-go für embedded ist, hast du jetzt Zeit gefunden dir das zu überlegen? cppbert schrieb: > du wolltest noch erklären warum das Iterator-Konzept ein No-go für > embedded ist :-)) cppbert schrieb: > das liegt primär daran das Rust die Standardlib statisch linked - auf > embedded sieht das ganz ganz anders aus Naja: dort wird alles statisch gelinkt (zumindest auf MCUs - auf MPUs läuft ja eher ein reguläres OS). Jörg W. schrieb: > Naja: dort wird alles statisch gelinkt Es ist trotzdem ein Unterschied, weil bei Rust Embedded (beim normalen Arbeiten mit Cargo) die stdlib nicht vorkompiliert ist. Sie nimmt Teil an dem einen Gesamtbuild mit dem einen LTO. Geht natürlich auch anders, wenn man will, aber sinnvoll ist es allemal das Gesamtkonstrukt zu optimieren und dann nichts mehr hinzu zu linken.
Gast
#7286785
Niemand hat gesagt das Rust und die komplette Tool-Chain 100% ausgereift ist, es geht hier (nach meiner Meinung) primär um die Sprache selbst und wenn die GCC Leute ihr eigenes Frontend bauen sieht es da auch ganz anders aus und falls Microsoft dann noch hinterher hüpft mit Rust# (ich hoffe nicht) sieht es nochmal anders aus cppbert schrieb: > Niemand hat gesagt das Rust und die komplette Tool-Chain 100% ausgereift > ist Das genügt den µC.net-Ansprüchen aber nicht. Es muss alles perfekt sein. Erst dann kann die bekanntlich perfekte Sprache C abgelöst werden. Da werden keinerlei Kompromisse eingegangen. :) Außer bei den eigenen Kenntnissen. Da werden Kompromisse eingegangen bis hin zur völligen Abwesenheit. > es geht hier (nach meiner Meinung) primär um die Sprache selbst Ich finde es schon wichtig auch zu zeigen, dass zum Beispiel das Standard-Buildsystem Cargo praktisch allen anderen Buildsystemen haushoch überlegen ist. Es funktioniert einfach sehr gut. Selbstverständlich liegt das auch daran, dass es perfekt auf Rust und seinen Compiler zugeschnitten ist. Das ist klar. cppbert schrieb: > und wenn die GCC Leute ihr eigenes Frontend bauen sieht es da auch ganz > anders aus Ich denke nicht, dass es ganz anders aussieht. Aber sicher wird man Aspekte der Sprache finden, über die sich bisher formell noch niemand Gedanken gemacht hat und die einfach so sind, weil rustc sie so implementiert. Das ist ja bereits so passiert und wird auch noch ein paar mal passieren. Das führt aber dazu, dass die Sprache als Ganzes noch besser wird. Deshalb sind sowohl gccrs als auch codegen-gcc ganz wichtige Projekte. Die Geschichte hat uns gelehrt, dass erst LLVM/clang wieder Leben in die damals völlig festgerostete gcc-Entwicklung gebracht hat. > Announcing Rust 1.66.0 https://blog.rust-lang.org/2022/12/15/Rust-1.66.0.html > Explicit discriminants on enums with fields Ist manchmal ganz nützlich z.B. in Parsern oder Protokollinterpretern. Jetzt auch mit komplexen enums. > core::hint::black_box Könnte nützlich sein für Embedded-Entwicklung. Da ist tatsächlich oft das "Problem", dass es einem den Code komplett wegoptimiert, wenn man ihn nirgendwo verwendet. z.B. wenn man nur mal kurz schauen will, zu welchem Assembly ein Stück Code generiert war es oft notwendig die Ein- und Ausgaben zu diesem Code irgendwie über volatile-Zugriffe zu machen. Das hier vereinfacht das sicher enorm. > checked signed+unsigned operations Das ist tatsächlich sehr nützlich und wird einige Programmteile deutlich verkürzen. Rust verbietet normalerweise Operationen zwischen verschiedenen Typen. Deshalb muss man Typen konvertieren und dann natürlich Überlaufprüfungen usw. machen. Es gibt aber einige Funktionen, die einige dieser gängigen Operationen erleichtern und gleichzeitig safe halten. > You can now use ..=X ranges in patterns. Jo das ist gut. Weiß gar nicht, warum das so lange nicht stabil war :)
Gast
#7286815
MaWin O. schrieb: > Ich finde es schon wichtig auch zu zeigen, dass zum Beispiel das > Standard-Buildsystem Cargo praktisch allen anderen Buildsystemen > haushoch überlegen ist. das gehört für mich zu der "Sprache" dazu - ist ja auch ein Konzept Es wird sich zeigen wie die integration in GCC sein wird - nur Rust als Sprache oder auch gccrs_cargo als weitere Implementation ich meinte beim Bezug zum GCC auch nur das dort das Linken usw. default-Verhalten nicht unbedingt so sein muss wie beim Referenz-System rustc usw. cppbert schrieb: > ich meinte beim Bezug zum GCC auch nur das dort das Linken usw. > default-Verhalten nicht unbedingt so sein muss wie beim Referenz-System > rustc usw. Achso. Ja. Das Linken hat natürlich gar nichts mit rustc zu tun. Auch heute nicht. Das ist wie Cargo die Toolchain bedient. Deshalb denke ich aber schon, dass sich das nicht grundsätzlich unterscheiden wird. Jedenfalls nicht mehr, als es sich bei gcc vs clang unterscheidet.
Gast
#7286824
MaWin O. schrieb: > Achso. Ja. > Das Linken hat natürlich gar nichts mit rustc zu tun. Auch heute nicht. > Das ist wie Cargo die Toolchain bedient. und dann landet das auch auch schön in cygwin oder mingw, msys2 und rbx ist gleich wieder froh :)
Gast
#7286834
cppbert schrieb: > Es wird sich zeigen wie die integration in GCC sein wird - nur Rust als > Sprache oder auch gccrs_cargo als weitere Implementation cargo dürfte eigentlich nur den Compileraufruf wrappen. Ob das dann gcc-rs anstelle von rustc ist, sollte nicht die entscheidende Rolle spielen. Flags und Optionen müssen natürlich ggfs. angepasst werden.
Gast
#7287040
Jörg W. schrieb: >
> OK, Gegentest: >
> Gut, etwas kleiner. :-) >
> Aber so ist das mit Trivialbeispielen, sie sind völlig unrepräsentativ > für die reale Welt. C ist immer noch total fett, wenn man es mit Assembler vergleicht. Hier bei mir braucht ein einfaches "Hello World!" in Rust 297208 Bytes. Meine Version in Assembler unter DOS braucht 87 Bytes. Gut, das ist ein 16 Bit REAL MODE Programm, aber meine 64 Bit Rust Version und deine C und C++ Binaries sind immer noch um ein Vielfaches größer. Das OS ist ein anderes und es sind 64 Bit Binaries, aber selbst wenn man bedenkt, dass die Binaries nicht statisch gelinkt sind und das printf von libc in der libc auch noch Platz braucht, ist das ziemlich viel Platz, was da benötigt wird. Die NASM Version unter Linux braucht mit nur 50 Bytes sogar noch weniger Bytes. Das könnte allerdings am SYSCALL liegen, d.h. der Kernel macht hier mehr und weil die Segmente wegfallen.
Angehängte Dateien:
Gast
#7287054
MaWin schrieb: > Cyblord -. schrieb: >> Warum das? Es gibt immerhin mal eine untere Grenze für die Binary Größe >> an. > > Weil es völlig egal ist, ob das 1 kB, 10 kB oder ein paar 100 kB sind, > seit niemand mehr mit Disketten arbeitet. Wenn das komplette Programm in den L1 Cache der CPU passt, macht das schon etwas aus, wenn es performancekritisch ist. Der Intel Tiger Lake hat nur einen L1 Cache von 48 KiB für Daten und 32 KiB für Befehle. Da sind 100 KiB schon zu groß. Nano schrieb: > Wenn das komplette Programm in den L1 Cache der CPU passt, macht das > schon etwas aus, wenn es performancekritisch ist. Wer kennt sie nicht, die performancekritischen Hello-World-Programme. Außerdem: Lies mal nach, was Dateigröße, Sectiongröße und RAM-Belegung unterscheidet. Es ist nicht mehr DOS. Du fragst: Wo soll ich das lesen? Wo soll ich mich weiterbilden? Die Antwort wird dich total überraschen: Hier im Thread! Heute!
Gast
#7287062
MaWin O. schrieb: > Nano schrieb: >> Wenn das komplette Programm in den L1 Cache der CPU passt, macht das >> schon etwas aus, wenn es performancekritisch ist. > > Wer kennt sie nicht, die performancekritischen Hello-World-Programme. Mein Supergirl hat nunmal hohe Ansprüche an eine schnelle Bildschirmausgabe. > > Außerdem: Lies mal nach, was Dateigröße, Sectiongröße und RAM-Belegung > unterscheidet. Nö, das weiß ich. Wenn du das binary strippst, dann unterscheidet sich die ls Ausgabe nicht mehr groß von size. > Du fragst: Wo soll ich das lesen? Wo soll ich mich weiterbilden? Ich habe gar nichts derartiges gefragt. Nano schrieb: > Nö, das weiß ich. Wenn du das binary strippst, dann unterscheidet sich > die ls Ausgabe nicht mehr groß von size. Besser doch noch einmal hier nachlesen und sich weiterbilden.
Gast
#7287078
MaWin O. schrieb: > Nano schrieb: >> Nö, das weiß ich. Wenn du das binary strippst, dann unterscheidet sich >> die ls Ausgabe nicht mehr groß von size. > > Besser doch noch einmal hier nachlesen und sich weiterbilden. Wie ich bereits sagte, muss ich das nicht, da ich das schon weiß. Dein Problem ist, dass du Fakten nicht als gegeben hinnehmen willst. Wenn jemand Fakten liefert, dann greifst du die Person persönlich an. Such dir also mal einen Psychologen. Nano schrieb: > Wie ich bereits sagte, muss ich das nicht, da ich das schon weiß. Anscheinend ja nicht. > Dein Problem ist, dass du Fakten nicht als gegeben hinnehmen willst. > Wenn jemand Fakten liefert, dann greifst du die Person persönlich an. Bitte einmal ein vollständiges Zitat liefern, wo ich das getan habe. Und zwar nicht als Reaktion auf einen vorhergehenden persönlichen Angriff (wie heute von unserem Herrn Moderator). Danke.
Gast
#7287094
MaWin O. schrieb: > Nano schrieb: >> Wie ich bereits sagte, muss ich das nicht, da ich das schon weiß. > > Anscheinend ja nicht. > >> Dein Problem ist, dass du Fakten nicht als gegeben hinnehmen willst. >> Wenn jemand Fakten liefert, dann greifst du die Person persönlich an. > > Bitte einmal ein vollständiges Zitat liefern, wo ich das getan habe. Und > zwar nicht als Reaktion auf einen vorhergehenden persönlichen Angriff Hier Z.B. > Anscheinend ja nicht. Du unterstellst mir Dinge, die 1. nicht stimmen und 2. obwohl du keine Ahnung über mich hast und 3. es völlig am Thema vorbei geht, ich scheine dir wohl wichtig zu sein. Dich stört der Fakt, dass Assemblerprogramme kleiner sind als C oder Rust Programme. Denn mehr als eine wertfreie Aussage dazu inkl. Lieferung eines Beweises habe ich nicht gesagt. Das könnte man jetzt als so gegeben hinnehmen und fertig. Aber du kochst rot vor Wut, weil ich es gewagt habe, das einfach mal wertfrei und objektiv an das schwarze Brett zu hängen, damit es jeder lesen kann. Sprich, du hast Komplexe und noch ganz andere Probleme, komm mal klar.
Gast
#7287099
Noch eine Ergänzung als Auflösung für dich. Ich habe ls anstatt size benutzt, weil es beim strippen relativ egal ist und ich ls aus reiner Gewohnheit verwende und es ausreichend gut ist. Und meine Screenshots sind älter, als mein Lesen des Kommentars von Jörg, der dich darauf hingewiesen hat, dass man size zum messen verwenden soll: Beitrag "Re: Rust - ist das hier um zu bleiben?" Und jetzt nörgelst du daran herum, weil du streiten willst. Siehe dazu mein vorheriges Kommentar, ich kann mich da nur wiederholen, komm mal klar. Nano schrieb: >> Anscheinend ja nicht. > Du unterstellst mir Dinge Du solltest einmal nachschlagen, was das Wort "anscheinend" bedeutet. > Dich stört der Fakt, dass Assemblerprogramme kleiner sind als C oder > Rust Programme. Völliger Unsinn. > Das könnte man jetzt als so gegeben hinnehmen und fertig. Und warum tust du das dann nicht? > Aber du kochst rot vor Wut Ach? Habe ich gar nicht gemerkt. > das einfach mal > wertfrei und objektiv an das schwarze Brett zu hängen Und für meine Antwort auf deinen Beitrag gelten diese Grundsätze nicht? > Sprich, du hast Komplexe und noch ganz andere Probleme, komm > mal klar. Hm ja. Danke, Herr Psychologe, der auch sagt: Nano schrieb: > dann greifst du die Person persönlich an. Aber du scheinst mich ja ziemlich gut zu kennen, denn > Und jetzt nörgelst du daran herum, weil du streiten willst. Du scheinst ein sehr angenehmer Zeitgenosse zu sein.
Gast
#7287118
MaWin O. schrieb: > Bla bla bla Nano schrieb: >> Bla bla bla Ganz schön wertfrei und objektiv, deine Antwort. Danke dafür.
Gast
#7287128
MaWin O. schrieb: > Nano schrieb: >>> Bla bla bla > > Ganz schön wertfrei und objektiv, deine Antwort. > Danke dafür. Ich habe nicht geantwortet, ich habe lediglich dein Geschwurbel in 3 Wörtern zusammengefasst.
Gast
#7287135
Nano schrieb: > Ich habe nicht geantwortet, ich habe lediglich dein Geschwurbel in 3 > Wörtern zusammengefasst. Also: Nano schrieb: > Wenn jemand Fakten liefert, dann greifst du die Person persönlich an. > Such dir also mal einen Psychologen.
Gast
#7287208
@Nano MaWin hat es lediglich versäumt dir zu erklären das dein Assembler Beispiel dank Syscall nutzung völlig sinnfrei ist um irgendwelche Größenvergleiche zu betreiben - spätestens bei DOS geschwurbel wurde klar das es dir irgendwie nur darum geht ein wenig Technik zu schnattern und jetzt hört bitte auf euch anzuzicken
Gast
#7287425
cppbert schrieb: > und dann landet das auch auch schön in cygwin oder mingw, msys2 und rbx > ist gleich wieder froh :) Naja, nicht nur ich.. https://stackoverflow.com/questions/55603111/unable-to-compile-rust-hello-world-on-windows-linker-link-exe-not-found Ich hatte bei der Seite mit den "Standalone" Downloads die falschen Versionen heruntergeladen und installiert. ("rust-1.65.0-aarch64-pc-windows-msvc.msi") Jetzt habe ich eine Version heruntergeladen und installiert, die heißt "rust-nightly-i686-pc-windows-msvc.msi". Stunden später.. Installation OK, Pfadeinträge OK, rustc trallalla.rs.. > >dir .. trallalla.rs > wo ist meine exe?? Wie in Linux: keine Nachricht ist eine gute Nachricht? Ich frage mich eher: was habe ich jetzt schon wieder falsch gemacht? Ich würde mich hinsichtlich der möglichen Antworten aber eher nicht auf die Persönlichkeitsanalyseprofis MaWin oder cppbert hier verlassen wollen.
Gast
#7287634
rbx schrieb: > Ich würde mich hinsichtlich der möglichen Antworten aber eher nicht auf > die Persönlichkeitsanalyseprofis MaWin oder cppbert hier verlassen > wollen. Wirklich keine Ahnung was du machst aber ich hab auch von VS2017,19,22, MSys2, Clang, Python, zum spielen D und Rust, ... Linux usw. auch einfach alles auf meinem Win10, VMWare Linux Systemen drauf - könnte sein das ich einfach nur dusel hab weil ich schon so viel installiert habe - und mit den Systemen aber Fulltime jeden Tag arbeite kann es gut sein das kleine Probleme mir gar nicht mehr auffallen weil ich eh den ganzen Tag durch CMake, make oder sonstige Orgien wühle und relativ genau weiss was ich tun muss damit etwas aus/oder mit Code funktioniert
Gast
#7287638
cleaner Win10 VM, https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-msvc/rustup-init.exe aufgerufen, 40sek später läuft rustc sauber durch mit hello world - keine Ahnung was deine Probleme sind ich hab eine 120MBit Leitung und 8 Kerne oder so - aber macht das so viel aus?
Gast
#7287648
dann noch https://www.oreilly.com/library/view/rust-programming-by/9781788390637/e07dc768-de29-482e-804b-0274b4bef418.xhtml
in der Konsole - 30sek später bin ich auf nightly
rustup ist so ein bisschen wie pacman von cygwin/msys2
Gast
#7287655
Man kann die verwendete Version auch pro Projekt festlegen: https://rust-lang.github.io/rustup/overrides.html#the-toolchain-file
Gast
#7287664
cppbert schrieb: > keine Ahnung was deine Probleme sind Vielleicht Windows 8.1? Und: hast du die Standaloneversion genutzt? Haskell Plattform kam auch erst nach einigen Klimmzügen bei der Installation auf ME auf den Trichter, die falsche Windowsversion zu melden. Hätte man auch gleich am Anfang machen können. Aber ich will keine Vorurteile haben. Version ist rustc 1.68.0-nightly (b70baa4f9 2022-12-14) rustup geht nicht, kann aber mit der Standaloneversion zu tun haben. Außerdem habe ich keine Admininstallation, sondern nur eine auf Userbasis, was man ja im Installer ausdrücklich einstellen konnte.
Gast
#7287677
rbx schrieb: > cppbert schrieb: >> keine Ahnung was deine Probleme sind > > Vielleicht Windows 8.1? Win10 > Und: hast du die Standaloneversion genutzt? Nein - die verwende ich nicht - ist nicht prefered und auch nur für die welchen eine "richtigen" Installer wollen oder unbedingt offline - ich hasse grafische Installer - die sehen schön aus - dahinter ist meist Schrott weil keiner Bock hat die zu pflegen - da ist mir jede Konsolen-Installation 1000% lieber https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-msvc/rustup-init.exe dann rustup default nightly
Gast
#7287700
rbx schrieb: > Außerdem habe ich keine Admininstallation, sondern nur eine auf > Userbasis, was man ja im Installer ausdrücklich einstellen konnte. ich hab auch keine Admininstallation - sowas macht auch wirklich niemand mehr der nicht ein bisschen verrückt ist cppbert schrieb: > rbx schrieb: >> Außerdem habe ich keine Admininstallation, sondern nur eine auf >> Userbasis, was man ja im Installer ausdrücklich einstellen konnte. > > ich hab auch keine Admininstallation - sowas macht auch wirklich niemand > mehr der nicht ein bisschen verrückt ist Das ist halt auch so ein 1990er Einstellung. Auch für dich hat XKCD was auf Lager. https://xkcd.com/1200/
Angehängte Dateien:
Gast
#7287707
rbx schrieb: > Ich frage mich eher: was habe ich jetzt schon wieder falsch gemacht? Ja. Das fragen wir uns alle. Normale Leute klicken auf rustup-init.exe, installieren die stable Variante (Warum zum Henker installierst du nightly?), und zack schon hat man ein voll funktionsfähiges Rust + Cargo. Ich habe echt nicht die geringste Ahnung, was du da veranstaltest.
Gast
#7287710
Cyblord -. schrieb: > Auch für dich hat XKCD was auf Lager. Das widerspricht ja gar nicht cppbert's Aussage. Ist dir das nicht selbst aufgefallen? MaWin schrieb: > Cyblord -. schrieb: >> Auch für dich hat XKCD was auf Lager. > > Das widerspricht ja gar nicht cppbert's Aussage. Ist dir das nicht > selbst aufgefallen? Nein ist es nicht. Weil es genau passt.
Gast
#7287721
Cyblord -. schrieb: > MaWin schrieb: >> Cyblord -. schrieb: >>> Auch für dich hat XKCD was auf Lager. >> >> Das widerspricht ja gar nicht cppbert's Aussage. Ist dir das nicht >> selbst aufgefallen? > > Nein ist es nicht. Weil es genau passt. aber > Auch für dich hat XKCD was auf Lager. > https://xkcd.com/1200/ klingt so als hätte ich jemands Admin-Installationen befürwortet :)
Gast
#7287723
cppbert schrieb: > klingt so als hätte ich jemands Admin-Installationen befürwortet :) jemals
Gast
#7287725
wer Admin-Installation macht öffnet Tür und Tor für jedes erdenkliche Problem
Gast
#7287730
rbx schrieb: >> keine Ahnung was deine Probleme sind > Vielleicht Windows 8.1? Ziemlich sicher auch. Niemand testet Rust auf einem Betriebssystem, dessen Support ausgelaufen ist. Aber darauf hättest du natürlich auch selbst kommen können. cppbert schrieb: >> Auch für dich hat XKCD was auf Lager. >> https://xkcd.com/1200/ > > klingt so als hätte ich jemands Admin-Installationen befürwortet :) Kann es sein dass du das XKCD nicht verstanden hast? Es spricht sich FÜR Admininstallationen aus. Weil eine eingeschränkte User-Installation heute nicht mehr viel bringt, weil alles wichtige heute online passiert und nicht in den tiefen des OS.
Gast
#7287734
Cyblord -. schrieb: > Es spricht sich FÜR Admininstallationen aus. Nein, tut es nicht. MaWin schrieb: > Cyblord -. schrieb: >> Es spricht sich FÜR Admininstallationen aus. > > Nein, tut es nicht. Ja ok ich verstehe langsam das Problem in den Begrifflichkeiten. Es geht um Admininstallationen vs. getrennte Admin- und Userinstallationen. Es spricht sich allerdings dafür aus, dass man standardmäßig auf Adminrechten arbeitet. MaWin schrieb: > Niemand testet Rust auf einem Betriebssystem, dessen Support ausgelaufen > ist Rust ist seiner Zeit voraus? ;-) "Windows 8.1 Support endet am 10. Januar 2023" https://support.microsoft.com/de-de/windows/windows-8-1-support-endet-am-10-januar-2023-3cfd4cde-f611-496a-8057-923fba401e93 Also aktuell ist es noch supportet … (wenn auch nur gerade noch so).
Gast
#7287748
Cyblord -. schrieb: > Weil eine eingeschränkte User-Installation > heute nicht mehr viel bringt völliger Quatsch - nur schlechte miese Software benötigt das - es gibt aber viele die seit UAC anfängen alles nur noch als Admin installieren - aus Gewohnheit - ich mache gar keine Admin-Installationen - maximal läuft das VStudio mal kurzfristig als Admin damit der Intel-VTune an die Hardware-Counter kommt - aber nur so lange Performanz-Tests laufen ohne Grund eine Admin-Installation zu machen ist völlig hirnlos cppbert schrieb: > Cyblord -. schrieb: >> Weil eine eingeschränkte User-Installation >> heute nicht mehr viel bringt > > völliger Quatsch - nur schlechte miese Software benötigt das Darum geht es gar nicht. > - es gibt > aber viele die seit UAC anfängen alles nur noch als Admin installieren - > aus Gewohnheit - ich mache gar keine Admin-Installationen - maximal > läuft das VStudio mal kurzfristig als Admin damit der Intel-VTune an die > Hardware-Counter kommt - aber nur so lange Performanz-Tests laufen > > ohne Grund eine Admin-Installation zu machen ist völlig hirnlos Und das sieht halt XKCD anders. Und es wird ja auch begründet. Mehr sage ich ja nicht. Du hingegen kannst bisher nicht begründen was die eingeschränkten Rechte bringen sollen.
Gast
#7287752
Cyblord -. schrieb: > Und das sieht halt XKCD anders. Mehr sage ich ja nicht. rbx hat geschrieben > Außerdem habe ich !!! keine !!! Admininstallation und dann hast (nur) du angefangen von Admin-Installation zu sprechen
Gast
#7287753
Cyblord -. schrieb: > Du hingegen kannst bisher nicht begründen was die eingeschränkten Rechte > bringen sollen. Mehr Sicherheit, weniger Konflikte zwischen Applikationen wenn manche anfangen teilweise mit Adminrechten Dateien usw. zu erstellen das ist völliger veralteter Windows-Noob User Style - hauptsache das System läuft irgendwie cppbert schrieb: > das ist völliger veralteter Windows-Noob User Style Wie gesagt, in den 90er war diese Einstellung unter Profis Konsens. Aber heute kann man das schon hinterfragen. Die Zeiten ändern sich. Du scheinst halt in alten Mustern festzuhängen.
Gast
#7287779
Jörg W. schrieb: > Also aktuell ist es noch supportet … (wenn auch nur gerade noch so). Ja. War mir klar, das dieser dümmliche Kommentar kommen musste. https://learn.microsoft.com/de-de/lifecycle/products/windows-81 > Enddatum des Mainstreamsupports: 9. Jan. 2018 > Erweitertes Enddatum: 10. Jan. 2023 Windows 8.x ist tot. Das ist Fakt. Es zu verwenden ist dumm. Nun zu jammern, dass Rust darauf eventuell Probleme haben könnte, ist noch dümmer. Niemand interessiert sich für historische Betriebssysteme im Rust-Umfeld. MaWin schrieb: > War mir klar, das dieser dümmliche Kommentar kommen musste. Ah ja, die Realität ist "dümmlich". Mir ist persönlich Windows ziemlich schnuppe (Rust interessiert mich wenigstens, anders als Windows), ich gehe auch nicht davon aus, dass seine alte Windows-Version da tatsächlich eine Rolle spielt.
Gast
#7287799
Jörg W. schrieb: > Ah ja, die Realität ist "dümmlich". Nein. Deine Antwort ist dümmlich. Mir war völlig klar, dass der erweiterte Support erst in ein paar Tagen ausläuft. Für mein Argument spielt das allerdings genau gar keine Rolle. Deshalb habe ich es nicht extra erwähnt. > ich gehe auch nicht davon aus, dass > seine alte Windows-Version da tatsächlich eine Rolle spielt. Ja. Ich auch nicht. Aber ich würde mich auch nicht wundern, wenn es denn so wäre. Es gibt überhaupt keinen Grund Windows 8 zu verwenden und dann hier die Leute mit Problemen zu belästigen. Rust funktioniert auf Windows 10 und 11 tadellos und ist trivial installierbar. MaWin schrieb: > Aber ich würde mich auch nicht wundern, wenn es denn so wäre. > Es gibt überhaupt keinen Grund Windows 8 zu verwenden und dann hier die > Leute mit Problemen zu belästigen. > > Rust funktioniert auf Windows 10 und 11 tadellos und ist trivial > installierbar. Also ich sehe starke parallelen in der Argumentation und im Sozialverhalten zwischen Rust-Anhängern und Linux-Anhängern. Frappierend möchte man sagen. Cyblord -. schrieb: > Also ich sehe starke parallelen in der Argumentation und im > Sozialverhalten zwischen Rust-Anhängern und Linux-Anhängern. Wegen eines Einzigen?
Gast
#7287900
Ich denke mal, in Linux lässt sich Rust viel unproblematischer und schneller installieren. Theoretisch bräuchte man in die Konsole nur schreiben rustc Die Automagie geht soweit, dass die sich dann praktisch um den Rest kümmert, hinsichtlich der notwendigen Installation. Ähnlich schnell und unproblematisch kann man die OpenWatcom Sachen auf Windows installieren. Sowas würde man sich auch für Rust wünschen - wenn das denn so eine tolle C-Ablösung sein soll.
Gast
#7287912
rbx schrieb: > Sowas würde man sich auch für Rust wünschen Es nennt sich rustup-init.exe. Cyblord -. schrieb: > Du scheinst halt in alten Mustern festzuhängen. Mit deiner Einstellung darfst du allerdings auch nie Python+pip benutzen (womit virtual environments ebenfalls tabu sein dürften), erst recht nicht Platform.IO.
Gast
#7288003
rbx schrieb: > Ich denke mal, in Linux lässt sich Rust viel unproblematischer und > schneller installieren. > Theoretisch bräuchte man in die Konsole nur schreiben rustc Ich habe unter Linux und Windows in ca. 70sek installiert, sehr auch irgendwas 8.1 nicht mehr Supporter sein soll rbx schrieb: > Ähnlich schnell und unproblematisch kann man die OpenWatcom Sachen auf > Windows installieren. > Sowas würde man sich auch für Rust wünschen - wenn das denn so eine > tolle C-Ablösung sein soll. Für OpenWatcom brauch ich ca. 30sek Ist aber alles relativ bis absolut egal weil man 99% der Zeit Code schreibt und nicht aus Langeweile staendig Compiler installiert
Gast
#7288004
Cppbert schrieb: > sehr auch irgendwas 8.1 nicht mehr Supporter sein soll Sehe auch nirgends das 8.1 nicht supportet sein soll
Gast
#7288028
Cppbert schrieb: > Sehe auch nirgends das 8.1 nicht supportet sein soll Google immer noch kaputt? https://doc.rust-lang.org/nightly/rustc/platform-support.html > 64-bit MSVC (Windows 7+) 2 > 2 Only Windows 10 currently undergoes automated testing. > Earlier versions of Windows rely on testing and support > from the community. Jörg W. schrieb: > Naja, ehrlich, wer will sich heutzutage noch mit dem > abscheulichen "real mode" eine 8086 herumschlagen? Ich, aber ich mache auch 8080/Z80. Da nehme ich natürlich kein Rust für. > Ansonsten kann ich mir nicht vorstellen, dass das soooo > Windows-untauglich ist, [...] Naja, Firefox hat die Unterstützung für Windows 9x/ME eingestellt, bevor sie Rust integriert haben... und selbst wenn da Rust-Code drin ist, dann muss der noch lange nicht nennenswert mit der WinAPI zusammenarbeiten. Vollwertige Anwendungen in einer Sprache schreiben ist nochmal was anderes als Bibliotheken.
Gast
#7288087
S. R. schrieb: > und selbst wenn da Rust-Code drin ist, dann > muss der noch lange nicht nennenswert mit der WinAPI zusammenarbeiten. Das hat ja auch niemand behauptet. Es geht hier um Rust und alles im Rust-Lieferumfang. Nicht um Firefox. MaWin schrieb: > Only Windows 10 currently undergoes automated testing. Keine automatischen Tests bedeutet aber noch lange nicht, dass es deshalb gleich nicht mehr funktionieren soll. Python hatte wohl kürzlich bei ihren Binärversionen Support für Windows 7 eingestellt (d.h. es lässt sich da auch wirklich nicht mehr installieren), aber 8.1 ist selbst bei denen noch in der Tüte.
Gast
#7288127
MaWin schrieb: > Es geht hier um Rust und alles im Rust-Lieferumfang Leicht daneben, es geht um die Zukunft von Rust, und Daniel ist nicht der einzige, der in diese Richtung fragt. Und wenn man Zukunftsfragen stellt, dann ist es nicht verkehrt, in die Vergangenheit zu schauen, oder nach ähnlichen Fällen. Unabhängig davon: FreeDOS Project: Then and Now [Kielux 2017] - https://www.youtube.com/watch?v=w6NswAAKmbU 42 Minuten Bryan Lunduke war sich nicht zu schade, ein Interview mit Jim Hall zu machen. (Auf der Suche nach Antworten, warum Linux so schwach verbreitet ist, warum Linux so Spielunfreundlich ist usw. usw.) highlights from linux sucks 2022 by bryan lunduke https://www.youtube.com/watch?v=MRKtybzB3ig 3:35 https://reactos.org/forum/viewtopic.php?t=18215 ---------------------- Man sollte schon festhalten, dass die Rustanhänger ein wenig ein auf Woke machen, andere Meinungen dissen, und dass das neu ist. Das Gegenseitige runtermachen ist nicht neu, das ist flamewar, es ist eher die beobachtbare kognitive Dissonanz bei den Rust-Freunden. Und wenn man die FP analog als Steinzeit betrachtet, dann ist Haskell darin Ägypten. Der bewährte Weg ist vom Bekannten zum Unbekannten. An vielen Stellen gesehen. Aber von Lisp kennt man auch: Dialektmanie, viel schlimmer noch als Basic. Praktisch jeden Freitag ein neuer Lisp Dialekt. Das war bei C immer weniger schlimm. Noch dazu gibt es didaktisch krasse Bücher, wie das vom Erlenkötter. So ganz unscheinbar wird einem die Programmierung einer Game-Engine beigebracht.. Bei K+R lernt man gleich am Anfang, wie man Verschlüsselungen knackt, sowas fanden viele spannend.
Gast
#7288131
Jörg W. schrieb: > Keine automatischen Tests bedeutet aber noch lange nicht, dass es > deshalb gleich nicht mehr funktionieren soll. Was ja auch niemand behauptet hat. rbx schrieb: > FreeDOS Project Bitte on-topic bleiben. Danke. > Man sollte schon festhalten, dass die Rustanhänger ein wenig ein auf > Woke machen Ja. Genau. > Steinzeit Ja. > Ägypten Genau das. rbx schrieb: > die Rustanhänger Soso. Wie viele kennst du denn so, dass du für "die Rustanhänger" sprechen kannst? Jörg W. schrieb: > rbx schrieb: >> die Rustanhänger > > Soso. Wie viele kennst du denn so, dass du für "die Rustanhänger" > sprechen kannst? Mindestens einen davon kennt jeder, der diesen Thread liest. Was wäre, mal rein hypothetisch betrachtet, wenn dieser eine repräsentativ für die meisten anderen in seiner Gilde wäre? ;-) SCNR Yalu X. schrieb: > Mindestens einen davon kennt jeder, der diesen Thread liest. Naja, genau genommen, kenne ich allein aus dem Thread bereits zwei. Nur einer davon tritt, nennen wir es mal, derart "offensiv" auf. Da ich aber privat noch weiter Leute kenne, die das gern nutzen, trau' ich mir durchaus die Aussage zu, dass man von diesem einen allein keineswegs auf alle schließen kann.
Gast
#7288206
Jörg W. schrieb: > dass man von diesem einen allein > keineswegs auf alle schließen kann. Mache ich auch nicht. Auffällig waren die Kommentare in einem reddit-thread (s.o.). Und in dem ungekürzten Bryan Lunduke Video wird auch ein kleiner Witz über Rust Programmierer gemacht - in dem Comic-Bild in der 3 Min Zusammenfassung bei 2:38 zu sehen. Was er weiter meint, ist sowas wie: jetzt sind wir endlich Perl losgeworden.. Das kommt ja auch nicht von ungefähr, und so "riecht" man schon so ein wenig Sektenhaftigkeit, Gleichschaltung, VT-Zuschreibung usw.
Gast
#7288266
Es ist völlig unrelevant für die Qualitäten einer Sprache oder Betriebsystem wie sich dessen subjektiv wahrgenommene Community verhält, kein erfahrener Entwickler lässt sich davon in irgendeiner Form beeinflussen Jede Community hat ihre gemäßigten, toxischen, fanatischen und Prediger, aber Einzelpersonen sind ohne Projekt oder Team dahinter unrelevant, sie sprechen nie für eine Gruppe sondern immer nur für sich selbst und das ist ok, erst wenn sich Leute öffentlich treffen und gemeinsam diese subjektiv erfahrenen Werte teilen wird es schwierig und so leid es mir tut habe ich solche Konflikte nie erlebt wenn ich auf C/C++, Linux,Windows oder sonstige Veranstaltungen war kein Evangelismus, keine Abgrenzung, offene Gespräche und immer nur viel Interesse Die Welt ist voll mit Menschen die Neuerungen ausprobieren wollen, egal zu welchem Zweck und den Konservativen die denken das nur aus Stillstand und Reife etwas besseres entstehen kann, beides braucht man Es ist nur eine Sache die deutlich zu erkennen ist, es gibt wenige professionelle, also hauptberufliche Entwickler mit breiter Erfahrung die sich an solchen Diskussionen aktiv beteiligen, der Anteil an Hobby Entwicklern die das nur als Zeitvertreib machen ist viel höher und leider kann dieser Teil der Entwicklergemeinschaft nur recht wenig objektives Beitragen weil sie die Welt nur aus einem sehr eingeschränkten Blickwinkel sehen, oder eben der andere Teil an Entwicklern die in ihrem Bereich recht professionell sind aber leider trotzdem nicht verstehen das die guten Konzepte aus ihrer Welt nur beschränkt in der Systemwelt greifen können oder der harte Kern der einfach nur Technikgeschschwafel betreiben will, dem jedes Argument irgendwie recht ist und den es oft an Objektivität, Weitblick und Erfahrung fehlt Mir persönlich ist es völlig egal wie MaWin und andere hier (manchmal) auftreten, ich filtere die für mich relevanten Infos raus und gut ist und ein klein wenig missionieren hab ich mir nach so langer Zeit in der C/C++,C#,Python,....,Linux,Windows Entwicklung auch verdient ;) Sollte es mal ein Forumstreffen geben wird MaWin sicherlich einen Vortrag über Rust halten und der grosse Rest hier wird ihm zuhören und dann vielleicht offen und freundlich diskutieren, aber niemals so eigenbrödlerisch wie das teilweise hier statt findet Cppbert schrieb: > ich filtere die für mich relevanten Infos raus Das ist übrigens auch für mich der einzige Grund, mich hier zu beteiligen. Ansonsten danke für deinen Beitrag!
Gast
#7288309
Ihr interpretiert da ganz einfach viel zu viel rein. Was ich hier tue: - Berichten, wenn es etwas aus meiner sich interessantes Neues zu berichten gibt. - Berichtigen, wenn hier jemand Quatsch labert. Ich sehe das Problem eher bei denjenigen, die ewig lange mit ja-doch "antworten", nachdem sie berichtigt wurden. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
