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

MaWin schrieb:
> Daniel A. schrieb:
>> Nur mal so zum drüber nach denken...
>
> Ich verstehe kein Wort von dem, was du schreibst.
>
> Könntest du das bitte verständlich neu formulieren?

Es ist Pro Rust, einfach mehrfach lesen dann wirds klar, kompliziert 
aber stechend formuliert

https://github.com/microsoft/windows-rs

Microsoft hat eine Metabeschreibung der WinApi veröffentlicht, nebst 
Binding Generator für Rust und C#, C++ soll folgen

Rust forciert:

1. einen einheitlichen Codingstyle (den man lokal deaktivieren kann - 
was aber nicht gerne gesehen ist)

==> der Style ist dann vielleicht nicht so wie man den seit 20 Jahren 
nutzt aber wenigstens ist er über alle Kollegen, Abteilungen UND Firmen 
für die man zeitweise arbeitet der selbe - und wer will den Ernsthaft 
behaupten das es zwischen den produktiven hunderten Codingstyles die das 
draussen so rumkreuchen und fleuchen der Unterschied mehr ist als 
Bauchgefühl

spätestes wenn du mit C,C++,C# und Python arbeitest fährt man im 
Normalfall schon 2-3 verschiedene Arten - also was soll es...

MERKE: man "kann" nicht nur einen gemeinsamen Codingstyle haben - man 
hat IMMER den selben(nicht nur den gleichen) Codingstyle

2. Ein Own/Share Konzept in der Sprache - was definitiv NICHT bedeutet 
das da Smart-Pointer einfach nur fest eingebaut sind sondern das die 
Sprache syntaktisch nicht erlaubt Own oder Share-Probleme zu 
programmieren, das komplette Programm ist wenn kompilierbar garantiert 
frei von (fast) alle Own/Share bezogenen Fehler - so lange der Kompiler 
keine Bugs hat :)

==> natürlich hat C++ auch Smart-Pointer und RAII mit der man viele 
Probleme unter Kontrolle bringt - aber eben nur wenn auch alle 
Entwickler mit machen,

Die grossen der Branche, also die mit sehr vielen Entwicklern und sehr 
viel C++-Code (10-100MioLOC) und Einfluss auf das Weltgeschehen, sage 
einstimmig, das ist alle ganz gut - wir haben aber trotzdem odentlich 
Probleme - und wer das nicht glaube hat einfach nicht wirklich Team- und 
im speziellen firmenübegreifende Entwicklungserfahrung oder hat keine 
Ahnung was ein Amazon AWS mit MioLOC C++ und 2 stellig Mio Anzahl Nutzer 
tagtäglich für Problemen mit Resourcen-Bedarf, Sicherheit gegen Angriff 
und.und.und ausgesetzt ist, ein google, Facebook etc. haben 
vergleichbare Größenordnung

MERKE: Mit Fehler die es nicht geben KANN muss man sich GAR NICHT 
beschäftigen

3. Ein Package und Build-System (aka Cargo)

Jeder Anfänger kann die Docs lesen und jeder andere Entwickler wird im 
Normalfall die selbe Sprache sprechen, fast jedes Projekt das sich nicht 
toal gegen den Standard wehrt baut out-of-the-box, das ist einfach was 
anderes als jeder-kann-es-machen-wie-er-will

unter C++ haben wir mittlerweile von Conan, vcpkg usw. schon etliche 
Systeme die immer mehr Verbreitung finden und es liegen x Proposal vor 
um C++ um ein solches System zu erweitern

ich hab beruflich mit fast allem Kontakt

MERKE: Vereinheitlichung ist erstmal einfacher für die meisten - an den 
Aufgaben wachsen kann jedes System

4. Ein auf Rust basiertes Build-System

natürlich haben wir da ein Wildwuchs an Systemen von CMake, meson, 
QMake, qbs, Scons - ich hab mit allen zu tun - und jedes ist irgendwie 
anders
, natürlich auch für embedded und, und, und

in Rust ist dein Build-System in Rust-Code und mehr braucht man 
eigentlich doch auch nicht

MERKE: die Sprache die du primär nutzt bleibt auch beim Build-System 
deine Sprache - kein Umdenken nötig

Nachteile:

1. Rust ist mit seinen 5-10 Jahren sehr jung für eine native Sprache mit 
so vielen echten Zwängen - go, C# oder andere nicht embedded-tauglichen 
oder VM-Sprachen sind einfach was anderes und können nur in der normalen 
Applikations-Entwicklung zum vergleich herangezogen werden - embedded 
und System-Entwicklung hat aber einfach noch viele viele kleine 
Anforderungen die eben auch sicher und performant realisierbar sein 
müssen

2. Rust ist oft arschlangsam beim kompilieren, liegt u.a. an dem stark 
organisch gewachsenem Kompiler und weil die Entwickler auch definitiv 
lange keine Fokus darauf gelegt haben - die wollte erst mal eine 
stimmige Syntax/Semantik entwickel/erforschen - und haben auch viele auf 
dem Weg dort hin gebaut und wieder völlig verworfen u.a. weil es eben 
nicht einfach nur ein C-Derivat ist (wie die meisten der anderen 
Sprachen)

Das ist jedem klar aber definitiv kein Argument gegen die 
Infrastruktur-Tools oder die Syntax und das macht die Entwickler auch 
nicht zu einem Haufen Idioten die gar nix können

3. Rust versucht gezielt mit vielen Zwängen die Entwickler auf die 
Algorithmen-Entwicklung zu fokusieren - das ist für viele aus der 
Kriegs- oder Anti-Autoritären-Erziehungs Generation zu wenig libreral, 
obwohl die meisten in ihren eigenen Firmen auch eher totalitärer 
Kontrolle über Infrastruktur-Tools und Codingstyle unterliegen oder 
ausüben

4. alles statisch gelinkt weil noch keine klare ABI für DLLs usw.

5. und, und, und...

Es wäre schön wenn wir vielleicht eine Positiv/Negativ-Liste aufbauen 
könnten

Nachteil 6:

Um Rust ranken sich zu viele Mythen:

"Rust ist perfekt für alles und erzeugt immer super-schnellen Code"

Die Syntax ist nicht ganz leicht und keine Programmiersprache der Welt 
vollbringt Wunder

Rust hat aber definitiv mit der Aliasing-Kontrolle potenzial stärker 
optimierbar sein zu können als C/C++ (wenn GCC und LLVM da keine Fehler 
hätten)

"Rust ist super-kompliziert"

Kommt definitiv darauf an welche Sprachen-Hintergrund man hat und welche 
Ziele man verfolgt, für jemanden der nur Basic kann ist alles schwer für 
jemanden der 10 Sprachen kann ist Rust vielleicht nicht so kompliziert

Die Frage ist nur ob man die Vorteile nutzen will

"Rust ist zu streng/einschränkend"

Jeder ist streng und einschränkend in seiner Firma oder Projekt - gibt 
es jemanden unter euch der akzeptiert das jeder im Team den Code einfach 
so strukturell oder visuell schreibt wie er jetzt gerade Bock drauf hat?

In C++ gibt es immer die Leute die auch mit den Infrastruktur-Tools wie 
Build-System, oder Sanitzer etc. arbeiten - oder diese auch einführen 
und pflegen, schulen - es ist meist nicht das ganze Team welche alles 
Tools gleich gut versteht - weil zu viel Spezialisierung nötig ist

"Es kann einfach nicht sein das Rust diese Sicherheits-Garantien 
erfüllt"

Es sind schon viele Sprachen daran gescheitert - meist weil die dabei 
entstandene Syntax kaum eine praktikable Entwicklung erlaubt, die 
meisten Sprachen sind entweder total unsicher wie z.B. C oder schaffen 
es mit größerem Ressourcen-Bedarf (alle VM Sprachen) die Problem besser 
unter Kontrolle zu halten, die dann aber wieder nicht für alle 
embedded/Echtzeit/niedrig-Latenz-Systeme geeignet sind

Sicherheits-Garantie bedeutet nicht das es sicher ist wenn man es 
richtig anwendet - das ist nur eine mögliche Sicherheit

Nachteil 7:

Rust hat erst vor kurzem, z.B. durch Amazon (die sponsorn alle Server 
und haben viele der Kern-Entwickler unter Vertrag genommen) und 
Microsoft (Azure und auch ein Teams im Aufbau) starke finanzielle 
Zuwendung ausserhalb von Mozilla erfahren

das ist verglichen mit der .Net-Entstehung  (stark durch den ganzen 
Microsoft-Konzern getrieben) , Java durch Sun/Oracle oder einem go mit 
starkem google-Hintergrund noch nicht wirklich viel Direkt-Finanzierung

das führt eben dazu das z.B. die Standard-Lib viel weniger umfangreich 
und ausgetesteter ist als bei Sprache/Platformen die erst hinter den 
Konzern-Türen so weit gebracht wurde das sie möglichst viele 
"Kauf-ich"-Argumente bei der Erstvorführung mitgebracht haben

Nachteil 8:

Rust will C/C++ im Embedded Bereich beerben - in dem ältesten und 
konservativstem Teil unserer Software-Landschaft, mit der größten Anteil 
an Spezalisierung bis runter auf die x Varianten von Kompilern und SDKs 
die von den Anbietern angepasst werden.

Das ist definitiv eine riesen Herausforderung - an der bisher jede 
Sprache ausser C (C++) und ein paar wenigen anderer, gescheitert ist - 
aber auch vielleicht weil die 1. zu Ressourcen-Hungrig waren oder 
einfach wirklich nur minimalsten Mehrwert gebracht haben

Carl D. schrieb:
> cppbert schrieb:
>>
> Wäre es nicht eine Überlegung wert, künftig einen anderen (Gast-)Nick zu
> verwenden?

Wie sollen mich dann bitte meine unzähligen Fans erkennen?

Carl D. schrieb:
> cppbert schrieb:
>>
> Wäre es nicht eine Überlegung wert, künftig einen anderen (Gast-)Nick zu
> verwenden?

Ich denke Rust braucht noch mind 5 Jahre bis zur Reife, bis dahin habe 
ich noch genug Zeit sehr viel C++ Code zu pflegen und zu schreiben, aber 
dann wechsel ich natürlich gleich auf rustbert

https://opensource.googleblog.com/2021/02/google-joins-rust-foundation.html

........
Memory safety security defects frequently threaten device safety, 
especially for applications and operating systems. For example, on 
Android, we’ve found that more than half of the security vulnerabilities 
we addressed in 2019 resulted from memory safety bugs. And this is 
despite significant efforts from Google and other contributors to the 
Android Open Source Project to either invest in or invent a variety of 
technologies, including AddressSanitizer, improved memory allocators, 
and numerous fuzzers and other code checking tools. Rust has proven 
effective at providing an additional layer of protection beyond even 
these tools in many other settings, including browsers, games, and even 
key libraries. We are excited to expand both our usage of Rust at Google 
and our contributions to the Rust Foundation and Rust ecosystem.
....

Half of the security vulnerabilities... und das von den Asan Erfindern 
:)

Cppbert3 schrieb:
> Half of the security vulnerabilities... und das von den Asan Erfindern
> :)
Und sie sagen zu rust:
Cppbert3 schrieb:
> an additional layer of protection
Das ist etwas anderes, als die Lösung des Problems.

mh schrieb:
> Das ist etwas anderes, als die Lösung des Problems.

was erwartest du: die haben 1Mrd. Zeilen C/C++ Code - wäre ziemlich blöd 
den Code in so einem Werbungs-Post schlecht klingen zu lassen, oder?

und was ist das Problem bei "die Lösung des Problems"?

Rust verhindert zu 100% alle Formen von Speicher-Falschnutzungen und 
Data-Races zur Kompilezeit (bis auf Array-Indizierung) - für den ganzen 
Source-Code auf einmal - was fehlt da noch an kritischen Problemen? 
Logikfehler kann man immer machen

und jede Sprache die versucht bis auf die Array-Indizierung herunter 
eine Garantie für die Fehlerfreiheit einer Software zu liefern ist 
praktisch kaum relevant(oder nutzbar)

Dergute W. schrieb:
> Na, wollnwa mal hoffen, dass nicht eines Tages auch mal sowas oder
> vergleichbares bei rust/cargo passiert:

Warum sollte es?

Dergute W. schrieb:
> MaWin schrieb:
>
>> Dergute W. schrieb:
>>> Na, wollnwa mal hoffen, dass nicht eines Tages auch mal sowas oder
>>> vergleichbares bei rust/cargo passiert:
>>
>> Warum sollte es?
>
> Sollte die Frage nicht besser lauten: Warum sollte es nicht?

Alle Package System die von Remote Code oder Binaries ziehen können und 
werden solche Probleme haben, nmp, vcpg, cargo, pip und und und, 
natürlich muss man da diszipliniert sein, aber ich hätte absolut kein 
Problem sowas komplett entkoppelt, firmenintern zu nutzen, was ja auch 
möglich ist - oder ich mache mein deployment von 3rd parties weiterhin 
von Hand, Cargo steht mir da auch nicht im Weg

aber ja, man kann alles irgendwie korrumpieren und es wird leichter

cppbert3 schrieb:
> Alle Package System die von Remote Code oder Binaries ziehen können und
> werden solche Probleme haben,

Das Problem war hier, dass Paypal ihr internes Buildsystem falsch 
konfiguriert haben. Einfach mal den Artikel lesen.
Das hat überhaupt nichts mit einer Lücke im Paketsystem zu tun.

