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


von cppbert3 (Gast)


Lesenswert?

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

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

von cppbert3 (Gast)


Lesenswert?

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

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

Beitrag #6565967 wurde vom Autor gelöscht.
von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

mh schrieb:
> Du hast offensichtlich keine Ahnung von modernem C++, wenn du nicht
> verstehst, warum new ein Indiz für unsicheren Code ist.

Ja aber nur wenn das

- delete fehlt
- oder Exception zwischendurch
- womöglich x hundert andere Pfade existieren wo etwas schief gehen kann
- das mein (seien wir ehrlich:) hinzugepfriemeltes Tool erst mal 
entdecken muss
- etc.

Code-Reflection ist eben nicht einfach, besonders wenn man die Regeln 
der grauen Eminenzen(Komitee)im Ökosystem einer organisch gewachsenen 
Programmiersprache beachten muss. (Völlig wertfrei gemeint ... ich bin 
in Boost verliebt)

Wie wäre es bloß, wenn man diesen steinigen Weg gar nicht gehen müsste 
und Speicherfehler vermeiden könnte, etwa durch ein Neu-Design? Was 
würde ich geben wenn es so etwas geben würde ... :)

1
unsafe
 ist natürlich immer noch böse.

Aber vergleichen wir einmal
https://github.com/google/sanitizers/issues?q=is%3Aissue+delete
mit https://debbugs.gnu.org/cgi/pkgreport.cgi?package=grep

Bei den grep issues nicht erschrecken lassen. Kein einziger Bug davon 
verhindert das grep -r unsafe * etwas anzuzeigen vergisst. Nur gabs 
gerade bei der Rekursion einen Memory-Leak. Sachen gibts;)
Das war jetzt aber eher mit einem zwinkernden Auge gemeint. Äpfel und 
Birnen.

xyz-sanitize ist eben KEIN Ersatz für Sprachdesign sondern die 
Putzkolonne, wenn die Sauerei schon dampft.


P.S.: Bild => völlig anderer Rost! -> 
https://dilbert.com/strip/2000-04-30

von cppbert (Gast)


Lesenswert?

Rust forciert:

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

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

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

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

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

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

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

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

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

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

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

ich hab beruflich mit fast allem Kontakt

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

4. Ein auf Rust basiertes Build-System

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

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

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

Nachteile:

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

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

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

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

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

5. und, und, und...

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

von cppbert (Gast)


Lesenswert?

Nachteil 6:

Um Rust ranken sich zu viele Mythen:

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

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

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

"Rust ist super-kompliziert"

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

Die Frage ist nur ob man die Vorteile nutzen will

"Rust ist zu streng/einschränkend"

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

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

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

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

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

von cppbert (Gast)


Lesenswert?

Nachteil 7:

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

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

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

Nachteil 8:

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

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

von Carl D. (jcw2)


Lesenswert?

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

von cppbert3 (Gast)


Lesenswert?

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

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

von cppbert3 (Gast)


Lesenswert?

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

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

von Cppbert3 (Gast)


Lesenswert?

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

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

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

Beitrag #6582066 wurde von einem Moderator gelöscht.
von mh (Gast)


Lesenswert?

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

von Vincent H. (vinci)


Lesenswert?

> Rust wandert ins System
> Eine wichtige Python-Bibliothek nutzt künftig teilweise Rust-Code. Bald wird
> es möglicherweise schwer, Linux-Systeme ohne Rust zu betreiben.

https://www.golem.de/news/linux-rust-wandert-ins-system-2102-154041.html

/edit
Dieses Forum braucht a gscheite Quote Funktion... -.-

: Bearbeitet durch User
von cppbert3 (Gast)


Lesenswert?

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

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

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

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

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

von Operator S. (smkr)


Lesenswert?

Jetzt wurde Rust in eine eigene Foundation ausgelagert. Mal schauen was 
daraus wird und ob sich dadurch mehr Vetrauen aus der Industrie gewinnen 
lässt.

https://blog.mozilla.org/blog/2021/02/08/mozilla-welcomes-the-rust-foundation/

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Na, wollnwa mal hoffen, dass nicht eines Tages auch mal sowas oder 
vergleichbares bei rust/cargo passiert:

https://www.heise.de/news/Sicherheitsforscher-bricht-ueber-Open-Source-Repositories-bei-PayPal-Co-ein-5051635.html

SCNR,
WK

von MaWin (Gast)


Lesenswert?

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

Warum sollte es?

von Dergute W. (derguteweka)


Lesenswert?

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

Sollte die Frage nicht besser lauten: Warum sollte es nicht?

von cppbert3 (Gast)


Lesenswert?

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

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

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

von MaWin (Gast)


Lesenswert?

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

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

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

von Olaf (Gast)


Lesenswert?

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

Es gibt schon einen Zusammenhang.

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

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

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

Olaf

von Le X. (lex_91)


Lesenswert?

Olaf schrieb:
> Bei Android geht es beim ersten einschalten, aber du musst dreimal
> soviel Muehe reinstecken um zu verhindern das deine privaten Daten
> ueberrall in der Welt landen. Ueber die Folgen kannst du jeden Tag in
> der Zeitung lesen.

Was steht denn da genau über Android-Handys?

Wenn ich in meiner (digitalen) Zeitung lese dass irgendwo Daten (z.B. 
Passwörter im Klartext) abgegriffen wurden dann so gut wie immer bei 
Firmen bzw. aus der Cloud. Also aus Linux-Serversystemen, nicht von 
Android-Smartphones.

: Bearbeitet durch User
von Olaf (Gast)


Lesenswert?

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

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

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

Olaf

von S. R. (svenska)


Lesenswert?

Le X. schrieb:
> Also aus Linux-Serversystemen, nicht von
> Android-Smartphones.

Aus Android-Smartphones muss man ja auch nichts abgreifen. Die senden 
die Daten ja von ganz allein dahin... und es ist nahezu unmöglich, das 
zu verhindern.

von Le X. (lex_91)


Lesenswert?

S. R. schrieb:
> Le X. schrieb:
>> Also aus Linux-Serversystemen, nicht von
>> Android-Smartphones.
>
> Aus Android-Smartphones muss man ja auch nichts abgreifen. Die senden
> die Daten ja von ganz allein dahin... und es ist nahezu unmöglich, das
> zu verhindern.

Mich hätte eigentlich nur interessiert was das für ominöse Folgen sind 
von denen Olaf spricht und wo man darüber lesen kann.
Olaf schrieb:
> aber du musst dreimal
> soviel Muehe reinstecken um zu verhindern das deine privaten Daten
> ueberrall in der Welt landen. Ueber die Folgen kannst du jeden Tag in
> der Zeitung lesen.
Aber die Antwort blieb er schuldig, seinem letzten Beitrag kann ich 
nicht wirklich Verständliches entnehmen.

von mh (Gast)


Lesenswert?

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

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

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

von Operator S. (smkr)


Lesenswert?

mh schrieb:
> Achso MaWin, wie hilft in diesem Fall dein heiliger Gral semantic
> versioning?

Wo bitte wurde das behauptet?

von mh (Gast)


Lesenswert?

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

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

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

von MaWin (Gast)


Lesenswert?

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

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

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

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

von mh (Gast)


Lesenswert?

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

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

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

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

von MaWin (Gast)


Lesenswert?

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

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

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

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

von cppbert3 (Gast)


Lesenswert?

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

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

von Operator S. (smkr)


Lesenswert?

mh schrieb:
> Da müsstest du die Beiträge von vor einem Monat lesen

Hab ich, den Thread verfolge ich seit Beginn.

Ironischerweise, löst genau Semantic Versioning das beschrieben Problem 
von derguteweka (Warum auch immer das hier in einem Rust Thread gelandet 
ist...)

Wenn man nämlich nur schreibt Package Install MyFancyLib, dann holt er 
sich das Package mit der höchsten Version das er finden kann. Ein 
"Hacker" erstellt dann einfach auf der öffentlichen Paketsource ein 
MyFancyLib mit einer sehr hohen Version und Zack landet es in deinem 
System.

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

An dieser Stelle danke für deine kritische Sichtweise, sonst wäre es mir 
nicht bewusst geworden, dass Semantic Versioning tatsächlich genau 
dieses Problem löst.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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

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

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

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


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

von Operator S. (smkr)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Es ist aber nicht so, dass es keine Ideen gibt, um das Problem mit
> technischen mitteln zu lösen.

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

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

🐧 DPA 🐧 schrieb:
> Irgendwann will man die
> Dependencies ja auch updaten, auch um mögliche Sicherheitslücken in
> alten Versionen zu schlissen. Dann macht man "npm/pip/cargo update", und
> was glaubst du, was dann passiert? Genau, es tut was es soll, und
> aktualisiert die Versionen der Abhängigkeiten.

Genau und dieser Schritt macht man von Hand. Es ist eine bewusste 
Aktien, dass man was verändert hat. Wenn man dann einfach nimmt was 
einem hergeworfen wird, sollte man sich ein anderes Handwerk suchen. Und 
ich meine hier nicht den Fall, dass ein Paket von Version 1.2.3 auf 
Version 2.1.0 ein Update erhalten hat und man bis ins letzte Detail 
nachschauen muss, was ist anders geworden. Wenn aber aus Version 1.2.3 
das Update Version 22.0.0 macht, sollte man das nachprüfen.
In der oben verlinkten "Sicherheitslücke" geht es aber darum, dass im 
Buildsystem automatisch die neueste Version genommen wird, wenn keine 
Version spezifiziert wurde. Ohne dass man bewusst nach einem Update 
verlangt hat.

von MaWin (Gast)


Lesenswert?

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

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

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

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

Das ist und bleibt PEBCAK.

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

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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

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

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

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

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

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

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

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

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

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

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

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

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

von MaWin (Gast)


Lesenswert?

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

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

Höchstens so etwas:

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

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

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

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

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

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

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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

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

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

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

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

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

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

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

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

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

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

Nie upzudaten ist aber auch nicht unbedingt Sicherheitstechnisch ideal.

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

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

von MaWin (Gast)


Lesenswert?

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

Wer hat das behauptet?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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

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

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

von MaWin (Gast)


Lesenswert?

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

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

Und die dazu noch aus dem Zusammenhang gerissen sind.

Aber das machst du natürlich extra.

von MaWin (Gast)


Lesenswert?

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

Was willst du eigentlich?

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

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

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

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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

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

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

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

MaWin schrieb:
> Was willst du eigentlich?

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

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

Ja, das ist so.

von MaWin (Gast)


Lesenswert?

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

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

> Ja, das ist so.

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

Ok?

von cppbert (Gast)


Lesenswert?

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

für den Rest:

