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

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

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

Theor schrieb:
> Ich würde das Problem: "Entscheidung für eine Programmiersprache" in
> Bezug auf Verfügbarkeit ignorieren. (Mittel- und langfristig).

Das sehe ich etwas anders. Als ich mich damals(tm) im Jahr 2004 
selbstständig machte, war ein guter Freund von mir gerade ein großer 
Smalltalk-Fan und -Verfechter. Er versuchte fast täglich, mich dazu zu 
überreden, auch exklusiv mit Smalltalk zu entwickeln und alle alten 
Zöpfe abzuschneiden. Auf meine Nachfrage, für welche Microcontroller es 
denn Smalltalk-Umgebungen gäbe, fand er nach länglicher Suche einen 
Anbieter, der damals kurz vor dem Durchbruch stünde, Smalltalk für 
einige ARM-Prozessoren zu unterstützen. Super.

Und entgegen seiner damaligen Prophezeiungen ist Smalltalk immer noch 
nicht aus seiner Nische herausgekommen.

Es ist generell ein falscher Weg, nur noch auf ein einzelnes Pferd zu 
setzen, insbesondere wenn dessen Mutter noch gar nicht richtig schwanger 
ist.

> ich halte es für wichtig, mehrere verschiedene Sprachen zu können, oder
> neben zwei oder dreien, die man "kann" und aktiv verwendet, auch einige
> andere zu kennen.

Ja, so etwas ist sehr wichtig. Leider erlebe ich es auch bei manchen 
Kunden immer wieder, dass ausgerechnet die Leute mit den größten 
Scheuklappen diejenigen sind, die Architekturen mit seit zwanzig Jahren 
schwächelnden Konzepten entwerfen. :-/ Ein kleiner Blick auf andere 
Programmiersprachen und deren Konzepte würde völlig ausreichen, um zu 
erkennen, dass gigantisch verschnörkelte C-Präprozessor-Makros nicht 
mehr zeitgemäß sind, um damit halbwegs zukunftssichere APIs zu 
definieren.

Andreas S. schrieb:
> Auf meine Nachfrage, für welche Microcontroller es
> denn Smalltalk-Umgebungen gäbe, fand er nach länglicher Suche einen
> Anbieter, der damals kurz vor dem Durchbruch stünde, Smalltalk für
> einige ARM-Prozessoren zu unterstützen. Super

Das wäre bei Rust sicher nicht das Problem, da Rust auf das LLVM-Backend 
setzt

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

Auch schon im Jahr 2004?

Moin,

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

Naja, mal gucken: Fuer ein C Programm brauchst du z.b. einen 
gcc+binutils. gcc ist abhaengig von (Kernel und einer) libc.
Um einen llvm zu bauen,brauchste python, cmake und einen gcc. Also 
mindestens schon einen c++ compiler, sonst wirds nix mit cmake 
(wahrscheinlich auch fuer Python). Python hat die angenehme Eigenschaft, 
in Geschmacksrichtung (2 und 3) herzukommen; im Zweifelsfall brauchts 
dann auch immer beide.

Um rust zu bauen brauchste llvm und einen riesenhaufen Zeugs, der so 
riesig und komplex ist, dass das automatisch irgendwie von irgendwoher 
runtergeladen werden muss. Und dann noch diversen anderen, nicht so 
exotischen Kram wie auch wieder Python und libssh.

Jetzt kann man sich natuerlich als z.B. Ubuntu-Aeffchen auf den 
Standpunkt stellen: Ist mir alles wurscht. Ich hab's voll drauf, denn so 
wie Windowsprofis auf jede setup.exe klicken koennen, kann ich ja 
einfach "sudo apt-get gedoens" tippern und alles wird immer gut!einself!

Aber wenn man dann und wann auch mal Software fuer nicht-mainstream 
Platformen haben will, kann's schonmal beliebig bloed werden mit dem 
Herbeizaubern einer (ggf. cross-)toolchain und was man sonst noch an 
Umgebung braucht. Und da bin ich persoenlich echt froh, wenn's nicht so 
irrsinnig ausufert, nur weil unbedingt irgendwer irgendwelchen heissen 
Scheiss ausprobieren musste.
Aber das ist nur meine kleine, beschraenkte Meinung, Profi-Informatiker 
sehen das sicherlich ganz anders.

(Ocaml war glaub' ich auch mal ziemlich hipp, iirc gabs irgendwelches 
Filesharing-Zeugs was in Ocaml geschrieben war.)

Gruss
WK

Dr. Sommer schrieb:
> Konnte nicht eine LLVM-Installation automatisch für alle Targets Code
> generieren?
> Also die Komplexität des Bauens des Compilers ist ein ziemliches Dummy
> Argument. Einen GCC mit allen benötigten libc-Varianten zu bauen ist
> auch ganz schön zum Haare raufen.

Ja. Im Gegensatz zum GCC ist das ein Cross-Compiler in sich und benötigt 
nicht für jede Architektur einen eigenen Build. Mal abgesehn von der 
Schwachsinnigkeit des Arguments hat GCC übrigens wesentlich mehr 
(legacy) Abhängikeiten als LLVM und rustc.

Meiner Meinung nach ist Rust hier um zu bleiben. Das liegt zum einen 
daran weil die Community über die "critical mass" hinaus gewachsen ist 
und zum anderen weil Rust als WebAssembly Sprache wohl für viele sehr 
attraktiv sein wird.

Moin,

Dr. Sommer schrieb:
> Einen GCC mit allen benötigten libc-Varianten zu bauen ist
> auch ganz schön zum Haare raufen.

Eigentlich reicht ja eine. Aber OK, auch die kann schmerzhaft sein. Nur, 
wenn das schon nicht klappt, wie wirds dann llvm und "schlimmeres" 
geben?

Vincent H. schrieb:
> Ja. Im Gegensatz zum GCC ist das ein Cross-Compiler in sich und benötigt
> nicht für jede Architektur einen eigenen Build.
Das klingt interessant. Haste mal ein Beispiel, wie man so auf die 
Schnelle mit einem llvm aufm x86_64 PC so was ganz simples wie ein 
HelloWorld fuer eine gaengige Architektur wie z.b. ARM crosskompilieren 
kann?

> Mal abgesehn von der
> Schwachsinnigkeit des Arguments hat GCC übrigens wesentlich mehr
> (legacy) Abhängikeiten als LLVM und rustc.
OK, und was waeren das fuer "(legacy) Abhängigkeiten"?

