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?

Jörg W. schrieb:
> Nur, wer braucht das? Wer etwas anders machen will, kann doch Rust
> nehmen (oder Python oder …).

Wie wäre es, wenn du dir das Video einmal anschaust, bevor du hier 
privilegiert trollst?

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


Lesenswert?

Du hast die Frage nicht beantwortet.

Aber willst du offenbar nicht. Da empfiehlt man nun schon mal, dass die 
Leute stattdessen doch lieber gleich was anderes machen sollten, isses 
dir auch nicht recht.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Du hast die Frage nicht beantwortet.

Wer diese Frage stellt, hat das Video nicht gesehen.
Das ist offensichtlich.

> Aber willst du offenbar nicht.

Genau. Wozu auch? Die Frage hat gar nichts mit Rust oder dem Video zu 
tun.

> Da empfiehlt man nun schon mal, dass die
> Leute stattdessen doch lieber gleich was anderes machen sollten, isses
> dir auch nicht recht.

Ach. Du bist ja so großzügig.
Du bist so ein großzügiger Troll, der hier nur nicht gelöscht wird, weil 
er Moderator ist.

Soll ich dir mal was sagen? Hm?
Gucke doch das Video. Wie wäre das?
Dann weißt du auch, worum es geht, und dann musst du dich hier nicht 
immer weiter bis auf die Knochen blamieren.

Peinlich, peinlich.

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


Lesenswert?

MaWin schrieb:
> Gucke doch das Video.

Die 1,5 h Zeit würde ich, wenn schon, lieber in Rust investieren.

Aber solange du einfach nur bei persönlichen Beschimpfungen bleiben 
willst, was soll's?

: Bearbeitet durch Moderator
von cppbert (Gast)


Lesenswert?

@Jörg W.

wenn es um C++2 geht - dann geht es eher darum das der Wechsel zwischen 
C++ und C++2 so absolut leicht und einfach sein soll wie möglich d.h. am 
besten 100% kompatibel - damit Firmen wie Microsft oder google die 
Mio/Mrd Zeilen von C++ haben leichter zwischen den Welten wandeln können 
ohne die geringsten Problem mit Kompiler/Toolchain etc. - bei solchen 
Codemengen, die ja täglich extrem wachsen sind auch mehrstufige 
Migrationen Richtung einfacher/fehlerfreier interessant

die Leute müssen sich einfach mal die Dimensionen vorstellen: wenn 2000 
oder mehr Entwickler an einem Codeberg arbeiten kann man teilweise im 
Sekundentakt die Repos wachsen sehen - das ist manchmal ganz schön 
beängstigen

@MaWin:

eine einfach kurze Antwort hätte gereicht - nicht jeder hier ist ein 
Troll und nicht alle sind einfach nur faul

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


Lesenswert?

cppbert schrieb:
> wenn es um C++2 geht - dann geht es eher darum das der Wechsel zwischen
> C++ und C++2 so absolut leicht und einfach sein soll wie möglich d.h. am
> besten 100% kompatibel

Das ist mir durchaus beim Ansehen des Videos (und der ja teils 
euphorischen Kommentare) klar geworden. Ich fürchte trotzdem, dass das 
nicht viel bringt, und dass es sinnvoller ist, es so wie Firefox zu 
machen und stückweise Subsysteme neu zu implementieren.

Dass das nicht von heute auf morgen gemacht ist, sieht man natürlich 
auch an Fifrefox.

von cppbert (Gast)


Lesenswert?

Jörg W. schrieb:
> Ich fürchte trotzdem, dass das
> nicht viel bringt, und dass es sinnvoller ist, es so wie Firefox zu
> machen und stückweise Subsysteme neu zu implementieren.

ja das Herb Sutter Beispiel ist ja nur ein Aufrüttler - was wäre wenn 
C++ sowas wie die Rust Editions hätte - was wäre möglich - Herb muss ja 
immer der am-weitesten-über-den-Tellerrand-schauer sein

aber auch Carbon von Chandler Carruth ist nicht ganz uninteressant

ich würde auch einfach neue Subsystem in Rust machen - aber ich muss 
auch keine 100Mio oder 2Mrd Zeilen Code unter Kontrolle halten - bei 
diesen Größenordnungen könnten Verbesserungen im niedrigen/sten 
Prozentbereich schon sehr viel bedeutung haben

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Das ist mir durchaus beim Ansehen des Videos (und der ja teils
> euphorischen Kommentare) klar geworden. Ich fürchte trotzdem, dass das
> nicht viel bringt, und dass es sinnvoller ist, es so wie Firefox zu
> machen und stückweise Subsysteme neu zu implementieren.

Das bestreitet niemand. Nicht einmal der Typ im Video.

In einem Pony-Wunderland würde ich auch gerne mit dem Finger schnippen 
und alles in Rust neuschreiben.

Aber das ist halt gar nicht das Thema. Das Thema war: Wie bringe ich 
moderne Eigenschaften von modernen Sprachen in C++ rein.
Deine Antwort "nutze halt moderne Sprachen" ist in diesem Kontext Unfug.

Eines der größten Probleme mit C++ ist, dass es nicht mit Altlasten 
aufräumen kann. C++ ist eine stinkende Müllhalde an legacy-Features, auf 
die oben drauf schön säuberlich leckere Früchte drapiert werden. Das ist 
der zentrale Punkt im Video. Das führt zwangsläufig dazu, dass neuer 
Schrottcode entwickelt wird, obwohl das verhinderbar wäre.
Diesen Fakt kann man nicht einfach überbügeln mit: "Ja dann nutze halt 
Rust".

Es muss dringend ein Umdenken passieren.
Neue Software muss möglichst in neuen sicheren Sprachen entwickelt 
werden.
Und bestehende Software muss Altlasten abwerfen.

von Vincent H. (vinci)


Lesenswert?

cppbert schrieb:
> ja das Herb Sutter Beispiel ist ja nur ein Aufrüttler - was wäre wenn
> C++ sowas wie die Rust Editions hätte - was wäre möglich - Herb muss ja
> immer der am-weitesten-über-den-Tellerrand-schauer sein

Das wurde als 'Epochs' bereits von Vittorio Romero vorgeschlagen und 
soweit ich mich erinnern kann mit großer Mehrheit vom Komitee abgelehnt.

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


Lesenswert?

MaWin schrieb:
> Eines der größten Probleme mit C++ ist, dass es nicht mit Altlasten
> aufräumen kann.

Eben deshalb halte ich das für keine sonderlich zielführende Idee, da 
noch weiter dran herum zu ändern. C++ hat sowieso schon eine Unmenge an 
Veränderungen in den letzten Jahrzehnten erfahren, dass da kaum einer 
noch durchblickt.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Eben deshalb halte ich das für keine sonderlich zielführende Idee, da
> noch weiter dran herum zu ändern. C++ hat sowieso schon eine Unmenge an
> Veränderungen in den letzten Jahrzehnten erfahren, dass da kaum einer
> noch durchblickt.

Du scheinst das Video wirklich nicht geguckt oder verstanden zu haben.
Anders ist das kaum zu erklären.

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


Lesenswert?

Ich sehe einfach nicht, dass das die Welt retten würde.

von MaWin (Gast)


Lesenswert?

Zum Glück behauptet das ja auch niemand.
Aber würde es sie verschlechtern?

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


Lesenswert?

MaWin schrieb:
> Aber würde es sie verschlechtern?

Ist halt die Frage: wenn du Leuten noch weniger Anreiz gibst, 
stattdessen andere Sprachen in Erwägung zu ziehen, ist das dann schon 
eine Verschlechterung?

von MaWin (Gast)


Lesenswert?

Nein. Global ist das keine Verschlechterung, sondern eine Verbesserung.

Und auch lokal ist es eine Verbesserung, wenn man in der Realität lebt, 
wo man eben eine riesige Codebasis hat, die niemand auf eine 
inkompatible Sprache umziehen wird.
Das sind nun einmal Realitäten, mit denen wir leben müssen. Da ändert 
auch ein "Anreiz zur Migration" nichts dran.

Im Ponyland. Ja. Dort wäre Cpp2 eine Verschlechterung.
Ich lebe dort aber nicht.

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


Lesenswert?

MaWin schrieb:
> die niemand auf eine inkompatible Sprache umziehen wird

Es geht ja nicht um "umziehen" (vor allem nicht sofort), ich hatte 
Firefox als Beispiel genannt.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Es geht ja nicht um "umziehen" (vor allem nicht sofort)

Ja doch. Genau darum geht es.
Es geht darum bestehenden C++-Code mit Cpp2 zu übersetzen und Schritt 
für Schritt zu verbessern, bis man den Cpp2-only-Schalter umlegen kann. 
Die Rückwärtskompatibilität von Cpp2 ist Opt-In. Und dieses Opt-In würde 
man initial geben und Schrittweise zurückfahren.

Ganz ähnlich, wie man das bei der Migration von C zu C++ tun kann. (Wie 
z.B. gcc es getan haben). Der Erste Schritt ist: Keine Codeänderung. Nur 
neuer Compiler.
(Nur, dass es in C->C++-Fall keinen Opt-In-Schalter gibt).

Und das geht eben mit einer inkompatiblen Sprache wie Rust gar nicht.

Guck doch zur Abwechslung einmal das Video.

von Daniel A. (daniel-a)


Lesenswert?

MaWin schrieb:
> Ganz ähnlich, wie man das bei der Migration von C zu C++ tun kann. (Wie
> z.B. gcc es getan haben). Der Erste Schritt ist: Keine Codeänderung. Nur
> neuer Compiler.

C ist kein Subset von C++. C++ Leuten, die versuchen C zu schreiben, und 
die Sprache nicht kennen, mag es vielleicht so vor kommen. Aber echte C 
Programmierer kennen die Sprache und nutzen ihr Potential voll aus. 
Einfach einen C++ Compiler nehmen geht da erfahrungsgemäss nur selten. 
Zumindest bei meinem Code geht das eigentlich nie. Da habe ich sowohl 
Sachen, die in C++ gar nicht kompilieren würden, als auch solche, die in 
C wohldefiniert, und in C++ ub sind.

von Cyblord -. (cyblord)


Lesenswert?

Daniel A. schrieb:
> C ist kein Subset von C++

Dann lass mal hören welche Teile von C nicht in C++ enthalten sind.

von MaWin (Gast)


Lesenswert?

Daniel A. schrieb:
> C ist kein Subset von C++

In der Praxis halt schon.
Die Unterschiede sind klein genug, um eine Compilermigration in den 
allermeisten Projekten mit minimalen Codeänderungen durchzuführen.

Aber das ist hier off-topic. Das war nur ein Beispiel und ein Vergleich.

von Wilhelm M. (wimalopaan)


Lesenswert?

Cyblord -. schrieb:
> Daniel A. schrieb:
>> C ist kein Subset von C++
>
> Dann lass mal hören welche Teile von C nicht in C++ enthalten sind.

https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B

von Daniel A. (daniel-a)


Lesenswert?

Cyblord -. schrieb:
> Daniel A. schrieb:
>> C ist kein Subset von C++
>
> Dann lass mal hören welche Teile von C nicht in C++ enthalten sind.

Da gibt es ganz elementare Sachen.

z.B., wenn ich in C "struct bla" schreibe, dann ist nur "struct bla" 
definiert, aber bla nicht. Ich könnte dann sogar zeugs machen, wie 
"typedef int bla;", oder eine variable bla oder Funktion bla nennen, 
usw.

Ein anderes Beispiel sind compound literale. Und bevor du jetzt sagst, 
"C++ hat die jetzt auch", die haben dort zusätzliche Einschränkungen. In 
C spielt es keine rolle, in welcher Reihenfolge ich die Dinger 
initialisiere. In C++ schon.

Ein Klassiger sind auch die Cast regeln. "dingsbums* x = 
(dingsbums*)malloc(sizeof(*x));" ist in C ein absolutes noob no-go. Den 
cast lässt man gefälligst weg.

Ein Beispiel für etwas, das nicht nur anders funktioniert, sondern es 
nur in C gibt: _Generic.

Dann noch ein Beispiel, das in C gut funktioniert, aber in C++ ub ist:
1
#include <stdio.h>
2
#include <string.h>
3
static inline char* hello(char bla[13]){
4
  strcpy(bla, "Hello World!");
5
  return bla;
6
}
7
int main(){
8
  const char* msg = hello((char[16]){0});
9
  puts(msg); // In C ok, da das compound literal im block scope ist. In C++ ub, weil die Lifetime nach dem Funktionsaufruf zuende ist.
10
}

Ich hätte noch mehr Beispiele, aber das dürfte fürs erste mal reichen.

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


Lesenswert?

MaWin schrieb:
> Es geht darum bestehenden C++-Code mit Cpp2 zu übersetzen und Schritt
> für Schritt zu verbessern, bis man den Cpp2-only-Schalter umlegen kann.

Ich habe nur meine Zweifel, dass just diese Organisationen mit riesigen 
C++-Codebasen die nötigen Ressourcen dafür aufzuwenden bereit sind. Denn 
es kostet Ressourcen, das alles durchzugehen. Das sehen wir doch schon 
an so einfachen Beispielen wie Compilerwarnungen über Mischen von signed 
und unsigned. Welches größere Projekt macht sich nachträglich die Mühe 
(die ja insbesondere auch irgendeine Finanzierung benötigt), sowas zu 
reparieren?

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Ich habe nur meine Zweifel, dass just diese Organisationen mit riesigen
> C++-Codebasen die nötigen Ressourcen dafür aufzuwenden bereit sind. Denn
> es kostet Ressourcen, das alles durchzugehen. Das sehen wir doch schon
> an so einfachen Beispielen wie Compilerwarnungen über Mischen von signed
> und unsigned.

Völlig richtig.
Und dann schlussfolgerst du, dass man stattdessen besser alles in Rust 
neuentwickeln soll?
Das verstehe, wer will.

von Marco (Gast)


Lesenswert?

DPA schrieb:
> Rust - ist das hier um zu bleiben?

Da Rust nun sehr alt ist, denke ich kann es weg!

von Rolf M. (rmagnus)


Lesenswert?

Daniel A. schrieb:
> Ich hätte noch mehr Beispiele, aber das dürfte fürs erste mal reichen.

Das ist denk ich der Punkt: Es ist nicht das eine große Feature, das in 
C++ fehlt, sondern viele Feinheiten, die es inkompatibel machen. Man 
muss auch bedenken, dass C++ ursprünglich mal C89 als Basis hatte. 
Inzwischen hat sich auch C weiterentwickelt. Vieles davon wurde in C++ 
auch nachgezogen, aber nicht alles, und auch nicht alles exakt gleich.

