News Open Source: Programmiersprache Rust emanzipiert sich von Mozilla

[foo_1337]

@andy_m4 dann lass doch lieber Hurd nehmen, steht das m4 in deinem nick für Mach4?

 

[andy_m4]

dann lass doch lieber Hurd nehmen

Stimmt. Auch wieder war. Vor allem, da es ja bereits nächstes Jahr raus kommt. :-)

steht das m4 in deinem nick für Mach4?

Nee. Das steht für m4 :-)
Das hab ich benutzt, bevor Du mit Deinem neumodischen Kram um die Ecke kamst, dem angeblich die Zukunft gehört. :-)

 

[foo_1337]

Nee. Das steht für m4 :-)

Yeah, sendmail.mc Das o'reilly sendmail Buch hab ich sogar noch irgendwo rumstehen.

bevor Du mit Deinem neumodischen Kram um die Ecke kamst, dem angeblich die Zukunft gehört. :-)

Ich bin selbst zu alt für den Mist. Wenn ich noch code schreibe, den kein anderer benutzen oder lesen muss, nehme ich nach wie vor perl

 

[ModellbahnerTT]

Dabei könnte der Linux-Kernel ein Rewrite gut gebrauchen. Da kann Torvalds auch endlich mal das Ding auf Mikrokernel umstellen und bei Tanenbaum Abbitte leisten. :-)

Wenn man das für Teile umsetzen mit rust wäre das schön aber die Umstellung auf Microkernel wird auch mit rust niemals kommen da zu komplex.

 

[andy_m4]

Ich bin selbst zu alt für den Mist.

Na super. Wein predigen aber Wasser trinken. Das sind mir die Richtigen. :-)

Wenn ich noch code schreibe, den kein anderer benutzen oder lesen muss, nehme ich nach wie vor perl

Perl macht aber nur dann Spaß, wenn es andere auch warten müssen. Nix geht über unkommentierten Perl-Code und exzessiven Ausnutzen aller Kniffe und leidenschaftlichem Praktizieren von Codegolf. :-)

aber die Umstellung auf Microkernel wird auch mit rust niemals kommen da zu komplex.

Ja. Am besten ist, man wirft den Kram einfach weg und beginnt neu. bzw. ganz neu braucht man gar nicht zu beginnen, weils ja schon Mirkokernel gibt auf die man aufsetzen kann. Inkl. den hier schon erwähnten und in Rust geschriebenen Redox-Kernel.

 

[TriggerThumb87]

-Komplettzitat entfernt-
Wie es richtig geht, ist hier nachzulesen.

Ironischerweise benutze ich C++ gerade wegen der gefährlichen Sachen, für Modding-Frameworks für Spiele/Detour-Bibliotheken.
Ich kenne da nicht die genauen Details in Rust, aber C++ ist gerade durch diese Gefährlichkeiten für sowas unerlässlich. Gut, natürlich eine Nischenanwendung. Mich würde mal interessieren ob das in Rust effizienter wäre oder nicht.
Ich bin allerdings froh, dass es performancemäßig eine sichere/bequemere Alternative zu C++ gibt.
Mir geht der Zug der meiner Meinung nach "Skriptsprachen" auf den Keks.

 

[andy_m4]

Ironischerweise benutze ich C++ gerade wegen der gefährlichen Sachen

Gefährliche Sachen sind ja auch nicht per se ein Problem. Dort wo es gefährlich sein muss, darf es ja ruhig auch gefährlich sein. Es ist halt nur ungünstig wenn Du für Problemstellungen "gefährliche Programmierung" benutzen musst, weils keine sicheren Alternativen gibt.
Wie gesagt. Da hat C++ ja auch schon einiges nachgeliefert. Rust legt da noch mal ne Schippe drauf.

Es ist halt per default sicher (so sicher wie es bei Programmierung eben sein kann). Du kannst also nicht versehentlich unsichere Konstrukte verwenden. Nichtsdestotrotz gibt es aber auch die Möglichkeit "dreckige" Programmierung zu machen. Dafür gibts unsafe-Sections. Da deklarierst Du halt ein Bereich als "unsafe" und kannst dann - platt gesagt - alle Schweinereien machen die Du in C oder auch C++ auch machen kannst.

Und das ist eigentlich ganz nett, weil Du halt per default im safe-mode bist und nur eben explizit und zielgenau die Stellen markieren kannst, wo Du dann deine gefährlichen Operationen brauchst.

Mich würde mal interessieren ob das in Rust effizienter wäre oder nicht.

Der Code den der Rustcompiler fabriziert und ungefähr so schnell wie der Code den C++-Compiler ausgeben.

Mir geht der Zug der meiner Meinung nach "Skriptsprachen" auf den Keks.

Zumal die "Skriptsprachen" nur das kopieren, was Du bei Lisp schon vor 40 Jahren hattest. Nur schlechter. :-)

 

[TriggerThumb87]

Okay, das klingt alles recht interessant.
Ich sollte meine Effizienzfrage vielleicht erweitern bzw. präzisieren.
Ich bezog mich damit nicht auf Performance, sondern um das Featureset bei meinen Projekten.