"Rust" ist keine Platform sondern die Programmiersprache

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

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

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

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

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

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

von mh (Gast)


Lesenswert?

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

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

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

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

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

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

von Operator S. (smkr)


Lesenswert?

@ mh, dann benutz es doch einfach nicht

von cppbert (Gast)


Lesenswert?

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

das sind zwei paar Stiefel

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

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

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

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

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

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

von MaWin (Gast)


Lesenswert?

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

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

Beitrag #6602631 wurde von einem Moderator gelöscht.
von cppbert3 (Gast)


Lesenswert?

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

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

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

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

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

von cppbert3 (Gast)


Lesenswert?

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

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

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

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

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


Lesenswert?

cppbert: Ich würde nicht soweit gehen, diese Idioten als Idioten zu 
bezeichnen(Spässle). Der Mensch ist unbeweglich. Besonders geistig. Ohne 
jemanden damit beleidigen zu wollen und natürlich ist das oberflächlich.

Was ich hier noch einmal betonen will ist, dass absolut kein Zwang 
besteht auf etwas Vernünftigeres und womöglich "Vesseres" zu wechseln.
Das ist eine Sache.
Aber die eigene Beratungsresistenz und Vorurteile unter den anderen 
Programmierern und Programmierer-Nachwuchs-Volk zu verteilen ist 
peinlich und kurzsichtig. Schade, dass man dies mit Scheuklappen nicht 
sehen kann.

Hab viel Geduld und Kraft, lieber cppbert3. Dieser sinnlose Streit über 
das richtige Werkzeug hört nämlich niemals auf.
Es ist wie mit dem Geschmack. Manche mögen ihren Käse erst so richtig 
mit viel viel Schimmel. Die Perversen haben sogar lateinische 
Kosenamen;)

Um zum Thema zurück zu kommen: Rust? Cool. Das bleibt. Alleine schon die 
163 Libs die mein Amateur-Kannst-Mich_Mal-Programm zum befragen meines 
Fernsehers (MIPS VU+ Box, Enigma2) braucht. Schrecklich! Und dann 
funktioniert das auch noch Lokal (x86) und Remote (mipsel). Okay so 
einfach war es auch nicht. Ich fühlte mich nicht sehr gut als ich den 
Pull Request für das MIPS OpenSSL in Rust hochgeladen habe. Habe aber 
bisher noch keine Morddrohungen oder einen Regressanspruch erhalten.

Cargo ist nicht Rust. Es ist nur in Rust geschrieben. Lasst uns doch mal 
gegen Conan schelten und deswegen C++ verdammen. Das ist nur gut, wenn 
man Beiden, den Conan und C++ Entwicklern auf die Nerven gehen will. 
Python libraries, Node-Chaos? ... Wer blickt da schon durch? Das ist 
aber ein völlig anderes Problem, nämlich der Versionsverwaltung und des 
Paketmanagements. Kein Alleinstellungsmerkmal von Rust UND Cargo!

Ach übrigens:
1
std::auto_ptr<MaWin> cppBert ...
Jeder macht mal Fehler. (Die Klassen- und Variablennamen des Beitrags 
sind frei erfunden. Etwaige Ähnlichkeiten mit tatsächlichen 
Begebenheiten oder lebenden oder verstorbenen Personen wären rein 
zufällig.)

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


Lesenswert?

Keine Ahnung was "Vesseres" bedeuten soll.
... vielleicht etwas besseres Verwässertes?:)

Außerdem: node != npm und pip != python

: Bearbeitet durch User
von 🐧 DPA 🐧 (Gast)


Lesenswert?

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

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

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

Die Situation ist schlicht nicht vergleichbar.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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

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

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


Lesenswert?

- Ja sind Build-System und Compiler jetzt verschiedene Dinge oder nicht? 
(JA)
- Welche Verrückte würde rustc (der Compiler) mit einem Makefile oder 
CMake benutzen? (Anwesende ausgeschlossen). Wer koa, der koa.

> Bis vorhin habe ich von conan tatsächlich noch nie gehört.
Tut mir leid:( Und in der Tat, das sind völlig andere Probleme als die 
der Sprachsemantik, Speichersicherheit, etc.

🐧 DPA 🐧 schrob außerdem:
> Zudem wurde hier auch immer klar angegeben, ob ein Problem/Vor-/Nachteil
> mit Cargo oder mit Rust besteht.
Das muss eine Parallelwelt sein, in der Du in diesem Faden hoch scrollen 
kannst und nicht alles durcheinander geworfen wird. Ist ja auch egal, 
kost nur Haare.

Satire: Ich komme aus einer Welt der guten Vorsätze. Aber alles endet 
irgendwann auf einem riesigen Scheißhaufen, wie etwa:
- das Repository von NPM,
- der letzte PlatformIO Library Manager sprang in den Fluss,
- pypi.org's hackertools infizieren sich schon selbst,
- Leiningen ist viel zu cool für das alles,
- Unstable, nightly-only --cargo-features sind so tief verschachtelt, 
dass sie ein eigenes Bewusstsein entwickeln und die Menschen als 
Bedrohung ansehen, besonders MaWin. Tja, gegen das fehlerhafte setzen 
eines Index innerhalb der Array-Grenzen (Bounds), hilft auch kein 
Bounds-Checker. (Tut  mir leid, MaWin:))
- etc. pp., alles von Muttern was eingemacht wird und ein Schild für 
späteres beäugen bekommt...

🐧 DPA 🐧 schrieb:
> Wäre die Diskussion gegen C++, und jemand würde sagen, verwendet nicht
> Conan, weil XY, hätte ich damit ehrlich gesagt kein Problem.
Klar. Mir sind die Anderen erst einmal anders und ich kenne mich bei mir 
am Besten aus. Etwa meine persönlichen Templates und in Jahren 
gewachsenen Monstrositäten. Das ist alles subjektiv und funktioniert für 
mich flott, einwandfrei und einleuchtend, manchmal bin ich sogar richtig 
produktiv;)

Ich finde dein Gedankenexperiment etwas schräg[1]: Conan ist nur das 
Programm. Dahinter stecken XYZ ... 2 Leute? Eine Firma? Eine Community? 
... die das Gertriebe der ganzen Packetmanager Chausse ölt.
Kein Problem mit der ganzen "Sache" zu haben ist übrigens 
selbstverständlich. Es geht mich, dich oder sonnst wen nichts an, wie 
jemand seine Arbeit verrichtet. Kritik ist erlaubt, klar, Respekt aber 
auch. Conan kannst Du mit jedem Community/Firmen betriebenen 
Datenbanksystem, das organisch wächst, ersetzen.

Bla, Ich bitte nur darum die einzelnen Schichten der Sprachumgebung zu 
trennen, oder vielleicht einmal darüber nachzudenken. DPA, Du hast 
natürlich auch Recht: Es ist ein Ökosystem.

Der Rest der Welt oooch;)

[1] Das Fass von den n^m Möglichkeiten der Objektivität, also möglicher 
(und legitimer) Toolverwendung, Expression, Impression, Iteration und 
was auf der Menükarte der Verfügbarkeiten gerade steht, machen wir nicht 
auf?

Rust? Werkzeusch. Basta!

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


Lesenswert?

"2 Leute? Eine Firma? Eine Community?" bezieht sich nun-chalant 
natürlich nicht auf das Repository von Conan.

Jeder kann selbst auf https://conan.io/center/ nachschauen. Das wird 
ohne jede Frage von Fröschen durchorganisiert.
Ich bezog mich da auf ALLLLLEEEES !!! Also meistinklusiv auf jeden 
erdenklichen Paketmanager und Paketmanagerin auf diesem Planeten und 
nicht spezifisch auf die guten Leute von Conan.

Kein plan von Fröschen, allerdings...

[Hint] JFrog ConanCenter

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


Lesenswert?

DPA: "Tut mir leid:(" ist natürlich scherzhaft gemeint.

... weil ich die Schuldige bin, die Conan in dein Leben bringt.
Verzeihung, also noch einmal;) (Mit einem Zwinkern)

von cppbert (Gast)


Lesenswert?

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

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

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

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

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

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

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

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

von Olaf (Gast)


Lesenswert?

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

Jaja, ich hab das hier gelesen:

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

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

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

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

Olaf

von MaWin (Gast)


Lesenswert?

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

Welcher Begriff stört dich denn?

von Rolf M. (rmagnus)


Lesenswert?

Ich vermute, er meint das:

Olaf schrieb:
> Ein Kernel-Crate (Rust-Bezeichnung für Bibliothek)

Warum nennt man eine Bibliothek "Crate" statt "Bibliothek"? Ist so 
ähnlich wie bei Arduino, wo ich mich schon immer gefragt habe, warum ein 
Programm nicht "Programm" heißt, sondern "Sketch".

von MaWin (Gast)


Lesenswert?

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

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

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

von Dergute W. (derguteweka)


Lesenswert?

Moin,

So, aus aktuellem Anlass hab' ich mir mal grad' wieder den rav1e neu 
ausgecheckt.
Und versucht zu bauen. Bricht natuerlich ab.
1
error[E0658]: const generics are unstable
2
 --> /root/.cargo/registry/src/github.com-1285ae84e5963aae/arrayvec-0.7.0/src/utils.rs:6:15
3
  |
