@testuser: było coś takiego - https://en.wikipedia.org/wiki/Toshiba_4S

Przecież Rust nie jest nawet stabilny sam w sobie, w sensie nie ma jeszcze stabilnego wydania

@osetnik: Co?

nie ma

Pokaż całość

@osetnik: No z tym, że nie ma stabilnego ABI to się zgodzę, ale ABI ma (bo musi).

Żadnego Rusta w kernelu nigdy nie będzie, póki co nie wymyślono niczego co mogłoby się do tego nadawać lepiej niż C

@slx2000: Przecież już są sterowniki dla Linucha napisane w Ruscie, przykładowo Asahi Linux ma cały GPU driverPokaż całość

jeden (słownie: 1) sterownik na 30 tysięcy...

@osetnik: patrząc, że Rust w kernelu to dalej dość świeża sprawa (2 lata, coś koło tego), a stworzony sterownik to dość niemała rzecz, to dalej uznałbym to za duży sukces. Nikt raczej nie będzie przepisywał istniejących sterowników na Rusta, bo zbytnio nie ma to sensu.

A wracając trochę do ABI - to to czego C bardzo potrzebuje obecnie to zerwania powiązania między CPokaż całość

Rust is not a good C replacement

@osetnik: przeanalizujmy punkty w tym artykule

C is the most portable programming

Pokaż całość

@aleksc: ale z czego się tutaj śmiać? To jest ogólnie bardzo dobry krok.

a te najbardziej niebezpieczne niemal zawsze bywają runtime

@sorek: No CVE się z Tobą niezbyt zgadza.

Mimo wszystko pomysł, by biurokraci i jakiś Biden, Kamala, Bush, Trump czy inny Tusk czy Kaczor dyktowali jakich technologii programowania mamy używać, jest tak niedorzeczny, że aż strach.

@khamoon: w przypadku infrastruktury rządowej? Przecież NSA (a to stamtąd wyszło to zalecenie) od dawna nie tylko dyktuje jakie rozwiązania *powinny* być stosowane, ale również jakie algorytmy muszą być stosowane w aplikacjach dla rządu USA, np. wymaganie używania AES, SHA-2/3, PBKDF2, nawetPokaż całość

@osetnik: nikt nie mówi o porzucaniu ABI, tylko o tym, by zerwać z tym, że kod w C definiuje ABI (bo tego nie robi i nigdy nie robił, a w obecnym stanie, gdzie jest do tego nadużywany, robi to badziewnie).

@osetnik: no zastanówmy się, język, który daje większą pewność developerom, zmniejsza ilość potrzebnych narzędzi (np. do SAST), pozwala na łatwiejsze wprowadzanie nowych programistów, pozwala na większe zaufanie co do typowania, zabezpiecza przed niektórymi typami błędów niejako z automatu. Nic dziwnego, że wolny rynek przemawia na jego korzyść.

@osetnik: Nie chińskie. Zamiast AES można użyć np. ChaCha20 (lub nawet lepiej XChaCha20), które zdecydowanie trudniej zaimplementować błędnie, a wydajnościowo będzie zazwyczaj porównywalnie (nie licząc implementacji w hardware). Podobnie zamiast SHA-2 lepiej użyć BLAKE2, które będzie zdecydowanie szybsze. Zamiast PBKDF2 mamy Bcrypt czy Argon2, które zapewniają zdecydowanie większe bezpieczeństwo przy mniejszych nakładach pracy. To nie jest nic nadzwyczajnego ani nie jest w żaden sposób kontrowersyjne.

@osetnik: pracy komputera. Dla programisty to jeden pies jest.

@slx2000: No Rust jest bezpieczniejszy niż C++, nie jest to duże osiągnięcie, ale jest przydatne mimo wszystko.

@osetnik: Linux, Apple, Microsoft, Mozilla, Discord, Dropbox, Amazon, Samsung i pewnie wiele innych pewnie wiele innych by się z Tobą nie zgodziło.

@slx2000: ISO C23 *nie może* tego ustandaryzować bo intmax_t. Jeśli by dodali 128-bitowe inty to złamią ABI i wiele rzeczy się posypie. ThePhD (edytor ISO C23) pisał o tym w ww. artykule. Nie ma znaczenia, że __int128 jest w GCC od 2010 roku, jak nie ma to stabilnego ABI (mówiłem już, że C nie ma stabilnego ABI?). Ale nawet wtedy, to nie zmienia faktu, że zarówno C jak iPokaż całość

większy runtime, większy koszt wykonania np. wyjątków

@slx2000: przecież panic w Ruście można łatwiutko ogarnąć by nie był bardziej kosztowny niż abort w C.

@slx2000: C nie definiuje ABI, w związku z czym nie ma on ABI, ale ludzie używają C jakby miało stabilne i zdefiniowane ABI, przez co będą "bardzo smutni" jeśli by się to zmieniło.

@slx2000: unsafe w Ruście nie wyłącza żadnych mechanizmów bezpieczeństwa Rusta. Jedyne co, to pozwala na dodatkowe rzeczy, które w "safe Rust" nie są dozwolone (i one mogą powodować problemy). Myk jest taki, że w przeciwieństwie do C i C++ musisz się mocniej skupić *tylko* na tych fragmentach, a nie na całym kodzie. W związku z czym review jest prostsze, a "blast radius" na to gdzie mogą być prowadzone poważne błędyPokaż całość

@Sikor12: No EU wprowadza nowe dyrektywy i zalecenia anti-SLAPP:

- https://eur-lex.europa.eu/eli/dir/2024/1069/oj
- https://www.euractiv.com/section/digital/news/eu-parliament-to-counter-lawsuits-designed-to-silence-journalists-ngos/
- https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022H0758&from=EN