Megérkezett a Rust támogatás a linux-next kernelfába

Címkék

Azok, akik követik a linux-next (az a kernelfa, amelyik a következő kernel beolvasztási időablakába szánt patcheket tartalmazza) változásait, észrevehettek egy jelentős változást: megjelent a kezdeti támogatás ahhoz, hogy a fejlesztők Rust-ban írhassanak eszközmeghajtó-programokat. Ehhez némi dokumentáció is rendelkezésre áll már, míg maga a kód a kernelforrás legfelsőbb szintjén található rust könyvtárban kapott helyet.

Hozzászólások

Új korszak kezdődik.

 

Ha még ehhez hozzáadjuk, hogy eBPF-et is lehet már Rustban írni: https://github.com/ingraind/redbpf és már fejlesztés alatt van az új Rust-ban és eBPF-ben írt konténerizációs megoldás (https://github.com/willfindlay/bpfcontain-rs), akkor szerintem záros határidőn belül a Rust lesz a de facto szabvány a Linux kernel fejlesztésben (nyilván csak új kódrészekre).

nyilván csak új kódrészekre

A Rust közösség imád meglévő programokat újraírni Rustban. Jó eséllyel lesz majd egy mozgalom, hogy minden modulnak legyen egy "-rs" végződésű változata és azon fognak versenyezni, hogy ki tud legelőször Rust-only Linux kernelt fordítani. :)

... kevésbé járatosként könnyű lassabb kódot írni. Szoktam leegyszerűsítve mondani, túl könnyű bárhol vektort allokálni. A malloc() és realloc() esetén jobban elgondolkodtunk.
De lehet C-vel versenyző gyors kódot is írni Rust-ban: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rus…

Egy igazi programozó bármilyen nyelven tud FORTRAN kódot írni. A probléma nem a Rust-tal van, abban is biztos lehet gyors és biztonságos kódot is írni, meg lassút és sechole-osat is. A szűk keresztmetszet meg legtöbb esetben az algoritmus; egy adott problémára adott szar algoritmus akkor is lassabban fog futni a jónál, ha assemblyben írják meg, a jót meg C#-ban. A probléma nem itt van, hanem a hülye ideológiáknál.

Egyfelől azzal a kettős mércével van a baj, hogy a mainstream felfogás szerint a C szar, mert buffer overflow, meg segfault, de ha valaki lekezeli ezeket a C kódban, hogy ne legyen buffer overflow, meg segfault, akkor az hülye, mert felesleges validálni, csak lassulni fog a kód, ugyanakkor, ha a Rust - vagy épp a C++ - nyelvi szinten kezel le egy raklap dolgot, amit C-ben kézzel kell csinálni, az rendben van, az ebből származó lassulás nem számít lassulásnak, mert szükséges, de ugyanez C-ben nem szükséges, a C szar és punktum.
A másik probléma pedig a kényszeresség; ha valaki megír egy új kernelmodult Rust-ban és az rendben teszi a dolgát, a memóriaigény és teljesítmény tekintetében meg nem marad annyival alul a C-vel szemben, hogy sikítozni kelljen tőle, akkor baromira nem számít, hogy Rust-ban írták meg, jól van az úgy, de csak azért újraírni egy már létező és működő kernelmodult, hogy Rust-ban legyen és ne C-ben, az már nettó marhaság.

Én azt látom, hogy a legtöbb esetben nem is az a bajuk az érintetteknek a C-vel, hogy lehet benne buffer overflow-t, meg segfault-ot csinálni - mert azt C++-ban és Rust-ban is lehet, ha nagyon akarja az ember - hanem az, hogy a C régi, tehát szükségszerűen szar és pusztulnia kell, mindegy milyen áron és tök mindegy, hogy amire a C-s kódot cserélik, az tényleg jobb lesz-e, vagy sem és az esetek többségében nem lesz jobb, mert az nem is volt szempont, hogy jobb legyen, csak a régi felszámolása.

Pszeudoprogresszív kényszerforradalom, aminek megint a felhasználók fogják meginni a levét, mert nem az a lényeg, hogy az új jobb legyen, hanem az, hogy a régi pusztuljon.

Néhány alap példa. clang -O2 -Wall ... ahogy a legtöbbünk fordít alapból.

#include <stdio.h>

char *datagen() {
    return NULL;
}

int main() {
    printf("%s\n", datagen());
}

Rust esetén elkülönül az adatcsatorna a hibakezeléstől, nincs NULL pointer állapot:

fn datagen() -> Option<String> {
    None
}

fn main() {
    if let Some(adat) = datagen() {
        println!("{}", adat);
    } else {
        println!("Nincs adat.");
    }
}

És egy másik példa:

#include <stdio.h>
#include <string.h>

struct _teszt {
    char szia[4];
    char miez[4];
} teszt;

struct _teszt *datagen() {
    strcpy(teszt.szia, "szia");
    strcpy(teszt.miez, "MIEZ");
    return &teszt;
}

int main() {
    struct _teszt *t = datagen();
    printf("szia: %s\n", t->szia);
    printf("miez: %s\n", t->miez);
}

Rust esetén szintén nehéz hibázni, nem engedi az ilyesmit.

Egy kis malloc() oda nem figyelés. Sebaj valamelyi másik területre ráírunk. Tipikus codeinjection sérülékenység forrás:

#include <stdio.h>
#include <string.h>
#include <malloc.h>

struct _teszt {
    char szia[4];
    char miez[4];
};

void datagen(struct _teszt *teszt) {
    strcpy(teszt->szia, "szia");
    strcpy(teszt->miez, "MIEZ");
}

int main() {
    struct _teszt *t = malloc(4); // nem kevés?

    datagen(t);
    printf("szia: %s\n", t->szia);
    printf("miez: %s\n", t->miez);
    // aztán a free() elfelejtődik, a memória zabálódik.
}

Szintén C gyöngyszem, clang nem szól, ellenben a kimenet téves eredményt ad:

#include <stdio.h>
#include <string.h>
#include <malloc.h>

struct _teszt {
    char szia[4];
    char miez[4];
};

void datagen(struct _teszt *teszt) {
    strcpy(teszt->szia, "szia");
    strcpy(teszt->miez, "MIEZ");
    // ... pár művelet
    free(teszt); // kis túlbuzgóság a kolléga által elkövetve
}

int main() {
    struct _teszt *t = malloc(4); // nem kevés?

    datagen(t);
    printf("szia: %s\n", t->szia);
    printf("miez: %s\n", t->miez);
}

Ezek kicsiben viccesek, egy több fő által írt nagyobb projekt esetén a hetekig tartó bugvadászat már kevésbé vicces.
A C-t tudni kell uralni. Mindig, hibázás nélkül!

clang -O2 -Wall ... ahogy a legtöbbünk fordít alapból.

Amíg debuggolsz, addig -Weverything jobb, persze mindent az sem szűr ki.

Rust esetén elkülönül az adatcsatorna a hibakezeléstől, nincs NULL pointer állapot:

Már bocs de ennek a Rust kódnak

fn datagen() -> Option {
    None
}

fn main() {
    if let Some(adat) = datagen() {
        println!("{}", adat);
    } else {
        println!("Nincs adat.");
    }
}

ez a C-s megfelelője

#include 

char *datagen() {
    return NULL;
}

int main() {
    char *adat;

    if (adat = datagen())
    {
        printf("%s\n", adat);
    }
    else
    {
        printf("Nincs adat.\n");
    }
}

és nem az, amit te írtál, ez pedig ugyanúgy azt fogja kiírni, hogy nincs adat. Így könnyű ráfogni a C-re, hogy szar, ha direkt kihagyod a hibakezelést, Rust-ban meg belerakod...

Rust esetén szintén nehéz hibázni, nem engedi az ilyesmit.

unsafe esetén se?

Egy kis malloc() oda nem figyelés. Sebaj valamelyi másik területre ráírunk. Tipikus codeinjection sérülékenység forrás:

Az oda nem figyelés is számít? Mert ennyi erővel végy egy 1.20-nál régebbi Rust fordítót, vagy futtasd egy olyan platformon, ahol az LLVM nem támogatja a stack probing-ot, aztán egy kis oda nem figyelés egy rekurziónál és kész a segfault, safe módban is.
Egyébként, amiket írtál, hogy "elfelejtődik" a free(), Valgrind-del ki lehet mérni, hogy mindent felszabadítottál-e.

A C-t tudni kell uralni. Mindig, hibázás nélkül!

Hibázni egyik nyelvben sem lehet, különben bugos lesz a programod. Az meg had ne legyen egy lowlevel nyelv hátránya, hogy tudni kell vele bánni; ennyi erővel az assembly is szar.
Egyébként nem tudom, hogy mit akartál ezzel bizonyítani; ha azt, hogy Rust-ban könnyebb programozni, azt senki sem vitatta, ha meg azt, hogy már tökéletesen működő C kódokat le kéne cserélni Rust-ra, azt meg ezzel nem sikerült.

Csak mert írtad, hogy szól a clang fordító. Hát nem. Simán hagyja megbújni a lekezeletlen NULL pointert, amit a kolléga időprés vagy bármi miatt trehányul taknyolt bele. Ahogy a többi trehányságra sem szól. Az strcpy-t már régen ki kellett volna írtani. Bár az strncpy-vel is csúnya hiba követhető el. A checked-C és safe-C projektek sajnos nem fejlődnek megfelelőképpen, így az sem lesz erre egyelőre igéretes megoldás.

Mindössze ez a baj a C-vel. Próbáld meg Rust esetén a null pointert például időprés miatti trehányság okán elkövetni. Vagy a függvényben eldobni a struktúrát, amivel később a függvényt meghívó program még operál.

Csak mert írtad, hogy szól a clang fordító.

Azt írtam: "a legtöbb buktatóra pl. a CLang fel is hívja a figyelmet."

Az strcpy-t már régen ki kellett volna írtani. Bár az strncpy-vel is csúnya hiba követhető el.

Miért is kellett volna? Látod, erről beszélek. Eszközöket hibáztatnak a C-haterek a kontár programozók helyett. Ki kell írtani a csavarhúzót, mert bele lehet állítani a másik ember szemébe.

Mindössze ez a baj a C-vel.

Nem, ez nem a C-vel baj, hanem a felfogásotokkal. A C egy lowlevel nyelv, ahol kevés a megkötés. Tiltsuk be az assembly-t is, ahol még szabadabban dobálózhatsz a pointerekkel? Nem a lowlevel nyelveket kell kiirtani, hanem meg kéne tanulni bennük programozni, vagy ha az nem megy, akkor meg békénhagyni őket, de csak azért felszámolni valamit, mert egyes emberek nem tudnak vele bánni, az nettó ostobaság. Tiltsuk be a hentesbárdot, a forrasztópákát és a hegedűt is, mert azokhoz is érteni kell, ott is oda kell figyelni, hogy mit csinál az ember és azokkal sem tud mindenki bánni. Miért is kellene elvenni azoktól az eszközeiket, akik tudnak velük bánni?

Próbáld meg Rust esetén a null pointert például időprés miatti trehányság okán elkövetni. Vagy a függvényben eldobni a struktúrát, amivel később a függvényt meghívó program még operál.

Rákérdeztem, de nem válaszoltál: unsafe esetén mi lesz, ha elköveti ezeket az ember?

unsafe { ... } önmagában nem teszi nem biztonságossá az eddig használt funkciókat, mindössze erre a blokkra kikapcsolja a védőhálót és megengedi számodra az olyan metódusok használatát is, aminek nem tudja garantálni a biztonságát.
Alapból ez a kulcsszó kerülendő. Viszont vannak indokolható esetek, ahol elkerülhetetlen kibújnod a védelem alól és saját felelősségre mélyebben alányúlni valaminek.
Innentől egy normális Rust programban kevés és rövid unsafe blokk van, és az is indokolható hogy miért nem lehetett csak a védelemből kilépve megoldani.

Őszinte jótanács: ismerd meg egy picit a Rust nyelvet, írogassál benne programokat és megérted ezeket.

unsafe { ... } önmagában nem teszi nem biztonságossá az eddig használt funkciókat, mindössze erre a blokkra kikapcsolja a védőhálót és megengedi számodra az olyan metódusok használatát is, aminek nem tudja garantálni a biztonságát.

Tudom. És akkor ugyanúgy jöhet a buffer overflow, meg a segfault...

Alapból ez a kulcsszó kerülendő.

Ez megint olyasmi lehet, mint az, hogy a goto az ördögtől való.

Innentől egy normális Rust programban kevés és rövid unsafe blokk van, és az is indokolható hogy miért nem lehetett csak a védelemből kilépve megoldani.

Őszinte jótanács: ismerd meg egy picit a Rust nyelvet, írogassál benne programokat és megérted ezeket.

Miért, szerinted nem láttam még unsafe-et más nyelvben?

"ha meg azt, hogy már tökéletesen működő C kódokat le kéne cserélni Rust-ra, azt meg ezzel nem sikerült."

Remenykedjunk bene hogy Rust communty "csak azert is" megirja gyorsabbra a regi kodokat minden arch/platfromra,
es nem felejt el  C interfacet is exportalni. ;-)

win-win ;-)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

> Már bocs de ennek a Rust kódnak [...]  ez a C-s megfelelője

Nem, nem ez.  Az Option<String> nem típuskompatibilis a String-gel, azaz amikor None, akkor nem látsz rá az adatra.  Csak match-csel tudod kiszedni, vagy "if let"-tel, ami nem egy sima "if", hanem a match másik neve.  Azaz nem tudod nem kezelni a hibát.  Ez ellen így ebben a formában az unsafe sem ad kiskaput.

Múltkor már szkanderoztunk az unsafe-en, :) sajnos nem tudtam jól elmagyarázni.  Talán most.

Ha van egy pl. 50.000 soros kódod, amiből 5 sor unsafe, akkor a fennmaradó 49.995 programsorra a compiler tudja garantálni, hogy nem lesz benne

  • dangling referencia,
  • invalid iterátor,
  • data race condition,
  • inicializálatlan változó, stb.

Ez az, amit nem tud pl. a C, C++.

A warningok sem tudnak ugyanannyit adni, nincs meg C-ben az a fajta kifejezőbb, magasabb szintű leírási lehetőség és szabályrendszer, ami alapján egyértelműen eldönthető lenne, hogy valami korrekt lesz-e, vagy sem. 

+1 arra a gondolatra, hogy - ha van sok időd, - gyakorolj vele kicsit, rá fogsz érezni.

Nem, nem ez. Az Option nem típuskompatibilis a String-gel, azaz amikor None, akkor nem látsz rá az adatra. Csak match-csel tudod kiszedni, vagy "if let"-tel, ami nem egy sima "if", hanem a match másik neve. Azaz nem tudod nem kezelni a hibát. Ez ellen így ebben a formában az unsafe sem ad kiskaput.

Asszem, rossz kódblokkokat néztél, mert ezekben szó nem volt az unsafe-ról. Ott arról volt szó, hogy Rust-ban direkt lekezelte, hogy mit adott vissza a függvény, C-ben meg direkt nem.

data race condition

Egy több magon futó, többthread-es, közös bufferen dolgozó kódban hogy gátolja meg a Rust a data race condition-t úgy, hogy ne nyírja ki az egészet?

Parancsolj:

use std::ffi::CString;

fn datagen() -> CString {
    unsafe
    {
        let p: *mut i8 = 0 as *mut i8;
        CString::from_raw(p)
    }
}

fn main()
{
    unsafe {
        println!("s == {:?}", datagen());
    }
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8408f8cb36752f0135ec70128dafbd4d

És az általad összerakott példán keresztül látod, amiről eddig beszéltünk. Ahhoz, hogy időprés vagy bármi miatt "trehány segfault-os kódot" írjál Rust-ban, nem hogy időt takarítasz meg ahogy a C-nél láttuk, hanem jelentős többletenergiát kell befektetned a "trehánysághoz".

Ajándékként mellékelem letisztázva:

use std::ffi::CString;

fn datagen() -> CString {
    let p: *mut i8 = 0 as *mut i8;
    unsafe { CString::from_raw(p) }
}

fn main() {
    println!("s == {:?}", datagen());
}

A mezei halandó Rust programozó ezért vélhetőleg inkább az alábbit választja a fenti ffi:CString-es bajlódás helyett. Ráadásul időprés esetén is:

fn datagen() -> Option<String> {
    None
}

És igen, ekkor a főprogramban vagy if let Some(x) vagy match segítségével le fogja kezelni. Mert az az egyszerűbb, gyorsabban lekódolható út számára.

Egyúttal ha már így belementünk a rutinos @TCH fórumtárssal: C-ből a NULL pointer állapotra is képes char * -ot vigyük tovább biztonságos Rust függvényként.

Egyszerű C példa, amit Rust-ba akarsz illeszteni. Legyen a neve string_teszt.c és a build.rs által libstring_teszt.a kimenetre fordul a cargo build hatására.

#include <stdio.h>
static char *txt = "Szia";

char *c_string_teszt(int melyik) {
    if (melyik == 1) return txt;
    else return NULL;
}

Rust-ból hogyan viszed tovább biztonságosan a visszatérő adatot vagy NULL pointert tartalmazó C-s char * -ot?

use libc::{c_char, c_int};
use std::ffi::CStr;

#[link(name = "string_teszt", kind = "static")]
extern "C" {
    fn c_string_teszt(a: c_int) -> *const c_char;
}

fn string_teszt<'a>(a: i32) -> Option<&'a str> {
    let c_buf: *const c_char = unsafe { c_string_teszt(a as c_int) };
    if c_buf > 0 as *const c_char {
        let c_str: &CStr = unsafe { CStr::from_ptr(c_buf) };
        let str_slice: &str = c_str.to_str().unwrap();
        // let string: String = str_slice.to_owned(); // ha string kellene
        Some(str_slice)
    } else {
        None
    }
}

Átalakítjuk &str-ré (length, heap_ptr) vagy akár stringgé. Ez a string_teszt() már mint normál Rust függvény hívható és a szokásos if let Some(x) vagy match segítségével nyerhető ki az adat belőle a hibakezelésen keresztül.
Így lesz a C-ből érkező pointerből (odafigyeléssel) biztonságos Option<T>.

Ahhoz, hogy időprés vagy bármi miatt "trehány segfault-os kódot" írjál Rust-ban, nem hogy időt takarítasz meg ahogy a C-nél láttuk, hanem jelentős többletenergiát kell befektetned a "trehánysághoz".

Nem, ez azért került több időbe, mert ez volt az első "programom" Rust-ban. Ha egy trehány programozó évek óta dolgozik benne, akkor semmi extra idő nem kell neki, hogy pár extra unsafe blokkal megfektesse.

Ajándékként mellékelem letisztázva:

Magyarul az a kódsor, ami segfaultot dob, az még csak nem is kell, hogy unsafe legyen, elég, ha az általa felhasznált érték unsafe körülmények között jött létre, azaz egyetlen hibás unsafe sor dominó effektust indíthat, hiába safe a program összes többi része. És egy sornyi elcseszett unsafe még bármelyik trehányabb programozótól kitellik. Ebből is látszik, hogy mennyire fals ez a biztonság.

Nagyon jó észrevétel.
Nem a kódsor maga lesz a segfault kiteljesítője, de abban a kódsorban lett az a védőháló nélküli kontrollálatlan utasítás végrehajtva, ami az egészet előidézi.

Másszóval ez is frankón ... segfault:

fn nemdurran() -> String {
    "Szia .. ez oké.".to_string()
}

fn feldurran() -> String {
    let buf = 0x10 as *mut u8; // jajj
    let len = 100;
    let capacity = 10; // len is nagyobb
    unsafe { String::from_raw_parts(buf, len, capacity) } // ennek a paramétereire kellett volna figyelni
}

fn main() {
    println!("{}", nemdurran());
    println!("Alább fel fog durranni");
    let durr = feldurran();
    println!("Durr ...");
    println!("Ez már nincs: {}", durr); // itt fog eldurranni ... a fenti hibás from_raw_parts() miatt.
}

unsafe { ... } és az általa engedélyezett kontrollálatlan lehetőségeket tényleg csak indokolható esetben (pl. nincs más megoldás) érdemes használni és körültekintően. Az itt kiadott kontrollálatlan utasításokkal semmivel sem vagy előrébb a C-hez képest biztonság terén. Viszont szűkebb részre kell koncentrálni átnézéskor. Unsafe szó szerencsére könnyen kereshető.
Minden egyéb helyen, ahol nem bújik ki a programozó a védelem alól, ott a nyelv védi a programozót, alacsony szintű hibát elkövetni az ilyen kódrészben nehezen tud.

unsafe { ... } és az általa engedélyezett kontrollálatlan lehetőségeket tényleg csak indokolható esetben (pl. nincs más megoldás) érdemes használni és körültekintően. Az itt kiadott kontrollálatlan utasításokkal semmivel sem vagy előrébb a C-hez képest biztonság terén. Viszont szűkebb részre kell koncentrálni átnézéskor. Unsafe szó szerencsére könnyen kereshető.
Minden egyéb helyen, ahol nem bújik ki a programozó a védelem alól, ott a nyelv védi a programozót, alacsony szintű hibát elkövetni az ilyen kódrészben nehezen tud.

Ez ugyan igaz lenne (elméletben, ha feltételezzük, hogy a safe részek valóban biztonságosak, nem futunk bele compiler bugba, stb.) ha a programozó ésszel és körültekintően használná, de itt pont a trehányság volt terítéken. Azaz egy trehány hülye ezt a nyelvet is hanyatt tudja lökni, ha elcseszi a kódot. Maximum azoknak lesz könnyebb dolga, akik utána fognak takarítani. :P

> Asszem, rossz kódblokkokat néztél, mert ezekben szó nem volt az unsafe-ról

Jó kódblokkot néztem, mint az a szövegből is kiderül.  Az unsafe-et csak hangsúlynak tettem hozzá, hogy még az sem érvényteleníti azt a szabályt, miszerint nem kapod meg az adatot, csak ellenőrzés után.

> Egy több magon futó, többthread-es, közös bufferen dolgozó kódban hogy gátolja meg a Rust a data race condition-t úgy, hogy ne nyírja ki az egészet?

  • Szál csak Sync típusú adatra vehet át referenciát.
  • Sync típusú a csak olvasható adat, a Mutex<T> és RwLock<T>, és az atomi műveleteket használó típusok.  De csinálhatsz magadnak egyéb szinkronizációs módszert, ha van ötleted még (lehet).  unsafe-fel természetesen.
  • A Mutexből és RwLock-ból - az Option<T>-hez egészen hasonlóan - nem tudod kivenni az adatot, kizárólag a lock() (Mutex esetén), illetve read() és write() (RwLock esetén) hívás ad rá referenciát.  Ami ráadásul nem is egészen nyers referencia, hanem Guard, ami azt jelenti, hogy kódblokkból kilépéskor elengedi a zárolást.  Ne aggódj, attól még ugyanolyan gyors, mint egy pointer, a standard lib inline deref() metódusokat szokott ilyen helyeken használni.

Hát így.

Kicsit pontosabban:

minden megosztott és írható adat lehetséges hibaforrás, amelyet valahogy kezelni kell.  Ha a megosztás szálak között történik (akár különböző fizikai magokon, akár nem), akkor szinkronizálni kell.  Erre a Rustnak vannak különböző megoldásai.  Mindegyik olyan hatékony ("low level"), amennyire egy rendszerprogramozói nyelvtől elvárható.

Oké, tehát összefoglalva, hogy hogyan véd meg a Rust a threadközi data race condition-től, arra az a válasz, hogy a referenciák esetén egyirányúsítással, az egyéb adatok esetén sehogy, hacsak meg nem írod magadnak. Ez így a gyakorlatban azt jelenti, hogy a Rust valójában nem oldja meg nyelvből/automatikusan a multithreaded data race condition problémáját. Az rendben van, hogy egy referenciát csak olvasni tud, de hogy ír egyszerre több párhuzamos szál egy azonos, globális buffert? Mert eddig nekem az jött át, hogy ugyanúgy szemaforozni kell, mint bármely más nyelvben.

> hogy a referenciák esetén egyirányúsítással, az egyéb adatok esetén sehogy, hacsak meg nem írod magadnak.

Nem.  Referenciák mindenhova kellenek, ahol adatot megosztottan szeretnél elérni (pl. több szálból). (*)

  • Ha a referenciák csak olvasható adatra mutatnak, az megosztható, és ez fordítási időben ellenőrizhető.  Igaz ez úgy is, hogy ha minden referencia csak olvassa (&T), noha az adat maga írható lenne (mut T).
  • Ha az adat írható is, és legalább egyvalaki író referenciát kér róla (&mut T), akkor valamelyik runtime szinkronizálási mechanizmus szükséges.  Mutex, RwLock, atomic, vagy akár saját módszer.

A fentiek közül valamelyiket viszont a fordító megköveteli.  Neki mindegy, hogy melyiket használjuk, akár az elsőt, akár a másodikból bármelyik módszert.

Tehát nem oldja meg magától a problémát, de hajszálpontosan szól, ha én egyik módszerrel sem oldottam meg.

----------------------------

(*) Másik megoldás lenne még a globális változó (itt: "static"), de nem erőlködnék most ezen.  Más nyelveken is ellenjavallt, itt ugyanazon okokból szabályok is korlátozzák a használatát, amelyek hasonlóak referenciás szabályokhoz.

Ebből nekem nem jött le, hogy egyszerre hogy tudnak egy közös globális buffert írni, ha a referenciák ezt kizárhatóvá teszik. BTW, egy közös buffer milyen adat legyen, ha nem globális, ha egyszer egyik szál sem birtokolja? Persze, lehet deklarálni a main-ben is és átadni a szálaknak, de azzal miért volnál beljebb? Ez a globális változó ellenjavallt, ez is olyan lehet, mint, hogy a goto az ördögtől való.

Nézzük sorra.

1.) Lehet, hogy "konkurrens" elérés helyett "fizikailag egy időben"-re gondolsz?  Föltételezek Rólad annyi hátteret, hogy tudod: "fizikailag egy időben" nem lehet, a RAM-nak is egy címbusza, egy adatbusza, kizárólagos vezérlőjelei vannak (gondolom nem dual-port RAM-ról akarsz beszélni, az kissé speciális állat).  Én végig data race condition elkerüléséről írtam.

Ha a konkurrens elérésről a korábbi magyarázataim még részletezésre szorulnak, kérlek, mutass rá a kérdéses mondatomra.  Elképzelhető, hogy Rustban kezdők számára túl tömören írtam.

2.) Az ellenjavallt és az ördögtől való, az két különböző dolog.

3.) A goto-ról: részint ízlése is válogatja, hogy kik mire szoktak jutni, de azt gondolom, hogy a szakmai álláspont:

  • (főleg ANSI) C-ben cleanup-ra pont jól használható (de gcc-ben már van __cleanup__ attribútum)
  • máskülönben ellenjavallt (a kevesebb meglepetést könnyebben megértik a kollégák, kisebb komplexitás => kisebb költség, nagyobb megbízhatóság).

Én biztos nem fogom Neked megtiltani. :)

4.) A globális változóról: ezt sem tilos.  Amikor kell, akkor kell, csak ismerni kell a hátrányait:

  • "lasagne" kódot készítünk, ami a spagettinél egy fokkal rosszabb, mert minden függ mindentől.  Nyerő, ha a komponensek belső konzisztenciája erős, kifele egymástól minél kevésbé függnek, mert annál könnyebb tesztelni és módosítani.
  • data race kockázata ott van, emiatt mint mondtam, Rustban hasonló szabályok vonatkoznak rá, mint referenciákkal megosztott lokális adatra.  Azaz:
    • vagy inicializálás után csak olvasható
    • vagy runtime szinkronizációs módszer kell, de elfelejteni nem tudjuk, kiköveteli a fordító, és ez elég fontos nyeremény
    • vagy minden egyes elérése unsafe blokkos, amit ugye alapvetően nem teszünk, ha a biztonságban kicsit is motiváltak vagyunk.
  • Inicializálás és drop (destruktor):
    • inicializálás csak konstanssal, vagy konstans függvénnyel történhet.  Ugyanis még a main() előtt kell inicializálni, különben egy darabig inicializálatlan lenne, és beleolvashatna akárki (akár egy interrupt handler is, ezt nincs mód ellenőrizni).
    • drop nincs, hasonló okokból, ezzel éljünk együtt.

Nem tiltja a Rust a globális (azaz "static") változó használatát, ha pl. Mutex-be teszed, vagy más szinkronizációs metódusba, esetleg ha csak olvasható (de az ritkán kell).

Főleg akkor vagyunk előrébb a main()-ben (vagy akárhol) lokális, és róla referenciát kérős adattal,

  • cselekedni kell élete végén (Rustban: kell rá drop())
  • vagy dinamikusan kell inicializálni, vagy több globális inicializálása egymástól függ;
  • vagy ha tervezési szempontból kezd aggasztó lenni, hogy mindenki hozzáfér;
  • illetve akkor is, ha nem feltétlenül akarjuk Mutex-be dugni csak azért, mert írni akarjuk.

Az inicializálási problémát a lazy_static!() könyvtári makró is meg tudja oldani (a drop()-ot talán nem oldja meg, nem emlékszem).

Egy bosszantó dolog lehet talán: egyszálú környezetben sem engedi Mutex vagy egyéb szinkronizálás nélkül írni.  Azt hiszem, ez feloldható egy egyszer leírt unsafe trait-tel, de akkor

  • ez ne lib legyen, amit az alkalmazás használhat konkurrensen is,
  • a fejlődése során később se váljon többszálúvá.

A safe módok static változóra tehát elérésenként el fognak füstölni pár órajelet - a szinkronizálás, és opcionálisan a lazy_static miatt.  Ha az 1 MHz-es kontrollert ki kell hajtani padlóig, akkor ne ezt válaszd. :)

A lokális static változókra ugyanez a szigor jut, talán mert egy másik szál is ráláthat arra a függvényre.  És talán ugyanezért hívják static-nak attól függetlenül, hogy globális-e vagy sem.

Lehet, hogy "konkurrens" elérés helyett "fizikailag egy időben"-re gondolsz? Föltételezek Rólad annyi hátteret, hogy tudod: "fizikailag egy időben" nem lehet, a RAM-nak is egy címbusza, egy adatbusza, kizárólagos vezérlőjelei vannak (gondolom nem dual-port RAM-ról akarsz beszélni, az kissé speciális állat). Én végig data race condition elkerüléséről írtam.

Inkább leírom. Van egy buffered, amit a main() allokált és átadja a szálaknak. Van annyi szálad, amennyi CPU magod és ezek ebbe a bufferbe írkálnak. Párhuzamosan. Minden szál ugyanazt a pointert kapta meg (én C-ben gondolkodok, te majd fordítasz Rust-ra), de más-más offsettel dolgoznak és egymás területéhez nem nyúlnak. Ebben a példában hogyan oldja meg a Rust a data race-t? Ha kikényszeríti a szemaforhasználatot, akkor "egyszerre" csak egy thread fér hozzá, a többinek meg kell várnia, egyébként pedig a szálak (azaz a magok) simán írhatják a memóriát "egyszerre", mert nem bántják egymás adatait. (Igen, tudom, hogy a RAM-hoz egyszerre csak egy fér hozzá, nem erről van szó, hanem az egymásra várásról. És nem, direkt nincs split, tudom, hogy ha nincs overlap, akkor fel is lehetne szeletelni a területet több pointerre; elméleti a kérdés.)

Az ellenjavallt és az ördögtől való, az két különböző dolog.

Inkább két külön szintje ugyanannak a dolognak. Ezek eszközök. Nincs olyan, hogy valami generikusan ellenjavallt.

Én biztos nem fogom Neked megtiltani. :)

Oh, köszönöm a kegyet. :)

A globális változóról: ezt sem tilos. Amikor kell, akkor kell, csak ismerni kell a hátrányait:

...

Kösz, hogy leírtad; magyarán ha van egy globális változód és a hozzáférésnél nem "burkolod" szemaforokkal, akkor a Rust beszól érte, azaz kötelezően lassít, akkor is, ha nincs lehetőség ütközésre. Mi a helyzet az 1-eshez adott példával? Az elméletileg nem globális változós, csak a main() által allokált terület van globálisan használva. Csak mert, ha arra ugyanez vonatkozik, akkor belassítja az egész procedúrát.

Rust slice:
   - beugrási pont
   - hossz

Ha van egy vektorod, az könnyedén szétcsapható, bármiféle adatmozgatás nélkül slice-okra.
Az egyes szeletkéket add át az adott thread-nek:
     https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gi…

Ha veszed a fáradságot és megérted az ownership és vele járó dolgokat, akkor egy csomó köd feloszlik. Ez alapján ugyanis sok probléma megoldható, miközben a nyelv overhead nélkül garantál biztonságos programozást.

Egyúttal megjegyzem, az ownership szemlélet szerinti gondolkodás az egyik nevesített rész a nehézségéről híres Rust tanulási görbében. Ha valamit, akkor az ownership szemlélete szerinti gondolkodást tényleg javaslom megismerni.
Ha jól tudom, ma még nincs másik elterjedt nyelv, ami ownership szemléletet követeli, ellenben várható hogy a jövőben létre fognak jönni ezt a szemléletet megkövetelő modern nyelvek. Időközben a Microsoft Verona projektje is ezzel a szemlélettel kezdett bele egy új programozási nyelv kifejlesztésébe.

> más-más offsettel dolgoznak és egymás területéhez nem nyúlnak [...] És nem, direkt nincs split, tudom, hogy ha nincs overlap, akkor fel is lehetne szeletelni a területet több pointerre; elméleti a kérdés.

Ja, így valóban komplexebb kicsit a helyzet.  Az offseteket kiosztó algoritmusod egy futásidőben akármitől is függhet, statikusan nem lehet elemezni.

Lehetőségek:

a) legbiztonságosabb, miközben leghatékonyabb, az az, amit most kizártál: a szálak indulása előtti slice-okra vágás.

b) saját szinkronizációs megoldás, és menet közben osztjuk slice-okra vagy referenciákra.  Pl. legyen egy Buffer objektumod, amitől guard-ok kérhetők le.  A Guard implementálja 1: a Deref trait-et, azaz * operátorral kiadja a mögöttes adatot vagy területet, és 2: a Drop trait-et, azaz destruktort, mert így tudja értesíteni a buffert, hogy már nem nyúlok ehhez a területhez, kioszthatod másnak.

Ez a Buffer kapjon unsafe Sync trait-et, ettől a fordító meg fogja engedni, hogy több szál referáljon a bufferre.  A guard-ok már szálakon belül maradjanak.  Teljesen safe applikációt lehet rá írni, lesz egy rövid és jól tesztelhető Buffer, ami unsafe.  Talán azt is meg tudod tenni, hogy a Buffer ne unsafe {} blokkos legyen, csak a Sync trait menjen rá unsafe módon, azaz az összes többi kérdést még a bufferen belül is ellenőrzi a fordító, csak az átlapolás ellen kell Neked felelősséget vállalni.

c) Az ugye látszik, hogy ha semmilyen szinkronizálást nem csinálsz, akkor minden programnyelvben data race lesz, mert a szálak futási ideje nem determinisztikus.

d) Esetleg - ha nagyon olyan az algoritmusod - arra is lehet számítani, hogy pl. egyenletesen előre mozognak egy körbufferben az offsetek, és elég nagy a távolság közöttük, hogy spórolósabb, de kevésbé biztonságos szinkronizálással menjen.  Ekkor azonban kulcsfontosságú a ráhagyás, ami azt is jelenti, hogy romlik a teljesítmény, azaz a b)-hez képest nem spóroltunk semmit, inkább rontottunk.

legbiztonságosabb, miközben leghatékonyabb, az az, amit most kizártál: a szálak indulása előtti slice-okra vágás.

De itt indokolatlan, mert nincs overlap. Pont azért zártam ki, mert arra vagyok kiváncsi, hogy a Rust behúzza-e a vészféket ott is, ahol nem kell. Itt egy közös memóriaterület (pointer) van, de eltérő munkaszegmensek (offsetekkel).

saját szinkronizációs megoldás, és menet közben osztjuk slice-okra vagy referenciákra. Pl. legyen egy Buffer objektumod, amitől guard-ok kérhetők le. A Guard implementálja 1: a Deref trait-et, azaz * operátorral kiadja a mögöttes adatot vagy területet, és 2: a Drop trait-et, azaz destruktort, mert így tudja értesíteni a buffert, hogy már nem nyúlok ehhez a területhez, kioszthatod másnak.

Ez is indokolatlan. Pont arról beszélek, hogy itt nem szükséges, mert nem fognak ütközni, csak a buffer "alapcíme" közös, de a területek szeparáltak.

Ez a Buffer kapjon unsafe Sync trait-et, ettől a fordító meg fogja engedni, hogy több szál referáljon a bufferre. A guard-ok már szálakon belül maradjanak. Teljesen safe applikációt lehet rá írni, lesz egy rövid és jól tesztelhető Buffer, ami unsafe. Talán azt is meg tudod tenni, hogy a Buffer ne unsafe {} blokkos legyen, csak a Sync trait menjen rá unsafe módon, azaz az összes többi kérdést még a bufferen belül is ellenőrzi a fordító, csak az átlapolás ellen kell Neked felelősséget vállalni.

Tehát ezt csak unsafe módon lehet megoldani lassítás nélkül?

Az ugye látszik, hogy ha semmilyen szinkronizálást nem csinálsz, akkor minden programnyelvben data race lesz, mert a szálak futási ideje nem determinisztikus.

Nyilván, de itt nem ez a kérdés, hanem az, hogy a Rust kikényszeríti-e a szemaforozást/mutexelést/whateverezést egy olyan shared buffer esetén is, ahol ez nem indokolt. Mert eddig a válasz az, hogy igen, kivéve, ha unsafe.

Esetleg - ha nagyon olyan az algoritmusod - arra is lehet számítani, hogy pl. egyenletesen előre mozognak egy körbufferben az offsetek, és elég nagy a távolság közöttük, hogy spórolósabb, de kevésbé biztonságos szinkronizálással menjen. Ekkor azonban kulcsfontosságú a ráhagyás, ami azt is jelenti, hogy romlik a teljesítmény, azaz a b)-hez képest nem spóroltunk semmit, inkább rontottunk.

De még mindig: itt nincs szükség szinkronizálásra.

> > Az ugye látszik, hogy ha semmilyen szinkronizálást nem csinálsz, akkor minden programnyelvben data race lesz, mert a szálak futási ideje nem determinisztikus

> Nyilván, de itt nem ez a kérdés

Elnézést Uram, de akkor minden borul.  Tehát jól értem?  Van egy programod, amelynek szabad hibáznia.  Azt mondod, hogy nincs szükség szinkronizálásra.  Elmondanád, hogy C-ben mitől nem fognak egymásra futni a különböző szálakból használt pointerek?

Szóval azt mondod, cseréljek kereket egy autón úgy, hogy nem ér kereket cserélni?

