Végleg elkurvult Linus?

HUP cikkturkáló
A ZDNet szemlézte Linus Torvalds kerekasztal beszélgetését a Open Source Summit Korea 2025 rendezvényen (amit a Microsoft pénzelt, és nem titok, ők fizetik Linus bérét is).

What Linus Torvalds really thinks about AI and software development might surprise you

Hát, bizony meglepett, mert elképesztő ostobaságokat mondott.
Some developers don't like Rust, but Linus approves of it becoming a mainstream part of the Linux kernel.
Csakhogy ez sosem szeretem-nem szeretem kérdése volt. A fő érvek a Rust ellen:
- túlkomplikált build environment
- újabb dependency-k, ráadásul cargo miatt Linux maintainerek által ellenőrizhetetlen forrásból
- interfész integrálási problémák
- ki fogja karbantartani, csak egyetlen csóka viszi, a többi maintaner már lelépett a francba
- ...stb.
A "szeretem-e a nyelvet" érv kb. a lista utolsó utáni helyén áll csak, sosem ez volt a fő aggály, nem tudom, miről beszél Linus.
Torvalds thinks AI's best use may be to help get young developers excited about programming.
Megint elképesztő baromság több okból is. A fő aggodalom pont az, hogy ha juniorok helyett mindenki LLM-et használ, akkor kikből lesz majd a következő generáció senior rétege?
Torvalds is pleased that AI has prompted Nvidia to become a significant contributor to the Linux kernel.
Nem biztos, hogy örülni kéne annak, hogy odafostak 1 millió ellenőrizetlen kódsort, amit pusztán a mennyisége miatt is képtelenség review-olni, és legalább 10%-ban már meglévő kernelfunkciókat duplikál tök feleslegesen (UVM).

Hol van már az a jó öreg Linus (akit még nem a Microsoft pénzelt) és kifakadt, hogy túl bloated a kernel? Pedig akkor még fele ennyi kódsorból sem állt a repo.
  • 4881 megtekintés

( bennyh | 2025. 12. 01., h – 11:38 )

Some developers don't like Rust, but Linus approves of it becoming a mainstream part of the Linux kernel.

Szerintem inkább tereli a népet egy biztonságosabb nyelv felé, minthogy elismerje, Tanenbaumnak talán igaza volt :D

Nem feladata, hanem "mellékhatása". Ne írtsuk ki a C-t, de azért támogassuk, hogy legyen bejárása ilyen "magasabb" (nem sértésből írom, volt aki már félreértette itt, mi így tanultuk!!!) szintű nyelveknek a Linux kernel fejlesztésébe. Lehet, hogy a Rust az informatika magyarpetije, de róla se tudjuk még, hogy mi lesz belőle :D

( Wabbitseason v | 2025. 12. 01., h – 12:08 )

Kár, hogy nem lehet a témaindítókra +1-et adni (vagy csak én nem látom?). Mindenesetre: +1.

( asm v | 2025. 12. 01., h – 12:10 )

Te vagy a modernkori HUP (amota csiga lassu) kikepzo-je.

( willy v | 2025. 12. 01., h – 12:15 )

Fel kellene fogni, hogy a világ fejlődik és körülnézni a piacon, ki mit találhat kihívásnak. Az öregedés nem mentség arra, hogy a befogadóképesség csökkenjen.

+1

Sokan itt hajlamosak nem elfogadni (vagy nem észrevenni), hogy a Linux már rég nem az a kedves kis hobbikernel, amihez olyan szép élményeik fűződnek a kilencvenes évekből, amikor pattanásos arccal egy flopiról bebootoltak.
A Linux első sorban még csak nem is a desktop-ról szól. Talán nem túlzás azt állítani, hogy lassan Linuxon működik a világ. Key infrastructure. Régóta az ipar pénzeli a fejlesztését. Ezért is tart itt, és nem ott, ahol a BSD.
IMHO nincs ezen semmi meglepő.
C programozóként is azt gondolom, hogy a Rust-ban nem ellenséget kell látni, hanem a C reinkarnációját. És erről nem Linus tehet. Hanem Ti. Mert bunkók vagytok. Meg lehet nézni, mit kókányoltatok az elmúlt évtizedekben. Ezzel lett tele a fasz.

ez a kulcs. miközben várjuk a linux desktop soha el nem jövő évét, már szépen beköszöntött az, hogy minden alkalmazás, amit használok (céges windows gépen persze) linuxon fut valamilyen módon. az, hogy a böngésző (vagy alkalmazásnak álcázott böngésző) kliens micsodán fut, az full irreleváns.   lassan át lehet nevezni a linuxot "az OS-nek". a munkahelyemen persze van még  mainframe, de az se sokáig. 

Én azt értettem meg hogy ha valaki nem feltétlenül és kritika nélkül rajong a Rust-ért hanem esetleg fenntartásai / kritikája van, ne-adj-isten megalapozottan akkor arra már nagyon könnyen rásütik a "Rust-hater" bélyeget. 

Van egy kor (és ez jellemzően a 20 év rutin körül következik be) amikor az ember már nem ül fel olyan könnyen a következő hype-vonatra. Nem kis részben azért mert már ült néhányon.

Ezek azok a dolgok amiket 20 évesen nem hisz el az ember, ezzel nincs is baj, én se hittem el anno. 

>na ezek a rust haterek...

Nem mondanám magam Rust haternek, de a felületes szemlélő számára esetleg az lehetek... Ezért megszólítva érzem magam.

Nem arról van szó, hogy boomerségből utáljuk. Hanem csak arról, hogy annyit mondunk, hogy óvatosabban az agarakkal! Egyrészt a C-hez képesti teljesítmény állítások nem teljesen állják meg a helyüket.

Hogy miért vagyok óvatos? Azért mert egy hasonló psyopnak az elszenvedője voltam uszkve 20 éve, amikor még én voltam a csillogó tekintetű kezdő. Ugyanígy elmondták, hogy a Java mindenre is jobb lesz mint a C. Aztán az sem lett igaz.

A Rusttal két problémám van: az egyik a katasztrofális hibakezelés. A hiba értékként elv az, amit a C-ben utáltunk, és azért találták fel a kivételeket. (Történelmileg talán nem ez volt a sorrend, kicsit egyszerűsítettem.) Ha belegondolsz ez egy visszalépés. Esetleg lehet úgy gondolni, hogy ha hozzátennénk egy satatikus ellenőrzést, ami nem engedné, hogy hibakódot ellenőrzés nélkül hagyjunk, akkor ugyanott lennénk. De attól még az strukturálisan egy rossz megközelítés szerintem, és az exceptiön a jó. Érteni vélem a hiba értékként oldal érveit, de pont a legutóbbi Cloudflare eset mutatja, hogy a gyakorlatban katasztrófa. Érted, alapesetben egy nullával osztás a processz leállását okozza. Érthetetlen, hogy ezt hogy lehet jónak gondolni.

A másik pedig a memóriakezelés: a biztonságosság csak egy dolog. Fontos, de nem minden. A teljesítményre vonatkozó állítások ott buknak meg, hogy ha nem tudod a memóriát folytonossá tenni, a cache-t optimálisan használni, akkor a programod nem fog jól teljesíteni. Ehhez pedig manuális memóriakezelés kell. Az objektumokat akár aspektusok szerint külön tömböke szétvágva kell tárolnod. A mai architektúrákon a memória hozzáférés módján múlik a teljesítmény nagy része, mert ez a szűk keresztmetszet. Tehát hiába bizonyítod egy mesterséges benchmarkon, hogy a nyelved ilyen meg olyan jól teljesít, ha a valóban high performance mintákat csak vérhugyozva, vagy a nyelv alapvető mechanizmusait áthágva tudod teljesíteni.

(Például Javában csináltam már ilyet: egy adatszerkezetet objektumok helyett egy bazi nagy int tömbbe tettem be és sokszoros gyorsulást értem el vele. Végülis Java, csak éppen nagyon nem olyan, mint amilyennek egy Java programnak illene lenni.)

Nincsen semmi baj a hiba értékként elvvel, csak akkor minden függvény adjon hibakódot vissza. Ilyen szempontból a shell sokkal konzisztensebb.

Aztán majd eldöntöm, hogy akarom-e kezelni vagy sem. Csak az a megoldás meg azért eredményezne átláthatatlan kódot.

Az exception valóban sokkal tisztább logikailag, egy veszélye van csak: mivel hogy az szépen megy felfelé, hajlamosak vagyunk nem lekezelni, hiszen "majd valaki elkapja" :)

Nincsen semmi baj a hiba értékként elvvel

Kivéve, hogy mindig jól át kell gondolni, hogy az általad kitalált hibakódok lehetnek-e valaha (akár a távoli jövőben) valid visszatérési értékek.

Szóval részemről is +1 az exceptionökre.

Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

Az exception jó dolog:

  • el tudod dönteni hogy milyen hibával hol foglalkozol
  • ha valamire "nem gondolsz" tök egyszerűen kiderül és tudod javítani
  • elkülönül a biznisz logika (happy path) és a hibakezelés 

Lassabb?

  • igen
  • az olyan "problémákat" amik elég sokszor előfordulnak érdemes "lekezelni" és akkor nem lassítanak (annyit) az exceptionök runtime

Egyetértek.

A visszatérési érték mint hibakód koncepcióval az a bajom, hogy nem terjed felfelé. Vagy helyben kezelni kell (ami nem mindig valid opció), vagy feljebb propagálni (foglalkozzon vele a faszom).
A hibakód így gyakran szimplán leszarva marad.
Az exception-re legalább esély van, hogy ha nagyon fáj, majd valahol odafent kezdek vele valamit.

Megnéztem a gos példát. Igen, valóban a normál visszatérési érték helyett egy error objektummal tér vissza. Ez olyan félút az exception felé szerintem.

A sikeres futás után a visszatérési érték mellé visszaadott nil (=ok) viszont szerintem fölösleges overhead. Igen, tudom, explicit és egyértelmű, de akkor is.

Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

A kivételnek nem mellékes előnye, hogy egy kódon kívül további információt is tud hordozni. Például milyen érték okozott problémát, vagy ha metóduson belüli hívás adott hibát, dobott kivételt, akkor azt is könnyen tovább lehet adni.

A teljesítménynek csekély jelentősége van: ha ritkán fordul elő adott hiba, akkor nem kell vele foglalkozni, ha gyakran, akkor az talán mégsem hiba, hanem körülmény, amire fel kell készíteni a programot.

Nekem is az, de gondoltam megmutatom, hogy szokták ezt akkor kezelni, ha az nincs :) Az, hogy mennyire felesleges, azt meg imho úgy érdemes nézni, hogy mondjuk az exceptionhoz képest milyen :)

Egyébként ugye az szokott még érv lenni, hogy a return value explicitebb, kevésbé felejted el, mert nincs ott egy "rejtett" code path. De ez imho max ízlés / egyén kérdése, meg leginkább gyakorlaté.

Ami még szívás tud lenni egyébként exception ügyben, főleg ilyen dinamikus típusos nyelvekben, az az itt még milyen exception jöhet. Pl a pytonnak az egyik leggyengébb pontja imho ez.

Úgy érted, hogy a függvény visszatérési értéke a hibakód? Akkor hogy ad vissza eredményt? Referencia szerinti paraméteren keresztül? Akkor viszont nem tudod így leírni, hogy x = sin(30). Vagy én értek nagyon félre valamit.

Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

Nos, a "régi, szép időkben" az alkalmazások nagy része még assembly-ben íródott. Ez csak egy kis felesleges közbevetés volt, annyit szerettem volna mondani, hogy az "igazi" programozó az ilyen "híreket" egyszerűen figyelmen kívül hagyja. Semmi jelentősége a számára. Egyszerűen teszi a dolgát, enyhe félmosollyal.

Ugyanígy elmondták, hogy a Java mindenre is jobb lesz mint a C.

