Announcement: there is an English version of this forum on 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:
--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....
echo "main() {}" > hello.c clang hello.c #OK, da faellt ein a.out raus. clang -target arm-none-eabi hello.c 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:
$ rustup target list aarch64-apple-ios aarch64-fuchsia aarch64-linux-android aarch64-pc-windows-msvc aarch64-unknown-cloudabi aarch64-unknown-linux-gnu aarch64-unknown-linux-musl arm-linux-androideabi arm-unknown-linux-gnueabi arm-unknown-linux-gnueabihf arm-unknown-linux-musleabi arm-unknown-linux-musleabihf armebv7r-none-eabi armebv7r-none-eabihf armv5te-unknown-linux-gnueabi armv5te-unknown-linux-musleabi armv7-apple-ios armv7-linux-androideabi armv7-unknown-linux-gnueabihf armv7-unknown-linux-musleabihf armv7r-none-eabi armv7r-none-eabihf armv7s-apple-ios asmjs-unknown-emscripten i386-apple-ios i586-pc-windows-msvc i586-unknown-linux-gnu i586-unknown-linux-musl i686-apple-darwin i686-linux-android i686-pc-windows-gnu i686-pc-windows-msvc i686-unknown-freebsd i686-unknown-linux-gnu i686-unknown-linux-musl mips-unknown-linux-gnu mips-unknown-linux-musl mips64-unknown-linux-gnuabi64 mips64el-unknown-linux-gnuabi64 mipsel-unknown-linux-gnu mipsel-unknown-linux-musl powerpc-unknown-linux-gnu powerpc64-unknown-linux-gnu powerpc64le-unknown-linux-gnu riscv32imac-unknown-none-elf riscv32imc-unknown-none-elf s390x-unknown-linux-gnu sparc64-unknown-linux-gnu sparcv9-sun-solaris thumbv6m-none-eabi thumbv7em-none-eabi thumbv7em-none-eabihf thumbv7m-none-eabi wasm32-unknown-emscripten wasm32-unknown-unknown x86_64-apple-darwin x86_64-apple-ios x86_64-fuchsia x86_64-linux-android x86_64-pc-windows-gnu (installed) x86_64-pc-windows-msvc x86_64-rumprun-netbsd x86_64-sun-solaris x86_64-unknown-cloudabi x86_64-unknown-freebsd x86_64-unknown-linux-gnu (default) x86_64-unknown-linux-gnux32 x86_64-unknown-linux-musl x86_64-unknown-netbsd 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.
fn main() {
let mut _x: u8 = 255;
_x += 1;
}
|
Kommt es bei der Ausfuehrung zum ueberlauf stuerzt das Programm ab.
thread 'main' panicked at 'attempt to add with overflow', src/main.rs:3:5 |
Schreibt man das ganze so:
fn main() {
let mut _x: u8 = 255;
_x = _x.wrapping_add(1);
}
|
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
Once you have a local instance of crates.io running at http://localhost:4200 by following the instructions in the "Working on the Backend" section, you can go to another Rust project 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
Cargo is a tool that allows Rust packages to declare their various
dependencies and ensure that you’ll always get a repeatable build.
To accomplish this goal, Cargo does four things:
Introduces two metadata files with various bits of package information.
Fetches and builds your package’s dependencies.
Invokes rustc or another build tool with the correct parameters to
build your package.
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
Although you can’t remove previous versions of a crate, you can prevent any future projects from adding them as a new dependency. This is useful when a crate version is broken for one reason or another. In such situations, Cargo supports yanking a crate version. Yanking a version prevents new projects from starting to depend on that version while allowing all existing projects that depend on it 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
Cross-language LTO is a new feature in the Rust compiler that enables LLVM's link time optimization to be performed 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
... 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: Youtube-Video "RustConf 2019 - Taking Constant Evaluation to the Limit by Oliver Schneider" 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.
Thread beobachten
Seitenaufteilung abschalten