Recenzja języka programowania Rust: czy warto się go uczyć?

Zapytaj dwóch doświadczonych programistów Rust, czy nauka Rust była warta wysiłku, a możesz dostać zupełnie przeciwne odpowiedzi. Jeden może powiedzieć, że nic nie dała jego karierze; drugi może nazwać ją jedną z najlepszych technicznych decyzji, jakie podjął. Obaj mogą mieć rację.

W tej sprzeczności tkwi właściwie pytanie „czy warto uczyć się Rust” i właśnie dlatego ogólnikowe „tak” jest dla ciebie bezużyteczne. Rust to język kompilowany, którego bezpieczny podzbiór egzekwuje zasady bezpieczeństwa pamięci na etapie kompilacji, bez potrzeby używania garbage collectora w czasie działania.

Dlatego dam konkretną odpowiedź, wskażę warunek, od którego zależy, i pokażę ci, ile ten warunek kosztuje.

Krótka wersja

Rust warto poznać, jeśli budujesz coś długowiecznego, gdzie warto zapłacić za to, że kompilator wyłapuje całą klasę błędów. To zły wybór, jeśli w tym miesiącu musisz wypuścić aplikację CRUD, uczysz się programowania albo liczysz oferty pracy. 4 na 5, z potrąceniem za to, ile kosztuje, zanim się zwróci.

• Co kupujesz: w bezpiecznym Rust reguły ownership i borrowing zamieniają błędy use-after-free, double-free, nieprawidłowych referencji i wyścigów danych w błędy kompilacji zamiast incydentów na produkcji. To cała obietnica i to dobra.
• Co płacisz: kompilator każe ci zapisać decyzje dotyczące pamięci, które twój obecny język podejmuje po cichu, a na początku wygląda to tak, jakby narzędzie robiło ci na złość.
• Kwestia trwałości jest przesądzona. Opiekunowie jądra zakończyli eksperyment z Rust na Maintainers Summit w grudniu 2025, a etykieta „eksperymentalny” zniknęła w Linux 7.0.
• Kwestia mody nie jest przesądzona i to zupełnie inne pytanie. Rust zajmuje #10 w indeksie TIOBE z września 2026, w górę z #18 rok wcześniej.
• Mój testowy serwis w Rust potrzebował znacznie więcej pamięci do kompilacji niż do działania: przy budowaniu zużycie sięgało blisko 1 GB, a w spoczynku podczas działania wynosiło około 3,5 MB.
• Dla ciebie, jeśli już wypuszczasz kod w innym języku i budujesz coś, w czym błąd pamięci byłby kosztowny, albo pracujesz blisko oprogramowania systemowego. Nie dla ciebie, jeśli masz napięty termin, zaczynasz od zera albo szukasz języka z największą liczbą ofert pracy.

Jak powstała ta recenzja: liczby dotyczące budowania i działania pochodzą ode mnie. Zainstalowałem Rust 1.98.1, napisałem mały serwis webowy w Axum i zmierzyłem, ile kosztowała jego kompilacja, a ile uruchomienie. Działało to w odizolowanym kontenerze, nie na dedykowanym sprzęcie, i to jeden projekt, więc traktuj te liczby jako punkt danych, a nie prawo. Cała reszta pochodzi ze źródeł pierwotnych lub wiarygodnych: z łatki jądra i relacji LWN na jej temat, z wpisów Google o bezpieczeństwie Androida, z samego indeksu TIOBE (z kwietniowym komentarzem w wersji zapisanej przez Slashdot), z Phoronix o oknie scalania Linux 7.0, z rejestrów CVE jądra Linux dotyczących podatności w Binder, z oświadczenia samego Canonical i z ankiety Stack Overflow z 2025 roku. Przeczytałem łatkę jądra. Nie audytowałem kodu Rust w jądrze. I nie piszę w Rust od lat, więc tam, gdzie ta recenzja ocenia sam język, opiera się na praktykach, którzy to robią, i podaje ich z nazwy.

Co daje ci kompilator

Daj w Rust dwóm wątkom mutowalną referencję do tego samego wektora, a kod się nie skompiluje. Nie ostrzeżenie. Nie lint, który można wyciszyć, gdy goni termin. Po prostu się nie zbuduje. Ta odmowa to właśnie to, co kupujesz w bezpiecznym Rust: błędy use-after-free, double-free, nieprawidłowych referencji i wyścigów danych stają się błędami kompilacji zamiast incydentami na produkcji. Furtka awaryjna Rust (unsafe) może obejść część tych gwarancji, więc nie jest to absolutna obietnica dotycząca każdej bazy kodu w Rust.