Nananana. Ezt így senki nem mondta, pontosan ismert volt, hogy pár tipikus dologra nem lesz ideális, sőt volt rögtön egy (elbszt) vetélytárs is (c#). 

Ez most más, az idők szava szerint a fiatalok a Rust irányban látják a megoldást, nem lesz az sem egyedülálló, a Go-nak, a C-nek és a Java-nak, Python-nek lesz simán terepe, de a Rust teljesen más viszonyban van a C-vel és több területen fog vele konkurálni. Egyszerűen nem szabad kizárni, és Linus elég helyesen nem érzelemből dönt. 

A Rusttal két problémám van: az egyik a katasztrofális hibakezelés. A hiba értékként elv az, amit a C-ben utáltunk, és azért találták fel a kivételeket. (Történelmileg talán nem ez volt a sorrend, kicsit egyszerűsítettem.) Ha belegondolsz ez egy visszalépés.

Az Exception a visszalépés. Jónak gondolt, hatalmas hiba. Egy előnye van, hogy kényelmes. Éppen ezért is nagyon rossz, mert könnyű rosszul használni, ellenben nagyon megbonyolítja a kódot. Használatával nehéz pontosan megmondani, hogy mikor mit csinál, hol lesz elkapva, ha módosítok, akkor mit rontok el, mit kellene átnéznem, ... Nem véletlen, hogy az újabb, nagyobb biztonságot kínáló nyelvek mind a hiba értékként elvet vallják, pl. Rust, Go, Zig, Haskell.

Ha valakit mélyebben is érdekel, itt írtam is róla, bár nincs teljesen befejezve: Hibakezelés

+1

Az exception akkor jó, ha minden potenciálisan problémás utasítássort körberakunk exception-kezeléssel. Ideértve az exception-kezelő utasítássorokat. Na persze ez normálisan lehetetlen, hanem úgy járunk el, hogy egy messze-messze függvényben valaki majd csak elkapja az kivételt, csak persze fogalma sem lesz arról, hogy ténylegesen mi volt a baj és mit kellene csinálni.

Az exception akkor jó, ha minden potenciálisan problémás utasítássort körberakunk exception-kezeléssel

-1

Azzal kell körberakni, amit az adott szinten le tudsz kezelni. Igen, lehet olyan exception, amit csak a végén kapsz el, logolod, értesíted az üzemeltetést, akármi, és hagyod meghalni az alkalmazást.

Nem értek egyet. Abban igaza(d?) van, hogy az alsóbb rétegek többet tudhatnak a technikai részletekről, de a felsőbbek meg többet tudnak a való világról.

Van mondjuk egy SDK-d, amit használsz a kódban. A mögöttes API dob egy errort rate limiting miatt. Hol kezeled le az exceptiont? A library-ban? Honnan fogja tudni, hogy mikor próbálkozhat újra, szabad-e újrapróbálkoznia, stb., vagy az eggyel fentebbi rétegben, ahol ezek az információk megvannak?

Vagy ha mondjuk a backend mögött valamiért megáll a DB, ott kezeled le a hibát helyben? Egy fenét, elengeded az exceptiont, a megfelelő rétegben meg összeszeded, és az adott réteg mondjuk küld egy alertet Service Now-ba, vagy mittudomén.

De legyen egy még életközelibb példa, van egy számlázórendszered, amiben használsz egy PDF-generátor és printer SDK-t. Visszajön az exception, hogy nem tud nyomtatni. Mit csinálsz vele ott helyben? Valószínűleg semmit, hanem összeszeded ott, ami például le tudja kezelni a hibát azzal, hogy számlanyomtatás nélkül megvétózza a termék postára adását, vagy akármi.

Ez, hogy az exception "random helyen" felbukkan, hülyeség. Vagy ha igen, akkor nem használjátok jól. :)

Nem az a kérdés, hogy hol jó kezelni az adott kivételt, hanem inkább az, hogy az adott réteg valóban tudni fogja, hogy ott neki kezelnie kellene a hibát.

Ha értékként van visszaadva, akkor mindenképp kell kezdeni vele valamit minden szinten, amíg valaki ténylegesen le nem kezeli. Ha az adott szint nem akarja kezelni, akkor odabök egy kérdőjelet (Rust) vagy egy try-t elé (Zig), máris feljebb dobta a labdát. Az eggyel fentebbi szinten ugyanez, vagy ténylegesen kezelem, vagy feljebb passzolom.
Minden esetben ott a fv szignatúrájában a hiba jelzése és az adott ponton valamit kezdeni kell vele.

Exceptionnél, x szinttel a hiba keletkezése fölött már sok esetben nem is nagyon tudjuk, hogy ott jöhet hiba vagy sem. Arról meg pláne nem tudunk, hogy milyen hiba és miért keletkezett. Persze, ha ezeket tudnánk, akkor ott jól lekezelnénk.
Kíváncsi vagyok, hogy hányan csináltatok olyat, hogy ha beraktatok egy meglévő függvénybe egy új hívást, akkor kinyomoztátok, hogy az dobhat-e hibát, milyen hibát és miért. Majd megkerestétek az összes hívóban és azok hívóiban és ..., hogy minden hívó ágon jól le van-e kezelve. Ezt persze minden egyes új kódsor berakásakor.

Ezceptionnél, x szinttel a hiba keletkezése fölött már sok esetben nem is nagyon tudjuk, hogy ott jöhet hiba vagy sem.

Ez így 100% igaz, viszont ez a modell áll legközelebb a valósághoz. Fentebb írtam, mondjuk van egy backend rendszered, mögötte a DB. Egyszer csak auth hibával elszáll a kapcsolat a DB-vel.

Mit kezelsz le, meg hogyan? Teljesen valid az a "hibakezelés", hogy ez vis maior, hagyjuk, hogy az app elköszönjön a usertől egy "something happened" jellegű általános hibával, a konkrét technikai részleteket logoljuk valahova, a correlation ID-val meg nyitunk egy alertet, hogy az ops alkalomadtán nézzen rá.

Arról meg pláne nem tudunk, hogy milyen hiba és miért keletkezett. Persze, ha ezeket tudnánk, akkor ott jól lekezelnénk.

Pont az az életszerű ebben a logikában, hogy mindenki azokat az eseteket válogatja ki, amivel ténylegesen tud is mit kezdeni. Amit meg mindenki továbbadott, az megy a gyűjtőbe, majd az ügyeletes ops megnézi, mi baja. Igenis léteznek olyan problémák, amivel nem tudsz magadtól mit kezdeni a kódban.

Majd megkerestétek az összes hívóban és azok hívóiban és ..., hogy minden hívó ágon jól le van-e kezelve. Ezt persze minden egyes új kódsor berakásakor.

Miért csinálnánk ilyet? Az exceptionnek a nevében is benne van, hogy a kivételes helyzetek kezelésére lett kitalálva. Ha előre fel tudod sorolni egy új kódsor összes potenciális hatását és mellékhatását, akkor kész vagy. Csak hát, ilyen a gyakorlatban ritkán van.

Miért csinálnánk ilyet? Az exceptionnek a nevében is benne van, hogy a kivételes helyzetek kezelésére lett kitalálva.

A nevében valóban az van, de nem a kivételes helyzetekre van kitalálva, hanem mindenféle hibakezelésre. Nem olvasható a file, rossz az adott érték, nincs jogosultsága, ... 
A kivételes hibák, amik mehetnek legfelülre, ott széttárjuk a kezünket, azokkal nincs baj. Azokkal van, amikkel kellene valamit kezdeni, de nem feltétlen ott, ahol épp keletkezett.

Fentebb írtam, mondjuk van egy backend rendszered, mögötte a DB. Egyszer csak auth hibával elszáll a kapcsolat a DB-vel.

Ez is lehet kéz felemelős, nem tudunk vele mit kezdeni, de lehet olyan is, hogy van rá megoldásunk, amivel kezelhető, pl. kapcsolat újraépítése, újrapróbálkozás x időközönkét y-szor, ... Attól függ, mi a cél és hogyan van megvalósítva.

Azokkal van, amikkel kellene valamit kezdeni, de nem feltétlen ott, ahol épp keletkezett.

De hát ezt mondom én is. :)

Van mondjuk egy csv betöltő library, egyszer azt mondja egy csv-re, hogy FileNotFoundError. Hiába a library rétegben van meg a legtöbb infó, ő sokszor nem fogja tudni eldönteni, hogy most akkor mi legyen. Ezt csak valamelyik magasabb szinten eldönteni, ahol látod az összképet.

De ezen hogy segít, pl. a már emlegetett Either (Option, stb.)? 

Ha minden adhat vissza hibát, akkor ugyanúgy nem tudod, hogy mi, milyen hibát adhat vissza, nem? Ugyanúgy megindul felfelé a stack-en, aztán majd ha abba a rétegbe ért, ami számít egy CSV hibára, akkor ott lekezeled.

A szignatúrából látod, hogy milyen kivételre számíthatsz.

De akár ilyet is tudsz:

try {} catch (RuntimeException re) {}

Vagy akár:

try {} catch (Throwable t) {}

A kivételnek a legfőbb előnye az én olvasatomban az, hogy kvázi nulla munkával nagyon sok információt vissza tudsz csorgatni. Ha van egy metódusod, aminek van 5 hívása, mindegyiknek van legalább 3 féle visszatérési értéke, akkor szépen szaporíthatod a visszatérési értékeidet, hogy pontos információt tudjál visszaadni. Arról nem beszélve, hogy hibakeresésnél mindegy egyes ilyen lépésnél meg kell nézni egy kódlistát, ahogy akkor merre kell felmenni. Ellenben egy stack trace esetén rögtön látod a hiba forrását, egy jó üzenettel akár a megoldás is azonnal kiderül, például látod, hogy milyen érték volt a paraméter, mi okozott gondot, még debugolni sem kell.

Tegye fel a kezét, akinek nem volt még dolga naplófájlban vagy alkalmazás ablakban semmit mondó hibaüzenettel/kóddal, amivel a gyártó sem tudott mit kezdeni vagy akár valós hibától teljesen eltérő (félrevezető) hibaüzenettel (amivel a gyártó szintén nem tudott mit kezdeni).

A kivételnek a legfőbb előnye az én olvasatomban az, hogy kvázi nulla munkával nagyon sok információt vissza tudsz csorgatni.

Igen, ez az előnye, hogy nagyon egyszerű és kényelmes. Viszont az a legrosszabb kombináció, hogy rossz dolgot egyszerű és kényelmes készíteni. Ha valamit nehéz csinálni, akkor sokkal jobban meggondolod, hogy mikor és mit csinálsz.

Pl. ha egy metódus paramétere hibás, akkor dobok egy exception-t, majd fentebb, akinek kell, az szépen lekezeli, problem solved. Az, hogy nem igazán lehet ezzel feljebb mit kezdeni, az azon a szinten senkit sem érdekel.
Legfelül beeshet bármilyen hiba, senki se fogja megnézni, hogy oda pontosan honnan és milyen hibák jöhetnek, amit írtál is, elkapjuk az összes Exception-t, kiírunk egy általános üzenetet, hogy váratlan hiba történt, majd lelogoljuk a hibát és jó esetben majd lehet elemezgetni, hogy ezt miként javítsuk a jövőben.
Ha viszont értékként adjuk vissza, akkor hamar meg fogjuk tanulni, hogy alulra már ne mehessen hibás adat, azt a lehető legfelsőbb szinten kezelni kell, mert ott még ki tudjuk írni, hogy hibás adat jött be, különben minden szinten megnehezíti a munkánkat.

Ha van egy metódusod, aminek van 5 hívása, mindegyiknek van legalább 3 féle visszatérési értéke, akkor szépen szaporíthatod a visszatérési értékeidet, hogy pontos információt tudjál visszaadni.

Exception kezelésnél ez sokszor előfordul. Ha értékként adjuk vissza a hibát, akkor törekedni fogunk rá, hogy úgy szervezzük a programot, hogy ahol hiba jön vissza, ott azon a szinten kezeljük is, ne menjen tovább, mert az kezelhetetlen lesz. Exception-nél is kezelhetetlen (ilyen értelemben: senki sem tudja, hogy adott pontra milyen hibák, honnan és miért jöhetnek), de ez nem kényszerít minket arra, hogy átgondoljuk a dolgokat és adott szinten kezeljük, ezért másként szervezzük a programot.

... rossz dolgot egyszerű és kényelmes készíteni. ... Ha valamit nehéz csinálni, akkor sokkal jobban meggondolod, hogy mikor és mit csinálsz.

Nem világos, miért rossz technológia a kivételkezelés.

Ahogy az sem világos, hogy miért jó, ha valamit nehéz csinálni. Lehet, hogy rengeteg idő elmegy adott metódus hibakezelésére értelmetlenül, mert soha nem lesz hiba. Vagy pont azért, mert nehéz, nem készül el. Lásd "Tegye fel a kezét, akinek nem volt még dolga naplófájlban vagy alkalmazás ablakban semmit mondó hibaüzenettel/kóddal, amivel a gyártó sem tudott mit kezdeni vagy akár valós hibától teljesen eltérő (félrevezető) hibaüzenettel (amivel a gyártó szintén nem tudott mit kezdeni)."

