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

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

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.

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.

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

Füller!

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.

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.

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

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?

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?

> 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

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

> 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

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

> 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

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

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.

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.

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

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.

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

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.

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

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.

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?

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.

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?

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

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

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.

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

Nochmal: Völliger Unsinn.

Google: semantic versioning

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?

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

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?

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.

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

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

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.

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

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

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

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.

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

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.

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?

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

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.

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.

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

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.

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

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

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.

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

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.

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?

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

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.

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

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?

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.

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.

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

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

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

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"

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?

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

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

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.

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.

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.

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

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

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

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

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

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

> 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

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?

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

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.

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

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

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.

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.

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

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

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?

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

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

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.

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.

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

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.

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

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?

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.

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.

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.

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?

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?