4
6 | impl<T, const N: usize> MakeMaybeUninit<T, N> {
5
  |               ^
6
  |
7
  = note: see issue #74878 <https://github.com/rust-lang/rust/issues/74878> for more information

...usw...bla..fasel...
1
For more information about this error, try `rustc --explain E0658`.
2
error: could not compile `arrayvec`.

OK, mach'mer mal, wie angeheisen, dann kommt:
1
If you're using a stable or a beta version of rustc, you won't be able to use
2
any unstable features. In order to do so, please switch to a nightly version of
3
rustc (by using rustup).
4
5
If you're using a nightly version of rustc, just add the corresponding feature
6
to be able to use it:
7
8
...

So, dann wird's mal Zeit, in die doc zum rav1e zu gucken - huch, da 
steht:
1
rav1e currently requires Rust 1.51.0 or later to build.
Ja, dann ists natuerlich klar, mein uralter rustc in der Version 1.47.0 
kann das natuerlich nicht mehr bauen, den hab' ich ja auch schon vor 
fast 3  Monaten installiert, weil mein vorhergehender ja auch schon 
voellig veraltet war. Bestimmt schon 6..9 Monate alt.

Bei so'ner alten Toolchain ist das ja kein Wunder.

Und jetzt hoffentlich bald diese richtungsweisende, stabile Sprache im 
Linuxkernel.
Millionen Fliegen koennen nicht irren...

I gfrei' mi riesig!

Gruss
WK

von MaWin (Gast)


Lesenswert?

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

rustup update

Schon schwierig, gell?

von Dergute W. (derguteweka)


Lesenswert?

Moin,

MaWin schrieb:
> rustup update
>
> Schon schwierig, gell?

In der Tat:
1
root [ /usr/src/rav1e ]# rustup update
2
-bash: rustup: command not found
3
root [ /usr/src/rav1e ]#

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

Gruss
WK

von MaWin (Gast)


Lesenswert?

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

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

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

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

Ich sehe da auch überhaupt kein Problem.

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

von cppbert (Gast)


Lesenswert?

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

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

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

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

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

von cppbert (Gast)


Lesenswert?

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

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

von cppbert (Gast)


Lesenswert?

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

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

von cppbert (Gast)


Lesenswert?

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

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

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

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

von mh (Gast)


Lesenswert?

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

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

von mh (Gast)


Lesenswert?

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

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

von MaWin (Gast)


Lesenswert?

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

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

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

von cppbert (Gast)


Lesenswert?

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

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

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

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

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

von cppbert (Gast)


Lesenswert?

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

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

von cppbert (Gast)


Lesenswert?

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

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

von mh (Gast)


Lesenswert?

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

> Ich sehe auch keinen Grund das Compilerupdate zu verzögern.
> Es ist ein einziger Befehl, der dein Problem löst:
> rustup update
Du hast gesehen, warum der zu alte rustc abbricht?
1
error[E0658]: const generics are unstable
Ist rust 100% abwärtskompatibel? Also alles was mit 1.47 korrekt 
funktioniert hat, funktioniert auch mit 1.51?

von MaWin (Gast)


Lesenswert?

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

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

von mh (Gast)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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

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

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

Ja, und?

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

Ja.

von MaWin (Gast)


Lesenswert?

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

Und welche Erkenntnis bringt das?

von cppbert3 (Gast)


Lesenswert?

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

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

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

von Klaus W. (mfgkw)


Lesenswert?

cppbert3 schrieb:
> MaWin schrieb:
>>> Ist rust 100% abwärtskompatibel? Also alles was mit 1.47 korrekt
>>> funktioniert hat, funktioniert auch mit 1.51?
>>
>> Ja.
>
> Aber natürlich bringt das nichts wenn man Features nutzt die erst in
> 1.51 verfügbar sind, aber das ist bei keiner Programmiersprache die sich
> noch weiterentwickelt anders
>
> Auch bei C++ ist das Geschrei gross wenn Libs den notwendigen Standard
> anheben, weil es immer einen Haufen Leute gibt die nur C++03 kompilieren
> können

Bei allen gängigen C- und C++-Compilern ist es schon so, daß die neuen 
Versionen die neuen Features der Sprache unterstützen.
Ein altes C-Programm aus Zeiten von Kernighan und Ritchie geht dann 
nicht mehr als C++ 20 durch. Aber trotzdem kann ich sie glatt 
kompilieren, wenn ich --std=.. angebe.
Erst wenn ich im Quelltext einen neueren Standard nutze, muß ich den 
dann auch erfüllen und alte Leichen wegräumen oder mumifizieren.

Der neueste gcc kompiliert wunderbar über 40 Jahre alte Quelltexte.

Reibungsverluste in älteren Programmen durch neue Standards sind nach 
meiner Erfahrung recht übersichtlich und eher in einer Ecke zu finden, 
wo man vielleicht sogar ohnehin besser nochmal reinschauen sollte.

Jetzt kann man von einer relativ neuen Entwicklung wie Rust das gar 
nicht verlangen, das wäre unfair.
Aber im Umkehrschluß finde ich dann, daß es für professionelle 
Entwicklung viel zu unausgegoren ist. Mir zieht es die Fußnägel hoch, 
wenn man damit auf Linux losgehen will.

von MaWin (Gast)


Lesenswert?

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

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

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

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

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

Wie begründest du das?

von Vincent H. (vinci)


Lesenswert?

Die Rust "Editions" dürften so gut funktionieren, dass Vittorio Romeo 
für C++ ein ähnliches System ala "Epochen" vorgeschlagen hat, mit denen 
sich bewusst Rückwärtskompatibilitäten hätten brechen lassen sollen. Der 
Vorschlag wurde aber leider recht früh abgelehnt.

von cppbert3 (Gast)


Lesenswert?

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

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

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

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

von cppbert3 (Gast)


Lesenswert?

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

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

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

von Rolf M. (rmagnus)


Lesenswert?

cppbert3 schrieb:
> Aber natürlich bringt das nichts wenn man Features nutzt die erst in
> 1.51 verfügbar sind, aber das ist bei keiner Programmiersprache die sich
> noch weiterentwickelt anders
>
> Auch bei C++ ist das Geschrei gross wenn Libs den notwendigen Standard
> anheben, weil es immer einen Haufen Leute gibt die nur C++03 kompilieren
> können

C++03 ist 18 Jahre alt, Rust 1.47 ein halbes Jahr. Wenn du jetzt 
geschrieben hättest "… weil es immer einen Haufen Leute gibt die nur 
C++20 kompilieren können", hätte es vom Alter der Version her besser 
gepasst. Und das Geschrei wäre vermutlich tatsächlich recht groß, wenn 
schon C++20 nicht mehr reichen würde.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

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

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

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

von Olaf (Gast)


Lesenswert?

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

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

Olaf

von cppbert3 (Gast)


Lesenswert?

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

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

von Phasenschieber (Gast)


Lesenswert?

Rust fügt ein paar interessante Ideen ein:

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

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

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

Alle komplexeren Datenstrukturen sind extrem schmerzhaft
aufzubauen.

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

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

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

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

von Olaf (Gast)


Lesenswert?

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

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

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

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

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

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

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

Olaf

von MaWin (Gast)


Lesenswert?

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

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

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

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

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

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

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

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

Rust verhindert keine Speicherleaks.

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

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

von mh (Gast)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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

rustup component add rust-docs

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

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

von mh (Gast)


Lesenswert?

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

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

von MaWin (Gast)


Lesenswert?

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

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

von mh (Gast)


Lesenswert?

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

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

von MaWin (Gast)


Lesenswert?

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

Und was hast du gefragt?

> Ich konnte in der Doku keine Versionstags finden

Aha.
Dann solltest du vielleicht einmal genauer gucken.

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

MIN gibt es seit 1.43.0

von mh (Gast)


Lesenswert?

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

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

von MaWin (Gast)


Lesenswert?

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

Vielleicht sind die Changelogs da eher sinnvoll?

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

von cppbert (Gast)


Lesenswert?

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

er sucht eben was vergleichbares wie

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

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

von Klaus W. (mfgkw)


Lesenswert?

Wen es interessiert: in der aktuellen iX beginnt eine Serie mit Tutorial 
zu Rust, ggf. wer es bezahlt hat (select) natürlich auch online,

von MaWin (Gast)


Lesenswert?

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

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

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

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> Rust verhindert keine Speicherleaks.

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

Aber trotzdem kannst du nicht mit einem geleaktem Speicher arbeiten

von cppbert3 (Gast)


Lesenswert?

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

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

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

von cppbert3 (Gast)


Lesenswert?

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

von cppbert3 (Gast)


Lesenswert?

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

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

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

von MaWin (Gast)


Lesenswert?

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

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

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

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

von Johannes S. (Gast)


Lesenswert?

Welcher MaWin schreibt hier? Ich bin beeindruckt 8)

von Yalu X. (yalu) (Moderator)


Lesenswert?

MaWin schrieb:
> Ihr werdet ganz schnell furchtbar frustriert sein, weil Rust euch
> ständig mit Compilerfehlern bewirft. ...
>
> Wenn man diese Phase überstanden hat, kommt allerdings die zweite Phase,
> in der man die Vorteile dieses Vorgehens erkennt. Es gibt den Spruch: If
> it compiles, then it works.

Das kenne ich verstärkt (sowohl in negativer als auch in positiver
Hinsicht) auch von Haskell. Das funktionale Programmierparadigma und das
äußerst strenge Typsystem sorgen dort dafür, dass sehr viele Sorten von
logischen Fehlern in Typfehler münden und damit zur Compilezeit erkannt
werden.

Leider eignet sich Haskell nicht gut für die systemnahe Programmierung.
Unter den Universalsprachen, die von hardwarenah bis völlig abgehoben
alles abdecken, ist deswegen Rust IMHO der mit Abstand beste Kompromiss,
den es derzeit gibt.

von Daniel A. (daniel-a)


Lesenswert?

MaWin schrieb:
> Man muss sich Gedanken machen über das, was man schreibt.
> Macht man es nicht, wird man umgehend vom Compiler dafür bestraft.

Gedanken darüber, was man schreibt, oder Gedanken darüber, wie man es in 
Rust schreibt?

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

Als Beispiel, führe ich einfach mal die völlig verrückte Datenstruktur 
einer linked list an. Ja, ich weiss, total verrückt, sowas zu benutzen, 
so ineffizient, so kompliziert, wer der noch bei Verstand ist würde denn 
sowas machen? Aber lasse ich doch das einfach mal die Rust läute selbst 
erklären: https://rust-unofficial.github.io/too-many-lists/

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

von MaWin (Gast)


Lesenswert?

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

Beides natürlich. Wie in jeder Sprache.

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

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

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

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

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

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

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

von cppbert (Gast)


Lesenswert?

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

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

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

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

von cppbert (Gast)


Lesenswert?

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

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

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

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

von von snowflakes - für snowflakes (Gast)


Lesenswert?

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

Blödsinn.

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

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

von von snowflakes - für snowflakes (Gast)


Lesenswert?

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

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

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

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

von Yalu X. (yalu) (Moderator)


Lesenswert?

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

Ich finde Restriktionen von Seiten der Programmiersprache völlig in
Ordnung, wenn sie mir dabei helfen, zuverlässigeren Code zu schreiben
und den Debug-Aufwand zu reduzieren.

Das ist ähnlich wie im Straßenverkehr:

Ich halte mich dort gerne an das Rechtsfahrgebot. Es schränkt mich zwar
in meiner Freiheit etwas ein, dafür kommt es nicht ständig zum Crash,
weil mir ein anderes Fahrzeug auf meiner Fahrspur entgegenkommt. Falls
ich dennoch einmal unabsichtlich als Geisterfahrer unterwegs sein
sollte, fände ich es völlig in Ordnung, wenn mich die Polizei anhält und
mich auf meinen Regelverstoß hinweist.

von Jemand (Gast)


Lesenswert?


von Yalu X. (yalu) (Moderator)


Lesenswert?

von snowflakes - für snowflakes schrieb:
> Aha, also wieder nur ein Kompromiss und nur für "derzeit".

