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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von MaWin (Gast)


Lesenswert?

Daniel A. schrieb:
> Nutzer von Gentoo & co. tun mir jetzt schon leid.

Die tun mir schon länger leid. Nicht erst, seit es Rust gibt.
SCNR.

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>> dann dürfte der Punkt
>> erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen
>> geschriebener Bibliotheken nicht mehr so wichtig ist.
>
> Warum sollte man den Punkt anstreben wollen?
"unsafe"
> Was hat das überhaupt mit Rust zu tun? Rust ist gut interoperabel mit
> anderen Sprachen. By Design.
"unsafe"
> In Gegensatz zu C. C ist nur mit C
> kompatibel. Deshalb muss sich der Rest der Welt darum kümmern mit C
> kompatibel zu sein. Und das tut Rust sehr gut. Heute.
"unsafe"

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> Für Rust wurde ja zumindest gesagt, dass es mit einer C-Umwelt klar
> kommt. Muss es eigentlich auch, denn bis mal alles Wichtige in Rust
> verfügbar ist, werden schon noch ein paar Jahrzehnte vergehen.

"zumindest gesagt"
"muss es eigentlich"

wurde schon sooo oft hier geschrieben - warum vermuten/fabulieren?

Rust kann direkt mit C gelinkt werden

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


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>> dann dürfte der Punkt
>> erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen
>> geschriebener Bibliotheken nicht mehr so wichtig ist.
>
> Warum sollte man den Punkt anstreben wollen?

Es war die Antwort auf deine Frage. Wenn du der Meinung bist, dass das 
gar nicht anstrebenswert ist, dann hättest du dir deine Frage auch 
sparen können.

> In Gegensatz zu C. C ist nur mit C
> kompatibel.

Wenn du derartige Äußerungen weglassen würdest, würde das deiner 
Glaubwürdigkeit gut zu Gesicht stehen. So tust du Rust einfach keinen 
Gefallen, weil sich jeder sagt: "Wenn deren Fanboys alle so sind, will 
ich damit nichts zu tun haben."

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


Lesenswert?

cppbert3 schrieb:
> wurde schon sooo oft hier geschrieben - warum vermuten/fabulieren?

Ich vermute oder fabuliere nicht, habe es nur selbst nicht verifiziert. 
Daher als Aussage anderer kenntlich gemacht.

Aber darum ging es gar nicht, sondern um deine Behauptung, dass es keine 
Intention gewesen wäre, dass C via Linker mit anderen Sprachen zusammen 
arbeitet. Die entbehrt jeglicher Grundlage.

von cppbert3 (Gast)


Lesenswert?

Mombert H. schrieb:
> MaWin schrieb:
>> Jörg W. schrieb:
>>> dann dürfte der Punkt
>>> erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen
>>> geschriebener Bibliotheken nicht mehr so wichtig ist.
>>
>> Warum sollte man den Punkt anstreben wollen?
> "unsafe"
>> Was hat das überhaupt mit Rust zu tun? Rust ist gut interoperabel mit
>> anderen Sprachen. By Design.
> "unsafe"
>> In Gegensatz zu C. C ist nur mit C
>> kompatibel. Deshalb muss sich der Rest der Welt darum kümmern mit C
>> kompatibel zu sein. Und das tut Rust sehr gut. Heute.
> "unsafe"

das ist doch jedem absolut klar, oder?
und selbst wenn nicht, 5min Rust Doku lesen und aufhören zu vermuten

wie soll Rust den bitte externe Abhängigkeiten safe einbinden?
Rust ist eine Systemsprache die nicht an jeder Ecke Prüfcode einbaut und 
auch nur deshalb überhaupt für Kernel-Entwicklung und High-Performanz 
relevant sein kann

diese episch tiefen Diskussionen über Kompiletime/Statische-Prüfbarkeit 
usw. scheitert hier häufig daran das irgendwelche Leute denke das 
Safe-Rust meint das alles geprüft wird oder Safe-Rust meint es sollte 
dann aber auch keine Fehler mehr geben - das ist doch 
Mathematisch/Systemisch gar nicht möglich - und auch die Rust Leute 
können nicht die Natur der Software-Probleme per se lösen sondern nur 
stark abschwächen

viele Leute finde "abschwächen" ist schon toll genug - auch wenn viele 
der Pro-Entwickler hier das 0 nachvollziehen können - weil ihr Code ja 
keine Fehler hat, oder ihre Team-Mitglieder alle gleich gut sind,...

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> Aber darum ging es gar nicht, sondern um deine Behauptung, dass es keine
> Intention gewesen wäre, dass C via Linker mit anderen Sprachen zusammen
> arbeitet. Die entbehrt jeglicher Grundlage.

das ist doch jedem Entwickler 100% klar, oder?
warum hier immer alle davon ausgehen das der Gesprächspartner nur 30% 
von der Medaille kennt?

Genau diese Denke führt hier zu diesen endlosen Tiefen-Diskussionen über 
banale Themen - Kompiletimeprüfung, Sanitizer, Zertifizierung, 
Entwicklungsprozesse - das sind alles alte Hüte die jeder kann und macht 
- und wenn man das dann so überdeutlich ausdrückt kommt hier jeder und 
erklärt wie relevant die Themen sind - als wäre das irgendjemanden nicht 
klar

Es ist nur einfach völlig unrelevant für den jetzigen Entwicklungstand 
von Rust - und war es auch vor Jahrzehnten für C/C++ und alle anderen 
jungen Programmiersprachen

und jetzt hört doch bitte auf immer in diesen Micro-Themen zu rotieren

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
>> In Gegensatz zu C. C ist nur mit C kompatibel.
> Wenn du derartige Äußerungen weglassen würdest, würde das deiner
> Glaubwürdigkeit gut zu Gesicht stehen.

Ach? Mit welchen Sprachen ist C denn so kompatibel?
Und wie sieht das C-Konstrukt aus, mit dem man z.B. angibt, dass 
Funktion X ein zur Sprache Y kompatibles ABI erhalten soll?
Ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind, 
und nicht umgekehrt?

Jörg W. schrieb:
> So tust du Rust einfach keinen
> Gefallen, weil sich jeder sagt: "Wenn deren Fanboys alle so sind, will
> ich damit nichts zu tun haben."

Wenn ein Programmierer seine Wahl der Programmiersprache von pseudonymen 
Posts von MaWin auf Mikrocontroller.net abhängig macht, dann ist diesem 
Programmierer eh nicht mehr zu helfen.

von Mombert H. (mh_mh)


Lesenswert?

cppbert3 schrieb:
> das ist doch jedem absolut klar, oder?
> und selbst wenn nicht, 5min Rust Doku lesen und aufhören zu vermuten
Könntest du kurz erklären was jedem klar ist? Und was die Doku damit zu 
tun hat? Ich verstehe nicht was du hier sagen willst.

cppbert3 schrieb:
> wie soll Rust den bitte externe Abhängigkeiten safe einbinden?
Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg.

Was du mit dem Rest deiner Tirade ausdrücken willst, weiß ich auch 
nicht.

von cppbert3 (Gast)


Lesenswert?

Mombert H. schrieb:
> cppbert3 schrieb:
>> das ist doch jedem absolut klar, oder?
>> und selbst wenn nicht, 5min Rust Doku lesen und aufhören zu vermuten
> Könntest du kurz erklären was jedem klar ist? Und was die Doku damit zu
> tun hat? Ich verstehe nicht was du hier sagen willst.

das externe Abhängigkeiten unsafe eingebunden werden muessen klar ist - 
sonst müsste Rust entweder sau langsam sein (wegen Prüfungen) oder 
irgendein magisches Konzept haben unsafes safe zu machen

> cppbert3 schrieb:
>> wie soll Rust den bitte externe Abhängigkeiten safe einbinden?
> Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg.

jetzt verstehe ich dich nicht - d.h. alles in Rust schreiben???
wie soll ich sonst die Abhängigkeiten los werden?

> Was du mit dem Rest deiner Tirade ausdrücken willst, weiß ich auch
> nicht.

ist nicht so schlimm, dauert noch ein bisschen

von MaWin (Gast)


Lesenswert?

Mombert H. schrieb:
> Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg.

Nein, "müssen" sie nicht.
Warum sollten sie das "müssen"?
Eine externe Bibliothek ist exakt genau so zu handhaben, wie 
unsafe-Blöcke in Rust. Da gibt es sogar ein Buch drüber, wenn du wissen 
willst, wie das geht:
https://doc.rust-lang.org/nomicon/  (work in progress)

Es ist doch völlig weltfremd anzunehmen, dass plötzlich alle Software 
der Welt nur noch in Rust geschrieben werden wird.

von MaWin (Gast)


Lesenswert?

cppbert3 schrieb:
> sonst müsste Rust entweder sau langsam sein (wegen Prüfungen)

Ich dachte wir hätten abschließend geklärt, dass Safe-Rust im Mittel 
nicht langsamer ist als äquivalenter sicherer C-Code? Das ist ein 
Rust-Designziel.

von Mombert H. (mh_mh)


Lesenswert?

cppbert3 schrieb:
> Mombert H. schrieb:
>> cppbert3 schrieb:
>>> das ist doch jedem absolut klar, oder?
>>> und selbst wenn nicht, 5min Rust Doku lesen und aufhören zu vermuten
>> Könntest du kurz erklären was jedem klar ist? Und was die Doku damit zu
>> tun hat? Ich verstehe nicht was du hier sagen willst.
>
> das externe Abhängigkeiten unsafe eingebunden werden muessen klar ist -
> sonst müsste Rust entweder sau langsam sein (wegen Prüfungen) oder
> irgendein magisches Konzept haben unsafes safe zu machen
Ok, was genau hat das mit dem ursprünglich (und natürlich von dir 
ausgelassenen) Beitrag zu tun, auf den du geantwortet hast?

>> cppbert3 schrieb:
>>> wie soll Rust den bitte externe Abhängigkeiten safe einbinden?
>> Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg.
>
> jetzt verstehe ich dich nicht - d.h. alles in Rust schreiben???
> wie soll ich sonst die Abhängigkeiten los werden?
Wtf?

>> cppbert3 schrieb:
>> Was du mit dem Rest deiner Tirade ausdrücken willst, weiß ich auch
>> nicht.
>
> ist nicht so schlimm, dauert noch ein bisschen
...

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> cppbert3 schrieb:
>> sonst müsste Rust entweder sau langsam sein (wegen Prüfungen)
>
> Ich dachte wir hätten abschließend geklärt, dass Safe-Rust im Mittel
> nicht langsamer ist als äquivalenter sicherer C-Code? Das ist ein
> Rust-Designziel.

das ist mir klar - ich fragte mich nur weiso Mombert H. überall unsafe 
geschrieben hatte in seinem Post - als wäre das was schlechtes, und dann 
meinte wir müssen die "Abhängigkeiten los werden" - aber laut seinem 
letzten Post "ohne neu schreiben in Rust" - keine Ahnung was er 
überhaupt meint

von cppbert3 (Gast)


Lesenswert?

Mombert H. schrieb:
>> das externe Abhängigkeiten unsafe eingebunden werden muessen klar ist -
>> sonst müsste Rust entweder sau langsam sein (wegen Prüfungen) oder
>> irgendein magisches Konzept haben unsafes safe zu machen
> Ok, was genau hat das mit dem ursprünglich (und natürlich von dir
> ausgelassenen) Beitrag zu tun, auf den du geantwortet hast?
>
>>> cppbert3 schrieb:
>>>> wie soll Rust den bitte externe Abhängigkeiten safe einbinden?
>>> Überhaupt nicht, deswegen müssen die Abhängigkeiten ja weg.
>>
>> jetzt verstehe ich dich nicht - d.h. alles in Rust schreiben???
>> wie soll ich sonst die Abhängigkeiten los werden?
> Wtf?

ich habe direkt auf einen Post geantwortet wo du überall "unsafe" 
hingeschrieben hast und ich mich gewundert hatte wie man sonst externen 
Code einbinden soll auf den das Rust Sicherheitskonzept keinen Einfluss 
hat

dann kam dein Kommentar mit den "deswegen müssen die Abhängigkeiten ja 
weg" womit ich völlig verloren bin und dachte du meinst das die externen 
Abhängigkeiten in Rust geschrieben werden müssen - weil ich sonst nicht 
verstehe was das "Abhängigkeiten ja weg" in diesem Kontext sonst 
bedeuten könnte

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


Lesenswert?

MaWin schrieb:
> ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind

Nein, sind sie nicht.

Mit deiner Argumentation ist wohl jede Sprache nur mit sich selbst 
kompatibel, denn sie kennt Konstrukte, die sich nicht in einer anderen 
ausdrücken lassen. Ein Pascal-Array-Argument kannst du beispielsweise in 
C nicht ausdrücken, denn es übergibt außer der Adresse auch seinen 
Indexbereich an den Aufgerufenen. Eine variadische Argumentliste in C 
wirst du wiederum in Pascal nicht aufgedröselt bekommen.

Kompatibilität ist folglich immer der kleinste gemeinsame Nenner 
zwischen beiden Seiten.

von MaWin (Gast)


Lesenswert?

cppbert3 schrieb:
> ich fragte mich nur weiso Mombert H. überall unsafe
> geschrieben hatte in seinem Post - als wäre das was schlechtes,

Ja. Das ist richtig. Unsafe-Codeteile, unter die auch externe 
Bibliotheken fallen, sind nicht schlecht. Es ist gar nicht so, dass 
Rustentwickler jetzt plötzlich losrennen und alle Unsafe-Teile 
eliminieren wollen. Ganz im Gegenteil. Unsafe-Code ist in Ordnung. Es 
bedeutet nur, dass dieser Code erheblich mehr Review und Testing 
erfahren muss.

Es ist ja auch gar nicht alles in Safe-Rust formulierbar, was formuliert 
werden muss. Je näher man an die Hardware kommt, desto mehr 
unsafe-Blöcke werden notwendig werden. Das Ziel ist es jedoch, diese 
unsafe-Blöcke in entsprechenden Safe-Rust-Modulen zu wrappen. Und genau 
das passiert auch mit externen Bibliotheken.

von Daniel A. (daniel-a)


Lesenswert?

MaWin schrieb:
> Ach? Mit welchen Sprachen ist C denn so kompatibel?
> Und wie sieht das C-Konstrukt aus, mit dem man z.B. angibt, dass
> Funktion X ein zur Sprache Y kompatibles ABI erhalten soll?

Wie soll den C die Datentypen und sonstigen Eigenheiten zukünftiger 
Sprachen unterstützen? Und wozu? C ist sehr alt, stabil, simpel, und 
bietet alles nötige, damit andere Programme mit ihm interoperieren 
können. Das ABI ist auch überall relative stabil und gut definiert. 
Zusammen mit seiner Verbreitung ist es daher heute mit so ziemlich jeder 
Sprache kompatibel. Oft verwendet man es sogar, um verschiedene Sprachen 
verbinden zu können. Es bietet sich in seiner jetzigen Form und 
Verbreitung dafür gerade zu an.

Auch wenn es dank historischer & designtechnischer Gründe diese 
Interopabilität quasi gratis bekommen hat, das ändert aber nichts daran, 
dass sie vorhanden ist.

Ausserdem, ist die ABI von Rust für die diversen Platformen mittlerweile 
endlich mal Stabil & Dokumentiert? Wobei, da müsste man vermutlich erst 
mal die Sprache selbst standardisieren? Wie soll man denn so damit 
überhaupt vollständig kompatibel sein können, im sinne von all seine 
Datentypen und APIs direkt nutzen können?

Man könnte das also umkehren. C erlaubt es anderen Sprachen recht 
einfach, zu ihm kompatibel zu sein. Aber ist das bei Rust überhaupt 
möglich?

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> MaWin schrieb:
>> ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind
>
> Nein, sind sie nicht.
>
> Mit deiner Argumentation ist wohl jede Sprache nur mit sich selbst
> kompatibel, denn sie kennt Konstrukte, die sich nicht in einer anderen
> ausdrücken lassen. Ein Pascal-Array-Argument kannst du beispielsweise in
> C nicht ausdrücken, denn es übergibt außer der Adresse auch seinen
> Indexbereich an den Aufgerufenen. Eine variadische Argumentliste in C
> wirst du wiederum in Pascal nicht aufgedröselt bekommen.
>
> Kompatibilität ist folglich immer der kleinste gemeinsame Nenner
> zwischen beiden Seiten.

MaWin wollte sicherlich eher zum Ausdruck bringen das der Teil den wir 
alle kennen von C der meistgenutzte gemeinsame Nenner ist an dem sich 
viele orientieren - und ja das passt auch für vieles von Pascal - aber 
man spricht dann trotzdem oft von der C Kompatibilität - obwohl auch 
Sprachen die älter sind als C schon "C-Kompatible" waren

Aber wie immer die Frage: Ist das wirklich Themen relevant?

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
>> ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind
> Nein, sind sie nicht.

Krass, wie du krampfhaft versuchst deine falsche Argumentation aufrecht 
zu erhalten.
C++ ist also nicht kompatibel zu C? extern "C"?
Rust ist also nicht kompatibel zu C? Auch wenn man structs und 
Funktionen explizit die C-ABI geben kann?

> Kompatibilität ist folglich immer der kleinste gemeinsame Nenner
> zwischen beiden Seiten.

Und C trägt aktiv exakt gar nichts dazu bei kompatibel zu irgendetwas zu 
sein.
C ist einfach nur C, so wie es ist.
C ist der kleinste gemeinsame Nenner, weil seine ABI so primitiv ist und 
weil es schlicht älter ist als alle anderen aktiv genutzten Sprachen.
Es gibt kein C-Konstrukt, mit dem man die ABI auf die einer anderen 
Sprache anpassen kann.

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> Es ist gar nicht so, dass
> Rustentwickler jetzt plötzlich losrennen und alle Unsafe-Teile
> eliminieren wollen. Ganz im Gegenteil. Unsafe-Code ist in Ordnung. Es
> bedeutet nur, dass dieser Code erheblich mehr Review und Testing
> erfahren muss.

viele denken man müsste alles nach Rust portieren
keine Ahnung wo dieser (schon dem Wahnsinn nahe stehendem) Irrglaube 
herkommt

sowas kenne ich nur von Anfängern oder Nur-eine-Sprach-Evangelisten (die 
zum Glück immer weniger im Business anzutreffen sind)

von cppbert3 (Gast)


Lesenswert?

Daniel A. schrieb:
> Es bietet sich in seiner jetzigen Form und
> Verbreitung dafür gerade zu an.

deswegen wird es ja auch direkt von Rust supportet, weil das schon so 
viele sprechen :)

Daniel A. schrieb:
> Aber ist das bei Rust überhaupt
> möglich?

gerade nicht weil die höherwertigen Konzepte sich recht
schwerlich durch eine ABI pressen lassen ohne die Performanzvorteile zu 
verlieren - wie bekommt man ein Kompiletime Ownership-Konzept durch eine 
Library/Dll-Grenze - nicht so einfach