von MaWin (Gast)


Lesenswert?

Rolf M. schrieb:
> Das ist denk ich der Punkt

Nein. Der Punkt war, dass das nur ein Beispiel war. Ein Vergleich.
Große Projekte haben diese Migration geschafft.
Auch wenn die µC.net-Experten dies aufgrund der großen Unterschiede als 
praktisch unmöglich ansehen.

Aber das ist nicht schlimm. Denn derzeit sind die Unterschiede zwischen 
Cpp2 und C++ noch genau 0, bei Compat-Opt-In.
Die Situation bei C++->Cpp2 ist also noch besser, als bei C->C++.

Und, nicht vergessen:
Cpp2 ist ein Vorschlag. Eine Idee. Ein Verbesserungsvorschlag zur 
Inkrementellen Verbesserung des C++-Ökosystems.
Es ist nicht: Ein fertiger Compiler. Ein Standard. Ein Zwang. Ein Keks.

Ich finde es ist unbedingt notwendig C++-Altlasten über Bord zu werfen 
und trotzdem rückwärtskompatibel zu bleiben. Und das ist, was Cpp2 
versucht vorzuschlagen und auch praktisch zu demonstrieren.
Und das finde ich gut.
Das ist ein wichtiger Schritt in die Richtung sicherer Sprachen, wie 
z.B. Rust.

von rbx (Gast)


Lesenswert?

Ein wenig Rust-Soziologie:

https://books.goalkicker.com

Rust: A Language for the Next 40 Years - Carol Nichols
https://www.youtube.com/watch?v=A3AdN7U24iU

https://www.reddit.com/r/rust/comments/jb3ukm/we_need_to_talk_a
bout_stackoverflow/

Richard Feldman — The Next Paradigm Shift in Programming
https://www.youtube.com/watch?v=6YbK8o9rZfI
(besonders spannend: die OO-Anfänge und Ideen. Viele Computer? großes 
Multirechnernetzwerk?)
(Haskell Cabal/Stack, Rust Online - statt komplettes Offline-Packet zum 
Lesen und Arbeiten (auch für DOS) wie bei OpenWatcom.)

https://de.wikipedia.org/wiki/Kognitive_Dissonanz#:~:text=Kognitive%20Dissonanz%20bezeichnet%20in%20der,Einstellungen%2C%20Wünsche%20oder%20Absichten).

Da FP sehr abstrakt ist, braucht es eine ganze Weile bis es rutscht.
Lerntechnisch ist es vielleicht hilfreicher für viele, C++ FP, oder 
JavaScriptFP oder Scala o.ä. zu nutzen.

von Rolf M. (rmagnus)


Lesenswert?

MaWin schrieb:
> Rolf M. schrieb:
>> Das ist denk ich der Punkt
>
> Nein. Der Punkt war, dass das nur ein Beispiel war. Ein Vergleich.
> Große Projekte haben diese Migration geschafft.

Natürlich ist die Migration machbar. Alleine schon die Wortwahl 
"Migration geschafft" zeigt aber doch, dass es doch etwas mehr ist als 
das Ersetzen von "gcc" durch "g++" im Makefile. Je nach Projekt kann der 
Aufwand zwischen relativ gering und sehr hoch variieren. Gemacht habe 
ich das auch schon, und dabei habe ich eben gemerkt, dass da der Teufel 
oft im Detail steckt.

> Auch wenn die µC.net-Experten dies aufgrund der großen Unterschiede als
> praktisch unmöglich ansehen.

Das habe ich hier nirgends gelesen.

von MaWin (Gast)


Lesenswert?

Rolf M. schrieb:
> Alleine schon die Wortwahl

Ja, Rolf. Du hast Recht. In allen Punkten.
Ich stimme dir voll und ganz zu. Was du sagst, ist die 100%ige Wahrheit.
Das war lediglich ein Vergleich. Und du hast die Probleme bei diesem 
Vergleich sehr schön dargelegt.

Ist es jetzt gut?

von Nano (Gast)


Lesenswert?

Mal eine etwas andere Frage.

C Compiler gibt es für 8086 Prozessoren zur genüge, die dann im 16 Bit 
Real Mode laufen und mit <= 640 KiB RAM auskommen.

Wäre das auch mit Rust möglich, wenn man dafür einen Compiler entwickeln 
würde, oder ist dafür die Sprache schon zu komplex?


Ja, man könnte den Code auch auf einer dicken Maschine compilieren, aber 
das ist hier nicht die Frage. Die Frage ist, ob ein Rust Compiler 
machbar wäre, der auf einem altem 8086 PC mit 640 KiB RAM läuft und zwar 
so, dass man nicht ständig auf der Festplatte Daten auslagern muss.

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


Lesenswert?

Nano schrieb:
> Die Frage ist,

… was willst du damit?

Fragt doch auch keiner nach einem C++-Compiler für CP/M. (Selbst 
C-Compiler für CP/M waren eher der Graus.)

Nicht einmal GCC läuft auf diesem ollen Krempel. DJ-GCC lief nur im 
32-Bit-Modus eines 80386.

: Bearbeitet durch Moderator
von Nano (Gast)


Lesenswert?

Jörg W. schrieb:
> Nano schrieb:
>> Die Frage ist,
>
> … was willst du damit?

Ich will einfach nur wissen ob es bei der Komplexität von Rust ginge.
Rust ist immerhin eine sehr moderne Sprache mit so Sachen wie Modulen.
Während man sich bei C und C++ noch um Headerdateien anstatt Modulen 
abmühte. Einer der Gründe warum waren die Systemanforderungen für den 
Compiler.

> Fragt doch auch keiner nach einem C++-Compiler für CP/M. (Selbst
> C-Compiler für CP/M waren eher der Graus.)

Typische CP/M Systeme hatten üblicherweise noch weniger RAM zur 
Verfügung.

> Nicht einmal GCC läuft auf diesem ollen Krempel. DJ-GCC lief nur im
> 32-Bit-Modus eines 80386.

GCC nicht, aber dafür frühe Microsoft C und QuickC Versionen. Sowie 
sicherlich auch Turbo C und noch ein paar andere. Frühe Watcom C 
Versionen eventuell auch noch.

von MaWin (Gast)


Lesenswert?

Nano schrieb:
> Die Frage ist, ob ein Rust Compiler
> machbar wäre, der auf einem altem 8086 PC mit 640 KiB RAM läuft und zwar
> so, dass man nicht ständig auf der Festplatte Daten auslagern muss.

Ziemlich sicher nicht.
Heutige Sprachen sind überhaupt nur möglich, weil genug Rechenleistung 
und Speicher für die Compiler zur Verfügung stehen.

Auch modernes C kann man mit einem modernen optimierenden Compiler nicht 
auf einer 8086 mit 640k RAM compilieren.

von cppbert (Gast)


Lesenswert?

Nano schrieb:
> Ich will einfach nur wissen ob es bei der Komplexität von Rust ginge.
> Rust ist immerhin eine sehr moderne Sprache mit so Sachen wie Modulen.
> Während man sich bei C und C++ noch um Headerdateien anstatt Modulen
> abmühte. Einer der Gründe warum waren die Systemanforderungen für den
> Compiler.

nein sicher nicht - die Analyse braucht einfach zu viel Speicher - aber 
selbst C hat im Vergleich zu damaligen Assemblern schon viel mehr 
Resourcen gebraucht
in den Anfängen von C mussten viele auch sicherliche ständig zwischen 
Disketten und Programmen wechseln um überhaupt was kompiliert zu 
bekommen

aber als Cross-Compiler könnte es gehen - wenn jemand sich darauf 
konzentriert einen Optimizer dafür zu schreiben der dann auch ordentlich 
auf Realmode Segment/Offset Kram optimiert ist

der aktuelle GCC IA 16 (https://github.com/tkchia/gcc-ia16) kann ja auch 
ordentlichen 8086 Code erzeugen und optimiert definitv besser als die 
Kompiler aus der Zeit und läuft sogar auf DOS - aber auch nur mit 
Extender und leider kein C++ :(

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


Lesenswert?

cppbert schrieb:
> aber selbst C hat im Vergleich zu damaligen Assemblern schon viel mehr
> Resourcen gebraucht

Üblich war eine Diskette mit den Tools, eine zweite mit den Dateien 
(Quellcode, Zwischendateien). Dauerte natürlich in der Tat ewig.

Turbo-Pascal wurde seinem Namen dagegen gerecht, im Vergleich zu allen 
anderen Compilern der Zeit war es rasend schnell und brachte noch dazu 
die wohl erste IDE mit, die es gab. Im Vergleich zu heute dürfte die 
Optimierung nicht sonderlich großartig gewesen sein, aber für viele 
Fälle reichte es. Ich habe einen kompletten EPROMMer damit recht 
komfortabel bedient, nur die innere Schleife wurde dann durch 
handoptimierten Inline-Assembler ersetzt.

von Nano (Gast)


Lesenswert?

cppbert schrieb:
> Nano schrieb:
>> Ich will einfach nur wissen ob es bei der Komplexität von Rust ginge.
>> Rust ist immerhin eine sehr moderne Sprache mit so Sachen wie Modulen.
>> Während man sich bei C und C++ noch um Headerdateien anstatt Modulen
>> abmühte. Einer der Gründe warum waren die Systemanforderungen für den
>> Compiler.
>
> nein sicher nicht - die Analyse braucht einfach zu viel Speicher -

Danke für die Antwort.

> aber
> selbst C hat im Vergleich zu damaligen Assemblern schon viel mehr
> Resourcen gebraucht
> in den Anfängen von C mussten viele auch sicherliche ständig zwischen
> Disketten und Programmen wechseln um überhaupt was kompiliert zu
> bekommen

Ja, das lag Anfangs aber an den Datenträgern. Mit Festplatten fiel das 
Diskette wechseln dann weg.
Bliebe dann nur noch das Auslagern von Daten auf Festplatte während dem 
Compilevorgang von größeren Projekten.

von Alexander S. (alesi)


Lesenswert?

MaWin schrieb:
> Ziemlich sicher nicht.
> Heutige Sprachen sind überhaupt nur möglich, weil genug Rechenleistung
> und Speicher für die Compiler zur Verfügung stehen.
>
> Auch modernes C kann man mit einem modernen optimierenden Compiler nicht
> auf einer 8086 mit 640k RAM compilieren.

Forth (2012) könnte vielleicht auf 8086 mit 640k RAM  gehen. Auf die 
Schnelle habe ich dazu aber keine Infos gefunden, nur das gforth auf 386 
läuft. https://gforth.org/  Supported systems i386 und Gforth 
EC(embedded) auch auf 8086.

P.S. Das ist zwar off-topic. Aber das waren einige andere Beiträge 
vorher auch. :-)

von Rolf M. (rmagnus)


Lesenswert?

Frühe Compiler bestanden aus mehreren Einzelprogrammen, von denen jedes 
einen Teilschritt des Compiliervorgangs durchführte, weil man alles 
zusammen nicht gleichzeitig in den Speicher bekam. Das hat's natürlich 
auch nicht gerade schnell gemacht, weil die Zwischenergebnisse natürlich 
immer erst abgespeichert und dann wieder geladen werden mussten. So sind 
moderne Compiler aber nicht mehr aufgebaut, daher funktionieren die auf 
Systemen mit so begrenzten Ressourcen nicht.

: Bearbeitet durch User
von 🐧 DPA 🐧 (Gast)


Lesenswert?

Rolf M. schrieb:
> So sind moderne Compiler aber nicht mehr aufgebaut, daher funktionieren die auf
> Systemen mit so begrenzten Ressourcen nicht.

Jein. Auch bei den 2 rust compilern gibt es theoretisch noch object 
files. Aber ohne separate include Files mit dem Interface zeugs drinn 
muss der Compiler trotzdem die ganzen abhängigen quellen ansehen, und da 
kann schnell mal alles zusammen hängen. Kommt aber aufs selbe raus, 
finde ich nicht gut. Da können selbst moderate Systeme ganz schön ins 
schwitzen kommen.

Der GCC kann übrigens auch noch pipes zwischen Compiler und Linker 
verwenden. So könnte man also theoretisch kompilieren und linken, ohne 
alles ins Dateisystem zu legen, und ohne alles auf einmal im RAM zu 
haben. Wobei, vermutlich bringt das heute auch nicht mehr viel, falls es 
überhaupt noch funktioniert...

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


Lesenswert?

🐧 DPA 🐧 schrieb:
> Der GCC kann übrigens auch noch pipes zwischen Compiler und Linker
> verwenden.

Linker nicht, aber zwischen Compiler und Assembler.
Präprozessor früher noch, aber das ist kein separater Prozess mehr.

von Wilhelm M. (wimalopaan)


Lesenswert?

🐧 DPA 🐧 schrieb:
> So könnte man also theoretisch kompilieren und linken, ohne
> alles ins Dateisystem zu legen, und ohne alles auf einmal im RAM zu
> haben.

Das ist beim gcc normal, siehe -save-temps Option.

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


Lesenswert?

Wilhelm M. schrieb:
> Das ist beim gcc normal, siehe -save-temps Option.

-save-temps behält sie nur bei, erzeugt werden sie auch sonst.

Aber das dürfte bei heutigen Betriebssystemen und Speichergrößen oft 
keine Rolle mehr spielen, weil die Zwischendateien im Cache bleiben. 
Windows ist allerdings mit vielen Dateioperationen spürbar langsam, und 
wenn man dann noch einen Virenchecker hat, der sich auch noch alle 
Zwischendateien ansehen möchte, dann hat man die Po-Karte gezogen.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Jörg W. schrieb:
> dann hat man die Po-Karte gezogen.

Wenn du ein Po-Kartenspiel hast, und du ziehst eine Karte...Was 
erwartest du dann? ;-)

scnr,
WK

von Wilhelm M. (wimalopaan)


Lesenswert?

Jörg W. schrieb:
> Aber das dürfte bei heutigen Betriebssystemen und Speichergrößen oft
> keine Rolle mehr spielen, weil die Zwischendateien im Cache bleiben.

Bei *nix werden temporäre Dateien unter /tmp erzeugt, was typischerweise 
ein tmpfs o.ä. ist, für das keine Persistenz verlangt wird.

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


Lesenswert?