Deshalb sehe ich auch nicht, was das mit Rust oder Cargo zu tun haben 
soll.

> Deshalb sehe ich auch nicht, was das mit Rust oder Cargo zu tun haben
> soll.

Es gibt schon einen Zusammenhang.

Wenn du frueher zu Ahnungslos gewesen bist um etwas ans laufen zu 
bringen dann hat es halt nicht funktioniert und du hast solange gelernt 
bist du es hin bekommen hast.

Heute funktioniert alles beim erstenmal moeglichst einfach, aber es ist 
Mist weil alles in die Welt rausgeblasen wird und du die unmoeglichsten 
Abhaengigkeiten auf der Kiste hast. Nur wenn du Ahnung hast und dir 
Muehe gibst kannst du es abstellen. Die Welt wird idiotensicher und wir 
bekommen immer mehr Idioten weil das reicht sich durchzuschummeln.

Vergleich das mit Handys. Nokiahandys unter Symbian waren angeblich 
schlecht weil es nach dem kauf kompliziert war die Kiste soweit zu 
bekommen das man damit ins Internet konnte, Email usw funktioniert hat. 
Bei Android geht es beim ersten einschalten, aber du musst dreimal 
soviel Muehe reinstecken um zu verhindern das deine privaten Daten 
ueberrall in der Welt landen. Ueber die Folgen kannst du jeden Tag in 
der Zeitung lesen.
Software geht denselben Weg....

Olaf

> Firmen bzw. aus der Cloud. Also aus Linux-Serversystemen, nicht von
> Android-Smartphones.

Das ist hier wohl eher OT, aber frag dich mal eine Sekunde wie bei 
Firmen wie Facebook, Google usw die Milliarden entstehen. Die muessen 
irgendwo was klauen das sie verkaufen koennen.

In der Software sehe ich das Problem das die Komplexizitaet immer 
groesser geworden ist. So gross das es immer schwerer faellt das alles 
zu durchschauen. Die Loesung sieht man darin die Systeme noch komplexer 
zu machen indem man diese Komplexizitaet nach aussen hin versteckt.

Olaf

MaWin schrieb:
> cppbert3 schrieb:
>> Alle Package System die von Remote Code oder Binaries ziehen können und
>> werden solche Probleme haben,
>
> Das Problem war hier, dass Paypal ihr internes Buildsystem falsch
> konfiguriert haben. Einfach mal den Artikel lesen.
> Das hat überhaupt nichts mit einer Lücke im Paketsystem zu tun.
>
> Deshalb sehe ich auch nicht, was das mit Rust oder Cargo zu tun haben
> soll.

Wenn es nur Paypal wäre, ist diese Aussage vielleicht Ok. Da es 
mittlerweile allerdings deutlich mehr Unternehmen getroffen hat, sollte 
man nochmal überlegen, wo genau das Problem liegt.

Achso MaWin, wie hilft in diesem Fall dein heiliger Gral semantic 
versioning?

Operator S. schrieb:
> mh schrieb:
>> Achso MaWin, wie hilft in diesem Fall dein heiliger Gral semantic
>> versioning?
>
> Wo bitte wurde das behauptet?

Da müsstest du die Beiträge von vor einem Monat lesen. Da hat MaWin im 
wesentlichen versucht, alle kiritschen Kommentare zu cargo mit Verweisen 
auf semantic versioning zu beantworten oder sie als völligen Unsinn 
bezeichnet.

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

mh schrieb:
> Da müsstest du die Beiträge von vor einem Monat lesen. Da hat MaWin im
> wesentlichen versucht, alle kiritschen Kommentare zu cargo mit Verweisen
> auf semantic versioning zu beantworten oder sie als völligen Unsinn
> bezeichnet.

Ach, habe ich das? Kann es vielleicht sein, dass das in einem völlig 
anderen Zusammenhang war?

Zitiere meine Aussage bitte, wenn du anderer Meinung bist.
Du wirst es nicht schaffen, weil es sie nicht gibt.

Könnten wir jetzt bitte wieder zum Thema zurückkommen? Rust?

MaWin schrieb:
> Ach, habe ich das? Kann es vielleicht sein, dass das in einem völlig
> anderen Zusammenhang war?
Ja und Nein.
> Zitiere meine Aussage bitte, wenn du anderer Meinung bist.
> Du wirst es nicht schaffen, weil es sie nicht gibt.
Ok ...

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

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

Und ja, ich sehe Malware in der Abhängigkeit als Qualitätsproblem.

mh schrieb:
> Und ja, ich sehe Malware in der Abhängigkeit als Qualitätsproblem.

Wie soll die Malware da plötzlich hinein kommen?
Warum soll mir ein Entwickler plötzlich Malware unterschieben?
Und warum ist das ein Problem des Tools?
Und warum ist das jetzt neu und unterscheidet sich von jedem anderen 
Updatemechanismus?

Ich glaube du hast immer noch nicht verstanden, wie crates.io 
funktioniert.

Das ist einzig und alleine ein soziales Problem.
Soziale Probleme lassen sich prinzipiell nicht mit Technik lösen.

MaWin schrieb:
> Soziale Probleme lassen sich prinzipiell nicht mit Technik lösen.

Doch schon, durch Isolation, die man aber mit Rust/CreateCreate 
realisieren kann - wenn man das als nötig befunden hat

Operator S. schrieb:
> Wenn man aber die Version spezifiziert a la Package Install MyFancyLib
> 1.2.5 dann holt er genau diese eine Version.
>
> An dieser Stelle danke für deine kritische Sichtweise, sonst wäre es mir
> nicht bewusst geworden, dass Semantic Versioning tatsächlich genau
> dieses Problem löst.

Ähm, nein, das hilft hier gar nichts. Irgendwann will man die 
Dependencies ja auch updaten, auch um mögliche Sicherheitslücken in 
alten Versionen zu schlissen. Dann macht man "npm/pip/cargo update", und 
was glaubst du, was dann passiert? Genau, es tut was es soll, und 
aktualisiert die Versionen der Abhängigkeiten. Da gibt es jetzt echt 
keinen Unterschied zwischen npm, pip, cargo, etc. Da müsste man schon 
selbst aufpassen, und nochmal genauer hin sehen...

Es ist aber nicht so, dass es keine Ideen gibt, um das Problem mit 
technischen mitteln zu lösen. Google hat letztens eine Dystopische 
Lösung für das Problem vorgeschlagen: Jeder braucht eine rechtsgültige, 
eindeutige Identität im Internet. Baut man scheisse, kann man sich einen 
neuen Job/Hobby suchen... [1]

(Man bedenke auch, dass vielerorts die Einführung von eIDs im Gange ist. 
Am Anfang alles freiwillig, aber sicher schreiben es Onlinedienste 
irgendwann vor, und dann ist ende mit Pseudonymität online, und wir 
enden mit einem von Firmen kontrollierten China-artigen Social Credit 
System...)


1) 
https://opensource.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting-discussion-around-vulnerabilities-in-open-source.html#:~:text=Goal:%20Authentication%20for%20Participants%20in%20Critical%20Software

🐧 DPA 🐧 schrieb:
> Genau, es tut was es soll, und
> aktualisiert die Versionen der Abhängigkeiten.

Bitte lies den Beitrag von Operator S. noch einmal.
Dann informiere dich, was Semantic Versioning ist und was mit diesem 
Satz gemeint ist:

> Wenn man aber die Version spezifiziert a la Package Install MyFancyLib
> 1.2.5 dann holt er genau diese eine Version.

Und dann informiere dich, wie crates.io und Cargo funktionieren.

Das ist und bleibt PEBCAK.

Wenn ich Cargo sage, dass es immer die neuste Version der Schiene ziehen 
soll, egal von welcher Quelle, dann macht es genau das. Oh Wunder.
Wenn ich Cargo sage, dass es das nicht tun soll, tut es das nicht.
Wie ich schon vor einiger Zeit schrieb: Es ist ein Konfigurationsfehler.

Operator S. schrieb:
> Es braucht keine Ideen um das Problem mit technischen Mitteln zu lösen,
> es ist bereits gelöst. Liest hier keiner mehr die Artikel, sondern nur
> die Überschrift?

Nein, Supply Chain Attacks sind real, und auch heute immer noch ein 
Problem. Das kannst du gerne leugnen, ändert aber nichts daran, dass 
diese überall immer mal wieder auftreten.

Operator S. schrieb:
> Definiere einfach deine Paketquelle und die verlangte Version, dann
> nimmt dein Paketsystem nicht einfach die höchste Version die es im
> Internet finden kann.

Ich nehme an du beziehst dich da auf Cargo.lock und co., wenn Projekte 
das direkt in ihrer Cargo.toml machen würde, würde das ja das ganze 
semver Konzept ad absurdum führen. Updaten muss man aber trotzdem von 
zeit zu zeit.

> Operator S. schrieb:
> 🐧 DPA 🐧 schrieb:
>> Irgendwann will man die Dependencies ja auch updaten,
>> ...
> Genau und dieser Schritt macht man von Hand. Es ist eine bewusste
> Aktien, dass man was verändert hat. Wenn man dann einfach nimmt was
> einem hergeworfen wird, sollte man sich ein anderes Handwerk suchen.

Das ist mir schon klar. Wenn man aber immer mal wieder liest, wie ein 
Security Researcher mal wieder was bei allen möglichen Firmen 
eingeschleust hat, dürfte ja wohl klar sein, dass das nicht dem 
entspricht, was in der Realität in der Regel gemacht wird. Ist ja auch 
nicht erstaunlich, wenn Projekte 100te Dependencies haben, die man 
updaten muss.

Operator S. schrieb:
> Und ich meine hier nicht den Fall, dass ein Paket von Version 1.2.3 auf
> Version 2.1.0 ein Update erhalten hat und man bis ins letzte Detail
> nachschauen muss, was ist anders geworden. Wenn aber aus Version 1.2.3
> das Update Version 22.0.0 macht, sollte man das nachprüfen.

Bei Supply Chain Attacks ist der Angreifer nicht gezwungen, die Major 
Version zu ändern, im Gegenteil, man will ja nicht auffallen. Deshalb 
ist es in dem Bezug völlig egal, ob das nur ein Minor Update ist, 
nachprüfen sollte man trotzdem. Nur um zu schauen, ob es noch läuft, 
kann man auch automatisierte Tests machen, das ist eine andere 
Baustelle.

Operator S. schrieb:
> In der oben verlinkten "Sicherheitslücke" geht es aber darum, dass im
> Buildsystem automatisch die neueste Version genommen wird, wenn keine
> Version spezifiziert wurde. Ohne dass man bewusst nach einem Update
> verlangt hat.

Naja, eigentlich war da das Problem mit Privaten vs. Öffentlichen Repos. 
Das ist aber nur einer von vielen Wegen, wie sowas passieren kann. Ein 
Projekt wechselt den Maintainer, jemand lädt versehentlich seine 
Zugangsdaten in Git mit hoch, und schwups, schon ist es passiert. Wobei, 
bei Crates scheint das seltener zu passieren als z.B. bei Chrome 
Extensions.

MaWin schrieb:
> mh schrieb:
>> Und ja, ich sehe Malware in der Abhängigkeit als Qualitätsproblem.
>
> Wie soll die Malware da plötzlich hinein kommen?
> Warum soll mir ein Entwickler plötzlich Malware unterschieben?

Bei hunderten Abhängigkeiten würde ich mich doch eher fragen, warum 
sollte es darunter kein schwarzes Schaf geben?

Semantic Versioning kann eine nette und nützliche Sache sein, aber 
Supply Chain Attacks kann es definitiv nicht verhindern.

🐧 DPA 🐧 schrieb:
> jemand lädt versehentlich seine
> Zugangsdaten in Git mit hoch, und schwups, schon ist es passiert.

Dann ist dieser Entwickler halt unfähig. Gegen Unfähigkeit kann man 
leider wenig machen.

Höchstens so etwas:

https://doc.rust-lang.org/cargo/reference/manifest.html#the-publish-field

🐧 DPA 🐧 schrieb:
> Bei hunderten Abhängigkeiten würde ich mich doch eher fragen, warum
> sollte es darunter kein schwarzes Schaf geben?

Ein Entwickler, der lange gute Versionen herausbrachte, bringt plötzlich 
Malware heraus?
Wann ist das einmal passiert? Das ist doch ein Fall, den du dir jetzt 
herbeikonstruierst, um Recht zu behalten.

Und wo ist der Unterschied zu jedem anderen System? z.B. Linux-Repos.

Niemand, auch nicht Cargo, zwingt jemanden zu einem Update.
Früher im Thread wurde behauptet, dass Leute ihre Dependencies gerne 
100% auditieren wollen. Ja dann bitte. Tut das. Das würde ja dieses 
konstruierte Malwareproblem vollständig lösen.

Das hat alles überhaupt gar nichts mit Rust zu tun!

MaWin schrieb:
> 🐧 DPA 🐧 schrieb:
>> jemand lädt versehentlich seine
>> Zugangsdaten in Git mit hoch, und schwups, schon ist es passiert.
>
> Dann ist dieser Entwickler halt unfähig. Gegen Unfähigkeit kann man
> leider wenig machen.

Nicht zwangsläufig. Sowas ist schnell mal passiert, und könnte jedem 
passieren.