Ich könnte mir vorstellen das sie eine Rust zu Rust ABI hinbekommen
aber eine Rust zu C ABI mit allen Rust-Features wird echt schwer

ist aber vergleichbar mit den Schwierigkeiten C++, C#, Java Konzepte mit 
C zu verbinden

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>>> ist es nicht eher so, dass alle anderen Sprachen zu C kompatibel sind
>> Nein, sind sie nicht.
>
> Krass, wie du krampfhaft versuchst deine falsche Argumentation aufrecht
> zu erhalten.
> C++ ist also nicht kompatibel zu C? extern "C"?
> Rust ist also nicht kompatibel zu C? Auch wenn man structs und
> Funktionen explizit die C-ABI geben kann?

Jörg hat technisch schon recht mit seinem kleinsten gemeinsamen Nennen 
was die Datenbereite/Typen angeht (das ist aber eher ein 
Hardware-Standard)
aber spätestens bei Calling-Conventions hat MaWin recht - da ist es das 
C-Standard(Subset) mit cdecl das supported wird oder auch z.B. die 
typischen C-Strings

die meisten Sprachen sprechen auch explizit von C Kompatibilität
ansonsten sind alle Sprache erstmal nur zu sich selbst kompatibel (oder 
dem C-Standard-Subset)

im Detail geht es bei der Kompatiblität nur um die Stabilität der ABI - 
ob die sich jetzt C oder whatever schimpft ist unrelevant

von cppbert3 (Gast)


Lesenswert?

cppbert3 schrieb:
> Ich könnte mir vorstellen das sie eine Rust zu Rust ABI hinbekommen

also z.B. gibt es zwei Rust DLLs (A und B) die unterschiedliche Heaps 
haben
und wenn die B-DLL Heap-Daten von der A-DLL ownen will das es dann eine 
besondere Form von Big/Fat-Pointer oder sowas gibt und es laut der ABI 
klar ist das es dann Performanprobleme geben kann wenn die Heap-Daten 
Löschung an A delegiert werden muss - oder eine Art 
Copy-on-transfer-Konzept

Alles nicht sehr einfach und schwer generisch definierbar (soll es 
leicht sein, performant sein, etc.)

ähnlich wie der Design-Trouble mit Async - nur noch viel komplizierter

von cppbert3 (Gast)


Lesenswert?

cppbert3 schrieb:
> also z.B. gibt es zwei Rust DLLs (A und B) die unterschiedliche Heaps
> haben

das Problem ist vergleichbar mit std::vector über DLL-Grenze mit 
unterschiedlichen Heaps

aber ich habe immer noch die Hoffnung das Rust hier auch irgendwann mal 
mit einem besseren Konzept kommt als wie bisher:

-Alles nur per Value
-Alles auf eine C-artige API runterbrechen
-Alles mit Interfaces auf dem Heap/Ref-Counted

ohne unterschiedliche Heaps gibt es keine Probleme

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


Lesenswert?

cppbert3 schrieb:
> obwohl auch Sprachen die älter sind als C schon "C-Kompatible" waren

FORTRAN übergibt alles in einer Parametertabelle, alle Parameter sind 
dort per Referenz übergeben – zumindest das FORTRAN, was älter ist als 
C. (Auf der PDP-11 wurde die Adresse der Tabelle in R5 übergeben.) Weiß 
nicht, ob sie inzwischen auch andere Aufrufkonventionen haben.

Mit üblichen C-Konventionen ist das nicht kompatibel …

> Aber wie immer die Frage: Ist das wirklich Themen relevant?

Sicher nicht, aber ich habe die Diskussion, alles würde sich nur nach C 
richten müssen, auch nicht begonnen.

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
>> Aber wie immer die Frage: Ist das wirklich Themen relevant?
>
> Sicher nicht, aber ich habe die Diskussion, alles würde sich nur nach C
> richten müssen, auch nicht begonnen.

aber sie auch nicht gestoppt - und jetzt auch noch ne Uralt PDP-11 mit 
ins Feld geworfen :)

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
>> Aber wie immer die Frage: Ist das wirklich Themen relevant?
>
> Sicher nicht, aber ich habe die Diskussion, alles würde sich nur nach C
> richten müssen, auch nicht begonnen.

und dir haben die 2.98% die sich nicht nach C richten gereicht um die 
Diskussion weiter zu befeuern - meinetwegen auch 13.445% aber mehr 
gestehe ich dir da nicht an Relevanz zu :)

von Roland F. (rhf)


Lesenswert?

Hallo,
cppbert3 schrieb:
> und jetzt hört doch bitte auf immer in diesen Micro-Themen zu rotieren

Was sind denn dann für dich "Macro-Themen" über die man diskutieren 
sollte?

rhf

von MaWin (Gast)


Lesenswert?

Roland F. schrieb:
> Was sind denn dann für dich "Macro-Themen" über die man diskutieren
> sollte?

Rust-Macros, zum Beispiel.
Sehr spannendes Thema.

von S. R. (svenska)


Lesenswert?

Ich war jetzt mal ein paar Wochen weg und ein interessanteste Punkt der 
Diskussion war für mich, dass
(a) der Rust-Compiler fehlerfrei ist (d.h. entsprechend der 
Sprachdefinition arbeitet);
(b) die vielen Compilerversionen und -änderungen daher irrelevant sind;
(c) man in Rust garnicht fehlerhaft programmieren kann, weil die Sprache 
Fehler schon vorher verhindert;
(d) die Kompatiblität zu älteren Sprachstandards (nach Spezifikation) 
ausschließlich durch den Compiler sichergestellt wird;
(e) Cargo und Rust überhaupt nichts miteinander zu tun haben.

Ich hab nichts gegen Rust. Nur gegen tightly-coupled-garbage.

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> Nur gegen tightly-coupled-garbage

ja, dann höre bitte damit auf. Danke.

von cppbert3 (Gast)


Lesenswert?

bevor hier wieder alle schreien

https://www.golem.de/news/open-source-entwickler-sabotiert-eigene-vielfach-genutzte-npm-pakete-2201-162299.html

das ist natürlich eine Gefahr - aber ich denke trotzdem das Rust oder 
auch npm oder auch vcpkg dafür einen dauerhaft sinnvolle Lösung finden 
müssen

in diesem Fall ist aber scheinbar ein "verlässlicher" auf die dunkle 
Seite der Macht konvertiert - um so mehr das passiert um so eher gibt es 
sinnvolle Diskussionen wie man automatische und sichere 
Depenency-Management bauen kann

mir ist klar das es keine 100% Lösung gibt, aber vielleicht ergeben sich 
ja zwitter-Strategien die doch ganz gut funktionieren

von MaWin O. (mawin_original)


Lesenswert?

cppbert3 schrieb:
> das ist natürlich eine Gefahr - aber ich denke trotzdem das Rust oder
> auch npm oder auch vcpkg dafür einen dauerhaft sinnvolle Lösung finden
> müssen

Naja, ich glaube diese Lösung, so gut das eben geht, bietet crates.io 
bereits.

Zitat Artikel:
> durch das Löschen von Paketen.

Das geht auf crates.io nicht.

Natürlich ist man grundsätzlich davon abhängig, dass ein Entwickler 
nicht durchdreht und plötzlich Mist baut. Aber auf crates.io gilt das 
nur für neue Versionen. Wenn man bereits eine Version verwendet, dann 
garantiert crates.io, dass genau diese Version dauerhaft und unverändert 
bereitgestellt werden wird. Daran kann auch der Autor nichts ändern.

Das zusammen mit Cargo.lock bedeutet, dass es nicht passieren kann, 
dass die eigene SW sich plötzlich anders verhält oder gar Schadsoftware 
einfließen kann.
Um neue Dependency-Versionen einzupflegen, ist immer eine bewusste 
Interaktion des Entwicklers per cargo update notwendig.

von Unterstrich (Gast)


Lesenswert?

cppbert3 schrieb:
> um so mehr das passiert um so eher gibt es
> sinnvolle Diskussionen wie man automatische und sichere
> Depenency-Management bauen kann

Erst machen - dann denken.

Sehr gut.

von Mombert H. (mh_mh)


Lesenswert?

MaWin O. schrieb:
> Aber auf crates.io gilt das
> nur für neue Versionen. Wenn man bereits eine Version verwendet, dann
> garantiert crates.io, dass genau diese Version dauerhaft und unverändert
> bereitgestellt werden wird. Daran kann auch der Autor nichts ändern.

Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen 
und Urhaberrechte eingehalten werden? Oder wie wird es gehandhabt, wenn 
gegen Rechte verstoßen wird?

von MaWin O. (mawin_original)


Lesenswert?

Mombert H. schrieb:
> Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen
> und Urhaberrechte eingehalten werden?

Ehm, warum sollte es?

> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird?

Das ist, wie immer, das Problem des Autors. Also sollte er so etwas 
nicht tun.

Deine Nebelkerze habe ich als solche erkannt.

von S. R. (svenska)


Lesenswert?

Mombert H. schrieb:
> Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen
> und Urhaberrechte eingehalten werden?

Nein. Es ist Aufgabe des Paketautors, seinen Code zu schreiben, zu 
paketieren und zu veröffentlichen. Das Repository hat damit nichts zu 
tun.

Es ist Aufgabe aller Nutzer des Paketes, das Paket selbst sowie 
sämtliche zukünftigen Updates auf Lizenzverstöße, Fehler, Böswilligkeit 
und andere Rechtswidrigkeiten zu überprüfen, bevor sie in der eigenen 
Software verwendet werden.

Praktisch also ein "update all please", gelegentlich gefolgt von "run my 
testsuite", wie man bei npm gerade schön sieht. (Sind ja nicht alle 
direkt betroffen. Nur viele.)

Dieses Problem (oder ein Äquivalent) besteht grundsätzlich bei allen auf 
schnelle Releasezyklen ausgelegten Systemen. Cargo und crates.io sind da 
nicht besser oder schlechter, und die Grundidee kritisieren zählt in 
großen Teilen der Informatik als Gotteslästerung.

MaWin O. schrieb:
>> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird?
> Das ist, wie immer, das Problem des Autors. Also sollte er so etwas
> nicht tun.

Falsch. Es ist ein Problem des Nutzers des Pakets, nicht des Autors des 
Pakets. Und wenn Pakete tatsächlich nicht gelöscht werden können, dann 
ist das sowieso ein interessantes Phänomen.

Vielleicht brauchen wir, wie von cppbert3 vorgeschlagen, einfach mehr 
Sabotage. Damit kriegen wir die Probleme alle klein.

von DPA (Gast)


Lesenswert?

S. R. schrieb:
> Vielleicht brauchen wir, wie von cppbert3 vorgeschlagen, einfach mehr
> Sabotage. Damit kriegen wir die Probleme alle klein.

Pass auf, was du dir wünschst!

Beitrag "Re: Rust - ist das hier um zu bleiben?"

von MaWin O. (mawin_original)


Lesenswert?

S. R. schrieb:
>> Das ist, wie immer, das Problem des Autors. Also sollte er so etwas
>> nicht tun.
> Falsch. Es ist ein Problem des Nutzers des Pakets, nicht des Autors des
> Pakets.

Falsch?
Es ist vielmehr das Problem des Autors und des Nutzers. Deshalb war 
meine Aussage nicht falsch, sondern richtig.

> und die Grundidee kritisieren zählt in
> großen Teilen der Informatik als Gotteslästerung.

An einer sachlichen Diskussion ist jeder interessiert.

> Dieses Problem (oder ein Äquivalent) besteht grundsätzlich bei allen auf
> schnelle Releasezyklen ausgelegten Systemen. Cargo und crates.io sind da
> nicht besser oder schlechter

Cargo ist auf vieles ausgelegt. Aber mit Sicherheit nicht auf die 
schnelle Änderungen von Dependency-Versionen.
Ganz im Gegenteil. Cargo lockt the Dependency-Versionen, wie ich bereits 
beschrieben habe, fest.

von Mombert H. (mh_mh)


Lesenswert?

MaWin O. schrieb:
> Mombert H. schrieb:
>> Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen
>> und Urhaberrechte eingehalten werden?
> Ehm, warum sollte es?
>> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird?
> Das ist, wie immer, das Problem des Autors. Also sollte er so etwas
> nicht tun.

S. R. schrieb:
> Es ist Aufgabe aller Nutzer des Paketes, das Paket selbst sowie
> sämtliche zukünftigen Updates auf Lizenzverstöße, Fehler, Böswilligkeit
> und andere Rechtswidrigkeiten zu überprüfen, bevor sie in der eigenen
> Software verwendet werden.

Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn 
dort veröffentliche Software gegen geltendes Recht verstößt?

von cppbert3 (Gast)


Lesenswert?

Mombert H. schrieb:
> MaWin O. schrieb:
>> Mombert H. schrieb:
>>> Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen
>>> und Urhaberrechte eingehalten werden?
>> Ehm, warum sollte es?
>>> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird?
>> Das ist, wie immer, das Problem des Autors. Also sollte er so etwas
>> nicht tun.
>
> S. R. schrieb:
>> Es ist Aufgabe aller Nutzer des Paketes, das Paket selbst sowie
>> sämtliche zukünftigen Updates auf Lizenzverstöße, Fehler, Böswilligkeit
>> und andere Rechtswidrigkeiten zu überprüfen, bevor sie in der eigenen
>> Software verwendet werden.
>
> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn
> dort veröffentliche Software gegen geltendes Recht verstößt?

ob crates.io durch sein Verhalten Rechtsbruch begeht hat doch mit der 
Sprache Rust absolut gar nicht zu tun - oder um was geht es dir?

wie handhaben das vpckg, Conan, npm und die vielen anderen Package 
Manager - find das doch mal raus und berichtet hier

von Mombert H. (mh_mh)


Lesenswert?

cppbert3 schrieb:
> Mombert H. schrieb:
>> MaWin O. schrieb:
>>> Mombert H. schrieb:
>>>> Crates.io prüft also bevor etwas veröffentlicht wird, ob alle Lizenzen
>>>> und Urhaberrechte eingehalten werden?
>>> Ehm, warum sollte es?
>>>> Oder wie wird es gehandhabt, wenn gegen Rechte verstoßen wird?
>>> Das ist, wie immer, das Problem des Autors. Also sollte er so etwas
>>> nicht tun.
>> S. R. schrieb:
>>> Es ist Aufgabe aller Nutzer des Paketes, das Paket selbst sowie
>>> sämtliche zukünftigen Updates auf Lizenzverstöße, Fehler, Böswilligkeit
>>> und andere Rechtswidrigkeiten zu überprüfen, bevor sie in der eigenen
>>> Software verwendet werden.
>> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn
>> dort veröffentliche Software gegen geltendes Recht verstößt?
> ob crates.io durch sein Verhalten Rechtsbruch begeht hat doch mit der
> Sprache Rust absolut gar nicht zu tun - oder um was geht es dir?
Was willst du jetzt mit der Sprache, oder ist cargo und crates.io 
plötzlich doch Teil der Sprache?

> wie handhaben das vpckg, Conan, npm und die vielen anderen Package
> Manager - find das doch mal raus und berichtet hier
Sie werden Pakete, die gegen die Regeln verstoßen, löschen. Aber das 
geht ja laut MaWin auf crates.io nicht.

von cppbert3 (Gast)


Lesenswert?

Mombert H. schrieb:
>> ob crates.io durch sein Verhalten Rechtsbruch begeht hat doch mit der
>> Sprache Rust absolut gar nicht zu tun - oder um was geht es dir?
> Was willst du jetzt mit der Sprache, oder ist cargo und crates.io
> plötzlich doch Teil der Sprache?
>> wie handhaben das vpckg, Conan, npm und die vielen anderen Package
>> Manager - find das doch mal raus und berichtet hier
> Sie werden Pakete, die gegen die Regeln verstoßen, löschen. Aber das
> geht ja laut MaWin auf crates.io nicht.

wenn dich Rust interessiert dann diskutier das Lösch-Problem direkt mit 
den crates.io Leuten ansonsten spar es dir doch mit MaWin zum rum zu 
spielen, was bringt das hier?

von MaWin O. (mawin_original)


Lesenswert?

Mombert H. schrieb:
> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn
> dort veröffentliche Software gegen geltendes Recht verstößt?

Nein. Das hat auch niemand geschrieben.

Mombert H. schrieb:
> Sie werden Pakete, die gegen die Regeln verstoßen, löschen. Aber das
> geht ja laut MaWin auf crates.io nicht.

Nicht von AUTOR selbst löschbar. Lies bitte meine Beiträge richtig.

Selbstverständlich haben die Administratoren von crates.io für den 
absoluten Sonderfall, dass jemand rechtswidriges Material hochlädt, 
immer noch den superuser-Zugriff auf die Datenbank.

von Mombert H. (mh_mh)


Lesenswert?

MaWin O. schrieb:
> Mombert H. schrieb:
>> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn
>> dort veröffentliche Software gegen geltendes Recht verstößt?
> Nein. Das hat auch niemand geschrieben.
> Mombert H. schrieb:
>> Sie werden Pakete, die gegen die Regeln verstoßen, löschen. Aber das
>> geht ja laut MaWin auf crates.io nicht.
>
> Nicht von AUTOR selbst löschbar. Lies bitte meine Beiträge richtig.
Und was passiert, wenn der AUTOR sich and die Administatoren von 
crates.io wendet und sagt, "Ich habe nicht die Rechte an dieser 
Software. Bitte löscht sie."?

von MaWin O. (mawin_original)


Lesenswert?

Mombert H. schrieb:
> Und was passiert, wenn der AUTOR sich and die Administatoren von
> crates.io wendet und sagt, "Ich habe nicht die Rechte an dieser
> Software. Bitte löscht sie."?

Ich weiß es nicht, aber da wird sicher nach vernünftigem menschlichem 
Ermessen drauf reagiert.
Und damit beende ich jetzt diese absolut dümmliche und nicht 
zielführende Diskussion.

von cppbert3 (Gast)


Lesenswert?

@MaWin O.

mich würde interessieren wie du das Thema ABI siehst (die C-ABI können 
wir - deswegen würde ich die mal komplett ausblenden)

-wie könnte eine "echte" Rust-ABI aussehen/was sind Herausforderungen
Kann es eine echte Rust-ABI geben oder wird das genau so ein Problem wie 
mit C++ und dem nicht C-Rest?

-irgendeine Vorstellung wie Dlls/Shared Object (mit nicht gemeinsam 
genutzten (Shared-CRT) Heaps diese Rust-ABI nutzen könnten)
mögliche Herausforderung: Owner-Ship-Transfer ueber Heap-Grenzen?

gibt es da irgendwelche Vorstellungen in der Community?

das Thema "echte" ABI und shared objects wird ja noch relativ stark auf 
"wir können ja C konform sein reduziert"

oder denkst du das Rust eher als Inside/Inline-Implementierung genutzt 
werden wird und es einfach nicht so viel Austausch über die oben 
genannten Grenzen geben wird weil alles direkt verlinkt ist?

von cppbert3 (Gast)