Wilhelm M. schrieb:
> Bei *nix werden temporäre Dateien unter /tmp erzeugt, was typischerweise
> ein tmpfs o.ä. ist

So typisch ist das nicht. Auf den Systemen, wo ich arbeite, ist es ein 
ganz normales Dateisystem (bzw. Bestandteil von /). Trotzdem geht es 
schnell, weil der Krempel noch komplett im RAM verfügbar ist, wenn die 
nächste Phase ihn wieder lesen will. Daher bringt -pipe nicht mehr so 
viel, wie das noch vor 20 Jahren der Fall war.

von Wilhelm M. (wimalopaan)


Lesenswert?

Jörg W. schrieb:
> So typisch ist das nicht.

Dann sind Deine Systeme atypisch oder antiquarisch oder beides ;-)

von cppbert (Gast)


Lesenswert?

zurück zum Thema, Burschen!

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


Lesenswert?

Du meinst, zur Frage, ob der Rust-Compiler auch temp files anlegt und ob 
man schneller wird, wenn man sie durch eine Pipe ersetzt? ;-)

Gibt's eigentlich Geschwindigkeitsvergleiche zwischen *nix und Windows 
für den Rust-Compiler?

von rbx (Gast)


Lesenswert?

Jörg W. schrieb:
> Gibt's eigentlich Geschwindigkeitsvergleiche zwischen *nix und Windows
> für den Rust-Compiler?

Hinsichtlich der Installation mit Sicherheit ;)

von Nano (Gast)


Lesenswert?

Rolf M. schrieb:
> Frühe Compiler bestanden aus mehreren Einzelprogrammen, von denen
> jedes
> einen Teilschritt des Compiliervorgangs durchführte, weil man alles
> zusammen nicht gleichzeitig in den Speicher bekam. Das hat's natürlich
> auch nicht gerade schnell gemacht, weil die Zwischenergebnisse natürlich
> immer erst abgespeichert und dann wieder geladen werden mussten.

Das ist richtig.

Präprozessor
Compiler
Assembler
Linker
und gegebenenfalls noch
EXE2BIN (war Bestandteil von MS-DOS, wurde manchem MS Compiler aber auch 
mitgeliefert)


> So sind
> moderne Compiler aber nicht mehr aufgebaut, daher funktionieren die auf
> Systemen mit so begrenzten Ressourcen nicht.

Das ist korrekt.
Bei LLVM wird sogar Bytecode für eine eigene CPU Maschine erzeugt und 
aus dem Bytecode wird dann erst der eigentliche Maschinencode für die 
Ziel CPU erstellt.

Der Vorteil:
Alle Sprachen generieren den Bytecode und aus diesem einen unified 
Bytecode kann man dann den eigentlichen Maschinencode für die Ziel CPU 
erstellen.
Damit muss man die Arbeit für eine bestimmte Ziel CPU nur einmal machen 
und man kann alle Sprachen für diese nutzen. Umgekehrt gilt das gleiche.

von Alexander S. (alesi)


Lesenswert?

cppbert schrieb:
> zurück zum Thema, Burschen!

Ok, zweiter Versuch:
Was kann Rust besser als Forth? https://gforth.org/
:-)

von MaWin (Gast)


Lesenswert?

Nano schrieb:
> Bei LLVM wird sogar Bytecode für eine eigene CPU Maschine erzeugt

Um noch einmal zum Thema des Threads zurück zu kommen:

Bei Rust gibt es nicht nur einen solchen Zwischenschritt (IR), sondern 
mehrere:

https://blog.rust-lang.org/2016/04/19/MIR.html

von Rolf M. (rmagnus)


Lesenswert?

Nano schrieb:
> Präprozessor
> Compiler
> Assembler
> Linker
> und gegebenenfalls noch
> EXE2BIN (war Bestandteil von MS-DOS, wurde manchem MS Compiler aber auch
> mitgeliefert)

Ich beziehe mich nur auf den Teil "Compiler". Dieser wurde in mehrere 
als getrennte Programme ausgeführte Einzelschritte zerlegt, wie z.B. 
lexikalische Analyse, Syntaxanalyse, Codegenerierung.

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


Lesenswert?

MaWin schrieb:
> Bei Rust gibt es nicht nur einen solchen Zwischenschritt (IR), sondern
> mehrere:

Wobei das jetzt eher ein Implementierungsdetail denn ein Sprachfeature 
sein dürfte, oder? Trifft man außerdem auch bei anderen Sprachen an. 
Lass mal den GCC mit -fdump-rtl-all laufen und erfreu dich dann an 
mehreren Dutzend Dateien, die die einzelnen Zwischenstufen 
repräsentieren. ;-)

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Wobei das jetzt eher ein Implementierungsdetail denn ein Sprachfeature
> sein dürfte, oder?

Bitte einfach einmal den verlinkten Artikel lesen.

> Trifft man außerdem auch bei anderen Sprachen an.

Ach. Wer hätte es gedacht.
Habe ich ja auch nie in Frage gestellt.

MaWin schrieb:
> Um noch einmal zum Thema des Threads zurück zu kommen:

Also doch wieder off-topic.
"anderen Sprachen"...

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


Lesenswert?

MaWin schrieb:
> Bitte einfach einmal den verlinkten Artikel lesen.

Ändert nichts dran, dass da Implementierungsdetails beschrieben werden.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Ändert nichts dran, dass da Implementierungsdetails beschrieben werden.

Genau so sieht es aus.
Das Lesen hätte des Artikels hätte die Frage beantwortet, bevor du sie 
hier gestellt hast.

von rbx (Gast)


Lesenswert?

MaWin schrieb:
> Also doch wieder off-topic.
> "anderen Sprachen"...

Was willst du denn immer mit deinem "offtopic"?

Wir sind hier nicht irgendwie Sprachdesigner von Rust, sondern es geht 
darum, welche Zukunft die Programmiersprache und seine 
Bereitstellung/Logistik/Schulung usw. hat.

Beispielsweise, warum kann man Rust nicht einfach wie D auf Windows 
installieren? D braucht nur einen kleinen Ordner, und man kann sofort 
damit arbeiten, ganz easy.
Nicht wirklich schwieriger als eine Tiny C Installation.

Den oben verlinkten Artikel solltest du mal ausdrucken. Wenn man das 
macht, hat man schon einen halben Arztroman zusammen.

Die FP Programmierung muss man (lange) pauken, wenn man nicht irgendwie 
mit Lisp (+ Emacs) groß geworden ist.

Für Haskell braucht man eigentlich nur Notepad oder Papier und 
Bleistift. Aber so richtig gut unter Windows funzt der GHC bzw. die 
Haskell Plattform auch nicht, ziemliches Gewürge bei der Installation, 
und dann auch noch pingelig hinsichtlich der Windows-Version.  - so dass 
man Haskell dann noch lieber auf Linux nutzen möchte.
Bei Rust ganz ähnlich.
Darüber sollten sich diese Rustentwickler mal ein paar Gedanken machen.
D oder Tiny C sind diesbezüglich einfach viel besser, trotz der 
eingeschränkten Ressourcen.

Und: Java? Java ist das abschreckende Beispiel bestimmter Entwicklungen. 
Python ja irgendwie auch - aber da gibt es wohl Wege, damit besser 
klarzukommen.

Und Idris? Was soll ich mit Idris, ich möchte mit Haskell arbeiten. Ach 
sch..

von MaWin (Gast)


Lesenswert?

rbx schrieb:
> Was willst du denn immer mit deinem "offtopic"?

Weil es hier um Rust geht. Nicht um Haskell oder sonstige Sprachen.

Damit ist 90% deines Beitrags wieder einmal off-topic.

> Beispielsweise, warum kann man Rust nicht einfach wie D auf Windows
> installieren?

Du musst ein Exe herunterladen und doppelt draufklicken.
Viel einfacher kann es nicht werden.

von DPA (Gast)


Lesenswert?

Man nennt das über den eigenen Tellerrand schauen. Aber das kann man 
nach Rust ja nicht mehr...

von rbx (Gast)


Lesenswert?

MaWin schrieb:
> Du musst ein Exe herunterladen und doppelt draufklicken.
> Viel einfacher kann es nicht werden.

(nightly Build): Falsche Windowsversion..

von MaWin (Gast)


Lesenswert?

rbx schrieb:
> (nightly Build): Falsche Windowsversion..

Was heißt das auf Deutsch?

von rbx (Gast)


Lesenswert?

MaWin schrieb:
> Was heißt das auf Deutsch?

Das heißt, dass Tiny C oder D viel einfacher zu installieren sind. 
Einfach downloaden, eventuell noch auspacken, fertisch.

Bei Rust: Warten, ...warten...warten...und wenn dann (so nach 30 Min) 
der Ordner fertig ist, z.B. könnte man diese Buch.exe anklicken und 
dann..

"Dieses Programm kann kann nicht auf Windows ausgeführt werden" - oder 
so ähnlich - typischerweise heißt das: Inkompatibles Windows. (-> 
lächerlich)

(Und groß VS Studio vorher zu installieren, das dauert auch ziemlich 
lange und verbraucht ziemlich viel Speicherplatz. Warum nicht was mit 
mingw?)

Wiederum lächerlich zu Tiny C, D, oder von mir aus auch Hugs. ( 
https://www.heise.de/download/product/hugs-98-40452 )
Hugs verarbeitet übrigens auch (im Gegensatz zum GHC) 
Literate-Programming. Schöne Sache.

( 
https://steamcommunity.com/app/252490/discussions/0/1745646819954096664/ 
)

von MaWin (Gast)


Lesenswert?

Troll bitte woanders.
Das ist ganz offensichtlich ausgedachter Quatsch.
Und das kann jeder nachprüfen, indem er selbst Rust installiert.
Also was soll das?

von rbx (Gast)


Lesenswert?

MaWin schrieb:
> Und das kann jeder nachprüfen, indem er selbst Rust installiert.
> Also was soll das?

Auch jemand, der Windows 8.1. hat, oder XP oder Me? Das würde mich echt 
mal interessieren.

Wenn hier einer trollt, dann kommt das von einem, der hier Rust 
lobpreist, obwohl noch vieles im Argen ist.
Scheint ja für diesen Typen einfacher zu sein, mehr auf die 
Persönlichkeitseigenschaften zu schließen, wenn dem was nicht passt, als 
tatsächlich mal die Sachlage zu überblicken.

Als ich das erste mal mit Modula 3 Bekannschaft machte, da hieß es, das 
wäre eine TOP-Programmiersprache. Ist die eigentlich auch. Aber die 
Logistik, die Linux-Pflicht, die Unibeschränktheit, die Bibs..

von Oliver R. (Gast)


Lesenswert?

rbx schrieb:
> Auch jemand, der Windows 8.1. hat, oder XP oder Me? Das würde mich echt
> mal interessieren.

Rust unter Windows 7 habe ich selbst getestet, funktioniert. Und ja, die 
Installation ist nervig wegen dieser GB grossen Abhängigkeiten. Ich 
fürchte, das hat aber auch mit lizenzrechtlichen Dingen zu tun und es 
daher getrennt von MS geladen werden muss.

von rbx (Gast)


Lesenswert?

Oliver R. schrieb:
> Rust unter Windows 7 habe ich selbst getestet, funktioniert.

Danke für den Hinweis.
32 oder 64 Bit?

Ich habe 64 Bit Windows 8.1. Da lief dann aber nach der Installation 
nichts, also ist der ganze Ordner wieder in den Papierkorb gewandert, 
und der auch gleich geleert worden.
Eventuell war der Nightly Build ein Fehler, möglicherweise funzt stable 
besser, mal sehen.

von Nachdenklicher (Gast)


Lesenswert?

Ich habe, angelockt durch diesen Thread her, jetzt einfach mal einen 
Test gemacht.
Ein einfaches Hello World in Rust unter Linux aus dem Tutorial kopiert 
und kompiliert. Das Executable hat knapp 4 Megabyte. Also jetzt mal im 
Ernst, das ist doch ein schlechter Witz, oder?  4 MB für ein Programm, 
das "Hello, World!" auf der Konsole ausgibt? 🤯

von Oliver R. (Gast)


Lesenswert?

rbx schrieb:
> Danke für den Hinweis.
> 32 oder 64 Bit?

War 64 Bit. Ist allerdings schon eine Weile her und der betreffende 
Rechner steht auch nicht bei mir. Ich würde auch bei stable bleiben 
solange nightly nicht explizit für bestimmten Code benötigt wird. 
Ansonsten verlierst du einen der Hauptvorteile von Rust, nämlich die 
Garantie, dass dein Code in allen zukünftigen (stable) Versionen 
kompilieren wird.

von Oliver R. (Gast)


Lesenswert?

Nachdenklicher schrieb:
> 4 MB für ein Programm,
> das "Hello, World!" auf der Konsole ausgibt?

Bist du sicher, dass du im Release Mode kompiliert hast und auch keine 
Debug Symbole drin sind?

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


Lesenswert?

Nachdenklicher schrieb:
> Das Executable hat knapp 4 Megabyte.

Schau dir die Ausgabe von "size <filename>" an, nicht die Größe im 
Dateisystem.

von Oliver R. (Gast)


Lesenswert?

Gerade getestet, das Hello World im Release Mode ohne Debug Symbole 
belegt unter Linux 289080 Bytes im Dateisystem. Man kann argumentieren, 
dass das immer noch viel ist und es gibt wohl Möglichkeiten da noch 
Platz einzusparen.

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


Lesenswert?

1
$ cat helloworld.rs 
2
fn main() {
3
    // Statements here are executed when the compiled binary is called
4
5
    // Print text to the console
6
    println!("Hello World!");
7
}
8
$ rustc -O helloworld.rs
9
$ ./helloworld
10
Hello World!
11
$ size helloworld
12
    text    data   bss      dec       hex   filename
13
  307914   12864   273   321051   0x4e61b   helloworld
OK, Gegentest:
1
$ cat helloworld.c
2
#include <stdio.h>
3
4
int main(void) {
5
   printf("Hello, world!\n");
6
   return 0;
7
}
8
$ cc -O -o helloworld helloworld.c
9
$ ./helloworld 
10
Hello, world!
11
$ size helloworld
12
  text   data   bss    dec     hex   filename
13
  1839    409     8   2256   0x8d0   helloworld
Gut, etwas kleiner. :-)
1
$ cat helloworld.cc
2
#include <iostream>
3
4
int main(void) {
5
  std::cout << "Hello, world" << std::endl;
6
  return 0;
7
}
8
$ c++ -O -o helloworld helloworld.cc
9
$ ./helloworld 
10
Hello, world
11
$ size helloworld
12
  text   data   bss    dec      hex   filename