Vincent H. schrieb:
> Meiner Meinung nach ist Rust hier um zu bleiben. Das liegt zum einen
> daran weil die Community über die "critical mass" hinaus gewachsen ist
> und zum anderen weil Rust als WebAssembly Sprache wohl für viele sehr
> attraktiv sein wird.

Naja, die verwendete Sprache sollte halt zum zu loesenden Problem 
passen. Da kanns schon sein, dass jetzt moderner Webkram mit Rust die 
tollste Wurst ist.
Ich sag' nochmal: Wenn man sicher ist, sich jederzeit mit "sudo apt-get 
install", setup.exe oder aehnlich "evelynesken" Kommandos die benoetigte 
Umgebung herzaubern kann, dann ist das alles simpel.

Nachdem aber im Eroeffnungspost explizit ein Zeitraum von 10 Jahren 
angegeben wurde, hab' ich halt so meine Zweifel an rust. Aber natuerlich 
kann ich nicht in die Zukunft blicken, nur aus der Vergangenheit 
versuchen zu interpolieren...

Gruss
WK

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

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

1

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

Default ist natürlich x86.

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

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

Moin,

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

1

echo "main() {}" > hello.c

2

clang  hello.c #OK, da faellt ein a.out raus.

3

clang -target arm-none-eabi hello.c 

4

error: unable to create target: 'No available targets are compatible with this triple.'

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

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

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

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

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

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

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


Gruss
WK

Wenn BLFS und Co für dich die Messlatte für etablierte Sprachen ist, 
dann wirst du am Sterbebett noch mit K&R C zu tun haben (müssen). ;)

Dafür dass du bei deinen Builds alle Targets rausnimmst kann ja ich nix.

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

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.

cargo als Paketmanager ist nett für
a) Windows-Nutzer, denn da muss der Anwender sowieso irgendwie mit der 
DLL-Hölle leben

b) Entwickler, die sich nur um eine spezifisch gepflegte Zielplattform 
kümmern müssen (z.B. die speziell für diese Applikation gedachten 
Cloudserver)

Wenn Du aber eine Linux-Distribution pflegen willst, bei der Du jede Lib 
möglichst nur ein mal zentral vorhalten & gemeinsam aktualisieren können 
willst, dann macht Dir das cargo das Leben schwerer als nötig.

Das zentral Vorhalten und gemeinsam Aktualisieren ist vom Aspekt der 
Sicherheitspflege ein ganz entscheidender Punkt. Ich als Admin der eine 
solche Distribution nutzt, kann so ganz einfach prüfen was für einen 
Stand, Patchlevel,... eine bestimmte Lib hat und es verstecken sich eben 
nicht noch 20 andere Kopien der selben Lib in unterschiedlichen 
Versionen als .so oder statisch gelinkt auf der Platte.

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

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

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


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

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

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

Rust wird bleiben. Genauso wie Kotlin.

Aber die Vorgabe, wie ein Projekt strukturiert zu sein hat, und dass man 
Internetzugang braucht, um die Dependencies runterzuladen, und dass es 
einen Dienstleister im Internet geben muss, der mir die Daten 
bereitstellt, das ... stinkt.

Rust ist eine Sprache. Wozu muss man eine weltweite Übersicht über jeden 
bekommen, der diese Sprache spricht oder in ihr jemals etwas 
niedergeschrieben hat? Das einzige, was man sich damit reinzieht, sind 
Abhängigkeiten.

Ich kann C-Code aus den 80ern aus einem Usenet-Posting fischen, ihn 
kompilieren und ausführen. Zugegeben: Er stinkt, er ist unsicher, und 
vielleicht fällt er auch schlicht hin und kotzt er mir auf die Platte. 
Aber es ist prinzipiell möglich.

Wenn ich in 30 Jahren irgendwo Rust-Code finde, dann steht da "führe 
bitte dieses magische Script aus, welches sämtliche Abhängigkeiten 
automatisch runterlädt und installiert" (d.h. mir am System pfuscht) an. 
Die Server gibt es nicht mehr, die Abhängigkeiten gibt es nicht mehr, 
die Dateien selbst finde ich vielleicht noch irgendwo, aber ich kriege 
sie ohne weiteres nicht mehr in das Build integriert.

Magie lässt sich schlecht debuggen, vor allem, wenn schon lange kein 
Mana mehr in der Umgebung ist...

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

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

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

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

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

Atemis H. schrieb:
> Das war mal aber vielleicht. Die Ansprüche dass Code sich auch in 15 der
> 30 Jahren compilieren lassen muss und dass es auch ohne Internet und
> Dienstleister gehen muss.

Bei Consumermüll vielleicht.

Atemis H. schrieb:
> Ich frage mich auch ob die Entwickler die die Hardware von Smartphones
> entwickeln auch das Bedürfnis haben dass ihr Code 20 Jahre hält.
> Wenn quasi jährlich ein neues Modell entwickelt werden muss mit neu
> entwickelter Hardware.
>
> Die Apps verlieren jedenfalls nach ein paar Updates des Betriebssystems
> ihre Kompatibilität.

Eben, Consumerkram. In der Industrie muss das Ding auch schon mal 15 
Jahre halten, oder zumindest reparierbar sein.

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.

Test schrieb:
> Das Konzept von Rust ist
> prinzipiell gut: Keine Laufzeitumgebung, keine Garbage Collection,
> sicher, performant, produktiv. Mal sehen wie sich das entwickelt...

Im Microcontrollerbereich wird der Erfolg von Rust entscheidend davon 
abhängen, ob Programmgeneratoren wie CubeMX oder Vivado/SDK 
Peripheriedefinitionen in Rust erzeugen können. Und im 
Automobilsteuergerätebereich ist ebenfalls wichtig, dass solche 
Platzhirsche wie z.B. Vector Informatik auch Rust unterstützen.

nickm schrieb:
> Fast alle oben genannten Sprachen hab ich mal verwendet oder haben mich
> sehr interessiert. Und was ist geblieben? C!

Die anderen die du aufgezählt hast sind auch noch alle da, du siehst sie 
nur nicht mehr weil du nicht mehr hinschaust (aus Zeitmangel wegen C).

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

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

> Modula
> Eiffel

Ziemlich tot.

> Occam

Wurde nur für Transputer geschaffen.

> Fortran

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

> Smalltalk

Nischenanwendungen

> Cobol

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

> Basic

z.B. Microsoft VBA in jedem Office-Paket

> Tcl

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

> C
> C++

Definitiv sehr weit verbreitet.

> Objective C

