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".
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
Moin,
Silvano C. schrieb:> Das wäre bei Rust sicher nicht das Problem, da Rust auf das LLVM-Backend> setzt
Naja, mal gucken: Fuer ein C Programm brauchst du z.b. einen
gcc+binutils. gcc ist abhaengig von (Kernel und einer) libc.
Um einen llvm zu bauen,brauchste python, cmake und einen gcc. Also
mindestens schon einen c++ compiler, sonst wirds nix mit cmake
(wahrscheinlich auch fuer Python). Python hat die angenehme Eigenschaft,
in Geschmacksrichtung (2 und 3) herzukommen; im Zweifelsfall brauchts
dann auch immer beide.
Um rust zu bauen brauchste llvm und einen riesenhaufen Zeugs, der so
riesig und komplex ist, dass das automatisch irgendwie von irgendwoher
runtergeladen werden muss. Und dann noch diversen anderen, nicht so
exotischen Kram wie auch wieder Python und libssh.
Jetzt kann man sich natuerlich als z.B. Ubuntu-Aeffchen auf den
Standpunkt stellen: Ist mir alles wurscht. Ich hab's voll drauf, denn so
wie Windowsprofis auf jede setup.exe klicken koennen, kann ich ja
einfach "sudo apt-get gedoens" tippern und alles wird immer gut!einself!
Aber wenn man dann und wann auch mal Software fuer nicht-mainstream
Platformen haben will, kann's schonmal beliebig bloed werden mit dem
Herbeizaubern einer (ggf. cross-)toolchain und was man sonst noch an
Umgebung braucht. Und da bin ich persoenlich echt froh, wenn's nicht so
irrsinnig ausufert, nur weil unbedingt irgendwer irgendwelchen heissen
Scheiss ausprobieren musste.
Aber das ist nur meine kleine, beschraenkte Meinung, Profi-Informatiker
sehen das sicherlich ganz anders.
(Ocaml war glaub' ich auch mal ziemlich hipp, iirc gabs irgendwelches
Filesharing-Zeugs was in Ocaml geschrieben war.)
Gruss
WK
Dergute W. schrieb:> und wann auch mal Software fuer nicht-mainstream Platformen haben will,> kann's schonmal beliebig bloed werden mit dem Herbeizaubern einer (ggf.> cross-)toolchain
Konnte nicht eine LLVM-Installation automatisch für alle Targets Code
generieren?
Also die Komplexität des Bauens des Compilers ist ein ziemliches Dummy
Argument. Einen GCC mit allen benötigten libc-Varianten zu bauen ist
auch ganz schön zum Haare raufen.
Dr. Sommer schrieb:> Konnte nicht eine LLVM-Installation automatisch für alle Targets Code> generieren?> Also die Komplexität des Bauens des Compilers ist ein ziemliches Dummy> Argument. Einen GCC mit allen benötigten libc-Varianten zu bauen ist> auch ganz schön zum Haare raufen.
Ja. Im Gegensatz zum GCC ist das ein Cross-Compiler in sich und benötigt
nicht für jede Architektur einen eigenen Build. Mal abgesehn von der
Schwachsinnigkeit des Arguments hat GCC übrigens wesentlich mehr
(legacy) Abhängikeiten als LLVM und rustc.
Meiner Meinung nach ist Rust hier um zu bleiben. Das liegt zum einen
daran weil die Community über die "critical mass" hinaus gewachsen ist
und zum anderen weil Rust als WebAssembly Sprache wohl für viele sehr
attraktiv sein wird.
Moin,
Dr. Sommer schrieb:> Einen GCC mit allen benötigten libc-Varianten zu bauen ist> auch ganz schön zum Haare raufen.
Eigentlich reicht ja eine. Aber OK, auch die kann schmerzhaft sein. Nur,
wenn das schon nicht klappt, wie wirds dann llvm und "schlimmeres"
geben?
Vincent H. schrieb:> Ja. Im Gegensatz zum GCC ist das ein Cross-Compiler in sich und benötigt> nicht für jede Architektur einen eigenen Build.
Das klingt interessant. Haste mal ein Beispiel, wie man so auf die
Schnelle mit einem llvm aufm x86_64 PC so was ganz simples wie ein
HelloWorld fuer eine gaengige Architektur wie z.b. ARM crosskompilieren
kann?
> Mal abgesehn von der> Schwachsinnigkeit des Arguments hat GCC übrigens wesentlich mehr> (legacy) Abhängikeiten als LLVM und rustc.
OK, und was waeren das fuer "(legacy) Abhängigkeiten"?
Vincent H. schrieb:> Meiner Meinung nach ist Rust hier um zu bleiben. Das liegt zum einen> daran weil die Community über die "critical mass" hinaus gewachsen ist> und zum anderen weil Rust als WebAssembly Sprache wohl für viele sehr> attraktiv sein wird.
Naja, die verwendete Sprache sollte halt zum zu loesenden Problem
passen. Da kanns schon sein, dass jetzt moderner Webkram mit Rust die
tollste Wurst ist.
Ich sag' nochmal: Wenn man sicher ist, sich jederzeit mit "sudo apt-get
install", setup.exe oder aehnlich "evelynesken" Kommandos die benoetigte
Umgebung herzaubern kann, dann ist das alles simpel.
Nachdem aber im Eroeffnungspost explizit ein Zeitraum von 10 Jahren
angegeben wurde, hab' ich halt so meine Zweifel an rust. Aber natuerlich
kann ich nicht in die Zukunft blicken, nur aus der Vergangenheit
versuchen zu interpolieren...
Gruss
WK
Dergute W. schrieb:> Das klingt interessant. Haste mal ein Beispiel, wie man so auf die> Schnelle mit einem llvm aufm x86_64 PC so was ganz simples wie ein> HelloWorld fuer eine gaengige Architektur wie z.b. ARM crosskompilieren> kann?
Man muss dem Compiler lediglich das Target als flag übermitteln. Also in
etwa so:
1
--target=arm-none-eabi-march=armv7e-m
Default ist natürlich x86.
> OK, und was waeren das fuer "(legacy) Abhängigkeiten"?
isl und gmp fallen mir da ein...
und da gabs noch ein paar so lustige Acronmy wo man sich erstmal denkt
"hä?"
Und wenn man schon auf Python rumhakt. Braucht GCC nicht Perl?
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".
Hm, ok - also was kann denn mein clang fuer Targets?
Uuupsi:
https://stackoverflow.com/questions/15036909/clang-how-to-list-supported-target-architectures
Scheint garnicht so simpel zu sein, das rauszukriegen...(Bloss gut dass
ich ihn selbergebaut hab', da weiss ich's noch).
Es ist also keinesfalls so, dass da automatisch immer alle crosscompiler
mitdrinnen sind. Das muss beim Bau angegeben sein.
Und genau solche Sachen erzeugen bei mir die Skepsis. Jeder blubberts
nach, weils irgendwo steht, aber wenn man's dann wirklich ausprobieren
will, wirds schnell zaeh'.
Vincent H. schrieb:> isl und gmp fallen mir da ein...
OK, ohne isl und diverse andere Gimmicks lassen sich sehr wohl gccs
bauen.
mpfr, gmp, mpc - ja klar, irgendwie muss der compiler konstante
Ausdruecke ja auch berechnen koennen. Ich wuesst' nicht, wie llvm ums
berechnen beim compilieren rumkommt. Vielleicht macht er's so wie alte
gccs und hat den ganzen Schmonz irgendwo festeingebaut.
Ich sag' mal: An dem Tag, wo ein LFS/BLFS artiges Projekt rauskommt, bei
dem nicht mit gcc usw. angefangen wird, sondern mit rustc und mit dem
dann llvm und danach evtl noch gcc gebaut wird - da bin ich auch
ueberzeugt, dass rust eine tolle Dauerwurst ist. vorher eher noch nicht
:-)
Gruss
WK
Wenn BLFS und Co für dich die Messlatte für etablierte Sprachen ist,
dann wirst du am Sterbebett noch mit K&R C zu tun haben (müssen). ;)
Dafür dass du bei deinen Builds alle Targets rausnimmst kann ja ich nix.
Dergute W. schrieb:> Eigentlich reicht ja eine
Eine für Soft float, eine für vfp4-sp-d16, eine für vfp4-dp-d16,
vfp3-sp-d16, ...
Dergute W. schrieb:> moderner Webkram mit Rust
Rust ist nicht für Web. Das ist für performante Low-Level Codes. Also
hauptsächlich als C und C++ Ersatz.
Und wenn man unbedingt ein LLVM für ein exotisches Target/Host bauen
will, kann man das ja unter einem Ubuntu tun, wo man alles per apt-get
installiert hat. Wenn man's richtig macht läuft das dann überall.
Das Build Script für den GCC-ARM-Embedded ist auch ein paar kLoC lang.
Ist wohl doch nicht so einfach. Den Rattenschwanz an Dependencies lädt
es manuell runter. Es funktioniert auch nur unter Ubuntu, und nur unter
32bit. Executables für Win64 kann es nicht erstellen. Da ist auch nicht
alles in Butter...
Von rust werden momentan diese Architekturen unterstuetzt:
1
$ rustup target list
2
aarch64-apple-ios
3
aarch64-fuchsia
4
aarch64-linux-android
5
aarch64-pc-windows-msvc
6
aarch64-unknown-cloudabi
7
aarch64-unknown-linux-gnu
8
aarch64-unknown-linux-musl
9
arm-linux-androideabi
10
arm-unknown-linux-gnueabi
11
arm-unknown-linux-gnueabihf
12
arm-unknown-linux-musleabi
13
arm-unknown-linux-musleabihf
14
armebv7r-none-eabi
15
armebv7r-none-eabihf
16
armv5te-unknown-linux-gnueabi
17
armv5te-unknown-linux-musleabi
18
armv7-apple-ios
19
armv7-linux-androideabi
20
armv7-unknown-linux-gnueabihf
21
armv7-unknown-linux-musleabihf
22
armv7r-none-eabi
23
armv7r-none-eabihf
24
armv7s-apple-ios
25
asmjs-unknown-emscripten
26
i386-apple-ios
27
i586-pc-windows-msvc
28
i586-unknown-linux-gnu
29
i586-unknown-linux-musl
30
i686-apple-darwin
31
i686-linux-android
32
i686-pc-windows-gnu
33
i686-pc-windows-msvc
34
i686-unknown-freebsd
35
i686-unknown-linux-gnu
36
i686-unknown-linux-musl
37
mips-unknown-linux-gnu
38
mips-unknown-linux-musl
39
mips64-unknown-linux-gnuabi64
40
mips64el-unknown-linux-gnuabi64
41
mipsel-unknown-linux-gnu
42
mipsel-unknown-linux-musl
43
powerpc-unknown-linux-gnu
44
powerpc64-unknown-linux-gnu
45
powerpc64le-unknown-linux-gnu
46
riscv32imac-unknown-none-elf
47
riscv32imc-unknown-none-elf
48
s390x-unknown-linux-gnu
49
sparc64-unknown-linux-gnu
50
sparcv9-sun-solaris
51
thumbv6m-none-eabi
52
thumbv7em-none-eabi
53
thumbv7em-none-eabihf
54
thumbv7m-none-eabi
55
wasm32-unknown-emscripten
56
wasm32-unknown-unknown
57
x86_64-apple-darwin
58
x86_64-apple-ios
59
x86_64-fuchsia
60
x86_64-linux-android
61
x86_64-pc-windows-gnu (installed)
62
x86_64-pc-windows-msvc
63
x86_64-rumprun-netbsd
64
x86_64-sun-solaris
65
x86_64-unknown-cloudabi
66
x86_64-unknown-freebsd
67
x86_64-unknown-linux-gnu (default)
68
x86_64-unknown-linux-gnux32
69
x86_64-unknown-linux-musl
70
x86_64-unknown-netbsd
71
x86_64-unknown-redox
AVR soll auch unterstuetzt werden, sobald das AVR Backend fehlerfreier
ist. Solange gibt es das avr-rust projekt.
Der Buildprozess ist mit cargo super angenehm. Man hat eine gewisse
Sicherheit was Rebuild-Sicherheit angeht, da alle veroeffentlichen
Versionen eines Crates immer wieder runterladbar sind. Man kan alte
Versionen extra markieren, womit diese nicht mehr fuer neue projekte
verwendet werden koennen, aber fuer alte projekte erhalten bleiben.
Arbeitet man mit den Crates von crates.io dann ist auch die verwaltung
der abhaengigkeiten sehr einfach. Das Oekosystem ist meiner Meinung nach
das groesste Plus bei Rust.
Durch die Gestaltung von Rust ist der Code sehr aussagekraeftig.
1
fn main() {
2
let mut _x: u8 = 255;
3
_x += 1;
4
}
Kommt es bei der Ausfuehrung zum ueberlauf stuerzt das Programm ab.
1
thread 'main' panicked at 'attempt to add with overflow', src/main.rs:3:5
Schreibt man das ganze so:
1
fn main() {
2
let mut _x: u8 = 255;
3
_x = _x.wrapping_add(1);
4
}
ist alles gut und man bekommt seinen ueberlauf. Die Sprache schuetzt zum
einem vor dem Fehler von ungewollten ueberlaeufen, und zum anderen
bietet sie die moeglichkeit eines gewollten ueberlaufs, was man dann
aber auch so im code ausdruecken muss. Das traegt doch ungemein zum
verstaendis von fremdcode bei. Neben wrapping_add() gibt es noch andere
funktionen, die einem dann auch noch sagen ob es einen ueberlauf gab.
Wie viele threads gibt es hier, wo sich drueber gestritten wird wie man
in c oder c++ am besten und sichersten einen ueberlauf feststellt...
Die generierte Doku gefaellt mir deutlich besser, als das was ich bisher
bei anderen Sprachen gesehen habe.
Unit-Tests (und auch benchmark-tests) sind gleich mit dabei, und man
kann auch private Methoden testen, ohne sich einen abbrechen zu muessen.
Mit rustfmt kann man den Code entsprechend den Rustguidlines formatieren
lassen. Unter Visual Studio Code laesst sich Rust genauso einfach wie C
oder C++ debuggen.
Ja, einige konzepte sind sehr ungewoht wenn man von c/c++ kommt (hallo
borrow-checker, mein freund...), aber das ist okay.
Es gibt praktisch keinen Grund, Rust nicht mal wenigstens eine
ernsthafte chance zu geben. Und mit ernsthaft meine ich, dass man sich
schon mal 1 Monat etwas intensiver mit Rust beschaeftigt haben sollte.
Meiner Meinung nach ist Rust die beste alternative zu C und C++, wenn es
um low-level geht, besonders weil sie auch viele embedded targets
unterstuetzt. Ebenso denke ich, das Rust in zukunft noch eine grosse
Rolle spielen wird, wenn es um sichere Software geht.
Ja, Rust ist gekommen um zu bleiben.
Rust wird bleiben, da die Lizenz von LLVM frei genug ist um LLVM auch in
proprietärer Software einzubauen und somit den langfristigen Support von
LLVM und seiner Front- und Backends auch durch Firmen mit Geld in der
Tasche und Manpower sicherzustellen.
Ein paar Dutzend an Compilern braucht es zum überleben der Sprache also
da gar nicht zwingend, obwohl es die sicher auch geben wird, sondern nur
die richtige Lizenz für den Marktrelevanten Compiler.
Zum Vergleich bei Java nimmt man für die x86 Architektur entweder den
Compiler von Oracle Java oder OpenJDK und dann kommt eine Weile nichts
mehr, obwohl es noch andere Implementationen gibt.
Bei C# ist es nicht viel anders.
LLVM wird also vor allem auch aufgrund seiner unproblematischen Lizenz
das alles alleine stemmen können und das auch langfristig.
Außerdem werden die Backends, also der Teil der den
architekturspezifischen Maschinen- oder VM Code erstellt, vom Rust
Frontent komplett unabhängig entwickelt.
Allein das sorgt schon dafür das die Entwicklung weitgehend
zukunftsicher ist, es müssen sich nur genug Leute finden die das
Frontend von Rust pflegen und das ist durch die freie Lizenz, die auch
Firmen mit ins Boot holt gesichert.
Dazu kommen noch die Vorteile der Sprache selbst bezüglich
Speicherschutz und Multi CPU Fähigkeit hinzu, die die Sprache für
Programmierer extrem attraktiv macht.
Ich mache mir da keine Sorgen. Zum Vergleich, die Zukunftsicherheit von
bspw. D ist weit weniger gewiss.
Nano schrieb:> LLVM wird also vor allem auch aufgrund seiner unproblematischen Lizenz> das alles alleine stemmen können und das auch langfristig.>> Außerdem werden die Backends, also der Teil der den> architekturspezifischen Maschinen- oder VM Code erstellt, vom Rust> Frontent komplett unabhängig entwickelt.> Allein das sorgt schon dafür das die Entwicklung weitgehend> zukunftsicher ist, es müssen sich nur genug Leute finden die das> Frontend von Rust pflegen und das ist durch die freie Lizenz, die auch> Firmen mit ins Boot holt gesichert.>> Dazu kommen noch die Vorteile der Sprache selbst bezüglich> Speicherschutz und Multi CPU Fähigkeit hinzu, die die Sprache für> Programmierer extrem attraktiv macht.
Sehe ich genauso.
Mittlerweile nutzen einige Programmiersprachen (respektive deren
Compiler) LLVM:
-ActionScript
-Ada
-C#
-Common Lisp
-Crystal
-CUDA
-D
-Delphi
-Fortran
-Graphical G Programming Language
-Halide
-Haskell
-Java bytecode
-Julia
-Kotlin
-Lua
-Objective-C
-OpenGL Shading Language
-Pony
-Python
-R
-Ruby
-Rust
-Scala
-Swift
-Xojo
(https://en.wikipedia.org/wiki/LLVM)
Ich denke also nicht das LLVM so schnell verschwinden wird.
Auch auf Rust basieren mittlerweile einige Projekte, welche auch diese
zum bleiben einladen:
-Firefox (zu mindestens Teile davon, bald auch die WebEngine)
-Microsoft Azure
-Stratis
-Railcar
Kaj schrieb:> Ja, Rust ist gekommen um zu bleiben.
Das denke ich auch
Silvano C. schrieb:> Mittlerweile nutzen einige Programmiersprachen (respektive deren> Compiler) LLVM:
Und natürlich auch C und C++! Clang ist eine ernstzunehmende Konkurrenz
für GCC. Man könnte sogar sagen dass die Konkurrenz durch Clang die
Entwicklung von GCC sogar auch beschleunigt hat...
Silvano C. schrieb:> Ich denke also nicht das LLVM so schnell verschwinden wird.> Auch auf Rust basieren mittlerweile einige Projekte, welche auch diese> zum bleiben einladen:> -Firefox (zu mindestens Teile davon, bald auch die WebEngine)> -Microsoft Azure> -Stratis> -Railcar
Mittelfristig wird sicherlich noch Thunderbird dazukommen.
Ich wuerde sagen: Rust ist wie C/C++, nur in "besser" -> mit weniger
(Laufzeit)-Fallstricken und an die Zeit angepasst. Eine low level
Sprache bei der man erkennen kann: Ja, wir haben aus den letzten 40
Jahren Softwareentwicklung etwas gelernt (auch wenn es mit sicherheit
nicht perfekt ist).
Die Entwicklung von Rust begann 2006, also vor 13 Jahren und wird seit
2009 von Mozilla gesponsort. Seit 2012 gibt es offizielle Releases mit
Versionsnummer. Das angehängte Diagramm zeigt die Veröffentlichungsdaten
der Minor-Releases (d.h. mit einer Versionsnummer der Form x.y oder
x.y.0) seit 2012. Man sieht, dass die Release-Frequenz stetig zunimmt.
Allein letztes Jahr gab es 18 Releases, also etwa alle 20 Tage eines.
Das ist ein starkes Indiz dafür, dass sehr intensiv an dem Projekt
gearbeitet wird. Ein Projekt, wo 13 Jahre lang so viel Arbeit
hineingesteckt wurde, kommt nicht so schnell zum Stillstand. Laut Github
arbeiten 88 Leute daran, so dass auch der Ausfall einzelner Personen
kein unüberwindliches Problem darstellen sollte. Selbst wenn Mozilla die
finanzielle Förderung einstellen sollte, wird das die Entwicklung zwar
verlangsamen, ich kann mir aber nicht vorstellen¸ dass sich die
Entwickler komplett aus dem Projekt zurückziehen und damit ihre
langjährigen Arbeit in die Tonne treten werden.
IMHO wird Rust innerhalb der nächsten 10 Jahre nicht eine der
Mainstream-Sprachen werden wie heute bspw. C, C++, Java und Python, es
wird aber sehr wahrscheinlich "Marktanteile" hinzugewinnen. Aussterben
(in dem Sinne, dass Compiler und Bibliotheken nicht mehr gepflegt
werden) wird es nicht, da bin ich mir ganz sicher.
Ich bin gerade dazu gekommen mal ein simples "Hello World" Programm mit
C, C++ und Rust in einer Anwendung zu machen, um zu sehen, wie gut das
geht, und um einen Eindruck zu bekommen, ob es beim Build irgendwelche
problematischen Dinge gibt. Es geht grundsätzlich, aber es gibt 2
Problematische Sachen:
1) Das erste ist eigentlich kein Rust Problem, sondern etwas, das
eigentlich alle C, C++, Rust, etc. Compiler betrifft: Die Compiler
bilden ein Wrapper für den Linker, und der Linker ist dadurch fast nicht
mehr Standalone verwendbar, weil man beim Aufruf die Runtimelibraries
der Sprachen, Systemweit verwendete libraries wie die jeweilige ld.so
kennen muss, und noch viele weitere Optionen. Man kann einen der
Compiler als Wrapper verwenden, bestenfalls der in dessen Sprache die
main geschrieben wurde, und dann die anderen Runtimes dazu linken. gcc,
g++, clang und clang++ haben derart ähnliche Optionen, und bieten derart
gute Möglichkeiten Optionen zum Linker weiterzureichen, dass mich das
dort nicht sehr gestört hat. Wenn jetzt aber noch rustc dazu kommt, mit
komplett anderen Optionen, die viel mehr high-level sind und weniger
low-level zeug erlauben, wird es langsam zum Problem, insbesondere, da
vermutlich nicht vorgesehen ist, das ohne cargo so zu verwenden. Ich
muss irgendwann mal eine standalone linker-wrapper Anwendung erstellen,
der man einfach sagen kann, linker X, runtimes für rust&c&c++, entry
point mit runtime X behandeln, und dann die restlichen linker Optionen
an den Linker weitergeben, und womöglich noch ein allgemeines subset der
Optionen bieten. Das würde das Problem lösen, und währe vermutlich auch
nicht schwer umzusetzen, jedoch müssten es die Compiler/Linkerbauer
sowie die Distributionen dann vermutlich in ihre Packages der jeweiligen
Linker miteinbeziehen, damit es immer reibungslos verwendbar würde, was
eher unwahrscheinlich ist.
2) Das zweite Problem ist auch nicht direkt Rust, sondern cargo. Es ist
nicht so, dass man rust nicht (noch) ohne cargo verwenden könnte, aber
es ist klar, dass die Verwendung von rust mit cargo die einzige
"normale" Nutzung von rust ist, und anderes nicht wirklich vorgesehen
ist. Mein Problem mit Cargo ist wieder zweierlei:
a) Es ist ein build tool (ähnlich wie make, cmake, automake, etc.) aber
auch ein Package Manager. Es ist nicht vorgesehen, cargo nur als
Packagemanager zu verwenden, und ein anderes, bestehendes build
automations tool, die bei vielen anderen Sprachen zum Einsatz kommen, zu
verwenden. Zudem wird die Projektstruktur zu einem gewissen grad
vorgegeben. Das führt zu unnötigen Komplikationen, wenn man ein anderes
build tool verwenden will, oder einzelne Rust quellen in ein bestehendes
nicht-rust Projekt integrieren will.
b) crates.io. Gut, das Problem haben npm und pip auch. Ja, man kann
direkt auf ein Verzeichnis oder auf ein Git repo verweisen, und man
könnte wohl auch irgendwie andere Registries angeben. Aber crates.io ist
der default. Es steht nirgends, wer es betriebt. Vermutlich Mozilla? Es
gibt keine Mirrors, und keine simplen Schnittstellen (z.B. rsync) um es
vollständig zu Mirroren. Die meisten Programme werden Dependencies
darauf haben. All dies macht es zu einem gefährlichen Single point of
failure.
Das alles ist jetzt noch nicht allzu tragisch, aber ich muss das bei
zukünftigen Ernsthafteren Projekten im Auge behalten & Gegenmassnahmen
treffen.
Mein "Hello World" versuch ist im Anhang. Ihr müsst vermutlich im
makefile die Nummer beim "-lstd-df4a2aaeab5f3a68" anpassen (ist ein Teil
der rust standard library). (Einfach mit ls -1
/usr/lib/x86_64-linux-gnu/libstd-*.so nachsehen.)
Cargo is a tool that allows Rust packages to declare their various
2
dependencies and ensure that you’ll always get a repeatable build.
3
4
To accomplish this goal, Cargo does four things:
5
Introduces two metadata files with various bits of package information.
6
7
Fetches and builds your package’s dependencies.
8
9
Invokes rustc or another build tool with the correct parameters to
10
build your package.
11
12
Introduces conventions to make working with Rust packages easier.
Das wichtige: "ensure that you’ll always get a repeatable build"
Das ist etwas, ueber das sich zu wenig leute gedanken machen. Auch ist
das ein Thema, das nicht ganz trivial ist (siehe Google oder Debian als
Beispiele).
DPA schrieb:> Aber crates.io ist der default.
Der default, um ein Paket offiziell zu veroeffentlichen, damit das alle
mitbekommen (zumindestens die, die auf crates.io gucken). Das ist ja
aber nur eine Kopie. Den Code selbst kannst du irgendwo hosten, oder
auch einfach nur auf deiner Platte liegen lassen (lokales crates.io oder
ganz ohne crates.io).
Ein default wie crates.io finde ich aber immernoch besser, als gar
nichts wie es bei C/C++ der Fall ist. Da wird was auf Github/Gitlab/etc.
hochgeladen, und keiner bekommt es mit.
Bei crates.io erscheinen Pakete die neu sind, oder aktualisiert wurden
auf der Hauptseite. Dadurch steigt die wahrscheinlichkeit das ein Paket
gesehen wird. Ebenso verringert das zusammenspielen von crates.io und
Cargo die wahrscheinlichkeit, das fuer neue Projekte veraltete
(fehlerhafte) Libs verwendet werden.
https://doc.rust-lang.org/book/ch14-02-publishing-to-crates-io.html#removing-versions-from-cratesio-with-cargo-yank
1
Although you can’t remove previous versions of a crate, you can prevent
2
any future projects from adding them as a new dependency. This is useful
3
when a crate version is broken for one reason or another.
4
In such situations, Cargo supports yanking a crate version.
5
6
Yanking a version prevents new projects from starting to depend on
7
that version while allowing all existing projects that depend on it
8
to continue to download and depend on that version.
Auch etwas, das es so bei anderen (mir bekannten) Sprachen nicht gibt.
cargo als Paketmanager ist nett für
a) Windows-Nutzer, denn da muss der Anwender sowieso irgendwie mit der
DLL-Hölle leben
b) Entwickler, die sich nur um eine spezifisch gepflegte Zielplattform
kümmern müssen (z.B. die speziell für diese Applikation gedachten
Cloudserver)
Wenn Du aber eine Linux-Distribution pflegen willst, bei der Du jede Lib
möglichst nur ein mal zentral vorhalten & gemeinsam aktualisieren können
willst, dann macht Dir das cargo das Leben schwerer als nötig.
Das zentral Vorhalten und gemeinsam Aktualisieren ist vom Aspekt der
Sicherheitspflege ein ganz entscheidender Punkt. Ich als Admin der eine
solche Distribution nutzt, kann so ganz einfach prüfen was für einen
Stand, Patchlevel,... eine bestimmte Lib hat und es verstecken sich eben
nicht noch 20 andere Kopien der selben Lib in unterschiedlichen
Versionen als .so oder statisch gelinkt auf der Platte.
Gerd E. schrieb:> Wenn Du aber eine Linux-Distribution pflegen willst, bei der Du jede Lib> möglichst nur ein mal zentral vorhalten & gemeinsam aktualisieren können> willst, dann macht Dir das cargo das Leben schwerer als nötig.
Und was hat das jetzt mit cargo zu tun?
Man kann mit rust genauso libs bauen wie mit C und C++ (bzw. mit gcc &
co.). Und wenn die Lib ueber den distrubitionseigenen Paketmanager
verteilt wird (was bei interessanten/wichtigen libs in der regel der
fall ist), interessiert cargo ueberhaupt nicht. cargo ist zum entwickeln
und bauen von rust programmen und zum managen der abhaengigkeiten (um
das programm bauen zu koennen), nicht um die Programme/Libs an den
Anwender zu verteilen (es sei denn, du baust alles aus den sourcen, aber
dann hast du mit rust und cargo dieselben probleme wie mit anderen
Sprachen und Tools auch).
cargo ist nichts anderes als das, was pip für python ist. Installierst
du über pip irgendwelche Programme die in Python geschrieben sind? Nein?
Dann gibt es mit cargo genauso wenig probleme.
Du siehst Probleme, wo keine sind.
Kaj schrieb:> Den Code von crates.io kannst du forken und wie das mit den Mirrors geht> steht auch auf der Github Seite von crates.io
Ah, ja. Ein "Mirror" nennen sie das. Laut der verlinkten Seite ist das
aber so:
> This mirror will function as a read-only duplicate of crates.io's API.> You will be able to download crates using your index and your mirror,> but the crate files will still come from crates.io's S3 storage.
Vieleicht war das nicht klar genug:
> keine Mirrors, und keine simplen Schnittstellen (z.B. rsync) um es> vollständig zu Mirroren
Ich verstehe unter einem Mirror etwas, dass alle Daten spiegelt. Ein apt
mirror spiegelt alle debian Packete der angegebenen Repos. Ein Mirror
der IETF RFCs hat eine Kopie von jedem RFC. Aber von der Beschreibung
des cargo "Mirrors" tönt es so, als wäre das höchstens ein Cacheing
Proxy, der die Pakete nur zwischenspeichert, die man abfragt, oder
eventuell nicht einmal das, und einfach immer nur auf die Daten auf dem
selben S3 zugreift. Vieleicht kann man die Daten des S3 irgendwie
kopieren? Aber damit hab ich keine Erfahrung. Was auch immer das jetzt
tatsächlich ist, ein Mirror ist es nicht. Ohne einen ECHTEN mirror, der
eine Kopie aller Daten hält und es im Notfall ersetzen könnte, bleibt es
ein Single Point of failure.
PS: Das ist nicht das erste mal, das ich "Mirrors" sehe, die gerade die
eigentlichen Daten eben nicht alle spiegeln...
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.
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".
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
> TclDER 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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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
Falls sich mal jemand gefragt hat auf welchem Stand Rust Punkto
"constant evaluation" gerade ist:
https://youtu.be/wkXNm_qo8aY?list=PL85XCvVPmGQhDOUIZBe6u388GydeACbTt
Die Kurzfassung ist, dass sich das wohl ziemlich parallel mit C++ und
dessen constexpr Möglichkeiten entwickelt.
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 :)
> 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
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.
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.
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". :-)
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.
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.
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.
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 :)
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.
Kaj schrieb:> Linus Torvalds kann sich Rust im Linux-Kernel vorstellen> https://www.golem.de/news/programmiersprache-linus-torvalds-kann-sich-rust-im-linux-kernel-vorstellen-2007-149627.html
Klingt spannend. Wenn das klappt, dann wäre das nach Mozilla selbst und
Microsoft eine weitere große und prominente Entwicklergruppe, die der
Verbreitung der Sprache Vorschub leistet.
Am Ende bleiben dann wohl nur noch
- Rust (für systemnahe und zeitkritische Programme),
- Python (für kleine Anwendungsprogramme) und
- Haskell (für große Anwendungsprogramme)
übrig, da alle drei sowohl von der Open-Source-Community als auch von
dem Softwareriesen Microsoft unterstützt werden, so dass neben den
technischen auch immer mehr die unternehmenspolitischen Hemmschwellen
fallen dürften. Aber natürlich werden auch Fortran, Cobol, C++, Java und
C# nicht völlig aussterben ;-)
Yalu X. schrieb:> Am Ende bleiben dann wohl nur noch>> - Rust (für systemnahe und zeitkritische Programme),> - Python (für kleine Anwendungsprogramme) und> - Haskell (für große Anwendungsprogramme)
Also wenn ich so an viel verwendete oder aufstrebende
Programmiersprachen denke, kommt mir Haskell nicht unbedingt als erstes
in den Sinn. :)
Im PYPL-Index ist sie mit 0,29% auf Platz 27 (Tendenz fallend), im
TIOBE-Index sogar nur auf Platz 40. Wenn sie es in den letzten 30 Jahren
nicht darüber hinaus geschafft hat, ist es eher unwahrscheinlich, dass
sich das plötzlich ändert.
Yalu X. schrieb:> Aber natürlich werden auch Fortran, Cobol, C++, Java und> C# nicht völlig aussterben ;-)
Vermutlich nicht :)
Zum jetzigen Zeitpunkt fände ich das eine sehr schlechte Idee. Jetzt
kann man den Kernel endlich mal mit zwei unabhängigen Compilern bauen,
und dann will man sich von rustc/llvm abhängig machen? Rustc, von dem es
keine alternative Implementierung gibt, und wo statt einem anständigen
Standard rustc die Referenz ist? Wenn sie das machen, müssen sie nachher
jeden Mist, den sich die rustc Compiler Bastler ausdenken, mitmachen,
ist denen das klar?
Ich hoffe, die kommen wenigstens nicht auf die Idee cargo zu
verwenden...
Rolf M. schrieb:> Yalu X. schrieb:>> Am Ende bleiben dann wohl nur noch>>>> - Rust (für systemnahe und zeitkritische Programme),>> - Python (für kleine Anwendungsprogramme) und>> - Haskell (für große Anwendungsprogramme)>> Also wenn ich so an viel verwendete oder aufstrebende> Programmiersprachen denke, kommt mir Haskell nicht unbedingt als erstes> in den Sinn. :)
Deswegen steht es ja nur an dritter und letzter Stelle ;-)
> Also wenn ich so an viel verwendete oder aufstrebende> Programmiersprachen denke, kommt mir Haskell nicht unbedingt als erstes> in den Sinn. :)
Mir kommt da immer der frueher einmal pro Jahr wiederkehrende Artikel in
der C't in Erinnerung wo sie uns darauf aufmerksam gemacht haben das
Smalltalk kurz vor dem Durchbruch steht. :-D
Und dann gibt es noch immer die regelmaessig wiederkehrenden Artikel das
man noch dringend Fortran und Cobol Programmierer sucht.
Olaf
Es wäre schade jetzt viel Zeit in C (oder gar C++) zu investieren / die
Sprachen zu lernen und später dann doch umsteigen :-(
Aber vielleicht wird Rust die Kernelentwickler doch noch enttäuschen und
dann rausfliegen ;-)
Wenn aber C langsam aber sicher durch Rust ersetzt wird, dann hat C++
gar keine Zukunft.
zitter_ned_aso schrieb:> Es wäre schade jetzt viel Zeit in C (oder gar C++) zu investieren / die> Sprachen zu lernen und später dann doch umsteigen :-(
Mach dir deswegen keine Sorgen. Ich weiß ja nicht, wieviel Lebens- und
Berufsjahre du noch vor dir hast, aber geh mal davon aus, dass bis zu
deinem Renteneintritt C und C++ nicht obsolet werden werden.
Yalu X. schrieb:>>> - Haskell (für große Anwendungsprogramme)>>>> Also wenn ich so an viel verwendete oder aufstrebende>> Programmiersprachen denke, kommt mir Haskell nicht unbedingt als erstes>> in den Sinn. :)>> Deswegen steht es ja nur an dritter und letzter Stelle ;-)
Haskell ist eine tolle Sprache, keine Frage. Aber Haskell als solches
wird sich (leider?) nicht in der Masse durchsetzen, da nicht
"Massenkompatibel".
Wenn man sich die großen Plattformen/Sprachen der letzten Jahrzehnte
anschaut fällt auf, dass es alles sehr "pragmatische" Sprachen sind, die
erfolgreich waren, und nicht die "schönen" und "perfekten".
Man erinnere sich an Perl, schaue sich den Java-Hype und PHP-Hype an und
auch Ruby. C# ist auch pragmatisch und (war) zusätzlich ein Politikum,
aktuell wächst es auch wegen dotnet. Python hat einen Push durch den
ganzen KI-Kram bekommen weil es vorher im "Wissenschafts-Computing"
schon am wachsen war. Javascript/Typescript wächst auch kontinuierlich
und wird/ist das neue PHP.
C/C++ hat etwas eine Sonderstellung, weil es unglaublich viel
Legacy-Code in dieser Sprache gibt und selbst heute mehr und weniger nur
ein "Luxus-Assembler" ist.
> Es wäre schade jetzt viel Zeit in C (oder gar C++) zu investieren / die> Sprachen zu lernen und später dann doch umsteigen :-(
Selten so gelacht. Seit etwa 20Jahren ist C im Embeddedbereich der
Standard. Egal welche schicke neue Sprache du cool findest, du musst
immer und als allererstes sehr gute C Kenntnisse haben weil du sonst
nicht die Arbeiten der letzten 10Jahre in deiner Firma lesen, verstehen
und wiederverwenden koenntest. Ueber jede neue Sprache kannst du
nachdenken nachdem du C drauf hast und nicht umgekehrt.
Und das ist auch der Grund warum jede neue Sprache es so schwer hat. Und
vergiss nicht, du arbeitest auch mit Kollegen zusammen die keine Lust
auf deine neue Sprache haben, oder eine ganz andere Sprache cool finden,
aber alle koennen auf jedenfall C.
Olaf
zitter_ned_aso schrieb:> Es wäre schade jetzt viel Zeit in C (oder gar C++) zu investieren / die> Sprachen zu lernen und später dann doch umsteigen :-(
Klar. Wie kurzlebig C ist, hat es in den letzten fast 50 Jahren ja
bewiesen. :)
Ok, die "Modesprache" C++ ist erst 35 Jahre alt…
? DPA ? schrieb:> Jetzt kann man den Kernel endlich mal mit zwei unabhängigen Compilern bauen,> und dann will man sich von rustc/llvm abhängig machen?
Mir scheint, dass Linus solche Abhängigkeiten egal sind. Er hat ja auch
hart daran gearbeitet, dass es möglichst schwer ist, den Kernel mit was
anderem als gcc zu übersetzen.
Man kann da sagen was man will. Man merkt C und C++ ihr Alter an und
dass die Neuerungen in C++ einfach nicht die Überzeugungskraft und
Eleganz einer neuen Programmiersprache haben, die basierend auf den
Erfahrungen mit C++ ganz neu erdacht wurde.
Was manche nicht verstehen ist dass historisch bedingte Positionen nicht
ewig bessere Konzepte am Durchbruch hindern können.
In solchen Fällen benötigt der Durchbruch der besseren Konzepte nur
etwas mehr Zeit. Es ist aber nicht abzuwenden.
Es ist sogar denkbar dass auch andere Programmiersprachen entstehen die
die Grundideen von Rust übernehmen und vielleicht wird eine Variante
davon erfolgreicher. So oder so C++ ist wie auch Rust nicht für die
Ewigkeit.
Und eins muss man doch auch einsehen. Wenn man eine Programmiersprache
viele Jahre lernen muss um sie wirklich zu beherrschen dann ist das ein
Zeichen dafür das die Sprache aufgebläht ist.
Warum also 10 Jahre C++ Erfahrung anhäufen wenn man die selbe Kompetenz
auch mit 1-2 Jahren Rust hätte?
So was ist höchstens im Interesse von Leuten die die Durststrecke
bereits durchgemacht haben und nun von ihrer gefragten Position
profitieren. Und es dauert ja bis die nächste Welle erfahrender C++ in
10-15 Jahren ankommen :D
Im Grunde ist das bitter für die Wirtschaft die dadurch nur Zeit
verliert.
SoOderSo schrieb:> Man merkt C und C++ ihr Alter an und> dass die Neuerungen in C++ einfach nicht die Überzeugungskraft und> Eleganz einer neuen Programmiersprache haben, die basierend auf den> Erfahrungen mit C++ ganz neu erdacht wurde.
Letztlich ist’s ja auch die Frage, was langfristig sinnvoller zu lernen
ist: eine Sprache wie C++, die es nunmal schon einige Dekaden gibt, und
die man daher als etabliert bezeichnen könnte, oder Rust, das
möglicherweise den Weg der meisten „modernen“ Sprachen geht, und in
wenigen Jahren von etwa „Oxide“ abgelöst wird, oder ganz an Bedeutung
verloren hat?
SoOderSo schrieb:> benötigt der Durchbruch der besseren Konzepte nur etwas mehr Zeit. Es> ist aber nicht abzuwenden.>> Es ist sogar denkbar dass auch andere Programmiersprachen entstehen die> die Grundideen von Rust übernehmen und vielleicht wird eine Variante> davon erfolgreicher.
Das war doch genau die Frage: schafft es Rust? Oder erst ein Nachfolger
an St. Nimmerlein.
C++ ist doch eine lebendige Sprache, die wohl kaum das Problem hat, zu
wenige Konzepte zu vereinigen.
SoOderSo schrieb:> Warum also 10 Jahre C++ Erfahrung anhäufen wenn man die selbe Kompetenz> auch mit 1-2 Jahren Rust hätte?
Das ist ne ziemlich sinnlose Frage. Ich kann auch fragen: Warum also 10
Jahre Rust Erfahrung anhäufen wenn man die selbe Kompetenz auch mit 1-2
Jahren C++ hätte?
Ich denke schon, dass Rust mittlerweilen das Potenzial hat zu bleiben
(vor allem, wenn man sich mal anschaut wer bereits Rust nutzt):
- Firefox (Servo, Quantum)
- Redox OS
- Stratis (file system für Fedora und RHEL)
- Dropbox (Magic Pocket)
- Microsoft Azure IoT Edge
- OpenDNS
- TOR
- Discord
- Google Fuchsia
...
Schorschi schrieb:> vor allem, wenn man sich mal anschaut wer bereits Rust nutzt
Du kannst dir auch anschauen, wer bereits Java genutzt hat. In einigen
Bereichen ist‘s schon wieder nahezu weg.
Andererseits würde die Liste, wer alles C++ benutzt, locker den Thread
sprengen. :-))
Aber es ist natürlich auch klar, dass ein „Neuankömmling“ es gegenüber
den Etablierten immer erstmal schwer hat.
Letztlich wird es damit stehen und fallen, ob es auch in der Industrie
„ankommt“, weil es in der Lage ist, in einem Projekt gegenüber C oder
C++ wirklich Entwicklungszeit zu sparen.
Jack V. schrieb:> Du kannst dir auch anschauen, wer bereits Java genutzt hat. In einigen> Bereichen ist‘s schon wieder nahezu weg.
klar das gibt es immer wieder und wird auch immer so bleiben
aber man darf Rust definitiv zugestehen das es positiven Einfluss auf
die Branche ausübt (z.B. Herb Sutters Gedanken zum Ownershipping in für
C++, die Ideen das auch in D rein zu bringen - was auch wieder einige
Gedankenknoten für andere Sprachen lösen könnte) und in der System oder
Hardware-nahen Programmierung gab es bisher gar keine alternativen zu
C/C++ - dort wo auch die Java oder .Net/GCC-Sprachen-Entwickler wie
Microsoft/Sun/etc. selbst nur kurzen und teilweise peinliche Vorstöße
gewagt haben
allgemein sehe ich Rust als den dritten im Bunde zwischen C und C++ in
der System/Embedded-Welt die sich gegenseitig sehr gut mit Ideen
versorgen, für normale Applikationen fehlen einfach noch sehr viele
Dinge die C++,C#,Java nach Jahren des Aufbaus einfach so aus dem Ärmel
schütteln
und "nur" die eine oder andere Sprache zu lernen und hier
Aufwand/Kosten/Nutzen abzuwägen ist eh nur Anfänger die keinen Bock
haben :)
man sollte z.B. mindestens ein paar der "Großen" Sprachen wie z.B.
C/C++/C#/Java und 1-2 Script-Sprache gut beherrschen
Rust krankt aber definitiv immer noch an der fehlenden ABI, dem
First-Shot-Kompiler der vollständig aber einfach noch viel zu langsam
ist weil er alles schön sequentiell durchkaut, zu viel IR-Code dem LLVM
hinwirft und,und,und - Kompilierzeit ist gerade noch ein Thema das die
"Sprache" schlecht wirken lässt - vergleichbar mit dem
Hyper-Pfeilschnellem D dmd der dafür aber miesen Code erzeugt
Moin,
Na, was steht denn so im BLFS Book, wenn man rustc-1.42.0 bauen will:
> Unfortunately, rust insists on installing source files for these below
/opt/rustc/lib/src.
Unschoen, aber naja gut.
> On some systems, linking fails to include libffi unless this is used. The reason
why this is needed is not clear.
Das sieht mir doch nach irgendeiner Unsauberkeit im Buildprocess aus.
Tut das not?
> For a long time, the miri crate (an interpreter for the Midlevel Intermediate
Representation) has failed to build on releases. It is optional, but the failure
messages can persuade people that the whole build failed. However, although it is
not built in the main compile, with rustc-1.35.0 it now gets compiled during the
install, but it is broken in this version.
WTF? Wieso fliegt sowas nicht raus oder wird gefixt? Genau so sieht
sh*tty Software aus.
> On some systems, cairo fails to link during the install because it cannot find
libssh2. This seems to fix it, but again the reason why the problem occurs is not
understood.
Siehe oben: Unsauberer Buildprocess.
Da kann die Sprache noch so toll sein, wenn der real existierende
dampfende Haufen aus Rustcompiler, Paket-Kasper und llvm noch solche
Gimmicks hat, bin ich eher nur so mittelfroh.
Gruss
WK
Jörg W. schrieb:> Kaj schrieb:>> Das Rustbook/die StdLib ist die Spec.>> Hmm, aber irgendeine Syntax-Definition sehe ich da nicht (EBNF oder> Syntaxdiagramme).
Die Semantik-Definition ist auch eher "dünn".
kein Mensch sagt Rust ist gut weil die formale Spezifikation von Rust
qualitativ so gut da steht oder das bauen aus den Quellen so super
schnuckelig ist - es ist und bleibt ein Community Projekt das immer noch
organisch wächst
das kann man nicht wirklich mit so einem stringenten Prozess wie bei der
Go , Swift oder .Net Entwicklung vergleichen - es sind viel weniger
Leute beteiligt und auch ist eine schnelle (ISO)Standardisierung nicht
Prio 0 gewesen - erst mal schauen ob die Ideen wie z.B. Ownership so
funktionieren und dann langsam wachsen lassen - die ersten paar
Versionen der nicht Go/Swift usw. Kompiler waren auch nicht von Anfang
an ein Gedicht
Klar ist das Gesamtkunstwerk aus Sprache+Kompiler relevant - aber dann
kann man sich aber auch über die Leichtigkeit von Crosskompilieren mit
Clang im Vergleich zu GCC oder Visual Studio aufregen :)
Momentan definiert effektiv der Compiler das Verhalten.
https://github.com/rust-lang/reference :
> This document is the primary reference for the Rust programming language.>> This document is not normative. It may include details that are specific to> rustc itself, and should not be taken as a specification for the Rust> language. We intend to produce such a document someday, but this is what we >
have for now.
cppbert schrieb:> auch ist eine schnelle (ISO)Standardisierung nicht Prio 0 gewesen
Naja, das war bei C ja auch ein Weg von fast 20 Jahren.
Dennoch, schau dir die BCPL-Referenz von 1967 an (Vorläufer von C,
findest du auf Dennis Ritchie's Webseiten) und vergleich das mal mit
dem, was Rust als "Definition" bietet.
Klar, wenn du dir dann den K&R ansiehst, enthält der auch einen deutlich
größeren Textteil mit anwenderorientierter Prosa, aber eben dennoch die
formale Beschreibung der Sprache ebenso. Bei Rust sehe ich nur die
anwenderorientierte Prosa, keine formale Beschreibung.
> Naja, das war bei C ja auch ein Weg von fast 20 Jahren.
C hatte im Embedded Bereich den Vorteil das es praktisch nur Assembler
verdraengen musste und das war eher einfach. .-)
> Das war doch genau die Frage: schafft es Rust? Oder erst ein Nachfolger> an St. Nimmerlein.
Frag das in 10Jahren nochmal!
> C++ ist doch eine lebendige Sprache, die wohl kaum das Problem hat, zu> wenige Konzepte zu vereinigen.
Ja, aber ich hab den Eindruck als wenn es von grossen in der branche
schon den Wunsch gibt einfachere Sprachen durchzusetzen damit man auch
schlichtere (und billigere) Gemueter als Programmierer verwenden kann.
C++ ist sozusagen die taegliche Diplompruefung. :-D
Olaf
Olaf schrieb:> Ja, aber ich hab den Eindruck als wenn es von grossen in der branche> schon den Wunsch gibt einfachere Sprachen durchzusetzen damit man auch> schlichtere (und billigere) Gemueter als Programmierer verwenden kann.
Wenn das so einfach wäre, würden heute alle Programme in Logo von der
Putzfrau erstellt werden.
Die Komplexität in der SW Entwicklung entsteht nicht durch die
Programmiersprache.
Jörg W. schrieb:> Dennoch, schau dir die BCPL-Referenz von 1967 an (Vorläufer von C,> findest du auf Dennis Ritchie's Webseiten) und vergleich das mal mit> dem, was Rust als "Definition" bietet.
Es gibt immer Entwickler die mehr Wert darauf legen von Anfang an gut
definiert zu sein - aber das ist einfach kein Qualitätsmerkmal der
Sprache, es muss irgendwann perfekt da stehen - aber jetzt gerade glaube
ich ist das noch nicht so relevant
Problem ist eben: Es muss besser als C/C++, schneller und sauberer
spezifiziert sein - sonst lohnt es sich schon mal nicht drauf zu schauen
- mit dem Argument kann man alles bremsen :)
cppbert schrieb:> aber das ist einfach kein Qualitätsmerkmal der> Sprache, es muss irgendwann perfekt da stehen - aber jetzt gerade glaube> ich ist das noch nicht so relevant
Läuft das dann unter dem Schlagwort "liquid Syntax"? Mal ernsthaft, das
wirkt alles wie Hipster Kram aber nicht wie ein ernsthafter Versuch
etablierte Industriestandards zu ersetzen.
Cyblord -. schrieb:> Die Komplexität in der SW Entwicklung entsteht nicht durch die> Programmiersprache.
nicht "NUR" durch die Programmiersprache wäre passender - aber man kann
Komplexitätsreduktion damit begünstigen
aber es gibt ja auch genug Leute die sagen: durch den Kompiler
forciertes Owning ist das selbe wie Smart-Pointers in C++ - weil der
Faktor Mensch (Stress, Desinteresse, man findet keine besseren
Entwickler usw. - nicht relevant sein kann(darf?))
und bei den großen Projekten mit >10Mio Zeilen Code und hunderten von
Entwicklern ist einfach jede Verbesserung spürbar
cppbert schrieb:> Jörg W. schrieb:>> Dennoch, schau dir die BCPL-Referenz von 1967 an (Vorläufer von C,>> findest du auf Dennis Ritchie's Webseiten) und vergleich das mal mit>> dem, was Rust als "Definition" bietet.>> Es gibt immer Entwickler die mehr Wert darauf legen von Anfang an gut> definiert zu sein - aber das ist einfach kein Qualitätsmerkmal der> Sprache, es muss irgendwann perfekt da stehen - aber jetzt gerade glaube> ich ist das noch nicht so relevant
Es wird sicher niemals perfekt sein, muss es auch nicht. Eine Sprache
muss zwingend Work in Progress sein, um erfolgreich zu sein. Die Sprache
nicht zu definieren ist das gleiche wie Software nicht zu Dokumentieren,
"Technical Debt".
Der aktuelle Zustand der "Definition" ist ein Problem. Es kann ohne
klare Definition keinen alternativen Compiler geben, ohne dass es
schnell zwei unterschiedliche Sprachen gibt.
Der Einstieg in die Sprache und vor allem der Einstige in die
Entwicklung der Sprache wird nach und nach immer schwerer. Wenn man den
Compiler lesen und verstehen muss, um konstruktiv an der Sprache zu
arbeiten, läuft etwas schief.
Cyblord -. schrieb:> Läuft das dann unter dem Schlagwort "liquid Syntax"? Mal ernsthaft, das> wirkt alles wie Hipster Kram aber nicht wie ein ernsthafter Versuch> etablierte Industriestandards zu ersetzen.
die Revolution wurde von den großen der Branche x mal versucht - und sie
sind alle gescheitert - daher jetzt einfach mal in kleinen Happen - wenn
es nichts wird ist es auch nicht schlimm - aber bitte nicht immer alles
auf die Goldwaage legen - dafür ist die Thematik einfach zu umfangreich
(vom Style, der Ausdruckskraft bis runter auf die
Code-Optimierungsebene)
Es ist nicht leicht, es gab viele Fehlversuche, es wird weiterhin Fehler
geben, keiner Zwingt einem was auf, lernen tut nicht weh, Gründe findet
man immer, wir haben nichts zu verlieren
mh schrieb:> Der aktuelle Zustand der "Definition" ist ein Problem. Es kann ohne> klare Definition keinen alternativen Compiler geben, ohne dass es> schnell zwei unterschiedliche Sprachen gibt.
100% ACK - aber wenn es dazu kommen sollte das alternative Kompiler
erbaut werden (ich schaue auf euch Microsoft und google) werden sich die
Leute zusammensetzen - die Zeiten von Inkompatible und Vendor Lock-in
sind definitiv lange vorbei und werden von niemandem mehr akzeptiert -
die Vermarktung wird zu schwer
und klar rennen da draußen tausend Fanboys rum die schreien das Rust das
geilsten ist was es gibt - die dürfen wir Profis natürlich mit aller
Kraft ignorieren
cppbert schrieb:> Es ist nicht leicht, es gab viele Fehlversuche, es wird weiterhin Fehler> geben, keiner Zwingt einem was auf, lernen tut nicht weh, Gründe findet> man immer, wir haben nichts zu verlieren
Das sehe ich anders. Lernen kostet Zeit und Zeit ist endlich. Wenn ich
etwas "falsches" lerne, tut mir das weh.
cppbert schrieb:> 100% ACK - aber wenn es dazu kommen sollte das alternative Kompiler> erbaut werden (ich schaue auf euch Microsoft und google) werden sich die> Leute zusammensetzen - die Zeiten von Inkompatible und Vendor Lock-in> sind definitiv lange vorbei und werden von niemandem mehr akzeptiert -> die Vermarktung wird zu schwer
Auch das sehe ich deutlich anders. Wenn Microsoft oder Google eine
Möglichkeit zum Vendor Lock-in sehen, werden sie es versuchen.
Neben böser Absicht, gibt es aber auch noch die Möglichkeit, dass sie
eine ganz andere Vorstellung der Sprache haben, und diese mit einem
alternativen Compiler umsetzen.
Die Compilezeiten sind mir ziemlich egal, in Anbetracht des Mehr an
Sicherheit das die Sprache bietet. Denn das ist alles Zeit, die ein
Entwickler nicht in Fehlersuche/Bugfixes investieren muss.
Wem das compilieren zu lange dauert:
1
cargo check
2
3
check - Analyze the current package and report errors, but don't build object files
cppbert schrieb:> nicht "NUR" durch die Programmiersprache wäre passender - aber man kann> Komplexitätsreduktion damit begünstigen
Die Sprache ist eher ein Pinsel für den Maler. Ja, manche sind besser
als andere, je nach Aufgabe, vor allem bei Massenware. Aber letztendlich
ist jede in der Praxis geschliffene Hochsprache (ab C) nur ein Werkzeug,
gerade bei komplexen Projekten, wo die Sprache weit hinter dem inneren
Aufbau der SW zurücktritt.
Olaf schrieb:> C hatte im Embedded Bereich den Vorteil das es praktisch nur Assembler> verdraengen musste und das war eher einfach. .-)
Das würde ich nicht sagen. Es ist halt nur C übrig geblieben, aber
Forth, Ada, Pascal, Basic und vermutlich hunderte weitere waren da
ebenso im Rennen.
> Das sehe ich anders. Lernen kostet Zeit und Zeit ist endlich. Wenn ich> etwas "falsches" lerne, tut mir das weh.
klingt dramatisch: wie oft hast du denn schon falsches gelernt?
und warum hattest du die Sorge bei C/C++ nicht
oder hast du dir damals dann nur Pascal angeschaut
> Auch das sehe ich deutlich anders. Wenn Microsoft oder Google eine> Möglichkeit zum Vendor Lock-in sehen, werden sie es versuchen.>> Neben böser Absicht, gibt es aber auch noch die Möglichkeit, dass sie> eine ganz andere Vorstellung der Sprache haben, und diese mit einem> alternativen Compiler umsetzen.
das ist einfach quatsch - nicht ein Standard hält eine Sprache stabil
und frei von monitären/macht Einflüssen sondern einen starke
Entwicklergemeinde die sich dagegen wehrt - und google/Microsoft habe
trotz ihrer Größe z.B. nicht mehr die Kraft sowas wie ein LLVM Projekte
alleine zu stemmen - die Zeiten sind vorbei
Microsoft und google sind auch sehr stark im C++ Konsortium drin - d.h.
die treffen da auch schon viele Entscheidungen mit - was ist der
Unterschied?
Kaj schrieb:> Die Compilezeiten sind mir ziemlich egal
...solange du nicht was größeres machst wo es nervig wird - es gibt
keine
Programmiersprache bei der das egal ist - es ist nur der Projektaufbau
und die Projektgröße entscheidend
solche Aussagen haben dazu geführt das wir bei C++ seit Jahrzenten
Modules ignoriert haben und wohl noch bis 2022 brauchen bis dieses Thema
endlich anständig gelöst ist
A. S. schrieb:> Es ist halt nur C übrig geblieben, aber Forth, Ada, Pascal, Basic und> vermutlich hunderte weitere waren da ebenso im Rennen.
Für Embedded / Lowlevel OS?
FORTH schon, Ada kam erst eine Dekade später und gab sich wohl nie Mühe,
außerhalb seines angedachten Anwenderkreises allgemein Fuß zu fassen.
Pascal und Basic rannten auf dieser Ebene nicht mit. Selbst wenn man
Standard-Pascal mal beiseite lässt, ich habe gern und viel mit
Turbo-Pascal unter CP/M gemacht, aber wenn's schnell gehen sollte,
musste man schon auf den Inline-Assembler zurückgreifen. Im Gegensatz zu
dem, was wir jetzt bspw. von GCC kennen, war das aber nur ein
Objektcode-Einbetter, gar kein Assembler selbst: man musste den
Objektcode extern mit einem Assembler erzeugen und konnte den
Assemblercode höchstens noch als Kommentar reinschreiben.
A. S. schrieb:> Aber letztendlich> ist jede in der Praxis geschliffene Hochsprache (ab C) nur ein Werkzeug,> gerade bei komplexen Projekten, wo die Sprache weit hinter dem inneren> Aufbau der SW zurücktritt.
d.h. es lohnt sich einfach nicht mehr die Ausruckskraft von Sprachen zu
hinterfragen, zu erweitern, begrenzen?
cppbert schrieb:>> Die Compilezeiten sind mir ziemlich egal
Ich habe noch nie einen Entwickler sagen hören - "Es wäre schön wenn es
länger kompiliern würde"
> FORTH schon, Ada kam erst eine Dekade später und gab sich wohl nie Mühe,> außerhalb seines angedachten Anwenderkreises allgemein Fuß zu fassen.
Das sehe ich aehnlich. Von Ada hab ich jedenfalls damals nichts gehoert.
Forth gab es hier und da, aber das hat nie mehr als 100Leute pro Land
interessiert und die waren jeweils damit beschaeftigt einen eigenen
Interpreter fuer ihre Lieblingshardaware zu schreiben. .-)
> Pascal und Basic rannten auf dieser Ebene nicht mit. Selbst wenn man
Pascal haette es schaffen koenne. Es gab auch Versuche das compilat von
TurboPascal embedded zu nutzen. (c't, aber auch von anderen)
Aber letztlich fand der Uebergang damals schon von Assembler nach C
statt.
Oh..und was mich an Rust (und go) auch gewaltig stoert ist das
Buildsystem! Das ist mir zu dogmatisch. Ich hab sogar letztens noch eine
neue Sprache angetestet wo die Compilerbauer darauf bestehen das man
kein Tab im Quelltext hat. So schnell hab ich noch nie rm getippt.
Olaf
cppbert schrieb:> d.h. es lohnt sich einfach nicht mehr die Ausruckskraft von Sprachen zu> hinterfragen, zu erweitern, begrenzen?
Doch. Das ist wichtig und gerade die Ausdruckskraft ist es, was m.E. die
erfolgreichen von den anderen unterscheidet. Und für C++ gilt auch
begrenzen sicherlich ;-)
Olaf schrieb:> Oh..und was mich an Rust (und go) auch gewaltig stoert ist das> Buildsystem! Das ist mir zu dogmatisch. Ich hab sogar letztens noch eine> neue Sprache angetestet wo die Compilerbauer darauf bestehen das man> kein Tab im Quelltext hat. So schnell hab ich noch nie rm getippt.
Na offenbar bist du nicht weniger dogmatisch. Wieso bestehst du auf Tabs
im Quelltext? :D
Olaf schrieb:> Oh..und was mich an Rust (und go) auch gewaltig stoert ist das> Buildsystem!
Wenn du ein besseres kennst, steht es dir frei, dieses benutzen.
> Ich hab sogar letztens noch eine neue Sprache angetestet wo die> Compilerbauer darauf bestehen das man kein Tab im Quelltext hat.
In Sprachen wie Nim, bei denen Blöcke per Einrückung definiert werden,
ist es aber auch mehr als sinnvoll, den Gebrauch von schwer voneinander
unterscheidbaren Whitespace-Zeichen zu verbieten.
> So schnell hab ich noch nie rm getippt.
Ja, das mache ich auch immer mit Tab-verseuchtem Quellcode ;-)
Jörg W. schrieb:> Letztlich wird es damit stehen und fallen, ob es auch in der Industrie> „ankommt“, weil es in der Lage ist, in einem Projekt gegenüber C oder> C++ wirklich Entwicklungszeit zu sparen.
Dazu gehört auch, dass man Experten hat/findet, die die Sprache
beherrschen. Denn man wird eher nicht ein neues Entwicklungsprojekt in
einer Sprache beginnen, die keiner der Mitarbeiter halbwegs beherrscht.
Olaf schrieb:> Oh..und was mich an Rust (und go) auch gewaltig stoert ist das> Buildsystem! Das ist mir zu dogmatisch. Ich hab sogar letztens noch eine> neue Sprache angetestet wo die Compilerbauer darauf bestehen das man> kein Tab im Quelltext hat. So schnell hab ich noch nie rm getippt.
Dabei hat man sich extra für dich die Mühe gemacht
Olaf schrieb:> Ich hab sogar letztens noch eine neue Sprache angetestet wo die Compilerbauer> darauf bestehen das man kein Tab im Quelltext hat.
Na endlich mal eine sinnvolle Einschränkung in einer Sprache.
Olaf schrieb:> Ueber jede neue Sprache kannst du> nachdenken nachdem du C drauf hast und nicht umgekehrt.
Bei Rust und erst recht bei Haskell ist es exakt umgekehrt: C-Denkweise
ist extrem hinderlich. Anders rum wärs wesentlich einfacher und weniger
schmerzhaft.
Ist das nur mein Eindruck oder relativieren viele C++ Entwickler
wirklich die C++ Neuerungen die Rust ähnliche Features bringen?
Einerseits wird mit der Weiterentwicklung von C++ argumentiert dass Rust
nicht notwendig sei. Anderseits sehe ich aber eine massive
Relativierung und mangelnde Akzeptanz der C++ Neuerungen.
So heißt es manchmal dass hohe Speichersicherheit mit den neuen Mitteln
nur für spezielle Fälle gut sei und man es jetzt nicht in der
alltäglichen Programmierungen benötige.
Man muss also erst für Militär oder Banken entwickeln damit das von
Bedeutung wird? Der Rest soll halt weiter leiden mit den Folgen
mangelnder Speichersicherheit und weiter Zeit und Geld dafür verlieren.
Was man bei C++ also gerne relativiert und nur für spezielle
Anforderungen abschiebt, um es nicht lernen und benutzen zu müssen, ist
bei Rust der Standard.
SoOderSo schrieb:> Ist das nur mein Eindruck oder relativieren viele C++ Entwickler> wirklich die C++ Neuerungen die Rust ähnliche Features bringen?
Das ist nicht mein Eindruck. In meinem Umfeld werden alle Neuerungen
getestet und bewertet. Wenn das Kosten-Nutzen-Verhältnises für einen
Anwendumgsfall stimmt, wird es genutzt.
Auf welche konkrete Features beziehst du dich denn?
Bevor nicht die Platzhirsche Rust adoptieren und kommerzialisieren,
werden die meisten Firmen sich mit dem Feind herumzuschlagen mit dem sie
schon lange Erfahrungen haben. Abgesehen davon hat sich bis jetzt Rust
nur im IT Markt(Google, Mozilla...) behauptet und nicht so viel im
embedded Bereich.
Was der Bauer nicht kennt frisst er nicht. Da wird sich Rust noch lange
schwer tun. Auch ist die Terminologie bei Rust etwas zu esoterisch um
bei Vielen anzukommen. Irgendwie passt z.B. "Crate" u.v.a. nicht in den
Jargon etablierter Entwicklung.
C/C++ mag seine Fußangeln zu Recht haben. Wer aber plant, bedacht und
diszipliniert seine Anwendungen durchsetzt wird auch damit zuverlässige
Anwendungen erstellen können. C/C++ kommt irgendwie logischer als Rust
an. Der ganze Syntax um Rust herum ist abenteuerlich. Unter der Haube
mag es ja vielleicht gut sein. Bis man aber dazu wirklich Vertrauen
gewinnen kann, wird noch viel Wasser die Flüsse herunter fließen müssen.
C/C++ hat im embedded Bereich einfach einen viel Hardware-näheren Ton
und fühlt sich wie dafür gemacht an. Bei Rust ist da ein viel breiterer
Abgrund.
Die wahrscheinlichste Prognostik: Trotz aller Hoffnung und Erwartungen
wird es genauso wie so viele andere Sprachen zuvor lange ein Nischen
Dasein führen und seinen Fan Club haben. Die Industrie wird aber noch
lange Zeit mit C/C++ weiter entwickeln weil dabei zu bleiben letzten
Endes doch Geld spart. Es ist eben so: Der Mensch verhält sich eben wie
Masse bei zunehmender Lichtgeschwindigkeit - Das Beharrungsverhalten
steigt bei vielen Leuten um so mehr an je mehr man auf den Gashebel
steigt.
Thread beobachten
Seitenaufteilung abschalten