13
  4997    649   192   5838   0x16ce   helloworld
Aber so ist das mit Trivialbeispielen, sie sind völlig unrepräsentativ 
für die reale Welt.

von Oliver R. (Gast)


Lesenswert?

Wer etwas tiefer einsteigen will:

https://github.com/johnthagen/min-sized-rust

von Nachdenklicher (Gast)


Lesenswert?

Jörg W. schrieb:
> $ size helloworld
>     text    data   bss      dec       hex   filename
>   307914   12864   273   321051   0x4e61b   helloworld

Okay, das sieht bei mir auch so in der Art aus, mit Abweichungen um 
wenige Bytes. Aber:
1
$ ls -lah
2
total 3,9M
3
drwxrwxr-x 2 user user 4,0K Dez 12 12:23 .
4
drwxrwxr-x 5 user user 4,0K Dez 12 12:22 ..
5
-rwxrwxr-x 1 user user 3,9M Dez 12 12:30 helloworld
6
-rw-rw-r-- 1 user user   45 Dez 12 12:28 helloworld.rs

Ich konnte es nicht aus der VM raus kopieren, eventuelle Tippfehler 
kommen vom Abschreiben. Woran liegt das dann, frage ich mich? Am 
Dateisystem ja wohl eher nicht, wenn der Sourcecode korrekt mit 45 Bytes 
angezeigt wird.

Kompiliert ist es mit "rustc helloworld.rs". Ob das was mit Debug oder 
ohne ist, weiß ich nicht...

von Cyblord -. (cyblord)


Lesenswert?

307914 vs 1839.

Damit hat sich die Frage nach Rust für Embedded sowieso bereits 
erledigt. Wie schon vermutet, alles ein Phänomen im PC Bereich. Wo bei 
Speicher und Co. alles egal ist.
Wie soll man mit so einem Footprint C für den Microcontrollerbereich mit 
wenigen MB oder gar kB Flash ablösen? Utopie trifft Wahnvorstellung.

von MaWin (Gast)


Lesenswert?

Ja. Die Größe der Rust-Binaries ist auf dem PC etwas größer als bei C.
Das ist ein bekanntes Problem und daran wurde auch schon gearbeitet.

Es wird jedoch offenbar nicht mit höchster Priorität verfolgt, da das ja 
nicht wirklich ein Problem ist. Ob ein Binary einer großen Applikation 
jetzt ein paar hundert kB größer ist oder nicht, spielt selten eine 
Rolle.

Ich denke echt, dass es da wichtigere Probleme zu lösen gibt.

> Und ja, die
> Installation ist nervig wegen dieser GB grossen Abhängigkeiten.

Ja. Das ist aber nur bei Windows so und der Grund ist Microsoft.
Da ist Rust selbstverständlich auch nicht alleine. So gut wie jede etwas 
größere Applikation braucht diese RT unter Windows.

Da kann Rust nun beim besten Willen nichts für und kann da auch nichts 
dran ändern.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Damit hat sich die Frage nach Rust für Embedded sowieso bereits
> erledigt.

Nö. Das ist ein reines PC-"Problem".

> Utopie trifft Wahnvorstellung

Vielleicht eher: Unwissenheit trifft Cyblord.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Nö. Das ist ein reines PC-"Problem".

Ach so. Gibts denn so ein Beispiel dann auch mal für zwei lauffähige 
Binaries für sagen wie mal nen STM32F103?

> Da kann Rust nun beim besten Willen nichts für und kann da auch nichts
> dran ändern.

Wenn man nicht schwimmen kann, ist meistens nicht die Badehose schuld.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Nachdenklicher schrieb:
> Woran liegt das dann, frage ich mich?

An allen möglichen weiteren sections im ELF-File, also Symboltabellen 
und Debug-Infos.

Aber das ist doch für die praktische Anwendung komplett irrelevant: 
geladen wird das, was "size" dir anzeigt. Alles andere braucht Platz auf 
der Festplatte, mehr nicht.

Cyblord -. schrieb:
> 307914 vs 1839.

Lässt allerdings komplett außer acht, dass das natürlich hier alles 
dynamisch gelinkte Binaries sind, d.h. ein nicht zu vernachlässigender 
Anteil an Code liegt in den shared libs. Jedoch sind diese natürlich, so 
der Name, eben "shared", d.h. alle Anwendungen nutzen das gemeinsam. 
(Das wäre bei "deeply embedded", also MCUs, anders.)

von Cyblord -. (cyblord)


Lesenswert?

Jörg W. schrieb:
> Lässt allerdings komplett außer acht, dass das natürlich hier alles
> dynamisch gelinkte Binaries sind, d.h. ein nicht zu vernachlässigender
> Anteil an Code liegt in den shared libs. Jedoch sind diese natürlich, so
> der Name, eben "shared", d.h. alle Anwendungen nutzen das gemeinsam.
> (Das wäre bei "deeply embedded", also MCUs, anders.)

Und was macht das C Programm hier anders als Rust? Und warum? Das muss 
ja auch auf dem bösen Windows laufen.

: Bearbeitet durch User
von Oliver R. (Gast)


Lesenswert?

Der Hauptgrund für die Binary-Größe auf Desktop-System ist die 
dazugelinkte Standard-Library. Embedded ist aber typischerweise 
"no-std", d.h. diese Problematik entfällt hier und die Binaries sind 
deutlich kleiner.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Ach so. Gibts denn so ein Beispiel dann auch mal für zwei lauffähige
> Binaries für sagen wie mal nen STM32F103?

Bestimmt. Google wieder kaputt?

Ich habe schon Binaries für AVR8 kompiliert.
Ein Rust-Programm mit leerer main() ist genau so groß wie ein C-Programm 
mit leerer main(). Es enthält dann in beiden Fällen nur die 
avr-libc-Boot- und Basisroutinen.

von Cyblord -. (cyblord)


Lesenswert?

Oliver R. schrieb:
> Der Hauptgrund für die Binary-Größe auf Desktop-System ist die
> dazugelinkte Standard-Library.

Also ist die Standard Library für Rust nur bloat im Gegensatz zu der von 
C? Nochmal die Frage an dich: Warum hat ein C Programm unter Windows 
nicht die gleichen Probleme?

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


Lesenswert?

Oliver R. schrieb:
> Der Hauptgrund für die Binary-Größe auf Desktop-System ist die
> dazugelinkte Standard-Library.

Leuchtet allerdings dahingehend nicht ein, dass aus einer Library nur 
die Dinge gelinkt werden sollten, die auch tatsächlich benötigt werden.

Es werden wohl eher Dinge wie ein Laufzeitsystem sein, die das 
aufblähen. Da ist dann die Frage, wieviel dieses Overheads eher statisch 
sind (also auch bei großen Programmen annähernd gleich groß bleiben), 
oder ob da was "mitwächst".

Dass ein Helloworld kein sinnvoller Benchmark für die Größe eines 
erzeugten Binaries ist, sollte jedem klar sein.

von Cyblord -. (cyblord)


Lesenswert?

Jörg W. schrieb:
> Dass ein Helloworld kein sinnvoller Benchmark für die Größe eines
> erzeugten Binaries ist, sollte jedem klar sein.

Warum das? Es gibt immerhin mal eine untere Grenze für die Binary Größe 
an.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Also ist die Standard Library für Rust nur bloat im Gegensatz zu der von
> C?

Nein.
Aber sie ist per default statisch gelinkt. Unter C ist sie per default 
dynamisch gelinkt. Guck dir mal an, wie groß eine libc .so/.dll ist.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Warum das? Es gibt immerhin mal eine untere Grenze für die Binary Größe
> an.

Weil es völlig egal ist, ob das 1 kB, 10 kB oder ein paar 100 kB sind, 
seit niemand mehr mit Disketten arbeitet.
Aber so kannst die Rust stdlib gerne dynamisch linken, wenn dich das 
stört.
Es ist halt (noch) nicht die Standardeinstellung, weil das ABI (noch) 
nicht stabil ist.

von Oliver R. (Gast)


Lesenswert?

Cyblord -. schrieb:
> Warum hat ein C Programm unter Windows
> nicht die gleichen Probleme?

Z.B. weil Rust einen Panic-Handler verwendet, während ein C Programm 
sich im Fall eines Absturzes einfach nur beendet.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Weil es völlig egal ist, ob das 1 kB, 10 kB oder ein paar 100 kB sind,

Genau DAS ist eben die fatale Einstellung der Rusties.

Ich denke Rust hat fertig. Rust kann gehen.

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


Lesenswert?

Cyblord -. schrieb:
>> Dass ein Helloworld kein sinnvoller Benchmark für die Größe eines
>> erzeugten Binaries ist, sollte jedem klar sein.
>
> Warum das?

Weil es nichts sinnvolles macht.

> Es gibt immerhin mal eine untere Grenze für die Binary Größe an.

Nein, falls da wirklich printf drin ist (meist wird es der Compiler 
rauskicken), dann bläht das auch schon auf. Die untere Grenze wäre
1
int main(void) {
2
  return 0;
3
}

MaWin schrieb:
> Aber sie ist per default statisch gelinkt.

Siehe oben, das allein erklärt das nicht. Auch bei statischem Linken 
wird aus einer Bibliothek nur rausgezogen, was benötigt wird.

Es erscheint mir auch nach all den Beschreibungen über die Features von 
Rust völlig logisch, dass da etwas mehr an Laufzeitsystem dahinter 
steckt. Alle diese Überprüfungen, die nicht schon der Compiler machen 
kann, müssen ja schließlich irgendwo stecken. Das ist bei FORTRAN oder 
Pascal nicht anders.

Komplett statisches Linken von Rust-Binaries scheint aber schon einiges 
an Aufwand zu sein, sonst hätte ich den Vergleich mal probiert. (Das 
zuweilen dokumentierte -C target-feature=+crt-static generiert trotzdem 
noch ein dynamisch gelinktes Binary, weil die Systembibliotheken 
dynamisch bleiben.)

von MaWin O. (mawin_original)


Lesenswert?

Jörg W. schrieb:
> Leuchtet allerdings dahingehend nicht ein, dass aus einer Library nur
> die Dinge gelinkt werden sollten, die auch tatsächlich benötigt werden.

Kannst gerne dran arbeiten, wenn es dich so stört.
Die Arbeit wird gerne angenommen.

Tipp: Auf Embedded-Rust ist das natürlich auch genau so, weil dort die 
stdlib im (LTO-)Build direkt mitgebaut wird statt dazugelinkt wird.
Das ist dann tatsächlich noch optimaler, als der C-Ansatz mit 
Link-Elision auf Funktionsbasis.

> Es werden wohl eher Dinge wie ein Laufzeitsystem sein, die das
> aufblähen.

Jörg wieder einmal wild am spekulieren.
Was soll das denn für ein Laufzeitsystem sein?

von Cyblord -. (cyblord)


Lesenswert?

Oliver R. schrieb:
> Cyblord -. schrieb:
>> Warum hat ein C Programm unter Windows
>> nicht die gleichen Probleme?
>
> Z.B. weil Rust einen Panic-Handler verwendet, während ein C Programm
> sich im Fall eines Absturzes einfach nur beendet.

Ja und? Will ich jetzt aber nicht haben. Muss ich aber drin haben? 
Super.

Ich stelle mir das schon vor:
"Also Chef, wir brauchen den größeren und teureren Controller, weil Rust 
hat den Panic Handler immer mit drin. Was der bringt? Bei uns gar 
nichts. Ja ist halt trotzdem drin. Ok machen wir das Produkt teuer. Die 
Kunden haben ja auch was davon. Was genau? Äh Ich muss weg."

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


Lesenswert?

MaWin O. schrieb:
> Jörg W. schrieb:
>> Leuchtet allerdings dahingehend nicht ein, dass aus einer Library nur
>> die Dinge gelinkt werden sollten, die auch tatsächlich benötigt werden.
>
> Kannst gerne dran arbeiten, wenn es dich so stört.

Das Verhalten, aus einer Library nur das rauszuziehen, was benötigt 
wird, hat nichts mit der Sprache zu tun, sondern ist eine Eigenschaft 
des Linkers.

> Was soll das denn für ein Laufzeitsystem sein?

Ich dachte, dass du mir das erklären kannst.

Oliver R. hat ja zumindest einen Punkt gebracht, der in diese Richtung 
passt.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Ja und? Will ich jetzt aber nicht haben. Muss ich aber drin haben?

Nein.
Du kannst es soweit reduzieren, dass es nur ein abort()-Aufruf ist.
Deine Entscheidung.

von MaWin O. (mawin_original)


Lesenswert?

Jörg W. schrieb:
> Ich dachte, dass du mir das erklären kannst.

Naja, du spekulierst hier wild herum über etwas, das es so nicht gibt.

von Oliver R. (Gast)


Lesenswert?

Cyblord -. schrieb:
> Ja und? Will ich jetzt aber nicht haben. Muss ich aber drin haben?
> Super.

Du hast von Windows geredet. Da ist der standardmässig drin.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
> Nein.
> Du kannst es soweit reduzieren, dass es nur ein abort()-Aufruf ist.
> Deine Entscheidung.

Ah wieder mal was per default drin was kacke ist. I see.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Ah wieder mal was per default drin was kacke ist. I see.

Es ist kacke ein Programm bei einem fatalen Problem vernünftig zu 
beenden und eine vernünftige Fehlermeldung auszugeben?
Verstehe.

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


Lesenswert?

MaWin O. schrieb:
> Cyblord -. schrieb:
>> Ja und? Will ich jetzt aber nicht haben. Muss ich aber drin haben?
>
> Nein.
> Du kannst es soweit reduzieren, dass es nur ein abort()-Aufruf ist.
> Deine Entscheidung.

Dann zeig doch bitte mal, wie diese "deine Entscheidung" praktisch 
aussieht.

Das (primitive) Codebeispiel ist oben. copy&paste einfach mal die 
nötigen Compileroptionen und das Ergebnis (wieder als Ausgabe von 
"size"). Das überzeugt deutlich mehr als eine wortreiche Erklärung "kann 
man doch alles abschalten". Bitte schalte es mal ab.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:

> Es ist kacke ein Programm bei einem fatalen Problem vernünftig zu
> beenden und eine vernünftige Fehlermeldung auszugeben?
> Verstehe.

