Rust - ist das hier um zu bleiben?

[DPA (Gast)]

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?

[Vancouver (Gast)]

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.

[Theor (Gast)]

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.

[Dergute W. (derguteweka)]

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

[Dr. Sommer (Gast)]

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...

[DPA (Gast)]

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.

[Silc P. (silch12)]

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".

[DPA (Gast)]

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.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Silc P. (silch12)]

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

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Silvano C. schrieb:
> Das wäre bei Rust sicher nicht das Problem, da Rust auf das LLVM-Backend
> setzt

Auch schon im Jahr 2004?

[Dergute W. (derguteweka)]

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

[Dr. Sommer (Gast)]

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.

[Vincent H. (vinci)]

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.

[Dergute W. (derguteweka)]

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

[Vincent H. (vinci)]

Dergute W. schrieb:
> Das klingt interessant. Haste mal ein Beispiel, wie man so auf die
> Schnelle mit einem llvm aufm x86_64 PC so was ganz simples wie ein
> HelloWorld fuer eine gaengige Architektur wie z.b. ARM crosskompilieren
> kann?

Man muss dem Compiler lediglich das Target als flag übermitteln. Also in 
etwa so:

--target=arm-none-eabi -march=armv7e-m

Default ist natürlich x86.

> OK, und was waeren das fuer "(legacy) Abhängigkeiten"?

isl und gmp fallen mir da ein...
und da gabs noch ein paar so lustige Acronmy wo man sich erstmal denkt 
"hä?"
Und wenn man schon auf Python rumhakt. Braucht GCC nicht Perl?

[Theor (Gast)]

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".

[Dergute W. (derguteweka)]

Moin,

Vincent H. schrieb:
> Man muss dem Compiler lediglich das Target als flag übermitteln. Also in
> etwa so:
>
Hmmmm....

echo "main() {}" > hello.c
clang  hello.c #OK, da faellt ein a.out raus.
clang -target arm-none-eabi hello.c 
error: unable to create target: 'No available targets are compatible with this triple.'

Hm, ok - also was kann denn mein clang fuer Targets?

Uuupsi:
https://stackoverflow.com/questions/15036909/clang-how-to-list-supported-target-architectures

Scheint garnicht so simpel zu sein, das rauszukriegen...(Bloss gut dass 
ich ihn selbergebaut hab', da weiss ich's noch).
Es ist also keinesfalls so, dass da automatisch immer alle crosscompiler 
mitdrinnen sind. Das muss beim Bau angegeben sein.

Und genau solche Sachen erzeugen bei mir die Skepsis. Jeder blubberts 
nach, weils irgendwo steht, aber wenn man's dann wirklich ausprobieren 
will, wirds schnell zaeh'.

Vincent H. schrieb:
> isl und gmp fallen mir da ein...
OK, ohne isl und diverse andere Gimmicks lassen sich sehr wohl gccs 
bauen.

mpfr, gmp, mpc - ja klar, irgendwie muss der compiler konstante 
Ausdruecke ja auch berechnen koennen. Ich wuesst' nicht, wie llvm ums 
berechnen beim compilieren rumkommt. Vielleicht macht er's so wie alte 
gccs und hat den ganzen Schmonz irgendwo festeingebaut.

Ich sag' mal: An dem Tag, wo ein LFS/BLFS artiges Projekt rauskommt, bei 
dem nicht mit gcc usw. angefangen wird, sondern mit rustc und mit dem 
dann llvm und danach evtl noch gcc gebaut wird - da bin ich auch 
ueberzeugt, dass rust eine tolle Dauerwurst ist. vorher eher noch nicht 
:-)


Gruss
WK

[Vincent H. (vinci)]

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.

[Dr. Sommer (Gast)]

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...

[Kaj (Gast)]

Von rust werden momentan diese Architekturen unterstuetzt:

$ rustup target list
aarch64-apple-ios
aarch64-fuchsia
aarch64-linux-android
aarch64-pc-windows-msvc
aarch64-unknown-cloudabi
aarch64-unknown-linux-gnu
aarch64-unknown-linux-musl
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
arm-unknown-linux-musleabi
arm-unknown-linux-musleabihf
armebv7r-none-eabi
armebv7r-none-eabihf
armv5te-unknown-linux-gnueabi
armv5te-unknown-linux-musleabi
armv7-apple-ios
armv7-linux-androideabi
armv7-unknown-linux-gnueabihf
armv7-unknown-linux-musleabihf
armv7r-none-eabi
armv7r-none-eabihf
armv7s-apple-ios
asmjs-unknown-emscripten
i386-apple-ios
i586-pc-windows-msvc
i586-unknown-linux-gnu
i586-unknown-linux-musl
i686-apple-darwin
i686-linux-android
i686-pc-windows-gnu
i686-pc-windows-msvc
i686-unknown-freebsd
i686-unknown-linux-gnu
i686-unknown-linux-musl
mips-unknown-linux-gnu
mips-unknown-linux-musl
mips64-unknown-linux-gnuabi64
mips64el-unknown-linux-gnuabi64
mipsel-unknown-linux-gnu
mipsel-unknown-linux-musl
powerpc-unknown-linux-gnu
powerpc64-unknown-linux-gnu
powerpc64le-unknown-linux-gnu
riscv32imac-unknown-none-elf
riscv32imc-unknown-none-elf
s390x-unknown-linux-gnu
sparc64-unknown-linux-gnu
sparcv9-sun-solaris
thumbv6m-none-eabi
thumbv7em-none-eabi
thumbv7em-none-eabihf
thumbv7m-none-eabi
wasm32-unknown-emscripten
wasm32-unknown-unknown
x86_64-apple-darwin
x86_64-apple-ios
x86_64-fuchsia
x86_64-linux-android
x86_64-pc-windows-gnu (installed)
x86_64-pc-windows-msvc
x86_64-rumprun-netbsd
x86_64-sun-solaris
x86_64-unknown-cloudabi
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu (default)
x86_64-unknown-linux-gnux32
x86_64-unknown-linux-musl
x86_64-unknown-netbsd
x86_64-unknown-redox

AVR soll auch unterstuetzt werden, sobald das AVR Backend fehlerfreier 
ist. Solange gibt es das avr-rust projekt.

Der Buildprozess ist mit cargo super angenehm. Man hat eine gewisse 
Sicherheit was Rebuild-Sicherheit angeht, da alle veroeffentlichen 
Versionen eines Crates immer wieder runterladbar sind. Man kan alte 
Versionen extra markieren, womit diese nicht mehr fuer neue projekte 
verwendet werden koennen, aber fuer alte projekte erhalten bleiben.
Arbeitet man mit den Crates von crates.io dann ist auch die verwaltung 
der abhaengigkeiten sehr einfach. Das Oekosystem ist meiner Meinung nach 
das groesste Plus bei Rust.

Durch die Gestaltung von Rust ist der Code sehr aussagekraeftig.

fn main() {
    let mut _x: u8 = 255;
    _x += 1;
}

Kommt es bei der Ausfuehrung zum ueberlauf stuerzt das Programm ab.

thread 'main' panicked at 'attempt to add with overflow', src/main.rs:3:5

Schreibt man das ganze so:

fn main() {
    let mut _x: u8 = 255;
    _x = _x.wrapping_add(1);
}

ist alles gut und man bekommt seinen ueberlauf. Die Sprache schuetzt zum 
einem vor dem Fehler von ungewollten ueberlaeufen, und zum anderen 
bietet sie die moeglichkeit eines gewollten ueberlaufs, was man dann 
aber auch so im code ausdruecken muss. Das traegt doch ungemein zum 
verstaendis von fremdcode bei. Neben wrapping_add() gibt es noch andere 
funktionen, die einem dann auch noch sagen ob es einen ueberlauf gab. 
Wie viele threads gibt es hier, wo sich drueber gestritten wird wie man 
in c oder c++ am besten und sichersten einen ueberlauf feststellt...