Ha ezek között szerkezeti okokból sose lehet overlap, akkor lehet slice-olni, ahogy hg2ecz mutatta.

Ha lehet overlap, pl. mert mozognak az offsetek, akkor több szál miatt nemdeterminisztikus az időzítés, azaz futásidőben szinkronizálni kell, Cépluszplusz per á per bé per huszonháromban is, mint minden nyelven.

Elköszönök, van más dolgom is.

Fogadd elismerésem az iránt, amilyen erőbedobással a kedvenc programozói irányaidat és kedvenc programnyelvedet véded.

Olyat lehet Rustban csinálni, hogy tegyük fel, van egy tömb, mondjuk egy float array. És tegyük fel, van egy fv-ed, ami float-ból számol float-ot, de mondjuk ez a fv lassú. Pl., tegyük fel, a cos számítása nagyon lassú. És az, hogy mennyi idő alatt számolja ki a cos-t, az inputfüggő.

És szeretnéd a float arraynak minden elemére kiszámolni a cos-t, több szálon. Méghozzá úgy, hogy legyen egy db. atomic int, ami tartalmazza a következő még-nem-kiszámolt elemnek az indexét. Valami ilyesmire gondolok:

atomic_int index = 0;
const int N = 1000;
float array[N] = { input };

// több ilyen szálat indítunk
void thread() {
  for (;;) {
    int i = index++;
    if (i>=N) break;
    array[i] = cos(array[i]);
  }
}

Tehát itt nem előre határozod meg, hogy az array-t hogyan dobod szét a szálak között (mondjuk 4 szál esetén 0..250, 250..500, 500..750, 750..1000), hanem runtime dől el, hogy melyik elemet éppen melyik szál számolja ki. Azért így, mert mivel a cos idejének kiszámítása inputfüggő, így osztod szét a terhelést a szálak közt automatán.

Nem, nem ezt mondtam. Ne adj dolgokat a számba. Én arra lettem volna kiváncsi, hogy a Rust akkor is megakadályozza egy szemaforozatlan közös változó használatát, ha garantáltan nem történhet ütközés még szemaforok nélkül se.

Anélkül, hogy fel kéne darabolni.

Az offsetek nem mozognak.

Jó munkát.

Köszönöm, csak épp nem a C a kedvenc programnyelvem. Sose volt az. Az a Pascal.

> magyarán ha van egy globális változód és a hozzáférésnél nem "burkolod" szemaforokkal, akkor a Rust beszól érte, azaz kötelezően lassít, akkor is, ha nincs lehetőség ütközésre.

Cserébe jövőbiztos kódot kapsz, amit egy mellélinkelt vagy fejlesztéskor módosított rész képtelen lesz elrontani.  Van az a komplexitás, ahol ez messze-messze megéri.

Mint mondtam, egy egysoros unsafe-fel erről is lebeszélheted, ha akarod, bár ezt rég próbáltam, Rád bízom a keresést, de emlékeim szerint akár még ez is menni fog.

Tied a választás.

De akkor megint ott vagyunk, hogy unsafe, akkor meg nem vagyunk előrébb a C-hez képest. A kérdés az volt, hogy hogyan oldja meg a race kérdését a Rust, úgy, hogy nem nyírja ki az egészet. Ezek szerint az a válasz, hogy sehogy, nyakon fogja vágni és be fogja lassítani egy kikényszerített szinkronizálási metodikával, vagy unsafe módon skippeled a kérdést és akkor ugyanott vagy, mint a Rust nélkül.

A dolog egy picit összetettebb. Általában nem hülyék írják a programokat. Viszont nem olyan tévedhetetlenek, mint sokan kívülállók hisszük (még) magukról. Szerencsére ritkábban, de képesek vagyunk benézni dolgokat.
Általában nem szándékos input struktúra felszabadítás okozza az általad felvetettet, annál inkább a sok allokáció és deallokáció között, netán egyéb benézés okán egy sima eltévesztés.
Ha gépi ellenőrzéshez hasonló tökéletességre lennénk képesek és mi sem tévesztenénk soha, akkor sokkal kevesebb erőforrást kellene allokáció ellenőrzésekre fordítani (bérköltség) és mégsem hízna ennyire az ilyen hibáktól a Common Vulnerabilities and Exposures táblázat.

Kb. ezért hype-olnak mindent, ami legalább ezekre a jelentős, ám a jelek szerint gépiesen jól kivédhető hibákra kínál védőhálót.
Persze ettől még feljebb az algoritmus implementálásnál elcseszhető a szoftver, de legalább erre a rétegre való fokozott odafigyeléssel nem kell a figyelmünket megosztani.

Viszont nem olyan tévedhetetlenek, mint sokan kívülállók hisszük (még) magukról.

Senki épelméjű nem hiszi magáról, hogy tévedhetetlen. A C-hez sem kell tévedhetetlennek lenni.

Kb. ezért hype-olnak mindent, ami legalább ezekre a jelentős, ám a jelek szerint gépiesen jól kivédhető hibákra kínál védőhálót.
Persze ettől még feljebb az algoritmus implementálásnál elcseszhető a szoftver, de legalább erre a rétegre való fokozott odafigyeléssel nem kell a figyelmünket megosztani.

A fokozott odafigyelést nem lehet eldobni, csak azért, mert a nyelv kivédi a memóriakezelési hibákat. Ha ilyen bullshitekkel leépíted az emberek figyelmét, ha fals biztonságérzetet adsz nekik, akkor rosszabb munkát fognak végezni és Rustban is szar kódot fognak írni. A figyelem nem opcionális. Ha valaki Rust-ban is úgy figyel, mint C-ben tenné, na az lehet, hogy jobban fogja elsőre megírni a programot, mert azt a két apróságot, amit C-ben elcseszett volna, azt a Rust megfogta. De ha valaki úgy dolgozik Rust-ban, hogy leszarja mit csinál, mert majd megfogja a nyelv, na az nem lesz vicces.
Egyébként sem csak memóriakezelési hibák vannak; egy trágya algoritmust a Rust sem fog az ember helyett jóra megírni.

Ha ilyen bullshitekkel leépíted az emberek figyelmét, ha fals biztonságérzetet adsz nekik, akkor rosszabb munkát fognak végezni és Rustban is szar kódot fognak írni.

Vagy épp jobb minőségű kódok fognak létrejönni, mert nem kell erre is vesztegetni a figyelmet, hanem a többi problémás dologra jobban oda lehet figyelni?

Szalmabáb-izélsz. Nem arról volt szó, hogy lehessen-e egyáltalán memóriát kezelni, hanem hogy ha már van ilyen lehetőség egy programnyelvben, akkor legyen-e egy beépített automata "biztonsági háló" azon hibák megfogására, amik az RCE sebezhetőségek jelentős részét okozták. Továbbra se láttam a topikban egyetlen épkézláb érvet amellett, hogy miért ne kéne egy ilyen beépített védelmet használni, ha az "ingyen" van.

Szalmabáb-izélsz.

Én?

Továbbra se láttam a topikban egyetlen épkézláb érvet amellett, hogy miért ne kéne egy ilyen beépített védelmet használni, ha az "ingyen" van.

Inkább te izéled a szalmabábot, ugyanis én ilyet nem mondtam, hogy ne legyen beépített védelem. Én azt mondtam, hogy a nyelv nem tud megvédeni mindentől. Én csupán arra hívtam fel a figyelmet, hogy kettős mércét alkalmaznak a C-haterek és nem szakmai megalapozottságból utálják a C-t, hanem ideológiából. Ugyanis...

Nem arról volt szó, hogy lehessen-e egyáltalán memóriát kezelni

...de, pontosan erről volt szó, hogy írjuk újra mindjárt az egész Linux kernelt Rust-ban, mert a C szar, mert buffer overflow, meg segfault. Az, hogy Rust-ban is van buffer overflow, meg segfault az nem baj. Az, hogy ezeket C-ben le lehet kezelni, az tilos (ill. hülyeség). Az, hogy a szar algoritmust semmilyen nyelv nem fogja ellensúlyozni, az megint nem számít, a C akkor is szar, mert csak.
Nem arról van szó, hogy a Rust ne lenne használható, vagy, hogy baj, hogy van benne védelem (ami egyébként opcionális, kikapcsolható az unsafe-fel), hanem arról, hogy a "marketingje" kontraproduktív, hogy ez a nyelv azért jó, mert nem kell odafigyelni. De. Oda kell. Akármiben írod, oda kell figyelni. A memóriakezelés automatizálása nem jelent automatikusan jobb kódminőséget. Erre próbáltam az előző posztomban célozni. A jobb kódminőség mindig a programozó függvénye és nem a nyelvé.

Ha Rustban lehet ugyanolyan jellegű kódot írni, mint C-ben, és plusz még megfogja a memóriakezeléssel kapcsolatos hibák nagy részét (és más jellegű hibákat is), akkor mégis mi a gond?

Szerintem teljesen egyértelmű, hogy emiatt automatikusan jobb lesz a kódminőség. Nem garantálja a kódminőséget, de valamivel jobb lesz.

És amúgy igen, a C ebben a tekintetben konkrétan szar. Emögött nem ideológia, meg C haterkedés van, hanem ez tény. 2021-ben kb. nincs semmi értelme C-t használni, ha nem muszáj. Már a Rust előtt is volt alternatíva a C++ személyében, csak ugye Linus irracionális okok miatt nem szereti. A Rust nemtom mennyire alternatíva most, de egyértelműen abba az irányba megy, hogy az legyen.

Az pedig, hogy van a Rustban unsafe, nem érv. Nem teszed a teljes kódodat unsafe-be, hanem csak azt a részt, amit muszáj. A kód maradék részén pedig fordítási időben ki fognak jönni olyan hibák, amik C-ben runtime jönnek ki, általában random hibák és sechole-ok formájában. Teljesen egyértelmű érv a Rust mellett. Nem arról van szó, hogy a buffer overflow-t tilos lekezelni C-ben. Hanem arról, hogy a Rust neked alapból megfogja az ilyen hibát, így nincs mit lekezelned. C-ben meg elfelejtheted lekezelni. A compiler lehet nem fogja meg az összes ilyen hibát, de ha már megfogja a 90%-t, akkor van értelme, nem? Ha 10x kevesebb buffer overflow-val kapcsolatos sechole lesz, akkor az egy jó dolog.

És amúgy lenne értelme újraírni a kernel bizonyos részeit (vagy akár az egészet) Rustban. Szerintem kiderülhetnek az átírás közben meglévő hibák, sechole-ok. Az más kérdés, hogy vajon ezt az erőfeszítést érdemes-e megtenni, és nem lenne-e jobb valami más produktívabb dologba fektetni inkább a munkát.

Ha Rustban lehet ugyanolyan jellegű kódot írni, mint C-ben, és plusz még megfogja a memóriakezeléssel kapcsolatos hibák nagy részét (és más jellegű hibákat is), akkor mégis mi a gond?

Az erőltetés és a bagatellizálás; a nyelv nem old meg mindent helyettünk.

Szerintem teljesen egyértelmű, hogy emiatt automatikusan jobb lesz a kódminőség. Nem garantálja a kódminőséget, de valamivel jobb lesz.

Mitől lenne? Ha a programozó trehány, azon a nyelv nem segít. Ezt látjuk a PHP-nál, a JS-nél, a Pythonnál és a Java-nál is... Egyikben sem kell a manuális memóriakezeléssel foglalkozni, aztán mégis mennyire gány kódok születnek ezekben. (Java-ban konkrétan olyan leakelős kódokat szoktak produkálni, hogy elfolynak a GB-ok, holott az is manage-elt.)

És amúgy igen, a C ebben a tekintetben konkrétan szar.

Nem, a C az nem szar, hanem egyszerű, mint egy faék és megengedő. Pont amilyennek egy lowlevel nyelvnek lennie kell.

Emögött nem ideológia, meg C haterkedés van, hanem ez tény.

Ez minden, csak nem tény. Hogy nálad nem ideológia van mögötte, az egy dolog, de a legtöbb embernél azt látom, hogy a C-t azért utálja, mert nem a haladó informatikai eszmék része, azaz nem divatos, meg nem áll mögötte valamelyik bálványozott techcég, mint a Rust mögött a Mozilla, vagy a C# mögött a microsoft...

2021-ben kb. nincs semmi értelme C-t használni, ha nem muszáj.

Muszáj...semmit sem muszáj, de értelme miért ne lenne? Mibe írja meg az ember pl. egy mikrokontroller vezérlését, ahol csak memóriacímeket kell szinte piszkálni, a C++ feature-jei közül semmit sem használna? Hiába fordítod a C++ fordítóval, valójában C kódot írtál, mert a supersetből semmit nem használtál.

Már a Rust előtt is volt alternatíva a C++ személyében, csak ugye Linus irracionális okok miatt nem szereti.

Nem biztos, hogy annyira irracionális okok miatt. Nem biztos, hogy a nyelvet nem szereti, csak lehet, hogy látta mire képesek a C nyelvvel azok, akik nem tudják használni és nem szeretné, ha a kernelben felszaporodna az olyan OOP kódok mennyisége, amit olyan programozók írtak, akik az OOP-pal sem tudnak bánni, mert az még rosszabb lenne. Az OOP-ot is varázslatként kezelték sokáig, hogy az majd mindent megold, aztán az esetek többségében csak több problémát generált, mint amit megoldott...de ez sem az OOP hibája, hanem azoké, akik úgy használták, hogy nem tudták használni. És ez vonatkozik a C-re is.

Az pedig, hogy van a Rustban unsafe, nem érv. Nem teszed a teljes kódodat unsafe-be, hanem csak azt a részt, amit muszáj.

Ez a kettős mérce. A nyelv lehetővé teszi, tehát ugyanúgy meg lehet benne csinálni ezeket a memóriakezelési hibákat (főleg mivel pont az a rész lesz unsafe-be rakva, amit muszáj, mert az nyúlkál kétes helyekre), hovatovább, pl. stack overflow esetén továbbra is segfaultot dob a nyelv, ha nincs stack probing és ehhez nem kell unsafe. Persze a C kódot meg direkt úgy írjuk meg, hogy még a hibakezelést is kidobjuk belőle és akkor szar a C.

A kód maradék részén pedig fordítási időben ki fognak jönni olyan hibák, amik C-ben runtime jönnek ki, általában random hibák és sechole-ok formájában. Teljesen egyértelmű érv a Rust mellett.

Ez konkrétan akár bármelyik managelt nyelv mellett lehetne érv, de ha pancser írja a kódot, az minden nyelvben szar kódot fog írni.

Nem arról van szó, hogy a buffer overflow-t tilos lekezelni C-ben.

Nem tilos, csak épp le van hülyézve érte az ember, amikor meg példakódot kell írni, hogy miért szar a C, akkor abból meg direkt ki van hagyva, mert fő az egyenlő bánásmód. No comment.

Hanem arról, hogy a Rust neked alapból megfogja az ilyen hibát, így nincs mit lekezelned.

Nem, nem fogja meg mindet. Egy részét fogja meg. Mondtam példát rá, csak az valahogy elsikkadt, de nem baj, megint leírtam.

C-ben meg elfelejtheted lekezelni.

El. És ha én elfelejtem lekezelni, az a nyelv hibája és nem az enyém? Ha annyi eszem van, hogy a ráspolyt a forró tűzhely mellé teszem le és amikor megint felveszem, megéget, akkor az a ráspoly hibája, mert fémből van? A programozó hibája nem a nyelv hibája.

A compiler lehet nem fogja meg az összes ilyen hibát, de ha már megfogja a 90%-t, akkor van értelme, nem? Ha 10x kevesebb buffer overflow-val kapcsolatos sechole lesz, akkor az egy jó dolog.

Azt senki nem mondta, hogy nincs értelme, vagy nem jó dolog, hogy van. De nem véd meg mindentől. Ezeket a számokat sem tudom, hogy mire alapozod.

És amúgy lenne értelme újraírni a kernel bizonyos részeit (vagy akár az egészet) Rustban. Szerintem kiderülhetnek az átírás közben meglévő hibák, sechole-ok.

Csak akkor, ha tényleg nyerünk vele valamit. Ha egy harminc ismert sechole-lal büszkélkedhető C kódot újraírtak Rust-ban és redukálták a sechole-ok számát háromra, a teljesítményveszteség meg 5% volt, a plusz memóriaigény meg 32 kB, akkor nyertünk vele és megérte. De ha a kód tökéletesen tette a dolgát, akkor teljesen értelmetlen volt átírni, csak azért, hogy Rust-ban legyen. Erről beszéltem: ez az ideológia.

Most nem reagálok minden részletre külön-külön. Ez az álláspontom: nyilván nem old meg minden programozó hibát a Rust, hanem pár gyakori hibát segít elkerülni. Ennyi. Ettől még maradhat egy csomó más hiba is a programban, lehet teljesen szar egy Rustban írt program, egy rossz programozó ugyanúgy rossz kódot fog benne írni, stb. Ha ezt a gondolatot megérted, akkor szerintem a hozzászólásod egy részére felesleges reagálnom, mert egyértelmű mit mondanék rá. Szerintem ebben a dologban nem gondolunk mást.

A C rossz ("szar") ebben a tekintetben pl. a Rust-tal összehasonlítva. A Rust is low-level, mégis jobban kezeli ezt a dolgot. És leakelni se tud úgy, mint a java, hogy ottfelejtesz egy referenciát valahol, és a fél világ bent marad a memóriában miatta. Ha más nyelv megoldja a biztonságos memóriahasználatot, miközben a performance alig veszik el, akkor a C rosszabb ebben a tekintetben. Ami nem is csoda, hiszen egy teljesen más korból származik, amikor még az is újdonság volt, hogy van nem int és nem pointer típusú változó. Bár mondjuk hasonlóan régi a lisp, ott nincsen ilyen jellegű probléma. De persze az teljesen más tészta.

C-hater vs. ideológia: leszarom, melyik tech mögött mi van. :) Pusztán tényeken alapulva mondom azt, amit mondok. A rustot se ismerem amúgy nagyon mélyen, egyelőre még kivárok vele, hogy jobban kiforrja magát, és akkor talán komolyabban ránézek.

C++ vs Linus: a kritikájának egy része teljes butaság. Az OOP-s, "mindenhova absztrakciót teszek" gondolatvilágtól való félelem valós, ez érthető. De ettől függetlenül lehet szabályokat hozni, hogy mit lehet, és mit nem. Szinte minden helyen a C++-nak csak egy adott subsetjét használják. Egyszerűen ultragáz pl., hogy a kernelben egy csomó mindent soksok soros makrókkal oldanak meg, amire mondjuk a C++ rendes megoldást ad template-ek formájában. A pointer access-ekre is lehet wrapper osztályt csinálni, amik aztán debugban tudják ellenőrizni a validságot, és nem kell napokig keresni valami memória túlírás okát. Stbstb. Ettől még lehet C logikával programozni C++-ban is.  A C++-t bárhol lehet használni, ahol a C-t. De jó, azt elfogadom, hogyha valami fél bites mikrocontrollerre kell valamit csinálni, akkor oda jó a C is. De ugyanúgy jó a C++ is, csak max. nem használod a feature-eit. De ha meg mégis kell valami, akkor meg ott van. Szerintem tökmind, hogy melyik fordítót hívja meg az ember.

Azt értsd meg, hogy nem az van, hogy a "hibakezelést kidobjuk belőle". Hanem az, hogy nem tud egy programozó minden esetre felkészülni. Vagy ha tud, akkor sokkal lassabban fog haladni. Ha valamit automatizálni lehet, akkor miért ne tegyük meg? Szerintem az egyetlen ellenérv, ami elfogadható ebben az esetben az az, hogy valami más hátránya van a Rust megoldásának. Pl. performance csökkenés. És ezt el is fogadom. Ha valami perf. szenzitív helyen a Rust odatesz felesleges ellenőrzéseket valahova, akkor oda mehet az unsafe. És akkor észnél kell lenni, hogy pontosan mi kerül az unsafe blokkba. Viszont mindenhol máshol meg nem kell emiatt aggódni.

Segfault: de épp magad mondod, hogyha nincs stack probing, akkor van gáz. És ha van? Szóval ez nem a nyelvnek a sajátossága, hogy esetleg a stack overflowt rosszul kezeli, hanem implementációs kérdés. A dolog megoldható, hogy a stack mérete folyamatosan ellenőrizve legyen. Más esetben is lehet segfault? Amúgy el bírom képzelni, hogy igen, pl. többszálú programokkal nemtom mit csinál a rust, hogyan kezeli a race conditionokat.

"amikor meg példakódot kell írni, hogy miért szar a C, akkor abból meg direkt ki van hagyva, mert fő az egyenlő bánásmód.": Jó, érted, ott pont az volt demonstrálva (ha a NULL ptres példára gondolsz), hogy a Rust szól neked compile-time, ha valamit elfelejtesz. A C meg nem szól. Minden programozó követ el hibákat, szóval jobb, ha a fordító tud szólni róla, minthogy runtime derül ki. Szóval nem volt az rossz példa egyáltalán. De amúgy jobb lenne, ha a Rustot inkább a C++-szal hasonlítanának össze. Mert ugye ott van std::optional (jé, még a neve is majdnem ugyanaz, mint Rustban!), ami ugyanúgy tud szólni.

"Ezeket a számokat sem tudom, hogy mire alapozod.". Hasamra ütöttem. De igaziból szerintem a számoknak még ennél is jobbnak kellene lennie a Rust javára. Ha unsafe-et csak indokolt esetben használsz, akkor a leírt memóriahozzáférések 99%-a ellenőrizve lesz (hasraütés). Tehát sokkal kissebb az esélye egy buffer overwrite-on alapuló sechole-nak.

"De ha a kód tökéletesen tette a dolgát, akkor teljesen értelmetlen volt átírni, csak azért, hogy Rust-ban legyen. Erről beszéltem: ez az ideológia.". Igen, de nem tudhatod, hogy egy kód biztonságosan teszi a dolgát. Nyilván működik, teszi a dolgát, OK. De hogy tutira nincs benne buffer overwrite? Hát az nem biztos.

Megértem, hogy nem tetszik az a jelenség, hogy sokan csak azért hype-olják a Rustot (vagy bármit), mert új, meg trendi. De azért van technikai oka is a hype-nak.

Szerintem ebben a dologban nem gondolunk mást.

Ebben nem. Én pontosan ezt mondtam eddig is. Még mindig nem a Rust ellen ágálok, hanem a C-hating ellen. Nagyon is megvan a létjogosultsága annak a nyelvnek.

A C rossz ("szar") ebben a tekintetben pl. a Rust-tal összehasonlítva. A Rust is low-level, mégis jobban kezeli ezt a dolgot.

A Rust mióta lowlevel? Meg mitől? Egy nyelv, ami a C tudásának a sokszorosát adja?

Ha más nyelv megoldja a biztonságos memóriahasználatot, miközben a performance alig veszik el, akkor a C rosszabb ebben a tekintetben.

Ha. Ezért lesz érdemes figyelni a sebességet, ha nekiállnak kernelmodulokat írkálni. Egy triviális probléma lehet, hogy 3%-kal lassab Rust-ban, meg 6 kB-tal több, miközben sokkal gyorsabban megvolt és safe. De mi lesz egy komplex problémával, amihez a Rust magas szintű nyelvi elemeire lesz szükség? (OOP és a többiek.) Ha használod őket, akkor a performance fokozatosan a C javára tolódik el, hiszen minél több extra mechanizmus és absztrakció kerül a kódodba, az annál több rétegcsillapítást fog rárakni. Ha meg átmész unsafe módba és megírod, mint ha C-ben tennéd, akkor lehet, hogy megint csak pár százalék meg kB a C előnye, de akkor pontosan mivel is vagyunk beljebb a C-nél, ha nem használtuk ki a Rust-ot?

Bár mondjuk hasonlóan régi a lisp, ott nincsen ilyen jellegű probléma. De persze az teljesen más tészta.

Az. Lévén az egy magas szintű nyelv, tehát nem lehet összehasonlítani a C-vel, hiába idősebb vagy 10 évvel a C-nél.

C-hater vs. ideológia: leszarom, melyik tech mögött mi van. :) Pusztán tényeken alapulva mondom azt, amit mondok.

Te lehet. De sokan meg nem. Sokan csak a trendeket, meg az épp kikiáltott vezérürüt követik.

A rustot se ismerem amúgy nagyon mélyen, egyelőre még kivárok vele, hogy jobban kiforrja magát, és akkor talán komolyabban ránézek.

Ezzel én is így vagyok. Addig C meg Pascal. :P (Mondjuk ezekről utána sem fogok leszokni, max akkor már Rust kódot is fogok írni. :P )

De ettől függetlenül lehet szabályokat hozni, hogy mit lehet, és mit nem.

Lehetni lehet, csak látod, ha fel meri emelni a hangját valami baromság ellen, akkor már "továbbképzésre" küldik, mert megint nem volt elég "befogadó".

Egyszerűen ultragáz pl., hogy a kernelben egy csomó mindent soksok soros makrókkal oldanak meg, amire mondjuk a C++ rendes megoldást ad template-ek formájában.

A Linux kernelben elég sok ultragáz dolog van már így is és nem a C miatt. Azt kell itt látni, hogy a Linux régen túlnőtt azon, hogy hobbi legyen a kockáknak, ma már komoly iparág épül rá és ennek megfelelően érdekek is fűződnek a Linux erre vagy arra történő terelésének. Az intel konkrétan hátsóajtót akart építeni a Linux véletlenszámgenerátorába (RDRAND) és csak Ted Ts'o éleslátásán múlt, hogy nem sikerült, amiért az intel strómanjai meg is próbálták mindenféle rágalommal kitúrni a projektből. De nem lehet minden beszivárgást elhárítani. Csoda, hogy Linus paranoiás és nem akarja, hogy a bevett módszereken mindenféle reformerek változtassanak? Ki tudja miféle érdekek mentén akarnak reformálni.

A pointer access-ekre is lehet wrapper osztályt csinálni, amik aztán debugban tudják ellenőrizni a validságot, és nem kell napokig keresni valami memória túlírás okát.

Ezt mondjuk pont C-ben is pár sorból meg lehet oldani, csak nem osztállyal. :P

Ettől még lehet C logikával programozni C++-ban is. A C++-t bárhol lehet használni, ahol a C-t. De jó, azt elfogadom, hogyha valami fél bites mikrocontrollerre kell valamit csinálni, akkor oda jó a C is. De ugyanúgy jó a C++ is, csak max. nem használod a feature-eit. De ha meg mégis kell valami, akkor meg ott van. Szerintem tökmind, hogy melyik fordítót hívja meg az ember.

Ezt lentebb is kiveséztük: mindegy melyiket hívod meg, de ha a C++ dolgaiból semmit sem használsz, ha a C fordító is le bírná fordítani, akkor hiába fordítottad a C++ fordítóval, az C kód maradt.

Ha valamit automatizálni lehet, akkor miért ne tegyük meg? Szerintem az egyetlen ellenérv, ami elfogadható ebben az esetben az az, hogy valami más hátránya van a Rust megoldásának. Pl. performance csökkenés. És ezt el is fogadom.

Meg mernék esküdni rá, hogy ezzel nyitottam, hogy majd érdemes lesz figyelni a sebességet...
Egyébként a performance csak az egyik probléma. A compiler-bug a másik. Hogy a védelmi mechanizmus amit belefordít, hibásan működik. A fordítót is lehet javítani persze, de ha arra várni kell, akkor az baj. Főleg, ha nem javítják azonnal, csak sok verzióval később. És ilyen előfordul, ld. a Rust 1.20 előtti stack overflow == segfault problémát. A Rust 2010-ben jött ki, az 1.20 meg 2017-ben. 7 évig ez a védelmi mechanizmus bugos volt, azaz hamis biztonságérzetet adott a felhasználóknak.

Ha valami perf. szenzitív helyen a Rust odatesz felesleges ellenőrzéseket valahova, akkor oda mehet az unsafe. És akkor észnél kell lenni, hogy pontosan mi kerül az unsafe blokkba. Viszont mindenhol máshol meg nem kell emiatt aggódni.

Ez az elmélet. A gyakorlatban meg a programozó, aki az ominózus teljesítményérzékeny részt C-ben elcseszné, az el fogja cseszni Rust-ban is, unsafe módban.

Segfault: de épp magad mondod, hogyha nincs stack probing, akkor van gáz. És ha van? Szóval ez nem a nyelvnek a sajátossága, hogy esetleg a stack overflowt rosszul kezeli, hanem implementációs kérdés.

Lehet, hogy nem nyelvi sajátosság, de ez a végeredmény szempontjából irreleváns, mert a végeredmény ekvivalens.

Más esetben is lehet segfault?

Biztos. Nem másztam bele annyira.

Amúgy el bírom képzelni, hogy igen, pl. többszálú programokkal nemtom mit csinál a rust, hogyan kezeli a race conditionokat.

Lentebb (?) írta Kiskübi, hogy lekezeli, de el nem tudom képzelni, ha van egy sokszálú, több magon futó, közös bufferrel dolgozó program, ott hogy fogják a data race-t preventálni fordítóból, úgy, hogy az ne ölje le az egészet.

A C meg nem szól. Minden programozó követ el hibákat, szóval jobb, ha a fordító tud szólni róla, minthogy runtime derül ki.

Pontosítsunk: a fordító nem szólt, mert amúgy szólhatna, annyi féle warningot raktak már bele, ez sem lenne lehetetlen.

De amúgy jobb lenne, ha a Rustot inkább a C++-szal hasonlítanának össze. Mert ugye ott van std::optional (jé, még a neve is majdnem ugyanaz, mint Rustban!), ami ugyanúgy tud szólni.

Ebben egyetértünk. Én nem is értem, hogy miért mindig szerencsétlen C-vel mérik össze ezeket a magas szintű nyelveket. Totál másra valóak. A C egy hordozható assembly. Ez a fő ereje és létjogosultsága, hogy a CPU-k és az OS-ek 99.99999%-án (hasraütöttem én is) elérhető, ennél hordozhatóbb nyelv nincs. A DragonFlyBSD-sek öt évet vártak vele, mire lett Rust-jük, de még mindig gáz van a Rust-os UNIX API-val alatta... És ez még csak nem is valami 9 nanobites mikrokontroller, hanem egy x86-on futó UNIX.

Hasamra ütöttem. De igaziból szerintem a számoknak még ennél is jobbnak kellene lennie a Rust javára. Ha unsafe-et csak indokolt esetben használsz, akkor a leírt memóriahozzáférések 99%-a ellenőrizve lesz (hasraütés). Tehát sokkal kissebb az esélye egy buffer overwrite-on alapuló sechole-nak.

És megint oda jutottunk, hogy ugyan az az állítás, hogy ennél a nyelvnél nem kell annyira észnél lenni, mint C-nél, ugyanakkor feltételezed, hogy a programozó észnél van és csak indokolt esetben használ unsafe-et és azt is ésszel...ez a kettő így ellentmond egymásnak. És a mai programozókat ismerve sajnos nem lesznek észnél.

Igen, de nem tudhatod, hogy egy kód biztonságosan teszi a dolgát. Nyilván működik, teszi a dolgát, OK. De hogy tutira nincs benne buffer overwrite? Hát az nem biztos.

Nem biztos, de következtetni lehet. Egy éves a modul és eddig tíz sechole volt benne? Akkor majdnem biztos, hogy van még. Lehet próbálkozni a Rust-tal. Tíz éves és még egy sechole sem volt benne? Akkor valószínűleg nincs is, vagy annyira konvulens módon lehetne kicsikarni belőle, hogy sose fogják megtalálni. Ide felesleges a Rust.

Megértem, hogy nem tetszik az a jelenség, hogy sokan csak azért hype-olják a Rustot (vagy bármit), mert új, meg trendi. De azért van technikai oka is a hype-nak.

Leírtam az elején, hogy nem a Rust-tal van a bajom. Biztos van technológiai indoklás is a hype mögött, de az valószínűleg a Rust userek kisebb hányadát érdekli, a többség megint csak a trend után megy...és hogyhogy nem, a trend már megint arra megy, hogy a C-t ircsákki, de legalábbis a Linux kernelt írják újra végre valami másban, ami nem régi (== szar), hanem valami modern, trendy és haladó. Ez közönséges gyűlölködés, ami nem csak kontraproduktív, de indokolatlan is. Mint mondtam a C legfőbb létjogosultsága a hordozhatósága, hogy bárhova viszem, ha az API különbségek le vannak kezelve, akkor fordítható lesz és az egyszerűsége, hogy azt csinálja, amit mondok neki, mint egy assembler. Ezt összehasonlítani a Rust-tal...hát mondhatni felesleges.
Egyébként, ha hordozhatóság; ha Rust részek lesznek a Linux kernelben, akkor azokat hogy forgatják le azokon a platformokon, ahol nincs Rust fordító?

Igen ... amióta leírtam, azóta gondolkozom azon, hogy az LLVM / CLANG-hoz kötöttem. Pedig  C nem csak ott van, amire a CLANG fordít.
Rust másik gyengéje még: egyetlen implementáció van gyakorlatilag (többi mögötte kullog) és amire fordít, arra van. Szerencsére szép a paletta:

  $ rustc --print target-list

     vagy weben: https://doc.rust-lang.org/stable/rustc/platform-support.html

Mondjuk C esetén is volt a GCC (ma már van CLANG is) és voltak a kevésbé fejlett C fordítók (meg néhány zárt, ami operációs rendszerhez kötött).

Pedig C nem csak ott van, amire a CLANG fordít.

Hát nem. C majdnem mindenre van. OS-re és CPU-ra is. (intel 4004-re, meg TMS-1000-esre még nem láttam, de lehet, hogy én voltam vak.)

Szerencsére szép a paletta:

Akkor ezek szerint Rust kb. van az x86-os windows/macOS/Linux mainstream triumvirátusra és ARM64-os Linuxra "élesben", ahol minden működik és további 149 platformra "kísérleti jelleggel", amiből 77 elméletileg - azaz talán - működik, 72 pedig még elméletileg se, bár kizárni nem lehet. Mondjuk a paletta nem tartalmaz mindent, pl. a 8-bites CPU-kat, pedig tudom, hogy pl. Z80-ra, ha megkötésekkel is, de van Rust.
Noha vannak ennél régebbi nyelvek, amiknek a palettája sehol sincs ehhez képest, azért gondolom belátod, hogy a C-hez képest meg ez nincsen sehol sem. Ha a Linux kernelt átírják Rust-ba, akkor az fordulni fog i686-on, AMD64-en és ARM64-en, a többin talán vagy talán se. A Linux, aminek pont az volt a lényege, hogy szinte mindenhova fordul, hirtelen csak a két mainstream architektúrára fog?

Nu, szerintem nagy vonalakban egyetértünk (valszeg kezdetektől fogva, mert az álláspontom nem változott, és valszeg a tiéd se), szóval azokra a dolgokra, amikre már reagáltam, meg elmondtam a véleményem inkább már nem reagálok.

A Rust mióta lowlevel? Meg mitől? Egy nyelv, ami a C tudásának a sokszorosát adja?

Ez ugye lehet definíciós vita... Számomra nem attól low level egy nyelv, hogy keveset tud. Hanem hogy mi a célja, mire lehet használni, milyen eszközök vannak hozzá. Szerintem a Rust simán teljesíti azokat a követelményeket, hogy low levelnek lehessen hívni. Gépi kódra fordul, simán lehet kb. sejteni, hogy milyen Rust kódból kb. milyen jellegű gépi kód lesz (nyilván nem mindenre igaz ez, de nagy vonalakban), stb. Kernelben, embeddedre, stb. lehet használni komolyabb overhead nélkül.

mivel is vagyunk beljebb a C-nél, ha nem használtuk ki a Rust-ot?

Azzal, hogy alapból biztonságosabb a nyelv. Meg egy csomó dolgot könnyeben lehet benne megcsinálni, gondolom (remélem). Ennyi. Értem, hogy Rustban is el lehet cseszni a dolgokat, stb. De mégis kisebb az esély rá, mint a C-ben. C++-ban is lehet úgy programozni, hogy "köszönöm szépen, a sok absztrakcióból nem kérek", és még így is jobb, mint a C. De amúgy azért még azt is érdemes figyelembe venni, hogy a Rust még új nyelv (C, C++-hoz képest mindenképpen), szóval kell idő neki, hogy kiforrja magát.

A compiler-bug a másik

Igen, ez benne van a pakliban sajnos.

Ezt mondjuk pont C-ben is pár sorból meg lehet oldani, csak nem osztállyal. :P

És vajon mennyire lehet könnyen használni? C++-ban meg lehet oldani úgy, hogy nem is látszik belőle semmi. Nem tudok róla, C-ben is lehetséges volna ilyet csinálni. És az, hogy ezt C++-ban meg lehet valósítani "észrevétlenül" nem a károsabb fajta absztrakció, mivel csak debugban fordulna pointer checkelősre, release-ben ugyanúgy ott van a szokásos raw pointer, szóval az átláthatóságot, a designt nem érinti egyáltalán.

Pontosítsunk: a fordító nem szólt, mert amúgy szólhatna, annyi féle warningot raktak már bele, ez sem lenne lehetetlen.

Nem igazán látom, hogy bizonyos speciális eseteket kivéve mégis hogyan szólhatna a fordító. Teljesen egyértelműen jobb a Rust megközelítése, szóval erről szerintem nincs nagyon értelme vitázni. Bocs, hogy ilyet mondok, de tényleg... Ha rendes nyelvi elem van az ilyesmire, akkor az garantálja az ilyen jellegű hibának a teljes kiküszöbölését. Míg C esetben ha szerencséd van, akkor a fordító dob egy warningot az esetek egy részére. A static analyzerek se vesznek észre egy csomó ilyesmit, nemhogy a fordító.

programozó észnél van és csak indokolt esetben használ unsafe-et és azt is ésszel

Azért feltételezek bizonyos dolgokat egy programozóról. Nem kell hozzá nagy ész, hogy ne szórd tele a programodat unsafe-fel. Ha még a program 50%-a unsafe mode-ban is megy, akkor is ott a másik 50%, ami meg biztonságos. Durván számolva akkor fele akkora a hibázás lehetősége. Szerintem akik olyan programokat írnak, ahol számít a biztonság, azért vannak egy szinten. Nyilván nem mindenki, de a nagy része igen. Nem azzal kezdik a projectet, hogy az egészet körbeteszik egy nagy unsafe-fel. Bár gondolom ilyet nem is lehet csinálni :)

Tíz éves és még egy sechole sem volt benne? Akkor valószínűleg nincs is

Ezzel nem értek egyet. Simán lehet bármilyen idős kódban sechole. Igen, ha valami régi, akkor több esély volt kiderülnie, hogy sechole van benne, de messze nem garancia. Magam is talátam hibát olyan fv-ben, ami több, mint 20 éves volt (opensource cuccban, amit ezernyi helyen használnak, konkrétan az strtod() kódjában). Nem sechole volt, egy nagyon apró hiba, de akkor is hiba. Az ember azt gondolná, hogy az ilyen alap rutinok azért már tökéletesen jól működnek.