In den meisten Fällen bringt dir das gar nichts. Das Gerät geht halt 
nicht mehr. Egal welche Handler da angesprungen oder nicht angesprungen 
werden.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

Jörg W. schrieb:
> Dann zeig doch bitte mal, wie diese "deine Entscheidung" praktisch
> aussieht.

Ach komm. Ist Google tatsächlich kaputt?
Das ist doch lächerlich.

Ich suche es jetzt garantiert nicht extra für dich raus, aber man muss 
ins Cargo.toml sowas wie panic=abort schreiben. Genauer habe ich es 
jetzt nicht im Kopf.

Cyblord -. schrieb:
> In den meisten Fällen bringt dir das gar nichts. Das Gerät geht halt
> nicht mehr. Egal welche Handler da angesprungen oder nicht angesprungen
> werden.

Genau deshalb schaltet man diesen Handler auf Embedded ja auch ab.
Wo ist eigentlich dein Problem?

von Le X. (lex_91)


Lesenswert?

Gibt es bei Rust für Embedded-Architekturen nicht irgendsowas wie 
-ffreestanding? Oder irgendwas um Teile der Laufzeitumgebung nicht 
mitzulinken?

Auf dem PC sind 3Mb Laufzeitgedöns vernachlässigbar (gesetzt dem Fall 
dass es nicht mitwächst und ein 100Mb-Exectuable auch nur 3Mb Bloat drin 
hat).
Embedded sind diese 3Mb natürlich ein NoGo.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

Le X. schrieb:
> Gibt es bei Rust für Embedded-Architekturen nicht irgendsowas wie
> -ffreestanding? Oder irgendwas um Teile der Laufzeitumgebung nicht
> mitzulinken?

Selbstverständlich. Nennt sich

#![no_std]

Wurde natürlich auch schon gesagt.

Le X. schrieb:
> Embedded sind diese 3Mb natürlich ein NoGo.

Gegebene Antworten hier nicht so lesen ist für mich ein NoGo.
Ich wiederhole das jetzt nicht.

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:

> Ach komm. Ist Google tatsächlich kaputt?
> Das ist doch lächerlich.

Ja, warum muss man ständig deine kruden Behauptungen selber googlen? 
Belege sie selbst oder nehme sie zurück.

> Ich suche es jetzt garantiert nicht extra für dich raus, aber man muss
> ins Cargo.toml sowas wie panic=abort schreiben. Genauer habe ich es
> jetzt nicht im Kopf.

Ja klar. Ist sicher echt trivial.

> Genau deshalb schaltet man diesen Handler auf Embedded ja auch ab.
> Wo ist eigentlich dein Problem?

Dass die Beispiele ständig zeigen dass es nicht brauchbar ist und du 
ständig behauptest man könne das alles auch anders haben, aber den 
Beweis schuldig bleibst und auf google verweist.
Argumentativ noch nackiger kann man sich ja nicht mehr machen als du 
hier gerade.

von Oliver R. (Gast)


Lesenswert?

Le X. schrieb:
> Gibt es bei Rust für Embedded-Architekturen nicht irgendsowas wie
> -ffreestanding? Oder irgendwas um Teile der Laufzeitumgebung nicht
> mitzulinken?

Das ist bei Rust "no-std", da wird nichts dazugelinkt und auch der Panic 
Handler muss explizit definiert werden.

von MaWin O. (mawin_original)


Lesenswert?

Cyblord -. schrieb:
> Belege sie selbst oder nehme sie zurück.

Ich werde weder das eine, noch das andere tun.
Stirb doch einfach dumm, Cyblord. Wie wäre das?

von Cyblord -. (cyblord)


Lesenswert?

MaWin O. schrieb:
> Stirb doch einfach dumm, Cyblord. Wie wäre das?

Solange ich ohne Rust sterben darf ist alles ok.

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


Lesenswert?

MaWin O. schrieb:
> Jörg W. schrieb:
>> Dann zeig doch bitte mal, wie diese "deine Entscheidung" praktisch
>> aussieht.
>
> Ach komm. Ist Google tatsächlich kaputt?

Ich habe auch nicht auf Google verwiesen, sondern Beispiele gezeigt, die 
man per copy&paste nachvollziehen kann.

Aber lass man, helfen oder gar jemanden überzeugen willst du offenbar 
nicht.

von MaWin O. (mawin_original)


Lesenswert?

Jörg W. schrieb:
> jemanden überzeugen willst du offenbar nicht.

Ganz gut erkannt.
Wenn du es nicht nutzen willst - und das willst du ganz offensichtlich 
nicht - dann lasse es halt.
Kein Problem.

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


Lesenswert?

MaWin O. schrieb:
> Ganz gut erkannt.
> Wenn du es nicht nutzen willst - und das willst du ganz offensichtlich
> nicht - dann lasse es halt.

Ich will es derzeit nicht nutzen (weil ich aktuell schlicht keine 
Anwendung für sowas habe). Ich mache aktuell auch bspw. kein C++.

Deshalb stecke ich jetzt auch keinen Aufwand da rein, aber es täte mich 
interessieren, und wenn ich das mal irgendwo gesehen habe, speichere ich 
mir solche Tricks gedanklich ab. Deshalb wäre ich daran interessiert, 
von jemandem, der damit täglich umgeht (und daher schneller ist als 
ich), sowas zu erfahren.

Von dir also offenbar nicht, dann lass es. Ich werde wohl lieber zu 
gegebener Zeit meinen Sohn danach fragen, das dürfte ergiebiger sein als 
so einen Sturkopf wie dich.

Sorry, musste mal raus.

von MaWin O. (mawin_original)


Lesenswert?

Jörg W. schrieb:
> Deshalb stecke ich jetzt auch keinen Aufwand da rein

Ja, das merke ich.
Das ist natürlich sehr klug mir den Aufwand aufzubürden und mich die 
Dokumentation durchsuchen zu lassen.
Nur tue ich das nicht.

> Deshalb wäre ich daran interessiert,
> von jemandem, der damit täglich umgeht (und daher schneller ist als
> ich), sowas zu erfahren.

Ich habe dir alle Stichworte geliefert, mit denen du es findest.
Der Rest liegt an dir.

> das dürfte ergiebiger sein als so einen Sturkopf wie dich.

Du bist ein ziemlich unverschämter Mensch, der direkt bockig wird, wenn 
andere Leute nicht nach deiner Pfeife tanzen.

Damit musst du leider leben.

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


Lesenswert?

MaWin O. schrieb:
> Das ist natürlich sehr klug mir den Aufwand aufzubürden und mich die
> Dokumentation durchsuchen zu lassen.

Nun, du hast behauptet, dass du das schon gemacht hast, insofern nahm 
ich an, dass du nicht erst Google bemühen musst. Da lag ich wohl falsch.

Wenn ich ansonsten genauso "bockig" wäre, wie du das behauptest, glaubst 
du, ich würde hier alle nasenlang Leuten bei den Problemen helfen, bei 
denen ich mich gut auskenne?

von Wilhelm M. (wimalopaan)


Lesenswert?

Bei mir ergibt das Rust HelloWorld Beispiel:
1
$ size hello
2
text    data     bss     dec     hex filename
3
1780     616       8    2404     964 hello

Das C++ Beispiel ist unwesentlich kleiner:
1
$ size hellocc
2
text    data     bss     dec     hex filename
3
1046     608       8    1662     67e hellocc

Beides dynamisch gelinkt.

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


Lesenswert?

Wilhelm M. schrieb:
> Bei mir ergibt das Rust HelloWorld Beispiel:

Das sieht doch gut aus.

Kannst du jetzt noch die Build-Optionen dafür posten?

von MaWin O. (mawin_original)


Lesenswert?

Jörg W. schrieb:
> Nun, du hast behauptet, dass du das schon gemacht hast, insofern nahm
> ich an, dass du nicht erst Google bemühen musst.

Richtig. Und ich habe ganz genau beschrieben, was ich gemacht habe und 
was ich noch im Kopf wusste.
Wo ist eigentlich dein Problem?
Statt hier mit mir zu diskutieren, hättest du schon lange "panic=abort" 
in Google eingeben können.
Das wäre vermutlich zu einfach gewesen.

von Wilhelm M. (wimalopaan)


Lesenswert?

Jörg W. schrieb:
> Wilhelm M. schrieb:
>> Bei mir ergibt das Rust HelloWorld Beispiel:
>
> Das sieht doch gut aus.
>
> Kannst du jetzt noch die Build-Optionen dafür posten?
1
rustc -C opt-level=z -C strip=symbols -C prefer-dynamic=yes hello.rs

Aber das haben die Rust-Experten hier ja sicher alles gewusst ;-)

Und statisch ist Rust und C++ auch wieder vergleichbar.

: Bearbeitet durch User
von Oliver R. (Gast)


Lesenswert?

Weil hier nach Beispielen für STM32 gefragt wurde ein, hier ein 
typisches "Blinky":

https://gitlab.com/jounathaen-projects/embedded-rust/blinky-rust

Ergibt als Release Build
1
   text     data      bss      dec      hex  filename
2
    820        0        4      824      338  blinky-rust

von Dergute W. (derguteweka)


Lesenswert?

Moin,

OK, damit kommt dann bei mir, wenn man sich das executable mittels ldd 
anguckt, noch eine weitere shared-lib dazu, die dann halt den Krempel, 
der vorher das binary so aufgeblasen hat, beinhalten wird. Bei so einem 
genialen Namen wie dann hier dafuer verwendet wird, freu' ich mich schon 
arg auf interoperabilitaet.
Achja: Neben den ganzen lustigen, aber scheint's wohl etwas 
platzfressenden Gimmicks von rust wird natuerlich in allen Faellen 
immernoch zusaetzlich die libc gebraucht...
1
ldd hello
2
  linux-vdso.so.1 (0x00007ffe60353000)
3
  libstd-b5176101f2c4a3c2.so => /opt/rustc/lib/libstd-b5176101f2c4a3c2.so (0x00007f9a9bbac000)
4
  libc.so.6 => /usr/lib/libc.so.6 (0x00007f9a9b9aa000)
5
  libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f9a9b990000)
6
  /lib64/ld-linux-x86-64.so.2 (0x00007f9a9bd6a000)

Gruss
WK

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


Lesenswert?

Wilhelm M. schrieb:
> Und statisch ist Rust und C++ auch wieder vergleichbar.

Hast du denn Rust statisch bekommen? Ich nicht, libc war trotzdem noch 
dynamisch, und das Netz verweist auf MUSL (oder so ähnlich).

von MaWin O. (mawin_original)


Lesenswert?

Dergute W. schrieb:
> Bei so einem
> genialen Namen wie dann hier dafuer verwendet wird, freu' ich mich schon
> arg auf interoperabilitaet.

Und deine konkrete Kritik ist jetzt was?

> von rust wird natuerlich in allen Faellen
> immernoch zusaetzlich die libc gebraucht...

Selbstverständlich nicht.
Aber das wurde hier mehrfach erklärt. Auch heute noch einmal. Deshalb 
wiederhole ich das jetzt nicht noch einmal.

Auf einem PC ist die libc halt de-facto die Schnittstelle zum 
Betriebsystem. Auf Windows ganz offiziell und auf Linux praktisch auch. 
Direkte Syscalls macht niemand.
Wenn man kein OS hat, dann braucht man die libc selbstverständlich 
nicht.
(Auf AVR braucht man sie derzeit nur, weil sie noch niemand rausgeworfen 
hat und die paar benötigten Features in Rust neuimplementiert hat.).

von Wilhelm M. (wimalopaan)


Lesenswert?

Dergute W. schrieb:
> OK, damit kommt dann bei mir, wenn man sich das executable mittels ldd
> anguckt, noch eine weitere shared-lib dazu, die dann halt den Krempel,
> der vorher das binary so aufgeblasen hat, beinhalten wird.

Das ist bei C++ auch so (und auch bei anderen Sprachen außer C). Nur C 
kommt (fast) nur mit der C-Lib aus.

Alles andere braucht auch die C-Lib, weil das auf den meisten Systemen 
das POSIX-API realisiert. Daher auch bei einem Rust executable.

von Wilhelm M. (wimalopaan)


Lesenswert?

Jörg W. schrieb:
> Wilhelm M. schrieb:
>> Und statisch ist Rust und C++ auch wieder vergleichbar.
>
> Hast du denn Rust statisch bekommen? Ich nicht, libc war trotzdem noch
> dynamisch, und das Netz verweist auf MUSL (oder so ähnlich).

Nicht vollständig wie bei C / C++ / ....
Das bezieht sich bei Rust nur auf die Bib von Rust selbst. Aber ich bin 
kein Rust Experte ...

Wenn ich mir ein
1
nm hello

ansehe, dann weiß ich auch, warm das dann so groß ist ;-)

: Bearbeitet durch User
von Dergute W. (derguteweka)


Lesenswert?

Moin,

MaWin O. schrieb:
> Dergute W. schrieb:
>> Bei so einem
>> genialen Namen wie dann hier dafuer verwendet wird, freu' ich mich schon
>> arg auf interoperabilitaet.
>
> Und deine konkrete Kritik ist jetzt was?
Keine Kritik - ich schrieb doch: ich freue mich... :-)

> Aber das wurde hier mehrfach erklärt. Auch heute noch einmal. Deshalb
> wiederhole ich das jetzt nicht noch einmal.
Tschuldigung, ich bin da halt etwas begriffstutzig.

> Auf einem PC ist die libc halt de-facto die Schnittstelle zum
> Betriebsystem. Auf Windows ganz offiziell und auf Linux praktisch auch.
> Direkte Syscalls macht niemand.
> Wenn man kein OS hat, dann braucht man die libc selbstverständlich
> nicht.
> (Auf AVR braucht man sie derzeit nur, weil sie noch niemand rausgeworfen
> hat und die paar benötigten Features in Rust neuimplementiert hat.).
Axo. Selbstverstaendlich.
Wie kam ich nur auf das schmale Brett, das bei dem sicheren Rust 
vielleicht auch der ganze "unsichere, in boesem C geschriebene" Unterbau 
durch was eigenes, viel geileres, sichereres ersetzt worden haette sein 
koennen. Von der Groesse der "Rust-Laufzeitumgebung" vielleicht? 
Neeeein, ist sicher nur, weil ich halt so'n bissl langsamer im Denken 
bin.

Gruss
WK

von MaWin O. (mawin_original)


Lesenswert?

Dergute W. schrieb:
> Neeeein, ist sicher nur, weil ich halt so'n bissl langsamer im Denken
> bin.

