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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von 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?

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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