Was ich mit C++ machen kann:
-Klassen nachbilden (entweder direkt als Klassen oder als Strukturen mit Funktionszeigern - so erspare ich mir die komplette Rückentwicklung von Hierarchien)
-Inline Assembly

 

[KitKat::new()]

-Klassen nachbilden (entweder direkt als Klassen oder als Strukturen mit Funktionszeigern - so erspare ich mir die komplette Rückentwicklung von Hierarchien)
-Inline Assembly

Inwiefern geht das mit Rust nicht?

Klassen nachbilden:
https://doc.rust-lang.org/book/ch05-03-method-syntax.html

Inline Assembler:
https://doc.rust-lang.org/1.8.0/book/inline-assembly.html

 

[TriggerThumb87]

Die Frage für mich als Nichtkenner von Rust ist inwiefern ich die Datenstrukturen exakt nachbilden kann, dass sie im Speicher exakt gleich sind.
Gerade wenn ich zum Beispiel Klassen nachbilde und Instanzen erzeuge und einschleuse, muss ich schon innerhalb derselben Sprache darauf achten, dass ich dieselbe Struktur habe (VTables, Felder, etc.). Das ist nämlich zumindest bei C++ nichtmal ein Standard, sondern kompilerabhängig. Da sind die VTables gerne mal anders aufgebaut und anders arrangiert.

 

[ZuseZ3]

Inline Assembler hat sogar seine eigene Working-group, welche daran arbeitet die asm Nutzung zu vereinfachen.

Du hast mehrere Features mit welchen du bei Bedarf festlegen kannst, wie etwas im Speicher aussehen soll. https://doc.rust-lang.org/nomicon/other-reprs.html

Grundsätzlich bietet dir das Foreign Function Interface verschiedene Möglichkeiten mit C/C++ zu interagieren:
https://doc.rust-lang.org/nomicon/ffi.html

 

[ponchofiesta]

@ponchofiesta

Was meinst du damit, dass Rust frei ist von Abhängigkeiten?

Ich hab auf die statischen Builds angespielt. Rust erstellt immer statische Builds. Wenn man darauf achtet, kann man so auch immer frei von Abhängigkeiten sein. Es gibt auch GUI-Bibliotheken in Rust, sind aber noch nicht ausgereift. Das hat seine Vorteile... und Nachteile.

 

[Unnu]

Hab ich da Python gehört?

Kann sein. Allerdings war ich mir gar nicht bewußt, dass die Schlange so dermassen abgeht gerade.
Das ist im Moment die Nr.1 der genutzten Sprachen.
Kann also nicht schaden, wenn man sich davon ein wenig aneignet.

 

[calluna]

@Unnu

Ja... derzeit ist fast jedes Buch über Machine Learning in Python geschrieben und die Beispiele sind in Jupyter-Notebooks zusammengestellt - die perfekt für so etwas sind.

Es ist auch, finde ich, weniger die Sprache an sich, die überzeugt... es ist die Einstellung, die hinter "Zen of Python" steckt und es sind vor allem Pakete wie Pandas, Numpy, SciPy, Matplotlib... bis PyTorch und Keras / Tensorflow... und unzählige andere.
Perfekt für wissenschaftliche Anwendungen, erkundende Datenanalyse... und Prototypen.

Und Pakte für Python lassen sich auch in Rust entwickeln... um den Bogen zum Thema hier zu spannen.

 

[andy_m4]

Das ist im Moment die Nr.1 der genutzten Sprachen.

Sagt wer? Und komm jetzt nicht mit dem TIOBE-Index oder so ein Quatsch. :-)

 

[calluna]

@andy_m4

https://redmonk.com/sogrady/2020/07/27/language-rankings-6-20/

Und wie steht es damit? Popularity Rank nach Github Projekten im Verhältnis zum Popularity Rank auf Stackoverflow.

Da ist auch meine Lieblingssprache Haskell nicht so weit abgeschlagen. :-)

Klar... das sollte man alles nicht so ernst nehmen. ;-) Aber man kann auch einfach nach Jobangeboten in Deutschland und den USA z.B. für die Sprachen suchen.

 

[andy_m4]

Und wie steht es damit?

Wir können uns ja darauf einigen, das Python recht beliebt ist. :-)
Wobei man Beliebtheit auf stackoverflow.com nicht nicht zwangsläufig für erstrebenswert halten muss. :-)

Da ist auch meine Lieblingssprache Haskell nicht so weit abgeschlagen. :-)

Stimmt.
Die Sprachen, die ich so ganz gut finde, findet man gar nicht erst in diesem rechten, oberen Quadranten. Muss ich mir jetzt Sorgen machen? :-)

Aber man kann auch einfach nach Jobangeboten in Deutschland und den USA z.B. für die Sprachen suchen.

Genau. Einfach mal diese Ingrid fragen. :-)

 

[foo_1337]

Für meinen ersten Job damals habe ich explizit nach FreeBSD gesucht und mich nur auf solche Stellen beworben. Das hatte dann irgendwie automatisch Perl und C impliziert

 

[andy_m4]

Damals. Als FreeBSD noch 386BSD hieß. :-)

 

[foo_1337]

Nee, so lange bin ich nun auch nicht dabei FreeBSD 4.5 oder so müsste damals aktuell gewesen sein.