Nowy język (C replacement)- co wybrać: Rust albo Zig

[FlyingDutch]

Cześć,

od jakiegoś czasu zaczałem się interesować językami, które mogłyby zastapić język C w programowaniu embedded. Chodzi mi o języki które są równie wydajne co C i mają nowoczesną składnię oraz ułatwiają pisanie kodu pozbawionego kilku błędów łatwych do popełnienia w języku C (zarządzanie pamięcią). W C++ według  mnie zarządzanie pamięcią dla typów alokowanych na stercie jest lepsze niż w C - np. uzycie inteligentnych wskaźników i używanie kontenerów z biblioteki STL, ale sam język jest bardziej złożony niż C.

Pierwszym językiem którym się zainteresowałem był Rust zapewniający większe bezpieczeństowo zarządzania pamięcią i programowania wielowątkowego. Potem trafiłem na język Zig, który zafascynował mnie prostą składnią i wydajnością często duzo wiekszą niż język C.

Podaję tutaj linki do stron domowych dla języków Rust i Zig:

https://www.rust-lang.org/

https://ziglang.org/

Czy ktoś ma doświadczenie w programowaniu mikrokontrolerów w jednym (lub obu) z tych języków i móglby się podzielić opiniami o ich przydatności i różnicach.

Pozdrawiam

[Gieneq]

Cześć @FlyingDutch

Robiłem podejście do Rusta i wygląda naprawdę ciekawie. Jest branch ESP-IDF dla ESP32 w tym języku i przez jakiś czas był dostępny devkit do realizacji przykładów z kursu Rusta dla ESP32. Jak byłem na Embedded World w Norymberdze to przy stoisku Espressifa rozmawiałem z gościem, który jest współtwórcą tego brancha i wyglądało na to że jest to projekt poważny, mogący być użyty w produkcji. Też można o tym posłuchać w konferencjach Espressifa.

Biorą udział w webinarach od ST raz wyszedł temat Rusta i tam ten temat jest negatywnie postrzegany. Został skomentowany "znowu pojawia się potwór-Rust". Na YT jest kilka filmów w tym jeden polski o programowaniu STM32 w Rust.

Ale czy zastąpi C, chyba nie. Z tego co rozumiem Rust jest tu językiem wyższego poziomu działający razem z C. C jest do opisu niskopoziomowego drivera, a Rust nabudowuje kod "unsafe". W ESP-IDF może mieć sens, bo to nie jest HAL tylko bardziej middleware.

Możliwe też, że z racji nowego języka mało kto będzie zainteresowany wdrożeniem do produkcji. U nas był pomysł pójścia w to, ale to za duży problem dla utrzymania - znalezienie programisty embedded to problem, a programisty embedded z egzotycznym językiem - na ten moment bardzo trudne. Ale mogę się nie znać 🙂 

[Gieneq]

Tu kiedyś coś pisaliśmy w tym temacie:

 

13 godzin temu, FlyingDutch napisał:

wydajnością często duzo wiekszą niż język C.

Jak to w ogóle możliwe? Kod jest jakoś lepiej kompilowany do asemblera? Czy w embedded jakoś lepiej wykorzystuje polecenia specyficzne dla konkretnego rdzenia?

[H1M4W4R1]

8 minut temu, Gieneq napisał:

Jak to w ogóle możliwe? Kod jest jakoś lepiej kompilowany do asemblera? Czy w embedded jakoś lepiej wykorzystuje polecenia specyficzne dla konkretnego rdzenia?

Może jakieś dziwne flagi kompilatora 😉 Ogólnie czasami zdarzało mi się, że C# był szybszy od C, ale to głównie dlatego, że biblioteki w C przez swój uniwersalizm wykorzystują standardowy zestaw instrukcji, a C# potrafi się dostosować do konkretnego procesora. Przykład LINQ w .NET 7.0, gdzie zaimplementowano sprzętową akcelerację obliczeń "wektorowych"  😉

Zig wygląda ciekawie, ale brak bibliotek jest już mniej ciekawy... 😄

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[ReniferRudolf]

