A Rust-ban való Linux kernel fejlesztés támogatása

Disclaimer: c++-t programozok penzert, tehat nem vagyok elfogulatlan egyaltalan.

Ha csak a feature-oket nezem a c++ is meglepoen modern nyelv. Mas kerdes, hogy a nyelv tervezesi alapelvei kozul melyik az, ami fontos es relevans ma is. Egyetertek azzal is, hogy Linus nem volt tulzottan motivalt abban, hogy a kernelt megnyissa a c++ fejlesztok fele.

De ha mar bashingeljuk a prognyelveket, akkor nyilvanvaloan nem csak a c++ hazanal van szemet:

1. A Go-nak pl. garbage collectora van. A felreertes onnan ered, hogy a Go-t rendszerprogramozasi nyelvnek szantak, de nem abban az ertelemben, hogy irjunk benne kernelt, hanem mondjuk irjunk benne szerveralkalmazasokat, halozati szolgaltatasokat (docker-t, IPFS-t, VPN klienst, adatbazis szervert stb. stb.). Szerintem a c++ is itt muzsikal a legjobban.

2. A Nim eleg partizan dolog. Community es nemi intezmenyi tamogatas nem artana moge. Marmint pl. gondolom egy magyar NIM konferenciara nem kellene kiberelni a Millenarist. Addig arrol beszelunk, hogy valakiknek pokolian sokat kellene dolgoznia, azert, hogy annak a 10 NIM fejlesztonek meglegyen a teoretikus lehetosege, hogy irjon egy kernelmodult. Egyszeruen nem lenne gazdasagos.

3. A Swift-nel szerintem soha nem is volt fokusz az, hogy ilyesmire hasznaljak. Vegignezve a feature listat (marmint kernelfejlesztesi igenyek alapjan), szerintem minden, amit tud a Swift, tudja a Rust is, csak jobban. Nem azt mondom, hogy a Swift szarabb, mint a Rust, mert amint arrol van szo, hogy mobilappot akarok csinalni iOS-re, egybol kivilagosodik az eg.

A Rust ebbol a szempontbol talan tenyleg a legjobb valasztas lehet, *ha* ugy dontottunk, hogy megprobaljuk ledobni a c-t mint legacyt. Strategiailag szerintem nem a legokosabb dontes. Ha engem kerdeznek, akkor irjanak egy kernelt Rust-ban (a la Redox), es mutassak meg, hogy a Rust velelmezett elonyei mennyivel faszabb eredmenyeket hoz. Bar a Rust tenyleg nagyon jo dolog, jot mosolygok, amikor azt latom, hogy a crate-ek egy jelentos resze bewrappel unsafe lib-eket (libmysqlclient, rocksdb, libpng, libpg, sqlite, curl, libopenssl (!!!) lehetne sorolni a vegtelensegig). Kicsit arrol van szo, hogyha irsz egy 5000 soros Rust service-t, akkor meg ott fog ketyegni alatta 100000 sornyi c/c++ kod es azt probaljuk allitani, hogy ez igy teljesen biztonsagos?

Ettol fuggetlenul en kivancsi vagyok ra, hogy mi lesz a kimenetele dolgoknak ezen a teren es kicsit drukkolok is a Rust-nak.

http://harmful.cat-v.org/software/c++/linus

Első körben tehát ezek a nyelvek jöhetnek szóba. Tök jó.

Linux kernelnél szempont, hogy ne GC-re támaszkodjon alapból a memóriafelszabadítása. Kérdés az, hogy ez mennyire valós szempont?
Talán ebből látszik időkritikus ütemezőben való használatkor néhány hátulütője: https://dlang.org/spec/garbage.html#how_gc_works
A fenti nyelvekből a GC alapú automata memóriamenedzsment dobva Linux kernel esetén, ugyanakkor legyen biztonságos a memóriakezelése.
Nézzük, hogy mi maradt.

https://github.com/gopher-os/gopher-os

according to the screenshots it is able to panic,
but non of the shots show a working `ls` for example.

Nincs. Ha FSM kell, akkor talán a rust-fsm-et használnám. Legközelebb talán a label break áll a gotohoz a nyelvben. Persze van ez a szörnyűség is: https://crates.io/crates/goto

Egyelőre nincs. Pedig pár helyen szerettük a goto-t:
  - computed goto ... például gyors token interpretereknél
  - hibaágra való kiugrás