Ahogy mindent RuntimeException-be csomagoltok, ugyanúgy simán elképzelhető, hogy visszatérési értéket sem néztek, hanem mentek előre.

A rossz gyakorlattól, kellő körültekintés hiánya ellen semmi nem fog védeni.

Ami adhat vissza hibát, annál látod a szignatúrából, hogy adhat vissza hibát és azt is, hogy milyen hibát ad vissza.

Most vagy nem értek valamit, vagy ehhez nagyon meg kell bíznod mindenféle ember mindenféle kódjában. Mi az, hogy előre látod, milyen hibát adhat vissza? És ha nem gondolt valamire a fejlesztő, akkor mi történik?

Ami adhat vissza hibát, annál látod a szignatúrából, hogy adhat vissza hibát és azt is, hogy milyen hibát ad vissza.

Zig esetén ilyen a szignatúra:

fn doAThing(text: []u8) error{ParseIntError}!void

A felkiáltójelből látod, hogy jöhet hiba, előtte levő ParseIntError -ból pedig azt, hogy milyen hiba jöhet.

Rust esetén ilyen a szignatúra:

fn doAThing(text: str) -> Result<(), ParseIntError>

A Result -ból látod, hogy jöhet hiba, a jobb oldali ParseIntError -ból pedig azt, hogy milyen hiba jöhet.

Exception esetén általában így néz ki:

void doAThing(String text)

Az első két esetben, ha meghívjuk a doAThing-et, akkor kezelni kell a visszaadott értéket, exception-nél az sem biztos, hogy tudunk róla, hogy doAThing exception-t dobhat, ki dobta és milyen exceptiont dobott.
Az első két esetben tudjuk, hogy adhat hibát, milyen hibát és a doAThing adta.

Oké ezt értem, de honnan tudod (pontosabban az eredeti kód szerzője honnan tudja), hogy a ParseIntError az egyetlen fajta hiba, amit a függvény dobhat?

Egy int parse-nál jó, viszonylag triviális, de mondjuk egy def upsertUserConfig(userId: int, config: UserConfig) -> None: ..., ami elmegy egy backendhez, DB-hez, akármihez, ott ez hogy néz ki?

Nem gondolom, hogy itt nagyon sok féle hibát kellene visszaadnia. Itt kb. csak annyit, hogy nem sikerült a UserConfig firssítése / létrehozása. 

Egyébként, ha valamiért érdekes lehet fentebb, akkor adhat vissza tetszőlegesen sok, egyedileg megadott hibát is, illetve akár azt is, hogy bármilyen hiba jöhet, de ez nem ajánlott.

Itt kb. csak annyit, hogy nem sikerült a UserConfig firssítése / létrehozása. 

És miért nem sikerült?

Nincs joga a usernek? Nem megy a DB? Az authN óta kitörlődött a user profil? Merge conflict van a megadott adatokban? Ezeket mind más-más szinten kell kezelni. 

Aztán máris ott tartunk, hogy vagy minden függvény tele van aggatva, mint egy karácsonyfa, vagy megadod, hogy bármilyen hiba jöhet, és akkor feltaláltad az exception kezelést :)

Szerintem tök egyszerű az egész.

Aminek van értelme helyben lekezelni (pl. egy DB elérési hibát vagy lockolt file elérését újrapróbálni), azt lekezelem ott, amivel úgysem tudok mit csinálni, mert olyan súlyos hiba, hogy nem mehet tovább a feldolgozás, azt engedem, hogy felbugybogjon a legfelső catch-ig, ahol is a teljes stack trace-t és akár forráskód sorszámot is látva, inner exception-öket kibontva leloggolom a hibát, ami után sokkal könnyebb utólag megfejteni, hogy mi a gond. (loggolás ráadásul annyi, hogy átadom a Log-nak az exception objektumot, ami minden mást elvégez)

A rossebb bohóckodna integer hibakódokkal a kód mélyén... 

Pontosan! Nem az a cél, hogy az Exception kezelést más technikával  csináljuk, hanem az, hogy a hibakezelést jól csináljuk.

Ha mindent ugyanúgy csinálsz, mint az Exception kezelésnél, akkor nem lesz semmivel sem jobb, csak pluszban még szívatod magad, a hiba feljebb passzolásokban.

Teljesen más hozzáállás kell! Pl.

Nincs joga a usernek?

Enterprise megvalósítás: egy-egy metódusra megadom, hogy milyen jogosultság kell, az lehet a 500.szinten is, majd a tetején elkapjuk a hibát és kiírjuk, hogy ehhez nincs joga. Közben csinált mindent is a program, meg jó esetben mindent vissza is, mire kiderült.

Más megoldás: A bejövő hívásnál ellenőrizzük, hogy ehhez van joga a usernek, ha nincs, akkor ott, az első szinten megy vissza az üzenet, az adott use-case el sem indul.

A többi is hasonló. Ha mindent ugyanúgy csinálsz, akkor nem igazán lesz jobb az érték szerinti hibaátadás.

Itt pont olyan példákat hozol, amik előre látható állapotok, mégcsak nem is hibák, mint pl. a jogosultságkezelésen fennakadás.

Én arra szeretnék elegáns, error code-os példát látni, hogy amikor a 20. rétegben lévő DB kezelő nem éri el az adatbázist, ezért el kell dobni az egész műveletet, felmenni 20 szintet, majd a hibát, a teljes kontextussal(!) - amiről a DB rétegnek fingja sem lehet - le kéne loggolni a későbbi hibakereséshez. Ez szerintem nem fog menni anélkül, hogy 20 rétegen keresztül passzolgatod egyre feljebb a hibakódot és bohóckodhatsz vele legfelelül és még akkor sem lesz a kezedben kutyagumi sem arról, hogy pontosan mi is történt legalul.

Hát ugye régen még az "exception előtti időkben" úgy volt, hogy:

  • modularizáltuk a kódot
  • a modulok maguknak logoltak
  • a modulokból kifele (felfele) is mehetett error-code, de nem nagyon sokféle
  • felküldött hiba esetén a hívó eldöntötte mit csinál, akár hibát dobhatott ő is tovább, és logolta hogy "alsó modul miatt megdöglöttem"
  • és akkor üzemeltetésnek kellett a logokból összevadászni hogy wtf

Itt pont olyan példákat hozol, amik előre látható állapotok, mégcsak nem is hibák, mint pl. a jogosultságkezelésen fennakadás.

Ha valami exceptiont dob, az hiba vagy nem hiba? Amik miatt exception dobódhat, az kb. mind előre látható állapotok.

Én arra szeretnék elegáns, error code-os példát látni, hogy amikor a 20. rétegben lévő DB kezelő nem éri el az adatbázist,

Mint, ahogy írtam is, ha ugyanúgy próbáljuk használni, mint az exception kezelést, akkor ugyanolyan rossz lesz a végeredmény, csak még több munkával jár.

Nézz pl. utána Functional Core Imperative Shell architektúrának. Ott az adatbázis hívás, ahogy az összes külvilággal történő kommunikáció, az mind a felső rétegben történik. Nem a 20. rétegben hívjuk az adatbázist, hanem az 1.-ben!

Ahol checked exception dobódik azon kötelezően ott van, ahol runtime exception, ott jó esetben a dobóra még rárakják, de már ott sem kell, de az ami hívja, arra már nem igazán szokták, amelyik azt hívja, arra még kisebb az esély, ...

A metódusok nagy részén, ahol dobódhat valamilyen exception, a fentiek miatt nincs rárakva semmi, pláne nem az, hogy pontosan mik dobódhatnak.

Ezt kézzel kell intézni, így még az is lehet, hogy valamelyikre rárakják, de belőle kikerül az a hívás, ami dobhat, így rajta lesz, hogy dobhat exception-t, pedig mégsem dobhat. ;-)

Hasonló, mint a kommentek. Van, hogy hasznos és segít, de van, hogy már nem az van ott, ami régen, így inkább káros.

Ezt kézzel kell intézni, így még az is lehet, hogy valamelyikre rárakják, de belőle kikerül az a hívás, ami dobhat, így rajta lesz, hogy dobhat exception-t, pedig mégsem dobhat. ;-)

Hasonló, mint a kommentek. Van, hogy hasznos és segít, de van, hogy már nem az van ott, ami régen, így inkább káros.

Ez speciel a zig-ben is pont így van, ott is deklarálhatsz olyan error-t amit sose fogsz dobni, illetve ott is pont úgy fog "kikerülni belőle" mint az exception deklarálásnál.

 

Ez speciel a zig-ben is pont így van, ott is deklarálhatsz olyan error-t amit sose fogsz dobni, illetve ott is pont úgy fog "kikerülni belőle" mint az exception deklarálásnál.

Valóban, de ez szerintem hibásan van implementálva. Minden információja megvan, ahhoz, hogy szóljon azért, ha hibát jelzünk, de nem dobhat hibát.

Azért is gondolom, mivel azért is szól, ha dobhat hibát, de nem jelezzük, tehát tudja, hogy mikor dobhat és mikor nem. Illetve még olyanokat sem enged, hogy mutable változót használunk, ami nem mutálódik, illetve konstanst használunk, ami nincs sehol sem használva. Ezek nem warningok, hanem fordítasi hibák.

Itt azért csúsztattál egy kicsit, a zig-es példának a

void doAThing(String test) throws ParseIntError;

felelne meg.  Vagy zig példát kellet volna így írni:

fn doAThing(text: []u8) !void

 

Egyébként szerintem az zig is "elrontotta" a hibakezelést :)  Ez a "kényszerítés" a rendes hibakezelésre nem fog működni.  Tele lesz a kód try-al, vagy error elnyeléssel.

Szerintem a zig esetén célszerűbb lett volna azt mondani, hogy alapból minden hivás try-al értendő (amennyiben a hívott fv tud hibát visszaadni).  Ahol tudunk értelmesen foglalkozni a hibával, ott majd lesz if, catch, stb.  A try erőltetése csak nehezebben olvashatóvá teszi a kódot szerintem.

 

disclaimer: 5 percet foglalkoztam a zig-gel a comment megírása előtt :)

Ez egy elég komoly félreértelmezése az exceptionkezelésnek.

A jól használt exception kezelésénél meglepően kevés helyen van exception kezelés, lényegében csak ott, ahol ténylegesen tudsz valamit értelmesen másképp csinálni az exception hatására. A legtöbb váratlan exception (mivel ugye a nevéből adódóan kivételes eset), leginkább úgy kezelhető, hogy a usernek hibaüzenet megy, az üzemeltetésnek meg valamilyen logbejegyzés a részletekkel. És az adott kérés tipikusan úgy ahogy van, hibával végződik. Ezek tipikusan olyan esetek, hogy mondjuk nem lehet a db-hez hálózaton csatlakozni, vagy elfogyott a lokál diszken a tárhely. Ezeknél a program egyszerűen nem tud mit csinálni a hiba megszüntetése érdekében.

Nagyon ritkán kell olyat programozni, hogy a normál üzleti logika része az, hogyha valamilyen specifikus exception jött, akkor konkrétan tud más ágat értelmesen végrehajtani a program. Mondjuk egy lehetséges példa: ha egy unique index értékre megpróbálunk beszúrni valamit, de visszajön egy exception, hogy unique constraint violation. Ez egy db exception, de csak akkor, ha a hibakód konkrétan a unique constraint violation-re vonatkozik, akkor máshogy csinál valamit a program, mondjuk update-et próbál helyette.

 

Az exception-ök bevezetésének egyik legfontosabb oka, hogy a programozók pont, hogy ignore-álták a függvény visszatérési értékben visszaadott hibakódot. Csak a happy path-ra koncentráltak, és nem foglalkoztak azzal, hogy a függvényhívás esetleg nem is sikerült, és ezzel tipikusan a következő sorban okoztak sokkal nehezebben debuggolható hibát. Legegyszerűbb példa, hogy a malloc mondjuk NULL-t ad vissza. Ha megpróbálod használni a pointert, akkor a következő sorokra kapsz valami rejtélyesebb hibaüzenetet. Ha lett volna exception kezelés, akkor meg egyből látszik, hogy mondjuk OutOfMemoryException volt. Ez is arra példa, hogy igazából sem a hibakód, sem az exception esetében nem tudsz értelmesen mit kezdeni a program kódjában a problémával, csak loggolni tudod meg a usert értesíteni. Nincs helyette olyan, hogy jó, akkor próbáljuk meg a másik algoritmussal megoldani a kérést, ami kevesebb memóriát használt, akkor gondolom eleve azt használtad volna :D