App-Entwicklung für Apple iOS.

> XC
> C99

C-Dialekte.

> AWK

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

> Java

Sehr verbreitet.

Andreas S. schrieb:
> Test schrieb:
>> Das Konzept von Rust ist
>> prinzipiell gut: Keine Laufzeitumgebung, keine Garbage Collection,
>> sicher, performant, produktiv. Mal sehen wie sich das entwickelt...
>
> Im Microcontrollerbereich wird der Erfolg von Rust entscheidend davon
> abhängen, ob Programmgeneratoren wie CubeMX oder Vivado/SDK
> Peripheriedefinitionen in Rust erzeugen können. Und im
> Automobilsteuergerätebereich ist ebenfalls wichtig, dass solche
> Platzhirsche wie z.B. Vector Informatik auch Rust unterstützen.

Ich finde der Name der Sprache wurde geradezu für den Automobilbereich 
maßgeschneidert.

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

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

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

Heimlehrgangprogrammierer schrieb:
> Solange Rust nicht kommerziell Mainstream wird und von den Tool
> Platzhirschen offiziell unterstützt wird und von gängigen
> Sicherheitsstandards nicht miteingeschlossen wird, [...]

wird es in Bereichen, die diese gängigen Sicherheitsstandards verlangen, 
nicht eingesetzt werden. Richtig.

Heimlehrgangprogrammierer schrieb:
> Auch müssen uC Belange genauso gut wie bei den existierenden
> Werkzeugen verläßlich und komplett unterstützt sein.

Nicht unbedingt. Man kann vieles in Bibliotheken auslagern (z.B. AVR: 
__flash gilt nur für C, alle anderen müssen PROGMEM nutzen). Absolute 
Vollständigkeit ist selten relevant (z.B. float auf AVR oder C99/C11 für 
Visual C++), wichtig ist das passende Subset.

Heimlehrgangprogrammierer schrieb:
> Und Ausnahmen bestätigen in diesem Fall nicht die Regel.

Du meinst, Sprachen wie PHP oder Javascript sind Nischenprodukte?

Deine Brille ist auf eine Branche geeicht und da ist das teilweise so. 
Trotzdem sind das mit die größten Sprachen auf diesem Planeten...

Dr. Sommer schrieb:
> vn n. schrieb:
>> Bei Consumermüll vielleicht.
>
> Der sogenannte Consumermüll ist aber die vorderste Front der
> High-Tech-Entwicklung. Für Smartphones werden die sparsamsten
> leistungsfähigsten SoCs entwickelt, fürs Gaming die besten Grafikkarten,
> für PCs die größten HDDs und CPUs.

Ist ja auch bitter notwendig, denn Consumersoftware läuft immer 
schlechter und schlechter und wird immer aufgeblähter. Letztens erst 
wieder gehört "warum soll ich mich um Effizienz kümmern, hab doch eh 4GB 
RAM am Raspberry". Und dann wundert man sich, dass in der User 
Experience nichts zu merken ist von der ständig besser werdenden 
Hardware.
Und nein, dein süßer kleiner Gaming-PC hat sicher nicht die größte CPU 
oder Festplatte. Die stecken eher in Servern.

Dr. Sommer schrieb:
> Die Betriebssysteme aus dem
> Consumer-Bereich (DOS, Windows) sind schon lange auch im professionellen
> Umfeld angekommen.

Leider. Managemententscheidungen halt. Windowssysteme, am besten auch 
noch mit Internetzugang, mitten in Anlagensteuerugen, an denen 
Menschenleben hängen. Wunderbar, so muss Fortschritt!

Dr. Sommer schrieb:
> Hinsichtlich Bedienbarkeit und Leistung ist
> Consumer-Software Vorbild für professionelle Software - eine Software
> von Format "WhatsApp" kann sich nicht leisten, alle 17 Minuten mit
> "Fehler 97832, bitte Handbuch konsultieren" abzustürzen. Bei
> Industriesoftware wird das schon eher akzeptiert.

Spaßvogel! Hast du auch nur einen blassen Schimmer, was Ausfallzeiten in 
der Indutrie kosten? Bei meinem Arbeitgeber ist das noch harmlos, je 
nach Kunden werden pro Stillstandstag bis zu 15.000€ Strafzahlung 
fällig. Belieferst du die Autoindustrie, wirds fünf- bis sechsstellig!

Dr. Sommer schrieb:
> Im Consumer-Bereich
> muss man immer mit den neuesten Entwicklungen gehen, der knallharten
> Konkurrenz voraus sein, neueste Standards beherrschen und eben auch die
> Hardware aktualisieren.

Meine Güte, bist du naiv.

Dr. Sommer schrieb:
> Soviel zu "Müll" - der Consumerbereich ist die echte Welt mit rapidem
> Fortschritt, während der Industriesektor ein gemütlicher Sandkasten mit
> realitätsfernen Bedingungen ist.

Du solltest vielleicht mal einen kleinen Realitätsabgleich machen.

Dr. Sommer schrieb:
> vn n. schrieb:
>> Und dann wundert man sich, dass in der User
>> Experience nichts zu merken ist von der ständig besser werdenden
>> Hardware.
>
> Niemand wundert sich darüber. Das ergibt sich einfach aus den
> Anforderungen der Kunden, möglichst feature-reiche Softwares möglichst
> schnell und möglichst billig zu bekommen. Wenn die Kunden bereit wären,
> für WhatsApp und Konsorten ordentlich zu bezahlen, sähe das schon anders
> aus.

Klar, es ist natürlich immer der Kunde schuld. Kennen wir eh schon. So 
wie bei den Haltebedingungen in der Tierhaltung, das will ja auch der 
Kunde so.
Und nebenbei, auch noch zahlen dafür, dass Facebook via WhatsApp Daten 
abschnorchelt und meistbietend verkauft? Im übrigen ist es tatsächlich 
so, dass ein Großteil der Ladezeit und der Rechenleistung bei Webseiten 
mittlerweile nicht für die Funktion drauf geht, sondern für Werbung und 
Tracking. Will ja der Kunde so. Und die drölfzig unsicheren 
JS-Frameworks als Abhängigkeiten, die will auch der Kunde.

Dr. Sommer schrieb:
> vn n. schrieb:
>> Und nein, dein süßer kleiner Gaming-PC hat sicher nicht die größte CPU
>> oder Festplatte. Die stecken eher in Servern.
>
> Die aufgebohrte Consumer-Technik sind - x86 war von Anfang an nur für
> Consumer gemacht, während es gleichzeitig schon viel bessere
> Server-Prozessoren gab - die jetzt nahezu verdrängt sind.