Gut erkannt.

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> 307914 vs 1839.
>
> Damit hat sich die Frage nach Rust für Embedded sowieso bereits
> erledigt. Wie schon vermutet, alles ein Phänomen im PC Bereich. Wo bei
> Speicher und Co. alles egal ist.
> Wie soll man mit so einem Footprint C für den Microcontrollerbereich mit
> wenigen MB oder gar kB Flash ablösen? Utopie trifft Wahnvorstellung.

das liegt primär daran das Rust die Standardlib statisch linked - auf 
embedded sieht das ganz ganz anders aus

btw: du wolltest noch erklären warum das Iterator-Konzept ein No-go für 
embedded ist, hast du jetzt Zeit gefunden dir das zu überlegen?

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


Lesenswert?

cppbert schrieb:
> du wolltest noch erklären warum das Iterator-Konzept ein No-go für
> embedded ist

:-))

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


Lesenswert?

cppbert schrieb:
> das liegt primär daran das Rust die Standardlib statisch linked - auf
> embedded sieht das ganz ganz anders aus

Naja: dort wird alles statisch gelinkt (zumindest auf MCUs - auf MPUs 
läuft ja eher ein reguläres OS).

von MaWin O. (mawin_original)


Lesenswert?

Jörg W. schrieb:
> Naja: dort wird alles statisch gelinkt

Es ist trotzdem ein Unterschied, weil bei Rust Embedded (beim normalen 
Arbeiten mit Cargo) die stdlib nicht vorkompiliert ist. Sie nimmt Teil 
an dem einen Gesamtbuild mit dem einen LTO.

Geht natürlich auch anders, wenn man will, aber sinnvoll ist es allemal 
das Gesamtkonstrukt zu optimieren und dann nichts mehr hinzu zu linken.

von cppbert (Gast)


Lesenswert?

Niemand hat gesagt das Rust und die komplette Tool-Chain 100% ausgereift 
ist, es geht hier (nach meiner Meinung) primär um die Sprache selbst

und wenn die GCC Leute ihr eigenes Frontend bauen sieht es da auch ganz 
anders aus und falls Microsoft dann noch hinterher hüpft mit Rust# (ich 
hoffe nicht) sieht es nochmal anders aus

von MaWin O. (mawin_original)


Lesenswert?

cppbert schrieb:
> Niemand hat gesagt das Rust und die komplette Tool-Chain 100% ausgereift
> ist

Das genügt den µC.net-Ansprüchen aber nicht.
Es muss alles perfekt sein. Erst dann kann die bekanntlich perfekte 
Sprache C abgelöst werden.
Da werden keinerlei Kompromisse eingegangen. :)

Außer bei den eigenen Kenntnissen. Da werden Kompromisse eingegangen bis 
hin zur völligen Abwesenheit.

> es geht hier (nach meiner Meinung) primär um die Sprache selbst

Ich finde es schon wichtig auch zu zeigen, dass zum Beispiel das 
Standard-Buildsystem Cargo praktisch allen anderen Buildsystemen 
haushoch überlegen ist.

Es funktioniert einfach sehr gut.
Selbstverständlich liegt das auch daran, dass es perfekt auf Rust und 
seinen Compiler zugeschnitten ist. Das ist klar.

cppbert schrieb:
> und wenn die GCC Leute ihr eigenes Frontend bauen sieht es da auch ganz
> anders aus

Ich denke nicht, dass es ganz anders aussieht.
Aber sicher wird man Aspekte der Sprache finden, über die sich bisher 
formell noch niemand Gedanken gemacht hat und die einfach so sind, weil 
rustc sie so implementiert. Das ist ja bereits so passiert und wird auch 
noch ein paar mal passieren.
Das führt aber dazu, dass die Sprache als Ganzes noch besser wird. 
Deshalb sind sowohl gccrs als auch codegen-gcc ganz wichtige Projekte.
Die Geschichte hat uns gelehrt, dass erst LLVM/clang wieder Leben in die 
damals völlig festgerostete gcc-Entwicklung gebracht hat.

von MaWin O. (mawin_original)


Lesenswert?

> Announcing Rust 1.66.0

https://blog.rust-lang.org/2022/12/15/Rust-1.66.0.html

> Explicit discriminants on enums with fields

Ist manchmal ganz nützlich z.B. in Parsern oder Protokollinterpretern.
Jetzt auch mit komplexen enums.

> core::hint::black_box

Könnte nützlich sein für Embedded-Entwicklung.
Da ist tatsächlich oft das "Problem", dass es einem den Code komplett 
wegoptimiert, wenn man ihn nirgendwo verwendet. z.B. wenn man nur mal 
kurz schauen will, zu welchem Assembly ein Stück Code generiert war es 
oft notwendig die Ein- und Ausgaben zu diesem Code irgendwie über 
volatile-Zugriffe zu machen.
Das hier vereinfacht das sicher enorm.

> checked signed+unsigned operations

Das ist tatsächlich sehr nützlich und wird einige Programmteile deutlich 
verkürzen.
Rust verbietet normalerweise Operationen zwischen verschiedenen Typen. 
Deshalb muss man Typen konvertieren und dann natürlich Überlaufprüfungen 
usw. machen. Es gibt aber einige Funktionen, die einige dieser gängigen 
Operationen erleichtern und gleichzeitig safe halten.

> You can now use ..=X ranges in patterns.

Jo das ist gut. Weiß gar nicht, warum das so lange nicht stabil war :)

von cppbert (Gast)


Lesenswert?

MaWin O. schrieb:
> Ich finde es schon wichtig auch zu zeigen, dass zum Beispiel das
> Standard-Buildsystem Cargo praktisch allen anderen Buildsystemen
> haushoch überlegen ist.

das gehört für mich zu der "Sprache" dazu - ist ja auch ein Konzept

Es wird sich zeigen wie die integration in GCC sein wird - nur Rust als 
Sprache oder auch gccrs_cargo als weitere Implementation

ich meinte beim Bezug zum GCC auch nur das dort das Linken usw. 
default-Verhalten nicht unbedingt so sein muss wie beim Referenz-System 
rustc usw.

von MaWin O. (mawin_original)


Lesenswert?

cppbert schrieb:
> ich meinte beim Bezug zum GCC auch nur das dort das Linken usw.
> default-Verhalten nicht unbedingt so sein muss wie beim Referenz-System
> rustc usw.

Achso. Ja.
Das Linken hat natürlich gar nichts mit rustc zu tun. Auch heute nicht. 
Das ist wie Cargo die Toolchain bedient. Deshalb denke ich aber schon, 
dass sich das nicht grundsätzlich unterscheiden wird. Jedenfalls nicht 
mehr, als es sich bei gcc vs clang unterscheidet.

von cppbert (Gast)


Lesenswert?

MaWin O. schrieb:
> Achso. Ja.
> Das Linken hat natürlich gar nichts mit rustc zu tun. Auch heute nicht.
> Das ist wie Cargo die Toolchain bedient.

und dann landet das auch auch schön in cygwin oder mingw, msys2 und rbx 
ist gleich wieder froh :)

von Oliver R. (Gast)


Lesenswert?

cppbert schrieb:
> Es wird sich zeigen wie die integration in GCC sein wird - nur Rust als
> Sprache oder auch gccrs_cargo als weitere Implementation

cargo dürfte eigentlich nur den Compileraufruf wrappen. Ob das dann 
gcc-rs anstelle von rustc ist, sollte nicht die entscheidende Rolle 
spielen. Flags und Optionen müssen natürlich ggfs. angepasst werden.

von Nano (Gast)


Angehängte Dateien:

Lesenswert?

Jörg W. schrieb:
>
1
> ...
2
> $ rustc -O helloworld.rs
3
> ...
4
> $ size helloworld
5
>     text    data   bss      dec       hex   filename
6
>   307914   12864   273   321051   0x4e61b   helloworld
7
>
> OK, Gegentest:
>
1
> ...
2
> $ cc -O -o helloworld helloworld.c
3
> ...
4
> $ size helloworld
5
>   text   data   bss    dec     hex   filename
6
>   1839    409     8   2256   0x8d0   helloworld
7
>
> Gut, etwas kleiner. :-)
>
1
> ...
2
> $ c++ -O -o helloworld helloworld.cc
3
> ...
4
> $ size helloworld
5
>   text   data   bss    dec      hex   filename
6
>   4997    649   192   5838   0x16ce   helloworld
7
>
> Aber so ist das mit Trivialbeispielen, sie sind völlig unrepräsentativ
> für die reale Welt.

C ist immer noch total fett, wenn man es mit Assembler vergleicht.

Hier bei mir braucht ein einfaches "Hello World!" in Rust 297208 Bytes.

Meine Version in Assembler unter DOS braucht 87 Bytes.

Gut, das ist ein 16 Bit REAL MODE Programm, aber meine 64 Bit Rust 
Version und deine C und C++ Binaries sind immer noch um ein Vielfaches 
größer.

Das OS ist ein anderes und es sind 64 Bit Binaries, aber selbst wenn man 
bedenkt, dass die Binaries nicht statisch gelinkt sind und das printf 
von libc in der libc auch noch Platz braucht, ist das ziemlich viel 
Platz, was da benötigt wird.

Die NASM Version unter Linux braucht mit nur 50 Bytes sogar noch weniger 
Bytes. Das könnte allerdings am SYSCALL liegen, d.h. der Kernel macht 
hier mehr und weil die Segmente wegfallen.

von Nano (Gast)


Lesenswert?

MaWin schrieb:
> Cyblord -. schrieb:
>> Warum das? Es gibt immerhin mal eine untere Grenze für die Binary Größe
>> an.
>
> Weil es völlig egal ist, ob das 1 kB, 10 kB oder ein paar 100 kB sind,
> seit niemand mehr mit Disketten arbeitet.

Wenn das komplette Programm in den L1 Cache der CPU passt, macht das 
schon etwas aus, wenn es performancekritisch ist.

Der Intel Tiger Lake hat nur einen L1 Cache von 48 KiB für Daten und 32 
KiB für Befehle. Da sind 100 KiB schon zu groß.

von MaWin O. (mawin_original)


Lesenswert?

Nano schrieb:
> Wenn das komplette Programm in den L1 Cache der CPU passt, macht das
> schon etwas aus, wenn es performancekritisch ist.

Wer kennt sie nicht, die performancekritischen Hello-World-Programme.

Außerdem: Lies mal nach, was Dateigröße, Sectiongröße und RAM-Belegung 
unterscheidet.
Es ist nicht mehr DOS.

Du fragst: Wo soll ich das lesen? Wo soll ich mich weiterbilden?
Die Antwort wird dich total überraschen: Hier im Thread! Heute!

von Nano (Gast)


Lesenswert?

MaWin O. schrieb:
> Nano schrieb:
>> Wenn das komplette Programm in den L1 Cache der CPU passt, macht das
>> schon etwas aus, wenn es performancekritisch ist.
>
> Wer kennt sie nicht, die performancekritischen Hello-World-Programme.

Mein Supergirl hat nunmal hohe Ansprüche an eine schnelle 
Bildschirmausgabe.

>
> Außerdem: Lies mal nach, was Dateigröße, Sectiongröße und RAM-Belegung
> unterscheidet.

Nö, das weiß ich. Wenn du das binary strippst, dann unterscheidet sich 
die ls Ausgabe nicht mehr groß von size.

> Du fragst: Wo soll ich das lesen? Wo soll ich mich weiterbilden?

Ich habe gar nichts derartiges gefragt.

von MaWin O. (mawin_original)


Lesenswert?

Nano schrieb:
> Nö, das weiß ich. Wenn du das binary strippst, dann unterscheidet sich
> die ls Ausgabe nicht mehr groß von size.

Besser doch noch einmal hier nachlesen und sich weiterbilden.

von Nano (Gast)


Lesenswert?

MaWin O. schrieb:
> Nano schrieb:
>> Nö, das weiß ich. Wenn du das binary strippst, dann unterscheidet sich
>> die ls Ausgabe nicht mehr groß von size.
>
> Besser doch noch einmal hier nachlesen und sich weiterbilden.

Wie ich bereits sagte, muss ich das nicht, da ich das schon weiß.

Dein Problem ist, dass du Fakten nicht als gegeben hinnehmen willst. 
Wenn jemand Fakten liefert, dann greifst du die Person persönlich an. 
Such dir also mal einen Psychologen.

von MaWin O. (mawin_original)


Lesenswert?

Nano schrieb:
> Wie ich bereits sagte, muss ich das nicht, da ich das schon weiß.

Anscheinend ja nicht.

> Dein Problem ist, dass du Fakten nicht als gegeben hinnehmen willst.
> Wenn jemand Fakten liefert, dann greifst du die Person persönlich an.

Bitte einmal ein vollständiges Zitat liefern, wo ich das getan habe. Und 
zwar nicht als Reaktion auf einen vorhergehenden persönlichen Angriff 
(wie heute von unserem Herrn Moderator).
Danke.

von Nano (Gast)


Lesenswert?

MaWin O. schrieb:
> Nano schrieb:
>> Wie ich bereits sagte, muss ich das nicht, da ich das schon weiß.
>
> Anscheinend ja nicht.
>
>> Dein Problem ist, dass du Fakten nicht als gegeben hinnehmen willst.
>> Wenn jemand Fakten liefert, dann greifst du die Person persönlich an.
>
> Bitte einmal ein vollständiges Zitat liefern, wo ich das getan habe. Und
> zwar nicht als Reaktion auf einen vorhergehenden persönlichen Angriff

Hier Z.B.
> Anscheinend ja nicht.

Du unterstellst mir Dinge, die 1. nicht stimmen und 2. obwohl du keine 
Ahnung über mich hast und 3. es völlig am Thema vorbei geht, ich scheine 
dir wohl wichtig zu sein.

Dich stört der Fakt, dass Assemblerprogramme kleiner sind als C oder 
Rust Programme. Denn mehr als eine wertfreie Aussage dazu inkl. 
Lieferung eines Beweises habe ich nicht gesagt. Das könnte man jetzt als 
so gegeben hinnehmen und fertig.
Aber du kochst rot vor Wut, weil ich es gewagt habe, das einfach mal 
wertfrei und objektiv an das schwarze Brett zu hängen, damit es jeder 
lesen kann. Sprich, du hast Komplexe und noch ganz andere Probleme, komm 
mal klar.

von Nano (Gast)


Lesenswert?

Noch eine Ergänzung als Auflösung für dich.