> 🐧 DPA 🐧 schrieb:
>> Bei hunderten Abhängigkeiten würde ich mich doch eher fragen, warum
>> sollte es darunter kein schwarzes Schaf geben?
>
> Ein Entwickler, der lange gute Versionen herausbrachte, bringt plötzlich
> Malware heraus?
> Wann ist das einmal passiert? Das ist doch ein Fall, den du dir jetzt
> herbeikonstruierst, um Recht zu behalten.

Die Maintainer von Software können sich auch ändern, beim Updaten schaut 
da selten jemand nach. Und auch sonst gibt es viele Wege, wie soetwas 
unabsichtlich passieren kann.

z.B. hatte es mal kurz bootstrap erwischt: 
https://nakedsecurity.sophos.com/2019/04/08/bootstrap-supply-chain-attack-is-another-attempt-to-poison-the-barrel/

z.B. Chrome extensions werden gerne mal verkauft: 
https://www.theregister.com/2021/01/07/great_suspender_malware/

Manchmal ist es auch nur ein blöder typo: 
https://github.com/jsdelivr/jsdelivr/issues/18070 (Hat damals glaube ich 
einige getroffen)

Es gäbe noch mehr Beispiele, ist alles schon passiert.

MaWin schrieb:
> Und wo ist der Unterschied zu jedem anderen System? z.B. Linux-Repos.

Das hängt jeweils von der konkreten Distribution und dessen Prozessen 
ab. Zumindest bei fixed Release Distros gibt es oft einen zumindest 
teilweise split zwischen Distro Mantainern und Entwicklern / 
Projektmaintainern. Eine Art 2 Augenprinzip, wenn man will. Die Distro 
Maintainer kennen sich entweder untereinander (kleine Distros), gehören 
zur selben Firma (z.B. RedHat), oder müssen anderweitigen Prozessen und 
Anforderungen genügen (z.B. debian), etc. Es gibt zudem normalerweise 
gewisse Moderadionsstrukturen, nicht jeder kann einfach Zeugs hochladen, 
und wie ein Maintainer mit Problemen umgeht, sowie soziale Aspekte, 
können jenachdem auch beachtet werden. Ausserdem ist es auch möglich, 
problematische Software zu entfernen. Die Pflege / das Managemant der 
Repos ist oft das entscheidende Alleinstellungsmerkmal von 
Distributionen.

MaWin schrieb:
> Niemand, auch nicht Cargo, zwingt jemanden zu einem Update.

Nie upzudaten ist aber auch nicht unbedingt Sicherheitstechnisch ideal.

MaWin schrieb:
> Das hat alles überhaupt gar nichts mit Rust zu tun!

Und deshalb schützt cargo nun plötzlich doch vor Supply Chain Attacks?
Ja ja, schon klar, nur Reden, wenn es pro Cargo und pro Rust ist, ist 
notiert 🙄

🐧 DPA 🐧 schrieb:
> Und deshalb schützt cargo nun plötzlich doch vor Supply Chain Attacks?

Wer hat das behauptet?

MaWin schrieb:
> 🐧 DPA 🐧 schrieb:
>> Und deshalb schützt cargo nun plötzlich doch vor Supply Chain Attacks?
>
> Wer hat das behauptet?

Operator S. schrieb:
> Ironischerweise, löst genau Semantic Versioning das beschrieben Problem
> von derguteweka

Klar, das war weniger allgemein gehalten gedacht, läuft am Ende aber auf 
das heraus.

🐧 DPA 🐧 schrieb:
> läuft am Ende aber auf das heraus.

Es läuft einzig und alleine darauf hinaus, dass du mir Aussagen 
unterstellst, die ich nicht getätigt habe.

Und die dazu noch aus dem Zusammenhang gerissen sind.

Aber das machst du natürlich extra.

🐧 DPA 🐧 schrieb:
> Nie upzudaten ist aber auch nicht unbedingt Sicherheitstechnisch ideal.

Was willst du eigentlich?

Du willst nicht updaten, weil das zu Sicherheitsproblemen führen könnte. 
Die neue Version könnte ja Malware enthalten, weil der Maintainer 
plötzlich zum Gangster wird.

Du willst updaten, weil das zu Sicherheitsproblemen führen könnte. Die 
alte Version könnte ja Bugs enthalten.

Wie soll man das lösen?
Es ist unlösbar.

MaWin schrieb:
> 🐧 DPA 🐧 schrieb:
>> läuft am Ende aber auf das heraus.
>
> Es läuft einzig und alleine darauf hinaus, dass du mir Aussagen
> unterstellst, die ich nicht getätigt habe.

Keineswegs. Ich habe dich lediglich darauf hingewiesen, warum das ganze 
hier Relevant wurde:

🐧 DPA 🐧 schrieb:
> MaWin schrieb:
>> Das hat alles überhaupt gar nichts mit Rust zu tun!
> Und deshalb schützt cargo nun plötzlich doch vor Supply Chain Attacks?

Supply Chain Attacks in Relation zu Semantic Versioning / cargo war die 
relevante Problematik, um die es in der momentanen Argumentation seit 
Beitrag #6584067 ging. Das ist auch, weshalb das ganze hier überhaupt 
relevant wurde. Ich dachte es wäre klar, worüber wir Diskutieren?

MaWin schrieb:
> Was willst du eigentlich?

Zu einem klareren Bild der ist-Situation und existierenden Problematiken 
beitragen?

MaWin schrieb:
> Wie soll man das lösen?
> Es ist unlösbar.

Ja, das ist so.

🐧 DPA 🐧 schrieb:
> Ich dachte es wäre klar, worüber wir Diskutieren?

Ja, das ist klar.
Über alles, aber nicht mehr über Rust.

> Ja, das ist so.

Dann können wir es ja damit abschließen, dass auch Rust unlösbare 
Probleme nicht löst.

Ok?

MaWin schrieb:
> Ja, das ist klar.
> Über alles, aber nicht mehr über Rust.

für den Rest:

"Rust" ist keine Platform sondern die Programmiersprache

Cargo ist der Standard Package-Manager und das Buildsystem für Rust - 
aber sogar das muss man nicht nutzen

und der Package-Manager kann so verantwortungslos (ich geben keine 
Versionen and und ziehe immer latest) bis zur absoluten statik (mein 
eigenes lokales crate wo ich alles von Hand rein tragen muss) 
konfiguriert werden - da kann man so viele Review Prozesse einschieben 
wie man braucht und will

Alle Package-Manager können das - und ja, die werden von Millionen 
Leuten verwendet und das kann gefährlich sein - sogar GitHub und GitLab 
machen das wenn man z.B. die submodule updated - von irgendeinem Projekt

und die Programmiersprache Rust ist auch nicht deswegen schlechter als 
andere weil ihr Standard-Package-Manager die gleichen unlösbaren 
Sicherheitsprobleme erzeugen kann wie jedes andere diese Systeme - also 
um was geht es?

Ich arbeite u.a. in Projekte in dem alles durch ordentliche 
Review-Phasen laufen muss und jedes noch so kleine 3rd-Party Update 
einen riesen Aufwand verursacht - die haben teilweise auch lokale 
Package-Manager für C++ im Einsatz und die Packages die da rein kommen 
sind eben reviewed

Vetrauen ist alles und Kontrollen machen die wenigsten - 
höchstwahrscheinlich sogar die am wenigsten die hier so gross davon 
reden wie wichtig das alles ist...

Operator S. schrieb:
> mh schrieb:
>> Da müsstest du die Beiträge von vor einem Monat lesen
>
> Hab ich, den Thread verfolge ich seit Beginn.
>
> Ironischerweise, löst genau Semantic Versioning das beschrieben Problem
> von derguteweka (Warum auch immer das hier in einem Rust Thread gelandet
> ist...)
>
> Wenn man nämlich nur schreibt Package Install MyFancyLib, dann holt er
> sich das Package mit der höchsten Version das er finden kann. Ein
> "Hacker" erstellt dann einfach auf der öffentlichen Paketsource ein
> MyFancyLib mit einer sehr hohen Version und Zack landet es in deinem
> System.
>
> Wenn man aber die Version spezifiziert a la Package Install MyFancyLib
> 1.2.5 dann holt er genau diese eine Version.

Und du stellst sicher, dass in MyFancyLib die Dependencies 100% korrekt 
definiert sind? Und in den Dependencies der Dependencies von MyFancyLib?
Nachdem ich eben etwas auf crates.io gestöbert habe, muss man das wohl 
explizit selbst prüfen, da die meisten crates Dependencies explizit oder 
implizit als "Caret requirements" angeben. Ich hab einige ziemlich lange
Ketten verfolgen können.
Es ist auch klar warum das so ist. Niemand hat lust sich häufig 
"Dependency Resolution failed" vom resolver zu beschäftigen.

🐧 DPA 🐧 schrieb:
> Wobei,
> bei Crates scheint das seltener zu passieren als z.B. bei Chrome
> Extensions.
Bleibt die Frage, ob es tatsächlich so ist, oder ob es nur scheint. Die 
Zielgruppe für Chrome Extensions ist vermutlich deutlich größer.

cppbert schrieb:
> und die Programmiersprache Rust ist auch nicht deswegen schlechter als
> andere weil ihr Standard-Package-Manager die gleichen unlösbaren
> Sicherheitsprobleme erzeugen kann wie jedes andere diese Systeme - also
> um was geht es?

Wenn ich mich richtig erinnere, hast du behauptet, dass cargo den 
Pflegeaufwand für Software reduziert:
mh schrieb:
> cppbert schrieb:
>> Jede Library hat die 5000.Implementation von irgendeinem Micro-Scheiss
>> im Bauch die so viel Pflege-Energie frisst - das versucht Rust mit einer
>> Zerlege- es-in-Libs-und-verteile-die-leicht zu reduzieren
>
> Damit ist man den Pflegeaufwand aber nicht los geworden, sondern verlegt
> ihn nur woanders hin. Du musst regelmäßig die Abhängigkeiten prüfen

In dem gleichen Beitrag hast du das übrigens auch als Vorteil von rust 
angepriesen:
cppbert schrieb:
> 4. Anstatt das jedes noch so kleine Projekt Self-Contained ist baut Rust
> einfach darauf das sich die Code-Duplikation über viele, gut gepflegte
> Libraries reduziert die in den heutigen Projekten in Mio Zeilen Code
> rumgurken

mh schrieb:
> Wenn ich mich richtig erinnere, hast du behauptet, dass cargo den
> Pflegeaufwand für Software reduziert:
> mh schrieb:
>> cppbert schrieb:
>>> Jede Library hat die 5000.Implementation von irgendeinem Micro-Scheiss
>>> im Bauch die so viel Pflege-Energie frisst - das versucht Rust mit einer
>>> Zerlege- es-in-Libs-und-verteile-die-leicht zu reduzieren
>>
>> Damit ist man den Pflegeaufwand aber nicht los geworden, sondern verlegt
>> ihn nur woanders hin. Du musst regelmäßig die Abhängigkeiten prüfen
>
> In dem gleichen Beitrag hast du das übrigens auch als Vorteil von rust
> angepriesen:
> cppbert schrieb:
>> 4. Anstatt das jedes noch so kleine Projekt Self-Contained ist baut Rust
>> einfach darauf das sich die Code-Duplikation über viele, gut gepflegte
>> Libraries reduziert die in den heutigen Projekten in Mio Zeilen Code
>> rumgurken

das sind zwei paar Stiefel

Das einen ist die undurchsichtige und Codelastige alles-selber-machen 
Kultur durch eine es-gibt-viele-kleine Crates die sich auf Aufgaben 
konzentrieren Kultur zu ersetzen - die Libs werden kleiner und überhaupt 
reviewbarer

Das ist das Konzept das wir alle intern mit jeder unserer eigenen 
Komponenten fahren - was vom Grundsatz nicht falsch und nicht wirklich 
diskutierbar ist

bei C/C++ klappt das einfach Aufgrund des schwierigen Deployments 
(welche Make-Tool, 3rd-Parties, etc.) nicht so gut über die 
Projektgrenzen hinweg,  ist aber eher eine historische Schwäche als ein 
gewolltest Konzept von C/C++

Das zweite ist die Menge der Entwicklern die plötzlich Einfluss auf dein 
Projekt haben könnten - da geben ich dir recht das es nicht einfacher 
wird - aber Monolithen-Libs mit viel gemeinsamen Redundanzen ist es eben 
auch nicht - da wähle ich lieber die Qualität ergibt sich durch die 
Community - und wenn ich viele 3rd-Parties brauche bin verliere ich auch 
mit C/C++ recht schnell die Kontrolle (falls man wirklich nicht auf die 
3rd-Parties verzichten kann)

und ich denke die wenigsten hier machen überhaupt irgendwelche Reviews 
von 3rd-Parties - wenn es kompiliert und die Tests laufen ists gut wird 
wohl die Standard-Devise sein, die Community der Libs oder gar die 
Kern-Entwickler haben auch die wenigsten auf ihrer Kontakt-Liste also 
ist die Qualität nur gut weil man nix negatives im Internet liesst oder 
eben keinen 3rd-Parties hat

noch dazu heisst es ja immer das Rust nicht nötig ist weil jede Firma 
sowiso nur Profi-Entwickler angestellt haben sollte - d.h. die können 
sich dann in Rust aufhören mit den internen Problemen zu beschäftigen 
sondern nur noch Algorithmik und die Sicherheits-Probleme durch die 
vielen 3rd-Party Abhängigkeiten bekämpfen :)