Ez egy elég komoly félreértelmezése az exceptionkezelésnek.

Huszon éve foglalkozom Excpetion-kkel, úgyhogy láttam már ezt meg azt. Neked is írom, hogy az Exception kezelést nem csak a kivételes esetekre találták ki, hanem mindenféle hibakezelésre. Nézd csak meg a Java saját exception-jeit: Exception, RuntimeException, Error

Ezekből pont az Error, amit úgy terveztek, hogy ne is kapja el az alkalmazás (kivétles eset), a többi a hibakezelés kategóriába esik. ;-)

De, én továbbra is azt mondom, hogy az Exception kezelést kivételes esetekre találták ki. Az nem megfelelő használat, hogyha a rendszer jó állapotban van, minden elérhető, van kapacitás, nincs túlterhelve stb., akkor Exception-ök dobódnak nagy számban. Ha egy normál és várható use-case az, hogy mondjuk hibás input van, mert a user beírhat tetszőleges szöveget egy szám mezőbe, akkor azt nem úgy kell kezelni, hogy megpróbáljuk parse-olni, és majd jól elkapjuk az Exception-t. A jobb nyelvek pont az ilyenekre biztosítanak Exception mentes parse-oló metódust, mint mondjuk a C# int.TryParse, szándékosan olyan szignatúrával, hogy elég nehéz legyen rosszul használni. Az már egy más kérdés, hogy a Java-ban ilyen pont nincs.

Az igaz, hogy ez nem egy matematikailag jól definiált fogalom, hogy mi a "kivételes", ez szubjektív. Ezért is van róla ennyiféle vélemény :)

Tudnád részletezni, hogy te milyen jellegű Exception-öket szoktál elkapni közelebb a dobás helyéhez, és akkor mit tudsz kezdeni velük?

De, én továbbra is azt mondom, hogy az Exception kezelést kivételes esetekre találták ki.

Ebben az esetben még egyet is értenénk. Azonban, mivel semmilyen támogatást nem nyújtanak a nyelvek a nem kivételes hibák kezelésére, ezért inkább arra hajlok, hogy mégsem csak a kivételes hibák kezelésére találták ki. Nem is arra használják az emberek, a tutorialok a sima hibák kezelésére is azokat ajánlják, pl. IllegalArgumentException, hogy ne hozzunk létra hibás objektumot.

Tudnád részletezni, hogy te milyen jellegű Exception-öket szoktál elkapni közelebb a dobás helyéhez, és akkor mit tudsz kezdeni velük?

Leginkább IOExcception-ök, pl. SQL hibák, file hibák, gyakori még az IllegalArgumentException. Nálunk még az a (rossz?) gyakorlat is megvan, hogy a checked Exception-öket (pl. IOException alapúak), de leginkább mindet, becsomagoljuk RuntimeException-be, hogy ne kelljen minden szinten továbbadogatni, így el is szokott hamar veszni, hogy hibát dobhat vissza egy metódus.

Ugye nem véletlen a rossz gyakorlat a checked Exception-ökkel, lásd pl.: https://www.artima.com/articles/the-trouble-with-checked-exceptions

A szoftverekben kb végtelen számú hiba előfordulhat, mindenre nem lehet nyelvi konstrukciót biztosítani. A visszatérési érték egy lehetőség, a kivétel dobása egy másik. Biztos van vagy lesz harmadik is, de végtelen számú sosem lesz. Így azt a végtelen számú hibalehetőséget le kell fordítani az erősen véges számú eszköztárra, mikor mit használsz.

Ahogy kolléga írta: "ez nem egy matematikailag jól definiált fogalom, hogy mi a "kivételes", ez szubjektív."

Van, amikor visszatérési érték a jó megoldás, van, amikor kivétel, van, amikor akár bármelyik.

"IllegalArgumentException" - el kellene olvasni az API dokumentációt és annak megfelelő paramétert átadni, és akkor nem repülnek ilyenek. A dokumentációban a fejlesztő leírja (khmm), hogy milyen bemenetet vár. Azaz neked lenne kutya kötelességed annak megfelelő értéket adni vagy környezetet biztosítani. Ha valami miatt nem olyan értéked van, akkor azt le tudod kezelni az adott szint logikájának megfelelően eggyel magasabb szinten. Kb ugyanaz, mintha kapnál egy visszatérési értéket, csak nem visszatérési értéket vizsgálsz, hanem már eleve a paramétert. És a szinteden lehet, hogy több lehetőség van értelmesen kezelni a "kivételes" ágat.

Ami a cikket és a "becsomagoljuk RuntimeException-be"-t illeti: lehet gyűjtő kivételeket is definiálni, ami adott réteg kivétele, és abban dobod tovább a rétegben keletkező kivételeket. És akkor nincs "with another subsystem you've got 80 exceptions in your throws clause.". (sok ezer hibakód jobb/kezelhetőbb lenne?)

Azonban, mivel semmilyen támogatást nem nyújtanak a nyelvek a nem kivételes hibák kezelésére

Pont előbb hoztam példát a C# int.TryParse -ra, persze ez csak egy nagyon kis alap építőkocka a kivételmentes hibakezelésre. Tény, hogy több ilyen kéne, több nyelvbe.

Leginkább IOExcception-ök, pl. SQL hibák, file hibák, gyakori még az IllegalArgumentException

A kérdés azon részének megválaszolását kihagytad, hogy hogyan kezeled ezeket közel a dobás helyéhez :)  A kezelés alatt azt értem, hogy nemcsak elkapjuk, loggoljuk, és a usernek valami hibaüzenetet adunk, hogy az általa kért művelet nem sikerült. Hanem valami értelmesen más ágra terelődik a vezérlés mondjuk egy SQL hiba vagy file hiba után, amitől megoldódik a user problémája. Szóval erre még kíváncsi lennék.

Pont előbb hoztam példát a C# int.TryParse -ra

Az nem nyelvi támogatása a hibakezelésnek. A nyelvi támogatás az, ahol nyelvi elemként megjelenik a hiba a visszatérési értéknél, a fordító szól, ha nem kezeljük a hibát, vagy rossz típust kezelünk, ...

Az, hogy egy függvény booleant, Optiont vagy Eithert ad vissza a hiba jelzésére, azok egyedi megoldások, nem nyelvi támogatás.

A kérdés azon részének megválaszolását kihagytad, hogy hogyan kezeled ezeket közel a dobás helyéhez :)

Erre nem lehet általánosan válaszolni. Pl. ha valamit elkérünk, de nem található, akkor használhatunk helyette egy default-ot, kérhetjük máshonnan. Vagy pl. ha valami nem található meg egy adatszerkezetben, akkor egyik ág fut, ha megtalálható, akkor másik. 

A nyelvi támogatás az, ahol nyelvi elemként megjelenik a hiba a visszatérési értéknél, a fordító szól, ha nem kezeljük a hibát, vagy rossz típust kezelünk

Érdekes, hogy ez pont hogy megvan Java-ban, a checked Exception. Amiről hosszú évek során kiderült, hogy nem annyira vált be, mint elsőre gondolták. Sőt, a legmeglepőbb helyről, tőled jön ez az idézet: "de leginkább mindet, becsomagoljuk RuntimeException-be". Nem érzed ellentmondásnak, hogy a nyelvi támogatásért kampányolsz, miközben ahol meg van rá nyelvi támogatás, ott a gyakorlatban egyből azzal workaround-olod, hogy továbbdobódjon az egész? :D

Pl. ha valamit elkérünk, de nem található, akkor használhatunk helyette egy default-ot, kérhetjük máshonnan. Vagy pl. ha valami nem található meg egy adatszerkezetben, akkor egyik ág fut, ha megtalálható, akkor másik. 

Ezek pont olyan use-case-ek, hogy nem kell exception-nel kezelni. Pl. az általad említett SQL nem dob exception-t, ha 0 darab sor jön vissza. Ha valami nincs egy adatszerkezetben, ismét hoznám a C#-ot példaként, a Dictionary.TryGetValue egy darab lookup-pal megmondja neked, hogy nincs benne a keresett elem az adatszerkezetben, vagy ha benne van, akkor vissza is adja az értékét, exception nélkül.

Nem érzed ellentmondásnak, hogy a nyelvi támogatásért kampányolsz, miközben ahol meg van rá nyelvi támogatás, ott a gyakorlatban egyből azzal workaround-olod, hogy továbbdobódjon az egész? :D

Elég jól összekevered a dolgokat. ;-) Az nem az érték szerinti hibaátadás nyelvi támogatása, hanem továbbra is, az exception kezelésé.

a Dictionary.TryGetValue egy darab lookup-pal megmondja neked, hogy nincs benne a keresett elem az adatszerkezetben, vagy ha benne van, akkor vissza is adja az értékét, exception nélkül.

Pontosan, méghozzá értékként adja vissza a hibát (boolean false formában), hogy nem talált ilyet.

Nem keverek semmit. Ezt írtad:

A nyelvi támogatás az, ahol nyelvi elemként megjelenik a hiba a visszatérési értéknél, a fordító szól, ha nem kezeljük a hibát, vagy rossz típust kezelünk

Ennek a hibakezelés definíciódnak teljes mértékben megfelel a Java checked exception, egy nyelvi elem, ami kötelező hibakezelésre való. (És mellesleg ez a hibakezelés exception kezeléssel van implementálva, de az most ebből a szempontból egy részletkérdés, ha úgy tetszik, a checked exception instance az az érték, amiben megjelenik a hiba). És te mégis azzal workaround-olod ezt a fajta, nyelv által biztosított hibakezelést, hogy továbbdobod RuntimeException-ként, tehát ez nekem továbbra is vizet prédikálsz és bort iszol szituációnak tűnik.

A nyelvi támogatás az, ahol nyelvi elemként megjelenik a hiba a visszatérési értéknél, a fordító szól, ha nem kezeljük a hibát, vagy rossz típust kezelünk

Akár hogyan is akarod csavarni, de a checked exception, az nem visszatérési érték.

Itt kiszállok, mert nem látom értelmét a továbbiaknak. ;-)

a checked exception, az nem visszatérési érték

Ebben egyetértünk, hogy szintaktikailag nem olyan mint egy visszatérési érték. Viszont logikáját, folyamatát és lekezelését tekintve gyakorlatilag ugyanolyan, mint egy lehetséges visszatérési érték: valami, ami a függvény szignatúrájában deklaráltan kijöhet a függvényből, és ráadásul ez pont olyan kijövő dolog, amivel a fordító által kikényszerítetten kezdened is kell valamit. Vagy egy normál visszatérési értéket kapsz, vagy valamelyik checked exception-t. És ezek közül pontosan az egyikre tudsz reagálni valamit. Tehát a dolog lényegét nézve, ez továbbra is pont az, amit kívánsz: a meghívott függvényből való visszatérésnél "a fordító szól, ha nem kezeljük a hibát".

A kivételek kezelését egy runtime (vagy fordított izé) automatizmus végzi, nem te és nem a te programod, ezzel külön nem kell foglalkoznod, az egész platformon alap.

A kivételek származtathatók egymásból és vizsgálható a típusuk.

A kivételek tetszőleges további információkat tárolhatnak a hibáról vagy annak körülményeiről.

A kivételek tovább dobhatók és egymásba ágyazhatók.

Olyan platformon, ahol ez nincs és megfelelően komplex rendszert csinálnak, ott előbb-utóbb feltalálnak valami részben- vagy nagyon hasonló megoldást arra, hogy megfelelően tudjanak hibakezelni.

Hívhatjuk mindezt visszatérési értéknek is, csak szerintem egyáltalán nem stimmel.

kivételek kezelését egy runtime (vagy fordított izé) automatizmus végzi

Miért, annak a hozzárendelését, hogy x = f() esetén az x változóba bekerül az érték, azt nem a runtime végzi? Mit jelent ebből a szempontból, hogy a "runtime" vagy a "te programod"? A kivételt is a "te programod" dobja, és a "runtime" kezeli, hogy mi történik vele. Pont ugyanúgy jól definiált a kivételek működése egy adott runtime esetén, mint egy változó hozzárendelés működése.

A kivételek származtathatók egymásból és vizsgálható a típusuk.

Ha kellően komplex a visszatérési érték, akkor arra ez ugyanez igaz.