Ich habe ls anstatt size benutzt, weil es beim strippen relativ egal ist 
und ich ls aus reiner Gewohnheit verwende und es ausreichend gut ist.
Und meine Screenshots sind älter, als mein Lesen des Kommentars von 
Jörg, der dich darauf hingewiesen hat, dass man size zum messen 
verwenden soll:
Beitrag "Re: Rust - ist das hier um zu bleiben?"

Und jetzt nörgelst du daran herum, weil du streiten willst. Siehe dazu 
mein vorheriges Kommentar, ich kann mich da nur wiederholen, komm mal 
klar.

von MaWin O. (mawin_original)


Lesenswert?

Nano schrieb:
>> Anscheinend ja nicht.
> Du unterstellst mir Dinge

Du solltest einmal nachschlagen, was das Wort "anscheinend" bedeutet.

> Dich stört der Fakt, dass Assemblerprogramme kleiner sind als C oder
> Rust Programme.

Völliger Unsinn.

> Das könnte man jetzt als so gegeben hinnehmen und fertig.

Und warum tust du das dann nicht?

> Aber du kochst rot vor Wut

Ach? Habe ich gar nicht gemerkt.

> das einfach mal
> wertfrei und objektiv an das schwarze Brett zu hängen

Und für meine Antwort auf deinen Beitrag gelten diese Grundsätze nicht?

> Sprich, du hast Komplexe und noch ganz andere Probleme, komm
> mal klar.

Hm ja. Danke, Herr Psychologe, der auch sagt:

Nano schrieb:
> dann greifst du die Person persönlich an.

Aber du scheinst mich ja ziemlich gut zu kennen, denn

> Und jetzt nörgelst du daran herum, weil du streiten willst.

Du scheinst ein sehr angenehmer Zeitgenosse zu sein.

von Nano (Gast)


Lesenswert?

MaWin O. schrieb:
> Bla bla bla

von MaWin O. (mawin_original)


Lesenswert?

Nano schrieb:
>> Bla bla bla

Ganz schön wertfrei und objektiv, deine Antwort.
Danke dafür.

von Nano (Gast)


Lesenswert?

MaWin O. schrieb:
> Nano schrieb:
>>> Bla bla bla
>
> Ganz schön wertfrei und objektiv, deine Antwort.
> Danke dafür.

Ich habe nicht geantwortet, ich habe lediglich dein Geschwurbel in 3 
Wörtern zusammengefasst.

von MaWin (Gast)


Lesenswert?

Nano schrieb:
> Ich habe nicht geantwortet, ich habe lediglich dein Geschwurbel in 3
> Wörtern zusammengefasst.

Also:

Nano schrieb:
> Wenn jemand Fakten liefert, dann greifst du die Person persönlich an.
> Such dir also mal einen Psychologen.

von cppbert (Gast)


Lesenswert?

@Nano

MaWin hat es lediglich versäumt dir zu erklären das dein Assembler 
Beispiel dank Syscall nutzung völlig sinnfrei ist um irgendwelche 
Größenvergleiche zu betreiben - spätestens bei DOS geschwurbel wurde 
klar das es dir irgendwie nur darum geht ein wenig Technik zu schnattern

und jetzt hört bitte auf euch anzuzicken

von rbx (Gast)


Lesenswert?

cppbert schrieb:
> und dann landet das auch auch schön in cygwin oder mingw, msys2 und rbx
> ist gleich wieder froh :)

Naja, nicht nur ich..
https://stackoverflow.com/questions/55603111/unable-to-compile-rust-hello-world-on-windows-linker-link-exe-not-found

Ich hatte bei der Seite mit den "Standalone" Downloads die falschen 
Versionen heruntergeladen und installiert.

("rust-1.65.0-aarch64-pc-windows-msvc.msi")

Jetzt habe ich eine Version heruntergeladen und installiert, die heißt 
"rust-nightly-i686-pc-windows-msvc.msi".

Stunden später..

Installation OK, Pfadeinträge OK, rustc trallalla.rs..

>
>dir
..

trallalla.rs
>

wo ist meine exe??

Wie in Linux: keine Nachricht ist eine gute Nachricht?

Ich frage mich eher: was habe ich jetzt schon wieder falsch gemacht?
Ich würde mich hinsichtlich der möglichen Antworten aber eher nicht auf 
die Persönlichkeitsanalyseprofis MaWin oder cppbert hier verlassen 
wollen.

von cppbert (Gast)


Lesenswert?

rbx schrieb:
> Ich würde mich hinsichtlich der möglichen Antworten aber eher nicht auf
> die Persönlichkeitsanalyseprofis MaWin oder cppbert hier verlassen
> wollen.

Wirklich keine Ahnung was du machst aber ich hab auch von VS2017,19,22, 
MSys2, Clang, Python, zum spielen D und Rust, ... Linux usw. auch 
einfach alles auf meinem Win10, VMWare Linux Systemen drauf - könnte 
sein das ich einfach nur dusel hab weil ich schon so viel installiert 
habe - und  mit den Systemen aber Fulltime jeden Tag arbeite kann es gut 
sein das kleine Probleme mir gar nicht mehr auffallen weil ich eh den 
ganzen Tag durch CMake, make oder sonstige Orgien wühle und relativ 
genau weiss was ich tun muss damit etwas aus/oder mit Code funktioniert

von cppbert (Gast)


Lesenswert?

cleaner Win10 VM, 
https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-msvc/rustup-init.exe 
aufgerufen, 40sek später läuft rustc sauber durch mit hello world - 
keine Ahnung was deine Probleme sind

ich hab eine 120MBit Leitung und 8 Kerne oder so - aber macht das so 
viel aus?

von cppbert (Gast)


Lesenswert?

dann noch 
https://www.oreilly.com/library/view/rust-programming-by/9781788390637/e07dc768-de29-482e-804b-0274b4bef418.xhtml
1
rustup default nightly

in der Konsole - 30sek später bin ich auf nightly
1
rustc --version
2
rustc 1.68.0-nightly (ec56537c4 2022-12-15)

rustup ist so ein bisschen wie pacman von cygwin/msys2

von Oliver R. (Gast)


Lesenswert?

Man kann die verwendete Version auch pro Projekt festlegen:

https://rust-lang.github.io/rustup/overrides.html#the-toolchain-file

von rbx (Gast)


Lesenswert?

cppbert schrieb:
> keine Ahnung was deine Probleme sind

Vielleicht Windows 8.1?
Und: hast du die Standaloneversion genutzt?
Haskell Plattform kam auch erst nach einigen Klimmzügen bei der 
Installation auf ME auf den Trichter, die falsche Windowsversion zu 
melden.
Hätte man auch gleich am Anfang machen können.
Aber ich will keine Vorurteile haben.

Version ist rustc 1.68.0-nightly (b70baa4f9 2022-12-14)
rustup geht nicht, kann aber mit der Standaloneversion zu tun haben.
Außerdem habe ich keine Admininstallation, sondern nur eine auf 
Userbasis, was man ja im Installer ausdrücklich einstellen konnte.

von cppbert (Gast)


Lesenswert?

rbx schrieb:
> cppbert schrieb:
>> keine Ahnung was deine Probleme sind
>
> Vielleicht Windows 8.1?
Win10

> Und: hast du die Standaloneversion genutzt?

Nein - die verwende ich nicht - ist nicht prefered und auch nur für die 
welchen eine "richtigen" Installer wollen oder unbedingt offline - ich 
hasse grafische Installer - die sehen schön aus - dahinter ist meist 
Schrott weil keiner Bock hat die zu pflegen - da ist mir jede 
Konsolen-Installation 1000% lieber

https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-msvc/rustup-init.exe

dann

rustup default nightly

von cppbert (Gast)


Lesenswert?

rbx schrieb:
> Außerdem habe ich keine Admininstallation, sondern nur eine auf
> Userbasis, was man ja im Installer ausdrücklich einstellen konnte.

ich hab auch keine Admininstallation - sowas macht auch wirklich niemand 
mehr der nicht ein bisschen verrückt ist

von Cyblord -. (cyblord)


Angehängte Dateien:

Lesenswert?

cppbert schrieb:
> rbx schrieb:
>> Außerdem habe ich keine Admininstallation, sondern nur eine auf
>> Userbasis, was man ja im Installer ausdrücklich einstellen konnte.
>
> ich hab auch keine Admininstallation - sowas macht auch wirklich niemand
> mehr der nicht ein bisschen verrückt ist

Das ist halt auch so ein 1990er Einstellung.
Auch für dich hat XKCD was auf Lager.
https://xkcd.com/1200/

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

rbx schrieb:
> Ich frage mich eher: was habe ich jetzt schon wieder falsch gemacht?

Ja. Das fragen wir uns alle.
Normale Leute klicken auf rustup-init.exe, installieren die stable 
Variante (Warum zum Henker installierst du nightly?), und zack schon hat 
man ein voll funktionsfähiges Rust + Cargo.
Ich habe echt nicht die geringste Ahnung, was du da veranstaltest.

von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Auch für dich hat XKCD was auf Lager.

Das widerspricht ja gar nicht cppbert's Aussage. Ist dir das nicht 
selbst aufgefallen?

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Cyblord -. schrieb:
>> Auch für dich hat XKCD was auf Lager.
>
> Das widerspricht ja gar nicht cppbert's Aussage. Ist dir das nicht
> selbst aufgefallen?

Nein ist es nicht. Weil es genau passt.

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> MaWin schrieb:
>> Cyblord -. schrieb:
>>> Auch für dich hat XKCD was auf Lager.
>>
>> Das widerspricht ja gar nicht cppbert's Aussage. Ist dir das nicht
>> selbst aufgefallen?
>
> Nein ist es nicht. Weil es genau passt.

aber

> Auch für dich hat XKCD was auf Lager.
> https://xkcd.com/1200/

klingt so als hätte ich jemands Admin-Installationen befürwortet :)

von cppbert (Gast)


Lesenswert?

cppbert schrieb:
> klingt so als hätte ich jemands Admin-Installationen befürwortet :)

jemals

von cppbert (Gast)


Lesenswert?

wer Admin-Installation macht öffnet Tür und Tor für jedes erdenkliche 
Problem

von MaWin (Gast)


Lesenswert?

rbx schrieb:
>> keine Ahnung was deine Probleme sind
> Vielleicht Windows 8.1?

Ziemlich sicher auch.
Niemand testet Rust auf einem Betriebssystem, dessen Support ausgelaufen 
ist.
Aber darauf hättest du natürlich auch selbst kommen können.

von Cyblord -. (cyblord)


Lesenswert?

cppbert schrieb:
>> Auch für dich hat XKCD was auf Lager.
>> https://xkcd.com/1200/
>
> klingt so als hätte ich jemands Admin-Installationen befürwortet :)

Kann es sein dass du das XKCD nicht verstanden hast? Es spricht sich FÜR 
Admininstallationen aus. Weil eine eingeschränkte User-Installation 
heute nicht mehr viel bringt, weil alles wichtige heute online passiert 
und nicht in den tiefen des OS.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Cyblord -. schrieb:
> Es spricht sich FÜR Admininstallationen aus.

Nein, tut es nicht.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Cyblord -. schrieb:
>> Es spricht sich FÜR Admininstallationen aus.
>
> Nein, tut es nicht.

Ja ok ich verstehe langsam das Problem in den Begrifflichkeiten. Es geht 
um Admininstallationen vs. getrennte Admin- und Userinstallationen.
Es spricht sich allerdings dafür aus, dass man standardmäßig auf 
Adminrechten arbeitet.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

MaWin schrieb:
> Niemand testet Rust auf einem Betriebssystem, dessen Support ausgelaufen
> ist

Rust ist seiner Zeit voraus? ;-)

"Windows 8.1 Support endet am 10. Januar 2023"

https://support.microsoft.com/de-de/windows/windows-8-1-support-endet-am-10-januar-2023-3cfd4cde-f611-496a-8057-923fba401e93

Also aktuell ist es noch supportet … (wenn auch nur gerade noch so).

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> Weil eine eingeschränkte User-Installation
> heute nicht mehr viel bringt

völliger Quatsch - nur schlechte miese Software benötigt das - es gibt 
aber viele die seit UAC anfängen alles nur noch als Admin installieren - 
aus Gewohnheit - ich mache gar keine Admin-Installationen - maximal 
läuft das VStudio mal kurzfristig als Admin damit der Intel-VTune an die 
Hardware-Counter kommt - aber nur so lange Performanz-Tests laufen

ohne Grund eine Admin-Installation zu machen ist völlig hirnlos

von Cyblord -. (cyblord)


Lesenswert?

cppbert schrieb:
> Cyblord -. schrieb:
>> Weil eine eingeschränkte User-Installation
>> heute nicht mehr viel bringt
>
> völliger Quatsch - nur schlechte miese Software benötigt das
Darum geht es gar nicht.

> - es gibt
> aber viele die seit UAC anfängen alles nur noch als Admin installieren -
> aus Gewohnheit - ich mache gar keine Admin-Installationen - maximal
> läuft das VStudio mal kurzfristig als Admin damit der Intel-VTune an die
> Hardware-Counter kommt - aber nur so lange Performanz-Tests laufen
>
> ohne Grund eine Admin-Installation zu machen ist völlig hirnlos

Und das sieht halt XKCD anders. Und es wird ja auch begründet. Mehr sage 
ich ja nicht.
Du hingegen kannst bisher nicht begründen was die eingeschränkten Rechte 
bringen sollen.

: Bearbeitet durch User
von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> Und das sieht halt XKCD anders. Mehr sage ich ja nicht.

rbx hat geschrieben

> Außerdem habe ich !!! keine !!! Admininstallation

und dann hast (nur) du angefangen von Admin-Installation zu sprechen

von cppbert (Gast)


Lesenswert?

Cyblord -. schrieb:
> Du hingegen kannst bisher nicht begründen was die eingeschränkten Rechte
> bringen sollen.

Mehr Sicherheit, weniger Konflikte zwischen Applikationen wenn manche 
anfangen teilweise mit Adminrechten Dateien usw. zu erstellen

das ist völliger veralteter Windows-Noob User Style - hauptsache das 
System läuft irgendwie

von Cyblord -. (cyblord)


Lesenswert?

cppbert schrieb:
> das ist völliger veralteter Windows-Noob User Style

Wie gesagt, in den 90er war diese Einstellung unter Profis Konsens. Aber 
heute kann man das schon hinterfragen. Die Zeiten ändern sich. Du 
scheinst halt in alten Mustern festzuhängen.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Also aktuell ist es noch supportet … (wenn auch nur gerade noch so).

