Ich lese mir gerade das Rust Tutorial durch: https://doc.rust-lang.org/rust-by-example/index.html Das ganze hört sich ganz nett an, und ich überlege mir, ob ich von C nach Rust wechseln soll. Was mich aber noch etwas zurück hält: Wenn ich ein c99 oder c11 konformes Programm schreibe, dann weiss ich, dass es in 10 Jahren immer noch zahlreiche freie Compiler geben wird, die das problemlos übersetzen können, und das immer noch alles wichtige in C geschrieben ist, und das die Sprache inzwischen nicht gros verhunzt wurde. Aber in Rust gibt es momentan nur den einen Compiler und es ist noch nicht sauber spezifiziert. Die menge an Rust Anwendungen hält sich auch noch in grenzen. Was meint ihr, ist es sicher, auf Rust zu setzen? Ist Rust in 10 Jahren immer noch da? Oder wird es sogar mehr Compiler geben? Werden heutige Programme dann immernoch unverändert gehen? Und wird die Sprache nicht mit allem möglichem unnötigem kram vollgepackt werden, wie es bei C++ passierte? Und wird es für das ding vielleicht auch endlich bald mal ein stabiles ABI geben?
Was soll man darauf antworten? Es kann niemand in die Zukunft schauen. Dass Python nach vielen Jahren sein Mauerblümchendasein verlässt und einen solchen Erfolg hat, konnte auch niemand vorhersehen. Andere Sprachen sind wieder in der Versenkung verschwunden, wie z.B. das unsägliche Oberon in den 90ern, obwohl es damals wie verrückt gehypt wurde. Sagen wir mal so: Jetzt komplett von C nach Rust zu wechseln ist sicher keine gute Idee. Aber das eine oder andere Projekt mal mit Rust zu versuchen kann sicher nicht schaden.
Ich würde das Problem: "Entscheidung für eine Programmiersprache" in Bezug auf Verfügbarkeit ignorieren. (Mittel- und langfristig). ich halte es für wichtig, mehrere verschiedene Sprachen zu können, oder neben zwei oder dreien, die man "kann" und aktiv verwendet, auch einige andere zu kennen. Ohnehin sind sich Sprachen eines Paradigmas (etwa imperative etcpp.) jeweils untereinander syntaktisch sehr ähnlich. Das Problem der Verfügbarkeit tritt dann (fast) gar nicht auf. Dadurch aktiviert und übt man aber auch verschiedene Denkweisen.
Moin, Bisher hab' ich zwar nix selber in rust programmiert, aber schon genug Malheur im Rahmen von BLFS/ Bau von firefox gehabt. Mein Eindruck ist, dass das der rust-compiler ein fuerchterlich anfaelliger Haufen Code ist, der sich immer nur exakt mit ganz bestimmten Versionen von clang, rust etc. ueberhaupt bauen laesst. Sowie da irgendwas nicht passt, klemmts ganz arg. Ich find's schon ein Unding, dass das bei C++ so ein Rumgefuhrwerke ist, alten Code mit neueren Compilern bauen zu koennen, aber da gehts um Jahre und nicht wie bei rust um Monate, wo das Zeugs sich schon nicht mehr bauen laesst. Gruss WK
Dergute W. schrieb: > Ich find's schon ein Unding, dass das bei C++ so ein Rumgefuhrwerke ist, > alten Code mit neueren Compilern bauen zu koennen, aber da gehts um > Jahre und nicht wie bei rust um Monate, wo das Zeugs sich schon nicht > mehr bauen laesst. Ja, skandalös dass neuere Compiler-Versionen besser darin werden Programmierfehler zu finden und einen am Debuggen hindern...
Theor schrieb: > Ich würde das Problem: "Entscheidung für eine Programmiersprache" in > Bezug auf Verfügbarkeit ignorieren. (Mittel- und langfristig). Ich will schon, dass die Programme die ich schreibe und veröffentliche, auch in Zukunft noch jemandem nützen konnten. > ich halte es für wichtig, mehrere verschiedene Sprachen zu können, oder > neben zwei oder dreien, die man "kann" und aktiv verwendet, auch einige > andere zu kennen. Ich kann und kenne schon einige. Das ist natürlich wahr, es ist nie falsch, eine Sprache zu Lernen. Dergute W. schrieb: > Mein Eindruck ist, > dass das der rust-compiler ein fuerchterlich anfaelliger Haufen Code > ist, der sich immer nur exakt mit ganz bestimmten Versionen von clang, > rust etc. ueberhaupt bauen laesst. Sowie da irgendwas nicht passt, > klemmts ganz arg. Oh, das wusste ich nicht. Ich hatte gehofft, nach 8 Jahren währe man da etwas weiter. Dann beobachte ich das vielleicht doch lieber noch zuerst ein par Jährchen.
DPA schrieb: > Dergute W. schrieb: >> Mein Eindruck ist, >> dass das der rust-compiler ein fuerchterlich anfaelliger Haufen Code >> ist, der sich immer nur exakt mit ganz bestimmten Versionen von clang, >> rust etc. ueberhaupt bauen laesst. Sowie da irgendwas nicht passt, >> klemmts ganz arg. > > Oh, das wusste ich nicht. Ich hatte gehofft, nach 8 Jahren währe man da > etwas weiter. Dann beobachte ich das vielleicht doch lieber noch zuerst > ein par Jährchen. Da bin ich anderer Meinung. Durch den Paketmanager Cargo weiss der Compiler genau, welche Bibliotheken sicher laufen, welche Updates der Bibliotheken zu der aktuellen kompatibel usw. sind. Der Rust Code an sich ist rückwärtskompatibel, d.h. Code in einerer früheren Version (ab 1.0, davor war beta) wird garantiert von neuen Compiler auch "verstanden".
:
Bearbeitet durch User
Silvano C. schrieb: > Da bin ich anderer Meinung. > Durch den Paketmanager Cargo weiss der Compiler genau, welche > Bibliotheken sicher laufen, welche Updates der Bibliotheken zu der > aktuellen kompatibel usw. sind. > Der Rust Code an sich ist rückwärtskompatibel, d.h. Code in einerer > früheren Version (ab 1.0, davor war beta) wird garantiert von neuen > Compiler auch "verstanden". Ich glaube es ging eher darum, das der Compiler selbst sehr Problem anfällig bezüglich seiner eigenen Kompilierung sei, und nicht darum, wie anfällig die Rust Programme währen, wenn man den Compiler mal hat. Wenn man den Compiler mal irgendwann nicht mehr bauen können sollte, nützt es einem nichts, wenn das Programm noch liefe, wenn man den Compiler um dieses zu bauen denn noch bauen könnte.
Theor schrieb: > Ich würde das Problem: "Entscheidung für eine Programmiersprache" in > Bezug auf Verfügbarkeit ignorieren. (Mittel- und langfristig). Das sehe ich etwas anders. Als ich mich damals(tm) im Jahr 2004 selbstständig machte, war ein guter Freund von mir gerade ein großer Smalltalk-Fan und -Verfechter. Er versuchte fast täglich, mich dazu zu überreden, auch exklusiv mit Smalltalk zu entwickeln und alle alten Zöpfe abzuschneiden. Auf meine Nachfrage, für welche Microcontroller es denn Smalltalk-Umgebungen gäbe, fand er nach länglicher Suche einen Anbieter, der damals kurz vor dem Durchbruch stünde, Smalltalk für einige ARM-Prozessoren zu unterstützen. Super. Und entgegen seiner damaligen Prophezeiungen ist Smalltalk immer noch nicht aus seiner Nische herausgekommen. Es ist generell ein falscher Weg, nur noch auf ein einzelnes Pferd zu setzen, insbesondere wenn dessen Mutter noch gar nicht richtig schwanger ist. > ich halte es für wichtig, mehrere verschiedene Sprachen zu können, oder > neben zwei oder dreien, die man "kann" und aktiv verwendet, auch einige > andere zu kennen. Ja, so etwas ist sehr wichtig. Leider erlebe ich es auch bei manchen Kunden immer wieder, dass ausgerechnet die Leute mit den größten Scheuklappen diejenigen sind, die Architekturen mit seit zwanzig Jahren schwächelnden Konzepten entwerfen. :-/ Ein kleiner Blick auf andere Programmiersprachen und deren Konzepte würde völlig ausreichen, um zu erkennen, dass gigantisch verschnörkelte C-Präprozessor-Makros nicht mehr zeitgemäß sind, um damit halbwegs zukunftssichere APIs zu definieren.
Andreas S. schrieb: > Auf meine Nachfrage, für welche Microcontroller es > denn Smalltalk-Umgebungen gäbe, fand er nach länglicher Suche einen > Anbieter, der damals kurz vor dem Durchbruch stünde, Smalltalk für > einige ARM-Prozessoren zu unterstützen. Super Das wäre bei Rust sicher nicht das Problem, da Rust auf das LLVM-Backend setzt
Silvano C. schrieb: > Das wäre bei Rust sicher nicht das Problem, da Rust auf das LLVM-Backend > setzt Auch schon im Jahr 2004?
Moin, Silvano C. schrieb: > Das wäre bei Rust sicher nicht das Problem, da Rust auf das LLVM-Backend > setzt Naja, mal gucken: Fuer ein C Programm brauchst du z.b. einen gcc+binutils. gcc ist abhaengig von (Kernel und einer) libc. Um einen llvm zu bauen,brauchste python, cmake und einen gcc. Also mindestens schon einen c++ compiler, sonst wirds nix mit cmake (wahrscheinlich auch fuer Python). Python hat die angenehme Eigenschaft, in Geschmacksrichtung (2 und 3) herzukommen; im Zweifelsfall brauchts dann auch immer beide. Um rust zu bauen brauchste llvm und einen riesenhaufen Zeugs, der so riesig und komplex ist, dass das automatisch irgendwie von irgendwoher runtergeladen werden muss. Und dann noch diversen anderen, nicht so exotischen Kram wie auch wieder Python und libssh. Jetzt kann man sich natuerlich als z.B. Ubuntu-Aeffchen auf den Standpunkt stellen: Ist mir alles wurscht. Ich hab's voll drauf, denn so wie Windowsprofis auf jede setup.exe klicken koennen, kann ich ja einfach "sudo apt-get gedoens" tippern und alles wird immer gut!einself! Aber wenn man dann und wann auch mal Software fuer nicht-mainstream Platformen haben will, kann's schonmal beliebig bloed werden mit dem Herbeizaubern einer (ggf. cross-)toolchain und was man sonst noch an Umgebung braucht. Und da bin ich persoenlich echt froh, wenn's nicht so irrsinnig ausufert, nur weil unbedingt irgendwer irgendwelchen heissen Scheiss ausprobieren musste. Aber das ist nur meine kleine, beschraenkte Meinung, Profi-Informatiker sehen das sicherlich ganz anders. (Ocaml war glaub' ich auch mal ziemlich hipp, iirc gabs irgendwelches Filesharing-Zeugs was in Ocaml geschrieben war.) Gruss WK
Dergute W. schrieb: > und wann auch mal Software fuer nicht-mainstream Platformen haben will, > kann's schonmal beliebig bloed werden mit dem Herbeizaubern einer (ggf. > cross-)toolchain Konnte nicht eine LLVM-Installation automatisch für alle Targets Code generieren? Also die Komplexität des Bauens des Compilers ist ein ziemliches Dummy Argument. Einen GCC mit allen benötigten libc-Varianten zu bauen ist auch ganz schön zum Haare raufen.
Dr. Sommer schrieb: > Konnte nicht eine LLVM-Installation automatisch für alle Targets Code > generieren? > Also die Komplexität des Bauens des Compilers ist ein ziemliches Dummy > Argument. Einen GCC mit allen benötigten libc-Varianten zu bauen ist > auch ganz schön zum Haare raufen. Ja. Im Gegensatz zum GCC ist das ein Cross-Compiler in sich und benötigt nicht für jede Architektur einen eigenen Build. Mal abgesehn von der Schwachsinnigkeit des Arguments hat GCC übrigens wesentlich mehr (legacy) Abhängikeiten als LLVM und rustc. Meiner Meinung nach ist Rust hier um zu bleiben. Das liegt zum einen daran weil die Community über die "critical mass" hinaus gewachsen ist und zum anderen weil Rust als WebAssembly Sprache wohl für viele sehr attraktiv sein wird.
Moin, Dr. Sommer schrieb: > Einen GCC mit allen benötigten libc-Varianten zu bauen ist > auch ganz schön zum Haare raufen. Eigentlich reicht ja eine. Aber OK, auch die kann schmerzhaft sein. Nur, wenn das schon nicht klappt, wie wirds dann llvm und "schlimmeres" geben? Vincent H. schrieb: > Ja. Im Gegensatz zum GCC ist das ein Cross-Compiler in sich und benötigt > nicht für jede Architektur einen eigenen Build. Das klingt interessant. Haste mal ein Beispiel, wie man so auf die Schnelle mit einem llvm aufm x86_64 PC so was ganz simples wie ein HelloWorld fuer eine gaengige Architektur wie z.b. ARM crosskompilieren kann? > Mal abgesehn von der > Schwachsinnigkeit des Arguments hat GCC übrigens wesentlich mehr > (legacy) Abhängikeiten als LLVM und rustc. OK, und was waeren das fuer "(legacy) Abhängigkeiten"? Vincent H. schrieb: > Meiner Meinung nach ist Rust hier um zu bleiben. Das liegt zum einen > daran weil die Community über die "critical mass" hinaus gewachsen ist > und zum anderen weil Rust als WebAssembly Sprache wohl für viele sehr > attraktiv sein wird. Naja, die verwendete Sprache sollte halt zum zu loesenden Problem passen. Da kanns schon sein, dass jetzt moderner Webkram mit Rust die tollste Wurst ist. Ich sag' nochmal: Wenn man sicher ist, sich jederzeit mit "sudo apt-get install", setup.exe oder aehnlich "evelynesken" Kommandos die benoetigte Umgebung herzaubern kann, dann ist das alles simpel. Nachdem aber im Eroeffnungspost explizit ein Zeitraum von 10 Jahren angegeben wurde, hab' ich halt so meine Zweifel an rust. Aber natuerlich kann ich nicht in die Zukunft blicken, nur aus der Vergangenheit versuchen zu interpolieren... Gruss WK
Dergute W. schrieb: > Das klingt interessant. Haste mal ein Beispiel, wie man so auf die > Schnelle mit einem llvm aufm x86_64 PC so was ganz simples wie ein > HelloWorld fuer eine gaengige Architektur wie z.b. ARM crosskompilieren > kann? Man muss dem Compiler lediglich das Target als flag übermitteln. Also in etwa so:
1 | --target=arm-none-eabi -march=armv7e-m |
Default ist natürlich x86.
> OK, und was waeren das fuer "(legacy) Abhängigkeiten"?
isl und gmp fallen mir da ein...
und da gabs noch ein paar so lustige Acronmy wo man sich erstmal denkt
"hä?"
Und wenn man schon auf Python rumhakt. Braucht GCC nicht Perl?
:
Bearbeitet durch User
Andreas S. schrieb: > Theor schrieb: >> Ich würde das Problem: "Entscheidung für eine Programmiersprache" in >> Bezug auf Verfügbarkeit ignorieren. (Mittel- und langfristig). > > Das sehe ich etwas anders. [...] Möglicherweise ist eine Klarstellung angebracht: Mit "die Entscheidung ignorieren" meine ich, keine Entscheidung davon abhängig zu machen; keine Entscheidung zu treffen. Nicht trotz des fehlenden Wissen von der Zukunft eine Entscheidung dafür oder dagegen zu treffen, diese Sprache vorzugsweise oder als einzige zu benutzen. Andernfalls beschreibt Dein Smalltalk-Beispiel genau, was ich meine: Weder für noch gegen Smalltalk allein entscheiden. Mal abgesehen davon finde ich Smalltalk als Sprache gut. Mir doch egal, ob das in einer Nische hockt oder nicht. > [...] >> [...] > Ja, so etwas ist sehr wichtig. Leider erlebe ich es auch bei manchen > Kunden immer wieder, dass ausgerechnet die Leute mit den größten > Scheuklappen diejenigen sind, die Architekturen mit seit zwanzig Jahren > schwächelnden Konzepten entwerfen. :-/ Was meinst Du konkret damit? Welche Konzepte? Welche Sprache? Das sind Meinungsfragen, keine absoluten, objektiven Werte. Solange eine Konzept stringent ist und die so geschriebenen Codes einigermaßen beweisbar und deterministisch tun was sie sollen, ist das alles ein Streit um des Kaisers Bart. Die Realität ist doch eher so, dass es potentiell so viele Programmiersprachen gibt, wie es Vorstellungen von der programmatisch kontrollierten Wirklichkeit gibt. Gibt ja auch Sprachen die das aktiv unterstützen - etwa FORTH, oder mit Operator-Overloading eben auch C++ u.a. > Ein kleiner Blick auf andere > Programmiersprachen und deren Konzepte würde völlig ausreichen, um zu > erkennen, dass gigantisch verschnörkelte C-Präprozessor-Makros nicht > mehr zeitgemäß sind, um damit halbwegs zukunftssichere APIs zu > definieren. Darum ging es ja gar nicht. Nicht darum Sprachen zu entwerfen, sondern sie zu benutzen. Und worauf bezieht sich Architektur? Meinst Du eigentlich "Paradigma"? Abgesehen davon, ist mir unklar, was "Verschnörkelungen" mit C-Makros zu tun haben und die wiederum mit "Architektur" oder "Paradigma".
Moin, Vincent H. schrieb: > Man muss dem Compiler lediglich das Target als flag übermitteln. Also in > etwa so: > Hmmmm....
1 | echo "main() {}" > hello.c |
2 | clang hello.c #OK, da faellt ein a.out raus. |
3 | clang -target arm-none-eabi hello.c |
4 | error: unable to create target: 'No available targets are compatible with this triple.' |
Hm, ok - also was kann denn mein clang fuer Targets? Uuupsi: https://stackoverflow.com/questions/15036909/clang-how-to-list-supported-target-architectures Scheint garnicht so simpel zu sein, das rauszukriegen...(Bloss gut dass ich ihn selbergebaut hab', da weiss ich's noch). Es ist also keinesfalls so, dass da automatisch immer alle crosscompiler mitdrinnen sind. Das muss beim Bau angegeben sein. Und genau solche Sachen erzeugen bei mir die Skepsis. Jeder blubberts nach, weils irgendwo steht, aber wenn man's dann wirklich ausprobieren will, wirds schnell zaeh'. Vincent H. schrieb: > isl und gmp fallen mir da ein... OK, ohne isl und diverse andere Gimmicks lassen sich sehr wohl gccs bauen. mpfr, gmp, mpc - ja klar, irgendwie muss der compiler konstante Ausdruecke ja auch berechnen koennen. Ich wuesst' nicht, wie llvm ums berechnen beim compilieren rumkommt. Vielleicht macht er's so wie alte gccs und hat den ganzen Schmonz irgendwo festeingebaut. Ich sag' mal: An dem Tag, wo ein LFS/BLFS artiges Projekt rauskommt, bei dem nicht mit gcc usw. angefangen wird, sondern mit rustc und mit dem dann llvm und danach evtl noch gcc gebaut wird - da bin ich auch ueberzeugt, dass rust eine tolle Dauerwurst ist. vorher eher noch nicht :-) Gruss WK
Wenn BLFS und Co für dich die Messlatte für etablierte Sprachen ist, dann wirst du am Sterbebett noch mit K&R C zu tun haben (müssen). ;) Dafür dass du bei deinen Builds alle Targets rausnimmst kann ja ich nix.
Dergute W. schrieb: > Eigentlich reicht ja eine Eine für Soft float, eine für vfp4-sp-d16, eine für vfp4-dp-d16, vfp3-sp-d16, ... Dergute W. schrieb: > moderner Webkram mit Rust Rust ist nicht für Web. Das ist für performante Low-Level Codes. Also hauptsächlich als C und C++ Ersatz. Und wenn man unbedingt ein LLVM für ein exotisches Target/Host bauen will, kann man das ja unter einem Ubuntu tun, wo man alles per apt-get installiert hat. Wenn man's richtig macht läuft das dann überall. Das Build Script für den GCC-ARM-Embedded ist auch ein paar kLoC lang. Ist wohl doch nicht so einfach. Den Rattenschwanz an Dependencies lädt es manuell runter. Es funktioniert auch nur unter Ubuntu, und nur unter 32bit. Executables für Win64 kann es nicht erstellen. Da ist auch nicht alles in Butter...
Von rust werden momentan diese Architekturen unterstuetzt:
1 | $ rustup target list |
2 | aarch64-apple-ios |
3 | aarch64-fuchsia |
4 | aarch64-linux-android |
5 | aarch64-pc-windows-msvc |
6 | aarch64-unknown-cloudabi |
7 | aarch64-unknown-linux-gnu |
8 | aarch64-unknown-linux-musl |
9 | arm-linux-androideabi |
10 | arm-unknown-linux-gnueabi |
11 | arm-unknown-linux-gnueabihf |
12 | arm-unknown-linux-musleabi |
13 | arm-unknown-linux-musleabihf |
14 | armebv7r-none-eabi |
15 | armebv7r-none-eabihf |
16 | armv5te-unknown-linux-gnueabi |
17 | armv5te-unknown-linux-musleabi |
18 | armv7-apple-ios |
19 | armv7-linux-androideabi |
20 | armv7-unknown-linux-gnueabihf |
21 | armv7-unknown-linux-musleabihf |
22 | armv7r-none-eabi |
23 | armv7r-none-eabihf |
24 | armv7s-apple-ios |
25 | asmjs-unknown-emscripten |
26 | i386-apple-ios |
27 | i586-pc-windows-msvc |
28 | i586-unknown-linux-gnu |
29 | i586-unknown-linux-musl |
30 | i686-apple-darwin |
31 | i686-linux-android |
32 | i686-pc-windows-gnu |
33 | i686-pc-windows-msvc |
34 | i686-unknown-freebsd |
35 | i686-unknown-linux-gnu |
36 | i686-unknown-linux-musl |
37 | mips-unknown-linux-gnu |
38 | mips-unknown-linux-musl |
39 | mips64-unknown-linux-gnuabi64 |
40 | mips64el-unknown-linux-gnuabi64 |
41 | mipsel-unknown-linux-gnu |
42 | mipsel-unknown-linux-musl |
43 | powerpc-unknown-linux-gnu |
44 | powerpc64-unknown-linux-gnu |
45 | powerpc64le-unknown-linux-gnu |
46 | riscv32imac-unknown-none-elf |
47 | riscv32imc-unknown-none-elf |
48 | s390x-unknown-linux-gnu |
49 | sparc64-unknown-linux-gnu |
50 | sparcv9-sun-solaris |
51 | thumbv6m-none-eabi |
52 | thumbv7em-none-eabi |
53 | thumbv7em-none-eabihf |
54 | thumbv7m-none-eabi |
55 | wasm32-unknown-emscripten |
56 | wasm32-unknown-unknown |
57 | x86_64-apple-darwin |
58 | x86_64-apple-ios |
59 | x86_64-fuchsia |
60 | x86_64-linux-android |
61 | x86_64-pc-windows-gnu (installed) |
62 | x86_64-pc-windows-msvc |
63 | x86_64-rumprun-netbsd |
64 | x86_64-sun-solaris |
65 | x86_64-unknown-cloudabi |
66 | x86_64-unknown-freebsd |
67 | x86_64-unknown-linux-gnu (default) |
68 | x86_64-unknown-linux-gnux32 |
69 | x86_64-unknown-linux-musl |
70 | x86_64-unknown-netbsd |
71 | x86_64-unknown-redox |
AVR soll auch unterstuetzt werden, sobald das AVR Backend fehlerfreier ist. Solange gibt es das avr-rust projekt. Der Buildprozess ist mit cargo super angenehm. Man hat eine gewisse Sicherheit was Rebuild-Sicherheit angeht, da alle veroeffentlichen Versionen eines Crates immer wieder runterladbar sind. Man kan alte Versionen extra markieren, womit diese nicht mehr fuer neue projekte verwendet werden koennen, aber fuer alte projekte erhalten bleiben. Arbeitet man mit den Crates von crates.io dann ist auch die verwaltung der abhaengigkeiten sehr einfach. Das Oekosystem ist meiner Meinung nach das groesste Plus bei Rust. Durch die Gestaltung von Rust ist der Code sehr aussagekraeftig.
1 | fn main() { |
2 | let mut _x: u8 = 255; |
3 | _x += 1; |
4 | } |
Kommt es bei der Ausfuehrung zum ueberlauf stuerzt das Programm ab.
1 | thread 'main' panicked at 'attempt to add with overflow', src/main.rs:3:5 |
Schreibt man das ganze so:
1 | fn main() { |
2 | let mut _x: u8 = 255; |
3 | _x = _x.wrapping_add(1); |
4 | } |
ist alles gut und man bekommt seinen ueberlauf. Die Sprache schuetzt zum einem vor dem Fehler von ungewollten ueberlaeufen, und zum anderen bietet sie die moeglichkeit eines gewollten ueberlaufs, was man dann aber auch so im code ausdruecken muss. Das traegt doch ungemein zum verstaendis von fremdcode bei. Neben wrapping_add() gibt es noch andere funktionen, die einem dann auch noch sagen ob es einen ueberlauf gab. Wie viele threads gibt es hier, wo sich drueber gestritten wird wie man in c oder c++ am besten und sichersten einen ueberlauf feststellt... Die generierte Doku gefaellt mir deutlich besser, als das was ich bisher bei anderen Sprachen gesehen habe. Unit-Tests (und auch benchmark-tests) sind gleich mit dabei, und man kann auch private Methoden testen, ohne sich einen abbrechen zu muessen. Mit rustfmt kann man den Code entsprechend den Rustguidlines formatieren lassen. Unter Visual Studio Code laesst sich Rust genauso einfach wie C oder C++ debuggen. Ja, einige konzepte sind sehr ungewoht wenn man von c/c++ kommt (hallo borrow-checker, mein freund...), aber das ist okay. Es gibt praktisch keinen Grund, Rust nicht mal wenigstens eine ernsthafte chance zu geben. Und mit ernsthaft meine ich, dass man sich schon mal 1 Monat etwas intensiver mit Rust beschaeftigt haben sollte. Meiner Meinung nach ist Rust die beste alternative zu C und C++, wenn es um low-level geht, besonders weil sie auch viele embedded targets unterstuetzt. Ebenso denke ich, das Rust in zukunft noch eine grosse Rolle spielen wird, wenn es um sichere Software geht. Ja, Rust ist gekommen um zu bleiben.
Rust wird bleiben, da die Lizenz von LLVM frei genug ist um LLVM auch in proprietärer Software einzubauen und somit den langfristigen Support von LLVM und seiner Front- und Backends auch durch Firmen mit Geld in der Tasche und Manpower sicherzustellen. Ein paar Dutzend an Compilern braucht es zum überleben der Sprache also da gar nicht zwingend, obwohl es die sicher auch geben wird, sondern nur die richtige Lizenz für den Marktrelevanten Compiler. Zum Vergleich bei Java nimmt man für die x86 Architektur entweder den Compiler von Oracle Java oder OpenJDK und dann kommt eine Weile nichts mehr, obwohl es noch andere Implementationen gibt. Bei C# ist es nicht viel anders. LLVM wird also vor allem auch aufgrund seiner unproblematischen Lizenz das alles alleine stemmen können und das auch langfristig. Außerdem werden die Backends, also der Teil der den architekturspezifischen Maschinen- oder VM Code erstellt, vom Rust Frontent komplett unabhängig entwickelt. Allein das sorgt schon dafür das die Entwicklung weitgehend zukunftsicher ist, es müssen sich nur genug Leute finden die das Frontend von Rust pflegen und das ist durch die freie Lizenz, die auch Firmen mit ins Boot holt gesichert. Dazu kommen noch die Vorteile der Sprache selbst bezüglich Speicherschutz und Multi CPU Fähigkeit hinzu, die die Sprache für Programmierer extrem attraktiv macht. Ich mache mir da keine Sorgen. Zum Vergleich, die Zukunftsicherheit von bspw. D ist weit weniger gewiss.
Nano schrieb: > LLVM wird also vor allem auch aufgrund seiner unproblematischen Lizenz > das alles alleine stemmen können und das auch langfristig. > > Außerdem werden die Backends, also der Teil der den > architekturspezifischen Maschinen- oder VM Code erstellt, vom Rust > Frontent komplett unabhängig entwickelt. > Allein das sorgt schon dafür das die Entwicklung weitgehend > zukunftsicher ist, es müssen sich nur genug Leute finden die das > Frontend von Rust pflegen und das ist durch die freie Lizenz, die auch > Firmen mit ins Boot holt gesichert. > > Dazu kommen noch die Vorteile der Sprache selbst bezüglich > Speicherschutz und Multi CPU Fähigkeit hinzu, die die Sprache für > Programmierer extrem attraktiv macht. Sehe ich genauso. Mittlerweile nutzen einige Programmiersprachen (respektive deren Compiler) LLVM: -ActionScript -Ada -C# -Common Lisp -Crystal -CUDA -D -Delphi -Fortran -Graphical G Programming Language -Halide -Haskell -Java bytecode -Julia -Kotlin -Lua -Objective-C -OpenGL Shading Language -Pony -Python -R -Ruby -Rust -Scala -Swift -Xojo (https://en.wikipedia.org/wiki/LLVM) Ich denke also nicht das LLVM so schnell verschwinden wird. Auch auf Rust basieren mittlerweile einige Projekte, welche auch diese zum bleiben einladen: -Firefox (zu mindestens Teile davon, bald auch die WebEngine) -Microsoft Azure -Stratis -Railcar Kaj schrieb: > Ja, Rust ist gekommen um zu bleiben. Das denke ich auch
Silvano C. schrieb: > Mittlerweile nutzen einige Programmiersprachen (respektive deren > Compiler) LLVM: Und natürlich auch C und C++! Clang ist eine ernstzunehmende Konkurrenz für GCC. Man könnte sogar sagen dass die Konkurrenz durch Clang die Entwicklung von GCC sogar auch beschleunigt hat...
Silvano C. schrieb: > Ich denke also nicht das LLVM so schnell verschwinden wird. > Auch auf Rust basieren mittlerweile einige Projekte, welche auch diese > zum bleiben einladen: > -Firefox (zu mindestens Teile davon, bald auch die WebEngine) > -Microsoft Azure > -Stratis > -Railcar Mittelfristig wird sicherlich noch Thunderbird dazukommen.
Ich wuerde sagen: Rust ist wie C/C++, nur in "besser" -> mit weniger (Laufzeit)-Fallstricken und an die Zeit angepasst. Eine low level Sprache bei der man erkennen kann: Ja, wir haben aus den letzten 40 Jahren Softwareentwicklung etwas gelernt (auch wenn es mit sicherheit nicht perfekt ist).
Die Entwicklung von Rust begann 2006, also vor 13 Jahren und wird seit 2009 von Mozilla gesponsort. Seit 2012 gibt es offizielle Releases mit Versionsnummer. Das angehängte Diagramm zeigt die Veröffentlichungsdaten der Minor-Releases (d.h. mit einer Versionsnummer der Form x.y oder x.y.0) seit 2012. Man sieht, dass die Release-Frequenz stetig zunimmt. Allein letztes Jahr gab es 18 Releases, also etwa alle 20 Tage eines. Das ist ein starkes Indiz dafür, dass sehr intensiv an dem Projekt gearbeitet wird. Ein Projekt, wo 13 Jahre lang so viel Arbeit hineingesteckt wurde, kommt nicht so schnell zum Stillstand. Laut Github arbeiten 88 Leute daran, so dass auch der Ausfall einzelner Personen kein unüberwindliches Problem darstellen sollte. Selbst wenn Mozilla die finanzielle Förderung einstellen sollte, wird das die Entwicklung zwar verlangsamen, ich kann mir aber nicht vorstellen¸ dass sich die Entwickler komplett aus dem Projekt zurückziehen und damit ihre langjährigen Arbeit in die Tonne treten werden. IMHO wird Rust innerhalb der nächsten 10 Jahre nicht eine der Mainstream-Sprachen werden wie heute bspw. C, C++, Java und Python, es wird aber sehr wahrscheinlich "Marktanteile" hinzugewinnen. Aussterben (in dem Sinne, dass Compiler und Bibliotheken nicht mehr gepflegt werden) wird es nicht, da bin ich mir ganz sicher.
Ich bin gerade dazu gekommen mal ein simples "Hello World" Programm mit C, C++ und Rust in einer Anwendung zu machen, um zu sehen, wie gut das geht, und um einen Eindruck zu bekommen, ob es beim Build irgendwelche problematischen Dinge gibt. Es geht grundsätzlich, aber es gibt 2 Problematische Sachen: 1) Das erste ist eigentlich kein Rust Problem, sondern etwas, das eigentlich alle C, C++, Rust, etc. Compiler betrifft: Die Compiler bilden ein Wrapper für den Linker, und der Linker ist dadurch fast nicht mehr Standalone verwendbar, weil man beim Aufruf die Runtimelibraries der Sprachen, Systemweit verwendete libraries wie die jeweilige ld.so kennen muss, und noch viele weitere Optionen. Man kann einen der Compiler als Wrapper verwenden, bestenfalls der in dessen Sprache die main geschrieben wurde, und dann die anderen Runtimes dazu linken. gcc, g++, clang und clang++ haben derart ähnliche Optionen, und bieten derart gute Möglichkeiten Optionen zum Linker weiterzureichen, dass mich das dort nicht sehr gestört hat. Wenn jetzt aber noch rustc dazu kommt, mit komplett anderen Optionen, die viel mehr high-level sind und weniger low-level zeug erlauben, wird es langsam zum Problem, insbesondere, da vermutlich nicht vorgesehen ist, das ohne cargo so zu verwenden. Ich muss irgendwann mal eine standalone linker-wrapper Anwendung erstellen, der man einfach sagen kann, linker X, runtimes für rust&c&c++, entry point mit runtime X behandeln, und dann die restlichen linker Optionen an den Linker weitergeben, und womöglich noch ein allgemeines subset der Optionen bieten. Das würde das Problem lösen, und währe vermutlich auch nicht schwer umzusetzen, jedoch müssten es die Compiler/Linkerbauer sowie die Distributionen dann vermutlich in ihre Packages der jeweiligen Linker miteinbeziehen, damit es immer reibungslos verwendbar würde, was eher unwahrscheinlich ist. 2) Das zweite Problem ist auch nicht direkt Rust, sondern cargo. Es ist nicht so, dass man rust nicht (noch) ohne cargo verwenden könnte, aber es ist klar, dass die Verwendung von rust mit cargo die einzige "normale" Nutzung von rust ist, und anderes nicht wirklich vorgesehen ist. Mein Problem mit Cargo ist wieder zweierlei: a) Es ist ein build tool (ähnlich wie make, cmake, automake, etc.) aber auch ein Package Manager. Es ist nicht vorgesehen, cargo nur als Packagemanager zu verwenden, und ein anderes, bestehendes build automations tool, die bei vielen anderen Sprachen zum Einsatz kommen, zu verwenden. Zudem wird die Projektstruktur zu einem gewissen grad vorgegeben. Das führt zu unnötigen Komplikationen, wenn man ein anderes build tool verwenden will, oder einzelne Rust quellen in ein bestehendes nicht-rust Projekt integrieren will. b) crates.io. Gut, das Problem haben npm und pip auch. Ja, man kann direkt auf ein Verzeichnis oder auf ein Git repo verweisen, und man könnte wohl auch irgendwie andere Registries angeben. Aber crates.io ist der default. Es steht nirgends, wer es betriebt. Vermutlich Mozilla? Es gibt keine Mirrors, und keine simplen Schnittstellen (z.B. rsync) um es vollständig zu Mirroren. Die meisten Programme werden Dependencies darauf haben. All dies macht es zu einem gefährlichen Single point of failure. Das alles ist jetzt noch nicht allzu tragisch, aber ich muss das bei zukünftigen Ernsthafteren Projekten im Auge behalten & Gegenmassnahmen treffen. Mein "Hello World" versuch ist im Anhang. Ihr müsst vermutlich im makefile die Nummer beim "-lstd-df4a2aaeab5f3a68" anpassen (ist ein Teil der rust standard library). (Einfach mit ls -1 /usr/lib/x86_64-linux-gnu/libstd-*.so nachsehen.)
Den Code von crates.io kannst du forken und wie das mit den Mirrors geht steht auch auf der Github Seite von crates.io https://github.com/rust-lang/crates.io Deploying & using a mirror https://github.com/rust-lang/crates.io/blob/master/docs/MIRROR.md#deploying--using-a-mirror Und wie man ein crates.io lokal laufen laesst steht unter contributing: https://github.com/rust-lang/crates.io/blob/master/docs/CONTRIBUTING.md
1 | Once you have a local instance of crates.io running at |
2 | http://localhost:4200 by following the instructions in the |
3 | "Working on the Backend" section, you can go to another Rust project |
4 | and tell cargo to use your local crates.io instead of production. |
Warum es Cargo gibt, und warum das Paketmanager und Buildtool in einem ist (und warum das nutzen ohne Cargo nicht wirklich vorgesehen ist), ist auch schnell geklaert: https://doc.rust-lang.org/cargo/guide/why-cargo-exists.html#why-cargo-exists
1 | Cargo is a tool that allows Rust packages to declare their various |
2 | dependencies and ensure that you’ll always get a repeatable build. |
3 | |
4 | To accomplish this goal, Cargo does four things: |
5 | Introduces two metadata files with various bits of package information. |
6 | |
7 | Fetches and builds your package’s dependencies. |
8 | |
9 | Invokes rustc or another build tool with the correct parameters to |
10 | build your package. |
11 | |
12 | Introduces conventions to make working with Rust packages easier. |
Das wichtige: "ensure that you’ll always get a repeatable build" Das ist etwas, ueber das sich zu wenig leute gedanken machen. Auch ist das ein Thema, das nicht ganz trivial ist (siehe Google oder Debian als Beispiele). DPA schrieb: > Aber crates.io ist der default. Der default, um ein Paket offiziell zu veroeffentlichen, damit das alle mitbekommen (zumindestens die, die auf crates.io gucken). Das ist ja aber nur eine Kopie. Den Code selbst kannst du irgendwo hosten, oder auch einfach nur auf deiner Platte liegen lassen (lokales crates.io oder ganz ohne crates.io). Ein default wie crates.io finde ich aber immernoch besser, als gar nichts wie es bei C/C++ der Fall ist. Da wird was auf Github/Gitlab/etc. hochgeladen, und keiner bekommt es mit. Bei crates.io erscheinen Pakete die neu sind, oder aktualisiert wurden auf der Hauptseite. Dadurch steigt die wahrscheinlichkeit das ein Paket gesehen wird. Ebenso verringert das zusammenspielen von crates.io und Cargo die wahrscheinlichkeit, das fuer neue Projekte veraltete (fehlerhafte) Libs verwendet werden. https://doc.rust-lang.org/book/ch14-02-publishing-to-crates-io.html#removing-versions-from-cratesio-with-cargo-yank
1 | Although you can’t remove previous versions of a crate, you can prevent |
2 | any future projects from adding them as a new dependency. This is useful |
3 | when a crate version is broken for one reason or another. |
4 | In such situations, Cargo supports yanking a crate version. |
5 | |
6 | Yanking a version prevents new projects from starting to depend on |
7 | that version while allowing all existing projects that depend on it |
8 | to continue to download and depend on that version. |
Auch etwas, das es so bei anderen (mir bekannten) Sprachen nicht gibt.
cargo als Paketmanager ist nett für a) Windows-Nutzer, denn da muss der Anwender sowieso irgendwie mit der DLL-Hölle leben b) Entwickler, die sich nur um eine spezifisch gepflegte Zielplattform kümmern müssen (z.B. die speziell für diese Applikation gedachten Cloudserver) Wenn Du aber eine Linux-Distribution pflegen willst, bei der Du jede Lib möglichst nur ein mal zentral vorhalten & gemeinsam aktualisieren können willst, dann macht Dir das cargo das Leben schwerer als nötig. Das zentral Vorhalten und gemeinsam Aktualisieren ist vom Aspekt der Sicherheitspflege ein ganz entscheidender Punkt. Ich als Admin der eine solche Distribution nutzt, kann so ganz einfach prüfen was für einen Stand, Patchlevel,... eine bestimmte Lib hat und es verstecken sich eben nicht noch 20 andere Kopien der selben Lib in unterschiedlichen Versionen als .so oder statisch gelinkt auf der Platte.
Gerd E. schrieb: > Wenn Du aber eine Linux-Distribution pflegen willst, bei der Du jede Lib > möglichst nur ein mal zentral vorhalten & gemeinsam aktualisieren können > willst, dann macht Dir das cargo das Leben schwerer als nötig. Und was hat das jetzt mit cargo zu tun? Man kann mit rust genauso libs bauen wie mit C und C++ (bzw. mit gcc & co.). Und wenn die Lib ueber den distrubitionseigenen Paketmanager verteilt wird (was bei interessanten/wichtigen libs in der regel der fall ist), interessiert cargo ueberhaupt nicht. cargo ist zum entwickeln und bauen von rust programmen und zum managen der abhaengigkeiten (um das programm bauen zu koennen), nicht um die Programme/Libs an den Anwender zu verteilen (es sei denn, du baust alles aus den sourcen, aber dann hast du mit rust und cargo dieselben probleme wie mit anderen Sprachen und Tools auch). cargo ist nichts anderes als das, was pip für python ist. Installierst du über pip irgendwelche Programme die in Python geschrieben sind? Nein? Dann gibt es mit cargo genauso wenig probleme. Du siehst Probleme, wo keine sind.
Kaj schrieb: > Den Code von crates.io kannst du forken und wie das mit den Mirrors geht > steht auch auf der Github Seite von crates.io Ah, ja. Ein "Mirror" nennen sie das. Laut der verlinkten Seite ist das aber so: > This mirror will function as a read-only duplicate of crates.io's API. > You will be able to download crates using your index and your mirror, > but the crate files will still come from crates.io's S3 storage. Vieleicht war das nicht klar genug: > keine Mirrors, und keine simplen Schnittstellen (z.B. rsync) um es > vollständig zu Mirroren Ich verstehe unter einem Mirror etwas, dass alle Daten spiegelt. Ein apt mirror spiegelt alle debian Packete der angegebenen Repos. Ein Mirror der IETF RFCs hat eine Kopie von jedem RFC. Aber von der Beschreibung des cargo "Mirrors" tönt es so, als wäre das höchstens ein Cacheing Proxy, der die Pakete nur zwischenspeichert, die man abfragt, oder eventuell nicht einmal das, und einfach immer nur auf die Daten auf dem selben S3 zugreift. Vieleicht kann man die Daten des S3 irgendwie kopieren? Aber damit hab ich keine Erfahrung. Was auch immer das jetzt tatsächlich ist, ein Mirror ist es nicht. Ohne einen ECHTEN mirror, der eine Kopie aller Daten hält und es im Notfall ersetzen könnte, bleibt es ein Single Point of failure. PS: Das ist nicht das erste mal, das ich "Mirrors" sehe, die gerade die eigentlichen Daten eben nicht alle spiegeln...
:
Bearbeitet durch User
Eine Entscheidung zu einer Programmiersprache ist eigentlich immer "UND" nicht "ODER"
Rust wird bleiben. Genauso wie Kotlin. Aber die Vorgabe, wie ein Projekt strukturiert zu sein hat, und dass man Internetzugang braucht, um die Dependencies runterzuladen, und dass es einen Dienstleister im Internet geben muss, der mir die Daten bereitstellt, das ... stinkt. Rust ist eine Sprache. Wozu muss man eine weltweite Übersicht über jeden bekommen, der diese Sprache spricht oder in ihr jemals etwas niedergeschrieben hat? Das einzige, was man sich damit reinzieht, sind Abhängigkeiten. Ich kann C-Code aus den 80ern aus einem Usenet-Posting fischen, ihn kompilieren und ausführen. Zugegeben: Er stinkt, er ist unsicher, und vielleicht fällt er auch schlicht hin und kotzt er mir auf die Platte. Aber es ist prinzipiell möglich. Wenn ich in 30 Jahren irgendwo Rust-Code finde, dann steht da "führe bitte dieses magische Script aus, welches sämtliche Abhängigkeiten automatisch runterlädt und installiert" (d.h. mir am System pfuscht) an. Die Server gibt es nicht mehr, die Abhängigkeiten gibt es nicht mehr, die Dateien selbst finde ich vielleicht noch irgendwo, aber ich kriege sie ohne weiteres nicht mehr in das Build integriert. Magie lässt sich schlecht debuggen, vor allem, wenn schon lange kein Mana mehr in der Umgebung ist...
Das war mal aber vielleicht. Die Ansprüche dass Code sich auch in 15 der 30 Jahren compilieren lassen muss und dass es auch ohne Internet und Dienstleister gehen muss. Das was viele heuter als starke Abhängigkeit empfinden wird immer mehr zum Standard. Und vielleicht verfällt der Anspruch dass Dinge ewig halten müssen. Technologie wird schnelllebiger. Die Verfallszeit ist aufgrund einer beschleunigten technologischen Entwicklung kürzer geworden. Früher meckerten sehr viele noch dass man auf Plattformen wie Steam unbedingt Internetverbindung benötigt. Ich glaube in Zukunft wird wirklich niemand mehr eine solche Abhängigkeit kritisieren. Es wird einfach absolut selbstverständlich dass man permanent einen Internetzugang hat. Auch wenn Deutschland da nicht glänzen mag. Für viele Länder ist eine flächendeckende breitband Verbindung Alltag geworden. Ich frage mich auch ob die Entwickler die die Hardware von Smartphones entwickeln auch das Bedürfnis haben dass ihr Code 20 Jahre hält. Wenn quasi jährlich ein neues Modell entwickelt werden muss mit neu entwickelter Hardware. Die Apps verlieren jedenfalls nach ein paar Updates des Betriebssystems ihre Kompatibilität. Immerhin ist das auf klassischen Computern nicht so schlimm.
:
Bearbeitet durch User
Atemis H. schrieb: > Das war mal aber vielleicht. Die Ansprüche dass Code sich auch in 15 der > 30 Jahren compilieren lassen muss und dass es auch ohne Internet und > Dienstleister gehen muss. Bei Consumermüll vielleicht. Atemis H. schrieb: > Ich frage mich auch ob die Entwickler die die Hardware von Smartphones > entwickeln auch das Bedürfnis haben dass ihr Code 20 Jahre hält. > Wenn quasi jährlich ein neues Modell entwickelt werden muss mit neu > entwickelter Hardware. > > Die Apps verlieren jedenfalls nach ein paar Updates des Betriebssystems > ihre Kompatibilität. Eben, Consumerkram. In der Industrie muss das Ding auch schon mal 15 Jahre halten, oder zumindest reparierbar sein.
vn n. schrieb: > Bei Consumermüll vielleicht. Der sogenannte Consumermüll ist aber die vorderste Front der High-Tech-Entwicklung. Für Smartphones werden die sparsamsten leistungsfähigsten SoCs entwickelt, fürs Gaming die besten Grafikkarten, für PCs die größten HDDs und CPUs. Die Betriebssysteme aus dem Consumer-Bereich (DOS, Windows) sind schon lange auch im professionellen Umfeld angekommen. ToF-Kameras sind überhaupt nur dank Consumer-Markt erhältlich (Kinect!). Ford hat die Fließbandfertigung für den Consumer-Markt erfunden. Hinsichtlich Bedienbarkeit und Leistung ist Consumer-Software Vorbild für professionelle Software - eine Software von Format "WhatsApp" kann sich nicht leisten, alle 17 Minuten mit "Fehler 97832, bitte Handbuch konsultieren" abzustürzen. Bei Industriesoftware wird das schon eher akzeptiert. vn n. schrieb: > Eben, Consumerkram. In der Industrie muss das Ding auch schon mal 15 > Jahre halten, oder zumindest reparierbar sein. In der Industrie macht man es sich schön einfach und definiert sich einfach lange Lieferbarkeit und benutzt dann ewig alten Kram (antike Schnittstellen, Prozessoren, Programmiersprachen). Im Consumer-Bereich muss man immer mit den neuesten Entwicklungen gehen, der knallharten Konkurrenz voraus sein, neueste Standards beherrschen und eben auch die Hardware aktualisieren. Soviel zu "Müll" - der Consumerbereich ist die echte Welt mit rapidem Fortschritt, während der Industriesektor ein gemütlicher Sandkasten mit realitätsfernen Bedingungen ist.
Was nicht alles gekommen ist um zu bleiben: Pascal Modula Eiffel Occam Fortran Smalltalk Cobol Basic Tcl C C++ Objective C XC C99 AWK Java ... Was bleibt haben nicht die Entwickler entschieden, sondern der "Markt". Fast alle oben genannten Sprachen hab ich mal verwendet oder haben mich sehr interessiert. Und was ist geblieben? C! Die Sprache die ich mal abgründig gehasst habe. Und wieso? Weil ich µC liebe. Und dass es Microchip nach 20 Jahren noch nicht gebacken bekommt iehre Header C99 kompatibel zu bekommen, sagt wer es entscheidet was bleibt. Und dass ich ObjC gerne hätte ist halt ein Traum. Aktuell verwende ich: C (Arbeit + privat) Tcl/Tk (Arbeit + privat), XC (privat) Verilog (privat). Man kann eine Sprache lernen, weils Spass macht und man seinen Horizont erweitert. Wenn man aber Geld damit verienen will, schaut man sich besser an was gefordert wird. **Wird** und nicht **könnte** Gruß, Nick
nickm schrieb: > Wenn man aber Geld damit verienen will, schaut man sich > besser an was gefordert wird. **Wird** und nicht **könnte** Als ich mich im Jahr 2004 selbstständig machte, versuchte ein Bekannter, mich immer wieder dazu zu überreden, ausschließlich auf Smalltalk zu setzen, da er meinte, besonders tolle Eigenschaften festgestellt zu haben und dass es offensichtlich sei, dass Smalltalk kurz vor dem großen Durchbruch stünde. Auf meinen Einwand, dass es damals für Microcontroller exakt keinen Compiler bzw. entsprechendes Laufzeitsystem gab, verwies er auf irgendein akademisches Paper einer Universität, in dem erwähnt wurde, dass die Arbeitsgruppe an einer Smalltalk-Umgebung für Embedded-Anwendungen arbeite. Super. Auf solch eine Ankündigung sollte ich aufbauen, zumal sicherlich viele Low-Level-Funktionen sicherlich nicht ordentlich abgedeckt worden wären.
Dr. Sommer schrieb: > vn n. schrieb: >> Bei Consumermüll vielleicht. > > Der sogenannte Consumermüll ist aber die vorderste Front der > High-Tech-Entwicklung. Für Smartphones werden die sparsamsten > leistungsfähigsten SoCs entwickelt, fürs Gaming die besten Grafikkarten, > für PCs die größten HDDs und CPUs. Die Aussage über SoCs und Smartphones stimmt vermutlich. Aber CPUs, HDDs/SSDs und GPUs für Server sind dann doch noch ne Nummer "besser".
Im Vergleich zu Smalltalk hat sich Rust aber schon eine grössere Community aufgebaut (wird deshalb wohl auch seit Jahren zur beliebtesten Sprache auf Stack Overflow gewählt). Auch im Embedded-Bereich wurde schon einiges gemacht. Falls es jemand interessiert: https://www.rust-lang.org/what/embedded https://github.com/rust-embedded/awesome-embedded-rust https://docs.rust-embedded.org/discovery/ https://docs.rust-embedded.org/book/
gimbo schrieb: > Im Vergleich zu Smalltalk hat sich Rust aber schon eine grössere > Community aufgebaut (wird deshalb wohl auch seit Jahren zur beliebtesten > Sprache auf Stack Overflow gewählt). Eine kurze Suche hat ergeben, dass Smalltalk in den 90er Jahren wohl einen Marktanteil von mehr als 10% bei OOP-Sprachen hatte. Rust hat aktuell weniger als 1%? Die Meinungen auf stackoverflow.com sind genaus wenig repräsentativ für die Allgemeinheit, wie reddit.com oder der "Inhalt" der Bildzeitung.
Laut Benchmark Game ( https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html ) gibt es derzeit nur 3 "schnelle" Sprachen: C, C++ und Rust. Die Produktivität von C ist eher gering. Das Konzept von Rust ist prinzipiell gut: Keine Laufzeitumgebung, keine Garbage Collection, sicher, performant, produktiv. Mal sehen wie sich das entwickelt...
Test schrieb: > Das Konzept von Rust ist > prinzipiell gut: Keine Laufzeitumgebung, keine Garbage Collection, > sicher, performant, produktiv. Mal sehen wie sich das entwickelt... Im Microcontrollerbereich wird der Erfolg von Rust entscheidend davon abhängen, ob Programmgeneratoren wie CubeMX oder Vivado/SDK Peripheriedefinitionen in Rust erzeugen können. Und im Automobilsteuergerätebereich ist ebenfalls wichtig, dass solche Platzhirsche wie z.B. Vector Informatik auch Rust unterstützen.
nickm schrieb: > Fast alle oben genannten Sprachen hab ich mal verwendet oder haben mich > sehr interessiert. Und was ist geblieben? C! Die anderen die du aufgezählt hast sind auch noch alle da, du siehst sie nur nicht mehr weil du nicht mehr hinschaust (aus Zeitmangel wegen C).
nickm schrieb: > Was nicht alles gekommen ist um zu bleiben: > Pascal Sehr verbreitet im SPS-Bereich als SCL bzw. ST (EN 61131-3 bzw. ISO 61131). > Modula > Eiffel Ziemlich tot. > Occam Wurde nur für Transputer geschaffen. > Fortran Als HPF (High Performance FORTRAN) immer noch im Bereich des Number Crunching sehr verbreitet. > Smalltalk Nischenanwendungen > Cobol Im Bankenbereich noch sehr verbreitet. Ein Bekannter ("Mainframe-Urgestein") hat sich vor wenigen Jahren sehr erfolgreich mit Cobol-Entwicklung selbstständig gemacht und kann sich vor Aufträgen kaum retten. Und er bekommt nicht nur Migrationsprojekte von Cobol nach xyz angeboten, sondern echte Weiterentwicklungen von langfristig eingesetzten Programmen. > Basic z.B. Microsoft VBA in jedem Office-Paket > Tcl DER Standard für Skripting und Constraints in sehr vielen FPGA-Entwicklungsumgebungen (Xilinx ISE, Vivado; Intel/Altera Quartus, usw.). > C > C++ Definitiv sehr weit verbreitet. > Objective C App-Entwicklung für Apple iOS. > XC > C99 C-Dialekte. > AWK Auf fast jedem Linux-System in Shell-Skripten versteckt, aber als eigenständige Sprache fast irrelevant. Niemals als Programmiersprache für universelle Anwendungen konzipiert. > Java Sehr verbreitet.
:
Bearbeitet durch User
mh schrieb: > Aber CPUs, HDDs/SSDs und GPUs für Server sind dann doch noch ne Nummer > "besser Aber sind auch nur aufgebohrte Consumer Produkte. Auch auf Servern wird mittlerweile x86 und IBM-PC-Hardware verwendet, was ursprünglich nur die verkappten Lowcost Consumer Produkte waren. Zusammen mit Windows & Co... Echte Server Hardware (z.B. mit Power Architektur) ist eher Nische. Das ganze GPGPU Zeug ist doch auch nur dank Gaming groß geworden, sonst gäbe es die ganzen Grundlagen nicht.
Solange Rust nicht kommerziell Mainstream wird und von den Tool Platzhirschen offiziell unterstützt wird und von gängigen Sicherheitsstandards nicht miteingeschlossen wird, wird Rust den Weg alles Irdischen gehen bzw. ein Nischenprodukt sein, nur von den akademischen und Hobby Enthusiasten am Leben erhalten. Die Mainstream Sprachen lassen sich nur schwer erschüttern. Dafür sorgt schon die Trägheit vieler Firmen und erfahrenene Software Spezialisten. Und was der Bauer nicht kennt, frißt er nicht. Abgesehen davon bevorzugt die Industrie Werkzeuge die sie komplett intern kontrollieren können und nicht extern auf Verderb oder Gedeih vom Geschmack des Monats bestimmt bzw. abhängig sind. Auch müssen uC Belange genauso gut wie bei den existierenden Werkzeugen verläßlich und komplett unterstützt sein. Die Industrie braucht Werkzeuge von denen man weiß wie sie sich verhalten - gut oder schlecht - und die erwarteten Standards einhält. Bis dahin wird noch viel Wasser den Rhein runterfliessen müssen. Meine Prognise ist, daß Rust noch für lange Zeit eine sprichwörtliche Aschenputtel Existenz fristen wird und lange zeit brauchen wird um Real-World Projekte für die Industrie gut genug handhaben zu können. Rust ist ein gut gemeinter Ansatz bekannte Probleme anderer Sprachen zu verbessern, aber der Preis in der Real-World ist noch viel zu hoch. In der Industrie hat man in Stein gemeisselte Vorbehalte und eine gewisse Trägheit und insbesonders ist man Risiko advers. Und Testen kostet viel Geld. Und Ausnahmen bestätigen in diesem Fall nicht die Regel.
Andreas S. schrieb: > Test schrieb: >> Das Konzept von Rust ist >> prinzipiell gut: Keine Laufzeitumgebung, keine Garbage Collection, >> sicher, performant, produktiv. Mal sehen wie sich das entwickelt... > > Im Microcontrollerbereich wird der Erfolg von Rust entscheidend davon > abhängen, ob Programmgeneratoren wie CubeMX oder Vivado/SDK > Peripheriedefinitionen in Rust erzeugen können. Und im > Automobilsteuergerätebereich ist ebenfalls wichtig, dass solche > Platzhirsche wie z.B. Vector Informatik auch Rust unterstützen. Ich finde der Name der Sprache wurde geradezu für den Automobilbereich maßgeschneidert.
Heimlehrgangprogrammierer schrieb: > Meine Prognise ist, daß Rust noch für lange Zeit eine sprichwörtliche > Aschenputtel Existenz fristen wird und lange zeit brauchen wird um > Real-World Projekte für die Industrie gut genug handhaben zu können. Ich habe die Vermutung daß ein eingefleischter C (oder C++) Programmierer der im Laufe der Jahre alle schmutzigen Tricks gesehen hat und der genau weiß wie er was machen muß damit es nicht knallt und der das Problem von race-Conditions mit C-Mitteln löst und mit (meist zutreffenden) Annahmen über das Verhalten seines eigenen Code einfach umschifft als wäre es gar nicht da es unglaublich schwer haben wird wenn er plötzlich mit den extrem restriktiven Compilezeit-Prüfungen und dem Eigentümer und Verleihkonzept in Rust konfrontiert wird, so sehr daß er schnell das Handtuch wefen und sagen wird "das wird mir jetzt aber echt zu blöd, so kann doch kein Mensch vernünftig arbeiten". Wahrscheinlich gehts einfacher wenn man das als erste Sprache lernt, andernfalls muss man praktisch alles (wirklich alles!) vergessen was man jemals gelernt hat, alle liebgewonnenen Konzepte und Designpatterns vergessen und nochmal komplett bei Null anfangen. Das ist extrem schwer.
:
Bearbeitet durch User
Bernd K. schrieb: > Heimlehrgangprogrammierer schrieb: >> Meine Prognise ist, daß Rust noch für lange Zeit eine sprichwörtliche >> Aschenputtel Existenz fristen wird und lange zeit brauchen wird um >> Real-World Projekte für die Industrie gut genug handhaben zu können. > > Ich habe die Vermutung daß ein eingefleischter C (oder C++) > Programmierer der im Laufe der Jahre alle schmutzigen Tricks gesehen hat > und der genau weiß wie er was machen muß damit es nicht knallt und der > das Problem von race-Conditions mit C-Mitteln löst und mit (meist > zutreffenden) Annahmen über das Verhalten seines eigenen Code einfach > aus dem Handgelenk umschifft es unglaublich schwer haben wird wenn er > plötzlich mit den extrem restriktiven Compilezeit-Prüfungen und dem > Eigentümer und Verleihkonzept in Rust konfrontiert wird, so sehr daß er > schnell das Handtuch wefen und sagen wird "das wird mir jetzt aber echt > zu blöd, so kann doch kein Mensch vernünftig arbeiten". > > Wahrscheinlich gehts einfacher wenn man das als erste Sprache lernt, > andernfalls muss man praktisch alles (wirklich alles!) vergessen was man > jemals gelernt hat, alle liebgewonnenen Konzepte und Designpatterns > vergessen und nochmal komplett bei Null anfangen. Das ist extrem schwer. Das Gleiche gilt doch schon für die "eingefleischten C Programmierer" wenn sie mal C++ sehen, das kein C mit Klassen ist. Typsicherheit ist für die ein völlig neues Konzept mit vielen Fehlermeldungen, was dann erstmal mit exzessiven C-Typecasts bekämpft werden muss. Für C++-Entwickler sieht es eher anders aus, natürlich gibt es auch gravierende Unterschiede, aber viele Dinge die man bei C++ heute als idiomatisch bezeichnen würde, sind in Rust Standard. Ist auch kein Wunder, wenn man bedenkt, dass die Sprache von C++-Entwicklern bei Mozilla entstand.
Dr. Sommer schrieb: > mh schrieb: >> Aber CPUs, HDDs/SSDs und GPUs für Server sind dann doch noch ne Nummer >> "besser > > Aber sind auch nur aufgebohrte Consumer Produkte. Auch auf Servern wird > mittlerweile x86 und IBM-PC-Hardware verwendet, was ursprünglich nur die > verkappten Lowcost Consumer Produkte waren. Zusammen mit Windows & Co... > Echte Server Hardware (z.B. mit Power Architektur) ist eher Nische. > Das ganze GPGPU Zeug ist doch auch nur dank Gaming groß geworden, sonst > gäbe es die ganzen Grundlagen nicht. Das ist ne interessante Argumentation, der ich allerdings nicht wirklich zustimmen kann.
Heimlehrgangprogrammierer schrieb: > Solange Rust nicht kommerziell Mainstream wird und von den Tool > Platzhirschen offiziell unterstützt wird und von gängigen > Sicherheitsstandards nicht miteingeschlossen wird, [...] wird es in Bereichen, die diese gängigen Sicherheitsstandards verlangen, nicht eingesetzt werden. Richtig. Heimlehrgangprogrammierer schrieb: > Auch müssen uC Belange genauso gut wie bei den existierenden > Werkzeugen verläßlich und komplett unterstützt sein. Nicht unbedingt. Man kann vieles in Bibliotheken auslagern (z.B. AVR: __flash gilt nur für C, alle anderen müssen PROGMEM nutzen). Absolute Vollständigkeit ist selten relevant (z.B. float auf AVR oder C99/C11 für Visual C++), wichtig ist das passende Subset. Heimlehrgangprogrammierer schrieb: > Und Ausnahmen bestätigen in diesem Fall nicht die Regel. Du meinst, Sprachen wie PHP oder Javascript sind Nischenprodukte? Deine Brille ist auf eine Branche geeicht und da ist das teilweise so. Trotzdem sind das mit die größten Sprachen auf diesem Planeten...
Dr. Sommer schrieb: > vn n. schrieb: >> Bei Consumermüll vielleicht. > > Der sogenannte Consumermüll ist aber die vorderste Front der > High-Tech-Entwicklung. Für Smartphones werden die sparsamsten > leistungsfähigsten SoCs entwickelt, fürs Gaming die besten Grafikkarten, > für PCs die größten HDDs und CPUs. Ist ja auch bitter notwendig, denn Consumersoftware läuft immer schlechter und schlechter und wird immer aufgeblähter. Letztens erst wieder gehört "warum soll ich mich um Effizienz kümmern, hab doch eh 4GB RAM am Raspberry". Und dann wundert man sich, dass in der User Experience nichts zu merken ist von der ständig besser werdenden Hardware. Und nein, dein süßer kleiner Gaming-PC hat sicher nicht die größte CPU oder Festplatte. Die stecken eher in Servern. Dr. Sommer schrieb: > Die Betriebssysteme aus dem > Consumer-Bereich (DOS, Windows) sind schon lange auch im professionellen > Umfeld angekommen. Leider. Managemententscheidungen halt. Windowssysteme, am besten auch noch mit Internetzugang, mitten in Anlagensteuerugen, an denen Menschenleben hängen. Wunderbar, so muss Fortschritt! Dr. Sommer schrieb: > Hinsichtlich Bedienbarkeit und Leistung ist > Consumer-Software Vorbild für professionelle Software - eine Software > von Format "WhatsApp" kann sich nicht leisten, alle 17 Minuten mit > "Fehler 97832, bitte Handbuch konsultieren" abzustürzen. Bei > Industriesoftware wird das schon eher akzeptiert. Spaßvogel! Hast du auch nur einen blassen Schimmer, was Ausfallzeiten in der Indutrie kosten? Bei meinem Arbeitgeber ist das noch harmlos, je nach Kunden werden pro Stillstandstag bis zu 15.000€ Strafzahlung fällig. Belieferst du die Autoindustrie, wirds fünf- bis sechsstellig! Dr. Sommer schrieb: > Im Consumer-Bereich > muss man immer mit den neuesten Entwicklungen gehen, der knallharten > Konkurrenz voraus sein, neueste Standards beherrschen und eben auch die > Hardware aktualisieren. Meine Güte, bist du naiv. Dr. Sommer schrieb: > Soviel zu "Müll" - der Consumerbereich ist die echte Welt mit rapidem > Fortschritt, während der Industriesektor ein gemütlicher Sandkasten mit > realitätsfernen Bedingungen ist. Du solltest vielleicht mal einen kleinen Realitätsabgleich machen.
vn n. schrieb: > Und dann wundert man sich, dass in der User > Experience nichts zu merken ist von der ständig besser werdenden > Hardware. Niemand wundert sich darüber. Das ergibt sich einfach aus den Anforderungen der Kunden, möglichst feature-reiche Softwares möglichst schnell und möglichst billig zu bekommen. Wenn die Kunden bereit wären, für WhatsApp und Konsorten ordentlich zu bezahlen, sähe das schon anders aus. vn n. schrieb: > Und nein, dein süßer kleiner Gaming-PC hat sicher nicht die größte CPU > oder Festplatte. Die stecken eher in Servern. Die aufgebohrte Consumer-Technik sind - x86 war von Anfang an nur für Consumer gemacht, während es gleichzeitig schon viel bessere Server-Prozessoren gab - die jetzt nahezu verdrängt sind. vn n. schrieb: > Belieferst du die Autoindustrie, wirds fünf- bis sechsstellig! Ich kenne diverse Software für die Automobil-Industrie, die öfters zufällig abstürzt. Rat des Herstellers: "Einfach neustarten". vn n. schrieb: > Meine Güte, bist du naiv. Ah, hier kommen die persönlichen Angriffe. Du bist viel naiver als ich!
Dr. Sommer schrieb: > vn n. schrieb: >> Und dann wundert man sich, dass in der User >> Experience nichts zu merken ist von der ständig besser werdenden >> Hardware. > > Niemand wundert sich darüber. Das ergibt sich einfach aus den > Anforderungen der Kunden, möglichst feature-reiche Softwares möglichst > schnell und möglichst billig zu bekommen. Wenn die Kunden bereit wären, > für WhatsApp und Konsorten ordentlich zu bezahlen, sähe das schon anders > aus. Klar, es ist natürlich immer der Kunde schuld. Kennen wir eh schon. So wie bei den Haltebedingungen in der Tierhaltung, das will ja auch der Kunde so. Und nebenbei, auch noch zahlen dafür, dass Facebook via WhatsApp Daten abschnorchelt und meistbietend verkauft? Im übrigen ist es tatsächlich so, dass ein Großteil der Ladezeit und der Rechenleistung bei Webseiten mittlerweile nicht für die Funktion drauf geht, sondern für Werbung und Tracking. Will ja der Kunde so. Und die drölfzig unsicheren JS-Frameworks als Abhängigkeiten, die will auch der Kunde. Dr. Sommer schrieb: > vn n. schrieb: >> Und nein, dein süßer kleiner Gaming-PC hat sicher nicht die größte CPU >> oder Festplatte. Die stecken eher in Servern. > > Die aufgebohrte Consumer-Technik sind - x86 war von Anfang an nur für > Consumer gemacht, während es gleichzeitig schon viel bessere > Server-Prozessoren gab - die jetzt nahezu verdrängt sind. Dass x86 ursprünglich ausschließlich im PC-Bereich verwendet wurde, ändert nix dran, dass Consumer-CPUs nicht gerade das Ende der Fahnenstange markieren. Dr. Sommer schrieb: > vn n. schrieb: >> Belieferst du die Autoindustrie, wirds fünf- bis sechsstellig! > > Ich kenne diverse Software für die Automobil-Industrie, die öfters > zufällig abstürzt. Rat des Herstellers: "Einfach neustarten". Mein Rat: Hersteller wechseln. Ja, ich weiß, das Management und der Support neigt gerne dazu, dem Kunden einzureden, ein Verhalten wie man es von Windows gewöhnt ist, sei normal. Versuchen unsere auch manchmal. Sollte man halt möglichst früh unterbinden, wenn man auch nur ansatzweise Qualitätsanspruch hat. Aber nun würde mich ja doch interessieren, welche Software das denn sein soll. Oder handelt es sich um leere Worte? Dr. Sommer schrieb: > vn n. schrieb: >> Meine Güte, bist du naiv. > > Ah, hier kommen die persönlichen Angriffe. Du bist viel naiver als ich! Keine Angst, das ist kein persönlicher Angriff. Da du scheinbar ernsthaft glaubst, irgendwelche Server-Hardware, Hochleistungs-FPGAs und schnelle DSPs würden im Consumerbereich eingesetzt, während in der Industrie irgendwelche alten Krücken laufen, womöglich noch mit Android und Java, kann man nur von Naivität sprechen. Aber vielleicht verwechselst du auch nur den Umstand, dass so ein Smartphone einen Octacore und 8GB RAM benötigt, um seinen eigentlichen Aufgaben neben Java-Overhead und den dutzenden Werbetrackern in jeder App auch nur leidlich nachzukommen, mit Innovation.
> Die anderen die du aufgezählt hast sind auch noch alle da, du siehst sie > nur nicht mehr weil du nicht mehr hinschaust (aus Zeitmangel wegen C). Treffer. Aber ich bin dennoch nicht verletzt. Einige der Sprachen sind nur noch in Nischen sichtbar. Ja, µC ist auch eine Nische, aber halt meine Nische, das mach ich gerne. Haskell ist wohl auch eine tolle Sprache (auch wenn ich da nur Bahnhof verstehe). Und die hat sich wohl eine Nische in der Telekommunikation erarbeitet. Also wen das Thema interessiert und Haskell spannend findet. Go for it! Aber so Aussagen wie "Rust is must" helfen nicht weiter. Wenn ich glaub, dass das kommt und in dem Bereich der mich interessiert auch verwendet wird. Und auch die Tools dafür zur Verfügung stehen. Ja, dann kann ich mich darum kümmern wenn es mich beruflich weiterbringt. Aber nochmal: Man muss trennen zwischen berufliche Anwendung und persönlichen Interesse. Privat kann ich mich für jeden Mist interessieren und dagegen kann man nicht argumentieren. Und wenn erste Stellenausschreibungen in meinem Bereich mit der Anforderung Rust auftauchen, hab ich immer noch genug Zeit. Gruß, Nick
Nick M. schrieb: > Und wenn erste Stellenausschreibungen in meinem Bereich mit der > Anforderung Rust auftauchen, hab ich immer noch genug Zeit. Solche Stellenausschreibungen findet man mittlerweile zuhauf, und zwar sowohl für ausgewachsene Entwickler als auch Werkstudenten: https://4scotty.com/candidate/position/senior-embedded-developer-fmx-ZkSystems-GmbH-in-Berlin-8455 https://portal.hgi.rub.de/uploads/files/1114_1_1199_tNYUrDjXxFCc2DqLmoql_36291-Praktikum-Embedded-Software-Development-mit-Rust.pdf
Beim ersten Link hab ich nur "Blockchain" gelesen und dann war das Fenster schon wieder zu. :-)) Nick
Gibt es data sheets von uControllern, wo die Programmierung anhand von Rust (und nicht mit C/Assembler) erklärt wird? Eben. Oder muss man Assembler/C lernen nur um irgendwelche programming manuals zu verstehen und später ein Projekt doch mit Rust umsetzen? Weil das viel sicherer ist? Und so modern. Das ist absurd. PS: Normalerweise sind alle Infos (data sheets, etc.) auch auf Englisch. Was machen die Profis? Sie schreiben Kommentare, Funktions-/Variablennamen auch auf English. Oder übersetzt ihr alles? (a la #define UND && etc.)
TriHexagon schrieb: > Das Gleiche gilt doch schon für die "eingefleischten C Programmierer" > wenn sie mal C++ sehen Das ist was völlig anderes, bei C++ können sie im Wesentlichen weiterhin alles genau so machen wie bisher in C und der Unterschied ist nur daß sie dann noch 42 zusätzliche Sachen obendrein auch noch machen können wenn sie wollen und die neuen Konzepte ganz sachte Stück für Stück lernen und schrittweise umstellen, der Frustfaktor ist relativ gering. Bei Rust kannst Du praktisch absolut nichts mehr auf die althergebrachte Weise machen, musst alles vergessen und komplett neu und anders lernen. Ähnlich schmerzhaft wie wenn man versucht vom ner imperativen Sprache auf Haskell umzusteigen. Vielleicht nicht ganz so extrem aber vergleichbar.
:
Bearbeitet durch User
zitter_ned_aso schrieb: > PS: Normalerweise sind alle Infos (data sheets, etc.) auch auf Englisch. Nein, nur ein winziger Bruchteil aller Datenblätter ist in englischer Sprache geschrieben. Wir befinden uns nämlich auch nur in einer "Filterblase" und sehe daher nur sehr selten chinesische Datenblätter. Ich wurde schon mehrmals damit konfrontiert, mit anhand rein chinesischer Dokumentation meinen Teil zusammenreimen zu müssen. Warum sollte auch ein Chinese, der (fast) kein Wort Englisch kann, sich die Mühe machen, ein Datenblatt in einer Sprache zu schreiben, die nur wenig Bedeutung in dem Zielmarkt des Produkts hat? Insbesondere Bauteile für den "Consumerschrott" werden zum allergrößten Teil in China verarbeitet. Die 3% an Stückzahlen, die direkt an europäische Gerätehersteller geliefert werden, rechtfertigen nicht unbedingt den Aufwand, dafür Datenblätter in einer völlig fremden Sprache wie Englisch zu verfassen. Mir ist allerdings nicht bekannt, ob Programmiersprachen, deren Schlüsselwörter komplett in einer asiatischen Sprache formuliert sind und ggf. auch auf einem asiatischen Zeichensatz basieren, derzeit halbwegs relevant sind. Dass es z.B. unter japanischem MS Windows auch BAT/CMD-Skripte mit japanischem Zeichensatz gibt oder zumindest mal gab, konnte ich vor etlichen Jahren selbst erleben. Damals wollte ich ein bestimmtes Programm auf dem Schlepptop eines japanischen Gastes installieren, was mir aber aus besagtem Grund nicht gelang. Seine Englischkenntnisse waren aber auch nicht so gut, dass er selbst die Programmdokumentation vollständig verstehen konnte. Wir gingen aber sehr stark davon aus, dass das Programm wohl deswegen nicht funktionierte, weil es eben mit dem japanischen Zeichensatz nicht zurechtkam. Deine obige Aussage bedeutet also nur, dass Du völlig den Bezug zur heutigen(!) Realität verloren hast, d.h. das was nicht sein soll, darf auch nicht sein.
Andreas S. schrieb: > Deine obige Aussage bedeutet also nur, dass Du völlig den Bezug zur > heutigen(!) Realität verloren hast nö. Was China angeht, habe ich die Gefahr längst erkannt und begrüße daher die Politik von Trump. Er macht alles richtig. Deutschland verkauft dagegen alles an die Chinesen. Und ihre Datenblätter könnnen die auch für sich behalten. Ja, die Asiaten haben ihre eigene Welt. Das war auch in der Sowjetunion so. Und? Was hat das mit Rust zu tun? Nichts. Die Programmierbeispiele in Manuals werden in Assemlber / C /(meinetwegen) C++ geschrieben. Ich muss also diese Programmiersprachen lernen um die Manuals überhaupt verstehen zu können und dann meinen Code aber in Rust schreiben? Wie absurd ist das denn.
Andreas S. schrieb: > Dass es z.B. unter japanischem MS Windows auch > BAT/CMD-Skripte mit japanischem Zeichensatz gibt oder zumindest mal gab, > konnte ich vor etlichen Jahren selbst erleben. Es gab mal ne Zeit da hat Microsoft in seinen Officprodukten die Funktionsnamen in die jeweilige Landessprache übersetzt und WIMRE war das Programmieren von Makros aus diesen oder einem damit eng zusammenhängenden Grund die absolute Hölle. Ist aber schon 20 Jahre her, kann sein daß die Erinnerung über die vielen Jahre hinweg dramatischer geworden ist. > Damals wollte ich ein > bestimmtes Programm auf dem Schlepptop eines japanischen Gastes > installieren, was mir aber aus besagtem Grund nicht gelang. Dann hat der Entwickler Mist gebaut. Hab ich selber auch schon geschafft, zum Beispiel in nem Python-Programm Text auf der stdout ausgeben wollen (nicht mit print sondern direkt mit write) und stillschweigend davon ausgehen daß die Konsole zufällig die selbe Kodierung hat wie bei einem zuhause. RTFM hätte geholfen denn das Verhalten ist dokumentiert und Empfehlungen existieren, ausreichend Erfahrung hätte ebenfalls geholfen, aber wenn man jung und ungeduldig ist... -- GigaDevice liefert Quelltexte für seine Demo-Boards und in der Demo für das Display sind literale strings enthalten. Die ganze C-Datei ist in einem chinesischen Zeichensatz kodiert (nicht in UTF-8 wie das jeder andere normale Mensch machen würde) und wenn man das dann mal durch den Compiler jagen will meckert der weil die Stringliterale die falsche Länge haben. Dann muss man erstmal ausprobieren(!) welcher von den dutzend verschiedenen chinesischen Windows-Zeichensätzen das wohl sein könnte. Das wird natürlich auch nirgendwo mit einem Wort erwähnt oder überhaupt nicht erst als Problem zur Kenntnis genommen denn in China(!) hat ja anscheinend noch kein Mensch je was von der Existenz unterschiedlicher Zeichensätze gehört. Noch nicht mal die Programmierer! Es wird so viel geschlampt und gepfuscht überall das geht echt auf keine Kuhhaut mehr.
:
Bearbeitet durch User
Bernd K. schrieb: > Es gab mal ne Zeit da hat Microsoft in seinen Officprodukten die > Funktionsnamen in die jeweilige Landessprache übersetzt und WIMRE war > das Programmieren von Makros aus diesen oder einem damit eng > zusammenhängenden Grund die absolute Hölle. Ist aber schon 20 Jahre her, > kann sein daß die Erinnerung über die vielen Jahre hinweg dramatischer > geworden ist. Ja, so war das bei MS Office. Es gab auch anfangs wohl weder eine automatische Übersetzung in die jeweilige Landessprache noch Englisch als Rückfallsprache. Glücklicherweise nutzte ich zu der Zeit Star Office und LaTeX. Es gibt aber auch noch eine Steigerung: ein Bekannter arbeitete als Systemadministrator, überwiegend mit AIX-Maschinen. Irgendwann konnte niemand mehr auf dem Postscript-Netzwerkdrucker drucken. Die Druckjobs trafen zwar bei dem Drucker ein, produzierten der aber nur Fehlermeldungen. Es stellte sich heraus, dass auf dem Rechner, auf dem der Druckerspooler lief, nach einem AIX-Update die deutsche Lokalisierung aktiviert wurde. Hierdurch wurden auch die im deutschen und amerikanischen Kulturkreis gegensätzlichen Dezimalpunkte und -kommata vertauscht, d.h. der Spooler griff in die Druckjobs ein und erzeugte "Postscript mit deutschen Zahlen". > Dann hat der Entwickler Mist gebaut. Ja, das ganze Programmpaket (Telelogic Tau SDL) war ziemlich fehlerhaft. > GigaDevice liefert Quelltexte für seine Demo-Boards und in der Demo für > das Display sind literale strings enthalten. Die ganze C-Datei ist in > einem chinesischen Zeichensatz kodiert (nicht in UTF-8 wie das jeder > andere normale Mensch machen würde) und wenn man das dann mal durch den > Compiler jagen will meckert der weil die Stringliterale die falsche > Länge haben. Dann muss man erstmal ausprobieren(!) welcher von den > dutzend verschiedenen chinesischen Windows-Zeichensätzen das wohl sein > könnte. Damals(tm) bearbeiteten zwei sehr unerfahrene Kollegen ihre C-Quelltexte mit MS Wordpad statt mit einem Texteditor und wunderten sich dann über komische Fehlermeldungen des Compilers. Das war eigentlich nicht schlimm, aber beide erwiesen sich als ziemlich beratungsresistent und verstanden nicht, dass der von Wordpad dargestellte Inhalt eben nicht identisch mit dem Dateiinhalt war. Die beiden fanden es sogar eine gute Idee, die Quelltexte mit den Mittels von Workpad aufzuhübschen, d.h. verschiedene Fonts, Fettschrift usw. zu verwenden, also Syntaxhighlighting für Arme zu betreiben. Und wenn dann solch ein "hübscher" Quelltext einfach eingecheckt wird, ohne ihn vorher selbst erfolgreich kompiliert zu haben, verlagert man die Fehlersuche auf die Kollegen und kann sich anschließend auch noch darüber beschweren, dass die Kollegen die hübsche Formatierung wieder entfernt hätten. > Das wird natürlich auch nirgendwo mit einem Wort erwähnt oder überhaupt > nicht erst als Problem zur Kenntnis genommen denn in China(!) hat ja > anscheinend noch kein Mensch je was von der Existenz unterschiedlicher > Zeichensätze gehört. Noch nicht mal die Programmierer! Damals(tm) hatte ich ein Entwicklungsboard zu einem NEC (mittlerweile Renesas) V850. Bei dem beigefügten GCC waren leider alle Meldungen bunt eingefärbt, so dass man zum einen gleich Augenkrebs bekam und zum anderen die Meldungen ein Editor o.ä. mit den Meldungen nichts mehr anfangen konnte. > Es wird so viel geschlampt und gepfuscht überall das geht echt auf keine > Kuhhaut mehr. Oh ja, und machten Leute machen das nicht etwa auf Grund von Flüchtigkeitsfehlern, sondern weil sie meinen, der Software eine individuelle Note geben zu müssen, und dabei nicht beachten, dass der Scheiß unbenutzbar oder gar fehlerhaft wird. Andererseit mag ich solche Entwickler, weil sie mir Aufträge sichern.
Andreas S. schrieb: > Es stellte sich heraus, dass auf dem Rechner, auf dem der Druckerspooler > lief, nach einem AIX-Update die deutsche Lokalisierung aktiviert wurde. > Hierdurch wurden auch die im deutschen und amerikanischen Kulturkreis > gegensätzlichen Dezimalpunkte und -kommata vertauscht, d.h. der Spooler > griff in die Druckjobs ein und erzeugte "Postscript mit deutschen > Zahlen". Selbst der C-Compiler war damals wohl davon betroffen. Da hatte man offenbar im Rundumschlag überall “setlocale(LC_ALL, "");” eingefügt ohne drüber nachzudenken, ob das nun für jedes Dienstprogramm so passend ist. Ist aber schon eine gaaanze Weile her, war zu Beginn der Zeit, wo die Geschichte mit den locales aufkam. Gewissermaßen haben sie damals bei AIX Lehrgeld für alle bezahlt.
S. R. schrieb: > Ich kann C-Code aus den 80ern aus einem Usenet-Posting fischen, ihn > kompilieren und ausführen. Zugegeben: Er stinkt, er ist unsicher, und > vielleicht fällt er auch schlicht hin und kotzt er mir auf die Platte. > Aber es ist prinzipiell möglich. Er könnte aber eine Lib Voraussetzen, die früher mal auf einer Mailbox vertrieben wurde und nun nicht mehr auffindbar ist. Wenn bei Rust crates.io noch vorhanden ist, wirst du die Lib noch finden. Insofern sieht's bei C und C++ bezüglich Abhängigkeiten nicht wirklich besser aus. Der Eindruck täuscht lediglich, wenn es nicht sogar schlimmer ist, da die Wahrscheinlichkeit, dass wenig benutzte Quellen viel größer ist, als eine zentrale Anlaufstelle.
also wenn Du Pascal Code aus dem Netz fischt aus den 80ern..und unter Freepascal kompilierst..geht das auch? Also das Beispiel ist nichtssagend
Nano schrieb: > Insofern sieht's bei C und C++ bezüglich Abhängigkeiten nicht wirklich > besser aus. Der Eindruck täuscht lediglich, wenn es nicht sogar > schlimmer ist, da die Wahrscheinlichkeit, dass wenig benutzte Quellen > viel größer ist, als eine zentrale Anlaufstelle. Das seh ich auch so. Dazu kommt das crates meines Wissens nach lediglich als sowas wie "deprecated" markiert werden können, vom Ersteller selbst aber nicht direkt gelöscht. Hat man in seinem C/C++ Projekt Abhängigkeiten zu einer alten Library auf irgendeinem Git-Repo deren Entwicklung eingeschlafen ist, dann ist man gut damit beraten diese lieber zu forken...
Nano schrieb: > Er könnte aber eine Lib Voraussetzen, die früher mal auf einer > Mailbox vertrieben wurde und nun nicht mehr auffindbar ist. Abgesehen davon, dass das äußerst unwahrscheinlich ist... wenn die Mailbox nicht mehr existiert, dann ist das ein Problem. Nano schrieb: > Wenn bei Rust crates.io noch vorhanden ist, > wirst du die Lib noch finden. Das setzt voraus, dass crates.io noch existiert, die alten Versionen noch vorrätig hält und kompatibel funktioniert. Gibt genug Webseiten und Dienste, die aus verschiedensten Gründen wieder verschwunden sind. Ich sehe da keinen Unterschied. Wenn der zugrundeliegende Dienst stirbt, hab ich ein Problem - aber wenn ich auf den Dienst angewiesen bin, ein wesentlich größeres. Gegeg J. schrieb: > also wenn Du Pascal Code aus dem Netz fischt aus den 80ern.. > und unter Freepascal kompilierst..geht das auch? Pascal hatte nie einen gebrauchbaren Sprachstandard. Daher ist Pascal-Code immer an den entsprechenden Compiler gebunden. Wenn Freepascal zufällig kompatibel zu deinem nicht näher genannten "Pascal Code" ist... ja? Davon abgesehen ändert das am Abhängigkeitsmanagement nichts.
Bei den meisten C/C++/etc. Sprachen haben die meisten Programme nur ein paar wenige Abhängigkeiten, nur die grösseren Programme haben etwas mehr. Man muss diese dann ja von irgendwo her holen, und wenn da kein Script dabei ist, dass das macht, muss man die erst mal selbst installieren. Zudem will man ja in der Regel die Version der Library, die schon in der Distro ist verwenden, sofern möglich. Deshalb ist es hier aufwendiger, Abhängigkeiten zu nutzen. Bei rust mit cargo sieht es aber vermutlich genauso aus wie bei nodejs mit npm. Dependencies können einfach so rekursiv geholt werden. Zieht euch mal eine beliebige nodejs Seite von GitHub runter, ein npm install und schon hat man hunderte bis tausende Pakete heruntergeladen. Ein Packet das man will einfach in die Liste schreiben, das ist zu einfach. Die Leute denken dann gar nicht mehr nach, ob sie X brauchen. Bei cargo ist es vermutlich noch nicht ganz so schlimm wie bei npm, aber ich garantiere euch, besser wird es mit der Zeit sicher nicht. Ich meine, wenn man das komplette crates.io, also alle Pakete, nicht nur die Metadaten mirroren könnte, ginge das ja eventuell noch. Obwohl, bei der Datenmenge, wäre das vielleicht so oder so für die meisten nicht mehr möglich. Aber zu glauben, dass crates.io nicht eines Tages stirbt, halte ich für eine Illusion. Jeder webservice verschwindet irgend wann mal, auf die eine oder andere weise. Und wenn das Ding dann mal weg ist, dann bricht die Hölle los, dann ist nicht nur ein obskures Programm betroffen, sondern so ziemlich jedes. Und jetzt nochmal kurz zurück zu Libraries aus den Paketquellen von Distros. Es gibt wohl rust und cargo basierte Pakete in z.B. Debian, es ist möglich. Traditionell sollte, zumindest in Debian, jedes Paket einen Maintainer haben, der es up-to-date hält. Wichtiger aber, es gibt Richtlinien, was in die Repos der Distro darf, und was nicht. Altes wird eventuell auch mal wieder aufgeräumt (entfernt). Bei Programmen, die PIP, NPM, Cargo, etc. nutzen, werden viele Entwickler sich nur darum kümmern, was in den default Repos der Tools ist. Ob die 1000+ Dependencies, die da dahinter hängen, auch in Distro X ist, wird denen egal sein. Für Paketmaintainer wird das die Arbeit massiv erschweren. Deshalb werden viele der Programme nicht in die Distro Repos gepackt werden, weil zu aufwendig. Diese werden die Nutzer dann halt selbst über die tools und deren Repos installieren. Die Software in den Repos dieser Tools nicht den gleichen Grad der Kontrolle, wie z.B. die Debian Repos, da jeder einfach so zeug hochladen kann, ohne dass da noch andere drüber schauen. Dies erhöht das Risiko von Adware und software supply chain attacks massiv. Ähnlich wie bei z.B. Flatpack und vergleichbaren Technologien verlieren die Distributoren so nach und nach die Kontrolle über die Software, die sie brauchen. Die Softwarepolitik der Distributionen, die Qualitätsstandards, die diese an die Software in ihren Repos stellen, verlieren nach und nach an Bedeutung, was ich für eine durchaus gefährliche Entwicklung halte.
S. R. schrieb: > Pascal hatte nie einen gebrauchbaren Sprachstandard. der immer gleiche Quatsch..er wird nicht wahrer wenn man ihn gebetsmühlenartig wiederholt. Der Standard nennt sich Borland Pascal, an dem Orientiert sich jeder ernstzunehmende Pascal clon.
S. R. schrieb: > Ich sehe da keinen Unterschied. Wenn der zugrundeliegende Dienst stirbt, > hab ich ein Problem - aber wenn ich auf den Dienst angewiesen bin, ein > wesentlich größeres. Du kannst auch Backups von den 3rd Party Sachen machen, die du für dein Projekt brauchst. Das würde ich ohnehin tun. Denn Vertrauen ist gut, Kontrolle ist besser.
Gegeg J. schrieb: > S. R. schrieb: >> Pascal hatte nie einen gebrauchbaren Sprachstandard. > > der immer gleiche Quatsch..er wird nicht wahrer wenn man ihn > gebetsmühlenartig wiederholt. > Der Standard nennt sich Borland Pascal, an dem Orientiert sich jeder > ernstzunehmende Pascal clon. Die Wörter Klon und orientieren hören sich nicht sehr vertrauenserweckend an. Wo kann man die Sprachregeln nachlesen?
> Der Standard nennt sich Borland Pascal,
Nein, das war das Pascal von N. Wirth.
Nein, UCSD-Pascal
Nein, SunValley Pascal.
Nein, Microsoft-Pascal!
Nick
Gegeg J. schrieb: > Der Standard nennt sich Borland Pascal, an dem Orientiert sich jeder > ernstzunehmende Pascal clon. Das tun nur Jungspunde. VAX Pascal war fast so verbreitet wie VAX FORTRAN. Und Borland Pascal hieß zum Zeitpunkt seiner größten Verbreitung noch Turbo Pascal.
:
Bearbeitet durch User
Turbo Pascal hieß immer Turbo Pascal und war von Borland...und Borland hatte Pascal überhaupt erst erfolgreich gemacht. Davor war Pascal kaum zu gebrauchen udn wie so oft vorgekaut..eher eine reine Lehrsprache. https://de.wikipedia.org/wiki/Turbo_Pascal oder https://www.bernd-leitenberger.de/turbo-pascal-history.shtml "Ohne Turbo Pascal hätte die Sprache Pascal sicher das gleiche Schicksal ereilt wie viele an Universitäten vorher und nachher geborene „Kunstsprachen“, z. B. Modula-2 oder Oberon (beide auch von Niklaus Wirth), die heute praktisch verschwunden sind"
Gegeg J. schrieb: > Turbo Pascal hieß immer Turbo Pascal und war von Borland... Falsch. Turbo Pascal hieß vorher Compass Pascal Compiler und davor Blue Label Software Pascal Compiler. > und Borland hatte Pascal überhaupt erst erfolgreich gemacht. Auch falsch. Borland hat Pascal auf IBM-kompatiblen PCs mit PC-DOS/MS-DOS erfolgreich gemacht. Zuvor war UCSD Pascal ausgesprochen erfolgreich auf Apple II usw.. Und auf Mehrbenutzersystemen wurden viele Anwendungen von Algol nach Pascal portiert, da es ähnlicher als Cobol oder FORTRAN war. > Davor war Pascal kaum zu gebrauchen udn wie so oft vorgekaut..eher eine > reine Lehrsprache. Falsch, siehe oben. > https://de.wikipedia.org/wiki/Turbo_Pascal > oder > https://www.bernd-leitenberger.de/turbo-pascal-history.shtml Dort wird die Historie von Turbo Pascal beschrieben, nicht von Pascal auf anderen Plattformen. > "Ohne Turbo Pascal hätte die Sprache Pascal sicher das gleiche Schicksal > ereilt wie viele an Universitäten vorher und nachher geborene > „Kunstsprachen“, z. B. Modula-2 oder Oberon (beide auch von Niklaus > Wirth), die heute praktisch verschwunden sind" Das ist durchaus zutreffend, aber betrifft erst die jüngere Geschichte, d.h. ab Ende der 1980er Jahre. Auf UNIXoiden Betriebssystemen konnte sich Pascal nicht durchsetzen, da dort häufig schon ein C-Compiler mitgeliefert wurde, und unter MS Windows war C angesagt. Die Tatsache, dass Pascal heutzutage außer im SPS-Bereich kaum noch anzutreffen ist, bedeutet nicht, dass es früher in anderen Bereichen sehr erfolgreich war. Die Namen Modula-2, Oberon, Eiffel und Konsorten kennen zwar viele Leute, aber diese Sprachen konnten sich nun wirklich nicht groß durchsetzen. Und dann gibt es natürlich noch die Unmengen an Programmiersprachen, die so erfolglos waren, dass sogar das Internet sie teilweise schon vergessen hat, wie z.B. Fungol.
Gegeg J. schrieb: > S. R. schrieb: >> Pascal hatte nie einen gebrauchbaren Sprachstandard. > > der immer gleiche Quatsch..er wird nicht wahrer wenn man ihn > gebetsmühlenartig wiederholt. > Der Standard nennt sich Borland Pascal, an dem Orientiert sich jeder > ernstzunehmende Pascal clon. Nö, der Standard nennt sich ISO 7185:1990 https://rti.etf.bg.ac.rs/rti/ir1p1/materijali/iso7185.pdf und ISO/IEC 10206:1991 http://web.eah-jena.de/~kleine/history/languages/iso-iec-10206-1990-ExtendedPascal.pdf Das es davon kaum eine vollständige Umsetzung gibt ist eine ganz anderes Thema...
Ich vermute, die Rede ist von µC? Weil für neue PC-Projekte nutzt man C ja eher selten. Ich sehe da folgendes Problem: Die Hersteller müssten dann in ihren IDEs Rust anbieten. Die Hersteller müssten Peripherie-Code (wie Cube-MX) so liefern, dass man ihn mit Rust einfach nutzen kann. Viele populäre Projekte sind außerdem in C++ oder C geschrieben (wie FATFs oder FreeRTOS - Dinge, die man nicht ohne Not selber schreiben will). Heute schreiben die meisten Leute ihren Peripherie-Code (Beispiel: USB, Ethernet) nicht mehr selber. Viele nutzen entweder die IDEs der Hersteller oder Dinge wie Keil oder IAR. Und einige Dinge wie das RTOS oder FATFs oder eine echte GUI würde man vermutlich nicht selber schreiben wollen. Viele Leute werden nicht mehrere Programmiersprachen in einem Projekt nutzen wollen, insbesondere wenn die IDEs die zweite (noch) nicht anbiegen. Damit sich das im Mainstream durchsetzt, müsste sich da also noch einiges tun. Hinweis: Ich beziehe mich ausschließlich auf den µC-Sektor!
Neben dem eigentlichen Programmieren in einer oder mehreren Programmiersprachen muss man auch das Debugging im Auge behalten, insbesondere wenn dies auf Hochsprachenebene geschehen soll. Und an der Stelle unterstützten die allermeisten Debugger derzeit nur C und C++, in wenigen Fällen auch das Debuggen von Java Bytecode. Natürlich kann man sich hinstellen und behaupten, dass in Rust viele Fehler vermieden würden, für die man bei klassischer C-Programmierung den Low-Level-Debugger herausholen muss. Dies ist sicherlich auch korrekt. Im Microcontrollerbereich gibt es aber auch noch die Unmengen an Hardwareabhängigkeiten und solche Themen wie Heap- und Stack-Kollisionen. So gerne ich auch auf Rust umstellen würde, so sehr sehe ich da noch ein paar Hindernisse.
Andreas S. schrieb: > unterstützten die allermeisten Debugger derzeit nur C und C++, in > wenigen Fällen auch das Debuggen von Java Bytecode. Es gibt keinen Debugger für Rust? Das mag ich kaum glauben.
Bernd K. schrieb: > Andreas S. schrieb: >> unterstützten die allermeisten Debugger derzeit nur C und C++, in >> wenigen Fällen auch das Debuggen von Java Bytecode. > > Es gibt keinen Debugger für Rust? Das mag ich kaum glauben. Kannst Du nicht lesen oder mangelt es Dir am Textverständnis? Die Aussage "die allermeisten Debugger" ist keinesfalls identisch mit "alle Debugger".
Andreas S. schrieb: > Die Aussage "die allermeisten Debugger" ist keinesfalls identisch mit > "alle Debugger". Was soll man mit den "allermeisten" Debuggern? Für jede Sprache nimmt man natürlich immer den geeigneten Debugger, für C oder C++ genauso, da geh ich auch nicht mit nem Java-Debugger dran und auch nicht einem Debugger für Go oder einem für C# oder einem für Python.
:
Bearbeitet durch User
Kaj schrieb: > Das wichtige: "ensure that you’ll always get a repeatable build" > > Das ist etwas, ueber das sich zu wenig leute gedanken machen. Auch ist > das ein Thema, das nicht ganz trivial ist (siehe Google oder Debian als > Beispiele). Zu unrepeatable builds kann ich ein ganzes Buch schreiben... Bei uns in der Firma wurden letztes und vorletztes Jahr einige Produkte mit STM32 Prozessor von SPL auf libopencm3 umgestellt. Diesen Januar hat uns der Mitarbeiter verlassen und kurz darauf kamen schon die ersten Probleme: 1) Sein Rechner mit Build-Umgebung wurde platt gemacht, nachdem er ausschied. Keines der libopencm3-Projekte compiliert auf einem debian-system mit dem offiziellen gcc von arm. Das Mitschleppen von veralteten, fertig installierten, Systemen ist allein schon aus Datenschutz- und Sicherheitsgründen keine Option. Wir können nicht für jedes Produkt eine Build-Farm unterhalten. 2) Nachdem dann neue Projekt-Templates angelegt wurden, welche nur die libopencm3 enthielten und die Code-Dateien unserer Software reinkopiert wurden, ging das (ab und zu) auch mal. 3) ca. 6 Monate später gab es mehrere Updates der libopencm3 und gcc. Nachdem die installiert wurden, waren stellenweise die Projekte wieder "broken". 4) Ich bin mir nicht 100%ig sicher, da ich selbst darüber nicht gestolpert bin, aber ich meine bei libopencm3 gab es API-Änderungen, sodass wieder Dinge broken waren. 5) Der Kollege wurde auch zu Rate gezogen, da kamen dann Sätze wie "du musst nur..." und "... man muss nur dort und dort das und das tun...." - typisches OS-Gefrickel-Gelaber. Als ich dort angefangen habe, war ein anderer Kollege dort am Hebel und der liess für jedes Projekt eine VM anlegen auf unserem Terminal-Server. Dorthin verband man sich vom Arbeitsplatz aus und hat dann 5 Jahre später immernoch die Möglichkeit kleine Änderungen schnell vorzunehmen. Die Unsitte, die ich bei libopencm3 überall sehe, die library mit git einzubinden in den Projektordner und erstmal runterladen zu müssen bei Bedarf kann ich auch nicht verstehen. Wenn ein Projekt fertig ist oder einen gewissen Stand erreicht hat, dann speichert man das so inkl aller Abhängigkeiten ab. Im schlimmsten Fall ist die library nicht mehr verfügbar und man kann alles neu machen. Ich will nicht wissen, wie gross das Geheule ist, wenn plötzlich und auf einen Schlag ein Anbieter wie github die Pforten schliesst. Wieviele Projekte dann unter Datenverlust leiden, ... Vor ein paar Wochen wurde bei einem Brand beim Kunden einiges zerstört. Der rief an und unser Chef sagte direkt ein paar "Extras" zu, was die neu zu liefernde Hardware/Software können wird. (BMS für Notstromsysteme - ein paar Schönheitskorrekturen in der Bedienung/Überwachung). Daran habe ich 9 volle AT geknabbert - dank libopencm3 und broken builds. Mich soll's nicht stören, ich werde dafür bezahlt. Mein Chef aber nicht. Da war er etwas zu voreilig.
Und bei dem ganzen abgekotze, habe ich direkt den Grund für das Ganze vergessen: Besagter, ausgeschiedener Kollege, hat das angeleiert. In Zusammenarbeit mit einer Hochschule etwas für die Open-Source Gemeinde zu tun. Alles was bisher passiert ist, war Fehlersuche/Flicken und die Kunden bekamen Quelltexte mit ihren Produkten. Kein Student, keine Öffentlichkeit hat bisher was davon gesehen...
Warum erbrichst du deinen Frust in einen Thread über die Sprache Rust, obwohl euer Mismanagement damit rein gar nichts zu tun hat? Mismanagement kann man in jeder beliebigen Sprache und jeder beliebigen Umgebung implementieren.
Ich wollte damit ein Beispiel für nicht wiederholbare Builds geben. Wenn dich das stört, tut's mir leid.
Bibo schrieb: > Ich wollte damit ein Beispiel für nicht wiederholbare Builds geben. > Wenn dich das stört, tut's mir leid. Das von Dir aufgezeigte Beispiel ist ein hervorragendes Beispiel für Pfusch auf Eurer Seite. Wenn man von solchen externen Komponenten abhängig ist, zieht man diese während des Build natürlich nicht von Github und Konsorten, sondern von einem eigenen Mirror solche Repositories. Solche Mirrors haben natürlich mindestens den gleichen Lebenszyklus wie die darauf basierenden Projekte/Produkte, d.h. sie müssen ebenfalls der Datensicherung unterworfen sein. Solange die externen Repositories aktiv sind, kann man die lokalen Mirrors auch wunderbar per cron-Job o.ä. synchronisieren. Anhand der dabei generierten Logs sieht man auch wunderbar, ob bzw. was sich auf den Upstream-Repositories tut. Der Erfolg von verteilten Versionskontrollsystemen wie z.B. Git basiert eben darauf, dass man nicht nur Sandboxes auschecken, sondern Repositories munter klonen kann. Und wenn Ihr nicht die entsprechenden Vorkehrungen trefft, wenn ein "Jungspund" mit externen Repositories arbeiten will, ist das Euer Organisationsversagen.
Bibo schrieb: > Und bei dem ganzen abgekotze, habe ich direkt den Grund für das Ganze > vergessen: > > Besagter, ausgeschiedener Kollege, hat das angeleiert. In Zusammenarbeit > mit einer Hochschule etwas für die Open-Source Gemeinde zu tun. > > Alles was bisher passiert ist, war Fehlersuche/Flicken und die Kunden > bekamen Quelltexte mit ihren Produkten. > Kein Student, keine Öffentlichkeit hat bisher was davon gesehen... Vor lauter abgekotze hast du ganz vergessen, dass das Problem bei euch nicht Open Source ist, sondern euer komplett kaputter Buildprozess. Projekte, die nur lokal kompiliert werden, sind in einem professionellen Umfeld ein absolutes No-Go. Lokal wird zur Entwicklung kompiliert, dann wird in die Versionskontrolle eingecheckt und der Buildserver braut ein reproduzierbares Image. Natürlich hat der auch die Anhängigkeiten vorliegen. Bibo schrieb: > Ich wollte damit ein Beispiel für nicht wiederholbare Builds geben. Vielleicht solltest du besser mal anfangen, den Grund für den nicht reproduzierbaren Build an der richtigen Stelle zu suchen. Aber das tust du nicht, denn: Bibo schrieb: > Mich soll's nicht stören, ich werde dafür bezahlt.
@Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) leider sind alle deine Kommentare falsch, aber ich will die Diskussion jetzt hier nicht ausufern lassen.. Turbo Pascal hieß IMMER Turbo Pascal Die von dir genannten Pascal Sprachen, haben nicht viel mit TUrbo von Borland zu tun..und ich sagte auch, das die Pascal Versionen VOR urbo/Borland kaum zu gebrauchen waren..lies noch mal was ich gechrieben hatte Auch der Rest von dir ist falsch widerlegt. Und der Standard heißt Borland/Turbo Pascal! bzw Delphi! Der ISO Standard wurde wie bereits richtig erkannt nie richtig umgesetzt..daher orientiert sich alles brauchbare an dem Borland/Delphi Standard
Gegeg J. schrieb: > leider sind alle deine Kommentare falsch, aber ich will die Diskussion > jetzt hier nicht ausufern lassen.. Entweder bist Du ein Lügner oder Dir mangelt es am Textverständnis. Ansonsten wäre Dir sowohl anhand des deutschen als auch englischen Wikipedia-Artikels die Historie von Turbo Pascal aufgefallen. Die darin aufgeführten Inhalte sind natürlich mit den entsprechenden Quellen versehen. > Turbo Pascal hieß IMMER Turbo Pascal > Die von dir genannten Pascal Sprachen, haben nicht viel mit TUrbo von > Borland zu tun.. Würdest Du die genannten Quellen lesen und verstehen, dann wüsstest Du, dass der Compiler eben ursprünglich nicht von Borland stammt, sondern von Borland (einschließlich des Entwicklers) eingekauft wurde: "The Turbo Pascal compiler was based on the Blue Label Pascal compiler originally produced for the NasSys cassette-based operating system of the Nascom microcomputer in 1981 by Anders Hejlsberg. Borland licensed Hejlsberg's "PolyPascal" compiler core (Poly Data was the name of Hejlsberg's company in Denmark), and added the user interface and editor. Anders Hejlsberg joined the company as an employee and was the architect for all versions of the Turbo Pascal compiler and the first three versions of Borland Delphi.[2] The compiler was first released as Compas Pascal for CP/M, and then released on November 20, 1983 as Turbo Pascal for CP/M" > und ich sagte auch, das die Pascal Versionen VOR > urbo/Borland kaum zu gebrauchen waren..lies noch mal was ich gechrieben > hatte Mit welchen Pascal-Compilern vor Turbo Pascal hast Du denn ganz konkret gearbeitet? Und wann sind diese Compiler auf den Markt gekommen? Und wie von mir schon erwähnt, basierte der große Erfolg des Apple II und seiner vielen Clones unter anderem auf UCSD Pascal, was damals DER Standard-Pascal-Compiler für viele Plattformen war, insbesondere auch die damals sehr verbreiteten DEC PDP-11, später auch DEC VAX/VMS. Bei UCSD Pascal dürfte es sich um eines der allerersten halbwegs komplexen Programmpakete handeln, die erfolgreich sowohl auf Mainframes, Minicomputern als auch Kleincomputern eingesetzt wurden. Und das Konzept der sog. p-Machine war viele Jahre später die Vorlage für die Java VM. https://en.wikipedia.org/wiki/UCSD_Pascal Ich beide Pascal-Compiler verwendet, d.h. UCSD Pascal auf Apple und VAX Pascal auf VAX-11/780 und microVAX-II. Nichtsdestotrotz stellt Turbo Pascal natürlich einen sehr wichtigen Meilenstein in der Pascal-Geschichte dar. > Auch der Rest von dir ist falsch widerlegt. Nein, Du wiederholst nur Deine Behauptungen. Bitte lege doch endlich einmal Quellen vor, die Deine Behauptungen stützen. > Und der Standard heißt Borland/Turbo Pascal! bzw Delphi! > > Der ISO Standard wurde wie bereits richtig erkannt nie richtig > umgesetzt.. Doch, Oregon Pascal-2 für etliche Plattformen war strikt ISO-7185-konform: https://www.computerwoche.de/a/pascal-2-compiler-fuer-vax-und-micro-vax,1168616 >daher orientiert sich alles brauchbare an dem Borland/Delphi > Standard Falsch. Die (Pascal-)Welt besteht nicht nur aus PCs mit Microsoft Windows, sondern umfasste früher sehr viel mehr Plattformen, und das zu einer Zeit, als es Windows noch nicht gab und MS-DOS noch in den Kinderschuhen steckte. Ich bestreite auch keineswegs, dass sich Pascal heutzutage nur noch in wenigen Nischen erfolgreich behaupten kann. Und bezüglich der Einhaltung von Normen und Standards sind andere erfolgreiche Compiler auch nicht besser. Microsoft Visual Studio C++ (und C) weichen an vielen Stellen auch ganz bewusst auch vom ANSI/ISO-Standard ab, um die Portierung von für Windows geschriebenen Programmen auf andere Betriebssysteme zu erschweren.
:
Bearbeitet durch User
Ok, wahrscheinlich ist "Turboiges" Pascal das einzig Überlebende seiner Art, ich kann die immernoch begeisterten ja bis zu einem gewissen Punkt verstehen, war doch TP CP/M meine erste Hochsprachenentwicklungsumgebung. nur: wo ist die Verbindung zu Rust?
> Falsch. Die (Pascal-)Welt besteht nicht nur aus PCs mit Microsoft > Windows, sondern umfasste früher sehr viel mehr Plattformen, und das zu Yep. Ich hatte damals Hisoft-Pascal auf dem ZX Spektrum. Das war vor dem Apple][+ > nur: wo ist die Verbindung zu Rust? Da hab ich mich auch gefragt. Vielleicht stimmen die langfristigen Ziele (auszusterben) ja ueberein. :) Ich hab mir rust auch mal angeschaut, aber nur bis zu dem Moment bis ich zu dem abenteuerlichen Build-System kam, danach hab ich es dann gleich geloescht. Schade eigentlich, ich verstehe nicht warum irgendwelche Nasen immer glauben alles anders und schlechter machen zu muessen. Ich finde man kann den langen Beitrag von Daniel A. oben im Thread nicht genug wuerdigen, beschreibt er doch genau was ich auch gedacht habe! Olaf
Nano schrieb: >> Ich sehe da keinen Unterschied. Wenn der zugrundeliegende Dienst >> stirbt, hab ich ein Problem - aber wenn ich auf den Dienst >> angewiesen bin, ein wesentlich größeres. > > Du kannst auch Backups von den 3rd Party Sachen machen, > die du für dein Projekt brauchst. Das setzt aber voraus, dass der zugrundeliegende Dienst das in einer sinnvollen und nutzbaren Weise anbietet. Tut er das nicht, muss ich Aufwand treiben, der je nach Design des Dienstes bis auf eine komplett eigene Infrastruktur steigen kann. > Das würde ich ohnehin tun. Denn Vertrauen ist gut, Kontrolle ist besser. Im kommerziellen Umfeld: Definitiv ja. sonstnochwer schrieb: > Ich vermute, die Rede ist von µC? > Weil für neue PC-Projekte nutzt man C ja eher selten. Das glaubst aber nur du. :-) Wobei man fairerweise dazu sagen muss, dass auf dem PC so ziemlich jeder C-Code durch einen C++-fähigen Compiler läuft. Aber die meisten meiner Tools sind entweder gescriptet oder klassisch C, auch auf dem PC.
Carl D. schrieb: > Ok, wahrscheinlich ist "Turboiges" Pascal das einzig Überlebende seiner > Art, Wie schon erwähnt, wird Pascal im SPS-Bereich eingesetzt und ist dort eine recht "moderne" Sprache. Dort heißt es ST (Strukturierter Text nach EN 61131-3 bzw. ISO 61131) und SCL (ST nach Siemens-Art). Gebräuchliche Entwicklungsumgebungen sind z.B. 3soft Codesys, Beckhoff TwinCAT PLC Control und Siemens STEP7 und Siemens TIA Portal. > nur: wo ist die Verbindung zu Rust? Hmmm, es ging um historische Vergleiche der Lebenszyklen von Programmiersprachen, passend zu diesem Thread.
Olaf schrieb: > Yep. Ich hatte damals Hisoft-Pascal auf dem ZX Spektrum. Das war vor dem > Apple][+ Vermutlich meinst Du den Apple II Europlus. Er wurde im Jahr 1979 in Europa auf den Markt gebracht, der Sinclair ZX Spectrum erst 1982. Ich bin aber selbst sehr erschrocken, wie lange das schon her ist. Nach meinem Bauchgefühl kam der TX Spectrum erst um 1985 heraus. Dafür hätte ich den ZX80 in den späten 1970er Jahren verortet, aber es war doch erst 1980; beim ZX81 lag ich wiederum richtig. Ich dachte, der Zeitabstand zwischen den Modellen hätte bei mindestens zwei Jahren gelegen. Wichtiger Hinweis für die anwesenden Jungspunde: die schaltungstechnischen Kniffe im ZX80 sind wirklich sehr interessant. Ich empfehle eine der vielen Webseiten, in denen die Schaltung analysiert wird. Ebenso interessant ist der Floppy-Controller im Apple II, d.h. der Vorgänger der IWM: https://en.wikipedia.org/wiki/Integrated_Woz_Machine
> Vermutlich meinst Du den Apple II Europlus. Er wurde im Jahr 1979 in > Europa auf den Markt gebracht, der Sinclair ZX Spectrum erst 1982. Noe, ich meinte die Reihenfolge in der ich die Rechner besessen habe. :-) Der ZX Spektrum hat mit diversen (nachtraeglich gekauften) Erweiterungen (Tastatur, Drucker, Floppy) so um die 1000DM gekostet. Der ZX alleine lag IMHO so bei 300 oder 400DM. Der Apple hat als Nachbau gebraucht 2000DM gekostet. (mit Ehring, 80Z, Z80, Monitor, und einer Kiste dezentraler Sicherungskopien) Ersteres konnte ich mir schon als Schueler leisten, letzeres erst spaeter. > Nach meinem Bauchgefühl kam der TX Spectrum erst um 1985 heraus. Ich bin mir ziemlich sicher den 1982 gekauft zu haben. BTW: Hisoft Pascal war ziemliche Kacke. Musste man jedesmal 10min von der Kassette laden und beim kleinsten Programmierfehler ist alles komplett abgestuerzt. Damit sollten die heuten Programmierer mal arbeiten muessen, oder mit UCSD-P wie sie bei jedem compilieren dreimal die Diskette wechseln und einmal crunchen. Da wuerden sie sorgfaeltiger programmieren und nicht gleichen jeden Unsinn in den Compiler husten. .-) > Wichtiger Hinweis für die anwesenden Jungspunde: die > schaltungstechnischen Kniffe im ZX80 sind wirklich sehr interessant. Ach was, versteht heute eh keiner mehr. Was glaubst du warum gute Hardwareentwickler so selten sind. :-) Um aber mal wieder auf das Topic zu kommen: Aus heutiger Sicht war damals auch vieles kruder Mist. Da muss man nichts verherrlichen. Um so bizarrer finde ich das man nichts darauf lernen kann und heute wieder neuen bizarren Mist produziert indem man immer fuer alles neue inkompatible Loesungen findet, oder Sachen ins Netz auslagert die da nicht hin gehoeren. Und deshalb wird rust nicht bleiben. Zumindest nicht bei mir. Olaf
Rust erlaubt seit 1.34 auch alternative Crates. Siehe dazu folgender Ausschnitt aus dem verlinkten Artikel: "Programmiersprache: Rust 1.34 erlaubt Alternativen zu crates.io Entwickler sind im aktuellen Rust-Release nicht mehr an die zentrale Cargo-Registry gebunden. ... Dafür lassen sich mit dem Paketmanager Cargo nun auch Module verwalten, die nicht öffentlich auf crate.io abgelegt sind" Quelle: https://www.heise.de/developer/meldung/Programmiersprache-Rust-1-34-erlaubt-Alternativen-zu-crates-io-4398171.html
Außerdem, seit 1.37: "After being available as a separate crate for years, the cargo vendor command is now integrated directly into Cargo. The command fetches all your project's dependencies unpacking them into the vendor/ directory, and shows the configuration snippet required to use the vendored code during builds." Quelle: https://blog.rust-lang.org/2019/08/15/Rust-1.37.0.html
Closing the gap: cross-language LTO between Rust and C/C++ http://blog.llvm.org/2019/09/closing-gap-cross-language-lto-between.html
1 | Cross-language LTO is a new feature in the Rust compiler |
2 | that enables LLVM's link time optimization to be performed |
3 | across a mixed C/C++/Rust codebase. |
Wer rustet der rostet schrieb: > https://www.golem.de/news/security-microsoft-baut-com-bibliothek-in-rust-1910-144358.html
1 | ... während eines Praktikums beim MSRC entstanden ... |
Da hat Microsoft ja richtig Resourcen investiert.
Falls sich mal jemand gefragt hat auf welchem Stand Rust Punkto "constant evaluation" gerade ist: https://youtu.be/wkXNm_qo8aY?list=PL85XCvVPmGQhDOUIZBe6u388GydeACbTt Die Kurzfassung ist, dass sich das wohl ziemlich parallel mit C++ und dessen constexpr Möglichkeiten entwickelt.
Moin, Ich seh' sowas hier: https://www.linuxquestions.org/questions/linux-from-scratch-13/9-0-gotcha%27s-4175662685/#post6049598 und fuehle mich in meiner hier schon in Post 4 geaeusserten Meinung leider bestaetigt. Und auch wenns die Informatiker hier nicht gerne hoeren wollen: So eine Software, die sich nicht vernueftig aus sourcen bauen laesst, taugt nix. War/Ist auch bei KDE > 3.x so. Gruss WK
Der 4. Post ist von einem Typ der die gegebenen LFS scripte "von Hand" abtippt, Fehler macht, dann die Fehler Stellen nicht mal nach deutlichen Hinweisen selbst findet, ivh hab 5sek gebraucht- also eine relativ hohe Fehlerrate hat und sich scheinbar auch nicht aus kennt - so was ist bei LFS tödlich Toller beweis fuer ein ganz schlimmes Bootstrapping :)
> Microsoft: We're creating a new Rust-based programming language for secure > coding https://www.zdnet.com/article/microsoft-were-creating-a-new-rust-based-programming-language-for-secure-coding/ Oh hell no.
:
Bearbeitet durch User
> Oh hell no.
Manchmal denke ich ja die produktive Haelfte der Menschheit verteilt
sich auf C und der Rest nutzt dann 43535347 verschiedene andere
garantiert inkompatible Programmiersprachen. Denn sobald sich irgendwo
zwei Informatikschnoesel treffen muessen die garantiert sofort eine neue
Sprache erfinden oder mindestens eine andere inkompatibel machen.
Irgendwie traurig...
Olaf
Dir ist klar, dass C, C++ und Rust kompatibel sind? Du scheinst halt eher nicht so zur produktiven Hälfte der Menschheit zu gehören...
Naja, MS will halt nicht, das Leute vom MS Softwareentwicklungs Ökosystem abwandern ins sich bildende Rust Ökosystem. Bei bereits zu grossen Geschichten, wie NPM, Docker, etc. haben sie versucht eigene Repos auf GitHub anzubieten, um dort wieder etwas mehr mitreden zu können. Insgesammt glaube ich aber nicht, das daraus was wird.
Vincent H. schrieb: >> Microsoft: We're creating a new Rust-based programming language for secure >> coding > > https://www.zdnet.com/article/microsoft-were-creating-a-new-rust-based-programming-language-for-secure-coding/ > > Oh hell no Der Klassiker: https://de.wikipedia.org/wiki/Embrace,_Extend_and_Extinguish#Die_Strategie
Wenn Rust erfolgreich wird, wird so etwas wie crates.io entweder nicht schließen, oder es wird nicht die einzige Quelle sein. Wenn es schließt und es gibt keine Alternativen dann doch nur weil kaum noch jemand Rust benutzt. Dann wird es auch nur wenigen weh tun können. Außerdem spricht eigentlich nichts dagegen die Bedürfnisse der Industrie in Zukunft besser zu befriedigen. Ich würde aber so oder so nicht erwarten dass Rust C und C++ ablöst. C und C++ werden seit Jahrzehnten stückchenweise "abgelöst". Fast alle anderen populären Sprachen nehmen einen Platz ein, der ohne sie, sehr wahrscheinlich durch C/C++ gefüllt wäre. Man könnte meinen C und C++ sterben seit Jahrzehnten Stück für Stück. Man stelle sich vor, welchen Anteil C und C++ hätten, in einer Welt ohne Sprachen wie Java, C# und Python. Die Verluste bzw. nie eingenommenen Anteile sind massiv :D C++ stirbt Tag für Tag während es weiterentwickelt wird. Eine Programmiersprache hat sich etabliert, wenn es sterbend überlebt :D
Atemis H. schrieb: > Man stelle sich vor, welchen Anteil C und C++ hätten, in einer Welt ohne > Sprachen wie Java, C# und Python. Hab jetzt keine Zahlen: bist Du sicher, dass der Anteil von C/C++ kleiner wird? Es hat schon immer um die 6000 Programmiersprachen gegeben, zumindest seit C erfunden wurde. Java und Co verdrängen vielleicht eher lisp und Smalltalk.
Ich will jetzt kein Fass aufmachen, aber was kann Rust, was Ada nicht kann? Ich habe "damals" vor 20 Jahren mal Ada gelernt, bevor ich C gelernt habe. Es war deutlich intuitiver zu schreiben, und macht immer exakt (!) das, was ich wollte. Die Ganzen Sicherheitsaspekte die hier aufgezählt werden, sind in Ada schon eigentlich immer (seit der ersten Festlegung des Std.) implementiert. Klar, in Ada schreibt man sich durch das extrem strenge Typensystem die Finger Wund! - Aber das was raus kommt ist Felsenfest! Nicht um sonst, setzten diverse sicherheitskritische Bereiche (Rüstung/Luft-/Raumfahrt/Medizin/Kraftwerke/...) teils noch immer darauf auf. -> Selbst Echtzeit/Hochsicherheits-OS´s wie RTEMS sind sehr stark verbandeln mit Ada. Und was auch sehr genial ist, ist die Tatsache, das der Code sehr gut menschen lesbar und nachvollziehbar ist. Ich habe mir neulich erst ein paar Bücher aus den 80ern erstanden (wirklich dicke Schinken für sehr kleines Geld, Teilweise von der Bundeswehr Uni München die über 30 Jahre alt waren in Schreibmaschinenoptik) und die sind noch immer so aktuell (klar, Stand Ada`83) das die aktuellen Compiler (benutze GNAT) es anstandslos fressen. Eigentlich vermisse ich schon in den alten '83 Std nichts, es kann eigentlich alles, von OOP bis Tasking ohne irgendwelche externen Bibliotheken... Von GNAT gab es auch Compiler Anpassungen in Richtung Bytecode .Net/Java oder auch SPARK ist aus Ada hervor gekommen. Aktuell wir auch aktiv am Frontend gearbeitet um es direkt mit LLVM zu verbandeln (um mehr Plattformen zu erreichen) - es gibt zwar auch das DragonEgg Projekt diesbezüglich, aber das ist wohl etwas OutOfdate und nicht von GNAT/AdaCore selber initiiert.
Atemis H. schrieb: > Wenn Rust erfolgreich wird, wird so etwas wie crates.io entweder nicht > schließen Das ist einfach nur naiv. Es gibt keinen Grund anzunehmen, dass crates.io für immer brauchbar bleibt oder bleiben kann. Alles, was einen Anfang hat, hat auch ein Ende. Ob Rust oder crates.io erfolgreich ist, ist dafür komplett Irrelevant. > oder es wird nicht die einzige Quelle sein. Es soll wohl mittlerweile irgendwo ein Tool geben, die versuchen alle Crates von crates.io herunterzuladen, aber nichts offizielles. Offizielle vollständige öffentliche Mirrors von crates.io konnte ich keine finden, schon gar keine offiziellen. Also nein, wenn dass so bleibt, und crates.io verschwindet, wird es sehr wohl die einzige Quelle sein, ganz egal, ob erfolgreich oder nicht. Es wurde schlicht nicht dafür gemacht, gemirrort zu werden. Wenn es mal verschwindet, wird mann sich die Crates erstmal zusammensuchen müssen, danach kommt dann das Registry-chaos.
DPA schrieb: > Das ist einfach nur naiv. Es gibt keinen Grund anzunehmen, dass > crates.io für immer brauchbar bleibt oder bleiben kann. Alles, was einen > Anfang hat, hat auch ein Ende. Ob Rust oder crates.io erfolgreich ist, > ist dafür komplett Irrelevant. Also wirklich. Ich glaube manche verwechseln hier Programmiersprachen mit Höhlenmalereien und Steintafeln. Programmiersprachen werden nicht für die Ewigkeit gemacht und der Wert einer Programmiersprache definiert sich nicht allein dadurch wie lange alter Code compiliert werden kann. Wer solche Bedürfnisse hat sollte am besten sowieso alle nötigen Dateien herunterladen und konservieren und nicht naiv erwarten dass die Welt die nächsten Jahrzehnte still stehen wird. Mit einer neuen Programmiersprache hat man jedenfalls die Freiheit solche Bedürfnisse gezielt anzugehen ohne auf moderne Konzepte zu verzichten. Ich bin mir sicher dass das möglich ist. Außerdem glaube ich dass die Trägheit der Industrie wohl einem Wandel unterworfen ist. Digitalisierung und Vernetzung nehmen auch in industriellen Produktionen immer mehr an Bedeutung zu. Damit wird auch die Software sicherlich schnelllebiger.
:
Bearbeitet durch User
Atemis H. schrieb: > Programmiersprachen werden nicht für die Ewigkeit gemacht > und der Wert einer Programmiersprache definiert sich nicht > allein dadurch wie lange alter Code compiliert werden kann. Das hängt von der Verwendung ab. Wer es sich leisten kann (oder muss), sämtlichen Code einer größeren Codebasis regelmäßig umschreiben zu müssen, der kann auf solche Programmiersprachen zurückgreifen. Web- und Appentwicklung gehören dazu, viele andere Dinge nicht. Atemis H. schrieb: > Wer solche Bedürfnisse hat sollte am besten sowieso alle > nötigen Dateien herunterladen und konservieren Das wiederum setzt voraus, dass die Umgebung der Programmiersprachen das sinnvoll ermöglicht, also heruntergeladene Artefakte nicht nur als temporären Cache betrachtet. Atemis H. schrieb: > und nicht naiv erwarten dass die Welt die > nächsten Jahrzehnte still stehen wird. Wieviel alt ist die durchschnittliche Codezeile im Windows-Kernel? Wieviel Code aus den 90ern findest du im Linux-Kernel? Welche Teile von Android 10.0 sind seit Android 2.3 nahezu unverändert? Mal so grob nach Schnellebigkeit sortiert. Atemis H. schrieb: > Damit wird auch die Software sicherlich schnelllebiger. Wenn du damit auf "der Updater funktioniert, let's ship today" anspielst, dann hoffe ich mal stark, dass du das nicht als positives Zukunftsmodell anpreist. Einen Markt für "relativ neue Programmiersprachen mit eigenem Ökosystem" gibt es definitiv, spontan denke ich so an Objective-C, C#, Swift, Go oder Kotlin. Mein Gefühl sagt allerdings auch, dass Rust nicht in diese Kategorie gehört (oder gehören will). Ich kann mich allerdings irren.
S. R. schrieb: > Einen Markt für "relativ neue Programmiersprachen mit eigenem Ökosystem" > gibt es definitiv, spontan denke ich so an Objective-C, C#, Swift, Go > oder Kotlin. Kleiner Einspruch: Obj-C gibt es seit 1980. Das bezeichne ich nicht als "relativ neu". C gibt es seit Anfang der 70er. Wenn du aber das aber mit dem "eigenen Ökosystem" stark verbindest, dann ja. Sehr schön war das von Next -> Apple (mit all seinen Klassen die mit NS anfingen). Das war dann erst so 2008.
Nick M. schrieb: > Kleiner Einspruch: Obj-C gibt es seit 1980. Das bezeichne ich > nicht als "relativ neu". C gibt es seit Anfang der 70er. Explizit nicht C/C++. Aber von ObjC hatte ich noch nie gehört, bis Apple das großflächig beworben hat. Daher ist das in meiner Welt "relativ neu". :-)
S. R. schrieb: > Aber von ObjC hatte ich noch nie gehört, Die Sprache hatte ihren ersten Frühling beim NeXT.
Jörg W. schrieb: >> Aber von ObjC hatte ich noch nie gehört, > Die Sprache hatte ihren ersten Frühling beim NeXT. Gegründet vor meiner Geburt, aufgekauft vor meinem ersten Englischunterricht in der Schule... ich glaub, ich bin entschuldigt. :-D
S. R. schrieb: > Nick M. schrieb: >> Kleiner Einspruch: Obj-C gibt es seit 1980. Das bezeichne ich >> nicht als "relativ neu". C gibt es seit Anfang der 70er. > > Explizit nicht C/C++. Aber von ObjC hatte ich noch nie gehört, bis Apple > das großflächig beworben hat. Daher ist das in meiner Welt "relativ > neu". :-) Ich hatte davon schon gehört, aber es hieß damals, das sei ein gescheiterter erster Versuch gewesen, C objektorientiert zu machen. Umso überraschter war ich, als Apple das plötzlich wieder ausgegraben und für sich zur Standardsprache erklärt hat.
Rolf M. schrieb: > Ich hatte davon schon gehört, aber es hieß damals, das sei ein > gescheiterter erster Versuch gewesen, C objektorientiert zu machen. Nein. :-) Ich hab mal eine Zeit lang mit Obj-C programmiert, nachdem ich C++ kennen und hassen gelernt habe. Obj-C steht, von C aus betrachtet, orthogonal zu C++. Obj-C ist objektorientiert, aber nicht so mächtig wie C++. Aber dafür ist Obj-C dynamisch. Dynamische Bindung, ohne die Klasse zu kennen. Nicht so wie das irreführende <dynamic-cast> an dem nichts dynamisch ist, sondern zur Compilezeit bekannt sein muss. Late binding, tatsächlich zur Laufzeit. Garbage collector. Ja, die Syntax ist etwas gewöhnungsbedürftig, man muss sich an die vielen eckigen Klammern gewöhnen. ;-) Leider hab ich fast alles vergessen, ausser dass mir die Sprache sehr gut gefallen hat. Dass ObjC jetzt bedeutungslos ist, ist wirklich schade, insbesonders, weil sie weitaus kompakter als C++ ist, und auch auf einem uC gut einsetzbar ist.
Atemis H. schrieb: > Also wirklich. Ich glaube manche verwechseln hier Programmiersprachen > mit Höhlenmalereien und Steintafeln. Programmiersprachen werden nicht > für die Ewigkeit gemacht und der Wert einer Programmiersprache definiert > sich nicht allein dadurch wie lange alter Code compiliert werden kann. > Wer solche Bedürfnisse hat sollte am besten sowieso alle nötigen Dateien > herunterladen und konservieren und nicht naiv erwarten dass die Welt die > nächsten Jahrzehnte still stehen wird. Wow. Scheinbar glaubst du in deiner Naivität ernsthaft, die ganze Welt funktioniert so wie die hippen Web-Startups. Wenn es nach die ginge, würde man wahrscheinlich den Linux-Kernel alle drei Jahre komplett neu schreiben...
Nick M. schrieb: > Rolf M. schrieb: >> Ich hatte davon schon gehört, aber es hieß damals, das sei ein >> gescheiterter erster Versuch gewesen, C objektorientiert zu machen. > > Nein. :-) Äh, doch. Das ist wirklich das, was ich damals gehört habe. Muss ja nicht unbedingt stimmen :) Atemis H. schrieb: > Also wirklich. Ich glaube manche verwechseln hier Programmiersprachen > mit Höhlenmalereien und Steintafeln. Programmiersprachen werden nicht > für die Ewigkeit gemacht und der Wert einer Programmiersprache definiert > sich nicht allein dadurch wie lange alter Code compiliert werden kann. Das nicht, aber es ist dennoch sehr wichtig. Denn nicht jeder hat das Bedürfnis, ständig das Rad neu zu erfinden. Manche möchten auch bestehenden Code nutzen können. Je komplexer Software wird, desto wichtiger ist da eine gewisse Beständigkeit. Sonst ist man irgendwann mehr damit beschäftigt, alles immer wieder neu zu machen, als damit, die Software an sich weiterzubringen.
:
Bearbeitet durch User
Moin, Also ich find' es schon sehr angenehm, wenn so Sachen wie z.B. der Bildbetrachter xv, der schon so ca. 30 Jahre auf dem Buckel hat, "einfach so" durch ein aktuelles make und einen aktuellen C compiler in ein lauffaehiges Binary uebersetzt werden kann. Das ist fuer mich ein Zeichen von gutem code, einer guten Programmiersprache und guten tools. Davon seh' ich bei Rust eher nix. Das ist irgendein wilder Wust aus einem wilden build-system, wildem package-manager und irgendwie mit llvm verknuspelt. Und mit viel Glueck faellt da dann mal was raus. Aber nur wenn man zig Gigabyte RAM hat. Und ja nix schiefgeht. Und alle Versionen aller Beteiligten exakt zusammenpassen. Und und und. Und jetzt macht mich rot - aendert aber nix. Besser waer's an diesen Problemen zu arbeiten... Gruss WK
Dergute W. schrieb: > Davon seh' ich bei Rust eher nix. > Das ist irgendein wilder Wust aus einem wilden build-system, wildem > package-manager und irgendwie mit llvm verknuspelt. Und mit viel Glueck > faellt da dann mal was raus. soo schlimm ist es auch wieder nicht, 1 Build-System, 1 Package-Manager und die LLVM verknurspelung ist genau so wie bei Clang (eben ein anderes Frontend) ansonsten weit näher an C als C++ - was jedem alten C-ler gefallen sollte alles braucht seine Zeit und Rust auch Der xv ist ja kein Paradebeispiel für eine komplexe vielschichtige Software (mit der manche von uns kämpfen) - xv ist in jeder Sprache mehr oder minder einfach - nur nicht in Perl :)
cppbert schrieb: > soo schlimm ist es auch wieder nicht, 1 Build-System, 1 Package-Manager Ähm, das würde ich jetzt eher als Negativpunkt betrachten, besonders ersteres. Keine Alternativen, Abhängigkeit / Single point of failure, keine Konkurrenz, etc. Es ist auch nicht so, als könnte man das von heute auf Morgen einfach so ändern, wenn dort mal irgendetwas unerwartetes passiert.
Dergute W. schrieb: > Davon seh' ich bei Rust eher nix. Naja, bisschen Zeit kann man dem Rost ... Rust schon lassen um sich anzusetz ... zu setzen. Aber man muss nicht jedem Hype hinterherrennen. Erst recht nicht, wenn der Code produktiv verwendet wird. Aus reiner Neugier und privat: Wieso nicht! Neue Konzepte kennenzulernen schadet absolut nichts.
Die Komfort Funktionen mit dem Paketmanager sind nicht zwingend. Man ist nicht gezwungen cargo zu benutzen und crates.io ist keine nicht auswechselbare Quelle. Man kann die Quellen selbst ändern und eigene lokale Quellen anlegen, die nichts anderes sind als Ordner voller Source Dateien. Man kann mit dem --git Flag in cargo auch direkt aus einem Git Repo installieren. https://doc.rust-lang.org/cargo/reference/source-replacement.html Wenn ich bei C++ externe Bibiliotheken einbinde bin ich doch auch abhängig davon und wenn ich die Dateien nicht selbe sichere, muss ich hoffen, dass sie auch in 30 Jahren noch im Internet gehostet und angeboten werden.
:
Bearbeitet durch User
DPA schrieb: > cppbert schrieb: >> soo schlimm ist es auch wieder nicht, 1 Build-System, 1 Package-Manager > > Ähm, das würde ich jetzt eher als Negativpunkt betrachten, besonders > ersteres. Keine Alternativen, Abhängigkeit / Single point of failure, > keine Konkurrenz, etc. Es ist auch nicht so, als könnte man das von > heute auf Morgen einfach so ändern, wenn dort mal irgendetwas > unerwartetes passiert. Alles Open Source, genau so wie meisten anderen Buildsysteme, wenn es Müll ist wird es ersetzt wenn nicht gibt es einfach einen Standard den alle Sprechen Ergebnis bei C/C++: mind. 10 relevante Buildsysteme, alle inkompatibel und jedes anders zu bedienen, in jedem Projekt hab ich es mit einem anderen Buildsystem zu tun - solche Argumente kommen doch nur von denen die kaum wechseln müssen Die Argumente die teilweise bei C/C++ ins Feld geführt werden sind oft sehr schwach und eher antrainiertes Verhalten - Beispiel die Kämpfe um das Problem Include-System, da haben so viele das schreien angefangen wenn man über Änderungen sprechen wollte, jahrelang - jetzt heissts immer nur noch "bald haben wir Modules" und die Probleme im Design werden einfach ignoriert Warum so viele Entwickler über die sinnhaftigkeit von Entwicklungen diskutieren, sich aber selbst nie direkt darin involvieren und trotzdem denke sie wuerde die notwendigkeiten und schwächen wirklich verstehen bleibt mir schleierhaft Die meisten "so sollte man es richtig machen" Aussage kommen immer von den Leuten mit dem geringsten Involvement und der geringsten breitenerfahrung an Technologien und Sprachen
Ich benutze einen Texteditor Neovim. Das ist ein Fork von VIM. An dem Ding wird seit >6 Jahren gearbeitet. Auf github steht dass dieses Projekt etwa 500 contributors hat. Die aktuelle Version ist 0.5.XXX. https://github.com/neovim/neovim Und da wurde nicht mal die Programmiersprache geändert. Es werden neue features hinzugefügt und refactoring gemacht. Also ich will sehen wie man große Projekte einfach noch mal im Rust neu schreibt. Irgendwie stelle ich mir das ziemlich schwer vor ;-)
Übrigens Mozilla muss auch nicht den gesamten C++ Code für Firefox auf Anhieb oder überhaupt vollständig durch Rust ersetzen. Man kann Rust in bestehenden C++ Projekten nutzen ohne die bisherige Arbeit zunichte zu machen.
:
Bearbeitet durch User
zitter_ned_aso schrieb: > Also ich will sehen wie man große Projekte einfach noch mal im Rust neu > schreibt. Irgendwie stelle ich mir das ziemlich schwer vor ;-) Warum sollten man das überhaupt machen? Ich kann doch auch nur ein paar Module in Rust programmieren und wenn es sich durchsetzt dann eben über die Zeit Das ist aber komischerweise immer eines der ersten Argumente - wie soll man das alles neu schreiben... niemand Neuschreiben wollen immer nur die Anfänger :)
Das ist ja noch schlimmer. Die einfachste Programmiersparche der Welt C++ und Rust lernen. (und später C++ "wegschmeißen")
zitter_ned_aso schrieb: > Das ist ja noch schlimmer. > > Die einfachste Programmiersparche der Welt C++ und Rust lernen. (und > später C++ "wegschmeißen") Rust ist vom Konzept her doch eher wie C und schwer weil der Kompiler dich stört beim Müll programmieren, C++ ist schwer weil es so leicht ist fehlerhaften oder schwer verständlichen Code zu schreiben - das kann man doch gar nicht vergleichen
Dergute W. schrieb: > Das ist fuer mich ein > Zeichen von gutem code, einer guten Programmiersprache und guten tools. > Davon seh' ich bei Rust eher nix. Das ist vor allem ein Zeichen von eingehaltener Rückwärtskompatibilität mit all seinen Vor- und Nachteilen. Es bringt nichts durch eine subjektive Romantisierung nur auf die Vorteile hinzuweisen. Die Nachteile sind dass man die Altlasten trägt und den Sprachumfang immer weiter aufbläht.
Tja, was C++ bisher nicht geschafft hat... ;) Linus Torvalds kann sich Rust im Linux-Kernel vorstellen https://www.golem.de/news/programmiersprache-linus-torvalds-kann-sich-rust-im-linux-kernel-vorstellen-2007-149627.html
Moin, <heise-mode>Juhuu, das ist das Ende von Linux</heise-mode> SCNR, WK
Kaj schrieb: > Linus Torvalds kann sich Rust im Linux-Kernel vorstellen > https://www.golem.de/news/programmiersprache-linus-torvalds-kann-sich-rust-im-linux-kernel-vorstellen-2007-149627.html Klingt spannend. Wenn das klappt, dann wäre das nach Mozilla selbst und Microsoft eine weitere große und prominente Entwicklergruppe, die der Verbreitung der Sprache Vorschub leistet. Am Ende bleiben dann wohl nur noch - Rust (für systemnahe und zeitkritische Programme), - Python (für kleine Anwendungsprogramme) und - Haskell (für große Anwendungsprogramme) übrig, da alle drei sowohl von der Open-Source-Community als auch von dem Softwareriesen Microsoft unterstützt werden, so dass neben den technischen auch immer mehr die unternehmenspolitischen Hemmschwellen fallen dürften. Aber natürlich werden auch Fortran, Cobol, C++, Java und C# nicht völlig aussterben ;-)
Yalu X. schrieb: > Am Ende bleiben dann wohl nur noch > > - Rust (für systemnahe und zeitkritische Programme), > - Python (für kleine Anwendungsprogramme) und > - Haskell (für große Anwendungsprogramme) Also wenn ich so an viel verwendete oder aufstrebende Programmiersprachen denke, kommt mir Haskell nicht unbedingt als erstes in den Sinn. :) Im PYPL-Index ist sie mit 0,29% auf Platz 27 (Tendenz fallend), im TIOBE-Index sogar nur auf Platz 40. Wenn sie es in den letzten 30 Jahren nicht darüber hinaus geschafft hat, ist es eher unwahrscheinlich, dass sich das plötzlich ändert. Yalu X. schrieb: > Aber natürlich werden auch Fortran, Cobol, C++, Java und > C# nicht völlig aussterben ;-) Vermutlich nicht :)
Zum jetzigen Zeitpunkt fände ich das eine sehr schlechte Idee. Jetzt kann man den Kernel endlich mal mit zwei unabhängigen Compilern bauen, und dann will man sich von rustc/llvm abhängig machen? Rustc, von dem es keine alternative Implementierung gibt, und wo statt einem anständigen Standard rustc die Referenz ist? Wenn sie das machen, müssen sie nachher jeden Mist, den sich die rustc Compiler Bastler ausdenken, mitmachen, ist denen das klar? Ich hoffe, die kommen wenigstens nicht auf die Idee cargo zu verwenden...
Rolf M. schrieb: > Yalu X. schrieb: >> Am Ende bleiben dann wohl nur noch >> >> - Rust (für systemnahe und zeitkritische Programme), >> - Python (für kleine Anwendungsprogramme) und >> - Haskell (für große Anwendungsprogramme) > > Also wenn ich so an viel verwendete oder aufstrebende > Programmiersprachen denke, kommt mir Haskell nicht unbedingt als erstes > in den Sinn. :) Deswegen steht es ja nur an dritter und letzter Stelle ;-)
> Also wenn ich so an viel verwendete oder aufstrebende > Programmiersprachen denke, kommt mir Haskell nicht unbedingt als erstes > in den Sinn. :) Mir kommt da immer der frueher einmal pro Jahr wiederkehrende Artikel in der C't in Erinnerung wo sie uns darauf aufmerksam gemacht haben das Smalltalk kurz vor dem Durchbruch steht. :-D Und dann gibt es noch immer die regelmaessig wiederkehrenden Artikel das man noch dringend Fortran und Cobol Programmierer sucht. Olaf
Es wäre schade jetzt viel Zeit in C (oder gar C++) zu investieren / die Sprachen zu lernen und später dann doch umsteigen :-( Aber vielleicht wird Rust die Kernelentwickler doch noch enttäuschen und dann rausfliegen ;-) Wenn aber C langsam aber sicher durch Rust ersetzt wird, dann hat C++ gar keine Zukunft.
zitter_ned_aso schrieb: > Es wäre schade jetzt viel Zeit in C (oder gar C++) zu investieren / die > Sprachen zu lernen und später dann doch umsteigen :-( Mach dir deswegen keine Sorgen. Ich weiß ja nicht, wieviel Lebens- und Berufsjahre du noch vor dir hast, aber geh mal davon aus, dass bis zu deinem Renteneintritt C und C++ nicht obsolet werden werden.
https://github.com/rust-lang/rust/issues/44052 Zudem ist Rust nun auch für AVR verfügbar (gut, war es schon länger aber neu ist dass es mit upstream Rust gemerged wurde)
Yalu X. schrieb: >>> - Haskell (für große Anwendungsprogramme) >> >> Also wenn ich so an viel verwendete oder aufstrebende >> Programmiersprachen denke, kommt mir Haskell nicht unbedingt als erstes >> in den Sinn. :) > > Deswegen steht es ja nur an dritter und letzter Stelle ;-) Haskell ist eine tolle Sprache, keine Frage. Aber Haskell als solches wird sich (leider?) nicht in der Masse durchsetzen, da nicht "Massenkompatibel". Wenn man sich die großen Plattformen/Sprachen der letzten Jahrzehnte anschaut fällt auf, dass es alles sehr "pragmatische" Sprachen sind, die erfolgreich waren, und nicht die "schönen" und "perfekten". Man erinnere sich an Perl, schaue sich den Java-Hype und PHP-Hype an und auch Ruby. C# ist auch pragmatisch und (war) zusätzlich ein Politikum, aktuell wächst es auch wegen dotnet. Python hat einen Push durch den ganzen KI-Kram bekommen weil es vorher im "Wissenschafts-Computing" schon am wachsen war. Javascript/Typescript wächst auch kontinuierlich und wird/ist das neue PHP. C/C++ hat etwas eine Sonderstellung, weil es unglaublich viel Legacy-Code in dieser Sprache gibt und selbst heute mehr und weniger nur ein "Luxus-Assembler" ist.
Beitrag #6338497 wurde von einem Moderator gelöscht.
Beitrag #6338509 wurde von einem Moderator gelöscht.
> Es wäre schade jetzt viel Zeit in C (oder gar C++) zu investieren / die > Sprachen zu lernen und später dann doch umsteigen :-( Selten so gelacht. Seit etwa 20Jahren ist C im Embeddedbereich der Standard. Egal welche schicke neue Sprache du cool findest, du musst immer und als allererstes sehr gute C Kenntnisse haben weil du sonst nicht die Arbeiten der letzten 10Jahre in deiner Firma lesen, verstehen und wiederverwenden koenntest. Ueber jede neue Sprache kannst du nachdenken nachdem du C drauf hast und nicht umgekehrt. Und das ist auch der Grund warum jede neue Sprache es so schwer hat. Und vergiss nicht, du arbeitest auch mit Kollegen zusammen die keine Lust auf deine neue Sprache haben, oder eine ganz andere Sprache cool finden, aber alle koennen auf jedenfall C. Olaf
zitter_ned_aso schrieb: > Es wäre schade jetzt viel Zeit in C (oder gar C++) zu investieren / die > Sprachen zu lernen und später dann doch umsteigen :-( Klar. Wie kurzlebig C ist, hat es in den letzten fast 50 Jahren ja bewiesen. :) Ok, die "Modesprache" C++ ist erst 35 Jahre alt… ? DPA ? schrieb: > Jetzt kann man den Kernel endlich mal mit zwei unabhängigen Compilern bauen, > und dann will man sich von rustc/llvm abhängig machen? Mir scheint, dass Linus solche Abhängigkeiten egal sind. Er hat ja auch hart daran gearbeitet, dass es möglichst schwer ist, den Kernel mit was anderem als gcc zu übersetzen.
Man kann da sagen was man will. Man merkt C und C++ ihr Alter an und dass die Neuerungen in C++ einfach nicht die Überzeugungskraft und Eleganz einer neuen Programmiersprache haben, die basierend auf den Erfahrungen mit C++ ganz neu erdacht wurde. Was manche nicht verstehen ist dass historisch bedingte Positionen nicht ewig bessere Konzepte am Durchbruch hindern können. In solchen Fällen benötigt der Durchbruch der besseren Konzepte nur etwas mehr Zeit. Es ist aber nicht abzuwenden. Es ist sogar denkbar dass auch andere Programmiersprachen entstehen die die Grundideen von Rust übernehmen und vielleicht wird eine Variante davon erfolgreicher. So oder so C++ ist wie auch Rust nicht für die Ewigkeit.
Und eins muss man doch auch einsehen. Wenn man eine Programmiersprache viele Jahre lernen muss um sie wirklich zu beherrschen dann ist das ein Zeichen dafür das die Sprache aufgebläht ist. Warum also 10 Jahre C++ Erfahrung anhäufen wenn man die selbe Kompetenz auch mit 1-2 Jahren Rust hätte? So was ist höchstens im Interesse von Leuten die die Durststrecke bereits durchgemacht haben und nun von ihrer gefragten Position profitieren. Und es dauert ja bis die nächste Welle erfahrender C++ in 10-15 Jahren ankommen :D Im Grunde ist das bitter für die Wirtschaft die dadurch nur Zeit verliert.
SoOderSo schrieb: > Man merkt C und C++ ihr Alter an und > dass die Neuerungen in C++ einfach nicht die Überzeugungskraft und > Eleganz einer neuen Programmiersprache haben, die basierend auf den > Erfahrungen mit C++ ganz neu erdacht wurde. Letztlich ist’s ja auch die Frage, was langfristig sinnvoller zu lernen ist: eine Sprache wie C++, die es nunmal schon einige Dekaden gibt, und die man daher als etabliert bezeichnen könnte, oder Rust, das möglicherweise den Weg der meisten „modernen“ Sprachen geht, und in wenigen Jahren von etwa „Oxide“ abgelöst wird, oder ganz an Bedeutung verloren hat?
SoOderSo schrieb: > benötigt der Durchbruch der besseren Konzepte nur etwas mehr Zeit. Es > ist aber nicht abzuwenden. > > Es ist sogar denkbar dass auch andere Programmiersprachen entstehen die > die Grundideen von Rust übernehmen und vielleicht wird eine Variante > davon erfolgreicher. Das war doch genau die Frage: schafft es Rust? Oder erst ein Nachfolger an St. Nimmerlein. C++ ist doch eine lebendige Sprache, die wohl kaum das Problem hat, zu wenige Konzepte zu vereinigen.
SoOderSo schrieb: > Warum also 10 Jahre C++ Erfahrung anhäufen wenn man die selbe Kompetenz > auch mit 1-2 Jahren Rust hätte? Das ist ne ziemlich sinnlose Frage. Ich kann auch fragen: Warum also 10 Jahre Rust Erfahrung anhäufen wenn man die selbe Kompetenz auch mit 1-2 Jahren C++ hätte?
Ich denke schon, dass Rust mittlerweilen das Potenzial hat zu bleiben (vor allem, wenn man sich mal anschaut wer bereits Rust nutzt): - Firefox (Servo, Quantum) - Redox OS - Stratis (file system für Fedora und RHEL) - Dropbox (Magic Pocket) - Microsoft Azure IoT Edge - OpenDNS - TOR - Discord - Google Fuchsia ...
Schorschi schrieb: > vor allem, wenn man sich mal anschaut wer bereits Rust nutzt Du kannst dir auch anschauen, wer bereits Java genutzt hat. In einigen Bereichen ist‘s schon wieder nahezu weg.
Also ich zocke Rust immer noch gerne. IMO das beste Survival Game am Markt.
Andererseits würde die Liste, wer alles C++ benutzt, locker den Thread sprengen. :-)) Aber es ist natürlich auch klar, dass ein „Neuankömmling“ es gegenüber den Etablierten immer erstmal schwer hat. Letztlich wird es damit stehen und fallen, ob es auch in der Industrie „ankommt“, weil es in der Lage ist, in einem Projekt gegenüber C oder C++ wirklich Entwicklungszeit zu sparen.
Jack V. schrieb: > Du kannst dir auch anschauen, wer bereits Java genutzt hat. In einigen > Bereichen ist‘s schon wieder nahezu weg. klar das gibt es immer wieder und wird auch immer so bleiben aber man darf Rust definitiv zugestehen das es positiven Einfluss auf die Branche ausübt (z.B. Herb Sutters Gedanken zum Ownershipping in für C++, die Ideen das auch in D rein zu bringen - was auch wieder einige Gedankenknoten für andere Sprachen lösen könnte) und in der System oder Hardware-nahen Programmierung gab es bisher gar keine alternativen zu C/C++ - dort wo auch die Java oder .Net/GCC-Sprachen-Entwickler wie Microsoft/Sun/etc. selbst nur kurzen und teilweise peinliche Vorstöße gewagt haben allgemein sehe ich Rust als den dritten im Bunde zwischen C und C++ in der System/Embedded-Welt die sich gegenseitig sehr gut mit Ideen versorgen, für normale Applikationen fehlen einfach noch sehr viele Dinge die C++,C#,Java nach Jahren des Aufbaus einfach so aus dem Ärmel schütteln und "nur" die eine oder andere Sprache zu lernen und hier Aufwand/Kosten/Nutzen abzuwägen ist eh nur Anfänger die keinen Bock haben :) man sollte z.B. mindestens ein paar der "Großen" Sprachen wie z.B. C/C++/C#/Java und 1-2 Script-Sprache gut beherrschen Rust krankt aber definitiv immer noch an der fehlenden ABI, dem First-Shot-Kompiler der vollständig aber einfach noch viel zu langsam ist weil er alles schön sequentiell durchkaut, zu viel IR-Code dem LLVM hinwirft und,und,und - Kompilierzeit ist gerade noch ein Thema das die "Sprache" schlecht wirken lässt - vergleichbar mit dem Hyper-Pfeilschnellem D dmd der dafür aber miesen Code erzeugt
Moin, Na, was steht denn so im BLFS Book, wenn man rustc-1.42.0 bauen will: > Unfortunately, rust insists on installing source files for these below /opt/rustc/lib/src. Unschoen, aber naja gut. > On some systems, linking fails to include libffi unless this is used. The reason why this is needed is not clear. Das sieht mir doch nach irgendeiner Unsauberkeit im Buildprocess aus. Tut das not? > For a long time, the miri crate (an interpreter for the Midlevel Intermediate Representation) has failed to build on releases. It is optional, but the failure messages can persuade people that the whole build failed. However, although it is not built in the main compile, with rustc-1.35.0 it now gets compiled during the install, but it is broken in this version. WTF? Wieso fliegt sowas nicht raus oder wird gefixt? Genau so sieht sh*tty Software aus. > On some systems, cairo fails to link during the install because it cannot find libssh2. This seems to fix it, but again the reason why the problem occurs is not understood. Siehe oben: Unsauberer Buildprocess. Da kann die Sprache noch so toll sein, wenn der real existierende dampfende Haufen aus Rustcompiler, Paket-Kasper und llvm noch solche Gimmicks hat, bin ich eher nur so mittelfroh. Gruss WK
Gibt es eigentlich eine formale Spezifikation von Rust? Oder definiert der Compiler das Verhalten (wie bei Perl)?
S. R. schrieb: > Gibt es eigentlich eine formale Spezifikation von Rust? > Oder definiert der Compiler das Verhalten (wie bei Perl)? Das Rustbook/die StdLib ist die Spec. https://doc.rust-lang.org/stable/book/
Kaj schrieb: > Das Rustbook/die StdLib ist die Spec. Hmm, aber irgendeine Syntax-Definition sehe ich da nicht (EBNF oder Syntaxdiagramme).
Jörg W. schrieb: > Kaj schrieb: >> Das Rustbook/die StdLib ist die Spec. > > Hmm, aber irgendeine Syntax-Definition sehe ich da nicht (EBNF oder > Syntaxdiagramme). Die Semantik-Definition ist auch eher "dünn".
kein Mensch sagt Rust ist gut weil die formale Spezifikation von Rust qualitativ so gut da steht oder das bauen aus den Quellen so super schnuckelig ist - es ist und bleibt ein Community Projekt das immer noch organisch wächst das kann man nicht wirklich mit so einem stringenten Prozess wie bei der Go , Swift oder .Net Entwicklung vergleichen - es sind viel weniger Leute beteiligt und auch ist eine schnelle (ISO)Standardisierung nicht Prio 0 gewesen - erst mal schauen ob die Ideen wie z.B. Ownership so funktionieren und dann langsam wachsen lassen - die ersten paar Versionen der nicht Go/Swift usw. Kompiler waren auch nicht von Anfang an ein Gedicht Klar ist das Gesamtkunstwerk aus Sprache+Kompiler relevant - aber dann kann man sich aber auch über die Leichtigkeit von Crosskompilieren mit Clang im Vergleich zu GCC oder Visual Studio aufregen :)
Momentan definiert effektiv der Compiler das Verhalten. https://github.com/rust-lang/reference : > This document is the primary reference for the Rust programming language. > > This document is not normative. It may include details that are specific to > rustc itself, and should not be taken as a specification for the Rust > language. We intend to produce such a document someday, but this is what we > have for now.
cppbert schrieb: > auch ist eine schnelle (ISO)Standardisierung nicht Prio 0 gewesen Naja, das war bei C ja auch ein Weg von fast 20 Jahren. Dennoch, schau dir die BCPL-Referenz von 1967 an (Vorläufer von C, findest du auf Dennis Ritchie's Webseiten) und vergleich das mal mit dem, was Rust als "Definition" bietet. Klar, wenn du dir dann den K&R ansiehst, enthält der auch einen deutlich größeren Textteil mit anwenderorientierter Prosa, aber eben dennoch die formale Beschreibung der Sprache ebenso. Bei Rust sehe ich nur die anwenderorientierte Prosa, keine formale Beschreibung.
> Naja, das war bei C ja auch ein Weg von fast 20 Jahren. C hatte im Embedded Bereich den Vorteil das es praktisch nur Assembler verdraengen musste und das war eher einfach. .-) > Das war doch genau die Frage: schafft es Rust? Oder erst ein Nachfolger > an St. Nimmerlein. Frag das in 10Jahren nochmal! > C++ ist doch eine lebendige Sprache, die wohl kaum das Problem hat, zu > wenige Konzepte zu vereinigen. Ja, aber ich hab den Eindruck als wenn es von grossen in der branche schon den Wunsch gibt einfachere Sprachen durchzusetzen damit man auch schlichtere (und billigere) Gemueter als Programmierer verwenden kann. C++ ist sozusagen die taegliche Diplompruefung. :-D Olaf
Olaf schrieb: > Ja, aber ich hab den Eindruck als wenn es von grossen in der branche > schon den Wunsch gibt einfachere Sprachen durchzusetzen damit man auch > schlichtere (und billigere) Gemueter als Programmierer verwenden kann. Wenn das so einfach wäre, würden heute alle Programme in Logo von der Putzfrau erstellt werden. Die Komplexität in der SW Entwicklung entsteht nicht durch die Programmiersprache.
Jörg W. schrieb: > Dennoch, schau dir die BCPL-Referenz von 1967 an (Vorläufer von C, > findest du auf Dennis Ritchie's Webseiten) und vergleich das mal mit > dem, was Rust als "Definition" bietet. Es gibt immer Entwickler die mehr Wert darauf legen von Anfang an gut definiert zu sein - aber das ist einfach kein Qualitätsmerkmal der Sprache, es muss irgendwann perfekt da stehen - aber jetzt gerade glaube ich ist das noch nicht so relevant Problem ist eben: Es muss besser als C/C++, schneller und sauberer spezifiziert sein - sonst lohnt es sich schon mal nicht drauf zu schauen - mit dem Argument kann man alles bremsen :)
cppbert schrieb: > aber das ist einfach kein Qualitätsmerkmal der > Sprache, es muss irgendwann perfekt da stehen - aber jetzt gerade glaube > ich ist das noch nicht so relevant Läuft das dann unter dem Schlagwort "liquid Syntax"? Mal ernsthaft, das wirkt alles wie Hipster Kram aber nicht wie ein ernsthafter Versuch etablierte Industriestandards zu ersetzen.
Cyblord -. schrieb: > Die Komplexität in der SW Entwicklung entsteht nicht durch die > Programmiersprache. nicht "NUR" durch die Programmiersprache wäre passender - aber man kann Komplexitätsreduktion damit begünstigen aber es gibt ja auch genug Leute die sagen: durch den Kompiler forciertes Owning ist das selbe wie Smart-Pointers in C++ - weil der Faktor Mensch (Stress, Desinteresse, man findet keine besseren Entwickler usw. - nicht relevant sein kann(darf?)) und bei den großen Projekten mit >10Mio Zeilen Code und hunderten von Entwicklern ist einfach jede Verbesserung spürbar
cppbert schrieb: > Jörg W. schrieb: >> Dennoch, schau dir die BCPL-Referenz von 1967 an (Vorläufer von C, >> findest du auf Dennis Ritchie's Webseiten) und vergleich das mal mit >> dem, was Rust als "Definition" bietet. > > Es gibt immer Entwickler die mehr Wert darauf legen von Anfang an gut > definiert zu sein - aber das ist einfach kein Qualitätsmerkmal der > Sprache, es muss irgendwann perfekt da stehen - aber jetzt gerade glaube > ich ist das noch nicht so relevant Es wird sicher niemals perfekt sein, muss es auch nicht. Eine Sprache muss zwingend Work in Progress sein, um erfolgreich zu sein. Die Sprache nicht zu definieren ist das gleiche wie Software nicht zu Dokumentieren, "Technical Debt". Der aktuelle Zustand der "Definition" ist ein Problem. Es kann ohne klare Definition keinen alternativen Compiler geben, ohne dass es schnell zwei unterschiedliche Sprachen gibt. Der Einstieg in die Sprache und vor allem der Einstige in die Entwicklung der Sprache wird nach und nach immer schwerer. Wenn man den Compiler lesen und verstehen muss, um konstruktiv an der Sprache zu arbeiten, läuft etwas schief.
Cyblord -. schrieb: > Läuft das dann unter dem Schlagwort "liquid Syntax"? Mal ernsthaft, das > wirkt alles wie Hipster Kram aber nicht wie ein ernsthafter Versuch > etablierte Industriestandards zu ersetzen. die Revolution wurde von den großen der Branche x mal versucht - und sie sind alle gescheitert - daher jetzt einfach mal in kleinen Happen - wenn es nichts wird ist es auch nicht schlimm - aber bitte nicht immer alles auf die Goldwaage legen - dafür ist die Thematik einfach zu umfangreich (vom Style, der Ausdruckskraft bis runter auf die Code-Optimierungsebene) Es ist nicht leicht, es gab viele Fehlversuche, es wird weiterhin Fehler geben, keiner Zwingt einem was auf, lernen tut nicht weh, Gründe findet man immer, wir haben nichts zu verlieren
mh schrieb: > Der aktuelle Zustand der "Definition" ist ein Problem. Es kann ohne > klare Definition keinen alternativen Compiler geben, ohne dass es > schnell zwei unterschiedliche Sprachen gibt. 100% ACK - aber wenn es dazu kommen sollte das alternative Kompiler erbaut werden (ich schaue auf euch Microsoft und google) werden sich die Leute zusammensetzen - die Zeiten von Inkompatible und Vendor Lock-in sind definitiv lange vorbei und werden von niemandem mehr akzeptiert - die Vermarktung wird zu schwer
und klar rennen da draußen tausend Fanboys rum die schreien das Rust das geilsten ist was es gibt - die dürfen wir Profis natürlich mit aller Kraft ignorieren
cppbert schrieb: > Es ist nicht leicht, es gab viele Fehlversuche, es wird weiterhin Fehler > geben, keiner Zwingt einem was auf, lernen tut nicht weh, Gründe findet > man immer, wir haben nichts zu verlieren Das sehe ich anders. Lernen kostet Zeit und Zeit ist endlich. Wenn ich etwas "falsches" lerne, tut mir das weh. cppbert schrieb: > 100% ACK - aber wenn es dazu kommen sollte das alternative Kompiler > erbaut werden (ich schaue auf euch Microsoft und google) werden sich die > Leute zusammensetzen - die Zeiten von Inkompatible und Vendor Lock-in > sind definitiv lange vorbei und werden von niemandem mehr akzeptiert - > die Vermarktung wird zu schwer Auch das sehe ich deutlich anders. Wenn Microsoft oder Google eine Möglichkeit zum Vendor Lock-in sehen, werden sie es versuchen. Neben böser Absicht, gibt es aber auch noch die Möglichkeit, dass sie eine ganz andere Vorstellung der Sprache haben, und diese mit einem alternativen Compiler umsetzen.
Die Compilezeiten sind mir ziemlich egal, in Anbetracht des Mehr an Sicherheit das die Sprache bietet. Denn das ist alles Zeit, die ein Entwickler nicht in Fehlersuche/Bugfixes investieren muss. Wem das compilieren zu lange dauert:
1 | cargo check |
2 | |
3 | check - Analyze the current package and report errors, but don't build object files |
Warum die Zeiten so lang sind, kann man hier lesen: The Rust Compilation Model Calamity https://pingcap.com/blog/rust-compilation-model-calamity
cppbert schrieb: > nicht "NUR" durch die Programmiersprache wäre passender - aber man kann > Komplexitätsreduktion damit begünstigen Die Sprache ist eher ein Pinsel für den Maler. Ja, manche sind besser als andere, je nach Aufgabe, vor allem bei Massenware. Aber letztendlich ist jede in der Praxis geschliffene Hochsprache (ab C) nur ein Werkzeug, gerade bei komplexen Projekten, wo die Sprache weit hinter dem inneren Aufbau der SW zurücktritt. Olaf schrieb: > C hatte im Embedded Bereich den Vorteil das es praktisch nur Assembler > verdraengen musste und das war eher einfach. .-) Das würde ich nicht sagen. Es ist halt nur C übrig geblieben, aber Forth, Ada, Pascal, Basic und vermutlich hunderte weitere waren da ebenso im Rennen.
> Das sehe ich anders. Lernen kostet Zeit und Zeit ist endlich. Wenn ich > etwas "falsches" lerne, tut mir das weh. klingt dramatisch: wie oft hast du denn schon falsches gelernt? und warum hattest du die Sorge bei C/C++ nicht oder hast du dir damals dann nur Pascal angeschaut > Auch das sehe ich deutlich anders. Wenn Microsoft oder Google eine > Möglichkeit zum Vendor Lock-in sehen, werden sie es versuchen. > > Neben böser Absicht, gibt es aber auch noch die Möglichkeit, dass sie > eine ganz andere Vorstellung der Sprache haben, und diese mit einem > alternativen Compiler umsetzen. das ist einfach quatsch - nicht ein Standard hält eine Sprache stabil und frei von monitären/macht Einflüssen sondern einen starke Entwicklergemeinde die sich dagegen wehrt - und google/Microsoft habe trotz ihrer Größe z.B. nicht mehr die Kraft sowas wie ein LLVM Projekte alleine zu stemmen - die Zeiten sind vorbei Microsoft und google sind auch sehr stark im C++ Konsortium drin - d.h. die treffen da auch schon viele Entscheidungen mit - was ist der Unterschied?
Kaj schrieb: > Die Compilezeiten sind mir ziemlich egal ...solange du nicht was größeres machst wo es nervig wird - es gibt keine Programmiersprache bei der das egal ist - es ist nur der Projektaufbau und die Projektgröße entscheidend solche Aussagen haben dazu geführt das wir bei C++ seit Jahrzenten Modules ignoriert haben und wohl noch bis 2022 brauchen bis dieses Thema endlich anständig gelöst ist
A. S. schrieb: > Es ist halt nur C übrig geblieben, aber Forth, Ada, Pascal, Basic und > vermutlich hunderte weitere waren da ebenso im Rennen. Für Embedded / Lowlevel OS? FORTH schon, Ada kam erst eine Dekade später und gab sich wohl nie Mühe, außerhalb seines angedachten Anwenderkreises allgemein Fuß zu fassen. Pascal und Basic rannten auf dieser Ebene nicht mit. Selbst wenn man Standard-Pascal mal beiseite lässt, ich habe gern und viel mit Turbo-Pascal unter CP/M gemacht, aber wenn's schnell gehen sollte, musste man schon auf den Inline-Assembler zurückgreifen. Im Gegensatz zu dem, was wir jetzt bspw. von GCC kennen, war das aber nur ein Objektcode-Einbetter, gar kein Assembler selbst: man musste den Objektcode extern mit einem Assembler erzeugen und konnte den Assemblercode höchstens noch als Kommentar reinschreiben.
A. S. schrieb: > Aber letztendlich > ist jede in der Praxis geschliffene Hochsprache (ab C) nur ein Werkzeug, > gerade bei komplexen Projekten, wo die Sprache weit hinter dem inneren > Aufbau der SW zurücktritt. d.h. es lohnt sich einfach nicht mehr die Ausruckskraft von Sprachen zu hinterfragen, zu erweitern, begrenzen?
cppbert schrieb: >> Die Compilezeiten sind mir ziemlich egal Ich habe noch nie einen Entwickler sagen hören - "Es wäre schön wenn es länger kompiliern würde"
> FORTH schon, Ada kam erst eine Dekade später und gab sich wohl nie Mühe, > außerhalb seines angedachten Anwenderkreises allgemein Fuß zu fassen. Das sehe ich aehnlich. Von Ada hab ich jedenfalls damals nichts gehoert. Forth gab es hier und da, aber das hat nie mehr als 100Leute pro Land interessiert und die waren jeweils damit beschaeftigt einen eigenen Interpreter fuer ihre Lieblingshardaware zu schreiben. .-) > Pascal und Basic rannten auf dieser Ebene nicht mit. Selbst wenn man Pascal haette es schaffen koenne. Es gab auch Versuche das compilat von TurboPascal embedded zu nutzen. (c't, aber auch von anderen) Aber letztlich fand der Uebergang damals schon von Assembler nach C statt. Oh..und was mich an Rust (und go) auch gewaltig stoert ist das Buildsystem! Das ist mir zu dogmatisch. Ich hab sogar letztens noch eine neue Sprache angetestet wo die Compilerbauer darauf bestehen das man kein Tab im Quelltext hat. So schnell hab ich noch nie rm getippt. Olaf
cppbert schrieb: > d.h. es lohnt sich einfach nicht mehr die Ausruckskraft von Sprachen zu > hinterfragen, zu erweitern, begrenzen? Doch. Das ist wichtig und gerade die Ausdruckskraft ist es, was m.E. die erfolgreichen von den anderen unterscheidet. Und für C++ gilt auch begrenzen sicherlich ;-)
Olaf schrieb: > Oh..und was mich an Rust (und go) auch gewaltig stoert ist das > Buildsystem! Das ist mir zu dogmatisch. Ich hab sogar letztens noch eine > neue Sprache angetestet wo die Compilerbauer darauf bestehen das man > kein Tab im Quelltext hat. So schnell hab ich noch nie rm getippt. Na offenbar bist du nicht weniger dogmatisch. Wieso bestehst du auf Tabs im Quelltext? :D
Olaf schrieb: > Oh..und was mich an Rust (und go) auch gewaltig stoert ist das > Buildsystem! Wenn du ein besseres kennst, steht es dir frei, dieses benutzen. > Ich hab sogar letztens noch eine neue Sprache angetestet wo die > Compilerbauer darauf bestehen das man kein Tab im Quelltext hat. In Sprachen wie Nim, bei denen Blöcke per Einrückung definiert werden, ist es aber auch mehr als sinnvoll, den Gebrauch von schwer voneinander unterscheidbaren Whitespace-Zeichen zu verbieten. > So schnell hab ich noch nie rm getippt. Ja, das mache ich auch immer mit Tab-verseuchtem Quellcode ;-)
Jörg W. schrieb: > Letztlich wird es damit stehen und fallen, ob es auch in der Industrie > „ankommt“, weil es in der Lage ist, in einem Projekt gegenüber C oder > C++ wirklich Entwicklungszeit zu sparen. Dazu gehört auch, dass man Experten hat/findet, die die Sprache beherrschen. Denn man wird eher nicht ein neues Entwicklungsprojekt in einer Sprache beginnen, die keiner der Mitarbeiter halbwegs beherrscht.
Olaf schrieb: > Oh..und was mich an Rust (und go) auch gewaltig stoert ist das > Buildsystem! Das ist mir zu dogmatisch. Ich hab sogar letztens noch eine > neue Sprache angetestet wo die Compilerbauer darauf bestehen das man > kein Tab im Quelltext hat. So schnell hab ich noch nie rm getippt. Dabei hat man sich extra für dich die Mühe gemacht
1 | #![allow(bad_style)] |
zu implementieren. lol
Olaf schrieb: > Ich hab sogar letztens noch eine neue Sprache angetestet wo die Compilerbauer > darauf bestehen das man kein Tab im Quelltext hat. Na endlich mal eine sinnvolle Einschränkung in einer Sprache.
nö dependent types und linear types ist das nächste große ding ;) btw ich vermisse ocaml in diesem thread
Olaf schrieb: > Ueber jede neue Sprache kannst du > nachdenken nachdem du C drauf hast und nicht umgekehrt. Bei Rust und erst recht bei Haskell ist es exakt umgekehrt: C-Denkweise ist extrem hinderlich. Anders rum wärs wesentlich einfacher und weniger schmerzhaft.
Ist das nur mein Eindruck oder relativieren viele C++ Entwickler wirklich die C++ Neuerungen die Rust ähnliche Features bringen? Einerseits wird mit der Weiterentwicklung von C++ argumentiert dass Rust nicht notwendig sei. Anderseits sehe ich aber eine massive Relativierung und mangelnde Akzeptanz der C++ Neuerungen. So heißt es manchmal dass hohe Speichersicherheit mit den neuen Mitteln nur für spezielle Fälle gut sei und man es jetzt nicht in der alltäglichen Programmierungen benötige. Man muss also erst für Militär oder Banken entwickeln damit das von Bedeutung wird? Der Rest soll halt weiter leiden mit den Folgen mangelnder Speichersicherheit und weiter Zeit und Geld dafür verlieren. Was man bei C++ also gerne relativiert und nur für spezielle Anforderungen abschiebt, um es nicht lernen und benutzen zu müssen, ist bei Rust der Standard.
SoOderSo schrieb: > Ist das nur mein Eindruck oder relativieren viele C++ Entwickler > wirklich die C++ Neuerungen die Rust ähnliche Features bringen? Das ist nicht mein Eindruck. In meinem Umfeld werden alle Neuerungen getestet und bewertet. Wenn das Kosten-Nutzen-Verhältnises für einen Anwendumgsfall stimmt, wird es genutzt. Auf welche konkrete Features beziehst du dich denn?
Bevor nicht die Platzhirsche Rust adoptieren und kommerzialisieren, werden die meisten Firmen sich mit dem Feind herumzuschlagen mit dem sie schon lange Erfahrungen haben. Abgesehen davon hat sich bis jetzt Rust nur im IT Markt(Google, Mozilla...) behauptet und nicht so viel im embedded Bereich. Was der Bauer nicht kennt frisst er nicht. Da wird sich Rust noch lange schwer tun. Auch ist die Terminologie bei Rust etwas zu esoterisch um bei Vielen anzukommen. Irgendwie passt z.B. "Crate" u.v.a. nicht in den Jargon etablierter Entwicklung. C/C++ mag seine Fußangeln zu Recht haben. Wer aber plant, bedacht und diszipliniert seine Anwendungen durchsetzt wird auch damit zuverlässige Anwendungen erstellen können. C/C++ kommt irgendwie logischer als Rust an. Der ganze Syntax um Rust herum ist abenteuerlich. Unter der Haube mag es ja vielleicht gut sein. Bis man aber dazu wirklich Vertrauen gewinnen kann, wird noch viel Wasser die Flüsse herunter fließen müssen. C/C++ hat im embedded Bereich einfach einen viel Hardware-näheren Ton und fühlt sich wie dafür gemacht an. Bei Rust ist da ein viel breiterer Abgrund. Die wahrscheinlichste Prognostik: Trotz aller Hoffnung und Erwartungen wird es genauso wie so viele andere Sprachen zuvor lange ein Nischen Dasein führen und seinen Fan Club haben. Die Industrie wird aber noch lange Zeit mit C/C++ weiter entwickeln weil dabei zu bleiben letzten Endes doch Geld spart. Es ist eben so: Der Mensch verhält sich eben wie Masse bei zunehmender Lichtgeschwindigkeit - Das Beharrungsverhalten steigt bei vielen Leuten um so mehr an je mehr man auf den Gashebel steigt.
Kompression: Dropbox macht Brotli zu Broccoli https://www.golem.de/news/kompression-dropbox-macht-brotli-zu-broccoli-2008-150075.html
1 | Der in Rust geschriebene Code der zugrundeliegenden Bibliothek |
2 | von Broccoli steht auf Github zur Verfügung. |
https://github.com/dropbox/rust-brotli#rust-brotli
Jörg W. schrieb: > Pascal und Basic rannten auf dieser Ebene nicht mit. Vielleicht wirds ja mit Object-Pascal noch was. Der FreePascal-Compiler unterstuetzt mittlerweile AVR, ARM, RISCV und Tensilica (ESP32).
W.Gates schrieb: > Das Beharrungsverhalten > steigt bei vielen Leuten um so mehr an je mehr man auf den Gashebel > steigt. Es sei mal dahingestellt ob das stimmt, aber beim Thema Programmiersprachen ist das überhaupt nicht der Punkt. Das ist als wenn man streiten würde welcher Kugelschreiber der Beste ist. Vielleicht schreibt einer ein bisschen besser als der andere, aber wer schreiben kann, kann mit jedem Kugelschreiber schreiben.
DerChris schrieb: > Das ist als wenn > man streiten würde welcher Kugelschreiber der Beste ist. Vielleicht > schreibt einer ein bisschen besser als der andere, aber wer schreiben > kann, kann mit jedem Kugelschreiber schreiben. Du hast vermutlich noch keine längeren Texte mit einem richtig guten Kugelschreiber geschrieben. Der Unterschied ist riesig.
mh schrieb: > Du hast vermutlich noch keine längeren Texte mit einem richtig guten > Kugelschreiber geschrieben. Der Unterschied ist riesig. Füller!
Zur Hilfe bei der Entscheidungsfindung für den TE habe ich auch noch eine oder zwei Anmerkungen. Eine Programmiersprache ist doch kein Freund(oder Freundin). "Jetzt hab ich einen Anderen gefunden und mache mit dem Alten schluss..." Es hält dich nichts davon ab deine alte Liebe c99 oder c11 weiterhin zu benutzen. Es ist nur ein Werkzeug, wie eine neue Zange, die besser geeignet ist um rechtwinklig zu biegen. Deswegen werfen wir doch nicht die alte Rundbiegezange weg! Ihr seht, ich kann genau so schreckliche vergleichende Beispiele wie meine Vorschreiber machen, hoffe aber die Intention, der Toolcharakter einer Sprache verdeutlicht zu haben:P Erfahrungsbericht: Ich(ganz jung:P) besitze eine VU+ Settop Box. Das Build-Ökosystem dazu benötigt ein spezifisches Linux System (Entwicklungsbedingt alt, Stabilität!) das mit OpenEmbedded dann für das Zielsystem (eine mipsel32, auch rustikal) ein Linux System mit der nötigen Paketverwaltung(wie zu erwarten, nicht das modernste, Linux: vuduo2 3.13.5) generiert. Ein kompletter Erstellungsvorgang kann schon einen halben Tag dauern und mehr als 20GB an Speicherplatz in Anspruch nehmen. Will ich mir auf die schnelle also einen IoT oder Mosquitto-Server zusammen schustern oder ein C/C++ basiertes selbst geschriebenes Tool erstellen braucht das also einen Rattenschwanz von Abhängigkeiten und jede Menge Ressourcen. Das ist völlig okay. Rust oder Go sind aber genau für solche Aufgaben prädestiniert. Also dachte ich, probier es mal aus. MIPSel ist natürlich etwas exotisch und wie zu Erwarten kam es zu Problemen. Nach 2 Tagen und ca. einer Woche Rust Erfahrung habe ich dann aktiv an der Verbesserung des OpenSSL Paketes teilgenommen. Dank der wunderbaren Community ging das recht flott und ohne Probleme. Gelernt habe ich dabei auch jede Menge. Mit relativ wenig Overhead(natürlich den Rust Compiler plus das zitierte LLVM-Backend für die Cross-Compilation) kann ich nun auf die Schnelle ein kleines Tool oder Server als Minimalbeispiel aufsetzen und darauf aufbauend entwickeln. Verschiedenes: Etwas Neues und ein frischer Wind sind eigentlich immer gut. In der (Computer-)Technik sollte man Innovation begrüßen, da sie Verbesserungen mit sich bringt und die Ängste, die man z.B. der Politik oder der Veränderung als solcher gegenüber bringt hinten anstellen. Rust ist gewöhnungsbedürftig. So wie auch das Konzept, das Speicheroperationen sicherer machen will. Das Rust Buch, https://doc.rust-lang.org/book/index.html bietet einen exzellenten Einstieg in die Materie und führt in moderne(für manche natürlich ein alter Hut) Konzepte wie Pattern Matching auf Control-Flow Basis oder Closures ein. Die Community ist flexibel und freundlich und hat mannigfaltige Interessen von System zu GUI-Programmierung über Embedded bis hin zur OS Entwicklung. Ich widerspreche hier entschieden meinem Vorgänger W.Gates, der meint bestimmen zu wollen, wie die Eltern ihr Kind benennen sollen. Das ist völlig nebensächlich und Trivia, ob etwas Crate heißt(wenn der Paketmanager sich Cargo schimpft. Haha, Wortspiel, ich lache...) und wenn dir der Scheiß mal auf die Füße fällt vergisst Du es nie wieder!!! (Dank mir und dieser Ausführung womöglich auch nicht mehr ...:P). > Der Mensch verhält sich eben wie Masse bei zunehmender Lichtgeschwindigkeit - Das Beharrungsverhalten steigt bei vielen Leuten um so mehr an je mehr man auf den Gashebel steigt. Das mag für jemanden gelten, der sich als Konservativ herausstellen will, nicht verstanden hat, dass die Lichtgeschwindigkeit konstant ist und sein eigenes Unvermögen zur Veränderung beschreibt(manchmal auch Faulheit oder fehlender Spieltrieb genannt:P). Alles Spitzfindigkeiten. Ich empfehle das ganze einfach selbst mal auszuprobieren. Die Installation ist denkbar einfach und das tooling gut. https://www.rust-lang.org/tools/install Embedded: Wer will kann sofort loslegen bei *Are we embedded yet?*: https://afonso360.github.io/rust-embedded/ Die Unterstützung ist einfach nur massiv und innovativ. Nochmal Crate: Eine Paketverwaltung kann auch schlecht sein. Bei kleinen Projekten, z.B. induziert sie mögliche Fehlerquellen und Unbekannte in den Erstellungsprozess, die besser durch Fachkenntnis und manuelle Verwaltung der (überschaubaren) Abhängigkeiten gelöst werden sollten. Das Endprodukt wird dabei stabiler, erfordert aber einen höheren Aufwand bei der Pflege. Als abschreckendes Beispiel nenne ich mal node.js und der Rattenschwanz an Unsinnigkeiten plus Sicherheitsrisiken. C/C++ Wir sollten dankbar sein. Ich sage jedenfalls nicht nein zu Tools wie clang-tidy und clang-format. Diese kommen nicht aus dem Luftleeren Raum. Die neuen Sprachen wie Rust bringen unter anderem ein ganzes Ökosystem wie rust-fmt, Dokumentation-Erstellung out of the box, benchmarking, fuzzing, testing, etc. mit sich. Das färbt auf die gute alte Mutter ab und ich finde das nicht schlecht. Als Hausaufgabe: Mal bei https://en.cppreference.com/w/cpp/compiler_support vorbei schauen und in sich gehen. Neuerungen und Verbesserungen sind ein Ding der Realität und des Fortschritts. OCaml Wer will kann C direkt mit OCaml verknüpfen, in Rust. https://caml.inria.fr/pub/docs/manual-ocaml/intfc.html + https://docs.rs/ocaml/0.14.2/ocaml/. Kein Grund also hier irgend eine gegen die andere ausspielen zu wollen:) Wenn gewollt ist Koexistenz durchaus möglich. Mozilla Ich bin gespannt ob und wie die Entlassungen Auswirkungen auf die Entwicklung von Rust haben. https://www.drwindows.de/news/mozilla-kuendigt-zahlreiche-entlassungen-und-grosse-reorganisation-an + https://blog.fefe.de/?ts=a1cd056a Fazit: Frischer Wind. Das Ausprobieren kostet nichts (außer Zeit und Nerven). Wer damit in Produktion gehen will kann das. Wer damit auf Entdeckungsreise gehen will kann das auch mit "rustup toolchain install nightly". Viel Spaß beim Entdecken:)
Ich wollte mir das eigentlich verkneifen, aber..... PLATZHIRSCHE? ... also Angeberei, Herdentrieb, Relevanz, etc. https://stackshare.io/rust https://www.rust-lang.org/production https://stackoverflow.blog/2020/01/20/what-is-rust-and-why-is-it-so-popular/ Entschuldigung. Das ist natürlich für manche ein wichtiges Thema und völlig berechtigt nach der Relevanz und Verwendung zu fragen.
Ich hab mal spasseshalber "rust" in die Suche bei Microchip eingegeben. 0 Treffer. Das kennen die nicht. https://github.com/rust-embedded/wg/issues/308 Sieht auch nicht wirklich vielversprechend aus. Und die Suchmaschine meiner Wahl liefert nicht sehr viel mit "rust pic32". OK, ich hab halbherzig gesucht. Aber wenn rust so toll ist und alle drauf abfahren (ausser mir), sollte man doch ordentlich und schnell was finden.
Beitrag #6373524 wurde von einem Moderator gelöscht.
Genau so wenig wie Microchip GCC (ausser ihr closed source gemurkse) kennt. Das ist wieder ein Teilstück vom Großen und Ganzen wo es mir jetzt wirklich schwer fällt die Schuld bei den Entwicklern von Rust zu sehen. Du kannst ja sofort damit anfangen einen hmmm, sagen wir Transpiler(damit es nicht so unmöglich erscheint) von Rust nach Embedded-C für PIC8/24/32 zu schreiben. Es hindert dich niemand daran. Genau so wenig wie dich jemand zwingt es zu benutzen. Es ist eine neue Sprache und vieles steckt in den Kinderschuhen. Euphorie und im Gegensatz Berührungsangst sind meiner Meinung nach fehl am Platz. Einfach mal ausprobieren. Das beisst nicht:) Fun fact: "Spaghetti" als Suchbegriff kennt man bei Microchip nur im "Chameleon 16-Bit User Guide", lol. Also einfach gesagt: Nick, ist das nicht ein bisschen unverschämt eine PIC Unterstützung zu verlangen? Ich mein jetzt egal von wem. Noch nicht mal dem Weihnachtsmann würde ich das zumuten. Microchip hällt ihren Stall geschlossen, also liegt das auch alleine bei ihnen etwas zu liefern. An wen auch immer. Und wirklich ? Bei 52 Repositories auf https://github.com/rust-embedded/ fällt dir das dazu ein? Das ist ein Scherz, oder?
Jedzia D. schrieb: > Genau so wenig wie Microchip GCC (ausser ihr closed source gemurkse) > kennt. Wie? Der Compiler ist GCC. Und es gibt den source. Und man kann sich die Pro-Version selbst compilieren. Ist aber auch völlig egal und hat absolut nichts mit rust zu tun. Jedzia D. schrieb: > Also einfach gesagt: Nick, ist das nicht ein bisschen unverschämt eine > PIC Unterstützung zu verlangen? Ach so. Entschuldigung! Ich dachte rust ist so toll, dass es alle verwenden sollten. OK, warum macht das dann nicht Microchip? Das wurde ihnen doch sicherlich schon 100te Male vorgetragen. Sollen sie paar Leute abstellen, die das portieren/anpassen. Genug Geld verdienen die schon um sich die paar Hanseln leisten zu können. Ganz abgesehen davon, dass dein Vorwurf ich sei unverschämt völlig verblödet ist. Aber möglicherweise muss man zur Elite gehören, um rust überhaupt mal erwähnen zu dürfen.
Ich meinte die Unverschämtheit etwas zu Erwarten, was über das Ziel hinaus schießt. Das ist völlig okay. Ich meinte nicht die Unverschämtheit deine Mitmenschen als blöde zu bezeichnen, das ist nicht okay. Es war mir weder persönlich noch besonders tot ernst wichtig. Ich selber sehe viele Mängel und Probleme bei Rust, benutze lieber Clang und GCC und bin weit davon weg ein fangirl zu sein. Elite? Ist das eine Beleidigung? ... Tut das was zur Sache? Noch mal zum Mitschreiben: Ich fand deine Argumente schlecht und ungerecht. Nicht dich als Person. Peace!
Jetzt lasst euch doch nicht so einfach provozieren... Vielleicht sollte man den thread hier sowieso mal Archivieren, ist ja schon über ein Jahr alt, und was grossartig geändert hat sich bei der Thematik in der zwischenzeit ja auch nicht wirklich was...
Jedzia D. schrieb: > Ich meinte nicht die Unverschämtheit deine Mitmenschen als blöde zu > bezeichnen, das ist nicht okay. Wo hab ich denn das gemacht? Jedzia D. schrieb: > Elite? Ist das eine Beleidigung? ... Tut das was zur Sache? Bei deiner Leerargumentation hab ich so den Eindruck, dass man Mitglied einer auserwählten Filterblase sein muss um rust verwenden zu dürfen. Gut ich hab schon mehrfach beobachtet, dass Leute darauf stolz sind etwas völlig unsinniges zu können. Z.B. elektrische Tretroller fahren zu können. Oder auf dem Handy zu tippen und über die Straße gehen zu können. Oder kein Wort C zu können, eine embedded Lösung entwickeln die billiger sein soll und dann vor den 3-fachen Kosten zu stehen und in einer Sackgasse zu stehen ohne Wendemöglichkeit. Also warum sollte ich ein Projekt das kein privates Gebastle ist, mich auf etwas einlassen, das von "meinem" µC nicht unterstützt wird?
Jedzia D. schrieb: > Das mag für jemanden gelten, der sich als Konservativ > herausstellen will, nicht verstanden hat, dass die > Lichtgeschwindigkeit konstant ist und sein eigenes > Unvermögen zur Veränderung beschreibt(manchmal auch > Faulheit oder fehlender Spieltrieb genannt:P). Die Kosten, ein Tool zu erlernen, ist hoch. Die Kosten, ein weiteres Tool von Grund auf zu erlernen, ist ebenfalls hoch. Wer neu anfängt, für den ist das kein Problem, denn alles ist "neu" und "interessant" und "cool". Wer das alles schon ein-zwei-drei mal durch hat, der hat (a) diese Kosten schon bezahlt; (b) hat erstmal sehr negatives Return-On-Investment; (c) reduziert seine vorhandenen Fähigkeit (wer eine Fremdsprache lange nicht spricht, wird erstmal objektiv schlechter). Ob das nun die "sunk-cost-fallacy" ist oder schlicht (privat)wirtschaftliches Denken, lasse ich mal offen. Spieltrieb kann sich auf verschiedene Dinge beziehen. Das können neue, coole Programmiersprachen sein oder neue, coole Algorithmen oder neue, coole Probleme. Du dampfst das auf Programmiersprachen ein. Mit 15 oder 25 sieht man die Welt anders als mit 35 oder 45.
Da hast Du recht @svenska. Mein kontra war das eine Ende des Spektrums. Wahrscheinlich ist es aber am besten die Goldene Mitte zu favorisieren, also eine gute Mischung zwischen gewohnter Stabilität und klug gewählter Neuerungen. Damit das System auch in Zukunft überlebensfähig und attraktiv bleibt.
Jedzia D. schrieb: > Du kannst ja sofort damit anfangen einen hmmm, sagen wir > Transpiler(damit es nicht so unmöglich erscheint) von Rust nach > Embedded-C für PIC8/24/32 zu schreiben. Klar ... wo kann ich nochmal nachlesen, wie die Sprache definiert ist?
Vincent H. schrieb: > Gibts nicht eh ein MIPS Backend für LLVM? https://github.com/llvm/llvm-project/tree/master/llvm/lib/Target/Mips
Rust bekommt eine Foundation: https://www.heise.de/news/Rust-Foundation-soll-Entwicklung-der-Programmiersprache-in-sichere-Bahnen-lenken-4873505.html
Moin, Jedzia D. schrieb: > Es ist nur ein Werkzeug, wie eine neue Zange, die besser > geeignet ist um rechtwinklig zu biegen. Von mir aus. Aber an der real existierenden Rust-Zange haengen halt unmittelbar und untrennbar immer auch noch eine Kuh(llvm) und ein Fahrrad(cargo). Und es muss genau die richtige Kuh und das richtige Fahrrad sein, sonst funktioniert die Rust-Zange nicht. Die Versionen von binutils, gmp, mpfr, mpc, kernel, glibc, gegen die eine gcc-Zange gebaut werden kann, sind viel unkritischer. Da muessen immer nur irgendwelche mindest/maximal-Versionsnummern passen; einen bare-metal-gcc kann man sogar voellig ohne kernel und glibc zusammenbauen. Aeltere gcc brauchen nicht mal gmp,mpfr,mpc. Deutlich flexibler, wenn man nicht zu den sudo-apt-get-install-Aeffchen gehoert. Jedzia D. schrieb: > Ich(ganz jung:P) besitze eine VU+ Settop Box. Das > Build-Ökosystem dazu benötigt ein spezifisches Linux System > (Entwicklungsbedingt alt, Stabilität!) das mit OpenEmbedded dann für das > Zielsystem (eine mipsel32, auch rustikal) ein Linux System mit der > nötigen Paketverwaltung(wie zu erwarten, nicht das modernste, Linux: > vuduo2 3.13.5) generiert. Ein kompletter Erstellungsvorgang kann schon > einen halben Tag dauern und mehr als 20GB an Speicherplatz in Anspruch > nehmen. Will ich mir auf die schnelle also einen IoT oder > Mosquitto-Server zusammen schustern oder ein C/C++ basiertes selbst > geschriebenes Tool erstellen braucht das also einen Rattenschwanz von > Abhängigkeiten und jede Menge Ressourcen. Das ist völlig okay. Nein das ist nicht okay, das ist voellige Kacke! Auch bei einem embedded linux sollte sich auf die Schnelle eine kleine Aenderung am Image machen lassen, ohne dass jedesmal wieder voellig bei 0 angefangen wird. Da erwarte ich, dass ich irgendwo eine Filestruktur rumfliegen habe, aus der das Flash-Image erstellt wird und da will ich auch gerne mal z.b. nur ein a.out, was ich per $CROSS-gcc aus einem hello.c kompiliert habe, einfach reinkopieren koennen und mir danach draus z.b. per mksquashfs oder sonstwie ein neues Image bauen koennen, ohne dass jedesmal der ganze Hoellenapparat aus wilden scripten, etc. anspringt, um allen moeglichen und unmoeglichen Scheiss neu zu bauen. Mir ist ein Ansatz wie z.b. das BLFS Book bedeutend lieber, als diese ganzen "Drueck-hier-auf-den-Knopf,dann-faellt-da-das-komplette-Image-aus"-embed dedLinux-Baukaesten. Egal ob yocto, buildroot und was es sonst noch gibt: Wenn da nur ein Furz anders ist, als von den Erbauern des script-wusts vorgesehen, geht viel zu schnell garnix mehr. Jedzia D. schrieb: > Etwas Neues und ein frischer Wind sind eigentlich immer gut. In der > (Computer-)Technik sollte man Innovation begrüßen, da sie Verbesserungen > mit sich bringt und die Ängste, die man z.B. der Politik oder der > Veränderung als solcher gegenüber bringt hinten anstellen. Nein, Neues und frischer Wind ist immer erstmal nur neu. Obs auch gut ist, muss man erstmal schauen. Es ist nicht automatisch gut, nur weil's neu ist. Aengste vor Veraenderungen sind manchmal durchaus auch berechtigt. Nur kleine Kinder denken: Uii, eine neue Herdplatte, da muss ich gleich mal mit dem Patschehaendchen drauffassen. Aeltere sind da etwas zoegerlich, obwohl neue Herdplatten per se nichts schlechtes sein muessen. Ok, ich weiss nicht, was mit C passiert waere, wenn die Bell Labs damals auch "ein paar Leute" rausgeschmissen haetten, so wie das jetzt anscheinend bei Rust und Mozilla der Fall ist. Na, wir werden es sehen... Gruss WK
Ich habe Heute im Internet ein Problem mit Rust gefunden, dass ich bisher noch nicht kannte: Das Bauen von Programmen kann sehr Resourcenintensiv sein: https://source.puri.sm/Librem5/squeekboard/-/issues/243#note_124514 > for reference: I had the kernel OOM kill the squeekboard build on a 4GB > laptop recently. The build takes longer than a kernel build with hot > ccache and needs as much disk space as the kernels git history of 2.9G. Ich frag mich, ob das wohl ein grundlegendes Architekturproblem von Rust ist, oder ob das irgendwann noch besser wird...
Mit nur 4 GB Hauptspeicher stößt auch template-lastiges C++ schnell an die Grenzen. Ein Hardcore-Programmierer, der von C++ auf Rust umsteigt, wird von dem Problem nichts merken, weil er sowieso schon 32 GB hat ;-)
Moin, Yalu X. schrieb: > Mit nur 4 GB Hauptspeicher stößt auch template-lastiges C++ schnell an > die Grenzen. Das ist aber leider nur ein schwacher Trost. So aehnlich, wie wenn der Schmerz, wenn man sich mit dem Hammer auf den Finger haut, nicht so schlimm ist, denn wenn einem dabei noch eine Dampfwalze ueber den Fuss faehrt, waere es noch schlimmer. Daniel A. schrieb: > oder ob das irgendwann noch besser wird... Sowas wuerde mich wirklich aus den Socken hauen, aber da mach' ich mir mal keine Hoffnung. Eher geht der 16Exabyte Adressraum, der sich mit 64bit Pointern adressieren laesst, zur Neige, wenn in ein paar Jahren mal mit einem Rust(nachfolger)compiler ein HelloWorld kompiliert werden muss. Gruss WK
:
Bearbeitet durch User
> Da muessen > immer nur irgendwelche mindest/maximal-Versionsnummern passen; einen > bare-metal-gcc kann man sogar voellig ohne kernel und glibc > zusammenbauen. Ist das eigentlich nur so ein Gerede oder hast du das wirklich schonmal gemacht? Ich hab das schon ein paarmal gemacht und ja man bekommt es irgendwann hin sich seinen eigene gcc crosscompiler zu uebersetzen. Aber das ist nicht mal eben so und es gibt da teilweise auch erstaunliche Versionsabhaengigkeiten. Olaf
Olaf schrieb: > Ist das eigentlich nur so ein Gerede oder hast du das wirklich schonmal > gemacht? Für AVR-GCC: ja, häufig. :) (Ist ja auch erstmal irgendwie ein Crosscompiler, und die Host-C-Library nützt einem nicht viel.) „Ohne Kernel“ ist natürlich Quatsch: irgendeine Form von OS braucht man schon, um den Host-CC laufen zu lassen. Anders als vor 25 Jahren genügt es auch nicht mehr, einen Host-CC zu haben, der noch nichtmal C89 beherrscht (wie er bspw. dazumals bei HP-UX mit ausgeliefert worden war, um ein paar Kernelmodule nachcompilieren zu können).
Es sind schon S.ooo.ooo.ooo viele Programmiersprachen aufgetaucht und wieder in der Versenkung verschwunden ohne das irgendjemand davon negativ beeinflusst wurde, keine Ahnung warum so viele Leute sich von der immer häufiger vorkommenden Werbung (Funk, Fernsehen und durch Fan Boys & Girls) für Rust so stören - das war mit Java oder .Net doch tausend mal schlimmer und davor waren es die VB-ler und Perl-Leute die uns mit der Allmacht ihrer Sprache genervt haben... Rust gibt es schon ein paar Jahren und bisher hat niemand irgendjemanden gezwungen drauf umzusteigen oder gar (Gott erbarme dich unser) eine weitere Programmiersprache dazu zu lernen, die welche keinen Bock drauf haben brauchen es nie zu nutzen und welche die auch noch 3 andere Programmiersprachen können und Bock darauf haben noch ein paar andere Sachen/Konzept-Ideen zu sehen (egal welche Relevanz das in Zukunft haben wird) machen es einfach - egal ob jemand das gut oder schlecht findet keine Argumente sind: -Was wir haben ist doch gut - das wurde von so vielen Firmen/Entwicklern die unsere Leben stark beeinflussen bestätigt (was außer krude Verschwörungstheorien soll die bitte dazu bewegen "Werbung" für etwas zu machen was denen gar nicht hilft) Nicht alle 15000 Entwickler von Google, Facebook, Microsoft etc. sind total blöde und machen nur Müll - die haben doch schon alle ihrer eigenen Super Sprachen/Plattformen - warum interessieren die sich überhaupt für eine weiter? Speziell wenn die vermeintlich nicht gut ist -Neue Programmiersprache lernen ist zu "kostenintensiv": Totaler Quatsch - man ist nicht interessiert, faul oder hat einfach keine Zeit - ist aber trotzdem kein Kontra-Argument, btw: das lernen schwierig und vielleicht unnötig ist höre ich immer nur von lernscheuem Gesindel :) - die meisten Entwickler die ich kennen die so "aktiv" argumentieren sind Eingefahren und wollen nicht mehr weiter lernen - oder sind einfach zu unerfahren um Situationen richtig zu bewerten -Läuft auf meiner Plattform nicht: den meisten geht es ehr nur um die Software-Konzepte die Rust forciert (die sind ja nicht neu) - ob der Kompiler jetzt schon alle Plattformen kann oder wird und ob guter Code generiert wird und ob das jetzt schon auf iOS oder dem Gameboy Color läuft ist völlig unrelevant, es hat bisher noch nie eine Sprache direkt auf allen Plattformen funktioniert und im Embedded Bereich dominiert C seit Jahrhunderten. Wer mit klarem Verstand denkt denn Ersthaft das man solch einen Plattform-Sprung in 5-10 Jahren erreicht - und nutzt das dann als Argument für die Qualität einer Sprache??? in Java/.Net/C/C++ wurde so viele Milliarden investiert - da kann man nicht einfach so hinterher ziehen - aber auch die kleinen brauchen mal eine Chance - oder sollen uns doch nur die großen Konzerne leiten? Einfach mal den Ball flach halten und die Fan Boys & Girls durch die Gassen marschieren lassen - vielleicht kommt ja doch was dabei raus
> Nicht alle 15000 Entwickler von Google, Facebook, Microsoft etc. sind > total blöde und machen nur Müll - die haben doch schon alle ihrer > eigenen Super Sprachen/Plattformen - warum interessieren die sich > überhaupt für eine weiter? Speziell wenn die vermeintlich nicht gut ist Noe, das sind sie sicher nicht. Die Frage ist nur was sie antreibt. Manche Sprachen werden von Einzelpersonen als Spassprojekt erfunden. Vielleicht weil sie der Scheiss den sie jeden Tag 8h in der Firma machen total abnervt. Das ist dann je nach Person, aber auch Erwartungshaltung, total genial oder ziemlicher Murks. Anderes wird aber von einer Firma entwickelt/gefordert/bezahlt. Und da kommen die Entwicklungsziele eher nicht vom Programmierer sondern von der Etage da drueber. Und was ist wohl deren Anforderung? Man darf vermuten das eines der groessten Probleme heute ist das die mittlere Faehigkeit eines Programmierers deutlich geringer ist als noch vor 20Jahren. Es gibt heute sicher noch genauso viele gute Leute wie frueher, aber da heute jeder Programmieren koennen soll der nicht bei drei auf den Baeumen ist, ist die mittlere Programmierintelligenz IMHO stark abgesunken. (siehe auch copy&paste, Webseitenprogrammierer, nicht vorhandener moralischer Kompass) Und da will man Sprachen wie C oder gar CPP nicht haben. Die lassen den Leute zuviel Freiraeume. Das ist wie eine Stadt wo man Autos ohne Geschwindigkeitsbegrenzung fahren kann. Fuer einige wenige waere es gut, fuer die meisten eher nicht. Ich persoenlich sehe durchaus auch Schwaechen in C und wuerde gerade fuer den Embedded Bereich gerne auch etwas anderes probieren. Gerne auch um mal einfach etwas anderes zu machen. Allerdings muss ich kotzen wenn ich sehe das man den Leuten dann gleich neue Buildsysteme und dauerhafte Onlinekacke aufzwingen will. Das ist die dumme Googledenke welche die Menschheit nicht braucht. Olaf
cppbert schrieb: > -Neue Programmiersprache lernen ist zu "kostenintensiv": Totaler Quatsch > - man ist nicht interessiert, faul oder hat einfach keine Zeit - ist > aber trotzdem kein Kontra-Argument Ein kluger Mann hat mal gesagt: "A language that doesn't change the way you think about programming is not worth learning". Ich kann wirklich nicht nachvollziehen warum man C++, Java, Python, Rust, etc. braucht. Man braucht ein paar Programmiersprachen - das ist alles. (Also Sprachen, mit verschiedenen Programmierparadigmen. Und keine Sprachen, die genauso funktioniert wie zwei dutzend anderer Programmiersprachen, bloss diesmal natürlich viel sicherer, einfacher und moderner) Kann man abends (wenn man Zeit hat) anschauen: https://www.youtube.com/watch?v=P2yr-3F6PQo Keine ensthafte Wissenschaft publiziert jedes Jahr x alternative Schreibweisen. Was Mathematiker vor 100 Jahren geschrieben haben, kann man auch heute noch "ausführen".
> Ich kann wirklich nicht nachvollziehen warum man C++, Java, Python, > Rust, etc. braucht. Es ist schon sinnvoll das etwas mal modernisiert wird. Sonst wuerde wir heute immer noch in Algol68 programmieren. Allerdings sollte man das nicht leuchtfertig tun. Schon garnicht im Embeddedbereich wo die grosse Dominanz von C halt auch den Vorteil hat das du alles lesen und verwenden kannst was bereits seit 20Jahren in der Firma da ist. Olaf
totaler Quatsch schrieb: > Ich kann wirklich nicht nachvollziehen warum man C++, Java, Python, > Rust, etc. braucht. Grundsätzlich versteh ich deinen Punkt. Dein Beispiel ist allerdings sehr schlecht gewählt. Zum einen ist zwar allen genannten Sprachen das Prozedurale Paradigma gemein, einige implementieren aber auch andere Paradigmen, zumindest teilweise. Viel wichtiger aber: die Technik (und somit der Einsatzbereich) der genannten Sprachen unterscheidet sich massivst. Wir haben da eine Skriptsprache, Sprachen die in nativen Maschinencode übersetzen und eine Sprache die plattformübergreifenden Bytecode für eine virtuelle Maschine liefert. In deiner Aufzählung könnte man maximal und mit viel guten Willen C++ und Rust gleichsetzen und eine davon in Frage stellen. Ansonsten vergleichst du Äpfel mit Birnen.
:
Bearbeitet durch User
Le X. schrieb: > Ansonsten vergleichst du Äpfel mit Birnen. "totaler Quatsch" halt. :-) Der Name ist Programm …
Beitrag #6456164 wurde von einem Moderator gelöscht.
Programmierbare LED's Viele von euch fragen sich ob Rust das kann: LED -> Hardware -> SETZEN, ON (nicht sechs ! :) ) Kann es ohne Probleme. Das Problem ist Mannigfaltig und von 6502 bis ,.,, weiss ich nicht. Rust ist ein Werkzeug. Ich hab nen laeppischen mips-bootloader laufen und ein Programm, dass mir iot-scheissdreck ueber meine VU+ Enigma box auf einen Gentoo Rechner mitteilt. Das passte grade gut, das in Rust zu programmieren. Netzwerk, ASIO, ggiot. Also was habt ihr fuer ein Problem, das nicht existiert? :) Are we embedded yet? https://afonso360.github.io/rust-embedded/
> Viele von euch fragen sich ob Rust das kann: Noe, das tun viele nicht. Ich kann aber hellsehen. Ungefaehr so wird es mit Rust in 20Jahren enden: https://www.heise.de/hintergrund/Forth-die-ewig-junge-Programmiersprache-4988866.html Olaf :-)
Open-Source-Projekt für Sexspielzeug wird stabil https://www.golem.de/news/buttplug-io-open-source-projekt-fuer-sexspielzeug-wird-stabil-2012-153083.html
1 | Die aktuelle Version 1.0 von Buttplug ist in Rust geschrieben und bietet |
2 | vor allem ein Kern-Paket, auf dem wiederum verschiedene Sprachanbindungen |
3 | etwa für C# und Javascript aufbauen. Laut Ankündigung dient die |
4 | Veröffentlichung vor allem dazu, künftig leichter neue Funktionen |
5 | umzusetzen und Hardware-Anbindungen zu implementieren. Dies soll künftig |
6 | nur noch einmal in Rust nötig und dann direkt in den Sprachanbindungen |
7 | nutzbar sein. Dank dem nun verfügbaren FFI können künftig auch leicht |
8 | weitere Sprachanbindungen erstellt werden. Dies hat sich die Community |
9 | bereits für Python und Java sowie Kotlin gewünscht. Letztere werden für |
10 | Android-Apps verwendet. Mithilfe von Anbindungen an C und C++ ist |
11 | außerdem die Nutzung in der Unreal Engine möglich. |
Rust 1.49.0 hebt Linux-64-Bit-ARM auf höchste Support-Stufe https://www.heise.de/news/Rust-1-49-0-hebt-Linux-64-Bit-ARM-auf-hoechste-Support-Stufe-5002855.html
1 | In der neuen Rust-Version 1.49.0 hält das Kompilierziel |
2 | aarch64-unknown-linux-gnu (64-Bit-ARM unter Linux) erstmals Einzug in |
3 | die Support-Stufe "Tier 1". Die höchste Support-Stufe war bislang |
4 | x86-Systemen vorbehalten. Ebenfalls gibt es Änderungen bei den |
5 | ARM-Plattformen von macOS und Windows sowie beim Test-Framework, |
6 | erklären die Entwickler in einem Blogeintrag. |
Sagt mal, nur so nebenbei ... wie viele von Euch werden dazu gezwungen in einem dunklen Kämmerlein zu sitzen und Rust zu programmieren? Manche Beiträge machen dann nämlich Sinn. Ansonsten: Einfach das Tool benutzen, was euch liegt, bzw. am besten zur Aufgabe und deren Lösung passt. Bitte befreit Euch von den Ketten, die euch an EINE Programmiersprache sowie eure Vorurteile fesseln. ... sonnst bekommt ihr noch Visionen. So wie Olaf;) Btw danke Olaf, der war gut:)
Jedzia D. schrieb: > Bitte befreit Euch von den Ketten, die euch an EINE Programmiersprache > sowie eure Vorurteile fesseln. Genau das machen Rust-Programmierer doch. Für kaum einen von denen wird Rust wohl die erste Sprache gewesen sein.
MaWin schrieb: > Jedzia D. schrieb: >> Bitte befreit Euch von den Ketten, die euch an EINE Programmiersprache >> sowie eure Vorurteile fesseln. > > Genau das machen Rust-Programmierer doch. > Für kaum einen von denen wird Rust wohl die erste Sprache gewesen sein. Stimmt. Und du solltest Rust mit X ersetzen. Dann können wir die Aussage wiederverwenden:P Mein "Pamphlet" richtete sich auch nicht an die Herren und Damen Rust-Programmierer, MaWin. Sondern an die Rust-Basher. Ich rede gern gegen Wände, weisst Du? Das Rust-Programmierer keine Vorurteile haben ist vielleicht ein wenig hoch gegriffen:) <- Ist ne böse Unterstellung, dass Du dich auch auf das bezogen hast.
:
Bearbeitet durch User
Moin, Schoenes Beispiel fuer real existierendes Rust: Ich will mir mal einen heif-decoder (das neue,lustige Video/Bildformat von Apple unter Linux bauen. Scheint mir in der libheif zu stecken. Die meint aber beim cmake, dass sie gerne noch den RAV1E codec haette. Oha, dett dingens (RAV1E) ist in rust geschrieben. Ich bin also nicht unbedingt scharf drauf, was in rust zu compilieren, aber wenn ich den RAV1E (oder aktuellen firefox, libsrvg, ...) unter BLFS haben will, bleibt mir wohl nix anderes uebrig. Also froehlich das git gecloned und geguckt, wie mans baut: Scheint erstmal simpel loszugehen; einfach "cargo build --release" schreiben und gucken. Oha, das zieht sich. Ich geh dann mal schlafen. zzzzZZZZZZ So, was ist denn derweilen passiert? * Wieso muss da immer Unmengen von Shice downgeloaded werden? Wenn ich das nochmal in vielleicht X Jahren bauen will, gibts die ganzen server doch nicht mehr, oder sie liegen wo ganz anders und koennen kein https mehr sondern vielleicht nur noch https-v5 oder mehr. z.b. den Bildbetrachter xv von vor 30 Jahren kann man einfach so bauen, ohne Internetverbindung. Man braucht halt die sourcen. * Ach - 's hat eh' nicht geklappt, weil mein rust schon wieder zu alt ist? Ja zum Teufel, warum kann das denn nicht frueher auffallen? Und was fuer geile Featueres sind in rustc-1.44.1 drinnen, die rustc-1.42.0 nicht hat? Und brauchts die wirklich so dringend? Komisch, die boesen,alten Autotools und auch das nicht ganz so alte cmake koenen das schon vorher sagen, wenn ihnen was nicht passt. Nicht erst nach zig Stunden bauen. So sehen meine neuesten Erfahrungen zur real existierenden rust-Welt aus. Klar, das ist vielleicht alles nicht die Sprache selbst, sondern die Umgebung, die bekloppten Programmierer, etc. Aber irgendwie ist das wie Kommunismus: Eigentlich ne Idee, die funktionieren koennte; fuehrt nur in der Praxis mit echten Menschen immer in die Katastrophe - braucht also kein Mensch. So wie rust, glaub' ich. Gruss WK
1 | root [ /usr/src/rav1e-0.4.0 ]# less doc/README.md |
2 | root [ /usr/src/rav1e-0.4.0 ]# cargo build --release |
3 | Updating crates.io index |
4 | Downloaded console v0.14.0 |
5 | Downloaded arg_enum_proc_macro v0.3.0 |
6 | Downloaded simd_helpers v0.1.0 |
7 | Downloaded y4m v0.7.0 |
8 | Downloaded signal-hook v0.3.3 |
9 | Downloaded nasm-rs v0.2.0 |
10 | Downloaded rustc_version v0.3.2 |
11 | Downloaded noop_proc_macro v0.3.0 |
12 | Downloaded cfg-if v1.0.0 |
13 | Downloaded arrayvec v0.5.2 |
14 | Downloaded bitstream-io v1.0.0 |
15 | Downloaded paste v1.0.4 |
16 | Downloaded rayon v1.5.0 |
17 | Downloaded cc v1.0.66 |
18 | Downloaded scan_fmt v0.2.5 |
19 | Downloaded num-derive v0.3.3 |
20 | Downloaded num-traits v0.2.14 |
21 | Downloaded rust_hawktracer v0.7.0 |
22 | Downloaded itertools v0.10.0 |
23 | Downloaded chrono v0.4.19 |
24 | Downloaded av-metrics v0.6.2 |
25 | Downloaded thiserror v1.0.23 |
26 | Downloaded regex v1.4.3 |
27 | Downloaded fern v0.6.0 |
28 | Downloaded time v0.1.43 |
29 | Downloaded rust_hawktracer_proc_macro v0.4.1 |
30 | Downloaded terminal_size v0.1.15 |
31 | Downloaded proc-macro2 v1.0.24 |
32 | Downloaded rust_hawktracer_normal_macro v0.4.1 |
33 | Downloaded thiserror-impl v1.0.23 |
34 | Downloaded signal-hook-registry v1.3.0 |
35 | Downloaded either v1.6.1 |
36 | Downloaded lab v0.8.2 |
37 | Downloaded quote v1.0.8 |
38 | Downloaded syn v1.0.58 |
39 | Downloaded num-integer v0.1.44 |
40 | Downloaded semver v0.11.0 |
41 | Downloaded rayon-core v1.9.0 |
42 | Downloaded crossbeam-deque v0.8.0 |
43 | Downloaded crossbeam v0.8.0 |
44 | Downloaded log v0.4.13 |
45 | Downloaded libc v0.2.82 |
46 | Downloaded memchr v2.3.4 |
47 | Downloaded semver-parser v0.10.2 |
48 | Downloaded num_cpus v1.13.0 |
49 | Downloaded thread_local v1.1.0 |
50 | Downloaded regex-syntax v0.6.22 |
51 | Downloaded crossbeam-utils v0.8.1 |
52 | Downloaded aho-corasick v0.7.15 |
53 | Downloaded crossbeam-channel v0.5.0 |
54 | Downloaded crossbeam-queue v0.3.1 |
55 | Downloaded pest v2.1.3 |
56 | Downloaded crossbeam-epoch v0.9.1 |
57 | Downloaded ucd-trie v0.1.3 |
58 | Downloaded scopeguard v1.1.0 |
59 | Downloaded const_fn v0.4.5 |
60 | Downloaded memoffset v0.6.1 |
61 | Compiling autocfg v1.0.1 |
62 | Compiling libc v0.2.82 |
63 | Compiling lazy_static v1.4.0 |
64 | Compiling cfg-if v1.0.0 |
65 | Compiling proc-macro2 v1.0.24 |
66 | Compiling const_fn v0.4.5 |
67 | Compiling unicode-xid v0.2.1 |
68 | Compiling scopeguard v1.1.0 |
69 | Compiling syn v1.0.58 |
70 | Compiling rayon-core v1.9.0 |
71 | Compiling memchr v2.3.4 |
72 | Compiling bitflags v1.2.1 |
73 | Compiling either v1.6.1 |
74 | Compiling ucd-trie v0.1.3 |
75 | Compiling regex-syntax v0.6.22 |
76 | Compiling log v0.4.13 |
77 | Compiling arrayvec v0.5.2 |
78 | Compiling unicode-width v0.1.8 |
79 | Compiling signal-hook v0.3.3 |
80 | Compiling noop_proc_macro v0.3.0 |
81 | Compiling cfg-if v0.1.10 |
82 | Compiling rust_hawktracer_proc_macro v0.4.1 |
83 | Compiling lab v0.8.2 |
84 | Compiling rust_hawktracer_normal_macro v0.4.1 |
85 | Compiling bitstream-io v1.0.0 |
86 | Compiling scan_fmt v0.2.5 |
87 | Compiling paste v1.0.4 |
88 | Compiling y4m v0.7.0 |
89 | Compiling crossbeam-utils v0.8.1 |
90 | Compiling num-traits v0.2.14 |
91 | Compiling memoffset v0.6.1 |
92 | Compiling num-integer v0.1.44 |
93 | Compiling rayon v1.5.0 |
94 | Compiling thread_local v1.1.0 |
95 | Compiling itertools v0.10.0 |
96 | Compiling pest v2.1.3 |
97 | Compiling textwrap v0.11.0 |
98 | Compiling rust_hawktracer v0.7.0 |
99 | Compiling ivf v0.1.1 (/usr/src/rav1e-0.4.0/ivf) |
100 | Compiling semver-parser v0.10.2 |
101 | Compiling time v0.1.43 |
102 | Compiling num_cpus v1.13.0 |
103 | Compiling jobserver v0.1.21 |
104 | Compiling signal-hook-registry v1.3.0 |
105 | Compiling terminal_size v0.1.15 |
106 | Compiling quote v1.0.8 |
107 | Compiling aho-corasick v0.7.15 |
108 | Compiling clap v2.33.3 |
109 | Compiling semver v0.11.0 |
110 | Compiling fern v0.6.0 |
111 | Compiling crossbeam-channel v0.5.0 |
112 | Compiling crossbeam-queue v0.3.1 |
113 | Compiling crossbeam-epoch v0.9.1 |
114 | Compiling cc v1.0.66 |
115 | Compiling simd_helpers v0.1.0 |
116 | Compiling regex v1.4.3 |
117 | Compiling rustc_version v0.3.2 |
118 | Compiling chrono v0.4.19 |
119 | Compiling crossbeam-deque v0.8.0 |
120 | Compiling num-derive v0.3.3 |
121 | Compiling thiserror-impl v1.0.23 |
122 | Compiling arg_enum_proc_macro v0.3.0 |
123 | Compiling console v0.14.0 |
124 | Compiling vergen v3.0.4 (/usr/src/rav1e-0.4.0/crates/vergen) |
125 | Compiling crossbeam v0.8.0 |
126 | Compiling v_frame v0.2.0 (/usr/src/rav1e-0.4.0/v_frame) |
127 | Compiling thiserror v1.0.23 |
128 | Compiling nasm-rs v0.2.0 |
129 | Compiling av-metrics v0.6.2 |
130 | Compiling rav1e v0.4.0 (/usr/src/rav1e-0.4.0) |
131 | error: failed to run custom build command for `rav1e v0.4.0 (/usr/src/rav1e-0.4.0)` |
132 | |
133 | Caused by: |
134 | process didn't exit successfully: `/usr/src/rav1e-0.4.0/target/release/build/rav1e-dc076fced3f1ff91/build-script-build` (exit code: 1) |
135 | --- stderr |
136 | rav1e requires rustc >= 1.44.1. |
137 | |
138 | root [ /usr/src/rav1e-0.4.0 ]# rustc --version |
139 | rustc 1.42.0 |
> * Wieso muss da immer Unmengen von Shice downgeloaded werden? Wenn ich > das nochmal in vielleicht X Jahren bauen will, gibts die ganzen server > doch nicht mehr, oder sie liegen wo ganz anders und koennen kein https Als mir dies aufgefallen ist hab ich den Krempel von meiner Platte geloescht. Das mag ich selbst beim rumspielen zuhause nicht, im professionellem Umfeld ist es geradzu absurd. Wobei ich noch das Bonusproblem hatte das er erst mit meiner cmake-Version unzufrieden war. Die Scriptkiddies die mittlerweile aus den Unis kommen koennen nur noch mit der Version von gestern und unter 100 libaries von Hinz und Kunz kriegen sie auch nix mehr gebacken. Die muessen erst noch lernen das sie mit ihren Betas zuhause rumspielen sollten und erst dann etwas veroeffentlichen wenn es geht. Aber das ist jetzt kein spezielles Problem von Rust sondern gilt fuer aktuelle Softwareentwicklung allgemein. Olaf
Dergute W. schrieb: > So, was ist denn derweilen passiert? > * Wieso muss da immer Unmengen von Shice downgeloaded werden? Wenn ich > das nochmal in vielleicht X Jahren bauen will, gibts die ganzen server > doch nicht mehr, oder sie liegen wo ganz anders und koennen kein https > mehr sondern vielleicht nur noch https-v5 oder mehr. z.b. den > Bildbetrachter xv von vor 30 Jahren kann man einfach so bauen, ohne > Internetverbindung. Man braucht halt die sourcen. Ja. Man braucht halt die Sourcen. Inklusive der Sourcen der Dependencies. Merkste was? In deinem Cargo cache liegen die ganzen Sourcen. Und dort liegen sie, bis du sie löschst. Du musst also in 30 Jahren gar nicht alles wieder herunterladen, wenn du es nicht gelöscht hast. Ganz ohne Internetverbindung.
Moin, MaWin schrieb: > Ja. Man braucht halt die Sourcen. Inklusive der Sourcen der > Dependencies. > Merkste was? > In deinem Cargo cache liegen die ganzen Sourcen. Und dort liegen sie, > bis du sie löschst. Ja, ich merk' was; ich bau schon seit >10 Jahren B/LFSse und merk' von daher schon, wo die Reise hingeht. Und ob mir das gefaellt. Wenn ich mir einen ffmpeg oder vlcplayer oder sonstwas mit vielen Abhaengigkeiten bau', dann sagen mir autotools und cmake VORHER, was sie beoetigen. In welcher Version. Und obs dringend ist oder eher nicht so. Und wenn ich z.b. im ffmpeg keinen shclonzen3-codec drinnenhaben will, dann kann ich ffmpeg auch ohne libshclonzen3 prima bauen. Und ich weiss, dass, wenn ich dann shclonzen3 support haben will, ich ffmpeg nochmal bauen kann, nachdem ich die libshclonzen3 sourcen runtergeladen und diese lib in der von mir gewuenschten Geschmacksrichtung (static/shared, debug/release, mit/ohne weitere Abhaengigkeiten, wie libbla, libblubber, ...) gebaut habe. Und wenn das buildsystem richtig gut ist, dann muss ich nichtmal alles beim ffmpeg neu bauen, sondern nur die durch die libshclonzen3 betroffenen Files. Und wenns super gut laeuft, dann kann ich das sogar crosscompilieren. Und nach einem Jahr, wenn ich das alles vergessen hab', guck ich in die config.log und sehe sofort exakt die Kommandozeile, mit der ich das konfiguriert habe. Das alles weiss ich (zu schaetzen). Trotzdem und deswegen stoert es mich, dass jetzt jede grad' hippe software/sprache meint, ihren eigenen Paketmanager oder gar build-umgebung, etc. bla. mitbringen zu muessen. Was der sudo-apt-get-install oder setup.exe Klicker nicht nachvollziehen kann. Was mir aber wurscht ist. Es stoert mich trotzdem. Gruss WK
was für ein Geheulte :) 1. Die Sprache und die ganze Infrastruktur ist noch jung - auch mit 5 Jahren noch, die Ideen mit Cargo kennt man aber so von .Net, Java, Python und mitlerweile sogar mit C/C++ - es ist eben noch nicht ganz so super perfekt rund - und das ist jedem Absolut klar 2. Cargo muss nicht unbedingt ins Internet - der kann auch lokal auf deinen eigenen feinst erwählten Crates orgeln 3. Es gibt eine Cache 4. Anstatt das jedes noch so kleine Projekt Self-Contained ist baut Rust einfach darauf das sich die Code-Duplikation über viele, gut gepflegte Libraries reduziert die in den heutigen Projekten in Mio Zeilen Code rumgurken Jede Library hat die 5000.Implementation von irgendeinem Micro-Scheiss im Bauch die so viel Pflege-Energie frisst - das versucht Rust mit einer Zerlege- es-in-Libs-und-verteile-die-leicht zu reduzieren
Dergute W. schrieb: > dann sagen mir autotools und cmake VORHER, was sie > beoetigen. cargo check > In welcher Version. Und obs dringend ist oder eher nicht so. > Und wenn ich z.b. im ffmpeg keinen shclonzen3-codec drinnenhaben will, > dann kann ich ffmpeg auch ohne libshclonzen3 prima bauen. Und ich weiss, > dass, wenn ich dann shclonzen3 support haben will, ich ffmpeg nochmal > bauen kann, nachdem ich die libshclonzen3 sourcen runtergeladen und > diese lib in der von mir gewuenschten Geschmacksrichtung Das nennt sich "features" in cargo. > Trotzdem und deswegen stoert es mich, dass jetzt jede grad' hippe > software/sprache meint, ihren eigenen Paketmanager oder gar > build-umgebung, etc. bla. mitbringen zu muessen. Weil es so gut funktioniert, oder warum? Zu sagen autotools wären besser als cargo zeugt von einer enormen Unkenntnis.
cppbert schrieb: > Jede Library hat die 5000.Implementation von irgendeinem Micro-Scheiss > im Bauch die so viel Pflege-Energie frisst - das versucht Rust mit einer > Zerlege- es-in-Libs-und-verteile-die-leicht zu reduzieren Damit ist man den Pflegeaufwand aber nicht los geworden, sondern verlegt ihn nur woanders hin. Du musst regelmäßig die Abhängigkeiten prüfen, ob da noch alles so funktioniert wie es soll, keine neuen unerwarteten Abhängigkeiten dazu gekommen sind, die Qualität noch deinen Anforderungen entspricht, kein Urheberrecht verletzt wird ...
mh schrieb: > Du musst regelmäßig die Abhängigkeiten prüfen, ob > da noch alles so funktioniert wie es soll, Quatsch. Dank semantic versioning ist das natürlich nicht notwendig. Du bekommst automatisch alle rückwärtskompatiblen Weiterentwicklungen und Fixes.
MaWin schrieb: > mh schrieb: >> Du musst regelmäßig die Abhängigkeiten prüfen, ob >> da noch alles so funktioniert wie es soll, > > Quatsch. > Dank semantic versioning ist das natürlich nicht notwendig. > Du bekommst automatisch alle rückwärtskompatiblen Weiterentwicklungen > und Fixes. Dieses magic "semantic versioning" beseitigt also alle Probleme, ohne dass man etwas dafür tun muss?
mh schrieb: > Dieses magic "semantic versioning" beseitigt also alle Probleme, ohne > dass man etwas dafür tun muss? Schaue es dir halt mal an, bevor du hier Dünnschiss verzapfst.
MaWin schrieb: > mh schrieb: >> Dieses magic "semantic versioning" beseitigt also alle Probleme, ohne >> dass man etwas dafür tun muss? > > Schaue es dir halt mal an, bevor du hier Dünnschiss verzapfst. Wie soll ich mir das anschauen, ohne eine größeres Projekt damit selbst zu verwalten?
mh schrieb: > cppbert schrieb: >> Jede Library hat die 5000.Implementation von irgendeinem Micro-Scheiss >> im Bauch die so viel Pflege-Energie frisst - das versucht Rust mit einer >> Zerlege- es-in-Libs-und-verteile-die-leicht zu reduzieren > > Damit ist man den Pflegeaufwand aber nicht los geworden, sondern verlegt > ihn nur woanders hin. nicht nur - man schafft auch eine Kultur(die dann irgendwann tief verwurzelt ist) das nicht jeder alles selber macht um die Self-Contained Ehre hoch zu halten... das reduziert auf den weltweiten Code Mio Zeilen die keiner braucht und welche die Interaktion zwischen Projekten erschweren > Du musst regelmäßig die Abhängigkeiten prüfen, ob > da noch alles so funktioniert wie es soll, keine neuen unerwarteten > Abhängigkeiten dazu gekommen sind, die Qualität noch deinen > Anforderungen entspricht, kein Urheberrecht verletzt wird ... so lange sich die Version nicht ändert gibts keine Änderung - thats it! Wer diese Kultur bricht kommt in die Hölle und man könnte die Lizenz oder git Hash, svn Revision ja noch als Optionales Plugin mit ins spiel bringen (Key und Quelle der Daten) - ob du dann dich direkt mit den Internet verlinkst oder nur lokal mit deinen selbst gewählten Crates arbeitest ist dein Bier
mh schrieb: > MaWin schrieb: >> mh schrieb: >>> Du musst regelmäßig die Abhängigkeiten prüfen, ob >>> da noch alles so funktioniert wie es soll, >> >> Quatsch. >> Dank semantic versioning ist das natürlich nicht notwendig. >> Du bekommst automatisch alle rückwärtskompatiblen Weiterentwicklungen >> und Fixes. > > Dieses magic "semantic versioning" beseitigt also alle Probleme, ohne > dass man etwas dafür tun muss? natürlich nicht - aber es steht auch nirgends das es jetzt so für die nächsten 20 Jahre bleibt es fehlt noch mehr Variants in den Quellen oder der Zuordnung - vielleicht will ich ja keine Version sondern einen bestimmt git-hash usw., die Quellen-Lokation ist noch ein wenig zu strikt
cppbert schrieb: > nicht nur - man schafft auch eine Kultur(die dann irgendwann tief > verwurzelt ist) das nicht jeder alles selber macht um die Self-Contained > Ehre hoch zu halten... das reduziert auf den weltweiten Code Mio Zeilen > die keiner braucht und welche die Interaktion zwischen Projekten > erschweren Das sorgt aber auch für eine Kultur, in der sich jeder darauf verlässt, dass das was man im cargo findet korrekt und sicher ist. cppbert schrieb: > so lange sich die Version nicht ändert gibts keine Änderung - thats it! > Wer diese Kultur bricht kommt in die Hölle Wenn ich keine Version ändere habe ich aber auch keinen wirklichen Vorteil. Und wenn ich eine Version ändere, muss ich trotzdem alles selbst prüfen.
mh schrieb: > Und wenn ich eine Version ändere, muss ich trotzdem alles > selbst prüfen. Nochmal: Völliger Unsinn. Google: semantic versioning
MaWin schrieb: > mh schrieb: >> Und wenn ich eine Version ändere, muss ich trotzdem alles >> selbst prüfen. > > Nochmal: Völliger Unsinn. > > Google: semantic versioning Ja MaWin, ich kann lesen und ich weiß was Semantic Versioning ist. Kannst du mir jetzt endlich erklären, wie das eins der Problem löst, wenn ich die Version von etwas ändern möchte oder muss? Wie übernimmt Semantic Versioning die Arbeit, die ich dann machen muss?
mh schrieb: > Wenn ich keine Version ändere habe ich aber auch keinen wirklichen > Vorteil. Und wenn ich eine Version ändere, muss ich trotzdem alles > selbst prüfen. Das erinnert mich an die Einstellung, wie man vor 20 Jahren Software entwickelte. Da blieb man jahrelang auf der gleichen Compilerversion, da die ja schliesslich funktionierte und erprobt sei. Alle später veröffentlichten Versionen konnte man nicht trauen, schliesslich könnten ja neue Fehler mit reingekommen sein, etc. :)
mh schrieb: > Das sorgt aber auch für eine Kultur, in der sich jeder darauf verlässt, > dass das was man im cargo findet korrekt und sicher ist. für Normale Entwickler vielleicht schon, die ziehen aber auch alles was kreucht und fleucht, aber nicht unbedingt im prof. Umfeld
mh schrieb: > Kannst du mir jetzt endlich erklären, wie das eins der Problem löst, > wenn ich die Version von etwas ändern möchte oder muss? Wie übernimmt > Semantic Versioning die Arbeit, die ich dann machen muss? wenn du einen Versions-Wechsel machst ändert doch Rust nichts an den Folgenotwendigekeiten? du musst immer noch prüfen ob die Interfaces passen, deine Tests laufen und ob die Lizenz noch zu dir passt? oder was meinst du?
Operator S. schrieb: > Alle später > veröffentlichten Versionen konnte man nicht trauen, schliesslich könnten > ja neue Fehler mit reingekommen sein, etc. :) Hast du das noch nie erlebt? Scheinbar nicht.
mh schrieb: > Wenn ich keine Version ändere habe ich aber auch keinen wirklichen > Vorteil. Und wenn ich eine Version ändere, muss ich trotzdem alles > selbst prüfen. ist ja auch nur ein Distribution-Konzept keine alles-geht-automatisch Lösung mehr ist es bisher nicht
cppbert schrieb: > mh schrieb: >> Wenn ich keine Version ändere habe ich aber auch keinen wirklichen >> Vorteil. Und wenn ich eine Version ändere, muss ich trotzdem alles >> selbst prüfen. > > ist ja auch nur ein Distribution-Konzept keine alles-geht-automatisch > Lösung > mehr ist es bisher nicht Zugangsproblem für Normalos ist immer - ich bekomme die Lib nicht zum Linken/Kompilieren etc. Solche Probleme haben .Net, Java, ... nicht und das macht für viele den Zugang schwer
Operator S. schrieb: > mh schrieb: >> Wenn ich keine Version ändere habe ich aber auch keinen wirklichen >> Vorteil. Und wenn ich eine Version ändere, muss ich trotzdem alles >> selbst prüfen. > > Das erinnert mich an die Einstellung, wie man vor 20 Jahren Software > entwickelte. Da blieb man jahrelang auf der gleichen Compilerversion, da > die ja schliesslich funktionierte und erprobt sei. Alle später > veröffentlichten Versionen konnte man nicht trauen, schliesslich könnten > ja neue Fehler mit reingekommen sein, etc. :) Nur, dass ich explizit die Version ändern möchte und den Arbeitsaufwand dafür kenne und weiß, dass mir cargo dabei nicht hilft. cppbert schrieb: > mh schrieb: >> Kannst du mir jetzt endlich erklären, wie das eins der Problem löst, >> wenn ich die Version von etwas ändern möchte oder muss? Wie übernimmt >> Semantic Versioning die Arbeit, die ich dann machen muss? > > wenn du einen Versions-Wechsel machst ändert doch Rust nichts an den > Folgenotwendigekeiten? du musst immer noch prüfen ob die Interfaces > passen, deine Tests laufen und ob die Lizenz noch zu dir passt? > > oder was meinst du? Du scheinst es so langsam verstanden zu haben. Wenn ich eine Version ändern möchte, hilft mir cargo nicht wirklich. Der große Teil der Arbeit liegt im Überprüfen der Änderungen, nicht im ändern der Versionsnummer für den wie auch immer organisierten Download. Ich schreib weiterhin "Kleinkram" selbst, mit allen Rechten und Pflichten, statt mich 2 Mal im Jahr durch die Doku in cargo und co quälen zu müssen, nur um am Ende mit weniger Rechten da zu stehen.
Also das Problem sehe ich auch. Man kann ohne Aufwand einfach Abhängigkeiten hinzufügen, diese rekursive runterladen & updaten lassen. Dadurch hat man schnell viele Abhängigkeiten. Mit mehr & öfters ändernden Abhängigkeiten ist die Qualitätskontrolle sehr schwierig. Und die müsste ja eigentlich im Idealfall von jedem Entwickler bei jeder Änderung erflogen. Scheint aber wohl heutzutage nicht mehr in zu sein...
Nick M. schrieb: > Hast du das noch nie erlebt? Scheinbar nicht. Doch, ich glaube mich wiederholen zu müssen, aber so vor 20 Jahren war das gang und gäbe. Seitdem haben die Tools und Software-Arbeitsprozesse aber einen erheblichen Fortschritt gemacht und man kann sich darauf verlassen, was drauf steht. Natürlich gibt es einige Firmen und noch mehr Einzelpersonen, die diese Entwicklung nicht mitgemacht haben. Die lernt man aber schnell zu meiden.
cppbert schrieb: > wenn du einen Versions-Wechsel machst ändert doch Rust nichts an den > Folgenotwendigekeiten? Ich weiß nicht wo dein Problem ist und wo das etwas mit Rust oder Cargo zu tun hätte. Kompatible Updates (Bugfixes) gehen mit Cargo dank Semantic Versioning halbautomatisch. Das einzige, was man tun muss, ist "cargo update". Wenn du auf eine inkompatible Version wechseln willst, dann hat der Aufwand überhaupt nichts mit Cargo zu tun und ist bei jeder Programmiersprache in etwa gleich groß.
Operator S. schrieb: > Nick M. schrieb: >> Hast du das noch nie erlebt? Scheinbar nicht. > > Doch, ich glaube mich wiederholen zu müssen, aber so vor 20 Jahren war > das gang und gäbe. > > Seitdem haben die Tools und Software-Arbeitsprozesse aber einen > erheblichen Fortschritt gemacht und man kann sich darauf verlassen, was > drauf steht. > Natürlich gibt es einige Firmen und noch mehr Einzelpersonen, die diese > Entwicklung nicht mitgemacht haben. Die lernt man aber schnell zu > meiden. Welches Tool stellt denn sicher, dass alle meine Abhängigkeiten nach dem Update weiterhin eine kompatible Lizenz haben? Welches Tool stellt sicher, dass keins der Projekte von denen ich abhängig bin gehackt wurde? Welches Tool stellt sicher, dass es keine bekannte gravierende ungefixete Sicherheitslücke in meinen Abhängigkeiten gibt? ...
MaWin schrieb: > Kompatible Updates (Bugfixes) gehen mit Cargo dank Semantic Versioning > halbautomatisch. Er spricht nicht von der technischen Hürde eine Version zu ändern, sondern vom Vertrauen in die Packages. Kein Wunder kommen Embedded Projekte nicht vom Fleck, wenn jeder sein eigenes Gärtchen beackert.
Operator S. schrieb: > Er spricht nicht von der technischen Hürde eine Version zu ändern, > sondern vom Vertrauen in die Packages. Warum sollte ein Paket mit einer neuen Version plötzlich unvertrauenswürdig werden? Auf crates.io kann zwar initial jeder alles hochladen, aber nicht als Folgeversion.
MaWin schrieb: > Kompatible Updates (Bugfixes) gehen mit Cargo dank Semantic Versioning > halbautomatisch. Das einzige, was man tun muss, ist "cargo update". Qualitätssicherung sollte schon etwas mehr beinhalten, als nur "kompiliert noch"...
MaWin schrieb: > cppbert schrieb: >> wenn du einen Versions-Wechsel machst ändert doch Rust nichts an den >> Folgenotwendigekeiten? > > Ich weiß nicht wo dein Problem ist und wo das etwas mit Rust oder Cargo > zu tun hätte. > Kompatible Updates (Bugfixes) gehen mit Cargo dank Semantic Versioning > halbautomatisch. Das einzige, was man tun muss, ist "cargo update". > Wenn du auf eine inkompatible Version wechseln willst, dann hat der > Aufwand überhaupt nichts mit Cargo zu tun und ist bei jeder > Programmiersprache in etwa gleich groß. Du hast vermutlich das Problem nicht verstanden. Ich muss trotzdem nachgucken, was geändert wurde, wer es geändert hat und vor allem, ob "deren" Meinung von "kompatibles Update" mit meiner Meinung übereinstimmt.
mh schrieb: > Welches Tool stellt denn sicher, dass alle meine Abhängigkeiten nach dem > Update weiterhin eine kompatible Lizenz haben? Semantic Versioning. > Welches Tool stellt > sicher, dass keins der Projekte von denen ich abhängig bin gehackt > wurde? Welches Tool stellt sicher, dass es keine bekannte gravierende > ungefixete Sicherheitslücke in meinen Abhängigkeiten gibt? ... Das hat doch alles überhaupt nichts mit Rust zu tun. Gleiches gilt für alle Software. Auch z.B. ganz klassische Linux-Distributionen. Warum zündest du diese Nebelkerzen?
🐧 DPA 🐧 schrieb: > Qualitätssicherung sollte schon etwas mehr beinhalten, als nur > "kompiliert noch"... Ja und? Dann mache doch deine Qualitätsprüfungen? Wo ist denn jetzt das Problem? Und wo unterscheidet sich das von jeder anderen Software, die nicht Rust/Cargo nutzt?
mh schrieb: > Du hast vermutlich das Problem nicht verstanden. Ich muss trotzdem > nachgucken, was geändert wurde, wer es geändert hat und vor allem, ob > "deren" Meinung von "kompatibles Update" mit meiner Meinung > übereinstimmt. Du musst überhaupt nichts. Wenn du das prüfen willst, dann steht es dir frei das alles zu prüfen. Dann beschwere dich aber bitte nicht, dass das viel Arbeit ist.
Operator S. schrieb: > Doch, ich glaube mich wiederholen zu müssen, aber so vor 20 Jahren war > das gang und gäbe. So weit muss ich da nicht zurückdenken. Mir genügen 3 Jahre.
MaWin schrieb: > mh schrieb: >> Welches Tool stellt denn sicher, dass alle meine Abhängigkeiten nach dem >> Update weiterhin eine kompatible Lizenz haben? > > Semantic Versioning. Schön, dass du einer Versionsnummer blind vertraust. MaWin schrieb: >> Welches Tool stellt >> sicher, dass keins der Projekte von denen ich abhängig bin gehackt >> wurde? Welches Tool stellt sicher, dass es keine bekannte gravierende >> ungefixete Sicherheitslücke in meinen Abhängigkeiten gibt? ... > > Das hat doch alles überhaupt nichts mit Rust zu tun. > Gleiches gilt für alle Software. Auch z.B. ganz klassische > Linux-Distributionen. Ich verkaufe keine Linux Distribution ... MaWin schrieb: > Und wo unterscheidet sich das von jeder anderen Software, die nicht > Rust/Cargo nutzt? Ja endlich! Du hast erkannt, dass es sich nicht unterscheidet. Damit sind wir bei meinem ursprünglichen Beitrag ... mh schrieb: > cppbert schrieb: >> Jede Library hat die 5000.Implementation von irgendeinem Micro-Scheiss >> im Bauch die so viel Pflege-Energie frisst - das versucht Rust mit einer >> Zerlege- es-in-Libs-und-verteile-die-leicht zu reduzieren > > Damit ist man den Pflegeaufwand aber nicht los geworden, sondern verlegt > ihn nur woanders hin. MaWin schrieb: > Wenn du das prüfen willst, dann steht es dir frei das alles zu prüfen. Meine Kunden erwarten, dass ich das für die Software, die ich entwickle, prüfe. Dafür Zahlen sie mir Geld ...
MaWin schrieb: > 🐧 DPA 🐧 schrieb: >> Qualitätssicherung sollte schon etwas mehr beinhalten, als nur >> "kompiliert noch"... > > Ja und? > Dann mache doch deine Qualitätsprüfungen? > Wo ist denn jetzt das Problem? 🐧 DPA 🐧 schrieb: > Man kann ohne Aufwand einfach > Abhängigkeiten hinzufügen, diese rekursive runterladen & updaten lassen. > Dadurch hat man schnell viele Abhängigkeiten. Mit mehr & öfters > ändernden Abhängigkeiten ist die Qualitätskontrolle sehr schwierig. Und > die müsste ja eigentlich im Idealfall von jedem Entwickler bei jeder > Änderung erflogen. Scheint aber wohl heutzutage nicht mehr in zu sein... MaWin schrieb: > Und wo unterscheidet sich das von jeder anderen Software, die nicht > Rust/Cargo nutzt? Darin, dass es einen Anreiz gibt, unnötige Abhängigkeiten zu vermeiden, und diese weniger leichtfertig verwendet werden. Man setzt sich eher damit auseinander. MaWin schrieb: > Gleiches gilt für alle Software. Auch z.B. ganz klassische > Linux-Distributionen. In besondere bei Debian gibt es strikte Kriterien, denen ein Packet gerecht werden muss, um in Debian rein zu kommen, und drin zu bleiben. Fehler müssen z.B. behoben werden, basierend ob proprietäre Software benötigt wird wird es anders einsortiert, usw. Das ist eine zusätzliche Qualitätssicherung.
Es ist klar das durch so ein Package-System sehr viele Dependencies entstehen können - aber es ist auch klar das kleinere, vielgenutzte Libs eine höhrere Qualität/Testgrad aufweisen als wenige monolithen Nicht anders machen wir es doch auch innerhalb unserer eigenen Software, viele kleine, gut getestete Komponenten - die sogar mit anderen Abteilungen geshared werden (sollten) Es ist klar das eine Handvoll externen Abhängigkeiten die als monolith entwickelt werden leichter kontrollierbar sind - aber auch nur weil die sich oft ihres Umfangs wegen weniger schneller entwickeln (was nicht unbedingt gesund oder ungesund ist) Ich finde es z.B. ziemlich beeindrucken das Rust mit den Nightly Builds einen grossteil der public verfügbaren Crates als Regressions-Test baut, dauert weil Rust so fiese langsam ist eben 4 Tage, aber stell euch mal vor wie aufwändig das wäre mit Github und C/C++ Projekten zu erreichen - wenn wir die Menge an Buildsystemen/Varianten mit einbeziehen ist das faktisch nicht möglich ohne permanente Handarbeit
mh schrieb: > Du hast vermutlich das Problem nicht verstanden. Ich muss trotzdem > nachgucken, was geändert wurde, wer es geändert hat und vor allem, ob > "deren" Meinung von "kompatibles Update" mit meiner Meinung > übereinstimmt. das ist doch noch alles gar nicht fertig, warum so drauf rumreiten? wenn das Semantic Versioning sauber durchgezogen wird erkennst du inkompatibilität an der Version - wenn das nicht sauber durchgezogen wird ists Müll Aber was garantiert dir denn bitte bei irgendeiner Lib das dort die Changelogs sauber sind - das geht doch nur wenn die Menge an Third-parties klein ist oder du deinen Pappenheimer genau kennst - schön für dein Programm? was ist mit den andere 40 Projekten die andere Dependencies haben und vielleicht nicht so einen klugen Entwickler wie dich an der Leitung - da ist es genau so glück das alles richtig funktioniert, richtig geprüft wird Wenn man immer nur auf sein kleinen Bereich schaut ist alles egal - aber frage mal einen Software-Projekt-Manager der zig Projekte und Teams unter sich hat...
cppbert schrieb: > wenn das Semantic Versioning sauber durchgezogen wird erkennst du > inkompatibilität an der Version - wenn das nicht sauber durchgezogen > wird ists Müll Wenn du dem nicht vertraust, dann nutze es nicht und prüfe alles manuell. Meine Güte. Deine Entscheidung.
🐧 DPA 🐧 schrieb: > Mit mehr & öfters > ändernden Abhängigkeiten ist die Qualitätskontrolle sehr schwierig. Und > die müsste ja eigentlich im Idealfall von jedem Entwickler bei jeder > Änderung erflogen. Diese Qualitätskontrolle besteht heutzutage i.d.R. nicht mehr aus „ein Entwickler liest sich den ganzen Code durch“, sondern aus automatisierten Tests, und QA-Protokollen die nicht auf Sourcecodeebene arbeiten. Wer heutzutage alle Änderungen in Code-Abhängigkeiten manuell prüfen möchte, der kann einfach keine komplexe Software mehr entwickeln. Ein Vertrauen in gewisse Packages oder Repositories ist notwendig, egal ob es um kommerzielle Angebote (z.B. kommerzielle Toolchains mit Bibliotheken) oder Open Source geht. Du kannst z.B. unmöglich alle Änderungen in komplexen Abhängigkeiten wie einem IP-Stack, einer SSL-Bibliothek oder einem RTOS manuell sichten. Und ewig auf alten Versionen festzuhalten ist eine „Lösung“ mit der man böse auf die Nase fallen kann. Plötzlich kommt soetwas wie Ripple20, und wer dann keinen etablierten Prozess hat um regelmäßig Änderungen in Abhängigkeiten einzupflegen der schaut plötzlich ganz blöd aus der Wäsche, weil das alte major release von lwIP das das Produkt verwendet seit 3 Jahren nicht mehr supported wird, und keiner eine Ahnung hat wie man das Loch patchen und testen kann.
Andreas schrieb: > Diese Qualitätskontrolle besteht heutzutage i.d.R. nicht mehr aus „ein > Entwickler liest sich den ganzen Code durch“, sondern aus > automatisierten Tests, Völlig richtig. Und deshalb hat Rust/Cargo natürlich auch ein vollständiges Unittest- und Systemtest-Framework eingebaut.
cppbert schrieb: > aber es ist auch klar das kleinere, vielgenutzte Libs > eine höhrere Qualität/Testgrad aufweisen als wenige monolithen Ist das so? Gibt es dazu eine Studie oder ähnliches, wo man das nachlesen kann? cppbert schrieb: > Nicht anders machen wir es doch auch innerhalb unserer eigenen Software, > viele kleine, gut getestete Komponenten - die sogar mit anderen > Abteilungen geshared werden (sollten) Da muss ich oder ein Kollege aber auch den Kopf hin halten, wenn etwas nicht in Ordnung ist. cppbert schrieb: > Ich finde es z.B. ziemlich beeindrucken das Rust mit den Nightly Builds > einen grossteil der public verfügbaren Crates als Regressions-Test baut, > dauert weil Rust so fiese langsam ist eben 4 Tage, aber stell euch mal > vor wie aufwändig das wäre mit Github und C/C++ Projekten zu erreichen - > wenn wir die Menge an Buildsystemen/Varianten mit einbeziehen ist das > faktisch nicht möglich ohne permanente Handarbeit Ich sehe nicht so ganz den Vorteil, unkontrollierten Quelltext für Regressionstests zu nutzen, vor allem bei einer nicht wirklich definierten Sprache (das Thema Sprachdefinition wurde schon durchgekaut, und ich bin an keiner weiteren Diskussion interessiert, bis die Definition existiert). Wer wertet das alles aus, vor allem wenn es schon 3 neue Nightly Builds gibt, wenn das Ergebnis bereit steht? cppbert schrieb: > mh schrieb: >> Du hast vermutlich das Problem nicht verstanden. Ich muss trotzdem >> nachgucken, was geändert wurde, wer es geändert hat und vor allem, ob >> "deren" Meinung von "kompatibles Update" mit meiner Meinung >> übereinstimmt. > > das ist doch noch alles gar nicht fertig, warum so drauf rumreiten? Weil MaWin es immer wieder aus der Ecke kramt. Und auch wenn es fertig wäre, löst es das Problem nicht. cppbert schrieb: > wenn das Semantic Versioning sauber durchgezogen wird erkennst du > inkompatibilität an der Version - wenn das nicht sauber durchgezogen > wird ists Müll Und wer kontrolliert, dass es sauber durchgezogen wird? cppbert schrieb: > Aber was garantiert dir denn bitte bei irgendeiner Lib das dort die > Changelogs sauber sind Man kann sich die Commits angucken ... Man muss ja nicht jedes einzelne Zeichen kontrollieren, es gibt Strategien, um die eigenen Fragen effizient zu beantworten. cppbert schrieb: > [...] > Wenn man immer nur auf sein kleinen Bereich schaut ist alles egal - aber > frage mal einen Software-Projekt-Manager der zig Projekte und Teams > unter sich hat... Was genau willst du damit sagen? Qualitätssicherung ist nicht wichtig, wenn man überarbeitet oder überfordert ist? Und warum kann der Sofrware-Projekt-Manager diese Aufgabe nicht an einen Softwareentwickler delegieren?
MaWin schrieb: > cppbert schrieb: >> wenn das Semantic Versioning sauber durchgezogen wird erkennst du >> inkompatibilität an der Version - wenn das nicht sauber durchgezogen >> wird ists Müll > > Wenn du dem nicht vertraust, dann nutze es nicht und prüfe alles > manuell. > Meine Güte. Deine Entscheidung. Ich wollte nichts dagegen sagen: ich vertraue darauf das Verfehlungen mit dem Semantic Versioning von der Community so radikal verurteilt werden das sich auch jeder Newbie in kürzester Zeit daran hält wie an die 10 Gebote...
mh schrieb: > Ich sehe nicht so ganz den Vorteil, unkontrollierten Quelltext für > Regressionstests zu nutzen, [...] Wer wertet das alles aus, vor allem wenn es schon > 3 neue Nightly Builds gibt, wenn das Ergebnis bereit steht? Da es sich natürlich um automatisierte Tests handelt, ist die Auswertung inbegriffen.
mh schrieb: >> aber es ist auch klar das kleinere, vielgenutzte Libs >> eine höhrere Qualität/Testgrad aufweisen als wenige monolithen > Ist das so? Gibt es dazu eine Studie oder ähnliches, wo man das > nachlesen kann? wozu Studie? vertraust du nicht auf das Konzept: weniger, aber viel genutzte Zeilen Code sind meist weniger fehlerbehaftet, als großer, selten genutzter Code? mh schrieb: >> Nicht anders machen wir es doch auch innerhalb unserer eigenen Software, >> viele kleine, gut getestete Komponenten - die sogar mit anderen >> Abteilungen geshared werden (sollten) > Da muss ich oder ein Kollege aber auch den Kopf hin halten, wenn etwas > nicht in Ordnung ist. das ist dann natürlich ganz klar meine Verantwortung, warum sollte ich dafür keine Verantwortung tragen??? mh schrieb: >> Ich finde es z.B. ziemlich beeindrucken das Rust mit den Nightly Builds >> einen grossteil der public verfügbaren Crates als Regressions-Test baut, >> dauert weil Rust so fiese langsam ist eben 4 Tage, aber stell euch mal >> vor wie aufwändig das wäre mit Github und C/C++ Projekten zu erreichen - >> wenn wir die Menge an Buildsystemen/Varianten mit einbeziehen ist das >> faktisch nicht möglich ohne permanente Handarbeit > Ich sehe nicht so ganz den Vorteil, unkontrollierten Quelltext für > Regressionstests zu nutzen Da geht es nur um Parser und Kompiler-Tests - mehr nicht, und das du sowas mit C/C++ oder anderen (im Kern) nicht Package-basierten out-of-the-box Buildbaren Sprachen so was einfach sehr schwer ist mh schrieb: >> wenn das Semantic Versioning sauber durchgezogen wird erkennst du >> inkompatibilität an der Version - wenn das nicht sauber durchgezogen >> wird ists Müll > Und wer kontrolliert, dass es sauber durchgezogen wird? du, deine Kollegen, die Community, die Welt... mh schrieb: >> Aber was garantiert dir denn bitte bei irgendeiner Lib das dort die >> Changelogs sauber sind > Man kann sich die Commits angucken ... Man muss ja nicht jedes einzelne > Zeichen kontrollieren, es gibt Strategien, um die eigenen Fragen > effizient zu beantworten. das würde Ich auch mit Semantik Versioning machen - aber würde es trotzdem schön finden wenn sich eine Kultur entwickelt die Verfehlungen in dem Bereich starke Abneigung der Community erzeugt - und wenn der kein Soziopath ist - oder wem seine Reputation egal ist wirds dann eben nicht jucken - ist halt so mh schrieb: >> Wenn man immer nur auf sein kleinen Bereich schaut ist alles egal - aber >> frage mal einen Software-Projekt-Manager der zig Projekte und Teams >> unter sich hat... > Was genau willst du damit sagen? Qualitätssicherung ist nicht wichtig, > wenn man überarbeitet oder überfordert ist? Und warum kann der > Sofrware-Projekt-Manager diese Aufgabe nicht an einen Softwareentwickler > delegieren? in absolut keinster Weise - wie kannst du das aus dem Text rauslesen? Ich sage nur das eine bessere Kulturentwicklung die von einem einfachem System begünstigt wird sich schlussendlich auszahlen wird und der einzelne Entwickler einfach nicht immer direkt einer von den sehr guten sein muss damit auch gut läuft - btw: ich arbeite viel im Medizinbereich - Auditierung usw. ich weiss ganz genau was Qualität bedeutet - speziell in Projekten wo dir die FDA u.a. oder anderen den Vetrieb verbieten können :)
MaWin schrieb: > Warum sollte ein Paket mit einer neuen Version plötzlich > unvertrauenswürdig werden? Weil z.B. das Ergebnis eines stattgefundenen Code-Reviews verpufft und nachgeholt werden muss. Zumindest, wenn man es ernst meint. Sich abhängig zu machen von anderen ist eine leichte Entscheidung. Wird aber doof, wenn man selbst den Kopf für das Gesamtergebnis hinhalten muss - und Teile davon außerhalb der eigenen Zuständigkeit liegen. Das Problem ist nicht, dass es Abhängigkeiten gibt. Das Problem ist, dass ein Programmierstil mit möglichst vielen Abhängigkeiten entsteht (und offensichtlich auch gewünscht wird). Die Stabilität des Gesamtsystems ist daher nicht mehr gegeben, da sich ununterbrochen bestimmte Teile verändern. An deinem Auto schraubst du auch nicht ständig rum und tauschst irgendwelche Bolzen aus, nur weil der Bolzenhersteller sagt, dass der gestern chromefarbene Bolzen heute bronzefarben sein muss...
cppbert schrieb: > das sich auch jeder Newbie in kürzester Zeit daran hält wie an > die 10 Gebote... Dann solltest du etwas Selbstrefelxion betreiben und prüfen, ob du dich an alle 10 Gebote hälst. Ich halte mich nicht an alle 10 ;-). cppbert schrieb: > mh schrieb: >>> aber es ist auch klar das kleinere, vielgenutzte Libs >>> eine höhrere Qualität/Testgrad aufweisen als wenige monolithen >> Ist das so? Gibt es dazu eine Studie oder ähnliches, wo man das >> nachlesen kann? > > wozu Studie? vertraust du nicht auf das Konzept: weniger, aber viel > genutzte Zeilen Code sind meist weniger fehlerbehaftet, als großer, > selten genutzter Code? 1. Nein ich vertraue nicht blind einem unbewiesenen Konzept 2. Warum ändert sich die Anzahl der Codezeilen? cppbert schrieb: > [...] > du, deine Kollegen, die Community, die Welt... Die Community ist aber nicht für die Software verantwortlich, die ich meinem Kunden verkaufe. Wir drehen uns im Kreis. Ich weiß nicht wie es dir geht, aber immer wenn ich von so etwas wie heartbleed erfahre, frage ich mich "wie kann sowas nicht vorher auffallen?". Ich sage nicht, dass mir der Bug aufgefallen wäre, aber ich wäre für die möglichen Folgen dieses Bugs in meiner Software verantwortlich und niemand sonst. (Ich habe openssl nicht als Abhängigkeit) > mh schrieb: >>> Aber was garantiert dir denn bitte bei irgendeiner Lib das dort die >>> Changelogs sauber sind >> Man kann sich die Commits angucken ... Man muss ja nicht jedes einzelne >> Zeichen kontrollieren, es gibt Strategien, um die eigenen Fragen >> effizient zu beantworten. > > das würde Ich auch mit Semantik Versioning machen - aber würde es > trotzdem schön finden wenn sich eine Kultur entwickelt die Verfehlungen > in dem Bereich starke Abneigung der Community erzeugt - und wenn der > kein Soziopath ist - oder wem seine Reputation egal ist wirds dann eben > nicht jucken - ist halt so Die Abneigung der Community und der eigene Ruf ist ziemlich egal, wenn es um viel Geld geht, vor allem, da das Internet ziemlich anonym ist. Wieviel Geld ein geschickter Hacker wohl verdienen kann, wenn er es schafft einen kleinen Exploit in openssl zu verstecken, der es für 1 Tag in die repos einer Linux Distribution schafft. > mh schrieb: >>> Wenn man immer nur auf sein kleinen Bereich schaut ist alles egal - aber >>> frage mal einen Software-Projekt-Manager der zig Projekte und Teams >>> unter sich hat... >> Was genau willst du damit sagen? Qualitätssicherung ist nicht wichtig, >> wenn man überarbeitet oder überfordert ist? Und warum kann der >> Sofrware-Projekt-Manager diese Aufgabe nicht an einen Softwareentwickler >> delegieren? > > in absolut keinster Weise - wie kannst du das aus dem Text rauslesen? Das war das einzige was ich da reinlesen konnte. Was sollte ich denn da rauslesen? > Ich sage nur das eine bessere Kulturentwicklung die von einem einfachem > System begünstigt wird sich schlussendlich auszahlen wird und der > einzelne Entwickler einfach nicht immer direkt einer von den sehr guten > sein muss damit auch gut läuft - btw: ich arbeite viel im Medizinbereich > - Auditierung usw. ich weiss ganz genau was Qualität bedeutet - speziell > in Projekten wo dir die FDA u.a. oder anderen den Vetrieb verbieten > können :) Und ihr überprüft nicht bei jedem Update, ob die Abhängikeiten noch in Ordnung sind? Für wen genau arbeitest du?
S. R. schrieb: > Die > Stabilität des Gesamtsystems ist daher nicht mehr gegeben, da sich > ununterbrochen bestimmte Teile verändern. Nein. Unsinn. Mit Semantic Versioning verändert sich genau gar nichts in inkompatibler Art und Weise. Und wenn du dem nicht vertraust, dann pinne halt deine Version fest. Es ist einzig und alleine die Entscheidung des Entwicklers, ob sich Teile ändern oder nicht. Ich sehe hier überhaupt gar keine Gefährdung der Stabilität des Gesamtsystems durch Cargo/Rust.
mh schrieb: > Ich sage nicht, dass mir der Bug aufgefallen wäre, aber ich wäre für die > möglichen Folgen dieses Bugs in meiner Software verantwortlich und > niemand sonst. (Ich habe openssl nicht als Abhängigkeit) Und wenn du die TLS-Implementierung selbst gemacht hättest, damit du nur ja keine böse Dependency hast für die die verantwortlich bist, hättest du das natürlich fehlerfrei implementiert. Wenn man eine Funktionalität braucht, hat man genau zwei Möglichkeiten: 1) Man programmiert es selbst. 2) Man nutzt Libs, die auch von anderen genutzt werden. Jetzt rate mal, wo im Schnitt mehr Bugs drin sind.
mh schrieb: > Ich weiß nicht wie es dir geht, aber immer wenn ich von so etwas wie > heartbleed erfahre, frage ich mich "wie kann sowas nicht vorher > auffallen?". > Ich sage nicht, dass mir der Bug aufgefallen wäre, aber ich wäre für die > möglichen Folgen dieses Bugs in meiner Software verantwortlich und > niemand sonst. (Ich habe openssl nicht als Abhängigkeit) falls du die Abhängigkeit gehabt hättest wäre dir der heartbleed beim Review der neueren Version sicherlich aufgefallen, oder? mh schrieb: >> Ich sage nur das eine bessere Kulturentwicklung die von einem einfachem >> System begünstigt wird sich schlussendlich auszahlen wird und der >> einzelne Entwickler einfach nicht immer direkt einer von den sehr guten >> sein muss damit auch gut läuft - btw: ich arbeite viel im Medizinbereich >> - Auditierung usw. ich weiss ganz genau was Qualität bedeutet - speziell >> in Projekten wo dir die FDA u.a. oder anderen den Vetrieb verbieten >> können :) > Und ihr überprüft nicht bei jedem Update, ob die Abhängikeiten noch in > Ordnung sind? Für wen genau arbeitest du? wie kommst du darauf? ohne automatisch erzwungenes Review durch einen Team Kollegen bekomme ich keinen Zeile in den Vor-Main, und in den Main kommen die erst wenn alle Tests durch sind - mit ca. 70-80% Abdeckung, ASAN, TSAN, Coverity, die ganze Buzzword-Kette - ist manchmal sehr anstrengend aber richtig übel wird es wenn du an gesharten Libs arbeitest oder Architektur-Änderungen machen willst :)
cppbert schrieb: > wie kommst du darauf? ohne automatisch erzwungenes Review durch einen > Team Kollegen bekomme ich keinen Zeile in den Vor-Main, und in den Main > kommen die erst wenn alle Tests durch sind - mit ca. 70-80% Abdeckung, > ASAN, TSAN, Coverity, die ganze Buzzword-Kette - ist manchmal sehr > anstrengend aber richtig übel wird es wenn du an gesharten Libs > arbeitest oder Architektur-Änderungen machen willst :) bei >100 Entwicklern und weit weit >1Mio LOC
und ja "Rust would’ve prevented Heartbleed" : https://tonyarcieri.com/would-rust-have-prevented-heartbleed-another-look Rust would’ve prevented Heartbleed, but Heartbleed is actually kind of boring compared to remote code execution vulnerabilities like Winshock or openssl-too-open. Remote code execution vulnerabilities are far scarier, and largely preventable in Rust due to its memory safety. aber es gibt trotzdem noch genug andere Sache die Rust nicht verhindern kann ist aber auch von 2015, keine Ahnung ob sich die Situation weiter verbessert hat
MaWin schrieb: > mh schrieb: >> Ich sage nicht, dass mir der Bug aufgefallen wäre, aber ich wäre für die >> möglichen Folgen dieses Bugs in meiner Software verantwortlich und >> niemand sonst. (Ich habe openssl nicht als Abhängigkeit) > > Und wenn du die TLS-Implementierung selbst gemacht hättest, damit du nur > ja keine böse Dependency hast für die die verantwortlich bist, hättest > du das natürlich fehlerfrei implementiert. Wo habe ich geschrieben, dass Dependencies böse sind? Wo habe ich auch nur angedeutet, dass ich TLS fehlerfrei implementiert hätte? Was genau wolltest du mit dem Satz genau sagen? Oder wolltest du mir einfach etwas unterstellen? MaWin schrieb: > Wenn man eine Funktionalität braucht, hat man genau zwei Möglichkeiten: > 1) Man programmiert es selbst. > 2) Man nutzt Libs, die auch von anderen genutzt werden. Die beiden Alternativen sind meiner Meinung nach unvollständig. 1. Man entwickelt es selbst. Dazu gehört ein unabhängiges Review. 2. Man nutzt eine extern entwickelte Lösung und führt das Review selbst durch. Wie gründlich das Review ist, ist situationsabhängig. MaWin schrieb: > Jetzt rate mal, wo im Schnitt mehr Bugs drin sind. Du hast sicher ein paar passende Studien zur Hand, die diese Frage beantworten? cppbert schrieb: > mh schrieb: >> Ich weiß nicht wie es dir geht, aber immer wenn ich von so etwas wie >> heartbleed erfahre, frage ich mich "wie kann sowas nicht vorher >> auffallen?". >> Ich sage nicht, dass mir der Bug aufgefallen wäre, aber ich wäre für die >> möglichen Folgen dieses Bugs in meiner Software verantwortlich und >> niemand sonst. (Ich habe openssl nicht als Abhängigkeit) > > falls du die Abhängigkeit gehabt hättest wäre dir der heartbleed beim > Review der neueren Version sicherlich aufgefallen, oder? Warum wollt ihr mir unbedingt unfehlbarkeit unterstellen? cppbert schrieb: > wie kommst du darauf? ohne automatisch erzwungenes Review durch einen > Team Kollegen bekomme ich keinen Zeile in den Vor-Main, und in den Main > kommen die erst wenn alle Tests durch sind - mit ca. 70-80% Abdeckung, > ASAN, TSAN, Coverity, die ganze Buzzword-Kette - ist manchmal sehr > anstrengend aber richtig übel wird es wenn du an gesharten Libs > arbeitest oder Architektur-Änderungen machen willst :) Warum muss dein Code ein Review durch einen Kollegen überstehen, und die Abhängigkeiten nicht? cppbert schrieb: > und ja "Rust would’ve prevented Heartbleed" und ja "FORTRAN would've prevented Heartbleed"
mh schrieb: > Wo habe ich geschrieben, dass Dependencies böse sind? Wo habe ich auch > nur angedeutet, dass ich TLS fehlerfrei implementiert hätte? Was genau > wolltest du mit dem Satz genau sagen? Oder wolltest du mir einfach etwas > unterstellen? Und warum hast du es dann geschrieben?
mh schrieb: > Warum muss dein Code ein Review durch einen Kollegen überstehen, und die > Abhängigkeiten nicht? Abhängigkeiten natürlich auch, die sogar noch intensiver weil der Prozess der Entwicklung da ja nicht so gut nachvollziehbar ist aber wie auch bei Rust Cargo kommen die nicht einfach plötzlich sondern man entscheidet sich für eine Versionsänderung - und beginnt dann den Upgrade-Prozess - der ein Weilchen dauern kann - das gilt für 3rd-Parties wie auch für das Entwicklungs/Laufzeitsystem und die verwendeten Kompiler
cppbert schrieb: > und beginnt dann den > Upgrade-Prozess - der ein Weilchen dauern kann d.h. alle Änderungen so weit wie möglich nachvollziehen, was bei manchen 3rd-Parties aber Aufgrund der Größe auch schwer sein kann (z.B. CAD-Kernel usw. - auch wenn mit Source Code kann ich da nicht durch alle 6000 Code-Änderungen durch, weil ich die Architektur der Lib nicht wirklich intensiv kenne und deswegen nicht die Fehler-Relevanz von Fixes oder Änderungen beurteilen kann) dann Branchen und alle Tests-Durchlaufen, manuelle und System-Tests, der Rest ist Hoffnung
Was macht ihr eigentlich so für Software, wenn ihr jede Dependency Zeile für Zeile reviewen müsst? Ariane 5? Steuerung der ISS? Falcon 9? Das ist völlig weltfremdes Gelaber. Niemand macht das. Und es ist allgemein auch gar nicht notwendig. Nur vielleicht im Einzelfall, wenn es eine obskure Lib ist, die sonst niemand verwendet oder ähnliches. Aber allgemein ist das völliger Quatsch. Unittests, Systemtests, und gut ist.
MaWin schrieb: > mh schrieb: >> Wo habe ich geschrieben, dass Dependencies böse sind? Wo habe ich auch >> nur angedeutet, dass ich TLS fehlerfrei implementiert hätte? Was genau >> wolltest du mit dem Satz genau sagen? Oder wolltest du mir einfach etwas >> unterstellen? > > Und warum hast du es dann geschrieben? Was habe ich wo geschrieben? cppbert schrieb: > mh schrieb: >> Warum muss dein Code ein Review durch einen Kollegen überstehen, und die >> Abhängigkeiten nicht? > > Abhängigkeiten natürlich auch, die sogar noch intensiver weil der > Prozess der Entwicklung da ja nicht so gut nachvollziehbar ist > > aber wie auch bei Rust Cargo kommen die nicht einfach plötzlich sondern > man entscheidet sich für eine Versionsänderung - und beginnt dann den > Upgrade-Prozess - der ein Weilchen dauern kann - das gilt für > 3rd-Parties wie auch für das Entwicklungs/Laufzeitsystem und die > verwendeten Kompiler Wieso ist dann der Pflegeaufwand für Abhängikeiten aus dem cargo geringer, als für eine selbst entwickelte Lösung? Wenn ihr ein Review macht, müsst ihr ja die Kompetenz besitzen, die Software selbst zu pflegen. Und die Zahl der Änderungen sollte bei der eigenen Lösung geringer sein, da nur eure Anforderungen erfüllt werden müssen.
mh schrieb: > Was habe ich wo geschrieben? Das: >Die Community ist aber nicht für die Software verantwortlich, die ich >meinem Kunden verkaufe. Wir drehen uns im Kreis. >Ich weiß nicht wie es dir geht, aber immer wenn ich von so etwas wie >heartbleed erfahre, frage ich mich "wie kann sowas nicht vorher >auffallen?". >Ich sage nicht, dass mir der Bug aufgefallen wäre, aber ich wäre für die >möglichen Folgen dieses Bugs in meiner Software verantwortlich und >niemand sonst. (Ich habe openssl nicht als Abhängigkeit) Warum hast du das geschrieben, wenn es doch keine Aussage hat? Ja, du musst für deine Software haften. Und? Du hast die Möglichkeit sie selbst zu schreiben, oder gut getestete und verbreitete Softwaremodule zu verwenden. Deine Entscheidung. Du beherrschst es sehr gut eine Diskussion entgleisen zu lassen, indem du ständig die Richtung änderst.
mh schrieb: > Wieso ist dann der Pflegeaufwand für Abhängikeiten aus dem cargo > geringer, als für eine selbst entwickelte Lösung? Wenn ihr ein Review > macht, müsst ihr ja die Kompetenz besitzen, die Software selbst zu > pflegen. Weil man es nicht selbst schreiben muss? Weil man eben nicht zwangsweise ein volles Review machen muss? Weil man es eben nicht zwangsweise vollständig testen muss? Weil es weniger wahrscheinlich Bugs enthält, wenn es auf millionen anderer Kisten bereits läuft? etc, etc...
MaWin schrieb: > [...] So lange du weiter unvollständig und/oder falsch zitierst diskutiere ich nicht weiter mit dir. Auch wenn ich weiter mit dir Diskutieren wollte, ist es nicht mehr möglich, da
1 | formerror_too_many_quoted_lines |
mh schrieb: > So lange du weiter unvollständig und/oder falsch zitierst Ach. Was war denn unvollständig? Deine Nebelkerzen kannst du dir sparen.
mh schrieb: >> aber wie auch bei Rust Cargo kommen die nicht einfach plötzlich sondern >> man entscheidet sich für eine Versionsänderung - und beginnt dann den >> Upgrade-Prozess - der ein Weilchen dauern kann - das gilt für >> 3rd-Parties wie auch für das Entwicklungs/Laufzeitsystem und die >> verwendeten Kompiler > Wieso ist dann der Pflegeaufwand für Abhängikeiten aus dem cargo > geringer, als für eine selbst entwickelte Lösung? für die professionelle Entwicklung ist der Prüfungsaufwand exakt gleich groß - kommt eben darauf an wie wichtig es ist, wer anders behauptet versteht es nicht oder meint was anderes (z.B. einfacheres deployment) aber für Mio Standard-Anwender wird das ganze deployment trivial, man braucht keine 10 Buildsysteme mehr verstehen - wenn du als Selbständiger viele Firmen durchwanderst wärst du schockiert wie viel Aufwand da investiert wird der beim Wechsel in eine andere Firma gerade wieder verpufft, bei Java und .Net ist z.B. die Effekt sehr klein - alle sprechen fast die gleiche Sprache/Tools > Wenn ihr ein Review > macht, müsst ihr ja die Kompetenz besitzen, die Software selbst zu > pflegen. Und die Zahl der Änderungen sollte bei der eigenen Lösung > geringer sein, da nur eure Anforderungen erfüllt werden müssen. das Konzept funktioniert nur so lange deine 3rd-Parties trivial sind weil du es dir in deinem Projekt leisten kannst, z.B. ist es recht sinnfrei mit einem Embedded-Entwickler von 64Kb Platformen über die Komplexität von Library-Abhängigkeiten zu diskutieren - er hat nämlich fast nie welche genau so sinnlos ist die Argumentation wenn z.B. genannte OpenSSL zum Einsatz kommt, der schiere Umfang der Lib erschwert ein Initiales-Review, und jeder der das anders verkaufen will redet Müll oder braucht die eben doch nicht wirklich In einem Projekt hatten wir einen CAD-Kernel im Einsatz - mit Quelltext-Lizenz, der war riesig und hat einen Haufen-Spezialfeatures gehabt von denen wir ~60% genutzt haben (für 1% der Software-Funktionalität), alles pure Mathematik mit ohne Ende Spezialfällen, Sau teuer, aber sehr gute Ergebnisse, nicht das ich Angst vor Mathe habe, aber es ist eben was anderes ob das dein Primärfeld ist oder nur Randgebiet in deiner Software
cppbert schrieb: > alles pure Mathematik mit ohne Ende > Spezialfällen, Sau teuer, aber sehr gute Ergebnisse, nicht das ich Angst > vor Mathe habe, aber es ist eben was anderes ob das dein Primärfeld ist > oder nur Randgebiet in deiner Software und ja bei dem Kunden gab es viele Mathematiker die das gekonnt hätte - aber die haben auch anderen Aufgaben als zig-tausend Euro Zukaufsoftware zu reviewen - bei manchen Projekten oder auch Verantwortlichen bekommt man so was durch oder es wird auch gefordert aber eben nicht einfach so überall
> Das ist völlig weltfremdes Gelaber. > Niemand macht das. Jeder der SIL2 Software macht. Und ab SIL3 machst das nicht du sondern ein unabhaengiger Dritter. Olaf
Moin, Na, war ja gut was los hier in der Zwischenzeit... MaWin schrieb: >> dann sagen mir autotools und cmake VORHER, was sie >> beoetigen. > > cargo check Wow - ich bin ja zutiefst impraegniert. Hat jetzt nichtmal 1h gedauert ... Ja, der Rechner ist keine Rakete, aber - hey - ich will einen einzelnen Videocodec bauen, kein ganzes ffmpeg, kein ganzes GNU-Octave, keinen Browser, kein komplettes X11R6 mit make world... und auch kein KiCad mit Furz und Feuerzeug. Nein, 1 (i.W. ein) Videocodec.
1 | root [ /usr/src/rav1e-0.4.0 ]# cargo check |
2 | Compiling autocfg v1.0.1 |
3 | Compiling libc v0.2.82 |
4 | Compiling const_fn v0.4.5 |
5 | Checking lazy_static v1.4.0 |
6 | Compiling proc-macro2 v1.0.24 |
7 | Compiling rayon-core v1.9.0 |
8 | Checking cfg-if v1.0.0 |
9 | Compiling memchr v2.3.4 |
10 | Compiling unicode-xid v0.2.1 |
11 | Compiling syn v1.0.58 |
12 | Compiling scopeguard v1.1.0 |
13 | Compiling bitflags v1.2.1 |
14 | Compiling ucd-trie v0.1.3 |
15 | Compiling either v1.6.1 |
16 | Compiling regex-syntax v0.6.22 |
17 | Compiling log v0.4.13 |
18 | Checking unicode-width v0.1.8 |
19 | Compiling arrayvec v0.5.2 |
20 | Checking cfg-if v0.1.10 |
21 | Compiling signal-hook v0.3.3 |
22 | Compiling noop_proc_macro v0.3.0 |
23 | Compiling rust_hawktracer_proc_macro v0.4.1 |
24 | Checking lab v0.8.2 |
25 | Checking bitstream-io v1.0.0 |
26 | Checking rust_hawktracer_normal_macro v0.4.1 |
27 | Checking scan_fmt v0.2.5 |
28 | Compiling paste v1.0.4 |
29 | Checking y4m v0.7.0 |
30 | Compiling crossbeam-utils v0.8.1 |
31 | Compiling memoffset v0.6.1 |
32 | Compiling num-traits v0.2.14 |
33 | Compiling num-integer v0.1.44 |
34 | Compiling rayon v1.5.0 |
35 | Checking thread_local v1.1.0 |
36 | Compiling pest v2.1.3 |
37 | Checking itertools v0.10.0 |
38 | Checking textwrap v0.11.0 |
39 | Checking ivf v0.1.1 (/usr/src/rav1e-0.4.0/ivf) |
40 | Checking rust_hawktracer v0.7.0 |
41 | Compiling semver-parser v0.10.2 |
42 | Compiling time v0.1.43 |
43 | Compiling num_cpus v1.13.0 |
44 | Compiling jobserver v0.1.21 |
45 | Checking terminal_size v0.1.15 |
46 | Checking signal-hook-registry v1.3.0 |
47 | Compiling quote v1.0.8 |
48 | Compiling aho-corasick v0.7.15 |
49 | Checking clap v2.33.3 |
50 | Compiling semver v0.11.0 |
51 | Checking fern v0.6.0 |
52 | Checking crossbeam-channel v0.5.0 |
53 | Checking crossbeam-queue v0.3.1 |
54 | Compiling crossbeam-epoch v0.9.1 |
55 | Compiling cc v1.0.66 |
56 | Compiling simd_helpers v0.1.0 |
57 | Compiling regex v1.4.3 |
58 | Compiling rustc_version v0.3.2 |
59 | Compiling crossbeam-deque v0.8.0 |
60 | Compiling chrono v0.4.19 |
61 | Compiling thiserror-impl v1.0.23 |
62 | Compiling num-derive v0.3.3 |
63 | Compiling arg_enum_proc_macro v0.3.0 |
64 | Checking console v0.14.0 |
65 | Checking crossbeam v0.8.0 |
66 | Compiling vergen v3.0.4 (/usr/src/rav1e-0.4.0/crates/vergen) |
67 | Checking thiserror v1.0.23 |
68 | Checking v_frame v0.2.0 (/usr/src/rav1e-0.4.0/v_frame) |
69 | Compiling nasm-rs v0.2.0 |
70 | Checking av-metrics v0.6.2 |
71 | Compiling rav1e v0.4.0 (/usr/src/rav1e-0.4.0) |
72 | error: failed to run custom build command for `rav1e v0.4.0 (/usr/src/rav1e-0.4.0)` |
73 | |
74 | Caused by: |
75 | process didn't exit successfully: `/usr/src/rav1e-0.4.0/target/debug/build/rav1e-6cc129c8c67eccb3/build-script-build` (exit code: 1) |
76 | --- stderr |
77 | rav1e requires rustc >= 1.44.1. |
Mal gucken, wann/wie ich weiterstuempere... Gruss WK
Olaf schrieb: > Jeder der SIL2 Software macht. Und ab SIL3 machst das nicht du sondern > ein unabhaengiger Dritter. Ja genau. Richtig. Du hast den Sonderfall gefunden. Bravo. Es geht hier um Rust und Cargo. Wie viel *SILxy SW davon nutzt denn crates.io? Richtig. Keine. Denn wie du ja schon selbst sagtest, braucht man da die 100%ige Kontrolle über seine Deps. Deshalb nutzt man lokale crates. Wo war jetzt noch gleich das Problem?
Dergute W. schrieb: > Wow - ich bin ja zutiefst impraegniert. Hat jetzt nichtmal 1h gedauert Rust ist scheisse langsam zu bauen - das ist mehr als bekannt - liegt aber nicht am Sprachendesign sondern dem Frontend was dem LLVM zu viel IR Code hinschmeisst den er dann Ewig optimieren muss Buildzeiten schlechter als C++ sind nicht selten - jedem bekannt trotzdem ändert das nichts daran das es ein relativ gutes Sprachendesign ist mit gute Ansätze/Anleihen für Infrastruktur-Tools
Dergute W. schrieb: >> cargo check > > Wow - ich bin ja zutiefst impraegniert. Hat jetzt nichtmal 1h gedauert Ja genau. Es hat auch keine 3 Tage und keine 3 Wochen gedauert. Sondern wenige Minuten.
1 | rav1e-0.4.0$ time cargo check |
2 | Downloaded jobserver v0.1.21 |
3 | Downloaded noop_proc_macro v0.3.0 |
4 | Downloaded nasm-rs v0.2.0 |
5 | Downloaded crossbeam v0.8.0 |
6 | Downloaded arg_enum_proc_macro v0.3.0 |
7 | ... |
8 | real 2m43.530s |
9 | user 9m35.788s |
10 | sys 0m15.025s |
Auf einem 8 Jahre alten Laptop. Der Rustcompiler ist nicht schnell. Das ist bekannt. Aber bitte höre auf zu lügen.
Dergute W. schrieb: > Mal gucken, wann/wie ich weiterstuempere... Ich hab das eben auch mal probiert. Ich kann nichts dazu sagen, ob das 1h dauert oder nicht, da es nach 20 Sekunden mit einer kryptischen Fehlermeldung abgebrochen ist. Das sah so aus als wäre der strerror Text für eine fehlende Datei direkt an den Nutzer weitergegeben worden, ohne zu erwähnen welche Datei fehlt. Sehr hilfreich ...
Moin, MaWin schrieb: > Aber bitte höre auf zu lügen. Bitte hoere auf, mir Luegen zu unterstellen; ich schrub' ja, der Rechner ist keine Rakete (Auch Laptop, aber deutlich aelter als deiner). Es waere mir ja anundpfirsich auch wurscht, wenn er ein paar Tage vor sich hinwerkelt und Gigabyteweise irgendwelchen mumpitz runterlaed', wenn danach was sinnvolles rausgekommen waere und nicht so eine bekloppte Meldung. Aber ich kann eben doch auch auf dieser alten Maschin' Buildgeschwindigkeit, -Komfort des Buildsystems, etc. in Relation zu diverser anderer Software setzen, die ich da gebaut habe. Wenn ich jetzt mal hier nachschau': https://github.com/xiph/rav1e/commit/c6a2d69a99c79763da3545e8b0f410c488cad98e und da les' ich was wie: "Bump minimum version to 1.44.1 This is needed to avoid a rustc bug that existed in 1.43, which was tripped by the updated version of semver-parser." Und ihr wollt mir hier einen von gutem Sprachdesign, und guten Ansaetzen von Infrastruktur-Tools und toller Versionierung und Sicherheit erzaehlen. Da kram' ich nochmal meinen schiefen Vergleich mit dem Kommunismus raus: Ich, der dumme Werktaetige (kein Informatiker), will einfach nur mal 'ne Banane(Videocodec) essen(kompilieren). Sind aber halt in der Zone grad aus. Deshalb sagen die Jungs frisch von der Kaderschmiede, ich soll mich mal nicht so anstellen; die Bananen, die der Klassenfeind im Westen(C, "alte" Buildsysteme") frisst, waeren ja eh' nix genaues, und wenn der Kommunismus den Kapitalismus erst ueberrundet hat, dann gibts hier viel groessere, gelbere und bananigere Bananen mit viel besseren Versionsnummern. Jaja, schon klar... ;-) SCNR, WK
Dergute W. schrieb: > und da les' ich was wie: > "Bump minimum version to 1.44.1 > This is needed to avoid a rustc bug that existed in 1.43, > which was tripped by the updated version of semver-parser." > > Und ihr wollt mir hier einen von gutem Sprachdesign, und guten Ansaetzen > von Infrastruktur-Tools und toller Versionierung und Sicherheit > erzaehlen. Es sagt niemand das irgendwas davon perfekt ausgereift und fehlerfrei ist, keine Ahnung warum du dich überhaupt nur im entfernesten daran störst? Ignorier einfach Rust und gut ist und falls deine Liblingslib oder App plötzlich eine Dependency dazu hat ist der Autor davon eben jetzt auch nicht mehr ganz so frisch im Kopf
Dergute W. schrieb: > ich schrub' ja, der Rechner > ist keine Rakete (Auch Laptop, aber deutlich aelter als deiner). Auf einer PDP-11 läuft Rust übrigens auch nicht. Dergute W. schrieb: > Und ihr wollt mir hier einen von gutem Sprachdesign, und guten Ansaetzen > von Infrastruktur-Tools und toller Versionierung und Sicherheit > erzaehlen. Blabla. Dummes Gelaber. Es hat einen Fehler gegeben. Und? In $anderer_compiler hat es schließlich noch nie Fehler gegeben. In der Zeit, die du hier herumpalavert hast, hättest du lange "rustup update" ausführen können und nach 10 Minuten hättest du ein modernes Rust gehabt, das dein Projekt bauen kann. Aber daran bist du ja gar nicht interessiert. Du willst ja lieber hier stänkern.
MaWin schrieb: > Wenn man eine Funktionalität braucht, hat man genau zwei Möglichkeiten: > 1) Man programmiert es selbst. > 2) Man nutzt Libs, die auch von anderen genutzt werden. Es sagt ja niemand, dass man gar keine externen Libraries brauchen darf. Es geht darum, die Abhängigkeiten sinnvoll und gering zu halten. Aber wenn es etwas gibt, das man braucht, aber nicht wirklich will? Man vergesse nicht Option 3! 3) Eine Abstraktionsschicht. Die Abhängigkeit in ein anderes Programm oder Backend auslagern / abtrennen, genutzt über ein möglichst simples Interface. Das macht das Hilfsprogram / Backend einfach zu ersetzen und erlaubt alternative und/oder unabhängige Implementationen! Ich mache das recht oft. Es ist nicht immer einfach umzusetzen, und es kann schwierig sein, zu entscheiden, wo man den Schnitt macht. Auch ich bin da nicht perfekt. Die Abhängigkeit geht oft auch nicht ganz weg, aber statt total von der einen Sache abhängig zu sein, kann man mehrere Implementationen haben, und diese einfach ersetzen, oder je nachdem was es ist auch mehrere nutzen. Notfalls muss man auch nicht das halbe Programm neu schreiben, wenn man es ersetzen muss. Beispiele von mir: 0) In einem Report Generator in nodejs, den ich mal schrieb, brauchte ich was um SVGs nach PNGs zu konvertieren (für email). Die bestehenden Implementationen gefielen mir aber alle nicht. Ich habe dann trotzdem eine genommen, ich bin ja nicht wahnsinnig, aber nicht direkt verwendet. Es gibt nur eine Datei mit einer einzigen exportierten Funktion, "svg_to_png", die die library nutzt. Alles andere nutzt die Funktion, und nicht die lib direkt. Austauschen wäre also simpel. 1) Mein Window Manager brauchte eine Appübersicht/homescreen/dashboard, wie auch immer man es nennen mag. Sowas will ich nicht ohne Gui Toolkit machen. Im Window Manager will ich aber von keinem Gui Toolkit abhängig sein. Ich hab das dann in eine andere Anwendung ausgelagert, die nur die Appübersicht anzeigt, und von der WM per xembed eingebunden wird. Wobei ich das Anzeigen nochmal in eine andere Anwendung ausgelagert habe. Also WM xembed <- dashboard <-> ui-grid Die WM ist c, das dashboard ist ein simples bash script, und das ui-grid ist python3 + pyqt: https://github.com/Daniel-Abrecht/ui-grid/blob/master/ui-grid https://github.com/Daniel-Abrecht/dpaw/blob/master/tools/dpaw-dashboard https://github.com/Daniel-Abrecht/dpaw/blob/38a72f273951c1185598337f6c67288daaa340a8/wm/src/dpawindow/workspace/handheld.c#L299 2) Meine tty multiplexer library hat ein Backend für Ausgaben über curses: https://github.com/Daniel-Abrecht/libttymultiplex/blob/master/backend/curses/src/main.c#L397 Eigentlich wollte ich noch ein tty, ein fbdev, ein KMS, etc. backends machen, bin aber nie dazu gekommen. Das interface da ist auch nicht besonders gut, libttymultiplex ist zwar von den Backends unabhängig, aber die backends nicht von libttymultiplex... 3) Mein console-keyboard-multiplexer (zeigt ein Keyboard unten in der Konsole an) und mein console-keyboard-basic (das angezeigte Keyboard) haben keine direkte Abhängigkeit. 4) Mein ACME2 challange solver trennt den generischen ACME2 part und den solver part. Der Solver ist ein separates Program. (packaging und verschieben des dns01 solvers in separates Repo noch ausstehend, hauptcode ist aber bereits davon voll unabhängig): https://github.com/Daniel-Abrecht/DPA-ACME2 Ich hatte noch mehr Zeugs, auch in anderen Sprachen, aber ich glaube das sind genug Beispiele. Ich bin natürlich nicht der Einzige, der das macht: 1&2) Das SDL Grafikframework und QT haben etliche Backends für alles mögliche, sei es X11, KMS, fbdev, für Grafik, pulse oder also für sound, xinput oder libinput für IO, etc. 3) Die gnome-chatty app nutzt libpurple plugins als backends, genauso wie glaube ich pidgin (ich glaube von dort kommt es ursprünglich) 4) gnome-calls hat modemmanager und ofono backends 5) X11 hat die DIX. Heutzutage abstrahiert da zwar mesa & gbm fast alles, so das nur noch die modesetting DIX benötigt wird, aber NVIDIA und ein paar andere querulanten kochen noch ihr eigenes Süppchen Zudem sollte man auch die Möglichkeit optionaler runtime & compiletime Dependencies nicht vergessen. Ich denke an all dem sieht man schön, dass nicht alle Abhängigkeiten immer gleich stark abhängig machen müssen. Es gibt weichere und härtere Abhängigkeiten, stärker integrierte und besser segregierte, ersetzbare und unersetzbare, etc.
Abstraktion ist natürlich wichtig, hier geht es aber gerade, um es in deinen Worten zu sagen, eine konkrete Implementierung und den Probleme die mit einem Versionswechsel bei einer 3rdParty Lib einhergehen
cppbert3 schrieb: > Abstraktion ist natürlich wichtig, hier geht es aber gerade, um es > in > deinen Worten zu sagen, eine konkrete Implementierung und den Probleme > die mit einem Versionswechsel bei einer 3rdParty Lib einhergehen oder besser - natürlich sollte(oder muss) man eine Abstraktion haben (um die Features zu erhalten die du aufzeigst) aber das war hier definitiv gar nicht das Thema :)
Um wieder den Link zu Cargo zu machen, in wieweit sind diese Art von Abhängigkeiten - also optionale Backends - damit abbildbar? In debian / apt kann man sagen Packet X bietet Y, Paket Z braucht Y, und man kann sagen welche Implementation man bevorzugt (als Z braucht X oder ein Y, wobei apt dann zuerst Z versucht, falls noch kein Y vorhanden oder mitangegeben). Man beachte, Z braucht nichts von X oder anderen Y zu wissen, es wird es beim Kompilieren nicht gebraucht, es geht um runtime dependencies. Wie gut kann man mit Cargo sowas abbilden? Ist das überhaupt im scope von Cargo, oder hilft einem das nur mit direkten compile time Abhängigkeiten?
Edit: müsste heissen: wobei apt dann zuerst X versucht (nicht Z)
Ich finde es interessant, wie die Cargo-Proponenten dafür trommeln, dass man (a) ausschließlich die neuesten Versionen nutzt; (b) keine Code-Reviews macht, sondern automatisiert testet; (c) sich auch bei hunderten von Abhängigkeiten mal nicht so anstellen soll; (d) verschwinden soll, wenn's einem nicht passt. Jedes dieser Argumente hat seine Berechtigung, aber eben auch Schwächen. Die hier mal ganz elegant wegerklärt werden. Das Sahnehäubchen ist noch, dass das natürlich auch für die Toolchain selbst zutrifft. Achso, und dass vorausgesetzt wird, dass Version 1.2.4 strikt besser ist als Version 1.2.3, garantiert und ohne jede Ausnahme - man verlässt sich schließlich darauf.
🐧 DPA 🐧 schrieb: > ist das überhaupt im scope von Cargo Naja, die ganzen Alternativen-Automatismen von apt hat cargo wohl eher nicht. Und ich wüsste auch nicht wozu. Mit cargo baut man eine Applikation und die dependencies. Und das lässt sich über Features konfigurieren. Wenn du jetzt gerne eine andere Dep verwenden würdest, musst du das Feature selektieren. Es steht ja jedem frei hier apt drüberzustülpen und diese ganze Dependency-Magie zu bauen.
S. R. schrieb: > Ich finde es interessant, wie die Cargo-Proponenten dafür trommeln, dass > man > (a) ausschließlich die neuesten Versionen nutzt; Ich denke das hat niemand gesagt. Ich jedenfalls nicht. Ganz im Gegenteil wurde ja aufgezeigt, dass man mehrere Möglichkeiten hat. Man pinnt eine Version oder man nutzt halt semantic versioning. Es gibt viele Arten die Dependency-Versionen festzulegen. Einfach mal die Cargo Doku lesen. > (b) keine Code-Reviews macht, sondern automatisiert testet; Das ist jetzt aber stark verkürzt zitiert. Es geht darum, dass man eher keine Reviews der Dependencies macht, weil die ja schon ein Review und eine Qualitätsfreigabe vom Autor haben. > (c) sich auch bei hunderten von Abhängigkeiten mal nicht so anstellen > soll; Wer hat das gesagt? > (d) verschwinden soll, wenn's einem nicht passt. Stänkere bitte woanders herum.
Packet-Manager und die Probleme/Vorteile, die man sich damit einhandelt sind ja wohl kein Alleinstellungsmerkmal von Rust. Die fehlende Ahnung vom - Konzept einer Versionsverwaltung - Open Source Arbeit und - Öffentliches Packet-Repository und - alte Rechner - falsche Bedienung - noch nicht mal das richtige Log posten, damit einem geholfen werden kann ... bei einem Problem in ... einem von tausenden Paketen ... in einem Thread wo das vollkommen off-topic ist sind absolute dämliche Argumente. Ja es sind immer die Anderen schuld. Besonders die Leute, die einem freiwillig und ungefragt ihre Arbeitsstunden in Form von funktionierenden Bibliotheken zur Verfügung stellen. Entweder selber machen oder nutzen. Oder vielleicht selbst zum Projekt beitragen? Das mag ein Diskussionsthema sein, aber zuerst einmal ist das eine Frage des Charakters. Zu Cargo: Niemand wird gezwungen Cargo zu benutzen um mit Rust zu arbeiten! Das ist zwar totaler Blödsinn, so "frei wie ein Vogel" zu arbeiten, aber wahr und möglich. Das gilt auch für Conan, dub, npm, leinen, nuget, etc., pp. Wer die Anforderung hat mit absolut strikten und lokalen Abhängigkeiten zu arbeiten kann das tun. Dazu muss man nur die Scheiß Anleitung lesen. Sorry für den Kraftausdruck.
MaWin schrieb: > 🐧 DPA 🐧 schrieb: >> ist das überhaupt im scope von Cargo > > Naja, die ganzen Alternativen-Automatismen von apt hat cargo wohl eher > nicht. > Und ich wüsste auch nicht wozu. > > Mit cargo baut man eine Applikation und die dependencies. Und das lässt > sich über Features konfigurieren. Wenn du jetzt gerne eine andere Dep > verwenden würdest, musst du das Feature selektieren. Und du hinterfragst nicht, ob das eine gute Sache ist, oder was für Auswirkungen auf die resultierende Software das hat? Diese Limitation wird auch direkt negative Netzwerkeffekte nach sich ziehen. Es werden alle Anwendungen, die aus vielen unabhängigen Anwendungen, bestehen, oder anderweitig komplett unabhängige Implementationen für gewisse Programmteile benötigen, aber kein konkretes voraussetzen, benachteiligt. Eigentlich werden sogar sämmtliche reinen Runtimeabhängigkeiten benachteiligt. Diese würden bei der Verwendung nämlich einen Mehraufwand bedeuten, da Cargo einem bei diesen Dependencies nicht weiterhilft, anders als bei compile time dependencies. Im Grunde bedeutet das, dass die Praxis, alles mit compile time dependencies zu machen inzentiviert wird. Da hilft mir auch nicht, dass ich weiterhin apt dass ich selbst für einige Distros mit apt das Problem für meine eigenen Anwendungen lösen könnte, denn dies ist ein Netzwerkeffekt, also etwas, dass sich auf mit Cargo verwaltete Software allgemein auswirkt. Man sieht hier schön, das geht so weit, dass den Entwicklern schon gar nicht mehr klar ist, dass es das nicht die Einzige Möglichkeit ist, oder wozu unabhängige und/oder runtime-only Abhängigkeiten gut sein sollen. Der Effekt, den sowas auf die Software haben dürfte, sollte eigentlich jedem offensichtlich sein: Weniger bis keine zur Runtime Auswählbaren, weglassbare oder Austauschbare Komponenten. Daraus folgt auch weniger Flexibilität für den Endnutzer, sowie weniger Auswahlmöglichkeiten allgemein. Es würde mich nicht erstaunen, wenn auch die Interoperation und Integration voneinander unabhängiger Programme, und damit die UX des Gesammtsystems, darunter leidet. Das ständige Argument "aber theoretisch könntest du/man ja" überall nervt mich auch etwas. Es ist ja immer schön, was ich selbst alles anders machen könnte, aber deshalb ist mir nicht egal, wie sich die Freie Software Welt insgesamt entwickelt. Das hat dann nämlich nachher auch wieder direkte Folgen für mich.
🐧 DPA 🐧 schrieb: > Und du hinterfragst nicht, ob das eine gute Sache ist, oder was für > Auswirkungen auf die resultierende Software das hat? > > Diese Limitation wird auch direkt negative Netzwerkeffekte nach sich > ziehen. > Es werden alle Anwendungen, die aus vielen unabhängigen Anwendungen, > bestehen, oder anderweitig komplett unabhängige Implementationen für > gewisse Programmteile benötigen, aber kein konkretes voraussetzen, > benachteiligt. > Eigentlich werden sogar sämmtliche reinen Runtimeabhängigkeiten > benachteiligt. > Diese würden bei der Verwendung nämlich einen Mehraufwand bedeuten, da > Cargo einem bei diesen Dependencies nicht weiterhilft, anders als bei > compile time dependencies. Das ist doch kompletter Unsinn. Mit der Argumentation wäre C/C++ noch viel eingeschränkter, weil es überhaupt kein Build- und Paketsystem mitbringt. Cargo ist eine Option. Niemand ist gezwungen Rust-Programme mit Cargo zu bauen und zu vertreiben. Wenn du dein Rust-Programm mit CMake bauen willst und mit Apt vertreiben willst, dann ist das selbstverständlich möglich und es steht dir frei. Davon zu sprechen, dass Cargo eine Limitation für Rust ist, ist ganz einfach Unsinn. Es zeigt nur auf, dass derjenige, der das behauptet, keine Ahnung von Rust hat. Eine zusätzliche Option (Cargo) kann nie eine Limitation sein. Das schließt sich logisch einfach aus. Lies den Text von Jedzia D. Dort ist alles sehr schön zusammengefasst.
Hast du mein Argument überhaupt gelesen? Ich sage nicht cargo ist eine Limitation, ich sage Cargo hat eine Limitation (bezüglich runtime dependencies). Ich sage sogar genau, was diese Limitation ist. Auch dass man Cargo nicht verwenden muss ist nicht relevant bei meiner Argumentation. In der praxis wird es verwendet, und auch wenn es die theoretische mögichkeit gibt, es nicht zu verwenden, ist dies in den meisten Anwendungsfällen bei Rust nicht besonders praktikabel. Cargo wird verwendet. Es hat Designentscheidungen, und damit wie jede Software auch Limitationen. Meine Argumentation basiert darauf, dass /eine konkrete dieser Limitationen/, gewisse Softwarearchitekturen stärker als andere begünstigt, und im Umkehrschluss einige Softwarearchitekturen beungünstigt, welche ich aber wünschenswert finde, da sie für den Endbenutzer einige Vorteile (in dem konkreten Fall mehr Auswahl / Modularität zur runtime) bietet. Es ist ein Nebeneffekt, der durch die breite Nutzung des Systems und dessen Eigenheiten entsteht. Ein Netzwerkeffekt. Aber ich seh schon, mit euch lässt ist nicht reden. Einfach sämtliche Kritik Ignorieren ("Das ist doch kompletter Unsinn"), und die Leute in eine Schublade packen ("müssen wohl alles rust nicht-versteher sein"), ist ja auch einfacher, als zu versuchen, die Kritiken & Argumente zu verstehen, das ganze mal von einem anderen Blickwinkel zu betrachten, und selbst mal darüber nachzudenken.
🐧 DPA 🐧 schrieb: > und auch wenn es > die theoretische mögichkeit gibt, es nicht zu verwenden, ist dies in > den meisten Anwendungsfällen bei Rust nicht besonders praktikabel. Blödsinn. Warum soll das so sein? Niemand zwingt dich Cargo zu verwenden.
MaWin schrieb: > Niemand zwingt dich Cargo zu verwenden. Dann kannst du sicher schnell eine Beschreibung aus deinem Ärmel schütteln, wie man z.B. das oben genannte RAV1E ohne cargo baut?
MaWin schrieb: > Niemand zwingt dich Cargo zu verwenden. Wie schon gesagt, das spielt bei meiner Argumentation oben bewusst keine rolle. Es genügt, dass es von so ziemlich jedem verwendet wird.
MaWin schrieb: > Blödsinn. Bitte beende diese Diskussion an dieser Stelle. Mit deiner Art von „Argumentation“ tust du weder Rust einen Gefallen, noch überzeugst du damit irgendwen. (Dies war ein „Warnschuss“ in meiner Eigenschaft als Moderator. Ich möchte, dass die Diskussion wieder auf ein sinnvolles Niveau kommt.)
mh schrieb: >> Niemand zwingt dich Cargo zu verwenden. > > Dann kannst du sicher schnell eine Beschreibung aus deinem Ärmel > schütteln, wie man z.B. das oben genannte RAV1E ohne cargo baut? Warum? Schüttelst du dann eine Beschreibung aus deinem Ärmel, wie man OpenSSL ohne Make baut? 🐧 DPA 🐧 schrieb: > Es genügt, dass es von so ziemlich jedem verwendet wird. Und deshalb bist du gezwungen, es selbst auch zu verwenden? Warum? Jörg W. schrieb: >> Blödsinn. > Bitte beende diese Diskussion an dieser Stelle. Ich behaupte hier nicht ständig Unwahrheiten. > Mit deiner Art von „Argumentation“ tust du weder Rust einen Gefallen, > noch überzeugst du damit irgendwen. Ja. Zu behaupten Cargo wäre mit Rust untrennbar verbunden, tut Rust wirklich keinen gefallen. Weil es ganz einfach falsch ist.
MaWin schrieb: > Jörg W. schrieb: >>> Blödsinn. >> Bitte beende diese Diskussion an dieser Stelle. > > Ich behaupte hier nicht ständig Unwahrheiten. Es geht weniger um Inhalte als um deinen Diskussionsstil. Der ist unterirdisch, und den möchte ich in diesem Thread nicht mehr dulden.
MaWin schrieb: > mh schrieb: >>> Niemand zwingt dich Cargo zu verwenden. >> >> Dann kannst du sicher schnell eine Beschreibung aus deinem Ärmel >> schütteln, wie man z.B. das oben genannte RAV1E ohne cargo baut? > > Warum? > > Schüttelst du dann eine Beschreibung aus deinem Ärmel, wie man OpenSSL > ohne Make baut? Nö, ich habe aber auch nicht behauptet, dass man C ohne maku und co sinnvoll einsetzen kann. Mal davon abgesehen, dass keine der besprochenen cargo Features etwas mit make zu tun haben.
mh schrieb: > ich habe aber auch nicht behauptet, dass man C ohne maku und co > sinnvoll einsetzen kann. Das habe ich auch nicht behauptet. Aber du hast den Zusammenhang hergestellt, dass man Rust nicht verwenden kann, weil irgendeine X-beliebige Dependency Cargo verwendet. Das ist ganz einfach aus vielen Gründen falsch. Allen voran, dass man halt die Dependency nicht verwenden muss. Man kann eine Alternative verwenden. Oder den Code selbst neuschreiben. Aber selbst wenn man die Dep unbedingt verwenden will, dann kann man sie natürlich auch mit Aufwand ohne Cargo übersetzen. Genau wie man OpenSSL auch auf jedes andere Buildsystem umstellen kann. Warum ist es kein Problem, wenn OpenSSL Make benutzt, und warum ist es ein Problem, wenn irgendeine Rust-Lib Cargo nutzt?
MaWin schrieb: > Schüttelst du dann eine Beschreibung aus deinem Ärmel, > wie man OpenSSL ohne Make baut? Ein sinnvoller Vergleich wäre vielleicht mit den Autotools, CMake oder einem anderen Buildsystem statt mit make gewesen. Es spielt keine Rolle, ob man theoretisch Rust auch ohne Cargo verwenden könnte. Solange Cargo die Basis für so ziemlich alle Rust-Projekte ist, das Rust-Ökosystem auf Cargo aufbaut und die Nichtverwendung von Cargo deutlich teurer ist als die Verwendung, ist das schlicht irrelevant. Das ist ähnlich wie App-Entwicklung für Android und Gradle. Ja, kann man theoretisch auch ohne machen, praktisch ist das aber unmöglich.
S. R. schrieb: > das Rust-Ökosystem auf Cargo aufbaut Tut es aber halt nicht. Informiert euch halt mal, bevor ihr hier so einen (das darf ich ja nicht mehr schreiben) postet. Man kann Rust z.B. auf kleinsten Microcontrollern verwenden. Ohne Buildtime-Download. Ohne Cargo. Ohne stdlib. bare metal. Es gibt ü-ber-haupt kein Zwang zu Cargo. Das liegt vollständig in der Gewalt des Entwicklers. Aber die meisten benutzen es natürlich, weil es halt sehr gut ist. Aber niemand (In Worten: Niemand) zwingt dich auch nur im Geringsten das alles zu nutzen. Bei jeder beliebigen C-Lib Dependency ist das auch nicht anders. Oder beschwerst du dich auch, dass es ja untragbar sei, dass Depencency-X Buildsystem Y nutzen? Warum nicht?
DPA, könntest Du bitte ein konkretes Beispiel dafür liefern, was Du mit der von dir genannten Inflexibilität ins Sachen Runtime-Code meinst? Und was das wirklich mit Cargo zu tun haben soll?[4] Cargo ist das "make" und der Paketmanager, das Test-Tool ... einfach das build-utility von Rust. Im Beispiel von Dergute W mit rav1e sind einige der aufgelösten Pakete nötig um zusätzlich zum Code von rav1e ein spezielles Build-System[1] extra für diesen Spezialfall zu erschaffen. Meta, Meta, anders übersetzt: Extrem kompliziert und extrem flexibel.Dieses System erlaubt gleichzeitig einen Bootloader für PowerPC zu schreiben und mit 'cargo run' die ganze Chaussee in QEMU zu starten. Alles zentral, alles ganz einfach (natürlich nicht hinter den Kulissen)[3]. Da ist nur eine Abhängigkeit zu Cargo: Es ist die Eierlegendewollmilchsau, die dein rav1e baut. Du meinst bestimmt etwas anderes aber:
1 | rustup target list |
erschlägt dich mit Runtimes, fehlt deine noch?[2] Jedes Komponentensystem, dass Runtime-Code nachlädt ließe sich über C-Schnittstellen schnell, oder als Eigenimplementierung mit Aufwand auch in Rust lösen. Die flexibilität von Cargo kannst auch Du nutzen um ein komplett neues Buildsystem zu erfinden. Etwa 1. Hilfs-Build-Tool wird gebaut 2. RISC-X helper/spezial-linker extra für diese Hardware-Konstellation wird gebaut 3. build: Applikation und Virtuelle Maschine für den internen Flash 4. build: VM-Code für das externe EEprom. 5. Spezielles Flash-Tool für diese Hardware wird gebaut 6. VM-Code in den externen Speicher laden 7. MCU flashen 8. Debugger starten ... X. Auf die Erfindung von Risc-X warten:) Viele Komponenten und Bibliotheken haben Schalter mit denen man das verhalten der Runtime beeinflussen kann. Es steht nicht unter Strafe selbst welche einzubauen. ([profile] und Configuration keys)[5] Wie wäre es mit der Erzeugung und Einbindung einer Shared-Library zur Laufzeit? -> https://github.com/manthanrtilva/runtime_plugin cranelift-simplejit -> Eine einfache JIT-Bibliothek, die von Cranelift unterstützt wird, Gruss an Alex dynasm -> Ein Plugin zum Zusammenstellen von Code zur Laufzeit. In Kombination mit dem Runtime Crate Dynasmrt können damit JIT-Compiler einfach geschrieben werden. Es ist auch keine gute Diskussionskultur Fakten einfach nach belieben zu ignorieren, wie die mehrmals erwähnte Freiheit etwas anders als Cargo zu benutzen. Ein Spezialfall? Ja! Genau so wie die Fähigkeit Runtime Code flexibel zu benutzen. [1]https://crates.io/crates/nasm-rs [2]https://github.com/rust-lang/rustup/issues/215 [3]https://github.com/rust-osdev/bootimage [4]https://prev.rust-lang.org/en-US/faq.html#does-rust-have-a-runtime [5]https://doc.rust-lang.org/cargo/reference/config.html Bleibt cool, ist doch nur ein Tool. Davon gibt es viele:)
Achja, noch ganz nebenbei: https://github.com/rust-lang/rust Hier lebt der Rust Compiler https://github.com/rust-lang/cargo Hier wohnt Cargo Das sind doch zwei Verschiedene Orte, oder irre ich mich? Falls die wirklich verheiratet sind, wie Einige hier sagen, dann verstehe ich die Gerüchte um Trennung und den Rosenkrieg, der nicht nur hier im Forum tobt. Über das obige nachzudenken ist kein Muss. Down voten reicht;)
Jedzia D. schrieb: > DPA, könntest Du bitte ein konkretes Beispiel dafür liefern, was Du mit > der von dir genannten Inflexibilität ins Sachen Runtime-Code meinst? Und > was das wirklich mit Cargo zu tun haben soll?[4] Das habe ich doch nun wirklich schon sehr Detailliert beschrieben, aber ich Versuches trotzdem nochmal. Als Beispiel nehme ich mal ein "Hello World" Program, um es so simpel wie möglich zu halten. Die Sprache und Art von Interface (Programm, Library funktionen, dbus, rest, etc.) ist für das eigentlich unerheblich, darum bringe ich mal 2 Beispiele mit unterschiedlichen Interfaces und Sprachen. --- Zunächst mal ein Beispiel mit C: Erstmal wird ein interface definiert. Dass kann teil von Projekt A sein, oder separat, oder generiert, etc. Hier will ich ein "greeter interface". Ich definiere es so: Interface: greeter/greeter.h:
1 | void greet(const char* who); |
Projekt A, von Person A, die eigentliche Anwendung: Compile time dependencies: greeting interface Runtime dependencies: Eine greeter implementation, aber keinen bestimmten! A/main.c:
1 | #include <greeter.h> |
2 | int main(int argc, char* argv[]){ |
3 | greet(argc > 1 ? argv[1] : "World"); |
4 | }
|
1 | cd A |
2 | # dummy library, damit ich keinen loader schreiben muss und kein dlopen brauche |
3 | gcc -x c - <<<"void greet(const char* who){}" -shared -fPIC -o libgreeter.so |
4 | # anwendung bauen |
5 | gcc main.c -I ../greeter -L "$PWD" -Wl,-rpath,'$ORIGIN' -lgreeter -o A.elf |
6 | # dummy library löschen |
7 | rm libgreeter.so |
8 | cd .. |
Projekt "hallo", von Person B: Eine greeter implementation: "Hallo" Greeter: Compile time dependencies: greeting interface Runtime dependencies: keine hallo/main.c:
1 | #include <stdio.h> |
2 | #include <greeter.h> |
3 | void greet(const char* who){ |
4 | printf("Hello %s!\n", who); |
5 | }
|
1 | cd hallo |
2 | gcc -shared -fPIC -I ../greeter main.c -o libgreeter.so |
3 | cd .. |
Projekt "Geburtstag", von Person C: Eine greeter implementation: Geburtstags Greeter: Compile time dependencies: greeting interface Runtime dependencies: keine geburtstag/main.c:
1 | #include <stdio.h> |
2 | #include <greeter.h> |
3 | void greet(const char* who){ |
4 | // TODO: Bake a cake
|
5 | printf("Happy birthday %s!\n", who); |
6 | }
|
1 | cd geburtstag |
2 | gcc -shared -fPIC -I ../greeter main.c -o libgreeter.so |
3 | cd .. |
Man beachte, ist das Interface separat, sind die Projekte "A", "Hallo" und "Geburtstag" sind beim kompilieren unabhängig voneinander. Falls man des Interface in "A" platziert, haben "Hallo" und "Geburtstag" eine compile time Abhängigkeit von "A". "A" hat in jedem fall keine compile time Abhängigkeit von "Hallo" oder "Geburtstag". "A" hat aber eine runtime dependecy, es braucht eine "greeter" implementierung. "Hallo" und "Geburtstag" bieten eine "greeter" implementierung an. Der Witz ist, es ist nachträglich möglich, für den Benutzer ohne neu kompilieren, die greeter Implementation zu wählen:
1 | $ cp A/A.elf . # Programm installieren |
2 | $ ./A.elf |
3 | ./A.elf: error while loading shared libraries: libgreeter.so: cannot open shared object file: No such file or directory |
4 | $ cp hallo/libgreeter.so . # hallo greeter installieren |
5 | $ ./A.elf |
6 | Hello World! |
7 | $ cp geburtstag/libgreeter.so . # hallo greeter ersetzen mit geburtstag greeter |
8 | $ ./A.elf |
9 | Happy birthday World! |
10 | $ ./A.elf Tom |
11 | Happy birthday Tom! |
Und die 3 Projekte können dennoch völlig unabhängig voneinander entstanden sein, von unterschiedlichen Autoren usw. --- Beispiel 2, mit bash, nochmal das selbe, aber Anwendungen als Interface: Inteface greeter:
1 | greeter [name] |
Projekt "A": A.sh:
1 | #!/bin/sh
|
2 | PATH="$PATH:$(dirname "$0")" |
3 | arg="$1" |
4 | [ $# -lt 1 ] && arg=World |
5 | greeter "$arg" |
Projekt "hallo": hallo_greeter.sh:
1 | #!/bin/sh
|
2 | echo "Hallo $1!" |
Projekt "geburtstag": birthday_greeter.sh:
1 | #!/bin/sh
|
2 | # TODO: Bake a cake
|
3 | echo "Happy birthday $1!" |
Anwendung:
1 | $ ./A.sh |
2 | ./A.sh: 5: ./A.sh: greeter: not found |
3 | $ ln -s hallo_greeter.sh greeter # hallo greeter verwenden |
4 | $ ./A.sh |
5 | Hallo World! |
6 | $ ln -sf birthday_greeter.sh greeter # birthday greeter verwenden |
7 | $ ./A.sh |
8 | Happy birthday World! |
9 | $ ./A.sh Tom |
10 | Happy birthday Tom! |
Auch hier wieder, A braucht eine greeter implementation. hallo greeter und birthday greeter bieten eine greeter implementation. hallo greeter und birthday greeter hängen nicht von A ab (ich könnte sie einfach alleine aufrufen). --- Das ist ein Beispiel einer Abhängigkeitsstruktur, die sich mit Cargo meines wissens nicht ohne weiteres abbilden lässt. Bildet man nur die tatsächlichen compile time Abhängigkeiten ab, muss man sich manuell ein Backend suchen. Mit z.B. apt ist das anders, dort kann ich die Abhängigkeit, und meine bevorzugter Implementation, genau so angeben. In den meisten fällen werden die Entwickler daher vermutlich nicht diese struktur wählen, es läuft dann nämlich nicht einfach so, nach dem builden, weil Cargo die runtime dependency ja nicht kennt. Ein Entwickler von Projekt A wird sich deshalb normalerweise kein Interface ausdenken, er wird sich statdessen den "hallo greeter" oder den "birthday greeter" aussuchen, und eine direkte kompile time Abhängigkeit darauf machen. "hallo greeter" und "birthday greeter" haben auch keinen Grund mehr, einem gemeinsamen Interface gerecht zu werden. Sie werden vermutlich ihr eigenes Interface machen, und dadurch nicht mehr zur runtime austauschbar sein. Der Entwickler müsste dann einen mehraufwand betreiben, wenn er beide greeter unterstützen möchte. Wenn beide zur runtime verfügbar sein sollen, hätte man dann zur compile time zu beiden eine Abhängigkeit. Andernfalls müsste man halt zur compile time wählen. Ein anderer Entwickler, der einen konkurierenden Greeter schreibt, könnte der Endanwender nachher auch nicht einfach installieren, selbst wenn dieser das selbe Interface hätte, entweder müsste erst jemand die Dependencies jeder einzelnen Anwendung, die einen Greeter nutzt, anpassen, oder der Endanwender müsste die Dependency bei sich lokal anpassen, und neu Kompilieren. Jenachdem, wo das Interface ist, wer es festlegt, usw. beeinflusst das auch die Anforderungen, das Design, die Art der Interessen daran (ein gutes Interface entwickeln (unabhängig entwickeltes Interface) vs. ein Interface für was ich will (Interface in Anwendung, welches es nutzt) vs. ein Interface, mit dem ich Alleinstellungsmerkmale habe (Interface in Library)), etc. Ich hoffe, es ist nun absolut klar, was die Problematik ist, auf die ich hinaus wollte.
Und vorneweg schonmal, ja, ich weiss dass man das in rust implementieren kann. Darum geht es mir nicht. Es geht um Cargo, und welche Strukturen dort einfacher umzusetzen sind.
🐧 DPA 🐧 schrieb: > Und vorneweg schonmal, ja, ich weiss dass man das in rust implementieren > kann. Und wo ist dann das Problem? > Es geht um Cargo, Warum? Warum willst du Cargo verwenden, wenn du doch bereits angeblich erkannt hast, dass es deinen Usecase nicht unterstützt?
MaWin schrieb: > Warum willst du Cargo verwenden, wenn du doch bereits angeblich erkannt > hast, dass es deinen Usecase nicht unterstützt? Auch wenn ich es nicht nutze, nutzen es so ziemlich alle anderen. Cargo beeinflusst durch sein Design die Architektur von mit cargo erstellter Software, und damit im grossen und granzen betrachtet von Rust Anwendungen. Mit der steigenden Relevanz von Rust in Linux und dem OpenSource umfeld allgemein, beeinflusst das das gesammte OpenSource umfeld. Ob ich persönlich cargo nutze oder nicht, hat keinen Einfluss auf dessen Netzwerkeffekte insgesammt, und ist daher nicht relevant. Um es nochmal gesagt zu haben: 🐧 DPA 🐧 schrieb: > Es ist ja immer schön, was ich selbst alles anders machen könnte, aber > deshalb ist mir nicht egal, wie sich die Freie Software Welt insgesamt > entwickelt. Das hat dann nämlich nachher auch wieder direkte Folgen für > mich.
🐧 DPA 🐧 schrieb: > Und vorneweg schonmal, ja, ich weiss dass man das in rust implementieren > kann. Darum geht es mir nicht. Es geht um Cargo, und welche Strukturen > dort einfacher umzusetzen sind. Du unterschlägst in deinen Beispielen wie du zum ausführbaren Code kommst. GCC und make fürs obere? Und bash fürs shell Beispiel? So, bash-runtime-interpreter + make sind hier das Äquivalent zu Teilen der Funktionalität von Cargo. println!("Hello Denkfehler. Try https://doc.rust-lang.org/rust-by-example/mod.html "); Ist so merkwürdig formatiert wegen dem Spass und der URL. 11. Crates und 12. Cargo nicht vergessen zu lesen. Anderes zum anschauen als Hilfe gegen deine DLL-Hell(aber nur die c runtime):
1 | rustflags = ["-C", "target-feature=+crt-static"] |
libgreeter.so Beispiel ... Rust: Danke, das es dieses Probleme dort nicht gibt. Du vergisst, dass alle Bibliotheken als source-code vorliegen. (Das ist dieses ... Cargo + crates.io). Wenn du Einzelnes wie Bibliotheken in ein apt/deb/etc-paket verpackst und nicht mit deiner Versionierung klarkommst ist das nicht das Problem von Cargo. Ähnliches Beispiel: Ubuntu Python-packages, die im Ubuntu repository vorliegen. Aber manche Schlaumeier installieren mit pip. Das geht ja auch immer gut. Notiz: Ich sollte einen https://crates.io/crates/dpa.greeter erstellen:) P.S.: Für uns Gentoo-Weiber ist das völlig normal und ein alter Hut. Inklusive der Probleme. Wir reden hier schließlich über Software. Zeig mir eine ohne Probleme;)
:
Bearbeitet durch User
Jedzia D. schrieb: > Du unterschlägst in deinen Beispielen wie du zum ausführbaren Code > kommst. GCC und make fürs obere? Und bash fürs shell Beispiel? Nein, die Kommandos zum Builden sind bei meinen Beispielen vorhanden, jeweils direkt unter dem Code. > Ist so merkwürdig formatiert wegen dem Spass und der URL. 11. Crates und > 12. Cargo nicht vergessen zu lesen. Hab ich. Das löst aber das zugrundeliegende Problem nicht. > Anderes zum anschauen als Hilfe gegen deine DLL-Hell(aber nur die c > runtime): Das ist keine DLL Hell, das ist gutes Design. > Du vergisst, dass alle Bibliotheken als source-code vorliegen. Ich habe auch schon gentoo verwendet, und grosse rust projekte kompiliert. Das gehört aber nicht zu meinen Lieblingstätigkeiten. Deshalb weiss ich binary distributionen und runtime dependencies sehr zu schätzen. > Wenn du Einzelnes wie Bibliotheken in ein apt/deb/etc-paket verpackst Mach ich doch gar nicht. Apt ist lediglich ein Beispiel für einen Paketmanager, der diese Paketstruktur sauber abbilden kann. > und nicht mit deiner Versionierung klarkommst ist das nicht das Problem > von Cargo. Wenn Cargo keinen Mechanismus vergleichbar zum Provides Mechanissmus von apt hat, und die Dependencies für gewisse Softwarearchitekturen schlicht nicht modellierbar sind, ist das sehr wohl ein Problem von Cargo. Jedzia D. schrieb: > Notiz: Ich sollte einen https://crates.io/crates/dpa.greeter erstellen:) Wenn du willst. Lass mich vorher die Problematik nochmal zusammenfassen: 1) Es gibt mindestens 3 crates: * Die Anwendung A (Entspricht oben der A.elf, btw. der A.sh) * Der hallo greeter * Der geburtstags greeter 2) Beim ausführen von A mit "cargo run" muss eine greeter implementation durch cargo bereits automatisch bereitgestellt worden sein, der user soll keinen Mehraufwand haben. 3) Die Anwendung A darf aber nicht explizit von einem oder beiden greetern abhängen, es soll nur angeben, dass es irgend einen braucht, es darf höchstens eine Präferenz angeben. Andere sollen auch greeter crates erstellen können, die man dann als Alternative wählen könnte, und Nutzer müssen sich einfach alle Optionen anzeigen lassen können. Das andere unabhängig welche über das repo (z.B. crates.io) hinzufügen können, ist der Witz an der ganzen Sache. 4) Es muss eine einfache Standardlösung sein, denn andernfalls wäre diese Architektur ja unter Entwicklern nicht mit direkten Dependencies konkurrenzfähig. Ich glaube ja nicht, dass das möglich ist, aber ich lasse mich gerne eines besseren belehren.
🐧 DPA 🐧 schrieb: > Ich glaube ja nicht, dass das möglich ist, aber ich lasse mich gerne > eines besseren belehren. In diesem Thread wurden bereits Möglichkeiten genannt, Dinge dynamisch zu laden. Aber davon abgesehen, funktionieren diverse Dinge in Rust halt anders. Da muss man sich dann mit abfinden, oder man verwendet es halt nicht, wenn man seine alten C-Techniken weiterverwenden will. Rust linkt eben grundsätzlich statisch. Das hat aber wiederum auch gar nichts mit Cargo zu tun. Aber trotzdem kann man natürlich Funktionen als DLLs aufrufen. Wie, wurde bereits erklärt. Du kannst dir unendlich viele synthetische Beispiele in C implementieren, die in Rust nur schwerer als in C zu lösen sind. z.B. aufgrund des Borrow-Checkers. Aber das ist eben so gewollt. Wenn man in Rust programmiert, muss man grundsätzlich umdenken. Wenn dir das nicht gefällt, dann ist Rust halt nichts für dich.
Zum Thema "Dynamisches Linken": Wenn dein C- oder C++-Programm eine bestimmte Lib in einer bestimmten Version vorraussetzt dann hast du erstmal drei Möglichkeiten, die zu deployen (keinen Anspruch auf Vollständigkeit). 1) Du schreibst in die Doku dass sich der User lib XYZ in Version 123 händisch auf seinen Rechner packen soll. Das ist die hässliche Lösung. 2) Du legst die lib deinem Binary bei. Das ist die Windows-Lösung. 3) Du löst die Abhängigkeit über einen Paketmanager auf, z.B. apt oder pacman. Das ist die Linux-Lösung. Lösung 3 funktioniert mit Rust-Binaries genauso wie mit C-Binaries und löst exakt das von DPA geschilderte Problem. Sogar optionale Abhängigkeiten oder Alternativen sind möglich. Auch in C/C++ werden Laufzeitabhängigkeiten auf einem aktuellen Linux über den Paketmanager aufgelöst. Warum ist das bei Rust ein Problem?
MaWin schrieb: > In diesem Thread wurden bereits Möglichkeiten genannt, Dinge dynamisch > zu laden. Dass das möglich ist, habe ich, wie ich schon mehrfach auch schrieb, nicht bestritten. Nochmal, es geht um die Limitationen des Abhängigkeitssystems für Cargo, und dessen daraus resultierenden Einfluss auf die Programmarchitektur der darauf basierenden Programme, und damit das Rust-Ökosystem insgesamt. Wenn ich so darüber nachdenke, fällt mir außerdem auf, das die selbe Problematik ebenfalls mit compile time Dependencies existiert, für diese bietet Cargo ebenfalls keinen einfachen Provides mechanismus. Statisches linken kann die Problematik also nicht lösen. Die Problematik ist von der Art der Schnittstelle auch unabhängig, vergleichbare Architekturen könnte ich auch mit Rest, dbus, etc. nachbilden. > Aber davon abgesehen, funktionieren diverse Dinge in Rust halt anders. > Da muss man sich dann mit abfinden, oder man verwendet es halt nicht, > wenn man seine alten C-Techniken weiterverwenden will. Wie ich bereits weiter oben gesagt habe, erschwert dies in dem von mir aufgezeigten Fall die Implementation von Plugin und Backend Systemen, wo man nicht selbst alle Plugins, Backends, etc. schreibt / selbst kennt, ungemein, was zwangsläufig negative Folgen auf Dinge wie die Flexibilität und Auswahlmöglichkeiten des Endnutzers bei sämtlicher mit Cargo gebauter Software, und letztendlich sämtliche OpenSource Software haben muss, da diese Architektur dadurch seltener verwendet wird, als dies andernfalls der Fall gewesen wäre. Das halte ich für eine negative Entwicklung, deshalb halte ich es auch für notwendig, diese Problematik aufzuzeigen. Und wie ich schon mehrfach schrieb, auch wenn ich selbst cargo nicht verwenden würde, als Nutzer einer Distribution mit Binärpaketen (Debian/Devuan), bin ich trotzdem von Fallout dieses Problems betroffen. Wenn das Entwicklungsmodell diese Form der Modularität behindert, habe ich dann nämlich, wenn ich mal eines der Programme oder Libraries als Endnutzer brauche, weniger Auswahlmöglichkeiten / Einstellungsmöglichkeiten. Le X. schrieb: > Lösung 3 funktioniert mit Rust-Binaries genauso wie mit C-Binaries und > löst exakt das von DPA geschilderte Problem. Sogar optionale > Abhängigkeiten oder Alternativen sind möglich. > > Auch in C/C++ werden Laufzeitabhängigkeiten auf einem aktuellen Linux > über den Paketmanager aufgelöst. > Warum ist das bei Rust ein Problem? Weil bei der Entwicklung so ziemlich jeder Cargo verwendet, um bei der Entwicklung seine Abhängigkeiten zu verwalten. Wenn diese Art der Abhängigkeit, die ich oben beschrieb, also schon dort, bereits in der Entwicklung, mit dem von allen verwendeten Tool, nicht ohne weiteres realisierbar ist, werden die Entwickler das schlicht nicht so umsetzen. Und wenn die unabhängigen Plugins und Backends im vornherein schon nicht entwickelt werden, kann man die nachher auch nicht in apt Pakete verpacken.
🐧 DPA 🐧 schrieb: > Weil bei der Entwicklung so ziemlich jeder Cargo verwendet, um bei der > Entwicklung seine Abhängigkeiten zu verwalten. Wenn diese Art der > Abhängigkeit, die ich oben beschrieb, also schon dort, bereits in der > Entwicklung, mit dem von allen verwendeten Tool, nicht ohne weiteres > realisierbar ist, werden die Entwickler das schlicht nicht so umsetzen. > Und wenn die unabhängigen Plugins und Backends im vornherein schon nicht > entwickelt werden, kann man die nachher auch nicht in apt Pakete > verpacken. Hast du denn da Erfahrungen aus der Praxis oder ist das eine Vermutung? Man müsste hier mal in etwa gleich komplexe Projekte aus C/C++ und Rust auf die Art des Linkens hin untersuchen.
Beitrag #6557356 wurde von einem Moderator gelöscht.
Ich habe mich mit Rust beschäftigt, und finde dessen Konzepte sehr interessant. Die Erfahrung aus der Softwareentwicklung der letzten Jahrzehnte, in neue Sprachen einfließen zu lassen, halte ich für einen richtigen Schritt. In unserer Firma gibt es Gruppen in denen Rustthemen auch immer wieder diskutiert werden. Momentan beruht das aber ausschließlich auf persönlichen Interessen. Im industriellen Bereich sind Produktlebenszeiten von 20...30 Jahren nichts besonderes. Die embedded Software dieser Produkte muss dann auch über diesen Zeitraum hinweg wartbar sein. Wartbar heißt nicht das eine Firmware in einer neue Sprache neu geschrieben wird, es wird nur das Bestehende am Laufen gehalten. Anders geht es aufgrund der hohen Kosten auch nicht. Wer schon mal mit der Begutachtung von Software zu tun hatte, dem ist klar was ich meine. Es ist also sehr wohl Kontinuität über Jahrzehnte hinweg gefragt. Da habe ich mit Rust noch so meine Zweifel. So lange mit Rust auf Dauer Abhängigkeiten zum Internet bestehen, sehe ich in unserem Bereich keinen Einsatz von Rust im grösseren Umfang.
Julius schrieb: > Es ist also sehr wohl Kontinuität über Jahrzehnte hinweg gefragt. Da > habe ich mit Rust noch so meine Zweifel. So lange mit Rust auf Dauer > Abhängigkeiten zum Internet bestehen, sehe ich in unserem Bereich keinen > Einsatz von Rust im grösseren Umfang. Klar das ist ein wichtiger Faktor um die Produkt-Sicherheit zu gewährleisten. Wo bezieht ihr eure, sagen wir Keil, ST(M) o.ä. Libraries und Frameworks her? Kommt der Werksfahrer?:) In Rust kannst Du genau so manuell oder selbstbestimmt deine Software lokal verwalten. Sogar mit Cargo. Relative Pfade und "Cargo.lock" sind die Stichworte hierzu. https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html
Le X. schrieb: > Hast du denn da Erfahrungen aus der Praxis oder ist das eine Vermutung? Ich kann leider nicht wissen, ob in der Praxis die Software wirklich anders ausgesehen hätte, wenn Cargo einen provides ähnlichen Mechanismus gehabt hätte. Aber ich halte es für naheliegend, dass wenn ein Mechanismus vorhanden ist, dieser auch öfter genutzt wird, mit allen sich daraus ergebenden Folgen, und umgekehrt. > Man müsste hier mal in etwa gleich komplexe Projekte aus C/C++ und Rust > auf die Art des Linkens hin untersuchen. Man sollte das nicht so stark Einschränken. Libraries sind nur eine einer Vielzahl möglicher Arten von Schnittellen. Bei Anwendungsaufruf, REST und dbus Schnittellen z.B., ist es etwas Einfacher, keine \/ eine umgedrehte / Austauschbare Abhängigkeit zu haben, als bei Libraries. Es ist aber auch nicht immer eindeutig, was effektiv von was abhängig ist, ob, von wem und in wie weit das Interface von jemandem kontrolliert / festgelegt wird, welches die normale Richtung ist, etc. Ausserdem gibt es in dem Fall noch die Möglichkeit, dass eine Anwendung / ein Projekt selbst auch Backends beinhaltet, aber trotzdem unabhängige Projekte ebenfalls Backends bereitstellen können. z.B. gibt es in X11 im Xorg Projekt die modesetting DDX, aber es gibt in anderen Repos unabhängige DDX für Nvidia, Intel, AMD, etc. Man kann da so ziemlich alle möglichen und unmöglichen Kombinationen antreffen. Je nach eigenen Kriterien könnte man das dann so oder so einordnen.
🐧 DPA 🐧 schrieb: > wie ich schon mehrfach auch schrieb, Ja Ok. Wir drehen uns im Kreis. Das bringt nichts, denn du bist echt nicht zugänglich für Fakten.
🐧 DPA 🐧 schrieb: > wenn Cargo einen provides ähnlichen Mechanismus > gehabt hätte. Es ergibt überhaupt gar keinen Sinn einen provides-Mechanismus in Cargo zu haben. Cargo ist keine System-Paketverwaltung. Wenn du das brauchst, dann musst du halt apt oder etwas ähnliches nutzen.
Ich verstehe das ganze argumentieren hier irgendwie gar nicht entweder ist man an Rust interresiert und hat aber Probleme mit Cargo, dann involviert man sich und verbessert die Situation, ist open source für direktwerkeln oder man redet mit den Entwicklern bei github oder reddit, dauert eben eine ganze Weile, aber das bei allen Projekten so oder man findet die Sprache nicht gut und lässt es, oder wartet das es besser wird, aber einfach nur meckern oder beschweren ohne das es wenigstens so wirkt als wolle man positive Impulse geben ist einfach sinnfrei
Rust ist eine Programmiersprache, deren Ökosystem relativ eng mit Cargo verknüpft ist. Cargo finde ich blöd, also ist Rust auch nichts für mich. Deswegen bin ich raus. Android scheint langsam auch Rust-Unterstützung zu bekommen, vielleicht fällt da ja ein besseres Buildsystem bei ab.
S. R. schrieb: > Rust ist eine Programmiersprache, deren Ökosystem relativ eng mit Cargo > verknüpft ist. Cargo finde ich blöd, also ist Rust auch nichts für mich. > Deswegen bin ich raus. d.h. die supertollen Rust-Features können das nicht ausbügeln oder gibt es für dich einfach keine supertollen Featuren in Rust?
cppbert schrieb: > S. R. schrieb: >> Rust ist eine Programmiersprache, deren Ökosystem relativ eng mit Cargo >> verknüpft ist. Cargo finde ich blöd, also ist Rust auch nichts für mich. >> Deswegen bin ich raus. > > d.h. die supertollen Rust-Features können das nicht ausbügeln oder gibt > es für dich einfach keine supertollen Featuren in Rust? Was gibt es denn neben Ownership/Memorysafety für supertolle Features in Rust? (Für mich bringt rust da auch keine Vorteile, da modernes C++ in dem Bereich kaum Möglichkeiten für Fehler bietet. Und wenn es einen Fehler gibt fällt der ziemlich sicher dank gcc und clang Sanitizern schnell auf.)
mh schrieb: > Was gibt es denn neben Ownership/Memorysafety für supertolle Features in > Rust? vieles match traits macros-rules proc-macros generics unmutable default enums (nein, enums in Rust sind nicht äquivalent zu C/C++ enums) Option (Sicherer Null-Ersatz) Result (Sicherer Ersatz für Exceptions und generelles Returnwert-gefrickel) ?-Operator (nein, der hat nichts mit ?: zu tun) lifetimes Vernünftiger Parser. Keine Deklarationen. Einfaches und effektives Modulsystem. und vieles vieles mehr. > (Für mich bringt rust da auch keine Vorteile, da modernes C++ in dem > Bereich kaum Möglichkeiten für Fehler bietet. kaum Möglichkeiten < keine Möglichkeiten
MaWin schrieb: > kaum Möglichkeiten < keine Möglichkeiten Bevor einer meckert: Ich meinte "kaum" ist schlechter als "keine". Der Operator sollte nicht die Anzahl vergleichen :)
MaWin schrieb: > mh schrieb: >> Was gibt es denn neben Ownership/Memorysafety für supertolle Features in >> Rust? > > vieles > [...] Und was davon ist jetzt ein Alleinstellungsmerkmal? MaWin schrieb: >> (Für mich bringt rust da auch keine Vorteile, da modernes C++ in dem >> Bereich kaum Möglichkeiten für Fehler bietet. > > kaum Möglichkeiten < keine Möglichkeiten Und mal wieder hast du nur die halbe Aussage zitiert.
mh schrieb: > Und was davon ist jetzt ein Alleinstellungsmerkmal? Alles zusammen. > Und mal wieder hast du nur die halbe Aussage zitiert. Na dann den Rest auch noch. Kommt aber auf die selbe Aussage raus: >Und wenn es einen Fehler gibt fällt der ziemlich sicher dank gcc und clang Sanitizern schnell auf.) "ziemlich sicher" schlechter als "sicher". "schnell" schlechter als "sofort schon beim Compiler".
mh schrieb: > (Für mich bringt rust da auch keine Vorteile, da modernes C++ in dem > Bereich kaum Möglichkeiten für Fehler bietet. Und wenn es einen Fehler > gibt fällt der ziemlich sicher dank gcc und clang Sanitizern schnell > auf.) Smart pointer, RAII und ASan sind nur Dinge die funktionieren wenn man sie auch nutzt, also abhängig von Projektqualität und Mitarbeitern, nach zig Firmen in der Selbständigkeit bei gross und klein kann ich ohne Probleme sage das es genau so viele gibt die davon gar nichts nutzen, zu viel - alles mit shared ptr oder eine wilde Mischung, ich hab noch kein grosses Projekt zur Analyse bekommen das nicht ordentlichen Fehler mit ASan gezeigt hat, egal wie gut und ordentlich das Team gearbeitet hat, ab eine gewissen Menge Mitarbeiter und Codegrösse ist es einfach schwierig, egal wie idealistisch man die Branche, seine eigene Firma oder die Kollegen einschätz, bei Rust kann niemand, wenn er nicht das verteufelte unsafe nutzt auch nur einen der typischen Fehler machen ohne das der Code nicht kompiliert 100.000 C/C++ler können Fehler dieser Art machen, Rustler eben gar nicht und das auch ohne Garbage Collector Bei ein paar guten Entwicklern im Team zu meinen das wäre fast das gleiche lasse ich noch gelten, aber nicht mehr bei hundertausend oder mehr Der Unterschied zwischen Fehler ist-nicht-möglich oder möglich ist riesig wenn du das auf alle potenziellen Entwickler skalierst
Die Frage ist eher ob du den Garantien von Rust glaubst und ob du jedem Entwickler in C/C++ den du kennst und der mit seiner Arbeit der Wirtschaft nutz oder schadet die gleichen Fähigkeit wie dir zusprichst
cppbert3 schrieb: > verteufelte unsafe Unsafe ist nicht verteufelt. unsafe schaltet überhaupt keine von Rusts safety-Garantien ab. Der Borrow-Checker und Memory-Safety von allen Rust-Typen ist weiterhin aktiv. Es gibt lediglich ein paar wenige zusätzliche Möglichkeiten frei. Das sind hauptsächlich raw-Pointer-Deref und die Möglichkeit anderen unsafe-Code aufzurufen. Unsafe macht Code also nicht automatisch unsicherer. Unsafe markiert nur Code, in dem man seine Raw-Pointer und unsafe-Aufrufe ganz genau auditieren sollte. Normaler Anwendercode braucht in der Regel kein Unsafe. Es ist aber an der Stelle notwendig, wo z.B. die Rust Runtime auf das Betriebssystem oder Hardware zugegriffen werden muss. Diese Zugriffe sind aber für Anwendercode alle in entsprechende safe-APIs gewrappt. Rust reduziert die zu auditierenden Blöcke also auf die unsafe-Blöcke, die in typischen Anwendungen bei ziemlich nahe 0% des Codes liegen.
cppbert3 schrieb: > egal wie idealistisch man die Branche, seine eigene Firma > oder die Kollegen einschätz, bei Rust kann niemand, wenn er nicht das > verteufelte unsafe nutzt auch nur einen der typischen Fehler machen ohne > das der Code nicht kompiliert Denk noch mal über den Satz nach. Wer verhindert, dass deine Kollegen unsafe nutzen? Und warum glaubst du, dass Entwickler, die nicht in der Lage sind sich in C++ an ein paar simple Regeln zu halten, mit rust klar zu kommen? Und behaupte jetzt bitte nicht, dass rust total einfach und idiotensicher ist.
cppbert3 schrieb: > Smart pointer, RAII und ASan sind nur Dinge die > funktionieren wenn man sie auch nutzt, Das gilt aber auch für Rust. Du kannst existierende C/C++-Projekte, die sowas nicht benutzen, nicht mit neuen Rust-Projekten vergleichen.
MaWin schrieb: > Unsafe ist nicht verteufelt. Das ist mir klar, aber das wird gerne als Argument genommen warum Rust ja doch nicht besser ist und es gab auch schon relevante Projekte die unnötig viel unsafe genutzt haben, deswegen ist unsafe erstmal verpönt und für die systemnahen unter uns vorbehalten
mh schrieb: >Wer verhindert, dass deine Kollegen unsafe nutzen? Dieses Missverständnis habe ich ja bereits erläutert. > Und warum glaubst du, dass Entwickler, die nicht in der Lage sind sich > in C++ an ein paar simple Regeln zu halten, mit rust klar zu kommen? Und > behaupte jetzt bitte nicht, dass rust total einfach und idiotensicher > ist. Wenn man sich in Rust nicht an die Regeln hält, compiliert der Code in der Regel nicht. In wenigen Fällen sagt er einem zur Laufzeit, dass man etwas getan hat, was nicht erlaubt ist. Deshalb werden die Entwickler sich dran halten müssen.
mh schrieb: > cppbert3 schrieb: >> egal wie idealistisch man die Branche, seine eigene Firma >> oder die Kollegen einschätz, bei Rust kann niemand, wenn er nicht das >> verteufelte unsafe nutzt auch nur einen der typischen Fehler machen ohne >> das der Code nicht kompiliert > Denk noch mal über den Satz nach. Wer verhindert, dass deine Kollegen > unsafe nutzen? > > Und warum glaubst du, dass Entwickler, die nicht in der Lage sind sich > in C++ an ein paar simple Regeln zu halten, mit rust klar zu kommen? Und > behaupte jetzt bitte nicht, dass rust total einfach und idiotensicher > ist. Was glaubst du was leichter ist: die Nutzung von unsafe zu erkennen oder fehlende Anwendung von sicherem C++?
mh schrieb im Beitrag > Und warum glaubst du, dass Entwickler, die nicht in der Lage sind sich > in C++ an ein paar simple Regeln zu halten, mit rust klar zu kommen? Und > behaupte jetzt bitte nicht, dass rust total einfach und idiotensicher > ist. In den meisten Fällen kompiliert es dann einfach nicht und ja es ist nicht leicht aber definitiv idiotensicher, wenn nicht sogar idiotenabwehrend
cppbert3 schrieb: > Das ist mir klar, Ich wollte das nur noch etwas untermauern, damit keine Missverständnisse entstehen. > aber das wird gerne als Argument genommen warum Rust > ja doch nicht besser ist Ja. Das ist genau das Missverständnis, was es auszuräumen gilt. >es gab auch schon relevante Projekte die unnötig viel unsafe genutzt haben, Ja, das ist natürlich in der Regel unnötig. Und es ist unschöner Stil. Aber es macht sie nicht per se unsicher. Aber solche Projekte sind ja mit ihren unsafe-Blöcken eindeutig als Murks markiert. Und da kann man dann seine Entscheidungen drauf basieren, ob man es denn verwendet oder nicht. Man braucht in Rust keine komplexen Checker-Tools, um potentiell unsicheren Code zu identifizieren, sondern nur grep unsafe
cppbert3 schrieb: > Was glaubst du was leichter ist: die Nutzung von unsafe zu erkennen oder > fehlende Anwendung von sicherem C++? Für mich, die fehlende Anwendung von sicherem C++.
S. R. schrieb: > Das gilt aber auch für Rust. Du kannst diese Konzepte in Rust nicht umgehen sonst kompiliert dein Code nicht Aliasing, Leaking oder sonstige Fehler dieser Art sind by design nicht möglich Ich glaube einigen ist das hier immer noch nicht wirklich klar Der Kompiler erhält durch die zusätzlich Ownership Annotation genug Informationen zur Kompilezeit um Fehler zu erkennen und ohne die annotation kompilierts nicht
mh schrieb: > Für mich, die fehlende Anwendung von sicherem C++. Weil du eine Plaintextsuche nach "unsafe" nicht durchführen kannst? Das erklärt einiges.
MaWin schrieb: > mh schrieb: >> Für mich, die fehlende Anwendung von sicherem C++. > > Weil du eine Plaintextsuche nach "unsafe" nicht durchführen kannst? > Das erklärt einiges. Das ist ein Schritt mehr, als ich in C++ machen muss.
Du vergleichst eine alte C/C++-Codebasis, die keinerlei Sanitizer und Vorsichtsmaßnahmen nutzt mit einer kompletten Neuentwicklung in Rust. Ist ja schön, dass Rust so geil ist, aber wenn man C++ richtig benutzt, mit den Sanitizern und Compilerwarnungen, was ist dann noch der Vorteil?
mh schrieb: > cppbert3 schrieb: >> Was glaubst du was leichter ist: die Nutzung von unsafe zu erkennen oder >> fehlende Anwendung von sicherem C++? > > Für mich, die fehlegrepnde Anwendung von sicherem C++. mh schrieb: > cppbert3 schrieb: >> Was glaubst du was leichter ist: die Nutzung von unsafe zu erkennen oder >> fehlende Anwendung von sicherem C++? > > Für mich, die fehlende Anwendung von sicherem C++. Ich meinte in 300.000 Zeile fremden Code den du morgen auf den Tisch bekommst In Rust suche ich nach "unsafe", der Rest ist per se Safe, Logikfehler kann ich in Rust und C++ machen
S. R. schrieb: > Du vergleichst eine alte C/C++-Codebasis, die keinerlei Sanitizer > und Vorsichtsmaßnahmen nutzt mit einer kompletten Neuentwicklung in > Rust. > > Ist ja schön, dass Rust so geil ist, aber wenn man C++ richtig benutzt, > mit den Sanitizern und Compilerwarnungen, was ist dann noch der Vorteil? Egal welcher Idiot den Rust code schreibt, er kann keinen der Speicherprobleme von C++ aufweisen
S. R. schrieb: > Ist ja schön, dass Rust so geil ist, aber wenn man C++ richtig benutzt, > mit den Sanitizern und Compilerwarnungen, was ist dann noch der Vorteil? Das "wenn" wird eliminiert. Der Code compiliert nicht mehr. Der Compiler beweist das "wenn".
cppbert3 schrieb: > In Rust suche ich nach "unsafe", der Rest ist per se Safe, Logikfehler > kann ich in Rust und C++ machen Es ist auch trivial, in C++ nach new zu suchen. Und die Tools, die derartige Dinge überprüfen, laufen so oder so über den Code. Warum glaubt ihr, jemand der nicht in der Lage ist Sanitizer und änhliche Tools zu nutzen, kommt mit rust klar?
S. R. schrieb: > Du vergleichst eine alte C/C++-Codebasis, die keinerlei Sanitizer > und Vorsichtsmaßnahmen nutzt mit einer kompletten Neuentwicklung in > Rust. > > Ist ja schön, dass Rust so geil ist, aber wenn man C++ richtig benutzt, > mit den Sanitizern und Compilerwarnungen, was ist dann noch der Vorteil? Du denkst nur in den kleinen kontrollierten Bedingungen deiner Projekte und Teams Wenn dein tolles grüne Wiese Projekt in C++ fertig ist komme andere nach dir und machen Sachen die du nicht so machen würdest, weil du schon dann schon an x anderen Projekten in einer anderen Abteilung arbeitest
cppbert3 schrieb: > Wenn dein tolles grüne Wiese Projekt in C++ fertig ist Ich lache mal und verlasse dann leise die Diskussion.
mh schrieb: > Es ist auch trivial, in C++ nach new zu suchen. new produziert unsicheren Code? So ein be*****es Argument habe ich ja lange nicht mehr gelesen.
SoOderSo schrieb: > Einerseits wird mit der Weiterentwicklung von C++ argumentiert dass Rust > nicht notwendig sei. Anderseits sehe ich aber eine massive > Relativierung und mangelnde Akzeptanz der C++ Neuerungen. Ob nun C++ oder Rust oder noch eine Handvoll Versuche, aus C irgend etwas Zukunftsweisendes zu machen, ist doch egal. Es ist immer wieder C und nochmals C und allenfalls mit einem Sack neuer Kollateraleffekte und Stolperfallen versehen, an die man sich gewöhnen müßte, wenn man so etwas als Programmiersprache tatsächlich benützen wollte. Überlaßt doch ganz einfach diese untoten Leichen sich selbst und ihren Fans. W.S.
mh schrieb: > Warum glaubt ihr, jemand der nicht in der Lage ist Sanitizer und > änhliche Tools zu nutzen, kommt mit rust klar? Das behauptet niemand. Aber Leute, die sich einen Dreck um sicheren Code scheren, werden mit Rust aussortiert.
mh schrieb: > cppbert3 schrieb: >> In Rust suche ich nach "unsafe", der Rest ist per se Safe, Logikfehler >> kann ich in Rust und C++ machen > > Es ist auch trivial, in C++ nach new zu suchen. Und die Tools, die > derartige Dinge überprüfen, laufen so oder so über den Code. > > Warum glaubt ihr, jemand der nicht in der Lage ist Sanitizer und > änhliche Tools zu nutzen, kommt mit rust klar? In Rust brauche ich diese Tools gar nicht Ich nutze die Sanitizer seit der 1. Stunde (und die sind ja echt noch superjung, ich hab vorher 20 jahre ohne gearbeiter und die sind ein Segen) und alle kommerziellen und kostenfreien Analyser mit allen möglichen Kompilern auf fast allen Platformen die marktrelevant sind, weil es ohne zu fahrlässig ist Du bestätigst doch selbst das man ohne Sanitizer nicht arbeiten sollte erklär mir doch einfach bitte warum eine Sprache die solche Tools unnötig macht nicht gut sein soll, traust du den versprechungen von Rust nicht?
MaWin schrieb: > mh schrieb: >> Es ist auch trivial, in C++ nach new zu suchen. > > new produziert unsicheren Code? > So ein be*****es Argument habe ich ja lange nicht mehr gelesen. Du hast offensichtlich keine Ahnung von modernem C++, wenn du nicht verstehst, warum new ein Indiz für unsicheren Code ist.
S. R. schrieb: > cppbert3 schrieb: >> Wenn dein tolles grüne Wiese Projekt in C++ fertig ist > > Ich lache mal und verlasse dann leise die Diskussion. Wie stellst du sicher das andere nach dir den Code nicht schlechter machen als du?
cppbert3 schrieb: > In Rust brauche ich diese Tools gar nicht Vielleicht, weil dieses Tool in den Compiler eingebaut ist? Oder wie wird Ownership in rust überprüft?
W.S. schrieb: > Ob nun C++ oder Rust oder noch eine Handvoll Versuche, aus C irgend > etwas Zukunftsweisendes zu machen, ist doch egal. > > Es ist immer wieder C und nochmals C Rust hat mit C überhaupt gar nichts gemeinsam, außer einige wenige Grammatikdetails. Jemand der C programmieren kann, kann noch lange keine einzige Zeile Rust programmieren. Ich war ja auch lange der Meinung, dass jeder, der wenigstens C kann, innerhalb von Tagen jede andere imperative Sprache erlernen kann. Rust hat mir das Gegenteil bewiesen. Man muss deutlich anders denken. Und es ist gut so! Rust eröffnet einem ganz neue Paradigmen. Ganz neue Denkweisen. Die kann man auch teilweise in andere Sprachen übertragen, die solche Garantien nicht haben.
mh schrieb: > Du hast offensichtlich keine Ahnung von modernem C++, wenn du nicht > verstehst, warum new ein Indiz für unsicheren Code ist. Ja. Ein Indiz. Rust beweist. Unterschied: Indiz <-> Beweis.
mh schrieb: > MaWin schrieb: >> mh schrieb: >>> Es ist auch trivial, in C++ nach new zu suchen. >> new produziert unsicheren Code? >> So ein be*****es Argument habe ich ja lange nicht mehr gelesen. > > Du hast offensichtlich keine Ahnung von modernem C++, wenn du nicht > verstehst, warum new ein Indiz für unsicheren Code ist. Du kannst aber auch noch nicht soo viel Erfahrung haben wenn du denkst das due suche nach new alle Speicherprobleme mit C++ aufzeigt, was ist mit Aliasing, Use-After-Free in cast-Ctors und und und, die Liste ist sehr lang aber viele C++ Entwickler glauben einfach das die anderen Entwickler eben auch so gut arbeiten wie man selbst und dem ist eben oft nicht so, klar kann man die alle entlassen, gehen die eben zu einer anderen Firma bis die dicht macht, schlussendlich bleiben die am Markt und werden eben genutzt In Rust können die wenigstens kein schwer zu findenden Speicherfehler machen, und nein hier geht es nicht um Memoryleaks die sind die einfachste Form
mh schrieb: > Vielleicht, weil dieses Tool in den Compiler eingebaut ist? Es ist in die Sprache eingebaut. Das ist ein Unterschied. > Oder wie wird Ownership in rust überprüft? Überhaupt nicht. Es ist ein intrinsisches Sprachdetail. Ich glaube du verwechselst das mit Borrowing. (vgl. C++ shared_ptr, aber zur Compilezeit)
mh schrieb: > cppbert3 schrieb: >> In Rust brauche ich diese Tools gar nicht > > Vielleicht, weil dieses Tool in den Compiler eingebaut ist? Oder wie > wird Ownership in rust überprüft? Rust hat keine Runtime Sanitation sonder kompiletime Analyse, klar irgendwie das gleiche - aber Rust braucht nichtmal Tests um den Fehler vor dem Lauf zu finden, nicht jedes Programm erreicht aus dem Stand 100% Coverage d.h. du musst in einem nicht-grüne-Wiese oder Fremden Code Projekt erstmal die Codezeile auslösen damit der Sanitizer wirkken kann, zeig mir mal wie du das schnell mit einem 100KLoc Programm mache das ich gerade erst bekommen habe, wo irgendwelche Fehler, scheinbar drinn sind - in Rust sind diese Fehler einfach nicht möglich
W.S. schrieb: > Ob nun C++ oder Rust oder noch eine Handvoll Versuche, aus C irgend > etwas Zukunftsweisendes zu machen, ist doch egal. ROTFL. Vielleicht solltest du dir ja wenigstens minimal was zur Sprache angucken, über die du hier gerade verdammt große Bögen spuckst. Könnte sonst sein, die Wurfparabel war falsch berechnet, und du schießt dir mit deiner Spucke ein Eigentor. :-)
Ihr argumentiert also gerade über den negativen Netzwerkeffekt des fehlenden Features der erzwungenen memory safety bei C++, der wäre, dass Programme des C++ Ökosystems häufiger Speichermanagementprobleme aufweisen, als wenn diese dieses Feature hätte. Also eine Designentscheidung des Systems, das Einfluss auf das Ökosystem hat. Euch mag eventuell auffallen, dass dies die selbe Art von Argument ist, wie ich es beim fehlenden provides Feature von Cargo vorbrachte. Ich könnte hier jetzt auf die selbe Art dagegen argumentieren, "Dann nutze doch keine C++/Cargo Anwendungen.", "Ist das eine Vermutung?", "Rust kann dynamisch linken" vs. "Das geht in C++ schon, mit smart Pointern.", usw. Die Probleme sind Echt. Nur mal so zum drüber nach denken...
Nur damit das klar ist Rust macht zur Kompilezeit eine programmweite Analyse, also 100% Source Abdeckung und bricht den Kompiliervorgang ab wenn irgendein Speicherfehler auftreten kann, aber nicht weil der Fehler passiert sondern weil die Rust Semantik solche Problem nicht erlaubt oder besser gesagt überhaupt abbilden kann, ist also ein Kompiletime Semantik-Fehler Die Sanitizer müssen durch Unit- oder manuelle oder Fuzzy Tests gezielt oder zufällig über ein Problem stolpern Zwischen den beiden Konzepten liegen Welten Rust ist wie bei Minority Report wo man vor dem Mord schon im Knast sitzt, die Sanitizer sind eher wie Polizisten die zufällig oder weil jemand sie dort hingeschickt hat den Mord beobachten
Daniel A. schrieb: > Nur mal so zum drüber nach denken... Ich verstehe kein Wort von dem, was du schreibst. Könntest du das bitte verständlich neu formulieren?
MaWin schrieb: > Daniel A. schrieb: >> Nur mal so zum drüber nach denken... > > Ich verstehe kein Wort von dem, was du schreibst. > > Könntest du das bitte verständlich neu formulieren? Es ist Pro Rust, einfach mehrfach lesen dann wirds klar, kompliziert aber stechend formuliert
https://github.com/microsoft/windows-rs Microsoft hat eine Metabeschreibung der WinApi veröffentlicht, nebst Binding Generator für Rust und C#, C++ soll folgen
Beitrag #6565967 wurde vom Autor gelöscht.
mh schrieb: > Du hast offensichtlich keine Ahnung von modernem C++, wenn du nicht > verstehst, warum new ein Indiz für unsicheren Code ist. Ja aber nur wenn das - delete fehlt - oder Exception zwischendurch - womöglich x hundert andere Pfade existieren wo etwas schief gehen kann - das mein (seien wir ehrlich:) hinzugepfriemeltes Tool erst mal entdecken muss - etc. Code-Reflection ist eben nicht einfach, besonders wenn man die Regeln der grauen Eminenzen(Komitee)im Ökosystem einer organisch gewachsenen Programmiersprache beachten muss. (Völlig wertfrei gemeint ... ich bin in Boost verliebt) Wie wäre es bloß, wenn man diesen steinigen Weg gar nicht gehen müsste und Speicherfehler vermeiden könnte, etwa durch ein Neu-Design? Was würde ich geben wenn es so etwas geben würde ... :)
1 | unsafe
|
ist natürlich immer noch böse. Aber vergleichen wir einmal https://github.com/google/sanitizers/issues?q=is%3Aissue+delete mit https://debbugs.gnu.org/cgi/pkgreport.cgi?package=grep Bei den grep issues nicht erschrecken lassen. Kein einziger Bug davon verhindert das grep -r unsafe * etwas anzuzeigen vergisst. Nur gabs gerade bei der Rekursion einen Memory-Leak. Sachen gibts;) Das war jetzt aber eher mit einem zwinkernden Auge gemeint. Äpfel und Birnen. xyz-sanitize ist eben KEIN Ersatz für Sprachdesign sondern die Putzkolonne, wenn die Sauerei schon dampft. P.S.: Bild => völlig anderer Rost! -> https://dilbert.com/strip/2000-04-30
Rust forciert: 1. einen einheitlichen Codingstyle (den man lokal deaktivieren kann - was aber nicht gerne gesehen ist) ==> der Style ist dann vielleicht nicht so wie man den seit 20 Jahren nutzt aber wenigstens ist er über alle Kollegen, Abteilungen UND Firmen für die man zeitweise arbeitet der selbe - und wer will den Ernsthaft behaupten das es zwischen den produktiven hunderten Codingstyles die das draussen so rumkreuchen und fleuchen der Unterschied mehr ist als Bauchgefühl spätestes wenn du mit C,C++,C# und Python arbeitest fährt man im Normalfall schon 2-3 verschiedene Arten - also was soll es... MERKE: man "kann" nicht nur einen gemeinsamen Codingstyle haben - man hat IMMER den selben(nicht nur den gleichen) Codingstyle 2. Ein Own/Share Konzept in der Sprache - was definitiv NICHT bedeutet das da Smart-Pointer einfach nur fest eingebaut sind sondern das die Sprache syntaktisch nicht erlaubt Own oder Share-Probleme zu programmieren, das komplette Programm ist wenn kompilierbar garantiert frei von (fast) alle Own/Share bezogenen Fehler - so lange der Kompiler keine Bugs hat :) ==> natürlich hat C++ auch Smart-Pointer und RAII mit der man viele Probleme unter Kontrolle bringt - aber eben nur wenn auch alle Entwickler mit machen, Die grossen der Branche, also die mit sehr vielen Entwicklern und sehr viel C++-Code (10-100MioLOC) und Einfluss auf das Weltgeschehen, sage einstimmig, das ist alle ganz gut - wir haben aber trotzdem odentlich Probleme - und wer das nicht glaube hat einfach nicht wirklich Team- und im speziellen firmenübegreifende Entwicklungserfahrung oder hat keine Ahnung was ein Amazon AWS mit MioLOC C++ und 2 stellig Mio Anzahl Nutzer tagtäglich für Problemen mit Resourcen-Bedarf, Sicherheit gegen Angriff und.und.und ausgesetzt ist, ein google, Facebook etc. haben vergleichbare Größenordnung MERKE: Mit Fehler die es nicht geben KANN muss man sich GAR NICHT beschäftigen 3. Ein Package und Build-System (aka Cargo) Jeder Anfänger kann die Docs lesen und jeder andere Entwickler wird im Normalfall die selbe Sprache sprechen, fast jedes Projekt das sich nicht toal gegen den Standard wehrt baut out-of-the-box, das ist einfach was anderes als jeder-kann-es-machen-wie-er-will unter C++ haben wir mittlerweile von Conan, vcpkg usw. schon etliche Systeme die immer mehr Verbreitung finden und es liegen x Proposal vor um C++ um ein solches System zu erweitern ich hab beruflich mit fast allem Kontakt MERKE: Vereinheitlichung ist erstmal einfacher für die meisten - an den Aufgaben wachsen kann jedes System 4. Ein auf Rust basiertes Build-System natürlich haben wir da ein Wildwuchs an Systemen von CMake, meson, QMake, qbs, Scons - ich hab mit allen zu tun - und jedes ist irgendwie anders , natürlich auch für embedded und, und, und in Rust ist dein Build-System in Rust-Code und mehr braucht man eigentlich doch auch nicht MERKE: die Sprache die du primär nutzt bleibt auch beim Build-System deine Sprache - kein Umdenken nötig Nachteile: 1. Rust ist mit seinen 5-10 Jahren sehr jung für eine native Sprache mit so vielen echten Zwängen - go, C# oder andere nicht embedded-tauglichen oder VM-Sprachen sind einfach was anderes und können nur in der normalen Applikations-Entwicklung zum vergleich herangezogen werden - embedded und System-Entwicklung hat aber einfach noch viele viele kleine Anforderungen die eben auch sicher und performant realisierbar sein müssen 2. Rust ist oft arschlangsam beim kompilieren, liegt u.a. an dem stark organisch gewachsenem Kompiler und weil die Entwickler auch definitiv lange keine Fokus darauf gelegt haben - die wollte erst mal eine stimmige Syntax/Semantik entwickel/erforschen - und haben auch viele auf dem Weg dort hin gebaut und wieder völlig verworfen u.a. weil es eben nicht einfach nur ein C-Derivat ist (wie die meisten der anderen Sprachen) Das ist jedem klar aber definitiv kein Argument gegen die Infrastruktur-Tools oder die Syntax und das macht die Entwickler auch nicht zu einem Haufen Idioten die gar nix können 3. Rust versucht gezielt mit vielen Zwängen die Entwickler auf die Algorithmen-Entwicklung zu fokusieren - das ist für viele aus der Kriegs- oder Anti-Autoritären-Erziehungs Generation zu wenig libreral, obwohl die meisten in ihren eigenen Firmen auch eher totalitärer Kontrolle über Infrastruktur-Tools und Codingstyle unterliegen oder ausüben 4. alles statisch gelinkt weil noch keine klare ABI für DLLs usw. 5. und, und, und... Es wäre schön wenn wir vielleicht eine Positiv/Negativ-Liste aufbauen könnten
Nachteil 6: Um Rust ranken sich zu viele Mythen: "Rust ist perfekt für alles und erzeugt immer super-schnellen Code" Die Syntax ist nicht ganz leicht und keine Programmiersprache der Welt vollbringt Wunder Rust hat aber definitiv mit der Aliasing-Kontrolle potenzial stärker optimierbar sein zu können als C/C++ (wenn GCC und LLVM da keine Fehler hätten) "Rust ist super-kompliziert" Kommt definitiv darauf an welche Sprachen-Hintergrund man hat und welche Ziele man verfolgt, für jemanden der nur Basic kann ist alles schwer für jemanden der 10 Sprachen kann ist Rust vielleicht nicht so kompliziert Die Frage ist nur ob man die Vorteile nutzen will "Rust ist zu streng/einschränkend" Jeder ist streng und einschränkend in seiner Firma oder Projekt - gibt es jemanden unter euch der akzeptiert das jeder im Team den Code einfach so strukturell oder visuell schreibt wie er jetzt gerade Bock drauf hat? In C++ gibt es immer die Leute die auch mit den Infrastruktur-Tools wie Build-System, oder Sanitzer etc. arbeiten - oder diese auch einführen und pflegen, schulen - es ist meist nicht das ganze Team welche alles Tools gleich gut versteht - weil zu viel Spezialisierung nötig ist "Es kann einfach nicht sein das Rust diese Sicherheits-Garantien erfüllt" Es sind schon viele Sprachen daran gescheitert - meist weil die dabei entstandene Syntax kaum eine praktikable Entwicklung erlaubt, die meisten Sprachen sind entweder total unsicher wie z.B. C oder schaffen es mit größerem Ressourcen-Bedarf (alle VM Sprachen) die Problem besser unter Kontrolle zu halten, die dann aber wieder nicht für alle embedded/Echtzeit/niedrig-Latenz-Systeme geeignet sind Sicherheits-Garantie bedeutet nicht das es sicher ist wenn man es richtig anwendet - das ist nur eine mögliche Sicherheit
Nachteil 7: Rust hat erst vor kurzem, z.B. durch Amazon (die sponsorn alle Server und haben viele der Kern-Entwickler unter Vertrag genommen) und Microsoft (Azure und auch ein Teams im Aufbau) starke finanzielle Zuwendung ausserhalb von Mozilla erfahren das ist verglichen mit der .Net-Entstehung (stark durch den ganzen Microsoft-Konzern getrieben) , Java durch Sun/Oracle oder einem go mit starkem google-Hintergrund noch nicht wirklich viel Direkt-Finanzierung das führt eben dazu das z.B. die Standard-Lib viel weniger umfangreich und ausgetesteter ist als bei Sprache/Platformen die erst hinter den Konzern-Türen so weit gebracht wurde das sie möglichst viele "Kauf-ich"-Argumente bei der Erstvorführung mitgebracht haben Nachteil 8: Rust will C/C++ im Embedded Bereich beerben - in dem ältesten und konservativstem Teil unserer Software-Landschaft, mit der größten Anteil an Spezalisierung bis runter auf die x Varianten von Kompilern und SDKs die von den Anbietern angepasst werden. Das ist definitiv eine riesen Herausforderung - an der bisher jede Sprache ausser C (C++) und ein paar wenigen anderer, gescheitert ist - aber auch vielleicht weil die 1. zu Ressourcen-Hungrig waren oder einfach wirklich nur minimalsten Mehrwert gebracht haben
cppbert schrieb: > Wäre es nicht eine Überlegung wert, künftig einen anderen (Gast-)Nick zu verwenden?
Carl D. schrieb: > cppbert schrieb: >> > Wäre es nicht eine Überlegung wert, künftig einen anderen (Gast-)Nick zu > verwenden? Wie sollen mich dann bitte meine unzähligen Fans erkennen?
Carl D. schrieb: > cppbert schrieb: >> > Wäre es nicht eine Überlegung wert, künftig einen anderen (Gast-)Nick zu > verwenden? Ich denke Rust braucht noch mind 5 Jahre bis zur Reife, bis dahin habe ich noch genug Zeit sehr viel C++ Code zu pflegen und zu schreiben, aber dann wechsel ich natürlich gleich auf rustbert
https://opensource.googleblog.com/2021/02/google-joins-rust-foundation.html ........ Memory safety security defects frequently threaten device safety, especially for applications and operating systems. For example, on Android, we’ve found that more than half of the security vulnerabilities we addressed in 2019 resulted from memory safety bugs. And this is despite significant efforts from Google and other contributors to the Android Open Source Project to either invest in or invent a variety of technologies, including AddressSanitizer, improved memory allocators, and numerous fuzzers and other code checking tools. Rust has proven effective at providing an additional layer of protection beyond even these tools in many other settings, including browsers, games, and even key libraries. We are excited to expand both our usage of Rust at Google and our contributions to the Rust Foundation and Rust ecosystem. .... Half of the security vulnerabilities... und das von den Asan Erfindern :)
Beitrag #6582066 wurde von einem Moderator gelöscht.
Cppbert3 schrieb: > Half of the security vulnerabilities... und das von den Asan Erfindern > :) Und sie sagen zu rust: Cppbert3 schrieb: > an additional layer of protection Das ist etwas anderes, als die Lösung des Problems.
> Rust wandert ins System > Eine wichtige Python-Bibliothek nutzt künftig teilweise Rust-Code. Bald wird > es möglicherweise schwer, Linux-Systeme ohne Rust zu betreiben. https://www.golem.de/news/linux-rust-wandert-ins-system-2102-154041.html /edit Dieses Forum braucht a gscheite Quote Funktion... -.-
:
Bearbeitet durch User
mh schrieb: > Das ist etwas anderes, als die Lösung des Problems. was erwartest du: die haben 1Mrd. Zeilen C/C++ Code - wäre ziemlich blöd den Code in so einem Werbungs-Post schlecht klingen zu lassen, oder? und was ist das Problem bei "die Lösung des Problems"? Rust verhindert zu 100% alle Formen von Speicher-Falschnutzungen und Data-Races zur Kompilezeit (bis auf Array-Indizierung) - für den ganzen Source-Code auf einmal - was fehlt da noch an kritischen Problemen? Logikfehler kann man immer machen und jede Sprache die versucht bis auf die Array-Indizierung herunter eine Garantie für die Fehlerfreiheit einer Software zu liefern ist praktisch kaum relevant(oder nutzbar)
Jetzt wurde Rust in eine eigene Foundation ausgelagert. Mal schauen was daraus wird und ob sich dadurch mehr Vetrauen aus der Industrie gewinnen lässt. https://blog.mozilla.org/blog/2021/02/08/mozilla-welcomes-the-rust-foundation/
Moin, Na, wollnwa mal hoffen, dass nicht eines Tages auch mal sowas oder vergleichbares bei rust/cargo passiert: https://www.heise.de/news/Sicherheitsforscher-bricht-ueber-Open-Source-Repositories-bei-PayPal-Co-ein-5051635.html SCNR, WK
Dergute W. schrieb: > Na, wollnwa mal hoffen, dass nicht eines Tages auch mal sowas oder > vergleichbares bei rust/cargo passiert: Warum sollte es?
MaWin schrieb: > Dergute W. schrieb: >> Na, wollnwa mal hoffen, dass nicht eines Tages auch mal sowas oder >> vergleichbares bei rust/cargo passiert: > > Warum sollte es? Sollte die Frage nicht besser lauten: Warum sollte es nicht?
Dergute W. schrieb: > MaWin schrieb: > >> Dergute W. schrieb: >>> Na, wollnwa mal hoffen, dass nicht eines Tages auch mal sowas oder >>> vergleichbares bei rust/cargo passiert: >> >> Warum sollte es? > > Sollte die Frage nicht besser lauten: Warum sollte es nicht? Alle Package System die von Remote Code oder Binaries ziehen können und werden solche Probleme haben, nmp, vcpg, cargo, pip und und und, natürlich muss man da diszipliniert sein, aber ich hätte absolut kein Problem sowas komplett entkoppelt, firmenintern zu nutzen, was ja auch möglich ist - oder ich mache mein deployment von 3rd parties weiterhin von Hand, Cargo steht mir da auch nicht im Weg aber ja, man kann alles irgendwie korrumpieren und es wird leichter
cppbert3 schrieb: > Alle Package System die von Remote Code oder Binaries ziehen können und > werden solche Probleme haben, Das Problem war hier, dass Paypal ihr internes Buildsystem falsch konfiguriert haben. Einfach mal den Artikel lesen. Das hat überhaupt nichts mit einer Lücke im Paketsystem zu tun. Deshalb sehe ich auch nicht, was das mit Rust oder Cargo zu tun haben soll.
> Deshalb sehe ich auch nicht, was das mit Rust oder Cargo zu tun haben > soll. Es gibt schon einen Zusammenhang. Wenn du frueher zu Ahnungslos gewesen bist um etwas ans laufen zu bringen dann hat es halt nicht funktioniert und du hast solange gelernt bist du es hin bekommen hast. Heute funktioniert alles beim erstenmal moeglichst einfach, aber es ist Mist weil alles in die Welt rausgeblasen wird und du die unmoeglichsten Abhaengigkeiten auf der Kiste hast. Nur wenn du Ahnung hast und dir Muehe gibst kannst du es abstellen. Die Welt wird idiotensicher und wir bekommen immer mehr Idioten weil das reicht sich durchzuschummeln. Vergleich das mit Handys. Nokiahandys unter Symbian waren angeblich schlecht weil es nach dem kauf kompliziert war die Kiste soweit zu bekommen das man damit ins Internet konnte, Email usw funktioniert hat. Bei Android geht es beim ersten einschalten, aber du musst dreimal soviel Muehe reinstecken um zu verhindern das deine privaten Daten ueberrall in der Welt landen. Ueber die Folgen kannst du jeden Tag in der Zeitung lesen. Software geht denselben Weg.... Olaf
Olaf schrieb: > Bei Android geht es beim ersten einschalten, aber du musst dreimal > soviel Muehe reinstecken um zu verhindern das deine privaten Daten > ueberrall in der Welt landen. Ueber die Folgen kannst du jeden Tag in > der Zeitung lesen. Was steht denn da genau über Android-Handys? Wenn ich in meiner (digitalen) Zeitung lese dass irgendwo Daten (z.B. Passwörter im Klartext) abgegriffen wurden dann so gut wie immer bei Firmen bzw. aus der Cloud. Also aus Linux-Serversystemen, nicht von Android-Smartphones.
:
Bearbeitet durch User
> Firmen bzw. aus der Cloud. Also aus Linux-Serversystemen, nicht von > Android-Smartphones. Das ist hier wohl eher OT, aber frag dich mal eine Sekunde wie bei Firmen wie Facebook, Google usw die Milliarden entstehen. Die muessen irgendwo was klauen das sie verkaufen koennen. In der Software sehe ich das Problem das die Komplexizitaet immer groesser geworden ist. So gross das es immer schwerer faellt das alles zu durchschauen. Die Loesung sieht man darin die Systeme noch komplexer zu machen indem man diese Komplexizitaet nach aussen hin versteckt. Olaf
Le X. schrieb: > Also aus Linux-Serversystemen, nicht von > Android-Smartphones. Aus Android-Smartphones muss man ja auch nichts abgreifen. Die senden die Daten ja von ganz allein dahin... und es ist nahezu unmöglich, das zu verhindern.
S. R. schrieb: > Le X. schrieb: >> Also aus Linux-Serversystemen, nicht von >> Android-Smartphones. > > Aus Android-Smartphones muss man ja auch nichts abgreifen. Die senden > die Daten ja von ganz allein dahin... und es ist nahezu unmöglich, das > zu verhindern. Mich hätte eigentlich nur interessiert was das für ominöse Folgen sind von denen Olaf spricht und wo man darüber lesen kann. Olaf schrieb: > aber du musst dreimal > soviel Muehe reinstecken um zu verhindern das deine privaten Daten > ueberrall in der Welt landen. Ueber die Folgen kannst du jeden Tag in > der Zeitung lesen. Aber die Antwort blieb er schuldig, seinem letzten Beitrag kann ich nicht wirklich Verständliches entnehmen.
MaWin schrieb: > cppbert3 schrieb: >> Alle Package System die von Remote Code oder Binaries ziehen können und >> werden solche Probleme haben, > > Das Problem war hier, dass Paypal ihr internes Buildsystem falsch > konfiguriert haben. Einfach mal den Artikel lesen. > Das hat überhaupt nichts mit einer Lücke im Paketsystem zu tun. > > Deshalb sehe ich auch nicht, was das mit Rust oder Cargo zu tun haben > soll. Wenn es nur Paypal wäre, ist diese Aussage vielleicht Ok. Da es mittlerweile allerdings deutlich mehr Unternehmen getroffen hat, sollte man nochmal überlegen, wo genau das Problem liegt. Achso MaWin, wie hilft in diesem Fall dein heiliger Gral semantic versioning?
mh schrieb: > Achso MaWin, wie hilft in diesem Fall dein heiliger Gral semantic > versioning? Wo bitte wurde das behauptet?
Operator S. schrieb: > mh schrieb: >> Achso MaWin, wie hilft in diesem Fall dein heiliger Gral semantic >> versioning? > > Wo bitte wurde das behauptet? Da müsstest du die Beiträge von vor einem Monat lesen. Da hat MaWin im wesentlichen versucht, alle kiritschen Kommentare zu cargo mit Verweisen auf semantic versioning zu beantworten oder sie als völligen Unsinn bezeichnet. Z.B. MaWin schrieb: > mh schrieb: >> Du musst regelmäßig die Abhängigkeiten prüfen, ob >> da noch alles so funktioniert wie es soll, > > Quatsch. > Dank semantic versioning ist das natürlich nicht notwendig. > Du bekommst automatisch alle rückwärtskompatiblen Weiterentwicklungen > und Fixes.
mh schrieb: > Da müsstest du die Beiträge von vor einem Monat lesen. Da hat MaWin im > wesentlichen versucht, alle kiritschen Kommentare zu cargo mit Verweisen > auf semantic versioning zu beantworten oder sie als völligen Unsinn > bezeichnet. Ach, habe ich das? Kann es vielleicht sein, dass das in einem völlig anderen Zusammenhang war? Zitiere meine Aussage bitte, wenn du anderer Meinung bist. Du wirst es nicht schaffen, weil es sie nicht gibt. Könnten wir jetzt bitte wieder zum Thema zurückkommen? Rust?
MaWin schrieb: > Ach, habe ich das? Kann es vielleicht sein, dass das in einem völlig > anderen Zusammenhang war? Ja und Nein. > Zitiere meine Aussage bitte, wenn du anderer Meinung bist. > Du wirst es nicht schaffen, weil es sie nicht gibt. Ok ... mh schrieb: > Damit ist man den Pflegeaufwand aber nicht los geworden, sondern verlegt > ihn nur woanders hin. Du musst regelmäßig die Abhängigkeiten prüfen, ob > da noch alles so funktioniert wie es soll, keine neuen unerwarteten > Abhängigkeiten dazu gekommen sind, die Qualität noch deinen > Anforderungen entspricht, kein Urheberrecht verletzt wird ... MaWin schrieb: > mh schrieb: >> ... > Quatsch. > Dank semantic versioning ist das natürlich nicht notwendig. > Du bekommst automatisch alle rückwärtskompatiblen Weiterentwicklungen > und Fixes. Und ja, ich sehe Malware in der Abhängigkeit als Qualitätsproblem.
mh schrieb: > Und ja, ich sehe Malware in der Abhängigkeit als Qualitätsproblem. Wie soll die Malware da plötzlich hinein kommen? Warum soll mir ein Entwickler plötzlich Malware unterschieben? Und warum ist das ein Problem des Tools? Und warum ist das jetzt neu und unterscheidet sich von jedem anderen Updatemechanismus? Ich glaube du hast immer noch nicht verstanden, wie crates.io funktioniert. Das ist einzig und alleine ein soziales Problem. Soziale Probleme lassen sich prinzipiell nicht mit Technik lösen.
MaWin schrieb: > Soziale Probleme lassen sich prinzipiell nicht mit Technik lösen. Doch schon, durch Isolation, die man aber mit Rust/CreateCreate realisieren kann - wenn man das als nötig befunden hat
mh schrieb: > Da müsstest du die Beiträge von vor einem Monat lesen Hab ich, den Thread verfolge ich seit Beginn. Ironischerweise, löst genau Semantic Versioning das beschrieben Problem von derguteweka (Warum auch immer das hier in einem Rust Thread gelandet ist...) Wenn man nämlich nur schreibt Package Install MyFancyLib, dann holt er sich das Package mit der höchsten Version das er finden kann. Ein "Hacker" erstellt dann einfach auf der öffentlichen Paketsource ein MyFancyLib mit einer sehr hohen Version und Zack landet es in deinem System. Wenn man aber die Version spezifiziert a la Package Install MyFancyLib 1.2.5 dann holt er genau diese eine Version. An dieser Stelle danke für deine kritische Sichtweise, sonst wäre es mir nicht bewusst geworden, dass Semantic Versioning tatsächlich genau dieses Problem löst.
Operator S. schrieb: > Wenn man aber die Version spezifiziert a la Package Install MyFancyLib > 1.2.5 dann holt er genau diese eine Version. > > An dieser Stelle danke für deine kritische Sichtweise, sonst wäre es mir > nicht bewusst geworden, dass Semantic Versioning tatsächlich genau > dieses Problem löst. Ähm, nein, das hilft hier gar nichts. Irgendwann will man die Dependencies ja auch updaten, auch um mögliche Sicherheitslücken in alten Versionen zu schlissen. Dann macht man "npm/pip/cargo update", und was glaubst du, was dann passiert? Genau, es tut was es soll, und aktualisiert die Versionen der Abhängigkeiten. Da gibt es jetzt echt keinen Unterschied zwischen npm, pip, cargo, etc. Da müsste man schon selbst aufpassen, und nochmal genauer hin sehen... Es ist aber nicht so, dass es keine Ideen gibt, um das Problem mit technischen mitteln zu lösen. Google hat letztens eine Dystopische Lösung für das Problem vorgeschlagen: Jeder braucht eine rechtsgültige, eindeutige Identität im Internet. Baut man scheisse, kann man sich einen neuen Job/Hobby suchen... [1] (Man bedenke auch, dass vielerorts die Einführung von eIDs im Gange ist. Am Anfang alles freiwillig, aber sicher schreiben es Onlinedienste irgendwann vor, und dann ist ende mit Pseudonymität online, und wir enden mit einem von Firmen kontrollierten China-artigen Social Credit System...) 1) https://opensource.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting-discussion-around-vulnerabilities-in-open-source.html#:~:text=Goal:%20Authentication%20for%20Participants%20in%20Critical%20Software
🐧 DPA 🐧 schrieb: > Es ist aber nicht so, dass es keine Ideen gibt, um das Problem mit > technischen mitteln zu lösen. Es braucht keine Ideen um das Problem mit technischen Mitteln zu lösen, es ist bereits gelöst. Liest hier keiner mehr die Artikel, sondern nur die Überschrift? Definiere einfach deine Paketquelle und die verlangte Version, dann nimmt dein Paketsystem nicht einfach die höchste Version die es im Internet finden kann. 🐧 DPA 🐧 schrieb: > Irgendwann will man die > Dependencies ja auch updaten, auch um mögliche Sicherheitslücken in > alten Versionen zu schlissen. Dann macht man "npm/pip/cargo update", und > was glaubst du, was dann passiert? Genau, es tut was es soll, und > aktualisiert die Versionen der Abhängigkeiten. Genau und dieser Schritt macht man von Hand. Es ist eine bewusste Aktien, dass man was verändert hat. Wenn man dann einfach nimmt was einem hergeworfen wird, sollte man sich ein anderes Handwerk suchen. Und ich meine hier nicht den Fall, dass ein Paket von Version 1.2.3 auf Version 2.1.0 ein Update erhalten hat und man bis ins letzte Detail nachschauen muss, was ist anders geworden. Wenn aber aus Version 1.2.3 das Update Version 22.0.0 macht, sollte man das nachprüfen. In der oben verlinkten "Sicherheitslücke" geht es aber darum, dass im Buildsystem automatisch die neueste Version genommen wird, wenn keine Version spezifiziert wurde. Ohne dass man bewusst nach einem Update verlangt hat.
🐧 DPA 🐧 schrieb: > Genau, es tut was es soll, und > aktualisiert die Versionen der Abhängigkeiten. Bitte lies den Beitrag von Operator S. noch einmal. Dann informiere dich, was Semantic Versioning ist und was mit diesem Satz gemeint ist: > Wenn man aber die Version spezifiziert a la Package Install MyFancyLib > 1.2.5 dann holt er genau diese eine Version. Und dann informiere dich, wie crates.io und Cargo funktionieren. Das ist und bleibt PEBCAK. Wenn ich Cargo sage, dass es immer die neuste Version der Schiene ziehen soll, egal von welcher Quelle, dann macht es genau das. Oh Wunder. Wenn ich Cargo sage, dass es das nicht tun soll, tut es das nicht. Wie ich schon vor einiger Zeit schrieb: Es ist ein Konfigurationsfehler.
Operator S. schrieb: > Es braucht keine Ideen um das Problem mit technischen Mitteln zu lösen, > es ist bereits gelöst. Liest hier keiner mehr die Artikel, sondern nur > die Überschrift? Nein, Supply Chain Attacks sind real, und auch heute immer noch ein Problem. Das kannst du gerne leugnen, ändert aber nichts daran, dass diese überall immer mal wieder auftreten. Operator S. schrieb: > Definiere einfach deine Paketquelle und die verlangte Version, dann > nimmt dein Paketsystem nicht einfach die höchste Version die es im > Internet finden kann. Ich nehme an du beziehst dich da auf Cargo.lock und co., wenn Projekte das direkt in ihrer Cargo.toml machen würde, würde das ja das ganze semver Konzept ad absurdum führen. Updaten muss man aber trotzdem von zeit zu zeit. > Operator S. schrieb: > 🐧 DPA 🐧 schrieb: >> Irgendwann will man die Dependencies ja auch updaten, >> ... > Genau und dieser Schritt macht man von Hand. Es ist eine bewusste > Aktien, dass man was verändert hat. Wenn man dann einfach nimmt was > einem hergeworfen wird, sollte man sich ein anderes Handwerk suchen. Das ist mir schon klar. Wenn man aber immer mal wieder liest, wie ein Security Researcher mal wieder was bei allen möglichen Firmen eingeschleust hat, dürfte ja wohl klar sein, dass das nicht dem entspricht, was in der Realität in der Regel gemacht wird. Ist ja auch nicht erstaunlich, wenn Projekte 100te Dependencies haben, die man updaten muss. Operator S. schrieb: > Und ich meine hier nicht den Fall, dass ein Paket von Version 1.2.3 auf > Version 2.1.0 ein Update erhalten hat und man bis ins letzte Detail > nachschauen muss, was ist anders geworden. Wenn aber aus Version 1.2.3 > das Update Version 22.0.0 macht, sollte man das nachprüfen. Bei Supply Chain Attacks ist der Angreifer nicht gezwungen, die Major Version zu ändern, im Gegenteil, man will ja nicht auffallen. Deshalb ist es in dem Bezug völlig egal, ob das nur ein Minor Update ist, nachprüfen sollte man trotzdem. Nur um zu schauen, ob es noch läuft, kann man auch automatisierte Tests machen, das ist eine andere Baustelle. Operator S. schrieb: > In der oben verlinkten "Sicherheitslücke" geht es aber darum, dass im > Buildsystem automatisch die neueste Version genommen wird, wenn keine > Version spezifiziert wurde. Ohne dass man bewusst nach einem Update > verlangt hat. Naja, eigentlich war da das Problem mit Privaten vs. Öffentlichen Repos. Das ist aber nur einer von vielen Wegen, wie sowas passieren kann. Ein Projekt wechselt den Maintainer, jemand lädt versehentlich seine Zugangsdaten in Git mit hoch, und schwups, schon ist es passiert. Wobei, bei Crates scheint das seltener zu passieren als z.B. bei Chrome Extensions. MaWin schrieb: > mh schrieb: >> Und ja, ich sehe Malware in der Abhängigkeit als Qualitätsproblem. > > Wie soll die Malware da plötzlich hinein kommen? > Warum soll mir ein Entwickler plötzlich Malware unterschieben? Bei hunderten Abhängigkeiten würde ich mich doch eher fragen, warum sollte es darunter kein schwarzes Schaf geben? Semantic Versioning kann eine nette und nützliche Sache sein, aber Supply Chain Attacks kann es definitiv nicht verhindern.
🐧 DPA 🐧 schrieb: > jemand lädt versehentlich seine > Zugangsdaten in Git mit hoch, und schwups, schon ist es passiert. Dann ist dieser Entwickler halt unfähig. Gegen Unfähigkeit kann man leider wenig machen. Höchstens so etwas: https://doc.rust-lang.org/cargo/reference/manifest.html#the-publish-field 🐧 DPA 🐧 schrieb: > Bei hunderten Abhängigkeiten würde ich mich doch eher fragen, warum > sollte es darunter kein schwarzes Schaf geben? Ein Entwickler, der lange gute Versionen herausbrachte, bringt plötzlich Malware heraus? Wann ist das einmal passiert? Das ist doch ein Fall, den du dir jetzt herbeikonstruierst, um Recht zu behalten. Und wo ist der Unterschied zu jedem anderen System? z.B. Linux-Repos. Niemand, auch nicht Cargo, zwingt jemanden zu einem Update. Früher im Thread wurde behauptet, dass Leute ihre Dependencies gerne 100% auditieren wollen. Ja dann bitte. Tut das. Das würde ja dieses konstruierte Malwareproblem vollständig lösen. Das hat alles überhaupt gar nichts mit Rust zu tun!
MaWin schrieb: > 🐧 DPA 🐧 schrieb: >> jemand lädt versehentlich seine >> Zugangsdaten in Git mit hoch, und schwups, schon ist es passiert. > > Dann ist dieser Entwickler halt unfähig. Gegen Unfähigkeit kann man > leider wenig machen. Nicht zwangsläufig. Sowas ist schnell mal passiert, und könnte jedem passieren. > 🐧 DPA 🐧 schrieb: >> Bei hunderten Abhängigkeiten würde ich mich doch eher fragen, warum >> sollte es darunter kein schwarzes Schaf geben? > > Ein Entwickler, der lange gute Versionen herausbrachte, bringt plötzlich > Malware heraus? > Wann ist das einmal passiert? Das ist doch ein Fall, den du dir jetzt > herbeikonstruierst, um Recht zu behalten. Die Maintainer von Software können sich auch ändern, beim Updaten schaut da selten jemand nach. Und auch sonst gibt es viele Wege, wie soetwas unabsichtlich passieren kann. z.B. hatte es mal kurz bootstrap erwischt: https://nakedsecurity.sophos.com/2019/04/08/bootstrap-supply-chain-attack-is-another-attempt-to-poison-the-barrel/ z.B. Chrome extensions werden gerne mal verkauft: https://www.theregister.com/2021/01/07/great_suspender_malware/ Manchmal ist es auch nur ein blöder typo: https://github.com/jsdelivr/jsdelivr/issues/18070 (Hat damals glaube ich einige getroffen) Es gäbe noch mehr Beispiele, ist alles schon passiert. MaWin schrieb: > Und wo ist der Unterschied zu jedem anderen System? z.B. Linux-Repos. Das hängt jeweils von der konkreten Distribution und dessen Prozessen ab. Zumindest bei fixed Release Distros gibt es oft einen zumindest teilweise split zwischen Distro Mantainern und Entwicklern / Projektmaintainern. Eine Art 2 Augenprinzip, wenn man will. Die Distro Maintainer kennen sich entweder untereinander (kleine Distros), gehören zur selben Firma (z.B. RedHat), oder müssen anderweitigen Prozessen und Anforderungen genügen (z.B. debian), etc. Es gibt zudem normalerweise gewisse Moderadionsstrukturen, nicht jeder kann einfach Zeugs hochladen, und wie ein Maintainer mit Problemen umgeht, sowie soziale Aspekte, können jenachdem auch beachtet werden. Ausserdem ist es auch möglich, problematische Software zu entfernen. Die Pflege / das Managemant der Repos ist oft das entscheidende Alleinstellungsmerkmal von Distributionen. MaWin schrieb: > Niemand, auch nicht Cargo, zwingt jemanden zu einem Update. Nie upzudaten ist aber auch nicht unbedingt Sicherheitstechnisch ideal. MaWin schrieb: > Das hat alles überhaupt gar nichts mit Rust zu tun! Und deshalb schützt cargo nun plötzlich doch vor Supply Chain Attacks? Ja ja, schon klar, nur Reden, wenn es pro Cargo und pro Rust ist, ist notiert 🙄
🐧 DPA 🐧 schrieb: > Und deshalb schützt cargo nun plötzlich doch vor Supply Chain Attacks? Wer hat das behauptet?
MaWin schrieb: > 🐧 DPA 🐧 schrieb: >> Und deshalb schützt cargo nun plötzlich doch vor Supply Chain Attacks? > > Wer hat das behauptet? Operator S. schrieb: > Ironischerweise, löst genau Semantic Versioning das beschrieben Problem > von derguteweka Klar, das war weniger allgemein gehalten gedacht, läuft am Ende aber auf das heraus.
🐧 DPA 🐧 schrieb: > läuft am Ende aber auf das heraus. Es läuft einzig und alleine darauf hinaus, dass du mir Aussagen unterstellst, die ich nicht getätigt habe. Und die dazu noch aus dem Zusammenhang gerissen sind. Aber das machst du natürlich extra.
🐧 DPA 🐧 schrieb: > Nie upzudaten ist aber auch nicht unbedingt Sicherheitstechnisch ideal. Was willst du eigentlich? Du willst nicht updaten, weil das zu Sicherheitsproblemen führen könnte. Die neue Version könnte ja Malware enthalten, weil der Maintainer plötzlich zum Gangster wird. Du willst updaten, weil das zu Sicherheitsproblemen führen könnte. Die alte Version könnte ja Bugs enthalten. Wie soll man das lösen? Es ist unlösbar.
MaWin schrieb: > 🐧 DPA 🐧 schrieb: >> läuft am Ende aber auf das heraus. > > Es läuft einzig und alleine darauf hinaus, dass du mir Aussagen > unterstellst, die ich nicht getätigt habe. Keineswegs. Ich habe dich lediglich darauf hingewiesen, warum das ganze hier Relevant wurde: 🐧 DPA 🐧 schrieb: > MaWin schrieb: >> Das hat alles überhaupt gar nichts mit Rust zu tun! > Und deshalb schützt cargo nun plötzlich doch vor Supply Chain Attacks? Supply Chain Attacks in Relation zu Semantic Versioning / cargo war die relevante Problematik, um die es in der momentanen Argumentation seit Beitrag #6584067 ging. Das ist auch, weshalb das ganze hier überhaupt relevant wurde. Ich dachte es wäre klar, worüber wir Diskutieren? MaWin schrieb: > Was willst du eigentlich? Zu einem klareren Bild der ist-Situation und existierenden Problematiken beitragen? MaWin schrieb: > Wie soll man das lösen? > Es ist unlösbar. Ja, das ist so.
🐧 DPA 🐧 schrieb: > Ich dachte es wäre klar, worüber wir Diskutieren? Ja, das ist klar. Über alles, aber nicht mehr über Rust. > Ja, das ist so. Dann können wir es ja damit abschließen, dass auch Rust unlösbare Probleme nicht löst. Ok?
MaWin schrieb: > Ja, das ist klar. > Über alles, aber nicht mehr über Rust. für den Rest: "Rust" ist keine Platform sondern die Programmiersprache Cargo ist der Standard Package-Manager und das Buildsystem für Rust - aber sogar das muss man nicht nutzen und der Package-Manager kann so verantwortungslos (ich geben keine Versionen and und ziehe immer latest) bis zur absoluten statik (mein eigenes lokales crate wo ich alles von Hand rein tragen muss) konfiguriert werden - da kann man so viele Review Prozesse einschieben wie man braucht und will Alle Package-Manager können das - und ja, die werden von Millionen Leuten verwendet und das kann gefährlich sein - sogar GitHub und GitLab machen das wenn man z.B. die submodule updated - von irgendeinem Projekt und die Programmiersprache Rust ist auch nicht deswegen schlechter als andere weil ihr Standard-Package-Manager die gleichen unlösbaren Sicherheitsprobleme erzeugen kann wie jedes andere diese Systeme - also um was geht es? Ich arbeite u.a. in Projekte in dem alles durch ordentliche Review-Phasen laufen muss und jedes noch so kleine 3rd-Party Update einen riesen Aufwand verursacht - die haben teilweise auch lokale Package-Manager für C++ im Einsatz und die Packages die da rein kommen sind eben reviewed Vetrauen ist alles und Kontrollen machen die wenigsten - höchstwahrscheinlich sogar die am wenigsten die hier so gross davon reden wie wichtig das alles ist...
Operator S. schrieb: > mh schrieb: >> Da müsstest du die Beiträge von vor einem Monat lesen > > Hab ich, den Thread verfolge ich seit Beginn. > > Ironischerweise, löst genau Semantic Versioning das beschrieben Problem > von derguteweka (Warum auch immer das hier in einem Rust Thread gelandet > ist...) > > Wenn man nämlich nur schreibt Package Install MyFancyLib, dann holt er > sich das Package mit der höchsten Version das er finden kann. Ein > "Hacker" erstellt dann einfach auf der öffentlichen Paketsource ein > MyFancyLib mit einer sehr hohen Version und Zack landet es in deinem > System. > > Wenn man aber die Version spezifiziert a la Package Install MyFancyLib > 1.2.5 dann holt er genau diese eine Version. Und du stellst sicher, dass in MyFancyLib die Dependencies 100% korrekt definiert sind? Und in den Dependencies der Dependencies von MyFancyLib? Nachdem ich eben etwas auf crates.io gestöbert habe, muss man das wohl explizit selbst prüfen, da die meisten crates Dependencies explizit oder implizit als "Caret requirements" angeben. Ich hab einige ziemlich lange Ketten verfolgen können. Es ist auch klar warum das so ist. Niemand hat lust sich häufig "Dependency Resolution failed" vom resolver zu beschäftigen. 🐧 DPA 🐧 schrieb: > Wobei, > bei Crates scheint das seltener zu passieren als z.B. bei Chrome > Extensions. Bleibt die Frage, ob es tatsächlich so ist, oder ob es nur scheint. Die Zielgruppe für Chrome Extensions ist vermutlich deutlich größer. cppbert schrieb: > und die Programmiersprache Rust ist auch nicht deswegen schlechter als > andere weil ihr Standard-Package-Manager die gleichen unlösbaren > Sicherheitsprobleme erzeugen kann wie jedes andere diese Systeme - also > um was geht es? Wenn ich mich richtig erinnere, hast du behauptet, dass cargo den Pflegeaufwand für Software reduziert: mh schrieb: > cppbert schrieb: >> Jede Library hat die 5000.Implementation von irgendeinem Micro-Scheiss >> im Bauch die so viel Pflege-Energie frisst - das versucht Rust mit einer >> Zerlege- es-in-Libs-und-verteile-die-leicht zu reduzieren > > Damit ist man den Pflegeaufwand aber nicht los geworden, sondern verlegt > ihn nur woanders hin. Du musst regelmäßig die Abhängigkeiten prüfen In dem gleichen Beitrag hast du das übrigens auch als Vorteil von rust angepriesen: cppbert schrieb: > 4. Anstatt das jedes noch so kleine Projekt Self-Contained ist baut Rust > einfach darauf das sich die Code-Duplikation über viele, gut gepflegte > Libraries reduziert die in den heutigen Projekten in Mio Zeilen Code > rumgurken
mh schrieb: > Wenn ich mich richtig erinnere, hast du behauptet, dass cargo den > Pflegeaufwand für Software reduziert: > mh schrieb: >> cppbert schrieb: >>> Jede Library hat die 5000.Implementation von irgendeinem Micro-Scheiss >>> im Bauch die so viel Pflege-Energie frisst - das versucht Rust mit einer >>> Zerlege- es-in-Libs-und-verteile-die-leicht zu reduzieren >> >> Damit ist man den Pflegeaufwand aber nicht los geworden, sondern verlegt >> ihn nur woanders hin. Du musst regelmäßig die Abhängigkeiten prüfen > > In dem gleichen Beitrag hast du das übrigens auch als Vorteil von rust > angepriesen: > cppbert schrieb: >> 4. Anstatt das jedes noch so kleine Projekt Self-Contained ist baut Rust >> einfach darauf das sich die Code-Duplikation über viele, gut gepflegte >> Libraries reduziert die in den heutigen Projekten in Mio Zeilen Code >> rumgurken das sind zwei paar Stiefel Das einen ist die undurchsichtige und Codelastige alles-selber-machen Kultur durch eine es-gibt-viele-kleine Crates die sich auf Aufgaben konzentrieren Kultur zu ersetzen - die Libs werden kleiner und überhaupt reviewbarer Das ist das Konzept das wir alle intern mit jeder unserer eigenen Komponenten fahren - was vom Grundsatz nicht falsch und nicht wirklich diskutierbar ist bei C/C++ klappt das einfach Aufgrund des schwierigen Deployments (welche Make-Tool, 3rd-Parties, etc.) nicht so gut über die Projektgrenzen hinweg, ist aber eher eine historische Schwäche als ein gewolltest Konzept von C/C++ Das zweite ist die Menge der Entwicklern die plötzlich Einfluss auf dein Projekt haben könnten - da geben ich dir recht das es nicht einfacher wird - aber Monolithen-Libs mit viel gemeinsamen Redundanzen ist es eben auch nicht - da wähle ich lieber die Qualität ergibt sich durch die Community - und wenn ich viele 3rd-Parties brauche bin verliere ich auch mit C/C++ recht schnell die Kontrolle (falls man wirklich nicht auf die 3rd-Parties verzichten kann) und ich denke die wenigsten hier machen überhaupt irgendwelche Reviews von 3rd-Parties - wenn es kompiliert und die Tests laufen ists gut wird wohl die Standard-Devise sein, die Community der Libs oder gar die Kern-Entwickler haben auch die wenigsten auf ihrer Kontakt-Liste also ist die Qualität nur gut weil man nix negatives im Internet liesst oder eben keinen 3rd-Parties hat noch dazu heisst es ja immer das Rust nicht nötig ist weil jede Firma sowiso nur Profi-Entwickler angestellt haben sollte - d.h. die können sich dann in Rust aufhören mit den internen Problemen zu beschäftigen sondern nur noch Algorithmik und die Sicherheits-Probleme durch die vielen 3rd-Party Abhängigkeiten bekämpfen :)
mh schrieb: > Und du stellst sicher, dass in MyFancyLib die Dependencies 100% korrekt > definiert sind? nein. Ich nicht. Das war aber auch nie meine Anforderung.
Beitrag #6602631 wurde von einem Moderator gelöscht.
mit dem neuen VS2019 16.9 Release können wir jetzt auch unter Windows/VStudio mit dem ASAN arbeiten - raus aus der Beta-Phase - läuft super - "leider" keine Findings da mein Code ja schon unter Linux seit einigen Jahren unter Sanitzer Kontrolle steht https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes#16.9.0 Und für die "C++ ist ausreichend perfekt durch ASAN"-Fraktion: Stellt euch mal vor wenn google nicht aus Eigeninitative die Sanitizer entwickelt hätte - wohlgemerkt nach "Jahrzehnten" der C/C++ Existenz, was würde eigentlich dann weiterhin für die Memory-Sicherheit bei C/C++ Applikationen unter Windows sorgen - der olle Intel Inspector, Dr. Memory...? und ja ist versteht das auch Rust einen Neuentwicklung ist - nur ist da sowas von Anfang an dabei, C/C++ hat dafür 25 Jahre auf einen Gross-Konzern warten müssen
und auch wenn ihr mir nicht glaubt (oder ich nur viele Idioten kenne) Es gibt sogar C/C++ Entwickler die nicht verstehen was an Rust besser ist UND die zusätzlich auch keinen Sinn in den Sanitizern sehen Noch besser: die den Sinn von Sanitizer erst verstehen wenn man ihnen im VStudio, in ihrem Code einen durch den ASAN gefundenen Bug zeigen kann - meistens wird dann ganz schnell aus einem unwissenden Kritiker ein Missionar ganz nach dem Motto: Erst wenn ich den Schimmel wirklich schmecken kann erkennen ich das irgendwas mit meinem weiß pelzigen Brot nicht stimmt :)
cppbert: Ich würde nicht soweit gehen, diese Idioten als Idioten zu bezeichnen(Spässle). Der Mensch ist unbeweglich. Besonders geistig. Ohne jemanden damit beleidigen zu wollen und natürlich ist das oberflächlich. Was ich hier noch einmal betonen will ist, dass absolut kein Zwang besteht auf etwas Vernünftigeres und womöglich "Vesseres" zu wechseln. Das ist eine Sache. Aber die eigene Beratungsresistenz und Vorurteile unter den anderen Programmierern und Programmierer-Nachwuchs-Volk zu verteilen ist peinlich und kurzsichtig. Schade, dass man dies mit Scheuklappen nicht sehen kann. Hab viel Geduld und Kraft, lieber cppbert3. Dieser sinnlose Streit über das richtige Werkzeug hört nämlich niemals auf. Es ist wie mit dem Geschmack. Manche mögen ihren Käse erst so richtig mit viel viel Schimmel. Die Perversen haben sogar lateinische Kosenamen;) Um zum Thema zurück zu kommen: Rust? Cool. Das bleibt. Alleine schon die 163 Libs die mein Amateur-Kannst-Mich_Mal-Programm zum befragen meines Fernsehers (MIPS VU+ Box, Enigma2) braucht. Schrecklich! Und dann funktioniert das auch noch Lokal (x86) und Remote (mipsel). Okay so einfach war es auch nicht. Ich fühlte mich nicht sehr gut als ich den Pull Request für das MIPS OpenSSL in Rust hochgeladen habe. Habe aber bisher noch keine Morddrohungen oder einen Regressanspruch erhalten. Cargo ist nicht Rust. Es ist nur in Rust geschrieben. Lasst uns doch mal gegen Conan schelten und deswegen C++ verdammen. Das ist nur gut, wenn man Beiden, den Conan und C++ Entwicklern auf die Nerven gehen will. Python libraries, Node-Chaos? ... Wer blickt da schon durch? Das ist aber ein völlig anderes Problem, nämlich der Versionsverwaltung und des Paketmanagements. Kein Alleinstellungsmerkmal von Rust UND Cargo! Ach übrigens:
1 | std::auto_ptr<MaWin> cppBert ... |
Jeder macht mal Fehler. (Die Klassen- und Variablennamen des Beitrags sind frei erfunden. Etwaige Ähnlichkeiten mit tatsächlichen Begebenheiten oder lebenden oder verstorbenen Personen wären rein zufällig.)
Keine Ahnung was "Vesseres" bedeuten soll. ... vielleicht etwas besseres Verwässertes?:) Außerdem: node != npm und pip != python
:
Bearbeitet durch User
Jedzia D. schrieb: > Cargo ist nicht Rust. Es ist nur in Rust geschrieben. Lasst uns doch mal > gegen Conan schelten und deswegen C++ verdammen. Mir ist bisher noch kein C++ Projekt über den Weg gelaufen, bei dem conan der Hauptweg ist, wie man an die Dependencies kommt und alles Kompiliert. Bis vorhin habe ich von conan tatsächlich noch nie gehört. Bei Cargo hingegen sieht das alles ganz anders aus, da muss man suchen, um etwas zu finden, was es nicht nutzt. Die Situation ist schlicht nicht vergleichbar.
Zudem wurde hier auch immer klar angegeben, ob ein Problem/Vor-/Nachteil mit Cargo oder mit Rust besteht. Wäre die Diskussion gegen C++, und jemand würde sagen, verwendet nicht Conan, weil XY, hätte ich damit ehrlich gesagt kein Problem.
- Ja sind Build-System und Compiler jetzt verschiedene Dinge oder nicht? (JA) - Welche Verrückte würde rustc (der Compiler) mit einem Makefile oder CMake benutzen? (Anwesende ausgeschlossen). Wer koa, der koa. > Bis vorhin habe ich von conan tatsächlich noch nie gehört. Tut mir leid:( Und in der Tat, das sind völlig andere Probleme als die der Sprachsemantik, Speichersicherheit, etc. 🐧 DPA 🐧 schrob außerdem: > Zudem wurde hier auch immer klar angegeben, ob ein Problem/Vor-/Nachteil > mit Cargo oder mit Rust besteht. Das muss eine Parallelwelt sein, in der Du in diesem Faden hoch scrollen kannst und nicht alles durcheinander geworfen wird. Ist ja auch egal, kost nur Haare. Satire: Ich komme aus einer Welt der guten Vorsätze. Aber alles endet irgendwann auf einem riesigen Scheißhaufen, wie etwa: - das Repository von NPM, - der letzte PlatformIO Library Manager sprang in den Fluss, - pypi.org's hackertools infizieren sich schon selbst, - Leiningen ist viel zu cool für das alles, - Unstable, nightly-only --cargo-features sind so tief verschachtelt, dass sie ein eigenes Bewusstsein entwickeln und die Menschen als Bedrohung ansehen, besonders MaWin. Tja, gegen das fehlerhafte setzen eines Index innerhalb der Array-Grenzen (Bounds), hilft auch kein Bounds-Checker. (Tut mir leid, MaWin:)) - etc. pp., alles von Muttern was eingemacht wird und ein Schild für späteres beäugen bekommt... 🐧 DPA 🐧 schrieb: > Wäre die Diskussion gegen C++, und jemand würde sagen, verwendet nicht > Conan, weil XY, hätte ich damit ehrlich gesagt kein Problem. Klar. Mir sind die Anderen erst einmal anders und ich kenne mich bei mir am Besten aus. Etwa meine persönlichen Templates und in Jahren gewachsenen Monstrositäten. Das ist alles subjektiv und funktioniert für mich flott, einwandfrei und einleuchtend, manchmal bin ich sogar richtig produktiv;) Ich finde dein Gedankenexperiment etwas schräg[1]: Conan ist nur das Programm. Dahinter stecken XYZ ... 2 Leute? Eine Firma? Eine Community? ... die das Gertriebe der ganzen Packetmanager Chausse ölt. Kein Problem mit der ganzen "Sache" zu haben ist übrigens selbstverständlich. Es geht mich, dich oder sonnst wen nichts an, wie jemand seine Arbeit verrichtet. Kritik ist erlaubt, klar, Respekt aber auch. Conan kannst Du mit jedem Community/Firmen betriebenen Datenbanksystem, das organisch wächst, ersetzen. Bla, Ich bitte nur darum die einzelnen Schichten der Sprachumgebung zu trennen, oder vielleicht einmal darüber nachzudenken. DPA, Du hast natürlich auch Recht: Es ist ein Ökosystem. Der Rest der Welt oooch;) [1] Das Fass von den n^m Möglichkeiten der Objektivität, also möglicher (und legitimer) Toolverwendung, Expression, Impression, Iteration und was auf der Menükarte der Verfügbarkeiten gerade steht, machen wir nicht auf? Rust? Werkzeusch. Basta!
"2 Leute? Eine Firma? Eine Community?" bezieht sich nun-chalant natürlich nicht auf das Repository von Conan. Jeder kann selbst auf https://conan.io/center/ nachschauen. Das wird ohne jede Frage von Fröschen durchorganisiert. Ich bezog mich da auf ALLLLLEEEES !!! Also meistinklusiv auf jeden erdenklichen Paketmanager und Paketmanagerin auf diesem Planeten und nicht spezifisch auf die guten Leute von Conan. Kein plan von Fröschen, allerdings... [Hint] JFrog ConanCenter
DPA: "Tut mir leid:(" ist natürlich scherzhaft gemeint. ... weil ich die Schuldige bin, die Conan in dein Leben bringt. Verzeihung, also noch einmal;) (Mit einem Zwinkern)
google unterstüzt Rust im Linux Kernel - (und Nein, ihr eigenes Go kann nicht im Kernel genutzt werden) https://security.googleblog.com/2021/04/rust-in-linux-kernel.html der Binder-Code in Rust sieht fiese aus - liegt aber auch daran das da viel C-Binding/FFI Sachen zu sehen sind Linus und Greg sind weit, weit offener als zu den damaligen C++ Diskussionen :) ich bin gespannt ob diese Integrations-Bestrebungen zu weiteren Verbesserungen in Rust führen und schlussendlich auch die Integration in den Kernel passiert und ob das auch die GCC Frontend-Entwicklung befeuert mittlerweile sind alle Grossen der Branche für ihre Low-Level Entwicklung mehr oder minder auf den Rust Zug aufgesprungen - google, Microsoft, Amazon, Facebook... egal wie man die Sache sieht - Rust in den Bereichen ihren eigenen Produkten/bisherigen Strategien vorzuziehen ist schon eine Aussage und Nein, kein Mensch der bei klarem Verstand ist möchte dann alles portieren :) - sagt auch niemand, und denkt nicht mal irgendjemand und Nein, eine C/Rust Mischung ist nicht per se der Teufel - nur für die Leute die immer gleich alles portieren wollen :)
> google unterstüzt Rust im Linux Kernel - (und Nein, ihr eigenes Go kann > nicht im Kernel genutzt werden) Jaja, ich hab das hier gelesen: https://www.heise.de/news/Startschuss-fuer-Rust-Entwicklung-im-Linux-Kernel-6017060.html Der Artikel hat mir mal wieder klar gemacht was in der heutigen Entwicklung alles so falsch laeuft. Ich zitiere mal einen Satz: Ein Kernel-Crate (Rust-Bezeichnung für Bibliothek) stellt die Kernel-API für Rust-Module bereit. Diese ganzen Bullshitbingoschwachkoepfe denken sich fuer den banalsten Unsinn eigene Sandkastenwoerter aus, die sie dann noch anderen erklaeren muessen weil sonst keiner mit ihnen spielen will, und wundern sich das ihren Kram keiner will? Olaf
Olaf schrieb: > Diese ganzen Bullshitbingoschwachkoepfe denken sich fuer den banalsten > Unsinn eigene Sandkastenwoerter aus Welcher Begriff stört dich denn?
Ich vermute, er meint das: Olaf schrieb: > Ein Kernel-Crate (Rust-Bezeichnung für Bibliothek) Warum nennt man eine Bibliothek "Crate" statt "Bibliothek"? Ist so ähnlich wie bei Arduino, wo ich mich schon immer gefragt habe, warum ein Programm nicht "Programm" heißt, sondern "Sketch".
Rolf M. schrieb: > Warum nennt man eine Bibliothek "Crate" statt "Bibliothek"? Weil ein Crate viel mehr ist als das, was man üblicherweise unter einer Bibliothek versteht. Ich würde Crate eher mit Paket übersetzen. Das käme ja auch vom Wortsinn etwas besser hin. Es ist nicht so, als hätte man bei Rust beliebig Worte ohne Not erfunden. Es gibt ja auch z.B. Module und auch ein Lib(-Crate).
Moin, So, aus aktuellem Anlass hab' ich mir mal grad' wieder den rav1e neu ausgecheckt. Und versucht zu bauen. Bricht natuerlich ab.
1 | error[E0658]: const generics are unstable |
2 | --> /root/.cargo/registry/src/github.com-1285ae84e5963aae/arrayvec-0.7.0/src/utils.rs:6:15 |
3 | | |
4 | 6 | impl<T, const N: usize> MakeMaybeUninit<T, N> { |
5 | | ^ |
6 | | |
7 | = note: see issue #74878 <https://github.com/rust-lang/rust/issues/74878> for more information |
...usw...bla..fasel...
1 | For more information about this error, try `rustc --explain E0658`. |
2 | error: could not compile `arrayvec`. |
OK, mach'mer mal, wie angeheisen, dann kommt:
1 | If you're using a stable or a beta version of rustc, you won't be able to use |
2 | any unstable features. In order to do so, please switch to a nightly version of |
3 | rustc (by using rustup). |
4 | |
5 | If you're using a nightly version of rustc, just add the corresponding feature |
6 | to be able to use it: |
7 | |
8 | ... |
So, dann wird's mal Zeit, in die doc zum rav1e zu gucken - huch, da steht:
1 | rav1e currently requires Rust 1.51.0 or later to build. |
Ja, dann ists natuerlich klar, mein uralter rustc in der Version 1.47.0 kann das natuerlich nicht mehr bauen, den hab' ich ja auch schon vor fast 3 Monaten installiert, weil mein vorhergehender ja auch schon voellig veraltet war. Bestimmt schon 6..9 Monate alt. Bei so'ner alten Toolchain ist das ja kein Wunder. Und jetzt hoffentlich bald diese richtungsweisende, stabile Sprache im Linuxkernel. Millionen Fliegen koennen nicht irren... I gfrei' mi riesig! Gruss WK
Moin, MaWin schrieb: > rustup update > > Schon schwierig, gell? In der Tat:
1 | root [ /usr/src/rav1e ]# rustup update |
2 | -bash: rustup: command not found |
3 | root [ /usr/src/rav1e ]# |
Und ganz abgesehen davon halte ich's fuer keine gute Idee, fuer jedes Projekt in jeder Versionsnummer dann auf den jeweils "richtigen" rust compiler achten zu muessen. Gruss WK
Dergute W. schrieb: > root [ /usr/src/rav1e ]# rustup update > -bash: rustup: command not found Ja gut. Dann ist deine Installation halt kaputt. Und warum machst du das überhaupt als root? > Und ganz abgesehen davon halte ich's fuer keine gute Idee, fuer jedes > Projekt in jeder Versionsnummer dann auf den jeweils "richtigen" rust > compiler achten zu muessen. Rust ist rückwärtskompatibel. Und das ist auch erklärtes Ziel von Rust. Das heißt man kann immer den aktuellen stable-Compiler verwenden. Ich sehe da auch überhaupt kein Problem. Es gibt so gut wie keine praktisch verwendete relevante Sprache, die nicht auch weiterentwickelt wird. Das gilt auch für so abgehangene Sprachen wie C.
Dergute W. schrieb: > Moin, > > So, aus aktuellem Anlass hab' ich mir mal grad' wieder den rav1e neu > ausgecheckt. > Und versucht zu bauen. Bricht natuerlich ab. das ist eine mehr als bekannte Schwäche der Sprache - weil sie eben noch in sehr stark in der Entwicklung ist - sollen sie einfach alle Feature von C++ kopieren und dann Releasen oder einfach nur C Klonen - damit solche Sprächänderungen/Erweiterungen nicht passieren - was wäre denn laut dir am sinnvollsten - außer es gar nicht zu machen das N was da mukiert wird ist das neue Feature von Konstanten als Template-Parameter - was es bei C++ eben schon seit 20 Jahren gibt, davor aber genau so wenig vorhanden war - da hat auch jeder alte Kompiler zu der Zeit das fluchen angefangen als die Libs darauf umgestellt wurden - warum darf so was heute deiner Meinung gar nicht mehr passieren? Denkst du ernsthaft das diese häufigen Änderungen zum Standard werden - oder das die Menschen die dahinter stehen alle so schlecht sind das Problem nicht als solches zu erkennen? C/C++ war 5 Jahren nach effektivem Erst-Release auch Meilen weg von Standard und Gleichmäßigkeit - ich glaube ihr seit alle zu jung oder habt vergessen wie das damals war
Dergute W. schrieb: > Moin, > Und ganz abgesehen davon halte ich's fuer keine gute Idee, fuer jedes > Projekt in jeder Versionsnummer dann auf den jeweils "richtigen" rust > compiler achten zu muessen. das war als C/C++ erfunden wurde doch genau so - oder hast du erst in den späten 90er mit Software-Entwicklung angefangen?
Olaf schrieb: > Jaja, ich hab das hier gelesen: > > https://www.heise.de/news/Startschuss-fuer-Rust-Entwicklung-im-Linux-Kernel-6017060.html relevant ist aber das Google jetzt aktiv diese Projekt unterstützt - offiziell und mit eigenen Entwicklern
Dergute W. schrieb: > So, aus aktuellem Anlass hab' ich mir mal grad' wieder den rav1e neu > ausgecheckt. > Und versucht zu bauen. Bricht natuerlich ab. das passiert dir genau so mit deinem alten Kompiler wenn du eine C11 oder C++17 Lib kompilieren willst bei Qt6 ist C++17 jetzt der Standard - d.h. mind VS2017 latest oder VS2019, oder gcc 7+ aber solche Libs sind dann eben für dich unrelevant und daher kein Problem der Sprache
cppbert schrieb: > Olaf schrieb: >> Jaja, ich hab das hier gelesen: >> >> > https://www.heise.de/news/Startschuss-fuer-Rust-Entwicklung-im-Linux-Kernel-6017060.html > > relevant ist aber das Google jetzt aktiv diese Projekt unterstützt - > offiziell und mit eigenen Entwicklern Warum ist das relevant? Gibts jetzt endlich nen Standard und nen alternativen Compiler?
cppbert schrieb: > bei Qt6 ist C++17 jetzt der Standard - d.h. mind VS2017 latest oder > VS2019, oder gcc 7+ Es gibt schon einen kleinen Unterschied zwischen einem mehr als 3 Jahre alten Standard und einer speziellen Compilerversion, die nichtmal einen Monat alt ist.
mh schrieb: > Es gibt schon einen kleinen Unterschied zwischen einem mehr als 3 Jahre > alten Standard und einer speziellen Compilerversion, die nichtmal einen > Monat alt ist. Nein, nicht wirklich. Wenn dein Compiler älter ist, funktioniert es nicht. Dann ist ein Update fällig. Das ist in beiden Fällen identisch. Ich sehe auch keinen Grund das Compilerupdate zu verzögern. Es ist ein einziger Befehl, der dein Problem löst: rustup update
mh schrieb: > Warum ist das relevant? Gibts jetzt endlich nen Standard und nen > alternativen Compiler? Nein - aber darf sich das durch solche Projekte nicht erst entwickeln? Woher kommt ständig dieser Es-muss-fertig-sein-Hochmut dem fast keine Programmiersprache in ihrer Entwicklung gerecht wurde und auch die meisten von euch nicht bei ihrere eigenen Arbeit leisten können? Warum so ängstlich - denkst du ernsthaft das die Kernel-Entwickler Rust akzeptieren bevor nicht alle Bedenken ausgeräumt sind - denkst du die sind sind Fähig für ihr weit >10Mio Zeilen Code Projekt richtige und sinnvolle Entscheidungen zu treffen? meinst du da kommt jede Sprache einfach so rein? Ich hätte auch gerne noch ein gcc-Frontend und einen Standard - aber scheinbar ist Rust auch schon so relevant genug das es nicht wie alle anderen Sprachen die es versucht haben direkt an Linus und Greg scheitert
mh schrieb: > Es gibt schon einen kleinen Unterschied zwischen einem mehr als 3 Jahre > alten Standard und einer speziellen Compilerversion, die nichtmal einen > Monat alt ist. Wie lange ist C++ in der Entwicklung, wie lange Rust? Was willst du vergleichen?
MaWin schrieb: > Ich sehe auch keinen Grund das Compilerupdate zu verzögern. Es gibt schon viele Projekte wo so was nicht erlaubt ist - weil die Kompiler neue Fehler einbringen könnten - z.B. im Medizinbereich war ich dem stark ausgesetzt
MaWin schrieb: > mh schrieb: >> Es gibt schon einen kleinen Unterschied zwischen einem mehr als 3 Jahre >> alten Standard und einer speziellen Compilerversion, die nichtmal einen >> Monat alt ist. > > Nein, nicht wirklich. > Wenn dein Compiler älter ist, funktioniert es nicht. Dann ist ein Update > fällig. Das ist in beiden Fällen identisch. Das heißt ich kann ab jetzt erwarten, dass jeder C++20 benutzt? > Ich sehe auch keinen Grund das Compilerupdate zu verzögern. > Es ist ein einziger Befehl, der dein Problem löst: > rustup update Du hast gesehen, warum der zu alte rustc abbricht?
1 | error[E0658]: const generics are unstable |
Ist rust 100% abwärtskompatibel? Also alles was mit 1.47 korrekt funktioniert hat, funktioniert auch mit 1.51?
cppbert schrieb: > Es gibt schon viele Projekte wo so was nicht erlaubt ist - weil die > Kompiler neue Fehler einbringen könnten - z.B. im Medizinbereich war ich > dem stark ausgesetzt Richtig. Und in solchen Projekten zieht man sich die neusten Crates rein, die neue Compilerabhängigkeiten bekommen? Natürlich macht man das nicht. Damit existiert das Problem auch nicht.
cppbert schrieb: > mh schrieb: >> Es gibt schon einen kleinen Unterschied zwischen einem mehr als 3 Jahre >> alten Standard und einer speziellen Compilerversion, die nichtmal einen >> Monat alt ist. > > Wie lange ist C++ in der Entwicklung, wie lange Rust? > Was willst du vergleichen? Man könnte mit der Zeitdifferenz zwischen erster Veröffentlichung der Sprache und des offiziellen Standards anfangen. Oder Anzahl der Compiler nach 10 Jahren.
mh schrieb: > erwarten, dass jeder C++20 benutzt? Nein. Warum? Nur weil ein Crate einen neueren Compiler voraussetzt, wird nicht gleich jeder gezwungen ein Update zu machen. Weder auf das neue Crate, noch auf den neuen Compiler. > Du hast gesehen, warum der zu alte rustc abbricht?error[E0658]: const > generics are unstable Ja, und? > Ist rust 100% abwärtskompatibel? Also alles was mit 1.47 korrekt > funktioniert hat, funktioniert auch mit 1.51? Ja.
mh schrieb: > Man könnte mit der Zeitdifferenz zwischen erster Veröffentlichung der > Sprache und des offiziellen Standards anfangen. Oder Anzahl der Compiler > nach 10 Jahren. Und welche Erkenntnis bringt das?
MaWin schrieb: >> Ist rust 100% abwärtskompatibel? Also alles was mit 1.47 korrekt >> funktioniert hat, funktioniert auch mit 1.51? > > Ja. Aber natürlich bringt das nichts wenn man Features nutzt die erst in 1.51 verfügbar sind, aber das ist bei keiner Programmiersprache die sich noch weiterentwickelt anders Auch bei C++ ist das Geschrei gross wenn Libs den notwendigen Standard anheben, weil es immer einen Haufen Leute gibt die nur C++03 kompilieren können
cppbert3 schrieb: > MaWin schrieb: >>> Ist rust 100% abwärtskompatibel? Also alles was mit 1.47 korrekt >>> funktioniert hat, funktioniert auch mit 1.51? >> >> Ja. > > Aber natürlich bringt das nichts wenn man Features nutzt die erst in > 1.51 verfügbar sind, aber das ist bei keiner Programmiersprache die sich > noch weiterentwickelt anders > > Auch bei C++ ist das Geschrei gross wenn Libs den notwendigen Standard > anheben, weil es immer einen Haufen Leute gibt die nur C++03 kompilieren > können Bei allen gängigen C- und C++-Compilern ist es schon so, daß die neuen Versionen die neuen Features der Sprache unterstützen. Ein altes C-Programm aus Zeiten von Kernighan und Ritchie geht dann nicht mehr als C++ 20 durch. Aber trotzdem kann ich sie glatt kompilieren, wenn ich --std=.. angebe. Erst wenn ich im Quelltext einen neueren Standard nutze, muß ich den dann auch erfüllen und alte Leichen wegräumen oder mumifizieren. Der neueste gcc kompiliert wunderbar über 40 Jahre alte Quelltexte. Reibungsverluste in älteren Programmen durch neue Standards sind nach meiner Erfahrung recht übersichtlich und eher in einer Ecke zu finden, wo man vielleicht sogar ohnehin besser nochmal reinschauen sollte. Jetzt kann man von einer relativ neuen Entwicklung wie Rust das gar nicht verlangen, das wäre unfair. Aber im Umkehrschluß finde ich dann, daß es für professionelle Entwicklung viel zu unausgegoren ist. Mir zieht es die Fußnägel hoch, wenn man damit auf Linux losgehen will.
Klaus W. schrieb: > Ein altes C-Programm aus Zeiten von Kernighan und Ritchie geht dann > nicht mehr als C++ 20 durch. Aber trotzdem kann ich sie glatt > kompilieren, wenn ich --std=.. angebe. > Erst wenn ich im Quelltext einen neueren Standard nutze, muß ich den > dann auch erfüllen und alte Leichen wegräumen oder mumifizieren. > > Der neueste gcc kompiliert wunderbar über 40 Jahre alte Quelltexte. Das ist bei Rust ganz genau so. --std heißt bei Rust "edition". > Jetzt kann man von einer relativ neuen Entwicklung wie Rust das gar > nicht verlangen, das wäre unfair. Doch. Das kann man verlangen und das ist auch erklärtes Ziel von Rust. Klaus W. schrieb: > Mir zieht es die Fußnägel hoch, wenn man damit auf Linux losgehen will. Wie begründest du das?
Die Rust "Editions" dürften so gut funktionieren, dass Vittorio Romeo für C++ ein ähnliches System ala "Epochen" vorgeschlagen hat, mit denen sich bewusst Rückwärtskompatibilitäten hätten brechen lassen sollen. Der Vorschlag wurde aber leider recht früh abgelehnt.
MaWin schrieb: >> Jetzt kann man von einer relativ neuen Entwicklung wie Rust das gar >> nicht verlangen, das wäre unfair. > Aber warum beschwerst du dich dann das dein c++11 kompiler die lib nicht kompilieren kann die c++14 Features nutzt Die lib die du da baust wird ziemlich nah an der latest Entwicklung gehalten, weil die von den Neuerungen stark profitieren, ist natürlich nicht so nett für dich, aber Rust kann nichts dafür das die eben jedem Feature hinterherspringen Die sind sozusagen geraden von c++17 auf c++20 gesprungen
MaWin schrieb: > Klaus W. schrieb: > >> Mir zieht es die Fußnägel hoch, wenn man damit auf Linux losgehen will. > > Wie begründest du das? Weil er die Kompilierfehler fälschlicherweise als Kompatibilitätsprobleme erkannt hat obowohl eigentlich die Lib plötzlich latest Features braucht Und es immer wieder mitschwingt als wäre die Linux Kernel Entwicklergemeinde nicht in der Lage sinnvolle Entscheidungen zu treffen, so wie scheinbar die meisten Grossen scheinbar aus niederen oder den falschen Gründen anfangen Rust zu betrachten, obwohl C und C++ ja scheinbar alles genau richtig machen
cppbert3 schrieb: > Aber natürlich bringt das nichts wenn man Features nutzt die erst in > 1.51 verfügbar sind, aber das ist bei keiner Programmiersprache die sich > noch weiterentwickelt anders > > Auch bei C++ ist das Geschrei gross wenn Libs den notwendigen Standard > anheben, weil es immer einen Haufen Leute gibt die nur C++03 kompilieren > können C++03 ist 18 Jahre alt, Rust 1.47 ein halbes Jahr. Wenn du jetzt geschrieben hättest "… weil es immer einen Haufen Leute gibt die nur C++20 kompilieren können", hätte es vom Alter der Version her besser gepasst. Und das Geschrei wäre vermutlich tatsächlich recht groß, wenn schon C++20 nicht mehr reichen würde.
:
Bearbeitet durch User
Rolf M. schrieb: > C++03 ist 18 Jahre alt, Rust 1.47 ein halbes Jahr. Und es war die Entscheidung der Crateentwickler, die relativ neue Version 1.51 voraussetzen. Das hat mit Rust ansich gar nichts zu tun. Genauso gut hätten C++-Lib-Entwickler irgendein brandneues GCC-Feature vorausetzen können. Das ist eine ganz normale Entwicklungsentscheidung. Aber ich kann es gut nachvollziehen, warum man gerne die neusten Rust-Features nutzt. Denn ein Rust-Compiler-Update ist sehr einfach und problemlos durchführbar für jeden. Und wenn jemand das nicht möchte, kann sie ja gerne auf der älteren Crateversion bleiben.
> Und jetzt hoffentlich bald diese richtungsweisende, stabile Sprache im > Linuxkernel. Ich schaetze dafuer muss das Build-System dann problemlos mit Makefile funktionieren und die ganze automatische Internet-Librarykacke wird rausgeworfen. Sonst bleibt das nicht lange drin weil Linus vermutlich sofort das Messer in der Tasche aufgeht wenn er seinen Kernel neu uebersetzen will und es nicht klappt weil irgendein scheiss sich updaten muss, nach dem updaten was anderes nicht funktioniert usw... Olaf
Olaf schrieb: > Ich schaetze dafuer muss das Build-System dann problemlos mit Makefile > funktionieren und die ganze automatische Internet-Librarykacke wird > rausgeworfen. Sonst bleibt das nicht lange drin weil Linus vermutlich > sofort das Messer in der Tasche aufgeht wenn er seinen Kernel neu > uebersetzen will und es nicht klappt weil irgendein scheiss sich updaten > muss, nach dem updaten was anderes nicht funktioniert usw... Wie schon 1000 mal gepostet: das ist kein Zwang, du kannst auch alles selber verwalten - und das ist genau das was die Kernelentwickler machen werden wenn es denn dazu kommt
Rust fügt ein paar interessante Ideen ein: -einheitliches Cargo Buildsystem -das "match" System ist mächtig -error handing gefällt mir gut -mehr move als copy Und Rust wäre auch eine schöne Sprache, wäre sie nur nicht so schmerzhaft zu nutzen. Fast alle Sachen brauchen 10mal so lange wie z.b. in C++. Ständig hängt man am borrow checker fest. Greife auf eine Klassenvariable zu. Greife dann auf eine andere zu. Geht schon nicht, weil `self` schon geborrowed wurde. Selbst die einfachsten for-loops durch Container kann man da vergessen. Antwort von der Rust Community: "Ja sowas machen wir hier nicht. Optionen:" -Algorithmus umschreiben (bitte was?) -Datenstruktur verändern, mit Boxen und Refcounting -Fiese Speicher-moves Alle komplexeren Datenstrukturen sind extrem schmerzhaft aufzubauen. Dann, das trait system. In der Theorie ganz lustig. Man kann einem i32 neue Funktionen dranhängen. Yey. In der Praxis sucht man sich in der Doku kaputt wo das trait jetzt herkommt und in welcher Crate man jetzt sein Feature findet. Ja ich weiß, Doku kommt mit der Zeit. Doch dass sich mein Funktionsumfang pro Typ ändern kann und nicht einfach ein klares Interface hat ist schon... seltsam Und dann Clippy und der Auto-formatter. Auch hier wieder, in der Theorie gut. In der Praxis fixe ich ständig irgentwelche Kleinigkeiten Wo Clippy sich wieder aufregt. Neulich passte ihm der Name meines Typen nicht. Gibt ein Standard-naming und meine Variable passt nicht. Rust Community sagt wieder "nicht unser Problem, DU machst was falsch". Und als Sahnehäubchen oben drauf hat der autoformatter einen riesen Spaß dabei, 10 Zeilen die inhaltlich zusammen hängen jedes mal anders umzubrechen. Konsistenz von Code ist wohl heute nicht mehr wichtig. Daher: Andere Sprachen (besonders C++), nehmt euch ein Beispiel an den guten Ideen die Rust bringt und baut diese auch ein. Grade Paketmanager + Buildsystem ist sehr hilfreich. Aber die Sprache selber... wollte zu viel, Ziel überschossen. Und zur Sicherheit: Die Entwicklung ist um ein vielfaches Langsamer, Netzwerkfehler, Logikfehler, etc gibt es auch weiterhin. 90% der Zeit steckt eh wieder ein Kunde daher der auf seiner Seite einen Fehler produziert hat der das ganze System anhält. Aber hey, dafür haben wir keine Speicherleaks mehr. Wie war das? Haben wir in C++ dank RAII auch nie gehabt? Hmm. Aber die Datensicherheit und das Owner Konzept! Oh, gibts in C++ auch. Hmm.
> und meine Variable passt nicht. Rust Community sagt wieder > "nicht unser Problem, DU machst was falsch". Das ist ein Standardproblem unserer Zeit. In Sprachen der C-Familie hast du alle Moeglichkeiten, musst aber eine ganze Menge lernen, unter anderem damit du manche der Moeglichkeiten nicht nutzt. Etwas das nicht immer klappt und dann zu Fehlern fuehrt und das noch ganz besonders wenn du eher weniger gute (preiswerte) Programmierer nutzen moechtest. Es gab in den letzten 30Jahren eine Verschiebung von wenigen Programmierer fuer eher "wichtige" Sachen zu vielen Programmieren fuer "jeden Scheiss der nicht bei drei auf den Baeumen ist". Daher gibt es ein Interesse daran die Leute soviel wie moeglich zu gaengeln. Diese Sprachen kommen ja nicht mehr aus dem Interesse der Programmierer ein Problem zu loesen, sondern aus dem Interesse einer Firma das ihre Probleme so preiswert wie moeglich geloest werden. Eine gute Sprache ist das Handwerkzeug eines Kuenstlers um Kunstwerke zu schaffen (im Idealfalle!) heute will man aber nur noch Handwerk. > Andere Sprachen (besonders C++), nehmt euch ein Beispiel an > den guten Ideen die Rust bringt und baut diese auch ein. Ja, ich denke etwa in diese Richtung sollte es laufen. Wobei man sich manchmal fragt was denn noch in C++ fehlen koennte. :) Olaf
Phasenschieber schrieb: > Fast alle Sachen brauchen 10mal > so lange wie z.b. in C++. Als Anfänger vielleicht. So wie mit jeder neuen Programmiersprache auch, die neue und unbekannte Konzepte verwendet. Phasenschieber schrieb: > Greife auf eine Klassenvariable zu. Greife dann auf eine > andere zu. Geht schon nicht, weil `self` schon geborrowed > wurde. Selbst die einfachsten for-loops durch Container > kann man da vergessen. Das ist einfach nur falsch, so wie du es schreibst. Es sei denn du bringst ein Beispiel und wir das diskutieren. Natürlich kann man nacheinander(!) schreibend, oder gleichzeitig lesend auf Member zugreifen. Natürlich kann man sehr einfach über Container iterieren. Dazu gibt es sehr viele verschiedene Konzepte. So wie das halt in modernen Sprachen ist. Für jeden Geschmack was dabei. Phasenschieber schrieb: > In der Praxis sucht > man sich in der Doku kaputt wo das trait jetzt herkommt Traits muss man explizit importieren (use). Ohne use, auch keine zusätzlichen Trait-implementationen zu bereits bekannten Typen. Phasenschieber schrieb: > Aber hey, dafür haben wir keine > Speicherleaks mehr. Rust verhindert keine Speicherleaks. Phasenschieber schrieb: > Hmm. Aber die Datensicherheit und > das Owner Konzept! Oh, gibts in C++ auch. Hmm. In C++ ist es sehr viel umständlicher und sperriger zu nutzen. Wenn man es konsequent durchzieht, ist es daher in C++ deutlich mehr Aufwand. Und daher zieht es niemand konsequent durch.
mh schrieb: > Wo genau finde ich die Doku für rust 1.47? rustup component add rust-docs https://rust-lang.github.io/rustup/concepts/components.html Oder online für die neuste Version: https://www.rust-lang.org/learn
MaWin schrieb: > mh schrieb: >> Wo genau finde ich die Doku für rust 1.47? > > rustup component add rust-docs > > https://rust-lang.github.io/rustup/concepts/components.html > > Oder online für die neuste Version: > https://www.rust-lang.org/learn Also wenn ich die 1.47er Doku haben will, muss ich erst den Compiler in der richtigen Version installieren? Wenn ich vergleichen will, muss ich hin und her wechseln?
mh schrieb: > Wenn ich vergleichen will, muss ich hin und her wechseln? Nein. Wie schon mehrfach hier im Thread geschrieben wurde, sind die Compilerversionen rückwärtskompatibel. In der Doku des neusten Compilers sind also auch alle Elemente der Vorgängerversionen enthalten. Mit entsprechenden Versionstags ist gekennzeichnet, mit welcher Version welches Feature eingebaut wurde.
MaWin schrieb: > mh schrieb: >> Wenn ich vergleichen will, muss ich hin und her wechseln? > > Nein. Wie schon mehrfach hier im Thread geschrieben wurde, sind die > Compilerversionen rückwärtskompatibel. In der Doku des neusten Compilers > sind also auch alle Elemente der Vorgängerversionen enthalten. Mit > entsprechenden Versionstags ist gekennzeichnet, mit welcher Version > welches Feature eingebaut wurde. Das ist nicht das was ich gefragt habe ... Ich konnte in der Doku keine Versionstags finden, muss also alles seit der ersten Veröffentlichung unverändert sein. Allerdings konnte ich in der Doku selbst (https://doc.rust-lang.org/reference) auch keine Info finden, für welche Version diese Doku gilt.
mh schrieb: > Das ist nicht das was ich gefragt habe ... Und was hast du gefragt? > Ich konnte in der Doku keine Versionstags finden Aha. Dann solltest du vielleicht einmal genauer gucken. Beispiel: https://doc.rust-lang.org/std/primitive.u32.html#associatedconstant.MIN MIN gibt es seit 1.43.0
MaWin schrieb: > mh schrieb: >> Das ist nicht das was ich gefragt habe ... > > Und was hast du gefragt? Stand doch in dem Beitrag den du zitiert hast. mh schrieb: > Wenn ich vergleichen will, muss ich > hin und her wechseln? Du hast auf die nicht gestellte Frage "Möchte ich die verschiedenen vergleichen" geantwortet. MaWin schrieb: >> Ich konnte in der Doku keine Versionstags finden > > Aha. > Dann solltest du vielleicht einmal genauer gucken. > Beispiel: > https://doc.rust-lang.org/std/primitive.u32.html#associatedconstant.MIN > > MIN gibt es seit 1.43.0 Ok in die Doku des std-cargos habe ich nicht geguckt. Interessiert mich auch eher weniger, mir geht es um die Sprache.
mh schrieb: > Du hast auf die nicht gestellte Frage "Möchte ich die verschiedenen > vergleichen" geantwortet. Vielleicht sind die Changelogs da eher sinnvoll? Und warum willst du das überhaupt machen? Nutze halt die neuste stable-Version.
MaWin schrieb: > mh schrieb: >> Du hast auf die nicht gestellte Frage "Möchte ich die verschiedenen >> vergleichen" geantwortet. > > Vielleicht sind die Changelogs da eher sinnvoll? > > Und warum willst du das überhaupt machen? Nutze halt die neuste > stable-Version. er sucht eben was vergleichbares wie https://en.cppreference.com/w/cpp/language/static_assert wo man schön sehen kann welches Sprach-Feature wann aufgetaucht ist
Wen es interessiert: in der aktuellen iX beginnt eine Serie mit Tutorial zu Rust, ggf. wer es bezahlt hat (select) natürlich auch online,
cppbert schrieb: > er sucht eben was vergleichbares wie > > https://en.cppreference.com/w/cpp/language/static_assert > > wo man schön sehen kann welches Sprach-Feature wann aufgetaucht ist Ja gut. Das ist ja genau das, was ich gezeigt habe. In der std-Doku sind auch alle core-Elemente der Sprache enthalten. Das einzige, was dort in der Regel nicht steht, ist wenn neue abstrakte Konzepte eingeführt werden, die keinen direkten core-support brauchen. Wie z.B. const-generics.
MaWin schrieb: > Rust verhindert keine Speicherleaks. Du kannst welche provozieren wenn du sie unbedingt für deine Systemprogrammierung brauchst aber der normale Entwickler bekommt das Erstmal nicht hin, Rust verhindert alle Fehler die der ASAN findet, aber man kann Leaks erzeugen die der LSAN findet, nur eben nicht aus versehen Aber trotzdem kannst du nicht mit einem geleaktem Speicher arbeiten
Phasenschieber schrieb: > Aber hey, dafür haben wir keine > Speicherleaks mehr. Wie war das? Haben wir in C++ dank > RAII auch nie gehabt? Hmm. Aber die Datensicherheit und > das Owner Konzept! Oh, gibts in C++ auch. Hmm. D.h. die Aussage von google, Microsoft, Amazon, Facebook usw. darüber das sie den grossteil der Sicherheitsprobleme in der Systemprogrammierung nicht unter Kontrolle bekommen ist nur Hilflosigkeit weil deren Entwickler alle so schlecht sind? Speziell Google als Erfinder von ASAN etc. Würde ich da eindeutig mehr Verständnis zusprechen, Systemprogrammierung ist was anderes, Nutzeranzahl von Mio bis Mrd ist was anderes, ständige Angriffe sind was anderes - ich glaube vielen fehlen hier einfach die Dimensionen mit was solche Firmen zu kämpfen haben Der Satz der mir hier von jedem braucht-man-nicht-Kritiker immer fehlt ist: "Wenn ich bei google, Amazon und Microsoft das Zepter für die Android, AWS und Azure Entwicklung in den Händen hätte würden meine >10.0000 Entwickler dank fortschrittlicher C++ Entwicklung solche Fehler einfach nicht mehr machen, mein Business würde ohne Sicherheits-, Ressourcen und Wartungsprobleme laufen - meine 10-800 Mio Kunden wären immer Zufrieden"
Bei der Menge an Kunden, Systemen ist jede Verbesserung in Sicherheit und Wartung nur im einstelligen Prozentbereich schon direkt ordentlich Geld wert
Olaf schrieb: > Daher gibt es ein Interesse daran die Leute soviel wie moeglich zu > gaengeln. > Diese Sprachen kommen ja nicht mehr aus dem Interesse der Programmierer > ein Problem zu loesen, sondern aus dem Interesse einer Firma das ihre > Probleme > so preiswert wie moeglich geloest werden. auch wenn der Satz natürlich so absolut richtig ist schwingt aber immer so ein Hauch von nur-schlechte-Entwickler machen schlechten/fehlerhaften Code mit... Die Probleme bei den Grossen sind real und in jahren harter Arbeit konnte man diese nicht signifikant Richtung 0 bringen, Rust versucht, und scheint es als Sprache auch erstmals in der Systemprogrammierung zu schaffen eine deutlichere Verbesserung out-of-the-box zu ermöglichen, ganz unabhängig von logischen Fehlern
Versucht doch einfach mal ein erstes Projekt mit Rust umzusetzen. Damit meine ich jetzt ein Hallo World, sondern ein größeres Projekt, was tatsächlich was tut. Ihr werdet ganz schnell furchtbar frustriert sein, weil Rust euch ständig mit Compilerfehlern bewirft. Das ist die erste Erkenntnis, die ihr haben werdet. Rust ist nur wenig geeignet, um mal schnell etwas hinzufrickeln. Man muss sich Gedanken machen über das, was man schreibt. Macht man es nicht, wird man umgehend vom Compiler dafür bestraft. Wenn man diese Phase überstanden hat, kommt allerdings die zweite Phase, in der man die Vorteile dieses Vorgehens erkennt. Es gibt den Spruch: If it compiles, then it works. Das ist natürlich nicht wörtlich zu nehmen. Selbstverständlich kann man in Rust auch algorithmische Fehler machen. Aber eine ganze Menge an Fehlern, die man in anderen Sprachen wie C oder gar Python erst zur Laufzeit erkennt (wenn man Glück hat), quittiert der Rustcompiler einem mit einem Fehler. Insofern hat man eine ganze Menge der Debuggingarbeit in die Phase der Programmierung verschoben. Und das ist eine gute Sache.
MaWin schrieb: > Ihr werdet ganz schnell furchtbar frustriert sein, weil Rust euch > ständig mit Compilerfehlern bewirft. ... > > Wenn man diese Phase überstanden hat, kommt allerdings die zweite Phase, > in der man die Vorteile dieses Vorgehens erkennt. Es gibt den Spruch: If > it compiles, then it works. Das kenne ich verstärkt (sowohl in negativer als auch in positiver Hinsicht) auch von Haskell. Das funktionale Programmierparadigma und das äußerst strenge Typsystem sorgen dort dafür, dass sehr viele Sorten von logischen Fehlern in Typfehler münden und damit zur Compilezeit erkannt werden. Leider eignet sich Haskell nicht gut für die systemnahe Programmierung. Unter den Universalsprachen, die von hardwarenah bis völlig abgehoben alles abdecken, ist deswegen Rust IMHO der mit Abstand beste Kompromiss, den es derzeit gibt.
MaWin schrieb: > Man muss sich Gedanken machen über das, was man schreibt. > Macht man es nicht, wird man umgehend vom Compiler dafür bestraft. Gedanken darüber, was man schreibt, oder Gedanken darüber, wie man es in Rust schreibt? Ich kann genau wissen, wie ich etwas idealerweise umsetzen würde, welche Datenstruktur und Algorithmen ich verwenden will. In C, Python, Java, GO, etc., selbst in anderen Imperativen und/oder OOP sprachen die ich eigentlich noch gar nicht kenne kann ich das dann einfach so hin schreiben. Aber nicht in Rust, gewisse Sachen muss man da einfach anders machen, und zwar nicht, weil es falsch oder besser wäre (von Aussen betrachtet), sondern einfach nur, weil es so nicht geht. Aber natürlich ist die Datenstruktur und der Algorithmus dann völlig verrückt, macht man einfach so nicht, oder? Als Beispiel, führe ich einfach mal die völlig verrückte Datenstruktur einer linked list an. Ja, ich weiss, total verrückt, sowas zu benutzen, so ineffizient, so kompliziert, wer der noch bei Verstand ist würde denn sowas machen? Aber lasse ich doch das einfach mal die Rust läute selbst erklären: https://rust-unofficial.github.io/too-many-lists/ Mittlerweile gibt es LinkedLists zum Glück aber in der Standard Library. Wurde auch sehr elegant gelöst. Jede Funktion nutzt einfach "unsafe". (Das ist aber auch die einzig vernünftige Lösung.) https://doc.rust-lang.org/src/alloc/collections/linked_list.rs.html
Daniel A. schrieb: > MaWin schrieb: >> Man muss sich Gedanken machen über das, was man schreibt. >> Macht man es nicht, wird man umgehend vom Compiler dafür bestraft. > > Gedanken darüber, was man schreibt, oder Gedanken darüber, wie man es in > Rust schreibt? Beides natürlich. Wie in jeder Sprache. > Ich kann genau wissen, wie ich etwas idealerweise umsetzen würde, welche > Datenstruktur und Algorithmen ich verwenden will. In C, Python, Java, > GO, etc., selbst in anderen Imperativen und/oder OOP sprachen die ich > eigentlich noch gar nicht kenne kann ich das dann einfach so hin > schreiben. Aber nicht in Rust, gewisse Sachen muss man da einfach anders > machen, und zwar nicht, weil es falsch oder besser wäre (von Aussen > betrachtet), sondern einfach nur, weil es so nicht geht. Aber natürlich > ist die Datenstruktur und der Algorithmus dann völlig verrückt, macht > man einfach so nicht, oder? In C kann man vieles implementieren, indem man wild mit Pointern um sich wirft. Und es resultiert regelmäßig in use-after-free oder ähnlichen Bugs. Man sollte sich in allen Sprachen Gedanken darüber machen, wie man einen Algorithmus möglichst safe implementiert. Rust zwingt den Entwickler dazu. C nicht. Das bedeutet zwangsläufig, dass man in Safe-Rust nicht alles machen kann, was in C geht. Und das ist natürlich auch so gewollt. Für die Fälle, die in Safe-Rust nicht direkt oder nur ineffizient lösbar sind, gibt es Abstraktionen in der std library, die dann intern Unsafe-Rust nutzen. > Mittlerweile gibt es LinkedLists zum Glück aber in der Standard Library. > Wurde auch sehr elegant gelöst. Jede Funktion nutzt einfach "unsafe". > (Das ist aber auch die einzig vernünftige Lösung.) > https://doc.rust-lang.org/src/alloc/collections/linked_list.rs.html Na dann ist doch alles gut, wenn die std library das Problem für dich gelöst hat, sodass du in deinem Code alles als safe-Rust schreiben kannst. Man kann eine linked-list selbstverständlich auch ohne die std linked list in safe rust schreiben. Man nehme Rc, RefCell und Box. Wie das genau geht, kannst du im offiziellen Rust-Buch nachlesen. Aber da das nicht ganz so effizient ist, wie eine dedizierte linked-list, gibt es eben die optimierte std-liste.
Daniel A. schrieb: > Als Beispiel, führe ich einfach mal die völlig verrückte Datenstruktur > einer linked list an. es ist sehr schwer die Offenheit von C/C++ oder gar Assembler in sichere(re) Konstrukte zu überführen - aber mal ehrlich, wer von uns schreibt denn ständig effiziente Link-Lists oder Graphen-Strukturen - machen tun wir das schon hin und wieder aber das als Messlatte heran zu ziehen ist doch nicht wirklich intelligent, oder denkst du das wirklich? Hast du gar das Gefühl den Entwicklern wäre das nicht ab der 1. Idee zum Ownershipping klar gewesen? das wurde so bewusst in kauf genommen nur bei Selbst-Referenzen und Offenen-Referenzen hat Rust - bisher noch :) -Probleme das "elegant" zu lösen - dafür die ganze Sicherheit die geboten wird komplett über Bord zu werfen würde ich als fraglich bezeichnen Die Spiel heisst nicht Nur-Vorteile-sonst-ebene-wieder-die-alte-Sprache
Daniel A. schrieb: > Als Beispiel, führe ich einfach mal die völlig verrückte Datenstruktur > einer linked list an. Ja, ich weiss, total verrückt, sowas zu benutzen, > so ineffizient, so kompliziert, wer der noch bei Verstand ist würde denn > sowas machen? niemand auf der Welt, mit Erfahrung denkt das, jede Verwaltungsform hat ihre Vor- und Nachteile Wie kommst du darauf das die Rust-Entwickler so was einfach vernachlässigen - sie haben sich eben so entschieden so das der 90% Fall sicher ist Falls du eine gute Idee hast wie man das fehlende Konzept für Link-Listen "sauber" in ein Ownership-Model bekommt - ohne das daraus ein GC wird - oder kein Ownership-Model existiert kannst du gerne Vorsprechen, dir sei Ruhm und Ehre gewiss :)
MaWin schrieb: > Man sollte sich in allen Sprachen Gedanken darüber machen, wie man einen > Algorithmus möglichst safe implementiert. > Rust zwingt den Entwickler dazu. C nicht. Blödsinn. Das ist C: - Trust the programmer - Don’t prevent the programmer from doing what needs to be done Für Rust sind die Entwickler anscheinend alle doof und man muss denen bestimmte Werkzeuge wegnehmen und ihnen regelmäßig auf die Finger hauen. Eine tolle Einstellung. Nach dieser Logik sollte man in einer Werkstatt alle Wekrzeuge durch Wattebällchen ersetzen. Damit da nichts passiert. Die schöne neue Zeit.
Yalu X. schrieb: > beste Kompromiss, > den es derzeit gibt. Aha, also wieder nur ein Kompromiss und nur für "derzeit". In ein paar Jahren brauchen wir dann eine neue Programmiersprache, die wieder alles besser macht? Und gerade bei systemnaher Programmierung? Hat dann Linux-Kernel 30 Million LOC geschrieben in C, 5 Million LOC in Rust, 5 Millionen LOC in XYZ, usw.?
von snowflakes - für snowflakes schrieb: > Für Rust sind die Entwickler anscheinend alle doof und man muss denen > bestimmte Werkzeuge wegnehmen und ihnen regelmäßig auf die Finger hauen. Ich finde Restriktionen von Seiten der Programmiersprache völlig in Ordnung, wenn sie mir dabei helfen, zuverlässigeren Code zu schreiben und den Debug-Aufwand zu reduzieren. Das ist ähnlich wie im Straßenverkehr: Ich halte mich dort gerne an das Rechtsfahrgebot. Es schränkt mich zwar in meiner Freiheit etwas ein, dafür kommt es nicht ständig zum Crash, weil mir ein anderes Fahrzeug auf meiner Fahrspur entgegenkommt. Falls ich dennoch einmal unabsichtlich als Geisterfahrer unterwegs sein sollte, fände ich es völlig in Ordnung, wenn mich die Polizei anhält und mich auf meinen Regelverstoß hinweist.
von snowflakes - für snowflakes schrieb: > Aha, also wieder nur ein Kompromiss und nur für "derzeit". Die Welt besteht nun einmal aus Kompromissen, denn die absolute Perfektion gibt es in der Realität nirgends. Und wer weiß, vielleicht hält dieser derzeitige Kompromiss bis an unser beider Lebensende und darüber hinaus.
:
Bearbeitet durch Moderator
von snowflakes - für snowflakes schrieb: > Für Rust sind die Entwickler anscheinend alle doof und man muss denen > bestimmte Werkzeuge wegnehmen und ihnen regelmäßig auf die Finger hauen. > Eine tolle Einstellung. Was ist das Problem an der Einstellung wenn dabei automatisch sicherere Programme entstehen Und die Grossen der Branche wechseln von ihreren eigenen Strategie in der Systemprogrammierung auch nur zu Rust weil denen so langweilig ist und nur die schlechten Entwickler dort arbeiten? Kann einer von euch hat mal schlüssig erklärt warum so viele der grossen Rust als die Lösung ihrer Lowlevel Probleme sehen und nur von euch keiner? Google entwickelt den ASAN der mittlerweile Standart ist, riesige Fuzzyfarmen und und und und sagen trotzdem das reicht nicht, ihr aber schon Ich finde Rust nicht interessant weil ich in den letzten 30 Jahren so unter C/C++ gelitten habe, dafür habe ich viel zu viel Code für allerlei Kunden und Projekte entwickelt, aber ich sehe viele Kernprobleme behandelt, als jüngling oder zu alter Entwickler verstehe ich eine gewissen Zurückhaltung, aber viele der Argumente hier gegen Rust sind so schwach das es schon auffällig ist, was ich schade finde weil C/C++ keiner Verteidigung bedarf, es wird ewiglich überdauern
von snowflakes - für snowflakes schrieb: > Und gerade bei systemnaher Programmierung? Hat dann Linux-Kernel 30 > Million LOC geschrieben in C, 5 Million LOC in Rust, 5 Millionen LOC in > XYZ, usw.? wenn die Kernelentwickler Rust in den Kernel einziehen lassen würde, trotz all der Mängel, was würde das über die Kernelentwickler und ihre Fähigkeiten und bisherigen Code aussagen? Wieder so ein schwaches Argument weil das Szenario mit XYZ eh niemals eintreten wird, warum sowas überhaupt posten?
Yalu X. schrieb: > von snowflakes - für snowflakes schrieb: >> Für Rust sind die Entwickler anscheinend alle doof und man muss denen >> bestimmte Werkzeuge wegnehmen und ihnen regelmäßig auf die Finger hauen. > > Ich finde Restriktionen von Seiten der Programmiersprache völlig in > Ordnung, wenn sie mir dabei helfen, zuverlässigeren Code zu schreiben > und den Debug-Aufwand zu reduzieren. > > Das ist ähnlich wie im Straßenverkehr: > > Ich halte mich dort gerne an das Rechtsfahrgebot. Es schränkt mich zwar > in meiner Freiheit etwas ein, dafür kommt es nicht ständig zum Crash, > weil mir ein anderes Fahrzeug auf meiner Fahrspur entgegenkommt. Das klingt aber eher nach C - du hast es unter Kontrolle und hältst dich an die Regel, weil sie sinnvoll ist. Dennoch kannst du z.B. zum Überholen oder zum Ausweichen auch mal nach links fahren. Rust wäre, wenn das Auto dir das Lenkrad blockiert, wenn du versuchst, auf die linke Spur zu fahren.
von snowflakes - für snowflakes schrieb: > Aha, also wieder nur ein Kompromiss und nur für "derzeit". > > In ein paar Jahren brauchen wir dann eine neue Programmiersprache, die > wieder alles besser macht? Es nennt sich Weiterentwicklung. > Und gerade bei systemnaher Programmierung? Hat dann Linux-Kernel 30 > Million LOC geschrieben in C, 5 Million LOC in Rust, 5 Millionen LOC in > XYZ, usw.? Wo wäre das Problem? Du tust gerade so, als stünden wir vor der Inflation der Programmiersprachen. von snowflakes - für snowflakes schrieb: > Das ist C: > - Trust the programmer > - Don’t prevent the programmer from doing what needs to be done Du hast noch was vergessen: - Don't prevent the programmer from doing absolutely dumb things that would never work. - Don't prevent the programmer from writing unsound code. - Don't prevent the programmer from introducing subtle and hard to debug race conditions. - Don't prevent the programmer from corrupting the memory.
Rolf M. schrieb: > Rust wäre, > wenn das Auto dir das Lenkrad blockiert, wenn du versuchst, auf die > linke Spur zu fahren. ... und wenn du doch unbedingt auf der falschen Spur fahren willst, kannst du das mit unsafe eindeutig kennzeichnen.
Rolf M. schrieb: > Das klingt aber eher nach C - du hast es unter Kontrolle und hältst dich > an die Regel, weil sie sinnvoll ist. Dennoch kannst du z.B. zum > Überholen oder zum Ausweichen auch mal nach links fahren. Rust wäre, > wenn das Auto dir das Lenkrad blockiert, wenn du versuchst, auf die > linke Spur zu fahren. Sind eingreifende Sicherungssysteme moderner Flugzeuge wie die Flight-Envelope-Protection ein Fort- oder Rückschritt? (dort gibt es so Rust-mäßig "unsafe"-Modi)
Jemand schrieb: > Sind eingreifende Sicherungssysteme moderner Flugzeuge wie die > Flight-Envelope-Protection ein Fort- oder Rückschritt? (dort gibt es so > Rust-mäßig "unsafe"-Modi) Ich halte die Auto- und Flugzeugvergleiche hier für völlig daneben. Die wichtigsten und meisten Rust-Merkmale sind Compiletime-Checks. Das wäre in etwa so, als würdest du vor dem Start beweisen, dass es im folgenden Flug nicht zu sicherheitskritischen Manövern kommen kann. Das ist natürlich bei Flugzeugen unmöglich und deshalb ist der Vergleich Unsinn.
MaWin schrieb: > Man kann eine linked-list selbstverständlich auch ohne die std linked > list in safe rust schreiben. Man nehme Rc, RefCell und Box. Wie das > genau geht, kannst du im offiziellen Rust-Buch nachlesen. > Aber da das nicht ganz so effizient ist, wie eine dedizierte > linked-list, gibt es eben die optimierte std-liste. Ja, es ist nicht ganz so schlimm, wie ich es darstelle. Das Owner Konzept ist eigentlich schon eine tolle Sache, aber es nervt mit der Zeit halt schon etwas, das ständige Hantieren mit Rc, RefCell, Box, etc. bis es geht. Da frage ich mich einfach, hätte man das wirklich nicht einfacher/besser lösen können?
Daniel A. schrieb: > Zeit halt schon etwas, das ständige Hantieren mit Rc, RefCell, Box, etc. > bis es geht. Da frage ich mich einfach, hätte man das wirklich nicht > einfacher/besser lösen können? Naja. Rc ist bereits ein Smart Pointer und damit praktisch transparent. Nur halt nicht bei der Deklaration. Man kann jetzt natürlich diverse Typen in einem eigenen neuen Typ kombinieren. Aber ich sehe da den Vorteil jetzt nicht wirklich. Das skaliert nicht so richtig.
Daniel A. schrieb: > Da frage ich mich einfach, hätte man das wirklich nicht einfacher/besser > lösen können? Nicht wirklich, das Ownership Model ist ja auch keine neue Idee, nur die Art der Integration in Rust Für Linklisten oder Graphen braucht man ein Nullable Konzept, das gibt es schon sehr langen in x Sprachen, aber es ist schwierig bis unmöglich das zur Kompilezeit sauber zu lösen/prüfen (eher ein mathematisches Problem), die functionalen Sprachen machen das sauber aber die sind leider nicht so praktisch Wenn du dir als Rust die Einschränkungen: Kompilezeitchecks und Lückenlosigkeit auferlegst wird es sehr schwierig aber sie haben eine gute mitte zwischen mathematischer Beweisbarkeit und noch praktischer Anwendbarkeit geschaffen, vielleicht schaffen sie auch noch diese Hürde
MaWin schrieb: > https://security.googleblog.com/2021/04/rust-in-linux-kernel.html Ganz unten auf der Seite ... Thanks Nick Desaulniers, Kees Cook, and Adrian Taylor for contributions to this post. Special thanks to Jeff Vander Stoep for contributions and editing, and to Greg Kroah-Hartman for reviewing and contributing to the code examples. ... Greg Kroah-Hartman hat sich also auch schon ein wenig intensiver damit beschäftig, wer ihn nicht kennt: das ist der 2. Man nach Linus Torvalds in der Kernelentwickler Befehlskette
Facebook ist jetzt auch in der Rust Foundation https://engineering.fb.com/2021/04/29/developer-tools/rust/ Laut dem Artikel arbeiten bei Facebook bis zu 100 Entwickler mit Rust Und nein, ich habe kein Facebook Account, Facebook als Firma ist aber trotzdem, technisch gesehen eine extreme Datenverarbeutungsmaschinerie mit sehr viel C++ und auch scheinbar nicht unbedeutende Menge an Rust dahinter, die wenigsten Leute bei denen machen HTML, js und PHP, die Zeiten sind schon lange vorbei
Vom neuen Facebook Rust Mitglied ;) "...And, seriously, if the Linux kernel is actually starting to even consider Rust as a language to be used for that codebase, well, that’s when you know you have made it. ..."
cppbert3 schrieb: > "...And, seriously, if the Linux kernel is actually starting to even > consider Rust as a language to be used for that codebase, well, that’s > when you know you have made it. ..." Da ist was dran. C++ ist an dieser Hürde mehrfach gescheitert. Gut, das ist nicht ganz vergleichbar, weil es dort darum ging den gesamten C-Code mit einem C++ Compiler zu übersetzen. Dennoch sind die Linux-Entwickler nicht bekannt dafür auf Hypetrains aufzuspringen. Das ist die Grundlage für die Aussage.
Moin, Mal wieder ein unqualifizierter rant: Bei BLFS-11 ist derweilen ein rustc in Version 1.52 hip. Der hat aber scheints immernoch den selben shice in miri, wie schon vor mindestens 16 Monaten hier: Beitrag "Re: Rust - ist das hier um zu bleiben?" beschrieben. Also in fast 1.5 Jahren weder repariert noch rausgeflogen. Kann man natuerlich machen, wird nicht wichtig sein, aber sieht halt doch irgendwie kacke aus, find' ich. Aber was weiss ich schon. Beim firefox bauen brauchts, scheint's auch seit geraumer Zeit einen patch, weil da manchmal was schief geht. Das hoert sich richtig ermunternd an: [quote=patch]This is an old patch from Arch, they build with clang and lto and have apparently needed this in the past. On two of my systems (one from May 21 and one of my BLFS-10.0 systems) firefox-91.0esr FTBFS with a message that a python check on libgkrust.a identified one networking function, getsockname, in the rust static library. The reason why this is now giving a problem, but only on some systems, is not understood, but this seems to stop it.[/quote] aye caramba! hat aber sicher nix mit rust zu tun. Gaaaanz sicher nicht... [quote=BLFS-11_Book]...and particularly because newer versions tend to break older mozilla packages, the BLFS editors take the view that it should only be updated when that is necessary[/quote] Wuzz? Hab' ich hier nicht noch vor ein paar Monaten erklaert bekommen, dass das garnicht sein kann, weil der neueste rust-compiler immer der geilste ist und zu allen aelteren kompatibel? Kanns kaum erwarten, bisses endlich auch im Kernel ist. Gruss WK
Moin, Haha! Kannste dir nicht ausdenken, sowas: Ich will mal wieder - jetzt eben mit dem rust-1.52 - aus BLFS-11 (und damit auch erfolgreich firefox (auf dem scheib ich grad dieses Pamphlet), thunderbird, librsvg,... gebaut) den rav1e bauen. Nehm' ich halt mal's letzte "release" p20211207 her. Boah: ein
1 | cargo build --release |
laeuft tatsaechlich durch. Ohne Mecker. Sollte ich tatsaechlich ungerechtfertigt zu miesepetrig druff sein? Jetzt noch gschwind die c-api anflanschen, damit der Rest der (C-)Welt auch was von dem schicken Encoder hat:
1 | root [ /usr/src/rav1e-p20211207 ]# cargo install cargo-c |
2 | Updating crates.io index |
3 | Downloaded cargo-c v0.9.5+cargo-0.57 |
4 | error: failed to parse manifest at `/root/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-c-0.9.5+cargo-0.57/Cargo.toml` |
5 | |
6 | Caused by: |
7 | feature `edition2021` is required |
8 | |
9 | this Cargo does not support nightly features, but if you |
10 | switch to nightly channel you can add |
11 | `cargo-features = ["edition2021"]` to enable this feature |
Ist das geil? Ich brauche also dringend das wichtige Feature "edition2021"? rly? Bloss gut, dass das ja nix mit rust zu tun hat und das man ja auch nicht gezwungen ist, cargo herzunehmen. Kann irgendwer mal anfangen, diese wildgewordenen Informatiker ein bisschen zu erden? Ja, ich weiss - niemand (ausser meiner eigenen Inkompetenz) haelt mich davon ab, mir einen noch viel geileren AV1 Encoder in der Sprache und mit dem Buildsystem meiner Wahl selbst zu programmieren. Schon klar. SCNR; WK
Meine Meinung zu Rust ist, dass die Entwickler von Rust anscheinend noch nie für Linux ein Paket gebaut haben. Es ist lächerlich, dass man erst nach langer Zeit mit Cargo offline bauen konnte. Und auch sehr lächerlich, dass es weiterhin alle Pakete in ein Offline-Repo zieht. Wenn man ein Paket für eine Linuxdistribution baut, will man in der Regel nur Pakete aus den eigenen Repos benutzen. Z.B. weil man sie auf Sicherheit geprüft hat. Crate.io traue ich nicht. Man hat ja bereits beim npm-Angriff gesehen, dass diese Spracheneigenen Repositories anfälliger für eine Supply-Chain-Attacke sind. Es sind bei solchen Projekten dem Anschein nach eher Sprach-Fanatiker dabei, die sich mehr um die "Coolness" ihrer Programmiersprache als um Supply-Chain-Sicherheit kümmern... Ein weiterer Punkt ist die massive Rekursionstiefe beim Bauen vom Rust Compiler package rustc: Entweder man schreibt einmal alles in einem Sublayer, quasi einen elementaren Baukasten von Rust-Befehlen, mit denen man dann einfach-rekursiv den Standard-namespace schreibt, oder man lässt es bleiben. Rust wirkt sprachlich, wie von hellen Köpfen entwickelt, aber die Kompiler-Entwickler scheinen noch nie von Idempotenz und Performance gehört zu haben, jedenfalls im Bezug auf das Compilerprojekt selbst.
Almdahl schrieb: > Supply-Chain-Attacke Wie soll das denn vonstattengehen, wenn das Distributionspaket die Dependency-Versionen pinnt (locked)? Almdahl schrieb: > Ein weiterer Punkt ist die massive Rekursionstiefe beim Bauen vom Rust > Compiler package rustc Tut mir leid. Das verstehe ich nicht. Kannst du das Problem vielleicht auch in verständlich erklären? Almdahl schrieb: > Es ist lächerlich, dass man erst nach langer Zeit mit Cargo offline > bauen konnte. Und auch sehr lächerlich, dass es weiterhin alle Pakete in > ein Offline-Repo zieht. Es ist also lächerlich, dass die Pakete online sind und gleichzeitig ist es lächerlich, dass die Pakete offline gecached werden? Verstehe ich deine Kritik richtig? Wie hättest du es denn gerne?
MaWin schrieb: > Almdahl schrieb: >> Supply-Chain-Attacke > Wie soll das denn vonstattengehen, wenn das Distributionspaket die > Dependency-Versionen pinnt (locked)? Ich meine nicht, dass es eine Supply-Chain-Attacke auf die Distribution geben kann, sondern eine in der programmierspracheneigenen Paketverwaltung. Ist meine Persönliche Meinung, aber ich finde es nervig, dass für Sprachen wie Rust, Python, Ruby usw. das Rad immer wieder neu erfunden wurde. Dass man die Crates auch mit Cargo laden kann, ist trotzdem nicht das eigentliche Problem. Man hat nur das Gefühl, dass alles darauf ausgelegt ist, dass man die Rust-Art benutzt, Dinge zu kompilieren und dass es beim Paketbau für Distributionen unangenehm wird. > Almdahl schrieb: >> Ein weiterer Punkt ist die massive Rekursionstiefe beim Bauen vom Rust >> Compiler package rustc > > Tut mir leid. Das verstehe ich nicht. > Kannst du das Problem vielleicht auch in verständlich erklären? Das Problem ist, dass jede neue rustc-Version davon ausgeht, dass der in der vorhergehenden stabilen rustc-Version definierte Namensraum zur Verfügung steht. Das bedeutet, man braucht immer die vorherige Version, um die nächste zu kompilieren. Wenn man ein Paket baut und beweisen möchte, dass der Binärcode dem Quelltext entspricht, muss man in jedem Update von vorne wieder jede einzelne Version von rustc bauen, oder zu jeder Zeit alle Versionen von rustc bereit halten (um den rekursiven Beweis aufrecht zu erhalten) die zum Bau von aktualisierten rustc-Paketen benötigt werden. Das finde ich technisch richtig dumm umgesetzt. Das macht auch die Programme zum Bereitstellen der Repositories komplexer als nötig. Ein paar Leute haben das mittlerweile entschärft, indem sie einen alternativen Compiler in C++ geschrieben haben (mrustc), der einige Schritte vereint. Trotzdem ist die Kompilierung bis zur aktuellsten Version mit einem immensen Ressourcen- und Zeitaufwand verbunden. Das ist Mist. Man sollte sich auf sehr wenige Stufen einigen, auf denen dann die neuen Versionen basieren. > Almdahl schrieb: > Es ist also lächerlich, dass die Pakete online sind und gleichzeitig ist > es lächerlich, dass die Pakete offline gecached werden? > Wie hättest du es denn gerne? Sorry für die missverständliche Ausdrucksweise - Ich hatte selbst etwas falsch in Erinnerung. Was ich kritisieren möchte ist die Möglichkeit, z.B. Patches von Github on the Fly beim Kompilieren über das Cargo.toml File zu laden und bei Dependencies auf git Links zu verweisen. Natürlich kann man sagen, dass man das nicht nutzen muss, aber ich finde, dass man manche Möglichkeiten auch nicht bieten muss. Denn zum Bau des Paketes hat man somit implizit doch wieder online Dependencies, wodurch der --offline-Modus nicht geht. Man muss als Paketbauer also zuerst alles manuell laden und das Cargo.toml patchen, damit man es offline bauen kann. Hätte der Programmierer die Möglichkeit nicht, hätte er die Sache auch "anständig" gelöst. Ganz ehrlich: Ich wollte gerne ein cooles Rust-Paket für eine Distribution bauen, aber der letztgenannte Punkt verdirbt einem dann einfach den Spaß und man wünscht sich ein gutes altes Makefile. Insgesamt bin ich dem Bau von Rust-Paketen mittlerweile eher abgeneigt. Und ein letzter Punkt: Wenn ich eine Programmiersprache benutze, will ich, dass sie sehr lange stabil ist. C99 war nicht umsonst sehr erfolgreich. Man konnte sich einfach darauf verlassen. Ich hoffe sehr, dass es auch mal einen Rust-Standard gibt, der 15-20 Jahre durchhält.
Almdahl schrieb: > oder zu jeder Zeit alle Versionen von rustc bereit halten Was ja kein Problem darstellen sollte. > Ein paar Leute haben das mittlerweile entschärft, indem sie einen > alternativen Compiler in C++ geschrieben haben (mrustc) Na siehste. Das Problem ist also praktisch gelöst. Rust für GCC wird es auch bald geben. Vermutlich nächstes Jahr. > Natürlich kann man sagen, dass man das nicht nutzen muss Genau. Deshalb ist es auch kein Problem. > Und ein letzter Punkt: Wenn ich eine Programmiersprache benutze, will > ich, dass sie sehr lange stabil ist. Das ist meiner Erfahrung nach bei Rust auch so. Deine Schilderungen zu BLFS und FF kann ich nicht kommentieren, da ich das nicht ausprobiert habe und die Hindergründe nicht kenne. In meiner Erfahrung gab es aber noch nie ein Paket, dass nach einem Compilerupdate nicht mehr funktioniert hätte. Und ich denke da bin ich nicht alleine mit.
MaWin schrieb: > Almdahl schrieb: >> oder zu jeder Zeit alle Versionen von rustc bereit halten > > Was ja kein Problem darstellen sollte. Für ein mickriges Paket ist der Ressourcenverbrauch extrem. >> Ein paar Leute haben das mittlerweile entschärft, indem sie einen >> alternativen Compiler in C++ geschrieben haben (mrustc) > > Na siehste. Das Problem ist also praktisch gelöst. Nicht wirklich... > Rust für GCC wird es auch bald geben. Vermutlich nächstes Jahr. Dann wäre es eventuell tatsächlich gelöst. Aber bis das stabil ist, werden ja sicherlich auch wieder Jahre ins Land gehen... Schade, dass es nicht früher umgesetzt wurde. >> Natürlich kann man sagen, dass man das nicht nutzen muss > > Genau. > Deshalb ist es auch kein Problem. Ich finde es schon problematisch, wenn viele unwissend Code schreiben, der auf Github vergammelt, weil keiner ihn packagen will. Und das wird durch die Möglichkeiten, die Cargo bietet, eben zum Teil gefördert.
Almdahl schrieb: > Für ein mickriges Paket ist der Ressourcenverbrauch extrem. Im Zeitalter von Terabytefestplatten? Zudem man das ja nicht für jedes Paket machen muss, sondern maximal ein mal pro Distribution. Ich glaube du konstruierst dir da wirklich zwanghaft deine Probleme. > Schade, dass es nicht früher umgesetzt wurde. Rust ist nach wie vor eine sehr junge Sprache, die sich rasant weiterentwickelt und dabei produktiv einsetzbar und rückwärtskompatibel bleibt. Rust is here to stay. Egal wie viel so mancher sich dagegen sträubt. Wenn es Probleme beim Distri-Packaging mit Rust gibt, dann ist es die Aufgabe der Distris das zu lösen. Wenn sie es nicht lösen, dann werden sie abgehängt werden. Die Rustwelle rollt auch ohne die Hilfe von Linux-Distributionen. > wenn viele unwissend Ja, es ist problematisch, wenn Leute keine Ahnung von dem haben, was sie tun. Mit Rust hat das allerdings nichts zu tun.
MaWin schrieb: >> Für ein mickriges Paket ist der Ressourcenverbrauch extrem. > Im Zeitalter von Terabytefestplatten? Auch im Zeitalter von Terabyte-Storage und Gigabyte-Speicher ist nicht jedes Problem mit der Nutzung sämtlichen zur Verfügung stehenden Stauraums gut gelöst. > Rust ist nach wie vor eine sehr junge Sprache, die sich rasant > weiterentwickelt und dabei produktiv einsetzbar und > rückwärtskompatibel bleibt. Mal schauen. Die Sprache mag ja gut sein, der Lernaufwand ist verglichen mit anderen modernen Sprachen aber enorm - und das Tooling je nach Sichtweise entweder eine Katastrophe (wenn man C/embedded kennt) oder der Wunschtraum der agilen Welt (wenn man JS/web kennt). C ist vor allem deswegen noch aktuell, weil man dafür nicht nur relativ einfach Compiler entwickeln kann (was für C++ nicht der Fall ist), sondern auch weil es in sich langfristig stabil war und ist. Der Rust-Ansatz ist eher vom Format "wir liefern auch den alten Compiler mit". Da das Ökosystem aber auch Dependencies aufbaue und diese natürlich die neuen Features wollen, ist der praktische Nutzen sehr begrenzt. Wenn die Kompatiblität tatsächlich gebrochen werden sollte, dann kann das in einer Python 2.x/3.x-Situation münden. Alles nicht ganz einfach. Mal schauen, was der Linux-Ansatz bringt - denn Linus wird ganz sicher keine Abhängigkeit zu Web-Services oder Paketmanagern reinbringen. Almdahl schrieb: > Meine Meinung zu Rust ist, dass die Entwickler von Rust > anscheinend noch nie für Linux ein Paket gebaut haben. Müssen sie auch nicht. Heutzutage schreit man Docker, Snap und so.
S. R. schrieb: > Wenn die Kompatiblität tatsächlich gebrochen werden sollte, > dann kann das in einer Python 2.x/3.x-Situation münden. Warum glaubst du, dass das auch tatsächlich passieren kann? Mit den Editions hat man einen wirksamen Mechanismus, um auch größere Umbauten vollständig rückwärtskompatibel durchzuführen. Python hingegen hat keinen solchen Mechanismus. Genau deshalb ist Python viel schlechter aufgestellt, was die Rückwärtskompatibilität angeht. Und das endet dann in Sachen wie der 2/3-Transition, aber auch in konstant eingeführten kleinen Inkompatibilitäten in so gut wie jeder neuen Version. > denn Linus wird ganz sicher > keine Abhängigkeit zu Web-Services oder Paketmanagern reinbringen. Ist auch gar nicht notwendig. Wie hier schon mehrfach erklärt wurde. Alle nötigen dependencies können lokal vorgehalten werden. Mit und ohne cargo. > Die Sprache mag ja gut sein, der Lernaufwand ist verglichen > mit anderen modernen Sprachen aber enorm Verglichen mit welchen Spachen? > und das Tooling je nach Sichtweise entweder eine Katastrophe Warum? Gerade weil die Rust Toolchain alles mitbringt, was man eh braucht, ist es extrem einfach zu verwenden.
Ich fasse es mal ehrlich zusammen: Wenn Rust22 gäbe, und dies mit GCC mit kompetitiver Performance kompilierbar wäre, würde ich nicht nur C, sondern auch viel Python, damit sofort ersetzen. Einfach, weil Rust das Zeug dazu hat, dies aus Sprachperspektive und Library-Support zu leisten. Solange die gravierenden Kritikpunkte (aus meiner Sicht) bleiben, betrachte ich Rust weiter wehmütig, als Sprache, die ich gern einsetzen würde, aber es aus Vernunftgründen noch nicht kann. Und zu Containern habe ich eine etwas kontroverse Meinung :).
Was sind Eure Rust Anwendungen und Targets? Redet man hier hauptsächlich von Embedded oder PCs und Co.? Im embedded Bereich gibt es da schon fertige Tools für bestimmte uC und wie verläßlich sind diese Tools? Wie leicht ist Umportierung von C/C++ auf Rust und wie leicht kommt man mit Rust an die uC HW ran? Wie steht es mit äquivalenten Bibliotheken? Wie geht das Debugging von embedded Projekte am Besten mit Rust? Wie schwierig ist die Konfigurierung im Vergleich zu altbekannten Werkzeugen? Wie schwer tut man sich wenn z.B. der Chef man möchte doch z.B. von STM32 oder PIC/AVR auf ein Rust Entwicklungssystem umzusteigen? Wird PIC/AVR unterstützt? Gibt es Case Studies wie man ein existierendes erfolgreiches embedded Projekt (STM32/AVR/PIC) von C/C++ auf Rust umsetzt und erfolgreich baut und betreibt? Wie lange braucht ein typischer embedded C/C++ Entwickler Rust so weit zu erlernen um wieder produktiv zu werden? Ich weiß nicht ob meine Fragen den Kernpunkt von Rust treffen, aber mir fällt es schwer eine befriedigende Perspektive ins Gesichtfeld zu bekommen. Bis jetzt fand ich die Rust Webinformationen doch nicht so hilfreich.
Hinterherhinkender schrieb: > embedded Ich denke alle deine Fragen kann man so beantworten: Theoretisch hat Rust das Zeug richtig gut im Embedded-Bereich zu werden. Praktisch ist es dort heute aber noch nicht wirklich einsetzbar. Es sei denn ein Gerät der Raspberry-Pi-Klasse gilt als Embedded. Dort ist Rust gut einsetzbar. Aber so etwas wie AVR funktioniert zwar prinzipiell, ist aber noch sehr weit von der Serienreife entfernt.
W.Gates schrieb: > Was der Bauer nicht kennt frisst er nicht. Ein Programm was ewig funktioniert ist selten. Frage ist, wieviele Helfer man für Rust im Ernstfall findet und das auch noch in xx Jahren. Zumindest gibt es glücklicherweise schon einige englische Bücher dafür. https://www.oreilly.com/library/view/programming-rust/9781491927274/
> Ist auch gar nicht notwendig. Wie hier schon mehrfach erklärt wurde. > Alle nötigen dependencies können lokal vorgehalten werden. Mit und ohne > cargo. Man kann viel, man muss es nur machen. Vermutlich dann irgendwie kompliziert und man ist ja vergesslich und der Mittelwert der Leute ist erschreckend faul. Und nach jedem Update bestimmt wieder neu einstellen. Also irgendwie... Lies mal hier ueber das Grauen schlechthin: https://www.heise.de/meinung/Kommentar-zu-log4j-Es-funktioniert-wie-spezifiziert-6294476.html Wenn sich solche absurden Buildkonzepte wie mit cargo verbreiten endet das in 10Jahre mit Rust genauso wie hier mit Java. Dabei sehe ich bereits heute regelmaessig Geraete wo ich dem Programmierer gerne links und rechts ein paar reinhauen wuerde. (erst gestern bei einem Sat-Reciever) Olaf
Olaf schrieb: > Vermutlich Weniger vermuten, mehr lernen. Dependency-crates lokal zu halten ist genau so trivial wie sie von crates.io zu beziehen. Wenn es mit Cargo sein soll, dann gibt man den path zu dem crate an. Fertig. Das war es. Alle Referenzen dazu wurden hier im Thread mehrfach genannt. > Wenn sich solche absurden Buildkonzepte wie mit cargo verbreiten endet > das in 10Jahre mit Rust genauso wie hier mit Java Was hat das Buildsystem mit diesem Bug zu tun? Warum ist es absurd? Was hat Java mit Rust zu tun? > wo ich dem Programmierer gerne links > und rechts ein paar reinhauen wuerde Gegen Agressionen helfen Waldspaziergänge.
> Was hat das Buildsystem mit diesem Bug zu tun?
Die Tendenz alles immer mehr aufzublasen bis es keiner mehr durchschaut.
Olaf
Olaf schrieb: >> Was hat das Buildsystem mit diesem Bug zu tun? > Die Tendenz alles immer mehr aufzublasen bis es keiner mehr durchschaut. Das Buildsystem führt zu komplexerem Programmcode? Na wenn du meinst...
MaWIn schrieb: > Das Buildsystem führt zu komplexerem Programmcode? Du willst missverstehen, oder? Nein, der durch solche Buildsysteme entstehende Programmcode ist deutlich weniger komplex, sogar bis hin zu äußerst trivial. Der vollstände, das gesamte Projekt umfassende Programmcode ist hochgradig verteilt und schlecht bis überhaupt nicht mehr erfassbar. Je einfacher es ist, sich zig Dependencies einzuwerfen, desto weniger wird über zusätzliche Dependencies nachgedacht. Dass diese Vorgehensweise zu im Allgemeinen zu größeren Programmen und auch Problemen führt, brauche ich hoffentlich nicht weiter auszuführen. Wir sollten uns darüber hinaus sogar einig sein, dass es Workarounds für alle nur vorstellbaren Probleme gibt - und dass sie weder weitreichend benutzt werden, noch benutzt werden sollen. Letzteres führt dann im Zweifelsfall dazu, dass Bugreports schlicht missverstanden oder mit "so macht man das nicht" geschlossen werden.
S. R. schrieb: > Nein, der durch solche Buildsysteme entstehende Programmcode ist > deutlich weniger komplex, sogar bis hin zu äußerst trivial. Der > vollstände, das gesamte Projekt umfassende Programmcode ist hochgradig > verteilt und schlecht bis überhaupt nicht mehr erfassbar. Und es ist besser riesige Monolithen zu bauen, weil diese besser erfassbar sind? Für mich ist das Gegenteil der Fall. > Je einfacher es ist, sich zig Dependencies einzuwerfen, desto weniger > wird über zusätzliche Dependencies nachgedacht. Das ist kein Problem der Sprache oder des Buildsystems, sondern es ist ein Problem in deinem Entwicklungsprozess. > Wir sollten uns darüber hinaus sogar einig sein, dass es Workarounds für > alle nur vorstellbaren Probleme gibt - und dass sie weder weitreichend > benutzt werden, noch benutzt werden sollen. Letzteres führt dann im > Zweifelsfall dazu, dass Bugreports schlicht missverstanden oder mit "so > macht man das nicht" geschlossen werden. Diesen Absatz verstehe ich überhaupt nicht. Was haben Bugreports und Workarounds jetzt plötzlich mit dem Buildsystem zu tun?
Dependencies sind wie Salz, ein bisschen davon kann gut / sinnvoll sein. Ok, der Vergleich funktioniert nicht ganz, es gibt viele Arten von Dependanceies. Compile-time, Runtime, Zwingende, optional, implizit, umgekehrt (Plugins), etc. Zwingende Dependencies sind wie Salz, ein bisschen davon kann gut / sinnvoll sein. Optionale Runtime Dependancies sind wie Butter. Immer rein damit!
MaWin schrieb: >> Je einfacher es ist, sich zig Dependencies einzuwerfen, desto weniger >> wird über zusätzliche Dependencies nachgedacht. > > Das ist kein Problem der Sprache oder des Buildsystems, sondern es ist > ein Problem in deinem Entwicklungsprozess. Der Programmierer ist also schuld, wenn das Ökosystem eine bestimmte Programmierweise begünstigt oder erfordert. Na wenn das so ist... > Diesen Absatz verstehe ich überhaupt nicht. Gut, dann belasse ich dich in deiner Unwissenheit. Daniel A. schrieb: > Optionale Runtime Dependancies sind wie Butter. Immer rein damit! Mögen alle Binaries dieser Welt mit sämtlichen verfügbaren Runtime-Dependencies aktiv ausgeliefert werden! Immer her damit! Möge die Theorie über die Realität siegen! log4j für alle! Seufz. Frohe Weihnachten euch allen.
S. R. schrieb: > Der Programmierer ist also schuld, wenn das Ökosystem eine bestimmte > Programmierweise begünstigt oder erfordert. Na wenn das so ist... Der Programmierer ist dafür verantwortlich, was er programmiert. Das ist doch sonst auch immer das Argument von C-Verfechtern. Einfach einmal korrekten Programmcode schreiben. Dann braucht man keine Bounds-Checks. Dass "das Ökosystem" eine "bestimmte Programmierweise begünstigt oder erfordert" ist halt nur deine Meinung. Ich sehe keinen Zusammenhang zwischen Codegröße/Projektgröße/Projektkomplexität und Rust/Cargo. Und das wurde auch hier schon alles im Thread ausdiskutiert. Nur noch nicht von jedem. > Gut, dann belasse ich dich in deiner Unwissenheit. Ok. 1:0 für mich.
Ich erkläre es einmal mit einer Analogie: Im Linux-Kernel soll man Tabs mit 8 Spalten benutzen. Die Begründung ist unter anderem, dass man dadurch gezwungen wird, die Blocktiefe gering zu halten. Schließlich rückt man durch jeden Block um 10% näher ans Zeilenende. Es ist, denke ich, einleuchtend, dass diese Maßnahme einen häufig gemachten Fehler extrem reduzieren kann, weil man ihn technisch nicht mehr umsetzen kann, im Vergleich zu z.B. 2 Spalten als Einrückung. Deshalb halte ich die Ansicht, dass Dinge die einfach durchführbar sind, mit der Menge an tatsächlichen Durchführungen nichts zu tun habe, für rational nicht nachvollziehbar. Aus meiner Sicht gehört zum Design und Ökosystem einer Programmiersprache auch die Sorge um den Sinnvollen Einsatz und dem leisten von Hilfestellungen - in Härtefällen auch durch absichtliche Einschränkung oder Behinderung von höchstproblematischen Fehlern.
S. R. schrieb: > Je einfacher es ist, sich zig Dependencies einzuwerfen, desto weniger > wird über zusätzliche Dependencies nachgedacht. Wird ja noch geiler mit Cargo, weil dann letztlich jede Anwendung ihre eigenen Abhängigkeiten selber statisch reingebacken bekommt. Hab dann mal sowas wie Log4j gerade, das wird richtig lustig werden. Da merkt man halt, daß Rust aus ner YOLO-Webbude stammt.
Moin, Zur Abwechslung mal gute Neuigkeiten. Der rav1e-p20211207 laesst sich grad mittels rustc-1.56.1 bauen. Yay! (Notorische Schwarzseher wuerden natuerlich gleich fragen: Und wie lange noch? ;-) Gruss WK
S. R. schrieb: > Mögen alle Binaries dieser Welt mit sämtlichen verfügbaren > Runtime-Dependencies aktiv ausgeliefert werden! Immer her damit! Ist ein bisschen off-topic jetzt, aber das hatten wir schonmal mit der berüchtigten "DLL Hell" unter Windows bis XP ungefähr. Und wir haben es in so gut wie jeder Linux-Distro. Lade irgendeine besonders kompakte Debian-Distro runter, egal ob für i64- oder RPi-Habitat. Das ist jetzt bewusst polemisch, aber füge 10 Pakete hinzu, die du brauchst oder willst, irgendeins davon referenziert auf irgendwas mit Grafik, auch wenn du genau das nicht willst, und schwupps ist aus deinem kompakten, sicheren Debian-Headless ein aufgeblähtes Klicki-Ubunti-Desktop-System geworden. Ja, ich benutze an sehr vielen Stellen Linux. Nein, ich benutze kein IoT-Windows. Aber es ist jedesmal ein Akt des Grauens, diesen Troll-Horden aus Paket-Abhängigkeiten Herr zu werden. Typisch z.b. für Windows(!)-Projekte, die ihre Ursprünge aus der Win32-Zeit haben, ist, dass sie auf irgendwelche uralten Runtimes referenzieren und auf deren Installation bestehen, obwohl man ne viel neuere Runtime auf dem System hat. Neuere Anwendungen sind da viel sauberer, ohne dass sie ständig Updates brauchen. Typisch für Linux-Anwendungen ist, dass sie sich bis heute so benehmen. Das ist eben (Achtung, jetzt kommt Gemecker) der Nachteil einer offenen Umgebung, wo jeder macht, was er will, ohne dass außer um die ganz wesentlichen Dinge wie den Kernel keiner groß guckt. Die beste Idee an Win386/Win3 war, dass es ein Aufsatz auf DOS war. DOS funktionierte ganz ohne Windows. Das endete mit Win95. Ein sauberes Unix-System war immer so. Ein sauber aufgesetzter X-Server kann immer noch ohne Client-X11-Gedöns. Probier das mal heute mit Tools wie apt und Co. Und selbst, wenn du ein paar kleine Tools aus den Sourcen bauen willst, kommt irgendwann eine Abhängigkeit, die dir wieder Zeug auf die Maschine bringt, die du einfach aus Sicherheitsgründen nicht haben willst, wenn du den Kram nicht im Detail kennst und weder Zeit noch Lust hast, selbst ein Audit zu machen. Und dasselbe gilt für sehr viele Programmierumgebungen. Setz mal nen Build-Server für z.B. Python auf, ohne dass auf dem Server GUI-Kram landet. Um der üblichen Debatte Linux vs. Windows vorzubeugen: Es ist richtig(!), dass man inzwischen wieder Headless-Server unter Windows aufsetzen kann, aber es ist irre aufwändig und nur für Großkunden von MS machbar, weil die Tools nicht oder nur sehr schwer auffindbar zur Verfügung stehen. Der Weg von Unix war immer andersherum, so wie gesagt bei DOS + Windows. Das Problem ist halt, dass ohne "offizielle Aufsicht" über die Pakete die OoopsSource Community macht, was sie will, und wenn ein Coder findet, dass er für sein Kommandozeilen-Tool ne Funktion aus ner Gnome-Anwendung benutzen muss, weil es halt da ist (auf seinem PC), wandert die Abhängigkeit halt ins Paket, und apt und Co. machen das, was er will und bestehen auf die Gnome-App, die auf Gnome besteht, das auf diesdasjenes besteht... Wie gesagt: Schwupps! Ich bleibe unter Linux bei genau dem, was die GNU Compiler Collection her gibt, weil da eben doch wer drauf guckt, plus DotNet / Xamarin-Mono, weil da auch wer drauf guckt, insbesondere wer, der sich um seinen Börsenwert schert. Es gibt das NanoFramework für uCs.
Carsten P. schrieb: > Typisch z.b. für Windows(!)-Projekte, die ihre Ursprünge aus der > Win32-Zeit haben, ist, dass sie auf irgendwelche uralten Runtimes > referenzieren und auf deren Installation bestehen, obwohl man ne viel > neuere Runtime auf dem System hat. Neuere Anwendungen sind da viel > sauberer, ohne dass sie ständig Updates brauchen. Heute mit .net wird das eben so gemacht, dass man einfach ein Dutzend .net-Frameworks parallel installiert hat, weil jedes Programm eine andere Version braucht. > Die beste Idee an Win386/Win3 war, dass es ein Aufsatz auf DOS war. DOS > funktionierte ganz ohne Windows. Das endete mit Win95. Das Problem war halt, dass man die dringend fehlenden Betriebssystem-Grundfunktionen nicht in DOS, was eigentlich das Betriebssystem war, integriert hat, sondern in dessen graphischer Benutzeroberfläche. > Ein sauberes Unix-System war immer so. Ein sauber aufgesetzter X-Server > kann immer noch ohne Client-X11-Gedöns. Wozu brauchst du einen X-Server ohne X-Clients? > Das Problem ist halt, dass ohne "offizielle Aufsicht" über die Pakete > die OoopsSource Community macht, was sie will, und wenn ein Coder > findet, dass er für sein Kommandozeilen-Tool ne Funktion aus ner > Gnome-Anwendung benutzen muss, weil es halt da ist (auf seinem PC), > wandert die Abhängigkeit halt ins Paket, und apt und Co. machen das, was > er will und bestehen auf die Gnome-App, die auf Gnome besteht, das auf > diesdasjenes besteht... Teilweise liegt sowas aber auch an den Distros und die Art, wie sie ihre Pakete zusammenstellen. Das habe ich gemerkt, als ich einen Docker-Container für den Build einer Software aufsetzen wollte. Dafür musste git installiert sein, weil die Entwickler es für nötig gehalten haben, irgendwelche git-Kommandos als Teil des Build-Prozesses auszuführen. Nun gab es eigentlich unter Debian mal ein minimales git-Paket und ein Meta-Paket, dass git mit kompletter Doku und ein paar Skripten und so Zeug installiert hat. Leider wurde das minimale Paket verworfen, und jetzt muss immer alles installiert sein. Und da geht's dann los: Nur für die blöden erwähnten Skripte, die ich nicht brauche, muss eine komplette Perl-Umgebung mit Dutzenden von Paketen installiert werden. Am Ende sind die Abhängigkeiten von dem Teil von git, den ich nicht brauche, größer als der ganze Rest vom Container, nur weil die bei Debian meinen, dass man ein minimales Paket nicht mehr braucht.
Rolf M. schrieb: >> Ein sauberes Unix-System war immer so. Ein sauber aufgesetzter X-Server >> kann immer noch ohne Client-X11-Gedöns. > Wozu brauchst du einen X-Server ohne X-Clients? Ich meinte, dass auf dem Server nicht notwendigerweise Client-Kram installiert sein muss. Der kann lokal ganz ohne GUI, er liefert an die Clients aus. > Teilweise liegt sowas aber auch an den Distros und die Art, wie sie ihre > Pakete zusammenstellen. (...) > irgendwelche git-Kommandos (...) > Leider wurde das minimale Paket verworfen (...) > Und da geht's dann los: Nur für die blöden erwähnten Skripte, > die ich nicht brauche, muss eine komplette Perl-Umgebung > mit Dutzenden von Paketen installiert werden. Exakt das ist das perfekte Beispiel für das, was ich meinte. Und die Person, die "wurde" ist, kriegst du nicht zu fassen, "es" wurde halt entschieden.
:
Bearbeitet durch User
Carsten P. schrieb: > Wie gesagt: Schwupps! Du schreibst leider ganz großen Unsinn und dazu hat er auch nichts mit Rust zu tun. Deshalb werde ich nicht näher darauf eingehen. Bitte beim Threadthema bleiben!
MaWin schrieb: > Bitte beim Threadthema bleiben! Das Dahinter ist dasselbe. Dass du Rust-Fanboy bist, habe ich schon verstanden. Du hast mir bisher viele gute Replies geschrieben, also halte auch mal paar Krümel aus, die nicht in deine Sahnesoße passen ;-) Fakt ist, dass Rust derzeit keine stabile, dauerhafte Umgebung mit Zukunft ist -- was ich auf Dauer auch für Ruby und Python vorhersage. Weil es nicht genug Leute gibt, die sich endlich mal damit beschäftigen, die OpenHorde zu bändigen und auch mal notwendige Ansagen zu machen.
Carsten P. schrieb: > Das Dahinter ist dasselbe. Dass du Rust-Fanboy bist, habe ich schon > verstanden. Ich bin sicher kein "Fanboy", sondern ich setze mich mit den Dingen auseinander, bevor ich sie bewerte. > also halte auch mal paar Krümel aus, die nicht in deine Sahnesoße passen ;-) Ich sehe nur, dass du hier abstraktes Zeug ablädtst. Würdest du vielleicht einmal den Namen des Paketes nennen, bei dem eine komplette Desktop-Umgebung installiert wird, obwohl das nicht zu erwarten ist? Dann können wir vielleicht weiterdiskutieren. > Fakt ist, dass Rust derzeit keine stabile, dauerhafte Umgebung mit > Zukunft ist -- was ich auf Dauer auch für Ruby und Python vorhersage. "Fakt" also. Soso. Belegen musst du das selbstverständlich nicht. Denn es ist "Fakt".
Carsten P. schrieb: > Fakt ist, dass Rust derzeit keine stabile, dauerhafte Umgebung mit > Zukunft ist -- was ich auf Dauer auch für Ruby und Python vorhersage. Python ist erst 30 Jahre alt, Ruby 26. Ja, werden bestimmt bald verschwinden. So wie C und C++ auch verschwunden sind.
Kaj schrieb: > Python ist erst 30 Jahre alt, Ich waer' ja froh, wenn wenigstens mal nur Python2 verschwinden wuerde; aber nichtmal das klappt :-( Gegen die Sprachen an sich hab' ich auch garnix. Ich hab' was dagegen, dass jeder Depp meint, er muss einen eigenen Paketmanager verwenden und dass sich Sprachen, die noch nicht so recht stabil sind, schon in irgendwelchen Projekten festsetzen, die eigentlich etwas stabiler sein sollten... Aber was weiss ich schon, bin kein Informatiker. Gruss WK
Dergute W. schrieb: > dass jeder Depp meint, er muss einen eigenen Paketmanager verwenden Du musst es ja nicht verwenden, wenn du das nicht möchtest. Du kannst dir alle Dependencies, solltest du denn welche haben, alle manuell zusammenstellen. Gar kein Problem. Aber das haben wir hier im Thread bereits mehrfach geklärt. > und dass sich Sprachen, die noch nicht so recht stabil sind, schon in > irgendwelchen Projekten festsetzen, die eigentlich etwas stabiler sein > sollten... Ab wann ist denn eine Sprache nach deiner Definition stabil? Rust ist dank der Editions äußerst stabil und es herrschen ziemlich strikte Regeln welche Änderungen innerhalb von Editions erlaubt sind, welche Änderungen zwischen Editions erlaubt sind und welche Änderungen es niemals geben wird. https://doc.rust-lang.org/cargo/reference/semver.html https://doc.rust-lang.org/edition-guide/introduction.html Jedes Rust-Release wird gegen alle auf crates.io verfügbaren Pakete getestet (build test). Ich persönlich habe es noch nicht erlebt, dass irgendein crate sich nicht bauen lassen wollte. Im Gegensatz zu zum Beispiel C/C++-Paketen mit CMake, Autotools oder was auch immer. Da kommt es ständig zu Buildabbrüchen. Alleine schon, weil das Buildsystem sich die Dependencies nicht holen kann.
Ich wage vorauszusagen, daß es C, C++, Python, Java, PHP und Co. Und vielleicht auch Rust, auch in 100 Jahren noch geben wird. Was sich bewährt hat überlebt auch. C mag im Vergleich zu Sprachen Neuentwicklungen "Ancient to the Extreme" sein, hat aber Stabilität und Effizienz und seine eigene Eleganz. Für Kernel oder Nischen Anwendungen oder uC ist C in den Händen erfahrener Designer bestimmt immer noch gut geeignet. Das größte Problem der modernen SW Entwicklung sind nicht notwendigerweise die Sprachen und Werkzeuge selber. Vielmehr verursachen unschöne Geschäftserwartungen und Time to Market Constraints viele Probleme durch Hetzerei die Produkte auf den Markt zu werfen. Man nimmt sich nicht mehr die Zeit, durchdacht und gemächlich vorgehen zu können. Deshalb haben wir ja auch andauernd persistente Sicherheitslücken. Ein Gebäude ist nur so robust wie sein Grundgerüst. Viele moderne IT Produkte können aus der Sicht des Users teilweise sehr nervig sein weil man sich nicht die Zeit nimmt, ergonomische Unebenheiten auszubügeln. Das ist sehr schade, weil jene so vermeidbar wären. Wer hat sich noch nicht maßlos geärgert wenn sich ein Gerät so dumm verhält und unnötig schwer bedienbar ist. Was wir in der Welt weniger brauchen ist diese Lawine von unwichtiger Elektronik und SW. Es ist Zeit Fazit zu nehmen um festzustellen wo wir uns befinden und ins nicht länger vom Strom des Marktes mit schwemmen lassen. Daß das zutreffend ist, kann man alleine daraus folgern, daß kaum einer heutzutage imstande ist tolle Produkte zu nennen die erinnerungswürdig sind. Wir werden von einer Lawine fernöstlicher vergessbaren Ramschware und Billigprodukten erdrückt und verlieren eigenes Produktionspotenzial. Wie viele Firmen können aus diesen Grund schon lange nicht mehr überleben. Beruflich ist es sowieso notwendig gut in der (den) Sprache(n) zu sein, für die ihm der Brötchengeber bezahlt und in die Firmenkultur reinpasst. Was mich und meine Anwendungen betrifft finde ich C besonders praktisch und das braucht sonst niemand besonders interessieren. Was mir an C gefällt ist die maschinennahe direkte Übersetzung und für uC Anwendungen ist das nicht unbedingt ein Nachteil. Man abstrahiert heute m.M.n. sowieso oft unnötig zu viel. Aber jeder mag es so halten wie es ihm für zweckmässig erachtet. Ich verstehe nicht wirklich warum wegen Computersprachen in den Foren so oft hitzige Glaubenskriege verursacht werden. Wir sind doch keine Missionare. Jeder kann doch diejenigen Werkzeuge verwenden die subjektiv attraktiv sind und für die beabsichtigten Zwecke gut funktionieren. Auch sind wir nicht alle gleich in der Art wie unsere Gehirne diesbezüglich funktionieren; der eine hat eine natürliche Affinität für objektorientierte Denkweise, der Andere ist mit prozedurer Denkweise total komfortabel. Deshalb sind diese ganze Streitereien und Diskussionen überflüssig weil wir alle grundverschieden sind. Konformität ist nur beruflich benötigt. Viele Argumente sind subjektiv bestimmt exakt zutreffend, aber nicht unbedingt in anderen Augen. Mit genug Disziplin und Erfahrung kann man in fast allen Sprachen zuverlässige SW bauen, sogar auch in C:-) Ob jetzt aus Rust ein Erwachsener wird, muß die Zukunft zeigen. Wenn es tatsächlich die Erwartungen eventuell erfüllen wird, dann wird es auch früher oder später eine solide Nische im Arsenal der Computerwerkzeuge finden. Time will tell. Bis dahin wird man eben sich damit befassen müssen.
Gerhard O. schrieb: > Man nimmt > sich nicht mehr die Zeit, durchdacht und gemächlich vorgehen zu können. > Deshalb haben wir ja auch andauernd persistente Sicherheitslücken. Ich würde das nicht als Hauptgrund für die Sicherheitslücken sehen, die wir ständig haben. Ich würde das eher in dieser Reihenfolge (1 = Hauptgrund) bewerten: 1: Kompetenz und Sicherheitsbewusstsein bei den Entwicklern ist nicht ausgeprägt genug. Aktuelles Beispiel? log4j. 2: Die Sprache erlaubt viel zu einfach triviale Schwachstellen. Aktuelles Beispiel? https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/lua/lua_request.c?r1=1896039&r2=1896038&pathrev=1896039 Das wäre mit Rust auch ein Bug, ein DoS, aber keine Speicherkorruption/Sicherheitslücke, die man eskalieren kann. 999: Druck vom Management und zu wenig Zeit.
Gerhard O. schrieb: > Wir sind doch keine Missionare. Genau. Wenn jemand kein Rust verwenden will, dann soll er es halt lassen. Wenn jemand meint C wäre die Antwort auf alle Fragen, dann soll er halt C verwenden. Das ist mir wirklich egal, was jeder tut. Ich sage ja auch nicht, dass Rust die Lösung für alle Probleme ist und dass ab sofort Rust für alles verwendet werden muss. Was ich nicht mag ist, wenn Unsinn verbreitet wird. Viel Unsinn in diesem Thread ist einfach von Leuten, die Rust eindeutig noch nie verwendet haben und die Sprache nur aus dem Heise-Forum kennen. Und dann gibt es auch noch die Leute, die grundsätzlich gegen alle Neuerungen sind. Da wäre ich froh, wenn die sich einfach komplett vom Thema fern halten. Lasst uns doch machen und lasst uns doch scheinbar in die Sackgasse fahren. Kann euch doch egal sein.
Moin, MaWin schrieb: > Ab wann ist denn eine Sprache nach deiner Definition stabil? Weiss ich nicht. Aber ich merk' wann was instabil ist: Wenn z.b. nach ein paar Monaten schon compiler und code irgendwie nicht mehr zusammenpassen wollen. Ich saug' mir das ja nicht aus den Fingern, sondern schreibe hier schon auch die Versionsnummern dazu. MaWin schrieb: > Jedes Rust-Release wird gegen alle auf crates.io verfügbaren Pakete > getestet (build test). > > Ich persönlich habe es noch nicht erlebt, dass irgendein crate sich > nicht bauen lassen wollte. Ich will auch kein crate bauen, schlonz verschwurbeln oder ein Honk verschradeln oder sonst sowas exotisches. Ich will ein Videocodec. Aus sourcen. Punkt. Nix weiter. Und das klemmt deutlich haeufiger und unangenehmer, wenn da Rust im Spiel ist. Auch wenn du mir 10x erzaehlst, dass da Rust natuerlich ueeeeberhaupt nix dazu kann. Der Kommunismus kann auch nix dazu, das er mit real existierenden Menschen nicht funktioniert. Aber deshalb sollte man ihn nicht einsetzen. Wie Rust. MaWin schrieb: > Im Gegensatz zu zum Beispiel C/C++-Paketen mit CMake, Autotools oder was > auch immer. Da kommt es ständig zu Buildabbrüchen. Alleine schon, weil > das Buildsystem sich die Dependencies nicht holen kann. Und genau das ist gut so. Ich will wissen, was da fuer dependencies drinnen sind. Und bei gut geschriebener Software kann ich mir's sogar raussuchen, ob ich irgendeine lib und ihre Funktionalitaet drinnenhaben will oder nicht. Bei ffmpeg ist das ein Thema, weil davon dann auch die Lizenz abhaengt, unter der das dann steht. Bei den Autotools ist's sogar so geil, das man auch nach langer Zeit einfach mal in der config.log nachschauen kann, mit was man das Dingens damals tatsaechlich konfiguriert & gebaut hat. Bei cmake, ninja, meson siehts bei so elemetaren Sachen ja eher schon arg mau aus - oder ich bin einfach zu bloed. Gruss WK
Dergute W. schrieb: > Ich saug' mir das ja nicht aus den Fingern, > sondern schreibe hier schon auch die Versionsnummern dazu. Ich sage ja nicht, dass das nicht stimmt. Sondern ich sage nur, dass du dort eine absolute Ausnahme erwischt hast. > Ich will wissen, was da fuer dependencies drinnen sind Kein Problem mit Cargo: https://doc.rust-lang.org/cargo/commands/cargo-tree.html > Und bei gut geschriebener Software kann ich mir's sogar > raussuchen, ob ich irgendeine lib und ihre Funktionalitaet drinnenhaben > will oder nicht Kein Problem mit Cargo: https://doc.rust-lang.org/cargo/reference/features.html > Bei den Autotools ist's sogar so geil, das man auch nach langer Zeit > einfach mal in der config.log nachschauen kann, mit was man das Dingens > damals tatsaechlich konfiguriert & gebaut hat. Kein Problem mit Cargo: Cargo.lock Aber wenn dir Cargo nicht passt, kannst du selbstverständlich auch dein Rust-Projekt mit Autotools bauen oder mit jedem anderen beliebigen Buildsystem.
> Ich will mir mal einen heif-decoder > (das neue,lustige Video/Bildformat > von Apple unter Linux Okay, da würde ich auch als Fauchbatz und Knurrer nur sagen "Fuck U, so what" xD Wer das neue lustige Format von den neuen Apple Situps mit den neuen von Google verkrackten Crunches vergleicht und dabei auch noch Sicherheit und so haben will, im Ernst... lol
cppbert schrieb: > Das ist definitiv eine riesen Herausforderung - an der bisher jede > Sprache ausser C (C++) und ein paar wenigen anderer, gescheitert ist - Sehe ich ganz genau so. Embedded ist zu breit gefächert. Auf die 100 Chips, die es im Mainboard-Bereich gibt, die aktuell laufen und neu unterstützt werden müssen, kommen im embedded-Bereich 10x soviele! Gleichzeitig sind es 100x weniger Nutzer! Es lohnt sich dreimal, eine Programmiersprache auf low level den PCs hinterher zu entwickeln, aber im embedded Bereich ist man immer hinterher. Auch die Gold-Anbieter decken immer nur einen Teil der Landschaft ab und teilen sich so den Markt. Wie will ein am Ende doch kleines Team das bewältigen? Der Aufwand für solche Neuimplementierungen und BSPs liegt im embedded Bereich bei locker dem 3-4 fachen und zusammen mit der Vielfalt der Chips braucht es 200 ... 500 mal mehr Entwickler, um Schritt zu halten. Um einen weiteren Vergleich zu ziehen wäre es interessant zu wissen, wieviele Compiler-Entwickler es weltweit gibt. Das sind hunderte Firmen mit Tausenden Programmierern. Die zu überholen wird schwer ,,,
Andreas F. schrieb: > Die zu überholen wird schwer ,,, Es ist überhaupt nicht der Anspruch jeden Nischencompiler "zu überholen". Es ist völlig in Ordnung auch in Zukunft Embedded-Software in C zu schreiben. Rust unterstützt aber bereits sehr viele ARM Devices und damit einen Großteil des Embedded-Marktes. Wenn GCC-Rust verwendbar wird (erste Version vermutlich nächstes Jahr), dann wird das noch einmal gewaltig ausgeweitet.
MaWin schrieb: > Wenn > jemand meint C wäre die Antwort auf alle Fragen, dann soll er halt C > verwenden. Das ist mir wirklich egal, was jeder tut. Mir ist das nicht egal. In vielen Fällen kann es einem egal sein was andere bevorzugen. Aber wenn die Wahl von Menschen, zu Folge hat, das Schäden für mich und andere Menschen entstehen, dann ist das nicht egal. C Programme beinhalten häufig vermeidbare Sicherheitslücken die die Sicherheit von IT Systemen gefährden. In der Folge entstehen massive Schäden. Daten werden geklaut oder manipuliert und vielen Unternehmen entstehen beträchtliche finanzielle Schäden. Ist wie mit der Logik der Schutzimpfung. Wer sich nicht impfen lässt trifft nicht nur eine Entscheidung für sich, sondern beeinflusst auch die Sicherheit anderer Menschen.
HabMut schrieb: > C Programme beinhalten häufig vermeidbare Sicherheitslücken die die > Sicherheit von IT Systemen gefährden. In der Folge entstehen massive > Schäden. Daten werden geklaut oder manipuliert und vielen Unternehmen > entstehen beträchtliche finanzielle Schäden. Das ist richtig. Trotzdem kannst du andere Leute nicht dazu zwingen eine Sprache zu verwenden, die sie nicht verwenden möchten. Dir steht aber offen entweder diese Programme nicht zu verwenden, oder sie selbst in Rust zu implementieren.
MaWin schrieb: > Trotzdem kannst du andere Leute nicht dazu zwingen eine Sprache zu > verwenden, die sie nicht verwenden möchten. Aus einer Kritik muss nicht immer ein Zwang hervorgehen. Kritik ist aber erforderlich damit etwas langfristig besser werden kann. Genau so ist Kritik an Rust auch ok und förderlich.
> C Programme beinhalten häufig vermeidbare Sicherheitslücken die die > Sicherheit von IT Systemen gefährden. Meinst du nicht das diese Einstellung in diesem Zusammenhang etwas laecherlich ist oder ist Rust schon nach IEC61508 zertifiziert? Olaf
Olaf schrieb: >> C Programme beinhalten häufig vermeidbare Sicherheitslücken die die >> Sicherheit von IT Systemen gefährden. > > Meinst du nicht das diese Einstellung in diesem Zusammenhang etwas > laecherlich ist oder ist Rust schon nach IEC61508 zertifiziert? Es geht um Security, nicht um Safety.
Firefox? Ist das nicht der Laden wo die guten Entwickler, abgehauen sind, und die jetzt lieber einen auf bunten FF machen stats einem guten Browser?
HabMut schrieb: > C Programme beinhalten häufig vermeidbare Sicherheitslücken die die > Sicherheit von IT Systemen gefährden. In der Folge entstehen massive > Schäden. Nein, jedes Programm in jeder Programmiersprache hat zwangsläufig Sicherheitslücken. Daran ändert Rust nichts. Man sehe sich z.B. log4j an. Java ist absolut Memory Safe, dank Garbage Kollektion. Und trotzdem hat man plötzlich gemerkt, das eigentlich jedes Java Programm einen format String basierten Remote Code Execution Bug hat. Eine Programmiersprache hilft nur wenig beim verhindern von solchen Fehlern. Was man wirklich braucht sind (bei der Entwicklung) Erfahrung, KISS, einen Überblick, was alle Programmkomponenten genau machen und wie sie zusammen spielen, (und bei OPs) jemand der alles Updated wenn Probleme gefunden werden, Tests, offizielle Kanäle zum melden von Bugs, und eventuell von zeit zu zeit mal ein Audit, usw. Und massive Schäden vermeidet man auch nicht mit einer "sicheren" Sprache. Statdessen braucht man eine gute Incidence Response Strategie, und regelmässige Übungen. Also offline Backups von allem, das zurück spielen prüfen, eventuell ein Fallback System (das kann auch analog sein, Hauptsache jeder weiss, was er Zutun hat), etc. Idealerweise sollte alles weiterlaufen, wenn mal das Haus abfackelt.
HabMut schrieb: > C Programme beinhalten häufig vermeidbare Sicherheitslücken die die > Sicherheit von IT Systemen gefährden. Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber "sicher" keine sicherheitsrelevanten großen Systeme. Ich kenne genau einen sehr versierten "plain C"-Entwickler, dem ich meine Bedürfnisse nach einer Software anvertrauen würde, und der verwendet eine selbst entwickelte GC, da ist nix mit malloc(). strcpy() und free(). Läuft seit der ersten Version sogar auf S7-Steuerungen. Traue keiner Runtime ohne verwaltetem Speicher! Und traue gar keinem System ohne eine Runtime/einem Framework! Das gilt für Linux wie für Windows wie für Android wie für iOS.
DPA schrieb: > Nein, jedes Programm in jeder Programmiersprache hat zwangsläufig > Sicherheitslücken. Daran ändert Rust nichts. Das Argument war aber nicht, daß Rust-Programme keine Sicherheitslücken hätten, sondern daß ganze Fehlerklassen mitsamt den zugehörigen Sicherheitslücken ausgeschlossen werden. Formatstring-basierte Lücken können C/C++-Programme nämlich zusätzlich zu den Speicherlücken haben.
Nop schrieb: > Das Argument war aber nicht, daß Rust-Programme keine Sicherheitslücken > hätten, sondern daß ganze Fehlerklassen mitsamt den zugehörigen > Sicherheitslücken ausgeschlossen werden. Formatstring-basierte Lücken > können C/C++-Programme nämlich zusätzlich zu den Speicherlücken haben. Zur Ehrenrettung anderer Umgebungen sei noch erwähnt, dass die das auch können, nicht nur Rust. Python ist da recht stabil, wenn auch langsam, das .NET NanoFramework kann das ebenso, nur schneller. Manche Leute meinen halt, dass das Programmieren von Mikrocontrollern weh tun muss, drum dann C. Die Zeiten ändern sich, auch wenn es manchen Leuten nicht passt. Wie gesagt, Python, Rust, NanoFramework sind halt das, was man heute einfach benutzt. Und für extrem zeitkritische Applikationen nimmt man halt entweder Maschinencode oder einfach die Version des uC, der schnell genug ist. Wer da auf den Cent genau kalkuliert, kalkuliert garantiert zweimal.
Nop schrieb: > Das Argument war aber nicht, daß Rust-Programme keine Sicherheitslücken > hätten, sondern daß ganze Fehlerklassen mitsamt den zugehörigen > Sicherheitslücken ausgeschlossen werden. Das mag ja sein, aber Speicherbasierte Sicherheitslücken sind meist nicht trivial auszunutzen, da brauchen Angreifer doch etwas Zeit, know-how, und Zusatzwissen zum Zielsystem. Den fix hat man dann meistens lange bevor das jemand ausnutzen kann. Aber all die anderen Fehlerklassen (format string confusion, zeugs das code/module nachlädt und ausführt, xss artiges zeug, parser bugs, path confusion bugs, supply chain Attacken, etc. etc., alles viel einfacher auszunutzen, und meiner Meinung nach viel gefährlicher. Zu meinen, Speichersicherheit mache den unterschied, ist wie die Vordertür abschliessen, aber nicht nachsehen, ob die Hintertür noch offen ist. Alles nur ein tropfen auf den heissen Stein, ein falscher sinn von Sicherheit, nutzlos!
Carsten P. schrieb: > Zur Ehrenrettung anderer Umgebungen sei noch erwähnt, dass die das auch > können, nicht nur Rust. Es geht aber darum, dass Rust diese Konzepte erzwingt und noch viel weiter treibt (Lifetimes) als z.B. C++. Ein Rust-Programm kann kein UB durch AOOB-Accesses haben. Ein Rust-Programm kann keine Data-Races haben. Es ist ein riesiger Unterschied, ob man in C++ diese Fehler auch vermeiden kann, oder ob diese Fehler in Rust gar nicht möglich sind. > Und für extrem zeitkritische > Applikationen nimmt man halt entweder Maschinencode Oder halt Rust.
> Nein, jedes Programm in jeder Programmiersprache hat zwangsläufig > Sicherheitslücken. Daran ändert Rust nichts. Man sehe sich z.B. log4j > an. Das Problem hier ist aber das man fremden Source in eigenen Programmen benutzt und der nicht fehlerfrei ist. Etwas das ja wohl heute Standard sein duerfte. Und die Leute machen das weil es bequemer, einfacher, zeitsparender ist als wenn man es selber macht. Gelegentlich auch weil ein fremder Autor mehr Expertise in einem Thema hat als man selber. Alles Dinge die sicherstellen das man garnicht in der Lage ist selber die Fehler in fremden Source zu finden. Man koennte auch sagen die zunehmende Featureritis sorgt dafuer das die Wahrscheinlichkeit fuer solche Probleme start ansteigt. Bisher im Embedded bereich noch nicht so stark, aber wir holen auf. :-) Alle Leute denken: Ach, diese Library benutzen ja schon 23425123 Leute, also wird sie wohl okay sein, was kann schon passieren. :-D Olaf
MaWin schrieb: > Ein Rust-Programm kann kein UB durch AOOB-Accesses haben. Ein > Rust-Programm kann keine Data-Races haben. > Es ist ein riesiger Unterschied, ob man in C++ diese Fehler auch > vermeiden kann, oder ob diese Fehler in Rust gar nicht möglich sind. Und die Titanic war unsinkbar. Solange eine Programmiersprache praktisch relevante Programme erlaubt, wird diese Fehler oder Sicherheitslücken zulassen. Solange Menschen Programmcode basteln, wird dieser Fehler oder Sicherheitslücken enthalten. Trotzdem ist jeder Fortschritt ein Fortschritt, wenn er sich bewährt. Oliver
Es geht gar nicht darum eine utopische perfekte Programmiersprache zu schaffen mit der Sicherheitsprobleme unmöglich sind. Ich spreche von bedeutenden Verbesserungen und wie hier schon erwähnt wurde, dass ganze Kategorien von möglichen Sicherheitsproblemen ausgeschlossen werden. Mit einem heutigen Auto kann man auch Unfälle bauen. Trotzdem würde ich von den Autos der ersten Generation abraten. Weil die noch viele Probleme aufweisen die man heute schon gelöst hat.
HabMut schrieb: > Es geht gar nicht darum eine utopische perfekte Programmiersprache zu > schaffen mit der Sicherheitsprobleme unmöglich sind. Ich spreche von > bedeutenden Verbesserungen und wie hier schon erwähnt wurde, dass ganze > Kategorien von möglichen Sicherheitsproblemen ausgeschlossen werden. 1 oder 2 Kategorien, von unzähligen. Schön und gut, aber ich würde das jetzt nicht gleich bedeutend nennen. Und wenn man bedenkt was für ein Krampf es sein kann, Rust zu schreiben, im Vergleich zu anderen sicheren Sprachen wie z.B. Java und Python, zweifle ich doch stark daran, dass sich das lohnt.
Oliver S. schrieb: > Und die Titanic war unsinkbar. > Solange eine Programmiersprache praktisch relevante Programme erlaubt, > wird diese Fehler oder Sicherheitslücken zulassen. Solange Menschen > Programmcode basteln, wird dieser Fehler oder Sicherheitslücken > enthalten. Aber eben keine UB durch AOOB-Zugriffe und auch keine Data-Races. Generell gibt es gar keine UB in Safe-Rust. Rust ist in dieser Hinsicht tatsächlich "unsinkbar". UB/AOOB und Data-Races sind für einen sehr großen, wenn nicht den größten, Teil der Sicherheitslücken in Software verantwortlich. DPA schrieb: > 1 oder 2 Kategorien, von unzähligen. Nein. Die relevantesten von unzähligen. DPA schrieb: > Und wenn man bedenkt was für ein > Krampf es sein kann, Rust zu schreiben, Warum? Kannst du das etwas näher erläutern, was hier "ein Krampf" sein soll? > im Vergleich zu anderen sicheren > Sprachen wie z.B. Java und Python, Weder Java noch Python bieten zum Beispiel die Garantie der Abwesenheit von Data-Races. Ich finde es auch gar nicht angebracht Rust mit Python zu vergleichen. Das sind zwei völlig verschiedene Sprachen mit völlig verschiedenen Einsatzgebieten. Rust hat gar nicht den Anspruch Python zu ersetzen.
MaWin schrieb: > Weder Java noch Python bieten zum Beispiel die Garantie der Abwesenheit > von Data-Races. Ja schon, aber es gibt viele sehr einfache Wege, diese zu vermeiden. Das Problem hat man ja nur, wenn man threads verwendet, und mit mehreren Threads auf die selben Daten zugreift. In der Praxis braucht man das nur selten wirklich. Meistens braucht man überhaupt keine Threads. Bei python ist meistens async-await eine sehr gute Alternativen. Je nachdem kann man ein Programm auch mehrfach starten, wenn das zu verarbeitende untereinander unabhängig ist. Und in Java ist es extrem einfach, lock guards zu machen. Eigentlich muss man da meistens nur nicht vergessen, die richtigen Methoden / Blöcke mit "synchronized" oder "synchronized(objekt)" zu kennzeichnen. Zudem ist noch zu beachten, dass man den Ablauf auch falsch machen kann, ohne klassische Data-Races. z.B. Kannst du trotzdem festlegen, dass ein Bankomat Geld ausgibt, und dass er es vom Kontobetrag abzieht, ohne festzulegen, das erst das eine, und dann erst das andere passiert. Du kannst in Rust dann halt nicht gleichzeitig auf den Kontobetrag zugreifen, und es ist etwas schwerer, das so derart falsch zu machen, aber derartige Race-Conditions kannst du trotzdem erzeugen. Ist halt dann kein Data-Race mehr, sondern ein falscher Ablauf, aber kein bisschen weniger schlimm. Es ist wie überall, die Entwickler werden einfach neue Wege finden, Dinge falsch zu machen.
DPA schrieb: > Ja schon, aber es gibt viele sehr einfache Wege, diese zu vermeiden. Und genau das ist der Unterschied. Jede Sprache hat Mittel und Wege diese Fehlerklasse zu vermeiden. In Rust ist es gar nicht möglich diesen Fehler zu machen. > Das > Problem hat man ja nur, wenn man threads verwendet, und mit mehreren > Threads auf die selben Daten zugreift. In der Praxis braucht man das nur > selten wirklich. Ja, weil es in vielen Sprachen extrem schwierig ist überhaupt Threads zu verwenden. (Ab C++11 ist es wenigstens in C++ recht einfach geworden). In Rust ist es hingegen sehr einfach Threads zu verwenden. Sehr viele Rustprogramme nutzen Threads. DPA schrieb: > Bei python ist meistens async-await eine sehr gute Alternativen. Das kann Rust natürlich auch. Und zusätzlich kann es die Coroutinen auch noch in OS-Threads ausführen. Eben weil die Sprache Thread-safety erzwingt, ist dies transparent und ohne spezielle Vorkehrungen des Entwicklers möglich. Das kann Python nicht. DPA schrieb: > Eigentlich > muss man da meistens nur nicht vergessen, die richtigen Methoden / > Blöcke mit "synchronized" oder "synchronized(objekt)" zu kennzeichnen. In Rust kann man das gar nicht falsch machen, weil man gar keinen Zugriff auf die Daten bekommt, wenn man das Locking falsch macht. DPA schrieb: > aber derartige Race-Conditions kannst du trotzdem erzeugen. Das ist richtig. Hat aber auch niemand behauptet, dass Rust gleich alle Probleme löst.
MaWin schrieb: > Es geht aber darum, dass Rust diese Konzepte erzwingt und noch viel > weiter treibt (Lifetimes) als z.B. C++. Sagte ich doch, das tun Rust, Python, NanoFramework und sicher noch ein paar andere. Und wie andere ebenfalls sagten, ist das nur eins der Einfallstore für clevere Hacker. Es gilt der Satz des indischen Weisen: Die größte Sicherheitslücke bei IT-Systemen sitzt vor dem Bildschirm und klickt auf Links.
:
Bearbeitet durch User
Carsten P. schrieb: > MaWin schrieb: >> Es geht aber darum, dass Rust diese Konzepte erzwingt und noch viel >> weiter treibt (Lifetimes) als z.B. C++. > > Sagte ich doch, das tun Rust, Python, NanoFramework und sicher noch ein > paar andere. Lifetimes sind ein Alleinstellungsmerkmal von Rust. Mit fällt spontan gar keine andere Sprache ein, die das auch kann. Im Nachhinein ist das auch praktisch nicht in eine bestehende Sprache einbaubar. > ist das nur eins der Einfallstore für clevere Hacker. UB/AOOB und Data Races sind nicht nur "irgendein Einfallstor", sondern es sind die Fehlerklassen, die für den Großteil der Sicherheitslücken in C/C++-Software verantwortlich sind. > Die größte Sicherheitslücke bei IT-Systemen sitzt an der Tastatur. Eben. Und deshalb sollte man Sprachen so designen, dass schwerwiegende Fehler gar nicht oder nur schwer möglich sind und im Fehlerfall nicht eskalierbar sind.
MaWin schrieb: >> ist das nur eins der Einfallstore für clevere Hacker. > UB/AOOB und Data Races sind nicht nur "irgendein Einfallstor" Wo habe ich "irgendein Einfallstor" geschrieben? Zitiere mich bitte richtig.
Carsten P. schrieb: > MaWin schrieb: >>> ist das nur eins der Einfallstore für clevere Hacker. >> UB/AOOB und Data Races sind nicht nur "irgendein Einfallstor" > > Wo habe ich "irgendein Einfallstor" geschrieben? Zitiere mich bitte > richtig. Ich habe dich richtig zitiert. Und zwar so: > ist das nur eins der Einfallstore für clevere Hacker.
Olaf schrieb: > Das Problem hier ist aber das man fremden Source in eigenen Programmen > benutzt und der nicht fehlerfrei ist. Dieser Satz lässt sehr tief blicken. Du implizierst nämlich, dass fremder Code mehr Fehler enthalten würde, als eigener Code. Und genau dieser Mindset ist die Grundlage für Software-Fehler, inkl. Sicherheitslücken. Witzig dabei, dass gerade dieser Mindset immer wieder bei Embedded-Leuten zu finden ist, und in aktueller Zeit gerade unzählige Embedded-Systeme mit scheunentorartigen Sicherheitslücken glänzen. Witzig dabei auch, dass die "große" Softwarebranche(n) diesem Irrglauben vor etwa 25 Jahren auch aufgesessen ist, und brutal lernen musste, wie falsch dieser Mindset war. Tragisch dabei, dass wieder bewiesen wird, das Gruppe B nicht aus den historischen Fehlern der Gruppe A lernt, sondern die gleichen Fehler selbst durchleben will. Scheint irgendwie zum Mensch zu gehören.
> Und deshalb sollte man Sprachen so designen, dass schwerwiegende Fehler > gar nicht oder nur schwer möglich sind und im Fehlerfall nicht > eskalierbar sind. Naja. Man sollte eines dabei im Auge behalten. Es wird immer mehr in Sprachen programmiert, die Anwendern und Entwicklern ermöglichen, in kürzester Zeit, d.h. ohne zeitaufwändige Einarbeitung lauffähigen Programmcode zu generieren. Wo steht da Rust z.B. im Vergleich mit bei vielen beliebten Programmierdialekten? Zitat von cppbert > Die Syntax ist nicht ganz leicht und keine Programmiersprache der Welt > vollbringt Wunder Wer (der es nicht muss) "quält" 1) sich schon freiwillig mit Zeugs rum, für das sich auch bereits bewährte Alternativen anbieten? Vor allem wenn letztere sich bereits lange in Entwicklung und damit ziemlich in hohem Maße gereift sind. Wo stehen denn z.B. die noch vor gar nicht so langer Zeit gehypten Sprachen wie go und Nim? Man hört Nim-mer viel .. Dem Linuxer mag es genügen wenn sein Code ihm ausgabemäßig die Konsole befüttert. Unter Windows haben es die Allermeisten aber gerne, wenn sich die App(likation) wohl aufgeräumt und im modernen Design dem Auge des Anwenders erschließt - nicht nur am Desktop, sondern am Tablet, am Smartphone, auf der Smartwatch usw. Mahnende Beispiele, die das (aufgeräumte GUI-Design) offensichtlich nicht bieten, sind hier aus dem CAD-Bereich jüngst genannt worden (verschrobene Bedienweise) bzw. wie man es besser macht oder sein kann ebenfalls. Vielleicht will dort Rust aber auch gar nicht hin. Vielleicht hat es der an Rust Interessierte mit GUI nicht so, weil ihm das zu "doof" erscheint und er sich lieber mit anderem befasst. Für Quantenalgorithmen gibt es Q-Sharp. Für KI listet die Computerwoche vom Nov. 21 Python, C++, JAVA, R, Julia und andere. Da ist weit und breit nix von Rust zu lesen. 1) extra in Anführung für die Fanboys ;)
> Du implizierst nämlich, dass fremder Code mehr Fehler enthalten würde, > als eigener Code. Und genau dieser Mindset ist die Grundlage für > Software-Fehler, inkl. Sicherheitslücken. Nein keineswegs. Du implizierst in deiner schlichten Gedankenwelt ein eigene Erkenntnis und baust daraus ein falsches Weltbild das du mir ueberstuelpen willst. Fremder Code kann im Rahmen gemittelter Programmiererfaehigkeit nur genauso gut/schlecht sein wie der eigene wenn er von relativ wenigen Leuten verwendet wird. Er koennte bezueglich Fehler aber auch sehr viel besser sein wenn er von sehr vielen Leuten verwendet wird die alle zur Verbesserung beitragen. Es gibt damit aber auch Probleme: 1. Finde ich eine Luecke/Fehler in einem fremden Code kann ich das dann sofort bei vielen Geraeten ausnutzen. Und im Embeddedbereich kannst du nicht rumlaufen und den Leuten erzaehlen das die jedes Geraet einmal im Monat updaten muss wie z.B bei Handysoftware. 2. Die Gruende viel fremden Code zu benutzen sind gleichzeitig gute Gruende den eben nicht genau zu untersuchen. Das wird ja schon jemand anderes gemacht haben. .-) 3. Gerade im Embeddedbereich passen unterschiedliche Programmierstile nicht immer perfekt zusammen. Das erhoeht die Resourcenanforderungen. Also mehr Strom oder teurere Controller. 4. Eine Tendenz jeden Kram in ein Geraet einzubauen und so die Funktionalitaet aufzublasen. Das kann natuerlich ein Vorteil sein, es ist aber auf jedenfall auch ein Nachteil. Jetzt schickt sich Rust ja an C zu verdraengen. Das wuerde ich tendenziell positiv finden, ich sehe durchaus den Nachteil von C. Allerdings gefaellt mir nicht der Mindset in den Entwicklerhirnen hinter Rust. (Erfinden von neuen Woertern fuer alten Wein (z.b crates!), Propagierung anderer Buildsysteme obwohl sowas unabhaengig von einer Sprache zu sein hat, Internetbezug/AutoUpdates) Olaf
Onkel Darwin schrieb: > Es wird immer mehr in > Sprachen programmiert, die Anwendern und Entwicklern ermöglichen, in > kürzester Zeit, d.h. ohne zeitaufwändige Einarbeitung lauffähigen > Programmcode zu generieren. Wo steht da Rust z.B. im Vergleich mit bei > vielen beliebten Programmierdialekten? Das ist eine Anforderung, die einer strengen Typisierung halt widerspricht. Wenn du Rapid Prototyping oder quick & dirty haben möchtest, nimm Python oder etwas ähnliches. > Wer (der es nicht muss) "quält" 1) sich schon freiwillig mit Zeugs rum Rust ist sehr C-ähnlich. Wer C kennt, findet sich schnell in Rust zurecht. > für das sich auch bereits bewährte Alternativen anbieten? Vor allem wenn > letztere sich bereits lange in Entwicklung und damit ziemlich in hohem > Maße gereift sind. Soso. In ziemlich hohem Maße gereift also. Die ständigen UB-basierten Sicherheitslücken reifen wohl mit. > Wo stehen denn z.B. die noch vor gar nicht so langer Zeit gehypten > Sprachen wie go und Nim? Go hat einen völlig anderen Zweck als Rust. Das steht nicht wirklich in Konkurrenz. Nim kenne ich nicht. > Vielleicht will dort Rust aber auch gar nicht hin. Vielleicht hat es der > an Rust Interessierte mit GUI nicht so, weil ihm das zu "doof" erscheint > und er sich lieber mit anderem befasst. Es ist überhaupt kein Problem GUI-Anwendungen in Rust zu schreiben. Zum Beispiel mit GTK. Das ist sicher nicht der Hauptzweck von Rust, aber es geht gut. Es wird ständig behauptet man könne Rust nicht für GUI-Applikationen einsetzen. Das ist ganz einfach falsch.
Olaf schrieb: > kannst du > nicht rumlaufen und den Leuten erzaehlen das die jedes Geraet einmal im > Monat updaten muss wie z.B bei Handysoftware. Auf meinem Mobiltelefon kommen täglich Updates rein. > Erfinden von neuen Woertern fuer alten Wein (z.b crates!) Welches Wort hättest du denn verwendet? > Propagierung anderer Buildsysteme Welches Buildsystem hättest du denn genommen? > obwohl sowas unabhaengig von einer Sprache zu sein hat Cargo ist unabhängig von der Sprache Rust. > Internetbezug Niemand zwingt dich Cargo online zu nutzen. Du kannst problemlos alle crates lokal vorhalten. Statt der Versionsnummer gibst du einfach den relativen Pfad zum Crate in Cargo.toml an. Einfacher gehts kaum. > AutoUpdates Was soll das sein?
MaWin schrieb: >> ist das nur eins der Einfallstore für clevere Hacker. "eins" ist nicht "irgendein". Nur zur Kenntnisnahme, auch auf die Gefahr hin, dass ich mich wiederhole: Ich halte "C" heutzutage für gar nichts mehr geeignet, weil es für alle möglichen Domains bessere Alternativen gibt. Würde heute noch wer ein neues Betriebssystem from scratch schreiben, würde er das sicher nicht in purem "C" machen, außer vielleicht die allerallerrudimentärsten Funktionen, die nötig sind, um einen gemanagten Kernel hochzuziehen, und danach zur Laufzeit diese rudimentären Funktionen auch gleich wieder entladen.
Onkel Darwin schrieb: > Wer (der es nicht muss) "quält" 1) sich schon freiwillig mit Zeugs rum, > für das sich auch bereits bewährte Alternativen anbieten? Vor allem wenn > letztere sich bereits lange in Entwicklung und damit ziemlich in hohem > Maße gereift sind. Was verstehst du unter bewährte Alternativen? Wenn ich Multithreading nutzen will, nützt es mir nicht viel das es C oder C++ schon so lange gibt. Ich müsste mich da für längere Zeit einarbeiten, bevor ich stabile Software entwickeln kann. Und danach musst du trotzdem immer aufpassen dass du trotz Erfahrung keine Fehler machst. Bei Rust arbeitest du dich auch einmal mühsam in die neuen Konzepte ein aber danach garantiert dir der Compiler dass bestimmte schwerwiegende Fehler ausgeschlossen sind. Onkel Darwin schrieb: > Wo stehen denn z.B. die noch vor gar nicht so langer Zeit gehypten > Sprachen wie go und Nim? > > Man hört Nim-mer viel .. Bevor Python oder Java erfolgreich wurden, gab es auch andere Programmiersprachen die gescheitert sind. Das Sprachen kommen und gehen sagt nicht viel über Rust aus. Was deine konkreten Beispiele angeht: Go wird immer noch genutzt aber kann aus Performance Gründen C++ nicht überall ersetzen. Ich denke es war auch nicht das Ziel damit Sprachen wie C++ in der gesamten Industrie zu ersetzen. Und Nim? Ich hörte davon, aber ich glaube Nim bei weitem nicht so weit wie Rust bisher.
Ob Rust in der Industrie Fuß fassen wird hängt wahrscheinlich doch stark davon ab ob sich die Platzhirsche der Compilertoolfirmen wie IAR & Co. der Sprache annehmen werden und sie unterstützen wollen. Deshalb nehme ich an, daß Rust genau wie andere Sprachen offiziell von den relevanten Standardorganisationen anerkannt werden muß. Letztens hängt Adoption auch von zusätzlicher notwendiger Industrie Bürokratie ab. Der embedded Bereich muß auch besonders berücksichtigt werden. Auch Debugging und Simulation sind wahrscheinlich wichtige Gesichtspunkte. Dazu kommt, daß in vielen Firmen die Entwickler nicht unbedingt durchsetzen können welche Sprachen für Produktentwicklung verwendet werden sollen. Deshalb nehme ich an, daß man geduldig sein werden muß um zu erleben wie sich die Adoption ausspielen wird. Die Inertia der Menschen ist oft der wirkliche Hinderungsgrund warum neue Paradigmen so lange brauchen um Fuß zu fassen. Erschwerend für eine Adoption werden dann manche Kunden auch darauf bestehen ein komplettes Rust Entwicklungspackage wie z.B. IAR Workbench für Rust bestellen zu können wo die praktischen Berücksichtigungen der realen Welt vorhanden sind. Bis dahin wird man schon abwarten müssen. Die Geeks mögen von Rust verzaubert sein, trotzdem fürchte ich, daß gerade das nicht genug ist. OK. Jetzt dürft ihr auf mich hauen wenn ihr könnt:-)
:
Bearbeitet durch User
So, jetzt auch mal meine Meinung zu Rust an sich, nicht das "Ja, du hast geschrieben: dies; ich sage dazu: das!" Prinzipiell finde ich die Idee von Rust sehr gut. Vom Konzept her wäre Rust gut geeignet gerade im Embedded-Bereich auf kleinen Controllern, wo die Projekte ja schon aus Speichergründen nicht unbedingt ausufern, und die Art der Ressourcen-Verwaltung in Rust in ein riesiger Fortschritt. Traits gefallen mir auch, die fördern eine klare Trennung von Daten und Methoden. In der klassischen Objektorientierung, die ja akademisch immer noch so gelehrt wird, sind Daten und Methoden immer brav in einer Klasse verpackt, aber in der Praxis ist das nur noch Ballast (Stichwort "Puppet-Player-Pattern", TDA, OCP). Was mich (das ist natürlich immer Geschmackssache) in vielen Punkten stört, ist die Syntax. Die sieht mir inkonsistent aus. Zum Einen ist es im Zeitalter der großen IDEs (seien es VS xyz, sei es Eclipse) absolut sinnfrei, ein Wörtchen wie "function" abzukürzen. Zum Zweiten, so gut ich es finde, dass Curlys zwangsweise sind (guter Stil in jeder Curly-Sprache heutzutage), kommt dann das Weglassen von runden Klammern wie etwas komplett Gegensätzliches daher und scheint ein gewisses Anbiedern an Python und sonstige Whitespace-Sprachen zu sein. Moderne Programmiersprachen sind nicht mehr auf Tipp-Effizienz, sondern auf klare Syntax ausgelegt UND stören nicht mehr mit künstlichen Störenfrieden wie * und &. C# ist z.B. mindestens so "C"-Style wie Rust, verzichtet aber auf solche Stolpersteine komplett, ebenso auf :, :: und -> außer in unsafe-Bereichen. Moderne Programmiersprachen achten viel mehr auf Lesbarkeit als der olle Kram von "damals, als alles besser war" (eigentlich ja doch schrecklicher). Oder mag wirklich jemand die Sternchen-Orgien in "C" bei Funktionszeigern oder die ollen & und -> in C++? Ein nicht besonders großes, aber hübsches Syntax-Gimmick ist, dass es keinen Unterschied mehr zwischen for- und for-each-Schleifen gibt. Braucht kein Mensch, richtig so. Das konnte schon lange wirklich mal weg! ^^
:
Bearbeitet durch User
Gerhard O. schrieb: > Ob Rust in der Industrie Fuß fassen wird hängt wahrscheinlich doch stark > davon ab ob sich die Platzhirsche der Compilertoolfirmen wie IAR & Co. > der Sprache annehmen werden und sie unterstützen wollen. Und warum sollten sie? Welcher z.B. Industriekunde würde das fordern bzw. kaufen? Solche Modesprachen existieren nur in ganz kleinen Blasen irgendwelcher akademischen Brainfucks und OO-Hipstern die auf jeden Quatsch aufspringen und eine smarte Saftpresse zuhause haben. Gerade die Mitglieder dieser Gruppen verkennen die reale Situation und können anscheinend schlecht einordnen, wie irrelevant Rust im wirklichen Leben, da wo Geld verdient wird, eigentlich ist.
Olaf schrieb: > Er koennte bezueglich Fehler aber auch sehr viel > besser sein wenn er von sehr vielen Leuten verwendet wird die alle zur > Verbesserung beitragen. Finde den Fehler... Es gibt sehr viel Code, der von sehr vielen Leuten verwendet wird. Es gibt aber nur sehr, sehr, sehr wenig Code, der von sehr vielen Leuten verwendet wird, die da auch alle zur Verbesserung beitragen. Und die Frage, ob mehr Fehler in wenig genutzer Software besser sind, als wenige in viel genutzer, dürfte noch nicht endgültig ausdiskutiert sein. Oliver
Cyblord -. schrieb: > Gerade die Mitglieder dieser Gruppen verkennen die reale Situation und > können anscheinend schlecht einordnen, wie irrelevant Rust im wirklichen > Leben, da wo Geld verdient wird, eigentlich ist. Da ist was dran, aber ich sage bewusst: leider. Wenn man sich die ganze Smart-Home-Szene ansieht, wo es sicher bald schon für Klospülungen ne App gibt (kennt noch wer diesen unsäglichen Werbespruch von Apple? "Ach, dafür gibt's doch bestimmt auch ne App!"), und wenn man das dann mal auf den Automotive-Bereich abstrahiert, dann Herzlichen Glückwunsch! Das ist so ein bisschen wie in der alten Zeit mit Dampfloks: "Was labern die da über Elektrifizierung! Ich steh hier mit 1000 Tonnen am Haken an der Steigung, und die Räder drehen durch!" Ob es nun Rust wird oder ne andere Sprache mit zeitgemäßen Konzepten, ist mir relativ. Andererseits bin ich faul, und wenn ich die Wahl zwischen Rust und Python haben müsste, würde ich eher Rust nehmen, weil sie mir vertrauter aussieht aka schneller vom Lernen zur Produktion. Ich bin (anders als andere hier) kein Fanboy, aber alleine schon das Ressourcen-Konzept ist ne bedenkenswerte Sache. Das Argument "das hilft mir doch aber jetzt nicht!" ist ein Zeichen von mangelnder Planung und vor allem von einer Mischung aus zu vielen Aufträgen und zu niedrigen Stunden-/Projektpreisen. Und ja, ich weiß, wie knifflig bis unmöglich es ist, ner Kundin beizubiegen, dass sie auch was davon hat, wenn wir verlässlicheren Code schreiben, der gleich beim ersten Release einigermaßen stabil läuft. (Bevor mich wer disst: Unternehmen sind meist "Gellschaften" (GmbH, AG...), drum "sie".)
:
Bearbeitet durch User
Cyblord -. schrieb: > Gerhard O. schrieb: >> Ob Rust in der Industrie Fuß fassen wird hängt wahrscheinlich doch stark >> davon ab ob sich die Platzhirsche der Compilertoolfirmen wie IAR & Co. >> der Sprache annehmen werden und sie unterstützen wollen. > > Und warum sollten sie? Welcher z.B. Industriekunde würde das fordern > bzw. kaufen? > Solche Modesprachen existieren nur in ganz kleinen Blasen irgendwelcher > akademischen Brainfucks und OO-Hipstern die auf jeden Quatsch > aufspringen und eine smarte Saftpresse zuhause haben. > > Gerade die Mitglieder dieser Gruppen verkennen die reale Situation und > können anscheinend schlecht einordnen, wie irrelevant Rust im wirklichen > Leben, da wo Geld verdient wird, eigentlich ist. Das sehe ich möglicherweise positiver als Du. Ich bin der Meinung, daß man Rust fairerweise einfach Zeit lassen muß um Fuß fassen zu können. Das geht deshalb nicht so schnell weil noch viele Erfahrungen in der realen Welt gesammelt werden müssen. Um im weiteren Bereich verwendet zu werden ist Standard Adoptierung hier absolut notwendig; geht aber nicht so schnell. Bis dahin werde ich mit Interesse die Entwicklung mit offenen Augen verfolgen. Bei C und C++ war es auch nicht viel anders.
Carsten P. schrieb: > Und ja, ich weiß, > wie knifflig bis unmöglich es ist, ner Kundin beizubiegen, dass sie auch > was davon hat, wenn wir verlässlicheren Code schreiben, der gleich beim > ersten Release einigermaßen stabil läuft. Was der zwar zunächst Geld spart, das die dann später doppelt wieder ausgibt, wenn der ganze Kram wegen Unwartbarkeit auf Grund einer Exotenprogrammiersprache in die Tonne gekloppt werden muß. Ich will jetzt nicht sagen, daß Rust dieses Schicksal droht, aber es ist noch nicht übern Berg. Oliver
Gehört nicht unbedingt zum Thema und ist O.T., aber hier ist noch ein allgemeiner Aspekt der mir Sorgen macht: Wegen der Komplexität und Device Intercommunication moderner verbundener Anwendungen werden sehr oft Teile der Anwendung mit eingebunden komplexen externen Ressourcen verwendet die nicht immer im Quellenformat zur Überprüfung erhältlich sind. Oft müssen BT, WLAN und Ähnliches funktionieren weil die Kunden alles über Smartphone und Internet steuern wollen. Erschwerend kommt dazu, daß nicht alle Programmierer Genies sind und man sich schwer tut Probleme oder Sicherheitslücken zu erkennen bzw. Diagnostizieren zu können. Wenn das tatsächlich so ist, dann ist Produktentwicklung fast immer ein riskante Sache und die Sprache vielleicht nur sekundär wichtig. Auch wenn Rust z.B. schwerer durch böswillige Elemente zu hintergehen ist, können die eingebundenen extern entwickelten Ressourcen alle durch die Sprache gegebene Robustheit wieder total zunichte machen. Um bessere externe Sicherheit zu erzielen müssten die Probleme an der Wurzel angefasst werden. Ob man dann in C++ oder Rust programmiert ist so gesehen nicht mehr so wichtig. Was notwendig ist, externe Stacks zu finden, die robust genug sind, Attacken gehörig zu erschweren. Wie man den Rest der Anwendung kodiert ist dann nicht mehr so kritisch wenn man nicht gerade groben Unfug macht. Ob ich hier mit meinen Ausführungen etwas angeschnitten habe was wichtig ist, kann ich praktisch nicht so gut beurteilen weil ich in Sachen "Verbundenheit" nicht viel mache und ihr müsst es wahrscheinlich besser wissen wie man sichere verbundene Apps und Geräte realisiert. Noch am Rande, man sieht in den Medien und Reklame immer öfters wie man Smartphones zur Bedienung, Öffnung der Autoschlösser usw. anpreist. Ehrlich gesagt mir wäre es zu blöd jedesmal ein Handy suchen und bedienen zu müssen um in mein Auto einsteigen zu können. Es mag sich zwar sexy ansehen, aber irgendwie finde ich ist dieser ganze Trend überzogen. Ein Handy mag in gewissen Situationen auf diese Weise nützlich sein, aber nicht um jeden Preis alles vernetzen zu wollen. Gerade diese Sachen verursachen die meisten Sicherheitslücken.
Carsten P. schrieb: > kommt dann das Weglassen von > runden Klammern wie etwas komplett Gegensätzliches daher Du kannst ja runde Klammern nutzen, wenn du das möchtest. Der Rust-Compiler hindert dich nicht daran. Du musst nur die Warnung abschalten. Eine Zeile in der compiler-config.
Syntax hat man schnell gelernt. Man schaut einmal auf ein Script, dann kennt man die Syntax. Das selbe einfach mit anderen Klammern / Keywords schreiben, das ist einfach. Aber plötzlich ändern müssen, wie man ein Programm schreibt, die Herangehensweise ändern müssen, und plötzlich gewisse Sachen nicht mehr so lösen zu können, wie man das immer überall sonst gemacht hat - das ist nicht einfach. C -> Python ist ersteres. C -> Rust ist letzteres. Beim Umstieg zu Rust kommt noch dazu, oft weiss man, das ist in Ordnung, aber dann sollte man das eigentlich auch noch dem Compiler beweisen. Da fängt dann wahre Frustration an. Ich und der Compiler - wir haben beide starke Meinungen, wie wir das lieber umgesetzt sehen wollen...
🐧 DPA 🐧 schrieb: > Ich und der Compiler - wir haben beide starke Meinungen, > wie wir das lieber umgesetzt sehen wollen... Das ist jetzt nicht böse gemeint, eher als "frohes neues Jahr"... Dann schreib dir doch deinen eigenen Compiler! ;-)
MaWin schrieb: > Carsten P. schrieb: >> kommt dann das Weglassen von >> runden Klammern wie etwas komplett Gegensätzliches daher > > Du kannst ja runde Klammern nutzen, wenn du das möchtest. Der > Rust-Compiler hindert dich nicht daran. Du musst nur die Warnung > abschalten. Eine Zeile in der compiler-config. Gut zu wissen. Ist echt mal ein Thema zum sich näher mit beschäftigen, und die nächsten Tage finde ich immer wieder mal ein bisschen Leerlauf. Nennt sich "nicht existenter Urlaub", aber das Thema interessiert mich jetzt echt. Frage an dich Fachperson: Wenn ich eine Rust-Lib "von woanders" aufrufen will, dann genauso wie ne C/C++-Lib?
> Dazu kommt, daß in vielen Firmen die Entwickler nicht unbedingt > durchsetzen können welche Sprachen für Produktentwicklung verwendet > werden sollen. Ich sehe du hast Industrieerfahrung. .-) Wenn man die Frage aus dem Subject beantworten moechte dann sollte man sich vielleicht mal fragen wie kam es im Embeddedbereich zu dieser EXTREMEN C Dominanz. Irgendwie war die Sprache irgendwann da, irgendwie hat sie jeder verwendet und keiner hat es je diskutiert. Das hat mich auch immer gewundert. Und noch erstaunlicher, C ist da mittlerweile seit 20Jahren dominant. Da kam noch nie jemand der Gedanke das man was anderes verwenden koennte. Das ist vollkommen anders als auf dem PC. Daher denke ich das Rust und jede andere Sprache zumindest im Embeddedbereich eine lustige Modeerscheinung bleiben wird. Aehnlich wie FORTH oder Pearl. Es ist einfach so das die ganze Industrie extrem konservativ ist. Ich bin mir sicher das wir noch die 100Jahrfeier von 4-20mA und C erleben werden. :-D Olaf
Carsten P. schrieb: > Frage an dich Fachperson: Wenn ich eine Rust-Lib "von woanders" aufrufen > will, dann genauso wie ne C/C++-Lib? Du kannst in Rust Symbole und Strukturen mit C-Layout und C-Linkage anlegen. Wenn es das ist, was du meinst.
Olaf schrieb: > Pearl Meinst du Perl? Das wird leider sehr massiv in der Embedded-Entwicklung verwendet. Aber ich denke bei Perl haben mittlerweile viele Leute verstanden, dass es nicht mehr zeitgemäß ist. Sogar die Perl-Entwickler scheinen das wohl verstanden zu haben und bauen die Sprache nun nach modernen Mustern um. > Ich bin mir sicher das wir noch die 100Jahrfeier von > 4-20mA und C erleben werden. :-D Ja, da bin ich mir leider auch sicher.
Gerhard O. schrieb: > Gehört nicht unbedingt zum Thema und ist O.T., aber hier ist noch ein > allgemeiner Aspekt der mir Sorgen macht: > > Wegen der Komplexität und Device Intercommunication moderner verbundener > Anwendungen werden sehr oft Teile der Anwendung mit eingebunden > komplexen externen Ressourcen verwendet die nicht immer im Quellenformat > zur Überprüfung erhältlich sind. Im Ernst, Gerhard, wenn das OT ist, ist das ganze Forum OT. Es gibt derzeit wohl kaum ein überall heißer diskutiertes Thema in der ganzen IT-Branche als genau das da! Deswegen verbaue ich nirgendwo auch nur zwei Devices ("Dinge" im Sinne von IoT), ohne dass ich einen Knoten dazwischen habe, der die Kisten überwacht. Bei uns ist es geschäftlich und bei mir ist es privat auch so, dass kein Teil verwendet wird, das fröhlich über http oder noch tiefer im Layer unverschlüsselte Daten in die Welt posaunen darf, es sei denn, es sitzt zB wie ein einfacher Sensor so nah am nächsten Knoten, den wir wieder unter Kontrolle haben, dass du schon die Leitung anritzen müsstest, um da was abzugreifen. Ich konstruiere mal ein gar nicht so fiktives Beispiel: Du bist ein Einbrecher. Du hast die nötige technische (durchaus legal beschaffbare und auch nicht großartig aufs Konto schlagende) Hardware. Du willst natürlich wissen, wann wer zuhause ist. Das ganze Zuhause der Leute, die du ausrauben willst, ist natürlich super "smart" (eigentlich steindoof). Das Licht wird geschaltet, etwa im Flur, über gaaaanz smarte, übers WLAN angeschlossene Lichtschalter. Ja, die Daten sind verschlüsselt, die Hersteller sind ja nicht ganz bekloppt. Nur haben sie was vergessen. Also hältst du deine WLAN-Antenne da aufs Haus, fischst die Pakete ab, und stellst fest, dass OIZ324867yyxdf "Aus" bedeutet und 6jhgbsd76345r4 "Ein". Klingt harmlos. Nun stellst du auch fest, weil die Alarmanlage vom selben Hersteller und auch übers WLAN ("dafür gibt's doch bestimmt ne App!") läuft, dass 9786dfkjhTX&% "Alarm ein" und PIUz876r54gh "Alarm aus" bedeuten. Jetzt kannst du ja mal probieren, mit derselben IP (weil du natürlich im Promisk-Modus gelauscht hast) das Signal "Lampe ein" zu schicken". Wenn das geht, könnte ja vielleicht auch "Alarm aus" funktionieren. Da musst du überhaupt nicht wissen, was die Daten wirklich bedeuten. Der Trick ist übrigens schon weit verbreitet bei Auto-Dieben, die einfach das Signal des Funk-Schlüssels aufzeichnen und wiedergeben. Würde der entsprechende Coder auf die Idee gekommen sein, einen Timestamp mit zu verschlüsseln, wäre das alles hinfällig. Aber wie man weiß, ist dem nicht so. Vielleicht, weil er nicht weit genug denkt, vielleicht aber auch, weil sein Chef im gesagt hat, dass bei 100.000 gebauten Autos 10 Cent für den uC schon seinen Bonus ausmachen. Stromzähler sind übrigens für so eine Schwachstelle bereits vom CCC und anderen aufmerksamen Leuten ausgemacht. Die senden gerne den Zählerstand ans EVU, und mit ein paar gar nicht so geheimen Tricks kriegt man von außen raus, wann der Stromverbrauch hoch und wann niedrig ist. Angenommen, bei entsprechenden Stückzahlen kosten ein AtTiny45 45 und ein AtMega328 328 Cent. Da kannst du dir ja vorstellen, was der Controller beim Kunden sagt, wenn du mit Datensicherheit anfängst, während der an den Bonus denkt.
:
Bearbeitet durch User
Carsten P. schrieb: > Der Trick ist übrigens schon weit verbreitet bei > Auto-Dieben, die einfach das Signal des Funk-Schlüssels aufzeichnen und > wiedergeben. Replay-Attacks funktionieren seit 20 Jahren nicht mehr bei Autoschlüsseln und bei allen anderen Arten von Crypto-Funkschaltern. Und es ist hier völlig Off-Topic.
MaWin schrieb: > Carsten P. schrieb: >> Frage an dich Fachperson: Wenn ich eine Rust-Lib "von woanders" aufrufen >> will, dann genauso wie ne C/C++-Lib? > > Du kannst in Rust Symbole und Strukturen mit C-Layout und C-Linkage > anlegen. Wenn es das ist, was du meinst. Ja, genau, das meinte ich, also so, dass ich sie von außen mit anderen Sprachen aufrufen kann wie ne "C"-Lib.
Olaf schrieb: > Und noch erstaunlicher, C ist da mittlerweile seit 20Jahren dominant. 1) Es gibt C-Compiler für jedes Target. 2) Es ist kein Problem, C-Entwickler zu finden. 3) C ist relativ einfach. Der dritte Punkt ist insofern relevant, als daß das eigentliche Coding oftmals nur ein kleiner Teil der Arbeit ist, für den man nicht extra einen Coding-Spezialisten einstellen würde, den man aber für eine komplizierte Sprache bräuchte.
MaWin schrieb: > Carsten P. schrieb: >> Der Trick ist übrigens schon weit verbreitet bei >> Auto-Dieben, die einfach das Signal des Funk-Schlüssels aufzeichnen und >> wiedergeben. > > Replay-Attacks funktionieren seit 20 Jahren nicht mehr bei > Autoschlüsseln und bei allen anderen Arten von Crypto-Funkschaltern. Komisch, dass die Mediatheken voll davon sind, und die sind damals, vor 20 Jahren, natürlich deswegen mit ner 16:9 Arri aufgenommen worden, als noch niemand an HD dachte, damit es heute authentisch wirkt... ^^ So viele kluge Sachen du manchmal schreibst, MaWin, manchmal schießt du deiner Glaubwürdigkeit selbst ins Knie ;-)
Nop schrieb: > 3) C ist relativ einfach. Definiere "relativ" ^^ Wir wissen alle, dass das totaler Quatsch ist. Aus Sicht eines BWLers vielleicht. Aber technisch gesehen ist blankes "C" genauso "einfach" wie Assembler. Wenn du schonmal ernsthafte (das heißt kommerziell in großen Stückzahlen verwendete und sicherheitstechnisch relevante) Software entwickelt als mit einem Nicht-Coder als Vorgesetztem, Kunden oder whatnot, weißt du, wie schnell aus der mal eben hin geschnodderten "Machbarkeitsstudie" ein Denkmal wird, das nicht mehr gemeißelt, sondern nur noch angemalt wird. Ich jedenfalls erinnere mich sehr gut daran, dass ich vor uff... knapp 30 Jahren? meinem damaligen Chef zeigte, wie man von nem PERL-Script im Sekunden-Takt Texte an nen Webbrowser (der hieß damals noch Netscape Navigator) schickt, bis er verstanden hatte, dass man daraus nen Chat bauen könnte, und der musste dann natürlich in ner Woche fertig sein. Sowas wie ne Anmeldung (ohne E-Mail-Prüfung, keine Zeit) hab ich dann nach Feierabend dazu gecodet. Das Ding ist weit gewachsen, aber an echte Sicherheit, also echte Authentifizierung hat damals keine Sau gedacht. Und die Fehler in dem hin gerotzten Code wurden natürlich gnadenlos aufgedeckt. Aber selbst dann fand mein Chef, nö, das tut's, das bringt Geld, keine Zeit, weiter zum nächsten Projekt. Heute sind manche Chefs anders und sensibler für solche Themen. Aber eben nicht alle, und genau da entstehen die @MaWin "irgendwelchen Scheunentore".
Nop schrieb: > Der dritte Punkt ist insofern relevant, als daß das eigentliche Coding > oftmals nur ein kleiner Teil der Arbeit ist, für den man nicht extra > einen Coding-Spezialisten einstellen würde, den man aber für eine > komplizierte Sprache bräuchte. Das ist richtig. Jedoch ist das Debugging in C relativ kompliziert. Rust dreht das herum. Das Coden ist etwas schwieriger. Dafür ist das Debugging aber deutlich einfacher und beschränkt sich nur noch auf logische Fehler. It works, if it compiles. Das ist zwar natürlich etwas überspitzt ausgedrückt, aber es steckt doch ein großer Teil Wahrheit drin. Deshalb macht außerdem auch deutlich mehr Spaß.
Olaf schrieb: > Und noch erstaunlicher, C ist da mittlerweile seit 20Jahren dominant. Da > kam noch nie jemand der Gedanke das man was anderes verwenden koennte. Davor wurden Controller halt vorrangig in Assembler programmiert. C war da schon mal eine mächtige Verbesserung, weil man mit vergleichsweise geringen Einbußen an Laufzeiteffizienz eine drastische Verbesserung der Coding-Effizienz erzielen kann und (auch wenn hier alle über C dahingehend unken) ganz gewiss auch eine drastische Verbesserung der Sicherheit. Wer sich (durchaus zu Recht) über die Sicherheitslücken beklagt, die mit C möglich sind, der sollte sich einfach mal vergegenwärtigen, wie das alles mit Assemblercode aussähe. ;-) Nun wiederum, einen einmal etablierten Platzhirsch zu vertreiben, ist keine so leichte Aufgabe. So groß dürfte der Leidensdruck, C an dieser Stelle abzulösen, bei vielen Programmierern im Embedded-Bereich *) nicht sein. Gerhard hat ja viele Punkte genannt. Die Verheiratung einer Sprache mit einem eigenen Buildsystem dürfte einem solchen Ansinnen auch nicht gerade förderlich sein. *) Ich meine hier mit "Embedded" nicht so'n Highlevel-Kram wie Smartphone & Co. Alles, was mit einem fetten Betriebssystem daher kommt, ist in dieser Hinsicht ja eher PC-mäßig. Ich meine den wirklichen Lowlevel-Kram, der bis vor 30 Jahren komplett in Assembler war (8051 waren die ersten, bei denen dann jemand mit Compilern angetreten war).
MaWin schrieb: > Das ist richtig. Jedoch ist das Debugging in C relativ kompliziert. Kann ich nicht bestätigen. Zumal man embedded sowieso noch nen MISRA-Checker drüberlaufen läßt, womit etliche Konstrukte angemeckert werden, die gerne verkehrt gemacht werden. Da man embedded auch etliche Sachen meistens schlichtweg nicht benutzt, wie z.B. dynamische Speicherallozierung, sind die damit einhergehenden Fehler natürlich auch ausgeschlossen.
Nop schrieb: > Kann ich nicht bestätigen. Hast du schon einmal Rust probiert um einen Vergleich zu bekommen? > Zumal man embedded sowieso noch nen > MISRA-Checker drüberlaufen läßt, womit etliche Konstrukte angemeckert > werden, die gerne verkehrt gemacht werden. Und jetzt stelle dir Rust wie einen Misra-Checker auf Steroiden vor. Der deutlich mehr Dinge prüft, weil sie erst durch die Sprache Rust prüfbar werden. Der dir auch noch Vorschläge macht, wie du die Warnungen und Fehler beheben kannst. Meistens stimmen die Vorschläge auch, oder sie lenken einen wenigstens eindeutig auf die richtige Lösung hin. > dynamische Speicherallozierung, sind die damit einhergehenden > Fehler natürlich auch ausgeschlossen. Dynamische Speicherverwaltung ist nur ein winziger Teil der Dinge, die Rust deutlich besser beherrscht als C (und auch besser als C++. Double-Free/Use-after-free ist in Rust nicht möglich). Außerdem gelten die Rust Speicherkonzepte auch für statische Allokation und Stackallokation.
Carsten P. schrieb: >> Replay-Attacks funktionieren seit 20 Jahren nicht mehr bei >> Autoschlüsseln und bei allen anderen Arten von Crypto-Funkschaltern. > > Komisch, dass die Mediatheken voll davon sind, Bei Crypto-Funkschaltern mag das so sein. Der Angriff auf Autos funktioniert ganz anders. Und weil das tatsächlich seit Jahren duch alle Mediakanäle getrieben wurde, sollte das jeder problemlos auseinander halten können. Oliver
Jörg W. schrieb: > Die Verheiratung einer Sprache mit einem eigenen Buildsystem Das ist, wie mehrfach schon gesagt, nicht wahr. Du kannst Rust ohne weiteres und insbesondere im Embedded-Bereich auch mit Make oder jedem anderen Tool verwenden.
MaWin schrieb: > Double-Free/Use-after-free ist in Rust nicht möglich). Solche checks sind ja toll. Genauso wie das Prüfen von Arraygrenzen. Das benötigt aber Code zur Laufzeit. Den kann auch Rust nicht wegzaubern. D.h. da läuft dann ständig irgendwelcher Code für JEDEN Arrayzugriff und es müssen ständig Datenstrukturen im Speicher mitgeführt werden, um solche Dinge abfangen zu können. In der System- und Embedded-Entwicklung will und kann man das aber meistens nicht.
:
Bearbeitet durch User
MaWin schrieb: > Hast du schon einmal Rust probiert um einen Vergleich zu bekommen? Ich habe keine speziellen Debugging-Probleme in C festgestellt, die überhaupt einer Lösung bedürften. Wenn, dann klemmt es algorithmisch, aber das wäre in jeder programmiersprache so. > Und jetzt stelle dir Rust wie einen Misra-Checker auf Steroiden vor. Schön, aber der Leidensdruck ist schlichtweg nicht da. Wozu eine deutlich kompliziertere Sprache, wenn es das angebliche Horrordebugging in C tatsächlich nicht gibt?
Cyblord -. schrieb: >> Double-Free/Use-after-free ist in Rust nicht möglich). > Solche checks sind ja toll. Genauso wie das Prüfen von Arraygrenzen. Das > benötigt aber Code zur Laufzeit. Nein, benötigt es nicht. Das prüfen von Allokationen passiert komplett zur Compilezeit und das Prüfen von Arraygrenzen auch zu einem sehr großen Teil. > D.h. da läuft dann ständig irgendwelcher Code für JEDEN Arrayzugriff Nein. Wenn der Array-Index nicht beliebig sein kann, dann wird das zur Compilezeit aufgelöst. Außerdem braucht man in Rust deutlich seltener Arrays, als in C. Mit Rust-Enums zum Beispiel kann man viele Dinge tun, die man in C mit C-Enums und Arrays machen würde. > und es müssen ständig Datenstrukturen im Speicher mitgeführt werden Ständig nicht. Aber teilweise natürlich schon. Ein Slice ist zum Beispiel ein Zeiger und eine Länge. Aber das ist in C auch nicht anders. An den Stellen, wo du in Rust ein Slice verwendest, würdest du in C einen Pointer und ein Längen-Integer manuell mitschleppen. Rust hat hier praktisch keinen Laufzeitnachteil gegenüber C.
Nop schrieb: > Schön, aber der Leidensdruck ist schlichtweg nicht da. Wozu eine > deutlich kompliziertere Sprache, wenn es das angebliche Horrordebugging > in C tatsächlich nicht gibt? Ja, dann ist doch alles gut. Niemand zwingt dich.
MaWin schrieb: > Nein, benötigt es nicht. > Das prüfen von Allokationen passiert komplett zur Compilezeit und das > Prüfen von Arraygrenzen auch zu einem sehr großen Teil. Ahso alles zur Compilezeit. Also wenn es dynamische Allokation gibt, dann muss man auch Grenzen zur Laufzeit prüfen. > Wenn der Array-Index nicht beliebig sein kann, dann wird das zur > Compilezeit aufgelöst. Und wenn deine Tante Eier hätte wäre sie dein Onkel. Der konkrete Index kann jederzeit von einer Eingabe zur Laufzeit abhängen. > Rust hat hier praktisch keinen Laufzeitnachteil gegenüber C. Jaja bla blubb. Erzähls deinen Hipster-Freunden. Es gibt nur zwei Möglichkeiten: Entweder du kannst relativ ungestört direkt in den Speicher reingreifen oder jeder Fetzen Speicher ist abgesichert, was aber Datenstrukturen und Code braucht, der Checks ausführt. Das kann man nicht wegdiskutieren.
:
Bearbeitet durch User
Cyblord -. schrieb: > Und wenn deine Tante Eier hätte wäre sie dein Onkel. Der konkrete Index > kann jederzeit von einer Eingabe zur Laufzeit abhängen. Praktisches Beispiel: eine for-Schleife über alle Deine Temperatursensoren, deren Werte in einem Array stecken. Da kann der Compiler durchaus statisch ermitteln, ob das Array mit ausreichender Größe deklariert ist.
Nop schrieb: > Cyblord -. schrieb: > >> Und wenn deine Tante Eier hätte wäre sie dein Onkel. Der konkrete Index >> kann jederzeit von einer Eingabe zur Laufzeit abhängen. > > Praktisches Beispiel: eine for-Schleife über alle Deine > Temperatursensoren, deren Werte in einem Array stecken. Da kann der > Compiler durchaus statisch ermitteln, ob das Array mit ausreichender > Größe deklariert ist. Das kann jedes PCLINT finden. Was bringt ein statisches Beispiel? Ein einziges dynamisches Beispiel und du brauchst den Check zur Laufzeit. Deshalb ist diese Sicherheit eben kein Verdienst von Rust, sondern muss in jedem Fall erkauft werden. Die Sprachdefinition und die möglichen Checks zur Compilezeit sind Kindergarten. Statische Codeanalyse wurde schon vor ner Weile erfunden.
:
Bearbeitet durch User
Cyblord -. schrieb: > Das kann jedes PCLINT finden. Aber nicht, wenn Du das Array als Parameter einer Funktion übergibst, womöglich noch in einer anderen TU, weil es in C dann zu einem Pointer ohne Längeninformation verflacht.
Nop schrieb: > Cyblord -. schrieb: > >> Das kann jedes PCLINT finden. > > Aber nicht, wenn Du das Array als Parameter einer Funktion übergibst, Doch ganz sicher. > womöglich noch in einer anderen TU, weil es in C dann zu einem Pointer > ohne Längeninformation verflacht. Ja und wie sieht dein statischer Check aus, wenn ich einen Index über UART empfange?
Wobei es natürlich bessere statische Code-Checker für C gibt, die auch interprozedurale Analyse können - aber PC-Lint speziell kann es halt nicht.
Cyblord -. schrieb: > Also wenn es dynamische Allokation gibt, > dann muss man auch Grenzen zur Laufzeit prüfen. Ja. Genau wie in C. > Der konkrete Index > kann jederzeit von einer Eingabe zur Laufzeit abhängen. In dem Fall musst du das in C auch prüfen. > Das kann man nicht wegdiskutieren. Ja, doch. Rust ist halt sehr viel ausdrucksreicher als C. Die Enums habe ich ja bereits genannt. Die sind halt zur Compilezeit komplett prüfbar. Man kann in Rust halt Dinge ausdrücken, die in C gar nicht möglich sind. Und wenn es dann wirklich diese eine Stelle gibt, die sooooooooooo performancekritisch ist und es dort auch gar nicht möglich ist das in Rust zu formulieren ohne Performanceoverhead, dann hat man immer noch die Möglichkeit von Unsafe-Rust. Da kannst du dich nach Herzenslust mit ungeprüfter C-Pointerarithmetik austoben. Aber es kommt praktisch nicht vor, dass das notwendig ist, weil man eigentlich alles in Rust performant ausdrücken kann. Performance ist ein Designziel von Rust! > Jaja bla blubb. Erzähls deinen Hipster-Freunden. Mit dem Argument hast du mich jetzt natürlich überzeugt ;)
Nop schrieb: > Wobei es natürlich bessere statische Code-Checker für C gibt, die auch > interprozedurale Analyse können - aber PC-Lint speziell kann es halt > nicht. Ja dann nimmst Klocwork. Rust brauch ich dafür immer noch nicht. Und wie dynamische Indizes ohne zusätzlichen Code und Daten geprüft werden kannst du sicher aufzeigen.
MaWin schrieb: > In dem Fall musst du das in C auch prüfen. Nein, ich KANN. Ich muss aber nicht. Vor allem wird kein Zwangsweise Code erzeugt der das prüft.
Nop schrieb: > Praktisches Beispiel: eine for-Schleife über alle Deine > Temperatursensoren, deren Werte in einem Array stecken. Da kann der > Compiler durchaus statisch ermitteln, ob das Array mit ausreichender > Größe deklariert ist. Ja, sogar in C geht das meistens. In Rust geht es aber öfter, weil Arrays vernünftig typisiert sind und nicht so ein Unfug mit Array-Pointer-Decay gemacht wird.
Cyblord -. schrieb: > Ja und wie sieht dein statischer Check aus, wenn ich einen Index über > UART empfange? Es gibt ihn nicht. Genauso wenig, wie es ihn in C gibt.
MaWin schrieb: > In Rust geht es aber öfter, weil Arrays vernünftig typisiert sind und > nicht so ein Unfug mit Array-Pointer-Decay gemacht wird. Dann kann Rust wohl keine Objekte/Strukturen serialisieren? Oder wie wandle ich sowas in ein Byte-Array um es z.B. über einen UART zu senden? Kann Rust beim Deserialisieren (Empfang über UART) prüfen ob das Objekt den korrekten Typ hat? Und das auch noch ohne zusätzlichen Speicher?
Cyblord -. schrieb: > Nein, ich KANN. Ich muss aber nicht. Ja, genau. Das ist ja das Problem. > Vor allem wird kein Zwangsweise Code erzeugt der das prüft. In Unsafe-Rust kannst du auch ungeprüfte Zugriffe verwenden, wenn du unbedingt scharf auf Sicherheitslücken bist.
Cyblord -. schrieb: > Dann kann Rust wohl keine Objekte/Strukturen serialisieren? Wie kommst du jetzt darauf? https://crates.io/crates/serde
MaWin O. schrieb: > In Unsafe-Rust kannst du auch ungeprüfte Zugriffe verwenden, wenn du > unbedingt scharf auf Sicherheitslücken bist. Tja in C will man eben relativ viel Freiheit mit einigermaßen ordentlichen Datentypen, Strukturen und Kontrollmechanismen. Wer das nicht will, nimmt C#, Java oder halt Rust. Nur kommen diese ganzen Checks eben nicht ohne Code und Daten zur Laufzeit aus. Darum geht es mir. Es ist nicht die tolle Sprache die irgendwas sicher macht, sondern die Unmengen an automatisch erzeugtem Code. Deshalb wird es C nicht ablösen. Weil man genau deshalb C verwendet um das nicht zu haben. Es gab schon genug Versuche mit Java auf Embedded. Und viele ähnliche Scherze. Am Ende ist das alles nur viel aufgeblasener Code um ein paar Zeilen produktiv Code in einem sicheren Setting zu schreiben.
Cyblord -. schrieb: > Es gab schon genug Versuche mit Java auf Embedded. Das Problem dabei war doch wohl vielmehr der GC, und den hat Rust nicht. Das Problem von Rust ist IMO eher, daß es zu kompliziert ist - und wenn die Leute, die embedded C verwenden, bislang eine kompliziertere Sprache gewollt hätten, dann hätten sie schon längst auf C++ umgestellt. Insofern ist Rust eher ein potentieller Ersatz für C++, nicht für C.
MaWin O. schrieb: >> Dann kann Rust wohl keine Objekte/Strukturen serialisieren? > > Wie kommst du jetzt darauf? > > https://crates.io/crates/serde Natürlich bietet Rust diese Funktionalität, aber der Punkt ist, wenn du ein Objekt in einen Bytestrom verwandelst, dann hast du auch keine Sicherheit mehr. Außer du baust mit zusätzlichen Daten wieder was drum rum. Nichts anderes passiert in C wenn man direkt in den Speicher einer Struktur oder eines Arrays reingreift. Und manchmal muss man das eben, z.B. mit angesprochenen Fall um das über UART zu senden.
Cyblord -. schrieb: > Nur kommen diese ganzen Checks eben nicht ohne Code und Daten zur > Laufzeit aus. Darum geht es mir. Ja. Darum geht es dir. Es ist aber falsch.
Cyblord -. schrieb: > Nichts anderes passiert in C Schön, dass du es doch noch eingesehen hast. Rust ist in diesem Aspekt nicht langsamer als C.
MaWin O. schrieb: > Cyblord -. schrieb: >> Nur kommen diese ganzen Checks eben nicht ohne Code und Daten zur >> Laufzeit aus. Darum geht es mir. > > Ja. Darum geht es dir. > > Es ist aber falsch. Dann zeig auf, wie ein dynamischer Index ohne Laufzeit und Daten von Rust geprüft wird. Minimalbeispiel:
1 | int a[100]; |
2 | int x=receiveUART(); |
3 | int d=a[x]; |
MaWin O. schrieb: > Rust ist in diesem Aspekt nicht langsamer als C. Dann kann Rust in diesem Aspekt auch nicht sicherer sein. Laufzeitchecks gibt es nicht umsonst. Kann es nicht geben.
:
Bearbeitet durch User
Wenn du z.B. ein Array a[n] und eins b[m] hast, und dann eins c[n+m], musst du nicht wissen, was n und m sind, um zu wissen, dass c[0:n] und c[n:m] darin liegen. Wenn du das für c[i] wissen willst, und du weist nichts über i (z.B. user gibt es ein) muss gecheckt werden ob es platz hat. Aber das muss man dann auch in c. Man braucht nur genug Metadaten beim Kompilieren.
Cyblord -. schrieb: > In der System- und Embedded-Entwicklung will und kann man das aber > meistens nicht. Ich lese mich ja gerade in Rust ein wenig ein, weil ich mir die Zeit dafür nehme. Erstens ist es natürlich mit nem (verschmerzenswerten) Overhead (das meiste passiert zur Compile-Zeit) verbunden, aber meine Antwort auf deine Aussage lautet unabhängig von der Programmiersprache: Wer das nicht WILL, wird irgendwann (sehr bald) den Bach runter gehen. Embedded ist nicht Zuse in der Neuzeit. Die Anforderungen gerade im Embedded-Bereich sind Sicherheit, Sicherheit, und bevor ich es vergesse: Sicherheit! Es liegt natürlich an deinem Naturelle, ob du damit leben kannst, dass dein Auftraggeber nach ein paar Toten und Schwerverletzten wegen einer falschen Programmierung von Airbags zigtausend Autos in die Werkstatt zurück rufen musst. Wenn du schlau warst, hast du jede Haftung ausgeschlossen im Vertrag... Wessen Maxime in diesem Bereich nur billig, billig! uuuund billig! ist, wird sich eher früher als später wundern, wenn er mit Klagen überrissen wird. Diese "ich weiß schon, was ich mache"-Attitüde ist einfach Mist. Ein Embedded-Coder hier, der seinen kompletten Code mit Unit-Tests überzieht? Test-driven? Clean Code anyone? Im Ernst, wenn die Produkte weiter nur auf billig, billig gebaut werden, darf sich niemand wundern, wenn die genauso miesen, aber nur halb so teuren Sachen aus China den Markt dumpen.
Cyblord -. schrieb: > Minimalbeispiel: > >
1 | > int a[100]; |
2 | > int x=receiveUART(); |
3 | > int d=a[x]; |
4 | >
|
Du prüfst also nicht, ob x > 100 ist? Oh, wow, ich hoffe, du programmierst keine Airbags... Achso, es ging um Rust. Jepp, das kriegt Rust hin, zur Übersetzungszeit bereits, weil es den Rückgabewert von receiveUART() prüft und dann feststellt, ob er die Array-Grenze überschreiten kann. Das könnte ein entsprechender "C"-Compiler aber auch, so ne Schlampigkeit feststellen ^^
:
Bearbeitet durch User
Carsten P. schrieb: > Du prüfst also nicht, ob x > 100 ist? Es ging ja darum dass Rust dies anscheinend ohne Overhead automatisch prüft. > Achso, es ging um Rust. Jepp, das kriegt > Rust hin, zur Übersetzungszeit bereits, weil es den Rückgabewert von > receiveUART() prüft und dann feststellt, ob er die Array-Grenze > überschreiten kann. Erstaunlich. Es kann in die Zukunft sehen welcher Wert über den UART reinkommt?
Carsten P. schrieb: > Es liegt natürlich an deinem Naturelle, ob du damit leben kannst, dass > dein Auftraggeber nach ein paar Toten und Schwerverletzten wegen einer > falschen Programmierung von Airbags zigtausend Autos in die Werkstatt > zurück rufen musst. Wenn du schlau warst, hast du jede Haftung > ausgeschlossen im Vertrag... Nur mal nebenbei gefragt, da es Airbags ja nun doch schon eine ganze Weile gibt: wie oft ist das denn bisher weltweit mal vorgekommen? Oliver
Oliver S. schrieb: > Nur mal nebenbei gefragt, da es Airbags ja nun doch schon eine ganze > Weile gibt: wie oft ist das denn bisher weltweit mal vorgekommen? Die sind wohl alle in Rust programmiert ;-)
Oliver S. schrieb: > Nur mal nebenbei gefragt, da es Airbags ja nun doch schon eine ganze > Weile gibt: wie oft ist das denn bisher weltweit mal vorgekommen? Speziell bei Airbags nun nicht, aber das Beispiel des Toyota Camry ist ja bekannt, und da gab es Tote. Das lag allerdings nicht an einem C-Fehler, sondern an unzureichender Stackanalyse, und zu allem Überfluß hat man den Stack auch noch nach unten hin auf die globalen Daten (oder den Heap) zuwachsen lassen. Das könnte wohl auch in Rust passieren, weil der Rust-Compiler sich auf eine korrekte Umgebung genauso verläßt wie ein C-Compiler. Das jünste Beispiel mit den Boeing-Abstürzen wiederum war auch kein C-Fehler, sondern ein Fehler im Systemdesign. Der Maximalausschlag des Höhenruders wurde nachträglich deutlich vergrößert, und dann hätte man das System nicht mehr mit nur einem Sensor betreiben dürfen. Hat man aber, obwohl man sogar physikalisch zwei Sensoren hatte, weil man den dann erhöhten Zertifizierungsaufwand einsaparen wollte.
Cyblord -. schrieb: > Es ging ja darum dass Rust dies anscheinend ohne Overhead automatisch > prüft. Naja: es prüft mit einem vergleichbaren Overhead. Wenn der Test statisch machbar ist, hast du ihn zur Compilezeit, keine Frage. Lässt er sich nur zur Laufzeit ausführen, dann müsstest du ihn für ein sicheres C- (oder Assembler-)Programm dort ebenfalls zur Laufzeit durchführen, daher sollte der Overhead vergleichbar sein.
Cyblord -. schrieb: > Carsten P. schrieb: > >> Du prüfst also nicht, ob x > 100 ist? > > Es ging ja darum dass Rust dies anscheinend ohne Overhead automatisch > prüft. > >> Achso, es ging um Rust. Jepp, das kriegt >> Rust hin, zur Übersetzungszeit bereits, weil es den Rückgabewert von >> receiveUART() prüft und dann feststellt, ob er die Array-Grenze >> überschreiten kann. > > Erstaunlich. Es kann in die Zukunft sehen welcher Wert über den UART > reinkommt? Ja, natürlich. Der Index von a ist maximal 99. Wenn receiveUART() ein uint8 zurückgibt, ist der größte Wert dort 255, also größer als 99. Das ist doch kein Hexenwerk...
Cyblord -. schrieb: >> Rust ist in diesem Aspekt nicht langsamer als C. > > Dann kann Rust in diesem Aspekt auch nicht sicherer sein. > Laufzeitchecks gibt es nicht umsonst. Kann es nicht geben. Ja, Ok. Ich habs verstanden. Du willst ganz offensichtlich nur provozieren und stellst dich bewusst dumm. Ich beende das Spiel an dieser Stelle.
Nop schrieb: > und zu allem Überfluß > hat man den Stack auch noch nach unten hin auf die globalen Daten (oder > den Heap) zuwachsen lassen. Das könnte wohl auch in Rust passieren, Nein, kann es natürlich nicht. Rust ist memory-safe. Das gilt selbstverständlich auch für den Stack. Jörg W. schrieb: > Naja: es prüft mit einem vergleichbaren Overhead. Wenn der Test statisch > machbar ist, hast du ihn zur Compilezeit, keine Frage. Wenigstens einer, der es verstanden hat. Ist aber auch gar nicht so schwer eigentlich :)
Beitrag #6930470 wurde von einem Moderator gelöscht.
MaWin O. schrieb: > Rust ist memory-safe. Das gilt selbstverständlich auch für den Stack. Echt? Der Compiler weiß beim Übersetzen, daß der Stack auf dem Target zu klein ist? Glaube ich nicht.
Nop schrieb: > Echt? Der Compiler weiß beim Übersetzen, daß der Stack auf dem Target zu > klein ist? Das hat niemand behauptet.
MaWin O. schrieb: > Das hat niemand behauptet. Doch, hast Du gerade. Alternativ, was wahrscheinlicher ist, hast Du das von mir beschriebene Problem nicht verstanden.
Nop schrieb: > Echt? Der Compiler weiß beim Übersetzen, daß der Stack auf dem Target zu > klein ist? Glaube ich nicht. Wissen tue ich es auch nicht, aber was hält den Compiler, auch bei genügend präzise angegebenen Targets als Cross-Compiler, davon ab, das zur Übersetzung zu wissen, wie groß der Stack werden darf? Wir reden hier von Embedded, ich jedenfalls, nicht von virtualisierten Maschinen auf virtualisierenden Servern.
Nop schrieb: > Doch, hast Du gerade. Bitte? Du weißt schon, dass man in einem Forum alles nachlesen kann und somit beweisen kann, dass ich es nicht behauptet habe?
MaWin O. schrieb: > Nop schrieb: >> Doch, hast Du gerade. > > Bitte? Du weißt schon, dass man in einem Forum alles nachlesen kann und > somit beweisen kann, dass ich es nicht behauptet habe? Hast Du, und zwar hier: MaWin O. schrieb: > Nein, kann es natürlich nicht. > Rust ist memory-safe. Das gilt selbstverständlich auch für den Stack. Du hast dabei nicht berücksichtigt, daß ein Stacküberlauf gar nicht im Fokus des Compilers sein kann, weil der Compiler nichts von der Stackdimensionierung weiß. Das wird erst beim Linken klar, und dann reden wir über LLVM, nicht mehr von Rust. Der Rust-Compiler verläßt sich genauso wie ein C-Compiler darauf, daß das Environment so funktioniert, wie es das sollte.
Carsten P. schrieb: > aber was hält den Compiler, auch bei genügend präzise angegebenen > Targets als Cross-Compiler, davon ab, das zur Übersetzung zu wissen, wie > groß der Stack werden darf? Einerseits call trees, die von äußeren Einflüssen (beispielsweise Eingabegrößen) abhängen, andererseits natürlich Rekursionen. Bei Rekursionen kann er bestenfalls eine worst-case-Annahme treffen (wenn beispielsweise durch den Datentyp, der die Rekursion steuert, eine maximale Rekursionstiefe ermittelbar ist), aber die kann natürlich meilenweit über im praktischen Betrieb auftretenden realen Anforderungen dann liegen. Dann ist es zwar sicher, aber u.U. derart überalloziert, dass es auf der realen Maschine nicht mehr nutzbar ist, weil sie gar nicht so viel Speicher für den Stack bereitstellen kann. Für eine virtual-memory-Architektur spielt das nicht so'ne große Geige (der Stack ist ja dann nur VM, und wenn der real nicht ausgenutzt wird, muss er nicht durch realen Speicher abgedeckt werden), aber auf einem kleinen Controller kann das ein Problem werden. Sowas kann auch keine Sprache in sich absichern, wenn man derartige Probleme hat. Man kann dann höchstens Monte-Carlo-Simulationen durchspielen, die für typische Szenarien ermitteln, wieviel STack tatsächlich gebraucht wird. In einem realen System würde mann dann in irgendeiner Form eine "Notbremse" einbauen die greift, wenn sich herausstellt, dass der allozierte Stack doch mal nicht reicht (geht natürlich am einfachsten, wenn die Zielarchitektur eine MMU dafür anbietet).
Nop schrieb: > Der Rust-Compiler verläßt sich genauso wie ein C-Compiler darauf, daß > das Environment so funktioniert, wie es das sollte. Nein, das ist halt ganz einfach falsch. Rust geht in ein Panic (und damit in ein Recovery) bei einem Stacküberlauf.
MaWin O. schrieb: > Rust geht in ein Panic (und damit in ein Recovery) bei einem > Stacküberlauf. Das tut er unter Linux, weil das Betriebssystem und die Runtime da noch mitspielen. Embedded und bare metal wird das so nichts werden. Abgesehen davon wäre das auch kaum besser, wenn mitten während der Fahrzeugregulierung das Programm einfach mal neu startet.
Jörg W. schrieb: > Einerseits call trees, die von äußeren Einflüssen (beispielsweise > Eingabegrößen) abhängen, andererseits natürlich Rekursionen. Japp. Korrekt. Anders als andere (einer) hier, behaupte ich auch nicht, dass sowas nicht möglich ist. Ich sage nur, dass ein gut geschneiderter Compiler sehr viel davon verhindern kann. Natürlich kannst du jede Laufzeit und jeden Compiler mit böser Absicht oder (wie du sagtest, Eingaben) genügend hilflosen Anwendern (Coder, die deinen Code linken, sind auch Anwender) in die Knie zwingen. Da fehlt aber gerade in der Hardware noch eine Menge Hirnschmalz, gerade bei kleinen uCs, also dass sie Threads von sich aus ausknipsen, wenn sie gewisse Stack-Grenzen überschreiten. Außer manchen (einem) behauptet ja aber auch niemand, dass Rust die einzige und perfekte Sprache/Laufzeit ist. Rust setzt an typischen Fehlerquellen an, wo ein Compiler bereits rein grätschen kann, und das ist, finde ich, ein sehr guter Ansatz. Natürlich wäre es süß, wenn auch ein AtTiny ne VM Umgebung herstellen könnte, aber dann würde er nicht 30 Cent, sondern 5 Euro mindestens kosten. So dumm ich das Argument selber finde, so sehr zieht es doch einerseits durch den Kostendruck aus anderen Regionen dieser Welt ALS AUCH vom Gerede mancher Entwickler, dass das alles kein Problem sei.
Nop schrieb: > das Beispiel des Toyota Camry ist > ja bekannt, und da gab es Tote. Das lag allerdings nicht an einem > C-Fehler, sondern an unzureichender Stackanalyse, und zu allem Überfluß > hat man den Stack auch noch nach unten hin auf die globalen Daten (oder > den Heap) zuwachsen lassen. Hm. Du hast doch dafür sicherlich eine Quelle. Meines Wissens nach ist die ganze Sache dort sehr viel komplexer gewesen, und ist bis heute nicht abschließend geklärt. > Das jünste Beispiel mit den Boeing-Abstürzen wiederum war auch kein > C-Fehler, sondern ein Fehler im Systemdesign. So war das wohl. Rust mag ja einige haarsträubende Ecken von C(++) umschiffen, aber die Fehler, die in diesen realen Projekten gemacht wurden, hätte das auch nicht verhindert. Oliver
Nop schrieb: > Das tut er unter Linux, weil das Betriebssystem und die Runtime da noch > mitspielen. Embedded und bare metal wird das so nichts werden. Weil du das sagst? Warum genau soll Rust nicht prüfen können, ob der Stack überläuft? > Abgesehen > davon wäre das auch kaum besser, wenn mitten während der > Fahrzeugregulierung das Programm einfach mal neu startet. Ja doch. Ein Neustart ist 1000 mal besser, als UB durch Memory-Corruption. Neustarts von Steuergeräten während der Fahrt passieren "ständig" (d.h. öfter als du denkst).
Oliver S. schrieb: > Hm. Du hast doch dafür sicherlich eine Quelle. Die Google-Stichworte lauten wenig überraschend: toyota camry stack overflow Da findest Du jede Menge dazu. Es war jedenfalls eine der Ursachen. > Rust mag ja einige haarsträubende Ecken von C(++) umschiffen, aber die > Fehler, die in diesen realen Projekten gemacht wurden, hätte das auch > nicht verhindert. Richtig. Das kann man Rust natürlich nicht ankreiden, aber es sind halt mal zwei Beispiele mit Toten, wo "wir machen alles in Rust" nichts geholfen hätte. Insofern sollte man da auch nicht übermütig werden. Wenn ich hier dann im Kontext von embedded-Entwicklung lese, Rust habe keine potentiellen Stackprobleme (haben auch C-Programme übrigens unter Linux nicht - die werden auch beendet), sieht das schon stark nach Risiko-Kompensation aus, was wiederum ein Risiko darstellt.
MaWin O. schrieb: > Warum genau soll Rust nicht prüfen können, ob der Stack überläuft? Weil Rust explizit auf Geschwindigkeit und "kein Runtime-Overhead" entwickelt wurde, und bei jedem Dekrementieren des Stackpointers vorher einen Runtime-Check zu machen wäre ein erheblicher Runtime-Overhead. Die Speichersicherheit bezieht sich auf die Anwendung und nicht darauf, daß das Environment außerhalb des Rust-Programms ein Problem hat. Das, was Du als Beispiel brachtest, wird vom OS bereitgestellt, was das Programm dann abbricht. Es geht hier aber um embedded und bare metal, nicht um Linuxanwendungen. > Ja doch. Ein Neustart ist 1000 mal besser Bei nennenswertem Tempo mit aktiver ASR wäre ein Neustart ebenso fatal.
https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=6ba3452d2c1eeb9b3c9c3f3fa236b77a > thread 'main' has overflowed its stack > fatal runtime error: stack overflow Komisch, gell? Wo Rust das doch angeblich gar nicht erkennen kann?
Ach ja, abgesehen davon weiß der Rust-Compiler gar nicht, wie groß der Stack überhaupt ist. Unter Linux ist das Sache des Betriebssystems, und bare metal wird das erst beim Linken klar - und dann reden wir über LLVM, lange nach dem Rust-Compiler.
Nop schrieb: > Weil Rust explizit auf Geschwindigkeit und "kein Runtime-Overhead" > entwickelt wurde, und bei jedem Dekrementieren des Stackpointers vorher > einen Runtime-Check zu machen wäre ein erheblicher Runtime-Overhead. Nein, wäre es nicht. Das wäre eine einzige Abfrage pro Funktion. Im Mittel deutlich weniger. > Die Speichersicherheit bezieht sich auf die Anwendung Ja eben. Die Anwendung macht die Allokation. Könnte die Anwendung durch Speicherallokation UB hervorrufen, wäre das "unsound". Unsoundness und UB gibt es in Rust nicht. > Das, was Du als Beispiel brachtest, wird vom OS bereitgestellt, Nein.
MaWin O. schrieb: > Ja eben. Die Anwendung macht die Allokation. Denk mal drüber nach, wieso das überhaupt ein Runtime-Fehler ist und nicht ein Compiletime-Fehler, obwohl die Stack-Allokation in Deinem Beispiel ja offensichtlich statisch ist. Das kommt daher, daß man über Guardpages geht, was auf Kernel-Level ein Segfault ist - blöd halt, wenn man gar keine Pages (und auch keinen Kernel) hat, weil wir hier über embedded-Controller reden.
Aus demselben Grund wird übrigens ein C-Programm mit Stackoverflow unter Linux ebenfalls problemlos beendet.
Nop schrieb: > Denk mal drüber nach, wieso das überhaupt ein Runtime-Fehler ist und > nicht ein Compiletime-Fehler, obwohl die Stack-Allokation in Deinem > Beispiel ja offensichtlich statisch ist. Ich habe nie gesagt, dass das ein Compiletime-Fehler ist. > Das kommt daher, daß man über Guardpages geht, was auf Kernel-Level ein > Segfault ist - blöd halt, wenn man gar keine Pages (und auch keinen > Kernel) hat, Es ist völlig unerheblich, ob ein Kernel existiert oder nicht. Die x86/x64-Implementiertung nutzt eine Guardpage. Das ist ein MMU-Feature. Das heißt aber nicht, dass man zwingend einen Kernel braucht. Und es heißt auch nicht, dass man eine MMU braucht. Man kann auch eine Memory-Protection-Unit verwenden. Oder wenn man die nicht hat, kann man den Stack in einen anderen ungültigen Bereich wachsen lassen. Sicher wirds auch irgendwelche Architekturen geben, die gar keine Traps bereitstellen für sowas. Aber selbst dort kann der Compiler selbstverständlich eine architekturspezifische Abrage machen. Macht Rust das derzeit bei allen Architekturen? Nein, denn... > weil wir hier über embedded-Controller reden. Wir reden hier hauptsächlich über Rust. Dass Rust derzeit noch nicht "fertig" ist für alle Embeddedsysteme (kleiner als Raspberry Pi), schrieb ich ja bereits.
MaWin O. schrieb: > Dass Rust derzeit noch nicht "fertig" ist für alle Embeddedsysteme > (kleiner als Raspberry Pi), schrieb ich ja bereits. Jaja, aber wir schwadronieren schon mal vorsorglich vom Ersetzen von C durch Rust.
MaWin O. schrieb: > Macht Rust das derzeit bei allen Architekturen? Nein, denn... ... es ist kein Teil des Rust-Sprachstandards. Oh wait - Rust HAT ja gar keinen Sprach-Standard, sondern ist das, was auch immer der einzige Rust-Compiler gerade tut. Wodurch man übrigens nichtmal einen Compiler-Bug von einem Feature unterscheiden kann, denn gegen welche Spec sollte man das auch prüfen. > Dass Rust derzeit noch nicht "fertig" ist für alle Embeddedsysteme > (kleiner als Raspberry Pi), schrieb ich ja bereits. Mit anderen Worten: Dir war klar, daß Dein Beispiel embedded gar nicht funktionieren würde, aber Du hast es trotzdem mal versucht - ich hätte es ja schlucken können, ne?
Nop schrieb: > Dir war klar, daß Dein Beispiel embedded gar nicht > funktionieren würde, aber Du hast es trotzdem mal versucht Ach komm... Es wurde behauptet, dass Rust sowas grundsätzlich nicht erkennen kann. Und das ist halt falsch. Cyblord -. schrieb: > Jaja, aber wir schwadronieren schon mal vorsorglich vom Ersetzen von C > durch Rust. Wir? Du? Ich jedenfalls nicht. Kannst du ja gerne nachlesen. Ich habe schon mehrfach betont, dass es mir egal ist, was ihr nutzt.
MaWin O. schrieb: > Es wurde behauptet, dass Rust sowas grundsätzlich nicht erkennen kann. > Und das ist halt falsch. Mit derselben Logik wäre das bei C auch kein Problem gewesen: unter Linux wird auch ein C-Programm bei einem Stackoverflow abgebrochen. Dummerweise war es aber kein Linuxsystem.
Nop schrieb: > Mit derselben Logik wäre das bei C auch kein Problem gewesen Richtig. Ich habe nicht behauptet, dass C das nicht auch kann. Ihr wart aber diejenigen, die behauptet haben, Rust könne das nicht.
MaWin O. schrieb: > Ihr wart aber diejenigen, die behauptet haben, Rust könne das nicht. Was Du ja dann ja auch eingestanden hast, nachdem Du erstmal den Unterschied zwischen bare metal und einem Linuxrechner verstanden hast. Im Übrigen könnte man sich selbstverständlich auch einen hypothetischen C-Compiler denken, der vor jedem SP-Dekrement erstmal einen Runtime-Check macht. Hätte, hätte, Fahrradkette.
Nop schrieb: > Was Du ja dann ja auch eingestanden hast Oh bitte. Höre einfach damit auf mir Dinge in den Mund zu legen, die ich nie gesagt habe. Ok? Man kann das hier alles nachlesen. Ok? Gut.
MaWin O. schrieb: > Oh bitte. Höre einfach damit auf mir Dinge in den Mund zu legen, die ich > nie gesagt habe. Ok? Dann hör einfach auf, halbgaren Quatsch zu erzählen und mit unsinnigen Beispielen zu "belegen", die nur darauf bauen, daß andere nicht genauer hinsehen.
Nop schrieb: > Dann hör einfach auf, halbgaren Quatsch zu erzählen Ja, genau. Höre du bitte auf damit. Ok? Die Diskussion ging nicht von mir aus. Ich habe nicht die Behauptung mit dem unbehandelbaren Stackoverflow (a.k.a. halbgarer Quatsch) ins Spiel gebracht.
Nop schrieb: > Die Google-Stichworte lauten wenig überraschend: > toyota camry stack overflow > Da findest Du jede Menge dazu. Eben nicht, daher frage ich ja. Ein Stack Overflow war eine der denkbaren Ursachen, neben einer Zillion anderen, die aus der Komplexität des Systems resultieren. Immerhin war das ein zweikanaliges Sicherheitssystem. Da das Verfahren aber abgeschlossen ist, wird’s dazu auch keine neuen Erkenntnisse geben. Oliver
Oliver S. schrieb: > Eben nicht Du mußt die Links natürlich auch schon anklicken. ;-) Etwa diesen hier: https://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-the-foot-with-stack-overflow/
> Olaf schrieb: > > Pearl > Meinst du Perl? Nein, ich meinte schon Pearl. Sonst haette es wohl kaum als Embedded Beispiel aus der Anfangszeit von C getaugt. Olaf
Nop schrieb: > Im Übrigen könnte man sich selbstverständlich auch einen hypothetischen > C-Compiler denken, der vor jedem SP-Dekrement erstmal einen > Runtime-Check macht. Geht eigentlich nur, wenn die CPU-Architektur das hergibt (also letztlich durch eine MMU). Wenn man das mit Maschinenbefehlen manuell bewerkstelligen will, wird es nicht nur schnarchlangsam, sondern man hat gute Chancen, dass man schon mal irgendein Register auf den Stack pushen muss, um überhaupt erstmal Platz für den Test zu haben … Dann ist es aber ganz unabhängig von der Sprache implementierbar (auch auf Controllern mit MMU, aber das sind halt nicht mehr die allerkleinsten). Da kommt einem aber sofort wieder "Steinbach's guideline of systems programming" in den Sinn … die klingt zwar hart, aber wenn man auf einem Controller gar keinen sinnvollen Ausweg hat, weil man nur noch zwischen Pest (undefined behaviour) und Cholera (spontaneous reboot) wählen kann, dann hat man im konkreten Fall eh ein Problem.
Jörg W. schrieb: > Wenn man das mit Maschinenbefehlen manuell > bewerkstelligen will, wird es nicht nur schnarchlangsam Ein Laden, ein Vergleich und ein bedingter Sprung pro Funktion, sofern der Stackframe am Funktionsanfang komplett aufgebaut wird. Der Overhead wäre schon deutlich. > sondern man hat > gute Chancen, dass man schon mal irgendein Register auf den Stack pushen > muss, um überhaupt erstmal Platz für den Test zu haben … Das wäre leicht abzufrühstücken, indem nicht getestet wird, ob der Stack überschritten sein wird, sondern eine bestimmte minimale Reserve bleibt. Die könnte man dann für register spill im Funktions-Prolog des nächsten Levels nutzen. > aber wenn man auf einem > Controller gar keinen sinnvollen Ausweg hat, weil man nur noch zwischen > Pest (undefined behaviour) und Cholera (spontaneous reboot) wählen kann, > dann hat man im konkreten Fall eh ein Problem. Das kann man aber mit statischer Stackanalyse in den Griff kriegen. Der Calltree ist größenteils bekannt, dann noch Interrupts in worst-case-Schachtelung, und ein paar Calls, die über Funktionszeiger gehen können. Bei den Projektgrößen, die man auf MMU-losen Systemen so hat, ist das kein Problem. Bei uns ist das in Prozeß-Checklisten als vorgeschriebener Teil jedes Software-Releases durchzuführen. Ohne Stackanalyse gibt's kein Release, auch nicht für Software ohne Sicherheitsrelevanz. Im Ernstfall wäre es nämlich langwierig und damit teuer, sporadischen Problemen im Feld nachzuspüren, und sowas würde mit dem Zeitplan laufender Projekte kollidieren.
Nop schrieb: > Das wäre leicht abzufrühstücken > Das kann man aber mit statischer Stackanalyse in den Griff kriegen. Das ist ja erstaunlich, wie schnell du von - das geht gar nicht! - Das kann der Compiler prinzipiell nicht, weil Linker und überhaupt ist das gar nicht bekannt wie groß der Stack ist! - Rust kann das überhaupt nicht! - Du unterstellst mir bewusste Irreführung. dich wandelst zu: > Das wäre leicht abzufrühstücken > Das kann man aber mit statischer Stackanalyse in den Griff kriegen.
Nop schrieb: > Oliver S. schrieb: > >> Eben nicht > > Du mußt die Links natürlich auch schon anklicken. ;-) Etwa diesen hier: > https://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-the-foot-with-stack-overflow/ Habe ich. Und sogar gelesen. Die darin zitierte Untersuchung und auch den Foliensatz kannte ich schon vorher. Da steht drin, daß ein Stackoverflow eine wahrscheinliche Ursache gewesen sein könnte, und als Bewies wird angeführt, daß die Misra nicht eingehalten haben. Bewiesen ist der Fehler nicht, und schon gar keine schuldige Codestelle identifiziert. Es steht auch drin, daß auch Hardwarefehler, kippende Bits, und ein Haufen anderer schöner Dinge die Ursache hätten sein können. Andere Untersuchungen zeigen, daß auch deren real-time-Annahmen auf die Kante genäht waren, usw. Toyota sagt, daß deren fail safe System all diese Fehler abgefangen hätte, kann das aber auch nicht beweisen. Fest steht mir, daß Rust an all dem nichts geändert hätte. Die Probleme liegen alle oberhalb der von Rust eingezogenen Sicherheitsebene. Oliver
Oliver S. schrieb: > Fest steht mir, daß Rust an all dem nichts geändert hätte. Die Probleme > liegen alle oberhalb der von Rust eingezogenen Sicherheitsebene. Ja, das ist ziemlich wahrscheinlich. Es geht bei Rust ja erst einmal auch nicht um Safety, sondern um Security. Das sind zwei grundverschiedene Dinge, auch wenn die Ursachen für Safety-Fehlfunktionen denen von Security-Fehlfunktionen ähneln können. Im Systemdesign unterscheiden die Gegenmaßnahmen sich aber erheblich.
MaWin O. schrieb: > - Das kann der Compiler prinzipiell nicht, weil Linker und überhaupt ist > das gar nicht bekannt wie groß der Stack ist! Es war im Kontext von "Speichersicherheit ohne Runtime-Overhead". Du wirst Dich erinnern, daß dies eines der zentralen Rust-Features ist. Das ist auch der Grund, wieso Rust unter Linux auf Guard-Pages setzt, die keinen Overhead verursachen, solange kein Stackoverflow passiert. Mit Runtime-Overhead kann man das natürlich in jeden Compiler einbauen, aber das ist dann kein Rust-Feature, sondern jede C-Implementation könnte das auch tun. Insofern ist es auch da korrekt, wenn man sagt, daß Rust als Sprache da gar nichts garantiert, ebensowenig wie C.
Nop schrieb: > "Speichersicherheit ohne Runtime-Overhead". Du > wirst Dich erinnern, daß dies eines der zentralen Rust-Features ist. Niemand hat behauptet, dass Speichersicherheit grundsätzlich ohne Runtime-Overhead in Rust realisiert ist. Und schon gar nicht, dass dies ein zentrales Rust-Feature ist. Bitte bleibe bei der Wahrheit. Man kann hier alles nachlesen, was du im Nachhinein falsch verdrehst. Speichersicherheit mit wenig Runtime-Overhead, im Mittel vergleichbar mit dem Overhead, den man in korrekten C-Programmen auch hätte. Das ist eines der zentralen Rust-Features. Und nichts anderes wurde hier gesagt.
Oliver S. schrieb: > und als Bewies wird angeführt, daß die Misra nicht > eingehalten haben. Das war schon ein bißchen mehr als nur MISRA-Mißachtung. > Bewiesen ist der Fehler nicht Derartige Fehler kann man auch schwerlich beweisen, weil es sehr seltene, sporadische Fehler sind. Sonst wäre das bei Testfahrten schon aufgefallen. > und schon gar keine schuldige Codestelle identifiziert. Bei Stackoverflow gibt es in dem Sinne auch keine schuldige Codestelle, wenn man die Stackdimensionierung selber nicht als solche durchgehen läßt, weil es z.B. bei Interrupts sehr davon abhängt, in welcher zeitlichen Abfolge sie mit Blick auf ihre Priorisierung anfallen und in welcher Tiefe des ISR-Calltrees der nächste Interrupt eintrifft. Das ist übrigens auch der Grund, wieso "den Stack vorher mit einem Testmuster füllen, das System laufen lassen und gucken, bis wo der Stack genutzt wurde" keine brauchbare Verifikationsmethode darstellt. Das ergibt nämlich nur eine untere Schranke für den Stackbedarf. Damit kann man lediglich die ohnehin fällige worst-case-Analyse einem Plausibilitäts-Check unterziehen.
MaWin O. schrieb: > Niemand hat behauptet, dass Speichersicherheit grundsätzlich ohne > Runtime-Overhead in Rust realisiert ist. Was bare metal und Stackoverflow angeht, ist sie sogar überhaupt nicht implementiert, wie Du nach diversen Versuchen des Rauswindens dann eingestanden hast. Sie ist also ganz offensichtlich nicht Teil der Sprache selber. > Speichersicherheit mit wenig Runtime-Overhead, im Mittel vergleichbar > mit dem Overhead, den man in korrekten C-Programmen auch hätte. Ein korrektes C-Programm braucht keinerlei Stacküberprüfung zu machen, weil eine dem C-Standard entsprechende Umgebung compilerseitig vorausgesetzt wird. Also genauso wie bei Rust und bare metal.
Nop schrieb: > nach diversen Versuchen des Rauswindens dann eingestanden hast. Das kannst du mehrfach behaupten, aber es stimmt halt nicht. Du kannst hier im Thread nachlesen, wie ich schon vor einiger Zeit gesagt habe, dass Rust derzeit noch nicht auf kleinen Embedded-Systemen stabil ist. Das gilt nach wie vor. Und das war lange bevor du deine Nebelkerzen zum Stackoverflow gezündet hast. > Ein korrektes C-Programm braucht keinerlei Stacküberprüfung zu machen, > weil eine dem C-Standard entsprechende Umgebung compilerseitig > vorausgesetzt wird. Also genauso wie bei Rust und bare metal. Wo ist dann dein Problem? Es wurde hier behauptet, dass ein Rustprogramm grundsätzlich keine Stackprüfung machen könne. Ich habe bewiesen, dass es doch eine Prüfung macht. Du hast halt Unrecht gehabt. Passiert jedem mal. Nicht schlimm. Ich habe nichts über C gesagt. Ich habe nicht gesagt, was besser und was schlechter ist.
Beitrag #6930724 wurde von einem Moderator gelöscht.
Nop schrieb im Beitrag #6930724: > Leider schon wieder gelogen. Warum greifst du mich persönlich an? > Der resultierende Segfault im Kernel ist ohne OS-Unterstützung so nicht drin. Selbstverständlich ist das ohne Kernelunterstützung implementierbar. Glaubst du der Kernel wäre etwas magisches, was irgendwas aus dem Hut zaubert? Es ist sogar ohne MMU-Unterstützung implementierbar, wenn die Hardware minimalste Protection-Mechanismen hat. Und es ist auch ohne MPU implementierbar, wenn man den Stack so platzieren kann, dass beim Überlauf ein Zugriff auf einen ungültigen Bereich stattfindet und dieser ein Trap auslöst. Und es ist auch ohne Trap lösbar, indem man alle Stackveränderungen ganz einfach prüft.
Beitrag #6930740 wurde von einem Moderator gelöscht.
Beitrag #6930742 wurde von einem Moderator gelöscht.
Beitrag #6930744 wurde von einem Moderator gelöscht.
Beitrag #6930751 wurde von einem Moderator gelöscht.
Nop schrieb: > Der Calltree ist größenteils bekannt, dann noch Interrupts in > worst-case-Schachtelung, und ein paar Calls, die über Funktionszeiger > gehen können. Klappt halt so nur, solange die Stacknutzung nicht zu stark von den (nicht exakt vorhersagbaren) Eingabedaten abhängt. Klar, alles was statisch machbar ist, ist eh immer am einfachsten. Im Zweifelsfalle, wenn man Sicherheit braucht, darf dann aber eben auch die Hardware weder von der Geschwindigkeit noch vom Speicherausbau „auf Kante genäht“ sein. Aber ja, mit Rust hat das alles jetzt nichts mehr zu tun. :-) Kann schon sein, dass Rust auch in diesem Bereich künftig noch an Boden gewinnt, aber im Moment sehe ich das noch nicht um die Ecke lugen. Ein Auftraggeber, für den ich letztens gearbeitet habe (mit durchaus sehr experimentierfreudigen Entwicklern), hatte es für eine Embedded-Lösung auf deutlich höherem Niveau (embedded Linux auf größerer STM-Plattform) initial in Erwägung gezogen, aber dann doch wieder verworfen und herkömmlich in C++ gearbeitet. Bei denen ist auch funktionale Sicherheit ein Thema, und der ganze Krams muss dann durch eine Zertifizierung durch.
Jörg W. schrieb: > Klappt halt so nur, solange die Stacknutzung nicht zu stark von den > (nicht exakt vorhersagbaren) Eingabedaten abhängt. Der Trick ist, daß man ja nicht die exakte Nutzung braucht, sondern nur eine verläßliche obere Schranke. Daher kann man die Eingabedaten mehr oder weniger ignorieren und geht einfach den Calltree durch, auch wenn der u.U. so in derser Kombo nicht unbedingt passieren kann. > Im Zweifelsfalle, wenn man Sicherheit braucht, darf dann aber eben auch > die Hardware weder von der Geschwindigkeit noch vom Speicherausbau „auf > Kante genäht“ sein. Klar, also beim Stackverbrauch wird ja auch immer noch ein wenig Reserve gefordert. > Aber ja, mit Rust hat das alles jetzt nichts mehr zu tun. :-) Nur noch am Rande. ;-) > Bei denen ist auch funktionale Sicherheit > ein Thema, und der ganze Krams muss dann durch eine Zertifizierung > durch. Da wird man dann noch so einiges an Lösungen brauchen, mindestens was für statement coverage. Mehr Sorgenfelder sehe ich darin, daß es nur einen einzigen Compiler gibt, der zugleich auch noch der Sprachstandard ist, so daß man nichtmal einen Compilerbug von einem Sprachfeature unterscheiden kann. Kommerzieller Support ist auch nicht drin. Ein zertifizierter Compiler ist in weiter Ferne, und ohne ISO-Standard sehe ich den auch nicht.
Bzgl. gelöschte Beiträge: Bitte freundlich bleiben, andere der Lüge zu bezichtigen ist kein Teil einer sachlichen Diskussion.
Nop schrieb: > ohne ISO-Standard sehe ich den auch nicht Ein ISO-Standard wiederum ist ein ganz schön großer Haufen an Arbeit, die keinerlei "Hack value" hat. Einfach nur Arbeit, administrativ, editorisch. Aber man könnte ihn – anders als bei Pascal – ja an den realen Features des existierenden Compilers fest machen. :)
Nop schrieb: > Ein zertifizierter Compiler > ist in weiter Ferne Sind eigentlich zertifizierte Compiler tatsächlich messbar besser? Oder nutzt man die nur der Zertifizierung und dem dazugehörigen Haftungszeug wegen?
Moin, Huch, hier war ja richtig was los die Tage... Nop schrieb: > Mehr Sorgenfelder sehe ich darin, daß es nur einen einzigen Compiler > gibt, der zugleich auch noch der Sprachstandard ist, so daß man nichtmal > einen Compilerbug von einem Sprachfeature unterscheiden kann. > Kommerzieller Support ist auch nicht drin. Ein zertifizierter Compiler > ist in weiter Ferne, und ohne ISO-Standard sehe ich den auch nicht. Ja, und dagegen hilft auch das gebetsmuehlenhafte Vortragen von "Nein, man muss ja kein Cargo nehmen..." auch von allen hier auftretenden MaWins nicht wirklich. Es aendern sich die Compilerversionen noch schneller als gute Entwicker ihre Unterhosen und Socken wechseln - ich glaub' bei sowas sollte auch der Diplom-Informatiker mit Fachrichtung Projektkasper doch mal kurz ins Gruebeln kommen, wie er dann, wenn er sowas aus Sicherheitsgruenden einsetzt, Probleme seinen Scheffs verkaufen will... Gruss WK
Dergute W. schrieb: > Es aendern sich die Compilerversionen noch schneller Und warum ist das schlecht? Ist gcc auch schlecht, weil es relativ oft Releases macht? https://gcc.gnu.org/releases.html Wenn du bei einem alten Compiler bleiben willst, dann bleibe halt bei einem alten Compiler. Warum auch nicht, wenn er deinen Code übersetzen kann? Niemand hat etwas dagegen. > Ja, und dagegen hilft auch das gebetsmuehlenhafte Vortragen von "Nein, > man muss ja kein Cargo nehmen..." Was hat jetzt Cargo genau mit Zertifizierung und ISO-Standard zu tun. Würde mich sehr interessieren, wenn du das einmal genauer erklärst.
Dergute W. schrieb: > Es aendern sich die Compilerversionen noch schneller als gute Entwicker > ihre Unterhosen und Socken wechseln Das würde sich übrigens ganz schnell geben, wenn man ein Standardisierungsgremium dafür aufbaut. Nur mal so, für den nächstes Jahr zu veröffentlichen C-Standard (C23) war Annahmeschluss für die letzten Papers, die neue Features einbringen können, im Oktober 2021. Im Laufe dieses Jahrs werden diese noch zu Ende gefeilt, und ab Sommer 2022 muss dann der eigentliche Formalismus für die Standardisierungsgremien (ISO, IEC, INCITS) in die Wege geleitet werden, damit der Standard nächstes Jahr fertig ist. Dabei ist die WG14 noch insgesamt recht wenig bürokratisch: bei den normalen Sitzungen gibt es keine formalen Abstimmungen (ballot), sondern nur Meinungsumfragen (straw polls), bei denen die Mehrheit der Anwesenden (also auch Gäste) entscheidet, da die jeweils Anwesenden als Expertengremium gehandhabt werden. Ergebnisse werden natürlich nur dann angenommen, wenn diese Umfragen eine hinreichend klare Linie ergeben, ansonsten muss der Antrag ggf. umformuliert und neu gestellt werden.
Jemand schrieb: > Sind eigentlich zertifizierte Compiler tatsächlich messbar besser? Besser, im Sinne von technisch weniger Bugs, ist ja gar nicht das Ziel einer Zertifizierung. So etwas enorm komplexes in einem Zertifizierungs-Regelwerk abzubilden, sodass keine Bugs mehr drin sein können, ist natürlich nicht möglich. Es geht vielmehr darum, dass der Verkauf das Zertifikat-Label auf das Produkt drucken darf und die QM-Abteilung ruhiggestellt wird. Durch einen zertifizierten Compiler wurde noch nie auch eine einzige Fehlfunktion verhindert. Ganz im Gegensatz zum Testen und Bugfixen (des Compilers). Das verhindert Bugs. Leider verhindert oft genug gerade die Zertifizierung das Bugfixen des Compilers, weil dann müsste er ja neuzertifiziert werden. Was dann oft genug in Workarounds in Produktcode ausufert, um Compilerbugs zu umschiffen. Das ist dann "billiger".
Jörg W. schrieb: > Nur mal so, für den nächstes > Jahr zu veröffentlichen C-Standard (C23) war Annahmeschluss für die > letzten Papers, die neue Features einbringen können, Das ist nur nötig, weil C kaum Mechanismen und Regelwerke hat, Features vollständig rückwärtskompatibel einzubauen. Im Gegensatz zu Rust. Links dazu habe ich bereits gepostet.
MaWin schrieb: > Das ist nur nötig Sorry, aber du erzählst gerade Unsinn. Das hat mit C absolut nichts zu tun, sondern mit der Wirkungsweise von Standardisierungsgremien. (Außerdem beweist deine Aussage über Nicht-Rückwärtskompatibilität von C höchstens, dass du diese Sprache nicht einmal kannst, geschweige denn ihre Standards. Aber der Thread hier ist natürlich nicht für die Diskussion über C da.)
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Das hat mit C absolut nichts zu > tun, sondern mit der Wirkungsweise von Standardisierungsgremien. Natürlich. Der C-Standard hat mit C absolut gar nichts zu tun. "Es gibt nichts zu sehen hier! Gehen Sie weiter!" > dass du diese Sprache nicht einmal kannst Ich muss mich hier nicht rechtfertigen. Aber vielleicht du? Wie gut kennst du Rust? Ja, Rust hat keine formelle Standardisierung. Das bestreitet niemand. Aber Rust hat sehrwohl wirkungsvolle Mechanismen und Features vollständig rückwärtskompatibel zu diskutieren und zu stabilisieren.
Jörg W. schrieb: > Außerdem beweist deine Aussage über Nicht-Rückwärtskompatibilität von C Außerdem habe ich das nie gesagt. Lies meine Posts, bitte.
MaWin schrieb: > Es geht vielmehr darum, dass der Verkauf das Zertifikat-Label auf das > Produkt drucken darf und die QM-Abteilung ruhiggestellt wird. Dieselbe Argumentation kann man auch bei der zertifizierten Produktsoftware selber anbringen. Als Schlußfolgerung bleiben dann z.B. Flugzeuge, die nach Agil-Yolo entwickelt wurden. Wird bestimmt ein Verkaufs-Hit.
Nop schrieb: > Als Schlußfolgerung bleiben dann z.B. Flugzeuge, Das ist korrekt. Auch in Flugzeugen werden Bugs ausschließlich durch Tests und in Design-Reviews/Prozessen gefunden und gefixt. Niemals aber durch eine Zertifizierung des Compilers. Standardisierte Entwicklungsprozesse sind es, as Safety schafft. Nicht Zertifizierung von Entwicklungstools.
MaWin schrieb: > Standardisierte Entwicklungsprozesse sind es, as Safety schafft. Nicht > Zertifizierung von Entwicklungstools. Dann darfst Du bei den höheren Anforderungsleveln als Hersteller gerne selber beweisen, daß der Maschinencode Deinem Sourcecode entspricht. Viel Spaß dabei, diese Kosten zu stemmen, und das für jedes Projekt und jedes Update erneut. Mit Testen alleine kommst Du da nämlich nicht durch.
... überdies ist der Widerspruch offensichtlich: bei Produkten helfen standardisierte Entwicklungsprozesse, die überhaupt die Basis für die Produkt-Zertifizierung sind, der Produktqualität - aber für Compiler gilt das natürlich nicht. Ja nee, ist klar.
Nop schrieb: > überhaupt die Basis für die > Produkt-Zertifizierung sind, der Produktqualität - aber für Compiler > gilt das natürlich nicht. Eine Produktzertifizierung hilft der Produktqualität genau so, wie eine Compilerzertifizierung der Compilerqualität hilft. Nämlich gar nicht. Solle klar sein.
Nop schrieb: > Dann darfst Du bei den höheren Anforderungsleveln als Hersteller gerne > selber beweisen, daß der Maschinencode Deinem Sourcecode entspricht. Wie hilft mir die Zertifizierung dabei? Also technisch jetzt. Nicht rechtlich, durch das Verschieben der Verantwortung.
MaWin schrieb: > Eine Produktzertifizierung hilft der Produktqualität genau so, wie eine > Compilerzertifizierung der Compilerqualität hilft. > Nämlich gar nicht. Aber sicher doch. Deswegen werden Flugzeuge ja zertifiziert. Weil's nichts bringt. Daß die Luftfahrt massiv sicherer geworden ist, ist halt Zufall. Jedenfalls in Deinem Paralleluniversum. Kleiner Denkanstoß: hätte man bei der 737-Max die Prozesse tatsächlich befolgt, wären die Flieger nicht abgestürzt. Hätte die FAA ihren Job gemacht und nicht effektiv Boeing sich selbst beliebige Zertifikate ausstellen lassen, dann wären die Prozesse auch befolgt worden.
Nop schrieb: > Kleiner Denkanstoß: hätte man bei der 737-Max die Prozesse tatsächlich > befolgt, wären die Flieger nicht abgestürzt. Ich habe bereits gesagt, dass Entwicklungsprozesse absolut und unbestritten zur Qualität beitragen (bzw. dessen Grundlage ist). Im Gegensatz zu Compilerzertifizierungen. Die helfen nur den Zertifizierungsunternehmen. Aber du wirst mir sicher wieder die Worte im Munde herumdrehen. Es ist alles nachlesbar und dokumentiert hier im Forum.
MaWin schrieb: > Ich habe bereits gesagt, dass Entwicklungsprozesse absolut und > unbestritten zur Qualität beitragen (bzw. dessen Grundlage ist). Was Du irgendwie nicht verstehst: Du bekommst keine Zertifizierung ohne den Nachweis entsprechender Entwicklungsprozesse. Das ist der Zweck einer Zertifizierung. Dementsprechend wirkt das bei Compilern ganz genauso wie bei anderen Produkten auch. In Deinem Paralleluniversum murkst man sich irgendeinen Mist zurecht, geht damit zu einem Zertifizierungsunternehmen, bekommt irgendeinen Wisch und ist zertifiziert. Kein Wunder, daß Du den Sinn nicht begreifst.
MaWin schrieb: > Es geht vielmehr darum, dass der Verkauf das Zertifikat-Label auf das > Produkt drucken darf und die QM-Abteilung ruhiggestellt wird. Also, MaWin mit oder ohne O, ich habe bisher einiges Nachdenkenswertes von dir gelesen, auch ein paar kluge Einwände, aber das ist jetzt echt mal kompletter Schwachsinn. Das, was du hier gerade schwafelst, ist, als wären Schuhgrößen, weil sie genormt und innerhalb der EU durch Standards diese Normen vereinheitlicht wurden, Unsinn. Also, du sagst, Normen, Zertifizierungen dieser Normen sind egal. Das würde z.B. bedeuten, dass du heute in München wohnst z.B., dort in einem Laden Schuhe in der Größe 42 kaufen kannst, im Laden nebenan knapp noch, irgendwas zwischen 41 und 43, dann ziehst du um nach Hamburg, dort heißen die Schuhgrößen Alpha, Beta, Gamma und Omikron, und aufgrund der Geschichte mit der Hanse sind die Tragweiten mit kyrillischen Buchstaben ausgezeichnet. Selbstverständlich gibt es in Hamburg Normen für Sohlen, die aber nur im Stadtgebiet von Hamburg und in einigen, aber nicht allen anderen Hansestädten gelten, was die Sicherheit angeht, falls sich die Sohle löst und du dir auf dem nicht weiter genormten Kopfsteinpflaster das Kinn brichst. Wenn du die Idee der Normen grundsätzlich ablehnst, ist das deine Sache. Wenn du aber die Idee der Zertifizierung entlang dieser Normen ablehnst, möchte ich nichtmal auf der Rückbank eines Taxis neben dir sitzen.
Carsten P. schrieb: > > Also, du sagst, Normen, [...] dieser Normen sind egal. > > Wenn du die Idee der Normen grundsätzlich ablehnst Wo habe ich das gesagt? Bitte zitieren. > Wenn du aber die Idee der Zertifizierung [...] ablehnst Ich sprach ausschließlich von der Zertifizierung von Compiler-Tools. Denn ebenjene bringen keinen Qualitätsgewinn. Die Compiler sind bereits sehr sehr gut. Compilerfehler treten praktisch nicht auf. Und das ist nicht der Verdienst der Zertifizierungen, sondern von Tests. Zertifizierungen im Compilerbereich bringen nur Nachteile, indem sie einen an ebenjene zertifizierte Compilerversion ketten. Auch wenn diese Version Bugs enthält. Von nichts anderem sprach ich. Es ging auch nicht um Produktzertifizierungen. Es ging auch nicht um genormte Prozesse und Produktnormen. Und auch nicht um irgendetwas beliebiges anderes. Das entspringt alles deiner Fantasie. Bitte bei der Wahrheit bleiben. Es ist alles hier nachlesbar, was ich geschrieben habe. Es bringt überhaupt nichts, mir etwas anzudichten, was ich nie geschrieben habe. Danke.
Und außerdem hat das überhaupt nichts mehr mit Rust zu tun. Wenn du den Rustcompiler zertifizieren willst, kannst du das gerne tun. Niemand hindert dich daran.
MaWin schrieb: > Wenn du den Rustcompiler zertifizieren willst, kannst du das gerne tun. Gegen was willst du den denn zertifizieren, wenn es keinen Standard gibt?
Jörg W. schrieb: > Gegen was willst du den denn zertifizieren, wenn es keinen Standard > gibt? Das bleibt dir überlassen. Vielleicht gegen deinen Wocheneinkaufszettel? An der Compilerqualität ändert es jedenfalls nichts. Egal, gegen was zertifiziert wird.
Vielleicht muß man nur geduldig sein. Gut Ding braucht Weil. War bei anderen Sprachen nicht anders. Ich habe mir deren Webseite angesehen und gelesen, daß eine STM32 Bord unter Rust praktisch demonstriert wird. Hat jemand von Euch damit schon herum gespielt? Wie gut wird sich Rust für kleinere uC bewähren? Gibt es Gründe warum Rust nicht auf kleinen 8-Bittern laufen wird? Oder ist da C/C++ momentan doch noch die beste Wahl. Ich bin an Rust schon etwas interessiert. Nur habe ich wenig Motivation Pionierarbeit oder mich mit schwierigen Problemen herumschlagen zu müssen. Normalerweise liegt es mir daran mit iC Probleme zu lösen anstatt lösen zu müssen. Ich bin sicher, daß sich in ein paar Jahren die augenblicklichen Wogen legen werden und man Platform gerechte Lösungen finden wird. Schön wäre es schon, wenn man ein Rust Entwicklungssystem hätte ohne große Überraschungen und mit guten Low-Level Support. So wie es halt bei allen anderen uC der Fall ist. Es scheint, momentan wäre die STM32 Familie die einzige uC Familie die unterstützt wird. Ich wäre sehr an praktischen Erfolgsberichten interessiert. Also z.B. "Ich baute mir ein Gadget mit Rust auf STM32" und Informationen über die Erfahrungen durchs Projekt hindurch. Im Augenblick theoretisiert Ihr mir eigentlich zu viel und zu viele Generalitäten werden hin und her geworfen. Wenn Rust wirklich Fuß fassen sollen brauchen viele von uns doch konkrete Anhaltspunkte wie es anderen wagemutigeren Wegbereitern gegangen ist und wie man die anfänglichen Ungewissheiten beseitigen könnte. Es ist nicht genug wenn nur die Gurus und Genies unter Euch damit Erfolge erzielen. Wir sollten wirklich vermeiden "Fanboys" zu sein und uns anstatt gegenseitig so gut es geht mit Fakten untereinander helfen und Erfahrungen austauschen. Was mich betrifft, hätte ich an Rust nur im uC embedded Bereich praktisches Interesse.
Gerhard O. schrieb: > Wie gut wird sich Rust für kleinere uC bewähren? Gibt es Gründe warum > Rust nicht auf kleinen 8-Bittern laufen wird? Es gibt einen experimentellen Rustcompiler für AVR8. Er ist allerdings noch relativ weit vom Produktiveinsatz entfernt. Aber als Proof-of-Concept taugt er. > Ich bin an Rust schon etwas interessiert. Nur habe ich wenig Motivation > Pionierarbeit oder mich mit schwierigen Problemen herumschlagen zu > müssen. Auf allem, was ARM-Cortex (Raspbery Pi) oder größer (bis PC) ist, ist die Pionierarbeit schon lange geleistet und Rust ist dort produktiv einsetzbar. > STM32 Da kenne ich den Status leider nicht. > Im Augenblick theoretisiert Ihr mir eigentlich zu viel Ja, das sehe ich auch so. Viele Leute haben hier im Thread eine starke Meinung, aber fast niemand von diesen Leuten hat Rust einmal wirklich ausprobiert. Das wird offensichtlich aus den teilweise haarsträubenden Behauptungen. > Wir sollten wirklich > vermeiden "Fanboys" zu sein und uns anstatt gegenseitig so gut es geht > mit Fakten untereinander helfen und Erfahrungen austauschen. Volle Zustimmung. Weniger Gefühle und Meinung. Mehr Fakten und Erfahrung.
Gerhard O. schrieb: > Ich habe mir deren Webseite angesehen und gelesen, daß eine STM32 Bord > unter Rust praktisch demonstriert wird. Hat jemand von Euch damit schon > herum gespielt? Seit ca. 2 Jahren nutze ich ausschließlich Rust für alle meine STM32 Hobby Projekte. Unter anderem habe ich Niklas G.'s USB-Tutorial als Übung auf Rust portiert (wenngleich das eine meiner ersten Rust-Aktionen war und noch um einiges mehr unsafe Code aufwies als nötig). Cargo gefällt mir super, man muss nicht auf irgendwelche IDEs setzen die einem das Grundgerüst generieren, sondern mit paar Handgriffen (Target wählen, no-std deklarieren und PAC laden) baut "cargo build" einfach die binary für den STM. Einen Schritt weiter kann "cargo run" auch das ganze samt debug ausgaben ausführen, wenn man z.b. probe-run oder cargo-embed nutzt. Wenn ich mich an die Verrenkungen mit make oder cmake erinnere, war das um einiges aufwendiger. Was mich vor allem zu Rust bekehrt hat ist das Pattern matching. Anfangs dachte ich match ist einfach nur "sowas ähnliches wie switch", aber es ist so viel mehr, vor allem macht es das Arbeiten mit enums (davon hat man ja oft welche) sehr viel übersichtlicher. Insgesamt finde ich Rust Code mittlerweile viel angenehmer und einfacher zu lesen als C-Code, auch weil es dank rustfmt immer im gleichen Stil ist. Der Einstieg in Rust auf STM32 ist einfach und es gibt mittlerweile sehr viele Beispiele, z.b. das Rust Embedded Book https://docs.rust-embedded.org/book/
Gerhard O. schrieb: > Gut Ding braucht Weil. Sei mir bitte nicht böse, Gerhard O., wenn ich dich nicht nur wörtlich, sondern Buchstabe für Buchstabe zitiere, denn "gut Ding braucht Weil!". Das ist ein sehr kluger Satz. Vielleicht hast du das "e" vergessen für deine Aussage, aber ich bleibe bei der, die du abgeschickt hast: "Gut Ding braucht Weil!". Das ist in etwa das, etwas anders, aber auf den Punkt formuliert, was man Wissenschaft nennt, vor allem Naturwissenschaft. Frage stets "Weil? Warum?"! Und lasse niemals locker, auch wenn dein Gegenüber genervt ist. Warum? Weil es nicht um dein Gegenüber geht, sondern um das Thema. Nicht um die Wahrheit an sich. Warum nicht? Weil es keine Wahrheit an sich gibt, sondern nur mehr oder weniger gute und überprüfbare Versuche, sich ihr anzunähern. Dass es eine einzige Wahrheit gibt, behaupten nur der Papst und Spaziergänger.
STMRust schrieb: > Seit ca. 2 Jahren nutze Vielen Dank für den Beitrag. Endlich einmal jemand, der Rust auch wirklich ausprobiert hat. > nutze ich ausschließlich Rust für alle meine STM32 Sehr interessant. Da habe ich jetzt auf jeden Fall etwas gelernt. Das sollte ich auch einmal ausprobieren.
MaWin schrieb: > Jörg W. schrieb: >> Gegen was willst du den denn zertifizieren, wenn es keinen Standard >> gibt? > > Das bleibt dir überlassen. Vielleicht gegen deinen Wocheneinkaufszettel? Dummes Gelaber - das selbstverständlich in den Bereichen, wo zertifizierte Tools gefordert werden, nicht akzeptiert wird. > An der Compilerqualität ändert es jedenfalls nichts. Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt, gegen den eventuelle Abweichungen festzustellen bzw. zu dem Konformität zu belegen wäre. Damit ist auch die Aussage von "sehr guter Qualität" nur eine leere Worthülse.
Carsten P. schrieb: > Gerhard O. schrieb: >> Gut Ding braucht Weil. > > Sei mir bitte nicht böse, Gerhard O., wenn ich dich nicht nur wörtlich, > sondern Buchstabe für Buchstabe zitiere, denn "gut Ding braucht Weil!". > Das ist ein sehr kluger Satz. Vielleicht hast du das "e" vergessen für > deine Aussage, aber ich bleibe bei der, die du abgeschickt hast: "Gut > Ding braucht Weil!". > Obwohl ich Dir im Weiteren vollkommen zustimme, habe ich mein Zitat nur im herkömmlichen Sinn gemeint, daß man eben Rust die Gelegenheit geben sollte erwachsen und reifer zu werden und daß das Zeit braucht. In zehn Jahren wird sich noch viel ergeben. So kann ich leider nicht das Kompliment annehmen:-) Ich möchte vorerst mich mit der Entwicklungsumgebung befassen um die Werkzeuge unter Windows in den Griff zu bekommen. Eigenbau STM32 HW habe ich auch. Es ist mir wichtig die Tool Chain zum Laufen zu bringen. Die Sprache selber ist ja ziemlich intuitiv wenn man mal von den Pragmas absieht die man lernen muß. Da sehe ich für mich eher die größeren Schwierigkeiten. Dafür sind aber die Online Dokus da. Die Tricks wird man man sowieso in Kollaboration mit Mitstreitern lernen müssen und vielleicht miteinander teilen können.
:
Bearbeitet durch User
An STMrust, Vielen Dank für Deine Hinweise. Ich habe mir schon die embedded Doku angesehen.
Nop schrieb: > Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt Qualität ist die Abwesenheit von Kundenreklamationen.
MaWin schrieb: > Nop schrieb: >> Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt > > Qualität ist die Abwesenheit von Kundenreklamationen. Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik.
Mombert H. schrieb: >> Qualität ist die Abwesenheit von Kundenreklamationen. > > Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik. Musst du sie noch auf die Gesamtkundenzahl beziehen, dann passt das schon. Könnte natürlich sein, dass C-Compiler dann dank ihrer großen Kundenzahl verdammt gut abschneiden. ;-)
Jörg W. schrieb: > Mombert H. schrieb: >>> Qualität ist die Abwesenheit von Kundenreklamationen. >> Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik. > Musst du sie noch auf die Gesamtkundenzahl beziehen, dann passt das > schon. > Könnte natürlich sein, dass C-Compiler dann dank ihrer großen Kundenzahl > verdammt gut abschneiden. ;-) Vorher müsste man klären was genau mit Kunde gemeint ist. Wenn ich clang oder gcc nutze sehe ich mich nicht als Kunde. Nur wenn ich ifort nutze sehe ich mich aktuell als Kunde und das macht weniger als 5% meiner Zeit aus.
Mombert H. schrieb: > Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik. Genau. In Abwesenheit von Kunden spielt Qualität keine Rolle. Außer in QM-Hirnen.
Mombert H. schrieb: > Vorher müsste man klären was genau mit Kunde gemeint ist. Nenne sie von mir aus „aktive Nutzer“. Streng genommen müsstest du natürlich noch die Nutzungshäufigkeit mit einbeziehen, denn je häufiger du sie nutzt, um so größer die Wahrscheinlichkeit, mal auf ein Problem damit zu stoßen.
Mombert H. schrieb: > Wenn ich clang oder gcc nutze sehe ich mich nicht als Kunde. Krass. Das sagt mehr über dich aus, als über clang, gcc und den Rest der Welt.
MaWin schrieb: > Mombert H. schrieb: >> Wenn ich clang oder gcc nutze sehe ich mich nicht als Kunde. > > Krass. > Das sagt mehr über dich aus, als über clang, gcc und den Rest der Welt. Dann erleuchte mal die Welt und gib uns deine Definiton von Kunde.
Mombert H. schrieb: > Dann erleuchte mal die Welt und gib uns deine Definiton von Kunde. Legaler Nutzer laut Lizenz.
MaWin schrieb: > Mombert H. schrieb: >> Dann erleuchte mal die Welt und gib uns deine Definiton von Kunde. > > Legaler Nutzer laut Lizenz. Wenn ich in den Supermarkt gehe, bin ich also kein (evtl. potentieller) Kunde? Oder wie definierst du Lizenz?
Software beschaffen -> Lizenz Vertrag Im Laden was Einkaufen -> Kauf Vertrag Sind beides Verträge, man denkt über letzteren nur nicht so, weil das meistens implizit ist. (Ich geb einfach den angeschriebenen Betrag, und allen ist klar, was die Konditionen sind) Eigentlich nervig, dass das bei Software noch nicht simpler gestaltet wurde. Kundenschutz ist auch nicht existent. Wie Geräte heute zu Servicen werden, zum Kotzen. Rechtssysteme versagen beim Digitalen einfach komplett, lassen Unternehmen verlangen, tun und lassen, was sie wollen, und regulieren am falschen Ort, um positiven Technologieeinsatz zu erschweren / verhindern.
DPA schrieb: > Software beschaffen -> Lizenz Vertrag > Im Laden was Einkaufen -> Kauf Vertrag Das bedeutet man kann Software nicht kaufen? Was ist mit Software, die ich nicht gekauft oder beschafft habe aber trotzdem nutze? Bin ich dann Kunde?
Mombert H. schrieb: > DPA schrieb: >> Software beschaffen -> Lizenz Vertrag >> Im Laden was Einkaufen -> Kauf Vertrag > Das bedeutet man kann Software nicht kaufen? Das ganze ist etwas kompliziert, ich überblicke das alles auch nicht. Die kurze Version ist, Ja, man kann Software Kaufen, aber was heisst das eigentlich? Man muss sich da überlegen, was man da unter kaufen versteht, bzw. was man eigentlich kaufen will. Man kann z.B. Lizenzen anbieten/kaufen. Damit kann man z.B. Nutzungsrechte an einer Software erwerben, aber auch andere Dinge festlegen. Kann man zwar beim Kauf anderer Sachen auch machen, insbesondere bei anderen nicht physischen Sachen (Bilder, Filme, Musik (oft separat Aufzeichnung, Vorführung, Noten, Texte), etc.), ist das recht üblich. Ich bin mir nicht sicher, bis zu welchem Grad man das mit physischen Dingen machen kann, und wie genau das mit "geistigem Eigentum", Eigentumsrechten, Besitzrechten, usw. im Detail zusammenhängt & funktioniert, aber man kann überall einiges festlegen. Aber eventuell will man eine Software kaufen, im sinne von den Code & sämtliche Rechte daran kaufen. Das geht bis zu einem gewissen Grad auch. Wobei, in gewissen Ländern kann man gewisse Rechte nicht verkaufen oder aufgeben, und vieles ist je nach Land sehr anders geregelt. Darum kann man z.B. nicht einfach sagen "Ich geb all meine rechte auf, und gebe sie der Allgemeinheit", sondern braucht dafür Lizenzen wie CC0, die versuchen das nächst beste mögliche zu bieten (https://creativecommons.org/share-your-work/public-domain/cc0/). Ehrlich gesagt, ich wüsste gar nicht, wie ich eine Software jemand anderem verkaufen könnte, im sinne von alle möglichen Rechte daran. > Was ist mit Software, die ich nicht gekauft oder beschafft habe aber trotzdem nutze? Um diese nutzen zu können, brauchst du trotzdem eine Vertrag/Lizenz, die dir das erlaubt. Oft ist das aber auch ein bisschen wie wenn man sonst was Einkauft oder Verschenkt. Wenn ich meine eigene Software gratis anbiete, oder als Demo Version, reicht es vermutlich zu sagen, das ist Freeware / eine Demo Version, hier ist der Download. Aber normalerweise gibt es danach trotzdem noch irgend eine EULA, die genauer festhält, das die Konditionen für den Endnutzer sind. Es gibt da noch irgend einen Unterschied zwischen Endnutzer Lizenzen und anderen arten von Lizenzen. Die GPL z.B. ist keine Endnutzerlizenz. Die legt einfach fest, was man mit dem Code machen darf, und man muss ihr nicht explizit zustimmen, will man die Rechte, die sie einem gibt, muss man sich aber an sie halten. Wenn ich meinen Code dann gratis öffentlich auf GitHub stelle, mit der GPL Lizenz drin, gebe ich die Lizenz quasi gratis an andere. Aber ich könnte den Code auch ohne Lizenz veröffentlichen, dann dürfte ihn eigentlich keiner nutzen. Als Urheber kann ich Software beliebig lizenzieren, ich kann den Code also auch unter der / irgendeiner Lizenz lizenziert verkaufen. (Und die Lizenz legt dann auch Dinge fest, wie z.B. darf ich das weiterverkaufen). Keine Ahnung, wann man Lizenzen explizit zustimmen muss und wann nicht, und wie das alles im Detail zusammen hängt. Vermutlich blickt da sowieso keiner durch. Irgendwo hätte ich von der BM her noch ein Buch (https://www.booklooker.de/B%C3%BCcher/Thomas-Sutter-Somm+ZGB-OR-Schweizerisches-Zivilgesetzbuch-und-Obligationenrecht-mit-ZPO-SchKG-und/isbn/9783906186245), da steht auch irgendwo drin, wer (in der Schweiz) beim Verkauf von Dingen welche Rechte und Pflichten hat, was Eigentum und Besitz genau heist, wie man das Anwendet / was man in einem Vertrag anders regeln kann, usw. Theoretisch könnte ich dort im ZGB Teil, unter Sachenrecht, alles relevante zum kaufen und verkaufen von Dingen nachlesen (der teil ist gar nicht mal so lang), das dürfte zu einem teil auch auf Software zeug anwendbar sein. wobei dort das URG[1] (Urheberrecht) noch relevant sein dürfte, für all das zeug rund um geistiges Eigentum (ich glaube das fehlt in meinem Buch). Ja, da könnte ich nachlesen, wie das genau funktioniert. Könnte... Aber gilt ja eh nur in der Schweiz, bringt mir vermutlich eh nicht viel. Wie auch immer, ob du jetzt eine Lizenz kaufst, oder die geschenkt bekommst, normalerweise bekommst du schon irgendwoher eine. > Bin ich dann Kunde? Gute frage. Ich bin mir nicht sicher, ob das irgendwo überhaupt formal definiert ist. Da kann ich nur meine eigene Sichtweise bringen. Was bedeutet es wirklich, Kunde zu sein? Wenn ich dir was schenke, hast du vermutlich keine Garantie Ansprüche usw. In gewissen sinne bist du vermutlich schon ein Kunde, aber wer würde wen wann wirklich als Kunde betrachten? Ehrlich gesagt betrachte ich mich nicht als Kunde, wenn ich Zeugs geschenkt kriege. Und andere, die meinen Code gratis nutzen, (den ich nicht Verkaufe), sehe ich auch nicht als Kunde. Wenn mir Fehler gemeldet werden, und ich hab genug infos, fix ich die normalerweise schon. Aber wenn jemand echten Support für seine Probleme usw. will, nö, keine Lust. Das soll er sich woanders kaufen. Also für mich ist man schon erst Kunde, sobald Geld fliesst. [1] https://www.fedlex.admin.ch/eli/cc/1993/1798_1798_1798/de
DPA schrieb: > Bilder, Filme, Musik (oft separat Aufzeichnung, Vorführung, Noten, Texte Vielen Dank für diesen riesigen Offtopic-Ausflug. Dann können wir ja hoffentlich zum Threadthema zurückkommen. Ja?
DPA schrieb: > Das ganze ist etwas kompliziert Ich stimme dir im Großen und ganzen zu und erwarte auch keine Antwort auf meine Fragen (ich hatte nur auf eine ernst gemeinte Antwort von MaWin auf die erste Frage gehofft ...). Ich möchte es an zwei Stellen aber noch etwas komplizierter machen ;-). DPA schrieb: >> Was ist mit Software, die ich nicht gekauft oder beschafft habe aber trotzdem nutze? > Um diese nutzen zu können, brauchst du trotzdem eine Vertrag/Lizenz, die > dir das erlaubt. Um sie legal nutzen zu können. Wäre ich ein Kunde, wenn ich sie illegal nutzen würde? Was ist wenn mein Arbeitgeber der Käufer ist? DPA schrieb: > Ehrlich gesagt betrachte ich mich nicht als Kunde, wenn ich > Zeugs geschenkt kriege. Und andere, die meinen Code gratis nutzen, (den > ich nicht Verkaufe), sehe ich auch nicht als Kunde. Das umgeht auch ein weiteres Problem. Wenn man Software für sich selbst entwickelt und nutzt, ist man dann sein eigener Kunde? MaWin schrieb: > DPA schrieb: >> Bilder, Filme, Musik (oft separat Aufzeichnung, Vorführung, Noten, Texte > > Vielen Dank für diesen riesigen Offtopic-Ausflug. > Dann können wir ja hoffentlich zum Threadthema zurückkommen. Ja? Ich habe gedacht, die Qualität des rust-Compilers ist essenziell, um die Frage "Rust - ist das hier um zu bleiben?" zu beantworten. Und dafür müssen wir wohl erstmal klären was Kunden sind, denn: MaWin schrieb: > Nop schrieb: >> Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt > > Qualität ist die Abwesenheit von Kundenreklamationen.
Mombert H. schrieb: > Und dafür müssen wir wohl erstmal klären Es ist alles beantwortet. Deshalb werde ich dazu auch nichts mehr sagen. Dass dir die Antworten nicht in den Kram passen, ist mir klar. Aber damit musst du dann wohl leben.
In diesem Forum tummeln sich so dermaßen viele Leute die jeden kleinsten Satz dazu nutzen um eine riesen Off Topic Diskussion von der Leine zu lassen und dann ewig drauf rum zu reiten Meistens wenn das Thema trivial oder irgendeine scheinbare nähe zu ihrem Fachgebiet aufweisst, oder man sich gar nicht mit dem Kern Topic auskennt und einfach nur quasseln will, Heise-Forumskultur in reinform Es ist idiotisch gegen eine 5 Jahre alte Sprache zu wettern die keinem ein Haar krümmt und mehr oder minder bekannte Strategien besser integriert, so lange die nutzung nicht erzwungen wird ist jede Argumentation sinnfrei, wenn sich Rust trotz der ganzen schwächen etabliert ist die komplette Community ein der ihr euch befindet eben nicht klug, wenn Rust stirb ist nichts verloren Diskutiert doch lieber mit MaWin über die Vor/Nachteile dieser oder jener Konstruktion von Rust als all die alten Kammellen die jeder kennt und versteht und nur ihr denkt das jemand die nicht genauso gut vestanden habt wie ihr durchzubeten/kauen alte Kamellen: -statische Codeanalyse reicht völlig aus -Sanitizer machen alles perfekt -schreib einfach guten Code dann ist auch ok -ohne ISO standard kann ich nicht leben -ohne zertifizierung kann ich nicht leben -wenn es nicht von allen Herstellern unterstuetzt wird ist es nichts wert -wenn es nicht jedes problem ob syntaktisch, ausdruckstaerke oder logisch löst ist es nix wert -Es kompiliert langsam, also ist es nichts wert Solche Kommentare können nicht von versierten und erfahrenen Entwickler mit grossen Team und Projekterfahrungen kommen denn das alles sind schon 100% genutzte und bekannte probleme und wissen, nur der kleingeist denkt man müsse damit noch misionieren gehen, das ist alles ausgetretenes standardwissen, auch wenn manche das hier nicht verstehen weil ihre Welten so klein und überschaubar sind Also reisst euch mal zusammen ihr Nörgelfritzen und bleibt bei der Sache
Ich kann mich gar nicht erinnern, dass hier jemand gegen Rust "gewettert" hätte. Was kritisiert worden ist ist, dass man mit der neuen Sprache auch gleich mal noch das 43. neue Buildsystem etabliert und ziemlich stark verbandelt hat.
Jörg W. schrieb: > Was kritisiert worden ist ist, dass man mit der neuen Sprache auch > gleich mal noch das 43. neue Buildsystem etabliert und ziemlich stark > verbandelt hat. Jörg, auch du warst gemeint mit: cppbert3 schrieb: > Meistens wenn das Thema trivial oder irgendeine scheinbare nähe zu ihrem > Fachgebiet aufweisst, oder man sich gar nicht mit dem Kern Topic > auskennt und einfach nur quasseln will, Heise-Forumskultur in reinform Die Sache mit dem angeblich stark verbandelten Buildsystem ist bereits mehrfach beantwortet. Dir passt die Wahrheit nur nicht. Das akzeptiere ich. Nun akzeptiere doch auch du die Realität. Auch das zehnte Infragestellen wird zu den gleichen Antworten führen.
MaWin schrieb: > Dir passt die Wahrheit nur nicht. Mir ist sie (zumindest derzeit) schlicht egal. Wenn ich aber eine Sprachbeschreibung sehe, die mir zugleich ein bestimmtes Buildsystem schmackhaft machen möchte ("Hello Cargo!" kommt gleich nach "Hello World!"), dann kannst du mir 10mal erzählen, die seien nicht verbandelt. Irgendwie sind sie es, sonst hätten sich die Autoren des Rust-Buchs nicht die Mühe gemacht, Cargo ein eigenes Kapitel zu widmen.
Jörg W. schrieb: > Wenn ich aber eine Sprachbeschreibung sehe, die mir zugleich ein > bestimmtes Buildsystem schmackhaft machen möchte ("Hello Cargo!" kommt > gleich nach "Hello World!"), Ja, genau. Das erste Beispiel "Hello World" im Buch ist komplett ohne Cargo. Komisch, gell? Wo man doch ohne Cargo praktisch nichts machen kann, weil es ja angeblich so stark verbandelt ist. Mal ganz davon abgesehen, dass Cargo halt sehr gut ist und es vielleicht deshalb so gerne genutzt wird. Mit einer "starken Verbandelung" hat das nichts zu tun. Aber was schreibe ich hier. Das ist alles ja schon mehrfach erklärt worden.
MaWin schrieb: > Ja, genau. Das erste Beispiel "Hello World" im Buch ist komplett ohne > Cargo. > Komisch, gell? "Hello World"- Beispiele für C kompilieren i.d.R. mit "gcc main.c -o main" oder so. Komplett ohne jedes Build-System. Auch komisch, oder? Oliver
Jörg W. schrieb: > MaWin schrieb: > >> Dir passt die Wahrheit nur nicht. > > Mir ist sie (zumindest derzeit) schlicht egal. > Wenn ich aber eine Sprachbeschreibung sehe, die mir zugleich ein > bestimmtes Buildsystem schmackhaft machen möchte ("Hello Cargo!" kommt > gleich nach "Hello World!"), dann kannst du mir 10mal erzählen, die > seien nicht verbandelt. Irgendwie sind sie es, sonst hätten sich die > Autoren des Rust-Buchs nicht die Mühe gemacht, Cargo ein eigenes Kapitel > zu widmen. Alte Kamelle: Buildsystemzwang, alles kommt aus dem Internet, Entwickler arbeiten nur noch mit third parties, validierungsproblematik Wenn du so wie ich bei jedem Kunden ein anderes Buildsystem nutzen müsstes würde dich das vielleicht gar nicht mehr so stören, Rust schafft mit Cargo wenigstens eine gemeinsame Basis auch wenn es, was garantiert passieren wird nacher 2-3 Cargo clone geben wird, weil vielleicht doch zu viel fehlt wird ein grossteil diesen Pseudostandard verwenden und das ist, egal wie du es drehst und wendest erstmal keine absolut problematische Situation - und wenn es auch nur die Rust Entwickler zwingt ihre Sprache auch in einem buildsystem kontext zu betrachten z.B. bei C++ warten wir alle auf Module, nur die meisten Buildsystem haben riesige Probleme auf Modulveraenderungen zu reagieren, weil es da keinen Standard gibt wie die intermediate Dateien heissen können usw. - weil sich die C++ Chairs immer schon einen dreck um die Infrastruktur um die sprache gekümmert haben, das ist z.B. auch der grund warum der Prepozessor so lange nicht teil des Standards war, die hatten keinen Bock auf die Verantwortung und haben das so weit wie möglich den Benutzern/Toolchainentwicklern aufgebürdet Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit stark integrierten Buildsystemen auf den Markt geworfen wurden
Oliver S. schrieb: > MaWin schrieb: > >> Ja, genau. Das erste Beispiel "Hello World" im Buch ist komplett ohne >> Cargo. >> Komisch, gell? > > "Hello World"- Beispiele für C kompilieren i.d.R. mit "gcc main.c -o > main" oder so. Komplett ohne jedes Build-System. Auch komisch, oder? > Oliver Das ist doch alles jedem bekannt, und das ist auch nichts was MaWin hier beschreitet oder als Argument für irgendwas verwendet Was soll so ein Post bewirken?
cppbert3 schrieb: > Das ist doch alles jedem bekannt, und das ist auch nichts was MaWin hier > beschreitet oder als Argument für irgendwas verwendet Doch, genau das war das Argument: Rust ist gar nicht mit Cargo verbandelt, weil das Hello-World-Beispiel im Buch ohne auskommt. Oliver
Oliver S. schrieb: > cppbert3 schrieb: > >> Das ist doch alles jedem bekannt, und das ist auch nichts was MaWin hier >> beschreitet oder als Argument für irgendwas verwendet > > Doch, genau das war das Argument: Rust ist gar nicht mit Cargo > verbandelt, weil das Hello-World-Beispiel im Buch ohne auskommt. > Oliver Er hat doch nur bestätig das es gleichwertig ist, du kannst alles ohne und alles mit dem buildsystem machen, und das stand hier schon vor monaten und wird immer und immer wieder rausgekramt, wie langweilig
cppbert3 schrieb: > Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit > stark integrierten Buildsystemen auf den Markt geworfen wurden Die haben ein integriertes Laufzeitsystem, insofern kannst du für die eher Python als Vergleich heranziehen als Rust, C oder FORTRAN.
Jörg W. schrieb: > cppbert3 schrieb: >> Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit >> stark integrierten Buildsystemen auf den Markt geworfen wurden > > Die haben ein integriertes Laufzeitsystem, insofern kannst du für die > eher Python als Vergleich heranziehen als Rust, C oder FORTRAN. über Laufzeitsystem haben wir hier doch bisher noch gar nicht gesprochen? ich bezog mich eher drauf das es kein Link System gibt sondern der Quelltext mehr oder weniger direkt seine Abhängigkeiten vorschreibt - so wie mit Turbo Pascal in grauer Vorzeit
cppbert3 schrieb: > ich bezog mich eher drauf das es kein Link System gibt sondern der > Quelltext mehr oder weniger direkt seine Abhängigkeiten vorschreibt Das ist aber durch das integrierte Laufzeitsystem ohnehin gesetzt. Daher der Vergleich mit Python. Der Anspruch eines Systems, das mit einem Linker arbeitet, ist ja eher, dass man Komponenten von möglichst vielen verschiedenen Welten miteinander integrieren kann. (Womit ich nicht behaupten will, dass das bei Rust nicht gehen würde.)
Jörg W. schrieb: > Das ist aber durch das integrierte Laufzeitsystem ohnehin gesetzt. Daher > der Vergleich mit Python. ich verstehe den Bezug immer noch nicht - ich möchte nur zum Ausdruck bringen das Build-Unit Abhängigkeiten in anderen Sprachen wie C#, Java und z.B. auch Turbo Pascal schon teil des Sprachstandards sind also so eine Art Sprach-Integriertes Buildsystem und sich da auch keiner beschwert hat bei C oder C++ (erst mit Modulen) gibt es so was gar nicht - ohne Preprozessor und Linker sind die einzelnen Build-Units völlig hilflos in der Luft umherfliegend - alles überentkoppelt weil C/C++ lange Zeit selbst das Konzept-von "Dateien" als zu grosse Abhängigkeit empfunden hat
Jörg W. schrieb: > Der Anspruch eines Systems, das mit einem Linker arbeitet, ist ja eher, > dass man Komponenten von möglichst vielen verschiedenen Welten > miteinander integrieren kann. das war nicht die Grundintension bei C/C++ - da wollte man nur mit Gewalt jeden Kontakt zwischen den "Dateien" vermeiden, weil Dateien damals noch kein durchgesetztes Konzept waren und es eher darum ging den Prozess in möglichst viele Teilschritte zu zerlegen weil der geringe Speicher der damaligen System einfach zu schnelle an die grenze gestoßen ist - viele der heutigen Entwickler vergessen völlig wo das alles mal angefangen hat
In einer perfekten Welt, die ich mir in meinem wirren Kopf so zusammenspinne, hätte ich auch gerne das eine perfekte Buildsystem, das mit allen Sprachen funktioniert und das alle Features genau so hat, wie jeder das will. Leider ist das nicht die Realität. Die Rustentwickler haben mit Cargo ein ziemlich gutes Buildsystem geschaffen, das viele Sachen sehr elegant löst. Standardisiertes Buildmanifest mit gutem Options- und Dependency-Management. Sehr schöne Integration von Unit-Tests, System-Tests und Beispielprogrammen. Sehr gute UX. Es funktioniert ganz einfach out of the box. Das sind so die Dinge, die mir spontan einfallen. Es gibt sicher noch viel mehr. Und trotzdem ist es eben nicht fest verbandelt. Es steht dem Entwickler frei, ob er dieses gute Angebot annimmt. Und natürlich nehmen die meisten Entwickler dieses Angebot an, weil es ganz einfach sehr gut funktioniert.
cppbert3 schrieb: > Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit > stark integrierten Buildsystemen auf den Markt geworfen wurden Die nutze ich privat einfach nicht. Früher in der Schule und bei der Arbeit gab es noch etwas Java, bis ich das später endlich alles ersetzen durfte. Wobei, in Java kann man Dateien haben, die exklusiv für ein Interface sind. Und ich kann Code Kompilieren & Ausführen, der Interfaces nutzt, ohne dabei die Implementation kennen zu müssen (Ich kann sogar eine zur Runtime nachladen usw., und auch noch ziemlich simpel.) Und auch wenn die Klassen, die man importiert, zum Kompilieren vorhanden sein müssen, das ist glaube ich bei Java immerhin nicht rekursiv. Eigentlich hat Java das noch vergleichsweise gut gelöst. Und das Generics Konzept gefällt mir ehrlich gesagt auch recht gut, ziemlich inspirierend aus technischer Sicht wenn man sich harte Templates gewohnt ist.
Daniel A. schrieb: > Eigentlich hat Java > das noch vergleichsweise gut gelöst. Und das Generics Konzept gefällt > mir ehrlich gesagt auch recht gut, Das ist sehr erfreulich. Aber da es hier im Thread um Rust geht: Wie gefallen dir Rust Generics denn so?
Daniel A. schrieb: > cppbert3 schrieb: >> Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit >> stark integrierten Buildsystemen auf den Markt geworfen wurden > > Die nutze ich privat einfach nicht. Früher in der Schule und bei der > Arbeit gab es noch etwas Java, bis ich das später endlich alles ersetzen > durfte. wie gesagt - bei Java/C# und Konsorten ist das alles Teil des Sprachstandards - bei C/C++ nicht - und Rust nutzt einen Teil dieser Konzepte
cppbert3 schrieb: >> Der Anspruch eines Systems, das mit einem Linker arbeitet, ist ja eher, >> dass man Komponenten von möglichst vielen verschiedenen Welten >> miteinander integrieren kann. > > das war nicht die Grundintension bei C/C++ Für C schon, denn das musste unbedingt mit Assemblercode kombiniert werden können, und FORTRAN war zu der Zeit vermutlich das, was heute C ist. Für Rust wurde ja zumindest gesagt, dass es mit einer C-Umwelt klar kommt. Muss es eigentlich auch, denn bis mal alles Wichtige in Rust verfügbar ist, werden schon noch ein paar Jahrzehnte vergehen.
MaWin schrieb: > Jörg W. schrieb: >> denn bis mal alles Wichtige in Rust verfügbar ist > > Was ist denn "alles Wichtige"? Alles, was täglich gebraucht wird. Wenn du in der Lage bist, einen normalen Desktop-Computer mitsamt seiner "Zutaten" (Browser, Editor, Office, Bildbearbeitung, PDF-Viewer etc. pp.) und dem zugrunde liegenden Betriebssystem mit Rust zu bauen (also nicht nur theoretisch, sondern ganz praktisch), dann dürfte der Punkt erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen geschriebener Bibliotheken nicht mehr so wichtig ist. Wobe, FORTRAN hängt uns ja selbst heute noch hinterher, numpy oder Matlab lassen da grüßen.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Wenn du in der Lage bist, einen normalen Desktop-Computer mitsamt seiner > "Zutaten" (Browser, Editor, Office, Bildbearbeitung, PDF-Viewer etc. > pp.) und dem zugrunde liegenden Betriebssystem mit Rust zu bauen Nutzer von Gentoo & co. tun mir jetzt schon leid. "emerge -uDN @world" - und jetzt warten wir mal einen Monat...
Jörg W. schrieb: > dann dürfte der Punkt > erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen > geschriebener Bibliotheken nicht mehr so wichtig ist. Warum sollte man den Punkt anstreben wollen? Was hat das überhaupt mit Rust zu tun? Rust ist gut interoperabel mit anderen Sprachen. By Design. In Gegensatz zu C. C ist nur mit C kompatibel. Deshalb muss sich der Rest der Welt darum kümmern mit C kompatibel zu sein. Und das tut Rust sehr gut. Heute.
Daniel A. schrieb: > Nutzer von Gentoo & co. tun mir jetzt schon leid. Die tun mir schon länger leid. Nicht erst, seit es Rust gibt. SCNR.
MaWin schrieb: > Jörg W. schrieb: >> dann dürfte der Punkt >> erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen >> geschriebener Bibliotheken nicht mehr so wichtig ist. > > Warum sollte man den Punkt anstreben wollen? "unsafe" > Was hat das überhaupt mit Rust zu tun? Rust ist gut interoperabel mit > anderen Sprachen. By Design. "unsafe" > In Gegensatz zu C. C ist nur mit C > kompatibel. Deshalb muss sich der Rest der Welt darum kümmern mit C > kompatibel zu sein. Und das tut Rust sehr gut. Heute. "unsafe"
Jörg W. schrieb: > Für Rust wurde ja zumindest gesagt, dass es mit einer C-Umwelt klar > kommt. Muss es eigentlich auch, denn bis mal alles Wichtige in Rust > verfügbar ist, werden schon noch ein paar Jahrzehnte vergehen. "zumindest gesagt" "muss es eigentlich" wurde schon sooo oft hier geschrieben - warum vermuten/fabulieren? Rust kann direkt mit C gelinkt werden
MaWin schrieb: > Jörg W. schrieb: >> dann dürfte der Punkt >> erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen >> geschriebener Bibliotheken nicht mehr so wichtig ist. > > Warum sollte man den Punkt anstreben wollen? Es war die Antwort auf deine Frage. Wenn du der Meinung bist, dass das gar nicht anstrebenswert ist, dann hättest du dir deine Frage auch sparen können. > In Gegensatz zu C. C ist nur mit C > kompatibel. Wenn du derartige Äußerungen weglassen würdest, würde das deiner Glaubwürdigkeit gut zu Gesicht stehen. So tust du Rust einfach keinen Gefallen, weil sich jeder sagt: "Wenn deren Fanboys alle so sind, will ich damit nichts zu tun haben."
cppbert3 schrieb: > wurde schon sooo oft hier geschrieben - warum vermuten/fabulieren? Ich vermute oder fabuliere nicht, habe es nur selbst nicht verifiziert. Daher als Aussage anderer kenntlich gemacht. Aber darum ging es gar nicht, sondern um deine Behauptung, dass es keine Intention gewesen wäre, dass C via Linker mit anderen Sprachen zusammen arbeitet. Die entbehrt jeglicher Grundlage.
Mombert H. schrieb: > MaWin schrieb: >> Jörg W. schrieb: >>> dann dürfte der Punkt >>> erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen >>> geschriebener Bibliotheken nicht mehr so wichtig ist. >> >> Warum sollte man den Punkt anstreben wollen? > "unsafe" >> Was hat das überhaupt mit Rust zu tun? Rust ist gut interoperabel mit >> anderen Sprachen. By Design. > "unsafe" >> In Gegensatz zu C. C ist nur mit C >> kompatibel. Deshalb muss sich der Rest der Welt darum kümmern mit C >> kompatibel zu sein. Und das tut Rust sehr gut. Heute. > "unsafe" das ist doch jedem absolut klar, oder? und selbst wenn nicht, 5min Rust Doku lesen und aufhören zu vermuten wie soll Rust den bitte externe Abhängigkeiten safe einbinden? Rust ist eine Systemsprache die nicht an jeder Ecke Prüfcode einbaut und auch nur deshalb überhaupt für Kernel-Entwicklung und High-Performanz relevant sein kann diese episch tiefen Diskussionen über Kompiletime/Statische-Prüfbarkeit usw. scheitert hier häufig daran das irgendwelche Leute denke das Safe-Rust meint das alles geprüft wird oder Safe-Rust meint es sollte dann aber auch keine Fehler mehr geben - das ist doch Mathematisch/Systemisch gar nicht möglich - und auch die Rust Leute können nicht die Natur der Software-Probleme per se lösen sondern nur stark abschwächen viele Leute finde "abschwächen" ist schon toll genug - auch wenn viele der Pro-Entwickler hier das 0 nachvollziehen können - weil ihr Code ja keine Fehler hat, oder ihre Team-Mitglieder alle gleich gut sind,...
Jörg W. schrieb: > Aber darum ging es gar nicht, sondern um deine Behauptung, dass es keine > Intention gewesen wäre, dass C via Linker mit anderen Sprachen zusammen > arbeitet. Die entbehrt jeglicher Grundlage. das ist doch jedem Entwickler 100% klar, oder? warum hier immer alle davon ausgehen das der Gesprächspartner nur 30% von der Medaille kennt? Genau diese Denke führt hier zu diesen endlosen Tiefen-Diskussionen über banale Themen - Kompiletimeprüfung, Sanitizer, Zertifizierung, Entwicklungsprozesse - das sind alles alte Hüte die jeder kann und macht - und wenn man das dann so überdeutlich ausdrückt kommt hier jeder und erklärt wie relevant die Themen sind - als wäre das irgendjemanden nicht klar Es ist nur einfach völlig unrelevant für den jetzigen Entwicklungstand von Rust - und war es auch vor Jahrzehnten für C/C++ und alle anderen jungen Programmiersprachen und jetzt hört doch bitte auf immer in diesen Micro-Themen zu rotieren
Jörg W. schrieb: >> In Gegensatz zu C. C ist nur mit C kompatibel. > Wenn du derartige Äußerungen weglassen würdest, würde das deiner > Glaubwürdigkeit gut zu Gesicht stehen. Ach? Mit welchen Sprachen ist C denn so kompatibel? Und wie sieht das C-Konstrukt aus, mit dem man z.B. angibt, dass Funktion X ein zur Sprache Y kompatibles ABI erhalten soll? Ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind, und nicht umgekehrt? Jörg W. schrieb: > So tust du Rust einfach keinen > Gefallen, weil sich jeder sagt: "Wenn deren Fanboys alle so sind, will > ich damit nichts zu tun haben." Wenn ein Programmierer seine Wahl der Programmiersprache von pseudonymen Posts von MaWin auf Mikrocontroller.net abhängig macht, dann ist diesem Programmierer eh nicht mehr zu helfen.
cppbert3 schrieb: > das ist doch jedem absolut klar, oder? > und selbst wenn nicht, 5min Rust Doku lesen und aufhören zu vermuten Könntest du kurz erklären was jedem klar ist? Und was die Doku damit zu tun hat? Ich verstehe nicht was du hier sagen willst. cppbert3 schrieb: > wie soll Rust den bitte externe Abhängigkeiten safe einbinden? Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg. Was du mit dem Rest deiner Tirade ausdrücken willst, weiß ich auch nicht.
Mombert H. schrieb: > cppbert3 schrieb: >> das ist doch jedem absolut klar, oder? >> und selbst wenn nicht, 5min Rust Doku lesen und aufhören zu vermuten > Könntest du kurz erklären was jedem klar ist? Und was die Doku damit zu > tun hat? Ich verstehe nicht was du hier sagen willst. das externe Abhängigkeiten unsafe eingebunden werden muessen klar ist - sonst müsste Rust entweder sau langsam sein (wegen Prüfungen) oder irgendein magisches Konzept haben unsafes safe zu machen > cppbert3 schrieb: >> wie soll Rust den bitte externe Abhängigkeiten safe einbinden? > Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg. jetzt verstehe ich dich nicht - d.h. alles in Rust schreiben??? wie soll ich sonst die Abhängigkeiten los werden? > Was du mit dem Rest deiner Tirade ausdrücken willst, weiß ich auch > nicht. ist nicht so schlimm, dauert noch ein bisschen
Mombert H. schrieb: > Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg. Nein, "müssen" sie nicht. Warum sollten sie das "müssen"? Eine externe Bibliothek ist exakt genau so zu handhaben, wie unsafe-Blöcke in Rust. Da gibt es sogar ein Buch drüber, wenn du wissen willst, wie das geht: https://doc.rust-lang.org/nomicon/ (work in progress) Es ist doch völlig weltfremd anzunehmen, dass plötzlich alle Software der Welt nur noch in Rust geschrieben werden wird.
cppbert3 schrieb: > sonst müsste Rust entweder sau langsam sein (wegen Prüfungen) Ich dachte wir hätten abschließend geklärt, dass Safe-Rust im Mittel nicht langsamer ist als äquivalenter sicherer C-Code? Das ist ein Rust-Designziel.
cppbert3 schrieb: > Mombert H. schrieb: >> cppbert3 schrieb: >>> das ist doch jedem absolut klar, oder? >>> und selbst wenn nicht, 5min Rust Doku lesen und aufhören zu vermuten >> Könntest du kurz erklären was jedem klar ist? Und was die Doku damit zu >> tun hat? Ich verstehe nicht was du hier sagen willst. > > das externe Abhängigkeiten unsafe eingebunden werden muessen klar ist - > sonst müsste Rust entweder sau langsam sein (wegen Prüfungen) oder > irgendein magisches Konzept haben unsafes safe zu machen Ok, was genau hat das mit dem ursprünglich (und natürlich von dir ausgelassenen) Beitrag zu tun, auf den du geantwortet hast? >> cppbert3 schrieb: >>> wie soll Rust den bitte externe Abhängigkeiten safe einbinden? >> Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg. > > jetzt verstehe ich dich nicht - d.h. alles in Rust schreiben??? > wie soll ich sonst die Abhängigkeiten los werden? Wtf? >> cppbert3 schrieb: >> Was du mit dem Rest deiner Tirade ausdrücken willst, weiß ich auch >> nicht. > > ist nicht so schlimm, dauert noch ein bisschen ...
MaWin schrieb: > cppbert3 schrieb: >> sonst müsste Rust entweder sau langsam sein (wegen Prüfungen) > > Ich dachte wir hätten abschließend geklärt, dass Safe-Rust im Mittel > nicht langsamer ist als äquivalenter sicherer C-Code? Das ist ein > Rust-Designziel. das ist mir klar - ich fragte mich nur weiso Mombert H. überall unsafe geschrieben hatte in seinem Post - als wäre das was schlechtes, und dann meinte wir müssen die "Abhängigkeiten los werden" - aber laut seinem letzten Post "ohne neu schreiben in Rust" - keine Ahnung was er überhaupt meint
Mombert H. schrieb: >> das externe Abhängigkeiten unsafe eingebunden werden muessen klar ist - >> sonst müsste Rust entweder sau langsam sein (wegen Prüfungen) oder >> irgendein magisches Konzept haben unsafes safe zu machen > Ok, was genau hat das mit dem ursprünglich (und natürlich von dir > ausgelassenen) Beitrag zu tun, auf den du geantwortet hast? > >>> cppbert3 schrieb: >>>> wie soll Rust den bitte externe Abhängigkeiten safe einbinden? >>> Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg. >> >> jetzt verstehe ich dich nicht - d.h. alles in Rust schreiben??? >> wie soll ich sonst die Abhängigkeiten los werden? > Wtf? ich habe direkt auf einen Post geantwortet wo du überall "unsafe" hingeschrieben hast und ich mich gewundert hatte wie man sonst externen Code einbinden soll auf den das Rust Sicherheitskonzept keinen Einfluss hat dann kam dein Kommentar mit den "deswegen müssen die Abhängigkeiten ja weg" womit ich völlig verloren bin und dachte du meinst das die externen Abhängigkeiten in Rust geschrieben werden müssen - weil ich sonst nicht verstehe was das "Abhängigkeiten ja weg" in diesem Kontext sonst bedeuten könnte
MaWin schrieb: > ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind Nein, sind sie nicht. Mit deiner Argumentation ist wohl jede Sprache nur mit sich selbst kompatibel, denn sie kennt Konstrukte, die sich nicht in einer anderen ausdrücken lassen. Ein Pascal-Array-Argument kannst du beispielsweise in C nicht ausdrücken, denn es übergibt außer der Adresse auch seinen Indexbereich an den Aufgerufenen. Eine variadische Argumentliste in C wirst du wiederum in Pascal nicht aufgedröselt bekommen. Kompatibilität ist folglich immer der kleinste gemeinsame Nenner zwischen beiden Seiten.
cppbert3 schrieb: > ich fragte mich nur weiso Mombert H. überall unsafe > geschrieben hatte in seinem Post - als wäre das was schlechtes, Ja. Das ist richtig. Unsafe-Codeteile, unter die auch externe Bibliotheken fallen, sind nicht schlecht. Es ist gar nicht so, dass Rustentwickler jetzt plötzlich losrennen und alle Unsafe-Teile eliminieren wollen. Ganz im Gegenteil. Unsafe-Code ist in Ordnung. Es bedeutet nur, dass dieser Code erheblich mehr Review und Testing erfahren muss. Es ist ja auch gar nicht alles in Safe-Rust formulierbar, was formuliert werden muss. Je näher man an die Hardware kommt, desto mehr unsafe-Blöcke werden notwendig werden. Das Ziel ist es jedoch, diese unsafe-Blöcke in entsprechenden Safe-Rust-Modulen zu wrappen. Und genau das passiert auch mit externen Bibliotheken.
MaWin schrieb: > Ach? Mit welchen Sprachen ist C denn so kompatibel? > Und wie sieht das C-Konstrukt aus, mit dem man z.B. angibt, dass > Funktion X ein zur Sprache Y kompatibles ABI erhalten soll? Wie soll den C die Datentypen und sonstigen Eigenheiten zukünftiger Sprachen unterstützen? Und wozu? C ist sehr alt, stabil, simpel, und bietet alles nötige, damit andere Programme mit ihm interoperieren können. Das ABI ist auch überall relative stabil und gut definiert. Zusammen mit seiner Verbreitung ist es daher heute mit so ziemlich jeder Sprache kompatibel. Oft verwendet man es sogar, um verschiedene Sprachen verbinden zu können. Es bietet sich in seiner jetzigen Form und Verbreitung dafür gerade zu an. Auch wenn es dank historischer & designtechnischer Gründe diese Interopabilität quasi gratis bekommen hat, das ändert aber nichts daran, dass sie vorhanden ist. Ausserdem, ist die ABI von Rust für die diversen Platformen mittlerweile endlich mal Stabil & Dokumentiert? Wobei, da müsste man vermutlich erst mal die Sprache selbst standardisieren? Wie soll man denn so damit überhaupt vollständig kompatibel sein können, im sinne von all seine Datentypen und APIs direkt nutzen können? Man könnte das also umkehren. C erlaubt es anderen Sprachen recht einfach, zu ihm kompatibel zu sein. Aber ist das bei Rust überhaupt möglich?
Jörg W. schrieb: > MaWin schrieb: >> ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind > > Nein, sind sie nicht. > > Mit deiner Argumentation ist wohl jede Sprache nur mit sich selbst > kompatibel, denn sie kennt Konstrukte, die sich nicht in einer anderen > ausdrücken lassen. Ein Pascal-Array-Argument kannst du beispielsweise in > C nicht ausdrücken, denn es übergibt außer der Adresse auch seinen > Indexbereich an den Aufgerufenen. Eine variadische Argumentliste in C > wirst du wiederum in Pascal nicht aufgedröselt bekommen. > > Kompatibilität ist folglich immer der kleinste gemeinsame Nenner > zwischen beiden Seiten. MaWin wollte sicherlich eher zum Ausdruck bringen das der Teil den wir alle kennen von C der meistgenutzte gemeinsame Nenner ist an dem sich viele orientieren - und ja das passt auch für vieles von Pascal - aber man spricht dann trotzdem oft von der C Kompatibilität - obwohl auch Sprachen die älter sind als C schon "C-Kompatible" waren Aber wie immer die Frage: Ist das wirklich Themen relevant?
Jörg W. schrieb: >> ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind > Nein, sind sie nicht. Krass, wie du krampfhaft versuchst deine falsche Argumentation aufrecht zu erhalten. C++ ist also nicht kompatibel zu C? extern "C"? Rust ist also nicht kompatibel zu C? Auch wenn man structs und Funktionen explizit die C-ABI geben kann? > Kompatibilität ist folglich immer der kleinste gemeinsame Nenner > zwischen beiden Seiten. Und C trägt aktiv exakt gar nichts dazu bei kompatibel zu irgendetwas zu sein. C ist einfach nur C, so wie es ist. C ist der kleinste gemeinsame Nenner, weil seine ABI so primitiv ist und weil es schlicht älter ist als alle anderen aktiv genutzten Sprachen. Es gibt kein C-Konstrukt, mit dem man die ABI auf die einer anderen Sprache anpassen kann.
MaWin schrieb: > Es ist gar nicht so, dass > Rustentwickler jetzt plötzlich losrennen und alle Unsafe-Teile > eliminieren wollen. Ganz im Gegenteil. Unsafe-Code ist in Ordnung. Es > bedeutet nur, dass dieser Code erheblich mehr Review und Testing > erfahren muss. viele denken man müsste alles nach Rust portieren keine Ahnung wo dieser (schon dem Wahnsinn nahe stehendem) Irrglaube herkommt sowas kenne ich nur von Anfängern oder Nur-eine-Sprach-Evangelisten (die zum Glück immer weniger im Business anzutreffen sind)
Daniel A. schrieb: > Es bietet sich in seiner jetzigen Form und > Verbreitung dafür gerade zu an. deswegen wird es ja auch direkt von Rust supportet, weil das schon so viele sprechen :) Daniel A. schrieb: > Aber ist das bei Rust überhaupt > möglich? gerade nicht weil die höherwertigen Konzepte sich recht schwerlich durch eine ABI pressen lassen ohne die Performanzvorteile zu verlieren - wie bekommt man ein Kompiletime Ownership-Konzept durch eine Library/Dll-Grenze - nicht so einfach Ich könnte mir vorstellen das sie eine Rust zu Rust ABI hinbekommen aber eine Rust zu C ABI mit allen Rust-Features wird echt schwer ist aber vergleichbar mit den Schwierigkeiten C++, C#, Java Konzepte mit C zu verbinden
MaWin schrieb: > Jörg W. schrieb: >>> ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind >> Nein, sind sie nicht. > > Krass, wie du krampfhaft versuchst deine falsche Argumentation aufrecht > zu erhalten. > C++ ist also nicht kompatibel zu C? extern "C"? > Rust ist also nicht kompatibel zu C? Auch wenn man structs und > Funktionen explizit die C-ABI geben kann? Jörg hat technisch schon recht mit seinem kleinsten gemeinsamen Nennen was die Datenbereite/Typen angeht (das ist aber eher ein Hardware-Standard) aber spätestens bei Calling-Conventions hat MaWin recht - da ist es das C-Standard(Subset) mit cdecl das supported wird oder auch z.B. die typischen C-Strings die meisten Sprachen sprechen auch explizit von C Kompatibilität ansonsten sind alle Sprache erstmal nur zu sich selbst kompatibel (oder dem C-Standard-Subset) im Detail geht es bei der Kompatiblität nur um die Stabilität der ABI - ob die sich jetzt C oder whatever schimpft ist unrelevant
cppbert3 schrieb: > Ich könnte mir vorstellen das sie eine Rust zu Rust ABI hinbekommen also z.B. gibt es zwei Rust DLLs (A und B) die unterschiedliche Heaps haben und wenn die B-DLL Heap-Daten von der A-DLL ownen will das es dann eine besondere Form von Big/Fat-Pointer oder sowas gibt und es laut der ABI klar ist das es dann Performanprobleme geben kann wenn die Heap-Daten Löschung an A delegiert werden muss - oder eine Art Copy-on-transfer-Konzept Alles nicht sehr einfach und schwer generisch definierbar (soll es leicht sein, performant sein, etc.) ähnlich wie der Design-Trouble mit Async - nur noch viel komplizierter
cppbert3 schrieb: > also z.B. gibt es zwei Rust DLLs (A und B) die unterschiedliche Heaps > haben das Problem ist vergleichbar mit std::vector über DLL-Grenze mit unterschiedlichen Heaps aber ich habe immer noch die Hoffnung das Rust hier auch irgendwann mal mit einem besseren Konzept kommt als wie bisher: -Alles nur per Value -Alles auf eine C-artige API runterbrechen -Alles mit Interfaces auf dem Heap/Ref-Counted ohne unterschiedliche Heaps gibt es keine Probleme
cppbert3 schrieb: > obwohl auch Sprachen die älter sind als C schon "C-Kompatible" waren FORTRAN übergibt alles in einer Parametertabelle, alle Parameter sind dort per Referenz übergeben – zumindest das FORTRAN, was älter ist als C. (Auf der PDP-11 wurde die Adresse der Tabelle in R5 übergeben.) Weiß nicht, ob sie inzwischen auch andere Aufrufkonventionen haben. Mit üblichen C-Konventionen ist das nicht kompatibel … > Aber wie immer die Frage: Ist das wirklich Themen relevant? Sicher nicht, aber ich habe die Diskussion, alles würde sich nur nach C richten müssen, auch nicht begonnen.
Jörg W. schrieb: >> Aber wie immer die Frage: Ist das wirklich Themen relevant? > > Sicher nicht, aber ich habe die Diskussion, alles würde sich nur nach C > richten müssen, auch nicht begonnen. aber sie auch nicht gestoppt - und jetzt auch noch ne Uralt PDP-11 mit ins Feld geworfen :)
Jörg W. schrieb: >> Aber wie immer die Frage: Ist das wirklich Themen relevant? > > Sicher nicht, aber ich habe die Diskussion, alles würde sich nur nach C > richten müssen, auch nicht begonnen. und dir haben die 2.98% die sich nicht nach C richten gereicht um die Diskussion weiter zu befeuern - meinetwegen auch 13.445% aber mehr gestehe ich dir da nicht an Relevanz zu :)
Hallo, cppbert3 schrieb: > und jetzt hört doch bitte auf immer in diesen Micro-Themen zu rotieren Was sind denn dann für dich "Macro-Themen" über die man diskutieren sollte? rhf
Roland F. schrieb: > Was sind denn dann für dich "Macro-Themen" über die man diskutieren > sollte? Rust-Macros, zum Beispiel. Sehr spannendes Thema.
Ich war jetzt mal ein paar Wochen weg und ein interessanteste Punkt der Diskussion war für mich, dass (a) der Rust-Compiler fehlerfrei ist (d.h. entsprechend der Sprachdefinition arbeitet); (b) die vielen Compilerversionen und -änderungen daher irrelevant sind; (c) man in Rust garnicht fehlerhaft programmieren kann, weil die Sprache Fehler schon vorher verhindert; (d) die Kompatiblität zu älteren Sprachstandards (nach Spezifikation) ausschließlich durch den Compiler sichergestellt wird; (e) Cargo und Rust überhaupt nichts miteinander zu tun haben. Ich hab nichts gegen Rust. Nur gegen tightly-coupled-garbage.
bevor hier wieder alle schreien https://www.golem.de/news/open-source-entwickler-sabotiert-eigene-vielfach-genutzte-npm-pakete-2201-162299.html das ist natürlich eine Gefahr - aber ich denke trotzdem das Rust oder auch npm oder auch vcpkg dafür einen dauerhaft sinnvolle Lösung finden müssen in diesem Fall ist aber scheinbar ein "verlässlicher" auf die dunkle Seite der Macht konvertiert - um so mehr das passiert um so eher gibt es sinnvolle Diskussionen wie man automatische und sichere Depenency-Management bauen kann mir ist klar das es keine 100% Lösung gibt, aber vielleicht ergeben sich ja zwitter-Strategien die doch ganz gut funktionieren
cppbert3 schrieb: > das ist natürlich eine Gefahr - aber ich denke trotzdem das Rust oder > auch npm oder auch vcpkg dafür einen dauerhaft sinnvolle Lösung finden > müssen Naja, ich glaube diese Lösung, so gut das eben geht, bietet crates.io bereits. Zitat Artikel: > durch das Löschen von Paketen. Das geht auf crates.io nicht. Natürlich ist man grundsätzlich davon abhängig, dass ein Entwickler nicht durchdreht und plötzlich Mist baut. Aber auf crates.io gilt das nur für neue Versionen. Wenn man bereits eine Version verwendet, dann garantiert crates.io, dass genau diese Version dauerhaft und unverändert bereitgestellt werden wird. Daran kann auch der Autor nichts ändern. Das zusammen mit Cargo.lock bedeutet, dass es nicht passieren kann, dass die eigene SW sich plötzlich anders verhält oder gar Schadsoftware einfließen kann. Um neue Dependency-Versionen einzupflegen, ist immer eine bewusste Interaktion des Entwicklers per cargo update notwendig.
cppbert3 schrieb: > um so mehr das passiert um so eher gibt es > sinnvolle Diskussionen wie man automatische und sichere > Depenency-Management bauen kann Erst machen - dann denken. Sehr gut.
MaWin O. schrieb: > Aber auf crates.io gilt das > nur für neue Versionen. Wenn man bereits eine Version verwendet, dann > garantiert crates.io, dass genau diese Version dauerhaft und unverändert > bereitgestellt werden wird. Daran kann auch der Autor nichts ändern. Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen und Urhaberrechte eingehalten werden? Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird?
Mombert H. schrieb: > Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen > und Urhaberrechte eingehalten werden? Ehm, warum sollte es? > Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird? Das ist, wie immer, das Problem des Autors. Also sollte er so etwas nicht tun. Deine Nebelkerze habe ich als solche erkannt.
Mombert H. schrieb: > Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen > und Urhaberrechte eingehalten werden? Nein. Es ist Aufgabe des Paketautors, seinen Code zu schreiben, zu paketieren und zu veröffentlichen. Das Repository hat damit nichts zu tun. Es ist Aufgabe aller Nutzer des Paketes, das Paket selbst sowie sämtliche zukünftigen Updates auf Lizenzverstöße, Fehler, Böswilligkeit und andere Rechtswidrigkeiten zu überprüfen, bevor sie in der eigenen Software verwendet werden. Praktisch also ein "update all please", gelegentlich gefolgt von "run my testsuite", wie man bei npm gerade schön sieht. (Sind ja nicht alle direkt betroffen. Nur viele.) Dieses Problem (oder ein Äquivalent) besteht grundsätzlich bei allen auf schnelle Releasezyklen ausgelegten Systemen. Cargo und crates.io sind da nicht besser oder schlechter, und die Grundidee kritisieren zählt in großen Teilen der Informatik als Gotteslästerung. MaWin O. schrieb: >> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird? > Das ist, wie immer, das Problem des Autors. Also sollte er so etwas > nicht tun. Falsch. Es ist ein Problem des Nutzers des Pakets, nicht des Autors des Pakets. Und wenn Pakete tatsächlich nicht gelöscht werden können, dann ist das sowieso ein interessantes Phänomen. Vielleicht brauchen wir, wie von cppbert3 vorgeschlagen, einfach mehr Sabotage. Damit kriegen wir die Probleme alle klein.
S. R. schrieb: > Vielleicht brauchen wir, wie von cppbert3 vorgeschlagen, einfach mehr > Sabotage. Damit kriegen wir die Probleme alle klein. Pass auf, was du dir wünschst! Beitrag "Re: Rust - ist das hier um zu bleiben?"
S. R. schrieb: >> Das ist, wie immer, das Problem des Autors. Also sollte er so etwas >> nicht tun. > Falsch. Es ist ein Problem des Nutzers des Pakets, nicht des Autors des > Pakets. Falsch? Es ist vielmehr das Problem des Autors und des Nutzers. Deshalb war meine Aussage nicht falsch, sondern richtig. > und die Grundidee kritisieren zählt in > großen Teilen der Informatik als Gotteslästerung. An einer sachlichen Diskussion ist jeder interessiert. > Dieses Problem (oder ein Äquivalent) besteht grundsätzlich bei allen auf > schnelle Releasezyklen ausgelegten Systemen. Cargo und crates.io sind da > nicht besser oder schlechter Cargo ist auf vieles ausgelegt. Aber mit Sicherheit nicht auf die schnelle Änderungen von Dependency-Versionen. Ganz im Gegenteil. Cargo lockt the Dependency-Versionen, wie ich bereits beschrieben habe, fest.
MaWin O. schrieb: > Mombert H. schrieb: >> Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen >> und Urhaberrechte eingehalten werden? > Ehm, warum sollte es? >> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird? > Das ist, wie immer, das Problem des Autors. Also sollte er so etwas > nicht tun. S. R. schrieb: > Es ist Aufgabe aller Nutzer des Paketes, das Paket selbst sowie > sämtliche zukünftigen Updates auf Lizenzverstöße, Fehler, Böswilligkeit > und andere Rechtswidrigkeiten zu überprüfen, bevor sie in der eigenen > Software verwendet werden. Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn dort veröffentliche Software gegen geltendes Recht verstößt?
Mombert H. schrieb: > MaWin O. schrieb: >> Mombert H. schrieb: >>> Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen >>> und Urhaberrechte eingehalten werden? >> Ehm, warum sollte es? >>> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird? >> Das ist, wie immer, das Problem des Autors. Also sollte er so etwas >> nicht tun. > > S. R. schrieb: >> Es ist Aufgabe aller Nutzer des Paketes, das Paket selbst sowie >> sämtliche zukünftigen Updates auf Lizenzverstöße, Fehler, Böswilligkeit >> und andere Rechtswidrigkeiten zu überprüfen, bevor sie in der eigenen >> Software verwendet werden. > > Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn > dort veröffentliche Software gegen geltendes Recht verstößt? ob crates.io durch sein Verhalten Rechtsbruch begeht hat doch mit der Sprache Rust absolut gar nicht zu tun - oder um was geht es dir? wie handhaben das vpckg, Conan, npm und die vielen anderen Package Manager - find das doch mal raus und berichtet hier
cppbert3 schrieb: > Mombert H. schrieb: >> MaWin O. schrieb: >>> Mombert H. schrieb: >>>> Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen >>>> und Urhaberrechte eingehalten werden? >>> Ehm, warum sollte es? >>>> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird? >>> Das ist, wie immer, das Problem des Autors. Also sollte er so etwas >>> nicht tun. >> S. R. schrieb: >>> Es ist Aufgabe aller Nutzer des Paketes, das Paket selbst sowie >>> sämtliche zukünftigen Updates auf Lizenzverstöße, Fehler, Böswilligkeit >>> und andere Rechtswidrigkeiten zu überprüfen, bevor sie in der eigenen >>> Software verwendet werden. >> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn >> dort veröffentliche Software gegen geltendes Recht verstößt? > ob crates.io durch sein Verhalten Rechtsbruch begeht hat doch mit der > Sprache Rust absolut gar nicht zu tun - oder um was geht es dir? Was willst du jetzt mit der Sprache, oder ist cargo und crates.io plötzlich doch Teil der Sprache? > wie handhaben das vpckg, Conan, npm und die vielen anderen Package > Manager - find das doch mal raus und berichtet hier Sie werden Pakete, die gegen die Regeln verstoßen, löschen. Aber das geht ja laut MaWin auf crates.io nicht.
Mombert H. schrieb: >> ob crates.io durch sein Verhalten Rechtsbruch begeht hat doch mit der >> Sprache Rust absolut gar nicht zu tun - oder um was geht es dir? > Was willst du jetzt mit der Sprache, oder ist cargo und crates.io > plötzlich doch Teil der Sprache? >> wie handhaben das vpckg, Conan, npm und die vielen anderen Package >> Manager - find das doch mal raus und berichtet hier > Sie werden Pakete, die gegen die Regeln verstoßen, löschen. Aber das > geht ja laut MaWin auf crates.io nicht. wenn dich Rust interessiert dann diskutier das Lösch-Problem direkt mit den crates.io Leuten ansonsten spar es dir doch mit MaWin zum rum zu spielen, was bringt das hier?
Mombert H. schrieb: > Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn > dort veröffentliche Software gegen geltendes Recht verstößt? Nein. Das hat auch niemand geschrieben. Mombert H. schrieb: > Sie werden Pakete, die gegen die Regeln verstoßen, löschen. Aber das > geht ja laut MaWin auf crates.io nicht. Nicht von AUTOR selbst löschbar. Lies bitte meine Beiträge richtig. Selbstverständlich haben die Administratoren von crates.io für den absoluten Sonderfall, dass jemand rechtswidriges Material hochlädt, immer noch den superuser-Zugriff auf die Datenbank.
MaWin O. schrieb: > Mombert H. schrieb: >> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn >> dort veröffentliche Software gegen geltendes Recht verstößt? > Nein. Das hat auch niemand geschrieben. > Mombert H. schrieb: >> Sie werden Pakete, die gegen die Regeln verstoßen, löschen. Aber das >> geht ja laut MaWin auf crates.io nicht. > > Nicht von AUTOR selbst löschbar. Lies bitte meine Beiträge richtig. Und was passiert, wenn der AUTOR sich and die Administatoren von crates.io wendet und sagt, "Ich habe nicht die Rechte an dieser Software. Bitte löscht sie."?
Mombert H. schrieb: > Und was passiert, wenn der AUTOR sich and die Administatoren von > crates.io wendet und sagt, "Ich habe nicht die Rechte an dieser > Software. Bitte löscht sie."? Ich weiß es nicht, aber da wird sicher nach vernünftigem menschlichem Ermessen drauf reagiert. Und damit beende ich jetzt diese absolut dümmliche und nicht zielführende Diskussion.
@MaWin O. mich würde interessieren wie du das Thema ABI siehst (die C-ABI können wir - deswegen würde ich die mal komplett ausblenden) -wie könnte eine "echte" Rust-ABI aussehen/was sind Herausforderungen Kann es eine echte Rust-ABI geben oder wird das genau so ein Problem wie mit C++ und dem nicht C-Rest? -irgendeine Vorstellung wie Dlls/Shared Object (mit nicht gemeinsam genutzten (Shared-CRT) Heaps diese Rust-ABI nutzen könnten) mögliche Herausforderung: Owner-Ship-Transfer ueber Heap-Grenzen? gibt es da irgendwelche Vorstellungen in der Community? das Thema "echte" ABI und shared objects wird ja noch relativ stark auf "wir können ja C konform sein reduziert" oder denkst du das Rust eher als Inside/Inline-Implementierung genutzt werden wird und es einfach nicht so viel Austausch über die oben genannten Grenzen geben wird weil alles direkt verlinkt ist?
ein paar Beispiele was so lange wir nicht von nur ein paar Value-Types reden ein Problem ist - z.B. in C++ Lib1(std::vector<x>*) <-> Lib2(std::vector<TypeX>*) (oder DLLs mit shared Heaps) Probleme: -Release/Debug Layout Unterschied beim vector DLL ohne shared Heaps Dll1(std::vector<x>*) <-> Dll2(std::vector<TypeX>*) Probleme: -Release/Debug Layout unterschied beim vector -vector delete muss an den richtigen Heap gehen und solche Sachen Java und C# usw. haben solchen Probleme nicht weil deren Runtime oder die eingeschränkten Generics solche ABI Probleme gar nicht erzeugen können, es gibt kein echtes Binary-Linking
MaWin O. schrieb: > Es ist vielmehr das Problem des Autors und des Nutzers. Deshalb war > meine Aussage nicht falsch, sondern richtig. Es ist mein Problem, fremden Code unverifiziert auszuführen. Ob der fremde Code überhaupt da hätte sein dürfen, ist ein separates Problem. Jemandem, der auf einer gleichrangigen Kreuzung von rechts kommt, muss ich die Vorfahrt gewähren - auch dann, wenn er rückwärts und falschrum aus einer Einbahnstraße kommt. Dass er das selbst nicht darf, ist nicht mein Problem. Wenn eine Firma ein illegales Paket einbindet und damit Geld verdient, dann wird die Firma angeklagt und nicht derjenige, der das Paket illegalerweise irgendwo hochgeladen hat. Das fällt unter "due diligence". >> Dieses Problem (oder ein Äquivalent) besteht grundsätzlich bei allen auf >> schnelle Releasezyklen ausgelegten Systemen. Cargo und crates.io sind da >> nicht besser oder schlechter > > Cargo ist auf vieles ausgelegt. Aber mit Sicherheit nicht auf die > schnelle Änderungen von Dependency-Versionen. Besser lesen. Ich schrieb "Releasezyklen". Du hast inzwischen mehrfach wiederholt festgestellt, dass Cargo nicht automatisch deine Versionsnummern aktualisiert, das ist angekommen. Aber in der Realität macht man regelmäßig ein Update und fertig ist - und genau diesen Schritt vereinfacht Cargo, wie auch jeder andere Paketmanager. Oft macht man das Update sogar automatisch (für nightlies, wann immer ein Update auftritt, etc.), der Sicherheit(slücken) wegen. Wir leben in einer Welt, in der Abhängigkeiten oft genug im Lockstep aktualisiert werden müssen, damit das Gesamtsystem noch funktioniert. Besonders, wenn alle Abhängigkeiten statisch in das Programm geklebt werden und ohnehin alles neu gebaut werden muss. Oder willst du ernsthaft argumentieren, dass man Code nie aktualisieren müsste und das deswegen kein Problem ist? Wirklich? Mombert H. schrieb: > Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn > dort veröffentliche Software gegen geltendes Recht verstößt? Nein. Aber vor Gericht landet erstmal der Nutzer der Pakete, der dann wiederum crates.io auf Schadensersatz verklagen kann. Ich bin mir sicher, das Regelwerk von crates.io wird den Schaden dann an den Autor weiterreichen.
Beitrag #6940915 wurde von einem Moderator gelöscht.
S. R. schrieb: > Mombert H. schrieb: >> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn >> dort veröffentliche Software gegen geltendes Recht verstößt? > > Nein. Aber vor Gericht landet erstmal der Nutzer der Pakete, der dann > wiederum crates.io auf Schadensersatz verklagen kann. Ich bin mir > sicher, das Regelwerk von crates.io wird den Schaden dann an den Autor > weiterreichen. Du bist dir sicher? Basiert dein sicher auf deinem Bauchgefühl oder kann man das irgendwo nachlesen? Also beide Teile, dass der Nutzer zuerst vor Gericht landet und dass der Nutzer gegenüber der Plattform einen Anspruch auf Schadensersatz hat. Wenn ich mir da z.B. "illegale" Tauschbörsen für Musik und Filme angucke, läuft das anders.
S. R. schrieb: > Aber in der Realität macht man regelmäßig ein Update und fertig ist - > und genau diesen Schritt vereinfacht Cargo, wie auch jeder andere > Paketmanager. Oft macht man das Update sogar automatisch (für nightlies, > wann immer ein Update auftritt, etc.), der Sicherheit(slücken) wegen. du hast vollkommen recht - Rust Cargo erschafft durch die Einfachheit schneller diese Dependency Probleme (auch wenn es kein Autoupgrade gibt) aber was ist die Antwort auf das Problem? einfach niemals Package Systeme einsetzen? Ich finde der grossen Vorteil ist das ich lokal in meiner Firma mein eigenes Repository aufbauen kann (in das ich Prozess-Sicher update) und innerhalb meiner Firma ist dann eine "gewisse" Sicherheit da und ja wir alle arbeiten seit Jahren mit Dependencies und wissen wie das geht (von händischen bis selbst-gestricktem CMAke/Batch/Python Scripten ist alles probiert und im Einsatz) und welche Fallstricke lauern - aber trotzdem finde ich das man das Deployment irgendwie vereinfachen muss - auch wenn der aktuelle Cargo Stand vielleicht noch nicht perfekt ist finde ich das Cargo eine gute Diskussion-Grundlage bietet um diese Punkte für die Zukunft zu verbessern ganz unabhängig von der Sprache Rust
Mombert H. schrieb: > S. R. schrieb: >> Mombert H. schrieb: >>> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn >>> dort veröffentliche Software gegen geltendes Recht verstößt? >> >> Nein. Aber vor Gericht landet erstmal der Nutzer der Pakete, der dann >> wiederum crates.io auf Schadensersatz verklagen kann. Ich bin mir >> sicher, das Regelwerk von crates.io wird den Schaden dann an den Autor >> weiterreichen. > Du bist dir sicher? Basiert dein sicher auf deinem Bauchgefühl oder kann > man das irgendwo nachlesen? Also beide Teile, dass der Nutzer zuerst vor > Gericht landet und dass der Nutzer gegenüber der Plattform einen > Anspruch auf Schadensersatz hat. Wenn ich mir da z.B. "illegale" > Tauschbörsen für Musik und Filme angucke, läuft das anders. die Antwort ist dann einfach - man darf gar nichts machen, oder? also kein Cargo kein crates.io - die User müssen das 100% selbst machen Rechtssicherheit ist ein unklar handhabbares Thema das man nie abschließen sauber lösen kann - das ist auch jedem klar - tausend Probleme - aber als Lösung einfach gar nichts machen? was ist das Ziel deiner Kritik?
Microsoft managed in vcpkg auch tausend fremde Dependencies genau nach dem gleichen Schema wie crates.io und NPM ist mitlerweile auch von Microsoft - also noch viel mehr solcher Dependencies Ignorieren die deine Sorgen einfach nur deshalb weil die 1000 Anwälte drauf werfen können wenn es Probleme gibt? Einfache Frage: Was macht Microsoft anders als crates.io oder sind die einfach genau so unbedarft?
cppbert3 schrieb: > die Antwort ist dann einfach - man darf gar nichts machen, oder? > also kein Cargo kein crates.io - die User müssen das 100% selbst machen Das ist ein ziemlich weiter Bogen, den du von MaWins "man kann Pakete nicht löschen" zu "man darf garnichts machen" spannst. cppbert3 schrieb: > Rechtssicherheit ist ein unklar handhabbares Thema das man nie > abschließen sauber lösen kann - das ist auch jedem klar - tausend > Probleme - aber als Lösung einfach gar nichts machen? Darum ging es mir nie. Es ging immer nur um "man kann nichts löschen" cppbert3 schrieb: > was ist das Ziel deiner Kritik? Welche Kritik meinst du genau? cppbert3 schrieb: > Microsoft managed in vcpkg auch tausend fremde Dependencies > genau nach dem gleichen Schema wie crates.io > [...] > Einfache Frage: Was macht Microsoft anders als crates.io oder sind die > einfach genau so unbedarft? Ich wusste nicht, dass jeder auf vcpkg.io Pakete veröffentlichen kann. Kann man sie dort löschen?
cppbert3 schrieb: > -wie könnte eine "echte" Rust-ABI aussehen/was sind Herausforderungen > Kann es eine echte Rust-ABI geben oder wird das genau so ein Problem wie > mit C++ und dem nicht C-Rest? Ja, das ist ein sehr spannendes und sehr komplexes Thema, von dem ich leider viel zu wenig Ahnung habe, um einen qualifizierten Kommentar absondern zu können. :) Aus meinem Bauchgefühl heraus wird eine Library-ABI deutlich eingeschränkter sein müssen, als die statisch gebauten Crate-Schnittstellen. Ich gehe erst einmal davon aus, dass gar keine Compiletime-Ownershiptransfers stattfinden werden, sondern eher etwas zur Laufzeit wie Arc/RefCell(+threadsafety). Wenn du da eine funktionierende Lösung findest, hast du damit sicher das Jobticket direkt zu Google und Konsorten gewonnen. ;)
MaWin O. schrieb: > Wenn du da eine funktionierende Lösung findest, hast du damit sicher das > Jobticket direkt zu Google und Konsorten gewonnen. ;) funktionierend ist nicht das Problem - generisch und performant genug ist die Herausforderung
Mombert H. schrieb: > cppbert3 schrieb: >> Rechtssicherheit ist ein unklar handhabbares Thema das man nie >> abschließen sauber lösen kann - das ist auch jedem klar - tausend >> Probleme - aber als Lösung einfach gar nichts machen? > Darum ging es mir nie. Es ging immer nur um "man kann nichts löschen" aber was soll MaWin mit dieser Info anfangen - das wäre doch eher was für eine Diskussion mit den crates.io Leuten, oder? MaWin hat mehrfach und deutlich gesagt - es ist noch viel im Fluss - und ja nicht alles was crates.io/Cargo macht ist absolut perfekt - das kann keine Sprache/Environment sein und so hirnlos kann kein Entwickler sein um das zu glauben aber was du machst ist auf Details rumreiten - auch wenn du das so nicht wahrnimmst - und es ist nicht klar zu welchem Zweck du das machst MaWin juckt deine Argumentation null - und die crates.io/Cargo Leute hören sie nur wenn du sie auch dort vorträgst Selbst wenn du bei MaWin ein Umdenken erreichst hat das immer noch nichts mit der Rust Sprache an sich zu tun - und über die will er reden - nicht über die Infrastruktur (obwohl die Klarweise wichtig ist - aber eben hier und jetzt nicht relevant ist) und wenn du deine Crate/crates.io Problematik nicht gewillt bist an der richtigen Stellen vorzutragen ist das genauso nur verschwendete Zeit die crates.io Probleme/Strategien sind vollständig entkoppelt von Rust als Sprache - auch wenn sie sehr nahe zusammenstehen - aber ob crates.io das Prinzip genau so beibehält oder noch x mal ändert ist völlig ungewiss
cppbert3 schrieb: > funktionierend ist nicht das Problem - generisch und performant genug > ist die Herausforderung Ja, das ist mir schon klar. Das wollte ich damit ausdrücken. Aber wenn man die Möglichkeiten der ABI einschränkt, sehe ich jetzt nicht unbedingt, warum das ein Performanceproblem sein sollte. Alle anderen dynamischen Sprachmerkmale ((A)Rc/RefCell/trait-objects/...etc...) sind ja schließlich auch in der Regel kein Performanceproblem. Und wenn doch, dann muss man das Feature halt anders implementieren oder statisch linken. Ich würde das erst einmal als Sonderfälle kategorisieren.
Mombert H. schrieb: > MaWin schrieb: >> Nop schrieb: >>> Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt >> >> Qualität ist die Abwesenheit von Kundenreklamationen. > > Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik. You made my day! =DDDDDD
Beitrag #6942606 wurde von einem Moderator gelöscht.
Beitrag #6942639 wurde von einem Moderator gelöscht.
Beitrag #6942647 wurde von einem Moderator gelöscht.
Beitrag #6942657 wurde von einem Moderator gelöscht.
Beitrag #6942669 wurde von einem Moderator gelöscht.
Es gibt eine neue Version: https://blog.rust-lang.org/2022/01/13/Rust-1.58.0.html > Captured identifiers in format strings Sehr nett. Ein Schritt weiter in Richtung Python-style-f-strings. > More #[must_use] in the standard library Sinnvoll. Kann C++ das eigentlich auch? (ohne Compiler-Extension).
MaWin schrieb: >> More #[must_use] in the standard library > > Sinnvoll. Kann C++ das eigentlich auch? (ohne Compiler-Extension). Ja, mit dem Attribut
1 | [[nodiscard]] |
Siehe https://en.cppreference.com/w/cpp/language/attributes/nodiscard
:
Bearbeitet durch User
Mombert H. schrieb: >> Nein. Aber vor Gericht landet erstmal der Nutzer der Pakete, der dann >> wiederum crates.io auf Schadensersatz verklagen kann. Ich bin mir >> sicher, das Regelwerk von crates.io wird den Schaden dann an den Autor >> weiterreichen. > Du bist dir sicher? Basiert dein sicher auf deinem Bauchgefühl oder > kann man das irgendwo nachlesen? Also beide Teile, dass der Nutzer > zuerst vor Gericht landet und dass der Nutzer gegenüber der Plattform > einen Anspruch auf Schadensersatz hat. Für ungeeignete Nutzung von Software hat mein Arbeitgeber durchaus schon einige Klagen abbekommen (ob gerechtfertigt oder nicht weiß ich nicht). Ist halt ein einfaches Ziel. Wo die Software ursprünglich herkam, interessierte den Kläger (und die Rechtskosten) dafür erstmal nicht. Was den Schadenersatz angeht, so schrieb ich was von "verklagen kann", nicht von "Anspruch auf Schadensersatz". Vor Gericht und auf hoher See, und so. > Wenn ich mir da z.B. "illegale" > Tauschbörsen für Musik und Filme angucke, läuft das anders. In Deutschland gab es vor einigen Jahren ja große Abmahnwellen von diversen Anwaltsagenturen, und die gingen auch großflächig gegen die Nutzer und nicht gegen die Tauschplattformen. Zumal letztere ein großes Interesse daran haben, nicht rechtlich auffindbar zu sein... cppbert3 schrieb: > du hast vollkommen recht - Rust Cargo erschafft durch die Einfachheit > schneller diese Dependency Probleme (auch wenn es kein Autoupgrade gibt) > aber was ist die Antwort auf das Problem? einfach niemals Package > Systeme einsetzen? Abhängigkeiten reduzieren, soweit möglich und sinnvoll. Also nicht "viel hilft viel", wie das diese ganzen Paketmanager begünstigen (und vermutlich auch wollen, denn daraus folgt deren Existenzberechtigung). Wenn jede Abhängigkeit erstmal Aufwand ist, dann überlegt man vorher, was man tut. Nachdenken kostet Zeit, und wenn die Zeit durch die Prozesse hinreichend stark verkürzt wird, dann findet kein Nachdenken mehr statt. Das empfinde ich als ein Problem. Andere wahrscheinlich nicht, denn "der Genosse wird sich schon was dabei gedacht haben". > auch wenn der aktuelle Cargo Stand vielleicht noch nicht perfekt ist > finde ich das Cargo eine gute Diskussion-Grundlage bietet um diese > Punkte für die Zukunft zu verbessern Mit Cargo selbst habe ich keine Probleme, nur mit dessen Grundidee (die ebenso auch für alle anderen Paketmanager zutrifft; dass npm gelegentlich explodiert, dürfte in erster Linie an dessen extremer Verbreitung liegen). Mein Problem mit Rust heißt aber Cargo, weil das eben keine getrennten oder auch nur sinnvoll trennbaren Technologien sind. Genausowenig, wie systemd von dem, was dessen Autoren "systemd umbrella" nennen oder wie einen C-Präprozessor von einem C-Compiler. cppbert3 schrieb: > Ignorieren die deine Sorgen einfach nur deshalb weil die 1000 Anwälte > drauf werfen können wenn es Probleme gibt? Ich kann mir gut vorstellen, dass Microsoft solche Probleme allein deshalb ignorieren kann, weil sie einerseits genug Anwälte für eine kompetente Verteidigung haben und andererseits genug Anwälte und Technologien haben, um jeden, der sie plattmachen will, selbst plattzumachen. Das ist übrigens auch der Grund, warum Microsoft vor einigen Jahrzehnten anfing, alles was geht zu patentieren (vorher lehnten sie Patente ab und ließen auch eher nichts patentieren): Um damit Angreifer plattmachen zu können. > Einfache Frage: Was macht Microsoft anders als crates.io oder sind die > einfach genau so unbedarft? Der Unterschied zwischen crates.io, Github, npm oder irgendwas anderem ist... in der Hinsicht nicht vorhanden. Die sind allesamt nicht Primärziele, was die illegale Nutzung (im Hinblick auf die Lizenzbedingungen) angeht. Sie verbreiten allerdings die Software weiter, was ebenfalls ein Teil der Lizenzbedingungen ist - und das prüfen sie durchaus (oder sollten es im Eigeninteresse). Github tut das beispielsweise.
:
Bearbeitet durch User
S. R. schrieb: > einige Klagen abbekommen > Anspruch auf Schadensersatz > Abmahnwellen > Tauschplattformen > npm > C-Präprozessor > Microsoft > illegale Nutzung > Lizenzbedingungen Es geht hier im Thread um die Programmiersprache Rust.
MaWin schrieb: > Es geht hier im Thread um die Programmiersprache Rust. Ich habe auf mir gestellte Fragen geantwortet.
Eine neue Rust-Version ist raus: https://blog.rust-lang.org/2022/02/24/Rust-1.59.0.html Das neue Hauptfeature wird wohl für die meisten die Stabilisierung von inline-assembly sein. Aber auch available_parallelism ist ganz nett und man ist nicht mehr auf die Verwendung von externen Crates an dieser Stelle unbedingt angewiesen.
ich fand die Inline Assembler Syntax am Anfang doch ein wenig gewöhnungsbedürftig (im Vergleich zu VC Inline asm unter x86 (unter x64 geht das ja auch schon nicht mehr)) oder würde man damit auch z.B. solche mehrseitigen SIMD Sin/Cos Implementierungen wie z.B. in der glibc inline machen?
cppbert schrieb: > ich fand die Inline Assembler Syntax am Anfang doch ein wenig > gewöhnungsbedürftig (im Vergleich zu VC Inline asm unter x86 (unter x64 > geht das ja auch schon nicht mehr)) Ich habe mir die Rust-Asm noch nicht genauer angeschaut. Deshalb bin ich interessiert daran, welche Kritikpunkte du hast. Auf den ersten Blick sieht Rust-Asm ja sehr an Gnu-GCC-Asm angelehnt aus. Und die finde ich eigentlich ganz gut. Wenn man einmal die Constraints auswendig gelernt und verstanden hat. > oder würde man damit auch z.B. solche mehrseitigen SIMD Sin/Cos > Implementierungen wie z.B. in der glibc inline machen? Klar. Denke schon. Wozu auch sonst? Für Einzeiler gibt es oft Intrinsics.
Rustc-GCC kann sich nun selbst kompilieren: https://lwn.net/Articles/889989/ > so this work will eventually allow programs to be built for a number of architectures that are not supported by rustc
Carsten P. schrieb: > HabMut schrieb: >> C Programme beinhalten häufig vermeidbare Sicherheitslücken die die >> Sicherheit von IT Systemen gefährden. > > Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber > "sicher" keine sicherheitsrelevanten großen Systeme. Ich kenne genau > einen sehr versierten "plain C"-Entwickler, dem ich meine Bedürfnisse > nach einer Software anvertrauen würde, und der verwendet eine selbst > entwickelte GC, da ist nix mit malloc(). strcpy() und free(). Läuft seit > der ersten Version sogar auf S7-Steuerungen. GC in Purem C? Wozu C native auf S7? Zeig mal wie das geht bzw. wo das steht, daß es geht. Wäre mir neu. > > Traue keiner Runtime ohne verwaltetem Speicher! Und traue gar keinem > System ohne eine Runtime/einem Framework! Das gilt für Linux wie für > Windows wie für Android wie für iOS. Und wo ist der Sinn? Das ist alles Software und kann tierische Fehler enthalten. Also sollte man einem Betriebssystem schon mal nicht vertrauen, aber der Javaapplikation die darauf läuft schon?
Rust 1.60.0 ist raus: https://blog.rust-lang.org/2022/04/07/Rust-1.60.0.html Punkte, die ich interessant finde: - Source-based Code Coverage - (A)Rc::new_cyclic: Verbessert die Handhabung von zyklischen/selbstreferenzierenden Datenstrukturen. - Vec::spare_capacity_mut: Kann ein Effizienzgewinn sein, wenn doppelte Initialisierungen vermieden werden können. Benötigt aber wahrscheinlich in den meisten (allen?) Fällen auch eine Zeile unsafe-Rust.
MaWin schrieb: > - Source-based Code Coverage ich finde es sehr gut das solche Dinge sehr stark integriert werden (schön wäre jetzt noch ein sehr Kompiler/Toolchain naher Parser und Refactoring-Service/Lib/whatever den externe Tools nutzen können) Contra: -es fehlen sicherlich dann ein paar Features die in gcov/und anderen Tools vorhanden sind - aber wachsen kann es ja jederzeit Pro: -egal wie gut oder schlecht - es gibt einen Standard den alle rustc/cargo Nutzer gemeinsam haben -wer mit C/C++, Platform- und Compilerübergreifend viel mit Coverage zu tun hat wir sich freuen das es vielleicht möglich ist auf eine gut und immer funktionierende Lösung zu kommen
cppbert schrieb: > (schön wäre jetzt noch ein sehr Kompiler/Toolchain naher Parser und > Refactoring-Service/Lib/whatever den externe Tools nutzen können) > > Contra: > -es fehlen sicherlich dann ein paar Features die in gcov/und anderen > Tools vorhanden sind - aber wachsen kann es ja jederzeit Ich kann dir leider nicht ganz folgen. Rust coverage basiert auf den Standard-LLVM-Coveragetools. https://llvm.org/docs/CommandGuide/llvm-profdata.html https://llvm.org/docs/CommandGuide/llvm-cov.html
Dann ist eher die frage wie der gcc-rustc dann coverage implementieren wird und wie schnell sich die beiden compiler angleichen damit man beide gleich nutzen kann In der c/cpp Welt speziell unter Windows gibt es x Lösungen die inkompatibel sind und jede Lösung hat irgendeine andere schwäche die dann projektbezogen auftreten, eine einheitliche Lösung egal auf welchem backend basierend ist da ein grosser Gewinn
cppbert3 schrieb: > Dann ist eher die frage wie der gcc-rustc dann coverage implementieren > wird und wie schnell sich die beiden compiler angleichen damit man beide > gleich nutzen kann Ja. Aber die Frage ist dann eher: Was sind die Unterschiede zwischen LLVM und GCC, was Coverage angeht? Mit Rust hat das dann erst einmal wenig zu tun.
Carsten P. schrieb: > Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber > "sicher" keine sicherheitsrelevanten großen Systeme. Und wenn das Betriebssystem selber in C geschrieben ist? Und der Compiler, den du dazu nutzt, auch? Das soll es ja gerüchteweise geben ;) Oliver
Oliver S. schrieb: > Carsten P. schrieb: >> Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber >> "sicher" keine sicherheitsrelevanten großen Systeme. > > Und wenn das Betriebssystem selber in C geschrieben ist? Und der > Compiler, den du dazu nutzt, auch? Ja, es wird gerne vergessen, dass praktisch so gut wie jedes Programm, das auf einem Rechner läuft, auf einen Unterbau in C aufsetzt.
MaWin schrieb: > cppbert3 schrieb: >> Dann ist eher die frage wie der gcc-rustc dann coverage implementieren >> wird und wie schnell sich die beiden compiler angleichen damit man beide >> gleich nutzen kann > > Ja. Aber die Frage ist dann eher: Was sind die Unterschiede zwischen > LLVM und GCC, was Coverage angeht? Mit Rust hat das dann erst einmal > wenig zu tun. er geht mir nur darum das ich finde das Rust als Komplettpaket es schafft alle Entwickler Feature-Technisch an einen Tisch zu bringen - nicht das einfach technisch geht sondern auch dieser Vereinheitlichungscharakter
Rolf M. schrieb: > Oliver S. schrieb: >> Carsten P. schrieb: >>> Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber >>> "sicher" keine sicherheitsrelevanten großen Systeme. >> >> Und wenn das Betriebssystem selber in C geschrieben ist? Und der >> Compiler, den du dazu nutzt, auch? > > Ja, es wird gerne vergessen, dass praktisch so gut wie jedes Programm, > das auf einem Rechner läuft, auf einen Unterbau in C aufsetzt. Auch wenn die Replik inhaltlich richtig ist: ich sehe das ähnlich wie Carsten P. Ich verdiene zwar mein Geld mit (systemnaher) C-Programmierung, aber Userspace-Programme würde ich ohne Not heute nicht mehr in C schreiben wollen. Man will ja irgendwann auch fertig werden.
Rolf M. schrieb: > Oliver S. schrieb: >> Carsten P. schrieb: >>> Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber >>> "sicher" keine sicherheitsrelevanten großen Systeme. >> >> Und wenn das Betriebssystem selber in C geschrieben ist? Und der >> Compiler, den du dazu nutzt, auch? > > Ja, es wird gerne vergessen, dass praktisch so gut wie jedes Programm, > das auf einem Rechner läuft, auf einen Unterbau in C aufsetzt. das vergisst doch niemand hier in dieser Diskussion und das selbe haben vorher die Assembler-Programmierer gesagt als C eingeführt wurde, und davor noch die, welche Kabeln programmiert haben... Der Spruch kommt von den Java hatern, weil die VM ja auch auf C/C++ basiert - aber das trifft hier nur unzureichend weil Rust als Systemsprache mit C/C++ auf einer Ebenen steht es ändert nur nichts an den Pro-Argumenten für Rust - und es juckt niemanden ob die Pro-Argumente nicht für alle so gelten, sonst dürfte man ja gar nichts schreiben
cppbert schrieb: > Der Spruch kommt von den Java hatern, weil die VM ja auch auf C/C++ > basiert - aber das trifft hier nur unzureichend weil Rust als > Systemsprache mit C/C++ auf einer Ebenen steht Es ging darum, dass diese Aussage nicht stimmt: Carsten P. schrieb: > Kleine Tools kann man gerne auf jedem OS in C schreiben, aber > "sicher" keine sicherheitsrelevanten großen Systeme. Denn in der realen Welt setzt aktuell so gut wie jedes sicherheitsrelevante große System auf einen Kern in C auf.
Moin, Rolf M. schrieb: > Denn in der realen Welt setzt aktuell so gut wie jedes > sicherheitsrelevante große System auf einen Kern in C auf. Jepp. Und dann passieren halt auch noch z.b. so Schoten, dass es fuer polkit (BLFS-Book: "Polkit is a toolkit for defining and handling authorizations. It is used for allowing unprivileged processes to communicate with privileged processes.") eine javascript-engine braucht (also aktuell ein Teil der firefox-sourcen), die dann ihrerseits wieder ein rustc zum Bauen braucht... Und der ganze Kack mit ich-weiss-nicht-wieviel-LOC soll dann sicher sein? Gruss WK
Dergute W. schrieb: > polkit ´ > Und der ganze Kack mit ich-weiss-nicht-wieviel-LOC soll dann sicher > sein? Nein. Niemand mit Verstand behauptet, dass polkit gut und/oder sicher ist. Mit Rust - dem Thema des Threads - hat das allerdings nichts zu tun.
Wer etwas mehr über negative Aspekte von Rust und Cargo lernen möchte, ohne gleich in (falsche) Vermutungen und FUD abzudriften, dem kann ich diese Lektüre empfehlen: https://www.bunniestudios.com/blog/?p=6375
Release: Rust 1.61.0 https://blog.rust-lang.org/2022/05/19/Rust-1.61.0.html Es scheinen viele Detailänderungen eingegangen zu sein. Man kann jetzt recht komfortabel mit Termination einen Returncode von Main zurückgeben.
Achja. Und außerdem funktioniert endlich das AVR8-Target wieder mit der neusten nightly-Version.
Rust-Frontend kommt offiziell in die GCC https://www.golem.de/news/programmiersprache-rust-frontend-kommt-offiziell-in-die-gcc-2207-166831.html
Kaj schrieb: > Rust-Frontend kommt offiziell in die GCC Das ist ein ganz wichtiger Schritt. Ohne diesen Schritt ist die breite Verwendung besonders auf Nicht-PC-Plattformen nicht denkbar.
MaWin schrieb: > Kaj schrieb: >> Rust-Frontend kommt offiziell in die GCC > > Das ist ein ganz wichtiger Schritt. Ohne diesen Schritt ist die breite > Verwendung besonders auf Nicht-PC-Plattformen nicht denkbar. Aber da Rust ohne Cargo niemand verwendet, bringt das allein auch nicht viel. IMO ist Rust schon tot. Genau so wie Go. Kotlin lebt nur noch wegen Android Apps. Im prof. Embedded Umfeld kommen solche Hypes ohnehin nicht vor. Das ist was für Medieninformatiker mit Nebenfach Sportgymnastik.
:
Bearbeitet durch User
Cyblord -. schrieb: > IMO ist Rust schon tot. zum Glück haben sich ein paar Linux-Kernel Entwickler bereit erklärt die archivarische Aufgabe zu übernehmen - damit man später seinen Kindern noch was davon zeigen kann :)
Cyblord -. schrieb: > Aber da Rust ohne Cargo niemand verwendet, bringt das allein auch nicht > viel. Wo genau soll das Problem sein? Man wird Cargo (und alle anderen Tools und Programme) natürlich mit gccrs übersetzen können.
Es gibt ja immer noch keinen authoritativen standard, und stattdessen wird das clang verhalten dafür missbraucht. Machen gcc und clang was anders, macht es also per definition gcc falsch. Gcc ist deshalb dazu verdammt, per definition immer die verbuggte hinterherhinkende Version zu bleiben. Eine echte Alternative / Konkurrenz, kann es so nicht werden. Solange es keinen authoritativen standard gibt, ist das gcc ein rust frontend hat, also nur auf dem Papier was wert, in der Praxis aber irrelevant.
DPA schrieb: > Solange es keinen authoritativen standard gibt, ist das gcc ein > rust frontend hat, also nur auf dem Papier was wert, in der Praxis aber > irrelevant. Genau so, wie alle Python-Implementierungen irrelevant sind, weil es keinen "authorativen Standard" gibt?
MaWin schrieb: > alle Python-Implementierungen Mal von Micro-Python abgesehen, gibt es denn da überhaupt mehr als eine Implementierung?
Jörg W. schrieb: > Mal von Micro-Python abgesehen, gibt es denn da überhaupt mehr als eine > Implementierung? Dann google doch mal. Es gibt dutzende große Pythonimplementierungen.
MaWin schrieb: > DPA schrieb: >> Solange es keinen authoritativen standard gibt, ist das gcc ein >> rust frontend hat, also nur auf dem Papier was wert, in der Praxis aber >> irrelevant. > Genau so, wie alle Python-Implementierungen irrelevant sind, weil es > keinen "authorativen Standard" gibt? Ich weiß nicht wie das anderswo ist. In meinem Arbeitsumfeld ist nur CPython relevant. Ich kenne niemanden, der etwas anderes in seinen Produkten einsetzt. In den letzten Jahren wurden in mehreren Projekten sogar explizit mehrere andere Implementationen vom Kunden verboten.
MaWin schrieb: > Jörg W. schrieb: >> Mal von Micro-Python abgesehen, gibt es denn da überhaupt mehr als eine >> Implementierung? > > Dann google doch mal. > Es gibt dutzende große Pythonimplementierungen. "Other Implementations … Note that most of these projects have not yet achieved language compliance" Allerdings hat Python zumindest eine Language Reference: https://docs.python.org/3/reference/index.html einschließlich einer kompletten Grammatikdokumentation: https://docs.python.org/3/reference/grammar.html
Es gibt auch noch: https://peps.python.org/pep-0000/ Änderungen werden also nicht einfach nur in der Implementierung umgesetzt, sondern erstmal vorgeschlagen & diskutiert.
Daniel A. schrieb: > Änderungen werden also nicht einfach nur in der Implementierung > umgesetzt, sondern erstmal vorgeschlagen & diskutiert. Das ist bei Rust identisch. Bitte zurück zum Thema. Hier geht es um Rust. Jörg W. schrieb: > Note that most of these projects have not yet achieved language > compliance" Dummes Blah.
MaWin schrieb: >> Note that most of these projects have not yet achieved language >> compliance" > > Dummes Blah. Ah ja. Stammt halt nur aus dem Python-Wiki.
Jörg W. schrieb: > Stammt halt nur aus dem Python-Wiki. Aus dem C-Python-Wiki. Wieso sollte das eine verlässliche Quelle über den Zustand von anderen Implementierungen sein? Gib deine Rechthaberei bitte auf. Es gibt sehr viele komplette und stabile Python-Implementierungen. Ich zähle sie hier bewusst nicht auf, weil das Thema des Threads nicht Python ist und das jeder in Google finden kann.
MaWin schrieb: > Wieso sollte das eine verlässliche Quelle über den Zustand von anderen > Implementierungen sein? Weil auch von C-Python letztlich die Sprachdefinition stammt. Wenn ich jetzt einen Rust-Compiler schreibe und sage, er sei Rust compliant, würdest du das als verlässliche Quelle akzeptieren, nur weil ich das so sage?
Jörg W. schrieb: > Wenn ich jetzt einen Rust-Compiler schreibe und sage, er sei Rust > compliant, würdest du das als verlässliche Quelle akzeptieren, nur weil > ich das so sage? Ach komm. Das ist doch dummes Geschwätz. Du hast weder Ahnung von Python, noch von Rust. Das ist offensichtlich.
Du musst es ja wissen. Und nur, weil du dich jetzt aufregst, dass über Python diskutiert wird: das war dein Einwand.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > das war dein Einwand. Nein. Ich habe nur einen Vergleich gebracht. Dass ihr Knalltüten jetzt gleich Python in Frage stellt, hätte ich mir allerdings denken können. Dinge in Frage stellen, von denen man Null Ahnung hat, ist ja euer Hobby.
Du disqualifizierst dich soeben für jegliche ernsthafte Diskussionen. Rust tust du mit deinem Auftreten gewiss keinen Gefallen.
Jörg W. schrieb: > Rust tust du mit deinem Auftreten gewiss keinen Gefallen. Wie wäre es denn, wenn du mal wieder zum Thema zurückkommen würdest? Ich kann nicht sehen, wie ich Rust schade, wenn ich Unwahrheiten über Python richtigstelle.
MaWin schrieb: > Bitte zurück zum Thema. > Hier geht es um Rust. MaWin schrieb: > Genau so, wie alle Python-Implementierungen irrelevant sind, weil es > keinen "authorativen Standard" gibt? Hauptsache nicht an die eigenen Regeln halten ;-) MaWin schrieb: > Es gibt sehr viele komplette und > stabile Python-Implementierungen. Ich zähle sie hier bewusst nicht auf, > weil das Thema des Threads nicht Python ist und das jeder in Google > finden kann. Schön, dass es sie gibt, und dass du glaubst, dass sie komplett und stabil sind. Aber wer nutzt sie?
Jörg W. schrieb: > Mal von Micro-Python abgesehen, gibt es denn da überhaupt mehr als eine > Implementierung? Einfach mal Google benutzen und ein paar Minuten lesen, wenn man von einem Thema schon keine Ahnung hat, ist zu viel verlangt? Ja, es gibt einige. Auch Du kannst das herausfinden, wenn Du willst, trotz Deinem "Moderator"-Emblem. Jörg W. schrieb: > Ah ja. > > Stammt halt nur aus dem Python-Wiki. Wenn Du Dir schon fremde Aussagen zu eigen machst, wäre ein Zitat und ein Link auf die Quelle angebracht, findest Du nicht auch? Darüber hinaus, als ob irgendwelche halb-verwaisten Wikis eine besondere Relevanz hätten. Einfach auf den jeweiligen Projektseiten nachlesen, welchen Stand das jeweilige Projekt hat, übersteigt Dein Interesse? Jörg W. schrieb: > Rust tust du mit deinem Auftreten gewiss keinen Gefallen. Was hat das Verhalten eines Forumsbenutzer mit der Reputation von Rust zu tun? So viel wie Dein Verahlten hier mit der Reputation dieses Forums?
Experte schrieb: >> Stammt halt nur aus dem Python-Wiki. > > Wenn Du Dir schon fremde Aussagen zu eigen machst, wäre ein Zitat und > ein Link auf die Quelle angebracht, findest Du nicht auch? Weißt du, wofür die Anführungszeichen gut sind? Bestimmt nicht, um mir etwas "zu eigen" zu machen. Den Link kann man doch ganz einfach herausfinden, indem man das Zitat bei Google einkippt. Das ist die Methode, die ihr mir nahe gelegt habt. https://wiki.python.org/moin/PythonImplementations > Darüber hinaus, als ob irgendwelche halb-verwaisten Wikis eine besondere > Relevanz hätten. Was bringt dir das, auf so einem Niveau zu diskutieren? Habe ich (oder jemand anders hier) irgendwo die Projektseiten von Rust als "halb-verwaist" diffamiert? Leute, auf dem Niveau bedarf es wohl keiner weiteren Diskussionen.
Jörg W. schrieb: > Was bringt dir das, auf so einem Niveau zu diskutieren? Jörg, ich respektiere dich sehr als Experten auf dem Gebiet C und AVR-C. Aber von Rust und Python hast du offensichtlich leider keinerlei Ahnung. Das zeigst du hier leider sehr eindrucksvoll. Wenn hier über > Niveau geredet wird, dann solltest du es auch selbst einhalten. Effektiv zu behaupten von Python gäbe es nur eine einzige breit genutzte vollständige Implementierung, ist einfach nur lächerlich. Deine Aussagen hier beweisen nur, dass du noch nie mit Python und Rust gearbeitet hast, was über ein Hello World oder ein schnell dahingehacktes Script hinausgeht.
MaWin schrieb: > Effektiv zu behaupten von Python gäbe es nur eine einzige breit genutzte > vollständige Implementierung, ist einfach nur lächerlich. Ich habe getan, was du empfohlen hast, und danach gegoogelt. Da bin ich beim Python-Wiki rausgekommen, welches dann jemand hier als "halb-verwaist" diffamiert. Was soll das? > Deine Aussagen > hier beweisen nur, dass du noch nie mit Python und Rust gearbeitet hast, > was über ein Hello World oder ein schnell dahingehacktes Script > hinausgeht. Du irrst, gewaltig, was Python angeht. Über Rust habe ich nichts geschrieben.
MaWin schrieb: > Effektiv zu behaupten von Python gäbe es nur eine einzige breit > genutzte vollständige Implementierung, ist einfach nur lächerlich. Wir können uns darauf einigen, dass es eine (oder vielleicht zwei) Standardimplementation gibt sowie viele weitere, die nur in ihren Ecken des Internets verbreitet sind. > Deine Aussagen hier beweisen nur, dass du noch nie mit Python > und Rust gearbeitet hast, was über ein Hello World oder ein schnell > dahingehacktes Script hinausgeht. Deine Aussagen beweisen auch nicht viel mehr. Nur, dass du mehr Zeit für Diskussionen übrig hast. Merkt man z.B. an sowas: MaWin schrieb: > Dass ihr Knalltüten jetzt gleich Python in Frage stellt, hätte ich mir > allerdings denken können. Riecht nach unpassendem Diskussionsstil.
S. R. schrieb: > Wir können uns darauf einigen Nein. Weil es Quatsch ist. > Riecht nach unpassendem Diskussionsstil. Ich möchte überhaupt nicht über Python diskutieren, sondern hatte es nur als Vergleich angebracht. Und damit beende ich mein Mitwirken an der Python-Diskussion hier. Hier geht es um Rust.
MaWin schrieb: > Hier geht es um Rust. Nun gut, dann können wir ja auch wieder zum Anfang der Diskussion - diesmal ohne Python-Vergleich - zurückkehren: DPA schrieb: > Es gibt ja immer noch keinen authoritativen standard, und > stattdessen wird das clang verhalten dafür missbraucht. > Machen gcc und clang was anders, macht es also per definition > gcc falsch. Gcc ist deshalb dazu verdammt, per definition > immer die verbuggte hinterherhinkende Version zu bleiben. > Eine echte Alternative / Konkurrenz, kann es so nicht > werden. Solange es keinen authoritativen standard gibt, > ist das gcc ein rust frontend hat, also nur auf dem Papier > was wert, in der Praxis aber irrelevant. Also?
S. R. schrieb: > Also? Es ist halt völliger Unsinn. Keinerlei Begründung und ich soll jetzt die Gegenbegründung finden? Na gut. > stattdessen wird das clang verhalten dafür missbraucht. Kannst du es vielleicht mal ausführen, was "das clang-Verhalten" überhaupt sein soll? Was hat clang überhaupt mit Rust zu tun? Meinst du LLVM? Welche Teile von Rust sind nur so, weil LLVM das vorgibt? Und warum ist das ein Missbrauch? S. R. schrieb: > macht es also per definition gcc falsch Richtig. Wo ist das Problem? > immer die verbuggte [...] zu bleiben. Warum? Können GCC-Entwickler keine Bugs fixen? > Solange es keinen authoritativen standard gibt, > ist das gcc ein rust frontend hat, also nur auf dem Papier > was wert, in der Praxis aber irrelevant. Wie kommst du zu der Schlussfolgerung?
MaWin schrieb: > Wie kommst du zu der Schlussfolgerung? Hab ich doch schon asführlich aufgeführt. Das llvm rustc Ding ist authoritativ. Szenario: gcc und rustc machen was anders. Resultat: Per definition muss rustc der compiler sein, der es richtig macht, und gcc der Compiler, der den Bug hat. Die Programme werden natürlich auch das rustc verhalten voraussetzen. Ausserdem, jede Änderung und Erweiterung heist, dass beide Compiler was anders machen, also gcc was falsch macht. Wie man es auch dreht und wendet, gcc kann so nicht relevant werden, und kann niemals besser als clang sein, per definition. Wenn es nicht relevant werden kann, ist es in der Praxis irrelevant. Das folgt alles logisch daraus, dass das llvm rustc Ding authoritativ ist, und eben nicht ein Standard. Es ist im vornherein als perfekt festgelegt, und perfekter als perfekt kann man halt nicht werden. Ich hoffe, diesmal konntest du mir folgen. Ich habe die ganze logik Kette a also b also c, nochmal angegeben. Aber ich kann dich natürlich nicht zwingen, den Gedankengang nachzuvollziehen.
DPA schrieb: > Resultat: Per definition muss rustc der compiler sein, der es richtig > macht, und gcc der Compiler, der den Bug hat. Richtig. Wo ist das Problem? > Die Programme werden natürlich auch das rustc verhalten voraussetzen. Richtig. Wo ist das Problem? > Ausserdem, jede Änderung und Erweiterung heist, dass beide Compiler was > anders machen, also gcc was falsch macht. Richtig. Ansonsten implementiert GCC nicht Rust, sondern etwas anderes. Das können sie gerne machen, aber dann ist es nicht Rust. Gccrs wollen Rust implementieren. Wo ist das Problem? > gcc kann so nicht relevant werden Warum? Ich verstehe nicht, wie du das schlussfolgern kannst. Wenn gccrs 99% von rustc's Verhalten implementiert, dann sind sie relevant. Wieso sollten sie es nicht sein? > kann niemals besser als clang sein, per definition. (Was hat clang hier wieder zu suchen?) GCC kann nur besser sein, wenn sie etwas implementieren, was nicht Rust ist? Das ist gar nicht das Ziel von gccrs. Sie wollen Rust implementieren. > Das folgt alles logisch daraus, dass das llvm rustc Ding authoritativ > ist, Richtig. Wo ist das Problem? > Es ist im vornherein als perfekt festgelegt Nein, das ist nicht richtig. Rust enthält sehr viele nicht implementierte Dinge und auch viele undefinierte Dinge (unstable). Und das ist im Entwicklungsprozess ziemlich gut eingebettet. Bei diesen Dingen hat dann weder rustc noch gccrs "recht". Aber wenn gccrs Rust implementieren will, dann werden sie sich mit den rustc Entwicklern abstimmen müssen. Wo ist das Problem? > Ich hoffe, diesmal konntest du mir folgen. Leider nicht. Ich sehe nicht, wo hier der Nachteil bei gccrs sein soll und warum es deshalb zum Scheitern verurteilt sein soll. Nach deiner Logik dürfte es immer nur einen Standard und/oder eine Sprachimplementierung geben. Das ist doch Unsinn. In der Praxis sind die wenigsten Sprachen offiziell standardisiert. Trotzdem sind sie erfolgreich und es gibt oft mehrere Implementierungen. Ich glaube ihr habt eher Angst vor Umbrüchen und Neuem. Rust ist hier. Und es wird nicht wieder gehen, nur weil ihr die Augen verschließt. Gccrs ist ein weiterer wichtiger Schritt dieses zu manifestieren.
MaWin schrieb: > Ich glaube ihr habt eher Angst vor Umbrüchen und Neuem. Nein. Die Kritik ist nicht daran, dass es die Sprache gibt und dass Leute sie verwenden (ich kenne auch ganz persönlich jemanden, der davon begeistert ist). (Ja, es gibt hier auch Leute, die der Meinung sind, die würde nichts taugen. Ich gehöre nicht dazu, und auch die Kritik von DPA behauptet nicht sowas.) Die Kritik ist, dass sie es bis heute nicht geschafft haben, eine formale Definition aufzuschreiben. Es gibt eine "Reference", aber die schreibt gleich als erstes, dass sie "incomplete" ist, und eine formale Definition will sie gar nicht sein. So ist das alles irgendwie mit Beispielen beschrieben statt mit einer formalen Syntax. Auch steht da sowas drin: "Finally, this book is not normative. It may include details that are specific to rustc itself, and should not be taken as a specification for the Rust language. We intend to produce such a book someday, and until then, the reference is the closest thing we have to one." Das ist, was DPA meinte: rustc ist damit de facto das Normativ. Sicher war das auch mit C eine Weile so, dass es nur einen implementierten Compiler gab. Der war aber auch vor 50 Jahren (kannst du bei Dennis Ritchie nachschlagen) bereits begleitet von einer formalen Sprachbeschreibung. Es konnte also jemand anders nur auf Basis der Beschreibung einen eigenen Compiler (oder anderweitigen Parser) schreiben. Aus alldem konnte man schließlich (ja, hat auch eine Weile gedauert) einen wohldefinierten Standard ableiten. Nochmal: ich gehe durchaus davon aus (auf der Basis dessen, was ich von anderen gehört habe), dass die Sprache Potenzial hat. Aber wenn man eine Sprache implementiert, die eine gewisse Bedeutung bekommen soll, dann muss man sich auch dem formalen Kram widmen und nicht nur neue Features hacken. Python ist da (wie ich oben mal schrieb) weiter. OK, ist auch älter, ist akzeptiert.
Jörg W. schrieb: > Die Kritik ist, dass sie es bis heute nicht geschafft haben, eine > formale Definition aufzuschreiben. Ja gut. Das ist richtig. Damit reiht Rust sich in 99% aller Sprachen ein. Scheint wohl kein allzu großes Problem zu sein. Für welche Sprachen gibt es überhaupt eine offizielle Standardisierung? Python, Matlab. Alles Sprachen kurz vor dem Bankrott. Niemand verwendet sie. Denn sie haben ja keine offizielle Standardisierung. Unsinn. > Sicher war das auch mit C eine Weile so Ach? Das ist ja ein Ding. Und trotzdem ist C so erfolgreich? Wie kommt denn das? Ist ja völlig unmöglich. > Der war aber auch vor 50 Jahren Das ist ja ein Ding. Und jetzt rechne mal nach, wie alt moderne Sprachen wie Rust sind. Und dann rechne einmal nach, wann C seinen ersten Standard bekam. > dann muss man sich auch dem formalen Kram widmen Gut. Dann ist ja alles in Butter. Die Rust-Entwicklung ist einem starken formellen Prozess unterlegen. > und nicht nur neue Features hacken. Passiert nur in deine Fantasie. > Python ist da (wie ich oben mal schrieb) weiter. Unsinn. Befasse dich einmal bitte mit der Rust-Entwicklung, bevor du sie bewertest. Danke.
MaWin schrieb: > Für welche Sprachen gibt es überhaupt eine offizielle Standardisierung? Recht viele, auch wenn die nicht überall öffentlich von einem Standardisierungsgremium abgesegnet worden ist. > Python, Matlab. Alles Sprachen kurz vor dem Bankrott. Niemand verwendet > sie. Denn sie haben ja keine offizielle Standardisierung. Nun, das Debakel um Python 2 und Python 3 tat ihrer Beliebtheit nun ganz sicher nicht helfen (und wir hadern damit noch immer). Eine sehr bekannte Sprache, der ihre fehlende Standardisierung - und damit die normative Macht der Implementation - zum Verhängnis geworden ist, wäre Perl. So aus der Ferne sieht das bei PHP ähnlich aus, und beide Sprachen sind inzwischen mehr tot als lebendig. > Das ist ja ein Ding. Und jetzt rechne mal nach, > wie alt moderne Sprachen wie Rust sind. > Und dann rechne einmal nach, wann C seinen ersten Standard bekam. Die formale Definition von C ist wesentlich älter als ihr erster Standard. Und zumindest ich trenne auch noch zwischen der Standardbibliothek und der Sprachdefinition selbst, aber da gibt es sicher auch andere Ansichten. > Gut. Dann ist ja alles in Butter. > Die Rust-Entwicklung ist einem starken > formellen Prozess unterlegen. Und am Ende des Prozesses steht ein "der Compiler hat Recht".
S. R. schrieb: > Und am Ende des Prozesses steht ein "der Compiler hat Recht". Ziemlicher Quatsch. Wie wäre es, wenn ihr euch Rust und den Entwicklungsprozess einmal anschaut?
MaWin schrieb: > Jörg W. schrieb: >> Die Kritik ist, dass sie es bis heute nicht geschafft haben, eine >> formale Definition aufzuschreiben. > > Ja gut. Das ist richtig. > Damit reiht Rust sich in 99% aller Sprachen ein. > Scheint wohl kein allzu großes Problem zu sein. > > Für welche Sprachen gibt es überhaupt eine offizielle Standardisierung? Es gibt auch noch was zwischen kar keiner Definition der Sprache und einem ISO-Standard. > Python, Matlab. Alles Sprachen kurz vor dem Bankrott. Niemand verwendet > sie. Denn sie haben ja keine offizielle Standardisierung. Sie haben aber eine formale Definition. >> Python ist da (wie ich oben mal schrieb) weiter. > > Unsinn. Befasse dich einmal bitte mit der Rust-Entwicklung, bevor du sie > bewertest. Hier ist die formale Definition von Python: https://docs.python.org/3/reference/index.html Wo ist das Äquivalent für Rust?
:
Bearbeitet durch User
Rolf M. schrieb: > Hier ist die formale Definition von Python: > I chose to use English rather than formal specifications for everything except syntax and lexical analysis. This should make the document more understandable to the average reader, but will leave room for ambiguities. Consequently, if you were coming from Mars and tried to re-implement Python from this document alone, you might have to guess things and in fact you would probably end up implementing quite a different language. [...] If you would like to see a more formal definition of the language, maybe you could volunteer your time — or invent a cloning machine :-). "formale Spezifikation"
Jemand schrieb: > [...] Lustig, dass du gerade den Satz übersprungen hast: "On the other hand, if you are using Python and wonder what the precise rules about a particular area of the language are, you should definitely be able to find them here."
MaWin schrieb: > Damit reiht Rust sich in 99% aller Sprachen ein. Nein. > Für welche Sprachen gibt es überhaupt eine offizielle Standardisierung? Es ging nicht um offizielle Standardisierung, sondern wenigstens mal selbst eine formale Sprachdefinition aufzuschreiben. Python beispielsweise hat sowas, habe ich dir geschrieben. Es geht auch nicht um "kurz vor dem Bankrott", sondern darum, dass sowas eine sinnvolle Basis dafür ist, dass jemand anders eine unabhängige Implementierung vornimmt. Aber du drehst uns die Worte im Munde rum, für dich sind wir die Bösen, die nur das neue scheuen, nur weil wir nicht 100 % in deine Lobpreisung einstimmen. Das ist keine Diskussionsbasis.
Jörg W. schrieb: > nur weil wir nicht 100 % in deine Lobpreisung einstimmen. Meine Lobpreisung existiert nur in deiner Fantasie. Ich sehe durchaus die Schwächen von Rust und habe das auch schon mehrfach hier geschrieben. Und ja, das Fehlen einer vollständigen formellen Sprachdefinition ist ein Teil davon. Ich stimme euch lediglich nicht dabei zu, dass das ein riesiges Problem ist. > Python beispielsweise hat sowas, habe ich dir geschrieben. Das ist genau so unvollständig, wie die Dokumentation von Rust. Trotzdem ist Python extrem erfolgreich. Komisch, gell?
MaWin schrieb: > Ich stimme euch lediglich nicht dabei zu, dass das ein riesiges Problem > ist. Das Thema kam nur im Zusammenhang damit hoch, dass den Thread jemand wieder hochgeholt hat um zu erzählen, dass das jetzt in GCC drin ist. Für eine unabhängige Compiler-Implementierung ist es vielleicht nicht ein "riesiges" Problem, aber zumindest aus Sicht mehrerer Leute hier durchaus ein Problem. Um nicht mehr und nicht weniger ging es. > Das ist genau so unvollständig, wie die Dokumentation von Rust. Kann gut sein, aber es ist ein Anfang, den Rust (an der Stelle) sich noch nicht die Mühe gemacht hat zu gehen. Eine derartige Unvollständigkeit würde natürlich wiederum erklären, warum die Alternativ-Implementierungen teilweise eben auch in der Vollständigkeit hinter CPython hinterher hinken – womit indirekt bewiesen ist, dass eine fehlende saubere und vollständige formale Beschreibung eben für alternative Implementierungen durchaus ein Problem sein kann. Wie geschrieben: darum, ob die Sprache selbst nun gut oder schlecht oder brauchbar ist oder nicht, ging's hier gerade gar nicht.
Jörg W. schrieb: > aber es ist ein Anfang, den Rust (an der Stelle) sich > noch nicht die Mühe gemacht hat zu gehen. Das ist natürlich auch mal wieder Quatsch. Die Rust Features werden alle in Issues/RFCs beschrieben und entwickelt. Und es gibt auch Bücher, die diese Informationen zusammentragen. https://doc.rust-lang.org/stable/unstable-book/the-unstable-book.html https://rustc-dev-guide.rust-lang.org/getting-started.html https://doc.rust-lang.org/nomicon/
Jörg W. schrieb: > darum, ob die Sprache selbst nun gut oder schlecht oder > brauchbar ist oder nicht, Ach. Das ist ja ein Ding. Da muss ich mich wohl falsch erinnern. Mal sehen... Cyblord -. schrieb: > IMO ist Rust schon tot. Ach, wohl doch nicht.
MaWin schrieb: > Jörg W. schrieb: >> darum, ob die Sprache selbst nun gut oder schlecht oder >> brauchbar ist oder nicht, > > Ach. Das ist ja ein Ding. Da muss ich mich wohl falsch erinnern. > Mal sehen... Was schmeißt du fremde Zitate in meine Argumentation? Klar gibt es Doku, hat keiner bestritten. Aber der Ansatz, einen alternativen Compiler zu entwickeln, geht halt normalerweise nicht über das Studium von Prosa oder gar Sourcecode eines anderen Compilers, sondern über eine formale Sprachdefinition. Wenn es die nicht gibt, wird der alternative Compiler irgendwie immer der zweite Sieger bleiben. Mehr war hier nicht als Argumentation (wenn man von solchen Blasen absieht, wie du zitiert hast – ich weiß bloß nicht, warum du dich über solcherart begründungslos hingeworfene Meinungsäußerungen derart aufregst).
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Was schmeißt du fremde Zitate in meine Argumentation? Weil nicht nur du und ich an der Diskussion teilnahmen. Der zitierte Satz war der Ausgangspunkt der ganzen Diskussionskette, deren Teil auch du bist. > Aber der Ansatz, einen > alternativen Compiler zu entwickeln, geht halt normalerweise nicht über > das Studium von Prosa oder gar Sourcecode eines anderen Compilers, > sondern über eine formale Sprachdefinition. Offensichtlich geht es halt doch auch anders. > Wenn es die nicht gibt, wird der alternative Compiler irgendwie immer > der zweite Sieger bleiben. Für dich. Und das darfst du gerne so sehen. Ich sehe das anders. > ich weiß bloß > nicht, warum du dich über solcherart begründungslos hingeworfene > Meinungsäußerungen derart aufregst). Wo genau rege ich mich auf?
MaWin schrieb: >> Wenn es die nicht gibt, wird der alternative Compiler irgendwie immer >> der zweite Sieger bleiben. > > Für dich. > Und das darfst du gerne so sehen. > Ich sehe das anders. Du hast ja schon mehrfach (Auch gerade wieder im benachbarten Thread Beitrag "Komplexe typedef struct mit 0 initialisieren") gezeigt, dass du dich nicht wirklich dafür interessierst, wie die Sprache etwas definiert. Hauptsache der Compiler schluckt es.
Mombert H. schrieb: > Auch gerade wieder im benachbarten Thread Kannst du bitte aufhören hier den Thread zuzumüllen? Danke.
Wo kommt denn bitte diese ganze altmodische, absolutistische (Ein Standard, Ein Kompiler, Ein Entscheider) Denkweise her? Es ist doch keines der komplexen Systeme die wir heute verwenden so enstanden? Und der Entwicklungsprozess war deswegen nicht besser oder schlechter - das ist eben Evolution in komplexen Systemen - und dazu zählen auch Programmiersprachen bestes Beispiel die Programmiersprache(n): C/C++ - von der wir hoffentlich alle Wissen das sie einer doch noch immer einflussreichsten Sprachen der Welt ist Es gab über Jahrzehnte nur ein paar Player auf dem Kompilermarkt - Microsoft, GCC, Intel, ... die waren auch alle gar nicht so super kompatible - jeder hat sich so weit wie möglich am Marktstärksten (nicht unbedingt am Standard) orientiert, Microsoft hat Micro-Details in "sein" C++ eingebaut wo es nur ging das waren Jahrzehnte des unklaren driftens - da war die Frage immer erst "Mit welchem C++ Kompiler wurde das gebaut" Und wer die Erfahrung nicht gemacht hat weil zu Jung oder nicht in dem Business war kann hier so gut wie gar keinen Senf zu abgeben und das C++ Konsortium konnte das so gut wie nicht unter kontrolle halten dann kam der LLVM/Clang - das Geschrei war laut - "noch ein Kompiler, noch mehr Probleme, können wir uns nicht auf einen konzentrieren, Blababla..." aber es kam auch: -der LLVM/Clang wurde so gut das der GCC mal wieder kämpfen musste und wieder besser wurde -beide haben sich unglaublich beschleunigt in besserer Diagnose, Support von neueren Standards, weniger Sonderfeatures die wirklich nicht sind portierbar sind und,und,und -selbst Microsoft musste sich dem ganzen beugen und hat wieder richtig konstruktiv begonnen an der Sprache und dem Kompilern mitzuarbeiten das alles weil "nur" ein neuere Kompiler aufgetaucht ist - ohne Clang wäre das wohl alles nicht passiert niemand der offenen Auges durch die C/C++ Branche wandelt kann das nur im entfernsteten Bestreiten - die letzten Jahren sind wirklich erstaunlich weil endlich mal wieder richtige Evolution passiert ist - der geistige GCC "Fork" machte Konkurrenz und hat den Markt einfach mal wieder wach gerüttelt das ist typische evolutionäre Entwicklung wie sie für komplexe System nötig ist - das schadet nicht - dauert nur länger als wenn der einzge König/Firma/Konsortium von oben die perfekten Vorgaben macht - die Systeme sind viel zu umfangreich geworden als das so etwas nur noch im Ansatz sinnvoll funktioniert - und das haben alle Grossen der Branche schon lange verstanden und arbeite (Achtung Buzword) "Agil" an Lösungen - so lange bis sich der richtige Standard durch Leistung und Überleben herauskristalisiert, bis der auch wieder unrelevant wird die meisten Argumente sind völlig sinnfrei weil sich sowiso die Systeme durchsetzen die passen - ob UNS das dann immer passt ist eine andere Frage und ein Sprachstandard in der 1. Stunde hat auch Javascript nicht verhindern können :)
und die besten Flitzpiepen sind die welche Denken das sich Linus und Greg Kroah-Hartman und andere unbedacht eine Sprache in ihren Kernel holen die dann ihr Lebenswerk verschlechtert so Idioten-Argumente wie: -ob die wissen das Rust gar nicht mit dem gcc kompiliert werden kann -das Cargo dann alle Kernel-Dependecies dann aus dem Internet holen muss -man doch lieber go nehmen sollte usw. das ist so unglaublich naiv das es schon weh tut
cppbert schrieb: > das ist so unglaublich naiv das es schon weh tut So ist das halt, wenn man sich für den größten Sprachexperten der Welt hält. Da werden dann schon einmal gerne Sprachen totgesagt, die weltweit gerade steil gehen. Was dem Mikrocontroller.net-Experten nicht gut genug ist, kann auch nix sein. > -ob die wissen das Rust gar nicht mit dem gcc kompiliert werden kann > -das Cargo dann alle Kernel-Dependecies dann aus dem Internet holen muss Exakt dies. Diese zwei Fragen wurden vor Jahren bereits von den Kernelexperten diskutiert und verstanden.
oder jetzt wo der Linus das erstmal eine andere Programmiersprache für den Kernel präsentiert bekommt ist er blöderweise anr Rust geraten, der kann das bestimmt null einschätzen - die anderen beteiligten bestimmt auch nicht - die wurden bestimmt überredet, so hilflos... das ist mehr oder minder der überspitzte Inhalt der meisten Diskussionen - als hätten die Kernel-Entwickler so mehr oder minder zufällig ~30Mio Zeilen Code zusammengeschraubt die unsere Welte mehr oder minder am Laufen hält :)
MaWin schrieb: > Exakt dies. Diese zwei Fragen wurden vor Jahren bereits von den > Kernelexperten diskutiert und verstanden. dieses Argument schlägt alle Rekorde - es ist seit Jahren unrelevant weil man es machen kann wie man will - und die Kernel-Leute machen das auch so aber es kommt immer und immer und immer wieder hoch
Und der fehlende Sprachstand juckt Microsoft, Amazon und x andere null, nicht mal das GCC Steering Committee interessiert das
MaWin schrieb: > Wo genau rege ich mich auf? "Dummes Blah.", "ihr Knalltüten" – bestimmt findet sich noch mehr. Unterstellte Lernunwilligkeit: "Ich glaube ihr habt eher Angst vor Umbrüchen und Neuem.", obwohl man was ganz anderes kritisiert. cppbert schrieb: > Es gab über Jahrzehnte nur ein paar Player auf dem Kompilermarkt - > Microsoft, GCC, Intel Es gab deutlich mehr, du beschreibst nur die PC-Welt. Fängt ja schon damit an, dass C++ als erstes durch CFront implementiert worden war, initial völlig außerhalb der PC-Welt. Die anderen waren und sind auch nicht so schräg drauf wie beispielsweise Microsoft, die erst nach Jahrzehnten überhaupt mal einen neuen Standard akzeptieren können. Bis auf notwendigerweise nicht von einem Standard abdeckbare Dinge (wie Interrupts) konnte und kann man beispielsweise klaglos Programme für Microcontroller von GCC und IAR compilieren lassen. Die C++-Welt mag da mit ihrem Featurismus anders ticken, für C ist die Entwicklung eher langsam vonstatten gegangen. Aber natürlich, Entwicklung gab es immer, und der übliche Weg bei internationalen Standards ist es, dass das Standardisierungsgremium Dinge übernimmt, die sich bereits in der Praxis bewährt haben, statt sich Dinge selbst auszudenken. Trotzdem gab es da immer eine gemeinsame Basis, die recht gut beschrieben war und ist (und das auch schon vor dem ersten C-Standard, sonst hätte es beispielsweise einen GCC nie geben können – der kam zwei Jahre vor dem ersten offiziellen Standard heraus).
Jörg W. schrieb: > sonst hätte es beispielsweise einen GCC nie geben können – > der kam zwei Jahre vor dem ersten offiziellen Standard heraus Was? Das ist ja ungeheuerlich! Wie kann das sein? Das ist doch völlig unmöglich Compiler ohne Standard zu entwickeln, habe ich hier gelernt.
Jörg W. schrieb: > cppbert schrieb: > >> Es gab über Jahrzehnte nur ein paar Player auf dem Kompilermarkt - >> Microsoft, GCC, Intel > > Es gab deutlich mehr, du beschreibst nur die PC-Welt. Ja das hatte ich vergessen zu erwähnen, aber das ist ja auch ein grosser Teil des Markts > Die C++-Welt mag da mit ihrem Featurismus anders ticken, für C ist die > Entwicklung eher langsam vonstatten gegangen. Aber natürlich, > Entwicklung gab es immer, und der übliche Weg bei internationalen > Standards ist es, dass das Standardisierungsgremium Dinge übernimmt, die > sich bereits in der Praxis bewährt haben, statt sich Dinge selbst > auszudenken. Trotzdem gab es da immer eine gemeinsame Basis, die recht > gut beschrieben war und ist (und das auch schon vor dem ersten > C-Standard, sonst hätte es beispielsweise einen GCC nie geben können – > der kam zwei Jahre vor dem ersten offiziellen Standard heraus). Bei C ist das auch viel einfacher weil die Sprach recht ausdrucksschwach ist, ganz neutral ausgedrueckt Wenn es in der Praxis keine guten Lösungen gibt muss man sich neues ausdenken, auch wenn viele gar keine Probleme sehen die man angreifen sollte/könnte Es hört sich leider oft so an als würden hier viele glauben das ein zur zeit nicht bestehender Standard automatisch irgendwie zu Chaos führt der irgendwie nicht mehr kontrollierbar wäre, genauso wie ein zweiter Kompiler, das ist zu drastisch gedacht und Realitätsfern, wer sollte interesse an sowas haben und zu welchem Zweck (mal die Schattenregierung ausser vor gelassen) Wie gesagt das GCC Steering Comittee stört das gerade nicht sonderlich und viele andere auch nicht, wiso sind die nicht so kritisch?
cppbert3 schrieb: > auch wenn viele gar keine Probleme sehen die man angreifen sollte/könnte Das ist ungefähr der selbe Prozentsatz der auch keine Sanitizer braucht oder nutzt :)
cppbert3 schrieb: > cppbert3 schrieb: > >> auch wenn viele gar keine Probleme sehen die man angreifen sollte/könnte > > Das ist ungefähr der selbe Prozentsatz der auch keine Sanitizer braucht > oder nutzt :) Was nicht bedeutet das logische Fehler nicht auch ein grosser Teil der üblichen Fehler sind
MaWin schrieb: > Jörg W. schrieb: >> sonst hätte es beispielsweise einen GCC nie geben können – >> der kam zwei Jahre vor dem ersten offiziellen Standard heraus > > Was? Das ist ja ungeheuerlich! > Wie kann das sein? Das ist doch völlig unmöglich Compiler ohne Standard > zu entwickeln, habe ich hier gelernt. Du hast bis jetzt den Unterschied zwischen einer formalen Sprachdefinition und einem (irgendwie "offiziellen", ISO oder was auch immer) Standard noch nicht verstanden, obwohl dir nun bereits mehrere Leute versucht haben, diesen zu verdeutlichen. Dafür titulierst du andere als Knalltüten und was weiß ich nicht was.
Jörg W. schrieb: > Du hast bis jetzt den Unterschied zwischen einer formalen > Sprachdefinition und einem (irgendwie "offiziellen", ISO oder was auch > immer) Standard noch nicht verstanden, obwohl dir nun bereits mehrere > Leute versucht haben, diesen zu verdeutlichen. > Dafür titulierst du andere als Knalltüten und was weiß ich nicht was. Weil hier die Leute so auf Microdetails achten und dann darauf rumreiten Und nochmal das GCC Steering Committee stört es nicht, warum jemanden hier? Oder besser warum ist das nur hier ein Argument?
cppbert3 schrieb: > Oder besser warum ist das nur hier ein Argument? Ob das "nur hier" eins ist, weiß ich nicht. Ich habe auch keine Idee, was die GCC-Leute so bewegt und was sie als Kriterien für irgendwelche Frontends haben. Schätzungsweise wird die aktuell erlangte Popularität von Rust schon dazu beigetragen haben, das dort offiziell mit aufzunehmen.
Jörg W. schrieb: > Du hast bis jetzt den Unterschied zwischen einer formalen > Sprachdefinition und einem (irgendwie "offiziellen", ISO oder was auch > immer) Standard noch nicht verstanden, obwohl dir nun bereits mehrere > Leute versucht haben, diesen zu verdeutlichen. Ahh. Jetzt verstehe ich! Diese formale Sprachdefinition ist also der Teil, der eine erfolgreiche Sprache von einem Fehlschlag unterscheidet. Endlich erklärt mir das mal jemand. Jetzt solltet ihr das auch noch Mozilla, Linus, Microsoft und vielen anderen Stümpern erklären. > Dafür titulierst du andere als Knalltüten und was weiß ich nicht was. Ich bitte um Entschuldigung. Ich wusste bisher nicht, dass Mozilla, Linus, Microsoft und die vielen anderen Stümper in Wahrheit die merkbefreiten Knalltüten sind und nicht die Mitglieder des Mikrocontroller.net-Forums. cppbert3 schrieb: > Weil hier die Leute so auf Microdetails achten und dann darauf rumreiten So ist das nun einmal, wenn man sich mit der Materie nicht auskennt. Dann pickt man sich irgendein Detail raus und reitet darauf herum und erklärt den gccrs mal eben für gescheitert. Jörg W. schrieb: > Ob das "nur hier" eins ist, weiß ich nicht. Das kann ich dir auch nicht sagen. Aber für Mozilla, Linus, Microsoft und die vielen anderen Stümper, ist es offenbar kein Argument. Jörg W. schrieb: > Schätzungsweise wird die aktuell erlangte Popularität > von Rust schon dazu beigetragen haben Wie kam es überhaupt zu dieser Popularität? So ganz ohne formale Sprachdefinition.
Jörg W. schrieb: > cppbert3 schrieb: > >> Oder besser warum ist das nur hier ein Argument? > > Ob das "nur hier" eins ist, weiß ich nicht. Ich habe auch keine Idee, > was die GCC-Leute so bewegt und was sie als Kriterien für irgendwelche > Frontends haben. Schätzungsweise wird die aktuell erlangte Popularität > von Rust schon dazu beigetragen haben, das dort offiziell mit > aufzunehmen. gilt das deiner Meinung nach auch für den Linux-Kernel? Was sagt das über die Entscheidungsqualtät der an diesen Projekten beteiligten Personen aus?
MaWin schrieb: > Diese formale Sprachdefinition ist also der Teil, der eine erfolgreiche > Sprache von einem Fehlschlag unterscheidet. Du erzählst schon wieder völligen Unfug, um mal mit deinen Worten zu reden – vielleicht verstehst du so eine Sprache ja besser, denn keiner (von den ernsthaften Diskutanten) hat behauptet, dass Rust ein Fehlschlag sei. Mit dir zu diskutieren, erweist sich wiederholt schlicht als sinnlos, du drehst alles so herum, dass du dich maximal drüber aufregen kannst. Ich sollte meine Zeit besser darauf verwenden, was Vernünftiges zu tun, vielleicht endlich mal wieder VHDL anzusehen zum Beispiel. Das wäre mir beispielsweise aktuell wichtiger als Rust.
Und ja MaWin kann patzig sein, ihr seit das aber auch irgendwie, GUT IST
cppbert3 schrieb: > gilt das deiner Meinung nach auch für den Linux-Kernel? Beides dürfte miteinander im Zusammenhang stehen. Linux möchte GCC (während bspw. Apple extra den Clang gepusht hat, um von GCC wegzukommen), und für GCC ist es wiederum ein wesentliches Anwendungsfeld. ps: Andererseits ist natürlich für Linux ein anwendungsfähiger Compiler das wesentliche Kriterium, nicht irgendeine formale Sprachdefinition, das ist wohl keine Frage. Dürfte im Gegenzug den Druck auf GCC erhöht haben, sich der Sprache zu widmen.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > MaWin schrieb: > >> Diese formale Sprachdefinition ist also der Teil, der eine erfolgreiche >> Sprache von einem Fehlschlag unterscheidet. > > Du erzählst schon wieder völligen Unfug, um mal mit deinen Worten zu > reden – vielleicht verstehst du so eine Sprache ja besser, denn keiner > (von den ernsthaften Diskutanten) hat behauptet, dass Rust ein > Fehlschlag sei. Das sagt er nur überspitzt und alle anderen reagieren wieder mit Microdetails, das kann sehr wirklich nervig sein, was leider auch ein wenig typisch für das Forum ist
cppbert3 schrieb: > Das sagt er nur überspitzt Naja, andere würden es als sehr persönliche Beleidigung empfinden, wenn sie als "Knalltüten" bezeichnet werden, nur weil sie eine andere Meinung haben als er.
Jörg W. schrieb: > cppbert3 schrieb: > >> Das sagt er nur überspitzt > > Naja, andere würden es als sehr persönliche Beleidigung empfinden, wenn > sie als "Knalltüten" bezeichnet werden, nur weil sie eine andere Meinung > haben als er. Du machst es schon wieder, lass doch dieses Satz-Sezieren, das ist deiner unwürdig
Jörg W. schrieb: > du drehst alles so herum Ich verdrehe hier die Tatsachen? Sehr interessante Sichtweise. > dass du dich maximal drüber aufregen kannst. Wie bereits mehrfach gesagt: Ich rege mich hier überhaupt nicht auf. Ich amüsiere mich prächtig. > Du erzählst schon wieder völligen Unfug Ach. Sag bloß. Könnte das daran liegen, dass das nicht ganz ernst gemeint war und bewusst so formuliert war? cppbert3 schrieb: > Das sagt er nur überspitzt und alle anderen reagieren wieder mit > Microdetails, Du hast es gut erkannt. ;)
Jörg W. schrieb: > cppbert3 schrieb: > >> gilt das deiner Meinung nach auch für den Linux-Kernel? > > Beides dürfte miteinander im Zusammenhang stehen. Linux möchte GCC > (während bspw. Apple extra den Clang gepusht hat, um von GCC > wegzukommen), und für GCC ist es wiederum ein wesentliches > Anwendungsfeld. > ps: Andererseits ist natürlich für Linux ein anwendungsfähiger Compiler > das wesentliche Kriterium, nicht irgendeine formale Sprachdefinition, > das ist wohl keine Frage. Dürfte im Gegenzug den Druck auf GCC erhöht > haben, sich der Sprache zu widmen. Ich finde es wiederum erstaunlich wie wenig Frontend man nur braucht um ins main repo zu kommmen, aber trotzdem ist es gut, das wird schlussendlich eine Menge mehr Entwickler an die Sprache bringen, sie muss gequält werden damit was gutes entstehen kann
MaWin schrieb: > Jörg W. schrieb: > >> du drehst alles so herum > > Ich verdrehe hier die Tatsachen? Sehr interessante Sichtweise. Du musst aber auch mal aufhören Öl ins Feuer zu schütten :)
cppbert3 schrieb: > aber trotzdem ist es gut, das wird > schlussendlich eine Menge mehr Entwickler an die Sprache bringen, sie > muss gequält werden damit was gutes entstehen kann Genau so ist es. Alles dies wird passieren. Was garantiert nicht passieren wird ist das, was hier im Forum postuliert wird. Gccrs wird nicht die zweite unbedeutende Geige spielen. Gccrs wird nicht in endlosen Grabenkämpfen zu strict aliasing ertrinken. Es wird Meinungsverschiedenheiten geben. Und das ist etwas Gutes! Denn nur durch das Lösen von Meinungsverschiedenheiten kann wirkliche Weiterentwicklung entstehen. Das gilt auf für Forumsmitglieder. Die "guten alten Zeiten", wo man sich erst einmal um eine formale Sprachdefinition kümmerte, sind vorbei. Genauer gesagt, gab es diese Zeiten nie. Moderne Sprachen sind so komplex, dass es erst einmal wichtiger ist sie praktisch nutzbar zu machen, als irgendein furztrockenes Dokument zu erstellen, das niemandem weiterhilft. Und falls ihr dennoch der Meinung seid, dass man jetzt direkt eine Sprachdefinition braucht: Rust ist Open Source. Also bitte. Oder ihr müsst euch von dieser Denkweise lösen.
MaWin schrieb: > Gccrs wird nicht in endlosen Grabenkämpfen zu strict aliasing ertrinken. Dann bekommt der gcc auch mal endlich die Möglichkeit über x Versionen strict aliasing Fehler im Kompiler zu finden, genau so wie der LLVM leiden musste
cppbert3 schrieb: > das wird schlussendlich eine Menge mehr Entwickler an die Sprache > bringen Da vermute ich, dass der Einfluss von Linux größer ist als der von GCC. Den Leuten, die die Sprache benutzen wollen, ist das vermutlich mittelmäßig egal, solange es mindestens einen brauchbaren (und freien) Compiler gibt, die könn(t)en also auch ohne GCC prima damit arbeiten. Die Affinität zu einem bestimmten Compiler hat ja eher religiöse, äh, lizenzpolitische Gründe (Apple -> kein GPL, Linux -> unbedingt GPL).
Jörg W. schrieb: > Die Affinität zu einem bestimmten Compiler hat ja eher religiöse, äh, > lizenzpolitische Gründe (Apple -> kein GPL, Linux -> unbedingt GPL). Das schon aber sehr lange Zeit war der Kernel aber auch voll mit GCC Spezialitäten (so viel zu wohldefinierten Standards), ich glaube es ist immer nicht so einfach den Kernel mit Clang zu bauen, oder
MaWin schrieb: > Jetzt solltet ihr das auch noch Mozilla, Linus, Microsoft und vielen > anderen Stümpern erklären. Ich wäre gern die Fliege an der Wand, wenn du Linus ins Gesicht als Stümper bezeichnest... > Dann pickt man sich irgendein Detail raus und reitet darauf herum und > erklärt den gccrs mal eben für gescheitert. Gescheitert ist das falsche Wort. Aber der Einfluss - außerhalb von Linux - dürfte wesentlich geringer bleiben, bis es eine Spezifikation gibt. > Wie kam es überhaupt zu dieser Popularität? > So ganz ohne formale Sprachdefinition. Wie bei Javascript, ebenfalls eine der besten Programmiersprachen, die dieser Planet jemals hervorgebracht hat. Jörg W. schrieb: > Den Leuten, die die Sprache benutzen wollen, ist das vermutlich > mittelmäßig egal, solange es mindestens einen brauchbaren (und freien) > Compiler gibt, die könn(t)en also auch ohne GCC prima damit arbeiten. Viele Sprachen haben nur genau einen relevanten Compiler (bzw. alle anderen sind effektiv Forks - mangels gebrauchbarer Spezifikation) und sie werden trotzdem benutzt. Wer sich in die Abhängigkeit begeben will, den kann man daran nicht hindern. Suizid ist schließlich auch nicht strafbar. > Die Affinität zu einem bestimmten Compiler hat ja eher religiöse, äh, > lizenzpolitische Gründe (Apple -> kein GPL, Linux -> unbedingt GPL). Nicht nur, die Geldflüsse wären da auch zu betrachten. Wo das Geld in Massen hinströmt, da wollen alle anderen auch hin. Erstmal anstellen, wenn man eine Warteschlange sieht, egal warum.
cppbert3 schrieb: > Das schon aber sehr lange Zeit war der Kernel aber auch voll mit GCC > Spezialitäten (so viel zu wohldefinierten Standards), ich glaube es ist > immer nicht so einfach den Kernel mit Clang zu bauen, oder Der Kernel hat aber auch nie behauptet, in C geschrieben zu sein. Und er wird sicher auch nie behaupten, in Rust geschrieben zu sein. Aus den gleichen Gründen.
Jörg W. schrieb: > Den Leuten, die die Sprache benutzen wollen, ist das vermutlich > mittelmäßig egal, solange es mindestens einen brauchbaren (und freien) > Compiler gibt, die könn(t)en also auch ohne GCC prima damit arbeiten. Nein. Es gibt ganz praktische Vorteile von GCC. Beispielsweise das enorm viel breitere Spektrum an unterstützten Architekturen. Das bedeutet zwar nicht, dass Gccrs automatisch auch alle diese unterstützt, aber es bereitet die notwendige Basis dafür. Das ist der Schlüssel für Rust-Embedded. > Linux -> unbedingt GPL Die Bindung von Linux an GCC hat rein technische Gründe. Sie fußt in der enormen Nutzung von GCC-Extensions in Linux. Das Linux-clang-Projekt ist (war? Ich weiß den aktuellen Zustand nicht) ein enorm großes Projekt.
Achja, falls das hier manchen nicht klar ist: GCC + Rust gibt es in zwei Varianten. 1) Rust-Frontend in GCC. Darum ging es hier im Gespräch hauptsächlich. 2) GCC als codegen backend von rustc. Beide werden aktiv entwickelt und beide sind wichtig für die Sprache. (1) ist ein eigenständiges Projekt und (2) ist (wird) Teil vom ursprünglichen Rust-Compiler.
S. R. schrieb: > MaWin schrieb: > >> Jetzt solltet ihr das auch noch Mozilla, Linus, Microsoft und vielen >> anderen Stümpern erklären. > > Ich wäre gern die Fliege an der Wand, wenn du Linus ins Gesicht als > Stümper bezeichnest... Alles nur halb zu lesen ist hier echt Standard im Forum, es ging darum das Linus Rust im Kernel akzeptiert und da Rust ja nicht gut ist es nur an Linus schlechtigkeit liegen kann das er die Sprache akzeptiert Nur damit auch du es peilst: MaWin ist Pro Rust UND Pro Linux/Linus :)
S. R. schrieb: > cppbert3 schrieb: > >> Das schon aber sehr lange Zeit war der Kernel aber auch voll mit GCC >> Spezialitäten (so viel zu wohldefinierten Standards), ich glaube es ist >> immer nicht so einfach den Kernel mit Clang zu bauen, oder > > Der Kernel hat aber auch nie behauptet, in C geschrieben zu sein. > Und er wird sicher auch nie behaupten, in Rust geschrieben zu sein. > Aus den gleichen Gründen. Und mit diese Microrelevanzaussage konter ich jetzt wie?
cppbert3 schrieb: > ich glaube es ist immer nicht so einfach den Kernel mit Clang zu bauen Clang hat allerdings von vornherein überall versucht, ein kompletter GCC-Ersatz zu sein und von daher auch allerlei GCC-Erweiterungen übernommen. MaWin schrieb: > Es gibt ganz praktische Vorteile von GCC. Beispielsweise das enorm viel > breitere Spektrum an unterstützten Architekturen. Ja, sicher, aber die, die jetzt Rust einsetzen, werden das schätzungsweise vorranging auf solchen Architekturen tun, für die es llvm-Backends gibt. llvm-Backends gibt's ja schließlich auch für alles Mögliche inzwischen. Im "deeply embedded" (also echte Microcontroller, keine miniaturisierten Allroundmachinen wie Raspberry etc.) hat man ja schon Mühe, mal jemanden zu finden, der wenigstens C++ akzeptieren würde. Sehe ich in den diversen Jobs meiner letzten Jahre, selbst an Stellen, wo ein OO-Ansatz durchaus günstig wäre, findet man kaum Kundschaft, der das als Argument für C++ ausreichend ist. Bis Rust dort ankommt (und damit jenseits dessen, was llvm als Backends hat), wird noch 'ne Menge Wasser Rhein und Elbe herunter fließen.
MaWin schrieb: > Das Linux-clang-Projekt ist (war? Ich weiß den aktuellen Zustand nicht) > ein enorm großes Projekt. Interessanterweise schien bei FreeBSD der Aufwand doch recht überschaubar. Bei denen ist nun schon seit einigen Jahren Clang als Standard dabei – und ein Kernel hat logischerweise auch dort 'ne ganze Reihe von Compiler-Erweiterungen benutzt.
Jörg W. schrieb: > Clang hat allerdings von vornherein überall versucht, ein kompletter > GCC-Ersatz zu sein und von daher auch allerlei GCC-Erweiterungen > übernommen. Trotzdem hat es Jahre gedauert bis das richtig ging
Jörg W. schrieb: > und ein Kernel hat logischerweise auch dort 'ne ganze > Reihe von Compiler-Erweiterungen benutzt. Linux nutzt wesentlich mehr GCC-Spezialitäten als BSD. Linux verwendet auch GCC-Plugins. Die Grundfunktionalität (ein funktionierendes Linux-System) lässt sich schon länger mit clang erzeugen. Aber alle Features gingen zumindest bis vor ein paar Jahren noch nicht. Wie es aktuell ist, weiß ich nicht. Jörg W. schrieb: > Clang hat allerdings von vornherein überall versucht, ein kompletter > GCC-Ersatz Die Worte "überall" und "kompletter" würde ich hier weglassen und durch sowas wie "weitgehend" ersetzen. Selbst auf ABI-Ebene ist LLVM nicht vollständig kompatibel. (128Bit Integers). Was aber eher als ein Bug angesehen wird. Jörg W. schrieb: > Ja, sicher, aber die, die jetzt Rust einsetzen, werden das > schätzungsweise vorranging auf solchen Architekturen tun, für die es > llvm-Backends gibt. Auch für die Leute, die jetzt Rust einsetzen, bringt jeder weitere Compiler nur Vorteile. Second Source. Bessere Sprachdefinition. Bessere Testabdeckung. > llvm-Backends gibt's ja schließlich auch für alles > Mögliche inzwischen. Es kommt auch auf die Qualität der Backends an. Das AVR-Backend in clang ist nicht wirklich gut. Da will man GCC haben (Ja, das ist vielleicht ein schlechtes Beispiel, weil GCC-AVR auch nicht mehr wirklich weiterentwickelt wird. Aber besser als clang ist es). Jörg W. schrieb: > Bis Rust dort ankommt (und damit jenseits > dessen, was llvm als Backends hat), wird noch 'ne Menge Wasser Rhein und > Elbe herunter fließen. Das ist richtig. Aber das ist kein Problem, was Rust lösen kann. Das muss sich in den Betonköpfen der Nutzer-Projektentscheider lösen. C++ wäre ein Schritt in die richtige Richtung. Aber bitte mit wenig OOP. Sonst muss man die wieder abtrainieren, wenn man zu Rust wechselt ;)
MaWin schrieb: > Nein. Es gibt ganz praktische Vorteile von GCC. Beispielsweise das enorm > viel breitere Spektrum an unterstützten Architekturen. Das bedeutet zwar > nicht, dass Gccrs automatisch auch alle diese unterstützt, aber es > bereitet die notwendige Basis dafür. Alternativ portiert man diese Architekturen nach LLVM. Das ist wegen der GPL sowieso der bevorzugte Weg für viele Firmen, wenn sie den Aufwand überhaupt treiben wollen. > Die Bindung von Linux an GCC hat rein technische Gründe. > Sie fußt in der enormen Nutzung von GCC-Extensions in Linux. Ja und nein. Clang will aus lizenztechnischen Gründen ein vollwertiger Ersatz sein und implementiert daher auch alle relevanten GCC-Extensions. Technische Gründe gibt es daher keine mehr, und die politischen Gründe werden auch weniger, weil viel Geld in bestimmte Richtungen fließt. > Das Linux-clang-Projekt ist (war? Ich weiß den aktuellen > Zustand nicht) ein enorm großes Projekt. Sämtliche Android-Kernel werden ausschließlich mit Clang gebaut. Google hat außerdem die letzten Jahre sehr viel (erfolgreich) investiert, um die Unterschiede zum Mainline-Kernel zu reduzieren. Dazu kommt, dass so gut wie alle Mitstreiter am Kernel heutzutage dafür bezahlt werden. Ein großer Teil der betroffenen Firmen kommen aus dem Embedded-Bereich und dort ist Android-Kompatiblität wichtig. Also baut der Code auch mit clang (und dessen Forks) bzw. wird nur damit getestet. Das von dir genannte Projekt war vor allem deswegen kompliziert, weil (a) clang damals einige GCC-Extensions nicht kannte; (b) der Kernel nicht nur GCC-Extensions benutzt, sondern auch gezielt GCC-Verhalten ausgenutzt hat; (c) der Kernel "fix clang-issue"-Patches ablehnt, wenn sie keine Bugs fixen oder die Performance mit GCC sinkt. cppbert3 schrieb: > Nur damit auch du es peilst: MaWin ist Pro Rust UND Pro Linux/Linus :) Ich bin nicht doof. MaWin ist einfach nur der bessere Troll. :( cppbert3 schrieb: >> Der Kernel hat aber auch nie behauptet, in C geschrieben zu sein. >> Und er wird sicher auch nie behaupten, in Rust geschrieben zu sein. >> Aus den gleichen Gründen. > > Und mit diese Microrelevanzaussage konter ich jetzt wie? Warum willst du da kontern? Linux ist schlicht nicht in C geschrieben, sondern in (einem Subset von) GCC-C. Portabilität und Compilerabhängigkeit sind schlicht irrelevant. Clang implementiert auch GCC-C (identifiziert sich auch als GNU-C), weil Google (und andere) dafür gesorgt haben. Deswegen ist es trotzdem kein C, aber in der Lage, den Kernel zu bauen. Ich sehe keinen Grund, warum der Kernel das Thema Rust irgendwie anders handhaben sollte. Der Rust-Code im Kernel wird kein echtes Rust sein, sondern schlicht GCC-Rust (oder Kernel-Rust oder wie man das nennen mag). Inwieweit die auseinander laufen oder sogar inkompatibel zueinander werden, werden wir in der Zukunft sehen. Jörg W. schrieb: > Interessanterweise schien bei FreeBSD der Aufwand doch recht > überschaubar. Bei denen ist nun schon seit einigen Jahren Clang als > Standard dabei – und ein Kernel hat logischerweise auch dort 'ne ganze > Reihe von Compiler-Erweiterungen benutzt. FreeBSD (wie auch die Geschwister) hat ein eigenes Interesse, von GPL-Abhängigkeiten wegzukommen, nicht zuletzt durch Apple. Viel habe ich nicht in BSD-Code geblättert, aber was ich gesehen habe, hat mir im Allgemeinen recht gut gefallen und sah auch stärker nach Standard-C aus als der Linux-Code. Entsprechend dürfte die Abhängigkeit auch schwächer (besser abstrahiert) gewesen sein.
S. R. schrieb: > FreeBSD (wie auch die Geschwister) hat ein eigenes Interesse, von > GPL-Abhängigkeiten wegzukommen, nicht zuletzt durch Apple. Apple hat zwar mal den Anfang mit FreeBSD gemacht, aber macht seither sein eigenes Ding. Insofern ist FreeBSD (und insbesondere dessen verwendeter Compiler) für sie kaum relevant. Kommt hinzu, dass der Kernel eh Mach ist und kein BSD. > Viel habe ich nicht in BSD-Code geblättert, aber was ich gesehen habe, > hat mir im Allgemeinen recht gut gefallen und sah auch stärker nach > Standard-C aus als der Linux-Code. Entsprechend dürfte die Abhängigkeit > auch schwächer (besser abstrahiert) gewesen sein. Das ist gut möglich, hat durchaus auch historische Gründe. BSD wollte schon immer portabel sein (und NetBSD ist daraus entstanden, weil Bill Jolitz teilweise auf Portabilität verzichtet hatte, um auf der von ihm anvisierten 80386-Plattform besser/schneller voran zu kommen), der Code war damit auch vor 30 Jahren schon sehr generisch. Linux war erstmal nur 80386, und hat sich von da aus zu einem portablen System entwickelt. (Als ich vor Jahrzehnten mal in deren Floppytreiber geschaut habe, war beispielsweise sowas wie der DMA-Kanal fix per #define reincompiliert. In einem 386BSD hätte man auch damals schon mehr als einen Floppycontroller mit verschiedenen Hardwareparametern installieren können.)
Cyblord -. schrieb: > Die Komplexität in der SW Entwicklung entsteht nicht durch die > Programmiersprache. Die Sprache hat sogar entscheidenden Einfluss. Und weil die sprachbedingte Komplexität über die Jahrzehnte so ausartet wird kaum eine der genannten Sprachen richtig Zukunft haben. Die gehört schlicht anderer Hardware inklusive intelligenterer Programmierformen- um hier mal KI ins Gedächtnis zu rufen.
:
Bearbeitet durch User
Ron T. schrieb: > um hier mal KI ins Gedächtnis zu rufen. KI als Lösung zur Komplexitätsreduktion. Wow. Echt gut getrollt.
Steam macht einen echt netten Service für Skyrim. Die installierten Mods werden immer wieder "automagisch" auf den neuesten Stand gebracht. Diese Mods haben aber immer bestimmte eigene Probleme, da kann Steam nicht viel machen. Man ist gut beraten, jedes einzelne Mod für sich auszuprobieren, um fatale Veränderungen wirklich mitzubekommen. Viele bevorzugen aber ein 300 Mod Setup zum Start - aus welchem Grund auch immer - denn die "Vanilla" Version, also Skyrim ohne Mods ist schon toll. Mit vielen Mods als Standard kann man erstmal nicht so gut sehen, wenn man Probleme hat, wo sie herkommen. Dann gibt es noch in der normalen Vanillaversion gewisse Probleme, aber man kann einiges mit dem Creation Kit und den Glitches abfangen bzw. ausbügeln, und natürlich mit der ein oder anderen Modifikation. Klar, man hätte sich noch ein paar Runden Qualitätssicherungen gefreut - Aber das ist halt irgendwie auch die Handschrift von Bethesda, dass die Dinge so sind wie sie sind. Die Rust Entstehung ist interessant. Gehässigerweise könnte man fragen, ein neuer Lisp-Dialekt? Früher gab es mal f2c. Heute dann c2r? Fortran hat seine Stärken in der mathematischen Performance. C ist Systemnäher, Basic, die kleine Schwester von Fortran, war weniger systemnah, dafür aber fast überall verfügbar und man konnte es für viele Dinge einsetzen. Python ist gewissermaßen in die Fußstapfen von Basic getreten. Rein von der Werkzeug-Betrachtung her scheint Rust echt gut zu sein. Programmierkulturtechnisch: schwierige funktionale Programmierung. Es gibt auch die "Lösung" "Funktionalität" in C++ zu importieren. Stichwort: funktionale C++ Programmierung. Wenn man auf die 60er Jahre schaut, dann eierte die Funktionale Programmierung/Lisp und ähnliche immer so mit, spielten aber - auch bei der Parallelisierung - meist nur die 2. oder 3. Geige - oder noch weiter hinten. Das ist bei Rust ein wenig anders. Mit z.B. Haskell einen Compiler zu entwickeln - das ist eine wirklich sehr gute Möglichkeit, sowas zu tun. Nicht dumm.. Nach hinten raus steht immer noch die Frage im Raum, lieber in C++ machen, oder nicht? Ich denke, man sollte beides können. Grundsätzlich doof ist, wenn die funktionalen Hintergründe nicht verstanden werden. Es ist halt eine Übungssache. Und deswegen mag ich Haskell, obwohl es da z.B. mit dem ghc oder dem Drumherum (mal so mal so - wie denn jetzt?) oder der fehlenden Hardwarenähe auch recht problematisch zugeht. Beim Lernen stört das aber erstmal nicht so. Rust ist der pragmatische Ansatz. https://mariusschulz.com/blog/fast-searching-with-ripgrep
Auch wenn ich nicht ganz schlau draus werde was du mit dem Post sagen möchtest, ist er trotzdem irgendwie positiv Die starken Funktionalen Bezüge in deinem Post kann ich nicht zuordnen den Rust ist wie C, C++ und viele andere eine imperative Programmiersprache ohne Funktionale Basis
Hallo, cppbert3 schrieb: > ... den Rust ist wie C, C++ und viele andere eine imperative > Programmiersprache ohne Funktionale Basis Wie ist dann in https://de.wikipedia.org/wiki/Rust_(Programmiersprache) das Programmierbespiel zur Berechnung der Fakultät zu verstehen? Zitat: "Alternativ erlaubt es Rust, das Problem im Sinne der funktionalen Programmierung anzugehen. Sogenannte Iterators bieten eine Möglichkeit, iterierbare Objekte zu verarbeiten. So lässt sich die Fakultät mit Hilfe des Iterators (1..=i) und dessen Methode product()[31] wie folgt darstellen..." rhf
rbx schrieb: > Python ist gewissermaßen in die Fußstapfen von Basic getreten. Naja, meine These lautet: Der Erfolg von Python wird überbewertet. Python ist heute nur wegen Numpy und dem ganzen KI-Kram so populär. Und Numpy entstand weil in den 1990er Mathworks mit ihrer Lizenzpolitik zu Matlab durchdrehte. Zusätzlich kam später IPython aka Jupyter dazu. Damit verfestigte sich Python im akademischen Sektor, einer Nische. Da aus der akademischen Welt auch die Entwicklung KI und Maschinelearning getrieben wurde, wurde natürlich das dort benutzte Python als Scriptsprache dafür verwendet. Denn genau das ist Python nämlich: Eine Script-Sprache für Numpy und die ganzen Maschinelearning-Plattformen. Kaum einer wählt Python als Sprache für ein Projekt der Sprache selbst wegen, sondern weil er eben Numpy oder ein Maschinelearning-Paket benutzen will. Und die allermeisten Scripte die in diesem Bereich mit Python gebastelt werden, haben nur ein paar hundert Zeilen oder niedrige vierstellige Anzahl von Zeilen. Python ist der Nachfolger von Perl: Plattform für Wegwerf-Programme. Egal. Zurück zu Rust: rbx schrieb: > Programmierkulturtechnisch: schwierige funktionale Programmierung. Naja, die Masse muss erst funktionale Programmierung verinnerlichen. Bei OO war das nicht anders. Das hat auch Jahrzehnte gedauert, bis die "Hardcore-Imperativisten" in der Minderheit waren. Aber OO hat seinen Zenit weit überschritten. Natürlich hat OO ein Riesenmomentum, weil in der Zwischenzeit der Softwaresektor explodiert ist. Wenn man sich aber anschaut, wie die vielen Neulinge witzigerweise über Javascript mit funktionalen Paradigmen "infiziert" werden, und welchen Boom Haskell vor ca. 15 Jahren erfuhr, und wie dieser Boom z.B. C++ und andere Sprachen, darunter sicherlich auch Rust, danach beeinflusst hat, hat der Siegeszug der Funktionalen Paradigmen schon längst begonnen. Haskell ist toll, aber teilweise doch ziemlich akademisch und letztendlich für die Massenanwendung zu heftig. Und genau da breitet sich Rust nun aus. Rust ist (etwas) anspruchsvoller als viele aktuelle Massensprachen, aber ein merkliches Stück einfacher als z.B. Haskell. Das ist glaub ein gute Mischung. Irgendwo habe ich mal gelesen: Rust sei das Haskell für die Praxis, oder so ähnlich. Dem stimme ich zu 100% zu. Rust ist durch und durch eine imperative Sprache, allerdings lassen sich funktionale Konzepte und Paradigmen sehr gut damit verwenden bzw. umsetzen, weil es u.a. auch Summen-Datentypen hat. Fehlende Summen-Datentypen halte ich für das größte Manko vieler Sprachen. (Und es wird ja in immer mehr Sprachen versucht, das irgendwie nachträglich reinzubasteln. Selbst Python versucht es inzwischen irgendwie mit seinem Structural Pattern Matching.) Dazu, finde ich, ist bei Rust die Standardbibliothek außerordentlich gut gelungen. Ob es nun einen Standard in einer vergleichbaren Form zu einem beliebigen anderen Sprachstandard gibt, ist meiner Meinung nach nebensächlich. Es gibt immer verschiedene Anwendungsgruppen von Software-Technologie. Es gibt Gruppen die nehmen neue Entwicklungen sehr früh auf und setzen sie produktiv und gewinnbringend ein, und andere Gruppen warten, bis es für jeden Furz der Technologie 100 Seiten ISO-Spezifikation gibt. Diese Gruppen hinken immer Jahrzehnte der Entwicklung hinterher. Sie sind aber auch kein Innovatoren und für Entwicklungen in der Software-Branche völlig bedeutungslos.
Programmierer schrieb: > Python ist heute nur wegen Numpy und dem ganzen KI-Kram so populär. Das hat sicher auch meiner Meinung nach massiv dazu beigetragen. Aber ganz unabhängig davon ist natürlich der Interpreter, in dem man schnell mal einen Konstrukt eines größeren Scripts "vortesten" kann, ein sehr praktisches Hilfsmittel. Auch bei uns in der Industrie ist daher Python jenseits der Firmware ziemlich häufig im Einsatz. (Matlab sicher auch, aber mehr im tatsächlichen Mathematik-Umfeld.) C, C#, C++, Java, Rust :) macht an der Stelle keiner.
Rust erlaubt genau so wie C++ Funktional-artige Programmierung, aber Haskell ist Kilometer von Funktional-"artig" weg - Haskell ist vollwertig Funktional der Vergleich Rust und Haskell macht keinen Sinn - aber scheinbar gibt es hier welche die da eine Ähnlichkeit sehen, es ist aber trotzdem eine ganz andere Art der Programmierung, deswegen die nicht so hohe durchdringung des Marktes
Programmierer schrieb: > Damit verfestigte sich Python im akademischen Sektor, einer Nische. Einer Nische? Interessant. Programmierer schrieb: > Denn genau das ist Python nämlich: Eine Script-Sprache für Numpy und die > ganzen Maschinelearning-Plattformen. Kaum einer wählt Python als Sprache > für ein Projekt der Sprache selbst wegen, sondern weil er eben Numpy > oder ein Maschinelearning-Paket benutzen will. Und die allermeisten > Scripte die in diesem Bereich mit Python gebastelt werden, haben nur ein > paar hundert Zeilen oder niedrige vierstellige Anzahl von Zeilen. Worauf basiert diese Einschätzung? Ich kenne niemanden, der (nur) wegen numpy zu Python gewechselt ist. numpy hat nicht viele Vorteile gegenüber Fortran und vermutlich genauso viele Nachteile. Das deutlich wichtigere Python Projekt ist matplotlib.
Mombert H. schrieb: > numpy hat nicht viele Vorteile gegenüber Fortran Der wesentliche Vorteil ist, dass man als Frontend zum alten FORTRAN-Kram eine benutzbare Programmiersprache bekommt, die man auch im 21. Jahrhundert einigermaßen verstehen kann. ;-) Ich denke, das ist genau der Punkt an dieser Stelle, und letztlich auch der, womit Matlab gepunktet hat (zumindest im Ursprung, mittlerweile eher mit Toolboxes für jede Lebenslage).
Mombert H. schrieb: > Programmierer schrieb: >> Damit verfestigte sich Python im akademischen Sektor, einer Nische. > Einer Nische? Interessant. Off-Topic-Alarm: Es geht hier um Rust, bleibt dabei
cppbert schrieb: > Es geht hier um Rust, bleibt dabei Gibt's denn ein Eispack/Linpack-Frontend in Rust?
Jörg W. schrieb: > Gibt's denn ein Eispack/Linpack-Frontend in Rust? Keine Ahnung. Das ist überhaupt nicht das Einsatzgebiet von Rust. Nimm Python. Rust ist eine Systems Programming Language.
Jörg W. schrieb: > cppbert schrieb: >> Es geht hier um Rust, bleibt dabei > > Gibt's denn ein Eispack/Linpack-Frontend in Rust? ich kenne nur https://nalgebra.org/ mit Lapack Bindings - keine Ahnung ob das was taucht
MaWin schrieb: > Keine Ahnung. > Das ist überhaupt nicht das Einsatzgebiet von Rust. > Nimm Python. > > Rust ist eine Systems Programming Language. Das würde ich jetzt nicht einfach so sage - warum sollte Rust dafür ungeeignet sein - als Sprache?
cppbert schrieb: > Das würde ich jetzt nicht einfach so sage - warum sollte Rust dafür > ungeeignet sein - als Sprache? Es ist nicht ungeeignet. Aber es gibt geeignetere Sprachen. Nicht alles, was möglich ist, ist auch sinnvoll. Rust hat ein sehr strenges und komplex zu bedienendes Typsystem. Ein Großteil des Entwicklungsaufwands bei Rust-Programmen fließt in das Design der Datentypen, Methoden und Traits. All dies muss zusammenspielen, sonst kommt man insbesondere bei Rust in Teufels Küche. Hacks, die das Typsystem hintergehen, sind in Rust nicht ohne weiteres (= unsafe Rust) möglich. Einfach mal mit einem Pointer um sich werfen, wie man es aus C++ kennt, kann man in Rust nicht. Und das ist gut so. Wenn ich mathematische Probleme löse, dann will ich eines ganz gewiss nicht: Mich mit dem Typsystem herumschlagen. Das ist der Einsatz, wo Sprachen wie Python (+ Numpy) groß sind.
Jörg W. schrieb: > Mombert H. schrieb: >> numpy hat nicht viele Vorteile gegenüber Fortran > Der wesentliche Vorteil ist, dass man als Frontend zum alten > FORTRAN-Kram eine benutzbare Programmiersprache bekommt, die man auch im > 21. Jahrhundert einigermaßen verstehen kann. ;-) Ich bin mir nicht sicher, wie genau du das meinst. Aber: - Niemand der im Jahre 20XX "altes FORTRAN" schreibt, wechselt zu Python und schreibt dort Python. Das wird im besten Fall PYTRAN77. - Python hat genügend Fallstricke und unschöne Ecken. Da muss sich modernes Fortran nicht verstecken, wenn es ums numbercrunshen geht. - Wenn z.B. numpy nicht bietet was man braucht muss man am Ende trotzdem C oder Fortran einsetzen + den ganzen Interface-Hokuspokus (dazu aus der aktuellen numpy-Doku:
1 | The default build system for F2PY has traditionally been the through the enhanced numpy.distutils module. This module is based on distutils which will be removed in Python 3.12.0 in October 2023; setuptools does not have support for Fortran or F2PY and it is unclear if it will be supported in the future. Alternative methods are thus increasingly more important. |
- Ich stoppe besser hier, bevor ich stundenlang die Vor- und Nachteile von Python, Fotran und C++ beim Lösen von numerischen Problemen aufliste. MaWin bekommt bestimmt schon einen hochroten Kopf, weil ich bis jetzt kein rust erwähnt habe. > Ich denke, das ist genau der Punkt an dieser Stelle, und letztlich auch > der, womit Matlab gepunktet hat (zumindest im Ursprung, mittlerweile > eher mit Toolboxes für jede Lebenslage). Python hat viele Pluspunkte. Einer der wichtigsten Punkte ist, dass Fortran eine Sackgasse ist. Wenn man seinen Abschluss hat, kann man in 95% der Fälle sein Fortran-Wissen direkt vergessen, weil man es nie wieder benutzen wird. Es ist Fachwissen und kein Werkzeug.
MaWin schrieb: > Das ist der Einsatz, wo Sprachen wie Python (+ Numpy) groß sind. Allerdings eben als interpretierte Sprache zwar schnell im Design, u.U. aber doch mit Geschwindigkeitseinbußen in der Ausführung. Wenn man große Datenmengen numerisch behandeln muss, kann es also sinnvoll sein, einen Python-Prototypen später in was anderem nachzuschreiben. Ich habe auch schon Python-Prototypen in C nachgeschrieben, für ARM-MCU, im Zusammenhang mit der ARM DSP Library. Insofern kann so eine Betrachtung nicht ganz unsinnig sein, die Portierung eines Prototypen von Python nach Rust zu machen. Die Typisierung musste ich übrigens auch in C abhandeln, nur "mit einem Pointer herum zu werfen" löst ja an sich erstmal noch kein Problem.
MaWin schrieb: > Einfach mal mit einem Pointer um sich werfen, > wie man es aus C++ kennt, kann man in Rust nicht. Und das ist gut so. Da sind wir wieder bei FORTRAN vs. Fortran, wenn das deine C++ Sicht ist ;-). MaWin schrieb: > Wenn ich mathematische Probleme löse, dann will ich eines ganz gewiss > nicht: Mich mit dem Typsystem herumschlagen. > Das ist der Einsatz, wo Sprachen wie Python (+ Numpy) groß sind. Gut, dass das nicht alle so sehen :-)
Jörg W. schrieb: >> Das ist der Einsatz, wo Sprachen wie Python (+ Numpy) groß sind. > > Allerdings eben als interpretierte Sprache zwar schnell im Design, u.U. > aber doch mit Geschwindigkeitseinbußen in der Ausführung. Wenn der interpretierte Teil eines Python+Numpy-Programms ein Problem wird, dann machst du in 99% der Fälle etwas sehr sehr falsches. > Wenn man große > Datenmengen numerisch behandeln muss, kann es also sinnvoll sein, einen > Python-Prototypen später in was anderem nachzuschreiben. Kann vorkommen. Aber sehr selten. Dann meinetwegen auch in Rust. Aber nicht von vorne herein schon. Jörg W. schrieb: > Die Typisierung musste ich übrigens auch in C abhandeln Die Rust-Typisierung mit C-Typisierung zu vergleichen ist schon etwas ulkig. Das Rust Typsystem verhält sich zum C Typsystem wie ein Daimler zu einem Tretroller.
MaWin schrieb: > Die Rust-Typisierung mit C-Typisierung zu vergleichen ist schon etwas > ulkig. Kann sein, aber möglicherweise kennst du auch bloß schlechtes C.
MaWin schrieb: > Das Rust Typsystem verhält sich zum C Typsystem wie ein Daimler zu einem > Tretroller. Also C ist ein Kinderspielzeug oder energiesparendes Kurzstreckenfahrzeug und rust eine Protzkarre?
Jörg W. schrieb: >> Die Rust-Typisierung mit C-Typisierung zu vergleichen ist schon etwas >> ulkig. > > Kann sein, aber möglicherweise kennst du auch bloß schlechtes C. Hä? Ich spreche von der Sprache C, die im ISO-Standard definiert ist. Ich denke nicht, dass die schlecht oder gut ist. Sie ist, wie sie ist. Das Typsystem der Sprache C ist überhaupt nicht direkt vergleichbar mit Rust. Das Rust-Typsystem ist von der Komplexität her etwa in der Liga des C++-Typsystems, um für dich einen Vergleich zu schaffen, den du eventuell nachvollziehen kannst. Aber auch dieser Vergleich ist eigentlich nicht zutreffend wegen der ganzen C-Altlasten in C++. Und weil Rust Features hat, die es in C++ gar nicht gibt. Das Konzept von Lifetimes gibt es weder in C, noch in C++. Wenn man ein Rust-Programm schreibt, ist man aber gezwungen sich mit Lifetimes (und allen anderen Eigenschaften des komplexen Typsystems) auseinanderzusetzen. Und das ist eben der Punkt. Wenn ich ein mathematisches Problem lösen möchte, dann stehen mir diese Dinge erst einmal im Weg. Wenn das Problem dann gelöst und verstanden ist, dann kann ich immer noch darüber nachdenken, ob es sinnvoll ist, das Programm in einer Sprache wie Rust neu zu schreiben. Bei Verwendung von einfachen Sprachen wie Python bleibt mehr Hirnkapazität für das zu lösende Problem über. Mit dem Nachteil, dass mehr Programmierfehler erst (sehr viel) später auffallen. Teilweise erst nach der Auslieferung des Programms. Es ist ein Abwägen von Prioritäten. Es ist erklärtes Ziel der Rust-Entwickler den Entwicklungsprozess eines Rust-Programms deutlich zu vereinfachen. Und das ist auch gut und notwendig. Aber dort sind wir leider noch nicht am Ziel angekommen. Und ich sehe nicht, wie wir jemals an die Entwicklungsperformance von Python auch nur im Ansatz anknüpfen können. Aber das ist eigentlich auch nicht notwendig. Jede Sprache für seinen Zweck.
MaWin schrieb: > Es ist nicht ungeeignet. > Aber es gibt geeignetere Sprachen. > Nicht alles, was möglich ist, ist auch sinnvoll. ich arbeite an einem Projekt das locker 500.000 Lines nur Mathecode beinhaltet um Maschinen zu steuern, teilweise nearly Echtzeit - da will ich kein Python, ist in diesem Projekt alles mit C++ realisiert Es kommt eben drauf an
MaWin schrieb: > Das Konzept von Lifetimes gibt es weder in C, noch in C++. Meinst du damit ein definierte Lifetime von Objekten oder die *rustc Lifetimes*™?
MaWin schrieb: > Das Typsystem der Sprache C ist überhaupt nicht direkt vergleichbar mit > Rust. Habe ich auch nicht behauptet. Aber C ist auch nicht bloß "mal einen Pointer herumwerfen", wie du das darstellst. Zumindest nicht, wenn man es ordentlich macht. Dass bei letzterem Rust einen deutlichen Vorteil hat (die Bedingung "wenn man es ordentlich macht" kann man dort nicht umgehen), ist unbestritten. Und klar, Python oder Matlab sind da pragmatischer, in der Beziehung halt wirklich eher wie BASIC.
Jörg W. schrieb: > Aber C ist auch nicht bloß "mal einen Pointer herumwerfen", wie du das > darstellst. Zumindest nicht, wenn man es ordentlich macht. du bist immer noch ein wenig zu kritisch - mitlerweile sollte dir klar sein das MaWin ein nicht ganz unbeschriebenes Blatt ist, sich auskennt und manchmal ein wenig überspitzt schreibt
Ich habe nur manchmal die Befürchtung, dass er von ein paar schlechten C-Programmierern auf die Qualität aller C-Programme schließt. Logischerweise hat natürlich Rust von Problemen existierender Sprachen gelernt, wofür sonst hätte es überhaupt einer neuen Programmiersprache bedurft?
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Ich habe nur manchmal die Befürchtung, dass er von ein paar schlechten > C-Programmierern auf die Qualität aller C-Programme schließt. Die "paar" schlechten C-Programmierer. Da sind sie wieder. Wenn man ein C-Programm richtig schreibt, ist es auch ein korrektes Programm. Ich stimme dir vollkommen zu. Aber du hast es ja bereits selbst erkannt, worum es Rust geht: Jörg W. schrieb: > Dass bei letzterem Rust einen deutlichen Vorteil hat (die Bedingung > "wenn man es ordentlich macht" kann man dort nicht umgehen), ist > unbestritten. Und das zwingt den Programmierer halt Hirnressourcen dafür aufzuwenden, die dann natürlich nicht anderweitig zur Verfügung stehen. In vielen Fällen mag der zusätzliche Aufwand gerechtfertigt sein. In vielen aber auch nicht. Das muss man abwägen. Rust ist kein Allheilmittel. Aber es ist eben auch ein mächtiges Werkzeug, das viele C/C++-Programme ablösen kann und sollte. Mombert H. schrieb: > Meinst du damit ein definierte Lifetime von Objekten oder die *rustc > Lifetimes*™? Mombert, dir antworte ich übrigens nicht mehr, falls du es noch nicht gemerkt hast. Befasse sich bitte erst einmal mit den Grundlagen von Rust. Und höre auf zu trollen.
Mombert H. schrieb: > MaWin schrieb: >> Das Konzept von Lifetimes gibt es weder in C, noch in C++. > Meinst du damit ein definierte Lifetime von Objekten oder die *rustc > Lifetimes*™? allen hier ist klar was Stack Objekte und RAII etc. ist - darum ging es nicht - Lifetime ist bei Rust eine Eigenschaft des Typ-Systems eben nicht nur Heap oder Scope
cppbert schrieb: > du bist immer noch ein wenig zu kritisch - mitlerweile sollte dir klar > sein das MaWin ein nicht ganz unbeschriebenes Blatt ist, sich auskennt > und manchmal ein wenig überspitzt schreibt Hier geht es aber eigentlich um Daniel und die Frage, ob die kognitive Dissonanz-Bearbeitung berechtigt ist, oder nicht. Ich bin mir nicht sicher. Auf der anderen Seite werden Programmiersprachen tatsächlich oft überbewertet. Know How, Algorithmen, Motivation sind auch sehr wichtig. Ohne Motivation geht nix. Warum stellt Daniel die Frage, ob Rust bleibt? Möchte er Kernelhacker werden? Vor dem Hintergrund der Multicore Nutzung steht Rust ganz gut da. Aber ich glaube nicht, dass eine Diskussion sehr weit führt. Es ist vielleicht hilfreicher, seine Lieblingsprogramme nach Rust zu übersetzen, und dann zu schauen, was man selber davon hat. Sinnvollerweise aber möglichst da, wo Rust seine Stärken hat.
rbx schrieb: > Warum stellt Daniel die Frage, ob Rust bleibt? Möchte er Kernelhacker > werden? welcher Daniel? hat er die Frage aufgemacht? Dieser Post hier ist eher so eine Sammlung an Rust Diskussionen die alle paar Monate mal wieder aufflammen, weiter betrieben von anderen
Jörg W. schrieb: > Ich habe nur manchmal die Befürchtung, dass er von ein paar schlechten > C-Programmierern auf die Qualität aller C-Programme schließt. eigentlich bist du es der immer wieder davon ausgeht das er keinen oder einen schlechten Überblick hat und dann in Detail-Diskussionen verfällt weil du ihn (löblicherweise) belehren willst - aber das ist so gut wie nie wirklich nötig leider schließen sich dann auch recht schnell viele anderen an und alle Antworten driften total in die Off-Topic Richtung - immer und immer wieder aber jetzt gerade ist deine Argumentation fein - Sternchen für dich :)
Ich bin wirklich sehr gespannt wann Rust im Linux-Kernel aktiv wird - also dem Protoypen-Status entwächst und auch von vielen anderen Linux-Entwicklern begutachtet wird (ich weiss das nicht jeder an allem arbeitet) weiss jemand ob das Asynchron-Konzept im Kernel (natürlich mit Kernel-Backend) Anwendung finden wird oder ist das ein zu "komplexes" Konzept für die Kernel-Ebene?
Jörg W. schrieb: > MaWin schrieb: >> Das ist der Einsatz, wo Sprachen wie Python (+ Numpy) groß sind. > > Allerdings eben als interpretierte Sprache zwar schnell im Design, u.U. > aber doch mit Geschwindigkeitseinbußen in der Ausführung. Wenn man große > Datenmengen numerisch behandeln muss, kann es also sinnvoll sein, einen > Python-Prototypen später in was anderem nachzuschreiben. Tatsächlich sind große Teile von numpy, scipy & Co. in nativen Sprachen wie C, C++ und Fortran implementiert. Performance ist daher in der Regel kein Thema, dessentwegen man Python-Prototypen in anderen Sprachen reimplementieren müßte. Auch Python selbst ist schneller als sein Ruf. Für ein Projekt habe ich mal einen Bag-of-Words-Algorithmus mit Boost::Python entwickelt, der sich am Ende als viel langsamer herausgestellt hat als die native Python-Implementierung.
:
Bearbeitet durch User
cppbert schrieb: > MaWin schrieb: >> Es ist nicht ungeeignet. >> Aber es gibt geeignetere Sprachen. >> Nicht alles, was möglich ist, ist auch sinnvoll. > > ich arbeite an einem Projekt das locker 500.000 Lines nur Mathecode > beinhaltet um Maschinen zu steuern, teilweise nearly Echtzeit - da will > ich kein Python, ist in diesem Projekt alles mit C++ realisiert 500 kLOC Mathcode hören sich zunächst nach viel an, bis man feststellt, in welcher Sprache sie geschrieben sind... ;-) Nein, im Ernst: auch Python läßt sich in nativen Code kompilieren, vor allem Mathcode (think numba). Zudem gibt es andere Interpreter wie Pypy mit JIT-Compiler, die in vielen Anwendungsfällen viel schneller sind als die Referenzimplementierung.
Ein T. schrieb: > Tatsächlich sind große Teile von numpy, scipy & Co. in nativen Sprachen > wie C, C++ und Fortran implementiert. Performance ist daher in der Regel > kein Thema, dessentwegen man Python-Prototypen in anderen Sprachen > reimplementieren müßte. wie gesagt es gibt die richtigen Gründe es zu tun und es nicht zu tun, kommt absolut auf das Projekt und die Umgebung des Projektes an - in meinen Hochlast und Resourcen-Beschränkten Projekten geht es einfach nicht in anderen schon > Auch Python selbst ist schneller als sein Ruf. Für ein Projekt habe ich > mal einen Bag-of-Words-Algorithmus mit Boost::Python entwickelt, der > sich am Ende als viel langsamer herausgestellt hat als die native > Python-Implementierung. was jetzt in keinster Weise bedeutet das native Python schnell ist - es kann so viele Gründe geben warum das bei dir so war das es als Argument schwerlich dienen kann
Vergleichen wir doch mal Rust mit C. Rust - Eisenoxid - Fe₂O₃ Eigentlich nur für 2 Sachen gut: Eisenherstellung / zutat in Thermit, und als Braunrotes Farbpigment. Meistens bereitet es aber Probleme. Eisen rostet, und wird brüchig. Rostige schrauben lassen sich nicht rein / raus drehen. Und wenn rostige Sachen im regen steht, färbt es alles darum rum Rot ein. Es gibt auch nichts wichtiges, was man aus Rost selbst herstellen würde, nur der Eisenanteil ist interessant. Normalerweise versucht man, zu verhindern, dass dinge Rosten. Wir haben Stahl erfunden, Rostschutzmittel, Lacke, etc. um dem Rost Herr zu werden. Aber ganz vernichten konnten wir ihn nie. Es gibt immer noch Dinge, die vor sich hin rosten, und so schnell ändert sich daran auch nichts... Rust - ist das hier um zu bleiben? Ja, sieht leider so aus. C - Kohlenstoff Unglaublich nützlich. Plastik und Polymere brauchen Kohlenstoff. Pythons, Menschen, etc. sind Kohlenstoffbasierte Lebewesen. Jegliche organische Chemie basiert auf Kohlenstoff. Kohlenstoff ist auch geeignet als Schmiermittel. Es kann für Transistoren verwendet werden. Und als Nono Röhrchen kann man damit extrem stabile Fäden herstellen. Und es ist auch beliebt zum Schreiben, in Bleistiften. In der Forschung und als schmuck ist es auch begehrt, als Diamanten. Es gibt sicher noch weitere Anwendungsgebiete. Ein wahrere Alleskönner. C ist also klar besser als Rust.
Ob Python schnell ist, kommt auch auf die Perspektive an. Python wurde schnell zu Hackers Liebling, nicht etwa eine der funktionalen Sprachen. Inwieweit ein Setup schnell ist, etwa für Statistikübersichten, Data-Mining Zeugs, Visualisierung für dies und das, ist vielleicht nochmal eine andere Frage. Aber bestimmt keine unwichtige. Ein Setup für Mikrocontroller vor allem bei Parallelprogrammierung wäre interessant, oder eben auch ein Setup für Spiele auf Linux, welche die Parallelität ausnutzen. Bei Spielen spielen aber auch Skriptsprachen eine Rolle, Lua oder Javascript z.B. Dann gibt es noch verschiedenen "Engines" z.B. für Physik, das muss man auch noch alles unter einen Hut bekommen. Und ja, die Gameengines selber sind aus mehrererlei Hinsicht überholungsbedürftig. Rust ist diesbezüglich eine große Chance. Im Weg steht das Umdenken. Mombert H. schrieb: > - Niemand der im Jahre 20XX "altes FORTRAN" schreibt, wechselt zu Python > und schreibt dort Python. Das wird im besten Fall PYTRAN77. Ziemlich guter Einwand.
DPA schrieb: > C ist also klar besser als Rust. Die erste gute Erklärung warum C wirklich besser ist :) Danke
rbx schrieb: > Ein Setup für Mikrocontroller vor allem bei Parallelprogrammierung wäre > interessant, oder eben auch ein Setup für Spiele auf Linux, welche die > Parallelität ausnutzen. > Bei Spielen spielen aber auch Skriptsprachen eine Rolle, Lua oder > Javascript z.B. > Dann gibt es noch verschiedenen "Engines" z.B. für Physik, das muss man > auch noch alles unter einen Hut bekommen. > Und ja, die Gameengines selber sind aus mehrererlei Hinsicht > überholungsbedürftig. das klingt wie eine Wunschlisten, Hoffnungssammlung ohne richtigen Hintergrund Rust kann das ganze vielleicht ein wenig homogenisieren und natürlich stark seine Stärken in Sicherer-Programmierung ausspielen - aber dadurch wird sonst nichts wirklich einfacher, ein ~8Mio Lines of Code pure Unreal Engine oder mindestens 10-20Mio Zeilen Code von GTA5 werden damit auch nicht magisch viel weniger oder einfacher - auch Projekt-Teams mit mehr als 100 Entwickler sind nicht ständig am Dependencies Resolven sondern kümmern sich mehr oder minder nur um den Game-Code, was absolut nicht bedeuten soll das Rust nicht super viel helfen kann - aber deine Auflistung ist trotzdem komisch oder was meinst du?
DPA schrieb: > Rust - Eisenoxid - Fe₂O₃ > > Eigentlich nur für 2 Sachen gut: Eisenherstellung / zutat in Thermit, > und als Braunrotes Farbpigment. Der Nutzen scheint auch eher für Kenner zu sein, also Leute, die es wirklich wissen wollen: https://www.deutschlandfunknova.de/nachrichten/magnetische-nanopartikel-mit-smartem-rost-gegen-mikroplastik Die Geschichte ist aber auch schon alt, und so wohl mehr für interessante Nachrichten geeignet, als tatsächlich coole Hilfe für echte Nöte.
cppbert schrieb: > oder was meinst du? Hinsichtlich einer komischen hoffnungsverlorenen Perspektive ohne richtiges Hintergrundverständnis auf meinen Beitrag finde ich es bei einem so wackeligen Thema so wie hier ziemlich erbärmlich, auf der Persönlichkeitsebene herumzueiern. Von Idealisierung der Programmiersprache hatte ich auch nichts gesagt, sondern nur dass die funktionale Programmierung nicht gut verstanden wird, was ja verständlich ist, denn der Code ist fremdartig, und kaum einer ist damit aufgewachsen, oder hat Fachzeitschriften und Bücher gewälzt mit funktionalen Sprachen, um Sachen auszuprobieren. Das ist aber heute echt ein Problem. Mein Punkt ist, dass das bessere Verständnis der funktionalen Programmierung und auch das Verständnis von so Geschichten wie Rust nicht verkehrt ist. Alternativ könnte ich auch Werbung für Modula 3 machen - Für einen aktuelleren Blick über den Tellerrand ist Rust viel besser geeignet.
rbx schrieb: > cppbert schrieb: >> oder was meinst du? > Hinsichtlich einer komischen hoffnungsverlorenen Perspektive ohne > richtiges Hintergrundverständnis auf meinen Beitrag finde ich es bei > einem so wackeligen Thema so wie hier ziemlich erbärmlich, auf der > Persönlichkeitsebene herumzueiern. Bitte nicht so empfindlich sein (erbärmlich und Persönlichkeitsebene war hier gar nichs) dein Text von oben ist einfach maximal Interpretierungsfähig und die Kernaussage dahinter ist mir immer noch unklar, stört mich aber auch nicht rbx schrieb: > Von Idealisierung der Programmiersprache hatte ich auch nichts gesagt, > sondern nur dass die funktionale Programmierung nicht gut verstanden > wird, was ja verständlich ist, denn der Code ist fremdartig, und kaum > einer ist damit aufgewachsen, oder hat Fachzeitschriften und Bücher > gewälzt mit funktionalen Sprachen, um Sachen auszuprobieren. > Das ist aber heute echt ein Problem. vielleicht ist das mein Problem - warum gehst du auf das fehlende Verständnis für Funktionale Sprachen ein wenn es hier um die Imperative Sprache Rust geht?
> oder eben auch ein Setup für Spiele auf Linux, > welche die Parallelität ausnutzen. das ist eine Sache der Spiele-Implementierung - egal in welcher Sprache, wenn du keine Threads/Asyncs nutzt ist dein Multicore eben ungenutzt - da kann Rust oder jede andere Sprache nichts dran ändern - und es gibt doch einen Haufen gut skalierende Software für Linux, Spiele sind da nichts besonderes > Bei Spielen spielen aber auch Skriptsprachen eine Rolle, Lua oder > Javascript z.B. geht es dir um die Einfachheit der Integration? ... > Und ja, die Gameengines selber sind aus mehrererlei Hinsicht > überholungsbedürftig. in welcher Hinsicht?
cppbert schrieb: > das ist eine Sache der Spiele-Implementierung - egal in welcher Sprache, > wenn du keine Threads/Asyncs nutzt ist dein Multicore eben ungenutzt - > da kann Rust oder jede andere Sprache nichts dran ändern Das ist prinzipiell richtig. Rust macht die Nutzung von mehreren Kernen aber deutlich einfacher, als andere Sprachen. Und dazu noch garantiert frei von Data Races. Die Threading-Primitive ansich sind schon sehr einfach zu verwenden. Aber viele Crates bauen dort noch einfacherere APIs drum herum. Und Async-Rust lässt sich auch mit ein paar Handgriffen auf mehreren Kernen parallel rechnen. Das kenne ich so von keiner anderen Sprache. Deshalb denke ich schon, dass Rust an der Verbreitung der Multicorenutzung etwas ändert.
MaWin schrieb: > Rust macht die Nutzung von mehreren Kernen aber deutlich einfacher, als > andere Sprachen. Und dazu noch garantiert frei von Data Races. > Die Threading-Primitive ansich sind schon sehr einfach zu verwenden. > Aber viele Crates bauen dort noch einfacherere APIs drum herum. Da hast du definitiv recht, aber gute skaliebarkeit und "sinnvolle" Parallelität immer noch ein Herausforderung, obwohl bei Rust viele technische Probleme gar nicht mehr passieren können
cppbert schrieb: > rbx schrieb: >> Ein Setup für Mikrocontroller vor allem bei Parallelprogrammierung wäre >> interessant, oder eben auch ein Setup für Spiele auf Linux, welche die >> Parallelität ausnutzen. >> Bei Spielen spielen aber auch Skriptsprachen eine Rolle, Lua oder >> Javascript z.B. >> Dann gibt es noch verschiedenen "Engines" z.B. für Physik, das muss man >> auch noch alles unter einen Hut bekommen. >> Und ja, die Gameengines selber sind aus mehrererlei Hinsicht >> überholungsbedürftig. > > das klingt wie eine Wunschlisten, Hoffnungssammlung ohne richtigen > Hintergrund Für mich klingt das, hüstel, eher wie "ich habe eine Lösung und jetzt hätte ich bitte gerne ein Problem dafür".
Ein T. schrieb: > Für mich klingt das, hüstel, eher wie "ich habe eine Lösung und jetzt > hätte ich bitte gerne ein Problem dafür". Eine Parole die über vielen Innovationen und kreativen Einfällen moderner Sprachen stehen könnte.
Ron T. schrieb: > Ein T. schrieb: >> Für mich klingt das, hüstel, eher wie "ich habe eine Lösung und jetzt >> hätte ich bitte gerne ein Problem dafür". > > Eine Parole die über vielen Innovationen und kreativen Einfällen > moderner Sprachen stehen könnte. Ja, keine Frage. Ich mein', ja, ich find' Rust ja auch toll und finde es deswegen sehr schade, daß es sich vermutlich nicht durchsetzen wird.
Ein T. schrieb: > Ja, keine Frage. Ich mein', ja, ich find' Rust ja auch toll und finde es > deswegen sehr schade, daß es sich vermutlich nicht durchsetzen wird. Es gibt gab noch nie einen so ernsthaften Versuch eine bessere alternative zu C oder C++ zu erschaffen, ja, viele andere Programmiersprachen - aber keine Systemprogrammiersprachen das ist relativ einmalig, noch dazu ist es das erste mal in der Linux Geschichte das eine andere Sprache als C überhaupt diskutiert wird, das ist alles andere als nicht durchsetzen, was absolut nicht bedeutet das jeder ab morgen Rust macht, aber selbst wenn es noch 10 Jahre dauert wäre das Lichtgeschwindigkeit für eine Systemprogrammiersprache
cppbert3 schrieb: > aber selbst wenn es noch 10 Jahre dauert wäre das Lichtgeschwindigkeit und ich meine nicht bis jeder es nutzt und alle 300 Billionen Zeile C/C++ vollständig portiert sind, das ist schwachsinn sondern einen etablierteren Zustand In Systemprogrammierung oder tief embedded hat bisher gar nichts, nicht mal minimal am C/C++ Thron gekratzt, das es sich überhaupt lohnen würde es anzuschauen, unabhängig von Wille und Bock
cppbert3 schrieb: > noch dazu ist es das erste mal in der Linux Geschichte > das eine andere Sprache als C überhaupt diskutiert wird C++ wurde mehrfach kurz diskutiert und immer direkt abgeschmettert. Und außerdem ist die halbe Kernelfunktionalität ja heute in (e)BPF programmiert. ;) Ne ohne Spaß jetzt: Ich sehe das auch so, dass Rust der erste ernstzunehmende Versuch ist C direkt zu ergänzen und langfristig weitgehend zu ersetzen.
cppbert3 schrieb: > Ein T. schrieb: >> Ja, keine Frage. Ich mein', ja, ich find' Rust ja auch toll und finde es >> deswegen sehr schade, daß es sich vermutlich nicht durchsetzen wird. > > Es gibt gab noch nie einen so ernsthaften Versuch eine bessere > alternative zu C oder C++ zu erschaffen, Aber ja doch, die Sprachen der PASCAL-Familie. Die haben zwar immer noch viele Freunde, aber durchgesetzt... eher nicht, oder? > ja, viele andere > Programmiersprachen - aber keine Systemprogrammiersprachen das ist > relativ einmalig, noch dazu ist es das erste mal in der Linux Geschichte > das eine andere Sprache als C überhaupt diskutiert wird, das ist alles > andere als nicht durchsetzen, was absolut nicht bedeutet das jeder ab > morgen Rust macht, aber selbst wenn es noch 10 Jahre dauert wäre das > Lichtgeschwindigkeit für eine Systemprogrammiersprache Systementwicklung als solche ist ja schon eine Nische, und... ich wünschte, es wäre anders, aber jede neue Sprache steht heute immer zunallererst vor dem Problem, daß es eine existierende Infrastruktur gibt. Ja, ich weiß, man kann C in Rust einbinden, verliert dann aber einige seiner wesentlichen Vorzüge. Und wer mal erlebt hat, wie vehement sich manche gestandene und erfahrene Entwickler dagegen sträuben, ihre lieb gewonnene Sprache und ihre Erfahrungen aufzugeben, mithin: wie sehr auch Entwickler Menschen und damit Gewohnheitstiere sind... Jo, die Aufnahme in den Linux-Kernel ist eine Art Ritterschlag, wenngleich sie bis dato noch ein Versuch ist und ähnlich fehlschlagen könnte wie weiland der Versuch, C++ in den Linux-Kernel zu integrieren. Insofern heißt es erstmal abwarten, ob das erfolgreich sein wird -- aber selbst wenn es erfolgreich ist, ist die Entwicklung von Kernelkomponenten für Linux ja auch immer noch ein Nischending.
Ein T. schrieb: > Systementwicklung als solche ist ja schon eine Nische Es ist die Nische, die C heute besetzt. C ist aus allen anderen Bereichen bereits praktisch verdrängt worden. > Ja, ich weiß, man kann C in Rust einbinden, verliert dann aber > einige seiner wesentlichen Vorzüge. Man verliert nicht wirklich etwas. Was meinst du damit? > Und wer mal erlebt hat, wie vehement > sich manche gestandene und erfahrene Entwickler dagegen sträuben Ja. Das ist das Hauptproblem. > und ähnlich fehlschlagen > könnte wie weiland der Versuch, C++ in den Linux-Kernel zu integrieren. Linux-Rust ist deutlich weiter als jeder vorhergehende C++-Linux-Versuch. > aber > selbst wenn es erfolgreich ist, ist die Entwicklung von > Kernelkomponenten für Linux ja auch immer noch ein Nischending. Linux ist eine der Kernkomponenten, die die Welt am Laufen halten. Ich würde das jetzt nicht als Nische bezeichnen.
Ein T. schrieb: > Nischending. Man könnte auch sagen "gesucht" (nicht zufliegend..). Wie etwa bei der Cuda-Schnittstelle: https://github.com/Rust-GPU/Rust-CUDA
Beitrag #7132840 wurde von einem Moderator gelöscht.
rbx schrieb: > Ein T. schrieb: >> Nischending. > > Man könnte auch sagen "gesucht" (nicht zufliegend..). > > Wie etwa bei der Cuda-Schnittstelle: > https://github.com/Rust-GPU/Rust-CUDA ich verstehe nie so wirklich was du sagen willst - ist eine Rust-CUDA Wrapper jetzt nicht Nische, oder Nische?
Würde gern mal die Frage in den Raum stellen warum sich über das Thema so trefflich diskutieren lässt? Weil Programmiersprachen vielleicht doch sehr auf den individuellen Geschmack (und individuelle Problemlösungen) angewiesen sind? Warum sprießen immerfort neue Sprachpilze aus dem Boden? Ist das nicht Ausdruck ständiger Unzufriedenheit mit dem Vorhandenen? Ist das nicht Ausdruck der Unmöglichkeit einer "perfekten" Sprache?
Cyblord -. schrieb im Beitrag #7132840: > MaWin schrieb: >> Linux ist eine der Kernkomponenten, die die Welt am Laufen halten. >> Ich würde das jetzt nicht als Nische bezeichnen. > > Klar, Linux als Nabel der Welt. Im Nerd-Kinderzimmer sicher richtig. jetzt komm schon, entweder trollst du äußerst gut oder hast absolut keine Ahnung - wenn Linux morgen von der Bildfläche verschwindet funktioniert so gut wie nichts mehr auf dieser Welt - nur so als Info in der Azure-Cloud von Microsoft sind ca. 80% Linux Server drin, fast alle Amazon AWS Instanzen sind Linux, fast alle Super-Computer laufen mit Linux, bis auf Apple fast alle Handys, alle Cloud-Systeme, Netflix, Amazon, Facebook, google, Whatsapp können nicht mal ansaztweise ohne, die Liste hört nicht auf - Microsoft ist definitiv der Desktop-König, aber Linux ist uneinholbar der Server und Konsumer-Devices-König - egal ob dir das bewusst ist Was denkst du warum Microsoft einen Linux Extension WSL für Windows anbietet, oder eine eigene Linux-Distro hat? und ich bin definitiv kein Linux-Nerd - ich muss nur hin und wieder dafür Software schreiben und laufe nicht mit geschlossenen Augen durch die Welt
Ron T. schrieb: > Ist das nicht Ausdruck ständiger Unzufriedenheit mit dem Vorhandenen? > Ist das nicht Ausdruck der Unmöglichkeit einer "perfekten" Sprache? nur wenn man aus der applikativen Richtung schaut, also Java, .Net, Python usw. - im der Systemprogrammiersprachen Welt gab und gib es kaum bis gar keine Bewegung seit jahrzehnten, darum ist Rust auch was anderes als eine "weitere" Sprache
Ron T. schrieb: > Weil Programmiersprachen vielleicht doch sehr auf den individuellen > Geschmack (und individuelle Problemlösungen) angewiesen sind? hört sich ja so an als wäre einen Neue Sprache keine riesen Zeit und Geld-Investition, das ist alles sehr Aufwändig und wird nicht einfach mal so gemacht klarweise gibt es aber wirklich sehr viel "Versuche" die meist schnell wieder unrelevant werden, oder Sache die nur für Nischen relevant sind und einfach nie für den Mainstream gedacht sind > Warum sprießen immerfort neue Sprachpilze aus dem Boden? welche von denen haben länger gehalten und eine relevanz erreicht? Alles Sprache die einfach so sprießen haben für die meisten Entwickler null bedeutung und sind einfach egal - ob sie aus Spass existieren oder nicht - Es gibt kein Globales-Programmiersprachen-Mana das davon weniger wird bis nix mehr da ist, genau so wenig wie das n Kompiler nur die Resourcen verschwenden weil man sich ja auf einen konzentrieren könnte - ABER wenn die Menschen das so nicht wollen/interessiert ist das eine sinnlose Rechnung :) > Ist das nicht Ausdruck ständiger Unzufriedenheit mit dem Vorhandenen? > Ist das nicht Ausdruck der Unmöglichkeit einer "perfekten" Sprache? so denken nur Anfänger - das kann und ist keine relevante Triebfeder - unfährt genauso blöde wie wir-müssem-alles-dann-neuschreiben-sonst-ist-es-nicht-perfekt, nur-wenn-es-in-einer-Sprache-geschrieben-ist-ists-auch-gut Mentalität - alles total überholte Denke die man ein wenig Aufweichen kann die meisten Menschen erwarten von einer neuen Programmiersprache dramatische Verbesserung ala - jetzt kann jeder das neue Doom39 schreiben weil alles automatisch geht - aber das ist nie so - es gibt nur inkrementelle Verbesserung oder Micro-Revolutionen UND die werden dann meistens kaum verstanden weil mehr als 50% der Entwickler eh einfach nur die Sprache nutzt die der Chef befohlen hat :) Mentalität, Erfahrung und die darauf basierenden Bedürfnisse sind so vielschichtig das es kaum möglich ist irgendwie einen direkt Begreifbaren Nenner zu finden - aber stehenbleiben war noch nie gut Ich kann mir schwerlich vorstellen das wir in 200 Jahren (falls es uns da noch gibt) noch C/C++ Code schreiben - maximal pflegen wir noch ein paar Zeilen irgendwo auf dem Mars :)
und nicht das ich falsch Verstanden werden - ich über die letzten 25 Jahre bisher mehrere x Million Zeilen Code, Multiplatform, C++ Projekte begonnen, angeleitet und betreut (nebst .Net, Java, Python...) - ich kenne mich ein wenig aus :)
Ich finde es auch super wie viele Entwickler (damit meine ich nicht unbedingt die anwesenden hier) und auch besonders Nicht-Entwickler, oder (die schlimmste Form) Pseudo-Entwickler sich über die vielfalt an Programmiersprachen aufregen obwohl sie nie wirklich Kontakt dazu haben - warum stresst Leute deren Existenz nur im geringsten und speziell die Leute mit dem geringsten Einfluss und technologischer Breite? so ein bisschen wie die Katholische Kirche und Neuerungen - die existenz ist schon bedrohlich :)
Ein T. schrieb: >> Es gibt gab noch nie einen so ernsthaften Versuch eine bessere >> alternative zu C oder C++ zu erschaffen, > > Aber ja doch, die Sprachen der PASCAL-Familie. Die sind eher zeitgleich entstanden, und zumindest von der Entstehung her hatten beide sehr unterschiedliche Prämissen: Niklaus Wirth wollte eine schöne Sprache für die Lehre erschaffen (das ist Pascal ganz zweifellos), Brian Kernighan und Dennis Ritchie wollten eine Sprache erschaffen, die das mühevolle Coden eines Betriebssystems in Assembler ablösen kann (auch das ist ihnen ganz offensichtlich gelungen). Insofern sind beide nebeneinander aufgewachsen, mit einer gewissen Konkurrenz, und Pascal hat viele Erweiterungen erfahren, aber C hatte natürlich im System-Umfeld die besseren Karten, die dann auch standardisiert worden sind. An Firefox sieht man aber, dass es noch ein langer Weg sein wird: obwohl er ja meines Wissens eine der treibenden Kräfte hinter Rust war (und ist), die Zahl der Speicherlecks und Sicherheitsprobleme ist immer noch recht erheblich. Aber was ich lesen konnte, sind es wohl auch erst 20 %, die in Rust geschrieben sind.
Jörg W. schrieb: > die Zahl der Speicherlecks und Sicherheitsprobleme ist immer noch > recht erheblich. Wie sieht diese "Statistik" denn für die Rust-Komponenten aus? Das ist ja, worauf es ankommt. (Und Rust verhindert keine Speicherlecks, sondern erschwert sie nur.)
MaWin schrieb: >> die Zahl der Speicherlecks und Sicherheitsprobleme ist immer noch >> recht erheblich. > > Wie sieht diese "Statistik" denn für die Rust-Komponenten aus? Keine Ahnung, ob es da eine gibt.
MaWin schrieb: > (Und Rust verhindert keine Speicherlecks, sondern erschwert sie nur.) weil Speicherlecks für Systemprogrammierung (Hardware mapped Speicher usw.) nötig sein können - einer der wenigen Anwendungsfälle :)
cppbert schrieb: > MaWin schrieb: >> (Und Rust verhindert keine Speicherlecks, sondern erschwert sie nur.) > > weil Speicherlecks für Systemprogrammierung (Hardware mapped Speicher > usw.) nötig sein können - einer der wenigen Anwendungsfälle :) UND man muss das auch gezielt sagen sonst gibt es keine ungewollten Leaks: std::mem::forget Box::leak Box::into_raw bei unsafe
cppbert schrieb: > weil Speicherlecks für Systemprogrammierung (Hardware mapped Speicher > usw.) nötig sein können - einer der wenigen Anwendungsfälle :) In einem Firefox sind sie aber eher unnötig. ;-)
cppbert schrieb: >> weil Speicherlecks für Systemprogrammierung (Hardware mapped Speicher >> usw.) nötig sein können - einer der wenigen Anwendungsfälle :) > > UND man muss das auch gezielt sagen sonst gibt es keine ungewollten > Leaks: Naja, der Grund ist eher, dass man Speicherlecks prinzipiell gar nicht 100% verhindern kann. Man kann in Rust ein Speicherleck ohne diese explizit leckenden Funktionen bauen, indem man eine Referenzschleife baut. So eine Referenzschleife ist dann von außen nicht mehr referenziert, aber erhält sich selbst weiterhin am Leben. Es ist damit ein Leck. Die explizit leckenden Funktionen wie forget waren früher unsafe. Man hat dann aber erkannt, dass man auch ohne diese Funktionen Speicher lecken konnte. Und dann hat man forget safe gemacht. Trotzdem ist es extrem schwierig versehentlich in Rust Speicher zu lecken.
MaWin schrieb: > Man kann in Rust ein Speicherleck ohne diese explizit leckenden > Funktionen bauen, indem man eine Referenzschleife baut. Enttäuschend. Dass nichteinmal Rust es schafft, Memory Safty & praktische Brauchbarkeit unter einen Hut zu bringen... Den Level an Sicherheit krieg ich mit C++ smart Pointern auch...
MaWin schrieb: > Trotzdem ist es extrem schwierig versehentlich in Rust Speicher zu > lecken. Was ich natürlich angesichts des sonstigen Fiaskos bei Firefox für ein mehr als wichtiges Feature halte. Meinen Computer kann ich mittlerweile wochen- und monatelang (und rein technisch gesehen sogar jahrelang) durchlaufen lassen, nur der Firefox braucht immer mal einen "Reboot".
DPA schrieb: > MaWin schrieb: >> Man kann in Rust ein Speicherleck ohne diese explizit leckenden >> Funktionen bauen, indem man eine Referenzschleife baut. > > Enttäuschend. Dass nichteinmal Rust es schafft, Memory Safty & > praktische Brauchbarkeit unter einen Hut zu bringen... Den Level an > Sicherheit krieg ich mit C++ smart Pointern auch... MaWin spricht von Cyclic Leaks - das bekommst du auch mit C++ Smartpointer hin - macht eben niemand - das lässt sich nicht "lösen" ohne das du eine Funktionale Programmiersprache nutzt
cppbert schrieb: > DPA schrieb: >> MaWin schrieb: >>> Man kann in Rust ein Speicherleck ohne diese explizit leckenden >>> Funktionen bauen, indem man eine Referenzschleife baut. >> >> Enttäuschend. Dass nichteinmal Rust es schafft, Memory Safty & >> praktische Brauchbarkeit unter einen Hut zu bringen... Den Level an >> Sicherheit krieg ich mit C++ smart Pointern auch... > > MaWin spricht von Cyclic Leaks - das bekommst du auch mit C++ > Smartpointer hin - macht eben niemand - das lässt sich nicht "lösen" > ohne das du eine Funktionale Programmiersprache nutzt Eben, keine Pluspunkte für rusts Memory Safty an dieser Stelle.
Mombert H. schrieb: > cppbert schrieb: >> DPA schrieb: >>> MaWin schrieb: >>>> Man kann in Rust ein Speicherleck ohne diese explizit leckenden >>>> Funktionen bauen, indem man eine Referenzschleife baut. >>> >>> Enttäuschend. Dass nichteinmal Rust es schafft, Memory Safty & >>> praktische Brauchbarkeit unter einen Hut zu bringen... Den Level an >>> Sicherheit krieg ich mit C++ smart Pointern auch... >> >> MaWin spricht von Cyclic Leaks - das bekommst du auch mit C++ >> Smartpointer hin - macht eben niemand - das lässt sich nicht "lösen" >> ohne das du eine Funktionale Programmiersprache nutzt > > Eben, keine Pluspunkte für rusts Memory Safty an dieser Stelle. Das lässt sich in einer Imperative (Statefull-Sprache) nicht lösen (also .Net, Java, C, C++, und,und,und) das ist kein KO-Kriterium für Rust - wer das nicht verstehe kann/will sollte sich Kommentare echt sparen, das wirkt nicht besonders Inteligent oder Erfahren was die Hintergründe bei allen von uns verwendeten Programmiersprachen sind Wieder so eine sinnfreie Argumentation - wenn es nicht 100% Sicherheit erreicht mache ich mit meinen <10% weiter wie bisher, gleiche Argumentation wie bei der Corona-Impfung - wenn die nicht 100% wirkt warum soll ich es dann machen - weil sie eben 30-50% wirkt, oder der Sicherheitsgurt: Der garantiert auch keine 100% Sicherheit - dann kann ich den ja auch weg lassen
cppbert schrieb: > <10% .Net, Java, C++ cppbert schrieb: > .Net, Java, C, C++, und,und,und ... > mache ich mit meinen <10% weiter .Net, Java, C++ (unter Verwendung von smart Pointen, wie heutzutage üblich), und <10%. lol. Viel glück in Java einen use after free zu generieren, das ist da mindestens so gut wie rust, das zu verhindern. Rust mag beim Threading ein paar Vorteile haben, in der Theorie. Aber wenn du glaubst, die Alternativen wären derart unsicher, liegst du schlicht komplett falsch.
cppbert schrieb: > warum stresst Leute deren Existenz nur im geringsten und speziell die > Leute mit dem geringsten Einfluss und technologischer Breite? Weil es an ihrem Weltbild zerrt. Die allermeisten Menschen möchte einfache, simple Erklärungen wie die Welt funktioniert. Dann haben sie das Gefühl sie verstünden die Welt und könnten sich ein Urteil bilden, eine Meinung haben und mitdiskutieren. Komplexität schreckt die meisten Menschen ab. Darum wird Komplexität verleugnet. Endstadium: Verschwörungstheorie.
DPA schrieb: > unter Verwendung von smart Pointen Ich weiß, dass ich einem Troll antworte. Aber das Thema generell ist es schon wert noch einmal zu betrachten. C++ Smart Pointer sind eine tolle Sache. Ich nutze sie in C++ auch gerne. Aber was, wenn ich an einer Stelle vergesse sie zu verwenden? In Rust wird die Verwendung erzwungen. Außerdem sind die Rust-Mechanismen (Referenzen, Pointer und Lifetimes) deutlich ausdrucksstärker und mächtiger als C++ Smart Pointers. Und auch besser zur Compilezeit prüfbar, durch die Rust-Referenzregeln und Lifetimes, die es in C++ beide nicht gibt.
Programmierer schrieb: > Komplexität schreckt die meisten Menschen ab. Darum wird Komplexität > verleugnet. Stop! So wollte ich nicht verstanden werden. Niemand leugnet daß Programmierung oft komplexe Probleme lösen muß und daher nicht immer einfach ist. Hier aber ging es um die Frage warum die Bewertung der einzelnen Sprache so endlos diskutierbar ist und warum da täglich neue entstehen (müssen). Außerdem: Die Programmierung der Sachlage angemessen möglichst einfach und die Werkzeuge dazu möglichst geeignet zu halten hat nichts mit Verleugnung sondern eher mit Vernunft zu tun. Mal umgekehrt die Frage: Zieht Komplexität vielleicht manche Menschen an und sie versuchen diese zu mehren? Computerprogrammierung scheint sich ja hierfür besonders anzubieten!
MaWin schrieb: > Aber was, wenn ich an einer Stelle vergesse sie zu verwenden? Du tippst ausversehen "*" statt std::shared_ptr<> usw. ein? Komplett unabsichtlich? > In Rust wird die Verwendung erzwungen. Es gibt doch unsafe und raw pointer, wer verhindert, dass du die genauso "versehentlich" einsetzt? MaWin schrieb: > Außerdem sind die Rust-Mechanismen (Referenzen, Pointer und Lifetimes) > deutlich ausdrucksstärker und mächtiger als C++ Smart Pointers. Und auch > besser zur Compilezeit prüfbar, durch die Rust-Referenzregeln und > Lifetimes, die es in C++ beide nicht gibt. Ok, beim Threading ganz nützlich. Aber abgesehen davon sehe ich nur einen geringen Nutzen. Und dem gegenüber steht, mit dem borrow Checker kämpfen zu müssen. Was hab ich den nun wirklich davon?
cppbert schrieb: > Mombert H. schrieb: >> Eben, keine Pluspunkte für rusts Memory Safty an dieser Stelle. > Das lässt sich in einer Imperative (Statefull-Sprache) nicht lösen (also > .Net, Java, C, C++, und,und,und) > das ist kein KO-Kriterium für Rust - wer das nicht verstehe kann/will > sollte sich Kommentare echt sparen, das wirkt nicht besonders Inteligent > oder Erfahren was die Hintergründe bei allen von uns verwendeten > Programmiersprachen sind > Wieder so eine sinnfreie Argumentation - wenn es nicht 100% Sicherheit > erreicht mache ich mit meinen <10% weiter wie bisher, gleiche > Argumentation wie bei der Corona-Impfung - wenn die nicht 100% wirkt > warum soll ich es dann machen - weil sie eben 30-50% wirkt, oder der > Sicherheitsgurt: Der garantiert auch keine 100% Sicherheit - dann kann > ich den ja auch weg lassen Du überreagierst etwas ... nichts von dem was du unterstellst hast, habe ich geschrieben. Ich habe nichts von KO-Kriterium geschrieben und ich habe nicht Argumentiert. Ich habe jediglich geschrieben, dass es an dieser *Stelle* keine Pluspunkte für rust gibt. Und natürlich ist dieses spezielle Problem in "Imperative (Statefull-Sprache)" lösbar. Ein garbage collector kann durchaus für alle Objekte prüfen, ob sie nur durch eine "Referenzschleife" am Leben erhalten werden. Wenn mit Referenzschleife etwas anderes gemeint ist, dann klärt mich auf. MaWin schrieb: > C++ Smart Pointer sind eine tolle Sache. Ich nutze sie in C++ auch > gerne. > Aber was, wenn ich an einer Stelle vergesse sie zu verwenden? In Rust > wird die Verwendung erzwungen. Ich weiß nicht wie man das vergessen soll. Du musst ja aktiv etwas anderes machen als den Smart-Pointer zu benutzen. Das ist eine bewusste Entscheidung.
:
Bearbeitet durch User
DPA schrieb: > cppbert schrieb: >> .Net, Java, C, C++, und,und,und Da ging es um den Zyklus in der Referenzierung - gut da sind die GC Sprachen teilweise in der Lage zu aber wenn wir von Rust sprechen geht es eingentlich eher um C/C++ > Viel glück in Java einen use after free zu generieren, das ist da > mindestens so gut wie rust, das zu verhindern. Rust mag beim Threading > ein paar Vorteile haben, in der Theorie. Aber wenn du glaubst, die > Alternativen wären derart unsicher, liegst du schlicht komplett falsch. das sagt niemand und das ist hier auch immer der Irrglaube - die meisten Rust-Befürworter mögen die "Steigerung" der Sicherheit die andere Seite geht immer irgendwie davon aus man sich nicht auskennt, als wenn Smart-Pointer-Verwendung in C++ überhaupt in den letzten +15 Jahren jemals zur Diskussion standen - auch wenn Sie erst mit C++11 wirklich richtig schön implementierbar wurden, wir waren noch in den 90er als die Smartpointer relevant wurden, das ist ein alter Hut und trotzdem kann bis heute mit 3 von 10 Entwicklern immer doch darüber diskutieren ob man die einsetzen sollte - die Frage stellt sich bei Rust nicht - da ist das implizit und btw: ohne ASAN würde man in C++ auch keine Use-After-Free so einfach finden - wenn man nicht alles zubaut mit Smart-Pointern, aber das dieser Luxus auch er wenige Jahre existiert und es immer noch sehr viele Entwickler gibt die denke das man Sanitizer gar nicht braucht erschreckt mich und btw: die Sanitizer sind von Google, welche sagen sie bekommen das mit C++ und ihren Hochgeschultet Entwicklern nicht hin - trotz Smart-Pointer, bei fast 1Mrd. Zeilen C++, welche die selben sind die auch Rust in den Kernel pushen aber das ist hier allen ja klar - so lange man nicht zwischen den Zeilen den Anfänger vermutet und entsprechen kontert
Mombert H. schrieb: > Du überreagierst etwas ... nichts von dem was du unterstellst hast, habe > ich geschrieben. Ich habe nichts von KO-Kriterium geschrieben und ich > habe nicht Argumentiert. Ich habe jediglich geschrieben, dass es an > dieser Stelle keine Pluspunkte für rust gibt. Sorry - du hast absolut recht, ich dich wirklich falsch verstanden
cppbert schrieb: > das ist ein alter Hut und trotzdem kann > bis heute mit 3 von 10 Entwicklern immer doch darüber diskutieren ob man > die einsetzen sollte - die Frage stellt sich bei Rust nicht - da ist das > implizit Da sind wir wieder bei PYTRAN77. Glaubst du wirklich, dass Entwickler, die es in C++ nicht hinbekommen (weil unfähig oder unwillig) konsistent Smart-Pointer einzusetzen, zu rust wechseln und alle Probleme sind verschwunden? Wo sollen da plötzlich die zusätzlichen Gehirnzellen oder der Wille herkommen? cppbert schrieb: > und btw: die Sanitizer sind von Google, welche sagen sie bekommen das > mit C++ und ihren Hochgeschultet Entwicklern nicht hin - trotz > Smart-Pointer, bei fast 1Mrd. Zeilen C++, welche die selben sind die > auch Rust in den Kernel pushen Vielleicht weil sie in ihren C++-Regeln
1 | *Prefer* to have single, fixed owners for dynamically allocated objects. *Prefer* to transfer ownership with smart pointers. |
zu viele "prefer" haben?
DPA schrieb: > Du tippst ausversehen "*" statt std::shared_ptr<> usw. ein? Komplett > unabsichtlich? das ist wieder viel zu detailiert - du, ich und MaWin benutzen alle schon garantiert lange und kontinuilierich Smart-Pointer - das steht ausser Frage sonst bräuchte keiner von uns hier irgenwie mitreden Rust macht den Unterschied as ein Goßteil der üblichen Smart-Pointer Verschmutzung deiner Schnistellen ins Type-System verschoben wird - das ist ein nicht zu kleiner Teil des Codes - und stören Smart-Pointer auch nicht - aber wenn ich Sie nicht schreiben muss und noch Ausdrucksstärker sein kann, warum nicht? btw: ich habe noch nicht erlebt das ein guter C++ Entwickler probleme hatte mit dem Borrow-Checker, der forciert nur Struktur-Strategien die eh üblich sind, nur die Drauf-los-Bastel-Fraktion die noch viel ausprobieren muss tut sich damit schwer - aber wer will die den in seinem Code rumorgeln lassen das ist z.B. genau der Teil der Entwickler die tunlichst die Finger von Kernelentwicklung lassen sollten und die ganze Argumentation endet irgendwie immer in - mir reicht der Vorteil nicht, ich mag das nicht, unrelevant für mich, ungebraucht von mir - das ist in Ordnung aber ist keine ordentliche Diskussion möglich wenn jemand der keinen Sinn an dem Ownership-Modell sieht und Smart-Pointer als ausreichende Lösung empfindet gegen einen Rust-nett-Finder argumentiert Das ist so wie wenn ein Milch-Trinker mit einem Wiskey-Liebhaber diskutiert - das kommt nichts bei raus...
Mombert H. schrieb: > Ich weiß nicht wie man das vergessen soll Komisch, wo dann ständig die ganzen Memory-Safety-Bugs herkommen.
Mombert H. schrieb: > Da sind wir wieder bei PYTRAN77. Glaubst du wirklich, dass Entwickler, > die es in C++ nicht hinbekommen (weil unfähig oder unwillig) konsistent > Smart-Pointer einzusetzen, zu rust wechseln und alle Probleme sind > verschwunden? Wo sollen da plötzlich die zusätzlichen Gehirnzellen oder > der Wille herkommen? Nein nicht alle, das wäre dumme zu denken, aber Sie können sich mehr auf die logischen oder strukturellen Probleme konzentrieren - damit haben die ja auch schon Probleme :) - was bringt es uns Sie damit zusätzlich zu belasten (mal außen vor gelassen das es noch viel C++ gibt und die das eh machen müssen) und wie gesagt - ich kann sehr gute C++ Software schreiben, ich kämpfe nicht mit C++ Probleme, oder ich habe genug Erfahrung das richtige zu tun - aber ich verstehe, wenn ich teilweise in +100 Entwickler-Teams sitze das meine eigenen Bedürfnisse und Fähigkeite nicht automatisch für das Team relevant sind und DAS ist der Unterschied - der Maßstab bei dem Rust-Features anfangen mehr Bedeutung zu bekommen - jedes mal wenn einer aus der Ich-Perspektive Argumentiert sitzt er alleine da und denk nicht an das Team und die Million von Entwicklern die auf der Welt verteilt sind - dafür werden bessere Programmiersprachen entwickelt - unabhängig davon ob die angenommen werden oder wegen sinnlosigkeit sterben
MaWin schrieb: > Mombert H. schrieb: >> Ich weiß nicht wie man das vergessen soll > Komisch, wo dann ständig die ganzen Memory-Safety-Bugs herkommen. Vielleicht haben sie sich gegen Smart-Pointer entschieden? Es gibt noch alternativen zum Vergessen. An dieser Stelle muss ich dich an einen deiner früheren Beiträge erinneren. MaWin schrieb: > Mombert, dir antworte ich übrigens nicht mehr, falls du es noch nicht > gemerkt hast. Hast du vergessen, dass du mir nicht mehr antwortest, oder hast du dich anders entschieden?
Mombert H. schrieb: > MaWin schrieb: >> Mombert H. schrieb: >>> Ich weiß nicht wie man das vergessen soll >> Komisch, wo dann ständig die ganzen Memory-Safety-Bugs herkommen. > Vielleicht haben sie sich gegen Smart-Pointer entschieden? Es gibt noch > alternativen zum Vergessen. Das könnte man vermutlich ganz einfach mit einem Linter fixen, der einfach keine normalen Pointer akzeptiert. Dann setzt man das als git hook im Repo, um es zu erzwingen. Und schon sind 99% der Probleme weg.
Mombert H. schrieb: > Vielleicht weil sie in ihren C++-Regeln*Prefer* to have single, fixed > owners for dynamically allocated objects. Prefer to transfer ownership > with smart pointers. > zu viele "prefer" haben? und wir sind wieder bei dem die haben wohl schlechte Regeln oder schlechte Mitarbeiter Argumentation - google investiert viel Zeit und Geld in seine Mitarbeiter, was sollen die sonst noch tun - auf bessere Zeiten hoffen? damit ihre zig tausend Entwickler so gut werden das die Testabteilung:Weltbevölkerung bei denen keine Fehler mehr findet, das ist irrglaube in diesem Dimensionen, deswegen haben die google Leute die Sanitizer entwickelt und dann nach ein paar Jahren festgestellt das es immer noch nicht reicht - welche Firma die nicht so gross ist betreibt denn noch so einen Aufwand um besser zu werden? Die Realität ist: Es wird zu wenig getestet, die Projekte werden immer komplexer, das erschwert das testen weiter, TDD ist nicht die Lösung, bessere Mitarbeitet ist der feuchte Traum jeden Abteilungsleiters und der menschliche Faktor ist schwierig zu kontrollieren - vielleicht in den 15 Mann Buden in denen wir alle mal hin und wieder gearbeitet haben aber nicht für zig-tausend Entwickler - und das bedeutet nicht das wir alle und alle Firmen ständig leakend und abstürzenden C++ Programme schreiben - absolut nicht
cppbert schrieb: > Mombert H. schrieb: >> Da sind wir wieder bei PYTRAN77. Glaubst du wirklich, dass Entwickler, >> die es in C++ nicht hinbekommen (weil unfähig oder unwillig) konsistent >> Smart-Pointer einzusetzen, zu rust wechseln und alle Probleme sind >> verschwunden? Wo sollen da plötzlich die zusätzlichen Gehirnzellen oder >> der Wille herkommen? > > Nein nicht alle, das wäre dumme zu denken, aber Sie können sich mehr auf > die logischen oder strukturellen Probleme konzentrieren - damit haben > die ja auch schon Probleme :) - was bringt es uns Sie damit zusätzlich > zu belasten (mal außen vor gelassen das es noch viel C++ gibt und die > das eh machen müssen) Nur weil sie in rust dazu gezwungen werden es richtig zu machen, heißt nicht, dass sie es automatisch sofort richtig machen können. rust nimmt einem nicht die Arbeit ab, es richtig zu machen. Man wird nur dazu gezwungen es auf die rust-Art zu machen, die in den allermeisten Fällen zu mehr Sicherheit führt. Es ist auch nicht so, als wäre es in C++ wirklich schwierig es richtig zu machen, wenn man es will.
DPA schrieb: > Mombert H. schrieb: >> MaWin schrieb: >>> Mombert H. schrieb: >>>> Ich weiß nicht wie man das vergessen soll >>> Komisch, wo dann ständig die ganzen Memory-Safety-Bugs herkommen. >> Vielleicht haben sie sich gegen Smart-Pointer entschieden? Es gibt noch >> alternativen zum Vergessen. > > Das könnte man vermutlich ganz einfach mit einem Linter fixen, der > einfach keine normalen Pointer akzeptiert. Dann setzt man das als git > hook im Repo, um es zu erzwingen. Und schon sind 99% der Probleme weg. wir nutzen doch schon alle Linter bis zum Umfallen, und git, perforce, svn Hooks ein für jeden Scheiss - die sau-teueren und die freeware, open source sachen - man findet immer und immer wieder Sachen, die Menge geht nicht runter - es ist immer noch stark an der eingetragenen Quelltextmenge fest zu machen - und das scheint bei vielen Firmen der Fall zu sein - ob du das so kennst ist eine andere Sachen, aber es existiert
DPA schrieb: > Und schon sind 99% der Probleme weg. Wenn man sich am Riemen reißt und alles richtig programmiert, dann sind sogar 100% der Probleme weg. Einfach keine Fehler machen und alles ist gut. Der Vorteil von Rust ist, dass diese Fehler dort gar nicht möglich sind.
Mombert H. schrieb: > Nur weil sie in rust dazu gezwungen werden es richtig zu machen, heißt > nicht, dass sie es automatisch sofort richtig machen können. rust nimmt > einem nicht die Arbeit ab, es richtig zu machen. Man wird nur dazu > gezwungen es auf die rust-Art zu machen, die in den allermeisten Fällen > zu mehr Sicherheit führt. Das hört sich eingezwänger als als es tatsächlich ist > Es ist auch nicht so, als wäre es in C++ wirklich schwierig es richtig > zu machen, wenn man es will. "man will" ist und bleibt das Kernproblem das man versucht (irgendwie) zu adressieren - wenn man das als sinnlos empfindet bringt Rust an dieser Stelle einfach nicht viel - weil es kein Problem gibt - oder Probleme nicht reduziert werden können (die Natur der Sache)
cppbert schrieb: > Das hört sich eingezwänger als als es tatsächlich ist Genau. Der Rust-Compiler gibt einem sehr gute Hinweise und die Compilerfehlerdokumentation ist auch sehr hilfreich. Das ist gar nicht vergleichbar mit den kryptischen Kram, den GCC und MSVC so rauswerfen. In der Regel steht die Lösung für das Problem, oder ein Vorschlag, der der Lösung bereits sehr nahe kommt, in der rustc-Fehlermeldung mit drin. Und wenn nicht, dann findet man in der zugehörigen, direkt vom Compiler verlinkten, Dokumentation eine genaue Erklärung, warum das nicht gut ist, was man da tut. cppbert schrieb: > "man will" ist und bleibt das Kernproblem das man versucht (irgendwie) > zu adressieren - wenn man das als sinnlos empfindet bringt Rust an > dieser Stelle einfach nicht viel Es geht über den reinen Willen hinaus. Rust hat einfach einige sehr unschöne Altlasten nicht, die C/C++ mitbringt. Zum Beispiel Integer-Promotion, Typbalancierung und implizite Typwandlungen gibt es alle in Rust nicht. Und Bugs ausgelöst durch diese Altlasten haben wohl die meisten Programmierer einmal versehentlich gemacht. Es ist insgesamt viel schwieriger solche grundlegenden und nicht direkt offensichtlichen Fehler zu machen.
Und diese ganze Smart-Pointer Aussage ist auch ohne Relevanz wenn wir von C sprechen - oder will hier ernsthaft jemand behaupten das er jemals diese fiesen Macro-basierte Smart-Pointer libs für C genutzt hat? im Embedded-Breich ist C eben z.B. auch deswegen stark weil es definitiv gar keine Runtime Braucht, im gegensatz zu C++ wegen Execptions (die auf dem Heap landen) - das ist z.B. auch ein Grund warum sich C++ da so nicht durchsetzt Rust hat diese Nachteile nicht - genau wie C keine Runtime nötig (gut so lange man auf Standard-Async verzichtet) und trotzdem hat man dort die Sicherheit die mit sonst manuell eingebrachten Smart-Pointern
cppbert schrieb: > das ist z.B. auch ein Grund warum sich C++ da so nicht durchsetzt Wobei man auf Exceptions ja durchaus auch verzichten kann, wenn das das einzige Problem wäre. Andererseits sind sie natürlich nett, wenn man sie hat, weil man sich dann so ein error code passing über 5 Etagen sparen kann.
cppbert schrieb: > im Embedded-Breich ist C eben z.B. auch deswegen stark weil es definitiv > gar keine Runtime Braucht, im gegensatz zu C++ wegen Execptions (die auf > dem Heap landen) - das ist z.B. auch ein Grund warum sich C++ da so > nicht durchsetzt Bist du sicher, dass das der Grund ist? Oder ist es vielleicht nur ein Vorwand der "Ich will nicht"-Fraktion? Denn auch C braucht eine Runtime, wenn man die ganze Sprache nutzen will und man kommt in C++ ohne Exceptions aus, wenn man nicht die ganze Sprache nutzt. Und das gleiche gilt für rust, wie du selbst feststellst ("gut so lange man ..."). > Rust hat diese Nachteile nicht - genau wie C keine Runtime nötig (gut so > lange man auf Standard-Async verzichtet) und trotzdem hat man dort die > Sicherheit > die mit sonst manuell eingebrachten Smart-Pointern
Mombert H. schrieb: > Denn auch C braucht eine Runtime Wobei diese schon sehr minimalistisch ist: Ausnullen von .bss, Initialisieren von .data, Setzen des Stackpointers.
Mombert H. schrieb: > cppbert schrieb: >> im Embedded-Breich ist C eben z.B. auch deswegen stark weil es definitiv >> gar keine Runtime Braucht, im gegensatz zu C++ wegen Execptions (die auf >> dem Heap landen) - das ist z.B. auch ein Grund warum sich C++ da so >> nicht durchsetzt > Bist du sicher, dass das der Grund ist? Oder ist es vielleicht nur ein > Vorwand der "Ich will nicht"-Fraktion? ja das auf jeden Fall auch > Denn auch C braucht eine Runtime, wenn man die ganze Sprache nutzen will die Sprache kommt ohne Runtime aus - oder meinst du die Standard Library?
cppbert schrieb: > ich verstehe nie so wirklich was du sagen willst Das ist jetzt aber nicht mein Problem :) cppbert schrieb: > ist eine Rust-CUDA > Wrapper jetzt nicht Nische, oder Nische? Das mit dem "Gesucht" war ergänzend zum Nischenargument gemeint, und würde zusammen mit dem Nischen-Vorwurf in DPAs Runterwertungsschublade passen. Also "Nische" + "Gesucht". Dass der Link auch zweideutig gemeint war, hast du nicht mitbekommen - möglicherweise, weil du den etwas zu ernst genommen hast.
Jörg W. schrieb: > Mombert H. schrieb: >> Denn auch C braucht eine Runtime > > Wobei diese schon sehr minimalistisch ist: Ausnullen von .bss, > Initialisieren von .data, Setzen des Stackpointers. Ich hätte jetzt noch die Buchführung für malloc und Co aufgelistet, aber das ist optional. cppbert schrieb: > Mombert H. schrieb: >> cppbert schrieb: >>> im Embedded-Breich ist C eben z.B. auch deswegen stark weil es definitiv >>> gar keine Runtime Braucht, im gegensatz zu C++ wegen Execptions (die auf >>> dem Heap landen) - das ist z.B. auch ein Grund warum sich C++ da so >>> nicht durchsetzt >> Bist du sicher, dass das der Grund ist? Oder ist es vielleicht nur ein >> Vorwand der "Ich will nicht"-Fraktion? > ja das auf jeden Fall auch >> Denn auch C braucht eine Runtime, wenn man die ganze Sprache nutzen will > die Sprache kommt ohne Runtime aus - oder meinst du die Standard > Library? Für mich gehört die Standard Bibliothek zur Sprache. Beide werden in einem Dokument mit der überschrift "Programming languages — C" definiert und nicht streng getrennt.
Mombert H. schrieb: > Ich hätte jetzt noch die Buchführung für malloc und Co aufgelistet, aber > das ist optional. Viele mögen es im (deeply) embedded nicht, wenngleich ich das nicht immer nachvollziehen kann. ;-) Ja, könnte man dazu zählen. > Für mich gehört die Standard Bibliothek zur Sprache. Beide werden in > einem Dokument mit der überschrift "Programming languages — C" definiert > und nicht streng getrennt. Zumal der Compiler ja auch implizites Wissen darüber haben darf und beispielsweise ein "strlen("Hi")" direkt durch die Konstante 2 ersetzen darf.
Mombert H. schrieb: > Für mich gehört die Standard Bibliothek zur Sprache. Beide werden in > einem Dokument mit der überschrift "Programming languages — C" definiert > und nicht streng getrennt. auf embedded kann es aber sein das du die Runtime komplett ersetzen willst, das geht mit C und Rust - aber nicht mit C++ - weil du die Exceptions nur vermeiden kannst aber da ist die Runtime trotzdem (oder kann man das mitlerweile auch entfernen? aber dann wieder Kompiler-Spezifisch) z.B. der Linux Kernel nutzt ja auch seine "eigene" Standard-Library weil er die GlibC klarerweise nicht nutzen kann
cppbert schrieb: > Linux Kernel nutzt ja auch seine "eigene" Standard-Library Ist ja egal, das ist dann alles "the implementation". Wichtig ist ja nur, dass sie zumindest die Teile, die wirklich benutzt werden, dann auch so implementiert, wie es der Sprachstandard will. Also "strlen("Hi")" sollte in der geänderten Version nicht gerade 42 zurück geben. ;-)
cppbert schrieb: > Mombert H. schrieb: >> Für mich gehört die Standard Bibliothek zur Sprache. Beide werden in >> einem Dokument mit der überschrift "Programming languages — C" definiert >> und nicht streng getrennt. > > auf embedded kann es aber sein das du die Runtime komplett ersetzen > willst, das geht mit C und Rust - aber nicht mit C++ - weil du die > Exceptions nur vermeiden kannst aber da ist die Runtime trotzdem (oder > kann man das mitlerweile auch entfernen? aber dann wieder > Kompiler-Spezifisch) Die C-Runtime unabhängig vom Compiler zu ersetzen, dürfte ne interessante Aufgabe sein. Wie schafft man es z.B. eine stdarg.h oder float.h zu erstellen, ohne auf die Eigenheiten des Compilers einzugehen?
:
Bearbeitet durch User
Mombert H. schrieb: > Wie schafft man es z.B. eine stdarg.h oder > float.h zu erstellen ja das wird schwierig - one aligment-Wissen wird das nix - ok mit C11 bekommt man das alignof noch raus usw. aber bastelig ist es definitiv
Wie ist in Rust eigentlich die async / await Geschichte implementiert? Mein momentaner Wissensstand ist, dass async Funktionen analog zu co-routinen sind / man das eine mittels dem anderen implementieren kann. co-routinen, und damit async funktionen, bräuchten damit einen zusätzlichen Stack. Ist das bei Rust auch so, braucht der Aufruf jeder async funktion einen eigenen Stack? Oder wurde da eine bessere Methode gefunden, das umzusetzen? Ich kenne async-await hauptsächlich von javascript und python her, es ist unglaublich praktisch. Falls ich mal meine eigene Programmiersprache entwickle, würde ich so ein feature auch wollen. Aber ich will nicht wirklich den Preis, den Speicher & Adressraum für mehrere Stacks, zahlen. Insbesondere wenn man auf tausende Sachen wartet, wie verhindert man da dass das enorm Speicher verbraucht? Und wie verhindert man, dass sich die Stacks in die quere kommen? Ich konnte das bisher noch nicht heraus finden.
DPA schrieb: > Wie ist in Rust eigentlich die async / await Geschichte implementiert? https://rust-lang.github.io/async-book/01_getting_started/02_why_async.html
1 | Async in Rust vs other languages |
2 | |
3 | Although asynchronous programming is supported in many languages, some details vary across implementations. Rust's implementation of async differs from most languages in a few ways: |
4 | |
5 | [...] |
6 | |
7 | Async is zero-cost in Rust, which means that you only pay for what you use. Specifically, you can use async without heap allocations and dynamic dispatch, which is great for performance! This also lets you use async in constrained environments, such as embedded systems. |
8 | |
9 | [...] |
...und die Runtime für Async ist austauchbar - damit man keinen Standard für alle definiert der dann in der Systemprogrammierung eh nie passt :) das macht das ganze aber ein bisschen komplizierter, weil man die Wahl zwischen verschiedenen Backends die nicht unbedingt von den Rust-Leuten selber kommen - das stört die Alles-aus-einer-Hand-Fraktion ein wenig
> Async is zero-cost in Rust, which means that you only pay for what you use.
Das ist ja gute Werbung, aber mich interessiert: Was heisst das, und wie
geht das? Nehmen wir gerade mal das Beispiel auf der Seite:
1 | async fn get_two_sites_async() { |
2 | // Create two different "futures" which, when run to completion,
|
3 | // will asynchronously download the webpages.
|
4 | let future_one = download_async("https://www.foo.com"); |
5 | let future_two = download_async("https://www.bar.com"); |
6 | |
7 | // Run both futures to completion at the same time.
|
8 | join!(future_one, future_two); |
9 | }
|
Um mal zu illustrieren, was mir unklar ist, nehmen wir mal folgenden execution flow, und nur einen Stack an:
1 | get_two_sites_async |
2 | join! |
3 | future_one (download_async) |
4 | ruft ne funktion auf |
5 | muss auf IO warten |
6 | future_two (download_async) |
7 | ruft ne funktion auf |
8 | muss auf IO warten |
9 | future_one wird fortgesetzt |
10 | ruft ne funktion auf >>> (Wo landet das jetzt auf dem Stack?) |
11 | future_one ist fertig |
12 | future_two (wird fortgesetzt) >>> (Wo liegt das jetzt auf dem Stack? Ist da jetzt einfach ne lücke, wo future_one war?) |
Wie haben die das gelöst? Wie geht das? Oder gibt es da 2 Stacks, auch in rust, und zero-cost heisst da nur Bestmöglich, statt effektiv gratis? cppbert schrieb: > ...und die Runtime für Async ist austauchbar - damit man keinen Standard > für alle definiert der dann in der Systemprogrammierung eh nie passt :) Ok, heisst das, dass halt die Runtime den Kompromiss machen müssen, und dort die Kosten entstehen, mehrere Stacks zu brauchen, während die API selbst prinzipiell schon zero-cost wäre?
DPA schrieb: > Ok, heisst das, dass halt die Runtime den Kompromiss machen müssen, und > dort die Kosten entstehen, mehrere Stacks zu brauchen, während die API > selbst prinzipiell schon zero-cost wäre? Wäre jetzt auch meine Vermutung. Ich wüsste zumindest nicht, wie man für threading mehrere Stacks vermeiden will. In einem VM-System kann natürlich jeder seinen eigenen VM-Bereich bekommen, der sich dann auch automatisch vergrößern lässt, auf einem Controller wird man wohl oder übel vorab Stacks definieren müssen.
DPA schrieb: > Oder gibt es da 2 Stacks, auch in rust, und zero-cost heisst da nur > Bestmöglich, statt effektiv gratis? Ich wüsste nicht wie man alles auf einem Stack realisieren könnte. Dafür müsste jedes mal wenn der Stack manipuliert wird, ein riesen Aufwand getrieben werden. Oder der Stack, den jeder async sieht hat eine festgelegte maximale Größe, die beim Aufruf festgelegt wird.
DPA schrieb: > cppbert schrieb: >> ...und die Runtime für Async ist austauchbar - damit man keinen Standard >> für alle definiert der dann in der Systemprogrammierung eh nie passt :) > > Ok, heisst das, dass halt die Runtime den Kompromiss machen müssen, und > dort die Kosten entstehen, mehrere Stacks zu brauchen, während die API > selbst prinzipiell schon zero-cost wäre? ja ich glaube das es so ist - aber vielleicht kann MaWin uns da mehr erleuchten - Rust versucht so viel wie möglich mit Move oder trivial-Copy zu machen - vielleicht heisst das hier auch Nearly-Zero-Copy das ist mir im Detail auch noch nicht klar wie die das machen - ich gehe auch davon aus das man n Stacks haben muss ich hab auch gelesen das die Runtime nicht notwendigerweise alles mit Threads machen muss - also auch so co-routine Style im Hintergrund moeglich, weil eben die Kleinst-Systeme vielleicht nur ein paar statische Puffer am auf denen sie operieren dürfen Ich fordere Tiefen-Erleuchtung!
DPA schrieb: > Wie haben die das gelöst? Wie geht das? > Oder gibt es da 2 Stacks, auch in rust, und zero-cost heisst da nur > Bestmöglich, statt effektiv gratis? Eine Async-Funktion in Rust unterbricht ihre Ausführung nur an .await-Stellen, dazwischen arbeitet sie grundsätzlich synchron. Zur Fortsetzung muss die Runtime wieder die poll-Methode aufrufen. Von jeder Unterbrechung bis zur Fortsetzung liegen die benötigten lokalen Variablen im Future-Objekt selbst. Die Größe des Future-Objekts ist statisch bekannt, da alle lokale Variablen eine bekannte Größe haben müssen. Als Konsequenz sind jedoch rekursive async-Aufrufe nicht in sich geschlossen möglich; dort kommt man um die Nutzung des Heaps meist nicht herum. Die Async-Sprachintegration ist im Grunde Syntaxzucker zur Erstellung von Zustandsautomaten (->Future). Die Anzahl der benötigten Stacks beläuft sich also auf genau die Anzahl der Async-Worker-Threads.
https://www.reddit.com/r/rust/comments/w4cwvj/how_much_zerocost_is_async/ > > Async functions desugar to something that looks a bit like an enum, with each variant representing a section between await points (and the associated state it needs). > > There's no reason for anything to be heap allocated, because the entire structure is known at compile time. You can put a future on the heap if you want, but you can just use impl Future if you don't want to (this is what an async fn does). > >There is one major exception: traits. Async functions in traits are currently not possible, but something quite similar can be achieved using the async-trait crate. This performs some of the same rewriting that the compiler does with regular async functions, but for various reasons, it needs to allocate futures on the heap. > >However, this restriction is expected to be lifted. Generic associated types (GATs) are one of the key blockers, and are close to being stabilized, but there are still some unresolved issues. However, it's possible that GATs can be used to implement "async fn in traits" before they are stabilized as a user-facing feature. >
Beitrag #7134604 wurde vom Autor gelöscht.
Jörg W. schrieb: > auf einem Controller wird man wohl oder > übel vorab Stacks definieren müssen. Kommt drauf an, auf dem Raspi könnte man auch OS-Ressourcen benutzen. Fragen könnte man sich, wie die Rust-Entwickler das mit der intensiven Cachenutzung und dem Alignment hinbekommen haben. Man kann aber ahnen, worauf es hinausläuft. Besondere Bibliotheken, bzw. Unterstützung für Embedded soll es auch geben. Wer Assembler kennt, und C, der weiß auch, dass vieles einfach über Zeiger läuft. (oder Basic, goto xy) Speichermanagement mit statischen Variablen stelle ich mir auch nicht sonderlich schwierig vor. Hinzu kommt, dass bei so Compilergeschichten und Programmiersprachen vieles letztendlich über C läuft, da braucht man sich über "kostenlose" Unterfunktionen in C nicht wundern. Parameterübergabe kann man sich ja mal in Haskell ansehen - Ich bin da sicher nicht der einzige, dem es diesbezüglich ein wenig an Pragmatik fehlt. Wenn im Hexeditor zwischen zwei Funktionen zuviel Platz erkennbar ist - nun, dafür hat man ja auch einen Hexeditor :) Die eine gute Analogie wäre: neues Motorrad, viel PS und schnell, Superhandling, aber Elektroantrieb. Mir würde der gute Sound fehlen, aber es gibt auch Leute, die fragen nach dem Ölverbrauch ;)
rbx schrieb: hier gibt es ordentlich Klärungsbedarf - du hast mich wieder mal verwirrt > Kommt drauf an, auf dem Raspi könnte man auch OS-Ressourcen benutzen. was sind OS-Ressourcen beim Raspi? irgendwelche In-Kernel Bereiche, ist das nicht Raspi-OS nicht einfach Linux, da kenn ich sowas nicht > Fragen könnte man sich, wie die Rust-Entwickler das mit der intensiven > Cachenutzung und dem Alignment hinbekommen haben. was meinst du mit hinbekommen? > Wer Assembler kennt, und C, der weiß auch, dass vieles einfach über > Zeiger läuft. > (oder Basic, goto xy) das ist doch der 90% Fall, oder? und welche Gemeinsamkeit haben Zeiger und goto? > Hinzu kommt, dass bei so Compilergeschichten und Programmiersprachen > vieles letztendlich über C läuft, da braucht man sich über "kostenlose" > Unterfunktionen in C nicht wundern. was sind "kostenlose" Unterfunktionen bei C? > Parameterübergabe kann man sich ja mal in Haskell ansehen - Ich bin da > sicher nicht der einzige, dem es diesbezüglich ein wenig an Pragmatik > fehlt. hat Haskell Parameterübergabe ähnlichkeit zu Async-Stacks? > Wenn im Hexeditor zwischen zwei Funktionen zuviel Platz erkennbar ist - > nun, dafür hat man ja auch einen Hexeditor :) Für was ist denn der Platz? Normalerweise doch für gar nichts ausser Alignment, oder was meinst du?
Async/Await benötigt in keiner Programmiersprache eigene Stacks pro "Warte-Stelle" oder Async-Funktion. Der Witz an Async/Await ist doch genau der, dass das nur Syntax-Zucker für Callbacks ist. Async/Await sind eben genau keine Threads, weder OS-Threads noch Green-Threads. Ganz Allgemein macht ein Compiler aus
1 | funtion a() { |
2 | teil_vorher(); |
3 | ergebnis = await async_funtion(); |
4 | teil_nachher(); |
5 | } |
zwei Funktionen, und der Teil nach dem await() wird eine Callback-Funktion der async-Funktion: Also etwa:
1 | funtion a_impl() { |
2 | teil_vorher(); |
3 | async_funktion_impl(&a_weiter_impl); |
4 | } |
5 | |
6 | funktion a_weiter_impl(ergebnis_von_async_funktion) { |
7 | teil_nachher(); |
8 | } |
Natürlich kommt da noch ein wenig Brimborium dazu, und in manchen Sprachen, z.B. Rust, wird noch etwas mehr gemacht. Aber das Grundprinzip ist immer gleich: Keine Threads, sondern nur eine State-Maschine die mit Callbacks implementiert ist.
Programmierer schrieb: > Async/Await benötigt in keiner Programmiersprache eigene Stacks > pro "Warte-Stelle" oder Async-Funktion. > Der Witz an Async/Await ist doch genau der, dass das nur Syntax-Zucker > für Callbacks ist. Async/Await sind eben genau keine Threads, weder > OS-Threads noch Green-Threads. Ok aber wie kann ich dann Async Funktionen wirklich parallel laufen lassen, also in verschiedenen Threads, um wirklich auf mehrere Kerne zu skalieren, oder gibt es dafür etwas ganz anderes, oder ist meine Threadingdenke zu antiquiert/eingefahren nach den vielen Jahren?
Programmierer schrieb: > Async/Await sind eben genau keine Threads Wie bereits gesagt: In Rust können async-Tasks auch auf Threads laufen. https://docs.rs/tokio/1.20.0/tokio/runtime/index.html#multi-thread-scheduler Das Rust-Typsystem mit seiner inhärenten Thread-safety macht es möglich.
MaWin schrieb: > Wie bereits gesagt: > In Rust können async-Tasks auch auf Threads laufen. Exakt. Das ist eine Besonderheit bei Rust, die durch das verwendete Memory-Modell erst möglich wird. cppbert3 schrieb: > Ok aber wie kann ich dann Async Funktionen wirklich parallel laufen > lassen, also in verschiedenen Threads, Async/Await als Konzept hat erstmal nichts mit Threads zu tun und laufen (eigentlich) niemals "parallel". Das ist eine Rust-Besonderheit. In anderen Sprachen ist das nicht möglich. > um wirklich auf mehrere Kerne zu skalieren Async/Await ist für den IO-Bound-Fall gedacht, dass also Dein Programm durch die IO-Bandbreite begrenzt wird, und nicht durch die CPU-Bandbreite. Das ist in einem einfachen Programm der Fall, während es große Dateien verarbeitet und während dessen z.B. einen Spinner auf der Konsole anzeigt, oder ein paar Dateien aus dem Internet heruntergeladen werden. Oder bei einem Server, der 20.000 Clients gleichzeitig irgendwelche HTML-Seiten ausliefert. Threads wiederum sind für CPU-Bound-Fälle ideal. D.h. das Programm muss etwas berechnen, z.B. Primzahlen oder eine numerische Lösung finden z.B. eine elektronische Schaltung simulieren. Da ist die CPU der Bremsklotz, und nicht IO. Async/Await ist sehr leichtgewichtig, da eben keine mehrfachen Stacks vorhanden sind oder Daten zwischen CPU-Kernen hin- und her- kopiert werden müssen inkl. Cache-Pollution etc. Natürlich sind die meisten Programme selten rein IO-Bounded. So müssen die Daten die ausgegeben oder empfangen werden, irgendwie generiert oder verarbeitet werden, also CPU-Ressourcen sind notwendig. Und hier kommt eben das Memory-Modell von Rust zur Hilfe, das es eben ermöglicht, die CPU-Anteile doch auf Threads und somit CPU-Cores zu verteilen. Aber wie gesagt, das ist eine Extra-Spezialität von der Du aus Sicht des Programmiermodels nichts mitbekommst. > oder ist meine > Threadingdenke zu antiquiert/eingefahren nach den vielen Jahren? Die meiste "Parallelisierung" in den meisten Programmen ist nicht CPU-bounded, sonder IO-bounded. Klassiker: Download von Dateien aus dem Internet. Dazu benötigt es keine Threads, das ist reine Ressourcenverschwendung und birgt in fast allen Programmiersprachen auch noch große Gefahren für Programmierfehler.
rbx schrieb: >> auf einem Controller wird man wohl oder >> übel vorab Stacks definieren müssen. > > Kommt drauf an, auf dem Raspi könnte man auch OS-Ressourcen benutzen. Ich schrieb: Controller. Ein Rapsberry Pi ist kein Microcontroller mehr. Wenn ich da ein (komplettes, nicht irgendwie herunter getunetes) Linux oder BSD drauf laufen lassen kann (selbst Windows hatte sich ja dran versucht), dann ist das Ding in der Art und Weise, wie es programmiert wird, letztlich ein PC. Dass er noch ein paar GPIOs rausgeführt hat, ändert nichts grundsätzlich dran. Programmierer schrieb: > Threads wiederum sind für CPU-Bound-Fälle ideal. Das würde ich überhaupt nicht so sehen. Das ist Parallelisierung, am besten über mehrere CPUs. Threads waren und sind ganz viel benutzt worden, um das Handling der IOs zu vereinfachen: ich habe einen Thread, der auf der seriellen Schnittstelle wartet, bis was reinkommt, einen, der die GUI bedient und wartet, bis dort irgendein Event angekleckert kommt, etc. pp. OK, stimmt schon, dafür muss man eigentlich nicht unbedingt einen kompletten Thread aufmachen mit eigenem Stack, weil während der IO-Wartezeit ja sowieso nichts auf diesem passieren würde. Lässt sich ja auch ganz klassisch komplett ohne Threads handhaben (siehe select()), ist dann eben nur im Code unhandlicher.
DPA schrieb: > C - Kohlenstoff > > Unglaublich nützlich... Lustig, Google kam wohl mit einer ähnlichen Analogie auf: Carbon Language - An experimental successor to C++ https://github.com/carbon-language/carbon-lang
Jörg W. schrieb: > Programmierer schrieb: >> Threads wiederum sind für CPU-Bound-Fälle ideal. > > Das würde ich überhaupt nicht so sehen. Das ist Parallelisierung, am > besten über mehrere CPUs. Threads waren und sind ganz viel benutzt > worden, um das Handling der IOs zu vereinfachen: ich habe einen Thread, > der auf der seriellen Schnittstelle wartet, bis was reinkommt, einen, > der die GUI bedient und wartet, bis dort irgendein Event angekleckert > kommt, etc. pp. > > OK, stimmt schon, dafür muss man eigentlich nicht unbedingt einen > kompletten Thread aufmachen mit eigenem Stack, weil während der > IO-Wartezeit ja sowieso nichts auf diesem passieren würde. Lässt sich ja > auch ganz klassisch komplett ohne Threads handhaben (siehe select()), > ist dann eben nur im Code unhandlicher. die meisten Betriebssysteme können ja recht viele Operationen auch asynchron, aber die Schicht die darüber liegt ist dann oft leider wieder synchron und dann braucht man extra einen Thread damit man das unblockierend laufen lassen kann - also sind Threads manchmal wirklich nur eine selbstgemachte (weil asynchron-Features ignoriend) oder Framework-arbeitet-leider-nur-synchron Notwendigkeit, wie viel Potential da schon verblasen wird
Hallo Programmierer. Programmierer schrieb: > Komplexität schreckt die meisten Menschen ab. Darum wird Komplexität > verleugnet. Endstadium: Verschwörungstheorie. Das ist richtig! Allerdings sollte man auch erwähnen, das Komplexität darum abschreckt, weil Komplexität die meisten Menschen überfordert. Darum sollte man versuchen Komplexität, wenn sie nicht unbedingt erforderlich ist, zu meiden. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > Darum sollte man versuchen Komplexität, wenn sie nicht unbedingt > erforderlich ist, zu meiden. Komplexität ist ein Biest:
1 | Person + Wissensstand + Erfahrung + aktueller Fokus => Komplexitätsgefühl |
da die vier Faktoren so unglaublich Variant sind ist Komplexität eher so als Random-Value zu sehen - die sich in jedem Kopf, zu jeder Zeit völlig anders darstellt und deswegen auch Programmiersprache-Diskussionen so ungelaublich schwer sind
Was für den einen komplex ist kann trotzdem die besser Lösung sein weil er einfach den Themenkomplex nicht überblickt - immer die grosse Gefahr viele stapeln gerne klein - nicht weil das so richtig ist sondern weil sie gar nicht anders können - rein kognitiv - das macht technische Kommunikation oft sehr schwierig - wenn man nicht nurn bissle SQL und GUIs macht (da ist es oft einfach nicht so relevant)
cppbert schrieb: > und welche Gemeinsamkeit haben Zeiger und goto? Nicht unbedingt für JavaScript-Gurus verständlich.
Das einzige, was mich an async in den meisten Sprachen stört, ist, dass man async Funktionen explizit als solche markieren muss. Das erschwert es dann, sync und async effektiv zu kombinieren. Dann muss man sehen, macht man alle Funktionen async, die eine Funktion mit io beinhalten könnte, dass man mit einem await später auf sie warten kann, oder wartet man halt synchron auf das io, oder splittet man es anderweitig weiter auf und speichert die Futures in irgend einer Queue oder so. Wenn man einfach sagen könnte, mach das zeug jetzt Asynchron, ohne alle Funktionen dazwischen async zu machen, das wäre cool... Ich glaube zig macht das anders / so ähnlich, muss ich mir nochmal ansehen. Wobei, vermutlich ist deren Method auch nicht wirklich besser / hat auch Problemchen.
cppbert schrieb: > viele stapeln gerne klein - nicht weil das so richtig ist sondern weil > sie gar nicht anders können - rein kognitiv Nein, die haben einfach mehr Erfahrung. Wenn ein Programm, in seiner Gesamtheit, nicht einfach verständlich ist, ist es nicht gut wartbar. Viele vergessen ihre geniale Lösung auch selbst gerne. Nö, gute Programme sind nie Komplex, gute Programme sind simpel. Und man muss kein Genie sein, um komplexen Mist zu verzapfen. Wirkliche Erfahrung, wahres Können, braucht man, um auf die einfachen Lösungen zu kommen. Meistens sind das auch die besten.
rbx schrieb: > cppbert schrieb: >> und welche Gemeinsamkeit haben Zeiger und goto? > > Nicht unbedingt für JavaScript-Gurus verständlich. für niemanden verständlich was du damit sagen wolltest den Rest der Fragen einfach mal ignoriert?
DPA schrieb: > cppbert schrieb: >> viele stapeln gerne klein - nicht weil das so richtig ist sondern weil >> sie gar nicht anders können - rein kognitiv > > Nein, die haben einfach mehr Erfahrung. Wenn ein Programm, in seiner > Gesamtheit, nicht einfach verständlich ist, ist es nicht gut wartbar. selbst gute wartbarkeite ist Ansichtssache - es gibt sogar Leute die viele Funktionen vermeiden weil sie die Zerlegung von Algorithmen als zu kompliziert empfinden > Viele vergessen ihre geniale Lösung auch selbst gerne. Nö, gute > Programme sind nie Komplex, gute Programme sind simpel. Und man muss > kein Genie sein, um komplexen Mist zu verzapfen. Wirkliche Erfahrung, > wahres Können, braucht man, um auf die einfachen Lösungen zu kommen. > Meistens sind das auch die besten. 100% ACK - aber ob man das wirklich gut kann merkt man erst wenn man mal mehrfach verantworlich war ein paar 100k Zeilen Code zu erschaffen und wartbar zu halten - zusammen mit x Entwicklern - alles andere bleibt irgendwie einfach, lokal, der eigene Mist oder wir reden eben von lokaler Algorithmik - die ist ist wenigstens ungefährlich weil von ihrer Art her einfach gut zu entkoppeln, auch wenn der 1., 2. und dritte Versuch Müll war kann man das gut und schnell bereinigen, architektonische Fehler, Designschwächen die Skalierungsprobleme verursachen sind viel schlimmer zu beheben, aber das machen eh nur die wenigsten
und dann noch die vielen Entwickler die es nicht mal gebacken bekommen wengstens die rudimentärste Entkopplung ihres Code zu schaffen um Unit-testbar zu sein(oder zu bleiben) und wenn sie von Design sprechen vornehmlich die Anordnung von if und else meinen :)
DPA schrieb: > Wenn man einfach sagen könnte, mach das zeug jetzt Asynchron, ohne alle > Funktionen dazwischen async zu machen, das wäre cool... Ich wüsste nicht, wie das gehen soll. Wenn Unterfunktionen asynchron sind, dann werden die aufrufenden Funktionen natürlich auch automatisch asynchron. Und deshalb muss man sie dann als solche markieren. Denn sonst wäre bei deren Aufruf nicht klar, ob man sie synchron oder asynchron aufrufen muss.
MaWin schrieb: > Ich wüsste nicht, wie das gehen soll. > Wenn Unterfunktionen asynchron sind, dann werden die aufrufenden > Funktionen natürlich auch automatisch asynchron. Allgemein gesprochen, unabhängig von realen Programmiersprachen, stimmt das so nicht ganz. Die Async-Markierung bedeutet nur, dass die Funktion das Ergebnis nicht direkt zurück liefert, sondern (im Idealfall) sofort zurückkehrt und ein Future-Objekt, Promise, Task o.ä. zurück liefert. Die Programmiersprache bietet mit einer Async-Markierung natürlich noch zusätzlich irgendwelche Unterstützung, so dass man bestimmte Dinge nicht von Hand machen muss, und schränkt evtl. bestimmte Verwendung der Asnyc-Funktion ein. Aber rein prinzipiell könnte synchroner Code ein Future-Objekt pollen, und das Future-Objekt würde dann irgendwann sagen, dass das Ergebnis vorhanden ist. Dann könnte der synchrone Code das Ergebnis vom Future-Objekt abholen. Allerdings ist mir auf die Schnelle keine Programmiersprache bekannt, wo das so möglich ist. Das Problem dabei wäre nämlich, dass Async-Code natürlich normale Funktionen aufrufen könnte, der intern ein Polling von Async-Code macht, der wiederum normalen Code aufruft, der intern ein Polling von Async-Code macht, der wiederum.... Es ist klar, auf was das heraus laufen würde, oder?
Programmierer schrieb: > Aber rein prinzipiell könnte synchroner Code ein Future-Objekt pollen, > und das Future-Objekt würde dann irgendwann sagen, dass das Ergebnis > vorhanden ist. Dann könnte der synchrone Code das Ergebnis vom > Future-Objekt abholen. > > Allerdings ist mir auf die Schnelle keine Programmiersprache bekannt, wo > das so möglich ist. Das ist in Rust natürlich möglich. Man kann zum Beispiel mit cassette (https://crates.io/crates/cassette), einer minimalen async-Runtime, ohne Weiteres ein Future pollen. Das geht natürlich auch mit vielen anderen Runtimes, oder man kann es auch selbst implementieren. Aber so hatte ich die Anforderung von DPA nicht verstanden. Ich hatte es eher so verstanden, dass man normale Funktionen und async wild mischt und die Sprache das dann irgendwie auf magische Weise "richtig" machen soll. Das würde natürlich dazu führen, dass die Sprache selbstständig im Hintergrund async-Eventloops aufziehen muss. Niemand würde mehr durchblicken. Ich hätte vielleicht schreiben sollen: Ich wüsste nicht, wie das sinnvoll gehen soll. > Es ist klar, auf was das heraus laufen würde, oder? Eben. :) Ich wüsste nicht, wie das sinnvoll automatisch von der Sprache aus gehen soll. Zu Fuß implementieren kann man diesen Fall aber.
MaWin schrieb: > Programmierer schrieb: >> Aber rein prinzipiell könnte synchroner Code ein Future-Objekt pollen, >> und das Future-Objekt würde dann irgendwann sagen, dass das Ergebnis >> vorhanden ist. Dann könnte der synchrone Code das Ergebnis vom >> Future-Objekt abholen. So hatte ich das eigentlich nicht im sinn. Ich dachte das eher so, dass async & await quasi der default sind, und man explizit angeben muss, wenn man das furture Objekt will. Das ist stärker als immer sofort das Future-Objekt zu pollen, den dann kann man später immernoch mehrere Funktionen parallelisieren. Irgendwo müsste man immernoch synchron warten, was aber kein problem sein sollte, man kann ja einfach in einer tread lokalen Variable oder so speichern, ob das gerade das "oberste" await ist, oder nicht. Das alles liese sich sicher auch abi-massig transparent gestalten, braucht vermutlich nur ein wrapper symbol und ein paar andere Tricksereien, nur kenne ich leider auch noch keinen Weg, das ohne coroutinen oder heap allocations, also Zusatzkosten, zu machen, denn dann müsste man das ja so lösen, dass man die Limitationen von rekursiven aufrufen usw. nicht hat. Also ich weiss nicht, ob es einen Weg gibt, das beste aller Welten zu kriegen, aber wenn es irgendwie ginge, das so zu machen, das währe für mich quasi der Heilige Gral. Ich weiss, dass zig die Funktionen selbst nicht als async definiert, sondern man beim Aufruf angibt, ob man eine future will. Aber ich weiss nicht, ob die das so wie von Programmierer angegeben machen, oder so wie ich das gerne hätte. Das muss ich mir mal genauer ansehen.
MaWin schrieb: > Zu Fuß implementieren kann man diesen Fall aber. Überhaupt kommt man nicht umhin, selber Gehirnschmalz einzusetzen, und das nicht zu knapp. Das bringt die Parallel-Programmierung so mit sich. Hier und da kommt man in Bereiche, wo man meint, nö, ich habe echt keinen Bock mehr mich länger geistig so anzustrengen - man muss halt auch lange nachdenken, und hat dann diesbezüglich Ausdauerprobleme. Da freut man sich dann auch über gewisse, schon ganz gut ausgetretende Pfade. Manchmal ist es aber auch so, da kann man nach Workflows Ausschau halten oder nach einfachen Rezepten. Ich finde das Kochbuch von Rust gar nicht so schlecht. Ich erinnere mich an die JavaScript Tutorials von Netscape. Die waren auch echt nicht schlecht. Ähnlich gut erscheint Rust Eine wenig fühle ich mich bei der Diskussion auch an die Haskell Monaden erinnert. Man könnte ja meinen, man muss erst ein Mathestudium abschließen, um Monaden sinnvoll verarbeiten zu können. Auswendiglernen der wichtigsten Handgriffe geht aber auch. Man muss halt nicht überall mitreden können. Auf Stackoverflow gab es eine nette Linkempfehlung zu Rust Async: https://ryhl.io/blog/async-what-is-blocking/ Für Komplexität gibt es zumindest noch eine bewährte Alternative zum Liegenlassen: schrittweise herangehen.
Beitrag #7136148 wurde von einem Moderator gelöscht.
Beitrag #7136150 wurde von einem Moderator gelöscht.
Beitrag #7136151 wurde vom Autor gelöscht.
Beitrag #7136155 wurde von einem Moderator gelöscht.
Beitrag #7136157 wurde von einem Moderator gelöscht.
Beitrag #7136160 wurde von einem Moderator gelöscht.
Beitrag #7136164 wurde von einem Moderator gelöscht.
Beitrag #7136173 wurde von einem Moderator gelöscht.
Beitrag #7136176 wurde von einem Moderator gelöscht.
Beitrag #7136180 wurde von einem Moderator gelöscht.
Ach herrje... was nicht passt wird passend gemacht? Kritik unerwünscht!
XY M. schrieb: > Ach herrje... was nicht passt wird passend gemacht? > Kritik unerwünscht! Naja, 9 gelöschte Post sind auch hier jetzt nicht Standard, wohl ein wenig in der Wortwahl vergriffen derjenige
Version 1.63.0 ist raus: https://blog.rust-lang.org/2022/08/11/Rust-1.63.0.html - std::thread::scope: Sehr nützlich. Das vereinfacht die Threading-API noch einmal mehr, weil das join-handling automatisiert wird. Und es ermöglicht dem Compiler übergebene Referenzen statisch zu prüfen. Es gab schon crates, die das ermöglicht haben, aber nun ist es in der std-lib drin. - const Mutex init: Auch eine gute Vereinfachung der Mutex-API. Macht das externe crate lazy_static in vielen Fällen unnötig. Beide Änderungen führen zum Wegfall von diversen Runtime-Checks und erhöhen damit (minimal) die Performance.
Programmierer schrieb: > Die allermeisten Menschen möchte einfache, simple Erklärungen wie die > Welt funktioniert. Dann haben sie das Gefühl sie verstünden die Welt und > könnten sich ein Urteil bilden, eine Meinung haben und mitdiskutieren. Das hieße dann im Umkehrschluss, wer die Welt nicht in all ihrer Komplexität versteht sollte keine Meinung über sie haben und sich das mitdiskutieren ersparen. Dann sollte die Menschheit aber kollektiv das Schweigen lernen, denn KEINER aber absolut KEINER ist allein im Stande die Welt gänzlich zu verstehen, ob beim Klimawandel, bei der Verteilung von Reichtum und Armut oder den großen Fragen der Zukunft, wie die Menschheit künftig ihr Dasein gestalten soll, ohne dass es für ganze Landstriche ins Desaster führt (bzgl. Lebensqualität, Ressourcen, Bildungschancen etc.). > Komplexität schreckt die meisten Menschen ab. Die meisten Menschen brauchen die Komplexität vieler Hintergründe auch gar nicht en Detail zu verstehen, um damit umgehen zu können. Du musst nicht verstehen wie ein Otto-Motor genau funktioniert, um Auto fahren zu können. Du musst (um beim Thema anzuknüpfen) auch nicht genau verstehen wie ein Compiler funktioniert, um ein lauffähiges Programm zu schreiben. Es genügt zu wissen, wie man einen übersetzbaren Quelltext schreibt und wie man daraus ein startbares Programm übersetzt. Dazu gibt es Tools. > Darum wird Komplexität > verleugnet. Endstadium: Verschwörungstheorie. Das ist eine andere Schiene. Verschwörungstheorien bilden sich dort wo Menschen das Vertrauen in ihre (hoffentlich) demokratischen Institutionen verloren haben. Ich würde nicht pauschal unterstellen, dass dort immer alle unterkomplex denken (für einige mag das zutreffen, aber nicht für alle). Bei vielen ist es einfach die Angst vor zu starker Veränderung, die die Leute umtreibt, gepaart mit dem Unvermögen der uns regierenden die "Komplexität" auf verstehbare, vermittelbare Sätze herunterzubrechen, anstatt zu schweigen oder den Leuten das Gefühl zu vermitteln selber die Dinge nicht richtig zu verstehen und daraus fragwürdige Handlungen abzuleiten. Aber wie gesagt, das ist eine andere Schiene (politisch) und gehört nicht in diesen Thread. Ich hab mal gerade in ein Tutorial von Rust reingeschaut. Bis hierhin war's zumindest unterhaltsam ;). https://www.youtube.com/watch?v=xYgfW8cIbMA
Die Welt ist zweifelsohne komplex. Daran lässt sich nichts ändern. Die Komplexität der Bedienung von Technik oder Programmierwerkzeugen /sprachen liegt aber in menschlichen Händen. Daran lässt sich durchaus was ändern.
Next steps for Rust in the kernel https://lwn.net/Articles/908347/ Der Artikel ist leider noch sobscriber-only. Solange zitiere ich einmal hier den Kern: > At the 2022 Linux Kernel Maintainers Summit, Miguel Ojeda updated the group on the status of the project with the goal of reaching a conclusion on when this merge might happen. The answer that came back was clear enough: Rust in the kernel will be happening soon indeed. > There was little suspense on that front; Linus Torvalds spoke up at the beginning of the session to say that he plans to accept the Rust patches for the 6.1 kernel (likely to be released in mid-December) unless he hears strong objections. > There is currently an ongoing effort to write a specification for Rust for safety-critical systems that will lead to a standard-like document. At the moment, though, Ojeda said, the developers of the GCC-based gccrs Rust compiler are finding the current documentation to be vague at times. Often, behavior is specified as "whatever the rustc compiler does". That is "not good", he said, but there is a path forward. > It has often been said that the merging of Rust into the kernel tree will be done on an experimental basis; if it doesn't work out, it can be removed again. > Torvalds added that Rust isn't that terrible in the end; "it's not Perl".
Ich hoffe die bekommen das "Pinning" Problem gut gelöst - oder ist das schon (sauber) vom Tisch? https://news.ycombinator.com/item?id=32864598 https://lwn.net/SubscriberLink/907876/ac0afc756df0ec71/ Ich finde es sehr gut das Rust jetzt vielleicht (zu)schnell in den Kernel kommt weil dann ein grosser Zwang besteht bestehende Probleme/Schwächen im Grossen Kreis zu klären mehr Szenarien = mehr Möglichkeit an Schwächen zu arbeiten
cppbert schrieb: > Ich hoffe die bekommen das "Pinning" Problem gut gelöst - oder ist > das > schon (sauber) vom Tisch? Gelöst ist das nicht. Aber es bedeutet lediglich, dass es derzeit ein paar mehr unsafe-Blöcke an den Schnittstellen zur C-Welt gibt. Oder an den wenigen Stellen, wo ein memcpy nicht wegoptimiert werden kann und dieses memcpy zu viele Schmerzen bereitet. Das Problem ist auch nicht, dass das im Einzelfall nicht immer lösbar wäre. Aber es gibt derzeit nicht eine wirklich saubere Universallösung für alle Fälle. (Wobei ich diese Procmakro-Lösung eigentlich gar nicht so schlecht finde. Da gibt es im Rust-Universum deutlich hässlichere Procmakros.)
Beitrag #7200277 wurde von einem Moderator gelöscht.
Volvo bringt Rust in die Auto-Software Das Rust-Team bei Volvo will die Nutzung der Sprache in der Auto-Software deutlich ausweiten. Bis hin zu sicherheitskritischen Anwendungen. https://www.golem.de/news/programmierung-volvo-bringt-rust-in-die-auto-software-2209-168520.html
Auch wenn die Diskussionen mit Linus wie üblich etwas harsch wirken finde ich es super das sich die Rust Leute (der kleine Teil der Community der sich damit bisher beschäftigt) jetzt den Anforderungen eines Mainstream Kernels aussetzen https://lkml.org/lkml/2022/9/19/1250 Egal wie die Integration verläuft sind das alles wichtige Impulse für die Sprachentwicklung
Muss man dann eigentlich Rust zum Kompilieren des Kernels haben, oder kann man all das Rust Zeugs auch in der config abwählen?
🐧 DPA 🐧 schrieb: > Muss man dann eigentlich Rust zum Kompilieren des Kernels haben, > oder > kann man all das Rust Zeugs auch in der config abwählen? ich denke nicht das die Kernel-Entwickler Rust gleich für alle Entwickler Zwangsausrollen werden, es wird bestimt modulorientiert sein - sonst das wäre ja totales Chaos bei >3000 aktiven Entwicklern
Nun ist es soweit. Die Rusthasser müssen sich nach einem alternativen Betriebssystem umsehen. https://lwn.net/Articles/910762/ There have been a lot of significant changes merged into the mainline for the 6.1 release, but one of the changes that has received the most attention will also have the least short-term effect for users of the kernel: the introduction of support for the Rust programming language. No system with a production 6.1 kernel will be running any Rust code, but this change does give kernel developers a chance to play with the language in the kernel context and get a sense for how Rust development feels. Perhaps the most likely conclusion for most developers, though, will be that there isn't yet enough Rust in the kernel to do much of anything interesting.
Am Anfang stehen und schon Feiern? Schauen wir mal, was aus Linux in ein paar Jahren geworden ist. Ob Rust dann immer noch drin ist, ob Linux noch lebt, etc. Da kann viel passieren.
🐧 DPA 🐧 schrieb: > ob Linux noch lebt, etc. Da kann viel passieren. Dein Getrolle war auch schon einmal besser. Gib dir bitte wieder mehr Mühe!
Moin, <heisemode>Juhuu, das ist das Ende von Linux</heisemode> scnr, WK
Ich würde ja eher sagen: Schauen wir mal, wieviel Rust in ein paar Jahren real im Kernel drin ist. Wenn sich das auf ein paar Treiber weniger Firmen beschränkt, dann war's viel Hype um nichts.
🐧 DPA 🐧 schrieb: > Am Anfang stehen und schon Feiern? Schauen wir mal, was aus Linux > in ein > paar Jahren geworden ist. Ob Rust dann immer noch drin ist, ob Linux > noch lebt, etc. Da kann viel passieren. genau das ist doch das Ziel und auch die Strategie - einfach ausprobieren, wenn es nix ist kommt Rust ganz schnell wieder raus, was aber trotzdem kein scheitern der ganzen Sprache bedeutet, es hat ja auch keine anderen Sprache bisher im Kernel einzug gehalten und sollte Rust dem Kernel erhalten bleiben und die Modul-Anzahl wachsen wird es immer noch genau so viele Leute im Internet geben die das alles nicht gut finden, selbst wenn alle Top-Kernel Entwickler sagen das ist die geilste Scheisse ever, hat das auch keine Relevanz - also schauen wir einfach ob es was wird und Rust an der Kernel-Herausforderung wächst oder scheitert
Hier der Teil der Key-Note mit Linus wo er über die Rust Integration spricht: https://www.youtube.com/watch?v=sLimmpZWRNI&t=1144s nicht ganz super ernsthaft aber pragmatisch - es wird auch kurz über die clang/LLVM abhängigkeit gesprochen, 1min nach Start
und über die Ängste die mit der Einführung einer neuen Sprache einhergehen und auch das wenn es schief geht das es eben schamvoll entfernt werden wird... aber ich hab wirklich selten Linus so euphorisch(für seine Verhältnisse) über eine Programmiersprache sprechen hören - er freut sich darauf die Rust-Syntax zu lernen Es wird die härteste und beste Herausforderung für Rust - wir werden sehen wie es sich schlägt und die harsch Linus damit umgehen wird
S. R. schrieb: > Ich würde ja eher sagen: Schauen wir mal, wieviel Rust in ein paar > Jahren real im Kernel drin ist. Wenn sich das auf ein paar Treiber > weniger Firmen beschränkt, dann war's viel Hype um nichts. Man könnte schon fast eine Vorhersage versuchen. Basierend auf: Berichte über Parallelitätsexpertise in den 50er und 60er Jahren:(sehr interessant) "Funktionale Sprachen sind auch ein guter Ansatz" (aber nicht der bestimmende) Haskell Hyperei (was war da eigentlich los (so zwischen 2008 und 2012)?) C++ PDF zur Frage: C++ vs Haskell. Die Antwort war: wegen dem schwierigen Haskell Code lieber in C++ was machen. Aber der Haskell Code in dem Pdf war eher plakativ ausgesucht. Der Haskell-Code war nicht unbedingt schwierig, aber der sah stark danach aus, als wäre der das. Also eher kognitive Dissonanz (Ent-)Berieselung dabei. Dann noch: Frederik Vester (Lerntypen in "Denken, Lernen, Vergessen) und Israel Rosenfield ("Das Fremde, das Vertraute und das Vergessene") Der Text von dem Rosenfield ist extrem erhellend - nicht unbedingt hier zum Thema, aber zu Bewusstseinsfragen und Integration an sich. Dann noch ein wenig Chaosforschung. Aus diesen zusammengefasst: Immer vom Vertrauten zum Unvertrauten. Nicht umgekehrt. Verhältnis empfindlich. Nicht zuviel neues aufeinmal. BWL-Grundkurs geht auch noch: welche Alternativkosten? Die Programmierung mit "funktionalen Sprachen" ist sehr abstrakt, und deswegen braucht man länger als für C und für C wurden früher 5-10 Jahre angesetzt. Das ist heute bestimmt anders, aber C hat Abstaktionen, die muss man auch erstmal verarbeiten - das dauert erstmal - und funktionale Sprachen dauern da noch viel länger - ganz abgesehen von dem (oft fehlenden) Drumherum in Richtung der Hardwareschnittstelle. Wir haben dann: - funktionale Programmiersprache, nicht sonderlich gut bekannt. - recht anspruchsvoller, hoher Abstraktionsgrad (man braucht lange), gute Matheausbildung sicher auch nicht verkehrt. - (professionelle Bibliotheken?) - Parallelprogrammierung mit vielen Kernen: Schwierig. - Plotten geht mit (Hilfe von) Octave viel besser. - Pycuda-Math Nun ist aber Parallelprogrammierhilfe schon dringender nötig als früher. Und C++ ist auch ein ganz schön dicker Brocken geworden. Der gcc auch, und der raubt mir mit seinen Fehlermeldungen den letzten Nerv. Gute Zeiten für Python? Ich weiß gar nicht mehr, wann das war - als bei Cygwin ein Python-Packet mit dabei war. Es war aber ein "Issue" ob mit dabei oder nicht. Ist noch nicht so lange her, vielleicht 8-10 Jahre. Der Python-Einstieg ist mittlerweile ganz einfach in Linux, weil schon vorinstalliert - bzw. so ein wenig auf Basic-Spuren herumläuft. Über den Status "eine gute Idee" (wie in den 60ern) ist Rust sicher hinausgekommen. Aber wie weit? Linus hypt auch nur in dem Video oben. Allerdings ist der auch nicht irgendwer ;)
MaWin schrieb: > rbx schrieb: >> - Parallelprogrammierung mit vielen Kernen: Schwierig. > > Falsch. > In Rust sehr einfach. Danke für die "Optimierung" Ich hatte noch im Hinterkopf: Wenn man das alles in Assembler machen müsste bei den Cells (Playstation usw) geht das ja noch - aber bei 100 Threads? Da kann man dann eben schon für solche Entwicklungen wie Rust dankbar sein.
rbx schrieb: > Danke für die "Optimierung" > Ich hatte noch im Hinterkopf: Wenn man das alles in Assembler machen > müsste bei den Cells (Playstation usw) geht das ja noch - aber bei 100 > Threads? Da kann man dann eben schon für solche Entwicklungen wie Rust > dankbar sein. sorry rbx - aber, wie so oft habe ich keine Ahnung was du vermitteln willst was hat denn der 2006 Playstation3 Cell Chip hier für einen relevanz? In C/C++ mit >100 Threads rumspielen war schon vor >15 Jahren, auch unter Windows völlig "normal" und Rust hat nur die Sicherheit deren Nutzung erhöht ansonsten ist Multithreading definitiv schon lange nichts besonderes mehr
cppbert schrieb: > was hat denn der 2006 Playstation3 Cell Chip hier für einen relevanz? der wurde nicht per se mit Assembler programmiert sondern eher in C++ (mit Extensions) https://www.codeproject.com/Articles/23733/Parallel-programming-on-PlayStation-3-Cell-archite
cppbert schrieb: > In C/C++ mit >100 Threads rumspielen war schon vor >15 Jahren, auch > unter Windows völlig "normal" und Rust hat nur die Sicherheit deren > Nutzung erhöht ich hab 2001 an einem System mit einer schlechten Architektur gearbeitet das bei einem Volllauf Geräte in einer Chemie-Automation mit C++ gesteuert hat, Window 2000, Visual C++ 6, >400 Threads - weil jedes Gerät seinen eigenen Thread-Message-Queue hatte, war ineffizient aber damals auch kein Hexenwerk oder meinst du Auto-Vektorisierung/Parallelisierung und solche Sachen? dann musst du das aber auch deutlich sagen - alles andere ist sonst nur Buzzword-Geplapper
cppbert schrieb: > war ineffizient aber damals auch > kein Hexenwerk In dem c't - Jubiläumsheft 24/2008 gab es den Artikel "Playstation unportable". https://www.heise.de/select/ct/archiv/2008/24/seite-276 Das Ergebnis der Programmierübungen auf dem Schrankteil war, dass Assemblerprogrammierung (auf dieser Kiste) deutlich effizienter ist - und möglichst vorzuziehen. https://de.wikipedia.org/wiki/IBM_Roadrunner (Ob Assemblerprogrammierung hier eine Rolle spielt, weiß ich nicht - aber es hilft vielleicht, das Argument oben etwas einfacher einzusortieren.)
Wird Rust besser, wenn die Sprache im Linuxkernel benutzt wird? Mehr akzeptiert und mehr verbreitet - ja, aber mit Sicherheit nicht besser. Da muss man nur anschauen, was Linus von C erwartet hat und welche "features" er da haben wollte. (z.B. memcpy ganz durch memmove ersetzen und weiterer Blödsinn)
ein lupenreiner Demokrat schrieb: > Wird Rust besser, wenn die Sprache im Linuxkernel benutzt wird? Mehr > akzeptiert und mehr verbreitet - ja, aber mit Sicherheit nicht besser. Es soll wohl eher als Qualitätsmerkmal dienen: Wenn es nicht gut wäre, würde es im Kernel doch nicht verwendet werden. > Da muss man nur anschauen, was Linus von C erwartet hat und welche > "features" er da haben wollte. (z.B. memcpy ganz durch memmove ersetzen > und weiterer Blödsinn) Nachdem ich die Gründe, die er gegen C++ im Kernel vorgebracht hat, gelesen habe, kann ich ihn in der Hinsicht eh nicht mehr ernst nehmen.
ein lupenreiner Demokrat schrieb: > Wird Rust besser, wenn die Sprache im Linuxkernel benutzt wird? Mehr > akzeptiert und mehr verbreitet - ja, aber mit Sicherheit nicht besser. Selbstverständlich wird Rust dadurch besser, indem Features stabilisiert werden und neue für die OS-Entwicklung zwingend notwendige Features hinzugefügt werden. Es gibt auch eine Trackingliste für dies, falls es dich interessiert. Rolf M. schrieb: >> Da muss man nur anschauen, was Linus von C erwartet hat und welche >> "features" er da haben wollte. (z.B. memcpy ganz durch memmove ersetzen >> und weiterer Blödsinn) > > Nachdem ich die Gründe, die er gegen C++ im Kernel vorgebracht hat, > gelesen habe, kann ich ihn in der Hinsicht eh nicht mehr ernst nehmen. Wie wäre es denn, wenn ihr Argumente vorbringt, statt beleidigt zu sein und alles als Blödsinn zu bezeichnen? Ich weiß, das ist unüblich hier im Forum.
MaWin schrieb: > Wie wäre es denn, wenn ihr Argumente vorbringt, statt beleidigt zu sein > und alles als Blödsinn zu bezeichnen? > Ich weiß, das ist unüblich hier im Forum. Frei nach Nietzsche: "Gegen Rust hat man keine Argumente, man hat /dev/null".
MaWin schrieb: > Rolf M. schrieb: >>> Da muss man nur anschauen, was Linus von C erwartet hat und welche >>> "features" er da haben wollte. (z.B. memcpy ganz durch memmove ersetzen >>> und weiterer Blödsinn) >> >> Nachdem ich die Gründe, die er gegen C++ im Kernel vorgebracht hat, >> gelesen habe, kann ich ihn in der Hinsicht eh nicht mehr ernst nehmen. > > Wie wäre es denn, wenn ihr Argumente vorbringt, statt beleidigt zu sein > und alles als Blödsinn zu bezeichnen? Warum sollte ich beleidigt sein? Ich bin lediglich der Ansicht, dass seine Argumente gegen C++ ziemlich an den Haaren herbeigezogen wirken. Er ist ja nun durchaus auch bekannt dafür, sich manchmal etwas zu sehr von Emotionen treiben zu lassen. Deshalb bin ich bei manchen Aussagen von ihm etwas vorsichtig.
Rolf M. schrieb: > Warum sollte ich beleidigt sein? Ich bin lediglich der Ansicht, dass > seine Argumente gegen C++ ziemlich an den Haaren herbeigezogen wirken. Weil...? Du lieferst wieder keine Argumente und stattdessen nur Emotion. Und dann kritisierst du genau das an Linus. So trägst du nichts zur Diskussion bei, außer dass ich nun weiß, dass du wohl aus unbekannten Gründen gerne C++ im Kernel hättest und irgendwie memcpy besser als memmove findest. Das ist für mich eine nutzlose Information, solange du das nicht begründest. Verstehst du jetzt das Problem?
MaWin schrieb: > Das ist für mich eine nutzlose Information, solange du das nicht > begründest. Warum memcpy() und memmove() zwei getrennte Funktionen sind, sollte eigentlich sonnenklar sein: wenn der Programmierer bereits weiß, dass es keine Überlappung geben kann, kann man sich die Umständlichkeit eines memmove() schlicht sparen. Und in sehr, sehr vielen Fällen weiß er das. Außerdem ist der C-Standard eh sehr, sehr zurückhaltend mit dem Entfernen alter Funktionen, daran wird auch ein Herr Torvalds nichts ändern. Der einzige Fall, der mir gerade in den Sinn kommt, dürfte gets() sein – aus gutem Grund, aber auch nur nach einer sehr langen Phase der deprecation (der eigentlich eine noch längere Phase vorangegangen ist, in denen so ziemlich jeder davor gewarnt hat, die Funktion überhaupt zu benutzen).
:
Bearbeitet durch Moderator
Naja, memmove hat doch auch seine Grenzen, wo heutzutage ein Buffer ja mehrfach gemappt sein kann. Mappe ich die selbe Page auf 1000 und 2000, und mache dann z.B. ein memmove von 20 bytes von 2000 nach 1010, müsste man das wie ein memmove von 1000 nach 1010 behandeln, aber memmove wird nichts von dem Mapping wissen, und 1000 < 1010 aber 2000 > 1010, und peng. Ich könnte mir gut vorstellen, das man da in einem Kernel mehr aufpassen muss, und memmove dann eher dazu führen könnte, das man sich in falscher Sicherheit wiegt, wenn man eigentlich hätte checken müssen, was da physisch gemappt war. Ist aber nur reine Spekulation.
Jörg W. schrieb: > Warum memcpy() und memmove() zwei getrennte Funktionen sind, sollte > eigentlich sonnenklar sein: wenn der Programmierer bereits weiß, dass es > keine Überlappung geben kann, kann man sich die Umständlichkeit eines > memmove() schlicht sparen. Und in sehr, sehr vielen Fällen weiß er das. das weiß hier jeder, auch MaWin aber warum Linus dann memmove semantic in memcpy fordert ist komisch weil nicht so optimierbar/schnell ist - einfach nur weil damit mehr Probleme per se kompensiert werden?
Jörg W. schrieb: > Warum memcpy() und memmove() zwei getrennte Funktionen sind, sollte > eigentlich sonnenklar sein: wenn der Programmierer bereits weiß, dass es > keine Überlappung geben kann, kann man sich die Umständlichkeit eines > memmove() schlicht sparen. Und in sehr, sehr vielen Fällen weiß er das. Ich weiß was memcpy und memmove sind. Darum ging es nicht. Lies bitte worauf du antwortest auch einmal durch. > Außerdem ist der C-Standard eh sehr, sehr zurückhaltend mit dem > Entfernen alter Funktionen, daran wird auch ein Herr Torvalds nichts > ändern. Ehm. doch. Der Kernel verwendet überhaupt keine stdlib.
Ich kann ja mal ein Argument liefern: Die Diskussion memcpy vs. memmove ist ein Argument für Rust. Denn in Rust können Speicherbereiche niemals überlappen und gleichzeitig drauf zugegriffen werden. Deshalb kann der Compiler alles mit memcpy kopieren. Der Programmierer braucht sich darüber gar keine Gedanken zu machen.
MaWin schrieb: > Der Kernel verwendet überhaupt keine stdlib. Warum diskutiert Linus dann überhaupt über memmove() und memcpy()? Oder hat der Kernel vielleicht doch eine Standard(ähnliche) Bibliothek? Es ist doch völlig schnuppe, wer diese Bibliothek geschrieben hat. Entscheidend ist, ob sie die Funktionen (oder einige davon) des Standards bereitstellt. MaWin schrieb: > Denn in Rust können Speicherbereiche niemals überlappen und gleichzeitig > drauf zugegriffen werden. 🐧 DPA 🐧 schrieb: > Naja, memmove hat doch auch seine Grenzen, wo heutzutage ein Buffer ja > mehrfach gemappt sein kann. Yup … daran wird vermutlich auch Rust nicht viel ändern können.
Jörg W. schrieb: > Yup … daran wird vermutlich auch Rust nicht viel ändern können. Da liegst du leider komplett falsch mit deiner Vermutung. Mehrfaches Mapping und gleichzeitiger Zugriff ist nicht möglich in Rust. Aliasing ist auch nicht möglich in Rust. Rust forciert, dass die Teilnehmer sich synchronisieren. Also das, was man in C auch machen muss um ein korrektes Programm zu bekommen. Ich würde vorschlagen, dass du vielleicht erst einmal die Grundlagen von Rust lernst. Das macht auch ziemlich viel Spaß.
MaWin schrieb: > Mehrfaches Mapping und gleichzeitiger Zugriff ist nicht möglich in Rust. Es ging mir (und DPA) nicht um irgendwelche Elemente einer Sprache, sondern um das VM Mapping der CPU. Damit kann man immer Aliase erzeugen, denn dieses Konstrukt ist vollständig außerhalb des Einflussbereichs irgendeiner Programmiersprache. Dementsprechend kann man, wenn man an der Stelle nicht sauber drauf achtet, sowohl die Eigentümerschafts-Annahmen von Rust gefährden genauso wie halt (das war das ursprüngliche Argument) Annahmen, die eine memmove()-Implementierung intern trifft.
Jörg W. schrieb: > Dementsprechend kann > man, wenn man an der Stelle nicht sauber drauf achtet, sowohl die > Eigentümerschafts-Annahmen von Rust gefährden Im Rust Code muss man auf überhaupt nicht darauf achten. Dass man das System außerhalb von Rust so einstellen und betreiben muss, dass die Anforderungen von Rust eingehalten werden, sollte selbstverständlich sein. Das gilt auch für C. Wenn die Hardware sich nicht ans Maschinenmodell der jeweiligen Sprache hält, dann ist das natürlich ein Bug. Fakt ist und bleibt, dass die Überlegung memcpy vs. memmove in Rust nicht existiert. Aber ich weiß jetzt nicht, worauf du hinaus willst. Zur Erinnerung: Es ging hier nicht um die Technik hinter memcpy/memmove, sondern um die politischen Entscheidungen von Linus. Es wurde kritisiert, dass Linus angeblich memmove statt memcpy generell bevorzugt und die Forumsteilnehmer hier das für Blödsinn halten. Eine Begründung gab es leider nicht.
cppbert schrieb: > aber warum Linus dann memmove semantic in memcpy fordert ist komisch > weil nicht so optimierbar/schnell ist - einfach nur weil damit mehr > Probleme per se kompensiert werden? Außerhalb einer sehr überschaubaren Nerd-Blase, juckt es doch wirklich niemanden was Linus zum Thema C sagt oder meint.
MaWin schrieb: > Eine Begründung gab es leider nicht. Genauer gesagt: Begründungen interessieren dich nicht. Lassen wir das, hat mit Rust eh nichts zu tun.
Cyblord -. schrieb: > Außerhalb einer sehr überschaubaren Nerd-Blase, juckt es doch wirklich > niemanden was Linus zum Thema C sagt oder meint. Wieder ein Beitrag ohne Inhalt und Argument.
Jörg W. schrieb: > Genauer gesagt: Begründungen interessieren dich nicht. Bitte was? Herr Moderator, warum greifen sie mich nun persönlich an? Wo soll diese Begründung denn gewesen sein? Zitat bitte!
MaWin schrieb: > Wo soll diese Begründung denn gewesen sein? Zitat bitte! Ich dachte, du wüsstest den Unterschied zwischen beiden? Die Performance. Sicher nicht auf jeder Architektur gleichermaßen. Aber wie du schon festgestellt hast, hat das mit Rust eh nichts zu tun, weil dieses durch seine Eigentümerschaft so eine Unterscheidung nicht benötigt.
Der Kernel managt auch Userspace Ressourcen. Und Userspace kann nun mal Speicher mehrfach mappen. Vermutlich wird das kein all zu grosses Problem sein, aber in gewissen Situationen wird man da sicher auch in Rust die Checks nicht vergessen dürfen, die man momentan noch in C macht, oder anderweitig abstrahieren. Wobei man da bei der UAPI etwas eingeschränkt ist, die soll nämlich stabil bleiben. Kommt halt drauf an, wo und in wie weit es später eingesetzt werden wird, ob man sich da noch damit auseinander setzen wird.
Jörg W. schrieb: > Ich dachte, du wüsstest den Unterschied zwischen beiden? Die > Performance Ach komm. Du trollst doch. Noch einmal extra für dich: Es ging nicht um die Technik hinter memcpy/memmove. Es ging um den politischen Umgang von Linus damit und um die Einschätzung dieses Umgangs als Blödsinn.
🐧 DPA 🐧 schrieb: > Der Kernel managt auch Userspace Ressourcen. Und Userspace kann > nun mal > Speicher mehrfach mappen. Es ist auch in C überhaupt nicht vorgesehen direkt auf Userspace-Speicher zuzugreifen. Das führt im besten Fall zu einem Crash. Im schlimmsten Fall funktioniert es manchmal und führt dann zu Securityproblemen. In Rust ist es gar nicht möglich solche verbotenen Aktionen zu programmieren. > Vermutlich wird das kein all zu grosses > Problem sein, aber in gewissen Situationen wird man da sicher auch in > Rust die Checks nicht vergessen dürfen Nein. Man kann sie nicht vergessen. Das ist der entscheidende Unterschied. Man kann in Rust kein funktionierendes Programm schreiben, das Speicherfehler hat. Solche Programme kompilieren schon zu 90% gar nicht erst. Und das gilt auch für Kernelcode.
Jörg W. schrieb: > Ich dachte, du wüsstest den Unterschied zwischen beiden? Die > Performance. Sicher nicht auf jeder Architektur gleichermaßen. Außerdem arbeitet memmove auf einem temporären Speicherblock. Das ist ein riesen Unterschied zu memcpy. Gerade auf kleinen und sehr kleinen Controllern. Das ist auch so ein Umstand den die Rust-Boys immer so gerne vergessen: Was für den PC gut ist, kann für den kleinen Controller katastrophal sein. Die ganzen Sicherheitsfeatures kommen mit einem Preisschild. Die sind nicht umsonst.
:
Bearbeitet durch User
MaWin O. schrieb: > Nein. Man kann sie nicht vergessen. Das ist der entscheidende > Unterschied. Man kann in Rust kein funktionierendes Programm schreiben, > das Speicherfehler hat. Solche Programme kompilieren schon zu 90% gar > nicht erst. Erklär mal bitte grob wie der Compiler erkennt, wenn jemand zur Laufzeit (z.B. sagen wir mal per UART), entscheidet, er möchte nun 50 Byte senden, mein Programm die 50 Bytes allokiert und dann aber 51 Byte rein schreibt. Ich meine, klar, teure Checks zur Laufzeit, inkl. die dafür notwendigen Strukturen für die Arraygrößen usw. kann man haben. Will man nur im Embedded Umfeld so gut wie nicht. Aber zur Kompilierzeit? Geht halt nicht. Daher ist das alles Geschwurbel. Mit religiösem Eifer vorgetragen. Da können die Zeugen Jehovas noch was von lernen.
Cyblord -. schrieb: > Das ist > ein riesen Unterschied zu memcpy. Gerade auf kleinen und sehr kleinen > Controllern. Genau. Zum Glück kann man in Rust ja immer memcpy nutzen, weil es kein Aliasing gibt. Man hat also immer den Performancevorteil. > Das ist auch so ein Umstand den die Rust-Boys immer so > gerne vergessen: Was für den PC gut ist, kann für den kleinen Controller > katastrophal sein. Merkste selbst, gell? > Die ganzen Sicherheitsfeatures kommen mit einem > Preisschild. Die allermeisten Sicherheitsfeatures von Rust sind zero cost. Und die wenigen übrigen sind mit sehr sehr geringen Runtimekosten verbunden. Im Vergleich zwischen zwischen einem korrekten C/C++ Programm (also mit notwendigen Sicherheitschecks) und einem Rust-Programm ist die Performance identisch.
MaWin O. schrieb: > Nein. Man kann sie nicht vergessen. Das ist der entscheidende > Unterschied. Man kann in Rust kein funktionierendes Programm schreiben, > das Speicherfehler hat. Garantien basieren immer auf Annahmen. Solange diese alle erfüllt sind, ist alles gut. Sobald das nicht mehr der Fall ist, hat man Probleme. Wie bei meinem memmove Beispiel oben. Das ist ein wichtiger Teil davon, wie man Sicherheitslücken findet. Und im Kernel wird man auch für solche Spezialfälle die Augen offen halten müssen. Ein "kann eh nicht passieren", funktioniert nicht besonders gut um mögliche Probleme zu finden.
Cyblord -. schrieb: > Aber zur Kompilierzeit? Geht halt nicht. Das hat niemand jemals behauptet. In Rust wird die immer notwendige Laufzeitprüfung lediglich von der Sprache forciert. Das Endergebnis ist das gleiche, wenn man die notwendige Abfrage in C nicht vergisst. > Mit religiösem Eifer vorgetragen. Sehe ich genau so.
🐧 DPA 🐧 schrieb: > Ein "kann eh nicht passieren", funktioniert nicht besonders gut > um mögliche Probleme zu finden. Wenn etwas nicht passieren kann, weil die Randbedingungen es forcieren, dann kann es auch keine Probleme geben. Einfache Logik.
MaWin O. schrieb: >> Aber zur Kompilierzeit? Geht halt nicht. > > Das hat niemand jemals behauptet. Ach nicht? > Solche Programme kompilieren schon zu 90% gar > nicht erst. > In Rust wird die immer notwendige Laufzeitprüfung lediglich von der > Sprache forciert. Das Endergebnis ist das gleiche, wenn man die > notwendige Abfrage in C nicht vergisst. In C implementiert aber normalerweise niemand Laufzeitchecks für JEDEN Zugriff. Genau das bräuchtest du aber um 100% Sicherheit zu haben. Du musst bei JEDEM Zugriff auf das Array, egal ob lesend oder schreibend, Code ablaufen lassen. Dazu brauchst du Speicher wo die Informationen zu jedem Array drin stehen. Dieser Code prüft dann für JEDEN ZUGRIFF ob der innerhalb der Grenzen stattfindet. Vergleiche das mal mit einem data[55]=x und dann erzähle nochmal was von Zero-Cost.
Die Randbedingungen sind in dem Fall die Annahmen, die man sicherstellen muss. Genau da muss man hinsehen. Genau das ist es ja.
Cyblord -. schrieb: > In C implementiert aber normalerweise niemand Laufzeitchecks für JEDEN > Zugriff. Nein. Das ist Unsinn. Man braucht genau einen einzigen Check ganz am Anfang der Verarbeitungskette. Genau wie in C auch. Unnötige Checks fügt der Compiler nicht ein. Und wenn der Compiler die nicht-Notwendigkeit nicht beweisen kann, dann hat man halt einen zusätzlichen Check. Das ist absolut vernachlässigbar. Viele Performancemessungen zeigen genau das. Du hängst dich hier an einem Detail auf. Wenn du wirklich irgendeine Stelle findest, bei der dieser eine Maschinenzyklus dich wirklich stört, kannst du an dieser einen Stelle ja gerne unsafe-Rust verwenden. Der Rest des Programms bleibt trotzdem safe. Im Gegensatz zu einem C-Programm, wo alles unsafe ist. Moderne Compiler sind etwas schlauer als dein K&R-Compiler. Stichwort LTO.
🐧 DPA 🐧 schrieb: > Die Randbedingungen sind in dem Fall die Annahmen, die man > sicherstellen > muss. Genau da muss man hinsehen. Genau das ist es ja. Ja. Die muss man sicherstellen. Und in C muss man zusätzlich noch jede einzelne Zeile auf UB kontrollieren und Sicherstellen, dass kein UB auftritt.
MaWin O. schrieb: > Nein. Das ist Unsinn. > Man braucht genau einen einzigen Check ganz am Anfang der > Verarbeitungskette. Wie soll das gehen? Und was ist eine Verarbeitungskette? Es geht um einen Zugriff auf ein Element in einem Array. > Du hängst dich hier an einem Detail auf. Nö ich hänge mich an der Aussage auf, dass Rust auf magische und kostenlose weise alles mögliche prüfen kann. Dass es allein durch die Sprache selbst sicher wird. Meist zur Kompilierzeit und wenn dann mit quasi null kosten zur Laufzeit. Das ist deine Grundaussage zu Rust. Kein Detail. Und da hätte ich halt mal gerne zu einem konkreten Beispiel eine Aussage wie Rust das machen will. > Wenn du wirklich irgendeine Stelle findest, bei der dieser eine > Maschinenzyklus dich wirklich stört, Du prüfst Array Zugriffe mit EINEM Maschinenzyklus? Rust ist echt der Hammer.
:
Bearbeitet durch User
Cyblord -. schrieb: > Wie soll das gehen? Und was ist eine Verarbeitungskette? Es geht um > einen Zugriff auf ein Element in einem Array. LTO + moderner Compiler. > Nö ich hänge mich an der Aussage auf, dass Rust auf magische und > kostenlose weise alles mögliche prüfen kann. Magie ist unbeteiligt.
MaWin O. schrieb: > Cyblord -. schrieb: >> Wie soll das gehen? Und was ist eine Verarbeitungskette? Es geht um >> einen Zugriff auf ein Element in einem Array. > > LTO + moderner Compiler. Ach so. Dann sind meine Fragen natürlich beantwortet. Danke.
@Cyblord Es geht MaWin nicht um Fremdeinflüsse die im Kernel durch Hardware und User-Space auftauchen können - die sind ja nicht Teil von einem sicherem Rust Code daher muss man dort genau so wie in C vorsichtig sein - aber diese Vorsicht ist so gut wie nicht nötig wenn du dich dann irgendwann in safem Rust-Code befindest (also weiter drinnen) - dann sorgt der Kompiler für dich - so lange du nicht wieder an solche Grenzen zur Hardware/User-Space kommst Es ist mir unverständlich wie man nur im entferntesten, als erfahrerener Entwickler glauben kann das ein andere Entwickler meinen könnte das es da irgendwie eine Magische-Hochperformante Sicherungsschicht geben kann - keine Sprache der Welt kann das und das hat hier auch noch nie irgendjemand (auch nicht MaWin) behauptet - es wird immer nur sehr intensiv so rausinterpretiert weil der andere das ja nicht wirklich im Detail verstehen "kann"
cppbert schrieb: > Es geht MaWin nicht um Fremdeinflüsse die im Kernel durch Hardware und > User-Space auftauchen können - die sind ja nicht Teil von einem sicherem > Rust Code daher muss man dort genau so wie in C vorsichtig sein - aber > diese Vorsicht ist so gut wie nicht nötig wenn du dich dann irgendwann > in safem Rust-Code befindest (also weiter drinnen) - dann sorgt der > Kompiler für dich - so lange du nicht wieder an solche Grenzen zur > Hardware/User-Space kommst Ach so na klar. Also der Benefit ist ein total sicherer Kernel. Der natürlich auch nicht nach außen mit irgendwas reden darf, damit man den Safe-Space nicht verlässt. Dann aber, dann kommt Rust voll zur Geltung. Natürlich nicht User Space. Die Applikation juckt ja nicht. Das mag ja im Bereich Linux-PC-Programmierung für irgendwen ein Benefit darstellen. Wer weiß, es soll solche Leute geben. Aber wenn man in Richtung Embedded und Mikrocontroller absteigt, findet man immer weniger Kernel und immer mehr Applikation. Und dann stellt sich, mal wieder, die Frage, warum soll man hier nun Rust nehmen? Können wir also im Protokoll festhalten dass Rust im Bereich Embedded nichts bringt? Sondern vor allem im Bereich Linux-Kernel-Nerdistan.
:
Bearbeitet durch User
cppbert schrieb: > Es geht MaWin nicht um Fremdeinflüsse die im Kernel durch Hardware und > User-Space auftauchen können - die sind ja nicht Teil von einem sicherem > Rust Code daher muss man dort genau so wie in C vorsichtig sein - aber > diese Vorsicht ist so gut wie nicht nötig wenn du dich dann irgendwann > in safem Rust-Code befindest (also weiter drinnen) - dann sorgt der > Kompiler für dich - so lange du nicht wieder an solche Grenzen zur > Hardware/User-Space kommst Gut erklärt. Vielleicht versteht es nun jemand. :) Hinzu kommt noch: Diese "Sicherheitsschichten" sind mit Hilfe von unsafe-Rust implementiert und in der Regel sehr sehr dünn. Meistens sogar zero-cost. Weil die meisten der Abfragen, sodenn welche notwendig sind, im C Code eh schon vorhanden sein müssen. Es kommen nur äußerst selten zusätzliche Lauzzeitabfragen rein. Und falls Cyblord jetzt doch die eine hochkritische Stelle in seinem Rustcode findet, wo eine Abfrage unnötigerweise generiert wird und es wirklich wehtut, dann kann er genau an dieser Stelle selbstverständlich eigenverantwortlich einen unchecked-Zugriff in unsafe-Rust machen. Gar kein Problem und auch völlig legitim. Damit ist diese eine Stelle performancemäßig entschärft und sämtliche andere Safetyprüfungen werden weiterhin alle durchgeführt. Auch für diesen einen unchecked-Zugriff. z.B. der Borrow-checker ist weiterhin aktiv. Der komplette restliche Rustcode ist unbeeinflusst.
Cyblord -. schrieb: > Aber wenn man in Richtung Embedded und Mikrocontroller absteigt, findet > man immer weniger Kernel und immer mehr Applikation. Und dann stellt > sich, mal wieder, die Frage, warum soll man hier nun Rust nehmen? Weil man heute ein sicheres und performantes Embedded-Programm komplett in Safe-Rust schreiben kann. Stand der Technik heute auf ESP32 und vielen weiteren gängigen Controllern. Das alles mit äußerst geringem Overhead. Nur so als Beispiel: Das komplette Zugriffsmanagement auf die Peripherie ist zu 99.9% statisch geprüft. Es gibt lediglich eine einzige Laufzeitabfrage während der Initialisierung. Und wenn man wollte, könnte man die auch noch herausoperieren. Multicoreentwicklung auf embedded Hardware ist mit Rust sehr elegant und hat so gut wie keinen höheren Overhead als ein korrektes C-Programm hätte. Locks, IRQ-disable oder atomics braucht man in C auch. Probiere es doch einfach mal aus! > Können wir also im Protokoll festhalten dass Rust im Bereich Embedded > nichts bringt? Ungern. Denn es bringt, wie gesagt, enorme Vorteile. Cyblord -. schrieb: > klar. Also der Benefit ist ein total sicherer Kernel. Der > natürlich auch nicht nach außen mit irgendwas reden darf Das interpretiere ich natürlich nur als Trollversuch deinerseits.
MaWin O. schrieb: > Das alles mit äußerst geringem Overhead. Nur so als Beispiel: Das > komplette Zugriffsmanagement auf die Peripherie ist zu 99.9% statisch > geprüft. Kunststück. Das IST ja auch alles statisch. Fehlerhafte Zugriffe passieren aber, oh Wunder, im Speicher. Und meistens eben bei dynamischem Speicher. Das ist statische Zugriffe leicht prüfen kann, ist doch eine Binse.
:
Bearbeitet durch User
Cyblord -. schrieb: > Kunststück. Das IST ja auch alles statisch. Fehlerhafte Zugriffe > passieren aber, oh Wunder, im Speicher. Und meistens eben bei > dynamischem Speicher. Das ist statische Zugriffe leicht prüfen kann, ist > doch eine Binse. Ach. Eben hast du noch gesagt, dass Rust ein enormes Problem auf Embedded hat. Jetzt erkennst du, dass genau das Gegenteil der Fall ist. Gut, dass auch du Erkenntnis erlangen kannst. Dynamischen Speicher kann Rust übrigens auch zum allergrößten Teil statisch prüfen. Lediglich dynamische Arrays nicht. Aber das kann C auch nicht.
MaWin O. schrieb: > Ach. Eben hast du noch gesagt, dass Rust ein enormes Problem auf > Embedded hat. Ja und ich habe ein KONKRETES Beispiel genannt wo ich das Problem sehe. Da bist du bisher nicht drauf eingegangen. Für statische Tests kann ich auch LINT nehmen. Da brauche ich keine neue Sprache. Deine Aussage war bisher dass Rust Code automatisch sicher ist. Jetzt lernen wir: Außer da eben da wo er nicht sicher ist. Also da wo ich nicht einfach statisch zur Kompilierzeit prüfen kann. Und deshalb machst du so ein Fass für Rust auf?
:
Bearbeitet durch User
Cyblord -. schrieb: > Ja und ich habe ein KONKRETES Beispiel genannt wo ich das Problem sehe. Ich sehe auch bei mehrmaligem Lesen kein konkretes Beispiel. Könntest du das noch einmal wiederholen, bitte? Cyblord -. schrieb: > Deine Aussage war bisher dass Rust Code automatisch sicher ist. > Jetzt lernen wir: Außer da eben da wo er nicht sicher ist. Dann hast du etwas gelernt, was hier nie gesagt wurde. Rust-Code ist automatisch sicher. Punkt.
Cyblord -. schrieb: > Ach so na klar. Also der Benefit ist ein total sicherer Kernel. Der > natürlich auch nicht nach außen mit irgendwas reden darf, damit man den > Safe-Space nicht verlässt. Dann aber, dann kommt Rust voll zur Geltung. > Natürlich nicht User Space. Die Applikation juckt ja nicht. habe nicht ich noch sonst jemand hier je behauptet - das ist deine Interpretation, die Durchdringunsschichten sind immer gefährlich und werden es auch bleiben - aber wenn der innere Code dann Safe ist habe ich trotzdem einen Gewinn - wenn du den nicht sehen kannst bringt es nichts mit dir über die Vorteile zu diskutieren, oder?
MaWin O. schrieb: > Cyblord -. schrieb: >> Ja und ich habe ein KONKRETES Beispiel genannt wo ich das Problem sehe. > > Ich sehe auch bei mehrmaligem Lesen kein konkretes Beispiel. Könntest du > das noch einmal wiederholen, bitte? Beitrag "Re: Rust - ist das hier um zu bleiben?" > > Cyblord -. schrieb: >> Deine Aussage war bisher dass Rust Code automatisch sicher ist. >> Jetzt lernen wir: Außer da eben da wo er nicht sicher ist. > > Dann hast du etwas gelernt, was hier nie gesagt wurde. > Rust-Code ist automatisch sicher. Punkt. Eigentlich haben wir gerade genau das Gegenteil gelernt. Aber dann sag mir wie Rust den Code in meinem obigen Beispiel sicher macht. Und zwar ohne Laufzeitoverhead.
Cyblord -. schrieb: > Deine Aussage war bisher dass Rust Code automatisch sicher ist. > Jetzt lernen wir: Außer da eben da wo er nicht sicher ist. Also da wo > ich nicht einfach statisch zur Kompilierzeit prüfen kann. > Und deshalb machst du so ein Fass für Rust auf? das hat er nie gesagt nur für die geschlossenen Teile, die nicht wenig sind weil nicht alles in einem Kernel oder Applikation durchdringt in jeder Zeile Code den Kernel- oder User-Space Rust ist safe so lange du nicht in eine andere Welt wechselst - das ist niemals eine Anforderung an Rust gewesen - wenn du darauf rumreiten willst das du es so verstanden hast ist es eben so, aber leider keine sinnvolle Diskussion
Cyblord -. schrieb: > Aber dann sag mir wie Rust den Code in meinem obigen Beispiel sicher > macht. Und zwar ohne Laufzeitoverhead. gar nicht - weil es das für Durchdringunsschichten nicht kann und nicht will - das muss du Hand anlegen - kein Pro-Rust entwickler stellt das in frage der Gewinn ist woanders
cppbert schrieb: > das hat er nie gesagt nur für die geschlossenen Teile, die nicht wenig > sind weil nicht alles in einem Kernel oder Applikation durchdringt in > jeder Zeile Code den Kernel- oder User-Space Liegt das an mir dass ich kein Stück von diesem Gestammel verstehen? > Rust ist safe so lange du nicht in eine andere Welt wechselst Andere Welt. Soso. > - das ist > niemals eine Anforderung an Rust gewesen Natürlich nicht. Nicht sicher in einer anderen Welt. Und nicht in der Anders-Welt. Aber in irgendeiner Welt bestimmt.
:
Bearbeitet durch User
cppbert schrieb: > der Gewinn ist woanders Wo finde ich den Gewinn wenn mein Array an dieser Stelle überläuft? Wo steckt hier der totale Vorteil von Rust? Irgendwo muss er doch sein.
:
Bearbeitet durch User
Cyblord -. schrieb: > Aber dann sag mir wie Rust den Code in meinem obigen Beispiel sicher > macht. Und zwar ohne Laufzeitoverhead. Das habe ich bereits erklärt. Der Rust-Code benötigt nicht mehr Checks als gleichwertig sicherer C-Code. Den Index musst du ein mal ganz am Anfang prüfen. In C muss man es und in Rust wäre es sinnvoll, wenn man keine Panics haben will. Weitergehende Indexchecks werden vom LLVM praktisch immer herausoptimiert, solange die Codepfade statisch verfolgbar sind. Und wenn nicht, dann steht dir wie bereits gesagt frei in genau diesen Sonderfällen unchecked-Zugriffe in Unsafe-Rust zu machen. In Summe hast du immer noch einen enormen Sicherheitsgewinn.
MaWin O. schrieb: > Den Index musst du ein mal ganz am Anfang prüfen. Anfang von was? Wenn dann muss man den Index bei JEDEM ZUGRIFF prüfen. Wie sonst soll das gehen?
Cyblord -. schrieb: > Anfang von was? Wenn dann muss man den Index bei JEDEM ZUGRIFF prüfen. > Wie sonst soll das gehen? Am Anfang der Callchain. Dort, wo du den Index aus den untrusted-Daten herausgepopelt hast. Wenn der Index einmal < len(buffer) ist, dann ist er es im weiteren Codeverlauf auch noch. Weitere Prüfungen finden nicht statt. Auch nicht bei Mehrfachzugriffen. Aber selbst wenn du alle Arrayzugriffe unchecked machst, was ohne Weiteres trivial möglich ist, dann hast du immer noch alle restlichen Vorteile und Sicherheiten von Rust. z.B. den Borrowchecker. Empfehlenswert ist es natürlich nicht, weil der Performancegewinn praktisch Null ist. Aber die Wahl liegt bei dir. In Rust ist diese ganze Array- und Index-Popelei sowieso nur selten notwendig. Es gibt dort deutlich einfachere und sichere Konzepte wie z.B. Iteratoren.
MaWin O. schrieb: > Wenn der Index einmal < len(buffer) ist, dann ist er es im weiteren > Codeverlauf auch noch. Nur verwendet man nicht dauernd den gleichen Index. MaWin O. schrieb: > In Rust ist diese ganze Array- und Index-Popelei sowieso nur selten > notwendig. Es gibt dort deutlich einfachere und sichere Konzepte wie > z.B. Iteratoren. Das nächste No-Go für embedded. Solche Konzepte sind für PC ja ok. Aber sie zeigen dass Rust auf Embedded noch ganz eigene Probleme hat. Gleiches gilt natürlich für die Systemprogrammierung. Wieder mal führt an C kein Weg vorbei. Wenn man nicht ständig und für alles enorme Datenstrukturen mitführen will.
:
Bearbeitet durch User
Cyblord -. schrieb: > Das nächste No-Go für embedded. Solche Konzepte sind für PC ja ok. Aber > sie zeigen dass Rust auf Embedded noch ganz eigene Probleme hat. Iteratoren sind zero-cost im Vergleich zur indexbasierten Lösung. Cyblord -. schrieb: > Nur verwendet man nicht dauernd den gleichen Index. Dann musst du natürlich auch in C prüfen, ob dein Index noch in bounds ist. Arithmetik auf indices führt gerne zu Sicherheitsbugs. Gern gehabt, kommt immer mal wieder rein. Erheitert uns ständig in der C-Welt.
Cyblord -. schrieb: > MaWin O. schrieb: >> In Rust ist diese ganze Array- und Index-Popelei sowieso nur selten >> notwendig. Es gibt dort deutlich einfachere und sichere Konzepte wie >> z.B. Iteratoren. > > Das nächste No-Go für embedded. Solche Konzepte sind für PC ja ok. Aber > sie zeigen dass Rust auf Embedded noch ganz eigene Probleme hat. Warum sollte das für embedded ein No-Go sein? Langsam denke ich das du nicht sehr viel Ahnung hast - was auch deine bisherigen Post erklären könnte Nicht mal ein C++-Iterator ist in embedded in jeglich Form ein Problem - weil so wie bei Rust ein Value-based Konzept Versuch doch mal nur das Problem mit Iterator und embedded zu erklären - vielleicht verstehen wir dann endlich mal was du nicht verstehst
Cyblord -. schrieb: > Wo finde ich den Gewinn wenn mein Array an dieser Stelle überläuft? Wo > steckt hier der totale Vorteil von Rust? Irgendwo muss er doch sein. die Linux-Kernel Entwickler akzeptieren Rust als erste weitere Programmiersprache neben C (nachdem C++ vor Jahren schon massiv abgelehnt wurde) weil die so viel Langeweile habe und Linus dafür bekannt ist immer die neusten Hype-Sprachen in den Linux Kernel aufzunehmen Erklär uns doch mal warum das passiert - unter der Annahme das die nicht alle völlig bescheuert sind
cppbert schrieb: > die Linux-Kernel Entwickler akzeptieren Rust als erste weitere > Programmiersprache neben C (nachdem C++ vor Jahren schon massiv > abgelehnt wurde) weil die so viel Langeweile habe und Linus dafür > bekannt ist immer die neusten Hype-Sprachen in den Linux Kernel > aufzunehmen Also Beweis durch Autorität? Rust ist ja wirklich ne Kirche. Es kann zwar niemand darlegen warum man bei Embedded/µC C durch Rust ersetzen sollte, aber 100 Linux Entwickler können sich nicht irren. > Langsam denke ich das du nicht sehr viel Ahnung hast - was auch deine > bisherigen Post erklären könnte Natürlich. Wer nicht fest in eurem Glauben steht, hat halt keine Ahnung.
:
Bearbeitet durch User
Cyblord -. schrieb: > Es kann zwar niemand darlegen warum man bei Embedded/µC C durch Rust > ersetzen sollte Ach troll dich doch bitte. Das ist doch keine ernsthafte Diskussion.
Cyblord -. schrieb: > Also Beweis durch Autorität? Rust ist ja wirklich ne Kirche. > ... > Natürlich. Wer nicht fest in eurem Glauben steht, hat halt keine Ahnung. sei doch nicht so extrem - ich hab dich nett nach einer Erklärung zu dem Iterator/embedded Problem gebeten und eine Erklärung warum Linux das jetzt akzeptiert - beides hast du nicht beantwortet und bist dan gleich zum Glaubenskrieg-Argument gewechselt
cppbert schrieb: > ich hab dich nett Äh nein. Mir Ahnungslosigkeit zu unterstellen fällt nicht unter nett. Es ist der typische Deppen-Abschluss einer Diskussion.
Cyblord -. schrieb: >> ich hab dich nett > > Äh nein. Mir Ahnungslosigkeit zu unterstellen fällt nicht unter nett. Es > ist der typische Deppen-Abschluss einer Diskussion. Jetzt beantworte doch einfach die Frage warum das Iterator-Konzept von Rust für embedded so untragbar ist und was die Gründe dafür sind warum du denkst das Rust überhaupt in Linux akzeptiert wurde - ich entschuldige mich auch dafür ein wenig ausfallend gewesen zu sein
Cyblord -. schrieb: > Mir Ahnungslosigkeit zu unterstellen fällt nicht unter nett. Es > ist der typische Deppen-Abschluss einer Diskussion. Es war lediglich eine Feststellung aufgrund deiner Aussagen hier. Ahnungslosigkeit zu vermuten ist da noch das Harmlose. Ich würde stattdessen eher vorsätzliche Trollerei vermuten.
Cyblord -. schrieb: > cppbert schrieb: >> ich hab dich nett > > Äh nein. Mir Ahnungslosigkeit zu unterstellen fällt nicht unter nett. Es > ist der typische Deppen-Abschluss einer Diskussion. das Rust-Iteratoren-Konzept einfach so (ohne jegliche Erklärung bisher) als untragbar für embedded zu bezeichnen ist nicht ein klein-wenig Ahnungslos? und von Glauben und Autorität zu sprechen wenn es darum geht das der Linux Kernel das erste mal in seiner Geschichte eine weitere Sprache akzeptiert ist differenziert? Machen es solche Aussagen vielleicht ungewollt einfacher ein wenig an deiner Erfahrung zu zweifeln?
MaWin schrieb: > Rolf M. schrieb: >> Warum sollte ich beleidigt sein? Ich bin lediglich der Ansicht, dass >> seine Argumente gegen C++ ziemlich an den Haaren herbeigezogen wirken. > > Weil...? > Du lieferst wieder keine Argumente und stattdessen nur Emotion. Nein. Du interpretierst nur in meine Postings sehr viel rein, das da nicht steht. > Und dann kritisierst du genau das an Linus. > > So trägst du nichts zur Diskussion bei, außer dass ich nun weiß, dass du > wohl aus unbekannten Gründen gerne C++ im Kernel hättest Nein, das weißt du nicht, du denkst es nur. Hab ich nie gesagt. Ich hab lediglich gesagt, dass seine Argumente dagegen nicht stichhaltig wirken. > und irgendwie memcpy besser als memmove findest. Zu memcpy hab ich überhaupt nichts gesagt. > Das ist für mich eine nutzlose Information, solange du das nicht > begründest. Natürlich ist sie nutzlos, weil falsch.
Rolf M. schrieb: > Ich hab > lediglich gesagt, dass seine Argumente dagegen nicht stichhaltig wirken. Ja. Und eine Begründung bleibst du uns weiterhin schuldig. Alleine darum ging es mir. Dass dir Linus Meinung nicht passt, habe ich verstanden. Warum das so ist, habe ich nicht verstanden. Rolf M. schrieb: > Zu memcpy hab ich überhaupt nichts gesagt. Ja, das habe ich dann verwechselt, weil das ein Gast war, der in genau die gleiche Tröte wie du geblasen hat. Sinnloses Abladen von: Määh ich finde Linus Aussage blöd.
Ok, ich habe jetzt noch einmal nachgeschaut. Rolf M. schrieb: >> Da muss man nur anschauen, was Linus von C erwartet hat und welche >> "features" er da haben wollte. (z.B. memcpy ganz durch memmove ersetzen >> und weiterer Blödsinn) > > Nachdem ich die Gründe, die er gegen C++ im Kernel vorgebracht hat, > gelesen habe, kann ich ihn in der Hinsicht eh nicht mehr ernst nehmen. Schon komisch, dass du genau auf die memcpy-Sache antwortest und jetzt behauptest nie etwas dazu gesagt zu haben. Du bist unehrlich.
MaWin schrieb: > Schon komisch, dass du genau auf die memcpy-Sache antwortest Auf welche "Sache" hätte ich denn sonst antworten sollen? Wenn da jetzt z.B. strlen oder was weiß ich was statt memcpy gestanden hätte, wäre meine Antwort dieselbe gewesen. Um die konkrete Funktion ging es gar nicht. Denk dir den Teil in den Klammern einfach weg, der ist unwichtig. > Du bist unehrlich. Nein, du legst es offenbar einfach darauf an, mich misszuverstehen.
Rolf M. schrieb: > Nein, du legst es offenbar einfach darauf an, mich misszuverstehen. Wir alle zusammen legen es darauf an, das scheint hier echt Forums-Kultur zu sein - Fehleannahmen, Empfindlichkeiten etc. aber warum machen wir jetzt nicht einfach ein Reset und kommen wieder aufs technische zurück und hören auf so zu "menscheln"
Tatsächlich ist doch schon längst alles gesagt worden. Mittlerweile ist das doch längst nur noch ein Webethread für die Rust Fanatiker. Wenn ich gekonnt hätte, hätte ich den längst geschlossen. Am Anfang hatte man noch Vorteile, echte Nachteile & Problematische Aspekte diskutiert. Aber das ist schon längst wieder unter den uninteressanten "alles toll, alles sicher, schau, neue Features, schau, jetzt mehr Rust dort" Beiträgen begraben, und wird eh von keinem mehr gelesen.
Rolf M. schrieb: > Um die konkrete Funktion ging es gar nicht. Gut, dass wir uns dann doch einig sind. Und wie sieht es mit einer Antwort aus? Warum glaubst du, dass Linus nicht in der Lage ist Grundlagenentscheidungen zu treffen? Ich kenne Linus Entscheidungen als sehr pragmatisch und sehr praxisorientiert. Bei Entscheidungen über C++, memcpy und Rust und vielem mehr. Der Erfolg gibt ihm Recht und seine Argumente sind für mich gut nachvollziehbar. Also nun Butter bei die Fische: Warum kannst du ihn "eh nicht mehr ernst nehmen"?
🐧 DPA 🐧 schrieb: > "alles toll, alles > sicher, schau, neue Features, schau, jetzt mehr Rust dort" Und wo ist das Problem? Ich schreibe sowohl über Vor- und Nachteile von Rust. Ich stelle hier zu 90% eh nur Unwahrheiten von Leuten, die offensichtlich nie mit der Sprache gearbeitet haben, richtig. > uninteressanten Warum diskutierst du trotzdem mit?
Naja, Linus wird auch langsam alt. Klare ansagen kann er auch nicht mehr machen, die SJW haben ihn einmal kräftig unter den Bus geworfen und so entschärft (wobei etwas weniger erfolgreich als bei RMS). Die Maintainer grosser Subsysteme sind auch schon etwas ausser Kontrolle, so macht z.B. Intel immer mal wieder was, wo sie dann schnell einen Release nachschieben müssen (letztens https://www.phoronix.com/news/Intel-iGPU-Avoid-Linux-5.19.12, davor ging mal plötzlich ältere FW nicht mehr, usw.) Eigentlich sollten das die diversen Maintainerschichten vorher abfangen. Und mit Greg Kroah-Hartman ist auch schon ein Linus-Ersatz vorhanden. Ich denke, Linus hat die Zügel längst abgegeben.
🐧 DPA 🐧 schrieb: > Aber > das ist schon längst wieder unter den uninteressanten "alles toll, alles > sicher, schau, neue Features, schau, jetzt mehr Rust dort" Beiträgen > begraben, und wird eh von keinem mehr gelesen. das ist schon irgendwie verständlich was du sagst - aber am Anfang hiess es immer das wird nichts weil es kein GCC Frontend dafür gibt, und weil es eh nicht relevant wird, keine Standard existiert, und das es auch gar niemand braucht weil C++ das schon alles perfekt kann und,und,und jetzt zieht Rust als erste weitere Sprachen in den Linux-Kernel ein (von dem wir denke ich alles wissen wie gross, relevant der ist und auch wie viele Entwickler daran arbeiten) und schon ist irgendwie klar das es die Linux-Kernel-Entwickler es auch nicht blicken - und das Microsoft und google usw. nachziehen ist ja auch nur eine allgem. blöde Idee weil die ihren Kram nicht unter Kontrolle bringen - aber komischerweise sind das die Zugpferde für alle C++ Sachen die in den letzten 15 Jahren gemacht wurden (pushen des C++ Standards, Sanitizer und und und) keiner sagt das Rust die Lösung aller Problem zu 100% ist (und das hat MaWin auch noch nie so global für alle Kontexte vermittel) aber zumindest eine nette Disukssion-Grundlage könnte es sein und dann kommen hier die Python, Javascript, C und C++ Entwickler und lassen sich (oft) ohne Background über irgendwelche Details aus und alle werden irgendwie sehr schnell sehr emotional - warum auch immer
🐧 DPA 🐧 schrieb: > Und mit Greg Kroah-Hartman > ist auch schon ein Linus-Ersatz vorhanden. aber der supportet doch auch pro-aktiv die Rust intergration - hat eines der ersten Linux-Beispiele mit dem Integrator entwickelt - also i don't care Linus, aber Greg hat schon viel früher mit Rust angefangen - so what?
und niemand hier ist so dumm zu glaube das ein schneller Einzug oder die Nutzung von Rust von mehreren Big-Playern irgendeine Qualitäts oder Perfektions-Relevanz hat, da geht es nur darum das sowas wie mit dem Linux-Kernel bisher einfach noch nie passiert ist und das entweder ein riesen Fehler ist oder eben eine sinnvolle Entscheidung - als Echtwelt-Gegenargument zu der ganzen Es-ist-perfekt-wie-es-ist-Fraktion
cppbert schrieb: > aber der supportet doch auch pro-aktiv die Rust intergration Ja eben. Ich sag ja: 🐧 DPA 🐧 schrieb: > Ich denke, Linus hat die Zügel längst abgegeben.
DPA schrieb: > cppbert schrieb: >> aber der supportet doch auch pro-aktiv die Rust intergration > > Ja eben. Ich sag ja: > > 🐧 DPA 🐧 schrieb: >> Ich denke, Linus hat die Zügel längst abgegeben. das stimmt auch nicht weil er ist auch sehr aktiv an der Integration beteiligt und freut sich ja (laut der letzten Keynote) darauf die Syntax zu lernen und richtig damit zu arbeiten (und das wird er - weil wir ihn kennen, er ist kein Man der leeren Worte, war er nie)
cppbert schrieb: > das stimmt auch nicht weil er ist auch sehr aktiv an der Integration > beteiligt und freut sich ja (laut der letzten Keynote) darauf die Syntax > zu lernen und richtig damit zu arbeiten (und das wird er - weil wir ihn > kennen, er ist kein Man der leeren Worte, war er nie) Das klingt als wenn die KP eine Pressemitteilung über Xi rausbringt. Oder in Nord-Korea über Kim geredet wird.
Cyblord -. schrieb: > cppbert schrieb: >> das stimmt auch nicht weil er ist auch sehr aktiv an der Integration >> beteiligt und freut sich ja (laut der letzten Keynote) darauf die Syntax >> zu lernen und richtig damit zu arbeiten (und das wird er - weil wir ihn >> kennen, er ist kein Man der leeren Worte, war er nie) > > Das klingt als wenn die KP eine Pressemitteilung über Xi rausbringt. > Oder in Nord-Korea über Kim geredet wird. ja schon - aber es ist doch trotzdem Realität das die beiden führenden Köpfe der Linux-Entwicklung das machen und google, Amazon und andere grosse das aktiv mit tragen - ich nehme einfach an das dir klar ist wie stark die grossen 5 von einem funktionierendem Linux abhängig sind btw: du hast immer noch nicht erklärt warum das Rust Iteratoren Konzept eine No-go für embedded ist - wird langsam Zeit
Am Anfang des Threads, 2019, war die Frage: > Rust - ist das hier um zu bleiben? Damals war Rust noch in so gut wie keinem relevanten Produkt vertreten. Viele Sachen waren unklar. Viele Features fehlten. Heute, 2022, würde ich sagen: > Rust - Das ist hier um zu bleiben! Heute sind immer noch viele Sachen unklar. Viele Features fehlen immer noch. Aber es hat sich enorm was getan. Viele Fragen wurden geklärt und viele Features wurden hinzugefügt. Man hat begonnen an einer Referenzdoku zu arbeiten. Alternative Compiler nähern sich rasant dem praktischen Nutzen. Rust auf Embedded funktioniert einfach mittlerweile (mit unstable compilern). Etc, etc... Und politisch ist Rust von vielen Firmen und großen Projekten als gute Alternative anerkannt und wird aktiv genutzt. Diese Akzeptanz breitet sich immer weiter aus und ist selbstverstärkend. Hinter Rust steht ein ganz anderes Moment als hinter all den anderen neuen Sprachen der letzten 20 Jahre. Das liegt natürlich auch daran, dass Rust viele der guten Features der Sprachen der letzten 20 Jahre vereinen konnte. Das liegt aber auch daran, dass Rust Dinge kann, die andere Sprachen nicht können und wahrscheinlich auch nie können werden. Und das Allerbeste: Wenn ihr Rust scheiße findet und es nicht verwenden wollt, dann verwendet es einfach nicht. So einfach ist das tatsächlich. Es gibt gar keinen Grund hier wild herumzuspekulieren und dabei seine eigene völlige Unkenntnis komplett preiszugeben. Ihr merkt das natürlich selbst nicht. Das ist klar. Während ihr euch dann weiterhin mit C eure Bufferoverflows implementiert, habe ich stattdessen Spaß mit Rust. Denn Rust macht tatsächlich Spaß. Und ich muss zugeben, dass ich das vorher auch nicht gedacht hätte. Irgendwann wird Rust von einer noch besseren Sprache abgelöst werden. Und da freue ich mich jetzt schon drauf.
MaWin O. schrieb: > Genau. Zum Glück kann man in Rust ja immer memcpy nutzen, weil es kein > Aliasing gibt. Man hat also immer den Performancevorteil. Bei aliasing geht es ja nur darum, dass man nicht mit einem Pointer/Referenz auf Speicher schreibt, und mit einem anderen Pointer im selben Scope das selbe dann wieder liest, oder? Aliasing wäre dann eine etwas schwächere Garantie, als dass 2 Pointer nicht auf den selben Speicherbereich zeigen. In C verarbeite ich buffer manchmal inplace, nach dem Schema:
1 | int i_in, i_out; |
2 | for(i_in=0,i_out=0; i_out < length; i_in++){ |
3 | unsigned char ch = buffer[i_in]; |
4 | ...
|
5 | if(bla) buffer[i_out++] = 123; |
6 | }
|
7 | length = i_out; |
Sprich, i_in wird bei jedem Durchlauf inkrementiert, i_out aber nicht (und auch höchstens einmal), damit ist immer i_in <= i_out garantiert, und es ist sichergestellt, dass beim schreiben nach buffer[i_out] nie etwas überschrieben wird, was danach mit i_in gelesen wird. Das müsste also eigentlich statisch erkennbar sein. Das ist recht nützlich, z.B. beim dekodieren von Hex zu Binär, aber auch bei base64 kann man es machen. (Das habe ich erst letztens mal wieder gemacht https://github.com/Daniel-Abrecht/ml666/blob/ml666/src/json-token-emmiter.c#L151-L200 (da sollte ich eventuell noch ein par "restrict" keywords reinwerfen). Kann man dieses Pattern, diesen Konstraint, in safe Rust bereits effektiv abdecken, oder muss man da Speicher verschwenden?
> Kann man dieses Pattern, diesen Konstraint, in safe Rust bereits > effektiv abdecken, oder muss man da Speicher verschwenden? Bei allem was wir hier inzwischen über Rust lesen, solltest du Speicher im Überfluss haben. In-Place kann da gar nichts gehen. Temporäres rumkopieren von Daten (bezüglich Laufzeit gratis natürlich) und anlegen von massiven Datenstrukturen (bezüglich Speicher gratis) für jeden Pups ist da mal default. Da passt dann die Empfehlung für memmove schon exakt ins Bild.
:
Bearbeitet durch User
Ich denke mit einem Callback könnte man sowas sicher abstrahieren, als C code würde das so aussehen:
1 | struct optional { |
2 | bool empty; |
3 | uint8_t value; |
4 | }
|
5 | void inplace_replace(const size_t length, uint8_t slice[length], struct optional (*const transformer)(const uint8_t input)){ |
6 | for(size_t i_in=0,i_out=0; i_in < length; i_in++){ |
7 | const struct optional out = transformer(slice[i_in]); |
8 | if(out.empty) slice[i_out++] = out.value; |
9 | }
|
10 | }
|
Das müsste doch so ähnlich auch in Rust machbar sein. Gibts da schon was in der Rust Standard Library oder so für so eine inplace_replace Funktion?
Cyblord -. schrieb: > Bei allem was wir hier inzwischen über Rust lesen, solltest du Speicher > im Überfluss haben. das sagt absolut niemand (keine Ahnung wo du das gelesen hast) - Move-Semantic ist bei Rust der Default (im gegensatz zu C/C++ wo Kopie der Defaul ist) - kopiert wird da recht wenig und ein grosses Ziele ist Resourcen-Vebrauch auf C Niveau oder besser btw: du hast immer noch nicht erklärt warum das Rust Iteratoren Konzept eine No-go für embedded ist - wird langsam wirklich Zeit
Ich schmeiß einfach mal nom in den Raum: https://github.com/Geal/nom Parser die nom nutzen: https://github.com/Geal/nom#parsers-written-with-nom https://github.com/Geal/nom#technical-features
1 | zero-copy: |
2 | If a parser returns a subset of its input data, it will return a |
3 | slice of that input, without copying |
4 | |
5 | safe parsing: |
6 | nom leverages Rust's safe memory handling and powerful types, and |
7 | parsers are routinely fuzzed and tested with real world data. So far, |
8 | the only flaws found by fuzzing were in code written outside of nom |
9 | |
10 | speed: |
11 | Benchmarks have shown that nom parsers often outperform many |
12 | parser combinators library like Parsec and attoparsec, some regular |
13 | expression engines and even handwritten C parsers |
🐧 DPA 🐧 schrieb: > Bei aliasing geht es ja nur darum, dass man nicht mit einem > Pointer/Referenz auf Speicher schreibt, und mit einem anderen Pointer im > selben Scope das selbe dann wieder liest, oder? Aliasing Probleme sind auch std::vector<int> v{1,2} int* a = &v[0]; v.push(20); v.push(30); v.push(40); v.push(50); -> wegen copy-on-resize im std::vector is a relativ sicher dangling passiert aber genau so mit realloc in C
Cyblord -. schrieb: > Da passt dann die Empfehlung für memmove schon exakt ins Bild. das war von Linus für den Linux-Kernel, für den C code, null Bezug zu Rust
cppbert schrieb: > das war von Linus für den Linux-Kernel, für den C code, null Bezug zu > Rust Aber hallo, von DEM Linus der jetzt doch voll auf Rust abfährt. Außerdem geht es eben um das Mindset hinter so einer Empfehlung. Da ist die Sprache egal.
:
Bearbeitet durch User
Cyblord -. schrieb: > cppbert schrieb: >> das war von Linus für den Linux-Kernel, für den C code, null Bezug zu >> Rust > > Aber hallo, von DEM Linus der jetzt doch voll auf Rust abfährt. > Außerdem geht es eben um das Mindset hinter so einer Empfehlung. Da ist > die Sprache egal. du hast immer noch nicht erklärt warum das Rust Iteratoren Konzept eine No-go für embedded ist - brauchst du vielleicht noch ein bisschen mehr Zeit?
🐧 DPA 🐧 schrieb: > int i_in, i_out; > for(i_in=0,i_out=0; i_out < length; i_in++){ > unsigned char ch = buffer[i_in]; > ... > if(bla) buffer[i_out++] = 123; > } > length = i_out; ich sehe da keine Probleme mit Rust, wo sind da Aliasing Probleme? In dem Beispiel ist doch alles nur Value-based, keine Pointer die irgendwie invalidieren
Mit i_in und i_out lese / schreibe ich vom selben buffer. Man könnte die quasi als 2 Pointer im selben Scope betrachten. Dennoch ist sichergestellt, dass ich nie mit dem einen das lese, was ich mit dem anderen schreibe. Die Sache ist also punkto aliasing komplett sicher, aber ich weiss nicht, wie man das mit safe Rust macht / abbildet (oder ob das überhaupt geht). Da fehlt mir etwas die Erfahrung. Aber vielleicht kann es ja jemand mit dieser Erfahrung hier übersetzen, sofern es möglich ist?
so? https://gcc.godbolt.org/z/8KGPPc35f
1 | fn _main() { |
2 | let mut buffer: [u8; 23] = [0; 23]; |
3 | let bla = true; |
4 | let mut i_out = 0usize; |
5 | for i_in in 0..buffer.len() |
6 | { |
7 | let _ch = buffer[i_in]; |
8 | if bla { buffer[i_out] = 123; } |
9 | i_out+=1; |
10 | } |
11 | } |
die unterstriche vor _main und _ch sind nur dazu da um die unused-value warnung zu unterdrücken Rust schützt dich nicht davor das dein Algorithmus jetzt kreuz und quer in deinem Array rumschreibt - nur das andere abhängigkeiten - andere Funktionen ausserhalb einen Zustand erwarten können, Rust versucht nicht deinen Algorithmus irgendwie zu validieren oder sonstige - falls das hier die Frage ist
Interressant. Dann sind gewisse Formen von Aliasing ja doch möglich.
DPA schrieb: > Interressant. Dann sind gewisse Formen von Aliasing ja doch möglich. Rust ist 100% sicher, außer in den Welten in denen es nicht sicher ist.
🐧 DPA 🐧 schrieb: > Sprich, i_in wird bei jedem Durchlauf inkrementiert, i_out aber nicht > (und auch höchstens einmal), damit ist immer i_in <= i_out garantiert, > und es ist sichergestellt, dass beim schreiben nach buffer[i_out] nie > etwas überschrieben wird, was danach mit i_in gelesen wird. Das müsste > also eigentlich statisch erkennbar sein. Mit Indexen gibt es eh kein Aliasing. Weder in C noch in Rust. 🐧 DPA 🐧 schrieb: > Kann man dieses Pattern, diesen Konstraint, in safe Rust bereits > effektiv abdecken Klar. Cyblord -. schrieb: > Bei allem was wir hier inzwischen über Rust lesen, solltest du Speicher > im Überfluss haben. > In-Place kann da gar nichts gehen. Kompletter Unsinn. Das ist genau wieder so ein Beitrag, wo du dich als komplett ahnungslos im Bezug auf Rust outest. "kann gar nicht gehen". Soso. Wieso fragst du nicht stattdessen "kann das gehen?"? Falsches als Fakt hinzustellen und dann beleidigt sein wenn man korrigiert wird, das ist das größte Problem an diesem Thread. In-Place hat überhaupt gar nichts mit Aliasing zu tun. Wenn man eine mutable-Referenz hat, kann man damit natürlich machen, was man will. Lesen, Schreiben, in beliebiger Reihenfolge auf beliebigen Indexen. Cyblord -. schrieb: > Außerdem geht es eben um das Mindset hinter so einer Empfehlung. Was meinst du damit? 🐧 DPA 🐧 schrieb: > Die Sache ist also punkto aliasing komplett sicher, aber ich weiss > nicht, wie man das mit safe Rust macht / abbildet Ziemlich ganz genau so, wie du es auch in C schreibst. Das unterscheidet sich nur syntaktisch minimalst und logisch/algorithmisch überhaupt nicht. 🐧 DPA 🐧 schrieb: > Man könnte die quasi als 2 Pointer im selben Scope betrachten Es sind aber keine 2 Pointer. Und es sind keine 2 Referenzen. In Rust gibt es eine ganz klare Unterscheidung zwischen Referenzen und Indexen. In Rust gibt es keine schwammigen Linien zwischen Pointern, Referenzen, Arrays, Indexen. Das sind vier völlig verschiedene Datentypen, zwischen denen explizit konvertiert werde muss, wenn das denn gewünscht ist. In der Regel ist das aber nicht notwenig oder sogar unsafe. Sowas wie Arrays, die in Pointer zerfallen oder Indexzugriffe, die eigentlich nur Syntaxzucker für Pointerarithmetik sind gibt es in Rust gar nicht. Indexzugriffe sind Indexzugriffe über die ganz klar definierten Index und IndexMut Traits.
Cyblord -. schrieb: > DPA schrieb: >> Interressant. Dann sind gewisse Formen von Aliasing ja doch möglich. Nein. Indexe sind keine Aliase. https://doc.rust-lang.org/std/ops/trait.Index.html https://doc.rust-lang.org/std/ops/trait.IndexMut.html Indexe operieren auf einer Referenz (im Trait self genannt). Diese Referenz darf und kann keinen Alias haben, wenn sie mutable ist. Das wird vom Compiler statisch forciert. > Rust ist 100% sicher, außer in den Welten in denen es nicht sicher ist. Oder wenn du wieder einmal etwas nicht verstanden hast. Safe-Rust ist 100% memory safe. Immer.
Logisch sind die Konzepte aber äquivalent, unabhängig von der Programmiersprache. Ob ich 2 Pointer oder 2 Indexe habe, im moment des Zugriffs wird genau die selbe Stelle geladen / geschrieben. Damit lässt sich dann in Rust auch ein logisches äquivalent zu memmove abbilden, halt dann mit Indexen, statt Pointern.
Cyblord -. schrieb: >> 100% memory safe > Gibts dafür ne Definition? Findest du sicher in der Rust-Referenz. Darunter fallen: Kein UB, kein Use-After-Free und keine Data Races. DPA schrieb: > Logisch sind die Konzepte aber äquivalent In diesem Fall schon. Ja. Wenn man in C denkt. > unabhängig von der > Programmiersprache. Ob ich 2 Pointer oder 2 Indexe habe, im moment des > Zugriffs wird genau die selbe Stelle geladen / geschrieben. Das ist halt die C-Denkweise. In Safe-Rust gibt es gar keine Pointerarithmetik. (Ja ja, Arithmetik gibts schon, aber man kann das Ergebnis nicht dereferenzieren). Somit erübrigt sich die Frage in Rust, ob Pointerarithmetik das gleiche wäre wie Indexarithmetik. Diese Frage kann man wenn dann überhaupt nur in Unsafe-Rust stellen und beantworten. DPA schrieb: > Damit lässt sich dann in Rust auch ein logisches äquivalent zu memmove > abbilden, halt dann mit Indexen, statt Pointern. Ein äquivalent zu memmove ist, wie mehrfach schon gesagt, in Rust überhaupt gar nicht notwendig. Rust kopiert alles mit memcpy, weil es kein Aliasing gibt. (Kein mutable Aliasing. Aliasing auf Immutables gibt es natürlich. Aber da kann halt auch niemand drauf schreiben). Und ob du jetzt deinen InPlace-Algorithmus oder etwas anderes schreibst, das hat doch gar nichts mit memmove zu tun. Ein InPlace-Algorithmus hat doch per Definition immer nur ein Ownership. Also auch nur eine mutable-Referenz. Zwei Mutable-Referenzen gehen in Rust nicht. Aber die braucht man auch gar nicht. (Auch nicht in C.) Irgendwie kommt es mir vor, als würden wir da aneinander vorbei reden.
MaWin schrieb: >> Logisch sind die Konzepte aber äquivalent > > In diesem Fall schon. Ja. Wenn man in C denkt. > >> unabhängig von der >> Programmiersprache. Ob ich 2 Pointer oder 2 Indexe habe, im moment des >> Zugriffs wird genau die selbe Stelle geladen / geschrieben. > > Das ist halt die C-Denkweise. In Safe-Rust gibt es gar keine > Pointerarithmetik. (Ja ja, Arithmetik gibts schon, aber man kann das > Ergebnis nicht dereferenzieren). Am Ende wird alles zu ASM Code und da gibts dann wieder direkte (und indirekte) Pointer auf den Speicher. Also was soll so ein Geschwätz? Das ist keine "C Sicht", das ist die scheiß Realität.
:
Bearbeitet durch User
MaWin schrieb: >>> 100% memory safe >> Gibts dafür ne Definition? > > Findest du sicher in der Rust-Referenz. Du hast mich falsch verstanden. Wenn du sagst, Rust ist 100% Memory Safe, dann muss du doch eine Liste von Konzepten im Kopf haben, welche für dich die 100% darstellen. Und Rust deckt sich damit. Aber du behauptest jetzt, genau das Set welches Rust bietet, entspricht 100%? Per welcher Definition?
MaWin schrieb: > Das ist halt die C-Denkweise. In Safe-Rust gibt es gar keine > Pointerarithmetik. Nein, mein Argument ist ein rein logisches. Welche Terminologie oder Semantik Rust oder C dort verwenden, ist irrelevant. Der Rest mag ja alles stimmen. Aber fundamental logisch betrachtet, ist und bleibt es ein spezieller Fall von erlaubtem Aliasing. Auch wenn die Rust läute das nicht so nennen und nicht wahr haben wollen. PS: Klar, das ist hier sinnvoll (also ein feature, kein bug), und mit vernachlässigbaren negativen Implikationen. Es geht mir hier um logische Konsistenz bei der Betrachtung & Argumentation über des Systems, und nicht darum, ein praktisches Problem heraufzubeschwören, wo keines ist.
Cyblord -. schrieb: > Am Ende wird alles zu ASM Code und da gibts dann wieder direkte (und > indirekte) Pointer auf den Speicher. > Also was soll so ein Geschwätz? Es zeigt sehr schön, dass du keine Ahnung davon hast, wie Sprachen definiert sind. Rust arbeitet, genau wie C auch, auf Basis eines virtuellen Maschinenmodell. In welches asm das dann irgendwann einmal übersetzt wird, spielt überhaupt keine Rolle. Weder in Rust, noch in C. Es ist Rust als Sprache völlig egal, ob das Backend das Programm in Code für Maschinen mit oder ohne Pointer übersetzt. (Ja, ich weiß, dass es da cornercases gibt. (vgl. Cheri-Architektur). Aber keine dieser Cornercases führen zu UB oder Verlust von Rust-Garantien. Und daran wird gearbeitet.) Erst nachdem Rust seine Sicherheitsgarantien statisch geprüft hat, wird die Kontrolle an LLVM übergeben. Dieser generiert dann irgendwann Code draus. Mit Rust hat das aber nichts mehr zu tun. Die paar wenigen verbliebenen Sicherheitsgarantien, die Rust nicht statisch prüfen kann, resultieren dann in entsprechendem asm-Code, der zur Laufzeit die Dinge prüft.
[Linus ist gegen C++ im Kernel aber für Rust] Der Grund dafür ist doch relativ einfach: Linus war schon immer ein Assembler Hacker und hat halt irgendwann (pragmatisch) C als Assembler Ersatz akzeptiert. Er denkt aber immer noch als Assembler Hacker, d.h. bei Änderungen in C sieht er relativ schnell den Assembler Code, den den Compiler generiert, vor sich. Das kann er (und auch viele andere C Hacker) bei C++ nicht mehr so gut. C++ ist standardisiert, mit einem Zulassen von C++ wurden die ganzen teilweise obskur wirkenden C++ Formulierungen in den Kernel Einzug halten. Die Schnittmenge sehr guter Kernel Hacker und sehr guter C++ Programmierer ist nicht so groß. Wer soll denn verantwortungsvoll den neuen C++ Code im Kernel reviewen? Die "alte" Kernel-Hacker-Gilde eher nicht. Einzelne C++ Features auszuschließen würde die Sache nicht besser machen, würde wohl in einem größeren Krieg enden. Aber ein paar Features wird man ausschließen müssen... Nun ist aber Linus pragmatisch genug, um zu sehen, dass der Kernel auch eine Weiterentwicklung in Bezug auf Programmiersprache braucht. Rust hat dabei gegenüber C++ ein paar pragmatische Vorteile a) bringt Sprachfeatures mit, die gut in den Bereich Betriebssystem passen b) gleichzeitig klein genug, um es in vernünftiger Zeit zu lernen c) Weit genug weg von C um keinen C/C++ Mischmasch entstehen zu lassen d) gleichzeitig neu genug, um noch Einfluss auf die Sprachkonzepte zu nehmen um diese sinnvoll für Systemprogrammierung/Embedded zu entwickeln e) Es gibt kaum Linux-Rust-Hacker, die Linus/die ganzen alten Linux Hacker zeigen würden, dass er bei Rust keine Ahnung hat bzw. es ist zzt. noch kein Problem, wenn ein "gestandener" Programmierer wenig Ahnung von Rust hat. f) Geht die Sache mit Rust schief, kann man zur Not Rust besser als C++ wieder loswerden.
Cyblord -. schrieb: > Per welcher Definition? Der Rust-Definition. Ich habe jetzt echt keine Lust für dich zu googlen. 🐧 DPA 🐧 schrieb: > ist und bleibt es ein spezieller Fall von erlaubtem Aliasing. Das ist und bleibt Quatsch. Sowohl in C als auch in Rust. Aliasing ist ein Konzept, das auf Typebene stattfindet. Indexierung ist ein Konzept, das auf Typ und auf Codeebene stattfindet. In Rust sind Typ- und Codeebene viel besser getrennt als in C. Eine Referenz ist kein Pointer. Ein Pointer ist keine Adresse. Eine Adresse ist keine Zahl (sieht man bei Cheri schön). Ein Index hat mit Pointertypen und Referenztypen gar nichts zu tun. Ein Index ist eine Zahl. Das sind alles unterschiedliche Konzepte, die C vermischt und Rust aber (fast) alle strikt voneinander trennt. Mehr kann ich dazu leider nicht mehr sagen.
Es ist simpel. Der Zugriff auf etwas braucht eine Referenz im allgemeinen sinne irgendwelcher Form darauf. Ob das ein Handle, ein Pointer, oder eine Kombination davon ist, ist da erstmal egal. Hat man es mit 2 Referenzen zutun, die auf das selbe verweisen, und man auf diese zugreift, hat man es mit aliasing im allgemeinen sinne zutun. Es ist sinvoll, solche Konzepte verallgemeinert (unabhängig einer konkreten Sprache) betrachtet zu können, um Sprachunabhängig logische Überlegungen zu Situationen, welche diese involvieren, machen zu können. Und das hat hier ja auch sehr gut funktioniert. Jetzt kennen wir den gesamten Sachverhalt in Bezug auf Rust viel genauer, inklusive wie Rust diesen betrachtet.
🐧 DPA 🐧 schrieb: > Es ist simpel. Der Zugriff auf etwas braucht eine Referenz im > allgemeinen sinne irgendwelcher Form darauf. Ob das ein Handle, ein > Pointer, oder eine Kombination davon ist, ist da erstmal egal. Hat man > es mit 2 Referenzen zutun, die auf das selbe verweisen, und man auf > diese zugreift, Korrekt. Wenn man einen Pointer hat und mit zwei unterschiedlichen Indexe auf unterschiedliche Elemente zugreift, dann sind das unterschiedliche Elemente. Also kein Aliasing. Auch in C nicht. Verstehst du es nun?
Die Kombination Pointer + Index ist in den 2 Stellen als eine Referenz auf etwas im allgemeinen Sinne zu betrachten. Es spielt keine rolle, ob Rust oder C das als Aliasing bezeichnen. Im allgemeinen sinne ist es aber genau das.
Ok, ich gebs auf. Du definierst dir deine eigene Definition von Aliasing zurecht, nur um Recht zu behalten.
Cyblord -. schrieb: > DPA schrieb: >> Interressant. Dann sind gewisse Formen von Aliasing ja doch möglich. > > Rust ist 100% sicher, außer in den Welten in denen es nicht sicher ist. du hast immer noch nicht beschreiben warum das Rust Iterator-Konzept ein No-go für embedded ist langsam denke ich schon das du recht anhnungslos bis, oder einfach nicht in der Lage bist gemachte Statements zu begründen
Ohne ein allgemeines Konzept von Aliasing wäre es nicht möglich, darüber unabhängig von der Programmiersprache nachzudenken, und diese zu vergleichen. Programmiersprachen verwenden und benennen die selben sowie die verschiedensten Konzepte und Variationen davon, ziemlich beliebig. Es ist ziemlich einschränkend, wenn man nichts unabhängig von der Sprache konzeptualisieren kann/darf.
🐧 DPA 🐧 schrieb: > Ohne ein allgemeines Konzept Ja. DPA. Du hast Recht. In allen Punkten. Nach deiner Definition gibt es Aliasing in Rust. Nach deiner Definition gibt es alles, was du zurechtdefinierst in Rust. Ist das nun ausreichend, damit du mit dem Unfug aufhörst?
1 | let person1 = "DPA"; |
2 | let person2 = "DPA"; |
3 | // mache etwas mit den beiden Handles in der µC.net Personendatenbank. |
4 | db.machewas(person1, person2); |
Nach DPA's "allgemeinen Aliasing-Definition" wäre das also Aliasing. Schön. Bringt leider niemandem was. Leider komplett nutzlos in der Diskussion. Komplett nutzlos bei der Betrachtung und Analyse von Aliasing (wie der Rest der Welt es versteht) in Typsystemen. Aber schön, dass wir nun auch DPA's Definition von Aliasing kennen.
MaWin schrieb: > Aber schön, dass wir nun auch DPA's Definition von Aliasing kennen. Ich glaube DPA driftet gerade zur guten Seite der Macht (mit ein wenig unklaren Aussagen, aber er versuchts) - bisschen weniger agro reicht auch
🐧 DPA 🐧 schrieb: > Es spielt keine rolle, ob > Rust oder C das als Aliasing bezeichnen. Im allgemeinen sinne ist es > aber genau das. Aliasing ist ein Sprachkonzept - das kann jede Sprache für sich definieren oder nicht - das ist kein allgmeines Hardwarekonzept - oder hab deine Aussage falsch verstanden?
MaWin schrieb: > Nach DPA's "allgemeinen Aliasing-Definition" wäre das also Aliasing. Das hängt in dem konkreten Beispiel von der Implementierung, und davon was "machewas" macht, ab. Oder zumindest würde es das dann, wenn man darauf zugriffe, aber in dem Beispiel weiss man das ja nicht. Angenommen es handelt sich um Rust (der selbe Code ist auch in ein paar anderen Sprachen, z.B. JS gültig), wäre es aber immerhin nicht mut (in rust Terminologie), immerhin weiss man also, das da nicht reingeschrieben wird, womit das ganze dann in dem Beispiel auch wieder keine grosse Rolle mehr spielen dürfte.
🐧 DPA 🐧 schrieb: > MaWin schrieb: >> Nach DPA's "allgemeinen Aliasing-Definition" wäre das also Aliasing. > > Das hängt in dem konkreten Beispiel von der Implementierung, und davon > was "machewas" macht, ab. Oder zumindest würde es das dann, wenn man > darauf zugriffe, aber in dem Beispiel weiss man das ja nicht. Angenommen > es handelt sich um Rust (der selbe Code ist auch in ein paar anderen > Sprachen, z.B. JS gültig), wäre es aber immerhin nicht mut (in rust > Terminologie), immerhin weiss man also, das da nicht reingeschrieben > wird, womit das ganze dann in dem Beispiel auch wieder keine grosse > Rolle mehr spielen dürfte. Was möchtest du uns sagen? dein genanntes Beispiel ist in allen Sprachen die C/JS/Rust/Java/C#-Artig sind Aliasing frei - geht es hier immer noch um Aliasing?
cppbert schrieb: > 🐧 DPA 🐧 schrieb: >> Es spielt keine rolle, ob >> Rust oder C das als Aliasing bezeichnen. Im allgemeinen sinne ist es >> aber genau das. > > Aliasing ist ein Sprachkonzept - das kann jede Sprache für sich > definieren oder nicht - das ist kein allgmeines Hardwarekonzept - oder > hab deine Aussage falsch verstanden? Das Aliasing Konzept dient dazu, über Dinge Rückschlüsse ziehen zu können, wie z.B. ob der Compiler lese / schreibzugriffe umsortieren und wegoptimieren kann, ohne das Verhalten zu ändern. Aber es ist auch nützlich, um über Situationen argumentieren zu können, wo gleichwertige Referenzen ungültig werden. Unter diesen Gesichtspunkten kann man Aliasing verallgemeinert betrachten & definieren, als rein abstraktes Konzept. Man muss nur schauen, worauf kommt es tatsächlich an? Es ergibt sich dann quasi von selbst. cppbert schrieb: > Was möchtest du uns sagen? dein genanntes Beispiel ist in allen Sprachen > die C/JS/Rust/Java/C#-Artig sind Aliasing frei - geht es hier immer noch > um Aliasing? In dem Beispiel von MaWin gibt es diverse Compiler, die die Strings zusammenfassen, weil sie die selben sind. Unter diesen umständen könnten die 2 Referenzen sich auf das selbe Objekt beziehen, und es gibt fälle, wo das relevant ist.
🐧 DPA 🐧 schrieb: > cppbert schrieb: >> 🐧 DPA 🐧 schrieb: >>> Es spielt keine rolle, ob >>> Rust oder C das als Aliasing bezeichnen. Im allgemeinen sinne ist es >>> aber genau das. >> >> Aliasing ist ein Sprachkonzept - das kann jede Sprache für sich >> definieren oder nicht - das ist kein allgmeines Hardwarekonzept - oder >> hab deine Aussage falsch verstanden? > > Das Aliasing Konzept dient dazu, über Dinge Rückschlüsse ziehen zu > können, wie z.B. ob der Compiler lese / schreibzugriffe umsortieren und > wegoptimieren kann, ohne das Verhalten zu ändern. Aber es ist auch > nützlich, um über Situationen argumentieren zu können, wo gleichwertige > Referenzen ungültig werden. Unter diesen Gesichtspunkten kann man > Aliasing verallgemeinert betrachten & definieren, als rein abstraktes > Konzept. Man muss nur schauen, worauf kommt es tatsächlich an? Es ergibt > sich dann quasi von selbst. das ist bekannt, wer es noch nicht weiß der kann: https://en.wikipedia.org/wiki/Aliasing_(computing) durchlesen > cppbert schrieb: >> Was möchtest du uns sagen? dein genanntes Beispiel ist in allen Sprachen >> die C/JS/Rust/Java/C#-Artig sind Aliasing frei - geht es hier immer noch >> um Aliasing? > In dem Beispiel von MaWin gibt es diverse Compiler, die die Strings > zusammenfassen, weil sie die selben sind. Unter diesen umständen könnten > die 2 Referenzen sich auf das selbe Objekt beziehen, und es gibt fälle, > wo das relevant ist. das würden (manche Compiler) nur dann machen wenn die imutable sind - dann gibt es auch kein schreiben und daher auch kein Konfliktpotenzial
cppbert schrieb: > das würden (manche Compiler) nur dann machen wenn die imutable sind - > dann gibt es auch kein schreiben und daher auch kein Konfliktpotenzial Das ist bei rust der Default. Wobei ich nicht weiss, ob rust Compiler die Strings zusammenfassen, und ich auch nicht weiss, ob Rust das definiert oder nicht. Ein fall, wo so etwas aber Konfliktpotenzial bietet, ist bei Vergleichen. Falls die Sprache eine Möglichkeit bietet, Referenzen zu vergleichen, und die in dem fall dann gleich wären. Wenn diese Voraussetzungen gegeben sind, kann man gewisse Fehler machen.
🐧 DPA 🐧 schrieb: > cppbert schrieb: >> das würden (manche Compiler) nur dann machen wenn die imutable sind - >> dann gibt es auch kein schreiben und daher auch kein Konfliktpotenzial > > Das ist bei rust der Default. weil die beiden immutable sind > Wobei ich nicht weiss, ob rust Compiler > die Strings zusammenfassen, und ich auch nicht weiss, ob Rust das > definiert oder nicht. also weisst du irgendwie gar nichts genaues dazu :) > Ein fall, wo so etwas aber Konfliktpotenzial bietet, ist bei > Vergleichen. Falls die Sprache eine Möglichkeit bietet, Referenzen zu > vergleichen, und die in dem fall dann gleich wären. Wenn diese > Voraussetzungen gegeben sind, kann man gewisse Fehler machen. das klingt so als vermutest du eine Lücke im Rust Konzept, oder driften wir gerade in ein anderes Thema?
cppbert schrieb: > das klingt so als vermutest du eine Lücke im Rust Konzept, oder > driften wir gerade in ein anderes Thema? Nein, Rust wird das schon richtig machen. Das ist nur einfach eine Allgemeine Sichtweise, wie ich solche Sachen betrachte, und wie ich über solche Dinge generell nachdenke. Vielleicht kommt das wirklich auch ein wenig vom Arbeiten mit C. Da muss man, neben der Sprachsyntax, Semantik, usw. auch diese allgemeinen Konzepte alle immer im Überblick haben, sonst kann man dort Fehler machen. Im Umkehrschluss hiesse das dann, dass wen Rust einem dies abnimmt, ... Aber öffnen wie diese Büchse der Pandora mal lieber nicht.
🐧 DPA 🐧 schrieb: > cppbert schrieb: >> das klingt so als vermutest du eine Lücke im Rust Konzept, oder >> driften wir gerade in ein anderes Thema? > > Nein, Rust wird das schon richtig machen. Das ist nur einfach eine > Allgemeine Sichtweise, wie ich solche Sachen betrachte, und wie ich über > solche Dinge generell nachdenke. Jetzt wirst du zu esotherisch... oder besser gesagt du verwässerst deine Klarheit das ist hier auch oft das Problem: Konkrekte, kleine Themen werden nicht auf ihrem Level diskutiert und dann fängt irgendwann so eine allgmeine. Sprachdesign-Welle an und am Ende gibt es kein Ergebnis - bis MaWin irgendeine Neuigkeit einstellt und dann geht das wieder von vorne los :)
🐧 DPA 🐧 schrieb: > Das hängt in dem konkreten Beispiel von der Implementierung, und davon > was "machewas" macht, ab. Ah. Komisch. Eben war es noch möglich eine allgemeine Definition zu haben. Plötzlich ist sie nicht mehr allgemein. Du hast völlig Recht, dass es von der Sprache abhängt. Dann lasse mich das mal etwas präziser formulieren: Ein Pointer-Aliasing, wie es C definiert, gibt es in Rust für mutable-Referenzen nicht. Würdest du da mitgehen? 🐧 DPA 🐧 schrieb: > Ein fall, wo so etwas aber Konfliktpotenzial bietet, ist bei > Vergleichen. Falls die Sprache eine Möglichkeit bietet, Referenzen zu > vergleichen, und die in dem fall dann gleich wären. Wenn diese > Voraussetzungen gegeben sind, kann man gewisse Fehler machen. Es gibt in Rust keine zwei Referenzen, die auf das gleiche Objekt zeigen, wenn eine oder mehrere davon mutable sind. Das versuchen wir dir hier seit Stunden beizubringen. 🐧 DPA 🐧 schrieb: > Vielleicht kommt das wirklich auch ein wenig vom Arbeiten mit C. Da muss > man, neben der Sprachsyntax, Semantik, usw. auch diese allgemeinen > Konzepte alle immer im Überblick haben, sonst kann man dort Fehler > machen. Im Umkehrschluss hiesse das dann, dass wen Rust einem dies > abnimmt, Völlig richtig. Endlich hast du es verstanden. > ... Aber öffnen wie diese Büchse der Pandora mal lieber nicht. Warum nicht? Könnte es zu Erkenntnis führen?
MaWin schrieb: > 🐧 DPA 🐧 schrieb: >> Das hängt in dem konkreten Beispiel von der Implementierung, und davon >> was "machewas" macht, ab. > > Ah. Komisch. Eben war es noch möglich eine allgemeine Definition zu > haben. Plötzlich ist sie nicht mehr allgemein. Die Definition ist trotzdem noch allgemein. Das konkrete Beispiel ist es nicht. Und nachfolgend habe ich dann ja genauer beschrieben, unter welchen umständen es dort zu Aliasing kommen kann, bei diesem Beispiel. Wenn ich sage, es gibt grüne Wände, und du sagst, dort ist eine Wand, ist die Grün? Dann kann ich allgemein schlussfolgern, dass die Möglichkeit besteht, dass die Wand grün sein könnte. Das macht meine Aussage nicht weniger Allgemein, und es macht Beschreibung nicht weniger spezifisch. Ich kann nichts genaueres sagen, aber ich kann doch etwas dazu sagen. Und beim vorherigen Beispiel, konnte ich doch schon sehr viel dazu sagen.
MaWin schrieb: > Ein > Pointer-Aliasing, wie es C definiert, gibt es in Rust für > mutable-Referenzen nicht. > Würdest du da mitgehen? > > 🐧 DPA 🐧 schrieb: >> Ein fall, wo so etwas aber Konfliktpotenzial bietet, ist bei >> Vergleichen. Falls die Sprache eine Möglichkeit bietet, Referenzen zu >> vergleichen, und die in dem fall dann gleich wären. Wenn diese >> Voraussetzungen gegeben sind, kann man gewisse Fehler machen. > > Es gibt in Rust keine zwei Referenzen, die auf das gleiche Objekt > zeigen, wenn eine oder mehrere davon mutable sind. das sind Beispiele für grosse Unterschiede zu bestehenden Programmiersprachen (C,C++,Java,C#), aber da sich die wenigsten mit diesen Details überhaupt auskennen können sie die Bedeutung sehr einfach als unrelevant empfinden
🐧 DPA 🐧 schrieb: > Die Definition ist trotzdem noch allgemein. Das konkrete Beispiel ist es > nicht. Und nachfolgend habe ich dann ja genauer beschrieben, unter > welchen umständen es dort zu Aliasing kommen kann, bei diesem Beispiel. aber eben nicht in Rust und darum geht doch hier, oder?
MaWin schrieb: > Ein Pointer-Aliasing, wie es C definiert, gibt es in Rust für > mutable-Referenzen nicht. > Würdest du da mitgehen? Wieso sollte ich? Ich habe nie von Pointer-Aliasing, wie es C definiert, geredet, sondern mich auf das zugrundeliegende abstrakte Konzept bezogen. Du fährst dich so darauf fest, das nur im Kontext einer spezifischen Sprache betrachten zu wollen. cppbert schrieb: > aber eben nicht in Rust und darum geht doch hier, oder? Doch, die ist genau so anwendbar. Das C und Rust seine eigene Terminologie und eigene Definitionen vom Begriff haben, ist da nicht relevant.
MaWin schrieb: >> ... Aber öffnen wie diese Büchse der Pandora mal lieber nicht. > > Warum nicht? > Könnte es zu Erkenntnis führen? Was passiert mit Piloten, die immer nur den Autopiloten Fliegen lassen? Sie verlernen es, selbst zu fliegen.
🐧 DPA 🐧 schrieb: > Du fährst dich so darauf fest, Nein. Du redest dich hier raus. > das nur im Kontext einer > spezifischen Sprache betrachten zu wollen. Es geht hier um Rust. 🐧 DPA 🐧 schrieb: > Doch, die ist genau so anwendbar. Ja. Wie gesagt, unter deiner Definition gibt es "Aliasing" in Rust.
🐧 DPA 🐧 schrieb: > Wieso sollte ich? Ich habe nie von Pointer-Aliasing, wie es C definiert, > geredet, sondern mich auf das zugrundeliegende abstrakte Konzept > bezogen. Du fährst dich so darauf fest, das nur im Kontext einer > spezifischen Sprache betrachten zu wollen. das ist aber kein "abstraktes" sondern ein Sprachen-Konzept - das kannst du nicht allgemein definieren - das Rust-Design ist extra so definiert das Aliasing über das Typ-System nicht ausdrückbar ist, Bedeutet: Rust supportet kein Aliasing
🐧 DPA 🐧 schrieb: > Was passiert mit Piloten, die immer nur den Autopiloten Fliegen lassen? > Sie verlernen es, selbst zu fliegen. Rust ist kein Autopilot. Rust ist ein permanenter Fluglehrer, der ständig neben dem Piloten sitzt und Pilotenfehler sofort korrigiert, bevor sie zu Flugfehlern führen.
cppbert schrieb: > das ist aber kein "abstraktes" sondern ein Sprachen-Konzept Du hat doch selbst auf https://en.wikipedia.org/wiki/Aliasing_(computing) verlinkt, wo das auch allgemein gehalten, mit Beispielen in mehreren Sprachen, ist. Natürlich gibt es das als allgemeines, abstraktes Konzept.
cppbert schrieb: > 🐧 DPA 🐧 schrieb: >> Wieso sollte ich? Ich habe nie von Pointer-Aliasing, wie es C definiert, >> geredet, sondern mich auf das zugrundeliegende abstrakte Konzept >> bezogen. Du fährst dich so darauf fest, das nur im Kontext einer >> spezifischen Sprache betrachten zu wollen. > > das ist aber kein "abstraktes" sondern ein Sprachen-Konzept - das kannst > du nicht allgemein definieren - das Rust-Design ist extra so definiert > das Aliasing über das Typ-System nicht ausdrückbar ist, Bedeutet: Rust > supportet kein Aliasing aber natürlich kannst du Aliasing-Probleme in unsafe erzeugen - weil du da (sehr eingeschränkt) C-Semantik hast - aber wir reden nicht von unsafe weil das der geringste Teil des Projektes sein sollte und niemals schlimmer ist als was man mit C machen kann
🐧 DPA 🐧 schrieb: > cppbert schrieb: >> das ist aber kein "abstraktes" sondern ein Sprachen-Konzept > > Du hat doch selbst auf > https://en.wikipedia.org/wiki/Aliasing_(computing) verlinkt, wo das auch > allgemein gehalten, mit Beispielen in mehreren Sprachen, ist. > > Natürlich gibt es das als allgemeines, abstraktes Konzept. natürlich - aber nicht ohne Sprachebezug - somit nicht mehr allgemein/abstrakt
cppbert schrieb: > 🐧 DPA 🐧 schrieb: >> cppbert schrieb: >>> das ist aber kein "abstraktes" sondern ein Sprachen-Konzept >> >> Du hat doch selbst auf >> https://en.wikipedia.org/wiki/Aliasing_(computing) verlinkt, wo das auch >> allgemein gehalten, mit Beispielen in mehreren Sprachen, ist. >> >> Natürlich gibt es das als allgemeines, abstraktes Konzept. > > natürlich - aber nicht ohne Sprachebezug - somit nicht mehr > allgemein/abstrakt Doch, auch ohne Sprachebezug. Wie fängt der Artikel an? Mit "In *computing*". Nicht mit "In Rust" oder mir "In C". Es gibt in dem Artikel auch konkrete Beispiele, aber eben, als Beispiele, nicht als Definition.
🐧 DPA 🐧 schrieb: > Doch, auch ohne Sprachebezug. Wie fängt der Artikel an? Mit "In > *computing*". Nicht mit "In Rust" oder mir "In C". Es gibt in dem > Artikel auch konkrete Beispiele, aber eben, als Beispiele, nicht als > Definition. Du hast ganz doll recht - so lange du nicht wieder von Aliasing in zusammenhang mit (Safe)Rust sprichst, weil es das dort nicht gibt
cppbert schrieb: > aber wir reden nicht von > unsafe weil das der geringste Teil des Projektes sein sollte und niemals > schlimmer ist als was man mit C machen kann Genau. In der Praxis ist der allerkleinste Teil des Projekts unsafe. In den allermeisten meiner Projekte ist gar kein unsafe drin. Und das ist nicht nur bei mir so. Wenn man allerdings unsafe-Rust-Code schreibt, dann ist das deutlich anspruchsvoller korrekt zu tun, als normales C zu schreiben. Vor allem wenn man so Dinge wie Pointer oder Transmutation verwendet oder bewusst gegen RAII verstößt. Der Grund dafür ist, dass man alle Dinge beachten muss, die man in C auch beachten muss. Und zusätzlich muss man noch sicherstellen, dass die Rust-Safety-Garantien eingehalten werden. Und zwar auch im restlichen Safe-Code. Unsafe-Codeabschnitte können Auswirkungen auf Safe-Code haben. Safe-Code darf nicht unsafe werden durch unsafe-Code.
MaWin schrieb: > 🐧 DPA 🐧 schrieb: >> Was passiert mit Piloten, die immer nur den Autopiloten Fliegen lassen? >> Sie verlernen es, selbst zu fliegen. > > Rust ist kein Autopilot. > Rust ist ein permanenter Fluglehrer, der ständig neben dem Piloten sitzt > und Pilotenfehler sofort korrigiert, bevor sie zu Flugfehlern führen. Bei dem konkreten Flugzeugmodell, versteht sich. Da lernt er dieses spezifische Modell zu bedienen. Mehr aber auch nicht. Und manchmal braucht man einen kleinen Crash, ein kleines Desaster, um wirklich zu verstehen, warum man tun muss was man tun muss. cppbert schrieb: > Du hast ganz doll recht - so lange du nicht wieder von Aliasing in > zusammenhang mit (Safe)Rust sprichst, weil es das dort nicht gibt Dann verstehst du das allgemeine Konzept selbst für sich genommen wohl noch nicht richtig.
🐧 DPA 🐧 schrieb: > Bei dem konkreten Flugzeugmodell, versteht sich. Da lernt er dieses > spezifische Modell zu bedienen. Mehr aber auch nicht. Mit dem Erlernen von Rust habe ich mindestens soviel über C/C++ gelernt, wie über Rust. Und ich habe vorher über 20 Jahre C/C++ entwickelt.
🐧 DPA 🐧 schrieb: > cppbert schrieb: >> Du hast ganz doll recht - so lange du nicht wieder von Aliasing in >> zusammenhang mit (Safe)Rust sprichst, weil es das dort nicht gibt > > Dann verstehst du das allgemeine Konzept selbst für sich genommen wohl > noch nicht richtig. ich denke gut genug - da die Definitionen logisch und simpel sind verstehe ich nicht was daran überhaupt unverständlich sein soll
cppbert schrieb: > ich denke gut genug - da die Definitionen logisch und simpel sind > verstehe ich nicht was daran überhaupt unverständlich sein soll aber vielleicht helfen mir da meine geballten 30 Jahren C/C++, Assembler und Reverse-Engineering Erfahrung :)
Mache gerade das Rust Buch durch (doc.rust-lang.org/book), und bis Kapitel 6 war es ja noch ok, aber jetzt wird´s schon etwas seltsam: - enum kann jede Variante andere Daten halten, aber ich komm nicht mehr dran außer mit match. - Match muß aber alle Varianten abdecken also gibt es "other =>" oder auch "_ =>" , naja ob das lesbarer wird? - Damit man das nicht braucht gibts das "if let", das ist ja total abstrus. Let weist eigentlich einer Variable etwas zu, jetzt steht daneben ein "Pattern". Kann ich nicht mehr als lesbar bezeichnen...
Thomas W. schrieb: > Mache gerade das Rust Buch durch (doc.rust-lang.org/book), und bis > Kapitel 6 war es ja noch ok, aber jetzt wird´s schon etwas seltsam: enum ist ein Sum-Type - also ein Variant/Union Type primär ist die Syntax dazu zu da die Mehrfägkeit zu bekommen ohne das auch mehr Probleme bei der Anwendung entstehen bei Union darfst du nicht zwischen den Membern lesend/schreiben springen sonst UB und bei std::variant musst du entweder einen Visitor bauen oder casten - beides ist nicht schön match vereint sicher die C++ enum und std::variant Features - auch wenn der Enum-Sumtype bei Rust aber eher aus dem OCaml Ursprung kommt die meisten empfinden genau das Enum-Sumtype Feature als DAS Rust Feature was sie am meisten lieben - manche erst nach eine gewissen Warmwerdzeit
und auch die "Patterns" sind der absolute Hammer - nicht das es nicht auch anders geht aber die eleganz das alles auf so wenig zu reduzieren finde ich schön
wenn man viel mit C++ Tuples, Variants, Lambdas macht fühlt man sich gleich zuhause - auch wenn Rust gar nicht aus der Welt kommt
Thomas W. schrieb: > Mache gerade das Rust Buch durch (doc.rust-lang.org/book), und bis > Kapitel 6 war es ja noch ok, aber jetzt wird´s schon etwas seltsam: > - enum kann jede Variante andere Daten halten, aber ich komm nicht mehr > dran außer mit match. > - Match muß aber alle Varianten abdecken also gibt es "other =>" oder > auch "_ =>" , naja ob das lesbarer wird? > - Damit man das nicht braucht gibts das "if let", das ist ja total > abstrus. Let weist eigentlich einer Variable etwas zu, jetzt steht > daneben ein "Pattern". Kann ich nicht mehr als lesbar bezeichnen... was du nicht vergessen darfst ist das das alle per default immutable ist - also in C++ gesagt "alles ist const" - das ist ein riesen Vorteil der Sprache und erzwigt implizit auch ein saubere, mehrheitliche State-freieres arbeiten aber ich verstehe es wenn jemand nicht stark aus dieser const/state-less Welt kommt (am besten noch aus einer gar typelosen Welt) das diese ganzen Konzepte vereint schon sich schon ein wenig "unhandlich" anfühlen, weil man den Mehrwert wie implizite const-correctness vielleicht bisher gar nie genutzt hat oder das einem gänzlich fremd ist wenn jemand z.B. viel mit Multithreading und C++ macht ist der Einstieg vergleichsweise einfacher weil Rust die sinnvollen Konzepte aus dem Bereich schon forciert
Ich mochte bei C, das man immer die Typen angeben musste. Da wusste man immer auf einen Blick, womit man es zu tun hat. Was ich auch noch etwas speziell finde, ist das man so Zeugs machen kann 'let x=1; let x="abc";', da muss man also auch noch die richtige finden. Ok, vermutlich helfen IDEs da einem weiter (wobei ich kein Fan von IDEs bin).
DPA schrieb: > Ich mochte bei C, das man immer die Typen angeben musste. Da > wusste man > immer auf einen Blick, womit man es zu tun hat. Was ich auch noch etwas > speziell finde, ist das man so Zeugs machen kann 'let x=1; let > x="abc";', da muss man also auch noch die richtige finden. Ok, > vermutlich helfen IDEs da einem weiter (wobei ich kein Fan von IDEs > bin). da geben ich dir recht ist vergleichbar mit C++/Java/C# auto/var sollte man wirklich nicht zu excessive nutzen sonst blickt man nichts mehr es kommt aber ganz darauf an - in manchen stellen z.B. bei generischer Programmierung kanst du das teilweise einfach nicht - deswegen das Sprachfeature aber ich finde es trotzdem gut das man let x = 1; let x: u32 = 1 let x = 1u32 let x: u32 = 1u32 schreiben kann - wenn man denn will
DPA schrieb: > Ich mochte bei C, das man immer die Typen angeben musste. Wenn ich mich recht erinnere, führt auch C gerade das "auto"-Schlüsselwort in der C++-Bedeutung ein … das kann manchmal ja auch sinnvoll sein. Oft genug sieht man sowas wie:
1 | foo *foop = (foo *)arg; |
wo der Typ zweimal auftauchen muss. Da ist ein
1 | auto foop = (foo *)arg; |
schneller überschaubar. Aber das kann schnell zu "obfuscation" führen, weil der Autor des Codes ja völlig klar wusste, welchen Typ die rechte Seite hat, nur jemand anders, der den Code lesen will, es erst auf die eine oder andere Art recherchieren muss. cppbert schrieb: > aber ich finde es trotzdem gut das man > let x = 1; > let x: u32 = 1 > let x = 1u32 > let x: u32 = 1u32 > schreiben kann - wenn man denn will Sinnvoll benutzt ist das sicher nützlich.
und das ist auch das coole und besondere an Rust Die schaffen es die Basis Konzepte von fast allen System(und auch Hochs)sprachen unter einen Hut (Zero-Cost, Constness/Immuateable by default, Movesemantic by default, No-GC, No-Runtime) zu bringen und dennoch applikationsfreundlich zu bleiben jeder andere Sprachenversuch hat bisher einen oder mehrere dieser Ansprüchen fallen lassen weil die es konzeptionell nicht in ein Design rein bekommen haben - das ist ein Novum auch wenn ich wirklich verstehe das die meisten gar keine Ahnung von den obigen Basis-Konzepten haben und auch deren relevanz kaum bis gar nicht einschätzen können - in Bezug auf Sicherheit, Performanz und Generic (also eben nur wie in vielen Sprachen nur einen Aspekt davon)
cppbert schrieb: > da geben ich dir recht ist vergleichbar mit C++/Java/C# auto/var > sollte man wirklich nicht zu excessive nutzen sonst blickt man nichts > mehr Ich finde es ist nicht vergleichbar mit C++, weil Rust die Typangabe durch den Programmierer auf Funktionsschnittstellen-, struct-, static- und const-var-Ebene forciert. Type inferrence findet nur innerhalb von Funktionen statt. (Lambdas sind eine optionale Ausnahme). Wenn ein Typ vom Compiler hergeleitet wird, dann sieht man in der Regel die Quelle der Herleitung auf der gleichen Bildschirmseite. Und wenn man das immer noch unübersichtlich findet, dann kann man jeder Variablen selbstverständlich auch einen expliziten Typen geben. Bei der Herleitung passiert so gut wie nie etwas Unerwartetes in Rust. Der Grund dafür ist das sehr strikte Typsystem. Im Gegensatz zu C++. Da hat man implizite Konvertierungen und Promotionsregeln. Das macht es manchmal sehr schwer zu sagen, welchen Typ eine Variable wirklich hat. Das ist in Rust anders. Wenn man sehr generischen Code schreibt, dann kann es schon manchmal schwerer werden den Typ von Variablen zu erkennen. Aber auch das ist meist nicht schlimm. Denn wenn man diese Variable, oder einen davon errechneten Variable, dann aus der Funktion rückgibt oder in ein struct schreibt, dann bricht der Compiler durch fehlende implizite Konvertierungsmechanismen bei einem Typ-mismach an. cppbert schrieb: > in manchen stellen z.B. bei generischer > Programmierung kanst du das teilweise einfach nicht - deswegen das > Sprachfeature Doch. Bei generischer Programmierung hat man in Rust immer einen generischen Typen. Den kann man dann auch angeben, wenn man möchte. Muss man aber eher selten. Aber ich mache es schon manchmal. Vor allem, wenn ein impl mehrere generische Typen hat. Ein generischer Typ ist nicht nur ein Platzhalter. Es ist ein Typ mit ganz klar definierten statisch festgelegten Eigenschaften. Generische Typen sind, anders als in C++, in Rust stark constrained. Man muss in Rust generische Typen mit der where-clause soweit einschränken, dass alle tatsächlich durchgeführten Operationen auf ebenjenen Typ abgedeckt sind. Wenn man das nicht macht, kann man überhaupt nichts mit dem Typ machen. Wenn man zwei Variablen generischen Typs addiert, dann muss dieser generische Typ im where-clause auf das Add-Trait eingeschränkt sein. d.h. der Typ kann nur einer sein, der auch tatsächlich exakt dieses Trait implementiert. Das wird alles schon bei der Implementierung der generischen Funktion festgezurrt. (In C++ wird das fast alles erst viel später bei der Instanziierung aufgelöst). Bei der Instanziierung wird dann wiederum festgezurrt, dass der tatsächliche Typ auch tatsächlich alle geforderten Traits implementiert. Ein generischer Typ monomorphiert immer bei der Instanziierung in genau einen konkreten tatsächlichen Typ.
MaWin schrieb: > cppbert schrieb: >> da geben ich dir recht ist vergleichbar mit C++/Java/C# auto/var >> sollte man wirklich nicht zu excessive nutzen sonst blickt man nichts >> mehr > > Ich finde es ist nicht vergleichbar mit C++, weil Rust die Typangabe > durch den Programmierer auf Funktionsschnittstellen-, struct-, static- > und const-var-Ebene forciert. Type inferrence findet nur innerhalb von > Funktionen statt. (Lambdas sind eine optionale Ausnahme). ja sorry das vergesse ich immer - im Ergebnis verhält es sich ähnlich, aber es ist doch viel strikter z.b. erzeugt auto nicht ungewillt Kopien - was bei C++ immer mal gern passiert oder häufig von Anfängern falsch gemacht wird - da Rust implizit moved und nur explizit kopiert kann das in Rust gar nicht passieren > cppbert schrieb: >> in manchen stellen z.B. bei generischer >> Programmierung kanst du das teilweise einfach nicht - deswegen das >> Sprachfeature > > Doch. Bei generischer Programmierung hat man in Rust immer einen > generischen Typen. Den kann man dann auch angeben, wenn man möchte. Muss > man aber eher selten. > Aber ich mache es schon manchmal. Vor allem, wenn ein impl mehrere > generische Typen hat. > > Ein generischer Typ ist nicht nur ein Platzhalter. Es ist ein Typ mit > ganz klar definierten statisch festgelegten Eigenschaften. > > Generische Typen sind, anders als in C++, in Rust stark constrained. > Man muss in Rust generische Typen mit der where-clause soweit > einschränken, dass alle tatsächlich durchgeführten Operationen auf > ebenjenen Typ abgedeckt sind. ja sorry - ich meinte eher das du keinen expliziten "Basis"-Typ angeben kannst (oder es recht wenig sinn macht) - und ja die where clausen (vergleichbar mit C++ Konzepts) verhindern zwangsweise die typischen C++ Template-Error-Wolken
Ein wichtiger weiterer Punkt, warum Type Inference in Rust viel besser nachvollziehbar ist, als in C++: Es gibt keine Methoden- und Funktionsüberladungen und keine Klassenhierarchien. Es ist viel einfacher nachzuvollziehen, was tatsächlich aufgerufen wird. Das klassische OOP-Problem, wo eine Methode 10 mal abgeleitet und auch noch 5 mal überladen ist, existiert in Rust nicht. Es ist zwar manchmal nicht ganz auf den ersten Blick zu erkennen, zu welchem Trait ein Funktionsaufruf gehört. Aber in der Doku, die man mit Cargo aus jedem Stück Rust-Code generieren kann, wird dem Entwickler das dann gut und eindeutig erklärt. Dazu ist es nicht notwendig, dass jemand das manuell irgendwo dokumentiert. Und wenn man dann immer noch nicht weiß, welchen Typ eine Variable hat, dann kann man den Rust-Compiler ganz einfach fragen: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2d69f5a260259c365c4e0ac0913eff0e
Als Fan von Pascal/Delphi und weniger von C, beobachte ich die Entwicklung auch mi Interesse. Auch im Freepascal Forum gibt es dazu gerade eine Vergleichsdiskussion, ob und wie sich Rust von Pascal unterscheidet https://forum.lazarus.freepascal.org/index.php/topic,54311.0.html
Peter K. schrieb: > Auch im Freepascal Forum gibt es dazu gerade eine Vergleichsdiskussion, letzer Post vom "April 25, 2021, 09:56:15 AM" ist aber nicht so aktuell
MaWin schrieb: > Und wenn man dann immer noch nicht weiß, welchen Typ eine Variable hat, > dann kann man den Rust-Compiler ganz einfach fragen: > > https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2d69f5a260259c365c4e0ac0913eff0e An so Informationen kommt man bei C++ auch nur mit kleinen Tricks :) ich hoffe das Rust in dem Bereich sehr viel stärker aus den C++ Fehlern lernt und die Fähigkeiten generischer zu programmieren auch mit den entsprechenden Tools unterfüttert um das einfach/schnell wartbar/verständlich zu halten
cppbert schrieb: > An so Informationen kommt man bei C++ auch nur mit kleinen Tricks :) Das macht bei Rust der rust-analyser. Der Zeigt bei jeder Variablen den Typ an. Gibt es als Plugin für VSCode.
cppbert schrieb: > ich hoffe das Rust in dem Bereich sehr viel stärker aus den C++ Fehlern > lernt und die Fähigkeiten generischer zu programmieren auch mit den > entsprechenden Tools unterfüttert um das einfach/schnell > wartbar/verständlich zu halten Ja also, ich sag mal so. Diesen Trick braucht man so gut wie nie. Aber wenn, dann ist es hilfreich zu wissen. Generell ist der Rustcompiler sehr viel besser in der Fehlerausgabe als z.B. der g++. Der Rustcompiler gibt bekannte Typinformationen zwar aus, aber überhäuft den Programmierer in der Regel nicht mit ellenlangen Typbeschreibungen (g++ ist da auch schon besser geworden). In der Regel gibt der Rustcompiler sogar eine Vorschlag, was der Programmierer vermutlich meinte. Oft ist das sogar schon richtig oder fast richtig oder gibt einem wenigstens einen Schubs in die richtige Richtung. Und dann hat jeder Compilerfehler auch noch eine eigene ID und einen Link auf eine manpage/website, wo der Fehler und seine möglichen Gründe noch einmal genauer und mit Beispielen beschrieben wird. Vom Fehlerdiagnoseverhalten ist der Rustcompiler so ziemlich das Beste, was ich kenne.
MaWin schrieb: > Generell ist der Rustcompiler sehr viel besser in der Fehlerausgabe als > z.B. der g++. Das ist jetzt aber auch keine allzu große Herausforderung... ;-)
>keine allzu große Herausforderung Der Rust Compiler umarmt einen und tröstet einen wenn man einen Fehler gemacht hat! https://youtu.be/vcFBwt1nu2U?t=2223
foo schrieb: > Der Rust Compiler umarmt einen und tröstet einen wenn man einen Fehler > gemacht hat! :) Nur mal so als Beispiel: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1c37c420e4f69cc62c6bf1272793321c Ich wüsste jetzt nicht, wie man das noch verständlicher und besser machen könnte.
MaWin schrieb: > Ich wüsste jetzt nicht, wie man das noch verständlicher und besser > machen könnte. Ich schon. ;-) Der Unterstrich wird an vielen Stellen als Gruppierungszeichen genutzt (auch wenn C++ und nun C sich für den Apostroph entschieden haben). Ich hätte daher sowas wie
1 | let c = i32: 42; |
lesbarer gefunden, um den Typ einer Zahl zu benennen. (Ja, erinnert an Pascal. ;-) Aber nur, weil du gefragt hast …
Jörg W. schrieb: > Ich hätte daher sowas wie > let c = i32: 42; > > lesbarer gefunden, um den Typ einer Zahl zu benennen. So kann man es ja in Rust auch machen:
1 | let c: i32 = 42; |
2 | let d = 42 as i32; |
Jörg W. schrieb: > Aber nur, weil du gefragt hast … Leider wieder auf eine Frage geantwortet, die gar nicht gestellt wurde. Es ging um die Fehlermeldungen.
Jörg W. schrieb: > Ich hätte daher sowas wie > let c = i32: 42; > > lesbarer gefunden, um den Typ einer Zahl zu benennen. (Ja, erinnert an > Pascal. ;-) Sorry aber das erinnert niemanden an Pascal weil der Typ bei Pascal doch immer rechts vom Doppelpunkt steht ;-) Rust entspricht bis auf das "let" exakt der Pascal-schreibweise
1 | Rust:
|
2 | let c: i32 = 42; |
3 | |
4 | Pascal: |
5 | c: integer = 42; |
Kaj schrieb: > So kann man es ja in Rust auch machen: >
1 | > let c: i32 = 42; |
2 | > let d = 42 as i32; |
3 | > |
Finde ich zumindest besser lesbar als die Unterstriche.
Jörg W. schrieb: > Finde ich zumindest besser lesbar als die Unterstriche. meinst du das Beipspiel von MaWin mit let _: () = x; das ist ein Spezial-Sonder-Case den du selten in freier Wildbahn sehen wirst
Jörg W. schrieb: > Finde ich zumindest besser lesbar als die Unterstriche.
1 | let a = 9_882_223_112; |
2 | let a = 9_882_223_112_i64; |
3 | let a = 9882223112_i64; |
4 | let a = 9882223112i64; |
5 | let a: i64 = 9882223112; |
6 | let a: i64 = 9_882_223_112; |
7 | //...usw... |
Was davon jetzt besser lesbar ist, ist vollkommen dir überlassen. Du kannst alle Schreibweisen verwenden. Unterstriche können fast beliebig platziert und weggelassen werden.
Jörg W. schrieb: > Finde ich zumindest besser lesbar als die Unterstriche. Bei Konstanten und globalen Variablen muss man es sogar so angeben:
1 | const VAR: Type = value; |
2 | static var: Type = value; |
Kaj schrieb: > Jörg W. schrieb: >> Finde ich zumindest besser lesbar als die Unterstriche. > Bei Konstanten und globalen Variablen muss man es sogar so angeben:const > VAR: Type = value; > static var: Type = value; kann einer sagen warum "const x = 123i32" nicht genug ist?
cppbert schrieb: > kann einer sagen warum "const x = 123i32" nicht genug ist? Weil geschwätzige Syntax wieder im Trend liegt? Ich hätte auch nicht gedacht dass jemand nochmal ernsthaft das alte Basic-Style "let" aufwärmt. Aber hey, die Rustler kennen da nix.
cppbert schrieb: > kann einer sagen warum "const x = 123i32" nicht genug ist? Weil man dann Type Inferrence bemühen müsste, was in einigen Fällen (nicht in diesem) interessante Probleme gibt. z.B. zyklische Typabhängigkeiten. Es ist eine Designentscheidung, dass alle toplevel-APIs ohne Type Inferrence typisiert werden müssen. Damit gewinnt man eine vollständige Kontextunabhängigkeit auf dieser Ebene. In Rust ist es sehr wichtig, dass die Größe von Typen bekannt ist, oder dass bekannt ist, dass die Größe dynamisch ist. Unbekannte Größen sind ein Problem und müssen so schnell wie möglich vom Compiler aufgelöst werden.