Będąc użytkownikiem Rusta, widzę niekiedy wiadomości, jak to nowy projekt zaczyna używać tego języka czy nowy

Będąc użytkownikiem Rusta, widzę niekiedy wiadomości, jak to nowy projekt zaczyna używać tego języka czy nowy driver w kernelu jest na niego przepisywany.

Pod każdym znajduje się spora ilość komentarzy pozytywnych/neutralnych jak i pewna część negatywnych głównie pochodzących od użytkowników innych niskopoziomowych języków tj. C czy C++.

Oto niektóre powody szkalowania(często słusznego) języka:

• Toksyczna społeczność - głównie chodzi o RIR(Rewrite in Rust) - pisane często pod postami o programach nie napisanych w tym języku - głównie przez osoby nie programujące w Rust, tylko myślące że jest to złoty środek na wszystkie bolączki i błędy występujące w programach.
  

• Niebezpieczny system pakietów - chodzi głównie o to że można próbować ataku polegającego na podszyciu się pod crates.io i zmienić paczki na ich złośliwe wersje. Według mnie taki atak prawie niemożliwy do wykonania, bo np. Cargo.lock posiada w środku hashe paczek, co uniemożliwia użycie podrobionej wersji paczki.
  

• Używanie do wszystkiego obcych zależności - parser cli czy implementacja tls, według niektórych użytkowników powinno to być napisane ręcznie albo przez zrobione przez kopiuj/wklej bezpośrednio do repozytorium. Według mnie to właśnie jest niebezpieczne, bo kopiowanie coś takiego komplikuje proces budowania, wydłuża proces tworzenia aplikacji jak i zwiększa ryzyko błędów/wymusza ciągłą synchronizację(można to łatwo zrobić przy pomocy git submodule, którego jednak niezbyt lubię). Obce pakiety, używane przez setki innych projektów mają zwykle o wiele lepszą jakość, więcej funkcji i mniej błędów niż te ręcznie napisane.
  

• Problemy statycznego linkowania - jeśli jakaś zależność np. openssl, będzie miała błąd który będzie naprawiony w nowej wersji, to gdy jest ona dynamicznie linkowana trzeba tylko ją przekompilować a w przypadku rusta całą aplikację - głównie jest to podnoszone przez ludzi zarządzających dystrybucjami, bo wiąże się to ze zwiększonym wysiłkiem.
  

• Problemy z pamięcią to tzw. skill issue i dobrzy programiści nie robią ich prawie wcale/mnie się one nie zdarzają choć już kilka lat programuję w C/C++ - setki tysięcy programistów używają C/C++ i naturą ludzką jest popełnianie błędów a te języki pozwalają odstrzelić sobie stopę w najbardziej wymyślny sposób w zupełnie losowym momencie(problemy z pamięcią często objawiają się z opóźnieniem). Wymagają od użytkowników trzymania dużej ilości informacji o kodzie w swojej głowie, co oczywiście nie jest idealne i problemy ze zrozumieniem kodu/jego poprawną zmianą pojawiają się przy zmiany osoby używającej program czy po dłuższej przerwie od danego kawałka kodu. W przeciwieństwie do C i podobnych niskopoziomowych języków, kompilator Rust traktuje użytkowników z dystansem(można powiedzieć że jako debili - ale w pozytywnym tego słowa znaczeniu(jeśli oczywiście takie jest)) i wymusza określony styl i praktyki, no chyba że zmienimy to przez unsafe. Pozwala to zwykłym użytkownikom tworzyć szybko działające programy, bez bania się o wszędzie czychające problemy z pamięcią, jak i przychylniejszym okiem patrzyć na pull requesty, bo szansa na zepsucie kodu jest o wiele mniejsza. Z tego co zauważyłem to programiści C, często uważają się za pewną elitę, bo przecież nie każdy potrafi robić to co oni. Wystarczy zobaczyć https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=memory, by zauważyć że zbyt wiele programów rozwijanych przez bardzo wykwalifikowanych programistów ma problemy z pamięcią i że to raczej nie problem ich zbyt małych umiejętności. No a jeśli to problem zbyt małych umiejętności, to większość programistów powinna unikać jak ognia C skoro jest on przystosowany jedynie dla najbardziej zaawansowanych.
  

• Długa kompilacja i biorąca dużo zasobów systemowych - Rust z racji ilości koniecznej weryfikacji wszystkich parametrów, typów, lifetimów etc. bierze o wiele więcej zasobów systemowych i czasu niż c czy np. go, więc do kompilacji lepiej zaopatrzyć się w mocniejszy komputer
  

• Brak dostępności na wszystkich platformach gdzie C jest dostępny - C jest chyba najbardziej przenośnym językiem na świecie(w ilości kompilatorów na różne platformy sprzętowe), wiec trudno by z nim konkurować. Rust wspiera najbardziej popularne systemy bazujące na ARM, x86-64 i wielu innych architekturach wspieranych przez llvm, ale obecnie nie ma oficjalnego wsparcia dla alpha, hppa, ia64, m68k czy s390. Problemem dużym to nie jest bo dotyczy zapewne grubo mniej niż 1% wszystkich użytkowników i to tych, którzy pracują na antycznym/mniej popularnym sprzęcie.
  

• Jest o wiele trudniejszy niż C/C++ - składniowo na pewno na pierwszy rzut oka nie wygląda zachęcająco, jednak z doświadczenia muszę powiedzieć że programuje się w nim o wiele szybciej niż w powyższych językach, bo nie muszę polegać w wielu przypadkach na sobie, tylko na kompilatorze. C jest dość prosty pod względem składni, ale bardzo trudnym gdy chce się go poprawnie używać, głównie przez to że bezpośrednio operuje się na pamięci. C++ z wersji na wersji próbuje stać się językiem bezpiecznym, jednak ciągnie się za nim szereg funkcji ze starszych wersji i problemów, które po prostu nie mogą zostać naprawione bez gruntownej modyfikacji języka.
  

• Rust rozwiązuje tylko problemy z pamięcią a ich nie robię - cóż, jeśli nawet to prawda(w co szczerze wątpie, jeśli używasz C/C++) to przynosi on szereg przydatnych funkcji, tj. ograniczenie wyścigów o dane, ujednolicenie formatowanie kodu(rustfmt), oficjalny system budowania(cargo), wymuszanie obsługi wszystkich sytuacji w match (switch w C/C++), przyjazne komunikaty błędów - bardzo często z kodem który można zrobić kopiuj/wklej i naprawić problem.
  

Jak widać Rust nie jest złotym środkiem na wszystko ale wprowadza kilka niezłych usprawnień w stosunku do C/C++, jednak jak widać części ludzi nie jest tym przekonana. C/C++ jak widać po np. statystykach na githubie nigdzie się nie wybiera i ciągle miliony linii kodu będą w tych językach pisane, jednak z roku na rok, coraz większe grono języków zaczyna je podgryzać.

#programowanie

#rustlang

#rust