akkor azokat hogy forgatják le azokon a platformokon, ahol nincs Rust fordító

Ha van is ilyen elterjedt platform, szerintem előbb-utóbb azon is lesz Rust.

Számomra nem attól low level egy nyelv, hogy keveset tud.

Számomra sem, rosszul fejeztem ki magam. Attól lowlevel, hogy kevés absztrakciót és automatizációt pakol a kódba. Attól lowlevel, hogy mennyire manuális, mennyivel csinál meg több dolgot, mint amit direktbe kértél. A C szinte semmit sem csinál meg. A Rust pedig nagyon is sokat.

Azzal, hogy alapból biztonságosabb a nyelv. Meg egy csomó dolgot könnyeben lehet benne megcsinálni, gondolom (remélem). Ennyi. Értem, hogy Rustban is el lehet cseszni a dolgokat, stb. De mégis kisebb az esély rá, mint a C-ben.

Valamikor a Java-ra is hasonlóakat mondtak, aztán a Java-s kódok még a C-s kódokat is überelték memóriaproblémák és sebezhetőségek terén. Oké, hogy a Rust nem a Java (hálistennek), de nagyon hasonlóak a lózungok; a Java-ban is megmagyarázták, hogy miért is van kierőltetve a kivételkezelés és az OOP, aminek aztán az lett az eredménye, hogy mindenkinek a töke tele lett vele és a kötelező köröket a kódban lefutották, a többit meg leszarták, az eredményt ismerjük. Lehet, hogy a Rust fejlesztői tanultak ebből, de ki tudja még, mi lesz ebből az új felállásból? Nyelvek és paradigmák jöttek és mentek, a C maradt. A C++ sem váltotta le, hanem kiegészítette és most mellette létezik, nem helyette.
Egyébként, hogy könnyebben lehetne Rust-ban dolgokat megcsinálni? Hát kétlem. Ebben a nyelvben már fordító szinten annyi gátló mechanizmus van, hogy mire kitapasztalod, hogy egyáltalán mit lehet benne, szakállad nő. Addigra nemhogy C++-ban, de még C-ben is megírtad volna. Úgy, hogy odafigyeltél és nem raktál bele sechole-okat.

C++-ban is lehet úgy programozni, hogy "köszönöm szépen, a sok absztrakcióból nem kérek", és még így is jobb, mint a C.

És a legtöbben sajnos úgy is programoznak, nem csak C++-ban, de szinte mindenben.

De amúgy azért még azt is érdemes figyelembe venni, hogy a Rust még új nyelv (C, C++-hoz képest mindenképpen), szóval kell idő neki, hogy kiforrja magát.

Oké, de akkor miért tartanak máris ott, hogy írjuk újra a Linux kernelt benne?

És vajon mennyire lehet könnyen használni?

Semennyire, körülményes lenne, mint szinte minden C-ben, de megoldható.

Nem igazán látom, hogy bizonyos speciális eseteket kivéve mégis hogyan szólhatna a fordító.

Miért, Rust-nál hogyan akadályoz meg benne? Heurisztikus analízissel, csak itt nem meggátólna benne, hanem warningot dobna, ha kérnéd fordításkor ezt az opciót. (Mondjuk C-ben is van olyanra lehetőség, hogy minden warning error legyen.)

Teljesen egyértelműen jobb a Rust megközelítése, szóval erről szerintem nincs nagyon értelme vitázni. Bocs, hogy ilyet mondok, de tényleg...

Magadat fosztod meg a vitapartner gondolataitól, nem engem. :)
Egyébként pont azt magyaráztam, hogy a Rust ezen megközelítése egyáltalán nem kizárólagos, simán átvehető. C-be is, C++-ba is, máshova is.

Nem kell hozzá nagy ész, hogy ne szórd tele a programodat unsafe-fel.

Valóban nem, de ahhoz sem kellett túl nagy ész, hogy ne szórja tele az ember OOP-vel, aztán mégis teleszórták.

Ha még a program 50%-a unsafe mode-ban is megy, akkor is ott a másik 50%, ami meg biztonságos. Durván számolva akkor fele akkora a hibázás lehetősége.

Biztos? hg2ecz fentebb adott egy példát, ahol a kódnak mindössze 11.56%-a unsafe és mégis segfaultot dob, ráadásul a segfaultoló sor safe módban van, vagyis a safe mód is simán dönthető, ha a felhasznált adatai unsafe körülmények közt jöttek létre, azaz hiába biztonságos a program nagy része, egyetlen elcseszett unsafe is láncreakciót indíthat el, azaz az unsafe és safe blokkok aránya nem korrelál lineárisan a biztonsággal.

Nem azzal kezdik a projectet, hogy az egészet körbeteszik egy nagy unsafe-fel. Bár gondolom ilyet nem is lehet csinálni :)

Biztos lesz olyan gyökér, aki ilyet csinál majd, de nem erre gondoltam. :P

Ezzel nem értek egyet. Simán lehet bármilyen idős kódban sechole. Igen, ha valami régi, akkor több esély volt kiderülnie, hogy sechole van benne, de messze nem garancia. Magam is talátam hibát olyan fv-ben, ami több, mint 20 éves volt (opensource cuccban, amit ezernyi helyen használnak, konkrétan az strtod() kódjában). Nem sechole volt, egy nagyon apró hiba, de akkor is hiba. Az ember azt gondolná, hogy az ilyen alap rutinok azért már tökéletesen jól működnek.

Bocsánat, ha egy kódban 20 év alatt egy hibát találnak, az jó kód és nem kell újraírni. 20 év alatt egyetlen hibajavítás az (majdnem) semmi. Ha újraírják, ki tudja, akkor mennyi hibát raknak bele.

Ha van is ilyen elterjedt platform, szerintem előbb-utóbb azon is lesz Rust.

És ha nem elterjedt? A niche platformokkal mi lesz? Nem csak a mainstream x86/ARM-windows/macOS/Linux van... Még OpenBSD-re sincs rendes Rust fordító, csak Tier 3-as támogatású.

Nem igazán értem, miért nem megy át neked az a gondolat, hogy a Rust bizonyos hibákat tud jobban kiszűrni, mint a C. Ha ezt megérted, akkor nem hoznád ide a java-t, amiben nyilvánvalóan nem lehet olyan bugot elkövetni, hogy a memóriát felülírod. Vagy ha esetleg valami nyakatekert módon mégis, akkor se az a jellemző. Már többször leírtam, de leírom még egyszer: a Rust egy biztonságosabb nyelv, mint a C, mert egy csomó hibalehetőségtől megvéd fordítási időben, és futási időben is több dolgot ellenőriz. Vagy inkább mondjuk úgy, hogy ellenőriz futási időben dolgokat. Mivel a C ugye nem ellenőriz semmit. Ennyi. Nem kell idehozni a java-t, hogy abban is lehet sechole-t csinálni, meg hogy az unsafe miatt meg lehet kerülni a védelmi mechanizmust, vagy hogy a Rust compilerben is lehet hiba, stb.stb. Nem arről van szó, hogy minden hibától megvéd. Hanem arról, hogy a hibák valószínűsége kisebb.

 

Oké, de akkor miért tartanak máris ott, hogy írjuk újra a Linux kernelt benne?

Mert lehet, hogy használható már ilyesmire. Ki kell próbálni, aztán kiderül. Mindenki azt csinál a szabadidejében vagy épp munkaként, amit akar.

 

Miért, Rust-nál hogyan akadályoz meg benne?

Te komolyan nem látod a különbséget a között, hogy egy fv. simán visszatér egy bármilyen pointerrel, és talán, ha szerencséd van, akkor kapsz valami warningot, és a között, hogy visszajön egy optional, amit fordítási időben csekkolni kell, és ha esetleg elrontod a kódrészt, akkor is maximum egy prediktálható runtime error lesz belőle? Ne már...

Rust ezen megközelítése egyáltalán nem kizárólagos, simán átvehető. C-be is, C++-ba is, máshova is.

C++-ba igen, sőt egy csomó dolog hasonlóan megy, mint a Rustban. C-be is átviheted a koncepciót, de valami undormány szar kód lesz belőle, ami 3x akkora lesz, mint kéne neki. Valszeg makrókkal teletüzdelve.

Biztos? hg2ecz fentebb adott egy példát, ahol a kódnak mindössze 11.56%-a unsafe és mégis segfaultot dob, ráadásul a segfaultoló sor safe módban van

Igen, nagy általánosságban biztos. Ez egy ellenpélda, ami persze megtörténhet a valóságban is simán. De ez csak egy változó lesz a sok közül, aminek az értéke rossz lesz. Ami szerencsés esetben hamar segfaultot okoz. Ha nem, akkor igen, más változók értékét is elronthatja, ez igaz. De ha a hibát kijavítod, akkor van egy jól működő programod. És nem az van, hogy a programban még bárhol lehet ilyen jellegű hiba. A dolog pofonegyszerű: csak az unsafe blokkokat kell jól átnézni ilyen jellegű hibák után kutatva, a maradék kód biztonságos. Tényleg nem értem, hogy mi ellen érvelsz tulajdonképp. Hogy nincs semmi értelme az unsafe-nek? Hogyha van egy unsafe blokk a programban, onnétól kezdve teljesen ugyanaz a helyzet, mintha az egész program unsafe lenne? Vagy mit akarsz mondani pontosan?

 

Bocsánat, ha egy kódban 20 év alatt egy hibát találnak,

Én találtam benne egyet. De amúgy meg egy csomó más hiba is volt benne az elmúlt sok évben.

És ha nem elterjedt?

Akkor azon lehet nem lesz Rust. A Rustnak nem biztos, hogy az a célja, hogy minden platformon lecserélje a C-t. Ha az elterjedtebb platformokon megteszi, akkor már egy hasznos dolog lehet.

Nem igazán értem, miért nem megy át neked az a gondolat, hogy a Rust bizonyos hibákat tud jobban kiszűrni, mint a C. Ha ezt megérted, akkor nem hoznád ide a java-t, amiben nyilvánvalóan nem lehet olyan bugot elkövetni, hogy a memóriát felülírod. Vagy ha esetleg valami nyakatekert módon mégis, akkor se az a jellemző.

Pedig átjött, a Java-t a trendek analógiája miatt hoztam ide; a világmegváltó új nyelvek kapcsán. Java-ban pedig nagyon is jellemző a memóriakezelési bug; kinyitom a keresőt, keresek Java-s segfault és memory leak eseteket, lesz bőven.

Már többször leírtam, de leírom még egyszer: a Rust egy biztonságosabb nyelv, mint a C, mert egy csomó hibalehetőségtől megvéd fordítási időben, és futási időben is több dolgot ellenőriz. Vagy inkább mondjuk úgy, hogy ellenőriz futási időben dolgokat. Mivel a C ugye nem ellenőriz semmit. Ennyi. Nem kell idehozni a java-t, hogy abban is lehet sechole-t csinálni, meg hogy az unsafe miatt meg lehet kerülni a védelmi mechanizmust, vagy hogy a Rust compilerben is lehet hiba, stb.stb. Nem arről van szó, hogy minden hibától megvéd. Hanem arról, hogy a hibák valószínűsége kisebb.

Ez rendben van. Az viszont nem lesz rendben, ha nekiállnak a többségre ráerőltetni az egészet. Nem lesz rendben, hogy a hátrányokat figyelmen kívül hagyva nekiállnak a fontos szoftvereket átírni ebbe. A Java-val és a C#-pal is mentek hasonló dolgok pár éve, a Java volt a legnépszerűbb nyelv, nem is egyszer.

Mindenki azt csinál a szabadidejében vagy épp munkaként, amit akar.

Amíg másnak nem okoz kárt, addig igen. Ha otthon maguknak átírják Rust-ba és lassabb lesz, vagy nem fog N architektúrán fordulni, az az ő dolguk. Ha utána ezt rákényszerítik Torvaldsra és az egész Linux világra, az már nem az ő dolguk.

Te komolyan nem látod a különbséget a között, hogy egy fv. simán visszatér egy bármilyen pointerrel, és talán, ha szerencséd van, akkor kapsz valami warningot, és a között, hogy visszajön egy optional, amit fordítási időben csekkolni kell, és ha esetleg elrontod a kódrészt, akkor is maximum egy prediktálható runtime error lesz belőle? Ne már...

Valamit félreértettél. Ez egy retorikai kérdés volt és rögtön meg is válaszoltam utána, hogy analizálja a kódot.

C++-ba igen, sőt egy csomó dolog hasonlóan megy, mint a Rustban. C-be is átviheted a koncepciót, de valami undormány szar kód lesz belőle, ami 3x akkora lesz, mint kéne neki. Valszeg makrókkal teletüzdelve.

Te itt valamit nagyon félreértettél. Én arról beszéltem, hogy ahogy a Rust fordításidőben analízis útján kiszúr egy csomó hibát és leállítja a fordítást, azt meg lehet csinálni C-ben is, hogy ha bekapcsolod a kódanalízist, akkor a C fordító ugyanezekre a hibákra kiszór egy csomó warningot. Vagy errort, ha azt kéred.

A dolog pofonegyszerű: csak az unsafe blokkokat kell jól átnézni ilyen jellegű hibák után kutatva, a maradék kód biztonságos.

Elméletileg, hacsak nem futsz bele egy compiler bugba.

Tényleg nem értem, hogy mi ellen érvelsz tulajdonképp.

A C-hating ellen és a mainstream erőltetése ellen, még mindig.

Vagy mit akarsz mondani pontosan?

Azt, hogy tökéletes védelem nem létezik, a hülyék ellen pláne nem, hát ne próbáljuk már meg megint kiirtani a megengedő nyelveket a hülyék miatt.

Én találtam benne egyet. De amúgy meg egy csomó más hiba is volt benne az elmúlt sok évben.

Ez nem érvényteleníti azt amit mondtam: ha egy kódban 20 év alatt egy hibát találnak, az jó kód, amit nem kell lecserélni.

Akkor azon lehet nem lesz Rust. A Rustnak nem biztos, hogy az a célja, hogy minden platformon lecserélje a C-t. Ha az elterjedtebb platformokon megteszi, akkor már egy hasznos dolog lehet.

De ha lecserélik a Linux kernel kódját Rust-ban írtra, akkor ezeken a platformokon többé Linux sem lesz.

Valamit félreértettél. Ez egy retorikai kérdés volt és rögtön meg is válaszoltam utána, hogy analizálja a kódot.

Bocs, valóban, de nem teljesen. Itt nem kódanalízisről van szó, hanem arról, hogy a típusszabályok miatt le se fog fordulni a kód. A rustos példában option jön vissza, amit kezelni kell. Tehát, nehezebb hibázni, nehezebb benézni azt, hogy nullptr-t deref-elsz. De ha be is nézed, akkor is szét runtime error lesz (gondolom).

A C-hating ellen és a mainstream erőltetése ellen, még mindig.

Ok, akkor ez tiszta :)

Ez nem érvényteleníti azt amit mondtam: ha egy kódban 20 év alatt egy hibát találnak, az jó kód

Egyetérek

amit nem kell lecserélni

Ezzel viszont nem feltétlenül. Ha a biztonságra törekedünk, akkor megérheti lecserélni. Még az is lehet amúgy, hogy lesz (vagy már van) valami tool, ami képes lesz C kódot áttenni Rustba. A Rust-ra portolás felfogható akár egy nagy code review-nak is, csak review közben át is írod a kódot egy másik nyelvre. Mondjuk Rust esetében ez lehet nem triviális a borrow checker miatt. De ha rá vagy kényszerülve, hogy átgondold az egészet emiatt, akkor lehet megéri

Ha már néhány hozzászólással feljebb a példakód kapcsán meg lettem említve: fontos Rust esetén, hogy ha valahol eldobjuk a védőhálót ( unsafe ) és ténylegesen alányúlunk, azzal addig nincs baj, amíg erre az alányúlásra teljes körültekintéssel mi magunk (vagy lelkiismeretes kolléga, netán Rust felhasználói közösség) odafigyelünk.

Aztán az élet és az oda nem figyelés esetei:

  - trehány kolléga kódját használjuk ( ... amiben persze akad pár unsafe { .. } )
  - crates.io --> közösségi könyvtárból veszünk ki más által összetákolt kódot (itt a 'cargo check' is fontos segítség lett mára, de ez sem mindenható)
  - random GitHUB oldalról rántjuk alá vadidegen által tákolt "tutijó" varázslatot

Amíg az látszik, hogy dejó hogy pár nap alatt elkészültél, addig tapsvihar és "milyen ügyes volt a cég".
Aztán ha az ilyen "ajándékba lemásolt varázslatból" jön a bug, akkor hogy lehettél TE ilyen hülye, hogy nem nézted át (a nem létező több hét alatt), amit külső modulokat felhasználtál.
A kettős mérce. Ez a rész sajnos ugyanúgy játszik.

Tehát itt is lényeges, hogy az unsafe környezetbeli alányúlásokat teljes körültekintéssel kell elvégezni a felhasznált modulokban is. Ellenkező esetben hiába biztonságos (safe) végig az általad írt, de azokat a modulokat hivogató kód. Ahogy már fentebb le lett írva, a felhasznált kódoknál is legalább az unsafe szavakra érdemes valakinek rákeresni és ezeknek a részeknek átnézni, ellenőrizni az esetleges kockázatait.

Itt nem kódanalízisről van szó, hanem arról, hogy a típusszabályok miatt le se fog fordulni a kód. A rustos példában option jön vissza, amit kezelni kell. Tehát, nehezebb hibázni, nehezebb benézni azt, hogy nullptr-t deref-elsz. De ha be is nézed, akkor is szét runtime error lesz (gondolom).

Ettől még a C fordító végezhet valamilyen szintű analízist, ami kiszűri az ilyen hibák egy részét.

Ha a biztonságra törekedünk, akkor megérheti lecserélni.

Egy olyan kódot, amiben 20 év alatt zéró biztonsági hibát találtak?

Még az is lehet amúgy, hogy lesz (vagy már van) valami tool, ami képes lesz C kódot áttenni Rustba. A Rust-ra portolás felfogható akár egy nagy code review-nak is, csak review közben át is írod a kódot egy másik nyelvre. Mondjuk Rust esetében ez lehet nem triviális a borrow checker miatt. De ha rá vagy kényszerülve, hogy átgondold az egészet emiatt, akkor lehet megéri

Miért érné meg? Az csak spekuláció, hogy biztonságosabb lesz, gyorsabb nem lesz, maximum lassabb se, hordozhatóbb meg pláne nem lesz...

Ettől még a C fordító végezhet valamilyen szintű analízist, ami kiszűri az ilyen hibák egy részét.
 

Igen. De ettől még a C-s megoldás rosszabb, mint a Rustos. A Rust garantál, a C-s verziónál meg bizhatsz valamiben, ami egyébként egyértelműen nem tudja kiszűrni az ilyen hibák nagy részét. Erre mondtam azt egyik korábbi hozzászólásomban, hogy egyáltalán nem értem, miért nem megy ez át neked (többször nem fogom leírni), és hogy erről nincs értelme vitázni, mert egyértelműen jobb a Rustos megközelítés.

Egy olyan kódot, amiben 20 év alatt zéró biztonsági hibát találtak?

Igen, mert ettől még lehet benne. Nem azt mondom, hogy mindig van értelme, és hogy egyértelműen meg kell tenni, de nem látok semmi kivetnivalót abban, ha valahol ezt megteszik. Ha be tudja teljesíteni azt (nagyon) hosszú távon, hogy ne legyenek buffer overrunos és egyéb ilyen jellegű hibák (vagy jelentősen csökkenjen le a számuk), akkor megéri. Én inkább pont azt mondom, hogy full gáz, hogy biztonságra szánt dolgok egy jelentős része 2021-ben még mindig C-ben van írva. Szóval abszolúte egy jó lépés hosszútávon, hogy a C-t lecseréljük valami másra.

Miért érné meg? Az csak spekuláció, hogy biztonságosabb lesz, gyorsabb nem lesz, maximum lassabb se, hordozhatóbb meg pláne nem lesz...

Viszont egy eléggé logikus spekuláció, hogy biztonságosabb a Rust, elég erős érvek vannak e mellett, amik már elhangzottak korábban, nem ismételném meg.

 

 

 

Erre mondtam azt egyik korábbi hozzászólásomban, hogy egyáltalán nem értem, miért nem megy ez át neked (többször nem fogom leírni), és hogy erről nincs értelme vitázni, mert egyértelműen jobb a Rustos megközelítés.

Nem is kell többször leírni, egyrészt mert elsőre is átjött, másrészt meg nem fogsz tudni meggyőzni, mert maximum egyes embereknek jobb. A Rust-ot úgy találták ki, hogy minden vackot meggátol, akkor is, ha nem feltétlen indokolt. Én meg nem szeretem, ha a szerszám akadályoz a munkában.

Szóval abszolúte egy jó lépés hosszútávon, hogy a C-t lecseréljük valami másra.

Helyes, cseréljük le Pascal-ra, az is biztonságosabb. :P

Viszont egy eléggé logikus spekuláció, hogy biztonságosabb a Rust, elég erős érvek vannak e mellett, amik már elhangzottak korábban, nem ismételném meg.

Ezt is felesleges megismételni, mert az én szememben itt 0 vs. 0 biztonsági rés felállás van; az, hogy valami C-ben van írva, az még nem ekvivalens azzal, hogy rögtön ementáli, amiben húsz év alatt sem fogtak bugot, azt nyugodtan lehet biztonságosnak tekinteni; azzal a spekulációval indokolni az újraírást, hogy C-ben van, tehát elméletileg lehet, hogy sechole van benne, az ugyanaz a szint, hogy a Rust verzióban meg van öt blokknyi unsafe, tehát elméletileg lehet, hogy sechole van benne.

Nem is kell többször leírni, egyrészt mert elsőre is átjött, másrészt meg nem fogsz tudni meggyőzni, mert maximum egyes embereknek jobb.

Jó, akkor nem túráztatom magam rajta. Ha ilyen érvet mondasz, mint amit itt írsz, ez már más. Nyilván lehet, hogy valaki nem akar a Rustnak a merevségével szívni. Ebben egyetértek. Én leginkább a biztonságosságáról beszéltem eddig, és nem a teljes képről, hogy ez vajon milyen áron valósul meg. Bár mondjuk az alap példa, amiből a beszélgetésnek ez a része kialakult, nem tartalmaz semmiféle merevséget. A Rust megoldása (C-s ptr, ami null lehet / vs Rust option) szerintem nem okoz akkora nagy fájdalmat. Szóval őszintén szólva szerintem ez a konkrét példa minden szempontból azt mutatja hogy a Rust jobban kezeli az esetet, komolyabb hátrány nélkül.

Ezt is felesleges megismételni...

Jó, hát akkor ebben nem fogunk egyetérteni, ennyi. Te nem látod a különbséget a között, hogy egy C kódban bárhol lehet ilyen jellegű hiba, a Rustos verzióban meg csak az unsafe blokkokban, amik valszeg a teljes kódbázis 0.1%-nál is kisebb részét teszik ki. Ez van, elengedtem a témát.

Te nem látod a különbséget a között, hogy egy C kódban bárhol lehet ilyen jellegű hiba, a Rustos verzióban meg csak az unsafe blokkokban, amik valszeg a teljes kódbázis 0.1%-nál is kisebb részét teszik ki.

Egyrészt, de látom, másrészt meg ez nem feltétlenül igaz, mert egyrészt előfordulhat compiler bug is, másfelől meg ott van fentebb az élő példa, hogy egy unsafe rész hibája a safe részig eszkalálódott és a safe rész volt, ami összedőlt.

Igen, lehet compiler bug. De az nem invalidálja az egész koncepciót. Most az, hogy volt egyszer egy bug, amit éveken keresztül nem vettek észre... előfordul. Ha lesz több ilyen is, akkor is csak azt fogom mondani, hogy előfordul. Az előnyökhöz képest ez elhanyagolható. És valszeg nem is azt jelentette, hogy akkor az összes Rustban fordított program olyanná vált hirtelen, mintha C-ben írták volna. Valszeg az ellenőrzések 99.99%-a ugyanúgy lefutott, compile time kiszűrte a hibákat ettől függetlenül is. Ne vitatkozzunk már ilyen 0.01%-okról. Senki se állította, hogy ezután minden tökéletes lesz. Hanem az az állítás, hogy jelentősen biztonságosabb lesz a program. Az, hogy egy unsafe blokkban hiba van, és kihat a teljes programra, nem számít. Ha hibát keresel, akkor csak az unsafe blokkokat kell átnézned. Nem a teljes programot. Tökre nem vágom, hogy ezt miért nem fogadod el. Hanem hozol mindenféle jelentéktelen ellenérvet, hogy de ha így, de ha úgy, akkor ez meg ez van. Igen. De az alapkoncepciót ezek az érvek nem változtatják meg. Simán lehet, hogy lesznek a jövőben olyan sechole-ok, amik pont egy unsafe blokk hibáját használják ki. De mivel a program <0.1% unsafe, pl. validálni a programot sokkal egyszerűbb, mert nem kell az egészet átnézni. Ezernyi olyan sechole volt az elmúlt években, amit a Rust nem engedett volna. Már ennyinek elégnek kellene lennie, hogy belásd, hogy a Rust biztonságosabb.

Ha érvelni akarsz, akkor mondj olyan érvet, ami azt mondja, hogy ez a koncepció nem működik, és a Rust nem biztonságosabb, mint a C. Ha pedig elfogadod, hogy a Rust biztonságosabb, mint a C, akkor készen is vagyunk, mivel kezdetektől fogva mindössze ennyi volt az állítás.

Most az, hogy volt egyszer egy bug, amit éveken keresztül nem vettek észre... előfordul. Ha lesz több ilyen is, akkor is csak azt fogom mondani, hogy előfordul. Az előnyökhöz képest ez elhanyagolható.

Szóval elhanyagolható. Tehát, ha a C kódban 20 évig nem találtak sechole-t, akkor az attól függetlenül is lehet, hogy sechole-os és újra kell írni Rust-ban, de ha a Rust compilerben 7 évig nem javítanak egy stack-crash-t, az nem baj. (Egyébként nem egyszer fordult ehhez hasonló elő, lehet többet is találni.)

Az, hogy egy unsafe blokkban hiba van, és kihat a teljes programra, nem számít. Ha hibát keresel, akkor csak az unsafe blokkokat kell átnézned. Nem a teljes programot. Tökre nem vágom, hogy ezt miért nem fogadod el. Hanem hozol mindenféle jelentéktelen ellenérvet, hogy de ha így, de ha úgy, akkor ez meg ez van. Igen. De az alapkoncepciót ezek az érvek nem változtatják meg.

Azt írtad, hogy "A sebességgel és mérettel viszont (szokás szerint) nem értek egyet. Rajtad, a programozón múlik, hogy hogyan használod. Nem a nyelv fogja meghatározni, hogy milyen sebességgel fog menni, ill., hogy mekkora lesz a kód."
Fordítsuk ezt meg: nem a nyelv fogja meghatározni, hogy mennyire lesz biztonságos a kész program. Egy hozzáértő a C-vel sokkal biztonságosabb programot fog csinálni, mint egy balfácán a Rust-tal. Persze mondhatod, hogy a hozzáértő a Rust-tal viszont még biztonságosabbat...csak épp balfácánból lesz a több. Alant a linkek, hogy már jönnek az 1:1 C->unsafe Rust programkonverziók. Ott is csak az unsafe blokkokat kell átnézni a hibák után, csak ott az egész unsafe lesz. Ebben a formában így mit is értünk el, azon túl, hogy megszabadultunk a C-től? Semmi biztosíték nincs arra sem, hogy majd a gyökerek nem fogják behajítani az egész kódot egy unsafe alá, amikor megunják, hogy a Rust nem fordít le semmit, amit írnak, viszont szentül hiszik, hogy a nyelv megvédi őket saját maguktól. Már megint a nyelv akarja megvédeni a balfácánokat saját maguktól, de azért mindjárt erőltessük rá mindenkire is az egész koncepciót, azokra is, akik nem saját magukat lövik lábon sem a C-vel, sem mással, mert tudják, hogy mit csinálnak. Nem tud egy ember mindenre felkészülni, hiába ért hozzá? Tény. A Rust írói sem tudnak minden eszement barom minden eszement baromságára felkészülni. Ez is tény.
Innentől kezdve viszont az alapkoncepció is megváltozik, hiszen arról volt szó, hogy ez majd biztonságos lesz, megvéd mindentől, de ez a a biztonság nagyon is látszólagos, mert a hülyék ellen nincs biztos védelem. Nem is lesz soha.
Mi lesz ennek a végeredménye? Az, hogy a hülyék miután átnyergeltek Rust-ra, sokkal több lyukas Rust kódot fognak produkálni, mint amennyi lyukas C kód van.

Ha pedig elfogadod, hogy a Rust biztonságosabb, mint a C, akkor készen is vagyunk, mivel kezdetektől fogva mindössze ennyi volt az állítás.

Csakhogy az állítás nem csupán ennyi volt, mert ha csak ennyi lett volna, már régen nem vitatkoznánk. Olyan állítások is elhangzottak, hogy mi mindent kéne erre a nyelve átírni, mert az biztos sokkal jobb lesz, csak éppen nem biztos, de azért írjuk át, hátha. Utánunk a vízözön módra. Három-négy éve a rustc még nem tudta magát lefordítani 32-bites x86-on, mert felzabálta a memóriát, nem volt neki elég ami a 32-bitbe belefért. Nem tudom, hogy ezt fixálták-e már, de ha nem és erre kéne átírni a Linux kernelt, akkor hogy fog a szintén brutális méretű forrással bíró Linux kernel lefordulni 32-bites gépeken?
Aztán, mert ezt még senki sem tagadta, a Rust fordítási sebessége iszonyatosan lassú; mikorra fog lefordulni a Linux kernel, a coreutils és az ökoszisztéma egyéb átírt részei egy 32-bites gépen? Több nap múlva?
Aztán, külön irodalma van annak, hogy hogy lehet a Rust-tal kicsi binárisokat fordítani, mert alapból egy hello world is többszáz kilósra fordul. Ez embedded környezetben minden, csak nem elfogadható, de nagyobb gépeken sem lesz vicces; hogy fogják ezt majd a balfácánok használni? Vagy produkálják majd a több MB-os binárisokat és a Linux kernel, ami eddig párszáz MB volt, az most hirtelen többtíz GB lesz? Hogy fog az mondjuk egy Raspberry Pi-n futni? Hogy fog bármin futni?
Ezek valós problémák, nem pedig "jelentéktelen ellenérvek".

Már ennyinek elégnek kellene lennie, hogy belásd, hogy a Rust biztonságosabb.

Amennyiben az "általában" kitétellel használjuk, akkor már az elején beláttam. Nektek is régen be kellett volna látni, hogy a C-nek még mindig megvan a létjogosultsága, de nem akarjátok. Azt is be kellett volna látnotok, hogy nem biztos, hogy olyan nagyon jó lesz, ha cédula nélkül átírunk mindent Rust-ba, de ezt sem akarjátok belátni. Ugyan ami ellenérveket felhoztam, azokat elismeritek, hogy igazak, csak nem foglalkoztok velük, lesöpritek az asztalról: az nem számít, jelentéktelen, meg ne vitatkozzunk rajta...miért is ne? Miért kéne axiómaként elfogadni mindent ami a Rust mellett és a C ellen szól, fordítva meg semmit, az miért is nem számít? Erről beszéltem már a legelején, hogy kettős mércével mérik a Rust-ot és a C-t.

És ez azért nagyon aggasztó, mert jelen pillanatban egyre inkább az látszik, hogy a Rust-osok takeover-t készítenek elő a Linuxos - és tágabb értelemben a UNIX-os - kulcsszoftverek kapcsán és így nem csak a Rust-tal nem rendelkező platformoktól veszik el az ökoszisztémát, de a nagy többségtől is, akik nem beszélik a Rust-ot. És mindehhez olyan multik biztosítják a műszaki és marketinghátteret, akikre nemhogy a számítógépem működését, de semmit se bíznék rá.

de ha a Rust compilerben 7 évig nem javítanak egy stack-crash-t, az nem baj.

Az a kettő közt a különbség, hogy Rust compilerből egy/kevés van (vagy lesz), megírt C programból meg sok. Azaz ha egyszer a Rust compiler mondjuk már (közel) hibátlan lesz, akkor ez a hibaforrás eltűnik, vagy jelentéktelenné fog válni.

Fordítsuk ezt meg: nem a nyelv fogja meghatározni, hogy mennyire lesz biztonságos a kész program

De, a nyelv kihatással van rá. Rustban nehezebb elkövetni bizonyos hibákat, amiket C-ben könnyű. Ezek után meg olyan érveket hozol ide, amik teljesen irrelevánsak. Ha Usain Boltra rápakolsz 100KG-ot, akkor én gyorsabban fogok futni. Most komolyan, mi értelme van összehasonlítani egy balfácán programozót egy hozzáértővel? Ki mondott olyat, hogy Rustban egy balfácán is jót fog alkotni? Már sokadjára hozol be olyan dolgokat, amit nem mondtam.

alapkoncepció is megváltozik, hiszen arról volt szó, hogy ez majd biztonságos lesz, megvéd mindentől

Nem, nem erről volt szó. Ha elolvasod a korábbi hozzászólásaimat, akkor ennek az ellenkezőjét mondom. Bizonyos hibáktól megvéd. És lehet, hogy mondjuk a Rustban írt programokban emiatt mondjuk 30%-kal kevesebb sechole lesz (hasraütés).

Olyan állítások is elhangzottak, hogy mi mindent kéne erre a nyelve átírni

Én biztosan nem mondtam olyat, hogy "kéne". Úgy fogalmaztam, hogy lehet értelme, ill., ha mondjuk valami komolyabb cuccról van szó, ami C-ben van, és nagyon fontos a biztonság, akkor látom az értelmét.

 

Na, szerintem itt én kiszállnék ebből a beszélgetésből. Csak azért írtam meg az első hozzászólásomat a témában, hogy rávilágítsak, hogy Rustban bizonyos hibákat nehezebb elkövetni, és ebben a tekintetben a C rosszabb. Ennyi. Ezt elmondtam, a többi dolog őszintén szólva nem különösebben érdekel. Többes számban fogalmazol, "Nektek belátni", olyan dolgokat írsz már megint, amiket már egyszer cáfoltam. Ill., olyan dolgokat hozol fel "kérdőre vonva", amikkel meg amúgy egyetértek.

Azaz ha egyszer a Rust compiler mondjuk már (közel) hibátlan lesz, akkor ez a hibaforrás eltűnik, vagy jelentéktelenné fog válni.

Értem, tehát az überbonyolult Rust, az lehet (közel) hibátlan, egy húsz nagyságrenddel kisebb C program, amiben meg 20 éve nem fogtak hibát, az meg nem, abban lehet hiba.

Most komolyan, mi értelme van összehasonlítani egy balfácán programozót egy hozzáértővel?

Mi értelme van összehasonlítani a C-t a Rust-tal?

Ki mondott olyat, hogy Rustban egy balfácán is jót fog alkotni?

Olyat senki, de én se erről beszéltem, hanem, hogy a Rust majd megvédi a balfácánokat maguktól: nem fogja.

Már sokadjára hozol be olyan dolgokat, amit nem mondtam.

Sorry, ez a válasz kb. három embernek is szólt egyszerre, mert nem akartam háromszor majdnem ugyanazt leírni, három külön helyre.

Ha elolvasod a korábbi hozzászólásaimat, akkor ennek az ellenkezőjét mondom. Bizonyos hibáktól megvéd. És lehet, hogy mondjuk a Rustban írt programokban emiatt mondjuk 30%-kal kevesebb sechole lesz (hasraütés).

Nem is azt mondtam, hogy te mondtad, hanem, hogy ez a mantra.

Csak azért írtam meg az első hozzászólásomat a témában, hogy rávilágítsak, hogy Rustban bizonyos hibákat nehezebb elkövetni, és ebben a tekintetben a C rosszabb.

Ebben meg végig egyetértettünk. Én egyébként azért írtam meg a saját hozzászólásaimat, hogy ne akarjátok már megint a C-t kiirtani.

Többes számban fogalmazol, "Nektek belátni", olyan dolgokat írsz már megint, amiket már egyszer cáfoltam.

Egyrészt, mert mint írtam a válasz három embernek szólt. Másrészt meg nem, nem cáfoltad meg. Hol cáfoltad meg azokat, amiket pl. a hármas bekezdésben írtam a binárisok méretéről, a compile-time-ról és a compile RAM igényéről? Hol cáfoltad meg a compiler bug-okat és hasonlókat? Nem megcáfoltad őket, hanem közölted, hogy az nem számít. Az nem cáfolat.

másfelől meg ott van fentebb az élő példa, hogy egy unsafe rész hibája a safe részig eszkalálódott és a safe rész volt, ami összedőlt.

... halkan jegyzem meg, hogy ezért fontos az "unsafe" fogalmát és célját helyén kezelni.
Te mint a függvényt alkalmazó, szóval a safe környezet azt jelenti hogy ott nem tudsz hibázni.

Ettől a rendszer mégis hibás eredményt fog produkálni, például mert:
   - a más által írt függvény unsafe részt tartalmaz kellő körültekintés nélkül
   - a bugos vagy átgányolt fordító fordít hülyeséget
   - memóriahibás a futtató gép és más utasításkódot ad a CPU felé

Értelemszerűen ezekre nem fog a rendszer biztonságot adni, hiába biztonságos a te kódrészed.
Átnézni viszont ez esetben nem a te hatalmas kódrészedet kell, hanem a fókusz
   - más által írt kódból az "unsafe" részeken
   - ellenőrizni, hogy nem átgányolt, nem bugos a fordító (~bugreport és társai)
   - kizárni azt a lehetőséget, hogy nem memóriahibás futtató gépen fut

"Nem lesz rendben, hogy a hátrányokat figyelmen kívül hagyva nekiállnak a fontos szoftvereket átírni ebbe."

Amit eddig neztem rust -ba megoldhato valoban zero overheaddel,
Ill. a legtobb dolog valoban zero overhead alapbol ugy ahogy a konyvben van.
(Meg nem jarok ott, hogy mindent microsocope ala tettem.)

Nehany zero-sitas pilota vizsgasnak tunik, meglatjuk kesobb is annak tartom -e.
Es gyakran nem is eri meg vele foglalkozni, mert csak a statup timet hoszabbitja 1usec -el,
ill a program tovabbi bovitessel C ben is kenytlen lennel hasonlo vedelmet beteni.

Az egyetlen dolog amit lattam fentebb irva,
hogy jelenleg kevesebb platformra elerheto, mint a C (BTW, ultra kicsi micro cuccoknal, altalban inkabb haszalok asm -et)

A maik dolog amit feltetlezel, hogy C kodot csak igazi programosok irnak. Ami manapsag kurvara nem igaz.
Lattam nem egy olyan C projectet,
amit akkar pythonban is megvernek ami sebesseget illeti.
Ill. nem egy olyan hiba kerul elo gyakorta amiert 5 ev kotel jarna.

