Na forum 4programmers.net korzystamy z plików cookies. Część z nich jest niezbędna do funkcjonowania
naszego forum, natomiast wykorzystanie pozostałych zależy od Twojej dobrowolnej zgody, którą możesz
wyrazić poniżej. Klikając „Zaakceptuj Wszystkie” zgadzasz się na wykorzystywanie przez nas plików cookies
analitycznych oraz reklamowych, jeżeli nie chcesz udzielić nam swojej zgody kliknij „Tylko niezbędne”.
Możesz także wyrazić swoją zgodę odrębnie dla plików cookies analitycznych lub reklamowych. W tym celu
ustaw odpowiednio pola wyboru i kliknij „Zaakceptuj Zaznaczone”. Więcej informacji o technologii cookie
znajduje się w naszej polityce prywatności.
Jaka jest definicja system programming language? Czy wystarczy, że dany język ma pointery oraz ręczne zarządzanie pamięcią? Czy system w tej nazwie to jest byle jakie urządzenie elektroniczne, nawet takie najbardziej prymitywne, np. nie wiem pilot do garażu :D czy chodzi o systemy operacyjne?
Czy rust jest językiem programowania systemów? Na wiki jest informacja, że jest general purpose language. Widziałem kilka wypowiedzi i artykułów i rust nie zawojował jądra linuxa. Z drugiej strony rust został stworzony przez pracownika mozilli, a więc tam się nie tworzy systemów.
Czy w przyszłości jest możliwe stworzenie języka programowania systemów opartego na Javie? Czy w historii były jakieś próby stworzenia takiego języka przez te wielkie korporacje jak Orlace/Sun?
Widziałem kilka wypowiedzi i artykułów i rust nie zawojował jądra linuxa.
a co zawojowało linuksa? tam jest tylko język c (w sensie jeśli chodzi o kod, który faktycznie ląduje w binarkach zwanych jądrem systemu), więc z tego miałoby wynikać, że tylko c to 'system programming language'?
rust powoli się wbija do linuksa, ale jest duży opór ze strony ludzi, którzy zakrawają na fanatyków c.
"A subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible. They don't see Rust as having value and would rather it just goes away.
When I tried to upstream the DRM abstractions last year, that all was blocked on basic support for the concept of a "Device" in Rust. Even just a stub wrapper for struct device would be enough.
That simple concept only recently finally got merged, over one year later.
When I wrote the DRM scheduler abstractions, I ran into many memory safety issues caused by bad design of the underlying C code. The lifetime requirements were undocumented and boiled down to "design your driver like amdgpu to make it work, or else".
My driver is not like amdgpu, it fundamentally can't work the same way. When I tried to upstream minor fixes to the C code to make the behavior more robust and the lifetime requirements sensible, the maintainer blocked it and said I should just do "what other drivers do".
Even when I pointed out that other C drivers also triggered the same bugs because the API is just bad and unintuitive and there are many secret hidden lifetime requirements, he wouldn't budge.
One C driver works, so Rust drivers must work the same way."
"This is as short a series as one can be: just removing myself as maintainer of the Rust for Linux project.
I am retiring from the project. After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it's best to leave it up to those who still have it in them.
To the Rust for Linux team: thank you, you are great. It was a pleasure working with you all; the times we spent discussing technical issues, finding ways to address soundness holes, etc. were something I always enjoyed and looked forward to. I count myself lucky to have collaborated with such a [talented] and friendly group.
I wish all the success to the project.
I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix.
Lastly, I'll leave a small, 3min 30s, sample for context here: https://youtu.be/WiPp9YEBV0Q?t=1529 -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code."
wspomiany filmik:
Jaka jest definicja system programming language? Czy wystarczy, że dany język ma pointery oraz ręczne zarządzanie pamięcią? Czy system w tej nazwie to jest byle jakie urządzenie elektroniczne, nawet takie najbardziej prymitywne, np. nie wiem pilot do garażu czy chodzi o systemy operacyjne?
(...)
Czy w przyszłości jest możliwe stworzenie języka programowania systemów opartego na Javie? Czy w historii były jakieś próby stworzenia takiego języka przez te wielkie korporacje jak Orlace/Sun?
wskaźniki i ręczne zarządzanie pamięcią da się zrobić w samej javie. jest nieudokumentowana i niby nieoficjalna klaska sun.misc.Unsafe , ale jest szeroko używana i są do niej poradniki, np: https://www.baeldung.com/java-unsafe . obecnie klasa sun.misc.unsafe jest powoli usuwana z javy i zastępowana przez https://openjdk.org/jeps/454 JEP 454: Foreign Function & Memory API i inne rozwiązania, które dają podobne możliwości.
w języku programowania systemów bardzo ważna jest wysoka wydajność od razu oraz ścisła kontrola nad zużyciem zasobów (w tym wydajnością). java jest ogólnie tego przeciwieństwem. nie tylko w javie jest duży dynamizm, np. kompilacja w locie włącznie z ładowaniem bajtkodu w locie, ale całe zarządzanie pamięcią (przynajmniej z perspektywy typowego programisty javy) jest oparte o garbage collectora, który nie daje wiele kontroli.
jest coś takiego jak https://en.wikipedia.org/wiki/Real-time_Java i z tego co pobieżnie przejrzałem, wygląda jakby kiedyś było tym zainteresowanie, ale od jakieś czasu jest cicho w temacie. gdyby coś poważnego z tego wyszło to teoretycznie można by zrobić system operacyjny oparty na tym. ogólnie jednak widać, że nikt już nie chce robić z tym nic poważnego. w sumie nie dziwię się, bo rust, podobnie jak java, zapewnia dużo lepsze bezpieczeństwo pamięci niż c/ c++/ etc, a jednocześnie dużo bardziej (niż java) pasuje jako system programming language dla współczesnych architektur procesorów, które mają wbudowane mechanizmy zabezpieczeń, wirtualizacji, itp itd
Języki systemowe to te które służą do programowania systemów, które dopiero uruchamiają aplikacje. Czyli przeciwieństwem programowania systemowego jest programowanie aplikacyjne.
Kluczowa cecha wg mnie żeby można było uznać język za systemowy to czy da się w nim pisać oprogramowanie systemowe bez polegania na innym systemie. Nie chodzi o wskaźniki i inne duperele niskopoziomowe, bo to do pewnego stopnia umie nawet Go i Java. Ale czy mógłbyś napisać w tym samodzielny program chodzący na gołym sprzęcie, bez pomocy systemu operacyjnego, interpretera czy jakiejś maszyny wirtualnej? Czy mógłbyś napisać w tym sam system operacyjny lub firmware jakiegoś urządzenia? Rust, C++, Zig, C to wymaganie spełniają, Java i Go nie.
Jezyki systemowe wyróżnia zwykle też to że dają programiście pełną kontrolę nad tym co robi program, aż do poziomu pojedynczej instrukcji CPU. Dają kontrolę nad położeniem rzeczy w pamięci. Język aplikacyjne zwykle takiej wolności nie dają, czasem pozwalają na troche kontroli jak wspomniane wyżej Unsafe w Javie ale nadal bardzo mocno ograniczają co możesz zrobić i wiele rzeczy robią „magicznie” decydując za Ciebie.
Ale z drogiej strony Rust jest akurat całkiem przyjemnym językiem do programowania aplikacyjnego, gdzie z odpowiednimi bibliotekami poziom abstrakcji może być podobny co w Pythonie. Dlatego jest językiem ogólnego przeznaczenia.
Kluczowa cecha wg mnie żeby można było uznać język za systemowy to czy da się w nim pisać oprogramowanie systemowe bez polegania na innym systemie. Nie chodzi o wskaźniki i inne duperele niskopoziomowe, bo to do pewnego stopnia umie nawet Go i Java. Ale czy mógłbyś napisać w tym samodzielny program chodzący na gołym sprzęcie, bez pomocy systemu operacyjnego, interpretera czy jakiejś maszyny wirtualnej? Czy mógłbyś napisać w tym sam system operacyjny lub firmware jakiegoś urządzenia? Rust, C++, Zig, C to wymaganie spełniają, Java i Go nie.
Jezyki systemowe wyróżnia zwykle też to że dają programiście pełną kontrolę nad tym co robi program, aż do poziomu pojedynczej instrukcji CPU. Dają kontrolę nad położeniem rzeczy w pamięci. Język aplikacyjne zwykle takiej wolności nie dają, czasem pozwalają na troche kontroli jak wspomniane wyżej Unsafe w Javie ale nadal bardzo mocno ograniczają co możesz zrobić i wiele rzeczy robią „magicznie” decydując za Ciebie.
To pewne uproszczenie. W języku C np. nic nie ma o kontrolowaniu pojedynczych instrukcji CPU, wywoływaniu i ustawianiu przerwań, poziomach uprzywilejowania itp. Raczej nie w standardzie.
Odpowienie rozszerzenia są dodane w opcjach konkretnego kompilatora, pragma itp.
Teoretycznie takie opcje można dodać do każdego języka - nawet PHP. Tylko nie zawsze warto.
Cholera wie co to jest system programming. Imo są takie poziomy:
język nie ma/ma minimalny runtime (lub ma taki przełącznik) i wstawki assemblerowe, co pozwala na pisanie czegokolwiek na czymkolwiek . Przykłady: C/Rust (no_std, Rust in Linux). C++ wypada tu trochę gorzej, bo wsparcie dla system programming na tym poziomie jest głównie z uwagi na to, że C++ to podzbiór C. Sama biblioteka standardowa C++ nawet nie aspiruje do bycia wspieraną w takich środowiskach w porównaniu do takiego Rusta
język pozwala na wygenerowanie dowolnego kodu przy pomocy swoich abstrakcji i wstawek assemblera. C++ jest dobrym przedstawicielem
poziom niżej: to samo, ale gorzej. Go jest dobrym przykładem: ma ciężki runtime, ale można pisać wstawki asemblerowe, do klepania w userspace wystarczy na napisanie czegokolwiek
najniższy poziom to języki o których nikt by nie pomyślał, że mogą być system programming np. Python/JS
Nie oznacza to, że ktoś uparty nie jest w stanie napisać prostej maszyny wirtualnej do Pythona i w taki sposób napisać kernel w Pythonie pokazując, że gadam głupoty. To czy dany język nadaje się czy nie do tego zastosowania zależy tylko od tego jaka konwencja i moda wykształciła się w naszym community. Przykładowo Go jest często uznawany za system programming, bo docker i k8s są w nim napisane. IMO nie jest to system programming w tradycyjnym tego słowa znaczenia, bardziej user space system programming
Przykładowo Go jest często uznawany za system programming, bo docker i k8s są w nim napisane. IMO nie jest to system programming w tradycyjnym tego słowa znaczenia, bardziej user space system programming
Czyli przywołując skądinąd zasłyszaną wypowiedź że w Nokii klepali (albo próbowali) oprogramowanie BTSów w JSie to można ten język nazwać embedded fronted programming czy raczej fullstack programming language?
Ja zrobię system operacyjny jeśli są spełnione następujące kryteria.
Można wygenerować kod bez wszystkich bibliotek no standard library.
To jest ważne, bo te biblioteki do standardowego programowania one często z jakichś systemowych wywołań korzystają, które są tylko w userspace. Za to mogą być biblioteki takie, które są specjalnie napisane w czystej postaci z niczego nie korzystają żadnych zależności i systemowych wywołań czy czegoś.
Język musi wygenerować natywny kod, bo dopiero piszesz system.
Musi mieć wstawki assemblera lub mieć swoje odpowiedniki operacji dla każdego procesora.
Są różne specjalne operacje i specjalne rejestry, np. żeby hardware breakpoint postawić, odczytać czy wypisać jakieś dane do io portów, wywołać przerwanie czy syscall.
Teoretycznie jak nie ma wstawek to można zapisać sekwencję bytów jako string i skoczyć tam callem jakby tam była jakaś funkcja, ale to wtedy zaciemnia kod bo kod zapisany opcodami jest nieczytelny na pierwszy rzut oka i to są haki, ale pewnie się uda. Tak wyglądają exploity gdzie ktoś podaje jako tekst instrukcje assemblera printowalnymi znakami, a potem niechcący use after free pointer myśli, że tam jakaś funkcja i wykonuje kod czy jakiś stackoverflow po nadpisaniu adresu powrotu gdzie się skacze do miejsca gdzie się zalokowało stringa, a ten string jest opcodami procesora.
No i taki wygenerowany kod najlepiej jakby był bez żadnego formatu surowa binarka coś jak wycięcie sekcji i pod assemblerem mamy tylko to co napisaliśmy nic poza tym, bo wtedy trzeba jeszcze ręcznie jakieś operacje przeprowadzać co prawda jest to wykonalne, ale utrudnia pracę.
Bez wycięcia też się uda, tylko musimy obliczyć relatywny adres i po prostu więcej miejsca zużyjemy.
garbage collector jest dozowolny są pewne implementacje do kernela, ale ma strasznie słabą wydajność z benchmarków, które pokazują, ale musi być specjalnie zaprojektowany, bo taki z javy to on używa innego wątku, który tym się zajmuje, a na początku nie masz jeszcze w ogóle żadnych wątków w takim systemie, musisz dopiero zarządzanie nimi zaprojektować.
czy chodzi o systemy operacyjne?
Java i Go nie- jakby z Jazelle się udało to byś inaczej śpiewał.