|
Anzeige
|
Rust - ist das hier um zu bleiben?
Gast
#7288316
MaWin schrieb: > Ihr interpretiert da ganz einfach viel zu viel rein. Nein, ich wollte damit auch nicht ausdrücken das du dich falsch verhälst - manchmal vielleicht ein Ticken zu bissig du machst genau das warum ich hier mitlesen - die interessierten informieren und das ist gut
Gast
#7288837
Cppbert schrieb: > 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 Das ist die Theorie. Ich finde z.B. spannend, wie wohl Rust auf Solaris läuft. Habe aber im Moment aber keinen Rechner frei zum testen frei. VM finde ich nicht so hilfreich. Ich will mir ja direkt die Software/Hardware-Situation ansehen. nightly Build wird für webassembly empfohlen, sollte also grundsätzlich funktionieren. Standaloneversionen überzeugen mich bisher noch nicht. Wie soll das auch sinnvoll gehen?
Gast
#7288857
rbx schrieb: > Ich finde z.B. spannend, wie wohl Rust auf Solaris läuft. was meinst du - ob das kompilieren geht oder wie die schnell die Applikation läuft, oder...?, sollte sich nicht von einem C/C++ Code unterscheiden - so lange die Stdandard-Lib-Unterschiede nicht zu gross sind Wird ja wenn dann vom LLVM kompiliert und der wird auch beim Clang unter der Haube verwendet, gibt es Rust für Solaris oder Clang für Solaris?
Gast
#7288870
rbx schrieb: > nightly Build wird für webassembly empfohlen Wo hast du diese wirre Information denn wieder aufgeschnappt? https://rustwasm.github.io/book/game-of-life/setup.html > The Rust and WebAssembly experience is riding the Rust release trains > to stable! That means we don't require any experimental feature > flags. However, we do require Rust 1.30 or newer.
Gast
#7289126
cppbert schrieb: > gibt es Rust für Solaris oder Clang für Solaris? du schaust dir offenbar gar nicht die Links von Jörg an? Naja, und wer Daniel ist, ist dir auch nicht so recht klar, und dass es professionelle Leute sind, die nach der Zukunft von Rust gefragt hatten scheinbar auch nicht. Ts.. Das mit Solaris war auch nur ein Hinweis auf Community-Problemchen. Viele professionelle Hansel müssen sowieso das Zeug nehmen/bearbeiten, was sie vorgesetzt kriegen, oder nachplappern, was die Bwl-Abteilung haben will. Nochmal Ts.. MaWin schrieb: > Wo hast du diese wirre Information denn wieder aufgeschnappt? Das hatte ich mich auch gefragt, bzw. fragen müssen, ich kenne nämlich die offiziellen Beschreibungen bei Rust oder bei Mozilla. Es könnte was mit Arch zu tun gehabt haben, aber ganz sicher bin ich mir nicht. https://aur.archlinux.org/packages/rust-nightly-bin rbx schrieb: (Solaris) > VM finde ich nicht so hilfreich. Ich will mir ja direkt die > Software/Hardware-Situation ansehen. Wobei für einen Compiler eine VM schon erstmal genügen sollte. Ich habe hier zwar noch eine Solaris-Kiste, aber die ist hornalt (SunFire V210). War mal gedacht als Big-endian-Testmaschine, habe ich jetzt aber schon lange nicht mehr eingeschaltet, dient eigentlich nur noch als Fachboden im Rack. ;-) Ob auf dem alten Solaris ein moderner Compiler noch lauffähig ist, wage ich zu bezweifeln.
Gast
#7289184
rbx schrieb: > Das mit Solaris war auch nur ein Hinweis auf Community-Problemchen Solaris interessiert mich nicht mehr seit der Support bei meinen Kunden dafuer begraben wurde, ich glaube Solaris ist jetzt auch nicht mehr so relevant bei uns, im asiatischen Raum ist es wohl noch stärker verbreitet, aber ich hab schon lange keinen Kontakt mehr, Linux löst die Systeme alle langsam ab Ich denke, dass das seit der Übernahme durch Oracle praktisch nur noch für Datenbankserver genutzt wird.
Gast
#7289482
Jörg W. schrieb: > Ich denke, dass das seit der Übernahme durch Oracle praktisch nur > noch > für Datenbankserver genutzt wird. Ich sehe das System auch als Nearly-Dead an, FreeDOS und ReactOS haben wenigstens noch einen Spass-Faktor - Solaris nervt nur noch seit Oracle das Projekt gegen die Wand fährt und ich vestehe sowiso nicht warum jetzt FreeDOS oder ein sterbendes Solaris plötzlich irgendwie relevant ist - ja OK FreeDOS lässt sich mit GCC-IA16 bauen aber das ist ein GCC Fork der von einer Person gepflegt wird und noch leider Jahre weg ist von einer Mainline Intergration (und es war einfach nur ein riesen Glück das jemand einen echten 16bit bauenden GCC probiert hat) und für Systeme auf dem der LLVM funktioniert ist Rust definitiv nicht unmöglich - sobald die GCC-Rust Leute (was noch ein paar Jahre dauern wird) fertig sind geht dann Rust auch für alle GCC Platformen - also wieso sprechen wir über sowas? Für alte oder Legacy Projekte werde ich wie immer C/C++ oder das notwendige nutzen, mit Freude - aber ich würde schon gerne sehen das ich die nächsten 20 Jahren noch erlebe das sich vielleicht etwas günstigeres/einfacheres/fähigeres durchsetzt - und wenn nicht mach ich eben bis zu meinem Ableben C/C++ - so wie schon die letzten 30 Jahre :)
Gast
#7289730
ich habe mal testweise rustc in die Fedora33 Konsole eingegeben. Ergebnis:
..
Ich hatte ja gewisse Bedenken hinsichtlich des Speicherplatzes.. naja, so grob: Rust ist eine Programmiersprache ohne Compiler/Linker - ist eigentlich auch neu. 64 Bit-Linker habe ich auf Windows nicht. Der von D ist wohl auch 32 Bit - kann ich gerade nicht gucken, schreibe ja auf Fedora. Watcom habe ich als 32 Bit, und möchte mir diese Installation auch nicht mit der 64Bit-Variante vermurksen Möglicherweise müsste man sich den Linker selber basteln? Dann hatte ich mal in Solaris-Buch geschaut, ob es da etwas erhellendes zum Thema Linker gibt: eigentlich nichts. Aktuell auf der Haben-Seite: zumindest python ist standardmäßig drin. Wäre vielleicht was für ein Supertyp oder wie hieß der nochmal? LLVM wäre eine gute Option. Wieviel Speicherplatz braucht das, und wie kriegt man die Installation auf Userspace hin? Der Installer, den ich hatte, rief sofort nach Adminrechten. LLVM könnte für Solaris auch eine Option (bezüglich Rust) sein. Die Relevanz? Es ist doch schon irgendwie traurig, das mit OpenSolaris. Vielleicht bräuchte es noch eine OpenSolaris Foundation, oder ähnliches. Die Features wollte ich eigentlich nicht abtippen, kann ich aber doch mal machen. - Support for multiple hardware architectures, including both SPARC and 32-bit and 64-bit x86based systems. OpenSolaris also performs well in many industry benchmarks. - High scalabitity. OpenSolaris runs on both single processor maschines and multiprocessor systems with hundrets of CPUs and terrabytes of RAM - Innovative file systems and volume manager support. Solaris uses a Virtual File System (VFS) layer so that different file systems can be plugged in on top of it relatively easely. In addition to the standard Unix File System (UFS), OpenSolaris includes the Solaris Volume Manager (SVM) and the new ZFS. - Networking features, including a kernel-level, high performance TCP/IP stack, IPv6 support, IPsec, Network Auto-Magic (NWAM) for automatic detection and configuration of network interfaces, and IP Network Multipathing (IPMP for fault tolerance and load balancing. - Complex ressource management, including processor pools, physical memory controls, and fair share scheduler. - Sophisticated security, including role-based access control (RBAC), configurable privileges, and trusted extensions. - Rich observability and debugging support, including myriad system monitor tools, the Modular Debugger (MDB), and the dynamic tracing facility (DTrace). - Predictive self-healing features in the form of the Fault Management Architecture (FMA) and Service Management Facility (SMF). They work together to detect hardware and software faults an take appropriate action. - Multiple forms of virtualization. In addition to the operating-system-level virtualization of Solaris Zones, OpenSolaris offers support for xVM Hypervisor, Logical Domains (LDoms), and VirtualBox, and runs in VMware and other virtualization frameworks. - Sophisticated 64bit fully preemptable kernel. The OpenSolaris kernel is also modular - device drivers can be installed without requiring a system boot, and features can be configured without compiling the kernel. The virtual memory subsystems uses demand paging for greater performance and less memory usage. The process scheduling systems support multiple scheduling classes, including timeshare, real time, interactive, fair share, and fixed priority. - Full POSIX compliance with a rich application programming API, including support for 64-bit applications. - Integrated AMP stack (Apache, MySQL, PHP) for running web services. ------------------ Und dann noch (das war aber so 2006-2007) "The Sun Studio compilers have better performance in many cases then do the GCC compilers" ..und jetzt ist mein Kaffee kalt ;)
Gast
#7289779
Deiner ganzer Post ist künstlich Fett (warum postest du die ganze rustc Ausgabe?) und dann noch Solaris Feature Werbung, der Rest ist fast wie immer halbwissen Technik blabla ohne jeglichen Hintergrund, kannst du auch anstaendig oder schreibst du einfach immer jeden Gedanken auf der so durch deinen Kopf schwirrt Alter, krass. Geh mal zu einem Arzt, rbx. Da stimmt doch was nicht. Oder du trollst. Und zwar schlecht.
Gast
#7290073
Cppbert schrieb: > warum postest du die ganze rustc > Ausgabe? Weil ich so darüber lachen musste.
Gast
#7290087
rbx schrieb: >> warum postest du die ganze rustc >> Ausgabe? > > Weil ich so darüber lachen musste. beim gcc, MinGW, Clang, Turbo C, Microsoft C, Microsoft cl, open-watcom, D Kompiler sieht das doch teilweise noch viel wilder aus? d.h. bei alle gängigen Kompilern der Früh und Neuzeit ich glaube dir fehlt sehr viel Erfahrung und du fröhnst hier nur völlig unreflektiert dein Technik-Interesse ohne echten Background - oder besser gesagt so lesen sich deine Post sehr häufig - und da du recht stupide einfach so weiter postest hat das schon echte Troll-Qualität cppbert schrieb: > beim gcc, MinGW, Clang, Turbo C, Microsoft C, Microsoft cl, open-watcom, > D Kompiler sieht das doch teilweise noch viel wilder aus? Naja, nicht ganz.
Warum man gleich unaufgefordert (statt mit -h oder --help oder so) eine mehrseitige Hilfe bringen muss, nun, mag Geschmackssache sein. Ist aber wohl auch mit Abstand der unwesentlichste Punkt überhaupt, darüber kann man sich beschweren, wenn es sonst keine Themen mehr gibt. ;-)
Gast
#7290156
Jörg W. schrieb: > Ist aber wohl auch mit Abstand der unwesentlichste Punkt überhaupt Der Satz hat dich gerettet :)
Gast
#7290508
cppbert schrieb: > und da du recht > stupide einfach so weiter postest Machst du doch auch. Du hast noch nicht mal den Witz verstanden, warum ich so lachen musste, Und so postest munter und zusammenhangbefreit drauflos, wo wohl noch größerer Ausgaben rauskommen. Und darauf baust du dann deine Persönlichkeitstheorie auf. Ich bin zwar kein Arzt, aber..
Gast
#7290577
rbx schrieb: > Du hast noch nicht mal den Witz verstanden, warum ich so lachen musste Dann erkläre den Witz doch mal, ich dachte du meinst den Umfang der Help Ausgabe, oder meinst du ein spezifisches Detail das mir in der halben Seite Text nicht aufgefallen ist? Oder belustigt dich das default Verhalten die Hilfe gleich zu zeigen? rbx schrieb: > naja, so grob: Rust ist eine Programmiersprache ohne Compiler/Linker - > ist eigentlich auch neu. Was möchtest Du uns damit sagen? Wilhelm M. schrieb: > Was möchtest Du uns damit sagen? Seine allumfassende Unkenntnis. Die hat er ja nun mehrfach hier bewiesen. Wollen wir rbx nicht einfach ignorieren? Mir wird das jedenfalls zu dumm. Je öfter man ihm antwortet, desto länger, wirrer und sinnloser werden seine "Beiträge". Kurze Nachfrage, 🐧 DPA 🐧 Hast du deinen Arsch eigentlich hochbekommen und geforked? Also zum Nullkostenpreis den (nicht vorhandenen) Schaden vermieden? Ich schliesse mich übrigens Jörg W. (dl8dtl) an: Ist nur für Datenbanken relevant ... also macht euch keinen Kopf und konzentriert euch lieber auf die Feiertage. Beweis, das 1.66 Enum update. Echt wahr! (:P) ref: https://www.heise.de/news/Programmiersprache-Rust-1-66-erweitert-Enumerations-und-entfernt-Abhaengigkeiten-7398888.html MaWin O. schrieb: > Seine allumfassende Unkenntnis. > Die hat er ja nun mehrfach hier bewiesen. Also ich war 2017 schon von meinen ersten Gehversuchen mit meinem "Rust-Blinky" auf dem STM32F103 begeistert. Lass ihm doch Zeit!:) tuschel Und er hat ja recht! ... es nervt echt, diese langweiligen Leute von der Rust Community: mipsel32 ... braucht keine Sau! Hat ne Woche gedauert, bis wir OpenSSL hinbekommen haben um auf der guten alten Schindmähre zu reiten, MaWin*g* ... siehe github. P.S.: Das war kein Zuspruch zu OpenSSL, sondern zum buildsystem. Die Leute bei Ersterem haben gewiss mehr Animositäten zu beachten .... :) Na ja. Manche Pakete sind halt auch einfach FERTIG! ... das Konzept mag dem ein oder anderen hier nicht geläufig sein. Lasst es mich erklären: Das ist dann, wenn die Arbeit gut ist ... und abgeschlossen ist!:))) (Ist natürlich ne Lüge, wie nachfolgende Beispiele und Argumente belegen werden ... von Api's echt jetze???) https://crates.io/crates/wasi/0.11.0+wasi-snapshot-preview1 https://crates.io/crates/cfg-if/1.0.0 https://crates.io/crates/getrandom/0.2.8 shit ... die "data-science" schläft nicht, hehehee;)
Gast
#7291918
@Jedzia D. Bist du ein Clone von rbx, du schreibst auch irgendwie fast genau wie er - so ein bisschen Fakten, bissel Emotionen, Somway Off-Topics aber irgendwie related - wilde Mischung oder bin ich schon so alt das mir dieser Whatsapp/Tiktok Kommunikationsstyle einfach nicht vertraut genug ist :)
Gast
#7293207
https://blog.yoshuawuyts.com/rust-2023/ netter Vergleich aus dem Post
cppbert schrieb: > The 80/20 rule is often used to indicate that "80% of effort is good > enough". But I think it's important to realize that sometimes achieving > 100% of a solution can provide a value-add which far outweighs all > incremental steps that come before it. Ja, das sehe ich ganz genau so. Und der Grund ist ganz einfach: Es reicht ein einziger memory safety bug aus, um das gesamte System zu Fall zu bringen. Ein Totalschaden, sozusagen. Das ist bereits der worst-case, der nicht schlimmer wird, nur weil es noch 10 weitere memory safety bugs in der Software gibt.
Gast
#7293268
Ich habe schon lange kein Programm mehr abstürzen sehen. Mal ehrlich, den zeitlichen Mehraufwand ist es nicht wert, sich mit dem checker herum zu schlagen. Erfahrene Entwickler wie ich wissen, was sie tun.
Gast
#7293284
DPA schrieb: > Ich habe schon lange kein Programm mehr abstürzen sehen. Mal > ehrlich, > den zeitlichen Mehraufwand ist es nicht wert, sich mit dem checker herum > zu schlagen. Erfahrene Entwickler wie ich wissen, was sie tun. ich arbeite hin und wieder an einem +3 Mio Zeilen Projekt mit >40 Entwicklern - wie viel Kontrolle hast du über deine Projekte? Es geht nicht nur um Abstürze - es geht auch um die Folgefehler die sich durch Speicherfehlern ergeben und die passieren oft einfach nur wenn du auch mal durch den Code läufst - Security-Problem kommen nicht durch abstürzende Software - und wenn deine Software nicht Secure sein muss oder nicht so viele Leute dran arbeiten kann es einfach sein das in deiner Domäne die Rust Features Null Bedeutung haben Ich verdiene mein Geld häufig damit große Systeme aufzuräumen/tief fehlerfrei zu bekommen - noch keine Software ob klein oder groß hat einen ASAN oder TSAN ohne Findings überstanden - keiner der Fehler hat direkt Menschen töten können, aber entfernt wurden trotzdem alle Ich schreibe Rust fast genau so problemlos wie C++ - warum sollte ich auf den Schutz verzichten - oder besser sogar dagegen argumentieren :)
Gast
#7293288
Kein C/C++ Entwickler wechselt zu Rust nur weil seine Software ständig abstürzt - das ist nicht der Antrieb, und das Problem hat wirklich niemand - es ist u.a. die 100% Speichersicherheit at Kompiletime - von Anfang bis zum Tod des Projektes DPA schrieb: > Ich habe schon lange kein Programm mehr abstürzen sehen Da sieht man mal wieder, dass du gar nicht weißt, wovon du sprichst. Rust verhindert den Absturz eines defekten Programms auch nicht immer. Aber es verhindert, dass ein solcher Fehler ausgenutzt werden kann. > Erfahrene Entwickler wie ich wissen, was sie tun. Ja genau. Das wird uns seit 30 Jahren erzählt. Und die Anzahl der Security-Bugs wurden nie weniger. Selbst mit Checker-Tools wurde die Anzahl nicht reduziert. Es ist also Bullshit. Doch weißt du, was die Anzahl der Bugs (in Android) schlussendlich dann doch reduziert - oder besser gesagt stand heute auf Null gebracht - hat? Rate mal. https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
Gast
#7293420
MaWin O. schrieb: > Doch weißt du, was die Anzahl der Bugs (in Android) schlussendlich dann > doch reduziert Das ist objektiv wahr. > - oder besser gesagt stand heute auf Null gebracht - Das allerdings nicht. War auch nicht im Moment deines Postings wahr. Wird auch nirgendwo in deinem Link https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html behauptet. Das hast du selbst frei erfunden. c-hater schrieb: > Das allerdings nicht. War auch nicht im Moment deines Postings wahr. > Wird auch nirgendwo in deinem Link > > https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html > > behauptet. Das hast du selbst frei erfunden. Ach. Gut. Da ist es ja einfach, das Gegenteil zu beweisen: Zitat: > Security impact > > To date, there have been zero memory safety vulnerabilities discovered in > Android’s Rust code. Muss dir aber nicht peinlich sein. Du wolltest ja nur stänkern. Das sei dir gegönnt.
Gast
#7293429
c-hater schrieb: > behauptet. Das hast du selbst frei erfunden. In dem Text steht das im Rust Code bisher keine security flaws aufgetaucht sind Aber trotzdem wuerde ich den Blog Post an sich jetzt auch nicht als Beweis akzeptieren, aber Google, selbst die Sanitizer Entwickler und stark im Fuzzy Bereich scheinen schon fuer den System Bereich von Rust überzeugt zu sein, das kann man auch nicht einfach ignorieren
Gast
#7293438
Cppbert schrieb: > Aber trotzdem wuerde ich den Blog Post an sich jetzt auch nicht als > Beweis akzeptieren Hab mich blöd ausgedrückt, ich meinte nur das der Blog Post jetzt nicht so geeignet ist Ungeläubige zu überzeugen :) Cppbert schrieb: > Hab mich blöd ausgedrückt, ich meinte nur das der Blog Post jetzt nicht > so geeignet ist Ungeläubige zu überzeugen :) Ich finde schon. Er sagt: Über mehr als eine Dekade haben wir ständig Security-Bugs und auch Checker helfen wenig bis gar nichts. Doch dann setzen wir Rust ein und die Anzahl der Security-Bugs reduziert sich plötzlich auf Null. Das, finde ich, ist schon ein einfach verständliches Argument. Auch für Anfänger und Ungläubige. Und ja, mir ist klar, dass auch Rust in Zukunft Securityprobleme haben wird. Das steht ja auch im Artikel. Aber es wird sehr sehr sehr sehr viel weniger sein, als mit allen anderen existierenden Techniken.
Gast
#7293516
MaWin O. schrieb: > Doch dann setzen wir Rust ein und die Anzahl der Security-Bugs reduziert > sich plötzlich auf Null. Memory safety bugs != security bugs. Security bugs sind Probleme, die von anderen auf eine Art und Weise ausgenutzt werden können, die problematisch ist, z.B. weil man dann Dinge tun kann, die nicht vorgesehen waren. Auch so Sachen wie XSS, fehlende Berechtigungschecks, die üblichen deserialisierungsbugs in Java, etc. fallen darunter. Und nicht nur sind security bugs oft keine memory safety, memory safety bugs müssen nicht immer security bugs sein. So wird mir z.B. ein Speicherfehler in meinem lokalen Minesweeper Game sicher keine Sicherheitsrelevanten Probleme bereiten. DPA schrieb: > ... Ja. Blah. Du kannst die Begriffe so lange verdrehen, wie du es willst. Aus dem Kontext ist ganz offensichtlich klar, was ich gesagt habe. Du lenkst ab. Ich habe mich auf das bezogen, was der Artikel aussagt. Und das ist halt: > Früher ganz viel -> Jetzt Null > Wegen Rust. Das ist Fakt. Und das ist leider eindeutig. Egal, wie du es nennst.
Gast
#7293626
Von https://opensrcsec.com/open_source_security_announces_rust_gcc_funding bis https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607959.html hat es doch etwas gedauert.. Was fehlt jetzt noch um meinen geliebten attiny85 mit gccrs zu programmieren? Wie lange muss man noch auf GCC v14 warten? Siggi A. schrieb: > Was fehlt jetzt noch um meinen geliebten attiny85 mit gccrs zu > programmieren? Warum mit gccrs? Das kannst du heute mit dem offiziellen Nightly-Release von rustc tun. MaWin O. schrieb: > Siggi A. schrieb: >> Was fehlt jetzt noch um meinen geliebten attiny85 mit gccrs zu >> programmieren? > > Warum mit gccrs? > Das kannst du heute mit dem offiziellen Nightly-Release von rustc tun. Die Version 1.66 hat nur avr-unknown-gnu-atmega328
Gast
#7293649
hab ein Beispiel für deinen geliebten attiny85 gefunden - keine Ahnung ob das qualitativ hochwertig ist https://github.com/eric-wood/rust-attiny85-example https://crates.io/crates/avr-device https://crates.io/crates/avrd https://docs.rs/avrd/latest/avrd/attiny85/index.html
Gast
#7293661
cppbert schrieb: > hab ein Beispiel für deinen geliebten attiny85 gefunden - keine Ahnung > ob das qualitativ hochwertig ist Es scheint in Teil auf dem avr-gcc zu basieren oder wenigstens wird dessen Linker verwendet - könnte sein das es nicht ganz so out-of-the-box funktioniert wie es gewünscht ist, aber AVR ist glaube ich auch erst vor ein paar Monaten zu Rust gekommen @Siggi A. Wäre schön wenn du deine Erfahrungen damit hier einbringen könntest Wilhelm M. schrieb: > Die Version 1.66 hat nur avr-unknown-gnu-atmega328 Das ist nicht wahr. MaWin O. schrieb: > Wilhelm M. schrieb: >> Die Version 1.66 hat nur avr-unknown-gnu-atmega328 > > Das ist nicht wahr. $ rustc --print target-list | grep avr avr-unknown-gnu-atmega328 $ rustc --version rustc 1.66.0 (69f9c33d7 2022-12-12) (Arch Linux rust 1:1.66.0-1) cppbert schrieb: > s scheint in Teil auf dem avr-gcc zu basieren oder wenigstens wird > dessen Linker verwendet Es "basiert" nicht auf avr-gcc. Es wird nur der Linker verwendet. Wie bei jeder anderer Rust-Plattform auch. Rust hat keinen eigenen Linker. Derzeit wird für die startup-Routinen auch noch avr-libc verwendet. > könnte sein das es nicht ganz so > out-of-the-box funktioniert wie es gewünscht ist, Doch. Es funktioniert out of the box. Einfach so. Probiere es doch einfach mal aus. Rust-Nightly installieren und das tun, was im Readme eines AVR-Beispiels steht: https://github.com/avr-rust/template-bin.git (Das ruduino-crate würde ich allerdings nicht empfehlen. Da gibts mit avr-device und avr-hal besseres) > aber AVR ist glaube > ich auch erst vor ein paar Monaten zu Rust gekommen Das ist nicht wahr. Es ist schon seit Jahren drin. Es war allerdings ein paar Monate lang wegen eines LLVM-Bugs defekt. Das wurde vor ein paar Monaten behoben. Wilhelm M. schrieb: > $ rustc --print target-list | grep avr Ja, Wilhelm. Das heißt nicht, dass nur der 328er unterstützt wird. Von avr-device werden derzeit diese Chips unterstützt: https://docs.rs/avr-device/0.4.0/avr_device/ avr-device is ein PAC. (Peripheral Access Crate). Das ist die Schicht unter der HAL. Im PAC wird die vorhandene Hardware/Peripherie beschrieben. MaWin O. schrieb: > Wilhelm M. schrieb: >> $ rustc --print target-list | grep avr > > Ja, Wilhelm. Das heißt nicht, dass nur der 328er unterstützt wird. Dann ist die Ausgabe aber sehr verwirrend ;-) Und welche werden bei dem Target avr-unknown-gnu-atmega328 unterstützt??? Wilhelm M. schrieb: > Und welche werden bei dem Target avr-unknown-gnu-atmega328 > unterstützt??? Soweit ich weiß alle. Die unterscheiden sich ja kaum auf CPU-Ebene. Es kommt eher darauf an, was das von dir verwendete PAC unterstützt. Und da habe ich den Link oben geliefert. MaWin O. schrieb: > Wilhelm M. schrieb: >> Und welche werden bei dem Target avr-unknown-gnu-atmega328 >> unterstützt??? > > Soweit ich weiß alle. Die unterscheiden sich ja kaum auf CPU-Ebene. Doch schon. Die Megas haben Instruktionen, die die Tinys nicht haben. Dann werden falsche Op-Codes generiert für die Tinys, bzw. die ganz neuen AVR werden nicht optimal genutzt. Wilhelm M. schrieb: > Dann werden falsche Op-Codes generiert für die Tinys Das sagst du jetzt einfach so, obwohl du es nie ausprobiert hast? Unfassbar. Wie gesagt, beim avr-device PAC gibt es eine Liste von unterstützten Devices. Schaue dir das und das Template-crate an. MaWin O. schrieb: > Wilhelm M. schrieb: >> Dann werden falsche Op-Codes generiert für die Tinys > > Das sagst du jetzt einfach so, obwohl du es nie ausprobiert hast? > Unfassbar. Ich glaube erst einmal nur der Ausgabe von rustc, sonst nichts. Und wenn dort das Target mega328 steht, dann glaube ich das auch. Sonst nichts. Wenn das target mega328 was auch bedeutet, das tiny, tiny0, tiny1, mega0, mega0 und mega1, xmega unetrstützt werden ist das evtl. schön. Allerdings frage ich mich dann, wie rustc dann die notwendige Unterscheidung für den Core hin bekommt. Aber das kannst Du sicher ganz einfach erklären. Wilhelm M. schrieb: > Allerdings frage ich mich dann, wie rustc dann die notwendige > Unterscheidung für den Core hin bekommt. Wie wäre es, wenn du dir das template endlich einmal anschaust? Schaffst du das? https://github.com/avr-rust/template-bin/blob/master/avr-atmega328p.json MaWin O. schrieb: > Wilhelm M. schrieb: >> Allerdings frage ich mich dann, wie rustc dann die notwendige >> Unterscheidung für den Core hin bekommt. > > Wie wäre es, wenn du dir das template endlich einmal anschaust? Schaffst > du das? > > https://github.com/avr-rust/template-bin/blob/master/avr-atmega328p.json Habe ich geschafft ;-) Und dort steht ja gerade -mmcu=atmega328p. Jetzt erklär mal bitte, wie der Code dann auf einem tiny laufen soll.
Beitrag #7293720 wurde von einem Moderator gelöscht.
Gast
#7293725
Wilhelm M. schrieb: > Allerdings frage ich mich dann, wie rustc dann die notwendige > Unterscheidung für den Core hin bekommt. das grenzt man noch weiter ein - aber ja ich geben dir recht das hat mich auch zuerst verwirrt - aber die von vielen hier gezeigte "das ist dann bestimmt irgendwie ein Fehler" Mentalität kann ich echt nicht nachvollziehen - das machen so viele hier
Gast
#7293727
Wilhelm M. schrieb: > Jetzt erklär mal bitte, wie der Code dann auf einem tiny laufen soll. war doch in meinem ersten Beispiel Post https://github.com/eric-wood/rust-attiny85-example/blob/main/avr-attiny85.json vergleich die beiden jsons cppbert schrieb: > Wilhelm M. schrieb: >> Jetzt erklär mal bitte, wie der Code dann auf einem tiny laufen soll. > > war doch in meinem ersten Beispiel Post > > https://github.com/eric-wood/rust-attiny85-example/blob/main/avr-attiny85.json > > vergleich die beiden jsons Ja, schon klar. Nur MaWin behauptete zum Target atmega328 folgendes: MaWin O. schrieb: > Soweit ich weiß alle. Und das ist definitiv falsch.
Gast
#7293746
Wilhelm M. schrieb: > Nur MaWin behauptete zum Target atmega328 folgendes: > > MaWin O. schrieb: >> Soweit ich weiß alle. > > Und das ist definitiv falsch. willst du jetzt wissen ob es geht oder mit MaWin das Er-hat-recht-du-hast-recht-Spiel-spielen? cppbert schrieb: > Wilhelm M. schrieb: >> Nur MaWin behauptete zum Target atmega328 folgendes: >> >> MaWin O. schrieb: >>> Soweit ich weiß alle. >> >> Und das ist definitiv falsch. > > willst du jetzt wissen ob es geht oder mit MaWin das > Er-hat-recht-du-hast-recht-Spiel-spielen? Das es nicht geht in Version 1.66, weiß ich ja bereits wie oben schon geschrieben: $ rustc --target=avr-unknown-gnu-attiny85 error: Error loading target specification: Could not find specification for target "avr-unknown-gnu-attiny85". Run `rustc --print target-list` for a list of built-in targets
Gast
#7293750
MaWins Sätzen sind manchmal ein wenig zu schroff - aber er kommt immer recht schnell wieder auf den Punkt das man was erreichen/wissen will und hat zu 95% recht - viele andere hier spielen dann Wer-hat-recht Kette durch - um jede 5% Recht haben - das ist es nicht wert
Gast
#7293756
Wilhelm M. schrieb: > Das es nicht geht in Version 1.66, weiß ich ja bereits wie oben schon > geschrieben: ok, sorry das ging unter Wilhelm M. schrieb: > Und das ist definitiv falsch. Weil du das sagst? Hast du beim avr-gcc auch einen separaten Compiler für jedes Target, oder machst du das per -mmcu? Du bist ein Laberkopp. MaWin O. schrieb: > Wilhelm M. schrieb: >> Und das ist definitiv falsch. > > Weil du das sagst? Nö, weil Atmel das so designed hat. > > Hast du beim avr-gcc auch einen separaten Compiler für jedes Target, > oder machst du das per -mmcu? Genau. Und die Option -mmcu hat rustc nicht, deswegen verwendet man dort --target. Und ein target für attiny85 gibt es in Version 1.66 eben nicht. S.a. mein Beitrag oben. Wilhelm M. schrieb: > Nö, weil Atmel das so designed hat. Atmel??? > Genau. Und die Option -mmcu hat rustc nicht, deswegen verwendet man dort > --target. Nein, tut man nicht. Würdest du dir endlich mal das Beispiel anschauen? Hm? Wie wäre das? Du machst dich hier einfach nur zur Kartoffel. MaWin O. schrieb: > Wilhelm M. schrieb: >> Nö, weil Atmel das so designed hat. > > Atmel??? > >> Genau. Und die Option -mmcu hat rustc nicht, deswegen verwendet man dort >> --target. > > Nein, tut man nicht. > Würdest du dir endlich mal das Beispiel anschauen? Hm? Wie wäre das? Es ist doch nur eine Zeile, oder? $ rustc bla.rs --target=??? Nenne mir einfach den passenden String für ??? oder den gesamten rustc-Aufruf für das target attiny85 in Version 1.66. Wilhelm M. schrieb: > Es ist doch nur eine Zeile, oder? > > $ rustc bla.rs --target=??? > > Nenne mir einfach den passenden String für ??? oder den gesamten > rustc-Aufruf für das target attiny85 in Version 1.66. Niemand ruft rustc direkt auf. Auf keiner Plattform. Deshalb kann ich dir auswendig den Aufruf auch nicht nennen. Alle Leute, inclusive des Beispiels (!) nutzen Cargo mit einem entsprechenden json (bei AVR) zur Konfiguration des Targets. Was Cargo daraus für rustc macht, weiß ich nicht. MaWin O. schrieb: > Wilhelm M. schrieb: >> Es ist doch nur eine Zeile, oder? >> >> $ rustc bla.rs --target=??? >> >> Nenne mir einfach den passenden String für ??? oder den gesamten >> rustc-Aufruf für das target attiny85 in Version 1.66. > > Niemand ruft rustc direkt auf. Auf keiner Plattform. > Deshalb kann ich dir auswendig den Aufruf auch nicht nennen. > > Alle Leute, inclusive des Beispiels (!) nutzen Cargo mit einem > entsprechenden json (bei AVR) zur Konfiguration des Targets. > > Was Cargo daraus für rustc macht, weiß ich nicht. Aaaach soo ;-) Wilhelm M. schrieb: >> Was Cargo daraus für rustc macht, weiß ich nicht. > > Aaaach soo ;-) Ja. Jetzt hast du die 5% gefunden, die cppbert meint. Glückwunsch. Am der ursprünglichen Tatsache der unterstützten Chips ändert das aber rein gar nichts. Und wenn du dir das Beispiel endlich einmal anschauen und ausprobieren würdest, dann könntest du selbst ganz einfach herausfinden, wie der rustc-Aufruf ist. Aber das willst du ja gar nicht.
Gast
#7293790
MaWin O. schrieb: > Aber das willst du ja gar nicht. ich glaube er will schon, aber ist es eben anders gewohnt - manche machen in einem neuen System erstmal genau das was sie kennen und wenn es dann nicht klappt steigt die Verwirrung - ist eben so, aber auch nicht wirklich schlimm cppbert schrieb: > ist eben so, aber auch nicht wirklich schlimm Es ist schlimm, weil hier zum X-ten Male mit Links vorgekaut wurde, wie es richtig geht. Das ist einfach nur unverschämt den Forenteilnehmern gegenüber.
Gast
#7293809
Bei einem simplen Makefile wüsste man sofort, was da abgeht. Aber die für rust zu schreiben, ist zwar möglich, aber halt leider nicht mehr so einfach / praktikabel. Aber wer will schon wissen, wie das zeug funktioniert? Ist ja jetzt so viel einfacher, wo cargo alles für einen macht, irgendwie... DPA schrieb: > Bei einem simplen Makefile wüsste man sofort, was da abgeht. Was ist bei dem Cargo.toml und dem json aus dem Beispiel-Template nicht einfach zu verstehen? Werde doch einmal konkret, bitte. Was wäre in einem Makefile besser zu sehen und zu verstehen? > ist ja jetzt so viel einfacher, wo cargo alles für einen > macht, irgendwie... Ja, es ist viel einfacher. Aber warum benutzt du make? Mit deiner Argumentation solltest du den gcc selbst per Hand aufrufen und kein böses Buildsystem (wie make) nutzen. Das make verkompliziert nur den simplen gcc-Aufruf! Regeln, Rezepte, Variablen, Abhängigkeiten. Alles das braucht man gar nicht, wenn man gcc direkt aufruft! Wozu also dieses komplizierte make-System?
Gast
#7293821
DPA schrieb: > Bei einem simplen Makefile wüsste man sofort aber auch nur die welche häufig mit Makefiles arbeiten und Makefiles sind echt nicht so schön wenn es grosse Multi-Platform-Projekte mit vielen Dependencies usw sind - das wissen alle aus langer Erfahrung :) ein bisschen (drastischer) Umstellen darf erlaubt sein sonst kann man ja gar nichts machen MaWin O. schrieb: > DPA schrieb: >> Bei einem simplen Makefile wüsste man sofort, was da abgeht. > > Was ist bei dem Cargo.toml und dem json aus dem Beispiel-Template nicht > einfach zu verstehen? Du hast selbst gesagt, du weisst nicht, wie der rustc Aufruf bei dem ding oben am Schluss aussieht. In einem Makefile steht ziemlich genau das drin. Zum bauen von X, führe Y aus. Das ist viel transparenter.
Gast
#7293829
was hat es mit dem json File auf sich: https://book.avr-rust.com/005.1-the-target-specification-json-file.html
Gast
#7293831
Daniel A. schrieb: > In einem Makefile steht ziemlich genau > das drin. Zum bauen von X, führe Y aus. Das ist viel transparenter. das weiß jeder hier - auch MaWin - Cargo ist eben ein wenig anders als make - mehr kann man da nicht diskutieren cppbert schrieb: > aber auch nur die welche häufig mit Makefiles arbeiten und Makefiles > sind echt nicht so schön wenn es grosse Multi-Platform-Projekte mit > vielen Dependencies usw sind - das wissen alle aus langer Erfahrung :) > > ein bisschen (drastischer) Umstellen darf erlaubt sein sonst kann man ja > gar nichts machen Genau so sieht es nämlich aus. In Makefiles ist so gut wie nichts standardisiert. Wo man da das Target umstellt, hat sich jeder Entwickler selbst ausgedacht und selbst neu erfunden. Bei Cargo ist das alles immer gleich. Cargo-Projekte können zwar auch komplex werden. Wenn man z.B. ein build.rs verwendet. Aber selbst dann ist es einfacher als make, weil die Stellen wo man anfangen muss zu schauen immer gleich sind. Bei Makefiles hat sich das hingegen jeder Entwickler neu ausgedacht. Daniel A. schrieb: > Du hast selbst gesagt, du weisst nicht, wie der rustc Aufruf bei dem > ding oben am Schluss aussieht. Weil ich es nicht brauche. Weil so gut wie niemand es braucht. Auch du nicht. Und genau deshalb schaue ich es auch nicht nach. Das ist nutzloses Wissen. > In einem Makefile steht ziemlich genau > das drin. Zum bauen von X, führe Y aus. Das ist viel transparenter. Ich glaube du hast noch nie ein Makefile aus der realen Welt gesehen. Ich habe sogar Projekte, die eigentlich nur ein grosses Makefile sind. z.B. https://github.com/Daniel-Abrecht/dpa-image-builder Ok, es gibt noch Sachen die Makefiles generieren, z.B. Automake, und dass will man dann wirklich nicht unbedingt lesen. Aber ein normales, simples, handgeschriebenes Makefile, ist wie ein wundervolles Kunstwerk. Maximale Einfachheit und Transparenz, ohne Einschränkungen. Das platonische Ideal der eines Build Tools! Daniel A. schrieb: > Ich habe sogar Projekte, die eigentlich nur ein grosses Makefile sind. > z.B. https://github.com/Daniel-Abrecht/dpa-image-builder https://github.com/Daniel-Abrecht/dpa-image-builder/blob/master/makefile Hm hm. Ja ja. Sehr einfach zu lesen, dein Makefile. Ich verstehe sofort, was es tut. Dagegen ist ein Cargo.toml https://github.com/avr-rust/template-bin/blob/master/Cargo.toml und ein json https://github.com/avr-rust/template-bin/blob/master/avr-atmega328p.json ja geradezu Hexenwerk und schwer verständlich! Bei Cargo kann man sogar in die Doku gucken und man bekommt alles sehr genau erklärt. Da lobe ich mir tatsächlich ein undokumentiertes Makefile. Da wird man noch gefordert! MaWin O. schrieb: > cppbert schrieb: >> ist eben so, aber auch nicht wirklich schlimm > > Es ist schlimm, weil hier zum X-ten Male mit Links vorgekaut wurde, wie > es richtig geht. > > Das ist einfach nur unverschämt den Forenteilnehmern gegenüber. Es ging sehr konkret um diese Frage: Beitrag "Re: Rust - ist das hier um zu bleiben?" Und Deine Antwort darauf: MaWin O. schrieb: > Wilhelm M. schrieb: >> $ rustc --print target-list | grep avr > > Ja, Wilhelm. Das heißt nicht, dass nur der 328er unterstützt wird. Es nicht um cargo mit einer geeigneten target-definition, wie Du siehst. Sondern es ging um rustc und die damit ausgelieferte target-definition ausschließlich für den m328. Und dann noch diese Deine Antwort: MaWin O. schrieb: > Wilhelm M. schrieb: >> Und welche werden bei dem Target avr-unknown-gnu-atmega328 >> unterstützt??? > > Soweit ich weiß alle. Die unterscheiden sich ja kaum auf CPU-Ebene. > Es kommt eher darauf an, was das von dir verwendete PAC unterstützt. Und > da habe ich den Link oben geliefert. Und das ist eben irreführend bzw. falsch. Wilhelm M. schrieb: > Es nicht um cargo mit einer geeigneten target-definition, wie Du siehst. Ja. Dann machst du es halt falsch. So einfach ist das. Nutze Cargo, wie jeder vernünftige Mensch, oder finde halt selbst raus, wie der rustc-Aufruf sein muss. Ich kann es dir nicht sagen und es spielt auch überhaupt keine Rolle, wie der rustc-Aufruf genau aussieht. Ich werde das jetzt nicht für dich recherchieren, weil es sinnlos ist. Hier ist die bereits gepostete Doku, die du bestimmt wieder nicht lesen wirst: https://book.avr-rust.com/005.1-the-target-specification-json-file.html Wilhelm M. schrieb: >> Soweit ich weiß alle. Die unterscheiden sich ja kaum auf CPU-Ebene. >> Es kommt eher darauf an, was das von dir verwendete PAC unterstützt. Und >> da habe ich den Link oben geliefert. > > Und das ist eben irreführend bzw. falsch. Was ist daran falsch? MaWin O. schrieb: > Wilhelm M. schrieb: >>> Soweit ich weiß alle. >> >> Und das ist eben irreführend bzw. falsch. > > Was ist daran falsch? Habe ich Dir oben doch schon erklärt: der Core der AVRs ist unterschiedlich. Daher passt das m328 target nicht auf einen anderen µC z.B. tiny oder DA, DB, DD. MaWin O. schrieb: > Ja. Dann machst du es halt falsch. Nö. Die richtige Antwort wäre gewesen, die korrekte Target-Definition für rustc zu erzeugen. Aber Du kennst Dich eben mit rustc nicht aus ... Wilhelm M. schrieb: > Habe ich Dir oben doch schon erklärt: der Core der AVRs ist > unterschiedlich. Daher passt das m328 target nicht auf einen anderen µC > z.B. tiny oder DA, DB, DD. Ich habe auch nie behauptet, dass ein für m328 kompiliertes Rust-Programm auf einem Tiny lauffähig wäre. Lies doch bitte die Doku. Dort steht, wie man das Target angibt: https://book.avr-rust.com/005.1-the-target-specification-json-file.html Oder gucke dir das Tiny-Beispiel an. Was falsch ist, ist lediglich deine Aussage, dass der Rustcompiler nur das m328-Target unterstützt. Wilhelm M. schrieb: > Aber Du kennst Dich eben mit rustc nicht aus ... So wirds sein. Genau. Danke für diese Erkenntnis. Zum Glück hast du mir das als Rust-Experte einmal erklärt. Es ist unfassbar, wie stur man sein kann, lieber Wilhelm. MaWin O. schrieb: > Wilhelm M. schrieb: >> Habe ich Dir oben doch schon erklärt: der Core der AVRs ist >> unterschiedlich. Daher passt das m328 target nicht auf einen anderen µC >> z.B. tiny oder DA, DB, DD. > > Ich habe auch nie behauptet, dass ein für m328 kompiliertes > Rust-Programm auf einem Tiny lauffähig wäre. Hier nochmal zum Nachlesen: Wilhelm M. schrieb: > MaWin O. schrieb: >> Wilhelm M. schrieb: >>> Und welche werden bei dem Target avr-unknown-gnu-atmega328 >>> unterstützt??? >> >> Soweit ich weiß alle. Die unterscheiden sich ja kaum auf CPU-Ebene. >> Es kommt eher darauf an, was das von dir verwendete PAC unterstützt. Und >> da habe ich den Link oben geliefert. Auf die Frage, welche AVRs beim dem Target m328 unterstützt werden, kam also Deine Antwort: "Soweit ich weiß alle". Dann solltest Du mal erklären, wie das gemeint war. Wilhelm M. schrieb: > Auf die Frage, welche AVRs beim dem Target m328 unterstützt werden, kam > also Deine Antwort: "Soweit ich weiß alle". Nein. Die Frage, welche AVRs das m328-Target unterstützt ist doch wohl trivial: Es unterstützt den m328. Ich dachte das wäre auch dir klar. Ich hätte es nicht für möglich gehalten, dass du tatsächlich fragst, welche Controller das m328-Target unterstützt. Aber so kann man sich irren. Also noch einmal für dich: Ja, das m328-Target unterstützt nur den m328-Controller. Wer hätte das gedacht. Aber das spielt zum Glück alles gar keine Rolle, denn es ging die ganze Zeit um den AVR-Rust-Compiler. Und dieser unterstützt nun eben auch mehr Targets als nur den m328. Und zwar - soweit ich weiß - alle, weil die sich eben kaum unterscheiden. Und weil das zu 99% eine LLVM-Sache ist. Du hast behauptet, dass er nur das m328-Target und damit nur den m328-Controller unterstützt. Und das ist eben ganz einfach falsch. MaWin O. schrieb: > Aber das spielt zum Glück alles gar keine Rolle, denn es ging die ganze > Zeit um den AVR-Rust-Compiler. Und dieser unterstützt nun eben auch mehr > Targets als nur den m328. Und zwar - soweit ich weiß - alle, weil die > sich eben kaum unterscheiden. Und weil das zu 99% eine LLVM-Sache ist. Dann die nä. Frage: das llvm-avr backend ist noch experimental, oder? Ich bin nicht ganz up-to-date, aber das letzte mal, als ich clang/clang++ für AVR ausprobiert habe ((vor)letztes Jahr?) kam da jedenfalls grottenschlechter Code raus. Wilhelm M. schrieb: > Dann die nä. Frage: das llvm-avr backend ist noch experimental, oder? Auch diese Frage wurde bereits hier beantwortet: AVR-Rust gibts im Nightly-Zweig. > Ich bin nicht ganz up-to-date, aber das letzte mal, als ich > clang/clang++ für AVR ausprobiert habe ((vor)letztes Jahr?) Probiere es doch zur Abwechslung einfach einmal aus. > kam da jedenfalls grottenschlechter Code raus. "Grottenschlecht" ist er nicht. Aber ja, einige der AVR-spezifischen Optimierungen, die der avr-gcc im backend macht, macht der llvm noch nicht. MaWin O. schrieb: > Aber ja, einige der AVR-spezifischen Optimierungen, die der avr-gcc im > backend macht, macht der llvm noch nicht. Viele davon sind bei Rust aber auch gar nicht nötig. Es gibt z.B. keine int-Promotion in Rust. Ein u8 ist ein u8. Da braucht das Backend gar nichts zu optimieren, weil Rust ein u8 nicht auf i16 promoviert, wie C das auf AVR tut. Deshalb kann es auch keine dem entsprechenden unnötigen Instruktionen geben, die dann wieder umständlich im Backend herausoptimiert werden müssen. MaWin O. schrieb: > Auch diese Frage wurde bereits hier beantwortet: > AVR-Rust gibts im Nightly-Zweig. Du hast mich nicht verstanden. Zur Info: mein rustc version 1.66 unterstützt avr (aber eben nur den m328, wie wir eben festgestellt haben, einfach mangels target-definition). rustc basiert auf llvm mit dem llvm-avr backend, und das ist experimentell immer noch, soweit ich weiß. Wilhelm M. schrieb: > Zur Info: mein rustc version 1.66 unterstützt avr (aber eben nur den > m328, wie wir eben festgestellt haben Du hast es echt immer noch nicht verstanden? Dein rustc unterstützt auch andere Targets! > rustc basiert auf llvm mit dem llvm-avr backend, und das ist > experimentell immer noch, soweit ich weiß. MaWin O. schrieb: > Auch diese Frage wurde bereits hier beantwortet: > AVR-Rust gibts im Nightly-Zweig. MaWin O. schrieb: > Wilhelm M. schrieb: >> Zur Info: mein rustc version 1.66 unterstützt avr (aber eben nur den >> m328, wie wir eben festgestellt haben > > Du hast es echt immer noch nicht verstanden? > Dein rustc unterstützt auch andere Targets! Aber sicher habe ich Dich verstanden ;-) Der rustc unterstützt nur dann andere Targets, wenn man ihm andere target-definitionen gibt. Aber andere als für den m328 sind in Version 1.66 einfach nicht dabei. Das ist dieselbe Mechanik, wie beim avr-gcc auch.
Gast
#7293966
Vielleicht erhellen diese Links die Sachlage etwas: https://book.avr-rust.com/ https://book.avr-rust.com/003.1-the-avr-unknown-gnu-atmega328-target.html https://book.avr-rust.com/005.1-the-target-specification-json-file.html Unten im letzten Link steht z.B. "Adapting a target specification JSON to another AVR variant is trivial. Options that must be updated to target individual microcontroller variants: cpu - set to the lower-case model name of the desired AVR variant pre-link-args - the correct -mmcu option, always equal to the cpu, must be updated" Wilhelm M. schrieb: > Der rustc unterstützt nur dann andere Targets, wenn man ihm andere > target-definitionen gibt. Aber andere als für den m328 sind in Version > 1.66 einfach nicht dabei. Das ist doch grob irreführender Quatsch. Du musst in der json-Datei deine CPU eintragen. Fertig. Das wars. Mehr ist nicht zu tun. Das ist es, worüber so hier einen riesigen Aufriss machst. Du machst dich hier absolut lächerlich. Links (nicht Rechts) schrieb: > Vielleicht erhellen diese Links die Sachlage etwas: Ist bekannt: nicht anderes habe ich oben geschrieben MaWin O. schrieb: > Wilhelm M. schrieb: >> Der rustc unterstützt nur dann andere Targets, wenn man ihm andere >> target-definitionen gibt. Aber andere als für den m328 sind in Version >> 1.66 einfach nicht dabei. > > Das ist doch grob irreführender Quatsch. Nö. $ rustc --print target-list | grep avr avr-unknown-gnu-atmega328
Gast
#7294005
Wilhelm M. schrieb: > $ rustc --print target-list | grep avr > avr-unknown-gnu-atmega328 du bekommst das nicht als target - egal wie oft du das forderst - es wird über das Json eingestellt und niemals mit --print target-list kommen, das steht doch in der Doku btw: ist das alles eh nur in Nighlty und ich glaube du arbeitest mit Release cppbert schrieb: > btw: ist das alles eh nur in Nighlty und ich glaube du arbeitest mit > Release Ja, auch das habe ich ganz oben schon gesagt: Version 1.66 cppbert schrieb: > du bekommst das nicht als target Doch, ein Target für avr gibt es eben in Version 1.66 Wilhelm M. schrieb: > Doch, ein Target für avr gibt es eben in Version 1.66 Wenn du es einmal ausprobiert hättest, hättest du auch gemerkt, dass es mit stable nicht funktioniert und du nightly brauchst, wie hier schon etliche Male gesagt. Aber du bis ja vollkommen beratungsresistent.
Gast
#7294108
hier steht das alles drin: https://book.avr-rust.com/001-introduction.html das man Nightly braucht (und nicht Stable), wie man ein nicht-unknown-gnu-atmega328 supported (mit json) was man alles installieren muss und kleine Beispiele ich würde das auch gerne kurz Durchspielen aber will jetzt nicht unbedingt ohne not (hab kein AVR auf dem Tisch) die gcc-avr Sachen auf meinem Windows installieren
Gast
#7294145
cppbert schrieb: > hier steht das alles drin: > https://book.avr-rust.com/001-introduction.html Aus https://book.avr-rust.com/002-installing-the-compiler.html ganz unten "NOTE: Compiling Rust/LLVM can be very memory intensive. You may find compilation abruptly stopping on machines with less than ~10GB of RAM due to the operating system out-of-memory killer stopping it." Auch wenn wir das Jahr 2022 schreiben. Das klingt nicht gerade nach KISS.
Gast
#7294152
Links (nicht Rechts) schrieb: > Auch wenn wir das Jahr 2022 schreiben. Das klingt nicht gerade nach > KISS. gut das AVR Zeug ist definitiv noch nicht Super-Mainstream und OOM bekomme ich auch mit Qt 6.4 wenn ich alles mit gcc und allen Kernen baue in einer VM mit 8GB RAM Links (nicht Rechts) schrieb: > Auch wenn wir das Jahr 2022 schreiben. Das klingt nicht gerade nach > KISS. Wann hast du das letzte Mal ein C++-Programm mit dem GCC auf einem Mehrkernrechner compiliert? 10 GB sind auch dafür zu wenig. Cargo nutzt standardmäßig alle Kerne, die zur Verfügung stehen.
Gast
#7294523
MaWin O. schrieb: > Wilhelm M. schrieb: >> Der rustc unterstützt nur dann andere Targets, wenn man ihm andere >> target-definitionen gibt. Aber andere als für den m328 sind in Version >> 1.66 einfach nicht dabei. > > Das ist doch grob irreführender Quatsch. > Du musst in der json-Datei deine CPU eintragen. Fertig. Das wars. Mehr > ist nicht zu tun. > Das ist es, worüber so hier einen riesigen Aufriss machst. > > Du machst dich hier absolut lächerlich. Hier ist er wieder, der MaWin, der nicht ohne persönliche Angriffe auskommt. Dabei hätte es genügt einfach sachlich zu bleiben. Nano schrieb: > Dabei hätte es genügt einfach sachlich zu bleiben. Einem Troll gegenüber sachlich bleiben? Nein, danke.
Gast
#7294549
MaWin O. schrieb: > Wann hast du das letzte Mal ein C++-Programm mit dem GCC auf einem > Mehrkernrechner compiliert? C++ finde ich auch reichlich überfrachtet und ich würde bei C++ auch nicht an KISS denken. Aber AVRs programmiert man auch eher in C oder Forth. Mir ist dabei schon klar, dass Rust nicht hpts. für AVRs entwickelt wurde. Links (nicht Rechts) schrieb: > Mir ist dabei schon klar, dass Rust nicht hpts. für AVRs > entwickelt wurde. Das ist Unsinn. Was hat das mit dem Speicher zu tun, den du auf der Buildmaschine zur Verfügung haben musst?
Gast
#7294555
In den letzten Beiträgen ging es u.a. um die Programmierung von einem ATtiny85 mit 8K Flash und wenn man einen PC mit mehr als 10 GB RAM braucht, um den zu programmieren, ist das sprichwörtlich "mit Kanonen auf Spatzen schießen". Links (nicht Rechts) schrieb: > In den letzten Beiträgen ging es u.a. um die Programmierung von einem > ATtiny85 mit 8K Flash und wenn man einen PC mit mehr als 10 GB RAM > braucht, um den zu programmieren, ist das sprichwörtlich "mit Kanonen > auf Spatzen schießen". Das kommt halt ganz auf dein Programm an, was du schreibst. Genau, wie es bei C++ ist. Wenn du hunderte Sources nutzt/schreibst, dann wollen die eben auch compiliert werden. Das hat gar nichts mit AVR zu tun.
Gast
#7294561
MaWin O. schrieb: > Nano schrieb: >> Dabei hätte es genügt einfach sachlich zu bleiben. > > Einem Troll gegenüber sachlich bleiben? > Nein, danke. Wilhelm M. war im Gegensatz zu dir sachlich. Sein Beitrag lässt nicht darauf schließen, dass er ein Troll wäre. Nano schrieb: > Wilhelm M. war im Gegensatz zu dir sachlich. Sein Beitrag lässt nicht > darauf schließen, dass er ein Troll wäre. haha. Genau. Lustig. Ein sachlicher Troll. cppbert schrieb: > Bist du ein Clone von rbx, du schreibst auch irgendwie fast genau wie er > - so ein bisschen Fakten, bissel Emotionen, Somway Off-Topics aber > irgendwie related - wilde Mischung > > oder bin ich schon so alt das mir dieser Whatsapp/Tiktok > Kommunikationsstyle einfach nicht vertraut genug ist :) Jetzt nicht, dass mich das nicht interessieren würde, oder dass ich mich wegen dem Alter nicht geschmeichelt fühlen würde:) Trotzdem: Was soll der Scheiss? Wenn dir Einer wegen der Form anstössig abgeht und du komplett den Inhalt ignorierst ist das dein Ding. Versteh ich aber. Das ist die Oberflächlichkeit womit der "kennste ... kennste?" ganze Stadien füllt. Whatsapp/Tiktok: Absolute Jungfrau in dieser Beziehung, also laber keinen Flatterschiss und lassen wir den off-topic Quatsch. Ich habe einen Aspekt von Rust untermauert und einen Grund, wieso es "hier bleibt" mit Beispielen untermauert. rbx kenn ich übrigens genau so wenig wie dich Frechdachs:) P.S.: Meine merkwürdigen Meta-Scherze und schlechte Witze muss ja niemand verstehen oder lieben. Einfach die Fassung bewahren und nicht zuschlagen. Man kann es durchaus überleben. P.S.S.: Wenn ich mal MaWin "zu jubel", weil ich der gleichen Meinung bin dann näss dich bitte nicht gleich ein. Das passt ja kaum zu deinem doch so hohen Alter, also von der geistigen Reife. Von der biologischen schon, hmm... (Muss ich dazu schreiben dass das ein Scherz war und nicht ernst gemeint?:P) MaWin O. schrieb: > Das kommt halt ganz auf dein Programm an, was du schreibst. Und es kommt bei dem Unterton der Diskussion da oben ja wohl auch darauf an, WER das Programm schreibt. Leute, Leute. Wer keine KANONEN zur Verfügung hat, der MUSS halt das nehmen, was er zur Verfügung hat. Rumheulen und Träumen bringt da gar nichts. Man nimmt halt ein Makefile oder gar gleich den Assembler (weil derjenige es muss ... oder nicht anders kann?) anstatt MBED oder Monstren wie PlatformIO, oder alle Cores doppelt mit Link-Time-Optimization zu bemühen. Refrain: Zwangsweise. Oder weil es nicht anders geht. Oder weil es wirtschaftlicher ist. Oder weil wir das so schlank eingeplant haben? Sucht euch was aus ... :P Die oben genannten Anforderungen(10GB) sind ja wohl eher ein Scherz für sogar 10 Jahre alte Entwicklungsarbeitsplätze (und natürlich Subjektiv, eine Hausnummer). Ich will jetzt auch nicht sagen, dass manche Lösung so einfach ist wie: "cargo build --jobs 1", aber bitte bitte bitte: RTFM! So einfach abtun sollte man das natürlich nicht. "Compiler using over 20GiB memory #82406": https://github.com/rust-lang/rust/issues/82406 Mit so hilfreichen Tips wie z.B.: > lto = "off" die nicht nur mir beim dieser LLVM-mässigen compilerverwahrlosenden Speicherverschwendung als Aufruf zur Selbsthilfe in den Sinn kommen. (Das war jetzt teilweise ernst gemeint!:O)) Ist ein Feature! Nich von mir, von LLVM:P Jedzia D. schrieb: > die nicht nur mir beim dieser LLVM-mässigen compilerverwahrlosenden > Speicherverschwendung bekommst du Geld zurück für jedes nicht verwendete Byte deines RAMs? Wie bereits gesagt: Die Speicherlast ist keine Eigenschaft von Rust, sondern eine Eigenschaft jedes modernen optimierenden Compilers. Also offtopic.
Gast
#7294721
Jedzia D. schrieb: > Wenn ich mal MaWin "zu jubel", weil ich der gleichen Meinung bin > dann näss dich bitte nicht gleich ein. Ich finde das MaWin hier gute arbeit leistet - auch wenn er leider oft gegen Windmühlen kämpfen muss
Gast
#7294724
Jedzia D. schrieb: > Die oben genannten Anforderungen(10GB) sind ja wohl eher ein Scherz für > sogar 10 Jahre alte Entwicklungsarbeitsplätze (und natürlich Subjektiv, > eine Hausnummer). blöderweise lässt sich so ein Text auf einer Homepage auch schnell mal uminterpretieren in ein "Rust braucht immer mind 10GB RAM zum kompilieren" aber du hast ganz Recht, viele wissen gar nicht mehr wie viel so ein kompilieren heute an Resourcen braucht, und die ganzen Defaults die Rust mit rein bringt LTO etc. sind natürlich auch nicht ganz ohne - aber auch gewollt rustc ist immer noch (nur) der Referenz-Kompiler und nicht mehr, hier geht es um die Sprache und diese erzwingt nicht per se übetriebene Nutzung von Resourcen - wird sich alles in der Zukunft zeigen, mal schauen wie sich da der gccrs schlagen wird
Gast
#7294733
cppbert schrieb: > aber du hast ganz Recht, viele wissen gar nicht mehr wie viel so ein > kompilieren heute an Resourcen braucht sorry, eher ein Parallel-Bauen mit vielen Kernen cppbert schrieb: > und die ganzen Defaults die Rust > mit rein bringt LTO etc. Cargo default ist lto=off ;) Die 10 GB (oder mehr, je nach Programm) sind worst case, wenn man es darauf anlegt. > hier > geht es um die Sprache und diese erzwingt nicht per se übetriebene > Nutzung von Resourcen Das ist grundsätzlich richtig. Man kann auch Cargo so betreiben, dass es wenig(er) RAM braucht. Vor allem lto=off und single-core-Betrieb werden hier massiv helfen. Natürlich auf Kosten der Codequalität und Compilezeit. Aber ich denke auch, dass Rust als Sprache ansich deutlich höhere Anforderungen an die Hardware stellt, als z.B. C. - Die ganzen statischen Prüfungen, die Rust verlangt, müssen vom Compiler durchgeführt werden. - Die Rust-Syntax ist nicht (wie C) auf einfachste Codegenerierung ausgelegt. In den verschiedenen IRs der Rust-Compilierung kommen massive Codemengen zusammen, die dann von den Optimierungsstufen zusammengeschrumpft werden müssen. Das Vorhandensein dieser Optimierungen ist eine Annahme, die man beim Sprachdesign getroffen hat. Und das kostet Ressourcen bei der Compilierung. Aber solange das sich im vernünftigen Rahmen der verfügbaren Hardware bewegt, dann halte ich das für eine sehr gute Abwägung. Es ist absolut vernünftig die Ressourcen, die zur Verfügung stehen, auch zu nutzen, um in einer modernen Sprache gute Programme zu compilieren. Wenn du nur 10% deines RAMs nutzt, verbessert das rein gar nichts. Wenn du aber 50% deines RAMs nutzt um damit besseren Code zu generieren oder eine bessere Sprache zu ermöglichen, dann verbessert das ganz erheblich was. Meine 2ct. cppbert schrieb: > wird sich alles in der Zukunft zeigen, mal > schauen wie sich da der gccrs schlagen wird Achja, und gccrs. Der wird im ersten Schritt noch keinen Borrow-Checker haben. Alleine deshalb wird gccrs schon wahrscheinlich schlanker und schneller sein. Natürlich auf Kosten der Memory-Safety. Es wird gerade ein neuer Borrow-Checker entwickelt, den man dann sowohl in rustc als auch in gccrs gedenkt einzusetzen. Der Vergleich zwischen rustc und gccrs wird aber immer spannend bleiben. Daraus wird sich hoffentlich ein Rennen um den besten Compiler entwickeln. Links (nicht Rechts) schrieb: > In den letzten Beiträgen ging es u.a. um die Programmierung von einem > ATtiny85 mit 8K Flash und wenn man einen PC mit mehr als 10 GB RAM > braucht Den PC mit mehr als 10 GB RAM brauchst du, um den Compiler zu compilieren, nicht das bissel Programm für den ATtiny. Das ist mit dem AVR-GCC sicher etwas weniger, mit dem AVR-Clang wird sich das nicht so grundlegend unterscheiden.
Gast
#7294795
Ich habe hier u.a. ein altes MacBook und ein Linux Notebook mit 4GB RAM. Darauf habe ich bisher alles kompilieren können, Embedded-Projekte ohnehin, aber auch GUI Anwendungen. Dass grosse Projekte auf diesen alten Kisten Probleme machen, will ich aber natürlich nicht ausschliessen. Was eher auf alten Rechnern mit vergleichsweise kleinen Festplatten/SSDs problematisch sein kann, ist die Grösse des target-Ordners. Da können schnell einige GB zusammenkommen. Oliver R. schrieb: > Ich habe hier u.a. ein altes MacBook und ein Linux Notebook mit 4GB RAM. > Darauf habe ich bisher alles kompilieren können, Embedded-Projekte > ohnehin, aber auch GUI Anwendungen. Aha. Ich habe hier einen Raspberry Pi mit 4GB und darauf kompiliere ich regelmäßig alle meine Rust-Programme. Gar kein Problem. Vielleicht wird es aber auch mal Zeit diese historischen MacBooks und Linux-Notebooks über Bord zu werden, oder halt darauf Software aus der damaligen Zeit zu betreiben. Auf einem Commodore 64 konnte man auch kein Windows 95 installieren. Der zeitliche Abstand dürfte in etwa der gleiche sein. Oliver R. schrieb: > Was eher auf alten Rechnern mit vergleichsweise kleinen Festplatten/SSDs > problematisch sein kann, ist die Grösse des target-Ordners. Da können > schnell einige GB zusammenkommen. Naja. Geht so.
Das ist jetzt eines meiner Embedded-Projekte für ESP32. Das sollte auch auf einem Rechner der ersten SSD-Generationen passen, wenn man das denn will.
Gast
#7295075
Beim target-Ordner sollte man halt wissen, dass die Builds darin versioniert sind. Wenn also z.B. Features geändert oder die Toolchain aktualisiert wird, dann wird ein komplett neuer Build angelegt. Das auch durchaus positiv zu sehen, weil dann schnell zwischen verschiedenen Versionen hin- und hergeschaltet werden kann ohne alles neu kompilieren zu müssen. Wenn man also nicht gelegentlich mal ein "cargo clean" macht, kann der Ordner entsprechend anwachsen.
Die angezeigte Target-Liste zeigt alle bekannten Targets, aber nicht die unterstützten.
beendet mit einem Fehler (rustc stable), da braucht's wohl die nightly als Basis. "avr-unknown-gnu-atmega328" ist offensichtlich ein Misnomer; das Target sollte einfach avr-unknown-gnu oder avr-unknown-none heißen. Tut es aber nicht; vermutlich hatten die Entwickler noch nen ATmega238 irgendwo rumfliegen... rustc basiert ja auf llvm, d.h. es ist llvm + Rust-Frontend. llvm / clang wiederum übernehmen viele Optionen von [avr-]gcc wie -o, -O*, -mmcu= etc. Für ein Frontend wie Rust ist es erst mal egal, ob eine Architektur MUL oder DIV unterstützt oder nicht. Es erzeugt Zwischencode für MUL und DIV etc., der dann irgendwann zu Assembly gelowert wird -- und dann muss man natürlich wissen, ob MUL oder Lib-Call, wie teuer MUL ist etc. Und dieses Lowering erfolgt eben nicht im (Rust-)Frontend. Das einzige, was Rust wissen müsste, ist wie man mit Inline Assembly umgeht, ganz konkret mit Constraints, die ja Target-abhängig sind. Teile der GNU-Tools wie AVR-LibC sind in mehreren Einzelteilen (Crates) verfügbar, die lax in etwa Libraries entsprechen. Es gibt nen Crate für avr-libc Funktionen, nen Crate für SFR-Definitionen (avrd), nen Crate für PROGMEM, nen Crate für ... you name it. Für jedes Puzzleteil muss man wissen, ob man es braucht oder nicht und in welcher Version, die man dann im .toml einträgt. Momentan scheint's da nen ziemlichen Wildwuchs zu geben, auf crate.io nach "avr" zu suchen bringt mehrere Seiten von Crates, wobei da auch andere Bedeutungen von "AVR" bei sind. Ein "offiziellen" AVR Support wie realisiert durch AVR-LibC scheint's nicht zu geben, wie gesagt muss man alles zusammensuchen. Und weil llvm nichts wie GCC's Spec-Files unterstützt, muss jede Kleineigkeit an Target-Optionen im Compiler selbst realsiert sein, so wie es bei avr-gcc bis v4.9 der Fall war.
Gast
#7311757
zu "Aber es gibt natürlich auch Fehler, die durch keine Programmiersprache der Welt verhindert werden." das ist den Rust-Designern und den Anwendern klar - nur damit hier niemand Zeit damit verschwenden muss ein also-doch-nicht-100%-Sicher-Kommentar einzustreuen :)
Gast
#7311815
Das ist richtig. Dazu gehört zum Beispiel das überprüfen der Länge. https://www.heise.de/news/Rust-bis-zu-2500-Projekte-durch-Bibliothek-Hyper-fuer-DoS-verwundbar-7451019.html
Auch die beste Sprache schützt nicht (immer) vor Schludrigkeit.
Gast
#7311836
Gast
#7312227
Das ist den Rust-Entwicklern sehr klar https://blog.rust-lang.org/2023/01/10/cve-2022-46176.html Vor Logikfehlern kann eine Sprache nur in einem gewissen Rahmen schützen. Aber auch da ist Rust besser als typunsichere Sprachen, weil sich solche Logikzusammenhänge oft als Typzusammenhänge formulieren lassen. Somit haben Bibliotheksentwickler die Möglichkeit eine Falschverwendung der APIs zu beschränken.
Gast
#7314682
Mehr Rust in Chrome https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html
Gast
#7314683
Laut Wikipedia hat das Chromium Projekt ca. 35 Mio Zeilen code, mit einem großen Anteil C++
"This will enable us to include Rust code in the Chrome binary within the next year." Das sind ja offenbar überhaupt erstmal die Voraussetzungen, dort Rust zu benutzen. Da ist es ja irgendwie logisch, dass das aktuell noch gar nicht dabei ist.
Gast
#7325820
Da fühlt sich jemand auf den Schlips getreten :D Sichere Programmiersprachen: Bjarne Stroustrup reagiert auf NSA-Empfehlung https://www.golem.de/news/sichere-programmiersprachen-bjarne-stroustrup-reagiert-auf-nsa-empfehlung-2301-171374.html
Gast
#7328160
Rust bietet zumindest (noch) keine Lösung für das kritischste Embedded C/C++ Problem: Is rust guaranteed to detect stack overflows? https://users.rust-lang.org/t/is-rust-guaranteed-to-detect-stack-overflows/52593/1 Rust code segfaults with stack overflow
Wobei "embedded" natürlich eine gaaanz breite Palette ist. Auch da gibt es Hardware, die memory protection kann. Wenn die Hardware das aber nicht kann, wäre der Preis, dass die Software vor jeder Stackoperation selbst erstmal gucken müsste, ob da jetzt eine Kollision entstehen kann. Gerade auf den Plattformen, die keine hardware memory protection haben (weil sie so klein sind) will man diesen Preis ohnehin eher nicht bezahlen.
Gast
#7328264
Es gibt zumindest Ideen dazu.
Gast
#7328325
Auch eine MPU nützt wenig, wenn der Stack nach unten wächst. Da müsste dann wohl eine leere Readonly Page zwischen Heap und Stack.
Zunächst Mal wäre der Aufwand für einen Compiler doch gar nicht so gross, den Platzbedarf für Register, Rücksprungadresse, lokale Variablen beim Funktionsaufruf zu berechnen. Und dann automatisch vor Funktionsaufruf eine Prüfung des Stackpointer zu erzeugen. Das ist eine Subtraktion und ein Compare, kein Aufwand. Bei rekursiven Funktionen in C zähle ich immer die Tiefe manuell mit, nur so kann nichts daneben gehe. Und bei "kleinen Platformen" wie z.B. dem 8051 läuft der Stack nach oben, da braucht es keine MPU, einfach nur Prüfung 0xFF - SP > Platzbedarf. Interrupt Handler müssen gar nicht geprüft werden, da Registerbänke.
Ja sicher. Was weiß der Idiot schon. Nur Rust Fanboys kennen die Wahrheit. In ihrem Leben zwar noch nie was geleistet, aber über einen der bedeutendsten Köpfe im Bereich Programmiersprachen herziehen.
Gast
#7328862
Announcing Rust 1.67.0 https://blog.rust-lang.org/2023/01/26/Rust-1.67.0.html Dieses Mal mehr unsichtbare Arbeiten unter der Haube. Aber auch wichtige Dinge wie die Beschleunigung von einer Variante der Inter-Thread-Communikation. (Was nicht heißt, dass diese vorher langsam war).
Warum sollte Stack-overflow das kritischste Embedded-Problem sein? Gibt es da auch Belege für? Es gibt wieder eine ganz große Ankündigung: https://blog.rust-lang.org/inside-rust/2023/02/23/keyword-generics-progress-report-feb-2023.html Generische Keywords. Das ist ein gigantischer Paukenschlag! Im ersten Schritt soll async (und vielleicht const) generisch werden. Braucht man das? Aber sicher. Das will man haben. Denn ein riesiges Problem bei asynchroner Programmierung ist, dass man vieles doppelt implementieren muss. Einmal als sync-Variante und einmal als async-Variante. Das kennt man auch aus andere Sprachen wie Python. Es gibt dann so Krücken, dass man in der Sync-Variante eine lokale Eventloop aufzieht und dann die async-Variante aufruft. Das funktioniert oft, hat aber entscheidende Nachteile. Erstens natürlich den ganz offensichtlichen Runtime-Overhead. Das will man natürlich vor allem in Rust nicht. Und dann, dass die Rekursion oder Verschachtelung solcher Konstrukte extrem eingeschränkt oder unmöglich ist. Falls sich darunter keiner etwas vorstellen kann: Es ist ähnlich wie const-Funktionen in C++ und auch Rust. Je nach Kontext, in denen sie verwendet werden, verhalten sich const-Funktionen wie const oder wie non-const. (Mehr dazu im verlinkten Artikel) Deshalb: Ich bin echt gespannt, wie async-Generics sein werden. Das wird der Durchbruch sein viele Libraries async-fähig zu machen, ohne alles noch einmal neu implementieren zu müssen. Ich glaube das wird der Durchbruch für die breite Nutzung von async. Aber bis dahin ist noch ein langer weg. Mal sehen, ob es ein kleiner Teil davon in die nächste Edition 2024 schafft. Announcing Rust 1.68.0 https://blog.rust-lang.org/2023/03/09/Rust-1.68.0.html
Mit 1.68 lässt sich nun auch ein globaler Allokator definieren, das war zuvor nur mit nightly möglich.
Mit wie vielen Features will man Rust eigentlich noch überladen?
Deine Frage lässt vermuten, dass du die Möglichkeit, einen globalen Allokator zu definieren, als überflüssig empfindest. Kannst du vielleicht näher erläutern, warum?
Diese Prämisse ist schon falsch.
Damit hat sich diese Frage erledigt.
Deine Frage bezog sich also gar nicht auf den von dir zitierten Text? Warum hast du ihn dann zitiert?
Ja. Du solltest, wenn du ernsthaft Kritik zu irgendetwas loswerden möchtest, auch dazuschreiben, worauf sich deine Kritik konkret bezieht. Oder war deine Frage vielleicht gar nicht kritisch gemeint? Ok, dann kann sie von jedem Rust-Fanboy ja ganz leicht mit "0" beantwortet werden ;-) Warum antwortet ihr diesem Troll immer noch? Das war doch ganz offensichtlich nur eine Trollfrage, um euch aus der Reserve zu locken.
Das ist richtig. Ein wichtiges Feature für manche Embedded-Entwicklungen und Kernelentwicklung.
Doch natürlich bezog es sich auf den zitierten Text. Nur die Prämisse dass ich das Feature als überflüssig empfinde stimmt nicht. Ich halte auch Staubsauger und Gasgrills nicht für überflüssig, würde beides aber ungern in einen Motorroller einbauen. Nicht alles was irgendwie nützlich sein könnte, muss man in diese Sprache reinpacken. Wo soll das Enden? Vor allem wenn man sich im Vergleich anschaut, mit wie wenig Features es C zu weltweiter Verbreitung gebracht hat. Vielleicht sind es eben nicht möglichst viele Features welche eine Sprache gut machen?
Prinzipiell bin ich diesbezüglich ganz bei dir, würde das aber nicht so allgemein formulieren. Deswegen frage ich mal so: Welche Features, die als nützlich angesehen werden und deswegen in Rust integriert wurden, haben deiner Ansicht nach nichts darin verloren? Zählt für dich konkret der benutzerdefinierbare globale Allokator dazu?
Das ist kein gutes Argument. Würde irgendjemand auf Rust umsteigen wollen, wenn er dort nur die bereits von C bekannten Features in einer leicht geänderten Syntax vorfinden würde?
Ich glaube, kein Sprachentwickler(team) hat das Ziel, "möglichst viele" Features in seine Sprache zu packen, sondern versucht, sich auf /sinnvolle/ Features zu beschränken. Natürlich gehen bei der Bewertung der Sinnhaftigkeit von Features die Ansichten stark auseinander. Das kann (und sollte) anhand konkreter Fälle diskutiert werden, es bringt aber nichts, das Hinzufügen neuer Features generell in Frage zu stellen. Was den benutzerdefinierbaren globalen Allokator betrifft: Das ist ein Feature, das für einige Programmierer nützlich ist, vor allem im Embedded-Bereich. Für andere (vor allem PC-Programmierer) ist es nur von geringer Relevanz. Diejenigen, die es nicht benötigen, stört es nicht, weil sie ihre Arbeit genauso fortführen können, wie sie sie vor der Einführung des Features gemacht haben. Das entsprechende Kapitel in der Dokumentation werden sie einfach überspringen. Das Feature stellt auch keine Vergewaltigung bisheriger Sprachelemente dar, wie sie z.T. in C++ (bspw. mit dem völlig unlogischen Überladen einiger Operatoren in der Standardbibliothek) stattgefunden hat. Was konkret spricht also dagegen, den Embedded-Programmierern (die ja immerhin eine der Zielgruppen von Rust sind) zuliebe das Feature einzuführen?
IMHO da, wo ein Feature nur von einer kleinen Minderheit gewünscht wird und nur mit Biegen und Brechen bzw. mit einem groben Bruch der bisher in der Sprache umgesetzten Konzepte implementierbar ist.
Vollkommen korrekt. Zu behaupten die Sprachentwickler würden Features in Rust nur einbauen um mehr Features zu haben, ist ganz offensichtliches Getrolle. Wann kommt denn OOP-Vererbung in Rust? Sie kommt nicht und wird auch nie kommen. Was ist mit Funktionsüberladung? Konstruktoren? Da gibt es dutzende Beispiele für Dinge, die ganz bewusst aus Rust herausgehalten werden. In die Sprache und die stdlib werden Features sehr sehr vorsichtig integriert. Denn wenn sie einmal drin sind, muss man sie für immer unterstützen. Deshalb werden Experimente gerne einmal über lange Zeit in externen Crates gemacht, bis dann schlussendlich Teile davon in die stdlib übernommen werden. Dieser Prozess dauert teilweise sehr viele Jahre. (z.B. GATs).
Natürlich gar nichts. Denn dieses Feature ist in C selbstverständlich auch vorhanden. Es taugt also nicht einmal für die Featureitis-Argumentation.
Ganz genau. Und jetzt kann unser Troll ja einmal ein konkretes Beispiel für ein Feature in der Sprache oder der stdlib liefern, was praktisch niemand braucht und deshalb nur Bloat ist. Windows Treiber mit Rust
Dazu kommt die geschwätzige basic-like Syntax. Das will heute niemand mehr.
Sehr gut. Jetzt habe ich tatsächlich einmal herzhaft lachen müssen. Das ist gesund. Danke dafür, lieber Cyblord. :D
Was ist an der Rust-Syntax basic-like oder gar geschwätzig? Für mich hat die Syntax eher eine gewisse Ähnlichkeit mit C. Hast du jemals in Basic oder C programmiert?
Wasn das für eine blöde Frage? Allein das "let" hat Basic Vibes ohne Ende.
Jetzt muss auch ich lachen, denn ich habe fast geahnt, dass genau das der Grund für deinen obigen Kommentar war. Danke für die Bestätigung :D Die Syntax einer Sprache definiert sich für dich also anhand eines einzelnen Schlüsselworts, und das völlig unabhängig davon, welche Bedeutung dieses hat :) Was glaubst du, in wievielen modernen Programmiersprache es dieses Schlüsselwort gibt? Diese wären nach deiner Argumentation ja automatisch alle Basic-ähnlich. Ganz abgesehen davon ist LET in den meisten Basic-Dialekten seit mindestens vier Jahrzehnten obsolet und wird auch von praktisch niemandem mehr verwendet. Rust ist da eher linuxoid, wie Haskell (ohne Internet irgendwie blöd) , und am besten auch immer alles mit bzw. im Emacs machen. Ich denke, BASIC bleibt als Einstiegssprache immer noch ungeschlagen. Leider hatte man früher auch viel Drumherum-Kultur. Den Part haben jetzt eher c, c++, python und java eingenommen. Sind aber dann aber auch mehrere Baustellen. Tatsächliche Vibes bei Rust müssten in diese Richtung gehen: https://de.wikipedia.org/wiki/Lambda-Kalkül Das ist auch alt, und man kann sich fragen, ob das wohl der Bringer gewesen wäre, hätte man diese Technik schon früh in der Schule durchgekaut. https://github.com/BurntSushi/ripgrep z.B. wäre ein nettes Projekt gewesen.
Beitrag #7505419 wurde von einem Moderator gelöscht.
Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
