Język programowania Rust zdobywa coraz więcej uwagi jako opcja warta wykorzystania. Jego możliwości w zakresie bezpieczeństwa pamięci są fascynujące, ale jak to często bywa, spożytkowanie ich może być trudniejsze niż się wydaje. Chociaż Rust stanowi interesującą opcję językową, istnieje co najmniej pięć znaczących przeszkód, które utrudniają jego adopcję w systemach wbudowanych. Przyjrzyjmy się kilku z nich.
Przeszkoda #1 — wsparcie komercyjne
Współczesne zespoły zajmujące się tworzeniem produktów wbudowanych zazwyczaj korzystają z komercyjnych narzędzi wsparcia, aby przyspieszyć rozwój oprogramowania. Na przykład producent mikrokontrolera przeważnie dostarcza sterowniki niskiego poziomu, systemy plików, systemy operacyjne czasu rzeczywistego (RTOS), narzędzia konfiguracyjne i wiele innych. To pomaga podkręcić tempo rozwoju, ponieważ większość pracy na niższym poziomie sprzętu została już wykonana. Do tej pory tylko nieliczni producenci mikrokontrolerów wspierają Rusta. Nadal dla klientów oferują oni wsparcie głównie dla języka C. Wszystko, co wykracza poza to, trzeba zrobić samodzielnie.
Istnieją narzędzia, takie jak svd2rust, które programiści mogą zużytkować do konwersji plików SVD, które opisują peryferia mikrokontrolera, na tzw. peripheral crate. Instrument ten potrafi dosyć dobrze wygenerować taką: „skrzynkę”, którą programista może wykorzystać. Niestety, może wiązać się to z potencjalnymi problemami, takimi jak:
* Znaczne różnice w jakości w zależności od producenta;
* Rozwlekły i złożony kod generowany przez automatyczne narzędzie;
* Brak komunikatów o błędach, co może skutkować dłuższym czasem debugowania;
* Brak możliwości konfiguracji — instrument stosuje takie samo podejście do każdej paczki;
* Wykorzystanie generyków i metaprogramowania może prowadzić do wydłużenia czasu kompilacji.
Jeśli producent nie dostarcza pakietów wsparcia, to samemu trzeba rozwiązać wszystkie te niedogodności. Choć może to być ekscytujące i przynieść wiele cennych doświadczeń, może negatywnie wpłynąć na harmonogram i budżet projektu.
Przeszkoda #2 — koszty szkoleń
Rust nie jest językiem łatwym do nauki. Chociaż dzieli wspólne idee i koncepcje z wieloma innymi, w tym z C, krzywa uczenia się jest bardziej stroma. Gdy firma rozważa wprowadzenie nowego języka, musi zatrudnić inżynierów, którzy już znają tę technologię lub przeszkolić swój zespół. Grupy zainteresowane wykorzystaniem Rusta na platformach wbudowanych znajdą się w małej i niszowej społeczności. W tejże jest niewielu wykwalifikowanych inżynierów oprogramowania wbudowanego, którzy znają Rusta. Oznacza to, że konieczne może być płacenie więcej za tych nielicznych programistów, którzy są z nim zaznajomieni lub inwestowanie w szkolenie istniejącego zespołu. Tak czy inaczej, przekłada się to na zwiększenie wydatków.
Szkolenie zespołu do nauki Rusta to dobry pomysł. Każda firma i programista powinien stale inwestować w siebie. Ta branża ewoluuje tak szybko, że jeśli się tego nie robi, to zostaje się w tyle. Jednak przejście z jednego języka programowania na inny musi przynieść zwrot z inwestycji dla firmy. Zwłaszcza w przypadku przeskoku na język o nieco niższej dojrzałości pokroju Rusta. Rezultat musi zaowocować zwrotem z inwestycji, takim jak lepsze zabezpieczenia, stabilniejszy system itp. Zespół planujący wykorzystać Rusta powinien obiektywnie ocenić, czy jest to odpowiednia droga do podążania.
Szkolenie w tym przypadku nie ogranicza się do krótkiego 5-dniowego kursu. Nauka składni języka to jedno, ale nabycie w nim doświadczenia, unikanie rozmaitych pułapek i pisania wysokiej jakości, łatwego do utrzymania kodu, to zupełnie inna bajka. Tego nie da się ogarnąć w tydzień. W rzeczywistości nie można tego osiągnąć nawet w ciągu roku, choć w tym czasie uda się poczynić wydatne postępy. Dlatego początkowe koszty szkolenia mogą wydawać się niewielkie. Jednak całościowe obejmują opóźnienia w projektach, dodatkowe debugowanie i wolniejszy czas rozwoju, ponieważ zespół uczy się, jak odpowiednio stosować nowy język w swoich produktach. Nie oznacza to, że nie powinno się tego robić, ale trzeba to dokładnie ocenić i zdawać sobie sprawę, że to istotne i realne utrudnienie.
Przeszkoda #3 — konserwatywne podejście do przyjmowania nowych technologii
Jak łatwo zauważyć, nowe technologie są wdrażane w środowiskach rozwoju systemów wbudowanych bardzo powoli. Podczas projektowania produktów fizycznych w porównaniu z czystymi aplikacjami programowymi, wszelkie nowości wiążą się z ryzykiem skorelowanym z bezpieczeństwem, produkcją i właściwym działaniem układu. W przypadku software, skargi prowadzą do aktualizacji oprogramowania w ciągu 24 godzin. Jeśli pracujemy nad systemem w branży lotniczej, motoryzacyjnej lub nawet elektroniki użytkowej, niekoniecznie można mieć taką możliwość.
Firmy bazujące na produktach fizycznych często ponoszą większe ryzyko niepowodzenia. Właściciele i menedżerowie przedsiębiorstw zwykle są bardziej oporni na potencjalne niebezpieczeństwa i wybierają technologie, które są znane i sprawdzone. (Spójrzmy na branżę wynoszenia pojazdów kosmicznych. Jak długo rozwój tego sektora niemalże stał w miejscu z powodu obaw przed ryzykiem?). Istnieją także często pewne inwestycje w obecne technologie, przepływy pracy i pozyskanych pracowników (patrz wyżej). Koszt zmiany może być znaczący dla ugruntowanej firmy, a korzyści z tego wynikające są potencjalnie niewielkie. Jeśli decyzję podejmuje mała marka, rozpoczynająca swoją działalność, nie ma jeszcze tych początkowych inwestycji, więc przyjęcie nowszego rozwiązania, takiego jak Rust, może być w tym przypadku rozsądne, ponieważ i tak trzeba stworzyć swoją infrastrukturę technologiczną i opracować procesy.
Możliwość niepowodzenia nierzadko skłania firmy do korzystania z dostępnych technologii o niskim ryzyku, aby osiągnąć swoje cele biznesowe. Dlatego wiele przedsiębiorstw może spojrzeć na Rusta i zdecydować się na użycie C lub C++, ponieważ przyjęcie nowego rozwiązania, takiego jak Rust, nie daje żadnych rzeczywistych korzyści w porównaniu z tym, co jest już ugruntowane w branży. Nie powinniśmy tego mówić, ale doświadczona jednostka może zrobić to samo w C lub C++, co programista Rusta w tym języku, zachowując jednakie bezpieczeństwo (różnica jest jedynie wtedy, gdy nie mamy do czynienia z zaawansowanymi specjalistami w zakresie programowania).
Przeszkoda #4 — integracja zestawu narzędzi
Wielu programistów korzysta obecnie z systemów budowania, przepływów pracy i narzędzi, które używają zintegrowanego sposobu wytwarzania oprogramowania wbudowanego. Zastosowanie Rusta wymusi na tych jednostkach ponowne przemyślenie i przerobienie całego procesu rozwoju, ponieważ Rust może nie działać w zgodzie z istniejącymi zestawami instrumentów.
Na przykład, klient, który zdecydował się na przesiadkę na Rusta, dotychczasowo wykorzystywał system czasu rzeczywistego (RTOS) i Tracealyzera od Percepio do monitorowania zadań i ich czasu realizacji. Jednak teraz firma ta planuje użyć RTIC (Real-Time Interrupt-driven Concurrency) z Rustem. W zespole programistów powstało pytanie: „Jak uzyskamy te same pomiary z naszego środowiska Rust?”. Odpowiedź na nie pozostaje jeszcze do ustalenia. Narzędzia, które poznali i nauczyli się wykorzystywać i od których są zależni, mogą już nie działać. (Wersja Tracealyzer dla bare-metal może funkcjonować, ale na ten moment nie jest to oczywiste, a co gorsze sprawdzenie tego wymaga stworzenia dużej części systemu).
Może się okazać, że choć nowoczesny i wartościowy język Rust wydaje się świetnym wyborem, może spowodować, że będzie trzeba cofnąć się i stracić np. wgląd w swój system, który wcześniej mieliśmy, dzięki narzędziom pomocniczym. Aby odzyskać tę możliwość, trzeba samodzielnie opracować nowe instrumenty i techniki pomocnicze. Wyniki mogą być w porządku, ale wszyscy wiedzą, że zaprzepaszczony w ten sposób czas, to stracone środki i szanse na dalszy rozwój.
Przeszkoda #5 — brak standaryzacji
C i C++ mają standardy, do których można się odwołać i zrozumieć, co jest oficjalnie wspierane w danym języku, a co nie. Rust nie posiada formalnej specyfikacji ani standardu. Zespół za niego odpowiedzialny kieruje jego projektowaniem, a wszelkie zmiany przechodzą przez ustanowiony proces zgłaszania komentarzy (RFC). RFC oraz dokumentacja Rust stanowią efektywnie specyfikację języka, ale wysoce nieformalną.
Brak takiej opcji oznacza, że wsparcie komercyjne dla tego języka w aplikacjach krytycznych dla bezpieczeństwa i innych obszarach, będzie w zasadzie nieistniejące. Kompilator Rusta, znany jako rustc, jest darmowy i otwartoźródłowy, ale nie ma wersji komercyjnej. Zainteresowana społeczność rozwija ten kompilator, a zespół Rusta nadzoruje postęp. Chociaż może to nie wydawać się dużym problemem, brak standaryzacji oznacza, że Rust może zmieniać kierunek rozwoju w jednej chwili. To może być świetne dla postępu i innowacji, ale nie dla specjalistów ds. systemów wbudowanych, którzy polegają na spójności dla produktów o długiej żywotności.
Podsumowanie
Czy te przeszkody mówią, że nie powinniśmy przyjmować Rusta w nowych projektach systemów wbudowanych? Nie! Jednakże wskazują, że każdorazowo trzeba dokładnie ocenić, czy jego wykorzystanie przyniesie korzyści firmie i zespołowi w tym projekcie. Jako branża, należy spodziewać się, że te utrudnienia będą istotnymi czynnikami, które mogą wpływać na to, dlaczego nie obserwujemy szybkiej adopcji Rusta. Będą oczywiście przedsiębiorstwa, które go przyjmą i osiągną sukces. Będą też takie, które go zaakceptują i nic godnego uwagi nie będzie z tego wynikać. Inni będą trzymać się sprawdzonych rozwiązań i prowadzić swoje działania jak zwykle, z wykorzystaniem dotychczasowych technologii.
Rust jest ekscytującym językiem i oczekuje się, że powoli zyska sobie udziały w rynku. Należy założyć, że w ciągu najbliższej połowy dekady, więcej zespołów przyjmie jednak C++ niż Rusta. A czy Wam zdarzyło się programować w Rust? W szczególności na platformach wbudowanych? Jakie macie w tym zakresie doświadczenia i odczucia? Co w ogóle zmotywowało Was do wykorzystania tego nowego języka zamiast klasycznego C?
Źródło: https://www.embedded.com/5-roadblocks-to-rust-adoption-in-embedded-systems/
Przeszkoda #1 — wsparcie komercyjne
Współczesne zespoły zajmujące się tworzeniem produktów wbudowanych zazwyczaj korzystają z komercyjnych narzędzi wsparcia, aby przyspieszyć rozwój oprogramowania. Na przykład producent mikrokontrolera przeważnie dostarcza sterowniki niskiego poziomu, systemy plików, systemy operacyjne czasu rzeczywistego (RTOS), narzędzia konfiguracyjne i wiele innych. To pomaga podkręcić tempo rozwoju, ponieważ większość pracy na niższym poziomie sprzętu została już wykonana. Do tej pory tylko nieliczni producenci mikrokontrolerów wspierają Rusta. Nadal dla klientów oferują oni wsparcie głównie dla języka C. Wszystko, co wykracza poza to, trzeba zrobić samodzielnie.
Istnieją narzędzia, takie jak svd2rust, które programiści mogą zużytkować do konwersji plików SVD, które opisują peryferia mikrokontrolera, na tzw. peripheral crate. Instrument ten potrafi dosyć dobrze wygenerować taką: „skrzynkę”, którą programista może wykorzystać. Niestety, może wiązać się to z potencjalnymi problemami, takimi jak:
* Znaczne różnice w jakości w zależności od producenta;
* Rozwlekły i złożony kod generowany przez automatyczne narzędzie;
* Brak komunikatów o błędach, co może skutkować dłuższym czasem debugowania;
* Brak możliwości konfiguracji — instrument stosuje takie samo podejście do każdej paczki;
* Wykorzystanie generyków i metaprogramowania może prowadzić do wydłużenia czasu kompilacji.
Jeśli producent nie dostarcza pakietów wsparcia, to samemu trzeba rozwiązać wszystkie te niedogodności. Choć może to być ekscytujące i przynieść wiele cennych doświadczeń, może negatywnie wpłynąć na harmonogram i budżet projektu.
Przeszkoda #2 — koszty szkoleń
Rust nie jest językiem łatwym do nauki. Chociaż dzieli wspólne idee i koncepcje z wieloma innymi, w tym z C, krzywa uczenia się jest bardziej stroma. Gdy firma rozważa wprowadzenie nowego języka, musi zatrudnić inżynierów, którzy już znają tę technologię lub przeszkolić swój zespół. Grupy zainteresowane wykorzystaniem Rusta na platformach wbudowanych znajdą się w małej i niszowej społeczności. W tejże jest niewielu wykwalifikowanych inżynierów oprogramowania wbudowanego, którzy znają Rusta. Oznacza to, że konieczne może być płacenie więcej za tych nielicznych programistów, którzy są z nim zaznajomieni lub inwestowanie w szkolenie istniejącego zespołu. Tak czy inaczej, przekłada się to na zwiększenie wydatków.
Szkolenie zespołu do nauki Rusta to dobry pomysł. Każda firma i programista powinien stale inwestować w siebie. Ta branża ewoluuje tak szybko, że jeśli się tego nie robi, to zostaje się w tyle. Jednak przejście z jednego języka programowania na inny musi przynieść zwrot z inwestycji dla firmy. Zwłaszcza w przypadku przeskoku na język o nieco niższej dojrzałości pokroju Rusta. Rezultat musi zaowocować zwrotem z inwestycji, takim jak lepsze zabezpieczenia, stabilniejszy system itp. Zespół planujący wykorzystać Rusta powinien obiektywnie ocenić, czy jest to odpowiednia droga do podążania.
Szkolenie w tym przypadku nie ogranicza się do krótkiego 5-dniowego kursu. Nauka składni języka to jedno, ale nabycie w nim doświadczenia, unikanie rozmaitych pułapek i pisania wysokiej jakości, łatwego do utrzymania kodu, to zupełnie inna bajka. Tego nie da się ogarnąć w tydzień. W rzeczywistości nie można tego osiągnąć nawet w ciągu roku, choć w tym czasie uda się poczynić wydatne postępy. Dlatego początkowe koszty szkolenia mogą wydawać się niewielkie. Jednak całościowe obejmują opóźnienia w projektach, dodatkowe debugowanie i wolniejszy czas rozwoju, ponieważ zespół uczy się, jak odpowiednio stosować nowy język w swoich produktach. Nie oznacza to, że nie powinno się tego robić, ale trzeba to dokładnie ocenić i zdawać sobie sprawę, że to istotne i realne utrudnienie.
Przeszkoda #3 — konserwatywne podejście do przyjmowania nowych technologii
Jak łatwo zauważyć, nowe technologie są wdrażane w środowiskach rozwoju systemów wbudowanych bardzo powoli. Podczas projektowania produktów fizycznych w porównaniu z czystymi aplikacjami programowymi, wszelkie nowości wiążą się z ryzykiem skorelowanym z bezpieczeństwem, produkcją i właściwym działaniem układu. W przypadku software, skargi prowadzą do aktualizacji oprogramowania w ciągu 24 godzin. Jeśli pracujemy nad systemem w branży lotniczej, motoryzacyjnej lub nawet elektroniki użytkowej, niekoniecznie można mieć taką możliwość.
Firmy bazujące na produktach fizycznych często ponoszą większe ryzyko niepowodzenia. Właściciele i menedżerowie przedsiębiorstw zwykle są bardziej oporni na potencjalne niebezpieczeństwa i wybierają technologie, które są znane i sprawdzone. (Spójrzmy na branżę wynoszenia pojazdów kosmicznych. Jak długo rozwój tego sektora niemalże stał w miejscu z powodu obaw przed ryzykiem?). Istnieją także często pewne inwestycje w obecne technologie, przepływy pracy i pozyskanych pracowników (patrz wyżej). Koszt zmiany może być znaczący dla ugruntowanej firmy, a korzyści z tego wynikające są potencjalnie niewielkie. Jeśli decyzję podejmuje mała marka, rozpoczynająca swoją działalność, nie ma jeszcze tych początkowych inwestycji, więc przyjęcie nowszego rozwiązania, takiego jak Rust, może być w tym przypadku rozsądne, ponieważ i tak trzeba stworzyć swoją infrastrukturę technologiczną i opracować procesy.
Możliwość niepowodzenia nierzadko skłania firmy do korzystania z dostępnych technologii o niskim ryzyku, aby osiągnąć swoje cele biznesowe. Dlatego wiele przedsiębiorstw może spojrzeć na Rusta i zdecydować się na użycie C lub C++, ponieważ przyjęcie nowego rozwiązania, takiego jak Rust, nie daje żadnych rzeczywistych korzyści w porównaniu z tym, co jest już ugruntowane w branży. Nie powinniśmy tego mówić, ale doświadczona jednostka może zrobić to samo w C lub C++, co programista Rusta w tym języku, zachowując jednakie bezpieczeństwo (różnica jest jedynie wtedy, gdy nie mamy do czynienia z zaawansowanymi specjalistami w zakresie programowania).
Przeszkoda #4 — integracja zestawu narzędzi
Wielu programistów korzysta obecnie z systemów budowania, przepływów pracy i narzędzi, które używają zintegrowanego sposobu wytwarzania oprogramowania wbudowanego. Zastosowanie Rusta wymusi na tych jednostkach ponowne przemyślenie i przerobienie całego procesu rozwoju, ponieważ Rust może nie działać w zgodzie z istniejącymi zestawami instrumentów.
Na przykład, klient, który zdecydował się na przesiadkę na Rusta, dotychczasowo wykorzystywał system czasu rzeczywistego (RTOS) i Tracealyzera od Percepio do monitorowania zadań i ich czasu realizacji. Jednak teraz firma ta planuje użyć RTIC (Real-Time Interrupt-driven Concurrency) z Rustem. W zespole programistów powstało pytanie: „Jak uzyskamy te same pomiary z naszego środowiska Rust?”. Odpowiedź na nie pozostaje jeszcze do ustalenia. Narzędzia, które poznali i nauczyli się wykorzystywać i od których są zależni, mogą już nie działać. (Wersja Tracealyzer dla bare-metal może funkcjonować, ale na ten moment nie jest to oczywiste, a co gorsze sprawdzenie tego wymaga stworzenia dużej części systemu).
Może się okazać, że choć nowoczesny i wartościowy język Rust wydaje się świetnym wyborem, może spowodować, że będzie trzeba cofnąć się i stracić np. wgląd w swój system, który wcześniej mieliśmy, dzięki narzędziom pomocniczym. Aby odzyskać tę możliwość, trzeba samodzielnie opracować nowe instrumenty i techniki pomocnicze. Wyniki mogą być w porządku, ale wszyscy wiedzą, że zaprzepaszczony w ten sposób czas, to stracone środki i szanse na dalszy rozwój.
Przeszkoda #5 — brak standaryzacji
C i C++ mają standardy, do których można się odwołać i zrozumieć, co jest oficjalnie wspierane w danym języku, a co nie. Rust nie posiada formalnej specyfikacji ani standardu. Zespół za niego odpowiedzialny kieruje jego projektowaniem, a wszelkie zmiany przechodzą przez ustanowiony proces zgłaszania komentarzy (RFC). RFC oraz dokumentacja Rust stanowią efektywnie specyfikację języka, ale wysoce nieformalną.
Brak takiej opcji oznacza, że wsparcie komercyjne dla tego języka w aplikacjach krytycznych dla bezpieczeństwa i innych obszarach, będzie w zasadzie nieistniejące. Kompilator Rusta, znany jako rustc, jest darmowy i otwartoźródłowy, ale nie ma wersji komercyjnej. Zainteresowana społeczność rozwija ten kompilator, a zespół Rusta nadzoruje postęp. Chociaż może to nie wydawać się dużym problemem, brak standaryzacji oznacza, że Rust może zmieniać kierunek rozwoju w jednej chwili. To może być świetne dla postępu i innowacji, ale nie dla specjalistów ds. systemów wbudowanych, którzy polegają na spójności dla produktów o długiej żywotności.
Podsumowanie
Czy te przeszkody mówią, że nie powinniśmy przyjmować Rusta w nowych projektach systemów wbudowanych? Nie! Jednakże wskazują, że każdorazowo trzeba dokładnie ocenić, czy jego wykorzystanie przyniesie korzyści firmie i zespołowi w tym projekcie. Jako branża, należy spodziewać się, że te utrudnienia będą istotnymi czynnikami, które mogą wpływać na to, dlaczego nie obserwujemy szybkiej adopcji Rusta. Będą oczywiście przedsiębiorstwa, które go przyjmą i osiągną sukces. Będą też takie, które go zaakceptują i nic godnego uwagi nie będzie z tego wynikać. Inni będą trzymać się sprawdzonych rozwiązań i prowadzić swoje działania jak zwykle, z wykorzystaniem dotychczasowych technologii.
Rust jest ekscytującym językiem i oczekuje się, że powoli zyska sobie udziały w rynku. Należy założyć, że w ciągu najbliższej połowy dekady, więcej zespołów przyjmie jednak C++ niż Rusta. A czy Wam zdarzyło się programować w Rust? W szczególności na platformach wbudowanych? Jakie macie w tym zakresie doświadczenia i odczucia? Co w ogóle zmotywowało Was do wykorzystania tego nowego języka zamiast klasycznego C?
Źródło: https://www.embedded.com/5-roadblocks-to-rust-adoption-in-embedded-systems/
Fajne? Ranking DIY