Die generierte Doku gefaellt mir deutlich besser, als das was ich bisher 
bei anderen Sprachen gesehen habe.

Unit-Tests (und auch benchmark-tests) sind gleich mit dabei, und man 
kann auch private Methoden testen, ohne sich einen abbrechen zu muessen. 
Mit rustfmt kann man den Code entsprechend den Rustguidlines formatieren 
lassen. Unter Visual Studio Code laesst sich Rust genauso einfach wie C 
oder C++ debuggen.

Ja, einige konzepte sind sehr ungewoht wenn man von c/c++ kommt (hallo 
borrow-checker, mein freund...), aber das ist okay.

Es gibt praktisch keinen Grund, Rust nicht mal wenigstens eine 
ernsthafte chance zu geben. Und mit ernsthaft meine ich, dass man sich 
schon mal 1 Monat etwas intensiver mit Rust beschaeftigt haben sollte.

Meiner Meinung nach ist Rust die beste alternative zu C und C++, wenn es 
um low-level geht, besonders weil sie auch viele embedded targets 
unterstuetzt. Ebenso denke ich, das Rust in zukunft noch eine grosse 
Rolle spielen wird, wenn es um sichere Software geht.

Ja, Rust ist gekommen um zu bleiben.

[Nano (Gast)]

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.

[Silc P. (silch12)]

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

[Dr. Sommer (Gast)]

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...

[Nano (Gast)]

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.

[Kaj (Gast)]

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).

[Yalu X. (yalu) (Moderator)]

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.

[DPA (Gast)]

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.)

[Kaj (Gast)]

Den Code von crates.io kannst du forken und wie das mit den Mirrors geht 
steht auch auf der Github Seite von crates.io

https://github.com/rust-lang/crates.io

Deploying & using a mirror
https://github.com/rust-lang/crates.io/blob/master/docs/MIRROR.md#deploying--using-a-mirror

Und wie man ein crates.io lokal laufen laesst steht unter contributing:
https://github.com/rust-lang/crates.io/blob/master/docs/CONTRIBUTING.md

Once you have a local instance of crates.io running at 
http://localhost:4200 by following the instructions in the 
"Working on the Backend" section, you can go to another Rust project 
and tell cargo to use your local crates.io instead of production.

Warum es Cargo gibt, und warum das Paketmanager und Buildtool in einem 
ist (und warum das nutzen ohne Cargo nicht wirklich vorgesehen ist), ist 
auch schnell geklaert:

https://doc.rust-lang.org/cargo/guide/why-cargo-exists.html#why-cargo-exists

Cargo is a tool that allows Rust packages to declare their various 
dependencies and ensure that you’ll always get a repeatable build.

To accomplish this goal, Cargo does four things:
    Introduces two metadata files with various bits of package information.

    Fetches and builds your package’s dependencies.

    Invokes rustc or another build tool with the correct parameters to
    build your package.

    Introduces conventions to make working with Rust packages easier.

Das wichtige: "ensure that you’ll always get a repeatable build"

Das ist etwas, ueber das sich zu wenig leute gedanken machen. Auch ist 
das ein Thema, das nicht ganz trivial ist (siehe Google oder Debian als 
Beispiele).

DPA schrieb:
> Aber crates.io ist der default.
Der default, um ein Paket offiziell zu veroeffentlichen, damit das alle 
mitbekommen (zumindestens die, die auf crates.io gucken). Das ist ja 
aber nur eine Kopie. Den Code selbst kannst du irgendwo hosten, oder 
auch einfach nur auf deiner Platte liegen lassen (lokales crates.io oder 
ganz ohne crates.io).

Ein default wie crates.io finde ich aber immernoch besser, als gar 
nichts wie es bei C/C++ der Fall ist. Da wird was auf Github/Gitlab/etc. 
hochgeladen, und keiner bekommt es mit.
Bei crates.io erscheinen Pakete die neu sind, oder aktualisiert wurden 
auf der Hauptseite. Dadurch steigt die wahrscheinlichkeit das ein Paket 
gesehen wird. Ebenso verringert das zusammenspielen von crates.io und 
Cargo die wahrscheinlichkeit, das fuer neue Projekte veraltete 
(fehlerhafte) Libs verwendet werden.