Die Welt besteht nun einmal aus Kompromissen, denn die absolute
Perfektion gibt es in der Realität nirgends.

Und wer weiß, vielleicht hält dieser derzeitige Kompromiss bis an unser
beider Lebensende und darüber hinaus.

: Bearbeitet durch Moderator
von cppbert3 (Gast)


Lesenswert?

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

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

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

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

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

von cppbert3 (Gast)


Lesenswert?

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

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

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

von Rolf M. (rmagnus)


Lesenswert?

Yalu X. schrieb:
> von snowflakes - für snowflakes schrieb:
>> Für Rust sind die Entwickler anscheinend alle doof und man muss denen
>> bestimmte Werkzeuge wegnehmen und ihnen regelmäßig auf die Finger hauen.
>
> Ich finde Restriktionen von Seiten der Programmiersprache völlig in
> Ordnung, wenn sie mir dabei helfen, zuverlässigeren Code zu schreiben
> und den Debug-Aufwand zu reduzieren.
>
> Das ist ähnlich wie im Straßenverkehr:
>
> Ich halte mich dort gerne an das Rechtsfahrgebot. Es schränkt mich zwar
> in meiner Freiheit etwas ein, dafür kommt es nicht ständig zum Crash,
> weil mir ein anderes Fahrzeug auf meiner Fahrspur entgegenkommt.

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

von MaWin (Gast)


Lesenswert?

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

Es nennt sich Weiterentwicklung.

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

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

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

Du hast noch was vergessen:

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

von MaWin (Gast)


Lesenswert?

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

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

von Jemand (Gast)


Lesenswert?

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

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

von MaWin (Gast)


Lesenswert?

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

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

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

von Daniel A. (daniel-a)


Lesenswert?

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

Ja, es ist nicht ganz so schlimm, wie ich es darstelle. Das Owner 
Konzept ist eigentlich schon eine tolle Sache, aber es nervt mit der 
Zeit halt schon etwas, das ständige Hantieren mit Rc, RefCell, Box, etc. 
bis es geht. Da frage ich mich einfach, hätte man das wirklich nicht 
einfacher/besser lösen können?

von MaWin (Gast)


Lesenswert?


von MaWin (Gast)


Lesenswert?

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

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

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

von cppbert3 (Gast)


Lesenswert?

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

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

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

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

von cppbert3 (Gast)


Lesenswert?

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

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

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

von cppbert3 (Gast)


Lesenswert?

Facebook ist jetzt auch in der Rust Foundation

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

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

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

von cppbert3 (Gast)


Lesenswert?

Vom neuen Facebook Rust Mitglied ;)

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

von MaWin (Gast)


Lesenswert?

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

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

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

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

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Mal wieder ein unqualifizierter rant:
Bei BLFS-11 ist derweilen ein rustc in Version 1.52 hip. Der hat aber 
scheints immernoch den selben shice in miri, wie schon vor mindestens 16 
Monaten hier:
Beitrag "Re: Rust - ist das hier um zu bleiben?"
beschrieben.
Also in fast 1.5 Jahren weder repariert noch rausgeflogen. Kann man 
natuerlich machen, wird nicht wichtig sein, aber sieht halt doch 
irgendwie kacke aus, find' ich. Aber was weiss ich schon.
Beim firefox bauen brauchts, scheint's auch seit geraumer Zeit einen 
patch, weil da manchmal was schief geht. Das hoert sich richtig 
ermunternd an:

[quote=patch]This is an old patch from Arch, they build with
clang and lto and have apparently needed this in the past.
On two of my systems (one from May 21 and one of my BLFS-10.0
systems) firefox-91.0esr FTBFS with a message that a python
check on libgkrust.a identified one networking function,
getsockname, in the rust static library.  The reason why this
is now giving a problem, but only on some systems, is not
understood, but this seems to stop it.[/quote]

aye caramba!
hat aber sicher nix mit rust zu tun. Gaaaanz sicher nicht...


[quote=BLFS-11_Book]...and particularly because newer versions tend to 
break older mozilla packages, the BLFS editors take the view that it 
should only be updated when that is necessary[/quote]

Wuzz? Hab' ich hier nicht noch vor ein paar Monaten erklaert bekommen, 
dass das garnicht sein kann, weil der neueste rust-compiler immer der 
geilste ist und zu allen aelteren kompatibel?

Kanns kaum erwarten, bisses endlich auch im Kernel ist.

Gruss
WK

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Haha! Kannste dir nicht ausdenken, sowas:
Ich will mal wieder - jetzt eben mit dem rust-1.52 - aus BLFS-11 (und 
damit auch erfolgreich firefox (auf dem scheib ich grad dieses 
Pamphlet), thunderbird, librsvg,... gebaut) den rav1e bauen. Nehm' ich 
halt mal's letzte "release" p20211207 her.
Boah: ein
1
cargo build --release
laeuft tatsaechlich durch. Ohne Mecker. Sollte ich tatsaechlich 
ungerechtfertigt zu miesepetrig druff sein?
Jetzt noch gschwind die c-api anflanschen, damit der Rest der (C-)Welt 
auch was von dem schicken Encoder hat:
1
root [ /usr/src/rav1e-p20211207 ]# cargo install cargo-c
2
    Updating crates.io index
3
  Downloaded cargo-c v0.9.5+cargo-0.57
4
error: failed to parse manifest at `/root/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-c-0.9.5+cargo-0.57/Cargo.toml`
5
6
Caused by:
7
  feature `edition2021` is required
8
9
  this Cargo does not support nightly features, but if you
10
  switch to nightly channel you can add
11
  `cargo-features = ["edition2021"]` to enable this feature

Ist das geil?
Ich brauche also dringend das wichtige Feature "edition2021"? rly?
Bloss gut, dass das ja nix mit rust zu tun hat und das man ja auch nicht 
gezwungen ist, cargo herzunehmen.
Kann irgendwer mal anfangen, diese wildgewordenen Informatiker ein 
bisschen zu erden?
Ja, ich weiss - niemand (ausser meiner eigenen Inkompetenz) haelt mich 
davon ab, mir einen noch viel geileren AV1 Encoder in der Sprache und 
mit dem Buildsystem meiner Wahl selbst zu programmieren. Schon klar.

SCNR;
WK

von Almdahl (Gast)


Lesenswert?

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

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

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

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

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

von MaWin (Gast)


Lesenswert?

Almdahl schrieb:
> Supply-Chain-Attacke

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

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

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

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

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

Wie hättest du es denn gerne?

von Almdahl (Gast)


Lesenswert?

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

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

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

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

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

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

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

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

von MaWin (Gast)


Lesenswert?

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

Was ja kein Problem darstellen sollte.

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

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

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

Genau.
Deshalb ist es auch kein Problem.

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

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

von Almdahl (Gast)


Lesenswert?

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

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

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

von MaWin (Gast)


Lesenswert?

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

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

Ich glaube du konstruierst dir da wirklich zwanghaft deine Probleme.

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

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

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

> wenn viele unwissend

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

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
>> Für ein mickriges Paket ist der Ressourcenverbrauch extrem.
> Im Zeitalter von Terabytefestplatten?

Auch im Zeitalter von Terabyte-Storage und Gigabyte-Speicher ist nicht 
jedes Problem mit der Nutzung sämtlichen zur Verfügung stehenden 
Stauraums gut gelöst.

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

Mal schauen. Die Sprache mag ja gut sein, der Lernaufwand ist verglichen 
mit anderen modernen Sprachen aber enorm - und das Tooling je nach 
Sichtweise entweder eine Katastrophe (wenn man C/embedded kennt) oder 
der Wunschtraum der agilen Welt (wenn man JS/web kennt).

C ist vor allem deswegen noch aktuell, weil man dafür nicht nur relativ 
einfach Compiler entwickeln kann (was für C++ nicht der Fall ist), 
sondern auch weil es in sich langfristig stabil war und ist.

Der Rust-Ansatz ist eher vom Format "wir liefern auch den alten Compiler 
mit". Da das Ökosystem aber auch Dependencies aufbaue und diese 
natürlich die neuen Features wollen, ist der praktische Nutzen sehr 
begrenzt. Wenn die Kompatiblität tatsächlich gebrochen werden sollte, 
dann kann das in einer Python 2.x/3.x-Situation münden. Alles nicht ganz 
einfach.

Mal schauen, was der Linux-Ansatz bringt - denn Linus wird ganz sicher 
keine Abhängigkeit zu Web-Services oder Paketmanagern reinbringen.

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

Müssen sie auch nicht. Heutzutage schreit man Docker, Snap und so.

von MaWIn (Gast)


Lesenswert?

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

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

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

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

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

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

Verglichen mit welchen Spachen?

> und das Tooling je nach Sichtweise entweder eine Katastrophe

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

von Almdahl (Gast)


Lesenswert?

Ich fasse es mal ehrlich zusammen:

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

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

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

von Hinterherhinkender (Gast)


Lesenswert?

Was sind Eure Rust Anwendungen und Targets?

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

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

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

Wie schwierig ist die Konfigurierung im Vergleich zu altbekannten 
Werkzeugen?

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

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

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

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

von MaWIn (Gast)


Lesenswert?

Hinterherhinkender schrieb:
> embedded

Ich denke alle deine Fragen kann man so beantworten:

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

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

von oszi40 (Gast)


Lesenswert?

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

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

von Olaf (Gast)


Lesenswert?

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

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

Lies mal hier ueber das Grauen schlechthin:

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

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

Olaf

von MaWIn (Gast)


Lesenswert?

Olaf schrieb:
> Vermutlich

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

Alle Referenzen dazu wurden hier im Thread mehrfach genannt.

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

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

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

Gegen Agressionen helfen Waldspaziergänge.

von Olaf (Gast)


Lesenswert?

> Was hat das Buildsystem mit diesem Bug zu tun?

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

Olaf

von MaWIn (Gast)


Lesenswert?

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

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

von S. R. (svenska)


Lesenswert?

MaWIn schrieb:
> Das Buildsystem führt zu komplexerem Programmcode?

Du willst missverstehen, oder?

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

Je einfacher es ist, sich zig Dependencies einzuwerfen, desto weniger 
wird über zusätzliche Dependencies nachgedacht. Dass diese 
Vorgehensweise zu im Allgemeinen zu größeren Programmen und auch 
Problemen führt, brauche ich hoffentlich nicht weiter auszuführen.

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

von MaWin (Gast)


Lesenswert?

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

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

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

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

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

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

von Daniel A. (daniel-a)


Lesenswert?

Dependencies sind wie Salz, ein bisschen davon kann gut / sinnvoll sein.

Ok, der Vergleich funktioniert nicht ganz, es gibt viele Arten von 
Dependanceies. Compile-time, Runtime, Zwingende, optional, implizit, 
umgekehrt (Plugins), etc.