A kivételek tetszőleges további információkat tárolhatnak a hibáról vagy annak körülményeiről.

Ha a visszatérési értéked egy Either<NormalReturnType, ProblemDescriptor> jellegű, ilyesmit írt már valaki feljebb, akkor ugyanaz elmondható róla, ahol a ProblemDescriptor egy hipotetikus hibaleíró osztály.

A kivételek tovább dobhatók és egymásba ágyazhatók.

Ha ez előző ProblemDescriptor hipotetikus osztályod olyan, akkor abban is lehet láncot vagy fát építeni a megelőző kiváltó problémákból.

Olyan platformon, ahol ez nincs és megfelelően komplex rendszert csinálnak, ott előbb-utóbb feltalálnak valami részben- vagy nagyon hasonló megoldást arra, hogy megfelelően tudjanak hibakezelni.

Ez így van, erre akartam utalni az előző megállapításaimmal.

Hívhatjuk mindezt visszatérési értéknek is, csak szerintem egyáltalán nem stimmel.

Szerintem amúgy nagyjából ugyanazt mondjuk, csak azt járjuk körbe-körbe, hogy most a checked exception-t hívhatjuk-e visszatérési értéknek vagy nem. Szó szerint nem, de nyilván ez abból adódik, mert kellett rá külön szintaktika, hiszen pont az a lényeg, hogy ne legyen ignore-álható, kikényszerítsen valami a compiler. Míg a szó szerinti visszatérési értéknél nincs kényszerítés, hogy csinálj is vele valamit.

Egyébként a Go nyelvben pont olyan utat választottak, hogy a hiba a visszatérési értékben jön vissza, de lényegében pont úgy van megoldva az error interfésszel, hogy amiket te írál (származtathatók, vizsgálhatók, tetszőleges információt tárolhatnak...), hogy végül nagyon hasonlóvá váltak a checked exception-höz. Akkor most egy alapjaiban eltérő, vagy inkább egy meglehetősen hasonló dologról van szó, amikor checked exceptiont és a visszatérési értéket hasonlítjuk össze?
 

Egy kivétel bármely programsoron "keletkezhet" szándékodtól függetlenül, a rendszer viszi addig amíg valami le nem kezeli, van lehetőség olyan blokk megadására, ami mindig lefut - semmi köze a szignatúrában megadott metódus visszatérési értékhez, benne van a teljes hívási lánc, stb.

Ha ezek alapján nem más neked mint a visszatérési érték, akkor nem tudok segíteni tovább. :)

Amit te mondasz az az általános exception, Java-ban pl. Error vagy RuntimeException. Vagy Go-ban a panic.

Én nem véletlenül a checked exception-t hasonlítottam a visszatérési értékhez. Arra igaz, amivel ez az egész szál indult, hogy legyen valami konstrukció arra, hogy a függvény szignatúrájában jelzed a hibalehetőségeket, és a compiler rákényszerít, hogy kezeld is.

Én amúgy nem is írtam sehol, hogy nagy rajongója lennék a checked exception-nek :) Én csak annyit írtam, hogyha valaki arra vágyik, hogy visszatérési értékben kapjon valamit, aminek a kezelésére rákényszerít a compiler, akkor erre a cheched exception konstrukció egész jól ráhúzható. És ugye ki is derült, hogy ezt vannak, akik csak becsomagolják RuntimeException-be, és továbbdobják nem checked exception-ként.

Ráadásul hülyeség is.

Hagy döntsem már én el, hogy akarok-e hibakezelést adott helyen vagy nem.

Csilliárd olyan kis tool-om van, ahol nem akarok hibakezelést. Pl. vár egy input file-t, ami ha nem létezik, nem olvasható, vagy bármi, akkor elperecel, kiirja melyik sorban milyen nem kezelt exception volt és kilép. Igy tökéletes, teljes agybaj lenne, ha nem fordithatnám igy le a programot.

Helyette pl. tudok global exception kezelést definálni, azaz a program belépési pontjánál definiálok egy olyan metódust, ahova befut bárhonnan(!), a máshol nem lekezelt exception, igy nincs olyan, hogy elfelejtettem lekezelni valamit, valahol és elveszik a hiba. Na ezt is nehézkes lenne error code-al megoldani.

Ezt nem teljesen értem, ezzel mit akarsz mondani. Onnan indultunk, hogy kell valami módszer a metódus által "várhatóan" visszaadott hibák kezeléséhez, lehetőleg compiler által ellenőrzötten. Ha van egy metódus, aminek nincs "természetes" visszatérési értéke, tehát alapból void jellegű lenne, de akarunk hibakezelést, és a checked exception vs. visszatérési értékben jelzett hibakód vonalon mozogva akarjuk ezt a hibakezelést megoldani, akkor két viszonylag egyértelmű lehetőség van:

-Checked exception a szignatúrában, és marad void visszatérési érték. Ez pl. a Java nyelv által adott lehetőség. Hogy mennyire működőképes nagy programok esetén hosszú idők tapasztalatai alapján, az megkérdőjelezhető.

-A void visszatérési értéket le kell cserélni egy hibát leíró visszatérési értékre. Vagy ennek a nyelvfüggő variáció, pl. kifelé menő paraméterek. Ez lehet integer vagy valami összetettebb objektum. (És ha ragaszkodunk ahhoz a kitételhez is, hogy compiler ellenőrizze, hogy ezt a visszaadott értéket ellenőrzi-e a programod, akkor olyan nyelvet kell használni, ahol erre van megoldás.).

Vagy most félreértek valamit, és másra vonatkozik a kérdésed? Nyilván a bármely ponton potenciálisan előforduló hibák, pl. a legtipikusabb amire szinte sehol nem készülnek előre, mégis bárhol előjöhet, a stack overflow, az egy egész más része ennek a kérdéskörnek.

Innen indultunk a közös "utunkon":

Ebben egyetértünk, hogy szintaktikailag nem olyan mint egy visszatérési érték. Viszont logikáját, folyamatát és lekezelését tekintve gyakorlatilag ugyanolyan, mint egy lehetséges visszatérési érték

Azt próbáltam bizonyítani neked egész eddig, hogy szerintem se a logikája, se a folyamata, se a kezelése nem ugyanolyan. Abbahagyom. :)

Abbahagyom. :)

+1 ;-)

A visszatérési érték az oda tér vissza, ahol hívták a metódust, annak az értéke. Ezért is hívják visszatérési értéknek. Nos, az exception az nagyon sok helyre visszamehet, csak oda nem, ahol hívták a metódust. ;-)

var valtozo = hivas();

A valtozo-nak semmilyen exception esetén sem lesz az értéke a dobott exception. Ha az lenne, akkor tekinthetnék visszatérési értéknek, mivel akkor tényleg az lenne ;-)

Egy kicsit próbáld meg átfogóbb szinten értelmezni, hogy mi a lényege annak, amit írtam, ne az egyenlőség jelre koncentrálj. Igen, a szintaktikája más az értékadásnak, mint a checked exception kezelésnek. Ennek nagyon egyszerű oka, hogy a checked exception-nek pont az a lényege, hogy ne tudd ignore-álni, kell egy compiler által ellenőrizhető szintaxis, mégpedig egy catch blokk (vagy throws a hívó szignatúrájában). Ha ugyanúgy nézne ki, akkor nem tudná a compiler ellenőrizni, hogy kezdesz-e vele valamit. Pont azért vezették be a checked exception-t mint nyelvi elemet, hogy a C stílusú "hívóként visszakapom az int hibakódot, de nem is adom értékül semminek, hanem leszarom az ellenőrzést" típusú programozói gyengeséget kiküszöbéljék.

Tehát ebből következik, hogy szintaktikailag nem az egyenlőség jel bal oldalán jelenik meg. De pont az a hasonlóság, hogy a hívás környékén kell megjelennie a checked exception kezelésének, ahogy a visszatérési értékkel is a hívás környékén kezdesz valamit.

A checked exceptionnél én ezt értem ez alatt, hogy a logikája, a folyamata, a kezelése hasonló a visszatérési értékhez: a függvény meghívásának a közelében foglalkozol vele, sőt a compiler által kikényszerítetten kötelező kezdeni vele valamit.

És ezzel áll ellentétben a nem checked exception, amit nem jelez semmi a szignatúrában, nem kötelező vele foglalkozni, és tipikusan a dobás helyétől sokkal távolabb kezeled.

Hát jó, kezdeni kell vele valamit, ami lehet akár annyi, hogy feltünteted a hívó szignatúrájában is - és akkor repül tovább feljebb. :)

Kezdeni leggyakrabban valahol ott kellene vele valamit (ha lejjebb nem sikerült sehol semmi stratégiát kitalálni), ahol absztrakciós/domain szintet lépne át (pl. io -> üzleti logika).

ha valami nem található meg egy adatszerkezetben, akkor egyik ág fut, ha megtalálható, akkor másik.

Szerintem ez nem hibakezelés, ez a normál működés két esete. Az exception (illetve bármilyen más hibakezelés) nem elágazás írására való.

Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

Így van. Az adott ponton a programozónak tudnia kell, hogy az a normál működés része, ha a keresett kulcshoz esetleg nem tartozik érték az adatszerkezetben. Ilyenkor ezt exception nélkül kell kétfelé ágaztatni.

Ha meg azt feltételezzük, hogyha minden előző művelet rendben volt és minden konzisztens és a keresett kulcsnak mindenképp benne kell lennie az adatszerkezetben, akkor meg lehet olyan kereső hívást használni, ami exception-t dob, ha nincs meg a keresett kulcs. És azt meg úgysem tudod helyben kezelni, hiszen pont az volt a feltételezésed, hogy csak akkor lehet helyes az egész lefutás, ha ott van a keresett kulcs.

Nem értek vele egyet. A hibaág és a happy path szétbontása, stack unwind, típusosságuk, stacktrace, a hiba elnyelés kockázatának mérséklése, a fordító által kikényszerített checked exception stb. olyan előnyök amit nem látok visszaköszönni a Eitherben és a hibaértékes megközelítéssel. A példád érdekes, de nem olvasható egy átlag programozónak, főleg nem annak aki hozzászokott a try/catch strukturákhoz illetve egyben van a happy path és a hibaág logika. A enterprise kódtermelésben az jó, ha a forrás szekezete, az alkalmazott idiómák stb olcsón kabantartható kódot alkotnak, aminek az egzotikus megoldások, egyéni nézőpontokat megvalósító szerkezetek nem barátai. 

A checked exception annyira jó, hogy egyedül a Javaban van, ha jól tudom, már a C#-sem vette át, annyi probléma van vele.

A enterprise kódtermelésben az jó, ha a forrás szekezete, az alkalmazott idiómák stb olcsón kabantartható kódot alkotnak

A enterprise kódtermelésben az jó, ha a forrás szekezete, az alkalmazott idiómák stb olcsón kabantartható írható és egyszerűnek kinéző kódot alkotnak. A karbantarthatóság viszont sokkal rosszabb, mint az értéket visszaadóknál.

a Rust-ban nem ellenséget kell látni, hanem a C reinkarnációját

A Rust egyik alapötlete -- ha nem "az" alapötlete -- nagyon vonzó. A szintaxisa viszont kritikán aluli. És ezt úgy mondom, hogy dolgoztam pl. OCaml-ben, aminek kifejezetten szép a szintaxisa. A Rust-ban (vagy legalábbis a Rust körülötti tooling-ban) számomra elfogadhatatlan még az automatikus csomagkezelés. Én nem tudom benne a C reinkarnációját látni.

Meg lehet nézni, mit kókányoltatok az elmúlt évtizedekben. Ezzel lett tele a fasz.

Ezzel sajnos nem tudok vitatkozni. Én is így érzem. Én szeretnék továbbra is C-ben dolgozni (most is abban dolgozom, a csapatommal együtt; embedded projekten), de majdnem mindenki másnak megtiltanám, hogy C-ben dolgozzon.

Volt alkalmam személyesen beszélni Ron Minnich-kel; megkérdeztem tőle, miért Go-ban kezdték el a u-root-ot (zárójelben: dolgoztam Go-ban, nem is sikertelenül; hidegrázás a C-hez képest). A válasza lényegében az volt, amit Tőled idéztem fent.

Ami még a C-t nagyon nehézzé teszi, az a szabvány fejlesztési folyamata. Egészen pontosan az, hogy a C egy nemzetközi (ISO) szabvány. Elképesztően nehézkessé teszi a közreműködést, ugyanakkor attól még, hogy ISO alá tartozik, a C (és C++) bizottságok belső listáin olyanok mennek, hogy attól még az LKML-es veteránoknak is lesülne a képéről a bőr.