Dass x86 ursprünglich ausschließlich im PC-Bereich verwendet wurde, 
ändert nix dran, dass Consumer-CPUs nicht gerade das Ende der 
Fahnenstange markieren.

Dr. Sommer schrieb:
> vn n. schrieb:
>> Belieferst du die Autoindustrie, wirds fünf- bis sechsstellig!
>
> Ich kenne diverse Software für die Automobil-Industrie, die öfters
> zufällig abstürzt. Rat des Herstellers: "Einfach neustarten".

Mein Rat: Hersteller wechseln.
Ja, ich weiß, das Management und der Support neigt gerne dazu, dem 
Kunden einzureden, ein Verhalten wie man es von Windows gewöhnt ist, sei 
normal. Versuchen unsere auch manchmal. Sollte man halt möglichst früh 
unterbinden, wenn man auch nur ansatzweise Qualitätsanspruch hat.

Aber nun würde mich ja doch interessieren, welche Software das denn sein 
soll. Oder handelt es sich um leere Worte?

Dr. Sommer schrieb:
> vn n. schrieb:
>> Meine Güte, bist du naiv.
>
> Ah, hier kommen die persönlichen Angriffe. Du bist viel naiver als ich!

Keine Angst, das ist kein persönlicher Angriff. Da du scheinbar 
ernsthaft glaubst, irgendwelche Server-Hardware, Hochleistungs-FPGAs und 
schnelle DSPs würden im Consumerbereich eingesetzt, während in der 
Industrie irgendwelche alten Krücken laufen, womöglich noch mit Android 
und Java, kann man nur von Naivität sprechen.
Aber vielleicht verwechselst du auch nur den Umstand, dass so ein 
Smartphone einen Octacore und 8GB RAM benötigt, um seinen eigentlichen 
Aufgaben neben Java-Overhead und den dutzenden Werbetrackern in jeder 
App auch nur leidlich nachzukommen, mit Innovation.

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

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

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

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

zitter_ned_aso schrieb:
> PS: Normalerweise sind alle Infos (data sheets, etc.) auch auf Englisch.

Nein, nur ein winziger Bruchteil aller Datenblätter ist in englischer 
Sprache geschrieben. Wir befinden uns nämlich auch nur in einer 
"Filterblase" und sehe daher nur sehr selten chinesische Datenblätter. 
Ich wurde schon mehrmals damit konfrontiert, mit anhand rein 
chinesischer Dokumentation meinen Teil zusammenreimen zu müssen.

Warum sollte auch ein Chinese, der (fast) kein Wort Englisch kann, sich 
die Mühe machen, ein Datenblatt in einer Sprache zu schreiben, die nur 
wenig Bedeutung in dem Zielmarkt des Produkts hat? Insbesondere Bauteile 
für den "Consumerschrott" werden zum allergrößten Teil in China 
verarbeitet. Die 3% an Stückzahlen, die direkt an europäische 
Gerätehersteller geliefert werden, rechtfertigen nicht unbedingt den 
Aufwand, dafür Datenblätter in einer völlig fremden Sprache wie Englisch 
zu verfassen.

Mir ist allerdings nicht bekannt, ob Programmiersprachen, deren 
Schlüsselwörter komplett in einer asiatischen Sprache formuliert sind 
und ggf. auch auf einem asiatischen Zeichensatz basieren, derzeit 
halbwegs relevant sind. Dass es z.B. unter japanischem MS Windows auch 
BAT/CMD-Skripte mit japanischem Zeichensatz gibt oder zumindest mal gab, 
konnte ich vor etlichen Jahren selbst erleben. Damals wollte ich ein 
bestimmtes Programm auf dem Schlepptop eines japanischen Gastes 
installieren, was mir aber aus besagtem Grund nicht gelang. Seine 
Englischkenntnisse waren aber auch nicht so gut, dass er selbst die 
Programmdokumentation vollständig verstehen konnte. Wir gingen aber sehr 
stark davon aus, dass das Programm wohl deswegen nicht funktionierte, 
weil es eben mit dem japanischen Zeichensatz nicht zurechtkam.

Deine obige Aussage bedeutet also nur, dass Du völlig den Bezug zur 
heutigen(!) Realität verloren hast, d.h. das was nicht sein soll, darf 
auch nicht sein.

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

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

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

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

--

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

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

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

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

Ja, so war das bei MS Office. Es gab auch anfangs wohl weder eine 
automatische Übersetzung in die jeweilige Landessprache noch Englisch 
als Rückfallsprache. Glücklicherweise nutzte ich zu der Zeit Star Office 
und LaTeX.

Es gibt aber auch noch eine Steigerung: ein Bekannter arbeitete als 
Systemadministrator, überwiegend mit AIX-Maschinen. Irgendwann konnte 
niemand mehr auf dem Postscript-Netzwerkdrucker drucken. Die Druckjobs 
trafen zwar bei dem Drucker ein, produzierten der aber nur 
Fehlermeldungen. Es stellte sich heraus, dass auf dem Rechner, auf dem 
der Druckerspooler lief, nach einem AIX-Update die deutsche 
Lokalisierung aktiviert wurde. Hierdurch wurden auch die im deutschen 
und amerikanischen Kulturkreis gegensätzlichen Dezimalpunkte und 
-kommata vertauscht, d.h. der Spooler griff in die Druckjobs ein und 
erzeugte "Postscript mit deutschen Zahlen".

> Dann hat der Entwickler Mist gebaut.

Ja, das ganze Programmpaket (Telelogic Tau SDL) war ziemlich fehlerhaft.

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

Damals(tm) bearbeiteten zwei sehr unerfahrene Kollegen ihre C-Quelltexte 
mit MS Wordpad statt mit einem Texteditor und wunderten sich dann über 
komische Fehlermeldungen des Compilers. Das war eigentlich nicht 
schlimm, aber beide erwiesen sich als ziemlich beratungsresistent und 
verstanden nicht, dass der von Wordpad dargestellte Inhalt eben nicht 
identisch mit dem Dateiinhalt war. Die beiden fanden es sogar eine gute 
Idee, die Quelltexte mit den Mittels von Workpad aufzuhübschen, d.h. 
verschiedene Fonts, Fettschrift usw. zu verwenden, also 
Syntaxhighlighting für Arme zu betreiben. Und wenn dann solch ein 
"hübscher" Quelltext einfach eingecheckt wird, ohne ihn vorher selbst 
erfolgreich kompiliert zu haben, verlagert man die Fehlersuche auf die 
Kollegen und kann sich anschließend auch noch darüber beschweren, dass 
die Kollegen die hübsche Formatierung wieder entfernt hätten.

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