https://doc.rust-lang.org/book/ch14-02-publishing-to-crates-io.html#removing-versions-from-cratesio-with-cargo-yank

Although you can’t remove previous versions of a crate, you can prevent 
any future projects from adding them as a new dependency. This is useful 
when a crate version is broken for one reason or another. 
In such situations, Cargo supports yanking a crate version.

Yanking a version prevents new projects from starting to depend on 
that version while allowing all existing projects that depend on it 
to continue to download and depend on that version.

Auch etwas, das es so bei anderen (mir bekannten) Sprachen nicht gibt.

[Gerd E. (robberknight)]

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.

[Kaj (Gast)]

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.

[Daniel A. (daniel-a)]

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...

[глупний форентроль (Gast)]

Eine Entscheidung zu einer Programmiersprache ist eigentlich immer "UND" 
nicht "ODER"

[S. R. (svenska)]

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...

[Atemis H. (at0)]

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.

[Vn N. (wefwef_s)]

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.

[Dr. Sommer (Gast)]

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.

[nickm (Gast)]

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

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[mh (Gast)]

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 (Gast)]

Im Vergleich zu Smalltalk hat sich Rust aber schon eine grössere 
Community aufgebaut (wird deshalb wohl auch seit Jahren zur beliebtesten 
Sprache auf Stack Overflow gewählt). Auch im Embedded-Bereich wurde 
schon einiges gemacht. Falls es jemand interessiert:

https://www.rust-lang.org/what/embedded
https://github.com/rust-embedded/awesome-embedded-rust
https://docs.rust-embedded.org/discovery/
https://docs.rust-embedded.org/book/

[mh (Gast)]

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.

[Test (Gast)]

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...

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Bernd K. (prof7bit)]

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).

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

nickm schrieb:
> Was nicht alles gekommen ist um zu bleiben:
> Pascal

Sehr verbreitet im SPS-Bereich als SCL bzw. ST (EN 61131-3 bzw. ISO 
61131).

> Modula
> Eiffel

Ziemlich tot.

> Occam

Wurde nur für Transputer geschaffen.

> Fortran

Als HPF (High Performance FORTRAN) immer noch im Bereich des Number 
Crunching sehr verbreitet.

> Smalltalk

Nischenanwendungen

> Cobol

Im Bankenbereich noch sehr verbreitet. Ein Bekannter 
("Mainframe-Urgestein") hat sich vor wenigen Jahren sehr erfolgreich mit 
Cobol-Entwicklung selbstständig gemacht und kann sich vor Aufträgen kaum 
retten. Und er bekommt nicht nur Migrationsprojekte von Cobol nach xyz 
angeboten, sondern echte Weiterentwicklungen von langfristig 
eingesetzten Programmen.

> Basic

z.B. Microsoft VBA in jedem Office-Paket

> Tcl

DER Standard für Skripting und Constraints in sehr vielen 
FPGA-Entwicklungsumgebungen (Xilinx ISE, Vivado; Intel/Altera Quartus, 
usw.).

> C
> C++

Definitiv sehr weit verbreitet.

> Objective C

App-Entwicklung für Apple iOS.

> XC
> C99

C-Dialekte.

> AWK

Auf fast jedem Linux-System in Shell-Skripten versteckt, aber als 
eigenständige Sprache fast irrelevant. Niemals als Programmiersprache 
für universelle Anwendungen konzipiert.

> Java

Sehr verbreitet.

[Dr. Sommer (Gast)]

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.

[Heimlehrgangprogrammierer (Gast)]

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.

[Carl D. (jcw2)]

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.

[Bernd K. (prof7bit)]

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.

[TriHexagon (Gast)]

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.

[mh (Gast)]

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.