Ownership oznacza, że każda wartość ma dokładnie jednego właściciela odpowiedzialnego za jej zwolnienie. Borrowing oznacza, że możesz pożyczać referencje, ale kompilator śledzi ich czas życia i nie pozwoli, by któraś przeżyła to, na co wskazuje, ani by mutowalne pożyczenie współistniało z jakimkolwiek innym. W bezpiecznym Rust błędy use-after-free, double-free, nieprawidłowych referencji i wyścigów danych są wyłapywane przez system ownership i typów, zanim program się uruchomi.

Nie ma garbage collectora i to druga połowa umowy. Ponieważ ownership już określa, kto zwalnia co i kiedy, nic nie musi przeglądać twojej sterty w czasie działania. Wypuszczasz binarkę bez żadnego collectora w środku i nie dostajesz pauz, pod które trzeba stroić aplikację.

Cena pojawia się w tym samym miejscu co gwarancja. Każdą decyzję o pamięci, którą twój obecny język po cichu podejmuje za ciebie, Rust każe ci zapisać: kto jest właścicielem tego, jak długo żyje ta referencja, czy cokolwiek innego ją widzi i czy przekracza granicę wątku. Kompilator nie robi ci na złość. Odmawia zgadywania.

A więc: to jest powód, dla którego ktokolwiek płaci cenę, jakiej żąda Rust, i moim zdaniem ten powód się broni. Jeśli klasa błędów, którą eliminuje, nie jest klasą, która cię martwi, reszta tej recenzji raczej nie zmieni twojego zdania.

Czy Rust jest wciąż eksperymentalny, czy to już infrastruktura produkcyjna?

Przestał być eksperymentalny w grudniu 2025, a zakończyli to sami opiekunowie jądra. Na Maintainers Summit 2025 uznali, że Rust zapracował na swoje miejsce w jądrze, technicznie i społecznie. Jonathan Corbet z LWN opisał ten konsensus 10 grudnia 2025: Rust w jądrze nie jest już eksperymentalny.

Rust trafił do głównej linii Linux w wersji v6.1 w 2022 właśnie po to, by przeprowadzić ten eksperyment. Łatka, w której Miguel Ojeda usunął etykietę, pojawiła się trzy dni po Summit i trafiła do okna scalania Linux 7.0.

„Ale eksperyment się zakończył, tzn. Rust zostaje na stałe.”

Miguel Ojeda, „rust: conclude the Rust experiment”, LKML, 13 grudnia 2025

Osobno, i wcześniej: przepisany przez Google w Rust sterownik Binder z Androida, czyli warstwa IPC, przez którą (nieustannie) komunikują się procesy Androida, trafił do Linux 6.18, wydanego 30 listopada 2025. Oddziel ten kamień milowy od konsensusu z Summit. To moment, w którym firma postawiła wypuszczany produkt na Rust w jądrze, a nie grupa opiekunów błogosławiąca pomysł. Rust w jądrze doczekał się od tamtej pory pierwszego CVE: CVE-2025-68260, wyścig (race condition) w tym samym sterowniku Binder, o którym 16 grudnia 2025 poinformował Greg Kroah-Hartman, wprowadzony w 6.18 i naprawiony w 6.18.1. Pierwsze doniesienia skupiały się na awariach, ale późniejsza ocena zespołu CVE jądra Linux wycenia CVE-2025-68260 na 7,8 (High) i opisuje lokalną ścieżkę eskalacji uprawnień przez uszkodzenie pamięci jądra. Ten sam sterownik (rust_binder) od tamtej pory zebrał też kolejne CVE.

To w Androidzie dowody nabierają liczbowego wymiaru. Blog bezpieczeństwa Google stwierdził w grudniu 2022, że w kodzie Rust w Androidzie wykryto zero podatności związanych z bezpieczeństwem pamięci przy około 1,5 mln linii Rust w AOSP i około 21% całego nowego kodu natywnego w Androidzie 13. To stwierdzenie z 2022 roku o zakresie z 2022 roku. Późniejsze wpisy Google pokazują dłuższy trend: problemy z bezpieczeństwem pamięci odpowiadały za 76% podatności Androida w 2019 i 24% w 2024, a ich bezwzględna liczba spadła z ponad 220 do prognozowanych 36. Te liczby mają sens tylko w odniesieniu do punktu wyjścia, który zastąpiły, czyli C i C++ pisanego przez bardzo dobrych inżynierów z bardzo dobrymi narzędziami.