Ez nem törvényszerű. Pl. a POSIX (mint spec) fejlesztése mind technikailag, mind közösségileg sokkal nyitottabb (és civilizáltabb), a kezdetek óta.

Az én számomra a C a C11-gyel kezdődően lejtmenetben van. A számomra leginkább vonzó verziója a szabványnak a C99.

(Megjegyzem: ISO szabványokból nincs igazából "verzió"; csak a legfrissebbet nevezzük szabványnak. Ami ma az ISO C, az a C23. [*])

Érdemes megvizsgálni a C23 Charter-t: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2611.htm

Additional Principles for C11

[...]

12. Trust the programmer, as a goal, is outdated in respect to the security and safety programming communities.

Ezzel nem tudok/akarok vitatkozni, de számomra már ez az egy pont -- ami elsőként a C11-nél jelent meg "elvként" -- önmagában megtestesíti az én személyes elidegenedésemet a C99 utáni verzióktól.

Elkezdtem egyszer olvasni a Modern C-t; nagyon hamar félredobtam. A C számomra nem azt jelenti, amivé mára vált.

Ami még az ember kedvét elveszi a C-től: a fenti [*] megjegyzésemmel összhangban a bizottság nem tart karban "stable" kiadásokat (néhány informális "worth backporting" jellegű megjegyzéstől eltekintve). Januárban elkezdtem a C17-et olvasni, "cover to cover" felkiáltással. (A C11 volt az első kiadás, amelyben megjelent a hivatalos memóriamodell, a C17 egy bugfix kiadás volt; a C23 nem érdekelt.) Az alapos átrágással a 6.5 Expressions előttig jutottam; írtam egy "N-cikket", és még a graz-i értekezletre is kimentem volna prezentálni (javasolták!), de kiderült, hogy a bizottságot csak a legfrissebb verzióval kapcsolatban érdeklik javaslatok, észrevételek. Így hagytam az egészet (a C17-et is, tokkal-vonóval).

Valahogy a C99 mögött álló bizottság, a comp.lang.c és comp.lang.c.moderated Usenet News csoportok "evidensnek", "relevánsnak" érződtek számomra. Az új ötletekkel kapcsolatban inkább ennek az ellenkezőjét érzem. (Pl. itt lehet azokról részletesen olvasni: https://thephd.dev.) Például a C-be behozni a Go-ból a defer-t (és még csak nem is úgy, ahogy a Go-ban van...) számomra egy agyrém. Nem arról van szó, hogy nem tudom követni. Nem akarom; nem értek vele egyet.

Az ISO C bizottság nagy dilemmával néz szembe: ha nem modernizálnak, akkor az új programozók nem hajlandók C-vel foglalkozni (ezt nevezték úgy, hogy a C "a COBOL sorsára jut"), ha pedig modernizálnak, akkor a C89/C99-en nevelkedettek elfordulnak a nyelvtől.

... Sajnos a C11 memóriamodell is -- amelynek a szükségességét nem lehet vitatni -- borzasztó. A C11-be a C++11-ből kendácsolták bele. Ahogy a szabványban le van írva (5.1.2.4 Multi-threaded executions and data races), az teljességgel érthetetlen (és ezt úgy mondom, hogy a release->acquire, release->consume, és sequential consistency szinkronizációt alapvetően értem). Az értetlenkedés kulcsa az, hogy a szabványban szereplő "kivonat" mögött valójában egy 400 oldalas doktori disszertáció áll (érdemes az Abstract-ot elolvasni!), ettől a számítástudóstól. A hardver van követhetetlenül elbonyolítva.

Én nem vonzódom a Rust-hoz, Zig-hez, Fil-C-hez, Go-hoz. Inkább olyan környezetben és projekten szeretnék dolgozni (és van alkalmam dolgozni most is, szerencsére!), ahol a C eredeti hivatása és jellemzői ma is érvényesek. Nem baj, ha niche; nem baj, ha nem mainstream. (Egyébként a csapatomban (saccra) az átlagéletkor 39 év, a minimumot 24-re teszem, a maximumot 58-ra.) Én nem bánom, ha a C "kihal velünk"; addig tudjam szeretni, amíg itt vagyok.

Fel kellene fogni, hogy:
  • a világ™ (tehát a Linux kernel) Rust nélkül is képes fejlődni.
  • a változtatgatás nem fejlődés, hanem visszafejlődés.
  • jól működő dolgok divatbuzi kidobálása nem fejlődés.
  • jó bornak nem kell cégér (a Rust-ot mégis erőltetik, kampányolják, influenszerkedik). Ami minden szempontból jobb, mint az elődje, az magától utat tör. Ki hiányolja pl. HTML5 videók helyett a Flash Playert?
  • a piac™ igénye nem a FOSS közösség és a Linux világ igénye. Akkor sem, ha multiék is commitolnak a FOSS projektekbe. A legtöbb FOSS-ban utazó milliárdos multi az open-source közösség ingyenmunkáján lett milliárdos multi. Hálával és tisztelettel tartoznak a közösségnek, nem felforgatással.
  • az öregedés arra sem mentség, hogy az elveidet feladd. Linus éppen ezt teszi, meg mindenki, aki a GNU/Linux vonalról beáll mögé.

Szerintem nem érted. A Linux kernel már nem egy hobbi projekt, hanem ezen fut a világ. Amikor a fejlődés irányait kitűzik, felmerülnek szempontok.

A milliárdos multi nem az open-source közösség munkáján lett milliárdos multi. Pont fordítva volt: ők tolták bele a lóvét évtizedeken át. Ezért nem ott tart most a Linux mint mondjuk a BSD.
A BSD-t meg meg lehet nézni, hol tart az elveivel.

Hogy mindez jó vagy rossz, azzal kapcsolatban nem szeretnék értékítéletekbe bocsátkozni, mindenki döntse el maga. Pusztán a percepcióimat írtam le.

Pont fordítva volt: ők tolták bele a lóvét évtizedeken át.
Nem lóvét toltak bele, hanem fejlesztői munkát, cserébe azért, mert mások ennek a munkának az alapjait már ingyen lerakták. Miért toltak bele olyan fejlesztői munkát, ami a közösségnek is hasznos? Elsősorban azért, mert a GPL kötelezte őket erre. Miért ebbe toltak fejlesztői munkát? Mert azokat az alapokat, amikre ráépítkeztek, nem kellett nulláról megírni, mert korábban már megírta a közösség. Az összes ma ismert Linux-multi semmi mást nem csinált startup korában, mint csomagokat buildelt és eladta a saját márkaneve alatt. Aztán, amikor már volt ügyfélbázisa, jöttek az ügyféligények és próbált hozzá többé-kevésbé igazodni.
Ezért nem ott tart most a Linux mint mondjuk a BSD.
Jelenleg ott tart a Linux, hogy a multik felforgatják és egy szarabb, húgyabb, bloat-abb valamit csinálnak belőle, arra való hivatkozással, hogy hát ők mennyi fejlesztőt fizettek, akik eddig is commitoltak bele.
A BSD-t meg meg lehet nézni, hol tart az elveivel.
Meg lehet, igen. Köszöni szépen, jól van systemd és a Red Hat enterprise-buzi mocskai nélkül. Ami teljesen jól van így. Ha valamelyik multi oda akar szarni az asztal közepére, akkor szépen elforkolja, és magának megcsinálja, mint tette az Apple a FreeBSD 4.4-gyel és csinált belőle MacOS-t, meg iOS-t. Így nem az egész közösség faszával fogja verni a csalánt, nem az egész BSD-világot fogja felforgatni, csak azért, mert túlárazott, semmivel sem kompatíbilis notebookokat és okostelefonokat szeretne eladni és ahhoz kell az animációbuzi kezelőfelülettől kezdve minden. Míg egy Linux-ban utazó multi (élen a Red Hat-tal) az egész Linux közösség torkán lenyomná a szutykát. A systemd-vel, pulseaudio-val, pipewire-rel, wayland-del sem lenne semmi baj, ha megmaradna a RHEL világban, de mivel multiék felfalták a népszerű desktop-környezetek (pl. GNOME) fejlesztőit/fejlesztését is, így mindenkin nagyobb a nyomás, hogy igazodjon a felforgatáshoz.

Félreértés ne essék, nekem se tetszik sok dolog, ami a Linux háza táján történik, és amerre tart. A systemd miatt például különösen fáj a szívem. De említhetném a Wayland-et, és még sok mást. Nekem már egy GNOME vagy KDE is felesleges túlzás volt. Hozták magukkal a bloat fos ökoszisztémát (és ez még nem enterprise mocsok volt). Egy fluxbox vagy IceWM mindent tud, amire valójában szükség van.
A mérleg másik serpenyőjében ott van, hogy a kilencvenes-kétezres években legtöbb hardverhez nem volt egy tisztességes driver, szopni, hekkelni kellett lépten-nyomon, ha Linuxoztál. Amit magam személy szerint még élveztem is. (Ugyanakkor megértem azt is, hogy én a kivétel vagyok, és a többség ezzel nem így van.)
Ezzel szemben ma egy villanyborotvára fel tudsz tenni egy Linuxot, és megy rajta a wifi meg a bluetooth out-of-the-box.

Lehet úgy is tekinteni, hogy még szerencse, hogy a Linuxot karolták fel és vakarták ki a geciből. Szembe kell vele nézni, hogy a magunk fajta buzi messze egy szemmel alig látható kisebbséghez tartozik. Irreális az elvárás, hogy ránk szabják ezeket a dolgokat.
A különbség köztünk, hogy - bár magam sem örülök neki - én ezt megértem, és elfogadom, hogy ha buzulni akarok, lehet menni BSD-zni. Mert az élet szerintem többről szól, mint megkeseredetten árral szembe hugyozni és folyamatosan panaszkodni. Abban a szerencsés helyzetben van részünk, hogy OS-ből van bőven választék. Vagy akár Linux disztróból is, ha az ember nem szeretne messzire menni.
Panaszkodás helyett van tehát hova nyúlni. Egy BSD meg kb. pont olyan, mint a Linux volt '97-ben, ha valakinek ez hiányzik.

Ha más vagy, mint az átlag, és nem tanulsz meg ezzel egy megfelelő viszonyt kialakítani, a dolgokat a helyükön kezelni, akkor az élet fájni fog.

A systemd miatt például különösen fáj a szívem. De említhetném a Wayland-et, és még sok mást. Nekem már egy GNOME vagy KDE is felesleges túlzás volt.
Akkor ebben egyetértünk. Szuper.
A mérleg másik serpenyőjében ott van, hogy a kilencvenes-kétezres években legtöbb hardverhez nem volt egy tisztességes driver, szopni, hekkelni kellett lépten-nyomon, ha Linuxoztál.
Most pedig már van, azokhoz a 90-es 2000-es évek hardvereihez is, meg a mostaniakhoz is. Mégsem Rust-ban írták.
Szembe kell vele nézni, hogy a magunk fajta buzi messze egy szemmel alig látható kisebbséghez tartozik.
Valójában meg a Rust-ot erőltetők vannak kevesebben, csak ők hangosabbak és multis-céges-milliódolláros felhatalmazással beszélnek. Egy kisebbségen (Linux-felhasználók, fejlesztők) belüli kisebbséget (Rust-ot erőltetők) akarsz beállítani többségnek.
https://a.te.ervelesi.hibad.hu/kozvelekedesre-hivatkozas
Irreális az elvárás, hogy ránk szabják ezeket a dolgokat.
Itt meg már elkezdesz szalmabábozni is. A probléma az eredeti irányelvek, architektúra, ökoszisztéma felforgatásával van, nem azzal, hogy a felforgatás utáni állapot tetszik vagy nem tetszik pinknek vagy hajbazernek.
én ezt megértem, és elfogadom, hogy ha buzulni akarok, lehet menni BSD-zni
Vagy bármelyik systemd-mentes Linuxra, mert ugye olyanok is vannak, amik önmagukban bizonyítják, hogy a Red Hat felforgatása nem az egyetlen irány. Sőt, nem csak buzulni lehet rajtuk, hanem használni is lehet őket ugyanúgy, mint egy systemd-fertőzött disztrót.
Mert az élet szerintem többről szól, mint megkeseredetten árral szembe hugyozni és folyamatosan panaszkodni.
Az élet valóban többről szól. Ezek a HUP topikok, amikbe kommentelünk, már nem biztos. :)
Ha más vagy, mint az átlag, és nem tanulsz meg ezzel egy megfelelő viszonyt kialakítani, a dolgokat a helyükön kezelni, akkor az élet fájni fog.
https://a.te.ervelesi.hibad.hu/kozvelekedesre-hivatkozas második alkalommal.
Spoiler: Az átlag nem használ Linuxot.
Főleg nem olyan célokra, mint te egy BSD-t. :)