mh schrieb:
> Und du stellst sicher, dass in MyFancyLib die Dependencies 100% korrekt
> definiert sind?

nein. Ich nicht.
Das war aber auch nie meine Anforderung.

mit dem neuen VS2019 16.9 Release können wir jetzt auch unter 
Windows/VStudio mit dem ASAN arbeiten - raus aus der Beta-Phase - läuft 
super - "leider" keine Findings da mein Code ja schon unter Linux seit 
einigen Jahren unter Sanitzer Kontrolle steht

https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes#16.9.0

Und für die "C++ ist ausreichend perfekt durch ASAN"-Fraktion:

Stellt euch mal vor wenn google nicht aus Eigeninitative die Sanitizer 
entwickelt hätte - wohlgemerkt nach "Jahrzehnten" der C/C++ Existenz, 
was würde eigentlich dann weiterhin für die Memory-Sicherheit bei C/C++ 
Applikationen unter Windows sorgen - der olle Intel Inspector, Dr. 
Memory...?

und ja ist versteht das auch Rust einen Neuentwicklung ist - nur ist da 
sowas von Anfang an dabei, C/C++ hat dafür 25 Jahre auf einen 
Gross-Konzern warten müssen

und auch wenn ihr mir nicht glaubt (oder ich nur viele Idioten kenne)

Es gibt sogar C/C++ Entwickler die nicht verstehen was an Rust besser 
ist UND die zusätzlich auch keinen Sinn in den Sanitizern sehen

Noch besser: die den Sinn von Sanitizer erst verstehen wenn man ihnen
im VStudio, in ihrem Code einen durch den ASAN gefundenen Bug zeigen 
kann - meistens wird dann ganz schnell aus einem unwissenden Kritiker 
ein Missionar

ganz nach dem Motto: Erst wenn ich den Schimmel wirklich schmecken kann 
erkennen ich das irgendwas mit meinem weiß pelzigen Brot nicht stimmt :)

Jedzia D. schrieb:
> Cargo ist nicht Rust. Es ist nur in Rust geschrieben. Lasst uns doch mal
> gegen Conan schelten und deswegen C++ verdammen.

Mir ist bisher noch kein C++ Projekt über den Weg gelaufen, bei dem 
conan der Hauptweg ist, wie man an die Dependencies kommt und alles 
Kompiliert. Bis vorhin habe ich von conan tatsächlich noch nie gehört.

Bei Cargo hingegen sieht das alles ganz anders aus, da muss man suchen, 
um etwas zu finden, was es nicht nutzt.

Die Situation ist schlicht nicht vergleichbar.

Zudem wurde hier auch immer klar angegeben, ob ein Problem/Vor-/Nachteil 
mit Cargo oder mit Rust besteht.

Wäre die Diskussion gegen C++, und jemand würde sagen, verwendet nicht 
Conan, weil XY, hätte ich damit ehrlich gesagt kein Problem.

google unterstüzt Rust im Linux Kernel - (und Nein, ihr eigenes Go kann 
nicht im Kernel genutzt werden)

https://security.googleblog.com/2021/04/rust-in-linux-kernel.html

der Binder-Code in Rust sieht fiese aus - liegt aber auch daran das da 
viel C-Binding/FFI Sachen zu sehen sind

Linus und Greg sind weit, weit offener als zu den damaligen C++ 
Diskussionen :)

ich bin gespannt ob diese Integrations-Bestrebungen zu weiteren 
Verbesserungen in Rust führen und schlussendlich auch die Integration in 
den Kernel passiert und ob das auch die GCC Frontend-Entwicklung 
befeuert

mittlerweile sind alle Grossen der Branche für ihre Low-Level 
Entwicklung mehr oder minder auf den Rust Zug aufgesprungen - google, 
Microsoft, Amazon, Facebook... egal wie man die Sache sieht - Rust in 
den Bereichen ihren eigenen Produkten/bisherigen Strategien vorzuziehen 
ist schon eine Aussage

und Nein, kein Mensch der bei klarem Verstand ist möchte dann alles 
portieren :) - sagt auch niemand, und denkt nicht mal irgendjemand

und Nein, eine C/Rust Mischung ist nicht per se der Teufel - nur für die 
Leute die immer gleich alles portieren wollen :)

> google unterstüzt Rust im Linux Kernel - (und Nein, ihr eigenes Go kann
> nicht im Kernel genutzt werden)

Jaja, ich hab das hier gelesen:

https://www.heise.de/news/Startschuss-fuer-Rust-Entwicklung-im-Linux-Kernel-6017060.html

Der Artikel hat mir mal wieder klar gemacht was in der heutigen 
Entwicklung alles so falsch laeuft. Ich zitiere mal einen Satz:

    Ein Kernel-Crate (Rust-Bezeichnung für Bibliothek) stellt
    die Kernel-API für Rust-Module bereit.

Diese ganzen Bullshitbingoschwachkoepfe denken sich fuer den banalsten 
Unsinn eigene Sandkastenwoerter aus, die sie dann noch anderen erklaeren 
muessen weil sonst keiner mit ihnen spielen will, und wundern sich das 
ihren Kram keiner will?

Olaf

Olaf schrieb:
> Diese ganzen Bullshitbingoschwachkoepfe denken sich fuer den banalsten
> Unsinn eigene Sandkastenwoerter aus

Welcher Begriff stört dich denn?

Rolf M. schrieb:
> Warum nennt man eine Bibliothek "Crate" statt "Bibliothek"?

Weil ein Crate viel mehr ist als das, was man üblicherweise unter einer 
Bibliothek versteht.
Ich würde Crate eher mit Paket übersetzen. Das käme ja auch vom Wortsinn 
etwas besser hin.

Es ist nicht so, als hätte man bei Rust beliebig Worte ohne Not 
erfunden. Es gibt ja auch z.B. Module und auch ein Lib(-Crate).

Dergute W. schrieb:
> Millionen Fliegen koennen nicht irren...

rustup update

Schon schwierig, gell?

Dergute W. schrieb:
> root [ /usr/src/rav1e ]# rustup update
> -bash: rustup: command not found

Ja gut. Dann ist deine Installation halt kaputt.
Und warum machst du das überhaupt als root?

> Und ganz abgesehen davon halte ich's fuer keine gute Idee, fuer jedes
> Projekt in jeder Versionsnummer dann auf den jeweils "richtigen" rust
> compiler achten zu muessen.

Rust ist rückwärtskompatibel. Und das ist auch erklärtes Ziel von Rust.
Das heißt man kann immer den aktuellen stable-Compiler verwenden.

Ich sehe da auch überhaupt kein Problem.

Es gibt so gut wie keine praktisch verwendete relevante Sprache, die 
nicht auch weiterentwickelt wird.
Das gilt auch für so abgehangene Sprachen wie C.

Dergute W. schrieb:
> Moin,
>
> So, aus aktuellem Anlass hab' ich mir mal grad' wieder den rav1e neu
> ausgecheckt.
> Und versucht zu bauen. Bricht natuerlich ab.

das ist eine mehr als bekannte Schwäche der Sprache - weil sie eben noch 
in sehr stark in der Entwicklung ist - sollen sie einfach alle Feature 
von C++ kopieren und dann Releasen oder einfach nur C Klonen - damit 
solche Sprächänderungen/Erweiterungen nicht passieren - was wäre denn 
laut dir am sinnvollsten - außer es gar nicht zu machen

das N was da mukiert wird ist das neue Feature von Konstanten als 
Template-Parameter - was es bei C++ eben schon seit 20 Jahren gibt, 
davor aber genau so wenig vorhanden war - da hat auch jeder alte 
Kompiler zu der Zeit das fluchen angefangen als die Libs darauf 
umgestellt wurden - warum darf so was heute deiner Meinung gar nicht 
mehr passieren?

Denkst du ernsthaft das diese häufigen Änderungen zum Standard werden - 
oder das die Menschen die dahinter stehen alle so schlecht sind das 
Problem nicht als solches zu erkennen?

C/C++ war 5 Jahren nach effektivem Erst-Release auch Meilen weg von 
Standard und Gleichmäßigkeit - ich glaube ihr seit alle zu jung oder 
habt vergessen wie das damals war

Dergute W. schrieb:
> Moin,
> Und ganz abgesehen davon halte ich's fuer keine gute Idee, fuer jedes
> Projekt in jeder Versionsnummer dann auf den jeweils "richtigen" rust
> compiler achten zu muessen.

das war als C/C++ erfunden wurde doch genau so - oder hast du erst in 
den späten 90er mit Software-Entwicklung angefangen?

Olaf schrieb:
> Jaja, ich hab das hier gelesen:
>
> 
https://www.heise.de/news/Startschuss-fuer-Rust-Entwicklung-im-Linux-Kernel-6017060.html

relevant ist aber das Google jetzt aktiv diese Projekt unterstützt - 
offiziell und mit eigenen Entwicklern

Dergute W. schrieb:
> So, aus aktuellem Anlass hab' ich mir mal grad' wieder den rav1e neu
> ausgecheckt.
> Und versucht zu bauen. Bricht natuerlich ab.

das passiert dir genau so mit deinem alten Kompiler wenn du eine C11 
oder C++17 Lib kompilieren willst

bei Qt6 ist C++17 jetzt der Standard - d.h. mind VS2017 latest oder 
VS2019, oder gcc 7+

aber solche Libs sind dann eben für dich unrelevant und daher kein 
Problem der Sprache

cppbert schrieb:
> Olaf schrieb:
>> Jaja, ich hab das hier gelesen:
>>
>>
> 
https://www.heise.de/news/Startschuss-fuer-Rust-Entwicklung-im-Linux-Kernel-6017060.html
>
> relevant ist aber das Google jetzt aktiv diese Projekt unterstützt -
> offiziell und mit eigenen Entwicklern

Warum ist das relevant? Gibts jetzt endlich nen Standard und nen 
alternativen Compiler?

cppbert schrieb:
> bei Qt6 ist C++17 jetzt der Standard - d.h. mind VS2017 latest oder
> VS2019, oder gcc 7+

Es gibt schon einen kleinen Unterschied zwischen einem mehr als 3 Jahre 
alten Standard und einer speziellen Compilerversion, die nichtmal einen 
Monat alt ist.

mh schrieb:
> Es gibt schon einen kleinen Unterschied zwischen einem mehr als 3 Jahre
> alten Standard und einer speziellen Compilerversion, die nichtmal einen
> Monat alt ist.

Nein, nicht wirklich.
Wenn dein Compiler älter ist, funktioniert es nicht. Dann ist ein Update 
fällig. Das ist in beiden Fällen identisch.

Ich sehe auch keinen Grund das Compilerupdate zu verzögern.
Es ist ein einziger Befehl, der dein Problem löst:
rustup update

mh schrieb:
> Warum ist das relevant? Gibts jetzt endlich nen Standard und nen
> alternativen Compiler?

Nein - aber darf sich das durch solche Projekte nicht erst entwickeln?

Woher kommt ständig dieser Es-muss-fertig-sein-Hochmut dem fast keine 
Programmiersprache in ihrer Entwicklung gerecht wurde und auch die 
meisten von euch nicht bei ihrere eigenen Arbeit leisten können?

Warum so ängstlich - denkst du ernsthaft das die Kernel-Entwickler Rust 
akzeptieren bevor nicht alle Bedenken ausgeräumt sind - denkst du die 
sind sind Fähig für ihr weit >10Mio Zeilen Code Projekt richtige und 
sinnvolle Entscheidungen zu treffen? meinst du da kommt jede Sprache 
einfach so rein?

Ich hätte auch gerne noch ein gcc-Frontend und einen Standard - aber 
scheinbar ist Rust auch schon so relevant genug das es nicht wie alle 
anderen Sprachen die es versucht haben direkt an Linus und Greg 
scheitert

mh schrieb:
> Es gibt schon einen kleinen Unterschied zwischen einem mehr als 3 Jahre
> alten Standard und einer speziellen Compilerversion, die nichtmal einen
> Monat alt ist.

Wie lange ist C++ in der Entwicklung, wie lange Rust?
Was willst du vergleichen?

MaWin schrieb:
> Ich sehe auch keinen Grund das Compilerupdate zu verzögern.

Es gibt schon viele Projekte wo so was nicht erlaubt ist - weil die 
Kompiler neue Fehler einbringen könnten - z.B. im Medizinbereich war ich 
dem stark ausgesetzt

MaWin schrieb:
> mh schrieb:
>> Es gibt schon einen kleinen Unterschied zwischen einem mehr als 3 Jahre
>> alten Standard und einer speziellen Compilerversion, die nichtmal einen
>> Monat alt ist.
>
> Nein, nicht wirklich.
> Wenn dein Compiler älter ist, funktioniert es nicht. Dann ist ein Update
> fällig. Das ist in beiden Fällen identisch.
Das heißt ich kann ab jetzt erwarten, dass jeder C++20 benutzt?

> Ich sehe auch keinen Grund das Compilerupdate zu verzögern.
> Es ist ein einziger Befehl, der dein Problem löst:
> rustup update
Du hast gesehen, warum der zu alte rustc abbricht?

1

error[E0658]: const generics are unstable

Ist rust 100% abwärtskompatibel? Also alles was mit 1.47 korrekt 
funktioniert hat, funktioniert auch mit 1.51?

cppbert schrieb:
> Es gibt schon viele Projekte wo so was nicht erlaubt ist - weil die
> Kompiler neue Fehler einbringen könnten - z.B. im Medizinbereich war ich
> dem stark ausgesetzt