Dwa mniejsze sygnały wskazują w tym samym kierunku. Sterownik GPU Apple AGX w Asahi Linux jest napisany w Rust, i to przez projekt Asahi Linux w ramach inżynierii wstecznej, a nie przez Apple. Aktualizacja Canonical dotycząca rust-coreutils mówi, że Ubuntu 26.04 LTS dostarcza rust-coreutils 0.8.0 dla większości narzędzi. Trzy zostają przy GNU coreutils (cp, mv, rm), ponieważ 22 kwietnia 2026 osiem problemów TOCTOU wciąż było otwartych; Canonical celuje w 26.10 dla pozostałych narzędzi.

To oś, którą oceniłbym najwyżej, a powodem jest rodzaj zaangażowania. Opiekunowie jądra nie odwołują zakończonych eksperymentów, Google nie cofa przepisywania na taką skalę, a Canonical nie wkłada przepisanych coreutils do wydania LTS, żeby zobaczyć, co będzie. Cokolwiek stanie się z popularnością Rust, ktoś musi utrzymywać ten kod przez lata.

Czy Rust jest martwy, czy tylko się wypłaszcza?

Nie. Rust wyrównał swoją najlepszą w historii pozycję w TIOBE, #13, w styczniu 2026. Trzy miesiące później spadł z powrotem na #16, a CEO TIOBE Paul Jansen napisał w kwietniu 2026, w komentarzu cytowanym wtedy przez Slashdot, że wzrost popularności Rust „wydaje się wyhamowywać”, a miejsce w top 10 „wydaje się teraz odleglejsze niż wcześniej”.

Opisywał, jak Rust osiąga swoją najwyższą pozycję w historii w jego własnym indeksie, miejsce, które po raz pierwszy zajął w lipcu 2024, a potem ją oddaje.

Indeks TIOBE z września 2026 stawia Rust na #10, w górę z #18 rok wcześniej, i wyżej niż #13, które TIOBE w styczniu nazwało jego najwyższą pozycją w historii.

Moja interpretacja: plateau było prawdziwe. Była to dziura powietrzna, a nie sufit. To lepsze niż wersja każdego z obozów, bo „Rust utknął” jest teraz nieprawdą, a „Rust idzie tylko w górę” nigdy nie było prawdą.

To zastrzeżenie działa w obie strony, a tekst Slashdot poruszył je już wtedy: czy rankingi po prostu nie wahają się wraz z comiesięcznym szumem w wynikach wyszukiwarek, bo to właśnie liczy indeks? Jeśli spadek o trzy pozycje w kwartał był słabym dowodem na to, że Rust zwalnia, to wzrost o sześć pozycji jest słabym dowodem na to, że wygrywa. Traktuj to jak pogodę, a nie klimat.

Mocniejszym sygnałem nastrojów jest ankieta Stack Overflow, w której Rust po raz kolejny jest najbardziej cenionym językiem programowania w 2025 z wynikiem 72%: to ludzie, którzy używali go w ostatnim roku i chcą używać dalej. To zamiar dalszego używania, a nie adopcja, i tutaj jest to bardziej przydatny sygnał niż sama popularność, jeśli zastanawiasz się, czy będzie ci się dobrze pracować z tym językiem na dłuższą metę.

Dynamika jest niejednoznaczna i waży dla mnie mniej niż opisana wyżej trwałość, bo nie inwestujesz w ranking.

Ile kosztuje cię nauka Rust

Koszt pojawia się wcześnie i od razu w całości. Kod, który Python, Java czy C# chętnie by uruchomiły, jest raz za razem odrzucany z powodów, które wydają się arbitralne, dopóki model ownership nie zaskoczy, i nie da się tego odłożyć. Nie prześlizgniesz się obok borrow checkera, po prostu wypuszczając kod, tak jak możesz prześlizgnąć się obok niepełnego rozumienia swojego ORM.

Oto część, która mnie zaskoczyła, i działa odwrotnie, niż można by się spodziewać. W wątku „Struggling to learn Rust” na r/rust odpowiedź, która zebrała największy odzew, przedstawia problem jako brak oswojenia, a nie trudność, a wątek wskazuje doświadczonych programistów przychodzących z języków z garbage collectorem jako tych, którym idzie trudniej. u/Voxelman ujmuje to wprost: „Rust nie jest trudny. Jest inny.” W tym samym wątku ta osoba opisuje własną drogę: C64 Basic, potem szereg języków imperatywnych i pierwszy kontakt z Rust, który „był wszystkim, tylko nie WOW”, bo pozbycie się starych nawyków trochę trwało.