Aranyiban veve egyre tobb a hatul gombolos a szakmaban,
nem feltetlen okos dolog igazi fegyvert adni a kezukbe.
Nem az okosabja tunt el, abbol is tobb van, egyszerun csak nagyon sokan lettunk.
Ill hatar idok is vannak, sietosebbek mint a regi idokben. Ill nagyobb az ember fuktucaio is,
egy project elete soran konyen lehet hogy a teljes garda korulotte tobbszor is teljesen lecserelodik.

Egyik beszelgetesem:
  En: Ez a project lassu. Nem kene atrirni mondjuk C -be?
  Masik: Ha ugyan az banda csinalja , C -ben el sem indulna.

Ill. ha megnezed fizetesi statistikakt erdekes,
hogy python kodernek manapsag tobbet fiztnek, mint egy C kodernek.
Valamilyen kulonos, modon nem feltetlen azt  az eszkozt keresik, amiben "elmeletben",
a legjobb lesz a futas ido. Ill az hogy tobben tudnak ertlemes python codot irni
mint C -t, megis jobban fizet a python.

C -t nehez uberelni.
Mi az ami nem C, FORTRAN, pascal, D, assembly es hulyeseg lenne Rust -ba tenni ?
Milyen tenyleges hatranyt latsz mondjuk go/java/c#/c++ -> Rust ba tetelenel ?

Ha egy C librarit valaki atir Rust -ba, de biztositja 100%  C compatibilis interfacet,
es meg 0.1% al gyorsabb is , hasznalnad -e ?

IMHO az hogy az emberek, atirkalna dologokat ekkora nepszerusegu nyelvnel,
ez  nem meglepo, kerdes az hogy az jo lesz-e nekunk, vagy csak neki ido toltes.
rust az az elso olyan eszkoz a C ota, aminek vegeredmenye akkar a jobb futas ido is lehet.
Nem ezert mert C -ben,  nem lehet gyorsabbra irni, hanem mert aki ujra irja remelhetoleg,
nagyon igyekszik majd megverni az elozo implementaciot.

Milyen tenyleges hatranyt latsz egy uj userland project rust -ban kezdesenel , C -val szemben ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ne feledjük, hogy a "sokan lettünk" mellett a nem igazán jóindulatúnak mondható internetre való minden rákapcsolása miatt a biztonságos programozás igencsak felértékelődött.
Nézzünk csak vissza a múltba, ehhez képest "békeévek" voltak.

A maik dolog amit feltetlezel, hogy C kodot csak igazi programosok irnak. Ami manapsag kurvara nem igaz.

Ööö...ezt hol is feltételeztem? Mert én nem emlékszem ilyesmire. Szó szerint leírtam, hogy "egy igazi programozó bármilyen nyelven tud FORTRAN kódot írni." Miről beszélsz?

nem feltetlen okos dolog igazi fegyvert adni a kezukbe.

És akkor azoktól is vegyük el, akik viszont tudnának vele bánni. Már megint. Már megint egy világmegváltó kisebbség akarja mindenkinek megmondani, hogy kell programozni, ami mögött szokás szerint egy multi áll, egy olyan multi, aki ha nem bizonyította be ezerszer, hogy nem bízhatunk meg benne, akkor egyszer sem. Pl. legutóbb a Rust csapat nagyrészét is kirugdalta.
Sőt, most nézem, hogy pár napja már nem is csak a Mozilla áll mögötte egyedül, hanem más multik is, akik mind a megbízhatóságukról híresek: https://en.wikipedia.org/wiki/Rust_(programming_language)

In August 2020, Mozilla laid off 250 of its 1,000 employees worldwide as part of a corporate restructuring caused by the long-term impact of the COVID-19 pandemic.[43][44] Among those laid off were most of the Rust team,[45] while the Servo team was completely disbanded.[46] The event raised concerns about the future of Rust.[47]

In the following week, the Rust Core Team acknowledged the severe impact of the layoffs and announced that plans for a Rust foundation were underway. The first goal of the foundation would be taking ownership of all trademarks and domain names, and also take financial responsibility for their costs.[48]

On February 8, 2021 the formation of the Rust Foundation was officially announced by its five founding companies (AWS, Huawei, Google, Microsoft, and Mozilla).[49][50]

Miért van déjà vu-m?

Ill. ha megnezed fizetesi statistikakt erdekes,
hogy python kodernek manapsag tobbet fiztnek, mint egy C kodernek.
Valamilyen kulonos, modon nem feltetlen azt az eszkozt keresik, amiben "elmeletben",
a legjobb lesz a futas ido. Ill az hogy tobben tudnak ertlemes python codot irni
mint C -t, megis jobban fizet a python.

Ilyesmikről szokott hajbazer filozofálni, de legtöbbször lehülyézik, ahelyett, hogy elgondolkodnának azon, amit mond... (Miért van olyan érzésem, hogy mindjárt jön a szalmabábcséplés, hogy "miért lenne jobb, ha mindent C-ben írnánk meg"?)

Milyen tenyleges hatranyt latsz mondjuk go/java/c#/c++ -> Rust ba tetelenel ?

A lingvisztikai sovinizmuson kívül? (Oké, a Java kódot nem lehetne nem úgy átírni majdnem bármi másba, hogy ne javítsunk vele...) Egyfelől időpazarlás. Ezek a nyelvek ugyanúgy vigyáznak a memóriára, ahogy a Rust is. Még csak azokat a hátrányokat sem dolgozod le az átírással, amit mondjuk egy C átírással megtennél (pl. memóriakezelésből fakadó sechole-ok). Aztán, ha már írtad, hogy Python-os embert többen keresnek, meg többet fizetnek, mint C-st, mert a profit számít, amit az időn nyernek, akkor had fordítsam ezt itt ferdén vissza: ha átírsz egy kódot egy olyan populáris nyelvből, mint a felsoroltak egy olyan underground nyelvbe, mint a Rust, akkor századannyi programozóból válogathatsz (jó esetben), mint előtte és akkor magadnak okozhatsz vele súlyos anyagi károkat, ha nem találsz embert.

Ha egy C librarit valaki atir Rust -ba, de biztositja 100% C compatibilis interfacet,
es meg 0.1% al gyorsabb is , hasznalnad -e ?

Úgy érted, ha le tudom forgatni a platformomra? Miért ne használnám, ha tényleg gyorsabb lett, mint volt?

Milyen tenyleges hatranyt latsz egy uj userland project rust -ban kezdesenel , C -val szemben ?

Látom, nagyon felületesen sikerült elolvasnod azokat, amiket írtam, mert szó nem volt új projektekről. Új projektet nyugodtan írjon abban, amiben akar. Rustban is. Abban írja meg, amiben akarja.

De meglévő régieket átírni, na az az a pont, ami nem biztos, hogy jó lesz azon projektek használóinak. Nézd meg, lent már belinkelte neuron, hogy a GNU coreutils-t is át akarják már írni Rust-ba. Úgy, hogy a coreutils-t használó rendszerek közül Tier 1-es Rust támogatása egyes-egyedül a Linuxnak van és még annak is csak ARM-on és x86-on! Ez mi, ha nem már megint egy kísérlet arra, hogy a Linuxon kívüli UNIX-okat és a nem-x86 és nem-ARM CPU-kat ellehetetlenítsék, ez mi már megint, ha nem a mainstream status quo-jának a kierőszakolása?
És ha már Linux, ha azt átírják Rust-ba, akkor azzal a rössel ott is töredékére csökkentik azoknak az embereknek a számát, akik utána hozzá tudnak szólni a Linux kernelhez. Akár tetszik, akár nem, a C többé-kevésbé a lingua franca az informatikában, mind a programozóknak, mind az oprendszereknek, mind a processzoroknak; olyan, mint az emberi nyelvek között az angol. Olyan ember, aki tud C-ben programozni, több tízmillió van. Rust-ban? Tavaly olyan félmillió körül volt, picit tán több. A C szinte az összes OS-re és CPU-ra elérhető, pedig valószínűleg több száz van belőlük. Rust? A Tier 1 két CPU-t és három OS-t támogat.

Ha átírod a Linux kernelt vagy a coreutils-t, vagy bármi létező projektet Rust-ba, akkor azt nem csak az architektúrák többségétől veszed el, de elveszed a programozók többségétől is és egy olyan kisebbség kezébe adod, akik mögött az Amazon, Huawei, Google, Microsoft és Mozilla ötösfogat áll. Szép kilátások, mondhatom.

"Kell?" Ki mondja? A C-t azért kellett megtanulni, mert mindent is ebben írtak. Rust-ban viszont egyelőre semmi fontos nincs megírva, csak próbálnak létfontosságú projekteket átírni bele, még azelőtt, hogy a Rust adoptálta volna az OS-ek és a CPU architektúrák többségét, ill., hogy az emberek többsége adoptálta volna a Rust-ot.

Mondom az én problémám nem magával a nyelvvel van, az olyan amilyen, mint az összes többi nyelv is. Az erőszakos konvertálást nem állom és amikor fontos dolgokat konvertálnak át bele a többség megkérdezése nélkül, az bizony erőszakos, valamint pusztító és kontraproduktív is.

Rust-ban viszont egyelőre semmi fontos nincs megírva

Firefox? Ha nem is az egész, egyelőre.

Az adoptációs probléma meg kicsit tyúk-tojás esete. Mindig lesznek úttörő (early adopter) projektek, amik még azelőtt állnak át, hogy maga a platform teljesen "készen" lett volna. De ez minden nyelvvel így van.

 

a többség megkérdezése nélkül

Ennek teljesen ellent mond az a tény, hogy beindult egy ilyen projekt, ami már magába foglalja azt is, hogy akkora támogatottsága van a Linux kernel fejlesztők körében, hogy érdemes volt egyáltalán felvetni a dolgot. Az is jelent valamit, hogy Torvalds is nyitott a projektre, tehát szerinte is annyival többet nyújt a Rust a C-nél, hogy érdemes élesben is letesztelni a dolgot.

Firefox? Az még van? És fontos is? Legutóbbi infóim szerint már lezuhant az Edge szintjére piaci részesedésben...

Az rendben van, de az nem early-adopting, hogy mindent cédula nélkül átírunk bele.

Ja, Torvalds a systemd-re is nyitott volt. (Nem.) Lehet, hogy nem akar megint "továbbképzésre" "menni". Itt a harmadik bekezdésben leírtam pár problémát a Linux kernel átírásával kapcsolatban. Egy dolog, hogy abban írnak meg újabb modulokat, de abba átírni az egészet?

Igen, létezik Firefox, miatta született a Rust is. :)

Látom nagyon megrémített a viccből írt #2 hozzászólásom. "Hivatalosan" nem akarják átírni az egész kernelt Rustba, hanem csak az újabb modulokat. Azt meg nem érzem semennyire gondnak, ha pár programozó a szabadidejében ennek ellenére mégis arra vetemedik, hogy pár meglévő részt is átírjon egy _alternatívaként_ Rusttal. A választás lehetősége csak jót tesz.

Hát, ha nem tették volna előtte tönkre a rókát, akkor tán még értelme is volna átírni Rust-ba. :(

Lehet, hogy te viccnek szántad, de ahogy nézem, vannak, akik ezt hótt-komolyan gondolják (szaporodnak az ilyen jellegű linkek a topicban). Ha ez lenne a felállás, hogy lesz egy C-ben írt kernel, meg lesz egy Rust-ban írt kernel és lehet választani, ez teljesen rendben lenne, lenne mire benchmarkolni meg flamel-ni, de ez legyen a legnagyobb baj, amíg elérhető választás marad a C-s, különben a Linux hardwaretámogatása a mainstream platformokra fog zsugorodni. És én sajnos attól félek, hogy pont az a cél, hogy az emberek mozgásterét szűkítsék (már a nyelv koncepciója is erre épül) és ezért akarják az ökoszisztéma kulcsfontosságú szoftvereit kurwa gyorsan átírni.

Attól nem kell tartanod, hogy valamilyen meglévő HW-támogatást kivesznek a kernelből, mert nem tudják/akarják átírni Rustba. Ilyenre inkább akkor van esély, ha az adott hardvert nem használja már senki és nincs aki karbantartsa a modulokat. A Rust a jelenről és a jövőről szól. Ha bejön valami új HW, akkor a jövőben lehetséges, hogy inkább Rustban írják majd meg a drivert hozzá, hiszen ez a jobb választás (asszem ebben már sikerült megegyezni a topikban).

Nem, félreérted. Nem arról beszéltem, hogy valamilyen adott hardware támogatását kiveszik a kernelből, hogy a drivereket lövik ki, hanem arról, hogy magát a kernelt nem fogják majd tudni lefordítani egy raklap processzorra/gépfajtára és azok a platformok mind elesnek utána a Linuxtól.

Régi vagy új architektúrákra gondolsz most? Régiek esetében miért ne működne az, hogy beállítom a NO_RUST_MODULES flag-et és csak a C-s részeket fordítom le? Meg egyébként miért a legújabb kernelt kell rakni egy régi hardverre? Mindig megvan a lehetőség korábbi kernel használatára, a régi cuccon elinduló programok is jó eséllyel nem a legújabb kernellel kompatibilisek.

Régiek esetében miért ne működne az, hogy beállítom a NO_RUST_MODULES flag-et és csak a C-s részeket fordítom le?

Ha az egész Linux kernelt átírják Rust-ba és felszámolják a C-s verziót, akkor hogy fordítod le a C-s részeket?

Meg egyébként miért a legújabb kernelt kell rakni egy régi hardverre?

Nem kell, de ha már 10 éve nincs C-s Linux kernel, akkor mit rakjon rá az ember?

Ha az egész Linux kernelt átírják Rust-ba és felszámolják a C-s verziót,

Ez belátható időn belül nem fog bekövetkezni, de még tervben sincs.

 

ha már 10 éve nincs C-s Linux kernel, akkor mit rakjon rá az ember?

Úgy értettem, hogy ha régi gépre akarsz Linuxot rakni, akkor keresel egy régi kernelt. Miért akarnál olyan kernelt rakni rá, amit évtizedekkel a hardver elavulása után fejlesztettek? Ameddig lesz áram, addig elérhető marad az összes létező kernel változat, bármelyiket elő lehet venni, ha nosztalgiázni akarsz egy régi hardveren. Az újabb hardvereket meg támogatni fogja az újabb kernel, akármilyen nyelven is írják.

Hogy mikor következik be, azt nem tudom, de tervben már van, check the topic.

Félreértettél. Most fel tudok rakni egy tíz éves gépre egy tíz éves kernelt, igen. De ha az elkövetkező öt évben a Linux kernel átkerül Rust kód alá, akkor tíz év múlva hogy rakok fel egy öt évvel korábbi (azaz mostantól öt év múlvai) kernelt egy öt évvel korábbi (dettó) gépre, amin a Rust nem elérhető? Rakjak fel rá egy tíz éves (azaz mostani) kernelt? Ez pont, hogy nem nosztalgia, ez nagyon is a jövőről szól. Jelen pillanatban a Rust a C platformjainak a töredékét sem támogatja. Ez biztos változni fog pozitív irányba, de kérdés, hogy mekkora lefedettéget fog adni a legvégén... (Ha tippelnem kéne, akkor töredékest, mert a C fél évszázad óta portlódik mindenhova.)

Egy arch tipukusan a rust tamogatast, az llvm tamogatasa elozi meg.
Amihez nincs active llvm/clang tamogatas, az valoszinulag mar ma is haldoklik vagy properatiry ami majdnem ugyan az ;-)

Az hogy mennyi munka egy plus archot hozza adni rusthoz ill. eletben tartani az hazi feladat ;-) .
De IMHO lenyegeben az llvm -tol fuggsz majd, mar ha 10 ev mulva meg lessz ..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"De új architektúrákon is mi az egyik legelső, ami megjelenik? C fordító."
Nem pont azt irtam, hogy ha nincs clag llvm -hez karban tartva?

Proprietary resz  felig-meddig vicc volt, ha nem esett volna le.

https://www.cnx-software.com/2020/04/22/is-mips-dead-lawsuit-bankruptcy…
A legfirssebb hallal hir keltes, szerinted ?

Legujabb core 2015, https://en.wikipedia.org/wiki/List_of_MIPS_architecture_processors 28nm.
28nm "elmegy" katagoria ma, de ha nem jon kisebb 3 even belul, en temetem ;-)

A ma kerdese hogy risc-v -bol lesz -e valami beleathato idon belul:
https://www.cnx-software.com/2020/08/25/more-details-about-alibaba-xt91…

Akkarsz beszelni soft-core -okrol is ? Erintett vagy -e az ugyben ?

szerk:
Altalanos celu Hard-core -bol nem valoszinu, hogy
tobb mint 6 csalad marad Linux tamogatott meg 10 ev mulva, illetve nem valoszinu, hogy
ujabbak bukannak fel, mikozben egy sem esik ki.
Es ehhez a rust-nak, semmi koze sincs.

 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem pont azt irtam, hogy ha nincs clag llvm -hez karban tartva?

Nem csak az LLVM/Clang létezik, vannak más C fordítók is.

Azt nem tudom, hogy a MIPS-nek mi lesz a sorsa, de tuti nem tőled fog függeni, hogy temetik-e, vagy sem.

Akkarsz beszelni soft-core -okrol is ? Erintett vagy -e az ugyben ?

Nem akkarok. Nem-e vagyok.
Nem tudom mi futott a májadra, de nagyon ráfutott, azt látom.
Hint: nincs jogod ezzel a pszeudoprogresszív mantrával en-block halálra ítélni minden legacy vagy kisszériás architektúrát; nem csak a mainstream létezik, nem csak azt használják.

Altalanos celu Hard-core -bol nem valoszinu, hogy
tobb mint 6 csalad marad

Több tucat fajta van most is, de nem probléma. Csak a mindenféle mikrokontrollerekből nem tudom hány. C azokra is van.

"Azt nem tudom, hogy a MIPS-nek mi lesz a sorsa, de tuti nem tőled fog függeni, hogy temetik-e, vagy sem."
A Linux tamgotsa akkor fog megszunni amikor az utolso ember is eltunik aki hajlando meg eletben tartani.
A MIPS es eszkozeimet ez evben nyugdijaztam, eleg keves esely van ra hogy az en leszek.

" Hint: nincs jogod ezzel a pszeudoprogresszív mantrával en-block halálra ítélni minden legacy vagy kisszériás architektúrát; nem csak a mainstream létezik, nem csak azt használják."
Nem csak mainstream letezik, de ha valami nem marad versenykepes, akkarcsak valami zug felhasznalasra
akkor az elobb utobb kihal.

"Több tucat fajta van most is, de nem probléma. Csak a mindenféle mikrokontrollerekből nem tudom hány. C azokra is van."
Linux futasara kepes eszkozokrol volt szo, abbol nincs sok.
Kerunk teljes mondatot idezni valasz elott, nem kiragadni a Linuxot.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ne menjünk messzire: TILE processzor: https://i.mt.lv/cdn/product_files/CCR1072-150831130622_150822.png
Gyártásban levő termék, a proci támogatását a kernelből viszont karbantartó hiányában kidobták. https://lkml.org/lkml/2018/3/14/514

Nem tudom, hogy imádkozták bele a Mikrotiknél a ROS7 ágba a TILE procis CCR-eket, de nem lehetett kis munka az 5.x-es kernelágba beledrótozni.
Ugyanígy nem lehet kis munka igény esetén egy elhalófélben levő AVR32 procit (vagy XYZ procit) a céged által beledrótozni az LLVM-be.
Ha benne van az LLVM-ben, akkor a Rust fordítót megkalapálni az előzőhöz képest már könnyebb feladat.

Mi következik ebből? Ha van egy frankó proci, akkor nem elég  hardver kifejlesztése, hanem a gyártónak gondoskodnia célszerű, hogy a GCC és CLANG fordítókban támogatva legyen. Legalábbis ha széles körben sikeressé akarja tenni.
Ha pedig van LLVM támogatás, akkor a Rust is könnyen felkészíthető erre a procira.

A termékhez fejlesztett saját C fordító korszaka régen elfogadott volt, ma már inkább hátrányt jelent az apró de kellemetlen C-beli és paraméterezésbeli eltérései miatt.
Megjegyzem, az egykori Borland (ma Embarcadero) fordítók szintén dobták néhány éve a saját backendet és CLANG/LLVM-re álltak át.

" Megjegyzem, az egykori Borland (ma Embarcadero) fordítók szintén dobták néhány éve a saját backendet és CLANG/LLVM-re álltak át."
Ez megmagyarazza miert van Delphi frontend.

Manapsag versenyben maradni, nagyon nehez, meg speciallis celra is:
https://en.wikipedia.org/wiki/Adapteva

A tile felhasznalok ugy latom ARM fele mozogtak, mind szinte mindenki aki sulyedo hajon volt.
Az ARM lehet lassan olyan helyzetbe jut, hogy nagyobb arat diktalhat.
Egyes cegeknek, csak azert is megerhet egy risc-v -t tartani, hogy ez ne kovetkezzen be.

Eleg sok ceg kell ahhoz, hogy esely legyen egy uj alatalonos celu arch-nak:
https://riscv.org/members/

Ti nincs a listan. (https://www.macrotrends.net/stocks/charts/TXN/texas-instruments/revenue hanyatlas volt)
Analog nincs a listan. (https://www.macrotrends.net/stocks/charts/ADI/analog-devices/revenue hanyatlas volt)
Intel megint beszerzett valamit amiben ARM -core is van, es nincs a listan.

Nvidia probalja megvenni az ARM-ot, mikozben a listan van.
https://www.cnet.com/news/google-microsoft-and-qualcomm-want-regulators…
Mellanox-al kapott ARM -coreos termeket.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az előzőről még egy kiegészítés: sok éve sikerült pár hétre hozzájutnom egy Xeon PHI kártyához. Sok mag + magonként 4HT. Azaz rengeteg szál. Szálon belül AVX512, stb.
A mutatvány ez esetben szintén ott akadt meg, hogy volt kölcsönbe egy szuper hardver, a szoftvertámogatása pedig csapnivaló volt. A kettő szorzata azt eredményezte, nem tudtam vele semmi értelmeset kezdeni. Dobtam.
Azóta az Intel is dobta. Utólag belátva idejében adtam fel a gyenge szoftver+doksit támogatás reverz módszerekkel való feltárását.

Tehát:
   1.) jó produktum
   2.) jó fejlesztői szoftver támogatás (lehetőleg a "megszokott" fordító kiegészítésével)
   3.) jó, néhol akár picit szájbarágós dokumentáció
   4.) reklám, terjesztés, közösségformálás

Szoftver terén is fontos: Rust új fordító, hátrány hogy új nyelv. Viszont sokmindenre nagyon odafigyeltek. Fordítót könnyen tudd telepíteni és használni. Hiba esetén lehetőleg adjon segítő tippet. Továbbá jól dokumentált legyen.
Erre az új mikrovezérlőknél, processzoroknál is oda kell figyelni a gyártónak. A TILE lassú elhalásához ez a támogatási környezet hiány is hozzájárult. Maximum az 1. pontot teljesítette, de azt is inkább oly módon, hogy hálózati eszközökre praktikus perifériái voltak. Ahogy pár évvel később lett ARM mag köré épülő hasonló periféria, az pedig fogyasztással (villanyszámla, hűtés, kevesebb hűtőborda okozta termékgyártási költség, ...) nyert.

RISC-V elvileg a kedvező számítás/fogyasztás arányával reklámozza magát. Kérdés lesz a különböző számítási tempó igények mellett, hogy valójában a számítás/fogyasztás arány tényleg az előzetes ígéretek szerint fog-e alakulni?
Ma az új versenyzőknek hátrány ha azt kell mondaniuk, hogy "mi nagyon jók vagyunk, de az architektúránk kizárólag ebben a számítási tempó szegmensben lelhető fel".

A masik "kedvencem" amikor nincs debug lehetoseg linux hosthoz.
Megveszed a dev boardot, es meg vegyel hozza egy 500$ debug eszkozot,
talan meg  fizes evente szoftverert es futtasd windowson.
A debug interface nem documentalt..
(500$ eszkoz, 5$ bol jon ki, 495$ lehuzas/license)

"RISC-V elvileg a kedvező számítás/fogyasztás arányával reklámozza magát. "
RISC-V ISA nem kulonleges, nincs semmi olyan tulajdonsaga ami az ARM vagy a mar kihalt cuccok nem
csinalnak. Hogy mit fog tudni az attol fugg hogy mit feljelsztenek kore a CPU fejlesztok.
Van eselye sok eves tavlatban megszorongatni a tobbieket, vagy eltunni a sulyesztoben.

RISC-V nem az elso open ISA, de az elso ami kore komoly tamogatok sorakoztak fel.
Most az a resz jon, hogy temetik bele a penzt.
Remelhetoleg megjelennek olyan chippek, amik azon tul hogy elmondhatod fejlesztettel
meg egy archra , talan meg jok jo valamire, illetve valahol koltseg hatekonyabbak is.

ARM license dija valami ilyesmi volt 1M USD illedelemes koszenes, 1M USD egy core valtozat,
0.01~1 USD per legyartott core.
Ez megvaltozott:
https://www.electronicdesign.com/technologies/embedded-revolution/artic…
 
Most az dolog hogy open core egy erdekes dolog.
Hogy a mezi hobbistak menyire tudnak corehoz hozza szolni az eleg limitalt.
1. Vannak zart valtozatok.
2. 99$ vehetsz olyan boardot amin legkisebb 32 bites, egyszeru coreal jatszhatsz,
ha egy complex rendszert/coreokat akkarsz FPGA -ban ossze hozni ami hasonlit is valami modern core- ra,
akkor az egy-ket nullaval tobbe kerul. Vagy probalkozhatsz szimulacioval, ami nem gyors,
es nem is anyira szorakoztato .
Nagyobb egyetemek meg tudjak fizetni az eszkozoket, ill. talan meg barati licensel is publikalni a
probalkozasaikat.
Manapsag cloud bol is lehet nagy FPGA-t kolcsonozni, de arra nem kotsz scopot ..

Az egyseges ISA korulu felsorakozas, pont azert is jo mert, nem kell sajat eco systemat fentartani,
a koltsegek eloszlanak a gyartok kozott.

ARM azert tudta megverni a tobbieket, mert sok-sok termekre tudta eloszotani a koltsegeket,
Igy azok aikik kevesebb core-t adtak el, tobbet kellett beszedniuk kevesebb corbol, ami
nem kedvezett az araknak.
ASIC gyartas es fejlesztes koltsege is novekedett, ahogy megyunk lejebb nm -ben.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"rétegigények is léteznek."
Velhetoleg egy termek nem attol lesz eladhato, mert
a fejlszotnek van egy szekreny "I love MIPS" poloja,
mikozben mar nem fejlesztenek ra /vele uj hardwert.

Ar szamit,  fogyasztas szamat, kokurrens termek teljestmenye ill.
funkcionalitasa szamit.

Milyen olyan feledat van most 2021 -ben, ahol te MIPS -et valasztanal ?
 - mi a faladat
 - mi az aminek meg kell lennie a SoC -ban/ boardban, hogy az megoldhato legyen
 - massal megolva, nem lenne -e jobb  a veg termek, vagy olcsobb a fejlesztes/elloalliats .

Tedd fel minden evben a kerdesket, elobb utobb te is oda jutsz a valoszakkal ahova masok
is jutottak.

A regi hardvereket dedelgetok clubja, kb. barmeddig hozza juthat a regi szoftverhez.
Ne vard, hogy mindenki oromodakakat zengve,
karban tart valamit amibol neki vagy cegenek nincs anyagi haszna.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem fejlesztenek már MIPS-szel új hardvert? És akkor pl. az Onion Omega2 sorozata micsoda? Az Omega2 Pro és Omega 2LTE most jött ki 2019-ben, ráadásul közösségi finanszírozással fejlesztették ki és a sokszorosát szedték össze a kért pénznek. Úgy látom, te csak dobálózol az architektúrák nevével, de nem tudod, hogy melyiket használják-e még, vagy sem. A 68000-rel is lukra futottál a ColdFire miatt.
BTW, nagyon leragadtál ennél a MIPS-nél, még nem is gyártanának hardvert vele, akkor is, mi van az összes többivel; mind kuka? x86 és ARM-only világ rulez? Mi van pl. a POWER-rel? SPARC? Azokkal is a mai napig építenek gépeket. Ez nem "régi" hardvereket dédelgetők klubja, hanem használt hardverek támogatása, nem más.

A big-endian POWER is élőnek számít; csekkold le a Raptor féle workstation-öket.
A SPARC-nak tényleg nem tett jót az Oracle, de egyelőre még élő architektúra, nem lehet kukázni a támogatását.
Minek nézegessem? Én nem használok MIPS-et. Az állításod az volt, hogy már nem fejlesztenek vele hardvert; de. Fejlesztenek.
Ami meg a tendenciákat illeti: ahogy leírtam már N-szer, a C-t eddig számos alkalommal próbálták leváltani, amióta megszületett. Számos nyelvvel és számos paradigmával. Mind sikertelenül. Pedig tényleg elég sok baja van. De egyszerűen az előnyei miatt van ahol nem tud az ember alternatívát állítani vele szembe.

"A big-endian POWER is élőnek számít; csekkold le a Raptor féle workstation-öket."
Mennek azok little endianban, es manapsag azt toljak poweren.

" Minek nézegessem? Én nem használok MIPS-et. Az állításod az volt, hogy már nem fejlesztenek vele hardvert; de. Fejlesztenek."
Eliras, felteles modot akkartam :) , ill fentebb irtam hogyha 3 even belul nem rukkolnak elo valamivel akkor fogom
halottnak tekinteni.

"Számos nyelvvel és számos paradigmával. Mind sikertelenül. Pedig tényleg elég sok baja van. De egyszerűen az előnyei miatt van ahol nem tud az ember alternatívát állítani vele szembe."
Engem nem kell meggyozonod, az hogy hetenete hallgatom "Write in C" zentet
es kuldozketem a muka tarsaknak az nem vicc volt , hanem a valosag.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem a en kedvemet pusztulna ki. Es ugy latom fogalmad sincs nekem milyen kedvem lenne.

Meg tudod -e nevezni az entitast, aki velhetoleg 14nm vagy kisebbre visz egy production -ra szant core-t  MIPS ISA -val ?
Meg tudod -e nevezni az entitast, aklirol azt gondolod hogy mondjuk wifi-7 -es SoC fog osszehozni MIPS ISA -val ?

MIPS nem tiltja meg hogy valaki tovabb vigye, de elvar nemi $$$ a MIPS certert vagy a hozza ferresert.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Neked tényleg nagyon beragadt ez a MIPS dolog. Tudtál mutatni egy architektúrát, aminek a gyártója most bejelentette, hogy nem akarja fejleszteni, annak ellenére, hogy jönnek ki vele hardware-ek. És? Mi lesz a többi soktucat architektúrával, amiket a Rust nem támogat, a C meg igen?

32bit MMU -val rendelkezo es kulso memoriat hasznalo chipek cegei a MIPS hez hasonload RISC-V fele mentek,
nem biztos hogy (ma vagy) 5 ev mulva erdkelni fogja oket van -e rust a rugi cumokra.
A regisegek vagy llvm vagy gccrs fele mozoghatnak, ha a rust elkerulhetettlen lesz.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

C nem fog kihalni, lesz bőven létjogosultsága a jövőben is. Ahogy az assembly sem halt ki, mert van még mindig létjogosultsága.
Igaz, teljes mértékben assembly projekt igen ritka. Leginkább a C rész alá dolgoznak assembly-vel, ahol bármi okból így célszerű.

Rust esetén mellesleg jelen pillanatban még ilyen a nagy sebességű jelfeldolgozás területén magának a blokkfeldolgozónak az implementálása. Egyelőre C betéttel vagy assembly intrinsic segítségével egyszerűbb a megnyerni a tempót. Ugyanis a Rust rész ahogy egy kis bizonytalanságot érez, inkább ellenőrizni akar, miközben egy-két lépéssel globálisabban továbbgondolva abban a blokkfeldolgozóban TUTI nem lehet szivárgás. A tempó pedig jelfeldolgozásnál gyakran nagyon fontos.
Ezt a Rust fórumon is feldobtam és bár igen jó megoldások jöttek. Viszont a teljes kontrollálatlanság kihasználása ebben a speciális esetben érezhető tempónövekedést hozott. De csak a blokkfeldolgozó primitív került át C betétbe, mivel a többi már nem illetve észrevehetetlen mértékben lassított.
Szerencsére nagyon könnyű a Rust-C összekapcsolás (példa itt), mérésem szerint futásidejű többlet költsége sincs.

A jövőben a Rust mellett számítok újabb, a Rust-féle ownership-koncepciót továbbvivő biztonságos rendszerprogramozásra alkalmas nyelv(ek) megjelenésére is. Azonban a C és assembly háttértámogatás vélhetően ott is megmarad. :)

C nem fog kihalni, lesz bőven létjogosultsága a jövőben is.

Én is ezt mondom, de látod van, aki irtaná...

(Assembly-t nem is tudna kihalni, anélkül nincs élet.)
Igaz, teljes mértékben assembly projekt igen ritka. Leginkább a C rész alá dolgoznak assembly-vel, ahol bármi okból így célszerű.

Az más kérdés, hogy assemblyben nem nagyon írnak meg direkt dolgokat, de a fordítók többsége tud assembly kimenetet adni, a debuggerek egy része is assembly szinten debuggol; assembly nélkül nincs élet. Nem kell, hogy közvetlenül abban írjanak bármit.

Rust esetén mellesleg jelen pillanatban még ilyen a nagy sebességű jelfeldolgozás területén magának a blokkfeldolgozónak az implementálása. Egyelőre C betéttel vagy assembly intrinsic segítségével egyszerűbb a megnyerni a tempót. Ugyanis a Rust rész ahogy egy kis bizonytalanságot érez, inkább ellenőrizni akar, miközben egy-két lépéssel globálisabban továbbgondolva abban a blokkfeldolgozóban TUTI nem lehet szivárgás. A tempó pedig jelfeldolgozásnál gyakran nagyon fontos.
Ezt a Rust fórumon is feldobtam és bár igen jó megoldások jöttek. Viszont a teljes kontrollálatlanság kihasználása ebben a speciális esetben érezhető tempónövekedést hozott. De csak a blokkfeldolgozó primitív került át C betétbe, mivel a többi már nem illetve észrevehetetlen mértékben lassított.

Ennek is biztos megvan a létjogosultsága a maga helyén, de amíg nem lehet a forgatás sebességét és erőforrásigényét nagyságrendileg a C közelébe szorítani, addig hiába futnak a Rust által készített binárisok near-C sebességgel.

Szerencsére nagyon könnyű a Rust-C összekapcsolás (példa itt), mérésem szerint futásidejű többlet költsége sincs.

Futásidejű lehet, hogy nem nagyon van, de itt nem is ez volt a kérdés.

A jövőben a Rust mellett számítok újabb, a Rust-féle ownership-koncepciót továbbvivő biztonságos rendszerprogramozásra alkalmas nyelv(ek) megjelenésére is. Azonban a C és assembly háttértámogatás vélhetően ott is megmarad. :)

Feltéve, ha a vallási fanatikusok nem írják át addig a Linux kernelt, meg minden egyebet Rust-ba, amit a mainstream szépen le is fog tolni az emberek torkán. Pedig még mindig nem magával a koncepcióval van a baj, hanem az erőszakossággal...

De könyörgöm, nem a kernel hadvertámogatásáról beszélünk, értsétek már meg... Nem arról, hogy most hány driver van benne C-ben, vagy Rust-ban megírva.
Arról beszélünk, hogy amíg C-ben van írva, addig azt a kódot több féle processzorarchitektúrára lehet leforgatni. Attól, hogy átírod Rust-ba még nem fog fordulni azokon a gépeken, ahol eddig fordult, mert nincs rájuk Rust fordító.

Kicsit félreérthető voltam, sry. Arra céloztam, hogy egy ilyen átírás esetén 0. lépésként az történne, hogy a Rustot portolják minden apró architektúrára, a Linux Foundation segítségével (legalábbis amíg Linus az irányító, reméljük, még sokáig).

Psszt, elárulom az IP-címemet: 192.168.0.14

A hivatalosan tamogatott archok kozul microblaze ami jelenleg hianyzik.
gccrs is keszuloben, tehat nem biztos hogy kell llvm tamogatas.

risc-v https://github.com/f32c/f32c eleg hasonlo szamokat mutat,
nem teljesen tamogatott  (Tier3). Ez a 32bites valtozat, 64bittes tamogatott.

szerk:
oops: nem MMU core
https://github.com/f32c/f32c/issues/73

Ehhez van MMU:
https://github.com/SpinalHDL/VexRiscv

https://antmicro.com/blog/2020/05/multicore-vex-in-litex/
"Taking only 70% of a 35 KLUT FPGA - the Artix A35T - VexRiscv runs at 100 MHz and boots Linux in about 4 seconds."

Kerdeses hogy mai hard-wired arm corok mellett menyire eri meg soft-coreokkal foglalkozni:
https://www.digikey.com/en/products/filter/embedded-system-on-chip-soc/…
https://www.digikey.com/en/products/filter/embedded-fpgas-field-program…
https://www.digikey.com/en/products/filter/embedded-fpgas-field-program…

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Hogyan akarják portolni olyan architektúrákra, ahol a Rust meg sem tud moccanni? Oké, magát a kernelt leforgatják crosscompile-lal, ha minden szakad, de amikor már fut a kernel az adott gépen, hogy fognak ott bármit lefordítani egy frissített kernelmodultól elkezdve bármelyik programig? Az rendben, hogy a Rust near-C sebességű binárisokat tud készíteni, de mennyi erőforrás és idő kell, amíg elkészíti őket? Azért ez is egy elég kardinális szempont. Hogy fog ez működni a resource-low platformokon? Sehogy? Run-only lesz és ha épp nincs crosscompile-ra lehetőséged, akkor dead end?

Resource low platfromokra, cross-comiler -el leforditasz mindent, az userlendet is bele ertve.
Vegre rajottem mirt akkarsz te azon forditani, mivel szinte mindenki massal elentetben, nem tudod hogyan
kene cross-forditani.

" de mennyi erőforrás és idő kell, amíg elkészíti őket?"
A kardinalis szempont , hogy egy tipukus "Resource low platfromokra" csak a fo gepem
40 szer gyorsabban fordit C -t, mint az adott masina (mondjuk PI4).
Es 6 gepem van uzemben, es ez csak itthon.
Nekem ido pocseklas megcsinalni , hogy menjen a fordito az adott cel hoszton is,
bar en is l'art pour l'art rajongo vagyok..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

De, én tudom, hogyan kell "cross-fordítani", csak éppen a cross-compile nem lehet megoldás minden helyzetben.

