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


von DPA (Gast)


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)


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)


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)


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)


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)


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 Silc P. (silch12)


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)


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


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 Silc P. (silch12)


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


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)


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)


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)


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)


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)


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

: Bearbeitet durch User
von Theor (Gast)


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)


Lesenswert?

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

von Vincent H. (vinci)


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)


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)


Lesenswert?

Von rust werden momentan diese Architekturen unterstuetzt:
1
$ rustup target list
2
aarch64-apple-ios
3
aarch64-fuchsia
4
aarch64-linux-android
5
aarch64-pc-windows-msvc
6
aarch64-unknown-cloudabi
7
aarch64-unknown-linux-gnu
8
aarch64-unknown-linux-musl
9
arm-linux-androideabi
10
arm-unknown-linux-gnueabi
11
arm-unknown-linux-gnueabihf
12
arm-unknown-linux-musleabi
13
arm-unknown-linux-musleabihf
14
armebv7r-none-eabi
15
armebv7r-none-eabihf
16
armv5te-unknown-linux-gnueabi
17
armv5te-unknown-linux-musleabi
18
armv7-apple-ios
19
armv7-linux-androideabi
20
armv7-unknown-linux-gnueabihf
21
armv7-unknown-linux-musleabihf
22
armv7r-none-eabi
23
armv7r-none-eabihf
24
armv7s-apple-ios
25
asmjs-unknown-emscripten
26
i386-apple-ios
27
i586-pc-windows-msvc
28
i586-unknown-linux-gnu
29
i586-unknown-linux-musl
30
i686-apple-darwin
31
i686-linux-android
32
i686-pc-windows-gnu
33
i686-pc-windows-msvc
34
i686-unknown-freebsd
35
i686-unknown-linux-gnu
36
i686-unknown-linux-musl
37
mips-unknown-linux-gnu
38
mips-unknown-linux-musl
39
mips64-unknown-linux-gnuabi64
40
mips64el-unknown-linux-gnuabi64
41
mipsel-unknown-linux-gnu
42
mipsel-unknown-linux-musl
43
powerpc-unknown-linux-gnu
44
powerpc64-unknown-linux-gnu
45
powerpc64le-unknown-linux-gnu
46
riscv32imac-unknown-none-elf
47
riscv32imc-unknown-none-elf
48
s390x-unknown-linux-gnu
49
sparc64-unknown-linux-gnu
50
sparcv9-sun-solaris
51
thumbv6m-none-eabi
52
thumbv7em-none-eabi
53
thumbv7em-none-eabihf
54
thumbv7m-none-eabi
55
wasm32-unknown-emscripten
56
wasm32-unknown-unknown
57
x86_64-apple-darwin
58
x86_64-apple-ios
59
x86_64-fuchsia
60
x86_64-linux-android
61
x86_64-pc-windows-gnu (installed)
62
x86_64-pc-windows-msvc
63
x86_64-rumprun-netbsd
64
x86_64-sun-solaris
65
x86_64-unknown-cloudabi
66
x86_64-unknown-freebsd
67
x86_64-unknown-linux-gnu (default)
68
x86_64-unknown-linux-gnux32
69
x86_64-unknown-linux-musl
70
x86_64-unknown-netbsd
71
x86_64-unknown-redox

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

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

Durch die Gestaltung von Rust ist der Code sehr aussagekraeftig.
1
fn main() {
2
    let mut _x: u8 = 255;
3
    _x += 1;
4
}
Kommt es bei der Ausfuehrung zum ueberlauf stuerzt das Programm ab.
1
thread 'main' panicked at 'attempt to add with overflow', src/main.rs:3:5

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

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

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

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

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

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

Ja, Rust ist gekommen um zu bleiben.

von Nano (Gast)


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 Silc P. (silch12)


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)


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)


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)


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)


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:

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)


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
1
Once you have a local instance of crates.io running at 
2
http://localhost:4200 by following the instructions in the 
3
"Working on the Backend" section, you can go to another Rust project 
4
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
1
Cargo is a tool that allows Rust packages to declare their various 
2
dependencies and ensure that you’ll always get a repeatable build.
3
4
To accomplish this goal, Cargo does four things:
5
    Introduces two metadata files with various bits of package information.
6
7
    Fetches and builds your package’s dependencies.
8
9
    Invokes rustc or another build tool with the correct parameters to
10
    build your package.
11
12
    Introduces conventions to make working with Rust packages easier.

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

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

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

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

https://doc.rust-lang.org/book/ch14-02-publishing-to-crates-io.html#removing-versions-from-cratesio-with-cargo-yank
1
Although you can’t remove previous versions of a crate, you can prevent 
2
any future projects from adding them as a new dependency. This is useful 
3
when a crate version is broken for one reason or another. 
4
In such situations, Cargo supports yanking a crate version.
5
6
Yanking a version prevents new projects from starting to depend on 
7
that version while allowing all existing projects that depend on it 
8
to continue to download and depend on that version.

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

von Gerd E. (robberknight)


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)


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)


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)


Lesenswert?

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

von S. R. (svenska)


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)


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)


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)


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)


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


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)


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)


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)


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)


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


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)


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


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)


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)


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)


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)


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)


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)


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)


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)


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)


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)


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


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


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


Lesenswert?

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

Nick

von zitter_ned_aso (Gast)


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)


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


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)


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)


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


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


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)


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)


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)


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)


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)


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)


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)


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)


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


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


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)


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


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)


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)


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


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)


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


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)


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)


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)


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


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)


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


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)


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)


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


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)


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)


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)


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


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


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)


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)


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)


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)


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
1
Cross-language LTO is a new feature in the Rust compiler 
2
that enables LLVM's link time optimization to be performed 
3
across a mixed C/C++/Rust codebase.

von Wer rustet der rostet (Gast)


Lesenswert?


von mh (Gast)


Lesenswert?

Wer rustet der rostet schrieb:
> 
https://www.golem.de/news/security-microsoft-baut-com-bibliothek-in-rust-1910-144358.html
1
... während eines Praktikums beim MSRC entstanden ...

Da hat Microsoft ja richtig Resourcen investiert.

von Vincent H. (vinci)


Lesenswert?

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.

von Dergute W. (derguteweka)


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)


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)


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)


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)


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)


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)


Lesenswert?


von Atemis H. (at0)


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


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)


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)


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)


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)


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


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)


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


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)


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)


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


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)


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)


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)


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)


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)


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


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)


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)


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)


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)


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)


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)


Lesenswert?

Das ist ja noch schlimmer.

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

von cppbert (Gast)


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)


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.

von Kaj (Gast)


Lesenswert?

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

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

von Dergute W. (derguteweka)


Lesenswert?

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

SCNR,
WK

von Yalu X. (yalu) (Moderator)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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

von ? DPA ? (Gast)


Lesenswert?

Zum jetzigen Zeitpunkt fände ich das eine sehr schlechte Idee. Jetzt 
kann man den Kernel endlich mal mit zwei unabhängigen Compilern bauen, 
und dann will man sich von rustc/llvm abhängig machen? Rustc, von dem es 
keine alternative Implementierung gibt, und wo statt einem anständigen 
Standard rustc die Referenz ist? Wenn sie das machen, müssen sie nachher 
jeden Mist, den sich die rustc Compiler Bastler ausdenken, mitmachen, 
ist denen das klar?

Ich hoffe, die kommen wenigstens nicht auf die Idee cargo zu 
verwenden...

von Yalu X. (yalu) (Moderator)


Lesenswert?

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

von Olaf (Gast)


Lesenswert?

> Also wenn ich so an viel verwendete oder aufstrebende
> Programmiersprachen denke, kommt mir Haskell nicht unbedingt als erstes
> in den Sinn. :)

Mir kommt da immer der frueher einmal pro Jahr wiederkehrende Artikel in 
der C't in Erinnerung wo sie uns darauf aufmerksam gemacht haben das 
Smalltalk kurz vor dem Durchbruch steht. :-D
Und dann gibt es noch immer die regelmaessig wiederkehrenden Artikel das 
man noch dringend Fortran und Cobol Programmierer sucht.

Olaf

von zitter_ned_aso (Gast)


Lesenswert?

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

Aber vielleicht wird Rust die Kernelentwickler doch noch enttäuschen und 
dann rausfliegen ;-)

Wenn aber C  langsam aber sicher durch Rust ersetzt wird, dann hat C++ 
gar keine Zukunft.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Schorschi (Gast)


Lesenswert?

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

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

von Bastler (Gast)


Lesenswert?

Yalu X. schrieb:
>>> - Haskell (für große Anwendungsprogramme)
>>
>> Also wenn ich so an viel verwendete oder aufstrebende
>> Programmiersprachen denke, kommt mir Haskell nicht unbedingt als erstes
>> in den Sinn. :)
>
> Deswegen steht es ja nur an dritter und letzter Stelle ;-)

Haskell ist eine tolle Sprache, keine Frage. Aber Haskell als solches 
wird sich (leider?) nicht in der Masse durchsetzen, da nicht 
"Massenkompatibel".

Wenn man sich die großen Plattformen/Sprachen der letzten Jahrzehnte 
anschaut fällt auf, dass es alles sehr "pragmatische" Sprachen sind, die 
erfolgreich waren, und nicht die "schönen" und "perfekten".

Man erinnere sich an Perl, schaue sich den Java-Hype und PHP-Hype an und 
auch Ruby. C# ist auch pragmatisch und (war) zusätzlich ein Politikum, 
aktuell wächst es auch wegen dotnet. Python hat einen Push durch den 
ganzen KI-Kram bekommen weil es vorher im "Wissenschafts-Computing" 
schon am wachsen war. Javascript/Typescript wächst auch kontinuierlich 
und wird/ist das neue PHP.

C/C++ hat etwas eine Sonderstellung, weil es unglaublich viel 
Legacy-Code in dieser Sprache gibt und selbst heute mehr und weniger nur 
ein "Luxus-Assembler" ist.

Beitrag #6338497 wurde von einem Moderator gelöscht.
Beitrag #6338509 wurde von einem Moderator gelöscht.
von Olaf (Gast)


Lesenswert?

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

Selten so gelacht. Seit etwa 20Jahren ist C im Embeddedbereich der 
Standard. Egal welche schicke neue Sprache du cool findest, du musst 
immer und als allererstes sehr gute C Kenntnisse haben weil du sonst 
nicht die Arbeiten der letzten 10Jahre in deiner Firma lesen, verstehen 
und wiederverwenden koenntest. Ueber jede neue Sprache kannst du 
nachdenken nachdem du C drauf hast und nicht umgekehrt.
Und das ist auch der Grund warum jede neue Sprache es so schwer hat. Und 
vergiss nicht, du arbeitest auch mit Kollegen zusammen die keine Lust 
auf deine neue Sprache haben, oder eine ganz andere Sprache cool finden, 
aber alle koennen auf jedenfall C.

Olaf

von Rolf M. (rmagnus)


Lesenswert?

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

Klar. Wie kurzlebig C ist, hat es in den letzten fast 50 Jahren ja 
bewiesen. :)
Ok, die "Modesprache" C++ ist erst 35 Jahre alt…

? DPA ? schrieb:
> Jetzt kann man den Kernel endlich mal mit zwei unabhängigen Compilern bauen,
> und dann will man sich von rustc/llvm abhängig machen?

Mir scheint, dass Linus solche Abhängigkeiten egal sind. Er hat ja auch 
hart daran gearbeitet, dass es möglichst schwer ist, den Kernel mit was 
anderem als gcc zu übersetzen.

von SoOderSo (Gast)


Lesenswert?

Man kann da sagen was man will. Man merkt C und C++ ihr Alter an und 
dass die Neuerungen in C++ einfach nicht die Überzeugungskraft und 
Eleganz einer neuen Programmiersprache haben, die basierend auf den 
Erfahrungen mit C++ ganz neu erdacht wurde.

Was manche nicht verstehen ist dass historisch bedingte Positionen nicht 
ewig bessere Konzepte am Durchbruch hindern können.
In solchen Fällen benötigt der Durchbruch der besseren Konzepte nur 
etwas mehr Zeit. Es ist aber nicht abzuwenden.

Es ist sogar denkbar dass auch andere Programmiersprachen entstehen die 
die Grundideen von Rust übernehmen und vielleicht wird eine Variante 
davon erfolgreicher. So oder so C++ ist wie auch Rust nicht für die 
Ewigkeit.

von SoOderSo (Gast)


Lesenswert?

Und eins muss man doch auch einsehen. Wenn man eine Programmiersprache 
viele Jahre lernen muss um sie wirklich zu beherrschen dann ist das ein 
Zeichen dafür das die Sprache aufgebläht ist.

Warum also 10 Jahre C++ Erfahrung anhäufen wenn man die selbe Kompetenz 
auch mit 1-2 Jahren Rust hätte?

So was ist höchstens im Interesse von Leuten die die Durststrecke 
bereits durchgemacht haben und nun von ihrer gefragten Position 
profitieren. Und es dauert ja bis die nächste Welle erfahrender C++ in 
10-15 Jahren ankommen :D
Im Grunde ist das bitter für die Wirtschaft die dadurch nur Zeit 
verliert.

von Jack V. (jackv)


Lesenswert?

SoOderSo schrieb:
> Man merkt C und C++ ihr Alter an und
> dass die Neuerungen in C++ einfach nicht die Überzeugungskraft und
> Eleganz einer neuen Programmiersprache haben, die basierend auf den
> Erfahrungen mit C++ ganz neu erdacht wurde.

Letztlich ist’s ja auch die Frage, was langfristig sinnvoller zu lernen 
ist: eine Sprache wie C++, die es nunmal schon einige Dekaden gibt, und 
die man daher als etabliert bezeichnen könnte, oder Rust, das 
möglicherweise den Weg der meisten „modernen“ Sprachen geht, und in 
wenigen Jahren von etwa „Oxide“ abgelöst wird, oder ganz an Bedeutung 
verloren hat?

von A. S. (Gast)


Lesenswert?

SoOderSo schrieb:
> benötigt der Durchbruch der besseren Konzepte nur etwas mehr Zeit. Es
> ist aber nicht abzuwenden.
>
> Es ist sogar denkbar dass auch andere Programmiersprachen entstehen die
> die Grundideen von Rust übernehmen und vielleicht wird eine Variante
> davon erfolgreicher.

Das war doch genau die Frage: schafft es Rust? Oder erst ein Nachfolger 
an St. Nimmerlein.

C++ ist doch eine lebendige Sprache, die wohl kaum das Problem hat, zu 
wenige Konzepte zu vereinigen.

von mh (Gast)


Lesenswert?

SoOderSo schrieb:
> Warum also 10 Jahre C++ Erfahrung anhäufen wenn man die selbe Kompetenz
> auch mit 1-2 Jahren Rust hätte?

Das ist ne ziemlich sinnlose Frage. Ich kann auch fragen: Warum also 10 
Jahre Rust Erfahrung anhäufen wenn man die selbe Kompetenz auch mit 1-2 
Jahren C++ hätte?

von Schorschi (Gast)


Lesenswert?

Ich denke schon, dass Rust mittlerweilen das Potenzial hat zu bleiben 
(vor allem, wenn man sich mal anschaut wer bereits Rust nutzt):
- Firefox (Servo, Quantum)
- Redox OS
- Stratis (file system für Fedora und RHEL)
- Dropbox (Magic Pocket)
- Microsoft Azure IoT Edge
- OpenDNS
- TOR
- Discord
- Google Fuchsia
...

von Jack V. (jackv)


Lesenswert?

Schorschi schrieb:
> vor allem, wenn man sich mal anschaut wer bereits Rust nutzt

Du kannst dir auch anschauen, wer bereits Java genutzt hat. In einigen 
Bereichen ist‘s schon wieder nahezu weg.

von Cyblord -. (cyblord)


Lesenswert?

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

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


Lesenswert?

Andererseits würde die Liste, wer alles C++ benutzt, locker den Thread 
sprengen. :-))

Aber es ist natürlich auch klar, dass ein „Neuankömmling“ es gegenüber 
den Etablierten immer erstmal schwer hat.

Letztlich wird es damit stehen und fallen, ob es auch in der Industrie 
„ankommt“, weil es in der Lage ist, in einem Projekt gegenüber C oder 
C++ wirklich Entwicklungszeit zu sparen.

von cppbert (Gast)


Lesenswert?

Jack V. schrieb:
> Du kannst dir auch anschauen, wer bereits Java genutzt hat. In einigen
> Bereichen ist‘s schon wieder nahezu weg.

klar das gibt es immer wieder und wird auch immer so bleiben

aber man darf Rust definitiv zugestehen das es positiven Einfluss auf 
die Branche ausübt (z.B. Herb Sutters Gedanken zum Ownershipping in für 
C++, die Ideen das auch in D rein zu bringen - was auch wieder einige 
Gedankenknoten für andere Sprachen lösen könnte) und in der System oder 
Hardware-nahen Programmierung gab es bisher gar keine alternativen zu 
C/C++ - dort wo auch die Java oder .Net/GCC-Sprachen-Entwickler wie 
Microsoft/Sun/etc. selbst nur kurzen und teilweise peinliche Vorstöße 
gewagt haben

allgemein sehe ich Rust als den dritten im Bunde zwischen C und C++ in 
der System/Embedded-Welt die sich gegenseitig sehr gut mit Ideen 
versorgen, für normale Applikationen fehlen einfach noch sehr viele 
Dinge die C++,C#,Java nach Jahren des Aufbaus einfach so aus dem Ärmel 
schütteln

und "nur" die eine oder andere Sprache zu lernen und hier 
Aufwand/Kosten/Nutzen abzuwägen ist eh nur Anfänger die keinen Bock 
haben :)

man sollte z.B. mindestens ein paar der "Großen" Sprachen wie z.B. 
C/C++/C#/Java und 1-2 Script-Sprache gut beherrschen

Rust krankt aber definitiv immer noch an der fehlenden ABI, dem 
First-Shot-Kompiler der vollständig aber einfach noch viel zu langsam 
ist weil er alles schön sequentiell durchkaut, zu viel IR-Code dem LLVM 
hinwirft und,und,und - Kompilierzeit ist gerade noch ein Thema das die 
"Sprache" schlecht wirken lässt - vergleichbar mit dem 
Hyper-Pfeilschnellem D dmd der dafür aber miesen Code erzeugt

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Na, was steht denn so im BLFS Book, wenn man rustc-1.42.0 bauen will:
>  Unfortunately, rust insists on installing source files for these below 
/opt/rustc/lib/src.
Unschoen, aber naja gut.

> On some systems, linking fails to include libffi unless this is used. The reason 
why this is needed is not clear.
Das sieht mir doch nach irgendeiner Unsauberkeit im Buildprocess aus. 
Tut das not?

> For a long time, the miri crate (an interpreter for the Midlevel Intermediate 
Representation) has failed to build on releases. It is optional, but the failure 
messages can persuade people that the whole build failed. However, although it is 
not built in the main compile, with rustc-1.35.0 it now gets compiled during the 
install, but it is broken in this version.

WTF? Wieso fliegt sowas nicht raus oder wird gefixt? Genau so sieht 
sh*tty Software aus.

> On some systems, cairo fails to link during the install because it cannot find 
libssh2. This seems to fix it, but again the reason why the problem occurs is not 
understood.
Siehe oben: Unsauberer Buildprocess.

Da kann die Sprache noch so toll sein, wenn der real existierende 
dampfende Haufen aus Rustcompiler, Paket-Kasper und llvm noch solche 
Gimmicks hat, bin ich eher nur so mittelfroh.

Gruss
WK

von S. R. (svenska)


Lesenswert?

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

von Kaj (Gast)


Lesenswert?

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

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


Lesenswert?

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

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

von mh (Gast)


Lesenswert?

Jörg W. schrieb:
> Kaj schrieb:
>> Das Rustbook/die StdLib ist die Spec.
>
> Hmm, aber irgendeine Syntax-Definition sehe ich da nicht (EBNF oder
> Syntaxdiagramme).

Die Semantik-Definition ist auch eher "dünn".

von cppbert (Gast)


Lesenswert?

kein Mensch sagt Rust ist gut weil die formale Spezifikation von Rust 
qualitativ so gut da steht oder das bauen aus den Quellen so super 
schnuckelig ist - es ist und bleibt ein Community Projekt das immer noch 
organisch wächst

das kann man nicht wirklich mit so einem stringenten Prozess wie bei der 
Go , Swift oder .Net Entwicklung vergleichen - es sind viel weniger 
Leute beteiligt und auch ist eine schnelle (ISO)Standardisierung nicht 
Prio 0 gewesen - erst mal schauen ob die Ideen wie z.B. Ownership so 
funktionieren und dann langsam wachsen lassen - die ersten paar 
Versionen der nicht Go/Swift usw. Kompiler waren auch nicht von Anfang 
an ein Gedicht

Klar ist das Gesamtkunstwerk aus Sprache+Kompiler relevant - aber dann 
kann man sich aber auch über die Leichtigkeit von Crosskompilieren mit 
Clang im Vergleich zu GCC oder Visual Studio aufregen :)

von ? DPA ? (Gast)


Lesenswert?

Momentan definiert effektiv der Compiler das Verhalten.

https://github.com/rust-lang/reference :

> This document is the primary reference for the Rust programming language.
>
> This document is not normative. It may include details that are specific to
> rustc itself, and should not be taken as a specification for the Rust
> language. We intend to produce such a document someday, but this is what we > 
have for now.

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


Lesenswert?

cppbert schrieb:
> auch ist eine schnelle (ISO)Standardisierung nicht Prio 0 gewesen

Naja, das war bei C ja auch ein Weg von fast 20 Jahren.

Dennoch, schau dir die BCPL-Referenz von 1967 an (Vorläufer von C, 
findest du auf Dennis Ritchie's Webseiten) und vergleich das mal mit 
dem, was Rust als "Definition" bietet.

Klar, wenn du dir dann den K&R ansiehst, enthält der auch einen deutlich 
größeren Textteil mit anwenderorientierter Prosa, aber eben dennoch die 
formale Beschreibung der Sprache ebenso. Bei Rust sehe ich nur die 
anwenderorientierte Prosa, keine formale Beschreibung.

von Olaf (Gast)


Lesenswert?

> Naja, das war bei C ja auch ein Weg von fast 20 Jahren.

C hatte im Embedded Bereich den Vorteil das es praktisch nur Assembler 
verdraengen musste und das war eher einfach. .-)

> Das war doch genau die Frage: schafft es Rust? Oder erst ein Nachfolger
> an St. Nimmerlein.

Frag das in 10Jahren nochmal!

> C++ ist doch eine lebendige Sprache, die wohl kaum das Problem hat, zu
> wenige Konzepte zu vereinigen.

Ja, aber ich hab den Eindruck als wenn es von grossen in der branche 
schon den Wunsch gibt einfachere Sprachen durchzusetzen damit man auch 
schlichtere (und billigere) Gemueter als Programmierer verwenden kann.

C++ ist sozusagen die taegliche Diplompruefung. :-D

Olaf

von Cyblord -. (cyblord)


Lesenswert?

Olaf schrieb:
> Ja, aber ich hab den Eindruck als wenn es von grossen in der branche
> schon den Wunsch gibt einfachere Sprachen durchzusetzen damit man auch
> schlichtere (und billigere) Gemueter als Programmierer verwenden kann.

Wenn das so einfach wäre, würden heute alle Programme in Logo von der 
Putzfrau erstellt werden.

Die Komplexität in der SW Entwicklung entsteht nicht durch die 
Programmiersprache.

von cppbert (Gast)


Lesenswert?

Jörg W. schrieb:
> Dennoch, schau dir die BCPL-Referenz von 1967 an (Vorläufer von C,
> findest du auf Dennis Ritchie's Webseiten) und vergleich das mal mit
> dem, was Rust als "Definition" bietet.

Es gibt immer Entwickler die mehr Wert darauf legen von Anfang an gut 
definiert zu sein - aber das ist einfach kein Qualitätsmerkmal der 
Sprache, es muss irgendwann perfekt da stehen - aber jetzt gerade glaube 
ich ist das noch nicht so relevant

Problem ist eben: Es muss besser als C/C++, schneller und sauberer 
spezifiziert sein - sonst lohnt es sich schon mal nicht drauf zu schauen 
- mit dem Argument kann man alles bremsen :)

von Cyblord -. (cyblord)


Lesenswert?

cppbert schrieb:
> aber das ist einfach kein Qualitätsmerkmal der
> Sprache, es muss irgendwann perfekt da stehen - aber jetzt gerade glaube
> ich ist das noch nicht so relevant

Läuft das dann unter dem Schlagwort "liquid Syntax"? Mal ernsthaft, das 
wirkt alles wie Hipster Kram aber nicht wie ein ernsthafter Versuch 
etablierte Industriestandards zu ersetzen.

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> Die Komplexität in der SW Entwicklung entsteht nicht durch die
> Programmiersprache.

nicht "NUR" durch die Programmiersprache wäre passender - aber man kann 
Komplexitätsreduktion damit begünstigen

aber es gibt ja auch genug Leute die sagen: durch den Kompiler 
forciertes Owning ist das selbe wie Smart-Pointers in C++ - weil der 
Faktor Mensch (Stress, Desinteresse, man findet keine besseren 
Entwickler usw. - nicht relevant sein kann(darf?))

und bei den großen Projekten mit >10Mio Zeilen Code und hunderten von 
Entwicklern ist einfach jede Verbesserung spürbar

von mh (Gast)


Lesenswert?

cppbert schrieb:
> Jörg W. schrieb:
>> Dennoch, schau dir die BCPL-Referenz von 1967 an (Vorläufer von C,
>> findest du auf Dennis Ritchie's Webseiten) und vergleich das mal mit
>> dem, was Rust als "Definition" bietet.
>
> Es gibt immer Entwickler die mehr Wert darauf legen von Anfang an gut
> definiert zu sein - aber das ist einfach kein Qualitätsmerkmal der
> Sprache, es muss irgendwann perfekt da stehen - aber jetzt gerade glaube
> ich ist das noch nicht so relevant

Es wird sicher niemals perfekt sein, muss es auch nicht. Eine Sprache 
muss zwingend Work in Progress sein, um erfolgreich zu sein. Die Sprache 
nicht zu definieren ist das gleiche wie Software nicht zu Dokumentieren, 
"Technical Debt".

Der aktuelle Zustand der "Definition" ist ein Problem. Es kann ohne 
klare Definition keinen alternativen Compiler geben, ohne dass es 
schnell zwei unterschiedliche Sprachen gibt.

Der Einstieg in die Sprache und vor allem der Einstige in die 
Entwicklung der Sprache wird nach und nach immer schwerer. Wenn man den 
Compiler lesen und verstehen muss, um konstruktiv an der Sprache zu 
arbeiten, läuft etwas schief.

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> Läuft das dann unter dem Schlagwort "liquid Syntax"? Mal ernsthaft, das
> wirkt alles wie Hipster Kram aber nicht wie ein ernsthafter Versuch
> etablierte Industriestandards zu ersetzen.

die Revolution wurde von den großen der Branche x mal versucht - und sie 
sind alle gescheitert - daher jetzt einfach mal in kleinen Happen - wenn 
es nichts wird ist es auch nicht schlimm - aber bitte nicht immer alles 
auf die Goldwaage legen - dafür ist die Thematik einfach zu umfangreich 
(vom Style, der Ausdruckskraft bis runter auf die 
Code-Optimierungsebene)

Es ist nicht leicht, es gab viele Fehlversuche, es wird weiterhin Fehler 
geben, keiner Zwingt einem was auf, lernen tut nicht weh, Gründe findet 
man immer, wir haben nichts zu verlieren

von cppbert (Gast)


Lesenswert?

mh schrieb:
> Der aktuelle Zustand der "Definition" ist ein Problem. Es kann ohne
> klare Definition keinen alternativen Compiler geben, ohne dass es
> schnell zwei unterschiedliche Sprachen gibt.

100% ACK - aber wenn es dazu kommen sollte das alternative Kompiler 
erbaut werden (ich schaue auf euch Microsoft und google) werden sich die 
Leute zusammensetzen - die Zeiten von Inkompatible und Vendor Lock-in 
sind definitiv lange vorbei und werden von niemandem mehr akzeptiert - 
die Vermarktung wird zu schwer

von cppbert (Gast)


Lesenswert?

und klar rennen da draußen tausend Fanboys rum die schreien das Rust das 
geilsten ist was es gibt - die dürfen wir Profis natürlich mit aller 
Kraft ignorieren

von mh (Gast)


Lesenswert?

cppbert schrieb:
> Es ist nicht leicht, es gab viele Fehlversuche, es wird weiterhin Fehler
> geben, keiner Zwingt einem was auf, lernen tut nicht weh, Gründe findet
> man immer, wir haben nichts zu verlieren

Das sehe ich anders. Lernen kostet Zeit und Zeit ist endlich. Wenn ich 
etwas "falsches" lerne, tut mir das weh.

cppbert schrieb:
> 100% ACK - aber wenn es dazu kommen sollte das alternative Kompiler
> erbaut werden (ich schaue auf euch Microsoft und google) werden sich die
> Leute zusammensetzen - die Zeiten von Inkompatible und Vendor Lock-in
> sind definitiv lange vorbei und werden von niemandem mehr akzeptiert -
> die Vermarktung wird zu schwer
Auch das sehe ich deutlich anders. Wenn Microsoft oder Google eine 
Möglichkeit zum Vendor Lock-in sehen, werden sie es versuchen.

Neben böser Absicht, gibt es aber auch noch die Möglichkeit, dass sie 
eine ganz andere Vorstellung der Sprache haben, und diese mit einem 
alternativen Compiler umsetzen.

von Kaj (Gast)


Lesenswert?

Die Compilezeiten sind mir ziemlich egal, in Anbetracht des Mehr an 
Sicherheit das die Sprache bietet. Denn das ist alles Zeit, die ein 
Entwickler nicht in Fehlersuche/Bugfixes investieren muss.

Wem das compilieren zu lange dauert:
1
cargo check
2
3
check - Analyze the current package and report errors, but don't build object files

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

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

von A. S. (Gast)


Lesenswert?

cppbert schrieb:
> nicht "NUR" durch die Programmiersprache wäre passender - aber man kann
> Komplexitätsreduktion damit begünstigen

Die Sprache ist eher ein Pinsel für den Maler. Ja, manche sind besser 
als andere, je nach Aufgabe, vor allem bei Massenware. Aber letztendlich 
ist jede in der Praxis geschliffene Hochsprache (ab C) nur ein Werkzeug, 
gerade bei komplexen Projekten, wo die Sprache weit hinter dem inneren 
Aufbau der SW zurücktritt.

Olaf schrieb:
> C hatte im Embedded Bereich den Vorteil das es praktisch nur Assembler
> verdraengen musste und das war eher einfach. .-)

Das würde ich nicht sagen. Es ist halt nur C übrig geblieben, aber 
Forth, Ada, Pascal, Basic und vermutlich hunderte weitere waren da 
ebenso im Rennen.

von cppbert (Gast)


Lesenswert?

> Das sehe ich anders. Lernen kostet Zeit und Zeit ist endlich. Wenn ich
> etwas "falsches" lerne, tut mir das weh.

klingt dramatisch: wie oft hast du denn schon falsches gelernt?

und warum hattest du die Sorge bei C/C++ nicht
oder hast du dir damals dann nur Pascal angeschaut

> Auch das sehe ich deutlich anders. Wenn Microsoft oder Google eine
> Möglichkeit zum Vendor Lock-in sehen, werden sie es versuchen.
>
> Neben böser Absicht, gibt es aber auch noch die Möglichkeit, dass sie
> eine ganz andere Vorstellung der Sprache haben, und diese mit einem
> alternativen Compiler umsetzen.

das ist einfach quatsch - nicht ein Standard hält eine Sprache stabil 
und frei von monitären/macht Einflüssen sondern einen starke 
Entwicklergemeinde die sich dagegen wehrt - und google/Microsoft habe 
trotz ihrer Größe z.B. nicht mehr die Kraft sowas wie ein LLVM Projekte 
alleine zu stemmen - die Zeiten sind vorbei

Microsoft und google sind auch sehr stark im C++ Konsortium drin - d.h. 
die treffen da auch schon viele Entscheidungen mit - was ist der 
Unterschied?

von cppbert (Gast)


Lesenswert?

Kaj schrieb:
> Die Compilezeiten sind mir ziemlich egal

...solange du nicht was größeres machst wo es nervig wird - es gibt 
keine
Programmiersprache bei der das egal ist - es ist nur der Projektaufbau 
und die Projektgröße entscheidend

solche Aussagen haben dazu geführt das wir bei C++ seit Jahrzenten 
Modules ignoriert haben und wohl noch bis 2022 brauchen bis dieses Thema 
endlich anständig gelöst ist

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


Lesenswert?

A. S. schrieb:
> Es ist halt nur C übrig geblieben, aber Forth, Ada, Pascal, Basic und
> vermutlich hunderte weitere waren da ebenso im Rennen.

Für Embedded / Lowlevel OS?

FORTH schon, Ada kam erst eine Dekade später und gab sich wohl nie Mühe, 
außerhalb seines angedachten Anwenderkreises allgemein Fuß zu fassen.

Pascal und Basic rannten auf dieser Ebene nicht mit. Selbst wenn man 
Standard-Pascal mal beiseite lässt, ich habe gern und viel mit 
Turbo-Pascal unter CP/M gemacht, aber wenn's schnell gehen sollte, 
musste man schon auf den Inline-Assembler zurückgreifen. Im Gegensatz zu 
dem, was wir jetzt bspw. von GCC kennen, war das aber nur ein 
Objektcode-Einbetter, gar kein Assembler selbst: man musste den 
Objektcode extern mit einem Assembler erzeugen und konnte den 
Assemblercode höchstens noch als Kommentar reinschreiben.

von cppbert (Gast)


Lesenswert?

A. S. schrieb:
> Aber letztendlich
> ist jede in der Praxis geschliffene Hochsprache (ab C) nur ein Werkzeug,
> gerade bei komplexen Projekten, wo die Sprache weit hinter dem inneren
> Aufbau der SW zurücktritt.

d.h. es lohnt sich einfach nicht mehr die Ausruckskraft von Sprachen zu 
hinterfragen, zu erweitern, begrenzen?

von cppbert (Gast)


Lesenswert?

cppbert schrieb:
>> Die Compilezeiten sind mir ziemlich egal

Ich habe noch nie einen Entwickler sagen hören - "Es wäre schön wenn es 
länger kompiliern würde"

von Olaf (Gast)


Lesenswert?

> FORTH schon, Ada kam erst eine Dekade später und gab sich wohl nie Mühe,
> außerhalb seines angedachten Anwenderkreises allgemein Fuß zu fassen.

Das sehe ich aehnlich. Von Ada hab ich jedenfalls damals nichts gehoert.
Forth gab es hier und da, aber das hat nie mehr als 100Leute pro Land 
interessiert und die waren jeweils damit beschaeftigt einen eigenen 
Interpreter fuer ihre Lieblingshardaware zu schreiben. .-)

> Pascal und Basic rannten auf dieser Ebene nicht mit. Selbst wenn man

Pascal haette es schaffen koenne. Es gab auch Versuche das compilat von 
TurboPascal embedded zu nutzen. (c't, aber auch von anderen)

Aber letztlich fand der Uebergang damals schon von Assembler nach C 
statt.

Oh..und was mich an Rust (und go) auch gewaltig stoert ist das 
Buildsystem! Das ist mir zu dogmatisch. Ich hab sogar letztens noch eine 
neue Sprache angetestet wo die Compilerbauer darauf bestehen das man 
kein Tab im Quelltext hat. So schnell hab ich noch nie rm getippt.

Olaf

von A. S. (Gast)


Lesenswert?

cppbert schrieb:
> d.h. es lohnt sich einfach nicht mehr die Ausruckskraft von Sprachen zu
> hinterfragen, zu erweitern, begrenzen?

Doch. Das ist wichtig und gerade die Ausdruckskraft ist es, was m.E. die 
erfolgreichen von den anderen unterscheidet. Und für C++ gilt auch 
begrenzen sicherlich ;-)

von SoOderSo (Gast)


Lesenswert?

Olaf schrieb:
> Oh..und was mich an Rust (und go) auch gewaltig stoert ist das
> Buildsystem! Das ist mir zu dogmatisch. Ich hab sogar letztens noch eine
> neue Sprache angetestet wo die Compilerbauer darauf bestehen das man
> kein Tab im Quelltext hat. So schnell hab ich noch nie rm getippt.

Na offenbar bist du nicht weniger dogmatisch. Wieso bestehst du auf Tabs 
im Quelltext? :D

von Yalu X. (yalu) (Moderator)


Lesenswert?

Olaf schrieb:
> Oh..und was mich an Rust (und go) auch gewaltig stoert ist das
> Buildsystem!

Wenn du ein besseres kennst, steht es dir frei, dieses benutzen.

> Ich hab sogar letztens noch eine neue Sprache angetestet wo die
> Compilerbauer darauf bestehen das man kein Tab im Quelltext hat.

In Sprachen wie Nim, bei denen Blöcke per Einrückung definiert werden,
ist es aber auch mehr als sinnvoll, den Gebrauch von schwer voneinander
unterscheidbaren Whitespace-Zeichen zu verbieten.

> So schnell hab ich noch nie rm getippt.

Ja, das mache ich auch immer mit Tab-verseuchtem Quellcode ;-)

von Rolf M. (rmagnus)


Lesenswert?

Jörg W. schrieb:
> Letztlich wird es damit stehen und fallen, ob es auch in der Industrie
> „ankommt“, weil es in der Lage ist, in einem Projekt gegenüber C oder
> C++ wirklich Entwicklungszeit zu sparen.

Dazu gehört auch, dass man Experten hat/findet, die die Sprache 
beherrschen. Denn man wird eher nicht ein neues Entwicklungsprojekt in 
einer Sprache beginnen, die keiner der Mitarbeiter halbwegs beherrscht.

von Jemand (Gast)


Lesenswert?

Olaf schrieb:
> Oh..und was mich an Rust (und go) auch gewaltig stoert ist das
> Buildsystem! Das ist mir zu dogmatisch. Ich hab sogar letztens noch eine
> neue Sprache angetestet wo die Compilerbauer darauf bestehen das man
> kein Tab im Quelltext hat. So schnell hab ich noch nie rm getippt.

Dabei hat man sich extra für dich die Mühe gemacht
1
#![allow(bad_style)]
zu implementieren.

lol

von Rolf M. (rmagnus)


Lesenswert?

Olaf schrieb:
> Ich hab sogar letztens noch eine neue Sprache angetestet wo die Compilerbauer
> darauf bestehen das man kein Tab im Quelltext hat.

Na endlich mal eine sinnvolle Einschränkung in einer Sprache.

von Daniel -. (root)


Lesenswert?

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

von Bernd K. (prof7bit)


Lesenswert?

Olaf schrieb:
> Ueber jede neue Sprache kannst du
> nachdenken nachdem du C drauf hast und nicht umgekehrt.

Bei Rust und erst recht bei Haskell ist es exakt umgekehrt: C-Denkweise 
ist extrem hinderlich. Anders rum wärs wesentlich einfacher und weniger 
schmerzhaft.

von SoOderSo (Gast)


Lesenswert?

Ist das nur mein Eindruck oder relativieren viele C++ Entwickler 
wirklich die C++ Neuerungen die Rust ähnliche Features bringen?

Einerseits wird mit der Weiterentwicklung von C++ argumentiert dass Rust 
nicht  notwendig sei. Anderseits sehe ich aber eine massive 
Relativierung und mangelnde Akzeptanz der C++ Neuerungen.

So heißt es manchmal dass hohe Speichersicherheit mit den neuen Mitteln 
nur für spezielle Fälle gut sei und man es jetzt nicht in der 
alltäglichen Programmierungen benötige.
Man muss also erst für Militär oder Banken entwickeln damit das von 
Bedeutung wird? Der Rest soll halt weiter leiden mit den Folgen 
mangelnder Speichersicherheit und weiter Zeit und Geld dafür verlieren.

Was man bei C++ also gerne relativiert und nur für spezielle 
Anforderungen abschiebt, um es nicht lernen und benutzen zu müssen, ist 
bei Rust der Standard.

von mh (Gast)


Lesenswert?

SoOderSo schrieb:
> Ist das nur mein Eindruck oder relativieren viele C++ Entwickler
> wirklich die C++ Neuerungen die Rust ähnliche Features bringen?

Das ist nicht mein Eindruck. In meinem Umfeld werden alle Neuerungen 
getestet und bewertet. Wenn das Kosten-Nutzen-Verhältnises für einen 
Anwendumgsfall stimmt, wird es genutzt.

Auf welche konkrete Features beziehst du dich denn?

von W.Gates (Gast)


Lesenswert?

Bevor nicht die Platzhirsche Rust adoptieren und kommerzialisieren, 
werden die meisten Firmen sich mit dem Feind herumzuschlagen mit dem sie 
schon lange Erfahrungen haben. Abgesehen davon hat sich bis jetzt Rust 
nur im IT Markt(Google, Mozilla...) behauptet und nicht so viel im 
embedded Bereich.

Was der Bauer nicht kennt frisst er nicht. Da wird sich Rust noch lange 
schwer tun. Auch ist die Terminologie bei Rust etwas zu esoterisch um 
bei Vielen anzukommen. Irgendwie passt z.B. "Crate" u.v.a. nicht in den 
Jargon etablierter Entwicklung.

C/C++ mag seine Fußangeln zu Recht haben. Wer aber plant, bedacht und 
diszipliniert seine Anwendungen durchsetzt wird auch damit zuverlässige 
Anwendungen erstellen können. C/C++ kommt irgendwie logischer als Rust 
an. Der ganze Syntax um Rust herum ist abenteuerlich. Unter der Haube 
mag es ja vielleicht gut sein. Bis man aber dazu wirklich Vertrauen 
gewinnen kann, wird noch viel Wasser die Flüsse herunter fließen müssen. 
C/C++ hat im embedded Bereich einfach einen viel Hardware-näheren Ton 
und fühlt sich wie dafür gemacht an. Bei Rust ist da ein viel breiterer 
Abgrund.

Die wahrscheinlichste Prognostik: Trotz aller Hoffnung und Erwartungen 
wird es genauso wie so viele andere Sprachen zuvor lange ein Nischen 
Dasein führen und seinen Fan Club haben. Die Industrie wird aber noch 
lange Zeit mit C/C++ weiter entwickeln weil dabei zu bleiben letzten 
Endes doch Geld spart. Es ist eben so: Der Mensch verhält sich eben wie 
Masse bei zunehmender Lichtgeschwindigkeit - Das Beharrungsverhalten 
steigt bei vielen Leuten um so mehr an je mehr man auf den Gashebel 
steigt.

von Kaj (Gast)


Lesenswert?

Kompression: Dropbox macht Brotli zu Broccoli
https://www.golem.de/news/kompression-dropbox-macht-brotli-zu-broccoli-2008-150075.html
1
Der in Rust geschriebene Code der zugrundeliegenden Bibliothek
2
von Broccoli steht auf Github zur Verfügung.
https://github.com/dropbox/rust-brotli#rust-brotli

von Mach (Gast)


Lesenswert?

Jörg W. schrieb:
> Pascal und Basic rannten auf dieser Ebene nicht mit.

Vielleicht wirds ja mit Object-Pascal noch was. Der FreePascal-Compiler 
unterstuetzt mittlerweile
AVR, ARM, RISCV und Tensilica (ESP32).

von DerChris (Gast)


Lesenswert?

W.Gates schrieb:
> Das Beharrungsverhalten
> steigt bei vielen Leuten um so mehr an je mehr man auf den Gashebel
> steigt.

Es sei mal dahingestellt ob das stimmt, aber beim Thema 
Programmiersprachen ist das überhaupt nicht der Punkt. Das ist als wenn 
man streiten würde welcher Kugelschreiber der Beste ist. Vielleicht 
schreibt einer ein bisschen besser als der andere, aber wer schreiben 
kann, kann mit jedem Kugelschreiber schreiben.

von mh (Gast)


Lesenswert?

DerChris schrieb:
> Das ist als wenn
> man streiten würde welcher Kugelschreiber der Beste ist. Vielleicht
> schreibt einer ein bisschen besser als der andere, aber wer schreiben
> kann, kann mit jedem Kugelschreiber schreiben.

Du hast vermutlich noch keine längeren Texte mit einem richtig guten 
Kugelschreiber geschrieben. Der Unterschied ist riesig.

von Nick M. (Gast)


Lesenswert?

mh schrieb:
> Du hast vermutlich noch keine längeren Texte mit einem richtig guten
> Kugelschreiber geschrieben. Der Unterschied ist riesig.

Füller!

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

Zur Hilfe bei der Entscheidungsfindung für den TE habe ich auch noch 
eine oder zwei Anmerkungen.

Eine Programmiersprache ist doch kein Freund(oder Freundin). "Jetzt hab 
ich einen Anderen gefunden und mache mit dem Alten schluss..."
Es hält dich nichts davon ab deine alte Liebe c99 oder c11 weiterhin zu 
benutzen. Es ist nur ein Werkzeug, wie eine neue Zange, die besser 
geeignet ist um rechtwinklig zu biegen. Deswegen werfen wir doch nicht 
die alte Rundbiegezange weg! Ihr seht, ich kann genau so schreckliche 
vergleichende Beispiele wie meine Vorschreiber machen, hoffe aber die 
Intention, der Toolcharakter einer Sprache verdeutlicht zu haben:P

Erfahrungsbericht: Ich(ganz jung:P) besitze eine VU+ Settop Box. Das 
Build-Ökosystem dazu benötigt ein spezifisches Linux System 
(Entwicklungsbedingt alt, Stabilität!) das mit OpenEmbedded dann für das 
Zielsystem (eine mipsel32, auch rustikal) ein Linux System mit der 
nötigen Paketverwaltung(wie zu erwarten, nicht das modernste, Linux: 
vuduo2 3.13.5) generiert. Ein kompletter Erstellungsvorgang kann schon 
einen halben Tag dauern und mehr als 20GB an Speicherplatz in Anspruch 
nehmen. Will ich mir auf die schnelle also einen IoT oder 
Mosquitto-Server zusammen schustern oder ein C/C++ basiertes selbst 
geschriebenes Tool erstellen braucht das also einen Rattenschwanz von 
Abhängigkeiten und jede Menge Ressourcen. Das ist völlig okay. Rust oder 
Go sind aber genau für solche Aufgaben prädestiniert. Also dachte ich, 
probier es mal aus.
MIPSel ist natürlich etwas exotisch und wie zu Erwarten kam es zu 
Problemen. Nach 2 Tagen und ca. einer Woche Rust Erfahrung habe ich dann 
aktiv an der Verbesserung des OpenSSL Paketes teilgenommen. Dank der 
wunderbaren Community ging das recht flott und ohne Probleme. Gelernt 
habe ich dabei auch jede Menge. Mit relativ wenig Overhead(natürlich den 
Rust Compiler plus das zitierte LLVM-Backend für die Cross-Compilation) 
kann ich nun auf die Schnelle ein kleines Tool oder Server als 
Minimalbeispiel aufsetzen und darauf aufbauend entwickeln.

Verschiedenes:
Etwas Neues und ein frischer Wind sind eigentlich immer gut. In der 
(Computer-)Technik sollte man Innovation begrüßen, da sie Verbesserungen 
mit sich bringt und die Ängste, die man z.B. der Politik oder der 
Veränderung als solcher gegenüber bringt hinten anstellen. Rust ist 
gewöhnungsbedürftig. So wie auch das Konzept, das Speicheroperationen 
sicherer machen will. Das Rust Buch, 
https://doc.rust-lang.org/book/index.html bietet einen exzellenten 
Einstieg in die Materie und führt in moderne(für manche natürlich ein 
alter Hut) Konzepte wie Pattern Matching auf Control-Flow Basis oder 
Closures ein. Die Community ist flexibel und freundlich und hat 
mannigfaltige Interessen von System zu GUI-Programmierung über Embedded 
bis hin zur OS Entwicklung. Ich widerspreche hier entschieden meinem 
Vorgänger W.Gates, der meint bestimmen zu wollen, wie die Eltern ihr 
Kind benennen sollen. Das ist völlig nebensächlich und Trivia, ob etwas 
Crate heißt(wenn der Paketmanager sich Cargo schimpft. Haha, Wortspiel, 
ich lache...) und wenn dir der Scheiß mal auf die Füße fällt vergisst Du 
es nie wieder!!! (Dank mir und dieser Ausführung womöglich auch nicht 
mehr ...:P).
> Der Mensch verhält sich eben wie Masse bei zunehmender Lichtgeschwindigkeit - 
Das Beharrungsverhalten steigt bei vielen Leuten um so mehr an je mehr man auf den 
Gashebel steigt.
Das mag für jemanden gelten, der sich als Konservativ herausstellen 
will, nicht verstanden hat, dass die Lichtgeschwindigkeit konstant ist 
und sein eigenes Unvermögen zur Veränderung beschreibt(manchmal auch 
Faulheit oder fehlender Spieltrieb genannt:P). Alles Spitzfindigkeiten. 
Ich empfehle das ganze einfach selbst mal auszuprobieren. Die 
Installation ist denkbar einfach und das tooling gut. 
https://www.rust-lang.org/tools/install

Embedded:
Wer will kann sofort loslegen bei *Are we embedded yet?*: 
https://afonso360.github.io/rust-embedded/ Die Unterstützung ist einfach 
nur massiv und innovativ.
Nochmal Crate: Eine Paketverwaltung kann auch schlecht sein. Bei kleinen 
Projekten, z.B. induziert sie mögliche Fehlerquellen und Unbekannte in 
den Erstellungsprozess, die besser durch Fachkenntnis und manuelle 
Verwaltung der (überschaubaren) Abhängigkeiten gelöst werden sollten. 
Das Endprodukt wird dabei stabiler, erfordert aber einen höheren Aufwand 
bei der Pflege. Als abschreckendes Beispiel nenne ich mal node.js und 
der Rattenschwanz an Unsinnigkeiten plus Sicherheitsrisiken.

C/C++
Wir sollten dankbar sein. Ich sage jedenfalls nicht nein zu Tools wie 
clang-tidy und clang-format. Diese kommen nicht aus dem Luftleeren Raum. 
Die neuen Sprachen wie Rust bringen unter anderem ein ganzes Ökosystem 
wie rust-fmt, Dokumentation-Erstellung out of the box, benchmarking, 
fuzzing, testing, etc. mit sich. Das färbt auf die gute alte Mutter ab 
und ich finde das nicht schlecht.
Als Hausaufgabe: Mal bei 
https://en.cppreference.com/w/cpp/compiler_support vorbei schauen und in 
sich gehen. Neuerungen und Verbesserungen sind ein Ding der Realität und 
des Fortschritts.

OCaml
Wer will kann C direkt mit OCaml verknüpfen, in Rust. 
https://caml.inria.fr/pub/docs/manual-ocaml/intfc.html + 
https://docs.rs/ocaml/0.14.2/ocaml/.
Kein Grund also hier irgend eine gegen die andere ausspielen zu wollen:) 
Wenn gewollt ist Koexistenz durchaus möglich.

Mozilla
Ich bin gespannt ob und wie die Entlassungen Auswirkungen auf die 
Entwicklung von Rust haben. 
https://www.drwindows.de/news/mozilla-kuendigt-zahlreiche-entlassungen-und-grosse-reorganisation-an 
+ https://blog.fefe.de/?ts=a1cd056a

Fazit:
Frischer Wind. Das Ausprobieren kostet nichts (außer Zeit und Nerven). 
Wer damit in Produktion gehen will kann das. Wer damit auf 
Entdeckungsreise gehen will kann das auch mit "rustup toolchain install 
nightly".

Viel Spaß beim Entdecken:)

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

Ich wollte mir das eigentlich verkneifen, aber.....

PLATZHIRSCHE?
... also Angeberei, Herdentrieb, Relevanz, etc.

https://stackshare.io/rust
https://www.rust-lang.org/production
https://stackoverflow.blog/2020/01/20/what-is-rust-and-why-is-it-so-popular/

Entschuldigung. Das ist natürlich für manche ein wichtiges Thema und 
völlig berechtigt nach der Relevanz und Verwendung zu fragen.

von Nick M. (Gast)


Lesenswert?

Ich hab mal spasseshalber "rust" in die Suche bei Microchip eingegeben.
0 Treffer. Das kennen die nicht.

https://github.com/rust-embedded/wg/issues/308
Sieht auch nicht wirklich vielversprechend aus.

Und die Suchmaschine meiner Wahl liefert nicht sehr viel mit "rust 
pic32".

OK, ich hab halbherzig gesucht. Aber wenn rust so toll ist und alle 
drauf abfahren (ausser mir), sollte man doch ordentlich und schnell was 
finden.

Beitrag #6373524 wurde von einem Moderator gelöscht.
von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

Genau so wenig wie Microchip GCC (ausser ihr closed source gemurkse) 
kennt. Das ist wieder ein Teilstück vom Großen und Ganzen wo es mir 
jetzt wirklich schwer fällt die Schuld bei den Entwicklern von Rust zu 
sehen.

Du kannst ja sofort damit anfangen einen hmmm, sagen wir 
Transpiler(damit es nicht so unmöglich erscheint) von Rust nach 
Embedded-C für PIC8/24/32 zu schreiben. Es hindert dich niemand daran. 
Genau so wenig wie dich jemand zwingt es zu benutzen. Es ist eine neue 
Sprache und vieles steckt in den Kinderschuhen. Euphorie und im 
Gegensatz Berührungsangst sind meiner Meinung nach fehl am Platz. 
Einfach mal ausprobieren. Das beisst nicht:)

Fun fact: "Spaghetti" als Suchbegriff kennt man bei Microchip nur im 
"Chameleon 16-Bit User Guide", lol.

Also einfach gesagt: Nick, ist das nicht ein bisschen unverschämt eine 
PIC Unterstützung zu verlangen? Ich mein jetzt egal von wem. Noch nicht 
mal dem Weihnachtsmann würde ich das zumuten. Microchip hällt ihren 
Stall geschlossen, also liegt das auch alleine bei ihnen etwas zu 
liefern. An wen auch immer. Und wirklich ? Bei 52 Repositories auf 
https://github.com/rust-embedded/ fällt dir das dazu ein? Das ist ein 
Scherz, oder?

von Nick M. (Gast)


Lesenswert?

Jedzia D. schrieb:
> Genau so wenig wie Microchip GCC (ausser ihr closed source gemurkse)
> kennt.

Wie? Der Compiler ist GCC. Und es gibt den source. Und man kann sich die 
Pro-Version selbst compilieren. Ist aber auch völlig egal und hat 
absolut nichts mit rust zu tun.

Jedzia D. schrieb:
> Also einfach gesagt: Nick, ist das nicht ein bisschen unverschämt eine
> PIC Unterstützung zu verlangen?

Ach so. Entschuldigung! Ich dachte rust ist so toll, dass es alle 
verwenden sollten. OK, warum macht das dann nicht Microchip? Das wurde 
ihnen doch sicherlich schon 100te Male vorgetragen. Sollen sie paar 
Leute abstellen, die das portieren/anpassen. Genug Geld verdienen die 
schon um sich die paar Hanseln leisten zu können.

Ganz abgesehen davon, dass dein Vorwurf ich sei unverschämt völlig 
verblödet ist. Aber möglicherweise muss man zur Elite gehören, um rust 
überhaupt mal erwähnen zu dürfen.

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

Ich meinte die Unverschämtheit etwas zu Erwarten, was über das Ziel 
hinaus schießt. Das ist völlig okay.
Ich meinte nicht die Unverschämtheit deine Mitmenschen als blöde zu 
bezeichnen, das ist nicht okay. Es war mir weder persönlich noch 
besonders tot ernst wichtig. Ich selber sehe viele Mängel und Probleme 
bei Rust, benutze lieber Clang und GCC und bin weit davon weg ein 
fangirl zu sein.

Elite? Ist das eine Beleidigung? ... Tut das was zur Sache?
Noch mal zum Mitschreiben: Ich fand deine Argumente schlecht und 
ungerecht. Nicht dich als Person. Peace!

von DPA (Gast)


Lesenswert?

Jetzt lasst euch doch nicht so einfach provozieren...

Vielleicht sollte man den thread hier sowieso mal Archivieren, ist ja 
schon über ein Jahr alt, und was grossartig geändert hat sich bei der 
Thematik in der zwischenzeit ja auch nicht wirklich was...

von Nick M. (Gast)


Lesenswert?

Jedzia D. schrieb:
> Ich meinte nicht die Unverschämtheit deine Mitmenschen als blöde zu
> bezeichnen, das ist nicht okay.

Wo hab ich denn das gemacht?

Jedzia D. schrieb:
> Elite? Ist das eine Beleidigung? ... Tut das was zur Sache?

Bei deiner Leerargumentation hab ich so den Eindruck, dass man Mitglied 
einer auserwählten Filterblase sein muss um rust verwenden zu dürfen.

Gut ich hab schon mehrfach beobachtet, dass Leute darauf stolz sind 
etwas völlig unsinniges zu können. Z.B. elektrische Tretroller fahren zu 
können. Oder auf dem Handy zu tippen und über die Straße gehen zu 
können. Oder kein Wort C zu können, eine embedded Lösung entwickeln die 
billiger sein soll und dann vor den 3-fachen Kosten zu stehen und in 
einer Sackgasse zu stehen ohne Wendemöglichkeit.
Also warum sollte ich ein Projekt das kein privates Gebastle ist, mich 
auf etwas einlassen, das von "meinem" µC nicht unterstützt wird?

von S. R. (svenska)


Lesenswert?

Jedzia D. schrieb:
> Das mag für jemanden gelten, der sich als Konservativ
> herausstellen will, nicht verstanden hat, dass die
> Lichtgeschwindigkeit konstant ist und sein eigenes
> Unvermögen zur Veränderung beschreibt(manchmal auch
> Faulheit oder fehlender Spieltrieb genannt:P).

Die Kosten, ein Tool zu erlernen, ist hoch. Die Kosten, ein weiteres 
Tool von Grund auf zu erlernen, ist ebenfalls hoch. Wer neu anfängt, für 
den ist das kein Problem, denn alles ist "neu" und "interessant" und 
"cool".

Wer das alles schon ein-zwei-drei mal durch hat, der hat (a) diese 
Kosten schon bezahlt; (b) hat erstmal sehr negatives 
Return-On-Investment; (c) reduziert seine vorhandenen Fähigkeit (wer 
eine Fremdsprache lange nicht spricht, wird erstmal objektiv 
schlechter). Ob das nun die "sunk-cost-fallacy" ist oder schlicht 
(privat)wirtschaftliches Denken, lasse ich mal offen.

Spieltrieb kann sich auf verschiedene Dinge beziehen. Das können neue, 
coole Programmiersprachen sein oder neue, coole Algorithmen oder neue, 
coole Probleme. Du dampfst das auf Programmiersprachen ein.

Mit 15 oder 25 sieht man die Welt anders als mit 35 oder 45.

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

Da hast Du recht @svenska.

Mein kontra war das eine Ende des Spektrums. Wahrscheinlich ist es aber 
am besten die Goldene Mitte zu favorisieren, also eine gute Mischung 
zwischen gewohnter Stabilität und klug gewählter Neuerungen. Damit das 
System auch in Zukunft überlebensfähig und attraktiv bleibt.

von mh (Gast)


Lesenswert?

Jedzia D. schrieb:
> Du kannst ja sofort damit anfangen einen hmmm, sagen wir
> Transpiler(damit es nicht so unmöglich erscheint) von Rust nach
> Embedded-C für PIC8/24/32 zu schreiben.

Klar ... wo kann ich nochmal nachlesen, wie die Sprache definiert ist?

von Vincent H. (vinci)


Lesenswert?

Gibts nicht eh ein MIPS Backend für LLVM?

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?


von Vincent H. (vinci)


Lesenswert?


von Dergute W. (derguteweka)


Lesenswert?

Moin,

Jedzia D. schrieb:
> Es ist nur ein Werkzeug, wie eine neue Zange, die besser
> geeignet ist um rechtwinklig zu biegen.

Von mir aus. Aber an der real existierenden Rust-Zange haengen halt 
unmittelbar und untrennbar immer auch noch eine Kuh(llvm) und ein 
Fahrrad(cargo). Und es muss genau die richtige Kuh und das richtige 
Fahrrad sein, sonst funktioniert die Rust-Zange nicht.
Die Versionen von binutils, gmp, mpfr, mpc, kernel, glibc, gegen die 
eine gcc-Zange gebaut werden kann, sind viel unkritischer. Da muessen 
immer nur irgendwelche mindest/maximal-Versionsnummern passen; einen 
bare-metal-gcc kann man sogar voellig ohne kernel und glibc 
zusammenbauen. Aeltere gcc brauchen nicht mal gmp,mpfr,mpc.
Deutlich flexibler, wenn man nicht zu den sudo-apt-get-install-Aeffchen 
gehoert.

Jedzia D. schrieb:
> Ich(ganz jung:P) besitze eine VU+ Settop Box. Das
> Build-Ökosystem dazu benötigt ein spezifisches Linux System
> (Entwicklungsbedingt alt, Stabilität!) das mit OpenEmbedded dann für das
> Zielsystem (eine mipsel32, auch rustikal) ein Linux System mit der
> nötigen Paketverwaltung(wie zu erwarten, nicht das modernste, Linux:
> vuduo2 3.13.5) generiert. Ein kompletter Erstellungsvorgang kann schon
> einen halben Tag dauern und mehr als 20GB an Speicherplatz in Anspruch
> nehmen. Will ich mir auf die schnelle also einen IoT oder
> Mosquitto-Server zusammen schustern oder ein C/C++ basiertes selbst
> geschriebenes Tool erstellen braucht das also einen Rattenschwanz von
> Abhängigkeiten und jede Menge Ressourcen. Das ist völlig okay.

Nein das ist nicht okay, das ist voellige Kacke!
Auch bei einem embedded linux sollte sich auf die Schnelle eine kleine 
Aenderung am Image machen lassen, ohne dass jedesmal wieder voellig bei 
0 angefangen wird. Da erwarte ich, dass ich irgendwo eine Filestruktur 
rumfliegen habe, aus der das Flash-Image erstellt wird und da will ich 
auch gerne mal z.b. nur ein a.out, was ich per $CROSS-gcc aus einem 
hello.c kompiliert habe, einfach reinkopieren koennen und mir danach 
draus z.b. per mksquashfs oder sonstwie ein neues Image bauen koennen, 
ohne dass jedesmal der ganze Hoellenapparat aus wilden scripten, etc. 
anspringt, um allen moeglichen und unmoeglichen Scheiss neu zu bauen.

Mir ist ein Ansatz wie z.b. das BLFS Book bedeutend lieber, als diese 
ganzen 
"Drueck-hier-auf-den-Knopf,dann-faellt-da-das-komplette-Image-aus"-embed 
dedLinux-Baukaesten.  Egal ob yocto, buildroot und was es sonst noch 
gibt: Wenn da nur ein Furz anders ist, als von den Erbauern des 
script-wusts vorgesehen, geht viel zu schnell garnix mehr.

Jedzia D. schrieb:
> Etwas Neues und ein frischer Wind sind eigentlich immer gut. In der
> (Computer-)Technik sollte man Innovation begrüßen, da sie Verbesserungen
> mit sich bringt und die Ängste, die man z.B. der Politik oder der
> Veränderung als solcher gegenüber bringt hinten anstellen.

Nein, Neues und frischer Wind ist immer erstmal nur neu. Obs auch gut 
ist, muss man erstmal schauen. Es ist nicht automatisch gut, nur weil's 
neu ist.
Aengste vor Veraenderungen sind manchmal durchaus auch berechtigt.
Nur kleine Kinder denken: Uii, eine neue Herdplatte, da muss ich gleich 
mal mit dem Patschehaendchen drauffassen. Aeltere sind da etwas 
zoegerlich, obwohl neue Herdplatten per se nichts schlechtes sein 
muessen.


Ok, ich weiss nicht, was mit C passiert waere, wenn die Bell Labs damals 
auch "ein paar Leute" rausgeschmissen haetten, so wie das jetzt 
anscheinend bei Rust und Mozilla der Fall ist. Na, wir werden es 
sehen...

Gruss
WK

von Daniel A. (daniel-a)


Lesenswert?

Ich habe Heute im Internet ein Problem mit Rust gefunden, dass ich 
bisher noch nicht kannte: Das Bauen von Programmen kann sehr 
Resourcenintensiv sein:

https://source.puri.sm/Librem5/squeekboard/-/issues/243#note_124514
> for reference: I had the kernel OOM kill the squeekboard build on a 4GB
> laptop recently. The  build takes longer than a kernel build with hot
> ccache and needs as much disk space as the kernels git history of 2.9G.

Ich frag mich, ob das wohl ein grundlegendes Architekturproblem von Rust 
ist, oder ob das irgendwann noch besser wird...

von Yalu X. (yalu) (Moderator)


Lesenswert?

Mit nur 4 GB Hauptspeicher stößt auch template-lastiges C++ schnell an
die Grenzen. Ein Hardcore-Programmierer, der von C++ auf Rust umsteigt,
wird von dem Problem nichts merken, weil er sowieso schon 32 GB hat ;-)

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Yalu X. schrieb:
> Mit nur 4 GB Hauptspeicher stößt auch template-lastiges C++ schnell an
> die Grenzen.

Das ist aber leider nur ein schwacher Trost. So aehnlich, wie wenn der 
Schmerz, wenn man sich mit dem Hammer auf den Finger haut, nicht so 
schlimm ist, denn wenn einem dabei noch eine Dampfwalze ueber den Fuss 
faehrt, waere es noch schlimmer.

Daniel A. schrieb:
> oder ob das irgendwann noch besser wird...
Sowas wuerde mich wirklich aus den Socken hauen, aber da mach' ich mir 
mal keine Hoffnung.
Eher geht der 16Exabyte Adressraum, der sich mit 64bit Pointern 
adressieren laesst, zur Neige, wenn in ein paar Jahren mal mit einem 
Rust(nachfolger)compiler ein HelloWorld kompiliert werden muss.

Gruss
WK

: Bearbeitet durch User
von Olaf (Gast)


Lesenswert?

> Da muessen
> immer nur irgendwelche mindest/maximal-Versionsnummern passen; einen
> bare-metal-gcc kann man sogar voellig ohne kernel und glibc
> zusammenbauen.

Ist das eigentlich nur so ein Gerede oder hast du das wirklich schonmal 
gemacht?

Ich hab das schon ein paarmal gemacht und ja man bekommt es irgendwann 
hin sich seinen eigene gcc crosscompiler zu uebersetzen. Aber das ist 
nicht mal eben so und es gibt da teilweise auch erstaunliche 
Versionsabhaengigkeiten.

Olaf

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


Lesenswert?

Olaf schrieb:
> Ist das eigentlich nur so ein Gerede oder hast du das wirklich schonmal
> gemacht?

Für AVR-GCC: ja, häufig. :)

(Ist ja auch erstmal irgendwie ein Crosscompiler, und die Host-C-Library 
nützt einem nicht viel.)

„Ohne Kernel“ ist natürlich Quatsch: irgendeine Form von OS braucht man 
schon, um den Host-CC laufen zu lassen. Anders als vor 25 Jahren genügt 
es auch nicht mehr, einen Host-CC zu haben, der noch nichtmal C89 
beherrscht (wie er bspw. dazumals bei HP-UX mit ausgeliefert worden war, 
um ein paar Kernelmodule nachcompilieren zu können).

von cppbert (Gast)


Lesenswert?

Es sind schon S.ooo.ooo.ooo viele Programmiersprachen aufgetaucht und 
wieder in der Versenkung verschwunden ohne das irgendjemand davon 
negativ beeinflusst wurde, keine Ahnung warum so viele Leute sich von 
der immer häufiger vorkommenden Werbung (Funk, Fernsehen und durch Fan 
Boys & Girls) für Rust so stören - das war mit Java oder .Net doch 
tausend mal schlimmer und davor waren es die VB-ler und Perl-Leute die 
uns mit der Allmacht ihrer Sprache genervt haben...

Rust gibt es schon ein paar Jahren und bisher hat niemand irgendjemanden 
gezwungen drauf umzusteigen oder gar (Gott erbarme dich unser) eine 
weitere Programmiersprache dazu zu lernen, die welche keinen Bock drauf 
haben brauchen es nie zu nutzen und welche die auch noch 3 andere 
Programmiersprachen können und Bock darauf haben noch ein paar andere 
Sachen/Konzept-Ideen zu sehen (egal welche Relevanz das in Zukunft haben 
wird) machen es einfach - egal ob jemand das gut oder schlecht findet

keine Argumente sind:

-Was wir haben ist doch gut - das wurde von so vielen Firmen/Entwicklern 
die unsere Leben stark beeinflussen bestätigt (was außer krude 
Verschwörungstheorien soll die bitte dazu bewegen "Werbung" für etwas zu 
machen was denen gar nicht hilft)
Nicht alle 15000 Entwickler von Google, Facebook, Microsoft etc. sind 
total blöde und machen nur Müll - die haben doch schon alle ihrer 
eigenen Super Sprachen/Plattformen - warum interessieren die sich 
überhaupt für eine weiter? Speziell wenn die vermeintlich nicht gut ist

-Neue Programmiersprache lernen ist zu "kostenintensiv": Totaler Quatsch 
- man ist nicht interessiert, faul oder hat einfach keine Zeit - ist 
aber trotzdem kein Kontra-Argument, btw: das lernen schwierig und 
vielleicht unnötig ist höre ich immer nur von lernscheuem Gesindel :) - 
die meisten Entwickler die ich kennen die so "aktiv" argumentieren sind 
Eingefahren und wollen nicht mehr weiter lernen - oder sind einfach zu 
unerfahren um Situationen richtig zu bewerten

-Läuft auf meiner Plattform nicht: den meisten geht es ehr nur um die 
Software-Konzepte die Rust forciert (die sind ja nicht neu) - ob der 
Kompiler jetzt schon alle Plattformen kann oder wird und ob guter Code 
generiert wird und ob das jetzt schon auf iOS oder dem Gameboy Color 
läuft ist völlig unrelevant, es hat bisher noch nie eine Sprache direkt 
auf allen Plattformen funktioniert und im Embedded Bereich dominiert C 
seit Jahrhunderten. Wer mit klarem Verstand denkt denn Ersthaft das man 
solch einen Plattform-Sprung in 5-10 Jahren erreicht - und nutzt das 
dann als Argument für die Qualität einer Sprache??? in Java/.Net/C/C++ 
wurde so viele Milliarden investiert - da kann man nicht einfach so 
hinterher ziehen - aber auch die kleinen brauchen mal eine Chance - oder 
sollen uns doch nur die großen Konzerne leiten?

Einfach mal den Ball flach halten und die Fan Boys & Girls durch die 
Gassen marschieren lassen - vielleicht kommt ja doch was dabei raus

von Olaf (Gast)


Lesenswert?

> Nicht alle 15000 Entwickler von Google, Facebook, Microsoft etc. sind
> total blöde und machen nur Müll - die haben doch schon alle ihrer
> eigenen Super Sprachen/Plattformen - warum interessieren die sich
> überhaupt für eine weiter? Speziell wenn die vermeintlich nicht gut ist

Noe, das sind sie sicher nicht. Die Frage ist nur was sie antreibt.

Manche Sprachen werden von Einzelpersonen als Spassprojekt erfunden. 
Vielleicht weil sie der Scheiss den sie jeden Tag 8h in der Firma machen 
total abnervt. Das ist dann je nach Person, aber auch Erwartungshaltung, 
total genial oder ziemlicher Murks.

Anderes wird aber von einer Firma entwickelt/gefordert/bezahlt. Und da 
kommen die Entwicklungsziele eher nicht vom Programmierer sondern von 
der Etage da drueber. Und was ist wohl deren Anforderung?

Man darf vermuten das eines der groessten Probleme heute ist das die 
mittlere Faehigkeit eines Programmierers deutlich geringer ist als noch 
vor 20Jahren. Es gibt heute sicher noch genauso viele gute Leute wie 
frueher, aber da heute jeder Programmieren koennen soll der nicht bei 
drei auf den Baeumen ist, ist die mittlere Programmierintelligenz IMHO 
stark abgesunken. (siehe auch copy&paste, Webseitenprogrammierer, nicht 
vorhandener moralischer Kompass)

Und da will man Sprachen wie C oder gar CPP nicht haben. Die lassen den 
Leute zuviel Freiraeume. Das ist wie eine Stadt wo man Autos ohne 
Geschwindigkeitsbegrenzung fahren kann. Fuer einige wenige waere es gut, 
fuer die meisten eher nicht.

Ich persoenlich sehe durchaus auch Schwaechen in C und wuerde gerade 
fuer den Embedded Bereich gerne auch etwas anderes probieren. Gerne auch 
um mal einfach etwas anderes zu machen. Allerdings muss ich kotzen wenn 
ich sehe das man den Leuten dann gleich neue Buildsysteme und dauerhafte 
Onlinekacke aufzwingen will. Das ist die dumme Googledenke welche die 
Menschheit nicht braucht.

Olaf

von totaler Quatsch (Gast)


Lesenswert?

cppbert schrieb:
> -Neue Programmiersprache lernen ist zu "kostenintensiv": Totaler Quatsch
> - man ist nicht interessiert, faul oder hat einfach keine Zeit - ist
> aber trotzdem kein Kontra-Argument

Ein kluger Mann hat mal gesagt: "A language that doesn't change the way 
you think about programming is not worth learning".

Ich kann wirklich nicht nachvollziehen warum man C++, Java, Python, 
Rust, etc. braucht.

Man braucht ein paar Programmiersprachen - das ist alles. (Also 
Sprachen, mit verschiedenen Programmierparadigmen. Und keine Sprachen, 
die genauso funktioniert wie zwei dutzend anderer Programmiersprachen, 
bloss diesmal natürlich viel sicherer, einfacher und moderner)

Kann man abends (wenn man Zeit hat) anschauen:

https://www.youtube.com/watch?v=P2yr-3F6PQo

Keine ensthafte Wissenschaft publiziert jedes Jahr x alternative 
Schreibweisen. Was Mathematiker vor 100 Jahren geschrieben haben, kann 
man auch heute noch "ausführen".

von Olaf (Gast)


Lesenswert?

> Ich kann wirklich nicht nachvollziehen warum man C++, Java, Python,
> Rust, etc. braucht.

Es ist schon sinnvoll das etwas mal modernisiert wird. Sonst wuerde wir 
heute immer noch in Algol68 programmieren. Allerdings sollte man das 
nicht leuchtfertig tun. Schon garnicht im Embeddedbereich wo die grosse 
Dominanz von C halt auch den Vorteil hat das du alles lesen und 
verwenden kannst was bereits seit 20Jahren in der Firma da ist.

Olaf

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


Lesenswert?

Olaf schrieb:
> sollte man das nicht leuchtfertig tun

Programmierbare LEDs? ;-)

SCNR …

von Le X. (lex_91)


Lesenswert?

totaler Quatsch schrieb:
> Ich kann wirklich nicht nachvollziehen warum man C++, Java, Python,
> Rust, etc. braucht.

Grundsätzlich versteh ich deinen Punkt.
Dein Beispiel ist allerdings sehr schlecht gewählt.
Zum einen ist zwar allen genannten Sprachen das Prozedurale Paradigma 
gemein, einige implementieren aber auch andere Paradigmen, zumindest 
teilweise.

Viel wichtiger aber: die Technik (und somit der Einsatzbereich) der 
genannten Sprachen unterscheidet sich massivst.
Wir haben da eine Skriptsprache, Sprachen die in nativen Maschinencode 
übersetzen und eine Sprache die plattformübergreifenden Bytecode für 
eine virtuelle Maschine liefert.

In deiner Aufzählung könnte man maximal und mit viel guten Willen C++ 
und Rust gleichsetzen und eine davon in Frage stellen.
Ansonsten vergleichst du Äpfel mit Birnen.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Le X. schrieb:
> Ansonsten vergleichst du Äpfel mit Birnen.

"totaler Quatsch" halt. :-) Der Name ist Programm …

Beitrag #6456164 wurde von einem Moderator gelöscht.
von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

Programmierbare LED's

Viele von euch fragen sich ob Rust das kann:
LED -> Hardware -> SETZEN, ON (nicht sechs ! :) )

Kann es ohne Probleme.

Das Problem ist Mannigfaltig und von 6502 bis ,.,, weiss ich nicht.
Rust ist ein Werkzeug. Ich hab nen laeppischen mips-bootloader laufen 
und ein Programm, dass mir iot-scheissdreck ueber meine VU+ Enigma box 
auf einen Gentoo Rechner mitteilt. Das passte grade gut, das in Rust zu 
programmieren.
Netzwerk, ASIO, ggiot.

Also was habt ihr fuer ein Problem, das nicht existiert? :)

Are we embedded yet?
https://afonso360.github.io/rust-embedded/

von Olaf (Gast)


Lesenswert?

> Viele von euch fragen sich ob Rust das kann:

Noe, das tun viele nicht. Ich kann aber hellsehen. Ungefaehr so wird es 
mit Rust in 20Jahren enden:

https://www.heise.de/hintergrund/Forth-die-ewig-junge-Programmiersprache-4988866.html


Olaf :-)

von Kaj (Gast)


Lesenswert?

Open-Source-Projekt für Sexspielzeug wird stabil
https://www.golem.de/news/buttplug-io-open-source-projekt-fuer-sexspielzeug-wird-stabil-2012-153083.html
1
Die aktuelle Version 1.0 von Buttplug ist in Rust geschrieben und bietet 
2
vor allem ein Kern-Paket, auf dem wiederum verschiedene Sprachanbindungen 
3
etwa für C# und Javascript aufbauen. Laut Ankündigung dient die 
4
Veröffentlichung vor allem dazu, künftig leichter neue Funktionen 
5
umzusetzen und Hardware-Anbindungen zu implementieren. Dies soll künftig 
6
nur noch einmal in Rust nötig und dann direkt in den Sprachanbindungen 
7
nutzbar sein. Dank dem nun verfügbaren FFI können künftig auch leicht 
8
weitere Sprachanbindungen erstellt werden. Dies hat sich die Community 
9
bereits für Python und Java sowie Kotlin gewünscht. Letztere werden für 
10
Android-Apps verwendet. Mithilfe von Anbindungen an C und C++ ist 
11
außerdem die Nutzung in der Unreal Engine möglich.


Rust 1.49.0 hebt Linux-64-Bit-ARM auf höchste Support-Stufe
https://www.heise.de/news/Rust-1-49-0-hebt-Linux-64-Bit-ARM-auf-hoechste-Support-Stufe-5002855.html
1
In der neuen Rust-Version 1.49.0 hält das Kompilierziel 
2
aarch64-unknown-linux-gnu (64-Bit-ARM unter Linux) erstmals Einzug in 
3
die Support-Stufe "Tier 1". Die höchste Support-Stufe war bislang 
4
x86-Systemen vorbehalten. Ebenfalls gibt es Änderungen bei den 
5
ARM-Plattformen von macOS und Windows sowie beim Test-Framework, 
6
erklären die Entwickler in einem Blogeintrag.

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

Sagt mal, nur so nebenbei ... wie viele von Euch werden dazu gezwungen 
in einem dunklen Kämmerlein zu sitzen und Rust zu programmieren?
Manche Beiträge machen dann nämlich Sinn.

Ansonsten: Einfach das Tool benutzen, was euch liegt, bzw. am besten zur 
Aufgabe und deren Lösung passt.

Bitte befreit Euch von den Ketten, die euch an EINE Programmiersprache 
sowie eure Vorurteile fesseln.
... sonnst bekommt ihr noch Visionen. So wie Olaf;)

Btw danke Olaf, der war gut:)

von MaWin (Gast)


Lesenswert?

Jedzia D. schrieb:
> Bitte befreit Euch von den Ketten, die euch an EINE Programmiersprache
> sowie eure Vorurteile fesseln.

Genau das machen Rust-Programmierer doch.
Für kaum einen von denen wird Rust wohl die erste Sprache gewesen sein.

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

MaWin schrieb:
> Jedzia D. schrieb:
>> Bitte befreit Euch von den Ketten, die euch an EINE Programmiersprache
>> sowie eure Vorurteile fesseln.
>
> Genau das machen Rust-Programmierer doch.
> Für kaum einen von denen wird Rust wohl die erste Sprache gewesen sein.

Stimmt. Und du solltest Rust mit X ersetzen. Dann können wir die Aussage 
wiederverwenden:P
Mein "Pamphlet" richtete sich auch nicht an die Herren und Damen 
Rust-Programmierer, MaWin. Sondern an die Rust-Basher. Ich rede gern 
gegen Wände, weisst Du?

Das Rust-Programmierer keine Vorurteile haben ist vielleicht ein wenig 
hoch gegriffen:) <- Ist ne böse Unterstellung, dass Du dich auch auf das 
bezogen hast.

: Bearbeitet durch User
von Dergute W. (derguteweka)


Lesenswert?

Moin,

Schoenes Beispiel fuer real existierendes Rust:
Ich will mir mal einen heif-decoder (das neue,lustige Video/Bildformat 
von Apple unter Linux bauen. Scheint mir in der libheif zu stecken. Die 
meint aber beim cmake, dass sie gerne noch den RAV1E codec haette.
Oha, dett dingens (RAV1E) ist in rust geschrieben.
Ich bin also nicht unbedingt scharf drauf, was in rust zu compilieren, 
aber wenn ich den RAV1E (oder aktuellen firefox, libsrvg, ...) unter 
BLFS haben will, bleibt mir wohl nix anderes uebrig.
Also froehlich das git gecloned und geguckt, wie mans baut: Scheint 
erstmal simpel loszugehen; einfach "cargo build --release" schreiben und 
gucken. Oha, das zieht sich. Ich geh dann mal schlafen. zzzzZZZZZZ

So, was ist denn derweilen passiert?
* Wieso muss da immer Unmengen von Shice downgeloaded werden? Wenn ich 
das nochmal in vielleicht X Jahren bauen will, gibts die ganzen server 
doch nicht mehr, oder sie liegen wo ganz anders und koennen kein https 
mehr sondern vielleicht nur noch https-v5 oder mehr. z.b. den 
Bildbetrachter xv von vor 30 Jahren kann man einfach so bauen, ohne 
Internetverbindung. Man braucht halt die sourcen.

* Ach - 's hat eh' nicht geklappt, weil mein rust schon wieder zu alt 
ist?
Ja zum Teufel, warum kann das denn nicht frueher auffallen? Und was fuer 
geile Featueres sind in rustc-1.44.1 drinnen, die rustc-1.42.0 nicht 
hat? Und brauchts die wirklich so dringend? Komisch, die boesen,alten 
Autotools und auch das nicht ganz so alte cmake koenen das schon vorher 
sagen, wenn ihnen was nicht passt. Nicht erst nach zig Stunden bauen.

So sehen meine neuesten Erfahrungen zur real existierenden rust-Welt 
aus.
Klar, das ist vielleicht alles nicht die Sprache selbst, sondern die 
Umgebung, die bekloppten Programmierer, etc.
Aber irgendwie ist das wie Kommunismus: Eigentlich ne Idee, die 
funktionieren koennte; fuehrt nur in der Praxis mit echten Menschen 
immer in die Katastrophe - braucht also kein Mensch.
So wie rust, glaub' ich.

Gruss
WK
1
root [ /usr/src/rav1e-0.4.0 ]# less doc/README.md 
2
root [ /usr/src/rav1e-0.4.0 ]# cargo build --release
3
    Updating crates.io index
4
  Downloaded console v0.14.0
5
  Downloaded arg_enum_proc_macro v0.3.0
6
  Downloaded simd_helpers v0.1.0
7
  Downloaded y4m v0.7.0
8
  Downloaded signal-hook v0.3.3
9
  Downloaded nasm-rs v0.2.0
10
  Downloaded rustc_version v0.3.2
11
  Downloaded noop_proc_macro v0.3.0
12
  Downloaded cfg-if v1.0.0
13
  Downloaded arrayvec v0.5.2
14
  Downloaded bitstream-io v1.0.0
15
  Downloaded paste v1.0.4
16
  Downloaded rayon v1.5.0
17
  Downloaded cc v1.0.66
18
  Downloaded scan_fmt v0.2.5
19
  Downloaded num-derive v0.3.3
20
  Downloaded num-traits v0.2.14
21
  Downloaded rust_hawktracer v0.7.0
22
  Downloaded itertools v0.10.0
23
  Downloaded chrono v0.4.19
24
  Downloaded av-metrics v0.6.2
25
  Downloaded thiserror v1.0.23
26
  Downloaded regex v1.4.3
27
  Downloaded fern v0.6.0
28
  Downloaded time v0.1.43
29
  Downloaded rust_hawktracer_proc_macro v0.4.1
30
  Downloaded terminal_size v0.1.15
31
  Downloaded proc-macro2 v1.0.24
32
  Downloaded rust_hawktracer_normal_macro v0.4.1
33
  Downloaded thiserror-impl v1.0.23
34
  Downloaded signal-hook-registry v1.3.0
35
  Downloaded either v1.6.1
36
  Downloaded lab v0.8.2
37
  Downloaded quote v1.0.8
38
  Downloaded syn v1.0.58
39
  Downloaded num-integer v0.1.44
40
  Downloaded semver v0.11.0
41
  Downloaded rayon-core v1.9.0
42
  Downloaded crossbeam-deque v0.8.0
43
  Downloaded crossbeam v0.8.0
44
  Downloaded log v0.4.13
45
  Downloaded libc v0.2.82
46
  Downloaded memchr v2.3.4
47
  Downloaded semver-parser v0.10.2
48
  Downloaded num_cpus v1.13.0
49
  Downloaded thread_local v1.1.0
50
  Downloaded regex-syntax v0.6.22
51
  Downloaded crossbeam-utils v0.8.1
52
  Downloaded aho-corasick v0.7.15
53
  Downloaded crossbeam-channel v0.5.0
54
  Downloaded crossbeam-queue v0.3.1
55
  Downloaded pest v2.1.3
56
  Downloaded crossbeam-epoch v0.9.1
57
  Downloaded ucd-trie v0.1.3
58
  Downloaded scopeguard v1.1.0
59
  Downloaded const_fn v0.4.5
60
  Downloaded memoffset v0.6.1
61
   Compiling autocfg v1.0.1
62
   Compiling libc v0.2.82
63
   Compiling lazy_static v1.4.0
64
   Compiling cfg-if v1.0.0
65
   Compiling proc-macro2 v1.0.24
66
   Compiling const_fn v0.4.5
67
   Compiling unicode-xid v0.2.1
68
   Compiling scopeguard v1.1.0
69
   Compiling syn v1.0.58
70
   Compiling rayon-core v1.9.0
71
   Compiling memchr v2.3.4
72
   Compiling bitflags v1.2.1
73
   Compiling either v1.6.1
74
   Compiling ucd-trie v0.1.3
75
   Compiling regex-syntax v0.6.22
76
   Compiling log v0.4.13
77
   Compiling arrayvec v0.5.2
78
   Compiling unicode-width v0.1.8
79
   Compiling signal-hook v0.3.3
80
   Compiling noop_proc_macro v0.3.0
81
   Compiling cfg-if v0.1.10
82
   Compiling rust_hawktracer_proc_macro v0.4.1
83
   Compiling lab v0.8.2
84
   Compiling rust_hawktracer_normal_macro v0.4.1
85
   Compiling bitstream-io v1.0.0
86
   Compiling scan_fmt v0.2.5
87
   Compiling paste v1.0.4
88
   Compiling y4m v0.7.0
89
   Compiling crossbeam-utils v0.8.1
90
   Compiling num-traits v0.2.14
91
   Compiling memoffset v0.6.1
92
   Compiling num-integer v0.1.44
93
   Compiling rayon v1.5.0
94
   Compiling thread_local v1.1.0
95
   Compiling itertools v0.10.0
96
   Compiling pest v2.1.3
97
   Compiling textwrap v0.11.0
98
   Compiling rust_hawktracer v0.7.0
99
   Compiling ivf v0.1.1 (/usr/src/rav1e-0.4.0/ivf)
100
   Compiling semver-parser v0.10.2
101
   Compiling time v0.1.43
102
   Compiling num_cpus v1.13.0
103
   Compiling jobserver v0.1.21
104
   Compiling signal-hook-registry v1.3.0
105
   Compiling terminal_size v0.1.15
106
   Compiling quote v1.0.8
107
   Compiling aho-corasick v0.7.15
108
   Compiling clap v2.33.3
109
   Compiling semver v0.11.0
110
   Compiling fern v0.6.0
111
   Compiling crossbeam-channel v0.5.0
112
   Compiling crossbeam-queue v0.3.1
113
   Compiling crossbeam-epoch v0.9.1
114
   Compiling cc v1.0.66
115
   Compiling simd_helpers v0.1.0
116
   Compiling regex v1.4.3
117
   Compiling rustc_version v0.3.2
118
   Compiling chrono v0.4.19
119
   Compiling crossbeam-deque v0.8.0
120
   Compiling num-derive v0.3.3
121
   Compiling thiserror-impl v1.0.23
122
   Compiling arg_enum_proc_macro v0.3.0
123
   Compiling console v0.14.0
124
   Compiling vergen v3.0.4 (/usr/src/rav1e-0.4.0/crates/vergen)
125
   Compiling crossbeam v0.8.0
126
   Compiling v_frame v0.2.0 (/usr/src/rav1e-0.4.0/v_frame)
127
   Compiling thiserror v1.0.23
128
   Compiling nasm-rs v0.2.0
129
   Compiling av-metrics v0.6.2
130
   Compiling rav1e v0.4.0 (/usr/src/rav1e-0.4.0)
131
error: failed to run custom build command for `rav1e v0.4.0 (/usr/src/rav1e-0.4.0)`
132
133
Caused by:
134
  process didn't exit successfully: `/usr/src/rav1e-0.4.0/target/release/build/rav1e-dc076fced3f1ff91/build-script-build` (exit code: 1)
135
--- stderr
136
rav1e requires rustc >= 1.44.1.
137
138
root [ /usr/src/rav1e-0.4.0 ]# rustc --version
139
rustc 1.42.0

von Olaf (Gast)


Lesenswert?

> * Wieso muss da immer Unmengen von Shice downgeloaded werden? Wenn ich
> das nochmal in vielleicht X Jahren bauen will, gibts die ganzen server
> doch nicht mehr, oder sie liegen wo ganz anders und koennen kein https

Als mir dies aufgefallen ist hab ich den Krempel von meiner Platte
geloescht. Das mag ich selbst beim rumspielen zuhause nicht, im
professionellem Umfeld ist es geradzu absurd.

Wobei ich noch das Bonusproblem hatte das er erst mit meiner 
cmake-Version unzufrieden war. Die Scriptkiddies die mittlerweile aus 
den Unis kommen koennen nur noch mit der Version von gestern und unter 
100 libaries von Hinz und Kunz kriegen sie auch nix mehr gebacken. Die 
muessen erst noch lernen
das sie mit ihren Betas zuhause rumspielen sollten und erst dann etwas 
veroeffentlichen wenn es geht. Aber das ist jetzt kein spezielles 
Problem
von Rust sondern gilt fuer aktuelle Softwareentwicklung allgemein.

Olaf

von MaWin (Gast)


Lesenswert?

Dergute W. schrieb:
> So, was ist denn derweilen passiert?
> * Wieso muss da immer Unmengen von Shice downgeloaded werden? Wenn ich
> das nochmal in vielleicht X Jahren bauen will, gibts die ganzen server
> doch nicht mehr, oder sie liegen wo ganz anders und koennen kein https
> mehr sondern vielleicht nur noch https-v5 oder mehr. z.b. den
> Bildbetrachter xv von vor 30 Jahren kann man einfach so bauen, ohne
> Internetverbindung. Man braucht halt die sourcen.

Ja. Man braucht halt die Sourcen. Inklusive der Sourcen der 
Dependencies.
Merkste was?
In deinem Cargo cache liegen die ganzen Sourcen. Und dort liegen sie, 
bis du sie löschst.
Du musst also in 30 Jahren gar nicht alles wieder herunterladen, wenn du 
es nicht gelöscht hast.
Ganz ohne Internetverbindung.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

MaWin schrieb:
> Ja. Man braucht halt die Sourcen. Inklusive der Sourcen der
> Dependencies.
> Merkste was?
> In deinem Cargo cache liegen die ganzen Sourcen. Und dort liegen sie,
> bis du sie löschst.

Ja, ich merk' was; ich bau schon seit >10 Jahren B/LFSse und merk' von 
daher schon, wo die Reise hingeht. Und ob mir das gefaellt.
Wenn ich mir einen ffmpeg oder vlcplayer oder sonstwas mit vielen 
Abhaengigkeiten bau', dann sagen mir autotools und cmake VORHER, was sie 
beoetigen. In welcher Version. Und obs dringend ist oder eher nicht so.
Und wenn ich z.b. im ffmpeg keinen shclonzen3-codec drinnenhaben will, 
dann kann ich ffmpeg auch ohne libshclonzen3 prima bauen. Und ich weiss, 
dass, wenn ich dann shclonzen3 support haben will, ich ffmpeg nochmal 
bauen kann, nachdem ich die libshclonzen3 sourcen runtergeladen und 
diese lib in der von mir gewuenschten Geschmacksrichtung 
(static/shared, debug/release, mit/ohne weitere Abhaengigkeiten, wie 
libbla, libblubber, ...) gebaut habe. Und wenn das buildsystem richtig 
gut ist, dann muss ich nichtmal alles beim ffmpeg neu bauen, sondern nur 
die durch die libshclonzen3 betroffenen Files. Und wenns super gut 
laeuft, dann kann ich das sogar crosscompilieren. Und nach einem Jahr, 
wenn ich das alles vergessen hab', guck ich in die config.log und sehe 
sofort exakt die Kommandozeile, mit der ich das konfiguriert habe. Das 
alles weiss ich (zu schaetzen).
Trotzdem und deswegen stoert es mich, dass jetzt jede grad' hippe 
software/sprache meint, ihren eigenen Paketmanager oder gar 
build-umgebung, etc. bla. mitbringen zu muessen.
Was der sudo-apt-get-install oder setup.exe Klicker nicht nachvollziehen 
kann. Was mir aber wurscht ist. Es stoert mich trotzdem.

Gruss
WK

von cppbert (Gast)


Lesenswert?

was für ein Geheulte :)

1. Die Sprache und die ganze Infrastruktur ist noch jung - auch mit 5 
Jahren noch, die Ideen mit Cargo kennt man aber so von .Net, Java, 
Python und mitlerweile sogar mit C/C++ - es ist eben noch nicht ganz so 
super perfekt rund - und das ist jedem Absolut klar

2. Cargo muss nicht unbedingt ins Internet - der kann auch lokal auf 
deinen eigenen feinst erwählten Crates orgeln

3. Es gibt eine Cache

4. Anstatt das jedes noch so kleine Projekt Self-Contained ist baut Rust 
einfach darauf das sich die Code-Duplikation über viele, gut gepflegte 
Libraries reduziert die in den heutigen Projekten in Mio Zeilen Code 
rumgurken

Jede Library hat die 5000.Implementation von irgendeinem Micro-Scheiss 
im Bauch die so viel Pflege-Energie frisst - das versucht Rust mit einer 
Zerlege- es-in-Libs-und-verteile-die-leicht zu reduzieren

von MaWin (Gast)


Lesenswert?

Dergute W. schrieb:
> dann sagen mir autotools und cmake VORHER, was sie
> beoetigen.

cargo check

> In welcher Version. Und obs dringend ist oder eher nicht so.
> Und wenn ich z.b. im ffmpeg keinen shclonzen3-codec drinnenhaben will,
> dann kann ich ffmpeg auch ohne libshclonzen3 prima bauen. Und ich weiss,
> dass, wenn ich dann shclonzen3 support haben will, ich ffmpeg nochmal
> bauen kann, nachdem ich die libshclonzen3 sourcen runtergeladen und
> diese lib in der von mir gewuenschten Geschmacksrichtung

Das nennt sich "features" in cargo.

> Trotzdem und deswegen stoert es mich, dass jetzt jede grad' hippe
> software/sprache meint, ihren eigenen Paketmanager oder gar
> build-umgebung, etc. bla. mitbringen zu muessen.

Weil es so gut funktioniert, oder warum?
Zu sagen autotools wären besser als cargo zeugt von einer enormen 
Unkenntnis.

von mh (Gast)


Lesenswert?

cppbert schrieb:
> Jede Library hat die 5000.Implementation von irgendeinem Micro-Scheiss
> im Bauch die so viel Pflege-Energie frisst - das versucht Rust mit einer
> Zerlege- es-in-Libs-und-verteile-die-leicht zu reduzieren

Damit ist man den Pflegeaufwand aber nicht los geworden, sondern verlegt 
ihn nur woanders hin. Du musst regelmäßig die Abhängigkeiten prüfen, ob 
da noch alles so funktioniert wie es soll, keine neuen unerwarteten 
Abhängigkeiten dazu gekommen sind, die Qualität noch deinen 
Anforderungen entspricht, kein Urheberrecht verletzt wird ...

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Du musst regelmäßig die Abhängigkeiten prüfen, ob
> da noch alles so funktioniert wie es soll,

Quatsch.
Dank semantic versioning ist das natürlich nicht notwendig.
Du bekommst automatisch alle rückwärtskompatiblen Weiterentwicklungen 
und Fixes.

von mh (Gast)


Lesenswert?

MaWin schrieb:
> mh schrieb:
>> Du musst regelmäßig die Abhängigkeiten prüfen, ob
>> da noch alles so funktioniert wie es soll,
>
> Quatsch.
> Dank semantic versioning ist das natürlich nicht notwendig.
> Du bekommst automatisch alle rückwärtskompatiblen Weiterentwicklungen
> und Fixes.

Dieses magic "semantic versioning" beseitigt also alle Probleme, ohne 
dass man etwas dafür tun muss?

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Dieses magic "semantic versioning" beseitigt also alle Probleme, ohne
> dass man etwas dafür tun muss?

Schaue es dir halt mal an, bevor du hier Dünnschiss verzapfst.

von mh (Gast)


Lesenswert?

MaWin schrieb:
> mh schrieb:
>> Dieses magic "semantic versioning" beseitigt also alle Probleme, ohne
>> dass man etwas dafür tun muss?
>
> Schaue es dir halt mal an, bevor du hier Dünnschiss verzapfst.

Wie soll ich mir das anschauen, ohne eine größeres Projekt damit selbst 
zu verwalten?

von cppbert (Gast)


Lesenswert?

mh schrieb:
> cppbert schrieb:
>> Jede Library hat die 5000.Implementation von irgendeinem Micro-Scheiss
>> im Bauch die so viel Pflege-Energie frisst - das versucht Rust mit einer
>> Zerlege- es-in-Libs-und-verteile-die-leicht zu reduzieren
>

> Damit ist man den Pflegeaufwand aber nicht los geworden, sondern verlegt
> ihn nur woanders hin.

nicht nur - man schafft auch eine Kultur(die dann irgendwann tief 
verwurzelt ist) das nicht jeder alles selber macht um die Self-Contained 
Ehre hoch zu halten... das reduziert auf den weltweiten Code Mio Zeilen 
die keiner braucht und welche die Interaktion zwischen Projekten 
erschweren

> Du musst regelmäßig die Abhängigkeiten prüfen, ob
> da noch alles so funktioniert wie es soll, keine neuen unerwarteten
> Abhängigkeiten dazu gekommen sind, die Qualität noch deinen
> Anforderungen entspricht, kein Urheberrecht verletzt wird ...

so lange sich die Version nicht ändert gibts keine Änderung - thats it!
Wer diese Kultur bricht kommt in die Hölle

und man könnte die Lizenz oder git Hash, svn Revision ja noch als 
Optionales Plugin mit ins spiel bringen (Key und Quelle der Daten) - ob 
du dann dich direkt mit den Internet verlinkst oder nur lokal mit deinen 
selbst gewählten Crates arbeitest ist dein Bier

von cppbert (Gast)


Lesenswert?

mh schrieb:
> MaWin schrieb:
>> mh schrieb:
>>> Du musst regelmäßig die Abhängigkeiten prüfen, ob
>>> da noch alles so funktioniert wie es soll,
>>
>> Quatsch.
>> Dank semantic versioning ist das natürlich nicht notwendig.
>> Du bekommst automatisch alle rückwärtskompatiblen Weiterentwicklungen
>> und Fixes.
>
> Dieses magic "semantic versioning" beseitigt also alle Probleme, ohne
> dass man etwas dafür tun muss?

natürlich nicht - aber es steht auch nirgends das es jetzt so für die 
nächsten 20 Jahre bleibt

es fehlt noch mehr Variants in den Quellen oder der Zuordnung - 
vielleicht will ich ja keine Version sondern einen bestimmt git-hash 
usw., die Quellen-Lokation ist noch ein wenig zu strikt

von mh (Gast)


Lesenswert?

cppbert schrieb:
> nicht nur - man schafft auch eine Kultur(die dann irgendwann tief
> verwurzelt ist) das nicht jeder alles selber macht um die Self-Contained
> Ehre hoch zu halten... das reduziert auf den weltweiten Code Mio Zeilen
> die keiner braucht und welche die Interaktion zwischen Projekten
> erschweren

Das sorgt aber auch für eine Kultur, in der sich jeder darauf verlässt, 
dass das was man im cargo findet korrekt und sicher ist.

cppbert schrieb:
> so lange sich die Version nicht ändert gibts keine Änderung - thats it!
> Wer diese Kultur bricht kommt in die Hölle

Wenn ich keine Version ändere habe ich aber auch keinen wirklichen 
Vorteil. Und wenn ich eine Version ändere, muss ich trotzdem alles 
selbst prüfen.

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Und wenn ich eine Version ändere, muss ich trotzdem alles
> selbst prüfen.

Nochmal: Völliger Unsinn.

Google: semantic versioning

von mh (Gast)


Lesenswert?

MaWin schrieb:
> mh schrieb:
>> Und wenn ich eine Version ändere, muss ich trotzdem alles
>> selbst prüfen.
>
> Nochmal: Völliger Unsinn.
>
> Google: semantic versioning

Ja MaWin, ich kann lesen und ich weiß was Semantic Versioning ist. 
Kannst du mir jetzt endlich erklären, wie das eins der Problem löst, 
wenn ich die Version von etwas ändern möchte oder muss? Wie übernimmt 
Semantic Versioning die Arbeit, die ich dann machen muss?

von Operator S. (smkr)


Lesenswert?

mh schrieb:
> Wenn ich keine Version ändere habe ich aber auch keinen wirklichen
> Vorteil. Und wenn ich eine Version ändere, muss ich trotzdem alles
> selbst prüfen.

Das erinnert mich an die Einstellung, wie man vor 20 Jahren Software 
entwickelte. Da blieb man jahrelang auf der gleichen Compilerversion, da 
die ja schliesslich funktionierte und erprobt sei. Alle später 
veröffentlichten Versionen konnte man nicht trauen, schliesslich könnten 
ja neue Fehler mit reingekommen sein, etc. :)

von cppbert (Gast)


Lesenswert?

mh schrieb:
> Das sorgt aber auch für eine Kultur, in der sich jeder darauf verlässt,
> dass das was man im cargo findet korrekt und sicher ist.

für Normale Entwickler vielleicht schon, die ziehen aber auch alles was 
kreucht und fleucht, aber nicht unbedingt im prof. Umfeld

von cppbert (Gast)


Lesenswert?

mh schrieb:
> Kannst du mir jetzt endlich erklären, wie das eins der Problem löst,
> wenn ich die Version von etwas ändern möchte oder muss? Wie übernimmt
> Semantic Versioning die Arbeit, die ich dann machen muss?

wenn du einen Versions-Wechsel machst ändert doch Rust nichts an den 
Folgenotwendigekeiten? du musst immer noch prüfen ob die Interfaces 
passen, deine Tests laufen und ob die Lizenz noch zu dir passt?

oder was meinst du?

von Nick M. (Gast)


Lesenswert?

Operator S. schrieb:
> Alle später
> veröffentlichten Versionen konnte man nicht trauen, schliesslich könnten
> ja neue Fehler mit reingekommen sein, etc. :)

Hast du das noch nie erlebt? Scheinbar nicht.

von cppbert (Gast)


Lesenswert?

mh schrieb:
> Wenn ich keine Version ändere habe ich aber auch keinen wirklichen
> Vorteil. Und wenn ich eine Version ändere, muss ich trotzdem alles
> selbst prüfen.

ist ja auch nur ein Distribution-Konzept keine alles-geht-automatisch 
Lösung
mehr ist es bisher nicht

von cppbert (Gast)


Lesenswert?

cppbert schrieb:
> mh schrieb:
>> Wenn ich keine Version ändere habe ich aber auch keinen wirklichen
>> Vorteil. Und wenn ich eine Version ändere, muss ich trotzdem alles
>> selbst prüfen.
>
> ist ja auch nur ein Distribution-Konzept keine alles-geht-automatisch
> Lösung
> mehr ist es bisher nicht

Zugangsproblem für Normalos ist immer - ich bekomme die Lib nicht zum 
Linken/Kompilieren etc.

Solche Probleme haben .Net, Java, ... nicht und das macht für viele den 
Zugang schwer

von mh (Gast)


Lesenswert?

Operator S. schrieb:
> mh schrieb:
>> Wenn ich keine Version ändere habe ich aber auch keinen wirklichen
>> Vorteil. Und wenn ich eine Version ändere, muss ich trotzdem alles
>> selbst prüfen.
>
> Das erinnert mich an die Einstellung, wie man vor 20 Jahren Software
> entwickelte. Da blieb man jahrelang auf der gleichen Compilerversion, da
> die ja schliesslich funktionierte und erprobt sei. Alle später
> veröffentlichten Versionen konnte man nicht trauen, schliesslich könnten
> ja neue Fehler mit reingekommen sein, etc. :)

Nur, dass ich explizit die Version ändern möchte und den Arbeitsaufwand 
dafür kenne und weiß, dass mir cargo dabei nicht hilft.

cppbert schrieb:
> mh schrieb:
>> Kannst du mir jetzt endlich erklären, wie das eins der Problem löst,
>> wenn ich die Version von etwas ändern möchte oder muss? Wie übernimmt
>> Semantic Versioning die Arbeit, die ich dann machen muss?
>
> wenn du einen Versions-Wechsel machst ändert doch Rust nichts an den
> Folgenotwendigekeiten? du musst immer noch prüfen ob die Interfaces
> passen, deine Tests laufen und ob die Lizenz noch zu dir passt?
>
> oder was meinst du?

Du scheinst es so langsam verstanden zu haben. Wenn ich eine Version 
ändern möchte, hilft mir cargo nicht wirklich. Der große Teil der Arbeit 
liegt im Überprüfen der Änderungen, nicht im ändern der Versionsnummer 
für den wie auch immer organisierten Download.

Ich schreib weiterhin "Kleinkram" selbst, mit allen Rechten und 
Pflichten, statt mich 2 Mal im Jahr durch die Doku in cargo und co 
quälen zu müssen, nur  um am Ende mit weniger Rechten da zu stehen.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Also das Problem sehe ich auch. Man kann ohne Aufwand einfach 
Abhängigkeiten hinzufügen, diese rekursive runterladen & updaten lassen. 
Dadurch hat man schnell viele Abhängigkeiten. Mit mehr & öfters 
ändernden Abhängigkeiten ist die Qualitätskontrolle sehr schwierig. Und 
die müsste ja eigentlich im Idealfall von jedem Entwickler bei jeder 
Änderung erflogen. Scheint aber wohl heutzutage nicht mehr in zu sein...

von Operator S. (smkr)


Lesenswert?

Nick M. schrieb:
> Hast du das noch nie erlebt? Scheinbar nicht.

Doch, ich glaube mich wiederholen zu müssen, aber so vor 20 Jahren war 
das gang und gäbe.

Seitdem haben die Tools und Software-Arbeitsprozesse aber einen 
erheblichen Fortschritt gemacht und man kann sich darauf verlassen, was 
drauf steht.
Natürlich gibt es einige Firmen und noch mehr Einzelpersonen, die diese 
Entwicklung nicht mitgemacht haben. Die lernt man aber schnell zu 
meiden.

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> wenn du einen Versions-Wechsel machst ändert doch Rust nichts an den
> Folgenotwendigekeiten?

Ich weiß nicht wo dein Problem ist und wo das etwas mit Rust oder Cargo 
zu tun hätte.
Kompatible Updates (Bugfixes) gehen mit Cargo dank Semantic Versioning 
halbautomatisch. Das einzige, was man tun muss, ist "cargo update".
Wenn du auf eine inkompatible Version wechseln willst, dann hat der 
Aufwand überhaupt nichts mit Cargo zu tun und ist bei jeder 
Programmiersprache in etwa gleich groß.

von mh (Gast)


Lesenswert?

Operator S. schrieb:
> Nick M. schrieb:
>> Hast du das noch nie erlebt? Scheinbar nicht.
>
> Doch, ich glaube mich wiederholen zu müssen, aber so vor 20 Jahren war
> das gang und gäbe.
>
> Seitdem haben die Tools und Software-Arbeitsprozesse aber einen
> erheblichen Fortschritt gemacht und man kann sich darauf verlassen, was
> drauf steht.
> Natürlich gibt es einige Firmen und noch mehr Einzelpersonen, die diese
> Entwicklung nicht mitgemacht haben. Die lernt man aber schnell zu
> meiden.

Welches Tool stellt denn sicher, dass alle meine Abhängigkeiten nach dem 
Update weiterhin eine kompatible Lizenz haben? Welches Tool stellt 
sicher, dass keins der Projekte von denen ich abhängig bin gehackt 
wurde? Welches Tool stellt sicher, dass es keine bekannte gravierende 
ungefixete Sicherheitslücke in meinen Abhängigkeiten gibt? ...

von Operator S. (smkr)


Lesenswert?

MaWin schrieb:
> Kompatible Updates (Bugfixes) gehen mit Cargo dank Semantic Versioning
> halbautomatisch.

Er spricht nicht von der technischen Hürde eine Version zu ändern, 
sondern vom Vertrauen in die Packages.

Kein Wunder kommen Embedded Projekte nicht vom Fleck, wenn jeder sein 
eigenes Gärtchen beackert.

von MaWin (Gast)


Lesenswert?

Operator S. schrieb:
> Er spricht nicht von der technischen Hürde eine Version zu ändern,
> sondern vom Vertrauen in die Packages.

Warum sollte ein Paket mit einer neuen Version plötzlich 
unvertrauenswürdig werden?
Auf crates.io kann zwar initial jeder alles hochladen, aber nicht als 
Folgeversion.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin schrieb:
> Kompatible Updates (Bugfixes) gehen mit Cargo dank Semantic Versioning
> halbautomatisch. Das einzige, was man tun muss, ist "cargo update".

Qualitätssicherung sollte schon etwas mehr beinhalten, als nur 
"kompiliert noch"...

von mh (Gast)


Lesenswert?

MaWin schrieb:
> cppbert schrieb:
>> wenn du einen Versions-Wechsel machst ändert doch Rust nichts an den
>> Folgenotwendigekeiten?
>
> Ich weiß nicht wo dein Problem ist und wo das etwas mit Rust oder Cargo
> zu tun hätte.
> Kompatible Updates (Bugfixes) gehen mit Cargo dank Semantic Versioning
> halbautomatisch. Das einzige, was man tun muss, ist "cargo update".
> Wenn du auf eine inkompatible Version wechseln willst, dann hat der
> Aufwand überhaupt nichts mit Cargo zu tun und ist bei jeder
> Programmiersprache in etwa gleich groß.

Du hast vermutlich das Problem nicht verstanden. Ich muss trotzdem 
nachgucken, was geändert wurde, wer es geändert hat und vor allem, ob 
"deren" Meinung von "kompatibles Update" mit meiner Meinung 
übereinstimmt.

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Welches Tool stellt denn sicher, dass alle meine Abhängigkeiten nach dem
> Update weiterhin eine kompatible Lizenz haben?

Semantic Versioning.

> Welches Tool stellt
> sicher, dass keins der Projekte von denen ich abhängig bin gehackt
> wurde? Welches Tool stellt sicher, dass es keine bekannte gravierende
> ungefixete Sicherheitslücke in meinen Abhängigkeiten gibt? ...

Das hat doch alles überhaupt nichts mit Rust zu tun.
Gleiches gilt für alle Software. Auch z.B. ganz klassische 
Linux-Distributionen.

Warum zündest du diese Nebelkerzen?

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Qualitätssicherung sollte schon etwas mehr beinhalten, als nur
> "kompiliert noch"...

Ja und?
Dann mache doch deine Qualitätsprüfungen?
Wo ist denn jetzt das Problem?
Und wo unterscheidet sich das von jeder anderen Software, die nicht 
Rust/Cargo nutzt?

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Du hast vermutlich das Problem nicht verstanden. Ich muss trotzdem
> nachgucken, was geändert wurde, wer es geändert hat und vor allem, ob
> "deren" Meinung von "kompatibles Update" mit meiner Meinung
> übereinstimmt.

Du musst überhaupt nichts.
Wenn du das prüfen willst, dann steht es dir frei das alles zu prüfen.
Dann beschwere dich aber bitte nicht, dass das viel Arbeit ist.

von Nick M. (Gast)


Lesenswert?

Operator S. schrieb:
> Doch, ich glaube mich wiederholen zu müssen, aber so vor 20 Jahren war
> das gang und gäbe.

So weit muss ich da nicht zurückdenken. Mir genügen 3 Jahre.

von mh (Gast)


Lesenswert?

MaWin schrieb:
> mh schrieb:
>> Welches Tool stellt denn sicher, dass alle meine Abhängigkeiten nach dem
>> Update weiterhin eine kompatible Lizenz haben?
>
> Semantic Versioning.

Schön, dass du einer Versionsnummer blind vertraust.

MaWin schrieb:
>> Welches Tool stellt
>> sicher, dass keins der Projekte von denen ich abhängig bin gehackt
>> wurde? Welches Tool stellt sicher, dass es keine bekannte gravierende
>> ungefixete Sicherheitslücke in meinen Abhängigkeiten gibt? ...
>
> Das hat doch alles überhaupt nichts mit Rust zu tun.
> Gleiches gilt für alle Software. Auch z.B. ganz klassische
> Linux-Distributionen.

Ich verkaufe keine Linux Distribution ...

MaWin schrieb:
> Und wo unterscheidet sich das von jeder anderen Software, die nicht
> Rust/Cargo nutzt?

Ja endlich! Du hast erkannt, dass es sich nicht unterscheidet. Damit 
sind wir bei meinem ursprünglichen Beitrag ...
mh schrieb:
> cppbert schrieb:
>> Jede Library hat die 5000.Implementation von irgendeinem Micro-Scheiss
>> im Bauch die so viel Pflege-Energie frisst - das versucht Rust mit einer
>> Zerlege- es-in-Libs-und-verteile-die-leicht zu reduzieren
>
> Damit ist man den Pflegeaufwand aber nicht los geworden, sondern verlegt
> ihn nur woanders hin.

MaWin schrieb:
> Wenn du das prüfen willst, dann steht es dir frei das alles zu prüfen.

Meine Kunden erwarten, dass ich das für die Software, die ich entwickle, 
prüfe. Dafür Zahlen sie mir Geld ...

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin schrieb:
> 🐧 DPA 🐧 schrieb:
>> Qualitätssicherung sollte schon etwas mehr beinhalten, als nur
>> "kompiliert noch"...
>
> Ja und?
> Dann mache doch deine Qualitätsprüfungen?
> Wo ist denn jetzt das Problem?

🐧 DPA 🐧 schrieb:
> Man kann ohne Aufwand einfach
> Abhängigkeiten hinzufügen, diese rekursive runterladen & updaten lassen.
> Dadurch hat man schnell viele Abhängigkeiten. Mit mehr & öfters
> ändernden Abhängigkeiten ist die Qualitätskontrolle sehr schwierig. Und
> die müsste ja eigentlich im Idealfall von jedem Entwickler bei jeder
> Änderung erflogen. Scheint aber wohl heutzutage nicht mehr in zu sein...

MaWin schrieb:
> Und wo unterscheidet sich das von jeder anderen Software, die nicht
> Rust/Cargo nutzt?

Darin, dass es einen Anreiz gibt, unnötige Abhängigkeiten zu vermeiden, 
und diese weniger leichtfertig verwendet werden. Man setzt sich eher 
damit auseinander.

MaWin schrieb:
> Gleiches gilt für alle Software. Auch z.B. ganz klassische
> Linux-Distributionen.

In besondere bei Debian gibt es strikte Kriterien, denen ein Packet 
gerecht werden muss, um in Debian rein zu kommen, und drin zu bleiben. 
Fehler müssen z.B. behoben werden, basierend ob proprietäre Software 
benötigt wird wird es anders einsortiert, usw. Das ist eine zusätzliche 
Qualitätssicherung.

von cppbert (Gast)


Lesenswert?

Es ist klar das durch so ein Package-System sehr viele Dependencies 
entstehen können - aber es ist auch klar das kleinere, vielgenutzte Libs 
eine höhrere Qualität/Testgrad aufweisen als wenige monolithen

Nicht anders machen wir es doch auch innerhalb unserer eigenen Software, 
viele kleine, gut getestete Komponenten - die sogar mit anderen 
Abteilungen geshared werden (sollten)

Es ist klar das eine Handvoll externen Abhängigkeiten die als monolith 
entwickelt werden leichter kontrollierbar sind - aber auch nur weil die 
sich oft ihres Umfangs wegen weniger schneller entwickeln (was nicht 
unbedingt gesund oder ungesund ist)

Ich finde es z.B. ziemlich beeindrucken das Rust mit den Nightly Builds 
einen grossteil der public verfügbaren Crates als Regressions-Test baut, 
dauert weil Rust so fiese langsam ist eben 4 Tage, aber stell euch mal 
vor wie aufwändig das wäre mit Github und C/C++ Projekten zu erreichen - 
wenn wir die Menge an Buildsystemen/Varianten mit einbeziehen ist das 
faktisch nicht möglich ohne permanente Handarbeit

von cppbert (Gast)


Lesenswert?

mh schrieb:
> Du hast vermutlich das Problem nicht verstanden. Ich muss trotzdem
> nachgucken, was geändert wurde, wer es geändert hat und vor allem, ob
> "deren" Meinung von "kompatibles Update" mit meiner Meinung
> übereinstimmt.

das ist doch noch alles gar nicht fertig, warum so drauf rumreiten?

wenn das Semantic Versioning sauber durchgezogen wird erkennst du 
inkompatibilität an der Version - wenn das nicht sauber durchgezogen 
wird ists Müll

Aber was garantiert dir denn bitte bei irgendeiner Lib das dort die 
Changelogs sauber sind - das geht doch nur wenn die Menge an 
Third-parties klein ist oder du deinen Pappenheimer genau kennst - schön 
für dein Programm? was ist mit den andere 40 Projekten die andere 
Dependencies haben und vielleicht nicht so einen klugen Entwickler wie 
dich an der Leitung - da ist es genau so glück das alles richtig 
funktioniert, richtig geprüft wird

Wenn man immer nur auf sein kleinen Bereich schaut ist alles egal - aber 
frage mal einen Software-Projekt-Manager der zig Projekte und Teams 
unter sich hat...

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> wenn das Semantic Versioning sauber durchgezogen wird erkennst du
> inkompatibilität an der Version - wenn das nicht sauber durchgezogen
> wird ists Müll

Wenn du dem nicht vertraust, dann nutze es nicht und prüfe alles 
manuell.
Meine Güte. Deine Entscheidung.

von Andreas (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Mit mehr & öfters
> ändernden Abhängigkeiten ist die Qualitätskontrolle sehr schwierig. Und
> die müsste ja eigentlich im Idealfall von jedem Entwickler bei jeder
> Änderung erflogen.

Diese Qualitätskontrolle besteht heutzutage i.d.R. nicht mehr aus „ein 
Entwickler liest sich den ganzen Code durch“, sondern aus 
automatisierten Tests, und QA-Protokollen die nicht auf Sourcecodeebene 
arbeiten. Wer heutzutage alle Änderungen in Code-Abhängigkeiten manuell 
prüfen möchte, der kann einfach keine komplexe Software mehr entwickeln. 
Ein Vertrauen in gewisse Packages oder Repositories ist notwendig, egal 
ob es um kommerzielle Angebote (z.B. kommerzielle Toolchains mit 
Bibliotheken) oder Open Source geht. Du kannst z.B. unmöglich alle 
Änderungen in komplexen Abhängigkeiten wie einem IP-Stack, einer 
SSL-Bibliothek oder einem RTOS manuell sichten. Und ewig auf alten 
Versionen festzuhalten ist eine „Lösung“ mit der man böse auf die Nase 
fallen kann. Plötzlich kommt soetwas wie Ripple20, und wer dann keinen 
etablierten Prozess hat um regelmäßig Änderungen in Abhängigkeiten 
einzupflegen der schaut plötzlich ganz blöd aus der Wäsche, weil das 
alte major release von lwIP das das Produkt verwendet seit 3 Jahren 
nicht mehr supported wird, und keiner eine Ahnung hat wie man das Loch 
patchen und testen kann.

von MaWin (Gast)


Lesenswert?

Andreas schrieb:
> Diese Qualitätskontrolle besteht heutzutage i.d.R. nicht mehr aus „ein
> Entwickler liest sich den ganzen Code durch“, sondern aus
> automatisierten Tests,

Völlig richtig.
Und deshalb hat Rust/Cargo natürlich auch ein vollständiges Unittest- 
und Systemtest-Framework eingebaut.

von mh (Gast)


Lesenswert?

cppbert schrieb:
> aber es ist auch klar das kleinere, vielgenutzte Libs
> eine höhrere Qualität/Testgrad aufweisen als wenige monolithen
Ist das so? Gibt es dazu eine Studie oder ähnliches, wo man das 
nachlesen kann?

cppbert schrieb:
> Nicht anders machen wir es doch auch innerhalb unserer eigenen Software,
> viele kleine, gut getestete Komponenten - die sogar mit anderen
> Abteilungen geshared werden (sollten)
Da muss ich oder ein Kollege aber auch den Kopf hin halten, wenn etwas 
nicht in Ordnung ist.

cppbert schrieb:
> Ich finde es z.B. ziemlich beeindrucken das Rust mit den Nightly Builds
> einen grossteil der public verfügbaren Crates als Regressions-Test baut,
> dauert weil Rust so fiese langsam ist eben 4 Tage, aber stell euch mal
> vor wie aufwändig das wäre mit Github und C/C++ Projekten zu erreichen -
> wenn wir die Menge an Buildsystemen/Varianten mit einbeziehen ist das
> faktisch nicht möglich ohne permanente Handarbeit
Ich sehe nicht so ganz den Vorteil, unkontrollierten Quelltext für 
Regressionstests zu nutzen, vor allem bei einer nicht wirklich 
definierten Sprache (das Thema Sprachdefinition wurde schon durchgekaut, 
und ich bin an keiner weiteren Diskussion interessiert, bis die 
Definition existiert). Wer wertet das alles aus, vor allem wenn es schon 
3 neue Nightly Builds gibt, wenn das Ergebnis bereit steht?

cppbert schrieb:
> mh schrieb:
>> Du hast vermutlich das Problem nicht verstanden. Ich muss trotzdem
>> nachgucken, was geändert wurde, wer es geändert hat und vor allem, ob
>> "deren" Meinung von "kompatibles Update" mit meiner Meinung
>> übereinstimmt.
>
> das ist doch noch alles gar nicht fertig, warum so drauf rumreiten?
Weil MaWin es immer wieder aus der Ecke kramt. Und auch wenn es fertig 
wäre, löst es das Problem nicht.

cppbert schrieb:
> wenn das Semantic Versioning sauber durchgezogen wird erkennst du
> inkompatibilität an der Version - wenn das nicht sauber durchgezogen
> wird ists Müll
Und wer kontrolliert, dass es sauber durchgezogen wird?

cppbert schrieb:
> Aber was garantiert dir denn bitte bei irgendeiner Lib das dort die
> Changelogs sauber sind
Man kann sich die Commits angucken ... Man muss ja nicht jedes einzelne 
Zeichen kontrollieren, es gibt Strategien, um die eigenen Fragen 
effizient zu beantworten.

cppbert schrieb:
> [...]
> Wenn man immer nur auf sein kleinen Bereich schaut ist alles egal - aber
> frage mal einen Software-Projekt-Manager der zig Projekte und Teams
> unter sich hat...
Was genau willst du damit sagen? Qualitätssicherung ist nicht wichtig, 
wenn man überarbeitet oder überfordert ist? Und warum kann der 
Sofrware-Projekt-Manager diese Aufgabe nicht an einen Softwareentwickler 
delegieren?

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> cppbert schrieb:
>> wenn das Semantic Versioning sauber durchgezogen wird erkennst du
>> inkompatibilität an der Version - wenn das nicht sauber durchgezogen
>> wird ists Müll
>
> Wenn du dem nicht vertraust, dann nutze es nicht und prüfe alles
> manuell.
> Meine Güte. Deine Entscheidung.

Ich wollte nichts dagegen sagen: ich vertraue darauf das Verfehlungen 
mit dem Semantic Versioning von der Community so radikal verurteilt 
werden das sich auch jeder Newbie in kürzester Zeit daran hält wie an 
die 10 Gebote...

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Ich sehe nicht so ganz den Vorteil, unkontrollierten Quelltext für
> Regressionstests zu nutzen, [...] Wer wertet das alles aus, vor allem wenn es 
schon
> 3 neue Nightly Builds gibt, wenn das Ergebnis bereit steht?

Da es sich natürlich um automatisierte Tests handelt, ist die Auswertung 
inbegriffen.

von cppbert (Gast)


Lesenswert?

mh schrieb:
>> aber es ist auch klar das kleinere, vielgenutzte Libs
>> eine höhrere Qualität/Testgrad aufweisen als wenige monolithen
> Ist das so? Gibt es dazu eine Studie oder ähnliches, wo man das
> nachlesen kann?

wozu Studie? vertraust du nicht auf das Konzept: weniger, aber viel 
genutzte Zeilen Code sind meist weniger fehlerbehaftet, als großer, 
selten genutzter Code?

mh schrieb:
>> Nicht anders machen wir es doch auch innerhalb unserer eigenen Software,
>> viele kleine, gut getestete Komponenten - die sogar mit anderen
>> Abteilungen geshared werden (sollten)
> Da muss ich oder ein Kollege aber auch den Kopf hin halten, wenn etwas
> nicht in Ordnung ist.

das ist dann natürlich ganz klar meine Verantwortung, warum sollte ich 
dafür keine Verantwortung tragen???

mh schrieb:
>> Ich finde es z.B. ziemlich beeindrucken das Rust mit den Nightly Builds
>> einen grossteil der public verfügbaren Crates als Regressions-Test baut,
>> dauert weil Rust so fiese langsam ist eben 4 Tage, aber stell euch mal
>> vor wie aufwändig das wäre mit Github und C/C++ Projekten zu erreichen -
>> wenn wir die Menge an Buildsystemen/Varianten mit einbeziehen ist das
>> faktisch nicht möglich ohne permanente Handarbeit
> Ich sehe nicht so ganz den Vorteil, unkontrollierten Quelltext für
> Regressionstests zu nutzen

Da geht es nur um Parser und Kompiler-Tests - mehr nicht, und das du 
sowas mit C/C++ oder anderen (im Kern) nicht Package-basierten 
out-of-the-box Buildbaren Sprachen so was einfach sehr schwer ist

mh schrieb:
>> wenn das Semantic Versioning sauber durchgezogen wird erkennst du
>> inkompatibilität an der Version - wenn das nicht sauber durchgezogen
>> wird ists Müll
> Und wer kontrolliert, dass es sauber durchgezogen wird?

du, deine Kollegen, die Community, die Welt...

mh schrieb:
>> Aber was garantiert dir denn bitte bei irgendeiner Lib das dort die
>> Changelogs sauber sind
> Man kann sich die Commits angucken ... Man muss ja nicht jedes einzelne
> Zeichen kontrollieren, es gibt Strategien, um die eigenen Fragen
> effizient zu beantworten.

das würde Ich auch mit Semantik Versioning machen - aber würde es 
trotzdem schön finden wenn sich eine Kultur entwickelt die Verfehlungen 
in dem Bereich starke Abneigung der Community erzeugt - und wenn der 
kein Soziopath ist - oder wem seine Reputation egal ist wirds dann eben 
nicht jucken - ist halt so

mh schrieb:
>> Wenn man immer nur auf sein kleinen Bereich schaut ist alles egal - aber
>> frage mal einen Software-Projekt-Manager der zig Projekte und Teams
>> unter sich hat...
> Was genau willst du damit sagen? Qualitätssicherung ist nicht wichtig,
> wenn man überarbeitet oder überfordert ist? Und warum kann der
> Sofrware-Projekt-Manager diese Aufgabe nicht an einen Softwareentwickler
> delegieren?

in absolut keinster Weise - wie kannst du das aus dem Text rauslesen?
Ich sage nur das eine bessere Kulturentwicklung die von einem einfachem 
System begünstigt wird sich schlussendlich auszahlen wird und der 
einzelne Entwickler einfach nicht immer direkt einer von den sehr guten 
sein muss damit auch gut läuft - btw: ich arbeite viel im Medizinbereich 
- Auditierung usw. ich weiss ganz genau was Qualität bedeutet - speziell 
in Projekten wo dir die FDA u.a. oder anderen den Vetrieb verbieten 
können :)

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
> Warum sollte ein Paket mit einer neuen Version plötzlich
> unvertrauenswürdig werden?

Weil z.B. das Ergebnis eines stattgefundenen Code-Reviews verpufft und 
nachgeholt werden muss. Zumindest, wenn man es ernst meint.

Sich abhängig zu machen von anderen ist eine leichte Entscheidung. Wird 
aber doof, wenn man selbst den Kopf für das Gesamtergebnis hinhalten 
muss - und Teile davon außerhalb der eigenen Zuständigkeit liegen.

Das Problem ist nicht, dass es Abhängigkeiten gibt.
Das Problem ist, dass ein Programmierstil mit möglichst vielen 
Abhängigkeiten entsteht (und offensichtlich auch gewünscht wird). Die 
Stabilität des Gesamtsystems ist daher nicht mehr gegeben, da sich 
ununterbrochen bestimmte Teile verändern.

An deinem Auto schraubst du auch nicht ständig rum und tauschst 
irgendwelche Bolzen aus, nur weil der Bolzenhersteller sagt, dass der 
gestern chromefarbene Bolzen heute bronzefarben sein muss...

von mh (Gast)


Lesenswert?

cppbert schrieb:
> das sich auch jeder Newbie in kürzester Zeit daran hält wie an
> die 10 Gebote...

Dann solltest du etwas Selbstrefelxion betreiben und prüfen, ob du dich 
an alle 10 Gebote hälst. Ich halte mich nicht an alle 10 ;-).

cppbert schrieb:
> mh schrieb:
>>> aber es ist auch klar das kleinere, vielgenutzte Libs
>>> eine höhrere Qualität/Testgrad aufweisen als wenige monolithen
>> Ist das so? Gibt es dazu eine Studie oder ähnliches, wo man das
>> nachlesen kann?
>
> wozu Studie? vertraust du nicht auf das Konzept: weniger, aber viel
> genutzte Zeilen Code sind meist weniger fehlerbehaftet, als großer,
> selten genutzter Code?

1. Nein ich vertraue nicht blind einem unbewiesenen Konzept
2. Warum ändert sich die Anzahl der Codezeilen?

cppbert schrieb:
> [...]
> du, deine Kollegen, die Community, die Welt...
Die Community ist aber nicht für die Software verantwortlich, die ich 
meinem Kunden verkaufe. Wir drehen uns im Kreis.

Ich weiß nicht wie es dir geht, aber immer wenn ich von so etwas wie 
heartbleed erfahre, frage ich mich "wie kann sowas nicht vorher 
auffallen?".
Ich sage nicht, dass mir der Bug aufgefallen wäre, aber ich wäre für die 
möglichen Folgen dieses Bugs in meiner Software verantwortlich und 
niemand sonst. (Ich habe openssl nicht als Abhängigkeit)

> mh schrieb:
>>> Aber was garantiert dir denn bitte bei irgendeiner Lib das dort die
>>> Changelogs sauber sind
>> Man kann sich die Commits angucken ... Man muss ja nicht jedes einzelne
>> Zeichen kontrollieren, es gibt Strategien, um die eigenen Fragen
>> effizient zu beantworten.
>
> das würde Ich auch mit Semantik Versioning machen - aber würde es
> trotzdem schön finden wenn sich eine Kultur entwickelt die Verfehlungen
> in dem Bereich starke Abneigung der Community erzeugt - und wenn der
> kein Soziopath ist - oder wem seine Reputation egal ist wirds dann eben
> nicht jucken - ist halt so
Die Abneigung der Community und der eigene Ruf ist ziemlich egal, wenn 
es um viel Geld geht, vor allem, da das Internet ziemlich anonym ist. 
Wieviel Geld ein geschickter Hacker wohl verdienen kann, wenn er es 
schafft einen kleinen Exploit in openssl zu verstecken, der es für 1 Tag 
in die repos einer Linux Distribution schafft.

> mh schrieb:
>>> Wenn man immer nur auf sein kleinen Bereich schaut ist alles egal - aber
>>> frage mal einen Software-Projekt-Manager der zig Projekte und Teams
>>> unter sich hat...
>> Was genau willst du damit sagen? Qualitätssicherung ist nicht wichtig,
>> wenn man überarbeitet oder überfordert ist? Und warum kann der
>> Sofrware-Projekt-Manager diese Aufgabe nicht an einen Softwareentwickler
>> delegieren?
>
> in absolut keinster Weise - wie kannst du das aus dem Text rauslesen?
Das war das einzige was ich da reinlesen konnte. Was sollte ich denn da 
rauslesen?

> Ich sage nur das eine bessere Kulturentwicklung die von einem einfachem
> System begünstigt wird sich schlussendlich auszahlen wird und der
> einzelne Entwickler einfach nicht immer direkt einer von den sehr guten
> sein muss damit auch gut läuft - btw: ich arbeite viel im Medizinbereich
> - Auditierung usw. ich weiss ganz genau was Qualität bedeutet - speziell
> in Projekten wo dir die FDA u.a. oder anderen den Vetrieb verbieten
> können :)
Und ihr überprüft nicht bei jedem Update, ob die Abhängikeiten noch in 
Ordnung sind? Für wen genau arbeitest du?

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> Die
> Stabilität des Gesamtsystems ist daher nicht mehr gegeben, da sich
> ununterbrochen bestimmte Teile verändern.

Nein. Unsinn.

Mit Semantic Versioning verändert sich genau gar nichts in inkompatibler 
Art und Weise.
Und wenn du dem nicht vertraust, dann pinne halt deine Version fest.

Es ist einzig und alleine die Entscheidung des Entwicklers, ob sich 
Teile ändern oder nicht.

Ich sehe hier überhaupt gar keine Gefährdung der Stabilität des 
Gesamtsystems durch Cargo/Rust.

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Ich sage nicht, dass mir der Bug aufgefallen wäre, aber ich wäre für die
> möglichen Folgen dieses Bugs in meiner Software verantwortlich und
> niemand sonst. (Ich habe openssl nicht als Abhängigkeit)

Und wenn du die TLS-Implementierung selbst gemacht hättest, damit du nur 
ja keine böse Dependency hast für die die verantwortlich bist, hättest 
du das natürlich fehlerfrei implementiert.

Wenn man eine Funktionalität braucht, hat man genau zwei Möglichkeiten:
1) Man programmiert es selbst.
2) Man nutzt Libs, die auch von anderen genutzt werden.

Jetzt rate mal, wo im Schnitt mehr Bugs drin sind.

von cppbert (Gast)


Lesenswert?

mh schrieb:
> Ich weiß nicht wie es dir geht, aber immer wenn ich von so etwas wie
> heartbleed erfahre, frage ich mich "wie kann sowas nicht vorher
> auffallen?".
> Ich sage nicht, dass mir der Bug aufgefallen wäre, aber ich wäre für die
> möglichen Folgen dieses Bugs in meiner Software verantwortlich und
> niemand sonst. (Ich habe openssl nicht als Abhängigkeit)

falls du die Abhängigkeit gehabt hättest wäre dir der heartbleed beim 
Review der neueren Version sicherlich aufgefallen, oder?

mh schrieb:
>> Ich sage nur das eine bessere Kulturentwicklung die von einem einfachem
>> System begünstigt wird sich schlussendlich auszahlen wird und der
>> einzelne Entwickler einfach nicht immer direkt einer von den sehr guten
>> sein muss damit auch gut läuft - btw: ich arbeite viel im Medizinbereich
>> - Auditierung usw. ich weiss ganz genau was Qualität bedeutet - speziell
>> in Projekten wo dir die FDA u.a. oder anderen den Vetrieb verbieten
>> können :)
> Und ihr überprüft nicht bei jedem Update, ob die Abhängikeiten noch in
> Ordnung sind? Für wen genau arbeitest du?

wie kommst du darauf? ohne automatisch erzwungenes Review durch einen 
Team Kollegen bekomme ich keinen Zeile in den Vor-Main, und in den Main 
kommen die erst wenn alle Tests durch sind - mit ca. 70-80% Abdeckung, 
ASAN, TSAN, Coverity, die ganze Buzzword-Kette - ist manchmal sehr 
anstrengend aber richtig übel wird es wenn du an gesharten Libs 
arbeitest oder Architektur-Änderungen machen willst :)

von cppbert (Gast)


Lesenswert?

cppbert schrieb:
> wie kommst du darauf? ohne automatisch erzwungenes Review durch einen
> Team Kollegen bekomme ich keinen Zeile in den Vor-Main, und in den Main
> kommen die erst wenn alle Tests durch sind - mit ca. 70-80% Abdeckung,
> ASAN, TSAN, Coverity, die ganze Buzzword-Kette - ist manchmal sehr
> anstrengend aber richtig übel wird es wenn du an gesharten Libs
> arbeitest oder Architektur-Änderungen machen willst :)

bei >100 Entwicklern und weit weit >1Mio LOC

von cppbert (Gast)


Lesenswert?

und ja "Rust would’ve prevented Heartbleed" : 
https://tonyarcieri.com/would-rust-have-prevented-heartbleed-another-look

Rust would’ve prevented Heartbleed, but Heartbleed is actually kind of 
boring compared to remote code execution vulnerabilities like Winshock 
or openssl-too-open. Remote code execution vulnerabilities are far 
scarier, and largely preventable in Rust due to its memory safety.

aber es gibt trotzdem noch genug andere Sache die Rust nicht verhindern 
kann

ist aber auch von 2015, keine Ahnung ob sich die Situation weiter 
verbessert hat

von mh (Gast)


Lesenswert?

MaWin schrieb:
> mh schrieb:
>> Ich sage nicht, dass mir der Bug aufgefallen wäre, aber ich wäre für die
>> möglichen Folgen dieses Bugs in meiner Software verantwortlich und
>> niemand sonst. (Ich habe openssl nicht als Abhängigkeit)
>
> Und wenn du die TLS-Implementierung selbst gemacht hättest, damit du nur
> ja keine böse Dependency hast für die die verantwortlich bist, hättest
> du das natürlich fehlerfrei implementiert.
Wo habe ich geschrieben, dass Dependencies böse sind? Wo habe ich auch 
nur angedeutet, dass ich TLS fehlerfrei implementiert hätte? Was genau 
wolltest du mit dem Satz genau sagen? Oder wolltest du mir einfach etwas 
unterstellen?

MaWin schrieb:
> Wenn man eine Funktionalität braucht, hat man genau zwei Möglichkeiten:
> 1) Man programmiert es selbst.
> 2) Man nutzt Libs, die auch von anderen genutzt werden.
Die beiden Alternativen sind meiner Meinung nach unvollständig.
1. Man entwickelt es selbst. Dazu gehört ein unabhängiges Review.
2. Man nutzt eine extern entwickelte Lösung und führt das Review selbst 
durch.
Wie gründlich das Review ist, ist situationsabhängig.

MaWin schrieb:
> Jetzt rate mal, wo im Schnitt mehr Bugs drin sind.
Du hast sicher ein paar passende Studien zur Hand, die diese Frage 
beantworten?



cppbert schrieb:
> mh schrieb:
>> Ich weiß nicht wie es dir geht, aber immer wenn ich von so etwas wie
>> heartbleed erfahre, frage ich mich "wie kann sowas nicht vorher
>> auffallen?".
>> Ich sage nicht, dass mir der Bug aufgefallen wäre, aber ich wäre für die
>> möglichen Folgen dieses Bugs in meiner Software verantwortlich und
>> niemand sonst. (Ich habe openssl nicht als Abhängigkeit)
>
> falls du die Abhängigkeit gehabt hättest wäre dir der heartbleed beim
> Review der neueren Version sicherlich aufgefallen, oder?
Warum wollt ihr mir unbedingt unfehlbarkeit unterstellen?

cppbert schrieb:
> wie kommst du darauf? ohne automatisch erzwungenes Review durch einen
> Team Kollegen bekomme ich keinen Zeile in den Vor-Main, und in den Main
> kommen die erst wenn alle Tests durch sind - mit ca. 70-80% Abdeckung,
> ASAN, TSAN, Coverity, die ganze Buzzword-Kette - ist manchmal sehr
> anstrengend aber richtig übel wird es wenn du an gesharten Libs
> arbeitest oder Architektur-Änderungen machen willst :)
Warum muss dein Code ein Review durch einen Kollegen überstehen, und die 
Abhängigkeiten nicht?

cppbert schrieb:
> und ja "Rust would’ve prevented Heartbleed"
und ja "FORTRAN would've prevented Heartbleed"

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Wo habe ich geschrieben, dass Dependencies böse sind? Wo habe ich auch
> nur angedeutet, dass ich TLS fehlerfrei implementiert hätte? Was genau
> wolltest du mit dem Satz genau sagen? Oder wolltest du mir einfach etwas
> unterstellen?

Und warum hast du es dann geschrieben?

von cppbert (Gast)


Lesenswert?

mh schrieb:
> Warum muss dein Code ein Review durch einen Kollegen überstehen, und die
> Abhängigkeiten nicht?

Abhängigkeiten natürlich auch, die sogar noch intensiver weil der 
Prozess der Entwicklung da ja nicht so gut nachvollziehbar ist

aber wie auch bei Rust Cargo kommen die nicht einfach plötzlich sondern 
man entscheidet sich für eine Versionsänderung - und beginnt dann den 
Upgrade-Prozess - der ein Weilchen dauern kann - das gilt für 
3rd-Parties wie auch für das Entwicklungs/Laufzeitsystem und die 
verwendeten Kompiler

von cppbert (Gast)


Lesenswert?

cppbert schrieb:
> und beginnt dann den
> Upgrade-Prozess - der ein Weilchen dauern kann

d.h. alle Änderungen so weit wie möglich nachvollziehen, was bei manchen 
3rd-Parties aber Aufgrund der Größe auch schwer sein kann (z.B. 
CAD-Kernel usw. - auch wenn mit Source Code kann ich da nicht durch alle 
6000 Code-Änderungen durch, weil ich die Architektur der Lib nicht 
wirklich intensiv kenne und deswegen nicht die Fehler-Relevanz von Fixes 
oder Änderungen beurteilen kann) dann Branchen und alle 
Tests-Durchlaufen, manuelle und System-Tests, der Rest ist Hoffnung

von MaWin (Gast)


Lesenswert?

Was macht ihr eigentlich so für Software, wenn ihr jede Dependency Zeile 
für Zeile reviewen müsst?

Ariane 5?
Steuerung der ISS?
Falcon 9?

Das ist völlig weltfremdes Gelaber.
Niemand macht das.
Und es ist allgemein auch gar nicht notwendig. Nur vielleicht im 
Einzelfall, wenn es eine obskure Lib ist, die sonst niemand verwendet 
oder ähnliches.
Aber allgemein ist das völliger Quatsch.
Unittests, Systemtests, und gut ist.

von mh (Gast)


Lesenswert?

MaWin schrieb:
> mh schrieb:
>> Wo habe ich geschrieben, dass Dependencies böse sind? Wo habe ich auch
>> nur angedeutet, dass ich TLS fehlerfrei implementiert hätte? Was genau
>> wolltest du mit dem Satz genau sagen? Oder wolltest du mir einfach etwas
>> unterstellen?
>
> Und warum hast du es dann geschrieben?
Was habe ich wo geschrieben?

cppbert schrieb:
> mh schrieb:
>> Warum muss dein Code ein Review durch einen Kollegen überstehen, und die
>> Abhängigkeiten nicht?
>
> Abhängigkeiten natürlich auch, die sogar noch intensiver weil der
> Prozess der Entwicklung da ja nicht so gut nachvollziehbar ist
>
> aber wie auch bei Rust Cargo kommen die nicht einfach plötzlich sondern
> man entscheidet sich für eine Versionsänderung - und beginnt dann den
> Upgrade-Prozess - der ein Weilchen dauern kann - das gilt für
> 3rd-Parties wie auch für das Entwicklungs/Laufzeitsystem und die
> verwendeten Kompiler
Wieso ist dann der Pflegeaufwand für Abhängikeiten aus dem cargo 
geringer, als für eine selbst entwickelte Lösung? Wenn ihr ein Review 
macht, müsst ihr ja die Kompetenz besitzen, die Software selbst zu 
pflegen. Und die Zahl der Änderungen sollte bei der eigenen Lösung 
geringer sein, da nur eure Anforderungen erfüllt werden müssen.

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Was habe ich wo geschrieben?

Das:

>Die Community ist aber nicht für die Software verantwortlich, die ich
>meinem Kunden verkaufe. Wir drehen uns im Kreis.
>Ich weiß nicht wie es dir geht, aber immer wenn ich von so etwas wie
>heartbleed erfahre, frage ich mich "wie kann sowas nicht vorher
>auffallen?".
>Ich sage nicht, dass mir der Bug aufgefallen wäre, aber ich wäre für die
>möglichen Folgen dieses Bugs in meiner Software verantwortlich und
>niemand sonst. (Ich habe openssl nicht als Abhängigkeit)

Warum hast du das geschrieben, wenn es doch keine Aussage hat?

Ja, du musst für deine Software haften.
Und?
Du hast die Möglichkeit sie selbst zu schreiben, oder gut getestete und 
verbreitete Softwaremodule zu verwenden.
Deine Entscheidung.


Du beherrschst es sehr gut eine Diskussion entgleisen zu lassen, indem 
du ständig die Richtung änderst.

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Wieso ist dann der Pflegeaufwand für Abhängikeiten aus dem cargo
> geringer, als für eine selbst entwickelte Lösung? Wenn ihr ein Review
> macht, müsst ihr ja die Kompetenz besitzen, die Software selbst zu
> pflegen.

Weil man es nicht selbst schreiben muss?
Weil man eben nicht zwangsweise ein volles Review machen muss?
Weil man es eben nicht zwangsweise vollständig testen muss?
Weil es weniger wahrscheinlich Bugs enthält, wenn es auf millionen 
anderer Kisten bereits läuft?

etc, etc...

von mh (Gast)


Lesenswert?

MaWin schrieb:
> [...]
So lange du weiter unvollständig und/oder falsch zitierst diskutiere ich 
nicht weiter mit dir.

Auch wenn ich weiter mit dir Diskutieren wollte, ist es nicht mehr 
möglich, da
1
formerror_too_many_quoted_lines

von MaWin (Gast)


Lesenswert?

mh schrieb:
> So lange du weiter unvollständig und/oder falsch zitierst

Ach. Was war denn unvollständig?
Deine Nebelkerzen kannst du dir sparen.

von cppbert (Gast)


Lesenswert?

mh schrieb:
>> aber wie auch bei Rust Cargo kommen die nicht einfach plötzlich sondern
>> man entscheidet sich für eine Versionsänderung - und beginnt dann den
>> Upgrade-Prozess - der ein Weilchen dauern kann - das gilt für
>> 3rd-Parties wie auch für das Entwicklungs/Laufzeitsystem und die
>> verwendeten Kompiler

> Wieso ist dann der Pflegeaufwand für Abhängikeiten aus dem cargo
> geringer, als für eine selbst entwickelte Lösung?

für die professionelle Entwicklung ist der Prüfungsaufwand exakt gleich 
groß - kommt eben darauf an wie wichtig es ist, wer anders behauptet 
versteht es nicht oder meint was anderes (z.B. einfacheres deployment)

aber für Mio Standard-Anwender wird das ganze deployment trivial, man 
braucht keine 10 Buildsysteme mehr verstehen - wenn du als Selbständiger 
viele Firmen durchwanderst wärst du schockiert wie viel Aufwand da 
investiert wird der beim Wechsel in eine andere Firma gerade wieder 
verpufft, bei Java und .Net ist z.B. die Effekt sehr klein - alle 
sprechen fast die gleiche Sprache/Tools

> Wenn ihr ein Review
> macht, müsst ihr ja die Kompetenz besitzen, die Software selbst zu
> pflegen. Und die Zahl der Änderungen sollte bei der eigenen Lösung
> geringer sein, da nur eure Anforderungen erfüllt werden müssen.

das Konzept funktioniert nur so lange deine 3rd-Parties trivial sind 
weil du es dir in deinem Projekt leisten kannst, z.B. ist es recht 
sinnfrei mit einem Embedded-Entwickler von 64Kb Platformen über die 
Komplexität von Library-Abhängigkeiten zu diskutieren - er hat nämlich 
fast nie welche

genau so sinnlos ist die Argumentation wenn z.B. genannte OpenSSL zum 
Einsatz kommt, der schiere Umfang der Lib erschwert ein 
Initiales-Review, und jeder der das anders verkaufen will redet Müll 
oder braucht die eben doch nicht wirklich

In einem Projekt hatten wir einen CAD-Kernel im Einsatz - mit 
Quelltext-Lizenz, der war riesig und hat einen Haufen-Spezialfeatures 
gehabt von denen wir ~60% genutzt haben (für 1% der 
Software-Funktionalität), alles pure Mathematik mit ohne Ende 
Spezialfällen, Sau teuer, aber sehr gute Ergebnisse, nicht das ich Angst 
vor Mathe habe, aber es ist eben was anderes ob das dein Primärfeld ist 
oder nur Randgebiet in deiner Software

von cppbert (Gast)


Lesenswert?

cppbert schrieb:
> alles pure Mathematik mit ohne Ende
> Spezialfällen, Sau teuer, aber sehr gute Ergebnisse, nicht das ich Angst
> vor Mathe habe, aber es ist eben was anderes ob das dein Primärfeld ist
> oder nur Randgebiet in deiner Software

und ja bei dem Kunden gab es viele Mathematiker die das gekonnt hätte - 
aber die haben auch anderen Aufgaben als zig-tausend Euro Zukaufsoftware 
zu reviewen - bei manchen Projekten oder auch Verantwortlichen bekommt 
man so was durch oder es wird auch gefordert aber eben nicht einfach so 
überall

von Olaf (Gast)


Lesenswert?

> Das ist völlig weltfremdes Gelaber.
> Niemand macht das.

Jeder der SIL2 Software macht. Und ab SIL3 machst das nicht du sondern 
ein unabhaengiger Dritter.

Olaf

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Na, war ja gut was los hier in der Zwischenzeit...

MaWin schrieb:
>> dann sagen mir autotools und cmake VORHER, was sie
>> beoetigen.
>
> cargo check

Wow - ich bin ja zutiefst impraegniert. Hat jetzt nichtmal 1h gedauert 
...
Ja, der Rechner ist keine Rakete, aber - hey - ich will einen einzelnen 
Videocodec bauen, kein ganzes ffmpeg, kein ganzes GNU-Octave, keinen 
Browser, kein komplettes X11R6 mit make world... und auch kein KiCad mit 
Furz und Feuerzeug. Nein, 1 (i.W. ein) Videocodec.
1
root [ /usr/src/rav1e-0.4.0 ]# cargo check
2
   Compiling autocfg v1.0.1
3
   Compiling libc v0.2.82
4
   Compiling const_fn v0.4.5
5
    Checking lazy_static v1.4.0
6
   Compiling proc-macro2 v1.0.24
7
   Compiling rayon-core v1.9.0
8
    Checking cfg-if v1.0.0
9
   Compiling memchr v2.3.4
10
   Compiling unicode-xid v0.2.1
11
   Compiling syn v1.0.58
12
   Compiling scopeguard v1.1.0
13
   Compiling bitflags v1.2.1
14
   Compiling ucd-trie v0.1.3
15
   Compiling either v1.6.1
16
   Compiling regex-syntax v0.6.22
17
   Compiling log v0.4.13
18
    Checking unicode-width v0.1.8
19
   Compiling arrayvec v0.5.2
20
    Checking cfg-if v0.1.10
21
   Compiling signal-hook v0.3.3
22
   Compiling noop_proc_macro v0.3.0
23
   Compiling rust_hawktracer_proc_macro v0.4.1
24
    Checking lab v0.8.2
25
    Checking bitstream-io v1.0.0
26
    Checking rust_hawktracer_normal_macro v0.4.1
27
    Checking scan_fmt v0.2.5
28
   Compiling paste v1.0.4
29
    Checking y4m v0.7.0
30
   Compiling crossbeam-utils v0.8.1
31
   Compiling memoffset v0.6.1
32
   Compiling num-traits v0.2.14
33
   Compiling num-integer v0.1.44
34
   Compiling rayon v1.5.0
35
    Checking thread_local v1.1.0
36
   Compiling pest v2.1.3
37
    Checking itertools v0.10.0
38
    Checking textwrap v0.11.0
39
    Checking ivf v0.1.1 (/usr/src/rav1e-0.4.0/ivf)
40
    Checking rust_hawktracer v0.7.0
41
   Compiling semver-parser v0.10.2
42
   Compiling time v0.1.43
43
   Compiling num_cpus v1.13.0
44
   Compiling jobserver v0.1.21
45
    Checking terminal_size v0.1.15
46
    Checking signal-hook-registry v1.3.0
47
   Compiling quote v1.0.8
48
   Compiling aho-corasick v0.7.15
49
    Checking clap v2.33.3
50
   Compiling semver v0.11.0
51
    Checking fern v0.6.0
52
    Checking crossbeam-channel v0.5.0
53
    Checking crossbeam-queue v0.3.1
54
   Compiling crossbeam-epoch v0.9.1
55
   Compiling cc v1.0.66
56
   Compiling simd_helpers v0.1.0
57
   Compiling regex v1.4.3
58
   Compiling rustc_version v0.3.2
59
   Compiling crossbeam-deque v0.8.0
60
   Compiling chrono v0.4.19
61
   Compiling thiserror-impl v1.0.23
62
   Compiling num-derive v0.3.3
63
   Compiling arg_enum_proc_macro v0.3.0
64
    Checking console v0.14.0
65
    Checking crossbeam v0.8.0
66
   Compiling vergen v3.0.4 (/usr/src/rav1e-0.4.0/crates/vergen)
67
    Checking thiserror v1.0.23
68
    Checking v_frame v0.2.0 (/usr/src/rav1e-0.4.0/v_frame)
69
   Compiling nasm-rs v0.2.0
70
    Checking av-metrics v0.6.2
71
   Compiling rav1e v0.4.0 (/usr/src/rav1e-0.4.0)
72
error: failed to run custom build command for `rav1e v0.4.0 (/usr/src/rav1e-0.4.0)`
73
74
Caused by:
75
  process didn't exit successfully: `/usr/src/rav1e-0.4.0/target/debug/build/rav1e-6cc129c8c67eccb3/build-script-build` (exit code: 1)
76
--- stderr
77
rav1e requires rustc >= 1.44.1.

Mal gucken, wann/wie ich weiterstuempere...

Gruss
WK

von MaWin (Gast)


Lesenswert?

Olaf schrieb:
> Jeder der SIL2 Software macht. Und ab SIL3 machst das nicht du sondern
> ein unabhaengiger Dritter.

Ja genau. Richtig.
Du hast den Sonderfall gefunden.
Bravo.
Es geht hier um Rust und Cargo.
Wie viel *SILxy SW davon nutzt denn crates.io?

Richtig. Keine. Denn wie du ja schon selbst sagtest, braucht man da die 
100%ige Kontrolle über seine Deps. Deshalb nutzt man lokale crates.

Wo war jetzt noch gleich das Problem?

von cppbert (Gast)


Lesenswert?

Dergute W. schrieb:
> Wow - ich bin ja zutiefst impraegniert. Hat jetzt nichtmal 1h gedauert

Rust ist scheisse langsam zu bauen - das ist mehr als bekannt - liegt 
aber nicht am Sprachendesign sondern dem Frontend was dem LLVM zu viel 
IR Code hinschmeisst den er dann Ewig optimieren muss

Buildzeiten schlechter als C++ sind nicht selten - jedem bekannt
trotzdem ändert das nichts daran das es ein relativ gutes Sprachendesign 
ist mit gute Ansätze/Anleihen für Infrastruktur-Tools

von MaWin (Gast)


Lesenswert?

Dergute W. schrieb:
>> cargo check
>
> Wow - ich bin ja zutiefst impraegniert. Hat jetzt nichtmal 1h gedauert

Ja genau.
Es hat auch keine 3 Tage und keine 3 Wochen gedauert.
Sondern wenige Minuten.
1
rav1e-0.4.0$ time cargo check 
2
  Downloaded jobserver v0.1.21     
3
  Downloaded noop_proc_macro v0.3.0
4
  Downloaded nasm-rs v0.2.0    
5
  Downloaded crossbeam v0.8.0   
6
  Downloaded arg_enum_proc_macro v0.3.0
7
...               
8
real    2m43.530s          
9
user    9m35.788s        
10
sys     0m15.025s

Auf einem 8 Jahre alten Laptop.

Der Rustcompiler ist nicht schnell.
Das ist bekannt.
Aber bitte höre auf zu lügen.

von mh (Gast)


Lesenswert?

Dergute W. schrieb:
> Mal gucken, wann/wie ich weiterstuempere...

Ich hab das eben auch mal probiert. Ich kann nichts dazu sagen, ob das 
1h dauert oder nicht, da es nach 20 Sekunden mit einer kryptischen 
Fehlermeldung abgebrochen ist. Das sah so aus als wäre der strerror Text 
für eine fehlende Datei direkt an den Nutzer weitergegeben worden, ohne 
zu erwähnen welche Datei fehlt. Sehr hilfreich ...

von Dergute W. (derguteweka)


Lesenswert?

Moin,

MaWin schrieb:
> Aber bitte höre auf zu lügen.
Bitte hoere auf, mir Luegen zu unterstellen; ich schrub' ja, der Rechner 
ist keine Rakete (Auch Laptop, aber deutlich aelter als deiner).
Es waere mir ja anundpfirsich auch wurscht, wenn er ein paar Tage vor 
sich hinwerkelt und Gigabyteweise irgendwelchen mumpitz runterlaed', 
wenn danach was sinnvolles rausgekommen waere und nicht so eine 
bekloppte Meldung.

Aber ich kann eben doch auch auf dieser alten Maschin' 
Buildgeschwindigkeit, -Komfort des Buildsystems, etc. in Relation zu 
diverser anderer Software setzen, die ich da gebaut habe.
Wenn ich jetzt mal hier nachschau':
https://github.com/xiph/rav1e/commit/c6a2d69a99c79763da3545e8b0f410c488cad98e

und da les' ich was wie:
 "Bump minimum version to 1.44.1
This is needed to avoid a rustc bug that existed in 1.43,
which was tripped by the updated version of semver-parser."

Und ihr wollt mir hier einen von gutem Sprachdesign, und guten Ansaetzen 
von Infrastruktur-Tools und toller Versionierung und Sicherheit 
erzaehlen.
Da kram' ich nochmal meinen schiefen Vergleich mit dem Kommunismus raus:
Ich, der dumme Werktaetige (kein Informatiker), will einfach nur mal 'ne 
Banane(Videocodec) essen(kompilieren). Sind aber halt in der Zone grad 
aus.
Deshalb sagen die Jungs frisch von der Kaderschmiede, ich soll mich mal 
nicht so anstellen; die Bananen, die der Klassenfeind im Westen(C, 
"alte" Buildsysteme") frisst, waeren ja eh' nix genaues, und wenn der 
Kommunismus den Kapitalismus erst ueberrundet hat, dann gibts hier viel 
groessere, gelbere und bananigere Bananen mit viel besseren 
Versionsnummern.
Jaja, schon klar... ;-)

SCNR,
WK

von cppbert3 (Gast)


Lesenswert?

Dergute W. schrieb:
> und da les' ich was wie:
>  "Bump minimum version to 1.44.1
> This is needed to avoid a rustc bug that existed in 1.43,
> which was tripped by the updated version of semver-parser."
>
> Und ihr wollt mir hier einen von gutem Sprachdesign, und guten Ansaetzen
> von Infrastruktur-Tools und toller Versionierung und Sicherheit
> erzaehlen.

Es sagt niemand das irgendwas davon perfekt ausgereift und fehlerfrei 
ist, keine Ahnung warum du dich überhaupt nur im entfernesten daran 
störst? Ignorier einfach Rust und gut ist und falls deine Liblingslib 
oder App plötzlich eine Dependency dazu hat ist der Autor davon eben 
jetzt auch nicht mehr ganz so frisch im Kopf

von MaWin (Gast)


Lesenswert?

Dergute W. schrieb:
> ich schrub' ja, der Rechner
> ist keine Rakete (Auch Laptop, aber deutlich aelter als deiner).

Auf einer PDP-11 läuft Rust übrigens auch nicht.

Dergute W. schrieb:
> Und ihr wollt mir hier einen von gutem Sprachdesign, und guten Ansaetzen
> von Infrastruktur-Tools und toller Versionierung und Sicherheit
> erzaehlen.

Blabla. Dummes Gelaber.
Es hat einen Fehler gegeben. Und?
In $anderer_compiler hat es schließlich noch nie Fehler gegeben.

In der Zeit, die du hier herumpalavert hast, hättest du lange "rustup 
update" ausführen können und nach 10 Minuten hättest du ein modernes 
Rust gehabt, das dein Projekt bauen kann.

Aber daran bist du ja gar nicht interessiert.
Du willst ja lieber hier stänkern.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin schrieb:
> Wenn man eine Funktionalität braucht, hat man genau zwei Möglichkeiten:
> 1) Man programmiert es selbst.
> 2) Man nutzt Libs, die auch von anderen genutzt werden.

Es sagt ja niemand, dass man gar keine externen Libraries brauchen darf. 
Es geht darum, die Abhängigkeiten sinnvoll und gering zu halten.

Aber wenn es etwas gibt, das man braucht, aber nicht wirklich will? Man 
vergesse nicht Option 3!

3) Eine Abstraktionsschicht. Die Abhängigkeit in ein anderes Programm 
oder Backend auslagern / abtrennen, genutzt über ein möglichst simples 
Interface. Das macht das Hilfsprogram / Backend einfach zu ersetzen und 
erlaubt alternative und/oder unabhängige Implementationen!

Ich mache das recht oft. Es ist nicht immer einfach umzusetzen, und es 
kann schwierig sein, zu entscheiden, wo man den Schnitt macht. Auch ich 
bin da nicht perfekt. Die Abhängigkeit geht oft auch nicht ganz weg, 
aber statt total von der einen Sache abhängig zu sein, kann man mehrere 
Implementationen haben, und diese einfach ersetzen, oder je nachdem was 
es ist auch mehrere nutzen. Notfalls muss man auch nicht das halbe 
Programm neu schreiben, wenn man es ersetzen muss.

Beispiele von mir:

0) In einem Report Generator in nodejs, den ich mal schrieb, brauchte 
ich was um SVGs nach PNGs zu konvertieren (für email). Die bestehenden 
Implementationen gefielen mir aber alle nicht. Ich habe dann trotzdem 
eine genommen, ich bin ja nicht wahnsinnig, aber nicht direkt verwendet. 
Es gibt nur eine Datei mit einer einzigen exportierten Funktion, 
"svg_to_png", die die library nutzt. Alles andere nutzt die Funktion, 
und nicht die lib direkt. Austauschen wäre also simpel.

1) Mein Window Manager brauchte eine Appübersicht/homescreen/dashboard, 
wie auch immer man es nennen mag. Sowas will ich nicht ohne Gui Toolkit 
machen. Im Window Manager will ich aber von keinem Gui Toolkit abhängig 
sein. Ich hab das dann in eine andere Anwendung ausgelagert, die nur die 
Appübersicht anzeigt, und von der WM per xembed eingebunden wird. Wobei 
ich das Anzeigen nochmal in eine andere Anwendung ausgelagert habe. Also 
WM xembed <- dashboard <-> ui-grid
Die WM ist c, das dashboard ist ein simples bash script, und das ui-grid 
ist python3 + pyqt: 
https://github.com/Daniel-Abrecht/ui-grid/blob/master/ui-grid 
https://github.com/Daniel-Abrecht/dpaw/blob/master/tools/dpaw-dashboard 
https://github.com/Daniel-Abrecht/dpaw/blob/38a72f273951c1185598337f6c67288daaa340a8/wm/src/dpawindow/workspace/handheld.c#L299

2) Meine tty multiplexer library hat ein Backend für Ausgaben über 
curses: 
https://github.com/Daniel-Abrecht/libttymultiplex/blob/master/backend/curses/src/main.c#L397 
Eigentlich wollte ich noch ein tty, ein fbdev, ein KMS, etc. backends 
machen, bin aber nie dazu gekommen. Das interface da ist auch nicht 
besonders gut, libttymultiplex ist zwar von den Backends unabhängig, 
aber die backends nicht von libttymultiplex...

3) Mein console-keyboard-multiplexer (zeigt ein Keyboard unten in der 
Konsole an) und mein console-keyboard-basic (das angezeigte Keyboard) 
haben keine direkte Abhängigkeit.

4) Mein ACME2 challange solver trennt den generischen ACME2 part und den 
solver part. Der Solver ist ein separates Program. (packaging und 
verschieben des dns01 solvers in separates Repo noch ausstehend, 
hauptcode ist aber bereits davon voll unabhängig): 
https://github.com/Daniel-Abrecht/DPA-ACME2

Ich hatte noch mehr Zeugs, auch in anderen Sprachen, aber ich glaube das 
sind genug Beispiele.


Ich bin natürlich nicht der Einzige, der das macht:

1&2) Das SDL Grafikframework  und QT haben etliche Backends für alles 
mögliche, sei es X11, KMS, fbdev, für Grafik, pulse oder also für sound, 
xinput oder libinput für IO, etc.

3) Die gnome-chatty app nutzt libpurple plugins als backends, genauso 
wie glaube ich pidgin (ich glaube von dort kommt es ursprünglich)

4) gnome-calls hat modemmanager und ofono backends

5) X11 hat die DIX. Heutzutage abstrahiert da zwar mesa & gbm fast 
alles, so das nur noch die modesetting DIX benötigt wird, aber NVIDIA 
und ein paar andere querulanten kochen noch ihr eigenes Süppchen


Zudem sollte man auch die Möglichkeit optionaler runtime & compiletime 
Dependencies nicht vergessen.


Ich denke an all dem sieht man schön, dass nicht alle Abhängigkeiten 
immer gleich stark abhängig machen müssen. Es gibt weichere und härtere 
Abhängigkeiten, stärker integrierte und besser segregierte, ersetzbare 
und unersetzbare, etc.

von cppbert3 (Gast)


Lesenswert?

Abstraktion ist natürlich wichtig, hier geht es aber gerade, um es in 
deinen Worten zu sagen, eine konkrete Implementierung und den Probleme 
die mit einem Versionswechsel bei einer 3rdParty Lib einhergehen

von cppbert (Gast)


Lesenswert?

cppbert3 schrieb:
> Abstraktion ist natürlich wichtig, hier geht es aber gerade, um es
> in
> deinen Worten zu sagen, eine konkrete Implementierung und den Probleme
> die mit einem Versionswechsel bei einer 3rdParty Lib einhergehen

oder besser - natürlich sollte(oder muss) man eine Abstraktion haben (um 
die Features zu erhalten die du aufzeigst) aber das war hier definitiv 
gar nicht das Thema :)

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Um wieder den Link zu Cargo zu machen, in wieweit sind diese Art von 
Abhängigkeiten - also optionale Backends - damit abbildbar?

In debian / apt kann man sagen Packet X bietet Y, Paket Z braucht Y, und 
man kann sagen welche Implementation man bevorzugt (als Z braucht X oder 
ein Y, wobei apt dann zuerst Z versucht, falls noch kein Y vorhanden 
oder mitangegeben). Man beachte, Z braucht nichts von X oder anderen Y 
zu wissen, es wird es beim Kompilieren nicht gebraucht, es geht um 
runtime dependencies.

Wie gut kann man mit Cargo sowas abbilden? Ist das überhaupt im scope 
von Cargo, oder hilft einem das nur mit direkten compile time 
Abhängigkeiten?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Edit: müsste heissen: wobei apt dann zuerst X versucht (nicht Z)

von S. R. (svenska)


Lesenswert?

Ich finde es interessant, wie die Cargo-Proponenten dafür trommeln, dass 
man
(a) ausschließlich die neuesten Versionen nutzt;
(b) keine Code-Reviews macht, sondern automatisiert testet;
(c) sich auch bei hunderten von Abhängigkeiten mal nicht so anstellen 
soll;
(d) verschwinden soll, wenn's einem nicht passt.

Jedes dieser Argumente hat seine Berechtigung, aber eben auch Schwächen. 
Die hier mal ganz elegant wegerklärt werden.

Das Sahnehäubchen ist noch, dass das natürlich auch für die Toolchain 
selbst zutrifft.

Achso, und dass vorausgesetzt wird, dass Version 1.2.4 strikt besser ist 
als Version 1.2.3, garantiert und ohne jede Ausnahme - man verlässt sich 
schließlich darauf.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> ist das überhaupt im scope von Cargo

Naja, die ganzen Alternativen-Automatismen von apt hat cargo wohl eher 
nicht.
Und ich wüsste auch nicht wozu.

Mit cargo baut man eine Applikation und die dependencies. Und das lässt 
sich über Features konfigurieren. Wenn du jetzt gerne eine andere Dep 
verwenden würdest, musst du das Feature selektieren.

Es steht ja jedem frei hier apt drüberzustülpen und diese ganze 
Dependency-Magie  zu bauen.

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> Ich finde es interessant, wie die Cargo-Proponenten dafür trommeln, dass
> man
> (a) ausschließlich die neuesten Versionen nutzt;

Ich denke das hat niemand gesagt.
Ich jedenfalls nicht.

Ganz im Gegenteil wurde ja aufgezeigt, dass man mehrere Möglichkeiten 
hat. Man pinnt eine Version oder man nutzt halt semantic versioning.
Es gibt viele Arten die Dependency-Versionen festzulegen.
Einfach mal die Cargo Doku lesen.

> (b) keine Code-Reviews macht, sondern automatisiert testet;

Das ist jetzt aber stark verkürzt zitiert.
Es geht darum, dass man eher keine Reviews der Dependencies macht, 
weil die ja schon ein Review und eine Qualitätsfreigabe vom Autor haben.

> (c) sich auch bei hunderten von Abhängigkeiten mal nicht so anstellen
> soll;

Wer hat das gesagt?

> (d) verschwinden soll, wenn's einem nicht passt.

Stänkere bitte woanders herum.

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

Packet-Manager und die Probleme/Vorteile, die man sich damit einhandelt 
sind ja wohl kein Alleinstellungsmerkmal von Rust.

Die fehlende Ahnung vom
- Konzept einer Versionsverwaltung
- Open Source Arbeit und
- Öffentliches Packet-Repository
und
- alte Rechner
- falsche Bedienung
- noch nicht mal das richtige Log posten, damit einem geholfen werden 
kann ... bei einem Problem in ... einem von tausenden Paketen ... in 
einem Thread wo das vollkommen off-topic ist

sind absolute dämliche Argumente.

Ja es sind immer die Anderen schuld. Besonders die Leute, die einem 
freiwillig und ungefragt ihre Arbeitsstunden in Form von 
funktionierenden Bibliotheken zur Verfügung stellen.
Entweder selber machen oder nutzen. Oder vielleicht selbst zum Projekt 
beitragen? Das mag ein Diskussionsthema sein, aber zuerst einmal ist das 
eine Frage des Charakters.

Zu Cargo: Niemand wird gezwungen Cargo zu benutzen um mit Rust zu 
arbeiten!
Das ist zwar totaler Blödsinn, so "frei wie ein Vogel" zu arbeiten, aber 
wahr und möglich. Das gilt auch für Conan, dub, npm, leinen, nuget, 
etc., pp. Wer die Anforderung hat mit absolut strikten und lokalen 
Abhängigkeiten zu arbeiten kann das tun. Dazu muss man nur die Scheiß 
Anleitung lesen.
Sorry für den Kraftausdruck.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin schrieb:
> 🐧 DPA 🐧 schrieb:
>> ist das überhaupt im scope von Cargo
>
> Naja, die ganzen Alternativen-Automatismen von apt hat cargo wohl eher
> nicht.
> Und ich wüsste auch nicht wozu.
>
> Mit cargo baut man eine Applikation und die dependencies. Und das lässt
> sich über Features konfigurieren. Wenn du jetzt gerne eine andere Dep
> verwenden würdest, musst du das Feature selektieren.

Und du hinterfragst nicht, ob das eine gute Sache ist, oder was für 
Auswirkungen auf die resultierende Software das hat?

Diese Limitation wird auch direkt negative Netzwerkeffekte nach sich 
ziehen.
Es werden alle Anwendungen, die aus vielen unabhängigen Anwendungen, 
bestehen, oder anderweitig komplett unabhängige Implementationen für 
gewisse Programmteile benötigen, aber kein konkretes voraussetzen, 
benachteiligt.
Eigentlich werden sogar sämmtliche reinen Runtimeabhängigkeiten 
benachteiligt.
Diese würden bei der Verwendung nämlich einen Mehraufwand bedeuten, da 
Cargo einem bei diesen Dependencies nicht weiterhilft, anders als bei 
compile time dependencies.

Im Grunde bedeutet das, dass die Praxis, alles mit compile time 
dependencies zu machen inzentiviert wird. Da hilft mir auch nicht, dass 
ich weiterhin apt dass ich selbst für einige Distros mit apt das Problem 
für meine eigenen Anwendungen lösen könnte, denn dies ist ein 
Netzwerkeffekt, also etwas, dass sich auf mit Cargo verwaltete Software 
allgemein auswirkt. Man sieht hier schön, das geht so weit, dass den 
Entwicklern schon gar nicht mehr klar ist, dass es das nicht die Einzige 
Möglichkeit ist, oder wozu unabhängige und/oder runtime-only 
Abhängigkeiten gut sein sollen.

Der Effekt, den sowas auf die Software haben dürfte, sollte eigentlich 
jedem offensichtlich sein: Weniger bis keine zur Runtime Auswählbaren, 
weglassbare oder Austauschbare Komponenten. Daraus folgt auch weniger 
Flexibilität für den Endnutzer, sowie weniger Auswahlmöglichkeiten 
allgemein. Es würde mich nicht erstaunen, wenn auch die Interoperation 
und Integration voneinander unabhängiger Programme, und damit die UX des 
Gesammtsystems, darunter leidet.


Das ständige Argument "aber theoretisch könntest du/man ja" überall 
nervt mich auch etwas. Es ist ja immer schön, was ich selbst alles 
anders machen könnte, aber deshalb ist mir nicht egal, wie sich die 
Freie Software Welt insgesamt entwickelt. Das hat dann nämlich nachher 
auch wieder direkte Folgen für mich.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Und du hinterfragst nicht, ob das eine gute Sache ist, oder was für
> Auswirkungen auf die resultierende Software das hat?
>
> Diese Limitation wird auch direkt negative Netzwerkeffekte nach sich
> ziehen.
> Es werden alle Anwendungen, die aus vielen unabhängigen Anwendungen,
> bestehen, oder anderweitig komplett unabhängige Implementationen für
> gewisse Programmteile benötigen, aber kein konkretes voraussetzen,
> benachteiligt.
> Eigentlich werden sogar sämmtliche reinen Runtimeabhängigkeiten
> benachteiligt.
> Diese würden bei der Verwendung nämlich einen Mehraufwand bedeuten, da
> Cargo einem bei diesen Dependencies nicht weiterhilft, anders als bei
> compile time dependencies.

Das ist doch kompletter Unsinn.

Mit der Argumentation wäre C/C++ noch viel eingeschränkter, weil es 
überhaupt kein Build- und Paketsystem mitbringt.

Cargo ist eine Option.
Niemand ist gezwungen Rust-Programme mit Cargo zu bauen und zu 
vertreiben.
Wenn du dein Rust-Programm mit CMake bauen willst und mit Apt vertreiben 
willst, dann ist das selbstverständlich möglich und es steht dir frei.

Davon zu sprechen, dass Cargo eine Limitation für Rust ist, ist ganz 
einfach Unsinn. Es zeigt nur auf, dass derjenige, der das behauptet, 
keine Ahnung von Rust hat.
Eine zusätzliche Option (Cargo) kann nie eine Limitation sein. Das 
schließt sich logisch einfach aus.

Lies den Text von Jedzia D.
Dort ist alles sehr schön zusammengefasst.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Hast du mein Argument überhaupt gelesen?

Ich sage nicht cargo ist eine Limitation, ich sage Cargo hat eine 
Limitation (bezüglich runtime dependencies). Ich sage sogar genau, was 
diese Limitation ist.

Auch dass man Cargo nicht verwenden muss ist nicht relevant bei 
meiner Argumentation. In der praxis wird es verwendet, und auch wenn es 
die theoretische mögichkeit gibt, es nicht zu verwenden, ist dies in 
den meisten Anwendungsfällen bei Rust nicht besonders praktikabel.

Cargo wird verwendet. Es hat Designentscheidungen, und damit wie 
jede Software auch Limitationen.

Meine Argumentation basiert darauf, dass /eine konkrete dieser 
Limitationen/, gewisse Softwarearchitekturen stärker als andere 
begünstigt, und im Umkehrschluss einige Softwarearchitekturen 
beungünstigt, welche ich aber wünschenswert finde, da sie für den 
Endbenutzer einige Vorteile (in dem konkreten Fall mehr Auswahl / 
Modularität zur runtime) bietet. Es ist ein Nebeneffekt, der durch die 
breite Nutzung des Systems und dessen Eigenheiten entsteht. Ein 
Netzwerkeffekt.


Aber ich seh schon, mit euch lässt ist nicht reden. Einfach sämtliche 
Kritik Ignorieren ("Das ist doch kompletter Unsinn"), und die Leute in 
eine Schublade packen ("müssen wohl alles rust nicht-versteher sein"), 
ist ja auch einfacher, als zu versuchen, die Kritiken & Argumente zu 
verstehen, das ganze mal von einem anderen Blickwinkel zu betrachten, 
und selbst mal darüber nachzudenken.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> und auch wenn es
> die theoretische mögichkeit gibt, es nicht zu verwenden, ist dies in
> den meisten Anwendungsfällen bei Rust nicht besonders praktikabel.

Blödsinn.
Warum soll das so sein?
Niemand zwingt dich Cargo zu verwenden.

von mh (Gast)


Lesenswert?

MaWin schrieb:
> Niemand zwingt dich Cargo zu verwenden.

Dann kannst du sicher schnell eine Beschreibung aus deinem Ärmel 
schütteln, wie man z.B. das oben genannte RAV1E ohne cargo baut?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin schrieb:
> Niemand zwingt dich Cargo zu verwenden.

Wie schon gesagt, das spielt bei meiner Argumentation oben bewusst keine 
rolle. Es genügt, dass es von so ziemlich jedem verwendet wird.

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


Lesenswert?

MaWin schrieb:
> Blödsinn.

Bitte beende diese Diskussion an dieser Stelle.

Mit deiner Art von „Argumentation“ tust du weder Rust einen Gefallen, 
noch überzeugst du damit irgendwen.

(Dies war ein „Warnschuss“ in meiner Eigenschaft als Moderator. Ich 
möchte, dass die Diskussion wieder auf ein sinnvolles Niveau kommt.)

von MaWin (Gast)


Lesenswert?

mh schrieb:
>> Niemand zwingt dich Cargo zu verwenden.
>
> Dann kannst du sicher schnell eine Beschreibung aus deinem Ärmel
> schütteln, wie man z.B. das oben genannte RAV1E ohne cargo baut?

Warum?

Schüttelst du dann eine Beschreibung aus deinem Ärmel, wie man OpenSSL 
ohne Make baut?

🐧 DPA 🐧 schrieb:
> Es genügt, dass es von so ziemlich jedem verwendet wird.

Und deshalb bist du gezwungen, es selbst auch zu verwenden?
Warum?

Jörg W. schrieb:
>> Blödsinn.
> Bitte beende diese Diskussion an dieser Stelle.

Ich behaupte hier nicht ständig Unwahrheiten.

> Mit deiner Art von „Argumentation“ tust du weder Rust einen Gefallen,
> noch überzeugst du damit irgendwen.

Ja. Zu behaupten Cargo wäre mit Rust untrennbar verbunden, tut Rust 
wirklich keinen gefallen. Weil es ganz einfach falsch ist.

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


Lesenswert?

MaWin schrieb:

> Jörg W. schrieb:
>>> Blödsinn.
>> Bitte beende diese Diskussion an dieser Stelle.
>
> Ich behaupte hier nicht ständig Unwahrheiten.

Es geht weniger um Inhalte als um deinen Diskussionsstil. Der ist 
unterirdisch, und den möchte ich in diesem Thread nicht mehr dulden.

von mh (Gast)


Lesenswert?

MaWin schrieb:
> mh schrieb:
>>> Niemand zwingt dich Cargo zu verwenden.
>>
>> Dann kannst du sicher schnell eine Beschreibung aus deinem Ärmel
>> schütteln, wie man z.B. das oben genannte RAV1E ohne cargo baut?
>
> Warum?
>
> Schüttelst du dann eine Beschreibung aus deinem Ärmel, wie man OpenSSL
> ohne Make baut?

Nö, ich habe aber auch nicht behauptet, dass man C ohne maku und co 
sinnvoll einsetzen kann. Mal davon abgesehen, dass keine der 
besprochenen cargo Features etwas mit make zu tun haben.

von MaWin (Gast)


Lesenswert?

mh schrieb:
> ich habe aber auch nicht behauptet, dass man C ohne maku und co
> sinnvoll einsetzen kann.

Das habe ich auch nicht behauptet.

Aber du hast den Zusammenhang hergestellt, dass man Rust nicht verwenden 
kann, weil irgendeine X-beliebige Dependency Cargo verwendet.

Das ist ganz einfach aus vielen Gründen falsch.
Allen voran, dass man halt die Dependency nicht verwenden muss.
Man kann eine Alternative verwenden. Oder den Code selbst neuschreiben.

Aber selbst wenn man die Dep unbedingt verwenden will, dann kann man sie 
natürlich auch mit Aufwand ohne Cargo übersetzen.

Genau wie man OpenSSL auch auf jedes andere Buildsystem umstellen kann.
Warum ist es kein Problem, wenn OpenSSL Make benutzt, und warum ist es 
ein Problem, wenn irgendeine Rust-Lib Cargo nutzt?

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
> Schüttelst du dann eine Beschreibung aus deinem Ärmel,
> wie man OpenSSL ohne Make baut?

Ein sinnvoller Vergleich wäre vielleicht mit den Autotools, CMake oder 
einem anderen Buildsystem statt mit make gewesen.

Es spielt keine Rolle, ob man theoretisch Rust auch ohne Cargo verwenden 
könnte. Solange Cargo die Basis für so ziemlich alle Rust-Projekte ist, 
das Rust-Ökosystem auf Cargo aufbaut und die Nichtverwendung von Cargo 
deutlich teurer ist als die Verwendung, ist das schlicht irrelevant.

Das ist ähnlich wie App-Entwicklung für Android und Gradle. Ja, kann man 
theoretisch auch ohne machen, praktisch ist das aber unmöglich.

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> das Rust-Ökosystem auf Cargo aufbaut

Tut es aber halt nicht.

Informiert euch halt mal, bevor ihr hier so einen (das darf ich ja nicht 
mehr schreiben) postet.

Man kann Rust z.B. auf kleinsten Microcontrollern verwenden.
Ohne Buildtime-Download.
Ohne Cargo.
Ohne stdlib.
bare metal.

Es gibt ü-ber-haupt kein Zwang zu Cargo.
Das liegt vollständig in der Gewalt des Entwicklers.

Aber die meisten benutzen es natürlich, weil es halt sehr gut ist.
Aber niemand (In Worten: Niemand) zwingt dich auch nur im Geringsten das 
alles zu nutzen.

Bei jeder beliebigen C-Lib Dependency ist das auch nicht anders.
Oder beschwerst du dich auch, dass es ja untragbar sei, dass 
Depencency-X Buildsystem Y nutzen?
Warum nicht?

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

DPA, könntest Du bitte ein konkretes Beispiel dafür liefern, was Du mit 
der von dir genannten Inflexibilität ins Sachen Runtime-Code meinst? Und 
was das wirklich mit Cargo zu tun haben soll?[4]

Cargo ist das "make" und der Paketmanager, das Test-Tool ... einfach das 
build-utility von Rust.
Im Beispiel von Dergute W mit rav1e sind einige der aufgelösten Pakete 
nötig um zusätzlich zum Code von rav1e ein spezielles Build-System[1] 
extra für diesen Spezialfall zu erschaffen. Meta, Meta, anders 
übersetzt: Extrem kompliziert und extrem flexibel.Dieses System erlaubt 
gleichzeitig einen Bootloader für PowerPC zu schreiben und mit 'cargo 
run' die ganze Chaussee in QEMU zu starten. Alles zentral, alles ganz 
einfach (natürlich nicht hinter den Kulissen)[3].
Da ist nur eine Abhängigkeit zu Cargo: Es ist die 
Eierlegendewollmilchsau, die dein rav1e baut.

Du meinst bestimmt etwas anderes aber:
1
rustup target list
erschlägt dich mit Runtimes, fehlt deine noch?[2]

Jedes Komponentensystem, dass Runtime-Code nachlädt ließe sich über 
C-Schnittstellen schnell, oder als Eigenimplementierung mit Aufwand auch 
in Rust lösen.
Die flexibilität von Cargo kannst auch Du nutzen um ein komplett neues 
Buildsystem zu erfinden. Etwa
1. Hilfs-Build-Tool wird gebaut
2. RISC-X helper/spezial-linker extra für diese Hardware-Konstellation 
wird gebaut
3. build: Applikation und Virtuelle Maschine für den internen Flash
4. build: VM-Code für das externe EEprom.
5. Spezielles Flash-Tool für diese Hardware wird gebaut
6. VM-Code in den externen Speicher laden
7. MCU flashen
8. Debugger starten
...
X. Auf die Erfindung von Risc-X warten:)

Viele Komponenten und Bibliotheken haben Schalter mit denen man das 
verhalten der Runtime beeinflussen kann. Es steht nicht unter Strafe 
selbst welche einzubauen. ([profile] und Configuration keys)[5]

Wie wäre es mit der Erzeugung und Einbindung einer Shared-Library zur 
Laufzeit? -> https://github.com/manthanrtilva/runtime_plugin
cranelift-simplejit -> Eine einfache JIT-Bibliothek, die von Cranelift 
unterstützt wird, Gruss an Alex
dynasm -> Ein Plugin zum Zusammenstellen von Code zur Laufzeit. In 
Kombination mit dem Runtime Crate Dynasmrt können damit JIT-Compiler 
einfach geschrieben werden.


Es ist auch keine gute Diskussionskultur Fakten einfach nach belieben zu 
ignorieren, wie die mehrmals erwähnte Freiheit etwas anders als Cargo zu 
benutzen. Ein Spezialfall? Ja! Genau so wie die Fähigkeit Runtime Code 
flexibel zu benutzen.


[1]https://crates.io/crates/nasm-rs
[2]https://github.com/rust-lang/rustup/issues/215
[3]https://github.com/rust-osdev/bootimage
[4]https://prev.rust-lang.org/en-US/faq.html#does-rust-have-a-runtime
[5]https://doc.rust-lang.org/cargo/reference/config.html

Bleibt cool, ist doch nur ein Tool. Davon gibt es viele:)

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

Achja, noch ganz nebenbei:

https://github.com/rust-lang/rust
Hier lebt der Rust Compiler

https://github.com/rust-lang/cargo
Hier wohnt Cargo

Das sind doch zwei Verschiedene Orte, oder irre ich mich?

Falls die wirklich verheiratet sind, wie Einige hier sagen, dann 
verstehe ich die Gerüchte um Trennung und den Rosenkrieg, der nicht nur 
hier im Forum tobt.

Über das obige nachzudenken ist kein Muss. Down voten reicht;)

von MaWin (Gast)


Lesenswert?

Sehr schöne Zusammenfassung.
Danke für die Mühe.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Jedzia D. schrieb:
> DPA, könntest Du bitte ein konkretes Beispiel dafür liefern, was Du mit
> der von dir genannten Inflexibilität ins Sachen Runtime-Code meinst? Und
> was das wirklich mit Cargo zu tun haben soll?[4]

Das habe ich doch nun wirklich schon sehr Detailliert beschrieben, aber 
ich Versuches trotzdem nochmal. Als Beispiel nehme ich mal ein "Hello 
World" Program, um es so simpel wie möglich zu halten. Die Sprache und 
Art von Interface (Programm, Library funktionen, dbus, rest, etc.) ist 
für das eigentlich unerheblich, darum bringe ich mal 2 Beispiele mit 
unterschiedlichen Interfaces und Sprachen.


---
Zunächst mal ein Beispiel mit C:

Erstmal wird ein interface definiert. Dass kann teil von Projekt A sein, 
oder separat, oder generiert, etc. Hier will ich ein "greeter 
interface". Ich definiere es so:

Interface:
greeter/greeter.h:
1
void greet(const char* who);


Projekt A, von Person A, die eigentliche Anwendung:

Compile time dependencies: greeting interface
Runtime dependencies: Eine greeter implementation, aber keinen 
bestimmten!

A/main.c:
1
#include <greeter.h>
2
int main(int argc, char* argv[]){
3
  greet(argc > 1 ? argv[1] : "World");
4
}
1
cd A
2
# dummy library, damit ich keinen loader schreiben muss und kein dlopen brauche
3
gcc -x c - <<<"void greet(const char* who){}" -shared -fPIC -o libgreeter.so
4
# anwendung bauen
5
gcc main.c -I ../greeter -L "$PWD" -Wl,-rpath,'$ORIGIN' -lgreeter -o A.elf
6
# dummy library löschen
7
rm libgreeter.so
8
cd ..


Projekt "hallo", von Person B: Eine greeter implementation: "Hallo" 
Greeter:

Compile time dependencies: greeting interface
Runtime dependencies: keine

hallo/main.c:
1
#include <stdio.h>
2
#include <greeter.h>
3
void greet(const char* who){
4
  printf("Hello %s!\n", who);
5
}
1
cd hallo
2
gcc -shared -fPIC -I ../greeter main.c -o libgreeter.so
3
cd ..

Projekt "Geburtstag", von Person C: Eine greeter implementation: 
Geburtstags Greeter:

Compile time dependencies: greeting interface
Runtime dependencies: keine

geburtstag/main.c:
1
#include <stdio.h>
2
#include <greeter.h>
3
void greet(const char* who){
4
  // TODO: Bake a cake
5
  printf("Happy birthday %s!\n", who);
6
}
1
cd geburtstag
2
gcc -shared -fPIC -I ../greeter main.c -o libgreeter.so
3
cd ..

Man beachte, ist das Interface separat, sind die Projekte "A", "Hallo" 
und "Geburtstag" sind beim kompilieren unabhängig voneinander. Falls man 
des Interface in "A" platziert, haben "Hallo" und "Geburtstag" eine 
compile time Abhängigkeit von "A". "A" hat in jedem fall keine compile 
time Abhängigkeit von "Hallo" oder "Geburtstag".

"A" hat aber eine runtime dependecy, es braucht eine "greeter" 
implementierung. "Hallo" und "Geburtstag" bieten eine "greeter" 
implementierung an.

Der Witz ist, es ist nachträglich möglich, für den Benutzer ohne neu 
kompilieren, die greeter Implementation zu wählen:
1
$ cp A/A.elf . # Programm installieren
2
$ ./A.elf 
3
./A.elf: error while loading shared libraries: libgreeter.so: cannot open shared object file: No such file or directory
4
$ cp hallo/libgreeter.so . # hallo greeter installieren
5
$ ./A.elf 
6
Hello World!
7
$ cp geburtstag/libgreeter.so . # hallo greeter ersetzen mit geburtstag greeter
8
$ ./A.elf 
9
Happy birthday World!
10
$ ./A.elf Tom
11
Happy birthday Tom!

Und die 3 Projekte können dennoch völlig unabhängig voneinander 
entstanden sein, von unterschiedlichen Autoren usw.

---

Beispiel 2, mit bash, nochmal das selbe, aber Anwendungen als Interface:

Inteface greeter:
1
greeter [name]

Projekt "A":
A.sh:
1
#!/bin/sh
2
PATH="$PATH:$(dirname "$0")"
3
arg="$1"
4
[ $# -lt 1 ] && arg=World
5
greeter "$arg"

Projekt "hallo":
hallo_greeter.sh:
1
#!/bin/sh
2
echo "Hallo $1!"

Projekt "geburtstag":
birthday_greeter.sh:
1
#!/bin/sh
2
# TODO: Bake a cake
3
echo "Happy birthday $1!"

Anwendung:
1
$ ./A.sh
2
./A.sh: 5: ./A.sh: greeter: not found
3
$ ln -s hallo_greeter.sh greeter # hallo greeter verwenden
4
$ ./A.sh
5
Hallo World!
6
$ ln -sf birthday_greeter.sh greeter # birthday greeter verwenden
7
$ ./A.sh
8
Happy birthday World!
9
$ ./A.sh Tom
10
Happy birthday Tom!

Auch hier wieder, A braucht eine greeter implementation. hallo greeter 
und birthday greeter bieten eine greeter implementation. hallo greeter 
und birthday greeter hängen nicht von A ab (ich könnte sie einfach 
alleine aufrufen).

---


Das ist ein Beispiel einer Abhängigkeitsstruktur, die sich mit Cargo 
meines wissens nicht ohne weiteres abbilden lässt. Bildet man nur die 
tatsächlichen compile time Abhängigkeiten ab, muss man sich manuell ein 
Backend suchen. Mit z.B. apt ist das anders, dort kann ich die 
Abhängigkeit, und meine bevorzugter Implementation, genau so angeben.

In den meisten fällen werden die Entwickler daher vermutlich nicht diese 
struktur wählen, es läuft dann nämlich nicht einfach so, nach dem 
builden, weil Cargo die runtime dependency ja nicht kennt. Ein 
Entwickler von Projekt A wird sich deshalb normalerweise kein Interface 
ausdenken, er wird sich statdessen den "hallo greeter" oder den 
"birthday greeter" aussuchen, und eine direkte kompile time Abhängigkeit 
darauf machen. "hallo greeter" und "birthday greeter" haben auch keinen 
Grund mehr, einem gemeinsamen Interface gerecht zu werden. Sie werden 
vermutlich ihr eigenes Interface machen, und dadurch nicht mehr zur 
runtime austauschbar sein. Der Entwickler müsste dann einen mehraufwand 
betreiben, wenn er beide greeter unterstützen möchte. Wenn beide zur 
runtime verfügbar sein sollen, hätte man dann zur compile time zu beiden 
eine Abhängigkeit. Andernfalls müsste man halt zur compile time wählen. 
Ein anderer Entwickler, der einen konkurierenden Greeter schreibt, 
könnte der Endanwender nachher auch nicht einfach installieren, selbst 
wenn dieser das selbe Interface hätte, entweder müsste erst jemand die 
Dependencies jeder einzelnen Anwendung, die einen Greeter nutzt, 
anpassen, oder der Endanwender müsste die Dependency bei sich lokal 
anpassen, und neu Kompilieren.

Jenachdem, wo das Interface ist, wer es festlegt, usw. beeinflusst das 
auch die Anforderungen, das Design, die Art der Interessen daran (ein 
gutes Interface entwickeln (unabhängig entwickeltes Interface) vs. ein 
Interface für was ich will (Interface in Anwendung, welches es nutzt) 
vs. ein Interface, mit dem ich Alleinstellungsmerkmale habe (Interface 
in Library)), etc.

Ich hoffe, es ist nun absolut klar, was die Problematik ist, auf die ich 
hinaus wollte.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Und vorneweg schonmal, ja, ich weiss dass man das in rust implementieren 
kann. Darum geht es mir nicht. Es geht um Cargo, und welche Strukturen 
dort einfacher umzusetzen sind.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Und vorneweg schonmal, ja, ich weiss dass man das in rust implementieren
> kann.

Und wo ist dann das Problem?

> Es geht um Cargo,

Warum?

Warum willst du Cargo verwenden, wenn du doch bereits angeblich erkannt 
hast, dass es deinen Usecase nicht unterstützt?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin schrieb:
> Warum willst du Cargo verwenden, wenn du doch bereits angeblich erkannt
> hast, dass es deinen Usecase nicht unterstützt?

Auch wenn ich es nicht nutze, nutzen es so ziemlich alle anderen. Cargo 
beeinflusst durch sein Design die Architektur von mit cargo erstellter 
Software, und damit im grossen und granzen betrachtet von Rust 
Anwendungen. Mit der steigenden Relevanz von Rust in Linux und dem 
OpenSource umfeld allgemein, beeinflusst das das gesammte OpenSource 
umfeld. Ob ich persönlich cargo nutze oder nicht, hat keinen Einfluss 
auf dessen Netzwerkeffekte insgesammt, und ist daher nicht relevant.

Um es nochmal gesagt zu haben:
🐧 DPA 🐧 schrieb:
> Es ist ja immer schön, was ich selbst alles anders machen könnte, aber
> deshalb ist mir nicht egal, wie sich die Freie Software Welt insgesamt
> entwickelt. Das hat dann nämlich nachher auch wieder direkte Folgen für
> mich.

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Und vorneweg schonmal, ja, ich weiss dass man das in rust implementieren
> kann. Darum geht es mir nicht. Es geht um Cargo, und welche Strukturen
> dort einfacher umzusetzen sind.

Du unterschlägst in deinen Beispielen wie du zum ausführbaren Code 
kommst. GCC und make fürs obere? Und bash fürs shell Beispiel?

So, bash-runtime-interpreter + make sind hier das Äquivalent zu Teilen 
der Funktionalität von Cargo.

println!("Hello Denkfehler.
Try https://doc.rust-lang.org/rust-by-example/mod.html
");
Ist so merkwürdig formatiert wegen dem Spass und der URL.
11. Crates und
12. Cargo
nicht vergessen zu lesen.


Anderes zum anschauen als Hilfe gegen deine DLL-Hell(aber nur die c 
runtime):
1
rustflags = ["-C", "target-feature=+crt-static"]

libgreeter.so Beispiel ... Rust: Danke, das es dieses Probleme dort 
nicht gibt. Du vergisst, dass alle Bibliotheken als source-code 
vorliegen. (Das ist dieses ... Cargo + crates.io). Wenn du Einzelnes wie 
Bibliotheken in ein apt/deb/etc-paket verpackst und nicht mit deiner 
Versionierung klarkommst ist das nicht das Problem von Cargo. Ähnliches 
Beispiel: Ubuntu Python-packages, die im Ubuntu repository vorliegen. 
Aber manche Schlaumeier installieren mit pip. Das geht ja auch immer 
gut.

Notiz: Ich sollte einen https://crates.io/crates/dpa.greeter erstellen:)

P.S.: Für uns Gentoo-Weiber ist das völlig normal und ein alter Hut. 
Inklusive der Probleme. Wir reden hier schließlich über Software. Zeig 
mir eine ohne Probleme;)

: Bearbeitet durch User
von 🐧 DPA 🐧 (Gast)


Lesenswert?

Jedzia D. schrieb:
> Du unterschlägst in deinen Beispielen wie du zum ausführbaren Code
> kommst. GCC und make fürs obere? Und bash fürs shell Beispiel?

Nein, die Kommandos zum Builden sind bei meinen Beispielen vorhanden, 
jeweils direkt unter dem Code.

> Ist so merkwürdig formatiert wegen dem Spass und der URL. 11. Crates und
> 12. Cargo nicht vergessen zu lesen.

Hab ich. Das löst aber das zugrundeliegende Problem nicht.

> Anderes zum anschauen als Hilfe gegen deine DLL-Hell(aber nur die c
> runtime):

Das ist keine DLL Hell, das ist gutes Design.

> Du vergisst, dass alle Bibliotheken als source-code vorliegen.

Ich habe auch schon gentoo verwendet, und grosse rust projekte 
kompiliert. Das gehört aber nicht zu meinen Lieblingstätigkeiten. 
Deshalb weiss ich binary distributionen und runtime dependencies sehr zu 
schätzen.

> Wenn du Einzelnes wie Bibliotheken in ein apt/deb/etc-paket verpackst

Mach ich doch gar nicht. Apt ist lediglich ein Beispiel für einen 
Paketmanager, der diese Paketstruktur sauber abbilden kann.

> und nicht mit deiner Versionierung klarkommst ist das nicht das Problem
> von Cargo.

Wenn Cargo keinen Mechanismus vergleichbar zum Provides Mechanissmus von 
apt hat, und die Dependencies für gewisse Softwarearchitekturen schlicht 
nicht modellierbar sind, ist das sehr wohl ein Problem von Cargo.

Jedzia D. schrieb:
> Notiz: Ich sollte einen https://crates.io/crates/dpa.greeter erstellen:)

Wenn du willst. Lass mich vorher die Problematik nochmal zusammenfassen:

1) Es gibt mindestens 3 crates:
 * Die Anwendung A (Entspricht oben der A.elf, btw. der A.sh)
 * Der hallo greeter
 * Der geburtstags greeter

2) Beim ausführen von A mit "cargo run" muss eine greeter implementation 
durch cargo bereits automatisch bereitgestellt worden sein, der user 
soll keinen Mehraufwand haben.

3) Die Anwendung A darf aber nicht explizit von einem oder beiden 
greetern abhängen, es soll nur angeben, dass es irgend einen braucht, es 
darf höchstens eine Präferenz angeben. Andere sollen auch greeter crates 
erstellen können, die man dann als Alternative wählen könnte, und Nutzer 
müssen sich einfach alle Optionen anzeigen lassen können. Das andere 
unabhängig welche über das repo (z.B. crates.io) hinzufügen können, ist 
der Witz an der ganzen Sache.

4) Es muss eine einfache Standardlösung sein, denn andernfalls wäre 
diese Architektur ja unter Entwicklern nicht mit direkten Dependencies 
konkurrenzfähig.


Ich glaube ja nicht, dass das möglich ist, aber ich lasse mich gerne 
eines besseren belehren.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Ich glaube ja nicht, dass das möglich ist, aber ich lasse mich gerne
> eines besseren belehren.

In diesem Thread wurden bereits Möglichkeiten genannt, Dinge dynamisch 
zu laden.

Aber davon abgesehen, funktionieren diverse Dinge in Rust halt anders.
Da muss man sich dann mit abfinden, oder man verwendet es halt nicht, 
wenn man seine alten C-Techniken weiterverwenden will.
Rust linkt eben grundsätzlich statisch.
Das hat aber wiederum auch gar nichts mit Cargo zu tun.
Aber trotzdem kann man natürlich Funktionen als DLLs aufrufen. Wie, 
wurde bereits erklärt.

Du kannst dir unendlich viele synthetische Beispiele in C 
implementieren, die in Rust nur schwerer als in C zu lösen sind. z.B. 
aufgrund des Borrow-Checkers.
Aber das ist eben so gewollt.

Wenn man in Rust programmiert, muss man grundsätzlich umdenken.
Wenn dir das nicht gefällt, dann ist Rust halt nichts für dich.

von Le X. (lex_91)


Lesenswert?

Zum Thema "Dynamisches Linken":

Wenn dein C- oder C++-Programm eine bestimmte Lib in einer bestimmten 
Version vorraussetzt dann hast du erstmal drei Möglichkeiten, die zu 
deployen (keinen Anspruch auf Vollständigkeit).

1) Du schreibst in die Doku dass sich der User lib XYZ in Version 123 
händisch auf seinen Rechner packen soll. Das ist die hässliche Lösung.

2) Du legst die lib deinem Binary bei. Das ist die Windows-Lösung.

3) Du löst die Abhängigkeit über einen Paketmanager auf, z.B. apt oder 
pacman. Das ist die Linux-Lösung.

Lösung 3 funktioniert mit Rust-Binaries genauso wie mit C-Binaries und 
löst exakt das von DPA geschilderte Problem. Sogar optionale 
Abhängigkeiten oder Alternativen sind möglich.

Auch in C/C++ werden Laufzeitabhängigkeiten auf einem aktuellen Linux 
über den Paketmanager aufgelöst.
Warum ist das bei Rust ein Problem?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin schrieb:
> In diesem Thread wurden bereits Möglichkeiten genannt, Dinge dynamisch
> zu laden.

Dass das möglich ist, habe ich, wie ich schon mehrfach auch schrieb, 
nicht bestritten. Nochmal, es geht um die Limitationen des 
Abhängigkeitssystems für Cargo, und dessen daraus resultierenden 
Einfluss auf die Programmarchitektur der darauf basierenden Programme, 
und damit das Rust-Ökosystem insgesamt.

Wenn ich so darüber nachdenke, fällt mir außerdem auf, das die selbe 
Problematik ebenfalls mit compile time Dependencies existiert, für diese 
bietet Cargo ebenfalls keinen einfachen Provides mechanismus. Statisches 
linken kann die Problematik also nicht lösen.

Die Problematik ist von der Art der Schnittstelle auch unabhängig, 
vergleichbare Architekturen könnte ich auch mit Rest, dbus, etc. 
nachbilden.

> Aber davon abgesehen, funktionieren diverse Dinge in Rust halt anders.
> Da muss man sich dann mit abfinden, oder man verwendet es halt nicht,
> wenn man seine alten C-Techniken weiterverwenden will.

Wie ich bereits weiter oben gesagt habe, erschwert dies in dem von mir 
aufgezeigten Fall die Implementation von Plugin und Backend Systemen, wo 
man nicht selbst alle Plugins, Backends, etc. schreibt / selbst kennt, 
ungemein, was zwangsläufig negative Folgen auf Dinge wie die 
Flexibilität und Auswahlmöglichkeiten des Endnutzers bei sämtlicher mit 
Cargo gebauter Software, und letztendlich sämtliche OpenSource Software 
haben muss, da diese Architektur dadurch seltener verwendet wird, als 
dies andernfalls der Fall gewesen wäre.

Das halte ich für eine negative Entwicklung, deshalb halte ich es auch 
für notwendig, diese Problematik aufzuzeigen.

Und wie ich schon mehrfach schrieb, auch wenn ich selbst cargo nicht 
verwenden würde, als Nutzer einer Distribution mit Binärpaketen 
(Debian/Devuan), bin ich trotzdem von Fallout dieses Problems betroffen. 
Wenn das Entwicklungsmodell diese Form der Modularität behindert, habe 
ich dann nämlich, wenn ich mal eines der Programme oder Libraries als 
Endnutzer brauche, weniger Auswahlmöglichkeiten / 
Einstellungsmöglichkeiten.

Le X. schrieb:
> Lösung 3 funktioniert mit Rust-Binaries genauso wie mit C-Binaries und
> löst exakt das von DPA geschilderte Problem. Sogar optionale
> Abhängigkeiten oder Alternativen sind möglich.
>
> Auch in C/C++ werden Laufzeitabhängigkeiten auf einem aktuellen Linux
> über den Paketmanager aufgelöst.
> Warum ist das bei Rust ein Problem?

Weil bei der Entwicklung so ziemlich jeder Cargo verwendet, um bei der 
Entwicklung seine Abhängigkeiten zu verwalten. Wenn diese Art der 
Abhängigkeit, die ich oben beschrieb, also schon dort, bereits in der 
Entwicklung, mit dem von allen verwendeten Tool, nicht ohne weiteres 
realisierbar ist, werden die Entwickler das schlicht nicht so umsetzen. 
Und wenn die unabhängigen Plugins und Backends im vornherein schon nicht 
entwickelt werden, kann man die nachher auch nicht in apt Pakete 
verpacken.

von Le X. (lex_91)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Weil bei der Entwicklung so ziemlich jeder Cargo verwendet, um bei der
> Entwicklung seine Abhängigkeiten zu verwalten. Wenn diese Art der
> Abhängigkeit, die ich oben beschrieb, also schon dort, bereits in der
> Entwicklung, mit dem von allen verwendeten Tool, nicht ohne weiteres
> realisierbar ist, werden die Entwickler das schlicht nicht so umsetzen.
> Und wenn die unabhängigen Plugins und Backends im vornherein schon nicht
> entwickelt werden, kann man die nachher auch nicht in apt Pakete
> verpacken.

Hast du denn da Erfahrungen aus der Praxis oder ist das eine Vermutung?

Man müsste hier mal in etwa gleich komplexe Projekte aus C/C++ und Rust 
auf die Art des Linkens hin untersuchen.

Beitrag #6557356 wurde von einem Moderator gelöscht.
von Julius (Gast)


Lesenswert?

Ich habe mich mit Rust beschäftigt, und finde dessen Konzepte sehr 
interessant. Die Erfahrung aus der Softwareentwicklung der letzten 
Jahrzehnte, in neue Sprachen einfließen zu lassen, halte ich für einen 
richtigen Schritt. In unserer Firma gibt es Gruppen in denen Rustthemen 
auch immer wieder diskutiert werden. Momentan beruht das aber 
ausschließlich auf persönlichen Interessen.

Im industriellen Bereich sind Produktlebenszeiten von 20...30 Jahren 
nichts besonderes. Die embedded Software dieser Produkte muss dann auch 
über diesen Zeitraum hinweg wartbar sein. Wartbar heißt nicht das eine 
Firmware in einer neue Sprache neu geschrieben wird, es wird nur das 
Bestehende am Laufen gehalten. Anders geht es aufgrund der hohen Kosten 
auch nicht. Wer schon mal mit der Begutachtung von Software zu tun 
hatte, dem ist klar was ich meine.

Es ist also sehr wohl Kontinuität über Jahrzehnte hinweg gefragt. Da 
habe ich mit Rust noch so meine Zweifel. So lange mit Rust auf Dauer 
Abhängigkeiten zum Internet bestehen, sehe ich in unserem Bereich keinen 
Einsatz von Rust im grösseren Umfang.

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

Julius schrieb:
> Es ist also sehr wohl Kontinuität über Jahrzehnte hinweg gefragt. Da
> habe ich mit Rust noch so meine Zweifel. So lange mit Rust auf Dauer
> Abhängigkeiten zum Internet bestehen, sehe ich in unserem Bereich keinen
> Einsatz von Rust im grösseren Umfang.

Klar das ist ein wichtiger Faktor um die Produkt-Sicherheit zu 
gewährleisten. Wo bezieht ihr eure, sagen wir Keil, ST(M) o.ä. Libraries 
und Frameworks her?
Kommt der Werksfahrer?:)

In Rust kannst Du genau so manuell oder selbstbestimmt deine Software 
lokal verwalten. Sogar mit Cargo.
Relative Pfade und "Cargo.lock" sind die Stichworte hierzu.

https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Le X. schrieb:
> Hast du denn da Erfahrungen aus der Praxis oder ist das eine Vermutung?

Ich kann leider nicht wissen, ob in der Praxis die Software wirklich 
anders ausgesehen hätte, wenn Cargo einen provides ähnlichen Mechanismus 
gehabt hätte. Aber ich halte es für naheliegend, dass wenn ein 
Mechanismus vorhanden ist, dieser auch öfter genutzt wird, mit allen 
sich daraus ergebenden Folgen, und umgekehrt.

> Man müsste hier mal in etwa gleich komplexe Projekte aus C/C++ und Rust
> auf die Art des Linkens hin untersuchen.

Man sollte das nicht so stark Einschränken. Libraries sind nur eine 
einer Vielzahl möglicher Arten von Schnittellen. Bei Anwendungsaufruf, 
REST und dbus Schnittellen z.B., ist es etwas Einfacher, keine \/ eine 
umgedrehte / Austauschbare Abhängigkeit zu haben, als bei Libraries.

Es ist aber auch nicht immer eindeutig, was effektiv von was abhängig 
ist, ob, von wem und in wie weit das Interface von jemandem kontrolliert 
/ festgelegt wird, welches die normale Richtung ist, etc.

Ausserdem gibt es in dem Fall noch die Möglichkeit, dass eine Anwendung 
/ ein Projekt selbst auch Backends beinhaltet, aber trotzdem unabhängige 
Projekte ebenfalls Backends bereitstellen können. z.B. gibt es in X11 im 
Xorg Projekt die modesetting DDX, aber es gibt in anderen Repos 
unabhängige DDX für Nvidia, Intel, AMD, etc.

Man kann da so ziemlich alle möglichen und unmöglichen Kombinationen 
antreffen. Je nach eigenen Kriterien könnte man das dann so oder so 
einordnen.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> wie ich schon mehrfach auch schrieb,

Ja Ok. Wir drehen uns im Kreis.
Das bringt nichts, denn du bist echt nicht zugänglich für Fakten.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> wenn Cargo einen provides ähnlichen Mechanismus
> gehabt hätte.

Es ergibt überhaupt gar keinen Sinn einen provides-Mechanismus in Cargo 
zu haben.
Cargo ist keine System-Paketverwaltung.
Wenn du das brauchst, dann musst du halt apt oder etwas ähnliches 
nutzen.

von cppbert3 (Gast)


Lesenswert?

Ich verstehe das ganze argumentieren hier irgendwie gar nicht

entweder ist man an Rust interresiert und hat aber Probleme mit Cargo, 
dann involviert man sich und verbessert die Situation, ist open source 
für direktwerkeln oder man redet mit den Entwicklern bei github oder 
reddit, dauert eben eine ganze Weile, aber das bei allen Projekten so

oder man findet die Sprache nicht gut und lässt es, oder wartet das es 
besser wird, aber einfach nur meckern oder beschweren ohne das es 
wenigstens so wirkt als wolle man positive Impulse geben ist einfach 
sinnfrei

von S. R. (svenska)


Lesenswert?

Rust ist eine Programmiersprache, deren Ökosystem relativ eng mit Cargo 
verknüpft ist. Cargo finde ich blöd, also ist Rust auch nichts für mich. 
Deswegen bin ich raus.

Android scheint langsam auch Rust-Unterstützung zu bekommen, vielleicht 
fällt da ja ein besseres Buildsystem bei ab.

von cppbert (Gast)


Lesenswert?

S. R. schrieb:
> Rust ist eine Programmiersprache, deren Ökosystem relativ eng mit Cargo
> verknüpft ist. Cargo finde ich blöd, also ist Rust auch nichts für mich.
> Deswegen bin ich raus.

d.h. die supertollen Rust-Features können das nicht ausbügeln oder gibt 
es für dich einfach keine supertollen Featuren in Rust?

von MaWin (Gast)


Lesenswert?

Um in Rust zu antworten:
1
loop {
2
}

von mh (Gast)


Lesenswert?

cppbert schrieb:
> S. R. schrieb:
>> Rust ist eine Programmiersprache, deren Ökosystem relativ eng mit Cargo
>> verknüpft ist. Cargo finde ich blöd, also ist Rust auch nichts für mich.
>> Deswegen bin ich raus.
>
> d.h. die supertollen Rust-Features können das nicht ausbügeln oder gibt
> es für dich einfach keine supertollen Featuren in Rust?

Was gibt es denn neben Ownership/Memorysafety für supertolle Features in 
Rust?

(Für mich bringt rust da auch keine Vorteile, da modernes C++ in dem 
Bereich kaum Möglichkeiten für Fehler bietet. Und wenn es einen Fehler 
gibt fällt der ziemlich sicher dank gcc und clang Sanitizern schnell 
auf.)

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Was gibt es denn neben Ownership/Memorysafety für supertolle Features in
> Rust?

vieles

match
traits
macros-rules
proc-macros
generics
unmutable default
enums (nein, enums in Rust sind nicht äquivalent zu C/C++ enums)
Option (Sicherer Null-Ersatz)
Result (Sicherer Ersatz für Exceptions und generelles 
Returnwert-gefrickel)
?-Operator (nein, der hat nichts mit ?: zu tun)
lifetimes
Vernünftiger Parser. Keine Deklarationen.
Einfaches und effektives Modulsystem.

und vieles vieles mehr.

> (Für mich bringt rust da auch keine Vorteile, da modernes C++ in dem
> Bereich kaum Möglichkeiten für Fehler bietet.

kaum Möglichkeiten < keine Möglichkeiten

von MaWin (Gast)


Lesenswert?

MaWin schrieb:
> kaum Möglichkeiten < keine Möglichkeiten

Bevor einer meckert:
Ich meinte "kaum" ist schlechter als "keine".
Der Operator sollte nicht die Anzahl vergleichen :)

von mh (Gast)


Lesenswert?

MaWin schrieb:
> mh schrieb:
>> Was gibt es denn neben Ownership/Memorysafety für supertolle Features in
>> Rust?
>
> vieles
> [...]

Und was davon ist jetzt ein Alleinstellungsmerkmal?

MaWin schrieb:
>> (Für mich bringt rust da auch keine Vorteile, da modernes C++ in dem
>> Bereich kaum Möglichkeiten für Fehler bietet.
>
> kaum Möglichkeiten < keine Möglichkeiten

Und mal wieder hast du nur die halbe Aussage zitiert.

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Und was davon ist jetzt ein Alleinstellungsmerkmal?

Alles zusammen.

> Und mal wieder hast du nur die halbe Aussage zitiert.

Na dann den Rest auch noch. Kommt aber auf die selbe Aussage raus:

>Und wenn es einen Fehler gibt fällt der ziemlich sicher dank gcc und clang 
Sanitizern schnell auf.)

"ziemlich sicher" schlechter als "sicher".
"schnell" schlechter als "sofort schon beim Compiler".

von cppbert3 (Gast)


Lesenswert?

mh schrieb:
> (Für mich bringt rust da auch keine Vorteile, da modernes C++ in dem
> Bereich kaum Möglichkeiten für Fehler bietet. Und wenn es einen Fehler
> gibt fällt der ziemlich sicher dank gcc und clang Sanitizern schnell
> auf.)

Smart pointer, RAII und ASan sind nur Dinge die funktionieren wenn man 
sie auch nutzt, also abhängig von Projektqualität und Mitarbeitern, nach 
zig Firmen in der Selbständigkeit bei gross und klein kann ich ohne 
Probleme sage das es genau so viele gibt die davon gar nichts nutzen, zu 
viel - alles mit shared ptr oder eine wilde Mischung, ich hab noch kein 
grosses Projekt zur Analyse bekommen das nicht ordentlichen Fehler mit 
ASan gezeigt hat, egal wie gut und ordentlich das Team gearbeitet hat, 
ab eine gewissen Menge Mitarbeiter und Codegrösse ist es einfach 
schwierig, egal wie idealistisch man die Branche, seine eigene Firma 
oder die Kollegen einschätz, bei Rust kann niemand, wenn er nicht das 
verteufelte unsafe nutzt auch nur einen der typischen Fehler machen ohne 
das der Code nicht kompiliert

100.000 C/C++ler können Fehler dieser Art machen, Rustler eben gar nicht 
und das auch ohne Garbage Collector

Bei ein paar guten Entwicklern im Team zu meinen das wäre fast das 
gleiche lasse ich noch gelten, aber nicht mehr bei hundertausend oder 
mehr

Der Unterschied zwischen Fehler ist-nicht-möglich oder möglich ist 
riesig wenn du das auf alle potenziellen Entwickler skalierst

von cppbert3 (Gast)


Lesenswert?

Die Frage ist eher ob du den Garantien von Rust glaubst und ob du jedem 
Entwickler in C/C++ den du kennst und der mit seiner Arbeit der 
Wirtschaft nutz oder schadet die gleichen Fähigkeit wie dir zusprichst

von MaWin (Gast)


Lesenswert?

cppbert3 schrieb:
> verteufelte unsafe

Unsafe ist nicht verteufelt.

unsafe schaltet überhaupt keine von Rusts safety-Garantien ab.
Der Borrow-Checker und Memory-Safety von allen Rust-Typen ist weiterhin 
aktiv.
Es gibt lediglich ein paar wenige zusätzliche Möglichkeiten frei.
Das sind hauptsächlich raw-Pointer-Deref und die Möglichkeit anderen 
unsafe-Code aufzurufen.

Unsafe macht Code also nicht automatisch unsicherer.
Unsafe markiert nur Code, in dem man seine Raw-Pointer und 
unsafe-Aufrufe ganz genau auditieren sollte.

Normaler Anwendercode braucht in der Regel kein Unsafe.

Es ist aber an der Stelle notwendig, wo z.B. die Rust Runtime auf das 
Betriebssystem oder Hardware zugegriffen werden muss. Diese Zugriffe 
sind aber für Anwendercode alle in entsprechende safe-APIs gewrappt.

Rust reduziert die zu auditierenden Blöcke also auf die unsafe-Blöcke, 
die in typischen Anwendungen bei ziemlich nahe 0% des Codes liegen.

von mh (Gast)


Lesenswert?

cppbert3 schrieb:
> egal wie idealistisch man die Branche, seine eigene Firma
> oder die Kollegen einschätz, bei Rust kann niemand, wenn er nicht das
> verteufelte unsafe nutzt auch nur einen der typischen Fehler machen ohne
> das der Code nicht kompiliert
Denk noch mal über den Satz nach. Wer verhindert, dass deine Kollegen 
unsafe nutzen?

Und warum glaubst du, dass Entwickler, die nicht in der Lage sind sich 
in C++ an ein paar simple Regeln zu halten, mit rust klar zu kommen? Und 
behaupte jetzt bitte nicht, dass rust total einfach und idiotensicher 
ist.

von S. R. (svenska)


Lesenswert?

cppbert3 schrieb:
> Smart pointer, RAII und ASan sind nur Dinge die
> funktionieren wenn man sie auch nutzt,

Das gilt aber auch für Rust.

Du kannst existierende C/C++-Projekte, die sowas nicht benutzen, nicht 
mit neuen Rust-Projekten vergleichen.

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> Unsafe ist nicht verteufelt.

Das ist mir klar, aber das wird gerne als Argument genommen warum Rust 
ja doch nicht besser ist und es gab auch schon relevante Projekte die 
unnötig viel unsafe genutzt haben, deswegen ist unsafe erstmal verpönt 
und für die systemnahen unter uns vorbehalten

von MaWin (Gast)


Lesenswert?

mh schrieb:
>Wer verhindert, dass deine Kollegen unsafe nutzen?

Dieses Missverständnis habe ich ja bereits erläutert.

> Und warum glaubst du, dass Entwickler, die nicht in der Lage sind sich
> in C++ an ein paar simple Regeln zu halten, mit rust klar zu kommen? Und
> behaupte jetzt bitte nicht, dass rust total einfach und idiotensicher
> ist.

Wenn man sich in Rust nicht an die Regeln hält, compiliert der Code in 
der Regel nicht.
In wenigen Fällen sagt er einem zur Laufzeit, dass man etwas getan hat, 
was nicht erlaubt ist.

Deshalb werden die Entwickler sich dran halten müssen.

von cppbert3 (Gast)


Lesenswert?

mh schrieb:
> cppbert3 schrieb:
>> egal wie idealistisch man die Branche, seine eigene Firma
>> oder die Kollegen einschätz, bei Rust kann niemand, wenn er nicht das
>> verteufelte unsafe nutzt auch nur einen der typischen Fehler machen ohne
>> das der Code nicht kompiliert
> Denk noch mal über den Satz nach. Wer verhindert, dass deine Kollegen
> unsafe nutzen?
>
> Und warum glaubst du, dass Entwickler, die nicht in der Lage sind sich
> in C++ an ein paar simple Regeln zu halten, mit rust klar zu kommen? Und
> behaupte jetzt bitte nicht, dass rust total einfach und idiotensicher
> ist.

Was glaubst du was leichter ist: die Nutzung von unsafe zu erkennen oder 
fehlende Anwendung von sicherem C++?

von cppbert3 (Gast)


Lesenswert?

mh schrieb im Beitrag
> Und warum glaubst du, dass Entwickler, die nicht in der Lage sind sich
> in C++ an ein paar simple Regeln zu halten, mit rust klar zu kommen? Und
> behaupte jetzt bitte nicht, dass rust total einfach und idiotensicher
> ist.

In den meisten Fällen kompiliert es dann einfach nicht und ja es ist 
nicht leicht aber definitiv idiotensicher, wenn nicht sogar 
idiotenabwehrend

von MaWin (Gast)


Lesenswert?

cppbert3 schrieb:
> Das ist mir klar,

Ich wollte das nur noch etwas untermauern, damit keine Missverständnisse 
entstehen.

> aber das wird gerne als Argument genommen warum Rust
> ja doch nicht besser ist

Ja. Das ist genau das Missverständnis, was es auszuräumen gilt.

>es gab auch schon relevante Projekte die unnötig viel unsafe genutzt haben,

Ja, das ist natürlich in der Regel unnötig. Und es ist unschöner Stil.
Aber es macht sie nicht per se unsicher.

Aber solche Projekte sind ja mit ihren unsafe-Blöcken eindeutig als 
Murks markiert.
Und da kann man dann seine Entscheidungen drauf basieren, ob man es denn 
verwendet oder nicht.

Man braucht in Rust keine komplexen Checker-Tools, um potentiell 
unsicheren Code zu identifizieren, sondern nur
grep unsafe

von mh (Gast)


Lesenswert?

cppbert3 schrieb:
> Was glaubst du was leichter ist: die Nutzung von unsafe zu erkennen oder
> fehlende Anwendung von sicherem C++?

Für mich, die fehlende Anwendung von sicherem C++.

von cppbert3 (Gast)


Lesenswert?

S. R. schrieb:
> Das gilt aber auch für Rust.

Du kannst diese Konzepte in Rust nicht umgehen sonst kompiliert dein 
Code nicht

Aliasing, Leaking oder sonstige Fehler dieser Art sind by design nicht 
möglich

Ich glaube einigen ist das hier immer noch nicht wirklich klar

Der Kompiler erhält durch die zusätzlich Ownership Annotation genug 
Informationen zur Kompilezeit um Fehler zu erkennen und ohne die 
annotation kompilierts nicht

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Für mich, die fehlende Anwendung von sicherem C++.

Weil du eine Plaintextsuche nach "unsafe" nicht durchführen kannst?
Das erklärt einiges.

von mh (Gast)


Lesenswert?

MaWin schrieb:
> mh schrieb:
>> Für mich, die fehlende Anwendung von sicherem C++.
>
> Weil du eine Plaintextsuche nach "unsafe" nicht durchführen kannst?
> Das erklärt einiges.

Das ist ein Schritt mehr, als ich in C++ machen muss.

von S. R. (svenska)


Lesenswert?

Du vergleichst eine alte C/C++-Codebasis, die keinerlei Sanitizer und 
Vorsichtsmaßnahmen nutzt mit einer kompletten Neuentwicklung in Rust.

Ist ja schön, dass Rust so geil ist, aber wenn man C++ richtig benutzt, 
mit den Sanitizern und Compilerwarnungen, was ist dann noch der Vorteil?

von cppbert3 (Gast)


Lesenswert?

mh schrieb:
> cppbert3 schrieb:
>> Was glaubst du was leichter ist: die Nutzung von unsafe zu erkennen oder
>> fehlende Anwendung von sicherem C++?
>
> Für mich, die fehlegrepnde Anwendung von sicherem C++.

mh schrieb:
> cppbert3 schrieb:
>> Was glaubst du was leichter ist: die Nutzung von unsafe zu erkennen oder
>> fehlende Anwendung von sicherem C++?
>
> Für mich, die fehlende Anwendung von sicherem C++.

Ich meinte in 300.000 Zeile fremden Code den du morgen auf den Tisch 
bekommst

In Rust suche ich nach "unsafe", der Rest ist per se Safe, Logikfehler 
kann ich in Rust und C++ machen

von cppbert3 (Gast)


Lesenswert?

S. R. schrieb:
> Du vergleichst eine alte C/C++-Codebasis, die keinerlei Sanitizer
> und Vorsichtsmaßnahmen nutzt mit einer kompletten Neuentwicklung in
> Rust.
>
> Ist ja schön, dass Rust so geil ist, aber wenn man C++ richtig benutzt,
> mit den Sanitizern und Compilerwarnungen, was ist dann noch der Vorteil?

Egal welcher Idiot den Rust code schreibt, er kann keinen der 
Speicherprobleme von C++ aufweisen

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> Ist ja schön, dass Rust so geil ist, aber wenn man C++ richtig benutzt,
> mit den Sanitizern und Compilerwarnungen, was ist dann noch der Vorteil?

Das "wenn" wird eliminiert.
Der Code compiliert nicht mehr.

Der Compiler beweist das "wenn".

von mh (Gast)


Lesenswert?

cppbert3 schrieb:
> In Rust suche ich nach "unsafe", der Rest ist per se Safe, Logikfehler
> kann ich in Rust und C++ machen

Es ist auch trivial, in C++ nach new zu suchen. Und die Tools, die 
derartige Dinge überprüfen, laufen so oder so über den Code.

Warum glaubt ihr, jemand der nicht in der Lage ist Sanitizer und 
änhliche Tools zu nutzen, kommt mit rust klar?

von cppbert3 (Gast)


Lesenswert?

S. R. schrieb:
> Du vergleichst eine alte C/C++-Codebasis, die keinerlei Sanitizer
> und Vorsichtsmaßnahmen nutzt mit einer kompletten Neuentwicklung in
> Rust.
>
> Ist ja schön, dass Rust so geil ist, aber wenn man C++ richtig benutzt,
> mit den Sanitizern und Compilerwarnungen, was ist dann noch der Vorteil?

Du denkst nur in den kleinen kontrollierten Bedingungen deiner Projekte 
und Teams

Wenn dein tolles grüne Wiese Projekt in C++ fertig ist komme andere nach 
dir und machen Sachen die du nicht so machen würdest, weil du schon dann 
schon an x anderen Projekten in einer anderen Abteilung arbeitest

von S. R. (svenska)


Lesenswert?

cppbert3 schrieb:
> Wenn dein tolles grüne Wiese Projekt in C++ fertig ist

Ich lache mal und verlasse dann leise die Diskussion.

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Es ist auch trivial, in C++ nach new zu suchen.

new produziert unsicheren Code?
So ein be*****es Argument habe ich ja lange nicht mehr gelesen.

von W.S. (Gast)


Lesenswert?

SoOderSo schrieb:
> Einerseits wird mit der Weiterentwicklung von C++ argumentiert dass Rust
> nicht  notwendig sei. Anderseits sehe ich aber eine massive
> Relativierung und mangelnde Akzeptanz der C++ Neuerungen.

Ob nun C++ oder Rust oder noch eine Handvoll Versuche, aus C irgend 
etwas Zukunftsweisendes zu machen, ist doch egal.

Es ist immer wieder C und nochmals C und allenfalls mit einem Sack neuer 
Kollateraleffekte und Stolperfallen versehen, an die man sich gewöhnen 
müßte, wenn man so etwas als Programmiersprache tatsächlich benützen 
wollte.

Überlaßt doch ganz einfach diese untoten Leichen sich selbst und ihren 
Fans.

W.S.

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Warum glaubt ihr, jemand der nicht in der Lage ist Sanitizer und
> änhliche Tools zu nutzen, kommt mit rust klar?

Das behauptet niemand.

Aber Leute, die sich einen Dreck um sicheren Code scheren, werden mit 
Rust aussortiert.

von cppbert3 (Gast)


Lesenswert?

mh schrieb:
> cppbert3 schrieb:
>> In Rust suche ich nach "unsafe", der Rest ist per se Safe, Logikfehler
>> kann ich in Rust und C++ machen
>
> Es ist auch trivial, in C++ nach new zu suchen. Und die Tools, die
> derartige Dinge überprüfen, laufen so oder so über den Code.
>
> Warum glaubt ihr, jemand der nicht in der Lage ist Sanitizer und
> änhliche Tools zu nutzen, kommt mit rust klar?

In Rust brauche ich diese Tools gar nicht

Ich nutze die Sanitizer seit der 1. Stunde (und die sind ja echt noch 
superjung, ich hab vorher 20 jahre ohne gearbeiter und die sind ein 
Segen) und alle kommerziellen und kostenfreien Analyser mit allen 
möglichen Kompilern auf fast allen Platformen die marktrelevant sind, 
weil es ohne zu fahrlässig ist

Du bestätigst doch selbst das man ohne Sanitizer nicht arbeiten sollte
erklär mir doch einfach bitte warum eine Sprache die solche Tools 
unnötig macht nicht gut sein soll, traust du den versprechungen von Rust 
nicht?

von mh (Gast)


Lesenswert?

MaWin schrieb:
> mh schrieb:
>> Es ist auch trivial, in C++ nach new zu suchen.
>
> new produziert unsicheren Code?
> So ein be*****es Argument habe ich ja lange nicht mehr gelesen.

Du hast offensichtlich keine Ahnung von modernem C++, wenn du nicht 
verstehst, warum new ein Indiz für unsicheren Code ist.

von cppbert3 (Gast)


Lesenswert?

S. R. schrieb:
> cppbert3 schrieb:
>> Wenn dein tolles grüne Wiese Projekt in C++ fertig ist
>
> Ich lache mal und verlasse dann leise die Diskussion.

Wie stellst du sicher das andere nach dir den Code nicht schlechter 
machen als du?

von mh (Gast)


Lesenswert?

cppbert3 schrieb:
> In Rust brauche ich diese Tools gar nicht

Vielleicht, weil dieses Tool in den Compiler eingebaut ist? Oder wie 
wird Ownership in rust überprüft?

von MaWin (Gast)


Lesenswert?

W.S. schrieb:
> Ob nun C++ oder Rust oder noch eine Handvoll Versuche, aus C irgend
> etwas Zukunftsweisendes zu machen, ist doch egal.
>
> Es ist immer wieder C und nochmals C

Rust hat mit C überhaupt gar nichts gemeinsam, außer einige wenige 
Grammatikdetails.

Jemand der C programmieren kann, kann noch lange keine einzige Zeile 
Rust programmieren.

Ich war ja auch lange der Meinung, dass jeder, der wenigstens C kann, 
innerhalb von Tagen jede andere imperative Sprache erlernen kann.
Rust hat mir das Gegenteil bewiesen.
Man muss deutlich anders denken.

Und es ist gut so!

Rust eröffnet einem ganz neue Paradigmen. Ganz neue Denkweisen.
Die kann man auch teilweise in andere Sprachen übertragen, die solche 
Garantien nicht haben.

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Du hast offensichtlich keine Ahnung von modernem C++, wenn du nicht
> verstehst, warum new ein Indiz für unsicheren Code ist.

Ja. Ein Indiz.

Rust beweist.

Unterschied: Indiz <-> Beweis.

von cppbert3 (Gast)


Lesenswert?

mh schrieb:
> MaWin schrieb:
>> mh schrieb:
>>> Es ist auch trivial, in C++ nach new zu suchen.
>> new produziert unsicheren Code?
>> So ein be*****es Argument habe ich ja lange nicht mehr gelesen.
>
> Du hast offensichtlich keine Ahnung von modernem C++, wenn du nicht
> verstehst, warum new ein Indiz für unsicheren Code ist.

Du kannst aber auch noch nicht soo viel Erfahrung haben wenn du denkst 
das due suche nach new alle Speicherprobleme mit C++ aufzeigt, was ist 
mit Aliasing, Use-After-Free in cast-Ctors und und und, die Liste ist 
sehr lang aber viele C++ Entwickler glauben einfach das die anderen 
Entwickler eben auch so gut arbeiten wie man selbst und dem ist eben oft 
nicht so, klar kann man die alle entlassen, gehen die eben zu einer 
anderen Firma bis die dicht macht, schlussendlich bleiben die am Markt 
und werden eben genutzt

In Rust können die wenigstens kein schwer zu findenden Speicherfehler 
machen, und nein hier geht es nicht um Memoryleaks die sind die 
einfachste Form

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Vielleicht, weil dieses Tool in den Compiler eingebaut ist?

Es ist in die Sprache eingebaut.
Das ist ein Unterschied.

> Oder wie wird Ownership in rust überprüft?

Überhaupt nicht.
Es ist ein intrinsisches Sprachdetail.

Ich glaube du verwechselst das mit Borrowing. (vgl. C++ shared_ptr, aber 
zur Compilezeit)

von cppbert3 (Gast)


Lesenswert?

mh schrieb:
> cppbert3 schrieb:
>> In Rust brauche ich diese Tools gar nicht
>
> Vielleicht, weil dieses Tool in den Compiler eingebaut ist? Oder wie
> wird Ownership in rust überprüft?

Rust hat keine Runtime Sanitation sonder kompiletime Analyse, klar 
irgendwie das gleiche - aber Rust braucht nichtmal Tests um den Fehler 
vor dem Lauf zu finden, nicht jedes Programm erreicht aus dem Stand 100% 
Coverage d.h. du musst in einem nicht-grüne-Wiese oder Fremden Code 
Projekt erstmal die Codezeile auslösen damit der Sanitizer wirkken kann, 
zeig mir mal wie du das schnell mit einem 100KLoc Programm mache das ich 
gerade erst bekommen habe, wo irgendwelche Fehler, scheinbar drinn sind 
- in Rust sind diese Fehler einfach nicht möglich

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


Lesenswert?

W.S. schrieb:
> Ob nun C++ oder Rust oder noch eine Handvoll Versuche, aus C irgend
> etwas Zukunftsweisendes zu machen, ist doch egal.

ROTFL.

Vielleicht solltest du dir ja wenigstens minimal was zur Sprache 
angucken, über die du hier gerade verdammt große Bögen spuckst. Könnte 
sonst sein, die Wurfparabel war falsch berechnet, und du schießt dir mit 
deiner Spucke ein Eigentor. :-)

von Daniel A. (daniel-a)


Lesenswert?

Ihr argumentiert also gerade über den negativen Netzwerkeffekt des 
fehlenden Features der erzwungenen memory safety bei C++, der wäre, dass 
Programme des C++ Ökosystems häufiger Speichermanagementprobleme 
aufweisen, als wenn diese dieses Feature hätte. Also eine 
Designentscheidung des Systems, das Einfluss auf das Ökosystem hat.

Euch mag eventuell auffallen, dass dies die selbe Art von Argument ist, 
wie ich es beim fehlenden provides Feature von Cargo vorbrachte.

Ich könnte hier jetzt auf die selbe Art dagegen argumentieren, "Dann 
nutze doch keine C++/Cargo Anwendungen.", "Ist das eine Vermutung?", 
"Rust kann dynamisch linken" vs. "Das geht in C++ schon, mit smart 
Pointern.", usw.

Die Probleme sind Echt. Nur mal so zum drüber nach denken...

von cppbert3 (Gast)


Lesenswert?

Nur damit das klar ist

Rust macht zur Kompilezeit eine programmweite Analyse, also 100% Source 
Abdeckung und bricht den Kompiliervorgang ab wenn irgendein 
Speicherfehler auftreten kann, aber nicht weil der Fehler passiert 
sondern weil die Rust Semantik solche Problem nicht erlaubt oder besser 
gesagt überhaupt abbilden kann, ist also ein Kompiletime Semantik-Fehler

Die Sanitizer müssen durch Unit- oder manuelle oder Fuzzy Tests gezielt 
oder zufällig über ein Problem stolpern

Zwischen den beiden Konzepten liegen Welten

Rust ist wie bei Minority Report wo man vor dem Mord schon im Knast 
sitzt, die Sanitizer sind eher wie Polizisten die zufällig oder weil 
jemand sie dort hingeschickt hat den Mord beobachten

von MaWin (Gast)


Lesenswert?

Daniel A. schrieb:
> Nur mal so zum drüber nach denken...

Ich verstehe kein Wort von dem, was du schreibst.

Könntest du das bitte verständlich neu formulieren?

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> Daniel A. schrieb:
>> Nur mal so zum drüber nach denken...
>
> Ich verstehe kein Wort von dem, was du schreibst.
>
> Könntest du das bitte verständlich neu formulieren?

Es ist Pro Rust, einfach mehrfach lesen dann wirds klar, kompliziert 
aber stechend formuliert

von cppbert3 (Gast)


Lesenswert?

https://github.com/microsoft/windows-rs

Microsoft hat eine Metabeschreibung der WinApi veröffentlicht, nebst 
Binding Generator für Rust und C#, C++ soll folgen

Beitrag #6565967 wurde vom Autor gelöscht.
von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

mh schrieb:
> Du hast offensichtlich keine Ahnung von modernem C++, wenn du nicht
> verstehst, warum new ein Indiz für unsicheren Code ist.

Ja aber nur wenn das

- delete fehlt
- oder Exception zwischendurch
- womöglich x hundert andere Pfade existieren wo etwas schief gehen kann
- das mein (seien wir ehrlich:) hinzugepfriemeltes Tool erst mal 
entdecken muss
- etc.

Code-Reflection ist eben nicht einfach, besonders wenn man die Regeln 
der grauen Eminenzen(Komitee)im Ökosystem einer organisch gewachsenen 
Programmiersprache beachten muss. (Völlig wertfrei gemeint ... ich bin 
in Boost verliebt)

Wie wäre es bloß, wenn man diesen steinigen Weg gar nicht gehen müsste 
und Speicherfehler vermeiden könnte, etwa durch ein Neu-Design? Was 
würde ich geben wenn es so etwas geben würde ... :)

1
unsafe
 ist natürlich immer noch böse.

Aber vergleichen wir einmal
https://github.com/google/sanitizers/issues?q=is%3Aissue+delete
mit https://debbugs.gnu.org/cgi/pkgreport.cgi?package=grep

Bei den grep issues nicht erschrecken lassen. Kein einziger Bug davon 
verhindert das grep -r unsafe * etwas anzuzeigen vergisst. Nur gabs 
gerade bei der Rekursion einen Memory-Leak. Sachen gibts;)
Das war jetzt aber eher mit einem zwinkernden Auge gemeint. Äpfel und 
Birnen.

xyz-sanitize ist eben KEIN Ersatz für Sprachdesign sondern die 
Putzkolonne, wenn die Sauerei schon dampft.


P.S.: Bild => völlig anderer Rost! -> 
https://dilbert.com/strip/2000-04-30

von cppbert (Gast)


Lesenswert?

Rust forciert:

1. einen einheitlichen Codingstyle (den man lokal deaktivieren kann - 
was aber nicht gerne gesehen ist)

==> der Style ist dann vielleicht nicht so wie man den seit 20 Jahren 
nutzt aber wenigstens ist er über alle Kollegen, Abteilungen UND Firmen 
für die man zeitweise arbeitet der selbe - und wer will den Ernsthaft 
behaupten das es zwischen den produktiven hunderten Codingstyles die das 
draussen so rumkreuchen und fleuchen der Unterschied mehr ist als 
Bauchgefühl

spätestes wenn du mit C,C++,C# und Python arbeitest fährt man im 
Normalfall schon 2-3 verschiedene Arten - also was soll es...

MERKE: man "kann" nicht nur einen gemeinsamen Codingstyle haben - man 
hat IMMER den selben(nicht nur den gleichen) Codingstyle

2. Ein Own/Share Konzept in der Sprache - was definitiv NICHT bedeutet 
das da Smart-Pointer einfach nur fest eingebaut sind sondern das die 
Sprache syntaktisch nicht erlaubt Own oder Share-Probleme zu 
programmieren, das komplette Programm ist wenn kompilierbar garantiert 
frei von (fast) alle Own/Share bezogenen Fehler - so lange der Kompiler 
keine Bugs hat :)

==> natürlich hat C++ auch Smart-Pointer und RAII mit der man viele 
Probleme unter Kontrolle bringt - aber eben nur wenn auch alle 
Entwickler mit machen,

Die grossen der Branche, also die mit sehr vielen Entwicklern und sehr 
viel C++-Code (10-100MioLOC) und Einfluss auf das Weltgeschehen, sage 
einstimmig, das ist alle ganz gut - wir haben aber trotzdem odentlich 
Probleme - und wer das nicht glaube hat einfach nicht wirklich Team- und 
im speziellen firmenübegreifende Entwicklungserfahrung oder hat keine 
Ahnung was ein Amazon AWS mit MioLOC C++ und 2 stellig Mio Anzahl Nutzer 
tagtäglich für Problemen mit Resourcen-Bedarf, Sicherheit gegen Angriff 
und.und.und ausgesetzt ist, ein google, Facebook etc. haben 
vergleichbare Größenordnung

MERKE: Mit Fehler die es nicht geben KANN muss man sich GAR NICHT 
beschäftigen

3. Ein Package und Build-System (aka Cargo)

Jeder Anfänger kann die Docs lesen und jeder andere Entwickler wird im 
Normalfall die selbe Sprache sprechen, fast jedes Projekt das sich nicht 
toal gegen den Standard wehrt baut out-of-the-box, das ist einfach was 
anderes als jeder-kann-es-machen-wie-er-will

unter C++ haben wir mittlerweile von Conan, vcpkg usw. schon etliche 
Systeme die immer mehr Verbreitung finden und es liegen x Proposal vor 
um C++ um ein solches System zu erweitern

ich hab beruflich mit fast allem Kontakt

MERKE: Vereinheitlichung ist erstmal einfacher für die meisten - an den 
Aufgaben wachsen kann jedes System

4. Ein auf Rust basiertes Build-System

natürlich haben wir da ein Wildwuchs an Systemen von CMake, meson, 
QMake, qbs, Scons - ich hab mit allen zu tun - und jedes ist irgendwie 
anders
, natürlich auch für embedded und, und, und

in Rust ist dein Build-System in Rust-Code und mehr braucht man 
eigentlich doch auch nicht

MERKE: die Sprache die du primär nutzt bleibt auch beim Build-System 
deine Sprache - kein Umdenken nötig

Nachteile:

1. Rust ist mit seinen 5-10 Jahren sehr jung für eine native Sprache mit 
so vielen echten Zwängen - go, C# oder andere nicht embedded-tauglichen 
oder VM-Sprachen sind einfach was anderes und können nur in der normalen 
Applikations-Entwicklung zum vergleich herangezogen werden - embedded 
und System-Entwicklung hat aber einfach noch viele viele kleine 
Anforderungen die eben auch sicher und performant realisierbar sein 
müssen

2. Rust ist oft arschlangsam beim kompilieren, liegt u.a. an dem stark 
organisch gewachsenem Kompiler und weil die Entwickler auch definitiv 
lange keine Fokus darauf gelegt haben - die wollte erst mal eine 
stimmige Syntax/Semantik entwickel/erforschen - und haben auch viele auf 
dem Weg dort hin gebaut und wieder völlig verworfen u.a. weil es eben 
nicht einfach nur ein C-Derivat ist (wie die meisten der anderen 
Sprachen)

Das ist jedem klar aber definitiv kein Argument gegen die 
Infrastruktur-Tools oder die Syntax und das macht die Entwickler auch 
nicht zu einem Haufen Idioten die gar nix können

3. Rust versucht gezielt mit vielen Zwängen die Entwickler auf die 
Algorithmen-Entwicklung zu fokusieren - das ist für viele aus der 
Kriegs- oder Anti-Autoritären-Erziehungs Generation zu wenig libreral, 
obwohl die meisten in ihren eigenen Firmen auch eher totalitärer 
Kontrolle über Infrastruktur-Tools und Codingstyle unterliegen oder 
ausüben

4. alles statisch gelinkt weil noch keine klare ABI für DLLs usw.

5. und, und, und...

Es wäre schön wenn wir vielleicht eine Positiv/Negativ-Liste aufbauen 
könnten

von cppbert (Gast)


Lesenswert?

Nachteil 6:

Um Rust ranken sich zu viele Mythen:

"Rust ist perfekt für alles und erzeugt immer super-schnellen Code"

Die Syntax ist nicht ganz leicht und keine Programmiersprache der Welt 
vollbringt Wunder

Rust hat aber definitiv mit der Aliasing-Kontrolle potenzial stärker 
optimierbar sein zu können als C/C++ (wenn GCC und LLVM da keine Fehler 
hätten)

"Rust ist super-kompliziert"

Kommt definitiv darauf an welche Sprachen-Hintergrund man hat und welche 
Ziele man verfolgt, für jemanden der nur Basic kann ist alles schwer für 
jemanden der 10 Sprachen kann ist Rust vielleicht nicht so kompliziert

Die Frage ist nur ob man die Vorteile nutzen will

"Rust ist zu streng/einschränkend"

Jeder ist streng und einschränkend in seiner Firma oder Projekt - gibt 
es jemanden unter euch der akzeptiert das jeder im Team den Code einfach 
so strukturell oder visuell schreibt wie er jetzt gerade Bock drauf hat?

In C++ gibt es immer die Leute die auch mit den Infrastruktur-Tools wie 
Build-System, oder Sanitzer etc. arbeiten - oder diese auch einführen 
und pflegen, schulen - es ist meist nicht das ganze Team welche alles 
Tools gleich gut versteht - weil zu viel Spezialisierung nötig ist

"Es kann einfach nicht sein das Rust diese Sicherheits-Garantien 
erfüllt"

Es sind schon viele Sprachen daran gescheitert - meist weil die dabei 
entstandene Syntax kaum eine praktikable Entwicklung erlaubt, die 
meisten Sprachen sind entweder total unsicher wie z.B. C oder schaffen 
es mit größerem Ressourcen-Bedarf (alle VM Sprachen) die Problem besser 
unter Kontrolle zu halten, die dann aber wieder nicht für alle 
embedded/Echtzeit/niedrig-Latenz-Systeme geeignet sind

Sicherheits-Garantie bedeutet nicht das es sicher ist wenn man es 
richtig anwendet - das ist nur eine mögliche Sicherheit

von cppbert (Gast)


Lesenswert?

Nachteil 7:

Rust hat erst vor kurzem, z.B. durch Amazon (die sponsorn alle Server 
und haben viele der Kern-Entwickler unter Vertrag genommen) und 
Microsoft (Azure und auch ein Teams im Aufbau) starke finanzielle 
Zuwendung ausserhalb von Mozilla erfahren

das ist verglichen mit der .Net-Entstehung  (stark durch den ganzen 
Microsoft-Konzern getrieben) , Java durch Sun/Oracle oder einem go mit 
starkem google-Hintergrund noch nicht wirklich viel Direkt-Finanzierung

das führt eben dazu das z.B. die Standard-Lib viel weniger umfangreich 
und ausgetesteter ist als bei Sprache/Platformen die erst hinter den 
Konzern-Türen so weit gebracht wurde das sie möglichst viele 
"Kauf-ich"-Argumente bei der Erstvorführung mitgebracht haben

Nachteil 8:

Rust will C/C++ im Embedded Bereich beerben - in dem ältesten und 
konservativstem Teil unserer Software-Landschaft, mit der größten Anteil 
an Spezalisierung bis runter auf die x Varianten von Kompilern und SDKs 
die von den Anbietern angepasst werden.

Das ist definitiv eine riesen Herausforderung - an der bisher jede 
Sprache ausser C (C++) und ein paar wenigen anderer, gescheitert ist - 
aber auch vielleicht weil die 1. zu Ressourcen-Hungrig waren oder 
einfach wirklich nur minimalsten Mehrwert gebracht haben

von Carl D. (jcw2)


Lesenswert?

cppbert schrieb:
>
Wäre es nicht eine Überlegung wert, künftig einen anderen (Gast-)Nick zu 
verwenden?

von cppbert3 (Gast)


Lesenswert?

Carl D. schrieb:
> cppbert schrieb:
>>
> Wäre es nicht eine Überlegung wert, künftig einen anderen (Gast-)Nick zu
> verwenden?

Wie sollen mich dann bitte meine unzähligen Fans erkennen?

von cppbert3 (Gast)


Lesenswert?

Carl D. schrieb:
> cppbert schrieb:
>>
> Wäre es nicht eine Überlegung wert, künftig einen anderen (Gast-)Nick zu
> verwenden?

Ich denke Rust braucht noch mind 5 Jahre bis zur Reife, bis dahin habe 
ich noch genug Zeit sehr viel C++ Code zu pflegen und zu schreiben, aber 
dann wechsel ich natürlich gleich auf rustbert

von Cppbert3 (Gast)


Lesenswert?

https://opensource.googleblog.com/2021/02/google-joins-rust-foundation.html

........
Memory safety security defects frequently threaten device safety, 
especially for applications and operating systems. For example, on 
Android, we’ve found that more than half of the security vulnerabilities 
we addressed in 2019 resulted from memory safety bugs. And this is 
despite significant efforts from Google and other contributors to the 
Android Open Source Project to either invest in or invent a variety of 
technologies, including AddressSanitizer, improved memory allocators, 
and numerous fuzzers and other code checking tools. Rust has proven 
effective at providing an additional layer of protection beyond even 
these tools in many other settings, including browsers, games, and even 
key libraries. We are excited to expand both our usage of Rust at Google 
and our contributions to the Rust Foundation and Rust ecosystem.
....

Half of the security vulnerabilities... und das von den Asan Erfindern 
:)

Beitrag #6582066 wurde von einem Moderator gelöscht.
von mh (Gast)


Lesenswert?

Cppbert3 schrieb:
> Half of the security vulnerabilities... und das von den Asan Erfindern
> :)
Und sie sagen zu rust:
Cppbert3 schrieb:
> an additional layer of protection
Das ist etwas anderes, als die Lösung des Problems.

von Vincent H. (vinci)


Lesenswert?

> Rust wandert ins System
> Eine wichtige Python-Bibliothek nutzt künftig teilweise Rust-Code. Bald wird
> es möglicherweise schwer, Linux-Systeme ohne Rust zu betreiben.

https://www.golem.de/news/linux-rust-wandert-ins-system-2102-154041.html

/edit
Dieses Forum braucht a gscheite Quote Funktion... -.-

: Bearbeitet durch User
von cppbert3 (Gast)


Lesenswert?

mh schrieb:
> Das ist etwas anderes, als die Lösung des Problems.

was erwartest du: die haben 1Mrd. Zeilen C/C++ Code - wäre ziemlich blöd 
den Code in so einem Werbungs-Post schlecht klingen zu lassen, oder?

und was ist das Problem bei "die Lösung des Problems"?

Rust verhindert zu 100% alle Formen von Speicher-Falschnutzungen und 
Data-Races zur Kompilezeit (bis auf Array-Indizierung) - für den ganzen 
Source-Code auf einmal - was fehlt da noch an kritischen Problemen? 
Logikfehler kann man immer machen

und jede Sprache die versucht bis auf die Array-Indizierung herunter 
eine Garantie für die Fehlerfreiheit einer Software zu liefern ist 
praktisch kaum relevant(oder nutzbar)

von Operator S. (smkr)


Lesenswert?

Jetzt wurde Rust in eine eigene Foundation ausgelagert. Mal schauen was 
daraus wird und ob sich dadurch mehr Vetrauen aus der Industrie gewinnen 
lässt.

https://blog.mozilla.org/blog/2021/02/08/mozilla-welcomes-the-rust-foundation/

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Na, wollnwa mal hoffen, dass nicht eines Tages auch mal sowas oder 
vergleichbares bei rust/cargo passiert:

https://www.heise.de/news/Sicherheitsforscher-bricht-ueber-Open-Source-Repositories-bei-PayPal-Co-ein-5051635.html

SCNR,
WK

von MaWin (Gast)


Lesenswert?

Dergute W. schrieb:
> Na, wollnwa mal hoffen, dass nicht eines Tages auch mal sowas oder
> vergleichbares bei rust/cargo passiert:

Warum sollte es?

von Dergute W. (derguteweka)


Lesenswert?

MaWin schrieb:
> Dergute W. schrieb:
>> Na, wollnwa mal hoffen, dass nicht eines Tages auch mal sowas oder
>> vergleichbares bei rust/cargo passiert:
>
> Warum sollte es?

Sollte die Frage nicht besser lauten: Warum sollte es nicht?

von cppbert3 (Gast)


Lesenswert?

Dergute W. schrieb:
> MaWin schrieb:
>
>> Dergute W. schrieb:
>>> Na, wollnwa mal hoffen, dass nicht eines Tages auch mal sowas oder
>>> vergleichbares bei rust/cargo passiert:
>>
>> Warum sollte es?
>
> Sollte die Frage nicht besser lauten: Warum sollte es nicht?

Alle Package System die von Remote Code oder Binaries ziehen können und 
werden solche Probleme haben, nmp, vcpg, cargo, pip und und und, 
natürlich muss man da diszipliniert sein, aber ich hätte absolut kein 
Problem sowas komplett entkoppelt, firmenintern zu nutzen, was ja auch 
möglich ist - oder ich mache mein deployment von 3rd parties weiterhin 
von Hand, Cargo steht mir da auch nicht im Weg

aber ja, man kann alles irgendwie korrumpieren und es wird leichter

von MaWin (Gast)


Lesenswert?

cppbert3 schrieb:
> Alle Package System die von Remote Code oder Binaries ziehen können und
> werden solche Probleme haben,

Das Problem war hier, dass Paypal ihr internes Buildsystem falsch 
konfiguriert haben. Einfach mal den Artikel lesen.
Das hat überhaupt nichts mit einer Lücke im Paketsystem zu tun.

Deshalb sehe ich auch nicht, was das mit Rust oder Cargo zu tun haben 
soll.

von Olaf (Gast)


Lesenswert?

> Deshalb sehe ich auch nicht, was das mit Rust oder Cargo zu tun haben
> soll.

Es gibt schon einen Zusammenhang.

Wenn du frueher zu Ahnungslos gewesen bist um etwas ans laufen zu 
bringen dann hat es halt nicht funktioniert und du hast solange gelernt 
bist du es hin bekommen hast.

Heute funktioniert alles beim erstenmal moeglichst einfach, aber es ist 
Mist weil alles in die Welt rausgeblasen wird und du die unmoeglichsten 
Abhaengigkeiten auf der Kiste hast. Nur wenn du Ahnung hast und dir 
Muehe gibst kannst du es abstellen. Die Welt wird idiotensicher und wir 
bekommen immer mehr Idioten weil das reicht sich durchzuschummeln.

Vergleich das mit Handys. Nokiahandys unter Symbian waren angeblich 
schlecht weil es nach dem kauf kompliziert war die Kiste soweit zu 
bekommen das man damit ins Internet konnte, Email usw funktioniert hat. 
Bei Android geht es beim ersten einschalten, aber du musst dreimal 
soviel Muehe reinstecken um zu verhindern das deine privaten Daten 
ueberrall in der Welt landen. Ueber die Folgen kannst du jeden Tag in 
der Zeitung lesen.
Software geht denselben Weg....

Olaf

von Le X. (lex_91)


Lesenswert?

Olaf schrieb:
> Bei Android geht es beim ersten einschalten, aber du musst dreimal
> soviel Muehe reinstecken um zu verhindern das deine privaten Daten
> ueberrall in der Welt landen. Ueber die Folgen kannst du jeden Tag in
> der Zeitung lesen.

Was steht denn da genau über Android-Handys?

Wenn ich in meiner (digitalen) Zeitung lese dass irgendwo Daten (z.B. 
Passwörter im Klartext) abgegriffen wurden dann so gut wie immer bei 
Firmen bzw. aus der Cloud. Also aus Linux-Serversystemen, nicht von 
Android-Smartphones.

: Bearbeitet durch User
von Olaf (Gast)


Lesenswert?

> Firmen bzw. aus der Cloud. Also aus Linux-Serversystemen, nicht von
> Android-Smartphones.

Das ist hier wohl eher OT, aber frag dich mal eine Sekunde wie bei 
Firmen wie Facebook, Google usw die Milliarden entstehen. Die muessen 
irgendwo was klauen das sie verkaufen koennen.

In der Software sehe ich das Problem das die Komplexizitaet immer 
groesser geworden ist. So gross das es immer schwerer faellt das alles 
zu durchschauen. Die Loesung sieht man darin die Systeme noch komplexer 
zu machen indem man diese Komplexizitaet nach aussen hin versteckt.

Olaf

von S. R. (svenska)


Lesenswert?

Le X. schrieb:
> Also aus Linux-Serversystemen, nicht von
> Android-Smartphones.

Aus Android-Smartphones muss man ja auch nichts abgreifen. Die senden 
die Daten ja von ganz allein dahin... und es ist nahezu unmöglich, das 
zu verhindern.

von Le X. (lex_91)


Lesenswert?

S. R. schrieb:
> Le X. schrieb:
>> Also aus Linux-Serversystemen, nicht von
>> Android-Smartphones.
>
> Aus Android-Smartphones muss man ja auch nichts abgreifen. Die senden
> die Daten ja von ganz allein dahin... und es ist nahezu unmöglich, das
> zu verhindern.

Mich hätte eigentlich nur interessiert was das für ominöse Folgen sind 
von denen Olaf spricht und wo man darüber lesen kann.
Olaf schrieb:
> aber du musst dreimal
> soviel Muehe reinstecken um zu verhindern das deine privaten Daten
> ueberrall in der Welt landen. Ueber die Folgen kannst du jeden Tag in
> der Zeitung lesen.
Aber die Antwort blieb er schuldig, seinem letzten Beitrag kann ich 
nicht wirklich Verständliches entnehmen.

von mh (Gast)


Lesenswert?

MaWin schrieb:
> cppbert3 schrieb:
>> Alle Package System die von Remote Code oder Binaries ziehen können und
>> werden solche Probleme haben,
>
> Das Problem war hier, dass Paypal ihr internes Buildsystem falsch
> konfiguriert haben. Einfach mal den Artikel lesen.
> Das hat überhaupt nichts mit einer Lücke im Paketsystem zu tun.
>
> Deshalb sehe ich auch nicht, was das mit Rust oder Cargo zu tun haben
> soll.

Wenn es nur Paypal wäre, ist diese Aussage vielleicht Ok. Da es 
mittlerweile allerdings deutlich mehr Unternehmen getroffen hat, sollte 
man nochmal überlegen, wo genau das Problem liegt.

Achso MaWin, wie hilft in diesem Fall dein heiliger Gral semantic 
versioning?

von Operator S. (smkr)


Lesenswert?

mh schrieb:
> Achso MaWin, wie hilft in diesem Fall dein heiliger Gral semantic
> versioning?

Wo bitte wurde das behauptet?

von mh (Gast)


Lesenswert?

Operator S. schrieb:
> mh schrieb:
>> Achso MaWin, wie hilft in diesem Fall dein heiliger Gral semantic
>> versioning?
>
> Wo bitte wurde das behauptet?

Da müsstest du die Beiträge von vor einem Monat lesen. Da hat MaWin im 
wesentlichen versucht, alle kiritschen Kommentare zu cargo mit Verweisen 
auf semantic versioning zu beantworten oder sie als völligen Unsinn 
bezeichnet.

Z.B.
MaWin schrieb:
> mh schrieb:
>> Du musst regelmäßig die Abhängigkeiten prüfen, ob
>> da noch alles so funktioniert wie es soll,
>
> Quatsch.
> Dank semantic versioning ist das natürlich nicht notwendig.
> Du bekommst automatisch alle rückwärtskompatiblen Weiterentwicklungen
> und Fixes.

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Da müsstest du die Beiträge von vor einem Monat lesen. Da hat MaWin im
> wesentlichen versucht, alle kiritschen Kommentare zu cargo mit Verweisen
> auf semantic versioning zu beantworten oder sie als völligen Unsinn
> bezeichnet.

Ach, habe ich das? Kann es vielleicht sein, dass das in einem völlig 
anderen Zusammenhang war?

Zitiere meine Aussage bitte, wenn du anderer Meinung bist.
Du wirst es nicht schaffen, weil es sie nicht gibt.

Könnten wir jetzt bitte wieder zum Thema zurückkommen? Rust?

von mh (Gast)


Lesenswert?

MaWin schrieb:
> Ach, habe ich das? Kann es vielleicht sein, dass das in einem völlig
> anderen Zusammenhang war?
Ja und Nein.
> Zitiere meine Aussage bitte, wenn du anderer Meinung bist.
> Du wirst es nicht schaffen, weil es sie nicht gibt.
Ok ...

mh schrieb:
> Damit ist man den Pflegeaufwand aber nicht los geworden, sondern verlegt
> ihn nur woanders hin. Du musst regelmäßig die Abhängigkeiten prüfen, ob
> da noch alles so funktioniert wie es soll, keine neuen unerwarteten
> Abhängigkeiten dazu gekommen sind, die Qualität noch deinen
> Anforderungen entspricht, kein Urheberrecht verletzt wird ...

MaWin schrieb:
> mh schrieb:
>> ...
> Quatsch.
> Dank semantic versioning ist das natürlich nicht notwendig.
> Du bekommst automatisch alle rückwärtskompatiblen Weiterentwicklungen
> und Fixes.

Und ja, ich sehe Malware in der Abhängigkeit als Qualitätsproblem.

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Und ja, ich sehe Malware in der Abhängigkeit als Qualitätsproblem.

Wie soll die Malware da plötzlich hinein kommen?
Warum soll mir ein Entwickler plötzlich Malware unterschieben?
Und warum ist das ein Problem des Tools?
Und warum ist das jetzt neu und unterscheidet sich von jedem anderen 
Updatemechanismus?

Ich glaube du hast immer noch nicht verstanden, wie crates.io 
funktioniert.

Das ist einzig und alleine ein soziales Problem.
Soziale Probleme lassen sich prinzipiell nicht mit Technik lösen.

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> Soziale Probleme lassen sich prinzipiell nicht mit Technik lösen.

Doch schon, durch Isolation, die man aber mit Rust/CreateCreate 
realisieren kann - wenn man das als nötig befunden hat

von Operator S. (smkr)


Lesenswert?

mh schrieb:
> Da müsstest du die Beiträge von vor einem Monat lesen

Hab ich, den Thread verfolge ich seit Beginn.

Ironischerweise, löst genau Semantic Versioning das beschrieben Problem 
von derguteweka (Warum auch immer das hier in einem Rust Thread gelandet 
ist...)

Wenn man nämlich nur schreibt Package Install MyFancyLib, dann holt er 
sich das Package mit der höchsten Version das er finden kann. Ein 
"Hacker" erstellt dann einfach auf der öffentlichen Paketsource ein 
MyFancyLib mit einer sehr hohen Version und Zack landet es in deinem 
System.

Wenn man aber die Version spezifiziert a la Package Install MyFancyLib 
1.2.5 dann holt er genau diese eine Version.

An dieser Stelle danke für deine kritische Sichtweise, sonst wäre es mir 
nicht bewusst geworden, dass Semantic Versioning tatsächlich genau 
dieses Problem löst.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Operator S. schrieb:
> Wenn man aber die Version spezifiziert a la Package Install MyFancyLib
> 1.2.5 dann holt er genau diese eine Version.
>
> An dieser Stelle danke für deine kritische Sichtweise, sonst wäre es mir
> nicht bewusst geworden, dass Semantic Versioning tatsächlich genau
> dieses Problem löst.

Ähm, nein, das hilft hier gar nichts. Irgendwann will man die 
Dependencies ja auch updaten, auch um mögliche Sicherheitslücken in 
alten Versionen zu schlissen. Dann macht man "npm/pip/cargo update", und 
was glaubst du, was dann passiert? Genau, es tut was es soll, und 
aktualisiert die Versionen der Abhängigkeiten. Da gibt es jetzt echt 
keinen Unterschied zwischen npm, pip, cargo, etc. Da müsste man schon 
selbst aufpassen, und nochmal genauer hin sehen...

Es ist aber nicht so, dass es keine Ideen gibt, um das Problem mit 
technischen mitteln zu lösen. Google hat letztens eine Dystopische 
Lösung für das Problem vorgeschlagen: Jeder braucht eine rechtsgültige, 
eindeutige Identität im Internet. Baut man scheisse, kann man sich einen 
neuen Job/Hobby suchen... [1]

(Man bedenke auch, dass vielerorts die Einführung von eIDs im Gange ist. 
Am Anfang alles freiwillig, aber sicher schreiben es Onlinedienste 
irgendwann vor, und dann ist ende mit Pseudonymität online, und wir 
enden mit einem von Firmen kontrollierten China-artigen Social Credit 
System...)


1) 
https://opensource.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting-discussion-around-vulnerabilities-in-open-source.html#:~:text=Goal:%20Authentication%20for%20Participants%20in%20Critical%20Software

von Operator S. (smkr)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Es ist aber nicht so, dass es keine Ideen gibt, um das Problem mit
> technischen mitteln zu lösen.

Es braucht keine Ideen um das Problem mit technischen Mitteln zu lösen, 
es ist bereits gelöst. Liest hier keiner mehr die Artikel, sondern nur 
die Überschrift?

Definiere einfach deine Paketquelle und die verlangte Version, dann 
nimmt dein Paketsystem nicht einfach die höchste Version die es im 
Internet finden kann.

🐧 DPA 🐧 schrieb:
> Irgendwann will man die
> Dependencies ja auch updaten, auch um mögliche Sicherheitslücken in
> alten Versionen zu schlissen. Dann macht man "npm/pip/cargo update", und
> was glaubst du, was dann passiert? Genau, es tut was es soll, und
> aktualisiert die Versionen der Abhängigkeiten.

Genau und dieser Schritt macht man von Hand. Es ist eine bewusste 
Aktien, dass man was verändert hat. Wenn man dann einfach nimmt was 
einem hergeworfen wird, sollte man sich ein anderes Handwerk suchen. Und 
ich meine hier nicht den Fall, dass ein Paket von Version 1.2.3 auf 
Version 2.1.0 ein Update erhalten hat und man bis ins letzte Detail 
nachschauen muss, was ist anders geworden. Wenn aber aus Version 1.2.3 
das Update Version 22.0.0 macht, sollte man das nachprüfen.
In der oben verlinkten "Sicherheitslücke" geht es aber darum, dass im 
Buildsystem automatisch die neueste Version genommen wird, wenn keine 
Version spezifiziert wurde. Ohne dass man bewusst nach einem Update 
verlangt hat.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Genau, es tut was es soll, und
> aktualisiert die Versionen der Abhängigkeiten.

Bitte lies den Beitrag von Operator S. noch einmal.
Dann informiere dich, was Semantic Versioning ist und was mit diesem 
Satz gemeint ist:

> Wenn man aber die Version spezifiziert a la Package Install MyFancyLib
> 1.2.5 dann holt er genau diese eine Version.

Und dann informiere dich, wie crates.io und Cargo funktionieren.

Das ist und bleibt PEBCAK.

Wenn ich Cargo sage, dass es immer die neuste Version der Schiene ziehen 
soll, egal von welcher Quelle, dann macht es genau das. Oh Wunder.
Wenn ich Cargo sage, dass es das nicht tun soll, tut es das nicht.
Wie ich schon vor einiger Zeit schrieb: Es ist ein Konfigurationsfehler.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Operator S. schrieb:
> Es braucht keine Ideen um das Problem mit technischen Mitteln zu lösen,
> es ist bereits gelöst. Liest hier keiner mehr die Artikel, sondern nur
> die Überschrift?

Nein, Supply Chain Attacks sind real, und auch heute immer noch ein 
Problem. Das kannst du gerne leugnen, ändert aber nichts daran, dass 
diese überall immer mal wieder auftreten.

Operator S. schrieb:
> Definiere einfach deine Paketquelle und die verlangte Version, dann
> nimmt dein Paketsystem nicht einfach die höchste Version die es im
> Internet finden kann.

Ich nehme an du beziehst dich da auf Cargo.lock und co., wenn Projekte 
das direkt in ihrer Cargo.toml machen würde, würde das ja das ganze 
semver Konzept ad absurdum führen. Updaten muss man aber trotzdem von 
zeit zu zeit.

> Operator S. schrieb:
> 🐧 DPA 🐧 schrieb:
>> Irgendwann will man die Dependencies ja auch updaten,
>> ...
> Genau und dieser Schritt macht man von Hand. Es ist eine bewusste
> Aktien, dass man was verändert hat. Wenn man dann einfach nimmt was
> einem hergeworfen wird, sollte man sich ein anderes Handwerk suchen.

Das ist mir schon klar. Wenn man aber immer mal wieder liest, wie ein 
Security Researcher mal wieder was bei allen möglichen Firmen 
eingeschleust hat, dürfte ja wohl klar sein, dass das nicht dem 
entspricht, was in der Realität in der Regel gemacht wird. Ist ja auch 
nicht erstaunlich, wenn Projekte 100te Dependencies haben, die man 
updaten muss.

Operator S. schrieb:
> Und ich meine hier nicht den Fall, dass ein Paket von Version 1.2.3 auf
> Version 2.1.0 ein Update erhalten hat und man bis ins letzte Detail
> nachschauen muss, was ist anders geworden. Wenn aber aus Version 1.2.3
> das Update Version 22.0.0 macht, sollte man das nachprüfen.

Bei Supply Chain Attacks ist der Angreifer nicht gezwungen, die Major 
Version zu ändern, im Gegenteil, man will ja nicht auffallen. Deshalb 
ist es in dem Bezug völlig egal, ob das nur ein Minor Update ist, 
nachprüfen sollte man trotzdem. Nur um zu schauen, ob es noch läuft, 
kann man auch automatisierte Tests machen, das ist eine andere 
Baustelle.

Operator S. schrieb:
> In der oben verlinkten "Sicherheitslücke" geht es aber darum, dass im
> Buildsystem automatisch die neueste Version genommen wird, wenn keine
> Version spezifiziert wurde. Ohne dass man bewusst nach einem Update
> verlangt hat.

Naja, eigentlich war da das Problem mit Privaten vs. Öffentlichen Repos. 
Das ist aber nur einer von vielen Wegen, wie sowas passieren kann. Ein 
Projekt wechselt den Maintainer, jemand lädt versehentlich seine 
Zugangsdaten in Git mit hoch, und schwups, schon ist es passiert. Wobei, 
bei Crates scheint das seltener zu passieren als z.B. bei Chrome 
Extensions.

MaWin schrieb:
> mh schrieb:
>> Und ja, ich sehe Malware in der Abhängigkeit als Qualitätsproblem.
>
> Wie soll die Malware da plötzlich hinein kommen?
> Warum soll mir ein Entwickler plötzlich Malware unterschieben?

Bei hunderten Abhängigkeiten würde ich mich doch eher fragen, warum 
sollte es darunter kein schwarzes Schaf geben?

Semantic Versioning kann eine nette und nützliche Sache sein, aber 
Supply Chain Attacks kann es definitiv nicht verhindern.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> jemand lädt versehentlich seine
> Zugangsdaten in Git mit hoch, und schwups, schon ist es passiert.

Dann ist dieser Entwickler halt unfähig. Gegen Unfähigkeit kann man 
leider wenig machen.

Höchstens so etwas:

https://doc.rust-lang.org/cargo/reference/manifest.html#the-publish-field

🐧 DPA 🐧 schrieb:
> Bei hunderten Abhängigkeiten würde ich mich doch eher fragen, warum
> sollte es darunter kein schwarzes Schaf geben?

Ein Entwickler, der lange gute Versionen herausbrachte, bringt plötzlich 
Malware heraus?
Wann ist das einmal passiert? Das ist doch ein Fall, den du dir jetzt 
herbeikonstruierst, um Recht zu behalten.

Und wo ist der Unterschied zu jedem anderen System? z.B. Linux-Repos.

Niemand, auch nicht Cargo, zwingt jemanden zu einem Update.
Früher im Thread wurde behauptet, dass Leute ihre Dependencies gerne 
100% auditieren wollen. Ja dann bitte. Tut das. Das würde ja dieses 
konstruierte Malwareproblem vollständig lösen.

Das hat alles überhaupt gar nichts mit Rust zu tun!

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin schrieb:
> 🐧 DPA 🐧 schrieb:
>> jemand lädt versehentlich seine
>> Zugangsdaten in Git mit hoch, und schwups, schon ist es passiert.
>
> Dann ist dieser Entwickler halt unfähig. Gegen Unfähigkeit kann man
> leider wenig machen.

Nicht zwangsläufig. Sowas ist schnell mal passiert, und könnte jedem 
passieren.

> 🐧 DPA 🐧 schrieb:
>> Bei hunderten Abhängigkeiten würde ich mich doch eher fragen, warum
>> sollte es darunter kein schwarzes Schaf geben?
>
> Ein Entwickler, der lange gute Versionen herausbrachte, bringt plötzlich
> Malware heraus?
> Wann ist das einmal passiert? Das ist doch ein Fall, den du dir jetzt
> herbeikonstruierst, um Recht zu behalten.

Die Maintainer von Software können sich auch ändern, beim Updaten schaut 
da selten jemand nach. Und auch sonst gibt es viele Wege, wie soetwas 
unabsichtlich passieren kann.

z.B. hatte es mal kurz bootstrap erwischt: 
https://nakedsecurity.sophos.com/2019/04/08/bootstrap-supply-chain-attack-is-another-attempt-to-poison-the-barrel/

z.B. Chrome extensions werden gerne mal verkauft: 
https://www.theregister.com/2021/01/07/great_suspender_malware/

Manchmal ist es auch nur ein blöder typo: 
https://github.com/jsdelivr/jsdelivr/issues/18070 (Hat damals glaube ich 
einige getroffen)

Es gäbe noch mehr Beispiele, ist alles schon passiert.

MaWin schrieb:
> Und wo ist der Unterschied zu jedem anderen System? z.B. Linux-Repos.

Das hängt jeweils von der konkreten Distribution und dessen Prozessen 
ab. Zumindest bei fixed Release Distros gibt es oft einen zumindest 
teilweise split zwischen Distro Mantainern und Entwicklern / 
Projektmaintainern. Eine Art 2 Augenprinzip, wenn man will. Die Distro 
Maintainer kennen sich entweder untereinander (kleine Distros), gehören 
zur selben Firma (z.B. RedHat), oder müssen anderweitigen Prozessen und 
Anforderungen genügen (z.B. debian), etc. Es gibt zudem normalerweise 
gewisse Moderadionsstrukturen, nicht jeder kann einfach Zeugs hochladen, 
und wie ein Maintainer mit Problemen umgeht, sowie soziale Aspekte, 
können jenachdem auch beachtet werden. Ausserdem ist es auch möglich, 
problematische Software zu entfernen. Die Pflege / das Managemant der 
Repos ist oft das entscheidende Alleinstellungsmerkmal von 
Distributionen.

MaWin schrieb:
> Niemand, auch nicht Cargo, zwingt jemanden zu einem Update.

Nie upzudaten ist aber auch nicht unbedingt Sicherheitstechnisch ideal.

MaWin schrieb:
> Das hat alles überhaupt gar nichts mit Rust zu tun!

Und deshalb schützt cargo nun plötzlich doch vor Supply Chain Attacks?
Ja ja, schon klar, nur Reden, wenn es pro Cargo und pro Rust ist, ist 
notiert 🙄

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Und deshalb schützt cargo nun plötzlich doch vor Supply Chain Attacks?

Wer hat das behauptet?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin schrieb:
> 🐧 DPA 🐧 schrieb:
>> Und deshalb schützt cargo nun plötzlich doch vor Supply Chain Attacks?
>
> Wer hat das behauptet?

Operator S. schrieb:
> Ironischerweise, löst genau Semantic Versioning das beschrieben Problem
> von derguteweka

Klar, das war weniger allgemein gehalten gedacht, läuft am Ende aber auf 
das heraus.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> läuft am Ende aber auf das heraus.

Es läuft einzig und alleine darauf hinaus, dass du mir Aussagen 
unterstellst, die ich nicht getätigt habe.

Und die dazu noch aus dem Zusammenhang gerissen sind.

Aber das machst du natürlich extra.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Nie upzudaten ist aber auch nicht unbedingt Sicherheitstechnisch ideal.

Was willst du eigentlich?

Du willst nicht updaten, weil das zu Sicherheitsproblemen führen könnte. 
Die neue Version könnte ja Malware enthalten, weil der Maintainer 
plötzlich zum Gangster wird.

Du willst updaten, weil das zu Sicherheitsproblemen führen könnte. Die 
alte Version könnte ja Bugs enthalten.

Wie soll man das lösen?
Es ist unlösbar.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin schrieb:
> 🐧 DPA 🐧 schrieb:
>> läuft am Ende aber auf das heraus.
>
> Es läuft einzig und alleine darauf hinaus, dass du mir Aussagen
> unterstellst, die ich nicht getätigt habe.

Keineswegs. Ich habe dich lediglich darauf hingewiesen, warum das ganze 
hier Relevant wurde:

🐧 DPA 🐧 schrieb:
> MaWin schrieb:
>> Das hat alles überhaupt gar nichts mit Rust zu tun!
> Und deshalb schützt cargo nun plötzlich doch vor Supply Chain Attacks?

Supply Chain Attacks in Relation zu Semantic Versioning / cargo war die 
relevante Problematik, um die es in der momentanen Argumentation seit 
Beitrag #6584067 ging. Das ist auch, weshalb das ganze hier überhaupt 
relevant wurde. Ich dachte es wäre klar, worüber wir Diskutieren?

MaWin schrieb:
> Was willst du eigentlich?

Zu einem klareren Bild der ist-Situation und existierenden Problematiken 
beitragen?

MaWin schrieb:
> Wie soll man das lösen?
> Es ist unlösbar.

Ja, das ist so.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Ich dachte es wäre klar, worüber wir Diskutieren?

Ja, das ist klar.
Über alles, aber nicht mehr über Rust.

> Ja, das ist so.

Dann können wir es ja damit abschließen, dass auch Rust unlösbare 
Probleme nicht löst.

Ok?

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> Ja, das ist klar.
> Über alles, aber nicht mehr über Rust.

für den Rest:

"Rust" ist keine Platform sondern die Programmiersprache

Cargo ist der Standard Package-Manager und das Buildsystem für Rust - 
aber sogar das muss man nicht nutzen

und der Package-Manager kann so verantwortungslos (ich geben keine 
Versionen and und ziehe immer latest) bis zur absoluten statik (mein 
eigenes lokales crate wo ich alles von Hand rein tragen muss) 
konfiguriert werden - da kann man so viele Review Prozesse einschieben 
wie man braucht und will

Alle Package-Manager können das - und ja, die werden von Millionen 
Leuten verwendet und das kann gefährlich sein - sogar GitHub und GitLab 
machen das wenn man z.B. die submodule updated - von irgendeinem Projekt

und die Programmiersprache Rust ist auch nicht deswegen schlechter als 
andere weil ihr Standard-Package-Manager die gleichen unlösbaren 
Sicherheitsprobleme erzeugen kann wie jedes andere diese Systeme - also 
um was geht es?

Ich arbeite u.a. in Projekte in dem alles durch ordentliche 
Review-Phasen laufen muss und jedes noch so kleine 3rd-Party Update 
einen riesen Aufwand verursacht - die haben teilweise auch lokale 
Package-Manager für C++ im Einsatz und die Packages die da rein kommen 
sind eben reviewed

Vetrauen ist alles und Kontrollen machen die wenigsten - 
höchstwahrscheinlich sogar die am wenigsten die hier so gross davon 
reden wie wichtig das alles ist...

von mh (Gast)


Lesenswert?

Operator S. schrieb:
> mh schrieb:
>> Da müsstest du die Beiträge von vor einem Monat lesen
>
> Hab ich, den Thread verfolge ich seit Beginn.
>
> Ironischerweise, löst genau Semantic Versioning das beschrieben Problem
> von derguteweka (Warum auch immer das hier in einem Rust Thread gelandet
> ist...)
>
> Wenn man nämlich nur schreibt Package Install MyFancyLib, dann holt er
> sich das Package mit der höchsten Version das er finden kann. Ein
> "Hacker" erstellt dann einfach auf der öffentlichen Paketsource ein
> MyFancyLib mit einer sehr hohen Version und Zack landet es in deinem
> System.
>
> Wenn man aber die Version spezifiziert a la Package Install MyFancyLib
> 1.2.5 dann holt er genau diese eine Version.

Und du stellst sicher, dass in MyFancyLib die Dependencies 100% korrekt 
definiert sind? Und in den Dependencies der Dependencies von MyFancyLib?
Nachdem ich eben etwas auf crates.io gestöbert habe, muss man das wohl 
explizit selbst prüfen, da die meisten crates Dependencies explizit oder 
implizit als "Caret requirements" angeben. Ich hab einige ziemlich lange
Ketten verfolgen können.
Es ist auch klar warum das so ist. Niemand hat lust sich häufig 
"Dependency Resolution failed" vom resolver zu beschäftigen.

🐧 DPA 🐧 schrieb:
> Wobei,
> bei Crates scheint das seltener zu passieren als z.B. bei Chrome
> Extensions.
Bleibt die Frage, ob es tatsächlich so ist, oder ob es nur scheint. Die 
Zielgruppe für Chrome Extensions ist vermutlich deutlich größer.

cppbert schrieb:
> und die Programmiersprache Rust ist auch nicht deswegen schlechter als
> andere weil ihr Standard-Package-Manager die gleichen unlösbaren
> Sicherheitsprobleme erzeugen kann wie jedes andere diese Systeme - also
> um was geht es?

Wenn ich mich richtig erinnere, hast du behauptet, dass cargo den 
Pflegeaufwand für Software reduziert:
mh schrieb:
> cppbert schrieb:
>> Jede Library hat die 5000.Implementation von irgendeinem Micro-Scheiss
>> im Bauch die so viel Pflege-Energie frisst - das versucht Rust mit einer
>> Zerlege- es-in-Libs-und-verteile-die-leicht zu reduzieren
>
> Damit ist man den Pflegeaufwand aber nicht los geworden, sondern verlegt
> ihn nur woanders hin. Du musst regelmäßig die Abhängigkeiten prüfen

In dem gleichen Beitrag hast du das übrigens auch als Vorteil von rust 
angepriesen:
cppbert schrieb:
> 4. Anstatt das jedes noch so kleine Projekt Self-Contained ist baut Rust
> einfach darauf das sich die Code-Duplikation über viele, gut gepflegte
> Libraries reduziert die in den heutigen Projekten in Mio Zeilen Code
> rumgurken

von Operator S. (smkr)


Lesenswert?

@ mh, dann benutz es doch einfach nicht

von cppbert (Gast)


Lesenswert?

mh schrieb:
> Wenn ich mich richtig erinnere, hast du behauptet, dass cargo den
> Pflegeaufwand für Software reduziert:
> mh schrieb:
>> cppbert schrieb:
>>> Jede Library hat die 5000.Implementation von irgendeinem Micro-Scheiss
>>> im Bauch die so viel Pflege-Energie frisst - das versucht Rust mit einer
>>> Zerlege- es-in-Libs-und-verteile-die-leicht zu reduzieren
>>
>> Damit ist man den Pflegeaufwand aber nicht los geworden, sondern verlegt
>> ihn nur woanders hin. Du musst regelmäßig die Abhängigkeiten prüfen
>
> In dem gleichen Beitrag hast du das übrigens auch als Vorteil von rust
> angepriesen:
> cppbert schrieb:
>> 4. Anstatt das jedes noch so kleine Projekt Self-Contained ist baut Rust
>> einfach darauf das sich die Code-Duplikation über viele, gut gepflegte
>> Libraries reduziert die in den heutigen Projekten in Mio Zeilen Code
>> rumgurken

das sind zwei paar Stiefel

Das einen ist die undurchsichtige und Codelastige alles-selber-machen 
Kultur durch eine es-gibt-viele-kleine Crates die sich auf Aufgaben 
konzentrieren Kultur zu ersetzen - die Libs werden kleiner und überhaupt 
reviewbarer

Das ist das Konzept das wir alle intern mit jeder unserer eigenen 
Komponenten fahren - was vom Grundsatz nicht falsch und nicht wirklich 
diskutierbar ist

bei C/C++ klappt das einfach Aufgrund des schwierigen Deployments 
(welche Make-Tool, 3rd-Parties, etc.) nicht so gut über die 
Projektgrenzen hinweg,  ist aber eher eine historische Schwäche als ein 
gewolltest Konzept von C/C++

Das zweite ist die Menge der Entwicklern die plötzlich Einfluss auf dein 
Projekt haben könnten - da geben ich dir recht das es nicht einfacher 
wird - aber Monolithen-Libs mit viel gemeinsamen Redundanzen ist es eben 
auch nicht - da wähle ich lieber die Qualität ergibt sich durch die 
Community - und wenn ich viele 3rd-Parties brauche bin verliere ich auch 
mit C/C++ recht schnell die Kontrolle (falls man wirklich nicht auf die 
3rd-Parties verzichten kann)

und ich denke die wenigsten hier machen überhaupt irgendwelche Reviews 
von 3rd-Parties - wenn es kompiliert und die Tests laufen ists gut wird 
wohl die Standard-Devise sein, die Community der Libs oder gar die 
Kern-Entwickler haben auch die wenigsten auf ihrer Kontakt-Liste also 
ist die Qualität nur gut weil man nix negatives im Internet liesst oder 
eben keinen 3rd-Parties hat

noch dazu heisst es ja immer das Rust nicht nötig ist weil jede Firma 
sowiso nur Profi-Entwickler angestellt haben sollte - d.h. die können 
sich dann in Rust aufhören mit den internen Problemen zu beschäftigen 
sondern nur noch Algorithmik und die Sicherheits-Probleme durch die 
vielen 3rd-Party Abhängigkeiten bekämpfen :)

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Und du stellst sicher, dass in MyFancyLib die Dependencies 100% korrekt
> definiert sind?

nein. Ich nicht.
Das war aber auch nie meine Anforderung.

Beitrag #6602631 wurde von einem Moderator gelöscht.
von cppbert3 (Gast)


Lesenswert?

mit dem neuen VS2019 16.9 Release können wir jetzt auch unter 
Windows/VStudio mit dem ASAN arbeiten - raus aus der Beta-Phase - läuft 
super - "leider" keine Findings da mein Code ja schon unter Linux seit 
einigen Jahren unter Sanitzer Kontrolle steht

https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes#16.9.0

Und für die "C++ ist ausreichend perfekt durch ASAN"-Fraktion:

Stellt euch mal vor wenn google nicht aus Eigeninitative die Sanitizer 
entwickelt hätte - wohlgemerkt nach "Jahrzehnten" der C/C++ Existenz, 
was würde eigentlich dann weiterhin für die Memory-Sicherheit bei C/C++ 
Applikationen unter Windows sorgen - der olle Intel Inspector, Dr. 
Memory...?

und ja ist versteht das auch Rust einen Neuentwicklung ist - nur ist da 
sowas von Anfang an dabei, C/C++ hat dafür 25 Jahre auf einen 
Gross-Konzern warten müssen

von cppbert3 (Gast)


Lesenswert?

und auch wenn ihr mir nicht glaubt (oder ich nur viele Idioten kenne)

Es gibt sogar C/C++ Entwickler die nicht verstehen was an Rust besser 
ist UND die zusätzlich auch keinen Sinn in den Sanitizern sehen

Noch besser: die den Sinn von Sanitizer erst verstehen wenn man ihnen
im VStudio, in ihrem Code einen durch den ASAN gefundenen Bug zeigen 
kann - meistens wird dann ganz schnell aus einem unwissenden Kritiker 
ein Missionar

ganz nach dem Motto: Erst wenn ich den Schimmel wirklich schmecken kann 
erkennen ich das irgendwas mit meinem weiß pelzigen Brot nicht stimmt :)

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

cppbert: Ich würde nicht soweit gehen, diese Idioten als Idioten zu 
bezeichnen(Spässle). Der Mensch ist unbeweglich. Besonders geistig. Ohne 
jemanden damit beleidigen zu wollen und natürlich ist das oberflächlich.

Was ich hier noch einmal betonen will ist, dass absolut kein Zwang 
besteht auf etwas Vernünftigeres und womöglich "Vesseres" zu wechseln.
Das ist eine Sache.
Aber die eigene Beratungsresistenz und Vorurteile unter den anderen 
Programmierern und Programmierer-Nachwuchs-Volk zu verteilen ist 
peinlich und kurzsichtig. Schade, dass man dies mit Scheuklappen nicht 
sehen kann.

Hab viel Geduld und Kraft, lieber cppbert3. Dieser sinnlose Streit über 
das richtige Werkzeug hört nämlich niemals auf.
Es ist wie mit dem Geschmack. Manche mögen ihren Käse erst so richtig 
mit viel viel Schimmel. Die Perversen haben sogar lateinische 
Kosenamen;)

Um zum Thema zurück zu kommen: Rust? Cool. Das bleibt. Alleine schon die 
163 Libs die mein Amateur-Kannst-Mich_Mal-Programm zum befragen meines 
Fernsehers (MIPS VU+ Box, Enigma2) braucht. Schrecklich! Und dann 
funktioniert das auch noch Lokal (x86) und Remote (mipsel). Okay so 
einfach war es auch nicht. Ich fühlte mich nicht sehr gut als ich den 
Pull Request für das MIPS OpenSSL in Rust hochgeladen habe. Habe aber 
bisher noch keine Morddrohungen oder einen Regressanspruch erhalten.

Cargo ist nicht Rust. Es ist nur in Rust geschrieben. Lasst uns doch mal 
gegen Conan schelten und deswegen C++ verdammen. Das ist nur gut, wenn 
man Beiden, den Conan und C++ Entwicklern auf die Nerven gehen will. 
Python libraries, Node-Chaos? ... Wer blickt da schon durch? Das ist 
aber ein völlig anderes Problem, nämlich der Versionsverwaltung und des 
Paketmanagements. Kein Alleinstellungsmerkmal von Rust UND Cargo!

Ach übrigens:
1
std::auto_ptr<MaWin> cppBert ...
Jeder macht mal Fehler. (Die Klassen- und Variablennamen des Beitrags 
sind frei erfunden. Etwaige Ähnlichkeiten mit tatsächlichen 
Begebenheiten oder lebenden oder verstorbenen Personen wären rein 
zufällig.)

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

Keine Ahnung was "Vesseres" bedeuten soll.
... vielleicht etwas besseres Verwässertes?:)

Außerdem: node != npm und pip != python

: Bearbeitet durch User
von 🐧 DPA 🐧 (Gast)


Lesenswert?

Jedzia D. schrieb:
> Cargo ist nicht Rust. Es ist nur in Rust geschrieben. Lasst uns doch mal
> gegen Conan schelten und deswegen C++ verdammen.

Mir ist bisher noch kein C++ Projekt über den Weg gelaufen, bei dem 
conan der Hauptweg ist, wie man an die Dependencies kommt und alles 
Kompiliert. Bis vorhin habe ich von conan tatsächlich noch nie gehört.

Bei Cargo hingegen sieht das alles ganz anders aus, da muss man suchen, 
um etwas zu finden, was es nicht nutzt.

Die Situation ist schlicht nicht vergleichbar.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Zudem wurde hier auch immer klar angegeben, ob ein Problem/Vor-/Nachteil 
mit Cargo oder mit Rust besteht.

Wäre die Diskussion gegen C++, und jemand würde sagen, verwendet nicht 
Conan, weil XY, hätte ich damit ehrlich gesagt kein Problem.

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

- Ja sind Build-System und Compiler jetzt verschiedene Dinge oder nicht? 
(JA)
- Welche Verrückte würde rustc (der Compiler) mit einem Makefile oder 
CMake benutzen? (Anwesende ausgeschlossen). Wer koa, der koa.

> Bis vorhin habe ich von conan tatsächlich noch nie gehört.
Tut mir leid:( Und in der Tat, das sind völlig andere Probleme als die 
der Sprachsemantik, Speichersicherheit, etc.

🐧 DPA 🐧 schrob außerdem:
> Zudem wurde hier auch immer klar angegeben, ob ein Problem/Vor-/Nachteil
> mit Cargo oder mit Rust besteht.
Das muss eine Parallelwelt sein, in der Du in diesem Faden hoch scrollen 
kannst und nicht alles durcheinander geworfen wird. Ist ja auch egal, 
kost nur Haare.

Satire: Ich komme aus einer Welt der guten Vorsätze. Aber alles endet 
irgendwann auf einem riesigen Scheißhaufen, wie etwa:
- das Repository von NPM,
- der letzte PlatformIO Library Manager sprang in den Fluss,
- pypi.org's hackertools infizieren sich schon selbst,
- Leiningen ist viel zu cool für das alles,
- Unstable, nightly-only --cargo-features sind so tief verschachtelt, 
dass sie ein eigenes Bewusstsein entwickeln und die Menschen als 
Bedrohung ansehen, besonders MaWin. Tja, gegen das fehlerhafte setzen 
eines Index innerhalb der Array-Grenzen (Bounds), hilft auch kein 
Bounds-Checker. (Tut  mir leid, MaWin:))
- etc. pp., alles von Muttern was eingemacht wird und ein Schild für 
späteres beäugen bekommt...

🐧 DPA 🐧 schrieb:
> Wäre die Diskussion gegen C++, und jemand würde sagen, verwendet nicht
> Conan, weil XY, hätte ich damit ehrlich gesagt kein Problem.
Klar. Mir sind die Anderen erst einmal anders und ich kenne mich bei mir 
am Besten aus. Etwa meine persönlichen Templates und in Jahren 
gewachsenen Monstrositäten. Das ist alles subjektiv und funktioniert für 
mich flott, einwandfrei und einleuchtend, manchmal bin ich sogar richtig 
produktiv;)

Ich finde dein Gedankenexperiment etwas schräg[1]: Conan ist nur das 
Programm. Dahinter stecken XYZ ... 2 Leute? Eine Firma? Eine Community? 
... die das Gertriebe der ganzen Packetmanager Chausse ölt.
Kein Problem mit der ganzen "Sache" zu haben ist übrigens 
selbstverständlich. Es geht mich, dich oder sonnst wen nichts an, wie 
jemand seine Arbeit verrichtet. Kritik ist erlaubt, klar, Respekt aber 
auch. Conan kannst Du mit jedem Community/Firmen betriebenen 
Datenbanksystem, das organisch wächst, ersetzen.

Bla, Ich bitte nur darum die einzelnen Schichten der Sprachumgebung zu 
trennen, oder vielleicht einmal darüber nachzudenken. DPA, Du hast 
natürlich auch Recht: Es ist ein Ökosystem.

Der Rest der Welt oooch;)

[1] Das Fass von den n^m Möglichkeiten der Objektivität, also möglicher 
(und legitimer) Toolverwendung, Expression, Impression, Iteration und 
was auf der Menükarte der Verfügbarkeiten gerade steht, machen wir nicht 
auf?

Rust? Werkzeusch. Basta!

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

"2 Leute? Eine Firma? Eine Community?" bezieht sich nun-chalant 
natürlich nicht auf das Repository von Conan.

Jeder kann selbst auf https://conan.io/center/ nachschauen. Das wird 
ohne jede Frage von Fröschen durchorganisiert.
Ich bezog mich da auf ALLLLLEEEES !!! Also meistinklusiv auf jeden 
erdenklichen Paketmanager und Paketmanagerin auf diesem Planeten und 
nicht spezifisch auf die guten Leute von Conan.

Kein plan von Fröschen, allerdings...

[Hint] JFrog ConanCenter

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

DPA: "Tut mir leid:(" ist natürlich scherzhaft gemeint.

... weil ich die Schuldige bin, die Conan in dein Leben bringt.
Verzeihung, also noch einmal;) (Mit einem Zwinkern)

von cppbert (Gast)


Lesenswert?

google unterstüzt Rust im Linux Kernel - (und Nein, ihr eigenes Go kann 
nicht im Kernel genutzt werden)

https://security.googleblog.com/2021/04/rust-in-linux-kernel.html

der Binder-Code in Rust sieht fiese aus - liegt aber auch daran das da 
viel C-Binding/FFI Sachen zu sehen sind

Linus und Greg sind weit, weit offener als zu den damaligen C++ 
Diskussionen :)

ich bin gespannt ob diese Integrations-Bestrebungen zu weiteren 
Verbesserungen in Rust führen und schlussendlich auch die Integration in 
den Kernel passiert und ob das auch die GCC Frontend-Entwicklung 
befeuert

mittlerweile sind alle Grossen der Branche für ihre Low-Level 
Entwicklung mehr oder minder auf den Rust Zug aufgesprungen - google, 
Microsoft, Amazon, Facebook... egal wie man die Sache sieht - Rust in 
den Bereichen ihren eigenen Produkten/bisherigen Strategien vorzuziehen 
ist schon eine Aussage

und Nein, kein Mensch der bei klarem Verstand ist möchte dann alles 
portieren :) - sagt auch niemand, und denkt nicht mal irgendjemand

und Nein, eine C/Rust Mischung ist nicht per se der Teufel - nur für die 
Leute die immer gleich alles portieren wollen :)

von Olaf (Gast)


Lesenswert?

> google unterstüzt Rust im Linux Kernel - (und Nein, ihr eigenes Go kann
> nicht im Kernel genutzt werden)

Jaja, ich hab das hier gelesen:

https://www.heise.de/news/Startschuss-fuer-Rust-Entwicklung-im-Linux-Kernel-6017060.html

Der Artikel hat mir mal wieder klar gemacht was in der heutigen 
Entwicklung alles so falsch laeuft. Ich zitiere mal einen Satz:

    Ein Kernel-Crate (Rust-Bezeichnung für Bibliothek) stellt
    die Kernel-API für Rust-Module bereit.

Diese ganzen Bullshitbingoschwachkoepfe denken sich fuer den banalsten 
Unsinn eigene Sandkastenwoerter aus, die sie dann noch anderen erklaeren 
muessen weil sonst keiner mit ihnen spielen will, und wundern sich das 
ihren Kram keiner will?

Olaf

von MaWin (Gast)


Lesenswert?

Olaf schrieb:
> Diese ganzen Bullshitbingoschwachkoepfe denken sich fuer den banalsten
> Unsinn eigene Sandkastenwoerter aus

Welcher Begriff stört dich denn?

von Rolf M. (rmagnus)


Lesenswert?

Ich vermute, er meint das:

Olaf schrieb:
> Ein Kernel-Crate (Rust-Bezeichnung für Bibliothek)

Warum nennt man eine Bibliothek "Crate" statt "Bibliothek"? Ist so 
ähnlich wie bei Arduino, wo ich mich schon immer gefragt habe, warum ein 
Programm nicht "Programm" heißt, sondern "Sketch".

von MaWin (Gast)


Lesenswert?

Rolf M. schrieb:
> Warum nennt man eine Bibliothek "Crate" statt "Bibliothek"?

Weil ein Crate viel mehr ist als das, was man üblicherweise unter einer 
Bibliothek versteht.
Ich würde Crate eher mit Paket übersetzen. Das käme ja auch vom Wortsinn 
etwas besser hin.

Es ist nicht so, als hätte man bei Rust beliebig Worte ohne Not 
erfunden. Es gibt ja auch z.B. Module und auch ein Lib(-Crate).

von Dergute W. (derguteweka)


Lesenswert?

Moin,

So, aus aktuellem Anlass hab' ich mir mal grad' wieder den rav1e neu 
ausgecheckt.
Und versucht zu bauen. Bricht natuerlich ab.
1
error[E0658]: const generics are unstable
2
 --> /root/.cargo/registry/src/github.com-1285ae84e5963aae/arrayvec-0.7.0/src/utils.rs:6:15
3
  |
4
6 | impl<T, const N: usize> MakeMaybeUninit<T, N> {
5
  |               ^
6
  |
7
  = note: see issue #74878 <https://github.com/rust-lang/rust/issues/74878> for more information

...usw...bla..fasel...
1
For more information about this error, try `rustc --explain E0658`.
2
error: could not compile `arrayvec`.

OK, mach'mer mal, wie angeheisen, dann kommt:
1
If you're using a stable or a beta version of rustc, you won't be able to use
2
any unstable features. In order to do so, please switch to a nightly version of
3
rustc (by using rustup).
4
5
If you're using a nightly version of rustc, just add the corresponding feature
6
to be able to use it:
7
8
...

So, dann wird's mal Zeit, in die doc zum rav1e zu gucken - huch, da 
steht:
1
rav1e currently requires Rust 1.51.0 or later to build.
Ja, dann ists natuerlich klar, mein uralter rustc in der Version 1.47.0 
kann das natuerlich nicht mehr bauen, den hab' ich ja auch schon vor 
fast 3  Monaten installiert, weil mein vorhergehender ja auch schon 
voellig veraltet war. Bestimmt schon 6..9 Monate alt.

Bei so'ner alten Toolchain ist das ja kein Wunder.

Und jetzt hoffentlich bald diese richtungsweisende, stabile Sprache im 
Linuxkernel.
Millionen Fliegen koennen nicht irren...

I gfrei' mi riesig!

Gruss
WK

von MaWin (Gast)


Lesenswert?

Dergute W. schrieb:
> Millionen Fliegen koennen nicht irren...

rustup update

Schon schwierig, gell?

von Dergute W. (derguteweka)


Lesenswert?

Moin,

MaWin schrieb:
> rustup update
>
> Schon schwierig, gell?

In der Tat:
1
root [ /usr/src/rav1e ]# rustup update
2
-bash: rustup: command not found
3
root [ /usr/src/rav1e ]#

Und ganz abgesehen davon halte ich's fuer keine gute Idee, fuer jedes 
Projekt in jeder Versionsnummer dann auf den jeweils "richtigen" rust 
compiler achten zu muessen.

Gruss
WK

von MaWin (Gast)


Lesenswert?

Dergute W. schrieb:
> root [ /usr/src/rav1e ]# rustup update
> -bash: rustup: command not found

Ja gut. Dann ist deine Installation halt kaputt.
Und warum machst du das überhaupt als root?

> Und ganz abgesehen davon halte ich's fuer keine gute Idee, fuer jedes
> Projekt in jeder Versionsnummer dann auf den jeweils "richtigen" rust
> compiler achten zu muessen.

Rust ist rückwärtskompatibel. Und das ist auch erklärtes Ziel von Rust.
Das heißt man kann immer den aktuellen stable-Compiler verwenden.

Ich sehe da auch überhaupt kein Problem.

Es gibt so gut wie keine praktisch verwendete relevante Sprache, die 
nicht auch weiterentwickelt wird.
Das gilt auch für so abgehangene Sprachen wie C.

von cppbert (Gast)


Lesenswert?

Dergute W. schrieb:
> Moin,
>
> So, aus aktuellem Anlass hab' ich mir mal grad' wieder den rav1e neu
> ausgecheckt.
> Und versucht zu bauen. Bricht natuerlich ab.

das ist eine mehr als bekannte Schwäche der Sprache - weil sie eben noch 
in sehr stark in der Entwicklung ist - sollen sie einfach alle Feature 
von C++ kopieren und dann Releasen oder einfach nur C Klonen - damit 
solche Sprächänderungen/Erweiterungen nicht passieren - was wäre denn 
laut dir am sinnvollsten - außer es gar nicht zu machen

das N was da mukiert wird ist das neue Feature von Konstanten als 
Template-Parameter - was es bei C++ eben schon seit 20 Jahren gibt, 
davor aber genau so wenig vorhanden war - da hat auch jeder alte 
Kompiler zu der Zeit das fluchen angefangen als die Libs darauf 
umgestellt wurden - warum darf so was heute deiner Meinung gar nicht 
mehr passieren?

Denkst du ernsthaft das diese häufigen Änderungen zum Standard werden - 
oder das die Menschen die dahinter stehen alle so schlecht sind das 
Problem nicht als solches zu erkennen?

C/C++ war 5 Jahren nach effektivem Erst-Release auch Meilen weg von 
Standard und Gleichmäßigkeit - ich glaube ihr seit alle zu jung oder 
habt vergessen wie das damals war

von cppbert (Gast)


Lesenswert?

Dergute W. schrieb:
> Moin,
> Und ganz abgesehen davon halte ich's fuer keine gute Idee, fuer jedes
> Projekt in jeder Versionsnummer dann auf den jeweils "richtigen" rust
> compiler achten zu muessen.

das war als C/C++ erfunden wurde doch genau so - oder hast du erst in 
den späten 90er mit Software-Entwicklung angefangen?

von cppbert (Gast)


Lesenswert?

Olaf schrieb:
> Jaja, ich hab das hier gelesen:
>
> 
https://www.heise.de/news/Startschuss-fuer-Rust-Entwicklung-im-Linux-Kernel-6017060.html

relevant ist aber das Google jetzt aktiv diese Projekt unterstützt - 
offiziell und mit eigenen Entwicklern

von cppbert (Gast)


Lesenswert?

Dergute W. schrieb:
> So, aus aktuellem Anlass hab' ich mir mal grad' wieder den rav1e neu
> ausgecheckt.
> Und versucht zu bauen. Bricht natuerlich ab.

das passiert dir genau so mit deinem alten Kompiler wenn du eine C11 
oder C++17 Lib kompilieren willst

bei Qt6 ist C++17 jetzt der Standard - d.h. mind VS2017 latest oder 
VS2019, oder gcc 7+

aber solche Libs sind dann eben für dich unrelevant und daher kein 
Problem der Sprache

von mh (Gast)


Lesenswert?

cppbert schrieb:
> Olaf schrieb:
>> Jaja, ich hab das hier gelesen:
>>
>>
> 
https://www.heise.de/news/Startschuss-fuer-Rust-Entwicklung-im-Linux-Kernel-6017060.html
>
> relevant ist aber das Google jetzt aktiv diese Projekt unterstützt -
> offiziell und mit eigenen Entwicklern

Warum ist das relevant? Gibts jetzt endlich nen Standard und nen 
alternativen Compiler?

von mh (Gast)


Lesenswert?

cppbert schrieb:
> bei Qt6 ist C++17 jetzt der Standard - d.h. mind VS2017 latest oder
> VS2019, oder gcc 7+

Es gibt schon einen kleinen Unterschied zwischen einem mehr als 3 Jahre 
alten Standard und einer speziellen Compilerversion, die nichtmal einen 
Monat alt ist.

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Es gibt schon einen kleinen Unterschied zwischen einem mehr als 3 Jahre
> alten Standard und einer speziellen Compilerversion, die nichtmal einen
> Monat alt ist.

Nein, nicht wirklich.
Wenn dein Compiler älter ist, funktioniert es nicht. Dann ist ein Update 
fällig. Das ist in beiden Fällen identisch.

Ich sehe auch keinen Grund das Compilerupdate zu verzögern.
Es ist ein einziger Befehl, der dein Problem löst:
rustup update

von cppbert (Gast)


Lesenswert?

mh schrieb:
> Warum ist das relevant? Gibts jetzt endlich nen Standard und nen
> alternativen Compiler?

Nein - aber darf sich das durch solche Projekte nicht erst entwickeln?

Woher kommt ständig dieser Es-muss-fertig-sein-Hochmut dem fast keine 
Programmiersprache in ihrer Entwicklung gerecht wurde und auch die 
meisten von euch nicht bei ihrere eigenen Arbeit leisten können?

Warum so ängstlich - denkst du ernsthaft das die Kernel-Entwickler Rust 
akzeptieren bevor nicht alle Bedenken ausgeräumt sind - denkst du die 
sind sind Fähig für ihr weit >10Mio Zeilen Code Projekt richtige und 
sinnvolle Entscheidungen zu treffen? meinst du da kommt jede Sprache 
einfach so rein?

Ich hätte auch gerne noch ein gcc-Frontend und einen Standard - aber 
scheinbar ist Rust auch schon so relevant genug das es nicht wie alle 
anderen Sprachen die es versucht haben direkt an Linus und Greg 
scheitert

von cppbert (Gast)


Lesenswert?

mh schrieb:
> Es gibt schon einen kleinen Unterschied zwischen einem mehr als 3 Jahre
> alten Standard und einer speziellen Compilerversion, die nichtmal einen
> Monat alt ist.

Wie lange ist C++ in der Entwicklung, wie lange Rust?
Was willst du vergleichen?

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> Ich sehe auch keinen Grund das Compilerupdate zu verzögern.

Es gibt schon viele Projekte wo so was nicht erlaubt ist - weil die 
Kompiler neue Fehler einbringen könnten - z.B. im Medizinbereich war ich 
dem stark ausgesetzt

von mh (Gast)


Lesenswert?

MaWin schrieb:
> mh schrieb:
>> Es gibt schon einen kleinen Unterschied zwischen einem mehr als 3 Jahre
>> alten Standard und einer speziellen Compilerversion, die nichtmal einen
>> Monat alt ist.
>
> Nein, nicht wirklich.
> Wenn dein Compiler älter ist, funktioniert es nicht. Dann ist ein Update
> fällig. Das ist in beiden Fällen identisch.
Das heißt ich kann ab jetzt erwarten, dass jeder C++20 benutzt?

> Ich sehe auch keinen Grund das Compilerupdate zu verzögern.
> Es ist ein einziger Befehl, der dein Problem löst:
> rustup update
Du hast gesehen, warum der zu alte rustc abbricht?
1
error[E0658]: const generics are unstable
Ist rust 100% abwärtskompatibel? Also alles was mit 1.47 korrekt 
funktioniert hat, funktioniert auch mit 1.51?

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> Es gibt schon viele Projekte wo so was nicht erlaubt ist - weil die
> Kompiler neue Fehler einbringen könnten - z.B. im Medizinbereich war ich
> dem stark ausgesetzt

Richtig.
Und in solchen Projekten zieht man sich die neusten Crates rein, die 
neue Compilerabhängigkeiten bekommen?
Natürlich macht man das nicht.
Damit existiert das Problem auch nicht.

von mh (Gast)


Lesenswert?

cppbert schrieb:
> mh schrieb:
>> Es gibt schon einen kleinen Unterschied zwischen einem mehr als 3 Jahre
>> alten Standard und einer speziellen Compilerversion, die nichtmal einen
>> Monat alt ist.
>
> Wie lange ist C++ in der Entwicklung, wie lange Rust?
> Was willst du vergleichen?
Man könnte mit der Zeitdifferenz zwischen erster Veröffentlichung der 
Sprache und des offiziellen Standards anfangen. Oder Anzahl der Compiler 
nach 10 Jahren.

von MaWin (Gast)


Lesenswert?

mh schrieb:
> erwarten, dass jeder C++20 benutzt?

Nein. Warum?
Nur weil ein Crate einen neueren Compiler voraussetzt, wird nicht gleich 
jeder gezwungen ein Update zu machen. Weder auf das neue Crate, noch auf 
den neuen Compiler.

> Du hast gesehen, warum der zu alte rustc abbricht?error[E0658]: const
> generics are unstable

Ja, und?

> Ist rust 100% abwärtskompatibel? Also alles was mit 1.47 korrekt
> funktioniert hat, funktioniert auch mit 1.51?

Ja.

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Man könnte mit der Zeitdifferenz zwischen erster Veröffentlichung der
> Sprache und des offiziellen Standards anfangen. Oder Anzahl der Compiler
> nach 10 Jahren.

Und welche Erkenntnis bringt das?

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
>> Ist rust 100% abwärtskompatibel? Also alles was mit 1.47 korrekt
>> funktioniert hat, funktioniert auch mit 1.51?
>
> Ja.

Aber natürlich bringt das nichts wenn man Features nutzt die erst in 
1.51 verfügbar sind, aber das ist bei keiner Programmiersprache die sich 
noch weiterentwickelt anders

Auch bei C++ ist das Geschrei gross wenn Libs den notwendigen Standard 
anheben, weil es immer einen Haufen Leute gibt die nur C++03 kompilieren 
können

von Klaus W. (mfgkw)


Lesenswert?

cppbert3 schrieb:
> MaWin schrieb:
>>> Ist rust 100% abwärtskompatibel? Also alles was mit 1.47 korrekt
>>> funktioniert hat, funktioniert auch mit 1.51?
>>
>> Ja.
>
> Aber natürlich bringt das nichts wenn man Features nutzt die erst in
> 1.51 verfügbar sind, aber das ist bei keiner Programmiersprache die sich
> noch weiterentwickelt anders
>
> Auch bei C++ ist das Geschrei gross wenn Libs den notwendigen Standard
> anheben, weil es immer einen Haufen Leute gibt die nur C++03 kompilieren
> können

Bei allen gängigen C- und C++-Compilern ist es schon so, daß die neuen 
Versionen die neuen Features der Sprache unterstützen.
Ein altes C-Programm aus Zeiten von Kernighan und Ritchie geht dann 
nicht mehr als C++ 20 durch. Aber trotzdem kann ich sie glatt 
kompilieren, wenn ich --std=.. angebe.
Erst wenn ich im Quelltext einen neueren Standard nutze, muß ich den 
dann auch erfüllen und alte Leichen wegräumen oder mumifizieren.

Der neueste gcc kompiliert wunderbar über 40 Jahre alte Quelltexte.

Reibungsverluste in älteren Programmen durch neue Standards sind nach 
meiner Erfahrung recht übersichtlich und eher in einer Ecke zu finden, 
wo man vielleicht sogar ohnehin besser nochmal reinschauen sollte.

Jetzt kann man von einer relativ neuen Entwicklung wie Rust das gar 
nicht verlangen, das wäre unfair.
Aber im Umkehrschluß finde ich dann, daß es für professionelle 
Entwicklung viel zu unausgegoren ist. Mir zieht es die Fußnägel hoch, 
wenn man damit auf Linux losgehen will.

von MaWin (Gast)


Lesenswert?

Klaus W. schrieb:
> Ein altes C-Programm aus Zeiten von Kernighan und Ritchie geht dann
> nicht mehr als C++ 20 durch. Aber trotzdem kann ich sie glatt
> kompilieren, wenn ich --std=.. angebe.
> Erst wenn ich im Quelltext einen neueren Standard nutze, muß ich den
> dann auch erfüllen und alte Leichen wegräumen oder mumifizieren.
>
> Der neueste gcc kompiliert wunderbar über 40 Jahre alte Quelltexte.

Das ist bei Rust ganz genau so.
--std heißt bei Rust "edition".

> Jetzt kann man von einer relativ neuen Entwicklung wie Rust das gar
> nicht verlangen, das wäre unfair.

Doch. Das kann man verlangen und das ist auch erklärtes Ziel von Rust.

Klaus W. schrieb:
> Mir zieht es die Fußnägel hoch, wenn man damit auf Linux losgehen will.

Wie begründest du das?

von Vincent H. (vinci)


Lesenswert?

Die Rust "Editions" dürften so gut funktionieren, dass Vittorio Romeo 
für C++ ein ähnliches System ala "Epochen" vorgeschlagen hat, mit denen 
sich bewusst Rückwärtskompatibilitäten hätten brechen lassen sollen. Der 
Vorschlag wurde aber leider recht früh abgelehnt.

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
>> Jetzt kann man von einer relativ neuen Entwicklung wie Rust das gar
>> nicht verlangen, das wäre unfair.
>

Aber warum beschwerst du dich dann das dein c++11 kompiler die lib nicht 
kompilieren kann die c++14 Features nutzt

Die lib die du da baust wird ziemlich nah an der latest Entwicklung 
gehalten, weil die von den Neuerungen stark profitieren, ist natürlich 
nicht so nett für dich, aber Rust kann nichts dafür das die eben jedem 
Feature hinterherspringen

Die sind sozusagen geraden von c++17 auf c++20 gesprungen

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> Klaus W. schrieb:
>
>> Mir zieht es die Fußnägel hoch, wenn man damit auf Linux losgehen will.
>
> Wie begründest du das?

Weil er die Kompilierfehler fälschlicherweise als 
Kompatibilitätsprobleme erkannt hat obowohl eigentlich die Lib plötzlich 
latest Features braucht

Und es immer wieder mitschwingt als wäre die Linux Kernel 
Entwicklergemeinde nicht in der Lage sinnvolle Entscheidungen zu 
treffen, so wie scheinbar die meisten Grossen scheinbar aus niederen 
oder den falschen Gründen anfangen Rust zu betrachten, obwohl C und C++ 
ja scheinbar alles genau richtig machen

von Rolf M. (rmagnus)


Lesenswert?

cppbert3 schrieb:
> Aber natürlich bringt das nichts wenn man Features nutzt die erst in
> 1.51 verfügbar sind, aber das ist bei keiner Programmiersprache die sich
> noch weiterentwickelt anders
>
> Auch bei C++ ist das Geschrei gross wenn Libs den notwendigen Standard
> anheben, weil es immer einen Haufen Leute gibt die nur C++03 kompilieren
> können

C++03 ist 18 Jahre alt, Rust 1.47 ein halbes Jahr. Wenn du jetzt 
geschrieben hättest "… weil es immer einen Haufen Leute gibt die nur 
C++20 kompilieren können", hätte es vom Alter der Version her besser 
gepasst. Und das Geschrei wäre vermutlich tatsächlich recht groß, wenn 
schon C++20 nicht mehr reichen würde.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Rolf M. schrieb:
> C++03 ist 18 Jahre alt, Rust 1.47 ein halbes Jahr.

Und es war die Entscheidung der Crateentwickler, die relativ neue 
Version 1.51 voraussetzen.
Das hat mit Rust ansich gar nichts zu tun.
Genauso gut hätten C++-Lib-Entwickler irgendein brandneues GCC-Feature 
vorausetzen können. Das ist eine ganz normale Entwicklungsentscheidung.

Aber ich kann es gut nachvollziehen, warum man gerne die neusten 
Rust-Features nutzt. Denn ein Rust-Compiler-Update ist sehr einfach und 
problemlos durchführbar für jeden. Und wenn jemand das nicht möchte, 
kann sie ja gerne auf der älteren Crateversion bleiben.

von Olaf (Gast)


Lesenswert?

> Und jetzt hoffentlich bald diese richtungsweisende, stabile Sprache im
> Linuxkernel.

Ich schaetze dafuer muss das Build-System dann problemlos mit Makefile 
funktionieren und die ganze automatische Internet-Librarykacke wird 
rausgeworfen. Sonst bleibt das nicht lange drin weil Linus vermutlich 
sofort das Messer in der Tasche aufgeht wenn er seinen Kernel neu 
uebersetzen will und es nicht klappt weil irgendein scheiss sich updaten 
muss, nach dem updaten was anderes nicht funktioniert usw...

Olaf

von cppbert3 (Gast)


Lesenswert?

Olaf schrieb:
> Ich schaetze dafuer muss das Build-System dann problemlos mit Makefile
> funktionieren und die ganze automatische Internet-Librarykacke wird
> rausgeworfen. Sonst bleibt das nicht lange drin weil Linus vermutlich
> sofort das Messer in der Tasche aufgeht wenn er seinen Kernel neu
> uebersetzen will und es nicht klappt weil irgendein scheiss sich updaten
> muss, nach dem updaten was anderes nicht funktioniert usw...

Wie schon 1000 mal gepostet: das ist kein Zwang, du kannst auch alles 
selber verwalten - und das ist genau das was die Kernelentwickler machen 
werden wenn es denn dazu kommt

von Phasenschieber (Gast)


Lesenswert?

Rust fügt ein paar interessante Ideen ein:

-einheitliches Cargo Buildsystem
-das "match" System ist mächtig
-error handing gefällt mir gut
-mehr move als copy

Und Rust wäre auch eine schöne Sprache, wäre sie nur nicht
so schmerzhaft zu nutzen. Fast alle Sachen brauchen 10mal
so lange wie z.b. in C++. Ständig hängt man am borrow
checker fest.

Greife auf eine Klassenvariable zu. Greife dann auf eine
andere zu. Geht schon nicht, weil `self` schon geborrowed
wurde. Selbst die einfachsten for-loops durch Container
kann man da vergessen. Antwort von der Rust Community:
"Ja sowas machen wir hier nicht. Optionen:"
-Algorithmus umschreiben (bitte was?)
-Datenstruktur verändern, mit Boxen und Refcounting
-Fiese Speicher-moves

Alle komplexeren Datenstrukturen sind extrem schmerzhaft
aufzubauen.

Dann, das trait system. In der Theorie ganz lustig. Man kann
einem i32 neue Funktionen dranhängen. Yey. In der Praxis sucht
man sich in der Doku kaputt wo das trait jetzt herkommt und in
welcher Crate man jetzt sein Feature findet. Ja ich weiß,
Doku kommt mit der Zeit. Doch dass sich mein Funktionsumfang
pro Typ ändern kann und nicht einfach ein klares Interface hat
ist schon... seltsam

Und dann Clippy und der Auto-formatter. Auch hier wieder, in
der Theorie gut. In der Praxis fixe ich ständig irgentwelche
Kleinigkeiten Wo Clippy sich wieder aufregt. Neulich passte
ihm der Name meines Typen nicht. Gibt ein Standard-naming
und meine Variable passt nicht. Rust Community sagt wieder
"nicht unser Problem, DU machst was falsch".
Und als Sahnehäubchen oben drauf hat der autoformatter einen
riesen Spaß dabei, 10 Zeilen die inhaltlich zusammen hängen
jedes mal anders umzubrechen. Konsistenz von Code ist wohl
heute nicht mehr wichtig.

Daher:
Andere Sprachen (besonders C++), nehmt euch ein Beispiel an
den guten Ideen die Rust bringt und baut diese auch ein.
Grade Paketmanager + Buildsystem ist sehr hilfreich.
Aber die Sprache selber... wollte zu viel, Ziel überschossen.

Und zur Sicherheit: Die Entwicklung ist um ein vielfaches
Langsamer, Netzwerkfehler, Logikfehler, etc gibt es auch
weiterhin. 90% der Zeit steckt eh wieder ein Kunde daher
der auf seiner Seite einen Fehler produziert hat der das
ganze System anhält. Aber hey, dafür haben wir keine
Speicherleaks mehr. Wie war das? Haben wir in C++ dank
RAII auch nie gehabt? Hmm. Aber die Datensicherheit und
das Owner Konzept! Oh, gibts in C++ auch. Hmm.

von Olaf (Gast)


Lesenswert?

> und meine Variable passt nicht. Rust Community sagt wieder
> "nicht unser Problem, DU machst was falsch".

Das ist ein Standardproblem unserer Zeit. In Sprachen der C-Familie
hast du alle Moeglichkeiten, musst aber eine ganze Menge lernen,
unter anderem damit du manche der Moeglichkeiten nicht nutzt.

Etwas das nicht immer klappt und dann zu Fehlern fuehrt und das noch
ganz besonders wenn du eher weniger gute (preiswerte) Programmierer 
nutzen moechtest. Es gab in den letzten 30Jahren eine Verschiebung von 
wenigen Programmierer fuer eher "wichtige" Sachen zu vielen 
Programmieren fuer "jeden Scheiss der nicht bei drei auf den Baeumen 
ist".

Daher gibt es ein Interesse daran die Leute soviel wie moeglich zu 
gaengeln.
Diese Sprachen kommen ja nicht mehr aus dem Interesse der Programmierer
ein Problem zu loesen, sondern aus dem Interesse einer Firma das ihre 
Probleme
so preiswert wie moeglich geloest werden.

Eine gute Sprache ist das Handwerkzeug eines Kuenstlers um Kunstwerke zu 
schaffen (im Idealfalle!) heute will man aber nur noch Handwerk.

> Andere Sprachen (besonders C++), nehmt euch ein Beispiel an
> den guten Ideen die Rust bringt und baut diese auch ein.

Ja, ich denke etwa in diese Richtung sollte es laufen. Wobei man sich 
manchmal fragt was denn noch in C++  fehlen koennte. :)

Olaf

von MaWin (Gast)


Lesenswert?

Phasenschieber schrieb:
> Fast alle Sachen brauchen 10mal
> so lange wie z.b. in C++.

Als Anfänger vielleicht. So wie mit jeder neuen Programmiersprache auch, 
die neue und unbekannte Konzepte verwendet.

Phasenschieber schrieb:
> Greife auf eine Klassenvariable zu. Greife dann auf eine
> andere zu. Geht schon nicht, weil `self` schon geborrowed
> wurde. Selbst die einfachsten for-loops durch Container
> kann man da vergessen.

Das ist einfach nur falsch, so wie du es schreibst.
Es sei denn du bringst ein Beispiel und wir das diskutieren.

Natürlich kann man nacheinander(!) schreibend, oder gleichzeitig lesend 
auf Member zugreifen.
Natürlich kann man sehr einfach über Container iterieren. Dazu gibt es 
sehr viele verschiedene Konzepte. So wie das halt in modernen Sprachen 
ist. Für jeden Geschmack was dabei.

Phasenschieber schrieb:
> In der Praxis sucht
> man sich in der Doku kaputt wo das trait jetzt herkommt

Traits muss man explizit importieren (use). Ohne use, auch keine 
zusätzlichen Trait-implementationen zu bereits bekannten Typen.

Phasenschieber schrieb:
> Aber hey, dafür haben wir keine
> Speicherleaks mehr.

Rust verhindert keine Speicherleaks.

Phasenschieber schrieb:
> Hmm. Aber die Datensicherheit und
> das Owner Konzept! Oh, gibts in C++ auch. Hmm.

In C++ ist es sehr viel umständlicher und sperriger zu nutzen.
Wenn man es konsequent durchzieht, ist es daher in C++ deutlich mehr 
Aufwand.
Und daher zieht es niemand konsequent durch.

von mh (Gast)


Lesenswert?

Wo genau finde ich die Doku für rust 1.47?

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Wo genau finde ich die Doku für rust 1.47?

rustup component add rust-docs

https://rust-lang.github.io/rustup/concepts/components.html

Oder online für die neuste Version:
https://www.rust-lang.org/learn

von mh (Gast)


Lesenswert?

MaWin schrieb:
> mh schrieb:
>> Wo genau finde ich die Doku für rust 1.47?
>
> rustup component add rust-docs
>
> https://rust-lang.github.io/rustup/concepts/components.html
>
> Oder online für die neuste Version:
> https://www.rust-lang.org/learn

Also wenn ich die 1.47er Doku haben will, muss ich erst den Compiler in 
der richtigen Version installieren? Wenn ich vergleichen will, muss ich 
hin und her wechseln?

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Wenn ich vergleichen will, muss ich hin und her wechseln?

Nein. Wie schon mehrfach hier im Thread geschrieben wurde, sind die 
Compilerversionen rückwärtskompatibel. In der Doku des neusten Compilers 
sind also auch alle Elemente der Vorgängerversionen enthalten. Mit 
entsprechenden Versionstags ist gekennzeichnet, mit welcher Version 
welches Feature eingebaut wurde.

von mh (Gast)


Lesenswert?

MaWin schrieb:
> mh schrieb:
>> Wenn ich vergleichen will, muss ich hin und her wechseln?
>
> Nein. Wie schon mehrfach hier im Thread geschrieben wurde, sind die
> Compilerversionen rückwärtskompatibel. In der Doku des neusten Compilers
> sind also auch alle Elemente der Vorgängerversionen enthalten. Mit
> entsprechenden Versionstags ist gekennzeichnet, mit welcher Version
> welches Feature eingebaut wurde.

Das ist nicht das was ich gefragt habe ...
Ich konnte in der Doku keine Versionstags finden, muss also alles seit 
der ersten Veröffentlichung unverändert sein. Allerdings konnte ich in 
der Doku selbst (https://doc.rust-lang.org/reference) auch keine Info 
finden, für welche Version diese Doku gilt.

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Das ist nicht das was ich gefragt habe ...

Und was hast du gefragt?

> Ich konnte in der Doku keine Versionstags finden

Aha.
Dann solltest du vielleicht einmal genauer gucken.

Beispiel:
https://doc.rust-lang.org/std/primitive.u32.html#associatedconstant.MIN

MIN gibt es seit 1.43.0

von mh (Gast)


Lesenswert?

MaWin schrieb:
> mh schrieb:
>> Das ist nicht das was ich gefragt habe ...
>
> Und was hast du gefragt?
Stand doch in dem Beitrag den du zitiert hast.
mh schrieb:
> Wenn ich vergleichen will, muss ich
> hin und her wechseln?
Du hast auf die nicht gestellte Frage "Möchte ich die verschiedenen 
vergleichen" geantwortet.

MaWin schrieb:
>> Ich konnte in der Doku keine Versionstags finden
>
> Aha.
> Dann solltest du vielleicht einmal genauer gucken.
> Beispiel:
> https://doc.rust-lang.org/std/primitive.u32.html#associatedconstant.MIN
>
> MIN gibt es seit 1.43.0
Ok in die Doku des std-cargos habe ich nicht geguckt. Interessiert mich 
auch eher weniger, mir geht es um die Sprache.

von MaWin (Gast)


Lesenswert?

mh schrieb:
> Du hast auf die nicht gestellte Frage "Möchte ich die verschiedenen
> vergleichen" geantwortet.

Vielleicht sind die Changelogs da eher sinnvoll?

Und warum willst du das überhaupt machen? Nutze halt die neuste 
stable-Version.

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> mh schrieb:
>> Du hast auf die nicht gestellte Frage "Möchte ich die verschiedenen
>> vergleichen" geantwortet.
>
> Vielleicht sind die Changelogs da eher sinnvoll?
>
> Und warum willst du das überhaupt machen? Nutze halt die neuste
> stable-Version.

er sucht eben was vergleichbares wie

https://en.cppreference.com/w/cpp/language/static_assert

wo man schön sehen kann welches Sprach-Feature wann aufgetaucht ist

von Klaus W. (mfgkw)


Lesenswert?

Wen es interessiert: in der aktuellen iX beginnt eine Serie mit Tutorial 
zu Rust, ggf. wer es bezahlt hat (select) natürlich auch online,

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> er sucht eben was vergleichbares wie
>
> https://en.cppreference.com/w/cpp/language/static_assert
>
> wo man schön sehen kann welches Sprach-Feature wann aufgetaucht ist

Ja gut. Das ist ja genau das, was ich gezeigt habe.
In der std-Doku sind auch alle core-Elemente der Sprache enthalten.

Das einzige, was dort in der Regel nicht steht, ist wenn neue abstrakte 
Konzepte eingeführt werden, die keinen direkten core-support brauchen. 
Wie z.B. const-generics.

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> Rust verhindert keine Speicherleaks.

Du kannst welche provozieren wenn du sie unbedingt für deine 
Systemprogrammierung brauchst aber der normale Entwickler bekommt das
Erstmal nicht hin, Rust verhindert alle Fehler die der ASAN findet, aber 
man kann Leaks erzeugen die der LSAN findet, nur eben nicht aus versehen

Aber trotzdem kannst du nicht mit einem geleaktem Speicher arbeiten

von cppbert3 (Gast)


Lesenswert?

Phasenschieber schrieb:
> Aber hey, dafür haben wir keine
> Speicherleaks mehr. Wie war das? Haben wir in C++ dank
> RAII auch nie gehabt? Hmm. Aber die Datensicherheit und
> das Owner Konzept! Oh, gibts in C++ auch. Hmm.

D.h. die Aussage von google, Microsoft, Amazon, Facebook usw. darüber 
das sie den grossteil der Sicherheitsprobleme in der 
Systemprogrammierung nicht unter Kontrolle bekommen ist nur 
Hilflosigkeit weil deren Entwickler alle so schlecht sind? Speziell 
Google als Erfinder von ASAN etc. Würde ich da eindeutig mehr 
Verständnis zusprechen, Systemprogrammierung ist was anderes, 
Nutzeranzahl von Mio bis Mrd ist was anderes, ständige Angriffe sind was 
anderes - ich glaube vielen fehlen hier einfach die Dimensionen mit was 
solche Firmen zu kämpfen haben

Der Satz der mir hier von jedem braucht-man-nicht-Kritiker immer fehlt 
ist:
"Wenn ich bei google, Amazon und Microsoft das Zepter für die Android, 
AWS und Azure Entwicklung in den Händen hätte würden meine >10.0000 
Entwickler dank fortschrittlicher C++ Entwicklung solche Fehler einfach 
nicht mehr machen, mein Business würde ohne Sicherheits-, Ressourcen und 
Wartungsprobleme laufen - meine 10-800 Mio Kunden wären immer Zufrieden"

von cppbert3 (Gast)


Lesenswert?

Bei der Menge an Kunden, Systemen ist jede Verbesserung in Sicherheit 
und Wartung nur im einstelligen Prozentbereich schon direkt ordentlich 
Geld wert

von cppbert3 (Gast)


Lesenswert?

Olaf schrieb:
> Daher gibt es ein Interesse daran die Leute soviel wie moeglich zu
> gaengeln.
> Diese Sprachen kommen ja nicht mehr aus dem Interesse der Programmierer
> ein Problem zu loesen, sondern aus dem Interesse einer Firma das ihre
> Probleme
> so preiswert wie moeglich geloest werden.

auch wenn der Satz natürlich so absolut richtig ist schwingt aber immer 
so ein Hauch von nur-schlechte-Entwickler machen schlechten/fehlerhaften 
Code mit...

Die Probleme bei den Grossen sind real und in jahren harter Arbeit 
konnte man diese nicht signifikant Richtung 0 bringen, Rust versucht, 
und scheint es als Sprache auch erstmals in der Systemprogrammierung zu 
schaffen eine deutlichere Verbesserung out-of-the-box zu ermöglichen, 
ganz unabhängig von logischen Fehlern

von MaWin (Gast)


Lesenswert?

Versucht doch einfach mal ein erstes Projekt mit Rust umzusetzen.
Damit meine ich jetzt ein Hallo World, sondern ein größeres Projekt, was 
tatsächlich was tut.

Ihr werdet ganz schnell furchtbar frustriert sein, weil Rust euch 
ständig mit Compilerfehlern bewirft. Das ist die erste Erkenntnis, die 
ihr haben werdet. Rust ist nur wenig geeignet, um mal schnell etwas 
hinzufrickeln. Man muss sich Gedanken machen über das, was man schreibt. 
Macht man es nicht, wird man umgehend vom Compiler dafür bestraft.

Wenn man diese Phase überstanden hat, kommt allerdings die zweite Phase, 
in der man die Vorteile dieses Vorgehens erkennt. Es gibt den Spruch: If 
it compiles, then it works. Das ist natürlich nicht wörtlich zu nehmen. 
Selbstverständlich kann man in Rust auch algorithmische Fehler machen. 
Aber eine ganze Menge an Fehlern, die man in anderen Sprachen wie C oder 
gar Python erst zur Laufzeit erkennt (wenn man Glück hat), quittiert der 
Rustcompiler einem mit einem Fehler.

Insofern hat man eine ganze Menge der Debuggingarbeit in die Phase der 
Programmierung verschoben.
Und das ist eine gute Sache.

von Johannes S. (Gast)


Lesenswert?

Welcher MaWin schreibt hier? Ich bin beeindruckt 8)

von Yalu X. (yalu) (Moderator)


Lesenswert?

MaWin schrieb:
> Ihr werdet ganz schnell furchtbar frustriert sein, weil Rust euch
> ständig mit Compilerfehlern bewirft. ...
>
> Wenn man diese Phase überstanden hat, kommt allerdings die zweite Phase,
> in der man die Vorteile dieses Vorgehens erkennt. Es gibt den Spruch: If
> it compiles, then it works.

Das kenne ich verstärkt (sowohl in negativer als auch in positiver
Hinsicht) auch von Haskell. Das funktionale Programmierparadigma und das
äußerst strenge Typsystem sorgen dort dafür, dass sehr viele Sorten von
logischen Fehlern in Typfehler münden und damit zur Compilezeit erkannt
werden.

Leider eignet sich Haskell nicht gut für die systemnahe Programmierung.
Unter den Universalsprachen, die von hardwarenah bis völlig abgehoben
alles abdecken, ist deswegen Rust IMHO der mit Abstand beste Kompromiss,
den es derzeit gibt.

von Daniel A. (daniel-a)


Lesenswert?

MaWin schrieb:
> Man muss sich Gedanken machen über das, was man schreibt.
> Macht man es nicht, wird man umgehend vom Compiler dafür bestraft.

Gedanken darüber, was man schreibt, oder Gedanken darüber, wie man es in 
Rust schreibt?

Ich kann genau wissen, wie ich etwas idealerweise umsetzen würde, welche 
Datenstruktur und Algorithmen ich verwenden will. In C, Python, Java, 
GO, etc., selbst in anderen Imperativen und/oder OOP sprachen die ich 
eigentlich noch gar nicht kenne kann ich das dann einfach so hin 
schreiben. Aber nicht in Rust, gewisse Sachen muss man da einfach anders 
machen, und zwar nicht, weil es falsch oder besser wäre (von Aussen 
betrachtet), sondern einfach nur, weil es so nicht geht. Aber natürlich 
ist die Datenstruktur und der Algorithmus dann völlig verrückt, macht 
man einfach so nicht, oder?

Als Beispiel, führe ich einfach mal die völlig verrückte Datenstruktur 
einer linked list an. Ja, ich weiss, total verrückt, sowas zu benutzen, 
so ineffizient, so kompliziert, wer der noch bei Verstand ist würde denn 
sowas machen? Aber lasse ich doch das einfach mal die Rust läute selbst 
erklären: https://rust-unofficial.github.io/too-many-lists/

Mittlerweile gibt es LinkedLists zum Glück aber in der Standard Library. 
Wurde auch sehr elegant gelöst. Jede Funktion nutzt einfach "unsafe". 
(Das ist aber auch die einzig vernünftige Lösung.)
https://doc.rust-lang.org/src/alloc/collections/linked_list.rs.html

von MaWin (Gast)


Lesenswert?

Daniel A. schrieb:
> MaWin schrieb:
>> Man muss sich Gedanken machen über das, was man schreibt.
>> Macht man es nicht, wird man umgehend vom Compiler dafür bestraft.
>
> Gedanken darüber, was man schreibt, oder Gedanken darüber, wie man es in
> Rust schreibt?

Beides natürlich. Wie in jeder Sprache.

> Ich kann genau wissen, wie ich etwas idealerweise umsetzen würde, welche
> Datenstruktur und Algorithmen ich verwenden will. In C, Python, Java,
> GO, etc., selbst in anderen Imperativen und/oder OOP sprachen die ich
> eigentlich noch gar nicht kenne kann ich das dann einfach so hin
> schreiben. Aber nicht in Rust, gewisse Sachen muss man da einfach anders
> machen, und zwar nicht, weil es falsch oder besser wäre (von Aussen
> betrachtet), sondern einfach nur, weil es so nicht geht. Aber natürlich
> ist die Datenstruktur und der Algorithmus dann völlig verrückt, macht
> man einfach so nicht, oder?

In C kann man vieles implementieren, indem man wild mit Pointern um sich 
wirft. Und es resultiert regelmäßig in use-after-free oder ähnlichen 
Bugs.
Man sollte sich in allen Sprachen Gedanken darüber machen, wie man einen 
Algorithmus möglichst safe implementiert.
Rust zwingt den Entwickler dazu. C nicht.

Das bedeutet zwangsläufig, dass man in Safe-Rust nicht alles machen 
kann, was in C geht. Und das ist natürlich auch so gewollt.

Für die Fälle, die in Safe-Rust nicht direkt oder nur ineffizient lösbar 
sind, gibt es Abstraktionen in der std library, die dann intern 
Unsafe-Rust nutzen.

> Mittlerweile gibt es LinkedLists zum Glück aber in der Standard Library.
> Wurde auch sehr elegant gelöst. Jede Funktion nutzt einfach "unsafe".
> (Das ist aber auch die einzig vernünftige Lösung.)
> https://doc.rust-lang.org/src/alloc/collections/linked_list.rs.html

Na dann ist doch alles gut, wenn die std library das Problem für dich 
gelöst hat, sodass du in deinem Code alles als safe-Rust schreiben 
kannst.

Man kann eine linked-list selbstverständlich auch ohne die std linked 
list in safe rust schreiben. Man nehme Rc, RefCell und Box. Wie das 
genau geht, kannst du im offiziellen Rust-Buch nachlesen.
Aber da das nicht ganz so effizient ist, wie eine dedizierte 
linked-list, gibt es eben die optimierte std-liste.

von cppbert (Gast)


Lesenswert?

Daniel A. schrieb:
> Als Beispiel, führe ich einfach mal die völlig verrückte Datenstruktur
> einer linked list an.

es ist sehr schwer die Offenheit von C/C++ oder gar Assembler in 
sichere(re) Konstrukte zu überführen - aber mal ehrlich, wer von uns 
schreibt denn ständig effiziente Link-Lists oder Graphen-Strukturen - 
machen tun wir das schon hin und wieder aber das als Messlatte heran zu 
ziehen ist doch nicht wirklich intelligent, oder denkst du das wirklich? 
Hast du gar das Gefühl den Entwicklern wäre das nicht ab der 1. Idee zum 
Ownershipping klar gewesen?  das wurde so bewusst in kauf genommen

nur bei Selbst-Referenzen und Offenen-Referenzen hat Rust - bisher noch 
:) -Probleme das "elegant" zu lösen - dafür die ganze Sicherheit die 
geboten wird komplett über Bord zu werfen würde ich als fraglich 
bezeichnen

Die Spiel heisst nicht Nur-Vorteile-sonst-ebene-wieder-die-alte-Sprache

von cppbert (Gast)


Lesenswert?

Daniel A. schrieb:
> Als Beispiel, führe ich einfach mal die völlig verrückte Datenstruktur
> einer linked list an. Ja, ich weiss, total verrückt, sowas zu benutzen,
> so ineffizient, so kompliziert, wer der noch bei Verstand ist würde denn
> sowas machen?

niemand auf der Welt, mit Erfahrung denkt das, jede Verwaltungsform hat 
ihre Vor- und Nachteile

Wie kommst du darauf das die Rust-Entwickler so was einfach 
vernachlässigen - sie haben sich eben so entschieden so das der 90% Fall 
sicher ist

Falls du eine gute Idee hast wie man das fehlende Konzept für 
Link-Listen "sauber" in ein Ownership-Model bekommt - ohne das daraus 
ein GC wird - oder kein Ownership-Model existiert kannst du gerne 
Vorsprechen, dir sei Ruhm und Ehre gewiss :)

von von snowflakes - für snowflakes (Gast)


Lesenswert?

MaWin schrieb:
> Man sollte sich in allen Sprachen Gedanken darüber machen, wie man einen
> Algorithmus möglichst safe implementiert.
> Rust zwingt den Entwickler dazu. C nicht.

Blödsinn.

Das ist C:
- Trust the programmer
- Don’t prevent the programmer from doing what needs to be done

Für Rust sind die Entwickler anscheinend alle doof und man muss denen 
bestimmte Werkzeuge wegnehmen und ihnen regelmäßig auf die Finger hauen. 
Eine tolle Einstellung. Nach dieser Logik sollte man in einer Werkstatt 
alle Wekrzeuge durch Wattebällchen ersetzen. Damit da nichts passiert. 
Die schöne neue Zeit.

von von snowflakes - für snowflakes (Gast)


Lesenswert?

Yalu X. schrieb:
> beste Kompromiss,
> den es derzeit gibt.

Aha, also wieder nur ein Kompromiss und nur für "derzeit".

In ein paar Jahren brauchen wir dann eine neue Programmiersprache, die 
wieder alles besser macht?

Und gerade bei systemnaher Programmierung? Hat dann Linux-Kernel 30 
Million LOC geschrieben in C, 5 Million LOC in Rust, 5 Millionen LOC in 
XYZ, usw.?

von Yalu X. (yalu) (Moderator)


Lesenswert?

von snowflakes - für snowflakes schrieb:
> Für Rust sind die Entwickler anscheinend alle doof und man muss denen
> bestimmte Werkzeuge wegnehmen und ihnen regelmäßig auf die Finger hauen.

Ich finde Restriktionen von Seiten der Programmiersprache völlig in
Ordnung, wenn sie mir dabei helfen, zuverlässigeren Code zu schreiben
und den Debug-Aufwand zu reduzieren.

Das ist ähnlich wie im Straßenverkehr:

Ich halte mich dort gerne an das Rechtsfahrgebot. Es schränkt mich zwar
in meiner Freiheit etwas ein, dafür kommt es nicht ständig zum Crash,
weil mir ein anderes Fahrzeug auf meiner Fahrspur entgegenkommt. Falls
ich dennoch einmal unabsichtlich als Geisterfahrer unterwegs sein
sollte, fände ich es völlig in Ordnung, wenn mich die Polizei anhält und
mich auf meinen Regelverstoß hinweist.

von Jemand (Gast)


Lesenswert?


von Yalu X. (yalu) (Moderator)


Lesenswert?

von snowflakes - für snowflakes schrieb:
> Aha, also wieder nur ein Kompromiss und nur für "derzeit".

Die Welt besteht nun einmal aus Kompromissen, denn die absolute
Perfektion gibt es in der Realität nirgends.

Und wer weiß, vielleicht hält dieser derzeitige Kompromiss bis an unser
beider Lebensende und darüber hinaus.

: Bearbeitet durch Moderator
von cppbert3 (Gast)


Lesenswert?

von snowflakes - für snowflakes schrieb:
> Für Rust sind die Entwickler anscheinend alle doof und man muss denen
> bestimmte Werkzeuge wegnehmen und ihnen regelmäßig auf die Finger hauen.
> Eine tolle Einstellung.

Was ist das Problem an der Einstellung wenn dabei automatisch sicherere 
Programme entstehen

Und die Grossen der Branche wechseln von ihreren eigenen Strategie in 
der Systemprogrammierung auch nur zu Rust weil denen so langweilig ist 
und nur die schlechten Entwickler dort arbeiten?

Kann einer von euch hat mal schlüssig erklärt warum so viele der grossen 
Rust als die Lösung ihrer Lowlevel Probleme sehen und nur von euch 
keiner? Google entwickelt den ASAN der mittlerweile Standart ist, 
riesige Fuzzyfarmen und und und und sagen trotzdem das reicht nicht, ihr 
aber schon

Ich finde Rust nicht interessant weil ich in den letzten 30 Jahren so 
unter C/C++ gelitten habe, dafür habe ich viel zu viel Code für allerlei 
Kunden und Projekte entwickelt, aber ich sehe viele Kernprobleme 
behandelt, als jüngling oder zu alter Entwickler verstehe ich eine 
gewissen Zurückhaltung, aber viele der Argumente hier gegen Rust sind so 
schwach das es schon auffällig ist, was ich schade finde weil C/C++ 
keiner Verteidigung bedarf, es wird ewiglich überdauern

von cppbert3 (Gast)


Lesenswert?

von snowflakes - für snowflakes schrieb:
> Und gerade bei systemnaher Programmierung? Hat dann Linux-Kernel 30
> Million LOC geschrieben in C, 5 Million LOC in Rust, 5 Millionen LOC in
> XYZ, usw.?

wenn die Kernelentwickler Rust in den Kernel einziehen lassen würde, 
trotz all der Mängel, was würde das über die Kernelentwickler und ihre 
Fähigkeiten und bisherigen Code aussagen?

Wieder so ein schwaches Argument weil das Szenario mit XYZ eh niemals 
eintreten wird, warum sowas überhaupt posten?

von Rolf M. (rmagnus)


Lesenswert?

Yalu X. schrieb:
> von snowflakes - für snowflakes schrieb:
>> Für Rust sind die Entwickler anscheinend alle doof und man muss denen
>> bestimmte Werkzeuge wegnehmen und ihnen regelmäßig auf die Finger hauen.
>
> Ich finde Restriktionen von Seiten der Programmiersprache völlig in
> Ordnung, wenn sie mir dabei helfen, zuverlässigeren Code zu schreiben
> und den Debug-Aufwand zu reduzieren.
>
> Das ist ähnlich wie im Straßenverkehr:
>
> Ich halte mich dort gerne an das Rechtsfahrgebot. Es schränkt mich zwar
> in meiner Freiheit etwas ein, dafür kommt es nicht ständig zum Crash,
> weil mir ein anderes Fahrzeug auf meiner Fahrspur entgegenkommt.

Das klingt aber eher nach C - du hast es unter Kontrolle und hältst dich 
an die Regel, weil sie sinnvoll ist. Dennoch kannst du z.B. zum 
Überholen oder zum Ausweichen auch mal nach links fahren. Rust wäre, 
wenn das Auto dir das Lenkrad blockiert, wenn du versuchst, auf die 
linke Spur zu fahren.

von MaWin (Gast)


Lesenswert?

von snowflakes - für snowflakes schrieb:
> Aha, also wieder nur ein Kompromiss und nur für "derzeit".
>
> In ein paar Jahren brauchen wir dann eine neue Programmiersprache, die
> wieder alles besser macht?

Es nennt sich Weiterentwicklung.

> Und gerade bei systemnaher Programmierung? Hat dann Linux-Kernel 30
> Million LOC geschrieben in C, 5 Million LOC in Rust, 5 Millionen LOC in
> XYZ, usw.?

Wo wäre das Problem?
Du tust gerade so, als stünden wir vor der Inflation der 
Programmiersprachen.

von snowflakes - für snowflakes schrieb:
> Das ist C:
> - Trust the programmer
> - Don’t prevent the programmer from doing what needs to be done

Du hast noch was vergessen:

- Don't prevent the programmer from doing absolutely dumb things that 
would never work.
- Don't prevent the programmer from writing unsound code.
- Don't prevent the programmer from introducing subtle and hard to debug 
race conditions.
- Don't prevent the programmer from corrupting the memory.

von MaWin (Gast)


Lesenswert?

Rolf M. schrieb:
> Rust wäre,
> wenn das Auto dir das Lenkrad blockiert, wenn du versuchst, auf die
> linke Spur zu fahren.

... und wenn du doch unbedingt auf der falschen Spur fahren willst, 
kannst du das mit unsafe eindeutig kennzeichnen.

von Jemand (Gast)


Lesenswert?

Rolf M. schrieb:
> Das klingt aber eher nach C - du hast es unter Kontrolle und hältst dich
> an die Regel, weil sie sinnvoll ist. Dennoch kannst du z.B. zum
> Überholen oder zum Ausweichen auch mal nach links fahren. Rust wäre,
> wenn das Auto dir das Lenkrad blockiert, wenn du versuchst, auf die
> linke Spur zu fahren.

Sind eingreifende Sicherungssysteme moderner Flugzeuge wie die 
Flight-Envelope-Protection ein Fort- oder Rückschritt? (dort gibt es so 
Rust-mäßig "unsafe"-Modi)

von MaWin (Gast)


Lesenswert?

Jemand schrieb:
> Sind eingreifende Sicherungssysteme moderner Flugzeuge wie die
> Flight-Envelope-Protection ein Fort- oder Rückschritt? (dort gibt es so
> Rust-mäßig "unsafe"-Modi)

Ich halte die Auto- und Flugzeugvergleiche hier für völlig daneben.
Die wichtigsten und meisten Rust-Merkmale sind Compiletime-Checks.

Das wäre in etwa so, als würdest du vor dem Start beweisen, dass es im 
folgenden Flug nicht zu sicherheitskritischen Manövern kommen kann. Das 
ist natürlich bei Flugzeugen unmöglich und deshalb ist der Vergleich 
Unsinn.

von Daniel A. (daniel-a)


Lesenswert?

MaWin schrieb:
> Man kann eine linked-list selbstverständlich auch ohne die std linked
> list in safe rust schreiben. Man nehme Rc, RefCell und Box. Wie das
> genau geht, kannst du im offiziellen Rust-Buch nachlesen.
> Aber da das nicht ganz so effizient ist, wie eine dedizierte
> linked-list, gibt es eben die optimierte std-liste.

Ja, es ist nicht ganz so schlimm, wie ich es darstelle. Das Owner 
Konzept ist eigentlich schon eine tolle Sache, aber es nervt mit der 
Zeit halt schon etwas, das ständige Hantieren mit Rc, RefCell, Box, etc. 
bis es geht. Da frage ich mich einfach, hätte man das wirklich nicht 
einfacher/besser lösen können?

von MaWin (Gast)


Lesenswert?


von MaWin (Gast)


Lesenswert?

Daniel A. schrieb:
> Zeit halt schon etwas, das ständige Hantieren mit Rc, RefCell, Box, etc.
> bis es geht. Da frage ich mich einfach, hätte man das wirklich nicht
> einfacher/besser lösen können?

Naja. Rc ist bereits ein Smart Pointer und damit praktisch transparent. 
Nur halt nicht bei der Deklaration.

Man kann jetzt natürlich diverse Typen in einem eigenen neuen Typ 
kombinieren. Aber ich sehe da den Vorteil jetzt nicht wirklich. Das 
skaliert nicht so richtig.

von cppbert3 (Gast)


Lesenswert?

Daniel A. schrieb:
> Da frage ich mich einfach, hätte man das wirklich nicht einfacher/besser
> lösen können?

Nicht wirklich, das Ownership Model ist ja auch keine neue Idee, nur die 
Art der Integration in Rust

Für Linklisten oder Graphen braucht man ein Nullable Konzept, das gibt 
es schon sehr langen in x Sprachen, aber es ist schwierig bis unmöglich 
das zur Kompilezeit sauber zu lösen/prüfen (eher ein mathematisches 
Problem), die functionalen Sprachen machen das sauber aber die sind 
leider nicht so praktisch

Wenn du dir als Rust die Einschränkungen: Kompilezeitchecks und 
Lückenlosigkeit auferlegst wird es sehr schwierig aber sie haben eine 
gute mitte zwischen mathematischer Beweisbarkeit und noch praktischer 
Anwendbarkeit geschaffen, vielleicht schaffen sie auch noch diese Hürde

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> https://security.googleblog.com/2021/04/rust-in-linux-kernel.html

Ganz unten auf der Seite
...
 Thanks Nick Desaulniers, Kees Cook, and Adrian Taylor for contributions 
to this post. Special thanks to Jeff Vander Stoep for contributions and 
editing, and to Greg Kroah-Hartman for reviewing and contributing to the 
code examples.
...

Greg Kroah-Hartman hat sich also auch schon ein wenig intensiver damit 
beschäftig, wer ihn nicht kennt: das ist der 2. Man nach Linus Torvalds 
in der Kernelentwickler Befehlskette

von cppbert3 (Gast)


Lesenswert?

Facebook ist jetzt auch in der Rust Foundation

https://engineering.fb.com/2021/04/29/developer-tools/rust/

Laut dem Artikel arbeiten bei Facebook bis zu 100 Entwickler mit Rust

Und nein, ich habe kein Facebook Account, Facebook als Firma ist aber 
trotzdem, technisch gesehen eine extreme Datenverarbeutungsmaschinerie 
mit sehr viel C++ und auch scheinbar nicht unbedeutende Menge an Rust 
dahinter, die wenigsten Leute bei denen machen HTML, js und PHP, die 
Zeiten sind schon lange vorbei

von cppbert3 (Gast)


Lesenswert?

Vom neuen Facebook Rust Mitglied ;)

"...And, seriously, if the Linux kernel is actually starting to even 
consider Rust as a language to be used for that codebase, well, that’s 
when you know you have made it. ..."

von MaWin (Gast)


Lesenswert?

cppbert3 schrieb:
> "...And, seriously, if the Linux kernel is actually starting to even
> consider Rust as a language to be used for that codebase, well, that’s
> when you know you have made it. ..."

Da ist was dran.
C++ ist an dieser Hürde mehrfach gescheitert.

Gut, das ist nicht ganz vergleichbar, weil es dort darum ging den 
gesamten C-Code mit einem C++ Compiler zu übersetzen.

Dennoch sind die Linux-Entwickler nicht bekannt dafür auf Hypetrains 
aufzuspringen. Das ist die Grundlage für die Aussage.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Mal wieder ein unqualifizierter rant:
Bei BLFS-11 ist derweilen ein rustc in Version 1.52 hip. Der hat aber 
scheints immernoch den selben shice in miri, wie schon vor mindestens 16 
Monaten hier:
Beitrag "Re: Rust - ist das hier um zu bleiben?"
beschrieben.
Also in fast 1.5 Jahren weder repariert noch rausgeflogen. Kann man 
natuerlich machen, wird nicht wichtig sein, aber sieht halt doch 
irgendwie kacke aus, find' ich. Aber was weiss ich schon.
Beim firefox bauen brauchts, scheint's auch seit geraumer Zeit einen 
patch, weil da manchmal was schief geht. Das hoert sich richtig 
ermunternd an:

[quote=patch]This is an old patch from Arch, they build with
clang and lto and have apparently needed this in the past.
On two of my systems (one from May 21 and one of my BLFS-10.0
systems) firefox-91.0esr FTBFS with a message that a python
check on libgkrust.a identified one networking function,
getsockname, in the rust static library.  The reason why this
is now giving a problem, but only on some systems, is not
understood, but this seems to stop it.[/quote]

aye caramba!
hat aber sicher nix mit rust zu tun. Gaaaanz sicher nicht...


[quote=BLFS-11_Book]...and particularly because newer versions tend to 
break older mozilla packages, the BLFS editors take the view that it 
should only be updated when that is necessary[/quote]

Wuzz? Hab' ich hier nicht noch vor ein paar Monaten erklaert bekommen, 
dass das garnicht sein kann, weil der neueste rust-compiler immer der 
geilste ist und zu allen aelteren kompatibel?

Kanns kaum erwarten, bisses endlich auch im Kernel ist.

Gruss
WK

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Haha! Kannste dir nicht ausdenken, sowas:
Ich will mal wieder - jetzt eben mit dem rust-1.52 - aus BLFS-11 (und 
damit auch erfolgreich firefox (auf dem scheib ich grad dieses 
Pamphlet), thunderbird, librsvg,... gebaut) den rav1e bauen. Nehm' ich 
halt mal's letzte "release" p20211207 her.
Boah: ein
1
cargo build --release
laeuft tatsaechlich durch. Ohne Mecker. Sollte ich tatsaechlich 
ungerechtfertigt zu miesepetrig druff sein?
Jetzt noch gschwind die c-api anflanschen, damit der Rest der (C-)Welt 
auch was von dem schicken Encoder hat:
1
root [ /usr/src/rav1e-p20211207 ]# cargo install cargo-c
2
    Updating crates.io index
3
  Downloaded cargo-c v0.9.5+cargo-0.57
4
error: failed to parse manifest at `/root/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-c-0.9.5+cargo-0.57/Cargo.toml`
5
6
Caused by:
7
  feature `edition2021` is required
8
9
  this Cargo does not support nightly features, but if you
10
  switch to nightly channel you can add
11
  `cargo-features = ["edition2021"]` to enable this feature

Ist das geil?
Ich brauche also dringend das wichtige Feature "edition2021"? rly?
Bloss gut, dass das ja nix mit rust zu tun hat und das man ja auch nicht 
gezwungen ist, cargo herzunehmen.
Kann irgendwer mal anfangen, diese wildgewordenen Informatiker ein 
bisschen zu erden?
Ja, ich weiss - niemand (ausser meiner eigenen Inkompetenz) haelt mich 
davon ab, mir einen noch viel geileren AV1 Encoder in der Sprache und 
mit dem Buildsystem meiner Wahl selbst zu programmieren. Schon klar.

SCNR;
WK

von Almdahl (Gast)


Lesenswert?

Meine Meinung zu Rust ist, dass die Entwickler von Rust anscheinend noch 
nie für Linux ein Paket gebaut haben.

Es ist lächerlich, dass man erst nach langer Zeit mit Cargo offline 
bauen konnte. Und auch sehr lächerlich, dass es weiterhin alle Pakete in 
ein Offline-Repo zieht.

Wenn man ein Paket für eine Linuxdistribution baut, will man in der 
Regel nur Pakete aus den eigenen Repos benutzen. Z.B. weil man sie auf 
Sicherheit geprüft hat. Crate.io traue ich nicht. Man hat ja bereits 
beim npm-Angriff gesehen, dass diese Spracheneigenen Repositories 
anfälliger für eine Supply-Chain-Attacke sind. Es sind bei solchen 
Projekten dem Anschein nach eher Sprach-Fanatiker dabei, die sich mehr 
um die "Coolness" ihrer Programmiersprache als um 
Supply-Chain-Sicherheit kümmern...

Ein weiterer Punkt ist die massive Rekursionstiefe beim Bauen vom Rust 
Compiler package rustc: Entweder man schreibt einmal alles in einem 
Sublayer, quasi einen elementaren Baukasten von Rust-Befehlen, mit denen 
man dann einfach-rekursiv den Standard-namespace schreibt, oder man 
lässt es bleiben.

Rust wirkt sprachlich, wie von hellen Köpfen entwickelt, aber die 
Kompiler-Entwickler scheinen noch nie von Idempotenz und Performance 
gehört zu haben, jedenfalls im Bezug auf das Compilerprojekt selbst.

von MaWin (Gast)


Lesenswert?

Almdahl schrieb:
> Supply-Chain-Attacke

Wie soll das denn vonstattengehen, wenn das Distributionspaket die 
Dependency-Versionen pinnt (locked)?

Almdahl schrieb:
> Ein weiterer Punkt ist die massive Rekursionstiefe beim Bauen vom Rust
> Compiler package rustc

Tut mir leid. Das verstehe ich nicht.
Kannst du das Problem vielleicht auch in verständlich erklären?

Almdahl schrieb:
> Es ist lächerlich, dass man erst nach langer Zeit mit Cargo offline
> bauen konnte. Und auch sehr lächerlich, dass es weiterhin alle Pakete in
> ein Offline-Repo zieht.

Es ist also lächerlich, dass die Pakete online sind und gleichzeitig ist 
es lächerlich, dass die Pakete offline gecached werden?
Verstehe ich deine Kritik richtig?

Wie hättest du es denn gerne?

von Almdahl (Gast)


Lesenswert?

MaWin schrieb:
> Almdahl schrieb:
>> Supply-Chain-Attacke
> Wie soll das denn vonstattengehen, wenn das Distributionspaket die
> Dependency-Versionen pinnt (locked)?
Ich meine nicht, dass es eine Supply-Chain-Attacke auf die Distribution 
geben kann, sondern eine in der programmierspracheneigenen 
Paketverwaltung. Ist meine Persönliche Meinung, aber ich finde es 
nervig, dass für Sprachen wie Rust, Python, Ruby usw. das Rad immer 
wieder neu erfunden wurde.

Dass man die Crates auch mit Cargo laden kann, ist trotzdem nicht das 
eigentliche Problem. Man hat nur das Gefühl, dass alles darauf ausgelegt 
ist, dass man die Rust-Art benutzt, Dinge zu kompilieren und dass es 
beim Paketbau für Distributionen unangenehm wird.

> Almdahl schrieb:
>> Ein weiterer Punkt ist die massive Rekursionstiefe beim Bauen vom Rust
>> Compiler package rustc
>
> Tut mir leid. Das verstehe ich nicht.
> Kannst du das Problem vielleicht auch in verständlich erklären?
Das Problem ist, dass jede neue rustc-Version davon ausgeht, dass der in 
der vorhergehenden stabilen rustc-Version definierte Namensraum zur 
Verfügung steht. Das bedeutet, man braucht immer die vorherige Version, 
um die nächste zu kompilieren. Wenn man ein Paket baut und beweisen 
möchte, dass der Binärcode dem Quelltext entspricht, muss man in jedem 
Update von vorne wieder jede einzelne Version von rustc bauen, oder zu 
jeder Zeit alle Versionen von rustc bereit halten (um den rekursiven 
Beweis aufrecht zu erhalten) die zum Bau von aktualisierten 
rustc-Paketen benötigt werden. Das finde ich technisch richtig dumm 
umgesetzt. Das macht auch die Programme zum Bereitstellen der 
Repositories komplexer als nötig.

Ein paar Leute haben das mittlerweile entschärft, indem sie einen 
alternativen Compiler in C++ geschrieben haben (mrustc), der einige 
Schritte vereint. Trotzdem ist die Kompilierung bis zur aktuellsten 
Version mit einem immensen Ressourcen- und Zeitaufwand verbunden. Das 
ist Mist. Man sollte sich auf sehr wenige Stufen einigen, auf denen dann 
die neuen Versionen basieren.

> Almdahl schrieb:
> Es ist also lächerlich, dass die Pakete online sind und gleichzeitig ist
> es lächerlich, dass die Pakete offline gecached werden?
> Wie hättest du es denn gerne?

Sorry für die missverständliche Ausdrucksweise - Ich hatte selbst etwas 
falsch in Erinnerung. Was ich kritisieren möchte ist die Möglichkeit, 
z.B. Patches von Github on the Fly beim Kompilieren über das Cargo.toml 
File zu laden und bei Dependencies auf git Links zu verweisen.
Natürlich kann man sagen, dass man das nicht nutzen muss, aber ich 
finde, dass man manche Möglichkeiten auch nicht bieten muss. Denn zum 
Bau des Paketes hat man somit implizit doch wieder online Dependencies, 
wodurch der --offline-Modus nicht geht. Man muss als Paketbauer also 
zuerst alles manuell laden und das Cargo.toml patchen, damit man es 
offline bauen kann. Hätte der Programmierer die Möglichkeit nicht, hätte 
er die Sache auch "anständig" gelöst.

Ganz ehrlich: Ich wollte gerne ein cooles Rust-Paket für eine 
Distribution bauen, aber der letztgenannte Punkt verdirbt einem dann 
einfach den Spaß und man wünscht sich ein gutes altes Makefile. 
Insgesamt bin ich dem Bau von Rust-Paketen mittlerweile eher abgeneigt.

Und ein letzter Punkt: Wenn ich eine Programmiersprache benutze, will 
ich, dass sie sehr lange stabil ist. C99 war nicht umsonst sehr 
erfolgreich. Man konnte sich einfach darauf verlassen. Ich hoffe sehr, 
dass es auch mal einen Rust-Standard gibt, der 15-20 Jahre durchhält.

von MaWin (Gast)


Lesenswert?

Almdahl schrieb:
> oder zu jeder Zeit alle Versionen von rustc bereit halten

Was ja kein Problem darstellen sollte.

> Ein paar Leute haben das mittlerweile entschärft, indem sie einen
> alternativen Compiler in C++ geschrieben haben (mrustc)

Na siehste. Das Problem ist also praktisch gelöst.
Rust für GCC wird es auch bald geben. Vermutlich nächstes Jahr.

> Natürlich kann man sagen, dass man das nicht nutzen muss

Genau.
Deshalb ist es auch kein Problem.

> Und ein letzter Punkt: Wenn ich eine Programmiersprache benutze, will
> ich, dass sie sehr lange stabil ist.

Das ist meiner Erfahrung nach bei Rust auch so.
Deine Schilderungen zu BLFS und FF kann ich nicht kommentieren, da ich 
das nicht ausprobiert habe und die Hindergründe nicht kenne.
In meiner Erfahrung gab es aber noch nie ein Paket, dass nach einem 
Compilerupdate nicht mehr funktioniert hätte. Und ich denke da bin ich 
nicht alleine mit.

von Almdahl (Gast)


Lesenswert?

MaWin schrieb:
> Almdahl schrieb:
>> oder zu jeder Zeit alle Versionen von rustc bereit halten
>
> Was ja kein Problem darstellen sollte.
Für ein mickriges Paket ist der Ressourcenverbrauch extrem.

>> Ein paar Leute haben das mittlerweile entschärft, indem sie einen
>> alternativen Compiler in C++ geschrieben haben (mrustc)
>
> Na siehste. Das Problem ist also praktisch gelöst.
Nicht wirklich...
> Rust für GCC wird es auch bald geben. Vermutlich nächstes Jahr.
Dann wäre es eventuell tatsächlich gelöst. Aber bis das stabil ist, 
werden ja sicherlich auch wieder Jahre ins Land gehen... Schade, dass es 
nicht früher umgesetzt wurde.

>> Natürlich kann man sagen, dass man das nicht nutzen muss
>
> Genau.
> Deshalb ist es auch kein Problem.
Ich finde es schon problematisch, wenn viele unwissend Code schreiben, 
der auf Github vergammelt, weil keiner ihn packagen will. Und das wird 
durch die Möglichkeiten, die Cargo bietet, eben zum Teil gefördert.

von MaWin (Gast)


Lesenswert?

Almdahl schrieb:
> Für ein mickriges Paket ist der Ressourcenverbrauch extrem.

Im Zeitalter von Terabytefestplatten?
Zudem man das ja nicht für jedes Paket machen muss, sondern maximal ein 
mal pro Distribution.

Ich glaube du konstruierst dir da wirklich zwanghaft deine Probleme.

> Schade, dass es nicht früher umgesetzt wurde.

Rust ist nach wie vor eine sehr junge Sprache, die sich rasant 
weiterentwickelt und dabei produktiv einsetzbar und rückwärtskompatibel 
bleibt.

Rust is here to stay.
Egal wie viel so mancher sich dagegen sträubt.
Wenn es Probleme beim Distri-Packaging mit Rust gibt, dann ist es die 
Aufgabe der Distris das zu lösen. Wenn sie es nicht lösen, dann werden 
sie abgehängt werden. Die Rustwelle rollt auch ohne die Hilfe von 
Linux-Distributionen.

> wenn viele unwissend

Ja, es ist problematisch, wenn Leute keine Ahnung von dem haben, was sie 
tun.
Mit Rust hat das allerdings nichts zu tun.

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
>> Für ein mickriges Paket ist der Ressourcenverbrauch extrem.
> Im Zeitalter von Terabytefestplatten?

Auch im Zeitalter von Terabyte-Storage und Gigabyte-Speicher ist nicht 
jedes Problem mit der Nutzung sämtlichen zur Verfügung stehenden 
Stauraums gut gelöst.

> Rust ist nach wie vor eine sehr junge Sprache, die sich rasant
> weiterentwickelt und dabei produktiv einsetzbar und
> rückwärtskompatibel bleibt.

Mal schauen. Die Sprache mag ja gut sein, der Lernaufwand ist verglichen 
mit anderen modernen Sprachen aber enorm - und das Tooling je nach 
Sichtweise entweder eine Katastrophe (wenn man C/embedded kennt) oder 
der Wunschtraum der agilen Welt (wenn man JS/web kennt).

C ist vor allem deswegen noch aktuell, weil man dafür nicht nur relativ 
einfach Compiler entwickeln kann (was für C++ nicht der Fall ist), 
sondern auch weil es in sich langfristig stabil war und ist.

Der Rust-Ansatz ist eher vom Format "wir liefern auch den alten Compiler 
mit". Da das Ökosystem aber auch Dependencies aufbaue und diese 
natürlich die neuen Features wollen, ist der praktische Nutzen sehr 
begrenzt. Wenn die Kompatiblität tatsächlich gebrochen werden sollte, 
dann kann das in einer Python 2.x/3.x-Situation münden. Alles nicht ganz 
einfach.

Mal schauen, was der Linux-Ansatz bringt - denn Linus wird ganz sicher 
keine Abhängigkeit zu Web-Services oder Paketmanagern reinbringen.

Almdahl schrieb:
> Meine Meinung zu Rust ist, dass die Entwickler von Rust
> anscheinend noch nie für Linux ein Paket gebaut haben.

Müssen sie auch nicht. Heutzutage schreit man Docker, Snap und so.

von MaWIn (Gast)


Lesenswert?

S. R. schrieb:
> Wenn die Kompatiblität tatsächlich gebrochen werden sollte,
> dann kann das in einer Python 2.x/3.x-Situation münden.

Warum glaubst du, dass das auch tatsächlich passieren kann?
Mit den Editions hat man einen wirksamen Mechanismus, um auch größere 
Umbauten vollständig rückwärtskompatibel durchzuführen.

Python hingegen hat keinen solchen Mechanismus. Genau deshalb ist Python 
viel schlechter aufgestellt, was die Rückwärtskompatibilität angeht. Und 
das endet dann in Sachen wie der 2/3-Transition, aber auch in konstant 
eingeführten kleinen Inkompatibilitäten in so gut wie jeder neuen 
Version.

> denn Linus wird ganz sicher
> keine Abhängigkeit zu Web-Services oder Paketmanagern reinbringen.

Ist auch gar nicht notwendig. Wie hier schon mehrfach erklärt wurde.
Alle nötigen dependencies können lokal vorgehalten werden. Mit und ohne 
cargo.

> Die Sprache mag ja gut sein, der Lernaufwand ist verglichen
> mit anderen modernen Sprachen aber enorm

Verglichen mit welchen Spachen?

> und das Tooling je nach Sichtweise entweder eine Katastrophe

Warum? Gerade weil die Rust Toolchain alles mitbringt, was man eh 
braucht, ist es extrem einfach zu verwenden.

von Almdahl (Gast)


Lesenswert?

Ich fasse es mal ehrlich zusammen:

Wenn Rust22 gäbe, und dies mit GCC mit kompetitiver Performance 
kompilierbar wäre, würde ich nicht nur C, sondern auch viel Python, 
damit sofort ersetzen. Einfach, weil Rust das Zeug dazu hat, dies aus 
Sprachperspektive und Library-Support zu leisten.

Solange die gravierenden Kritikpunkte (aus meiner Sicht) bleiben, 
betrachte ich Rust weiter wehmütig, als Sprache, die ich gern einsetzen 
würde, aber es aus Vernunftgründen noch nicht kann.

Und zu Containern habe ich eine etwas kontroverse Meinung :).

von Hinterherhinkender (Gast)


Lesenswert?

Was sind Eure Rust Anwendungen und Targets?

Redet man hier hauptsächlich von Embedded oder PCs und Co.?

Im embedded Bereich gibt es da schon fertige Tools für bestimmte uC und 
wie verläßlich sind diese Tools?

Wie leicht ist Umportierung von C/C++ auf Rust und wie leicht kommt man 
mit Rust an die uC HW ran? Wie steht es mit äquivalenten Bibliotheken? 
Wie geht das Debugging von embedded Projekte am Besten mit Rust?

Wie schwierig ist die Konfigurierung im Vergleich zu altbekannten 
Werkzeugen?

Wie schwer tut man sich wenn z.B. der Chef man möchte doch z.B. von 
STM32 oder PIC/AVR auf ein Rust Entwicklungssystem umzusteigen? Wird 
PIC/AVR unterstützt?

Gibt es Case Studies wie man ein existierendes erfolgreiches embedded 
Projekt (STM32/AVR/PIC) von C/C++ auf Rust umsetzt und erfolgreich baut 
und betreibt?

Wie lange braucht ein typischer embedded C/C++ Entwickler Rust so weit 
zu erlernen um wieder produktiv zu werden?

Ich weiß nicht ob meine Fragen den Kernpunkt von Rust treffen, aber mir 
fällt es schwer eine befriedigende Perspektive ins Gesichtfeld zu 
bekommen. Bis jetzt fand ich die Rust Webinformationen doch nicht so 
hilfreich.

von MaWIn (Gast)


Lesenswert?

Hinterherhinkender schrieb:
> embedded

Ich denke alle deine Fragen kann man so beantworten:

Theoretisch hat Rust das Zeug richtig gut im Embedded-Bereich zu werden.
Praktisch ist es dort heute aber noch nicht wirklich einsetzbar.

Es sei denn ein Gerät der Raspberry-Pi-Klasse gilt als Embedded. Dort 
ist Rust gut einsetzbar.
Aber so etwas wie AVR funktioniert zwar prinzipiell, ist aber noch sehr 
weit von der Serienreife entfernt.

von oszi40 (Gast)


Lesenswert?

W.Gates schrieb:
> Was der Bauer nicht kennt frisst er nicht.

Ein Programm was ewig funktioniert ist selten. Frage ist, wieviele 
Helfer man für Rust im Ernstfall findet und das auch noch in xx Jahren. 
Zumindest gibt es glücklicherweise schon einige englische Bücher dafür. 
https://www.oreilly.com/library/view/programming-rust/9781491927274/

von Olaf (Gast)


Lesenswert?

> Ist auch gar nicht notwendig. Wie hier schon mehrfach erklärt wurde.
> Alle nötigen dependencies können lokal vorgehalten werden. Mit und ohne
> cargo.

Man kann viel, man muss es nur machen. Vermutlich dann irgendwie 
kompliziert und man ist ja vergesslich und der Mittelwert der Leute ist 
erschreckend faul. Und nach jedem Update bestimmt wieder neu einstellen. 
Also irgendwie...

Lies mal hier ueber das Grauen schlechthin:

https://www.heise.de/meinung/Kommentar-zu-log4j-Es-funktioniert-wie-spezifiziert-6294476.html

Wenn sich solche absurden Buildkonzepte wie mit cargo verbreiten endet 
das in 10Jahre mit Rust genauso wie hier mit Java. Dabei sehe ich 
bereits heute regelmaessig Geraete wo ich dem Programmierer gerne links 
und rechts ein paar reinhauen wuerde. (erst gestern bei einem 
Sat-Reciever)

Olaf

von MaWIn (Gast)


Lesenswert?

Olaf schrieb:
> Vermutlich

Weniger vermuten, mehr lernen.
Dependency-crates lokal zu halten ist genau so trivial wie sie von 
crates.io zu beziehen. Wenn es mit Cargo sein soll, dann gibt man den 
path zu dem crate an. Fertig. Das war es.

Alle Referenzen dazu wurden hier im Thread mehrfach genannt.

> Wenn sich solche absurden Buildkonzepte wie mit cargo verbreiten endet
> das in 10Jahre mit Rust genauso wie hier mit Java

Was hat das Buildsystem mit diesem Bug zu tun?
Warum ist es absurd?
Was hat Java mit Rust zu tun?

> wo ich dem Programmierer gerne links
> und rechts ein paar reinhauen wuerde

Gegen Agressionen helfen Waldspaziergänge.

von Olaf (Gast)


Lesenswert?

> Was hat das Buildsystem mit diesem Bug zu tun?

Die Tendenz alles immer mehr aufzublasen bis es keiner mehr durchschaut.

Olaf

von MaWIn (Gast)


Lesenswert?

Olaf schrieb:
>> Was hat das Buildsystem mit diesem Bug zu tun?
> Die Tendenz alles immer mehr aufzublasen bis es keiner mehr durchschaut.

Das Buildsystem führt zu komplexerem Programmcode?
Na wenn du meinst...

von S. R. (svenska)


Lesenswert?

MaWIn schrieb:
> Das Buildsystem führt zu komplexerem Programmcode?

Du willst missverstehen, oder?

Nein, der durch solche Buildsysteme entstehende Programmcode ist 
deutlich weniger komplex, sogar bis hin zu äußerst trivial. Der 
vollstände, das gesamte Projekt umfassende Programmcode ist hochgradig 
verteilt und schlecht bis überhaupt nicht mehr erfassbar.

Je einfacher es ist, sich zig Dependencies einzuwerfen, desto weniger 
wird über zusätzliche Dependencies nachgedacht. Dass diese 
Vorgehensweise zu im Allgemeinen zu größeren Programmen und auch 
Problemen führt, brauche ich hoffentlich nicht weiter auszuführen.

Wir sollten uns darüber hinaus sogar einig sein, dass es Workarounds für 
alle nur vorstellbaren Probleme gibt - und dass sie weder weitreichend 
benutzt werden, noch benutzt werden sollen. Letzteres führt dann im 
Zweifelsfall dazu, dass Bugreports schlicht missverstanden oder mit "so 
macht man das nicht" geschlossen werden.

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> Nein, der durch solche Buildsysteme entstehende Programmcode ist
> deutlich weniger komplex, sogar bis hin zu äußerst trivial. Der
> vollstände, das gesamte Projekt umfassende Programmcode ist hochgradig
> verteilt und schlecht bis überhaupt nicht mehr erfassbar.

Und es ist besser riesige Monolithen zu bauen, weil diese besser 
erfassbar sind?
Für mich ist das Gegenteil der Fall.

> Je einfacher es ist, sich zig Dependencies einzuwerfen, desto weniger
> wird über zusätzliche Dependencies nachgedacht.

Das ist kein Problem der Sprache oder des Buildsystems, sondern es ist 
ein Problem in deinem Entwicklungsprozess.

> Wir sollten uns darüber hinaus sogar einig sein, dass es Workarounds für
> alle nur vorstellbaren Probleme gibt - und dass sie weder weitreichend
> benutzt werden, noch benutzt werden sollen. Letzteres führt dann im
> Zweifelsfall dazu, dass Bugreports schlicht missverstanden oder mit "so
> macht man das nicht" geschlossen werden.

Diesen Absatz verstehe ich überhaupt nicht.
Was haben Bugreports und Workarounds jetzt plötzlich mit dem Buildsystem 
zu tun?

von Daniel A. (daniel-a)


Lesenswert?

Dependencies sind wie Salz, ein bisschen davon kann gut / sinnvoll sein.

Ok, der Vergleich funktioniert nicht ganz, es gibt viele Arten von 
Dependanceies. Compile-time, Runtime, Zwingende, optional, implizit, 
umgekehrt (Plugins), etc.

Zwingende Dependencies sind wie Salz, ein bisschen davon kann gut / 
sinnvoll sein.

Optionale Runtime Dependancies sind wie Butter. Immer rein damit!

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
>> Je einfacher es ist, sich zig Dependencies einzuwerfen, desto weniger
>> wird über zusätzliche Dependencies nachgedacht.
>
> Das ist kein Problem der Sprache oder des Buildsystems, sondern es ist
> ein Problem in deinem Entwicklungsprozess.

Der Programmierer ist also schuld, wenn das Ökosystem eine bestimmte 
Programmierweise begünstigt oder erfordert. Na wenn das so ist...

> Diesen Absatz verstehe ich überhaupt nicht.

Gut, dann belasse ich dich in deiner Unwissenheit.

Daniel A. schrieb:
> Optionale Runtime Dependancies sind wie Butter. Immer rein damit!

Mögen alle Binaries dieser Welt mit sämtlichen verfügbaren 
Runtime-Dependencies aktiv ausgeliefert werden! Immer her damit!
Möge die Theorie über die Realität siegen! log4j für alle!

Seufz. Frohe Weihnachten euch allen.

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> Der Programmierer ist also schuld, wenn das Ökosystem eine bestimmte
> Programmierweise begünstigt oder erfordert. Na wenn das so ist...

Der Programmierer ist dafür verantwortlich, was er programmiert.
Das ist doch sonst auch immer das Argument von C-Verfechtern. Einfach 
einmal korrekten Programmcode schreiben. Dann braucht man keine 
Bounds-Checks.

Dass "das Ökosystem" eine "bestimmte Programmierweise begünstigt oder 
erfordert" ist halt nur deine Meinung. Ich sehe keinen Zusammenhang 
zwischen Codegröße/Projektgröße/Projektkomplexität und Rust/Cargo.
Und das wurde auch hier schon alles im Thread ausdiskutiert. Nur noch 
nicht von jedem.

> Gut, dann belasse ich dich in deiner Unwissenheit.

Ok. 1:0 für mich.

von Almdahl (Gast)


Lesenswert?

Ich erkläre es einmal mit einer Analogie: Im Linux-Kernel soll man Tabs 
mit 8 Spalten benutzen. Die Begründung ist unter anderem, dass man 
dadurch gezwungen wird, die Blocktiefe gering zu halten. Schließlich 
rückt man durch jeden Block um 10% näher ans Zeilenende.

Es ist, denke ich, einleuchtend, dass diese Maßnahme einen häufig 
gemachten Fehler extrem reduzieren kann, weil man ihn technisch nicht 
mehr umsetzen kann, im Vergleich zu z.B. 2 Spalten als Einrückung.

Deshalb halte ich die Ansicht, dass Dinge die einfach durchführbar sind, 
mit der Menge an tatsächlichen Durchführungen nichts zu tun habe, für 
rational nicht nachvollziehbar.

Aus meiner Sicht gehört zum Design und Ökosystem einer 
Programmiersprache auch die Sorge um den Sinnvollen Einsatz und dem 
leisten von Hilfestellungen - in Härtefällen auch durch absichtliche 
Einschränkung oder Behinderung von höchstproblematischen Fehlern.

von Nop (Gast)


Lesenswert?

S. R. schrieb:

> Je einfacher es ist, sich zig Dependencies einzuwerfen, desto weniger
> wird über zusätzliche Dependencies nachgedacht.

Wird ja noch geiler mit Cargo, weil dann letztlich jede Anwendung ihre 
eigenen Abhängigkeiten selber statisch reingebacken bekommt. Hab dann 
mal sowas wie Log4j gerade, das wird richtig lustig werden. Da merkt man 
halt, daß Rust aus ner YOLO-Webbude stammt.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Zur Abwechslung mal gute Neuigkeiten. Der rav1e-p20211207 laesst sich 
grad mittels rustc-1.56.1 bauen. Yay!
(Notorische Schwarzseher wuerden natuerlich gleich fragen: Und wie lange 
noch? ;-)

Gruss
WK

von Carsten P. (r2pi)


Lesenswert?

S. R. schrieb:
> Mögen alle Binaries dieser Welt mit sämtlichen verfügbaren
> Runtime-Dependencies aktiv ausgeliefert werden! Immer her damit!

Ist ein bisschen off-topic jetzt, aber das hatten wir schonmal mit der 
berüchtigten "DLL Hell" unter Windows bis XP ungefähr. Und wir haben es 
in so gut wie jeder Linux-Distro.

Lade irgendeine besonders kompakte Debian-Distro runter, egal ob für 
i64- oder RPi-Habitat. Das ist jetzt bewusst polemisch, aber füge 10 
Pakete hinzu, die du brauchst oder willst, irgendeins davon referenziert 
auf irgendwas mit Grafik, auch wenn du genau das nicht willst, und 
schwupps ist aus deinem kompakten, sicheren Debian-Headless ein 
aufgeblähtes Klicki-Ubunti-Desktop-System geworden.

Ja, ich benutze an sehr vielen Stellen Linux. Nein, ich benutze kein 
IoT-Windows. Aber es ist jedesmal ein Akt des Grauens, diesen 
Troll-Horden aus Paket-Abhängigkeiten Herr zu werden.

Typisch z.b. für Windows(!)-Projekte, die ihre Ursprünge aus der 
Win32-Zeit haben, ist, dass sie auf irgendwelche uralten Runtimes 
referenzieren und auf deren Installation bestehen, obwohl man ne viel 
neuere Runtime auf dem System hat. Neuere Anwendungen sind da viel 
sauberer, ohne dass sie ständig Updates brauchen.

Typisch für Linux-Anwendungen ist, dass sie sich bis heute so benehmen. 
Das ist eben (Achtung, jetzt kommt Gemecker) der Nachteil einer offenen 
Umgebung, wo jeder macht, was er will, ohne dass außer um die ganz 
wesentlichen Dinge wie den Kernel keiner groß guckt.

Die beste Idee an Win386/Win3 war, dass es ein Aufsatz auf DOS war. DOS 
funktionierte ganz ohne Windows. Das endete mit Win95.

Ein sauberes Unix-System war immer so. Ein sauber aufgesetzter X-Server 
kann immer noch ohne Client-X11-Gedöns. Probier das mal heute mit Tools 
wie apt und Co. Und selbst, wenn du ein paar kleine Tools aus den 
Sourcen bauen willst, kommt irgendwann eine Abhängigkeit, die dir wieder 
Zeug auf die Maschine bringt, die du einfach aus Sicherheitsgründen 
nicht haben willst, wenn du den Kram nicht im Detail kennst und weder 
Zeit noch Lust hast, selbst ein Audit zu machen.

Und dasselbe gilt für sehr viele Programmierumgebungen. Setz mal nen 
Build-Server für z.B. Python auf, ohne dass auf dem Server GUI-Kram 
landet.

Um der üblichen Debatte Linux vs. Windows vorzubeugen: Es ist 
richtig(!), dass man inzwischen wieder Headless-Server unter Windows 
aufsetzen kann, aber es ist irre aufwändig und nur für Großkunden von MS 
machbar, weil die Tools nicht oder nur sehr schwer auffindbar zur 
Verfügung stehen. Der Weg von Unix war immer andersherum, so wie gesagt 
bei DOS + Windows.

Das Problem ist halt, dass ohne "offizielle Aufsicht" über die Pakete 
die OoopsSource Community macht, was sie will, und wenn ein Coder 
findet, dass er für sein Kommandozeilen-Tool ne Funktion aus ner 
Gnome-Anwendung benutzen muss, weil es halt da ist (auf seinem PC), 
wandert die Abhängigkeit halt ins Paket, und apt und Co. machen das, was 
er will und bestehen auf die Gnome-App, die auf Gnome besteht, das auf 
diesdasjenes besteht...

Wie gesagt: Schwupps!

Ich bleibe unter Linux bei genau dem, was die GNU Compiler Collection 
her gibt, weil da eben doch wer drauf guckt, plus DotNet / Xamarin-Mono, 
weil da auch wer drauf guckt, insbesondere wer, der sich um seinen 
Börsenwert schert. Es gibt das NanoFramework für uCs.

von Rolf M. (rmagnus)


Lesenswert?

Carsten P. schrieb:
> Typisch z.b. für Windows(!)-Projekte, die ihre Ursprünge aus der
> Win32-Zeit haben, ist, dass sie auf irgendwelche uralten Runtimes
> referenzieren und auf deren Installation bestehen, obwohl man ne viel
> neuere Runtime auf dem System hat. Neuere Anwendungen sind da viel
> sauberer, ohne dass sie ständig Updates brauchen.

Heute mit .net wird das eben so gemacht, dass man einfach ein Dutzend 
.net-Frameworks parallel installiert hat, weil jedes Programm eine 
andere Version braucht.

> Die beste Idee an Win386/Win3 war, dass es ein Aufsatz auf DOS war. DOS
> funktionierte ganz ohne Windows. Das endete mit Win95.

Das Problem war halt, dass man die dringend fehlenden 
Betriebssystem-Grundfunktionen nicht in DOS, was eigentlich das 
Betriebssystem war, integriert hat, sondern in dessen graphischer 
Benutzeroberfläche.

> Ein sauberes Unix-System war immer so. Ein sauber aufgesetzter X-Server
> kann immer noch ohne Client-X11-Gedöns.

Wozu brauchst du einen X-Server ohne X-Clients?

> Das Problem ist halt, dass ohne "offizielle Aufsicht" über die Pakete
> die OoopsSource Community macht, was sie will, und wenn ein Coder
> findet, dass er für sein Kommandozeilen-Tool ne Funktion aus ner
> Gnome-Anwendung benutzen muss, weil es halt da ist (auf seinem PC),
> wandert die Abhängigkeit halt ins Paket, und apt und Co. machen das, was
> er will und bestehen auf die Gnome-App, die auf Gnome besteht, das auf
> diesdasjenes besteht...

Teilweise liegt sowas aber auch an den Distros und die Art, wie sie ihre 
Pakete zusammenstellen. Das habe ich gemerkt, als ich einen 
Docker-Container für den Build einer Software aufsetzen wollte. Dafür 
musste git installiert sein, weil die Entwickler es für nötig gehalten 
haben, irgendwelche git-Kommandos als Teil des Build-Prozesses 
auszuführen. Nun gab es eigentlich unter Debian mal ein minimales 
git-Paket und ein Meta-Paket, dass git mit kompletter Doku und ein paar 
Skripten und so Zeug installiert hat. Leider wurde das minimale Paket 
verworfen, und jetzt muss immer alles installiert sein. Und da geht's 
dann los: Nur für die blöden erwähnten Skripte, die ich nicht brauche, 
muss eine komplette Perl-Umgebung mit Dutzenden von Paketen installiert 
werden. Am Ende sind die Abhängigkeiten von dem Teil von git, den ich 
nicht brauche, größer als der ganze Rest vom Container, nur weil die bei 
Debian meinen, dass man ein minimales Paket nicht mehr braucht.

von Carsten P. (r2pi)


Lesenswert?

Rolf M. schrieb:
>> Ein sauberes Unix-System war immer so. Ein sauber aufgesetzter X-Server
>> kann immer noch ohne Client-X11-Gedöns.
> Wozu brauchst du einen X-Server ohne X-Clients?

Ich meinte, dass auf dem Server nicht notwendigerweise Client-Kram 
installiert sein muss. Der kann lokal ganz ohne GUI, er liefert an die 
Clients aus.

> Teilweise liegt sowas aber auch an den Distros und die Art, wie sie ihre
> Pakete zusammenstellen. (...)
> irgendwelche git-Kommandos (...)
> Leider wurde das minimale Paket verworfen (...)
> Und da geht's dann los: Nur für die blöden erwähnten Skripte,
> die ich nicht brauche, muss eine komplette Perl-Umgebung
> mit Dutzenden von Paketen installiert werden.

Exakt das ist das perfekte Beispiel für das, was ich meinte.

Und die Person, die "wurde" ist, kriegst du nicht zu fassen, "es" wurde 
halt entschieden.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
> Wie gesagt: Schwupps!

Du schreibst leider ganz großen Unsinn und dazu hat er auch nichts mit 
Rust zu tun. Deshalb werde ich nicht näher darauf eingehen.

Bitte beim Threadthema bleiben!

von Carsten P. (r2pi)


Lesenswert?

MaWin schrieb:
> Bitte beim Threadthema bleiben!

Das Dahinter ist dasselbe. Dass du Rust-Fanboy bist, habe ich schon 
verstanden. Du hast mir bisher viele gute Replies geschrieben, also 
halte auch mal paar Krümel aus, die nicht in deine Sahnesoße passen ;-)

Fakt ist, dass Rust derzeit keine stabile, dauerhafte Umgebung mit 
Zukunft ist -- was ich auf Dauer auch für Ruby und Python vorhersage. 
Weil es nicht genug Leute gibt, die sich endlich mal damit beschäftigen, 
die OpenHorde zu bändigen und auch mal notwendige Ansagen zu machen.

von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
> Das Dahinter ist dasselbe. Dass du Rust-Fanboy bist, habe ich schon
> verstanden.

Ich bin sicher kein "Fanboy", sondern ich setze mich mit den Dingen 
auseinander, bevor ich sie bewerte.

> also halte auch mal paar Krümel aus, die nicht in deine Sahnesoße passen ;-)

Ich sehe nur, dass du hier abstraktes Zeug ablädtst.
Würdest du vielleicht einmal den Namen des Paketes nennen, bei dem eine 
komplette Desktop-Umgebung installiert wird, obwohl das nicht zu 
erwarten ist?
Dann können wir vielleicht weiterdiskutieren.

> Fakt ist, dass Rust derzeit keine stabile, dauerhafte Umgebung mit
> Zukunft ist -- was ich auf Dauer auch für Ruby und Python vorhersage.

"Fakt" also. Soso.
Belegen musst du das selbstverständlich nicht. Denn es ist "Fakt".

von Kaj (Gast)


Lesenswert?

Carsten P. schrieb:
> Fakt ist, dass Rust derzeit keine stabile, dauerhafte Umgebung mit
> Zukunft ist -- was ich auf Dauer auch für Ruby und Python vorhersage.
Python ist erst 30 Jahre alt, Ruby 26. Ja, werden bestimmt bald 
verschwinden. So wie C und C++ auch verschwunden sind.

von Dergute W. (derguteweka)


Lesenswert?

Kaj schrieb:
> Python ist erst 30 Jahre alt,

Ich waer' ja froh, wenn wenigstens mal nur Python2 verschwinden wuerde; 
aber nichtmal das klappt :-(
Gegen die Sprachen an sich hab' ich auch garnix. Ich hab' was dagegen, 
dass jeder Depp meint, er muss einen eigenen Paketmanager verwenden und 
dass sich Sprachen, die noch nicht so recht stabil sind, schon in 
irgendwelchen Projekten festsetzen, die eigentlich etwas stabiler sein 
sollten...
Aber was weiss ich schon, bin kein Informatiker.

Gruss
WK

von MaWin (Gast)


Lesenswert?

Dergute W. schrieb:
> dass jeder Depp meint, er muss einen eigenen Paketmanager verwenden

Du musst es ja nicht verwenden, wenn du das nicht möchtest. Du kannst 
dir alle Dependencies, solltest du denn welche haben, alle manuell 
zusammenstellen. Gar kein Problem.

Aber das haben wir hier im Thread bereits mehrfach geklärt.

> und dass sich Sprachen, die noch nicht so recht stabil sind, schon in
> irgendwelchen Projekten festsetzen, die eigentlich etwas stabiler sein
> sollten...

Ab wann ist denn eine Sprache nach deiner Definition stabil?
Rust ist dank der Editions äußerst stabil und es herrschen ziemlich 
strikte Regeln welche Änderungen innerhalb von Editions erlaubt sind, 
welche Änderungen zwischen Editions erlaubt sind und welche Änderungen 
es niemals geben wird.

https://doc.rust-lang.org/cargo/reference/semver.html

https://doc.rust-lang.org/edition-guide/introduction.html

Jedes Rust-Release wird gegen alle auf crates.io verfügbaren Pakete 
getestet (build test).

Ich persönlich habe es noch nicht erlebt, dass irgendein crate sich 
nicht bauen lassen wollte.
Im Gegensatz zu zum Beispiel C/C++-Paketen mit CMake, Autotools oder was 
auch immer. Da kommt es ständig zu Buildabbrüchen. Alleine schon, weil 
das Buildsystem sich die Dependencies nicht holen kann.

von Gerhard O. (gerhard_)


Lesenswert?

Ich wage vorauszusagen, daß es C, C++, Python, Java, PHP und Co. Und 
vielleicht auch Rust, auch in 100 Jahren noch geben wird. Was sich 
bewährt hat überlebt auch. C mag im Vergleich zu Sprachen 
Neuentwicklungen "Ancient to the Extreme" sein, hat aber Stabilität und 
Effizienz und seine eigene Eleganz. Für Kernel oder Nischen Anwendungen 
oder uC ist C in den Händen erfahrener Designer bestimmt immer noch gut 
geeignet.

Das größte Problem der modernen SW Entwicklung sind nicht 
notwendigerweise die Sprachen und Werkzeuge selber. Vielmehr verursachen 
unschöne Geschäftserwartungen und Time to Market Constraints viele 
Probleme durch Hetzerei die Produkte auf den Markt zu werfen. Man nimmt 
sich nicht mehr die Zeit, durchdacht und gemächlich vorgehen zu können. 
Deshalb haben wir ja auch andauernd persistente Sicherheitslücken. Ein 
Gebäude ist nur so robust wie sein Grundgerüst. Viele moderne IT 
Produkte können aus der Sicht des Users teilweise sehr nervig sein weil 
man sich nicht die Zeit nimmt, ergonomische Unebenheiten auszubügeln. 
Das ist sehr schade, weil jene so vermeidbar wären. Wer hat sich noch 
nicht maßlos geärgert wenn sich ein Gerät so dumm verhält und unnötig 
schwer bedienbar ist.

Was wir in der Welt weniger brauchen ist diese Lawine von unwichtiger 
Elektronik und SW. Es ist Zeit Fazit zu nehmen um festzustellen wo wir 
uns befinden und ins nicht länger vom Strom des Marktes mit schwemmen 
lassen. Daß das zutreffend ist, kann man alleine daraus folgern, daß 
kaum einer heutzutage imstande ist tolle Produkte zu nennen die 
erinnerungswürdig sind. Wir werden von einer Lawine fernöstlicher 
vergessbaren Ramschware und Billigprodukten erdrückt und verlieren 
eigenes Produktionspotenzial. Wie viele Firmen können aus diesen Grund 
schon lange nicht mehr überleben.

Beruflich ist es sowieso notwendig gut in der (den) Sprache(n) zu sein, 
für die ihm der Brötchengeber bezahlt und in die Firmenkultur reinpasst.

Was mich und meine Anwendungen betrifft finde ich C besonders praktisch 
und das braucht sonst niemand besonders interessieren. Was mir an C 
gefällt ist die maschinennahe direkte Übersetzung und für uC Anwendungen 
ist das nicht unbedingt ein Nachteil. Man abstrahiert heute m.M.n. 
sowieso oft unnötig zu viel. Aber jeder mag es so halten wie es ihm für 
zweckmässig erachtet.

Ich verstehe nicht wirklich warum wegen Computersprachen in den Foren so 
oft hitzige Glaubenskriege verursacht werden. Wir sind doch keine 
Missionare. Jeder kann doch diejenigen Werkzeuge verwenden die subjektiv 
attraktiv sind und für die beabsichtigten Zwecke gut funktionieren. Auch 
sind wir nicht alle gleich in der Art wie unsere Gehirne diesbezüglich 
funktionieren; der eine hat eine natürliche Affinität für 
objektorientierte Denkweise, der Andere ist mit prozedurer Denkweise 
total komfortabel. Deshalb sind diese ganze Streitereien und 
Diskussionen überflüssig weil wir alle grundverschieden sind. 
Konformität ist nur beruflich benötigt. Viele Argumente sind subjektiv 
bestimmt exakt zutreffend, aber nicht unbedingt in anderen Augen. Mit 
genug Disziplin und Erfahrung kann man in fast allen Sprachen 
zuverlässige SW bauen, sogar auch in C:-)

Ob jetzt aus Rust ein Erwachsener wird, muß die Zukunft zeigen. Wenn es 
tatsächlich die Erwartungen eventuell erfüllen wird, dann wird es auch 
früher oder später eine solide Nische im Arsenal der Computerwerkzeuge 
finden. Time will tell. Bis dahin wird man eben sich damit befassen 
müssen.

von MaWin (Gast)


Lesenswert?

Gerhard O. schrieb:
> Man nimmt
> sich nicht mehr die Zeit, durchdacht und gemächlich vorgehen zu können.
> Deshalb haben wir ja auch andauernd persistente Sicherheitslücken.

Ich würde das nicht als Hauptgrund für die Sicherheitslücken sehen, die 
wir ständig haben. Ich würde das eher in dieser Reihenfolge (1 = 
Hauptgrund) bewerten:

1: Kompetenz und Sicherheitsbewusstsein bei den Entwicklern ist nicht 
ausgeprägt genug. Aktuelles Beispiel? log4j.

2: Die Sprache erlaubt viel zu einfach triviale Schwachstellen. 
Aktuelles Beispiel?
https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/lua/lua_request.c?r1=1896039&r2=1896038&pathrev=1896039
Das wäre mit Rust auch ein Bug, ein DoS, aber keine 
Speicherkorruption/Sicherheitslücke, die man eskalieren kann.

999: Druck vom Management und zu wenig Zeit.

von MaWin (Gast)


Lesenswert?

Gerhard O. schrieb:
> Wir sind doch keine Missionare.

Genau.
Wenn jemand kein Rust verwenden will, dann soll er es halt lassen. Wenn 
jemand meint C wäre die Antwort auf alle Fragen, dann soll er halt C 
verwenden. Das ist mir wirklich egal, was jeder tut.
Ich sage ja auch nicht, dass Rust die Lösung für alle Probleme ist und 
dass ab sofort Rust für alles verwendet werden muss.

Was ich nicht mag ist, wenn Unsinn verbreitet wird.

Viel Unsinn in diesem Thread ist einfach von Leuten, die Rust eindeutig 
noch nie verwendet haben und die Sprache nur aus dem Heise-Forum kennen.

Und dann gibt es auch noch die Leute, die grundsätzlich gegen alle 
Neuerungen sind. Da wäre ich froh, wenn die sich einfach komplett vom 
Thema fern halten. Lasst uns doch machen und lasst uns doch scheinbar in 
die Sackgasse fahren. Kann euch doch egal sein.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

MaWin schrieb:
> Ab wann ist denn eine Sprache nach deiner Definition stabil?
Weiss ich nicht. Aber ich merk' wann was instabil ist: Wenn z.b. nach 
ein paar Monaten schon compiler und code irgendwie nicht mehr 
zusammenpassen wollen. Ich saug' mir das ja nicht aus den Fingern, 
sondern schreibe hier schon auch die Versionsnummern dazu.

MaWin schrieb:
> Jedes Rust-Release wird gegen alle auf crates.io verfügbaren Pakete
> getestet (build test).
>
> Ich persönlich habe es noch nicht erlebt, dass irgendein crate sich
> nicht bauen lassen wollte.
Ich will auch kein crate bauen, schlonz verschwurbeln oder ein Honk 
verschradeln oder sonst sowas exotisches.
Ich will ein Videocodec. Aus sourcen. Punkt. Nix weiter.
Und das klemmt deutlich haeufiger und unangenehmer, wenn da Rust im 
Spiel ist. Auch wenn du mir 10x erzaehlst, dass da Rust natuerlich 
ueeeeberhaupt nix dazu kann. Der Kommunismus kann auch nix dazu, das er 
mit real existierenden Menschen nicht funktioniert. Aber deshalb sollte 
man ihn nicht einsetzen. Wie Rust.

MaWin schrieb:
> Im Gegensatz zu zum Beispiel C/C++-Paketen mit CMake, Autotools oder was
> auch immer. Da kommt es ständig zu Buildabbrüchen. Alleine schon, weil
> das Buildsystem sich die Dependencies nicht holen kann.
Und genau das ist gut so. Ich will wissen, was da fuer dependencies 
drinnen sind. Und bei gut geschriebener Software kann ich mir's sogar 
raussuchen, ob ich irgendeine lib und ihre Funktionalitaet drinnenhaben 
will oder nicht. Bei ffmpeg ist das ein Thema, weil davon dann auch die 
Lizenz abhaengt, unter der das dann steht.

Bei den Autotools ist's sogar so geil, das man auch nach langer Zeit 
einfach mal in der config.log nachschauen kann, mit was man das Dingens 
damals tatsaechlich konfiguriert & gebaut hat.
Bei cmake, ninja, meson siehts bei so elemetaren Sachen ja eher schon 
arg mau aus - oder ich bin einfach zu bloed.

Gruss
WK

von MaWin (Gast)


Lesenswert?

Dergute W. schrieb:
> Ich saug' mir das ja nicht aus den Fingern,
> sondern schreibe hier schon auch die Versionsnummern dazu.

Ich sage ja nicht, dass das nicht stimmt.
Sondern ich sage nur, dass du dort eine absolute Ausnahme erwischt hast.

> Ich will wissen, was da fuer dependencies drinnen sind

Kein Problem mit Cargo:
https://doc.rust-lang.org/cargo/commands/cargo-tree.html

> Und bei gut geschriebener Software kann ich mir's sogar
> raussuchen, ob ich irgendeine lib und ihre Funktionalitaet drinnenhaben
> will oder nicht

Kein Problem mit Cargo:
https://doc.rust-lang.org/cargo/reference/features.html

> Bei den Autotools ist's sogar so geil, das man auch nach langer Zeit
> einfach mal in der config.log nachschauen kann, mit was man das Dingens
> damals tatsaechlich konfiguriert & gebaut hat.

Kein Problem mit Cargo:
Cargo.lock

Aber wenn dir Cargo nicht passt, kannst du selbstverständlich auch dein 
Rust-Projekt mit Autotools bauen oder mit jedem anderen beliebigen 
Buildsystem.

von Carsten P. (r2pi)


Lesenswert?

> Ich will mir mal einen heif-decoder
> (das neue,lustige Video/Bildformat
> von Apple unter Linux

Okay, da würde ich auch als Fauchbatz und Knurrer nur sagen "Fuck U, so 
what" xD Wer das neue lustige Format von den neuen Apple Situps mit den 
neuen von Google verkrackten Crunches vergleicht und dabei auch noch 
Sicherheit und so haben will, im Ernst... lol

von A. F. (chefdesigner)


Lesenswert?

cppbert schrieb:
> Das ist definitiv eine riesen Herausforderung - an der bisher jede
> Sprache ausser C (C++) und ein paar wenigen anderer, gescheitert ist -

Sehe ich ganz genau so. Embedded ist zu breit gefächert. Auf die 100 
Chips, die es im Mainboard-Bereich gibt, die aktuell laufen und neu 
unterstützt werden müssen, kommen im embedded-Bereich 10x soviele! 
Gleichzeitig sind es 100x weniger Nutzer!

Es lohnt sich dreimal, eine Programmiersprache auf low level den PCs 
hinterher zu entwickeln, aber im embedded Bereich ist man immer 
hinterher. Auch die Gold-Anbieter decken immer nur einen Teil der 
Landschaft ab und teilen sich so den Markt. Wie will ein am Ende doch 
kleines Team das bewältigen?

Der Aufwand für solche Neuimplementierungen und BSPs liegt im embedded 
Bereich bei locker dem 3-4 fachen und zusammen mit der Vielfalt der 
Chips braucht es 200 ... 500 mal mehr Entwickler, um Schritt zu halten.

Um einen weiteren Vergleich zu ziehen wäre es interessant zu wissen, 
wieviele Compiler-Entwickler es weltweit gibt. Das sind hunderte Firmen 
mit Tausenden Programmierern. Die zu überholen wird schwer ,,,

von MaWin (Gast)


Lesenswert?

Andreas F. schrieb:
> Die zu überholen wird schwer ,,,

Es ist überhaupt nicht der Anspruch jeden Nischencompiler "zu 
überholen".
Es ist völlig in Ordnung auch in Zukunft Embedded-Software in C zu 
schreiben.

Rust unterstützt aber bereits sehr viele ARM Devices und damit einen 
Großteil des Embedded-Marktes. Wenn GCC-Rust verwendbar wird (erste 
Version vermutlich nächstes Jahr), dann wird das noch einmal gewaltig 
ausgeweitet.

von HabMut (Gast)


Lesenswert?

MaWin schrieb:
> Wenn
> jemand meint C wäre die Antwort auf alle Fragen, dann soll er halt C
> verwenden. Das ist mir wirklich egal, was jeder tut.

Mir ist das nicht egal. In vielen Fällen kann es einem egal sein was 
andere bevorzugen. Aber wenn die Wahl von Menschen, zu Folge hat, das 
Schäden für mich und andere Menschen entstehen, dann ist das nicht egal.

C Programme beinhalten häufig vermeidbare Sicherheitslücken die die 
Sicherheit von IT Systemen gefährden. In der Folge entstehen massive 
Schäden. Daten werden geklaut oder manipuliert und vielen Unternehmen 
entstehen beträchtliche finanzielle Schäden.

Ist wie mit der Logik der Schutzimpfung. Wer sich nicht impfen lässt 
trifft nicht nur eine Entscheidung für sich, sondern beeinflusst auch 
die Sicherheit anderer Menschen.

von MaWin (Gast)


Lesenswert?

HabMut schrieb:
> C Programme beinhalten häufig vermeidbare Sicherheitslücken die die
> Sicherheit von IT Systemen gefährden. In der Folge entstehen massive
> Schäden. Daten werden geklaut oder manipuliert und vielen Unternehmen
> entstehen beträchtliche finanzielle Schäden.

Das ist richtig.
Trotzdem kannst du andere Leute nicht dazu zwingen eine Sprache zu 
verwenden, die sie nicht verwenden möchten.
Dir steht aber offen entweder diese Programme nicht zu verwenden, oder 
sie selbst in Rust zu implementieren.

von HabMut (Gast)


Lesenswert?

MaWin schrieb:
> Trotzdem kannst du andere Leute nicht dazu zwingen eine Sprache zu
> verwenden, die sie nicht verwenden möchten.

Aus einer Kritik muss nicht immer ein Zwang hervorgehen. Kritik ist aber 
erforderlich damit etwas langfristig besser werden kann.
Genau so ist Kritik an Rust auch ok und förderlich.

von Olaf (Gast)


Lesenswert?

> C Programme beinhalten häufig vermeidbare Sicherheitslücken die die
> Sicherheit von IT Systemen gefährden.

Meinst du nicht das diese Einstellung in diesem Zusammenhang etwas
laecherlich ist oder ist Rust schon nach IEC61508 zertifiziert?

Olaf

von MaWin (Gast)


Lesenswert?

Olaf schrieb:
>> C Programme beinhalten häufig vermeidbare Sicherheitslücken die die
>> Sicherheit von IT Systemen gefährden.
>
> Meinst du nicht das diese Einstellung in diesem Zusammenhang etwas
> laecherlich ist oder ist Rust schon nach IEC61508 zertifiziert?

Es geht um Security, nicht um Safety.

von Jens B. (dasjens)


Lesenswert?

Firefox?
Ist das nicht der Laden wo die guten Entwickler, abgehauen sind, und die 
jetzt lieber einen auf bunten FF machen stats einem guten Browser?

von DPA (Gast)


Lesenswert?

HabMut schrieb:
> C Programme beinhalten häufig vermeidbare Sicherheitslücken die die
> Sicherheit von IT Systemen gefährden. In der Folge entstehen massive
> Schäden.

Nein, jedes Programm in jeder Programmiersprache hat zwangsläufig 
Sicherheitslücken. Daran ändert Rust nichts. Man sehe sich z.B. log4j 
an. Java ist absolut Memory Safe, dank Garbage Kollektion. Und trotzdem 
hat man plötzlich gemerkt, das eigentlich jedes Java Programm einen 
format String basierten Remote Code Execution Bug hat.

Eine Programmiersprache hilft nur wenig beim verhindern von solchen 
Fehlern. Was man wirklich braucht sind (bei der Entwicklung) Erfahrung, 
KISS, einen Überblick, was alle Programmkomponenten genau machen und wie 
sie zusammen spielen, (und bei OPs) jemand der alles Updated wenn 
Probleme gefunden werden, Tests, offizielle Kanäle zum melden von Bugs, 
und eventuell von zeit zu zeit mal ein Audit, usw.

Und massive Schäden vermeidet man auch nicht mit einer "sicheren" 
Sprache. Statdessen braucht man eine gute Incidence Response Strategie, 
und regelmässige Übungen. Also offline Backups von allem, das zurück 
spielen prüfen, eventuell ein Fallback System (das kann auch analog 
sein, Hauptsache jeder weiss, was er Zutun hat), etc. Idealerweise 
sollte alles weiterlaufen, wenn mal das Haus abfackelt.

von Carsten P. (r2pi)


Lesenswert?

HabMut schrieb:
> C Programme beinhalten häufig vermeidbare Sicherheitslücken die die
> Sicherheit von IT Systemen gefährden.

Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber 
"sicher" keine sicherheitsrelevanten großen Systeme. Ich kenne genau 
einen sehr versierten "plain C"-Entwickler, dem ich meine Bedürfnisse 
nach einer Software anvertrauen würde, und der verwendet eine selbst 
entwickelte GC, da ist nix mit malloc(). strcpy() und free(). Läuft seit 
der ersten Version sogar auf S7-Steuerungen.

Traue keiner Runtime ohne verwaltetem Speicher! Und traue gar keinem 
System ohne eine Runtime/einem Framework! Das gilt für Linux wie für 
Windows wie für Android wie für iOS.

von Nop (Gast)


Lesenswert?

DPA schrieb:

> Nein, jedes Programm in jeder Programmiersprache hat zwangsläufig
> Sicherheitslücken. Daran ändert Rust nichts.

Das Argument war aber nicht, daß Rust-Programme keine Sicherheitslücken 
hätten, sondern daß ganze Fehlerklassen mitsamt den zugehörigen 
Sicherheitslücken ausgeschlossen werden. Formatstring-basierte Lücken 
können C/C++-Programme nämlich zusätzlich zu den Speicherlücken haben.

von Carsten P. (r2pi)


Lesenswert?

Nop schrieb:
> Das Argument war aber nicht, daß Rust-Programme keine Sicherheitslücken
> hätten, sondern daß ganze Fehlerklassen mitsamt den zugehörigen
> Sicherheitslücken ausgeschlossen werden. Formatstring-basierte Lücken
> können C/C++-Programme nämlich zusätzlich zu den Speicherlücken haben.

Zur Ehrenrettung anderer Umgebungen sei noch erwähnt, dass die das auch 
können, nicht nur Rust. Python ist da recht stabil, wenn auch langsam, 
das .NET NanoFramework kann das ebenso, nur schneller.

Manche Leute meinen halt, dass das Programmieren von Mikrocontrollern 
weh tun muss, drum dann C. Die Zeiten ändern sich, auch wenn es manchen 
Leuten nicht passt. Wie gesagt, Python, Rust, NanoFramework sind halt 
das, was man heute einfach benutzt. Und für extrem zeitkritische 
Applikationen nimmt man halt entweder Maschinencode oder einfach die 
Version des uC, der schnell genug ist. Wer da auf den Cent genau 
kalkuliert, kalkuliert garantiert zweimal.

von DPA (Gast)


Lesenswert?

Nop schrieb:
> Das Argument war aber nicht, daß Rust-Programme keine Sicherheitslücken
> hätten, sondern daß ganze Fehlerklassen mitsamt den zugehörigen
> Sicherheitslücken ausgeschlossen werden.

Das mag ja sein, aber Speicherbasierte Sicherheitslücken sind meist 
nicht trivial auszunutzen, da brauchen Angreifer doch etwas Zeit, 
know-how, und Zusatzwissen zum Zielsystem. Den fix hat man dann meistens 
lange bevor das jemand ausnutzen kann.

Aber all die anderen Fehlerklassen (format string confusion, zeugs das 
code/module nachlädt und ausführt, xss artiges zeug, parser bugs, path 
confusion bugs, supply chain Attacken, etc. etc., alles viel einfacher 
auszunutzen, und meiner Meinung nach viel gefährlicher.

Zu meinen, Speichersicherheit mache den unterschied, ist wie die 
Vordertür abschliessen, aber nicht nachsehen, ob die Hintertür noch 
offen ist. Alles nur ein tropfen auf den heissen Stein, ein falscher 
sinn von Sicherheit, nutzlos!

von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
> Zur Ehrenrettung anderer Umgebungen sei noch erwähnt, dass die das auch
> können, nicht nur Rust.

Es geht aber darum, dass Rust diese Konzepte erzwingt und noch viel 
weiter treibt (Lifetimes) als z.B. C++.
Ein Rust-Programm kann kein UB durch AOOB-Accesses haben. Ein 
Rust-Programm kann keine Data-Races haben.
Es ist ein riesiger Unterschied, ob man in C++ diese Fehler auch 
vermeiden kann, oder ob diese Fehler in Rust gar nicht möglich sind.

> Und für extrem zeitkritische
> Applikationen nimmt man halt entweder Maschinencode

Oder halt Rust.

von Olaf (Gast)


Lesenswert?

> Nein, jedes Programm in jeder Programmiersprache hat zwangsläufig
> Sicherheitslücken. Daran ändert Rust nichts. Man sehe sich z.B. log4j
> an.

Das Problem hier ist aber das man fremden Source in eigenen Programmen 
benutzt und der nicht fehlerfrei ist. Etwas das ja wohl heute Standard 
sein duerfte. Und die Leute machen das weil es bequemer, einfacher, 
zeitsparender ist als wenn man es selber macht. Gelegentlich auch weil 
ein fremder Autor mehr Expertise in einem Thema hat als man selber. 
Alles Dinge die sicherstellen das man garnicht in der Lage ist selber 
die Fehler in fremden Source zu finden.

Man koennte auch sagen die zunehmende Featureritis sorgt dafuer das die 
Wahrscheinlichkeit fuer solche Probleme start ansteigt. Bisher im 
Embedded bereich noch nicht so stark, aber wir holen auf. :-)

Alle Leute denken: Ach, diese Library benutzen ja schon 23425123 Leute, 
also wird sie wohl okay sein, was kann schon passieren. :-D

Olaf

von Oliver S. (oliverso)


Lesenswert?

MaWin schrieb:
> Ein Rust-Programm kann kein UB durch AOOB-Accesses haben. Ein
> Rust-Programm kann keine Data-Races haben.
> Es ist ein riesiger Unterschied, ob man in C++ diese Fehler auch
> vermeiden kann, oder ob diese Fehler in Rust gar nicht möglich sind.

Und die Titanic war unsinkbar.

Solange eine Programmiersprache praktisch relevante Programme erlaubt, 
wird diese Fehler oder Sicherheitslücken zulassen. Solange Menschen 
Programmcode basteln, wird dieser Fehler oder Sicherheitslücken 
enthalten.

Trotzdem ist jeder Fortschritt ein Fortschritt, wenn er sich bewährt.

Oliver

von HabMut (Gast)


Lesenswert?

Es geht gar nicht darum eine utopische perfekte Programmiersprache zu 
schaffen mit der Sicherheitsprobleme unmöglich sind. Ich spreche von 
bedeutenden Verbesserungen und wie hier schon erwähnt wurde, dass ganze 
Kategorien von möglichen Sicherheitsproblemen ausgeschlossen werden.

Mit einem heutigen Auto kann man auch Unfälle bauen. Trotzdem würde ich 
von den Autos der ersten Generation abraten. Weil die noch viele 
Probleme aufweisen die man heute schon gelöst hat.

von DPA (Gast)


Lesenswert?

HabMut schrieb:
> Es geht gar nicht darum eine utopische perfekte Programmiersprache zu
> schaffen mit der Sicherheitsprobleme unmöglich sind. Ich spreche von
> bedeutenden Verbesserungen und wie hier schon erwähnt wurde, dass ganze
> Kategorien von möglichen Sicherheitsproblemen ausgeschlossen werden.

1 oder 2 Kategorien, von unzähligen. Schön und gut, aber ich würde das 
jetzt nicht gleich bedeutend nennen. Und wenn man bedenkt was für ein 
Krampf es sein kann, Rust zu schreiben, im Vergleich zu anderen sicheren 
Sprachen wie z.B. Java und Python, zweifle ich doch stark daran, dass 
sich das lohnt.

von MaWin (Gast)


Lesenswert?

Oliver S. schrieb:
> Und die Titanic war unsinkbar.
> Solange eine Programmiersprache praktisch relevante Programme erlaubt,
> wird diese Fehler oder Sicherheitslücken zulassen. Solange Menschen
> Programmcode basteln, wird dieser Fehler oder Sicherheitslücken
> enthalten.

Aber eben keine UB durch AOOB-Zugriffe und auch keine Data-Races.
Generell gibt es gar keine UB in Safe-Rust. Rust ist in dieser Hinsicht 
tatsächlich "unsinkbar".

UB/AOOB und Data-Races sind für einen sehr großen, wenn nicht den 
größten, Teil der Sicherheitslücken in Software verantwortlich.

DPA schrieb:
> 1 oder 2 Kategorien, von unzähligen.

Nein. Die relevantesten von unzähligen.

DPA schrieb:
> Und wenn man bedenkt was für ein
> Krampf es sein kann, Rust zu schreiben,

Warum? Kannst du das etwas näher erläutern, was hier "ein Krampf" sein 
soll?

> im Vergleich zu anderen sicheren
> Sprachen wie z.B. Java und Python,

Weder Java noch Python bieten zum Beispiel die Garantie der Abwesenheit 
von Data-Races.

Ich finde es auch gar nicht angebracht Rust mit Python zu vergleichen.
Das sind zwei völlig verschiedene Sprachen mit völlig verschiedenen 
Einsatzgebieten.
Rust hat gar nicht den Anspruch Python zu ersetzen.

von DPA (Gast)


Lesenswert?

MaWin schrieb:
> Weder Java noch Python bieten zum Beispiel die Garantie der Abwesenheit
> von Data-Races.

Ja schon, aber es gibt viele sehr einfache Wege, diese zu vermeiden. Das 
Problem hat man ja nur, wenn man threads verwendet, und mit mehreren 
Threads auf die selben Daten zugreift. In der Praxis braucht man das nur 
selten wirklich. Meistens braucht man überhaupt keine Threads.

Bei python ist meistens async-await eine sehr gute Alternativen.
Je nachdem kann man ein Programm auch mehrfach starten, wenn das zu 
verarbeitende untereinander unabhängig ist.
Und in Java ist es extrem einfach, lock guards zu machen. Eigentlich 
muss man da meistens nur nicht vergessen, die richtigen Methoden / 
Blöcke mit "synchronized"  oder "synchronized(objekt)" zu kennzeichnen.

Zudem ist noch zu beachten, dass man den Ablauf auch falsch machen kann, 
ohne klassische Data-Races. z.B. Kannst du trotzdem festlegen, dass ein 
Bankomat Geld ausgibt, und dass er es vom Kontobetrag abzieht, ohne 
festzulegen, das erst das eine, und dann erst das andere passiert. Du 
kannst in Rust dann halt nicht gleichzeitig auf den Kontobetrag 
zugreifen, und es ist etwas schwerer, das so derart falsch zu machen, 
aber derartige Race-Conditions kannst du trotzdem erzeugen. Ist halt 
dann kein Data-Race mehr, sondern ein falscher Ablauf, aber kein 
bisschen weniger schlimm. Es ist wie überall, die Entwickler werden 
einfach neue Wege finden, Dinge falsch zu machen.

von MaWin (Gast)


Lesenswert?

DPA schrieb:
> Ja schon, aber es gibt viele sehr einfache Wege, diese zu vermeiden.

Und genau das ist der Unterschied. Jede Sprache hat Mittel und Wege 
diese Fehlerklasse zu vermeiden. In Rust ist es gar nicht möglich 
diesen Fehler zu machen.

> Das
> Problem hat man ja nur, wenn man threads verwendet, und mit mehreren
> Threads auf die selben Daten zugreift. In der Praxis braucht man das nur
> selten wirklich.

Ja, weil es in vielen Sprachen extrem schwierig ist überhaupt Threads zu 
verwenden. (Ab C++11 ist es wenigstens in C++ recht einfach geworden).
In Rust ist es hingegen sehr einfach Threads zu verwenden. Sehr viele 
Rustprogramme nutzen Threads.

DPA schrieb:
> Bei python ist meistens async-await eine sehr gute Alternativen.

Das kann Rust natürlich auch.
Und zusätzlich kann es die Coroutinen auch noch in OS-Threads ausführen. 
Eben weil die Sprache Thread-safety erzwingt, ist dies transparent und 
ohne spezielle Vorkehrungen des Entwicklers möglich. Das kann Python 
nicht.

DPA schrieb:
> Eigentlich
> muss man da meistens nur nicht vergessen, die richtigen Methoden /
> Blöcke mit "synchronized"  oder "synchronized(objekt)" zu kennzeichnen.

In Rust kann man das gar nicht falsch machen, weil man gar keinen 
Zugriff auf die Daten bekommt, wenn man das Locking falsch macht.

DPA schrieb:
> aber derartige Race-Conditions kannst du trotzdem erzeugen.

Das ist richtig.
Hat aber auch niemand behauptet, dass Rust gleich alle Probleme löst.

von Carsten P. (r2pi)


Lesenswert?

MaWin schrieb:
> Es geht aber darum, dass Rust diese Konzepte erzwingt und noch viel
> weiter treibt (Lifetimes) als z.B. C++.

Sagte ich doch, das tun Rust, Python, NanoFramework und sicher noch ein 
paar andere. Und wie andere ebenfalls sagten, ist das nur eins der 
Einfallstore für clevere Hacker. Es gilt der Satz des indischen Weisen: 
Die größte Sicherheitslücke bei IT-Systemen sitzt vor dem Bildschirm und 
klickt auf Links.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
> MaWin schrieb:
>> Es geht aber darum, dass Rust diese Konzepte erzwingt und noch viel
>> weiter treibt (Lifetimes) als z.B. C++.
>
> Sagte ich doch, das tun Rust, Python, NanoFramework und sicher noch ein
> paar andere.

Lifetimes sind ein Alleinstellungsmerkmal von Rust. Mit fällt spontan 
gar keine andere Sprache ein, die das auch kann. Im Nachhinein ist das 
auch praktisch nicht in eine bestehende Sprache einbaubar.

> ist das nur eins der Einfallstore für clevere Hacker.

UB/AOOB und Data Races sind nicht nur "irgendein Einfallstor", sondern 
es sind die Fehlerklassen, die für den Großteil der Sicherheitslücken in 
C/C++-Software verantwortlich sind.

> Die größte Sicherheitslücke bei IT-Systemen sitzt an der Tastatur.

Eben.
Und deshalb sollte man Sprachen so designen, dass schwerwiegende Fehler 
gar nicht oder nur schwer möglich sind und im Fehlerfall nicht 
eskalierbar sind.

von Carsten P. (r2pi)


Lesenswert?

MaWin schrieb:
>> ist das nur eins der Einfallstore für clevere Hacker.
> UB/AOOB und Data Races sind nicht nur "irgendein Einfallstor"

Wo habe ich "irgendein Einfallstor" geschrieben? Zitiere mich bitte 
richtig.

von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
> MaWin schrieb:
>>> ist das nur eins der Einfallstore für clevere Hacker.
>> UB/AOOB und Data Races sind nicht nur "irgendein Einfallstor"
>
> Wo habe ich "irgendein Einfallstor" geschrieben? Zitiere mich bitte
> richtig.

Ich habe dich richtig zitiert. Und zwar so:

> ist das nur eins der Einfallstore für clevere Hacker.

von Einer (Gast)


Lesenswert?

Olaf schrieb:
> Das Problem hier ist aber das man fremden Source in eigenen Programmen
> benutzt und der nicht fehlerfrei ist.

Dieser Satz lässt sehr tief blicken.

Du implizierst nämlich, dass fremder Code mehr Fehler enthalten würde, 
als eigener Code. Und genau dieser Mindset ist die Grundlage für 
Software-Fehler, inkl. Sicherheitslücken.

Witzig dabei, dass gerade dieser Mindset immer wieder bei 
Embedded-Leuten zu finden ist, und in aktueller Zeit gerade unzählige 
Embedded-Systeme mit scheunentorartigen Sicherheitslücken glänzen.

Witzig dabei auch, dass die "große" Softwarebranche(n) diesem Irrglauben 
vor etwa 25 Jahren auch aufgesessen ist, und brutal lernen musste, wie 
falsch dieser Mindset war.

Tragisch dabei, dass wieder bewiesen wird, das Gruppe B nicht aus den 
historischen Fehlern der Gruppe A lernt, sondern die gleichen Fehler 
selbst durchleben will. Scheint irgendwie zum Mensch zu gehören.

von Onkel Darwin (Gast)


Lesenswert?

> Und deshalb sollte man Sprachen so designen, dass schwerwiegende Fehler
> gar nicht oder nur schwer möglich sind und im Fehlerfall nicht
> eskalierbar sind.

Naja. Man sollte eines dabei im Auge behalten. Es wird immer mehr in 
Sprachen programmiert, die Anwendern und Entwicklern ermöglichen, in 
kürzester Zeit, d.h. ohne zeitaufwändige Einarbeitung lauffähigen 
Programmcode zu generieren. Wo steht da Rust z.B. im Vergleich mit bei 
vielen beliebten Programmierdialekten?

Zitat von cppbert

> Die Syntax ist nicht ganz leicht und keine Programmiersprache der Welt
> vollbringt Wunder

Wer (der es nicht muss) "quält" 1) sich schon freiwillig mit Zeugs rum, 
für das sich auch bereits bewährte Alternativen anbieten? Vor allem wenn 
letztere sich bereits lange in Entwicklung und damit ziemlich in hohem 
Maße gereift sind.

Wo stehen denn z.B. die noch vor gar nicht so langer Zeit gehypten 
Sprachen wie go und Nim?

Man hört Nim-mer viel ..

Dem Linuxer mag es genügen wenn sein Code ihm ausgabemäßig die Konsole 
befüttert. Unter Windows haben es die Allermeisten aber gerne, wenn sich 
die App(likation) wohl aufgeräumt und im modernen Design dem Auge des 
Anwenders erschließt - nicht nur am Desktop, sondern am Tablet, am 
Smartphone, auf der Smartwatch usw.

Mahnende Beispiele, die das (aufgeräumte GUI-Design) offensichtlich 
nicht bieten, sind hier aus dem CAD-Bereich jüngst genannt worden 
(verschrobene Bedienweise) bzw. wie man es besser macht oder sein kann 
ebenfalls.

Vielleicht will dort Rust aber auch gar nicht hin. Vielleicht hat es der 
an Rust Interessierte mit GUI nicht so, weil ihm das zu "doof" erscheint 
und er sich lieber mit anderem befasst.

Für Quantenalgorithmen gibt es Q-Sharp. Für KI listet die Computerwoche 
vom Nov. 21 Python, C++, JAVA, R, Julia und andere. Da ist weit und 
breit nix von Rust zu lesen.

1) extra in Anführung für die Fanboys ;)

von Olaf (Gast)


Lesenswert?

> Du implizierst nämlich, dass fremder Code mehr Fehler enthalten würde,
> als eigener Code. Und genau dieser Mindset ist die Grundlage für
> Software-Fehler, inkl. Sicherheitslücken.

Nein keineswegs. Du implizierst in deiner schlichten Gedankenwelt ein 
eigene Erkenntnis und baust daraus ein falsches Weltbild das du mir 
ueberstuelpen willst.

Fremder Code kann im Rahmen gemittelter Programmiererfaehigkeit nur 
genauso gut/schlecht sein wie der eigene wenn er von relativ wenigen 
Leuten verwendet wird. Er koennte bezueglich Fehler aber auch sehr viel 
besser sein wenn er von sehr vielen Leuten verwendet wird die alle zur 
Verbesserung beitragen.

Es gibt damit aber auch Probleme:

1. Finde ich eine Luecke/Fehler in einem fremden Code kann ich das dann 
sofort bei vielen Geraeten ausnutzen. Und im Embeddedbereich kannst du 
nicht rumlaufen und den Leuten erzaehlen das die jedes Geraet  einmal im 
Monat updaten muss wie z.B bei Handysoftware.

2. Die Gruende viel fremden Code zu benutzen sind gleichzeitig gute 
Gruende den eben nicht genau zu untersuchen. Das wird ja schon jemand 
anderes gemacht haben. .-)

3. Gerade im Embeddedbereich passen unterschiedliche Programmierstile 
nicht immer perfekt zusammen. Das erhoeht die Resourcenanforderungen. 
Also mehr Strom oder teurere Controller.

4. Eine Tendenz jeden Kram in ein Geraet einzubauen und so die 
Funktionalitaet aufzublasen. Das kann natuerlich ein Vorteil sein, es 
ist aber auf jedenfall auch ein Nachteil.

Jetzt schickt sich Rust ja an C zu verdraengen. Das wuerde ich 
tendenziell positiv finden, ich sehe durchaus den Nachteil von C. 
Allerdings gefaellt mir nicht der Mindset in den Entwicklerhirnen hinter 
Rust. (Erfinden von neuen Woertern fuer alten Wein (z.b crates!), 
Propagierung anderer Buildsysteme obwohl sowas unabhaengig von einer 
Sprache zu sein hat, Internetbezug/AutoUpdates)

Olaf

von MaWin (Gast)


Lesenswert?

Onkel Darwin schrieb:
> Es wird immer mehr in
> Sprachen programmiert, die Anwendern und Entwicklern ermöglichen, in
> kürzester Zeit, d.h. ohne zeitaufwändige Einarbeitung lauffähigen
> Programmcode zu generieren. Wo steht da Rust z.B. im Vergleich mit bei
> vielen beliebten Programmierdialekten?

Das ist eine Anforderung, die einer strengen Typisierung halt 
widerspricht.
Wenn du Rapid Prototyping oder quick & dirty haben möchtest, nimm Python 
oder etwas ähnliches.

> Wer (der es nicht muss) "quält" 1) sich schon freiwillig mit Zeugs rum

Rust ist sehr C-ähnlich. Wer C kennt, findet sich schnell in Rust 
zurecht.

> für das sich auch bereits bewährte Alternativen anbieten? Vor allem wenn
> letztere sich bereits lange in Entwicklung und damit ziemlich in hohem
> Maße gereift sind.

Soso. In ziemlich hohem Maße gereift also. Die ständigen UB-basierten 
Sicherheitslücken reifen wohl mit.

> Wo stehen denn z.B. die noch vor gar nicht so langer Zeit gehypten
> Sprachen wie go und Nim?

Go hat einen völlig anderen Zweck als Rust. Das steht nicht wirklich in 
Konkurrenz.
Nim kenne ich nicht.

> Vielleicht will dort Rust aber auch gar nicht hin. Vielleicht hat es der
> an Rust Interessierte mit GUI nicht so, weil ihm das zu "doof" erscheint
> und er sich lieber mit anderem befasst.

Es ist überhaupt kein Problem GUI-Anwendungen in Rust zu schreiben. Zum 
Beispiel mit GTK.
Das ist sicher nicht der Hauptzweck von Rust, aber es geht gut.
Es wird ständig behauptet man könne Rust nicht für GUI-Applikationen 
einsetzen. Das ist ganz einfach falsch.

von MaWin (Gast)


Lesenswert?

Olaf schrieb:
> kannst du
> nicht rumlaufen und den Leuten erzaehlen das die jedes Geraet  einmal im
> Monat updaten muss wie z.B bei Handysoftware.

Auf meinem Mobiltelefon kommen täglich Updates rein.

> Erfinden von neuen Woertern fuer alten Wein (z.b crates!)

Welches Wort hättest du denn verwendet?

> Propagierung anderer Buildsysteme

Welches Buildsystem hättest du denn genommen?

> obwohl sowas unabhaengig von einer Sprache zu sein hat

Cargo ist unabhängig von der Sprache Rust.

> Internetbezug

Niemand zwingt dich Cargo online zu nutzen.
Du kannst problemlos alle crates lokal vorhalten. Statt der 
Versionsnummer gibst du einfach den relativen Pfad zum Crate in 
Cargo.toml an. Einfacher gehts kaum.

> AutoUpdates

Was soll das sein?

von Carsten P. (r2pi)


Lesenswert?

MaWin schrieb:
>> ist das nur eins der Einfallstore für clevere Hacker.

"eins" ist nicht "irgendein".

Nur zur Kenntnisnahme, auch auf die Gefahr hin, dass ich mich 
wiederhole: Ich halte "C" heutzutage für gar nichts mehr geeignet, weil 
es für alle möglichen Domains bessere Alternativen gibt. Würde heute 
noch wer ein neues Betriebssystem from scratch schreiben, würde er das 
sicher nicht in purem "C" machen, außer vielleicht die 
allerallerrudimentärsten Funktionen, die nötig sind, um einen gemanagten 
Kernel hochzuziehen, und danach zur Laufzeit diese rudimentären 
Funktionen auch gleich wieder entladen.

von HabMut (Gast)


Lesenswert?

Onkel Darwin schrieb:
> Wer (der es nicht muss) "quält" 1) sich schon freiwillig mit Zeugs rum,
> für das sich auch bereits bewährte Alternativen anbieten? Vor allem wenn
> letztere sich bereits lange in Entwicklung und damit ziemlich in hohem
> Maße gereift sind.

Was verstehst du unter bewährte Alternativen? Wenn ich Multithreading 
nutzen will, nützt es mir nicht viel das es C oder C++ schon so lange 
gibt. Ich müsste mich da für längere Zeit einarbeiten, bevor ich stabile 
Software entwickeln kann. Und danach musst du trotzdem immer aufpassen 
dass du trotz Erfahrung keine Fehler machst.
Bei Rust arbeitest du dich auch einmal mühsam in die neuen Konzepte ein 
aber danach garantiert dir der Compiler dass bestimmte schwerwiegende 
Fehler ausgeschlossen sind.

Onkel Darwin schrieb:
> Wo stehen denn z.B. die noch vor gar nicht so langer Zeit gehypten
> Sprachen wie go und Nim?
>
> Man hört Nim-mer viel ..

Bevor Python oder Java erfolgreich wurden, gab es auch andere 
Programmiersprachen die gescheitert sind. Das Sprachen kommen und gehen 
sagt nicht viel über Rust aus.

Was deine konkreten Beispiele angeht: Go wird immer noch genutzt aber 
kann aus Performance Gründen C++ nicht überall ersetzen. Ich denke es 
war auch nicht das Ziel damit Sprachen wie C++ in der gesamten Industrie 
zu ersetzen.
Und Nim? Ich hörte davon, aber ich glaube Nim bei weitem nicht so weit 
wie Rust bisher.

von Gerhard O. (gerhard_)


Lesenswert?

Ob Rust in der Industrie Fuß fassen wird hängt wahrscheinlich doch stark 
davon ab ob sich die Platzhirsche der Compilertoolfirmen wie IAR & Co. 
der Sprache annehmen werden und sie unterstützen wollen.

Deshalb nehme ich an, daß Rust genau wie andere Sprachen offiziell von 
den relevanten Standardorganisationen anerkannt werden muß. Letztens 
hängt Adoption auch von zusätzlicher notwendiger Industrie Bürokratie 
ab. Der embedded Bereich muß auch besonders berücksichtigt werden. Auch 
Debugging und Simulation sind wahrscheinlich wichtige Gesichtspunkte.

Dazu kommt, daß in vielen Firmen die Entwickler nicht unbedingt 
durchsetzen können welche Sprachen für Produktentwicklung verwendet 
werden sollen. Deshalb nehme ich an, daß man geduldig sein werden muß um 
zu erleben wie sich die Adoption ausspielen wird. Die Inertia der 
Menschen ist oft der wirkliche Hinderungsgrund warum neue Paradigmen so 
lange brauchen um Fuß zu fassen.

Erschwerend für eine Adoption werden dann manche Kunden auch darauf 
bestehen ein komplettes Rust Entwicklungspackage wie z.B. IAR Workbench 
für Rust bestellen zu können wo die praktischen Berücksichtigungen der 
realen Welt vorhanden sind. Bis dahin wird man schon abwarten müssen. 
Die Geeks mögen von Rust verzaubert sein, trotzdem fürchte ich, daß 
gerade das nicht genug ist.

OK. Jetzt dürft ihr auf mich hauen wenn ihr könnt:-)

: Bearbeitet durch User
von Carsten P. (r2pi)


Lesenswert?

So, jetzt auch mal meine Meinung zu Rust an sich, nicht das "Ja, du hast 
geschrieben: dies; ich sage dazu: das!"

Prinzipiell finde ich die Idee von Rust sehr gut. Vom Konzept her wäre 
Rust gut geeignet gerade im Embedded-Bereich auf kleinen Controllern, wo 
die Projekte ja schon aus Speichergründen nicht unbedingt ausufern, und 
die Art der Ressourcen-Verwaltung in Rust in ein riesiger Fortschritt. 
Traits gefallen mir auch, die fördern eine klare Trennung von Daten und 
Methoden. In der klassischen Objektorientierung, die ja akademisch immer 
noch so gelehrt wird, sind Daten und Methoden immer brav in einer Klasse 
verpackt, aber in der Praxis ist das nur noch Ballast (Stichwort 
"Puppet-Player-Pattern", TDA, OCP).

Was mich (das ist natürlich immer Geschmackssache) in vielen Punkten 
stört, ist die Syntax. Die sieht mir inkonsistent aus.

Zum Einen ist es im Zeitalter der großen IDEs (seien es VS xyz, sei es 
Eclipse) absolut sinnfrei, ein Wörtchen wie "function" abzukürzen.

Zum Zweiten, so gut ich es finde, dass Curlys zwangsweise sind (guter 
Stil in jeder Curly-Sprache heutzutage), kommt dann das Weglassen von 
runden Klammern wie etwas komplett Gegensätzliches daher und scheint ein 
gewisses Anbiedern an Python und sonstige Whitespace-Sprachen zu sein.

Moderne Programmiersprachen sind nicht mehr auf Tipp-Effizienz, sondern 
auf klare Syntax ausgelegt UND stören nicht mehr mit künstlichen 
Störenfrieden wie * und &. C# ist z.B. mindestens so "C"-Style wie Rust, 
verzichtet aber auf solche Stolpersteine komplett, ebenso auf :, :: und 
-> außer in unsafe-Bereichen. Moderne Programmiersprachen achten viel 
mehr auf Lesbarkeit als der olle Kram von "damals, als alles besser war" 
(eigentlich ja doch schrecklicher). Oder mag wirklich jemand die 
Sternchen-Orgien in "C" bei Funktionszeigern oder die ollen & und -> in 
C++?

Ein nicht besonders großes, aber hübsches Syntax-Gimmick ist, dass es 
keinen Unterschied mehr zwischen for- und for-each-Schleifen gibt. 
Braucht kein Mensch, richtig so. Das konnte schon lange wirklich mal 
weg! ^^

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

Gerhard O. schrieb:
> Ob Rust in der Industrie Fuß fassen wird hängt wahrscheinlich doch stark
> davon ab ob sich die Platzhirsche der Compilertoolfirmen wie IAR & Co.
> der Sprache annehmen werden und sie unterstützen wollen.

Und warum sollten sie? Welcher z.B. Industriekunde würde das fordern 
bzw. kaufen?
Solche Modesprachen existieren nur in ganz kleinen Blasen irgendwelcher 
akademischen Brainfucks und OO-Hipstern die auf jeden Quatsch 
aufspringen und eine smarte Saftpresse zuhause haben.

Gerade die Mitglieder dieser Gruppen verkennen die reale Situation und 
können anscheinend schlecht einordnen, wie irrelevant Rust im wirklichen 
Leben, da wo Geld verdient wird, eigentlich ist.

von Oliver S. (oliverso)


Lesenswert?

Olaf schrieb:
> Er koennte bezueglich Fehler aber auch sehr viel
> besser sein wenn er von sehr vielen Leuten verwendet wird die alle zur
> Verbesserung beitragen.

Finde den Fehler...

Es gibt sehr viel Code, der von sehr vielen Leuten verwendet wird. Es 
gibt aber nur sehr, sehr, sehr wenig Code, der von sehr vielen Leuten 
verwendet wird, die da auch alle zur Verbesserung beitragen.

Und die Frage, ob mehr Fehler in wenig genutzer Software besser sind, 
als wenige in viel genutzer, dürfte noch nicht endgültig ausdiskutiert 
sein.

Oliver

von Carsten P. (r2pi)


Lesenswert?

Cyblord -. schrieb:
> Gerade die Mitglieder dieser Gruppen verkennen die reale Situation und
> können anscheinend schlecht einordnen, wie irrelevant Rust im wirklichen
> Leben, da wo Geld verdient wird, eigentlich ist.

Da ist was dran, aber ich sage bewusst: leider. Wenn man sich die ganze 
Smart-Home-Szene ansieht, wo es sicher bald schon für Klospülungen ne 
App gibt (kennt noch wer diesen unsäglichen Werbespruch von Apple? "Ach, 
dafür gibt's doch bestimmt auch ne App!"), und wenn man das dann mal auf 
den Automotive-Bereich abstrahiert, dann Herzlichen Glückwunsch!

Das ist so ein bisschen wie in der alten Zeit mit Dampfloks: "Was labern 
die da über Elektrifizierung! Ich steh hier mit 1000 Tonnen am Haken an 
der Steigung, und die Räder drehen durch!"

Ob es nun Rust wird oder ne andere Sprache mit zeitgemäßen Konzepten, 
ist mir relativ. Andererseits bin ich faul, und wenn ich die Wahl 
zwischen Rust und Python haben müsste, würde ich eher Rust nehmen, weil 
sie mir vertrauter aussieht aka schneller vom Lernen zur Produktion. Ich 
bin (anders als andere hier) kein Fanboy, aber alleine schon das 
Ressourcen-Konzept ist ne bedenkenswerte Sache.

Das Argument "das hilft mir doch aber jetzt nicht!" ist ein Zeichen von 
mangelnder Planung und vor allem von einer Mischung aus zu vielen 
Aufträgen und zu niedrigen Stunden-/Projektpreisen. Und ja, ich weiß, 
wie knifflig bis unmöglich es ist, ner Kundin beizubiegen, dass sie auch 
was davon hat, wenn wir verlässlicheren Code schreiben, der gleich beim 
ersten Release einigermaßen stabil läuft.

(Bevor mich wer disst: Unternehmen sind meist "Gellschaften" (GmbH, 
AG...), drum "sie".)

: Bearbeitet durch User
von Gerhard O. (gerhard_)


Lesenswert?

Cyblord -. schrieb:
> Gerhard O. schrieb:
>> Ob Rust in der Industrie Fuß fassen wird hängt wahrscheinlich doch stark
>> davon ab ob sich die Platzhirsche der Compilertoolfirmen wie IAR & Co.
>> der Sprache annehmen werden und sie unterstützen wollen.
>
> Und warum sollten sie? Welcher z.B. Industriekunde würde das fordern
> bzw. kaufen?
> Solche Modesprachen existieren nur in ganz kleinen Blasen irgendwelcher
> akademischen Brainfucks und OO-Hipstern die auf jeden Quatsch
> aufspringen und eine smarte Saftpresse zuhause haben.
>
> Gerade die Mitglieder dieser Gruppen verkennen die reale Situation und
> können anscheinend schlecht einordnen, wie irrelevant Rust im wirklichen
> Leben, da wo Geld verdient wird, eigentlich ist.

Das sehe ich möglicherweise positiver als Du. Ich bin der Meinung, daß 
man Rust fairerweise einfach Zeit lassen muß um Fuß fassen zu können. 
Das geht deshalb nicht so schnell weil noch viele Erfahrungen in der 
realen Welt gesammelt werden müssen. Um im weiteren Bereich verwendet zu 
werden ist Standard Adoptierung hier absolut notwendig; geht aber nicht 
so schnell. Bis dahin werde ich mit Interesse die Entwicklung mit 
offenen Augen verfolgen. Bei C und C++ war es auch nicht viel anders.

von Oliver S. (oliverso)


Lesenswert?

Carsten P. schrieb:
> Und ja, ich weiß,
> wie knifflig bis unmöglich es ist, ner Kundin beizubiegen, dass sie auch
> was davon hat, wenn wir verlässlicheren Code schreiben, der gleich beim
> ersten Release einigermaßen stabil läuft.

Was der zwar zunächst Geld spart, das die dann später doppelt wieder 
ausgibt, wenn der ganze Kram wegen Unwartbarkeit auf Grund einer 
Exotenprogrammiersprache in die Tonne gekloppt werden muß.

Ich will jetzt nicht sagen, daß Rust dieses Schicksal droht, aber es ist 
noch nicht übern Berg.

Oliver

von Gerhard O. (gerhard_)


Lesenswert?

Gehört nicht unbedingt zum Thema und ist O.T., aber hier ist noch ein 
allgemeiner Aspekt der mir Sorgen macht:

Wegen der Komplexität und Device Intercommunication moderner verbundener 
Anwendungen werden sehr oft Teile der Anwendung mit eingebunden 
komplexen externen Ressourcen verwendet die nicht immer im Quellenformat 
zur Überprüfung erhältlich sind. Oft müssen BT, WLAN und Ähnliches 
funktionieren weil die Kunden alles über Smartphone und Internet steuern 
wollen. Erschwerend kommt dazu, daß nicht alle Programmierer Genies sind 
und man sich schwer tut Probleme oder Sicherheitslücken zu erkennen bzw. 
Diagnostizieren zu können.

Wenn das tatsächlich so ist, dann ist Produktentwicklung fast immer ein 
riskante Sache und die Sprache vielleicht nur sekundär wichtig. Auch 
wenn Rust z.B. schwerer durch böswillige Elemente zu hintergehen ist, 
können die eingebundenen extern entwickelten Ressourcen alle durch die 
Sprache gegebene Robustheit wieder total zunichte machen. Um bessere 
externe Sicherheit zu erzielen müssten die Probleme an der Wurzel 
angefasst werden.

Ob man dann in C++ oder Rust programmiert ist so gesehen nicht mehr so 
wichtig. Was notwendig ist, externe Stacks zu finden, die robust genug 
sind, Attacken gehörig zu erschweren. Wie man den Rest der Anwendung 
kodiert ist dann nicht mehr so kritisch wenn man nicht gerade groben 
Unfug macht. Ob ich hier mit meinen Ausführungen etwas angeschnitten 
habe was wichtig ist, kann ich praktisch nicht so gut beurteilen weil 
ich in Sachen "Verbundenheit" nicht viel mache und ihr müsst es 
wahrscheinlich besser wissen wie man sichere verbundene Apps und Geräte 
realisiert.

Noch am Rande, man sieht in den Medien und Reklame immer öfters wie man 
Smartphones zur Bedienung, Öffnung der Autoschlösser usw. anpreist. 
Ehrlich gesagt mir wäre es zu blöd jedesmal ein Handy suchen und 
bedienen zu müssen um in mein Auto einsteigen zu können. Es mag sich 
zwar sexy ansehen, aber irgendwie finde ich ist dieser ganze Trend 
überzogen. Ein Handy mag in gewissen Situationen auf diese Weise 
nützlich sein, aber nicht um jeden Preis alles vernetzen zu wollen. 
Gerade diese Sachen verursachen die meisten Sicherheitslücken.

von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
> kommt dann das Weglassen von
> runden Klammern wie etwas komplett Gegensätzliches daher

Du kannst ja runde Klammern nutzen, wenn du das möchtest. Der 
Rust-Compiler hindert dich nicht daran. Du musst nur die Warnung 
abschalten. Eine Zeile in der compiler-config.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Syntax hat man schnell gelernt. Man schaut einmal auf ein Script, dann 
kennt man die Syntax. Das selbe einfach mit anderen Klammern / Keywords 
schreiben, das ist einfach.

Aber plötzlich ändern müssen, wie man ein Programm schreibt, die 
Herangehensweise ändern müssen, und plötzlich gewisse Sachen nicht mehr 
so lösen zu können, wie man das immer überall sonst gemacht hat - das 
ist nicht einfach.

C -> Python ist ersteres.

C -> Rust ist letzteres.

Beim Umstieg zu Rust kommt noch dazu, oft weiss man, das ist in Ordnung, 
aber dann sollte man das eigentlich auch noch dem Compiler beweisen. Da 
fängt dann wahre Frustration an. Ich und der Compiler - wir haben beide 
starke Meinungen, wie wir das lieber umgesetzt sehen wollen...

von Carsten P. (r2pi)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Ich und der Compiler - wir haben beide starke Meinungen,
> wie wir das lieber umgesetzt sehen wollen...

Das ist jetzt nicht böse gemeint, eher als "frohes neues Jahr"... Dann 
schreib dir doch deinen eigenen Compiler! ;-)

von Carsten P. (r2pi)


Lesenswert?

MaWin schrieb:
> Carsten P. schrieb:
>> kommt dann das Weglassen von
>> runden Klammern wie etwas komplett Gegensätzliches daher
>
> Du kannst ja runde Klammern nutzen, wenn du das möchtest. Der
> Rust-Compiler hindert dich nicht daran. Du musst nur die Warnung
> abschalten. Eine Zeile in der compiler-config.

Gut zu wissen. Ist echt mal ein Thema zum sich näher mit beschäftigen, 
und die nächsten Tage finde ich immer wieder mal ein bisschen Leerlauf. 
Nennt sich "nicht existenter Urlaub", aber das Thema interessiert mich 
jetzt echt.

Frage an dich Fachperson: Wenn ich eine Rust-Lib "von woanders" aufrufen 
will, dann genauso wie ne C/C++-Lib?

von Olaf (Gast)


Lesenswert?

> Dazu kommt, daß in vielen Firmen die Entwickler nicht unbedingt
> durchsetzen können welche Sprachen für Produktentwicklung verwendet
> werden sollen.

Ich sehe du hast Industrieerfahrung. .-)

Wenn man die Frage aus dem Subject beantworten moechte dann sollte man 
sich vielleicht mal fragen wie kam es im Embeddedbereich zu dieser 
EXTREMEN C Dominanz. Irgendwie war die Sprache irgendwann da, irgendwie 
hat sie jeder verwendet und keiner hat es je diskutiert. Das hat mich 
auch immer gewundert.

Und noch erstaunlicher, C ist da mittlerweile seit 20Jahren dominant. Da 
kam noch nie jemand der Gedanke das man was anderes verwenden koennte. 
Das ist vollkommen anders als auf dem PC.

Daher denke ich das Rust und jede andere Sprache zumindest im 
Embeddedbereich eine lustige Modeerscheinung bleiben wird. Aehnlich wie 
FORTH oder Pearl. Es ist einfach so das die ganze Industrie extrem 
konservativ ist. Ich bin mir sicher das wir noch die 100Jahrfeier von 
4-20mA und C erleben werden. :-D

Olaf

von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
> Frage an dich Fachperson: Wenn ich eine Rust-Lib "von woanders" aufrufen
> will, dann genauso wie ne C/C++-Lib?

Du kannst in Rust Symbole und Strukturen mit C-Layout und C-Linkage 
anlegen. Wenn es das ist, was du meinst.

von MaWin (Gast)


Lesenswert?

Olaf schrieb:
> Pearl

Meinst du Perl? Das wird leider sehr massiv in der Embedded-Entwicklung 
verwendet. Aber ich denke bei Perl haben mittlerweile viele Leute 
verstanden, dass es nicht mehr zeitgemäß ist. Sogar die Perl-Entwickler 
scheinen das wohl verstanden zu haben und bauen die Sprache nun nach 
modernen Mustern um.

> Ich bin mir sicher das wir noch die 100Jahrfeier von
> 4-20mA und C erleben werden. :-D

Ja, da bin ich mir leider auch sicher.

von Carsten P. (r2pi)


Lesenswert?

Gerhard O. schrieb:
> Gehört nicht unbedingt zum Thema und ist O.T., aber hier ist noch ein
> allgemeiner Aspekt der mir Sorgen macht:
>
> Wegen der Komplexität und Device Intercommunication moderner verbundener
> Anwendungen werden sehr oft Teile der Anwendung mit eingebunden
> komplexen externen Ressourcen verwendet die nicht immer im Quellenformat
> zur Überprüfung erhältlich sind.

Im Ernst, Gerhard, wenn das OT ist, ist das ganze Forum OT. Es gibt 
derzeit wohl kaum ein überall heißer diskutiertes Thema in der ganzen 
IT-Branche als genau das da!

Deswegen verbaue ich nirgendwo auch nur zwei Devices ("Dinge" im Sinne 
von IoT), ohne dass ich einen Knoten dazwischen habe, der die Kisten 
überwacht. Bei uns ist es geschäftlich und bei mir ist es privat auch 
so, dass kein Teil verwendet wird, das fröhlich über http oder noch 
tiefer im Layer unverschlüsselte Daten in die Welt posaunen darf, es sei 
denn, es sitzt zB wie ein einfacher Sensor so nah am nächsten Knoten, 
den wir wieder unter Kontrolle haben, dass du schon die Leitung anritzen 
müsstest, um da was abzugreifen.

Ich konstruiere mal ein gar nicht so fiktives Beispiel: Du bist ein 
Einbrecher. Du hast die nötige technische (durchaus legal beschaffbare 
und auch nicht großartig aufs Konto schlagende) Hardware. Du willst 
natürlich wissen, wann wer zuhause ist. Das ganze Zuhause der Leute, die 
du ausrauben willst, ist natürlich super "smart" (eigentlich steindoof). 
Das Licht wird geschaltet, etwa im Flur, über gaaaanz smarte, übers WLAN 
angeschlossene Lichtschalter. Ja, die Daten sind verschlüsselt, die 
Hersteller sind ja nicht ganz bekloppt. Nur haben sie was vergessen.

Also hältst du deine WLAN-Antenne da aufs Haus, fischst die Pakete ab, 
und stellst fest, dass OIZ324867yyxdf "Aus" bedeutet und 6jhgbsd76345r4 
"Ein". Klingt harmlos. Nun stellst du auch fest, weil die Alarmanlage 
vom selben Hersteller und auch übers WLAN ("dafür gibt's doch bestimmt 
ne App!") läuft, dass 9786dfkjhTX&% "Alarm ein" und PIUz876r54gh "Alarm 
aus" bedeuten. Jetzt kannst du ja mal probieren, mit derselben IP (weil 
du natürlich im Promisk-Modus gelauscht hast) das Signal "Lampe ein" zu 
schicken". Wenn das geht, könnte ja vielleicht auch "Alarm aus" 
funktionieren. Da musst du überhaupt nicht wissen, was die Daten 
wirklich bedeuten. Der Trick ist übrigens schon weit verbreitet bei 
Auto-Dieben, die einfach das Signal des Funk-Schlüssels aufzeichnen und 
wiedergeben.

Würde der entsprechende Coder auf die Idee gekommen sein, einen 
Timestamp mit zu verschlüsseln, wäre das alles hinfällig. Aber wie man 
weiß, ist dem nicht so. Vielleicht, weil er nicht weit genug denkt, 
vielleicht aber auch, weil sein Chef im gesagt hat, dass bei 100.000 
gebauten Autos 10 Cent für den uC schon seinen Bonus ausmachen.

Stromzähler sind übrigens für so eine Schwachstelle bereits vom CCC und 
anderen aufmerksamen Leuten ausgemacht. Die senden gerne den Zählerstand 
ans EVU, und mit ein paar gar nicht so geheimen Tricks kriegt man von 
außen raus, wann der Stromverbrauch hoch und wann niedrig ist. 
Angenommen, bei entsprechenden Stückzahlen kosten ein AtTiny45 45 und 
ein AtMega328 328 Cent. Da kannst du dir ja vorstellen, was der 
Controller beim Kunden sagt, wenn du mit Datensicherheit anfängst, 
während der an den Bonus denkt.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
> Der Trick ist übrigens schon weit verbreitet bei
> Auto-Dieben, die einfach das Signal des Funk-Schlüssels aufzeichnen und
> wiedergeben.

Replay-Attacks funktionieren seit 20 Jahren nicht mehr bei 
Autoschlüsseln und bei allen anderen Arten von Crypto-Funkschaltern.

Und es ist hier völlig Off-Topic.

von Carsten P. (r2pi)


Lesenswert?

MaWin schrieb:
> Carsten P. schrieb:
>> Frage an dich Fachperson: Wenn ich eine Rust-Lib "von woanders" aufrufen
>> will, dann genauso wie ne C/C++-Lib?
>
> Du kannst in Rust Symbole und Strukturen mit C-Layout und C-Linkage
> anlegen. Wenn es das ist, was du meinst.

Ja, genau, das meinte ich, also so, dass ich sie von außen mit anderen 
Sprachen aufrufen kann wie ne "C"-Lib.

von Nop (Gast)


Lesenswert?

Olaf schrieb:

> Und noch erstaunlicher, C ist da mittlerweile seit 20Jahren dominant.

1) Es gibt C-Compiler für jedes Target.
2) Es ist kein Problem, C-Entwickler zu finden.
3) C ist relativ einfach.

Der dritte Punkt ist insofern relevant, als daß das eigentliche Coding 
oftmals nur ein kleiner Teil der Arbeit ist, für den man nicht extra 
einen Coding-Spezialisten einstellen würde, den man aber für eine 
komplizierte Sprache bräuchte.

von Carsten P. (r2pi)


Lesenswert?

MaWin schrieb:
> Carsten P. schrieb:
>> Der Trick ist übrigens schon weit verbreitet bei
>> Auto-Dieben, die einfach das Signal des Funk-Schlüssels aufzeichnen und
>> wiedergeben.
>
> Replay-Attacks funktionieren seit 20 Jahren nicht mehr bei
> Autoschlüsseln und bei allen anderen Arten von Crypto-Funkschaltern.

Komisch, dass die Mediatheken voll davon sind, und die sind damals, vor 
20 Jahren, natürlich deswegen mit ner 16:9 Arri aufgenommen worden, als 
noch niemand an HD dachte, damit es heute authentisch wirkt... ^^

So viele kluge Sachen du manchmal schreibst, MaWin, manchmal schießt du 
deiner Glaubwürdigkeit selbst ins Knie ;-)

von Carsten P. (r2pi)


Lesenswert?

Nop schrieb:
> 3) C ist relativ einfach.

Definiere "relativ" ^^

Wir wissen alle, dass das totaler Quatsch ist. Aus Sicht eines BWLers 
vielleicht. Aber technisch gesehen ist blankes "C" genauso "einfach" wie 
Assembler.

Wenn du schonmal ernsthafte (das heißt kommerziell in großen Stückzahlen 
verwendete und sicherheitstechnisch relevante) Software entwickelt als 
mit einem Nicht-Coder als Vorgesetztem, Kunden oder whatnot, weißt du, 
wie schnell aus der mal eben hin geschnodderten "Machbarkeitsstudie" ein 
Denkmal wird, das nicht mehr gemeißelt, sondern nur noch angemalt wird.

Ich jedenfalls erinnere mich sehr gut daran, dass ich vor uff... knapp 
30 Jahren? meinem damaligen Chef zeigte, wie man von nem PERL-Script im 
Sekunden-Takt Texte an nen Webbrowser (der hieß damals noch Netscape 
Navigator) schickt, bis er verstanden hatte, dass man daraus nen Chat 
bauen könnte, und der musste dann natürlich in ner Woche fertig sein. 
Sowas wie ne Anmeldung (ohne E-Mail-Prüfung, keine Zeit) hab ich dann 
nach Feierabend dazu gecodet. Das Ding ist weit gewachsen, aber an echte 
Sicherheit, also echte Authentifizierung hat damals keine Sau gedacht. 
Und die Fehler in dem hin gerotzten Code wurden natürlich gnadenlos 
aufgedeckt. Aber selbst dann fand mein Chef, nö, das tut's, das bringt 
Geld, keine Zeit, weiter zum nächsten Projekt.

Heute sind manche Chefs anders und sensibler für solche Themen. Aber 
eben nicht alle, und genau da entstehen die @MaWin "irgendwelchen 
Scheunentore".

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> Der dritte Punkt ist insofern relevant, als daß das eigentliche Coding
> oftmals nur ein kleiner Teil der Arbeit ist, für den man nicht extra
> einen Coding-Spezialisten einstellen würde, den man aber für eine
> komplizierte Sprache bräuchte.

Das ist richtig. Jedoch ist das Debugging in C relativ kompliziert.
Rust dreht das herum. Das Coden ist etwas schwieriger. Dafür ist das 
Debugging aber deutlich einfacher und beschränkt sich nur noch auf 
logische Fehler.

It works, if it compiles. Das ist zwar natürlich etwas überspitzt 
ausgedrückt, aber es steckt doch ein großer Teil Wahrheit drin.
Deshalb macht außerdem auch deutlich mehr Spaß.

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


Lesenswert?

Olaf schrieb:
> Und noch erstaunlicher, C ist da mittlerweile seit 20Jahren dominant. Da
> kam noch nie jemand der Gedanke das man was anderes verwenden koennte.

Davor wurden Controller halt vorrangig in Assembler programmiert. C war 
da schon mal eine mächtige Verbesserung, weil man mit vergleichsweise 
geringen Einbußen an Laufzeiteffizienz eine drastische Verbesserung der 
Coding-Effizienz erzielen kann und (auch wenn hier alle über C 
dahingehend unken) ganz gewiss auch eine drastische Verbesserung der 
Sicherheit. Wer sich (durchaus zu Recht) über die Sicherheitslücken 
beklagt, die mit C möglich sind, der sollte sich einfach mal 
vergegenwärtigen, wie das alles mit Assemblercode aussähe. ;-)

Nun wiederum, einen einmal etablierten Platzhirsch zu vertreiben, ist 
keine so leichte Aufgabe. So groß dürfte der Leidensdruck, C an dieser 
Stelle abzulösen, bei vielen Programmierern im Embedded-Bereich *) nicht 
sein. Gerhard hat ja viele Punkte genannt. Die Verheiratung einer 
Sprache mit einem eigenen Buildsystem dürfte einem solchen Ansinnen auch 
nicht gerade förderlich sein.

*) Ich meine hier mit "Embedded" nicht so'n Highlevel-Kram wie 
Smartphone & Co. Alles, was mit einem fetten Betriebssystem daher kommt, 
ist in dieser Hinsicht ja eher PC-mäßig. Ich meine den wirklichen 
Lowlevel-Kram, der bis vor 30 Jahren komplett in Assembler war (8051 
waren die ersten, bei denen dann jemand mit Compilern angetreten war).

von Nop (Gast)


Lesenswert?

MaWin schrieb:

> Das ist richtig. Jedoch ist das Debugging in C relativ kompliziert.

Kann ich nicht bestätigen. Zumal man embedded sowieso noch nen 
MISRA-Checker drüberlaufen läßt, womit etliche Konstrukte angemeckert 
werden, die gerne verkehrt gemacht werden.

Da man embedded auch etliche Sachen meistens schlichtweg nicht benutzt, 
wie z.B. dynamische Speicherallozierung, sind die damit einhergehenden 
Fehler natürlich auch ausgeschlossen.

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> Kann ich nicht bestätigen.

Hast du schon einmal Rust probiert um einen Vergleich zu bekommen?

> Zumal man embedded sowieso noch nen
> MISRA-Checker drüberlaufen läßt, womit etliche Konstrukte angemeckert
> werden, die gerne verkehrt gemacht werden.

Und jetzt stelle dir Rust wie einen Misra-Checker auf Steroiden vor. Der 
deutlich mehr Dinge prüft, weil sie erst durch die Sprache Rust prüfbar 
werden. Der dir auch noch Vorschläge macht, wie du die Warnungen und 
Fehler beheben kannst.
Meistens stimmen die Vorschläge auch, oder sie lenken einen wenigstens 
eindeutig auf die richtige Lösung hin.

> dynamische Speicherallozierung, sind die damit einhergehenden
> Fehler natürlich auch ausgeschlossen.

Dynamische Speicherverwaltung ist nur ein winziger Teil der Dinge, die 
Rust deutlich besser beherrscht als C (und auch besser als C++. 
Double-Free/Use-after-free ist in Rust nicht möglich).
Außerdem gelten die Rust Speicherkonzepte auch für statische Allokation 
und Stackallokation.

von Oliver S. (oliverso)


Lesenswert?

Carsten P. schrieb:
>> Replay-Attacks funktionieren seit 20 Jahren nicht mehr bei
>> Autoschlüsseln und bei allen anderen Arten von Crypto-Funkschaltern.
>
> Komisch, dass die Mediatheken voll davon sind,

Bei Crypto-Funkschaltern mag das so sein. Der Angriff auf Autos 
funktioniert ganz anders. Und weil das tatsächlich seit Jahren duch alle 
Mediakanäle getrieben wurde, sollte das jeder problemlos auseinander 
halten können.

Oliver

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Die Verheiratung einer Sprache mit einem eigenen Buildsystem

Das ist, wie mehrfach schon gesagt, nicht wahr.
Du kannst Rust ohne weiteres und insbesondere im Embedded-Bereich auch 
mit Make oder jedem anderen Tool verwenden.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Double-Free/Use-after-free ist in Rust nicht möglich).

Solche checks sind ja toll. Genauso wie das Prüfen von Arraygrenzen. Das 
benötigt aber Code zur Laufzeit. Den kann auch Rust nicht wegzaubern. 
D.h. da läuft dann ständig irgendwelcher Code für JEDEN Arrayzugriff und 
es müssen ständig Datenstrukturen im Speicher mitgeführt werden, um 
solche Dinge abfangen zu können.

In der System- und Embedded-Entwicklung will und kann man das aber 
meistens nicht.

: Bearbeitet durch User
von Nop (Gast)


Lesenswert?

MaWin schrieb:

> Hast du schon einmal Rust probiert um einen Vergleich zu bekommen?

Ich habe keine speziellen Debugging-Probleme in C festgestellt, die 
überhaupt einer Lösung bedürften. Wenn, dann klemmt es algorithmisch, 
aber das wäre in jeder programmiersprache so.

> Und jetzt stelle dir Rust wie einen Misra-Checker auf Steroiden vor.

Schön, aber der Leidensdruck ist schlichtweg nicht da. Wozu eine 
deutlich kompliziertere Sprache, wenn es das angebliche Horrordebugging 
in C tatsächlich nicht gibt?

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
>> Double-Free/Use-after-free ist in Rust nicht möglich).
> Solche checks sind ja toll. Genauso wie das Prüfen von Arraygrenzen. Das
> benötigt aber Code zur Laufzeit.

Nein, benötigt es nicht.
Das prüfen von Allokationen passiert komplett zur Compilezeit und das 
Prüfen von Arraygrenzen auch zu einem sehr großen Teil.

> D.h. da läuft dann ständig irgendwelcher Code für JEDEN Arrayzugriff

Nein.
Wenn der Array-Index nicht beliebig sein kann, dann wird das zur 
Compilezeit aufgelöst.

Außerdem braucht man in Rust deutlich seltener Arrays, als in C.
Mit Rust-Enums zum Beispiel kann man viele Dinge tun, die man in C mit 
C-Enums und Arrays machen würde.

> und es müssen ständig Datenstrukturen im Speicher mitgeführt werden

Ständig nicht. Aber teilweise natürlich schon. Ein Slice ist zum 
Beispiel ein Zeiger und eine Länge.
Aber das ist in C auch nicht anders. An den Stellen, wo du in Rust ein 
Slice verwendest, würdest du in C einen Pointer und ein Längen-Integer 
manuell mitschleppen.

Rust hat hier praktisch keinen Laufzeitnachteil gegenüber C.

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> Schön, aber der Leidensdruck ist schlichtweg nicht da. Wozu eine
> deutlich kompliziertere Sprache, wenn es das angebliche Horrordebugging
> in C tatsächlich nicht gibt?

Ja, dann ist doch alles gut.
Niemand zwingt dich.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:

> Nein, benötigt es nicht.
> Das prüfen von Allokationen passiert komplett zur Compilezeit und das
> Prüfen von Arraygrenzen auch zu einem sehr großen Teil.

Ahso alles zur Compilezeit. Also wenn es dynamische Allokation gibt, 
dann muss man auch Grenzen zur Laufzeit prüfen.

> Wenn der Array-Index nicht beliebig sein kann, dann wird das zur
> Compilezeit aufgelöst.

Und wenn deine Tante Eier hätte wäre sie dein Onkel. Der konkrete Index 
kann jederzeit von einer Eingabe zur Laufzeit abhängen.

> Rust hat hier praktisch keinen Laufzeitnachteil gegenüber C.

Jaja bla blubb. Erzähls deinen Hipster-Freunden.

Es gibt nur zwei Möglichkeiten: Entweder du kannst relativ ungestört 
direkt in den Speicher reingreifen oder jeder Fetzen Speicher ist 
abgesichert, was aber Datenstrukturen und Code braucht, der Checks 
ausführt.
Das kann man nicht wegdiskutieren.

: Bearbeitet durch User
von Nop (Gast)


Lesenswert?

Cyblord -. schrieb:

> Und wenn deine Tante Eier hätte wäre sie dein Onkel. Der konkrete Index
> kann jederzeit von einer Eingabe zur Laufzeit abhängen.

Praktisches Beispiel: eine for-Schleife über alle Deine 
Temperatursensoren, deren Werte in einem Array stecken. Da kann der 
Compiler durchaus statisch ermitteln, ob das Array mit ausreichender 
Größe deklariert ist.

von Cyblord -. (cyblord)


Lesenswert?

Nop schrieb:
> Cyblord -. schrieb:
>
>> Und wenn deine Tante Eier hätte wäre sie dein Onkel. Der konkrete Index
>> kann jederzeit von einer Eingabe zur Laufzeit abhängen.
>
> Praktisches Beispiel: eine for-Schleife über alle Deine
> Temperatursensoren, deren Werte in einem Array stecken. Da kann der
> Compiler durchaus statisch ermitteln, ob das Array mit ausreichender
> Größe deklariert ist.

Das kann jedes PCLINT finden. Was bringt ein statisches Beispiel? Ein 
einziges dynamisches Beispiel und du brauchst den Check zur Laufzeit.

Deshalb ist diese Sicherheit eben kein Verdienst von Rust, sondern muss 
in jedem Fall erkauft werden. Die Sprachdefinition und die möglichen 
Checks zur Compilezeit sind Kindergarten. Statische Codeanalyse wurde 
schon vor ner Weile erfunden.

: Bearbeitet durch User
von Nop (Gast)


Lesenswert?

Cyblord -. schrieb:

> Das kann jedes PCLINT finden.

Aber nicht, wenn Du das Array als Parameter einer Funktion übergibst, 
womöglich noch in einer anderen TU, weil es in C dann zu einem Pointer 
ohne Längeninformation verflacht.

von Cyblord -. (cyblord)


Lesenswert?

Nop schrieb:
> Cyblord -. schrieb:
>
>> Das kann jedes PCLINT finden.
>
> Aber nicht, wenn Du das Array als Parameter einer Funktion übergibst,

Doch ganz sicher.

> womöglich noch in einer anderen TU, weil es in C dann zu einem Pointer
> ohne Längeninformation verflacht.


Ja und wie sieht dein statischer Check aus, wenn ich einen Index über 
UART empfange?

von Nop (Gast)


Lesenswert?

Wobei es natürlich bessere statische Code-Checker für C gibt, die auch 
interprozedurale Analyse können - aber PC-Lint speziell kann es halt 
nicht.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Also wenn es dynamische Allokation gibt,
> dann muss man auch Grenzen zur Laufzeit prüfen.

Ja. Genau wie in C.

> Der konkrete Index
> kann jederzeit von einer Eingabe zur Laufzeit abhängen.

In dem Fall musst du das in C auch prüfen.

> Das kann man nicht wegdiskutieren.

Ja, doch.
Rust ist halt sehr viel ausdrucksreicher als C. Die Enums habe ich ja 
bereits genannt. Die sind halt zur Compilezeit komplett prüfbar. Man 
kann in Rust halt Dinge ausdrücken, die in C gar nicht möglich sind.

Und wenn es dann wirklich diese eine Stelle gibt, die sooooooooooo 
performancekritisch ist und es dort auch gar nicht möglich ist das in 
Rust zu formulieren ohne Performanceoverhead, dann hat man immer noch 
die Möglichkeit von Unsafe-Rust. Da kannst du dich nach Herzenslust mit 
ungeprüfter C-Pointerarithmetik austoben.
Aber es kommt praktisch nicht vor, dass das notwendig ist, weil man 
eigentlich alles in Rust performant ausdrücken kann.
Performance ist ein Designziel von Rust!

> Jaja bla blubb. Erzähls deinen Hipster-Freunden.

Mit dem Argument hast du mich jetzt natürlich überzeugt ;)

von Cyblord -. (cyblord)


Lesenswert?

Nop schrieb:
> Wobei es natürlich bessere statische Code-Checker für C gibt, die auch
> interprozedurale Analyse können - aber PC-Lint speziell kann es halt
> nicht.

Ja dann nimmst Klocwork.

Rust brauch ich dafür immer noch nicht. Und wie dynamische Indizes ohne 
zusätzlichen Code und Daten geprüft werden kannst du sicher aufzeigen.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> In dem Fall musst du das in C auch prüfen.

Nein, ich KANN. Ich muss aber nicht. Vor allem wird kein Zwangsweise 
Code erzeugt der das prüft.

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> Praktisches Beispiel: eine for-Schleife über alle Deine
> Temperatursensoren, deren Werte in einem Array stecken. Da kann der
> Compiler durchaus statisch ermitteln, ob das Array mit ausreichender
> Größe deklariert ist.

Ja, sogar in C geht das meistens.
In Rust geht es aber öfter, weil Arrays vernünftig typisiert sind und 
nicht so ein Unfug mit Array-Pointer-Decay gemacht wird.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Ja und wie sieht dein statischer Check aus, wenn ich einen Index über
> UART empfange?

Es gibt ihn nicht. Genauso wenig, wie es ihn in C gibt.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> In Rust geht es aber öfter, weil Arrays vernünftig typisiert sind und
> nicht so ein Unfug mit Array-Pointer-Decay gemacht wird.

Dann kann Rust wohl keine Objekte/Strukturen serialisieren? Oder wie 
wandle ich sowas in ein Byte-Array um es z.B. über einen UART zu senden? 
Kann Rust beim Deserialisieren (Empfang über UART) prüfen ob das Objekt 
den korrekten Typ hat?
Und das auch noch ohne zusätzlichen Speicher?

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Nein, ich KANN. Ich muss aber nicht.

Ja, genau. Das ist ja das Problem.

> Vor allem wird kein Zwangsweise Code erzeugt der das prüft.

In Unsafe-Rust kannst du auch ungeprüfte Zugriffe verwenden, wenn du 
unbedingt scharf auf Sicherheitslücken bist.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Dann kann Rust wohl keine Objekte/Strukturen serialisieren?

Wie kommst du jetzt darauf?

https://crates.io/crates/serde

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
> In Unsafe-Rust kannst du auch ungeprüfte Zugriffe verwenden, wenn du
> unbedingt scharf auf Sicherheitslücken bist.

Tja in C will man eben relativ viel Freiheit mit einigermaßen 
ordentlichen Datentypen, Strukturen und Kontrollmechanismen.

Wer das nicht will, nimmt C#, Java oder halt Rust.
Nur kommen diese ganzen Checks eben nicht ohne Code und Daten zur 
Laufzeit aus. Darum geht es mir. Es ist nicht die tolle Sprache die 
irgendwas sicher macht, sondern die Unmengen an automatisch erzeugtem 
Code.
Deshalb wird es C nicht ablösen. Weil man genau deshalb C verwendet um 
das nicht zu haben.
Es gab schon genug Versuche mit Java auf Embedded. Und viele ähnliche 
Scherze. Am Ende ist das alles nur viel aufgeblasener Code um ein paar 
Zeilen produktiv Code in einem sicheren Setting zu schreiben.

von Nop (Gast)


Lesenswert?

Cyblord -. schrieb:

> Es gab schon genug Versuche mit Java auf Embedded.

Das Problem dabei war doch wohl vielmehr der GC, und den hat Rust nicht. 
Das Problem von Rust ist IMO eher, daß es zu kompliziert ist - und wenn 
die Leute, die embedded C verwenden, bislang eine kompliziertere Sprache 
gewollt hätten, dann hätten sie schon längst auf C++ umgestellt. 
Insofern ist Rust eher ein potentieller Ersatz für C++, nicht für C.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
>> Dann kann Rust wohl keine Objekte/Strukturen serialisieren?
>
> Wie kommst du jetzt darauf?
>
> https://crates.io/crates/serde

Natürlich bietet Rust diese Funktionalität, aber der Punkt ist, wenn du 
ein Objekt in einen Bytestrom verwandelst, dann hast du auch keine 
Sicherheit mehr. Außer du baust mit zusätzlichen Daten wieder was drum 
rum.
Nichts anderes passiert in C wenn man direkt in den Speicher einer 
Struktur oder eines Arrays reingreift. Und manchmal muss man das eben, 
z.B. mit angesprochenen Fall um das über UART zu senden.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Nur kommen diese ganzen Checks eben nicht ohne Code und Daten zur
> Laufzeit aus. Darum geht es mir.

Ja. Darum geht es dir.

Es ist aber falsch.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Nichts anderes passiert in C

Schön, dass du es doch noch eingesehen hast.
Rust ist in diesem Aspekt nicht langsamer als C.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
> Cyblord -. schrieb:
>> Nur kommen diese ganzen Checks eben nicht ohne Code und Daten zur
>> Laufzeit aus. Darum geht es mir.
>
> Ja. Darum geht es dir.
>
> Es ist aber falsch.

Dann zeig auf, wie ein dynamischer Index ohne Laufzeit und Daten von 
Rust geprüft wird.

Minimalbeispiel:
1
int a[100];
2
int x=receiveUART();
3
int d=a[x];

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
> Rust ist in diesem Aspekt nicht langsamer als C.

Dann kann Rust in diesem Aspekt auch nicht sicherer sein.
Laufzeitchecks gibt es nicht umsonst. Kann es nicht geben.

: Bearbeitet durch User
von DPA (Gast)


Lesenswert?

Wenn du z.B. ein Array a[n] und eins b[m] hast, und dann eins c[n+m], 
musst du nicht wissen, was n und m sind, um zu wissen, dass c[0:n] und 
c[n:m] darin liegen.
Wenn du das für c[i] wissen willst, und du weist nichts über i (z.B. 
user gibt es ein) muss gecheckt werden ob es platz hat. Aber das muss 
man dann auch in c. Man braucht nur genug Metadaten beim Kompilieren.

von Carsten P. (r2pi)


Lesenswert?

Cyblord -. schrieb:
> In der System- und Embedded-Entwicklung will und kann man das aber
> meistens nicht.

Ich lese mich ja gerade in Rust ein wenig ein, weil ich mir die Zeit 
dafür nehme. Erstens ist es natürlich mit nem (verschmerzenswerten) 
Overhead (das meiste passiert zur Compile-Zeit) verbunden, aber meine 
Antwort auf deine Aussage lautet unabhängig von der Programmiersprache:

Wer das nicht WILL, wird irgendwann (sehr bald) den Bach runter gehen. 
Embedded ist nicht Zuse in der Neuzeit. Die Anforderungen gerade im 
Embedded-Bereich sind Sicherheit, Sicherheit, und bevor ich es vergesse: 
Sicherheit!

Es liegt natürlich an deinem Naturelle, ob du damit leben kannst, dass 
dein Auftraggeber nach ein paar Toten und Schwerverletzten wegen einer 
falschen Programmierung von Airbags zigtausend Autos in die Werkstatt 
zurück rufen musst. Wenn du schlau warst, hast du jede Haftung 
ausgeschlossen im Vertrag...

Wessen Maxime in diesem Bereich nur billig, billig! uuuund billig! ist, 
wird sich eher früher als später wundern, wenn er mit Klagen überrissen 
wird.

Diese "ich weiß schon, was ich mache"-Attitüde ist einfach Mist. Ein 
Embedded-Coder hier, der seinen kompletten Code mit Unit-Tests 
überzieht? Test-driven? Clean Code anyone? Im Ernst, wenn die Produkte 
weiter nur auf billig, billig gebaut werden, darf sich niemand wundern, 
wenn die genauso miesen, aber nur halb so teuren Sachen aus China den 
Markt dumpen.

von Carsten P. (r2pi)


Lesenswert?

Cyblord -. schrieb:
> Minimalbeispiel:
>
>
1
> int a[100];
2
> int x=receiveUART();
3
> int d=a[x];
4
>

Du prüfst also nicht, ob x > 100 ist? Oh, wow, ich hoffe, du 
programmierst keine Airbags... Achso, es ging um Rust. Jepp, das kriegt 
Rust hin, zur Übersetzungszeit bereits, weil es den Rückgabewert von 
receiveUART() prüft und dann feststellt, ob er die Array-Grenze 
überschreiten kann.

Das könnte ein entsprechender "C"-Compiler aber auch, so ne 
Schlampigkeit feststellen ^^

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

Carsten P. schrieb:

> Du prüfst also nicht, ob x > 100 ist?

Es ging ja darum dass Rust dies anscheinend ohne Overhead automatisch 
prüft.

> Achso, es ging um Rust. Jepp, das kriegt
> Rust hin, zur Übersetzungszeit bereits, weil es den Rückgabewert von
> receiveUART() prüft und dann feststellt, ob er die Array-Grenze
> überschreiten kann.

Erstaunlich. Es kann in die Zukunft sehen welcher Wert über den UART 
reinkommt?

von Oliver S. (oliverso)


Lesenswert?

Carsten P. schrieb:
> Es liegt natürlich an deinem Naturelle, ob du damit leben kannst, dass
> dein Auftraggeber nach ein paar Toten und Schwerverletzten wegen einer
> falschen Programmierung von Airbags zigtausend Autos in die Werkstatt
> zurück rufen musst. Wenn du schlau warst, hast du jede Haftung
> ausgeschlossen im Vertrag...

Nur mal nebenbei gefragt, da es Airbags ja nun doch schon eine ganze 
Weile gibt: wie oft ist das denn bisher weltweit mal vorgekommen?

Oliver

von Cyblord -. (cyblord)


Lesenswert?

Oliver S. schrieb:
> Nur mal nebenbei gefragt, da es Airbags ja nun doch schon eine ganze
> Weile gibt: wie oft ist das denn bisher weltweit mal vorgekommen?

Die sind wohl alle in Rust programmiert ;-)

von Nop (Gast)


Lesenswert?

Oliver S. schrieb:

> Nur mal nebenbei gefragt, da es Airbags ja nun doch schon eine ganze
> Weile gibt: wie oft ist das denn bisher weltweit mal vorgekommen?

Speziell bei Airbags nun nicht, aber das Beispiel des Toyota Camry ist 
ja bekannt, und da gab es Tote. Das lag allerdings nicht an einem 
C-Fehler, sondern an unzureichender Stackanalyse, und zu allem Überfluß 
hat man den Stack auch noch nach unten hin auf die globalen Daten (oder 
den Heap) zuwachsen lassen. Das könnte wohl auch in Rust passieren, weil 
der Rust-Compiler sich auf eine korrekte Umgebung genauso verläßt wie 
ein C-Compiler.

Das jünste Beispiel mit den Boeing-Abstürzen wiederum war auch kein 
C-Fehler, sondern ein Fehler im Systemdesign. Der Maximalausschlag des 
Höhenruders wurde nachträglich deutlich vergrößert, und dann hätte man 
das System nicht mehr mit nur einem Sensor betreiben dürfen. Hat man 
aber, obwohl man sogar physikalisch zwei Sensoren hatte, weil man den 
dann erhöhten Zertifizierungsaufwand einsaparen wollte.

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


Lesenswert?

Cyblord -. schrieb:
> Es ging ja darum dass Rust dies anscheinend ohne Overhead automatisch
> prüft.

Naja: es prüft mit einem vergleichbaren Overhead. Wenn der Test statisch 
machbar ist, hast du ihn zur Compilezeit, keine Frage. Lässt er sich nur 
zur Laufzeit ausführen, dann müsstest du ihn für ein sicheres C- (oder 
Assembler-)Programm dort ebenfalls zur Laufzeit durchführen, daher 
sollte der Overhead vergleichbar sein.

von Carsten P. (r2pi)


Lesenswert?

Cyblord -. schrieb:
> Carsten P. schrieb:
>
>> Du prüfst also nicht, ob x > 100 ist?
>
> Es ging ja darum dass Rust dies anscheinend ohne Overhead automatisch
> prüft.
>
>> Achso, es ging um Rust. Jepp, das kriegt
>> Rust hin, zur Übersetzungszeit bereits, weil es den Rückgabewert von
>> receiveUART() prüft und dann feststellt, ob er die Array-Grenze
>> überschreiten kann.
>
> Erstaunlich. Es kann in die Zukunft sehen welcher Wert über den UART
> reinkommt?

Ja, natürlich. Der Index von a ist maximal 99. Wenn receiveUART() ein 
uint8 zurückgibt, ist der größte Wert dort 255, also größer als 99.

Das ist doch kein Hexenwerk...

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
>> Rust ist in diesem Aspekt nicht langsamer als C.
>
> Dann kann Rust in diesem Aspekt auch nicht sicherer sein.
> Laufzeitchecks gibt es nicht umsonst. Kann es nicht geben.

Ja, Ok. Ich habs verstanden. Du willst ganz offensichtlich nur 
provozieren und stellst dich bewusst dumm.
Ich beende das Spiel an dieser Stelle.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> und zu allem Überfluß
> hat man den Stack auch noch nach unten hin auf die globalen Daten (oder
> den Heap) zuwachsen lassen. Das könnte wohl auch in Rust passieren,

Nein, kann es natürlich nicht.
Rust ist memory-safe. Das gilt selbstverständlich auch für den Stack.

Jörg W. schrieb:
> Naja: es prüft mit einem vergleichbaren Overhead. Wenn der Test statisch
> machbar ist, hast du ihn zur Compilezeit, keine Frage.

Wenigstens einer, der es verstanden hat. Ist aber auch gar nicht so 
schwer eigentlich :)

Beitrag #6930470 wurde von einem Moderator gelöscht.
von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Rust ist memory-safe. Das gilt selbstverständlich auch für den Stack.

Echt? Der Compiler weiß beim Übersetzen, daß der Stack auf dem Target zu 
klein ist? Glaube ich nicht.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Echt? Der Compiler weiß beim Übersetzen, daß der Stack auf dem Target zu
> klein ist?

Das hat niemand behauptet.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Das hat niemand behauptet.

Doch, hast Du gerade. Alternativ, was wahrscheinlicher ist, hast Du das 
von mir beschriebene Problem nicht verstanden.

von Carsten P. (r2pi)


Lesenswert?

Nop schrieb:
> Echt? Der Compiler weiß beim Übersetzen, daß der Stack auf dem Target zu
> klein ist? Glaube ich nicht.

Wissen tue ich es auch nicht, aber was hält den Compiler, auch bei 
genügend präzise angegebenen Targets als Cross-Compiler, davon ab, das 
zur Übersetzung zu wissen, wie groß der Stack werden darf? Wir reden 
hier von Embedded, ich jedenfalls, nicht von virtualisierten Maschinen 
auf virtualisierenden Servern.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Doch, hast Du gerade.

Bitte? Du weißt schon, dass man in einem Forum alles nachlesen kann und 
somit beweisen kann, dass ich es nicht behauptet habe?

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:
> Nop schrieb:
>> Doch, hast Du gerade.
>
> Bitte? Du weißt schon, dass man in einem Forum alles nachlesen kann und
> somit beweisen kann, dass ich es nicht behauptet habe?

Hast Du, und zwar hier:

MaWin O. schrieb:
> Nein, kann es natürlich nicht.
> Rust ist memory-safe. Das gilt selbstverständlich auch für den Stack.

Du hast dabei nicht berücksichtigt, daß ein Stacküberlauf gar nicht im 
Fokus des Compilers sein kann, weil der Compiler nichts von der 
Stackdimensionierung weiß. Das wird erst beim Linken klar, und dann 
reden wir über LLVM, nicht mehr von Rust.

Der Rust-Compiler verläßt sich genauso wie ein C-Compiler darauf, daß 
das Environment so funktioniert, wie es das sollte.

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


Lesenswert?

Carsten P. schrieb:
> aber was hält den Compiler, auch bei genügend präzise angegebenen
> Targets als Cross-Compiler, davon ab, das zur Übersetzung zu wissen, wie
> groß der Stack werden darf?

Einerseits call trees, die von äußeren Einflüssen (beispielsweise 
Eingabegrößen) abhängen, andererseits natürlich Rekursionen. Bei 
Rekursionen kann er bestenfalls eine worst-case-Annahme treffen (wenn 
beispielsweise durch den Datentyp, der die Rekursion steuert, eine 
maximale Rekursionstiefe ermittelbar ist), aber die kann natürlich 
meilenweit über im praktischen Betrieb auftretenden realen Anforderungen 
dann liegen. Dann ist es zwar sicher, aber u.U. derart überalloziert, 
dass es auf der realen Maschine nicht mehr nutzbar ist, weil sie gar 
nicht so viel Speicher für den Stack bereitstellen kann.

Für eine virtual-memory-Architektur spielt das nicht so'ne große Geige 
(der Stack ist ja dann nur VM, und wenn der real nicht ausgenutzt wird, 
muss er nicht durch realen Speicher abgedeckt werden), aber auf einem 
kleinen Controller kann das ein Problem werden.

Sowas kann auch keine Sprache in sich absichern, wenn man derartige 
Probleme hat. Man kann dann höchstens Monte-Carlo-Simulationen 
durchspielen, die für typische Szenarien ermitteln, wieviel STack 
tatsächlich gebraucht wird. In einem realen System würde mann dann in 
irgendeiner Form eine "Notbremse" einbauen die greift, wenn sich 
herausstellt, dass der allozierte Stack doch mal nicht reicht (geht 
natürlich am einfachsten, wenn die Zielarchitektur eine MMU dafür 
anbietet).

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Der Rust-Compiler verläßt sich genauso wie ein C-Compiler darauf, daß
> das Environment so funktioniert, wie es das sollte.

Nein, das ist halt ganz einfach falsch.
Rust geht in ein Panic (und damit in ein Recovery) bei einem 
Stacküberlauf.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Rust geht in ein Panic (und damit in ein Recovery) bei einem
> Stacküberlauf.

Das tut er unter Linux, weil das Betriebssystem und die Runtime da noch 
mitspielen. Embedded und bare metal wird das so nichts werden. Abgesehen 
davon wäre das auch kaum besser, wenn mitten während der 
Fahrzeugregulierung das Programm einfach mal neu startet.

von Carsten P. (r2pi)


Lesenswert?

Jörg W. schrieb:
> Einerseits call trees, die von äußeren Einflüssen (beispielsweise
> Eingabegrößen) abhängen, andererseits natürlich Rekursionen.

Japp. Korrekt. Anders als andere (einer) hier, behaupte ich auch nicht, 
dass sowas nicht möglich ist. Ich sage nur, dass ein gut geschneiderter 
Compiler sehr viel davon verhindern kann. Natürlich kannst du jede 
Laufzeit und jeden Compiler mit böser Absicht oder (wie du sagtest, 
Eingaben) genügend hilflosen Anwendern (Coder, die deinen Code linken, 
sind auch Anwender) in die Knie zwingen.

Da fehlt aber gerade in der Hardware noch eine Menge Hirnschmalz, gerade 
bei kleinen uCs, also dass sie Threads von sich aus ausknipsen, wenn sie 
gewisse Stack-Grenzen überschreiten.

Außer manchen (einem) behauptet ja aber auch niemand, dass Rust die 
einzige und perfekte Sprache/Laufzeit ist. Rust setzt an typischen 
Fehlerquellen an, wo ein Compiler bereits rein grätschen kann, und das 
ist, finde ich, ein sehr guter Ansatz. Natürlich wäre es süß, wenn auch 
ein AtTiny ne VM Umgebung herstellen könnte, aber dann würde er nicht 30 
Cent, sondern 5 Euro mindestens kosten. So dumm ich das Argument selber 
finde, so sehr zieht es doch einerseits durch den Kostendruck aus 
anderen Regionen dieser Welt ALS AUCH vom Gerede mancher Entwickler, 
dass das alles kein Problem sei.

von Oliver S. (oliverso)


Lesenswert?

Nop schrieb:
> das Beispiel des Toyota Camry ist
> ja bekannt, und da gab es Tote. Das lag allerdings nicht an einem
> C-Fehler, sondern an unzureichender Stackanalyse, und zu allem Überfluß
> hat man den Stack auch noch nach unten hin auf die globalen Daten (oder
> den Heap) zuwachsen lassen.

Hm. Du hast doch dafür sicherlich eine Quelle. Meines Wissens nach ist 
die ganze Sache dort sehr viel komplexer gewesen, und ist bis heute 
nicht abschließend geklärt.

> Das jünste Beispiel mit den Boeing-Abstürzen wiederum war auch kein
> C-Fehler, sondern ein Fehler im Systemdesign.

So war das wohl.

Rust mag ja einige haarsträubende Ecken von C(++) umschiffen, aber die 
Fehler, die in diesen realen Projekten gemacht wurden, hätte das auch 
nicht verhindert.

Oliver

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Das tut er unter Linux, weil das Betriebssystem und die Runtime da noch
> mitspielen. Embedded und bare metal wird das so nichts werden.

Weil du das sagst?
Warum genau soll Rust nicht prüfen können, ob der Stack überläuft?

> Abgesehen
> davon wäre das auch kaum besser, wenn mitten während der
> Fahrzeugregulierung das Programm einfach mal neu startet.

Ja doch. Ein Neustart ist 1000 mal besser, als UB durch 
Memory-Corruption.
Neustarts von Steuergeräten während der Fahrt passieren "ständig" (d.h. 
öfter als du denkst).

von Nop (Gast)


Lesenswert?

Oliver S. schrieb:

> Hm. Du hast doch dafür sicherlich eine Quelle.

Die Google-Stichworte lauten wenig überraschend:
toyota camry stack overflow
Da findest Du jede Menge dazu. Es war jedenfalls eine der Ursachen.

> Rust mag ja einige haarsträubende Ecken von C(++) umschiffen, aber die
> Fehler, die in diesen realen Projekten gemacht wurden, hätte das auch
> nicht verhindert.

Richtig. Das kann man Rust natürlich nicht ankreiden, aber es sind halt 
mal zwei Beispiele mit Toten, wo "wir machen alles in Rust" nichts 
geholfen hätte. Insofern sollte man da auch nicht übermütig werden.

Wenn ich hier dann im Kontext von embedded-Entwicklung lese, Rust habe 
keine potentiellen Stackprobleme (haben auch C-Programme übrigens unter 
Linux nicht - die werden auch beendet), sieht das schon stark nach 
Risiko-Kompensation aus, was wiederum ein Risiko darstellt.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Warum genau soll Rust nicht prüfen können, ob der Stack überläuft?

Weil Rust explizit auf Geschwindigkeit und "kein Runtime-Overhead" 
entwickelt wurde, und bei jedem Dekrementieren des Stackpointers vorher 
einen Runtime-Check zu machen wäre ein erheblicher Runtime-Overhead. Die 
Speichersicherheit bezieht sich auf die Anwendung und nicht darauf, daß 
das Environment außerhalb des Rust-Programms ein Problem hat.

Das, was Du als Beispiel brachtest, wird vom OS bereitgestellt, was das 
Programm dann abbricht. Es geht hier aber um embedded und bare metal, 
nicht um Linuxanwendungen.

> Ja doch. Ein Neustart ist 1000 mal besser

Bei nennenswertem Tempo mit aktiver ASR wäre ein Neustart ebenso fatal.

von MaWin O. (mawin_original)


Lesenswert?

https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=6ba3452d2c1eeb9b3c9c3f3fa236b77a

> thread 'main' has overflowed its stack
> fatal runtime error: stack overflow

Komisch, gell?
Wo Rust das doch angeblich gar nicht erkennen kann?

von Nop (Gast)


Lesenswert?

Ach ja, abgesehen davon weiß der Rust-Compiler gar nicht, wie groß der 
Stack überhaupt ist. Unter Linux ist das Sache des Betriebssystems, und 
bare metal wird das erst beim Linken klar - und dann reden wir über 
LLVM, lange nach dem Rust-Compiler.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Weil Rust explizit auf Geschwindigkeit und "kein Runtime-Overhead"
> entwickelt wurde, und bei jedem Dekrementieren des Stackpointers vorher
> einen Runtime-Check zu machen wäre ein erheblicher Runtime-Overhead.

Nein, wäre es nicht.
Das wäre eine einzige Abfrage pro Funktion. Im Mittel deutlich weniger.

> Die Speichersicherheit bezieht sich auf die Anwendung

Ja eben. Die Anwendung macht die Allokation.
Könnte die Anwendung durch Speicherallokation UB hervorrufen, wäre das 
"unsound". Unsoundness und UB gibt es in Rust nicht.

> Das, was Du als Beispiel brachtest, wird vom OS bereitgestellt,

Nein.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Ja eben. Die Anwendung macht die Allokation.

Denk mal drüber nach, wieso das überhaupt ein Runtime-Fehler ist und 
nicht ein Compiletime-Fehler, obwohl die Stack-Allokation in Deinem 
Beispiel ja offensichtlich statisch ist.

Das kommt daher, daß man über Guardpages geht, was auf Kernel-Level ein 
Segfault ist - blöd halt, wenn man gar keine Pages (und auch keinen 
Kernel) hat, weil wir hier über embedded-Controller reden.

von Nop (Gast)


Lesenswert?

Aus demselben Grund wird übrigens ein C-Programm mit Stackoverflow unter 
Linux ebenfalls problemlos beendet.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Denk mal drüber nach, wieso das überhaupt ein Runtime-Fehler ist und
> nicht ein Compiletime-Fehler, obwohl die Stack-Allokation in Deinem
> Beispiel ja offensichtlich statisch ist.

Ich habe nie gesagt, dass das ein Compiletime-Fehler ist.

> Das kommt daher, daß man über Guardpages geht, was auf Kernel-Level ein
> Segfault ist - blöd halt, wenn man gar keine Pages (und auch keinen
> Kernel) hat,

Es ist völlig unerheblich, ob ein Kernel existiert oder nicht.
Die x86/x64-Implementiertung nutzt eine Guardpage. Das ist ein 
MMU-Feature.
Das heißt aber nicht, dass man zwingend einen Kernel braucht.
Und es heißt auch nicht, dass man eine MMU braucht.
Man kann auch eine Memory-Protection-Unit verwenden. Oder wenn man die 
nicht hat, kann man den Stack in einen anderen ungültigen Bereich 
wachsen lassen.

Sicher wirds auch irgendwelche Architekturen geben, die gar keine Traps 
bereitstellen für sowas. Aber selbst dort kann der Compiler 
selbstverständlich eine architekturspezifische Abrage machen.

Macht Rust das derzeit bei allen Architekturen? Nein, denn...

> weil wir hier über embedded-Controller reden.

Wir reden hier hauptsächlich über Rust.
Dass Rust derzeit noch nicht "fertig" ist für alle Embeddedsysteme 
(kleiner als Raspberry Pi), schrieb ich ja bereits.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:

> Dass Rust derzeit noch nicht "fertig" ist für alle Embeddedsysteme
> (kleiner als Raspberry Pi), schrieb ich ja bereits.

Jaja, aber wir schwadronieren schon mal vorsorglich vom Ersetzen von C 
durch Rust.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Macht Rust das derzeit bei allen Architekturen? Nein, denn...

... es ist kein Teil des Rust-Sprachstandards. Oh wait - Rust HAT ja gar 
keinen Sprach-Standard, sondern ist das, was auch immer der einzige 
Rust-Compiler gerade tut. Wodurch man übrigens nichtmal einen 
Compiler-Bug von einem Feature unterscheiden kann, denn gegen welche 
Spec sollte man das auch prüfen.

> Dass Rust derzeit noch nicht "fertig" ist für alle Embeddedsysteme
> (kleiner als Raspberry Pi), schrieb ich ja bereits.

Mit anderen Worten: Dir war klar, daß Dein Beispiel embedded gar nicht 
funktionieren würde, aber Du hast es trotzdem mal versucht - ich hätte 
es ja schlucken können, ne?

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Dir war klar, daß Dein Beispiel embedded gar nicht
> funktionieren würde, aber Du hast es trotzdem mal versucht

Ach komm...
Es wurde behauptet, dass Rust sowas grundsätzlich nicht erkennen kann.
Und das ist halt falsch.

Cyblord -. schrieb:
> Jaja, aber wir schwadronieren schon mal vorsorglich vom Ersetzen von C
> durch Rust.

Wir? Du?
Ich jedenfalls nicht. Kannst du ja gerne nachlesen.

Ich habe schon mehrfach betont, dass es mir egal ist, was ihr nutzt.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Es wurde behauptet, dass Rust sowas grundsätzlich nicht erkennen kann.
> Und das ist halt falsch.

Mit derselben Logik wäre das bei C auch kein Problem gewesen: unter 
Linux wird auch ein C-Programm bei einem Stackoverflow abgebrochen. 
Dummerweise war es aber kein Linuxsystem.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Mit derselben Logik wäre das bei C auch kein Problem gewesen

Richtig. Ich habe nicht behauptet, dass C das nicht auch kann.
Ihr wart aber diejenigen, die behauptet haben, Rust könne das nicht.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Ihr wart aber diejenigen, die behauptet haben, Rust könne das nicht.

Was Du ja dann ja auch eingestanden hast, nachdem Du erstmal den 
Unterschied zwischen bare metal und einem Linuxrechner verstanden hast.

Im Übrigen könnte man sich selbstverständlich auch einen hypothetischen 
C-Compiler denken, der vor jedem SP-Dekrement erstmal einen 
Runtime-Check macht. Hätte, hätte, Fahrradkette.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Was Du ja dann ja auch eingestanden hast

Oh bitte. Höre einfach damit auf mir Dinge in den Mund zu legen, die ich 
nie gesagt habe. Ok?
Man kann das hier alles nachlesen. Ok?
Gut.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Oh bitte. Höre einfach damit auf mir Dinge in den Mund zu legen, die ich
> nie gesagt habe. Ok?

Dann hör einfach auf, halbgaren Quatsch zu erzählen und mit unsinnigen 
Beispielen zu "belegen", die nur darauf bauen, daß andere nicht genauer 
hinsehen.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Dann hör einfach auf, halbgaren Quatsch zu erzählen

Ja, genau. Höre du bitte auf damit. Ok? Die Diskussion ging nicht von 
mir aus. Ich habe nicht die Behauptung mit dem unbehandelbaren 
Stackoverflow (a.k.a. halbgarer Quatsch) ins Spiel gebracht.

von Oliver S. (oliverso)


Lesenswert?

Nop schrieb:
> Die Google-Stichworte lauten wenig überraschend:
> toyota camry stack overflow
> Da findest Du jede Menge dazu.

Eben nicht, daher frage ich ja. Ein Stack Overflow war eine der 
denkbaren Ursachen, neben einer Zillion anderen, die aus der Komplexität 
des Systems resultieren. Immerhin war das ein zweikanaliges 
Sicherheitssystem.

Da das Verfahren aber abgeschlossen ist, wird’s dazu auch keine neuen 
Erkenntnisse geben.

Oliver

von Nop (Gast)


Lesenswert?

Oliver S. schrieb:

> Eben nicht

Du mußt die Links natürlich auch schon anklicken. ;-) Etwa diesen hier:
https://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-the-foot-with-stack-overflow/

von Olaf (Gast)


Lesenswert?

> Olaf schrieb:
> > Pearl

> Meinst du Perl?

Nein, ich meinte schon Pearl. Sonst haette es wohl kaum als Embedded 
Beispiel aus der Anfangszeit von C getaugt.

Olaf

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


Lesenswert?

Nop schrieb:
> Im Übrigen könnte man sich selbstverständlich auch einen hypothetischen
> C-Compiler denken, der vor jedem SP-Dekrement erstmal einen
> Runtime-Check macht.

Geht eigentlich nur, wenn die CPU-Architektur das hergibt (also 
letztlich durch eine MMU). Wenn man das mit Maschinenbefehlen manuell 
bewerkstelligen will, wird es nicht nur schnarchlangsam, sondern man hat 
gute Chancen, dass man schon mal irgendein Register auf den Stack pushen 
muss, um überhaupt erstmal Platz für den Test zu haben …

Dann ist es aber ganz unabhängig von der Sprache implementierbar (auch 
auf Controllern mit MMU, aber das sind halt nicht mehr die 
allerkleinsten).

Da kommt einem aber sofort wieder "Steinbach's guideline of systems 
programming" in den Sinn … die klingt zwar hart, aber wenn man auf einem 
Controller gar keinen sinnvollen Ausweg hat, weil man nur noch zwischen 
Pest (undefined behaviour) und Cholera (spontaneous reboot) wählen kann, 
dann hat man im konkreten Fall eh ein Problem.

von Nop (Gast)


Lesenswert?

Jörg W. schrieb:
> Wenn man das mit Maschinenbefehlen manuell
> bewerkstelligen will, wird es nicht nur schnarchlangsam

Ein Laden, ein Vergleich und ein bedingter Sprung pro Funktion, sofern 
der Stackframe am Funktionsanfang komplett aufgebaut wird. Der Overhead 
wäre schon deutlich.

> sondern man hat
> gute Chancen, dass man schon mal irgendein Register auf den Stack pushen
> muss, um überhaupt erstmal Platz für den Test zu haben …

Das wäre leicht abzufrühstücken, indem nicht getestet wird, ob der Stack 
überschritten sein wird, sondern eine bestimmte minimale Reserve bleibt. 
Die könnte man dann für register spill im Funktions-Prolog des nächsten 
Levels nutzen.

> aber wenn man auf einem
> Controller gar keinen sinnvollen Ausweg hat, weil man nur noch zwischen
> Pest (undefined behaviour) und Cholera (spontaneous reboot) wählen kann,
> dann hat man im konkreten Fall eh ein Problem.

Das kann man aber mit statischer Stackanalyse in den Griff kriegen. Der 
Calltree ist größenteils bekannt, dann noch Interrupts in 
worst-case-Schachtelung, und ein paar Calls, die über Funktionszeiger 
gehen können. Bei den Projektgrößen, die man auf MMU-losen Systemen so 
hat, ist das kein Problem.

Bei uns ist das in Prozeß-Checklisten als vorgeschriebener Teil jedes 
Software-Releases durchzuführen. Ohne Stackanalyse gibt's kein Release, 
auch nicht für Software ohne Sicherheitsrelevanz. Im Ernstfall wäre es 
nämlich langwierig und damit teuer, sporadischen Problemen im Feld 
nachzuspüren, und sowas würde mit dem Zeitplan laufender Projekte 
kollidieren.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> Das wäre leicht abzufrühstücken
> Das kann man aber mit statischer Stackanalyse in den Griff kriegen.

Das ist ja erstaunlich, wie schnell du von

- das geht gar nicht!
- Das kann der Compiler prinzipiell nicht, weil Linker und überhaupt ist 
das gar nicht bekannt wie groß der Stack ist!
- Rust kann das überhaupt nicht!
- Du unterstellst mir bewusste Irreführung.

dich wandelst zu:
> Das wäre leicht abzufrühstücken
> Das kann man aber mit statischer Stackanalyse in den Griff kriegen.

von Oliver S. (oliverso)


Lesenswert?

Nop schrieb:
> Oliver S. schrieb:
>
>> Eben nicht
>
> Du mußt die Links natürlich auch schon anklicken. ;-) Etwa diesen hier:
> 
https://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-the-foot-with-stack-overflow/

Habe ich. Und sogar gelesen. Die darin zitierte Untersuchung und auch 
den Foliensatz kannte ich schon vorher.

Da steht drin, daß ein Stackoverflow eine wahrscheinliche Ursache 
gewesen sein könnte, und als Bewies wird angeführt, daß die Misra nicht 
eingehalten haben. Bewiesen ist der Fehler nicht, und schon gar keine 
schuldige Codestelle identifiziert. Es steht auch drin, daß auch 
Hardwarefehler, kippende Bits, und ein Haufen anderer schöner Dinge die 
Ursache hätten sein können. Andere Untersuchungen zeigen, daß auch deren 
real-time-Annahmen auf die Kante genäht waren, usw.

Toyota sagt, daß deren fail safe System all diese Fehler abgefangen 
hätte, kann das aber auch nicht beweisen.

Fest steht mir, daß Rust an all dem nichts geändert hätte. Die Probleme 
liegen alle oberhalb der von Rust eingezogenen Sicherheitsebene.

Oliver

von MaWin O. (mawin_original)


Lesenswert?

Oliver S. schrieb:
> Fest steht mir, daß Rust an all dem nichts geändert hätte. Die Probleme
> liegen alle oberhalb der von Rust eingezogenen Sicherheitsebene.

Ja, das ist ziemlich wahrscheinlich.
Es geht bei Rust ja erst einmal auch nicht um Safety, sondern um 
Security.
Das sind zwei grundverschiedene Dinge, auch wenn die Ursachen für 
Safety-Fehlfunktionen denen von Security-Fehlfunktionen ähneln können. 
Im Systemdesign unterscheiden die Gegenmaßnahmen sich aber erheblich.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> - Das kann der Compiler prinzipiell nicht, weil Linker und überhaupt ist
> das gar nicht bekannt wie groß der Stack ist!

Es war im Kontext von "Speichersicherheit ohne Runtime-Overhead". Du 
wirst Dich erinnern, daß dies eines der zentralen Rust-Features ist. Das 
ist auch der Grund, wieso Rust unter Linux auf Guard-Pages setzt, die 
keinen Overhead verursachen, solange kein Stackoverflow passiert.

Mit Runtime-Overhead kann man das natürlich in jeden Compiler einbauen, 
aber das ist dann kein Rust-Feature, sondern jede C-Implementation 
könnte das auch tun. Insofern ist es auch da korrekt, wenn man sagt, daß 
Rust als Sprache da gar nichts garantiert, ebensowenig wie C.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> "Speichersicherheit ohne Runtime-Overhead". Du
> wirst Dich erinnern, daß dies eines der zentralen Rust-Features ist.

Niemand hat behauptet, dass Speichersicherheit grundsätzlich ohne 
Runtime-Overhead in Rust realisiert ist. Und schon gar nicht, dass dies 
ein zentrales Rust-Feature ist.
Bitte bleibe bei der Wahrheit. Man kann hier alles nachlesen, was du im 
Nachhinein falsch verdrehst.

Speichersicherheit mit wenig Runtime-Overhead, im Mittel vergleichbar 
mit dem Overhead, den man in korrekten C-Programmen auch hätte. Das ist 
eines der zentralen Rust-Features. Und nichts anderes wurde hier gesagt.

von Nop (Gast)


Lesenswert?

Oliver S. schrieb:
> und als Bewies wird angeführt, daß die Misra nicht
> eingehalten haben.

Das war schon ein bißchen mehr als nur MISRA-Mißachtung.

> Bewiesen ist der Fehler nicht

Derartige Fehler kann man auch schwerlich beweisen, weil es sehr 
seltene, sporadische Fehler sind. Sonst wäre das bei Testfahrten schon 
aufgefallen.

> und schon gar keine schuldige Codestelle identifiziert.

Bei Stackoverflow gibt es in dem Sinne auch keine schuldige Codestelle, 
wenn man die Stackdimensionierung selber nicht als solche durchgehen 
läßt, weil es z.B. bei Interrupts sehr davon abhängt, in welcher 
zeitlichen Abfolge sie mit Blick auf ihre Priorisierung anfallen und in 
welcher Tiefe des ISR-Calltrees der nächste Interrupt eintrifft.

Das ist übrigens auch der Grund, wieso "den Stack vorher mit einem 
Testmuster füllen, das System laufen lassen und gucken, bis wo der Stack 
genutzt wurde" keine brauchbare Verifikationsmethode darstellt. Das 
ergibt nämlich nur eine untere Schranke für den Stackbedarf. Damit kann 
man lediglich die ohnehin fällige worst-case-Analyse einem 
Plausibilitäts-Check unterziehen.

von Nop (Gast)


Lesenswert?

MaWin O. schrieb:

> Niemand hat behauptet, dass Speichersicherheit grundsätzlich ohne
> Runtime-Overhead in Rust realisiert ist.

Was bare metal und Stackoverflow angeht, ist sie sogar überhaupt nicht 
implementiert, wie Du nach diversen Versuchen des Rauswindens dann 
eingestanden hast. Sie ist also ganz offensichtlich nicht Teil der 
Sprache selber.

> Speichersicherheit mit wenig Runtime-Overhead, im Mittel vergleichbar
> mit dem Overhead, den man in korrekten C-Programmen auch hätte.

Ein korrektes C-Programm braucht keinerlei Stacküberprüfung zu machen, 
weil eine dem C-Standard entsprechende Umgebung compilerseitig 
vorausgesetzt wird. Also genauso wie bei Rust und bare metal.

von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb:
> nach diversen Versuchen des Rauswindens dann eingestanden hast.

Das kannst du mehrfach behaupten, aber es stimmt halt nicht.
Du kannst hier im Thread nachlesen, wie ich schon vor einiger Zeit 
gesagt habe, dass Rust derzeit noch nicht auf kleinen Embedded-Systemen 
stabil ist. Das gilt nach wie vor.
Und das war lange bevor du deine Nebelkerzen zum Stackoverflow gezündet 
hast.

> Ein korrektes C-Programm braucht keinerlei Stacküberprüfung zu machen,
> weil eine dem C-Standard entsprechende Umgebung compilerseitig
> vorausgesetzt wird. Also genauso wie bei Rust und bare metal.

Wo ist dann dein Problem?

Es wurde hier behauptet, dass ein Rustprogramm grundsätzlich keine 
Stackprüfung machen könne. Ich habe bewiesen, dass es doch eine Prüfung 
macht. Du hast halt Unrecht gehabt. Passiert jedem mal. Nicht schlimm.

Ich habe nichts über C gesagt. Ich habe nicht gesagt, was besser und was 
schlechter ist.

Beitrag #6930724 wurde von einem Moderator gelöscht.
von MaWin O. (mawin_original)


Lesenswert?

Nop schrieb im Beitrag #6930724:
> Leider schon wieder gelogen.

Warum greifst du mich persönlich an?

> Der resultierende Segfault im Kernel ist ohne OS-Unterstützung so nicht drin.

Selbstverständlich ist das ohne Kernelunterstützung implementierbar.
Glaubst du der Kernel wäre etwas magisches, was irgendwas aus dem Hut 
zaubert?

Es ist sogar ohne MMU-Unterstützung implementierbar, wenn die Hardware 
minimalste Protection-Mechanismen hat.
Und es ist auch ohne MPU implementierbar, wenn man den Stack so 
platzieren kann, dass beim Überlauf ein Zugriff auf einen ungültigen 
Bereich stattfindet und dieser ein Trap auslöst.
Und es ist auch ohne Trap lösbar, indem man alle Stackveränderungen ganz 
einfach prüft.

Beitrag #6930740 wurde von einem Moderator gelöscht.
Beitrag #6930742 wurde von einem Moderator gelöscht.
Beitrag #6930744 wurde von einem Moderator gelöscht.
Beitrag #6930751 wurde von einem Moderator gelöscht.
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Nop schrieb:
> Der Calltree ist größenteils bekannt, dann noch Interrupts in
> worst-case-Schachtelung, und ein paar Calls, die über Funktionszeiger
> gehen können.

Klappt halt so nur, solange die Stacknutzung nicht zu stark von den 
(nicht exakt vorhersagbaren) Eingabedaten abhängt.

Klar, alles was statisch machbar ist, ist eh immer am einfachsten.

Im Zweifelsfalle, wenn man Sicherheit braucht, darf dann aber eben auch 
die Hardware weder von der Geschwindigkeit noch vom Speicherausbau „auf 
Kante genäht“ sein.

Aber ja, mit Rust hat das alles jetzt nichts mehr zu tun. :-)

Kann schon sein, dass Rust auch in diesem Bereich künftig noch an Boden 
gewinnt, aber im Moment sehe ich das noch nicht um die Ecke lugen. Ein 
Auftraggeber, für den ich letztens gearbeitet habe (mit durchaus sehr 
experimentierfreudigen Entwicklern), hatte es für eine Embedded-Lösung 
auf deutlich höherem Niveau (embedded Linux auf größerer STM-Plattform) 
initial in Erwägung gezogen, aber dann doch wieder verworfen und 
herkömmlich in C++ gearbeitet. Bei denen ist auch funktionale Sicherheit 
ein Thema, und der ganze Krams muss dann durch eine Zertifizierung 
durch.

von Nop (Gast)


Lesenswert?

Jörg W. schrieb:

> Klappt halt so nur, solange die Stacknutzung nicht zu stark von den
> (nicht exakt vorhersagbaren) Eingabedaten abhängt.

Der Trick ist, daß man ja nicht die exakte Nutzung braucht, sondern nur 
eine verläßliche obere Schranke. Daher kann man die Eingabedaten mehr 
oder weniger ignorieren und geht einfach den Calltree durch, auch wenn 
der u.U. so in derser Kombo nicht unbedingt passieren kann.

> Im Zweifelsfalle, wenn man Sicherheit braucht, darf dann aber eben auch
> die Hardware weder von der Geschwindigkeit noch vom Speicherausbau „auf
> Kante genäht“ sein.

Klar, also beim Stackverbrauch wird ja auch immer noch ein wenig Reserve 
gefordert.

> Aber ja, mit Rust hat das alles jetzt nichts mehr zu tun. :-)

Nur noch am Rande. ;-)

> Bei denen ist auch funktionale Sicherheit
> ein Thema, und der ganze Krams muss dann durch eine Zertifizierung
> durch.

Da wird man dann noch so einiges an Lösungen brauchen, mindestens was 
für statement coverage.

Mehr Sorgenfelder sehe ich darin, daß es nur einen einzigen Compiler 
gibt, der zugleich auch noch der Sprachstandard ist, so daß man nichtmal 
einen Compilerbug von einem Sprachfeature unterscheiden kann. 
Kommerzieller Support ist auch nicht drin. Ein zertifizierter Compiler 
ist in weiter Ferne, und ohne ISO-Standard sehe ich den auch nicht.

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

Bzgl. gelöschte Beiträge: Bitte freundlich bleiben, andere der Lüge zu 
bezichtigen ist kein Teil einer sachlichen Diskussion.

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


Lesenswert?

Nop schrieb:
> ohne ISO-Standard sehe ich den auch nicht

Ein ISO-Standard wiederum ist ein ganz schön großer Haufen an Arbeit, 
die keinerlei "Hack value" hat. Einfach nur Arbeit, administrativ, 
editorisch.

Aber man könnte ihn – anders als bei Pascal – ja an den realen Features 
des existierenden Compilers fest machen. :)

von Jemand (Gast)


Lesenswert?

Nop schrieb:
> Ein zertifizierter Compiler
> ist in weiter Ferne

Sind eigentlich zertifizierte Compiler tatsächlich messbar besser? Oder 
nutzt man die nur der Zertifizierung und dem dazugehörigen Haftungszeug 
wegen?

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Huch, hier war ja richtig was los die Tage...

Nop schrieb:
> Mehr Sorgenfelder sehe ich darin, daß es nur einen einzigen Compiler
> gibt, der zugleich auch noch der Sprachstandard ist, so daß man nichtmal
> einen Compilerbug von einem Sprachfeature unterscheiden kann.
> Kommerzieller Support ist auch nicht drin. Ein zertifizierter Compiler
> ist in weiter Ferne, und ohne ISO-Standard sehe ich den auch nicht.

Ja, und dagegen hilft auch das gebetsmuehlenhafte Vortragen von "Nein, 
man muss ja kein Cargo nehmen..." auch von allen hier auftretenden 
MaWins nicht wirklich.

Es aendern sich die Compilerversionen noch schneller als gute Entwicker 
ihre Unterhosen und Socken wechseln - ich glaub' bei sowas sollte auch 
der Diplom-Informatiker mit Fachrichtung Projektkasper doch mal kurz ins 
Gruebeln kommen, wie er dann, wenn er sowas aus Sicherheitsgruenden 
einsetzt, Probleme seinen Scheffs verkaufen will...

Gruss
WK

von MaWin (Gast)


Lesenswert?

Dergute W. schrieb:
> Es aendern sich die Compilerversionen noch schneller

Und warum ist das schlecht?

Ist gcc auch schlecht, weil es relativ oft Releases macht?
https://gcc.gnu.org/releases.html

Wenn du bei einem alten Compiler bleiben willst, dann bleibe halt bei 
einem alten Compiler. Warum auch nicht, wenn er deinen Code übersetzen 
kann? Niemand hat etwas dagegen.

> Ja, und dagegen hilft auch das gebetsmuehlenhafte Vortragen von "Nein,
> man muss ja kein Cargo nehmen..."

Was hat jetzt Cargo genau mit Zertifizierung und ISO-Standard zu tun. 
Würde mich sehr interessieren, wenn du das einmal genauer erklärst.

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


Lesenswert?

Dergute W. schrieb:
> Es aendern sich die Compilerversionen noch schneller als gute Entwicker
> ihre Unterhosen und Socken wechseln

Das würde sich übrigens ganz schnell geben, wenn man ein 
Standardisierungsgremium dafür aufbaut. Nur mal so, für den nächstes 
Jahr zu veröffentlichen C-Standard (C23) war Annahmeschluss für die 
letzten Papers, die neue Features einbringen können, im Oktober 2021. Im 
Laufe dieses Jahrs werden diese noch zu Ende gefeilt, und ab Sommer 2022 
muss dann der eigentliche Formalismus für die Standardisierungsgremien 
(ISO, IEC, INCITS) in die Wege geleitet werden, damit der Standard 
nächstes Jahr fertig ist.

Dabei ist die WG14 noch insgesamt recht wenig bürokratisch: bei den 
normalen Sitzungen gibt es keine formalen Abstimmungen (ballot), sondern 
nur Meinungsumfragen (straw polls), bei denen die Mehrheit der 
Anwesenden (also auch Gäste) entscheidet, da die jeweils Anwesenden als 
Expertengremium gehandhabt werden. Ergebnisse werden natürlich nur dann 
angenommen, wenn diese Umfragen eine hinreichend klare Linie ergeben, 
ansonsten muss der Antrag ggf. umformuliert und neu gestellt werden.

von MaWin (Gast)


Lesenswert?

Jemand schrieb:
> Sind eigentlich zertifizierte Compiler tatsächlich messbar besser?

Besser, im Sinne von technisch weniger Bugs, ist ja gar nicht das Ziel 
einer Zertifizierung. So etwas enorm komplexes in einem 
Zertifizierungs-Regelwerk abzubilden, sodass keine Bugs mehr drin sein 
können, ist natürlich nicht möglich.
Es geht vielmehr darum, dass der Verkauf das Zertifikat-Label auf das 
Produkt drucken darf und die QM-Abteilung ruhiggestellt wird.
Durch einen zertifizierten Compiler wurde noch nie auch eine einzige 
Fehlfunktion verhindert. Ganz im Gegensatz zum Testen und Bugfixen (des 
Compilers). Das verhindert Bugs. Leider verhindert oft genug gerade die 
Zertifizierung das Bugfixen des Compilers, weil dann müsste er ja 
neuzertifiziert werden. Was dann oft genug in Workarounds in Produktcode 
ausufert, um Compilerbugs zu umschiffen. Das ist dann "billiger".

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Nur mal so, für den nächstes
> Jahr zu veröffentlichen C-Standard (C23) war Annahmeschluss für die
> letzten Papers, die neue Features einbringen können,

Das ist nur nötig, weil C kaum Mechanismen und Regelwerke hat, Features 
vollständig rückwärtskompatibel einzubauen. Im Gegensatz zu Rust. Links 
dazu habe ich bereits gepostet.

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


Lesenswert?

MaWin schrieb:
> Das ist nur nötig

Sorry, aber du erzählst gerade Unsinn. Das hat mit C absolut nichts zu 
tun, sondern mit der Wirkungsweise von Standardisierungsgremien.

(Außerdem beweist deine Aussage über Nicht-Rückwärtskompatibilität von C 
höchstens, dass du diese Sprache nicht einmal kannst, geschweige denn 
ihre Standards. Aber der Thread hier ist natürlich nicht für die 
Diskussion über C da.)

: Bearbeitet durch Moderator
von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Das hat mit C absolut nichts zu
> tun, sondern mit der Wirkungsweise von Standardisierungsgremien.

Natürlich. Der C-Standard hat mit C absolut gar nichts zu tun. "Es gibt 
nichts zu sehen hier! Gehen Sie weiter!"

> dass du diese Sprache nicht einmal kannst

Ich muss mich hier nicht rechtfertigen.

Aber vielleicht du? Wie gut kennst du Rust?

Ja, Rust hat keine formelle Standardisierung. Das bestreitet niemand.
Aber Rust hat sehrwohl wirkungsvolle Mechanismen und Features 
vollständig rückwärtskompatibel zu diskutieren und zu stabilisieren.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Außerdem beweist deine Aussage über Nicht-Rückwärtskompatibilität von C

Außerdem habe ich das nie gesagt. Lies meine Posts, bitte.

von Nop (Gast)


Lesenswert?

MaWin schrieb:

> Es geht vielmehr darum, dass der Verkauf das Zertifikat-Label auf das
> Produkt drucken darf und die QM-Abteilung ruhiggestellt wird.

Dieselbe Argumentation kann man auch bei der zertifizierten 
Produktsoftware selber anbringen. Als Schlußfolgerung bleiben dann z.B. 
Flugzeuge, die nach Agil-Yolo entwickelt wurden. Wird bestimmt ein 
Verkaufs-Hit.

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> Als Schlußfolgerung bleiben dann z.B. Flugzeuge,

Das ist korrekt.

Auch in Flugzeugen werden Bugs ausschließlich durch Tests und in 
Design-Reviews/Prozessen gefunden und gefixt. Niemals aber durch eine 
Zertifizierung des Compilers.

Standardisierte Entwicklungsprozesse sind es, as Safety schafft. Nicht 
Zertifizierung von Entwicklungstools.

von Nop (Gast)


Lesenswert?

MaWin schrieb:

> Standardisierte Entwicklungsprozesse sind es, as Safety schafft. Nicht
> Zertifizierung von Entwicklungstools.

Dann darfst Du bei den höheren Anforderungsleveln als Hersteller gerne 
selber beweisen, daß der Maschinencode Deinem Sourcecode entspricht. 
Viel Spaß dabei, diese Kosten zu stemmen, und das für jedes Projekt und 
jedes Update erneut. Mit Testen alleine kommst Du da nämlich nicht 
durch.

von Nop (Gast)


Lesenswert?

... überdies ist der Widerspruch offensichtlich: bei Produkten helfen 
standardisierte Entwicklungsprozesse, die überhaupt die Basis für die 
Produkt-Zertifizierung sind, der Produktqualität - aber für Compiler 
gilt das natürlich nicht. Ja nee, ist klar.

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> überhaupt die Basis für die
> Produkt-Zertifizierung sind, der Produktqualität - aber für Compiler
> gilt das natürlich nicht.

Eine Produktzertifizierung hilft der Produktqualität genau so, wie eine 
Compilerzertifizierung der Compilerqualität hilft.
Nämlich gar nicht.
Solle klar sein.

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> Dann darfst Du bei den höheren Anforderungsleveln als Hersteller gerne
> selber beweisen, daß der Maschinencode Deinem Sourcecode entspricht.

Wie hilft mir die Zertifizierung dabei? Also technisch jetzt. Nicht 
rechtlich, durch das Verschieben der Verantwortung.

von Nop (Gast)


Lesenswert?

MaWin schrieb:

> Eine Produktzertifizierung hilft der Produktqualität genau so, wie eine
> Compilerzertifizierung der Compilerqualität hilft.
> Nämlich gar nicht.

Aber sicher doch. Deswegen werden Flugzeuge ja zertifiziert. Weil's 
nichts bringt. Daß die Luftfahrt massiv sicherer geworden ist, ist halt 
Zufall. Jedenfalls in Deinem Paralleluniversum.

Kleiner Denkanstoß: hätte man bei der 737-Max die Prozesse tatsächlich 
befolgt, wären die Flieger nicht abgestürzt. Hätte die FAA ihren Job 
gemacht und nicht effektiv Boeing sich selbst beliebige Zertifikate 
ausstellen lassen, dann wären die Prozesse auch befolgt worden.

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> Kleiner Denkanstoß: hätte man bei der 737-Max die Prozesse tatsächlich
> befolgt, wären die Flieger nicht abgestürzt.

Ich habe bereits gesagt, dass Entwicklungsprozesse absolut und 
unbestritten zur Qualität beitragen (bzw. dessen Grundlage ist).
Im Gegensatz zu Compilerzertifizierungen. Die helfen nur den 
Zertifizierungsunternehmen.

Aber du wirst mir sicher wieder die Worte im Munde herumdrehen. Es ist 
alles nachlesbar und dokumentiert hier im Forum.

von Nop (Gast)


Lesenswert?

MaWin schrieb:

> Ich habe bereits gesagt, dass Entwicklungsprozesse absolut und
> unbestritten zur Qualität beitragen (bzw. dessen Grundlage ist).

Was Du irgendwie nicht verstehst: Du bekommst keine Zertifizierung ohne 
den Nachweis entsprechender Entwicklungsprozesse. Das ist der Zweck 
einer Zertifizierung. Dementsprechend wirkt das bei Compilern ganz 
genauso wie bei anderen Produkten auch.

In Deinem Paralleluniversum murkst man sich irgendeinen Mist zurecht, 
geht damit zu einem Zertifizierungsunternehmen, bekommt irgendeinen 
Wisch und ist zertifiziert. Kein Wunder, daß Du den Sinn nicht 
begreifst.

von Carsten P. (r2pi)


Lesenswert?

MaWin schrieb:
> Es geht vielmehr darum, dass der Verkauf das Zertifikat-Label auf das
> Produkt drucken darf und die QM-Abteilung ruhiggestellt wird.

Also, MaWin mit oder ohne O, ich habe bisher einiges Nachdenkenswertes 
von dir gelesen, auch ein paar kluge Einwände, aber das ist jetzt echt 
mal kompletter Schwachsinn.

Das, was du hier gerade schwafelst, ist, als wären Schuhgrößen, weil sie 
genormt und innerhalb der EU durch Standards diese Normen 
vereinheitlicht wurden, Unsinn. Also, du sagst, Normen, Zertifizierungen 
dieser Normen sind egal. Das würde z.B. bedeuten, dass du heute in 
München wohnst z.B., dort in einem Laden Schuhe in der Größe 42 kaufen 
kannst, im Laden nebenan knapp noch, irgendwas zwischen 41 und 43, dann 
ziehst du um nach Hamburg, dort heißen die Schuhgrößen Alpha, Beta, 
Gamma und Omikron, und aufgrund der Geschichte mit der Hanse sind die 
Tragweiten mit kyrillischen Buchstaben ausgezeichnet.

Selbstverständlich gibt es in Hamburg Normen für Sohlen, die aber nur im 
Stadtgebiet von Hamburg und in einigen, aber nicht allen anderen 
Hansestädten gelten, was die Sicherheit angeht, falls sich die Sohle 
löst und du dir auf dem nicht weiter genormten Kopfsteinpflaster das 
Kinn brichst.

Wenn du die Idee der Normen grundsätzlich ablehnst, ist das deine Sache. 
Wenn du aber die Idee der Zertifizierung entlang dieser Normen ablehnst, 
möchte ich nichtmal auf der Rückbank eines Taxis neben dir sitzen.

von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
>
> Also, du sagst, Normen, [...] dieser Normen sind egal.
>
> Wenn du die Idee der Normen grundsätzlich ablehnst

Wo habe ich das gesagt? Bitte zitieren.

> Wenn du aber die Idee der Zertifizierung [...] ablehnst

Ich sprach ausschließlich von der Zertifizierung von Compiler-Tools. 
Denn ebenjene bringen keinen Qualitätsgewinn. Die Compiler sind 
bereits sehr sehr gut. Compilerfehler treten praktisch nicht auf. Und 
das ist nicht der Verdienst der Zertifizierungen, sondern von Tests. 
Zertifizierungen im Compilerbereich bringen nur Nachteile, indem sie 
einen an ebenjene zertifizierte Compilerversion ketten. Auch wenn diese 
Version Bugs enthält.

Von nichts anderem sprach ich. Es ging auch nicht um 
Produktzertifizierungen. Es ging auch nicht um genormte Prozesse und 
Produktnormen. Und auch nicht um irgendetwas beliebiges anderes. Das 
entspringt alles deiner Fantasie.

Bitte bei der Wahrheit bleiben. Es ist alles hier nachlesbar, was ich 
geschrieben habe. Es bringt überhaupt nichts, mir etwas anzudichten, was 
ich nie geschrieben habe.
Danke.

von MaWin (Gast)


Lesenswert?

Und außerdem hat das überhaupt nichts mehr mit Rust zu tun.
Wenn du den Rustcompiler zertifizieren willst, kannst du das gerne tun. 
Niemand hindert dich daran.

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


Lesenswert?

MaWin schrieb:
> Wenn du den Rustcompiler zertifizieren willst, kannst du das gerne tun.

Gegen was willst du den denn zertifizieren, wenn es keinen Standard 
gibt?

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Gegen was willst du den denn zertifizieren, wenn es keinen Standard
> gibt?

Das bleibt dir überlassen. Vielleicht gegen deinen Wocheneinkaufszettel?
An der Compilerqualität ändert es jedenfalls nichts. Egal, gegen was 
zertifiziert wird.

von Gerhard O. (gerhard_)


Lesenswert?

Vielleicht muß man nur geduldig sein. Gut Ding braucht Weil. War bei 
anderen Sprachen nicht anders.

Ich habe mir deren Webseite angesehen und gelesen, daß eine STM32 Bord 
unter Rust praktisch demonstriert wird. Hat jemand von Euch damit schon 
herum gespielt?

Wie gut wird sich Rust für kleinere uC bewähren? Gibt es Gründe warum 
Rust nicht auf kleinen 8-Bittern laufen wird? Oder ist da C/C++ momentan 
doch noch die beste Wahl.

Ich bin an Rust schon etwas interessiert. Nur habe ich wenig Motivation 
Pionierarbeit oder mich mit schwierigen Problemen herumschlagen zu 
müssen. Normalerweise liegt es mir daran mit iC Probleme zu lösen 
anstatt lösen zu müssen. Ich bin sicher, daß sich in ein paar Jahren die 
augenblicklichen Wogen legen werden und man Platform gerechte Lösungen 
finden wird.

Schön wäre es schon, wenn man ein Rust Entwicklungssystem hätte ohne 
große Überraschungen und mit guten Low-Level Support. So wie es halt bei 
allen anderen uC der Fall ist. Es scheint, momentan wäre die STM32 
Familie die einzige uC Familie die unterstützt wird.

Ich wäre sehr an praktischen Erfolgsberichten interessiert. Also z.B. 
"Ich baute mir ein Gadget mit Rust auf STM32" und Informationen über die 
Erfahrungen durchs Projekt hindurch.

Im Augenblick theoretisiert Ihr mir eigentlich zu viel und zu viele 
Generalitäten werden hin und her geworfen. Wenn Rust wirklich Fuß fassen 
sollen brauchen viele von uns doch konkrete Anhaltspunkte wie es anderen 
wagemutigeren Wegbereitern gegangen ist und wie man die anfänglichen 
Ungewissheiten beseitigen könnte. Es ist nicht genug wenn nur die Gurus 
und Genies unter Euch damit Erfolge erzielen. Wir sollten wirklich 
vermeiden "Fanboys" zu sein und uns anstatt gegenseitig so gut es geht 
mit Fakten untereinander helfen und Erfahrungen austauschen.

Was mich betrifft, hätte ich an Rust nur im uC embedded Bereich 
praktisches Interesse.

von MaWin (Gast)


Lesenswert?

Gerhard O. schrieb:
> Wie gut wird sich Rust für kleinere uC bewähren? Gibt es Gründe warum
> Rust nicht auf kleinen 8-Bittern laufen wird?

Es gibt einen experimentellen Rustcompiler für AVR8.
Er ist allerdings noch relativ weit vom Produktiveinsatz entfernt.
Aber als Proof-of-Concept taugt er.

> Ich bin an Rust schon etwas interessiert. Nur habe ich wenig Motivation
> Pionierarbeit oder mich mit schwierigen Problemen herumschlagen zu
> müssen.

Auf allem, was ARM-Cortex (Raspbery Pi) oder größer (bis PC) ist, ist 
die Pionierarbeit schon lange geleistet und Rust ist dort produktiv 
einsetzbar.

> STM32

Da kenne ich den Status leider nicht.

> Im Augenblick theoretisiert Ihr mir eigentlich zu viel

Ja, das sehe ich auch so. Viele Leute haben hier im Thread eine starke 
Meinung, aber fast niemand von diesen Leuten hat Rust einmal wirklich 
ausprobiert. Das wird offensichtlich aus den teilweise haarsträubenden 
Behauptungen.

> Wir sollten wirklich
> vermeiden "Fanboys" zu sein und uns anstatt gegenseitig so gut es geht
> mit Fakten untereinander helfen und Erfahrungen austauschen.

Volle Zustimmung.
Weniger Gefühle und Meinung. Mehr Fakten und Erfahrung.

von STMRust (Gast)


Lesenswert?

Gerhard O. schrieb:
> Ich habe mir deren Webseite angesehen und gelesen, daß eine STM32 Bord
> unter Rust praktisch demonstriert wird. Hat jemand von Euch damit schon
> herum gespielt?

Seit ca. 2 Jahren nutze ich ausschließlich Rust für alle meine STM32 
Hobby Projekte. Unter anderem habe ich Niklas G.'s USB-Tutorial als 
Übung auf Rust portiert (wenngleich das eine meiner ersten Rust-Aktionen 
war und noch um einiges mehr unsafe Code aufwies als nötig).
Cargo gefällt mir super, man muss nicht auf irgendwelche IDEs setzen die 
einem das Grundgerüst generieren, sondern mit paar Handgriffen (Target 
wählen, no-std deklarieren und PAC laden) baut "cargo build" einfach die 
binary für den STM. Einen Schritt weiter kann "cargo run" auch das ganze 
samt debug ausgaben ausführen, wenn man z.b. probe-run oder cargo-embed 
nutzt. Wenn ich mich an die Verrenkungen mit make oder cmake erinnere, 
war das um einiges aufwendiger.

Was mich vor allem zu Rust bekehrt hat ist das Pattern matching. Anfangs 
dachte ich match ist einfach nur "sowas ähnliches wie switch", aber es 
ist so viel mehr, vor allem macht es das Arbeiten mit enums (davon hat 
man ja oft welche) sehr viel übersichtlicher.
Insgesamt finde ich Rust Code mittlerweile viel angenehmer und einfacher 
zu lesen als C-Code, auch weil es dank rustfmt immer im gleichen Stil 
ist.

Der Einstieg in Rust auf STM32 ist einfach und es gibt mittlerweile sehr 
viele Beispiele, z.b. das Rust Embedded Book 
https://docs.rust-embedded.org/book/

von Carsten P. (r2pi)


Lesenswert?

Gerhard O. schrieb:
> Gut Ding braucht Weil.

Sei mir bitte nicht böse, Gerhard O., wenn ich dich nicht nur wörtlich, 
sondern Buchstabe für Buchstabe zitiere, denn "gut Ding braucht Weil!". 
Das ist ein sehr kluger Satz. Vielleicht hast du das "e" vergessen für 
deine Aussage, aber ich bleibe bei der, die du abgeschickt hast: "Gut 
Ding braucht Weil!".

Das ist in etwa das, etwas anders, aber auf den Punkt formuliert, was 
man Wissenschaft nennt, vor allem Naturwissenschaft.

Frage stets "Weil? Warum?"! Und lasse niemals locker, auch wenn dein 
Gegenüber genervt ist. Warum? Weil es nicht um dein Gegenüber geht, 
sondern um das Thema. Nicht um die Wahrheit an sich. Warum nicht? Weil 
es keine Wahrheit an sich gibt, sondern nur mehr oder weniger gute und 
überprüfbare Versuche, sich ihr anzunähern. Dass es eine einzige 
Wahrheit gibt, behaupten nur der Papst und Spaziergänger.

von MaWin (Gast)


Lesenswert?

STMRust schrieb:
> Seit ca. 2 Jahren nutze

Vielen Dank für den Beitrag. Endlich einmal jemand, der Rust auch 
wirklich ausprobiert hat.

> nutze ich ausschließlich Rust für alle meine STM32

Sehr interessant. Da habe ich jetzt auf jeden Fall etwas gelernt. Das 
sollte ich auch einmal ausprobieren.

von Nop (Gast)


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>> Gegen was willst du den denn zertifizieren, wenn es keinen Standard
>> gibt?
>
> Das bleibt dir überlassen. Vielleicht gegen deinen Wocheneinkaufszettel?

Dummes Gelaber - das selbstverständlich in den Bereichen, wo 
zertifizierte Tools gefordert werden, nicht akzeptiert wird.

> An der Compilerqualität ändert es jedenfalls nichts.

Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt, 
gegen den eventuelle Abweichungen festzustellen bzw. zu dem Konformität 
zu belegen wäre. Damit ist auch die Aussage von "sehr guter Qualität" 
nur eine leere Worthülse.

von Gerhard O. (gerhard_)


Lesenswert?

Carsten P. schrieb:
> Gerhard O. schrieb:
>> Gut Ding braucht Weil.
>
> Sei mir bitte nicht böse, Gerhard O., wenn ich dich nicht nur wörtlich,
> sondern Buchstabe für Buchstabe zitiere, denn "gut Ding braucht Weil!".
> Das ist ein sehr kluger Satz. Vielleicht hast du das "e" vergessen für
> deine Aussage, aber ich bleibe bei der, die du abgeschickt hast: "Gut
> Ding braucht Weil!".
>
Obwohl ich Dir im Weiteren vollkommen zustimme, habe ich mein Zitat nur 
im herkömmlichen Sinn gemeint, daß man eben Rust die Gelegenheit geben 
sollte erwachsen und reifer zu werden und daß das Zeit braucht. In zehn 
Jahren wird sich noch viel ergeben. So kann ich leider nicht das 
Kompliment annehmen:-)

Ich möchte vorerst mich mit der Entwicklungsumgebung befassen um die 
Werkzeuge unter Windows in den Griff zu bekommen. Eigenbau STM32 HW habe 
ich auch. Es ist mir wichtig die Tool Chain zum Laufen zu bringen. Die 
Sprache selber ist ja ziemlich intuitiv wenn man mal von den Pragmas 
absieht die man lernen muß. Da sehe ich für mich eher die größeren 
Schwierigkeiten. Dafür sind aber die Online Dokus da. Die Tricks wird 
man man sowieso in Kollaboration mit Mitstreitern lernen müssen und 
vielleicht miteinander teilen können.

: Bearbeitet durch User
von Gerhard O. (gerhard_)


Lesenswert?

An STMrust,

Vielen Dank für Deine Hinweise. Ich habe mir schon die embedded Doku 
angesehen.

von MaWin (Gast)


Lesenswert?

Nop schrieb:
> Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt

Qualität ist die Abwesenheit von Kundenreklamationen.

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> Nop schrieb:
>> Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt
>
> Qualität ist die Abwesenheit von Kundenreklamationen.

Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik.

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


Lesenswert?

Mombert H. schrieb:

>> Qualität ist die Abwesenheit von Kundenreklamationen.
>
> Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik.

Musst du sie noch auf die Gesamtkundenzahl beziehen, dann passt das 
schon.

Könnte natürlich sein, dass C-Compiler dann dank ihrer großen Kundenzahl 
verdammt gut abschneiden. ;-)

von Mombert H. (mh_mh)


Lesenswert?

Jörg W. schrieb:
> Mombert H. schrieb:
>>> Qualität ist die Abwesenheit von Kundenreklamationen.
>> Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik.
> Musst du sie noch auf die Gesamtkundenzahl beziehen, dann passt das
> schon.
> Könnte natürlich sein, dass C-Compiler dann dank ihrer großen Kundenzahl
> verdammt gut abschneiden. ;-)
Vorher müsste man klären was genau mit Kunde gemeint ist. Wenn ich clang 
oder gcc nutze sehe ich mich nicht als Kunde. Nur wenn ich ifort nutze 
sehe ich mich aktuell als Kunde und das macht weniger als 5% meiner Zeit 
aus.

von MaWin (Gast)


Lesenswert?

Mombert H. schrieb:
> Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik.

Genau.
In Abwesenheit von Kunden spielt Qualität keine Rolle.
Außer in QM-Hirnen.

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


Lesenswert?

Mombert H. schrieb:
> Vorher müsste man klären was genau mit Kunde gemeint ist.

Nenne sie von mir aus „aktive Nutzer“. Streng genommen müsstest du 
natürlich noch die Nutzungshäufigkeit mit einbeziehen, denn je häufiger 
du sie nutzt, um so größer die Wahrscheinlichkeit, mal auf ein Problem 
damit zu stoßen.

von MaWin (Gast)


Lesenswert?

Mombert H. schrieb:
> Wenn ich clang oder gcc nutze sehe ich mich nicht als Kunde.

Krass.
Das sagt mehr über dich aus, als über clang, gcc und den Rest der Welt.

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> Mombert H. schrieb:
>> Wenn ich clang oder gcc nutze sehe ich mich nicht als Kunde.
>
> Krass.
> Das sagt mehr über dich aus, als über clang, gcc und den Rest der Welt.
Dann erleuchte mal die Welt und gib uns deine Definiton von Kunde.

von MaWin (Gast)


Lesenswert?

Mombert H. schrieb:
> Dann erleuchte mal die Welt und gib uns deine Definiton von Kunde.

Legaler Nutzer laut Lizenz.

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> Mombert H. schrieb:
>> Dann erleuchte mal die Welt und gib uns deine Definiton von Kunde.
>
> Legaler Nutzer laut Lizenz.

Wenn ich in den Supermarkt gehe, bin ich also kein (evtl. potentieller) 
Kunde? Oder wie definierst du Lizenz?

von DPA (Gast)


Lesenswert?

Software beschaffen    -> Lizenz Vertrag

Im Laden was Einkaufen -> Kauf Vertrag

Sind beides Verträge, man denkt über letzteren nur nicht so, weil das 
meistens implizit ist. (Ich geb einfach den angeschriebenen Betrag, und 
allen ist klar, was die Konditionen sind)

Eigentlich nervig, dass das bei Software noch nicht simpler gestaltet 
wurde. Kundenschutz ist auch nicht existent. Wie Geräte heute zu 
Servicen werden, zum Kotzen. Rechtssysteme versagen beim Digitalen 
einfach komplett, lassen Unternehmen verlangen, tun und lassen, was sie 
wollen, und regulieren am falschen Ort, um positiven Technologieeinsatz 
zu erschweren / verhindern.

von Mombert H. (mh_mh)


Lesenswert?

DPA schrieb:
> Software beschaffen    -> Lizenz Vertrag
> Im Laden was Einkaufen -> Kauf Vertrag
Das bedeutet man kann Software nicht kaufen? Was ist mit Software, die 
ich nicht gekauft oder beschafft habe aber trotzdem nutze? Bin ich dann 
Kunde?

von DPA (Gast)


Lesenswert?

Mombert H. schrieb:
> DPA schrieb:
>> Software beschaffen    -> Lizenz Vertrag
>> Im Laden was Einkaufen -> Kauf Vertrag

> Das bedeutet man kann Software nicht kaufen?

Das ganze ist etwas kompliziert, ich überblicke das alles auch nicht.
Die kurze Version ist, Ja, man kann Software Kaufen, aber was heisst das 
eigentlich?

Man muss sich da überlegen, was man da unter kaufen versteht, bzw. was 
man eigentlich kaufen will. Man kann z.B. Lizenzen anbieten/kaufen. 
Damit kann man z.B. Nutzungsrechte an einer Software erwerben, aber auch 
andere Dinge festlegen.

Kann man zwar beim Kauf anderer Sachen auch machen, insbesondere bei 
anderen nicht physischen Sachen (Bilder, Filme, Musik (oft separat 
Aufzeichnung, Vorführung, Noten, Texte), etc.), ist das recht üblich. 
Ich bin mir nicht sicher, bis zu welchem Grad man das mit physischen 
Dingen machen kann, und wie genau das mit "geistigem Eigentum", 
Eigentumsrechten, Besitzrechten, usw. im Detail zusammenhängt & 
funktioniert, aber man kann überall einiges festlegen.

Aber eventuell will man eine Software kaufen, im sinne von den Code & 
sämtliche Rechte daran kaufen. Das geht bis zu einem gewissen Grad auch. 
Wobei, in gewissen Ländern kann man gewisse Rechte nicht verkaufen oder 
aufgeben, und vieles ist je nach Land sehr anders geregelt. Darum kann 
man z.B. nicht einfach sagen "Ich geb all meine rechte auf, und gebe sie 
der Allgemeinheit", sondern braucht dafür Lizenzen wie CC0, die 
versuchen das nächst beste mögliche zu bieten 
(https://creativecommons.org/share-your-work/public-domain/cc0/). 
Ehrlich gesagt, ich wüsste gar nicht, wie ich eine Software jemand 
anderem verkaufen könnte, im sinne von alle möglichen Rechte daran.

> Was ist mit Software, die ich nicht gekauft oder beschafft habe aber trotzdem 
nutze?

Um diese nutzen zu können, brauchst du trotzdem eine Vertrag/Lizenz, die 
dir das erlaubt. Oft ist das aber auch ein bisschen wie wenn man sonst 
was Einkauft oder Verschenkt. Wenn ich meine eigene Software gratis 
anbiete, oder als Demo Version, reicht es vermutlich zu sagen, das ist 
Freeware / eine Demo Version, hier ist der Download. Aber normalerweise 
gibt es danach trotzdem noch irgend eine EULA, die genauer festhält, das 
die Konditionen für den Endnutzer sind. Es gibt da noch irgend einen 
Unterschied zwischen Endnutzer Lizenzen und anderen arten von Lizenzen. 
Die GPL z.B. ist keine Endnutzerlizenz. Die legt einfach fest, was man 
mit dem Code machen darf, und man muss ihr nicht explizit zustimmen, 
will man die Rechte, die sie einem gibt, muss man sich aber an sie 
halten. Wenn ich meinen Code dann gratis öffentlich auf GitHub stelle, 
mit der GPL Lizenz drin, gebe ich die Lizenz quasi gratis an andere. 
Aber ich könnte den Code auch ohne Lizenz veröffentlichen, dann dürfte 
ihn eigentlich keiner nutzen. Als Urheber kann ich Software beliebig 
lizenzieren, ich kann den Code also auch unter der / irgendeiner Lizenz 
lizenziert verkaufen. (Und die Lizenz legt dann auch Dinge fest, wie 
z.B. darf ich das weiterverkaufen).
Keine Ahnung, wann man Lizenzen explizit zustimmen muss und wann nicht, 
und wie das alles im Detail zusammen hängt. Vermutlich blickt da sowieso 
keiner durch.

Irgendwo hätte ich von der BM her noch ein Buch 
(https://www.booklooker.de/B%C3%BCcher/Thomas-Sutter-Somm+ZGB-OR-Schweizerisches-Zivilgesetzbuch-und-Obligationenrecht-mit-ZPO-SchKG-und/isbn/9783906186245), 
da steht auch irgendwo drin, wer (in der Schweiz) beim Verkauf von 
Dingen welche Rechte und Pflichten hat, was Eigentum und Besitz genau 
heist, wie man das Anwendet / was man in einem Vertrag anders regeln 
kann, usw. Theoretisch könnte ich dort im ZGB Teil, unter Sachenrecht, 
alles relevante zum kaufen und verkaufen von Dingen nachlesen (der teil 
ist gar nicht mal so lang), das dürfte zu einem teil auch auf Software 
zeug anwendbar sein. wobei dort das URG[1] (Urheberrecht) noch relevant 
sein dürfte, für all das zeug rund um geistiges Eigentum (ich glaube das 
fehlt in meinem Buch). Ja, da könnte ich nachlesen, wie das genau 
funktioniert. Könnte... Aber gilt ja eh nur in der Schweiz, bringt mir 
vermutlich eh nicht viel.

Wie auch immer, ob du jetzt eine Lizenz kaufst, oder die geschenkt 
bekommst, normalerweise bekommst du schon irgendwoher eine.



> Bin ich dann Kunde?

Gute frage. Ich bin mir nicht sicher, ob das irgendwo überhaupt formal 
definiert ist. Da kann ich nur meine eigene Sichtweise bringen.
Was bedeutet es wirklich, Kunde zu sein? Wenn ich dir was schenke, hast 
du vermutlich keine Garantie Ansprüche usw. In gewissen sinne bist du 
vermutlich schon ein Kunde, aber wer würde wen wann wirklich als Kunde 
betrachten? Ehrlich gesagt betrachte ich mich nicht als Kunde, wenn ich 
Zeugs geschenkt kriege. Und andere, die meinen Code gratis nutzen, (den 
ich nicht Verkaufe), sehe ich auch nicht als Kunde. Wenn mir Fehler 
gemeldet werden, und ich hab genug infos, fix ich die normalerweise 
schon. Aber wenn jemand echten Support für seine Probleme usw. will, nö, 
keine Lust. Das soll er sich woanders kaufen.

Also für mich ist man schon erst Kunde, sobald Geld fliesst.


[1] https://www.fedlex.admin.ch/eli/cc/1993/1798_1798_1798/de

von MaWin (Gast)


Lesenswert?

DPA schrieb:
> Bilder, Filme, Musik (oft separat Aufzeichnung, Vorführung, Noten, Texte

Vielen Dank für diesen riesigen Offtopic-Ausflug.
Dann können wir ja hoffentlich zum Threadthema zurückkommen. Ja?

von Mombert H. (mh_mh)


Lesenswert?

DPA schrieb:
> Das ganze ist etwas kompliziert
Ich stimme dir im Großen und ganzen zu und erwarte auch keine Antwort 
auf meine Fragen (ich hatte nur auf eine ernst gemeinte Antwort von 
MaWin auf die erste Frage gehofft ...). Ich möchte es an zwei Stellen 
aber noch etwas komplizierter machen ;-).

DPA schrieb:
>> Was ist mit Software, die ich nicht gekauft oder beschafft habe aber trotzdem 
nutze?
> Um diese nutzen zu können, brauchst du trotzdem eine Vertrag/Lizenz, die
> dir das erlaubt.
Um sie legal nutzen zu können. Wäre ich ein Kunde, wenn ich sie illegal 
nutzen würde? Was ist wenn mein Arbeitgeber der Käufer ist?

DPA schrieb:
> Ehrlich gesagt betrachte ich mich nicht als Kunde, wenn ich
> Zeugs geschenkt kriege. Und andere, die meinen Code gratis nutzen, (den
> ich nicht Verkaufe), sehe ich auch nicht als Kunde.
Das umgeht auch ein weiteres Problem. Wenn man Software für sich selbst 
entwickelt und nutzt, ist man dann sein eigener Kunde?

MaWin schrieb:
> DPA schrieb:
>> Bilder, Filme, Musik (oft separat Aufzeichnung, Vorführung, Noten, Texte
>
> Vielen Dank für diesen riesigen Offtopic-Ausflug.
> Dann können wir ja hoffentlich zum Threadthema zurückkommen. Ja?

Ich habe gedacht, die Qualität des rust-Compilers ist essenziell, um die 
Frage "Rust - ist das hier um zu bleiben?" zu beantworten. Und dafür 
müssen wir wohl erstmal klären was Kunden sind, denn:
MaWin schrieb:
> Nop schrieb:
>> Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt
>
> Qualität ist die Abwesenheit von Kundenreklamationen.

von MaWin (Gast)


Lesenswert?

Mombert H. schrieb:
> Und dafür müssen wir wohl erstmal klären

Es ist alles beantwortet. Deshalb werde ich dazu auch nichts mehr sagen.
Dass dir die Antworten nicht in den Kram passen, ist mir klar. Aber 
damit musst du dann wohl leben.

von cppbert3 (Gast)


Lesenswert?

In diesem Forum tummeln sich so dermaßen viele Leute die jeden kleinsten 
Satz dazu nutzen um eine riesen Off Topic Diskussion von der Leine zu 
lassen und dann ewig drauf rum zu reiten

Meistens wenn das Thema trivial oder irgendeine scheinbare nähe zu ihrem 
Fachgebiet aufweisst, oder man sich gar nicht mit dem Kern Topic 
auskennt und einfach nur quasseln will, Heise-Forumskultur in reinform

Es ist idiotisch gegen eine 5 Jahre alte Sprache zu wettern die keinem 
ein Haar krümmt und mehr oder minder bekannte Strategien besser 
integriert, so lange die nutzung nicht erzwungen wird ist jede 
Argumentation sinnfrei, wenn sich Rust trotz der ganzen schwächen 
etabliert ist die komplette Community ein der ihr euch befindet eben 
nicht klug, wenn Rust stirb ist nichts verloren

Diskutiert doch lieber mit MaWin über die Vor/Nachteile dieser oder 
jener Konstruktion von Rust als all die alten Kammellen die jeder kennt 
und versteht und nur ihr denkt das jemand die nicht genauso gut 
vestanden habt wie ihr durchzubeten/kauen

alte Kamellen:
-statische Codeanalyse reicht völlig aus
-Sanitizer machen alles perfekt
-schreib einfach guten Code dann ist auch ok
-ohne ISO standard kann ich nicht leben
-ohne zertifizierung kann ich nicht leben
-wenn es nicht von allen Herstellern unterstuetzt wird ist es nichts 
wert
-wenn es nicht jedes problem ob syntaktisch, ausdruckstaerke oder 
logisch löst ist es nix wert
-Es kompiliert langsam, also ist es nichts wert

Solche Kommentare können nicht von versierten und erfahrenen Entwickler 
mit grossen Team und Projekterfahrungen kommen denn das alles sind schon 
100% genutzte und bekannte probleme und wissen, nur der kleingeist denkt 
man müsse damit noch misionieren gehen, das ist alles ausgetretenes 
standardwissen, auch wenn manche das hier nicht verstehen weil ihre 
Welten so klein und überschaubar sind

Also reisst euch mal zusammen ihr Nörgelfritzen und bleibt bei der Sache

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


Lesenswert?

Ich kann mich gar nicht erinnern, dass hier jemand gegen Rust 
"gewettert" hätte.

Was kritisiert worden ist ist, dass man mit der neuen Sprache auch 
gleich mal noch das 43. neue Buildsystem etabliert und ziemlich stark 
verbandelt hat.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Was kritisiert worden ist ist, dass man mit der neuen Sprache auch
> gleich mal noch das 43. neue Buildsystem etabliert und ziemlich stark
> verbandelt hat.

Jörg, auch du warst gemeint mit:

cppbert3 schrieb:
> Meistens wenn das Thema trivial oder irgendeine scheinbare nähe zu ihrem
> Fachgebiet aufweisst, oder man sich gar nicht mit dem Kern Topic
> auskennt und einfach nur quasseln will, Heise-Forumskultur in reinform

Die Sache mit dem angeblich stark verbandelten Buildsystem ist bereits 
mehrfach beantwortet. Dir passt die Wahrheit nur nicht. Das akzeptiere 
ich. Nun akzeptiere doch auch du die Realität. Auch das zehnte 
Infragestellen wird zu den gleichen Antworten führen.

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


Lesenswert?

MaWin schrieb:
> Dir passt die Wahrheit nur nicht.

Mir ist sie (zumindest derzeit) schlicht egal.

Wenn ich aber eine Sprachbeschreibung sehe, die mir zugleich ein 
bestimmtes Buildsystem schmackhaft machen möchte ("Hello Cargo!" kommt 
gleich nach "Hello World!"), dann kannst du mir 10mal erzählen, die 
seien nicht verbandelt. Irgendwie sind sie es, sonst hätten sich die 
Autoren des Rust-Buchs nicht die Mühe gemacht, Cargo ein eigenes Kapitel 
zu widmen.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Wenn ich aber eine Sprachbeschreibung sehe, die mir zugleich ein
> bestimmtes Buildsystem schmackhaft machen möchte ("Hello Cargo!" kommt
> gleich nach "Hello World!"),

Ja, genau. Das erste Beispiel "Hello World" im Buch ist komplett ohne 
Cargo.
Komisch, gell? Wo man doch ohne Cargo praktisch nichts machen kann, weil 
es ja angeblich so stark verbandelt ist.

Mal ganz davon abgesehen, dass Cargo halt sehr gut ist und es vielleicht 
deshalb so gerne genutzt wird. Mit einer "starken Verbandelung" hat 
das nichts zu tun.

Aber was schreibe ich hier. Das ist alles ja schon mehrfach erklärt 
worden.

von Oliver S. (oliverso)


Lesenswert?

MaWin schrieb:
> Ja, genau. Das erste Beispiel "Hello World" im Buch ist komplett ohne
> Cargo.
> Komisch, gell?

"Hello World"- Beispiele für C kompilieren i.d.R. mit "gcc main.c -o 
main" oder so. Komplett ohne jedes Build-System. Auch komisch, oder?

Oliver

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> MaWin schrieb:
>
>> Dir passt die Wahrheit nur nicht.
>
> Mir ist sie (zumindest derzeit) schlicht egal.
> Wenn ich aber eine Sprachbeschreibung sehe, die mir zugleich ein
> bestimmtes Buildsystem schmackhaft machen möchte ("Hello Cargo!" kommt
> gleich nach "Hello World!"), dann kannst du mir 10mal erzählen, die
> seien nicht verbandelt. Irgendwie sind sie es, sonst hätten sich die
> Autoren des Rust-Buchs nicht die Mühe gemacht, Cargo ein eigenes Kapitel
> zu widmen.

Alte Kamelle: Buildsystemzwang, alles kommt aus dem Internet, Entwickler 
arbeiten nur noch mit third parties, validierungsproblematik

Wenn du so wie ich bei jedem Kunden ein anderes Buildsystem nutzen 
müsstes würde dich das vielleicht gar nicht mehr so stören, Rust schafft 
mit Cargo wenigstens eine gemeinsame Basis auch wenn es, was garantiert 
passieren wird nacher 2-3 Cargo clone geben wird, weil vielleicht doch 
zu viel fehlt wird ein grossteil diesen Pseudostandard verwenden und das 
ist, egal wie du es drehst und wendest erstmal keine absolut 
problematische Situation - und wenn es auch nur die Rust Entwickler 
zwingt ihre Sprache auch in einem buildsystem kontext zu betrachten

z.B. bei C++ warten wir alle auf Module, nur die meisten Buildsystem 
haben riesige Probleme auf Modulveraenderungen zu reagieren, weil es da 
keinen Standard gibt wie die intermediate Dateien heissen können usw. - 
weil sich die C++ Chairs immer schon einen dreck um die Infrastruktur um 
die sprache gekümmert haben, das ist z.B. auch der grund warum der 
Prepozessor so lange nicht teil des Standards war, die hatten keinen 
Bock auf die Verantwortung und haben das so weit wie möglich den 
Benutzern/Toolchainentwicklern aufgebürdet

Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit 
stark integrierten Buildsystemen auf den Markt geworfen wurden

von cppbert3 (Gast)


Lesenswert?

Oliver S. schrieb:
> MaWin schrieb:
>
>> Ja, genau. Das erste Beispiel "Hello World" im Buch ist komplett ohne
>> Cargo.
>> Komisch, gell?
>
> "Hello World"- Beispiele für C kompilieren i.d.R. mit "gcc main.c -o
> main" oder so. Komplett ohne jedes Build-System. Auch komisch, oder?
> Oliver

Das ist doch alles jedem bekannt, und das ist auch nichts was MaWin hier 
beschreitet oder als Argument für irgendwas verwendet

Was soll so ein Post bewirken?

von Oliver S. (oliverso)


Lesenswert?

cppbert3 schrieb:
> Das ist doch alles jedem bekannt, und das ist auch nichts was MaWin hier
> beschreitet oder als Argument für irgendwas verwendet

Doch, genau das war das Argument: Rust ist gar nicht mit Cargo 
verbandelt, weil das Hello-World-Beispiel im Buch ohne auskommt.

Oliver

von cppbert3 (Gast)


Lesenswert?

Oliver S. schrieb:
> cppbert3 schrieb:
>
>> Das ist doch alles jedem bekannt, und das ist auch nichts was MaWin hier
>> beschreitet oder als Argument für irgendwas verwendet
>
> Doch, genau das war das Argument: Rust ist gar nicht mit Cargo
> verbandelt, weil das Hello-World-Beispiel im Buch ohne auskommt.
> Oliver

Er hat doch nur bestätig das es gleichwertig ist, du kannst alles ohne 
und alles mit dem buildsystem machen, und das stand hier schon vor 
monaten und wird immer und immer wieder rausgekramt, wie langweilig

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


Lesenswert?

cppbert3 schrieb:
> Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit
> stark integrierten Buildsystemen auf den Markt geworfen wurden

Die haben ein integriertes Laufzeitsystem, insofern kannst du für die 
eher Python als Vergleich heranziehen als Rust, C oder FORTRAN.

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> cppbert3 schrieb:
>> Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit
>> stark integrierten Buildsystemen auf den Markt geworfen wurden
>
> Die haben ein integriertes Laufzeitsystem, insofern kannst du für die
> eher Python als Vergleich heranziehen als Rust, C oder FORTRAN.

über Laufzeitsystem haben wir hier doch bisher noch gar nicht 
gesprochen?

ich bezog mich eher drauf das es kein Link System gibt sondern der 
Quelltext mehr oder weniger direkt seine Abhängigkeiten vorschreibt - so 
wie mit Turbo Pascal in grauer Vorzeit

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


Lesenswert?

cppbert3 schrieb:
> ich bezog mich eher drauf das es kein Link System gibt sondern der
> Quelltext mehr oder weniger direkt seine Abhängigkeiten vorschreibt

Das ist aber durch das integrierte Laufzeitsystem ohnehin gesetzt. Daher 
der Vergleich mit Python.

Der Anspruch eines Systems, das mit einem Linker arbeitet, ist ja eher, 
dass man Komponenten von möglichst vielen verschiedenen Welten 
miteinander integrieren kann. (Womit ich nicht behaupten will, dass das 
bei Rust nicht gehen würde.)

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> Das ist aber durch das integrierte Laufzeitsystem ohnehin gesetzt. Daher
> der Vergleich mit Python.

ich verstehe den Bezug immer noch nicht - ich möchte nur zum Ausdruck 
bringen das Build-Unit Abhängigkeiten in anderen Sprachen wie C#, Java 
und z.B. auch Turbo Pascal schon teil des Sprachstandards sind also so 
eine Art Sprach-Integriertes Buildsystem und sich da auch keiner 
beschwert hat

bei C oder C++ (erst mit Modulen) gibt es so was gar nicht - ohne 
Preprozessor und Linker sind die einzelnen Build-Units völlig hilflos in 
der Luft umherfliegend - alles überentkoppelt weil C/C++ lange Zeit 
selbst das Konzept-von "Dateien" als zu grosse Abhängigkeit empfunden 
hat

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> Der Anspruch eines Systems, das mit einem Linker arbeitet, ist ja eher,
> dass man Komponenten von möglichst vielen verschiedenen Welten
> miteinander integrieren kann.

das war nicht die Grundintension bei C/C++ - da wollte man nur mit 
Gewalt jeden Kontakt zwischen den "Dateien" vermeiden, weil Dateien 
damals noch kein durchgesetztes Konzept waren und es eher darum ging den 
Prozess in möglichst viele Teilschritte zu zerlegen weil der geringe 
Speicher der damaligen System einfach zu schnelle an die grenze gestoßen 
ist - viele der heutigen Entwickler vergessen völlig wo das alles mal 
angefangen hat

von MaWin (Gast)


Lesenswert?

In einer perfekten Welt, die ich mir in meinem wirren Kopf so 
zusammenspinne, hätte ich auch gerne das eine perfekte Buildsystem, 
das mit allen Sprachen funktioniert und das alle Features genau so hat, 
wie jeder das will.

Leider ist das nicht die Realität.

Die Rustentwickler haben mit Cargo ein ziemlich gutes Buildsystem 
geschaffen, das viele Sachen sehr elegant löst. Standardisiertes 
Buildmanifest mit gutem Options- und Dependency-Management. Sehr schöne 
Integration von Unit-Tests, System-Tests und Beispielprogrammen. Sehr 
gute UX. Es funktioniert ganz einfach out of the box. Das sind so die 
Dinge, die mir spontan einfallen. Es gibt sicher noch viel mehr.

Und trotzdem ist es eben nicht fest verbandelt.
Es steht dem Entwickler frei, ob er dieses gute Angebot annimmt. Und 
natürlich nehmen die meisten Entwickler dieses Angebot an, weil es 
ganz einfach sehr gut funktioniert.

von Daniel A. (daniel-a)


Lesenswert?

cppbert3 schrieb:
> Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit
> stark integrierten Buildsystemen auf den Markt geworfen wurden

Die nutze ich privat einfach nicht. Früher in der Schule und bei der 
Arbeit gab es noch etwas Java, bis ich das später endlich alles ersetzen 
durfte.

Wobei, in Java kann man Dateien haben, die exklusiv für ein Interface 
sind. Und ich kann Code Kompilieren & Ausführen, der Interfaces nutzt, 
ohne dabei die Implementation kennen zu müssen (Ich kann sogar eine zur 
Runtime nachladen usw., und auch noch ziemlich simpel.) Und auch wenn 
die Klassen, die man importiert, zum Kompilieren vorhanden sein müssen, 
das ist glaube ich bei Java immerhin nicht rekursiv. Eigentlich hat Java 
das noch vergleichsweise gut gelöst. Und das Generics Konzept gefällt 
mir ehrlich gesagt auch recht gut, ziemlich inspirierend aus technischer 
Sicht wenn man sich harte Templates gewohnt ist.

von MaWin (Gast)


Lesenswert?

Daniel A. schrieb:
> Eigentlich hat Java
> das noch vergleichsweise gut gelöst. Und das Generics Konzept gefällt
> mir ehrlich gesagt auch recht gut,

Das ist sehr erfreulich.

Aber da es hier im Thread um Rust geht:
Wie gefallen dir Rust Generics denn so?

von cppbert3 (Gast)


Lesenswert?

Daniel A. schrieb:
> cppbert3 schrieb:
>> Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit
>> stark integrierten Buildsystemen auf den Markt geworfen wurden
>
> Die nutze ich privat einfach nicht. Früher in der Schule und bei der
> Arbeit gab es noch etwas Java, bis ich das später endlich alles ersetzen
> durfte.

wie gesagt - bei Java/C# und Konsorten ist das alles Teil des 
Sprachstandards - bei C/C++ nicht - und Rust nutzt einen Teil dieser 
Konzepte

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


Lesenswert?

cppbert3 schrieb:
>> Der Anspruch eines Systems, das mit einem Linker arbeitet, ist ja eher,
>> dass man Komponenten von möglichst vielen verschiedenen Welten
>> miteinander integrieren kann.
>
> das war nicht die Grundintension bei C/C++

Für C schon, denn das musste unbedingt mit Assemblercode kombiniert 
werden können, und FORTRAN war zu der Zeit vermutlich das, was heute C 
ist.

Für Rust wurde ja zumindest gesagt, dass es mit einer C-Umwelt klar 
kommt. Muss es eigentlich auch, denn bis mal alles Wichtige in Rust 
verfügbar ist, werden schon noch ein paar Jahrzehnte vergehen.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> denn bis mal alles Wichtige in Rust verfügbar ist

Was ist denn "alles Wichtige"?

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


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>> denn bis mal alles Wichtige in Rust verfügbar ist
>
> Was ist denn "alles Wichtige"?

Alles, was täglich gebraucht wird.

Wenn du in der Lage bist, einen normalen Desktop-Computer mitsamt seiner 
"Zutaten" (Browser, Editor, Office, Bildbearbeitung, PDF-Viewer etc. 
pp.) und dem zugrunde liegenden Betriebssystem mit Rust zu bauen (also 
nicht nur theoretisch, sondern ganz praktisch), dann dürfte der Punkt 
erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen 
geschriebener Bibliotheken nicht mehr so wichtig ist.

Wobe, FORTRAN hängt uns ja selbst heute noch hinterher, numpy oder 
Matlab lassen da grüßen.

: Bearbeitet durch Moderator
von Daniel A. (daniel-a)


Lesenswert?

Jörg W. schrieb:
> Wenn du in der Lage bist, einen normalen Desktop-Computer mitsamt seiner
> "Zutaten" (Browser, Editor, Office, Bildbearbeitung, PDF-Viewer etc.
> pp.) und dem zugrunde liegenden Betriebssystem mit Rust zu bauen

Nutzer von Gentoo & co. tun mir jetzt schon leid. "emerge -uDN @world" - 
und jetzt warten wir mal einen Monat...

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> dann dürfte der Punkt
> erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen
> geschriebener Bibliotheken nicht mehr so wichtig ist.

Warum sollte man den Punkt anstreben wollen?
Was hat das überhaupt mit Rust zu tun? Rust ist gut interoperabel mit 
anderen Sprachen. By Design. In Gegensatz zu C. C ist nur mit C 
kompatibel. Deshalb muss sich der Rest der Welt darum kümmern mit C 
kompatibel zu sein. Und das tut Rust sehr gut. Heute.

von MaWin (Gast)


Lesenswert?

Daniel A. schrieb:
> Nutzer von Gentoo & co. tun mir jetzt schon leid.

Die tun mir schon länger leid. Nicht erst, seit es Rust gibt.
SCNR.

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>> dann dürfte der Punkt
>> erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen
>> geschriebener Bibliotheken nicht mehr so wichtig ist.
>
> Warum sollte man den Punkt anstreben wollen?
"unsafe"
> Was hat das überhaupt mit Rust zu tun? Rust ist gut interoperabel mit
> anderen Sprachen. By Design.
"unsafe"
> In Gegensatz zu C. C ist nur mit C
> kompatibel. Deshalb muss sich der Rest der Welt darum kümmern mit C
> kompatibel zu sein. Und das tut Rust sehr gut. Heute.
"unsafe"

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> Für Rust wurde ja zumindest gesagt, dass es mit einer C-Umwelt klar
> kommt. Muss es eigentlich auch, denn bis mal alles Wichtige in Rust
> verfügbar ist, werden schon noch ein paar Jahrzehnte vergehen.

"zumindest gesagt"
"muss es eigentlich"

wurde schon sooo oft hier geschrieben - warum vermuten/fabulieren?

Rust kann direkt mit C gelinkt werden

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


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>> dann dürfte der Punkt
>> erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen
>> geschriebener Bibliotheken nicht mehr so wichtig ist.
>
> Warum sollte man den Punkt anstreben wollen?

Es war die Antwort auf deine Frage. Wenn du der Meinung bist, dass das 
gar nicht anstrebenswert ist, dann hättest du dir deine Frage auch 
sparen können.

> In Gegensatz zu C. C ist nur mit C
> kompatibel.

Wenn du derartige Äußerungen weglassen würdest, würde das deiner 
Glaubwürdigkeit gut zu Gesicht stehen. So tust du Rust einfach keinen 
Gefallen, weil sich jeder sagt: "Wenn deren Fanboys alle so sind, will 
ich damit nichts zu tun haben."

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


Lesenswert?

cppbert3 schrieb:
> wurde schon sooo oft hier geschrieben - warum vermuten/fabulieren?

Ich vermute oder fabuliere nicht, habe es nur selbst nicht verifiziert. 
Daher als Aussage anderer kenntlich gemacht.

Aber darum ging es gar nicht, sondern um deine Behauptung, dass es keine 
Intention gewesen wäre, dass C via Linker mit anderen Sprachen zusammen 
arbeitet. Die entbehrt jeglicher Grundlage.

von cppbert3 (Gast)


Lesenswert?

Mombert H. schrieb:
> MaWin schrieb:
>> Jörg W. schrieb:
>>> dann dürfte der Punkt
>>> erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen
>>> geschriebener Bibliotheken nicht mehr so wichtig ist.
>>
>> Warum sollte man den Punkt anstreben wollen?
> "unsafe"
>> Was hat das überhaupt mit Rust zu tun? Rust ist gut interoperabel mit
>> anderen Sprachen. By Design.
> "unsafe"
>> In Gegensatz zu C. C ist nur mit C
>> kompatibel. Deshalb muss sich der Rest der Welt darum kümmern mit C
>> kompatibel zu sein. Und das tut Rust sehr gut. Heute.
> "unsafe"

das ist doch jedem absolut klar, oder?
und selbst wenn nicht, 5min Rust Doku lesen und aufhören zu vermuten

wie soll Rust den bitte externe Abhängigkeiten safe einbinden?
Rust ist eine Systemsprache die nicht an jeder Ecke Prüfcode einbaut und 
auch nur deshalb überhaupt für Kernel-Entwicklung und High-Performanz 
relevant sein kann

diese episch tiefen Diskussionen über Kompiletime/Statische-Prüfbarkeit 
usw. scheitert hier häufig daran das irgendwelche Leute denke das 
Safe-Rust meint das alles geprüft wird oder Safe-Rust meint es sollte 
dann aber auch keine Fehler mehr geben - das ist doch 
Mathematisch/Systemisch gar nicht möglich - und auch die Rust Leute 
können nicht die Natur der Software-Probleme per se lösen sondern nur 
stark abschwächen

viele Leute finde "abschwächen" ist schon toll genug - auch wenn viele 
der Pro-Entwickler hier das 0 nachvollziehen können - weil ihr Code ja 
keine Fehler hat, oder ihre Team-Mitglieder alle gleich gut sind,...

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> Aber darum ging es gar nicht, sondern um deine Behauptung, dass es keine
> Intention gewesen wäre, dass C via Linker mit anderen Sprachen zusammen
> arbeitet. Die entbehrt jeglicher Grundlage.

das ist doch jedem Entwickler 100% klar, oder?
warum hier immer alle davon ausgehen das der Gesprächspartner nur 30% 
von der Medaille kennt?

Genau diese Denke führt hier zu diesen endlosen Tiefen-Diskussionen über 
banale Themen - Kompiletimeprüfung, Sanitizer, Zertifizierung, 
Entwicklungsprozesse - das sind alles alte Hüte die jeder kann und macht 
- und wenn man das dann so überdeutlich ausdrückt kommt hier jeder und 
erklärt wie relevant die Themen sind - als wäre das irgendjemanden nicht 
klar

Es ist nur einfach völlig unrelevant für den jetzigen Entwicklungstand 
von Rust - und war es auch vor Jahrzehnten für C/C++ und alle anderen 
jungen Programmiersprachen

und jetzt hört doch bitte auf immer in diesen Micro-Themen zu rotieren

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
>> In Gegensatz zu C. C ist nur mit C kompatibel.
> Wenn du derartige Äußerungen weglassen würdest, würde das deiner
> Glaubwürdigkeit gut zu Gesicht stehen.

Ach? Mit welchen Sprachen ist C denn so kompatibel?
Und wie sieht das C-Konstrukt aus, mit dem man z.B. angibt, dass 
Funktion X ein zur Sprache Y kompatibles ABI erhalten soll?
Ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind, 
und nicht umgekehrt?

Jörg W. schrieb:
> So tust du Rust einfach keinen
> Gefallen, weil sich jeder sagt: "Wenn deren Fanboys alle so sind, will
> ich damit nichts zu tun haben."

Wenn ein Programmierer seine Wahl der Programmiersprache von pseudonymen 
Posts von MaWin auf Mikrocontroller.net abhängig macht, dann ist diesem 
Programmierer eh nicht mehr zu helfen.

von Mombert H. (mh_mh)


Lesenswert?

cppbert3 schrieb:
> das ist doch jedem absolut klar, oder?
> und selbst wenn nicht, 5min Rust Doku lesen und aufhören zu vermuten
Könntest du kurz erklären was jedem klar ist? Und was die Doku damit zu 
tun hat? Ich verstehe nicht was du hier sagen willst.

cppbert3 schrieb:
> wie soll Rust den bitte externe Abhängigkeiten safe einbinden?
Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg.

Was du mit dem Rest deiner Tirade ausdrücken willst, weiß ich auch 
nicht.

von cppbert3 (Gast)


Lesenswert?

Mombert H. schrieb:
> cppbert3 schrieb:
>> das ist doch jedem absolut klar, oder?
>> und selbst wenn nicht, 5min Rust Doku lesen und aufhören zu vermuten
> Könntest du kurz erklären was jedem klar ist? Und was die Doku damit zu
> tun hat? Ich verstehe nicht was du hier sagen willst.

das externe Abhängigkeiten unsafe eingebunden werden muessen klar ist - 
sonst müsste Rust entweder sau langsam sein (wegen Prüfungen) oder 
irgendein magisches Konzept haben unsafes safe zu machen

> cppbert3 schrieb:
>> wie soll Rust den bitte externe Abhängigkeiten safe einbinden?
> Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg.

jetzt verstehe ich dich nicht - d.h. alles in Rust schreiben???
wie soll ich sonst die Abhängigkeiten los werden?

> Was du mit dem Rest deiner Tirade ausdrücken willst, weiß ich auch
> nicht.

ist nicht so schlimm, dauert noch ein bisschen

von MaWin (Gast)


Lesenswert?

Mombert H. schrieb:
> Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg.

Nein, "müssen" sie nicht.
Warum sollten sie das "müssen"?
Eine externe Bibliothek ist exakt genau so zu handhaben, wie 
unsafe-Blöcke in Rust. Da gibt es sogar ein Buch drüber, wenn du wissen 
willst, wie das geht:
https://doc.rust-lang.org/nomicon/  (work in progress)

Es ist doch völlig weltfremd anzunehmen, dass plötzlich alle Software 
der Welt nur noch in Rust geschrieben werden wird.

von MaWin (Gast)


Lesenswert?

cppbert3 schrieb:
> sonst müsste Rust entweder sau langsam sein (wegen Prüfungen)

Ich dachte wir hätten abschließend geklärt, dass Safe-Rust im Mittel 
nicht langsamer ist als äquivalenter sicherer C-Code? Das ist ein 
Rust-Designziel.

von Mombert H. (mh_mh)


Lesenswert?

cppbert3 schrieb:
> Mombert H. schrieb:
>> cppbert3 schrieb:
>>> das ist doch jedem absolut klar, oder?
>>> und selbst wenn nicht, 5min Rust Doku lesen und aufhören zu vermuten
>> Könntest du kurz erklären was jedem klar ist? Und was die Doku damit zu
>> tun hat? Ich verstehe nicht was du hier sagen willst.
>
> das externe Abhängigkeiten unsafe eingebunden werden muessen klar ist -
> sonst müsste Rust entweder sau langsam sein (wegen Prüfungen) oder
> irgendein magisches Konzept haben unsafes safe zu machen
Ok, was genau hat das mit dem ursprünglich (und natürlich von dir 
ausgelassenen) Beitrag zu tun, auf den du geantwortet hast?

>> cppbert3 schrieb:
>>> wie soll Rust den bitte externe Abhängigkeiten safe einbinden?
>> Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg.
>
> jetzt verstehe ich dich nicht - d.h. alles in Rust schreiben???
> wie soll ich sonst die Abhängigkeiten los werden?
Wtf?

>> cppbert3 schrieb:
>> Was du mit dem Rest deiner Tirade ausdrücken willst, weiß ich auch
>> nicht.
>
> ist nicht so schlimm, dauert noch ein bisschen
...

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> cppbert3 schrieb:
>> sonst müsste Rust entweder sau langsam sein (wegen Prüfungen)
>
> Ich dachte wir hätten abschließend geklärt, dass Safe-Rust im Mittel
> nicht langsamer ist als äquivalenter sicherer C-Code? Das ist ein
> Rust-Designziel.

das ist mir klar - ich fragte mich nur weiso Mombert H. überall unsafe 
geschrieben hatte in seinem Post - als wäre das was schlechtes, und dann 
meinte wir müssen die "Abhängigkeiten los werden" - aber laut seinem 
letzten Post "ohne neu schreiben in Rust" - keine Ahnung was er 
überhaupt meint

von cppbert3 (Gast)


Lesenswert?

Mombert H. schrieb:
>> das externe Abhängigkeiten unsafe eingebunden werden muessen klar ist -
>> sonst müsste Rust entweder sau langsam sein (wegen Prüfungen) oder
>> irgendein magisches Konzept haben unsafes safe zu machen
> Ok, was genau hat das mit dem ursprünglich (und natürlich von dir
> ausgelassenen) Beitrag zu tun, auf den du geantwortet hast?
>
>>> cppbert3 schrieb:
>>>> wie soll Rust den bitte externe Abhängigkeiten safe einbinden?
>>> Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg.
>>
>> jetzt verstehe ich dich nicht - d.h. alles in Rust schreiben???
>> wie soll ich sonst die Abhängigkeiten los werden?
> Wtf?

ich habe direkt auf einen Post geantwortet wo du überall "unsafe" 
hingeschrieben hast und ich mich gewundert hatte wie man sonst externen 
Code einbinden soll auf den das Rust Sicherheitskonzept keinen Einfluss 
hat

dann kam dein Kommentar mit den "deswegen müssen die Abhängigkeiten ja 
weg" womit ich völlig verloren bin und dachte du meinst das die externen 
Abhängigkeiten in Rust geschrieben werden müssen - weil ich sonst nicht 
verstehe was das "Abhängigkeiten ja weg" in diesem Kontext sonst 
bedeuten könnte

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


Lesenswert?

MaWin schrieb:
> ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind

Nein, sind sie nicht.

Mit deiner Argumentation ist wohl jede Sprache nur mit sich selbst 
kompatibel, denn sie kennt Konstrukte, die sich nicht in einer anderen 
ausdrücken lassen. Ein Pascal-Array-Argument kannst du beispielsweise in 
C nicht ausdrücken, denn es übergibt außer der Adresse auch seinen 
Indexbereich an den Aufgerufenen. Eine variadische Argumentliste in C 
wirst du wiederum in Pascal nicht aufgedröselt bekommen.

Kompatibilität ist folglich immer der kleinste gemeinsame Nenner 
zwischen beiden Seiten.

von MaWin (Gast)


Lesenswert?

cppbert3 schrieb:
> ich fragte mich nur weiso Mombert H. überall unsafe
> geschrieben hatte in seinem Post - als wäre das was schlechtes,

Ja. Das ist richtig. Unsafe-Codeteile, unter die auch externe 
Bibliotheken fallen, sind nicht schlecht. Es ist gar nicht so, dass 
Rustentwickler jetzt plötzlich losrennen und alle Unsafe-Teile 
eliminieren wollen. Ganz im Gegenteil. Unsafe-Code ist in Ordnung. Es 
bedeutet nur, dass dieser Code erheblich mehr Review und Testing 
erfahren muss.

Es ist ja auch gar nicht alles in Safe-Rust formulierbar, was formuliert 
werden muss. Je näher man an die Hardware kommt, desto mehr 
unsafe-Blöcke werden notwendig werden. Das Ziel ist es jedoch, diese 
unsafe-Blöcke in entsprechenden Safe-Rust-Modulen zu wrappen. Und genau 
das passiert auch mit externen Bibliotheken.

von Daniel A. (daniel-a)


Lesenswert?

MaWin schrieb:
> Ach? Mit welchen Sprachen ist C denn so kompatibel?
> Und wie sieht das C-Konstrukt aus, mit dem man z.B. angibt, dass
> Funktion X ein zur Sprache Y kompatibles ABI erhalten soll?

Wie soll den C die Datentypen und sonstigen Eigenheiten zukünftiger 
Sprachen unterstützen? Und wozu? C ist sehr alt, stabil, simpel, und 
bietet alles nötige, damit andere Programme mit ihm interoperieren 
können. Das ABI ist auch überall relative stabil und gut definiert. 
Zusammen mit seiner Verbreitung ist es daher heute mit so ziemlich jeder 
Sprache kompatibel. Oft verwendet man es sogar, um verschiedene Sprachen 
verbinden zu können. Es bietet sich in seiner jetzigen Form und 
Verbreitung dafür gerade zu an.

Auch wenn es dank historischer & designtechnischer Gründe diese 
Interopabilität quasi gratis bekommen hat, das ändert aber nichts daran, 
dass sie vorhanden ist.

Ausserdem, ist die ABI von Rust für die diversen Platformen mittlerweile 
endlich mal Stabil & Dokumentiert? Wobei, da müsste man vermutlich erst 
mal die Sprache selbst standardisieren? Wie soll man denn so damit 
überhaupt vollständig kompatibel sein können, im sinne von all seine 
Datentypen und APIs direkt nutzen können?

Man könnte das also umkehren. C erlaubt es anderen Sprachen recht 
einfach, zu ihm kompatibel zu sein. Aber ist das bei Rust überhaupt 
möglich?

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> MaWin schrieb:
>> ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind
>
> Nein, sind sie nicht.
>
> Mit deiner Argumentation ist wohl jede Sprache nur mit sich selbst
> kompatibel, denn sie kennt Konstrukte, die sich nicht in einer anderen
> ausdrücken lassen. Ein Pascal-Array-Argument kannst du beispielsweise in
> C nicht ausdrücken, denn es übergibt außer der Adresse auch seinen
> Indexbereich an den Aufgerufenen. Eine variadische Argumentliste in C
> wirst du wiederum in Pascal nicht aufgedröselt bekommen.
>
> Kompatibilität ist folglich immer der kleinste gemeinsame Nenner
> zwischen beiden Seiten.

MaWin wollte sicherlich eher zum Ausdruck bringen das der Teil den wir 
alle kennen von C der meistgenutzte gemeinsame Nenner ist an dem sich 
viele orientieren - und ja das passt auch für vieles von Pascal - aber 
man spricht dann trotzdem oft von der C Kompatibilität - obwohl auch 
Sprachen die älter sind als C schon "C-Kompatible" waren

Aber wie immer die Frage: Ist das wirklich Themen relevant?

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
>> ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind
> Nein, sind sie nicht.

Krass, wie du krampfhaft versuchst deine falsche Argumentation aufrecht 
zu erhalten.
C++ ist also nicht kompatibel zu C? extern "C"?
Rust ist also nicht kompatibel zu C? Auch wenn man structs und 
Funktionen explizit die C-ABI geben kann?

> Kompatibilität ist folglich immer der kleinste gemeinsame Nenner
> zwischen beiden Seiten.

Und C trägt aktiv exakt gar nichts dazu bei kompatibel zu irgendetwas zu 
sein.
C ist einfach nur C, so wie es ist.
C ist der kleinste gemeinsame Nenner, weil seine ABI so primitiv ist und 
weil es schlicht älter ist als alle anderen aktiv genutzten Sprachen.
Es gibt kein C-Konstrukt, mit dem man die ABI auf die einer anderen 
Sprache anpassen kann.

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> Es ist gar nicht so, dass
> Rustentwickler jetzt plötzlich losrennen und alle Unsafe-Teile
> eliminieren wollen. Ganz im Gegenteil. Unsafe-Code ist in Ordnung. Es
> bedeutet nur, dass dieser Code erheblich mehr Review und Testing
> erfahren muss.

viele denken man müsste alles nach Rust portieren
keine Ahnung wo dieser (schon dem Wahnsinn nahe stehendem) Irrglaube 
herkommt

sowas kenne ich nur von Anfängern oder Nur-eine-Sprach-Evangelisten (die 
zum Glück immer weniger im Business anzutreffen sind)

von cppbert3 (Gast)


Lesenswert?

Daniel A. schrieb:
> Es bietet sich in seiner jetzigen Form und
> Verbreitung dafür gerade zu an.

deswegen wird es ja auch direkt von Rust supportet, weil das schon so 
viele sprechen :)

Daniel A. schrieb:
> Aber ist das bei Rust überhaupt
> möglich?

gerade nicht weil die höherwertigen Konzepte sich recht
schwerlich durch eine ABI pressen lassen ohne die Performanzvorteile zu 
verlieren - wie bekommt man ein Kompiletime Ownership-Konzept durch eine 
Library/Dll-Grenze - nicht so einfach

Ich könnte mir vorstellen das sie eine Rust zu Rust ABI hinbekommen
aber eine Rust zu C ABI mit allen Rust-Features wird echt schwer

ist aber vergleichbar mit den Schwierigkeiten C++, C#, Java Konzepte mit 
C zu verbinden

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>>> ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind
>> Nein, sind sie nicht.
>
> Krass, wie du krampfhaft versuchst deine falsche Argumentation aufrecht
> zu erhalten.
> C++ ist also nicht kompatibel zu C? extern "C"?
> Rust ist also nicht kompatibel zu C? Auch wenn man structs und
> Funktionen explizit die C-ABI geben kann?

Jörg hat technisch schon recht mit seinem kleinsten gemeinsamen Nennen 
was die Datenbereite/Typen angeht (das ist aber eher ein 
Hardware-Standard)
aber spätestens bei Calling-Conventions hat MaWin recht - da ist es das 
C-Standard(Subset) mit cdecl das supported wird oder auch z.B. die 
typischen C-Strings

die meisten Sprachen sprechen auch explizit von C Kompatibilität
ansonsten sind alle Sprache erstmal nur zu sich selbst kompatibel (oder 
dem C-Standard-Subset)

im Detail geht es bei der Kompatiblität nur um die Stabilität der ABI - 
ob die sich jetzt C oder whatever schimpft ist unrelevant

von cppbert3 (Gast)


Lesenswert?

cppbert3 schrieb:
> Ich könnte mir vorstellen das sie eine Rust zu Rust ABI hinbekommen

also z.B. gibt es zwei Rust DLLs (A und B) die unterschiedliche Heaps 
haben
und wenn die B-DLL Heap-Daten von der A-DLL ownen will das es dann eine 
besondere Form von Big/Fat-Pointer oder sowas gibt und es laut der ABI 
klar ist das es dann Performanprobleme geben kann wenn die Heap-Daten 
Löschung an A delegiert werden muss - oder eine Art 
Copy-on-transfer-Konzept

Alles nicht sehr einfach und schwer generisch definierbar (soll es 
leicht sein, performant sein, etc.)

ähnlich wie der Design-Trouble mit Async - nur noch viel komplizierter

von cppbert3 (Gast)


Lesenswert?

cppbert3 schrieb:
> also z.B. gibt es zwei Rust DLLs (A und B) die unterschiedliche Heaps
> haben

das Problem ist vergleichbar mit std::vector über DLL-Grenze mit 
unterschiedlichen Heaps

aber ich habe immer noch die Hoffnung das Rust hier auch irgendwann mal 
mit einem besseren Konzept kommt als wie bisher:

-Alles nur per Value
-Alles auf eine C-artige API runterbrechen
-Alles mit Interfaces auf dem Heap/Ref-Counted

ohne unterschiedliche Heaps gibt es keine Probleme

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


Lesenswert?

cppbert3 schrieb:
> obwohl auch Sprachen die älter sind als C schon "C-Kompatible" waren

FORTRAN übergibt alles in einer Parametertabelle, alle Parameter sind 
dort per Referenz übergeben – zumindest das FORTRAN, was älter ist als 
C. (Auf der PDP-11 wurde die Adresse der Tabelle in R5 übergeben.) Weiß 
nicht, ob sie inzwischen auch andere Aufrufkonventionen haben.

Mit üblichen C-Konventionen ist das nicht kompatibel …

> Aber wie immer die Frage: Ist das wirklich Themen relevant?

Sicher nicht, aber ich habe die Diskussion, alles würde sich nur nach C 
richten müssen, auch nicht begonnen.

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
>> Aber wie immer die Frage: Ist das wirklich Themen relevant?
>
> Sicher nicht, aber ich habe die Diskussion, alles würde sich nur nach C
> richten müssen, auch nicht begonnen.

aber sie auch nicht gestoppt - und jetzt auch noch ne Uralt PDP-11 mit 
ins Feld geworfen :)

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
>> Aber wie immer die Frage: Ist das wirklich Themen relevant?
>
> Sicher nicht, aber ich habe die Diskussion, alles würde sich nur nach C
> richten müssen, auch nicht begonnen.

und dir haben die 2.98% die sich nicht nach C richten gereicht um die 
Diskussion weiter zu befeuern - meinetwegen auch 13.445% aber mehr 
gestehe ich dir da nicht an Relevanz zu :)

von Roland F. (rhf)


Lesenswert?

Hallo,
cppbert3 schrieb:
> und jetzt hört doch bitte auf immer in diesen Micro-Themen zu rotieren

Was sind denn dann für dich "Macro-Themen" über die man diskutieren 
sollte?

rhf

von MaWin (Gast)


Lesenswert?

Roland F. schrieb:
> Was sind denn dann für dich "Macro-Themen" über die man diskutieren
> sollte?

Rust-Macros, zum Beispiel.
Sehr spannendes Thema.

von S. R. (svenska)


Lesenswert?

Ich war jetzt mal ein paar Wochen weg und ein interessanteste Punkt der 
Diskussion war für mich, dass
(a) der Rust-Compiler fehlerfrei ist (d.h. entsprechend der 
Sprachdefinition arbeitet);
(b) die vielen Compilerversionen und -änderungen daher irrelevant sind;
(c) man in Rust garnicht fehlerhaft programmieren kann, weil die Sprache 
Fehler schon vorher verhindert;
(d) die Kompatiblität zu älteren Sprachstandards (nach Spezifikation) 
ausschließlich durch den Compiler sichergestellt wird;
(e) Cargo und Rust überhaupt nichts miteinander zu tun haben.

Ich hab nichts gegen Rust. Nur gegen tightly-coupled-garbage.

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> Nur gegen tightly-coupled-garbage

ja, dann höre bitte damit auf. Danke.

von cppbert3 (Gast)


Lesenswert?

bevor hier wieder alle schreien

https://www.golem.de/news/open-source-entwickler-sabotiert-eigene-vielfach-genutzte-npm-pakete-2201-162299.html

das ist natürlich eine Gefahr - aber ich denke trotzdem das Rust oder 
auch npm oder auch vcpkg dafür einen dauerhaft sinnvolle Lösung finden 
müssen

in diesem Fall ist aber scheinbar ein "verlässlicher" auf die dunkle 
Seite der Macht konvertiert - um so mehr das passiert um so eher gibt es 
sinnvolle Diskussionen wie man automatische und sichere 
Depenency-Management bauen kann

mir ist klar das es keine 100% Lösung gibt, aber vielleicht ergeben sich 
ja zwitter-Strategien die doch ganz gut funktionieren

von MaWin O. (mawin_original)


Lesenswert?

cppbert3 schrieb:
> das ist natürlich eine Gefahr - aber ich denke trotzdem das Rust oder
> auch npm oder auch vcpkg dafür einen dauerhaft sinnvolle Lösung finden
> müssen

Naja, ich glaube diese Lösung, so gut das eben geht, bietet crates.io 
bereits.

Zitat Artikel:
> durch das Löschen von Paketen.

Das geht auf crates.io nicht.

Natürlich ist man grundsätzlich davon abhängig, dass ein Entwickler 
nicht durchdreht und plötzlich Mist baut. Aber auf crates.io gilt das 
nur für neue Versionen. Wenn man bereits eine Version verwendet, dann 
garantiert crates.io, dass genau diese Version dauerhaft und unverändert 
bereitgestellt werden wird. Daran kann auch der Autor nichts ändern.

Das zusammen mit Cargo.lock bedeutet, dass es nicht passieren kann, 
dass die eigene SW sich plötzlich anders verhält oder gar Schadsoftware 
einfließen kann.
Um neue Dependency-Versionen einzupflegen, ist immer eine bewusste 
Interaktion des Entwicklers per cargo update notwendig.

von Unterstrich (Gast)


Lesenswert?

cppbert3 schrieb:
> um so mehr das passiert um so eher gibt es
> sinnvolle Diskussionen wie man automatische und sichere
> Depenency-Management bauen kann

Erst machen - dann denken.

Sehr gut.

von Mombert H. (mh_mh)


Lesenswert?

MaWin O. schrieb:
> Aber auf crates.io gilt das
> nur für neue Versionen. Wenn man bereits eine Version verwendet, dann
> garantiert crates.io, dass genau diese Version dauerhaft und unverändert
> bereitgestellt werden wird. Daran kann auch der Autor nichts ändern.

Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen 
und Urhaberrechte eingehalten werden? Oder wie wird es gehandhabt, wenn 
gegen Rechte verstoßen wird?

von MaWin O. (mawin_original)


Lesenswert?

Mombert H. schrieb:
> Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen
> und Urhaberrechte eingehalten werden?

Ehm, warum sollte es?

> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird?

Das ist, wie immer, das Problem des Autors. Also sollte er so etwas 
nicht tun.

Deine Nebelkerze habe ich als solche erkannt.

von S. R. (svenska)


Lesenswert?

Mombert H. schrieb:
> Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen
> und Urhaberrechte eingehalten werden?

Nein. Es ist Aufgabe des Paketautors, seinen Code zu schreiben, zu 
paketieren und zu veröffentlichen. Das Repository hat damit nichts zu 
tun.

Es ist Aufgabe aller Nutzer des Paketes, das Paket selbst sowie 
sämtliche zukünftigen Updates auf Lizenzverstöße, Fehler, Böswilligkeit 
und andere Rechtswidrigkeiten zu überprüfen, bevor sie in der eigenen 
Software verwendet werden.

Praktisch also ein "update all please", gelegentlich gefolgt von "run my 
testsuite", wie man bei npm gerade schön sieht. (Sind ja nicht alle 
direkt betroffen. Nur viele.)

Dieses Problem (oder ein Äquivalent) besteht grundsätzlich bei allen auf 
schnelle Releasezyklen ausgelegten Systemen. Cargo und crates.io sind da 
nicht besser oder schlechter, und die Grundidee kritisieren zählt in 
großen Teilen der Informatik als Gotteslästerung.

MaWin O. schrieb:
>> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird?
> Das ist, wie immer, das Problem des Autors. Also sollte er so etwas
> nicht tun.

Falsch. Es ist ein Problem des Nutzers des Pakets, nicht des Autors des 
Pakets. Und wenn Pakete tatsächlich nicht gelöscht werden können, dann 
ist das sowieso ein interessantes Phänomen.

Vielleicht brauchen wir, wie von cppbert3 vorgeschlagen, einfach mehr 
Sabotage. Damit kriegen wir die Probleme alle klein.

von DPA (Gast)


Lesenswert?

S. R. schrieb:
> Vielleicht brauchen wir, wie von cppbert3 vorgeschlagen, einfach mehr
> Sabotage. Damit kriegen wir die Probleme alle klein.

Pass auf, was du dir wünschst!

Beitrag "Re: Rust - ist das hier um zu bleiben?"

von MaWin O. (mawin_original)


Lesenswert?

S. R. schrieb:
>> Das ist, wie immer, das Problem des Autors. Also sollte er so etwas
>> nicht tun.
> Falsch. Es ist ein Problem des Nutzers des Pakets, nicht des Autors des
> Pakets.

Falsch?
Es ist vielmehr das Problem des Autors und des Nutzers. Deshalb war 
meine Aussage nicht falsch, sondern richtig.

> und die Grundidee kritisieren zählt in
> großen Teilen der Informatik als Gotteslästerung.

An einer sachlichen Diskussion ist jeder interessiert.

> Dieses Problem (oder ein Äquivalent) besteht grundsätzlich bei allen auf
> schnelle Releasezyklen ausgelegten Systemen. Cargo und crates.io sind da
> nicht besser oder schlechter

Cargo ist auf vieles ausgelegt. Aber mit Sicherheit nicht auf die 
schnelle Änderungen von Dependency-Versionen.
Ganz im Gegenteil. Cargo lockt the Dependency-Versionen, wie ich bereits 
beschrieben habe, fest.

von Mombert H. (mh_mh)


Lesenswert?

MaWin O. schrieb:
> Mombert H. schrieb:
>> Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen
>> und Urhaberrechte eingehalten werden?
> Ehm, warum sollte es?
>> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird?
> Das ist, wie immer, das Problem des Autors. Also sollte er so etwas
> nicht tun.

S. R. schrieb:
> Es ist Aufgabe aller Nutzer des Paketes, das Paket selbst sowie
> sämtliche zukünftigen Updates auf Lizenzverstöße, Fehler, Böswilligkeit
> und andere Rechtswidrigkeiten zu überprüfen, bevor sie in der eigenen
> Software verwendet werden.

Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn 
dort veröffentliche Software gegen geltendes Recht verstößt?

von cppbert3 (Gast)


Lesenswert?

Mombert H. schrieb:
> MaWin O. schrieb:
>> Mombert H. schrieb:
>>> Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen
>>> und Urhaberrechte eingehalten werden?
>> Ehm, warum sollte es?
>>> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird?
>> Das ist, wie immer, das Problem des Autors. Also sollte er so etwas
>> nicht tun.
>
> S. R. schrieb:
>> Es ist Aufgabe aller Nutzer des Paketes, das Paket selbst sowie
>> sämtliche zukünftigen Updates auf Lizenzverstöße, Fehler, Böswilligkeit
>> und andere Rechtswidrigkeiten zu überprüfen, bevor sie in der eigenen
>> Software verwendet werden.
>
> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn
> dort veröffentliche Software gegen geltendes Recht verstößt?

ob crates.io durch sein Verhalten Rechtsbruch begeht hat doch mit der 
Sprache Rust absolut gar nicht zu tun - oder um was geht es dir?

wie handhaben das vpckg, Conan, npm und die vielen anderen Package 
Manager - find das doch mal raus und berichtet hier

von Mombert H. (mh_mh)


Lesenswert?

cppbert3 schrieb:
> Mombert H. schrieb:
>> MaWin O. schrieb:
>>> Mombert H. schrieb:
>>>> Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen
>>>> und Urhaberrechte eingehalten werden?
>>> Ehm, warum sollte es?
>>>> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird?
>>> Das ist, wie immer, das Problem des Autors. Also sollte er so etwas
>>> nicht tun.
>> S. R. schrieb:
>>> Es ist Aufgabe aller Nutzer des Paketes, das Paket selbst sowie
>>> sämtliche zukünftigen Updates auf Lizenzverstöße, Fehler, Böswilligkeit
>>> und andere Rechtswidrigkeiten zu überprüfen, bevor sie in der eigenen
>>> Software verwendet werden.
>> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn
>> dort veröffentliche Software gegen geltendes Recht verstößt?
> ob crates.io durch sein Verhalten Rechtsbruch begeht hat doch mit der
> Sprache Rust absolut gar nicht zu tun - oder um was geht es dir?
Was willst du jetzt mit der Sprache, oder ist cargo und crates.io 
plötzlich doch Teil der Sprache?

> wie handhaben das vpckg, Conan, npm und die vielen anderen Package
> Manager - find das doch mal raus und berichtet hier
Sie werden Pakete, die gegen die Regeln verstoßen, löschen. Aber das 
geht ja laut MaWin auf crates.io nicht.

von cppbert3 (Gast)


Lesenswert?

Mombert H. schrieb:
>> ob crates.io durch sein Verhalten Rechtsbruch begeht hat doch mit der
>> Sprache Rust absolut gar nicht zu tun - oder um was geht es dir?
> Was willst du jetzt mit der Sprache, oder ist cargo und crates.io
> plötzlich doch Teil der Sprache?
>> wie handhaben das vpckg, Conan, npm und die vielen anderen Package
>> Manager - find das doch mal raus und berichtet hier
> Sie werden Pakete, die gegen die Regeln verstoßen, löschen. Aber das
> geht ja laut MaWin auf crates.io nicht.

wenn dich Rust interessiert dann diskutier das Lösch-Problem direkt mit 
den crates.io Leuten ansonsten spar es dir doch mit MaWin zum rum zu 
spielen, was bringt das hier?

von MaWin O. (mawin_original)


Lesenswert?

Mombert H. schrieb:
> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn
> dort veröffentliche Software gegen geltendes Recht verstößt?

Nein. Das hat auch niemand geschrieben.

Mombert H. schrieb:
> Sie werden Pakete, die gegen die Regeln verstoßen, löschen. Aber das
> geht ja laut MaWin auf crates.io nicht.

Nicht von AUTOR selbst löschbar. Lies bitte meine Beiträge richtig.

Selbstverständlich haben die Administratoren von crates.io für den 
absoluten Sonderfall, dass jemand rechtswidriges Material hochlädt, 
immer noch den superuser-Zugriff auf die Datenbank.

von Mombert H. (mh_mh)


Lesenswert?

MaWin O. schrieb:
> Mombert H. schrieb:
>> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn
>> dort veröffentliche Software gegen geltendes Recht verstößt?
> Nein. Das hat auch niemand geschrieben.
> Mombert H. schrieb:
>> Sie werden Pakete, die gegen die Regeln verstoßen, löschen. Aber das
>> geht ja laut MaWin auf crates.io nicht.
>
> Nicht von AUTOR selbst löschbar. Lies bitte meine Beiträge richtig.
Und was passiert, wenn der AUTOR sich and die Administatoren von 
crates.io wendet und sagt, "Ich habe nicht die Rechte an dieser 
Software. Bitte löscht sie."?

von MaWin O. (mawin_original)


Lesenswert?

Mombert H. schrieb:
> Und was passiert, wenn der AUTOR sich and die Administatoren von
> crates.io wendet und sagt, "Ich habe nicht die Rechte an dieser
> Software. Bitte löscht sie."?

Ich weiß es nicht, aber da wird sicher nach vernünftigem menschlichem 
Ermessen drauf reagiert.
Und damit beende ich jetzt diese absolut dümmliche und nicht 
zielführende Diskussion.

von cppbert3 (Gast)


Lesenswert?

@MaWin O.

mich würde interessieren wie du das Thema ABI siehst (die C-ABI können 
wir - deswegen würde ich die mal komplett ausblenden)

-wie könnte eine "echte" Rust-ABI aussehen/was sind Herausforderungen
Kann es eine echte Rust-ABI geben oder wird das genau so ein Problem wie 
mit C++ und dem nicht C-Rest?

-irgendeine Vorstellung wie Dlls/Shared Object (mit nicht gemeinsam 
genutzten (Shared-CRT) Heaps diese Rust-ABI nutzen könnten)
mögliche Herausforderung: Owner-Ship-Transfer ueber Heap-Grenzen?

gibt es da irgendwelche Vorstellungen in der Community?

das Thema "echte" ABI und shared objects wird ja noch relativ stark auf 
"wir können ja C konform sein reduziert"

oder denkst du das Rust eher als Inside/Inline-Implementierung genutzt 
werden wird und es einfach nicht so viel Austausch über die oben 
genannten Grenzen geben wird weil alles direkt verlinkt ist?

von cppbert3 (Gast)


Lesenswert?

ein paar Beispiele was so lange wir nicht von nur ein paar Value-Types 
reden ein Problem ist - z.B. in C++

Lib1(std::vector<x>*) <-> Lib2(std::vector<TypeX>*)
(oder DLLs mit shared Heaps)

Probleme:
-Release/Debug Layout Unterschied beim vector

DLL ohne shared Heaps
Dll1(std::vector<x>*) <-> Dll2(std::vector<TypeX>*)

Probleme:
-Release/Debug Layout unterschied beim vector
-vector delete muss an den richtigen Heap gehen

und solche Sachen

Java und C# usw. haben solchen Probleme nicht weil deren Runtime oder 
die eingeschränkten Generics solche ABI Probleme gar nicht erzeugen 
können, es gibt kein echtes Binary-Linking

von S. R. (svenska)


Lesenswert?

MaWin O. schrieb:
> Es ist vielmehr das Problem des Autors und des Nutzers. Deshalb war
> meine Aussage nicht falsch, sondern richtig.

Es ist mein Problem, fremden Code unverifiziert auszuführen. Ob der 
fremde Code überhaupt da hätte sein dürfen, ist ein separates Problem.

Jemandem, der auf einer gleichrangigen Kreuzung von rechts kommt, muss 
ich die Vorfahrt gewähren - auch dann, wenn er rückwärts und falschrum 
aus einer Einbahnstraße kommt. Dass er das selbst nicht darf, ist nicht 
mein Problem.

Wenn eine Firma ein illegales Paket einbindet und damit Geld verdient, 
dann wird die Firma angeklagt und nicht derjenige, der das Paket 
illegalerweise irgendwo hochgeladen hat. Das fällt unter "due 
diligence".

>> Dieses Problem (oder ein Äquivalent) besteht grundsätzlich bei allen auf
>> schnelle Releasezyklen ausgelegten Systemen. Cargo und crates.io sind da
>> nicht besser oder schlechter
>
> Cargo ist auf vieles ausgelegt. Aber mit Sicherheit nicht auf die
> schnelle Änderungen von Dependency-Versionen.

Besser lesen. Ich schrieb "Releasezyklen". Du hast inzwischen mehrfach 
wiederholt festgestellt, dass Cargo nicht automatisch deine 
Versionsnummern aktualisiert, das ist angekommen.

Aber in der Realität macht man regelmäßig ein Update und fertig ist - 
und genau diesen Schritt vereinfacht Cargo, wie auch jeder andere 
Paketmanager. Oft macht man das Update sogar automatisch (für nightlies, 
wann immer ein Update auftritt, etc.), der Sicherheit(slücken) wegen.

Wir leben in einer Welt, in der Abhängigkeiten oft genug im Lockstep 
aktualisiert werden müssen, damit das Gesamtsystem noch funktioniert. 
Besonders, wenn alle Abhängigkeiten statisch in das Programm geklebt 
werden und ohnehin alles neu gebaut werden muss.

Oder willst du ernsthaft argumentieren, dass man Code nie aktualisieren 
müsste und das deswegen kein Problem ist? Wirklich?

Mombert H. schrieb:
> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn
> dort veröffentliche Software gegen geltendes Recht verstößt?

Nein. Aber vor Gericht landet erstmal der Nutzer der Pakete, der dann 
wiederum crates.io auf Schadensersatz verklagen kann. Ich bin mir 
sicher, das Regelwerk von crates.io wird den Schaden dann an den Autor 
weiterreichen.

Beitrag #6940915 wurde von einem Moderator gelöscht.
von Mombert H. (mh_mh)


Lesenswert?

S. R. schrieb:
> Mombert H. schrieb:
>> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn
>> dort veröffentliche Software gegen geltendes Recht verstößt?
>
> Nein. Aber vor Gericht landet erstmal der Nutzer der Pakete, der dann
> wiederum crates.io auf Schadensersatz verklagen kann. Ich bin mir
> sicher, das Regelwerk von crates.io wird den Schaden dann an den Autor
> weiterreichen.
Du bist dir sicher? Basiert dein sicher auf deinem Bauchgefühl oder kann 
man das irgendwo nachlesen? Also beide Teile, dass der Nutzer zuerst vor 
Gericht landet und dass der Nutzer gegenüber der Plattform einen 
Anspruch auf Schadensersatz hat. Wenn ich mir da z.B. "illegale" 
Tauschbörsen für Musik und Filme angucke, läuft das anders.

von cppbert3 (Gast)


Lesenswert?

S. R. schrieb:
> Aber in der Realität macht man regelmäßig ein Update und fertig ist -
> und genau diesen Schritt vereinfacht Cargo, wie auch jeder andere
> Paketmanager. Oft macht man das Update sogar automatisch (für nightlies,
> wann immer ein Update auftritt, etc.), der Sicherheit(slücken) wegen.

du hast vollkommen recht - Rust Cargo erschafft durch die Einfachheit 
schneller diese Dependency Probleme (auch wenn es kein Autoupgrade gibt)
aber was ist die Antwort auf das Problem? einfach niemals Package 
Systeme einsetzen?

Ich finde der grossen Vorteil ist das ich lokal in meiner Firma mein 
eigenes Repository aufbauen kann (in das ich Prozess-Sicher update) und 
innerhalb meiner Firma ist dann eine "gewisse" Sicherheit da

und ja wir alle arbeiten seit Jahren mit Dependencies und wissen wie das 
geht (von händischen bis selbst-gestricktem CMAke/Batch/Python Scripten 
ist alles probiert und im Einsatz) und welche Fallstricke lauern - aber 
trotzdem finde ich das man das Deployment irgendwie vereinfachen muss - 
auch wenn der aktuelle Cargo Stand vielleicht noch nicht perfekt ist 
finde ich das Cargo eine gute Diskussion-Grundlage bietet um diese 
Punkte für die Zukunft zu verbessern

ganz unabhängig von der Sprache Rust

von cppbert3 (Gast)


Lesenswert?

Mombert H. schrieb:
> S. R. schrieb:
>> Mombert H. schrieb:
>>> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn
>>> dort veröffentliche Software gegen geltendes Recht verstößt?
>>
>> Nein. Aber vor Gericht landet erstmal der Nutzer der Pakete, der dann
>> wiederum crates.io auf Schadensersatz verklagen kann. Ich bin mir
>> sicher, das Regelwerk von crates.io wird den Schaden dann an den Autor
>> weiterreichen.
> Du bist dir sicher? Basiert dein sicher auf deinem Bauchgefühl oder kann
> man das irgendwo nachlesen? Also beide Teile, dass der Nutzer zuerst vor
> Gericht landet und dass der Nutzer gegenüber der Plattform einen
> Anspruch auf Schadensersatz hat. Wenn ich mir da z.B. "illegale"
> Tauschbörsen für Musik und Filme angucke, läuft das anders.

die Antwort ist dann einfach - man darf gar nichts machen, oder?
also kein Cargo kein crates.io - die User müssen das 100% selbst machen

Rechtssicherheit ist ein unklar handhabbares Thema das man nie 
abschließen sauber lösen kann - das ist auch jedem klar - tausend 
Probleme - aber als Lösung einfach gar nichts machen?

was ist das Ziel deiner Kritik?

von cppbert3 (Gast)


Lesenswert?

Microsoft managed in vcpkg auch tausend fremde Dependencies
genau nach dem gleichen Schema wie crates.io
und NPM ist mitlerweile auch von Microsoft - also noch viel mehr solcher 
Dependencies

Ignorieren die deine Sorgen einfach nur deshalb weil die 1000 Anwälte 
drauf werfen können wenn es Probleme gibt?

Einfache Frage: Was macht Microsoft anders als crates.io oder sind die 
einfach genau so unbedarft?

von Mombert H. (mh_mh)


Lesenswert?

cppbert3 schrieb:
> die Antwort ist dann einfach - man darf gar nichts machen, oder?
> also kein Cargo kein crates.io - die User müssen das 100% selbst machen

Das ist ein ziemlich weiter Bogen, den du von MaWins "man kann Pakete 
nicht löschen" zu "man darf garnichts machen" spannst.

cppbert3 schrieb:
> Rechtssicherheit ist ein unklar handhabbares Thema das man nie
> abschließen sauber lösen kann - das ist auch jedem klar - tausend
> Probleme - aber als Lösung einfach gar nichts machen?
Darum ging es mir nie. Es ging immer nur um "man kann nichts löschen"

cppbert3 schrieb:
> was ist das Ziel deiner Kritik?
Welche Kritik meinst du genau?

cppbert3 schrieb:
> Microsoft managed in vcpkg auch tausend fremde Dependencies
> genau nach dem gleichen Schema wie crates.io
> [...]
> Einfache Frage: Was macht Microsoft anders als crates.io oder sind die
> einfach genau so unbedarft?
Ich wusste nicht, dass jeder auf vcpkg.io Pakete veröffentlichen kann. 
Kann man sie dort löschen?

von MaWin O. (mawin_original)


Lesenswert?

cppbert3 schrieb:
> -wie könnte eine "echte" Rust-ABI aussehen/was sind Herausforderungen
> Kann es eine echte Rust-ABI geben oder wird das genau so ein Problem wie
> mit C++ und dem nicht C-Rest?

Ja, das ist ein sehr spannendes und sehr komplexes Thema, von dem ich 
leider viel zu wenig Ahnung habe, um einen qualifizierten Kommentar 
absondern zu können. :)

Aus meinem Bauchgefühl heraus wird eine Library-ABI deutlich 
eingeschränkter sein müssen, als die statisch gebauten 
Crate-Schnittstellen. Ich gehe erst einmal davon aus, dass gar keine 
Compiletime-Ownershiptransfers stattfinden werden, sondern eher etwas 
zur Laufzeit wie Arc/RefCell(+threadsafety).

Wenn du da eine funktionierende Lösung findest, hast du damit sicher das 
Jobticket direkt zu Google und Konsorten gewonnen. ;)

von cppbert3 (Gast)


Lesenswert?

MaWin O. schrieb:
> Wenn du da eine funktionierende Lösung findest, hast du damit sicher das
> Jobticket direkt zu Google und Konsorten gewonnen. ;)

funktionierend ist nicht das Problem - generisch und performant genug 
ist die Herausforderung

von cppbert3 (Gast)


Lesenswert?

Mombert H. schrieb:
> cppbert3 schrieb:
>> Rechtssicherheit ist ein unklar handhabbares Thema das man nie
>> abschließen sauber lösen kann - das ist auch jedem klar - tausend
>> Probleme - aber als Lösung einfach gar nichts machen?
> Darum ging es mir nie. Es ging immer nur um "man kann nichts löschen"

aber was soll MaWin mit dieser Info anfangen - das wäre doch eher was 
für eine Diskussion mit den crates.io Leuten, oder?

MaWin hat mehrfach und deutlich gesagt - es ist noch viel im Fluss - und 
ja nicht alles was crates.io/Cargo macht ist absolut perfekt - das kann 
keine Sprache/Environment sein und so hirnlos kann kein Entwickler sein 
um das zu glauben

aber was du machst ist auf Details rumreiten - auch wenn du das so nicht 
wahrnimmst - und es ist nicht klar zu welchem Zweck du das machst
MaWin juckt deine Argumentation null - und die crates.io/Cargo Leute 
hören sie nur wenn du sie auch dort vorträgst

Selbst wenn du bei MaWin ein Umdenken erreichst hat das immer noch 
nichts mit der Rust Sprache an sich zu tun - und über die will er reden 
- nicht über die Infrastruktur (obwohl die Klarweise wichtig ist - aber 
eben hier und jetzt nicht relevant ist)
und wenn du deine Crate/crates.io Problematik nicht gewillt bist an der 
richtigen Stellen vorzutragen ist das genauso nur verschwendete Zeit

die crates.io Probleme/Strategien sind vollständig entkoppelt von Rust 
als Sprache - auch wenn sie sehr nahe zusammenstehen - aber ob crates.io 
das Prinzip genau so beibehält oder noch x mal ändert ist völlig 
ungewiss

von MaWin O. (mawin_original)


Lesenswert?

cppbert3 schrieb:
> funktionierend ist nicht das Problem - generisch und performant genug
> ist die Herausforderung

Ja, das ist mir schon klar. Das wollte ich damit ausdrücken.

Aber wenn man die Möglichkeiten der ABI einschränkt, sehe ich jetzt 
nicht unbedingt, warum das ein Performanceproblem sein sollte. Alle 
anderen dynamischen Sprachmerkmale 
((A)Rc/RefCell/trait-objects/...etc...) sind ja schließlich auch in der 
Regel kein Performanceproblem. Und wenn doch, dann muss man das Feature 
halt anders implementieren oder statisch linken. Ich würde das erst 
einmal als Sonderfälle kategorisieren.

von Carsten P. (r2pi)


Lesenswert?

Mombert H. schrieb:
> MaWin schrieb:
>> Nop schrieb:
>>> Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt
>>
>> Qualität ist die Abwesenheit von Kundenreklamationen.
>
> Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik.

You made my day! =DDDDDD

Beitrag #6942606 wurde von einem Moderator gelöscht.
Beitrag #6942639 wurde von einem Moderator gelöscht.
Beitrag #6942647 wurde von einem Moderator gelöscht.
Beitrag #6942657 wurde von einem Moderator gelöscht.
Beitrag #6942669 wurde von einem Moderator gelöscht.
von MaWin (Gast)


Lesenswert?

Es gibt eine neue Version:
https://blog.rust-lang.org/2022/01/13/Rust-1.58.0.html

> Captured identifiers in format strings

Sehr nett.
Ein Schritt weiter in Richtung Python-style-f-strings.

> More #[must_use] in the standard library

Sinnvoll. Kann C++ das eigentlich auch? (ohne Compiler-Extension).

von Rolf M. (rmagnus)


Lesenswert?

MaWin schrieb:
>> More #[must_use] in the standard library
>
> Sinnvoll. Kann C++ das eigentlich auch? (ohne Compiler-Extension).

Ja, mit dem Attribut
1
[[nodiscard]]
 Siehe https://en.cppreference.com/w/cpp/language/attributes/nodiscard

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Rolf M. schrieb:
> nodiscard

Super, danke. Kannte ich noch nicht.

von S. R. (svenska)


Lesenswert?

Mombert H. schrieb:
>> Nein. Aber vor Gericht landet erstmal der Nutzer der Pakete, der dann
>> wiederum crates.io auf Schadensersatz verklagen kann. Ich bin mir
>> sicher, das Regelwerk von crates.io wird den Schaden dann an den Autor
>> weiterreichen.
> Du bist dir sicher? Basiert dein sicher auf deinem Bauchgefühl oder
> kann man das irgendwo nachlesen? Also beide Teile, dass der Nutzer
> zuerst vor Gericht landet und dass der Nutzer gegenüber der Plattform
> einen Anspruch auf Schadensersatz hat.

Für ungeeignete Nutzung von Software hat mein Arbeitgeber durchaus schon 
einige Klagen abbekommen (ob gerechtfertigt oder nicht weiß ich nicht). 
Ist halt ein einfaches Ziel. Wo die Software ursprünglich herkam, 
interessierte den Kläger (und die Rechtskosten) dafür erstmal nicht.

Was den Schadenersatz angeht, so schrieb ich was von "verklagen kann", 
nicht von "Anspruch auf Schadensersatz". Vor Gericht und auf hoher See, 
und so.

> Wenn ich mir da z.B. "illegale"
> Tauschbörsen für Musik und Filme angucke, läuft das anders.

In Deutschland gab es vor einigen Jahren ja große Abmahnwellen von 
diversen Anwaltsagenturen, und die gingen auch großflächig gegen die 
Nutzer und nicht gegen die Tauschplattformen. Zumal letztere ein großes 
Interesse daran haben, nicht rechtlich auffindbar zu sein...

cppbert3 schrieb:
> du hast vollkommen recht - Rust Cargo erschafft durch die Einfachheit
> schneller diese Dependency Probleme (auch wenn es kein Autoupgrade gibt)
> aber was ist die Antwort auf das Problem? einfach niemals Package
> Systeme einsetzen?

Abhängigkeiten reduzieren, soweit möglich und sinnvoll. Also nicht "viel 
hilft viel", wie das diese ganzen Paketmanager begünstigen (und 
vermutlich auch wollen, denn daraus folgt deren Existenzberechtigung).

Wenn jede Abhängigkeit erstmal Aufwand ist, dann überlegt man vorher, 
was man tut. Nachdenken kostet Zeit, und wenn die Zeit durch die 
Prozesse hinreichend stark verkürzt wird, dann findet kein Nachdenken 
mehr statt.

Das empfinde ich als ein Problem. Andere wahrscheinlich nicht, denn "der 
Genosse wird sich schon was dabei gedacht haben".

> auch wenn der aktuelle Cargo Stand vielleicht noch nicht perfekt ist
> finde ich das Cargo eine gute Diskussion-Grundlage bietet um diese
> Punkte für die Zukunft zu verbessern

Mit Cargo selbst habe ich keine Probleme, nur mit dessen Grundidee (die 
ebenso auch für alle anderen Paketmanager zutrifft; dass npm 
gelegentlich explodiert, dürfte in erster Linie an dessen extremer 
Verbreitung liegen).

Mein Problem mit Rust heißt aber Cargo, weil das eben keine getrennten 
oder auch nur sinnvoll trennbaren Technologien sind. Genausowenig, wie 
systemd von dem, was dessen Autoren "systemd umbrella" nennen oder wie 
einen C-Präprozessor von einem C-Compiler.

cppbert3 schrieb:
> Ignorieren die deine Sorgen einfach nur deshalb weil die 1000 Anwälte
> drauf werfen können wenn es Probleme gibt?

Ich kann mir gut vorstellen, dass Microsoft solche Probleme allein 
deshalb ignorieren kann, weil sie einerseits genug Anwälte für eine 
kompetente Verteidigung haben und andererseits genug Anwälte und 
Technologien haben, um jeden, der sie plattmachen will, selbst 
plattzumachen.

Das ist übrigens auch der Grund, warum Microsoft vor einigen Jahrzehnten 
anfing, alles was geht zu patentieren (vorher lehnten sie Patente ab und 
ließen auch eher nichts patentieren): Um damit Angreifer plattmachen zu 
können.

> Einfache Frage: Was macht Microsoft anders als crates.io oder sind die
> einfach genau so unbedarft?

Der Unterschied zwischen crates.io, Github, npm oder irgendwas anderem 
ist... in der Hinsicht nicht vorhanden. Die sind allesamt nicht 
Primärziele, was die illegale Nutzung (im Hinblick auf die 
Lizenzbedingungen) angeht.

Sie verbreiten allerdings die Software weiter, was ebenfalls ein Teil 
der Lizenzbedingungen ist - und das prüfen sie durchaus (oder sollten es 
im Eigeninteresse). Github tut das beispielsweise.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> einige Klagen abbekommen
> Anspruch auf Schadensersatz
> Abmahnwellen
> Tauschplattformen
> npm
> C-Präprozessor
> Microsoft
> illegale Nutzung
> Lizenzbedingungen

Es geht hier im Thread um die Programmiersprache Rust.

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
> Es geht hier im Thread um die Programmiersprache Rust.

Ich habe auf mir gestellte Fragen geantwortet.

von MaWin (Gast)


Lesenswert?

Eine neue Rust-Version ist raus:

https://blog.rust-lang.org/2022/02/24/Rust-1.59.0.html

Das neue Hauptfeature wird wohl für die meisten die Stabilisierung von 
inline-assembly sein.
Aber auch available_parallelism ist ganz nett und man ist nicht mehr auf 
die Verwendung von externen Crates an dieser Stelle unbedingt 
angewiesen.

von cppbert (Gast)


Lesenswert?

ich fand die Inline Assembler Syntax am Anfang doch ein wenig 
gewöhnungsbedürftig (im Vergleich zu VC Inline asm unter x86 (unter x64 
geht das ja auch schon nicht mehr))

oder würde man damit auch z.B. solche mehrseitigen SIMD Sin/Cos 
Implementierungen wie z.B. in der glibc inline machen?

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> ich fand die Inline Assembler Syntax am Anfang doch ein wenig
> gewöhnungsbedürftig (im Vergleich zu VC Inline asm unter x86 (unter x64
> geht das ja auch schon nicht mehr))

Ich habe mir die Rust-Asm noch nicht genauer angeschaut.
Deshalb bin ich interessiert daran, welche Kritikpunkte du hast.

Auf den ersten Blick sieht Rust-Asm ja sehr an Gnu-GCC-Asm angelehnt 
aus.
Und die finde ich eigentlich ganz gut. Wenn man einmal die Constraints 
auswendig gelernt und verstanden hat.

> oder würde man damit auch z.B. solche mehrseitigen SIMD Sin/Cos
> Implementierungen wie z.B. in der glibc inline machen?

Klar. Denke schon. Wozu auch sonst? Für Einzeiler gibt es oft 
Intrinsics.

von MaWin (Gast)


Lesenswert?

Rustc-GCC kann sich nun selbst kompilieren:

https://lwn.net/Articles/889989/

> so this work will eventually allow programs to be built for a number of 
architectures that are not supported by rustc

von Jens B. (dasjens)


Lesenswert?

Carsten P. schrieb:
> HabMut schrieb:
>> C Programme beinhalten häufig vermeidbare Sicherheitslücken die die
>> Sicherheit von IT Systemen gefährden.
>
> Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber
> "sicher" keine sicherheitsrelevanten großen Systeme. Ich kenne genau
> einen sehr versierten "plain C"-Entwickler, dem ich meine Bedürfnisse
> nach einer Software anvertrauen würde, und der verwendet eine selbst
> entwickelte GC, da ist nix mit malloc(). strcpy() und free(). Läuft seit
> der ersten Version sogar auf S7-Steuerungen.

GC in Purem C? Wozu
C native auf S7? Zeig mal wie das geht bzw. wo das steht, daß es geht. 
Wäre mir neu.

>
> Traue keiner Runtime ohne verwaltetem Speicher! Und traue gar keinem
> System ohne eine Runtime/einem Framework! Das gilt für Linux wie für
> Windows wie für Android wie für iOS.

Und wo ist der Sinn?
Das ist alles Software und kann tierische Fehler enthalten.
Also sollte man einem Betriebssystem schon mal nicht vertrauen, aber der 
Javaapplikation die darauf läuft schon?

von MaWin (Gast)


Lesenswert?

Rust 1.60.0 ist raus:

https://blog.rust-lang.org/2022/04/07/Rust-1.60.0.html

Punkte, die ich interessant finde:

- Source-based Code Coverage

- (A)Rc::new_cyclic: Verbessert die Handhabung von 
zyklischen/selbstreferenzierenden Datenstrukturen.

- Vec::spare_capacity_mut: Kann ein Effizienzgewinn sein, wenn doppelte 
Initialisierungen vermieden werden können. Benötigt aber wahrscheinlich 
in den meisten (allen?) Fällen auch eine Zeile unsafe-Rust.

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> - Source-based Code Coverage

ich finde es sehr gut das solche Dinge sehr stark integriert werden
(schön wäre jetzt noch ein sehr Kompiler/Toolchain naher Parser und 
Refactoring-Service/Lib/whatever den externe Tools nutzen können)

Contra:
-es fehlen sicherlich dann ein paar Features die in gcov/und anderen 
Tools vorhanden sind - aber wachsen kann es ja jederzeit

Pro:
-egal wie gut oder schlecht - es gibt einen Standard den alle 
rustc/cargo Nutzer gemeinsam haben
-wer mit C/C++, Platform- und Compilerübergreifend viel mit Coverage zu 
tun hat wir sich freuen das es vielleicht möglich ist auf eine gut und 
immer funktionierende Lösung zu kommen

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> (schön wäre jetzt noch ein sehr Kompiler/Toolchain naher Parser und
> Refactoring-Service/Lib/whatever den externe Tools nutzen können)
>
> Contra:
> -es fehlen sicherlich dann ein paar Features die in gcov/und anderen
> Tools vorhanden sind - aber wachsen kann es ja jederzeit

Ich kann dir leider nicht ganz folgen.

Rust coverage basiert auf den Standard-LLVM-Coveragetools.

https://llvm.org/docs/CommandGuide/llvm-profdata.html
https://llvm.org/docs/CommandGuide/llvm-cov.html

von cppbert3 (Gast)


Lesenswert?

Dann ist eher die frage wie der gcc-rustc dann coverage implementieren 
wird und wie schnell sich die beiden compiler angleichen damit man beide 
gleich nutzen kann

In der c/cpp Welt speziell unter Windows gibt es x Lösungen die 
inkompatibel sind und jede Lösung hat irgendeine andere schwäche die 
dann projektbezogen auftreten, eine einheitliche Lösung egal auf welchem 
backend basierend ist da ein grosser Gewinn

von MaWin (Gast)


Lesenswert?

cppbert3 schrieb:
> Dann ist eher die frage wie der gcc-rustc dann coverage implementieren
> wird und wie schnell sich die beiden compiler angleichen damit man beide
> gleich nutzen kann

Ja. Aber die Frage ist dann eher: Was sind die Unterschiede zwischen 
LLVM und GCC, was Coverage angeht? Mit Rust hat das dann erst einmal 
wenig zu tun.

von Oliver S. (oliverso)


Lesenswert?

Carsten P. schrieb:
> Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber
> "sicher" keine sicherheitsrelevanten großen Systeme.

Und wenn das Betriebssystem selber in C geschrieben ist? Und der 
Compiler, den du dazu nutzt, auch?

Das soll es ja gerüchteweise geben ;)

Oliver

von Rolf M. (rmagnus)


Lesenswert?

Oliver S. schrieb:
> Carsten P. schrieb:
>> Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber
>> "sicher" keine sicherheitsrelevanten großen Systeme.
>
> Und wenn das Betriebssystem selber in C geschrieben ist? Und der
> Compiler, den du dazu nutzt, auch?

Ja, es wird gerne vergessen, dass praktisch so gut wie jedes Programm, 
das auf einem Rechner läuft, auf einen Unterbau in C aufsetzt.

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> cppbert3 schrieb:
>> Dann ist eher die frage wie der gcc-rustc dann coverage implementieren
>> wird und wie schnell sich die beiden compiler angleichen damit man beide
>> gleich nutzen kann
>
> Ja. Aber die Frage ist dann eher: Was sind die Unterschiede zwischen
> LLVM und GCC, was Coverage angeht? Mit Rust hat das dann erst einmal
> wenig zu tun.

er geht mir nur darum das ich finde das Rust als Komplettpaket es 
schafft alle Entwickler Feature-Technisch an einen Tisch zu bringen - 
nicht das einfach technisch geht sondern auch dieser 
Vereinheitlichungscharakter

von Le X. (lex_91)


Lesenswert?

Rolf M. schrieb:
> Oliver S. schrieb:
>> Carsten P. schrieb:
>>> Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber
>>> "sicher" keine sicherheitsrelevanten großen Systeme.
>>
>> Und wenn das Betriebssystem selber in C geschrieben ist? Und der
>> Compiler, den du dazu nutzt, auch?
>
> Ja, es wird gerne vergessen, dass praktisch so gut wie jedes Programm,
> das auf einem Rechner läuft, auf einen Unterbau in C aufsetzt.

Auch wenn die Replik inhaltlich richtig ist:
ich sehe das ähnlich wie Carsten P.
Ich verdiene zwar mein Geld mit (systemnaher) C-Programmierung, aber 
Userspace-Programme würde ich ohne Not heute nicht mehr in C schreiben 
wollen.
Man will ja irgendwann auch fertig werden.

von cppbert (Gast)


Lesenswert?

Rolf M. schrieb:
> Oliver S. schrieb:
>> Carsten P. schrieb:
>>> Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber
>>> "sicher" keine sicherheitsrelevanten großen Systeme.
>>
>> Und wenn das Betriebssystem selber in C geschrieben ist? Und der
>> Compiler, den du dazu nutzt, auch?
>
> Ja, es wird gerne vergessen, dass praktisch so gut wie jedes Programm,
> das auf einem Rechner läuft, auf einen Unterbau in C aufsetzt.

das vergisst doch niemand hier in dieser Diskussion
und das selbe haben vorher die Assembler-Programmierer gesagt als C 
eingeführt wurde, und davor noch die, welche Kabeln programmiert 
haben...

Der Spruch kommt von den Java hatern, weil die VM ja auch auf C/C++ 
basiert - aber das trifft hier nur unzureichend weil Rust als 
Systemsprache mit C/C++ auf einer Ebenen steht

es ändert nur nichts an den Pro-Argumenten für Rust - und es juckt 
niemanden ob die Pro-Argumente nicht für alle so gelten, sonst dürfte 
man ja gar nichts schreiben

von Rolf M. (rmagnus)


Lesenswert?

cppbert schrieb:
> Der Spruch kommt von den Java hatern, weil die VM ja auch auf C/C++
> basiert - aber das trifft hier nur unzureichend weil Rust als
> Systemsprache mit C/C++ auf einer Ebenen steht

Es ging darum, dass diese Aussage nicht stimmt:

Carsten P. schrieb:
> Kleine Tools kann man gerne auf jedem OS in C schreiben, aber
> "sicher" keine sicherheitsrelevanten großen Systeme.

Denn in der realen Welt setzt aktuell so gut wie jedes 
sicherheitsrelevante große System auf einen Kern in C auf.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Rolf M. schrieb:
> Denn in der realen Welt setzt aktuell so gut wie jedes
> sicherheitsrelevante große System auf einen Kern in C auf.

Jepp. Und dann passieren halt auch noch z.b. so Schoten, dass es fuer 
polkit
(BLFS-Book: "Polkit is a toolkit for defining and handling 
authorizations. It is used for allowing unprivileged processes to 
communicate with privileged processes.")
 eine javascript-engine braucht (also aktuell ein Teil der 
firefox-sourcen), die dann ihrerseits wieder ein rustc zum Bauen 
braucht...
Und der ganze Kack mit ich-weiss-nicht-wieviel-LOC soll dann sicher 
sein?

Gruss
WK

von MaWin (Gast)


Lesenswert?

Dergute W. schrieb:
> polkit
´
> Und der ganze Kack mit ich-weiss-nicht-wieviel-LOC soll dann sicher
> sein?

Nein. Niemand mit Verstand behauptet, dass polkit gut und/oder sicher 
ist.
Mit Rust - dem Thema des Threads - hat das allerdings nichts zu tun.

von MaWin (Gast)


Lesenswert?

Wer etwas mehr über negative Aspekte von Rust und Cargo lernen möchte, 
ohne gleich in (falsche) Vermutungen und FUD abzudriften, dem kann ich 
diese Lektüre empfehlen:

https://www.bunniestudios.com/blog/?p=6375

von MaWin (Gast)


Lesenswert?

Release: Rust 1.61.0
https://blog.rust-lang.org/2022/05/19/Rust-1.61.0.html

Es scheinen viele Detailänderungen eingegangen zu sein.
Man kann jetzt recht komfortabel mit Termination einen Returncode von 
Main zurückgeben.

von MaWin (Gast)


Lesenswert?

Achja.
Und außerdem funktioniert endlich das AVR8-Target wieder mit der neusten 
nightly-Version.

von Kaj (Gast)


Lesenswert?


von MaWin (Gast)


Lesenswert?

Kaj schrieb:
> Rust-Frontend kommt offiziell in die GCC

Das ist ein ganz wichtiger Schritt. Ohne diesen Schritt ist die breite 
Verwendung besonders auf Nicht-PC-Plattformen nicht denkbar.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Kaj schrieb:
>> Rust-Frontend kommt offiziell in die GCC
>
> Das ist ein ganz wichtiger Schritt. Ohne diesen Schritt ist die breite
> Verwendung besonders auf Nicht-PC-Plattformen nicht denkbar.

Aber da Rust ohne Cargo niemand verwendet, bringt das allein auch nicht 
viel.

IMO ist Rust schon tot. Genau so wie Go.
Kotlin lebt nur noch wegen Android Apps.

Im prof. Embedded Umfeld kommen solche Hypes ohnehin nicht vor. Das ist 
was für Medieninformatiker mit Nebenfach Sportgymnastik.

: Bearbeitet durch User
von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> IMO ist Rust schon tot.

zum Glück haben sich ein paar Linux-Kernel Entwickler bereit erklärt die 
archivarische Aufgabe zu übernehmen - damit man später seinen Kindern 
noch was davon zeigen kann :)

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Aber da Rust ohne Cargo niemand verwendet, bringt das allein auch nicht
> viel.

Wo genau soll das Problem sein?
Man wird Cargo (und alle anderen Tools und Programme) natürlich mit 
gccrs übersetzen können.

von DPA (Gast)


Lesenswert?

Es gibt ja immer noch keinen authoritativen standard, und stattdessen 
wird das clang verhalten dafür missbraucht. Machen gcc und clang was 
anders, macht es also per definition gcc falsch. Gcc ist deshalb dazu 
verdammt, per definition immer die verbuggte hinterherhinkende Version 
zu bleiben. Eine echte Alternative / Konkurrenz, kann es so nicht 
werden. Solange es keinen authoritativen standard gibt, ist das gcc ein 
rust frontend hat, also nur auf dem Papier was wert, in der Praxis aber 
irrelevant.

von MaWin (Gast)


Lesenswert?

DPA schrieb:
> Solange es keinen authoritativen standard gibt, ist das gcc ein
> rust frontend hat, also nur auf dem Papier was wert, in der Praxis aber
> irrelevant.

Genau so, wie alle Python-Implementierungen irrelevant sind, weil es 
keinen "authorativen Standard" gibt?

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


Lesenswert?

MaWin schrieb:
> alle Python-Implementierungen

Mal von Micro-Python abgesehen, gibt es denn da überhaupt mehr als eine 
Implementierung?

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Mal von Micro-Python abgesehen, gibt es denn da überhaupt mehr als eine
> Implementierung?

Dann google doch mal.
Es gibt dutzende große Pythonimplementierungen.

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> DPA schrieb:
>> Solange es keinen authoritativen standard gibt, ist das gcc ein
>> rust frontend hat, also nur auf dem Papier was wert, in der Praxis aber
>> irrelevant.
> Genau so, wie alle Python-Implementierungen irrelevant sind, weil es
> keinen "authorativen Standard" gibt?
Ich weiß nicht wie das anderswo ist. In meinem Arbeitsumfeld ist nur 
CPython relevant. Ich kenne niemanden, der etwas anderes in seinen 
Produkten einsetzt. In den letzten Jahren wurden in mehreren Projekten 
sogar explizit mehrere andere Implementationen vom Kunden verboten.

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


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>> Mal von Micro-Python abgesehen, gibt es denn da überhaupt mehr als eine
>> Implementierung?
>
> Dann google doch mal.
> Es gibt dutzende große Pythonimplementierungen.

"Other Implementations

…

Note that most of these projects have not yet achieved language 
compliance"

Allerdings hat Python zumindest eine Language Reference:

https://docs.python.org/3/reference/index.html

einschließlich einer kompletten Grammatikdokumentation:

https://docs.python.org/3/reference/grammar.html

von Daniel A. (daniel-a)


Lesenswert?

Es gibt auch noch: https://peps.python.org/pep-0000/
Änderungen werden also nicht einfach nur in der Implementierung 
umgesetzt, sondern erstmal vorgeschlagen & diskutiert.

von MaWin (Gast)


Lesenswert?

Daniel A. schrieb:
> Änderungen werden also nicht einfach nur in der Implementierung
> umgesetzt, sondern erstmal vorgeschlagen & diskutiert.

Das ist bei Rust identisch.
Bitte zurück zum Thema.
Hier geht es um Rust.

Jörg W. schrieb:
> Note that most of these projects have not yet achieved language
> compliance"

Dummes Blah.

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


Lesenswert?

MaWin schrieb:
>> Note that most of these projects have not yet achieved language
>> compliance"
>
> Dummes Blah.

Ah ja.

Stammt halt nur aus dem Python-Wiki.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Stammt halt nur aus dem Python-Wiki.

Aus dem C-Python-Wiki. Wieso sollte das eine verlässliche Quelle über 
den Zustand von anderen Implementierungen sein?

Gib deine Rechthaberei bitte auf. Es gibt sehr viele komplette und 
stabile Python-Implementierungen. Ich zähle sie hier bewusst nicht auf, 
weil das Thema des Threads nicht Python ist und das jeder in Google 
finden kann.

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


Lesenswert?

MaWin schrieb:
> Wieso sollte das eine verlässliche Quelle über den Zustand von anderen
> Implementierungen sein?

Weil auch von C-Python letztlich die Sprachdefinition stammt.

Wenn ich jetzt einen Rust-Compiler schreibe und sage, er sei Rust 
compliant, würdest du das als verlässliche Quelle akzeptieren, nur weil 
ich das so sage?

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Wenn ich jetzt einen Rust-Compiler schreibe und sage, er sei Rust
> compliant, würdest du das als verlässliche Quelle akzeptieren, nur weil
> ich das so sage?

Ach komm. Das ist doch dummes Geschwätz.
Du hast weder Ahnung von Python, noch von Rust. Das ist offensichtlich.

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


Lesenswert?

Du musst es ja wissen.

Und nur, weil du dich jetzt aufregst, dass über Python diskutiert wird: 
das war dein Einwand.

: Bearbeitet durch Moderator
von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> das war dein Einwand.

Nein. Ich habe nur einen Vergleich gebracht.
Dass ihr Knalltüten jetzt gleich Python in Frage stellt, hätte ich mir 
allerdings denken können.
Dinge in Frage stellen, von denen man Null Ahnung hat, ist ja euer 
Hobby.

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


Lesenswert?

Du disqualifizierst dich soeben für jegliche ernsthafte Diskussionen.

Rust tust du mit deinem Auftreten gewiss keinen Gefallen.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Rust tust du mit deinem Auftreten gewiss keinen Gefallen.

Wie wäre es denn, wenn du mal wieder zum Thema zurückkommen würdest?

Ich kann nicht sehen, wie ich Rust schade, wenn ich Unwahrheiten über 
Python richtigstelle.

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> Bitte zurück zum Thema.
> Hier geht es um Rust.
MaWin schrieb:
> Genau so, wie alle Python-Implementierungen irrelevant sind, weil es
> keinen "authorativen Standard" gibt?
Hauptsache nicht an die eigenen Regeln halten ;-)

MaWin schrieb:
> Es gibt sehr viele komplette und
> stabile Python-Implementierungen. Ich zähle sie hier bewusst nicht auf,
> weil das Thema des Threads nicht Python ist und das jeder in Google
> finden kann.
Schön, dass es sie gibt, und dass du glaubst, dass sie komplett und 
stabil sind. Aber wer nutzt sie?

von Experte (Gast)


Lesenswert?

Jörg W. schrieb:
> Mal von Micro-Python abgesehen, gibt es denn da überhaupt mehr als eine
> Implementierung?

Einfach mal Google benutzen und ein paar Minuten lesen, wenn man von 
einem Thema schon keine Ahnung hat, ist zu viel verlangt?

Ja, es gibt einige. Auch Du kannst das herausfinden, wenn Du willst, 
trotz Deinem "Moderator"-Emblem.

Jörg W. schrieb:
> Ah ja.
>
> Stammt halt nur aus dem Python-Wiki.

Wenn Du Dir schon fremde Aussagen zu eigen machst, wäre ein Zitat und 
ein Link auf die Quelle angebracht, findest Du nicht auch?

Darüber hinaus, als ob irgendwelche halb-verwaisten Wikis eine besondere 
Relevanz hätten. Einfach auf den jeweiligen Projektseiten nachlesen, 
welchen Stand das jeweilige Projekt hat, übersteigt Dein Interesse?

Jörg W. schrieb:
> Rust tust du mit deinem Auftreten gewiss keinen Gefallen.

Was hat das Verhalten eines Forumsbenutzer mit der Reputation von Rust 
zu tun? So viel wie Dein Verahlten hier mit der Reputation dieses 
Forums?

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


Lesenswert?

Experte schrieb:

>> Stammt halt nur aus dem Python-Wiki.
>
> Wenn Du Dir schon fremde Aussagen zu eigen machst, wäre ein Zitat und
> ein Link auf die Quelle angebracht, findest Du nicht auch?

Weißt du, wofür die Anführungszeichen gut sind? Bestimmt nicht, um mir 
etwas "zu eigen" zu machen.

Den Link kann man doch ganz einfach herausfinden, indem man das Zitat 
bei Google einkippt. Das ist die Methode, die ihr mir nahe gelegt habt.

https://wiki.python.org/moin/PythonImplementations

> Darüber hinaus, als ob irgendwelche halb-verwaisten Wikis eine besondere
> Relevanz hätten.

Was bringt dir das, auf so einem Niveau zu diskutieren? Habe ich (oder 
jemand anders hier) irgendwo die Projektseiten von Rust als 
"halb-verwaist" diffamiert?

Leute, auf dem Niveau bedarf es wohl keiner weiteren Diskussionen.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Was bringt dir das, auf so einem Niveau zu diskutieren?

Jörg, ich respektiere dich sehr als Experten auf dem Gebiet C und AVR-C.
Aber von Rust und Python hast du offensichtlich leider keinerlei Ahnung. 
Das zeigst du hier leider sehr eindrucksvoll.

Wenn hier über

> Niveau

geredet wird, dann solltest du es auch selbst einhalten.
Effektiv zu behaupten von Python gäbe es nur eine einzige breit genutzte 
vollständige Implementierung, ist einfach nur lächerlich. Deine Aussagen 
hier beweisen nur, dass du noch nie mit Python und Rust gearbeitet hast, 
was über ein Hello World oder ein schnell dahingehacktes Script 
hinausgeht.

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


Lesenswert?

MaWin schrieb:
> Effektiv zu behaupten von Python gäbe es nur eine einzige breit genutzte
> vollständige Implementierung, ist einfach nur lächerlich.

Ich habe getan, was du empfohlen hast, und danach gegoogelt. Da bin ich 
beim Python-Wiki rausgekommen, welches dann jemand hier als 
"halb-verwaist" diffamiert.

Was soll das?

> Deine Aussagen
> hier beweisen nur, dass du noch nie mit Python und Rust gearbeitet hast,
> was über ein Hello World oder ein schnell dahingehacktes Script
> hinausgeht.

Du irrst, gewaltig, was Python angeht.

Über Rust habe ich nichts geschrieben.

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
> Effektiv zu behaupten von Python gäbe es nur eine einzige breit
> genutzte vollständige Implementierung, ist einfach nur lächerlich.

Wir können uns darauf einigen, dass es eine (oder vielleicht zwei) 
Standardimplementation gibt sowie viele weitere, die nur in ihren Ecken 
des Internets verbreitet sind.

> Deine Aussagen hier beweisen nur, dass du noch nie mit Python
> und Rust gearbeitet hast, was über ein Hello World oder ein schnell
> dahingehacktes Script hinausgeht.

Deine Aussagen beweisen auch nicht viel mehr.
Nur, dass du mehr Zeit für Diskussionen übrig hast.

Merkt man z.B. an sowas:

MaWin schrieb:
> Dass ihr Knalltüten jetzt gleich Python in Frage stellt, hätte ich mir
> allerdings denken können.

Riecht nach unpassendem Diskussionsstil.

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> Wir können uns darauf einigen

Nein. Weil es Quatsch ist.

> Riecht nach unpassendem Diskussionsstil.

Ich möchte überhaupt nicht über Python diskutieren, sondern hatte es nur 
als Vergleich angebracht. Und damit beende ich mein Mitwirken an der 
Python-Diskussion hier.

Hier geht es um Rust.

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
> Hier geht es um Rust.
Nun gut, dann können wir ja auch wieder zum Anfang der Diskussion - 
diesmal ohne Python-Vergleich - zurückkehren:

DPA schrieb:
> Es gibt ja immer noch keinen authoritativen standard, und
> stattdessen wird das clang verhalten dafür missbraucht.
> Machen gcc und clang was anders, macht es also per definition
> gcc falsch. Gcc ist deshalb dazu verdammt, per definition
> immer die verbuggte hinterherhinkende Version zu bleiben.
> Eine echte Alternative / Konkurrenz, kann es so nicht
> werden. Solange es keinen authoritativen standard gibt,
> ist das gcc ein rust frontend hat, also nur auf dem Papier
> was wert, in der Praxis aber irrelevant.

Also?

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> Also?

Es ist halt völliger Unsinn.
Keinerlei Begründung und ich soll jetzt die Gegenbegründung finden?
Na gut.

> stattdessen wird das clang verhalten dafür missbraucht.

Kannst du es vielleicht mal ausführen, was "das clang-Verhalten" 
überhaupt sein soll?
Was hat clang überhaupt mit Rust zu tun? Meinst du LLVM?
Welche Teile von Rust sind nur so, weil LLVM das vorgibt?
Und warum ist das ein Missbrauch?

S. R. schrieb:
> macht es also per definition gcc falsch

Richtig. Wo ist das Problem?

> immer die verbuggte [...] zu bleiben.

Warum?
Können GCC-Entwickler keine Bugs fixen?

> Solange es keinen authoritativen standard gibt,
> ist das gcc ein rust frontend hat, also nur auf dem Papier
> was wert, in der Praxis aber irrelevant.

Wie kommst du zu der Schlussfolgerung?

von DPA (Gast)


Lesenswert?

MaWin schrieb:
> Wie kommst du zu der Schlussfolgerung?

Hab ich doch schon asführlich aufgeführt.

Das llvm rustc Ding ist authoritativ.
Szenario: gcc und rustc machen was anders.
Resultat: Per definition muss rustc der compiler sein, der es richtig 
macht, und gcc der Compiler, der den Bug hat.

Die Programme werden natürlich auch das rustc verhalten voraussetzen. 
Ausserdem, jede Änderung und Erweiterung heist, dass beide Compiler was 
anders machen, also gcc was falsch macht.
Wie man es auch dreht und wendet, gcc kann so nicht relevant werden, und 
kann niemals besser als clang sein, per definition. Wenn es nicht 
relevant werden kann, ist es in der Praxis irrelevant.

Das folgt alles logisch daraus, dass das llvm rustc Ding authoritativ 
ist, und eben nicht ein Standard. Es ist im vornherein als perfekt 
festgelegt, und perfekter als perfekt kann man halt nicht werden.

Ich hoffe, diesmal konntest du mir folgen. Ich habe die ganze logik 
Kette a also b also c, nochmal angegeben. Aber ich kann dich natürlich 
nicht zwingen, den Gedankengang nachzuvollziehen.

von MaWin (Gast)


Lesenswert?

DPA schrieb:
> Resultat: Per definition muss rustc der compiler sein, der es richtig
> macht, und gcc der Compiler, der den Bug hat.

Richtig. Wo ist das Problem?

> Die Programme werden natürlich auch das rustc verhalten voraussetzen.

Richtig. Wo ist das Problem?

> Ausserdem, jede Änderung und Erweiterung heist, dass beide Compiler was
> anders machen, also gcc was falsch macht.

Richtig. Ansonsten implementiert GCC nicht Rust, sondern etwas anderes.
Das können sie gerne machen, aber dann ist es nicht Rust.
Gccrs wollen Rust implementieren.

Wo ist das Problem?

> gcc kann so nicht relevant werden

Warum? Ich verstehe nicht, wie du das schlussfolgern kannst.
Wenn gccrs 99% von rustc's Verhalten implementiert, dann sind sie 
relevant.
Wieso sollten sie es nicht sein?

> kann niemals besser als clang sein, per definition.

(Was hat clang hier wieder zu suchen?)
GCC kann nur besser sein, wenn sie etwas implementieren, was nicht Rust 
ist?
Das ist gar nicht das Ziel von gccrs.
Sie wollen Rust implementieren.

> Das folgt alles logisch daraus, dass das llvm rustc Ding authoritativ
> ist,

Richtig. Wo ist das Problem?

> Es ist im vornherein als perfekt festgelegt

Nein, das ist nicht richtig.
Rust enthält sehr viele nicht implementierte Dinge und auch viele 
undefinierte Dinge (unstable).
Und das ist im Entwicklungsprozess ziemlich gut eingebettet.
Bei diesen Dingen hat dann weder rustc noch gccrs "recht". Aber wenn 
gccrs Rust implementieren will, dann werden sie sich mit den rustc 
Entwicklern abstimmen müssen.
Wo ist das Problem?

> Ich hoffe, diesmal konntest du mir folgen.

Leider nicht. Ich sehe nicht, wo hier der Nachteil bei gccrs sein soll 
und warum es deshalb zum Scheitern verurteilt sein soll.

Nach deiner Logik dürfte es immer nur einen Standard und/oder eine 
Sprachimplementierung geben.
Das ist doch Unsinn.
In der Praxis sind die wenigsten Sprachen offiziell standardisiert.
Trotzdem sind sie erfolgreich und es gibt oft mehrere Implementierungen.

Ich glaube ihr habt eher Angst vor Umbrüchen und Neuem.
Rust ist hier. Und es wird nicht wieder gehen, nur weil ihr die Augen 
verschließt.
Gccrs ist ein weiterer wichtiger Schritt dieses zu manifestieren.

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


Lesenswert?

MaWin schrieb:
> Ich glaube ihr habt eher Angst vor Umbrüchen und Neuem.

Nein.

Die Kritik ist nicht daran, dass es die Sprache gibt und dass Leute sie 
verwenden (ich kenne auch ganz persönlich jemanden, der davon begeistert 
ist). (Ja, es gibt hier auch Leute, die der Meinung sind, die würde 
nichts taugen. Ich gehöre nicht dazu, und auch die Kritik von DPA 
behauptet nicht sowas.)

Die Kritik ist, dass sie es bis heute nicht geschafft haben, eine 
formale Definition aufzuschreiben. Es gibt eine "Reference", aber die 
schreibt gleich als erstes, dass sie "incomplete" ist, und eine formale 
Definition will sie gar nicht sein. So ist das alles irgendwie mit 
Beispielen beschrieben statt mit einer formalen Syntax. Auch steht da 
sowas drin:

"Finally, this book is not normative. It may include details that are 
specific to rustc itself, and should not be taken as a specification for 
the Rust language. We intend to produce such a book someday, and until 
then, the reference is the closest thing we have to one."

Das ist, was DPA meinte: rustc ist damit de facto das Normativ.

Sicher war das auch mit C eine Weile so, dass es nur einen 
implementierten Compiler gab. Der war aber auch vor 50 Jahren (kannst du 
bei Dennis Ritchie nachschlagen) bereits begleitet von einer formalen 
Sprachbeschreibung. Es konnte also jemand anders nur auf Basis der 
Beschreibung einen eigenen Compiler (oder anderweitigen Parser) 
schreiben. Aus alldem konnte man schließlich (ja, hat auch eine Weile 
gedauert) einen wohldefinierten Standard ableiten.

Nochmal: ich gehe durchaus davon aus (auf der Basis dessen, was ich von 
anderen gehört habe), dass die Sprache Potenzial hat. Aber wenn man eine 
Sprache implementiert, die eine gewisse Bedeutung bekommen soll, dann 
muss man sich auch dem formalen Kram widmen und nicht nur neue Features 
hacken. Python ist da (wie ich oben mal schrieb) weiter. OK, ist auch 
älter, ist akzeptiert.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Die Kritik ist, dass sie es bis heute nicht geschafft haben, eine
> formale Definition aufzuschreiben.

Ja gut. Das ist richtig.
Damit reiht Rust sich in 99% aller Sprachen ein.
Scheint wohl kein allzu großes Problem zu sein.

Für welche Sprachen gibt es überhaupt eine offizielle Standardisierung?

Python, Matlab. Alles Sprachen kurz vor dem Bankrott. Niemand verwendet 
sie. Denn sie haben ja keine offizielle Standardisierung.

Unsinn.

> Sicher war das auch mit C eine Weile so

Ach? Das ist ja ein Ding.
Und trotzdem ist C so erfolgreich?
Wie kommt denn das?
Ist ja völlig unmöglich.

> Der war aber auch vor 50 Jahren

Das ist ja ein Ding. Und jetzt rechne mal nach, wie alt moderne Sprachen 
wie Rust sind.
Und dann rechne einmal nach, wann C seinen ersten Standard bekam.

> dann muss man sich auch dem formalen Kram widmen

Gut. Dann ist ja alles in Butter. Die Rust-Entwicklung ist einem starken 
formellen Prozess unterlegen.

> und nicht nur neue Features hacken.

Passiert nur in deine Fantasie.

> Python ist da (wie ich oben mal schrieb) weiter.

Unsinn. Befasse dich einmal bitte mit der Rust-Entwicklung, bevor du sie 
bewertest.
Danke.

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
> Für welche Sprachen gibt es überhaupt eine offizielle Standardisierung?

Recht viele, auch wenn die nicht überall öffentlich von einem 
Standardisierungsgremium abgesegnet worden ist.

> Python, Matlab. Alles Sprachen kurz vor dem Bankrott. Niemand verwendet
> sie. Denn sie haben ja keine offizielle Standardisierung.

Nun, das Debakel um Python 2 und Python 3 tat ihrer Beliebtheit nun ganz 
sicher nicht helfen (und wir hadern damit noch immer). Eine sehr 
bekannte Sprache, der ihre fehlende Standardisierung - und damit die 
normative Macht der Implementation - zum Verhängnis geworden ist, wäre 
Perl. So aus der Ferne sieht das bei PHP ähnlich aus, und beide Sprachen 
sind inzwischen mehr tot als lebendig.

> Das ist ja ein Ding. Und jetzt rechne mal nach,
> wie alt moderne Sprachen wie Rust sind.
> Und dann rechne einmal nach, wann C seinen ersten Standard bekam.

Die formale Definition von C ist wesentlich älter als ihr erster 
Standard. Und zumindest ich trenne auch noch zwischen der 
Standardbibliothek und der Sprachdefinition selbst, aber da gibt es 
sicher auch andere Ansichten.

> Gut. Dann ist ja alles in Butter.
> Die Rust-Entwicklung ist einem starken
> formellen Prozess unterlegen.

Und am Ende des Prozesses steht ein "der Compiler hat Recht".

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> Und am Ende des Prozesses steht ein "der Compiler hat Recht".

Ziemlicher Quatsch.
Wie wäre es, wenn ihr euch Rust und den Entwicklungsprozess einmal 
anschaut?

von Rolf M. (rmagnus)


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>> Die Kritik ist, dass sie es bis heute nicht geschafft haben, eine
>> formale Definition aufzuschreiben.
>
> Ja gut. Das ist richtig.
> Damit reiht Rust sich in 99% aller Sprachen ein.
> Scheint wohl kein allzu großes Problem zu sein.
>
> Für welche Sprachen gibt es überhaupt eine offizielle Standardisierung?

Es gibt auch noch was zwischen kar keiner Definition der Sprache und 
einem ISO-Standard.

> Python, Matlab. Alles Sprachen kurz vor dem Bankrott. Niemand verwendet
> sie. Denn sie haben ja keine offizielle Standardisierung.

Sie haben aber eine formale Definition.

>> Python ist da (wie ich oben mal schrieb) weiter.
>
> Unsinn. Befasse dich einmal bitte mit der Rust-Entwicklung, bevor du sie
> bewertest.

Hier ist die formale Definition von Python:
https://docs.python.org/3/reference/index.html
Wo ist das Äquivalent für Rust?

: Bearbeitet durch User
von Jemand (Gast)


Lesenswert?

Rolf M. schrieb:
> Hier ist die formale Definition von Python:

> I chose to use English rather than formal specifications for everything except 
syntax and lexical analysis. This should make the document more understandable to 
the average reader, but will leave room for ambiguities. Consequently, if you were 
coming from Mars and tried to re-implement Python from this document alone, you 
might have to guess things and in fact you would probably end up implementing 
quite a different language. [...] If you would like to see a more formal 
definition of the language, maybe you could volunteer your time — or invent a 
cloning machine :-).

"formale Spezifikation"

von Rolf M. (rmagnus)


Lesenswert?

Jemand schrieb:
> [...]

Lustig, dass du gerade den Satz übersprungen hast:

"On the other hand, if you are using Python and wonder what the precise 
rules about a particular area of the language are, you should definitely 
be able to find them here."

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


Lesenswert?

MaWin schrieb:

> Damit reiht Rust sich in 99% aller Sprachen ein.

Nein.

> Für welche Sprachen gibt es überhaupt eine offizielle Standardisierung?

Es ging nicht um offizielle Standardisierung, sondern wenigstens mal 
selbst eine formale Sprachdefinition aufzuschreiben.

Python beispielsweise hat sowas, habe ich dir geschrieben.

Es geht auch nicht um "kurz vor dem Bankrott", sondern darum, dass sowas 
eine sinnvolle Basis dafür ist, dass jemand anders eine unabhängige 
Implementierung vornimmt.

Aber du drehst uns die Worte im Munde rum, für dich sind wir die Bösen, 
die nur das neue scheuen, nur weil wir nicht 100 % in deine Lobpreisung 
einstimmen. Das ist keine Diskussionsbasis.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> nur weil wir nicht 100 % in deine Lobpreisung einstimmen.

Meine Lobpreisung existiert nur in deiner Fantasie.

Ich sehe durchaus die Schwächen von Rust und habe das auch schon 
mehrfach hier geschrieben.
Und ja, das Fehlen einer vollständigen formellen Sprachdefinition ist 
ein Teil davon.
Ich stimme euch lediglich nicht dabei zu, dass das ein riesiges Problem 
ist.

> Python beispielsweise hat sowas, habe ich dir geschrieben.

Das ist genau so unvollständig, wie die Dokumentation von Rust.
Trotzdem ist Python extrem erfolgreich.
Komisch, gell?

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


Lesenswert?

MaWin schrieb:
> Ich stimme euch lediglich nicht dabei zu, dass das ein riesiges Problem
> ist.

Das Thema kam nur im Zusammenhang damit hoch, dass den Thread jemand 
wieder hochgeholt hat um zu erzählen, dass das jetzt in GCC drin ist.

Für eine unabhängige Compiler-Implementierung ist es vielleicht nicht 
ein "riesiges" Problem, aber zumindest aus Sicht mehrerer Leute hier 
durchaus ein Problem.

Um nicht mehr und nicht weniger ging es.

> Das ist genau so unvollständig, wie die Dokumentation von Rust.

Kann gut sein, aber es ist ein Anfang, den Rust (an der Stelle) sich 
noch nicht die Mühe gemacht hat zu gehen. Eine derartige 
Unvollständigkeit würde natürlich wiederum erklären, warum die 
Alternativ-Implementierungen teilweise eben auch in der Vollständigkeit 
hinter CPython hinterher hinken – womit indirekt bewiesen ist, dass eine 
fehlende saubere und vollständige formale Beschreibung eben für 
alternative Implementierungen durchaus ein Problem sein kann.

Wie geschrieben: darum, ob die Sprache selbst nun gut oder schlecht oder 
brauchbar ist oder nicht, ging's hier gerade gar nicht.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> aber es ist ein Anfang, den Rust (an der Stelle) sich
> noch nicht die Mühe gemacht hat zu gehen.

Das ist natürlich auch mal wieder Quatsch.

Die Rust Features werden alle in Issues/RFCs beschrieben und entwickelt.
Und es gibt auch Bücher, die diese Informationen zusammentragen.

https://doc.rust-lang.org/stable/unstable-book/the-unstable-book.html
https://rustc-dev-guide.rust-lang.org/getting-started.html
https://doc.rust-lang.org/nomicon/

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> darum, ob die Sprache selbst nun gut oder schlecht oder
> brauchbar ist oder nicht,

Ach. Das ist ja ein Ding. Da muss ich mich wohl falsch erinnern.
Mal sehen...

Cyblord -. schrieb:
> IMO ist Rust schon tot.

Ach, wohl doch nicht.

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


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>> darum, ob die Sprache selbst nun gut oder schlecht oder
>> brauchbar ist oder nicht,
>
> Ach. Das ist ja ein Ding. Da muss ich mich wohl falsch erinnern.
> Mal sehen...

Was schmeißt du fremde Zitate in meine Argumentation?

Klar gibt es Doku, hat keiner bestritten. Aber der Ansatz, einen 
alternativen Compiler zu entwickeln, geht halt normalerweise nicht über 
das Studium von Prosa oder gar Sourcecode eines anderen Compilers, 
sondern über eine formale Sprachdefinition.

Wenn es die nicht gibt, wird der alternative Compiler irgendwie immer 
der zweite Sieger bleiben. Mehr war hier nicht als Argumentation (wenn 
man von solchen Blasen absieht, wie du zitiert hast – ich weiß bloß 
nicht, warum du dich über solcherart begründungslos hingeworfene 
Meinungsäußerungen derart aufregst).

: Bearbeitet durch Moderator
von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Was schmeißt du fremde Zitate in meine Argumentation?

Weil nicht nur du und ich an der Diskussion teilnahmen.

Der zitierte Satz war der Ausgangspunkt der ganzen Diskussionskette, 
deren Teil auch du bist.

> Aber der Ansatz, einen
> alternativen Compiler zu entwickeln, geht halt normalerweise nicht über
> das Studium von Prosa oder gar Sourcecode eines anderen Compilers,
> sondern über eine formale Sprachdefinition.

Offensichtlich geht es halt doch auch anders.

> Wenn es die nicht gibt, wird der alternative Compiler irgendwie immer
> der zweite Sieger bleiben.

Für dich.
Und das darfst du gerne so sehen.
Ich sehe das anders.

> ich weiß bloß
> nicht, warum du dich über solcherart begründungslos hingeworfene
> Meinungsäußerungen derart aufregst).

Wo genau rege ich mich auf?

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
>> Wenn es die nicht gibt, wird der alternative Compiler irgendwie immer
>> der zweite Sieger bleiben.
>
> Für dich.
> Und das darfst du gerne so sehen.
> Ich sehe das anders.

Du hast ja schon mehrfach (Auch gerade wieder im benachbarten Thread 
Beitrag "Komplexe typedef struct mit 0 initialisieren") gezeigt, dass du dich 
nicht wirklich dafür interessierst, wie die Sprache etwas definiert. 
Hauptsache der Compiler schluckt es.

von MaWin O. (mawin_original)


Lesenswert?

Mombert H. schrieb:
> Auch gerade wieder im benachbarten Thread

Kannst du bitte aufhören hier den Thread zuzumüllen?
Danke.

von cppbert (Gast)


Lesenswert?

Wo kommt denn bitte diese ganze altmodische, absolutistische (Ein 
Standard, Ein Kompiler, Ein Entscheider) Denkweise her?
Es ist doch keines der komplexen Systeme die wir heute verwenden so 
enstanden?
Und der Entwicklungsprozess war deswegen nicht besser oder schlechter - 
das ist eben Evolution in komplexen Systemen - und dazu zählen auch 
Programmiersprachen

bestes Beispiel die Programmiersprache(n): C/C++ - von der wir 
hoffentlich alle Wissen das sie einer doch noch immer einflussreichsten 
Sprachen der Welt ist

Es gab über Jahrzehnte nur ein paar Player auf dem Kompilermarkt - 
Microsoft, GCC, Intel, ... die waren auch alle gar nicht so super 
kompatible - jeder hat sich so weit wie möglich am Marktstärksten (nicht 
unbedingt am Standard) orientiert, Microsoft hat Micro-Details in "sein" 
C++ eingebaut wo es nur ging

das waren Jahrzehnte des unklaren driftens - da war die Frage immer erst 
"Mit welchem C++ Kompiler wurde das gebaut"

Und wer die Erfahrung nicht gemacht hat weil zu Jung oder nicht in dem 
Business war kann hier so gut wie gar keinen Senf zu abgeben

und das C++ Konsortium konnte das so gut wie nicht unter kontrolle 
halten

dann kam der LLVM/Clang - das Geschrei war laut - "noch ein Kompiler, 
noch mehr Probleme, können wir uns nicht auf einen konzentrieren, 
Blababla..."

aber es kam auch:
-der LLVM/Clang wurde so gut das der GCC mal wieder kämpfen musste und 
wieder besser wurde
-beide haben sich unglaublich beschleunigt in besserer Diagnose, Support 
von neueren Standards, weniger Sonderfeatures die wirklich nicht sind 
portierbar sind und,und,und
-selbst Microsoft musste sich dem ganzen beugen und hat wieder richtig 
konstruktiv begonnen an der Sprache und dem Kompilern mitzuarbeiten

das alles weil "nur" ein neuere Kompiler aufgetaucht ist - ohne Clang 
wäre das wohl alles nicht passiert

niemand der offenen Auges durch die C/C++ Branche wandelt kann das nur 
im entfernsteten Bestreiten - die letzten Jahren sind wirklich 
erstaunlich
weil endlich mal wieder richtige Evolution passiert ist - der geistige 
GCC "Fork" machte Konkurrenz und hat den Markt einfach mal wieder wach 
gerüttelt

das ist typische evolutionäre Entwicklung wie sie für komplexe System 
nötig ist - das schadet nicht - dauert nur länger als wenn der einzge 
König/Firma/Konsortium von oben die perfekten Vorgaben macht - die 
Systeme sind viel zu umfangreich geworden als das so etwas nur noch im 
Ansatz sinnvoll funktioniert - und das haben alle Grossen der Branche 
schon lange verstanden und arbeite (Achtung Buzword) "Agil" an Lösungen 
- so lange bis sich der richtige Standard durch Leistung und Überleben 
herauskristalisiert, bis der auch wieder unrelevant wird

die meisten Argumente sind völlig sinnfrei weil sich sowiso die Systeme 
durchsetzen die passen - ob UNS das dann immer passt ist eine andere 
Frage

und ein Sprachstandard in der 1. Stunde hat auch Javascript nicht 
verhindern können :)

von cppbert (Gast)


Lesenswert?

und die besten Flitzpiepen sind die welche Denken das sich Linus und 
Greg Kroah-Hartman und andere unbedacht eine Sprache in ihren Kernel 
holen die dann ihr Lebenswerk verschlechtert

so Idioten-Argumente wie:
-ob die wissen das Rust gar nicht mit dem gcc kompiliert werden kann
-das Cargo dann alle Kernel-Dependecies dann aus dem Internet holen muss
-man doch lieber go nehmen sollte
usw.

das ist so unglaublich naiv das es schon weh tut

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> das ist so unglaublich naiv das es schon weh tut

So ist das halt, wenn man sich für den größten Sprachexperten der Welt 
hält.
Da werden dann schon einmal gerne Sprachen totgesagt, die weltweit 
gerade steil gehen. Was dem Mikrocontroller.net-Experten nicht gut genug 
ist, kann auch nix sein.

> -ob die wissen das Rust gar nicht mit dem gcc kompiliert werden kann
> -das Cargo dann alle Kernel-Dependecies dann aus dem Internet holen muss

Exakt dies. Diese zwei Fragen wurden vor Jahren bereits von den 
Kernelexperten diskutiert und verstanden.

von cppbert (Gast)


Lesenswert?

oder

jetzt wo der Linus das erstmal eine andere Programmiersprache für den 
Kernel präsentiert bekommt ist er blöderweise anr Rust geraten, der kann 
das bestimmt null einschätzen - die anderen beteiligten bestimmt auch 
nicht - die wurden bestimmt überredet, so hilflos...

das ist mehr oder minder der überspitzte Inhalt der meisten Diskussionen
- als hätten die Kernel-Entwickler so mehr oder minder zufällig ~30Mio 
Zeilen Code zusammengeschraubt die unsere Welte mehr oder minder am 
Laufen hält :)

von cppbert (Gast)


Lesenswert?

mehr oder minder

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> Exakt dies. Diese zwei Fragen wurden vor Jahren bereits von den
> Kernelexperten diskutiert und verstanden.

dieses Argument schlägt alle Rekorde - es ist seit Jahren unrelevant 
weil man es machen kann wie man will - und die Kernel-Leute machen das 
auch so

aber es kommt immer und immer und immer wieder hoch

von cppbert3 (Gast)


Lesenswert?

Und der fehlende Sprachstand juckt Microsoft, Amazon und x andere null, 
nicht mal das GCC Steering Committee interessiert das

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


Lesenswert?

MaWin schrieb:
> Wo genau rege ich mich auf?

"Dummes Blah.", "ihr Knalltüten" – bestimmt findet sich noch mehr.

Unterstellte Lernunwilligkeit: "Ich glaube ihr habt eher Angst vor 
Umbrüchen und Neuem.", obwohl man was ganz anderes kritisiert.

cppbert schrieb:
> Es gab über Jahrzehnte nur ein paar Player auf dem Kompilermarkt -
> Microsoft, GCC, Intel

Es gab deutlich mehr, du beschreibst nur die PC-Welt. Fängt ja schon 
damit an, dass C++ als erstes durch CFront implementiert worden war, 
initial völlig außerhalb der PC-Welt.

Die anderen waren und sind auch nicht so schräg drauf wie beispielsweise 
Microsoft, die erst nach Jahrzehnten überhaupt mal einen neuen Standard 
akzeptieren können. Bis auf notwendigerweise nicht von einem Standard 
abdeckbare Dinge (wie Interrupts) konnte und kann man beispielsweise 
klaglos Programme für Microcontroller von GCC und IAR compilieren 
lassen.

Die C++-Welt mag da mit ihrem Featurismus anders ticken, für C ist die 
Entwicklung eher langsam vonstatten gegangen. Aber natürlich, 
Entwicklung gab es immer, und der übliche Weg bei internationalen 
Standards ist es, dass das Standardisierungsgremium Dinge übernimmt, die 
sich bereits in der Praxis bewährt haben, statt sich Dinge selbst 
auszudenken. Trotzdem gab es da immer eine gemeinsame Basis, die recht 
gut beschrieben war und ist (und das auch schon vor dem ersten 
C-Standard, sonst hätte es beispielsweise einen GCC nie geben können – 
der kam zwei Jahre vor dem ersten offiziellen Standard heraus).

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> sonst hätte es beispielsweise einen GCC nie geben können –
> der kam zwei Jahre vor dem ersten offiziellen Standard heraus

Was? Das ist ja ungeheuerlich!
Wie kann das sein? Das ist doch völlig unmöglich Compiler ohne Standard 
zu entwickeln, habe ich hier gelernt.

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> cppbert schrieb:
>
>> Es gab über Jahrzehnte nur ein paar Player auf dem Kompilermarkt -
>> Microsoft, GCC, Intel
>
> Es gab deutlich mehr, du beschreibst nur die PC-Welt.

Ja das hatte ich vergessen zu erwähnen, aber das ist ja auch ein grosser 
Teil des Markts

> Die C++-Welt mag da mit ihrem Featurismus anders ticken, für C ist die
> Entwicklung eher langsam vonstatten gegangen. Aber natürlich,
> Entwicklung gab es immer, und der übliche Weg bei internationalen
> Standards ist es, dass das Standardisierungsgremium Dinge übernimmt, die
> sich bereits in der Praxis bewährt haben, statt sich Dinge selbst
> auszudenken. Trotzdem gab es da immer eine gemeinsame Basis, die recht
> gut beschrieben war und ist (und das auch schon vor dem ersten
> C-Standard, sonst hätte es beispielsweise einen GCC nie geben können –
> der kam zwei Jahre vor dem ersten offiziellen Standard heraus).

Bei C ist das auch viel einfacher weil die Sprach recht ausdrucksschwach 
ist, ganz neutral ausgedrueckt

Wenn es in der Praxis keine guten Lösungen gibt muss man sich neues 
ausdenken, auch wenn viele gar keine Probleme sehen die man angreifen 
sollte/könnte

Es hört sich leider oft so an als würden hier viele glauben das ein zur 
zeit nicht bestehender Standard automatisch irgendwie zu Chaos führt der 
irgendwie nicht mehr kontrollierbar wäre, genauso wie ein zweiter 
Kompiler, das ist zu drastisch gedacht und Realitätsfern, wer sollte 
interesse an sowas haben und zu welchem Zweck (mal die Schattenregierung 
ausser vor gelassen)

Wie gesagt das GCC Steering Comittee stört das gerade nicht sonderlich 
und viele andere auch nicht, wiso sind die nicht so kritisch?

von cppbert3 (Gast)


Lesenswert?

cppbert3 schrieb:
> auch wenn viele gar keine Probleme sehen die man angreifen sollte/könnte

Das ist ungefähr der selbe Prozentsatz der auch keine Sanitizer braucht 
oder nutzt :)

von cppbert3 (Gast)


Lesenswert?

cppbert3 schrieb:
> cppbert3 schrieb:
>
>> auch wenn viele gar keine Probleme sehen die man angreifen sollte/könnte
>
> Das ist ungefähr der selbe Prozentsatz der auch keine Sanitizer braucht
> oder nutzt :)

Was nicht bedeutet das logische Fehler nicht auch ein grosser Teil der 
üblichen Fehler sind

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


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>> sonst hätte es beispielsweise einen GCC nie geben können –
>> der kam zwei Jahre vor dem ersten offiziellen Standard heraus
>
> Was? Das ist ja ungeheuerlich!
> Wie kann das sein? Das ist doch völlig unmöglich Compiler ohne Standard
> zu entwickeln, habe ich hier gelernt.

Du hast bis jetzt den Unterschied zwischen einer formalen 
Sprachdefinition und einem (irgendwie "offiziellen", ISO oder was auch 
immer) Standard noch nicht verstanden, obwohl dir nun bereits mehrere 
Leute versucht haben, diesen zu verdeutlichen.

Dafür titulierst du andere als Knalltüten und was weiß ich nicht was.

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> Du hast bis jetzt den Unterschied zwischen einer formalen
> Sprachdefinition und einem (irgendwie "offiziellen", ISO oder was auch
> immer) Standard noch nicht verstanden, obwohl dir nun bereits mehrere
> Leute versucht haben, diesen zu verdeutlichen.
> Dafür titulierst du andere als Knalltüten und was weiß ich nicht was.

Weil hier die Leute so auf Microdetails achten und dann darauf rumreiten

Und nochmal das GCC Steering Committee stört es nicht, warum jemanden 
hier?
Oder besser warum ist das nur hier ein Argument?

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


Lesenswert?

cppbert3 schrieb:
> Oder besser warum ist das nur hier ein Argument?

Ob das "nur hier" eins ist, weiß ich nicht. Ich habe auch keine Idee, 
was die GCC-Leute so bewegt und was sie als Kriterien für irgendwelche 
Frontends haben. Schätzungsweise wird die aktuell erlangte Popularität 
von Rust schon dazu beigetragen haben, das dort offiziell mit 
aufzunehmen.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Du hast bis jetzt den Unterschied zwischen einer formalen
> Sprachdefinition und einem (irgendwie "offiziellen", ISO oder was auch
> immer) Standard noch nicht verstanden, obwohl dir nun bereits mehrere
> Leute versucht haben, diesen zu verdeutlichen.

Ahh. Jetzt verstehe ich!
Diese formale Sprachdefinition ist also der Teil, der eine erfolgreiche 
Sprache von einem Fehlschlag unterscheidet. Endlich erklärt mir das mal 
jemand.

Jetzt solltet ihr das auch noch Mozilla, Linus, Microsoft und vielen 
anderen Stümpern erklären.

> Dafür titulierst du andere als Knalltüten und was weiß ich nicht was.

Ich bitte um Entschuldigung.
Ich wusste bisher nicht, dass Mozilla, Linus, Microsoft und die vielen 
anderen Stümper in Wahrheit die merkbefreiten Knalltüten sind und nicht 
die Mitglieder des Mikrocontroller.net-Forums.

cppbert3 schrieb:
> Weil hier die Leute so auf Microdetails achten und dann darauf rumreiten

So ist das nun einmal, wenn man sich mit der Materie nicht auskennt. 
Dann pickt man sich irgendein Detail raus und reitet darauf herum und 
erklärt den gccrs mal eben für gescheitert.

Jörg W. schrieb:
> Ob das "nur hier" eins ist, weiß ich nicht.

Das kann ich dir auch nicht sagen.
Aber für Mozilla, Linus, Microsoft und die vielen anderen Stümper, ist 
es offenbar kein Argument.

Jörg W. schrieb:
> Schätzungsweise wird die aktuell erlangte Popularität
> von Rust schon dazu beigetragen haben

Wie kam es überhaupt zu dieser Popularität? So ganz ohne formale 
Sprachdefinition.

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> cppbert3 schrieb:
>
>> Oder besser warum ist das nur hier ein Argument?
>
> Ob das "nur hier" eins ist, weiß ich nicht. Ich habe auch keine Idee,
> was die GCC-Leute so bewegt und was sie als Kriterien für irgendwelche
> Frontends haben. Schätzungsweise wird die aktuell erlangte Popularität
> von Rust schon dazu beigetragen haben, das dort offiziell mit
> aufzunehmen.

gilt das deiner Meinung nach auch für den Linux-Kernel?

Was sagt das über die Entscheidungsqualtät der an diesen Projekten 
beteiligten Personen aus?

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


Lesenswert?

MaWin schrieb:

> Diese formale Sprachdefinition ist also der Teil, der eine erfolgreiche
> Sprache von einem Fehlschlag unterscheidet.

Du erzählst schon wieder völligen Unfug, um mal mit deinen Worten zu 
reden – vielleicht verstehst du so eine Sprache ja besser, denn keiner 
(von den ernsthaften Diskutanten) hat behauptet, dass Rust ein 
Fehlschlag sei.

Mit dir zu diskutieren, erweist sich wiederholt schlicht als sinnlos, du 
drehst alles so herum, dass du dich maximal drüber aufregen kannst. Ich 
sollte meine Zeit besser darauf verwenden, was Vernünftiges zu tun, 
vielleicht endlich mal wieder VHDL anzusehen zum Beispiel. Das wäre mir 
beispielsweise aktuell wichtiger als Rust.

von cppbert3 (Gast)


Lesenswert?

Und ja MaWin kann patzig sein, ihr seit das aber auch irgendwie, GUT IST

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


Lesenswert?

cppbert3 schrieb:

> gilt das deiner Meinung nach auch für den Linux-Kernel?

Beides dürfte miteinander im Zusammenhang stehen. Linux möchte GCC 
(während bspw. Apple extra den Clang gepusht hat, um von GCC 
wegzukommen), und für GCC ist es wiederum ein wesentliches 
Anwendungsfeld.

ps: Andererseits ist natürlich für Linux ein anwendungsfähiger Compiler 
das wesentliche Kriterium, nicht irgendeine formale Sprachdefinition, 
das ist wohl keine Frage. Dürfte im Gegenzug den Druck auf GCC erhöht 
haben, sich der Sprache zu widmen.

: Bearbeitet durch Moderator
von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> MaWin schrieb:
>
>> Diese formale Sprachdefinition ist also der Teil, der eine erfolgreiche
>> Sprache von einem Fehlschlag unterscheidet.
>
> Du erzählst schon wieder völligen Unfug, um mal mit deinen Worten zu
> reden – vielleicht verstehst du so eine Sprache ja besser, denn keiner
> (von den ernsthaften Diskutanten) hat behauptet, dass Rust ein
> Fehlschlag sei.

Das sagt er nur überspitzt und alle anderen reagieren wieder mit 
Microdetails, das kann sehr wirklich nervig sein, was leider auch ein 
wenig typisch für das Forum ist

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


Lesenswert?

cppbert3 schrieb:
> Das sagt er nur überspitzt

Naja, andere würden es als sehr persönliche Beleidigung empfinden, wenn 
sie als "Knalltüten" bezeichnet werden, nur weil sie eine andere Meinung 
haben als er.

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> cppbert3 schrieb:
>
>> Das sagt er nur überspitzt
>
> Naja, andere würden es als sehr persönliche Beleidigung empfinden, wenn
> sie als "Knalltüten" bezeichnet werden, nur weil sie eine andere Meinung
> haben als er.

Du machst es schon wieder, lass doch dieses Satz-Sezieren, das ist 
deiner unwürdig

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> du drehst alles so herum

Ich verdrehe hier die Tatsachen? Sehr interessante Sichtweise.

> dass du dich maximal drüber aufregen kannst.

Wie bereits mehrfach gesagt: Ich rege mich hier überhaupt nicht auf. Ich 
amüsiere mich prächtig.

> Du erzählst schon wieder völligen Unfug

Ach. Sag bloß. Könnte das daran liegen, dass das nicht ganz ernst 
gemeint war und bewusst so formuliert war?

cppbert3 schrieb:
> Das sagt er nur überspitzt und alle anderen reagieren wieder mit
> Microdetails,

Du hast es gut erkannt. ;)

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> cppbert3 schrieb:
>
>> gilt das deiner Meinung nach auch für den Linux-Kernel?
>
> Beides dürfte miteinander im Zusammenhang stehen. Linux möchte GCC
> (während bspw. Apple extra den Clang gepusht hat, um von GCC
> wegzukommen), und für GCC ist es wiederum ein wesentliches
> Anwendungsfeld.
> ps: Andererseits ist natürlich für Linux ein anwendungsfähiger Compiler
> das wesentliche Kriterium, nicht irgendeine formale Sprachdefinition,
> das ist wohl keine Frage. Dürfte im Gegenzug den Druck auf GCC erhöht
> haben, sich der Sprache zu widmen.

Ich finde es wiederum erstaunlich wie wenig Frontend man nur braucht um 
ins main repo zu kommmen, aber trotzdem ist es gut, das wird 
schlussendlich eine Menge mehr Entwickler an die Sprache bringen, sie 
muss gequält werden damit was gutes entstehen kann

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>
>> du drehst alles so herum
>
> Ich verdrehe hier die Tatsachen? Sehr interessante Sichtweise.

Du musst aber auch mal aufhören Öl ins Feuer zu schütten :)

von MaWin (Gast)


Lesenswert?

cppbert3 schrieb:
> aber trotzdem ist es gut, das wird
> schlussendlich eine Menge mehr Entwickler an die Sprache bringen, sie
> muss gequält werden damit was gutes entstehen kann

Genau so ist es.

Alles dies wird passieren.
Was garantiert nicht passieren wird ist das, was hier im Forum 
postuliert wird.
Gccrs wird nicht die zweite unbedeutende Geige spielen.
Gccrs wird nicht in endlosen Grabenkämpfen zu strict aliasing ertrinken.

Es wird Meinungsverschiedenheiten geben. Und das ist etwas Gutes! Denn 
nur durch das Lösen von Meinungsverschiedenheiten kann wirkliche 
Weiterentwicklung entstehen.

Das gilt auf für Forumsmitglieder. Die "guten alten Zeiten", wo man sich 
erst einmal um eine formale Sprachdefinition kümmerte, sind vorbei. 
Genauer gesagt, gab es diese Zeiten nie.
Moderne Sprachen sind so komplex, dass es erst einmal wichtiger ist sie 
praktisch nutzbar zu machen, als irgendein furztrockenes Dokument zu 
erstellen, das niemandem weiterhilft.

Und falls ihr dennoch der Meinung seid, dass man jetzt direkt eine 
Sprachdefinition braucht: Rust ist Open Source. Also bitte.
Oder ihr müsst euch von dieser Denkweise lösen.

von cppbert3 (Gast)


Lesenswert?

Schon wieder Öl, wenn auch nur in Tropfen

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> Gccrs wird nicht in endlosen Grabenkämpfen zu strict aliasing ertrinken.

Dann bekommt der gcc auch mal endlich die Möglichkeit über x Versionen 
strict aliasing Fehler im Kompiler zu finden, genau so wie der LLVM 
leiden musste

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


Lesenswert?

cppbert3 schrieb:
> das wird schlussendlich eine Menge mehr Entwickler an die Sprache
> bringen

Da vermute ich, dass der Einfluss von Linux größer ist als der von GCC.

Den Leuten, die die Sprache benutzen wollen, ist das vermutlich 
mittelmäßig egal, solange es mindestens einen brauchbaren (und freien) 
Compiler gibt, die könn(t)en also auch ohne GCC prima damit arbeiten. 
Die Affinität zu einem bestimmten Compiler hat ja eher religiöse, äh, 
lizenzpolitische Gründe (Apple -> kein GPL, Linux -> unbedingt GPL).

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> Die Affinität zu einem bestimmten Compiler hat ja eher religiöse, äh,
> lizenzpolitische Gründe (Apple -> kein GPL, Linux -> unbedingt GPL).

Das schon aber sehr lange Zeit war der Kernel aber auch voll mit GCC 
Spezialitäten (so viel zu wohldefinierten Standards), ich glaube es ist 
immer nicht so einfach den Kernel mit Clang zu bauen, oder

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
> Jetzt solltet ihr das auch noch Mozilla, Linus, Microsoft und vielen
> anderen Stümpern erklären.

Ich wäre gern die Fliege an der Wand, wenn du Linus ins Gesicht als 
Stümper bezeichnest...

> Dann pickt man sich irgendein Detail raus und reitet darauf herum und
> erklärt den gccrs mal eben für gescheitert.

Gescheitert ist das falsche Wort. Aber der Einfluss - außerhalb von 
Linux - dürfte wesentlich geringer bleiben, bis es eine Spezifikation 
gibt.

> Wie kam es überhaupt zu dieser Popularität?
> So ganz ohne formale Sprachdefinition.

Wie bei Javascript, ebenfalls eine der besten Programmiersprachen, die 
dieser Planet jemals hervorgebracht hat.

Jörg W. schrieb:
> Den Leuten, die die Sprache benutzen wollen, ist das vermutlich
> mittelmäßig egal, solange es mindestens einen brauchbaren (und freien)
> Compiler gibt, die könn(t)en also auch ohne GCC prima damit arbeiten.

Viele Sprachen haben nur genau einen relevanten Compiler (bzw. alle 
anderen sind effektiv Forks - mangels gebrauchbarer Spezifikation) und 
sie werden trotzdem benutzt.

Wer sich in die Abhängigkeit begeben will, den kann man daran nicht 
hindern. Suizid ist schließlich auch nicht strafbar.

> Die Affinität zu einem bestimmten Compiler hat ja eher religiöse, äh,
> lizenzpolitische Gründe (Apple -> kein GPL, Linux -> unbedingt GPL).

Nicht nur, die Geldflüsse wären da auch zu betrachten. Wo das Geld in 
Massen hinströmt, da wollen alle anderen auch hin. Erstmal anstellen, 
wenn man eine Warteschlange sieht, egal warum.

von S. R. (svenska)


Lesenswert?

cppbert3 schrieb:
> Das schon aber sehr lange Zeit war der Kernel aber auch voll mit GCC
> Spezialitäten (so viel zu wohldefinierten Standards), ich glaube es ist
> immer nicht so einfach den Kernel mit Clang zu bauen, oder

Der Kernel hat aber auch nie behauptet, in C geschrieben zu sein.
Und er wird sicher auch nie behaupten, in Rust geschrieben zu sein.
Aus den gleichen Gründen.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Den Leuten, die die Sprache benutzen wollen, ist das vermutlich
> mittelmäßig egal, solange es mindestens einen brauchbaren (und freien)
> Compiler gibt, die könn(t)en also auch ohne GCC prima damit arbeiten.

Nein. Es gibt ganz praktische Vorteile von GCC. Beispielsweise das enorm 
viel breitere Spektrum an unterstützten Architekturen. Das bedeutet zwar 
nicht, dass Gccrs automatisch auch alle diese unterstützt, aber es 
bereitet die notwendige Basis dafür.

Das ist der Schlüssel für Rust-Embedded.

> Linux -> unbedingt GPL

Die Bindung von Linux an GCC hat rein technische Gründe.
Sie fußt in der enormen Nutzung von GCC-Extensions in Linux.
Das Linux-clang-Projekt ist (war? Ich weiß den aktuellen Zustand nicht) 
ein enorm großes Projekt.

von MaWin (Gast)


Lesenswert?

Achja, falls das hier manchen nicht klar ist:

GCC + Rust gibt es in zwei Varianten.
1) Rust-Frontend in GCC. Darum ging es hier im Gespräch hauptsächlich.
2) GCC als codegen backend von rustc.

Beide werden aktiv entwickelt und beide sind wichtig für die Sprache.
(1) ist ein eigenständiges Projekt und (2) ist (wird) Teil vom 
ursprünglichen Rust-Compiler.

von cppbert3 (Gast)


Lesenswert?

S. R. schrieb:
> MaWin schrieb:
>
>> Jetzt solltet ihr das auch noch Mozilla, Linus, Microsoft und vielen
>> anderen Stümpern erklären.
>
> Ich wäre gern die Fliege an der Wand, wenn du Linus ins Gesicht als
> Stümper bezeichnest...

Alles nur halb zu lesen ist hier echt Standard im Forum, es ging darum 
das Linus Rust im Kernel akzeptiert und da Rust ja nicht gut ist es nur 
an Linus schlechtigkeit liegen kann das er die Sprache akzeptiert

Nur damit auch du es peilst: MaWin ist Pro Rust UND Pro Linux/Linus :)

von cppbert3 (Gast)


Lesenswert?

S. R. schrieb:
> cppbert3 schrieb:
>
>> Das schon aber sehr lange Zeit war der Kernel aber auch voll mit GCC
>> Spezialitäten (so viel zu wohldefinierten Standards), ich glaube es ist
>> immer nicht so einfach den Kernel mit Clang zu bauen, oder
>
> Der Kernel hat aber auch nie behauptet, in C geschrieben zu sein.
> Und er wird sicher auch nie behaupten, in Rust geschrieben zu sein.
> Aus den gleichen Gründen.

Und mit diese Microrelevanzaussage konter ich jetzt wie?

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


Lesenswert?

cppbert3 schrieb:
> ich glaube es ist immer nicht so einfach den Kernel mit Clang zu bauen

Clang hat allerdings von vornherein überall versucht, ein kompletter 
GCC-Ersatz zu sein und von daher auch allerlei GCC-Erweiterungen 
übernommen.

MaWin schrieb:
> Es gibt ganz praktische Vorteile von GCC. Beispielsweise das enorm viel
> breitere Spektrum an unterstützten Architekturen.

Ja, sicher, aber die, die jetzt Rust einsetzen, werden das 
schätzungsweise vorranging auf solchen Architekturen tun, für die es 
llvm-Backends gibt. llvm-Backends gibt's ja schließlich auch für alles 
Mögliche inzwischen.

Im "deeply embedded" (also echte Microcontroller, keine miniaturisierten 
Allroundmachinen wie Raspberry etc.) hat man ja schon Mühe, mal jemanden 
zu finden, der wenigstens C++ akzeptieren würde. Sehe ich in den 
diversen Jobs meiner letzten Jahre, selbst an Stellen, wo ein OO-Ansatz 
durchaus günstig wäre, findet man kaum Kundschaft, der das als Argument 
für C++ ausreichend ist. Bis Rust dort ankommt (und damit jenseits 
dessen, was llvm als Backends hat), wird noch 'ne Menge Wasser Rhein und 
Elbe herunter fließen.

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


Lesenswert?

MaWin schrieb:
> Das Linux-clang-Projekt ist (war? Ich weiß den aktuellen Zustand nicht)
> ein enorm großes Projekt.

Interessanterweise schien bei FreeBSD der Aufwand doch recht 
überschaubar. Bei denen ist nun schon seit einigen Jahren Clang als 
Standard dabei – und ein Kernel hat logischerweise auch dort 'ne ganze 
Reihe von Compiler-Erweiterungen benutzt.

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> Clang hat allerdings von vornherein überall versucht, ein kompletter
> GCC-Ersatz zu sein und von daher auch allerlei GCC-Erweiterungen
> übernommen.

Trotzdem hat es Jahre gedauert bis das richtig ging

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> und ein Kernel hat logischerweise auch dort 'ne ganze
> Reihe von Compiler-Erweiterungen benutzt.

Linux nutzt wesentlich mehr GCC-Spezialitäten als BSD. Linux verwendet 
auch GCC-Plugins.
Die Grundfunktionalität (ein funktionierendes Linux-System) lässt sich 
schon länger mit clang erzeugen. Aber alle Features gingen zumindest bis 
vor ein paar Jahren noch nicht. Wie es aktuell ist, weiß ich nicht.

Jörg W. schrieb:
> Clang hat allerdings von vornherein überall versucht, ein kompletter
> GCC-Ersatz

Die Worte "überall" und "kompletter" würde ich hier weglassen und durch 
sowas wie "weitgehend" ersetzen.
Selbst auf ABI-Ebene ist LLVM nicht vollständig kompatibel. (128Bit 
Integers). Was aber eher als ein Bug angesehen wird.

Jörg W. schrieb:
> Ja, sicher, aber die, die jetzt Rust einsetzen, werden das
> schätzungsweise vorranging auf solchen Architekturen tun, für die es
> llvm-Backends gibt.

Auch für die Leute, die jetzt Rust einsetzen, bringt jeder weitere 
Compiler nur Vorteile. Second Source. Bessere Sprachdefinition. Bessere 
Testabdeckung.

> llvm-Backends gibt's ja schließlich auch für alles
> Mögliche inzwischen.

Es kommt auch auf die Qualität der Backends an. Das AVR-Backend in clang 
ist nicht wirklich gut. Da will man GCC haben (Ja, das ist vielleicht 
ein schlechtes Beispiel, weil GCC-AVR auch nicht mehr wirklich 
weiterentwickelt wird. Aber besser als clang ist es).

Jörg W. schrieb:
> Bis Rust dort ankommt (und damit jenseits
> dessen, was llvm als Backends hat), wird noch 'ne Menge Wasser Rhein und
> Elbe herunter fließen.

Das ist richtig. Aber das ist kein Problem, was Rust lösen kann. Das 
muss sich in den Betonköpfen der Nutzer-Projektentscheider lösen.
C++ wäre ein Schritt in die richtige Richtung. Aber bitte mit wenig OOP. 
Sonst muss man die wieder abtrainieren, wenn man zu Rust wechselt ;)

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
> Nein. Es gibt ganz praktische Vorteile von GCC. Beispielsweise das enorm
> viel breitere Spektrum an unterstützten Architekturen. Das bedeutet zwar
> nicht, dass Gccrs automatisch auch alle diese unterstützt, aber es
> bereitet die notwendige Basis dafür.

Alternativ portiert man diese Architekturen nach LLVM. Das ist wegen der 
GPL sowieso der bevorzugte Weg für viele Firmen, wenn sie den Aufwand 
überhaupt treiben wollen.

> Die Bindung von Linux an GCC hat rein technische Gründe.
> Sie fußt in der enormen Nutzung von GCC-Extensions in Linux.

Ja und nein. Clang will aus lizenztechnischen Gründen ein vollwertiger 
Ersatz sein und implementiert daher auch alle relevanten GCC-Extensions. 
Technische Gründe gibt es daher keine mehr, und die politischen Gründe 
werden auch weniger, weil viel Geld in bestimmte Richtungen fließt.

> Das Linux-clang-Projekt ist (war? Ich weiß den aktuellen
> Zustand nicht) ein enorm großes Projekt.

Sämtliche Android-Kernel werden ausschließlich mit Clang gebaut. Google 
hat außerdem die letzten Jahre sehr viel (erfolgreich) investiert, um 
die Unterschiede zum Mainline-Kernel zu reduzieren.

Dazu kommt, dass so gut wie alle Mitstreiter am Kernel heutzutage dafür 
bezahlt werden. Ein großer Teil der betroffenen Firmen kommen aus dem 
Embedded-Bereich und dort ist Android-Kompatiblität wichtig. Also baut 
der Code auch mit clang (und dessen Forks) bzw. wird nur damit getestet.

Das von dir genannte Projekt war vor allem deswegen kompliziert, weil 
(a) clang damals einige GCC-Extensions nicht kannte; (b) der Kernel 
nicht nur GCC-Extensions benutzt, sondern auch gezielt GCC-Verhalten 
ausgenutzt hat; (c) der Kernel "fix clang-issue"-Patches ablehnt, wenn 
sie keine Bugs fixen oder die Performance mit GCC sinkt.

cppbert3 schrieb:
> Nur damit auch du es peilst: MaWin ist Pro Rust UND Pro Linux/Linus :)

Ich bin nicht doof. MaWin ist einfach nur der bessere Troll. :(

cppbert3 schrieb:
>> Der Kernel hat aber auch nie behauptet, in C geschrieben zu sein.
>> Und er wird sicher auch nie behaupten, in Rust geschrieben zu sein.
>> Aus den gleichen Gründen.
>
> Und mit diese Microrelevanzaussage konter ich jetzt wie?

Warum willst du da kontern? Linux ist schlicht nicht in C geschrieben, 
sondern in (einem Subset von) GCC-C. Portabilität und 
Compilerabhängigkeit sind schlicht irrelevant.

Clang implementiert auch GCC-C (identifiziert sich auch als GNU-C), weil 
Google (und andere) dafür gesorgt haben. Deswegen ist es trotzdem kein 
C, aber in der Lage, den Kernel zu bauen.

Ich sehe keinen Grund, warum der Kernel das Thema Rust irgendwie anders 
handhaben sollte. Der Rust-Code im Kernel wird kein echtes Rust sein, 
sondern schlicht GCC-Rust (oder Kernel-Rust oder wie man das nennen 
mag). Inwieweit die auseinander laufen oder sogar inkompatibel 
zueinander werden, werden wir in der Zukunft sehen.

Jörg W. schrieb:
> Interessanterweise schien bei FreeBSD der Aufwand doch recht
> überschaubar. Bei denen ist nun schon seit einigen Jahren Clang als
> Standard dabei – und ein Kernel hat logischerweise auch dort 'ne ganze
> Reihe von Compiler-Erweiterungen benutzt.

FreeBSD (wie auch die Geschwister) hat ein eigenes Interesse, von 
GPL-Abhängigkeiten wegzukommen, nicht zuletzt durch Apple.

Viel habe ich nicht in BSD-Code geblättert, aber was ich gesehen habe, 
hat mir im Allgemeinen recht gut gefallen und sah auch stärker nach 
Standard-C aus als der Linux-Code. Entsprechend dürfte die Abhängigkeit 
auch schwächer (besser abstrahiert) gewesen sein.

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


Lesenswert?

S. R. schrieb:

> FreeBSD (wie auch die Geschwister) hat ein eigenes Interesse, von
> GPL-Abhängigkeiten wegzukommen, nicht zuletzt durch Apple.

Apple hat zwar mal den Anfang mit FreeBSD gemacht, aber macht seither 
sein eigenes Ding. Insofern ist FreeBSD (und insbesondere dessen 
verwendeter Compiler) für sie kaum relevant. Kommt hinzu, dass der 
Kernel eh Mach ist und kein BSD.

> Viel habe ich nicht in BSD-Code geblättert, aber was ich gesehen habe,
> hat mir im Allgemeinen recht gut gefallen und sah auch stärker nach
> Standard-C aus als der Linux-Code. Entsprechend dürfte die Abhängigkeit
> auch schwächer (besser abstrahiert) gewesen sein.

Das ist gut möglich, hat durchaus auch historische Gründe. BSD wollte 
schon immer portabel sein (und NetBSD ist daraus entstanden, weil Bill 
Jolitz teilweise auf Portabilität verzichtet hatte, um auf der von ihm 
anvisierten 80386-Plattform besser/schneller voran zu kommen), der Code 
war damit auch vor 30 Jahren schon sehr generisch. Linux war erstmal nur 
80386, und hat sich von da aus zu einem portablen System entwickelt. 
(Als ich vor Jahrzehnten mal in deren Floppytreiber geschaut habe, war 
beispielsweise sowas wie der DMA-Kanal fix per #define reincompiliert. 
In einem 386BSD hätte man auch damals schon mehr als einen 
Floppycontroller mit verschiedenen Hardwareparametern installieren 
können.)

von Ron T. (rontem)


Lesenswert?

Cyblord -. schrieb:
> Die Komplexität in der SW Entwicklung entsteht nicht durch die
> Programmiersprache.

Die Sprache hat sogar entscheidenden Einfluss. Und weil die 
sprachbedingte Komplexität über die Jahrzehnte so ausartet wird kaum 
eine der genannten Sprachen richtig Zukunft haben. Die gehört schlicht 
anderer Hardware inklusive intelligenterer Programmierformen- um hier 
mal KI ins Gedächtnis zu rufen.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Ron T. schrieb:
> um hier mal KI ins Gedächtnis zu rufen.

KI als Lösung zur Komplexitätsreduktion. Wow. Echt gut getrollt.

von rbx (Gast)


Lesenswert?

Steam macht einen echt netten Service für Skyrim. Die installierten Mods 
werden immer wieder "automagisch" auf den neuesten Stand gebracht. Diese 
Mods haben aber immer bestimmte eigene Probleme, da kann Steam nicht 
viel machen. Man ist gut beraten, jedes einzelne Mod für sich 
auszuprobieren, um fatale Veränderungen wirklich mitzubekommen. Viele 
bevorzugen aber ein 300 Mod Setup zum Start - aus welchem Grund auch 
immer - denn die "Vanilla" Version, also Skyrim ohne Mods ist schon 
toll. Mit vielen Mods als Standard kann man erstmal nicht so gut sehen, 
wenn man Probleme hat, wo sie herkommen.
Dann gibt es noch in der normalen Vanillaversion gewisse Probleme, aber 
man kann einiges mit dem Creation Kit und den Glitches abfangen bzw. 
ausbügeln, und natürlich mit der ein oder anderen Modifikation. Klar, 
man hätte sich noch ein paar Runden Qualitätssicherungen gefreut - Aber 
das ist halt irgendwie auch die Handschrift von Bethesda, dass die Dinge 
so sind wie sie sind.

Die Rust Entstehung ist interessant. Gehässigerweise könnte man fragen, 
ein neuer Lisp-Dialekt?
Früher gab es mal f2c. Heute dann c2r?
Fortran hat seine Stärken in der mathematischen Performance. C ist 
Systemnäher, Basic, die kleine Schwester von Fortran, war weniger 
systemnah, dafür aber fast überall verfügbar und man konnte es für viele 
Dinge einsetzen.
Python ist gewissermaßen in die Fußstapfen von Basic getreten.

Rein von der Werkzeug-Betrachtung her scheint Rust echt gut zu sein.

Programmierkulturtechnisch: schwierige funktionale Programmierung. Es 
gibt auch die "Lösung" "Funktionalität" in C++ zu importieren.

Stichwort: funktionale C++ Programmierung.

Wenn man auf die 60er Jahre schaut, dann eierte die Funktionale 
Programmierung/Lisp und ähnliche immer so mit, spielten aber - auch bei 
der Parallelisierung - meist nur die 2. oder 3. Geige - oder noch weiter 
hinten.

Das ist bei Rust ein wenig anders. Mit z.B. Haskell einen Compiler zu 
entwickeln - das ist eine wirklich sehr gute Möglichkeit, sowas zu tun.
Nicht dumm..

Nach hinten raus steht immer noch die Frage im Raum, lieber in C++ 
machen, oder nicht?
Ich denke, man sollte beides können. Grundsätzlich doof ist, wenn die 
funktionalen Hintergründe nicht verstanden werden.
Es ist halt eine Übungssache.

Und deswegen mag ich Haskell, obwohl es da z.B. mit dem ghc oder dem 
Drumherum (mal so mal so - wie denn jetzt?) oder der fehlenden 
Hardwarenähe auch recht problematisch zugeht.
Beim Lernen stört das aber erstmal nicht so.

Rust ist der pragmatische Ansatz.

https://mariusschulz.com/blog/fast-searching-with-ripgrep

von cppbert3 (Gast)


Lesenswert?

Auch wenn ich nicht ganz schlau draus werde was du mit dem Post sagen 
möchtest, ist er trotzdem irgendwie positiv

Die starken Funktionalen Bezüge in deinem Post kann ich nicht zuordnen 
den Rust ist wie C, C++ und viele andere eine imperative 
Programmiersprache ohne Funktionale Basis

von Roland F. (rhf)


Lesenswert?

Hallo,
cppbert3 schrieb:
> ... den Rust ist wie C, C++ und viele andere eine imperative
> Programmiersprache ohne Funktionale Basis

Wie ist dann in
https://de.wikipedia.org/wiki/Rust_(Programmiersprache)
das Programmierbespiel zur Berechnung der Fakultät zu verstehen?
Zitat:
"Alternativ erlaubt es Rust, das Problem im Sinne der funktionalen 
Programmierung anzugehen. Sogenannte Iterators bieten eine Möglichkeit, 
iterierbare Objekte zu verarbeiten. So lässt sich die Fakultät mit Hilfe 
des Iterators (1..=i) und dessen Methode product()[31] wie folgt 
darstellen..."

rhf

von Programmierer (Gast)


Lesenswert?

rbx schrieb:
> Python ist gewissermaßen in die Fußstapfen von Basic getreten.

Naja, meine These lautet: Der Erfolg von Python wird überbewertet.

Python ist heute nur wegen Numpy und dem ganzen KI-Kram so populär. Und 
Numpy entstand weil in den 1990er Mathworks mit ihrer Lizenzpolitik zu 
Matlab durchdrehte. Zusätzlich kam später IPython aka Jupyter dazu. 
Damit verfestigte sich Python im akademischen Sektor, einer Nische. Da 
aus der akademischen Welt auch die Entwicklung KI und Maschinelearning 
getrieben wurde, wurde natürlich das dort benutzte Python als 
Scriptsprache dafür verwendet.

Denn genau das ist Python nämlich: Eine Script-Sprache für Numpy und die 
ganzen Maschinelearning-Plattformen. Kaum einer wählt Python als Sprache 
für ein Projekt der Sprache selbst wegen, sondern weil er eben Numpy 
oder ein Maschinelearning-Paket benutzen will. Und die allermeisten 
Scripte die in diesem Bereich mit Python gebastelt werden, haben nur ein 
paar hundert Zeilen oder niedrige vierstellige Anzahl von Zeilen. Python 
ist der Nachfolger von Perl: Plattform für Wegwerf-Programme.

Egal. Zurück zu Rust:


rbx schrieb:
> Programmierkulturtechnisch: schwierige funktionale Programmierung.

Naja, die Masse muss erst funktionale Programmierung verinnerlichen. Bei 
OO war das nicht anders. Das hat auch Jahrzehnte gedauert, bis die 
"Hardcore-Imperativisten" in der Minderheit waren.

Aber OO hat seinen Zenit weit überschritten.

Natürlich hat OO ein Riesenmomentum, weil in der Zwischenzeit der 
Softwaresektor explodiert ist. Wenn man sich aber anschaut, wie die 
vielen Neulinge witzigerweise über Javascript mit funktionalen 
Paradigmen "infiziert" werden, und welchen Boom Haskell vor ca. 15 
Jahren erfuhr, und wie dieser Boom z.B. C++ und andere Sprachen, 
darunter sicherlich auch Rust, danach beeinflusst hat, hat der Siegeszug 
der Funktionalen Paradigmen schon längst begonnen.

Haskell ist toll, aber teilweise doch ziemlich akademisch und 
letztendlich für die Massenanwendung zu heftig.

Und genau da breitet sich Rust nun aus. Rust ist (etwas) anspruchsvoller 
als viele aktuelle Massensprachen, aber ein merkliches Stück einfacher 
als z.B. Haskell. Das ist glaub ein gute Mischung. Irgendwo habe ich mal 
gelesen: Rust sei das Haskell für die Praxis, oder so ähnlich. Dem 
stimme ich zu 100% zu.

Rust ist durch und durch eine imperative Sprache, allerdings lassen sich 
funktionale Konzepte und Paradigmen sehr gut damit verwenden bzw. 
umsetzen, weil es u.a. auch Summen-Datentypen hat. Fehlende 
Summen-Datentypen halte ich für das größte Manko vieler Sprachen.

(Und es wird ja in immer mehr Sprachen versucht, das irgendwie 
nachträglich reinzubasteln. Selbst Python versucht es inzwischen 
irgendwie mit seinem Structural Pattern Matching.)

Dazu, finde ich, ist bei Rust die Standardbibliothek außerordentlich gut 
gelungen.

Ob es nun einen Standard in einer vergleichbaren Form zu einem 
beliebigen anderen Sprachstandard gibt, ist meiner Meinung nach 
nebensächlich. Es gibt immer verschiedene Anwendungsgruppen von 
Software-Technologie. Es gibt Gruppen die nehmen neue Entwicklungen sehr 
früh auf und setzen sie produktiv und gewinnbringend ein, und andere 
Gruppen warten, bis es für jeden Furz der Technologie 100 Seiten 
ISO-Spezifikation gibt. Diese Gruppen hinken immer Jahrzehnte der 
Entwicklung hinterher. Sie sind aber auch kein Innovatoren und für 
Entwicklungen in der Software-Branche völlig bedeutungslos.

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


Lesenswert?

Programmierer schrieb:
> Python ist heute nur wegen Numpy und dem ganzen KI-Kram so populär.

Das hat sicher auch meiner Meinung nach massiv dazu beigetragen.

Aber ganz unabhängig davon ist natürlich der Interpreter, in dem man 
schnell mal einen Konstrukt eines größeren Scripts "vortesten" kann, ein 
sehr praktisches Hilfsmittel. Auch bei uns in der Industrie ist daher 
Python jenseits der Firmware ziemlich häufig im Einsatz. (Matlab sicher 
auch, aber mehr im tatsächlichen Mathematik-Umfeld.)

C, C#, C++, Java, Rust :) macht an der Stelle keiner.

von cppbert (Gast)


Lesenswert?

Rust erlaubt genau so wie C++ Funktional-artige Programmierung, aber 
Haskell ist Kilometer von Funktional-"artig" weg - Haskell ist 
vollwertig Funktional

der Vergleich Rust und Haskell macht keinen Sinn - aber scheinbar gibt 
es hier welche die da eine Ähnlichkeit sehen, es ist aber trotzdem eine 
ganz andere Art der Programmierung, deswegen die nicht so hohe 
durchdringung des Marktes

von Mombert H. (mh_mh)


Lesenswert?

Programmierer schrieb:
> Damit verfestigte sich Python im akademischen Sektor, einer Nische.
Einer Nische? Interessant.

Programmierer schrieb:
> Denn genau das ist Python nämlich: Eine Script-Sprache für Numpy und die
> ganzen Maschinelearning-Plattformen. Kaum einer wählt Python als Sprache
> für ein Projekt der Sprache selbst wegen, sondern weil er eben Numpy
> oder ein Maschinelearning-Paket benutzen will. Und die allermeisten
> Scripte die in diesem Bereich mit Python gebastelt werden, haben nur ein
> paar hundert Zeilen oder niedrige vierstellige Anzahl von Zeilen.
Worauf basiert diese Einschätzung?

Ich kenne niemanden, der (nur) wegen numpy zu Python gewechselt ist. 
numpy hat nicht viele Vorteile gegenüber Fortran und vermutlich genauso 
viele Nachteile. Das deutlich wichtigere Python Projekt ist matplotlib.

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


Lesenswert?

Mombert H. schrieb:
> numpy hat nicht viele Vorteile gegenüber Fortran

Der wesentliche Vorteil ist, dass man als Frontend zum alten 
FORTRAN-Kram eine benutzbare Programmiersprache bekommt, die man auch im 
21. Jahrhundert einigermaßen verstehen kann. ;-)

Ich denke, das ist genau der Punkt an dieser Stelle, und letztlich auch 
der, womit Matlab gepunktet hat (zumindest im Ursprung, mittlerweile 
eher mit Toolboxes für jede Lebenslage).

von cppbert (Gast)


Lesenswert?

Mombert H. schrieb:
> Programmierer schrieb:
>> Damit verfestigte sich Python im akademischen Sektor, einer Nische.
> Einer Nische? Interessant.

Off-Topic-Alarm: Es geht hier um Rust, bleibt dabei

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


Lesenswert?

cppbert schrieb:
> Es geht hier um Rust, bleibt dabei

Gibt's denn ein Eispack/Linpack-Frontend in Rust?

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Gibt's denn ein Eispack/Linpack-Frontend in Rust?

Keine Ahnung.
Das ist überhaupt nicht das Einsatzgebiet von Rust.
Nimm Python.

Rust ist eine Systems Programming Language.

von cppbert (Gast)


Lesenswert?

Jörg W. schrieb:
> cppbert schrieb:
>> Es geht hier um Rust, bleibt dabei
>
> Gibt's denn ein Eispack/Linpack-Frontend in Rust?

ich kenne nur https://nalgebra.org/ mit Lapack Bindings - keine Ahnung 
ob das was taucht

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> Keine Ahnung.
> Das ist überhaupt nicht das Einsatzgebiet von Rust.
> Nimm Python.
>
> Rust ist eine Systems Programming Language.

Das würde ich jetzt nicht einfach so sage - warum sollte Rust dafür 
ungeeignet sein - als Sprache?

von Kaj (Gast)


Lesenswert?

Für Lapack gibt es wrapper:
https://crates.io/crates/lapack

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> Das würde ich jetzt nicht einfach so sage - warum sollte Rust dafür
> ungeeignet sein - als Sprache?

Es ist nicht ungeeignet.
Aber es gibt geeignetere Sprachen.
Nicht alles, was möglich ist, ist auch sinnvoll.

Rust hat ein sehr strenges und komplex zu bedienendes Typsystem. Ein 
Großteil des Entwicklungsaufwands bei Rust-Programmen fließt in das 
Design der Datentypen, Methoden und Traits. All dies muss 
zusammenspielen, sonst kommt man insbesondere bei Rust in Teufels Küche. 
Hacks, die das Typsystem hintergehen, sind in Rust nicht ohne weiteres 
(= unsafe Rust) möglich. Einfach mal mit einem Pointer um sich werfen, 
wie man es aus C++ kennt, kann man in Rust nicht. Und das ist gut so.

Wenn ich mathematische Probleme löse, dann will ich eines ganz gewiss 
nicht: Mich mit dem Typsystem herumschlagen.
Das ist der Einsatz, wo Sprachen wie Python (+ Numpy) groß sind.

von Mombert H. (mh_mh)


Lesenswert?

Jörg W. schrieb:
> Mombert H. schrieb:
>> numpy hat nicht viele Vorteile gegenüber Fortran
> Der wesentliche Vorteil ist, dass man als Frontend zum alten
> FORTRAN-Kram eine benutzbare Programmiersprache bekommt, die man auch im
> 21. Jahrhundert einigermaßen verstehen kann. ;-)
Ich bin mir nicht sicher, wie genau du das meinst. Aber:
- Niemand der im Jahre 20XX "altes FORTRAN" schreibt, wechselt zu Python 
und schreibt dort Python. Das wird im besten Fall PYTRAN77.
- Python hat genügend Fallstricke und unschöne Ecken. Da muss sich 
modernes Fortran nicht verstecken, wenn es ums numbercrunshen geht.
- Wenn z.B. numpy nicht bietet was man braucht muss man am Ende trotzdem 
C oder Fortran einsetzen + den ganzen Interface-Hokuspokus (dazu aus der 
aktuellen numpy-Doku:
1
The default build system for F2PY has traditionally been the through the enhanced numpy.distutils module. This module is based on distutils which will be removed in Python 3.12.0 in October 2023; setuptools does not have support for Fortran or F2PY and it is unclear if it will be supported in the future. Alternative methods are thus increasingly more important.
- Ich stoppe besser hier, bevor ich stundenlang die Vor- und Nachteile 
von Python, Fotran und C++ beim Lösen von numerischen Problemen 
aufliste. MaWin bekommt bestimmt schon einen hochroten Kopf, weil ich 
bis jetzt kein rust erwähnt habe.

> Ich denke, das ist genau der Punkt an dieser Stelle, und letztlich auch
> der, womit Matlab gepunktet hat (zumindest im Ursprung, mittlerweile
> eher mit Toolboxes für jede Lebenslage).
Python hat viele Pluspunkte. Einer der wichtigsten Punkte ist, dass 
Fortran eine Sackgasse ist. Wenn man seinen Abschluss hat, kann man in 
95% der Fälle sein Fortran-Wissen direkt vergessen, weil man es nie 
wieder benutzen wird. Es ist Fachwissen und kein Werkzeug.

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


Lesenswert?

MaWin schrieb:
> Das ist der Einsatz, wo Sprachen wie Python (+ Numpy) groß sind.

Allerdings eben als interpretierte Sprache zwar schnell im Design, u.U. 
aber doch mit Geschwindigkeitseinbußen in der Ausführung. Wenn man große 
Datenmengen numerisch behandeln muss, kann es also sinnvoll sein, einen 
Python-Prototypen später in was anderem nachzuschreiben.

Ich habe auch schon Python-Prototypen in C nachgeschrieben, für ARM-MCU, 
im Zusammenhang mit der ARM DSP Library.

Insofern kann so eine Betrachtung nicht ganz unsinnig sein, die 
Portierung eines Prototypen von Python nach Rust zu machen. Die 
Typisierung musste ich übrigens auch in C abhandeln, nur "mit einem 
Pointer herum zu werfen" löst ja an sich erstmal noch kein Problem.

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> Einfach mal mit einem Pointer um sich werfen,
> wie man es aus C++ kennt, kann man in Rust nicht. Und das ist gut so.
Da sind wir wieder bei FORTRAN vs. Fortran, wenn das deine C++ Sicht ist 
;-).

MaWin schrieb:
> Wenn ich mathematische Probleme löse, dann will ich eines ganz gewiss
> nicht: Mich mit dem Typsystem herumschlagen.
> Das ist der Einsatz, wo Sprachen wie Python (+ Numpy) groß sind.
Gut, dass das nicht alle so sehen :-)

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
>> Das ist der Einsatz, wo Sprachen wie Python (+ Numpy) groß sind.
>
> Allerdings eben als interpretierte Sprache zwar schnell im Design, u.U.
> aber doch mit Geschwindigkeitseinbußen in der Ausführung.

Wenn der interpretierte Teil eines Python+Numpy-Programms ein Problem 
wird, dann machst du in 99% der Fälle etwas sehr sehr falsches.

> Wenn man große
> Datenmengen numerisch behandeln muss, kann es also sinnvoll sein, einen
> Python-Prototypen später in was anderem nachzuschreiben.

Kann vorkommen. Aber sehr selten.
Dann meinetwegen auch in Rust.
Aber nicht von vorne herein schon.

Jörg W. schrieb:
> Die Typisierung musste ich übrigens auch in C abhandeln

Die Rust-Typisierung mit C-Typisierung zu vergleichen ist schon etwas 
ulkig.

Das Rust Typsystem verhält sich zum C Typsystem wie ein Daimler zu einem 
Tretroller.

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


Lesenswert?

MaWin schrieb:
> Die Rust-Typisierung mit C-Typisierung zu vergleichen ist schon etwas
> ulkig.

Kann sein, aber möglicherweise kennst du auch bloß schlechtes C.

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> Das Rust Typsystem verhält sich zum C Typsystem wie ein Daimler zu einem
> Tretroller.
Also C ist ein Kinderspielzeug oder energiesparendes 
Kurzstreckenfahrzeug und rust eine Protzkarre?

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
>> Die Rust-Typisierung mit C-Typisierung zu vergleichen ist schon etwas
>> ulkig.
>
> Kann sein, aber möglicherweise kennst du auch bloß schlechtes C.

Hä?
Ich spreche von der Sprache C, die im ISO-Standard definiert ist. Ich 
denke nicht, dass die schlecht oder gut ist. Sie ist, wie sie ist.

Das Typsystem der Sprache C ist überhaupt nicht direkt vergleichbar mit 
Rust.
Das Rust-Typsystem ist von der Komplexität her etwa in der Liga des 
C++-Typsystems, um für dich einen Vergleich zu schaffen, den du 
eventuell nachvollziehen kannst.
Aber auch dieser Vergleich ist eigentlich nicht zutreffend wegen der 
ganzen C-Altlasten in C++. Und weil Rust Features hat, die es in C++ gar 
nicht gibt. Das Konzept von Lifetimes gibt es weder in C, noch in C++. 
Wenn man ein Rust-Programm schreibt, ist man aber gezwungen sich mit 
Lifetimes (und allen anderen Eigenschaften des komplexen Typsystems) 
auseinanderzusetzen.

Und das ist eben der Punkt. Wenn ich ein mathematisches Problem lösen 
möchte, dann stehen mir diese Dinge erst einmal im Weg.
Wenn das Problem dann gelöst und verstanden ist, dann kann ich immer 
noch darüber nachdenken, ob es sinnvoll ist, das Programm in einer 
Sprache wie Rust neu zu schreiben.
Bei Verwendung von einfachen Sprachen wie Python bleibt mehr 
Hirnkapazität für das zu lösende Problem über. Mit dem Nachteil, dass 
mehr Programmierfehler erst (sehr viel) später auffallen. Teilweise erst 
nach der Auslieferung des Programms. Es ist ein Abwägen von Prioritäten.

Es ist erklärtes Ziel der Rust-Entwickler den Entwicklungsprozess eines 
Rust-Programms deutlich zu vereinfachen. Und das ist auch gut und 
notwendig.
Aber dort sind wir leider noch nicht am Ziel angekommen. Und ich sehe 
nicht, wie wir jemals an die Entwicklungsperformance von Python auch nur 
im Ansatz anknüpfen können. Aber das ist eigentlich auch nicht 
notwendig. Jede Sprache für seinen Zweck.

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> Es ist nicht ungeeignet.
> Aber es gibt geeignetere Sprachen.
> Nicht alles, was möglich ist, ist auch sinnvoll.

ich arbeite an einem Projekt das locker 500.000 Lines nur Mathecode 
beinhaltet um Maschinen zu steuern, teilweise nearly Echtzeit - da will 
ich kein Python, ist in diesem Projekt alles mit C++ realisiert

Es kommt eben drauf an

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> Das Konzept von Lifetimes gibt es weder in C, noch in C++.
Meinst du damit ein definierte Lifetime von Objekten oder die *rustc 
Lifetimes*™?

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


Lesenswert?

MaWin schrieb:
> Das Typsystem der Sprache C ist überhaupt nicht direkt vergleichbar mit
> Rust.

Habe ich auch nicht behauptet.

Aber C ist auch nicht bloß "mal einen Pointer herumwerfen", wie du das 
darstellst. Zumindest nicht, wenn man es ordentlich macht.

Dass bei letzterem Rust einen deutlichen Vorteil hat (die Bedingung 
"wenn man es ordentlich macht" kann man dort nicht umgehen), ist 
unbestritten. Und klar, Python oder Matlab sind da pragmatischer, in der 
Beziehung halt wirklich eher wie BASIC.

von cppbert (Gast)


Lesenswert?

Jörg W. schrieb:
> Aber C ist auch nicht bloß "mal einen Pointer herumwerfen", wie du das
> darstellst. Zumindest nicht, wenn man es ordentlich macht.

du bist immer noch ein wenig zu kritisch - mitlerweile sollte dir klar 
sein das MaWin ein nicht ganz unbeschriebenes Blatt ist, sich auskennt 
und manchmal ein wenig überspitzt schreibt

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


Lesenswert?

Ich habe nur manchmal die Befürchtung, dass er von ein paar schlechten 
C-Programmierern auf die Qualität aller C-Programme schließt.

Logischerweise hat natürlich Rust von Problemen existierender Sprachen 
gelernt, wofür sonst hätte es überhaupt einer neuen Programmiersprache 
bedurft?

: Bearbeitet durch Moderator
von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Ich habe nur manchmal die Befürchtung, dass er von ein paar schlechten
> C-Programmierern auf die Qualität aller C-Programme schließt.

Die "paar" schlechten C-Programmierer.
Da sind sie wieder.
Wenn man ein C-Programm richtig schreibt, ist es auch ein korrektes 
Programm.
Ich stimme dir vollkommen zu.

Aber du hast es ja bereits selbst erkannt, worum es Rust geht:

Jörg W. schrieb:
> Dass bei letzterem Rust einen deutlichen Vorteil hat (die Bedingung
> "wenn man es ordentlich macht" kann man dort nicht umgehen), ist
> unbestritten.

Und das zwingt den Programmierer halt Hirnressourcen dafür aufzuwenden, 
die dann natürlich nicht anderweitig zur Verfügung stehen.
In vielen Fällen mag der zusätzliche Aufwand gerechtfertigt sein. In 
vielen aber auch nicht.
Das muss man abwägen.
Rust ist kein Allheilmittel.
Aber es ist eben auch ein mächtiges Werkzeug, das viele C/C++-Programme 
ablösen kann und sollte.

Mombert H. schrieb:
> Meinst du damit ein definierte Lifetime von Objekten oder die *rustc
> Lifetimes*™?

Mombert, dir antworte ich übrigens nicht mehr, falls du es noch nicht 
gemerkt hast.
Befasse sich bitte erst einmal mit den Grundlagen von Rust. Und höre auf 
zu trollen.

von cppbert (Gast)


Lesenswert?

Mombert H. schrieb:
> MaWin schrieb:
>> Das Konzept von Lifetimes gibt es weder in C, noch in C++.
> Meinst du damit ein definierte Lifetime von Objekten oder die *rustc
> Lifetimes*™?

allen hier ist klar was Stack Objekte und RAII etc. ist - darum ging es 
nicht
- Lifetime ist bei Rust eine Eigenschaft des Typ-Systems eben nicht nur 
Heap oder Scope

von rbx (Gast)


Lesenswert?

cppbert schrieb:
> du bist immer noch ein wenig zu kritisch - mitlerweile sollte dir klar
> sein das MaWin ein nicht ganz unbeschriebenes Blatt ist, sich auskennt
> und manchmal ein wenig überspitzt schreibt

Hier geht es aber eigentlich um Daniel und die Frage, ob die kognitive 
Dissonanz-Bearbeitung berechtigt ist, oder nicht.
Ich bin mir nicht sicher.

Auf der anderen Seite werden Programmiersprachen tatsächlich oft 
überbewertet.
Know How, Algorithmen, Motivation sind auch sehr wichtig. Ohne 
Motivation geht nix.

Warum stellt Daniel die Frage, ob Rust bleibt? Möchte er Kernelhacker 
werden?

Vor dem Hintergrund der Multicore Nutzung steht Rust ganz gut da.

Aber ich glaube nicht, dass eine Diskussion sehr weit führt. Es ist 
vielleicht hilfreicher, seine Lieblingsprogramme nach Rust zu 
übersetzen, und dann zu schauen, was man selber davon hat.
Sinnvollerweise aber möglichst da, wo Rust seine Stärken hat.

von cppbert (Gast)


Lesenswert?

rbx schrieb:
> Warum stellt Daniel die Frage, ob Rust bleibt? Möchte er Kernelhacker
> werden?

welcher Daniel? hat er die Frage aufgemacht?

Dieser Post hier ist eher so eine Sammlung an Rust Diskussionen die alle 
paar Monate mal wieder aufflammen, weiter betrieben von anderen

von cppbert (Gast)


Lesenswert?

Jörg W. schrieb:
> Ich habe nur manchmal die Befürchtung, dass er von ein paar schlechten
> C-Programmierern auf die Qualität aller C-Programme schließt.

eigentlich bist du es der immer wieder davon ausgeht das er keinen oder 
einen schlechten Überblick hat und dann in Detail-Diskussionen verfällt 
weil du ihn (löblicherweise) belehren willst - aber das ist so gut wie 
nie wirklich nötig

leider schließen sich dann auch recht schnell viele anderen an und alle 
Antworten driften total in die Off-Topic Richtung - immer und immer 
wieder

aber jetzt gerade ist deine Argumentation fein - Sternchen für dich :)

von cppbert (Gast)


Lesenswert?

Ich bin wirklich sehr gespannt wann Rust im Linux-Kernel aktiv wird - 
also dem Protoypen-Status entwächst und auch von vielen anderen 
Linux-Entwicklern begutachtet wird (ich weiss das nicht jeder an allem 
arbeitet)

weiss jemand ob das Asynchron-Konzept im Kernel (natürlich mit 
Kernel-Backend) Anwendung finden wird oder ist das ein zu "komplexes" 
Konzept für die Kernel-Ebene?

von Ein T. (ein_typ)


Lesenswert?

Jörg W. schrieb:
> MaWin schrieb:
>> Das ist der Einsatz, wo Sprachen wie Python (+ Numpy) groß sind.
>
> Allerdings eben als interpretierte Sprache zwar schnell im Design, u.U.
> aber doch mit Geschwindigkeitseinbußen in der Ausführung. Wenn man große
> Datenmengen numerisch behandeln muss, kann es also sinnvoll sein, einen
> Python-Prototypen später in was anderem nachzuschreiben.

Tatsächlich sind große Teile von numpy, scipy & Co. in nativen Sprachen 
wie C, C++ und Fortran implementiert. Performance ist daher in der Regel 
kein Thema, dessentwegen man Python-Prototypen in anderen Sprachen 
reimplementieren müßte.

Auch Python selbst ist schneller als sein Ruf. Für ein Projekt habe ich 
mal einen Bag-of-Words-Algorithmus mit Boost::Python entwickelt, der 
sich am Ende als viel langsamer herausgestellt hat als die native 
Python-Implementierung.

: Bearbeitet durch User
von Ein T. (ein_typ)


Lesenswert?

cppbert schrieb:
> MaWin schrieb:
>> Es ist nicht ungeeignet.
>> Aber es gibt geeignetere Sprachen.
>> Nicht alles, was möglich ist, ist auch sinnvoll.
>
> ich arbeite an einem Projekt das locker 500.000 Lines nur Mathecode
> beinhaltet um Maschinen zu steuern, teilweise nearly Echtzeit - da will
> ich kein Python, ist in diesem Projekt alles mit C++ realisiert

500 kLOC Mathcode hören sich zunächst nach viel an, bis man feststellt, 
in welcher Sprache sie geschrieben sind... ;-)

Nein, im Ernst: auch Python läßt sich in nativen Code kompilieren, vor 
allem Mathcode (think numba). Zudem gibt es andere Interpreter wie Pypy 
mit JIT-Compiler, die in vielen Anwendungsfällen viel schneller sind als 
die Referenzimplementierung.

von cppbert (Gast)


Lesenswert?

Ein T. schrieb:
> Tatsächlich sind große Teile von numpy, scipy & Co. in nativen Sprachen
> wie C, C++ und Fortran implementiert. Performance ist daher in der Regel
> kein Thema, dessentwegen man Python-Prototypen in anderen Sprachen
> reimplementieren müßte.

wie gesagt es gibt die richtigen Gründe es zu tun und es nicht zu tun, 
kommt absolut auf das Projekt und die Umgebung des Projektes an - in 
meinen Hochlast und Resourcen-Beschränkten Projekten geht es einfach 
nicht in anderen schon

> Auch Python selbst ist schneller als sein Ruf. Für ein Projekt habe ich
> mal einen Bag-of-Words-Algorithmus mit Boost::Python entwickelt, der
> sich am Ende als viel langsamer herausgestellt hat als die native
> Python-Implementierung.

was jetzt in keinster Weise bedeutet das native Python schnell ist - es 
kann so viele Gründe geben warum das bei dir so war das es als Argument 
schwerlich dienen kann

von DPA (Gast)


Lesenswert?

Vergleichen wir doch mal Rust mit C.


Rust - Eisenoxid - Fe₂O₃

Eigentlich nur für 2 Sachen gut: Eisenherstellung / zutat in Thermit, 
und als Braunrotes Farbpigment.

Meistens bereitet es aber Probleme. Eisen rostet, und wird brüchig. 
Rostige schrauben lassen sich nicht rein / raus drehen. Und wenn rostige 
Sachen im regen steht, färbt es alles darum rum Rot ein. Es gibt auch 
nichts wichtiges, was man aus Rost selbst herstellen würde, nur der 
Eisenanteil ist interessant.

Normalerweise versucht man, zu verhindern, dass dinge Rosten. Wir haben 
Stahl erfunden, Rostschutzmittel, Lacke, etc. um dem Rost Herr zu 
werden. Aber ganz vernichten konnten wir ihn nie. Es gibt immer noch 
Dinge, die vor sich hin rosten, und so schnell ändert sich daran auch 
nichts...
Rust - ist das hier um zu bleiben?
Ja, sieht leider so aus.


C - Kohlenstoff

Unglaublich nützlich. Plastik und Polymere brauchen Kohlenstoff. 
Pythons, Menschen,  etc. sind Kohlenstoffbasierte Lebewesen. Jegliche 
organische Chemie basiert auf Kohlenstoff. Kohlenstoff ist auch geeignet 
als Schmiermittel. Es kann für Transistoren verwendet werden. Und als 
Nono Röhrchen kann man damit extrem stabile Fäden herstellen. Und es ist 
auch beliebt zum Schreiben, in Bleistiften. In der Forschung und als 
schmuck ist es auch begehrt, als Diamanten. Es gibt sicher noch weitere 
Anwendungsgebiete. Ein wahrere Alleskönner.

C ist also klar besser als Rust.

von rbx (Gast)


Lesenswert?

Ob Python schnell ist, kommt auch auf die Perspektive an. Python wurde 
schnell zu Hackers Liebling, nicht etwa eine der funktionalen Sprachen.

Inwieweit ein Setup schnell ist, etwa für Statistikübersichten, 
Data-Mining Zeugs, Visualisierung für dies und das, ist vielleicht 
nochmal eine andere Frage. Aber bestimmt keine unwichtige.

Ein Setup für Mikrocontroller vor allem bei Parallelprogrammierung wäre 
interessant, oder eben auch ein Setup für Spiele auf Linux, welche die 
Parallelität ausnutzen.
Bei Spielen spielen aber auch Skriptsprachen eine Rolle, Lua oder 
Javascript z.B.
Dann gibt es noch verschiedenen "Engines" z.B. für Physik, das muss man 
auch noch alles unter einen Hut bekommen.
Und ja, die Gameengines selber sind aus mehrererlei Hinsicht 
überholungsbedürftig.

Rust ist diesbezüglich eine große Chance. Im Weg steht das Umdenken.

Mombert H. schrieb:
> - Niemand der im Jahre 20XX "altes FORTRAN" schreibt, wechselt zu Python
> und schreibt dort Python. Das wird im besten Fall PYTRAN77.

Ziemlich guter Einwand.

von cppbert (Gast)


Lesenswert?

DPA schrieb:
> C ist also klar besser als Rust.

Die erste gute Erklärung warum C wirklich besser ist :)

Danke

von cppbert (Gast)


Lesenswert?

rbx schrieb:
> Ein Setup für Mikrocontroller vor allem bei Parallelprogrammierung wäre
> interessant, oder eben auch ein Setup für Spiele auf Linux, welche die
> Parallelität ausnutzen.
> Bei Spielen spielen aber auch Skriptsprachen eine Rolle, Lua oder
> Javascript z.B.
> Dann gibt es noch verschiedenen "Engines" z.B. für Physik, das muss man
> auch noch alles unter einen Hut bekommen.
> Und ja, die Gameengines selber sind aus mehrererlei Hinsicht
> überholungsbedürftig.

das klingt wie eine Wunschlisten, Hoffnungssammlung ohne richtigen 
Hintergrund

Rust kann das ganze vielleicht ein wenig homogenisieren und natürlich 
stark seine Stärken in Sicherer-Programmierung ausspielen - aber dadurch 
wird sonst nichts wirklich einfacher, ein ~8Mio Lines of Code pure 
Unreal Engine oder mindestens 10-20Mio Zeilen Code von GTA5 werden damit 
auch nicht magisch viel weniger oder einfacher - auch Projekt-Teams mit 
mehr als 100 Entwickler sind nicht ständig am Dependencies Resolven 
sondern kümmern sich mehr oder minder nur um den Game-Code, was absolut 
nicht bedeuten soll das Rust nicht super viel helfen kann - aber deine 
Auflistung ist trotzdem komisch

oder was meinst du?

von rbx (Gast)


Lesenswert?

DPA schrieb:
> Rust - Eisenoxid - Fe₂O₃
>
> Eigentlich nur für 2 Sachen gut: Eisenherstellung / zutat in Thermit,
> und als Braunrotes Farbpigment.

Der Nutzen scheint auch eher für Kenner zu sein, also Leute, die es 
wirklich wissen wollen:
https://www.deutschlandfunknova.de/nachrichten/magnetische-nanopartikel-mit-smartem-rost-gegen-mikroplastik

Die Geschichte ist aber auch schon alt, und so wohl mehr für 
interessante Nachrichten geeignet, als tatsächlich coole Hilfe für echte 
Nöte.

von rbx (Gast)


Lesenswert?

cppbert schrieb:
> oder was meinst du?
Hinsichtlich einer komischen hoffnungsverlorenen Perspektive ohne 
richtiges Hintergrundverständnis auf meinen Beitrag finde ich es bei 
einem so wackeligen Thema so wie hier ziemlich erbärmlich, auf der 
Persönlichkeitsebene herumzueiern.

Von Idealisierung der Programmiersprache hatte ich auch nichts gesagt, 
sondern nur dass die funktionale Programmierung nicht gut verstanden 
wird, was ja verständlich ist, denn der Code ist fremdartig, und kaum 
einer ist damit aufgewachsen, oder hat Fachzeitschriften und Bücher 
gewälzt mit funktionalen Sprachen, um Sachen auszuprobieren.
Das ist aber heute echt ein Problem.

Mein Punkt ist, dass das bessere Verständnis der funktionalen 
Programmierung und auch das Verständnis von so Geschichten wie Rust 
nicht verkehrt ist.

Alternativ könnte ich auch Werbung für Modula 3 machen - Für einen 
aktuelleren Blick über den Tellerrand ist Rust viel besser geeignet.

von cppbert (Gast)


Lesenswert?

rbx schrieb:
> cppbert schrieb:
>> oder was meinst du?
> Hinsichtlich einer komischen hoffnungsverlorenen Perspektive ohne
> richtiges Hintergrundverständnis auf meinen Beitrag finde ich es bei
> einem so wackeligen Thema so wie hier ziemlich erbärmlich, auf der
> Persönlichkeitsebene herumzueiern.

Bitte nicht so empfindlich sein (erbärmlich und Persönlichkeitsebene war 
hier gar nichs)
dein Text von oben ist einfach maximal Interpretierungsfähig und die 
Kernaussage dahinter ist mir immer noch unklar, stört mich aber auch 
nicht

rbx schrieb:
> Von Idealisierung der Programmiersprache hatte ich auch nichts gesagt,
> sondern nur dass die funktionale Programmierung nicht gut verstanden
> wird, was ja verständlich ist, denn der Code ist fremdartig, und kaum
> einer ist damit aufgewachsen, oder hat Fachzeitschriften und Bücher
> gewälzt mit funktionalen Sprachen, um Sachen auszuprobieren.
> Das ist aber heute echt ein Problem.

vielleicht ist das mein Problem - warum gehst du auf das fehlende 
Verständnis für Funktionale Sprachen ein wenn es hier um die Imperative 
Sprache Rust geht?

von cppbert (Gast)


Lesenswert?

> oder eben auch ein Setup für Spiele auf Linux,
> welche die Parallelität ausnutzen.

das ist eine Sache der Spiele-Implementierung - egal in welcher Sprache, 
wenn du keine Threads/Asyncs nutzt ist dein Multicore eben ungenutzt - 
da kann Rust oder jede andere Sprache nichts dran ändern - und es gibt 
doch einen Haufen gut skalierende Software für Linux, Spiele sind da 
nichts besonderes

> Bei Spielen spielen aber auch Skriptsprachen eine Rolle, Lua oder
> Javascript z.B.

geht es dir um die Einfachheit der Integration?

...

> Und ja, die Gameengines selber sind aus mehrererlei Hinsicht
> überholungsbedürftig.

in welcher Hinsicht?

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> das ist eine Sache der Spiele-Implementierung - egal in welcher Sprache,
> wenn du keine Threads/Asyncs nutzt ist dein Multicore eben ungenutzt -
> da kann Rust oder jede andere Sprache nichts dran ändern

Das ist prinzipiell richtig.

Rust macht die Nutzung von mehreren Kernen aber deutlich einfacher, als 
andere Sprachen. Und dazu noch garantiert frei von Data Races.
Die Threading-Primitive ansich sind schon sehr einfach zu verwenden. 
Aber viele Crates bauen dort noch einfacherere APIs drum herum.


Und Async-Rust lässt sich auch mit ein paar Handgriffen auf mehreren 
Kernen parallel rechnen. Das kenne ich so von keiner anderen Sprache.

Deshalb denke ich schon, dass Rust an der Verbreitung der 
Multicorenutzung etwas ändert.

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> Rust macht die Nutzung von mehreren Kernen aber deutlich einfacher, als
> andere Sprachen. Und dazu noch garantiert frei von Data Races.
> Die Threading-Primitive ansich sind schon sehr einfach zu verwenden.
> Aber viele Crates bauen dort noch einfacherere APIs drum herum.

Da hast du definitiv recht, aber gute skaliebarkeit und "sinnvolle" 
Parallelität immer noch ein Herausforderung, obwohl bei Rust viele 
technische Probleme gar nicht mehr passieren können

von Ein T. (ein_typ)


Lesenswert?

cppbert schrieb:
> rbx schrieb:
>> Ein Setup für Mikrocontroller vor allem bei Parallelprogrammierung wäre
>> interessant, oder eben auch ein Setup für Spiele auf Linux, welche die
>> Parallelität ausnutzen.
>> Bei Spielen spielen aber auch Skriptsprachen eine Rolle, Lua oder
>> Javascript z.B.
>> Dann gibt es noch verschiedenen "Engines" z.B. für Physik, das muss man
>> auch noch alles unter einen Hut bekommen.
>> Und ja, die Gameengines selber sind aus mehrererlei Hinsicht
>> überholungsbedürftig.
>
> das klingt wie eine Wunschlisten, Hoffnungssammlung ohne richtigen
> Hintergrund

Für mich klingt das, hüstel, eher wie "ich habe eine Lösung und jetzt 
hätte ich bitte gerne ein Problem dafür".

von Ron T. (rontem)


Lesenswert?

Ein T. schrieb:
> Für mich klingt das, hüstel, eher wie "ich habe eine Lösung und jetzt
> hätte ich bitte gerne ein Problem dafür".

Eine Parole die über vielen Innovationen und kreativen Einfällen 
moderner Sprachen stehen könnte.

von Ein T. (ein_typ)


Lesenswert?

Ron T. schrieb:
> Ein T. schrieb:
>> Für mich klingt das, hüstel, eher wie "ich habe eine Lösung und jetzt
>> hätte ich bitte gerne ein Problem dafür".
>
> Eine Parole die über vielen Innovationen und kreativen Einfällen
> moderner Sprachen stehen könnte.

Ja, keine Frage. Ich mein', ja, ich find' Rust ja auch toll und finde es 
deswegen sehr schade, daß es sich vermutlich nicht durchsetzen wird.

von cppbert3 (Gast)


Lesenswert?

Ein T. schrieb:
> Ja, keine Frage. Ich mein', ja, ich find' Rust ja auch toll und finde es
> deswegen sehr schade, daß es sich vermutlich nicht durchsetzen wird.

Es gibt gab noch nie einen so ernsthaften Versuch eine bessere 
alternative zu C oder C++ zu erschaffen, ja, viele andere 
Programmiersprachen - aber keine Systemprogrammiersprachen das ist 
relativ einmalig, noch dazu ist es das erste mal in der Linux Geschichte 
das eine andere Sprache als C überhaupt diskutiert wird, das ist alles 
andere als nicht durchsetzen, was absolut nicht bedeutet das jeder ab 
morgen Rust macht, aber selbst wenn es noch 10 Jahre dauert wäre das 
Lichtgeschwindigkeit für eine Systemprogrammiersprache

von cppbert3 (Gast)


Lesenswert?

cppbert3 schrieb:
> aber selbst wenn es noch 10 Jahre dauert wäre das Lichtgeschwindigkeit

und ich meine nicht bis jeder es nutzt und alle 300 Billionen Zeile 
C/C++ vollständig portiert sind, das ist schwachsinn sondern einen 
etablierteren Zustand

In Systemprogrammierung oder tief embedded hat bisher gar nichts, nicht 
mal minimal am C/C++ Thron gekratzt, das es sich überhaupt lohnen würde 
es anzuschauen, unabhängig von Wille und Bock

von MaWin (Gast)


Lesenswert?

cppbert3 schrieb:
> noch dazu ist es das erste mal in der Linux Geschichte
> das eine andere Sprache als C überhaupt diskutiert wird

C++ wurde mehrfach kurz diskutiert und immer direkt abgeschmettert.

Und außerdem ist die halbe Kernelfunktionalität ja heute in (e)BPF 
programmiert. ;)

Ne ohne Spaß jetzt: Ich sehe das auch so, dass Rust der erste 
ernstzunehmende Versuch ist C direkt zu ergänzen und langfristig 
weitgehend zu ersetzen.

von Ein T. (ein_typ)


Lesenswert?

cppbert3 schrieb:
> Ein T. schrieb:
>> Ja, keine Frage. Ich mein', ja, ich find' Rust ja auch toll und finde es
>> deswegen sehr schade, daß es sich vermutlich nicht durchsetzen wird.
>
> Es gibt gab noch nie einen so ernsthaften Versuch eine bessere
> alternative zu C oder C++ zu erschaffen,

Aber ja doch, die Sprachen der PASCAL-Familie. Die haben zwar immer noch 
viele Freunde, aber durchgesetzt... eher nicht, oder?

> ja, viele andere
> Programmiersprachen - aber keine Systemprogrammiersprachen das ist
> relativ einmalig, noch dazu ist es das erste mal in der Linux Geschichte
> das eine andere Sprache als C überhaupt diskutiert wird, das ist alles
> andere als nicht durchsetzen, was absolut nicht bedeutet das jeder ab
> morgen Rust macht, aber selbst wenn es noch 10 Jahre dauert wäre das
> Lichtgeschwindigkeit für eine Systemprogrammiersprache

Systementwicklung als solche ist ja schon eine Nische, und... ich 
wünschte, es wäre anders, aber jede neue Sprache steht heute immer 
zunallererst vor dem Problem, daß es eine existierende Infrastruktur 
gibt. Ja, ich weiß, man kann C in Rust einbinden, verliert dann aber 
einige seiner wesentlichen Vorzüge. Und wer mal erlebt hat, wie vehement 
sich manche gestandene und erfahrene Entwickler dagegen sträuben, ihre 
lieb gewonnene Sprache und ihre Erfahrungen aufzugeben, mithin: wie sehr 
auch Entwickler Menschen und damit Gewohnheitstiere sind...

Jo, die Aufnahme in den Linux-Kernel ist eine Art Ritterschlag, 
wenngleich sie bis dato noch ein Versuch ist und ähnlich fehlschlagen 
könnte wie weiland der Versuch, C++ in den Linux-Kernel zu integrieren. 
Insofern heißt es erstmal abwarten, ob das erfolgreich sein wird -- aber 
selbst wenn es erfolgreich ist, ist die Entwicklung von 
Kernelkomponenten für Linux ja auch immer noch ein Nischending.

von MaWin (Gast)


Lesenswert?

Ein T. schrieb:
> Systementwicklung als solche ist ja schon eine Nische

Es ist die Nische, die C heute besetzt.
C ist aus allen anderen Bereichen bereits praktisch verdrängt worden.

> Ja, ich weiß, man kann C in Rust einbinden, verliert dann aber
> einige seiner wesentlichen Vorzüge.

Man verliert nicht wirklich etwas.
Was meinst du damit?

> Und wer mal erlebt hat, wie vehement
> sich manche gestandene und erfahrene Entwickler dagegen sträuben

Ja. Das ist das Hauptproblem.

> und ähnlich fehlschlagen
> könnte wie weiland der Versuch, C++ in den Linux-Kernel zu integrieren.

Linux-Rust ist deutlich weiter als jeder vorhergehende 
C++-Linux-Versuch.

> aber
> selbst wenn es erfolgreich ist, ist die Entwicklung von
> Kernelkomponenten für Linux ja auch immer noch ein Nischending.

Linux ist eine der Kernkomponenten, die die Welt am Laufen halten.
Ich würde das jetzt nicht als Nische bezeichnen.

von rbx (Gast)


Lesenswert?

Ein T. schrieb:
> Nischending.

Man könnte auch sagen "gesucht" (nicht zufliegend..).

Wie etwa bei der Cuda-Schnittstelle:
https://github.com/Rust-GPU/Rust-CUDA

Beitrag #7132840 wurde von einem Moderator gelöscht.
von cppbert (Gast)


Lesenswert?

rbx schrieb:
> Ein T. schrieb:
>> Nischending.
>
> Man könnte auch sagen "gesucht" (nicht zufliegend..).
>
> Wie etwa bei der Cuda-Schnittstelle:
> https://github.com/Rust-GPU/Rust-CUDA

ich verstehe nie so wirklich was du sagen willst - ist eine Rust-CUDA 
Wrapper jetzt nicht Nische, oder Nische?

von Ron T. (rontem)


Lesenswert?

Würde gern mal die Frage in den Raum stellen warum sich über das Thema 
so trefflich diskutieren lässt?
Weil Programmiersprachen vielleicht doch sehr auf den individuellen 
Geschmack (und individuelle Problemlösungen) angewiesen sind?
Warum sprießen immerfort neue Sprachpilze aus dem Boden?
Ist das nicht Ausdruck ständiger Unzufriedenheit mit dem Vorhandenen?
Ist das nicht Ausdruck der Unmöglichkeit einer "perfekten" Sprache?

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb im Beitrag #7132840:
> MaWin schrieb:
>> Linux ist eine der Kernkomponenten, die die Welt am Laufen halten.
>> Ich würde das jetzt nicht als Nische bezeichnen.
>
> Klar, Linux als Nabel der Welt. Im Nerd-Kinderzimmer sicher richtig.

jetzt komm schon, entweder trollst du äußerst gut oder hast absolut 
keine Ahnung - wenn Linux morgen von der Bildfläche verschwindet 
funktioniert so gut wie nichts mehr auf dieser Welt - nur so als Info in 
der Azure-Cloud von Microsoft sind ca. 80% Linux Server drin, fast alle 
Amazon AWS Instanzen sind Linux, fast alle Super-Computer laufen mit 
Linux, bis auf Apple fast alle Handys, alle Cloud-Systeme, Netflix, 
Amazon, Facebook, google, Whatsapp können nicht mal ansaztweise ohne, 
die Liste hört nicht auf - Microsoft ist definitiv der Desktop-König, 
aber Linux ist uneinholbar der Server und Konsumer-Devices-König - egal 
ob dir das bewusst ist
Was denkst du warum Microsoft einen Linux Extension WSL für Windows 
anbietet, oder eine eigene Linux-Distro hat?

und ich bin definitiv kein Linux-Nerd - ich muss nur hin und wieder 
dafür Software schreiben und laufe nicht mit geschlossenen Augen durch 
die Welt

von cppbert (Gast)


Lesenswert?

Ron T. schrieb:
> Ist das nicht Ausdruck ständiger Unzufriedenheit mit dem Vorhandenen?
> Ist das nicht Ausdruck der Unmöglichkeit einer "perfekten" Sprache?

nur wenn man aus der applikativen Richtung schaut, also Java, .Net, 
Python usw. - im der Systemprogrammiersprachen Welt gab und gib es kaum 
bis gar keine Bewegung seit jahrzehnten, darum ist Rust auch was anderes 
als eine "weitere" Sprache

von cppbert (Gast)


Lesenswert?

Ron T. schrieb:
> Weil Programmiersprachen vielleicht doch sehr auf den individuellen
> Geschmack (und individuelle Problemlösungen) angewiesen sind?

hört sich ja so an als wäre einen Neue Sprache keine riesen Zeit und 
Geld-Investition, das ist alles sehr Aufwändig und wird nicht einfach 
mal so gemacht

klarweise gibt es aber wirklich sehr viel "Versuche" die meist schnell 
wieder unrelevant werden, oder Sache die nur für Nischen relevant sind 
und einfach nie für den Mainstream gedacht sind

> Warum sprießen immerfort neue Sprachpilze aus dem Boden?

welche von denen haben länger gehalten und eine relevanz erreicht?
Alles Sprache die einfach so sprießen haben für die meisten Entwickler 
null bedeutung und sind einfach egal - ob sie aus Spass existieren oder 
nicht
- Es gibt kein Globales-Programmiersprachen-Mana das davon weniger wird 
bis nix mehr da ist, genau so wenig wie das n Kompiler nur die Resourcen 
verschwenden weil man sich ja auf einen konzentrieren könnte - ABER wenn 
die Menschen das so nicht wollen/interessiert ist das eine sinnlose 
Rechnung :)

> Ist das nicht Ausdruck ständiger Unzufriedenheit mit dem Vorhandenen?
> Ist das nicht Ausdruck der Unmöglichkeit einer "perfekten" Sprache?

so denken nur Anfänger - das kann und ist keine relevante Triebfeder
- unfährt genauso blöde wie 
wir-müssem-alles-dann-neuschreiben-sonst-ist-es-nicht-perfekt, 
nur-wenn-es-in-einer-Sprache-geschrieben-ist-ists-auch-gut Mentalität - 
alles total überholte Denke die man ein wenig Aufweichen kann

die meisten Menschen erwarten von einer neuen Programmiersprache 
dramatische Verbesserung ala - jetzt kann jeder das neue Doom39 
schreiben weil alles automatisch geht - aber das ist nie so - es gibt 
nur inkrementelle Verbesserung oder Micro-Revolutionen UND die werden 
dann meistens kaum verstanden weil mehr als 50% der Entwickler eh 
einfach nur die Sprache nutzt die der Chef befohlen hat :)

Mentalität, Erfahrung und die darauf basierenden Bedürfnisse sind so 
vielschichtig das es kaum möglich ist irgendwie einen direkt 
Begreifbaren Nenner zu finden - aber stehenbleiben war noch nie gut

Ich kann mir schwerlich vorstellen das wir in 200 Jahren (falls es uns 
da noch gibt) noch C/C++ Code schreiben - maximal pflegen wir noch ein 
paar Zeilen irgendwo auf dem Mars :)

von cppbert (Gast)


Lesenswert?

und nicht das ich falsch Verstanden werden - ich über die letzten 25 
Jahre  bisher mehrere x Million Zeilen Code, Multiplatform, C++ Projekte 
begonnen,
angeleitet und betreut (nebst .Net, Java, Python...) - ich kenne mich 
ein wenig aus :)

von cppbert (Gast)


Lesenswert?

Ich finde es auch super wie viele Entwickler (damit meine ich nicht 
unbedingt die anwesenden hier) und auch besonders Nicht-Entwickler, oder 
(die schlimmste Form) Pseudo-Entwickler sich über die vielfalt an 
Programmiersprachen aufregen obwohl sie nie wirklich Kontakt dazu haben 
- warum stresst Leute deren Existenz nur im geringsten und speziell die 
Leute mit dem geringsten Einfluss und technologischer Breite? so ein 
bisschen wie die Katholische Kirche und Neuerungen - die existenz ist 
schon bedrohlich :)

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


Lesenswert?

Ein T. schrieb:
>> Es gibt gab noch nie einen so ernsthaften Versuch eine bessere
>> alternative zu C oder C++ zu erschaffen,
>
> Aber ja doch, die Sprachen der PASCAL-Familie.

Die sind eher zeitgleich entstanden, und zumindest von der Entstehung 
her hatten beide sehr unterschiedliche Prämissen: Niklaus Wirth wollte 
eine schöne Sprache für die Lehre erschaffen (das ist Pascal ganz 
zweifellos), Brian Kernighan und Dennis Ritchie wollten eine Sprache 
erschaffen, die das mühevolle Coden eines Betriebssystems in Assembler 
ablösen kann (auch das ist ihnen ganz offensichtlich gelungen).

Insofern sind beide nebeneinander aufgewachsen, mit einer gewissen 
Konkurrenz, und Pascal hat viele Erweiterungen erfahren, aber C hatte 
natürlich im System-Umfeld die besseren Karten, die dann auch 
standardisiert worden sind.

An Firefox sieht man aber, dass es noch ein langer Weg sein wird: obwohl 
er ja meines Wissens eine der treibenden Kräfte hinter Rust war (und 
ist), die Zahl der Speicherlecks und Sicherheitsprobleme ist immer noch 
recht erheblich. Aber was ich lesen konnte, sind es wohl auch erst 20 %, 
die in Rust geschrieben sind.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> die Zahl der Speicherlecks und Sicherheitsprobleme ist immer noch
> recht erheblich.

Wie sieht diese "Statistik" denn für die Rust-Komponenten aus? Das ist 
ja, worauf es ankommt.
(Und Rust verhindert keine Speicherlecks, sondern erschwert sie nur.)

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


Lesenswert?

MaWin schrieb:

>> die Zahl der Speicherlecks und Sicherheitsprobleme ist immer noch
>> recht erheblich.
>
> Wie sieht diese "Statistik" denn für die Rust-Komponenten aus?

Keine Ahnung, ob es da eine gibt.

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> (Und Rust verhindert keine Speicherlecks, sondern erschwert sie nur.)

weil Speicherlecks für Systemprogrammierung (Hardware mapped Speicher 
usw.) nötig sein können - einer der wenigen Anwendungsfälle :)

von cppbert (Gast)


Lesenswert?

cppbert schrieb:
> MaWin schrieb:
>> (Und Rust verhindert keine Speicherlecks, sondern erschwert sie nur.)
>
> weil Speicherlecks für Systemprogrammierung (Hardware mapped Speicher
> usw.) nötig sein können - einer der wenigen Anwendungsfälle :)

UND man muss das auch gezielt sagen sonst gibt es keine ungewollten 
Leaks:

std::mem::forget
Box::leak
Box::into_raw bei unsafe

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


Lesenswert?

cppbert schrieb:

> weil Speicherlecks für Systemprogrammierung (Hardware mapped Speicher
> usw.) nötig sein können - einer der wenigen Anwendungsfälle :)

In einem Firefox sind sie aber eher unnötig. ;-)

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
>> weil Speicherlecks für Systemprogrammierung (Hardware mapped Speicher
>> usw.) nötig sein können - einer der wenigen Anwendungsfälle :)
>
> UND man muss das auch gezielt sagen sonst gibt es keine ungewollten
> Leaks:

Naja, der Grund ist eher, dass man Speicherlecks prinzipiell gar nicht 
100% verhindern kann.
Man kann in Rust ein Speicherleck ohne diese explizit leckenden 
Funktionen bauen, indem man eine Referenzschleife baut. So eine 
Referenzschleife ist dann von außen nicht mehr referenziert, aber erhält 
sich selbst weiterhin am Leben. Es ist damit ein Leck.

Die explizit leckenden Funktionen wie forget waren früher unsafe. Man 
hat dann aber erkannt, dass man auch ohne diese Funktionen Speicher 
lecken konnte. Und dann hat man forget safe gemacht.

Trotzdem ist es extrem schwierig versehentlich in Rust Speicher zu 
lecken.

von DPA (Gast)


Lesenswert?

MaWin schrieb:
> Man kann in Rust ein Speicherleck ohne diese explizit leckenden
> Funktionen bauen, indem man eine Referenzschleife baut.

Enttäuschend. Dass nichteinmal Rust es schafft, Memory Safty & 
praktische Brauchbarkeit unter einen Hut zu bringen... Den Level an 
Sicherheit krieg ich mit C++ smart Pointern auch...

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


Lesenswert?

MaWin schrieb:
> Trotzdem ist es extrem schwierig versehentlich in Rust Speicher zu
> lecken.

Was ich natürlich angesichts des sonstigen Fiaskos bei Firefox für ein 
mehr als wichtiges Feature halte.

Meinen Computer kann ich mittlerweile wochen- und monatelang (und rein 
technisch gesehen sogar jahrelang) durchlaufen lassen, nur der Firefox 
braucht immer mal einen "Reboot".

von cppbert (Gast)


Lesenswert?

DPA schrieb:
> MaWin schrieb:
>> Man kann in Rust ein Speicherleck ohne diese explizit leckenden
>> Funktionen bauen, indem man eine Referenzschleife baut.
>
> Enttäuschend. Dass nichteinmal Rust es schafft, Memory Safty &
> praktische Brauchbarkeit unter einen Hut zu bringen... Den Level an
> Sicherheit krieg ich mit C++ smart Pointern auch...

MaWin spricht von Cyclic Leaks - das bekommst du auch mit C++ 
Smartpointer hin - macht eben niemand - das lässt sich nicht "lösen" 
ohne das du eine Funktionale Programmiersprache nutzt

von Mombert H. (mh_mh)


Lesenswert?

cppbert schrieb:
> DPA schrieb:
>> MaWin schrieb:
>>> Man kann in Rust ein Speicherleck ohne diese explizit leckenden
>>> Funktionen bauen, indem man eine Referenzschleife baut.
>>
>> Enttäuschend. Dass nichteinmal Rust es schafft, Memory Safty &
>> praktische Brauchbarkeit unter einen Hut zu bringen... Den Level an
>> Sicherheit krieg ich mit C++ smart Pointern auch...
>
> MaWin spricht von Cyclic Leaks - das bekommst du auch mit C++
> Smartpointer hin - macht eben niemand - das lässt sich nicht "lösen"
> ohne das du eine Funktionale Programmiersprache nutzt

Eben, keine Pluspunkte für rusts Memory Safty an dieser Stelle.

von cppbert (Gast)


Lesenswert?

Mombert H. schrieb:
> cppbert schrieb:
>> DPA schrieb:
>>> MaWin schrieb:
>>>> Man kann in Rust ein Speicherleck ohne diese explizit leckenden
>>>> Funktionen bauen, indem man eine Referenzschleife baut.
>>>
>>> Enttäuschend. Dass nichteinmal Rust es schafft, Memory Safty &
>>> praktische Brauchbarkeit unter einen Hut zu bringen... Den Level an
>>> Sicherheit krieg ich mit C++ smart Pointern auch...
>>
>> MaWin spricht von Cyclic Leaks - das bekommst du auch mit C++
>> Smartpointer hin - macht eben niemand - das lässt sich nicht "lösen"
>> ohne das du eine Funktionale Programmiersprache nutzt
>
> Eben, keine Pluspunkte für rusts Memory Safty an dieser Stelle.

Das lässt sich in einer Imperative (Statefull-Sprache) nicht lösen (also 
.Net, Java, C, C++, und,und,und)
das ist kein KO-Kriterium für Rust - wer das nicht verstehe kann/will 
sollte sich Kommentare echt sparen, das wirkt nicht besonders Inteligent 
oder Erfahren was die Hintergründe bei allen von uns verwendeten 
Programmiersprachen sind

Wieder so eine sinnfreie Argumentation - wenn es nicht 100% Sicherheit 
erreicht mache ich mit meinen <10% weiter wie bisher, gleiche 
Argumentation wie bei der Corona-Impfung - wenn die nicht 100% wirkt 
warum soll ich es dann machen - weil sie eben 30-50% wirkt, oder der 
Sicherheitsgurt: Der garantiert auch keine 100% Sicherheit - dann kann 
ich den ja auch weg lassen

von DPA (Gast)


Lesenswert?

cppbert schrieb:
> <10%

.Net, Java, C++

cppbert schrieb:
> .Net, Java, C, C++, und,und,und

...

> mache ich mit meinen <10% weiter

.Net, Java, C++ (unter Verwendung von smart Pointen, wie heutzutage 
üblich), und <10%. lol.

Viel glück in Java einen use after free zu generieren, das ist da 
mindestens so gut wie rust, das zu verhindern. Rust mag beim Threading 
ein paar Vorteile haben, in der Theorie. Aber wenn du glaubst, die 
Alternativen wären derart unsicher, liegst du schlicht komplett falsch.

von Programmierer (Gast)


Lesenswert?

cppbert schrieb:
> warum stresst Leute deren Existenz nur im geringsten und speziell die
> Leute mit dem geringsten Einfluss und technologischer Breite?

Weil es an ihrem Weltbild zerrt.

Die allermeisten Menschen möchte einfache, simple Erklärungen wie die 
Welt funktioniert. Dann haben sie das Gefühl sie verstünden die Welt und 
könnten sich ein Urteil bilden, eine Meinung haben und mitdiskutieren.

Komplexität schreckt die meisten Menschen ab. Darum wird Komplexität 
verleugnet. Endstadium: Verschwörungstheorie.

von MaWin (Gast)


Lesenswert?

DPA schrieb:
> unter Verwendung von smart Pointen

Ich weiß, dass ich einem Troll antworte. Aber das Thema generell ist es 
schon wert noch einmal zu betrachten.

C++ Smart Pointer sind eine tolle Sache. Ich nutze sie in C++ auch 
gerne.
Aber was, wenn ich an einer Stelle vergesse sie zu verwenden? In Rust 
wird die Verwendung erzwungen.

Außerdem sind die Rust-Mechanismen (Referenzen, Pointer und Lifetimes) 
deutlich ausdrucksstärker und mächtiger als C++ Smart Pointers. Und auch 
besser zur Compilezeit prüfbar, durch die Rust-Referenzregeln und 
Lifetimes, die es in C++ beide nicht gibt.

von Ron T. (rontem)


Lesenswert?

Programmierer schrieb:
> Komplexität schreckt die meisten Menschen ab. Darum wird Komplexität
> verleugnet.

Stop! So wollte ich nicht verstanden werden. Niemand leugnet daß 
Programmierung oft komplexe Probleme lösen muß und daher nicht immer 
einfach ist. Hier aber ging es um die Frage warum die Bewertung der 
einzelnen Sprache so endlos diskutierbar ist und warum da täglich neue 
entstehen (müssen). Außerdem: Die Programmierung der Sachlage angemessen 
möglichst einfach und die Werkzeuge dazu möglichst geeignet zu halten 
hat nichts mit Verleugnung sondern eher mit Vernunft zu tun. Mal 
umgekehrt die Frage: Zieht Komplexität vielleicht manche Menschen an und 
sie versuchen diese zu mehren? Computerprogrammierung scheint sich ja 
hierfür besonders anzubieten!

von DPA (Gast)


Lesenswert?

MaWin schrieb:
> Aber was, wenn ich an einer Stelle vergesse sie zu verwenden?

Du tippst ausversehen "*" statt std::shared_ptr<> usw. ein? Komplett 
unabsichtlich?

> In Rust wird die Verwendung erzwungen.

Es gibt doch unsafe und raw pointer, wer verhindert, dass du die genauso 
"versehentlich" einsetzt?

MaWin schrieb:
> Außerdem sind die Rust-Mechanismen (Referenzen, Pointer und Lifetimes)
> deutlich ausdrucksstärker und mächtiger als C++ Smart Pointers. Und auch
> besser zur Compilezeit prüfbar, durch die Rust-Referenzregeln und
> Lifetimes, die es in C++ beide nicht gibt.

Ok, beim Threading ganz nützlich. Aber abgesehen davon sehe ich nur 
einen geringen Nutzen. Und dem gegenüber steht, mit dem borrow Checker 
kämpfen zu müssen. Was hab ich den nun wirklich davon?

von Mombert H. (mh_mh)


Lesenswert?

cppbert schrieb:
> Mombert H. schrieb:
>> Eben, keine Pluspunkte für rusts Memory Safty an dieser Stelle.
> Das lässt sich in einer Imperative (Statefull-Sprache) nicht lösen (also
> .Net, Java, C, C++, und,und,und)
> das ist kein KO-Kriterium für Rust - wer das nicht verstehe kann/will
> sollte sich Kommentare echt sparen, das wirkt nicht besonders Inteligent
> oder Erfahren was die Hintergründe bei allen von uns verwendeten
> Programmiersprachen sind
> Wieder so eine sinnfreie Argumentation - wenn es nicht 100% Sicherheit
> erreicht mache ich mit meinen <10% weiter wie bisher, gleiche
> Argumentation wie bei der Corona-Impfung - wenn die nicht 100% wirkt
> warum soll ich es dann machen - weil sie eben 30-50% wirkt, oder der
> Sicherheitsgurt: Der garantiert auch keine 100% Sicherheit - dann kann
> ich den ja auch weg lassen

Du überreagierst etwas ... nichts von dem was du unterstellst hast, habe 
ich geschrieben. Ich habe nichts von KO-Kriterium geschrieben und ich 
habe nicht Argumentiert. Ich habe jediglich geschrieben, dass es an 
dieser *Stelle* keine Pluspunkte für rust gibt.

Und natürlich ist dieses spezielle Problem in "Imperative 
(Statefull-Sprache)" lösbar. Ein garbage collector kann durchaus für 
alle Objekte prüfen, ob sie nur durch eine "Referenzschleife" am Leben 
erhalten werden. Wenn mit Referenzschleife etwas anderes gemeint ist, 
dann klärt mich auf.

MaWin schrieb:
> C++ Smart Pointer sind eine tolle Sache. Ich nutze sie in C++ auch
> gerne.
> Aber was, wenn ich an einer Stelle vergesse sie zu verwenden? In Rust
> wird die Verwendung erzwungen.
Ich weiß nicht wie man das vergessen soll. Du musst ja aktiv etwas 
anderes machen als den Smart-Pointer zu benutzen. Das ist eine bewusste 
Entscheidung.

: Bearbeitet durch User
von cppbert (Gast)


Lesenswert?

DPA schrieb:
> cppbert schrieb:
>> .Net, Java, C, C++, und,und,und

Da ging es um den Zyklus in der Referenzierung - gut da sind die GC 
Sprachen teilweise in der Lage zu aber wenn wir von Rust sprechen geht 
es eingentlich eher um C/C++

> Viel glück in Java einen use after free zu generieren, das ist da
> mindestens so gut wie rust, das zu verhindern. Rust mag beim Threading
> ein paar Vorteile haben, in der Theorie. Aber wenn du glaubst, die
> Alternativen wären derart unsicher, liegst du schlicht komplett falsch.

das sagt niemand und das ist hier auch immer der Irrglaube - die meisten 
Rust-Befürworter mögen die "Steigerung" der Sicherheit die andere Seite 
geht immer irgendwie davon aus man sich nicht auskennt, als wenn 
Smart-Pointer-Verwendung in C++ überhaupt in den letzten +15 Jahren 
jemals zur Diskussion standen - auch wenn Sie erst mit C++11 wirklich 
richtig schön implementierbar wurden, wir waren noch in den 90er als die 
Smartpointer relevant wurden, das ist ein alter Hut und trotzdem kann 
bis heute mit 3 von 10 Entwicklern immer doch darüber diskutieren ob man 
die einsetzen sollte - die Frage stellt sich bei Rust nicht - da ist das 
implizit

und btw: ohne ASAN würde man in C++ auch keine Use-After-Free so einfach 
finden - wenn man nicht alles zubaut mit Smart-Pointern, aber das dieser 
Luxus auch er wenige Jahre existiert und es immer noch sehr viele 
Entwickler gibt die denke das man Sanitizer gar nicht braucht erschreckt 
mich

und btw: die Sanitizer sind von Google, welche sagen sie bekommen das 
mit C++ und ihren Hochgeschultet Entwicklern nicht hin - trotz 
Smart-Pointer, bei fast 1Mrd. Zeilen C++, welche die selben sind die 
auch Rust in den Kernel pushen

aber das ist hier allen ja klar - so lange man nicht zwischen den Zeilen 
den Anfänger vermutet und entsprechen kontert

von cppbert (Gast)


Lesenswert?

Mombert H. schrieb:
> Du überreagierst etwas ... nichts von dem was du unterstellst hast, habe
> ich geschrieben. Ich habe nichts von KO-Kriterium geschrieben und ich
> habe nicht Argumentiert. Ich habe jediglich geschrieben, dass es an
> dieser Stelle keine Pluspunkte für rust gibt.

Sorry - du hast absolut recht, ich dich wirklich falsch verstanden

von Mombert H. (mh_mh)


Lesenswert?

cppbert schrieb:
> das ist ein alter Hut und trotzdem kann
> bis heute mit 3 von 10 Entwicklern immer doch darüber diskutieren ob man
> die einsetzen sollte - die Frage stellt sich bei Rust nicht - da ist das
> implizit
Da sind wir wieder bei PYTRAN77. Glaubst du wirklich, dass Entwickler, 
die es in C++ nicht hinbekommen (weil unfähig oder unwillig) konsistent 
Smart-Pointer einzusetzen, zu rust wechseln und alle Probleme sind 
verschwunden? Wo sollen da plötzlich die zusätzlichen Gehirnzellen oder 
der Wille herkommen?

cppbert schrieb:
> und btw: die Sanitizer sind von Google, welche sagen sie bekommen das
> mit C++ und ihren Hochgeschultet Entwicklern nicht hin - trotz
> Smart-Pointer, bei fast 1Mrd. Zeilen C++, welche die selben sind die
> auch Rust in den Kernel pushen

Vielleicht weil sie in ihren C++-Regeln
1
*Prefer* to have single, fixed owners for dynamically allocated objects. *Prefer* to transfer ownership with smart pointers.
zu viele "prefer" haben?

von cppbert (Gast)


Lesenswert?

DPA schrieb:
> Du tippst ausversehen "*" statt std::shared_ptr<> usw. ein? Komplett
> unabsichtlich?

das ist wieder viel zu detailiert - du, ich und MaWin benutzen alle 
schon garantiert lange und kontinuilierich Smart-Pointer - das steht 
ausser Frage sonst bräuchte keiner von uns hier irgenwie mitreden

Rust macht den Unterschied as ein Goßteil der üblichen Smart-Pointer 
Verschmutzung deiner Schnistellen ins Type-System verschoben wird - das 
ist ein nicht zu kleiner Teil des Codes - und stören Smart-Pointer auch 
nicht - aber wenn ich Sie nicht schreiben muss und noch Ausdrucksstärker 
sein kann, warum nicht?

btw: ich habe noch nicht erlebt das ein guter C++ Entwickler probleme 
hatte mit dem Borrow-Checker, der forciert nur Struktur-Strategien die 
eh üblich sind, nur die Drauf-los-Bastel-Fraktion die noch viel 
ausprobieren muss tut sich damit schwer - aber wer will die den in 
seinem Code rumorgeln lassen
das ist z.B. genau der Teil der Entwickler die tunlichst die Finger von 
Kernelentwicklung lassen sollten

und die ganze Argumentation endet irgendwie immer in - mir reicht der 
Vorteil nicht, ich mag das nicht, unrelevant für mich, ungebraucht von 
mir - das ist in Ordnung aber ist keine ordentliche Diskussion möglich 
wenn jemand der keinen Sinn an dem Ownership-Modell sieht und 
Smart-Pointer als ausreichende Lösung empfindet gegen einen 
Rust-nett-Finder argumentiert
Das ist so wie wenn ein Milch-Trinker mit einem Wiskey-Liebhaber 
diskutiert - das kommt nichts bei raus...

von MaWin (Gast)


Lesenswert?

DPA schrieb:
> Was hab ich den nun wirklich davon?

Garantierte Memory-Safety.

von MaWin (Gast)


Lesenswert?

Mombert H. schrieb:
> Ich weiß nicht wie man das vergessen soll

Komisch, wo dann ständig die ganzen Memory-Safety-Bugs herkommen.

von cppbert (Gast)


Lesenswert?

Mombert H. schrieb:
> Da sind wir wieder bei PYTRAN77. Glaubst du wirklich, dass Entwickler,
> die es in C++ nicht hinbekommen (weil unfähig oder unwillig) konsistent
> Smart-Pointer einzusetzen, zu rust wechseln und alle Probleme sind
> verschwunden? Wo sollen da plötzlich die zusätzlichen Gehirnzellen oder
> der Wille herkommen?

Nein nicht alle, das wäre dumme zu denken, aber Sie können sich mehr auf 
die logischen oder strukturellen Probleme konzentrieren - damit haben 
die ja auch schon Probleme :) - was bringt es uns Sie damit zusätzlich 
zu belasten (mal außen vor gelassen das es noch viel C++ gibt und die 
das eh machen müssen)

und wie gesagt - ich kann sehr gute C++ Software schreiben, ich kämpfe 
nicht mit C++ Probleme, oder ich habe genug Erfahrung das richtige zu 
tun - aber ich verstehe, wenn ich teilweise in +100 Entwickler-Teams 
sitze das meine eigenen Bedürfnisse und Fähigkeite nicht automatisch für 
das Team relevant sind
und DAS ist der Unterschied - der Maßstab bei dem Rust-Features anfangen 
mehr Bedeutung zu bekommen - jedes mal wenn einer aus der 
Ich-Perspektive Argumentiert sitzt er alleine da und denk nicht an das 
Team und die Million von Entwicklern die auf der Welt verteilt sind - 
dafür werden bessere Programmiersprachen entwickelt - unabhängig davon 
ob die angenommen werden oder wegen sinnlosigkeit sterben

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> Mombert H. schrieb:
>> Ich weiß nicht wie man das vergessen soll
> Komisch, wo dann ständig die ganzen Memory-Safety-Bugs herkommen.
Vielleicht haben sie sich gegen Smart-Pointer entschieden? Es gibt noch 
alternativen zum Vergessen.

An dieser Stelle muss ich dich an einen deiner früheren Beiträge 
erinneren.
MaWin schrieb:
> Mombert, dir antworte ich übrigens nicht mehr, falls du es noch nicht
> gemerkt hast.
Hast du vergessen, dass du mir nicht mehr antwortest, oder hast du dich 
anders entschieden?

von DPA (Gast)


Lesenswert?

Mombert H. schrieb:
> MaWin schrieb:
>> Mombert H. schrieb:
>>> Ich weiß nicht wie man das vergessen soll
>> Komisch, wo dann ständig die ganzen Memory-Safety-Bugs herkommen.
> Vielleicht haben sie sich gegen Smart-Pointer entschieden? Es gibt noch
> alternativen zum Vergessen.

Das könnte man vermutlich ganz einfach mit einem Linter fixen, der 
einfach keine normalen Pointer akzeptiert. Dann setzt man das als git 
hook im Repo, um es zu erzwingen. Und schon sind 99% der Probleme weg.

von cppbert (Gast)


Lesenswert?

Mombert H. schrieb:
> Vielleicht weil sie in ihren C++-Regeln*Prefer* to have single, fixed
> owners for dynamically allocated objects. Prefer to transfer ownership
> with smart pointers.
> zu viele "prefer" haben?

und wir sind wieder bei dem die haben wohl schlechte Regeln oder 
schlechte Mitarbeiter Argumentation - google investiert viel Zeit und 
Geld in seine Mitarbeiter, was sollen die sonst noch tun - auf bessere 
Zeiten hoffen? damit ihre zig tausend Entwickler so gut werden das die 
Testabteilung:Weltbevölkerung bei denen keine Fehler mehr findet, das 
ist irrglaube in diesem Dimensionen, deswegen haben die google Leute die 
Sanitizer entwickelt und dann nach ein paar Jahren festgestellt das es 
immer noch nicht reicht - welche Firma die nicht so gross ist betreibt 
denn noch so einen Aufwand um besser zu werden?

Die Realität ist: Es wird zu wenig getestet, die Projekte werden immer 
komplexer, das erschwert das testen weiter, TDD ist nicht die Lösung, 
bessere Mitarbeitet ist der feuchte Traum jeden Abteilungsleiters und 
der menschliche Faktor ist schwierig zu kontrollieren - vielleicht in 
den 15 Mann Buden in denen wir alle mal hin und wieder gearbeitet haben 
aber nicht für zig-tausend Entwickler - und das bedeutet nicht das wir 
alle und alle Firmen ständig leakend und abstürzenden C++ Programme 
schreiben - absolut nicht

von Mombert H. (mh_mh)


Lesenswert?

cppbert schrieb:
> Mombert H. schrieb:
>> Da sind wir wieder bei PYTRAN77. Glaubst du wirklich, dass Entwickler,
>> die es in C++ nicht hinbekommen (weil unfähig oder unwillig) konsistent
>> Smart-Pointer einzusetzen, zu rust wechseln und alle Probleme sind
>> verschwunden? Wo sollen da plötzlich die zusätzlichen Gehirnzellen oder
>> der Wille herkommen?
>
> Nein nicht alle, das wäre dumme zu denken, aber Sie können sich mehr auf
> die logischen oder strukturellen Probleme konzentrieren - damit haben
> die ja auch schon Probleme :) - was bringt es uns Sie damit zusätzlich
> zu belasten (mal außen vor gelassen das es noch viel C++ gibt und die
> das eh machen müssen)

Nur weil sie in rust dazu gezwungen werden es richtig zu machen, heißt 
nicht, dass sie es automatisch sofort richtig machen können. rust nimmt 
einem nicht die Arbeit ab, es richtig zu machen. Man wird nur dazu 
gezwungen es auf die rust-Art zu machen, die in den allermeisten Fällen 
zu mehr Sicherheit führt.
Es ist auch nicht so, als wäre es in C++ wirklich schwierig es richtig 
zu machen, wenn man es will.

von cppbert (Gast)


Lesenswert?

DPA schrieb:
> Mombert H. schrieb:
>> MaWin schrieb:
>>> Mombert H. schrieb:
>>>> Ich weiß nicht wie man das vergessen soll
>>> Komisch, wo dann ständig die ganzen Memory-Safety-Bugs herkommen.
>> Vielleicht haben sie sich gegen Smart-Pointer entschieden? Es gibt noch
>> alternativen zum Vergessen.
>
> Das könnte man vermutlich ganz einfach mit einem Linter fixen, der
> einfach keine normalen Pointer akzeptiert. Dann setzt man das als git
> hook im Repo, um es zu erzwingen. Und schon sind 99% der Probleme weg.

wir nutzen doch schon alle Linter bis zum Umfallen, und git, perforce, 
svn Hooks ein für jeden Scheiss - die sau-teueren und die freeware, open 
source sachen - man findet immer und immer wieder Sachen, die Menge geht 
nicht runter - es ist immer noch stark an der eingetragenen 
Quelltextmenge fest zu machen - und das scheint bei vielen Firmen der 
Fall zu sein - ob du das so kennst ist eine andere Sachen, aber es 
existiert

von MaWin (Gast)


Lesenswert?

DPA schrieb:
> Und schon sind 99% der Probleme weg.

Wenn man sich am Riemen reißt und alles richtig programmiert, dann sind 
sogar 100% der Probleme weg. Einfach keine Fehler machen und alles ist 
gut.

Der Vorteil von Rust ist, dass diese Fehler dort gar nicht möglich sind.

von cppbert (Gast)


Lesenswert?

Mombert H. schrieb:
> Nur weil sie in rust dazu gezwungen werden es richtig zu machen, heißt
> nicht, dass sie es automatisch sofort richtig machen können. rust nimmt
> einem nicht die Arbeit ab, es richtig zu machen. Man wird nur dazu
> gezwungen es auf die rust-Art zu machen, die in den allermeisten Fällen
> zu mehr Sicherheit führt.

Das hört sich eingezwänger als als es tatsächlich ist

> Es ist auch nicht so, als wäre es in C++ wirklich schwierig es richtig
> zu machen, wenn man es will.

"man will" ist und bleibt das Kernproblem das man versucht (irgendwie) 
zu adressieren - wenn man das als sinnlos empfindet bringt Rust an 
dieser Stelle einfach nicht viel - weil es kein Problem gibt - oder 
Probleme nicht reduziert werden können (die Natur der Sache)

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> Das hört sich eingezwänger als als es tatsächlich ist

Genau. Der Rust-Compiler gibt einem sehr gute Hinweise und die 
Compilerfehlerdokumentation ist auch sehr hilfreich. Das ist gar nicht 
vergleichbar mit den kryptischen Kram, den GCC und MSVC so rauswerfen.

In der Regel steht die Lösung für das Problem, oder ein Vorschlag, der 
der Lösung bereits sehr nahe kommt, in der rustc-Fehlermeldung mit drin. 
Und wenn nicht, dann findet man in der zugehörigen, direkt vom Compiler 
verlinkten, Dokumentation eine genaue Erklärung, warum das nicht gut 
ist, was man da tut.

cppbert schrieb:
> "man will" ist und bleibt das Kernproblem das man versucht (irgendwie)
> zu adressieren - wenn man das als sinnlos empfindet bringt Rust an
> dieser Stelle einfach nicht viel

Es geht über den reinen Willen hinaus.
Rust hat einfach einige sehr unschöne Altlasten nicht, die C/C++ 
mitbringt. Zum Beispiel Integer-Promotion, Typbalancierung und implizite 
Typwandlungen gibt es alle in Rust nicht. Und Bugs ausgelöst durch diese 
Altlasten haben wohl die meisten Programmierer einmal versehentlich 
gemacht.
Es ist insgesamt viel schwieriger solche grundlegenden und nicht direkt 
offensichtlichen Fehler zu machen.

von cppbert (Gast)


Lesenswert?

Und diese ganze Smart-Pointer Aussage ist auch ohne Relevanz wenn wir 
von C sprechen - oder will hier ernsthaft jemand behaupten das er jemals 
diese fiesen Macro-basierte Smart-Pointer libs für C genutzt hat?

im Embedded-Breich ist C eben z.B. auch deswegen stark weil es definitiv 
gar keine Runtime Braucht, im gegensatz zu C++ wegen Execptions (die auf 
dem Heap landen) - das ist z.B. auch ein Grund warum sich C++ da so 
nicht durchsetzt

Rust hat diese Nachteile nicht - genau wie C keine Runtime nötig (gut so 
lange man auf Standard-Async verzichtet) und trotzdem hat man dort die 
Sicherheit
die mit sonst manuell eingebrachten Smart-Pointern

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


Lesenswert?

cppbert schrieb:
> das ist z.B. auch ein Grund warum sich C++ da so nicht durchsetzt

Wobei man auf Exceptions ja durchaus auch verzichten kann, wenn das das 
einzige Problem wäre. Andererseits sind sie natürlich nett, wenn man sie 
hat, weil man sich dann so ein error code passing über 5 Etagen sparen 
kann.

von Mombert H. (mh_mh)


Lesenswert?

cppbert schrieb:
> im Embedded-Breich ist C eben z.B. auch deswegen stark weil es definitiv
> gar keine Runtime Braucht, im gegensatz zu C++ wegen Execptions (die auf
> dem Heap landen) - das ist z.B. auch ein Grund warum sich C++ da so
> nicht durchsetzt
Bist du sicher, dass das der Grund ist? Oder ist es vielleicht nur ein 
Vorwand der "Ich will nicht"-Fraktion?
Denn auch C braucht eine Runtime, wenn man die ganze Sprache nutzen will 
und man kommt in C++ ohne Exceptions aus, wenn man nicht die ganze 
Sprache nutzt. Und das gleiche gilt für rust, wie du selbst feststellst 
("gut so lange man ...").

> Rust hat diese Nachteile nicht - genau wie C keine Runtime nötig (gut so
> lange man auf Standard-Async verzichtet) und trotzdem hat man dort die
> Sicherheit
> die mit sonst manuell eingebrachten Smart-Pointern

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


Lesenswert?

Mombert H. schrieb:
> Denn auch C braucht eine Runtime

Wobei diese schon sehr minimalistisch ist: Ausnullen von .bss, 
Initialisieren von .data, Setzen des Stackpointers.

von cppbert (Gast)


Lesenswert?

Mombert H. schrieb:
> cppbert schrieb:
>> im Embedded-Breich ist C eben z.B. auch deswegen stark weil es definitiv
>> gar keine Runtime Braucht, im gegensatz zu C++ wegen Execptions (die auf
>> dem Heap landen) - das ist z.B. auch ein Grund warum sich C++ da so
>> nicht durchsetzt
> Bist du sicher, dass das der Grund ist? Oder ist es vielleicht nur ein
> Vorwand der "Ich will nicht"-Fraktion?

ja das auf jeden Fall auch

> Denn auch C braucht eine Runtime, wenn man die ganze Sprache nutzen will

die Sprache kommt ohne Runtime aus - oder meinst du die Standard 
Library?

von rbx (Gast)


Lesenswert?

cppbert schrieb:
> ich verstehe nie so wirklich was du sagen willst

Das ist jetzt aber nicht mein Problem :)

cppbert schrieb:
> ist eine Rust-CUDA
> Wrapper jetzt nicht Nische, oder Nische?

Das mit dem "Gesucht" war ergänzend zum Nischenargument gemeint, und 
würde zusammen mit dem Nischen-Vorwurf in DPAs Runterwertungsschublade 
passen.

Also "Nische" + "Gesucht".

Dass der Link auch zweideutig gemeint war, hast du nicht mitbekommen - 
möglicherweise, weil du den etwas zu ernst genommen hast.

von Mombert H. (mh_mh)


Lesenswert?

Jörg W. schrieb:
> Mombert H. schrieb:
>> Denn auch C braucht eine Runtime
>
> Wobei diese schon sehr minimalistisch ist: Ausnullen von .bss,
> Initialisieren von .data, Setzen des Stackpointers.
Ich hätte jetzt noch die Buchführung für malloc und Co aufgelistet, aber 
das ist optional.

cppbert schrieb:
> Mombert H. schrieb:
>> cppbert schrieb:
>>> im Embedded-Breich ist C eben z.B. auch deswegen stark weil es definitiv
>>> gar keine Runtime Braucht, im gegensatz zu C++ wegen Execptions (die auf
>>> dem Heap landen) - das ist z.B. auch ein Grund warum sich C++ da so
>>> nicht durchsetzt
>> Bist du sicher, dass das der Grund ist? Oder ist es vielleicht nur ein
>> Vorwand der "Ich will nicht"-Fraktion?
> ja das auf jeden Fall auch
>> Denn auch C braucht eine Runtime, wenn man die ganze Sprache nutzen will
> die Sprache kommt ohne Runtime aus - oder meinst du die Standard
> Library?
Für mich gehört die Standard Bibliothek zur Sprache. Beide werden in 
einem Dokument mit der überschrift "Programming languages — C" definiert 
und nicht streng getrennt.

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


Lesenswert?

Mombert H. schrieb:

> Ich hätte jetzt noch die Buchführung für malloc und Co aufgelistet, aber
> das ist optional.

Viele mögen es im (deeply) embedded nicht, wenngleich ich das nicht 
immer nachvollziehen kann. ;-)

Ja, könnte man dazu zählen.

> Für mich gehört die Standard Bibliothek zur Sprache. Beide werden in
> einem Dokument mit der überschrift "Programming languages — C" definiert
> und nicht streng getrennt.

Zumal der Compiler ja auch implizites Wissen darüber haben darf und 
beispielsweise ein "strlen("Hi")" direkt durch die Konstante 2 ersetzen 
darf.

von cppbert (Gast)


Lesenswert?

Mombert H. schrieb:
> Für mich gehört die Standard Bibliothek zur Sprache. Beide werden in
> einem Dokument mit der überschrift "Programming languages — C" definiert
> und nicht streng getrennt.

auf embedded kann es aber sein das du die Runtime komplett ersetzen 
willst, das geht mit C und Rust - aber nicht mit C++ - weil du die 
Exceptions nur vermeiden kannst aber da ist die Runtime trotzdem (oder 
kann man das mitlerweile auch entfernen? aber dann wieder 
Kompiler-Spezifisch)

z.B. der Linux Kernel nutzt ja auch seine "eigene" Standard-Library weil 
er die GlibC klarerweise nicht nutzen kann

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


Lesenswert?

cppbert schrieb:
> Linux Kernel nutzt ja auch seine "eigene" Standard-Library

Ist ja egal, das ist dann alles "the implementation". Wichtig ist ja 
nur, dass sie zumindest die Teile, die wirklich benutzt werden, dann 
auch so implementiert, wie es der Sprachstandard will. Also 
"strlen("Hi")" sollte in der geänderten Version nicht gerade 42 zurück 
geben. ;-)

von Mombert H. (mh_mh)


Lesenswert?

cppbert schrieb:
> Mombert H. schrieb:
>> Für mich gehört die Standard Bibliothek zur Sprache. Beide werden in
>> einem Dokument mit der überschrift "Programming languages — C" definiert
>> und nicht streng getrennt.
>
> auf embedded kann es aber sein das du die Runtime komplett ersetzen
> willst, das geht mit C und Rust - aber nicht mit C++ - weil du die
> Exceptions nur vermeiden kannst aber da ist die Runtime trotzdem (oder
> kann man das mitlerweile auch entfernen? aber dann wieder
> Kompiler-Spezifisch)
Die C-Runtime unabhängig vom Compiler zu ersetzen, dürfte ne 
interessante Aufgabe sein. Wie schafft man es z.B. eine stdarg.h oder 
float.h zu erstellen, ohne auf die Eigenheiten des Compilers einzugehen?

: Bearbeitet durch User
von cppbert (Gast)


Lesenswert?

Mombert H. schrieb:
> Wie schafft man es z.B. eine stdarg.h oder
> float.h zu erstellen

ja das wird schwierig - one aligment-Wissen wird das nix - ok mit C11 
bekommt man das alignof noch raus usw. aber bastelig ist es definitiv

von DPA (Gast)


Lesenswert?

Wie ist in Rust eigentlich die async / await Geschichte implementiert?

Mein momentaner Wissensstand ist, dass async Funktionen analog zu 
co-routinen sind / man das eine mittels dem anderen implementieren kann. 
co-routinen, und damit async funktionen, bräuchten damit einen 
zusätzlichen Stack.

Ist das bei Rust auch so, braucht der Aufruf jeder async funktion einen 
eigenen Stack? Oder wurde da eine bessere Methode gefunden, das 
umzusetzen?

Ich kenne async-await hauptsächlich von javascript und python her, es 
ist unglaublich praktisch. Falls ich mal meine eigene Programmiersprache 
entwickle, würde ich so ein feature auch wollen. Aber ich will nicht 
wirklich den Preis, den Speicher & Adressraum für mehrere Stacks, 
zahlen. Insbesondere wenn man auf tausende Sachen wartet, wie verhindert 
man da dass das enorm Speicher verbraucht? Und wie verhindert man, dass 
sich die Stacks in die quere kommen? Ich konnte das bisher noch nicht 
heraus finden.

von Kaj (Gast)


Lesenswert?

DPA schrieb:
> Wie ist in Rust eigentlich die async / await Geschichte implementiert?
https://rust-lang.github.io/async-book/01_getting_started/02_why_async.html
1
Async in Rust vs other languages
2
3
Although asynchronous programming is supported in many languages, some details vary across implementations. Rust's implementation of async differs from most languages in a few ways:
4
5
[...]
6
7
Async is zero-cost in Rust, which means that you only pay for what you use. Specifically, you can use async without heap allocations and dynamic dispatch, which is great for performance! This also lets you use async in constrained environments, such as embedded systems.
8
9
[...]

von cppbert (Gast)


Lesenswert?

...und die Runtime für Async ist austauchbar - damit man keinen Standard 
für alle definiert der dann in der Systemprogrammierung eh nie passt :)

das macht das ganze aber ein bisschen komplizierter, weil man die Wahl 
zwischen verschiedenen Backends die nicht unbedingt von den Rust-Leuten 
selber kommen - das stört die Alles-aus-einer-Hand-Fraktion ein wenig

von DPA (Gast)


Lesenswert?

> Async is zero-cost in Rust, which means that you only pay for what you use.

Das ist ja gute Werbung, aber mich interessiert: Was heisst das, und wie 
geht das? Nehmen wir gerade mal das Beispiel auf der Seite:
1
async fn get_two_sites_async() {
2
    // Create two different "futures" which, when run to completion,
3
    // will asynchronously download the webpages.
4
    let future_one = download_async("https://www.foo.com");
5
    let future_two = download_async("https://www.bar.com");
6
7
    // Run both futures to completion at the same time.
8
    join!(future_one, future_two);
9
}

Um mal zu illustrieren, was mir unklar ist, nehmen wir mal folgenden 
execution flow, und nur einen Stack an:
1
get_two_sites_async
2
  join!
3
    future_one (download_async)
4
      ruft ne funktion auf
5
        muss auf IO warten
6
          future_two (download_async)
7
            ruft ne funktion auf
8
              muss auf IO warten
9
    future_one wird fortgesetzt
10
      ruft ne funktion auf  >>> (Wo landet das jetzt auf dem Stack?)
11
    future_one ist fertig
12
              future_two (wird fortgesetzt)  >>> (Wo liegt das jetzt auf dem Stack? Ist da jetzt einfach ne lücke, wo future_one war?)

Wie haben die das gelöst? Wie geht das?
Oder gibt es da 2 Stacks, auch in rust, und zero-cost heisst da nur 
Bestmöglich, statt effektiv gratis?

cppbert schrieb:
> ...und die Runtime für Async ist austauchbar - damit man keinen Standard
> für alle definiert der dann in der Systemprogrammierung eh nie passt :)

Ok, heisst das, dass halt die Runtime den Kompromiss machen müssen, und 
dort die Kosten entstehen, mehrere Stacks zu brauchen, während die API 
selbst prinzipiell schon zero-cost wäre?

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


Lesenswert?

DPA schrieb:
> Ok, heisst das, dass halt die Runtime den Kompromiss machen müssen, und
> dort die Kosten entstehen, mehrere Stacks zu brauchen, während die API
> selbst prinzipiell schon zero-cost wäre?

Wäre jetzt auch meine Vermutung. Ich wüsste zumindest nicht, wie man für 
threading mehrere Stacks vermeiden will. In einem VM-System kann 
natürlich jeder seinen eigenen VM-Bereich bekommen, der sich dann auch 
automatisch vergrößern lässt, auf einem Controller wird man wohl oder 
übel vorab Stacks definieren müssen.

von Mombert H. (mh_mh)


Lesenswert?

DPA schrieb:
> Oder gibt es da 2 Stacks, auch in rust, und zero-cost heisst da nur
> Bestmöglich, statt effektiv gratis?

Ich wüsste nicht wie man alles auf einem Stack realisieren könnte. Dafür 
müsste jedes mal wenn der Stack manipuliert wird, ein riesen Aufwand 
getrieben werden. Oder der Stack, den jeder async sieht hat eine 
festgelegte maximale Größe, die beim Aufruf festgelegt wird.

von cppbert (Gast)


Lesenswert?

DPA schrieb:
> cppbert schrieb:
>> ...und die Runtime für Async ist austauchbar - damit man keinen Standard
>> für alle definiert der dann in der Systemprogrammierung eh nie passt :)
>
> Ok, heisst das, dass halt die Runtime den Kompromiss machen müssen, und
> dort die Kosten entstehen, mehrere Stacks zu brauchen, während die API
> selbst prinzipiell schon zero-cost wäre?

ja ich glaube das es so ist - aber vielleicht kann MaWin uns da mehr 
erleuchten - Rust versucht so viel wie möglich mit Move oder 
trivial-Copy zu machen - vielleicht heisst das hier auch 
Nearly-Zero-Copy

das ist mir im Detail auch noch nicht klar wie die das machen - ich gehe 
auch davon aus das man n Stacks haben muss

ich hab auch gelesen das die Runtime nicht notwendigerweise alles mit 
Threads machen muss - also auch so co-routine Style im Hintergrund 
moeglich, weil eben die Kleinst-Systeme vielleicht nur ein paar 
statische Puffer am auf denen sie operieren dürfen

Ich fordere Tiefen-Erleuchtung!

von Jemand (Gast)


Lesenswert?

DPA schrieb:
> Wie haben die das gelöst? Wie geht das?
> Oder gibt es da 2 Stacks, auch in rust, und zero-cost heisst da nur
> Bestmöglich, statt effektiv gratis?

Eine Async-Funktion in Rust unterbricht ihre Ausführung nur an 
.await-Stellen, dazwischen arbeitet sie grundsätzlich synchron. Zur 
Fortsetzung muss die Runtime wieder die poll-Methode aufrufen. Von jeder 
Unterbrechung bis zur Fortsetzung liegen die benötigten lokalen 
Variablen im Future-Objekt selbst. Die Größe des Future-Objekts ist 
statisch bekannt, da alle lokale Variablen eine bekannte Größe haben 
müssen. Als Konsequenz sind jedoch rekursive async-Aufrufe nicht in sich 
geschlossen möglich; dort kommt man um die Nutzung des Heaps meist nicht 
herum.
Die Async-Sprachintegration ist im Grunde Syntaxzucker zur Erstellung 
von Zustandsautomaten (->Future).
Die Anzahl der benötigten Stacks beläuft sich also auf genau die Anzahl 
der Async-Worker-Threads.

von cppbert (Gast)


Lesenswert?

https://www.reddit.com/r/rust/comments/w4cwvj/how_much_zerocost_is_async/

>
> Async functions desugar to something that looks a bit like an enum, with each 
variant representing a section between await points (and the associated state it 
needs).
>
> There's no reason for anything to be heap allocated, because the entire 
structure is known at compile time. You can put a future on the heap if you want, 
but you can just use impl Future if you don't want to (this is what an async fn 
does).
>
>There is one major exception: traits. Async functions in traits are currently not 
possible, but something quite similar can be achieved using the async-trait crate. 
This performs some of the same rewriting that the compiler does with regular async 
functions, but for various reasons, it needs to allocate futures on the heap.
>
>However, this restriction is expected to be lifted. Generic associated types 
(GATs) are one of the key blockers, and are close to being stabilized, but there 
are still some unresolved issues. However, it's possible that GATs can be used to 
implement "async fn in traits" before they are stabilized as a user-facing 
feature.
>

Beitrag #7134604 wurde vom Autor gelöscht.
von rbx (Gast)


Lesenswert?

Jörg W. schrieb:
> auf einem Controller wird man wohl oder
> übel vorab Stacks definieren müssen.

Kommt drauf an, auf dem Raspi könnte man auch OS-Ressourcen benutzen. 
Fragen könnte man sich, wie die Rust-Entwickler das mit der intensiven 
Cachenutzung und dem Alignment hinbekommen haben.
Man kann aber ahnen, worauf es hinausläuft.
Besondere Bibliotheken, bzw. Unterstützung für Embedded soll es auch 
geben.

Wer Assembler kennt, und C, der weiß auch, dass vieles einfach über 
Zeiger läuft.
(oder Basic, goto xy)
Speichermanagement mit statischen Variablen stelle ich mir auch nicht 
sonderlich schwierig vor.

Hinzu kommt, dass bei so Compilergeschichten und Programmiersprachen 
vieles letztendlich über C läuft, da braucht man sich über "kostenlose" 
Unterfunktionen in C nicht wundern.
Parameterübergabe kann man sich ja mal in Haskell ansehen - Ich bin da 
sicher nicht der einzige, dem es diesbezüglich ein wenig an Pragmatik 
fehlt.

Wenn im Hexeditor zwischen zwei Funktionen zuviel Platz erkennbar ist - 
nun, dafür hat man ja auch einen Hexeditor :)

Die eine gute Analogie wäre: neues Motorrad, viel PS und schnell, 
Superhandling, aber Elektroantrieb.

Mir würde der gute Sound fehlen, aber es gibt auch Leute, die fragen 
nach dem Ölverbrauch ;)

von cppbert (Gast)


Lesenswert?

rbx schrieb:

hier gibt es ordentlich Klärungsbedarf - du hast mich wieder mal 
verwirrt

> Kommt drauf an, auf dem Raspi könnte man auch OS-Ressourcen benutzen.

was sind OS-Ressourcen beim Raspi? irgendwelche In-Kernel Bereiche, ist 
das nicht Raspi-OS nicht einfach Linux, da kenn ich sowas nicht

> Fragen könnte man sich, wie die Rust-Entwickler das mit der intensiven
> Cachenutzung und dem Alignment hinbekommen haben.

was meinst du mit hinbekommen?

> Wer Assembler kennt, und C, der weiß auch, dass vieles einfach über
> Zeiger läuft.
> (oder Basic, goto xy)

das ist doch der 90% Fall, oder?
und welche Gemeinsamkeit haben Zeiger und goto?

> Hinzu kommt, dass bei so Compilergeschichten und Programmiersprachen
> vieles letztendlich über C läuft, da braucht man sich über "kostenlose"
> Unterfunktionen in C nicht wundern.

was sind "kostenlose" Unterfunktionen bei C?

> Parameterübergabe kann man sich ja mal in Haskell ansehen - Ich bin da
> sicher nicht der einzige, dem es diesbezüglich ein wenig an Pragmatik
> fehlt.

hat Haskell Parameterübergabe ähnlichkeit zu Async-Stacks?

> Wenn im Hexeditor zwischen zwei Funktionen zuviel Platz erkennbar ist -
> nun, dafür hat man ja auch einen Hexeditor :)

Für was ist denn der Platz? Normalerweise doch für gar nichts ausser 
Alignment, oder was meinst du?

von Programmierer (Gast)


Lesenswert?

Async/Await benötigt in keiner Programmiersprache eigene Stacks pro 
"Warte-Stelle" oder Async-Funktion.

Der Witz an Async/Await ist doch genau der, dass das nur Syntax-Zucker 
für Callbacks ist. Async/Await sind eben genau keine Threads, weder 
OS-Threads noch Green-Threads.

Ganz Allgemein macht ein Compiler aus
1
  funtion a() {
2
    teil_vorher();
3
    ergebnis = await async_funtion();
4
    teil_nachher();
5
  }

zwei Funktionen, und der Teil nach dem await() wird eine 
Callback-Funktion der async-Funktion:

Also etwa:
1
  funtion a_impl() {
2
    teil_vorher();
3
    async_funktion_impl(&a_weiter_impl);
4
  }
5
6
  funktion a_weiter_impl(ergebnis_von_async_funktion) {
7
    teil_nachher();
8
  }

Natürlich kommt da noch ein wenig Brimborium dazu, und in manchen 
Sprachen, z.B. Rust, wird noch etwas mehr gemacht. Aber das Grundprinzip 
ist immer gleich: Keine Threads, sondern nur eine State-Maschine die mit 
Callbacks implementiert ist.

von cppbert3 (Gast)


Lesenswert?

Programmierer schrieb:
> Async/Await benötigt in keiner Programmiersprache eigene Stacks
> pro "Warte-Stelle" oder Async-Funktion.
> Der Witz an Async/Await ist doch genau der, dass das nur Syntax-Zucker
> für Callbacks ist. Async/Await sind eben genau keine Threads, weder
> OS-Threads noch Green-Threads.

Ok aber wie kann ich dann Async Funktionen wirklich parallel laufen 
lassen, also in verschiedenen Threads, um wirklich auf mehrere Kerne zu 
skalieren, oder gibt es dafür etwas ganz anderes, oder ist meine 
Threadingdenke zu antiquiert/eingefahren nach den vielen Jahren?

von MaWin (Gast)


Lesenswert?

Programmierer schrieb:
> Async/Await sind eben genau keine Threads

Wie bereits gesagt:
In Rust können async-Tasks auch auf Threads laufen.

https://docs.rs/tokio/1.20.0/tokio/runtime/index.html#multi-thread-scheduler

Das Rust-Typsystem mit seiner inhärenten Thread-safety macht es möglich.

von Programmierer (Gast)


Lesenswert?

MaWin schrieb:
> Wie bereits gesagt:
> In Rust können async-Tasks auch auf Threads laufen.

Exakt. Das ist eine Besonderheit bei Rust, die durch das verwendete 
Memory-Modell erst möglich wird.


cppbert3 schrieb:
> Ok aber wie kann ich dann Async Funktionen wirklich parallel laufen
> lassen, also in verschiedenen Threads,

Async/Await als Konzept hat erstmal nichts mit Threads zu tun und laufen 
(eigentlich) niemals "parallel". Das ist eine Rust-Besonderheit. In 
anderen Sprachen ist das nicht möglich.

> um wirklich auf mehrere Kerne zu skalieren

Async/Await ist für den IO-Bound-Fall gedacht, dass also Dein Programm 
durch die IO-Bandbreite begrenzt wird, und nicht durch die 
CPU-Bandbreite.
Das ist in einem einfachen Programm der Fall, während es große Dateien 
verarbeitet und während dessen z.B. einen Spinner auf der Konsole 
anzeigt, oder ein paar Dateien aus dem Internet heruntergeladen werden.
Oder bei einem Server, der 20.000 Clients gleichzeitig irgendwelche 
HTML-Seiten ausliefert.

Threads wiederum sind für CPU-Bound-Fälle ideal. D.h. das Programm muss 
etwas berechnen, z.B. Primzahlen oder eine numerische Lösung finden z.B. 
eine elektronische Schaltung simulieren. Da ist die CPU der Bremsklotz, 
und nicht IO.

Async/Await ist sehr leichtgewichtig, da eben keine mehrfachen Stacks 
vorhanden sind oder Daten zwischen CPU-Kernen hin- und her- kopiert 
werden müssen inkl. Cache-Pollution etc.

Natürlich sind die meisten Programme selten rein IO-Bounded. So müssen 
die Daten die ausgegeben oder empfangen werden, irgendwie generiert oder 
verarbeitet werden, also CPU-Ressourcen sind notwendig.

Und hier kommt eben das Memory-Modell von Rust zur Hilfe, das es eben 
ermöglicht, die CPU-Anteile doch auf Threads und somit CPU-Cores zu 
verteilen. Aber wie gesagt, das ist eine Extra-Spezialität von der Du 
aus Sicht des Programmiermodels nichts mitbekommst.

> oder ist meine
> Threadingdenke zu antiquiert/eingefahren nach den vielen Jahren?

Die meiste "Parallelisierung" in den meisten Programmen ist nicht 
CPU-bounded, sonder IO-bounded. Klassiker: Download von Dateien aus dem 
Internet. Dazu benötigt es keine Threads, das ist reine 
Ressourcenverschwendung und birgt in fast allen Programmiersprachen auch 
noch große Gefahren für Programmierfehler.

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


Lesenswert?

rbx schrieb:
>> auf einem Controller wird man wohl oder
>> übel vorab Stacks definieren müssen.
>
> Kommt drauf an, auf dem Raspi könnte man auch OS-Ressourcen benutzen.

Ich schrieb: Controller.

Ein Rapsberry Pi ist kein Microcontroller mehr. Wenn ich da ein 
(komplettes, nicht irgendwie herunter getunetes) Linux oder BSD drauf 
laufen lassen kann (selbst Windows hatte sich ja dran versucht), dann 
ist das Ding in der Art und Weise, wie es programmiert wird, letztlich 
ein PC. Dass er noch ein paar GPIOs rausgeführt hat, ändert nichts 
grundsätzlich dran.

Programmierer schrieb:
> Threads wiederum sind für CPU-Bound-Fälle ideal.

Das würde ich überhaupt nicht so sehen. Das ist Parallelisierung, am 
besten über mehrere CPUs. Threads waren und sind ganz viel benutzt 
worden, um das Handling der IOs zu vereinfachen: ich habe einen Thread, 
der auf der seriellen Schnittstelle wartet, bis was reinkommt, einen, 
der die GUI bedient und wartet, bis dort irgendein Event angekleckert 
kommt, etc. pp.

OK, stimmt schon, dafür muss man eigentlich nicht unbedingt einen 
kompletten Thread aufmachen mit eigenem Stack, weil während der 
IO-Wartezeit ja sowieso nichts auf diesem passieren würde. Lässt sich ja 
auch ganz klassisch komplett ohne Threads handhaben (siehe select()), 
ist dann eben nur im Code unhandlicher.

von Vincent H. (vinci)


Lesenswert?

DPA schrieb:
> C - Kohlenstoff
>
> Unglaublich nützlich...


Lustig, Google kam wohl mit einer ähnlichen Analogie auf:

Carbon Language - An experimental successor to C++
https://github.com/carbon-language/carbon-lang

von cppbert (Gast)


Lesenswert?

Jörg W. schrieb:
> Programmierer schrieb:
>> Threads wiederum sind für CPU-Bound-Fälle ideal.
>
> Das würde ich überhaupt nicht so sehen. Das ist Parallelisierung, am
> besten über mehrere CPUs. Threads waren und sind ganz viel benutzt
> worden, um das Handling der IOs zu vereinfachen: ich habe einen Thread,
> der auf der seriellen Schnittstelle wartet, bis was reinkommt, einen,
> der die GUI bedient und wartet, bis dort irgendein Event angekleckert
> kommt, etc. pp.
>
> OK, stimmt schon, dafür muss man eigentlich nicht unbedingt einen
> kompletten Thread aufmachen mit eigenem Stack, weil während der
> IO-Wartezeit ja sowieso nichts auf diesem passieren würde. Lässt sich ja
> auch ganz klassisch komplett ohne Threads handhaben (siehe select()),
> ist dann eben nur im Code unhandlicher.

die meisten Betriebssysteme können ja recht viele Operationen auch 
asynchron, aber die Schicht die darüber liegt ist dann oft leider wieder 
synchron und dann braucht man extra einen Thread damit man das 
unblockierend laufen lassen kann - also sind Threads manchmal wirklich 
nur eine selbstgemachte (weil asynchron-Features ignoriend) oder 
Framework-arbeitet-leider-nur-synchron Notwendigkeit, wie viel Potential 
da schon verblasen wird

von Bernd W. (berndwiebus) Benutzerseite


Lesenswert?

Hallo Programmierer.

Programmierer schrieb:

> Komplexität schreckt die meisten Menschen ab. Darum wird Komplexität
> verleugnet. Endstadium: Verschwörungstheorie.

Das ist richtig!

Allerdings sollte man auch erwähnen, das Komplexität darum abschreckt, 
weil Komplexität die meisten Menschen überfordert.

Darum sollte man versuchen Komplexität, wenn sie nicht unbedingt 
erforderlich ist, zu meiden.

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.l02.de

von cppbert (Gast)


Lesenswert?

Bernd W. schrieb:
> Darum sollte man versuchen Komplexität, wenn sie nicht unbedingt
> erforderlich ist, zu meiden.

Komplexität ist ein Biest:
1
Person + Wissensstand + Erfahrung + aktueller Fokus => Komplexitätsgefühl

da die vier Faktoren so unglaublich Variant sind ist Komplexität eher so 
als Random-Value zu sehen - die sich in jedem Kopf, zu jeder Zeit völlig 
anders darstellt und deswegen auch Programmiersprache-Diskussionen so 
ungelaublich schwer sind

von cppbert (Gast)


Lesenswert?

Was für den einen komplex ist kann trotzdem die besser Lösung sein weil 
er einfach den Themenkomplex nicht überblickt - immer die grosse Gefahr

viele stapeln gerne klein - nicht weil das so richtig ist sondern weil 
sie gar nicht anders können - rein kognitiv - das macht technische 
Kommunikation oft sehr schwierig - wenn man nicht nurn bissle SQL und 
GUIs macht (da ist es oft einfach nicht so relevant)

von rbx (Gast)


Lesenswert?

cppbert schrieb:
> und welche Gemeinsamkeit haben Zeiger und goto?

Nicht unbedingt für JavaScript-Gurus verständlich.

von DPA (Gast)


Lesenswert?

Das einzige, was mich an async in den meisten Sprachen stört, ist, dass 
man async Funktionen explizit als solche markieren muss. Das erschwert 
es dann, sync und async effektiv zu kombinieren. Dann muss man sehen, 
macht man alle Funktionen async, die eine Funktion mit io beinhalten 
könnte, dass man mit einem await später auf sie warten kann, oder wartet 
man halt synchron auf das io, oder splittet man es anderweitig weiter 
auf und speichert die Futures in irgend einer Queue oder so.

Wenn man einfach sagen könnte, mach das zeug jetzt Asynchron, ohne alle 
Funktionen dazwischen async zu machen, das wäre cool...

Ich glaube zig macht das anders / so ähnlich, muss ich mir nochmal 
ansehen. Wobei, vermutlich ist deren Method auch nicht wirklich besser / 
hat auch Problemchen.

von DPA (Gast)


Lesenswert?

cppbert schrieb:
> viele stapeln gerne klein - nicht weil das so richtig ist sondern weil
> sie gar nicht anders können - rein kognitiv

Nein, die haben einfach mehr Erfahrung. Wenn ein Programm, in seiner 
Gesamtheit, nicht einfach verständlich ist, ist es nicht gut wartbar. 
Viele vergessen ihre geniale Lösung auch selbst gerne. Nö, gute 
Programme sind nie Komplex, gute Programme sind simpel. Und man muss 
kein Genie sein, um komplexen Mist zu verzapfen. Wirkliche Erfahrung, 
wahres Können, braucht man, um auf die einfachen Lösungen zu kommen. 
Meistens sind das auch die besten.

von cppbert (Gast)


Lesenswert?

rbx schrieb:
> cppbert schrieb:
>> und welche Gemeinsamkeit haben Zeiger und goto?
>
> Nicht unbedingt für JavaScript-Gurus verständlich.

für niemanden verständlich was du damit sagen wolltest
den Rest der Fragen einfach mal ignoriert?

von cppbert (Gast)


Lesenswert?

DPA schrieb:
> cppbert schrieb:
>> viele stapeln gerne klein - nicht weil das so richtig ist sondern weil
>> sie gar nicht anders können - rein kognitiv
>
> Nein, die haben einfach mehr Erfahrung. Wenn ein Programm, in seiner
> Gesamtheit, nicht einfach verständlich ist, ist es nicht gut wartbar.

selbst gute wartbarkeite ist Ansichtssache - es gibt sogar Leute die 
viele Funktionen vermeiden weil sie die Zerlegung von Algorithmen als zu 
kompliziert empfinden

> Viele vergessen ihre geniale Lösung auch selbst gerne. Nö, gute
> Programme sind nie Komplex, gute Programme sind simpel. Und man muss
> kein Genie sein, um komplexen Mist zu verzapfen. Wirkliche Erfahrung,
> wahres Können, braucht man, um auf die einfachen Lösungen zu kommen.
> Meistens sind das auch die besten.

100% ACK - aber ob man das wirklich gut kann merkt man erst wenn man mal 
mehrfach verantworlich war ein paar 100k Zeilen Code zu erschaffen und 
wartbar zu halten - zusammen mit x Entwicklern - alles andere bleibt 
irgendwie einfach, lokal, der eigene Mist

oder wir reden eben von lokaler Algorithmik - die ist ist wenigstens 
ungefährlich weil von ihrer Art her einfach gut zu entkoppeln, auch wenn 
der 1., 2. und dritte Versuch Müll war kann man das gut und schnell 
bereinigen, architektonische Fehler, Designschwächen die 
Skalierungsprobleme verursachen sind viel schlimmer zu beheben, aber das 
machen eh nur die wenigsten

von cppbert (Gast)


Lesenswert?

und dann noch die vielen Entwickler die es nicht mal gebacken bekommen 
wengstens die rudimentärste Entkopplung ihres Code zu schaffen um 
Unit-testbar zu sein(oder zu bleiben) und wenn sie von Design sprechen 
vornehmlich die Anordnung von if und else meinen :)

von MaWin (Gast)


Lesenswert?

DPA schrieb:
> Wenn man einfach sagen könnte, mach das zeug jetzt Asynchron, ohne alle
> Funktionen dazwischen async zu machen, das wäre cool...

Ich wüsste nicht, wie das gehen soll.
Wenn Unterfunktionen asynchron sind, dann werden die aufrufenden 
Funktionen natürlich auch automatisch asynchron. Und deshalb muss man 
sie dann als solche markieren. Denn sonst wäre bei deren Aufruf nicht 
klar, ob man sie synchron oder asynchron aufrufen muss.

von Ron T. (rontem)


Lesenswert?


von Programmierer (Gast)


Lesenswert?

MaWin schrieb:
> Ich wüsste nicht, wie das gehen soll.
> Wenn Unterfunktionen asynchron sind, dann werden die aufrufenden
> Funktionen natürlich auch automatisch asynchron.

Allgemein gesprochen, unabhängig von realen Programmiersprachen, stimmt 
das so nicht ganz.

Die Async-Markierung bedeutet nur, dass die Funktion das Ergebnis nicht 
direkt zurück liefert, sondern (im Idealfall) sofort zurückkehrt und ein 
Future-Objekt, Promise, Task o.ä. zurück liefert.

Die Programmiersprache bietet mit einer Async-Markierung natürlich noch 
zusätzlich irgendwelche Unterstützung, so dass man bestimmte Dinge nicht 
von Hand machen muss, und schränkt evtl. bestimmte Verwendung der 
Asnyc-Funktion ein.

Aber rein prinzipiell könnte synchroner Code ein Future-Objekt pollen, 
und das Future-Objekt würde dann irgendwann sagen, dass das Ergebnis 
vorhanden ist. Dann könnte der synchrone Code das Ergebnis vom 
Future-Objekt abholen.

Allerdings ist mir auf die Schnelle keine Programmiersprache bekannt, wo 
das so möglich ist. Das Problem dabei wäre nämlich, dass Async-Code 
natürlich normale Funktionen aufrufen könnte, der intern ein Polling von 
Async-Code macht, der wiederum normalen Code aufruft, der intern ein 
Polling von Async-Code macht, der wiederum....

Es ist klar, auf was das heraus laufen würde, oder?

von MaWin (Gast)


Lesenswert?

Programmierer schrieb:
> Aber rein prinzipiell könnte synchroner Code ein Future-Objekt pollen,
> und das Future-Objekt würde dann irgendwann sagen, dass das Ergebnis
> vorhanden ist. Dann könnte der synchrone Code das Ergebnis vom
> Future-Objekt abholen.
>
> Allerdings ist mir auf die Schnelle keine Programmiersprache bekannt, wo
> das so möglich ist.

Das ist in Rust natürlich möglich.
Man kann zum Beispiel mit cassette (https://crates.io/crates/cassette), 
einer minimalen async-Runtime, ohne Weiteres ein Future pollen. Das geht 
natürlich auch mit vielen anderen Runtimes, oder man kann es auch selbst 
implementieren.

Aber so hatte ich die Anforderung von DPA nicht verstanden.
Ich hatte es eher so verstanden, dass man normale Funktionen und async 
wild mischt und die Sprache das dann irgendwie auf magische Weise 
"richtig" machen soll. Das würde natürlich dazu führen, dass die Sprache 
selbstständig im Hintergrund async-Eventloops aufziehen muss. Niemand 
würde mehr durchblicken. Ich hätte vielleicht schreiben sollen: Ich 
wüsste nicht, wie das sinnvoll gehen soll.

> Es ist klar, auf was das heraus laufen würde, oder?

Eben. :)
Ich wüsste nicht, wie das sinnvoll automatisch von der Sprache aus gehen 
soll.
Zu Fuß implementieren kann man diesen Fall aber.

von Daniel A. (daniel-a)


Lesenswert?

MaWin schrieb:
> Programmierer schrieb:
>> Aber rein prinzipiell könnte synchroner Code ein Future-Objekt pollen,
>> und das Future-Objekt würde dann irgendwann sagen, dass das Ergebnis
>> vorhanden ist. Dann könnte der synchrone Code das Ergebnis vom
>> Future-Objekt abholen.

So hatte ich das eigentlich nicht im sinn. Ich dachte das eher so, dass 
async & await quasi der default sind, und man explizit angeben muss, 
wenn man das furture Objekt will. Das ist stärker als immer sofort das 
Future-Objekt zu pollen, den dann kann man später immernoch mehrere 
Funktionen parallelisieren.
Irgendwo müsste man immernoch synchron warten, was aber kein problem 
sein sollte, man kann ja einfach in einer tread lokalen Variable oder so 
speichern, ob das gerade das "oberste" await ist, oder nicht. Das alles 
liese sich sicher auch abi-massig transparent gestalten, braucht 
vermutlich nur ein wrapper symbol und ein paar andere Tricksereien, nur 
kenne ich leider auch noch keinen Weg, das ohne coroutinen oder heap 
allocations, also Zusatzkosten, zu machen, denn dann müsste man das ja 
so lösen, dass man die Limitationen von rekursiven aufrufen usw. nicht 
hat.

Also ich weiss nicht, ob es einen Weg gibt, das beste aller Welten zu 
kriegen, aber wenn es irgendwie ginge, das so zu machen, das währe für 
mich quasi der Heilige Gral.

Ich weiss, dass zig die Funktionen selbst nicht als async definiert, 
sondern man beim Aufruf angibt, ob man eine future will. Aber ich weiss 
nicht, ob die das so wie von Programmierer angegeben machen, oder so wie 
ich das gerne hätte. Das muss ich mir mal genauer ansehen.

von rbx (Gast)


Lesenswert?

MaWin schrieb:
> Zu Fuß implementieren kann man diesen Fall aber.

Überhaupt kommt man nicht umhin, selber Gehirnschmalz einzusetzen, und 
das nicht zu knapp. Das bringt die Parallel-Programmierung so mit sich.
Hier und da kommt man in Bereiche, wo man meint, nö, ich habe echt 
keinen Bock mehr mich länger geistig so anzustrengen - man muss halt 
auch lange nachdenken, und hat dann diesbezüglich Ausdauerprobleme.
Da freut man sich dann auch über gewisse, schon ganz gut ausgetretende 
Pfade.

Manchmal ist es aber auch so, da kann man nach Workflows Ausschau halten 
oder nach einfachen Rezepten. Ich finde das Kochbuch von Rust gar nicht 
so schlecht. Ich erinnere mich an die JavaScript Tutorials von Netscape. 
Die waren auch echt nicht schlecht.
Ähnlich gut erscheint Rust

Eine wenig fühle ich mich bei der Diskussion auch an die Haskell Monaden 
erinnert. Man könnte ja meinen, man muss erst ein Mathestudium 
abschließen, um Monaden sinnvoll verarbeiten zu können.
Auswendiglernen der wichtigsten Handgriffe geht aber auch. Man muss halt 
nicht überall mitreden können.

Auf Stackoverflow gab es eine nette Linkempfehlung zu Rust Async:

https://ryhl.io/blog/async-what-is-blocking/

Für Komplexität gibt es zumindest noch eine bewährte Alternative zum 
Liegenlassen: schrittweise herangehen.

Beitrag #7136148 wurde von einem Moderator gelöscht.
Beitrag #7136150 wurde von einem Moderator gelöscht.
Beitrag #7136151 wurde vom Autor gelöscht.
Beitrag #7136155 wurde von einem Moderator gelöscht.
Beitrag #7136157 wurde von einem Moderator gelöscht.
Beitrag #7136160 wurde von einem Moderator gelöscht.
Beitrag #7136164 wurde von einem Moderator gelöscht.
Beitrag #7136173 wurde von einem Moderator gelöscht.
Beitrag #7136176 wurde von einem Moderator gelöscht.
Beitrag #7136180 wurde von einem Moderator gelöscht.
von XY M. (xym)


Lesenswert?

Ach herrje... was nicht passt wird passend gemacht?
Kritik unerwünscht!

von cppbert3 (Gast)


Lesenswert?

XY M. schrieb:
> Ach herrje... was nicht passt wird passend gemacht?
> Kritik unerwünscht!

Naja, 9 gelöschte Post sind auch hier jetzt nicht Standard, wohl ein 
wenig in der Wortwahl vergriffen derjenige

von MaWin (Gast)


Lesenswert?

Version 1.63.0 ist raus:

https://blog.rust-lang.org/2022/08/11/Rust-1.63.0.html

- std::thread::scope: Sehr nützlich. Das vereinfacht die Threading-API 
noch einmal mehr, weil das join-handling automatisiert wird. Und es 
ermöglicht dem Compiler übergebene Referenzen statisch zu prüfen. Es gab 
schon crates, die das ermöglicht haben, aber nun ist es in der std-lib 
drin.

- const Mutex init: Auch eine gute Vereinfachung der Mutex-API. Macht 
das externe crate lazy_static in vielen Fällen unnötig.

Beide Änderungen führen zum Wegfall von diversen Runtime-Checks und 
erhöhen damit (minimal) die Performance.

von Drüsensekretfermentat (Gast)


Angehängte Dateien:

Lesenswert?

Rust gibt's auch zum Frühstück!

von ein bisschen Programmierer (Gast)


Lesenswert?

Programmierer schrieb:
> Die allermeisten Menschen möchte einfache, simple Erklärungen wie die
> Welt funktioniert. Dann haben sie das Gefühl sie verstünden die Welt und
> könnten sich ein Urteil bilden, eine Meinung haben und mitdiskutieren.

Das hieße dann im Umkehrschluss, wer die Welt nicht in all ihrer 
Komplexität versteht sollte keine Meinung über sie haben und sich das 
mitdiskutieren ersparen. Dann sollte die Menschheit aber kollektiv das 
Schweigen lernen, denn KEINER aber absolut KEINER ist allein im Stande 
die Welt gänzlich zu verstehen, ob beim Klimawandel, bei der Verteilung 
von Reichtum und Armut oder den großen Fragen der Zukunft, wie die 
Menschheit künftig ihr Dasein gestalten soll, ohne dass es für ganze 
Landstriche ins Desaster führt (bzgl. Lebensqualität, Ressourcen, 
Bildungschancen etc.).

> Komplexität schreckt die meisten Menschen ab.

Die meisten Menschen brauchen die Komplexität vieler Hintergründe auch 
gar nicht en Detail zu verstehen, um damit umgehen zu können. Du musst 
nicht verstehen wie ein Otto-Motor genau funktioniert, um Auto fahren zu 
können. Du musst (um beim Thema anzuknüpfen) auch nicht genau verstehen 
wie ein Compiler funktioniert, um ein lauffähiges Programm zu schreiben. 
Es genügt zu wissen, wie man einen übersetzbaren Quelltext schreibt und 
wie man daraus ein startbares Programm übersetzt. Dazu gibt es Tools.

> Darum wird Komplexität
> verleugnet. Endstadium: Verschwörungstheorie.

Das ist eine andere Schiene. Verschwörungstheorien bilden sich dort wo 
Menschen das Vertrauen in ihre (hoffentlich) demokratischen 
Institutionen verloren haben. Ich würde nicht pauschal unterstellen, 
dass dort immer alle unterkomplex denken (für einige mag das zutreffen, 
aber nicht für alle). Bei vielen ist es einfach die Angst vor zu starker 
Veränderung, die die Leute umtreibt, gepaart mit dem Unvermögen der uns 
regierenden die "Komplexität" auf verstehbare, vermittelbare Sätze 
herunterzubrechen, anstatt zu schweigen oder den Leuten das Gefühl zu 
vermitteln selber die Dinge nicht richtig zu verstehen und daraus 
fragwürdige Handlungen abzuleiten.

Aber wie gesagt, das ist eine andere Schiene (politisch) und gehört 
nicht in diesen Thread.

Ich hab mal gerade in ein Tutorial von Rust reingeschaut. Bis hierhin 
war's zumindest unterhaltsam ;).

https://www.youtube.com/watch?v=xYgfW8cIbMA

von Ron T. (rontem)


Lesenswert?

Die Welt ist zweifelsohne komplex.
Daran lässt sich nichts ändern.
Die Komplexität der Bedienung von Technik oder Programmierwerkzeugen 
/sprachen liegt aber in menschlichen Händen. Daran lässt sich durchaus 
was ändern.

von MaWin (Gast)


Lesenswert?

Next steps for Rust in the kernel
https://lwn.net/Articles/908347/

Der Artikel ist leider noch sobscriber-only. Solange zitiere ich einmal 
hier den Kern:

> At the 2022 Linux Kernel Maintainers Summit, Miguel Ojeda updated the group on 
the status of the project with the goal of reaching a conclusion on when this 
merge might happen. The answer that came back was clear enough: Rust in the kernel 
will be happening soon indeed.
> There was little suspense on that front; Linus Torvalds spoke up at the 
beginning of the session to say that he plans to accept the Rust patches for the 
6.1 kernel (likely to be released in mid-December) unless he hears strong 
objections.

>  There is currently an ongoing effort to write a specification for Rust for 
safety-critical systems that will lead to a standard-like document. At the moment, 
though, Ojeda said, the developers of the GCC-based gccrs Rust compiler are 
finding the current documentation to be vague at times. Often, behavior is 
specified as "whatever the rustc compiler does". That is "not good", he said, but 
there is a path forward.

>  It has often been said that the merging of Rust into the kernel tree will be 
done on an experimental basis; if it doesn't work out, it can be removed again.

> Torvalds added that Rust isn't that terrible in the end; "it's not Perl".

von cppbert (Gast)


Lesenswert?

Ich hoffe die bekommen das "Pinning" Problem gut gelöst - oder ist das 
schon (sauber) vom Tisch?

https://news.ycombinator.com/item?id=32864598
https://lwn.net/SubscriberLink/907876/ac0afc756df0ec71/

Ich finde es sehr gut das Rust jetzt vielleicht (zu)schnell in den 
Kernel kommt weil dann ein grosser Zwang besteht bestehende 
Probleme/Schwächen im Grossen Kreis zu klären

mehr Szenarien = mehr Möglichkeit an Schwächen zu arbeiten

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> Ich hoffe die bekommen das "Pinning" Problem gut gelöst - oder ist
> das
> schon (sauber) vom Tisch?

Gelöst ist das nicht.
Aber es bedeutet lediglich, dass es derzeit ein paar mehr unsafe-Blöcke 
an den Schnittstellen zur C-Welt gibt. Oder an den wenigen Stellen, wo 
ein memcpy nicht wegoptimiert werden kann und dieses memcpy zu viele 
Schmerzen bereitet.

Das Problem ist auch nicht, dass das im Einzelfall nicht immer lösbar 
wäre. Aber es gibt derzeit nicht eine wirklich saubere Universallösung 
für alle Fälle.
(Wobei ich diese Procmakro-Lösung eigentlich gar nicht so schlecht 
finde. Da gibt es im Rust-Universum deutlich hässlichere Procmakros.)

Beitrag #7200277 wurde von einem Moderator gelöscht.
von Kaj (Gast)


Lesenswert?

Volvo bringt Rust in die Auto-Software

Das Rust-Team bei Volvo will die Nutzung der Sprache in der 
Auto-Software deutlich ausweiten. Bis hin zu sicherheitskritischen 
Anwendungen.

https://www.golem.de/news/programmierung-volvo-bringt-rust-in-die-auto-software-2209-168520.html

von cppbert (Gast)


Lesenswert?

Auch wenn die Diskussionen mit Linus wie üblich etwas harsch wirken 
finde ich es super das sich die Rust Leute (der kleine Teil der 
Community der sich damit bisher beschäftigt) jetzt den Anforderungen 
eines Mainstream Kernels aussetzen

https://lkml.org/lkml/2022/9/19/1250

Egal wie die Integration verläuft sind das alles wichtige Impulse für 
die Sprachentwicklung

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Muss man dann eigentlich Rust zum Kompilieren des Kernels haben, oder 
kann man all das Rust Zeugs auch in der config abwählen?

von cppbert (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Muss man dann eigentlich Rust zum Kompilieren des Kernels haben,
> oder
> kann man all das Rust Zeugs auch in der config abwählen?

ich denke nicht das die Kernel-Entwickler Rust gleich für alle 
Entwickler Zwangsausrollen werden, es wird bestimt modulorientiert sein 
- sonst das wäre ja totales Chaos bei >3000 aktiven Entwicklern

von MaWin (Gast)


Lesenswert?

Nun ist es soweit. Die Rusthasser müssen sich nach einem alternativen 
Betriebssystem umsehen.

https://lwn.net/Articles/910762/

There have been a lot of significant changes merged into the mainline 
for the 6.1 release, but one of the changes that has received the most 
attention will also have the least short-term effect for users of the 
kernel: the introduction of support for the Rust programming language. 
No system with a production 6.1 kernel will be running any Rust code, 
but this change does give kernel developers a chance to play with the 
language in the kernel context and get a sense for how Rust development 
feels. Perhaps the most likely conclusion for most developers, though, 
will be that there isn't yet enough Rust in the kernel to do much of 
anything interesting.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Am Anfang stehen und schon Feiern? Schauen wir mal, was aus Linux in ein 
paar Jahren geworden ist. Ob Rust dann immer noch drin ist, ob Linux 
noch lebt, etc. Da kann viel passieren.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> ob Linux noch lebt, etc. Da kann viel passieren.

Dein Getrolle war auch schon einmal besser. Gib dir bitte wieder mehr 
Mühe!

von Dergute W. (derguteweka)


Lesenswert?

Moin,

<heisemode>Juhuu, das ist das Ende von Linux</heisemode>

scnr,
WK

von S. R. (svenska)


Lesenswert?

Ich würde ja eher sagen: Schauen wir mal, wieviel Rust in ein paar 
Jahren real im Kernel drin ist. Wenn sich das auf ein paar Treiber 
weniger Firmen beschränkt, dann war's viel Hype um nichts.

von cppbert (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Am Anfang stehen und schon Feiern? Schauen wir mal, was aus Linux
> in ein
> paar Jahren geworden ist. Ob Rust dann immer noch drin ist, ob Linux
> noch lebt, etc. Da kann viel passieren.

genau das ist doch das Ziel und auch die Strategie - einfach 
ausprobieren, wenn es nix ist kommt Rust ganz schnell wieder raus, was 
aber trotzdem kein scheitern der ganzen Sprache bedeutet, es hat ja auch 
keine anderen Sprache bisher im Kernel einzug gehalten

und sollte Rust dem Kernel erhalten bleiben und die Modul-Anzahl wachsen 
wird es immer noch genau so viele Leute im Internet geben die das alles 
nicht gut finden, selbst wenn alle Top-Kernel Entwickler sagen das ist 
die geilste Scheisse ever, hat das auch keine Relevanz - also schauen 
wir einfach ob es was wird und Rust an der Kernel-Herausforderung wächst 
oder scheitert

von cppbert (Gast)


Lesenswert?

Hier der Teil der Key-Note mit Linus wo er über die Rust Integration 
spricht:

https://www.youtube.com/watch?v=sLimmpZWRNI&t=1144s

nicht ganz super ernsthaft aber pragmatisch - es wird auch
kurz über die clang/LLVM abhängigkeit gesprochen, 1min nach Start

von cppbert (Gast)


Lesenswert?

und über die Ängste die mit der Einführung einer neuen Sprache 
einhergehen und auch das wenn es schief geht das es eben schamvoll 
entfernt werden wird...

aber ich hab wirklich selten Linus so euphorisch(für seine Verhältnisse) 
über eine Programmiersprache sprechen hören - er freut sich darauf die 
Rust-Syntax zu lernen

Es wird die härteste und beste Herausforderung für Rust - wir werden 
sehen wie es sich schlägt und die harsch Linus damit umgehen wird

von rbx (Gast)


Lesenswert?

S. R. schrieb:
> Ich würde ja eher sagen: Schauen wir mal, wieviel Rust in ein paar
> Jahren real im Kernel drin ist. Wenn sich das auf ein paar Treiber
> weniger Firmen beschränkt, dann war's viel Hype um nichts.

Man könnte schon fast eine Vorhersage versuchen.

Basierend auf:

Berichte über Parallelitätsexpertise in den 50er und 60er Jahren:(sehr 
interessant)
"Funktionale Sprachen sind auch ein guter Ansatz" (aber nicht der 
bestimmende)

Haskell Hyperei (was war da eigentlich los (so zwischen 2008 und 2012)?)

C++ PDF zur Frage: C++ vs Haskell.

Die Antwort war:

wegen dem schwierigen Haskell Code lieber in C++ was machen.
Aber der Haskell Code in dem Pdf war eher plakativ ausgesucht.
Der Haskell-Code war nicht unbedingt schwierig, aber der sah stark 
danach aus, als wäre der das. Also eher kognitive Dissonanz 
(Ent-)Berieselung dabei.

Dann noch:
Frederik Vester (Lerntypen in "Denken, Lernen, Vergessen) und Israel 
Rosenfield ("Das Fremde, das Vertraute und das Vergessene")
Der Text von dem Rosenfield ist extrem erhellend - nicht unbedingt hier 
zum Thema, aber zu Bewusstseinsfragen und Integration an sich.
Dann noch ein wenig Chaosforschung.

Aus diesen zusammengefasst:

 Immer vom Vertrauten zum Unvertrauten. Nicht umgekehrt. Verhältnis 
empfindlich. Nicht zuviel neues aufeinmal.
BWL-Grundkurs geht auch noch: welche Alternativkosten?

Die Programmierung mit "funktionalen Sprachen" ist sehr abstrakt, und 
deswegen braucht man länger als für C und für C wurden früher 5-10 Jahre 
angesetzt. Das ist heute bestimmt anders, aber C hat Abstaktionen, die 
muss man auch erstmal verarbeiten - das dauert erstmal - und funktionale 
Sprachen dauern da noch viel länger - ganz abgesehen von dem (oft 
fehlenden) Drumherum in Richtung der Hardwareschnittstelle.

Wir haben dann:
- funktionale Programmiersprache, nicht sonderlich gut bekannt.
- recht anspruchsvoller, hoher Abstraktionsgrad (man braucht lange), 
gute Matheausbildung sicher auch nicht verkehrt.

- (professionelle Bibliotheken?)
- Parallelprogrammierung mit vielen Kernen: Schwierig.
- Plotten geht mit (Hilfe von) Octave viel besser.
- Pycuda-Math

Nun ist aber Parallelprogrammierhilfe schon dringender nötig als früher. 
Und C++ ist auch ein ganz schön dicker Brocken geworden.
Der gcc auch, und der raubt mir mit seinen Fehlermeldungen den letzten 
Nerv.

Gute Zeiten für Python?

Ich weiß gar nicht mehr, wann das war - als bei Cygwin ein Python-Packet 
mit dabei war.
Es war aber ein "Issue" ob mit dabei oder nicht. Ist noch nicht so lange 
her, vielleicht 8-10 Jahre.

Der Python-Einstieg ist mittlerweile ganz einfach in Linux, weil schon 
vorinstalliert - bzw. so ein wenig auf Basic-Spuren herumläuft.

Über den Status "eine gute Idee" (wie in den 60ern) ist Rust sicher 
hinausgekommen. Aber wie weit?

Linus hypt auch nur in dem Video oben.
Allerdings ist der auch nicht irgendwer ;)

von MaWin (Gast)


Lesenswert?

rbx schrieb:
> - Parallelprogrammierung mit vielen Kernen: Schwierig.

Falsch.
In Rust sehr einfach.

von cppbert (Gast)


Lesenswert?

Superpower von rbx? Haskell Bezüge in fast jedem Post :)

von rbx (Gast)


Lesenswert?

MaWin schrieb:
> rbx schrieb:
>> - Parallelprogrammierung mit vielen Kernen: Schwierig.
>
> Falsch.
> In Rust sehr einfach.

Danke für die "Optimierung"
Ich hatte noch im Hinterkopf: Wenn man das alles in Assembler machen 
müsste bei den Cells (Playstation usw) geht das ja noch - aber bei 100 
Threads? Da kann man dann eben schon für solche Entwicklungen wie Rust 
dankbar sein.

von cppbert (Gast)


Lesenswert?

rbx schrieb:
> Danke für die "Optimierung"
> Ich hatte noch im Hinterkopf: Wenn man das alles in Assembler machen
> müsste bei den Cells (Playstation usw) geht das ja noch - aber bei 100
> Threads? Da kann man dann eben schon für solche Entwicklungen wie Rust
> dankbar sein.

sorry rbx - aber, wie so oft habe ich keine Ahnung was du vermitteln 
willst

was hat denn der 2006 Playstation3 Cell Chip hier für einen relevanz?

In C/C++ mit >100 Threads rumspielen war schon vor >15 Jahren, auch 
unter Windows völlig "normal" und Rust hat nur die Sicherheit deren 
Nutzung erhöht
ansonsten ist Multithreading definitiv schon lange nichts besonderes 
mehr

von cppbert (Gast)


Lesenswert?

cppbert schrieb:
> was hat denn der 2006 Playstation3 Cell Chip hier für einen relevanz?

der wurde nicht per se mit Assembler programmiert sondern eher in C++ 
(mit Extensions)

https://www.codeproject.com/Articles/23733/Parallel-programming-on-PlayStation-3-Cell-archite

von cppbert (Gast)


Lesenswert?

cppbert schrieb:
> In C/C++ mit >100 Threads rumspielen war schon vor >15 Jahren, auch
> unter Windows völlig "normal" und Rust hat nur die Sicherheit deren
> Nutzung erhöht

ich hab 2001 an einem System mit einer schlechten Architektur gearbeitet 
das
bei einem Volllauf Geräte in einer Chemie-Automation mit C++ gesteuert 
hat, Window 2000, Visual C++ 6, >400 Threads - weil jedes Gerät seinen 
eigenen Thread-Message-Queue hatte, war ineffizient aber damals auch 
kein Hexenwerk

oder meinst du Auto-Vektorisierung/Parallelisierung und solche Sachen? 
dann musst du das aber auch deutlich sagen - alles andere ist sonst nur 
Buzzword-Geplapper

von rbx (Gast)


Lesenswert?

cppbert schrieb:
> war ineffizient aber damals auch
> kein Hexenwerk

In dem c't - Jubiläumsheft 24/2008 gab es den Artikel "Playstation 
unportable".

https://www.heise.de/select/ct/archiv/2008/24/seite-276

Das Ergebnis der Programmierübungen auf dem Schrankteil war, dass 
Assemblerprogrammierung (auf dieser Kiste) deutlich effizienter ist - 
und möglichst vorzuziehen.

https://de.wikipedia.org/wiki/IBM_Roadrunner
(Ob Assemblerprogrammierung hier eine Rolle spielt, weiß ich nicht - 
aber es hilft vielleicht, das Argument oben etwas einfacher 
einzusortieren.)

von ein lupenreiner Demokrat (Gast)


Lesenswert?

Wird Rust besser, wenn die Sprache im Linuxkernel benutzt wird? Mehr 
akzeptiert und mehr verbreitet - ja, aber mit Sicherheit nicht besser.

Da muss man nur anschauen, was Linus von C erwartet hat und welche 
"features" er da haben wollte. (z.B. memcpy ganz durch memmove ersetzen 
und weiterer Blödsinn)

von Rolf M. (rmagnus)


Lesenswert?

ein lupenreiner Demokrat schrieb:
> Wird Rust besser, wenn die Sprache im Linuxkernel benutzt wird? Mehr
> akzeptiert und mehr verbreitet - ja, aber mit Sicherheit nicht besser.

Es soll wohl eher als Qualitätsmerkmal dienen: Wenn es nicht gut wäre, 
würde es im Kernel doch nicht verwendet werden.

> Da muss man nur anschauen, was Linus von C erwartet hat und welche
> "features" er da haben wollte. (z.B. memcpy ganz durch memmove ersetzen
> und weiterer Blödsinn)

Nachdem ich die Gründe, die er gegen C++ im Kernel vorgebracht hat, 
gelesen habe, kann ich ihn in der Hinsicht eh nicht mehr ernst nehmen.

von MaWin (Gast)


Lesenswert?

ein lupenreiner Demokrat schrieb:
> Wird Rust besser, wenn die Sprache im Linuxkernel benutzt wird? Mehr
> akzeptiert und mehr verbreitet - ja, aber mit Sicherheit nicht besser.

Selbstverständlich wird Rust dadurch besser, indem Features stabilisiert 
werden und neue für die OS-Entwicklung zwingend notwendige Features 
hinzugefügt werden. Es gibt auch eine Trackingliste für dies, falls es 
dich interessiert.

Rolf M. schrieb:
>> Da muss man nur anschauen, was Linus von C erwartet hat und welche
>> "features" er da haben wollte. (z.B. memcpy ganz durch memmove ersetzen
>> und weiterer Blödsinn)
>
> Nachdem ich die Gründe, die er gegen C++ im Kernel vorgebracht hat,
> gelesen habe, kann ich ihn in der Hinsicht eh nicht mehr ernst nehmen.

Wie wäre es denn, wenn ihr Argumente vorbringt, statt beleidigt zu sein 
und alles als Blödsinn zu bezeichnen?
Ich weiß, das ist unüblich hier im Forum.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Wie wäre es denn, wenn ihr Argumente vorbringt, statt beleidigt zu sein
> und alles als Blödsinn zu bezeichnen?
> Ich weiß, das ist unüblich hier im Forum.

Frei nach Nietzsche: "Gegen Rust hat man keine Argumente, man hat 
/dev/null".

von Rolf M. (rmagnus)


Lesenswert?

MaWin schrieb:
> Rolf M. schrieb:
>>> Da muss man nur anschauen, was Linus von C erwartet hat und welche
>>> "features" er da haben wollte. (z.B. memcpy ganz durch memmove ersetzen
>>> und weiterer Blödsinn)
>>
>> Nachdem ich die Gründe, die er gegen C++ im Kernel vorgebracht hat,
>> gelesen habe, kann ich ihn in der Hinsicht eh nicht mehr ernst nehmen.
>
> Wie wäre es denn, wenn ihr Argumente vorbringt, statt beleidigt zu sein
> und alles als Blödsinn zu bezeichnen?

Warum sollte ich beleidigt sein? Ich bin lediglich der Ansicht, dass 
seine Argumente gegen C++ ziemlich an den Haaren herbeigezogen wirken. 
Er ist ja nun durchaus auch bekannt dafür, sich manchmal etwas zu sehr 
von Emotionen treiben zu lassen. Deshalb bin ich bei manchen Aussagen 
von ihm etwas vorsichtig.

von MaWin (Gast)


Lesenswert?

Rolf M. schrieb:
> Warum sollte ich beleidigt sein? Ich bin lediglich der Ansicht, dass
> seine Argumente gegen C++ ziemlich an den Haaren herbeigezogen wirken.

Weil...?
Du lieferst wieder keine Argumente und stattdessen nur Emotion.

Und dann kritisierst du genau das an Linus.

So trägst du nichts zur Diskussion bei, außer dass ich nun weiß, dass du 
wohl aus unbekannten Gründen gerne C++ im Kernel hättest und irgendwie 
memcpy besser als memmove findest. Das ist für mich eine nutzlose 
Information, solange du das nicht begründest.

Verstehst du jetzt das Problem?

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


Lesenswert?

MaWin schrieb:
> Das ist für mich eine nutzlose Information, solange du das nicht
> begründest.

Warum memcpy() und memmove() zwei getrennte Funktionen sind, sollte 
eigentlich sonnenklar sein: wenn der Programmierer bereits weiß, dass es 
keine Überlappung geben kann, kann man sich die Umständlichkeit eines 
memmove() schlicht sparen. Und in sehr, sehr vielen Fällen weiß er das.

Außerdem ist der C-Standard eh sehr, sehr zurückhaltend mit dem 
Entfernen alter Funktionen, daran wird auch ein Herr Torvalds nichts 
ändern. Der einzige Fall, der mir gerade in den Sinn kommt, dürfte 
gets() sein – aus gutem Grund, aber auch nur nach einer sehr langen 
Phase der deprecation (der eigentlich eine noch längere Phase 
vorangegangen ist, in denen so ziemlich jeder davor gewarnt hat, die 
Funktion überhaupt zu benutzen).

: Bearbeitet durch Moderator
von 🐧 DPA 🐧 (Gast)


Lesenswert?

Naja, memmove hat doch auch seine Grenzen, wo heutzutage ein Buffer ja 
mehrfach gemappt sein kann. Mappe ich die selbe Page auf 1000 und 2000, 
und mache dann z.B. ein memmove von 20 bytes von 2000 nach 1010, müsste 
man das wie ein memmove von 1000 nach 1010 behandeln, aber memmove wird 
nichts von dem Mapping wissen, und 1000 < 1010 aber 2000 > 1010, und 
peng.

Ich könnte mir gut vorstellen, das man da in einem Kernel mehr aufpassen 
muss, und memmove dann eher dazu führen könnte, das man sich in falscher 
Sicherheit wiegt, wenn man eigentlich hätte checken müssen, was da 
physisch gemappt war.
Ist aber nur reine Spekulation.

von cppbert (Gast)


Lesenswert?

Jörg W. schrieb:
> Warum memcpy() und memmove() zwei getrennte Funktionen sind, sollte
> eigentlich sonnenklar sein: wenn der Programmierer bereits weiß, dass es
> keine Überlappung geben kann, kann man sich die Umständlichkeit eines
> memmove() schlicht sparen. Und in sehr, sehr vielen Fällen weiß er das.

das weiß hier jeder, auch MaWin

aber warum Linus dann memmove semantic in memcpy fordert ist komisch 
weil nicht so optimierbar/schnell ist - einfach nur weil damit mehr 
Probleme per se kompensiert werden?

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Warum memcpy() und memmove() zwei getrennte Funktionen sind, sollte
> eigentlich sonnenklar sein: wenn der Programmierer bereits weiß, dass es
> keine Überlappung geben kann, kann man sich die Umständlichkeit eines
> memmove() schlicht sparen. Und in sehr, sehr vielen Fällen weiß er das.

Ich weiß was memcpy und memmove sind.
Darum ging es nicht. Lies bitte worauf du antwortest auch einmal durch.

> Außerdem ist der C-Standard eh sehr, sehr zurückhaltend mit dem
> Entfernen alter Funktionen, daran wird auch ein Herr Torvalds nichts
> ändern.

Ehm. doch.
Der Kernel verwendet überhaupt keine stdlib.

von MaWin (Gast)


Lesenswert?

Ich kann ja mal ein Argument liefern:

Die Diskussion memcpy vs. memmove ist ein Argument für Rust.
Denn in Rust können Speicherbereiche niemals überlappen und gleichzeitig 
drauf zugegriffen werden.
Deshalb kann der Compiler alles mit memcpy kopieren. Der Programmierer 
braucht sich darüber gar keine Gedanken zu machen.

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


Lesenswert?

MaWin schrieb:
> Der Kernel verwendet überhaupt keine stdlib.

Warum diskutiert Linus dann überhaupt über memmove() und memcpy()?

Oder hat der Kernel vielleicht doch eine Standard(ähnliche) Bibliothek?

Es ist doch völlig schnuppe, wer diese Bibliothek geschrieben hat. 
Entscheidend ist, ob sie die Funktionen (oder einige davon) des 
Standards bereitstellt.

MaWin schrieb:
> Denn in Rust können Speicherbereiche niemals überlappen und gleichzeitig
> drauf zugegriffen werden.

🐧 DPA 🐧 schrieb:
> Naja, memmove hat doch auch seine Grenzen, wo heutzutage ein Buffer ja
> mehrfach gemappt sein kann.

Yup … daran wird vermutlich auch Rust nicht viel ändern können.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Yup … daran wird vermutlich auch Rust nicht viel ändern können.

Da liegst du leider komplett falsch mit deiner Vermutung.
Mehrfaches Mapping und gleichzeitiger Zugriff ist nicht möglich in Rust.
Aliasing ist auch nicht möglich in Rust.

Rust forciert, dass die Teilnehmer sich synchronisieren. Also das, was 
man in C auch machen muss um ein korrektes Programm zu bekommen.

Ich würde vorschlagen, dass du vielleicht erst einmal die Grundlagen von 
Rust lernst. Das macht auch ziemlich viel Spaß.

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


Lesenswert?

MaWin schrieb:
> Mehrfaches Mapping und gleichzeitiger Zugriff ist nicht möglich in Rust.

Es ging mir (und DPA) nicht um irgendwelche Elemente einer Sprache, 
sondern um das VM Mapping der CPU. Damit kann man immer Aliase 
erzeugen, denn dieses Konstrukt ist vollständig außerhalb des 
Einflussbereichs irgendeiner Programmiersprache. Dementsprechend kann 
man, wenn man an der Stelle nicht sauber drauf achtet, sowohl die 
Eigentümerschafts-Annahmen von Rust gefährden genauso wie halt (das war 
das ursprüngliche Argument) Annahmen, die eine memmove()-Implementierung 
intern trifft.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Dementsprechend kann
> man, wenn man an der Stelle nicht sauber drauf achtet, sowohl die
> Eigentümerschafts-Annahmen von Rust gefährden

Im Rust Code muss man auf überhaupt nicht darauf achten.

Dass man das System außerhalb von Rust so einstellen und betreiben muss, 
dass die Anforderungen von Rust eingehalten werden, sollte 
selbstverständlich sein.
Das gilt auch für C. Wenn die Hardware sich nicht ans Maschinenmodell 
der jeweiligen Sprache hält, dann ist das natürlich ein Bug.

Fakt ist und bleibt, dass die Überlegung memcpy vs. memmove in Rust 
nicht existiert.

Aber ich weiß jetzt nicht, worauf du hinaus willst.
Zur Erinnerung: Es ging hier nicht um die Technik hinter memcpy/memmove, 
sondern um die politischen Entscheidungen von Linus. Es wurde 
kritisiert, dass Linus angeblich memmove statt memcpy generell bevorzugt 
und die Forumsteilnehmer hier das für Blödsinn halten. Eine Begründung 
gab es leider nicht.

von Cyblord -. (cyblord)


Lesenswert?

cppbert schrieb:
> aber warum Linus dann memmove semantic in memcpy fordert ist komisch
> weil nicht so optimierbar/schnell ist - einfach nur weil damit mehr
> Probleme per se kompensiert werden?

Außerhalb einer sehr überschaubaren Nerd-Blase, juckt es doch wirklich 
niemanden was Linus zum Thema C sagt oder meint.

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


Lesenswert?

MaWin schrieb:
> Eine Begründung gab es leider nicht.

Genauer gesagt: Begründungen interessieren dich nicht.

Lassen wir das, hat mit Rust eh nichts zu tun.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Außerhalb einer sehr überschaubaren Nerd-Blase, juckt es doch wirklich
> niemanden was Linus zum Thema C sagt oder meint.

Wieder ein Beitrag ohne Inhalt und Argument.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Genauer gesagt: Begründungen interessieren dich nicht.

Bitte was?
Herr Moderator, warum greifen sie mich nun persönlich an?

Wo soll diese Begründung denn gewesen sein? Zitat bitte!

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


Lesenswert?

MaWin schrieb:
> Wo soll diese Begründung denn gewesen sein? Zitat bitte!

Ich dachte, du wüsstest den Unterschied zwischen beiden? Die 
Performance. Sicher nicht auf jeder Architektur gleichermaßen.

Aber wie du schon festgestellt hast, hat das mit Rust eh nichts zu tun, 
weil dieses durch seine Eigentümerschaft so eine Unterscheidung nicht 
benötigt.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Der Kernel managt auch Userspace Ressourcen. Und Userspace kann nun mal 
Speicher mehrfach mappen. Vermutlich wird das kein all zu grosses 
Problem sein, aber in gewissen Situationen wird man da sicher auch in 
Rust die Checks nicht vergessen dürfen, die man momentan noch in C 
macht, oder anderweitig abstrahieren. Wobei man da bei der UAPI etwas 
eingeschränkt ist, die soll nämlich stabil bleiben. Kommt halt drauf an, 
wo und in wie weit es später eingesetzt werden wird, ob man sich da noch 
damit auseinander setzen wird.

von MaWin O. (mawin_original)


Lesenswert?

Jörg W. schrieb:
> Ich dachte, du wüsstest den Unterschied zwischen beiden? Die
> Performance

Ach komm. Du trollst doch.
Noch einmal extra für dich: Es ging nicht um die Technik hinter 
memcpy/memmove.
Es ging um den politischen Umgang von Linus damit und um die 
Einschätzung dieses Umgangs als Blödsinn.

von MaWin O. (mawin_original)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Der Kernel managt auch Userspace Ressourcen. Und Userspace kann
> nun mal
> Speicher mehrfach mappen.

Es ist auch in C überhaupt nicht vorgesehen direkt auf 
Userspace-Speicher zuzugreifen. Das führt im besten Fall zu einem Crash. 
Im schlimmsten Fall funktioniert es manchmal und führt dann zu 
Securityproblemen.

In Rust ist es gar nicht möglich solche verbotenen Aktionen zu 
programmieren.

> Vermutlich wird das kein all zu grosses
> Problem sein, aber in gewissen Situationen wird man da sicher auch in
> Rust die Checks nicht vergessen dürfen

Nein. Man kann sie nicht vergessen. Das ist der entscheidende 
Unterschied. Man kann in Rust kein funktionierendes Programm schreiben, 
das Speicherfehler hat. Solche Programme kompilieren schon zu 90% gar 
nicht erst.
Und das gilt auch für Kernelcode.

von Cyblord -. (cyblord)


Lesenswert?

Jörg W. schrieb:
> Ich dachte, du wüsstest den Unterschied zwischen beiden? Die
> Performance. Sicher nicht auf jeder Architektur gleichermaßen.

Außerdem arbeitet memmove auf einem temporären Speicherblock. Das ist 
ein riesen Unterschied zu memcpy. Gerade auf kleinen und sehr kleinen 
Controllern. Das ist auch so ein Umstand den die Rust-Boys immer so 
gerne vergessen: Was für den PC gut ist, kann für den kleinen Controller 
katastrophal sein. Die ganzen Sicherheitsfeatures kommen mit einem 
Preisschild. Die sind nicht umsonst.

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:

> Nein. Man kann sie nicht vergessen. Das ist der entscheidende
> Unterschied. Man kann in Rust kein funktionierendes Programm schreiben,
> das Speicherfehler hat. Solche Programme kompilieren schon zu 90% gar
> nicht erst.

Erklär mal bitte grob wie der Compiler erkennt, wenn jemand zur Laufzeit 
(z.B. sagen wir mal per UART), entscheidet, er möchte nun 50 Byte 
senden, mein Programm die 50 Bytes allokiert und dann aber 51 Byte rein 
schreibt.
Ich meine, klar, teure Checks zur Laufzeit, inkl. die dafür notwendigen 
Strukturen für die Arraygrößen usw. kann man haben. Will man nur im 
Embedded Umfeld so gut wie nicht.

Aber zur Kompilierzeit? Geht halt nicht.

Daher ist das alles Geschwurbel. Mit religiösem Eifer vorgetragen. Da 
können die Zeugen Jehovas noch was von lernen.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Das ist
> ein riesen Unterschied zu memcpy. Gerade auf kleinen und sehr kleinen
> Controllern.

Genau. Zum Glück kann man in Rust ja immer memcpy nutzen, weil es kein 
Aliasing gibt. Man hat also immer den Performancevorteil.

> Das ist auch so ein Umstand den die Rust-Boys immer so
> gerne vergessen: Was für den PC gut ist, kann für den kleinen Controller
> katastrophal sein.

Merkste selbst, gell?

> Die ganzen Sicherheitsfeatures kommen mit einem
> Preisschild.

Die allermeisten Sicherheitsfeatures von Rust sind zero cost.
Und die wenigen übrigen sind mit sehr sehr geringen Runtimekosten 
verbunden.

Im Vergleich zwischen zwischen einem korrekten C/C++ Programm (also mit 
notwendigen Sicherheitschecks) und einem Rust-Programm ist die 
Performance identisch.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin O. schrieb:
> Nein. Man kann sie nicht vergessen. Das ist der entscheidende
> Unterschied. Man kann in Rust kein funktionierendes Programm schreiben,
> das Speicherfehler hat.

Garantien basieren immer auf Annahmen. Solange diese alle erfüllt sind, 
ist alles gut. Sobald das nicht mehr der Fall ist, hat man Probleme. Wie 
bei meinem memmove Beispiel oben.

Das ist ein wichtiger Teil davon, wie man Sicherheitslücken findet. Und 
im Kernel wird man auch für solche Spezialfälle die Augen offen halten 
müssen. Ein "kann eh nicht passieren", funktioniert nicht besonders gut 
um mögliche Probleme zu finden.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Aber zur Kompilierzeit? Geht halt nicht.

Das hat niemand jemals behauptet.
In Rust wird die immer notwendige Laufzeitprüfung lediglich von der 
Sprache forciert. Das Endergebnis ist das gleiche, wenn man die 
notwendige Abfrage in C nicht vergisst.

> Mit religiösem Eifer vorgetragen.

Sehe ich genau so.

von MaWin O. (mawin_original)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Ein "kann eh nicht passieren", funktioniert nicht besonders gut
> um mögliche Probleme zu finden.

Wenn etwas nicht passieren kann, weil die Randbedingungen es forcieren, 
dann kann es auch keine Probleme geben. Einfache Logik.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
>> Aber zur Kompilierzeit? Geht halt nicht.
>
> Das hat niemand jemals behauptet.

Ach nicht?

> Solche Programme kompilieren schon zu 90% gar
> nicht erst.

> In Rust wird die immer notwendige Laufzeitprüfung lediglich von der
> Sprache forciert. Das Endergebnis ist das gleiche, wenn man die
> notwendige Abfrage in C nicht vergisst.

In C implementiert aber normalerweise niemand Laufzeitchecks für JEDEN 
Zugriff. Genau das bräuchtest du aber um 100% Sicherheit zu haben.
Du musst bei JEDEM Zugriff auf das Array, egal ob lesend oder 
schreibend, Code ablaufen lassen. Dazu brauchst du Speicher wo die 
Informationen zu jedem Array drin stehen.
Dieser Code prüft dann für JEDEN ZUGRIFF ob der innerhalb der Grenzen 
stattfindet.
Vergleiche das mal mit einem data[55]=x und dann erzähle nochmal was von 
Zero-Cost.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Die Randbedingungen sind in dem Fall die Annahmen, die man sicherstellen 
muss. Genau da muss man hinsehen. Genau das ist es ja.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> In C implementiert aber normalerweise niemand Laufzeitchecks für JEDEN
> Zugriff.

Nein. Das ist Unsinn.
Man braucht genau einen einzigen Check ganz am Anfang der 
Verarbeitungskette. Genau wie in C auch.
Unnötige Checks fügt der Compiler nicht ein. Und wenn der Compiler die 
nicht-Notwendigkeit nicht beweisen kann, dann hat man halt einen 
zusätzlichen Check. Das ist absolut vernachlässigbar.
Viele Performancemessungen zeigen genau das.

Du hängst dich hier an einem Detail auf.

Wenn du wirklich irgendeine Stelle findest, bei der dieser eine 
Maschinenzyklus dich wirklich stört, kannst du an dieser einen Stelle ja 
gerne unsafe-Rust verwenden. Der Rest des Programms bleibt trotzdem 
safe. Im Gegensatz zu einem C-Programm, wo alles unsafe ist.

Moderne Compiler sind etwas schlauer als dein K&R-Compiler.
Stichwort LTO.

von MaWin O. (mawin_original)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Die Randbedingungen sind in dem Fall die Annahmen, die man
> sicherstellen
> muss. Genau da muss man hinsehen. Genau das ist es ja.

Ja. Die muss man sicherstellen.

Und in C muss man zusätzlich noch jede einzelne Zeile auf UB 
kontrollieren und Sicherstellen, dass kein UB auftritt.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:

> Nein. Das ist Unsinn.
> Man braucht genau einen einzigen Check ganz am Anfang der
> Verarbeitungskette.

Wie soll das gehen? Und was ist eine Verarbeitungskette? Es geht um 
einen Zugriff auf ein Element in einem Array.

> Du hängst dich hier an einem Detail auf.

Nö ich hänge mich an der Aussage auf, dass Rust auf magische und 
kostenlose weise alles mögliche prüfen kann. Dass es allein durch die 
Sprache selbst sicher wird. Meist zur Kompilierzeit und wenn dann mit 
quasi null kosten zur Laufzeit.
Das ist deine Grundaussage zu Rust. Kein Detail. Und da hätte ich halt 
mal gerne zu einem konkreten Beispiel eine Aussage wie Rust das machen 
will.

> Wenn du wirklich irgendeine Stelle findest, bei der dieser eine
> Maschinenzyklus dich wirklich stört,

Du prüfst Array Zugriffe mit EINEM Maschinenzyklus? Rust ist echt der 
Hammer.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Wie soll das gehen? Und was ist eine Verarbeitungskette? Es geht um
> einen Zugriff auf ein Element in einem Array.

LTO + moderner Compiler.

> Nö ich hänge mich an der Aussage auf, dass Rust auf magische und
> kostenlose weise alles mögliche prüfen kann.

Magie ist unbeteiligt.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
> Cyblord -. schrieb:
>> Wie soll das gehen? Und was ist eine Verarbeitungskette? Es geht um
>> einen Zugriff auf ein Element in einem Array.
>
> LTO + moderner Compiler.

Ach so. Dann sind meine Fragen natürlich beantwortet. Danke.

von cppbert (Gast)


Lesenswert?

@Cyblord

Es geht MaWin nicht um Fremdeinflüsse die im Kernel durch Hardware und 
User-Space auftauchen können - die sind ja nicht Teil von einem sicherem 
Rust Code daher muss man dort genau so wie in C vorsichtig sein - aber 
diese Vorsicht ist so gut wie nicht nötig wenn du dich dann irgendwann 
in safem Rust-Code befindest (also weiter drinnen) - dann sorgt der 
Kompiler für dich - so lange du nicht wieder an solche Grenzen zur 
Hardware/User-Space kommst

Es ist mir unverständlich wie man nur im entferntesten, als erfahrerener 
Entwickler glauben kann das ein andere Entwickler meinen könnte das es 
da irgendwie eine Magische-Hochperformante Sicherungsschicht geben kann 
- keine Sprache der Welt kann das und das hat hier auch noch nie 
irgendjemand (auch nicht MaWin) behauptet - es wird immer nur sehr 
intensiv so rausinterpretiert weil der andere das ja nicht wirklich im 
Detail verstehen "kann"

von Cyblord -. (cyblord)


Lesenswert?

cppbert schrieb:
> Es geht MaWin nicht um Fremdeinflüsse die im Kernel durch Hardware und
> User-Space auftauchen können - die sind ja nicht Teil von einem sicherem
> Rust Code daher muss man dort genau so wie in C vorsichtig sein - aber
> diese Vorsicht ist so gut wie nicht nötig wenn du dich dann irgendwann
> in safem Rust-Code befindest (also weiter drinnen) - dann sorgt der
> Kompiler für dich - so lange du nicht wieder an solche Grenzen zur
> Hardware/User-Space kommst

Ach so na klar. Also der Benefit ist ein total sicherer Kernel. Der 
natürlich auch nicht nach außen mit irgendwas reden darf, damit man den 
Safe-Space nicht verlässt. Dann aber, dann kommt Rust voll zur Geltung.
Natürlich nicht User Space. Die Applikation juckt ja nicht.

Das mag ja im Bereich Linux-PC-Programmierung für irgendwen ein Benefit 
darstellen. Wer weiß, es soll solche Leute geben.
Aber wenn man in Richtung Embedded und Mikrocontroller absteigt, findet 
man immer weniger Kernel und immer mehr Applikation. Und dann stellt 
sich, mal wieder, die Frage, warum soll man hier nun Rust nehmen?

Können wir also im Protokoll festhalten dass Rust im Bereich Embedded 
nichts bringt? Sondern vor allem im Bereich Linux-Kernel-Nerdistan.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

cppbert schrieb:
> Es geht MaWin nicht um Fremdeinflüsse die im Kernel durch Hardware und
> User-Space auftauchen können - die sind ja nicht Teil von einem sicherem
> Rust Code daher muss man dort genau so wie in C vorsichtig sein - aber
> diese Vorsicht ist so gut wie nicht nötig wenn du dich dann irgendwann
> in safem Rust-Code befindest (also weiter drinnen) - dann sorgt der
> Kompiler für dich - so lange du nicht wieder an solche Grenzen zur
> Hardware/User-Space kommst

Gut erklärt. Vielleicht versteht es nun jemand. :)

Hinzu kommt noch:
Diese "Sicherheitsschichten" sind mit Hilfe von unsafe-Rust 
implementiert und in der Regel sehr sehr dünn. Meistens sogar zero-cost. 
Weil die meisten der Abfragen, sodenn welche notwendig sind, im C Code 
eh schon vorhanden sein müssen. Es kommen nur äußerst selten zusätzliche 
Lauzzeitabfragen rein.

Und falls Cyblord jetzt doch die eine hochkritische Stelle in seinem 
Rustcode findet, wo eine Abfrage unnötigerweise generiert wird und es 
wirklich wehtut, dann kann er genau an dieser Stelle selbstverständlich 
eigenverantwortlich einen unchecked-Zugriff in unsafe-Rust machen. Gar 
kein Problem und auch völlig legitim. Damit ist diese eine Stelle 
performancemäßig entschärft und sämtliche andere Safetyprüfungen werden 
weiterhin alle durchgeführt. Auch für diesen einen unchecked-Zugriff. 
z.B. der Borrow-checker ist weiterhin aktiv. Der komplette restliche 
Rustcode ist unbeeinflusst.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Aber wenn man in Richtung Embedded und Mikrocontroller absteigt, findet
> man immer weniger Kernel und immer mehr Applikation. Und dann stellt
> sich, mal wieder, die Frage, warum soll man hier nun Rust nehmen?

Weil man heute ein sicheres und performantes Embedded-Programm komplett 
in Safe-Rust schreiben kann. Stand der Technik heute auf ESP32 und 
vielen weiteren gängigen Controllern.

Das alles mit äußerst geringem Overhead. Nur so als Beispiel: Das 
komplette Zugriffsmanagement auf die Peripherie ist zu 99.9% statisch 
geprüft. Es gibt lediglich eine einzige Laufzeitabfrage während der 
Initialisierung. Und wenn man wollte, könnte man die auch noch 
herausoperieren.

Multicoreentwicklung auf embedded Hardware ist mit Rust sehr elegant und 
hat so gut wie keinen höheren Overhead als ein korrektes C-Programm 
hätte. Locks, IRQ-disable oder atomics braucht man in C auch.

Probiere es doch einfach mal aus!

> Können wir also im Protokoll festhalten dass Rust im Bereich Embedded
> nichts bringt?

Ungern. Denn es bringt, wie gesagt, enorme Vorteile.

Cyblord -. schrieb:
> klar. Also der Benefit ist ein total sicherer Kernel. Der
> natürlich auch nicht nach außen mit irgendwas reden darf

Das interpretiere ich natürlich nur als Trollversuch deinerseits.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
> Das alles mit äußerst geringem Overhead. Nur so als Beispiel: Das
> komplette Zugriffsmanagement auf die Peripherie ist zu 99.9% statisch
> geprüft.

Kunststück. Das IST ja auch alles statisch. Fehlerhafte Zugriffe 
passieren aber, oh Wunder, im Speicher. Und meistens eben bei 
dynamischem Speicher. Das ist statische Zugriffe leicht prüfen kann, ist 
doch eine Binse.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Kunststück. Das IST ja auch alles statisch. Fehlerhafte Zugriffe
> passieren aber, oh Wunder, im Speicher. Und meistens eben bei
> dynamischem Speicher. Das ist statische Zugriffe leicht prüfen kann, ist
> doch eine Binse.

Ach. Eben hast du noch gesagt, dass Rust ein enormes Problem auf 
Embedded hat.
Jetzt erkennst du, dass genau das Gegenteil der Fall ist.
Gut, dass auch du Erkenntnis erlangen kannst.

Dynamischen Speicher kann Rust übrigens auch zum allergrößten Teil 
statisch prüfen. Lediglich dynamische Arrays nicht. Aber das kann C auch 
nicht.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
> Ach. Eben hast du noch gesagt, dass Rust ein enormes Problem auf
> Embedded hat.

Ja und ich habe ein KONKRETES Beispiel genannt wo ich das Problem sehe. 
Da bist du bisher nicht drauf eingegangen.
Für statische Tests kann ich auch LINT nehmen. Da brauche ich keine neue 
Sprache.
Deine Aussage war bisher dass Rust Code automatisch sicher ist.
Jetzt lernen wir: Außer da eben da wo er nicht sicher ist. Also da wo 
ich nicht einfach statisch zur Kompilierzeit prüfen kann.
Und deshalb machst du so ein Fass für Rust auf?

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Ja und ich habe ein KONKRETES Beispiel genannt wo ich das Problem sehe.

Ich sehe auch bei mehrmaligem Lesen kein konkretes Beispiel. Könntest du 
das noch einmal wiederholen, bitte?

Cyblord -. schrieb:
> Deine Aussage war bisher dass Rust Code automatisch sicher ist.
> Jetzt lernen wir: Außer da eben da wo er nicht sicher ist.

Dann hast du etwas gelernt, was hier nie gesagt wurde.
Rust-Code ist automatisch sicher. Punkt.

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> Ach so na klar. Also der Benefit ist ein total sicherer Kernel. Der
> natürlich auch nicht nach außen mit irgendwas reden darf, damit man den
> Safe-Space nicht verlässt. Dann aber, dann kommt Rust voll zur Geltung.
> Natürlich nicht User Space. Die Applikation juckt ja nicht.

habe nicht ich noch sonst jemand hier je behauptet - das ist deine 
Interpretation, die Durchdringunsschichten sind immer gefährlich und 
werden es auch bleiben - aber wenn der innere Code dann Safe ist habe 
ich trotzdem einen Gewinn - wenn du den nicht sehen kannst bringt es 
nichts mit dir über die Vorteile zu diskutieren, oder?

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
> Cyblord -. schrieb:
>> Ja und ich habe ein KONKRETES Beispiel genannt wo ich das Problem sehe.
>
> Ich sehe auch bei mehrmaligem Lesen kein konkretes Beispiel. Könntest du
> das noch einmal wiederholen, bitte?

Beitrag "Re: Rust - ist das hier um zu bleiben?"

>
> Cyblord -. schrieb:
>> Deine Aussage war bisher dass Rust Code automatisch sicher ist.
>> Jetzt lernen wir: Außer da eben da wo er nicht sicher ist.
>
> Dann hast du etwas gelernt, was hier nie gesagt wurde.
> Rust-Code ist automatisch sicher. Punkt.

Eigentlich haben wir gerade genau das Gegenteil gelernt.

Aber dann sag mir wie Rust den Code in meinem obigen Beispiel sicher 
macht. Und zwar ohne Laufzeitoverhead.

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> Deine Aussage war bisher dass Rust Code automatisch sicher ist.
> Jetzt lernen wir: Außer da eben da wo er nicht sicher ist. Also da wo
> ich nicht einfach statisch zur Kompilierzeit prüfen kann.
> Und deshalb machst du so ein Fass für Rust auf?

das hat er nie gesagt nur für die geschlossenen Teile, die nicht wenig 
sind weil nicht alles in einem Kernel oder Applikation durchdringt in 
jeder Zeile Code den Kernel- oder User-Space

Rust ist safe so lange du nicht in eine andere Welt wechselst - das ist 
niemals eine Anforderung an Rust gewesen - wenn du darauf rumreiten 
willst das du es so verstanden hast ist es eben so, aber leider keine 
sinnvolle Diskussion

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> Aber dann sag mir wie Rust den Code in meinem obigen Beispiel sicher
> macht. Und zwar ohne Laufzeitoverhead.

gar nicht - weil es das für Durchdringunsschichten nicht kann und nicht 
will - das muss du Hand anlegen - kein Pro-Rust entwickler stellt das in 
frage der Gewinn ist woanders

von Cyblord -. (cyblord)


Lesenswert?

cppbert schrieb:

> das hat er nie gesagt nur für die geschlossenen Teile, die nicht wenig
> sind weil nicht alles in einem Kernel oder Applikation durchdringt in
> jeder Zeile Code den Kernel- oder User-Space

Liegt das an mir dass ich kein Stück von diesem Gestammel verstehen?

> Rust ist safe so lange du nicht in eine andere Welt wechselst

Andere Welt. Soso.
>  - das ist
> niemals eine Anforderung an Rust gewesen

Natürlich nicht. Nicht sicher in einer anderen Welt. Und nicht in der 
Anders-Welt. Aber in irgendeiner Welt bestimmt.

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

cppbert schrieb:
> der Gewinn ist woanders

Wo finde ich den Gewinn wenn mein Array an dieser Stelle überläuft? Wo 
steckt hier der totale Vorteil von Rust? Irgendwo muss er doch sein.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Aber dann sag mir wie Rust den Code in meinem obigen Beispiel sicher
> macht. Und zwar ohne Laufzeitoverhead.

Das habe ich bereits erklärt.
Der Rust-Code benötigt nicht mehr Checks als gleichwertig sicherer 
C-Code.
Den Index musst du ein mal ganz am Anfang prüfen. In C muss man es und 
in Rust wäre es sinnvoll, wenn man keine Panics haben will.

Weitergehende Indexchecks werden vom LLVM praktisch immer 
herausoptimiert, solange die Codepfade statisch verfolgbar sind.
Und wenn nicht, dann steht dir wie bereits gesagt frei in genau diesen 
Sonderfällen unchecked-Zugriffe in Unsafe-Rust zu machen.
In Summe hast du immer noch einen enormen Sicherheitsgewinn.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
> Den Index musst du ein mal ganz am Anfang prüfen.

Anfang von was? Wenn dann muss man den Index bei JEDEM ZUGRIFF prüfen. 
Wie sonst soll das gehen?

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Anfang von was? Wenn dann muss man den Index bei JEDEM ZUGRIFF prüfen.
> Wie sonst soll das gehen?

Am Anfang der Callchain. Dort, wo du den Index aus den untrusted-Daten 
herausgepopelt hast.
Wenn der Index einmal < len(buffer) ist, dann ist er es im weiteren 
Codeverlauf auch noch. Weitere Prüfungen finden nicht statt. Auch nicht 
bei Mehrfachzugriffen.

Aber selbst wenn du alle Arrayzugriffe unchecked machst, was ohne 
Weiteres trivial möglich ist, dann hast du immer noch alle restlichen 
Vorteile und Sicherheiten von Rust. z.B. den Borrowchecker.
Empfehlenswert ist es natürlich nicht, weil der Performancegewinn 
praktisch Null ist.
Aber die Wahl liegt bei dir.

In Rust ist diese ganze Array- und Index-Popelei sowieso nur selten 
notwendig. Es gibt dort deutlich einfachere und sichere Konzepte wie 
z.B. Iteratoren.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
> Wenn der Index einmal < len(buffer) ist, dann ist er es im weiteren
> Codeverlauf auch noch.

Nur verwendet man nicht dauernd den gleichen Index.

MaWin O. schrieb:
> In Rust ist diese ganze Array- und Index-Popelei sowieso nur selten
> notwendig. Es gibt dort deutlich einfachere und sichere Konzepte wie
> z.B. Iteratoren.

Das nächste No-Go für embedded. Solche Konzepte sind für PC ja ok. Aber 
sie zeigen dass Rust auf Embedded noch ganz eigene Probleme hat.
Gleiches gilt natürlich für die Systemprogrammierung. Wieder mal führt 
an C kein Weg vorbei. Wenn man nicht ständig und für alles enorme 
Datenstrukturen mitführen will.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Das nächste No-Go für embedded. Solche Konzepte sind für PC ja ok. Aber
> sie zeigen dass Rust auf Embedded noch ganz eigene Probleme hat.

Iteratoren sind zero-cost im Vergleich zur indexbasierten Lösung.

Cyblord -. schrieb:
> Nur verwendet man nicht dauernd den gleichen Index.

Dann musst du natürlich auch in C prüfen, ob dein Index noch in bounds 
ist.
Arithmetik auf indices führt gerne zu Sicherheitsbugs. Gern gehabt, 
kommt immer mal wieder rein. Erheitert uns ständig in der C-Welt.

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> MaWin O. schrieb:
>> In Rust ist diese ganze Array- und Index-Popelei sowieso nur selten
>> notwendig. Es gibt dort deutlich einfachere und sichere Konzepte wie
>> z.B. Iteratoren.
>
> Das nächste No-Go für embedded. Solche Konzepte sind für PC ja ok. Aber
> sie zeigen dass Rust auf Embedded noch ganz eigene Probleme hat.

Warum sollte das für embedded ein No-Go sein?
Langsam denke ich das du nicht sehr viel Ahnung hast - was auch deine 
bisherigen Post erklären könnte

Nicht mal ein C++-Iterator ist in embedded in jeglich Form ein Problem - 
weil so wie bei Rust ein Value-based Konzept

Versuch doch mal nur das Problem mit Iterator und embedded zu erklären - 
vielleicht verstehen wir dann endlich mal was du nicht verstehst

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> Wo finde ich den Gewinn wenn mein Array an dieser Stelle überläuft? Wo
> steckt hier der totale Vorteil von Rust? Irgendwo muss er doch sein.

die Linux-Kernel Entwickler akzeptieren Rust als erste weitere 
Programmiersprache neben C (nachdem C++ vor Jahren schon massiv 
abgelehnt wurde) weil die so viel Langeweile habe und Linus dafür 
bekannt ist immer die neusten Hype-Sprachen in den Linux Kernel 
aufzunehmen

Erklär uns doch mal warum das passiert - unter der Annahme das die nicht 
alle völlig bescheuert sind

von Cyblord -. (cyblord)


Lesenswert?

cppbert schrieb:
> die Linux-Kernel Entwickler akzeptieren Rust als erste weitere
> Programmiersprache neben C (nachdem C++ vor Jahren schon massiv
> abgelehnt wurde) weil die so viel Langeweile habe und Linus dafür
> bekannt ist immer die neusten Hype-Sprachen in den Linux Kernel
> aufzunehmen

Also Beweis durch Autorität? Rust ist ja wirklich ne Kirche.

Es kann zwar niemand darlegen warum man bei Embedded/µC C durch Rust 
ersetzen sollte, aber 100 Linux Entwickler können sich nicht irren.

> Langsam denke ich das du nicht sehr viel Ahnung hast - was auch deine
> bisherigen Post erklären könnte

Natürlich. Wer nicht fest in eurem Glauben steht, hat halt keine Ahnung.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Es kann zwar niemand darlegen warum man bei Embedded/µC C durch Rust
> ersetzen sollte

Ach troll dich doch bitte. Das ist doch keine ernsthafte Diskussion.

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> Also Beweis durch Autorität? Rust ist ja wirklich ne Kirche.
> ...
> Natürlich. Wer nicht fest in eurem Glauben steht, hat halt keine Ahnung.

sei doch nicht so extrem - ich hab dich nett nach einer Erklärung zu dem 
Iterator/embedded Problem gebeten und eine Erklärung warum Linux das 
jetzt akzeptiert - beides hast du nicht beantwortet und bist dan gleich 
zum Glaubenskrieg-Argument gewechselt

von Cyblord -. (cyblord)


Lesenswert?

cppbert schrieb:
> ich hab dich nett

Äh nein. Mir Ahnungslosigkeit zu unterstellen fällt nicht unter nett. Es 
ist der typische Deppen-Abschluss einer Diskussion.

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
>> ich hab dich nett
>
> Äh nein. Mir Ahnungslosigkeit zu unterstellen fällt nicht unter nett. Es
> ist der typische Deppen-Abschluss einer Diskussion.

Jetzt beantworte doch einfach die Frage warum das Iterator-Konzept von 
Rust für embedded so untragbar ist und was die Gründe dafür sind warum 
du denkst das Rust überhaupt in Linux akzeptiert wurde - ich 
entschuldige mich auch dafür ein wenig ausfallend gewesen zu sein

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Mir Ahnungslosigkeit zu unterstellen fällt nicht unter nett. Es
> ist der typische Deppen-Abschluss einer Diskussion.

Es war lediglich eine Feststellung aufgrund deiner Aussagen hier.
Ahnungslosigkeit zu vermuten ist da noch das Harmlose. Ich würde 
stattdessen eher vorsätzliche Trollerei vermuten.

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> cppbert schrieb:
>> ich hab dich nett
>
> Äh nein. Mir Ahnungslosigkeit zu unterstellen fällt nicht unter nett. Es
> ist der typische Deppen-Abschluss einer Diskussion.

das Rust-Iteratoren-Konzept einfach so (ohne jegliche Erklärung bisher) 
als untragbar für embedded zu bezeichnen ist nicht ein klein-wenig 
Ahnungslos?

und von Glauben und Autorität zu sprechen wenn es darum geht das der 
Linux Kernel das erste mal in seiner Geschichte eine weitere Sprache 
akzeptiert ist differenziert?

Machen es solche Aussagen vielleicht ungewollt einfacher ein wenig an 
deiner Erfahrung zu zweifeln?

von Rolf M. (rmagnus)


Lesenswert?

MaWin schrieb:
> Rolf M. schrieb:
>> Warum sollte ich beleidigt sein? Ich bin lediglich der Ansicht, dass
>> seine Argumente gegen C++ ziemlich an den Haaren herbeigezogen wirken.
>
> Weil...?
> Du lieferst wieder keine Argumente und stattdessen nur Emotion.

Nein. Du interpretierst nur in meine Postings sehr viel rein, das da 
nicht steht.

> Und dann kritisierst du genau das an Linus.
>
> So trägst du nichts zur Diskussion bei, außer dass ich nun weiß, dass du
> wohl aus unbekannten Gründen gerne C++ im Kernel hättest

Nein, das weißt du nicht, du denkst es nur. Hab ich nie gesagt. Ich hab 
lediglich gesagt, dass seine Argumente dagegen nicht stichhaltig wirken.

> und irgendwie memcpy besser als memmove findest.

Zu memcpy hab ich überhaupt nichts gesagt.

> Das ist für mich eine nutzlose Information, solange du das nicht
> begründest.

Natürlich ist sie nutzlos, weil falsch.

von MaWin (Gast)


Lesenswert?

Rolf M. schrieb:
> Ich hab
> lediglich gesagt, dass seine Argumente dagegen nicht stichhaltig wirken.

Ja. Und eine Begründung bleibst du uns weiterhin schuldig.
Alleine darum ging es mir.

Dass dir Linus Meinung nicht passt, habe ich verstanden.
Warum das so ist, habe ich nicht verstanden.

Rolf M. schrieb:
> Zu memcpy hab ich überhaupt nichts gesagt.

Ja, das habe ich dann verwechselt, weil das ein Gast war, der in genau 
die gleiche Tröte wie du geblasen hat.
Sinnloses Abladen von: Määh ich finde Linus Aussage blöd.

von MaWin (Gast)


Lesenswert?

Ok, ich habe jetzt noch einmal nachgeschaut.

Rolf M. schrieb:
>> Da muss man nur anschauen, was Linus von C erwartet hat und welche
>> "features" er da haben wollte. (z.B. memcpy ganz durch memmove ersetzen
>> und weiterer Blödsinn)
>
> Nachdem ich die Gründe, die er gegen C++ im Kernel vorgebracht hat,
> gelesen habe, kann ich ihn in der Hinsicht eh nicht mehr ernst nehmen.

Schon komisch, dass du genau auf die memcpy-Sache antwortest und jetzt 
behauptest nie etwas dazu gesagt zu haben.
Du bist unehrlich.

von Rolf M. (rmagnus)


Lesenswert?

MaWin schrieb:
> Schon komisch, dass du genau auf die memcpy-Sache antwortest

Auf welche "Sache" hätte ich denn sonst antworten sollen? Wenn da jetzt 
z.B. strlen oder was weiß ich was statt memcpy gestanden hätte, wäre 
meine Antwort dieselbe gewesen. Um die konkrete Funktion ging es gar 
nicht. Denk dir den Teil in den Klammern einfach weg, der ist unwichtig.

> Du bist unehrlich.

Nein, du legst es offenbar einfach darauf an, mich misszuverstehen.

von cppbert (Gast)


Lesenswert?

Rolf M. schrieb:
> Nein, du legst es offenbar einfach darauf an, mich misszuverstehen.

Wir alle zusammen legen es darauf an, das scheint hier echt 
Forums-Kultur zu sein - Fehleannahmen, Empfindlichkeiten etc.

aber warum machen wir jetzt nicht einfach ein Reset und kommen wieder 
aufs technische zurück und hören auf so zu "menscheln"

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Tatsächlich ist doch schon längst alles gesagt worden. Mittlerweile ist 
das doch längst nur noch ein Webethread für die Rust Fanatiker. Wenn ich 
gekonnt hätte, hätte ich den längst geschlossen. Am Anfang hatte man 
noch Vorteile, echte Nachteile & Problematische Aspekte diskutiert. Aber 
das ist schon längst wieder unter den uninteressanten "alles toll, alles 
sicher, schau, neue Features, schau, jetzt mehr Rust dort" Beiträgen 
begraben, und wird eh von keinem mehr gelesen.

von MaWin (Gast)


Lesenswert?

Rolf M. schrieb:
> Um die konkrete Funktion ging es gar nicht.

Gut, dass wir uns dann doch einig sind.

Und wie sieht es mit einer Antwort aus?
Warum glaubst du, dass Linus nicht in der Lage ist 
Grundlagenentscheidungen zu treffen?
Ich kenne Linus Entscheidungen als sehr pragmatisch und sehr 
praxisorientiert.
Bei Entscheidungen über C++, memcpy und Rust und vielem mehr.
Der Erfolg gibt ihm Recht und seine Argumente sind für mich gut 
nachvollziehbar.

Also nun Butter bei die Fische:
Warum kannst du ihn "eh nicht mehr ernst nehmen"?

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> "alles toll, alles
> sicher, schau, neue Features, schau, jetzt mehr Rust dort"

Und wo ist das Problem?
Ich schreibe sowohl über Vor- und Nachteile von Rust.

Ich stelle hier zu 90% eh nur Unwahrheiten von Leuten, die 
offensichtlich nie mit der Sprache gearbeitet haben, richtig.

> uninteressanten

Warum diskutierst du trotzdem mit?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Naja, Linus wird auch langsam alt. Klare ansagen kann er auch nicht mehr 
machen, die SJW haben ihn einmal kräftig unter den Bus geworfen und so 
entschärft (wobei etwas weniger erfolgreich als bei RMS). Die Maintainer 
grosser Subsysteme sind auch schon etwas ausser Kontrolle, so macht z.B. 
Intel immer mal wieder was, wo sie dann schnell einen Release 
nachschieben müssen (letztens 
https://www.phoronix.com/news/Intel-iGPU-Avoid-Linux-5.19.12, davor ging 
mal plötzlich ältere FW nicht mehr, usw.) Eigentlich sollten das die 
diversen Maintainerschichten vorher abfangen. Und mit Greg Kroah-Hartman 
ist auch schon ein Linus-Ersatz vorhanden.

Ich denke, Linus hat die Zügel längst abgegeben.

von cppbert (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Aber
> das ist schon längst wieder unter den uninteressanten "alles toll, alles
> sicher, schau, neue Features, schau, jetzt mehr Rust dort" Beiträgen
> begraben, und wird eh von keinem mehr gelesen.

das ist schon irgendwie verständlich was du sagst - aber am Anfang hiess 
es immer das wird nichts weil es kein GCC Frontend dafür gibt, und weil 
es eh nicht relevant wird, keine Standard existiert, und das es auch gar 
niemand braucht weil C++ das schon alles perfekt kann und,und,und

jetzt zieht Rust als erste weitere Sprachen in den Linux-Kernel ein (von 
dem wir denke ich alles wissen wie gross, relevant der ist und auch wie 
viele Entwickler daran arbeiten) und schon ist irgendwie klar das es die 
Linux-Kernel-Entwickler es auch nicht blicken - und das Microsoft und 
google usw. nachziehen ist ja auch nur eine allgem. blöde Idee weil die 
ihren Kram nicht unter Kontrolle bringen - aber komischerweise sind das 
die Zugpferde für alle C++ Sachen die in den letzten 15 Jahren gemacht 
wurden (pushen des C++ Standards, Sanitizer und und und)

keiner sagt das Rust die Lösung aller Problem zu 100% ist (und das hat 
MaWin auch noch nie so global für alle Kontexte vermittel)
aber zumindest eine nette Disukssion-Grundlage könnte es sein

und dann kommen hier die Python, Javascript, C und C++ Entwickler und 
lassen sich (oft) ohne Background über irgendwelche Details aus und alle 
werden irgendwie sehr schnell sehr emotional - warum auch immer

von cppbert (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Und mit Greg Kroah-Hartman
> ist auch schon ein Linus-Ersatz vorhanden.

aber der supportet doch auch pro-aktiv die Rust intergration - hat eines 
der ersten Linux-Beispiele mit dem Integrator entwickelt - also i don't 
care Linus, aber Greg hat schon viel früher mit Rust angefangen - so 
what?

von cppbert (Gast)


Lesenswert?

und niemand hier ist so dumm zu glaube das ein schneller Einzug oder die 
Nutzung von Rust von mehreren Big-Playern irgendeine Qualitäts oder 
Perfektions-Relevanz hat, da geht es nur darum das sowas wie mit dem 
Linux-Kernel bisher einfach noch nie passiert ist und das entweder ein 
riesen Fehler ist oder eben eine sinnvolle Entscheidung - als 
Echtwelt-Gegenargument zu der ganzen Es-ist-perfekt-wie-es-ist-Fraktion

von DPA (Gast)


Lesenswert?

cppbert schrieb:
> aber der supportet doch auch pro-aktiv die Rust intergration

Ja eben. Ich sag ja:

🐧 DPA 🐧 schrieb:
> Ich denke, Linus hat die Zügel längst abgegeben.

von cppbert (Gast)


Lesenswert?

DPA schrieb:
> cppbert schrieb:
>> aber der supportet doch auch pro-aktiv die Rust intergration
>
> Ja eben. Ich sag ja:
>
> 🐧 DPA 🐧 schrieb:
>> Ich denke, Linus hat die Zügel längst abgegeben.

das stimmt auch nicht weil er ist auch sehr aktiv an der Integration 
beteiligt und freut sich ja (laut der letzten Keynote) darauf die Syntax 
zu lernen und richtig damit zu arbeiten (und das wird er - weil wir ihn 
kennen, er ist kein Man der leeren Worte, war er nie)

von Cyblord -. (cyblord)


Lesenswert?

cppbert schrieb:
> das stimmt auch nicht weil er ist auch sehr aktiv an der Integration
> beteiligt und freut sich ja (laut der letzten Keynote) darauf die Syntax
> zu lernen und richtig damit zu arbeiten (und das wird er - weil wir ihn
> kennen, er ist kein Man der leeren Worte, war er nie)

Das klingt als wenn die KP eine Pressemitteilung über Xi rausbringt. 
Oder in Nord-Korea über Kim geredet wird.

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> cppbert schrieb:
>> das stimmt auch nicht weil er ist auch sehr aktiv an der Integration
>> beteiligt und freut sich ja (laut der letzten Keynote) darauf die Syntax
>> zu lernen und richtig damit zu arbeiten (und das wird er - weil wir ihn
>> kennen, er ist kein Man der leeren Worte, war er nie)
>
> Das klingt als wenn die KP eine Pressemitteilung über Xi rausbringt.
> Oder in Nord-Korea über Kim geredet wird.

ja schon - aber es ist doch trotzdem Realität das die beiden führenden 
Köpfe der Linux-Entwicklung das machen und google, Amazon und andere 
grosse das aktiv mit tragen - ich nehme einfach an das dir klar ist wie 
stark die grossen 5 von einem funktionierendem Linux abhängig sind

btw: du hast immer noch nicht erklärt warum das Rust Iteratoren Konzept 
eine No-go für embedded ist - wird langsam Zeit

von MaWin (Gast)


Lesenswert?

Am Anfang des Threads, 2019, war die Frage:
> Rust - ist das hier um zu bleiben?

Damals war Rust noch in so gut wie keinem relevanten Produkt vertreten.
Viele Sachen waren unklar. Viele Features fehlten.

Heute, 2022, würde ich sagen:

> Rust - Das ist hier um zu bleiben!

Heute sind immer noch viele Sachen unklar. Viele Features fehlen immer 
noch.
Aber es hat sich enorm was getan.
Viele Fragen wurden geklärt und viele Features wurden hinzugefügt. Man 
hat begonnen an einer Referenzdoku zu arbeiten. Alternative Compiler 
nähern sich rasant dem praktischen Nutzen. Rust auf Embedded 
funktioniert einfach mittlerweile (mit unstable compilern). Etc, etc...

Und politisch ist Rust von vielen Firmen und großen Projekten als gute 
Alternative anerkannt und wird aktiv genutzt. Diese Akzeptanz breitet 
sich immer weiter aus und ist selbstverstärkend.

Hinter Rust steht ein ganz anderes Moment als hinter all den anderen 
neuen Sprachen der letzten 20 Jahre. Das liegt natürlich auch daran, 
dass Rust viele der guten Features der Sprachen der letzten 20 Jahre 
vereinen konnte. Das liegt aber auch daran, dass Rust Dinge kann, die 
andere Sprachen nicht können und wahrscheinlich auch nie können werden.

Und das Allerbeste: Wenn ihr Rust scheiße findet und es nicht verwenden 
wollt, dann verwendet es einfach nicht. So einfach ist das tatsächlich.

Es gibt gar keinen Grund hier wild herumzuspekulieren und dabei seine 
eigene völlige Unkenntnis komplett preiszugeben.
Ihr merkt das natürlich selbst nicht. Das ist klar.

Während ihr euch dann weiterhin mit C eure Bufferoverflows 
implementiert, habe ich stattdessen Spaß mit Rust.

Denn Rust macht tatsächlich Spaß. Und ich muss zugeben, dass ich das 
vorher auch nicht gedacht hätte.

Irgendwann wird Rust von einer noch besseren Sprache abgelöst werden. 
Und da freue ich mich jetzt schon drauf.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin O. schrieb:
> Genau. Zum Glück kann man in Rust ja immer memcpy nutzen, weil es kein
> Aliasing gibt. Man hat also immer den Performancevorteil.

Bei aliasing geht es ja nur darum, dass man nicht mit einem 
Pointer/Referenz auf Speicher schreibt, und mit einem anderen Pointer im 
selben Scope das selbe dann wieder liest, oder? Aliasing wäre dann eine 
etwas schwächere Garantie, als dass 2 Pointer nicht auf den selben 
Speicherbereich zeigen.

In C verarbeite ich buffer manchmal inplace, nach dem Schema:
1
int i_in, i_out;
2
for(i_in=0,i_out=0; i_out < length; i_in++){
3
  unsigned char ch = buffer[i_in];
4
  ...
5
  if(bla) buffer[i_out++] = 123;
6
}
7
length = i_out;

Sprich, i_in wird bei jedem Durchlauf inkrementiert, i_out aber nicht 
(und auch höchstens einmal), damit ist immer i_in <= i_out garantiert, 
und es ist sichergestellt, dass beim schreiben nach buffer[i_out] nie 
etwas überschrieben wird, was danach mit i_in gelesen wird. Das müsste 
also eigentlich statisch erkennbar sein.

Das ist recht nützlich, z.B. beim dekodieren von Hex zu Binär, aber auch 
bei base64 kann man es machen. (Das habe ich erst letztens mal wieder 
gemacht 
https://github.com/Daniel-Abrecht/ml666/blob/ml666/src/json-token-emmiter.c#L151-L200 
(da sollte ich eventuell noch ein par "restrict" keywords reinwerfen).

Kann man dieses Pattern, diesen Konstraint, in safe Rust bereits 
effektiv abdecken, oder muss man da Speicher verschwenden?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Edit: Ich meinte "i_in < length". Zu schnell getippt...

von Cyblord -. (cyblord)


Lesenswert?

> Kann man dieses Pattern, diesen Konstraint, in safe Rust bereits
> effektiv abdecken, oder muss man da Speicher verschwenden?

Bei allem was wir hier inzwischen über Rust lesen, solltest du Speicher 
im Überfluss haben.
In-Place kann da gar nichts gehen. Temporäres rumkopieren von Daten 
(bezüglich Laufzeit gratis natürlich) und anlegen von massiven 
Datenstrukturen (bezüglich Speicher gratis) für jeden Pups ist da mal 
default. Da passt dann die Empfehlung für memmove schon exakt ins Bild.

: Bearbeitet durch User
von 🐧 DPA 🐧 (Gast)


Lesenswert?

Ich denke mit einem Callback könnte man sowas sicher abstrahieren, als C 
code würde das so aussehen:
1
struct optional {
2
  bool empty;
3
  uint8_t value;
4
}
5
void inplace_replace(const size_t length, uint8_t slice[length], struct optional (*const transformer)(const uint8_t input)){
6
  for(size_t i_in=0,i_out=0; i_in < length; i_in++){
7
    const struct optional out = transformer(slice[i_in]);
8
    if(out.empty) slice[i_out++] = out.value;
9
  }
10
}

Das müsste doch so ähnlich auch in Rust machbar sein. Gibts da schon was 
in der Rust Standard Library oder so für so eine inplace_replace 
Funktion?

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> Bei allem was wir hier inzwischen über Rust lesen, solltest du Speicher
> im Überfluss haben.

das sagt absolut niemand (keine Ahnung wo du das gelesen hast) - 
Move-Semantic ist bei Rust der Default (im gegensatz zu C/C++ wo Kopie 
der Defaul ist) - kopiert wird da recht wenig und ein grosses Ziele ist 
Resourcen-Vebrauch auf C Niveau oder besser

btw: du hast immer noch nicht erklärt warum das Rust Iteratoren Konzept
eine No-go für embedded ist - wird langsam wirklich Zeit

von Kaj (Gast)


Lesenswert?

Ich schmeiß einfach mal nom in den Raum:
https://github.com/Geal/nom

Parser die nom nutzen:
https://github.com/Geal/nom#parsers-written-with-nom

https://github.com/Geal/nom#technical-features
1
zero-copy:
2
If a parser returns a subset of its input data, it will return a 
3
slice of that input, without copying
4
5
safe parsing: 
6
nom leverages Rust's safe memory handling and powerful types, and 
7
parsers are routinely fuzzed and tested with real world data. So far, 
8
the only flaws found by fuzzing were in code written outside of nom
9
10
speed: 
11
Benchmarks have shown that nom parsers often outperform many 
12
parser combinators library like Parsec and attoparsec, some regular 
13
expression engines and even handwritten C parsers

von cppbert (Gast)


Lesenswert?

Kaj schrieb:
> Ich schmeiß einfach mal nom in den Raum:

warum?

von cppbert (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Bei aliasing geht es ja nur darum, dass man nicht mit einem
> Pointer/Referenz auf Speicher schreibt, und mit einem anderen Pointer im
> selben Scope das selbe dann wieder liest, oder?

Aliasing Probleme sind auch

std::vector<int> v{1,2}
int* a = &v[0];
v.push(20);
v.push(30);
v.push(40);
v.push(50);
-> wegen copy-on-resize im std::vector is a relativ sicher dangling

passiert aber genau so mit realloc in C

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> Da passt dann die Empfehlung für memmove schon exakt ins Bild.

das war von Linus für den Linux-Kernel, für den C code, null Bezug zu 
Rust

von Cyblord -. (cyblord)


Lesenswert?

cppbert schrieb:
> das war von Linus für den Linux-Kernel, für den C code, null Bezug zu
> Rust

Aber hallo, von DEM Linus der jetzt doch voll auf Rust abfährt.
Außerdem geht es eben um das Mindset hinter so einer Empfehlung. Da ist 
die Sprache egal.

: Bearbeitet durch User
von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> cppbert schrieb:
>> das war von Linus für den Linux-Kernel, für den C code, null Bezug zu
>> Rust
>
> Aber hallo, von DEM Linus der jetzt doch voll auf Rust abfährt.
> Außerdem geht es eben um das Mindset hinter so einer Empfehlung. Da ist
> die Sprache egal.

du hast immer noch nicht erklärt warum das Rust Iteratoren Konzept
eine No-go für embedded ist - brauchst du vielleicht noch ein bisschen 
mehr Zeit?

von cppbert (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> int i_in, i_out;
> for(i_in=0,i_out=0; i_out < length; i_in++){
>   unsigned char ch = buffer[i_in];
>   ...
>   if(bla) buffer[i_out++] = 123;
> }
> length = i_out;

ich sehe da keine Probleme mit Rust, wo sind da Aliasing Probleme?
In dem Beispiel ist doch alles nur Value-based, keine Pointer die 
irgendwie invalidieren

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Mit i_in und i_out lese / schreibe ich vom selben buffer. Man könnte die 
quasi als 2 Pointer im selben Scope betrachten. Dennoch ist 
sichergestellt, dass ich nie mit dem einen das lese, was ich mit dem 
anderen schreibe.

Die Sache ist also punkto aliasing komplett sicher, aber ich weiss 
nicht, wie man das mit safe Rust macht / abbildet (oder ob das überhaupt 
geht). Da fehlt mir etwas die Erfahrung. Aber vielleicht kann es ja 
jemand mit dieser Erfahrung hier übersetzen, sofern es möglich ist?

von cppbert (Gast)


Lesenswert?

so? https://gcc.godbolt.org/z/8KGPPc35f
1
fn _main() {
2
  let mut buffer: [u8; 23] = [0; 23];
3
  let bla = true;
4
  let mut i_out = 0usize;
5
  for i_in in 0..buffer.len() 
6
  {
7
        let _ch = buffer[i_in];
8
        if bla { buffer[i_out] = 123; }
9
        i_out+=1;
10
  }
11
}

die unterstriche vor _main und _ch sind nur dazu da um die unused-value 
warnung zu unterdrücken

Rust schützt dich nicht davor das dein Algorithmus jetzt kreuz und quer 
in deinem Array rumschreibt - nur das andere abhängigkeiten - andere 
Funktionen ausserhalb einen Zustand erwarten können, Rust versucht nicht 
deinen Algorithmus irgendwie zu validieren oder sonstige - falls das 
hier die Frage ist

von DPA (Gast)


Lesenswert?

Interressant. Dann sind gewisse Formen von Aliasing ja doch möglich.

von Cyblord -. (cyblord)


Lesenswert?

DPA schrieb:
> Interressant. Dann sind gewisse Formen von Aliasing ja doch möglich.

Rust ist 100% sicher, außer in den Welten in denen es nicht sicher ist.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Sprich, i_in wird bei jedem Durchlauf inkrementiert, i_out aber nicht
> (und auch höchstens einmal), damit ist immer i_in <= i_out garantiert,
> und es ist sichergestellt, dass beim schreiben nach buffer[i_out] nie
> etwas überschrieben wird, was danach mit i_in gelesen wird. Das müsste
> also eigentlich statisch erkennbar sein.

Mit Indexen gibt es eh kein Aliasing. Weder in C noch in Rust.

🐧 DPA 🐧 schrieb:
> Kann man dieses Pattern, diesen Konstraint, in safe Rust bereits
> effektiv abdecken

Klar.

Cyblord -. schrieb:
> Bei allem was wir hier inzwischen über Rust lesen, solltest du Speicher
> im Überfluss haben.
> In-Place kann da gar nichts gehen.

Kompletter Unsinn. Das ist genau wieder so ein Beitrag, wo du dich als 
komplett ahnungslos im Bezug auf Rust outest. "kann gar nicht gehen". 
Soso.
Wieso fragst du nicht stattdessen "kann das gehen?"? Falsches als Fakt 
hinzustellen und dann beleidigt sein wenn man korrigiert wird, das ist 
das größte Problem an diesem Thread.

In-Place hat überhaupt gar nichts mit Aliasing zu tun.

Wenn man eine mutable-Referenz hat, kann man damit natürlich machen, was 
man will. Lesen, Schreiben, in beliebiger Reihenfolge auf beliebigen 
Indexen.

Cyblord -. schrieb:
> Außerdem geht es eben um das Mindset hinter so einer Empfehlung.

Was meinst du damit?

🐧 DPA 🐧 schrieb:
> Die Sache ist also punkto aliasing komplett sicher, aber ich weiss
> nicht, wie man das mit safe Rust macht / abbildet

Ziemlich ganz genau so, wie du es auch in C schreibst.
Das unterscheidet sich nur syntaktisch minimalst und 
logisch/algorithmisch überhaupt nicht.

🐧 DPA 🐧 schrieb:
> Man könnte die quasi als 2 Pointer im selben Scope betrachten

Es sind aber keine 2 Pointer. Und es sind keine 2 Referenzen.
In Rust gibt es eine ganz klare Unterscheidung zwischen Referenzen und 
Indexen.

In Rust gibt es keine schwammigen Linien zwischen Pointern, Referenzen, 
Arrays, Indexen.
Das sind vier völlig verschiedene Datentypen, zwischen denen explizit 
konvertiert werde muss, wenn das denn gewünscht ist. In der Regel ist 
das aber nicht notwenig oder sogar unsafe.

Sowas wie Arrays, die in Pointer zerfallen oder Indexzugriffe, die 
eigentlich nur Syntaxzucker für Pointerarithmetik sind gibt es in Rust 
gar nicht. Indexzugriffe sind Indexzugriffe über die ganz klar 
definierten Index und IndexMut Traits.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> DPA schrieb:
>> Interressant. Dann sind gewisse Formen von Aliasing ja doch möglich.

Nein. Indexe sind keine Aliase.

https://doc.rust-lang.org/std/ops/trait.Index.html
https://doc.rust-lang.org/std/ops/trait.IndexMut.html

Indexe operieren auf einer Referenz (im Trait self genannt).
Diese Referenz darf und kann keinen Alias haben, wenn sie mutable ist. 
Das wird vom Compiler statisch forciert.

> Rust ist 100% sicher, außer in den Welten in denen es nicht sicher ist.

Oder wenn du wieder einmal etwas nicht verstanden hast.

Safe-Rust ist 100% memory safe. Immer.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> 100% memory safe

Gibts dafür ne Definition?

von DPA (Gast)


Lesenswert?

Logisch sind die Konzepte aber äquivalent, unabhängig von der 
Programmiersprache. Ob ich 2 Pointer oder 2 Indexe habe, im moment des 
Zugriffs wird genau die selbe Stelle geladen / geschrieben.

Damit lässt sich dann in Rust auch ein logisches äquivalent zu memmove 
abbilden, halt dann mit Indexen, statt Pointern.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
>> 100% memory safe
> Gibts dafür ne Definition?

Findest du sicher in der Rust-Referenz.
Darunter fallen: Kein UB, kein Use-After-Free und keine Data Races.

DPA schrieb:
> Logisch sind die Konzepte aber äquivalent

In diesem Fall schon. Ja. Wenn man in C denkt.

> unabhängig von der
> Programmiersprache. Ob ich 2 Pointer oder 2 Indexe habe, im moment des
> Zugriffs wird genau die selbe Stelle geladen / geschrieben.

Das ist halt die C-Denkweise. In Safe-Rust gibt es gar keine 
Pointerarithmetik. (Ja ja, Arithmetik gibts schon, aber man kann das 
Ergebnis nicht dereferenzieren).

Somit erübrigt sich die Frage in Rust, ob Pointerarithmetik das gleiche 
wäre wie Indexarithmetik. Diese Frage kann man wenn dann überhaupt nur 
in Unsafe-Rust stellen und beantworten.

DPA schrieb:
> Damit lässt sich dann in Rust auch ein logisches äquivalent zu memmove
> abbilden, halt dann mit Indexen, statt Pointern.

Ein äquivalent zu memmove ist, wie mehrfach schon gesagt, in Rust 
überhaupt gar nicht notwendig. Rust kopiert alles mit memcpy, weil es 
kein Aliasing gibt. (Kein mutable Aliasing. Aliasing auf Immutables gibt 
es natürlich. Aber da kann halt auch niemand drauf schreiben).

Und ob du jetzt deinen InPlace-Algorithmus oder etwas anderes schreibst, 
das hat doch gar nichts mit memmove zu tun.
Ein InPlace-Algorithmus hat doch per Definition immer nur ein Ownership. 
Also auch nur eine mutable-Referenz. Zwei Mutable-Referenzen gehen in 
Rust nicht. Aber die braucht man auch gar nicht. (Auch nicht in C.)

Irgendwie kommt es mir vor, als würden wir da aneinander vorbei reden.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
>> Logisch sind die Konzepte aber äquivalent
>
> In diesem Fall schon. Ja. Wenn man in C denkt.
>
>> unabhängig von der
>> Programmiersprache. Ob ich 2 Pointer oder 2 Indexe habe, im moment des
>> Zugriffs wird genau die selbe Stelle geladen / geschrieben.
>
> Das ist halt die C-Denkweise. In Safe-Rust gibt es gar keine
> Pointerarithmetik. (Ja ja, Arithmetik gibts schon, aber man kann das
> Ergebnis nicht dereferenzieren).

Am Ende wird alles zu ASM Code und da gibts dann wieder direkte (und 
indirekte) Pointer auf den Speicher. Also was soll so ein Geschwätz?
Das ist keine "C Sicht", das ist die scheiß Realität.

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
>>> 100% memory safe
>> Gibts dafür ne Definition?
>
> Findest du sicher in der Rust-Referenz.

Du hast mich falsch verstanden. Wenn du sagst, Rust ist 100% Memory 
Safe, dann muss du doch eine Liste von Konzepten im Kopf haben, welche 
für dich die 100% darstellen. Und Rust deckt sich damit.
Aber du behauptest jetzt, genau das Set welches Rust bietet, entspricht 
100%? Per welcher Definition?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin schrieb:
> Das ist halt die C-Denkweise. In Safe-Rust gibt es gar keine
> Pointerarithmetik.

Nein, mein Argument ist ein rein logisches. Welche Terminologie oder 
Semantik Rust oder C dort verwenden, ist irrelevant.

Der Rest mag ja alles stimmen. Aber fundamental logisch betrachtet, ist 
und bleibt es ein spezieller Fall von erlaubtem Aliasing. Auch wenn die 
Rust läute das nicht so nennen und nicht wahr haben wollen.

PS: Klar, das ist hier sinnvoll (also ein feature, kein bug), und mit 
vernachlässigbaren negativen Implikationen. Es geht mir hier um logische 
Konsistenz bei der Betrachtung & Argumentation über des Systems, und 
nicht darum, ein praktisches Problem heraufzubeschwören, wo keines ist.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Am Ende wird alles zu ASM Code und da gibts dann wieder direkte (und
> indirekte) Pointer auf den Speicher.

> Also was soll so ein Geschwätz?

Es zeigt sehr schön, dass du keine Ahnung davon hast, wie Sprachen 
definiert sind.
Rust arbeitet, genau wie C auch, auf Basis eines virtuellen 
Maschinenmodell. In welches asm das dann irgendwann einmal übersetzt 
wird, spielt überhaupt keine Rolle. Weder in Rust, noch in C.

Es ist Rust als Sprache völlig egal, ob das Backend das Programm in Code 
für Maschinen mit oder ohne Pointer übersetzt. (Ja, ich weiß, dass es da 
cornercases gibt. (vgl. Cheri-Architektur). Aber keine dieser 
Cornercases führen zu UB oder Verlust von Rust-Garantien. Und daran wird 
gearbeitet.)

Erst nachdem Rust seine Sicherheitsgarantien statisch geprüft hat, wird 
die Kontrolle an LLVM übergeben. Dieser generiert dann irgendwann Code 
draus. Mit Rust hat das aber nichts mehr zu tun.

Die paar wenigen verbliebenen Sicherheitsgarantien, die Rust nicht 
statisch prüfen kann, resultieren dann in entsprechendem asm-Code, der 
zur Laufzeit die Dinge prüft.

von 2⁵ (Gast)


Lesenswert?

[Linus ist gegen C++ im Kernel aber für Rust]

Der Grund dafür ist doch relativ einfach: Linus war schon immer ein 
Assembler Hacker und hat halt irgendwann (pragmatisch) C als Assembler 
Ersatz akzeptiert. Er denkt aber immer noch als Assembler Hacker, d.h. 
bei Änderungen in C sieht er relativ schnell den Assembler Code, den den 
Compiler generiert, vor sich. Das kann er (und auch viele andere C 
Hacker) bei C++ nicht mehr so gut. C++ ist standardisiert, mit einem 
Zulassen von C++ wurden die ganzen teilweise obskur wirkenden C++ 
Formulierungen in den Kernel Einzug halten. Die Schnittmenge sehr guter 
Kernel Hacker und sehr guter C++ Programmierer ist nicht so groß. Wer 
soll denn verantwortungsvoll den neuen C++ Code im Kernel reviewen? Die 
"alte" Kernel-Hacker-Gilde eher nicht.
Einzelne C++ Features auszuschließen würde die Sache nicht besser 
machen, würde wohl in einem größeren Krieg enden. Aber ein paar Features 
wird man ausschließen müssen...
Nun ist aber Linus pragmatisch genug, um zu sehen, dass der Kernel auch 
eine Weiterentwicklung in Bezug auf Programmiersprache braucht. Rust hat 
dabei gegenüber C++ ein paar pragmatische Vorteile

a) bringt Sprachfeatures mit, die gut in den Bereich Betriebssystem 
passen

b) gleichzeitig klein genug, um es in vernünftiger Zeit zu lernen

c) Weit genug weg von C um keinen C/C++ Mischmasch entstehen zu lassen

d) gleichzeitig neu genug, um noch Einfluss auf die Sprachkonzepte zu 
nehmen um diese sinnvoll für Systemprogrammierung/Embedded zu entwickeln

e) Es gibt kaum Linux-Rust-Hacker, die Linus/die ganzen alten Linux 
Hacker zeigen würden, dass er bei Rust keine Ahnung hat bzw. es ist zzt. 
noch kein Problem, wenn ein "gestandener" Programmierer wenig Ahnung von 
Rust hat.

f) Geht die Sache mit Rust schief, kann man zur Not Rust besser als C++ 
wieder loswerden.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Per welcher Definition?

Der Rust-Definition. Ich habe jetzt echt keine Lust für dich zu googlen.

🐧 DPA 🐧 schrieb:
> ist und bleibt es ein spezieller Fall von erlaubtem Aliasing.

Das ist und bleibt Quatsch. Sowohl in C als auch in Rust.
Aliasing ist ein Konzept, das auf Typebene stattfindet. Indexierung ist 
ein Konzept, das auf Typ und auf Codeebene stattfindet.

In Rust sind Typ- und Codeebene viel besser getrennt als in C.

Eine Referenz ist kein Pointer.
Ein Pointer ist keine Adresse.
Eine Adresse ist keine Zahl (sieht man bei Cheri schön).
Ein Index hat mit Pointertypen und Referenztypen gar nichts zu tun.
Ein Index ist eine Zahl.

Das sind alles unterschiedliche Konzepte, die C vermischt und Rust aber 
(fast) alle strikt voneinander trennt.
Mehr kann ich dazu leider nicht mehr sagen.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Es ist simpel. Der Zugriff auf etwas braucht eine Referenz im 
allgemeinen sinne irgendwelcher Form darauf. Ob das ein Handle, ein 
Pointer, oder eine Kombination davon ist, ist da erstmal egal. Hat man 
es mit 2 Referenzen zutun, die auf das selbe verweisen, und man auf 
diese zugreift, hat man es mit aliasing im allgemeinen sinne zutun.

Es ist sinvoll, solche Konzepte verallgemeinert (unabhängig einer 
konkreten Sprache) betrachtet zu können, um Sprachunabhängig logische 
Überlegungen zu Situationen, welche diese involvieren, machen zu können. 
Und das hat hier ja auch sehr gut funktioniert. Jetzt kennen wir den 
gesamten Sachverhalt in Bezug auf Rust viel genauer, inklusive wie Rust 
diesen betrachtet.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Es ist simpel. Der Zugriff auf etwas braucht eine Referenz im
> allgemeinen sinne irgendwelcher Form darauf. Ob das ein Handle, ein
> Pointer, oder eine Kombination davon ist, ist da erstmal egal. Hat man
> es mit 2 Referenzen zutun, die auf das selbe verweisen, und man auf
> diese zugreift,

Korrekt.
Wenn man einen Pointer hat und mit zwei unterschiedlichen Indexe auf 
unterschiedliche Elemente zugreift, dann sind das unterschiedliche 
Elemente. Also kein Aliasing.
Auch in C nicht.

Verstehst du es nun?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Die Kombination Pointer + Index ist in den 2 Stellen als eine Referenz 
auf etwas im allgemeinen Sinne zu betrachten. Es spielt keine rolle, ob 
Rust oder C das als Aliasing bezeichnen. Im allgemeinen sinne ist es 
aber genau das.

von MaWin (Gast)


Lesenswert?

Ok, ich gebs auf. Du definierst dir deine eigene Definition von Aliasing 
zurecht, nur um Recht zu behalten.

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> DPA schrieb:
>> Interressant. Dann sind gewisse Formen von Aliasing ja doch möglich.
>
> Rust ist 100% sicher, außer in den Welten in denen es nicht sicher ist.

du hast immer noch nicht beschreiben warum das Rust Iterator-Konzept ein 
No-go für embedded ist

langsam denke ich schon das du recht anhnungslos bis, oder einfach nicht 
in der Lage bist gemachte Statements zu begründen

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Ohne ein allgemeines Konzept von Aliasing wäre es nicht möglich, darüber 
unabhängig von der Programmiersprache nachzudenken, und diese zu 
vergleichen. Programmiersprachen verwenden und benennen die selben sowie 
die verschiedensten Konzepte und Variationen davon, ziemlich beliebig. 
Es ist ziemlich einschränkend, wenn man nichts unabhängig von der 
Sprache konzeptualisieren kann/darf.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Ohne ein allgemeines Konzept

Ja. DPA. Du hast Recht. In allen Punkten.
Nach deiner Definition gibt es Aliasing in Rust. Nach deiner Definition 
gibt es alles, was du zurechtdefinierst in Rust.

Ist das nun ausreichend, damit du mit dem Unfug aufhörst?

von MaWin (Gast)


Lesenswert?

1
let person1 = "DPA";
2
let person2 = "DPA";
3
// mache etwas mit den beiden Handles in der µC.net Personendatenbank.
4
db.machewas(person1, person2);

Nach DPA's "allgemeinen Aliasing-Definition" wäre das also Aliasing.
Schön.
Bringt leider niemandem was.
Leider komplett nutzlos in der Diskussion.
Komplett nutzlos bei der Betrachtung und Analyse von Aliasing (wie der 
Rest der Welt es versteht) in Typsystemen.

Aber schön, dass wir nun auch DPA's Definition von Aliasing kennen.

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> Aber schön, dass wir nun auch DPA's Definition von Aliasing kennen.

Ich glaube DPA driftet gerade zur guten Seite der Macht (mit ein wenig 
unklaren Aussagen, aber er versuchts) - bisschen weniger agro reicht 
auch

von cppbert (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Es spielt keine rolle, ob
> Rust oder C das als Aliasing bezeichnen. Im allgemeinen sinne ist es
> aber genau das.

Aliasing ist ein Sprachkonzept - das kann jede Sprache für sich 
definieren oder nicht - das ist kein allgmeines Hardwarekonzept - oder 
hab deine Aussage falsch verstanden?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin schrieb:
> Nach DPA's "allgemeinen Aliasing-Definition" wäre das also Aliasing.

Das hängt in dem konkreten Beispiel von der Implementierung, und davon 
was "machewas" macht, ab. Oder zumindest würde es das dann, wenn man 
darauf zugriffe, aber in dem Beispiel weiss man das ja nicht. Angenommen 
es handelt sich um Rust (der selbe Code ist auch in ein paar anderen 
Sprachen, z.B. JS gültig), wäre es aber immerhin nicht mut (in rust 
Terminologie), immerhin weiss man also, das da nicht reingeschrieben 
wird, womit das ganze dann in dem Beispiel auch wieder keine grosse 
Rolle mehr spielen dürfte.

von cppbert (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> MaWin schrieb:
>> Nach DPA's "allgemeinen Aliasing-Definition" wäre das also Aliasing.
>
> Das hängt in dem konkreten Beispiel von der Implementierung, und davon
> was "machewas" macht, ab. Oder zumindest würde es das dann, wenn man
> darauf zugriffe, aber in dem Beispiel weiss man das ja nicht. Angenommen
> es handelt sich um Rust (der selbe Code ist auch in ein paar anderen
> Sprachen, z.B. JS gültig), wäre es aber immerhin nicht mut (in rust
> Terminologie), immerhin weiss man also, das da nicht reingeschrieben
> wird, womit das ganze dann in dem Beispiel auch wieder keine grosse
> Rolle mehr spielen dürfte.

Was möchtest du uns sagen? dein genanntes Beispiel ist in allen Sprachen 
die C/JS/Rust/Java/C#-Artig sind Aliasing frei - geht es hier immer noch 
um Aliasing?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

cppbert schrieb:
> 🐧 DPA 🐧 schrieb:
>> Es spielt keine rolle, ob
>> Rust oder C das als Aliasing bezeichnen. Im allgemeinen sinne ist es
>> aber genau das.
>
> Aliasing ist ein Sprachkonzept - das kann jede Sprache für sich
> definieren oder nicht - das ist kein allgmeines Hardwarekonzept - oder
> hab deine Aussage falsch verstanden?

Das Aliasing Konzept dient dazu, über Dinge Rückschlüsse ziehen zu 
können, wie z.B. ob der Compiler lese / schreibzugriffe umsortieren und 
wegoptimieren kann, ohne das Verhalten zu ändern. Aber es ist auch 
nützlich, um über Situationen argumentieren zu können, wo gleichwertige 
Referenzen ungültig werden. Unter diesen Gesichtspunkten kann man 
Aliasing verallgemeinert betrachten & definieren, als rein abstraktes 
Konzept. Man muss nur schauen, worauf kommt es tatsächlich an? Es ergibt 
sich dann quasi von selbst.

cppbert schrieb:
> Was möchtest du uns sagen? dein genanntes Beispiel ist in allen Sprachen
> die C/JS/Rust/Java/C#-Artig sind Aliasing frei - geht es hier immer noch
> um Aliasing?

In dem Beispiel von MaWin gibt es diverse Compiler, die die Strings 
zusammenfassen, weil sie die selben sind. Unter diesen umständen könnten 
die 2 Referenzen sich auf das selbe Objekt beziehen, und es gibt fälle, 
wo das relevant ist.

von cppbert (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> cppbert schrieb:
>> 🐧 DPA 🐧 schrieb:
>>> Es spielt keine rolle, ob
>>> Rust oder C das als Aliasing bezeichnen. Im allgemeinen sinne ist es
>>> aber genau das.
>>
>> Aliasing ist ein Sprachkonzept - das kann jede Sprache für sich
>> definieren oder nicht - das ist kein allgmeines Hardwarekonzept - oder
>> hab deine Aussage falsch verstanden?
>
> Das Aliasing Konzept dient dazu, über Dinge Rückschlüsse ziehen zu
> können, wie z.B. ob der Compiler lese / schreibzugriffe umsortieren und
> wegoptimieren kann, ohne das Verhalten zu ändern. Aber es ist auch
> nützlich, um über Situationen argumentieren zu können, wo gleichwertige
> Referenzen ungültig werden. Unter diesen Gesichtspunkten kann man
> Aliasing verallgemeinert betrachten & definieren, als rein abstraktes
> Konzept. Man muss nur schauen, worauf kommt es tatsächlich an? Es ergibt
> sich dann quasi von selbst.

das ist bekannt, wer es noch nicht weiß der kann: 
https://en.wikipedia.org/wiki/Aliasing_(computing) durchlesen

> cppbert schrieb:
>> Was möchtest du uns sagen? dein genanntes Beispiel ist in allen Sprachen
>> die C/JS/Rust/Java/C#-Artig sind Aliasing frei - geht es hier immer noch
>> um Aliasing?

> In dem Beispiel von MaWin gibt es diverse Compiler, die die Strings
> zusammenfassen, weil sie die selben sind. Unter diesen umständen könnten
> die 2 Referenzen sich auf das selbe Objekt beziehen, und es gibt fälle,
> wo das relevant ist.

das würden (manche Compiler) nur dann machen wenn die imutable sind - 
dann gibt es auch kein schreiben und daher auch kein Konfliktpotenzial

von 🐧 DPA 🐧 (Gast)


Lesenswert?

cppbert schrieb:
> das würden (manche Compiler) nur dann machen wenn die imutable sind -
> dann gibt es auch kein schreiben und daher auch kein Konfliktpotenzial

Das ist bei rust der Default. Wobei ich nicht weiss, ob rust Compiler 
die Strings zusammenfassen, und ich auch nicht weiss, ob Rust das 
definiert oder nicht.

Ein fall, wo so etwas aber Konfliktpotenzial bietet, ist bei 
Vergleichen. Falls die Sprache eine Möglichkeit bietet, Referenzen zu 
vergleichen, und die in dem fall dann gleich wären. Wenn diese 
Voraussetzungen gegeben sind, kann man gewisse Fehler machen.

von cppbert (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> cppbert schrieb:
>> das würden (manche Compiler) nur dann machen wenn die imutable sind -
>> dann gibt es auch kein schreiben und daher auch kein Konfliktpotenzial
>
> Das ist bei rust der Default.

weil die beiden immutable sind

> Wobei ich nicht weiss, ob rust Compiler
> die Strings zusammenfassen, und ich auch nicht weiss, ob Rust das
> definiert oder nicht.

also weisst du irgendwie gar nichts genaues dazu :)

> Ein fall, wo so etwas aber Konfliktpotenzial bietet, ist bei
> Vergleichen. Falls die Sprache eine Möglichkeit bietet, Referenzen zu
> vergleichen, und die in dem fall dann gleich wären. Wenn diese
> Voraussetzungen gegeben sind, kann man gewisse Fehler machen.

das klingt so als vermutest du eine Lücke im Rust Konzept, oder
driften wir gerade in ein anderes Thema?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

cppbert schrieb:
> das klingt so als vermutest du eine Lücke im Rust Konzept, oder
> driften wir gerade in ein anderes Thema?

Nein, Rust wird das schon richtig machen. Das ist nur einfach eine 
Allgemeine Sichtweise, wie ich solche Sachen betrachte, und wie ich über 
solche Dinge generell nachdenke.

Vielleicht kommt das wirklich auch ein wenig vom Arbeiten mit C. Da muss 
man, neben der Sprachsyntax, Semantik, usw. auch diese allgemeinen 
Konzepte alle immer im Überblick haben, sonst kann man dort Fehler 
machen. Im Umkehrschluss hiesse das dann, dass wen Rust einem dies 
abnimmt, ... Aber öffnen wie diese Büchse der Pandora mal lieber nicht.

von cppbert (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> cppbert schrieb:
>> das klingt so als vermutest du eine Lücke im Rust Konzept, oder
>> driften wir gerade in ein anderes Thema?
>
> Nein, Rust wird das schon richtig machen. Das ist nur einfach eine
> Allgemeine Sichtweise, wie ich solche Sachen betrachte, und wie ich über
> solche Dinge generell nachdenke.

Jetzt wirst du zu esotherisch... oder besser gesagt du verwässerst deine 
Klarheit

das ist hier auch oft das Problem: Konkrekte, kleine Themen werden nicht 
auf ihrem Level diskutiert und dann fängt irgendwann so eine allgmeine. 
Sprachdesign-Welle an und am Ende gibt es kein Ergebnis - bis MaWin 
irgendeine Neuigkeit einstellt und dann geht das wieder von vorne los :)

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Das hängt in dem konkreten Beispiel von der Implementierung, und davon
> was "machewas" macht, ab.

Ah. Komisch. Eben war es noch möglich eine allgemeine Definition zu 
haben. Plötzlich ist sie nicht mehr allgemein.

Du hast völlig Recht, dass es von der Sprache abhängt.
Dann lasse mich das mal etwas präziser formulieren: Ein 
Pointer-Aliasing, wie es C definiert, gibt es in Rust für 
mutable-Referenzen nicht.
Würdest du da mitgehen?

🐧 DPA 🐧 schrieb:
> Ein fall, wo so etwas aber Konfliktpotenzial bietet, ist bei
> Vergleichen. Falls die Sprache eine Möglichkeit bietet, Referenzen zu
> vergleichen, und die in dem fall dann gleich wären. Wenn diese
> Voraussetzungen gegeben sind, kann man gewisse Fehler machen.

Es gibt in Rust keine zwei Referenzen, die auf das gleiche Objekt 
zeigen, wenn eine oder mehrere davon mutable sind. Das versuchen wir dir 
hier seit Stunden beizubringen.

🐧 DPA 🐧 schrieb:
> Vielleicht kommt das wirklich auch ein wenig vom Arbeiten mit C. Da muss
> man, neben der Sprachsyntax, Semantik, usw. auch diese allgemeinen
> Konzepte alle immer im Überblick haben, sonst kann man dort Fehler
> machen. Im Umkehrschluss hiesse das dann, dass wen Rust einem dies
> abnimmt,

Völlig richtig. Endlich hast du es verstanden.

> ... Aber öffnen wie diese Büchse der Pandora mal lieber nicht.

Warum nicht?
Könnte es zu Erkenntnis führen?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin schrieb:
> 🐧 DPA 🐧 schrieb:
>> Das hängt in dem konkreten Beispiel von der Implementierung, und davon
>> was "machewas" macht, ab.
>
> Ah. Komisch. Eben war es noch möglich eine allgemeine Definition zu
> haben. Plötzlich ist sie nicht mehr allgemein.

Die Definition ist trotzdem noch allgemein. Das konkrete Beispiel ist es 
nicht. Und nachfolgend habe ich dann ja genauer beschrieben, unter 
welchen umständen es dort zu Aliasing kommen kann, bei diesem Beispiel.

Wenn ich sage, es gibt grüne Wände, und du sagst, dort ist eine Wand, 
ist die Grün? Dann kann ich allgemein schlussfolgern, dass die 
Möglichkeit besteht, dass die Wand grün sein könnte. Das macht meine 
Aussage nicht weniger Allgemein, und es macht Beschreibung nicht weniger 
spezifisch. Ich kann nichts genaueres sagen, aber ich kann doch etwas 
dazu sagen.
Und beim vorherigen Beispiel, konnte ich doch schon sehr viel dazu 
sagen.

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> Ein
> Pointer-Aliasing, wie es C definiert, gibt es in Rust für
> mutable-Referenzen nicht.
> Würdest du da mitgehen?
>
> 🐧 DPA 🐧 schrieb:
>> Ein fall, wo so etwas aber Konfliktpotenzial bietet, ist bei
>> Vergleichen. Falls die Sprache eine Möglichkeit bietet, Referenzen zu
>> vergleichen, und die in dem fall dann gleich wären. Wenn diese
>> Voraussetzungen gegeben sind, kann man gewisse Fehler machen.
>
> Es gibt in Rust keine zwei Referenzen, die auf das gleiche Objekt
> zeigen, wenn eine oder mehrere davon mutable sind.

das sind Beispiele für grosse Unterschiede zu bestehenden 
Programmiersprachen (C,C++,Java,C#), aber da sich die wenigsten mit 
diesen Details überhaupt auskennen können sie die Bedeutung sehr einfach 
als unrelevant empfinden

von cppbert (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Die Definition ist trotzdem noch allgemein. Das konkrete Beispiel ist es
> nicht. Und nachfolgend habe ich dann ja genauer beschrieben, unter
> welchen umständen es dort zu Aliasing kommen kann, bei diesem Beispiel.

aber eben nicht in Rust und darum geht doch hier, oder?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin schrieb:
> Ein Pointer-Aliasing, wie es C definiert, gibt es in Rust für
> mutable-Referenzen nicht.
> Würdest du da mitgehen?

Wieso sollte ich? Ich habe nie von Pointer-Aliasing, wie es C definiert, 
geredet, sondern mich auf das zugrundeliegende abstrakte Konzept 
bezogen. Du fährst dich so darauf fest, das nur im Kontext einer 
spezifischen Sprache betrachten zu wollen.

cppbert schrieb:
> aber eben nicht in Rust und darum geht doch hier, oder?

Doch, die ist genau so anwendbar. Das C und Rust seine eigene 
Terminologie und eigene Definitionen vom Begriff haben, ist da nicht 
relevant.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin schrieb:
>> ... Aber öffnen wie diese Büchse der Pandora mal lieber nicht.
>
> Warum nicht?
> Könnte es zu Erkenntnis führen?

Was passiert mit Piloten, die immer nur den Autopiloten Fliegen lassen? 
Sie verlernen es, selbst zu fliegen.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Du fährst dich so darauf fest,

Nein. Du redest dich hier raus.

> das nur im Kontext einer
> spezifischen Sprache betrachten zu wollen.

Es geht hier um Rust.

🐧 DPA 🐧 schrieb:
> Doch, die ist genau so anwendbar.

Ja. Wie gesagt, unter deiner Definition gibt es "Aliasing" in Rust.

von cppbert (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Wieso sollte ich? Ich habe nie von Pointer-Aliasing, wie es C definiert,
> geredet, sondern mich auf das zugrundeliegende abstrakte Konzept
> bezogen. Du fährst dich so darauf fest, das nur im Kontext einer
> spezifischen Sprache betrachten zu wollen.

das ist aber kein "abstraktes" sondern ein Sprachen-Konzept - das kannst 
du nicht allgemein definieren - das Rust-Design ist extra so definiert 
das Aliasing über das Typ-System nicht ausdrückbar ist, Bedeutet: Rust 
supportet kein Aliasing

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Was passiert mit Piloten, die immer nur den Autopiloten Fliegen lassen?
> Sie verlernen es, selbst zu fliegen.

Rust ist kein Autopilot.
Rust ist ein permanenter Fluglehrer, der ständig neben dem Piloten sitzt 
und Pilotenfehler sofort korrigiert, bevor sie zu Flugfehlern führen.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

cppbert schrieb:
> das ist aber kein "abstraktes" sondern ein Sprachen-Konzept

Du hat doch selbst auf 
https://en.wikipedia.org/wiki/Aliasing_(computing) verlinkt, wo das auch 
allgemein gehalten, mit Beispielen in mehreren Sprachen, ist.

Natürlich gibt es das als allgemeines, abstraktes Konzept.

von cppbert (Gast)


Lesenswert?

cppbert schrieb:
> 🐧 DPA 🐧 schrieb:
>> Wieso sollte ich? Ich habe nie von Pointer-Aliasing, wie es C definiert,
>> geredet, sondern mich auf das zugrundeliegende abstrakte Konzept
>> bezogen. Du fährst dich so darauf fest, das nur im Kontext einer
>> spezifischen Sprache betrachten zu wollen.
>
> das ist aber kein "abstraktes" sondern ein Sprachen-Konzept - das kannst
> du nicht allgemein definieren - das Rust-Design ist extra so definiert
> das Aliasing über das Typ-System nicht ausdrückbar ist, Bedeutet: Rust
> supportet kein Aliasing

aber natürlich kannst du Aliasing-Probleme in unsafe erzeugen - weil du 
da (sehr eingeschränkt) C-Semantik hast - aber wir reden nicht von 
unsafe weil das der geringste Teil des Projektes sein sollte und niemals 
schlimmer ist als was man mit C machen kann

von cppbert (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> cppbert schrieb:
>> das ist aber kein "abstraktes" sondern ein Sprachen-Konzept
>
> Du hat doch selbst auf
> https://en.wikipedia.org/wiki/Aliasing_(computing) verlinkt, wo das auch
> allgemein gehalten, mit Beispielen in mehreren Sprachen, ist.
>
> Natürlich gibt es das als allgemeines, abstraktes Konzept.

natürlich - aber nicht ohne Sprachebezug - somit nicht mehr 
allgemein/abstrakt

von 🐧 DPA 🐧 (Gast)


Lesenswert?

cppbert schrieb:
> 🐧 DPA 🐧 schrieb:
>> cppbert schrieb:
>>> das ist aber kein "abstraktes" sondern ein Sprachen-Konzept
>>
>> Du hat doch selbst auf
>> https://en.wikipedia.org/wiki/Aliasing_(computing) verlinkt, wo das auch
>> allgemein gehalten, mit Beispielen in mehreren Sprachen, ist.
>>
>> Natürlich gibt es das als allgemeines, abstraktes Konzept.
>
> natürlich - aber nicht ohne Sprachebezug - somit nicht mehr
> allgemein/abstrakt

Doch, auch ohne Sprachebezug. Wie fängt der Artikel an? Mit  "In 
*computing*". Nicht mit "In Rust" oder mir "In C". Es gibt in dem 
Artikel auch konkrete Beispiele, aber eben, als Beispiele, nicht als 
Definition.

von cppbert (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Doch, auch ohne Sprachebezug. Wie fängt der Artikel an? Mit  "In
> *computing*". Nicht mit "In Rust" oder mir "In C". Es gibt in dem
> Artikel auch konkrete Beispiele, aber eben, als Beispiele, nicht als
> Definition.

Du hast ganz doll recht - so lange du nicht wieder von Aliasing in 
zusammenhang mit (Safe)Rust sprichst, weil es das dort nicht gibt

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> aber wir reden nicht von
> unsafe weil das der geringste Teil des Projektes sein sollte und niemals
> schlimmer ist als was man mit C machen kann

Genau. In der Praxis ist der allerkleinste Teil des Projekts unsafe. In 
den allermeisten meiner Projekte ist gar kein unsafe drin. Und das ist 
nicht nur bei mir so.

Wenn man allerdings unsafe-Rust-Code schreibt, dann ist das deutlich 
anspruchsvoller korrekt zu tun, als normales C zu schreiben. Vor allem 
wenn man so Dinge wie Pointer oder Transmutation verwendet oder bewusst 
gegen RAII verstößt.

Der Grund dafür ist, dass man alle Dinge beachten muss, die man in C 
auch beachten muss. Und zusätzlich muss man noch sicherstellen, dass die 
Rust-Safety-Garantien eingehalten werden. Und zwar auch im restlichen 
Safe-Code.
Unsafe-Codeabschnitte können Auswirkungen auf Safe-Code haben. Safe-Code 
darf nicht unsafe werden durch unsafe-Code.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

MaWin schrieb:
> 🐧 DPA 🐧 schrieb:
>> Was passiert mit Piloten, die immer nur den Autopiloten Fliegen lassen?
>> Sie verlernen es, selbst zu fliegen.
>
> Rust ist kein Autopilot.
> Rust ist ein permanenter Fluglehrer, der ständig neben dem Piloten sitzt
> und Pilotenfehler sofort korrigiert, bevor sie zu Flugfehlern führen.

Bei dem konkreten Flugzeugmodell, versteht sich. Da lernt er dieses 
spezifische Modell zu bedienen. Mehr aber auch nicht.

Und manchmal braucht man einen kleinen Crash, ein kleines Desaster, um 
wirklich zu verstehen, warum man tun muss was man tun muss.

cppbert schrieb:
> Du hast ganz doll recht - so lange du nicht wieder von Aliasing in
> zusammenhang mit (Safe)Rust sprichst, weil es das dort nicht gibt

Dann verstehst du das allgemeine Konzept selbst für sich genommen wohl 
noch nicht richtig.

von MaWin (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Bei dem konkreten Flugzeugmodell, versteht sich. Da lernt er dieses
> spezifische Modell zu bedienen. Mehr aber auch nicht.

Mit dem Erlernen von Rust habe ich mindestens soviel über C/C++ gelernt, 
wie über Rust. Und ich habe vorher über 20 Jahre C/C++ entwickelt.

von cppbert (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> cppbert schrieb:
>> Du hast ganz doll recht - so lange du nicht wieder von Aliasing in
>> zusammenhang mit (Safe)Rust sprichst, weil es das dort nicht gibt
>
> Dann verstehst du das allgemeine Konzept selbst für sich genommen wohl
> noch nicht richtig.

ich denke gut genug - da die Definitionen logisch und simpel sind 
verstehe ich nicht was daran überhaupt unverständlich sein soll

von cppbert (Gast)


Lesenswert?

cppbert schrieb:
> ich denke gut genug - da die Definitionen logisch und simpel sind
> verstehe ich nicht was daran überhaupt unverständlich sein soll

aber vielleicht helfen mir da meine geballten 30 Jahren C/C++, Assembler 
und Reverse-Engineering Erfahrung :)

von Thomas W. (goaty)


Lesenswert?

Mache gerade das Rust Buch durch (doc.rust-lang.org/book), und bis 
Kapitel 6 war es ja noch ok, aber jetzt wird´s schon etwas seltsam:
- enum kann jede Variante andere Daten halten, aber ich komm nicht mehr 
dran außer mit match.
- Match muß aber alle Varianten abdecken also gibt es "other =>" oder 
auch "_ =>" , naja ob das lesbarer wird?
- Damit man das nicht braucht gibts das "if let", das ist ja total 
abstrus. Let weist eigentlich einer Variable etwas zu, jetzt steht 
daneben ein "Pattern". Kann ich nicht mehr als lesbar bezeichnen...

von cppbert (Gast)


Lesenswert?

Thomas W. schrieb:
> Mache gerade das Rust Buch durch (doc.rust-lang.org/book), und bis
> Kapitel 6 war es ja noch ok, aber jetzt wird´s schon etwas seltsam:

enum ist ein Sum-Type - also ein Variant/Union Type
primär ist die Syntax dazu zu da die Mehrfägkeit zu bekommen ohne das 
auch mehr Probleme bei der Anwendung entstehen

bei Union darfst du nicht zwischen den Membern lesend/schreiben springen 
sonst UB und bei std::variant musst du entweder einen Visitor bauen oder 
casten - beides ist nicht schön

match vereint sicher die C++ enum und std::variant Features - auch wenn 
der Enum-Sumtype bei Rust aber eher aus dem OCaml Ursprung kommt

die meisten empfinden genau das Enum-Sumtype Feature als DAS Rust 
Feature was sie am meisten lieben - manche erst nach eine gewissen 
Warmwerdzeit

von cppbert (Gast)


Lesenswert?

und auch die "Patterns" sind der absolute Hammer - nicht das es nicht 
auch anders geht aber die eleganz das alles auf so wenig zu reduzieren 
finde ich schön

von cppbert (Gast)


Lesenswert?

wenn man viel mit C++ Tuples, Variants, Lambdas macht fühlt man sich 
gleich zuhause - auch wenn Rust gar nicht aus der Welt kommt

von cppbert (Gast)


Lesenswert?

Thomas W. schrieb:
> Mache gerade das Rust Buch durch (doc.rust-lang.org/book), und bis
> Kapitel 6 war es ja noch ok, aber jetzt wird´s schon etwas seltsam:
> - enum kann jede Variante andere Daten halten, aber ich komm nicht mehr
> dran außer mit match.
> - Match muß aber alle Varianten abdecken also gibt es "other =>" oder
> auch "_ =>" , naja ob das lesbarer wird?
> - Damit man das nicht braucht gibts das "if let", das ist ja total
> abstrus. Let weist eigentlich einer Variable etwas zu, jetzt steht
> daneben ein "Pattern". Kann ich nicht mehr als lesbar bezeichnen...

was du nicht vergessen darfst ist das das alle per default immutable ist 
- also in C++ gesagt "alles ist const" - das ist ein riesen Vorteil der 
Sprache und erzwigt implizit auch ein saubere, mehrheitliche 
State-freieres arbeiten

aber ich verstehe es wenn jemand nicht stark aus dieser const/state-less 
Welt kommt (am besten noch aus einer gar typelosen Welt) das diese 
ganzen Konzepte vereint schon sich schon ein wenig "unhandlich" 
anfühlen, weil man den Mehrwert wie implizite const-correctness 
vielleicht bisher gar nie genutzt hat oder das einem gänzlich fremd ist

wenn jemand z.B. viel mit Multithreading und C++ macht ist der Einstieg 
vergleichsweise einfacher weil Rust die sinnvollen Konzepte aus dem 
Bereich schon forciert

von DPA (Gast)


Lesenswert?

Ich mochte bei C, das man immer die Typen angeben musste. Da wusste man 
immer auf einen Blick, womit man es zu tun hat. Was ich auch noch etwas 
speziell finde, ist das man so Zeugs machen kann 'let x=1; let 
x="abc";', da muss man also auch noch die richtige finden. Ok, 
vermutlich helfen IDEs da einem weiter (wobei ich kein Fan von IDEs 
bin).

von cppbert (Gast)


Lesenswert?

DPA schrieb:
> Ich mochte bei C, das man immer die Typen angeben musste. Da
> wusste man
> immer auf einen Blick, womit man es zu tun hat. Was ich auch noch etwas
> speziell finde, ist das man so Zeugs machen kann 'let x=1; let
> x="abc";', da muss man also auch noch die richtige finden. Ok,
> vermutlich helfen IDEs da einem weiter (wobei ich kein Fan von IDEs
> bin).

da geben ich dir recht ist vergleichbar mit C++/Java/C# auto/var
sollte man wirklich nicht zu excessive nutzen sonst blickt man nichts 
mehr
es kommt aber ganz darauf an - in manchen stellen z.B. bei generischer 
Programmierung kanst du das teilweise einfach nicht - deswegen das 
Sprachfeature

aber ich finde es trotzdem gut das man

let x = 1;
let x: u32 = 1
let x = 1u32
let x: u32 = 1u32

schreiben kann - wenn man denn will

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


Lesenswert?

DPA schrieb:
> Ich mochte bei C, das man immer die Typen angeben musste.

Wenn ich mich recht erinnere, führt auch C gerade das 
"auto"-Schlüsselwort in der C++-Bedeutung ein … das kann manchmal ja 
auch sinnvoll sein. Oft genug sieht man sowas wie:
1
  foo *foop = (foo *)arg;

wo der Typ zweimal auftauchen muss. Da ist ein
1
  auto foop = (foo *)arg;

schneller überschaubar. Aber das kann schnell zu "obfuscation" führen, 
weil der Autor des Codes ja völlig klar wusste, welchen Typ die rechte 
Seite hat, nur jemand anders, der den Code lesen will, es erst auf die 
eine oder andere Art recherchieren muss.

cppbert schrieb:
> aber ich finde es trotzdem gut das man
> let x = 1;
> let x: u32 = 1
> let x = 1u32
> let x: u32 = 1u32
> schreiben kann - wenn man denn will

Sinnvoll benutzt ist das sicher nützlich.

von cppbert (Gast)


Lesenswert?

und das ist auch das coole und besondere an Rust

Die schaffen es die Basis Konzepte von fast allen System(und auch 
Hochs)sprachen unter einen Hut (Zero-Cost, Constness/Immuateable by 
default, Movesemantic by default, No-GC, No-Runtime) zu bringen und 
dennoch applikationsfreundlich zu bleiben

jeder andere Sprachenversuch hat bisher einen oder mehrere dieser 
Ansprüchen fallen lassen weil die es konzeptionell nicht in ein Design 
rein bekommen haben - das ist ein Novum

auch wenn ich wirklich verstehe das die meisten gar keine Ahnung von den 
obigen Basis-Konzepten haben und auch deren relevanz kaum bis gar nicht 
einschätzen können - in Bezug auf Sicherheit, Performanz und Generic 
(also eben nur wie in vielen Sprachen nur einen Aspekt davon)

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> da geben ich dir recht ist vergleichbar mit C++/Java/C# auto/var
> sollte man wirklich nicht zu excessive nutzen sonst blickt man nichts
> mehr

Ich finde es ist nicht vergleichbar mit C++, weil Rust die Typangabe 
durch den Programmierer auf Funktionsschnittstellen-, struct-, static- 
und const-var-Ebene forciert. Type inferrence findet nur innerhalb von 
Funktionen statt. (Lambdas sind eine optionale Ausnahme).

Wenn ein Typ vom Compiler hergeleitet wird, dann sieht man in der Regel 
die Quelle der Herleitung auf der gleichen Bildschirmseite.
Und wenn man das immer noch unübersichtlich findet, dann kann man jeder 
Variablen selbstverständlich auch einen expliziten Typen geben.

Bei der Herleitung passiert so gut wie nie etwas Unerwartetes in Rust.
Der Grund dafür ist das sehr strikte Typsystem.
Im Gegensatz zu C++. Da hat man implizite Konvertierungen und 
Promotionsregeln. Das macht es manchmal sehr schwer zu sagen, welchen 
Typ eine Variable wirklich hat.
Das ist in Rust anders.

Wenn man sehr generischen Code schreibt, dann kann es schon manchmal 
schwerer werden den Typ von Variablen zu erkennen. Aber auch das ist 
meist nicht schlimm. Denn wenn man diese Variable, oder einen davon 
errechneten Variable, dann aus der Funktion rückgibt oder in ein struct 
schreibt, dann bricht der Compiler durch fehlende implizite 
Konvertierungsmechanismen bei einem Typ-mismach an.

cppbert schrieb:
> in manchen stellen z.B. bei generischer
> Programmierung kanst du das teilweise einfach nicht - deswegen das
> Sprachfeature

Doch. Bei generischer Programmierung hat man in Rust immer einen 
generischen Typen. Den kann man dann auch angeben, wenn man möchte. Muss 
man aber eher selten.
Aber ich mache es schon manchmal. Vor allem, wenn ein impl mehrere 
generische Typen hat.

Ein generischer Typ ist nicht nur ein Platzhalter. Es ist ein Typ mit 
ganz klar definierten statisch festgelegten Eigenschaften.

Generische Typen sind, anders als in C++, in Rust stark constrained.
Man muss in Rust generische Typen mit der where-clause soweit 
einschränken, dass alle tatsächlich durchgeführten Operationen auf 
ebenjenen Typ abgedeckt sind. Wenn man das nicht macht, kann man 
überhaupt nichts mit dem Typ machen. Wenn man zwei Variablen generischen 
Typs addiert, dann muss dieser generische Typ im where-clause auf das 
Add-Trait eingeschränkt sein. d.h. der Typ kann nur einer sein, der auch 
tatsächlich exakt dieses Trait implementiert. Das wird alles schon bei 
der Implementierung der generischen Funktion festgezurrt. (In C++ wird 
das fast alles erst viel später bei der Instanziierung aufgelöst).
Bei der Instanziierung wird dann wiederum festgezurrt, dass der 
tatsächliche Typ auch tatsächlich alle geforderten Traits implementiert.
Ein generischer Typ monomorphiert immer bei der Instanziierung in genau 
einen konkreten tatsächlichen Typ.

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> cppbert schrieb:
>> da geben ich dir recht ist vergleichbar mit C++/Java/C# auto/var
>> sollte man wirklich nicht zu excessive nutzen sonst blickt man nichts
>> mehr
>
> Ich finde es ist nicht vergleichbar mit C++, weil Rust die Typangabe
> durch den Programmierer auf Funktionsschnittstellen-, struct-, static-
> und const-var-Ebene forciert. Type inferrence findet nur innerhalb von
> Funktionen statt. (Lambdas sind eine optionale Ausnahme).

ja sorry das vergesse ich immer - im Ergebnis verhält es sich ähnlich, 
aber es ist doch viel strikter

z.b. erzeugt auto nicht ungewillt Kopien - was bei C++ immer mal gern 
passiert oder häufig von Anfängern falsch gemacht wird - da Rust 
implizit moved und nur explizit kopiert kann das in Rust gar nicht 
passieren

> cppbert schrieb:
>> in manchen stellen z.B. bei generischer
>> Programmierung kanst du das teilweise einfach nicht - deswegen das
>> Sprachfeature
>
> Doch. Bei generischer Programmierung hat man in Rust immer einen
> generischen Typen. Den kann man dann auch angeben, wenn man möchte. Muss
> man aber eher selten.
> Aber ich mache es schon manchmal. Vor allem, wenn ein impl mehrere
> generische Typen hat.
>
> Ein generischer Typ ist nicht nur ein Platzhalter. Es ist ein Typ mit
> ganz klar definierten statisch festgelegten Eigenschaften.
>
> Generische Typen sind, anders als in C++, in Rust stark constrained.
> Man muss in Rust generische Typen mit der where-clause soweit
> einschränken, dass alle tatsächlich durchgeführten Operationen auf
> ebenjenen Typ abgedeckt sind.

ja sorry - ich meinte eher das du keinen expliziten "Basis"-Typ angeben 
kannst (oder es recht wenig sinn macht) - und ja die where clausen 
(vergleichbar mit C++ Konzepts) verhindern zwangsweise die typischen C++ 
Template-Error-Wolken

von MaWin (Gast)


Lesenswert?

Ein wichtiger weiterer Punkt, warum Type Inference in Rust viel besser 
nachvollziehbar ist, als in C++:
Es gibt keine Methoden- und Funktionsüberladungen und keine 
Klassenhierarchien.
Es ist viel einfacher nachzuvollziehen, was tatsächlich aufgerufen wird. 
Das klassische OOP-Problem, wo eine Methode 10 mal abgeleitet und auch 
noch 5 mal überladen ist, existiert in Rust nicht.

Es ist zwar manchmal nicht ganz auf den ersten Blick zu erkennen, zu 
welchem Trait ein Funktionsaufruf gehört. Aber in der Doku, die man mit 
Cargo aus jedem Stück Rust-Code generieren kann, wird dem Entwickler das 
dann gut und eindeutig erklärt. Dazu ist es nicht notwendig, dass jemand 
das manuell irgendwo dokumentiert.

Und wenn man dann immer noch nicht weiß, welchen Typ eine Variable hat, 
dann kann man den Rust-Compiler ganz einfach fragen:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2d69f5a260259c365c4e0ac0913eff0e

von Peter K. (Gast)


Lesenswert?

Als Fan von Pascal/Delphi und weniger von C, beobachte ich die 
Entwicklung auch mi Interesse.
Auch im Freepascal Forum gibt es dazu gerade eine Vergleichsdiskussion, 
ob und wie sich Rust von Pascal unterscheidet
https://forum.lazarus.freepascal.org/index.php/topic,54311.0.html

von cppbert (Gast)


Lesenswert?

Peter K. schrieb:
> Auch im Freepascal Forum gibt es dazu gerade eine Vergleichsdiskussion,

letzer Post vom "April 25, 2021, 09:56:15 AM" ist aber nicht so aktuell

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> Und wenn man dann immer noch nicht weiß, welchen Typ eine Variable hat,
> dann kann man den Rust-Compiler ganz einfach fragen:
>
> 
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2d69f5a260259c365c4e0ac0913eff0e

An so Informationen kommt man bei C++ auch nur mit kleinen Tricks :)
ich hoffe das Rust in dem Bereich sehr viel stärker aus den C++ Fehlern 
lernt und die Fähigkeiten generischer zu programmieren auch mit den 
entsprechenden Tools unterfüttert um das einfach/schnell 
wartbar/verständlich zu halten

von Kaj (Gast)


Lesenswert?

cppbert schrieb:
> An so Informationen kommt man bei C++ auch nur mit kleinen Tricks :)

Das macht bei Rust der rust-analyser. Der Zeigt bei jeder Variablen den 
Typ an. Gibt es als Plugin für VSCode.

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> ich hoffe das Rust in dem Bereich sehr viel stärker aus den C++ Fehlern
> lernt und die Fähigkeiten generischer zu programmieren auch mit den
> entsprechenden Tools unterfüttert um das einfach/schnell
> wartbar/verständlich zu halten

Ja also, ich sag mal so. Diesen Trick braucht man so gut wie nie. Aber 
wenn, dann ist es hilfreich zu wissen.

Generell ist der Rustcompiler sehr viel besser in der Fehlerausgabe als 
z.B. der g++.
Der Rustcompiler gibt bekannte Typinformationen zwar aus, aber überhäuft 
den Programmierer in der Regel nicht mit ellenlangen Typbeschreibungen 
(g++ ist da auch schon besser geworden).
In der Regel gibt der Rustcompiler sogar eine Vorschlag, was der 
Programmierer vermutlich meinte. Oft ist das sogar schon richtig oder 
fast richtig oder gibt einem wenigstens einen Schubs in die richtige 
Richtung.
Und dann hat jeder Compilerfehler auch noch eine eigene ID und einen 
Link auf eine manpage/website, wo der Fehler und seine möglichen Gründe 
noch einmal genauer und mit Beispielen beschrieben wird.

Vom Fehlerdiagnoseverhalten ist der Rustcompiler so ziemlich das Beste, 
was ich kenne.

von Ein T. (ein_typ)


Lesenswert?

MaWin schrieb:
> Generell ist der Rustcompiler sehr viel besser in der Fehlerausgabe als
> z.B. der g++.

Das ist jetzt aber auch keine allzu große Herausforderung... ;-)

von foo (Gast)


Lesenswert?

>keine allzu große Herausforderung

Der Rust Compiler umarmt einen und tröstet einen wenn man einen Fehler 
gemacht hat!
https://youtu.be/vcFBwt1nu2U?t=2223

von MaWin (Gast)


Lesenswert?

foo schrieb:
> Der Rust Compiler umarmt einen und tröstet einen wenn man einen Fehler
> gemacht hat!

:)

Nur mal so als Beispiel:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1c37c420e4f69cc62c6bf1272793321c

Ich wüsste jetzt nicht, wie man das noch verständlicher und besser 
machen könnte.

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


Lesenswert?

MaWin schrieb:
> Ich wüsste jetzt nicht, wie man das noch verständlicher und besser
> machen könnte.

Ich schon. ;-)

Der Unterstrich wird an vielen Stellen als Gruppierungszeichen genutzt 
(auch wenn C++ und nun C sich für den Apostroph entschieden haben).

Ich hätte daher sowas wie
1
  let c = i32: 42;

lesbarer gefunden, um den Typ einer Zahl zu benennen. (Ja, erinnert an 
Pascal. ;-)

Aber nur, weil du gefragt hast …

von Kaj (Gast)


Lesenswert?

Jörg W. schrieb:
> Ich hätte daher sowas wie
>   let c = i32: 42;
>
> lesbarer gefunden, um den Typ einer Zahl zu benennen.
So kann man es ja in Rust auch machen:
1
let c: i32 = 42;
2
let d = 42 as i32;

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Aber nur, weil du gefragt hast …

Leider wieder auf eine Frage geantwortet, die gar nicht gestellt wurde.
Es ging um die Fehlermeldungen.

von cppbert (Gast)


Lesenswert?

Jörg W. schrieb:
> Ich hätte daher sowas wie
>   let c = i32: 42;
>
> lesbarer gefunden, um den Typ einer Zahl zu benennen. (Ja, erinnert an
> Pascal. ;-)

Sorry aber das erinnert niemanden an Pascal weil der Typ bei Pascal doch 
immer rechts vom Doppelpunkt steht ;-)
Rust entspricht bis auf das "let" exakt der Pascal-schreibweise
1
Rust:
2
let c: i32 = 42;
3
4
Pascal:
5
    c: integer = 42;

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


Lesenswert?

Kaj schrieb:

> So kann man es ja in Rust auch machen:
>
1
> let c: i32 = 42;
2
> let d = 42 as i32;
3
>

Finde ich zumindest besser lesbar als die Unterstriche.

von cppbert (Gast)


Lesenswert?

Jörg W. schrieb:
> Finde ich zumindest besser lesbar als die Unterstriche.

meinst du das Beipspiel von MaWin mit

let _: () = x;

das ist ein Spezial-Sonder-Case den du selten in freier Wildbahn sehen 
wirst

von let (Gast)


Lesenswert?

Kaj schrieb:
> So kann man es ja in Rust auch machen:

Nicht zu vergessen:
1
let e = 42i32;

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Finde ich zumindest besser lesbar als die Unterstriche.
1
let a = 9_882_223_112;
2
let a = 9_882_223_112_i64;
3
let a = 9882223112_i64;
4
let a = 9882223112i64;
5
let a: i64 = 9882223112;
6
let a: i64 = 9_882_223_112;
7
//...usw...

Was davon jetzt besser lesbar ist, ist vollkommen dir überlassen. Du 
kannst alle Schreibweisen verwenden. Unterstriche können fast beliebig 
platziert und weggelassen werden.

von Kaj (Gast)


Lesenswert?

Jörg W. schrieb:
> Finde ich zumindest besser lesbar als die Unterstriche.
Bei Konstanten und globalen Variablen muss man es sogar so angeben:
1
const VAR: Type = value;
2
static var: Type = value;

von cppbert (Gast)


Lesenswert?

Kaj schrieb:
> Jörg W. schrieb:
>> Finde ich zumindest besser lesbar als die Unterstriche.
> Bei Konstanten und globalen Variablen muss man es sogar so angeben:const
> VAR: Type = value;
> static var: Type = value;

kann einer sagen warum "const x = 123i32" nicht genug ist?

von Cyblord -. (cyblord)


Lesenswert?

cppbert schrieb:
> kann einer sagen warum "const x = 123i32" nicht genug ist?

Weil geschwätzige Syntax wieder im Trend liegt?
Ich hätte auch nicht gedacht dass jemand nochmal ernsthaft das alte 
Basic-Style "let" aufwärmt. Aber hey, die Rustler kennen da nix.

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> kann einer sagen warum "const x = 123i32" nicht genug ist?

Weil man dann Type Inferrence bemühen müsste, was in einigen Fällen 
(nicht in diesem) interessante Probleme gibt. z.B. zyklische 
Typabhängigkeiten.

Es ist eine Designentscheidung, dass alle toplevel-APIs ohne Type 
Inferrence typisiert werden müssen.
Damit gewinnt man eine vollständige Kontextunabhängigkeit auf dieser 
Ebene.

In Rust ist es sehr wichtig, dass die Größe von Typen bekannt ist, oder 
dass bekannt ist, dass die Größe dynamisch ist. Unbekannte Größen sind 
ein Problem und müssen so schnell wie möglich vom Compiler aufgelöst 
werden.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Ich hätte auch nicht gedacht dass jemand nochmal ernsthaft das alte
> Basic-Style "let" aufwärmt. Aber hey, die Rustler kennen da nix.

Wie würdest du denn eine Variable mit Type Inferrence ohne let 
definieren und dabei auch zwischen Definition und Zuweisung 
unterscheiden? Mir fällt da spontan keine Möglichkeit ein, außer 
Keyword.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Wie würdest du denn eine Variable mit Type Inferrence ohne let
> definieren

Ich will schon gar keine Type Inference machen.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Ich will schon gar keine Type Inference machen.

Interessant. Eben sagtest du noch:

Cyblord -. schrieb:
> Weil geschwätzige Syntax wieder im Trend liegt?

Was denn nun? Lieber mehr oder lieber weniger tippen?

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> cppbert schrieb:
>> kann einer sagen warum "const x = 123i32" nicht genug ist?
>
> Weil geschwätzige Syntax wieder im Trend liegt?
> Ich hätte auch nicht gedacht dass jemand nochmal ernsthaft das alte
> Basic-Style "let" aufwärmt. Aber hey, die Rustler kennen da nix.

wann erklärst du jetzt wirklich mal endlich warum die Rust-Iteratoren 
ein No-Go für embedded sind?

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Was denn nun? Lieber mehr oder lieber weniger tippen?

Nur das NOTWENDIGE tippen. Und dazu gehört der Typ. Dazu gehört aber 
kein let und kein func.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Nur das NOTWENDIGE tippen.

Eben. Warum dann kein Type Inferrence?
1
let a: i32 = 1; // Typ wahrscheinlich nicht notwendig.
2
let b: i32 = 2; // Typ sicher nicht notwendig
3
let c: i32 = a + b; // Typ sicher nicht notwendig
4
//...

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> Nur das NOTWENDIGE tippen. Und dazu gehört der Typ. Dazu gehört aber
> kein let und kein func.

als wenn das bei Algorithmen-Entwicklung irgendeine relevanz hat, oder 
jemals gehabt hätte ausser in irgendeiner Wurstbude die auch {} bei if 
weglässt weil das so viel spart aber die halbe Manschaft kann nicht mal 
10-Finger schreiben :)

btw: du denkst noch an die Iteratoren und die No-Go Aufklärung?

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Dazu gehört aber kein let und kein func.

Da haben wir ja noch einmal Glück gehabt, denn 'func' gibt es in Rust 
nicht.

Btw: An der Aufklärung der Iteratorenfrage wäre ich auch noch sehr 
interessiert. Du scheinst da etwas zu wissen, was ich nicht weiß.

von MaWin (Gast)


Lesenswert?

Ein schöner Artikel über Rust und Standardisierung:

https://blog.m-ou.se/rust-standard/

> To better understand how to give a more useful definition, we first need to
> understand how Rust evolves. What “Rust” means changes regularly, as we are
> constantly working on improvements. Every six weeks, we release a new stable
> version of the compiler, each time changing what “Rust” means.

von MaWin (Gast)


Lesenswert?

> Announcing Rust 1.65.0

https://blog.rust-lang.org/2022/11/03/Rust-1.65.0.html

Dieses Mal mit einem Feuerwerk an neuen großen Features.

> Generic associated types (GATs)

Yay! Kann man nicht in ein paar Worten erklären :)

> let-else statements

Noch elegantere Fehler- und Sonderfallbehandlung.
let-else verringert die Verschachtelungstiefen massiv.

> break from labeled blocks

Verringert auch Schachteltiefen und erhöht die Lesbarkeit für 
Codeabläufe mit Abbruchbedingungen.

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
>> Generic associated types (GATs)
>
> Yay! Kann man nicht in ein paar Worten erklären :)

magst du es mal versuchen? am besten mit möglichem C++ Bezug

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> magst du es mal versuchen? am besten mit möglichem C++ Bezug

Einen C++-Bezug kann ich leider nicht bringen. Da kenne ich mich nicht 
gut genug mit C++ aus.

Grundsätzlich gesagt ist es eine relativ "einfache" (aus 
Programmierersicht) Erweiterung eines bestehenden Features.

Man kann in Rust Typen mit Traits assoziieren.
Was heißt das?
Das typische Beispiel, wie es auch im Announcement vorkommt, ist ein 
Iterator-Trait:
1
trait Iterator {
2
    type Item;
3
    fn next(&mut self) -> Option<Self::Item>;
4
}

Grob gesagt erreicht man damit, dass die Implementierung des Traits 
angeben kann, welcher Typ konkret verwendet werden soll (hier: Welchen 
konkreten Typ next() zurückgeben soll). Wenn man jetzt diesen Iterator 
für einen Typ implementiert, dann muss man den konkreten Typ der 
zurückgegebenen Elemente mit angeben. Somit weiß der Compiler bei der 
Verwendung dieses Iterators, welche konkreten Typen aus dem Iterator 
herausfallen. Im Trait selbst (in provided methods) kann man auch mit 
dem Typ arbeiten, allerdings nur auf abstrakter und nicht auf konkreter 
Ebene. (Man muss den Typ weiter einschränken mit Bounds).

Soweit so gut. Das alles gibt es schon sehr lange.

Nun ist neu, dass der assoziierte Typ auch generisch sein kann.
Das ist (IMO) hauptsächlich sinnvoll, wenn der assoziierte Typ eine 
Lifetimeangabe braucht. Lifetimes werden über den generic-Mechanismus 
gemacht. Das ist z.B. notwendig, wenn der Typ Referenzen einbettet.
Ohne GATs ist es nicht möglich dem assoziierten Typ eine Lebenszeit 
(außer `static) zu geben.
Damit waren bis jetzt associated Types auf owned-Typen beschränkt.

Mit GATs gibt es praktisch keine Beschränkung mehr.

von cppbert (Gast)


Lesenswert?

Es gibt noch ein bisschen Optimierungsbedarf mit der Stack-Nutzung

wird aber schon aktiv von Patrick Walton (Rust Entwickler bei Facebook) 
getrackt
1
The main goal is removing replacing pointless stack-to-stack copies with simply mutating in-place on the stack correctly in the first place.
2
Due to some mix of:
3
4
* Rust code relying more on copies than C++ (for esample, harder to make something uninitialized and fill it in)
5
* LLVM missing optimizations that rust relies on heavier than C++
6
* No real guarantees around RVO / NRVO

https://arewestackefficientyet.com/

https://news.ycombinator.com/item?id=33637092

von MaWin (Gast)


Lesenswert?

Und hier kommt auch schon der GAT fast-follower (in nightly):

async in Traits.

https://blog.rust-lang.org/inside-rust/2022/11/17/async-fn-in-trait-nightly.html


cppbert schrieb:
> Es gibt noch ein bisschen Optimierungsbedarf mit der Stack-Nutzung

Ja. Richtig. Haben wir hier ja auch schon besprochen.

Das ist aber tatsächlich weniger schlimm, als es sich erst anhört.

>Does this mean Rust is slower than C++?
> No. You can always write your Rust code carefully to avoid copies.
> Besides, all of this only comes out to a small percentage of the
> total instruction count.

Aber sicherlich ist es etwas, das behoben werden muss.

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> Aber sicherlich ist es etwas, das behoben werden muss.

also eher Potenzial als Problem :)

von rbx (Gast)


Lesenswert?

ach sch..
Jetzt habe ich Text zum Text von weiter oben kopiert..von zu weit oben?
1
Standard Error
2
   Compiling playground v0.0.1 (/playground)
3
error[E0308]: mismatched types
4
 --> src/main.rs:4:17
5
  |
6
4 |     let z = x + y;
7
  |                 ^ expected `i32`, found `i64`
8
9
error[E0277]: cannot add `i64` to `i32`
10
 --> src/main.rs:4:15
11
  |
12
4 |     let z = x + y;
13
  |               ^ no implementation for `i32 + i64`
14
  |
15
  = help: the trait `Add<i64>` is not implemented for `i32`
16
  = help: the following other types implement trait `Add<Rhs>`:
17
            <&'a f32 as Add<f32>>
18
            <&'a f64 as Add<f64>>
19
            <&'a i128 as Add<i128>>
20
            <&'a i16 as Add<i16>>
21
            <&'a i32 as Add<i32>>
22
            <&'a i64 as Add<i64>>
23
            <&'a i8 as Add<i8>>
24
            <&'a isize as Add<isize>>
25
          and 48 others
26
27
Some errors have detailed explanations: E0277, E0308.
28
For more information about an error, try `rustc --explain E0277`.
29
error: could not compile `playground` due to 2 previous errors

Wieso macht eigentlich der ghci aus 0xa + 0xb  21 ??

Und auf Assemblerebene kann man sehr wohl ganz gut 32 Bit mit 64 Bit 
addieren. Vor diesem Hintergrund fragt man sich, was wohl mit fehlender 
"Implementation" gemeint ist.

Ich würde jetzt auch nicht von Umarmung sprechen -  mich erinnert das 
Szenario eher an Veräppelung.

von MaWin (Gast)


Lesenswert?

rbx schrieb:
> Und auf Assemblerebene kann man sehr wohl ganz gut 32 Bit mit 64 Bit
> addieren.

Selbstverständlich.

Aber eben aus gutem Grund nicht im Rust-Typsystem.
Es zwingt dich explizit zu sein und eine Typumwandlung durchzuführen.
Und diese Entscheidung wie addiert werden soll, musst du natürlich auch 
in Asm treffen.
Soll i32 auf i64 aufgeblasen werden? Mit oder ohne sign extension? Soll 
auf i32 saturiert werden? Soll auf i32 abgeschnitten werden? All diese 
Fragen gilt es zu beantworten. Der Rust-Compiler rät das Ergebnis dieser 
Fragen nicht. Er fragt dich als Programmierer.

> Vor diesem Hintergrund fragt man sich, was wohl mit fehlender
> "Implementation" gemeint ist.

Es fehlt (ganz bewusst und gewollt) die Implementierung des 
Additions-Operators (Add-Trait) für i32 + i64.

rbx schrieb:
> Ich würde jetzt auch nicht von Umarmung sprechen -  mich erinnert das
> Szenario eher an Veräppelung.

Was genau ist denn an dieser Fehlermeldung nicht zu verstehen?

> error[E0308]: mismatched types
> error[E0277]: cannot add `i64` to `i32`

Alles was danach folgt ist nur eine weitere tiefergehende Erklärung, 
warum i32 und i64 nicht addiert werden können.

> Wieso macht eigentlich der ghci aus 0xa + 0xb  21 ??

Was ist ghci?
Warum soll 10 + 11 nicht 21 sein?

von cppbert (Gast)


Lesenswert?

rbx schrieb:
> Und auf Assemblerebene kann man sehr wohl ganz gut 32 Bit mit 64 Bit
> addieren.

nur explizit - die ganze implizite Auto-Casting und Integer-Promotion 
Verhalten verursacht viele latente Fehler die schwer zu finden sind
auch z.B. Pointer == int == bool ist relativ böse

Rust zwingt zur hygiene - und die ist wirklich nötig, auch wenn viele 
davon nie was mitbekommen - weil die meisten Kämpfe in der Standardlib 
oder 3rd-Parties passieren

höchstwahrscheinlich kompilieren die meisten C/C++ Projekte gar nicht 
mehr wenn man sign-unsiged-mismatch-Warning-als-Error im gcc aktivert :)

MaWin schrieb:
> Was ist ghci?

in einem rbx Post darf ein Haskell-Bezug nicht fehlen :)

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


Lesenswert?

cppbert schrieb:
> höchstwahrscheinlich kompilieren die meisten C/C++ Projekte gar nicht
> mehr wenn man sign-unsiged-mismatch-Warning-als-Error im gcc aktivert

It depends.

Seit die Warnung nun standardmäßig ein ist, dürfte das schon deutlich 
zur Verbesserung beigetragen haben. Ich habe schon viele Projekte 
gesehen, die eine zero-warning-policy fahren (kommerzielle wie 
Opensource).

von Cppbert (Gast)


Lesenswert?

Jörg W. schrieb:
> cppbert schrieb:
>
>> höchstwahrscheinlich kompilieren die meisten C/C++ Projekte gar nicht
>> mehr wenn man sign-unsiged-mismatch-Warning-als-Error im gcc aktivert
>
> It depends.
> Seit die Warnung nun standardmäßig ein ist, dürfte das schon deutlich
> zur Verbesserung beigetragen haben. Ich habe schon viele Projekte
> gesehen, die eine zero-warning-policy fahren (kommerzielle wie
> Opensource).

Die Top Projekte schon aber dann wird die Luft schnell dünn

genauso wie ASAN,TSAN Nutzung und statische Codeanalyse, ich treffe 
immer wieder auf Fehler wegen fehlendem Tooleinsatz und Warninglevel

von Cppbert (Gast)


Lesenswert?

Beispiel: ASAN build von Qt 6.4 und Glib findet sofort eine 
Stackoverflow, faellt aber nur auf wenn man auch die GLib mit ASAN baut, 
TSAN Tests werden bei denen auch nicht über den CI-Server gemacht weil 
zu viel Aufwand/ Belastung für den Server

von rbx (Gast)


Lesenswert?

MaWin schrieb:
> Was ist ghci?

Würde ich sagen Glasgow Haskell Compiler Interpreter.

MaWin schrieb:
> Warum soll 10 + 11 nicht 21 sein?

Weil 0xa + 0xb nunmal 0x15 sind. Außerdem nicht mehr 4 Bit, sondern 
jetzt 8. Das ist alles viel Interpretationssache, z.B. auch, weil die 
Zahlen ab 8000 bei 16 Bit immer negativ sind - sofern man das braucht.

Wenn man schon eine Art künstlichen Prozessor programmiert, der viele 
mögliche Operationen mit Datentypen macht, dann sollte der auch 32Bit 
mit 64 Bit addieren können. Am Ende ist eher die Frage, wo speichere ich 
das Ergebnis?
Dann bräuchte man also nur einen Typen für 32Bit + 64Bit Additionen 
konstruieren, der selbstverständlich mindestens 64Bit hat.
Besser wäre natürlich eine noch größere Bitbreite, das ja auch 64 Bit 
bereits auf FFFF (überall) stehen kann. Da könnte man dann nur noch, bei 
64 Bit - falls überhaupt - ein Bool addieren.

Man kann sich ein Vorbild an der Kompatibilität der Hardware nehmen - 
und muss nicht alles ins absurdum führen, weil die Transparenz in 
Assembler eher unbekannt ist.

Bei so Diskussionen rund um Loop-Automatismen auf YT weiß ich jedenfalls 
eher nicht, ob ich nun lachen soll, oder weinen muss.

Das ist übrigens auch etwas (Loopautomatismen usw.) was bei Haskell 
anstößig ist. Da heißt es dann: das sieht aber furchtbar aus, da 
programmiere ich doch lieber C++.
Ich selber finde schon die vielen Möglichkeiten, die man in (PC) 
Assembler hat , etwas unübersichtlich.
Aber um sich einen Überblick zu verschaffen, muss man eben eine Liste 
machen, herumprobieren, Sourcecodes lesen oder Bücher zur 
Programmierkunst in Asm.
Das geht alles ganz gut ohne YT.
Das gleiche gilt für Loop-Automatismen in Haskell und wird für Rust auch 
nicht anders sein.

von MaWin (Gast)


Lesenswert?

rbx schrieb:
> Wenn man schon eine Art künstlichen Prozessor programmiert, der viele
> mögliche Operationen mit Datentypen macht, dann sollte der auch 32Bit
> mit 64 Bit addieren können.

Nein. Wozu? Was würde das bringen?
Es ist viel einfacher und auch für die Programmiererin viel eindeutiger, 
wenn sie die Konvertierung explizit macht. Sie muss sich keine 1000 
Regeln merken. Alles steht explizit im Code.
1
let c = a as i64 + b;

Ich sehe das Problem nicht.
Rust bietet mit 'as' und 'into' sehr mächtige und bequeme 
Konvertierungstools.

> Am Ende ist eher die Frage, wo speichere ich das Ergebnis?

Die Fragen sind viel mehr die, die ich bereits oben formuliert habe. Wo 
es dann gespeichert wird, ergibt sich daraus (Type inference).

> Dann bräuchte man also nur einen Typen für 32Bit + 64Bit Additionen
> konstruieren, der selbstverständlich mindestens 64Bit hat.

Ach. Das ist selbstverständlich? Für mich nicht. Ich würde das als 
Programmierer gerne von Fall zu Fall entscheiden.

> Besser wäre natürlich eine noch größere Bitbreite

Die bietet Rust.

> Man kann sich ein Vorbild an der Kompatibilität der Hardware nehmen

Man kann es auch sein lassen.
Nicht einmal das Maschinenmodell von C stimmt mit irgendeiner realen 
Hardware auch nur annähernd überein.

> Assembler

Ich weiß ja nicht, was du ständig mit Assembly hast. Aber es ist 
offtopic. Assembly hat überhaupt kein Typsystem. Es ist somit gar nicht 
vergleichbar mit irgendeiner Hochsprache.

Rust definiert sich durch sein Typsystem.

> Bei so Diskussionen rund um Loop-Automatismen auf YT

Was sind "Loop-Automatismen"?

von Yalu X. (yalu) (Moderator)


Lesenswert?

rbx schrieb:
> Wieso macht eigentlich der ghci aus 0xa + 0xb  21 ??

rbx schrieb:
> MaWin schrieb:
>> Warum soll 10 + 11 nicht 21 sein?
>
> Weil 0xa + 0xb nunmal 0x15 sind.

Und wo liegt das deiner Ansicht nach der Widerspruch?

Fragen wir doch einfach mal ghci, was der dazu meint:
1
ghci> compare 21 0x15
2
EQ

Um ganz sicher zu gehen, machen wir auch noch die Gegenprobe:
1
ghci> 21 == 0x15
2
True

Aber nicht nur in Haskell, sondern auch in Rust, C, C++, Java und Python
ist 0x15 = 21. Somit entspricht das Verhalten von Haskell dem Prinzip
der geringsten Überraschung, weswegen ich nicht verstehe, was daran
schlecht sein soll.

von cppbert (Gast)


Lesenswert?

Yalu X. schrieb:
> Somit entspricht das Verhalten von Haskell dem Prinzip
> der geringsten Überraschung, weswegen ich nicht verstehe, was daran
> schlecht sein soll.

Integer Promotion in jeder Form ist ein möglicher Fehler - in Normalfall
braucht man das sehr selten, weil man ja normalerweise nicht sinnlos 
int32 und int64 in seinem Code mischt - oder es ist eben Schluri-Code

wenn du Kernel-Code schreibst musst du dir definitiv sicher sein das es 
funktioniert und auch prüfen sonst gibt es Probleme - Rust forciert 
schon mal das du solche Stellen immer deutlich im Code siehst auch wenn 
es nur der Cast ist und sie nicht wie bei C und C++ nur mit Warnungen 
belegt werden

Aber das ist auch eine Erfahrungs-Sache - oft neigen die unerfahrenen 
eher zur einfachen aber schwächeren Schreibweisen weil die eben "so 
schön einfach sind" - aber die Konsequenzen die sich aus vielen solchen 
kleinen Sachen ergeben überblicken diese Entwickler meistens überhaupt 
nicht - und das lässt
sich eben auch schlecht erklären - weil es immer einen "Maier Müller" 
gibt der "damit" noch keine Probleme hatte

genau so könnten wir darüber diskutieren warum Java keinen 
unsigned-Typen hat - weils dann eben so schön einfach ist, das Ende vom 
Lied: es ist ein riesen Scheiss wenn man System-Programmierung macht

von rbx (Gast)


Lesenswert?

MaWin schrieb:
> Assembly hat überhaupt kein Typsystem.

Das stimmt nicht. Und wenn man weniger abstrahiert, kann man beim PC AVX 
zum Addieren einsetzen, oder andere logische Operationen.
Blöd ist halt der Zugriff auf AVX. Aber logische Operationen mit 256 Bit 
sind schon sehr nett, wenn man weiß, wie man sowas nutzt.

https://www.intel.com/content/dam/develop/external/us/en/documents/36945

https://stackoverflow.com/questions/42938907/is-it-possible-to-use-simd-instructions-in-rust

Der Visual Studio Debugger war ja auch super, oder damals der 
Tasm-Debugger.
Wäre schön, wenn es sowas (oder vergleichbares) mal von diesen 
Funktional Programmiersprachen-Helden gäbe.

http://wiki.haskell.org/Research_papers/Parallelism_and_concurrency

Die Referenzen sind teilweise ganz gut, aber mittlerweile ziemlich alt.

Bei Haskell (ja, schon wieder..) muss man auch wissen, dass der Datentyp 
Double auf Performance getrimmt ist. So ähnlich wie früher Addieren mit 
AX. Oft gab es nur dieses eine Register.

Rust IDE wird wohl die gleiche sein, wie schon für Haskell:

https://github.com/rust-lang/rust-mode

von cppbert (Gast)


Lesenswert?

rbx schrieb:
> MaWin schrieb:
>> Assembly hat überhaupt kein Typsystem.
>
> Das stimmt nicht. Und wenn man weniger abstrahiert, kann man beim PC AVX
> zum Addieren einsetzen

bedeutet nicht das Assembler ein Typsystem hat - das man als solches 
Bezeichnen kann

btw: du Off-Topicst wieder in jede Richtung gleichzetig, SIMD, IDEs, 
AVX...

von rbx (Gast)


Lesenswert?

cppbert schrieb:
> btw: du Off-Topicst wieder in jede Richtung gleichzetig, SIMD, IDEs,
> AVX...

Sehe ich nicht als offtopic. Rust ist ja gerade gut für sowas, Haskell 
eben auch, was man damaliger tiefschürfender Literatur entnehmen konnte.

Ja gut, und rekursive Typen, oder Typen mit Baumstrukturen usw. sind in 
Asm jetzt nicht typisch, allerdings brauchen solche Typsysteme auch eine 
ganze Weile an Nachdenken und Üben, bevor sie Spaß machen.

Andererseits sind bei Asm die "Datentypen" eher die des Prozessors - so 
gesehen stimmt das dann doch, dass es in Asm keine Typen gibt.
Eher gibt es Programmiertypen ;)

von MaWin (Gast)


Lesenswert?

rbx schrieb:
> Sehe ich nicht als offtopic.

Es ist vollkommen Offtopic und dein Geschreibsel über Asm+Typen ist 
riesiger Unsinn. Deshalb kommentiere ich das jetzt auch nicht im Detail.
Du solltest dich dringend einmal in das Thema Typtheorie von Sprachen 
in der Informatik einlesen.

von cppbert (Gast)


Lesenswert?

Deine Post haben manchmal diesen komischen "Ich find das irgendwie 
interessant hab aber keine Ahnung davon"-Stil

und wie ich schon sagte - Parallelsierung, Vektorisierung und auch AVX 
sind völlige Daily-Business-Einsatzwerkzeuge in der C/C++ 
Software-Entwicklung wenn man nicht gerade Micro-Kontroller oder nur 
Datenbanken programmiert - du schreibst darüber als wenn das was 
neues/besonderes wäre - Rust macht das ganze nur sicherer - genutzt wird 
das alles permanent seit Jahren, von sehr vielen Entwicklern

von MaWin (Gast)


Lesenswert?

Memory Safe Languages in Android 13

https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

> Looking at vulnerabilities reported in the Android security bulletin,
> which includes critical/high severity vulnerabilities reported through
> our vulnerability rewards program (VRP) and vulnerabilities reported
> internally, we see that the number of memory safety vulnerabilities
> have dropped considerably over the past few years/releases.
> From 2019 to 2022 the annual number of memory safety vulnerabilities
> dropped from 223 down to 85.

> In Android 13, about 21% of all new native code (C/C++/Rust) is in Rust.
> There are approximately 1.5 million total lines of Rust code in AOSP

> To date, there have been zero memory safety vulnerabilities discovered
> in Android’s Rust code.

von Kaj (Gast)


Lesenswert?


von Yalu X. (yalu) (Moderator)


Lesenswert?

Kaj schrieb:
> Asahi Linux: Rust-Magie macht Linux-Treiber für Apple-GPU möglich
> 
https://www.golem.de/news/asahi-linux-rust-magie-macht-linux-treiber-fuer-apple-gpu-moeglich-2211-170130.html

Man fragt sich nur, wie Apple selbst den Treiber ohne Rust hinbekommen
hat. Oder ist der Treiber mangels Rust-Magie so hingemurkst und verbugt,
dass er alle fünf Minuten abstürzt? Ich habe keinen Apple, deswegen kann
ich das nicht nachprüfen ;-)

von Kaj (Gast)


Lesenswert?

Yalu X. schrieb:
> Man fragt sich nur, wie Apple selbst den Treiber ohne Rust hinbekommen
> hat.

Es ist in C ja nicht unmöglich, nur besonders aufwändig und 
fehleranfällig.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Kaj schrieb:
> Es ist in C ja nicht unmöglich,

Der Titel des verlinkten Artikels "Rust-Magie macht Linux-Treiber für
Apple-GPU möglich" impliziert das aber fast :)

> nur besonders aufwändig und fehleranfällig.

Deswegen meine obige Frage:

Yalu X. schrieb:
> Oder ist der Treiber mangels Rust-Magie so hingemurkst und verbugt,
> dass er alle fünf Minuten abstürzt?

Das die meisten Apple-User mit ihrem Rechner sehr zufrieden zu sein
scheinen, gehe ich davon aus, dass sich die Fehleranfälligkeit in
akzeptablen Grenzen hält.

von rbx (Gast)


Lesenswert?

Yalu X. schrieb:
> Das die meisten Apple-User mit ihrem Rechner sehr zufrieden zu sein
> scheinen, gehe ich davon aus, dass sich die Fehleranfälligkeit in
> akzeptablen Grenzen hält.

Ich habe festgestellt, dass ich doch lieber Diablo2 auf meiner Windows 8 
Kiste spiele, als mich bei Linux darüber zu ärgern, dass der Maustreiber 
bzw. die Maussteuerung bei Baldurs Gate2 total verkackt.
Interessanterweise gab es bei Open Solaris ganz gute Maus bzw. auch 
Touchpad-Treiber bzw. -Steuerung. Das war etwas untypisch (für Unixe). 
Wie konnte das sein?
Schwierig war dann aber auch noch den Rechner ohne Konsole 
herunterfahren - oder die automatische Hardwareerkennung, die beim 
Internetmodul versagte. ausgerechnet da..

Vor dem Hintergrund der Parallelfreundlichkeit von Rust kann man schon 
sagen, Rust wird bleiben.
Der pragmatische Backround erinnert an JavaScript - ja und auch wenn 
JavaScript gewöhnungsbedürftig ist - es hatte einen ganz guten Weg 
gemacht - oder nicht?
Diablo2 ist eines der besten Computerspiele überhaupt, von richtig guten 
Leuten programmiert. Das Spielmanagement bzw. auch Modding lief über 
JavaScript.
Und das schon kurz nach der Jahrtausendwende, als JavaScript noch in 
Kinderschuhen herumlief.
Hätte damals einer gefragt: Wird JavaScript bleiben? Ich hätte meine 
Zweifel gehabt (aber unterm Strich nicht wirklich widersprochen) - die 
hervorragenden Programmierer hatten den pragmatischen Weg gewählt.

von MaWin (Gast)


Lesenswert?

rbx schrieb:
> ...

Nimm bitte weniger davon.
Oder mehr.
Jedenfalls stimmt die Menge nicht. Das ist klar.

von cppbert (Gast)


Lesenswert?

rbx schrieb:
> pragmatische Backround erinnert an JavaScript

Neben den Assoziations-Chaos-Sätzen die ungebremst aus deinem Gehirn 
schwallen ist dein Javascript-Bezug echt das lustiges was du bisher 
geschrieben hast :)

Außerdem bekommst du einen Bonuspunkt für einen haskellfreien Post

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


Lesenswert?

cppbert schrieb:
> ist dein Javascript-Bezug echt das lustiges was du bisher geschrieben
> hast

Der hat mich auch amüsiert.

Im deutschen Wikipedia stand auch lange Zeit drin, dass Python eine 
Verwandtschaft mit der esoterischen Programmiersprache "Whitespace" hat, 
weil die Einrückungen syntaktische Relevanz haben. ;-) Hat allerdings 
inzwischen jemand heraus editiert.

von rbx (Gast)


Lesenswert?

MaWin schrieb:
> Nimm bitte weniger davon.
> Oder mehr.

Wie denn jetzt? Als das anfing mit JS, da hatte ich gemeint, das wäre 
für nette Website-Gimmicks gut - aber sonst?

Punkt 1: begabte Programmierer (spricht für Rust)

Nun kam JS mit der Webentwicklung und wird zum Teil auch von der 
getragen. Was hat Rust als Starthilfe?

Punkt 2: es gibt viele lästige Treiberprobleme in der Linux-Unix-World. 
(spricht für Rust)

Grafik und Spiele ist dabei ein wichtiges Thema. Updates und Upgrades 
nicht immer unproblematisch.

Punkt 3: mehr Spielspaß willkommen (spricht für Rust)

von cppbert (Gast)


Lesenswert?

rbx schrieb:
> Wie denn jetzt? Als das anfing mit JS, da hatte ich gemeint, das wäre
> für nette Website-Gimmicks gut - aber sonst?
>
> Punkt 1: begabte Programmierer (spricht für Rust)
>
> Nun kam JS mit der Webentwicklung und wird zum Teil auch von der
> getragen. Was hat Rust als Starthilfe?

Javascript hat einen völligen anderen Anwendungsbereich und ganz andere 
Ziele als Rust, eine interpretierte, garbage-collectorte und typenlose 
Sprache mit Rust zu vergleichen ist wie als wenn du sagt Chinesisch ist 
wie Englisch, und für was braucht Rust Starthilfe? Diablo war auch keine 
Starthilfe für Javascript - btw wünschen sich die meisten den schnellen 
Tod von Javascript, selbst der Schöpfer - falls dir das engangen ist

> Punkt 2: es gibt viele lästige Treiberprobleme in der Linux-Unix-World.
> (spricht für Rust)

Rust ist kein Heilmittel gegen schlecht gewarteten oder supporteten Code 
- es ist nur schwerer ganz blöde Fehler zu machen, ob der Rust 
Entwickler dann mit seinem Code Maus richtig supported ist was völlig 
anderes und bei Solaris war dann wohl das Fehlermanagement und 
Issue-Tracking besser - absolut gar keinen Bezug zu Rust

>
> Grafik und Spiele ist dabei ein wichtiges Thema. Updates und Upgrades
> nicht immer unproblematisch.
>
> Punkt 3: mehr Spielspaß willkommen (spricht für Rust)

Updates und Upgrades werden durch Rust nicht leichter oder einfacher - 
wie kommst du auf sowas? genau so wirr wie dein 
Parallelitäts-Geschreibsel

ganz wichtig: entweder merkst du wirklich nicht was für komische 
Statements du hier abgibst oder du bist ein brillianter Troll

von Rolf M. (rmagnus)


Lesenswert?

cppbert schrieb:
> btw wünschen sich die meisten den schnellen Tod von Javascript, selbst
> der Schöpfer - falls dir das engangen ist

Heute gibt's ja auch WebAssembly. Dafür kann man in allen möglichen 
Sprachen (auch C und Rust) Code erzeugen, der dann direkt so im Browser 
läuft.

von Daniel A. (daniel-a)


Lesenswert?

Ich kann WebAssembly leider noch nicht verwenden. Der Grund ist recht 
simpel: Ich brauche memory mapping. Momentan gibt es in WebAssembly nur 
einen Memory pro Programm. Sachen wie der Ringbuffer Trick, Speicher 
zwischen Prozessen hin und her schieben, etc. kann man damit also 
vergessen, ausser man will die ganze zeit massenhavt Daten kopieren...
Und für multi threading wäre es auch nützlich, da braucht man nämlich 
mehrere web worker mit einem shared memory.

Ich denke, wenn das da wäre, hätte man alles was es braucht, alle 
beliebige Programme unverändert nach WebAssembly übersetzen zu können. 
Es wäre echt cool, wenn man z.B. gleich ein Debian port für WebAssembly 
haben könnte, man stelle sich das mal vor, man könnte einfach so, 
libreoffice, mpv, krita, gnome-games, etc. im Browser einbinden.

Es fehlt so wenig! Es gibt auch schon ein Entwurf 
(https://github.com/WebAssembly/multi-memory). So nah dran! Aber ich 
fürchte, auch Jahre Später implementiert das noch keiner... 
(https://webassembly.org/roadmap/#table-row-multimemory)

von A. B. (funky)


Lesenswert?

Kann für Rust jemadn ein gutes Einstiegsbuch empfehlen? Oder ändert sich 
da eh noch alle Nase was und das macht keinen Sinn bzw. es gibt nichts 
was sich lohnt zu lesen?
Ein komprimierter Einstieg würde mich schonmal interessieren

von Kaj (Gast)


Lesenswert?


von rust (Gast)


Lesenswert?


von MaWin (Gast)


Lesenswert?

Jetzt dürft ihr "denen" mal eure Meinung geigen:

https://blog.rust-lang.org/2022/12/05/survey-launch.html

von Dergute W. (derguteweka)


Lesenswert?

<heisemode>
Juhuu, das ist das Ende von Rust!!1!einself!
https://www.n-tv.de/politik/Horst-Seehofer-lernt-C--article23766893.html
</heisemode>

scnr,
WK

von MaWin (Gast)


Lesenswert?

Dergute W. schrieb:
> https://www.n-tv.de/politik/Horst-Seehofer-lernt-C--article23766893.html

Ach du meine Güte.
Seehofer lernt C++.

Noch eindeutigere Beweise dafür, dass C++ vom alten Eisen ist und am 
Ende seiner Lebenszeit angelangt ist, werden nicht mehr benötigt. ;)

von rbx (Gast)


Lesenswert?

MaWin schrieb:
> dass C++ vom alten Eisen ist

C++ kann ich tatsächlich auf meiner Windows ME Kiste nutzen (cygwin, 
OpenWatcom), Haskell-Plattform wollte nicht (nur Hugs) und nun frag mal 
dreimal, was da wohl mit Rust geht.

Oder gibt es eine nette Rust-Ide für FreeDOS?
Oder wenigstens was für Cygwin? Python ist schon vorgegangen, und wurde 
willkommen geheißen. Nur ist das schon lange her.
Übersetzungsanleitung vielleicht für flat assembler?

Rust ist tatsächlich noch viel zu Linuxoid, und dann auch noch recht 
Windows/DOS unfreundlich. Das war Haskell nicht, wenn auch in viele 
Fettnäpfchen getreten oder kaum nutzbar da. DOS? Scheinbar nie gehört.
Aber Windows ist bei vielen schon vorinstalliert - und dann sind wir 
auch schon bei der "Community":

Die gab es bei OpenWatcom auch, hatte sich aber nicht lange gehalten.
Modula 3 war auch so ein linuxoides Ding wo ist Modula 3 jetzt?

Die Linuxuidität und die Windows/DOS-Unfreundlichkeit geht nach -> 
Nischenprodukt.

Webassembly dagegen wirkt nicht so problematisch, weder von der 
Zugangsseite, noch von der Nutzerseite..
https://www.reddit.com/r/WebAssembly/comments/z8jyjk/super_nintendo_emulators_online_running_on_wasm/

Basic war damals überall zu finden, und in den Volkshochschulen gab es 
Programmierkurse zu verschiedenen Programmiersprachen.
In den Schulen wurden noch lange Basic-Programmierkurse gelehrt. An den 
Unis teilweise (und fragwürdigerweise) mit Java abgelöst. War Java jetzt 
besser als Basic?
Auf jeden Fall wurden beide Sprachen bis in die kleinste Ecke 
hineingepusht.

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


Lesenswert?

rbx schrieb:
> DOS?

Naja, ehrlich, wer will sich heutzutage noch mit dem abscheulichen "real 
mode" eine 8086 herumschlagen?

Ansonsten kann ich mir nicht vorstellen, dass das soooo 
Windows-untauglich ist, denn schließlich ist inzwischen im Firefox einen 
nennenswerter Anteil an Rust, und da es Firefox für Windows gibt, muss 
er sich ja irgendwie dafür compilieren lassen haben …

von rbx (Gast)


Lesenswert?

Jörg W. schrieb:
> Ansonsten kann ich mir nicht vorstellen, dass das soooo
> Windows-untauglich ist,

Glaube ich jetzt auch nicht, aber warte mal..
1
Rust Visual C++ prerequisites
2
3
Rust requires a linker and Windows API
4
available.
5
6
These components can be acquired throug
7
8
1) Quick install via the Visual Studio
9
   (free for individuals, academic uses
10
11
2) Manually install the prerequisites
12
   (for enterprise and advanced users).
13
14
3) Don't install the prerequisites
15
   (if you're targetting the GNU ABI).

Quick install von VS?
Das ging schon immer schnell, und braucht auch nur ganz wenig 
Speicherplatz ;)

Naja, im Ernst, die sollten erstmal zusehen, dass sie was auf FreeDOS 
hinbekommen - eventuell ersparen die sich die eine oder andere 
Speichermacke/Ignoranz/Arroganz, whatever, und wäre das nicht zu hoffen? 
Und warum jetzt nicht was für Tiny C?

Ich bleibe bei Nischenprodukt, und denke an Modula 3 - trotz der guten 
Vorraussetzungen (s.o.).

von MaWin (Gast)


Lesenswert?

Wieso werden offensichtliche Trolls wie rbx hier nicht gelöscht?

von MaWin (Gast)


Lesenswert?

Vielleicht ist das hier ja etwas, für die ganzen Leute, die (noch) nicht 
von ihrer C++-Droge weg kommen (wollen oder können).

https://www.youtube.com/watch?v=ELeZAKCN4tY

Es ist ein sehr interessanter Vortrag darüber, wie man C++ sicherer (by 
default) machen könnte.

Das hat jetzt zwar nicht direkt etwas mit Rust zu tun, aber das Ergebnis 
sieht schon sehr Rust-ähnlich aus. In dieser hier C++2 genannten neuen 
Sprache sind viele Defaults so eingestellt, wie sie in Rust auch zu 
finden sind.

Natürlich ist es bei weitem nicht so safe wie Rust, aber es wäre eine 
deutliche Verbesserung des völlig kaputten C++-Zustands, mit dem wir 
heute leben müssen.

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


Lesenswert?

MaWin schrieb:
> Natürlich ist es bei weitem nicht so safe wie Rust, aber es wäre eine
> deutliche Verbesserung des völlig kaputten C++-Zustands, mit dem wir
> heute leben müssen.

Nur, wer braucht das? Wer etwas anders machen will, kann doch Rust 
nehmen (oder Python oder …).

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Nur, wer braucht das? Wer etwas anders machen will, kann doch Rust
> nehmen (oder Python oder …).

Wie wäre es, wenn du dir das Video einmal anschaust, bevor du hier 
privilegiert trollst?

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


Lesenswert?

Du hast die Frage nicht beantwortet.

Aber willst du offenbar nicht. Da empfiehlt man nun schon mal, dass die 
Leute stattdessen doch lieber gleich was anderes machen sollten, isses 
dir auch nicht recht.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Du hast die Frage nicht beantwortet.

Wer diese Frage stellt, hat das Video nicht gesehen.
Das ist offensichtlich.

> Aber willst du offenbar nicht.

Genau. Wozu auch? Die Frage hat gar nichts mit Rust oder dem Video zu 
tun.

> Da empfiehlt man nun schon mal, dass die
> Leute stattdessen doch lieber gleich was anderes machen sollten, isses
> dir auch nicht recht.

Ach. Du bist ja so großzügig.
Du bist so ein großzügiger Troll, der hier nur nicht gelöscht wird, weil 
er Moderator ist.

Soll ich dir mal was sagen? Hm?
Gucke doch das Video. Wie wäre das?
Dann weißt du auch, worum es geht, und dann musst du dich hier nicht 
immer weiter bis auf die Knochen blamieren.

Peinlich, peinlich.

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


Lesenswert?

MaWin schrieb:
> Gucke doch das Video.

Die 1,5 h Zeit würde ich, wenn schon, lieber in Rust investieren.

Aber solange du einfach nur bei persönlichen Beschimpfungen bleiben 
willst, was soll's?

: Bearbeitet durch Moderator
von cppbert (Gast)


Lesenswert?

@Jörg W.

wenn es um C++2 geht - dann geht es eher darum das der Wechsel zwischen 
C++ und C++2 so absolut leicht und einfach sein soll wie möglich d.h. am 
besten 100% kompatibel - damit Firmen wie Microsft oder google die 
Mio/Mrd Zeilen von C++ haben leichter zwischen den Welten wandeln können 
ohne die geringsten Problem mit Kompiler/Toolchain etc. - bei solchen 
Codemengen, die ja täglich extrem wachsen sind auch mehrstufige 
Migrationen Richtung einfacher/fehlerfreier interessant

die Leute müssen sich einfach mal die Dimensionen vorstellen: wenn 2000 
oder mehr Entwickler an einem Codeberg arbeiten kann man teilweise im 
Sekundentakt die Repos wachsen sehen - das ist manchmal ganz schön 
beängstigen

@MaWin:

eine einfach kurze Antwort hätte gereicht - nicht jeder hier ist ein 
Troll und nicht alle sind einfach nur faul

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


Lesenswert?

cppbert schrieb:
> wenn es um C++2 geht - dann geht es eher darum das der Wechsel zwischen
> C++ und C++2 so absolut leicht und einfach sein soll wie möglich d.h. am
> besten 100% kompatibel

Das ist mir durchaus beim Ansehen des Videos (und der ja teils 
euphorischen Kommentare) klar geworden. Ich fürchte trotzdem, dass das 
nicht viel bringt, und dass es sinnvoller ist, es so wie Firefox zu 
machen und stückweise Subsysteme neu zu implementieren.

Dass das nicht von heute auf morgen gemacht ist, sieht man natürlich 
auch an Fifrefox.

von cppbert (Gast)


Lesenswert?

Jörg W. schrieb:
> Ich fürchte trotzdem, dass das
> nicht viel bringt, und dass es sinnvoller ist, es so wie Firefox zu
> machen und stückweise Subsysteme neu zu implementieren.

ja das Herb Sutter Beispiel ist ja nur ein Aufrüttler - was wäre wenn 
C++ sowas wie die Rust Editions hätte - was wäre möglich - Herb muss ja 
immer der am-weitesten-über-den-Tellerrand-schauer sein

aber auch Carbon von Chandler Carruth ist nicht ganz uninteressant

ich würde auch einfach neue Subsystem in Rust machen - aber ich muss 
auch keine 100Mio oder 2Mrd Zeilen Code unter Kontrolle halten - bei 
diesen Größenordnungen könnten Verbesserungen im niedrigen/sten 
Prozentbereich schon sehr viel bedeutung haben

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Das ist mir durchaus beim Ansehen des Videos (und der ja teils
> euphorischen Kommentare) klar geworden. Ich fürchte trotzdem, dass das
> nicht viel bringt, und dass es sinnvoller ist, es so wie Firefox zu
> machen und stückweise Subsysteme neu zu implementieren.

Das bestreitet niemand. Nicht einmal der Typ im Video.

In einem Pony-Wunderland würde ich auch gerne mit dem Finger schnippen 
und alles in Rust neuschreiben.

Aber das ist halt gar nicht das Thema. Das Thema war: Wie bringe ich 
moderne Eigenschaften von modernen Sprachen in C++ rein.
Deine Antwort "nutze halt moderne Sprachen" ist in diesem Kontext Unfug.

Eines der größten Probleme mit C++ ist, dass es nicht mit Altlasten 
aufräumen kann. C++ ist eine stinkende Müllhalde an legacy-Features, auf 
die oben drauf schön säuberlich leckere Früchte drapiert werden. Das ist 
der zentrale Punkt im Video. Das führt zwangsläufig dazu, dass neuer 
Schrottcode entwickelt wird, obwohl das verhinderbar wäre.
Diesen Fakt kann man nicht einfach überbügeln mit: "Ja dann nutze halt 
Rust".

Es muss dringend ein Umdenken passieren.
Neue Software muss möglichst in neuen sicheren Sprachen entwickelt 
werden.
Und bestehende Software muss Altlasten abwerfen.

von Vincent H. (vinci)


Lesenswert?

cppbert schrieb:
> ja das Herb Sutter Beispiel ist ja nur ein Aufrüttler - was wäre wenn
> C++ sowas wie die Rust Editions hätte - was wäre möglich - Herb muss ja
> immer der am-weitesten-über-den-Tellerrand-schauer sein

Das wurde als 'Epochs' bereits von Vittorio Romero vorgeschlagen und 
soweit ich mich erinnern kann mit großer Mehrheit vom Komitee abgelehnt.

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


Lesenswert?

MaWin schrieb:
> Eines der größten Probleme mit C++ ist, dass es nicht mit Altlasten
> aufräumen kann.

Eben deshalb halte ich das für keine sonderlich zielführende Idee, da 
noch weiter dran herum zu ändern. C++ hat sowieso schon eine Unmenge an 
Veränderungen in den letzten Jahrzehnten erfahren, dass da kaum einer 
noch durchblickt.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Eben deshalb halte ich das für keine sonderlich zielführende Idee, da
> noch weiter dran herum zu ändern. C++ hat sowieso schon eine Unmenge an
> Veränderungen in den letzten Jahrzehnten erfahren, dass da kaum einer
> noch durchblickt.

Du scheinst das Video wirklich nicht geguckt oder verstanden zu haben.
Anders ist das kaum zu erklären.

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


Lesenswert?

Ich sehe einfach nicht, dass das die Welt retten würde.

von MaWin (Gast)


Lesenswert?

Zum Glück behauptet das ja auch niemand.
Aber würde es sie verschlechtern?

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


Lesenswert?

MaWin schrieb:
> Aber würde es sie verschlechtern?

Ist halt die Frage: wenn du Leuten noch weniger Anreiz gibst, 
stattdessen andere Sprachen in Erwägung zu ziehen, ist das dann schon 
eine Verschlechterung?

von MaWin (Gast)


Lesenswert?

Nein. Global ist das keine Verschlechterung, sondern eine Verbesserung.

Und auch lokal ist es eine Verbesserung, wenn man in der Realität lebt, 
wo man eben eine riesige Codebasis hat, die niemand auf eine 
inkompatible Sprache umziehen wird.
Das sind nun einmal Realitäten, mit denen wir leben müssen. Da ändert 
auch ein "Anreiz zur Migration" nichts dran.

Im Ponyland. Ja. Dort wäre Cpp2 eine Verschlechterung.
Ich lebe dort aber nicht.

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


Lesenswert?

MaWin schrieb:
> die niemand auf eine inkompatible Sprache umziehen wird

Es geht ja nicht um "umziehen" (vor allem nicht sofort), ich hatte 
Firefox als Beispiel genannt.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Es geht ja nicht um "umziehen" (vor allem nicht sofort)

Ja doch. Genau darum geht es.
Es geht darum bestehenden C++-Code mit Cpp2 zu übersetzen und Schritt 
für Schritt zu verbessern, bis man den Cpp2-only-Schalter umlegen kann. 
Die Rückwärtskompatibilität von Cpp2 ist Opt-In. Und dieses Opt-In würde 
man initial geben und Schrittweise zurückfahren.

Ganz ähnlich, wie man das bei der Migration von C zu C++ tun kann. (Wie 
z.B. gcc es getan haben). Der Erste Schritt ist: Keine Codeänderung. Nur 
neuer Compiler.
(Nur, dass es in C->C++-Fall keinen Opt-In-Schalter gibt).

Und das geht eben mit einer inkompatiblen Sprache wie Rust gar nicht.

Guck doch zur Abwechslung einmal das Video.

von Daniel A. (daniel-a)


Lesenswert?

MaWin schrieb:
> Ganz ähnlich, wie man das bei der Migration von C zu C++ tun kann. (Wie
> z.B. gcc es getan haben). Der Erste Schritt ist: Keine Codeänderung. Nur
> neuer Compiler.

C ist kein Subset von C++. C++ Leuten, die versuchen C zu schreiben, und 
die Sprache nicht kennen, mag es vielleicht so vor kommen. Aber echte C 
Programmierer kennen die Sprache und nutzen ihr Potential voll aus. 
Einfach einen C++ Compiler nehmen geht da erfahrungsgemäss nur selten. 
Zumindest bei meinem Code geht das eigentlich nie. Da habe ich sowohl 
Sachen, die in C++ gar nicht kompilieren würden, als auch solche, die in 
C wohldefiniert, und in C++ ub sind.

von Cyblord -. (cyblord)


Lesenswert?

Daniel A. schrieb:
> C ist kein Subset von C++

Dann lass mal hören welche Teile von C nicht in C++ enthalten sind.

von MaWin (Gast)


Lesenswert?

Daniel A. schrieb:
> C ist kein Subset von C++

In der Praxis halt schon.
Die Unterschiede sind klein genug, um eine Compilermigration in den 
allermeisten Projekten mit minimalen Codeänderungen durchzuführen.

Aber das ist hier off-topic. Das war nur ein Beispiel und ein Vergleich.

von Wilhelm M. (wimalopaan)


Lesenswert?

Cyblord -. schrieb:
> Daniel A. schrieb:
>> C ist kein Subset von C++
>
> Dann lass mal hören welche Teile von C nicht in C++ enthalten sind.

https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B

von Daniel A. (daniel-a)


Lesenswert?

Cyblord -. schrieb:
> Daniel A. schrieb:
>> C ist kein Subset von C++
>
> Dann lass mal hören welche Teile von C nicht in C++ enthalten sind.

Da gibt es ganz elementare Sachen.

z.B., wenn ich in C "struct bla" schreibe, dann ist nur "struct bla" 
definiert, aber bla nicht. Ich könnte dann sogar zeugs machen, wie 
"typedef int bla;", oder eine variable bla oder Funktion bla nennen, 
usw.

Ein anderes Beispiel sind compound literale. Und bevor du jetzt sagst, 
"C++ hat die jetzt auch", die haben dort zusätzliche Einschränkungen. In 
C spielt es keine rolle, in welcher Reihenfolge ich die Dinger 
initialisiere. In C++ schon.

Ein Klassiger sind auch die Cast regeln. "dingsbums* x = 
(dingsbums*)malloc(sizeof(*x));" ist in C ein absolutes noob no-go. Den 
cast lässt man gefälligst weg.

Ein Beispiel für etwas, das nicht nur anders funktioniert, sondern es 
nur in C gibt: _Generic.

Dann noch ein Beispiel, das in C gut funktioniert, aber in C++ ub ist:
1
#include <stdio.h>
2
#include <string.h>
3
static inline char* hello(char bla[13]){
4
  strcpy(bla, "Hello World!");
5
  return bla;
6
}
7
int main(){
8
  const char* msg = hello((char[16]){0});
9
  puts(msg); // In C ok, da das compound literal im block scope ist. In C++ ub, weil die Lifetime nach dem Funktionsaufruf zuende ist.
10
}

Ich hätte noch mehr Beispiele, aber das dürfte fürs erste mal reichen.

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


Lesenswert?

MaWin schrieb:
> Es geht darum bestehenden C++-Code mit Cpp2 zu übersetzen und Schritt
> für Schritt zu verbessern, bis man den Cpp2-only-Schalter umlegen kann.

Ich habe nur meine Zweifel, dass just diese Organisationen mit riesigen 
C++-Codebasen die nötigen Ressourcen dafür aufzuwenden bereit sind. Denn 
es kostet Ressourcen, das alles durchzugehen. Das sehen wir doch schon 
an so einfachen Beispielen wie Compilerwarnungen über Mischen von signed 
und unsigned. Welches größere Projekt macht sich nachträglich die Mühe 
(die ja insbesondere auch irgendeine Finanzierung benötigt), sowas zu 
reparieren?

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Ich habe nur meine Zweifel, dass just diese Organisationen mit riesigen
> C++-Codebasen die nötigen Ressourcen dafür aufzuwenden bereit sind. Denn
> es kostet Ressourcen, das alles durchzugehen. Das sehen wir doch schon
> an so einfachen Beispielen wie Compilerwarnungen über Mischen von signed
> und unsigned.

Völlig richtig.
Und dann schlussfolgerst du, dass man stattdessen besser alles in Rust 
neuentwickeln soll?
Das verstehe, wer will.

von Marco (Gast)


Lesenswert?

DPA schrieb:
> Rust - ist das hier um zu bleiben?

Da Rust nun sehr alt ist, denke ich kann es weg!

von Rolf M. (rmagnus)


Lesenswert?

Daniel A. schrieb:
> Ich hätte noch mehr Beispiele, aber das dürfte fürs erste mal reichen.

Das ist denk ich der Punkt: Es ist nicht das eine große Feature, das in 
C++ fehlt, sondern viele Feinheiten, die es inkompatibel machen. Man 
muss auch bedenken, dass C++ ursprünglich mal C89 als Basis hatte. 
Inzwischen hat sich auch C weiterentwickelt. Vieles davon wurde in C++ 
auch nachgezogen, aber nicht alles, und auch nicht alles exakt gleich.

von MaWin (Gast)


Lesenswert?

Rolf M. schrieb:
> Das ist denk ich der Punkt

Nein. Der Punkt war, dass das nur ein Beispiel war. Ein Vergleich.
Große Projekte haben diese Migration geschafft.
Auch wenn die µC.net-Experten dies aufgrund der großen Unterschiede als 
praktisch unmöglich ansehen.

Aber das ist nicht schlimm. Denn derzeit sind die Unterschiede zwischen 
Cpp2 und C++ noch genau 0, bei Compat-Opt-In.
Die Situation bei C++->Cpp2 ist also noch besser, als bei C->C++.

Und, nicht vergessen:
Cpp2 ist ein Vorschlag. Eine Idee. Ein Verbesserungsvorschlag zur 
Inkrementellen Verbesserung des C++-Ökosystems.
Es ist nicht: Ein fertiger Compiler. Ein Standard. Ein Zwang. Ein Keks.

Ich finde es ist unbedingt notwendig C++-Altlasten über Bord zu werfen 
und trotzdem rückwärtskompatibel zu bleiben. Und das ist, was Cpp2 
versucht vorzuschlagen und auch praktisch zu demonstrieren.
Und das finde ich gut.
Das ist ein wichtiger Schritt in die Richtung sicherer Sprachen, wie 
z.B. Rust.

von rbx (Gast)


Lesenswert?

Ein wenig Rust-Soziologie:

https://books.goalkicker.com

Rust: A Language for the Next 40 Years - Carol Nichols
https://www.youtube.com/watch?v=A3AdN7U24iU

https://www.reddit.com/r/rust/comments/jb3ukm/we_need_to_talk_a
bout_stackoverflow/

Richard Feldman — The Next Paradigm Shift in Programming
https://www.youtube.com/watch?v=6YbK8o9rZfI
(besonders spannend: die OO-Anfänge und Ideen. Viele Computer? großes 
Multirechnernetzwerk?)
(Haskell Cabal/Stack, Rust Online - statt komplettes Offline-Packet zum 
Lesen und Arbeiten (auch für DOS) wie bei OpenWatcom.)

https://de.wikipedia.org/wiki/Kognitive_Dissonanz#:~:text=Kognitive%20Dissonanz%20bezeichnet%20in%20der,Einstellungen%2C%20Wünsche%20oder%20Absichten).

Da FP sehr abstrakt ist, braucht es eine ganze Weile bis es rutscht.
Lerntechnisch ist es vielleicht hilfreicher für viele, C++ FP, oder 
JavaScriptFP oder Scala o.ä. zu nutzen.

von Rolf M. (rmagnus)


Lesenswert?

MaWin schrieb:
> Rolf M. schrieb:
>> Das ist denk ich der Punkt
>
> Nein. Der Punkt war, dass das nur ein Beispiel war. Ein Vergleich.
> Große Projekte haben diese Migration geschafft.

Natürlich ist die Migration machbar. Alleine schon die Wortwahl 
"Migration geschafft" zeigt aber doch, dass es doch etwas mehr ist als 
das Ersetzen von "gcc" durch "g++" im Makefile. Je nach Projekt kann der 
Aufwand zwischen relativ gering und sehr hoch variieren. Gemacht habe 
ich das auch schon, und dabei habe ich eben gemerkt, dass da der Teufel 
oft im Detail steckt.

> Auch wenn die µC.net-Experten dies aufgrund der großen Unterschiede als
> praktisch unmöglich ansehen.

Das habe ich hier nirgends gelesen.

von MaWin (Gast)


Lesenswert?

Rolf M. schrieb:
> Alleine schon die Wortwahl

Ja, Rolf. Du hast Recht. In allen Punkten.
Ich stimme dir voll und ganz zu. Was du sagst, ist die 100%ige Wahrheit.
Das war lediglich ein Vergleich. Und du hast die Probleme bei diesem 
Vergleich sehr schön dargelegt.

Ist es jetzt gut?

von Nano (Gast)


Lesenswert?

Mal eine etwas andere Frage.

C Compiler gibt es für 8086 Prozessoren zur genüge, die dann im 16 Bit 
Real Mode laufen und mit <= 640 KiB RAM auskommen.

Wäre das auch mit Rust möglich, wenn man dafür einen Compiler entwickeln 
würde, oder ist dafür die Sprache schon zu komplex?


Ja, man könnte den Code auch auf einer dicken Maschine compilieren, aber 
das ist hier nicht die Frage. Die Frage ist, ob ein Rust Compiler 
machbar wäre, der auf einem altem 8086 PC mit 640 KiB RAM läuft und zwar 
so, dass man nicht ständig auf der Festplatte Daten auslagern muss.

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


Lesenswert?

Nano schrieb:
> Die Frage ist,

… was willst du damit?

Fragt doch auch keiner nach einem C++-Compiler für CP/M. (Selbst 
C-Compiler für CP/M waren eher der Graus.)

Nicht einmal GCC läuft auf diesem ollen Krempel. DJ-GCC lief nur im 
32-Bit-Modus eines 80386.

: Bearbeitet durch Moderator
von Nano (Gast)


Lesenswert?

Jörg W. schrieb:
> Nano schrieb:
>> Die Frage ist,
>
> … was willst du damit?

Ich will einfach nur wissen ob es bei der Komplexität von Rust ginge.
Rust ist immerhin eine sehr moderne Sprache mit so Sachen wie Modulen.
Während man sich bei C und C++ noch um Headerdateien anstatt Modulen 
abmühte. Einer der Gründe warum waren die Systemanforderungen für den 
Compiler.

> Fragt doch auch keiner nach einem C++-Compiler für CP/M. (Selbst
> C-Compiler für CP/M waren eher der Graus.)

Typische CP/M Systeme hatten üblicherweise noch weniger RAM zur 
Verfügung.

> Nicht einmal GCC läuft auf diesem ollen Krempel. DJ-GCC lief nur im
> 32-Bit-Modus eines 80386.

GCC nicht, aber dafür frühe Microsoft C und QuickC Versionen. Sowie 
sicherlich auch Turbo C und noch ein paar andere. Frühe Watcom C 
Versionen eventuell auch noch.

von MaWin (Gast)


Lesenswert?

Nano schrieb:
> Die Frage ist, ob ein Rust Compiler
> machbar wäre, der auf einem altem 8086 PC mit 640 KiB RAM läuft und zwar
> so, dass man nicht ständig auf der Festplatte Daten auslagern muss.

Ziemlich sicher nicht.
Heutige Sprachen sind überhaupt nur möglich, weil genug Rechenleistung 
und Speicher für die Compiler zur Verfügung stehen.

Auch modernes C kann man mit einem modernen optimierenden Compiler nicht 
auf einer 8086 mit 640k RAM compilieren.

von cppbert (Gast)


Lesenswert?

Nano schrieb:
> Ich will einfach nur wissen ob es bei der Komplexität von Rust ginge.
> Rust ist immerhin eine sehr moderne Sprache mit so Sachen wie Modulen.
> Während man sich bei C und C++ noch um Headerdateien anstatt Modulen
> abmühte. Einer der Gründe warum waren die Systemanforderungen für den
> Compiler.

nein sicher nicht - die Analyse braucht einfach zu viel Speicher - aber 
selbst C hat im Vergleich zu damaligen Assemblern schon viel mehr 
Resourcen gebraucht
in den Anfängen von C mussten viele auch sicherliche ständig zwischen 
Disketten und Programmen wechseln um überhaupt was kompiliert zu 
bekommen

aber als Cross-Compiler könnte es gehen - wenn jemand sich darauf 
konzentriert einen Optimizer dafür zu schreiben der dann auch ordentlich 
auf Realmode Segment/Offset Kram optimiert ist

der aktuelle GCC IA 16 (https://github.com/tkchia/gcc-ia16) kann ja auch 
ordentlichen 8086 Code erzeugen und optimiert definitv besser als die 
Kompiler aus der Zeit und läuft sogar auf DOS - aber auch nur mit 
Extender und leider kein C++ :(

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


Lesenswert?

cppbert schrieb:
> aber selbst C hat im Vergleich zu damaligen Assemblern schon viel mehr
> Resourcen gebraucht

Üblich war eine Diskette mit den Tools, eine zweite mit den Dateien 
(Quellcode, Zwischendateien). Dauerte natürlich in der Tat ewig.

Turbo-Pascal wurde seinem Namen dagegen gerecht, im Vergleich zu allen 
anderen Compilern der Zeit war es rasend schnell und brachte noch dazu 
die wohl erste IDE mit, die es gab. Im Vergleich zu heute dürfte die 
Optimierung nicht sonderlich großartig gewesen sein, aber für viele 
Fälle reichte es. Ich habe einen kompletten EPROMMer damit recht 
komfortabel bedient, nur die innere Schleife wurde dann durch 
handoptimierten Inline-Assembler ersetzt.

von Nano (Gast)


Lesenswert?

cppbert schrieb:
> Nano schrieb:
>> Ich will einfach nur wissen ob es bei der Komplexität von Rust ginge.
>> Rust ist immerhin eine sehr moderne Sprache mit so Sachen wie Modulen.
>> Während man sich bei C und C++ noch um Headerdateien anstatt Modulen
>> abmühte. Einer der Gründe warum waren die Systemanforderungen für den
>> Compiler.
>
> nein sicher nicht - die Analyse braucht einfach zu viel Speicher -

Danke für die Antwort.

> aber
> selbst C hat im Vergleich zu damaligen Assemblern schon viel mehr
> Resourcen gebraucht
> in den Anfängen von C mussten viele auch sicherliche ständig zwischen
> Disketten und Programmen wechseln um überhaupt was kompiliert zu
> bekommen

Ja, das lag Anfangs aber an den Datenträgern. Mit Festplatten fiel das 
Diskette wechseln dann weg.
Bliebe dann nur noch das Auslagern von Daten auf Festplatte während dem 
Compilevorgang von größeren Projekten.

von Alexander S. (alesi)


Lesenswert?

MaWin schrieb:
> Ziemlich sicher nicht.
> Heutige Sprachen sind überhaupt nur möglich, weil genug Rechenleistung
> und Speicher für die Compiler zur Verfügung stehen.
>
> Auch modernes C kann man mit einem modernen optimierenden Compiler nicht
> auf einer 8086 mit 640k RAM compilieren.

Forth (2012) könnte vielleicht auf 8086 mit 640k RAM  gehen. Auf die 
Schnelle habe ich dazu aber keine Infos gefunden, nur das gforth auf 386 
läuft. https://gforth.org/  Supported systems i386 und Gforth 
EC(embedded) auch auf 8086.

P.S. Das ist zwar off-topic. Aber das waren einige andere Beiträge 
vorher auch. :-)

von Rolf M. (rmagnus)


Lesenswert?

Frühe Compiler bestanden aus mehreren Einzelprogrammen, von denen jedes 
einen Teilschritt des Compiliervorgangs durchführte, weil man alles 
zusammen nicht gleichzeitig in den Speicher bekam. Das hat's natürlich 
auch nicht gerade schnell gemacht, weil die Zwischenergebnisse natürlich 
immer erst abgespeichert und dann wieder geladen werden mussten. So sind 
moderne Compiler aber nicht mehr aufgebaut, daher funktionieren die auf 
Systemen mit so begrenzten Ressourcen nicht.

: Bearbeitet durch User
von 🐧 DPA 🐧 (Gast)


Lesenswert?

Rolf M. schrieb:
> So sind moderne Compiler aber nicht mehr aufgebaut, daher funktionieren die auf
> Systemen mit so begrenzten Ressourcen nicht.

Jein. Auch bei den 2 rust compilern gibt es theoretisch noch object 
files. Aber ohne separate include Files mit dem Interface zeugs drinn 
muss der Compiler trotzdem die ganzen abhängigen quellen ansehen, und da 
kann schnell mal alles zusammen hängen. Kommt aber aufs selbe raus, 
finde ich nicht gut. Da können selbst moderate Systeme ganz schön ins 
schwitzen kommen.

Der GCC kann übrigens auch noch pipes zwischen Compiler und Linker 
verwenden. So könnte man also theoretisch kompilieren und linken, ohne 
alles ins Dateisystem zu legen, und ohne alles auf einmal im RAM zu 
haben. Wobei, vermutlich bringt das heute auch nicht mehr viel, falls es 
überhaupt noch funktioniert...

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


Lesenswert?

🐧 DPA 🐧 schrieb:
> Der GCC kann übrigens auch noch pipes zwischen Compiler und Linker
> verwenden.

Linker nicht, aber zwischen Compiler und Assembler.
Präprozessor früher noch, aber das ist kein separater Prozess mehr.

von Wilhelm M. (wimalopaan)


Lesenswert?

🐧 DPA 🐧 schrieb:
> So könnte man also theoretisch kompilieren und linken, ohne
> alles ins Dateisystem zu legen, und ohne alles auf einmal im RAM zu
> haben.

Das ist beim gcc normal, siehe -save-temps Option.

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


Lesenswert?

Wilhelm M. schrieb:
> Das ist beim gcc normal, siehe -save-temps Option.

-save-temps behält sie nur bei, erzeugt werden sie auch sonst.

Aber das dürfte bei heutigen Betriebssystemen und Speichergrößen oft 
keine Rolle mehr spielen, weil die Zwischendateien im Cache bleiben. 
Windows ist allerdings mit vielen Dateioperationen spürbar langsam, und 
wenn man dann noch einen Virenchecker hat, der sich auch noch alle 
Zwischendateien ansehen möchte, dann hat man die Po-Karte gezogen.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Jörg W. schrieb:
> dann hat man die Po-Karte gezogen.

Wenn du ein Po-Kartenspiel hast, und du ziehst eine Karte...Was 
erwartest du dann? ;-)

scnr,
WK

von Wilhelm M. (wimalopaan)


Lesenswert?

Jörg W. schrieb:
> Aber das dürfte bei heutigen Betriebssystemen und Speichergrößen oft
> keine Rolle mehr spielen, weil die Zwischendateien im Cache bleiben.

Bei *nix werden temporäre Dateien unter /tmp erzeugt, was typischerweise 
ein tmpfs o.ä. ist, für das keine Persistenz verlangt wird.

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


Lesenswert?

Wilhelm M. schrieb:
> Bei *nix werden temporäre Dateien unter /tmp erzeugt, was typischerweise
> ein tmpfs o.ä. ist

So typisch ist das nicht. Auf den Systemen, wo ich arbeite, ist es ein 
ganz normales Dateisystem (bzw. Bestandteil von /). Trotzdem geht es 
schnell, weil der Krempel noch komplett im RAM verfügbar ist, wenn die 
nächste Phase ihn wieder lesen will. Daher bringt -pipe nicht mehr so 
viel, wie das noch vor 20 Jahren der Fall war.

von Wilhelm M. (wimalopaan)


Lesenswert?

Jörg W. schrieb:
> So typisch ist das nicht.

Dann sind Deine Systeme atypisch oder antiquarisch oder beides ;-)

von cppbert (Gast)


Lesenswert?

zurück zum Thema, Burschen!

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


Lesenswert?

Du meinst, zur Frage, ob der Rust-Compiler auch temp files anlegt und ob 
man schneller wird, wenn man sie durch eine Pipe ersetzt? ;-)

Gibt's eigentlich Geschwindigkeitsvergleiche zwischen *nix und Windows 
für den Rust-Compiler?

von rbx (Gast)


Lesenswert?

Jörg W. schrieb:
> Gibt's eigentlich Geschwindigkeitsvergleiche zwischen *nix und Windows
> für den Rust-Compiler?

Hinsichtlich der Installation mit Sicherheit ;)

von Nano (Gast)


Lesenswert?

Rolf M. schrieb:
> Frühe Compiler bestanden aus mehreren Einzelprogrammen, von denen
> jedes
> einen Teilschritt des Compiliervorgangs durchführte, weil man alles
> zusammen nicht gleichzeitig in den Speicher bekam. Das hat's natürlich
> auch nicht gerade schnell gemacht, weil die Zwischenergebnisse natürlich
> immer erst abgespeichert und dann wieder geladen werden mussten.

Das ist richtig.

Präprozessor
Compiler
Assembler
Linker
und gegebenenfalls noch
EXE2BIN (war Bestandteil von MS-DOS, wurde manchem MS Compiler aber auch 
mitgeliefert)


> So sind
> moderne Compiler aber nicht mehr aufgebaut, daher funktionieren die auf
> Systemen mit so begrenzten Ressourcen nicht.

Das ist korrekt.
Bei LLVM wird sogar Bytecode für eine eigene CPU Maschine erzeugt und 
aus dem Bytecode wird dann erst der eigentliche Maschinencode für die 
Ziel CPU erstellt.

Der Vorteil:
Alle Sprachen generieren den Bytecode und aus diesem einen unified 
Bytecode kann man dann den eigentlichen Maschinencode für die Ziel CPU 
erstellen.
Damit muss man die Arbeit für eine bestimmte Ziel CPU nur einmal machen 
und man kann alle Sprachen für diese nutzen. Umgekehrt gilt das gleiche.

von Alexander S. (alesi)


Lesenswert?

cppbert schrieb:
> zurück zum Thema, Burschen!

Ok, zweiter Versuch:
Was kann Rust besser als Forth? https://gforth.org/
:-)

von MaWin (Gast)


Lesenswert?

Nano schrieb:
> Bei LLVM wird sogar Bytecode für eine eigene CPU Maschine erzeugt

Um noch einmal zum Thema des Threads zurück zu kommen:

Bei Rust gibt es nicht nur einen solchen Zwischenschritt (IR), sondern 
mehrere:

https://blog.rust-lang.org/2016/04/19/MIR.html

von Rolf M. (rmagnus)


Lesenswert?

Nano schrieb:
> Präprozessor
> Compiler
> Assembler
> Linker
> und gegebenenfalls noch
> EXE2BIN (war Bestandteil von MS-DOS, wurde manchem MS Compiler aber auch
> mitgeliefert)

Ich beziehe mich nur auf den Teil "Compiler". Dieser wurde in mehrere 
als getrennte Programme ausgeführte Einzelschritte zerlegt, wie z.B. 
lexikalische Analyse, Syntaxanalyse, Codegenerierung.

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


Lesenswert?

MaWin schrieb:
> Bei Rust gibt es nicht nur einen solchen Zwischenschritt (IR), sondern
> mehrere:

Wobei das jetzt eher ein Implementierungsdetail denn ein Sprachfeature 
sein dürfte, oder? Trifft man außerdem auch bei anderen Sprachen an. 
Lass mal den GCC mit -fdump-rtl-all laufen und erfreu dich dann an 
mehreren Dutzend Dateien, die die einzelnen Zwischenstufen 
repräsentieren. ;-)

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Wobei das jetzt eher ein Implementierungsdetail denn ein Sprachfeature
> sein dürfte, oder?

Bitte einfach einmal den verlinkten Artikel lesen.

> Trifft man außerdem auch bei anderen Sprachen an.

Ach. Wer hätte es gedacht.
Habe ich ja auch nie in Frage gestellt.

MaWin schrieb:
> Um noch einmal zum Thema des Threads zurück zu kommen:

Also doch wieder off-topic.
"anderen Sprachen"...

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


Lesenswert?

MaWin schrieb:
> Bitte einfach einmal den verlinkten Artikel lesen.

Ändert nichts dran, dass da Implementierungsdetails beschrieben werden.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Ändert nichts dran, dass da Implementierungsdetails beschrieben werden.

Genau so sieht es aus.
Das Lesen hätte des Artikels hätte die Frage beantwortet, bevor du sie 
hier gestellt hast.

von rbx (Gast)


Lesenswert?

MaWin schrieb:
> Also doch wieder off-topic.
> "anderen Sprachen"...

Was willst du denn immer mit deinem "offtopic"?

Wir sind hier nicht irgendwie Sprachdesigner von Rust, sondern es geht 
darum, welche Zukunft die Programmiersprache und seine 
Bereitstellung/Logistik/Schulung usw. hat.

Beispielsweise, warum kann man Rust nicht einfach wie D auf Windows 
installieren? D braucht nur einen kleinen Ordner, und man kann sofort 
damit arbeiten, ganz easy.
Nicht wirklich schwieriger als eine Tiny C Installation.

Den oben verlinkten Artikel solltest du mal ausdrucken. Wenn man das 
macht, hat man schon einen halben Arztroman zusammen.

Die FP Programmierung muss man (lange) pauken, wenn man nicht irgendwie 
mit Lisp (+ Emacs) groß geworden ist.

Für Haskell braucht man eigentlich nur Notepad oder Papier und 
Bleistift. Aber so richtig gut unter Windows funzt der GHC bzw. die 
Haskell Plattform auch nicht, ziemliches Gewürge bei der Installation, 
und dann auch noch pingelig hinsichtlich der Windows-Version.  - so dass 
man Haskell dann noch lieber auf Linux nutzen möchte.
Bei Rust ganz ähnlich.
Darüber sollten sich diese Rustentwickler mal ein paar Gedanken machen.
D oder Tiny C sind diesbezüglich einfach viel besser, trotz der 
eingeschränkten Ressourcen.

Und: Java? Java ist das abschreckende Beispiel bestimmter Entwicklungen. 
Python ja irgendwie auch - aber da gibt es wohl Wege, damit besser 
klarzukommen.

Und Idris? Was soll ich mit Idris, ich möchte mit Haskell arbeiten. Ach 
sch..

von MaWin (Gast)


Lesenswert?

rbx schrieb:
> Was willst du denn immer mit deinem "offtopic"?

Weil es hier um Rust geht. Nicht um Haskell oder sonstige Sprachen.

Damit ist 90% deines Beitrags wieder einmal off-topic.

> Beispielsweise, warum kann man Rust nicht einfach wie D auf Windows
> installieren?

Du musst ein Exe herunterladen und doppelt draufklicken.
Viel einfacher kann es nicht werden.

von DPA (Gast)


Lesenswert?

Man nennt das über den eigenen Tellerrand schauen. Aber das kann man 
nach Rust ja nicht mehr...

von rbx (Gast)


Lesenswert?

MaWin schrieb:
> Du musst ein Exe herunterladen und doppelt draufklicken.
> Viel einfacher kann es nicht werden.

(nightly Build): Falsche Windowsversion..

von MaWin (Gast)


Lesenswert?

rbx schrieb:
> (nightly Build): Falsche Windowsversion..

Was heißt das auf Deutsch?

von rbx (Gast)


Lesenswert?

MaWin schrieb:
> Was heißt das auf Deutsch?

Das heißt, dass Tiny C oder D viel einfacher zu installieren sind. 
Einfach downloaden, eventuell noch auspacken, fertisch.

Bei Rust: Warten, ...warten...warten...und wenn dann (so nach 30 Min) 
der Ordner fertig ist, z.B. könnte man diese Buch.exe anklicken und 
dann..

"Dieses Programm kann kann nicht auf Windows ausgeführt werden" - oder 
so ähnlich - typischerweise heißt das: Inkompatibles Windows. (-> 
lächerlich)

(Und groß VS Studio vorher zu installieren, das dauert auch ziemlich 
lange und verbraucht ziemlich viel Speicherplatz. Warum nicht was mit 
mingw?)

Wiederum lächerlich zu Tiny C, D, oder von mir aus auch Hugs. ( 
https://www.heise.de/download/product/hugs-98-40452 )
Hugs verarbeitet übrigens auch (im Gegensatz zum GHC) 
Literate-Programming. Schöne Sache.

( 
https://steamcommunity.com/app/252490/discussions/0/1745646819954096664/ 
)

von MaWin (Gast)


Lesenswert?

Troll bitte woanders.
Das ist ganz offensichtlich ausgedachter Quatsch.
Und das kann jeder nachprüfen, indem er selbst Rust installiert.
Also was soll das?

von rbx (Gast)


Lesenswert?

MaWin schrieb:
> Und das kann jeder nachprüfen, indem er selbst Rust installiert.
> Also was soll das?

Auch jemand, der Windows 8.1. hat, oder XP oder Me? Das würde mich echt 
mal interessieren.

Wenn hier einer trollt, dann kommt das von einem, der hier Rust 
lobpreist, obwohl noch vieles im Argen ist.
Scheint ja für diesen Typen einfacher zu sein, mehr auf die 
Persönlichkeitseigenschaften zu schließen, wenn dem was nicht passt, als 
tatsächlich mal die Sachlage zu überblicken.

Als ich das erste mal mit Modula 3 Bekannschaft machte, da hieß es, das 
wäre eine TOP-Programmiersprache. Ist die eigentlich auch. Aber die 
Logistik, die Linux-Pflicht, die Unibeschränktheit, die Bibs..

von Oliver R. (Gast)


Lesenswert?

rbx schrieb:
> Auch jemand, der Windows 8.1. hat, oder XP oder Me? Das würde mich echt
> mal interessieren.

Rust unter Windows 7 habe ich selbst getestet, funktioniert. Und ja, die 
Installation ist nervig wegen dieser GB grossen Abhängigkeiten. Ich 
fürchte, das hat aber auch mit lizenzrechtlichen Dingen zu tun und es 
daher getrennt von MS geladen werden muss.

von rbx (Gast)


Lesenswert?

Oliver R. schrieb:
> Rust unter Windows 7 habe ich selbst getestet, funktioniert.

Danke für den Hinweis.
32 oder 64 Bit?

Ich habe 64 Bit Windows 8.1. Da lief dann aber nach der Installation 
nichts, also ist der ganze Ordner wieder in den Papierkorb gewandert, 
und der auch gleich geleert worden.
Eventuell war der Nightly Build ein Fehler, möglicherweise funzt stable 
besser, mal sehen.

von Nachdenklicher (Gast)


Lesenswert?

Ich habe, angelockt durch diesen Thread her, jetzt einfach mal einen 
Test gemacht.
Ein einfaches Hello World in Rust unter Linux aus dem Tutorial kopiert 
und kompiliert. Das Executable hat knapp 4 Megabyte. Also jetzt mal im 
Ernst, das ist doch ein schlechter Witz, oder?  4 MB für ein Programm, 
das "Hello, World!" auf der Konsole ausgibt? 🤯

von Oliver R. (Gast)


Lesenswert?

rbx schrieb:
> Danke für den Hinweis.
> 32 oder 64 Bit?

War 64 Bit. Ist allerdings schon eine Weile her und der betreffende 
Rechner steht auch nicht bei mir. Ich würde auch bei stable bleiben 
solange nightly nicht explizit für bestimmten Code benötigt wird. 
Ansonsten verlierst du einen der Hauptvorteile von Rust, nämlich die 
Garantie, dass dein Code in allen zukünftigen (stable) Versionen 
kompilieren wird.

von Oliver R. (Gast)


Lesenswert?

Nachdenklicher schrieb:
> 4 MB für ein Programm,
> das "Hello, World!" auf der Konsole ausgibt?

Bist du sicher, dass du im Release Mode kompiliert hast und auch keine 
Debug Symbole drin sind?

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


Lesenswert?

Nachdenklicher schrieb:
> Das Executable hat knapp 4 Megabyte.

Schau dir die Ausgabe von "size <filename>" an, nicht die Größe im 
Dateisystem.

von Oliver R. (Gast)


Lesenswert?

Gerade getestet, das Hello World im Release Mode ohne Debug Symbole 
belegt unter Linux 289080 Bytes im Dateisystem. Man kann argumentieren, 
dass das immer noch viel ist und es gibt wohl Möglichkeiten da noch 
Platz einzusparen.

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


Lesenswert?

1
$ cat helloworld.rs 
2
fn main() {
3
    // Statements here are executed when the compiled binary is called
4
5
    // Print text to the console
6
    println!("Hello World!");
7
}
8
$ rustc -O helloworld.rs
9
$ ./helloworld
10
Hello World!
11
$ size helloworld
12
    text    data   bss      dec       hex   filename
13
  307914   12864   273   321051   0x4e61b   helloworld
OK, Gegentest:
1
$ cat helloworld.c
2
#include <stdio.h>
3
4
int main(void) {
5
   printf("Hello, world!\n");
6
   return 0;
7
}
8
$ cc -O -o helloworld helloworld.c
9
$ ./helloworld 
10
Hello, world!
11
$ size helloworld
12
  text   data   bss    dec     hex   filename
13
  1839    409     8   2256   0x8d0   helloworld
Gut, etwas kleiner. :-)
1
$ cat helloworld.cc
2
#include <iostream>
3
4
int main(void) {
5
  std::cout << "Hello, world" << std::endl;
6
  return 0;
7
}
8
$ c++ -O -o helloworld helloworld.cc
9
$ ./helloworld 
10
Hello, world
11
$ size helloworld
12
  text   data   bss    dec      hex   filename
13
  4997    649   192   5838   0x16ce   helloworld
Aber so ist das mit Trivialbeispielen, sie sind völlig unrepräsentativ 
für die reale Welt.

von Oliver R. (Gast)


Lesenswert?

Wer etwas tiefer einsteigen will:

https://github.com/johnthagen/min-sized-rust

von Nachdenklicher (Gast)


Lesenswert?

Jörg W. schrieb:
> $ size helloworld
>     text    data   bss      dec       hex   filename
>   307914   12864   273   321051   0x4e61b   helloworld

Okay, das sieht bei mir auch so in der Art aus, mit Abweichungen um 
wenige Bytes. Aber:
1
$ ls -lah
2
total 3,9M
3
drwxrwxr-x 2 user user 4,0K Dez 12 12:23 .
4
drwxrwxr-x 5 user user 4,0K Dez 12 12:22 ..
5
-rwxrwxr-x 1 user user 3,9M Dez 12 12:30 helloworld
6
-rw-rw-r-- 1 user user   45 Dez 12 12:28 helloworld.rs

Ich konnte es nicht aus der VM raus kopieren, eventuelle Tippfehler 
kommen vom Abschreiben. Woran liegt das dann, frage ich mich? Am 
Dateisystem ja wohl eher nicht, wenn der Sourcecode korrekt mit 45 Bytes 
angezeigt wird.

Kompiliert ist es mit "rustc helloworld.rs". Ob das was mit Debug oder 
ohne ist, weiß ich nicht...

von Cyblord -. (cyblord)


Lesenswert?

307914 vs 1839.

Damit hat sich die Frage nach Rust für Embedded sowieso bereits 
erledigt. Wie schon vermutet, alles ein Phänomen im PC Bereich. Wo bei 
Speicher und Co. alles egal ist.
Wie soll man mit so einem Footprint C für den Microcontrollerbereich mit 
wenigen MB oder gar kB Flash ablösen? Utopie trifft Wahnvorstellung.

von MaWin (Gast)


Lesenswert?

Ja. Die Größe der Rust-Binaries ist auf dem PC etwas größer als bei C.
Das ist ein bekanntes Problem und daran wurde auch schon gearbeitet.

Es wird jedoch offenbar nicht mit höchster Priorität verfolgt, da das ja 
nicht wirklich ein Problem ist. Ob ein Binary einer großen Applikation 
jetzt ein paar hundert kB größer ist oder nicht, spielt selten eine 
Rolle.

Ich denke echt, dass es da wichtigere Probleme zu lösen gibt.

> Und ja, die
> Installation ist nervig wegen dieser GB grossen Abhängigkeiten.

Ja. Das ist aber nur bei Windows so und der Grund ist Microsoft.
Da ist Rust selbstverständlich auch nicht alleine. So gut wie jede etwas 
größere Applikation braucht diese RT unter Windows.

Da kann Rust nun beim besten Willen nichts für und kann da auch nichts 
dran ändern.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Damit hat sich die Frage nach Rust für Embedded sowieso bereits
> erledigt.

Nö. Das ist ein reines PC-"Problem".

> Utopie trifft Wahnvorstellung

Vielleicht eher: Unwissenheit trifft Cyblord.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Nö. Das ist ein reines PC-"Problem".

Ach so. Gibts denn so ein Beispiel dann auch mal für zwei lauffähige 
Binaries für sagen wie mal nen STM32F103?

> Da kann Rust nun beim besten Willen nichts für und kann da auch nichts
> dran ändern.

Wenn man nicht schwimmen kann, ist meistens nicht die Badehose schuld.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Nachdenklicher schrieb:
> Woran liegt das dann, frage ich mich?

An allen möglichen weiteren sections im ELF-File, also Symboltabellen 
und Debug-Infos.

Aber das ist doch für die praktische Anwendung komplett irrelevant: 
geladen wird das, was "size" dir anzeigt. Alles andere braucht Platz auf 
der Festplatte, mehr nicht.

Cyblord -. schrieb:
> 307914 vs 1839.

Lässt allerdings komplett außer acht, dass das natürlich hier alles 
dynamisch gelinkte Binaries sind, d.h. ein nicht zu vernachlässigender 
Anteil an Code liegt in den shared libs. Jedoch sind diese natürlich, so 
der Name, eben "shared", d.h. alle Anwendungen nutzen das gemeinsam. 
(Das wäre bei "deeply embedded", also MCUs, anders.)

von Cyblord -. (cyblord)


Lesenswert?

Jörg W. schrieb:
> Lässt allerdings komplett außer acht, dass das natürlich hier alles
> dynamisch gelinkte Binaries sind, d.h. ein nicht zu vernachlässigender
> Anteil an Code liegt in den shared libs. Jedoch sind diese natürlich, so
> der Name, eben "shared", d.h. alle Anwendungen nutzen das gemeinsam.
> (Das wäre bei "deeply embedded", also MCUs, anders.)

Und was macht das C Programm hier anders als Rust? Und warum? Das muss 
ja auch auf dem bösen Windows laufen.

: Bearbeitet durch User
von Oliver R. (Gast)


Lesenswert?

Der Hauptgrund für die Binary-Größe auf Desktop-System ist die 
dazugelinkte Standard-Library. Embedded ist aber typischerweise 
"no-std", d.h. diese Problematik entfällt hier und die Binaries sind 
deutlich kleiner.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Ach so. Gibts denn so ein Beispiel dann auch mal für zwei lauffähige
> Binaries für sagen wie mal nen STM32F103?

Bestimmt. Google wieder kaputt?

Ich habe schon Binaries für AVR8 kompiliert.
Ein Rust-Programm mit leerer main() ist genau so groß wie ein C-Programm 
mit leerer main(). Es enthält dann in beiden Fällen nur die 
avr-libc-Boot- und Basisroutinen.

von Cyblord -. (cyblord)


Lesenswert?

Oliver R. schrieb:
> Der Hauptgrund für die Binary-Größe auf Desktop-System ist die
> dazugelinkte Standard-Library.

Also ist die Standard Library für Rust nur bloat im Gegensatz zu der von 
C? Nochmal die Frage an dich: Warum hat ein C Programm unter Windows 
nicht die gleichen Probleme?

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


Lesenswert?

Oliver R. schrieb:
> Der Hauptgrund für die Binary-Größe auf Desktop-System ist die
> dazugelinkte Standard-Library.

Leuchtet allerdings dahingehend nicht ein, dass aus einer Library nur 
die Dinge gelinkt werden sollten, die auch tatsächlich benötigt werden.

Es werden wohl eher Dinge wie ein Laufzeitsystem sein, die das 
aufblähen. Da ist dann die Frage, wieviel dieses Overheads eher statisch 
sind (also auch bei großen Programmen annähernd gleich groß bleiben), 
oder ob da was "mitwächst".

Dass ein Helloworld kein sinnvoller Benchmark für die Größe eines 
erzeugten Binaries ist, sollte jedem klar sein.

von Cyblord -. (cyblord)


Lesenswert?

Jörg W. schrieb:
> Dass ein Helloworld kein sinnvoller Benchmark für die Größe eines
> erzeugten Binaries ist, sollte jedem klar sein.

Warum das? Es gibt immerhin mal eine untere Grenze für die Binary Größe 
an.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Also ist die Standard Library für Rust nur bloat im Gegensatz zu der von
> C?

Nein.
Aber sie ist per default statisch gelinkt. Unter C ist sie per default 
dynamisch gelinkt. Guck dir mal an, wie groß eine libc .so/.dll ist.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Warum das? Es gibt immerhin mal eine untere Grenze für die Binary Größe
> an.

Weil es völlig egal ist, ob das 1 kB, 10 kB oder ein paar 100 kB sind, 
seit niemand mehr mit Disketten arbeitet.
Aber so kannst die Rust stdlib gerne dynamisch linken, wenn dich das 
stört.
Es ist halt (noch) nicht die Standardeinstellung, weil das ABI (noch) 
nicht stabil ist.

von Oliver R. (Gast)


Lesenswert?

Cyblord -. schrieb:
> Warum hat ein C Programm unter Windows
> nicht die gleichen Probleme?

Z.B. weil Rust einen Panic-Handler verwendet, während ein C Programm 
sich im Fall eines Absturzes einfach nur beendet.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Weil es völlig egal ist, ob das 1 kB, 10 kB oder ein paar 100 kB sind,

Genau DAS ist eben die fatale Einstellung der Rusties.

Ich denke Rust hat fertig. Rust kann gehen.

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


Lesenswert?

Cyblord -. schrieb:
>> Dass ein Helloworld kein sinnvoller Benchmark für die Größe eines
>> erzeugten Binaries ist, sollte jedem klar sein.
>
> Warum das?

Weil es nichts sinnvolles macht.

> Es gibt immerhin mal eine untere Grenze für die Binary Größe an.

Nein, falls da wirklich printf drin ist (meist wird es der Compiler 
rauskicken), dann bläht das auch schon auf. Die untere Grenze wäre
1
int main(void) {
2
  return 0;
3
}

MaWin schrieb:
> Aber sie ist per default statisch gelinkt.

Siehe oben, das allein erklärt das nicht. Auch bei statischem Linken 
wird aus einer Bibliothek nur rausgezogen, was benötigt wird.

Es erscheint mir auch nach all den Beschreibungen über die Features von 
Rust völlig logisch, dass da etwas mehr an Laufzeitsystem dahinter 
steckt. Alle diese Überprüfungen, die nicht schon der Compiler machen 
kann, müssen ja schließlich irgendwo stecken. Das ist bei FORTRAN oder 
Pascal nicht anders.

Komplett statisches Linken von Rust-Binaries scheint aber schon einiges 
an Aufwand zu sein, sonst hätte ich den Vergleich mal probiert. (Das 
zuweilen dokumentierte -C target-feature=+crt-static generiert trotzdem 
noch ein dynamisch gelinktes Binary, weil die Systembibliotheken 
dynamisch bleiben.)

von MaWin O. (mawin_original)


Lesenswert?

Jörg W. schrieb:
> Leuchtet allerdings dahingehend nicht ein, dass aus einer Library nur
> die Dinge gelinkt werden sollten, die auch tatsächlich benötigt werden.

Kannst gerne dran arbeiten, wenn es dich so stört.
Die Arbeit wird gerne angenommen.

Tipp: Auf Embedded-Rust ist das natürlich auch genau so, weil dort die 
stdlib im (LTO-)Build direkt mitgebaut wird statt dazugelinkt wird.
Das ist dann tatsächlich noch optimaler, als der C-Ansatz mit 
Link-Elision auf Funktionsbasis.

> Es werden wohl eher Dinge wie ein Laufzeitsystem sein, die das
> aufblähen.

Jörg wieder einmal wild am spekulieren.
Was soll das denn für ein Laufzeitsystem sein?

von Cyblord -. (cyblord)


Lesenswert?

Oliver R. schrieb:
> Cyblord -. schrieb:
>> Warum hat ein C Programm unter Windows
>> nicht die gleichen Probleme?
>
> Z.B. weil Rust einen Panic-Handler verwendet, während ein C Programm
> sich im Fall eines Absturzes einfach nur beendet.

Ja und? Will ich jetzt aber nicht haben. Muss ich aber drin haben? 
Super.

Ich stelle mir das schon vor:
"Also Chef, wir brauchen den größeren und teureren Controller, weil Rust 
hat den Panic Handler immer mit drin. Was der bringt? Bei uns gar 
nichts. Ja ist halt trotzdem drin. Ok machen wir das Produkt teuer. Die 
Kunden haben ja auch was davon. Was genau? Äh Ich muss weg."

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


Lesenswert?

MaWin O. schrieb:
> Jörg W. schrieb:
>> Leuchtet allerdings dahingehend nicht ein, dass aus einer Library nur
>> die Dinge gelinkt werden sollten, die auch tatsächlich benötigt werden.
>
> Kannst gerne dran arbeiten, wenn es dich so stört.

Das Verhalten, aus einer Library nur das rauszuziehen, was benötigt 
wird, hat nichts mit der Sprache zu tun, sondern ist eine Eigenschaft 
des Linkers.

> Was soll das denn für ein Laufzeitsystem sein?

Ich dachte, dass du mir das erklären kannst.

Oliver R. hat ja zumindest einen Punkt gebracht, der in diese Richtung 
passt.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Ja und? Will ich jetzt aber nicht haben. Muss ich aber drin haben?

Nein.
Du kannst es soweit reduzieren, dass es nur ein abort()-Aufruf ist.
Deine Entscheidung.

von MaWin O. (mawin_original)


Lesenswert?

Jörg W. schrieb:
> Ich dachte, dass du mir das erklären kannst.

Naja, du spekulierst hier wild herum über etwas, das es so nicht gibt.

von Oliver R. (Gast)


Lesenswert?

Cyblord -. schrieb:
> Ja und? Will ich jetzt aber nicht haben. Muss ich aber drin haben?
> Super.

Du hast von Windows geredet. Da ist der standardmässig drin.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
> Nein.
> Du kannst es soweit reduzieren, dass es nur ein abort()-Aufruf ist.
> Deine Entscheidung.

Ah wieder mal was per default drin was kacke ist. I see.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Ah wieder mal was per default drin was kacke ist. I see.

Es ist kacke ein Programm bei einem fatalen Problem vernünftig zu 
beenden und eine vernünftige Fehlermeldung auszugeben?
Verstehe.

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


Lesenswert?

MaWin O. schrieb:
> Cyblord -. schrieb:
>> Ja und? Will ich jetzt aber nicht haben. Muss ich aber drin haben?
>
> Nein.
> Du kannst es soweit reduzieren, dass es nur ein abort()-Aufruf ist.
> Deine Entscheidung.

Dann zeig doch bitte mal, wie diese "deine Entscheidung" praktisch 
aussieht.

Das (primitive) Codebeispiel ist oben. copy&paste einfach mal die 
nötigen Compileroptionen und das Ergebnis (wieder als Ausgabe von 
"size"). Das überzeugt deutlich mehr als eine wortreiche Erklärung "kann 
man doch alles abschalten". Bitte schalte es mal ab.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:

> Es ist kacke ein Programm bei einem fatalen Problem vernünftig zu
> beenden und eine vernünftige Fehlermeldung auszugeben?
> Verstehe.

In den meisten Fällen bringt dir das gar nichts. Das Gerät geht halt 
nicht mehr. Egal welche Handler da angesprungen oder nicht angesprungen 
werden.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

Jörg W. schrieb:
> Dann zeig doch bitte mal, wie diese "deine Entscheidung" praktisch
> aussieht.

Ach komm. Ist Google tatsächlich kaputt?
Das ist doch lächerlich.

Ich suche es jetzt garantiert nicht extra für dich raus, aber man muss 
ins Cargo.toml sowas wie panic=abort schreiben. Genauer habe ich es 
jetzt nicht im Kopf.

Cyblord -. schrieb:
> In den meisten Fällen bringt dir das gar nichts. Das Gerät geht halt
> nicht mehr. Egal welche Handler da angesprungen oder nicht angesprungen
> werden.

Genau deshalb schaltet man diesen Handler auf Embedded ja auch ab.
Wo ist eigentlich dein Problem?

von Le X. (lex_91)


Lesenswert?

Gibt es bei Rust für Embedded-Architekturen nicht irgendsowas wie 
-ffreestanding? Oder irgendwas um Teile der Laufzeitumgebung nicht 
mitzulinken?

Auf dem PC sind 3Mb Laufzeitgedöns vernachlässigbar (gesetzt dem Fall 
dass es nicht mitwächst und ein 100Mb-Exectuable auch nur 3Mb Bloat drin 
hat).
Embedded sind diese 3Mb natürlich ein NoGo.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

Le X. schrieb:
> Gibt es bei Rust für Embedded-Architekturen nicht irgendsowas wie
> -ffreestanding? Oder irgendwas um Teile der Laufzeitumgebung nicht
> mitzulinken?

Selbstverständlich. Nennt sich

#![no_std]

Wurde natürlich auch schon gesagt.

Le X. schrieb:
> Embedded sind diese 3Mb natürlich ein NoGo.

Gegebene Antworten hier nicht so lesen ist für mich ein NoGo.
Ich wiederhole das jetzt nicht.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:

> Ach komm. Ist Google tatsächlich kaputt?
> Das ist doch lächerlich.

Ja, warum muss man ständig deine kruden Behauptungen selber googlen? 
Belege sie selbst oder nehme sie zurück.

> Ich suche es jetzt garantiert nicht extra für dich raus, aber man muss
> ins Cargo.toml sowas wie panic=abort schreiben. Genauer habe ich es
> jetzt nicht im Kopf.

Ja klar. Ist sicher echt trivial.

> Genau deshalb schaltet man diesen Handler auf Embedded ja auch ab.
> Wo ist eigentlich dein Problem?

Dass die Beispiele ständig zeigen dass es nicht brauchbar ist und du 
ständig behauptest man könne das alles auch anders haben, aber den 
Beweis schuldig bleibst und auf google verweist.
Argumentativ noch nackiger kann man sich ja nicht mehr machen als du 
hier gerade.

von Oliver R. (Gast)


Lesenswert?

Le X. schrieb:
> Gibt es bei Rust für Embedded-Architekturen nicht irgendsowas wie
> -ffreestanding? Oder irgendwas um Teile der Laufzeitumgebung nicht
> mitzulinken?

Das ist bei Rust "no-std", da wird nichts dazugelinkt und auch der Panic 
Handler muss explizit definiert werden.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Belege sie selbst oder nehme sie zurück.

Ich werde weder das eine, noch das andere tun.
Stirb doch einfach dumm, Cyblord. Wie wäre das?

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
> Stirb doch einfach dumm, Cyblord. Wie wäre das?

Solange ich ohne Rust sterben darf ist alles ok.

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


Lesenswert?

MaWin O. schrieb:
> Jörg W. schrieb:
>> Dann zeig doch bitte mal, wie diese "deine Entscheidung" praktisch
>> aussieht.
>
> Ach komm. Ist Google tatsächlich kaputt?

Ich habe auch nicht auf Google verwiesen, sondern Beispiele gezeigt, die 
man per copy&paste nachvollziehen kann.

Aber lass man, helfen oder gar jemanden überzeugen willst du offenbar 
nicht.

von MaWin O. (mawin_original)


Lesenswert?

Jörg W. schrieb:
> jemanden überzeugen willst du offenbar nicht.

Ganz gut erkannt.
Wenn du es nicht nutzen willst - und das willst du ganz offensichtlich 
nicht - dann lasse es halt.
Kein Problem.

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


Lesenswert?

MaWin O. schrieb:
> Ganz gut erkannt.
> Wenn du es nicht nutzen willst - und das willst du ganz offensichtlich
> nicht - dann lasse es halt.

Ich will es derzeit nicht nutzen (weil ich aktuell schlicht keine 
Anwendung für sowas habe). Ich mache aktuell auch bspw. kein C++.

Deshalb stecke ich jetzt auch keinen Aufwand da rein, aber es täte mich 
interessieren, und wenn ich das mal irgendwo gesehen habe, speichere ich 
mir solche Tricks gedanklich ab. Deshalb wäre ich daran interessiert, 
von jemandem, der damit täglich umgeht (und daher schneller ist als 
ich), sowas zu erfahren.

Von dir also offenbar nicht, dann lass es. Ich werde wohl lieber zu 
gegebener Zeit meinen Sohn danach fragen, das dürfte ergiebiger sein als 
so einen Sturkopf wie dich.

Sorry, musste mal raus.

von MaWin O. (mawin_original)


Lesenswert?

Jörg W. schrieb:
> Deshalb stecke ich jetzt auch keinen Aufwand da rein

Ja, das merke ich.
Das ist natürlich sehr klug mir den Aufwand aufzubürden und mich die 
Dokumentation durchsuchen zu lassen.
Nur tue ich das nicht.

> Deshalb wäre ich daran interessiert,
> von jemandem, der damit täglich umgeht (und daher schneller ist als
> ich), sowas zu erfahren.

Ich habe dir alle Stichworte geliefert, mit denen du es findest.
Der Rest liegt an dir.

> das dürfte ergiebiger sein als so einen Sturkopf wie dich.

Du bist ein ziemlich unverschämter Mensch, der direkt bockig wird, wenn 
andere Leute nicht nach deiner Pfeife tanzen.

Damit musst du leider leben.

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


Lesenswert?

MaWin O. schrieb:
> Das ist natürlich sehr klug mir den Aufwand aufzubürden und mich die
> Dokumentation durchsuchen zu lassen.

Nun, du hast behauptet, dass du das schon gemacht hast, insofern nahm 
ich an, dass du nicht erst Google bemühen musst. Da lag ich wohl falsch.

Wenn ich ansonsten genauso "bockig" wäre, wie du das behauptest, glaubst 
du, ich würde hier alle nasenlang Leuten bei den Problemen helfen, bei 
denen ich mich gut auskenne?

von Wilhelm M. (wimalopaan)


Lesenswert?

Bei mir ergibt das Rust HelloWorld Beispiel:
1
$ size hello
2
text    data     bss     dec     hex filename
3
1780     616       8    2404     964 hello

Das C++ Beispiel ist unwesentlich kleiner:
1
$ size hellocc
2
text    data     bss     dec     hex filename
3
1046     608       8    1662     67e hellocc

Beides dynamisch gelinkt.

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


Lesenswert?

Wilhelm M. schrieb:
> Bei mir ergibt das Rust HelloWorld Beispiel:

Das sieht doch gut aus.

Kannst du jetzt noch die Build-Optionen dafür posten?

von MaWin O. (mawin_original)


Lesenswert?

Jörg W. schrieb:
> Nun, du hast behauptet, dass du das schon gemacht hast, insofern nahm
> ich an, dass du nicht erst Google bemühen musst.

Richtig. Und ich habe ganz genau beschrieben, was ich gemacht habe und 
was ich noch im Kopf wusste.
Wo ist eigentlich dein Problem?
Statt hier mit mir zu diskutieren, hättest du schon lange "panic=abort" 
in Google eingeben können.
Das wäre vermutlich zu einfach gewesen.

von Wilhelm M. (wimalopaan)


Lesenswert?

Jörg W. schrieb:
> Wilhelm M. schrieb:
>> Bei mir ergibt das Rust HelloWorld Beispiel:
>
> Das sieht doch gut aus.
>
> Kannst du jetzt noch die Build-Optionen dafür posten?
1
rustc -C opt-level=z -C strip=symbols -C prefer-dynamic=yes hello.rs

Aber das haben die Rust-Experten hier ja sicher alles gewusst ;-)

Und statisch ist Rust und C++ auch wieder vergleichbar.

: Bearbeitet durch User
von Oliver R. (Gast)


Lesenswert?

Weil hier nach Beispielen für STM32 gefragt wurde ein, hier ein 
typisches "Blinky":

https://gitlab.com/jounathaen-projects/embedded-rust/blinky-rust

Ergibt als Release Build
1
   text     data      bss      dec      hex  filename
2
    820        0        4      824      338  blinky-rust

von Dergute W. (derguteweka)


Lesenswert?

Moin,

OK, damit kommt dann bei mir, wenn man sich das executable mittels ldd 
anguckt, noch eine weitere shared-lib dazu, die dann halt den Krempel, 
der vorher das binary so aufgeblasen hat, beinhalten wird. Bei so einem 
genialen Namen wie dann hier dafuer verwendet wird, freu' ich mich schon 
arg auf interoperabilitaet.
Achja: Neben den ganzen lustigen, aber scheint's wohl etwas 
platzfressenden Gimmicks von rust wird natuerlich in allen Faellen 
immernoch zusaetzlich die libc gebraucht...
1
ldd hello
2
  linux-vdso.so.1 (0x00007ffe60353000)
3
  libstd-b5176101f2c4a3c2.so => /opt/rustc/lib/libstd-b5176101f2c4a3c2.so (0x00007f9a9bbac000)
4
  libc.so.6 => /usr/lib/libc.so.6 (0x00007f9a9b9aa000)
5
  libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f9a9b990000)
6
  /lib64/ld-linux-x86-64.so.2 (0x00007f9a9bd6a000)

Gruss
WK

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


Lesenswert?

Wilhelm M. schrieb:
> Und statisch ist Rust und C++ auch wieder vergleichbar.

Hast du denn Rust statisch bekommen? Ich nicht, libc war trotzdem noch 
dynamisch, und das Netz verweist auf MUSL (oder so ähnlich).

von MaWin O. (mawin_original)


Lesenswert?

Dergute W. schrieb:
> Bei so einem
> genialen Namen wie dann hier dafuer verwendet wird, freu' ich mich schon
> arg auf interoperabilitaet.

Und deine konkrete Kritik ist jetzt was?

> von rust wird natuerlich in allen Faellen
> immernoch zusaetzlich die libc gebraucht...

Selbstverständlich nicht.
Aber das wurde hier mehrfach erklärt. Auch heute noch einmal. Deshalb 
wiederhole ich das jetzt nicht noch einmal.

Auf einem PC ist die libc halt de-facto die Schnittstelle zum 
Betriebsystem. Auf Windows ganz offiziell und auf Linux praktisch auch. 
Direkte Syscalls macht niemand.
Wenn man kein OS hat, dann braucht man die libc selbstverständlich 
nicht.
(Auf AVR braucht man sie derzeit nur, weil sie noch niemand rausgeworfen 
hat und die paar benötigten Features in Rust neuimplementiert hat.).

von Wilhelm M. (wimalopaan)


Lesenswert?

Dergute W. schrieb:
> OK, damit kommt dann bei mir, wenn man sich das executable mittels ldd
> anguckt, noch eine weitere shared-lib dazu, die dann halt den Krempel,
> der vorher das binary so aufgeblasen hat, beinhalten wird.

Das ist bei C++ auch so (und auch bei anderen Sprachen außer C). Nur C 
kommt (fast) nur mit der C-Lib aus.

Alles andere braucht auch die C-Lib, weil das auf den meisten Systemen 
das POSIX-API realisiert. Daher auch bei einem Rust executable.

von Wilhelm M. (wimalopaan)


Lesenswert?

Jörg W. schrieb:
> Wilhelm M. schrieb:
>> Und statisch ist Rust und C++ auch wieder vergleichbar.
>
> Hast du denn Rust statisch bekommen? Ich nicht, libc war trotzdem noch
> dynamisch, und das Netz verweist auf MUSL (oder so ähnlich).

Nicht vollständig wie bei C / C++ / ....
Das bezieht sich bei Rust nur auf die Bib von Rust selbst. Aber ich bin 
kein Rust Experte ...

Wenn ich mir ein
1
nm hello

ansehe, dann weiß ich auch, warm das dann so groß ist ;-)

: Bearbeitet durch User
von Dergute W. (derguteweka)


Lesenswert?

Moin,

MaWin O. schrieb:
> Dergute W. schrieb:
>> Bei so einem
>> genialen Namen wie dann hier dafuer verwendet wird, freu' ich mich schon
>> arg auf interoperabilitaet.
>
> Und deine konkrete Kritik ist jetzt was?
Keine Kritik - ich schrieb doch: ich freue mich... :-)

> Aber das wurde hier mehrfach erklärt. Auch heute noch einmal. Deshalb
> wiederhole ich das jetzt nicht noch einmal.
Tschuldigung, ich bin da halt etwas begriffstutzig.

> Auf einem PC ist die libc halt de-facto die Schnittstelle zum
> Betriebsystem. Auf Windows ganz offiziell und auf Linux praktisch auch.
> Direkte Syscalls macht niemand.
> Wenn man kein OS hat, dann braucht man die libc selbstverständlich
> nicht.
> (Auf AVR braucht man sie derzeit nur, weil sie noch niemand rausgeworfen
> hat und die paar benötigten Features in Rust neuimplementiert hat.).
Axo. Selbstverstaendlich.
Wie kam ich nur auf das schmale Brett, das bei dem sicheren Rust 
vielleicht auch der ganze "unsichere, in boesem C geschriebene" Unterbau 
durch was eigenes, viel geileres, sichereres ersetzt worden haette sein 
koennen. Von der Groesse der "Rust-Laufzeitumgebung" vielleicht? 
Neeeein, ist sicher nur, weil ich halt so'n bissl langsamer im Denken 
bin.

Gruss
WK

von MaWin O. (mawin_original)


Lesenswert?

Dergute W. schrieb:
> Neeeein, ist sicher nur, weil ich halt so'n bissl langsamer im Denken
> bin.

Gut erkannt.

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> 307914 vs 1839.
>
> Damit hat sich die Frage nach Rust für Embedded sowieso bereits
> erledigt. Wie schon vermutet, alles ein Phänomen im PC Bereich. Wo bei
> Speicher und Co. alles egal ist.
> Wie soll man mit so einem Footprint C für den Microcontrollerbereich mit
> wenigen MB oder gar kB Flash ablösen? Utopie trifft Wahnvorstellung.

das liegt primär daran das Rust die Standardlib statisch linked - auf 
embedded sieht das ganz ganz anders aus

btw: du wolltest noch erklären warum das Iterator-Konzept ein No-go für 
embedded ist, hast du jetzt Zeit gefunden dir das zu überlegen?

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


Lesenswert?

cppbert schrieb:
> du wolltest noch erklären warum das Iterator-Konzept ein No-go für
> embedded ist

:-))

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


Lesenswert?

cppbert schrieb:
> das liegt primär daran das Rust die Standardlib statisch linked - auf
> embedded sieht das ganz ganz anders aus

Naja: dort wird alles statisch gelinkt (zumindest auf MCUs - auf MPUs 
läuft ja eher ein reguläres OS).

von MaWin O. (mawin_original)


Lesenswert?

Jörg W. schrieb:
> Naja: dort wird alles statisch gelinkt

Es ist trotzdem ein Unterschied, weil bei Rust Embedded (beim normalen 
Arbeiten mit Cargo) die stdlib nicht vorkompiliert ist. Sie nimmt Teil 
an dem einen Gesamtbuild mit dem einen LTO.

Geht natürlich auch anders, wenn man will, aber sinnvoll ist es allemal 
das Gesamtkonstrukt zu optimieren und dann nichts mehr hinzu zu linken.

von cppbert (Gast)


Lesenswert?

Niemand hat gesagt das Rust und die komplette Tool-Chain 100% ausgereift 
ist, es geht hier (nach meiner Meinung) primär um die Sprache selbst

und wenn die GCC Leute ihr eigenes Frontend bauen sieht es da auch ganz 
anders aus und falls Microsoft dann noch hinterher hüpft mit Rust# (ich 
hoffe nicht) sieht es nochmal anders aus

von MaWin O. (mawin_original)


Lesenswert?

cppbert schrieb:
> Niemand hat gesagt das Rust und die komplette Tool-Chain 100% ausgereift
> ist

Das genügt den µC.net-Ansprüchen aber nicht.
Es muss alles perfekt sein. Erst dann kann die bekanntlich perfekte 
Sprache C abgelöst werden.
Da werden keinerlei Kompromisse eingegangen. :)

Außer bei den eigenen Kenntnissen. Da werden Kompromisse eingegangen bis 
hin zur völligen Abwesenheit.

> es geht hier (nach meiner Meinung) primär um die Sprache selbst

Ich finde es schon wichtig auch zu zeigen, dass zum Beispiel das 
Standard-Buildsystem Cargo praktisch allen anderen Buildsystemen 
haushoch überlegen ist.

Es funktioniert einfach sehr gut.
Selbstverständlich liegt das auch daran, dass es perfekt auf Rust und 
seinen Compiler zugeschnitten ist. Das ist klar.

cppbert schrieb:
> und wenn die GCC Leute ihr eigenes Frontend bauen sieht es da auch ganz
> anders aus

Ich denke nicht, dass es ganz anders aussieht.
Aber sicher wird man Aspekte der Sprache finden, über die sich bisher 
formell noch niemand Gedanken gemacht hat und die einfach so sind, weil 
rustc sie so implementiert. Das ist ja bereits so passiert und wird auch 
noch ein paar mal passieren.
Das führt aber dazu, dass die Sprache als Ganzes noch besser wird. 
Deshalb sind sowohl gccrs als auch codegen-gcc ganz wichtige Projekte.
Die Geschichte hat uns gelehrt, dass erst LLVM/clang wieder Leben in die 
damals völlig festgerostete gcc-Entwicklung gebracht hat.

von MaWin O. (mawin_original)


Lesenswert?

> Announcing Rust 1.66.0

https://blog.rust-lang.org/2022/12/15/Rust-1.66.0.html

> Explicit discriminants on enums with fields

Ist manchmal ganz nützlich z.B. in Parsern oder Protokollinterpretern.
Jetzt auch mit komplexen enums.

> core::hint::black_box

Könnte nützlich sein für Embedded-Entwicklung.
Da ist tatsächlich oft das "Problem", dass es einem den Code komplett 
wegoptimiert, wenn man ihn nirgendwo verwendet. z.B. wenn man nur mal 
kurz schauen will, zu welchem Assembly ein Stück Code generiert war es 
oft notwendig die Ein- und Ausgaben zu diesem Code irgendwie über 
volatile-Zugriffe zu machen.
Das hier vereinfacht das sicher enorm.

> checked signed+unsigned operations

Das ist tatsächlich sehr nützlich und wird einige Programmteile deutlich 
verkürzen.
Rust verbietet normalerweise Operationen zwischen verschiedenen Typen. 
Deshalb muss man Typen konvertieren und dann natürlich Überlaufprüfungen 
usw. machen. Es gibt aber einige Funktionen, die einige dieser gängigen 
Operationen erleichtern und gleichzeitig safe halten.

> You can now use ..=X ranges in patterns.

Jo das ist gut. Weiß gar nicht, warum das so lange nicht stabil war :)

von cppbert (Gast)


Lesenswert?

MaWin O. schrieb:
> Ich finde es schon wichtig auch zu zeigen, dass zum Beispiel das
> Standard-Buildsystem Cargo praktisch allen anderen Buildsystemen
> haushoch überlegen ist.

das gehört für mich zu der "Sprache" dazu - ist ja auch ein Konzept

Es wird sich zeigen wie die integration in GCC sein wird - nur Rust als 
Sprache oder auch gccrs_cargo als weitere Implementation

ich meinte beim Bezug zum GCC auch nur das dort das Linken usw. 
default-Verhalten nicht unbedingt so sein muss wie beim Referenz-System 
rustc usw.

von MaWin O. (mawin_original)


Lesenswert?

cppbert schrieb:
> ich meinte beim Bezug zum GCC auch nur das dort das Linken usw.
> default-Verhalten nicht unbedingt so sein muss wie beim Referenz-System
> rustc usw.

Achso. Ja.
Das Linken hat natürlich gar nichts mit rustc zu tun. Auch heute nicht. 
Das ist wie Cargo die Toolchain bedient. Deshalb denke ich aber schon, 
dass sich das nicht grundsätzlich unterscheiden wird. Jedenfalls nicht 
mehr, als es sich bei gcc vs clang unterscheidet.

von cppbert (Gast)


Lesenswert?

MaWin O. schrieb:
> Achso. Ja.
> Das Linken hat natürlich gar nichts mit rustc zu tun. Auch heute nicht.
> Das ist wie Cargo die Toolchain bedient.

und dann landet das auch auch schön in cygwin oder mingw, msys2 und rbx 
ist gleich wieder froh :)

von Oliver R. (Gast)


Lesenswert?

cppbert schrieb:
> Es wird sich zeigen wie die integration in GCC sein wird - nur Rust als
> Sprache oder auch gccrs_cargo als weitere Implementation

cargo dürfte eigentlich nur den Compileraufruf wrappen. Ob das dann 
gcc-rs anstelle von rustc ist, sollte nicht die entscheidende Rolle 
spielen. Flags und Optionen müssen natürlich ggfs. angepasst werden.

von Nano (Gast)


Angehängte Dateien:

Lesenswert?

Jörg W. schrieb:
>
1
> ...
2
> $ rustc -O helloworld.rs
3
> ...
4
> $ size helloworld
5
>     text    data   bss      dec       hex   filename
6
>   307914   12864   273   321051   0x4e61b   helloworld
7
>
> OK, Gegentest:
>
1
> ...
2
> $ cc -O -o helloworld helloworld.c
3
> ...
4
> $ size helloworld
5
>   text   data   bss    dec     hex   filename
6
>   1839    409     8   2256   0x8d0   helloworld
7
>
> Gut, etwas kleiner. :-)
>
1
> ...
2
> $ c++ -O -o helloworld helloworld.cc
3
> ...
4
> $ size helloworld
5
>   text   data   bss    dec      hex   filename
6
>   4997    649   192   5838   0x16ce   helloworld
7
>
> Aber so ist das mit Trivialbeispielen, sie sind völlig unrepräsentativ
> für die reale Welt.

C ist immer noch total fett, wenn man es mit Assembler vergleicht.

Hier bei mir braucht ein einfaches "Hello World!" in Rust 297208 Bytes.

Meine Version in Assembler unter DOS braucht 87 Bytes.

Gut, das ist ein 16 Bit REAL MODE Programm, aber meine 64 Bit Rust 
Version und deine C und C++ Binaries sind immer noch um ein Vielfaches 
größer.

Das OS ist ein anderes und es sind 64 Bit Binaries, aber selbst wenn man 
bedenkt, dass die Binaries nicht statisch gelinkt sind und das printf 
von libc in der libc auch noch Platz braucht, ist das ziemlich viel 
Platz, was da benötigt wird.

Die NASM Version unter Linux braucht mit nur 50 Bytes sogar noch weniger 
Bytes. Das könnte allerdings am SYSCALL liegen, d.h. der Kernel macht 
hier mehr und weil die Segmente wegfallen.

von Nano (Gast)


Lesenswert?

MaWin schrieb:
> Cyblord -. schrieb:
>> Warum das? Es gibt immerhin mal eine untere Grenze für die Binary Größe
>> an.
>
> Weil es völlig egal ist, ob das 1 kB, 10 kB oder ein paar 100 kB sind,
> seit niemand mehr mit Disketten arbeitet.

Wenn das komplette Programm in den L1 Cache der CPU passt, macht das 
schon etwas aus, wenn es performancekritisch ist.

Der Intel Tiger Lake hat nur einen L1 Cache von 48 KiB für Daten und 32 
KiB für Befehle. Da sind 100 KiB schon zu groß.

von MaWin O. (mawin_original)


Lesenswert?

Nano schrieb:
> Wenn das komplette Programm in den L1 Cache der CPU passt, macht das
> schon etwas aus, wenn es performancekritisch ist.

Wer kennt sie nicht, die performancekritischen Hello-World-Programme.

Außerdem: Lies mal nach, was Dateigröße, Sectiongröße und RAM-Belegung 
unterscheidet.
Es ist nicht mehr DOS.

Du fragst: Wo soll ich das lesen? Wo soll ich mich weiterbilden?
Die Antwort wird dich total überraschen: Hier im Thread! Heute!

von Nano (Gast)


Lesenswert?

MaWin O. schrieb:
> Nano schrieb:
>> Wenn das komplette Programm in den L1 Cache der CPU passt, macht das
>> schon etwas aus, wenn es performancekritisch ist.
>
> Wer kennt sie nicht, die performancekritischen Hello-World-Programme.

Mein Supergirl hat nunmal hohe Ansprüche an eine schnelle 
Bildschirmausgabe.

>
> Außerdem: Lies mal nach, was Dateigröße, Sectiongröße und RAM-Belegung
> unterscheidet.

Nö, das weiß ich. Wenn du das binary strippst, dann unterscheidet sich 
die ls Ausgabe nicht mehr groß von size.

> Du fragst: Wo soll ich das lesen? Wo soll ich mich weiterbilden?

Ich habe gar nichts derartiges gefragt.

von MaWin O. (mawin_original)


Lesenswert?

Nano schrieb:
> Nö, das weiß ich. Wenn du das binary strippst, dann unterscheidet sich
> die ls Ausgabe nicht mehr groß von size.

Besser doch noch einmal hier nachlesen und sich weiterbilden.

von Nano (Gast)


Lesenswert?

MaWin O. schrieb:
> Nano schrieb:
>> Nö, das weiß ich. Wenn du das binary strippst, dann unterscheidet sich
>> die ls Ausgabe nicht mehr groß von size.
>
> Besser doch noch einmal hier nachlesen und sich weiterbilden.

Wie ich bereits sagte, muss ich das nicht, da ich das schon weiß.

Dein Problem ist, dass du Fakten nicht als gegeben hinnehmen willst. 
Wenn jemand Fakten liefert, dann greifst du die Person persönlich an. 
Such dir also mal einen Psychologen.

von MaWin O. (mawin_original)


Lesenswert?

Nano schrieb:
> Wie ich bereits sagte, muss ich das nicht, da ich das schon weiß.

Anscheinend ja nicht.

> Dein Problem ist, dass du Fakten nicht als gegeben hinnehmen willst.
> Wenn jemand Fakten liefert, dann greifst du die Person persönlich an.

Bitte einmal ein vollständiges Zitat liefern, wo ich das getan habe. Und 
zwar nicht als Reaktion auf einen vorhergehenden persönlichen Angriff 
(wie heute von unserem Herrn Moderator).
Danke.

von Nano (Gast)


Lesenswert?

MaWin O. schrieb:
> Nano schrieb:
>> Wie ich bereits sagte, muss ich das nicht, da ich das schon weiß.
>
> Anscheinend ja nicht.
>
>> Dein Problem ist, dass du Fakten nicht als gegeben hinnehmen willst.
>> Wenn jemand Fakten liefert, dann greifst du die Person persönlich an.
>
> Bitte einmal ein vollständiges Zitat liefern, wo ich das getan habe. Und
> zwar nicht als Reaktion auf einen vorhergehenden persönlichen Angriff

Hier Z.B.
> Anscheinend ja nicht.

Du unterstellst mir Dinge, die 1. nicht stimmen und 2. obwohl du keine 
Ahnung über mich hast und 3. es völlig am Thema vorbei geht, ich scheine 
dir wohl wichtig zu sein.

Dich stört der Fakt, dass Assemblerprogramme kleiner sind als C oder 
Rust Programme. Denn mehr als eine wertfreie Aussage dazu inkl. 
Lieferung eines Beweises habe ich nicht gesagt. Das könnte man jetzt als 
so gegeben hinnehmen und fertig.
Aber du kochst rot vor Wut, weil ich es gewagt habe, das einfach mal 
wertfrei und objektiv an das schwarze Brett zu hängen, damit es jeder 
lesen kann. Sprich, du hast Komplexe und noch ganz andere Probleme, komm 
mal klar.

von Nano (Gast)


Lesenswert?

Noch eine Ergänzung als Auflösung für dich.

Ich habe ls anstatt size benutzt, weil es beim strippen relativ egal ist 
und ich ls aus reiner Gewohnheit verwende und es ausreichend gut ist.
Und meine Screenshots sind älter, als mein Lesen des Kommentars von 
Jörg, der dich darauf hingewiesen hat, dass man size zum messen 
verwenden soll:
Beitrag "Re: Rust - ist das hier um zu bleiben?"

Und jetzt nörgelst du daran herum, weil du streiten willst. Siehe dazu 
mein vorheriges Kommentar, ich kann mich da nur wiederholen, komm mal 
klar.

von MaWin O. (mawin_original)


Lesenswert?

Nano schrieb:
>> Anscheinend ja nicht.
> Du unterstellst mir Dinge

Du solltest einmal nachschlagen, was das Wort "anscheinend" bedeutet.

> Dich stört der Fakt, dass Assemblerprogramme kleiner sind als C oder
> Rust Programme.

Völliger Unsinn.

> Das könnte man jetzt als so gegeben hinnehmen und fertig.

Und warum tust du das dann nicht?

> Aber du kochst rot vor Wut

Ach? Habe ich gar nicht gemerkt.

> das einfach mal
> wertfrei und objektiv an das schwarze Brett zu hängen

Und für meine Antwort auf deinen Beitrag gelten diese Grundsätze nicht?

> Sprich, du hast Komplexe und noch ganz andere Probleme, komm
> mal klar.

Hm ja. Danke, Herr Psychologe, der auch sagt:

Nano schrieb:
> dann greifst du die Person persönlich an.

Aber du scheinst mich ja ziemlich gut zu kennen, denn

> Und jetzt nörgelst du daran herum, weil du streiten willst.

Du scheinst ein sehr angenehmer Zeitgenosse zu sein.

von Nano (Gast)


Lesenswert?

MaWin O. schrieb:
> Bla bla bla

von MaWin O. (mawin_original)


Lesenswert?

Nano schrieb:
>> Bla bla bla

Ganz schön wertfrei und objektiv, deine Antwort.
Danke dafür.

von Nano (Gast)


Lesenswert?

MaWin O. schrieb:
> Nano schrieb:
>>> Bla bla bla
>
> Ganz schön wertfrei und objektiv, deine Antwort.
> Danke dafür.

Ich habe nicht geantwortet, ich habe lediglich dein Geschwurbel in 3 
Wörtern zusammengefasst.

von MaWin (Gast)


Lesenswert?

Nano schrieb:
> Ich habe nicht geantwortet, ich habe lediglich dein Geschwurbel in 3
> Wörtern zusammengefasst.

Also:

Nano schrieb:
> Wenn jemand Fakten liefert, dann greifst du die Person persönlich an.
> Such dir also mal einen Psychologen.

von cppbert (Gast)


Lesenswert?

@Nano

MaWin hat es lediglich versäumt dir zu erklären das dein Assembler 
Beispiel dank Syscall nutzung völlig sinnfrei ist um irgendwelche 
Größenvergleiche zu betreiben - spätestens bei DOS geschwurbel wurde 
klar das es dir irgendwie nur darum geht ein wenig Technik zu schnattern

und jetzt hört bitte auf euch anzuzicken

von rbx (Gast)


Lesenswert?

cppbert schrieb:
> und dann landet das auch auch schön in cygwin oder mingw, msys2 und rbx
> ist gleich wieder froh :)

Naja, nicht nur ich..
https://stackoverflow.com/questions/55603111/unable-to-compile-rust-hello-world-on-windows-linker-link-exe-not-found

Ich hatte bei der Seite mit den "Standalone" Downloads die falschen 
Versionen heruntergeladen und installiert.

("rust-1.65.0-aarch64-pc-windows-msvc.msi")

Jetzt habe ich eine Version heruntergeladen und installiert, die heißt 
"rust-nightly-i686-pc-windows-msvc.msi".

Stunden später..

Installation OK, Pfadeinträge OK, rustc trallalla.rs..

>
>dir
..

trallalla.rs
>

wo ist meine exe??

Wie in Linux: keine Nachricht ist eine gute Nachricht?

Ich frage mich eher: was habe ich jetzt schon wieder falsch gemacht?
Ich würde mich hinsichtlich der möglichen Antworten aber eher nicht auf 
die Persönlichkeitsanalyseprofis MaWin oder cppbert hier verlassen 
wollen.

von cppbert (Gast)


Lesenswert?

rbx schrieb:
> Ich würde mich hinsichtlich der möglichen Antworten aber eher nicht auf
> die Persönlichkeitsanalyseprofis MaWin oder cppbert hier verlassen
> wollen.

Wirklich keine Ahnung was du machst aber ich hab auch von VS2017,19,22, 
MSys2, Clang, Python, zum spielen D und Rust, ... Linux usw. auch 
einfach alles auf meinem Win10, VMWare Linux Systemen drauf - könnte 
sein das ich einfach nur dusel hab weil ich schon so viel installiert 
habe - und  mit den Systemen aber Fulltime jeden Tag arbeite kann es gut 
sein das kleine Probleme mir gar nicht mehr auffallen weil ich eh den 
ganzen Tag durch CMake, make oder sonstige Orgien wühle und relativ 
genau weiss was ich tun muss damit etwas aus/oder mit Code funktioniert

von cppbert (Gast)


Lesenswert?

cleaner Win10 VM, 
https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-msvc/rustup-init.exe 
aufgerufen, 40sek später läuft rustc sauber durch mit hello world - 
keine Ahnung was deine Probleme sind

ich hab eine 120MBit Leitung und 8 Kerne oder so - aber macht das so 
viel aus?

von cppbert (Gast)


Lesenswert?

dann noch 
https://www.oreilly.com/library/view/rust-programming-by/9781788390637/e07dc768-de29-482e-804b-0274b4bef418.xhtml
1
rustup default nightly

in der Konsole - 30sek später bin ich auf nightly
1
rustc --version
2
rustc 1.68.0-nightly (ec56537c4 2022-12-15)

rustup ist so ein bisschen wie pacman von cygwin/msys2

von Oliver R. (Gast)


Lesenswert?

Man kann die verwendete Version auch pro Projekt festlegen:

https://rust-lang.github.io/rustup/overrides.html#the-toolchain-file

von rbx (Gast)


Lesenswert?

cppbert schrieb:
> keine Ahnung was deine Probleme sind

Vielleicht Windows 8.1?
Und: hast du die Standaloneversion genutzt?
Haskell Plattform kam auch erst nach einigen Klimmzügen bei der 
Installation auf ME auf den Trichter, die falsche Windowsversion zu 
melden.
Hätte man auch gleich am Anfang machen können.
Aber ich will keine Vorurteile haben.

Version ist rustc 1.68.0-nightly (b70baa4f9 2022-12-14)
rustup geht nicht, kann aber mit der Standaloneversion zu tun haben.
Außerdem habe ich keine Admininstallation, sondern nur eine auf 
Userbasis, was man ja im Installer ausdrücklich einstellen konnte.

von cppbert (Gast)


Lesenswert?

rbx schrieb:
> cppbert schrieb:
>> keine Ahnung was deine Probleme sind
>
> Vielleicht Windows 8.1?
Win10

> Und: hast du die Standaloneversion genutzt?

Nein - die verwende ich nicht - ist nicht prefered und auch nur für die 
welchen eine "richtigen" Installer wollen oder unbedingt offline - ich 
hasse grafische Installer - die sehen schön aus - dahinter ist meist 
Schrott weil keiner Bock hat die zu pflegen - da ist mir jede 
Konsolen-Installation 1000% lieber

https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-msvc/rustup-init.exe

dann

rustup default nightly

von cppbert (Gast)


Lesenswert?

rbx schrieb:
> Außerdem habe ich keine Admininstallation, sondern nur eine auf
> Userbasis, was man ja im Installer ausdrücklich einstellen konnte.

ich hab auch keine Admininstallation - sowas macht auch wirklich niemand 
mehr der nicht ein bisschen verrückt ist

von Cyblord -. (cyblord)


Angehängte Dateien:

Lesenswert?

cppbert schrieb:
> rbx schrieb:
>> Außerdem habe ich keine Admininstallation, sondern nur eine auf
>> Userbasis, was man ja im Installer ausdrücklich einstellen konnte.
>
> ich hab auch keine Admininstallation - sowas macht auch wirklich niemand
> mehr der nicht ein bisschen verrückt ist

Das ist halt auch so ein 1990er Einstellung.
Auch für dich hat XKCD was auf Lager.
https://xkcd.com/1200/

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

rbx schrieb:
> Ich frage mich eher: was habe ich jetzt schon wieder falsch gemacht?

Ja. Das fragen wir uns alle.
Normale Leute klicken auf rustup-init.exe, installieren die stable 
Variante (Warum zum Henker installierst du nightly?), und zack schon hat 
man ein voll funktionsfähiges Rust + Cargo.
Ich habe echt nicht die geringste Ahnung, was du da veranstaltest.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Auch für dich hat XKCD was auf Lager.

Das widerspricht ja gar nicht cppbert's Aussage. Ist dir das nicht 
selbst aufgefallen?

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Cyblord -. schrieb:
>> Auch für dich hat XKCD was auf Lager.
>
> Das widerspricht ja gar nicht cppbert's Aussage. Ist dir das nicht
> selbst aufgefallen?

Nein ist es nicht. Weil es genau passt.

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> MaWin schrieb:
>> Cyblord -. schrieb:
>>> Auch für dich hat XKCD was auf Lager.
>>
>> Das widerspricht ja gar nicht cppbert's Aussage. Ist dir das nicht
>> selbst aufgefallen?
>
> Nein ist es nicht. Weil es genau passt.

aber

> Auch für dich hat XKCD was auf Lager.
> https://xkcd.com/1200/

klingt so als hätte ich jemands Admin-Installationen befürwortet :)

von cppbert (Gast)


Lesenswert?

cppbert schrieb:
> klingt so als hätte ich jemands Admin-Installationen befürwortet :)

jemals

von cppbert (Gast)


Lesenswert?

wer Admin-Installation macht öffnet Tür und Tor für jedes erdenkliche 
Problem

von MaWin (Gast)


Lesenswert?

rbx schrieb:
>> keine Ahnung was deine Probleme sind
> Vielleicht Windows 8.1?

Ziemlich sicher auch.
Niemand testet Rust auf einem Betriebssystem, dessen Support ausgelaufen 
ist.
Aber darauf hättest du natürlich auch selbst kommen können.

von Cyblord -. (cyblord)


Lesenswert?

cppbert schrieb:
>> Auch für dich hat XKCD was auf Lager.
>> https://xkcd.com/1200/
>
> klingt so als hätte ich jemands Admin-Installationen befürwortet :)

Kann es sein dass du das XKCD nicht verstanden hast? Es spricht sich FÜR 
Admininstallationen aus. Weil eine eingeschränkte User-Installation 
heute nicht mehr viel bringt, weil alles wichtige heute online passiert 
und nicht in den tiefen des OS.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Es spricht sich FÜR Admininstallationen aus.

Nein, tut es nicht.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Cyblord -. schrieb:
>> Es spricht sich FÜR Admininstallationen aus.
>
> Nein, tut es nicht.

Ja ok ich verstehe langsam das Problem in den Begrifflichkeiten. Es geht 
um Admininstallationen vs. getrennte Admin- und Userinstallationen.
Es spricht sich allerdings dafür aus, dass man standardmäßig auf 
Adminrechten arbeitet.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

MaWin schrieb:
> Niemand testet Rust auf einem Betriebssystem, dessen Support ausgelaufen
> ist

Rust ist seiner Zeit voraus? ;-)

"Windows 8.1 Support endet am 10. Januar 2023"

https://support.microsoft.com/de-de/windows/windows-8-1-support-endet-am-10-januar-2023-3cfd4cde-f611-496a-8057-923fba401e93

Also aktuell ist es noch supportet … (wenn auch nur gerade noch so).

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> Weil eine eingeschränkte User-Installation
> heute nicht mehr viel bringt

völliger Quatsch - nur schlechte miese Software benötigt das - es gibt 
aber viele die seit UAC anfängen alles nur noch als Admin installieren - 
aus Gewohnheit - ich mache gar keine Admin-Installationen - maximal 
läuft das VStudio mal kurzfristig als Admin damit der Intel-VTune an die 
Hardware-Counter kommt - aber nur so lange Performanz-Tests laufen

ohne Grund eine Admin-Installation zu machen ist völlig hirnlos

von Cyblord -. (cyblord)


Lesenswert?

cppbert schrieb:
> Cyblord -. schrieb:
>> Weil eine eingeschränkte User-Installation
>> heute nicht mehr viel bringt
>
> völliger Quatsch - nur schlechte miese Software benötigt das
Darum geht es gar nicht.

> - es gibt
> aber viele die seit UAC anfängen alles nur noch als Admin installieren -
> aus Gewohnheit - ich mache gar keine Admin-Installationen - maximal
> läuft das VStudio mal kurzfristig als Admin damit der Intel-VTune an die
> Hardware-Counter kommt - aber nur so lange Performanz-Tests laufen
>
> ohne Grund eine Admin-Installation zu machen ist völlig hirnlos

Und das sieht halt XKCD anders. Und es wird ja auch begründet. Mehr sage 
ich ja nicht.
Du hingegen kannst bisher nicht begründen was die eingeschränkten Rechte 
bringen sollen.

: Bearbeitet durch User
von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> Und das sieht halt XKCD anders. Mehr sage ich ja nicht.

rbx hat geschrieben

> Außerdem habe ich !!! keine !!! Admininstallation

und dann hast (nur) du angefangen von Admin-Installation zu sprechen

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> Du hingegen kannst bisher nicht begründen was die eingeschränkten Rechte
> bringen sollen.

Mehr Sicherheit, weniger Konflikte zwischen Applikationen wenn manche 
anfangen teilweise mit Adminrechten Dateien usw. zu erstellen

das ist völliger veralteter Windows-Noob User Style - hauptsache das 
System läuft irgendwie

von Cyblord -. (cyblord)


Lesenswert?

cppbert schrieb:
> das ist völliger veralteter Windows-Noob User Style

Wie gesagt, in den 90er war diese Einstellung unter Profis Konsens. Aber 
heute kann man das schon hinterfragen. Die Zeiten ändern sich. Du 
scheinst halt in alten Mustern festzuhängen.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Also aktuell ist es noch supportet … (wenn auch nur gerade noch so).

Ja. War mir klar, das dieser dümmliche Kommentar kommen musste.

https://learn.microsoft.com/de-de/lifecycle/products/windows-81

> Enddatum des Mainstreamsupports:  9. Jan. 2018
> Erweitertes Enddatum:  10. Jan. 2023

Windows 8.x ist tot. Das ist Fakt.
Es zu verwenden ist dumm.
Nun zu jammern, dass Rust darauf eventuell Probleme haben könnte, ist 
noch dümmer.

Niemand interessiert sich für historische Betriebssysteme im 
Rust-Umfeld.

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


Lesenswert?

MaWin schrieb:
> War mir klar, das dieser dümmliche Kommentar kommen musste.

Ah ja, die Realität ist "dümmlich".

Mir ist persönlich Windows ziemlich schnuppe (Rust interessiert mich 
wenigstens, anders als Windows), ich gehe auch nicht davon aus, dass 
seine alte Windows-Version da tatsächlich eine Rolle spielt.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Ah ja, die Realität ist "dümmlich".

Nein. Deine Antwort ist dümmlich.
Mir war völlig klar, dass der erweiterte Support erst in ein paar Tagen 
ausläuft.
Für mein Argument spielt das allerdings genau gar keine Rolle. Deshalb 
habe ich es nicht extra erwähnt.

> ich gehe auch nicht davon aus, dass
> seine alte Windows-Version da tatsächlich eine Rolle spielt.

Ja. Ich auch nicht.
Aber ich würde mich auch nicht wundern, wenn es denn so wäre.
Es gibt überhaupt keinen Grund Windows 8 zu verwenden und dann hier die 
Leute mit Problemen zu belästigen.

Rust funktioniert auf Windows 10 und 11 tadellos und ist trivial 
installierbar.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Aber ich würde mich auch nicht wundern, wenn es denn so wäre.
> Es gibt überhaupt keinen Grund Windows 8 zu verwenden und dann hier die
> Leute mit Problemen zu belästigen.
>
> Rust funktioniert auf Windows 10 und 11 tadellos und ist trivial
> installierbar.

Also ich sehe starke parallelen in der Argumentation und im 
Sozialverhalten zwischen Rust-Anhängern und Linux-Anhängern. Frappierend 
möchte man sagen.

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


Lesenswert?

Cyblord -. schrieb:
> Also ich sehe starke parallelen in der Argumentation und im
> Sozialverhalten zwischen Rust-Anhängern und Linux-Anhängern.

Wegen eines Einzigen?

von rbx (Gast)


Lesenswert?

Ich denke mal, in Linux lässt sich Rust viel unproblematischer und 
schneller installieren.
Theoretisch bräuchte man in die Konsole nur schreiben rustc

Die Automagie geht soweit, dass die sich dann praktisch um den Rest 
kümmert, hinsichtlich der notwendigen Installation.

Ähnlich schnell und unproblematisch kann man die OpenWatcom Sachen auf 
Windows installieren.
Sowas würde man sich auch für Rust wünschen - wenn das denn so eine 
tolle C-Ablösung sein soll.

von MaWin (Gast)


Lesenswert?

rbx schrieb:
> Sowas würde man sich auch für Rust wünschen

Es nennt sich rustup-init.exe.

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


Lesenswert?

Cyblord -. schrieb:
> Du scheinst halt in alten Mustern festzuhängen.

Mit deiner Einstellung darfst du allerdings auch nie Python+pip benutzen 
(womit virtual environments ebenfalls tabu sein dürften), erst recht 
nicht Platform.IO.

von Cppbert (Gast)


Lesenswert?

rbx schrieb:
> Ich denke mal, in Linux lässt sich Rust viel unproblematischer und
> schneller installieren.
> Theoretisch bräuchte man in die Konsole nur schreiben rustc

Ich habe unter Linux und Windows in ca. 70sek installiert, sehr auch 
irgendwas 8.1 nicht mehr Supporter sein soll

rbx schrieb:
> Ähnlich schnell und unproblematisch kann man die OpenWatcom Sachen auf
> Windows installieren.
> Sowas würde man sich auch für Rust wünschen - wenn das denn so eine
> tolle C-Ablösung sein soll.

Für OpenWatcom brauch ich ca. 30sek

Ist aber alles relativ bis absolut egal weil man 99% der Zeit Code 
schreibt und nicht aus Langeweile staendig Compiler installiert

von Cppbert (Gast)


Lesenswert?

Cppbert schrieb:
> sehr auch irgendwas 8.1 nicht mehr Supporter sein soll

Sehe auch nirgends das 8.1 nicht supportet sein soll

von MaWin (Gast)


Lesenswert?

Cppbert schrieb:
> Sehe auch nirgends das 8.1 nicht supportet sein soll

Google immer noch kaputt?

https://doc.rust-lang.org/nightly/rustc/platform-support.html

> 64-bit MSVC (Windows 7+) 2

> 2  Only Windows 10 currently undergoes automated testing.
>    Earlier versions of Windows rely on testing and support
>    from the community.

von S. R. (svenska)


Lesenswert?

Jörg W. schrieb:
> Naja, ehrlich, wer will sich heutzutage noch mit dem
> abscheulichen "real mode" eine 8086 herumschlagen?

Ich, aber ich mache auch 8080/Z80.
Da nehme ich natürlich kein Rust für.

> Ansonsten kann ich mir nicht vorstellen, dass das soooo
> Windows-untauglich ist, [...]

Naja, Firefox hat die Unterstützung für Windows 9x/ME eingestellt, bevor 
sie Rust integriert haben... und selbst wenn da Rust-Code drin ist, dann 
muss der noch lange nicht nennenswert mit der WinAPI zusammenarbeiten.

Vollwertige Anwendungen in einer Sprache schreiben ist nochmal was 
anderes als Bibliotheken.

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> und selbst wenn da Rust-Code drin ist, dann
> muss der noch lange nicht nennenswert mit der WinAPI zusammenarbeiten.

Das hat ja auch niemand behauptet.

Es geht hier um Rust und alles im Rust-Lieferumfang. Nicht um Firefox.

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


Lesenswert?

MaWin schrieb:
> Only Windows 10 currently undergoes automated testing.

Keine automatischen Tests bedeutet aber noch lange nicht, dass es 
deshalb gleich nicht mehr funktionieren soll.

Python hatte wohl kürzlich bei ihren Binärversionen Support für Windows 
7 eingestellt (d.h. es lässt sich da auch wirklich nicht mehr 
installieren), aber 8.1 ist selbst bei denen noch in der Tüte.

von rbx (Gast)


Lesenswert?

MaWin schrieb:
> Es geht hier um Rust und alles im Rust-Lieferumfang

Leicht daneben, es geht um die Zukunft von Rust, und Daniel ist nicht 
der einzige, der in diese Richtung fragt.
Und wenn man Zukunftsfragen stellt, dann ist es nicht verkehrt, in die 
Vergangenheit zu schauen, oder nach ähnlichen Fällen.

Unabhängig davon:
FreeDOS Project: Then and Now [Kielux 2017]
- https://www.youtube.com/watch?v=w6NswAAKmbU
42 Minuten

Bryan Lunduke war sich nicht zu schade, ein Interview mit Jim Hall zu 
machen.
(Auf der Suche nach Antworten, warum Linux so schwach verbreitet ist, 
warum Linux so Spielunfreundlich ist usw. usw.)

highlights from linux sucks 2022 by bryan lunduke

https://www.youtube.com/watch?v=MRKtybzB3ig
3:35

https://reactos.org/forum/viewtopic.php?t=18215
----------------------

Man sollte schon festhalten, dass die Rustanhänger ein wenig ein auf 
Woke machen, andere Meinungen dissen, und dass das neu ist. Das 
Gegenseitige runtermachen ist nicht neu, das ist flamewar, es ist eher 
die beobachtbare kognitive Dissonanz bei den Rust-Freunden.

Und wenn man die FP analog als Steinzeit betrachtet, dann ist Haskell 
darin Ägypten.
Der bewährte Weg ist vom Bekannten zum Unbekannten. An vielen Stellen 
gesehen.
Aber von Lisp kennt man auch: Dialektmanie, viel schlimmer noch als 
Basic. Praktisch jeden Freitag ein neuer Lisp Dialekt.

Das war bei C immer weniger schlimm. Noch dazu gibt es didaktisch krasse 
Bücher, wie das vom Erlenkötter. So ganz unscheinbar wird einem die 
Programmierung einer Game-Engine beigebracht..
Bei K+R lernt man gleich am Anfang, wie man Verschlüsselungen knackt, 
sowas fanden viele spannend.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Keine automatischen Tests bedeutet aber noch lange nicht, dass es
> deshalb gleich nicht mehr funktionieren soll.

Was ja auch niemand behauptet hat.

rbx schrieb:
> FreeDOS Project

Bitte on-topic bleiben. Danke.

> Man sollte schon festhalten, dass die Rustanhänger ein wenig ein auf
> Woke machen

Ja. Genau.

> Steinzeit

Ja.

> Ägypten

Genau das.

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


Lesenswert?

rbx schrieb:
> die Rustanhänger

Soso. Wie viele kennst du denn so, dass du für "die Rustanhänger" 
sprechen kannst?

von Yalu X. (yalu) (Moderator)


Lesenswert?

Jörg W. schrieb:
> rbx schrieb:
>> die Rustanhänger
>
> Soso. Wie viele kennst du denn so, dass du für "die Rustanhänger"
> sprechen kannst?

Mindestens einen davon kennt jeder, der diesen Thread liest. Was wäre,
mal rein hypothetisch betrachtet, wenn dieser eine repräsentativ für die
meisten anderen in seiner Gilde wäre? ;-)

SCNR

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


Lesenswert?

Yalu X. schrieb:
> Mindestens einen davon kennt jeder, der diesen Thread liest.

Naja, genau genommen, kenne ich allein aus dem Thread bereits zwei. Nur 
einer davon tritt, nennen wir es mal, derart "offensiv" auf.

Da ich aber privat noch weiter Leute kenne, die das gern nutzen, trau' 
ich mir durchaus die Aussage zu, dass man von diesem einen allein 
keineswegs auf alle schließen kann.

von rbx (Gast)


Lesenswert?

Jörg W. schrieb:
> dass man von diesem einen allein
> keineswegs auf alle schließen kann.

Mache ich auch nicht. Auffällig waren die Kommentare in einem 
reddit-thread (s.o.).
Und in dem ungekürzten Bryan Lunduke Video wird auch ein kleiner Witz 
über Rust Programmierer gemacht - in dem Comic-Bild in der 3 Min 
Zusammenfassung bei 2:38 zu sehen. Was er weiter meint, ist sowas wie: 
jetzt sind wir endlich Perl losgeworden..
Das kommt ja auch nicht von ungefähr, und so "riecht" man schon so ein 
wenig Sektenhaftigkeit, Gleichschaltung, VT-Zuschreibung usw.

von Cppbert (Gast)


Lesenswert?

Es ist völlig unrelevant für die Qualitäten einer Sprache oder 
Betriebsystem wie sich dessen subjektiv wahrgenommene Community verhält, 
kein erfahrener Entwickler lässt sich davon in irgendeiner Form 
beeinflussen

Jede Community hat ihre gemäßigten, toxischen, fanatischen und Prediger, 
aber Einzelpersonen sind ohne Projekt oder Team dahinter unrelevant, sie 
sprechen nie für eine Gruppe sondern immer nur für sich selbst und das 
ist ok, erst wenn sich Leute öffentlich treffen und gemeinsam diese 
subjektiv erfahrenen Werte teilen wird es schwierig und so leid es mir 
tut habe ich solche Konflikte nie erlebt wenn ich auf C/C++, 
Linux,Windows oder sonstige Veranstaltungen war kein Evangelismus, keine 
Abgrenzung, offene Gespräche und immer nur viel Interesse

Die Welt ist voll mit Menschen die Neuerungen ausprobieren wollen, egal 
zu welchem Zweck und den Konservativen die denken das nur aus Stillstand 
und Reife etwas besseres entstehen kann, beides braucht man

Es ist nur eine Sache die deutlich zu erkennen ist, es gibt wenige 
professionelle, also hauptberufliche Entwickler mit breiter Erfahrung 
die sich an solchen Diskussionen aktiv beteiligen, der Anteil an Hobby 
Entwicklern die das nur als Zeitvertreib machen ist viel höher und 
leider kann dieser Teil der Entwicklergemeinschaft nur recht wenig 
objektives Beitragen weil sie die Welt nur aus einem sehr 
eingeschränkten Blickwinkel sehen, oder eben der andere Teil an 
Entwicklern die in ihrem Bereich recht professionell sind aber leider 
trotzdem nicht verstehen das die guten Konzepte aus ihrer Welt nur 
beschränkt in der Systemwelt greifen können oder der harte Kern der 
einfach nur Technikgeschschwafel betreiben will, dem jedes Argument 
irgendwie recht ist und den es oft an Objektivität, Weitblick und 
Erfahrung fehlt

Mir persönlich ist es völlig egal wie MaWin und andere hier (manchmal) 
auftreten, ich filtere die für mich relevanten Infos raus und gut ist 
und ein klein wenig missionieren hab ich mir nach so langer Zeit in der 
C/C++,C#,Python,....,Linux,Windows Entwicklung auch verdient ;)

Sollte es mal ein Forumstreffen geben wird MaWin sicherlich einen 
Vortrag über Rust halten und der grosse Rest hier wird ihm zuhören und 
dann vielleicht offen und freundlich diskutieren, aber niemals so 
eigenbrödlerisch wie das teilweise hier statt findet

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


Lesenswert?

Cppbert schrieb:
> ich filtere die für mich relevanten Infos raus

Das ist übrigens auch für mich der einzige Grund, mich hier zu 
beteiligen.

Ansonsten danke für deinen Beitrag!

von MaWin (Gast)


Lesenswert?

Ihr interpretiert da ganz einfach viel zu viel rein.

Was ich hier tue:
- Berichten, wenn es etwas aus meiner sich interessantes Neues zu 
berichten gibt.
- Berichtigen, wenn hier jemand Quatsch labert.

Ich sehe das Problem eher bei denjenigen, die ewig lange mit ja-doch 
"antworten", nachdem sie berichtigt wurden.

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> Ihr interpretiert da ganz einfach viel zu viel rein.

Nein, ich wollte damit auch nicht ausdrücken das du dich falsch verhälst 
- manchmal vielleicht ein Ticken zu bissig

du machst genau das warum ich hier mitlesen - die interessierten 
informieren
und das ist gut

von rbx (Gast)


Lesenswert?

Cppbert schrieb:
> Es ist völlig unrelevant für die Qualitäten einer Sprache oder
> Betriebsystem wie sich dessen subjektiv wahrgenommene Community verhält,
> kein erfahrener Entwickler lässt sich davon in irgendeiner Form
> beeinflussen

Das ist die Theorie.

Ich finde z.B. spannend, wie wohl Rust auf Solaris läuft. Habe aber im 
Moment aber keinen Rechner frei zum testen frei.
VM finde ich nicht so hilfreich. Ich will mir ja direkt die 
Software/Hardware-Situation ansehen.

nightly Build wird für webassembly empfohlen, sollte also grundsätzlich 
funktionieren.
Standaloneversionen überzeugen mich bisher noch nicht. Wie soll das auch 
sinnvoll gehen?

von cppbert (Gast)


Lesenswert?

rbx schrieb:
> Ich finde z.B. spannend, wie wohl Rust auf Solaris läuft.

was meinst du - ob das kompilieren geht oder wie die schnell die 
Applikation läuft, oder...?, sollte sich nicht von einem C/C++ Code 
unterscheiden - so lange die Stdandard-Lib-Unterschiede nicht zu gross 
sind

Wird ja wenn dann vom LLVM kompiliert und der wird auch beim Clang unter 
der Haube verwendet, gibt es Rust für Solaris oder Clang für Solaris?

von MaWin (Gast)


Lesenswert?

rbx schrieb:
> nightly Build wird für webassembly empfohlen

Wo hast du diese wirre Information denn wieder aufgeschnappt?

https://rustwasm.github.io/book/game-of-life/setup.html

> The Rust and WebAssembly experience is riding the Rust release trains
> to stable! That means we don't require any experimental feature
> flags. However, we do require Rust 1.30 or newer.

von rbx (Gast)


Lesenswert?

cppbert schrieb:
> gibt es Rust für Solaris oder Clang für Solaris?

du schaust dir offenbar gar nicht die Links von Jörg an? Naja, und wer 
Daniel ist, ist dir auch nicht so recht klar, und dass es professionelle 
Leute sind, die nach der Zukunft von Rust gefragt hatten scheinbar auch 
nicht. Ts..

Das mit Solaris war auch nur ein Hinweis auf Community-Problemchen. 
Viele professionelle Hansel müssen sowieso das Zeug nehmen/bearbeiten, 
was sie vorgesetzt kriegen, oder nachplappern, was die Bwl-Abteilung 
haben will. Nochmal Ts..

MaWin schrieb:
> Wo hast du diese wirre Information denn wieder aufgeschnappt?

Das hatte ich mich auch gefragt, bzw. fragen müssen, ich kenne nämlich 
die offiziellen Beschreibungen bei Rust oder bei Mozilla.
Es könnte was mit Arch zu tun gehabt haben, aber ganz sicher bin ich mir 
nicht.
https://aur.archlinux.org/packages/rust-nightly-bin

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


Lesenswert?

rbx schrieb:

(Solaris)

> VM finde ich nicht so hilfreich. Ich will mir ja direkt die
> Software/Hardware-Situation ansehen.

Wobei für einen Compiler eine VM schon erstmal genügen sollte.

Ich habe hier zwar noch eine Solaris-Kiste, aber die ist hornalt 
(SunFire V210). War mal gedacht als Big-endian-Testmaschine, habe ich 
jetzt aber schon lange nicht mehr eingeschaltet, dient eigentlich nur 
noch als Fachboden im Rack. ;-) Ob auf dem alten Solaris ein moderner 
Compiler noch lauffähig ist, wage ich zu bezweifeln.

von Cppbert (Gast)


Lesenswert?

rbx schrieb:
> Das mit Solaris war auch nur ein Hinweis auf Community-Problemchen

Solaris interessiert mich nicht mehr seit der Support bei meinen Kunden 
dafuer begraben wurde, ich glaube Solaris ist jetzt auch nicht mehr so 
relevant bei uns, im asiatischen Raum ist es wohl noch stärker 
verbreitet, aber ich hab schon lange keinen Kontakt mehr, Linux löst die 
Systeme alle langsam ab

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


Lesenswert?

Ich denke, dass das seit der Übernahme durch Oracle praktisch nur noch 
für Datenbankserver genutzt wird.

von cppbert (Gast)


Lesenswert?

Jörg W. schrieb:
> Ich denke, dass das seit der Übernahme durch Oracle praktisch nur
> noch
> für Datenbankserver genutzt wird.

Ich sehe das System auch als Nearly-Dead an, FreeDOS und ReactOS haben 
wenigstens noch einen Spass-Faktor - Solaris nervt nur noch seit Oracle 
das Projekt gegen die Wand fährt

und ich vestehe sowiso nicht warum jetzt FreeDOS oder ein sterbendes 
Solaris plötzlich irgendwie relevant ist - ja OK FreeDOS lässt sich mit 
GCC-IA16 bauen aber das ist ein GCC Fork der von einer Person gepflegt 
wird und noch leider Jahre weg ist von einer Mainline Intergration (und 
es war einfach nur ein riesen Glück das jemand einen echten 16bit 
bauenden GCC probiert hat) und für Systeme auf dem der LLVM funktioniert 
ist Rust definitiv nicht unmöglich - sobald die GCC-Rust Leute (was noch 
ein paar Jahre dauern wird) fertig sind geht dann Rust auch für alle GCC 
Platformen - also wieso sprechen wir über sowas?

Für alte oder Legacy Projekte werde ich wie immer C/C++ oder das 
notwendige nutzen, mit Freude - aber ich würde schon gerne sehen das ich 
die nächsten 20 Jahren noch erlebe das sich vielleicht etwas 
günstigeres/einfacheres/fähigeres durchsetzt - und wenn nicht mach ich 
eben bis zu meinem Ableben C/C++ - so wie schon die letzten 30 Jahre :)

von rbx (Gast)


Lesenswert?

ich habe mal testweise rustc in die Fedora33 Konsole eingegeben.
Ergebnis:
1
[rbx@fe1 ~]$ rustc
2
Usage: rustc [OPTIONS] INPUT
3
4
Options:
5
    -h, --help          Display this message
6
        --cfg SPEC      Configure the compilation environment
7
    -L [KIND=]PATH      Add a directory to the library search path. The
8
                        optional KIND can be one of dependency, crate, native,
9
                        framework, or all (the default).
10
    -l [KIND[:MODIFIERS]=]NAME[:RENAME]
11
                        Link the generated crate(s) to the specified native
12
                        library NAME. The optional KIND can be one of
13
                        static, framework, or dylib (the default).
14
                        Optional comma separated MODIFIERS
15
                        (bundle|verbatim|whole-archive|as-needed)
16
                        may be specified each with a prefix of either '+' to
17
                        enable or '-' to disable.
18
        --crate-type [bin|lib|rlib|dylib|cdylib|staticlib|proc-macro]
19
                        Comma separated list of types of crates
20
                        for the compiler to emit
21
        --crate-name NAME
22
                        Specify the name of the crate being built
23
        --edition 2015|2018|2021
24
                        Specify which edition of the compiler to use when
25
                        compiling code.
26
        --emit [asm|llvm-bc|llvm-ir|obj|metadata|link|dep-info|mir]
27
                        Comma separated list of types of output for the
28
                        compiler to emit
29
        --print [crate-name|file-names|sysroot|target-libdir|cfg|target-list|target-cpus|target-features|relocation-models|code-models|tls-models|target-spec-json|native-static-libs]
30
                        Compiler information to print on stdout
31
    -g                  Equivalent to -C debuginfo=2
32
    -O                  Equivalent to -C opt-level=2
33
    -o FILENAME         Write output to <filename>
34
        --out-dir DIR   Write output to compiler-chosen filename in <dir>
35
        --explain OPT   Provide a detailed explanation of an error message
36
        --test          Build a test harness
37
        --target TARGET Target triple for which the code is compiled
38
    -A, --allow LINT    Set lint allowed
39
    -W, --warn LINT     Set lint warnings
40
        --force-warn LINT
41
                        Set lint force-warn
42
    -D, --deny LINT     Set lint denied
43
    -F, --forbid LINT   Set lint forbidden
44
        --cap-lints LEVEL
45
                        Set the most restrictive lint level. More restrictive
46
                        lints are capped at this level
47
    -C, --codegen OPT[=VALUE]
48
                        Set a codegen option
49
    -V, --version       Print version info and exit
50
    -v, --verbose       Use verbose output
51
52
Additional help:
53
    -C help             Print codegen options
54
    -W help             Print 'lint' options and default settings
55
    --help -v           Print the full set of options rustc accepts
56
57
[rbx@fe1 ~]$
..
1
rustc --version
2
rustc 1.56.1 (Fedora 1.56.1-1.fc33)
3
[rbx@fe1 ~]$

Ich hatte ja gewisse Bedenken hinsichtlich des Speicherplatzes..

naja, so grob: Rust ist eine Programmiersprache ohne Compiler/Linker - 
ist eigentlich auch neu.

64 Bit-Linker habe ich auf Windows nicht. Der von D ist wohl auch 32 Bit 
- kann ich gerade nicht gucken, schreibe ja auf Fedora.
Watcom habe ich als 32 Bit, und möchte mir diese Installation auch nicht 
mit der 64Bit-Variante vermurksen

Möglicherweise müsste man sich den Linker selber basteln? Dann hatte ich 
mal in Solaris-Buch geschaut, ob es da etwas erhellendes zum Thema 
Linker gibt: eigentlich nichts.
Aktuell auf der Haben-Seite: zumindest python ist standardmäßig drin.
Wäre vielleicht was für ein Supertyp oder wie hieß der nochmal?

LLVM wäre eine gute Option. Wieviel Speicherplatz braucht das, und wie 
kriegt man die Installation auf Userspace hin? Der Installer, den ich 
hatte, rief sofort nach Adminrechten.

LLVM könnte für Solaris auch eine Option (bezüglich Rust) sein.

Die Relevanz? Es ist doch schon irgendwie traurig, das mit OpenSolaris. 
Vielleicht bräuchte es noch eine OpenSolaris Foundation, oder ähnliches.

Die Features wollte ich eigentlich nicht abtippen, kann ich aber doch 
mal machen.

- Support for multiple hardware architectures, including both SPARC and 
32-bit and 64-bit x86based systems. OpenSolaris also performs well in 
many industry benchmarks.

- High scalabitity. OpenSolaris runs on both single processor maschines 
and multiprocessor systems with hundrets of CPUs and terrabytes of RAM

- Innovative file systems and volume manager support. Solaris uses a 
Virtual File System (VFS) layer so that different file systems can be 
plugged in on top of it relatively easely. In addition to the standard 
Unix File System (UFS), OpenSolaris includes the Solaris Volume Manager 
(SVM) and the new ZFS.

- Networking features, including a kernel-level, high performance TCP/IP 
stack, IPv6 support, IPsec, Network Auto-Magic (NWAM) for automatic 
detection and configuration of network interfaces, and IP Network 
Multipathing (IPMP for fault tolerance and load balancing.

- Complex ressource management, including processor pools, physical 
memory controls, and fair share scheduler.

- Sophisticated security, including role-based access control (RBAC), 
configurable privileges, and trusted extensions.

- Rich observability and debugging support, including myriad system 
monitor tools, the Modular Debugger (MDB), and the dynamic tracing 
facility (DTrace).

- Predictive self-healing features in the form of the Fault Management 
Architecture (FMA) and Service Management Facility (SMF). They work 
together to detect hardware and software faults an take appropriate 
action.

- Multiple forms of virtualization. In addition to the 
operating-system-level virtualization of Solaris Zones, OpenSolaris 
offers support for xVM Hypervisor, Logical Domains (LDoms), and 
VirtualBox, and runs in VMware and other virtualization frameworks.

- Sophisticated 64bit fully preemptable kernel. The OpenSolaris kernel 
is also modular - device drivers can be installed without requiring a 
system boot, and features can be configured without compiling the 
kernel. The virtual memory subsystems uses demand paging for greater 
performance and less memory usage. The process scheduling systems 
support multiple scheduling classes, including timeshare, real time, 
interactive, fair share, and fixed priority.

- Full POSIX compliance with a rich application  programming API, 
including support for 64-bit applications.

- Integrated AMP stack (Apache, MySQL, PHP) for running web services.
------------------

Und dann noch (das war aber so 2006-2007)
"The Sun Studio compilers have better performance in many cases then do 
the GCC compilers"

..und jetzt ist mein Kaffee kalt ;)

von Cppbert (Gast)


Lesenswert?

Deiner ganzer Post ist künstlich Fett (warum postest du die ganze rustc 
Ausgabe?) und dann noch Solaris Feature Werbung, der Rest ist fast wie 
immer halbwissen Technik blabla ohne jeglichen Hintergrund, kannst du 
auch anstaendig oder schreibst du einfach immer jeden Gedanken auf der 
so durch deinen Kopf schwirrt

von MaWin O. (mawin_original)


Lesenswert?

Alter, krass.
Geh mal zu einem Arzt, rbx.

Da stimmt doch was nicht. Oder du trollst. Und zwar schlecht.

von rbx (Gast)


Lesenswert?

Cppbert schrieb:
> warum postest du die ganze rustc
> Ausgabe?

Weil ich so darüber lachen musste.

von cppbert (Gast)


Lesenswert?

rbx schrieb:
>> warum postest du die ganze rustc
>> Ausgabe?
>
> Weil ich so darüber lachen musste.

beim gcc, MinGW, Clang, Turbo C, Microsoft C, Microsoft cl, open-watcom, 
D Kompiler sieht das doch teilweise noch viel wilder aus? d.h. bei alle 
gängigen Kompilern der Früh und Neuzeit

ich glaube dir fehlt sehr viel Erfahrung und du fröhnst hier nur völlig 
unreflektiert dein Technik-Interesse ohne echten Background - oder 
besser gesagt so lesen sich deine Post sehr häufig - und da du recht 
stupide einfach so weiter postest hat das schon echte Troll-Qualität

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


Lesenswert?

cppbert schrieb:
> beim gcc, MinGW, Clang, Turbo C, Microsoft C, Microsoft cl, open-watcom,
> D Kompiler sieht das doch teilweise noch viel wilder aus?

Naja, nicht ganz.
1
$ cc
2
cc: error: no input files

Warum man gleich unaufgefordert (statt mit -h oder --help oder so) eine 
mehrseitige Hilfe bringen muss, nun, mag Geschmackssache sein. Ist aber 
wohl auch mit Abstand der unwesentlichste Punkt überhaupt, darüber kann 
man sich beschweren, wenn es sonst keine Themen mehr gibt. ;-)

: Bearbeitet durch Moderator
von Cppbert (Gast)


Lesenswert?

Jörg W. schrieb:
> Ist aber wohl auch mit Abstand der unwesentlichste Punkt überhaupt

Der Satz hat dich gerettet :)

von rbx (Gast)


Lesenswert?

cppbert schrieb:
> und da du recht
> stupide einfach so weiter postest

Machst du doch auch. Du hast noch nicht mal den Witz verstanden, warum 
ich so lachen musste, Und so postest munter und zusammenhangbefreit 
drauflos, wo wohl noch größerer Ausgaben rauskommen.
Und darauf baust du dann deine Persönlichkeitstheorie auf.

Ich bin zwar kein Arzt, aber..

von Cppbert (Gast)


Lesenswert?

rbx schrieb:
> Du hast noch nicht mal den Witz verstanden, warum ich so lachen musste

Dann erkläre den Witz doch mal, ich dachte du meinst den Umfang der Help 
Ausgabe, oder meinst du ein spezifisches Detail das mir in der halben 
Seite Text nicht aufgefallen ist? Oder belustigt dich das default 
Verhalten die Hilfe gleich zu zeigen?

von Wilhelm M. (wimalopaan)


Lesenswert?

rbx schrieb:
> naja, so grob: Rust ist eine Programmiersprache ohne Compiler/Linker -
> ist eigentlich auch neu.

Was möchtest Du uns damit sagen?

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> Was möchtest Du uns damit sagen?

Seine allumfassende Unkenntnis.
Die hat er ja nun mehrfach hier bewiesen.

Wollen wir rbx nicht einfach ignorieren?

Mir wird das jedenfalls zu dumm. Je öfter man ihm antwortet, desto 
länger, wirrer und sinnloser werden seine "Beiträge".

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

Kurze Nachfrage, 🐧 DPA 🐧
Hast du deinen Arsch eigentlich hochbekommen und geforked?
Also zum Nullkostenpreis den (nicht vorhandenen) Schaden vermieden?

Ich schliesse mich übrigens Jörg W. (dl8dtl) an: Ist nur für Datenbanken 
relevant ... also macht euch keinen Kopf und konzentriert euch lieber 
auf die Feiertage. Beweis, das 1.66 Enum update.

Echt wahr! (:P)

ref: 
https://www.heise.de/news/Programmiersprache-Rust-1-66-erweitert-Enumerations-und-entfernt-Abhaengigkeiten-7398888.html

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

MaWin O. schrieb:
> Seine allumfassende Unkenntnis.
> Die hat er ja nun mehrfach hier bewiesen.

Also ich war 2017 schon von meinen ersten Gehversuchen mit meinem 
"Rust-Blinky" auf dem STM32F103 begeistert.
Lass ihm doch Zeit!:)

tuschel Und er hat ja recht! ... es nervt echt, diese langweiligen 
Leute von der Rust Community: mipsel32 ... braucht keine Sau! Hat ne 
Woche gedauert, bis wir OpenSSL hinbekommen haben um auf der guten alten 
Schindmähre zu reiten, MaWin*g* ... siehe github.

P.S.: Das war kein Zuspruch zu OpenSSL, sondern zum buildsystem. Die 
Leute bei Ersterem haben gewiss mehr Animositäten zu beachten .... :)

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

Na ja. Manche Pakete sind halt auch einfach FERTIG!

... das Konzept mag dem ein oder anderen hier nicht geläufig sein.
Lasst es mich erklären: Das ist dann, wenn die Arbeit gut ist ... und 
abgeschlossen ist!:)))

(Ist natürlich ne Lüge, wie nachfolgende Beispiele und Argumente belegen 
werden ... von Api's echt jetze???)

https://crates.io/crates/wasi/0.11.0+wasi-snapshot-preview1
https://crates.io/crates/cfg-if/1.0.0
https://crates.io/crates/getrandom/0.2.8 shit ... die "data-science" 
schläft nicht, hehehee;)

von cppbert (Gast)


Lesenswert?

@Jedzia D.

Bist du ein Clone von rbx, du schreibst auch irgendwie fast genau wie er
- so ein bisschen Fakten, bissel Emotionen, Somway Off-Topics aber 
irgendwie related - wilde Mischung

oder bin ich schon so alt das mir dieser Whatsapp/Tiktok 
Kommunikationsstyle einfach nicht vertraut genug ist :)

von cppbert (Gast)


Lesenswert?

https://blog.yoshuawuyts.com/rust-2023/

netter Vergleich aus dem Post
1
Take for example memory safety in systems programming languages. Using fuzzers and sanitizers you may be able to easily address 80% of bugs. But the remaining 20% of bugs will take some effort to find. And even when you do; code changes over time, which means that you'll be unlikely to ever afford to stop looking for these types of bugs.
2
3
Compare that with the borrow checker, which guarantees there will never be any memory safety bugs: meaning you can catagorically eliminate the concern alltogether. The 80/20 rule is often used to indicate that "80% of effort is good enough". But I think it's important to realize that sometimes achieving 100% of a solution can provide a value-add which far outweighs all incremental steps that come before it.

von MaWin O. (mawin_original)


Lesenswert?

cppbert schrieb:
> The 80/20 rule is often used to indicate that "80% of effort is good
> enough". But I think it's important to realize that sometimes achieving
> 100% of a solution can provide a value-add which far outweighs all
> incremental steps that come before it.

Ja, das sehe ich ganz genau so.
Und der Grund ist ganz einfach: Es reicht ein einziger memory safety bug 
aus, um das gesamte System zu Fall zu bringen. Ein Totalschaden, 
sozusagen. Das ist bereits der worst-case, der nicht schlimmer wird, nur 
weil es noch 10 weitere memory safety bugs in der Software gibt.

von DPA (Gast)


Lesenswert?

Ich habe schon lange kein Programm mehr abstürzen sehen. Mal ehrlich, 
den zeitlichen Mehraufwand ist es nicht wert, sich mit dem checker herum 
zu schlagen. Erfahrene Entwickler wie ich wissen, was sie tun.

von cppbert (Gast)


Lesenswert?

DPA schrieb:
> Ich habe schon lange kein Programm mehr abstürzen sehen. Mal
> ehrlich,
> den zeitlichen Mehraufwand ist es nicht wert, sich mit dem checker herum
> zu schlagen. Erfahrene Entwickler wie ich wissen, was sie tun.

ich arbeite hin und wieder an einem +3 Mio Zeilen Projekt mit >40 
Entwicklern
- wie viel Kontrolle hast du über deine Projekte?

Es geht nicht nur um Abstürze - es geht auch um die Folgefehler die sich 
durch Speicherfehlern ergeben und die passieren oft einfach nur wenn du 
auch mal durch den Code läufst - Security-Problem kommen nicht durch 
abstürzende Software - und wenn deine Software nicht Secure sein muss 
oder nicht so viele Leute dran arbeiten kann es einfach sein das in 
deiner Domäne die Rust Features Null Bedeutung haben

Ich verdiene mein Geld häufig damit große Systeme aufzuräumen/tief 
fehlerfrei zu bekommen - noch keine Software ob klein oder groß hat 
einen ASAN oder TSAN ohne Findings überstanden - keiner der Fehler hat 
direkt Menschen töten können, aber entfernt wurden trotzdem alle

Ich schreibe Rust fast genau so problemlos wie C++ - warum sollte ich 
auf den Schutz verzichten - oder besser sogar dagegen argumentieren :)

von cppbert (Gast)


Lesenswert?

Kein C/C++ Entwickler wechselt zu Rust nur weil seine Software ständig 
abstürzt - das ist nicht der Antrieb, und das Problem hat wirklich 
niemand - es ist u.a. die 100% Speichersicherheit at Kompiletime - von 
Anfang bis zum Tod des Projektes

von MaWin O. (mawin_original)


Lesenswert?

DPA schrieb:
> Ich habe schon lange kein Programm mehr abstürzen sehen

Da sieht man mal wieder, dass du gar nicht weißt, wovon du sprichst.

Rust verhindert den Absturz eines defekten Programms auch nicht immer.
Aber es verhindert, dass ein solcher Fehler ausgenutzt werden kann.

> Erfahrene Entwickler wie ich wissen, was sie tun.

Ja genau.
Das wird uns seit 30 Jahren erzählt. Und die Anzahl der Security-Bugs 
wurden nie weniger. Selbst mit Checker-Tools wurde die Anzahl nicht 
reduziert.
Es ist also Bullshit.

Doch weißt du, was die Anzahl der Bugs (in Android) schlussendlich dann 
doch reduziert - oder besser gesagt stand heute auf Null gebracht - 
hat?

Rate mal.

https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

von c-hater (Gast)


Lesenswert?

MaWin O. schrieb:

> Doch weißt du, was die Anzahl der Bugs (in Android) schlussendlich dann
> doch reduziert

Das ist objektiv wahr.

> - oder besser gesagt stand heute auf Null gebracht -

Das allerdings nicht. War auch nicht im Moment deines Postings wahr. 
Wird auch nirgendwo in deinem Link

https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

behauptet. Das hast du selbst frei erfunden.

von MaWin O. (mawin_original)


Lesenswert?

c-hater schrieb:
> Das allerdings nicht. War auch nicht im Moment deines Postings wahr.
> Wird auch nirgendwo in deinem Link
>
> https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
>
> behauptet. Das hast du selbst frei erfunden.

Ach. Gut.
Da ist es ja einfach, das Gegenteil zu beweisen:

Zitat:

> Security impact
>
> To date, there have been zero memory safety vulnerabilities discovered in
> Android’s Rust code.

Muss dir aber nicht peinlich sein. Du wolltest ja nur stänkern. Das sei 
dir gegönnt.

von Cppbert (Gast)


Lesenswert?

c-hater schrieb:
> behauptet. Das hast du selbst frei erfunden.

In dem Text steht das im Rust Code bisher keine security flaws 
aufgetaucht sind

Aber trotzdem wuerde ich den Blog Post an sich jetzt auch nicht als 
Beweis akzeptieren, aber Google, selbst die Sanitizer Entwickler und 
stark im Fuzzy Bereich scheinen schon fuer den System Bereich von Rust 
überzeugt zu sein, das kann man auch nicht einfach ignorieren

von Cppbert (Gast)


Lesenswert?

Cppbert schrieb:
> Aber trotzdem wuerde ich den Blog Post an sich jetzt auch nicht als
> Beweis akzeptieren

Hab mich blöd ausgedrückt, ich meinte nur das der Blog Post jetzt nicht 
so geeignet ist Ungeläubige zu überzeugen :)

von MaWin O. (mawin_original)


Lesenswert?

Cppbert schrieb:
> Hab mich blöd ausgedrückt, ich meinte nur das der Blog Post jetzt nicht
> so geeignet ist Ungeläubige zu überzeugen :)

Ich finde schon.
Er sagt:

Über mehr als eine Dekade haben wir ständig Security-Bugs und auch 
Checker helfen wenig bis gar nichts.

Doch dann setzen wir Rust ein und die Anzahl der Security-Bugs reduziert 
sich plötzlich auf Null.

Das, finde ich, ist schon ein einfach verständliches Argument.
Auch für Anfänger und Ungläubige.

Und ja, mir ist klar, dass auch Rust in Zukunft Securityprobleme haben 
wird. Das steht ja auch im Artikel. Aber es wird sehr sehr sehr sehr 
viel weniger sein, als mit allen anderen existierenden Techniken.

von DPA (Gast)


Lesenswert?

MaWin O. schrieb:
> Doch dann setzen wir Rust ein und die Anzahl der Security-Bugs reduziert
> sich plötzlich auf Null.

Memory safety bugs != security bugs.

Security bugs sind Probleme, die von anderen auf eine Art und Weise 
ausgenutzt werden können, die problematisch ist, z.B. weil man dann 
Dinge tun kann, die nicht vorgesehen waren. Auch so Sachen wie XSS, 
fehlende Berechtigungschecks, die üblichen deserialisierungsbugs in 
Java, etc. fallen darunter.

Und nicht nur sind security bugs oft keine memory safety, memory safety 
bugs müssen nicht immer security bugs sein.
So wird mir z.B. ein Speicherfehler in meinem lokalen Minesweeper Game 
sicher keine Sicherheitsrelevanten Probleme bereiten.

von MaWin O. (mawin_original)


Lesenswert?

DPA schrieb:
> ...

Ja. Blah.

Du kannst die Begriffe so lange verdrehen, wie du es willst.

Aus dem Kontext ist ganz offensichtlich klar, was ich gesagt habe.
Du lenkst ab.

Ich habe mich auf das bezogen, was der Artikel aussagt.
Und das ist halt:
> Früher ganz viel -> Jetzt Null
> Wegen Rust.

Das ist Fakt.

Und das ist leider eindeutig. Egal, wie du es nennst.

von Siggi A. (Gast)


Lesenswert?

Von
https://opensrcsec.com/open_source_security_announces_rust_gcc_funding
bis
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607959.html
hat es doch etwas gedauert..

Was fehlt jetzt noch um meinen geliebten attiny85 mit gccrs zu 
programmieren?

Wie lange muss man noch auf GCC v14 warten?

von MaWin O. (mawin_original)


Lesenswert?

Siggi A. schrieb:
> Was fehlt jetzt noch um meinen geliebten attiny85 mit gccrs zu
> programmieren?

Warum mit gccrs?
Das kannst du heute mit dem offiziellen Nightly-Release von rustc tun.

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin O. schrieb:
> Siggi A. schrieb:
>> Was fehlt jetzt noch um meinen geliebten attiny85 mit gccrs zu
>> programmieren?
>
> Warum mit gccrs?
> Das kannst du heute mit dem offiziellen Nightly-Release von rustc tun.

Die Version 1.66 hat nur avr-unknown-gnu-atmega328

von cppbert (Gast)


Lesenswert?


von cppbert (Gast)


Lesenswert?

cppbert schrieb:
> hab ein Beispiel für deinen geliebten attiny85 gefunden - keine Ahnung
> ob das qualitativ hochwertig ist

Es scheint in Teil auf dem avr-gcc zu basieren oder wenigstens wird 
dessen Linker verwendet - könnte sein das es nicht ganz so 
out-of-the-box funktioniert wie es gewünscht ist, aber AVR ist glaube 
ich auch erst vor ein paar Monaten zu Rust gekommen

@Siggi A.

Wäre schön wenn du deine Erfahrungen damit hier einbringen könntest

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> Die Version 1.66 hat nur avr-unknown-gnu-atmega328

Das ist nicht wahr.

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin O. schrieb:
> Wilhelm M. schrieb:
>> Die Version 1.66 hat nur avr-unknown-gnu-atmega328
>
> Das ist nicht wahr.

$ rustc --print target-list | grep avr 
avr-unknown-gnu-atmega328
$ rustc --version
rustc 1.66.0 (69f9c33d7 2022-12-12) (Arch Linux rust 1:1.66.0-1)

von MaWin O. (mawin_original)


Lesenswert?

cppbert schrieb:
> s scheint in Teil auf dem avr-gcc zu basieren oder wenigstens wird
> dessen Linker verwendet

Es "basiert" nicht auf avr-gcc.
Es wird nur der Linker verwendet. Wie bei jeder anderer Rust-Plattform 
auch. Rust hat keinen eigenen Linker.

Derzeit wird für die startup-Routinen auch noch avr-libc verwendet.

> könnte sein das es nicht ganz so
> out-of-the-box funktioniert wie es gewünscht ist,

Doch. Es funktioniert out of the box. Einfach so.
Probiere es doch einfach mal aus.

Rust-Nightly installieren und das tun, was im Readme eines AVR-Beispiels 
steht:

https://github.com/avr-rust/template-bin.git

(Das ruduino-crate würde ich allerdings nicht empfehlen. Da gibts mit 
avr-device und avr-hal besseres)

> aber AVR ist glaube
> ich auch erst vor ein paar Monaten zu Rust gekommen

Das ist nicht wahr. Es ist schon seit Jahren drin.
Es war allerdings ein paar Monate lang wegen eines LLVM-Bugs defekt.
Das wurde vor ein paar Monaten behoben.

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> $ rustc --print target-list | grep avr

Ja, Wilhelm. Das heißt nicht, dass nur der 328er unterstützt wird.

von MaWin O. (mawin_original)


Lesenswert?

Von avr-device werden derzeit diese Chips unterstützt:

https://docs.rs/avr-device/0.4.0/avr_device/

avr-device is ein PAC. (Peripheral Access Crate). Das ist die Schicht 
unter der HAL. Im PAC wird die vorhandene Hardware/Peripherie 
beschrieben.

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin O. schrieb:
> Wilhelm M. schrieb:
>> $ rustc --print target-list | grep avr
>
> Ja, Wilhelm. Das heißt nicht, dass nur der 328er unterstützt wird.

Dann ist die Ausgabe aber sehr verwirrend ;-)

Und welche werden bei dem Target avr-unknown-gnu-atmega328 
unterstützt???

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> Und welche werden bei dem Target avr-unknown-gnu-atmega328
> unterstützt???

Soweit ich weiß alle. Die unterscheiden sich ja kaum auf CPU-Ebene.
Es kommt eher darauf an, was das von dir verwendete PAC unterstützt. Und 
da habe ich den Link oben geliefert.

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin O. schrieb:
> Wilhelm M. schrieb:
>> Und welche werden bei dem Target avr-unknown-gnu-atmega328
>> unterstützt???
>
> Soweit ich weiß alle. Die unterscheiden sich ja kaum auf CPU-Ebene.

Doch schon. Die Megas haben Instruktionen, die die Tinys nicht haben. 
Dann werden falsche Op-Codes generiert für die Tinys, bzw. die ganz 
neuen AVR werden nicht optimal genutzt.

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> Dann werden falsche Op-Codes generiert für die Tinys

Das sagst du jetzt einfach so, obwohl du es nie ausprobiert hast?
Unfassbar.

Wie gesagt, beim avr-device PAC gibt es eine Liste von unterstützten 
Devices.
Schaue dir das und das Template-crate an.

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin O. schrieb:
> Wilhelm M. schrieb:
>> Dann werden falsche Op-Codes generiert für die Tinys
>
> Das sagst du jetzt einfach so, obwohl du es nie ausprobiert hast?
> Unfassbar.

Ich glaube erst einmal nur der Ausgabe von rustc, sonst nichts. Und wenn 
dort das Target mega328 steht, dann glaube ich das auch. Sonst nichts. 
Wenn das target mega328 was auch bedeutet, das tiny, tiny0, tiny1, 
mega0, mega0 und mega1, xmega unetrstützt werden ist das evtl. schön. 
Allerdings frage ich mich dann, wie rustc dann die notwendige 
Unterscheidung für den Core hin bekommt.

Aber das kannst Du sicher ganz einfach erklären.

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> Allerdings frage ich mich dann, wie rustc dann die notwendige
> Unterscheidung für den Core hin bekommt.

Wie wäre es, wenn du dir das template endlich einmal anschaust? Schaffst 
du das?

https://github.com/avr-rust/template-bin/blob/master/avr-atmega328p.json

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin O. schrieb:
> Wilhelm M. schrieb:
>> Allerdings frage ich mich dann, wie rustc dann die notwendige
>> Unterscheidung für den Core hin bekommt.
>
> Wie wäre es, wenn du dir das template endlich einmal anschaust? Schaffst
> du das?
>
> https://github.com/avr-rust/template-bin/blob/master/avr-atmega328p.json

Habe ich geschafft ;-)

Und dort steht ja gerade -mmcu=atmega328p.

Jetzt erklär mal bitte, wie der Code dann auf einem tiny laufen soll.

Beitrag #7293720 wurde von einem Moderator gelöscht.
von cppbert (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Allerdings frage ich mich dann, wie rustc dann die notwendige
> Unterscheidung für den Core hin bekommt.

das grenzt man noch weiter ein - aber ja ich geben dir recht das hat 
mich auch zuerst verwirrt - aber die von vielen hier gezeigte "das ist 
dann bestimmt irgendwie ein Fehler" Mentalität kann ich echt nicht 
nachvollziehen - das machen so viele hier

von cppbert (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Jetzt erklär mal bitte, wie der Code dann auf einem tiny laufen soll.

war doch in meinem ersten Beispiel Post

https://github.com/eric-wood/rust-attiny85-example/blob/main/avr-attiny85.json

vergleich die beiden jsons

von Wilhelm M. (wimalopaan)


Lesenswert?

cppbert schrieb:
> Wilhelm M. schrieb:
>> Jetzt erklär mal bitte, wie der Code dann auf einem tiny laufen soll.
>
> war doch in meinem ersten Beispiel Post
>
> https://github.com/eric-wood/rust-attiny85-example/blob/main/avr-attiny85.json
>
> vergleich die beiden jsons

Ja, schon klar.

Nur MaWin behauptete zum Target atmega328 folgendes:

MaWin O. schrieb:
> Soweit ich weiß alle.

Und das ist definitiv falsch.

von cppbert (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Nur MaWin behauptete zum Target atmega328 folgendes:
>
> MaWin O. schrieb:
>> Soweit ich weiß alle.
>
> Und das ist definitiv falsch.

willst du jetzt wissen ob es geht oder mit MaWin das 
Er-hat-recht-du-hast-recht-Spiel-spielen?

von Wilhelm M. (wimalopaan)


Lesenswert?

cppbert schrieb:
> Wilhelm M. schrieb:
>> Nur MaWin behauptete zum Target atmega328 folgendes:
>>
>> MaWin O. schrieb:
>>> Soweit ich weiß alle.
>>
>> Und das ist definitiv falsch.
>
> willst du jetzt wissen ob es geht oder mit MaWin das
> Er-hat-recht-du-hast-recht-Spiel-spielen?

Das es nicht geht in Version 1.66, weiß ich ja bereits wie oben schon 
geschrieben:

$ rustc --target=avr-unknown-gnu-attiny85
error: Error loading target specification: Could not find specification 
for target "avr-unknown-gnu-attiny85". Run `rustc --print target-list` 
for a list of built-in targets

von cppbert (Gast)


Lesenswert?

MaWins Sätzen sind manchmal ein wenig zu schroff - aber er kommt immer 
recht schnell wieder auf den Punkt das man was erreichen/wissen will und 
hat zu 95% recht - viele andere hier spielen dann Wer-hat-recht Kette 
durch - um jede 5% Recht haben - das ist es nicht wert

von cppbert (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Das es nicht geht in Version 1.66, weiß ich ja bereits wie oben schon
> geschrieben:

ok, sorry das ging unter

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> Und das ist definitiv falsch.

Weil du das sagst?

Hast du beim avr-gcc auch einen separaten Compiler für jedes Target, 
oder machst du das per -mmcu?

Du bist ein Laberkopp.

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin O. schrieb:
> Wilhelm M. schrieb:
>> Und das ist definitiv falsch.
>
> Weil du das sagst?

Nö, weil Atmel das so designed hat.

>
> Hast du beim avr-gcc auch einen separaten Compiler für jedes Target,
> oder machst du das per -mmcu?

Genau. Und die Option -mmcu hat rustc nicht, deswegen verwendet man dort 
--target. Und ein target für attiny85 gibt es in Version 1.66 eben 
nicht. S.a. mein Beitrag oben.

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> Nö, weil Atmel das so designed hat.

Atmel???

> Genau. Und die Option -mmcu hat rustc nicht, deswegen verwendet man dort
> --target.

Nein, tut man nicht.
Würdest du dir endlich mal das Beispiel anschauen? Hm? Wie wäre das?

Du machst dich hier einfach nur zur Kartoffel.

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin O. schrieb:
> Wilhelm M. schrieb:
>> Nö, weil Atmel das so designed hat.
>
> Atmel???
>
>> Genau. Und die Option -mmcu hat rustc nicht, deswegen verwendet man dort
>> --target.
>
> Nein, tut man nicht.
> Würdest du dir endlich mal das Beispiel anschauen? Hm? Wie wäre das?

Es ist doch nur eine Zeile, oder?

$ rustc bla.rs --target=???

Nenne mir einfach den passenden String für ??? oder den gesamten 
rustc-Aufruf für das target attiny85 in Version 1.66.

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> Es ist doch nur eine Zeile, oder?
>
> $ rustc bla.rs --target=???
>
> Nenne mir einfach den passenden String für ??? oder den gesamten
> rustc-Aufruf für das target attiny85 in Version 1.66.

Niemand ruft rustc direkt auf. Auf keiner Plattform.
Deshalb kann ich dir auswendig den Aufruf auch nicht nennen.

Alle Leute, inclusive des Beispiels (!) nutzen Cargo mit einem 
entsprechenden json (bei AVR) zur Konfiguration des Targets.

Was Cargo daraus für rustc macht, weiß ich nicht.

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin O. schrieb:
> Wilhelm M. schrieb:
>> Es ist doch nur eine Zeile, oder?
>>
>> $ rustc bla.rs --target=???
>>
>> Nenne mir einfach den passenden String für ??? oder den gesamten
>> rustc-Aufruf für das target attiny85 in Version 1.66.
>
> Niemand ruft rustc direkt auf. Auf keiner Plattform.
> Deshalb kann ich dir auswendig den Aufruf auch nicht nennen.
>
> Alle Leute, inclusive des Beispiels (!) nutzen Cargo mit einem
> entsprechenden json (bei AVR) zur Konfiguration des Targets.
>
> Was Cargo daraus für rustc macht, weiß ich nicht.

Aaaach soo ;-)

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
>> Was Cargo daraus für rustc macht, weiß ich nicht.
>
> Aaaach soo ;-)

Ja. Jetzt hast du die 5% gefunden, die cppbert meint.
Glückwunsch.

Am der ursprünglichen Tatsache der unterstützten Chips ändert das aber 
rein gar nichts.
Und wenn du dir das Beispiel endlich einmal anschauen und ausprobieren 
würdest, dann könntest du selbst ganz einfach herausfinden, wie der 
rustc-Aufruf ist.
Aber das willst du ja gar nicht.

von cppbert (Gast)


Lesenswert?

MaWin O. schrieb:
> Aber das willst du ja gar nicht.

ich glaube er will schon, aber ist es eben anders gewohnt - manche 
machen in einem neuen System erstmal genau das was sie kennen und wenn 
es dann nicht klappt steigt die Verwirrung - ist eben so, aber auch 
nicht wirklich schlimm

von MaWin O. (mawin_original)


Lesenswert?

cppbert schrieb:
> ist eben so, aber auch nicht wirklich schlimm

Es ist schlimm, weil hier zum X-ten Male mit Links vorgekaut wurde, wie 
es richtig geht.

Das ist einfach nur unverschämt den Forenteilnehmern gegenüber.

von DPA (Gast)


Lesenswert?

Bei einem simplen Makefile wüsste man sofort, was da abgeht. Aber die 
für rust zu schreiben, ist zwar möglich, aber halt leider nicht mehr so 
einfach / praktikabel. Aber wer will schon wissen, wie das zeug 
funktioniert? Ist ja jetzt so viel einfacher, wo cargo alles für einen 
macht, irgendwie...

von MaWin O. (mawin_original)


Lesenswert?

DPA schrieb:
> Bei einem simplen Makefile wüsste man sofort, was da abgeht.

Was ist bei dem Cargo.toml und dem json aus dem Beispiel-Template nicht 
einfach zu verstehen?

Werde doch einmal konkret, bitte. Was wäre in einem Makefile besser zu 
sehen und zu verstehen?

> ist ja jetzt so viel einfacher, wo cargo alles für einen
> macht, irgendwie...

Ja, es ist viel einfacher.

Aber warum benutzt du make? Mit deiner Argumentation solltest du den gcc 
selbst per Hand aufrufen und kein böses Buildsystem (wie make) nutzen.
Das make verkompliziert nur den simplen gcc-Aufruf! Regeln, Rezepte, 
Variablen, Abhängigkeiten. Alles das braucht man gar nicht, wenn man gcc 
direkt aufruft! Wozu also dieses komplizierte make-System?

von cppbert (Gast)


Lesenswert?

DPA schrieb:
> Bei einem simplen Makefile wüsste man sofort

aber auch nur die welche häufig mit Makefiles arbeiten und Makefiles 
sind echt nicht so schön wenn es grosse Multi-Platform-Projekte mit 
vielen Dependencies usw sind - das wissen alle aus langer Erfahrung :)

ein bisschen (drastischer) Umstellen darf erlaubt sein sonst kann man ja 
gar nichts machen

von Daniel A. (daniel-a)


Lesenswert?

MaWin O. schrieb:
> DPA schrieb:
>> Bei einem simplen Makefile wüsste man sofort, was da abgeht.
>
> Was ist bei dem Cargo.toml und dem json aus dem Beispiel-Template nicht
> einfach zu verstehen?

Du hast selbst gesagt, du weisst nicht, wie der rustc Aufruf bei dem 
ding oben am Schluss aussieht. In einem Makefile steht ziemlich genau 
das drin. Zum bauen von X, führe Y aus. Das ist viel transparenter.

von cppbert (Gast)


Lesenswert?


von cppbert (Gast)


Lesenswert?

Daniel A. schrieb:
> In einem Makefile steht ziemlich genau
> das drin. Zum bauen von X, führe Y aus. Das ist viel transparenter.

das weiß jeder hier - auch MaWin - Cargo ist eben ein wenig anders als 
make - mehr kann man da nicht diskutieren

von MaWin O. (mawin_original)


Lesenswert?

cppbert schrieb:
> aber auch nur die welche häufig mit Makefiles arbeiten und Makefiles
> sind echt nicht so schön wenn es grosse Multi-Platform-Projekte mit
> vielen Dependencies usw sind - das wissen alle aus langer Erfahrung :)
>
> ein bisschen (drastischer) Umstellen darf erlaubt sein sonst kann man ja
> gar nichts machen

Genau so sieht es nämlich aus.
In Makefiles ist so gut wie nichts standardisiert.
Wo man da das Target umstellt, hat sich jeder Entwickler selbst 
ausgedacht und selbst neu erfunden.

Bei Cargo ist das alles immer gleich.
Cargo-Projekte können zwar auch komplex werden. Wenn man z.B. ein 
build.rs verwendet. Aber selbst dann ist es einfacher als make, weil die 
Stellen wo man anfangen muss zu schauen immer gleich sind.
Bei Makefiles hat sich das hingegen jeder Entwickler neu ausgedacht.

von MaWin O. (mawin_original)


Lesenswert?

Daniel A. schrieb:
> Du hast selbst gesagt, du weisst nicht, wie der rustc Aufruf bei dem
> ding oben am Schluss aussieht.

Weil ich es nicht brauche.
Weil so gut wie niemand es braucht. Auch du nicht.
Und genau deshalb schaue ich es auch nicht nach. Das ist nutzloses 
Wissen.

> In einem Makefile steht ziemlich genau
> das drin. Zum bauen von X, führe Y aus. Das ist viel transparenter.

Ich glaube du hast noch nie ein Makefile aus der realen Welt gesehen.

von Daniel A. (daniel-a)


Lesenswert?

Ich habe sogar Projekte, die eigentlich nur ein grosses Makefile sind. 
z.B. https://github.com/Daniel-Abrecht/dpa-image-builder

Ok, es gibt noch Sachen die Makefiles generieren, z.B. Automake, und 
dass will man dann wirklich nicht unbedingt lesen. Aber ein normales, 
simples, handgeschriebenes Makefile, ist wie ein wundervolles Kunstwerk. 
Maximale Einfachheit und Transparenz, ohne Einschränkungen. Das 
platonische Ideal der eines Build Tools!

von MaWin O. (mawin_original)


Lesenswert?

Daniel A. schrieb:
> Ich habe sogar Projekte, die eigentlich nur ein grosses Makefile sind.
> z.B. https://github.com/Daniel-Abrecht/dpa-image-builder

https://github.com/Daniel-Abrecht/dpa-image-builder/blob/master/makefile

Hm hm. Ja ja.
Sehr einfach zu lesen, dein Makefile.
Ich verstehe sofort, was es tut.

Dagegen ist ein Cargo.toml
https://github.com/avr-rust/template-bin/blob/master/Cargo.toml
und ein json
https://github.com/avr-rust/template-bin/blob/master/avr-atmega328p.json
ja geradezu Hexenwerk und schwer verständlich!

Bei Cargo kann man sogar in die Doku gucken und man bekommt alles sehr 
genau erklärt. Da lobe ich mir tatsächlich ein undokumentiertes 
Makefile. Da wird man noch gefordert!

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin O. schrieb:
> cppbert schrieb:
>> ist eben so, aber auch nicht wirklich schlimm
>
> Es ist schlimm, weil hier zum X-ten Male mit Links vorgekaut wurde, wie
> es richtig geht.
>
> Das ist einfach nur unverschämt den Forenteilnehmern gegenüber.

Es ging sehr konkret um diese Frage:

Beitrag "Re: Rust - ist das hier um zu bleiben?"

Und Deine Antwort darauf:

MaWin O. schrieb:
> Wilhelm M. schrieb:
>> $ rustc --print target-list | grep avr
>
> Ja, Wilhelm. Das heißt nicht, dass nur der 328er unterstützt wird.

Es nicht um cargo mit einer geeigneten target-definition, wie Du siehst. 
Sondern es ging um rustc und die damit ausgelieferte target-definition 
ausschließlich für den m328.

Und dann noch diese Deine Antwort:

MaWin O. schrieb:
> Wilhelm M. schrieb:
>> Und welche werden bei dem Target avr-unknown-gnu-atmega328
>> unterstützt???
>
> Soweit ich weiß alle. Die unterscheiden sich ja kaum auf CPU-Ebene.
> Es kommt eher darauf an, was das von dir verwendete PAC unterstützt. Und
> da habe ich den Link oben geliefert.

Und das ist eben irreführend bzw. falsch.

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> Es nicht um cargo mit einer geeigneten target-definition, wie Du siehst.

Ja. Dann machst du es halt falsch.
So einfach ist das.

Nutze Cargo, wie jeder vernünftige Mensch, oder finde halt selbst raus, 
wie der rustc-Aufruf sein muss.
Ich kann es dir nicht sagen und es spielt auch überhaupt keine Rolle, 
wie der rustc-Aufruf genau aussieht.
Ich werde das jetzt nicht für dich recherchieren, weil es sinnlos ist.

Hier ist die bereits gepostete Doku, die du bestimmt wieder nicht lesen 
wirst:
https://book.avr-rust.com/005.1-the-target-specification-json-file.html

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
>> Soweit ich weiß alle. Die unterscheiden sich ja kaum auf CPU-Ebene.
>> Es kommt eher darauf an, was das von dir verwendete PAC unterstützt. Und
>> da habe ich den Link oben geliefert.
>
> Und das ist eben irreführend bzw. falsch.

Was ist daran falsch?

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin O. schrieb:
> Wilhelm M. schrieb:
>>> Soweit ich weiß alle.
>>
>> Und das ist eben irreführend bzw. falsch.
>
> Was ist daran falsch?

Habe ich Dir oben doch schon erklärt: der Core der AVRs ist 
unterschiedlich. Daher passt das m328 target nicht auf einen anderen µC 
z.B. tiny oder DA, DB, DD.

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin O. schrieb:
> Ja. Dann machst du es halt falsch.

Nö.
Die richtige Antwort wäre gewesen, die korrekte Target-Definition für 
rustc zu erzeugen. Aber Du kennst Dich eben mit rustc nicht aus ...

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> Habe ich Dir oben doch schon erklärt: der Core der AVRs ist
> unterschiedlich. Daher passt das m328 target nicht auf einen anderen µC
> z.B. tiny oder DA, DB, DD.

Ich habe auch nie behauptet, dass ein für m328 kompiliertes 
Rust-Programm auf einem Tiny lauffähig wäre.

Lies doch bitte die Doku. Dort steht, wie man das Target angibt:
https://book.avr-rust.com/005.1-the-target-specification-json-file.html

Oder gucke dir das Tiny-Beispiel an.

Was falsch ist, ist lediglich deine Aussage, dass der Rustcompiler nur 
das m328-Target unterstützt.

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> Aber Du kennst Dich eben mit rustc nicht aus ...

So wirds sein. Genau.
Danke für diese Erkenntnis.
Zum Glück hast du mir das als Rust-Experte einmal erklärt.

Es ist unfassbar, wie stur man sein kann, lieber Wilhelm.

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin O. schrieb:
> Wilhelm M. schrieb:
>> Habe ich Dir oben doch schon erklärt: der Core der AVRs ist
>> unterschiedlich. Daher passt das m328 target nicht auf einen anderen µC
>> z.B. tiny oder DA, DB, DD.
>
> Ich habe auch nie behauptet, dass ein für m328 kompiliertes
> Rust-Programm auf einem Tiny lauffähig wäre.

Hier nochmal zum Nachlesen:

Wilhelm M. schrieb:
> MaWin O. schrieb:
>> Wilhelm M. schrieb:
>>> Und welche werden bei dem Target avr-unknown-gnu-atmega328
>>> unterstützt???
>>
>> Soweit ich weiß alle. Die unterscheiden sich ja kaum auf CPU-Ebene.
>> Es kommt eher darauf an, was das von dir verwendete PAC unterstützt. Und
>> da habe ich den Link oben geliefert.

Auf die Frage, welche AVRs beim dem Target m328 unterstützt werden, kam 
also Deine Antwort: "Soweit ich weiß alle".

Dann solltest Du mal erklären, wie das gemeint war.

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> Auf die Frage, welche AVRs beim dem Target m328 unterstützt werden, kam
> also Deine Antwort: "Soweit ich weiß alle".

Nein. Die Frage, welche AVRs das m328-Target unterstützt ist doch wohl 
trivial: Es unterstützt den m328.
Ich dachte das wäre auch dir klar.
Ich hätte es nicht für möglich gehalten, dass du tatsächlich fragst, 
welche Controller das m328-Target unterstützt. Aber so kann man sich 
irren. Also noch einmal für dich: Ja, das m328-Target unterstützt nur 
den m328-Controller. Wer hätte das gedacht.

Aber das spielt zum Glück alles gar keine Rolle, denn es ging die ganze 
Zeit um den AVR-Rust-Compiler. Und dieser unterstützt nun eben auch mehr 
Targets als nur den m328. Und zwar - soweit ich weiß - alle, weil die 
sich eben kaum unterscheiden. Und weil das zu 99% eine LLVM-Sache ist.

Du hast behauptet, dass er nur das m328-Target und damit nur den 
m328-Controller unterstützt. Und das ist eben ganz einfach falsch.

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin O. schrieb:
> Aber das spielt zum Glück alles gar keine Rolle, denn es ging die ganze
> Zeit um den AVR-Rust-Compiler. Und dieser unterstützt nun eben auch mehr
> Targets als nur den m328. Und zwar - soweit ich weiß - alle, weil die
> sich eben kaum unterscheiden. Und weil das zu 99% eine LLVM-Sache ist.

Dann die nä. Frage: das llvm-avr backend ist noch experimental, oder?

Ich bin nicht ganz up-to-date, aber das letzte mal, als ich 
clang/clang++ für AVR ausprobiert habe ((vor)letztes Jahr?) kam da 
jedenfalls grottenschlechter Code raus.

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> Dann die nä. Frage: das llvm-avr backend ist noch experimental, oder?

Auch diese Frage wurde bereits hier beantwortet:
AVR-Rust gibts im Nightly-Zweig.

> Ich bin nicht ganz up-to-date, aber das letzte mal, als ich
> clang/clang++ für AVR ausprobiert habe ((vor)letztes Jahr?)

Probiere es doch zur Abwechslung einfach einmal aus.

> kam da jedenfalls grottenschlechter Code raus.

"Grottenschlecht" ist er nicht.
Aber ja, einige der AVR-spezifischen Optimierungen, die der avr-gcc im 
backend macht, macht der llvm noch nicht.

von MaWin O. (mawin_original)


Lesenswert?

MaWin O. schrieb:
> Aber ja, einige der AVR-spezifischen Optimierungen, die der avr-gcc im
> backend macht, macht der llvm noch nicht.

Viele davon sind bei Rust aber auch gar nicht nötig.
Es gibt z.B. keine int-Promotion in Rust. Ein u8 ist ein u8. Da braucht 
das Backend gar nichts zu optimieren, weil Rust ein u8 nicht auf i16 
promoviert, wie C das auf AVR tut.
Deshalb kann es auch keine dem entsprechenden unnötigen Instruktionen 
geben, die dann wieder umständlich im Backend herausoptimiert werden 
müssen.

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin O. schrieb:
> Auch diese Frage wurde bereits hier beantwortet:
> AVR-Rust gibts im Nightly-Zweig.

Du hast mich nicht verstanden.
Zur Info: mein rustc version 1.66 unterstützt avr (aber eben nur den 
m328, wie wir eben festgestellt haben, einfach mangels 
target-definition).

rustc basiert auf llvm mit dem llvm-avr backend, und das ist 
experimentell immer noch, soweit ich weiß.

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> Zur Info: mein rustc version 1.66 unterstützt avr (aber eben nur den
> m328, wie wir eben festgestellt haben

Du hast es echt immer noch nicht verstanden?
Dein rustc unterstützt auch andere Targets!

> rustc basiert auf llvm mit dem llvm-avr backend, und das ist
> experimentell immer noch, soweit ich weiß.

MaWin O. schrieb:
> Auch diese Frage wurde bereits hier beantwortet:
> AVR-Rust gibts im Nightly-Zweig.

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin O. schrieb:
> Wilhelm M. schrieb:
>> Zur Info: mein rustc version 1.66 unterstützt avr (aber eben nur den
>> m328, wie wir eben festgestellt haben
>
> Du hast es echt immer noch nicht verstanden?
> Dein rustc unterstützt auch andere Targets!

Aber sicher habe ich Dich verstanden ;-)

Der rustc unterstützt nur dann andere Targets, wenn man ihm andere 
target-definitionen gibt. Aber andere als für den m328 sind in Version 
1.66 einfach nicht dabei. Das ist dieselbe Mechanik, wie beim avr-gcc 
auch.

: Bearbeitet durch User
von Links (nicht Rechts) (Gast)


Lesenswert?

Vielleicht erhellen diese Links die Sachlage etwas:

https://book.avr-rust.com/

https://book.avr-rust.com/003.1-the-avr-unknown-gnu-atmega328-target.html

https://book.avr-rust.com/005.1-the-target-specification-json-file.html

Unten im letzten Link steht z.B.
"Adapting a target specification JSON to another AVR variant is trivial.

Options that must be updated to target individual microcontroller 
variants:

    cpu - set to the lower-case model name of the desired AVR variant
    pre-link-args - the correct -mmcu option, always equal to the cpu, 
must be updated"

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> Der rustc unterstützt nur dann andere Targets, wenn man ihm andere
> target-definitionen gibt. Aber andere als für den m328 sind in Version
> 1.66 einfach nicht dabei.

Das ist doch grob irreführender Quatsch.
Du musst in der json-Datei deine CPU eintragen. Fertig. Das wars. Mehr 
ist nicht zu tun.
Das ist es, worüber so hier einen riesigen Aufriss machst.

Du machst dich hier absolut lächerlich.

von Wilhelm M. (wimalopaan)


Lesenswert?

Links (nicht Rechts) schrieb:
> Vielleicht erhellen diese Links die Sachlage etwas:

Ist bekannt: nicht anderes habe ich oben geschrieben

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin O. schrieb:
> Wilhelm M. schrieb:
>> Der rustc unterstützt nur dann andere Targets, wenn man ihm andere
>> target-definitionen gibt. Aber andere als für den m328 sind in Version
>> 1.66 einfach nicht dabei.
>
> Das ist doch grob irreführender Quatsch.

Nö.

$ rustc --print target-list | grep avr
avr-unknown-gnu-atmega328

von cppbert (Gast)


Lesenswert?

Wilhelm M. schrieb:
> $ rustc --print target-list | grep avr
> avr-unknown-gnu-atmega328

du bekommst das nicht als target - egal wie oft du das forderst - es 
wird über das Json eingestellt und niemals mit --print target-list 
kommen, das steht doch in der Doku

btw: ist das alles eh nur in Nighlty und ich glaube du arbeitest mit 
Release

von Wilhelm M. (wimalopaan)


Lesenswert?

cppbert schrieb:
> btw: ist das alles eh nur in Nighlty und ich glaube du arbeitest mit
> Release

Ja, auch das habe ich ganz oben schon gesagt: Version 1.66

von Wilhelm M. (wimalopaan)


Lesenswert?

cppbert schrieb:
> du bekommst das nicht als target

Doch, ein Target für avr gibt es eben in Version 1.66

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> Doch, ein Target für avr gibt es eben in Version 1.66

Wenn du es einmal ausprobiert hättest, hättest du auch gemerkt, dass es 
mit stable nicht funktioniert und du nightly brauchst, wie hier schon 
etliche Male gesagt.

Aber du bis ja vollkommen beratungsresistent.

von cppbert (Gast)


Lesenswert?

hier steht das alles drin: 
https://book.avr-rust.com/001-introduction.html

das man Nightly braucht (und nicht Stable), wie man ein 
nicht-unknown-gnu-atmega328 supported (mit json)
was man alles installieren muss und kleine Beispiele

ich würde das auch gerne kurz Durchspielen aber will jetzt nicht 
unbedingt ohne not (hab kein AVR auf dem Tisch) die gcc-avr Sachen auf 
meinem Windows installieren

von Links (nicht Rechts) (Gast)


Lesenswert?

cppbert schrieb:
> hier steht das alles drin:
> https://book.avr-rust.com/001-introduction.html

Aus https://book.avr-rust.com/002-installing-the-compiler.html ganz 
unten

"NOTE: Compiling Rust/LLVM can be very memory intensive. You may find 
compilation abruptly stopping on machines with less than ~10GB of RAM 
due to the operating system out-of-memory killer stopping it."

Auch wenn wir das Jahr 2022 schreiben. Das klingt nicht gerade nach 
KISS.

von cppbert (Gast)


Lesenswert?

Links (nicht Rechts) schrieb:
> Auch wenn wir das Jahr 2022 schreiben. Das klingt nicht gerade nach
> KISS.

gut das AVR Zeug ist definitiv noch nicht Super-Mainstream und OOM 
bekomme ich auch mit Qt 6.4 wenn ich alles mit gcc und allen Kernen baue 
in einer VM mit 8GB RAM

von MaWin O. (mawin_original)


Lesenswert?

Links (nicht Rechts) schrieb:
> Auch wenn wir das Jahr 2022 schreiben. Das klingt nicht gerade nach
> KISS.

Wann hast du das letzte Mal ein C++-Programm mit dem GCC auf einem 
Mehrkernrechner compiliert? 10 GB sind auch dafür zu wenig.

Cargo nutzt standardmäßig alle Kerne, die zur Verfügung stehen.

von Nano (Gast)


Lesenswert?

MaWin O. schrieb:
> Wilhelm M. schrieb:
>> Der rustc unterstützt nur dann andere Targets, wenn man ihm andere
>> target-definitionen gibt. Aber andere als für den m328 sind in Version
>> 1.66 einfach nicht dabei.
>
> Das ist doch grob irreführender Quatsch.
> Du musst in der json-Datei deine CPU eintragen. Fertig. Das wars. Mehr
> ist nicht zu tun.
> Das ist es, worüber so hier einen riesigen Aufriss machst.
>
> Du machst dich hier absolut lächerlich.

Hier ist er wieder, der MaWin, der nicht ohne persönliche Angriffe 
auskommt.

Dabei hätte es genügt einfach sachlich zu bleiben.

von MaWin O. (mawin_original)


Lesenswert?

Nano schrieb:
> Dabei hätte es genügt einfach sachlich zu bleiben.

Einem Troll gegenüber sachlich bleiben?
Nein, danke.

von Links (nicht Rechts) (Gast)


Lesenswert?

MaWin O. schrieb:
> Wann hast du das letzte Mal ein C++-Programm mit dem GCC auf einem
> Mehrkernrechner compiliert?

C++ finde ich auch reichlich überfrachtet und ich würde bei C++ auch 
nicht an KISS denken. Aber AVRs programmiert man auch eher in C oder 
Forth. Mir ist dabei schon klar, dass Rust nicht hpts. für AVRs 
entwickelt wurde.

von MaWin O. (mawin_original)


Lesenswert?

Links (nicht Rechts) schrieb:
> Mir ist dabei schon klar, dass Rust nicht hpts. für AVRs
> entwickelt wurde.

Das ist Unsinn.
Was hat das mit dem Speicher zu tun, den du auf der Buildmaschine zur 
Verfügung haben musst?

von Links (nicht Rechts) (Gast)


Lesenswert?

In den letzten Beiträgen ging es u.a. um die Programmierung von einem 
ATtiny85 mit 8K Flash und wenn man einen PC mit mehr als 10 GB RAM 
braucht, um den zu programmieren, ist das sprichwörtlich "mit Kanonen 
auf Spatzen schießen".

von MaWin O. (mawin_original)


Lesenswert?

Links (nicht Rechts) schrieb:
> In den letzten Beiträgen ging es u.a. um die Programmierung von einem
> ATtiny85 mit 8K Flash und wenn man einen PC mit mehr als 10 GB RAM
> braucht, um den zu programmieren, ist das sprichwörtlich "mit Kanonen
> auf Spatzen schießen".

Das kommt halt ganz auf dein Programm an, was du schreibst.
Genau, wie es bei C++ ist.

Wenn du hunderte Sources nutzt/schreibst, dann wollen die eben auch 
compiliert werden.

Das hat gar nichts mit AVR zu tun.

von Nano (Gast)


Lesenswert?

MaWin O. schrieb:
> Nano schrieb:
>> Dabei hätte es genügt einfach sachlich zu bleiben.
>
> Einem Troll gegenüber sachlich bleiben?
> Nein, danke.

Wilhelm M. war im Gegensatz zu dir sachlich. Sein Beitrag lässt nicht 
darauf schließen, dass er ein Troll wäre.

von MaWin O. (mawin_original)


Lesenswert?

Nano schrieb:
> Wilhelm M. war im Gegensatz zu dir sachlich. Sein Beitrag lässt nicht
> darauf schließen, dass er ein Troll wäre.

haha.
Genau.
Lustig.

Ein sachlicher Troll.

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

cppbert schrieb:
> Bist du ein Clone von rbx, du schreibst auch irgendwie fast genau wie er
> - so ein bisschen Fakten, bissel Emotionen, Somway Off-Topics aber
> irgendwie related - wilde Mischung
>
> oder bin ich schon so alt das mir dieser Whatsapp/Tiktok
> Kommunikationsstyle einfach nicht vertraut genug ist :)

Jetzt nicht, dass mich das nicht interessieren würde, oder dass ich mich 
wegen dem Alter nicht geschmeichelt fühlen würde:)
Trotzdem: Was soll der Scheiss? Wenn dir Einer wegen der Form anstössig 
abgeht und du komplett den Inhalt ignorierst ist das dein Ding.

Versteh ich aber. Das ist die Oberflächlichkeit womit der "kennste ... 
kennste?" ganze Stadien füllt.
Whatsapp/Tiktok: Absolute Jungfrau in dieser Beziehung, also laber 
keinen Flatterschiss und lassen wir den off-topic Quatsch.

Ich habe einen Aspekt von Rust untermauert und einen Grund, wieso es 
"hier bleibt" mit Beispielen untermauert.

rbx kenn ich übrigens genau so wenig wie dich Frechdachs:)

P.S.: Meine merkwürdigen Meta-Scherze und schlechte Witze muss ja 
niemand verstehen oder lieben. Einfach die Fassung bewahren und nicht 
zuschlagen. Man kann es durchaus überleben.
P.S.S.: Wenn ich mal MaWin "zu jubel", weil ich der gleichen Meinung bin 
dann näss dich bitte nicht gleich ein. Das passt ja kaum zu deinem doch 
so hohen Alter, also von der geistigen Reife. Von der biologischen 
schon, hmm... (Muss ich dazu schreiben dass das ein Scherz war und nicht 
ernst gemeint?:P)

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

MaWin O. schrieb:
> Das kommt halt ganz auf dein Programm an, was du schreibst.

Und es kommt bei dem Unterton der Diskussion da oben ja wohl auch darauf 
an, WER das Programm schreibt.

Leute, Leute. Wer keine KANONEN zur Verfügung hat, der MUSS halt das 
nehmen, was er zur Verfügung hat. Rumheulen und Träumen bringt da gar 
nichts. Man nimmt halt ein Makefile oder gar gleich den Assembler (weil 
derjenige es muss ... oder nicht anders kann?) anstatt MBED oder 
Monstren wie PlatformIO, oder alle Cores doppelt mit 
Link-Time-Optimization zu bemühen.
Refrain: Zwangsweise. Oder weil es nicht anders geht. Oder weil es 
wirtschaftlicher ist. Oder weil wir das so schlank eingeplant haben? 
Sucht euch was aus ... :P

Die oben genannten Anforderungen(10GB) sind ja wohl eher ein Scherz für 
sogar 10 Jahre alte Entwicklungsarbeitsplätze (und natürlich Subjektiv, 
eine Hausnummer).
Ich will jetzt auch nicht sagen, dass manche Lösung so einfach ist wie: 
"cargo build --jobs 1", aber bitte bitte bitte: RTFM!

So einfach abtun sollte man das natürlich nicht.
"Compiler using over 20GiB memory #82406": 
https://github.com/rust-lang/rust/issues/82406
Mit so hilfreichen Tips wie z.B.:
> lto = "off"

die nicht nur mir beim dieser LLVM-mässigen compilerverwahrlosenden 
Speicherverschwendung als Aufruf zur Selbsthilfe in den Sinn kommen.
(Das war jetzt teilweise ernst gemeint!:O))
Ist ein Feature! Nich von mir, von LLVM:P

von MaWin O. (mawin_original)


Lesenswert?

Jedzia D. schrieb:
> die nicht nur mir beim dieser LLVM-mässigen compilerverwahrlosenden
> Speicherverschwendung

bekommst du Geld zurück für jedes nicht verwendete Byte deines RAMs?

Wie bereits gesagt: Die Speicherlast ist keine Eigenschaft von Rust, 
sondern eine Eigenschaft jedes modernen optimierenden Compilers. Also 
offtopic.

von cppbert (Gast)


Lesenswert?

Jedzia D. schrieb:
> Wenn ich mal MaWin "zu jubel", weil ich der gleichen Meinung bin
> dann näss dich bitte nicht gleich ein.

Ich finde das MaWin hier gute arbeit leistet - auch wenn er leider oft 
gegen Windmühlen kämpfen muss

von cppbert (Gast)


Lesenswert?

Jedzia D. schrieb:
> Die oben genannten Anforderungen(10GB) sind ja wohl eher ein Scherz für
> sogar 10 Jahre alte Entwicklungsarbeitsplätze (und natürlich Subjektiv,
> eine Hausnummer).

blöderweise lässt sich so ein Text auf einer Homepage auch schnell mal 
uminterpretieren in ein "Rust braucht immer mind 10GB RAM zum 
kompilieren"

aber du hast ganz Recht, viele wissen gar nicht mehr wie viel so ein 
kompilieren heute an Resourcen braucht, und die ganzen Defaults die Rust 
mit rein bringt LTO etc. sind natürlich auch nicht ganz ohne - aber auch 
gewollt

rustc ist immer noch (nur) der Referenz-Kompiler und nicht mehr, hier 
geht es um die Sprache und diese erzwingt nicht per se übetriebene 
Nutzung von Resourcen - wird sich alles in der Zukunft zeigen, mal 
schauen wie sich da der gccrs schlagen wird

von cppbert (Gast)


Lesenswert?

cppbert schrieb:
> aber du hast ganz Recht, viele wissen gar nicht mehr wie viel so ein
> kompilieren heute an Resourcen braucht

sorry, eher ein Parallel-Bauen mit vielen Kernen

von MaWin O. (mawin_original)


Lesenswert?

cppbert schrieb:
> und die ganzen Defaults die Rust
> mit rein bringt LTO etc.

Cargo default ist lto=off

;)

Die 10 GB (oder mehr, je nach Programm) sind worst case, wenn man es 
darauf anlegt.

> hier
> geht es um die Sprache und diese erzwingt nicht per se übetriebene
> Nutzung von Resourcen

Das ist grundsätzlich richtig.
Man kann auch Cargo so betreiben, dass es wenig(er) RAM braucht.
Vor allem lto=off und single-core-Betrieb werden hier massiv helfen. 
Natürlich auf Kosten der Codequalität und Compilezeit.

Aber ich denke auch, dass Rust als Sprache ansich deutlich höhere 
Anforderungen an die Hardware stellt, als z.B. C.

- Die ganzen statischen Prüfungen, die Rust verlangt, müssen vom 
Compiler durchgeführt werden.
- Die Rust-Syntax ist nicht (wie C) auf einfachste Codegenerierung 
ausgelegt. In den verschiedenen IRs der Rust-Compilierung kommen massive 
Codemengen zusammen, die dann von den Optimierungsstufen 
zusammengeschrumpft werden müssen. Das Vorhandensein dieser 
Optimierungen ist eine Annahme, die man beim Sprachdesign getroffen hat. 
Und das kostet Ressourcen bei der Compilierung.

Aber solange das sich im vernünftigen Rahmen der verfügbaren Hardware 
bewegt, dann halte ich das für eine sehr gute Abwägung.
Es ist absolut vernünftig die Ressourcen, die zur Verfügung stehen, auch 
zu nutzen, um in einer modernen Sprache gute Programme zu compilieren.
Wenn du nur 10% deines RAMs nutzt, verbessert das rein gar nichts.
Wenn du aber 50% deines RAMs nutzt um damit besseren Code zu generieren 
oder eine bessere Sprache zu ermöglichen, dann verbessert das ganz 
erheblich was.

Meine 2ct.

von MaWin O. (mawin_original)


Lesenswert?

cppbert schrieb:
> wird sich alles in der Zukunft zeigen, mal
> schauen wie sich da der gccrs schlagen wird

Achja, und gccrs. Der wird im ersten Schritt noch keinen Borrow-Checker 
haben. Alleine deshalb wird gccrs schon wahrscheinlich schlanker und 
schneller sein.
Natürlich auf Kosten der Memory-Safety.

Es wird gerade ein neuer Borrow-Checker entwickelt, den man dann sowohl 
in rustc als auch in gccrs gedenkt einzusetzen.

Der Vergleich zwischen rustc und gccrs wird aber immer spannend bleiben. 
Daraus wird sich hoffentlich ein Rennen um den besten Compiler 
entwickeln.

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


Lesenswert?

Links (nicht Rechts) schrieb:
> In den letzten Beiträgen ging es u.a. um die Programmierung von einem
> ATtiny85 mit 8K Flash und wenn man einen PC mit mehr als 10 GB RAM
> braucht

Den PC mit mehr als 10 GB RAM brauchst du, um den Compiler zu 
compilieren, nicht das bissel Programm für den ATtiny.

Das ist mit dem AVR-GCC sicher etwas weniger, mit dem AVR-Clang wird 
sich das nicht so grundlegend unterscheiden.

von Oliver R. (Gast)


Lesenswert?

Ich habe hier u.a. ein altes MacBook und ein Linux Notebook mit 4GB RAM. 
Darauf habe ich bisher alles kompilieren können, Embedded-Projekte 
ohnehin, aber auch GUI Anwendungen. Dass grosse Projekte auf diesen 
alten Kisten Probleme machen, will ich aber natürlich nicht 
ausschliessen.

Was eher auf alten Rechnern mit vergleichsweise kleinen Festplatten/SSDs 
problematisch sein kann, ist die Grösse des target-Ordners. Da können 
schnell einige GB zusammenkommen.

von MaWin O. (mawin_original)


Lesenswert?

Oliver R. schrieb:
> Ich habe hier u.a. ein altes MacBook und ein Linux Notebook mit 4GB RAM.
> Darauf habe ich bisher alles kompilieren können, Embedded-Projekte
> ohnehin, aber auch GUI Anwendungen.

Aha. Ich habe hier einen Raspberry Pi mit 4GB und darauf kompiliere ich 
regelmäßig alle meine Rust-Programme. Gar kein Problem.

Vielleicht wird es aber auch mal Zeit diese historischen MacBooks und 
Linux-Notebooks über Bord zu werden, oder halt darauf Software aus der 
damaligen Zeit zu betreiben.

Auf einem Commodore 64 konnte man auch kein Windows 95 installieren.
Der zeitliche Abstand dürfte in etwa der gleiche sein.

Oliver R. schrieb:
> Was eher auf alten Rechnern mit vergleichsweise kleinen Festplatten/SSDs
> problematisch sein kann, ist die Grösse des target-Ordners. Da können
> schnell einige GB zusammenkommen.

Naja. Geht so.
1
$ du -sh target/
2
1.8G    target/
3
du -sh .embuild/
4
1.3G    .embuild/

Das ist jetzt eines meiner Embedded-Projekte für ESP32.
Das sollte auch auf einem Rechner der ersten SSD-Generationen passen, 
wenn man das denn will.

von Oliver R. (Gast)


Lesenswert?

Beim target-Ordner sollte man halt wissen, dass die Builds darin 
versioniert sind. Wenn also z.B. Features geändert oder die Toolchain 
aktualisiert wird, dann wird ein komplett neuer Build angelegt.

Das auch durchaus positiv zu sehen, weil dann schnell zwischen 
verschiedenen Versionen hin- und hergeschaltet werden kann ohne alles 
neu kompilieren zu müssen.

Wenn man also nicht gelegentlich mal ein "cargo clean" macht, kann der 
Ordner entsprechend anwachsen.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Wilhelm M. schrieb:
> cppbert schrieb:
>> du bekommst das nicht als target
>
> Doch, ein Target für avr gibt es eben in Version 1.66

Die angezeigte Target-Liste zeigt alle bekannten Targets, aber nicht die 
unterstützten.
1
rustup target add avr-unknown-gnu-atmega328

beendet mit einem Fehler (rustc stable), da braucht's wohl die nightly 
als Basis.

"avr-unknown-gnu-atmega328" ist offensichtlich ein Misnomer; das Target 
sollte einfach avr-unknown-gnu oder avr-unknown-none heißen.  Tut es 
aber nicht; vermutlich hatten die Entwickler noch nen ATmega238 irgendwo 
rumfliegen...

rustc basiert ja auf llvm, d.h. es ist llvm + Rust-Frontend.  llvm / 
clang wiederum übernehmen viele Optionen von [avr-]gcc wie -o, -O*, 
-mmcu= etc.

Für ein Frontend wie Rust ist es erst mal egal, ob eine Architektur MUL 
oder DIV unterstützt oder nicht.  Es erzeugt Zwischencode für MUL und 
DIV etc., der dann irgendwann zu Assembly gelowert wird -- und dann muss 
man natürlich wissen, ob MUL oder Lib-Call, wie teuer MUL ist etc.  Und 
dieses Lowering erfolgt eben nicht im (Rust-)Frontend.  Das einzige, was 
Rust wissen müsste, ist wie man mit Inline Assembly umgeht, ganz konkret 
mit Constraints, die ja Target-abhängig sind.

Teile der GNU-Tools wie AVR-LibC sind in mehreren Einzelteilen (Crates) 
verfügbar, die lax in etwa Libraries entsprechen.  Es gibt nen Crate für 
avr-libc Funktionen, nen Crate für SFR-Definitionen (avrd), nen Crate 
für PROGMEM, nen Crate für ... you name it.

Für jedes Puzzleteil muss man wissen, ob man es braucht oder nicht und 
in welcher Version, die man dann im .toml einträgt.

Momentan scheint's da nen ziemlichen Wildwuchs zu geben, auf crate.io 
nach "avr" zu suchen bringt mehrere Seiten von Crates, wobei da auch 
andere Bedeutungen von "AVR" bei sind.

Ein "offiziellen" AVR Support wie realisiert durch AVR-LibC scheint's 
nicht zu geben, wie gesagt muss man alles zusammensuchen. Und weil llvm 
nichts wie GCC's Spec-Files unterstützt, muss jede Kleineigkeit an 
Target-Optionen im Compiler selbst realsiert sein, so wie es bei avr-gcc 
bis v4.9 der Fall war.

: Bearbeitet durch User
von cppbert (Gast)


Lesenswert?

https://www.heise.de/hintergrund/Interview-Soenke-Huster-ueber-Luecken-im-WLAN-Stack-des-Linux-Kernels-7447684.html
1
ct: C gilt als relativ unsichere Programmiersprache. Künftig soll es möglich sein, Kernel-Komponenten stattdessen in Rust zu schreiben. Hätte das deine Sicherheitslücken verhindert?
2
3
Huster: Sehr wahrscheinlich wären diese Lücken nicht aufgetreten, hätte man die Module in Rust geschrieben. Gerade die Geschichte, dass man Speicher überschreiben kann. Der Rust-Compiler hätte verhindert, dass die Kernel-Entwickler diesen Fehler überhaupt einbauen. Aber es gibt natürlich auch Fehler, die durch keine Programmiersprache der Welt verhindert werden.

zu

"Aber es gibt natürlich auch Fehler, die durch keine Programmiersprache 
der Welt verhindert werden."

das ist den Rust-Designern und den Anwendern klar - nur damit hier 
niemand Zeit damit verschwenden muss ein 
also-doch-nicht-100%-Sicher-Kommentar einzustreuen :)

von Kaj (Gast)


Lesenswert?

cppbert schrieb:
> "Aber es gibt natürlich auch Fehler, die durch keine Programmiersprache
> der Welt verhindert werden."
Das ist richtig. Dazu gehört zum Beispiel das überprüfen der Länge.
https://www.heise.de/news/Rust-bis-zu-2500-Projekte-durch-Bibliothek-Hyper-fuer-DoS-verwundbar-7451019.html
1
Allerdings ist es bei Hyper möglich, das Problem mit kleinen Paketen 
2
auszunutzen. Wenn die Funktion to_bytes mehr als einen Chunk an Daten 
3
erwartet, erzeugt sie einen Vektor, der der Länge des zu lesenden Bodys 
4
entspricht. Die Länge des Vektors bestimmt sich dabei über den Content-
5
Length-Header, dessen Wert Angreifer einfach so hoch setzen können, dass 
6
der Prozess beim Erzeugen des Vektors abstürzt. Da HTTP-Server oft Daten 
7
aus nicht vertrauenswürdigen Quellen empfangen, ist eine solche Attacke 
8
vorstellbar.
Auch die beste Sprache schützt nicht (immer) vor Schludrigkeit.

von cppbert (Gast)


Lesenswert?

Kaj schrieb:
> Auch die beste Sprache schützt nicht (immer) vor Schludrigkeit.

100% ACK

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> das ist den Rust-Designern und den Anwendern klar - nur damit hier
> niemand Zeit damit verschwenden muss ein
> also-doch-nicht-100%-Sicher-Kommentar einzustreuen :)

Das ist den Rust-Entwicklern sehr klar

https://blog.rust-lang.org/2023/01/10/cve-2022-46176.html

Vor Logikfehlern kann eine Sprache nur in einem gewissen Rahmen 
schützen.

Aber auch da ist Rust besser als typunsichere Sprachen, weil sich solche 
Logikzusammenhänge oft als Typzusammenhänge formulieren lassen. Somit 
haben Bibliotheksentwickler die Möglichkeit eine Falschverwendung der 
APIs zu beschränken.

von Cppbert (Gast)


Lesenswert?


von Cppbert (Gast)


Lesenswert?

Cppbert schrieb:
> Mehr Rust in Chrome

Laut Wikipedia hat das Chromium Projekt ca. 35 Mio Zeilen code, mit 
einem großen Anteil C++

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


Lesenswert?

Cppbert schrieb:
> Cppbert schrieb:
>> Mehr Rust in Chrome
>
> Laut Wikipedia hat das Chromium Projekt ca. 35 Mio Zeilen code, mit
> einem großen Anteil C++

"This will enable us to include Rust code in the Chrome binary within 
the next year."

Das sind ja offenbar überhaupt erstmal die Voraussetzungen, dort Rust zu 
benutzen. Da ist es ja irgendwie logisch, dass das aktuell noch gar 
nicht dabei ist.

von Kaj (Gast)


Lesenswert?

Da fühlt sich jemand auf den Schlips getreten :D

Sichere Programmiersprachen: Bjarne Stroustrup reagiert auf 
NSA-Empfehlung
https://www.golem.de/news/sichere-programmiersprachen-bjarne-stroustrup-reagiert-auf-nsa-empfehlung-2301-171374.html

von Lothar (Gast)


Lesenswert?

Rust bietet zumindest (noch) keine Lösung für das kritischste Embedded 
C/C++ Problem:

Is rust guaranteed to detect stack overflows?

https://users.rust-lang.org/t/is-rust-guaranteed-to-detect-stack-overflows/52593/1

Rust code segfaults with stack overflow

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

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


Lesenswert?

Lothar schrieb:
> Rust bietet zumindest (noch) keine Lösung für das kritischste Embedded
> C/C++ Problem:

Wobei "embedded" natürlich eine gaaanz breite Palette ist.

Auch da gibt es Hardware, die memory protection kann. Wenn die Hardware 
das aber nicht kann, wäre der Preis, dass die Software vor jeder 
Stackoperation selbst erstmal gucken müsste, ob da jetzt eine Kollision 
entstehen kann. Gerade auf den Plattformen, die keine hardware memory 
protection haben (weil sie so klein sind) will man diesen Preis ohnehin 
eher nicht bezahlen.

von Oliver R. (Gast)


Lesenswert?

Es gibt zumindest Ideen dazu.

https://github.com/knurling-rs/flip-link

von Lothar (Gast)


Lesenswert?

Jörg W. schrieb:
> Auch da gibt es Hardware, die memory protection kann.

Auch eine MPU nützt wenig, wenn der Stack nach unten wächst. Da müsste 
dann wohl eine leere Readonly Page zwischen Heap und Stack.

> Gerade auf den Plattformen, die keine hardware memory
> protection haben (weil sie so klein sind) will man diesen Preis ohnehin
> eher nicht bezahlen.

Zunächst Mal wäre der Aufwand für einen Compiler doch gar nicht so 
gross, den Platzbedarf für Register, Rücksprungadresse, lokale Variablen 
beim Funktionsaufruf zu berechnen. Und dann automatisch vor 
Funktionsaufruf eine Prüfung des Stackpointer zu erzeugen. Das ist eine 
Subtraktion und ein Compare, kein Aufwand.

Bei rekursiven Funktionen in C zähle ich immer die Tiefe manuell mit, 
nur so kann nichts daneben gehe.

Und bei "kleinen Platformen" wie z.B. dem 8051 läuft der Stack nach 
oben, da braucht es keine MPU, einfach nur Prüfung 0xFF - SP > 
Platzbedarf. Interrupt Handler müssen gar nicht geprüft werden, da 
Registerbänke.

von Cyblord -. (cyblord)


Lesenswert?

Kaj schrieb:
> Da fühlt sich jemand auf den Schlips getreten :D
>
> Sichere Programmiersprachen: Bjarne Stroustrup reagiert auf
> NSA-Empfehlung
> 
https://www.golem.de/news/sichere-programmiersprachen-bjarne-stroustrup-reagiert-auf-nsa-empfehlung-2301-171374.html

Ja sicher. Was weiß der Idiot schon.  Nur Rust Fanboys kennen die 
Wahrheit. In ihrem Leben zwar noch nie was geleistet, aber über einen 
der bedeutendsten Köpfe im Bereich Programmiersprachen herziehen.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Announcing Rust 1.67.0

https://blog.rust-lang.org/2023/01/26/Rust-1.67.0.html

Dieses Mal mehr unsichtbare Arbeiten unter der Haube.
Aber auch wichtige Dinge wie die Beschleunigung von einer Variante der 
Inter-Thread-Communikation. (Was nicht heißt, dass diese vorher langsam 
war).


Lothar schrieb:
> Rust bietet zumindest (noch) keine Lösung für das kritischste Embedded
> C/C++ Problem:

Warum sollte Stack-overflow das kritischste Embedded-Problem sein?
Gibt es da auch Belege für?

von MaWin O. (mawin_original)


Lesenswert?

Es gibt wieder eine ganz große Ankündigung:

https://blog.rust-lang.org/inside-rust/2023/02/23/keyword-generics-progress-report-feb-2023.html

Generische Keywords.
Das ist ein gigantischer Paukenschlag!

Im ersten Schritt soll async (und vielleicht const) generisch werden.
Braucht man das? Aber sicher.

Das will man haben. Denn ein riesiges Problem bei asynchroner 
Programmierung ist, dass man vieles doppelt implementieren muss. Einmal 
als sync-Variante und einmal als async-Variante. Das kennt man auch aus 
andere Sprachen wie Python.
Es gibt dann so Krücken, dass man in der Sync-Variante eine lokale 
Eventloop aufzieht und dann die async-Variante aufruft. Das funktioniert 
oft, hat aber entscheidende Nachteile. Erstens natürlich den ganz 
offensichtlichen Runtime-Overhead. Das will man natürlich vor allem in 
Rust nicht. Und dann, dass die Rekursion oder Verschachtelung solcher 
Konstrukte extrem eingeschränkt oder unmöglich ist.

Falls sich darunter keiner etwas vorstellen kann: Es ist ähnlich wie 
const-Funktionen in C++ und auch Rust. Je nach Kontext, in denen sie 
verwendet werden, verhalten sich const-Funktionen wie const oder wie 
non-const. (Mehr dazu im verlinkten Artikel)

Deshalb: Ich bin echt gespannt, wie async-Generics sein werden. Das wird 
der Durchbruch sein viele Libraries async-fähig zu machen, ohne alles 
noch einmal neu implementieren zu müssen.
Ich glaube das wird der Durchbruch für die breite Nutzung von async.

Aber bis dahin ist noch ein langer weg. Mal sehen, ob es ein kleiner 
Teil davon in die nächste Edition 2024 schafft.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

Announcing Rust 1.68.0

https://blog.rust-lang.org/2023/03/09/Rust-1.68.0.html

* Das schnelle cargo-Protokoll ist stabil.
* Pinning wurde einfacher.

von Oliver R. (sourcebox)


Lesenswert?

Mit 1.68 lässt sich nun auch ein globaler Allokator definieren, das war 
zuvor nur mit nightly möglich.

https://github.com/rust-embedded/embedded-alloc

von Cyblord -. (cyblord)


Lesenswert?

Oliver R. schrieb:
> Mit 1.68 lässt sich nun auch ein globaler Allokator definieren, das war
> zuvor nur mit nightly möglich.
>
> https://github.com/rust-embedded/embedded-alloc

Mit wie vielen Features will man Rust eigentlich noch überladen?

von Yalu X. (yalu) (Moderator)


Lesenswert?

Cyblord -. schrieb:
> Oliver R. schrieb:
>> Mit 1.68 lässt sich nun auch ein globaler Allokator definieren, das war
>> zuvor nur mit nightly möglich.
>>
>> https://github.com/rust-embedded/embedded-alloc
>
> Mit wie vielen Features will man Rust eigentlich noch überladen?

Deine Frage lässt vermuten, dass du die Möglichkeit, einen globalen
Allokator zu definieren, als überflüssig empfindest. Kannst du
vielleicht näher erläutern, warum?

von Cyblord -. (cyblord)


Lesenswert?

Yalu X. schrieb:
> Cyblord -. schrieb:
>> Oliver R. schrieb:
>>> Mit 1.68 lässt sich nun auch ein globaler Allokator definieren, das war
>>> zuvor nur mit nightly möglich.
>>>
>>> https://github.com/rust-embedded/embedded-alloc
>>
>> Mit wie vielen Features will man Rust eigentlich noch überladen?
>
> Deine Frage lässt vermuten, dass du die Möglichkeit, einen globalen
> Allokator zu definieren, als überflüssig empfindest.

Diese Prämisse ist schon falsch.

> Kannst du
> vielleicht näher erläutern, warum?

Damit hat sich diese Frage erledigt.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Cyblord -. schrieb:
> Diese Prämisse ist schon falsch.

Deine Frage bezog sich also gar nicht auf den von dir zitierten Text?
Warum hast du ihn dann zitiert?

Cyblord -. schrieb:
> Damit hat sich diese Frage erledigt.

Ja.

Du solltest, wenn du ernsthaft Kritik zu irgendetwas loswerden möchtest,
auch dazuschreiben, worauf sich deine Kritik konkret bezieht.

Oder war deine Frage vielleicht gar nicht kritisch gemeint?

Ok, dann kann sie von jedem Rust-Fanboy ja ganz leicht mit "0"
beantwortet werden ;-)

von MaWin O. (mawin_original)


Lesenswert?

Warum antwortet ihr diesem Troll immer noch? Das war doch ganz 
offensichtlich nur eine Trollfrage, um euch aus der Reserve zu locken.

Oliver R. schrieb:
> Mit 1.68 lässt sich nun auch ein globaler Allokator definieren, das war
> zuvor nur mit nightly möglich.

Das ist richtig.
Ein wichtiges Feature für manche Embedded-Entwicklungen und 
Kernelentwicklung.

von Cyblord -. (cyblord)


Lesenswert?

Yalu X. schrieb:
> Deine Frage bezog sich also gar nicht auf den von dir zitierten Text?
> Warum hast du ihn dann zitiert?

Doch natürlich bezog es sich auf den zitierten Text. Nur die Prämisse 
dass ich das Feature als überflüssig empfinde stimmt nicht.
Ich halte auch Staubsauger und Gasgrills nicht für überflüssig, würde 
beides aber ungern in einen Motorroller einbauen.

Nicht alles was irgendwie nützlich sein könnte, muss man in diese 
Sprache reinpacken. Wo soll das Enden?
Vor allem wenn man sich im Vergleich anschaut, mit wie wenig Features es 
C zu weltweiter Verbreitung gebracht hat. Vielleicht sind es eben nicht 
möglichst viele Features welche eine Sprache gut machen?

von Yalu X. (yalu) (Moderator)


Lesenswert?

Cyblord -. schrieb:
> Yalu X. schrieb:
>> Deine Frage bezog sich also gar nicht auf den von dir zitierten Text?
>> Warum hast du ihn dann zitiert?
>
> Doch natürlich bezog es sich auf den zitierten Text. Nur die Prämisse
> dass ich das Feature als überflüssig empfinde stimmt nicht.
> ...
> Nicht alles was irgendwie nützlich sein könnte, muss man in diese
> Sprache reinpacken.

Prinzipiell bin ich diesbezüglich ganz bei dir, würde das aber nicht so
allgemein formulieren. Deswegen frage ich mal so: Welche Features, die
als nützlich angesehen werden und deswegen in Rust integriert wurden,
haben deiner Ansicht nach nichts darin verloren? Zählt für dich konkret
der benutzerdefinierbare globale Allokator dazu?

> Vor allem wenn man sich im Vergleich anschaut, mit wie wenig Features es
> C zu weltweiter Verbreitung gebracht hat.

Das ist kein gutes Argument. Würde irgendjemand auf Rust umsteigen
wollen, wenn er dort nur die bereits von C bekannten Features in einer
leicht geänderten Syntax vorfinden würde?

> Vielleicht sind es eben nicht möglichst viele Features welche eine
> Sprache gut machen?

Ich glaube, kein Sprachentwickler(team) hat das Ziel, "möglichst viele"
Features in seine Sprache zu packen, sondern versucht, sich auf
sinnvolle Features zu beschränken. Natürlich gehen bei der Bewertung
der Sinnhaftigkeit von Features die Ansichten stark auseinander. Das
kann (und sollte) anhand konkreter Fälle diskutiert werden, es bringt
aber nichts, das Hinzufügen neuer Features generell in Frage zu stellen.

Was den benutzerdefinierbaren globalen Allokator betrifft:

Das ist ein Feature, das für einige Programmierer nützlich ist, vor
allem im Embedded-Bereich. Für andere (vor allem PC-Programmierer) ist
es nur von geringer Relevanz.

Diejenigen, die es nicht benötigen, stört es nicht, weil sie ihre Arbeit
genauso fortführen können, wie sie sie vor der Einführung des Features
gemacht haben. Das entsprechende Kapitel in der Dokumentation werden sie
einfach überspringen.

Das Feature stellt auch keine Vergewaltigung bisheriger Sprachelemente
dar, wie sie z.T. in C++ (bspw. mit dem völlig unlogischen Überladen
einiger Operatoren in der Standardbibliothek) stattgefunden hat.

Was konkret spricht also dagegen, den Embedded-Programmierern (die ja
immerhin eine der Zielgruppen von Rust sind) zuliebe das Feature
einzuführen?

> Wo soll das Enden?

IMHO da, wo ein Feature nur von einer kleinen Minderheit gewünscht wird
und nur mit Biegen und Brechen bzw. mit einem groben Bruch der bisher in
der Sprache umgesetzten Konzepte implementierbar ist.

von MaWin O. (mawin_original)


Lesenswert?

Yalu X. schrieb:
> Ich glaube, kein Sprachentwickler(team) hat das Ziel, "möglichst viele"
> Features in seine Sprache zu packen, sondern versucht, sich auf
> sinnvolle Features zu beschränken.

Vollkommen korrekt.

Zu behaupten die Sprachentwickler würden Features in Rust nur einbauen 
um mehr Features zu haben, ist ganz offensichtliches Getrolle.

Wann kommt denn OOP-Vererbung in Rust? Sie kommt nicht und wird auch nie 
kommen.
Was ist mit Funktionsüberladung?
Konstruktoren?
Da gibt es dutzende Beispiele für Dinge, die ganz bewusst aus Rust 
herausgehalten werden.

In die Sprache und die stdlib werden Features sehr sehr vorsichtig 
integriert. Denn wenn sie einmal drin sind, muss man sie für immer 
unterstützen.
Deshalb werden Experimente gerne einmal über lange Zeit in externen 
Crates gemacht, bis dann schlussendlich Teile davon in die stdlib 
übernommen werden.
Dieser Prozess dauert teilweise sehr viele Jahre. (z.B. GATs).

Yalu X. schrieb:
> Was konkret spricht also dagegen, den Embedded-Programmierern (die ja
> immerhin eine der Zielgruppen von Rust sind) zuliebe das Feature
> einzuführen?

Natürlich gar nichts.
Denn dieses Feature ist in C selbstverständlich auch vorhanden.
Es taugt also nicht einmal für die Featureitis-Argumentation.

Yalu X. schrieb:
>> Wo soll das Enden?
>
> IMHO da, wo ein Feature nur von einer kleinen Minderheit gewünscht wird
> und nur mit Biegen und Brechen bzw. mit einem groben Bruch der bisher in
> der Sprache umgesetzten Konzepte implementierbar ist.

Ganz genau. Und jetzt kann unser Troll ja einmal ein konkretes Beispiel 
für ein Feature in der Sprache oder der stdlib liefern, was praktisch 
niemand braucht und deshalb nur Bloat ist.

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

Windows Treiber mit Rust

https://www.golem.de/news/entwicklung-microsoft-legt-rust-framework-fuer-windows-treiber-offen-2309-177932.html
1
Konkret handelt es sich bei den Projekten um Rust-Pakete (Crates), mit denen 
2
die üblichen Treiber-Modelle WDM und WDF umgesetzt werden können, also auch 
3
Kernel- und Usermode-Treiber. Ebenso möglich werden sollen damit Systemdienste 
4
(Win32). Die Crates umfassen allen voran idiomatische API-Anbindungen an das 
5
Windows Development Kit (WDK), die Safe-Rust unterstützen. Hinzu kommen 
6
FFI-Anbindungen, Makros sowie Bibliotheken zur Panic-Behandlung, zur 
7
Speicherzuweisung oder zum Bauen und Linken der Treiber selbst.

https://github.com/microsoft/windows-drivers-rs

von Cyblord -. (cyblord)


Lesenswert?

W.Gates schrieb:
> Was der Bauer nicht kennt frisst er nicht. Da wird sich Rust noch lange
> schwer tun. Auch ist die Terminologie bei Rust etwas zu esoterisch um
> bei Vielen anzukommen. Irgendwie passt z.B. "Crate" u.v.a. nicht in den
> Jargon etablierter Entwicklung.

Dazu kommt die geschwätzige basic-like Syntax. Das will heute niemand 
mehr.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Dazu kommt die geschwätzige basic-like Syntax.

Sehr gut. Jetzt habe ich tatsächlich einmal herzhaft lachen müssen. Das 
ist gesund.
Danke dafür, lieber Cyblord. :D

von Yalu X. (yalu) (Moderator)


Lesenswert?

Cyblord -. schrieb:
> Dazu kommt die geschwätzige basic-like Syntax.

Was ist an der Rust-Syntax basic-like oder gar geschwätzig?

Für mich hat die Syntax eher eine gewisse Ähnlichkeit mit C.

Hast du jemals in Basic oder C programmiert?

von Cyblord -. (cyblord)


Lesenswert?

Yalu X. schrieb:

> Hast du jemals in Basic oder C programmiert?

Wasn das für eine blöde Frage?

Allein das "let" hat Basic Vibes ohne Ende.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Allein das "let" hat Basic Vibes ohne Ende.

Herrlich. Einfach nur herrlich. :D

von Yalu X. (yalu) (Moderator)


Lesenswert?

Cyblord -. schrieb:
> Allein das "let" hat Basic Vibes ohne Ende.

Jetzt muss auch ich lachen, denn ich habe fast geahnt, dass genau das
der Grund für deinen obigen Kommentar war. Danke für die Bestätigung :D

Die Syntax einer Sprache definiert sich für dich also anhand eines
einzelnen Schlüsselworts, und das völlig unabhängig davon, welche
Bedeutung dieses hat :)

Was glaubst du, in wievielen modernen Programmiersprache es dieses
Schlüsselwort gibt? Diese wären nach deiner Argumentation ja automatisch
alle Basic-ähnlich.

Ganz abgesehen davon ist LET in den meisten Basic-Dialekten seit
mindestens vier Jahrzehnten obsolet und wird auch von praktisch
niemandem mehr verwendet.

: Bearbeitet durch Moderator
von Rbx (rcx)


Lesenswert?

Rust ist da eher linuxoid, wie Haskell (ohne Internet irgendwie blöd) , 
und am besten auch immer alles mit bzw. im Emacs machen.

Ich denke, BASIC bleibt als Einstiegssprache immer noch ungeschlagen. 
Leider hatte man früher auch viel Drumherum-Kultur. Den Part haben jetzt 
eher c, c++, python und java eingenommen. Sind aber dann aber auch 
mehrere Baustellen.

Tatsächliche Vibes bei Rust müssten in diese Richtung gehen:
https://de.wikipedia.org/wiki/Lambda-Kalkül

Das ist auch alt, und man kann sich fragen, ob das wohl der Bringer 
gewesen wäre, hätte man diese Technik schon früh in der Schule 
durchgekaut.
https://github.com/BurntSushi/ripgrep z.B.
wäre ein nettes Projekt gewesen.

Beitrag #7505419 wurde von einem Moderator gelöscht.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.