Forum: PC-Programmierung Rust - ist das hier um zu bleiben?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von DPA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Vancouver (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dergute W. (derguteweka)


Bewertung
-3 lesenswert
nicht lesenswert
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

von Dr. Sommer (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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...

von DPA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Silvano C. (silch12)


Bewertung
0 lesenswert
nicht lesenswert
DPA schrieb:
> Dergute W. schrieb:
>> Mein Eindruck ist,
>> dass das der rust-compiler ein fuerchterlich anfaelliger Haufen Code
>> ist, der sich immer nur exakt mit ganz bestimmten Versionen von clang,
>> rust etc. ueberhaupt bauen laesst. Sowie da irgendwas nicht passt,
>> klemmts ganz arg.
>
> Oh, das wusste ich nicht. Ich hatte gehofft, nach 8 Jahren währe man da
> etwas weiter. Dann beobachte ich das vielleicht doch lieber noch zuerst
> ein par Jährchen.

Da bin ich anderer Meinung.
Durch den Paketmanager Cargo weiss der Compiler genau, welche 
Bibliotheken sicher laufen, welche Updates der Bibliotheken zu der 
aktuellen kompatibel usw. sind.
Der Rust Code an sich ist rückwärtskompatibel, d.h. Code in einerer 
früheren Version (ab 1.0, davor war beta) wird garantiert von neuen 
Compiler auch "verstanden".

: Bearbeitet durch User
von DPA (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Silvano C. (silch12)


Bewertung
0 lesenswert
nicht lesenswert
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

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


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

Auch schon im Jahr 2004?

von Dergute W. (derguteweka)


Bewertung
1 lesenswert
nicht lesenswert
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

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Vincent H. (vinci)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Vincent H. (vinci)


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

Man muss dem Compiler lediglich das Target als flag übermitteln. Also in 
etwa so:
--target=arm-none-eabi -march=armv7e-m

Default ist natürlich x86.

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

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

: Bearbeitet durch User
von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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".

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Vincent H. (vinci)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Eigentlich reicht ja eine

Eine für Soft float, eine für vfp4-sp-d16, eine für vfp4-dp-d16, 
vfp3-sp-d16, ...

Dergute W. schrieb:
> moderner Webkram mit Rust

Rust ist nicht für Web. Das ist für performante Low-Level Codes. Also 
hauptsächlich als C und C++ Ersatz.

Und wenn man unbedingt ein LLVM für ein exotisches Target/Host bauen 
will, kann man das ja unter einem Ubuntu tun, wo man alles per apt-get 
installiert hat. Wenn man's richtig macht läuft das dann überall.

Das Build Script für den GCC-ARM-Embedded ist auch ein paar kLoC lang. 
Ist wohl doch nicht so einfach. Den Rattenschwanz an Dependencies lädt 
es manuell runter. Es funktioniert auch nur unter Ubuntu, und nur unter 
32bit. Executables für Win64 kann es nicht erstellen. Da ist auch nicht 
alles in Butter...

von Kaj (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Silvano C. (silch12)


Bewertung
1 lesenswert
nicht lesenswert
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

von Dr. Sommer (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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...

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Kaj (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Yalu X. (yalu) (Moderator)


Bewertung
1 lesenswert
nicht lesenswert
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.

von DPA (Gast)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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.)

von Kaj (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Kaj (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Daniel A. (daniel-a)


Bewertung
0 lesenswert
nicht lesenswert
Kaj schrieb:
> Den Code von crates.io kannst du forken und wie das mit den Mirrors geht
> steht auch auf der Github Seite von crates.io

Ah, ja. Ein "Mirror" nennen sie das. Laut der verlinkten Seite ist das 
aber so:

> This mirror will function as a read-only duplicate of crates.io's API.
> You will be able to download crates using your index and your mirror,
> but the crate files will still come from crates.io's S3 storage.


Vieleicht war das nicht klar genug:
> keine Mirrors, und keine simplen Schnittstellen (z.B. rsync) um es
> vollständig zu Mirroren

Ich verstehe unter einem Mirror etwas, dass alle Daten spiegelt. Ein apt 
mirror spiegelt alle debian Packete der angegebenen Repos. Ein Mirror 
der IETF RFCs hat eine Kopie von jedem RFC. Aber von der Beschreibung 
des cargo "Mirrors" tönt es so, als wäre das höchstens ein Cacheing 
Proxy, der die Pakete nur zwischenspeichert, die man abfragt, oder 
eventuell nicht einmal das, und einfach immer nur auf die Daten auf dem 
selben S3 zugreift. Vieleicht kann man die Daten des S3 irgendwie 
kopieren? Aber damit hab ich keine Erfahrung. Was auch immer das jetzt 
tatsächlich ist, ein Mirror ist es nicht. Ohne einen ECHTEN mirror, der 
eine Kopie aller Daten hält und es im Notfall ersetzen könnte, bleibt es 
ein Single Point of failure.

PS: Das ist nicht das erste mal, das ich "Mirrors" sehe, die gerade die 
eigentlichen Daten eben nicht alle spiegeln...

: Bearbeitet durch User
von глупний форентроль (Gast)


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

von S. R. (svenska)


Bewertung
3 lesenswert
nicht lesenswert
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...

von Atemis H. (at0)


Bewertung
0 lesenswert
nicht lesenswert
Das war mal aber vielleicht. Die Ansprüche dass Code sich auch in 15 der 
30 Jahren compilieren lassen muss und dass es auch ohne Internet und 
Dienstleister gehen muss.

Das was viele heuter als starke Abhängigkeit empfinden wird immer mehr 
zum Standard. Und vielleicht verfällt der Anspruch dass Dinge ewig 
halten müssen.
Technologie wird schnelllebiger. Die Verfallszeit ist aufgrund einer 
beschleunigten technologischen Entwicklung kürzer geworden.

Früher meckerten sehr viele noch dass man auf Plattformen wie Steam 
unbedingt Internetverbindung benötigt.
Ich glaube in Zukunft wird wirklich niemand mehr eine solche 
Abhängigkeit kritisieren. Es wird einfach absolut selbstverständlich 
dass man permanent einen Internetzugang hat.
Auch wenn Deutschland da nicht glänzen mag. Für viele Länder ist eine 
flächendeckende breitband Verbindung Alltag geworden.

Ich frage mich auch ob die Entwickler die die Hardware von Smartphones 
entwickeln auch das Bedürfnis haben dass ihr Code 20 Jahre hält.
Wenn quasi jährlich ein neues Modell entwickelt werden muss mit neu 
entwickelter Hardware.

Die Apps verlieren jedenfalls nach ein paar Updates des Betriebssystems 
ihre Kompatibilität.
Immerhin ist das auf klassischen Computern nicht so schlimm.

: Bearbeitet durch User
von Vn N. (wefwef_s)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Dr. Sommer (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von nickm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von mh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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".

von gimbo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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/

von mh (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Test (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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...

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
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).

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


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

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

> Modula
> Eiffel

Ziemlich tot.

> Occam

Wurde nur für Transputer geschaffen.

> Fortran

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

> Smalltalk

Nischenanwendungen

> Cobol

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

> Basic

z.B. Microsoft VBA in jedem Office-Paket

> Tcl

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

> C
> C++

Definitiv sehr weit verbreitet.

> Objective C

App-Entwicklung für Apple iOS.

> XC
> C99

C-Dialekte.

> AWK

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

> Java

Sehr verbreitet.

: Bearbeitet durch User
von Dr. Sommer (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Heimlehrgangprogrammierer (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Carl D. (jcw2)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
3 lesenswert
nicht lesenswert
Heimlehrgangprogrammierer schrieb:
> Meine Prognise ist, daß Rust noch für lange Zeit eine sprichwörtliche
> Aschenputtel Existenz fristen wird und lange zeit brauchen wird um
> Real-World Projekte für die Industrie gut genug handhaben zu können.

Ich habe die Vermutung daß ein eingefleischter C (oder C++) 
Programmierer der im Laufe der Jahre alle schmutzigen Tricks gesehen hat 
und der genau weiß wie er was machen muß damit es nicht knallt und der 
das Problem von race-Conditions mit C-Mitteln löst und mit (meist 
zutreffenden) Annahmen über das Verhalten seines eigenen Code einfach 
umschifft als wäre es gar nicht da es unglaublich schwer haben wird wenn 
er plötzlich mit den extrem restriktiven Compilezeit-Prüfungen und dem 
Eigentümer und Verleihkonzept in Rust konfrontiert wird, so sehr daß er 
schnell das Handtuch wefen und sagen wird "das wird mir jetzt aber echt 
zu blöd, so kann doch kein Mensch vernünftig arbeiten".

Wahrscheinlich gehts einfacher wenn man das als erste Sprache lernt, 
andernfalls muss man praktisch alles (wirklich alles!) vergessen was man 
jemals gelernt hat, alle liebgewonnenen Konzepte und Designpatterns 
vergessen und nochmal komplett bei Null anfangen. Das ist extrem schwer.

: Bearbeitet durch User
von TriHexagon (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von mh (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Vn N. (wefwef_s)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Vn N. (wefwef_s)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nick M. (muellernick)


Bewertung
0 lesenswert
nicht lesenswert
> 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

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

von Nick M. (muellernick)


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

Nick

von zitter_ned_aso (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.)

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
TriHexagon schrieb:
> Das Gleiche gilt doch schon für die "eingefleischten C Programmierer"
> wenn sie mal C++ sehen

Das ist was völlig anderes, bei C++ können sie im Wesentlichen weiterhin 
alles genau so machen wie bisher in C und der Unterschied ist nur daß 
sie dann noch 42 zusätzliche Sachen obendrein auch noch machen können 
wenn sie wollen und die neuen Konzepte ganz sachte Stück für Stück 
lernen und schrittweise umstellen, der Frustfaktor ist relativ gering.

Bei Rust kannst Du praktisch absolut nichts mehr auf die althergebrachte 
Weise machen, musst alles vergessen und komplett neu und anders lernen. 
Ähnlich schmerzhaft wie wenn man versucht vom ner imperativen Sprache 
auf Haskell umzusteigen. Vielleicht nicht ganz so extrem aber 
vergleichbar.

: Bearbeitet durch User
von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von zitter_ned_aso (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Dass es z.B. unter japanischem MS Windows auch
> BAT/CMD-Skripte mit japanischem Zeichensatz gibt oder zumindest mal gab,
> konnte ich vor etlichen Jahren selbst erleben.

Es gab mal ne Zeit da hat Microsoft in seinen Officprodukten die 
Funktionsnamen in die jeweilige Landessprache übersetzt und WIMRE war 
das Programmieren von Makros aus diesen oder einem damit eng 
zusammenhängenden Grund die absolute Hölle. Ist aber schon 20 Jahre her, 
kann sein daß die Erinnerung über die vielen Jahre hinweg dramatischer 
geworden ist.

> Damals wollte ich ein
> bestimmtes Programm auf dem Schlepptop eines japanischen Gastes
> installieren, was mir aber aus besagtem Grund nicht gelang.

Dann hat der Entwickler Mist gebaut. Hab ich selber auch schon 
geschafft, zum Beispiel in nem Python-Programm Text auf der stdout 
ausgeben wollen (nicht mit print sondern direkt mit write) und 
stillschweigend davon ausgehen daß die Konsole zufällig die selbe 
Kodierung hat wie bei einem zuhause. RTFM hätte geholfen denn das 
Verhalten ist dokumentiert und Empfehlungen existieren, ausreichend 
Erfahrung hätte ebenfalls geholfen, aber wenn man jung und ungeduldig 
ist...

--

GigaDevice liefert Quelltexte für seine Demo-Boards und in der Demo für 
das Display sind literale strings enthalten. Die ganze C-Datei ist in 
einem chinesischen Zeichensatz kodiert (nicht in UTF-8 wie das jeder 
andere normale Mensch machen würde) und wenn man das dann mal durch den 
Compiler jagen will meckert der weil die Stringliterale die falsche 
Länge haben. Dann muss man erstmal ausprobieren(!) welcher von den 
dutzend verschiedenen chinesischen Windows-Zeichensätzen das wohl sein 
könnte.

Das wird natürlich auch nirgendwo mit einem Wort erwähnt oder überhaupt 
nicht erst als Problem zur Kenntnis genommen denn in China(!) hat ja 
anscheinend noch kein Mensch je was von der Existenz unterschiedlicher 
Zeichensätze gehört. Noch nicht mal die Programmierer!

Es wird so viel geschlampt und gepfuscht überall das geht echt auf keine 
Kuhhaut mehr.

: Bearbeitet durch User
von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gegeg J. (Gast)


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

von Vincent H. (vinci)


Bewertung
-1 lesenswert
nicht lesenswert
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...

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Daniel A. (daniel-a)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Gegeg J. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von mh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Nick M. (muellernick)


Bewertung
0 lesenswert
nicht lesenswert
> Der Standard nennt sich Borland Pascal,

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


Nick

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gegeg J. schrieb:
> Der Standard nennt sich Borland Pascal, an dem Orientiert sich jeder
> ernstzunehmende Pascal clon.

Das tun nur Jungspunde. VAX Pascal war fast so verbreitet wie VAX 
FORTRAN. Und Borland Pascal hieß zum Zeitpunkt seiner größten 
Verbreitung noch Turbo Pascal.

: Bearbeitet durch User
von Gegeg J. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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"

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Irgend W. (Firma: egal) (irgendwer)


Bewertung
0 lesenswert
nicht lesenswert
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...

von sonstnochwer (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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!

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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".

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Die Aussage "die allermeisten Debugger" ist keinesfalls identisch mit
> "alle Debugger".

Was soll man mit den "allermeisten" Debuggern? Für jede Sprache nimmt 
man natürlich immer den geeigneten Debugger, für C oder C++ genauso, da 
geh ich auch nicht mit nem Java-Debugger dran und auch nicht einem 
Debugger für Go oder einem für C# oder einem für Python.

: Bearbeitet durch User
von Bibo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bibo (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
6 lesenswert
nicht lesenswert
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.

von Bibo (Gast)


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

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Vn N. (wefwef_s)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gegeg J. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
@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

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gegeg J. schrieb:
> leider sind alle deine Kommentare falsch, aber ich will die Diskussion
> jetzt hier nicht ausufern lassen..

Entweder bist Du ein Lügner oder Dir mangelt es am Textverständnis. 
Ansonsten wäre Dir sowohl anhand des deutschen als auch englischen 
Wikipedia-Artikels die Historie von Turbo Pascal aufgefallen. Die darin 
aufgeführten Inhalte sind natürlich mit den entsprechenden Quellen 
versehen.

> Turbo Pascal hieß IMMER Turbo Pascal
> Die von dir genannten Pascal Sprachen, haben nicht viel mit TUrbo von
> Borland zu tun..

Würdest Du die genannten Quellen lesen und verstehen, dann wüsstest Du, 
dass der Compiler eben ursprünglich nicht von Borland stammt, sondern 
von Borland (einschließlich des Entwicklers) eingekauft wurde:

"The Turbo Pascal compiler was based on the Blue Label Pascal compiler 
originally produced for the NasSys cassette-based operating system of 
the Nascom microcomputer in 1981 by Anders Hejlsberg. Borland licensed 
Hejlsberg's "PolyPascal" compiler core (Poly Data was the name of 
Hejlsberg's company in Denmark), and added the user interface and 
editor. Anders Hejlsberg joined the company as an employee and was the 
architect for all versions of the Turbo Pascal compiler and the first 
three versions of Borland Delphi.[2]

The compiler was first released as Compas Pascal for CP/M, and then 
released on November 20, 1983 as Turbo Pascal for CP/M"

> und ich sagte auch, das die Pascal Versionen VOR
> urbo/Borland kaum zu gebrauchen waren..lies noch mal was ich gechrieben
> hatte

Mit welchen Pascal-Compilern vor Turbo Pascal hast Du denn ganz 
konkret gearbeitet? Und wann sind diese Compiler auf den Markt gekommen?

Und wie von mir schon erwähnt, basierte der große Erfolg des Apple II 
und seiner vielen Clones unter anderem auf UCSD Pascal, was damals DER 
Standard-Pascal-Compiler für viele Plattformen war, insbesondere auch 
die damals sehr verbreiteten DEC PDP-11, später auch DEC VAX/VMS. Bei 
UCSD Pascal dürfte es sich um eines der allerersten halbwegs komplexen 
Programmpakete handeln, die erfolgreich sowohl auf Mainframes, 
Minicomputern als auch Kleincomputern eingesetzt wurden. Und das Konzept 
der sog. p-Machine war viele Jahre später die Vorlage für die Java VM.

https://en.wikipedia.org/wiki/UCSD_Pascal

Ich beide Pascal-Compiler verwendet, d.h. UCSD Pascal auf Apple und VAX 
Pascal auf VAX-11/780 und microVAX-II.

Nichtsdestotrotz stellt Turbo Pascal natürlich einen sehr wichtigen 
Meilenstein in der Pascal-Geschichte dar.

> Auch der Rest von dir ist falsch widerlegt.

Nein, Du wiederholst nur Deine Behauptungen. Bitte lege doch endlich 
einmal Quellen vor, die Deine Behauptungen stützen.

> Und der Standard heißt Borland/Turbo Pascal! bzw Delphi!
>
> Der ISO Standard wurde wie bereits richtig erkannt nie richtig
> umgesetzt..

Doch, Oregon Pascal-2 für etliche Plattformen war strikt 
ISO-7185-konform:

https://www.computerwoche.de/a/pascal-2-compiler-fuer-vax-und-micro-vax,1168616

>daher orientiert sich alles brauchbare  an dem Borland/Delphi
> Standard

Falsch. Die (Pascal-)Welt besteht nicht nur aus PCs mit Microsoft 
Windows, sondern umfasste früher sehr viel mehr Plattformen, und das zu 
einer Zeit, als es Windows noch nicht gab und MS-DOS noch in den 
Kinderschuhen steckte. Ich bestreite auch keineswegs, dass sich Pascal 
heutzutage nur noch in wenigen Nischen erfolgreich behaupten kann.

Und bezüglich der Einhaltung von Normen und Standards sind andere 
erfolgreiche Compiler auch nicht besser. Microsoft Visual Studio C++ 
(und C) weichen an vielen Stellen auch ganz bewusst auch vom 
ANSI/ISO-Standard ab, um die Portierung von für Windows geschriebenen 
Programmen auf andere Betriebssysteme zu erschweren.

: Bearbeitet durch User
von Carl D. (jcw2)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Olaf (Gast)


Bewertung
1 lesenswert
nicht lesenswert
> 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

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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

von Olaf (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
> 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

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Nano (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von Kaj (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Wer rustet der rostet (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von mh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Vincent H. (vinci)


Bewertung
1 lesenswert
nicht lesenswert
Falls sich mal jemand gefragt hat auf welchem Stand Rust Punkto 
"constant evaluation" gerade ist:
Youtube-Video "RustConf 2019 - Taking Constant Evaluation to the Limit by Oliver Schneider"

Die Kurzfassung ist, dass sich das wohl ziemlich parallel mit C++ und 
dessen constexpr Möglichkeiten entwickelt.

von Dergute W. (derguteweka)


Bewertung
-3 lesenswert
nicht lesenswert
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

von cppbert3 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von Vincent H. (vinci)


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

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

Oh hell no.

: Bearbeitet durch User
von Olaf (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
> 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

von vn nn (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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...

von DPA (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von vn nn (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Atemis H. (at0)


Bewertung
-1 lesenswert
nicht lesenswert
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

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ex Progger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von DPA (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Atemis H. (at0)


Bewertung
-1 lesenswert
nicht lesenswert
DPA schrieb:
> Das ist einfach nur naiv. Es gibt keinen Grund anzunehmen, dass
> crates.io für immer brauchbar bleibt oder bleiben kann. Alles, was einen
> Anfang hat, hat auch ein Ende. Ob Rust oder crates.io erfolgreich ist,
> ist dafür komplett Irrelevant.

Also wirklich. Ich glaube manche verwechseln hier Programmiersprachen 
mit Höhlenmalereien und Steintafeln. Programmiersprachen werden nicht 
für die Ewigkeit gemacht und der Wert einer Programmiersprache definiert 
sich nicht allein dadurch wie lange alter Code compiliert werden kann.
Wer solche Bedürfnisse hat sollte am besten sowieso alle nötigen Dateien 
herunterladen und konservieren und nicht naiv erwarten dass die Welt die 
nächsten Jahrzehnte still stehen wird.

Mit einer neuen Programmiersprache hat man jedenfalls die Freiheit 
solche Bedürfnisse gezielt anzugehen ohne auf moderne Konzepte zu 
verzichten. Ich bin mir sicher dass das möglich ist.

Außerdem glaube ich dass die Trägheit der Industrie wohl einem Wandel 
unterworfen ist. Digitalisierung und Vernetzung nehmen auch in 
industriellen Produktionen immer mehr an Bedeutung zu. Damit wird auch 
die Software sicherlich schnelllebiger.

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nick M. (muellernick)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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". :-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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

Die Sprache hatte ihren ersten Frühling beim NeXT.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nick M. (muellernick)


Bewertung
1 lesenswert
nicht lesenswert
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.

von vn nn (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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...

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
Nick M. schrieb:
> Rolf M. schrieb:
>> Ich hatte davon schon gehört, aber es hieß damals, das sei ein
>> gescheiterter erster Versuch gewesen, C objektorientiert zu machen.
>
> Nein. :-)

Äh, doch. Das ist wirklich das, was ich damals gehört habe. Muss ja 
nicht unbedingt stimmen :)

Atemis H. schrieb:
> Also wirklich. Ich glaube manche verwechseln hier Programmiersprachen
> mit Höhlenmalereien und Steintafeln. Programmiersprachen werden nicht
> für die Ewigkeit gemacht und der Wert einer Programmiersprache definiert
> sich nicht allein dadurch wie lange alter Code compiliert werden kann.

Das nicht, aber es ist dennoch sehr wichtig. Denn nicht jeder hat das 
Bedürfnis, ständig das Rad neu zu erfinden. Manche möchten auch 
bestehenden Code nutzen können. Je komplexer Software wird, desto 
wichtiger ist da eine gewisse Beständigkeit. Sonst ist man irgendwann 
mehr damit beschäftigt, alles immer wieder neu zu machen, als damit, die 
Software an sich weiterzubringen.

: Bearbeitet durch User
von Dergute W. (derguteweka)


Bewertung
2 lesenswert
nicht lesenswert
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

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von DPA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nick M. (muellernick)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Atemis H. (at0)


Bewertung
1 lesenswert
nicht lesenswert
Die Komfort Funktionen mit dem Paketmanager sind nicht zwingend. Man ist 
nicht gezwungen cargo zu benutzen und crates.io ist keine nicht 
auswechselbare Quelle. Man kann die Quellen selbst ändern und eigene 
lokale Quellen anlegen, die nichts anderes sind als Ordner voller Source 
Dateien.
Man kann mit dem --git Flag in cargo auch direkt aus einem Git Repo 
installieren.
https://doc.rust-lang.org/cargo/reference/source-replacement.html

Wenn ich bei C++ externe Bibiliotheken einbinde bin ich doch auch 
abhängig davon und wenn ich die Dateien nicht selbe sichere, muss ich 
hoffen, dass sie auch in 30 Jahren noch im Internet gehostet und 
angeboten werden.

: Bearbeitet durch User
von cppbert (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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

von zitter_ned_aso (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

von Atemis H. (at0)


Bewertung
1 lesenswert
nicht lesenswert
Übrigens Mozilla muss auch nicht den gesamten C++ Code für Firefox auf 
Anhieb oder überhaupt vollständig durch Rust ersetzen. Man kann Rust in 
bestehenden C++ Projekten nutzen ohne die bisherige Arbeit zunichte zu 
machen.

: Bearbeitet durch User
von cppbert (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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 :)

von zitter_ned_aso (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Das ist ja noch schlimmer.

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

von cppbert (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von Atemis H. (at0)


Bewertung
1 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.