Zwingende Dependencies sind wie Salz, ein bisschen davon kann gut / 
sinnvoll sein.

Optionale Runtime Dependancies sind wie Butter. Immer rein damit!

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
>> Je einfacher es ist, sich zig Dependencies einzuwerfen, desto weniger
>> wird über zusätzliche Dependencies nachgedacht.
>
> Das ist kein Problem der Sprache oder des Buildsystems, sondern es ist
> ein Problem in deinem Entwicklungsprozess.

Der Programmierer ist also schuld, wenn das Ökosystem eine bestimmte 
Programmierweise begünstigt oder erfordert. Na wenn das so ist...

> Diesen Absatz verstehe ich überhaupt nicht.

Gut, dann belasse ich dich in deiner Unwissenheit.

Daniel A. schrieb:
> Optionale Runtime Dependancies sind wie Butter. Immer rein damit!

Mögen alle Binaries dieser Welt mit sämtlichen verfügbaren 
Runtime-Dependencies aktiv ausgeliefert werden! Immer her damit!
Möge die Theorie über die Realität siegen! log4j für alle!

Seufz. Frohe Weihnachten euch allen.

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> Der Programmierer ist also schuld, wenn das Ökosystem eine bestimmte
> Programmierweise begünstigt oder erfordert. Na wenn das so ist...

Der Programmierer ist dafür verantwortlich, was er programmiert.
Das ist doch sonst auch immer das Argument von C-Verfechtern. Einfach 
einmal korrekten Programmcode schreiben. Dann braucht man keine 
Bounds-Checks.

Dass "das Ökosystem" eine "bestimmte Programmierweise begünstigt oder 
erfordert" ist halt nur deine Meinung. Ich sehe keinen Zusammenhang 
zwischen Codegröße/Projektgröße/Projektkomplexität und Rust/Cargo.
Und das wurde auch hier schon alles im Thread ausdiskutiert. Nur noch 
nicht von jedem.

> Gut, dann belasse ich dich in deiner Unwissenheit.

Ok. 1:0 für mich.

von Almdahl (Gast)


Lesenswert?

Ich erkläre es einmal mit einer Analogie: Im Linux-Kernel soll man Tabs 
mit 8 Spalten benutzen. Die Begründung ist unter anderem, dass man 
dadurch gezwungen wird, die Blocktiefe gering zu halten. Schließlich 
rückt man durch jeden Block um 10% näher ans Zeilenende.

Es ist, denke ich, einleuchtend, dass diese Maßnahme einen häufig 
gemachten Fehler extrem reduzieren kann, weil man ihn technisch nicht 
mehr umsetzen kann, im Vergleich zu z.B. 2 Spalten als Einrückung.

Deshalb halte ich die Ansicht, dass Dinge die einfach durchführbar sind, 
mit der Menge an tatsächlichen Durchführungen nichts zu tun habe, für 
rational nicht nachvollziehbar.

Aus meiner Sicht gehört zum Design und Ökosystem einer 
Programmiersprache auch die Sorge um den Sinnvollen Einsatz und dem 
leisten von Hilfestellungen - in Härtefällen auch durch absichtliche 
Einschränkung oder Behinderung von höchstproblematischen Fehlern.

von Nop (Gast)


Lesenswert?

S. R. schrieb:

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

Wird ja noch geiler mit Cargo, weil dann letztlich jede Anwendung ihre 
eigenen Abhängigkeiten selber statisch reingebacken bekommt. Hab dann 
mal sowas wie Log4j gerade, das wird richtig lustig werden. Da merkt man 
halt, daß Rust aus ner YOLO-Webbude stammt.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Zur Abwechslung mal gute Neuigkeiten. Der rav1e-p20211207 laesst sich 
grad mittels rustc-1.56.1 bauen. Yay!
(Notorische Schwarzseher wuerden natuerlich gleich fragen: Und wie lange 
noch? ;-)

Gruss
WK

von Carsten P. (r2pi)


Lesenswert?

S. R. schrieb:
> Mögen alle Binaries dieser Welt mit sämtlichen verfügbaren
> Runtime-Dependencies aktiv ausgeliefert werden! Immer her damit!

Ist ein bisschen off-topic jetzt, aber das hatten wir schonmal mit der 
berüchtigten "DLL Hell" unter Windows bis XP ungefähr. Und wir haben es 
in so gut wie jeder Linux-Distro.

Lade irgendeine besonders kompakte Debian-Distro runter, egal ob für 
i64- oder RPi-Habitat. Das ist jetzt bewusst polemisch, aber füge 10 
Pakete hinzu, die du brauchst oder willst, irgendeins davon referenziert 
auf irgendwas mit Grafik, auch wenn du genau das nicht willst, und 
schwupps ist aus deinem kompakten, sicheren Debian-Headless ein 
aufgeblähtes Klicki-Ubunti-Desktop-System geworden.

Ja, ich benutze an sehr vielen Stellen Linux. Nein, ich benutze kein 
IoT-Windows. Aber es ist jedesmal ein Akt des Grauens, diesen 
Troll-Horden aus Paket-Abhängigkeiten Herr zu werden.

Typisch z.b. für Windows(!)-Projekte, die ihre Ursprünge aus der 
Win32-Zeit haben, ist, dass sie auf irgendwelche uralten Runtimes 
referenzieren und auf deren Installation bestehen, obwohl man ne viel 
neuere Runtime auf dem System hat. Neuere Anwendungen sind da viel 
sauberer, ohne dass sie ständig Updates brauchen.

Typisch für Linux-Anwendungen ist, dass sie sich bis heute so benehmen. 
Das ist eben (Achtung, jetzt kommt Gemecker) der Nachteil einer offenen 
Umgebung, wo jeder macht, was er will, ohne dass außer um die ganz 
wesentlichen Dinge wie den Kernel keiner groß guckt.

Die beste Idee an Win386/Win3 war, dass es ein Aufsatz auf DOS war. DOS 
funktionierte ganz ohne Windows. Das endete mit Win95.

Ein sauberes Unix-System war immer so. Ein sauber aufgesetzter X-Server 
kann immer noch ohne Client-X11-Gedöns. Probier das mal heute mit Tools 
wie apt und Co. Und selbst, wenn du ein paar kleine Tools aus den 
Sourcen bauen willst, kommt irgendwann eine Abhängigkeit, die dir wieder 
Zeug auf die Maschine bringt, die du einfach aus Sicherheitsgründen 
nicht haben willst, wenn du den Kram nicht im Detail kennst und weder 
Zeit noch Lust hast, selbst ein Audit zu machen.

Und dasselbe gilt für sehr viele Programmierumgebungen. Setz mal nen 
Build-Server für z.B. Python auf, ohne dass auf dem Server GUI-Kram 
landet.

Um der üblichen Debatte Linux vs. Windows vorzubeugen: Es ist 
richtig(!), dass man inzwischen wieder Headless-Server unter Windows 
aufsetzen kann, aber es ist irre aufwändig und nur für Großkunden von MS 
machbar, weil die Tools nicht oder nur sehr schwer auffindbar zur 
Verfügung stehen. Der Weg von Unix war immer andersherum, so wie gesagt 
bei DOS + Windows.

Das Problem ist halt, dass ohne "offizielle Aufsicht" über die Pakete 
die OoopsSource Community macht, was sie will, und wenn ein Coder 
findet, dass er für sein Kommandozeilen-Tool ne Funktion aus ner 
Gnome-Anwendung benutzen muss, weil es halt da ist (auf seinem PC), 
wandert die Abhängigkeit halt ins Paket, und apt und Co. machen das, was 
er will und bestehen auf die Gnome-App, die auf Gnome besteht, das auf 
diesdasjenes besteht...

Wie gesagt: Schwupps!

Ich bleibe unter Linux bei genau dem, was die GNU Compiler Collection 
her gibt, weil da eben doch wer drauf guckt, plus DotNet / Xamarin-Mono, 
weil da auch wer drauf guckt, insbesondere wer, der sich um seinen 
Börsenwert schert. Es gibt das NanoFramework für uCs.

von Rolf M. (rmagnus)


Lesenswert?

Carsten P. schrieb:
> Typisch z.b. für Windows(!)-Projekte, die ihre Ursprünge aus der
> Win32-Zeit haben, ist, dass sie auf irgendwelche uralten Runtimes
> referenzieren und auf deren Installation bestehen, obwohl man ne viel
> neuere Runtime auf dem System hat. Neuere Anwendungen sind da viel
> sauberer, ohne dass sie ständig Updates brauchen.

Heute mit .net wird das eben so gemacht, dass man einfach ein Dutzend 
.net-Frameworks parallel installiert hat, weil jedes Programm eine 
andere Version braucht.

> Die beste Idee an Win386/Win3 war, dass es ein Aufsatz auf DOS war. DOS
> funktionierte ganz ohne Windows. Das endete mit Win95.

Das Problem war halt, dass man die dringend fehlenden 
Betriebssystem-Grundfunktionen nicht in DOS, was eigentlich das 
Betriebssystem war, integriert hat, sondern in dessen graphischer 
Benutzeroberfläche.

> Ein sauberes Unix-System war immer so. Ein sauber aufgesetzter X-Server
> kann immer noch ohne Client-X11-Gedöns.

Wozu brauchst du einen X-Server ohne X-Clients?

> Das Problem ist halt, dass ohne "offizielle Aufsicht" über die Pakete
> die OoopsSource Community macht, was sie will, und wenn ein Coder
> findet, dass er für sein Kommandozeilen-Tool ne Funktion aus ner
> Gnome-Anwendung benutzen muss, weil es halt da ist (auf seinem PC),
> wandert die Abhängigkeit halt ins Paket, und apt und Co. machen das, was
> er will und bestehen auf die Gnome-App, die auf Gnome besteht, das auf
> diesdasjenes besteht...

Teilweise liegt sowas aber auch an den Distros und die Art, wie sie ihre 
Pakete zusammenstellen. Das habe ich gemerkt, als ich einen 
Docker-Container für den Build einer Software aufsetzen wollte. Dafür 
musste git installiert sein, weil die Entwickler es für nötig gehalten 
haben, irgendwelche git-Kommandos als Teil des Build-Prozesses 
auszuführen. Nun gab es eigentlich unter Debian mal ein minimales 
git-Paket und ein Meta-Paket, dass git mit kompletter Doku und ein paar 
Skripten und so Zeug installiert hat. Leider wurde das minimale Paket 
verworfen, und jetzt muss immer alles installiert sein. Und da geht's 
dann los: Nur für die blöden erwähnten Skripte, die ich nicht brauche, 
muss eine komplette Perl-Umgebung mit Dutzenden von Paketen installiert 
werden. Am Ende sind die Abhängigkeiten von dem Teil von git, den ich 
nicht brauche, größer als der ganze Rest vom Container, nur weil die bei 
Debian meinen, dass man ein minimales Paket nicht mehr braucht.