Igen, a Linux nem megy a legjobb irányba. A systemd-re túl sok minden dependel, az vele a baj. A Waylanddel sem lenne önmagában bajom, a baj azzal van, hogy az ellenében az X.org-ot próbálják agresszíven elavultatni, azt nem kéne. A Pipewire és Wireplumber is bloat sajnos, rá van tolva mindenkire. Az ilyen mainstream DE-ken, GUI-kon én rég túlléptem, hogy Gnome, KDE, az a normiknak van. Hála istennek van még systemd-mentes disztró, meg X-et szállító disztró, sovány X-es ablakkezelő, addig mindig van alternatíva, nem muszáj a mainstream-et (Ubuntu, Red Hat) követni.

Én a magam részéről már arra is felkészülök, ha a Linuxszal történne valami, hogy BSD-re vagy illumosra lehessen váltani. Ügyelek rá, hogy a rendszerem portolható legyen, X11, minimalista tiling WM C-ben, POSIX kompatibilis shell scriptek, hordozható konfigfájlok, bármikor át tudjak járni más unixos, unixlike rendszerek felé. Pont azért, hogy globális gigamultik ne tudják alólam a rendszerem, workflow-m kiavultatni, ne kelljen új divathullámra felszállni, új szoftvereket és megoldásokat újratanulni, újra megszokni.

Igazából én egy waylandes váltásra is kész vagyok, arra is van eltettt Sway-konfigom, meg szkriptek, csomaglista, szóval ha az X11-et sikerülne is kinyírniuk, akkor is van bejáratott rendszerem, B tervem rá.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

Az, hogy nem vagy képes felfogni valamit, nem jelenti azt, hogy az automatikusan baromság. Az, hogy nem tudsz valamivel vitatkozni, mert érvelés helyett csak személyeskedni tudsz, szintén nem jelenti azt, hogy ne lehetne valamivel vitatkozni.
Ha egyszer a lamerről szobrot állítanak, te leszel a model.
Helyesen: modell
Tessék: https://www.artmajeur.com/clark-camilleri/en/artworks/15208090/la-mer
Nekem ez inkább egy fordított W betűre hasonlít, willyke. 🤡

A helyzet az, hogy a véleményed mondtad el kijelentésekbe formázva, de semmit sem értesz abból amit történik. Linus nem azért teszi ezt mert ehhez van a legnagyobb kedve, hanem azért képes lépést tartani a világgal. Pont ezért tart ott a Linux manapság ahol. 
De elég ha körülnézel te mit értél el, és mit ért el Linus ezzel a felfogással, hogy belásd, hogy ehhez kell rugalmasság és szakértelem. Ezek meg nálad nem léteznek. 
De ez teljesen mindegy mert szerencsére se megállítani, de még megakasztani se fogod tudni a fejlődést.

Én nagyon szerettem anno Flashben programozni. Sztem kib@szott nagy durranás volt, innovatív, inspiratív. Tulképp máig nehéz olyan dolgot találni webes területen, amit akkoriban ne tudott volna a Flash. És a Macromedia zseniális szerkesztőt csinált hozzá, tényleg öröm volt vele dolgozni. Kár érte. 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Fejlesztői szempontból lehet, hogy jó volt, ezt nem tudom megítélni, de a web koncepciójába egyáltalán nem illett.

Például teljesen flash oldalak esetén, böngészőn belül sem tudtál szóra rákeresni, a keresők sem tudták indexelni, az oldalak nem voltak átméretezhetők és még biztos lehetne sorolni. Én nagyon örülök, hogy eltűnt. Legfeljebb cirkuszi megjelenésnek vannak most korlátai ilyen szempontból, de az nem hiányzik.

( bazso | 2025. 12. 01., h – 12:37 )

Nemcsak Linus öregszik, az új generációt nehéz lesz meggyőzni, hogy tanuljon C/C++, legyen vele 10 év hardcore tapasztalata és utána talán nyúlhat kernel kódhoz. Úgyhogy ebben van jó adag előremenekülés is.

( asch v | 2025. 12. 01., h – 15:06 )

Nekem már akkor gyanús volt, amikor amerikába költözött. :-)

( Caro | 2025. 12. 01., h – 17:31 )

Van klibc, van kernel-doc, kbuild... biztos vagyok benne hogy meg fogják találni a módját (ha még nem találták), hogy a rust mentes legyen a külső függőségektől.

Tudtommal meg is van találva. Nem szabad std-t használnod, csak core-t és bármi library, amit a kernel fejlesztők engedélyeznek a kernelben használatra, szintén nem hozhat be olyan külső függőséget (std-t sem), amit nem explicite engedélyeztek.

Régóta vágyok én, az androidok mezonkincsére már!

( ggallo | 2025. 12. 01., h – 18:02 )

Nem értem ezt a szintű Rust ellenességedet abban a korban, amikor lasszóval sem lehet összefogdosni egy maréknyi fiatalt világszinten, hogy tanuljon C-t. Hosszú távon abból lehet választani, hogy vagy olyan nyelveken fejlesztenek amin hajlandóak, vagy elhalnak projektek, ha nincs olyan nyelven fejlesztő, amit erőltetnének rájuk. Nem abba kellene ennyi energiát beletenni, hogy irtsunk mindent, ami 30 évnél fiatalabb technológia, hanem abba, hogy a lehető legjobban lehessen vele (együtt)dolgozni...

Megint elképesztő baromság több okból is. A fő aggodalom pont az, hogy ha juniorok helyett mindenki LLM-et használ, akkor kikből lesz majd a következő generáció senior rétege?

Itt pont azt mondta, hogy az AI segítségével szerinte felkelthető a fiatal fejlesztők érdeklődése, hogy "újra izgatottak legyenek". Szó nem volt LLM-ek használatáról juniorok helyett...

Nem biztos, hogy örülni kéne annak, hogy odafostak 1 millió ellenőrizetlen kódsort

Valóban nem kell örülni a nVidia open source felé nyitásának! Ha nem tudnak elsőre tökéletes, karcsú, tiszta, jól olvasható, auditált, duplikátumot nem tartalmazó drivert adni ingyen, akkor bele se kezdtek volna. Majd szopik mindenki a Nouveau-val tovább meg prüszölünk inkább a zárt meghajtóra. Linus is elsőre megírta tökéletesre és teljesre a Linux kernelt, azóta csak maszatol az a sok ember.

Hol van már az a jó öreg Linus (akit még nem a Microsoft pénzelt) és kifakadt, hogy túl bloated a kernel? 

Miért gondolod, hogy ha a Microsoft fizeti a bérét, akkor azt mondja, amit ők akanak, és kizárt, hogy neki ez legyen a véleménye? Naponta jön hír arról, hogy a bloat és a rossz kód ellen küzd a mai napig. Attól, hogy nem szólta le szélsőségesen az AI-t meg a Rust-ot a Te elvárásaid szerint, még nem lett elpuhult...

Másrészt egy egyszerű nyelv, könnyű tanulni.
És kiforrott. Nem változik fél évente a specifikációja és a fordítója, mint a Rust-nak.

De az egész "szeretem-e" kérdéskör eleve értelmetlen, mikor az LKML-en konkrétan arról folyik a vita, hogy milyen nyelvi változtatások szükségesek még a Rustban, hogy egyáltalán lehessen integrálni...
Ezeket még csak most tervezik bevenni a Rust specifikációba, még benne sincsenek.

Ha nem is teljesen felelesleges gondolkozni, de azért van valóságalapja ennek. Ahogy használom az AI-t, és látom, hogy mire képes, miközben azt is látom, hogy most mit tanulnak a gyerekeim az iskolában. Néha még magamat is nehéz meggyőzni, hogy jelen formájában mi értelme van az oktatásnak. Az általános iskolás és gimis tudáshalmazt és feladatmegoldást nagyon nagy részben teljesen jól helyettesíti. Persze közben meg mégis az az elvárásom, hogy a gyerekek igenis rendelkezzenek AI nélkül is műveltséggel és gondolkodási képességgel.

Pont a kritikus gondolkodást meg az ok-okozati összefüggéseket nem fogják AI-al megtanulni a gyerekek, hiába "oldja meg" a feladatot az AI. (több-kevesebb sikerrel)

Ez ugyanaz, hogy hiába van számológép (most már mindenki zsebében) attól még hasznos dolog, ha össze tudsz adni két számot vagy van valami fogalmad, hogy reális-e az ár, ami 8 db termékért kérnek a boltban.

Ha nem tanulják meg, mert az AI majd úgyis megoldja, akkor rettenetesen buták lesznek és olyan szinten ki lesznek szolgáltatva, amit ma el sem tudunk képzelni.

Ha felnő egy olyan réteg, aki a legelemibb összefüggéseket, feladatokat sem tudja ellátni AI nélkül, akkor a rabszolgái lesznek. Az árát meg nyilván az egekbe fogják emelni, hiszen az élete fog múlni rajta, hogy elérje az AI-t.

Kicsit olyan ez, mint a mai fél-önvezető autók. Kezdő vezetőnek életveszélyes a kezébe adni, mert képtelen lesz lekezelni az esetet, amikor váratlanul visszakapja a vezérlést (vagy vissza sem kapja, hanem neki kéne észrevenni, hogy át kéne vegye, mert hülyeséget csinál az "AI") és még azt a keveset is elfelejti, amit megtanult a vezetésről. Ellenben egy tapasztalt vezetőnek rohadt jó és kényelmes. AI ugyanez.

Eleinte furcsa volt AI támogatással programozni. Van azonban előnye is. Nem kell elmélyedned matematikai modellekben, egy-egy kódrészletet legenerál az AI századannyi idő ráfordításával.
Ahol elválik az ocsú a búzától: vajon az adott kóder tudja-e relevánsan challengelni, ellenőrizni, hogy jól működik-e a generált kód? Vajon felismeri-e azt, ha hibásak az apriori feltételezések?

Általános célra most is elég a gyengébb kóder.
Ahol fontos a tisztességes munka (imho ez a projektek egyszámjegyű százaléka), ott AI-val támogatottan is szükség van arra az emberre, aki tudja, mit csinál.

Nem értem ezt a szintű Rust ellenességedet
Te tajgetosz-pozitív vagy ezzel a szintű szövegértési képességeddel, ugye?

Az, hogy én mit gondolok a Rustról, egyáltalán még csak nem is szerepelt a posztban. A Linux kernel fejlesztők véleményét soroltam fel, és persze ezekre képtelen voltál reagálni (várható volt).
vagy olyan nyelveken fejlesztenek amin hajlandóak
Mit gondolsz, miért van akkor folyamatosan annyi új C nyelvű repó a githubon?
az AI segítségével szerinte felkelthető a fiatal fejlesztők érdeklődése [...] Szó nem volt LLM-ek használatáról juniorok helyett
:facepalm: Az LLM segítségével felkeltett érdeklődésű fiatal fejlesztők szerinted mit fognak akkor használni? Az agyukat vagy az LLM-et?
Ha nem tudnak elsőre tökéletes, karcsú, tiszta, jól olvasható, auditált, duplikátumot nem tartalmazó drivert adni ingyen, akkor bele se kezdtek volna.
:facepalm: te tényleg nem érted, miért baj az, ha review-olhatatlanul kerül kód a kernelbe. Segítek: nézd meg, más esetekben hogyan reagálnak az ilyen masszív patchekre a kernel fejlesztők!
Miért gondolod, hogy ha a Microsoft fizeti a bérét, akkor azt mondja, amit ők akanak
:facepalm: no comment. És nem "ha", mindenki tudja jól, ki fizeti Linust. Nyilvános.

Te tajgetosz-pozitív vagy ezzel a szintű szövegértési képességeddel, ugye?

Igen. Gondolom. Bár nem tudom mi az a tajgetosz-pozitív, de remélem jó dolog (...pozitív...), így gondolom az vagyok.

Mit gondolsz, miért van akkor folyamatosan annyi új C nyelvű repó a githubon?