1 godzinę temu, Gieneq napisał:

Ale czy zastąpi C, chyba nie. Z tego co rozumiem Rust jest tu językiem wyższego poziomu działający razem z C. C jest do opisu niskopoziomowego drivera, a Rust nabudowuje kod "unsafe".

Myślę, że to jest zupełnie kluczowa uwaga. Do niskopoziomowego driver-a nie da się wymyśleć niczego lepszego niż C. Podpowiada to zarówno intuicja jak i fakt, że przez 40 lat niczego nie wymyślono... Ale już jakakolwiek "nadbudówka" w stronę "middleware" (o wyższych warstwach nawet nie wspominam) - tu z C warto się pożegnać i otwiera się pole do długiej i szerokiej dyskusji. 

Edytowano Październik 23, 2023 przez ReniferRudolf

[FlyingDutch]

54 minuty temu, Gieneq napisał:

Tu kiedyś coś pisaliśmy w tym temacie:

 

Jak to w ogóle możliwe? Kod jest jakoś lepiej kompilowany do asemblera? Czy w embedded jakoś lepiej wykorzystuje polecenia specyficzne dla konkretnego rdzenia?

Cześć,

w wielu standardowych benchmarkach (na tym samym sprzęcie) Zig jest czasami ponad 10 razy szybszy od C.

Jest to możliwe tu cyctat:

Cytat

Zig uses undefined behavior as a razor sharp tool for both bug prevention and performance enhancement. Speaking of performance, Zig is faster than C. The reference implementation uses LLVM as a backend for state of the art optimizations. What other projects call “Link Time Optimization” Zig does automatically.

Pozdrawiam

[Gieneq]

2 godziny temu, H1M4W4R1 napisał:

Zig wygląda ciekawie, ale brak bibliotek jest już mniej ciekawy...

to też problem 😕 Rust jest pod tym względem bardziej popularny ale bez rewelacji - ma sporo projektów w stylu "Are we XXX yet/ready?", są w tym całkiem dobre biblioteki, mają swoje niewielkie społeczności, ale zmiany które tam zachodzą, powodują że raczej nie są solidną bazą produkcyjną. W embedded może się nie wypowiem, ale przez jakiś czas szukałem biblioteki graficznej dla game dev w Rust i nie było to oczywiste. Widziałem kilka mniej lub bardziej udanych ale porzuconych projektów i kilka większych rozwijanych ale z niewielką historią. Ostatecznie odpuściłem i wybrałem to co znam w C.

Ale jest tu ciekawe wyzwanie dla pasjonaty - można przyłączyć się do przecierania szlaków 🙂 

[rade]

c# joined the game 😆

https://www.nanoframework.net/

Używałem jakiś czas do pogodynki, i używał bym nadal gdyby komunikację z Supla można było łatwo przenieść do c#.

 

[FlyingDutch]

1 godzinę temu, rade napisał:

c# joined the game 😆

https://www.nanoframework.net/

Używałem jakiś czas do pogodynki, i używał bym nadal gdyby komunikację z Supla można było łatwo przenieść do c#.

 

Cześć,

ale C# jest oparty na kodzie pośrednim MSIL i do poprawnego działania wymaga dodatkowego "runtime". Poza tym korzysta z "garbage collector'a" i nie nadaje się do systemów real-time. No chyba, że się coś zmieniło dla tej konkretnej wersji, ale jest to mało prawdopodobne.

Pozdrawiam

[H1M4W4R1]

4 minuty temu, FlyingDutch napisał:

Cześć,

ale C# jest oparty na kodzie pośrednim MSIL i do poprawnego działania wymaga dodatkowego "runtime". Poza tym korzysta z "garbage collector'a" i nie nadaje się do systemów real-time. No chyba, że się coś zmieniło dla tej konkretnej wersji, ale jest to mało prawdopodobne.

C# nie jest oparty na IL. To Roslyn kompiluje C# .NET do kodu pośredniego IL wymagającego runtime'a 😉 (tak język tej nielubianej firmy prawidłowo nazywa się C# .NET, a nie C#).