[S. R. (svenska)]

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...

[Vn N. (wefwef_s)]

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.

[Dr. Sommer (Gast)]

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!

[Vn N. (wefwef_s)]

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.

[Nick M. (Gast)]

> 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

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Nick M. schrieb:
> Und wenn erste Stellenausschreibungen in meinem Bereich mit der
> Anforderung Rust auftauchen, hab ich immer noch genug Zeit.

Solche Stellenausschreibungen findet man mittlerweile zuhauf, und zwar 
sowohl für ausgewachsene Entwickler als auch Werkstudenten:

https://4scotty.com/candidate/position/senior-embedded-developer-fmx-ZkSystems-GmbH-in-Berlin-8455

https://portal.hgi.rub.de/uploads/files/1114_1_1199_tNYUrDjXxFCc2DqLmoql_36291-Praktikum-Embedded-Software-Development-mit-Rust.pdf

[Nick M. (Gast)]

Beim ersten Link hab ich nur "Blockchain" gelesen und dann war das 
Fenster schon wieder zu. :-))

Nick

[zitter_ned_aso (Gast)]

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.)

[Bernd K. (prof7bit)]

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.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[zitter_ned_aso (Gast)]

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.

[Bernd K. (prof7bit)]

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.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Nano (Gast)]

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.

[Gegeg J. (Gast)]

also wenn Du Pascal Code aus dem Netz fischt aus den 80ern..und unter 
Freepascal kompilierst..geht das auch?
Also das Beispiel ist nichtssagend

[Vincent H. (vinci)]

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...

[S. R. (svenska)]

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.

[Daniel A. (daniel-a)]

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.

[Gegeg J. (Gast)]

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.

[Nano (Gast)]

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.

[mh (Gast)]

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?

[Nick M. (Gast)]

> Der Standard nennt sich Borland Pascal,

Nein, das war das Pascal von N. Wirth.
Nein, UCSD-Pascal
Nein, SunValley Pascal.
Nein, Microsoft-Pascal!


Nick

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Gegeg J. (Gast)]

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"

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Irgend W. (Firma: egal) (irgendwer)]

Gegeg J. schrieb:
> S. R. schrieb:
>> Pascal hatte nie einen gebrauchbaren Sprachstandard.
>
> der immer gleiche Quatsch..er wird nicht wahrer wenn man ihn
> gebetsmühlenartig wiederholt.
> Der Standard nennt sich Borland Pascal, an dem Orientiert sich jeder
> ernstzunehmende Pascal clon.

Nö, der Standard nennt sich ISO 7185:1990
https://rti.etf.bg.ac.rs/rti/ir1p1/materijali/iso7185.pdf

und ISO/IEC 10206:1991
http://web.eah-jena.de/~kleine/history/languages/iso-iec-10206-1990-ExtendedPascal.pdf

Das es davon kaum eine vollständige Umsetzung gibt ist eine ganz anderes 
Thema...

[sonstnochwer (Gast)]

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!

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Bernd K. (prof7bit)]

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.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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".

[Bernd K. (prof7bit)]

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.

[Bibo (Gast)]

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.

[Bibo (Gast)]

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...

[Jörg W. (dl8dtl) (Moderator)]

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 (Gast)]

Ich wollte damit ein Beispiel für nicht wiederholbare Builds geben.
Wenn dich das stört, tut's mir leid.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Vn N. (wefwef_s)]

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.

[Gegeg J. (Gast)]

@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

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Carl D. (jcw2)]

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?

[Olaf (Gast)]

> 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

[S. R. (svenska)]

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.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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

[Olaf (Gast)]

> 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

[Nano (Gast)]

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

[Nano (Gast)]

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

[Kaj (Gast)]

Closing the gap: cross-language LTO between Rust and C/C++
http://blog.llvm.org/2019/09/closing-gap-cross-language-lto-between.html

Cross-language LTO is a new feature in the Rust compiler 
that enables LLVM's link time optimization to be performed 
across a mixed C/C++/Rust codebase.