Richtig.
Und in solchen Projekten zieht man sich die neusten Crates rein, die 
neue Compilerabhängigkeiten bekommen?
Natürlich macht man das nicht.
Damit existiert das Problem auch nicht.

cppbert schrieb:
> mh schrieb:
>> Es gibt schon einen kleinen Unterschied zwischen einem mehr als 3 Jahre
>> alten Standard und einer speziellen Compilerversion, die nichtmal einen
>> Monat alt ist.
>
> Wie lange ist C++ in der Entwicklung, wie lange Rust?
> Was willst du vergleichen?
Man könnte mit der Zeitdifferenz zwischen erster Veröffentlichung der 
Sprache und des offiziellen Standards anfangen. Oder Anzahl der Compiler 
nach 10 Jahren.

mh schrieb:
> erwarten, dass jeder C++20 benutzt?

Nein. Warum?
Nur weil ein Crate einen neueren Compiler voraussetzt, wird nicht gleich 
jeder gezwungen ein Update zu machen. Weder auf das neue Crate, noch auf 
den neuen Compiler.

> Du hast gesehen, warum der zu alte rustc abbricht?error[E0658]: const
> generics are unstable

Ja, und?

> Ist rust 100% abwärtskompatibel? Also alles was mit 1.47 korrekt
> funktioniert hat, funktioniert auch mit 1.51?

Ja.

mh schrieb:
> Man könnte mit der Zeitdifferenz zwischen erster Veröffentlichung der
> Sprache und des offiziellen Standards anfangen. Oder Anzahl der Compiler
> nach 10 Jahren.

Und welche Erkenntnis bringt das?

MaWin schrieb:
>> Ist rust 100% abwärtskompatibel? Also alles was mit 1.47 korrekt
>> funktioniert hat, funktioniert auch mit 1.51?
>
> Ja.

Aber natürlich bringt das nichts wenn man Features nutzt die erst in 
1.51 verfügbar sind, aber das ist bei keiner Programmiersprache die sich 
noch weiterentwickelt anders

Auch bei C++ ist das Geschrei gross wenn Libs den notwendigen Standard 
anheben, weil es immer einen Haufen Leute gibt die nur C++03 kompilieren 
können

Klaus W. schrieb:
> Ein altes C-Programm aus Zeiten von Kernighan und Ritchie geht dann
> nicht mehr als C++ 20 durch. Aber trotzdem kann ich sie glatt
> kompilieren, wenn ich --std=.. angebe.
> Erst wenn ich im Quelltext einen neueren Standard nutze, muß ich den
> dann auch erfüllen und alte Leichen wegräumen oder mumifizieren.
>
> Der neueste gcc kompiliert wunderbar über 40 Jahre alte Quelltexte.

Das ist bei Rust ganz genau so.
--std heißt bei Rust "edition".

> Jetzt kann man von einer relativ neuen Entwicklung wie Rust das gar
> nicht verlangen, das wäre unfair.

Doch. Das kann man verlangen und das ist auch erklärtes Ziel von Rust.

Klaus W. schrieb:
> Mir zieht es die Fußnägel hoch, wenn man damit auf Linux losgehen will.

Wie begründest du das?

MaWin schrieb:
>> Jetzt kann man von einer relativ neuen Entwicklung wie Rust das gar
>> nicht verlangen, das wäre unfair.
>

Aber warum beschwerst du dich dann das dein c++11 kompiler die lib nicht 
kompilieren kann die c++14 Features nutzt

Die lib die du da baust wird ziemlich nah an der latest Entwicklung 
gehalten, weil die von den Neuerungen stark profitieren, ist natürlich 
nicht so nett für dich, aber Rust kann nichts dafür das die eben jedem 
Feature hinterherspringen

Die sind sozusagen geraden von c++17 auf c++20 gesprungen

MaWin schrieb:
> Klaus W. schrieb:
>
>> Mir zieht es die Fußnägel hoch, wenn man damit auf Linux losgehen will.
>
> Wie begründest du das?

Weil er die Kompilierfehler fälschlicherweise als 
Kompatibilitätsprobleme erkannt hat obowohl eigentlich die Lib plötzlich 
latest Features braucht

Und es immer wieder mitschwingt als wäre die Linux Kernel 
Entwicklergemeinde nicht in der Lage sinnvolle Entscheidungen zu 
treffen, so wie scheinbar die meisten Grossen scheinbar aus niederen 
oder den falschen Gründen anfangen Rust zu betrachten, obwohl C und C++ 
ja scheinbar alles genau richtig machen

Rolf M. schrieb:
> C++03 ist 18 Jahre alt, Rust 1.47 ein halbes Jahr.

Und es war die Entscheidung der Crateentwickler, die relativ neue 
Version 1.51 voraussetzen.
Das hat mit Rust ansich gar nichts zu tun.
Genauso gut hätten C++-Lib-Entwickler irgendein brandneues GCC-Feature 
vorausetzen können. Das ist eine ganz normale Entwicklungsentscheidung.

Aber ich kann es gut nachvollziehen, warum man gerne die neusten 
Rust-Features nutzt. Denn ein Rust-Compiler-Update ist sehr einfach und 
problemlos durchführbar für jeden. Und wenn jemand das nicht möchte, 
kann sie ja gerne auf der älteren Crateversion bleiben.

> Und jetzt hoffentlich bald diese richtungsweisende, stabile Sprache im
> Linuxkernel.

Ich schaetze dafuer muss das Build-System dann problemlos mit Makefile 
funktionieren und die ganze automatische Internet-Librarykacke wird 
rausgeworfen. Sonst bleibt das nicht lange drin weil Linus vermutlich 
sofort das Messer in der Tasche aufgeht wenn er seinen Kernel neu 
uebersetzen will und es nicht klappt weil irgendein scheiss sich updaten 
muss, nach dem updaten was anderes nicht funktioniert usw...

Olaf

Olaf schrieb:
> Ich schaetze dafuer muss das Build-System dann problemlos mit Makefile
> funktionieren und die ganze automatische Internet-Librarykacke wird
> rausgeworfen. Sonst bleibt das nicht lange drin weil Linus vermutlich
> sofort das Messer in der Tasche aufgeht wenn er seinen Kernel neu
> uebersetzen will und es nicht klappt weil irgendein scheiss sich updaten
> muss, nach dem updaten was anderes nicht funktioniert usw...

Wie schon 1000 mal gepostet: das ist kein Zwang, du kannst auch alles 
selber verwalten - und das ist genau das was die Kernelentwickler machen 
werden wenn es denn dazu kommt

Rust fügt ein paar interessante Ideen ein:

-einheitliches Cargo Buildsystem
-das "match" System ist mächtig
-error handing gefällt mir gut
-mehr move als copy

Und Rust wäre auch eine schöne Sprache, wäre sie nur nicht
so schmerzhaft zu nutzen. Fast alle Sachen brauchen 10mal
so lange wie z.b. in C++. Ständig hängt man am borrow
checker fest.

Greife auf eine Klassenvariable zu. Greife dann auf eine
andere zu. Geht schon nicht, weil `self` schon geborrowed
wurde. Selbst die einfachsten for-loops durch Container
kann man da vergessen. Antwort von der Rust Community:
"Ja sowas machen wir hier nicht. Optionen:"
-Algorithmus umschreiben (bitte was?)
-Datenstruktur verändern, mit Boxen und Refcounting
-Fiese Speicher-moves

Alle komplexeren Datenstrukturen sind extrem schmerzhaft
aufzubauen.

Dann, das trait system. In der Theorie ganz lustig. Man kann
einem i32 neue Funktionen dranhängen. Yey. In der Praxis sucht
man sich in der Doku kaputt wo das trait jetzt herkommt und in
welcher Crate man jetzt sein Feature findet. Ja ich weiß,
Doku kommt mit der Zeit. Doch dass sich mein Funktionsumfang
pro Typ ändern kann und nicht einfach ein klares Interface hat
ist schon... seltsam

Und dann Clippy und der Auto-formatter. Auch hier wieder, in
der Theorie gut. In der Praxis fixe ich ständig irgentwelche
Kleinigkeiten Wo Clippy sich wieder aufregt. Neulich passte
ihm der Name meines Typen nicht. Gibt ein Standard-naming
und meine Variable passt nicht. Rust Community sagt wieder
"nicht unser Problem, DU machst was falsch".
Und als Sahnehäubchen oben drauf hat der autoformatter einen
riesen Spaß dabei, 10 Zeilen die inhaltlich zusammen hängen
jedes mal anders umzubrechen. Konsistenz von Code ist wohl
heute nicht mehr wichtig.

Daher:
Andere Sprachen (besonders C++), nehmt euch ein Beispiel an
den guten Ideen die Rust bringt und baut diese auch ein.
Grade Paketmanager + Buildsystem ist sehr hilfreich.
Aber die Sprache selber... wollte zu viel, Ziel überschossen.

Und zur Sicherheit: Die Entwicklung ist um ein vielfaches
Langsamer, Netzwerkfehler, Logikfehler, etc gibt es auch
weiterhin. 90% der Zeit steckt eh wieder ein Kunde daher
der auf seiner Seite einen Fehler produziert hat der das
ganze System anhält. Aber hey, dafür haben wir keine
Speicherleaks mehr. Wie war das? Haben wir in C++ dank
RAII auch nie gehabt? Hmm. Aber die Datensicherheit und
das Owner Konzept! Oh, gibts in C++ auch. Hmm.

> und meine Variable passt nicht. Rust Community sagt wieder
> "nicht unser Problem, DU machst was falsch".

Das ist ein Standardproblem unserer Zeit. In Sprachen der C-Familie
hast du alle Moeglichkeiten, musst aber eine ganze Menge lernen,
unter anderem damit du manche der Moeglichkeiten nicht nutzt.

Etwas das nicht immer klappt und dann zu Fehlern fuehrt und das noch
ganz besonders wenn du eher weniger gute (preiswerte) Programmierer 
nutzen moechtest. Es gab in den letzten 30Jahren eine Verschiebung von 
wenigen Programmierer fuer eher "wichtige" Sachen zu vielen 
Programmieren fuer "jeden Scheiss der nicht bei drei auf den Baeumen 
ist".

Daher gibt es ein Interesse daran die Leute soviel wie moeglich zu 
gaengeln.
Diese Sprachen kommen ja nicht mehr aus dem Interesse der Programmierer
ein Problem zu loesen, sondern aus dem Interesse einer Firma das ihre 
Probleme
so preiswert wie moeglich geloest werden.

Eine gute Sprache ist das Handwerkzeug eines Kuenstlers um Kunstwerke zu 
schaffen (im Idealfalle!) heute will man aber nur noch Handwerk.

> Andere Sprachen (besonders C++), nehmt euch ein Beispiel an
> den guten Ideen die Rust bringt und baut diese auch ein.

Ja, ich denke etwa in diese Richtung sollte es laufen. Wobei man sich 
manchmal fragt was denn noch in C++  fehlen koennte. :)

Olaf

Phasenschieber schrieb:
> Fast alle Sachen brauchen 10mal
> so lange wie z.b. in C++.

Als Anfänger vielleicht. So wie mit jeder neuen Programmiersprache auch, 
die neue und unbekannte Konzepte verwendet.

Phasenschieber schrieb:
> Greife auf eine Klassenvariable zu. Greife dann auf eine
> andere zu. Geht schon nicht, weil `self` schon geborrowed
> wurde. Selbst die einfachsten for-loops durch Container
> kann man da vergessen.

Das ist einfach nur falsch, so wie du es schreibst.
Es sei denn du bringst ein Beispiel und wir das diskutieren.

Natürlich kann man nacheinander(!) schreibend, oder gleichzeitig lesend 
auf Member zugreifen.
Natürlich kann man sehr einfach über Container iterieren. Dazu gibt es 
sehr viele verschiedene Konzepte. So wie das halt in modernen Sprachen 
ist. Für jeden Geschmack was dabei.

Phasenschieber schrieb:
> In der Praxis sucht
> man sich in der Doku kaputt wo das trait jetzt herkommt

Traits muss man explizit importieren (use). Ohne use, auch keine 
zusätzlichen Trait-implementationen zu bereits bekannten Typen.

Phasenschieber schrieb:
> Aber hey, dafür haben wir keine
> Speicherleaks mehr.

Rust verhindert keine Speicherleaks.

Phasenschieber schrieb:
> Hmm. Aber die Datensicherheit und
> das Owner Konzept! Oh, gibts in C++ auch. Hmm.

In C++ ist es sehr viel umständlicher und sperriger zu nutzen.
Wenn man es konsequent durchzieht, ist es daher in C++ deutlich mehr 
Aufwand.
Und daher zieht es niemand konsequent durch.

Wo genau finde ich die Doku für rust 1.47?

mh schrieb:
> Wo genau finde ich die Doku für rust 1.47?

rustup component add rust-docs

https://rust-lang.github.io/rustup/concepts/components.html

Oder online für die neuste Version:
https://www.rust-lang.org/learn

MaWin schrieb:
> mh schrieb:
>> Wo genau finde ich die Doku für rust 1.47?
>
> rustup component add rust-docs
>
> https://rust-lang.github.io/rustup/concepts/components.html
>
> Oder online für die neuste Version:
> https://www.rust-lang.org/learn

Also wenn ich die 1.47er Doku haben will, muss ich erst den Compiler in 
der richtigen Version installieren? Wenn ich vergleichen will, muss ich 
hin und her wechseln?

