Inhaltliche Wünsche zu einer Rust-Vorstellung

[esclear]

Hey, nachdem der @iblech das letzten Donnerstag ja mal „angeregt“ hat und durchaus Interesse zu bestehen scheint, denke ich tatsächlich darüber nach, Rust vorzustellen.

Als Termin würde ich ggf. das übernächste Treffen und ca. 30 - 45 Minuten Dauer ins Auge fassen.

Damit der Vortrag nicht zu langweilig wird, würde ich mich freuen, wenn Ihr hier einfach mal inhaltliche Wünsche / Themen die Euch interessieren reinschreibt.

Ich dachte bereits an:

• Typsystem
• Borrowing
• Lifetimes
• cargo, der Paketmanager
• Aufbau (LLVM, rustc, der rustc übersetzt)
• Cooles Zeug, das es schon gibt vorstellen (Servo, …)

[sternenseemann]

Wäre sicher eine gute Idee, das auch auf der ML zu fragen, da lesen vmtl. mehr mit…

[timjb]

Ich fände interessant:

• wie funktionieren Closures?
• welche Concurrency-Primitive stellt die Standardlibrary zur Verfügung und wie nutzen sie Borrowing / Lifetimes aus?

[iblech]

Finde ich super, dass du das machst! :-)

Ich würde gerne Beispiele für (in anderen Sprachen) häufige Programmierfehler sehen, die in Rust unmöglich werden. Solche gibt es ja wahrscheinlich wie Sand am Meer.

Zum Kontrast sind aber vielleicht auch Beispiele erhellend, die zeigen, was nötig ist, damit das Typsystem augenscheinlich korrekten Code akzeptiert: Ist das meist ganz einfach? Oder gibt es Situationen, wo man länger mit dem Typsystem kämpfen muss?

(Das würde ich Rust keinesfalls schlecht auslegen. Kein Typsystem ist perfekt. Es ist nicht trivial, eine Balance zwischen "das Typsystem findet Fehler", "das Typsystem akzeptiert korrekte Programme", "das Typsystem produziert verständliche Fehlermeldungen", "das Typsystem trifft seine Entscheidung rasch" und "das Typsystem erzieht mich zu einer guten Programmiererin mit einem scharfen Stilbewusstsein" zu finden.)

[Profpatsch]

Als Anmerkung: Es besteht von mehreren Seiten Interesse daran, einen regelmäßigen Rust-Stammtisch im OpenLab zu machen. Einfach mal auf der Mailingliste (alle@lists.openlab-augsburg.de) anstoßen.

[Profpatsch]

lol, ich bin wieder zu langsam gewesen: https://openlab-augsburg.de/2016/11/neu-rust-stammtisch-im-openlab/

[iblech]

Jup. Vielleicht könnte Daniels Vortrag sowas wie ein nulltes Treffen des Rust-Stammtischs sein! (In Analogie zum Vortrag über die Implementierung von Perl 6 in Haskell im Perl-Stammtisch, welchen man vielleicht als nulltes Treffen des Curry Clubs ansehen kann.)

Vielleicht aber auch nicht, wenn die Interessen der Rust-Fans sich zu sehr vom Curry Club unterscheiden.

[esclear]

Den Vortrag bis zum Donnerstag zu halten, ist unrealistisch :)

[esclear]

• Warum sind Rust-Executables so riesig?

[Profpatsch]

Warum sind Rust-Executables so riesig?

Was ist ein riesiges Executable? 4MB? Statisch oder dynamisch kompiliert?

[esclear]

631 kiB für ein einfaches "Hello World!":

fn main() {
    println!("Hello world!");
}

Das liegt unteranderem daran, dass standardmäßig Debug-Symbole enthalten sind, außerdem wird für Generics Monomorphization angewandt. Außerdem wird standardmäßig jemalloc für Speicherverwaltung mitgeliefert.

Im Allgemeinen sind die Executables auch dynamisch gelinked, aber eingebundene Crates werden "statisch" eingebunden.

[esclear]

Siehe auch die offizielle FAQ: https://www.rust-lang.org/en-US/faq.html#why-do-rust-programs-use-more-memory-than-c

[larsrh]

Zum Thema große Binaries :wink:

$ du -sh bin/isabellectl
46M     bin/isabellectl

[Profpatsch]

631 kiB für ein einfaches "Hello World!":

Ich denke viele verstehen einfach das Konzept von “konstantem Overhead” nicht. Das sind auch die Leute, die aus der Binary Size von Hello World mit Debugsymbolen Schlüsse ziehen … Jemand sollte da auch mal eine Korellation mit Menschen ziehen, die GC aus Prinzip ablehnen. Das wäre interessant.

[esclear]

@Profpatsch Ich empfinde das für die Verwendung auf Desktopsystemen im 21. Jahrhundert nicht als Problem, dennoch hört man diese Frage relativ oft, deswegen ist sie ja auch in den FAQ enthalten.

Wenn man mit Rust jedoch im Embedded-Bereich was machen möchte, beispielsweise Mikrocontroller programmieren, dann ist es denke ich schon sehr interessant, wie man die Größe der Binary verkleinern kann und weshalb sie überhaupt so groß ist.

[sternenseemann]

lol @Profpatsch ist mett