Tak wygląda rachunek. Jeśli od ośmiu lat piszesz w Pythonie, nie uczysz się zestawu reguł, tylko porzucasz zestaw założeń o tym, kto po tobie sprząta. Ktoś, kto wie mniej, ma mniej do oduczenia się.

W tym wątku wielokrotnie pojawia się jeszcze jeden wzorzec, który zamienia błąd kolejności w problem z pewnością siebie: ludzie utykają nie na Rust, lecz na wyborze frameworka webowego, próbując uczyć się języka przez Axum czy Actix, zanim ownership na dobre się uleży. Jak ujął to u/jmartin2683, to „jak próba nauki Ruby przez naukę Rails.”

Większość ostrzeżeń o koszcie odczytuję jako wskazujące na niewłaściwą rzecz. Zaplanuj systematyczną praktykę, nie weekend, i nie traktuj wczesnej frustracji jako werdyktu o swoich umiejętnościach.

Rust potrzebuje większej maszyny do budowania niż do działania

Oto wynik, którego się nie spodziewałem: zbudowanie tego projektu w Rust zajęło o rzędy wielkości więcej pamięci niż jego uruchomienie. Zbudowałem mały serwis w Axum (Tokio z zestawem funkcji full oraz serde, serde_json, tower, jedna trasa JSON, około 60 crate'ów w drzewie zależności) na rustc i cargo 1.98.1, z strip = true w profilu release, a potem dwukrotnie zbudowałem go od zera:

# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --release

Przy ograniczeniu do jednego zadania kompilacji (--jobs 1) szczytowe zużycie pamięci przez cargo, rustc i linker wyniosło od 464 MB do 527 MB, zależnie od tego, którą z moich dwóch metod pomiaru przyjąć (mierzyłem na dwa sposoby, bo pierwsza liczba wyglądała zbyt ładnie), a całość trwała 113 sekund. Przy domyślnej równoległości na czterech vCPU szczytowe zużycie pamięci mniej więcej się podwoiło, do około 1 GB, a build skończył się po około 35 sekundach. Zmienną jest tu równoległość, nie projekt. Więcej zadań oznacza więcej procesów rustc jednocześnie w pamięci, dlatego kompilatory są jednym z niewielu obciążeń, które chętnie zajmą każdy rdzeń, jaki im dasz i to na całe minuty.

Gotowy program po strip ma 1,3 MB i w spoczynku zajmuje około 3,3 do 3,6 MB pamięci.

Przy domyślnej równoległości to od dwustu do trzystu razy więcej pamięci na kompilację niż na działanie; przy ograniczeniu do jednego zadania wciąż ponad sto razy więcej. Jeśli dobierzesz serwer do tego, czego twój serwis w Rust potrzebuje na produkcji, możesz skończyć z maszyną, która nie da rady go zbudować, a awaria nie kończy się czytelnym błędem: to OOM killer ubijający rustc w połowie builda albo kompilator mielący swap przez dwadzieścia minut. Działają dwa rozwiązania. Buduj tam, gdzie jest zapas, i wysyłaj gotową binarkę, według tego samego wzorca co utrzymywanie osobnej maszyny do buildów przy ciężkiej pracy z Dockerem. Albo buduj na tej maszynie i daj jej miejsce: dla serwisu tego typu kilka gigabajtów RAM i dwa vCPU wystarczą z zapasem. Gdy to niemożliwe, furtką awaryjną jest --jobs 1 (tak, jest wolniej; taka jest cena).

Jeśli maszyna, na której pracujesz, nie ma takiego zapasu, nasz samodzielnie zarządzany Linux VPS daje ci dostęp root z rozliczeniem godzinowym lub miesięcznym i miejsce, w którym możesz zrobić build i które oddasz, gdy skończysz, choć to wciąż serwer, którym zarządzasz sam, a nie taki, który zarządza się sam.

Jeden projekt, jeden kształt, jedna maszyna. Maszyną był współdzielony, odizolowany kontener, a nie dedykowany serwer, z około 2 GB dostępnej pamięci, więc szczyt bez ograniczeń był bliżej swojego sufitu, niż byłby na większej maszynie. To nie są uniwersalne stałe: jeśli twoje drzewo zależności jest cztery razy większe albo twój profil release włącza link-time optimization, spodziewaj się innych liczb. Większe drzewa zależności, link-time optimization i kod intensywnie korzystający z generyków mogą podnieść zużycie pamięci przy budowaniu, więc nie traktuj moich pomiarów jako uniwersalnego sufitu.

Zaliczyłbym to do tego, jak pracujesz, a nie do tego, czy uczysz się języka. Dowiedz się o tym, zanim się na to natkniesz.

Kto powinien uczyć się Rust

Trzy sytuacje, w których poradziłbym ci poświęcić ten czas: długowieczne oprogramowanie, w którym błąd pamięci jest kosztowny, praca blisko systemu operacyjnego i chęć zyskania tego, co walka z kompilatorem robi z twoim myśleniem o pamięci. W każdej z nich jest powód, dla którego ten czas się zwraca.

Już wypuszczasz kod w innym języku i budujesz coś długowiecznego, w czym błąd pamięci byłby kosztowny. Serwis, który musi działać bez przerw. Biblioteka, od której zależą inne zespoły. Wszystko, w czym use-after-free oznacza analizę incydentu, a nie stack trace w twoim terminalu. To dokładnie ten przypadek, dla którego zbudowano całą gwarancję, a to, co płacisz na starcie, amortyzuje się przez cały okres życia tego, co budujesz.

Pracujesz blisko oprogramowania systemowego albo w nim. Sterowniki, praca z urządzeniami, narzędzia systemu bazowego, embedded, wszystko, co działa pod systemem operacyjnym, a nie na nim. Branża zaangażowała się tu tak, jak nigdzie indziej, a dowody na bezpieczeństwo pamięci są tu najmocniejsze.

Chcesz efektu ubocznego. Dwóch komentujących w tym wątku na r/rust zupełnie nie zgadza się co do wartości Rust dla kariery, a mimo to w tej kwestii dochodzą do tego samego. u/tyler_church, który twierdzi, że nie miało to żadnego wpływu na jego karierę, przyznaje jednak „być może subtelne wpływy na to, jak piszę inne programy w innych językach”. u/SirKastic23, od dwóch lat opłacany za pisanie w Rust, mówi, że poszerzyło to jego umiejętności programistyczne w sposób, którego się nie spodziewał. Dwie osoby, a nie badanie, ale to zysk, który zostaje, nawet jeśli nigdy nie będziesz pisać w Rust zawodowo: zmiana w sposobie myślenia, a nie linijka w CV.

Kto nie powinien uczyć się Rust

Trzy sytuacje, w których lepiej poświęcić ten czas na coś innego: masz termin w tym miesiącu, dopiero uczysz się programować albo wybierasz język według liczby ofert pracy, w których się pojawia. O tę trzecią ludzie pytają najczęściej.

Masz w tym miesiącu termin na aplikację CRUD albo prototyp. Rust przychodzi w dokładnie złym tempie dla pracy, która ma istnieć do piątku. Go to oczywisty wybór zamiast niego, jeśli chcesz języka kompilowanego z szybkimi buildami i zarządzaniem pamięcią przez garbage collector, a nie potrzebujesz gwarancji Rust opartych na ownership.

Dopiero uczysz się programować. Ta kwestia naprawdę dzieli ludzi, którzy zawodowo piszą w Rust, a spór w wątkach na r/rust toczy się w obie strony, więc moje stanowisko jest takie: wręczenie początkującemu rzutu monetą to zła rada, niezależnie od tego, na którą stronę moneta spadnie. Najpierw naucz się, jak działa maszyna, gdzieś, gdzie jest więcej wyrozumiałości, a potem wróć i pozwól kompilatorowi to dokręcić.

Wybierasz język według liczby ofert pracy, w których się pojawia. Nie podam tu liczby, bo nie znalazłem danych o zarobkach ani liczbie ofert dla Rust, które prowadziłyby do źródła, którego bym bronił. To, co u/crusoe opisuje w tym wątku na r/rust, to rynek z mniejszą liczbą bardziej wyspecjalizowanych stanowisk. To jeden komentujący w jednym wątku, a nie dane z rynku pracy, więc nie robiłbym z tego tezy, że pracy w Rust jest ogólnie mało. Jeśli liczba ofert jest dla ciebie decydująca, sprawdź aktualne ogłoszenia na swoim rynku docelowym, zanim wybierzesz język.

Często zadawane pytania