mh schrieb:
> Wenn ich vergleichen will, muss ich hin und her wechseln?

Nein. Wie schon mehrfach hier im Thread geschrieben wurde, sind die 
Compilerversionen rückwärtskompatibel. In der Doku des neusten Compilers 
sind also auch alle Elemente der Vorgängerversionen enthalten. Mit 
entsprechenden Versionstags ist gekennzeichnet, mit welcher Version 
welches Feature eingebaut wurde.

MaWin schrieb:
> mh schrieb:
>> Wenn ich vergleichen will, muss ich hin und her wechseln?
>
> Nein. Wie schon mehrfach hier im Thread geschrieben wurde, sind die
> Compilerversionen rückwärtskompatibel. In der Doku des neusten Compilers
> sind also auch alle Elemente der Vorgängerversionen enthalten. Mit
> entsprechenden Versionstags ist gekennzeichnet, mit welcher Version
> welches Feature eingebaut wurde.

Das ist nicht das was ich gefragt habe ...
Ich konnte in der Doku keine Versionstags finden, muss also alles seit 
der ersten Veröffentlichung unverändert sein. Allerdings konnte ich in 
der Doku selbst (https://doc.rust-lang.org/reference) auch keine Info 
finden, für welche Version diese Doku gilt.

mh schrieb:
> Das ist nicht das was ich gefragt habe ...

Und was hast du gefragt?

> Ich konnte in der Doku keine Versionstags finden

Aha.
Dann solltest du vielleicht einmal genauer gucken.

Beispiel:
https://doc.rust-lang.org/std/primitive.u32.html#associatedconstant.MIN

MIN gibt es seit 1.43.0

MaWin schrieb:
> mh schrieb:
>> Das ist nicht das was ich gefragt habe ...
>
> Und was hast du gefragt?
Stand doch in dem Beitrag den du zitiert hast.
mh schrieb:
> Wenn ich vergleichen will, muss ich
> hin und her wechseln?
Du hast auf die nicht gestellte Frage "Möchte ich die verschiedenen 
vergleichen" geantwortet.

MaWin schrieb:
>> Ich konnte in der Doku keine Versionstags finden
>
> Aha.
> Dann solltest du vielleicht einmal genauer gucken.
> Beispiel:
> https://doc.rust-lang.org/std/primitive.u32.html#associatedconstant.MIN
>
> MIN gibt es seit 1.43.0
Ok in die Doku des std-cargos habe ich nicht geguckt. Interessiert mich 
auch eher weniger, mir geht es um die Sprache.

mh schrieb:
> Du hast auf die nicht gestellte Frage "Möchte ich die verschiedenen
> vergleichen" geantwortet.

Vielleicht sind die Changelogs da eher sinnvoll?

Und warum willst du das überhaupt machen? Nutze halt die neuste 
stable-Version.

MaWin schrieb:
> mh schrieb:
>> Du hast auf die nicht gestellte Frage "Möchte ich die verschiedenen
>> vergleichen" geantwortet.
>
> Vielleicht sind die Changelogs da eher sinnvoll?
>
> Und warum willst du das überhaupt machen? Nutze halt die neuste
> stable-Version.

er sucht eben was vergleichbares wie

https://en.cppreference.com/w/cpp/language/static_assert

wo man schön sehen kann welches Sprach-Feature wann aufgetaucht ist

cppbert schrieb:
> er sucht eben was vergleichbares wie
>
> https://en.cppreference.com/w/cpp/language/static_assert
>
> wo man schön sehen kann welches Sprach-Feature wann aufgetaucht ist

Ja gut. Das ist ja genau das, was ich gezeigt habe.
In der std-Doku sind auch alle core-Elemente der Sprache enthalten.

Das einzige, was dort in der Regel nicht steht, ist wenn neue abstrakte 
Konzepte eingeführt werden, die keinen direkten core-support brauchen. 
Wie z.B. const-generics.

MaWin schrieb:
> Rust verhindert keine Speicherleaks.

Du kannst welche provozieren wenn du sie unbedingt für deine 
Systemprogrammierung brauchst aber der normale Entwickler bekommt das
Erstmal nicht hin, Rust verhindert alle Fehler die der ASAN findet, aber 
man kann Leaks erzeugen die der LSAN findet, nur eben nicht aus versehen

Aber trotzdem kannst du nicht mit einem geleaktem Speicher arbeiten

Phasenschieber schrieb:
> Aber hey, dafür haben wir keine
> Speicherleaks mehr. Wie war das? Haben wir in C++ dank
> RAII auch nie gehabt? Hmm. Aber die Datensicherheit und
> das Owner Konzept! Oh, gibts in C++ auch. Hmm.

D.h. die Aussage von google, Microsoft, Amazon, Facebook usw. darüber 
das sie den grossteil der Sicherheitsprobleme in der 
Systemprogrammierung nicht unter Kontrolle bekommen ist nur 
Hilflosigkeit weil deren Entwickler alle so schlecht sind? Speziell 
Google als Erfinder von ASAN etc. Würde ich da eindeutig mehr 
Verständnis zusprechen, Systemprogrammierung ist was anderes, 
Nutzeranzahl von Mio bis Mrd ist was anderes, ständige Angriffe sind was 
anderes - ich glaube vielen fehlen hier einfach die Dimensionen mit was 
solche Firmen zu kämpfen haben

Der Satz der mir hier von jedem braucht-man-nicht-Kritiker immer fehlt 
ist:
"Wenn ich bei google, Amazon und Microsoft das Zepter für die Android, 
AWS und Azure Entwicklung in den Händen hätte würden meine >10.0000 
Entwickler dank fortschrittlicher C++ Entwicklung solche Fehler einfach 
nicht mehr machen, mein Business würde ohne Sicherheits-, Ressourcen und 
Wartungsprobleme laufen - meine 10-800 Mio Kunden wären immer Zufrieden"

Bei der Menge an Kunden, Systemen ist jede Verbesserung in Sicherheit 
und Wartung nur im einstelligen Prozentbereich schon direkt ordentlich 
Geld wert

Olaf schrieb:
> Daher gibt es ein Interesse daran die Leute soviel wie moeglich zu
> gaengeln.
> Diese Sprachen kommen ja nicht mehr aus dem Interesse der Programmierer
> ein Problem zu loesen, sondern aus dem Interesse einer Firma das ihre
> Probleme
> so preiswert wie moeglich geloest werden.

auch wenn der Satz natürlich so absolut richtig ist schwingt aber immer 
so ein Hauch von nur-schlechte-Entwickler machen schlechten/fehlerhaften 
Code mit...

Die Probleme bei den Grossen sind real und in jahren harter Arbeit 
konnte man diese nicht signifikant Richtung 0 bringen, Rust versucht, 
und scheint es als Sprache auch erstmals in der Systemprogrammierung zu 
schaffen eine deutlichere Verbesserung out-of-the-box zu ermöglichen, 
ganz unabhängig von logischen Fehlern

Versucht doch einfach mal ein erstes Projekt mit Rust umzusetzen.
Damit meine ich jetzt ein Hallo World, sondern ein größeres Projekt, was 
tatsächlich was tut.

Ihr werdet ganz schnell furchtbar frustriert sein, weil Rust euch 
ständig mit Compilerfehlern bewirft. Das ist die erste Erkenntnis, die 
ihr haben werdet. Rust ist nur wenig geeignet, um mal schnell etwas 
hinzufrickeln. Man muss sich Gedanken machen über das, was man schreibt. 
Macht man es nicht, wird man umgehend vom Compiler dafür bestraft.

Wenn man diese Phase überstanden hat, kommt allerdings die zweite Phase, 
in der man die Vorteile dieses Vorgehens erkennt. Es gibt den Spruch: If 
it compiles, then it works. Das ist natürlich nicht wörtlich zu nehmen. 
Selbstverständlich kann man in Rust auch algorithmische Fehler machen. 
Aber eine ganze Menge an Fehlern, die man in anderen Sprachen wie C oder 
gar Python erst zur Laufzeit erkennt (wenn man Glück hat), quittiert der 
Rustcompiler einem mit einem Fehler.

Insofern hat man eine ganze Menge der Debuggingarbeit in die Phase der 
Programmierung verschoben.
Und das ist eine gute Sache.

Welcher MaWin schreibt hier? Ich bin beeindruckt 8)

Daniel A. schrieb:
> MaWin schrieb:
>> Man muss sich Gedanken machen über das, was man schreibt.
>> Macht man es nicht, wird man umgehend vom Compiler dafür bestraft.
>
> Gedanken darüber, was man schreibt, oder Gedanken darüber, wie man es in
> Rust schreibt?

Beides natürlich. Wie in jeder Sprache.

> Ich kann genau wissen, wie ich etwas idealerweise umsetzen würde, welche
> Datenstruktur und Algorithmen ich verwenden will. In C, Python, Java,
> GO, etc., selbst in anderen Imperativen und/oder OOP sprachen die ich
> eigentlich noch gar nicht kenne kann ich das dann einfach so hin
> schreiben. Aber nicht in Rust, gewisse Sachen muss man da einfach anders
> machen, und zwar nicht, weil es falsch oder besser wäre (von Aussen
> betrachtet), sondern einfach nur, weil es so nicht geht. Aber natürlich
> ist die Datenstruktur und der Algorithmus dann völlig verrückt, macht
> man einfach so nicht, oder?

In C kann man vieles implementieren, indem man wild mit Pointern um sich 
wirft. Und es resultiert regelmäßig in use-after-free oder ähnlichen 
Bugs.
Man sollte sich in allen Sprachen Gedanken darüber machen, wie man einen 
Algorithmus möglichst safe implementiert.
Rust zwingt den Entwickler dazu. C nicht.

Das bedeutet zwangsläufig, dass man in Safe-Rust nicht alles machen 
kann, was in C geht. Und das ist natürlich auch so gewollt.

Für die Fälle, die in Safe-Rust nicht direkt oder nur ineffizient lösbar 
sind, gibt es Abstraktionen in der std library, die dann intern 
Unsafe-Rust nutzen.

> Mittlerweile gibt es LinkedLists zum Glück aber in der Standard Library.
> Wurde auch sehr elegant gelöst. Jede Funktion nutzt einfach "unsafe".
> (Das ist aber auch die einzig vernünftige Lösung.)
> https://doc.rust-lang.org/src/alloc/collections/linked_list.rs.html

Na dann ist doch alles gut, wenn die std library das Problem für dich 
gelöst hat, sodass du in deinem Code alles als safe-Rust schreiben 
kannst.

Man kann eine linked-list selbstverständlich auch ohne die std linked 
list in safe rust schreiben. Man nehme Rc, RefCell und Box. Wie das 
genau geht, kannst du im offiziellen Rust-Buch nachlesen.
Aber da das nicht ganz so effizient ist, wie eine dedizierte 
linked-list, gibt es eben die optimierte std-liste.

Daniel A. schrieb:
> Als Beispiel, führe ich einfach mal die völlig verrückte Datenstruktur
> einer linked list an.

es ist sehr schwer die Offenheit von C/C++ oder gar Assembler in 
sichere(re) Konstrukte zu überführen - aber mal ehrlich, wer von uns 
schreibt denn ständig effiziente Link-Lists oder Graphen-Strukturen - 
machen tun wir das schon hin und wieder aber das als Messlatte heran zu 
ziehen ist doch nicht wirklich intelligent, oder denkst du das wirklich? 
Hast du gar das Gefühl den Entwicklern wäre das nicht ab der 1. Idee zum 
Ownershipping klar gewesen?  das wurde so bewusst in kauf genommen

nur bei Selbst-Referenzen und Offenen-Referenzen hat Rust - bisher noch 
:) -Probleme das "elegant" zu lösen - dafür die ganze Sicherheit die 
geboten wird komplett über Bord zu werfen würde ich als fraglich 
bezeichnen

Die Spiel heisst nicht Nur-Vorteile-sonst-ebene-wieder-die-alte-Sprache

Daniel A. schrieb:
> Als Beispiel, führe ich einfach mal die völlig verrückte Datenstruktur
> einer linked list an. Ja, ich weiss, total verrückt, sowas zu benutzen,
> so ineffizient, so kompliziert, wer der noch bei Verstand ist würde denn
> sowas machen?

niemand auf der Welt, mit Erfahrung denkt das, jede Verwaltungsform hat 
ihre Vor- und Nachteile

Wie kommst du darauf das die Rust-Entwickler so was einfach 
vernachlässigen - sie haben sich eben so entschieden so das der 90% Fall 
sicher ist

Falls du eine gute Idee hast wie man das fehlende Konzept für 
Link-Listen "sauber" in ein Ownership-Model bekommt - ohne das daraus 
ein GC wird - oder kein Ownership-Model existiert kannst du gerne 
Vorsprechen, dir sei Ruhm und Ehre gewiss :)

MaWin schrieb:
> Man sollte sich in allen Sprachen Gedanken darüber machen, wie man einen
> Algorithmus möglichst safe implementiert.
> Rust zwingt den Entwickler dazu. C nicht.

Blödsinn.

Das ist C:
- Trust the programmer
- Don’t prevent the programmer from doing what needs to be done

Für Rust sind die Entwickler anscheinend alle doof und man muss denen 
bestimmte Werkzeuge wegnehmen und ihnen regelmäßig auf die Finger hauen. 
Eine tolle Einstellung. Nach dieser Logik sollte man in einer Werkstatt 
alle Wekrzeuge durch Wattebällchen ersetzen. Damit da nichts passiert. 
Die schöne neue Zeit.

