There's a lot of weird debate about whether Rust in the kernel is useful or not... in my experience, it's way more useful than I could've ever imagined!
I went from 1st render to a stable desktop that can run run games, browsers, etc. in about two days of work on my driver (!!!)
Zaznaczam, że nie widziałem kodu tego sterownika, ale czytając wątek na Nitterze nie sposób nie zauważyć fascynacji automatycznym zarządzaniem zasobami w Rust.
Zastanawiam się, czy migracja niskopoziomowych programistów C do Rusta nie rozpocznie mody na pisanie niezbyt wydajnego kodu.
To jest coś, z czym od lat próbuje walczyć Muratori, bo łatwość stososowania wzorca RAII w C++ spowodowała dokładnie ten sam problem. Alokacje pamięci są teraz wszędzie, prawie nikt nie zastanawia się nad tworzeniem np. stringów w pętlach.
To jest trochę paradoksalne, ale C poprzez swoją toporność w zarządzaniu zasobami skłaniało ludzi do stosowania wydajnych rozwiązań - prealokacji zasobów na samym starcie i zwalniania ich tak późno, jak tylko się dało.
Oczywiście da się to zrobić lepiej zarówno w C++, jak i w Rust. Ostatnio czytałem nawet artykuł, gdzie gość implementował raytracer minimalizując ilość alokacji - https://matklad.github.io/2022/10/06/hard-mode-rust.html
Problem polega na tym, że takie rozwiązanie w Rust wymaga ręcznego zarządzania czasem życia obiektów (referencje muszą mieć podany lifetime), a to potrafi być niesamowicie uciążliwe (znacznie bardziej niż w przypadku C++).
Nie chciałbym, żeby za parę lat Linus narzekał, że włączenie Rusta do kernela było błędem, bo spowolniło kod.
To rzeczywiście kapa.
W wielu bibliotekach C też istnieją potwory. Głównie, kiedy twórca udaje, że wie lepiej jak powinienem zarządzać zasobami. Potem wygląda to tak samo jak architektura zarządzania w C++/Rust, tylko muszę pamiętać, jakie w tym tygodniu wymyślił nazwy funkcji do dealokacji (jedna z popularnych bibliotek ma przynajmniej dwie nazwy). No i ukrywanie struktur za setterami/getterami.
Jak pamiętam to Linus narzekał zawsze od czasów 2.4/2.6. Mówił, że to przerośnięty bloat.
Czyli można powiedzieć, że w JS można łatwiej zarządzać pamięcią niż w Rust.
Zaznaczam, że nie widziałem kodu tego sterownika, ale czytając wątek na Nitterze nie sposób nie zauważyć fascynacji automatycznym zarządzaniem zasobami w Rust.
Zastanawiam się, czy migracja niskopoziomowych programistów C do Rusta nie rozpocznie mody na pisanie niezbyt wydajnego kodu.
To jest coś, z czym od lat próbuje walczyć Muratori, bo łatwość stososowania wzorca RAII w C++ spowodowała dokładnie ten sam problem. Alokacje pamięci są teraz wszędzie, prawie nikt nie zastanawia się nad tworzeniem np. stringów w pętlach.
To jest trochę paradoksalne, ale C poprzez swoją toporność w zarządzaniu zasobami skłaniało ludzi do stosowania wydajnych rozwiązań - prealokacji zasobów na samym starcie i zwalniania ich tak późno, jak tylko się dało.
Oczywiście da się to zrobić lepiej zarówno w C++, jak i w Rust. Ostatnio czytałem nawet artykuł, gdzie gość implementował raytracer minimalizując ilość alokacji - https://matklad.github.io/2022/10/06/hard-mode-rust.html
Problem polega na tym, że takie rozwiązanie w Rust wymaga ręcznego zarządzania czasem życia obiektów (referencje muszą mieć podany lifetime), a to potrafi być niesamowicie uciążliwe (znacznie bardziej niż w przypadku C++).
Nie chciałbym, żeby za parę lat Linus narzekał, że włączenie Rusta do kernela było błędem, bo spowolniło kod.
To rzeczywiście kapa. W wielu bibliotekach C też istnieją potwory. Głównie, kiedy twórca udaje, że wie lepiej jak powinienem zarządzać zasobami. Potem wygląda to tak samo jak architektura zarządzania w C++/Rust, tylko muszę pamiętać, jakie w tym tygodniu wymyślił nazwy funkcji do dealokacji (jedna z popularnych bibliotek ma przynajmniej dwie nazwy). No i ukrywanie struktur za setterami/getterami.
Jak pamiętam to Linus narzekał zawsze od czasów 2.4/2.6. Mówił, że to przerośnięty bloat.
Czyli można powiedzieć, że w JS można łatwiej zarządzać pamięcią niż w Rust.
Tu jest kawałek kodu: https://nitter.net/LinaAsahi/status/1583498896847667216#m
Tu jest wspólna prezentacja o sterowniku: https://www.youtube.com/watch?v=0XSJG5xGZfU&t=21330s
A tu jest radość: https://www.youtube.com/watch?v=X7cNeFtGM3k&t=35595s