Man sieht ja auf einigen Internetseiten Rustup-code und wundert sich, dass Rustup in Linux (Fedora 42) nicht geht. Schaut man sich ein wenig um, steht man wieder mal wie der Ochs vorm Scheunentor. Andererseits, wenn ich schon ein wenig besseren Durchblick habe, möchte ich mich dann doch lieber auf die Community verlassen. Kann man das anders sehen? (https://www.reddit.com/r/rust/comments/4inmpb/lets_talk_about_rustuprs/)
Wenn du jetzt noch eine sinnvolle Frage formulieren könntest, wäre das für den weiteren Thread hilfreich, auch wenn heute Freitag ist. Oliver P.S. Den Code von rustup findet man nicht auf „einigen Internetseiten“, sondern primär hier: https://github.com/rust-lang/rustup
Rbx schrieb: > Man sieht ja auf einigen Internetseiten Rustup-code Tut man das? Ich zumindest nicht. > und wundert sich, > dass Rustup in Linux (Fedora 42) nicht geht. Und schon wieder kein Treffer... > Schaut man sich ein wenig > um, steht man wieder mal wie der Ochs vorm Scheunentor. Nein, auch nicht. > Kann man das anders sehen? Oh man kann zu deinem ganzen Post eine sehr sehr ambivalente Meinung haben. Senil ist noch das netteste was mir dazu einfällt.
Rbx schrieb: > Man sieht ja auf einigen Internetseiten Rustup-code und wundert sich Man? Ich jedenfalls nicht. Was bezweckst du mit diesem Thema? Worauf willst du hibaus?
Rbx schrieb: > Man sieht ja auf einigen Internetseiten Rustup-code und wundert sich, > dass Rustup in Linux (Fedora 42) nicht geht. Schaut man sich ein wenig > um, steht man wieder mal wie der Ochs vorm >Scheunentor. > Andererseits, wenn ich schon ein wenig besseren Durchblick habe, möchte > ich mich dann doch lieber auf die Community verlassen. > Kann man das anders sehen? Ja. Zunächst sehe ich keinen "Rustup-Code" auf "einigen Internetseiten". Hin und wieder sehe ich Code in der Programmiersprache "Rust", aber "rustup" scheint lediglich ein Installationsprogramm für die Werkzeuge zur Arbeit mit dieser Programmiersprache zu sein. > (https://www.reddit.com/r/rust/comments/4inmpb/lets_talk_about_rustuprs/) Ohne diesen Thread gelesen zu haben, scheint es dort zunächst um Arch Linux und gewisse... Sicherheitsimplikationen hinsichtlich der Installation der Rust-Programmierwerkzeuge mit dem vom Rust-Projekt empfohlenen Methode mit einem Shellscript namens "rustup" zu gehen. Über Fedora steht dort nichts. Weil ich es genauer wissen wollte, habe ich mir dann ein Installationsimage von "Fedora Workstation", Version 42, heruntergeladen und in einer virtuellen Maschine (VM) installiert. Nach dem Booten der frisch installierten VM habe ich diese gebootet und in der grafischen Benutzeroberfläche (die übrigens wirklich schick aussieht, ein Landschaftsbild mit Brücke im Comic-Stil) ein Terminal gestartet (ich bin halt ein Kommandozeilenfreund, vermutlich gibt es dafür auch grafische Werkzeuge). In dem Terminal habe ich dann "dnf search rustup" ausgeführt, mir wurde dann ein Paket "rustup" vorgeschlagen, das ich installiert habe. Daraufhin stand mir das Programm "rustup" zur Verfügung, welches ich ausgeführt habe und auf die Abfrage die Option "1" für eine Standardinstallation der Rust-Werkzeuge ausgewählt. Das Programm hat dann eine Weile gerödelt und beendete sich mit dem Hinweis, daß die Rust-Installation nun vollständig sei. Also habe ich ein kleines "Hello World"-Programm geschrieben und versucht, es mit dem Rust-Compiler "rustc" zu übersetzen. Das schlug mit dem Hinweis fehl, daß irgendein anderes Werkzeug fehlen würde -- ich habe vergessen, welches, wußte aber, daß es zu den Entwicklungswerkzeugen für C gehört. Also habe ich die Pakete make, automake, autoconf, gcc, gcc-c++ und kernel-devel mit dem Fedora-Paketmanager dnf installiert. Danach konnte ich dann auch mit "rustc" mein "Hello World" kompilieren und das Kompilat ausführen. Als Gegencheck habe ich dann das von Fedoras "rustup" erzeugte Verzeichnis ".cargo" in meinem Homedirectory umbenannt und den auf [1] empfohlenen Befehl
1 | curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh |
ausgeführt. Daraufhin entspann sich derselbe Dialog, den ich bereits von dem Fedora-Werkzeug "rustup" kannte, ich habe dieselbe Option "1" gewählt und erhielt ein neues Verzeichnis .cargo in meinem Homedirectory. Mit den darin enthaltenen Werkzeugen konnte ich mein "Hello World" ebenfalls übersetzen und das erzeugte Executable ausführen. Mit einer kurzen Überprüfung stellte sich zudem heraus, daß das von Fedora gelieferte "rustup" dieselben Versionen der Werkzeuge installiert hatte wie das heruntergeladene Script. Deine Aussage, "dass Rustup in Linux (Fedora 42) nicht geht", kann ich daher in keiner Weise nachvollziehen. Bei mir hat alles reibungslos funktioniert. Könntest Du mir bitte erklären, wie Du zu Deiner Aussage kommst? Vielleicht können wir das ja aufklären. Danke.
Rbx schrieb: > (https://www.reddit.com/r/rust/comments/4inmpb/lets_talk_about_rustuprs/) Ein 10 Jahre alter Reddit Thread? Ernsthaft?
Kaj G. schrieb: > Ein 10 Jahre alter Reddit Thread? Ernsthaft? Man bedient sich eben dessen, dass die eigenen Vorurteile bestätigt, auch wenn es überhaupt nicht mehr passend ist.
Rbx schrieb: > wenn ich schon ein wenig besseren Durchblick habe, Sollen wir drauf warten? Drauf wetten? Warum frägst Du nicht im Forum von Rust? Die sollten deine Probleme schnell beantworten können. Da sind recht freundliche und kompetente Leute unterwegs. Aber Obacht: Die wollen klar gestellte Fragen, die Spinner! https://rust-lang.org/
Rbx schrieb: > Man sieht ja auf einigen Internetseiten Rustup-code und wundert > sich, > dass Rustup in Linux (Fedora 42) nicht geht. Schaut man sich ein wenig > um, steht man wieder mal wie der Ochs vorm Scheunentor. > Andererseits, wenn ich schon ein wenig besseren Durchblick habe, möchte > ich mich dann doch lieber auf die Community verlassen. > Kann man das anders sehen? Ja. > (https://www.reddit.com/r/rust/comments/4inmpb/lets_talk_about_rustuprs/)
Ein T. schrieb: > Hm, scheint als hätten wir unseren TO verloren... :-( Das ist ja ganz was neues hier!
Nick schrieb: > Ein T. schrieb: >> Hm, scheint als hätten wir unseren TO verloren... :-( > > Das ist ja ganz was neues hier! Das ist leider wahr. Aber in diesem Fall mag ich den TO und mache mir Sorgen, ob es ihm gut geht. :-(
Ein T. schrieb: > Aber in diesem Fall mag ich den TO und mache mir > Sorgen, ob es ihm gut geht. :-( Das ehrt Dich. Versuch ihn zu kontaktieren. Hier get es scheinbar nicht.
Ein T. schrieb: > Deine Aussage, "dass Rustup in Linux (Fedora 42) nicht geht", kann ich > daher in keiner Weise nachvollziehen. Bei mir hat alles reibungslos > funktioniert. Könntest Du mir bitte erklären, wie Du zu Deiner Aussage > kommst? Vielleicht können wir das ja aufklären. Danke. Ich kann dein Herumgemache auch nicht nachvollziehen. rustc geht bei mir einwandfrei und reicht erstmal völlig. Den anderen Krempel brauche ich eigentlich nicht, und wollte nur mal Meinungen und Einschätzungen hören. Bei Haskell gab es ja auch schon so ein Herumgehampel mit Cabal und Stack - sofern man Internet hat. Eigentlich ist das alles nur Beihilfe-Zeug, aber nicht so zentral, wie wichtige Programmierung oder Programmierkniffe oder Programmierpraxis an sich. Bei K+R-C kann man z.B. gleich lernen, wie man Kryptocrack-Programme schreiben kann oder beim Erlenkötter C, wie eine Game-Engine in den Grundbausteinen funktioniert. Bei Haskell oder Rust muss man sich aber erst eine Weile einarbeiten, um auf den Geschmack zu kommen, da stören Internet oder "Pflege"-Zusätze eigentlich nur. (sofern man nicht übers Internet lernt). Relativ gut kommt man (dokumentierbar) vorwärts, wenn man bestimmte bekannte C oder C++ Programme nimmt, und die nach Haskell oder Rust übersetzt. Wobei Rust ja auch C und Assembler ersetzen möchte. Das zu vergleichen ist sicher auch interessant - aber die eigentlichen Stärken von Rust liegen wohl eher in der Parallelverarbeitung.
Rbx schrieb: > Wobei Rust ja auch C und Assembler ersetzen möchte. Das zu vergleichen > ist sicher auch interessant - aber die eigentlichen Stärken von Rust > liegen wohl eher in der Parallelverarbeitung. Nachdem der Ausgangsbeitrag ja nun schon eine völlig willkürliche Abfolge von zusammenhangslosen Wörtern war, geht’s jetzt nahtlos weiter. Irgendwie geht da was gründlich durcheinander. Oliver
Oliver S. schrieb: > Irgendwie geht da was gründlich durcheinander. Danke, seh ich auch so. Ich musste mich schon zurückhalten auf das Posting (zwei vor diesem) zu antworten. "K&R C und Kryptocrack-Programme" miteinander zu verknüpfen, das schnall ich -als bekennender K&R "Hasser"- nicht. "Erlenkötter C und game engine". Das Buch ist von 1985. Und hat wohl von zeitgemässen C so viel am Hut wie K&R. Nichts. Wie 1985 und game engine zusammenhängen ist mir auch nicht klar. Liegt bestimmt an mir. Und dann von rust + C (OK, passt halbwegs zusammen, fehlt noch Zig) auf Haskel umzuschwenken. Haskel ist eine funktionale Programmiersprache. Ich hab mir mal Haskel angeschaut, da kann ich gleich APL nehmen. ICH komm mit Beidem nicht zurecht. Ich habs mal mit Ocaml probiert, das ist mir leider zu seltsam, die Infrastruktur obskur.*) Und dann Programme von C auf Haskel übersetzen. Das sind zwei komplett orthogonale Paradigmen. Übersetzen lässt sich das (möglicherweise) irgendwie, geht aber dann an der Zielsprache komplett und vorsätzlich vorbei. Ich hab das mal probiert. Von C auf Ocaml. Wenn man fertig ist, kann man mit Neuschreiben weitermachen. Ich hab das auch mal von C auf rust gemacht. Klappt besser, beim Borrowing fällt man dann immer wieder auf die Schnauze. Und merkt dann, dass man das doch besser neu schreibt und nur die Struktur behält. Obwohl C und rust nah beieinander stehen. Aber wurscht! *) In Ocaml sind die Quelltexte im UVZ "bin". Auf die Frage, warum es kein UVZ "src" dafür gibt, bekam ich die Antwort, "Weil man aus den sourcen binaries erzeugt". Das wurde von Anderen auch so gutgeheissen.
Puh, ein Glück, Du bist wieder da und es Dir anscheinend gut geht. :-) Rbx schrieb: > Ich kann dein Herumgemache auch nicht nachvollziehen. rustc geht bei mir > einwandfrei und reicht erstmal völlig. Nunja, Du hattest im Eröffnungsbeitrag geschrieben: Rbx schrieb: > Man sieht ja auf einigen Internetseiten Rustup-code und wundert sich, > dass Rustup in Linux (Fedora 42) nicht geht. Wegen Deiner Aussagen hatte ich mich gefragt, ob Rustup unter Linux allgemein oder unter Fedora 42 wirklich "nicht geht", wie Du gesagt hattest. Darum habe ich es ausprobiert und gesehen, daß das einwandfrei funktioniert. Dies wollte ich Dir nur mitteilen und Dir meine Unterstützung bei der Klärung eventueller Probleme anbieten. > Den anderen Krempel brauche ich > eigentlich nicht, und wollte nur mal Meinungen und Einschätzungen hören. Diesbezüglich kann ich nur vermuten, daß Du diesen "anderen Krempel" zumindest teilweise allerspätestens dann benötigst, wenn Du Programme schreiben wirst, die Bibliotheken aus externen Quellen benutzen sollen. Dann wird Dir zumindest der Paketmanager cargo sicherlich eine Hilfe sein. > Bei Haskell gab es ja auch schon so ein Herumgehampel mit Cabal und > Stack - sofern man Internet hat. Wenn ich das richtig verstanden habe, ist Cabal ein Paketmanager, ähnlich wie cargo. Stack verwaltet die Abhängigkeiten der Pakete und baut wohl auf Cabal auf bzw. benutzt Cabal als Bibliothek, kann das sein? > Eigentlich ist das alles nur > Beihilfe-Zeug, aber nicht so zentral, wie wichtige Programmierung oder > Programmierkniffe oder Programmierpraxis an sich. Naja, viele dieser Werkzeuge muß man in der Regel nicht unbedingt haben, aber am Ende erleichtern sie Aufgaben sicherlich enorm. Programmieren ist ja nicht nur das reine Schreiben von Code, oder? > Bei K+R-C kann man z.B. gleich lernen, wie man Kryptocrack-Programme > schreiben kann oder beim Erlenkötter C, wie eine Game-Engine in den > Grundbausteinen funktioniert. Hm... ich glaube nicht, daß Kryptoanalyse oder Gameengines sinnvolle Aufgaben für Einsteiger einer bestimmte Sprache oder gar ins Programmieren selbst sind. Ich meine, das sehen wir hier im Forum ja leider oft: Menschen, die zunächst voller Enthusiasmus sind und ein bestimmtes Projekt realisieren möchten, sich dabei aber hoffnungslos übernehmen und alsbald frustriert aufgeben. > Bei Haskell oder Rust muss man sich aber erst eine Weile einarbeiten, um > auf den Geschmack zu kommen, da stören Internet oder "Pflege"-Zusätze > eigentlich nur. > Relativ gut kommt man (dokumentierbar) vorwärts, wenn man bestimmte > bekannte C oder C++ Programme nimmt, und die nach Haskell oder Rust > übersetzt. Möglicherweise, allerdings... ich kann da natürlich nur für mich persönlich sprechen, aber eine neue Programmiersprache zu lernen ist für mich nicht nur eine akademische Übung, sondern ich habe auch den Anspruch, diese Sprache in meiner beruflichen und privaten Praxis benutzen zu können. Insofern ist Rust für mich deutlich interessanter als Haskell, das -- berechtigt oder nicht -- doch eher ein Nischendasein zu führen scheint. > Wobei Rust ja auch C und Assembler ersetzen möchte. Das zu vergleichen > ist sicher auch interessant - aber die eigentlichen Stärken von Rust > liegen wohl eher in der Parallelverarbeitung. Bisher habe ich mich mit Rust noch nicht intensiver beschäftigt, aber was ich davon bislang für Gleichzeitigkeit und Parallelisierung gesehen habe, scheint sich noch nicht sehr wesentlich von dem zu unterscheiden, was ich von anderen Sprachen kenne. Da finde ich den Ansatz von Golang mit seinem Kerngedanken "Do not communicate by sharing memory; instead, share memory by communicating" [1] irgendwie spannender... und nach einer Umdenkphase auch viel angenehmer. ;-) [1] https://go.dev/blog/codelab-share
Ein T. schrieb: > Diesbezüglich kann ich nur vermuten, daß Du diesen "anderen Krempel" > zumindest teilweise allerspätestens dann benötigst, wenn Du Programme > schreiben wirst, Ich seh den "Krempel" von rust als Stärke. Das ist sauber strukturiert und funktioniert einfach für rust. Unabhängig davon wofür man es einsetzen will. Kein Manufacturer lock in, egal welche Platform man verwenden will. Keine Abweichungen vom Standard (C) oder spezielle compiler-pragmas. Da gibts halt einfach nur EIN rust. Und ich hoffe, dass das so bleibt.
Nick schrieb: > Ich seh den "Krempel" von rust als Stärke. Das ist sauber strukturiert > und funktioniert einfach für rust. Naja, wenn es für Python funktionieren würde... wär doch komisch, oder? ;-) Aber Scherz beiseite: ich glaube, wir reden aneinander vorbei. Ich bezog mich mit dem "Krempel", da der TO von rustc gesprochen hatte, auf die Werkzeuge von Rust wie cargo et cetera. Welchen "Krempel" meinst Du?
Ein T. schrieb: > ich glaube, wir reden aneinander vorbei. Nein. Ich mein schon auch z.B. cargo oder das eigentlich nicht vorhandene make. Oder den Zwang zur einzig wahren Formatierung. Das hat man sich schon gut überlegt und nicht so zusammengeschustert wie in OCaml. Ein T. schrieb: > Welchen "Krempel" meinst Du? Genau den "Krempel" der Teil des Ganzen ist. Wer will, kann rust und alles drumrum als Krempel bezeichnen. Ich find es gut. Es ist halt nicht so billig zu erlernen wie z.b. Java oder Basic. :-)
Nick schrieb: > Nein. Ich mein schon auch z.B. cargo oder das eigentlich nicht > vorhandene make. Ah, okay. Was make(1) angeht... ich finde es immer wieder verblüffend, wie lange sich das olle Ding hält. > Genau den "Krempel" der Teil des Ganzen ist. Wer will, kann rust und > alles drumrum als Krempel bezeichnen. Ich find es gut. Es ist halt nicht > so billig zu erlernen wie z.b. Java oder Basic. :-) Das liest sich jedenfalls interessant... ich glaube, das schaue ich mir mal genauer an. Andererseits, Java mit seinem OO-Zwang "billig zu erlernen" zu nennen, hat hier, wo OOP als Teufelszeug gilt, eine gewisse Komik. :-D
Ein T. schrieb: > ich glaube, das schaue ich mir mal genauer an. Ja, mach das! Aber für Embedded z.Zt. eher nicht geeignet (also ich würds mir nicht antun). Allerdings gibt es eine Referenzplattform auf einem STM32. https://docs.rust-embedded.org Bei der Gelegenheit fällt Dir dann hoffentlich die IMHO gute Doku von rust auf. Rust hat knallharte Regeln die auch durchgezogen werden. > Andererseits, Java mit seinem OO-Zwang "billig zu > erlernen" zu nennen, hat hier, wo OOP als Teufelszeug gilt, eine gewisse > Komik. :-D Wenn man von C++ kommt, dann find ich Java "billig". Ich hab damals[tm] den OOP-Hype mitgemacht. Also das funktioniert schon. Aber sein Platz ist eher der Desktop oder der Server. Mich interessiert Java nicht mehr. OOP ist oft genug wirklich sinnvoll. Vom Denkansatz her geht das aber selbst mit schnödem C.
Ein T. schrieb: > Ah, okay. Was make(1) angeht... ich finde es immer wieder verblüffend, > wie lange sich das olle Ding hält. Sicherlich noch viel länger als die meisten von uns sich halten werden. ;-) Und das ist auch gut so, schließlich wird es tagtäglich zig-tausendfach zur vollsten Zufriedenheit genutzt.
Nick schrieb: > Ja, mach das! :-) > Aber für Embedded z.Zt. eher nicht geeignet Embedded mach' ich eh nicht (mehr) so oft und wenn, ist Cpp mein Freund. :-) > Bei der Gelegenheit fällt Dir dann hoffentlich die IMHO gute Doku von > rust auf. > Rust hat knallharte Regeln die auch durchgezogen werden. Jo, hab' schon ein bisschen 'reingelesen, sieht richtig gut aus. > Wenn man von C++ kommt, dann find ich Java "billig". Ich hab damals[tm] > den OOP-Hype mitgemacht. Also das funktioniert schon. Bitte nicht flashc verstehen: ich mag OOP sehr, mag mich aber nicht darauf festnageln lassen. Java mochte ich noch nie, diese Arbeit hätte ich damals lieber in Cpp investiert gesehen. :-) > OOP ist oft genug wirklich sinnvoll. Vom Denkansatz her geht das aber > selbst mit schnödem C. Im Kern unterstützt OO doch weitgehend nur, was auch in den prozeduralen Sprachen als guter Stil gilt... und dazu kommt dann noch die so häufig überstrapazierte Vererbung. Aber wenn man sowas hier im Forum sagt, geben einem die anderen alten weißen Männer immer so viele Minuspunkte. :-)
Ein T. schrieb: > Bitte nicht flashc verstehen: ich mag OOP sehr, mag mich aber nicht > darauf festnageln lassen. Java mochte ich noch nie, diese Arbeit hätte > ich damals lieber in Cpp investiert gesehen. :-) Ist aber kein Zeitverlust, weil OOP in C++ eher rudimentär implementiert ist. Viel wichtiger sind da die Templates oder die Polymorphie richtig einzusetzen. Jedenfalls ist C++ nicht unbedingt die beste Programmiersprache um sich OOP tiefschürfend einzusaugen. Darüberhinaus schiele ich gerade ein wenig nach D. Ich meine, du hast ja Python, sonst könnte C# auch noch eine Empfehlung sein.
Rbx schrieb: > Ist aber kein Zeitverlust, weil OOP in C++ eher rudimentär implementiert > ist. Oh... dabei gehen mit Cpp ein paar Sachen, die nicht einmal das hochgelobte Java kann. Was genau fehlt Dir denn bei Cpp? > Viel wichtiger sind da die Templates oder die Polymorphie richtig > einzusetzen. Ich glaube, es ist immer wichtig, die passenden Werkzeuge zu wählen und sie dann natürlich auch richtig einzusetzen. > Jedenfalls ist C++ nicht unbedingt die beste Programmiersprache um sich > OOP tiefschürfend einzusaugen. Ach, bei mir hat es mit C, Cpp und Perl -- dessen nachträglich angeflanschte Objektorientierung wirklich lustig war, da mußte man seine Objekte segnen (bless) -- IMHO ziemlich gut geklappt. Aber ich habe ja auch noch ein paar andere Sprachen, unter anderem auch Java. In diesem Zusammenhang finde ich auch Golang mit einer OOP ohne Vererbung und einem ganz eigenen Verständnis von Interfaces ziemlich spannend. :-) > Darüberhinaus schiele ich gerade ein wenig nach D. Kann es eventuell möglicherweise vielleicht sein, daß Du eine gewisse... Neigung zu Exoten hast? :-) > Ich meine, du hast ja Python, sonst könnte C# auch noch eine Empfehlung > sein. Ach, wie gesagt, ich hab' noch ein paar andere Sprachen... aber klar, Python hat schon einen ziemlich hohen Coolheitsfaktor... ;-)
Ein T. schrieb: > Oh... dabei gehen mit Cpp ein paar Sachen, die nicht einmal das > hochgelobte Java kann. Was genau fehlt Dir denn bei Cpp? Was willst du da jetzt hören? C++ ist komplex und OOP ist ebenfalls reichlich komplex, erst recht vor dem Hintergrund der Implementierung. Da sind doch Programmierspachen wie Java oder Objective-C erstmal wesentlich hilfreicher um einen gewissen Überblick über OOP zu bekommen. Ganz abgesehen davon stehen bei Java und Objective-C das Nachrichten austauschen eher im Vordergrund. Dazu gehören auch eine gewisse Strenge und Demut, da interessiert es erstmal nicht, was man mit C++ sonst noch alles anstellen kann oder könnte. Spannender wäre in diesem Zusammenhang vielleicht, was man hinsichtlich OOP mit Ruby alles anstellen könnte ;) Die KI kann man irgendwie gar nicht fragen, wie das mit dem OOP in Rust ist. Da landet man letztendlich wieder mal bei: https://www.reddit.com/r/rust/comments/1pyv0vb/thoughts_on_oop/?tl=de https://www.reddit.com/r/rust/comments/1h48us2/opinions_on_rust_in_scientific_settings/ ;) SPJ meinte mal sowas wie die "Signatur" wäre das UML in Haskell. Naja, man muss ja Haskell nicht mögen, aber sowas wie Compiler programmieren erschien mir früher viel schwieriger. Dank einiger Haskell-Papers verstehe ich solche Zusammenhänge deutlich besser. Exploring Verse, Haskell, Language Design and Teaching (with Simon Peyton Jones) https://www.youtube.com/watch?v=UBgam9XUHs0 Ein kleiner Anfang hinsichtlich schneller compilieren: Solving Rust’s biggest problem https://www.youtube.com/watch?v=P1cJJMLMEKk
Rbx schrieb: > Die KI kann man irgendwie gar nicht fragen, wie das mit dem OOP in Rust > ist. Welche hast du denn gefragt? Hast du einfach mal in die Doku geguckt? Kapitel 18. https://doc.rust-lang.org/book/ch18-00-oop.html https://doc.rust-lang.org/book/ch18-01-what-is-oo.html https://doc.rust-lang.org/book/ch18-02-trait-objects.html https://doc.rust-lang.org/book/ch18-03-oo-design-patterns.html
Rbx schrieb: > Was willst du da jetzt hören? Naja, Du hattest geschrieben, daß Deiner Meinung nach: Rbx schrieb: > [...] OOP in C++ eher rudimentär implementiert ist. Wenn ich "rudimentär" jetzt so interpretiere, wie die Google-KI das macht ("unvollständig, unvollkommen, nur in Ansätzen [vorhanden], unzureichend"), dann scheint Dir dabei doch etwas zu fehlen. Da wüßte ich gern, was. > C++ ist komplex und OOP ist ebenfalls > reichlich komplex, erst recht vor dem Hintergrund der Implementierung. Hm... okay, Cpp hat seine Eigenheiten, aber die OOP als solche empfinde ich jetzt nicht als übermäßig komplex -- im Gegenteil finde ich, OOP fühlt sich häufig viel natürlicher an als prozedurale oder funktionale Programmierung. > Da sind doch Programmierspachen wie Java oder Objective-C erstmal > wesentlich hilfreicher um einen gewissen Überblick über OOP zu bekommen. Objective-C kenne ich nicht, aber... die OOP von Java steht hinsichtlich ihrer Komplexität der von Cpp wenig nach, finde ich. Ok, in Java gibt es keine echte Mehrfachvererbung wie in Cpp oder Python, aber die braucht man ja eher selten, und kann in Java etwas Ähnliches mit Interfaces abbilden. > Ganz abgesehen davon stehen bei Java und Objective-C das Nachrichten > austauschen eher im Vordergrund. Kannst Du das bitte näher erläutern? DAnke. > Spannender wäre in diesem Zusammenhang vielleicht, was man hinsichtlich > OOP mit Ruby alles anstellen könnte ;) Ruby habe ich mir vor einigen Jahren mal näher angeschaut, als mein Team eine gemeinsame Skriptsprache etablieren wollte und Ruby einer der Kandidaten war. Grundsätzlich würde ich aus der Erinnerung heraus vermuten, daß dabei ziemlich ähnliche Dinge möglich sind wie mit anderen OO-Sprachen. > Die KI kann man irgendwie gar nicht fragen, wie das mit dem OOP in Rust > ist. Du kannst in die Dokumentation [1] schauen. Ich hab' mich noch nicht besonders tief in Rust hineingefuchst -- und habe gerade auch andere Dinge zu erledigen -- aber Rust scheint ein OO-Modell ähnlich dem von Golang zu haben, zusätzlich allerdings sogenannte Traits. Structs und Interfaces sind auch aus den anderen OO-Sprachen bekannt und Traits sind Funktionen, die mehrere Structs benutzen können, soweit ich das bisher verstanden habe. Eine Vererbung, so wie wir sie kennen, scheint es nicht zu geben, und wenngleich ich Vererbung als nützliches Feature sehe, weiß ich auch, wie oft sie mißbraucht wird -- darum verzichten beispielsweise Golang und anscheinend auch Rust darauf. [1] https://doc.rust-lang.org/book/ch05-03-method-syntax.html > Da landet man letztendlich wieder mal bei: > https://www.reddit.com/r/rust/comments/1pyv0vb/thoughts_on_oop/?tl=de > https://www.reddit.com/r/rust/comments/1h48us2/opinions_on_rust_in_scientific_settings/ Warum auch immer, lande ich eher selten auf Reddit. :-) > SPJ meinte mal sowas wie die "Signatur" wäre das UML in Haskell. Was ist SPJ? Und ist mit "UML" die Unified Modeling Language gemeint? Welche Zusammenhänge gibt es zwischen der Unified Modeling Language und Haskell? > Naja, man muss ja Haskell nicht mögen, aber sowas wie Compiler > programmieren erschien mir früher viel schwieriger. Dank einiger > Haskell-Papers verstehe ich solche Zusammenhänge deutlich besser. Ich hab' weder etwas für, noch gegen Haskell. ich weiß darüber nicht viel. Es ist wohl eine funktionale Programmiersprache, mit einer Syntax, die sich mir nicht auf Anhieb erschließen möchte, und das von mir gerne und oft eingesetzte Programm pandoc(1) ist wohl damit geschrieben. Außerdem sollen Programme, die in Haskell geschrieben worden sind, nicht besonders performant sein -- sofern ich mich recht entsinne, hattest Du das hier mal erwähnt? > Exploring Verse, Haskell, Language Design and Teaching (with Simon > Peyton Jones) > https://www.youtube.com/watch?v=UBgam9XUHs0 > > Ein kleiner Anfang hinsichtlich schneller compilieren: > Solving Rust’s biggest problem > https://www.youtube.com/watch?v=P1cJJMLMEKk Danke für die Links, die habe ich mir mal gespeichert. Aber mein Interesse am Compilerbau steht auf meiner Liste aktuell sehr, sehr weit hinten. :-)
Ein T. schrieb: > zusätzlich allerdings sogenannte Traits. Structs und > Interfaces sind auch aus den anderen OO-Sprachen bekannt und Traits sind > Funktionen, die mehrere Structs benutzen können, soweit ich das bisher > verstanden habe. Rust hat 3 Sachen: - Traits - Structs - Enums Traits müssen auf Structs oder Enums implementiert werden und sind am besten als Interface zu verstehen. Von einem Trait kann kein Objekt erstellt werden. Traits können ein Default verhalten bereitstellen, müssen es aber nicht. Methoden können für Structs und Enums implementiert werden. Ein T. schrieb: > Eine Vererbung, so wie wir sie kennen, scheint es nicht > zu geben Das ist richtig. Es wird composition over inheritance bevorzugt.
:
Bearbeitet durch User
Kaj G. schrieb: > Traits müssen auf Structs oder Enums implementiert werden und sind am > besten als Interface zu verstehen. Von einem Trait kann kein Objekt > erstellt werden. Traits können ein Default verhalten bereitstellen, > müssen es aber nicht. Methoden können für Structs und Enums > implementiert werden. Ja, das hatte ich in Deinen Links (danke dafür!) auch mittlerweile gelesen, Traits sind offenbar so etwas wie Golang-Interfaces auf Steroiden. :-) > Das ist richtig. Es wird composition over inheritance bevorzugt. Auch das erinnert mich stark an Golang... :-)
Korrektur: "Vererbung" gibt es in beschränktem Maße, mit Derive:
1 | #[derive(Debug, Copy, ...)] |
2 | struct MyStruct {
|
3 | ... |
4 | } |
Das wird an vielen Stellen benutz. Wenn ein Objekt mit <>= Operatoren Vergleichbar sein soll:
1 | #[derive(Eq, PartialEq)] |
2 | struct MyStruct {
|
3 | ... |
4 | } |
wenn ein Objekt mit Serde (de)serialisierbar sein soll.
1 | #[derive(serde::Deserialize, serde::Serialize)] |
2 | struct MyStruct {
|
3 | ... |
4 | } |
Wobei ich mich nie damit beschäftigt habe, was die Voraussetzungen sind, damit etwas per Derive benutzt werden kann. Und ich verstehe es mehr als "short cut" zu einem
1 | impl serde::Deserialize for MyStruct {
|
2 | ... |
3 | } |
4 | |
5 | impl serde::Serialize for MyStruct {
|
6 | ... |
7 | } |
Ein T. schrieb: > danke dafür! Gerne :)
Ein T. schrieb: > Objective-C kenne ich nicht, aber... ObjC ist eine schöne Sprache. Aber ich sehe keinen Sinn darin heute noch dafür Energie reinzustecken. Das wird kaum unterstützt, ausser man greift auf die üblichen Kommandozeilen-Geschichten zurück. ObjC ist auch irgendwie eigenartig in der Syntax. Man muss bei jedem Funktionsaufruf den Parameternamen und den Parameter angeben. Änlich wie man es bei Verilog machen kann. Nur, man muss. Die OOP-Geschichten sind einfach angelegt. Man könnte auch rudimentär sagen. Was aber extrem witzig ist, es ist eine dynamische Sprache. Nein, in C++ ist das <dynamic> (oder wie das war) eine Tatsachenvortäuschen. Das <dynamic> muss zu compile-time auflösbar sein. In ObjC passiert das zur Laufzeit. Dazu weist ObjC für Variablen keinen Speicherplatz zu, sondern bildet einen hash. Zur Laufzeit wird dann über den hash auf die Variable zugegriffen. Man kann sogar zur Laufzeit einen Variablennamen aus Strings zusammenfassen, sich den hash geben lassen und dann auf diese Variable zugreifen. Ach ja, man muss sich damit abgeben, dass die Tasten [ und ] extremen Verschleiß unterliegen. Gefühlt sind 10% des codes eckige Klammern. :-]] Ich hoffe, ich verwechsel das folgende jetzt nicht mit einer anderen Sprache: Das dynamische Verhalten geht sogar so weit, dass man zur Laufzeit nachschauen kann ob in einem record ein bestimmtes Feld existiert und kann auch nachträglich ein beliebiges hinzufügen. Damit kann man u.a. Vererbung implementieren. Mir hat die Arbeit mit ObjC riesen Spaß gemacht und ich trauere dem ein wenig hinterher. rust und OOP: Vorsicht! Wenn man von C++ kommt, sollte man das C++ lieber komplett vergessen. C++ arbeitet mit Pointern, und die gibt es in Rust einfach nicht. Man kann das umschiffen mit unsafe code, aber da kommt nur massiv Ärger dabei raus. Sinnvoll geht es nur mit enums. Wobei die enums komplett nichts mit den enums von C zu tun haben. Das nur als Warnung. Die pointer innerhalb von z.B. arrays oder strings umgeht rust mit slices. Ich find die sehr genial. Die slices sind sicher (Pointerüberlauf unmöglich), aber fast genauso effektiv. Man muss sich schon umgewöhnen wenn man von C kommt. Manches existiert einfach nicht, oder wird anders gemacht. Auch wenn man glaubt, dass rust C-ähnlich ist. Ja und Nein. Und mit der Brechstange kommt man in rust nicht weiter. In C ist die Brechstange oft ein nützliches (und gefährliches) Mittel. rust bezeichnet sich als sichere Programmiersprache und setzt das auch gnadenlos durch. BTDT.
Kaj G. schrieb: > Rbx schrieb: >> Die KI kann man irgendwie gar nicht fragen, wie das mit dem OOP in Rust >> ist. > Welche hast du denn gefragt? Die übliche halt, Google eben. Mein Hintergrundgedanke dazu war u.a. MPI oder openMP, ATLAS in Octave - oder was sich sonst so bei C-Sprachen anbietet, um die Laufzeit von Programmen schneller ablaufen zu lassen. Bei Haskell lohnt es sich, die wissenschaftlichen Papers von SPJ zur Parallelisierung des GHC zu lesen, das gibt Einblicke darüber, dass man sich bei der Parallelisierung mit Haskell auch schon größere Mühe gemacht hatte. Immerhin gib es bei Rust sowas: https://github.com/rsmpi/rsmpi
Nick schrieb: > ObjC ist eine schöne Sprache. Aber ich sehe keinen Sinn darin heute noch > dafür Energie reinzustecken. Das wird kaum unterstützt, ausser man > greift auf die üblichen Kommandozeilen-Geschichten zurück. ObjC hab' ich irgendwie immer mit Apple assoziiert -- und ich mag Macs, wurde aber nach dem HP 97 und dem VC20 schon früh mit UNIX sozialisiert. :-) > Was aber extrem witzig ist, es ist eine dynamische Sprache. Liest sich interessant, aber... wenn ich mir alles näher anschaue, das ich interessant finde, dann komme ich ja zu gar nichts mehr. :-) > rust und OOP: > Vorsicht! Wenn man von C++ kommt, sollte man das C++ lieber komplett > vergessen. C++ arbeitet mit Pointern, und die gibt es in Rust einfach > nicht. Man kann das umschiffen mit unsafe code, aber da kommt nur massiv > Ärger dabei raus. Sinnvoll geht es nur mit enums. Wobei die enums > komplett nichts mit den enums von C zu tun haben. Das nur als Warnung. Danke für die Warnung, aber... ich mag C++ und seine OOP zwar, aber ich bin nicht sonderlich darauf fixiert, und komme ja auch mit Java, Python, Golang, und früher mit Perl5, mit ihren OOP-Varianten und ihren bisweilen subtilen Unterschieden gut zurande. Insbesondere Go scheint Rust bei der OO zu ähneln -- und Slices gibt es auch in Go. Lustig unter Go ist, daß sogar Funktionen Methoden haben können [1]... Rust und ich werden -- wenn es soweit ist -- vermutlich schnell Freunde, da mache ich mir wenig Sorgen. Auf der anderen Seite bleibt Go für mich aktuell wichtiger, weil im Moment so viel Infrastrukturzeug damit entwickelt wurde: Kubernetes, Docker, Podman, Traefik, Caddy, um nur ein paar zu nennen. [1] https://kinbiko.com/posts/2021-01-10-function-types-in-go/
Ein T. schrieb: > Rust und ich werden -- wenn es soweit ist -- vermutlich schnell Freunde, Der Hoare ist allerdings später zu Swift übergelaufen. Ich bin mir jetzt auch nicht sicher, ob die Entwurfsmuster so gut zu Rust passen, das meiste dazu läuft eher über OO. Nun ist man bei Rust auf jeden Fall auf einer sichereren Seite, wenn man sich mit dem Real World Haskell-Buch Kapitel 4 (https://book.realworldhaskell.org/read/) befasst hat. Kommt mir im Moment wie Kinderkram vor - aber damals brauchte ich schon ein paar Tage, wenn nicht Wochen, damit fertig zu werden. Was ist daran so besonders? Naja, bekommt auf jeden Fall schon mal eine Ahnung, welche Art von Jonglage sich mit den "Typen" so anstellen lassen. Da ist dann das Beschäftigen mit dem Lambda-Kalkül schon etwas beruhigender. Netterweise kann man Inline-Assembly in Rust machen - spricht schon mal für Rust ;)
Nick schrieb: > Vorsicht! Wenn man von C++ kommt, sollte man das C++ lieber komplett > vergessen. C++ arbeitet mit Pointern Nein. Es kann mit Zeigern arbeiten. Das ist eben die Erbsünde der gewollten C-Komptibilität. Sauberer C++-Code braucht keine Zeiger. Das Problem bei C++ ist einfach: Es ist unendlich schwer, das sicher zu verwenden. Denn es schleppt so ziemlich alle Unsicherheiten seit Asm mit und macht sie für den Programmierer jederzeit leicht verfügbar. Nur mit sehr viel Disziplin kann man C++ sicher bekommen. Allerdings: bei Rust sieht das letztlich nicht viel anders aus. Da wird die Unsicherheit eigentlich auch nur aus dem Sprachumfang ausgelagert und in die importierte Softwaremodule verschoben. Man sieht es also nicht mehr so leicht. Das ist eigentlich auch schon alles. Nur theoretisch ist also Rust wenigstens Speicher-sicher. Wenn nix importiert werden muss. Praktisch muß aber fast immer was importiert werden. All die Lücken in den importierten Teilen kann also auch Rust-Verwendung nicht beheben. Das allerdings ist auch wieder nix wirklich neues. Es gab ja schon das Konzept der "managed"-Sprachen (Java, C# usw.). Aber bei denen ist es letztlich ganz genauso. Solange sie nix importieren, sind sie nutzlos. Und wenn sie was importieren, ist der Nutzen des Managing eher begrenzt. Bestenfalls für den Teil des Codes wirksam, der in der jeweiligen Sprache verfasst wurde.
Ob S. schrieb: > Das Problem bei C++ ist einfach: Es ist unendlich schwer, das sicher zu > verwenden. Verwende doch einfach dein früheres Pseudonym weiter, dann kommt man nicht auf die Idee, Du könntest irgendwas sachliches über Programmiersprachen schreiben.
Ob S. schrieb: > Nein. Es kann mit Zeigern arbeiten. Das ist eben die Erbsünde der > gewollten C-Komptibilität. In rust geht der gewollte und/oder notwendige "Blödsinn" mit Zeigern der aus C bekannt ist nicht. Selbst mit unsave wirds es schwierig. Ob S. schrieb: > Sauberer C++-Code braucht keine Zeiger. Geniales Argument! Es hat aber unsichere Zeiger. Ich selbst verwende schon ewig kein C++ mehr. Die Sprache ist völlig aus dem Ruder gelaufen. Und mir fällt dazu immer Stroustrup ein, als er auf einem Vortrag sinngemäß sagte: Wenn ich gewusst hätte was aus C++ wird, hätte ich es nicht angefangen.
Nick schrieb: > Geniales Argument! Sich mit "C-Hater" über Programmiersprachen zu unterhalten ist ähnlich sinnlos, wie mit einer Taube Schach spielen zu wollen - irgendwann wirft sie alle Figuren um und kackt aufs Schachbrett.
Ob S. schrieb: > Es kann mit Zeigern arbeiten. Das ist eben die Erbsünde der gewollten > C-Komptibilität. Sauberer C++-Code braucht keine Zeiger. Googles junge Go Sprache (die extra für den Einsatz unerfahrener Entwickler konzipiert wurde), setzt ebenfalls fest auf Zeiger. Referenzen hat man weg gelassen. Alles was bei der Übergabe nicht kopiert werden soll geht über Zeiger. Und kopierte structs als Argument sind tückisch, weil es keine deep Kopien sind. Also erleben Zeiger ein regelrechtes Revival in Go.
:
Bearbeitet durch User
Rbx schrieb: > Die übliche halt, Google eben. Mein Hintergrundgedanke dazu war u.a. MPI > oder openMP, ATLAS in Octave - oder was sich sonst so bei C-Sprachen > anbietet, um die Laufzeit von Programmen schneller ablaufen zu lassen. Für die Parallelisierung von Programmen gibt es zunächst zwei altbewährte Techniken, nämlich Multiprocessing und Multithreading. Du hingegen sprichst jetzt zum wiederholten Mal von MPI. Warum eigentlich?
Rbx schrieb: > Ich bin mir jetzt auch nicht sicher, ob die Entwurfsmuster so gut zu > Rust passen, das meiste dazu läuft eher über OO. Mir fällt eine ganze Reihe von GoF-Entwurfsmustern ein, die sich zumindest mit Golang leicht realisieren lassen. Da der Rust-Weg dem von Golang sehr ähnlich zu sein scheint, würde ich da wenig Probleme erwarten. > Nun ist man bei Rust auf jeden Fall auf einer sichereren Seite, wenn man > sich mit dem Real World Haskell-Buch Kapitel 4 > (https://book.realworldhaskell.org/read/) befasst hat. Man soll ein Haskell-Buch lesen, um Rust zu lernen? > Netterweise kann man Inline-Assembly in Rust machen - spricht schon mal > für Rust ;) Ob es ein besonderes Merkmal einer Programmiersprache ist, eine andere Sprache darin einbetten zu können... hm, hm, hm.
Nemopuk schrieb: > Googles junge Go Sprache (die extra für den Einsatz unerfahrener > Entwickler konzipiert wurde), setzt ebenfalls fest auf Zeiger. > Referenzen hat man weg gelassen. Alles was bei der Übergabe nicht > kopiert werden soll geht über Zeiger. Und kopierte structs als Argument > sind tückisch, weil es keine deep Kopien sind. Also erleben Zeiger ein > regelrechtes Revival in Go. Naja, die schwierigen Teile wie die Zeigerarithmetik haben wie weggelassen, das eliminiert zumindest einige der fehleranfälligeren Aspekte -- und für Arrays / Slices und Maps gibt es native Datentypen. Andererseits kann man Golangs Zeiger gewinnbringend nutzen, um unnötige Kopien (Kontextwechsel!) etwa bei Methodenaufrufen oder dem Messaging über Channels zu vermeiden. Okay, nach den Erfahrungen mit C kann ich schon irgendwo nachvollziehen, daß manche Leute beim Wort "Zeiger" gerne die Nase rümpfen. Aber nichtsdestotrotz können Zeiger, mit Bedacht genutzt, ein sehr nützliches Werkzeug sein.
Harald K. schrieb: > Nick schrieb: >> Geniales Argument! > > Sich mit "C-Hater" über Programmiersprachen zu unterhalten ist ähnlich > sinnlos, wie mit einer Taube Schach spielen zu wollen - irgendwann wirft > sie alle Figuren um und kackt aufs Schachbrett. Naja, irgendwann... beim C-Haider ist das der Eröffnungszug. :-)
Ein T. schrieb: > Du hingegen sprichst jetzt zum wiederholten Mal von MPI. Warum > eigentlich? Warum eigentlich nicht? Wäre zumindest ein Hintergrund, am Ende doch lieber Fortran zu nehmen. Aber es gibt natürlich auch Leute, die denken, die kommen mit Python überall hin obwohl die Grafikkartenschnittstelle bei Cuda nach wie vor C und C++ vorgibt. Ist natürlich auch eine nette Sache mit Wrappern für x und y nicht-C-oder-C++-Programmiersprache - sofern das Problem selber mitmacht. Für Haskell musste man ja auch erstmal suchen welche Programme die Vorteile zeigen - während auf der anderen Seite die Low-Level-Ebene völlig außen vor bleibt und die Anbindung außer an C ->naja.. (oder Grafik bei Haskell, einfaches Plotten, z.B. wie bei Octave oder Python, müsste doch auch gehen - scheint aber keinen Vorrang zu haben, Rechnen mit Hexzahlen nicht, Spiele auch nicht oder professionelle Programme mit Industriestandard erst recht nicht - allenfalls mühsam zusammengesucht als POC.) Und apropos Low-Level-Ebene: Jetzt kann man bei Rust direkt an ein Code-Fragment dranschreiben: "Unsafe". Weißt du wo der Vorteil dieser Geschichte ist? Früher bei Spickzetteln meinte mal eine Lehrerin, die Spickzettel haben den Vorteil, dass man die zu merkenden Sachen zuerstmal aufschreiben muss. Mit etwas Glück braucht es anschließend den Spickzettel gar nicht mehr. Überhaupt, man kann so tolle Sachen mit LEA machen - da darf ich aber gar nicht lange drüber nachdenken, sonst lande ich am Ende doch wieder bei der Suche nach Möglichkeiten für Linux-Assembly und dann findet man zuerst oft Seiten wie https://www.hackingarticles.in/64-bit-linux-assembly-and-shellcoding/ Ein T. schrieb: > Man soll ein Haskell-Buch lesen, um Rust zu lernen? Ne, nur das verlinkte Kapitel 4 verstehen. Man könnte sich theoretisch auch damit beschäftigen: https://ocaml.org/ Aber jetzt würde ich sagen, schauen wir uns doch einfach mal Rust genauer an. Bei Println! fragt man sich ein wenig, wo das "#" vorm Ausrufezeichen bleibt. Bei PC-Assembler hat man allerdings auch nicht alles an Firlefanz im Griff, z.B. brauchte man üblicherweise die recht umfangreiche Interrupt-Liste von Ralf Brown. Oder auch DOS hatte seine eigenen Interrupts oder eben verschiedene Programme. Spätere Compilerpackete hatten sich auch um den Segmentteil gekümmert, so dass man das nicht mehr selber machen musste.
Rbx schrieb: > Bei PC-Assembler ... brauchte man üblicherweise die recht umfangreiche > Interrupt-Liste von Ralf Brown. Diese Zeiten sind seit zig Jahren vorbei, das war im letzten Jahrtausend. Unter Windows, Linux, BSD, ... ruft man OS Funktionen ganz sicher nicht mehr per Interrupt auf.
:
Bearbeitet durch User
Nemopuk schrieb: > ruft man OS Funktionen ganz > sicher nicht mehr per Interrupt auf. Doch, wenn man Spiele mit Haskell programmiert.
Rbx schrieb: > Ein T. schrieb: >> Du hingegen sprichst jetzt zum wiederholten Mal von MPI. Warum >> eigentlich? > > Warum eigentlich nicht? Wäre zumindest ein Hintergrund, am Ende doch > lieber Fortran zu nehmen. Nee, sorry, vor FORTRAN bin ich FORTgeRANnt. :-) > Aber es gibt natürlich auch Leute, die denken, die kommen mit Python > überall hin obwohl die Grafikkartenschnittstelle bei Cuda nach wie vor C > und C++ vorgibt. Es war eines der wichtigsten Designziele von Python und ist bis heute eine seiner großen Stärken, eine gute Glue-Sprache zu sein. > Und apropos Low-Level-Ebene: > Jetzt kann man bei Rust direkt an ein Code-Fragment dranschreiben: > "Unsafe". Weißt du wo der Vorteil dieser Geschichte ist? Mir fallen da mehrere Punkte ein, welche(n) meinst Du? > Überhaupt, man kann so tolle Sachen mit LEA machen Man kann mit vielen Dingen tolle Sachen machen. Bestimmt auch mit Lea, aber die habe ich seit unserer Pfadfinderzeit leider nicht mehr gesehen, deswegen mach ich sowas heute lieber mit meiner wunderbaren Sabrina. :-) > Ein T. schrieb: >> Man soll ein Haskell-Buch lesen, um Rust zu lernen? > > Ne, nur das verlinkte Kapitel 4 verstehen. > Man könnte sich theoretisch auch damit beschäftigen: > https://ocaml.org/ Ja, das könnte man theoretisch machen, und wenn man möchte, sicherlich auch praktisch. Allerdings stehe ich diesbezüglich leider immer wieder vor einem riesigen Problem, daß mein Tag nämlich leider nur 24 Stunden hat. > Aber jetzt würde ich sagen, schauen wir uns doch einfach mal Rust > genauer an. > Bei Println! fragt man sich ein wenig, wo das "#" vorm Ausrufezeichen > bleibt. Ehrlich gesagt glaube ich nicht, daß ich mich einer Programmiersprache mit syntaktischen Betrachtungen nähern möchte... jedenfalls, solange wir nicht über alte Versionen einer Sprache reden, vor der ich FORTgeRANnt bin. > Bei PC-Assembler hat man allerdings auch nicht alles an Firlefanz im > Griff, z.B. brauchte man üblicherweise die recht umfangreiche > Interrupt-Liste von Ralf Brown. Bei PC-Assembler hat man aber auch die Möglichkeit, es nur dann zu benutzen, wenn man es wirklich braucht. > Oder auch DOS hatte seine eigenen Interrupts oder eben verschiedene > Programme. Beides haben IIRC aber auch Linux, Solaris und die BSDs... > Spätere Compilerpackete hatten sich auch um den Segmentteil gekümmert, > so dass man das nicht mehr selber machen musste. Das machen Compiler sogar heute noch. Das finde ich super, weil meine Zeit (siehe oben) beschränkt ist, und ich vor allem deswegen mit einem Computer arbeite, damit er tut, was er besser kann als ich. :-) Wie dem auch sei: wie Du vielleicht an meinen mitunter flapsigen Antworten erkennen kannst, fällt es mir leider zunehmend schwer, Deinen Gedanken und Ausführungen zu folgen. Das liegt natürlich an mir und meinem mangelnden Intellekt, aber bitte sei doch etwas deutlicher. Dankeschön!
Ein T. schrieb: > Das liegt natürlich an mir und meinem mangelnden Intellekt, Nein, das liegt an mir.
Hallo, Ein T. schrieb: > Das liegt natürlich an mir und meinem mangelnden Intellekt... Und ich dachte es geht nur mir so. rhf
:
Bearbeitet durch User
Ein T. schrieb: > aber bitte sei doch etwas deutlicher. > Dankeschön! Und du könntest deine Fragen in Threads auch mal genauer spezifizieren, sonst müsste man glauben, dass du das nur machst, um den Leuten auf die Füsse zu treten, damit die herummaulen. ..ach so, hier noch ein Link, über den ich gestolpert bin: https://github.com/rust-unofficial/awesome-rust Nemopuk schrieb: > Diese Zeiten sind seit zig Jahren vorbei, das war im letzten > Jahrtausend. Unter Windows, Linux, BSD, ... ruft man OS Funktionen ganz > sicher nicht mehr per Interrupt auf. Du hast keine Ahnung, komische grobe Schubladen du hast. Bei Rust auf MCs muss man wohl auch alles, auch bei blinki blinki auf "unsafe" laufen lassen. Diesbezüglich wollte ich mal Emails schreiben - .. Allerdings denke ich im Moment etwas über das alte C Programm mit Celsius und Fahrenheit nach. Da könnte man aktuell wohl noch eine Version mit Rankine dazunehmen ;)
Rbx schrieb: > Da könnte man aktuell wohl noch eine > Version mit Rankine dazunehmen Réaumur nicht vergessen.
Rbx schrieb: > Bei Rust auf MCs muss man wohl auch alles, auch bei blinki blinki auf > "unsafe" laufen lassen. Geht das in Haskell oder OCaml auch? Ach so, damit kann man kein barebone "Betriebssystem" schreiben.
1 | static mut COUNTER: u32 = 0; |
2 | |
3 | #[entry] |
4 | fn main() -> ! {
|
5 | set_timer_1hz(); |
6 | let mut last_state = false; |
7 | loop {
|
8 | let state = read_signal_level(); |
9 | if state && !last_state {
|
10 | // New critical section ensures synchronised access to COUNTER |
11 | cortex_m::interrupt::free(|_| {
|
12 | unsafe { COUNTER += 1 };
|
13 | }); |
14 | } |
15 | last_state = state; |
16 | } |
17 | } |
18 | |
19 | #[interrupt] |
20 | fn timer() {
|
21 | unsafe { COUNTER = 0; }
|
22 | } |
Sicherlich hast Du eine Lösung wie man das sonst ohne unsafe machen könnte. Vorläufig kannst Du aufzeigen, wie man da das "Alles" finden kann. Rbx schrieb: > scheint aber keinen Vorrang zu haben, > Rechnen mit Hexzahlen nicht, Welche Sprache ist das denn in der man Hex darstellen kann, aber nicht damit rechnen? foo = 0xD000 + 0x0F; Rechne mal kurz nach!
:
Bearbeitet durch User
Harald K. schrieb: > Réaumur nicht vergessen. Das ist aber alt, und passt nicht ganz zu Rust. Eigentlich müsste diesbezüglich eher was mit L finden, was zu Lisp passt ;) Nick schrieb: > Sicherlich hast Du eine Lösung wie man das sonst ohne unsafe machen > könnte. So ganz indirekt mit viel Know How - nur hat das eben nicht jeder. Ganz abgesehen von so manchen Dokumentationen oder wenig Doku, oder teilweise Doku oder gar nicht da Doku. Ich bin aber kein Programmiersprachenentwickler, also warum fragst du mich das überhaupt? Schließlich habe ich Rust nicht erfunden, sondern versuche im Moment nur etwas Informations Gathering zu betreiben. Nick schrieb: > Welche Sprache ist das denn in der man Hex darstellen kann, aber nicht > damit rechnen? Ja, bei Haskell gibt es wohl eine Bib mit der das geht. Sollte aber eigentlich kein Problem beim ghci mit Standardausrüstung sein. Kannst du selbst überprüfen. Gib deine Rechnung oben in den ghci ein und schau was herauskommt. Könnte man natürlich auch auf Papier machen, aber darum geht es hier wohl nicht.
Rbx schrieb: > Und du könntest deine Fragen in Threads auch mal genauer spezifizieren, > sonst müsste man glauben, dass du das nur machst, um den Leuten auf die > Füsse zu treten, damit die herummaulen. Okay, dann stelle ich eine frühere Frage noch einmal. Was genau emfindest Du an der OO von Cpp als "rudimentär"? > ..ach so, hier noch ein Link, über den ich gestolpert bin: > https://github.com/rust-unofficial/awesome-rust Danke für den Link, das ist sicherlich eine wertvolle Ressource. Genauso wie die vielen anderen kuratierten "Awesome"-Listen, etwa für Python [1], Go [2] und sogar einzelne Frameworks wie zum Beispiel Gofiber [3]. Viele der Listen werden sehr gut gepflegt und sind dann oft absolut großartige Quellen. [1] https://github.com/vinta/awesome-python [2] https://github.com/avelino/awesome-go [3] https://github.com/gofiber/awesome-fiber
Ein T. schrieb: > Okay, dann stelle ich eine frühere Frage noch einmal. Was genau > emfindest Du an der OO von Cpp als "rudimentär"? Du schriebest ja oben selbst, dass du OO nicht so komplex findest. Naja, dann könnte man so antworten, dass die Einfachheit von OO in C++ etwas untergeht. Steht auch nicht im Vordergrund, ganz abgesehen von didaktischen Hintergründen, wo die anderen Programmiersprachen das Umdenken etwas leichter machen.
Rbx schrieb: > Schließlich habe ich Rust nicht erfunden, sondern > versuche im Moment nur etwas Informations Gathering zu betreiben. Um Informationen über Software allgemein und besonders Programmiersprachen zu gewinnen, bieten sich zunächst ihre offiziellen Dokumentationen an. Meistens gibt es diese online und häufig sogar kostenlos. Dort findest Du sicher viel bessere Informationen als mit wilden Recherchen im Netz und KI-Modellen. Für viele Programmiersprachen gibt es zudem so genannte "Bücher", häufig mit einem Namen wie "The <you-name-it> Programming Language", oft ergänzt durch weitere Werke, die häufig "A Tour Of <you-name-it>". Beispiele: "The C++ Programming Language" [1] und "A Tour Of C++" von Bjarne Stroustrup [2], die sind leider kostenpflichtig, auch wenn man sie im Internet als PDF finden kann. Für C++ gibt es sogar ein ausgesprochen lesenswertes und kluges Buch namens "The Design and Evolution of C++" von Bjarne Stroustrup, in dem er beschreibt, wie er die Sprache C++ entwickelt hat, und warum er welche Designentscheidungen getroffen hat. "The Go Programming Language" [3] und "A Tour Of Go" [4] gibt es kostenlos im Internet, genauso "The Rust Programming Language" [5] (zudem eine interaktive Version [6]) und "The Cargo Book" [7] über das Werkzeug "Cargo", das in Rust für das Build- und Dependency-Management verantwortlich ist. Für Rust gibt es ebenfalls interaktive Tutorials, die beide "A Tour Of Rust" heißen [8,9]. Für viele Sprachen gibt es darüber hinaus Leitfäden zur effektiven Anwendung, beispielsweise "Effective Rust" [10], "Effective Go" [11], und weitere. Einige Skriptsprachen weichen von dem Namensschema ab, aber auch für Python und Perl gibt es entsprechende Dokumentationen. Viel Spaß beim Lesen! :-) [1] https://www.stroustrup.com/4th.html [2] https://www.stroustrup.com/tour3.html [3] https://www.gopl.io/ [4] https://go.dev/tour/ [5] https://doc.rust-lang.org/book/ [6] https://rust-book.cs.brown.edu/ [7] https://doc.rust-lang.org/cargo/ [8] https://tourofrust.com/ [9] https://rust-tour.dev/ [10] https://effective-rust.com/ [11] https://go.dev/doc/effective_go
Rbx schrieb: > Ein T. schrieb: >> Okay, dann stelle ich eine frühere Frage noch einmal. Was genau >> emfindest Du an der OO von Cpp als "rudimentär"? > > Du schriebest ja oben selbst, dass du OO nicht so komplex findest. Naja, > dann könnte man so antworten, dass die Einfachheit von OO in C++ etwas > untergeht. So leid es mir tut, sehe ich das nicht. Alle bekannteren OO-Features von der Datenkapselung über Vererbung, Überladung, Interfaces, Messaging: all das ist in Cpp vorhanden, auch wenn Interfaces in Cpp als abstrakte Klassen umgesetzt werden. Und im Gegensatz zu Java beherrscht Cpp sogar echte Mehrfachvererbung und das Überladen von Operatoren. Obendrein ist Cpp allerdings nicht nur eine objektorientierte Sprache wie Java, sondern eine multiparadigmatische Sprache. Das heißt, ich kann in Cpp nicht nur objektorientiert, sondern auch prozedural und funktional arbeiten, und, zugegeben, in Verbindung mit generischer Programmierung durch Templates und weiteren Features wie Move- und Copy-Semantiken wird Cpp natürlich nicht einfacher, keine Frage -- eher sogar im Gegenteil. > Steht auch nicht im Vordergrund, ganz abgesehen von didaktischen > Hintergründen, wo die anderen Programmiersprachen das Umdenken etwas > leichter machen. Hier an der RWTH in Aachen wird Cpp seit vielen Jahren gelehrt, siehe hier [1] für den Kurs im aktuellen Wintersemester. Und wenn das sogar so Feld-, Wald- und Wiesen-Sysops können wie ich, kann das gar so schwierig nicht sein. :-) Allerdings, wie gesagt, ist Cpp, aus den oben aufgeführten Gründen, durchaus umfangreicher als Java, und wer reine OOP lernen will, der ist mit Java für den Anfang womöglich besser bedient. Aber das heißt ja nicht, daß die OOP von Cpp jener von Java irgendwie nachstünde, schlecher oder unvollständig wäre, sondern nur, daß sie in Java die einzige Option und in Cpp nur ein weiteres Werkzeug in einem sehr viel größeren Werkzeugkasten ist. [1] https://www.igpm.rwth-aachen.de/studium/cpp
Rbx schrieb: > Ich bin mir jetzt auch nicht sicher, ob die Entwurfsmuster so gut zu > Rust passen, das meiste dazu läuft eher über OO. Ich habe zwei Fragen: 1. Über welche Entwurfsmuster sprechen wir hier? 2. Kannst Du noch eine andere Sprache als Haskell?
Ich ergänze um eine Frage: 3. Hast Du rustup jetzt 10 Jahre später zum laufen gebracht?
Harald K. schrieb: > Ob S. schrieb: >> Das Problem bei C++ ist einfach: Es ist unendlich schwer, das sicher zu >> verwenden. > > Verwende doch einfach dein früheres Pseudonym weiter, dann kommt man > nicht auf die Idee, Du könntest irgendwas sachliches über > Programmiersprachen schreiben. Mir scheint, das was ich schrieb, war sehr sachlich und korrekt. Wenn du anderer Meinung bist, steht es dir ja frei, sachliche Gegenargumente anzuführen.
Ein T. schrieb: > So leid es mir tut, sehe ich das nicht. Alle bekannteren OO-Features von > der Datenkapselung über Vererbung, Überladung, Interfaces, Messaging: > all das ist in Cpp vorhanden, auch wenn Interfaces in Cpp als abstrakte > Klassen umgesetzt werden. Und im Gegensatz zu Java beherrscht Cpp sogar > echte Mehrfachvererbung und das Überladen von Operatoren. Mehrfachvererbung ist generell der Schlund zur unwartbaren Hölle. Und auch nicht Teil dessen, was den Designern des OOP vorschwebte. Da war strenge Hierarchie (also Baum) intendiert, kein offener Graph. Schon aus rein praktischen Gründen. C++ zeigt (wenn man es darauf anlegt), warum die ursprüngliche OOP-Intention sich bei der Vererbung freiwillig auf einen Baum beschränkt hat... Und das Überladen von Operatoren ist zwar gelegentlich durchaus nützlich, sogar wünschenswert und (im Kontext) logisch, verführt aber durchaus auch dazu, es mißbräuchlich, rein zur Code-Obfuskation zu verwenden. Ich habe schon Code gesehen, der das tut. Da wollte wohl ein C#-Entwickler seinen Posten sichern (ja, auch C# kann Operatoren überladen). Ist ihm nicht gelungen. Im Gegenteil: Der Nachweis der mißbräuchlichen, im Sinne der Sache völlig zwecklosen Nutzung hat im Endeffekt dazu geführt, dass er rausgeflogen ist. Und am Ende wurde das mit einem Urteil eines Arbeitsgerichtes bestätigt, das explizit diesen Kündigungsgrund anerkannt hat. > Obendrein ist Cpp allerdings nicht nur eine objektorientierte Sprache > wie Java, sondern eine multiparadigmatische Sprache. Jepp. Und eine, die viele Altlasten absichtlich mitnimmt. Das macht sie überaus komplex und immanent unsicher. Ich bin fast sicher, dass es weltweit nur sehr wenige Leute gibt, die C++ vollständig "im Kopf" haben. Der weitaus überwiegende Teil der C++-Programmierer benutzt selber das, was er kennt, importiert aber ohne Nachzudenken fremde Quellen, die sich bestenfalls dadurch auszeichnen, dass sie in C++ legal sind. Soll heißen: so lange der Compiler nicht meckert, wird der Code typisch überhaupt nicht geprüft. Und selbst, wenn er meckert, geht es mehr darum, den Mecker zu entsorgen, als die Ursache zu finden...
Ob S. schrieb: > Mehrfachvererbung ist generell der Schlund zur unwartbaren Hölle. Und > auch nicht Teil dessen, was den Designern des OOP vorschwebte. Da war > strenge Hierarchie (also Baum) intendiert, kein offener Graph. Nichtsdestotrotz kann auch Mehrfachvererbung mitunter ausgesprochen nützlich sein und dann gerade die Hölle der Unwartbarkeit verhindern. Deine persönlichen Abneigungen verhindern, daß Du sachlich und objektiv über Programmiersprachen sprechen kannst. Stattdessen schreibst Du so viel Unfug, muß das denn wirklich sein?
Ein T. schrieb: > Nichtsdestotrotz kann auch Mehrfachvererbung mitunter ausgesprochen > nützlich sein und dann gerade die Hölle der Unwartbarkeit verhindern. Wobei die use-cases doch sehr überschaubar sein werden. Das einzige, wo mit C++ Mehrfachvererbung sehr sinnvoll ist, ist die Nachbildung der fehlenden Interfaces durch vollständig virtuelle Klassen. Oliver
Oliver S. schrieb: > Wobei die use-cases doch sehr überschaubar sein werden. Natürlich. > Das einzige, wo > mit C++ Mehrfachvererbung sehr sinnvoll ist, ist die Nachbildung der > fehlenden Interfaces durch vollständig virtuelle Klassen. Ja, das ist ein Beispiel. In Python kann Mehrfachvererbung viel nützlicher sein, aber dennoch: das ist ein Ausnahmefeature für Ausnahmefälle. Dennoch habe ich in meiner Zeit als Entwickler mindestens einen Fall in Cpp und IIRC zwei in Python gehabt wo das die beste Lösung war. Im dritten Fall unter Python haben sich die Anforderungen während der Laufzeit des Projekts geändert und deswegen war es besser davon wegzugehen. Letztlich verstehe ich Eure Punkte nur teilweise (und nein ich möchte Dich keinesfalls mit dem Hater gleichsetzen, bitte nicht falsch verstehen): das stellt ein selten genutztes aber dennoch sehr mächtiges Feature dar. Ich kann nur für mich sprechen, aber ich habe lieber mächtige Features und benutze sie nicht, als sie gar nicht erst zu haben.
Ob S. schrieb: > Mehrfachvererbung ist generell der Schlund zur unwartbaren Hölle. Und > auch nicht Teil dessen, was den Designern des OOP vorschwebte. Da war > strenge Hierarchie (also Baum) intendiert, kein offener Graph. Schon aus > rein praktischen Gründen. Ja, Simula, Algol und Smalltalk konnten anfangs nur einfache Vererbung. Das war auch der damaligen Hard- und Software geschuldet und ist deswegen kein besonders kluges Argument. > Und das Überladen von Operatoren ist zwar gelegentlich durchaus > nützlich, sogar wünschenswert und (im Kontext) logisch, verführt aber > durchaus auch dazu, es mißbräuchlich, rein zur Code-Obfuskation zu > verwenden. Ich habe schon Code gesehen, der das tut. Solchen Code habe ich auch schon gesehen. Wobei ich mir bis heute noch nicht sicher bin ob es um Obfuskation, um Unfähigkeit oder einfach nur darum ging, eine mißglückte Implementierung weiter zu benutzen weil keine Ressourcen für einen Umbau freigegeben worden sind. Aber Softwareentwicklung ist oft kein Ponyhof und Entwickler sind nicht immer frei in ihren Entscheidungen. Das gehört dazu und auch zu der Abwägung ob man besondere Features wie Mehrfachvererbung oder Operatorüberladung vorschlägt.
Oliver S. schrieb: > Wobei die use-cases doch sehr überschaubar sein werden. Das einzige, wo > mit C++ Mehrfachvererbung sehr sinnvoll ist, ist die Nachbildung der > fehlenden Interfaces durch vollständig virtuelle Klassen. Jepp. Und wenn C++ darauf beschränkt wäre, wäre ja auch alles OK. Aber C++ ist eben leider nicht darauf beschränkt. In die Hölle fährt man also über kurz oder lang ein, wenn man diese "Freiheit" tatsächlich nutzt. Das Schlimme dabei ist: zu Anfang merkt man es noch nicht. Da funktioniert i.d.R. noch alles. Aber wehe, wenn in den "Zuläufen" an mehreren Stellen erweitert wird...
Ob S. schrieb: > In die Hölle fährt man also über kurz oder lang ein, wenn man diese > "Freiheit" tatsächlich nutzt. Das C++ einem beliebig viele Möglichkeiten bietet, um sich von hinten durch die Brust ins Auge schließen kann, und das auch noch mit beliebiger Zeitverzögerung, ist ja nun nichts Neues. Sheeva P. schrieb: > Ich kann nur für mich sprechen, aber ich habe lieber mächtige Features > und benutze sie nicht, als sie gar nicht erst zu haben. So ist es. Auch wenn C++23 und C++26 den Anschein erwecken, daß da immer noch die Unsäglichkeiten aus C++11 repariert werden. Oliver
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.