Lesenswert?

ein paar Beispiele was so lange wir nicht von nur ein paar Value-Types 
reden ein Problem ist - z.B. in C++

Lib1(std::vector<x>*) <-> Lib2(std::vector<TypeX>*)
(oder DLLs mit shared Heaps)

Probleme:
-Release/Debug Layout Unterschied beim vector

DLL ohne shared Heaps
Dll1(std::vector<x>*) <-> Dll2(std::vector<TypeX>*)

Probleme:
-Release/Debug Layout unterschied beim vector
-vector delete muss an den richtigen Heap gehen

und solche Sachen

Java und C# usw. haben solchen Probleme nicht weil deren Runtime oder 
die eingeschränkten Generics solche ABI Probleme gar nicht erzeugen 
können, es gibt kein echtes Binary-Linking

von S. R. (svenska)


Lesenswert?

MaWin O. schrieb:
> Es ist vielmehr das Problem des Autors und des Nutzers. Deshalb war
> meine Aussage nicht falsch, sondern richtig.

Es ist mein Problem, fremden Code unverifiziert auszuführen. Ob der 
fremde Code überhaupt da hätte sein dürfen, ist ein separates Problem.

Jemandem, der auf einer gleichrangigen Kreuzung von rechts kommt, muss 
ich die Vorfahrt gewähren - auch dann, wenn er rückwärts und falschrum 
aus einer Einbahnstraße kommt. Dass er das selbst nicht darf, ist nicht 
mein Problem.

Wenn eine Firma ein illegales Paket einbindet und damit Geld verdient, 
dann wird die Firma angeklagt und nicht derjenige, der das Paket 
illegalerweise irgendwo hochgeladen hat. Das fällt unter "due 
diligence".

>> Dieses Problem (oder ein Äquivalent) besteht grundsätzlich bei allen auf
>> schnelle Releasezyklen ausgelegten Systemen. Cargo und crates.io sind da
>> nicht besser oder schlechter
>
> Cargo ist auf vieles ausgelegt. Aber mit Sicherheit nicht auf die
> schnelle Änderungen von Dependency-Versionen.

Besser lesen. Ich schrieb "Releasezyklen". Du hast inzwischen mehrfach 
wiederholt festgestellt, dass Cargo nicht automatisch deine 
Versionsnummern aktualisiert, das ist angekommen.

Aber in der Realität macht man regelmäßig ein Update und fertig ist - 
und genau diesen Schritt vereinfacht Cargo, wie auch jeder andere 
Paketmanager. Oft macht man das Update sogar automatisch (für nightlies, 
wann immer ein Update auftritt, etc.), der Sicherheit(slücken) wegen.

Wir leben in einer Welt, in der Abhängigkeiten oft genug im Lockstep 
aktualisiert werden müssen, damit das Gesamtsystem noch funktioniert. 
Besonders, wenn alle Abhängigkeiten statisch in das Programm geklebt 
werden und ohnehin alles neu gebaut werden muss.

Oder willst du ernsthaft argumentieren, dass man Code nie aktualisieren 
müsste und das deswegen kein Problem ist? Wirklich?

Mombert H. schrieb:
> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn
> dort veröffentliche Software gegen geltendes Recht verstößt?

Nein. Aber vor Gericht landet erstmal der Nutzer der Pakete, der dann 
wiederum crates.io auf Schadensersatz verklagen kann. Ich bin mir 
sicher, das Regelwerk von crates.io wird den Schaden dann an den Autor 
weiterreichen.

Beitrag #6940915 wurde von einem Moderator gelöscht.
von Mombert H. (mh_mh)


Lesenswert?

S. R. schrieb:
> Mombert H. schrieb:
>> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn
>> dort veröffentliche Software gegen geltendes Recht verstößt?
>
> Nein. Aber vor Gericht landet erstmal der Nutzer der Pakete, der dann
> wiederum crates.io auf Schadensersatz verklagen kann. Ich bin mir
> sicher, das Regelwerk von crates.io wird den Schaden dann an den Autor
> weiterreichen.
Du bist dir sicher? Basiert dein sicher auf deinem Bauchgefühl oder kann 
man das irgendwo nachlesen? Also beide Teile, dass der Nutzer zuerst vor 
Gericht landet und dass der Nutzer gegenüber der Plattform einen 
Anspruch auf Schadensersatz hat. Wenn ich mir da z.B. "illegale" 
Tauschbörsen für Musik und Filme angucke, läuft das anders.

von cppbert3 (Gast)


Lesenswert?

S. R. schrieb:
> Aber in der Realität macht man regelmäßig ein Update und fertig ist -
> und genau diesen Schritt vereinfacht Cargo, wie auch jeder andere
> Paketmanager. Oft macht man das Update sogar automatisch (für nightlies,
> wann immer ein Update auftritt, etc.), der Sicherheit(slücken) wegen.

du hast vollkommen recht - Rust Cargo erschafft durch die Einfachheit 
schneller diese Dependency Probleme (auch wenn es kein Autoupgrade gibt)
aber was ist die Antwort auf das Problem? einfach niemals Package 
Systeme einsetzen?

Ich finde der grossen Vorteil ist das ich lokal in meiner Firma mein 
eigenes Repository aufbauen kann (in das ich Prozess-Sicher update) und 
innerhalb meiner Firma ist dann eine "gewisse" Sicherheit da

und ja wir alle arbeiten seit Jahren mit Dependencies und wissen wie das 
geht (von händischen bis selbst-gestricktem CMAke/Batch/Python Scripten 
ist alles probiert und im Einsatz) und welche Fallstricke lauern - aber 
trotzdem finde ich das man das Deployment irgendwie vereinfachen muss - 
auch wenn der aktuelle Cargo Stand vielleicht noch nicht perfekt ist 
finde ich das Cargo eine gute Diskussion-Grundlage bietet um diese 
Punkte für die Zukunft zu verbessern

ganz unabhängig von der Sprache Rust

von cppbert3 (Gast)


Lesenswert?

Mombert H. schrieb:
> S. R. schrieb:
>> Mombert H. schrieb:
>>> Ihr beide glaubt also, dass es für crates.io vollkommen egal ist, wenn
>>> dort veröffentliche Software gegen geltendes Recht verstößt?
>>
>> Nein. Aber vor Gericht landet erstmal der Nutzer der Pakete, der dann
>> wiederum crates.io auf Schadensersatz verklagen kann. Ich bin mir
>> sicher, das Regelwerk von crates.io wird den Schaden dann an den Autor
>> weiterreichen.
> Du bist dir sicher? Basiert dein sicher auf deinem Bauchgefühl oder kann
> man das irgendwo nachlesen? Also beide Teile, dass der Nutzer zuerst vor
> Gericht landet und dass der Nutzer gegenüber der Plattform einen
> Anspruch auf Schadensersatz hat. Wenn ich mir da z.B. "illegale"
> Tauschbörsen für Musik und Filme angucke, läuft das anders.

die Antwort ist dann einfach - man darf gar nichts machen, oder?
also kein Cargo kein crates.io - die User müssen das 100% selbst machen

Rechtssicherheit ist ein unklar handhabbares Thema das man nie 
abschließen sauber lösen kann - das ist auch jedem klar - tausend 
Probleme - aber als Lösung einfach gar nichts machen?

was ist das Ziel deiner Kritik?

von cppbert3 (Gast)


Lesenswert?

Microsoft managed in vcpkg auch tausend fremde Dependencies
genau nach dem gleichen Schema wie crates.io
und NPM ist mitlerweile auch von Microsoft - also noch viel mehr solcher 
Dependencies

Ignorieren die deine Sorgen einfach nur deshalb weil die 1000 Anwälte 
drauf werfen können wenn es Probleme gibt?

Einfache Frage: Was macht Microsoft anders als crates.io oder sind die 
einfach genau so unbedarft?

von Mombert H. (mh_mh)


Lesenswert?

cppbert3 schrieb:
> die Antwort ist dann einfach - man darf gar nichts machen, oder?
> also kein Cargo kein crates.io - die User müssen das 100% selbst machen

Das ist ein ziemlich weiter Bogen, den du von MaWins "man kann Pakete 
nicht löschen" zu "man darf garnichts machen" spannst.

cppbert3 schrieb:
> Rechtssicherheit ist ein unklar handhabbares Thema das man nie
> abschließen sauber lösen kann - das ist auch jedem klar - tausend
> Probleme - aber als Lösung einfach gar nichts machen?
Darum ging es mir nie. Es ging immer nur um "man kann nichts löschen"

cppbert3 schrieb:
> was ist das Ziel deiner Kritik?
Welche Kritik meinst du genau?

cppbert3 schrieb:
> Microsoft managed in vcpkg auch tausend fremde Dependencies
> genau nach dem gleichen Schema wie crates.io
> [...]
> Einfache Frage: Was macht Microsoft anders als crates.io oder sind die
> einfach genau so unbedarft?
Ich wusste nicht, dass jeder auf vcpkg.io Pakete veröffentlichen kann. 
Kann man sie dort löschen?

von MaWin O. (mawin_original)


Lesenswert?

cppbert3 schrieb:
> -wie könnte eine "echte" Rust-ABI aussehen/was sind Herausforderungen
> Kann es eine echte Rust-ABI geben oder wird das genau so ein Problem wie
> mit C++ und dem nicht C-Rest?

Ja, das ist ein sehr spannendes und sehr komplexes Thema, von dem ich 
leider viel zu wenig Ahnung habe, um einen qualifizierten Kommentar 
absondern zu können. :)

Aus meinem Bauchgefühl heraus wird eine Library-ABI deutlich 
eingeschränkter sein müssen, als die statisch gebauten 
Crate-Schnittstellen. Ich gehe erst einmal davon aus, dass gar keine 
Compiletime-Ownershiptransfers stattfinden werden, sondern eher etwas 
zur Laufzeit wie Arc/RefCell(+threadsafety).

Wenn du da eine funktionierende Lösung findest, hast du damit sicher das 
Jobticket direkt zu Google und Konsorten gewonnen. ;)

von cppbert3 (Gast)


Lesenswert?

MaWin O. schrieb:
> Wenn du da eine funktionierende Lösung findest, hast du damit sicher das
> Jobticket direkt zu Google und Konsorten gewonnen. ;)

funktionierend ist nicht das Problem - generisch und performant genug 
ist die Herausforderung

von cppbert3 (Gast)


Lesenswert?

Mombert H. schrieb:
> cppbert3 schrieb:
>> Rechtssicherheit ist ein unklar handhabbares Thema das man nie
>> abschließen sauber lösen kann - das ist auch jedem klar - tausend
>> Probleme - aber als Lösung einfach gar nichts machen?
> Darum ging es mir nie. Es ging immer nur um "man kann nichts löschen"

aber was soll MaWin mit dieser Info anfangen - das wäre doch eher was 
für eine Diskussion mit den crates.io Leuten, oder?

MaWin hat mehrfach und deutlich gesagt - es ist noch viel im Fluss - und 
ja nicht alles was crates.io/Cargo macht ist absolut perfekt - das kann 
keine Sprache/Environment sein und so hirnlos kann kein Entwickler sein 
um das zu glauben

aber was du machst ist auf Details rumreiten - auch wenn du das so nicht 
wahrnimmst - und es ist nicht klar zu welchem Zweck du das machst
MaWin juckt deine Argumentation null - und die crates.io/Cargo Leute 
hören sie nur wenn du sie auch dort vorträgst

Selbst wenn du bei MaWin ein Umdenken erreichst hat das immer noch 
nichts mit der Rust Sprache an sich zu tun - und über die will er reden 
- nicht über die Infrastruktur (obwohl die Klarweise wichtig ist - aber 
eben hier und jetzt nicht relevant ist)
und wenn du deine Crate/crates.io Problematik nicht gewillt bist an der 
richtigen Stellen vorzutragen ist das genauso nur verschwendete Zeit

die crates.io Probleme/Strategien sind vollständig entkoppelt von Rust 
als Sprache - auch wenn sie sehr nahe zusammenstehen - aber ob crates.io 
das Prinzip genau so beibehält oder noch x mal ändert ist völlig 
ungewiss

von MaWin O. (mawin_original)


Lesenswert?

cppbert3 schrieb:
> funktionierend ist nicht das Problem - generisch und performant genug
> ist die Herausforderung

Ja, das ist mir schon klar. Das wollte ich damit ausdrücken.

Aber wenn man die Möglichkeiten der ABI einschränkt, sehe ich jetzt 
nicht unbedingt, warum das ein Performanceproblem sein sollte. Alle 
anderen dynamischen Sprachmerkmale 
((A)Rc/RefCell/trait-objects/...etc...) sind ja schließlich auch in der 
Regel kein Performanceproblem. Und wenn doch, dann muss man das Feature 
halt anders implementieren oder statisch linken. Ich würde das erst 
einmal als Sonderfälle kategorisieren.

von Carsten P. (r2pi)


Lesenswert?

Mombert H. schrieb:
> MaWin schrieb:
>> Nop schrieb:
>>> Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt
>>
>> Qualität ist die Abwesenheit von Kundenreklamationen.
>
> Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik.

You made my day! =DDDDDD

Beitrag #6942606 wurde von einem Moderator gelöscht.
Beitrag #6942639 wurde von einem Moderator gelöscht.
Beitrag #6942647 wurde von einem Moderator gelöscht.
Beitrag #6942657 wurde von einem Moderator gelöscht.
Beitrag #6942669 wurde von einem Moderator gelöscht.
von MaWin (Gast)


Lesenswert?

Es gibt eine neue Version:
https://blog.rust-lang.org/2022/01/13/Rust-1.58.0.html

> Captured identifiers in format strings

Sehr nett.
Ein Schritt weiter in Richtung Python-style-f-strings.

> More #[must_use] in the standard library

Sinnvoll. Kann C++ das eigentlich auch? (ohne Compiler-Extension).

von Rolf M. (rmagnus)


Lesenswert?

MaWin schrieb:
>> More #[must_use] in the standard library
>
> Sinnvoll. Kann C++ das eigentlich auch? (ohne Compiler-Extension).

Ja, mit dem Attribut
1
[[nodiscard]]
 Siehe https://en.cppreference.com/w/cpp/language/attributes/nodiscard

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Rolf M. schrieb:
> nodiscard

Super, danke. Kannte ich noch nicht.

von S. R. (svenska)


Lesenswert?

Mombert H. schrieb:
>> Nein. Aber vor Gericht landet erstmal der Nutzer der Pakete, der dann
>> wiederum crates.io auf Schadensersatz verklagen kann. Ich bin mir
>> sicher, das Regelwerk von crates.io wird den Schaden dann an den Autor
>> weiterreichen.
> Du bist dir sicher? Basiert dein sicher auf deinem Bauchgefühl oder
> kann man das irgendwo nachlesen? Also beide Teile, dass der Nutzer
> zuerst vor Gericht landet und dass der Nutzer gegenüber der Plattform
> einen Anspruch auf Schadensersatz hat.

Für ungeeignete Nutzung von Software hat mein Arbeitgeber durchaus schon 
einige Klagen abbekommen (ob gerechtfertigt oder nicht weiß ich nicht). 
Ist halt ein einfaches Ziel. Wo die Software ursprünglich herkam, 
interessierte den Kläger (und die Rechtskosten) dafür erstmal nicht.

Was den Schadenersatz angeht, so schrieb ich was von "verklagen kann", 
nicht von "Anspruch auf Schadensersatz". Vor Gericht und auf hoher See, 
und so.

> Wenn ich mir da z.B. "illegale"
> Tauschbörsen für Musik und Filme angucke, läuft das anders.

In Deutschland gab es vor einigen Jahren ja große Abmahnwellen von 
diversen Anwaltsagenturen, und die gingen auch großflächig gegen die 
Nutzer und nicht gegen die Tauschplattformen. Zumal letztere ein großes 
Interesse daran haben, nicht rechtlich auffindbar zu sein...

cppbert3 schrieb:
> du hast vollkommen recht - Rust Cargo erschafft durch die Einfachheit
> schneller diese Dependency Probleme (auch wenn es kein Autoupgrade gibt)
> aber was ist die Antwort auf das Problem? einfach niemals Package
> Systeme einsetzen?

Abhängigkeiten reduzieren, soweit möglich und sinnvoll. Also nicht "viel 
hilft viel", wie das diese ganzen Paketmanager begünstigen (und 
vermutlich auch wollen, denn daraus folgt deren Existenzberechtigung).

Wenn jede Abhängigkeit erstmal Aufwand ist, dann überlegt man vorher, 
was man tut. Nachdenken kostet Zeit, und wenn die Zeit durch die 
Prozesse hinreichend stark verkürzt wird, dann findet kein Nachdenken 
mehr statt.

Das empfinde ich als ein Problem. Andere wahrscheinlich nicht, denn "der 
Genosse wird sich schon was dabei gedacht haben".

> auch wenn der aktuelle Cargo Stand vielleicht noch nicht perfekt ist
> finde ich das Cargo eine gute Diskussion-Grundlage bietet um diese
> Punkte für die Zukunft zu verbessern

Mit Cargo selbst habe ich keine Probleme, nur mit dessen Grundidee (die 
ebenso auch für alle anderen Paketmanager zutrifft; dass npm 
gelegentlich explodiert, dürfte in erster Linie an dessen extremer 
Verbreitung liegen).

Mein Problem mit Rust heißt aber Cargo, weil das eben keine getrennten 
oder auch nur sinnvoll trennbaren Technologien sind. Genausowenig, wie 
systemd von dem, was dessen Autoren "systemd umbrella" nennen oder wie 
einen C-Präprozessor von einem C-Compiler.

cppbert3 schrieb:
> Ignorieren die deine Sorgen einfach nur deshalb weil die 1000 Anwälte
> drauf werfen können wenn es Probleme gibt?

Ich kann mir gut vorstellen, dass Microsoft solche Probleme allein 
deshalb ignorieren kann, weil sie einerseits genug Anwälte für eine 
kompetente Verteidigung haben und andererseits genug Anwälte und 
Technologien haben, um jeden, der sie plattmachen will, selbst 
plattzumachen.

Das ist übrigens auch der Grund, warum Microsoft vor einigen Jahrzehnten 
anfing, alles was geht zu patentieren (vorher lehnten sie Patente ab und 
ließen auch eher nichts patentieren): Um damit Angreifer plattmachen zu 
können.

> Einfache Frage: Was macht Microsoft anders als crates.io oder sind die
> einfach genau so unbedarft?

Der Unterschied zwischen crates.io, Github, npm oder irgendwas anderem 
ist... in der Hinsicht nicht vorhanden. Die sind allesamt nicht 
Primärziele, was die illegale Nutzung (im Hinblick auf die 
Lizenzbedingungen) angeht.

Sie verbreiten allerdings die Software weiter, was ebenfalls ein Teil 
der Lizenzbedingungen ist - und das prüfen sie durchaus (oder sollten es 
im Eigeninteresse). Github tut das beispielsweise.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> einige Klagen abbekommen
> Anspruch auf Schadensersatz
> Abmahnwellen
> Tauschplattformen
> npm
> C-Präprozessor
> Microsoft
> illegale Nutzung
> Lizenzbedingungen