Yalu X. schrieb:
> beste Kompromiss,
> den es derzeit gibt.

Aha, also wieder nur ein Kompromiss und nur für "derzeit".

In ein paar Jahren brauchen wir dann eine neue Programmiersprache, die 
wieder alles besser macht?

Und gerade bei systemnaher Programmierung? Hat dann Linux-Kernel 30 
Million LOC geschrieben in C, 5 Million LOC in Rust, 5 Millionen LOC in 
XYZ, usw.?

von snowflakes - für snowflakes schrieb:
> …

><((((*>

von snowflakes - für snowflakes schrieb:
> Für Rust sind die Entwickler anscheinend alle doof und man muss denen
> bestimmte Werkzeuge wegnehmen und ihnen regelmäßig auf die Finger hauen.
> Eine tolle Einstellung.

Was ist das Problem an der Einstellung wenn dabei automatisch sicherere 
Programme entstehen

Und die Grossen der Branche wechseln von ihreren eigenen Strategie in 
der Systemprogrammierung auch nur zu Rust weil denen so langweilig ist 
und nur die schlechten Entwickler dort arbeiten?

Kann einer von euch hat mal schlüssig erklärt warum so viele der grossen 
Rust als die Lösung ihrer Lowlevel Probleme sehen und nur von euch 
keiner? Google entwickelt den ASAN der mittlerweile Standart ist, 
riesige Fuzzyfarmen und und und und sagen trotzdem das reicht nicht, ihr 
aber schon

Ich finde Rust nicht interessant weil ich in den letzten 30 Jahren so 
unter C/C++ gelitten habe, dafür habe ich viel zu viel Code für allerlei 
Kunden und Projekte entwickelt, aber ich sehe viele Kernprobleme 
behandelt, als jüngling oder zu alter Entwickler verstehe ich eine 
gewissen Zurückhaltung, aber viele der Argumente hier gegen Rust sind so 
schwach das es schon auffällig ist, was ich schade finde weil C/C++ 
keiner Verteidigung bedarf, es wird ewiglich überdauern

von snowflakes - für snowflakes schrieb:
> Und gerade bei systemnaher Programmierung? Hat dann Linux-Kernel 30
> Million LOC geschrieben in C, 5 Million LOC in Rust, 5 Millionen LOC in
> XYZ, usw.?

wenn die Kernelentwickler Rust in den Kernel einziehen lassen würde, 
trotz all der Mängel, was würde das über die Kernelentwickler und ihre 
Fähigkeiten und bisherigen Code aussagen?

Wieder so ein schwaches Argument weil das Szenario mit XYZ eh niemals 
eintreten wird, warum sowas überhaupt posten?

von snowflakes - für snowflakes schrieb:
> Aha, also wieder nur ein Kompromiss und nur für "derzeit".
>
> In ein paar Jahren brauchen wir dann eine neue Programmiersprache, die
> wieder alles besser macht?

Es nennt sich Weiterentwicklung.

> Und gerade bei systemnaher Programmierung? Hat dann Linux-Kernel 30
> Million LOC geschrieben in C, 5 Million LOC in Rust, 5 Millionen LOC in
> XYZ, usw.?

Wo wäre das Problem?
Du tust gerade so, als stünden wir vor der Inflation der 
Programmiersprachen.

von snowflakes - für snowflakes schrieb:
> Das ist C:
> - Trust the programmer
> - Don’t prevent the programmer from doing what needs to be done

Du hast noch was vergessen:

- Don't prevent the programmer from doing absolutely dumb things that 
would never work.
- Don't prevent the programmer from writing unsound code.
- Don't prevent the programmer from introducing subtle and hard to debug 
race conditions.
- Don't prevent the programmer from corrupting the memory.

Rolf M. schrieb:
> Rust wäre,
> wenn das Auto dir das Lenkrad blockiert, wenn du versuchst, auf die
> linke Spur zu fahren.

... und wenn du doch unbedingt auf der falschen Spur fahren willst, 
kannst du das mit unsafe eindeutig kennzeichnen.

Rolf M. schrieb:
> Das klingt aber eher nach C - du hast es unter Kontrolle und hältst dich
> an die Regel, weil sie sinnvoll ist. Dennoch kannst du z.B. zum
> Überholen oder zum Ausweichen auch mal nach links fahren. Rust wäre,
> wenn das Auto dir das Lenkrad blockiert, wenn du versuchst, auf die
> linke Spur zu fahren.

Sind eingreifende Sicherungssysteme moderner Flugzeuge wie die 
Flight-Envelope-Protection ein Fort- oder Rückschritt? (dort gibt es so 
Rust-mäßig "unsafe"-Modi)

Jemand schrieb:
> Sind eingreifende Sicherungssysteme moderner Flugzeuge wie die
> Flight-Envelope-Protection ein Fort- oder Rückschritt? (dort gibt es so
> Rust-mäßig "unsafe"-Modi)

Ich halte die Auto- und Flugzeugvergleiche hier für völlig daneben.
Die wichtigsten und meisten Rust-Merkmale sind Compiletime-Checks.

Das wäre in etwa so, als würdest du vor dem Start beweisen, dass es im 
folgenden Flug nicht zu sicherheitskritischen Manövern kommen kann. Das 
ist natürlich bei Flugzeugen unmöglich und deshalb ist der Vergleich 
Unsinn.

https://security.googleblog.com/2021/04/rust-in-linux-kernel.html

Daniel A. schrieb:
> Zeit halt schon etwas, das ständige Hantieren mit Rc, RefCell, Box, etc.
> bis es geht. Da frage ich mich einfach, hätte man das wirklich nicht
> einfacher/besser lösen können?

Naja. Rc ist bereits ein Smart Pointer und damit praktisch transparent. 
Nur halt nicht bei der Deklaration.

Man kann jetzt natürlich diverse Typen in einem eigenen neuen Typ 
kombinieren. Aber ich sehe da den Vorteil jetzt nicht wirklich. Das 
skaliert nicht so richtig.

Daniel A. schrieb:
> Da frage ich mich einfach, hätte man das wirklich nicht einfacher/besser
> lösen können?

Nicht wirklich, das Ownership Model ist ja auch keine neue Idee, nur die 
Art der Integration in Rust

Für Linklisten oder Graphen braucht man ein Nullable Konzept, das gibt 
es schon sehr langen in x Sprachen, aber es ist schwierig bis unmöglich 
das zur Kompilezeit sauber zu lösen/prüfen (eher ein mathematisches 
Problem), die functionalen Sprachen machen das sauber aber die sind 
leider nicht so praktisch

Wenn du dir als Rust die Einschränkungen: Kompilezeitchecks und 
Lückenlosigkeit auferlegst wird es sehr schwierig aber sie haben eine 
gute mitte zwischen mathematischer Beweisbarkeit und noch praktischer 
Anwendbarkeit geschaffen, vielleicht schaffen sie auch noch diese Hürde

MaWin schrieb:
> https://security.googleblog.com/2021/04/rust-in-linux-kernel.html

Ganz unten auf der Seite
...
 Thanks Nick Desaulniers, Kees Cook, and Adrian Taylor for contributions 
to this post. Special thanks to Jeff Vander Stoep for contributions and 
editing, and to Greg Kroah-Hartman for reviewing and contributing to the 
code examples.
...

Greg Kroah-Hartman hat sich also auch schon ein wenig intensiver damit 
beschäftig, wer ihn nicht kennt: das ist der 2. Man nach Linus Torvalds 
in der Kernelentwickler Befehlskette

Facebook ist jetzt auch in der Rust Foundation

https://engineering.fb.com/2021/04/29/developer-tools/rust/

Laut dem Artikel arbeiten bei Facebook bis zu 100 Entwickler mit Rust

Und nein, ich habe kein Facebook Account, Facebook als Firma ist aber 
trotzdem, technisch gesehen eine extreme Datenverarbeutungsmaschinerie 
mit sehr viel C++ und auch scheinbar nicht unbedeutende Menge an Rust 
dahinter, die wenigsten Leute bei denen machen HTML, js und PHP, die 
Zeiten sind schon lange vorbei

Vom neuen Facebook Rust Mitglied ;)

"...And, seriously, if the Linux kernel is actually starting to even 
consider Rust as a language to be used for that codebase, well, that’s 
when you know you have made it. ..."

cppbert3 schrieb:
> "...And, seriously, if the Linux kernel is actually starting to even
> consider Rust as a language to be used for that codebase, well, that’s
> when you know you have made it. ..."

Da ist was dran.
C++ ist an dieser Hürde mehrfach gescheitert.

Gut, das ist nicht ganz vergleichbar, weil es dort darum ging den 
gesamten C-Code mit einem C++ Compiler zu übersetzen.

Dennoch sind die Linux-Entwickler nicht bekannt dafür auf Hypetrains 
aufzuspringen. Das ist die Grundlage für die Aussage.

Meine Meinung zu Rust ist, dass die Entwickler von Rust anscheinend noch 
nie für Linux ein Paket gebaut haben.

Es ist lächerlich, dass man erst nach langer Zeit mit Cargo offline 
bauen konnte. Und auch sehr lächerlich, dass es weiterhin alle Pakete in 
ein Offline-Repo zieht.

Wenn man ein Paket für eine Linuxdistribution baut, will man in der 
Regel nur Pakete aus den eigenen Repos benutzen. Z.B. weil man sie auf 
Sicherheit geprüft hat. Crate.io traue ich nicht. Man hat ja bereits 
beim npm-Angriff gesehen, dass diese Spracheneigenen Repositories 
anfälliger für eine Supply-Chain-Attacke sind. Es sind bei solchen 
Projekten dem Anschein nach eher Sprach-Fanatiker dabei, die sich mehr 
um die "Coolness" ihrer Programmiersprache als um 
Supply-Chain-Sicherheit kümmern...

Ein weiterer Punkt ist die massive Rekursionstiefe beim Bauen vom Rust 
Compiler package rustc: Entweder man schreibt einmal alles in einem 
Sublayer, quasi einen elementaren Baukasten von Rust-Befehlen, mit denen 
man dann einfach-rekursiv den Standard-namespace schreibt, oder man 
lässt es bleiben.

Rust wirkt sprachlich, wie von hellen Köpfen entwickelt, aber die 
Kompiler-Entwickler scheinen noch nie von Idempotenz und Performance 
gehört zu haben, jedenfalls im Bezug auf das Compilerprojekt selbst.

Almdahl schrieb:
> Supply-Chain-Attacke

Wie soll das denn vonstattengehen, wenn das Distributionspaket die 
Dependency-Versionen pinnt (locked)?

Almdahl schrieb:
> Ein weiterer Punkt ist die massive Rekursionstiefe beim Bauen vom Rust
> Compiler package rustc

Tut mir leid. Das verstehe ich nicht.
Kannst du das Problem vielleicht auch in verständlich erklären?

Almdahl schrieb:
> Es ist lächerlich, dass man erst nach langer Zeit mit Cargo offline
> bauen konnte. Und auch sehr lächerlich, dass es weiterhin alle Pakete in
> ein Offline-Repo zieht.

Es ist also lächerlich, dass die Pakete online sind und gleichzeitig ist 
es lächerlich, dass die Pakete offline gecached werden?
Verstehe ich deine Kritik richtig?

Wie hättest du es denn gerne?

MaWin schrieb:
> Almdahl schrieb:
>> Supply-Chain-Attacke
> Wie soll das denn vonstattengehen, wenn das Distributionspaket die
> Dependency-Versionen pinnt (locked)?
Ich meine nicht, dass es eine Supply-Chain-Attacke auf die Distribution 
geben kann, sondern eine in der programmierspracheneigenen 
Paketverwaltung. Ist meine Persönliche Meinung, aber ich finde es 
nervig, dass für Sprachen wie Rust, Python, Ruby usw. das Rad immer 
wieder neu erfunden wurde.

Dass man die Crates auch mit Cargo laden kann, ist trotzdem nicht das 
eigentliche Problem. Man hat nur das Gefühl, dass alles darauf ausgelegt 
ist, dass man die Rust-Art benutzt, Dinge zu kompilieren und dass es 
beim Paketbau für Distributionen unangenehm wird.

> Almdahl schrieb:
>> Ein weiterer Punkt ist die massive Rekursionstiefe beim Bauen vom Rust
>> Compiler package rustc
>
> Tut mir leid. Das verstehe ich nicht.
> Kannst du das Problem vielleicht auch in verständlich erklären?
Das Problem ist, dass jede neue rustc-Version davon ausgeht, dass der in 
der vorhergehenden stabilen rustc-Version definierte Namensraum zur 
Verfügung steht. Das bedeutet, man braucht immer die vorherige Version, 
um die nächste zu kompilieren. Wenn man ein Paket baut und beweisen 
möchte, dass der Binärcode dem Quelltext entspricht, muss man in jedem 
Update von vorne wieder jede einzelne Version von rustc bauen, oder zu 
jeder Zeit alle Versionen von rustc bereit halten (um den rekursiven 
Beweis aufrecht zu erhalten) die zum Bau von aktualisierten 
rustc-Paketen benötigt werden. Das finde ich technisch richtig dumm 
umgesetzt. Das macht auch die Programme zum Bereitstellen der 
Repositories komplexer als nötig.

Ein paar Leute haben das mittlerweile entschärft, indem sie einen 
alternativen Compiler in C++ geschrieben haben (mrustc), der einige 
Schritte vereint. Trotzdem ist die Kompilierung bis zur aktuellsten 
Version mit einem immensen Ressourcen- und Zeitaufwand verbunden. Das 
ist Mist. Man sollte sich auf sehr wenige Stufen einigen, auf denen dann 
die neuen Versionen basieren.

> Almdahl schrieb:
> Es ist also lächerlich, dass die Pakete online sind und gleichzeitig ist
> es lächerlich, dass die Pakete offline gecached werden?
> Wie hättest du es denn gerne?

Sorry für die missverständliche Ausdrucksweise - Ich hatte selbst etwas 
falsch in Erinnerung. Was ich kritisieren möchte ist die Möglichkeit, 
z.B. Patches von Github on the Fly beim Kompilieren über das Cargo.toml 
File zu laden und bei Dependencies auf git Links zu verweisen.
Natürlich kann man sagen, dass man das nicht nutzen muss, aber ich 
finde, dass man manche Möglichkeiten auch nicht bieten muss. Denn zum 
Bau des Paketes hat man somit implizit doch wieder online Dependencies, 
wodurch der --offline-Modus nicht geht. Man muss als Paketbauer also 
zuerst alles manuell laden und das Cargo.toml patchen, damit man es 
offline bauen kann. Hätte der Programmierer die Möglichkeit nicht, hätte 
er die Sache auch "anständig" gelöst.

Ganz ehrlich: Ich wollte gerne ein cooles Rust-Paket für eine 
Distribution bauen, aber der letztgenannte Punkt verdirbt einem dann 
einfach den Spaß und man wünscht sich ein gutes altes Makefile. 
Insgesamt bin ich dem Bau von Rust-Paketen mittlerweile eher abgeneigt.

Und ein letzter Punkt: Wenn ich eine Programmiersprache benutze, will 
ich, dass sie sehr lange stabil ist. C99 war nicht umsonst sehr 
erfolgreich. Man konnte sich einfach darauf verlassen. Ich hoffe sehr, 
dass es auch mal einen Rust-Standard gibt, der 15-20 Jahre durchhält.

Almdahl schrieb:
> oder zu jeder Zeit alle Versionen von rustc bereit halten

Was ja kein Problem darstellen sollte.

> Ein paar Leute haben das mittlerweile entschärft, indem sie einen
> alternativen Compiler in C++ geschrieben haben (mrustc)

Na siehste. Das Problem ist also praktisch gelöst.
Rust für GCC wird es auch bald geben. Vermutlich nächstes Jahr.

> Natürlich kann man sagen, dass man das nicht nutzen muss

Genau.
Deshalb ist es auch kein Problem.

> Und ein letzter Punkt: Wenn ich eine Programmiersprache benutze, will
> ich, dass sie sehr lange stabil ist.

Das ist meiner Erfahrung nach bei Rust auch so.
Deine Schilderungen zu BLFS und FF kann ich nicht kommentieren, da ich 
das nicht ausprobiert habe und die Hindergründe nicht kenne.
In meiner Erfahrung gab es aber noch nie ein Paket, dass nach einem 
Compilerupdate nicht mehr funktioniert hätte. Und ich denke da bin ich 
nicht alleine mit.

MaWin schrieb:
> Almdahl schrieb:
>> oder zu jeder Zeit alle Versionen von rustc bereit halten
>
> Was ja kein Problem darstellen sollte.
Für ein mickriges Paket ist der Ressourcenverbrauch extrem.

>> Ein paar Leute haben das mittlerweile entschärft, indem sie einen
>> alternativen Compiler in C++ geschrieben haben (mrustc)
>
> Na siehste. Das Problem ist also praktisch gelöst.
Nicht wirklich...
> Rust für GCC wird es auch bald geben. Vermutlich nächstes Jahr.
Dann wäre es eventuell tatsächlich gelöst. Aber bis das stabil ist, 
werden ja sicherlich auch wieder Jahre ins Land gehen... Schade, dass es 
nicht früher umgesetzt wurde.

>> Natürlich kann man sagen, dass man das nicht nutzen muss
>
> Genau.
> Deshalb ist es auch kein Problem.
Ich finde es schon problematisch, wenn viele unwissend Code schreiben, 
der auf Github vergammelt, weil keiner ihn packagen will. Und das wird 
durch die Möglichkeiten, die Cargo bietet, eben zum Teil gefördert.

Almdahl schrieb:
> Für ein mickriges Paket ist der Ressourcenverbrauch extrem.

Im Zeitalter von Terabytefestplatten?
Zudem man das ja nicht für jedes Paket machen muss, sondern maximal ein 
mal pro Distribution.

Ich glaube du konstruierst dir da wirklich zwanghaft deine Probleme.

> Schade, dass es nicht früher umgesetzt wurde.

Rust ist nach wie vor eine sehr junge Sprache, die sich rasant 
weiterentwickelt und dabei produktiv einsetzbar und rückwärtskompatibel 
bleibt.

Rust is here to stay.
Egal wie viel so mancher sich dagegen sträubt.
Wenn es Probleme beim Distri-Packaging mit Rust gibt, dann ist es die 
Aufgabe der Distris das zu lösen. Wenn sie es nicht lösen, dann werden 
sie abgehängt werden. Die Rustwelle rollt auch ohne die Hilfe von 
Linux-Distributionen.

> wenn viele unwissend

Ja, es ist problematisch, wenn Leute keine Ahnung von dem haben, was sie 
tun.
Mit Rust hat das allerdings nichts zu tun.

S. R. schrieb:
> Wenn die Kompatiblität tatsächlich gebrochen werden sollte,
> dann kann das in einer Python 2.x/3.x-Situation münden.

Warum glaubst du, dass das auch tatsächlich passieren kann?
Mit den Editions hat man einen wirksamen Mechanismus, um auch größere 
Umbauten vollständig rückwärtskompatibel durchzuführen.

Python hingegen hat keinen solchen Mechanismus. Genau deshalb ist Python 
viel schlechter aufgestellt, was die Rückwärtskompatibilität angeht. Und 
das endet dann in Sachen wie der 2/3-Transition, aber auch in konstant 
eingeführten kleinen Inkompatibilitäten in so gut wie jeder neuen 
Version.

> denn Linus wird ganz sicher
> keine Abhängigkeit zu Web-Services oder Paketmanagern reinbringen.

Ist auch gar nicht notwendig. Wie hier schon mehrfach erklärt wurde.
Alle nötigen dependencies können lokal vorgehalten werden. Mit und ohne 
cargo.

> Die Sprache mag ja gut sein, der Lernaufwand ist verglichen
> mit anderen modernen Sprachen aber enorm

Verglichen mit welchen Spachen?

> und das Tooling je nach Sichtweise entweder eine Katastrophe

Warum? Gerade weil die Rust Toolchain alles mitbringt, was man eh 
braucht, ist es extrem einfach zu verwenden.

Ich fasse es mal ehrlich zusammen:

Wenn Rust22 gäbe, und dies mit GCC mit kompetitiver Performance 
kompilierbar wäre, würde ich nicht nur C, sondern auch viel Python, 
damit sofort ersetzen. Einfach, weil Rust das Zeug dazu hat, dies aus 
Sprachperspektive und Library-Support zu leisten.

Solange die gravierenden Kritikpunkte (aus meiner Sicht) bleiben, 
betrachte ich Rust weiter wehmütig, als Sprache, die ich gern einsetzen 
würde, aber es aus Vernunftgründen noch nicht kann.

Und zu Containern habe ich eine etwas kontroverse Meinung :).

Was sind Eure Rust Anwendungen und Targets?

Redet man hier hauptsächlich von Embedded oder PCs und Co.?

Im embedded Bereich gibt es da schon fertige Tools für bestimmte uC und 
wie verläßlich sind diese Tools?

Wie leicht ist Umportierung von C/C++ auf Rust und wie leicht kommt man 
mit Rust an die uC HW ran? Wie steht es mit äquivalenten Bibliotheken? 
Wie geht das Debugging von embedded Projekte am Besten mit Rust?

Wie schwierig ist die Konfigurierung im Vergleich zu altbekannten 
Werkzeugen?

Wie schwer tut man sich wenn z.B. der Chef man möchte doch z.B. von 
STM32 oder PIC/AVR auf ein Rust Entwicklungssystem umzusteigen? Wird 
PIC/AVR unterstützt?

Gibt es Case Studies wie man ein existierendes erfolgreiches embedded 
Projekt (STM32/AVR/PIC) von C/C++ auf Rust umsetzt und erfolgreich baut 
und betreibt?

Wie lange braucht ein typischer embedded C/C++ Entwickler Rust so weit 
zu erlernen um wieder produktiv zu werden?

Ich weiß nicht ob meine Fragen den Kernpunkt von Rust treffen, aber mir 
fällt es schwer eine befriedigende Perspektive ins Gesichtfeld zu 
bekommen. Bis jetzt fand ich die Rust Webinformationen doch nicht so 
hilfreich.

Hinterherhinkender schrieb:
> embedded

Ich denke alle deine Fragen kann man so beantworten:

Theoretisch hat Rust das Zeug richtig gut im Embedded-Bereich zu werden.
Praktisch ist es dort heute aber noch nicht wirklich einsetzbar.

Es sei denn ein Gerät der Raspberry-Pi-Klasse gilt als Embedded. Dort 
ist Rust gut einsetzbar.
Aber so etwas wie AVR funktioniert zwar prinzipiell, ist aber noch sehr 
weit von der Serienreife entfernt.

W.Gates schrieb:
> Was der Bauer nicht kennt frisst er nicht.

Ein Programm was ewig funktioniert ist selten. Frage ist, wieviele 
Helfer man für Rust im Ernstfall findet und das auch noch in xx Jahren. 
Zumindest gibt es glücklicherweise schon einige englische Bücher dafür. 
https://www.oreilly.com/library/view/programming-rust/9781491927274/

> Ist auch gar nicht notwendig. Wie hier schon mehrfach erklärt wurde.
> Alle nötigen dependencies können lokal vorgehalten werden. Mit und ohne
> cargo.

Man kann viel, man muss es nur machen. Vermutlich dann irgendwie 
kompliziert und man ist ja vergesslich und der Mittelwert der Leute ist 
erschreckend faul. Und nach jedem Update bestimmt wieder neu einstellen. 
Also irgendwie...

Lies mal hier ueber das Grauen schlechthin:

https://www.heise.de/meinung/Kommentar-zu-log4j-Es-funktioniert-wie-spezifiziert-6294476.html

Wenn sich solche absurden Buildkonzepte wie mit cargo verbreiten endet 
das in 10Jahre mit Rust genauso wie hier mit Java. Dabei sehe ich 
bereits heute regelmaessig Geraete wo ich dem Programmierer gerne links 
und rechts ein paar reinhauen wuerde. (erst gestern bei einem 
Sat-Reciever)

Olaf

Olaf schrieb:
> Vermutlich

Weniger vermuten, mehr lernen.
Dependency-crates lokal zu halten ist genau so trivial wie sie von 
crates.io zu beziehen. Wenn es mit Cargo sein soll, dann gibt man den 
path zu dem crate an. Fertig. Das war es.

Alle Referenzen dazu wurden hier im Thread mehrfach genannt.

> Wenn sich solche absurden Buildkonzepte wie mit cargo verbreiten endet
> das in 10Jahre mit Rust genauso wie hier mit Java

Was hat das Buildsystem mit diesem Bug zu tun?
Warum ist es absurd?
Was hat Java mit Rust zu tun?

> wo ich dem Programmierer gerne links
> und rechts ein paar reinhauen wuerde

Gegen Agressionen helfen Waldspaziergänge.

> Was hat das Buildsystem mit diesem Bug zu tun?

Die Tendenz alles immer mehr aufzublasen bis es keiner mehr durchschaut.

Olaf

Olaf schrieb:
>> Was hat das Buildsystem mit diesem Bug zu tun?
> Die Tendenz alles immer mehr aufzublasen bis es keiner mehr durchschaut.

Das Buildsystem führt zu komplexerem Programmcode?
Na wenn du meinst...

S. R. schrieb:
> Nein, der durch solche Buildsysteme entstehende Programmcode ist
> deutlich weniger komplex, sogar bis hin zu äußerst trivial. Der
> vollstände, das gesamte Projekt umfassende Programmcode ist hochgradig
> verteilt und schlecht bis überhaupt nicht mehr erfassbar.

Und es ist besser riesige Monolithen zu bauen, weil diese besser 
erfassbar sind?
Für mich ist das Gegenteil der Fall.

> Je einfacher es ist, sich zig Dependencies einzuwerfen, desto weniger
> wird über zusätzliche Dependencies nachgedacht.

Das ist kein Problem der Sprache oder des Buildsystems, sondern es ist 
ein Problem in deinem Entwicklungsprozess.

> Wir sollten uns darüber hinaus sogar einig sein, dass es Workarounds für
> alle nur vorstellbaren Probleme gibt - und dass sie weder weitreichend
> benutzt werden, noch benutzt werden sollen. Letzteres führt dann im
> Zweifelsfall dazu, dass Bugreports schlicht missverstanden oder mit "so
> macht man das nicht" geschlossen werden.

Diesen Absatz verstehe ich überhaupt nicht.
Was haben Bugreports und Workarounds jetzt plötzlich mit dem Buildsystem 
zu tun?