von Carsten P. (r2pi)


Lesenswert?

Rolf M. schrieb:
>> Ein sauberes Unix-System war immer so. Ein sauber aufgesetzter X-Server
>> kann immer noch ohne Client-X11-Gedöns.
> Wozu brauchst du einen X-Server ohne X-Clients?

Ich meinte, dass auf dem Server nicht notwendigerweise Client-Kram 
installiert sein muss. Der kann lokal ganz ohne GUI, er liefert an die 
Clients aus.

> Teilweise liegt sowas aber auch an den Distros und die Art, wie sie ihre
> Pakete zusammenstellen. (...)
> irgendwelche git-Kommandos (...)
> Leider wurde das minimale Paket verworfen (...)
> Und da geht's dann los: Nur für die blöden erwähnten Skripte,
> die ich nicht brauche, muss eine komplette Perl-Umgebung
> mit Dutzenden von Paketen installiert werden.

Exakt das ist das perfekte Beispiel für das, was ich meinte.

Und die Person, die "wurde" ist, kriegst du nicht zu fassen, "es" wurde 
halt entschieden.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
> Wie gesagt: Schwupps!

Du schreibst leider ganz großen Unsinn und dazu hat er auch nichts mit 
Rust zu tun. Deshalb werde ich nicht näher darauf eingehen.

Bitte beim Threadthema bleiben!

von Carsten P. (r2pi)


Lesenswert?

MaWin schrieb:
> Bitte beim Threadthema bleiben!

Das Dahinter ist dasselbe. Dass du Rust-Fanboy bist, habe ich schon 
verstanden. Du hast mir bisher viele gute Replies geschrieben, also 
halte auch mal paar Krümel aus, die nicht in deine Sahnesoße passen ;-)

Fakt ist, dass Rust derzeit keine stabile, dauerhafte Umgebung mit 
Zukunft ist -- was ich auf Dauer auch für Ruby und Python vorhersage. 
Weil es nicht genug Leute gibt, die sich endlich mal damit beschäftigen, 
die OpenHorde zu bändigen und auch mal notwendige Ansagen zu machen.

von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
> Das Dahinter ist dasselbe. Dass du Rust-Fanboy bist, habe ich schon
> verstanden.

Ich bin sicher kein "Fanboy", sondern ich setze mich mit den Dingen 
auseinander, bevor ich sie bewerte.

> also halte auch mal paar Krümel aus, die nicht in deine Sahnesoße passen ;-)

Ich sehe nur, dass du hier abstraktes Zeug ablädtst.
Würdest du vielleicht einmal den Namen des Paketes nennen, bei dem eine 
komplette Desktop-Umgebung installiert wird, obwohl das nicht zu 
erwarten ist?
Dann können wir vielleicht weiterdiskutieren.

> Fakt ist, dass Rust derzeit keine stabile, dauerhafte Umgebung mit
> Zukunft ist -- was ich auf Dauer auch für Ruby und Python vorhersage.

"Fakt" also. Soso.
Belegen musst du das selbstverständlich nicht. Denn es ist "Fakt".

von Kaj (Gast)


Lesenswert?

Carsten P. schrieb:
> Fakt ist, dass Rust derzeit keine stabile, dauerhafte Umgebung mit
> Zukunft ist -- was ich auf Dauer auch für Ruby und Python vorhersage.
Python ist erst 30 Jahre alt, Ruby 26. Ja, werden bestimmt bald 
verschwinden. So wie C und C++ auch verschwunden sind.

von Dergute W. (derguteweka)


Lesenswert?

Kaj schrieb:
> Python ist erst 30 Jahre alt,

Ich waer' ja froh, wenn wenigstens mal nur Python2 verschwinden wuerde; 
aber nichtmal das klappt :-(
Gegen die Sprachen an sich hab' ich auch garnix. Ich hab' was dagegen, 
dass jeder Depp meint, er muss einen eigenen Paketmanager verwenden und 
dass sich Sprachen, die noch nicht so recht stabil sind, schon in 
irgendwelchen Projekten festsetzen, die eigentlich etwas stabiler sein 
sollten...
Aber was weiss ich schon, bin kein Informatiker.

Gruss
WK

von MaWin (Gast)


Lesenswert?

Dergute W. schrieb:
> dass jeder Depp meint, er muss einen eigenen Paketmanager verwenden

Du musst es ja nicht verwenden, wenn du das nicht möchtest. Du kannst 
dir alle Dependencies, solltest du denn welche haben, alle manuell 
zusammenstellen. Gar kein Problem.

Aber das haben wir hier im Thread bereits mehrfach geklärt.

> und dass sich Sprachen, die noch nicht so recht stabil sind, schon in
> irgendwelchen Projekten festsetzen, die eigentlich etwas stabiler sein
> sollten...

Ab wann ist denn eine Sprache nach deiner Definition stabil?
Rust ist dank der Editions äußerst stabil und es herrschen ziemlich 
strikte Regeln welche Änderungen innerhalb von Editions erlaubt sind, 
welche Änderungen zwischen Editions erlaubt sind und welche Änderungen 
es niemals geben wird.

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

https://doc.rust-lang.org/edition-guide/introduction.html

Jedes Rust-Release wird gegen alle auf crates.io verfügbaren Pakete 
getestet (build test).

Ich persönlich habe es noch nicht erlebt, dass irgendein crate sich 
nicht bauen lassen wollte.
Im Gegensatz zu zum Beispiel C/C++-Paketen mit CMake, Autotools oder was 
auch immer. Da kommt es ständig zu Buildabbrüchen. Alleine schon, weil 
das Buildsystem sich die Dependencies nicht holen kann.

von Gerhard O. (gerhard_)


Lesenswert?

Ich wage vorauszusagen, daß es C, C++, Python, Java, PHP und Co. Und 
vielleicht auch Rust, auch in 100 Jahren noch geben wird. Was sich 
bewährt hat überlebt auch. C mag im Vergleich zu Sprachen 
Neuentwicklungen "Ancient to the Extreme" sein, hat aber Stabilität und 
Effizienz und seine eigene Eleganz. Für Kernel oder Nischen Anwendungen 
oder uC ist C in den Händen erfahrener Designer bestimmt immer noch gut 
geeignet.

Das größte Problem der modernen SW Entwicklung sind nicht 
notwendigerweise die Sprachen und Werkzeuge selber. Vielmehr verursachen 
unschöne Geschäftserwartungen und Time to Market Constraints viele 
Probleme durch Hetzerei die Produkte auf den Markt zu werfen. Man nimmt 
sich nicht mehr die Zeit, durchdacht und gemächlich vorgehen zu können. 
Deshalb haben wir ja auch andauernd persistente Sicherheitslücken. Ein 
Gebäude ist nur so robust wie sein Grundgerüst. Viele moderne IT 
Produkte können aus der Sicht des Users teilweise sehr nervig sein weil 
man sich nicht die Zeit nimmt, ergonomische Unebenheiten auszubügeln. 
Das ist sehr schade, weil jene so vermeidbar wären. Wer hat sich noch 
nicht maßlos geärgert wenn sich ein Gerät so dumm verhält und unnötig 
schwer bedienbar ist.

Was wir in der Welt weniger brauchen ist diese Lawine von unwichtiger 
Elektronik und SW. Es ist Zeit Fazit zu nehmen um festzustellen wo wir 
uns befinden und ins nicht länger vom Strom des Marktes mit schwemmen 
lassen. Daß das zutreffend ist, kann man alleine daraus folgern, daß 
kaum einer heutzutage imstande ist tolle Produkte zu nennen die 
erinnerungswürdig sind. Wir werden von einer Lawine fernöstlicher 
vergessbaren Ramschware und Billigprodukten erdrückt und verlieren 
eigenes Produktionspotenzial. Wie viele Firmen können aus diesen Grund 
schon lange nicht mehr überleben.

Beruflich ist es sowieso notwendig gut in der (den) Sprache(n) zu sein, 
für die ihm der Brötchengeber bezahlt und in die Firmenkultur reinpasst.

Was mich und meine Anwendungen betrifft finde ich C besonders praktisch 
und das braucht sonst niemand besonders interessieren. Was mir an C 
gefällt ist die maschinennahe direkte Übersetzung und für uC Anwendungen 
ist das nicht unbedingt ein Nachteil. Man abstrahiert heute m.M.n. 
sowieso oft unnötig zu viel. Aber jeder mag es so halten wie es ihm für 
zweckmässig erachtet.

Ich verstehe nicht wirklich warum wegen Computersprachen in den Foren so 
oft hitzige Glaubenskriege verursacht werden. Wir sind doch keine 
Missionare. Jeder kann doch diejenigen Werkzeuge verwenden die subjektiv 
attraktiv sind und für die beabsichtigten Zwecke gut funktionieren. Auch 
sind wir nicht alle gleich in der Art wie unsere Gehirne diesbezüglich 
funktionieren; der eine hat eine natürliche Affinität für 
objektorientierte Denkweise, der Andere ist mit prozedurer Denkweise 
total komfortabel. Deshalb sind diese ganze Streitereien und 
Diskussionen überflüssig weil wir alle grundverschieden sind. 
Konformität ist nur beruflich benötigt. Viele Argumente sind subjektiv 
bestimmt exakt zutreffend, aber nicht unbedingt in anderen Augen. Mit 
genug Disziplin und Erfahrung kann man in fast allen Sprachen 
zuverlässige SW bauen, sogar auch in C:-)

Ob jetzt aus Rust ein Erwachsener wird, muß die Zukunft zeigen. Wenn es 
tatsächlich die Erwartungen eventuell erfüllen wird, dann wird es auch 
früher oder später eine solide Nische im Arsenal der Computerwerkzeuge 
finden. Time will tell. Bis dahin wird man eben sich damit befassen 
müssen.

von MaWin (Gast)


Lesenswert?

Gerhard O. schrieb:
> Man nimmt
> sich nicht mehr die Zeit, durchdacht und gemächlich vorgehen zu können.
> Deshalb haben wir ja auch andauernd persistente Sicherheitslücken.

Ich würde das nicht als Hauptgrund für die Sicherheitslücken sehen, die 
wir ständig haben. Ich würde das eher in dieser Reihenfolge (1 = 
Hauptgrund) bewerten:

1: Kompetenz und Sicherheitsbewusstsein bei den Entwicklern ist nicht 
ausgeprägt genug. Aktuelles Beispiel? log4j.