Es geht hier im Thread um die Programmiersprache Rust.

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
> Es geht hier im Thread um die Programmiersprache Rust.

Ich habe auf mir gestellte Fragen geantwortet.

von MaWin (Gast)


Lesenswert?

Eine neue Rust-Version ist raus:

https://blog.rust-lang.org/2022/02/24/Rust-1.59.0.html

Das neue Hauptfeature wird wohl für die meisten die Stabilisierung von 
inline-assembly sein.
Aber auch available_parallelism ist ganz nett und man ist nicht mehr auf 
die Verwendung von externen Crates an dieser Stelle unbedingt 
angewiesen.

von cppbert (Gast)


Lesenswert?

ich fand die Inline Assembler Syntax am Anfang doch ein wenig 
gewöhnungsbedürftig (im Vergleich zu VC Inline asm unter x86 (unter x64 
geht das ja auch schon nicht mehr))

oder würde man damit auch z.B. solche mehrseitigen SIMD Sin/Cos 
Implementierungen wie z.B. in der glibc inline machen?

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> ich fand die Inline Assembler Syntax am Anfang doch ein wenig
> gewöhnungsbedürftig (im Vergleich zu VC Inline asm unter x86 (unter x64
> geht das ja auch schon nicht mehr))

Ich habe mir die Rust-Asm noch nicht genauer angeschaut.
Deshalb bin ich interessiert daran, welche Kritikpunkte du hast.

Auf den ersten Blick sieht Rust-Asm ja sehr an Gnu-GCC-Asm angelehnt 
aus.
Und die finde ich eigentlich ganz gut. Wenn man einmal die Constraints 
auswendig gelernt und verstanden hat.

> oder würde man damit auch z.B. solche mehrseitigen SIMD Sin/Cos
> Implementierungen wie z.B. in der glibc inline machen?

Klar. Denke schon. Wozu auch sonst? Für Einzeiler gibt es oft 
Intrinsics.

von MaWin (Gast)


Lesenswert?

Rustc-GCC kann sich nun selbst kompilieren:

https://lwn.net/Articles/889989/

> so this work will eventually allow programs to be built for a number of 
architectures that are not supported by rustc

von Jens B. (dasjens)


Lesenswert?

Carsten P. schrieb:
> HabMut schrieb:
>> C Programme beinhalten häufig vermeidbare Sicherheitslücken die die
>> Sicherheit von IT Systemen gefährden.
>
> Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber
> "sicher" keine sicherheitsrelevanten großen Systeme. Ich kenne genau
> einen sehr versierten "plain C"-Entwickler, dem ich meine Bedürfnisse
> nach einer Software anvertrauen würde, und der verwendet eine selbst
> entwickelte GC, da ist nix mit malloc(). strcpy() und free(). Läuft seit
> der ersten Version sogar auf S7-Steuerungen.

GC in Purem C? Wozu
C native auf S7? Zeig mal wie das geht bzw. wo das steht, daß es geht. 
Wäre mir neu.

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

Und wo ist der Sinn?
Das ist alles Software und kann tierische Fehler enthalten.
Also sollte man einem Betriebssystem schon mal nicht vertrauen, aber der 
Javaapplikation die darauf läuft schon?

von MaWin (Gast)


Lesenswert?

Rust 1.60.0 ist raus:

https://blog.rust-lang.org/2022/04/07/Rust-1.60.0.html

Punkte, die ich interessant finde:

- Source-based Code Coverage

- (A)Rc::new_cyclic: Verbessert die Handhabung von 
zyklischen/selbstreferenzierenden Datenstrukturen.

- Vec::spare_capacity_mut: Kann ein Effizienzgewinn sein, wenn doppelte 
Initialisierungen vermieden werden können. Benötigt aber wahrscheinlich 
in den meisten (allen?) Fällen auch eine Zeile unsafe-Rust.

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> - Source-based Code Coverage

ich finde es sehr gut das solche Dinge sehr stark integriert werden
(schön wäre jetzt noch ein sehr Kompiler/Toolchain naher Parser und 
Refactoring-Service/Lib/whatever den externe Tools nutzen können)

Contra:
-es fehlen sicherlich dann ein paar Features die in gcov/und anderen 
Tools vorhanden sind - aber wachsen kann es ja jederzeit

Pro:
-egal wie gut oder schlecht - es gibt einen Standard den alle 
rustc/cargo Nutzer gemeinsam haben
-wer mit C/C++, Platform- und Compilerübergreifend viel mit Coverage zu 
tun hat wir sich freuen das es vielleicht möglich ist auf eine gut und 
immer funktionierende Lösung zu kommen

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> (schön wäre jetzt noch ein sehr Kompiler/Toolchain naher Parser und
> Refactoring-Service/Lib/whatever den externe Tools nutzen können)
>
> Contra:
> -es fehlen sicherlich dann ein paar Features die in gcov/und anderen
> Tools vorhanden sind - aber wachsen kann es ja jederzeit

Ich kann dir leider nicht ganz folgen.

Rust coverage basiert auf den Standard-LLVM-Coveragetools.

https://llvm.org/docs/CommandGuide/llvm-profdata.html
https://llvm.org/docs/CommandGuide/llvm-cov.html

von cppbert3 (Gast)


Lesenswert?

Dann ist eher die frage wie der gcc-rustc dann coverage implementieren 
wird und wie schnell sich die beiden compiler angleichen damit man beide 
gleich nutzen kann

In der c/cpp Welt speziell unter Windows gibt es x Lösungen die 
inkompatibel sind und jede Lösung hat irgendeine andere schwäche die 
dann projektbezogen auftreten, eine einheitliche Lösung egal auf welchem 
backend basierend ist da ein grosser Gewinn

von MaWin (Gast)


Lesenswert?

cppbert3 schrieb:
> Dann ist eher die frage wie der gcc-rustc dann coverage implementieren
> wird und wie schnell sich die beiden compiler angleichen damit man beide
> gleich nutzen kann

Ja. Aber die Frage ist dann eher: Was sind die Unterschiede zwischen 
LLVM und GCC, was Coverage angeht? Mit Rust hat das dann erst einmal 
wenig zu tun.

von Oliver S. (oliverso)


Lesenswert?

Carsten P. schrieb:
> Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber
> "sicher" keine sicherheitsrelevanten großen Systeme.

Und wenn das Betriebssystem selber in C geschrieben ist? Und der 
Compiler, den du dazu nutzt, auch?

Das soll es ja gerüchteweise geben ;)

Oliver

von Rolf M. (rmagnus)


Lesenswert?

Oliver S. schrieb:
> Carsten P. schrieb:
>> Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber
>> "sicher" keine sicherheitsrelevanten großen Systeme.
>
> Und wenn das Betriebssystem selber in C geschrieben ist? Und der
> Compiler, den du dazu nutzt, auch?

Ja, es wird gerne vergessen, dass praktisch so gut wie jedes Programm, 
das auf einem Rechner läuft, auf einen Unterbau in C aufsetzt.

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> cppbert3 schrieb:
>> Dann ist eher die frage wie der gcc-rustc dann coverage implementieren
>> wird und wie schnell sich die beiden compiler angleichen damit man beide
>> gleich nutzen kann
>
> Ja. Aber die Frage ist dann eher: Was sind die Unterschiede zwischen
> LLVM und GCC, was Coverage angeht? Mit Rust hat das dann erst einmal
> wenig zu tun.

er geht mir nur darum das ich finde das Rust als Komplettpaket es 
schafft alle Entwickler Feature-Technisch an einen Tisch zu bringen - 
nicht das einfach technisch geht sondern auch dieser 
Vereinheitlichungscharakter

von Le X. (lex_91)


Lesenswert?

Rolf M. schrieb:
> Oliver S. schrieb:
>> Carsten P. schrieb:
>>> Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber
>>> "sicher" keine sicherheitsrelevanten großen Systeme.
>>
>> Und wenn das Betriebssystem selber in C geschrieben ist? Und der
>> Compiler, den du dazu nutzt, auch?
>
> Ja, es wird gerne vergessen, dass praktisch so gut wie jedes Programm,
> das auf einem Rechner läuft, auf einen Unterbau in C aufsetzt.

Auch wenn die Replik inhaltlich richtig ist:
ich sehe das ähnlich wie Carsten P.
Ich verdiene zwar mein Geld mit (systemnaher) C-Programmierung, aber 
Userspace-Programme würde ich ohne Not heute nicht mehr in C schreiben 
wollen.
Man will ja irgendwann auch fertig werden.

von cppbert (Gast)


Lesenswert?

Rolf M. schrieb:
> Oliver S. schrieb:
>> Carsten P. schrieb:
>>> Richtig. Kleine Tools kann man gerne auf jedem OS in C schreiben, aber
>>> "sicher" keine sicherheitsrelevanten großen Systeme.
>>
>> Und wenn das Betriebssystem selber in C geschrieben ist? Und der
>> Compiler, den du dazu nutzt, auch?
>
> Ja, es wird gerne vergessen, dass praktisch so gut wie jedes Programm,
> das auf einem Rechner läuft, auf einen Unterbau in C aufsetzt.

das vergisst doch niemand hier in dieser Diskussion
und das selbe haben vorher die Assembler-Programmierer gesagt als C 
eingeführt wurde, und davor noch die, welche Kabeln programmiert 
haben...

Der Spruch kommt von den Java hatern, weil die VM ja auch auf C/C++ 
basiert - aber das trifft hier nur unzureichend weil Rust als 
Systemsprache mit C/C++ auf einer Ebenen steht

es ändert nur nichts an den Pro-Argumenten für Rust - und es juckt 
niemanden ob die Pro-Argumente nicht für alle so gelten, sonst dürfte 
man ja gar nichts schreiben

von Rolf M. (rmagnus)


Lesenswert?

cppbert schrieb:
> Der Spruch kommt von den Java hatern, weil die VM ja auch auf C/C++
> basiert - aber das trifft hier nur unzureichend weil Rust als
> Systemsprache mit C/C++ auf einer Ebenen steht

Es ging darum, dass diese Aussage nicht stimmt:

Carsten P. schrieb:
> Kleine Tools kann man gerne auf jedem OS in C schreiben, aber
> "sicher" keine sicherheitsrelevanten großen Systeme.

Denn in der realen Welt setzt aktuell so gut wie jedes 
sicherheitsrelevante große System auf einen Kern in C auf.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Rolf M. schrieb:
> Denn in der realen Welt setzt aktuell so gut wie jedes
> sicherheitsrelevante große System auf einen Kern in C auf.

Jepp. Und dann passieren halt auch noch z.b. so Schoten, dass es fuer 
polkit
(BLFS-Book: "Polkit is a toolkit for defining and handling 
authorizations. It is used for allowing unprivileged processes to 
communicate with privileged processes.")
 eine javascript-engine braucht (also aktuell ein Teil der 
firefox-sourcen), die dann ihrerseits wieder ein rustc zum Bauen 
braucht...
Und der ganze Kack mit ich-weiss-nicht-wieviel-LOC soll dann sicher 
sein?

Gruss
WK

von MaWin (Gast)


Lesenswert?

Dergute W. schrieb:
> polkit
´
> Und der ganze Kack mit ich-weiss-nicht-wieviel-LOC soll dann sicher
> sein?

Nein. Niemand mit Verstand behauptet, dass polkit gut und/oder sicher 
ist.
Mit Rust - dem Thema des Threads - hat das allerdings nichts zu tun.

von MaWin (Gast)


Lesenswert?

Wer etwas mehr über negative Aspekte von Rust und Cargo lernen möchte, 
ohne gleich in (falsche) Vermutungen und FUD abzudriften, dem kann ich 
diese Lektüre empfehlen:

https://www.bunniestudios.com/blog/?p=6375

von MaWin (Gast)


Lesenswert?

Release: Rust 1.61.0
https://blog.rust-lang.org/2022/05/19/Rust-1.61.0.html

Es scheinen viele Detailänderungen eingegangen zu sein.
Man kann jetzt recht komfortabel mit Termination einen Returncode von 
Main zurückgeben.

von MaWin (Gast)


Lesenswert?

Achja.
Und außerdem funktioniert endlich das AVR8-Target wieder mit der neusten 
nightly-Version.

von Kaj (Gast)


Lesenswert?


von MaWin (Gast)


Lesenswert?

Kaj schrieb:
> Rust-Frontend kommt offiziell in die GCC

Das ist ein ganz wichtiger Schritt. Ohne diesen Schritt ist die breite 
Verwendung besonders auf Nicht-PC-Plattformen nicht denkbar.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Kaj schrieb:
>> Rust-Frontend kommt offiziell in die GCC
>
> Das ist ein ganz wichtiger Schritt. Ohne diesen Schritt ist die breite
> Verwendung besonders auf Nicht-PC-Plattformen nicht denkbar.

Aber da Rust ohne Cargo niemand verwendet, bringt das allein auch nicht 
viel.

IMO ist Rust schon tot. Genau so wie Go.
Kotlin lebt nur noch wegen Android Apps.

Im prof. Embedded Umfeld kommen solche Hypes ohnehin nicht vor. Das ist 
was für Medieninformatiker mit Nebenfach Sportgymnastik.

: Bearbeitet durch User
von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> IMO ist Rust schon tot.

zum Glück haben sich ein paar Linux-Kernel Entwickler bereit erklärt die 
archivarische Aufgabe zu übernehmen - damit man später seinen Kindern 
noch was davon zeigen kann :)

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Aber da Rust ohne Cargo niemand verwendet, bringt das allein auch nicht
> viel.

Wo genau soll das Problem sein?
Man wird Cargo (und alle anderen Tools und Programme) natürlich mit 
gccrs übersetzen können.

von DPA (Gast)


Lesenswert?

Es gibt ja immer noch keinen authoritativen standard, und stattdessen 
wird das clang verhalten dafür missbraucht. Machen gcc und clang was 
anders, macht es also per definition gcc falsch. Gcc ist deshalb dazu 
verdammt, per definition immer die verbuggte hinterherhinkende Version 
zu bleiben. Eine echte Alternative / Konkurrenz, kann es so nicht 
werden. Solange es keinen authoritativen standard gibt, ist das gcc ein 
rust frontend hat, also nur auf dem Papier was wert, in der Praxis aber 
irrelevant.

von MaWin (Gast)


Lesenswert?

DPA schrieb:
> Solange es keinen authoritativen standard gibt, ist das gcc ein
> rust frontend hat, also nur auf dem Papier was wert, in der Praxis aber
> irrelevant.

Genau so, wie alle Python-Implementierungen irrelevant sind, weil es 
keinen "authorativen Standard" gibt?

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


Lesenswert?

MaWin schrieb:
> alle Python-Implementierungen

Mal von Micro-Python abgesehen, gibt es denn da überhaupt mehr als eine 
Implementierung?

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Mal von Micro-Python abgesehen, gibt es denn da überhaupt mehr als eine
> Implementierung?

Dann google doch mal.
Es gibt dutzende große Pythonimplementierungen.

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> DPA schrieb:
>> Solange es keinen authoritativen standard gibt, ist das gcc ein
>> rust frontend hat, also nur auf dem Papier was wert, in der Praxis aber
>> irrelevant.
> Genau so, wie alle Python-Implementierungen irrelevant sind, weil es
> keinen "authorativen Standard" gibt?
Ich weiß nicht wie das anderswo ist. In meinem Arbeitsumfeld ist nur 
CPython relevant. Ich kenne niemanden, der etwas anderes in seinen 
Produkten einsetzt. In den letzten Jahren wurden in mehreren Projekten 
sogar explizit mehrere andere Implementationen vom Kunden verboten.

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


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>> Mal von Micro-Python abgesehen, gibt es denn da überhaupt mehr als eine
>> Implementierung?
>
> Dann google doch mal.
> Es gibt dutzende große Pythonimplementierungen.

"Other Implementations

…

Note that most of these projects have not yet achieved language 
compliance"

Allerdings hat Python zumindest eine Language Reference:

https://docs.python.org/3/reference/index.html

einschließlich einer kompletten Grammatikdokumentation:

https://docs.python.org/3/reference/grammar.html

von Daniel A. (daniel-a)


Lesenswert?

Es gibt auch noch: https://peps.python.org/pep-0000/
Änderungen werden also nicht einfach nur in der Implementierung 
umgesetzt, sondern erstmal vorgeschlagen & diskutiert.

von MaWin (Gast)


Lesenswert?

Daniel A. schrieb:
> Änderungen werden also nicht einfach nur in der Implementierung
> umgesetzt, sondern erstmal vorgeschlagen & diskutiert.

Das ist bei Rust identisch.
Bitte zurück zum Thema.
Hier geht es um Rust.

Jörg W. schrieb:
> Note that most of these projects have not yet achieved language
> compliance"

Dummes Blah.

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


Lesenswert?

MaWin schrieb:
>> Note that most of these projects have not yet achieved language
>> compliance"
>
> Dummes Blah.

Ah ja.

Stammt halt nur aus dem Python-Wiki.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Stammt halt nur aus dem Python-Wiki.

Aus dem C-Python-Wiki. Wieso sollte das eine verlässliche Quelle über 
den Zustand von anderen Implementierungen sein?

Gib deine Rechthaberei bitte auf. Es gibt sehr viele komplette und 
stabile Python-Implementierungen. Ich zähle sie hier bewusst nicht auf, 
weil das Thema des Threads nicht Python ist und das jeder in Google 
finden kann.

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


Lesenswert?

MaWin schrieb:
> Wieso sollte das eine verlässliche Quelle über den Zustand von anderen
> Implementierungen sein?

Weil auch von C-Python letztlich die Sprachdefinition stammt.

Wenn ich jetzt einen Rust-Compiler schreibe und sage, er sei Rust 
compliant, würdest du das als verlässliche Quelle akzeptieren, nur weil 
ich das so sage?

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Wenn ich jetzt einen Rust-Compiler schreibe und sage, er sei Rust
> compliant, würdest du das als verlässliche Quelle akzeptieren, nur weil
> ich das so sage?

Ach komm. Das ist doch dummes Geschwätz.
Du hast weder Ahnung von Python, noch von Rust. Das ist offensichtlich.

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


Lesenswert?

Du musst es ja wissen.

Und nur, weil du dich jetzt aufregst, dass über Python diskutiert wird: 
das war dein Einwand.

: Bearbeitet durch Moderator
von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> das war dein Einwand.

Nein. Ich habe nur einen Vergleich gebracht.
Dass ihr Knalltüten jetzt gleich Python in Frage stellt, hätte ich mir 
allerdings denken können.
Dinge in Frage stellen, von denen man Null Ahnung hat, ist ja euer 
Hobby.

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


Lesenswert?

Du disqualifizierst dich soeben für jegliche ernsthafte Diskussionen.

Rust tust du mit deinem Auftreten gewiss keinen Gefallen.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Rust tust du mit deinem Auftreten gewiss keinen Gefallen.