És már megint az, hogy te mit csinálsz, meg neked mid van... Kit érdekel, hogy te mit csinálsz, meg neked mid van? És akinek nincs?
Van, aki azért vett überolcsó 32-bites mini-PC-t, mert arra volt pénze. Átírtuk a szoftvereket Rust-ba, a tizedét nem fogja tudni fordítani rajta...

Nézd meg, lent már belinkelte neuron, hogy a GNU coreutils-t is át akarják már írni Rust-ba.

De itt a HUP-on nem az a mondás, hogy mindenki azzal tölti a szabadidejét, amivel akarja? Lehet, hogy ők látnak benne kihívást, kipróbálják, és ha tetszik, megtartják. Vagy kidobják.

Attól, hogy valaki valamit átír, az eredeti még nem veszik el.

Amúgy attól, hogy lehet, még nem kötelező Rustban kernel modult írni. Sőt, ha nem írsz kernel modult, nem tök mindegy, hogy miben nem teszed?

De itt a HUP-on nem az a mondás, hogy mindenki azzal tölti a szabadidejét, amivel akarja?

Addig amíg másnak nem okoz vele kárt.

Attól, hogy valaki valamit átír, az eredeti még nem veszik el.

Csak karbantartás nélkül marad, deprecated lesz, stb., szóval hosszútávon végül is elveszik.

Amúgy attól, hogy lehet, még nem kötelező Rustban kernel modult írni. Sőt, ha nem írsz kernel modult, nem tök mindegy, hogy miben nem teszed?

Ha megszakadok se értem az összefüggést az és az között, hogy valaki ír-e kernelmodult, vagy sem és ha Rustban újraír kernelmodulokat, akkor annak számos hátulütője lesz...

A C++-t bárhol lehet használni, ahol a C-t. De jó, azt elfogadom, hogyha valami fél bites mikrocontrollerre kell valamit csinálni, akkor oda jó a C is.

Ezt akkor engedtem el, amikor egy 8 bites mikrokontrolleren kellett és parseolnom egy bináris protokollt. Megírtam C-ben, majd C++ -ban, állapotgéppel megvalósítva. Az absztrakt C++ -ból a fordító kisebb kódot generált... Pedig szerintem a C-s megoldásom se volt szar.
Nem feltétlenül baj az absztrakció. A fordítók sokat fejlődtek.

Senki se mondja (már aki szakmailag komolyan vehető), hogy a C nyelv szar lenne. Arról van csak szó, hogy van már nála jobb nyelv bizonyos feladatokra. A C már majdnem 50 éves, így ez azért nem annyira meglepő fordulat. Ha valaki ma akarna létrehozni egy Linux kernel szintű rendszert, kétlem hogy C-ben írná meg. A programozónak véges mennyiségű figyelme van. Ha egy terhet levesznek a válláról, akkor más területekre több figyelmet tud szentelni.

A C már majdnem 50 éves

Ez így ebben a formában szerintem csúsztatás. Hiszen ritka, hogy valaki ANSI C-ben programoz. Inkább valamelyik későbbi standardben. A legutóbbi talán a C11, 2011-ből.
Szerintem inkább a nyelv félreértése és a misuse a gond sok esetben. Elfelejtik, hogy a C valójában egy Assembly, makrókkal.
Nem mondom, hogy mindent C-ben kell írni, de sok vita hátterében inkább ezt érzem.

Ha "a C valójában egy Assembly, makrókkal", akkor ez azt jelenti, hogy gyorsabb benne implementálni bármit mint tiszta Assembly-ben. Ha azt vesszük hogy a Rust bizonyos dolgokat lekezel a C-hez képest, akkor ott is igaz-e, hogy Rust-ban átlagosan gyorsabban lehet haladni mint egy mai C-ben?

Ez nagyon jó kérdés szerintem.  Azt gondolom, egyrészt - amint többen is írtuk már - : az adott emberek ismereteitől is függ a dolog.

Másrészt a fejlesztendő projekt becsült méretétől, komplexitásától.

Python-ban pl. jól érzem magam kb. 2000 - 5000 sorig, aztán piszkosul elkezd hiányozni a típusosság.  Valaki valahol módosított valamit (de az is lehet, hogy én, csak nem emlékszem rá), és máris rosszul használok egy objektumot, és lehet, hogy ez csak jövő héten derül ki, de ha most, akkor sem látom, hogy mitől romlott el.

Ehhez hasonló nekem a C -> C++ -> Rust átmenet is.  Kiváltképp, amíg nincs komolyabb Rust-rutinunk, mert az első sokk után, ami akár 1-2 hónap is lehet, már lehet ugyan programozgatni (lassan)...  de egyszercsak előugranak az élettartam-annotációk, amit eddig meg akartunk úszni...  aztán a lambda...  aztán a generikus szerkezetek...

Sőt, ha ez mind megvan, talán még akkor is lassabban lehet gépelni egy árnyalattal, mint C++-ban...  én legalábbis bevallottan így vagyok... csakhogy immár lényegében hibátlanul. :)  Ez több időt fog behozni maintenance-en, amit ráadásul általában utálunk is csinálni.

Senki se mondja (már aki szakmailag komolyan vehető), hogy a C nyelv szar lenne.

Pedig látod, itt egyel feletted geza42 is ezt mondta, pedig ő szakmailag komolyan vehető, csak ebben nincs igaza. Nem a C szar, hanem az emberek szarnak bele mindenbe, mert legyen kész tegnapra és a szerszámaikat szidják, arra kenik az egészet, hogy nem sikerült bugmentesen megírni tegnapra. Csak az a mentalitás, hogy legyen kész tegnapra, nehogy a cég elessen fél cent profittól, az Rust-ban is szart fog eredményezni.

Arról van csak szó, hogy van már nála jobb nyelv bizonyos feladatokra.

Ezt meg senki nem is vitatta. A C egy lowlevel nyelv, lowlevel feladatokra való. Hordozható assembly, ahogy szokták mondani rá. Nem alkalmazást kell benne írni, hanem lowlevel dolgokat. Az, hogy bizonyos lowlevel dolgokat meg lehet írni Rust-ban, az jó dolog, de előbb utóbb úgyis belefutsz abba, hogy vagy átmész unsafe-be és akkor kvázi ugyanott vagy, mint C-ben, vagy masszív lesz az overhead a C-hez képest.

A C már majdnem 50 éves, így ez azért nem annyira meglepő fordulat.

A C 52 éves, de ez nem jelent semmit. A C++ 42 éves, tilcsukbe? A Python 32 éves, tilcsukbe? A JS 26 éves, tilcsukbe? A PHP 26 éves, tilcsukbe?

Ha valaki ma akarna létrehozni egy Linux kernel szintű rendszert, kétlem hogy C-ben írná meg.

http://a.te.ervelesi.hibad.hu/szemelyes-ketely

A programozónak véges mennyiségű figyelme van. Ha egy terhet levesznek a válláról, akkor más területekre több figyelmet tud szentelni.

Ezt aláírom. De azzal indokolni egy nyelv használatát, hogy mert abban nem kell figyelni, az nagyon kontraproduktív és kontraindikált.

Na, azért nem azt mondtam, hogy "a C nyelv szar", hanem azt, hogy ebben a tekintetben szar. :) Ezt az állításomat továbbra is fenntartom.

Nem az van, hogy az emberek szarnak bele mindenbe. Persze, ez is van. Hanem az, hogy programozóként nem tudsz minden esetre felkészülni. Vagy ha igen, akkor az elképesztően nagy meló lenne, senki se csinál ilyet, sokkal lassabban menne a fejlesztés. Tehát jobb, ha a fordító leellenőrzi a memóriahozzáféréseket. Ahogy fejlődnek a compilerek, egyre jobban ki tudják szűrni, hogy mik a felesleges ellenőrzések.

Ha C-ben programozok, mindig ott van az a rossz érzés, minden egyes pointer indexelésnél, derefnél, hogy "vajon valid lesz itt ez a hozzáférés?". Nyilván az esetek 99.99%-ban az. De nem tudod 100%-ra felvinni ezt egy bonyolultabb programnál, vagy tényleg 1000x lassabban fogsz haladni.

Szerintem tök egyértelmű, hogy jobb, ha ott van egy automata ellenőrzés, ami tutira működik, vagy legalábbis kiszűri a hibák nagy részét. De ha nem is szűri ki compile-time, akkor runtime szűri ki. És nem vulnerability lesz belőle, hanem csak kilép a program (vagy esetleg exceptionnel kezeled le, és még tovább is tud menni).

Egy tökúj projectben tutira nem használnék C-t. Nem azért, mert régi. Ez nekem se lenne elfogadható érv. Hanem mert van szinte minden szempontból jobb megoldás nála.

Na, azért nem azt mondtam, hogy "a C nyelv szar", hanem azt, hogy ebben a tekintetben szar. :) Ezt az állításomat továbbra is fenntartom.

Oké, akkor ebben a tekintetben faék és megengedő, nem pedig szar. És ezt én is fenntartom. :P

Nem az van, hogy az emberek szarnak bele mindenbe. Persze, ez is van. Hanem az, hogy programozóként nem tudsz minden esetre felkészülni. Vagy ha igen, akkor az elképesztően nagy meló lenne, senki se csinál ilyet, sokkal lassabban menne a fejlesztés. Tehát jobb, ha a fordító leellenőrzi a memóriahozzáféréseket. Ahogy fejlődnek a compilerek, egyre jobban ki tudják szűrni, hogy mik a felesleges ellenőrzések.

Persze, hogy nem tudok mindenre felkészülni, de ez a Rust nyelv kitalálóira és a Rust fordító íróira és így végsősoron a Rust-ra is igaz, hogy nem tud mindenre felkészülni. Jó dolog, ha egy magasszintű nyelv ad bizonyos védelmi mechanizmusokat, de attól egy lowlevel nyelv nem lesz szar, mert az nem ad. Nem célja.

Ha C-ben programozok, mindig ott van az a rossz érzés, minden egyes pointer indexelésnél, derefnél, hogy "vajon valid lesz itt ez a hozzáférés?". Nyilván az esetek 99.99%-ban az. De nem tudod 100%-ra felvinni ezt egy bonyolultabb programnál, vagy tényleg 1000x lassabban fogsz haladni.

Mérlegelni kell, hogy ha ennyire kétséges, akkor esetleg egy validálást berakni elé. De most nem ezért, vagy azért, de ha a malloc() és tsai. NULL-t adott vissza, mert kifogytál a tárból, ott C++-ban mit fogsz kapni, ha az objektum konstruktora elszáll a memóriahiány miatt?

Szerintem tök egyértelmű, hogy jobb, ha ott van egy automata ellenőrzés, ami tutira működik, vagy legalábbis kiszűri a hibák nagy részét. De ha nem is szűri ki compile-time, akkor runtime szűri ki. És nem vulnerability lesz belőle, hanem csak kilép a program (vagy esetleg exceptionnel kezeled le, és még tovább is tud menni).

De ezt még mindig senki nem vitatta, hogy ez nem baj, hogy a nyelv levéd bizonyos dolgokat...

Egy tökúj projectben tutira nem használnék C-t. Nem azért, mert régi. Ez nekem se lenne elfogadható érv. Hanem mert van szinte minden szempontból jobb megoldás nála.

Minden esetben? Akkor is, ha valami egzotikus chipen kell futnia, össz 4k RAM-mal? A Rust hány architektúrát és hány OS-t is támogat? A C mennyit? Van, ahol nem is tudod a Rust-ot választani. Sőt, semmit nem tudsz választani a C helyett, mert nincs. Max. a C++-t, de azzal meg megint ugyanott vagyunk, hogy ha semmit sem használtál a supersetből, akkor az mitől is C++? (Vagy választhatod az assembly-t is, de abban még annyi komfort se lesz, mint a faék C-ben és onnantól a kódod sem lesz hordozható.)

Oké, akkor ebben a tekintetben faék és megengedő, nem pedig szar.

Megengedő, és emiatt rossz :).

Persze, hogy nem tudok mindenre felkészülni, de ez a Rust nyelv kitalálóira és a Rust fordító íróira és így végsősoron a Rust-ra is igaz, hogy nem tud mindenre felkészülni. Jó dolog, ha egy magasszintű nyelv ad bizonyos védelmi mechanizmusokat, de attól egy lowlevel nyelv nem lesz szar, mert az nem ad. Nem célja.

Igen, nem tud mindenre felkészülni. De ha választhatok, hogy 10% valszínűséggel kapok egy pofont, vagy 0.1% valszínűséggel, akkor inkább az utóbbit választom :) Igen, ez a baj a C-vel, hogy nem ad védelmi mechanizmusokat. Most erre mondhatod, hogy low level, nem célja, hogy adjon. OK, ez egy hozzáállás. Én azt mondom, hogy attól függetlenül, hogy low level, még adhatna védelmi mechanizmusokat. Ha a performance meg tud maradni, a low level is meg tud maradni, akkor mi a baj azzal, hogy esetleg még védelmi mechanizmust is kapsz? 

Mérlegelni kell, hogy ha ennyire kétséges, akkor esetleg egy validálást berakni elé. De most nem ezért, vagy azért, de ha a malloc() és tsai. NULL-t adott vissza, mert kifogytál a tárból, ott C++-ban mit fogsz kapni, ha az objektum konstruktora elszáll a memóriahiány miatt?

Ez az, hogy Rustban nem kell mérlegelned, megspórolhatod azt. Persze, ha a programod ettől függetlenül tartalmaz mondjuk egy túlindexelést, akkor baj lesz belőle. Csak nem mindegy, hogy sechole lesz, vagy csak egy sima, well-defined exit. A C++ le tudja kezelni a memóriahiányt is, ilyenkor dob egy exceptiont. Persze kérdéses, hogy ilyenkor hogyan tud továbbmenni a progi, hogy nincs memória. De, ha valami kritikus rendszert csinálsz, akkor felkészülhetsz ennek a lekezelésére, pl. a progi elején lefoglalod azokat az erőforrásokat, amik kellenek az out_of_memory-nak a kezeléséhez, és akkor ki tudsz lépni szépen. Vagy esetleg felszabadítasz valamit, és újrapróbálod az adott dolgot. De amúgy alapesetben nem gondolom, hogy ezzel bárki is foglalkozik. Az alap beállítású Linux alatt tutira nem, mert ugye a linux szeret több memóriát adni neked, mint amennyi van, szóval out_of_memory helyett OOM lesz, nem igazán szokott a malloc/new null-lal visszatérni alap linuxon.

De ezt még mindig senki nem vitatta, hogy ez nem baj, hogy a nyelv levéd bizonyos dolgokat...

Ok, akkor miről vitatkozunk? :)

Akkor is, ha valami egzotikus chipen kell futnia, össz 4k RAM-mal?

Nyilván ha nincs C++/Rust/whatever megoldás egy adott platformon, akkor marad a C. Erre utaltam valamelyik korábbi hozzászólásomban, hogyha nem muszáj, akkor nem használnék C-t. De ha muszáj, akkor nyilván nincs más megoldás. De mondjuk az az érv, hogy "ugyse használok semmit a C++ feature-eiből, ezért jó a C is", szerintem nem állja meg a helyét. Nem mindegy, hogy melyik compilert hívod meg? És ha mégis kell valami C++ feature, akkor meg ott van. Láttam nem egy olyan projectet ami ilyen gondolkodás mellett indult, C-ben. De aztán csak szükség lett volna C++-ra egy idő után arra, mert bizonyos dolgokat C++-ban jobban meg lehet oldani. De persze itt most nyilván olyan esetekre gondolok, amikor 2KB-d van a kódra, és 48 byte-od a data-ra, mert itt maga a fejlesztés se tart túl sokáig. Valszeg ha kész C-ben, akkor nem kell tovább birizgálni. De mondjuk én még egy ilyennek is C++-al állnék neki, mert egész egyszerűen nincs semmi okom C-t használni. 

Megengedő, és emiatt rossz :).

Ez nézőpont kérdése. :)

Ha a performance meg tud maradni, a low level is meg tud maradni, akkor mi a baj azzal, hogy esetleg még védelmi mechanizmust is kapsz?

Az, hogy nem marad meg a teljesítmény. A szükséges védelmi mechanizmusok bonyolultságától függően csökkenni fog. C-ben meg egy if lekezelni egy hibát.

A C++ le tudja kezelni a memóriahiányt is, ilyenkor dob egy exceptiont.

Amit le kell kezelni. Elmondanád, hogy miért szar a C egy if-ből álló nullpointer checkje és miért jó a C++ try/catch szerkezete, ami belül valójában egy if/elseif/elseif/stb.? A múltkor az xp-forrásos topicban kaptam az ívet, hogy le merem ellenőrizni a nullptr-t C-ben, hogy ez mekkora pazarlás, ugyanakkor meg C++-ban valid az exception-ök elkapása?

De, ha valami kritikus rendszert csinálsz, akkor felkészülhetsz ennek a lekezelésére, pl. a progi elején lefoglalod azokat az erőforrásokat, amik kellenek az out_of_memory-nak a kezeléséhez, és akkor ki tudsz lépni szépen.

Ezt nem lehet minden esetben eljátszani, pl. GUI programozáskor garantáltan nem.

De amúgy alapesetben nem gondolom, hogy ezzel bárki is foglalkozik.

Szerintem se nagyon törődnek vele és ez is egy potenciális sérülékenység lehet, ha elfogy a memória és utána mennek tovább.

Az alap beállítású Linux alatt tutira nem, mert ugye a linux szeret több memóriát adni neked, mint amennyi van, szóval out_of_memory helyett OOM lesz, nem igazán szokott a malloc/new null-lal visszatérni alap linuxon.

Én nem csak Linuxra fejlesztek, hanem BSD-kre, Solarisra, retrocomputerekre, underground OS-ekre...a Linux-specifikus malloc() viselkedést én nem vehetem alapnak.

Ok, akkor miről vitatkozunk? :)

Arról, hogy a C nem szar. :P Ez egy eszköz, amivel tudni kell bánni.

De mondjuk az az érv, hogy "ugyse használok semmit a C++ feature-eiből, ezért jó a C is", szerintem nem állja meg a helyét. Nem mindegy, hogy melyik compilert hívod meg? És ha mégis kell valami C++ feature, akkor meg ott van.

Én nem ezt mondtam, hanem azt, hogy ha nem használsz semmit a C++ cuccaiból, akkor C kódot írtál. De, tök mindegy, hogy melyik compilert hívtad meg, főleg, mivel a mainstream C compilerek nagy része már rég C++ compiler is. A lényeg, hogy hiába forgattad le C++ compilerrel azt a kódot, amit a C compiler is leforgatott volna; az C kód maradt.

És ha mégis kell valami C++ feature, akkor meg ott van. Láttam nem egy olyan projectet ami ilyen gondolkodás mellett indult, C-ben. De aztán csak szükség lett volna C++-ra egy idő után arra, mert bizonyos dolgokat C++-ban jobban meg lehet oldani.

Bizonyos dolgokat tuti. Stringkezelés. OOP. Kiterjesztett típusok. Operator overload. (Stb.) Ezek C++ alatt maguktól értetődnek, C-vel meg szopni, meg wrappelni kell. És ha nincs szükség ezekre? Vagy nincs hely/erőforrás ezekre?

De persze itt most nyilván olyan esetekre gondolok, amikor 2KB-d van a kódra, és 48 byte-od a data-ra, mert itt maga a fejlesztés se tart túl sokáig. Valszeg ha kész C-ben, akkor nem kell tovább birizgálni. De mondjuk én még egy ilyennek is C++-al állnék neki, mert egész egyszerűen nincs semmi okom C-t használni.

És mitől lesz az C++ kód? Mert gondolom nem OOP kódot akartál írni 2 kB kódtárral és 48 byte adattárral.

Amit le kell kezelni. Elmondanád, hogy miért szar a C egy if-ből álló nullpointer checkje és miért jó a C++ try/catch szerkezete, ami belül valójában egy if/elseif/elseif/stb.? A múltkor az xp-forrásos topicban kaptam az ívet, hogy le merem ellenőrizni a nullptr-t C-ben, hogy ez mekkora pazarlás, ugyanakkor meg C++-ban valid az exception-ök elkapása?

Nemtom mennyire vagy barátságban a C++-szal, hogy honnét induljak... A C++-os try/catch sokkal több, mint az if, belül egyáltalán nem az van, amit ezekszerint gondolsz. Hiszen ahol elkapod az exceptiont, az sokkal feljebb is lehet a call stacken, mint ahol dobtad. És közben szépen minden köztes fv-ben lerakott objectnek is meghívódik a destruktora. Manapság az exception nem úgy működik, hogy lesz a fv-ednek valami rejtett visszatérési értéke, amit a hívott oldal rejtve csekkolgat. Ha nem dobsz exceptiont, akkor nem is kell csekkolni semmit. Emiatt akár gyorsabb is lehet a kód, ha exceptionnal jelzed a hibát. A mostani C++ fordítók zero cost exceptiont használnak. Ami egy kicsit félrevezető név, mert csak akkor zero cost, ha nem dobsz exceptiont. Ha dobsz, akkor viszont az lassú. Viszont, erre a memóriaelfogyásos dologra tökéletes megoldás. Sehol se kell bajlódnod azzal, hogy csekkold a malloc() visszatérési értékét, hanem valahol magasabb szinten elkapod az out_of_memory exceptiont, és kész. Ha a resource-okat RAII-val allokálod (ez manapság teljesen alap), akkor minden automatán menni fog, minden resource amit a köztes fv-ek allokáltak felszabadul szépen mindenféle külön kezelés nélkül. Ugyanezt a logikát C-ben végigprogramozni kézzel... Hát, ha ilyen kódot kellene írnom C-ben, szerintem felmondanék.

Ezt nem lehet minden esetben eljátszani, pl. GUI programozáskor garantáltan nem.

Nyilván itt általában arról van szó, hogy ilyen memória elfogyás esetben menteni, ami menthető. Szóval a GUI-val nem igazán kell foglalkozni. Ki kell lépni, de úgy, hogy lehetőség szerint minden fontos adatot kiírni konzisztensen.

Arról, hogy a C nem szar. :P Ez egy eszköz, amivel tudni kell bánni.

A "szar" túlzás volt részemről, bár csak egy korábbi szóhasználatot ismételtem meg. Inkább azt mondanám, hogy már van helyette jobb. De mindegy, szerintem kb. elmondunk mindent ezzel kapcs., szóval hagyjuk :)

 

És mitől lesz az C++ kód? Mert gondolom nem OOP kódot akartál írni 2 kB kódtárral és 48 byte adattárral.

Ez csak egy légbőlkapott példa volt. De tudok mondani rendes példát is. C-ben írt kernelmodul, ahol a device drivernek a mindenféle paramétereit egy structban tárolják, és a modul betöltésekor szépen lépésről lépésre kitölti minden memberjét egy-egy fv. Nos, ezt C-ben úgy oldották meg, hogy a kitöltő fv-t kiemelték egy 20 soros macro-ba, majd kb. 10x meghívták különböző paraméterekkel, hogy a ~10 member értéke beállítódjon (mivel a fv-ek amik kitöltik a membereket, nagyon hasonlóak egymáshoz). Ha ezt C++-ban csinálom, megírom szépen template fv-ben, és kapok egy normálisabb megoldást. Lefordított kódméret ugyanakkora, nincs semmi hátránya a C-s megoldáshoz képest. De tudnék még ilyen példákat hozni.

A C++-os try/catch sokkal több, mint az if, belül egyáltalán nem az van, amit ezekszerint gondolsz. Hiszen ahol elkapod az exceptiont, az sokkal feljebb is lehet a call stacken, mint ahol dobtad. És közben szépen minden köztes fv-ben lerakott objectnek is meghívódik a destruktora. Manapság az exception nem úgy működik, hogy lesz a fv-ednek valami rejtett visszatérési értéke, amit a hívott oldal rejtve csekkolgat. Ha nem dobsz exceptiont, akkor nem is kell csekkolni semmit. Emiatt akár gyorsabb is lehet a kód, ha exceptionnal jelzed a hibát.

Nem erre gondoltam, hanem arra, hogy a kivételkezelés belül egy halom if-re és elseif-re fog fordulni, ami a keletkezett exception értékekkel dolgozik, vagy ez már nem így van? Hogy néz ki a végeredmény belül?

A mostani C++ fordítók zero cost exceptiont használnak. Ami egy kicsit félrevezető név, mert csak akkor zero cost, ha nem dobsz exceptiont. Ha dobsz, akkor viszont az lassú. Viszont, erre a memóriaelfogyásos dologra tökéletes megoldás. Sehol se kell bajlódnod azzal, hogy csekkold a malloc() visszatérési értékét, hanem valahol magasabb szinten elkapod az out_of_memory exceptiont, és kész. Ha a resource-okat RAII-val allokálod (ez manapság teljesen alap), akkor minden automatán menni fog, minden resource amit a köztes fv-ek allokáltak felszabadul szépen mindenféle külön kezelés nélkül.

Ez a zero cost amúgy sem túl tiszta, mert három C++ fejlesztő négyféleképpen magyarázza, Bjarne meg évszámtól függően.

Ugyanezt a logikát C-ben végigprogramozni kézzel... Hát, ha ilyen kódot kellene írnom C-ben, szerintem felmondanék.

C-ben erre nincs is szükség, hiszen a mechanizmusok sem ennyire bonyolultak.

Inkább azt mondanám, hogy már van helyette jobb.

Mire jobb és miben jobb? :) Hordozhatóságban alig hinném, hogy bármi übereli. Teljesítményben is kb. csak az assembly, de az is csak akkor, ha vagy nem "bonyolult" a CPU (spekulatív végrehajtás, OOO végrehajtás, stb.), vagy az assembly-ző kóder nagyon penge; egyéb esetben a C kb. jobb assembly kódot fog generálni, mint amit a kóder írna. (Ezt egyszer kiveséztük.)

De tudok mondani rendes példát is. C-ben írt kernelmodul, ahol a device drivernek a mindenféle paramétereit egy structban tárolják, és a modul betöltésekor szépen lépésről lépésre kitölti minden memberjét egy-egy fv. Nos, ezt C-ben úgy oldották meg, hogy a kitöltő fv-t kiemelték egy 20 soros macro-ba, majd kb. 10x meghívták különböző paraméterekkel, hogy a ~10 member értéke beállítódjon (mivel a fv-ek amik kitöltik a membereket, nagyon hasonlóak egymáshoz). Ha ezt C++-ban csinálom, megírom szépen template fv-ben, és kapok egy normálisabb megoldást. Lefordított kódméret ugyanakkora, nincs semmi hátránya a C-s megoldáshoz képest. De tudnék még ilyen példákat hozni.

Ezt C-ben is lehet, hogy ki lehetne egyszerűsíteni; ezt a Linux kernelben láttad, vagy nem publikus céges cucc?

a kivételkezelés belül egy halom if-re és elseif-re fog fordulni, ami a keletkezett exception értékekkel dolgozik

Ezt nem tudom, de szerintem nem ezen a részen megy el az idő nagy része. Kivéve persze ha egy csomó catch ág van mindenféle típussal.

 

Ez a zero cost amúgy sem túl tiszta, mert három C++ fejlesztő négyféleképpen magyarázza, Bjarne meg évszámtól függően.

Amennyire értem, eléggé tiszta miről van szó. A kódod ugyanúgy fut addig, amíg exceptiont nem dobsz. Nincs sehol se exceptionra ellenőrzés, hogy "vajon dobott-e ez a fv. exceptiont?". Hanem a throw sakkozza ki, azonnal azon a helyen, ahol dobódott, hogy mit kell csinálnia. Milyen destruktorokat kell meghívnia, és hogy melyik catch ágra kell ugrania. Ehhez pedig kell egy nagyobb táblázat, ami tartalmazza ezeket a dolgokat. De van valami nem tiszta neked, mondd, és talán tudom rá a választ.

 

C-ben erre nincs is szükség, hiszen a mechanizmusok sem ennyire bonyolultak.

Ez nem nyelvfüggő. Ha az a feladatod, hogy olyan programot írj, ami lekezeli az out of memory-t rendesen, akkor C-ben egy irgalmatlan nagy katyvasz lesz belőle. Minden malloc() visszatérési értéke ellenőrizve lesz, a resource-ok deallokálását kézzel kell végezni az összes esetben. Tele lesz rakat if-fel a kód. És goto-val is, ha a linux kerneles megoldást választod, ami egyébként valszeg a legjobb megoldás erre a problémára. A C++ kódon pedig kb. meg se fog látszani, hogy ilyet is tud, mert automatán működni fog. Meglehetősen nagy a különbség.

 

Mire jobb és miben jobb?

A hordozhatóságon kívül bármiben? De azért C++ elég sok mindenre van már, lássuk be, szóval a hordozhatóság se annyira probléma.

 

egyéb esetben a C kb. jobb assembly kódot fog generálni, mint amit a kóder írna. (Ezt egyszer kiveséztük.)

Lehet, nem emlékszek rá :) Remélem nem mondok magamnak akkor ellent, hogy ezzel a megállapítással nem értek egyet. Nagyon gyakran lehet javítani a compiler által készített kódon. Vagy ha nem is akar lemenni az ember asm-be, akkor is addig kell masszírozni a C kódot, amíg kb. azt a kódot nem látja az outputon, amit kb. vár. De amúgy igen, egy átlagos kóder ritkán csinána jobb kódot, mint egy fordító. De hogy ne a levegőbe beszéljek, itt egy példa: https://godbolt.org/z/zrzooa34x. Mindhárom elterjedt fordító meglehetősen rossz kódot csinál erre. De tudnék hozni egy rakat ilyen példát.

 

Ezt C-ben is lehet, hogy ki lehetne egyszerűsíteni; ezt a Linux kernelben láttad, vagy nem publikus céges cucc?

Nem igazán lehetett, mivel a változók típusa más volt, és picit másképp kellett kezelni bizonyos helyzeteket. Lehet, hogy lehetett volna 3-4 verziót csinálni, és akkor azokkal már szépen le lehetett volna kezelni. De C++-ban meg simán egy template megoldja. Céges cucc volt amúgy.

De van valami nem tiszta neked, mondd, és talán tudom rá a választ.

Az érdekelne, hogy a kivételkezelés milyen elemi szerkezetekre bomlik fel fordítás alatt. Ahhoz most nincs kedvem, hogy nekiálljak disasm listákat elemezni. :P

Ez nem nyelvfüggő. Ha az a feladatod, hogy olyan programot írj, ami lekezeli az out of memory-t rendesen, akkor C-ben egy irgalmatlan nagy katyvasz lesz belőle. Minden malloc() visszatérési értéke ellenőrizve lesz, a resource-ok deallokálását kézzel kell végezni az összes esetben. Tele lesz rakat if-fel a kód. És goto-val is, ha a linux kerneles megoldást választod, ami egyébként valszeg a legjobb megoldás erre a problémára. A C++ kódon pedig kb. meg se fog látszani, hogy ilyet is tud, mert automatán működni fog. Meglehetősen nagy a különbség.

Pontosan ezt szoktam csinálni, minden malloc()-ot ellenőrzök és ha elhasalt, deallokálok, lezárok, kiszállok. A mechanizmus bonyolultságán azt értettem, hogy a C++-os OOP mögött jóval több húzódik meg a háttérben, pl. a konstruktornál, mint egy-egy malloc(), tehát C-ben kevesebb dolgot kell lekezelni, felszabadítani, stb. Csak a C++ a sajátját automatice csinálja, C-ben meg kézzel kell.

A hordozhatóságon kívül bármiben?

Azért a teljesítményt és a binárisok méretét se felejtsük el. Tudom, van amikor a C++ gyorsabb és/vagy kisebb lesz. Kivétel erősíti a szabályt.

Remélem nem mondok magamnak akkor ellent, hogy ezzel a megállapítással nem értek egyet.

Annak nem mondtál ellent, amit a múltkor mondtál, mert akkor is ezt mondtad - és hosszas vita után meg is győztél - de a mondatod elejének a végével ellentmondtál, mert én elmondtam azt, amiről a múltkor meggyőztél, te meg mondod, hogy nem értesz egyet és utána elmondod ugyanazt, hogy assemblyben gyorsabb kódot lehet írni, mint C-ben, de nem az átlagos kódernek. Hát én ugyanezt mondtam. :)

BTW, a példának, amit adtál, mi lenne az optimális megoldása? Én ezt hoztam össze, így csak kétharmad annyi az assembly kód és elágazás sincs benne, viszont így mindenképpen 4 db memóriahozzáférés van, nem 2 vagy 4, mint ha logikai éssel kapcsolom őket össze.

Az érdekelne, hogy a kivételkezelés milyen elemi szerkezetekre bomlik fel fordítás alatt. Ahhoz most nincs kedvem, hogy nekiálljak disasm listákat elemezni. :P

Hát, a full exception handling meglehetősen bonyolult, és én se vágom mélyebben. De sokkal több dolog van az exceptionnal, mint ahogy az ember elsőre gondolná. Az alapötlet az, hogy a kód mellé generálódik egy nagy táblázat. Amiben le van írva az, hogyha a fv -ek bizonyos pontjain exception miatti kilépés van, akkor mit kell csinálni (melyik objecteknek kell a dtor-ját meghívni). És amikor runtime throw van, akkor a táblázatból kikeresi az aktuális instruction pointer-hez tartozó részt, és lefuttatja a szükséges dolgokat. Aztán szépen egyenként felmászik a stack-en, és mindegyik frame-ben megnézi ugyanezt, hogy milyen objectet dtor-ját kell meghívni. Ill., azt is, hogy milyen exception handlerek vannak ott bejegyezve, hátha van handler, ami le tudja kezelni az aktuális exceptiont. De ez ennél nyilván bonyolultabb, csak valami ilyesmi a lényeg.

Pontosan ezt szoktam csinálni, minden malloc()-ot ellenőrzök és ha elhasalt, deallokálok, lezárok, kiszállok.

Ez az, amit pl. meg tudsz spórolni, ha C++-t használsz C helyett. Itt szerintem teljesen egyértelmű a C++ előnye. Nagyon nem örülnék neki, ha minden allokálásnál csekkolgatnom kellene, hogy sikerült-e.

C-ben kevesebb dolgot kell lekezelni, felszabadítani, stb. Csak a C++ a sajátját automatice csinálja, C-ben meg kézzel kell.

Itt nem igazán értem mire gondolsz. Ha C-ben is OOP módon programozol, akkor ugyanazok a dolgokat csinálod kézzel, mint amit a C++ neked alapból megad. Nem látom, hogy hol van itt a "C-ben kevesebb dolog".

Azért a teljesítményt és a binárisok méretét se felejtsük el. Tudom, van amikor a C++ gyorsabb és/vagy kisebb lesz. Kivétel erősíti a szabályt.

Szerintem ebben nincs különbség a két nyelvben, feltéve, hogy almát hasonlítunk almával. Ha logikailag is ugyanazt kéred a két nyelvtől, akkor kb. ugyanazt fogod kapni. Pl., szokás összehasonlítani a qsort()-ot az std::sort-tal, mivel mindkettő rendez. És ugye ilyenkor mérlegelik, hogy melyik a jobb nyelv, a C v. C++. Pedig maga az összehasonlítás butaság. Azon kívül, hogy mindkettő rendez, teljesen más van mögötte. Ha akarom, akkor egyrészt C++-ból is meghívhatom a qsort()-ot, vagy éppenséggel csinálhatok egy olyan qsort()-hoz hasonló fv-t, ami az std::sort()-ot használja, de a felületén ugyanúgy fv ptr megy be, mint a qsort()-nak. Így nem fog minden típushoz külön std::sort fv. generálódni, és nem lesz akkora nagy kódnövekedés (de persze cserébe lassabb lesz). De a fordítottja is működhet: össze lehet tenni C-ben is egy SORT macro-t, ami aztán minden használatkor odagenerál egy rakat kódot.

te meg mondod, hogy nem értesz egyet és utána elmondod ugyanazt, hogy assemblyben gyorsabb kódot lehet írni, mint C-ben

Ok, bocs, figyelmetlenül olvastam kissé.

mi lenne az optimális megoldása?

Valami ilyesmi pl.: https://godbolt.org/z/Y5Gzqfb9K. Teljesen triviális amúgy, nem értem miért nem csinálja meg egyik fordító se. Simán 2 memóriahozzáférés, és egy cmp. Semmi branch.

Hát, a full exception handling meglehetősen bonyolult, és én se vágom mélyebben. De sokkal több dolog van az exceptionnal, mint ahogy az ember elsőre gondolná. Az alapötlet az, hogy a kód mellé generálódik egy nagy táblázat. Amiben le van írva az, hogyha a fv -ek bizonyos pontjain exception miatti kilépés van, akkor mit kell csinálni (melyik objecteknek kell a dtor-ját meghívni). És amikor runtime throw van, akkor a táblázatból kikeresi az aktuális instruction pointer-hez tartozó részt, és lefuttatja a szükséges dolgokat. Aztán szépen egyenként felmászik a stack-en, és mindegyik frame-ben megnézi ugyanezt, hogy milyen objectet dtor-ját kell meghívni. Ill., azt is, hogy milyen exception handlerek vannak ott bejegyezve, hátha van handler, ami le tudja kezelni az aktuális exceptiont. De ez ennél nyilván bonyolultabb, csak valami ilyesmi a lényeg.

Nem baj, ennyi is rávilágított a lényegre, köszi, hogy leírtad. Ez belül egy nagyságrenddel bonyolultabb, mint a C malloc()-jai, if-jei és free()-jei. Úgyhogy akkor vissza az eredeti kérdésre: miért szar a C-ben az a pár elágazás, az miért pazarlás és miért jó ez a sokkal bonyolultabb hibakezelési mechanizmus C++-ban?

Ez az, amit pl. meg tudsz spórolni, ha C++-t használsz C helyett. Itt szerintem teljesen egyértelmű a C++ előnye. Nagyon nem örülnék neki, ha minden allokálásnál csekkolgatnom kellene, hogy sikerült-e.

Egyértelmű a C++ előnye, ha időre mész, de ha teljesítményre, vagy sebességre? Abból, amit leírtál, már érthető, hogy miért lassú, ha ténylegesen dobódik egy kivétel; egyesével visszamászni a stack-en és végignézegetni, hogy mit kell meghívni? Hát ez nem csoda, hogy lassú, ha ténylegesen kivétel keletkezik.

Itt nem igazán értem mire gondolsz. Ha C-ben is OOP módon programozol, akkor ugyanazok a dolgokat csinálod kézzel, mint amit a C++ neked alapból megad. Nem látom, hogy hol van itt a "C-ben kevesebb dolog".

C-ben ha OOP módon programozok, akkor van egy struct-om, meg egy raklap függvényem, ami azon operál. Itt a "konstruktor" kimerül egy malloc()-ban és annak lekezelésében, ami itt egy darab if, C++-ban meg az van, amit leírtál és gondolom, maguk az OOP részek sem sima struct-okra fordulnak le, hanem ott is lesz mindenféle referenciatáblázattól elkezdve minden egyéb adat és láthatatlan segédrutin is.