Damals(tm) hatte ich ein Entwicklungsboard zu einem NEC (mittlerweile 
Renesas) V850. Bei dem beigefügten GCC waren leider alle Meldungen bunt 
eingefärbt, so dass man zum einen gleich Augenkrebs bekam und zum 
anderen die Meldungen ein Editor o.ä. mit den Meldungen nichts mehr 
anfangen konnte.

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

Oh ja, und machten Leute machen das nicht etwa auf Grund von 
Flüchtigkeitsfehlern, sondern weil sie meinen, der Software eine 
individuelle Note geben zu müssen, und dabei nicht beachten, dass der 
Scheiß unbenutzbar oder gar fehlerhaft wird. Andererseit mag ich solche 
Entwickler, weil sie mir Aufträge sichern.

Andreas S. schrieb:
> Es stellte sich heraus, dass auf dem Rechner, auf dem der Druckerspooler
> lief, nach einem AIX-Update die deutsche Lokalisierung aktiviert wurde.
> Hierdurch wurden auch die im deutschen und amerikanischen Kulturkreis
> gegensätzlichen Dezimalpunkte und -kommata vertauscht, d.h. der Spooler
> griff in die Druckjobs ein und erzeugte "Postscript mit deutschen
> Zahlen".

Selbst der C-Compiler war damals wohl davon betroffen. Da hatte man 
offenbar im Rundumschlag überall “setlocale(LC_ALL, "");” eingefügt ohne 
drüber nachzudenken, ob das nun für jedes Dienstprogramm so passend 
ist.

Ist aber schon eine gaaanze Weile her, war zu Beginn der Zeit, wo die 
Geschichte mit den locales aufkam. Gewissermaßen haben sie damals bei 
AIX Lehrgeld für alle bezahlt.

Nano schrieb:
> Insofern sieht's bei C und C++ bezüglich Abhängigkeiten nicht wirklich
> besser aus. Der Eindruck täuscht lediglich, wenn es nicht sogar
> schlimmer ist, da die Wahrscheinlichkeit, dass wenig benutzte Quellen
> viel größer ist, als eine zentrale Anlaufstelle.

Das seh ich auch so. Dazu kommt das crates meines Wissens nach lediglich 
als sowas wie "deprecated" markiert werden können, vom Ersteller selbst 
aber nicht direkt gelöscht.

Hat man in seinem C/C++ Projekt Abhängigkeiten zu einer alten Library 
auf irgendeinem Git-Repo deren Entwicklung eingeschlafen ist, dann ist 
man gut damit beraten diese lieber zu forken...

Nano schrieb:
> Er könnte aber eine Lib Voraussetzen, die früher mal auf einer
> Mailbox vertrieben wurde und nun nicht mehr auffindbar ist.

Abgesehen davon, dass das äußerst unwahrscheinlich ist... wenn die 
Mailbox nicht mehr existiert, dann ist das ein Problem.

Nano schrieb:
> Wenn bei Rust crates.io noch vorhanden ist,
> wirst du die Lib noch finden.

Das setzt voraus, dass crates.io noch existiert, die alten Versionen 
noch vorrätig hält und kompatibel funktioniert. Gibt genug Webseiten und 
Dienste, die aus verschiedensten Gründen wieder verschwunden sind.

Ich sehe da keinen Unterschied. Wenn der zugrundeliegende Dienst stirbt, 
hab ich ein Problem - aber wenn ich auf den Dienst angewiesen bin, ein 
wesentlich größeres.

Gegeg J. schrieb:
> also wenn Du Pascal Code aus dem Netz fischt aus den 80ern..
> und unter Freepascal kompilierst..geht das auch?

Pascal hatte nie einen gebrauchbaren Sprachstandard. Daher ist 
Pascal-Code immer an den entsprechenden Compiler gebunden. Wenn 
Freepascal zufällig kompatibel zu deinem nicht näher genannten "Pascal 
Code" ist... ja?

Davon abgesehen ändert das am Abhängigkeitsmanagement nichts.

Bei den meisten C/C++/etc. Sprachen haben die meisten Programme nur ein 
paar wenige Abhängigkeiten, nur die grösseren Programme haben etwas 
mehr. Man muss diese dann ja von irgendwo her holen, und wenn da kein 
Script dabei ist, dass das macht, muss man die erst mal selbst 
installieren. Zudem will man ja in der Regel die Version der Library, 
die schon in der Distro ist verwenden, sofern möglich. Deshalb ist es 
hier aufwendiger, Abhängigkeiten zu nutzen.

Bei rust mit cargo sieht es aber vermutlich genauso aus wie bei nodejs 
mit npm. Dependencies können einfach so rekursiv geholt werden. Zieht 
euch mal eine beliebige nodejs Seite von GitHub runter, ein npm install 
und schon hat man hunderte bis tausende Pakete heruntergeladen. Ein 
Packet das man will einfach in die Liste schreiben, das ist zu einfach. 
Die Leute denken dann gar nicht mehr nach, ob sie X brauchen. Bei cargo 
ist es vermutlich noch nicht ganz so schlimm wie bei npm, aber ich 
garantiere euch, besser wird es mit der Zeit sicher nicht.

Ich meine, wenn man das komplette crates.io, also alle Pakete, nicht nur 
die Metadaten mirroren könnte, ginge das ja eventuell noch. Obwohl, bei 
der Datenmenge, wäre das vielleicht so oder so für die meisten nicht 
mehr möglich. Aber zu glauben, dass crates.io nicht eines Tages stirbt, 
halte ich für eine Illusion. Jeder webservice verschwindet irgend wann 
mal, auf die eine oder andere weise. Und wenn das Ding dann mal weg ist, 
dann bricht die Hölle los, dann ist nicht nur ein obskures Programm 
betroffen, sondern so ziemlich jedes.