Wie wäre es denn, wenn du mal wieder zum Thema zurückkommen würdest?

Ich kann nicht sehen, wie ich Rust schade, wenn ich Unwahrheiten über 
Python richtigstelle.

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> Bitte zurück zum Thema.
> Hier geht es um Rust.
MaWin schrieb:
> Genau so, wie alle Python-Implementierungen irrelevant sind, weil es
> keinen "authorativen Standard" gibt?
Hauptsache nicht an die eigenen Regeln halten ;-)

MaWin schrieb:
> Es gibt sehr viele komplette und
> stabile Python-Implementierungen. Ich zähle sie hier bewusst nicht auf,
> weil das Thema des Threads nicht Python ist und das jeder in Google
> finden kann.
Schön, dass es sie gibt, und dass du glaubst, dass sie komplett und 
stabil sind. Aber wer nutzt sie?

von Experte (Gast)


Lesenswert?

Jörg W. schrieb:
> Mal von Micro-Python abgesehen, gibt es denn da überhaupt mehr als eine
> Implementierung?

Einfach mal Google benutzen und ein paar Minuten lesen, wenn man von 
einem Thema schon keine Ahnung hat, ist zu viel verlangt?

Ja, es gibt einige. Auch Du kannst das herausfinden, wenn Du willst, 
trotz Deinem "Moderator"-Emblem.

Jörg W. schrieb:
> Ah ja.
>
> Stammt halt nur aus dem Python-Wiki.

Wenn Du Dir schon fremde Aussagen zu eigen machst, wäre ein Zitat und 
ein Link auf die Quelle angebracht, findest Du nicht auch?

Darüber hinaus, als ob irgendwelche halb-verwaisten Wikis eine besondere 
Relevanz hätten. Einfach auf den jeweiligen Projektseiten nachlesen, 
welchen Stand das jeweilige Projekt hat, übersteigt Dein Interesse?

Jörg W. schrieb:
> Rust tust du mit deinem Auftreten gewiss keinen Gefallen.

Was hat das Verhalten eines Forumsbenutzer mit der Reputation von Rust 
zu tun? So viel wie Dein Verahlten hier mit der Reputation dieses 
Forums?

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


Lesenswert?

Experte schrieb:

>> Stammt halt nur aus dem Python-Wiki.
>
> Wenn Du Dir schon fremde Aussagen zu eigen machst, wäre ein Zitat und
> ein Link auf die Quelle angebracht, findest Du nicht auch?

Weißt du, wofür die Anführungszeichen gut sind? Bestimmt nicht, um mir 
etwas "zu eigen" zu machen.

Den Link kann man doch ganz einfach herausfinden, indem man das Zitat 
bei Google einkippt. Das ist die Methode, die ihr mir nahe gelegt habt.

https://wiki.python.org/moin/PythonImplementations

> Darüber hinaus, als ob irgendwelche halb-verwaisten Wikis eine besondere
> Relevanz hätten.

Was bringt dir das, auf so einem Niveau zu diskutieren? Habe ich (oder 
jemand anders hier) irgendwo die Projektseiten von Rust als 
"halb-verwaist" diffamiert?

Leute, auf dem Niveau bedarf es wohl keiner weiteren Diskussionen.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Was bringt dir das, auf so einem Niveau zu diskutieren?

Jörg, ich respektiere dich sehr als Experten auf dem Gebiet C und AVR-C.
Aber von Rust und Python hast du offensichtlich leider keinerlei Ahnung. 
Das zeigst du hier leider sehr eindrucksvoll.

Wenn hier über

> Niveau

geredet wird, dann solltest du es auch selbst einhalten.
Effektiv zu behaupten von Python gäbe es nur eine einzige breit genutzte 
vollständige Implementierung, ist einfach nur lächerlich. Deine Aussagen 
hier beweisen nur, dass du noch nie mit Python und Rust gearbeitet hast, 
was über ein Hello World oder ein schnell dahingehacktes Script 
hinausgeht.

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


Lesenswert?

MaWin schrieb:
> Effektiv zu behaupten von Python gäbe es nur eine einzige breit genutzte
> vollständige Implementierung, ist einfach nur lächerlich.

Ich habe getan, was du empfohlen hast, und danach gegoogelt. Da bin ich 
beim Python-Wiki rausgekommen, welches dann jemand hier als 
"halb-verwaist" diffamiert.

Was soll das?

> Deine Aussagen
> hier beweisen nur, dass du noch nie mit Python und Rust gearbeitet hast,
> was über ein Hello World oder ein schnell dahingehacktes Script
> hinausgeht.

Du irrst, gewaltig, was Python angeht.

Über Rust habe ich nichts geschrieben.

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
> Effektiv zu behaupten von Python gäbe es nur eine einzige breit
> genutzte vollständige Implementierung, ist einfach nur lächerlich.

Wir können uns darauf einigen, dass es eine (oder vielleicht zwei) 
Standardimplementation gibt sowie viele weitere, die nur in ihren Ecken 
des Internets verbreitet sind.

> Deine Aussagen hier beweisen nur, dass du noch nie mit Python
> und Rust gearbeitet hast, was über ein Hello World oder ein schnell
> dahingehacktes Script hinausgeht.

Deine Aussagen beweisen auch nicht viel mehr.
Nur, dass du mehr Zeit für Diskussionen übrig hast.

Merkt man z.B. an sowas:

MaWin schrieb:
> Dass ihr Knalltüten jetzt gleich Python in Frage stellt, hätte ich mir
> allerdings denken können.

Riecht nach unpassendem Diskussionsstil.

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> Wir können uns darauf einigen

Nein. Weil es Quatsch ist.

> Riecht nach unpassendem Diskussionsstil.

Ich möchte überhaupt nicht über Python diskutieren, sondern hatte es nur 
als Vergleich angebracht. Und damit beende ich mein Mitwirken an der 
Python-Diskussion hier.

Hier geht es um Rust.

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
> Hier geht es um Rust.
Nun gut, dann können wir ja auch wieder zum Anfang der Diskussion - 
diesmal ohne Python-Vergleich - zurückkehren:

DPA schrieb:
> Es gibt ja immer noch keinen authoritativen standard, und
> stattdessen wird das clang verhalten dafür missbraucht.
> Machen gcc und clang was anders, macht es also per definition
> gcc falsch. Gcc ist deshalb dazu verdammt, per definition
> immer die verbuggte hinterherhinkende Version zu bleiben.
> Eine echte Alternative / Konkurrenz, kann es so nicht
> werden. Solange es keinen authoritativen standard gibt,
> ist das gcc ein rust frontend hat, also nur auf dem Papier
> was wert, in der Praxis aber irrelevant.

Also?

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> Also?

Es ist halt völliger Unsinn.
Keinerlei Begründung und ich soll jetzt die Gegenbegründung finden?
Na gut.

> stattdessen wird das clang verhalten dafür missbraucht.

Kannst du es vielleicht mal ausführen, was "das clang-Verhalten" 
überhaupt sein soll?
Was hat clang überhaupt mit Rust zu tun? Meinst du LLVM?
Welche Teile von Rust sind nur so, weil LLVM das vorgibt?
Und warum ist das ein Missbrauch?

S. R. schrieb:
> macht es also per definition gcc falsch

Richtig. Wo ist das Problem?

> immer die verbuggte [...] zu bleiben.

Warum?
Können GCC-Entwickler keine Bugs fixen?

> Solange es keinen authoritativen standard gibt,
> ist das gcc ein rust frontend hat, also nur auf dem Papier
> was wert, in der Praxis aber irrelevant.

Wie kommst du zu der Schlussfolgerung?

von DPA (Gast)


Lesenswert?

MaWin schrieb:
> Wie kommst du zu der Schlussfolgerung?

Hab ich doch schon asführlich aufgeführt.

Das llvm rustc Ding ist authoritativ.
Szenario: gcc und rustc machen was anders.
Resultat: Per definition muss rustc der compiler sein, der es richtig 
macht, und gcc der Compiler, der den Bug hat.

Die Programme werden natürlich auch das rustc verhalten voraussetzen. 
Ausserdem, jede Änderung und Erweiterung heist, dass beide Compiler was 
anders machen, also gcc was falsch macht.
Wie man es auch dreht und wendet, gcc kann so nicht relevant werden, und 
kann niemals besser als clang sein, per definition. Wenn es nicht 
relevant werden kann, ist es in der Praxis irrelevant.

Das folgt alles logisch daraus, dass das llvm rustc Ding authoritativ 
ist, und eben nicht ein Standard. Es ist im vornherein als perfekt 
festgelegt, und perfekter als perfekt kann man halt nicht werden.

Ich hoffe, diesmal konntest du mir folgen. Ich habe die ganze logik 
Kette a also b also c, nochmal angegeben. Aber ich kann dich natürlich 
nicht zwingen, den Gedankengang nachzuvollziehen.

von MaWin (Gast)


Lesenswert?

DPA schrieb:
> Resultat: Per definition muss rustc der compiler sein, der es richtig
> macht, und gcc der Compiler, der den Bug hat.

Richtig. Wo ist das Problem?

> Die Programme werden natürlich auch das rustc verhalten voraussetzen.

Richtig. Wo ist das Problem?

> Ausserdem, jede Änderung und Erweiterung heist, dass beide Compiler was
> anders machen, also gcc was falsch macht.

Richtig. Ansonsten implementiert GCC nicht Rust, sondern etwas anderes.
Das können sie gerne machen, aber dann ist es nicht Rust.
Gccrs wollen Rust implementieren.

Wo ist das Problem?

> gcc kann so nicht relevant werden

Warum? Ich verstehe nicht, wie du das schlussfolgern kannst.
Wenn gccrs 99% von rustc's Verhalten implementiert, dann sind sie 
relevant.
Wieso sollten sie es nicht sein?

> kann niemals besser als clang sein, per definition.

(Was hat clang hier wieder zu suchen?)
GCC kann nur besser sein, wenn sie etwas implementieren, was nicht Rust 
ist?
Das ist gar nicht das Ziel von gccrs.
Sie wollen Rust implementieren.

> Das folgt alles logisch daraus, dass das llvm rustc Ding authoritativ
> ist,

Richtig. Wo ist das Problem?

> Es ist im vornherein als perfekt festgelegt

Nein, das ist nicht richtig.
Rust enthält sehr viele nicht implementierte Dinge und auch viele 
undefinierte Dinge (unstable).
Und das ist im Entwicklungsprozess ziemlich gut eingebettet.
Bei diesen Dingen hat dann weder rustc noch gccrs "recht". Aber wenn 
gccrs Rust implementieren will, dann werden sie sich mit den rustc 
Entwicklern abstimmen müssen.
Wo ist das Problem?

> Ich hoffe, diesmal konntest du mir folgen.

Leider nicht. Ich sehe nicht, wo hier der Nachteil bei gccrs sein soll 
und warum es deshalb zum Scheitern verurteilt sein soll.

Nach deiner Logik dürfte es immer nur einen Standard und/oder eine 
Sprachimplementierung geben.
Das ist doch Unsinn.
In der Praxis sind die wenigsten Sprachen offiziell standardisiert.
Trotzdem sind sie erfolgreich und es gibt oft mehrere Implementierungen.

Ich glaube ihr habt eher Angst vor Umbrüchen und Neuem.
Rust ist hier. Und es wird nicht wieder gehen, nur weil ihr die Augen 
verschließt.
Gccrs ist ein weiterer wichtiger Schritt dieses zu manifestieren.

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


Lesenswert?

MaWin schrieb:
> Ich glaube ihr habt eher Angst vor Umbrüchen und Neuem.

Nein.

Die Kritik ist nicht daran, dass es die Sprache gibt und dass Leute sie 
verwenden (ich kenne auch ganz persönlich jemanden, der davon begeistert 
ist). (Ja, es gibt hier auch Leute, die der Meinung sind, die würde 
nichts taugen. Ich gehöre nicht dazu, und auch die Kritik von DPA 
behauptet nicht sowas.)

Die Kritik ist, dass sie es bis heute nicht geschafft haben, eine 
formale Definition aufzuschreiben. Es gibt eine "Reference", aber die 
schreibt gleich als erstes, dass sie "incomplete" ist, und eine formale 
Definition will sie gar nicht sein. So ist das alles irgendwie mit 
Beispielen beschrieben statt mit einer formalen Syntax. Auch steht da 
sowas drin:

"Finally, this book is not normative. It may include details that are 
specific to rustc itself, and should not be taken as a specification for 
the Rust language. We intend to produce such a book someday, and until 
then, the reference is the closest thing we have to one."

Das ist, was DPA meinte: rustc ist damit de facto das Normativ.

Sicher war das auch mit C eine Weile so, dass es nur einen 
implementierten Compiler gab. Der war aber auch vor 50 Jahren (kannst du 
bei Dennis Ritchie nachschlagen) bereits begleitet von einer formalen 
Sprachbeschreibung. Es konnte also jemand anders nur auf Basis der 
Beschreibung einen eigenen Compiler (oder anderweitigen Parser) 
schreiben. Aus alldem konnte man schließlich (ja, hat auch eine Weile 
gedauert) einen wohldefinierten Standard ableiten.

Nochmal: ich gehe durchaus davon aus (auf der Basis dessen, was ich von 
anderen gehört habe), dass die Sprache Potenzial hat. Aber wenn man eine 
Sprache implementiert, die eine gewisse Bedeutung bekommen soll, dann 
muss man sich auch dem formalen Kram widmen und nicht nur neue Features 
hacken. Python ist da (wie ich oben mal schrieb) weiter. OK, ist auch 
älter, ist akzeptiert.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Die Kritik ist, dass sie es bis heute nicht geschafft haben, eine
> formale Definition aufzuschreiben.

Ja gut. Das ist richtig.
Damit reiht Rust sich in 99% aller Sprachen ein.
Scheint wohl kein allzu großes Problem zu sein.

Für welche Sprachen gibt es überhaupt eine offizielle Standardisierung?

Python, Matlab. Alles Sprachen kurz vor dem Bankrott. Niemand verwendet 
sie. Denn sie haben ja keine offizielle Standardisierung.

Unsinn.

> Sicher war das auch mit C eine Weile so

Ach? Das ist ja ein Ding.
Und trotzdem ist C so erfolgreich?
Wie kommt denn das?
Ist ja völlig unmöglich.

> Der war aber auch vor 50 Jahren

Das ist ja ein Ding. Und jetzt rechne mal nach, wie alt moderne Sprachen 
wie Rust sind.
Und dann rechne einmal nach, wann C seinen ersten Standard bekam.

> dann muss man sich auch dem formalen Kram widmen

Gut. Dann ist ja alles in Butter. Die Rust-Entwicklung ist einem starken 
formellen Prozess unterlegen.

> und nicht nur neue Features hacken.

Passiert nur in deine Fantasie.

> Python ist da (wie ich oben mal schrieb) weiter.

Unsinn. Befasse dich einmal bitte mit der Rust-Entwicklung, bevor du sie 
bewertest.
Danke.

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
> Für welche Sprachen gibt es überhaupt eine offizielle Standardisierung?

Recht viele, auch wenn die nicht überall öffentlich von einem 
Standardisierungsgremium abgesegnet worden ist.

> Python, Matlab. Alles Sprachen kurz vor dem Bankrott. Niemand verwendet
> sie. Denn sie haben ja keine offizielle Standardisierung.

Nun, das Debakel um Python 2 und Python 3 tat ihrer Beliebtheit nun ganz 
sicher nicht helfen (und wir hadern damit noch immer). Eine sehr 
bekannte Sprache, der ihre fehlende Standardisierung - und damit die 
normative Macht der Implementation - zum Verhängnis geworden ist, wäre 
Perl. So aus der Ferne sieht das bei PHP ähnlich aus, und beide Sprachen 
sind inzwischen mehr tot als lebendig.

> Das ist ja ein Ding. Und jetzt rechne mal nach,
> wie alt moderne Sprachen wie Rust sind.
> Und dann rechne einmal nach, wann C seinen ersten Standard bekam.

Die formale Definition von C ist wesentlich älter als ihr erster 
Standard. Und zumindest ich trenne auch noch zwischen der 
Standardbibliothek und der Sprachdefinition selbst, aber da gibt es 
sicher auch andere Ansichten.

> Gut. Dann ist ja alles in Butter.
> Die Rust-Entwicklung ist einem starken
> formellen Prozess unterlegen.

Und am Ende des Prozesses steht ein "der Compiler hat Recht".

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> Und am Ende des Prozesses steht ein "der Compiler hat Recht".

Ziemlicher Quatsch.
Wie wäre es, wenn ihr euch Rust und den Entwicklungsprozess einmal 
anschaut?

von Rolf M. (rmagnus)


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>> Die Kritik ist, dass sie es bis heute nicht geschafft haben, eine
>> formale Definition aufzuschreiben.
>
> Ja gut. Das ist richtig.
> Damit reiht Rust sich in 99% aller Sprachen ein.
> Scheint wohl kein allzu großes Problem zu sein.
>
> Für welche Sprachen gibt es überhaupt eine offizielle Standardisierung?

Es gibt auch noch was zwischen kar keiner Definition der Sprache und 
einem ISO-Standard.

> Python, Matlab. Alles Sprachen kurz vor dem Bankrott. Niemand verwendet
> sie. Denn sie haben ja keine offizielle Standardisierung.

Sie haben aber eine formale Definition.

>> Python ist da (wie ich oben mal schrieb) weiter.
>
> Unsinn. Befasse dich einmal bitte mit der Rust-Entwicklung, bevor du sie
> bewertest.

Hier ist die formale Definition von Python:
https://docs.python.org/3/reference/index.html
Wo ist das Äquivalent für Rust?

: Bearbeitet durch User
von Jemand (Gast)


Lesenswert?

Rolf M. schrieb:
> Hier ist die formale Definition von Python:

> I chose to use English rather than formal specifications for everything except 
syntax and lexical analysis. This should make the document more understandable to 
the average reader, but will leave room for ambiguities. Consequently, if you were 
coming from Mars and tried to re-implement Python from this document alone, you 
might have to guess things and in fact you would probably end up implementing 
quite a different language. [...] If you would like to see a more formal 
definition of the language, maybe you could volunteer your time — or invent a 
cloning machine :-).

"formale Spezifikation"

von Rolf M. (rmagnus)


Lesenswert?

Jemand schrieb:
> [...]

Lustig, dass du gerade den Satz übersprungen hast:

"On the other hand, if you are using Python and wonder what the precise 
rules about a particular area of the language are, you should definitely 
be able to find them here."

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


Lesenswert?

MaWin schrieb:

> Damit reiht Rust sich in 99% aller Sprachen ein.

Nein.

> Für welche Sprachen gibt es überhaupt eine offizielle Standardisierung?

Es ging nicht um offizielle Standardisierung, sondern wenigstens mal 
selbst eine formale Sprachdefinition aufzuschreiben.

Python beispielsweise hat sowas, habe ich dir geschrieben.