Szerintem ebben nincs különbség a két nyelvben, feltéve, hogy almát hasonlítunk almával. Ha logikailag is ugyanazt kéred a két nyelvtől, akkor kb. ugyanazt fogod kapni.

A nyelv "rejtett" részeiről beszéltem, nem arról, hogy C++-ban direkt nem a qsort-ot hívom meg; amit te leírtál, ott nem is a nyelveket hasonlították össze. De ahogy leírtad, hogy mi van a C++ kivételkezelése között; C-ben ha a malloc() elhasal, azt egy darab if-el kezelem le, C++-ban meg kaphatom el a kivételt, amit a konstruktor elhasalása okozott, mögötte pedig az a mechanizmus húzódik meg, amit leírtál. A C egyértelműen kevesebb és gyorsabb kódot fog adni.

Valami ilyesmi pl.: https://godbolt.org/z/Y5Gzqfb9K. Teljesen triviális amúgy, nem értem miért nem csinálja meg egyik fordító se. Simán 2 memóriahozzáférés, és egy cmp. Semmi branch.

Látom, de ez a megoldás 64-bites CPU-t igényel. 32-bites CPU-ra forgatva háromszor ekkora kódot kapunk, két elágazással: https://godbolt.org/z/4x35TnrMh

miért szar a C-ben az a pár elágazás, az miért pazarlás és miért jó ez a sokkal bonyolultabb hibakezelési mechanizmus C++-ban?

Szerintem ez nem a velem való vitában jött elő, legalábbis én nem mondtam ilyesmit.

Egyértelmű a C++ előnye, ha időre mész, de ha teljesítményre, vagy sebességre? 

Ha most konkrétan ezt az out of mem-es példát nézzük, akkor egyértelmű a C++ előnye nem csak programozási időben, hanem teljesítményt nézve is. Leírtam már, de leírom még egyszer: ha nincs exception, akkor a kódod nem fut rá semmiféle ellenőrzésre. Amíg nincs exception, addig a C++-os verzió gyorsabban fog futni, mint a C-s verzió, mivel a C-s verzió ugye állandóan ellenőrizgeti a malloc() visszatérési értékét. És ebben az esetben mondjuk az exception-nak az overheadje, mikor ténylegesen eldobódik, valszeg senkit se érdekel, mivel az out of mem kezelése sokkal több időt fog elvinni.

C-ben ha OOP módon programozok, akkor van egy struct-om, meg egy raklap függvényem, ami azon operál. Itt a "konstruktor" kimerül egy malloc()-ban és annak lekezelésében, ami itt egy darab if, C++-ban meg az van, amit leírtál és gondolom, maguk az OOP részek sem sima struct-okra fordulnak le, hanem ott is lesz mindenféle referenciatáblázattól elkezdve minden egyéb adat és láthatatlan segédrutin is.

Hát, ezt nem igazán mondanám. Ha almát az almával hasonlítasz, akkor nem igazán van a C++-nak olyan overheadje, amire utalsz. Ha C-ben csak struct-od van, akkor C++-ban is használj csak struct-ot. Ha C-ben írsz valami fv-t, ami inicializálja a malloc() által visszaadott memóriaterületet, akkor C++-ban ctor-t írsz. És kb. tökugyanaz lesz belőle, nincs overhead. Ha C-ben fv pointerekkel csinálsz polymorphizmust, akkor C++-ban virtuális fv-t használsz, ami belül ugyanúgy fv pointer lesz, stb. Általánosságban elmondható magáról a nyelvről, kevés olyan dolog van benne, aminek olyan komoly overheadje van, ami mondjuk C-ben nem lenne, ha kézzel implementálod le. Nyilván lehetnek meglepő dolgok bizonyos esetekben, hogy a C++ fordító valamiből miért csinál valami olyasmit, amit nem vársz tőle, de némi tapasztalattal ezeket el lehet kerülni. Ill., persze, van pár olyan dolog sajnos, aminek van overheadje a "kényelem", vagy éppen egy rosszul megdesignolt ABI miatt. A C++ baromi bonyolult nyelv, nagyon sok idő kell hozzá, mire rendesen megtanulja az ember. A C-t sokkal könnyebb megtanulni. Szóval komoly befeketetést igényel, megértem, hogy sokan nem szeretik, feleslegesen bonyolultnak tartják (ennek egy része igaz is mondjuk). De ha megtanultad, akkor kapsz egy sokkal jobb eszközt, mint a C.

Inkább amúgy azzal van gond néha, hogy a C++-os alap megoldás nem annyira flexibilis, mint kéne. Pl., ha saját C-s OOP-d van, akkor ott azzal azt csinálsz, amit akarsz, úgy designolod meg, ahogy az neked jó. Ha a C++-os virtuális fv-es megoldást alkalmazod, akkor ott megvan, hogy az mit tud, és kész, nem tudod kibővíteni a designját. Hogy egy példát hozzak: 1-2x előfordult már, hogy tök jó lett volna 1-2 virtuális fv-nek a címét átírni az objectben, hogy későbbiekben másképp viselkedjen. Ezt  C++-ban, 1-2 speckó esetet kivéve nem lehet megcsinálni. De ha a saját OOP-det úgy designolod meg, hogy minden objectben ott vannak a fv pointerek (tehát nem csak 1 ptr van a virtuális táblára), akkor ott azokkal a pointerekkel azt csinálsz, amit akarsz. Flexibilisebb. Csak ugye azon az áron, hogy több dolgot kell kézzel megcsinálni.

A C egyértelműen kevesebb és gyorsabb kódot fog adni.

Nem, ahogy már utaltam rá. Ha sok exceptiont dobálsz, akkor igen, lassabb lesz mint az `if`-es megoldás. De ha kevés exception dobás van, akkor gyorsabb lehet. Meg, senki se kötelez rá, hogy exceptiont dobálj. Ha neked az nem tetszik, akkor kezeld a hibákat ugyanúgy, ahogy C-ben, a dolog megengedett. Linusnak is ez volt az egyik érve a C++ ellen, hogy az exceptionnak egy csomó minden hátránya van. Igen, ez igaz. Akkor nem kell használni, ennyi. De mondjuk bizonyos dolgokra még akkor is megéri használni. Pl., out of mem-re, vagy más rendkívül váratlan eseményre szerintem az ideális megoldás. A C++ ad egy nagyon nagy eszközkészletet a C-re építve, a programozóra van bízva, hogy ezek közül melyikeket használja.

Látom, de ez a megoldás 64-bites CPU-t igényel.

Igen, de szerintem nem ez a lényeg. Arról beszéltem, hogy a fordítók esetenként még tudnak nagyon szuboptimális kódot generálni, és hoztam rá egy aktuális példát.

Szerintem ez nem a velem való vitában jött elő, legalábbis én nem mondtam ilyesmit.

Onnan indult ki, hogy azt mondtad, hogy "A C++ le tudja kezelni a memóriahiányt is, ilyenkor dob egy exceptiont." én meg kérdeztem, hogy az miért is jobb, amikor sokkal bonyolultabb belül, mint a C-féle lekezelés. Aztán kiveséztük - illetve levezetted - hogy mi is van a C++-nál ilyenkor belül. És akkor most ismétlem a kérdést, hogy miért rossz és pazarlás C-ben az a pár elágazásnyi védelem, amikor a C++ egy nagyságrenddel bonyolultabb hibakezelést valósít meg?

Ha most konkrétan ezt az out of mem-es példát nézzük, akkor egyértelmű a C++ előnye nem csak programozási időben, hanem teljesítményt nézve is.

Akkor egy pillanatra álljunk meg, mert valamit nem értek. Ugye azt írtad, hogy "Az alapötlet az, hogy a kód mellé generálódik egy nagy táblázat. Amiben le van írva az, hogyha a fv -ek bizonyos pontjain exception miatti kilépés van, akkor mit kell csinálni (melyik objecteknek kell a dtor-ját meghívni)." Honnan tudja a C++, hogy mikor van a kód bizonyos pontjain exception miatti kilépés? Ezt hogy állapítja meg, ahhoz nem kell vizsgálat?
(Egyébként az előbb elfelejtettem leírni, de ennyi védelmi mechanizmussal a bináris mérete is nagyobb lesz C++-ban.)

Hát, ezt nem igazán mondanám. Ha almát az almával hasonlítasz, akkor nem igazán van a C++-nak olyan overheadje, amire utalsz. Ha C-ben csak struct-od van, akkor C++-ban is használj csak struct-ot. Ha C-ben írsz valami fv-t, ami inicializálja a malloc() által visszaadott memóriaterületet, akkor C++-ban ctor-t írsz. És kb. tökugyanaz lesz belőle, nincs overhead. Ha C-ben fv pointerekkel csinálsz polymorphizmust, akkor C++-ban virtuális fv-t használsz, ami belül ugyanúgy fv pointer lesz, stb. Általánosságban elmondható magáról a nyelvről, kevés olyan dolog van benne, aminek olyan komoly overheadje van, ami mondjuk C-ben nem lenne, ha kézzel implementálod le.

De akkor nem C++ kódot írtam C++-ban sem, hanem C kódot... Én most arról beszéltem, ha a C++ saját eszközeit használom pl. OOP-ra és nem struct-okkal dobálózok, mint C-ben. Persze, hogy ha ugyanazt írom meg C++-ban, mint C-ben, akkor ugyanazt kapom a végén, de itt az volt a kérdés, hogy a C++-os megközelítéssel lesz az extra mechanizmusok miatt extra kód és extra idő is.

Ill., persze, van pár olyan dolog sajnos, aminek van overheadje a "kényelem", vagy éppen egy rosszul megdesignolt ABI miatt.

Nem, én nem arról beszéltem, hogy az underlying cuccokban valami el van keffentve, az nem a C++ hibája...

A C++ baromi bonyolult nyelv, nagyon sok idő kell hozzá, mire rendesen megtanulja az ember. A C-t sokkal könnyebb megtanulni. Szóval komoly befeketetést igényel, megértem, hogy sokan nem szeretik, feleslegesen bonyolultnak tartják (ennek egy része igaz is mondjuk). De ha megtanultad, akkor kapsz egy sokkal jobb eszközt, mint a C.

Félreérted, én nem vagyok C++ hater, valamennyire tudok én C++-ban is programozni, csak messze nem annyira, mint C-ben. A TDE-be (egykori KDE3 utóda) sokat contribute-oltam, az is C++-ban van írva. Én nem vitatom a C++ előnyeit. (Ahogy a Rust-ét se.) Azt vitatom, hogy a C-nek ne lenne előnye. Hordozhatóság, többnyire sebesség és méret (nem csak memory allocation exception lehet, meg említetted a "kényelmi overhead-et" is), valamint az - ami másnak lehet, hogy inkább hátrány - hogy mindent lehet. (Tudom, a C++ sem szab túl sok gátat az embernek.)

Inkább amúgy azzal van gond néha, hogy a C++-os alap megoldás nem annyira flexibilis, mint kéne. Pl., ha saját C-s OOP-d van, akkor ott azzal azt csinálsz, amit akarsz, úgy designolod meg, ahogy az neked jó. Ha a C++-os virtuális fv-es megoldást alkalmazod, akkor ott megvan, hogy az mit tud, és kész, nem tudod kibővíteni a designját. Hogy egy példát hozzak: 1-2x előfordult már, hogy tök jó lett volna 1-2 virtuális fv-nek a címét átírni az objectben, hogy későbbiekben másképp viselkedjen. Ezt C++-ban, 1-2 speckó esetet kivéve nem lehet megcsinálni. De ha a saját OOP-det úgy designolod meg, hogy minden objectben ott vannak a fv pointerek (tehát nem csak 1 ptr van a virtuális táblára), akkor ott azokkal a pointerekkel azt csinálsz, amit akarsz. Flexibilisebb. Csak ugye azon az áron, hogy több dolgot kell kézzel megcsinálni.

Egyetértek. (És amikor valamelyik függvénypointerét elfelejti az ember belőni a megfelelő függvényre, akkor a környezetében ülőknek vastagon bővülni fog a szókincse. :))) )

Nem, ahogy már utaltam rá. Ha sok exceptiont dobálsz, akkor igen, lassabb lesz mint az `if`-es megoldás. De ha kevés exception dobás van, akkor gyorsabb lehet. Meg, senki se kötelez rá, hogy exceptiont dobálj. Ha neked az nem tetszik, akkor kezeld a hibákat ugyanúgy, ahogy C-ben, a dolog megengedett. Linusnak is ez volt az egyik érve a C++ ellen, hogy az exceptionnak egy csomó minden hátránya van. Igen, ez igaz. Akkor nem kell használni, ennyi. De mondjuk bizonyos dolgokra még akkor is megéri használni. Pl., out of mem-re, vagy más rendkívül váratlan eseményre szerintem az ideális megoldás. A C++ ad egy nagyon nagy eszközkészletet a C-re építve, a programozóra van bízva, hogy ezek közül melyikeket használja.

Oké, de akkor megint ott vagyunk, mint korábban már sokszor, hogy akkor C kódot írtunk, nem C++ kódot. Miért használjunk C++-t, vagy épp Rust-ot, ha nem használjuk az extra feature-jeiket? Én azt mondom, mindenre azt kell használni, ami ott a legoptimálisabb.

Igen, de szerintem nem ez a lényeg. Arról beszéltem, hogy a fordítók esetenként még tudnak nagyon szuboptimális kódot generálni, és hoztam rá egy aktuális példát.

Félreérted: értettem én, hogy mire adtad a példát, csak engem ettől függetlenül is érdekelne az optimális megoldás.

hogy miért rossz és pazarlás C-ben az a pár elágazásnyi védelem, amikor a C++ egy nagyságrenddel bonyolultabb hibakezelést valósít meg?

Én nem mondtam ilyet sehol, hogy rossz és pazarlás. Miből gondolod, hogy erről ez a véleményem? Mert amúgy nem ez... Hiába dumálok itt mondjuk exceptionokról amúgy, a saját hobbi dolgaimban én se használom, a sima visszatéréses megoldást jobban szeretem. Bár az out of mem kezelése mondjuk kivétel lenne, ott használnám az exceptionokat, ha érdekelne az out of mem. De nem érdekel :)

Honnan tudja a C++, hogy mikor van a kód bizonyos pontjain exception miatti kilépés? Ezt hogy állapítja meg, ahhoz nem kell vizsgálat?

Írtam már, de akkor úgy látszik az info áramlás nem a legjobb, vagy rosszul írtam le :) A throw csinálja. Mikor valahol meghívódik egy throw, akkor ő intézi az egészet. Szóval nem az van, hogyha throw van, akkor visszatér a fv "rendesen", csak valahova odaírja, hogy "exception volt", amit a hívó fél csekkol. Nincs semmiféle ilyesmi. Hanem az van, hogy a throw (ott, ahol az exception dobódik) keresi ki a táblázatból, hogy mit kell csinálnia. Felmászik a stack-en, exception handlert keres, közben meghívja a kilépett fv-ek dtor-át. Gyakorlatilag a throw-ból lesz egy goto, ami "kapásból" ráugrik a handlerre. Remélem így már világos. Szóval pl. tudnia kell arról, hogy hogyan kell a stack-en végigmászni. Ehhez a fordító csinál neki infot az ELF-be, ha jól emlékszek az .eh_frame section való erre. Meg tudnia kell, hogy a kód egy adott pontján melyik objectek élnek, hogy meg tudja hívni a dtor-okat. Ezeket mind el kell tennie táblázatba. És igen amúgy, emiatt a bináris mérete nagyobb lesz. De a bináris mérete attól is nagyobb lenne, ha ugyanezt a funkcionalitást te kézzel kódolod le. Az összes malloc() utáni ellenőrzés sincs ingyen, ill. az összes cleanup kód se. Még az is előfordulhat, hogy az exceptionos megoldás a kisebb (mivel eléggé kompakt formában tárolja a táblázatot). Bár mondjuk azért meglepődnék rajta :)

de itt az volt a kérdés, hogy a C++-os megközelítéssel lesz az extra mechanizmusok miatt extra kód és extra idő is.

Ha mondasz konkrét példát, akkor lehet tudok rá mondani valamit, de így... Milyen extra mechanizmusok? Épp ezt mondom, hogy szerintem ez egy rossz beidegződés, hogy a C++ "biztos odatesz felesleges, extra dolgokat". Általában nem tesz, mert nincs rá oka. Ha a C-vel analog dolgot valósítod meg, akkor nem lesznek felesleges dolgok. Persze lehet, hogy vannak kivételek, de általában ez igaz.

Félreérted, én nem vagyok C++ hater

Szerintem nem is mondtam ilyet. Meg amúgy nem is gondoltam.

Azt vitatom, hogy a C-nek ne lenne előnye. Hordozhatóság, többnyire sebesség és méret

Meg azt se mondtam, hogy a C-nek ne lehetne előnye. A hordozhatóság egyértelműen előnye, mert a legtöbb mindenre megvan. Bár így 2021-ben szerintem ez már nem akkora dolog mondjuk a C++-szal szemben, de valami különbség azért biztosan van. A sebességgel és mérettel viszont (szokás szerint) nem értek egyet. Rajtad, a programozón múlik, hogy hogyan használod. Nem a nyelv fogja meghatározni, hogy milyen sebességgel fog menni, ill., hogy mekkora lesz a kód. Hanem te, hogy a rendelkezésre álló eszközök közül melyikeket használod. Nem minden használt eszköznek van overheadje. Sőt, inkább az ellenkezője igaz, ugye az a mondás, hogy "pay what you use". Ami a core language-re igaz is szerintem nagy vonalakban. A standard library-re már kevésbé.

Oké, de akkor megint ott vagyunk, mint korábban már sokszor, hogy akkor C kódot írtunk, nem C++ kódot.

Mert attól még, hogy 1-2 feature-re nemet mondasz, még használhatod a maradékot. Nem lesz még belőle C kód. De mindegy, túlragoztuk a témát szerintem.

Félreérted: értettem én, hogy mire adtad a példát, csak engem ettől függetlenül is érdekelne az optimális megoldás.

Ezt nem annyira értem. 64-bites fordításnál egyik fordító se hozott optimális megoldást, viszont ha odatettem kézzel a memcmp-t, akkor már mindegyik kihozta az optimális megoldást, amit mutattam. Az az optimális megoldás. Ha arra gondolsz, hogy mi az a megoldás, ami minden esetben optimális (32 és 64 biten is), olyan valszeg erre a problémára éppen most nincs. Hacsak oda nem teszel egy #ifdef-et. Pont ez a baj, hogy még mindig nem lehet megbízni a fordítókban, és még mindig az asm-et kell lesni, hogy vajon mit ront el, és utána vajon hogyan lehet rávenni arra, hogy mégis legyen szíves valamennyire optimális kódot kipréselni magából. Ami akkor tud nagy örömet okozni, ha mindezt mondjuk 3 fordítóval is el kell játszani.

Én nem mondtam ilyet sehol, hogy rossz és pazarlás. Miből gondolod, hogy erről ez a véleményem? Mert amúgy nem ez...

Hát a múltkor még azt mondtad, hogy nálad ökölszabály, hogy nem ellenőrzöd a bemenetet, hogy gyorsabban menjen a kód.

Hiába dumálok itt mondjuk exceptionokról amúgy, a saját hobbi dolgaimban én se használom, a sima visszatéréses megoldást jobban szeretem. Bár az out of mem kezelése mondjuk kivétel lenne, ott használnám az exceptionokat, ha érdekelne az out of mem. De nem érdekel :)

Ok, akkor tárgytalan, mert akkor C++-ban is így csinálod, tehát nem fogod a C++ mechanizmusaival növelni a bináris méretét vagy a futásidőt. Csak akkor azt nem értem, hogy miért gondolod ennyire jónak a Rust-ot, ahol ez viszont kikapcsolhatatlan? :)

Írtam már, de akkor úgy látszik az info áramlás nem a legjobb, vagy rosszul írtam le :) A throw csinálja. Mikor valahol meghívódik egy throw, akkor ő intézi az egészet. Szóval nem az van, hogyha throw van, akkor visszatér a fv "rendesen", csak valahova odaírja, hogy "exception volt", amit a hívó fél csekkol. Nincs semmiféle ilyesmi. Hanem az van, hogy a throw (ott, ahol az exception dobódik) keresi ki a táblázatból, hogy mit kell csinálnia. Felmászik a stack-en, exception handlert keres, közben meghívja a kilépett fv-ek dtor-át. Gyakorlatilag a throw-ból lesz egy goto, ami "kapásból" ráugrik a handlerre. Remélem így már világos.

Lehet, hogy hülye vagyok, de nem, nem világos. Hogyan dől el, hogy throw lesz? Valamilyen vizsgálatnak történnie kell, amikor eldönti, hogy most dob egy kivételt, különben mi alapján dobja... Hogyan dől el, hogy meg fogja hívni a throw-ot?

Szóval pl. tudnia kell arról, hogy hogyan kell a stack-en végigmászni. Ehhez a fordító csinál neki infot az ELF-be, ha jól emlékszek az .eh_frame section való erre. Meg tudnia kell, hogy a kód egy adott pontján melyik objectek élnek, hogy meg tudja hívni a dtor-okat. Ezeket mind el kell tennie táblázatba. És igen amúgy, emiatt a bináris mérete nagyobb lesz. De a bináris mérete attól is nagyobb lenne, ha ugyanezt a funkcionalitást te kézzel kódolod le. Az összes malloc() utáni ellenőrzés sincs ingyen, ill. az összes cleanup kód se. Még az is előfordulhat, hogy az exceptionos megoldás a kisebb (mivel eléggé kompakt formában tárolja a táblázatot). Bár mondjuk azért meglepődnék rajta :)

Nyilván, ha ezt implementálom C-ben, akkor az is ugyanakkora lesz, mint C++-ban, csak C-ben nem így kezel hibát az ember. De egyébként nekem nem az a rész nem tiszta, hogy mi történik a throw után, hanem az, hogy mi történik a throw előtt, hogyan dől el, hogy throw fog történni?

Ha mondasz konkrét példát, akkor lehet tudok rá mondani valamit, de így... Milyen extra mechanizmusok? Épp ezt mondom, hogy szerintem ez egy rossz beidegződés, hogy a C++ "biztos odatesz felesleges, extra dolgokat". Általában nem tesz, mert nincs rá oka. Ha a C-vel analog dolgot valósítod meg, akkor nem lesznek felesleges dolgok. Persze lehet, hogy vannak kivételek, de általában ez igaz.

Épp az előző bekezdésben írtad, hogy "Szóval pl. tudnia kell arról, hogy hogyan kell a stack-en végigmászni. Ehhez a fordító csinál neki infot az ELF-be, ha jól emlékszek az .eh_frame section való erre. Meg tudnia kell, hogy a kód egy adott pontján melyik objectek élnek, hogy meg tudja hívni a dtor-okat. Ezeket mind el kell tennie táblázatba. És igen amúgy, emiatt a bináris mérete nagyobb lesz."

A sebességgel és mérettel viszont (szokás szerint) nem értek egyet. Rajtad, a programozón múlik, hogy hogyan használod. Nem a nyelv fogja meghatározni, hogy milyen sebességgel fog menni, ill., hogy mekkora lesz a kód. Hanem te, hogy a rendelkezésre álló eszközök közül melyikeket használod.

De ebben konszenzus van, hát ezt írtam le én is, már a legelején. Én csak arról beszéltem, hogy ha a C++-ban ugyanazt az algoritmust a C++ eszközeivel csinálod meg, akkor annak lesz némi méreti és sebességbeli overheadje. Ezt pár kommenttel feljebb is (meg most is) elismerted, pl. amikor a "kényelemre" hivatkoztál. És én nem azt mondtam, hogy ez baj, csak azt, hogy ez így van.

Mert attól még, hogy 1-2 feature-re nemet mondasz, még használhatod a maradékot. Nem lesz még belőle C kód. De mindegy, túlragoztuk a témát szerintem.

Igen, ha használod, akkor nem lesz C kód, de ha nem használtad, akkor C kód lesz, hiába C++ fordító fordítja. De szerintem is túlragoztuk.

Ezt nem annyira értem. 64-bites fordításnál egyik fordító se hozott optimális megoldást, viszont ha odatettem kézzel a memcmp-t, akkor már mindegyik kihozta az optimális megoldást, amit mutattam. Az az optimális megoldás. Ha arra gondolsz, hogy mi az a megoldás, ami minden esetben optimális (32 és 64 biten is), olyan valszeg erre a problémára éppen most nincs. Hacsak oda nem teszel egy #ifdef-et. Pont ez a baj, hogy még mindig nem lehet megbízni a fordítókban, és még mindig az asm-et kell lesni, hogy vajon mit ront el, és utána vajon hogyan lehet rávenni arra, hogy mégis legyen szíves valamennyire optimális kódot kipréselni magából. Ami akkor tud nagy örömet okozni, ha mindezt mondjuk 3 fordítóval is el kell játszani.

Igen, erre gondoltam, hogy mi az az optimális C felőli megoldás, ami mindenütt az és ezek szerint a válasz az, hogy nincs ilyen -> #ifdef. Erre voltam kiváncsi, köszönöm. :) (És akkor ezek szerint lehet, hogy 32 bitre már elég optimális volt az a kivonós is, amit fentebb írtam.)

Hát a múltkor még azt mondtad, hogy nálad ökölszabály, hogy nem ellenőrzöd a bemenetet, hogy gyorsabban menjen a kód.

Egy operációs rendszerben, ha már egy felsőbb réteg ellenőrizte a bemenetet, akkor igen, az alsóbb rétegeknek már felesleges ellenőriznie őket. Ott valami ilyesmiről volt szó. Ill., megjegyzem, hogy én ott utánamentem, és pontosan megnéztem, hogy mi okozta azt a hibát. Ott az se fogta volna meg a hibát, ha a paraméterek ellenőrizve vannak, mivel más jellegű volt a hiba.

De persze amúgy, ha mondjuk olyan OS-t fejlesztenék, ahol a biztonság lenne az első (és a perf. csak sokadlagos), akkor lehet, hogy minden fv.-be tennék ellenőrzéseket. Vagy csak egyszerűen Rustot használnék :)

C++ mechanizmusaival növelni a bináris méretét vagy a futásidőt

Nem a C++ mechanizmusaival így globálisan, hanem csak az exceptionokról beszélünk itt. Én a hobbi projectjeimben nem használom. Tökre nem ugyanaz. De egy csomó C++ feature-t meg használok. A Rustban pedig amennyire tudom, nincs is exception. A védőháló pedig kikapcsolható mint ugye tudjuk, ott az unsafe.

Lehet, hogy hülye vagyok, de nem, nem világos. Hogyan dől el, hogy throw lesz? Valamilyen vizsgálatnak történnie kell, amikor eldönti, hogy most dob egy kivételt, különben mi alapján dobja... Hogyan dől el, hogy meg fogja hívni a throw-ot?

Nyilván ott van valami vizsgálat, ami kiváltja a throwt, azt nem lehet megspórolni (hogyan is lehetne?). Mi nem erről beszéltünk, hanem arról, hogy mondjuk a malloc visszatérési értékét hogyan kezeled, kell-e ellenőrizni, ill. exception esetben mi történik.

// C:

void *malloc() {
  // nagy rettenet, ahol valahol van ilyen a kódban:
  if (nincs_mem) {
     return NULL;
  }
  return <valami_mem>;
}

// Ahol használod:
int fn() {
  void *p = malloc(333);
  if (!p) {
    return -3; // hibakód. A hibát végig kell görgetni az összes fv-en a main-ig, ha mondjuk az a terv, hogy szépen ki kell lépni.
               // tele lesz a program if-fel
  }
  // p-n dolgozunk
  return 42; // szuper!
}

// Ezzel szemben C++:

void *new() {
  // nagy rettenet, ahol valahol van ilyen a kódban:
  if (nincs_mem) {
     throw out_of_mem; // ez goto-zni fog a main-ben lévő handlerre, a catch-re. Tehát nem megyünk vissza az fn()-be
  }
  return <valami_mem>;
}

// Ahol használod:
int fn() {
  void *p = new(333);
  // hopp, itt nincs if. Se a forráskódban, se a lefordított asm-ben. Itt nem kell hibát kezelni. Meg sehol se, ahol new() van leírva a kódban.
  // Nincs a kódban egy darab if se, ami az out_of_mem-et csekkolná
  // p-n dolgozunk
  return 42; // szuper!
}

// Aztán mondjuk a main-ben:
int main() {
  try {
    // valami, ami meghívja az fn-t, lehet hogy 123 mélyen
  } catch (out_of_mem &) {
    // mikor ide érünk, már minden objectnek szépen lefutott a dtora, amik remélhetőleg felszabadítottak minden erőforrást, kiírtak minden file-t, stb.
    // Mindezt automatán, nem kellett érte tennie semmit a programozónak
    printf("out_of_mem, exiting..."); 
  }
}

Épp az előző bekezdésben írtad

De ez nem extra mechanizmus. Ha exceptionkezelést választasz, akkor tudod, hogy ez lesz mögötte. Azért választod, mert élni akarsz az exception kezelés előnyeivel. Eldöntöd, hogy nem akarsz a visszatérési értékekkel szívni, hanem szeretnéd, hogy a compiler megcsináljon helyetted dolgokat. Szóval ez nem egy olyan absztrakció, aminek olyan overheadje van, ami mondjuk C-ben nem lenne. Mert C-ben nincs is ilyen. Max. setjmp/longjmp-pal tudsz valami hasonlót csinálni, de az meg se közelíti azt, amit a C++ ad ebben az esetben.

Én csak arról beszéltem, hogy ha a C++-ban ugyanazt az algoritmust a C++ eszközeivel csinálod meg, akkor annak lesz némi méreti és sebességbeli overheadje.

Nincs minden C++ featurenek overheadje, pont ezt mondom. Sőt, a legtöbbnek nincs (jellemzően a core language-ben nincs overhead. A std libben vannak dolgok, amiket én se szeretek az overheadjük, vagy éppen a rossz tervezés miatt). Viszont a template-k miatt sokszor éppen előnye van a C++-nak a C-vel szemben. qsort() vs. std::sort, std::sort-tal alkalmasint sokkal gyorsabb kódot kapsz. Ha úgy tekintjük, hogy nem almát az almával, hanem hogy milyen eszközöket ad a kezedbe. De mindegy, szerintem ezt is túlragoztuk.

Mi nem erről beszéltünk, hanem arról, hogy mondjuk a malloc visszatérési értékét hogyan kezeled, kell-e ellenőrizni, ill. exception esetben mi történik.

De, én pont erről beszéltem, hogy vizsgálat az exception-öknél is kell, hogy legyen, csak nem értettem ezt a "csak akkor csinál bármit is, ha tényleg történik kivétel" mechanizmust. Tehát magyarán a mélyben ugyanúgy megvizsgálja, hogy kivétel keletkezett, mint ahogy a C megvizsgálja, hogy hiba történt; akkor mitől is lenne lassabb a C, ha ugyanúgy vizsgálja ez is a hibákat?

De ez nem extra mechanizmus. Ha exceptionkezelést választasz, akkor tudod, hogy ez lesz mögötte. Azért választod, mert élni akarsz az exception kezelés előnyeivel. Eldöntöd, hogy nem akarsz a visszatérési értékekkel szívni, hanem szeretnéd, hogy a compiler megcsináljon helyetted dolgokat.

Hát nem egészen, én megkérdeztem, hogy "C++-ban mit fogsz kapni, ha az objektum konstruktora elszáll a memóriahiány miatt?", te pedig azt válaszoltad, hogy "A C++ le tudja kezelni a memóriahiányt is, ilyenkor dob egy exceptiont."
Magyarán itt muszáj a kivételkezelést használnom, ha a konstruktor elpusztult, nem?

Nincs minden C++ featurenek overheadje, pont ezt mondom. Sőt, a legtöbbnek nincs (jellemzően a core language-ben nincs overhead. A std libben vannak dolgok, amiket én se szeretek az overheadjük, vagy éppen a rossz tervezés miatt).

Mondjuk olyat nem is mondtam, hogy minden C++ feature overhead-del jár.

De mindegy, szerintem ezt is túlragoztuk.

Szerintem is.

Tehát magyarán a mélyben ugyanúgy megvizsgálja, hogy kivétel keletkezett, mint ahogy a C megvizsgálja, hogy hiba történt; akkor mitől is lenne lassabb a C, ha ugyanúgy vizsgálja ez is a hibákat?

Bocs, de ennél jobban már nem írnám le, hogy mi van. Az előző hosszászólásomból meg kellene tudnod érteni. Ott van a kódpélda, kristálytisztán ki lehet olvasni a kommentekből, hogy mi van. Teljesen egyértelműen látszik, hogy a C++-s verzió gyorsabb akkor, amikor nem dobódik exception. A C-s verzióban ott az "if" a malloc után, a C++-osban pedig nincs "if" a new után.

Magyarán itt muszáj a kivételkezelést használnom, ha a konstruktor elpusztult, nem?

Ha azt a new operatort használod, ami exceptiont dob (ez a default amúgy), akkor muszáj exception kezelést használnod, igen. De ha nem azt használod, akkor meg nem. Van olyan new, ami null-lal tér vissza out_of_mem esetén. Kérdés mit értesz azon, hogy az obj ctora elszáll memóriahiány miatt. Ez ugye úgy működik, hogy először lefoglalja a memóriát, és ha az sikerült, akkor lefuttatja a ctor-t. De ha nem sikerült, akkor vissza fog térni null-lal (nothrow-s new. A throw-s new exceptiont dob akkor). Szóval ebben a tekintetben nem muszáj exception kezelést használnod. Itt megint csak az van, hogy választhatsz, a C++ megadja a lehetőségét. Ha nem akarsz, nem kell exceptionokat használni.

"A C++ le tudja kezelni a memóriahiányt is, ilyenkor dob egy exceptiont." Ez alatt azt értettem, hogyha mondjuk egy object ctor-a allokálna egy másik memóriablokkot, de nem sikerül, akkor a C++ szépen lepusztítja a félkész objectet (mert ugye félbe kell hagyni a ctor-t, hiszen nem tud leinicalizálódni), és továbbdobja az exceptiont. Mindezt úgy, hogy nem kell külön kódot írnod, hogy a félkész object resource-ai szabaduljanak fel. Tehát nem az van, hogy neked kell kézzel vacakolni a helyzettel, hanem megoldja neked az egészet a C++ automatán (feltéve, amit már írtam, hogy a resource-ok allokálását RAII módon végzed, de ez eléggé alap manapság).

A C-s verzióban ott az "if" a malloc után, a C++-osban pedig nincs "if" a new után.

Ott nincs, de valahol van, csak nem látszik. Most beszéltük meg, hogy valahol vizsgálnia kell, hogy kivétel keletkezett-e. A viszgálat C++-ban is megtörténik, csak nem látszik.

Ha azt a new operatort használod, ami exceptiont dob (ez a default amúgy), akkor muszáj exception kezelést használnod, igen. De ha nem azt használod, akkor meg nem. Van olyan new, ami null-lal tér vissza out_of_mem esetén. Kérdés mit értesz azon, hogy az obj ctora elszáll memóriahiány miatt. Ez ugye úgy működik, hogy először lefoglalja a memóriát, és ha az sikerült, akkor lefuttatja a ctor-t. De ha nem sikerült, akkor vissza fog térni null-lal (nothrow-s new. A throw-s new exceptiont dob akkor). Szóval ebben a tekintetben nem muszáj exception kezelést használnod. Itt megint csak az van, hogy választhatsz, a C++ megadja a lehetőségét. Ha nem akarsz, nem kell exceptionokat használni.

Tehát vagy megvizsgálom itt is NULL-ra, vagy belül a kivételkezelés vizsgálja meg, hogy sikerült-e a foglalás.

Ez alatt azt értettem, hogyha mondjuk egy object ctor-a allokálna egy másik memóriablokkot, de nem sikerül, akkor a C++ szépen lepusztítja a félkész objectet (mert ugye félbe kell hagyni a ctor-t, hiszen nem tud leinicalizálódni), és továbbdobja az exceptiont. Mindezt úgy, hogy nem kell külön kódot írnod, hogy a félkész object resource-ai szabaduljanak fel. Tehát nem az van, hogy neked kell kézzel vacakolni a helyzettel, hanem megoldja neked az egészet a C++ automatán (feltéve, amit már írtam, hogy a resource-ok allokálását RAII módon végzed, de ez eléggé alap manapság).

Oké, ezt én nem is vitattam, hogy C++-ban sokkal kényelmesebb megoldani, meg kevesebbet kell kódolni hozzá, én arról beszéltem, hogy C++-ban is lesz vizsgálat, tehát nem lehet gyorsabb a C-snél, akkor sem, ha nincs exception, hiszen azt le kell kezelnie, hogy volt-e exception, vagy sem, ami minimum egy vizsgálat és C-ben is ugyanannyi van, csak ott látszik az if.

Ott nincs, de valahol van, csak nem látszik. Most beszéltük meg, hogy valahol vizsgálnia kell, hogy kivétel keletkezett-e. A viszgálat C++-ban is megtörténik, csak nem látszik.

Nem. https://godbolt.org/z/Gr5xMszMG a cFn-ben ott a vizsgálat. a cppFn-ben nincs (ergo gyorsabban fut, ha nincs exception). A cppMalloc exception esetben vissza se tér, hanem kapásból a handerre ugrik (ezt belül intézi a __cxa_throw). Ennél jobban már tényleg nem tudom elmagyarázni.

Hát ebben az esetben maga a C++-os malloc dobja a kivételt, az így tényleg mínusz egy if, mert a vizsgálat odabennt történik, feltéve, ha a C++ nem a libc-ben lévő malloc()-ra wrappel, mert akkor viszont valahol van benne egy olyan is, hogy

ptr = malloc(size);
if (ptr == NULL)
{
	throw out_of_memory;
}

viszont generikusan ha a te függvényeid dobnak kivételt, akkor abban ugyanúgy meg kell vizsgálni, hogy kell-e kivételt dobni, tehát generikusan nem spórolod meg azokat az elágazásokat, csak másutt lesznek.

Nem csak mínusz egy if, hanem annyi, amennyire feljebb van az a kód, ami kezelni tudja az out_of_memet. Ha pedig azt nézem, hogy konkrétan hány ifet spórol meg az exception, amit nem kell leírni a kódba, az legalább annyi, ahány malloc-t leírsz a kódba. Nem csak egy.

ha a te függvényeid dobnak kivételt, akkor abban ugyanúgy meg kell vizsgálni, hogy kell-e kivételt dobni, tehát generikusan nem spórolod meg azokat az elágazásokat, csak másutt lesznek.

Nyilvánvalóan a hiba keletkezésének a feltételét nem lehet megspórolni sehogy, de ezt nem is mondtam.

Ha a hiba keletkezésének és lekezelésének a helye nem ugyanabban a fv-ben van (azért ez meglehetősen jellemző), akkor megspórolom az összes ifet, ami a hiba keletkezése és a handler között van. Tehát nem máshol lesznek, hanem nincsenek.