Und jetzt nochmal kurz zurück zu Libraries aus den Paketquellen von 
Distros. Es gibt wohl rust und cargo basierte Pakete in z.B. Debian, es 
ist möglich. Traditionell sollte, zumindest in Debian, jedes Paket einen 
Maintainer haben, der es up-to-date hält. Wichtiger aber, es gibt 
Richtlinien, was in die Repos der Distro darf, und was nicht. Altes wird 
eventuell auch mal wieder aufgeräumt (entfernt). Bei Programmen, die 
PIP, NPM, Cargo, etc. nutzen, werden viele Entwickler sich nur darum 
kümmern, was in den default Repos der Tools ist. Ob die 1000+ 
Dependencies, die da dahinter hängen, auch in Distro X ist, wird denen 
egal sein. Für Paketmaintainer wird das die Arbeit massiv erschweren. 
Deshalb werden viele der Programme nicht in die Distro Repos gepackt 
werden, weil zu aufwendig. Diese werden die Nutzer dann halt selbst über 
die tools und deren Repos installieren. Die Software in den Repos dieser 
Tools nicht den gleichen Grad der Kontrolle, wie z.B. die Debian Repos, 
da jeder einfach so zeug hochladen kann, ohne dass da noch andere drüber 
schauen. Dies erhöht das Risiko von Adware und software supply chain 
attacks massiv. Ähnlich wie bei z.B. Flatpack und vergleichbaren 
Technologien verlieren die Distributoren so nach und nach die Kontrolle 
über die Software, die sie brauchen. Die Softwarepolitik der 
Distributionen, die Qualitätsstandards, die diese an die Software in 
ihren Repos stellen, verlieren nach und nach an Bedeutung, was ich für 
eine durchaus gefährliche Entwicklung halte.

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

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

Gegeg J. schrieb:
> Turbo Pascal hieß immer Turbo Pascal und war von Borland...

Falsch. Turbo Pascal hieß vorher Compass Pascal Compiler und davor Blue 
Label Software Pascal Compiler.

> und Borland hatte Pascal überhaupt erst erfolgreich gemacht.

Auch falsch. Borland hat Pascal auf IBM-kompatiblen PCs mit 
PC-DOS/MS-DOS erfolgreich gemacht. Zuvor war UCSD Pascal ausgesprochen 
erfolgreich auf Apple II usw.. Und auf Mehrbenutzersystemen wurden viele 
Anwendungen von Algol nach Pascal portiert, da es ähnlicher als Cobol 
oder FORTRAN war.

> Davor war Pascal kaum zu gebrauchen udn wie so oft vorgekaut..eher eine
> reine Lehrsprache.

Falsch, siehe oben.

> https://de.wikipedia.org/wiki/Turbo_Pascal
> oder
> https://www.bernd-leitenberger.de/turbo-pascal-history.shtml

Dort wird die Historie von Turbo Pascal beschrieben, nicht von Pascal 
auf anderen Plattformen.

> "Ohne Turbo Pascal hätte die Sprache Pascal sicher das gleiche Schicksal
> ereilt wie viele an Universitäten vorher und nachher geborene
> „Kunstsprachen“, z. B. Modula-2 oder Oberon (beide auch von Niklaus
> Wirth), die heute praktisch verschwunden sind"

Das ist durchaus zutreffend, aber betrifft erst die jüngere Geschichte, 
d.h. ab Ende der 1980er Jahre. Auf UNIXoiden Betriebssystemen konnte 
sich Pascal nicht durchsetzen, da dort häufig schon ein C-Compiler 
mitgeliefert wurde, und unter MS Windows war C angesagt.

Die Tatsache, dass Pascal heutzutage außer im SPS-Bereich kaum noch 
anzutreffen ist, bedeutet nicht, dass es früher in anderen Bereichen 
sehr erfolgreich war. Die Namen Modula-2, Oberon, Eiffel und Konsorten 
kennen zwar viele Leute, aber diese Sprachen konnten sich nun wirklich 
nicht groß durchsetzen. Und dann gibt es natürlich noch die Unmengen an 
Programmiersprachen, die so erfolglos waren, dass sogar das Internet sie 
teilweise schon vergessen hat, wie z.B. Fungol.

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

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

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

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

Neben dem eigentlichen Programmieren in einer oder mehreren 
Programmiersprachen muss man auch das Debugging im Auge behalten, 
insbesondere wenn dies auf Hochsprachenebene geschehen soll. Und an der 
Stelle unterstützten die allermeisten Debugger derzeit nur C und C++, in 
wenigen Fällen auch das Debuggen von Java Bytecode.

Natürlich kann man sich hinstellen und behaupten, dass in Rust viele 
Fehler vermieden würden, für die man bei klassischer C-Programmierung 
den Low-Level-Debugger herausholen muss. Dies ist sicherlich auch 
korrekt. Im Microcontrollerbereich gibt es aber auch noch die Unmengen 
an Hardwareabhängigkeiten und solche Themen wie Heap- und 
Stack-Kollisionen.

So gerne ich auch auf Rust umstellen würde, so sehr sehe ich da noch ein 
paar Hindernisse.

Andreas S. schrieb:
> unterstützten die allermeisten Debugger derzeit nur C und C++, in
> wenigen Fällen auch das Debuggen von Java Bytecode.

Es gibt keinen Debugger für Rust? Das mag ich kaum glauben.

Bernd K. schrieb:
> Andreas S. schrieb:
>> unterstützten die allermeisten Debugger derzeit nur C und C++, in
>> wenigen Fällen auch das Debuggen von Java Bytecode.
>
> Es gibt keinen Debugger für Rust? Das mag ich kaum glauben.

Kannst Du nicht lesen oder mangelt es Dir am Textverständnis?

Die Aussage "die allermeisten Debugger" ist keinesfalls identisch mit 
"alle Debugger".

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

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

Warum erbrichst du deinen Frust in einen Thread über die Sprache Rust, 
obwohl euer Mismanagement damit rein gar nichts zu tun hat? 
Mismanagement kann man in jeder beliebigen Sprache und jeder beliebigen 
Umgebung implementieren.

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

Das von Dir aufgezeigte Beispiel ist ein hervorragendes Beispiel für 
Pfusch auf Eurer Seite. Wenn man von solchen externen Komponenten 
abhängig ist, zieht man diese während des Build natürlich nicht von 
Github und Konsorten, sondern von einem eigenen Mirror solche 
Repositories. Solche Mirrors haben natürlich mindestens den gleichen 
Lebenszyklus wie die darauf basierenden Projekte/Produkte, d.h. sie 
müssen ebenfalls der Datensicherung unterworfen sein. Solange die 
externen Repositories aktiv sind, kann man die lokalen Mirrors auch 
wunderbar per cron-Job o.ä. synchronisieren. Anhand der dabei 
generierten Logs sieht man auch wunderbar, ob bzw. was sich auf den 
Upstream-Repositories tut.