Es geht auch nicht um "kurz vor dem Bankrott", sondern darum, dass sowas 
eine sinnvolle Basis dafür ist, dass jemand anders eine unabhängige 
Implementierung vornimmt.

Aber du drehst uns die Worte im Munde rum, für dich sind wir die Bösen, 
die nur das neue scheuen, nur weil wir nicht 100 % in deine Lobpreisung 
einstimmen. Das ist keine Diskussionsbasis.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> nur weil wir nicht 100 % in deine Lobpreisung einstimmen.

Meine Lobpreisung existiert nur in deiner Fantasie.

Ich sehe durchaus die Schwächen von Rust und habe das auch schon 
mehrfach hier geschrieben.
Und ja, das Fehlen einer vollständigen formellen Sprachdefinition ist 
ein Teil davon.
Ich stimme euch lediglich nicht dabei zu, dass das ein riesiges Problem 
ist.

> Python beispielsweise hat sowas, habe ich dir geschrieben.

Das ist genau so unvollständig, wie die Dokumentation von Rust.
Trotzdem ist Python extrem erfolgreich.
Komisch, gell?

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


Lesenswert?

MaWin schrieb:
> Ich stimme euch lediglich nicht dabei zu, dass das ein riesiges Problem
> ist.

Das Thema kam nur im Zusammenhang damit hoch, dass den Thread jemand 
wieder hochgeholt hat um zu erzählen, dass das jetzt in GCC drin ist.

Für eine unabhängige Compiler-Implementierung ist es vielleicht nicht 
ein "riesiges" Problem, aber zumindest aus Sicht mehrerer Leute hier 
durchaus ein Problem.

Um nicht mehr und nicht weniger ging es.

> Das ist genau so unvollständig, wie die Dokumentation von Rust.

Kann gut sein, aber es ist ein Anfang, den Rust (an der Stelle) sich 
noch nicht die Mühe gemacht hat zu gehen. Eine derartige 
Unvollständigkeit würde natürlich wiederum erklären, warum die 
Alternativ-Implementierungen teilweise eben auch in der Vollständigkeit 
hinter CPython hinterher hinken – womit indirekt bewiesen ist, dass eine 
fehlende saubere und vollständige formale Beschreibung eben für 
alternative Implementierungen durchaus ein Problem sein kann.

Wie geschrieben: darum, ob die Sprache selbst nun gut oder schlecht oder 
brauchbar ist oder nicht, ging's hier gerade gar nicht.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> aber es ist ein Anfang, den Rust (an der Stelle) sich
> noch nicht die Mühe gemacht hat zu gehen.

Das ist natürlich auch mal wieder Quatsch.

Die Rust Features werden alle in Issues/RFCs beschrieben und entwickelt.
Und es gibt auch Bücher, die diese Informationen zusammentragen.

https://doc.rust-lang.org/stable/unstable-book/the-unstable-book.html
https://rustc-dev-guide.rust-lang.org/getting-started.html
https://doc.rust-lang.org/nomicon/

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> darum, ob die Sprache selbst nun gut oder schlecht oder
> brauchbar ist oder nicht,

Ach. Das ist ja ein Ding. Da muss ich mich wohl falsch erinnern.
Mal sehen...

Cyblord -. schrieb:
> IMO ist Rust schon tot.

Ach, wohl doch nicht.

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


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>> darum, ob die Sprache selbst nun gut oder schlecht oder
>> brauchbar ist oder nicht,
>
> Ach. Das ist ja ein Ding. Da muss ich mich wohl falsch erinnern.
> Mal sehen...

Was schmeißt du fremde Zitate in meine Argumentation?

Klar gibt es Doku, hat keiner bestritten. Aber der Ansatz, einen 
alternativen Compiler zu entwickeln, geht halt normalerweise nicht über 
das Studium von Prosa oder gar Sourcecode eines anderen Compilers, 
sondern über eine formale Sprachdefinition.

Wenn es die nicht gibt, wird der alternative Compiler irgendwie immer 
der zweite Sieger bleiben. Mehr war hier nicht als Argumentation (wenn 
man von solchen Blasen absieht, wie du zitiert hast – ich weiß bloß 
nicht, warum du dich über solcherart begründungslos hingeworfene 
Meinungsäußerungen derart aufregst).

: Bearbeitet durch Moderator
von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Was schmeißt du fremde Zitate in meine Argumentation?

Weil nicht nur du und ich an der Diskussion teilnahmen.

Der zitierte Satz war der Ausgangspunkt der ganzen Diskussionskette, 
deren Teil auch du bist.

> Aber der Ansatz, einen
> alternativen Compiler zu entwickeln, geht halt normalerweise nicht über
> das Studium von Prosa oder gar Sourcecode eines anderen Compilers,
> sondern über eine formale Sprachdefinition.

Offensichtlich geht es halt doch auch anders.

> Wenn es die nicht gibt, wird der alternative Compiler irgendwie immer
> der zweite Sieger bleiben.

Für dich.
Und das darfst du gerne so sehen.
Ich sehe das anders.

> ich weiß bloß
> nicht, warum du dich über solcherart begründungslos hingeworfene
> Meinungsäußerungen derart aufregst).

Wo genau rege ich mich auf?

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
>> Wenn es die nicht gibt, wird der alternative Compiler irgendwie immer
>> der zweite Sieger bleiben.
>
> Für dich.
> Und das darfst du gerne so sehen.
> Ich sehe das anders.

Du hast ja schon mehrfach (Auch gerade wieder im benachbarten Thread 
Beitrag "Komplexe typedef struct mit 0 initialisieren") gezeigt, dass du dich 
nicht wirklich dafür interessierst, wie die Sprache etwas definiert. 
Hauptsache der Compiler schluckt es.

von MaWin O. (mawin_original)


Lesenswert?

Mombert H. schrieb:
> Auch gerade wieder im benachbarten Thread

Kannst du bitte aufhören hier den Thread zuzumüllen?
Danke.

von cppbert (Gast)


Lesenswert?

Wo kommt denn bitte diese ganze altmodische, absolutistische (Ein 
Standard, Ein Kompiler, Ein Entscheider) Denkweise her?
Es ist doch keines der komplexen Systeme die wir heute verwenden so 
enstanden?
Und der Entwicklungsprozess war deswegen nicht besser oder schlechter - 
das ist eben Evolution in komplexen Systemen - und dazu zählen auch 
Programmiersprachen

bestes Beispiel die Programmiersprache(n): C/C++ - von der wir 
hoffentlich alle Wissen das sie einer doch noch immer einflussreichsten 
Sprachen der Welt ist

Es gab über Jahrzehnte nur ein paar Player auf dem Kompilermarkt - 
Microsoft, GCC, Intel, ... die waren auch alle gar nicht so super 
kompatible - jeder hat sich so weit wie möglich am Marktstärksten (nicht 
unbedingt am Standard) orientiert, Microsoft hat Micro-Details in "sein" 
C++ eingebaut wo es nur ging

das waren Jahrzehnte des unklaren driftens - da war die Frage immer erst 
"Mit welchem C++ Kompiler wurde das gebaut"

Und wer die Erfahrung nicht gemacht hat weil zu Jung oder nicht in dem 
Business war kann hier so gut wie gar keinen Senf zu abgeben

und das C++ Konsortium konnte das so gut wie nicht unter kontrolle 
halten

dann kam der LLVM/Clang - das Geschrei war laut - "noch ein Kompiler, 
noch mehr Probleme, können wir uns nicht auf einen konzentrieren, 
Blababla..."

aber es kam auch:
-der LLVM/Clang wurde so gut das der GCC mal wieder kämpfen musste und 
wieder besser wurde
-beide haben sich unglaublich beschleunigt in besserer Diagnose, Support 
von neueren Standards, weniger Sonderfeatures die wirklich nicht sind 
portierbar sind und,und,und
-selbst Microsoft musste sich dem ganzen beugen und hat wieder richtig 
konstruktiv begonnen an der Sprache und dem Kompilern mitzuarbeiten

das alles weil "nur" ein neuere Kompiler aufgetaucht ist - ohne Clang 
wäre das wohl alles nicht passiert

niemand der offenen Auges durch die C/C++ Branche wandelt kann das nur 
im entfernsteten Bestreiten - die letzten Jahren sind wirklich 
erstaunlich
weil endlich mal wieder richtige Evolution passiert ist - der geistige 
GCC "Fork" machte Konkurrenz und hat den Markt einfach mal wieder wach 
gerüttelt

das ist typische evolutionäre Entwicklung wie sie für komplexe System 
nötig ist - das schadet nicht - dauert nur länger als wenn der einzge 
König/Firma/Konsortium von oben die perfekten Vorgaben macht - die 
Systeme sind viel zu umfangreich geworden als das so etwas nur noch im 
Ansatz sinnvoll funktioniert - und das haben alle Grossen der Branche 
schon lange verstanden und arbeite (Achtung Buzword) "Agil" an Lösungen 
- so lange bis sich der richtige Standard durch Leistung und Überleben 
herauskristalisiert, bis der auch wieder unrelevant wird

die meisten Argumente sind völlig sinnfrei weil sich sowiso die Systeme 
durchsetzen die passen - ob UNS das dann immer passt ist eine andere 
Frage

und ein Sprachstandard in der 1. Stunde hat auch Javascript nicht 
verhindern können :)

von cppbert (Gast)


Lesenswert?

und die besten Flitzpiepen sind die welche Denken das sich Linus und 
Greg Kroah-Hartman und andere unbedacht eine Sprache in ihren Kernel 
holen die dann ihr Lebenswerk verschlechtert

so Idioten-Argumente wie:
-ob die wissen das Rust gar nicht mit dem gcc kompiliert werden kann
-das Cargo dann alle Kernel-Dependecies dann aus dem Internet holen muss
-man doch lieber go nehmen sollte
usw.

das ist so unglaublich naiv das es schon weh tut

von MaWin (Gast)


Lesenswert?

cppbert schrieb:
> das ist so unglaublich naiv das es schon weh tut

So ist das halt, wenn man sich für den größten Sprachexperten der Welt 
hält.
Da werden dann schon einmal gerne Sprachen totgesagt, die weltweit 
gerade steil gehen. Was dem Mikrocontroller.net-Experten nicht gut genug 
ist, kann auch nix sein.

> -ob die wissen das Rust gar nicht mit dem gcc kompiliert werden kann
> -das Cargo dann alle Kernel-Dependecies dann aus dem Internet holen muss

Exakt dies. Diese zwei Fragen wurden vor Jahren bereits von den 
Kernelexperten diskutiert und verstanden.

von cppbert (Gast)


Lesenswert?

oder

jetzt wo der Linus das erstmal eine andere Programmiersprache für den 
Kernel präsentiert bekommt ist er blöderweise anr Rust geraten, der kann 
das bestimmt null einschätzen - die anderen beteiligten bestimmt auch 
nicht - die wurden bestimmt überredet, so hilflos...

das ist mehr oder minder der überspitzte Inhalt der meisten Diskussionen
- als hätten die Kernel-Entwickler so mehr oder minder zufällig ~30Mio 
Zeilen Code zusammengeschraubt die unsere Welte mehr oder minder am 
Laufen hält :)

von cppbert (Gast)


Lesenswert?

mehr oder minder

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> Exakt dies. Diese zwei Fragen wurden vor Jahren bereits von den
> Kernelexperten diskutiert und verstanden.

dieses Argument schlägt alle Rekorde - es ist seit Jahren unrelevant 
weil man es machen kann wie man will - und die Kernel-Leute machen das 
auch so

aber es kommt immer und immer und immer wieder hoch

von cppbert3 (Gast)


Lesenswert?

Und der fehlende Sprachstand juckt Microsoft, Amazon und x andere null, 
nicht mal das GCC Steering Committee interessiert das

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


Lesenswert?

MaWin schrieb:
> Wo genau rege ich mich auf?

"Dummes Blah.", "ihr Knalltüten" – bestimmt findet sich noch mehr.

Unterstellte Lernunwilligkeit: "Ich glaube ihr habt eher Angst vor 
Umbrüchen und Neuem.", obwohl man was ganz anderes kritisiert.

cppbert schrieb:
> Es gab über Jahrzehnte nur ein paar Player auf dem Kompilermarkt -
> Microsoft, GCC, Intel

Es gab deutlich mehr, du beschreibst nur die PC-Welt. Fängt ja schon 
damit an, dass C++ als erstes durch CFront implementiert worden war, 
initial völlig außerhalb der PC-Welt.

Die anderen waren und sind auch nicht so schräg drauf wie beispielsweise 
Microsoft, die erst nach Jahrzehnten überhaupt mal einen neuen Standard 
akzeptieren können. Bis auf notwendigerweise nicht von einem Standard 
abdeckbare Dinge (wie Interrupts) konnte und kann man beispielsweise 
klaglos Programme für Microcontroller von GCC und IAR compilieren 
lassen.

Die C++-Welt mag da mit ihrem Featurismus anders ticken, für C ist die 
Entwicklung eher langsam vonstatten gegangen. Aber natürlich, 
Entwicklung gab es immer, und der übliche Weg bei internationalen 
Standards ist es, dass das Standardisierungsgremium Dinge übernimmt, die 
sich bereits in der Praxis bewährt haben, statt sich Dinge selbst 
auszudenken. Trotzdem gab es da immer eine gemeinsame Basis, die recht 
gut beschrieben war und ist (und das auch schon vor dem ersten 
C-Standard, sonst hätte es beispielsweise einen GCC nie geben können – 
der kam zwei Jahre vor dem ersten offiziellen Standard heraus).

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> sonst hätte es beispielsweise einen GCC nie geben können –
> der kam zwei Jahre vor dem ersten offiziellen Standard heraus

Was? Das ist ja ungeheuerlich!
Wie kann das sein? Das ist doch völlig unmöglich Compiler ohne Standard 
zu entwickeln, habe ich hier gelernt.

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> cppbert schrieb:
>
>> Es gab über Jahrzehnte nur ein paar Player auf dem Kompilermarkt -
>> Microsoft, GCC, Intel
>
> Es gab deutlich mehr, du beschreibst nur die PC-Welt.

Ja das hatte ich vergessen zu erwähnen, aber das ist ja auch ein grosser 
Teil des Markts

> Die C++-Welt mag da mit ihrem Featurismus anders ticken, für C ist die
> Entwicklung eher langsam vonstatten gegangen. Aber natürlich,
> Entwicklung gab es immer, und der übliche Weg bei internationalen
> Standards ist es, dass das Standardisierungsgremium Dinge übernimmt, die
> sich bereits in der Praxis bewährt haben, statt sich Dinge selbst
> auszudenken. Trotzdem gab es da immer eine gemeinsame Basis, die recht
> gut beschrieben war und ist (und das auch schon vor dem ersten
> C-Standard, sonst hätte es beispielsweise einen GCC nie geben können –
> der kam zwei Jahre vor dem ersten offiziellen Standard heraus).

Bei C ist das auch viel einfacher weil die Sprach recht ausdrucksschwach 
ist, ganz neutral ausgedrueckt

Wenn es in der Praxis keine guten Lösungen gibt muss man sich neues 
ausdenken, auch wenn viele gar keine Probleme sehen die man angreifen 
sollte/könnte

Es hört sich leider oft so an als würden hier viele glauben das ein zur 
zeit nicht bestehender Standard automatisch irgendwie zu Chaos führt der 
irgendwie nicht mehr kontrollierbar wäre, genauso wie ein zweiter 
Kompiler, das ist zu drastisch gedacht und Realitätsfern, wer sollte 
interesse an sowas haben und zu welchem Zweck (mal die Schattenregierung 
ausser vor gelassen)

Wie gesagt das GCC Steering Comittee stört das gerade nicht sonderlich 
und viele andere auch nicht, wiso sind die nicht so kritisch?

von cppbert3 (Gast)


Lesenswert?

cppbert3 schrieb:
> auch wenn viele gar keine Probleme sehen die man angreifen sollte/könnte

Das ist ungefähr der selbe Prozentsatz der auch keine Sanitizer braucht 
oder nutzt :)

von cppbert3 (Gast)


Lesenswert?

cppbert3 schrieb:
> cppbert3 schrieb:
>
>> auch wenn viele gar keine Probleme sehen die man angreifen sollte/könnte
>
> Das ist ungefähr der selbe Prozentsatz der auch keine Sanitizer braucht
> oder nutzt :)

Was nicht bedeutet das logische Fehler nicht auch ein grosser Teil der 
üblichen Fehler sind

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


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>> sonst hätte es beispielsweise einen GCC nie geben können –
>> der kam zwei Jahre vor dem ersten offiziellen Standard heraus
>
> Was? Das ist ja ungeheuerlich!
> Wie kann das sein? Das ist doch völlig unmöglich Compiler ohne Standard
> zu entwickeln, habe ich hier gelernt.

Du hast bis jetzt den Unterschied zwischen einer formalen 
Sprachdefinition und einem (irgendwie "offiziellen", ISO oder was auch 
immer) Standard noch nicht verstanden, obwohl dir nun bereits mehrere 
Leute versucht haben, diesen zu verdeutlichen.

Dafür titulierst du andere als Knalltüten und was weiß ich nicht was.

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> Du hast bis jetzt den Unterschied zwischen einer formalen
> Sprachdefinition und einem (irgendwie "offiziellen", ISO oder was auch
> immer) Standard noch nicht verstanden, obwohl dir nun bereits mehrere
> Leute versucht haben, diesen zu verdeutlichen.
> Dafür titulierst du andere als Knalltüten und was weiß ich nicht was.

Weil hier die Leute so auf Microdetails achten und dann darauf rumreiten

Und nochmal das GCC Steering Committee stört es nicht, warum jemanden 
hier?
Oder besser warum ist das nur hier ein Argument?

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


Lesenswert?

cppbert3 schrieb:
> Oder besser warum ist das nur hier ein Argument?

Ob das "nur hier" eins ist, weiß ich nicht. Ich habe auch keine Idee, 
was die GCC-Leute so bewegt und was sie als Kriterien für irgendwelche 
Frontends haben. Schätzungsweise wird die aktuell erlangte Popularität 
von Rust schon dazu beigetragen haben, das dort offiziell mit 
aufzunehmen.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Du hast bis jetzt den Unterschied zwischen einer formalen
> Sprachdefinition und einem (irgendwie "offiziellen", ISO oder was auch
> immer) Standard noch nicht verstanden, obwohl dir nun bereits mehrere
> Leute versucht haben, diesen zu verdeutlichen.

Ahh. Jetzt verstehe ich!
Diese formale Sprachdefinition ist also der Teil, der eine erfolgreiche 
Sprache von einem Fehlschlag unterscheidet. Endlich erklärt mir das mal 
jemand.

Jetzt solltet ihr das auch noch Mozilla, Linus, Microsoft und vielen 
anderen Stümpern erklären.

> Dafür titulierst du andere als Knalltüten und was weiß ich nicht was.

