Skocz do zawartości

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


FlyingDutch

Pomocna odpowiedź

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ć 🙂 

  • Lubię! 1
  • Pomogłeś! 1
Link do komentarza
Share on other sites

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?

Link do komentarza
Share on other sites

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... 😄

  • Lubię! 1
  • Pomogłeś! 1
Link do komentarza
Share on other sites

Zarejestruj się lub zaloguj, aby ukryć tę reklamę.
Zarejestruj się lub zaloguj, aby ukryć tę reklamę.

jlcpcb.jpg

jlcpcb.jpg

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

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 przez ReniferRudolf
  • Lubię! 1
  • Pomogłeś! 1
Link do komentarza
Share on other sites

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

Link do komentarza
Share on other sites

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 🙂 

  • Lubię! 1
Link do komentarza
Share on other sites

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

Link do komentarza
Share on other sites

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ć.

Link do komentarza
Share on other sites

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

Link do komentarza
Share on other sites

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:

image.thumb.png.33e6e9b91ec7f07a11eac17be8a33cc9.png

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ć 🙂 

  • Lubię! 2
Link do komentarza
Share on other sites

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

  • Lubię! 1
Link do komentarza
Share on other sites

(edytowany)

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 przez FlyingDutch
  • Lubię! 1
Link do komentarza
Share on other sites

Bądź aktywny - zaloguj się lub utwórz konto!

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto w ~20 sekund!

Zarejestruj nowe konto, to proste!

Zarejestruj się »

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się »
×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.