Ja. War mir klar, das dieser dümmliche Kommentar kommen musste.

https://learn.microsoft.com/de-de/lifecycle/products/windows-81

> Enddatum des Mainstreamsupports:  9. Jan. 2018
> Erweitertes Enddatum:  10. Jan. 2023

Windows 8.x ist tot. Das ist Fakt.
Es zu verwenden ist dumm.
Nun zu jammern, dass Rust darauf eventuell Probleme haben könnte, ist 
noch dümmer.

Niemand interessiert sich für historische Betriebssysteme im 
Rust-Umfeld.

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


Lesenswert?

MaWin schrieb:
> War mir klar, das dieser dümmliche Kommentar kommen musste.

Ah ja, die Realität ist "dümmlich".

Mir ist persönlich Windows ziemlich schnuppe (Rust interessiert mich 
wenigstens, anders als Windows), ich gehe auch nicht davon aus, dass 
seine alte Windows-Version da tatsächlich eine Rolle spielt.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Ah ja, die Realität ist "dümmlich".

Nein. Deine Antwort ist dümmlich.
Mir war völlig klar, dass der erweiterte Support erst in ein paar Tagen 
ausläuft.
Für mein Argument spielt das allerdings genau gar keine Rolle. Deshalb 
habe ich es nicht extra erwähnt.

> ich gehe auch nicht davon aus, dass
> seine alte Windows-Version da tatsächlich eine Rolle spielt.

Ja. Ich auch nicht.
Aber ich würde mich auch nicht wundern, wenn es denn so wäre.
Es gibt überhaupt keinen Grund Windows 8 zu verwenden und dann hier die 
Leute mit Problemen zu belästigen.

Rust funktioniert auf Windows 10 und 11 tadellos und ist trivial 
installierbar.

von Cyblord -. (cyblord)


Lesenswert?

MaWin schrieb:
> Aber ich würde mich auch nicht wundern, wenn es denn so wäre.
> Es gibt überhaupt keinen Grund Windows 8 zu verwenden und dann hier die
> Leute mit Problemen zu belästigen.
>
> Rust funktioniert auf Windows 10 und 11 tadellos und ist trivial
> installierbar.

Also ich sehe starke parallelen in der Argumentation und im 
Sozialverhalten zwischen Rust-Anhängern und Linux-Anhängern. Frappierend 
möchte man sagen.

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


Lesenswert?

Cyblord -. schrieb:
> Also ich sehe starke parallelen in der Argumentation und im
> Sozialverhalten zwischen Rust-Anhängern und Linux-Anhängern.

Wegen eines Einzigen?

von rbx (Gast)


Lesenswert?

Ich denke mal, in Linux lässt sich Rust viel unproblematischer und 
schneller installieren.
Theoretisch bräuchte man in die Konsole nur schreiben rustc

Die Automagie geht soweit, dass die sich dann praktisch um den Rest 
kümmert, hinsichtlich der notwendigen Installation.

Ähnlich schnell und unproblematisch kann man die OpenWatcom Sachen auf 
Windows installieren.
Sowas würde man sich auch für Rust wünschen - wenn das denn so eine 
tolle C-Ablösung sein soll.

von MaWin (Gast)


Lesenswert?

rbx schrieb:
> Sowas würde man sich auch für Rust wünschen

Es nennt sich rustup-init.exe.

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


Lesenswert?

Cyblord -. schrieb:
> Du scheinst halt in alten Mustern festzuhängen.

Mit deiner Einstellung darfst du allerdings auch nie Python+pip benutzen 
(womit virtual environments ebenfalls tabu sein dürften), erst recht 
nicht Platform.IO.

von Cppbert (Gast)


Lesenswert?

rbx schrieb:
> Ich denke mal, in Linux lässt sich Rust viel unproblematischer und
> schneller installieren.
> Theoretisch bräuchte man in die Konsole nur schreiben rustc

Ich habe unter Linux und Windows in ca. 70sek installiert, sehr auch 
irgendwas 8.1 nicht mehr Supporter sein soll

rbx schrieb:
> Ähnlich schnell und unproblematisch kann man die OpenWatcom Sachen auf
> Windows installieren.
> Sowas würde man sich auch für Rust wünschen - wenn das denn so eine
> tolle C-Ablösung sein soll.

Für OpenWatcom brauch ich ca. 30sek

Ist aber alles relativ bis absolut egal weil man 99% der Zeit Code 
schreibt und nicht aus Langeweile staendig Compiler installiert

von Cppbert (Gast)


Lesenswert?

Cppbert schrieb:
> sehr auch irgendwas 8.1 nicht mehr Supporter sein soll

Sehe auch nirgends das 8.1 nicht supportet sein soll

von MaWin (Gast)


Lesenswert?

Cppbert schrieb:
> Sehe auch nirgends das 8.1 nicht supportet sein soll

Google immer noch kaputt?

https://doc.rust-lang.org/nightly/rustc/platform-support.html

> 64-bit MSVC (Windows 7+) 2

> 2  Only Windows 10 currently undergoes automated testing.
>    Earlier versions of Windows rely on testing and support
>    from the community.

von S. R. (svenska)


Lesenswert?

Jörg W. schrieb:
> Naja, ehrlich, wer will sich heutzutage noch mit dem
> abscheulichen "real mode" eine 8086 herumschlagen?

Ich, aber ich mache auch 8080/Z80.
Da nehme ich natürlich kein Rust für.

> Ansonsten kann ich mir nicht vorstellen, dass das soooo
> Windows-untauglich ist, [...]

Naja, Firefox hat die Unterstützung für Windows 9x/ME eingestellt, bevor 
sie Rust integriert haben... und selbst wenn da Rust-Code drin ist, dann 
muss der noch lange nicht nennenswert mit der WinAPI zusammenarbeiten.

Vollwertige Anwendungen in einer Sprache schreiben ist nochmal was 
anderes als Bibliotheken.

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> und selbst wenn da Rust-Code drin ist, dann
> muss der noch lange nicht nennenswert mit der WinAPI zusammenarbeiten.

Das hat ja auch niemand behauptet.

Es geht hier um Rust und alles im Rust-Lieferumfang. Nicht um Firefox.

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


Lesenswert?

MaWin schrieb:
> Only Windows 10 currently undergoes automated testing.

Keine automatischen Tests bedeutet aber noch lange nicht, dass es 
deshalb gleich nicht mehr funktionieren soll.

Python hatte wohl kürzlich bei ihren Binärversionen Support für Windows 
7 eingestellt (d.h. es lässt sich da auch wirklich nicht mehr 
installieren), aber 8.1 ist selbst bei denen noch in der Tüte.

von rbx (Gast)


Lesenswert?

MaWin schrieb:
> Es geht hier um Rust und alles im Rust-Lieferumfang

Leicht daneben, es geht um die Zukunft von Rust, und Daniel ist nicht 
der einzige, der in diese Richtung fragt.
Und wenn man Zukunftsfragen stellt, dann ist es nicht verkehrt, in die 
Vergangenheit zu schauen, oder nach ähnlichen Fällen.

Unabhängig davon:
FreeDOS Project: Then and Now [Kielux 2017]
- https://www.youtube.com/watch?v=w6NswAAKmbU
42 Minuten

Bryan Lunduke war sich nicht zu schade, ein Interview mit Jim Hall zu 
machen.
(Auf der Suche nach Antworten, warum Linux so schwach verbreitet ist, 
warum Linux so Spielunfreundlich ist usw. usw.)

highlights from linux sucks 2022 by bryan lunduke

https://www.youtube.com/watch?v=MRKtybzB3ig
3:35

https://reactos.org/forum/viewtopic.php?t=18215
----------------------

Man sollte schon festhalten, dass die Rustanhänger ein wenig ein auf 
Woke machen, andere Meinungen dissen, und dass das neu ist. Das 
Gegenseitige runtermachen ist nicht neu, das ist flamewar, es ist eher 
die beobachtbare kognitive Dissonanz bei den Rust-Freunden.

Und wenn man die FP analog als Steinzeit betrachtet, dann ist Haskell 
darin Ägypten.
Der bewährte Weg ist vom Bekannten zum Unbekannten. An vielen Stellen 
gesehen.
Aber von Lisp kennt man auch: Dialektmanie, viel schlimmer noch als 
Basic. Praktisch jeden Freitag ein neuer Lisp Dialekt.

Das war bei C immer weniger schlimm. Noch dazu gibt es didaktisch krasse 
Bücher, wie das vom Erlenkötter. So ganz unscheinbar wird einem die 
Programmierung einer Game-Engine beigebracht..
Bei K+R lernt man gleich am Anfang, wie man Verschlüsselungen knackt, 
sowas fanden viele spannend.

von MaWin (Gast)


Lesenswert?

Jörg W. schrieb:
> Keine automatischen Tests bedeutet aber noch lange nicht, dass es
> deshalb gleich nicht mehr funktionieren soll.

Was ja auch niemand behauptet hat.

rbx schrieb:
> FreeDOS Project

Bitte on-topic bleiben. Danke.

> Man sollte schon festhalten, dass die Rustanhänger ein wenig ein auf
> Woke machen

Ja. Genau.

> Steinzeit

Ja.

> Ägypten

Genau das.

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


Lesenswert?

rbx schrieb:
> die Rustanhänger

Soso. Wie viele kennst du denn so, dass du für "die Rustanhänger" 
sprechen kannst?

von Yalu X. (yalu) (Moderator)


Lesenswert?

Jörg W. schrieb:
> rbx schrieb:
>> die Rustanhänger
>
> Soso. Wie viele kennst du denn so, dass du für "die Rustanhänger"
> sprechen kannst?

Mindestens einen davon kennt jeder, der diesen Thread liest. Was wäre,
mal rein hypothetisch betrachtet, wenn dieser eine repräsentativ für die
meisten anderen in seiner Gilde wäre? ;-)

SCNR

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


Lesenswert?

Yalu X. schrieb:
> Mindestens einen davon kennt jeder, der diesen Thread liest.

Naja, genau genommen, kenne ich allein aus dem Thread bereits zwei. Nur 
einer davon tritt, nennen wir es mal, derart "offensiv" auf.

Da ich aber privat noch weiter Leute kenne, die das gern nutzen, trau' 
ich mir durchaus die Aussage zu, dass man von diesem einen allein 
keineswegs auf alle schließen kann.

von rbx (Gast)


Lesenswert?

Jörg W. schrieb:
> dass man von diesem einen allein
> keineswegs auf alle schließen kann.

Mache ich auch nicht. Auffällig waren die Kommentare in einem 
reddit-thread (s.o.).
Und in dem ungekürzten Bryan Lunduke Video wird auch ein kleiner Witz 
über Rust Programmierer gemacht - in dem Comic-Bild in der 3 Min 
Zusammenfassung bei 2:38 zu sehen. Was er weiter meint, ist sowas wie: 
jetzt sind wir endlich Perl losgeworden..
Das kommt ja auch nicht von ungefähr, und so "riecht" man schon so ein 
wenig Sektenhaftigkeit, Gleichschaltung, VT-Zuschreibung usw.

von Cppbert (Gast)


Lesenswert?

Es ist völlig unrelevant für die Qualitäten einer Sprache oder 
Betriebsystem wie sich dessen subjektiv wahrgenommene Community verhält, 
kein erfahrener Entwickler lässt sich davon in irgendeiner Form 
beeinflussen

Jede Community hat ihre gemäßigten, toxischen, fanatischen und Prediger, 
aber Einzelpersonen sind ohne Projekt oder Team dahinter unrelevant, sie 
sprechen nie für eine Gruppe sondern immer nur für sich selbst und das 
ist ok, erst wenn sich Leute öffentlich treffen und gemeinsam diese 
subjektiv erfahrenen Werte teilen wird es schwierig und so leid es mir 
tut habe ich solche Konflikte nie erlebt wenn ich auf C/C++, 
Linux,Windows oder sonstige Veranstaltungen war kein Evangelismus, keine 
Abgrenzung, offene Gespräche und immer nur viel Interesse

Die Welt ist voll mit Menschen die Neuerungen ausprobieren wollen, egal 
zu welchem Zweck und den Konservativen die denken das nur aus Stillstand 
und Reife etwas besseres entstehen kann, beides braucht man

Es ist nur eine Sache die deutlich zu erkennen ist, es gibt wenige 
professionelle, also hauptberufliche Entwickler mit breiter Erfahrung 
die sich an solchen Diskussionen aktiv beteiligen, der Anteil an Hobby 
Entwicklern die das nur als Zeitvertreib machen ist viel höher und 
leider kann dieser Teil der Entwicklergemeinschaft nur recht wenig 
objektives Beitragen weil sie die Welt nur aus einem sehr 
eingeschränkten Blickwinkel sehen, oder eben der andere Teil an 
Entwicklern die in ihrem Bereich recht professionell sind aber leider 
trotzdem nicht verstehen das die guten Konzepte aus ihrer Welt nur 
beschränkt in der Systemwelt greifen können oder der harte Kern der 
einfach nur Technikgeschschwafel betreiben will, dem jedes Argument 
irgendwie recht ist und den es oft an Objektivität, Weitblick und 
Erfahrung fehlt

Mir persönlich ist es völlig egal wie MaWin und andere hier (manchmal) 
auftreten, ich filtere die für mich relevanten Infos raus und gut ist 
und ein klein wenig missionieren hab ich mir nach so langer Zeit in der 
C/C++,C#,Python,....,Linux,Windows Entwicklung auch verdient ;)

Sollte es mal ein Forumstreffen geben wird MaWin sicherlich einen 
Vortrag über Rust halten und der grosse Rest hier wird ihm zuhören und 
dann vielleicht offen und freundlich diskutieren, aber niemals so 
eigenbrödlerisch wie das teilweise hier statt findet

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


Lesenswert?

Cppbert schrieb:
> ich filtere die für mich relevanten Infos raus

Das ist übrigens auch für mich der einzige Grund, mich hier zu 
beteiligen.

Ansonsten danke für deinen Beitrag!

von MaWin (Gast)


Lesenswert?

Ihr interpretiert da ganz einfach viel zu viel rein.

Was ich hier tue:
- Berichten, wenn es etwas aus meiner sich interessantes Neues zu 
berichten gibt.
- Berichtigen, wenn hier jemand Quatsch labert.

Ich sehe das Problem eher bei denjenigen, die ewig lange mit ja-doch 
"antworten", nachdem sie berichtigt wurden.

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.