[Wer rustet der rostet (Gast)]

https://www.golem.de/news/security-microsoft-baut-com-bibliothek-in-rust-1910-144358.html

[mh (Gast)]

Wer rustet der rostet schrieb:
> 
https://www.golem.de/news/security-microsoft-baut-com-bibliothek-in-rust-1910-144358.html

... während eines Praktikums beim MSRC entstanden ...

Da hat Microsoft ja richtig Resourcen investiert.

[Vincent H. (vinci)]

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.

[Dergute W. (derguteweka)]

Moin,

Ich seh' sowas hier:

https://www.linuxquestions.org/questions/linux-from-scratch-13/9-0-gotcha%27s-4175662685/#post6049598

und fuehle mich in meiner hier schon in Post 4 geaeusserten Meinung 
leider bestaetigt.
Und auch wenns die Informatiker hier nicht gerne hoeren wollen: So eine 
Software, die sich nicht vernueftig aus sourcen bauen laesst, taugt nix.
War/Ist auch bei KDE > 3.x so.

Gruss
WK

[cppbert3 (Gast)]

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 :)

[Vincent H. (vinci)]

> Microsoft: We're creating a new Rust-based programming language for secure
> coding

https://www.zdnet.com/article/microsoft-were-creating-a-new-rust-based-programming-language-for-secure-coding/

Oh hell no.

[Olaf (Gast)]

> 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

[vn nn (Gast)]

Dir ist klar, dass C, C++ und Rust kompatibel sind?

Du scheinst halt eher nicht so zur produktiven Hälfte der Menschheit zu 
gehören...

[DPA (Gast)]

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.

[vn nn (Gast)]

Vincent H. schrieb:
>> Microsoft: We're creating a new Rust-based programming language for secure
>> coding
>
> 
https://www.zdnet.com/article/microsoft-were-creating-a-new-rust-based-programming-language-for-secure-coding/
>
> Oh hell no

Der Klassiker: 
https://de.wikipedia.org/wiki/Embrace,_Extend_and_Extinguish#Die_Strategie

[Atemis H. (at0)]

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

[A. S. (Gast)]

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.

[Ex Progger (Gast)]

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.

[DPA (Gast)]

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.

[Atemis H. (at0)]

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.

[S. R. (svenska)]

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.

[Nick M. (Gast)]

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.

[S. R. (svenska)]

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. (dl8dtl) (Moderator)]

S. R. schrieb:
> Aber von ObjC hatte ich noch nie gehört,

Die Sprache hatte ihren ersten Frühling beim NeXT.

[S. R. (svenska)]

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

[Rolf M. (rmagnus)]

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.

[Nick M. (Gast)]

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.

[vn nn (Gast)]

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...

[Rolf M. (rmagnus)]

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.

[Dergute W. (derguteweka)]

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

[cppbert (Gast)]

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 :)

[DPA (Gast)]

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.

[Nick M. (Gast)]

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.

[Atemis H. (at0)]

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.

[cppbert (Gast)]

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

[zitter_ned_aso (Gast)]

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 ;-)

[Atemis H. (at0)]

Ü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.

[cppbert (Gast)]

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 (Gast)]

Das ist ja noch schlimmer.

Die einfachste Programmiersparche der Welt C++ und Rust lernen. (und 
später C++ "wegschmeißen")

[cppbert (Gast)]

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

[Atemis H. (at0)]

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 (Gast)]

Tja, was C++ bisher nicht geschafft hat... ;)

Linus Torvalds kann sich Rust im Linux-Kernel vorstellen
https://www.golem.de/news/programmiersprache-linus-torvalds-kann-sich-rust-im-linux-kernel-vorstellen-2007-149627.html

[Dergute W. (derguteweka)]

Moin,
<heise-mode>Juhuu, das ist das Ende von Linux</heise-mode>

SCNR,
WK

[Yalu X. (yalu) (Moderator)]

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 ;-)

[Rolf M. (rmagnus)]

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 :)