Der Erfolg von verteilten Versionskontrollsystemen wie z.B. Git basiert 
eben darauf, dass man nicht nur Sandboxes auschecken, sondern 
Repositories munter klonen kann. Und wenn Ihr nicht die entsprechenden 
Vorkehrungen trefft, wenn ein "Jungspund" mit externen Repositories 
arbeiten will, ist das Euer Organisationsversagen.

Bibo schrieb:
> Und bei dem ganzen abgekotze, habe ich direkt den Grund für das Ganze
> vergessen:
>
> Besagter, ausgeschiedener Kollege, hat das angeleiert. In Zusammenarbeit
> mit einer Hochschule etwas für die Open-Source Gemeinde zu tun.
>
> Alles was bisher passiert ist, war Fehlersuche/Flicken und die Kunden
> bekamen Quelltexte mit ihren Produkten.
> Kein Student, keine Öffentlichkeit hat bisher was davon gesehen...

Vor lauter abgekotze hast du ganz vergessen, dass das Problem bei euch 
nicht Open Source ist, sondern euer komplett kaputter Buildprozess.
Projekte, die nur lokal kompiliert werden, sind in einem professionellen 
Umfeld ein absolutes No-Go. Lokal wird zur Entwicklung kompiliert, dann 
wird in die Versionskontrolle eingecheckt und der Buildserver braut ein 
reproduzierbares Image. Natürlich hat der auch die Anhängigkeiten 
vorliegen.

Bibo schrieb:
> Ich wollte damit ein Beispiel für nicht wiederholbare Builds geben.

Vielleicht solltest du besser mal anfangen, den Grund für den nicht 
reproduzierbaren Build an der richtigen Stelle zu suchen. Aber das tust 
du nicht, denn:

Bibo schrieb:
> Mich soll's nicht stören, ich werde dafür bezahlt.

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

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

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

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

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

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

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

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

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

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

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

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

> Auch der Rest von dir ist falsch widerlegt.

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

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

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

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

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

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

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

Ok, wahrscheinlich ist "Turboiges" Pascal das einzig Überlebende seiner 
Art, ich kann die immernoch begeisterten ja bis zu einem gewissen Punkt 
verstehen, war doch TP CP/M meine erste 
Hochsprachenentwicklungsumgebung.

nur: wo ist die Verbindung zu Rust?

Nano schrieb:
>> Ich sehe da keinen Unterschied. Wenn der zugrundeliegende Dienst
>> stirbt, hab ich ein Problem - aber wenn ich auf den Dienst
>> angewiesen bin, ein wesentlich größeres.
>
> Du kannst auch Backups von den 3rd Party Sachen machen,
> die du für dein Projekt brauchst.

Das setzt aber voraus, dass der zugrundeliegende Dienst das in einer 
sinnvollen und nutzbaren Weise anbietet. Tut er das nicht, muss ich 
Aufwand treiben, der je nach Design des Dienstes bis auf eine komplett 
eigene Infrastruktur steigen kann.

> Das würde ich ohnehin tun. Denn Vertrauen ist gut, Kontrolle ist besser.

Im kommerziellen Umfeld: Definitiv ja.

sonstnochwer schrieb:
> Ich vermute, die Rede ist von µC?
> Weil für neue PC-Projekte nutzt man C ja eher selten.

Das glaubst aber nur du. :-)

Wobei man fairerweise dazu sagen muss, dass auf dem PC so ziemlich jeder 
C-Code durch einen C++-fähigen Compiler läuft. Aber die meisten meiner 
Tools sind entweder gescriptet oder klassisch C, auch auf dem PC.

Carl D. schrieb:
> Ok, wahrscheinlich ist "Turboiges" Pascal das einzig Überlebende seiner
> Art,

Wie schon erwähnt, wird Pascal im SPS-Bereich eingesetzt und ist dort 
eine recht "moderne" Sprache. Dort heißt es ST (Strukturierter Text nach 
EN 61131-3 bzw. ISO 61131) und SCL (ST nach Siemens-Art). Gebräuchliche 
Entwicklungsumgebungen sind z.B. 3soft Codesys, Beckhoff TwinCAT PLC 
Control und Siemens STEP7 und Siemens TIA Portal.

> nur: wo ist die Verbindung zu Rust?

Hmmm, es ging um historische Vergleiche der Lebenszyklen von 
Programmiersprachen, passend zu diesem Thread.