2: Die Sprache erlaubt viel zu einfach triviale Schwachstellen. 
Aktuelles Beispiel?
https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/lua/lua_request.c?r1=1896039&r2=1896038&pathrev=1896039
Das wäre mit Rust auch ein Bug, ein DoS, aber keine 
Speicherkorruption/Sicherheitslücke, die man eskalieren kann.

999: Druck vom Management und zu wenig Zeit.

von MaWin (Gast)


Lesenswert?

Gerhard O. schrieb:
> Wir sind doch keine Missionare.

Genau.
Wenn jemand kein Rust verwenden will, dann soll er es halt lassen. Wenn 
jemand meint C wäre die Antwort auf alle Fragen, dann soll er halt C 
verwenden. Das ist mir wirklich egal, was jeder tut.
Ich sage ja auch nicht, dass Rust die Lösung für alle Probleme ist und 
dass ab sofort Rust für alles verwendet werden muss.

Was ich nicht mag ist, wenn Unsinn verbreitet wird.

Viel Unsinn in diesem Thread ist einfach von Leuten, die Rust eindeutig 
noch nie verwendet haben und die Sprache nur aus dem Heise-Forum kennen.

Und dann gibt es auch noch die Leute, die grundsätzlich gegen alle 
Neuerungen sind. Da wäre ich froh, wenn die sich einfach komplett vom 
Thema fern halten. Lasst uns doch machen und lasst uns doch scheinbar in 
die Sackgasse fahren. Kann euch doch egal sein.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

MaWin schrieb:
> Ab wann ist denn eine Sprache nach deiner Definition stabil?
Weiss ich nicht. Aber ich merk' wann was instabil ist: Wenn z.b. nach 
ein paar Monaten schon compiler und code irgendwie nicht mehr 
zusammenpassen wollen. Ich saug' mir das ja nicht aus den Fingern, 
sondern schreibe hier schon auch die Versionsnummern dazu.

MaWin schrieb:
> Jedes Rust-Release wird gegen alle auf crates.io verfügbaren Pakete
> getestet (build test).
>
> Ich persönlich habe es noch nicht erlebt, dass irgendein crate sich
> nicht bauen lassen wollte.
Ich will auch kein crate bauen, schlonz verschwurbeln oder ein Honk 
verschradeln oder sonst sowas exotisches.
Ich will ein Videocodec. Aus sourcen. Punkt. Nix weiter.
Und das klemmt deutlich haeufiger und unangenehmer, wenn da Rust im 
Spiel ist. Auch wenn du mir 10x erzaehlst, dass da Rust natuerlich 
ueeeeberhaupt nix dazu kann. Der Kommunismus kann auch nix dazu, das er 
mit real existierenden Menschen nicht funktioniert. Aber deshalb sollte 
man ihn nicht einsetzen. Wie Rust.

MaWin schrieb:
> Im Gegensatz zu zum Beispiel C/C++-Paketen mit CMake, Autotools oder was
> auch immer. Da kommt es ständig zu Buildabbrüchen. Alleine schon, weil
> das Buildsystem sich die Dependencies nicht holen kann.
Und genau das ist gut so. Ich will wissen, was da fuer dependencies 
drinnen sind. Und bei gut geschriebener Software kann ich mir's sogar 
raussuchen, ob ich irgendeine lib und ihre Funktionalitaet drinnenhaben 
will oder nicht. Bei ffmpeg ist das ein Thema, weil davon dann auch die 
Lizenz abhaengt, unter der das dann steht.

Bei den Autotools ist's sogar so geil, das man auch nach langer Zeit 
einfach mal in der config.log nachschauen kann, mit was man das Dingens 
damals tatsaechlich konfiguriert & gebaut hat.
Bei cmake, ninja, meson siehts bei so elemetaren Sachen ja eher schon 
arg mau aus - oder ich bin einfach zu bloed.

Gruss
WK

von MaWin (Gast)


Lesenswert?

Dergute W. schrieb:
> Ich saug' mir das ja nicht aus den Fingern,
> sondern schreibe hier schon auch die Versionsnummern dazu.

Ich sage ja nicht, dass das nicht stimmt.
Sondern ich sage nur, dass du dort eine absolute Ausnahme erwischt hast.

> Ich will wissen, was da fuer dependencies drinnen sind

Kein Problem mit Cargo:
https://doc.rust-lang.org/cargo/commands/cargo-tree.html

> Und bei gut geschriebener Software kann ich mir's sogar
> raussuchen, ob ich irgendeine lib und ihre Funktionalitaet drinnenhaben
> will oder nicht

Kein Problem mit Cargo:
https://doc.rust-lang.org/cargo/reference/features.html

> Bei den Autotools ist's sogar so geil, das man auch nach langer Zeit
> einfach mal in der config.log nachschauen kann, mit was man das Dingens
> damals tatsaechlich konfiguriert & gebaut hat.

Kein Problem mit Cargo:
Cargo.lock

Aber wenn dir Cargo nicht passt, kannst du selbstverständlich auch dein 
Rust-Projekt mit Autotools bauen oder mit jedem anderen beliebigen 
Buildsystem.

von Carsten P. (r2pi)


Lesenswert?