Szerintem a nagy öregek vágnak bele újabb projektekbe. Biztos nem fiatalok tömegei kezdtek C-ben programozni.

Az LLM segítségével felkeltett érdeklődésű fiatal fejlesztők szerinted mit fognak akkor használni? Az agyukat vagy az LLM-et?

Ha egy kis eszük van, mind a kettőt. Mert miért pattintanánk kőből kést, ha van olcsón jobb rozsdamentes acélból az IKEA-ban? Az, hogy segítségül hív egy LLM-et, vagy el akarja végeztetni a munkáját LLM-el, óriási különbség. És az oktatás (meg a senior-ok, akik nyitottak, nem laggardok) tudják ezt a különbséget megtanítani nekik.

te tényleg nem érted, miért baj az, ha review-olhatatlanul kerül kód a kernelbe. Segítek: nézd meg, más esetekben hogyan reagálnak az ilyen masszív patchekre a kernel fejlesztők!

Linus kernelét ki review-olta amikor kiadta? Jaaa, senki. Aztán idővel kiderültek a bajok meg hiányosságok, és javították, fejlesztették. Ez a fejlesztési folyamat lényege. Bekerült egy kódbázis, amit el lehet kezdeni átnézni, javítani, fejleszteni.

no comment. És nem "ha", mindenki tudja jól, ki fizeti Linust. Nyilvános.

Itt azért visszanyal ez a szövegértési tajgetosz szerintem. A "ha" itt nem Linus fizetésének forrására vonatkozott...
Az szerintem csak Neked egyértelmű, hogy ha az MS fizeti, akkor azt mondja amit az MS hallani akar, mert ez szokás itt a kommunizmusba. Mi - szerintem a többség - azt gondoljuk róla (Linus-ról), hogy annak ellenére, hogy az MS fizeti, továbbra is azt mondja amit gondol, nem amit elvárnak tőle.

>Szerintem a nagy öregek vágnak bele újabb projektekbe. Biztos nem fiatalok tömegei kezdtek C-ben programozni.

Meglepődnél, de van egy ilyen trend is. Néhány link: https://bettersoftwareconference.com/ Wookash podcast, https://www.nicbarker.com/, https://www.youtube.com/tsoding

Lehet azzal jönni, hogy jó de ők már inkább 30-asok, de nézd meg, hogy online jelenlétük van, minden videó alatt van élet is a komment szekcióban, és a fiatalok is követik őket.

A C valójában egyszerű és barátságos nyelv. Pont a Rusthoz képest sokkal alacsonyabb a belépési küszöbe. A legkomplexebb fogalom a pointer, amit kicsit nehezebb megérteni, de nem kell borrow checkerrel foglalkozni egy hello world-höz. (Na meg az effektív típus és az undefined beaviour, de ezeket nagyvonalúan el lehet sikálni jó sokáig nem kell foglalkozni vele.)

Félreértés ne essék, én nem vagyok a C ellen, és nem vagyok a Rust mellett.

Szerintem csak az a harc a felesleges, hogy küzdjünk minden ellen ami nem C, mert csak C-ben lehet jól megcsinálni, meg különben is.

A másik trend, hogy a fiatalok, akiket ha véletlen érdekel az informatika (mára ez sem annyira népszerű terület, mint akár 10 éve volt) és véletlen ezen belül a fejlesztés, akkor nyilván a modernebb-újabb nyelvek felé orientálódnak javarészt, mert azt keresi a piac. Ezzel nem azt mondom, hogy ezek jobbak a régebbi nyelveknél, hanem azt, hogy aki a szoftverfejlesztésre teszi fel a karrierjét, az nyilván piacképes nyelvet akar megtanulni, amivel a lehető legtöbb pénzt keresi, amire a legnagyobb igény van munkáltató oldalon. Az viszont egyértelműen nem a C nyelv mostanában (de nem is a Rust).

A hobbifejlesztők meg simán lehet, hogy maradnak a C-nél, és rá se néunek másra, de szerintem nagyon vékony az a réteg, aki hobbifejlesztő C-ben, jó is benne, de valami tök más a főállása, nem programozó. Szóval nem ők fogják meghatáronzi a trendeket.

>Szerintem a nagy öregek vágnak bele újabb projektekbe. Biztos nem fiatalok tömegei kezdtek C-ben programozni.

Meglepődnél, de van egy ilyen trend is. Néhány link: https://bettersoftwareconference.com/ Wookash podcast, https://www.nicbarker.com/, https://www.youtube.com/tsoding

Lehet azzal jönni, hogy jó de ők már inkább 30-asok, de nézd meg, hogy online jelenlétük van, minden videó alatt van élet is a komment szekcióban, és a fiatalok is követik őket.

A C valójában egyszerű és barátságos nyelv. Pont a Rusthoz képest sokkal alacsonyabb a belépési küszöbe. A legkomplexebb fogalom a pointer, amit kicsit nehezebb megérteni, de nem kell borrow checkerrel foglalkozni egy hello world-höz. (Na meg az effektív típus és az undefined beaviour, de ezeket nagyvonalúan el lehet sikálni jó sokáig nem kell foglalkozni vele.)

+1

C nagyon kellemes, barátságos nyelv Rusthoz képest. Sok éve egyetemen azzal kezdtük a programozást, kicsit fájdalmas volt,  de utána jött még egyetemen meg munkában is Java, C#, C++ és sok kisebb munka random nyelveken. Ezekhez képest a C egy barátságos, letisztult és elegáns nyelv (szerintem). Az én ízlésemhez legközelebb a C és a Python van és nagy mák, hogy ebben a két nyelvben a munkám 99%-át meg tudom csinálni.

Linus kernelét ki review-olta amikor kiadta? Jaaa, senki. Aztán idővel kiderültek a bajok meg hiányosságok, és javították, fejlesztették. Ez a fejlesztési folyamat lényege. Bekerült egy kódbázis, amit el lehet kezdeni átnézni, javítani, fejleszteni.

Az már múltkor kiderült, hogy neki van egy határozott vélemény arról, hogy hogyan kell a kernelt fejleszteni (branchek :D :facepalm), és nem hagyja, hogy a valóság véletlenül is befolyásolja ezt a véleményt:)

( whitehawk v | 2025. 12. 02., k – 14:00 )

Torvalds thinks AI's best use may be to help get young developers excited about programming.

Megint elképesztő baromság több okból is. A fő aggodalom pont az, hogy ha juniorok helyett mindenki LLM-et használ, akkor kikből lesz majd a következő generáció senior rétege?

Az, hogy mi Linus szerint az MI legjobb felhasználása, és hogy mi az MI-val kapcsolatos fő aggodalom fejlesztés terén nem zárja ki egymást. Hátha egy másik példa segít: "szerintem az atom legjobb felhasználása az energiatermelés" vs "sokan aggódnak, hogy az atom elpusztítja a világot"

Software is like sex, it's better with a penguin. :D (r)(tm)(c) آكوش

( carlcolt | 2025. 12. 03., sze – 06:32 )

> Torvalds thinks AI's best use may be to help get young developers excited about programming.

Megint elképesztő baromság több okból is. A fő aggodalom pont az, hogy ha juniorok helyett mindenki LLM-et használ, akkor kikből lesz majd a következő generáció senior rétege?


Tevedes. A mai juniorok tobbet tudnak a regi junioroknal, mert ha elakadnak, sokkal hamarabb megvalaszolja nekik az LLM, hogy milyen iranyba menjenek, amikor hibat keresnek.

Mi idonkben nehezebb volt: napokat vartal egy forumon, hogy "ez a class miert nem tudja annak a class-nak a memberet modositani" es csomo mellebeszelos valaszt kaptal, pl. Immutability-evangelistaktol es egyeb figyelemzavaros szofosasos forumozoktol, hogy ok hogy gondolnak ujra az egeszet.

(A gond ott kezdodik, ha a junior nem elakadas konkret targyat kerdezi az AI-tol, hanem vibe coding jelleggel tobbezer sor szemetet termeltet vele. Igen, van, olyan is, nem tagadom.)

"Tevedes. A mai juniorok tobbet tudnak a regi junioroknal, mert ha elakadnak, sokkal hamarabb megvalaszolja nekik az LLM, hogy milyen iranyba menjenek, amikor hibat keresnek."

  1. Az LLM vagy hülyeséget mond neki vagy nem. Sokszor bizony hülyeséget mond. Egy bizonyos szint felett egyre gyakrabban.
  2. Jópár cikk szól arról hogy amit az LLM-től kap meg válaszban az ember azt nem tanulja meg.

És itt arról a juniorról beszéltünk aki akar tanulni. Nem mind akar.

Lehet hogy első ránézésre a diskurzus hasonlít, de ha végignézed a feladatmegoldás tipikus lépéseit akkor nagyon különböző dolgokról beszélünk. 

Egy Google keresés eredménye nem fog neked felhasználásra kész eredményt adni. Egy megfelelő környezetbe betolt prompt meg igen.

Mondok egy példát: éppen most promptolok egy iphone-ra készülő Swift nyelven írt alkalmazást. 
Fog futni? Fog bizony. Addig fogom faragni hogy fusson. 

Érteni fogok a Swifthez? Dehogy...
A promptoláshoz meg a teszteléshez fogok érteni.

Kezdődött valahol az internet megjelenése környékén egy szép kis komplexitás és tudásanyag robbanás, és mára már egy programozási nyelvhez tartozó ökoszisztémát vagy platformot se lehet egy aggyal átlátni vagy megszakérteni. És akkor jönnek az öregek és "sírnak", hogy a mai fiatalok semmihez se értenek és hová lesz így a világ, mert az AI-t kérdezgetik ahelyett, hogy a keresőmotort, a  könyveket, a fórumokat, vagy stackoverflow-t bogarásznák. :D

Szerintem tanulságosak. Ha másra nem is jók (úgy értve, hogy az adott konfiguráció viszonylag kevés helyen létezik), arra nagyon is, hogy lássuk, hány nagy és neves projektben is megvan a 'jóvanazúgy' aka. 'worksforme' hozzáállás.

Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

Az van, hogy a Te kritérium-koordinátarendszeredben értelmezve szinte csak babzsákfejlesztők vannak. Látni kell, hogy programozni nem önmagában a programozás szépségéért szoktunk, hanem a felmerülő problémák gyors megoldását kell szem előtt tartani. Ki kell termelni a ráfordítást. Mindenki a golden path-ra fejleszt, aztán ha valami nagyon böki az ánuszt, legfeljebb majd kijavítjuk, vagy csinálunk valamit. De csak akkor, ha tényleg annyira fáj, hogy megéri vele foglalkozni. Ez a realitás.

Nagyon kicsi az a terület, ahol mission critical kód kell, és gazdaságilag is az az optimum.

Azért tartom részben meddőnek a fenti vitát (error as a value vs. exception), mert hibát kezelni valójában senki se szeret. Hiszen az eredmény szempontjából elbaszott idő. A nagyon nagy disznóságokra még csak-csak csinálsz egy csekket, aztán elengeded a kezét. A tapasztalat az, hogy ezek ellenére sem dől össze a világ.

( Raynes v | 2025. 12. 05., p – 05:01 )

Szerintem nem kurvult el, csak nem meri túl keményen megmondani a véleményét, mert rossz PR neki. Így felvette ezt a polkorrektkedő, szeretjük és lelkileg kíméljük a hülyéket módszerű szerepkört, hogy ne érje rossz hír, hogy agresszív meg mindenkire ugrik, aki nem azokat az elveket vallja, amit ő.

Teljesen egyetértek veled, szerintem is baromság, amiket mondott. Az AI/vibe coding az egyik legrosszabb megközelítés egy kezdőnek, mert azt fogja hinni, hogy a gép, hardver az akarata szerint működik, nem az utasítási szerint. A Rust-ot meg hiba volt a kernelbe engedni, bár ez lehet egy olyan probléma, ami megoldja magát, mert máris csak 1 karbantartó maradt a 3-ból, szépen fogyatkoznak a rusztafárik, adják fel.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

Jo, de kell valtoztatni ezen az elgondolason ahhoz, hogy amugy sikeresen irjak Rust kodot, ha mar egyszer majd muszaj lesz es azert fizetnek? :)

Vagy azon az elgondolason kell valtoztatnom, hogy "lehet, hogy csak negyen gondoljuk igy"? Kb. az egyetlen logikus kiutad, ha erre gondoltal. :D Nem en lennek az elso, aki utalja vagy feleslegesnek tartja a munkajat, vagy valamelyik munkaeszkozet. :)