Ich bitte um Entschuldigung.
Ich wusste bisher nicht, dass Mozilla, Linus, Microsoft und die vielen 
anderen Stümper in Wahrheit die merkbefreiten Knalltüten sind und nicht 
die Mitglieder des Mikrocontroller.net-Forums.

cppbert3 schrieb:
> Weil hier die Leute so auf Microdetails achten und dann darauf rumreiten

So ist das nun einmal, wenn man sich mit der Materie nicht auskennt. 
Dann pickt man sich irgendein Detail raus und reitet darauf herum und 
erklärt den gccrs mal eben für gescheitert.

Jörg W. schrieb:
> Ob das "nur hier" eins ist, weiß ich nicht.

Das kann ich dir auch nicht sagen.
Aber für Mozilla, Linus, Microsoft und die vielen anderen Stümper, ist 
es offenbar kein Argument.

Jörg W. schrieb:
> Schätzungsweise wird die aktuell erlangte Popularität
> von Rust schon dazu beigetragen haben

Wie kam es überhaupt zu dieser Popularität? So ganz ohne formale 
Sprachdefinition.

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> cppbert3 schrieb:
>
>> Oder besser warum ist das nur hier ein Argument?
>
> Ob das "nur hier" eins ist, weiß ich nicht. Ich habe auch keine Idee,
> was die GCC-Leute so bewegt und was sie als Kriterien für irgendwelche
> Frontends haben. Schätzungsweise wird die aktuell erlangte Popularität
> von Rust schon dazu beigetragen haben, das dort offiziell mit
> aufzunehmen.

gilt das deiner Meinung nach auch für den Linux-Kernel?

Was sagt das über die Entscheidungsqualtät der an diesen Projekten 
beteiligten Personen aus?

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


Lesenswert?

MaWin schrieb:

> Diese formale Sprachdefinition ist also der Teil, der eine erfolgreiche
> Sprache von einem Fehlschlag unterscheidet.

Du erzählst schon wieder völligen Unfug, um mal mit deinen Worten zu 
reden – vielleicht verstehst du so eine Sprache ja besser, denn keiner 
(von den ernsthaften Diskutanten) hat behauptet, dass Rust ein 
Fehlschlag sei.

Mit dir zu diskutieren, erweist sich wiederholt schlicht als sinnlos, du 
drehst alles so herum, dass du dich maximal drüber aufregen kannst. Ich 
sollte meine Zeit besser darauf verwenden, was Vernünftiges zu tun, 
vielleicht endlich mal wieder VHDL anzusehen zum Beispiel. Das wäre mir 
beispielsweise aktuell wichtiger als Rust.

von cppbert3 (Gast)


Lesenswert?

Und ja MaWin kann patzig sein, ihr seit das aber auch irgendwie, GUT IST

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


Lesenswert?

cppbert3 schrieb:

> gilt das deiner Meinung nach auch für den Linux-Kernel?

Beides dürfte miteinander im Zusammenhang stehen. Linux möchte GCC 
(während bspw. Apple extra den Clang gepusht hat, um von GCC 
wegzukommen), und für GCC ist es wiederum ein wesentliches 
Anwendungsfeld.

ps: Andererseits ist natürlich für Linux ein anwendungsfähiger Compiler 
das wesentliche Kriterium, nicht irgendeine formale Sprachdefinition, 
das ist wohl keine Frage. Dürfte im Gegenzug den Druck auf GCC erhöht 
haben, sich der Sprache zu widmen.

: Bearbeitet durch Moderator
von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> MaWin schrieb:
>
>> Diese formale Sprachdefinition ist also der Teil, der eine erfolgreiche
>> Sprache von einem Fehlschlag unterscheidet.
>
> Du erzählst schon wieder völligen Unfug, um mal mit deinen Worten zu
> reden – vielleicht verstehst du so eine Sprache ja besser, denn keiner
> (von den ernsthaften Diskutanten) hat behauptet, dass Rust ein
> Fehlschlag sei.

Das sagt er nur überspitzt und alle anderen reagieren wieder mit 
Microdetails, das kann sehr wirklich nervig sein, was leider auch ein 
wenig typisch für das Forum ist

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


Lesenswert?

cppbert3 schrieb:
> Das sagt er nur überspitzt

Naja, andere würden es als sehr persönliche Beleidigung empfinden, wenn 
sie als "Knalltüten" bezeichnet werden, nur weil sie eine andere Meinung 
haben als er.

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> cppbert3 schrieb:
>
>> Das sagt er nur überspitzt
>
> Naja, andere würden es als sehr persönliche Beleidigung empfinden, wenn
> sie als "Knalltüten" bezeichnet werden, nur weil sie eine andere Meinung
> haben als er.

Du machst es schon wieder, lass doch dieses Satz-Sezieren, das ist 
deiner unwürdig

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> du drehst alles so herum

Ich verdrehe hier die Tatsachen? Sehr interessante Sichtweise.

> dass du dich maximal drüber aufregen kannst.

Wie bereits mehrfach gesagt: Ich rege mich hier überhaupt nicht auf. Ich 
amüsiere mich prächtig.

> Du erzählst schon wieder völligen Unfug

Ach. Sag bloß. Könnte das daran liegen, dass das nicht ganz ernst 
gemeint war und bewusst so formuliert war?

cppbert3 schrieb:
> Das sagt er nur überspitzt und alle anderen reagieren wieder mit
> Microdetails,

Du hast es gut erkannt. ;)

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> cppbert3 schrieb:
>
>> gilt das deiner Meinung nach auch für den Linux-Kernel?
>
> Beides dürfte miteinander im Zusammenhang stehen. Linux möchte GCC
> (während bspw. Apple extra den Clang gepusht hat, um von GCC
> wegzukommen), und für GCC ist es wiederum ein wesentliches
> Anwendungsfeld.
> ps: Andererseits ist natürlich für Linux ein anwendungsfähiger Compiler
> das wesentliche Kriterium, nicht irgendeine formale Sprachdefinition,
> das ist wohl keine Frage. Dürfte im Gegenzug den Druck auf GCC erhöht
> haben, sich der Sprache zu widmen.

Ich finde es wiederum erstaunlich wie wenig Frontend man nur braucht um 
ins main repo zu kommmen, aber trotzdem ist es gut, das wird 
schlussendlich eine Menge mehr Entwickler an die Sprache bringen, sie 
muss gequält werden damit was gutes entstehen kann

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> Jörg W. schrieb:
>
>> du drehst alles so herum
>
> Ich verdrehe hier die Tatsachen? Sehr interessante Sichtweise.

Du musst aber auch mal aufhören Öl ins Feuer zu schütten :)

von MaWin (Gast)


Lesenswert?

cppbert3 schrieb:
> aber trotzdem ist es gut, das wird
> schlussendlich eine Menge mehr Entwickler an die Sprache bringen, sie
> muss gequält werden damit was gutes entstehen kann

Genau so ist es.

Alles dies wird passieren.
Was garantiert nicht passieren wird ist das, was hier im Forum 
postuliert wird.
Gccrs wird nicht die zweite unbedeutende Geige spielen.
Gccrs wird nicht in endlosen Grabenkämpfen zu strict aliasing ertrinken.

Es wird Meinungsverschiedenheiten geben. Und das ist etwas Gutes! Denn 
nur durch das Lösen von Meinungsverschiedenheiten kann wirkliche 
Weiterentwicklung entstehen.

Das gilt auf für Forumsmitglieder. Die "guten alten Zeiten", wo man sich 
erst einmal um eine formale Sprachdefinition kümmerte, sind vorbei. 
Genauer gesagt, gab es diese Zeiten nie.
Moderne Sprachen sind so komplex, dass es erst einmal wichtiger ist sie 
praktisch nutzbar zu machen, als irgendein furztrockenes Dokument zu 
erstellen, das niemandem weiterhilft.

Und falls ihr dennoch der Meinung seid, dass man jetzt direkt eine 
Sprachdefinition braucht: Rust ist Open Source. Also bitte.
Oder ihr müsst euch von dieser Denkweise lösen.

von cppbert3 (Gast)


Lesenswert?

Schon wieder Öl, wenn auch nur in Tropfen

von cppbert3 (Gast)


Lesenswert?

MaWin schrieb:
> Gccrs wird nicht in endlosen Grabenkämpfen zu strict aliasing ertrinken.

Dann bekommt der gcc auch mal endlich die Möglichkeit über x Versionen 
strict aliasing Fehler im Kompiler zu finden, genau so wie der LLVM 
leiden musste

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


Lesenswert?

cppbert3 schrieb:
> das wird schlussendlich eine Menge mehr Entwickler an die Sprache
> bringen

Da vermute ich, dass der Einfluss von Linux größer ist als der von GCC.

Den Leuten, die die Sprache benutzen wollen, ist das vermutlich 
mittelmäßig egal, solange es mindestens einen brauchbaren (und freien) 
Compiler gibt, die könn(t)en also auch ohne GCC prima damit arbeiten. 
Die Affinität zu einem bestimmten Compiler hat ja eher religiöse, äh, 
lizenzpolitische Gründe (Apple -> kein GPL, Linux -> unbedingt GPL).

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> Die Affinität zu einem bestimmten Compiler hat ja eher religiöse, äh,
> lizenzpolitische Gründe (Apple -> kein GPL, Linux -> unbedingt GPL).

Das schon aber sehr lange Zeit war der Kernel aber auch voll mit GCC 
Spezialitäten (so viel zu wohldefinierten Standards), ich glaube es ist 
immer nicht so einfach den Kernel mit Clang zu bauen, oder

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
> Jetzt solltet ihr das auch noch Mozilla, Linus, Microsoft und vielen
> anderen Stümpern erklären.

Ich wäre gern die Fliege an der Wand, wenn du Linus ins Gesicht als 
Stümper bezeichnest...

> Dann pickt man sich irgendein Detail raus und reitet darauf herum und
> erklärt den gccrs mal eben für gescheitert.

Gescheitert ist das falsche Wort. Aber der Einfluss - außerhalb von 
Linux - dürfte wesentlich geringer bleiben, bis es eine Spezifikation 
gibt.

> Wie kam es überhaupt zu dieser Popularität?
> So ganz ohne formale Sprachdefinition.

Wie bei Javascript, ebenfalls eine der besten Programmiersprachen, die 
dieser Planet jemals hervorgebracht hat.

Jörg W. schrieb:
> Den Leuten, die die Sprache benutzen wollen, ist das vermutlich
> mittelmäßig egal, solange es mindestens einen brauchbaren (und freien)
> Compiler gibt, die könn(t)en also auch ohne GCC prima damit arbeiten.

Viele Sprachen haben nur genau einen relevanten Compiler (bzw. alle 
anderen sind effektiv Forks - mangels gebrauchbarer Spezifikation) und 
sie werden trotzdem benutzt.

Wer sich in die Abhängigkeit begeben will, den kann man daran nicht 
hindern. Suizid ist schließlich auch nicht strafbar.

> Die Affinität zu einem bestimmten Compiler hat ja eher religiöse, äh,
> lizenzpolitische Gründe (Apple -> kein GPL, Linux -> unbedingt GPL).

Nicht nur, die Geldflüsse wären da auch zu betrachten. Wo das Geld in 
Massen hinströmt, da wollen alle anderen auch hin. Erstmal anstellen, 
wenn man eine Warteschlange sieht, egal warum.

von S. R. (svenska)


Lesenswert?

cppbert3 schrieb:
> Das schon aber sehr lange Zeit war der Kernel aber auch voll mit GCC
> Spezialitäten (so viel zu wohldefinierten Standards), ich glaube es ist
> immer nicht so einfach den Kernel mit Clang zu bauen, oder

Der Kernel hat aber auch nie behauptet, in C geschrieben zu sein.
Und er wird sicher auch nie behaupten, in Rust geschrieben zu sein.
Aus den gleichen Gründen.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Den Leuten, die die Sprache benutzen wollen, ist das vermutlich
> mittelmäßig egal, solange es mindestens einen brauchbaren (und freien)
> Compiler gibt, die könn(t)en also auch ohne GCC prima damit arbeiten.

Nein. Es gibt ganz praktische Vorteile von GCC. Beispielsweise das enorm 
viel breitere Spektrum an unterstützten Architekturen. Das bedeutet zwar 
nicht, dass Gccrs automatisch auch alle diese unterstützt, aber es 
bereitet die notwendige Basis dafür.

Das ist der Schlüssel für Rust-Embedded.

> Linux -> unbedingt GPL

Die Bindung von Linux an GCC hat rein technische Gründe.
Sie fußt in der enormen Nutzung von GCC-Extensions in Linux.
Das Linux-clang-Projekt ist (war? Ich weiß den aktuellen Zustand nicht) 
ein enorm großes Projekt.

von MaWin (Gast)


Lesenswert?

Achja, falls das hier manchen nicht klar ist:

GCC + Rust gibt es in zwei Varianten.
1) Rust-Frontend in GCC. Darum ging es hier im Gespräch hauptsächlich.
2) GCC als codegen backend von rustc.

Beide werden aktiv entwickelt und beide sind wichtig für die Sprache.
(1) ist ein eigenständiges Projekt und (2) ist (wird) Teil vom 
ursprünglichen Rust-Compiler.

von cppbert3 (Gast)


Lesenswert?

S. R. schrieb:
> MaWin schrieb:
>
>> Jetzt solltet ihr das auch noch Mozilla, Linus, Microsoft und vielen
>> anderen Stümpern erklären.
>
> Ich wäre gern die Fliege an der Wand, wenn du Linus ins Gesicht als
> Stümper bezeichnest...

Alles nur halb zu lesen ist hier echt Standard im Forum, es ging darum 
das Linus Rust im Kernel akzeptiert und da Rust ja nicht gut ist es nur 
an Linus schlechtigkeit liegen kann das er die Sprache akzeptiert

Nur damit auch du es peilst: MaWin ist Pro Rust UND Pro Linux/Linus :)

von cppbert3 (Gast)


Lesenswert?

S. R. schrieb:
> cppbert3 schrieb:
>
>> Das schon aber sehr lange Zeit war der Kernel aber auch voll mit GCC
>> Spezialitäten (so viel zu wohldefinierten Standards), ich glaube es ist
>> immer nicht so einfach den Kernel mit Clang zu bauen, oder
>
> Der Kernel hat aber auch nie behauptet, in C geschrieben zu sein.
> Und er wird sicher auch nie behaupten, in Rust geschrieben zu sein.
> Aus den gleichen Gründen.

Und mit diese Microrelevanzaussage konter ich jetzt wie?

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


Lesenswert?

cppbert3 schrieb:
> ich glaube es ist immer nicht so einfach den Kernel mit Clang zu bauen

Clang hat allerdings von vornherein überall versucht, ein kompletter 
GCC-Ersatz zu sein und von daher auch allerlei GCC-Erweiterungen 
übernommen.

MaWin schrieb:
> Es gibt ganz praktische Vorteile von GCC. Beispielsweise das enorm viel
> breitere Spektrum an unterstützten Architekturen.

Ja, sicher, aber die, die jetzt Rust einsetzen, werden das 
schätzungsweise vorranging auf solchen Architekturen tun, für die es 
llvm-Backends gibt. llvm-Backends gibt's ja schließlich auch für alles 
Mögliche inzwischen.

Im "deeply embedded" (also echte Microcontroller, keine miniaturisierten 
Allroundmachinen wie Raspberry etc.) hat man ja schon Mühe, mal jemanden 
zu finden, der wenigstens C++ akzeptieren würde. Sehe ich in den 
diversen Jobs meiner letzten Jahre, selbst an Stellen, wo ein OO-Ansatz 
durchaus günstig wäre, findet man kaum Kundschaft, der das als Argument 
für C++ ausreichend ist. Bis Rust dort ankommt (und damit jenseits 
dessen, was llvm als Backends hat), wird noch 'ne Menge Wasser Rhein und 
Elbe herunter fließen.

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


Lesenswert?

MaWin schrieb:
> Das Linux-clang-Projekt ist (war? Ich weiß den aktuellen Zustand nicht)
> ein enorm großes Projekt.

Interessanterweise schien bei FreeBSD der Aufwand doch recht 
überschaubar. Bei denen ist nun schon seit einigen Jahren Clang als 
Standard dabei – und ein Kernel hat logischerweise auch dort 'ne ganze 
Reihe von Compiler-Erweiterungen benutzt.

von cppbert3 (Gast)


Lesenswert?

Jörg W. schrieb:
> Clang hat allerdings von vornherein überall versucht, ein kompletter
> GCC-Ersatz zu sein und von daher auch allerlei GCC-Erweiterungen
> übernommen.

Trotzdem hat es Jahre gedauert bis das richtig ging

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> und ein Kernel hat logischerweise auch dort 'ne ganze
> Reihe von Compiler-Erweiterungen benutzt.

Linux nutzt wesentlich mehr GCC-Spezialitäten als BSD. Linux verwendet 
auch GCC-Plugins.
Die Grundfunktionalität (ein funktionierendes Linux-System) lässt sich 
schon länger mit clang erzeugen. Aber alle Features gingen zumindest bis 
vor ein paar Jahren noch nicht. Wie es aktuell ist, weiß ich nicht.

Jörg W. schrieb:
> Clang hat allerdings von vornherein überall versucht, ein kompletter
> GCC-Ersatz

Die Worte "überall" und "kompletter" würde ich hier weglassen und durch 
sowas wie "weitgehend" ersetzen.
Selbst auf ABI-Ebene ist LLVM nicht vollständig kompatibel. (128Bit 
Integers). Was aber eher als ein Bug angesehen wird.

Jörg W. schrieb:
> Ja, sicher, aber die, die jetzt Rust einsetzen, werden das
> schätzungsweise vorranging auf solchen Architekturen tun, für die es
> llvm-Backends gibt.

Auch für die Leute, die jetzt Rust einsetzen, bringt jeder weitere 
Compiler nur Vorteile. Second Source. Bessere Sprachdefinition. Bessere 
Testabdeckung.

> llvm-Backends gibt's ja schließlich auch für alles
> Mögliche inzwischen.

Es kommt auch auf die Qualität der Backends an. Das AVR-Backend in clang 
ist nicht wirklich gut. Da will man GCC haben (Ja, das ist vielleicht 
ein schlechtes Beispiel, weil GCC-AVR auch nicht mehr wirklich 
weiterentwickelt wird. Aber besser als clang ist es).

Jörg W. schrieb:
> Bis Rust dort ankommt (und damit jenseits
> dessen, was llvm als Backends hat), wird noch 'ne Menge Wasser Rhein und
> Elbe herunter fließen.

Das ist richtig. Aber das ist kein Problem, was Rust lösen kann. Das 
muss sich in den Betonköpfen der Nutzer-Projektentscheider lösen.
C++ wäre ein Schritt in die richtige Richtung. Aber bitte mit wenig OOP. 
Sonst muss man die wieder abtrainieren, wenn man zu Rust wechselt ;)

von S. R. (svenska)


Lesenswert?

MaWin schrieb:
> Nein. Es gibt ganz praktische Vorteile von GCC. Beispielsweise das enorm
> viel breitere Spektrum an unterstützten Architekturen. Das bedeutet zwar
> nicht, dass Gccrs automatisch auch alle diese unterstützt, aber es
> bereitet die notwendige Basis dafür.