Úgy érted malloc hívások számából mínusz a throw-ok számával lesz kevesebb?

Legalább. De ha egy hibát propagálni kell felfelé, akkor lehet, hogy még több if-fel lesz kevesebb. Viszont, ha a new-t használod, akkor egy olyan if se lesz a programodban, ami az out of mem-et ellenőrizné.

Mi van, ha azt is tudni szeretném az exception-ből, hogy konkrétan melyik malloc hasalt el?

Vagy odateszel egy külön try/catch blokkot, vagy azon a helyen azt a new-t használod, amelyik nothrow-os (ebben az esetben akkor nem spóroltál if-et). Vagy becsomagolhatod a malloc()-t, és adhatsz paramétert a csomagoló fv-nek, ami ezt a paramétert beleteszi az exceptionba (vagy épp másik típusú exceptiont dobsz), így később azt le tudod kérdezni.

Oké, lassan kezd leesni, köszi a türelmet. :)
Az viszont még mindig nem tiszta, hogy mi történik, ha többszörös kivétel történik, pl. ha a kivétel dobása alatt a destruktor is égnek tartja a bakancsot. Erről csak egymásnak ellentmondó hablatyot láttam eddig a neten; a sima elágazásos lekezelésnél egyértelmű, hogy mit csinál az ember, ha két hiba is bekövetkezik.

Oké, lassan kezd leesni, köszi a türelmet. :)

Ennek örülök, nincsmit!

kivétel dobása alatt a destruktor is égnek tartja a bakancsot

Hát igen, a kérdés nagyon jó. Ha épp egy exception dobásának a kezelése folyik (hívódnak a dtorok), és egy új exception dobódik, akkor std::terminate() lesz a válasz. De csak akkor, ha ezt az új exceptiont nem kapja el egy azóta elindított try/catch block. Ha ez most nem teljesen tiszta, akkor hozom a példát. Tegyük fel, hogy a dtor így néz ki:

Valami::~Valami() {
  try {
    valamiFvAmiExceptiontDobhat();
  } catch (...) {
  }
}

És tegyük fel, hogy ez a Valami object le van téve valahova a stackre. Ha dobódik egy exception, akkor ugye végre fog hajtódni a Valami dtor-a. De ez is dobhat egy exceptiont (ha a valamiFvAmiExceptiontDobhat() dob egyet), miközben még az eredetileg dobott exception se kezelődött le. Tehát egyszerre 2 eldobott exception object is létezik. De ez ebben az esetben nem baj, mivel a valami-ben van try/catch, ami lekezeli ezt a második exceptiont. Tehát "nem jut ki" az exception a dtor-ból. Ezt csak a teljesség kedvéért mondtam el, sokan nincsenek ezzel az esettel tisztában. Tehát a teljes szabály bonyolultabb, mint hogy "exception dobás közben nem szabad másik exceptiont dobni".

Visszatérve, az std::terminate() pedig meghív egy user handlert, ami defaultból az std::abort()-ot hívja. Szóval csúnya vége lesz a történetnek. De amúgy felül lehet definiálni a terminate handlert. De mindenesetre ezért van az az ökölszabály, hogy dtor-ból ne dobjunk exceptiont. Ami egyébként szinte mindig betartható. Általában a resource-ok felszabadítása nem szokott hibával járni. De ha azzal is jár, általában sokat nem lehet tenni vele. Pl., nem annyira köztudott, hogy a "close()" is visszatérhet hibával, ami alkalomadtán network FS-en hibavesztéssel is járhat (elviekben). De sajnos sok mindent nem lehet vele kezdeni, max újra lehet írni a file-t.

elágazásos lekezelésnél egyértelmű, hogy mit csinál az ember, ha két hiba is bekövetkezik.

Egyetértek. Ahogy mondtam is korábban, a saját dolgaimban nem használok exceptionokat, mert igaziból nem szeretem, ill., nincs rá szükségem. De az out_of_mem kezelése kivételt képez, szóval ilyesmi durva esetekre szerintem jó eszköz lehet. Én teljes mértékben a visszatérési érték alapú hibakezelést preferálom, amivel tudom, hogy sokan nem értenek egyet, nem ez az elfogadott C++ körökben. De még senki se tudott meggyőzni arról, hogy az exceptionok jók az általános hibakezelésre (pedig amúgy nyitott lennék rá, csak a felhozott érveimre, kérdéseimre nem tudnak megnyugtató válaszokat adni). Szerintem több hátránya van, mint előnye. És ugye azért vannak az újabb nyelvek designerei között is olyanok, akik hasonlóan gondolkodhatnak. Se a go-ban, se a Rustban nincs az a klasszikus exceptionkezelés.

Nagyjából értem, tehát, ha exception közben a destructor is exceptiont-dob, akkor std::terminate() lesz a vége, azaz crash, mert nem tudnak lefutni a vészleálló mechanizmusok... Na most, az, hogy a destructor lehetőleg ne dobáljon exceptiont, az rendben van, de mi van, ha "a nyelv" (azaz valami built-in mechanizmus) dob alatta egyet? Olyan lehetséges? Pl. OoM esetén sem maga a konstruktor dobja, mert az kipurcant, hanem valamelyik mechanizmusa a C++-nak.

Egyetértek. Ahogy mondtam is korábban, a saját dolgaimban nem használok exceptionokat, mert igaziból nem szeretem, ill., nincs rá szükségem. De az out_of_mem kezelése kivételt képez, szóval ilyesmi durva esetekre szerintem jó eszköz lehet. Én teljes mértékben a visszatérési érték alapú hibakezelést preferálom, amivel tudom, hogy sokan nem értenek egyet, nem ez az elfogadott C++ körökben. De még senki se tudott meggyőzni arról, hogy az exceptionok jók az általános hibakezelésre (pedig amúgy nyitott lennék rá, csak a felhozott érveimre, kérdéseimre nem tudnak megnyugtató válaszokat adni). Szerintem több hátránya van, mint előnye. És ugye azért vannak az újabb nyelvek designerei között is olyanok, akik hasonlóan gondolkodhatnak. Se a go-ban, se a Rustban nincs az a klasszikus exceptionkezelés.

Na, most sikerült teljesen összezavarnod... :)))
Eddig arról győzködtél, hogy az exception-ök gyorsabban fognak működni, mint ha mindent elágazásokkal lekezelünk (már, ha nincs tényleges throw) és azt írtad, hogy felmondanál, ha neked egyesével kellene minden deallokációt és egyéb vacakot megírnod, ahelyett, hogy az exception lekezelné.
Rendben, hogy OoM-ról beszéltünk főleg, de kivételt bármi dobhat, ami után fel kell minden túrót szabadítani; socket error, file error, whatever error... Vagy C++-ban erre van valami egyéb megoldás is?

mi van, ha "a nyelv" (azaz valami built-in mechanizmus) dob alatta egyet?

Olyan nincs, hogy "csak úgy" dob a nyelv valami exceptiont. Pontosan specifikálva van, hogy mi dobhat exceptiont. OoM esetén maga a new operator dobja, ami szintén specifikálva van.

gyorsabban fognak működni, mint ha mindent elágazásokkal lekezelünk

Igen, de olyan sokat nem számít. Ha nem történik hiba, akkor a hibakezelő if-ek elég jól prediktálható branchek, szóval a különbség minimális. Itt az elvekről beszéltünk, hogy mondjuk a C gyorsabb, mint a C++. És akkor itt volt ez az ellenpélda, hogy nem feltétlenül. Kicsi a különbség, de attól még különbség. Bocsi, nem akartam félrevezető lenni.

 felmondanál, ha neked egyesével kellene minden deallokációt és egyéb vacakot megírnod, ahelyett, hogy az exception lekezelné.

Így van, de ezt tényleg erre a konkrét esetre írtam. Tehát ha az lenne a feladatom, hogy olyan kódot írjak, ami le tudja kezelni az OoM-et, de közben meg nem használhatok exceptionokat, akkor mondanék fel.

kivételt bármi dobhat, ami után fel kell minden túrót szabadítani; socket error, file error, whatever error... Vagy C++-ban erre van valami egyéb megoldás is?

Azért nem egészen. A C++ standard library nem sűrűn dobál exceptiont, inkább ott is visszatérési értékekkel operálnak, vagy éppen speckó state-be teszik az objectet hiba után (pl. streamek). De persze azért dobál exceptionokat is, de nem ez a jellemző. Maga a core language meg talán nem dob soha exceptiont, kivétel a new, de ebből ugye van nothrow-s verzió.

Saját magam pedig úgy kezelem a helyzetet, hogy nem használom a standard library-t egyáltalán, hanem mindenre saját megoldásom van, ami mindent hibakóddal kezel le (vagy éppen assert-tel, ha programozó hibáról van szó). Igaziból saját allokátorom is van, szóval a new-t se használom. Egyetlen egy helyen van leírva a kódban az, hogy new (egy placement new, hogy meghívja az ctort, szóval ez se az allokálás miatt van).

Olyan nincs, hogy "csak úgy" dob a nyelv valami exceptiont. Pontosan specifikálva van, hogy mi dobhat exceptiont. OoM esetén maga a new operator dobja, ami szintén specifikálva van.

Nem úgy értettem, hogy "csak úgy", hanem úgy, hogy kivételt kellett dobnia.

Itt az elvekről beszéltünk, hogy mondjuk a C gyorsabb, mint a C++. És akkor itt volt ez az ellenpélda, hogy nem feltétlenül.

Nem is azt mondtam, hogy feltétlenül, hanem azt, hogy általában, le is írtam, hogy "tudom, van amikor a C++ gyorsabb és/vagy kisebb lesz."

Bocsi, nem akartam félrevezető lenni.

Mindegy, így már tiszta, köszi, hogy kibeszéltük.

Azért nem egészen. A C++ standard library nem sűrűn dobál exceptiont, inkább ott is visszatérési értékekkel operálnak, vagy éppen speckó state-be teszik az objectet hiba után (pl. streamek). De persze azért dobál exceptionokat is, de nem ez a jellemző. Maga a core language meg talán nem dob soha exceptiont, kivétel a new, de ebből ugye van nothrow-s verzió.

Akkor itt volt az én fejemben a kavarodás; nem a nyelvnek az overheadjei ezek, hanem a hozzá kapcsolt stdlib-nek...

Saját magam pedig úgy kezelem a helyzetet, hogy nem használom a standard library-t egyáltalán, hanem mindenre saját megoldásom van, ami mindent hibakóddal kezel le (vagy éppen assert-tel, ha programozó hibáról van szó). Igaziból saját allokátorom is van, szóval a new-t se használom. Egyetlen egy helyen van leírva a kódban az, hogy new (egy placement new, hogy meghívja az ctort, szóval ez se az allokálás miatt van).

Magyarul majdnemhogy inkább C kódot írsz, mint C++ kódot? :) (A saját allokátor alatt mit értesz? Egy malloc()-ra épülő refcounteres wrappert, vagy szó szerint egy malloc() replacementet?)

Nem úgy értettem, hogy "csak úgy", hanem úgy, hogy kivételt kellett dobnia.

Akkor úgyanúgy baj van belőle. Tudni kell, hogy mik dobhatnak exceptiont.

Nem is azt mondtam, hogy feltétlenül, hanem azt, hogy általában, le is írtam, hogy "tudom, van amikor a C++ gyorsabb és/vagy kisebb lesz."

Ok :) Még azért annyit hozzátennék az exceptionhoz, hogy azért lehet az exceptionoknak is "rejtett" költsége, ami meg újra a return code-ok felé döntheti a mérleg nyelvét. Pl., úgy kell a kódot megírni, hogy exception safe legyen. Pl., ha exception dobás van, akkor se legyen memleak. A összes fv-t fel kellene annotate-elni, ami nem dob exceptiont, hogy a fordító ezt lássa, és olyan kódot tudjon generálni, ami nincs felkészülve az exceptionokra (és emiatt gyorsabb lehet). Szóval ez meglehetősen komplex témakör.

Akkor itt volt az én fejemben a kavarodás; nem a nyelvnek az overheadjei ezek, hanem a hozzá kapcsolt stdlib-nek...

Igen, jellemzően ez van. Legalábbis nekem magával a core language-vel nem nagyon van bajom overhead tekintetében. Viszont a standard library-val már sokszor "összevesztem". Pont ezért nem használom.

Amúgy közben eszembejutott még egy core language-s exception, a dynamic_cast is tud exceptiont dobni. De ezt is el lehet kerülni. Ha referenciára castolsz, akkor dobhat, ha viszont pointerre, a null-t ad az exception helyett.

Magyarul majdnemhogy inkább C kódot írsz, mint C++ kódot? 

Azért nem... az stdlibet nem használom. Meg az exceptionokat. Viszont kb. minden mást igen. Ez még mindig nagyon messze van a C-től.

saját allokátor alatt mit értesz?

Az allocator osztályom egy interface, bármit mögé lehet tenni. Van olyan, ami csak simán a malloc()-ra egy wrapper. De van debug allocator, aminek van egy csomó feature: sentinelt rak a blokk elé és mögé, amit le tud ellenőrizni (buffer túlírásra). Nyilvántartja a foglalt blokkokat, a foglalás helyét teljes call stack-kel, így lehet memleak-et detektálni. De van olyan allokátorom is, ami gyakorlatilag teljesen kitudja váltani a malloc()-ot.

A designak az is része, hogy minden object, ami allokálni akar, annak be kell adni allokatort. Tehát a különböző objectek különböző allokatort tudnak használni. Így pl., szépen lehet látni, hogy melyik subsystem mennyi memóriát eszik. Külön memory poolból tudnak dolgozni. Ha gyanús, hogy valamelyik subsystem leak-el, akkor csak arra be tudom kapcsolni a memleak detectiont (mert akkor annak a subsystemnek debugos allocatort adok, a többinek meg "simát"), stb.

Azért nem... az stdlibet nem használom. Meg az exceptionokat. Viszont kb. minden mást igen. Ez még mindig nagyon messze van a C-től.

Akkor lowlevel C++, vagy pure C++. :P
Mindenesetre azért csak eljutottunk odáig, hogy nem csinálok baromságot, amikor C-ben validálom a pointereket. :P

Van olyan, ami csak simán a malloc()-ra egy wrapper. De van debug allocator, aminek van egy csomó feature: sentinelt rak a blokk elé és mögé, amit le tud ellenőrizni (buffer túlírásra). Nyilvántartja a foglalt blokkokat, a foglalás helyét teljes call stack-kel, így lehet memleak-et detektálni.

Akkor ez nagyjából olyan, mint az én allokátorom C-ben, bár abban "sentinel" nincsen.

De van olyan allokátorom is, ami gyakorlatilag teljesen kitudja váltani a malloc()-ot.

Úgy érted, hogy chunk-szinten kezeli a memóriát, ahogy maga a malloc()? Ha igen, akkor azt hogyan hurcolod az OS-ek közt?

Mindenesetre azért csak eljutottunk odáig, hogy nem csinálok baromságot, amikor C-ben validálom a pointereket. :P

Nyilván egy API interface-én érdemes validálni a bemenetet. Az a felhasználási területen múlhat, hogy hogyan teszi meg az ember ezt. Szerintem az assert-et mindig érdemes odatenni. De ha mondjuk egy olyan API-t csinálsz, ami egy lib, ami egy másik programba lesz betéve, akkor lehet, hogy ennél többet nem érdemes csinálni. Ez koncepció kérdése. Viszont ha ez az API mondjuk egy OS-nek a syscalljai, akkor meg le kell ellenőrizni a paramétereket.

Úgy érted, hogy chunk-szinten kezeli a memóriát, ahogy maga a malloc()? Ha igen, akkor azt hogyan hurcolod az OS-ek közt?

Van neki egy backend allocatora, ami szolgáltatni tudja a memóriát. Ebből lehet olyan, ami brk()-val ad memet, vagy éppen mmap-pel, VirtualAlloc-kal, stb. És utána a backend allocator által visszaadott részekbe teszi bele a saját chunk-jait. Szóval össze lehet legózni mindenféle allokátort. Pl., a debug allocator se tud megállni a saját lábán. Van 2 backend allocatora, az egyik, amelyik magát a blokkot foglalja le (opcionálisan sentinellel), és van egy másik, amivel meg a blokkhoz tartozó debug adatok vannak lefoglalva.

Van egy "ChunkedAllocator" nevű cucc, aminek van 1 backendje. Ez a backendből foglal nagyobb blokkokat, és utána ezekből a nagyobb blokkokból szolgálja ki a kisebb kéréseket. És van olyan backend, ami mmap-et hív (unixon), és van olyan backend, ami meg VirtualAlloc-ot (windowson). De, ha akarod, akkor ezeket a backend-nek szánt allocatorokat is használhatod közvetlenül (mivel ugyanazt az allocator interface-t implementálják), csak ugye kisebb kérésekre nem lesz hatékony.

Csak az a mentalitás, hogy legyen kész tegnapra, nehogy a cég elessen fél cent profittól, az Rust-ban is szart fog eredményezni.

Igen, ebben maximálisan egyetértünk. Azonban a Linux kernel (és más nagyobb nyílt forrású kódok) fejlesztése nem a "legyen kész tegnapra" mentalitással készültek és mégis volt bennük számtalan memóriakezeléses hiba.

 

A C egy lowlevel nyelv, lowlevel feladatokra való.

Akkor inkább az a kérdés, hogy egy Linux kernel lowlevel-nek számít-e, vagy mondjuk az SSH? Mindkettőben volt már olyan RCE hiba, amit a Rust fordítás közben kiszúrt volna. Az unsafe kódrészlet valóban lehet problémás, de mivel expliciten meg van jelölve, a tisztelt programozó csak jobban figyel rá. Aki berakná a teljes forráskódot egy nagy unsafe blokkba, az amúgy se fog Rustot használni. :)

 

A C 52 éves, de ez nem jelent semmit.

De, sokat jelent. Az alapjait egészen más korban/környezetben tették le, amitől nem tud 100%-ban megszabadulni. A Python is jó példa, mert a Python 3-at lehet akár egy új nyelvnek tekinteni, mivel megszabadultak pár tervezési hibától, de maradt még benne néhány, amiket nehezebb kigyomlálni. Egy új nyelvnél megvan az az előny, hogy tanulhatnak a korábbiak hibáiból és az adott korszak hardverére fejleszthetik. 50 év múlva a Rust is jó eséllyel elavult lesz, hiába toldozgatják időközben.

 

mert abban nem kell figyelni

Egy konkrét hibaforrásra, mert arra figyel a fordító (mint ahogy már számos más dologra is). Lehet másra összpontosítani, mint te is írtad, számos helyen el lehet rontani a kódot, még akkor is, ha nincs benne memóriakezeléses bug.

Azonban a Linux kernel (és más nagyobb nyílt forrású kódok) fejlesztése nem a "legyen kész tegnapra" mentalitással készültek és mégis volt bennük számtalan memóriakezeléses hiba.

Volt bizony. A nem (csak) C-ben írt windows kernelekben meg még több. Akkor most...?

Az unsafe kódrészlet valóban lehet problémás, de mivel expliciten meg van jelölve, a tisztelt programozó csak jobban figyel rá. Aki berakná a teljes forráskódot egy nagy unsafe blokkba, az amúgy se fog Rustot használni. :)

Megint alulbecsülöd az emberi hülyeséget.

De, sokat jelent. Az alapjait egészen más korban/környezetben tették le, amitől nem tud 100%-ban megszabadulni. A Python is jó példa, mert a Python 3-at lehet akár egy új nyelvnek tekinteni, mivel megszabadultak pár tervezési hibától, de maradt még benne néhány, amiket nehezebb kigyomlálni.

Ennyi erővel ld. pink válaszát és a C11 is egy új nyelv, mert nem ugyanaz, mint a C89.

Egy konkrét hibaforrásra, mert arra figyel a fordító (mint ahogy már számos más dologra is).

Csak eddig nem igazán ez volt a mantra...

> A fokozott odafigyelést nem lehet eldobni, csak azért, mert a nyelv kivédi a memóriakezelési hibákat.

Abszolút egyetértek.

> Ha ilyen bullshitekkel leépíted az emberek figyelmét, ha fals biztonságérzetet adsz nekik, akkor rosszabb munkát fognak végezni és Rustban is szar kódot fognak írni.

A tapasztalatom ennek fordítottja: olyan problémaköröket értettem meg jobban a Rust megismerése alatt, amit C++-ban hosszú időn keresztül is csak sejtettem, így-úgy használtam.  Most sokkal jobban látom, hogy mi miért van.

Inkább az a kérdés foglalkoztat, hogy mekkora és milyen projektnél éri meg a ráfordított, kevésnek egyáltalán nem mondható tanulás, gyakorlás.

A tapasztalatom ennek fordítottja: olyan problémaköröket értettem meg jobban a Rust megismerése alatt, amit C++-ban hosszú időn keresztül is csak sejtettem, így-úgy használtam. Most sokkal jobban látom, hogy mi miért van.

Hogy neked ez a tapasztalatod a Rust-tal, az egy dolog, de az általános tapasztalat azt mutatja, hogy aki trágya kódot ír, az mindegy milyen nyelven írja.

Inkább az a kérdés foglalkoztat, hogy mekkora és milyen projektnél éri meg a ráfordított, kevésnek egyáltalán nem mondható tanulás, gyakorlás.

A tanulás mindenképp megéri, ha másért nem, hogy lásd, hogy miért jó, vagy nem jó.

Ellenpéldát adtál, nem cáfolatot. Az, hogy neked mi a tapasztalatod, az nem cáfolat. Fentebb geza42-nek mondtam a stack overflow segfault problémáját, ami 7 évig (az 1.20-as Rust-ig) volt a rendszerben. Az nem hamis biztonságérzet, ha nem működik a védelmi mechanizmus?

Bevallom, fölment bennem a pumpa, :) mert úgy látom, mintha egyik oldalon szakmai érveket engednél el a füled mellett, a másik oldalon szavakon kötözködnél.  De már rendben vagyok. :)

Cáfolom részletesebben.  Még egyszer, erről a mondatról van szó:

> > > Ha ilyen bullshitekkel leépíted az emberek figyelmét, ha fals biztonságérzetet adsz nekik, akkor rosszabb munkát fognak végezni és Rustban is szar kódot fognak írni

Többször látom úgy, mintha azt gondolnád, a nyelv sok automatizmust tesz a generált, futtatható kódba.  Nos, a lefordított kódon kívül semmit.  A standard library - a C++-hoz hasonlóan - tartalmaz hasznos eszközöket.  Ami ebből a biztonságot illeti, kb. ezekről van szó:

  • Rc<T> és Arc<T> - ezek olyanok, mint C++-ban a shared_ptr, semmi extra.
  • RefCell<T> - technikailag az előzőekhez hasonló bonyolultságú (azaz egyszerűségű).
  • Mutex, RwLock - szintén semmi váratlan, ami a lefordított kódjukat illeti.

A lényeg a fordítási idejű ellenőrzéseken van;  illetve a fenti 3 egyszerű, futásidejű cucc (meg még 1-2 ilyen) kombinálása a fordításidejű ellenőrzésekkel.

Azaz semmit nem csinál meg helyettem azokon túl, amit egy C++ is tud, viszont extrém pontosan megtilt mindent, amiből baj lehet.  Azaz nekem magamnak kell rájönnöm a megoldás hogyanjára.  Ez nehéz, de egészen építő folyamat tud lenni.

A segfault, amit mutattál (bár nem találtam meg konkrétan, de elhiszem Neked) jó fogás, látszik, hogy semmi nem tökéletes.  Szerencsére múló állapot volt.  Lesz még ilyen?  Simán lehet.  Megéri attól még Rustozni?  No, ez egy egészen más kérdés.  Nem szándékozom megválaszolni, mindenki döntse el magának, hogy Neki megéri-e.

mert úgy látom, mintha egyik oldalon szakmai érveket engednél el a füled mellett, a másik oldalon szavakon kötözködnél.

Az utóbbit biztos nem csináltam, a másik meg max. véletlen lehetett, ha valami felett elsiklottam.

Többször látom úgy, mintha azt gondolnád, a nyelv sok automatizmust tesz a generált, futtatható kódba. Nos, a lefordított kódon kívül semmit.

A lefordítandó kód mindenképpen absztrakció valamilyen szinten; a memóriakezelést pl. biztos, hogy bele kell, hogy rakja, legalábbis erről volt szó eddig.

Azaz semmit nem csinál meg helyettem azokon túl, amit egy C++ is tud, viszont extrém pontosan megtilt mindent, amiből baj lehet.

Aztán láthatod hg2ecz példakódján, hogy hiába tiltotta meg a program nagy részén a veszélyes dolgokat, egy sornyi unsafe felborította az egészet, úgy, hogy konkrétan a crash-t előidéző sor safe módban van.

A segfault, amit mutattál (bár nem találtam meg konkrétan, de elhiszem Neked) jó fogás, látszik, hogy semmi nem tökéletes. Szerencsére múló állapot volt.

Hát ez az, hogy nem múlt még el, mert ahol az LLVM nem támogatja a stack probing-ot, ott még mindig megvan.

Lesz még ilyen? Simán lehet. Megéri attól még Rustozni? No, ez egy egészen más kérdés. Nem szándékozom megválaszolni, mindenki döntse el magának, hogy Neki megéri-e.

Dehát ki mondta, hogy nem éri meg Rust-ozni? Én még mindig az indokolatlan C-hating ellen beszélek és nem a Rust ellen. Csak arra hívtam fel a figyelmet, hogy a Rust biztonsága túl van dimenzionálva, ld. az eddigi példákat. Az lehet, hogy a C-nél biztonságosabb, de azt meg nem nehéz... :P A két nyelv nem ugyanarra való.

\0 terminalt stringek nem mindig legjobb valasztas.
Lehet hogy midkettot vissza dobom ;-)

ill lehet, hogy egy korabbi kod resz biztositja, hogy ne legyen gebasz.
-> jelentheti azt hogy valami memcpy  valtozattal jobban jarsz
-> jelentheti azt hogy strcpy gyorsabb megoldas, es ugyan ugy biztonsagos.

Sot meg azert is vissza lehet dobni egy cpy -t,
ha  megoldhato copy nelkul biztonsagosan.

Pl. az eredtei nagyobb string-re nem lesz szukseg, minde szukgseges resz string utan van legallabb egy byte ami nem kell vagy 0,
akkor lehet pointer hegyeket hasznalni akkar 0 terminalt stringekel.
Egyebkent slice szeru dolog (pl. iovec)..

Most jon az a resz, hogy fel lehet szabadatinai a nagy stringet rosz idoben..

Ill minek oszze rakni egy nagy stringet, ha a rendszer hivas maga is oszze tudja rakni (pwritev) az irashoz...

 

 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Magam is mindig strncpy() párti voltam, amíg C-ben programoztam. Sőt, utána explicit terminálom a sztringet nullával sizeof()-nál, mert az strncpy() is tud olyat, hogy pont végigírja a célterületet és nem lesz terminálva.

Már nem C-zek aktívan, de bevallom meglep, hogy sokan natívan kezelnek sztringet meg memóriát. Sok esetben mi is így csináltuk, de vannak azért erre lib-ek, amik tudnak slice allokációt, automatikus újraallokálást, stb. Nyilván nem performance kritikus helyeken használja ezeket az ember, de vannak.
Valamint a C fordítónak vannak módjai. Mi pl. C89-ben kódoltunk, amikor ebben igazán aktív voltam, tizenévvel ezelőtt.

Sokan azt sem veszik tudomásul, hogy a fejlesztés fontos részeit képezik az egységtesztek, amiket nem lehet félvállról venni.
Voltak saját fejlesztésű tesztjeim is pl. memory leak ellen. Mert főleg firmware komponenseket írtam, amik folyamatosan futnak.

nem az a lényeg, hogy az új jobb legyen, hanem az, hogy a régi pusztuljon

Rust eseteben de. Azert azt neked is be kell ismerned, hogy az elmult cca. 50 ev nem mult egy nyomtalanul a C-n. A libc/stdlib otvar, thread-eket is ugy kellett rapatkolni, es meg egy nyamvadt string concat-hoz is kezzel kell allokalni. Nincs kozponti csomagkezelo (lasd cargo/maven/npm...), dependency lib-ek nagy szopas deploy-nal. A tokolodes Makefile-okkal meg autotools-al. Es meg hosszu a lista.

En szeretem a C-t, foleg a bantoan egyszeru syntax miatt. Meg a jo teljesitmenye miatt, hogy kb. majdnem assemblerben irsz kodot. De az osszes tobbi, na az egy okadek igy anno 2021-ben.

Nem mondom, sokmindent javitottak rajta. Van glib meg egy par egyeb lib, de osszessegeben egy modern platformmal nem tud versenyezni.

 

Ami nagyon ut, az a borrow checker. Mert a Rust ugye alapvetoen egy garbage collectorral indult anno. Ez az otlet, hogy legyen tulajdonosa minden objektumnak, ez egy nagyon uj otlet, es a GC kidobasa is ennek a kovetkezmenye. Meg a buffer under/overflow is. De emellett meg a multi-threading problemat is megoldja az, hogy csak 1 thread lehet a tulajdonos. Emellett meg lehet frankon extra optimalizaciokat csinalni forditoban, hiszen a fordito pontosan tudja a kod forgatasakor, hogy az adott blokk modosithatja-e az objektumot. Meg meg rengeteg egyeb jon ebbol az otletbol, hogy igenis legyen tulajdonosa minden objektumnak.

Emellett a Rust szakitott az OO modellel is. Ez megintcsak egy nagy lepes volt. Nincs oroklodes. Van adat (struct), van interface (trait) meg van implementacio/kod.

Erdemes megismerkedni vele, mert borzasztoan mas, mint a C, de egyerteluen nagyon eloremutato!

Rust eseteben de.

Maximum egyes emberek esetében de.

Azert azt neked is be kell ismerned, hogy az elmult cca. 50 ev nem mult egy nyomtalanul a C-n.

Nem hát, ez is fejlődött.

En szeretem a C-t, foleg a bantoan egyszeru syntax miatt. Meg a jo teljesitmenye miatt, hogy kb. majdnem assemblerben irsz kodot. De az osszes tobbi, na az egy okadek igy anno 2021-ben.

Ennek megfelelően C-ben lowlevel kódot írunk, nem az összes többit. Egyébként a teljesítmény és az egyszerűség mellől kihagytad a hordozhatóságot.

de osszessegeben egy modern platformmal nem tud versenyezni.

Miben nem tud velük versenyezni? Teljesítményben? Hordozhatóságban?

Ami nagyon ut, az a borrow checker. Mert a Rust ugye alapvetoen egy garbage collectorral indult anno. Ez az otlet, hogy legyen tulajdonosa minden objektumnak, ez egy nagyon uj otlet, es a GC kidobasa is ennek a kovetkezmenye. Meg a buffer under/overflow is. De emellett meg a multi-threading problemat is megoldja az, hogy csak 1 thread lehet a tulajdonos. Emellett meg lehet frankon extra optimalizaciokat csinalni forditoban, hiszen a fordito pontosan tudja a kod forgatasakor, hogy az adott blokk modosithatja-e az objektumot. Meg meg rengeteg egyeb jon ebbol az otletbol, hogy igenis legyen tulajdonosa minden objektumnak.

És hol jönnek ezek be, ha épp mikrokontrollerre írsz hordozható assembly-t? Én komolyan nem értem, hogy miért mindig a C-vel hasonlítják össze a Rust-ot, amikor teljesen másra valóak.

Emellett a Rust szakitott az OO modellel is. Ez megintcsak egy nagy lepes volt. Nincs oroklodes. Van adat (struct), van interface (trait) meg van implementacio/kod.

Az OOP is nagy varázslat volt, hogy az majd minden problémát megold, amit C-ben nem lehetett...aztán kiderült, hogy messze több problémát hozott, mint amennyit megoldott, mert az emberek nem tudták használni. A C meg maradt. Időről-időre megpróbálják leváltani a C-t, de eddig még senkinek sem sikerült, pedig sok nyelv és sok paradigma próbálta.

Miben nem tud velük versenyezni? Teljesítményben? Hordozhatóságban?

Toolingban pl. a modern technológiák jobbak, a rust-alanyzer pl. zseniális.

Plusz pl. egy Android UI alkalmazás vagy egy REST service Swaggerrel és TLS-sek biztosan nem egy nap alatt készül el (produktivitás) C-ben.

Amúgy a hordozhetóság akkor számít, ha hordozni akarod a kódodat. Ha nem, akkor tökmindegy.

A sok OS között a hordozhatósággal van probléma. Főleg ablakozás terén.
Android, IoS telefonalkalmazás főleg állatorvosi ló.

A Rust elsősorban 4 területet tűzött ki (ma még legalábbis):
   - Command Line - cmd alkalmazások
   - WebAssembly (WASI is!)
   - Networking - démonok
   - Embedded - na itt azért vannak furi dolgok, amit nehezen emésztek még.
Persze GTK és társai modulok is vannak a https://crates.io oldalon, de nem ez a fő célterület.

Architektúra terén:
   - https://doc.rust-lang.org/nightly/rustc/platform-support.html ... van sokminden. Fusd át.
   - 32 bites mikrovezérlők (ARM, MIPS) is benne vannak, AVR32 nincs, a népszerű AVR8 no-std-vel van. Új procik terén RISCV szintén van. Egyeseknél a https://crates.io -n komplett libek vannak már.
   A "host" annyit jelent itt, hogy azon a targeten maga a cargo + rustc is futtatható, nem csak mint target szerepel.

Cross compilingot is csináltam Rust esetén. Mind x86 -> ARM, mint olyat hogy Linux alól fordítottam Windows parancssoros alkalmazást. Futott.
ARM esetén ha single-board-computer, akkor oda telepítek fordítót és helyben fordítok (512 MB RAM-os legkisebb SBC-n is elfutott a Rust fordító). De a cross-compiling is megy.
ARM mikrovezérlőre (STM32-re írtam kódot) értelemszerűen cross-compiling.

"AVR32 nincs"
https://www.avrfreaks.net/forum/avr32-dead-long-live-what

AVR32 -t atmel valoszinuleg csak azert csinalta, hogy
ne fuggjon az ARM -tol es megsporojon nemi license dijat.
Akkori egyszerubb ARM -okkal felvette versenyt, de a maiakkal szemben mar nincs eselye.

Mindegy, legalabb novelte a mar irtam ra valamit archok szamat ;-)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

A sok OS között a hordozhatósággal van probléma. Főleg ablakozás terén.

Ezeket le szoktam kezelni, bár az ablakozás az tényleg komoly gond. (Az ablakos cuccokat inkább Pascalban írom meg.)

Architektúra terén:

Csupa mainstream cucc. Mikor lesz pl. OpenBSD/PowerPC64-re? MorphOS/PowerPC-re? Utóbbi még a Tier 3 listán sincs rajta.

Ha már nyelvekről diskurálunk, és említve lett, Pascal-os kérdésem lehet?

Kíváncsi lennék a gyakorlati tapasztalatokra vele. Például a futó kód megközelíti-e a C-ben írt teljesítményét? Vannak-e jól használható lib-ek hozzá? Mennyire állja meg a helyét így 2021-ben más nyelvekkel összevetve? Mire való leginkább? Mit lehet szeretni benne?

Például a futó kód megközelíti-e a C-ben írt teljesítményét?

Ha generikusan kéne válaszolnom, akkor az lenne a válasz, hogy esélytelen. De mint fentebb is írtam, a futó kódoknál a legtöbbször a szűk keresztmetszetet nem a nyelv, hanem az alkalmazott algoritmus adja. Egy jól megkonstruált algoritmus überelni fogja szart, akkor is, ha a jót Java-ban, vagy C#-ban írták, a rosszat meg assemblyben. És akkor ott jön még az, hogy az algoritmus még lehet is azonos, de az implementáció is eltérhet. Végy egy raklap mátrixműveletet, pl.; azt Pascalban (és pl. C++-ban) megcsinálhatod úgy, hogy megalkotod a mátrix típust az elemi típusokra alapozva és overload-olhatod az operátoraidat és aztán leírhatod, hogy MResult := M1 * M2;, míg C-ben gyakorlatilag tömbökkel - vagy struct-okkal - fogsz dobálózni és úgy írod le a szorzást, hogy MResult = matrix_multiplying(M1, M2);

A Pascalnak ugyanúgy megvannak az extra feature-jei és mechanizmusai, mint a C++-nak, amik nincsenek ingyen, kódmérettel és teljesítménycsökkenéssel fizetsz értük, viszont nem kötelezőek, le is cserélheted őket, meg kódolhatsz C style-ban is.
Maga a kódgenerátor, hogy mennyire ad optimalizált kódot; valószínűleg alul fog maradni a C-hez képest, de platformja is válogatja.

Vannak-e jól használható lib-ek hozzá?

Vannak, bár távolról sem annyi, mint a populárisabb nyelvekhez, viszont az "alapfelszereltség" az übereli mindét. C-ben és C++-ban kb. indulsz egy pucér fordítóval (jobb rendszereken valamiféle libc-vel) és aztán vadászhatod össze a libjeidet, vagy C++-nál felrakhatod valamelyik Qt-t, ami mindent is tud (jó sok tárhelyért, meg jó nagy kapott binárisokért), míg a Pascal alapból ad egy akkora librarytömeget, amiben a hálózat - és hálózati protokollok! - kezeléstől elkezdve az adatbázisokon át mindenféle egzotikus baromságig minden van benne.
A Pascalt továbbá nyugodtan össze lehet kötni más nyelvekben írt .o és .so fájlokkal; ha van valami forrásod C-ben, vagy C++-ban, akkor leforgatod object-nek, aztán Pascalban írsz egy mezei wrapper unit-ot, ami az adott object fájl szimbólumaira támaszkodva hívogatja a lib függvényeit és az SO-nál ugyanígy működik. (Ha a célbináris a C-féle függvényhívó konvenciókat használja, akkor a wrapperben a wrapper bejegyzéseknél ezt definiálni kell cdecl-el.)

Mennyire állja meg a helyét így 2021-ben más nyelvekkel összevetve?