Sam C# to definicja języka, którą można zastosować do budowy własnego kompilatora. Równie dobrze C# można kompilować do kodu źródłowego w C lub ASM 😉 Język i toolchain to dwie odmienne kwestie.

Gdzieś kiedyś widziałem definicje C i C# w ANTLR, które pozwalały na budowę własnych kompilatorów, ale nie jestem teraz tego w stanie wykopać.

[FlyingDutch]

10 minut temu, H1M4W4R1 napisał:

C# nie jest oparty na IL. To Roslyn kompiluje C# .NET do kodu pośredniego IL wymagającego runtime'a 😉 (tak język tej nielubianej firmy prawidłowo nazywa się C# .NET, a nie C#).

Sam C# to definicja języka, którą można zastosować do budowy własnego kompilatora. Równie dobrze C# można kompilować do kodu źródłowego w C lub ASM 😉 Język i toolchain to dwie odmienne kwestie.

Gdzieś kiedyś widziałem definicje C i C# w ANTLR, które pozwalały na budowę własnych kompilatorów, ale nie jestem teraz tego w stanie wykopać.

Z tego co widzę .NET nanoFramework jest oparty na runtime dla kodu pośredniego (cytat z oryginalnej dokumentacji):

Cytat

The way .NET nanoFramework code is build is through the normal msbuild tool chain and then with a specific application called metadata processor. The role of this application is crucial as it does transform the normal dll/exe with the Intermediate Language (IL) code into a Portable Executable (PE) code that can be interpreted on every device by nanoFramework’s execution engine and .NET Base Class Library.

Poza tym zarządzalną część Języka C# nie może korzystać ze wskaźników tak jak to czyni C (można to robić w kodzie unsafe). Jakoś nie widzę potrzeby pisania własnego kompilatora dla C#.

Pozdrawiam

[Gieneq]

W tzw międzyczasie przeglądam jak tam ma się Rust i powoli nabieram ochoty na kolejne podejście. Znalazłem ciekawy komentarz na forum ST:

Link do githuba. 600+ commitów, 2 lata, widać że aktywnie coś się dzieje i całkiem pokaźna lista mikrokontrolerów:

Cytat

F3, F4, L4, L5, G0, G4, H5, H7, WB, and WL. U5 is planned once its SVD files and PAC become available.

Tested on the following devices:

STM32F303

STM32F401, F411

STM32L476, L433, L443, L412, L432

STM32L552

STM32WB5MMG

STM32G431, G491, G473

STM32H743(V), H745 (both cores)

Myślę, że warto sprawdzić. L4 to ten sam układ co w kursie na Forbocie. Można porównać 🙂 

[rziomber]

Trochę się interesowałem Zig, ale jako `zig cc`: a Powerful Drop-In Replacement for GCC/Clang

Using Zig As Cross Platform C Toolchain

Compile a C/C++ Project with Zig

Cytat

The result is a statically compiled ImGui application that can run under Windows. It runs noticeably slower than an application compiled Windows -> Windows under mingw32, though, but I have not looked into that too much (since it's an internal utility mostly used by myself ...). Adding -O2 does not help, but turning verbose logging output out does.

Using Zig to cross-compile from Linux to Windows

[FlyingDutch]

3 godziny temu, rziomber napisał:

Trochę się interesowałem Zig, ale jako `zig cc`: a Powerful Drop-In Replacement for GCC/Clang

...

Cześć,

na razie właśnie też to testuję w wolnych chwilach 🙂

Pozdrawiam

[FlyingDutch]

Cześć,

dość dużo się dzieje nie tylko w językach mających konkurować z C++, ale również w rozwoju samego C++ (i jego rozwojowych gałęziach). W tym odcinku serii  tutoriali Mike'a Shah dot. C++ jest to fajnie przedstawione:

https://www.youtube.com/watch?v=vX4eG5qx-6s&list=PLvv0ScY6vfd8j-tlhYVPYgiIyXduu6m-L&index=90

Pozdrawiam

 

Edytowano Listopad 9, 2023 przez FlyingDutch