[? DPA ? (Gast)]

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...

[Yalu X. (yalu) (Moderator)]

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 ;-)

[Olaf (Gast)]

> 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

[zitter_ned_aso (Gast)]

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.

[Yalu X. (yalu) (Moderator)]

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.

[Schorschi (Gast)]

https://github.com/rust-lang/rust/issues/44052

Zudem ist Rust nun auch für AVR verfügbar (gut, war es schon länger aber 
neu ist dass es mit upstream Rust gemerged wurde)

[Bastler (Gast)]

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.

[Olaf (Gast)]

> 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

[Rolf M. (rmagnus)]

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.

[SoOderSo (Gast)]

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.

[SoOderSo (Gast)]

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.

[Jack V. (jackv)]

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?

[A. S. (Gast)]

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.

[mh (Gast)]

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?

[Schorschi (Gast)]

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
...

[Jack V. (jackv)]

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.

[Cyblord -. (cyblord)]

Also ich zocke Rust immer noch gerne. IMO das beste Survival Game am 
Markt.

[Jörg W. (dl8dtl) (Moderator)]

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.

[cppbert (Gast)]

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

[Dergute W. (derguteweka)]

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

[S. R. (svenska)]

Gibt es eigentlich eine formale Spezifikation von Rust?
Oder definiert der Compiler das Verhalten (wie bei Perl)?

[Kaj (Gast)]

S. R. schrieb:
> Gibt es eigentlich eine formale Spezifikation von Rust?
> Oder definiert der Compiler das Verhalten (wie bei Perl)?
Das Rustbook/die StdLib ist die Spec.
https://doc.rust-lang.org/stable/book/

[Jörg W. (dl8dtl) (Moderator)]

Kaj schrieb:
> Das Rustbook/die StdLib ist die Spec.

Hmm, aber irgendeine Syntax-Definition sehe ich da nicht (EBNF oder 
Syntaxdiagramme).

[mh (Gast)]

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".

[cppbert (Gast)]

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 :)

[? DPA ? (Gast)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Olaf (Gast)]

> 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

[Cyblord -. (cyblord)]

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.

[cppbert (Gast)]

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 :)

[Cyblord -. (cyblord)]

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.

[cppbert (Gast)]

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

[mh (Gast)]

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.

[cppbert (Gast)]

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

[cppbert (Gast)]

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

[cppbert (Gast)]

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

[mh (Gast)]

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.

[Kaj (Gast)]

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:

cargo check

check - Analyze the current package and report errors, but don't build object files

Warum die Zeiten so lang sind, kann man hier lesen:

The Rust Compilation Model Calamity
https://pingcap.com/blog/rust-compilation-model-calamity

[A. S. (Gast)]

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.

[cppbert (Gast)]

> 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?

[cppbert (Gast)]

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

[Jörg W. (dl8dtl) (Moderator)]

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.

[cppbert (Gast)]

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 (Gast)]

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"

[Olaf (Gast)]

> 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

[A. S. (Gast)]

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 ;-)

[SoOderSo (Gast)]

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

[Yalu X. (yalu) (Moderator)]

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 ;-)

[Rolf M. (rmagnus)]

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.

[Jemand (Gast)]

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

#![allow(bad_style)]

zu implementieren.

lol

[Rolf M. (rmagnus)]

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.

[Daniel -. (root)]

nö dependent types und linear types ist das nächste große ding ;)
btw ich vermisse ocaml in diesem thread

[Bernd K. (prof7bit)]

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.

[SoOderSo (Gast)]

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.

[mh (Gast)]

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?

[W.Gates (Gast)]

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.

[Kaj (Gast)]

Kompression: Dropbox macht Brotli zu Broccoli
https://www.golem.de/news/kompression-dropbox-macht-brotli-zu-broccoli-2008-150075.html

Der in Rust geschriebene Code der zugrundeliegenden Bibliothek
von Broccoli steht auf Github zur Verfügung.

https://github.com/dropbox/rust-brotli#rust-brotli