> Ich will mir mal einen heif-decoder
> (das neue,lustige Video/Bildformat
> von Apple unter Linux

Okay, da würde ich auch als Fauchbatz und Knurrer nur sagen "Fuck U, so 
what" xD Wer das neue lustige Format von den neuen Apple Situps mit den 
neuen von Google verkrackten Crunches vergleicht und dabei auch noch 
Sicherheit und so haben will, im Ernst... lol

von A. F. (chefdesigner)


Lesenswert?

cppbert schrieb:
> Das ist definitiv eine riesen Herausforderung - an der bisher jede
> Sprache ausser C (C++) und ein paar wenigen anderer, gescheitert ist -

Sehe ich ganz genau so. Embedded ist zu breit gefächert. Auf die 100 
Chips, die es im Mainboard-Bereich gibt, die aktuell laufen und neu 
unterstützt werden müssen, kommen im embedded-Bereich 10x soviele! 
Gleichzeitig sind es 100x weniger Nutzer!

Es lohnt sich dreimal, eine Programmiersprache auf low level den PCs 
hinterher zu entwickeln, aber im embedded Bereich ist man immer 
hinterher. Auch die Gold-Anbieter decken immer nur einen Teil der 
Landschaft ab und teilen sich so den Markt. Wie will ein am Ende doch 
kleines Team das bewältigen?

Der Aufwand für solche Neuimplementierungen und BSPs liegt im embedded 
Bereich bei locker dem 3-4 fachen und zusammen mit der Vielfalt der 
Chips braucht es 200 ... 500 mal mehr Entwickler, um Schritt zu halten.

Um einen weiteren Vergleich zu ziehen wäre es interessant zu wissen, 
wieviele Compiler-Entwickler es weltweit gibt. Das sind hunderte Firmen 
mit Tausenden Programmierern. Die zu überholen wird schwer ,,,

von MaWin (Gast)


Lesenswert?

Andreas F. schrieb:
> Die zu überholen wird schwer ,,,

Es ist überhaupt nicht der Anspruch jeden Nischencompiler "zu 
überholen".
Es ist völlig in Ordnung auch in Zukunft Embedded-Software in C zu 
schreiben.

Rust unterstützt aber bereits sehr viele ARM Devices und damit einen 
Großteil des Embedded-Marktes. Wenn GCC-Rust verwendbar wird (erste 
Version vermutlich nächstes Jahr), dann wird das noch einmal gewaltig 
ausgeweitet.

von HabMut (Gast)


Lesenswert?

MaWin schrieb:
> Wenn
> jemand meint C wäre die Antwort auf alle Fragen, dann soll er halt C
> verwenden. Das ist mir wirklich egal, was jeder tut.

Mir ist das nicht egal. In vielen Fällen kann es einem egal sein was 
andere bevorzugen. Aber wenn die Wahl von Menschen, zu Folge hat, das 
Schäden für mich und andere Menschen entstehen, dann ist das nicht egal.

C Programme beinhalten häufig vermeidbare Sicherheitslücken die die 
Sicherheit von IT Systemen gefährden. In der Folge entstehen massive 
Schäden. Daten werden geklaut oder manipuliert und vielen Unternehmen 
entstehen beträchtliche finanzielle Schäden.

Ist wie mit der Logik der Schutzimpfung. Wer sich nicht impfen lässt 
trifft nicht nur eine Entscheidung für sich, sondern beeinflusst auch 
die Sicherheit anderer Menschen.

von MaWin (Gast)


Lesenswert?

HabMut schrieb:
> C Programme beinhalten häufig vermeidbare Sicherheitslücken die die
> Sicherheit von IT Systemen gefährden. In der Folge entstehen massive
> Schäden. Daten werden geklaut oder manipuliert und vielen Unternehmen
> entstehen beträchtliche finanzielle Schäden.

Das ist richtig.
Trotzdem kannst du andere Leute nicht dazu zwingen eine Sprache zu 
verwenden, die sie nicht verwenden möchten.
Dir steht aber offen entweder diese Programme nicht zu verwenden, oder 
sie selbst in Rust zu implementieren.

von HabMut (Gast)


Lesenswert?

MaWin schrieb:
> Trotzdem kannst du andere Leute nicht dazu zwingen eine Sprache zu
> verwenden, die sie nicht verwenden möchten.

Aus einer Kritik muss nicht immer ein Zwang hervorgehen. Kritik ist aber 
erforderlich damit etwas langfristig besser werden kann.
Genau so ist Kritik an Rust auch ok und förderlich.

von Olaf (Gast)


Lesenswert?

> C Programme beinhalten häufig vermeidbare Sicherheitslücken die die
> Sicherheit von IT Systemen gefährden.

Meinst du nicht das diese Einstellung in diesem Zusammenhang etwas
laecherlich ist oder ist Rust schon nach IEC61508 zertifiziert?

Olaf

von MaWin (Gast)


Lesenswert?

Olaf schrieb:
>> C Programme beinhalten häufig vermeidbare Sicherheitslücken die die
>> Sicherheit von IT Systemen gefährden.
>
> Meinst du nicht das diese Einstellung in diesem Zusammenhang etwas
> laecherlich ist oder ist Rust schon nach IEC61508 zertifiziert?

Es geht um Security, nicht um Safety.

von Jens B. (dasjens)


Lesenswert?

Firefox?
Ist das nicht der Laden wo die guten Entwickler, abgehauen sind, und die 
jetzt lieber einen auf bunten FF machen stats einem guten Browser?

von DPA (Gast)


Lesenswert?

HabMut schrieb:
> C Programme beinhalten häufig vermeidbare Sicherheitslücken die die
> Sicherheit von IT Systemen gefährden. In der Folge entstehen massive
> Schäden.

Nein, jedes Programm in jeder Programmiersprache hat zwangsläufig 
Sicherheitslücken. Daran ändert Rust nichts. Man sehe sich z.B. log4j 
an. Java ist absolut Memory Safe, dank Garbage Kollektion. Und trotzdem 
hat man plötzlich gemerkt, das eigentlich jedes Java Programm einen 
format String basierten Remote Code Execution Bug hat.

Eine Programmiersprache hilft nur wenig beim verhindern von solchen 
Fehlern. Was man wirklich braucht sind (bei der Entwicklung) Erfahrung, 
KISS, einen Überblick, was alle Programmkomponenten genau machen und wie 
sie zusammen spielen, (und bei OPs) jemand der alles Updated wenn 
Probleme gefunden werden, Tests, offizielle Kanäle zum melden von Bugs, 
und eventuell von zeit zu zeit mal ein Audit, usw.

Und massive Schäden vermeidet man auch nicht mit einer "sicheren" 
Sprache. Statdessen braucht man eine gute Incidence Response Strategie, 
und regelmässige Übungen. Also offline Backups von allem, das zurück 
spielen prüfen, eventuell ein Fallback System (das kann auch analog 
sein, Hauptsache jeder weiss, was er Zutun hat), etc. Idealerweise 
sollte alles weiterlaufen, wenn mal das Haus abfackelt.

von Carsten P. (r2pi)


Lesenswert?

HabMut schrieb:
> C Programme beinhalten häufig vermeidbare Sicherheitslücken die die
> Sicherheit von IT Systemen gefährden.

Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber 
"sicher" keine sicherheitsrelevanten großen Systeme. Ich kenne genau 
einen sehr versierten "plain C"-Entwickler, dem ich meine Bedürfnisse 
nach einer Software anvertrauen würde, und der verwendet eine selbst 
entwickelte GC, da ist nix mit malloc(). strcpy() und free(). Läuft seit 
der ersten Version sogar auf S7-Steuerungen.

Traue keiner Runtime ohne verwaltetem Speicher! Und traue gar keinem 
System ohne eine Runtime/einem Framework! Das gilt für Linux wie für 
Windows wie für Android wie für iOS.

von Nop (Gast)


Lesenswert?

DPA schrieb:

> Nein, jedes Programm in jeder Programmiersprache hat zwangsläufig
> Sicherheitslücken. Daran ändert Rust nichts.

Das Argument war aber nicht, daß Rust-Programme keine Sicherheitslücken 
hätten, sondern daß ganze Fehlerklassen mitsamt den zugehörigen 
Sicherheitslücken ausgeschlossen werden. Formatstring-basierte Lücken 
können C/C++-Programme nämlich zusätzlich zu den Speicherlücken haben.

von Carsten P. (r2pi)


Lesenswert?

Nop schrieb:
> Das Argument war aber nicht, daß Rust-Programme keine Sicherheitslücken
> hätten, sondern daß ganze Fehlerklassen mitsamt den zugehörigen
> Sicherheitslücken ausgeschlossen werden. Formatstring-basierte Lücken
> können C/C++-Programme nämlich zusätzlich zu den Speicherlücken haben.

Zur Ehrenrettung anderer Umgebungen sei noch erwähnt, dass die das auch 
können, nicht nur Rust. Python ist da recht stabil, wenn auch langsam, 
das .NET NanoFramework kann das ebenso, nur schneller.

Manche Leute meinen halt, dass das Programmieren von Mikrocontrollern 
weh tun muss, drum dann C. Die Zeiten ändern sich, auch wenn es manchen 
Leuten nicht passt. Wie gesagt, Python, Rust, NanoFramework sind halt 
das, was man heute einfach benutzt. Und für extrem zeitkritische 
Applikationen nimmt man halt entweder Maschinencode oder einfach die 
Version des uC, der schnell genug ist. Wer da auf den Cent genau 
kalkuliert, kalkuliert garantiert zweimal.

von DPA (Gast)


Lesenswert?

Nop schrieb:
> Das Argument war aber nicht, daß Rust-Programme keine Sicherheitslücken
> hätten, sondern daß ganze Fehlerklassen mitsamt den zugehörigen
> Sicherheitslücken ausgeschlossen werden.

Das mag ja sein, aber Speicherbasierte Sicherheitslücken sind meist 
nicht trivial auszunutzen, da brauchen Angreifer doch etwas Zeit, 
know-how, und Zusatzwissen zum Zielsystem. Den fix hat man dann meistens 
lange bevor das jemand ausnutzen kann.

Aber all die anderen Fehlerklassen (format string confusion, zeugs das 
code/module nachlädt und ausführt, xss artiges zeug, parser bugs, path 
confusion bugs, supply chain Attacken, etc. etc., alles viel einfacher 
auszunutzen, und meiner Meinung nach viel gefährlicher.

Zu meinen, Speichersicherheit mache den unterschied, ist wie die 
Vordertür abschliessen, aber nicht nachsehen, ob die Hintertür noch 
offen ist. Alles nur ein tropfen auf den heissen Stein, ein falscher 
sinn von Sicherheit, nutzlos!

von MaWin (Gast)


Lesenswert?

Carsten P. schrieb:
> Zur Ehrenrettung anderer Umgebungen sei noch erwähnt, dass die das auch
> können, nicht nur Rust.

Es geht aber darum, dass Rust diese Konzepte erzwingt und noch viel 
weiter treibt (Lifetimes) als z.B. C++.
Ein Rust-Programm kann kein UB durch AOOB-Accesses haben. Ein 
Rust-Programm kann keine Data-Races haben.
Es ist ein riesiger Unterschied, ob man in C++ diese Fehler auch 
vermeiden kann, oder ob diese Fehler in Rust gar nicht möglich sind.

> Und für extrem zeitkritische
> Applikationen nimmt man halt entweder Maschinencode

Oder halt Rust.

von Olaf (Gast)


Lesenswert?

> Nein, jedes Programm in jeder Programmiersprache hat zwangsläufig
> Sicherheitslücken. Daran ändert Rust nichts. Man sehe sich z.B. log4j
> an.

Das Problem hier ist aber das man fremden Source in eigenen Programmen 
benutzt und der nicht fehlerfrei ist. Etwas das ja wohl heute Standard 
sein duerfte. Und die Leute machen das weil es bequemer, einfacher, 
zeitsparender ist als wenn man es selber macht. Gelegentlich auch weil 
ein fremder Autor mehr Expertise in einem Thema hat als man selber. 
Alles Dinge die sicherstellen das man garnicht in der Lage ist selber 
die Fehler in fremden Source zu finden.

Man koennte auch sagen die zunehmende Featureritis sorgt dafuer das die 
Wahrscheinlichkeit fuer solche Probleme start ansteigt. Bisher im 
Embedded bereich noch nicht so stark, aber wir holen auf. :-)

Alle Leute denken: Ach, diese Library benutzen ja schon 23425123 Leute, 
also wird sie wohl okay sein, was kann schon passieren. :-D

Olaf

von Oliver S. (oliverso)


Lesenswert?

MaWin schrieb:
> Ein Rust-Programm kann kein UB durch AOOB-Accesses haben. Ein
> Rust-Programm kann keine Data-Races haben.
> Es ist ein riesiger Unterschied, ob man in C++ diese Fehler auch
> vermeiden kann, oder ob diese Fehler in Rust gar nicht möglich sind.

Und die Titanic war unsinkbar.

Solange eine Programmiersprache praktisch relevante Programme erlaubt, 
wird diese Fehler oder Sicherheitslücken zulassen. Solange Menschen 
Programmcode basteln, wird dieser Fehler oder Sicherheitslücken 
enthalten.

Trotzdem ist jeder Fortschritt ein Fortschritt, wenn er sich bewährt.

Oliver

von HabMut (Gast)


Lesenswert?

Es geht gar nicht darum eine utopische perfekte Programmiersprache zu 
schaffen mit der Sicherheitsprobleme unmöglich sind. Ich spreche von 
bedeutenden Verbesserungen und wie hier schon erwähnt wurde, dass ganze 
Kategorien von möglichen Sicherheitsproblemen ausgeschlossen werden.

Mit einem heutigen Auto kann man auch Unfälle bauen. Trotzdem würde ich 
von den Autos der ersten Generation abraten. Weil die noch viele 
Probleme aufweisen die man heute schon gelöst hat.

von DPA (Gast)


Lesenswert?

HabMut schrieb:
> Es geht gar nicht darum eine utopische perfekte Programmiersprache zu
> schaffen mit der Sicherheitsprobleme unmöglich sind. Ich spreche von
> bedeutenden Verbesserungen und wie hier schon erwähnt wurde, dass ganze
> Kategorien von möglichen Sicherheitsproblemen ausgeschlossen werden.

1 oder 2 Kategorien, von unzähligen. Schön und gut, aber ich würde das 
jetzt nicht gleich bedeutend nennen. Und wenn man bedenkt was für ein 
Krampf es sein kann, Rust zu schreiben, im Vergleich zu anderen sicheren 
Sprachen wie z.B. Java und Python, zweifle ich doch stark daran, dass 
sich das lohnt.

von MaWin (Gast)


Lesenswert?

Oliver S. schrieb:
> Und die Titanic war unsinkbar.
> Solange eine Programmiersprache praktisch relevante Programme erlaubt,
> wird diese Fehler oder Sicherheitslücken zulassen. Solange Menschen
> Programmcode basteln, wird dieser Fehler oder Sicherheitslücken
> enthalten.

Aber eben keine UB durch AOOB-Zugriffe und auch keine Data-Races.
Generell gibt es gar keine UB in Safe-Rust. Rust ist in dieser Hinsicht 
tatsächlich "unsinkbar".

UB/AOOB und Data-Races sind für einen sehr großen, wenn nicht den 
größten, Teil der Sicherheitslücken in Software verantwortlich.

DPA schrieb:
> 1 oder 2 Kategorien, von unzähligen.

Nein. Die relevantesten von unzähligen.

DPA schrieb:
> Und wenn man bedenkt was für ein
> Krampf es sein kann, Rust zu schreiben,

Warum? Kannst du das etwas näher erläutern, was hier "ein Krampf" sein 
soll?

> im Vergleich zu anderen sicheren
> Sprachen wie z.B. Java und Python,

Weder Java noch Python bieten zum Beispiel die Garantie der Abwesenheit 
von Data-Races.

Ich finde es auch gar nicht angebracht Rust mit Python zu vergleichen.
Das sind zwei völlig verschiedene Sprachen mit völlig verschiedenen 
Einsatzgebieten.
Rust hat gar nicht den Anspruch Python zu ersetzen.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.