Rust esetén:
  - computed goto nincs, loop-ból break ÉRTÉK; van, bár ez az egyébként frankó megoldás a computed goto-t nem helyettesíti
  - hibaágra ugrás nincs, ? operátor viszont van, ami szintén frankón használható

Nem úgy volt már 30 éve is, hogy komoly programban nincs GOTO?

Talán ezzel az egyel nem értek egyet;  a „mit honnan hívjunk”, az nekem ennél fontosabb szempontok alapján dől el.

Nem írtam semmilyen szempontot. Annyit írtam, hogy ez egy jelzés, hogy talán nem jól van szervezve a kód. Itt jön képbe az a fontos szempont, ami esetleg nem volt figyelembe véve és aszerint kell átalakítani a kódot, ahol már feltehetően nem kell 8 mélységben felfelé mappelgetni a hibát.

és amikor nagyon kell, akkor map-elgetek, de ritkán kell. 

Ezek szerint nálad nem igazán jelent ez problémát, nem jelez, hogy rosszul van szervezve a kód, mivel nem igen kell mappelgetned.

Rust esetén implicit konverzió nincs, olyannyira hogy az f32 (float) és az f64 (double) között sem tudsz közvetlenül műveletet végezni. Előbb mondd meg, hogy melyiket konvertálja melyikké. Tehát például az alábbi hiba nem marad rejtve Rust-ban:

#include <stdio.h>

int main() {
    float oszto = 1./3;

    int eredmeny = 4. / oszto;
    printf("4 / (1/3): %d\n", eredmeny);
}

Ugyanez a példa Rust-ban: https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gi…

A függvények fejlécében kötelező megadni a típust, a visszatérő típust szintén. Az automatikus típusmegállapítás csak függvényen belül játszik, de a fenti példában látjátok, hogy explicit módon bárhol megadható a típus, ahol picit is szükségét érzed (let oszto: f32 = ...).

Olyan hibákra, amik biztos, hogy a fejlesztőnek szólnak, szívfájdalom nélkül pánikolok, a pánik meg tud mutatni stack trace-t.

Kiveve, hogy egy lib-ben nem panik-olhatsz. Egy szerverben sem, mert az nem opcio, hogy egy thread hibaja az egesz szervert magaval rantja.

:D

>Mielott valaki azzal jonne, hogy "mar nem fontos a zero overhead policy", azokrol azok a devek jutnak eszembe, akik nem ertik, mi a jo a C++-ban, es azt sem ertik, hogy miert baj, hogy egy electronos app 10 sec-ig tolt be, aztan megeszik 1.5GB RAM-ot, hogy megjelenitsen egy haromoszlopos tablazatot.

Hát, pedig ha szigorúan nézzük, akkor az electronos appok 99,999%-a C++ban van írva (a Chromium motor ami csomagolva van beléjük), a JS rész hozzájuk inkább egy kitekert konfigfájl csak. :^)

Biztonság terén a malloc és a new között kevés különbség van (oké, a new legalább típusbiztos).  Inkább a shared_ptr-t hoznám, mint előnyt.

... bár arra sokszor nincs szükség, elég lenne unique_ptr, az meg nem másolható, ez néha korlátozó tényező, a move meg C++-ban kicsit nehéz, és nagyon nem biztonságos...  és megérkeztünk a Rusthoz. :)  Mikor használnál dinamikus memóriát?

• Ha futáskor dől el valaminek a mérete vagy elemszáma: vannak konténerek, az alkalmazásnak nem kell dinamikus memóriát kezelnie.
• Ha az A modul inicializál valamit, de B modul fogja tartalmazni: szintén nem kell, move szemantikás a nyelv.

> nem volt neki a new meg delete elegge zero overhead

Amúgy ja, én azzal szoktam találkozni, hogy "a C++ azért lassú, mert mindenféle függvénypointereken keresztül mennek a hívások";

de ugye a) az esetek túlnyomó részében ez mérési hiba alatt van;  b) gondoljunk bele, mikor kell virtulális metódus;  leginkább olyankor, amikor C-ben vagy switch-case-zel válogatnék közöttük, vagy callback-táblázattal, tehát ugyanott vagyunk.

Mondjuk azt sajnálom, hogy C++-ban (még) nincs rendes fordításidejű polimorfizmus, olyankor RTTI-s objektumokat kell csinálni, ha szeretnék közös őst.  C++20-astól jön a concept C++-ba is.