Olaf schrieb:
> Yep. Ich hatte damals Hisoft-Pascal auf dem ZX Spektrum. Das war vor dem
> Apple][+

Vermutlich meinst Du den Apple II Europlus. Er wurde im Jahr 1979 in 
Europa auf den Markt gebracht, der Sinclair ZX Spectrum erst 1982. Ich 
bin aber selbst sehr erschrocken, wie lange das schon her ist. Nach 
meinem Bauchgefühl kam der TX Spectrum erst um 1985 heraus. Dafür hätte 
ich den ZX80 in den späten 1970er Jahren verortet, aber es war doch erst 
1980; beim ZX81 lag ich wiederum richtig. Ich dachte, der Zeitabstand 
zwischen den Modellen hätte bei mindestens zwei Jahren gelegen.

Wichtiger Hinweis für die anwesenden Jungspunde: die 
schaltungstechnischen Kniffe im ZX80 sind wirklich sehr interessant. Ich 
empfehle eine der vielen Webseiten, in denen die Schaltung analysiert 
wird. Ebenso interessant ist der Floppy-Controller im Apple II, d.h. der 
Vorgänger der IWM:

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

Falls sich mal jemand gefragt hat auf welchem Stand Rust Punkto 
"constant evaluation" gerade ist:
https://youtu.be/wkXNm_qo8aY?list=PL85XCvVPmGQhDOUIZBe6u388GydeACbTt

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

Moin,

Ich seh' sowas hier:

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

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

Gruss
WK

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

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

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

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

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

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

Atemis H. schrieb:
> Programmiersprachen werden nicht für die Ewigkeit gemacht
> und der Wert einer Programmiersprache definiert sich nicht
> allein dadurch wie lange alter Code compiliert werden kann.

Das hängt von der Verwendung ab. Wer es sich leisten kann (oder muss), 
sämtlichen Code einer größeren Codebasis regelmäßig umschreiben zu 
müssen, der kann auf solche Programmiersprachen zurückgreifen. Web- und 
Appentwicklung gehören dazu, viele andere Dinge nicht.

Atemis H. schrieb:
> Wer solche Bedürfnisse hat sollte am besten sowieso alle
> nötigen Dateien herunterladen und konservieren

Das wiederum setzt voraus, dass die Umgebung der Programmiersprachen das 
sinnvoll ermöglicht, also heruntergeladene Artefakte nicht nur als 
temporären Cache betrachtet.

Atemis H. schrieb:
> und nicht naiv erwarten dass die Welt die
> nächsten Jahrzehnte still stehen wird.

Wieviel alt ist die durchschnittliche Codezeile im Windows-Kernel?
Wieviel Code aus den 90ern findest du im Linux-Kernel?
Welche Teile von Android 10.0 sind seit Android 2.3 nahezu unverändert?

Mal so grob nach Schnellebigkeit sortiert.

Atemis H. schrieb:
> Damit wird auch die Software sicherlich schnelllebiger.

Wenn du damit auf "der Updater funktioniert, let's ship today" 
anspielst, dann hoffe ich mal stark, dass du das nicht als positives 
Zukunftsmodell anpreist.

Einen Markt für "relativ neue Programmiersprachen mit eigenem Ökosystem" 
gibt es definitiv, spontan denke ich so an Objective-C, C#, Swift, Go 
oder Kotlin. Mein Gefühl sagt allerdings auch, dass Rust nicht in diese 
Kategorie gehört (oder gehören will). Ich kann mich allerdings irren.

Nick M. schrieb:
> Kleiner Einspruch: Obj-C gibt es seit 1980. Das bezeichne ich
> nicht als "relativ neu". C gibt es seit Anfang der 70er.

Explizit nicht C/C++. Aber von ObjC hatte ich noch nie gehört, bis Apple 
das großflächig beworben hat. Daher ist das in meiner Welt "relativ 
neu". :-)

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

Die Sprache hatte ihren ersten Frühling beim NeXT.

Jörg W. schrieb:
>> Aber von ObjC hatte ich noch nie gehört,
> Die Sprache hatte ihren ersten Frühling beim NeXT.

Gegründet vor meiner Geburt, aufgekauft vor meinem ersten 
Englischunterricht in der Schule... ich glaub, ich bin entschuldigt. :-D

S. R. schrieb:
> Nick M. schrieb:
>> Kleiner Einspruch: Obj-C gibt es seit 1980. Das bezeichne ich
>> nicht als "relativ neu". C gibt es seit Anfang der 70er.
>
> Explizit nicht C/C++. Aber von ObjC hatte ich noch nie gehört, bis Apple
> das großflächig beworben hat. Daher ist das in meiner Welt "relativ
> neu". :-)

Ich hatte davon schon gehört, aber es hieß damals, das sei ein 
gescheiterter erster Versuch gewesen, C objektorientiert zu machen. Umso 
überraschter war ich, als Apple das plötzlich wieder ausgegraben und für 
sich zur Standardsprache erklärt hat.

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

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

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

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

Moin,

Also ich find' es schon sehr angenehm, wenn so Sachen wie z.B. der 
Bildbetrachter xv, der schon so ca. 30 Jahre auf dem Buckel hat, 
"einfach so" durch ein aktuelles make und einen aktuellen C compiler in 
ein lauffaehiges Binary uebersetzt werden kann. Das ist fuer mich ein 
Zeichen von gutem code, einer guten Programmiersprache und guten tools.
Davon seh' ich bei Rust eher nix.
Das ist irgendein wilder Wust aus einem wilden build-system, wildem 
package-manager und irgendwie mit llvm verknuspelt. Und mit viel Glueck 
faellt da dann mal was raus. Aber nur wenn man zig Gigabyte RAM hat. Und 
ja nix schiefgeht. Und alle Versionen aller Beteiligten exakt 
zusammenpassen. Und und und.

Und jetzt macht mich rot - aendert aber nix. Besser waer's an diesen 
Problemen zu arbeiten...

Gruss
WK

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.

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

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.

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

SCNR,
WK

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

Klingt spannend. Wenn das klappt, dann wäre das nach Mozilla selbst und
Microsoft eine weitere große und prominente Entwicklergruppe, die der
Verbreitung der Sprache Vorschub leistet.

Am Ende bleiben dann wohl nur noch

- Rust (für systemnahe und zeitkritische Programme),
- Python (für kleine Anwendungsprogramme) und
- Haskell (für große Anwendungsprogramme)

übrig, da alle drei sowohl von der Open-Source-Community als auch von
dem Softwareriesen Microsoft unterstützt werden, so dass neben den
technischen auch immer mehr die unternehmenspolitischen Hemmschwellen
fallen dürften. Aber natürlich werden auch Fortran, Cobol, C++, Java und
C# nicht völlig aussterben ;-)

Yalu X. schrieb:
> Am Ende bleiben dann wohl nur noch
>
> - Rust (für systemnahe und zeitkritische Programme),
> - Python (für kleine Anwendungsprogramme) und
> - Haskell (für große Anwendungsprogramme)

Also wenn ich so an viel verwendete oder aufstrebende 
Programmiersprachen denke, kommt mir Haskell nicht unbedingt als erstes 
in den Sinn. :)
Im PYPL-Index ist sie mit 0,29% auf Platz 27 (Tendenz fallend), im 
TIOBE-Index sogar nur auf Platz 40. Wenn sie es in den letzten 30 Jahren 
nicht darüber hinaus geschafft hat, ist es eher unwahrscheinlich, dass 
sich das plötzlich ändert.

Yalu X. schrieb:
> Aber natürlich werden auch Fortran, Cobol, C++, Java und
> C# nicht völlig aussterben ;-)

Vermutlich nicht :)

Rolf M. schrieb:
> Yalu X. schrieb:
>> Am Ende bleiben dann wohl nur noch
>>
>> - Rust (für systemnahe und zeitkritische Programme),
>> - Python (für kleine Anwendungsprogramme) und
>> - Haskell (für große Anwendungsprogramme)
>
> Also wenn ich so an viel verwendete oder aufstrebende
> Programmiersprachen denke, kommt mir Haskell nicht unbedingt als erstes
> in den Sinn. :)

Deswegen steht es ja nur an dritter und letzter Stelle ;-)

zitter_ned_aso schrieb:
> Es wäre schade jetzt viel Zeit in C (oder gar C++) zu investieren / die
> Sprachen zu lernen und später dann doch umsteigen :-(

Mach dir deswegen keine Sorgen. Ich weiß ja nicht, wieviel Lebens- und
Berufsjahre du noch vor dir hast, aber geh mal davon aus, dass bis zu
deinem Renteneintritt C und C++ nicht obsolet werden werden.