Alternativ portiert man diese Architekturen nach LLVM. Das ist wegen der 
GPL sowieso der bevorzugte Weg für viele Firmen, wenn sie den Aufwand 
überhaupt treiben wollen.

> Die Bindung von Linux an GCC hat rein technische Gründe.
> Sie fußt in der enormen Nutzung von GCC-Extensions in Linux.

Ja und nein. Clang will aus lizenztechnischen Gründen ein vollwertiger 
Ersatz sein und implementiert daher auch alle relevanten GCC-Extensions. 
Technische Gründe gibt es daher keine mehr, und die politischen Gründe 
werden auch weniger, weil viel Geld in bestimmte Richtungen fließt.

> Das Linux-clang-Projekt ist (war? Ich weiß den aktuellen
> Zustand nicht) ein enorm großes Projekt.

Sämtliche Android-Kernel werden ausschließlich mit Clang gebaut. Google 
hat außerdem die letzten Jahre sehr viel (erfolgreich) investiert, um 
die Unterschiede zum Mainline-Kernel zu reduzieren.

Dazu kommt, dass so gut wie alle Mitstreiter am Kernel heutzutage dafür 
bezahlt werden. Ein großer Teil der betroffenen Firmen kommen aus dem 
Embedded-Bereich und dort ist Android-Kompatiblität wichtig. Also baut 
der Code auch mit clang (und dessen Forks) bzw. wird nur damit getestet.

Das von dir genannte Projekt war vor allem deswegen kompliziert, weil 
(a) clang damals einige GCC-Extensions nicht kannte; (b) der Kernel 
nicht nur GCC-Extensions benutzt, sondern auch gezielt GCC-Verhalten 
ausgenutzt hat; (c) der Kernel "fix clang-issue"-Patches ablehnt, wenn 
sie keine Bugs fixen oder die Performance mit GCC sinkt.

cppbert3 schrieb:
> Nur damit auch du es peilst: MaWin ist Pro Rust UND Pro Linux/Linus :)

Ich bin nicht doof. MaWin ist einfach nur der bessere Troll. :(

cppbert3 schrieb:
>> Der Kernel hat aber auch nie behauptet, in C geschrieben zu sein.
>> Und er wird sicher auch nie behaupten, in Rust geschrieben zu sein.
>> Aus den gleichen Gründen.
>
> Und mit diese Microrelevanzaussage konter ich jetzt wie?

Warum willst du da kontern? Linux ist schlicht nicht in C geschrieben, 
sondern in (einem Subset von) GCC-C. Portabilität und 
Compilerabhängigkeit sind schlicht irrelevant.

Clang implementiert auch GCC-C (identifiziert sich auch als GNU-C), weil 
Google (und andere) dafür gesorgt haben. Deswegen ist es trotzdem kein 
C, aber in der Lage, den Kernel zu bauen.

Ich sehe keinen Grund, warum der Kernel das Thema Rust irgendwie anders 
handhaben sollte. Der Rust-Code im Kernel wird kein echtes Rust sein, 
sondern schlicht GCC-Rust (oder Kernel-Rust oder wie man das nennen 
mag). Inwieweit die auseinander laufen oder sogar inkompatibel 
zueinander werden, werden wir in der Zukunft sehen.

Jörg W. schrieb:
> Interessanterweise schien bei FreeBSD der Aufwand doch recht
> überschaubar. Bei denen ist nun schon seit einigen Jahren Clang als
> Standard dabei – und ein Kernel hat logischerweise auch dort 'ne ganze
> Reihe von Compiler-Erweiterungen benutzt.

FreeBSD (wie auch die Geschwister) hat ein eigenes Interesse, von 
GPL-Abhängigkeiten wegzukommen, nicht zuletzt durch Apple.

Viel habe ich nicht in BSD-Code geblättert, aber was ich gesehen habe, 
hat mir im Allgemeinen recht gut gefallen und sah auch stärker nach 
Standard-C aus als der Linux-Code. Entsprechend dürfte die Abhängigkeit 
auch schwächer (besser abstrahiert) gewesen sein.

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


Lesenswert?

S. R. schrieb:

> FreeBSD (wie auch die Geschwister) hat ein eigenes Interesse, von
> GPL-Abhängigkeiten wegzukommen, nicht zuletzt durch Apple.

Apple hat zwar mal den Anfang mit FreeBSD gemacht, aber macht seither 
sein eigenes Ding. Insofern ist FreeBSD (und insbesondere dessen 
verwendeter Compiler) für sie kaum relevant. Kommt hinzu, dass der 
Kernel eh Mach ist und kein BSD.

> Viel habe ich nicht in BSD-Code geblättert, aber was ich gesehen habe,
> hat mir im Allgemeinen recht gut gefallen und sah auch stärker nach
> Standard-C aus als der Linux-Code. Entsprechend dürfte die Abhängigkeit
> auch schwächer (besser abstrahiert) gewesen sein.

Das ist gut möglich, hat durchaus auch historische Gründe. BSD wollte 
schon immer portabel sein (und NetBSD ist daraus entstanden, weil Bill 
Jolitz teilweise auf Portabilität verzichtet hatte, um auf der von ihm 
anvisierten 80386-Plattform besser/schneller voran zu kommen), der Code 
war damit auch vor 30 Jahren schon sehr generisch. Linux war erstmal nur 
80386, und hat sich von da aus zu einem portablen System entwickelt. 
(Als ich vor Jahrzehnten mal in deren Floppytreiber geschaut habe, war 
beispielsweise sowas wie der DMA-Kanal fix per #define reincompiliert. 
In einem 386BSD hätte man auch damals schon mehr als einen 
Floppycontroller mit verschiedenen Hardwareparametern installieren 
können.)

von Ron T. (rontem)


Lesenswert?

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

Die Sprache hat sogar entscheidenden Einfluss. Und weil die 
sprachbedingte Komplexität über die Jahrzehnte so ausartet wird kaum 
eine der genannten Sprachen richtig Zukunft haben. Die gehört schlicht 
anderer Hardware inklusive intelligenterer Programmierformen- um hier 
mal KI ins Gedächtnis zu rufen.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Ron T. schrieb:
> um hier mal KI ins Gedächtnis zu rufen.

KI als Lösung zur Komplexitätsreduktion. Wow. Echt gut getrollt.

von rbx (Gast)


Lesenswert?

Steam macht einen echt netten Service für Skyrim. Die installierten Mods 
werden immer wieder "automagisch" auf den neuesten Stand gebracht. Diese 
Mods haben aber immer bestimmte eigene Probleme, da kann Steam nicht 
viel machen. Man ist gut beraten, jedes einzelne Mod für sich 
auszuprobieren, um fatale Veränderungen wirklich mitzubekommen. Viele 
bevorzugen aber ein 300 Mod Setup zum Start - aus welchem Grund auch 
immer - denn die "Vanilla" Version, also Skyrim ohne Mods ist schon 
toll. Mit vielen Mods als Standard kann man erstmal nicht so gut sehen, 
wenn man Probleme hat, wo sie herkommen.
Dann gibt es noch in der normalen Vanillaversion gewisse Probleme, aber 
man kann einiges mit dem Creation Kit und den Glitches abfangen bzw. 
ausbügeln, und natürlich mit der ein oder anderen Modifikation. Klar, 
man hätte sich noch ein paar Runden Qualitätssicherungen gefreut - Aber 
das ist halt irgendwie auch die Handschrift von Bethesda, dass die Dinge 
so sind wie sie sind.

Die Rust Entstehung ist interessant. Gehässigerweise könnte man fragen, 
ein neuer Lisp-Dialekt?
Früher gab es mal f2c. Heute dann c2r?
Fortran hat seine Stärken in der mathematischen Performance. C ist 
Systemnäher, Basic, die kleine Schwester von Fortran, war weniger 
systemnah, dafür aber fast überall verfügbar und man konnte es für viele 
Dinge einsetzen.
Python ist gewissermaßen in die Fußstapfen von Basic getreten.

Rein von der Werkzeug-Betrachtung her scheint Rust echt gut zu sein.

Programmierkulturtechnisch: schwierige funktionale Programmierung. Es 
gibt auch die "Lösung" "Funktionalität" in C++ zu importieren.

Stichwort: funktionale C++ Programmierung.

Wenn man auf die 60er Jahre schaut, dann eierte die Funktionale 
Programmierung/Lisp und ähnliche immer so mit, spielten aber - auch bei 
der Parallelisierung - meist nur die 2. oder 3. Geige - oder noch weiter 
hinten.

Das ist bei Rust ein wenig anders. Mit z.B. Haskell einen Compiler zu 
entwickeln - das ist eine wirklich sehr gute Möglichkeit, sowas zu tun.
Nicht dumm..

Nach hinten raus steht immer noch die Frage im Raum, lieber in C++ 
machen, oder nicht?
Ich denke, man sollte beides können. Grundsätzlich doof ist, wenn die 
funktionalen Hintergründe nicht verstanden werden.
Es ist halt eine Übungssache.

Und deswegen mag ich Haskell, obwohl es da z.B. mit dem ghc oder dem 
Drumherum (mal so mal so - wie denn jetzt?) oder der fehlenden 
Hardwarenähe auch recht problematisch zugeht.
Beim Lernen stört das aber erstmal nicht so.

Rust ist der pragmatische Ansatz.

https://mariusschulz.com/blog/fast-searching-with-ripgrep

von cppbert3 (Gast)


Lesenswert?

Auch wenn ich nicht ganz schlau draus werde was du mit dem Post sagen 
möchtest, ist er trotzdem irgendwie positiv

Die starken Funktionalen Bezüge in deinem Post kann ich nicht zuordnen 
den Rust ist wie C, C++ und viele andere eine imperative 
Programmiersprache ohne Funktionale Basis

von Roland F. (rhf)


Lesenswert?

Hallo,
cppbert3 schrieb:
> ... den Rust ist wie C, C++ und viele andere eine imperative
> Programmiersprache ohne Funktionale Basis

Wie ist dann in
https://de.wikipedia.org/wiki/Rust_(Programmiersprache)
das Programmierbespiel zur Berechnung der Fakultät zu verstehen?
Zitat:
"Alternativ erlaubt es Rust, das Problem im Sinne der funktionalen 
Programmierung anzugehen. Sogenannte Iterators bieten eine Möglichkeit, 
iterierbare Objekte zu verarbeiten. So lässt sich die Fakultät mit Hilfe 
des Iterators (1..=i) und dessen Methode product()[31] wie folgt 
darstellen..."

rhf

von Programmierer (Gast)


Lesenswert?

rbx schrieb:
> Python ist gewissermaßen in die Fußstapfen von Basic getreten.

Naja, meine These lautet: Der Erfolg von Python wird überbewertet.

Python ist heute nur wegen Numpy und dem ganzen KI-Kram so populär. Und 
Numpy entstand weil in den 1990er Mathworks mit ihrer Lizenzpolitik zu 
Matlab durchdrehte. Zusätzlich kam später IPython aka Jupyter dazu. 
Damit verfestigte sich Python im akademischen Sektor, einer Nische. Da 
aus der akademischen Welt auch die Entwicklung KI und Maschinelearning 
getrieben wurde, wurde natürlich das dort benutzte Python als 
Scriptsprache dafür verwendet.

Denn genau das ist Python nämlich: Eine Script-Sprache für Numpy und die 
ganzen Maschinelearning-Plattformen. Kaum einer wählt Python als Sprache 
für ein Projekt der Sprache selbst wegen, sondern weil er eben Numpy 
oder ein Maschinelearning-Paket benutzen will. Und die allermeisten 
Scripte die in diesem Bereich mit Python gebastelt werden, haben nur ein 
paar hundert Zeilen oder niedrige vierstellige Anzahl von Zeilen. Python 
ist der Nachfolger von Perl: Plattform für Wegwerf-Programme.

Egal. Zurück zu Rust:


rbx schrieb:
> Programmierkulturtechnisch: schwierige funktionale Programmierung.

Naja, die Masse muss erst funktionale Programmierung verinnerlichen. Bei 
OO war das nicht anders. Das hat auch Jahrzehnte gedauert, bis die 
"Hardcore-Imperativisten" in der Minderheit waren.

Aber OO hat seinen Zenit weit überschritten.

Natürlich hat OO ein Riesenmomentum, weil in der Zwischenzeit der 
Softwaresektor explodiert ist. Wenn man sich aber anschaut, wie die 
vielen Neulinge witzigerweise über Javascript mit funktionalen 
Paradigmen "infiziert" werden, und welchen Boom Haskell vor ca. 15 
Jahren erfuhr, und wie dieser Boom z.B. C++ und andere Sprachen, 
darunter sicherlich auch Rust, danach beeinflusst hat, hat der Siegeszug 
der Funktionalen Paradigmen schon längst begonnen.

Haskell ist toll, aber teilweise doch ziemlich akademisch und 
letztendlich für die Massenanwendung zu heftig.

Und genau da breitet sich Rust nun aus. Rust ist (etwas) anspruchsvoller 
als viele aktuelle Massensprachen, aber ein merkliches Stück einfacher 
als z.B. Haskell. Das ist glaub ein gute Mischung. Irgendwo habe ich mal 
gelesen: Rust sei das Haskell für die Praxis, oder so ähnlich. Dem 
stimme ich zu 100% zu.

Rust ist durch und durch eine imperative Sprache, allerdings lassen sich 
funktionale Konzepte und Paradigmen sehr gut damit verwenden bzw. 
umsetzen, weil es u.a. auch Summen-Datentypen hat. Fehlende 
Summen-Datentypen halte ich für das größte Manko vieler Sprachen.

(Und es wird ja in immer mehr Sprachen versucht, das irgendwie 
nachträglich reinzubasteln. Selbst Python versucht es inzwischen 
irgendwie mit seinem Structural Pattern Matching.)

Dazu, finde ich, ist bei Rust die Standardbibliothek außerordentlich gut 
gelungen.

Ob es nun einen Standard in einer vergleichbaren Form zu einem 
beliebigen anderen Sprachstandard gibt, ist meiner Meinung nach 
nebensächlich. Es gibt immer verschiedene Anwendungsgruppen von 
Software-Technologie. Es gibt Gruppen die nehmen neue Entwicklungen sehr 
früh auf und setzen sie produktiv und gewinnbringend ein, und andere 
Gruppen warten, bis es für jeden Furz der Technologie 100 Seiten 
ISO-Spezifikation gibt. Diese Gruppen hinken immer Jahrzehnte der 
Entwicklung hinterher. Sie sind aber auch kein Innovatoren und für 
Entwicklungen in der Software-Branche völlig bedeutungslos.

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


Lesenswert?

Programmierer schrieb:
> Python ist heute nur wegen Numpy und dem ganzen KI-Kram so populär.

Das hat sicher auch meiner Meinung nach massiv dazu beigetragen.

Aber ganz unabhängig davon ist natürlich der Interpreter, in dem man 
schnell mal einen Konstrukt eines größeren Scripts "vortesten" kann, ein 
sehr praktisches Hilfsmittel. Auch bei uns in der Industrie ist daher 
Python jenseits der Firmware ziemlich häufig im Einsatz. (Matlab sicher 
auch, aber mehr im tatsächlichen Mathematik-Umfeld.)

C, C#, C++, Java, Rust :) macht an der Stelle keiner.

von cppbert (Gast)


Lesenswert?

Rust erlaubt genau so wie C++ Funktional-artige Programmierung, aber 
Haskell ist Kilometer von Funktional-"artig" weg - Haskell ist 
vollwertig Funktional

der Vergleich Rust und Haskell macht keinen Sinn - aber scheinbar gibt 
es hier welche die da eine Ähnlichkeit sehen, es ist aber trotzdem eine 
ganz andere Art der Programmierung, deswegen die nicht so hohe 
durchdringung des Marktes

von Mombert H. (mh_mh)


Lesenswert?

Programmierer schrieb:
> Damit verfestigte sich Python im akademischen Sektor, einer Nische.
Einer Nische? Interessant.

Programmierer schrieb:
> Denn genau das ist Python nämlich: Eine Script-Sprache für Numpy und die
> ganzen Maschinelearning-Plattformen. Kaum einer wählt Python als Sprache
> für ein Projekt der Sprache selbst wegen, sondern weil er eben Numpy
> oder ein Maschinelearning-Paket benutzen will. Und die allermeisten
> Scripte die in diesem Bereich mit Python gebastelt werden, haben nur ein
> paar hundert Zeilen oder niedrige vierstellige Anzahl von Zeilen.
Worauf basiert diese Einschätzung?

Ich kenne niemanden, der (nur) wegen numpy zu Python gewechselt ist. 
numpy hat nicht viele Vorteile gegenüber Fortran und vermutlich genauso 
viele Nachteile. Das deutlich wichtigere Python Projekt ist matplotlib.

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


Lesenswert?

Mombert H. schrieb:
> numpy hat nicht viele Vorteile gegenüber Fortran

Der wesentliche Vorteil ist, dass man als Frontend zum alten 
FORTRAN-Kram eine benutzbare Programmiersprache bekommt, die man auch im 
21. Jahrhundert einigermaßen verstehen kann. ;-)

Ich denke, das ist genau der Punkt an dieser Stelle, und letztlich auch 
der, womit Matlab gepunktet hat (zumindest im Ursprung, mittlerweile 
eher mit Toolboxes für jede Lebenslage).

von cppbert (Gast)


Lesenswert?

Mombert H. schrieb:
> Programmierer schrieb:
>> Damit verfestigte sich Python im akademischen Sektor, einer Nische.
> Einer Nische? Interessant.

Off-Topic-Alarm: Es geht hier um Rust, bleibt dabei

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


Lesenswert?

cppbert schrieb:
> Es geht hier um Rust, bleibt dabei

Gibt's denn ein Eispack/Linpack-Frontend in Rust?

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Gibt's denn ein Eispack/Linpack-Frontend in Rust?

Keine Ahnung.
Das ist überhaupt nicht das Einsatzgebiet von Rust.
Nimm Python.

Rust ist eine Systems Programming Language.

von cppbert (Gast)


Lesenswert?

Jörg W. schrieb:
> cppbert schrieb:
>> Es geht hier um Rust, bleibt dabei
>
> Gibt's denn ein Eispack/Linpack-Frontend in Rust?

ich kenne nur https://nalgebra.org/ mit Lapack Bindings - keine Ahnung 
ob das was taucht

von cppbert (Gast)


Lesenswert?

MaWin schrieb:
> Keine Ahnung.
> Das ist überhaupt nicht das Einsatzgebiet von Rust.
> Nimm Python.
>
> Rust ist eine Systems Programming Language.

Das würde ich jetzt nicht einfach so sage - warum sollte Rust dafür 
ungeeignet sein - als Sprache?

von Kaj (Gast)


Lesenswert?

Für Lapack gibt es wrapper:
https://crates.io/crates/lapack

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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