Az attól függ, milyen nyelvvel hasonlítod össze és hogy mi a vizsgált témakör. :)
Én azt mondanám, hogy nagyjából azt hozza, amit a C++, hol többet, hol kevesebbet, de leginkább azzal van értelme összemérni. Amiben pl. biztos übereli a C-t és a C++-t az az ablakkezelés és a cross-platform fejlesztés könnyűsége.
C-ben egy raklap ablakozós libraryra (Motif, GNUStep, XForms, GTK-k, stb. az X11-es rendszereken, windows és macOS natívja) fel kell készítened a programodat, ha azt akarod, hogy mindenütt menjen. C++-ban kicsit könnyebb dolgod van, mert fogod a Qt valamelyik verzióját, ami windowson és macOS-en natív ablakokat ad (azt hiszem), X11 alatt meg saját ablakozást használ, ami jól elüt a rendszeredtől, ha nem azt használod, viszont megold mindent helyetted, de cserébe nagyobb és lassabb is lesz a cuccod.
Namármost, Pascalban meg fogod a Lazarus IDE-t és egy kattintással eldöntöd, hogy amilyen ablakos programot írtál, az milyen ablakozóra forduljon; windowsos natívra, macOS-es Carbonra ill. Cocoa-ra, X11-es GTK1, 2, 3-ra, vagy Qt4-re, Qt5-re és még egy-két egzotikus izére. Azaz, tök mindegy, hogy a célrendszer melyik környezetet használja, ha a Lazarus ismeri (a libeket fel kell rakni hozzá), akkor egy kattintás és olyat csinálsz. (Sajnos a Motif-ot, ill. a Qt3-at pont nem ismeri. :( )
És ugyanez jellemzi általában a cross-platform forgatást. Átviszed a másik platformra a kódodat, betöltöd az IDE-t (vagy, ha nem ablakos, akkor parancssorból fpc x.pas vagy lazbuild x.lpi) és már fordul is. Ellentétben a Java-val, ami write once, debug everywhere, ez tényleg write once, compile everywhere. (Az esetek többségében, én pl. már futottam bele OpenBSD alatt HTTPS bugba.)
Tehát félreértés ne essék, nem arról beszélünk, hogy a Pascal crossplatformabb lenne a C-nél, vagy a C++-nál, mert távolról sem az, de a komfortos-crossplatform fejlesztésben odaver nekik. C++-nál, ha kifutottál a Qt-ből (olyan platformon kell dolgoznod, ahol nincs), akkor ugyanott tartasz, mint a C-vel, hogy vadászhatsz össze mindent és kezelhetsz le mindent. Pascalban, ami platform támogatva van az ökoszisztéma által, az rendszerint fullosan támogatva van. Persze előfordulnak itt is bugok, vagy le nem implementált részek; sajnos a Pascal mára már keményen underground nyelvnek számít és kevesen használják és fejlesztik.

És, ami még idevág és nagyon fontos: az a runtime. C-ben és C++-ban, ha nincs felrakva a libc, vagy a Qt, vagy fel van, de eltérés van benne ahhoz képest, amihez forgatták, akkor megszívtad. A Pascal viszont hordozza a saját runtime-ját, minek következtében egy parancssoros Pascal program az egy szál pucér kernel felett is el fog futni, mindenféle library-k nélkül. Ez ugyan azzal jár, hogy egy sima hello world is 20-30 kB lesz, ha több cucc kell, azok is hozzák magukkal a saját függőségeiket, tehát a binárisok méretében tuti nem fog versenyzni a C-vel...hacsak nem cseréled le a runtime-ot, ugyanis a Pascal ezt lehetővé teszi. Ha nem tetszik pl. az a memóriakezelés, amit adnak hozzá, akkor megírhatod a sajátodat.
És azt is hozzá kell tenni, hogy az a runtime, amit a Pascal beleforgat a binárisba, az még így is kisebb lesz, mint a libc.

Mire való leginkább?

Generikus nyelv, tehát elvileg bármit csinálhatsz vele, de ahol tényleg nagyot üt, az az, amit leírtam, a komfortos-crossplatform fejlesztés, meg a desktop alkalmazások fejlesztése. De én írtam már benne beágyazott eszközökön futó különféle hálózati szervereket, kiosk alkalmazást, parser-eket, exe-hackert, modtoolokat, meg mittudomén még mi mindent is. A nyelv baromira rugalmas, fejleszthetsz benne C++-szerűen OOP-pal, kivételkezeléssel, extra típusokkal és minden túróval megspékelve, de fejleszthetsz benne C stílusban is, pointerekkel, record-okkal (a struct pascalos megfelelője) és sok-sok manuális memóriafoglalással. :)

Mit lehet szeretni benne?

Ezek után mit nem? :) A kódot még nem mondtam, hogy az is olvashatóbb és átláthatóbb, mint a C-é, vagy a C++-é, viszont grafománabb is, többet kell gépelni.

Nem tudom, biztos van, amit kihagytam, de szerintem nyitásként ennyi marhaság is elég. :P

Disclaimer: Az ebben a posztban található brainglitch-caused tárgyi tévedésekért és hülyeségekért ez az átokverte időjárás a hibás. :P

Egy programozási nyelv választásnál mondjuk több dolgot érdemes figyelembe venni, főleg ha a hobbin túlmutat:

   - szükséges platformok támogatottsága
   - produktív programozás szempontjából
   - biztonságos programozás szempontjából: első kérdés, hogy a célfeladatnál mennyire hangsúlyos?
   - emberi tényezők - mennyire lehet rá fejlesztőt találni, mennyire "mainstream"?

A legutolsóról egy tapasztalat: rokonságom vidéki kisvállalkozása nyomta Foxpro-ban a könyvelőszoftvert.
Jött a Windows 7 környéke, ideje volt modernizálni a DOS-ra írtat, a Foxpro ismerete után Visual Foxproban elkezdték újraírni.
A "hobbikezdet" komolyodott, szükségessé vált további fejlesztővel való bővölés. Ekkor dőlt a mutatvány, mert nem találtak.

Pascal esetén is ez utóbbit szintén problémás lehet. Ipari alkalmazásban ha elkezdesz valamit Pascal-ban, szerencsére lesz hozzáértő de mégis nehezebben fogtok rá további fejlesztőt, későbbi kódkarbantartót találni. Főleg ha valami rutinosabb kellene.
Hobbiként az más téma, ott még a Forth-ba is érdemes belekóstolni (tényleg érdekes az RPN, a dup, swap, rot és társai).

Lásd még: https://redmonk.com/sogrady/files/2021/03/lang.rank_.0121.wm_.png

Egy programozási nyelv választásnál mondjuk több dolgot érdemes figyelembe venni, főleg ha a hobbin túlmutat:

Az előző cégnél, ahol dolgoztam, ott egy raklap termékünk működött a Pascal-ban írt szoftvereimmel. Ez nem csak hobbi.

- szükséges platformok támogatottsága

Pascal > Rust

Pascal (61 "Tier 1", 7 "Tier 2")
Rust (8 Tier 1, 76 Tier 2, 80 Tier 3)
Jól néz ki a Rustnál az a rengeteg felsorolt platform a Tier 2 és Tier 3-as szekciókban, de egyrészt maguk is bevallják, hogy azok nem feltétlen fognak működni; a Pascalnál meg amint látod túlsúlyban vannak a "Tier 1"-es platformok, másrészt meg a Rust listája csalóka, mert ők különveszik az egyes architektúrán és bitszélességen belül az "alfajokat" (pl. i386/i486/i586/i686 vagy armv#/thumbv#), de még az endianitást is, míg a Pascalnál ezek csak úgy vannak szétbontva, hogy architektúra/bitszélesség, (pl. az i386 az az összes 32-bites x86-ot jelöli, az AArch32 meg az összes 32-bites ARM-ot), sőt néha még az sem, mint pl. a MIPS-nél, vagy a RISC-V-nél.

- produktív programozás szempontjából

Pascal >> Rust

Láttad már a Lazarust?

- biztonságos programozás szempontjából: első kérdés, hogy a célfeladatnál mennyire hangsúlyos?

Pascal < Rust

A Pascal kb. annyira biztonságos, mint a C++, ha úgy használod, de lehet annyira is, mint a C, ha úgy használod. Nem úgy tervezték, mint a Rust-ot. "Magától" sosem lesz annyira biztonságos, mint a Rust, mert nem is volt cél.

- emberi tényezők - mennyire lehet rá fejlesztőt találni, mennyire "mainstream"?

Pascal ? Rust

Rust fejlesztőből tavaly olyan 600 ezer volt. Pascalban régen sok millióan programoztak, de a nagy részük már nem aktív, valószínűleg alig emlékeznek már a nyelvre. Viszont a Rustba beletanulni - így látatlanban is - nem könnyű, Pascalba meg az.

Lásd még: https://redmonk.com/sogrady/files/2021/03/lang.rank_.0121.wm_.png

Ez a grafikon egyrészt azért nem mérvadó, mert a mintavételezése úgy ahogy van parciális és ráadásul rossz a minta: a Pascal fejlesztők elsősorban a forum.lazarus.freepascal.org-on tömörülnek és nem a StackOverflow-on, meg a GitHub-on; másrészt meg azért, mert mint mondtam, a Pascal-nak van múltja, régen ez egy populáris nyelv volt, ergo rengeteg "rejtett" Pascal fejlesztő van, aki még tudna Pascal-ban programozni, csak már nem akar valami miatt.

A fejlesztés célterületét nézve a szükséges platform  elég gyakran nem ekvivalens a minden létező platform kifejezéssel.
Legalábbis amely cégnek dolgozok, ott definiálva van, mire készülnek a termékei.

meg a GitHub-on

Ismeretségi körödben hova rakják a fejlesztők a publikálásra szánt projektjeiket? Esetleg van praktikusabb hely? /* ha igen, Redmonk-nak is érdemes javasolni */
A segítségkérő oldalra elterjedt áltlalános a StackOverflow, de ahogy a Pascal a forum.lazarus.freepascal.org körül tobzódik, a Rust fejlesztői közösség szintén a https://users.rust-lang.org/ fórumra támaszkodnak. De más nyelveknél is akadhatnak ilyenek.

Végül amikor egy állapotot nézünk, akkor célszerű a trenddel is kalkulálni. A Pascal mint írtad is, a dicső múlt és a jelenre való kihatása. Ezzel szemben például a Rust 10 éve még gyakorlatilag senki nem hallott róla. Látszik, hogy a fejlődés szakaszában van architektúra támogatás meg minden tekintetében. Jelenleg az látszik, hogy nem várható a lassú elhalása, se a fejlesztők lemorzsolódása.
De hogy mit hoz a jövő, arra csak jósolni lehet, pontosan tudni nem.

A fejlesztés célterületét nézve a szükséges platform elég gyakran nem ekvivalens a minden létező platform kifejezéssel.
Legalábbis amely cégnek dolgozok, ott definiálva van, mire készülnek a termékei.

És mi is a szükséges platform? A windows/macOS/Linux triumvirátus, meg az ARM/x86? Ezeket a Pascal is támogatja. Vagy mire gondolsz?

Ismeretségi körödben hova rakják a fejlesztők a publikálásra szánt projektjeiket?

Gőzöm sincs, hogy ki hol tárolja.

Esetleg van praktikusabb hely?

Most, hogy az ms megvette, kb. bármi. Ha nem akar valaki úgy járni, mint a youtube-dl.

Végül amikor egy állapotot nézünk, akkor célszerű a trenddel is kalkulálni. A Pascal mint írtad is, a dicső múlt és a jelenre való kihatása. Ezzel szemben például a Rust 10 éve még gyakorlatilag senki nem hallott róla. Látszik, hogy a fejlődés szakaszában van architektúra támogatás meg minden tekintetében. Jelenleg az látszik, hogy nem várható a lassú elhalása, se a fejlesztők lemorzsolódása.

A Pascalnál nem a "dicső múlt" a lényeg, de abból valószínűleg több programozót találsz, még mindig. Csak Delphi-vel töbmillióan dolgoztak annak idején és most is számos komoly stuff épül rá.

Mármint, hogy melyiken lehet megírni nulláról? Akármelyiken. Vagy, hogy melyiken van alapból már megírt gRPC kliens komponens? Delphi alá már megcsinálták, azt be lehet húzni FreePascal alá és támogatja a windowst, az Androidot és a Linuxot, de dolgoznak a FreePascalos verzión is, ami mindenen elérhető lesz.
Miért? Hogy jön a platformok fordítási támogatásához az, hogy egy adott hálózati komponens létezik-e vagy sem?

És ki mondta, hogy modern dolgokra nem lehet használni, vagy csak nehézkesen? Azt a delphi-s gRPC-s csomagot - mivel a Linuxot is támogatja - valószínűleg kevés melóval bármelyik UNIX alatt életre lehet lehelni. A Pascal/Lazarus által adott csomagok viszont mindegyik supported platformon futnak. (Vagy futniuk kellene, de bugokba belefuthatsz itt is.)

Ezt a Pascalról is el lehet mondani. Biztos a Rust-nál is lehet találni olyan feladatot, amihez nincs kész csomag.

Lehet, hogy Rustnál kevesebb a Tier 1, de a csomagok lefordulnak mindenféle exetleges extra meló nélkül, és lefutnak a tesztek.

Nem tudnék olyan feladatot mondani, amire ne találtam volna jól használható, stabil crate-t, pedig nekem időnként elég extra igényeim vannak, pl. post-quantum cryptography a TLS-ben.

Mielőtt megkérdezed: igen, minden nagyobb compiler módosítás előtt (vagy talán a release részeként) lefordítják az összes crate-t az összes architektúrára, hogy elkerüljék a regressziót. Van ott pénz...

??? Pascalnál mi nem fordul le? Pont az az ökoszisztéma az, ahol megfogod és átviszed az egészet egy másik platformra és lefordítod gond nélkül. Ez a delphi-s komponens egy 3rd-party komponens. BTW, fordítás: a Pascal fordító még egy Pentium I-esen is lefordítja saját magát. A Rust le tudja már magát fordítani 4 GB-nál kevesebb RAM-mal?

Te nem, akkor senki sem?

Te tenyleg nagyon keresed mibe lehetne bele kotni.
A mobil telefon amit mar nem hasznalok , 4GB memorival rendelkezett.
Az utobbi 5 eveben , mindenkit lebeszeltem olyan PC/laptop beszerzeserol,
akkarmilyen olcso aminek nincs legalabb 8GB memoriaja vagy rogton nem vesz bele annyit.
A leggyengebb meg forditasra (is, distcc) hasznalt gepem 8GB memorias 2008 -bol.

Mobil telefonra vagy hason szoru elemekre,
cross compile toll az ember, mert az asztali gepe, jo esellyel koroket ver forditasi idoben ra,
magha a fordito el is indulna rajta..

rust 2GB alatt volt kepes fordulni par eve. Ha regi geped van csak es nincs lehetoseged cross forditasra sem,
akkor regi rust -al meg mindig probalkozhatsz.

4GB RAM ara 10kHUF korul mar van.
Egy ettermet kihagysz es megvan. "Meal for 2 People, Mid-range Restaurant, Three-course" : 10000 HUF.
20 sor kocsmai ara, ami egy redes egyetemista heti fogyasztasa lehet ;-)

Az inkabb erdekesebb kerdes, megyire tud/lehet global optimilazciot csinalni rust -tal,
ill. vs. C megoldasok mit tudnak manapsag.
Global optimalizacio: optimalizicaio nagyobb kod reszlet figyelembe vetevel, mint a tipikus/default forditasi egyseg.

Ugye az is megvan, hogy rendszerint egy idohataros problema olcsobban
megoldhato tobb rammal, mint tobb CPU -val.

Merges leszek, ha "nem letezo" gepek miatt, lassabba vagy butabba tesznek valamit! ;-)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Te tenyleg nagyon keresed mibe lehetne bele kotni.

Nem, csak nem érted, miről beszélek.
Kit érdekel a mobilod? Láttál már olcsó SBC-t, meg beágyazott környezetet? Azokban hol van 8 GB RAM?

rust 2GB alatt volt kepes fordulni par eve.

Nem, nem volt. Pont erről beszéltem, hogy 32-bites x86-oson kifutott még a címtérből is.

akkor regi rust -al meg mindig probalkozhatsz.

Azzal, ami nem tudott lefordulni 32-biten?

4GB RAM ara 10kHUF korul mar van.
Egy ettermet kihagysz es megvan. "Meal for 2 People, Mid-range Restaurant, Three-course" : 10000 HUF.
20 sor kocsmai ara, ami egy redes egyetemista heti fogyasztasa lehet ;-)

És hova dugod azt a 4 GB RAM-ot ha a gépeden ráforrasztott RAM chipek vannak?

Merges leszek, ha "nem letezo" gepek miatt, lassabba vagy butabba tesznek valamit! ;-)

Nem létezik a Raspberry Pi? Ezt jó tudni.

"És hova dugod azt a 4 GB RAM-ot ha a gépeden ráforrasztott RAM chipek vannak?"
Van egy zsak PCB -amiert nem kar es csak arra hasznalom, hogy SMD forasztast gyakoroljak.

"Nem létezik a Raspberry Pi? Ezt jó tudni."
Ha forditasrol van szo, szamomra nem letezik.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

És? Ha neked nem kell, akkor másnak se kelljen?

Na, látod, erről beszéltem. Eddig ugyan X szoftver fordult RPi-n is, de innentől kezdve már csak crosscompile lesz lehetséges, vagy az sem, ha az a CPU épp nem lesz támogatva. Ha neked nem kell, másnak se kelljen? No comment.

Csak kivancsisagbol, te tenyleg forgatsz a PI-n magan, vagy csak trollkodsz ?

Hasonszoro eszkozoket, fejleszes idelye alatt gyorsabb volt revenni network fs ill boot hasznaltara,
mint egy tenyleges iteraciot megcsinalni rajta.

PI-t target platfromnak tekintem, de nem olyan platfromnak amin forditot erdemes futatni.

A regi idokben, az ARM-ok nak meg regebbi C hez sem volt eleg memoriaja.

"Ha neked nem kell, másnak se kelljen?"
Engem nem erdekel masok mivel probaljak meg szugsegtelenul nehezeti az eletuket,
de ne azok hataroljak be egy eszkoz kepesseget akik szandekosan nehezetik sajat dolgukat..
 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

;-)

Ha mar felhoztad, van mar barmilyen nyilt fordito a dsp -hez ?

BTW, regi idokben 32MB -rammal siman tudtal C -t fordaitani x86 -ra,
de azt a C forditott szinte barki megverte kezi asm -el. Tobbnyire nem veletlenul
zabbalnak a mai forditok.
 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Én speciel nem akarom. Csak jeleztem, hogy egy olyan nyelv, aminek a self-hostingja ilyen költséges, abban nem biztos, hogy túl hordozható lesz bármi. Nem csak a fordítót akarhatod átpakolni valami más platformra, akár a saját szoftveredet is.
Ha a fordító sem fordul le X GB RAM-nál kevesebb esetén, akkor a pl. kernelnek mennyi fog kelleni? Az "mai" "nagy" gépen is elég nagy gond lesz, ha pl. olyan desktopod van, amiben van 16 GB RAM és a kernelhez meg 32 kéne.

2GB -nel a fuggeseg (llvm, c++) nal megadja magat, no swap.
 

[2227/2718] Building CXX object lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o
FAILED: lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o
/usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Passes -I/home/stack/rust/src/llvm-project/llvm/lib/Passes -Iinclude -I/home/stack/rust/src/llvm-project/llvm/include -ffunction-sections -fdata-sections -fPIC -m64 -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -O2 -DNDEBUG    -fno-exceptions -fno-rtti -std=c++14 -MD -MT lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -MF lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o.d -o lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -c /home/stack/rust/src/llvm-project/llvm/lib/Passes/PassBuilder.cpp
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.

[ 9053.285588] Out of memory: Killed process 31832 (cc1plus) total-vm:1806396kB, anon-rss:1755260kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:3568kB oom_score_adj:0

Egy szalas VM.

rust esetben volt egy eros optimalizalas borrow checker memoria hasznalatan,
de 2GB nem eleg c++ hoz sem x86_64.

Te ARM -rol beszelsz, ha jol remlik arra lehet kevesebbet eszik a forditas.

szerk:
+1 GB swap hozza adva
befejezodik a forditas.

Ezt 4GB nel kevesebbenk hivom.
 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

1. szivatom magam ;-)
2. nem szeretnem az nvme irasi limitjebol kifogyni (nem mintha nem unsafe cache-t hasznalnek ;-) a VM allatt), egyertelmuen olyan kiserlet volt ami erosen swappelhet.
3. cloud style -ban tolom a VM -et, megha a sajat desktopomon is indul, es semmit sem allitottam a particionalason, nem adtam extra swap disket sem hozza.
  Van egy image tree-m amik cloud-init -t hasznalnak. SSH kulcsot es alap configot egy generalt iso imagean (config-drive) kapnak.
  Az alap cloud init visilkedes, ha "fizikalis" disk nagyobb mint a particio akkor megnoveli a teljese mertre.

A 2. nekifutasnal swap file volt hasznalva, vegen kb. 50MB volt benne.

unsafe cachet azert hasznalok, mert gyakaran a base image copy-on-write modban van, igy ha tobb vm ugyan arrol az imagerol indul akkor
a host cachen osztoznak.
unsafe azt jeleni, hogy betap vesztes eseten nagy eselyel corrupt lesz az FS. Ezek a VM -ek nalam par orat elnek. a munkajuk megismetheto, ugyhogy nem nagy gond.
Miven dirty cache nem feltelen irodik ki, igy az SSD tovabb el.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

rust bootstrap jelenleg llvm -en alapszik.
llvm -et C++ ban irtak, es nem tervesik rust/C -ba tenni belathato idon belul.

rust forditas llvm forditassal kezdodik, legalabbis ugy ahogy a githubon termet.

Rust fordito, leforditasanak memoria igenyet kerdezted.

Igen, hallottam.
Es jopar linux futatasra nem keps microcontroller/cpu/dsp/whatever el is volt dolgom,
amibol 0 an hasznalatm coreutilst.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

És? Ez hol kapcsolódik ahhoz, hogy szerinted kukázni kéne azt, amit a LLVM nem támogat?

Azt meg, hogy már megint te nem használtál coreutils-t, azt had ne minősítsem, OK? Más akkor nem is használhatja, or what? Ha neked nem kell, ne kelljen senkinek, vagy mi? Én ezt komolyan nem értem...

– Minden férfinek joga van gyerekeket szülni, ha akar! – fejtette ki álláspontját Szten.

– De te nem szülhetsz gyereket! – mondta Redzs jó hangosan és nyomatékkal artikulálva, mint amikor egy magyar ember külföldinek magyaráz magyarul.

Szten kikérte magának.

– Ne nyomj el engem!

– Nem nyomlak el Szten, de neked nincs méhed! Hogy fogod kihordani a magzatot? Belerakod egy szatyorba?

https://helikon7.wordpress.com/2009/12/10/monty-python-%E2%80%93-brian-…

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Mi tokert tennel coreutils mondjuk egy PIC 16 -ra ?
Akkarmit csinalsz nem fer ra, es megis, mire lenne jo?
Erre akartam kujakdni.

Kozben josz azzal hogy en vagyok a gonosz aki megatolna benne.
Felolem, teljesen jogodban all.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

És még én trollkodok? Ki beszélt a PIC16-ról? Jó, hogy nem mindjárt a C64-re kéred számon, hogy oda minek...
Olyan CPU-król és mikrokontrollerekről volt szó, ahol lehet használni, van rá OS, de az LLVM nem támogatja azt a platformot. Pl. a ColdFire-ön - meg a rajta futó RTOS-eken - lehet használni coreutils-t.

Nem mondtam, hogy meggátolsz benne, arról beszéltem, hogy kb. az a nézőpontod, hogy neked nincs rá szükséged, tehát nincs rá szükség.

Csak kivancsisagbol, te tenyleg forgatsz a PI-n magan, vagy csak trollkodsz ?

Rustot? Nem. Pascalt? Igen. C-t? Igen.
Mi a baj? Ha nem tetszik valami, akkor mindjárt trollkodik a másik? No comment.

Engem nem erdekel masok mivel probaljak meg szugsegtelenul nehezeti az eletuket,
de ne azok hataroljak be egy eszkoz kepesseget akik szandekosan nehezetik sajat dolgukat..

Aha, de azért a Linuxot meg a coreutils-t írják át bele, vegyék el minden Rust-on kívülitől, mi?

Milyen olyan arch letezik amire van ertelme a coreutilst leforditani ,
de nincs llvm tamogatas ?

Netan: https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Motorola-6800-…
https://en.wikipedia.org/wiki/MicroBlaze
Support was added to LLVM in April 2010,[2] but subsequently removed in July 2013[3] due to a lack of maintainer.

 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ha már szóbahoztad a 68000-est, akkor szólok, hogy abból nem csak a legacy 680x0 széria van: a ColdFire és ColdFire+ CPU-kat/uC-ket a mai napig gyártják és használják beágyazott környezetekben és ennek megfelelően a mai napig támogatják különféle valós idejű operációs rendszerek, mint például a FreeRTOS, az eCosPro és az RTEMS, de egyébként a Linux is támogatja, csak amióta az uClinux behalt, azóta OOB disztró nincs hozzá, de a Linux maga támogatja. Ez bizony a mai napig egy élő architektúra. Tehát van értelme a coreutils-t lefordítani 68k architektúrákra. (És akkor még nem is beszéltünk arról, hogy a különféle UNIX-oknak (Linux, OpenBSD, NetBSD) a mai napig vannak 68k-s Apple, Amiga, Atari és NeXT portjai, csak azt úgyis lesöpörted volna az asztalról, hogy retro, meg nem biznisz, úgyhogy téged nem érdekel...)
Plz. ne te akard már eldönteni mások helyett, hogy számukra minek van értelme és minek nincs.

" Plz. ne te akard már eldönteni mások helyett, hogy számukra minek van értelme és minek nincs."
En nem akkarom, te akkarsz mindenkit megyozni, hogy meg ezeknek van ertelme.

Ahogy latom a csaladot, a legaljatol van mar olcsobb, hasonlo ,
tetejetol van joval gyorsabb, hasonlo aron mas archbol.

Fejlesztes koltsege nem olcso, amig veszik az erre epulo termekeket es nem kell fejlesztore kolteni,
akkar az idok vegezeteig gyarthatjak.

De ahol ar verseny is van, ott nem sok jovot latok neki.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

En nem akkarom, te akkarsz mindenkit megyozni, hogy meg ezeknek van ertelme.

Léteznek? Igen. Az ipar használja őket? Igen. Akkor van értelme. Pont.

Ahogy latom a csaladot, a legaljatol van mar olcsobb, hasonlo ,
tetejetol van joval gyorsabb, hasonlo aron mas archbol.

Fejlesztes koltsege nem olcso, amig veszik az erre epulo termekeket es nem kell fejlesztore kolteni,
akkar az idok vegezeteig gyarthatjak.

De ahol ar verseny is van, ott nem sok jovot latok neki.

Bízd az NXP-re, majd ők tudják, mikor kell leállni vele. Egyébként a ColdFire is csak egy példa a sokból.

"Például a futó kód megközelíti-e a C-ben írt teljesítményét? "
Elmeletben igen, gyakorlatban nem feltetlen.

https://en.wikipedia.org/wiki/Calling_convention tipikusan elter a tipikus C hez kepest.

"Vannak-e jól használható lib-ek hozzá?"
"Mennyire állja meg a helyét így 2021-ben más nyelvekkel összevetve?"
Kihalo felben levo nyelv, az volt 10 eve is .

"Mire való leginkább?"
Hazi feladatot be lehet adni nemely iskolban pascalban.

"Mit lehet szeretni benne?"
Csomo dolog van amit hasznalo szeretnek benne, de tenylegesen a vilag nem arra mozdult.
Sokon olvashatoban tartjak, ill. egyesek szerint alkalmasabb oktatasra mint a C.
A valosagban C utani nyelvek tobbsege a C -bol vette at a kifejezeseket.

Modulok kezeleset.
A rust jobban hasonlit ilyen teren a pascal felfogasra.

Pascal egy lepeses forditas, a C -nel ket lepes van.
eloforditas 'macrco kezelse' ill tenyleges objectre forditas.
Valahol ez jol jon, valakinek zavaro..
(A valosagban tobb lepes van, de azt nem kotik az orodra.)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Kihalo felben levo nyelv, az volt 10 eve is .

Ezt honnan szedted? Van egy aktív többtízezres felhasználótábora, tíz éve is annyi volt.

Hazi feladatot be lehet adni nemely iskolban pascalban.

Iskolában már rég nem oktatnak Pascal-t. Egyébként komoly cégek termékei épülnek Delphi-re, vagy épp FreePascal-ra; az előző cégemnél, ahol dolgoztam, szinte az összes cuccunk arra épült, kivéve a központi szervert, ami C++-ban volt, meg egy-két mikrokontrolleres izét, ami C-ben.

Cobol -ban is lehet, hogy programoznak meg mindig 10000 -rek.
Es meg kurva sokat is fizetnek erte , kurva nagy "komoly" penzugyi cegek.
Attol meg egy kihalofelben levo nyelv az is.

Fortran -ban is van meg olyan kod amit mind maig hasznalunk,
de lenyegeben minimalis ember muveli, es szinte semmit nem kezdenek benne manapsag.
https://github.com/xianyi/OpenBLAS

A fortan jelenlete, tipikusan *BLAS hasznaloi kozosegen van jelen, ahol
 kisebb uj progik is szuletnek.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Akkor lenne kihalófélben, ha fogynának a használói, de nem teszik, aki mellette döntött és még mindig használja, az nem is dobja már el. Nincsenek már túl sokan, de nem fogynak.
Ahol én dolgoztam az meg egy biztonságtechnikai cég volt, nem pénzügyi. De mindegy, ne értsd, ha nem akarod.

En ugy halottam senki sem hallhatatlan.
Ha nincs utanpotlas, akkor ..

Lazarus volt az utolso pascal dolog amit fordittam,
Emlekeim szerint egy alap linux rendszeren semmi sincs pascalbol,
meg fortran is relevansabb.

Rust felmenoben van,
lehet hogy ma meg nem maghatarazo, de lehet hogy holnap az lesz . (~2ev)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ez semennyire sem érv arra, hogy ne legyen egy viszonylag gyakori, potenciálisan távolról kihasználható biztonsági réseket generáló probléma ellen "ingyen" védelem. A programozó is ember véges mennyiségű figyelemmel, így garantáltan lesznek ilyen jellegű hibák egy C kódban, ha meghalad egy méretet és/vagy többen dolgoznak rajta. Rustban legalább ez nem lesz és csak n-1 típusú hibával kell foglalkozni. Ha ma alkotnák meg a C "2.0" nyelvet, biztos raknának bele hasonló automata védelmet látva az ebből eredő RCE hibák tömkelegét.

Ez semennyire sem érv arra, hogy ne legyen egy viszonylag gyakori, potenciálisan távolról kihasználható biztonsági réseket generáló probléma ellen "ingyen" védelem. A programozó is ember véges mennyiségű figyelemmel, így garantáltan lesznek ilyen jellegű hibák egy C kódban, ha meghalad egy méretet és/vagy többen dolgoznak rajta. Rustban legalább ez nem lesz és csak n-1 típusú hibával kell foglalkozni.

https://hup.hu/cikkek/20210321/megerkezett_a_rust_tamogatas_a_linux_next_kernelfaba#comment-2606538

Ha ma alkotnák meg a C "2.0" nyelvet, biztos raknának bele hasonló automata védelmet látva az ebből eredő RCE hibák tömkelegét.

https://hup.hu/cikkek/20210321/megerkezett_a_rust_tamogatas_a_linux_next_kernelfaba#comment-2606426

Nem valszoinu, hogy egy platform fuggetlen assemblyibe kell ilyesmi.

Ha C "2.0" -t csinalnanak akkor a tulmeretezett comminity-t kene figyelembe venni,
es 'import',  'use' szeru dolgokkal, kulso /belso modoluk, estleges nevterek kezeleset segiteni.
I'll valami sajat cpan szeru dologgal valo egyutt mukodest az elejen hozza gondolni.
Talan a tul sok binaris formatum sem jo a nepnek,
lehet kellett volna definialni par dolgokot a nyelven felul ..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Biztonságos C terén is futnak a háttérben fejlesztések:

     http://www.safe-c.org/
     https://www.microsoft.com/en-us/research/project/checked-c/

A Rust ezeknek valamelyest alávágott. A Microsoft azóta fő támogatója lett a függetlenné vált Rust alapítványnak: https://foundation.rust-lang.org/members/
Amit feljebb kisarkított példákat rögtönöztem, azoknak a hibáknak a nyelv+fordító általi kivédésében félő, hogy nem elég a C-t részben átfaragcsálni.

A Rust merőben el mert szakadni a C hagyományaitól. Fő dobása ownership+borrowing és az ezáltal létrejövő sok megnyíló lehetőség, GC nélküli automata memóriakezelés, stb.
De itt nem álltak meg, egyúttal csomó ezredforduló utáni modern dolgot beemeltek a nyelvbe.
Hátrány: koncepcióban így eléggé eltér a C-től, így nehéz átképződni rá C-ről. Sokan ezért is fújnak rá.

Amit feljebb kisarkított példákat rögtönöztem, azoknak a hibáknak a nyelv+fordító általi kivédésében félő, hogy nem elég a C-t részben átfaragcsálni.

A hibakezelést semmilyen nyelven nem lehet elsunnyogni. Ha egy call hibával is visszatérhet, akkor azt le kell kezelni. A try/catch is hibakezelés.

Hátrány: koncepcióban így eléggé eltér a C-től, így nehéz átképződni rá C-ről. Sokan ezért is fújnak rá.

Ezért kell sok nyelvet beszélni és akkor nem C-ről kell átképződni rá. :)))

Hátrány: koncepcióban így eléggé eltér a C-től, így nehéz átképződni rá C-ről. Sokan ezért is fújnak rá.

Nem baj, suszter maradjon a kaptafánál, C programozó a C nyelvnél.

Majd jön egy újabb, boldogabb generáció, akik már másképp fejlesztenek, mint mi.

Amúgy +1 a poliglot hozzászólásra, igazából aki fejleszt, az legalább 2-3-4 nyelven fejleszt, nagyrészt egyszerre. És ebben a környezetben a Rustnak is pontosan ugyanúgy megvan a helye.

Mai állapot:

linux-next$ find ./ -name '*.rs'
./drivers/char/rust_example.rs
./rust/module.rs
./rust/kernel/allocator.rs
./rust/kernel/prelude.rs
./rust/kernel/sysctl.rs
./rust/kernel/miscdev.rs
./rust/kernel/bindings.rs
./rust/kernel/module_param.rs
./rust/kernel/chrdev.rs
./rust/kernel/error.rs
./rust/kernel/static_assert.rs
./rust/kernel/sync/guard.rs
./rust/kernel/sync/mod.rs
./rust/kernel/sync/mutex.rs
./rust/kernel/sync/condvar.rs
./rust/kernel/sync/spinlock.rs
./rust/kernel/random.rs
./rust/kernel/c_types.rs
./rust/kernel/buffer.rs
./rust/kernel/user_ptr.rs
./rust/kernel/lib.rs
./rust/kernel/printk.rs
./rust/kernel/types.rs
./rust/kernel/file_operations.rs
./rust/compiler_builtins.rs

.config:

CONFIG_HAS_RUST=y
CONFIG_RUSTC_VERSION=15200      # Stable kevés, nightly-build kell hogy a 'default' fordító legyen.
CONFIG_RUST=y                   # General setup --> legalján Rust support
CONFIG_RUST_EXAMPLE=m           # Device Drivers --> Character Devices --> legalján Rust Example


                                # Kernel hacking --> Rust hacking (default okés)
# CONFIG_RUST_DEBUG_ASSERTIONS is not set
# CONFIG_RUST_OVERFLOW_CHECKS is not set
CONFIG_RUST_OPT_LEVEL_SIMILAR_AS_CHOSEN_FOR_C=y
# CONFIG_RUST_OPT_LEVEL_0 is not set
# CONFIG_RUST_OPT_LEVEL_1 is not set
# CONFIG_RUST_OPT_LEVEL_2 is not set
# CONFIG_RUST_OPT_LEVEL_3 is not set
# CONFIG_RUST_OPT_LEVEL_S is not set
# CONFIG_RUST_OPT_LEVEL_Z is not set

A lefordítása külön történet. Egyelőre még a stable Rust kevés, a nightly-build kell hozzá + sok egyéb cucc. Idővel vélhetőleg ez is egyszerűbb lesz.
Itt található a fordítási leírás: Documentation/rust/quick-start.rst (txt file)

Lesznek itt még magokat 100%-on pörgető, RAM-ból gigabájtokat zabáló kernelmodulok.

Huhh ez a rust de ronda... Tényleg csak ez hiányzott a linuxnak, jó kis bloat. Furor support mikor jön?

PHP-ban mikor írunk kernelt gyerekek?

És phyton-ban?

(Mert úgy hallottam javascript-re már vannak kezdemények.)

Egy biztos, én akkor fogom elővenni az írógépet újra, amikor megjelenik a patch a Scratch-ban írt kernelmodulokhoz.

Trollkodásnak jó, amit írsz, de másra nem nagyon. A Rust nem áll közelebb a JS-hez / Pythonhoz mint a C vagy C++.

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

A Rust "csak" a Windows és a Linux kernelfejlesztés következő generációs nyelve lesz, ~5 éven belül meglesz a safety critical subset, és fel fog gyorsulni a terjedése az ezt megkövetelő helyeken (ASIL-D és társai).

Nem hasonlította a JS-hez a Rust-ot. Egy tendenciára hívta fel a figyelmet. Ha azt hiszed, hogy csak trollkodásból írta, hogy JS-ben már akarnak írni kernelt, akkor csekkold le ezt a szálat a legutóbbi ReactOS topicban; két kolléga frankón komolyan gondolta ezt a JS-ben a kernel dolgot...

Értem én, hogy hajnal volt, de Linus & Co. támogatása nélkül a rust soha nem kerülhetett volna a linux kernel közelébe, de hát nyilván Linus  csak egy fogalmatlan retardált egy random hupperhez képest.

Adott esetben nem is árt talán egy kis kód refaktorálás (szemét ki, új bugok be), modernebb algoritmusok használata, stb. Ha pedig az első néhány driveren elvérzik a rust (bármilyen okból), akkor nem fogja leváltani a C-t.

de hát nyilván Linus csak egy fogalmatlan retardált egy random hupperhez képest.

http://a.te.ervelesi.hibad.hu/szalmabab
Ilyet senki nem mondott és nem is kell, hogy retardált legyen. Nem egyszer láttunk már rá példát, hogy nem korlátlan ura a kernelnek, ha erős nyomás nehezedik rá, akkor előbb utóbb bekerülhet olyan is, amit nem akar.

Hagyd már ezt a retardált hajbazer szintet az érvelési hibás linkekkel, mert lassan azt hiszem, hogy egy másodnickje vagy.

Implicit benne van a vinnyogásban amire reagáltam, hogy mindenki meghal és mekkora baromság a linux kernel közelébe engedni a rustot, mert az szar és ezzel az erővel JS-ben is lehetne kernelt írni. Ha viszont ennyire nyilvánvalóan szar a rust, akkor Linus nem ért hozzá. Lehet itt rugózni a hülyeség kenegetésén, de kb. ez a lényege annak amire válaszoltam.

Ha meg csak úgy lenyomták volna a torkán, akkor a mindenféle tréningek ellenére kiverte volna a hisztit és lennének róla hírek, hogy ő nem akarta, csak átverték rajta. Annyira elképzelhetetlen, hogy esetleg lát benne valamit?