Az amerikai nemzetbiztonság szerint is felejtsük már el végre a C-t és a C++-t

Az amerikai nemzetbiztonság szerint is felejtsük már el végre a C-t és a C++-t
2022-11-11T11:18:10+01:00
2022-11-14T15:58:23+01:00
2022-11-14T16:15:29+01:00
  • Hát annyi hogy ha a zöld lámpánál egyes helyett hármasba kapcsolsz és lefulladsz, akkor abból csak anyázás lesz de anyagi kár nem szokott keletkezni. Itt viszont anyagi vonzata is lehet egy hibának.
    Mutasd a teljes hozzászólást!
  • Akkor inkább azzal lehetne példázni maradva a vezetésnél, hogy aki rutintalanabb/kényelmesebb az használja az automata váltót, aki meg rutinosabb és szeretne optimálisabb fogyasztást is használja a manuálisat. Automatánál is lehet persze spórolni, de csak közvetett módon és az már plusz erőbefektetést jelent.
    Mutasd a teljes hozzászólást!
  • Ha TFLOPS-ban jelent neked valamit a teljesítmény, akkor nyugodtan vedd ide a GPU-t, mert ebben az fogja az igazi teljesítményt nyújtani, és az eredeti megjegyzésedhez akkor annak már kevés köze van. 

    de amugy tud C++ kodot futtani, plane, hogy az egy nyelv, es nem kod

    Az nem az a C++ (forrásból generált) kód, amit te itt most próbálsz szembeállítani a már nem is tudom mivel, mert azzal a GPU nem sokmindent tudna kezdeni. 

    GC-vel semmi bajom, sok helyen nagyon jo, de azt feltetelezni, hogy megoldja a problemaid, mar ha vannak, szerintem tulzas.

    Nincsenek feltételezések. Konkrétan megold problémákat, többet is. A memory safety, az interoperabilitás támogatása triviálisan adott, a defrag szintén (ennek azért ugye van valamennyi köze a TLB-hez is, sőt (*)), a mallocnál hatékonyobb allokálás, a batchben memória felszabadítás (ami már nem referált objektumokra tök ingyen van) simán hatékonyabb, mint a rengeteg free(). Ezek nem várakozások, hanem tények. Ahogy az is tény, hogy csomóan nem értik a GC-t, össze-vissza allokálgatnak, new genből old genbe referálgatnak, mindenféle életciklusú objektumokat allokálgatnak stb, amivel szép problémákat lehet okozni. És pont ilyenek miatt szoktak nem jó teljesítményűek lenni a mindenféle random libekkel megírt programok, mert nem ez van fókuszban. 

    Nagyteljesitmenyu rendszereknel, mar terevzesnel is figyelembe vesszuk, hogy optimalizalod a TLB-t, vagy eppen huge paget haznalsz, milyen lesz az eloszlasa a cachenak (pl. CPU-k kozott, mar ha tamogat ilyet). Memoria busz allokaciok szinten pinnelve vannak. Ha van OP akkor nagyon nem mindegy, hogy van kiosztva a memoria, es CPU-k, a lenyeg, hogy ez itt egy nagyon hosszu felsorolas lenne, ami vegen siman nyersz 100%, vagy akar tobbet performanicaban, ahelyett, hogy azt mondjuk a GC az ugy is jo.

    Igen, ezeket tudom. Meg azok a korábbi C++ fejlesztők, akik nagyteljesítményű C++-ban írt rendszereket cseréltek le Java-ra, vagy az új rendszereket már Javaban írták is tudják, és ennek ellenére (ezzel a tudással) mégse a C++-t választották. A Java nyelvi eszközei alapvetően nem arra vannak kitalálva, hogy ilyen low-level dolgokra optimalizálj. De ha ezeket is, és a JVM-et is tudod hogy működik, akkor mégis tudsz. TLB-re, cache-re, tudsz pinnelni stb. De ez a téma már nagyon-nagyon messze van attól, amikor arról van értelme beszélgetni, hogy az esetek igen-igen nagy részében nem fogsz teljesítménykülönbséget látni. Amiket írtál, azok már az utolsó cseppek kifacsarása, és mint ilyen bőven kívül esik a rendszerek többségén. Amellett, hogy ennek már köze sinc sok a GC-hez. GC allokátor is tud egymás mellé helyezni összefüggő objektumokat pl. Másolásnál szoktak is ilyet egyébként.

    Csak, hogy lassuk a GC mennyire nem jo, mind az MS, mind az Apple, vagy a JVM mar a sokadik generacios GC-nel tart, adott esetben teljesen szakitva a korabbi memoria modellel (Objectuive-C -> Swift), ha olyan jok lennenek, nyilvan nem kellene ennyit faragni rajta, persze eset fuggo.

    Kicsit úgy érzem, hogy most már bármit leírsz, csak hogy rosszabbul nézzenek ki a GC-s nyelvek :) JVM-et ismerem igen jól. Azért van többféle GC, mert egyrészt fejlődtek a gépek, fejlődött az egész környezet, másrészt mert különböző teljesítményigényű programokhoz más típusú GC passzol jobban (throughput vs low-latency GC-k). A low-latency GC-kre kimondottan a nagy teljesítményű, alacsony késleltetésű rendszereknél merült fel igény. Tehát nem hogy az lenne az igaz, amit írtál, hanem annak az ellentéte: ezeknek az új GC algoritmusoknak az implementálása pont arra bizonyíték, hogy a JVM nagyonis megállja a helyét a C++-szal szemben a nagyteljesítményű rendszerek terén, és erre van piaci igény (nem is kicsi). 

    (*) Minden allokátor algoritmushoz létezik olyan allokációs minta, amit az adott algoritmus borzasztóan fregmentált heap-pel honorál.
    Mutasd a teljes hozzászólást!
  • Szia

     Nem tudok ilyen doksirol, csak magarol a tenyrol, hogy egy idoben mindent lecsereltek getterre, aztan vissza. Ugyanigy a C#-tol is probalnak megszabadulni az ill2cpp kereteben, most meg eppen a GC-tol. De mar a objecket is tul nagy overloadot jelentenek, ezert bevezettek a DOT-ot. Valamelyik  eloadason hallottam (Brightonban) egy fejlesztotol, hogy mar banjak, hogy nem C++-nal maradtak, de ugye ez egy performance orientalt felhasznalas, nem egy pedig egy smart home, vagy ECU.

    Igi
    Mutasd a teljes hozzászólást!
  • A Wikipedia szócikk szerint a runtime C++, a scripting API C#, ebből nekem nem volt egyértelmű hogy a C# kódból vették ki a gettereket.

    De mivel egy gyors Google kereséssel nem találtam doksit arról hogy gettereket tüntettek volna el, esetleg tudnál rá valami forrást adni?
    Mutasd a teljes hozzászólást!
  • Unit3D C#. A teszteken termeszetesen minden kibukik, amire irnak tesztet ;)
    Mutasd a teljes hozzászólást!
  • Unity3d-ben kiszedtek, pontosabban fuggvenyekbol valtozokat csinaltak, nyilvan a szandek ugyanaz.

    Ja, hogy most ugrottunk C++-ra. Ott nem tudom mennyire lehet triviális gettereket inline-olni. Azt tudom hogy alapból a headerbe kell tenni amit inline-olhatóvá szeretnél tenni, de az meg más fajta tradeoff-fal jár. És van még whole program optimization, ami mégis tudja inline-olni amit a hagyományos modell szerint nem lehet.

    Amugy a getter, es setter ellen rengeteg erv szol

    Kíváncsivá tettél, fel tudod őket sorolni? (Jó lesz link is, ha van) Valóban lehetővé teszik a végtelen rekurziót, vagy akár azt hogy valaki egy getterben leformázza valamelyik adattárolódat, de azért egy tesztelés során mind a kettő gyorsan ki fog bukni
    Mutasd a teljes hozzászólást!
  • GC-vel semmi bajom, sok helyen nagyon jo, de azt feltetelezni, hogy megoldja a problemaid, mar ha vannak, szerintem tulzas.

    Most gyorsan visszaolvastam a témát, de ilyet senki nem állított benne. Az NSA eredeti állítása (ami okán a cikk született) az, hogy az említett nyelvekben lévő kötelező ellenőrzések (pl. tömbindex-ellenőrzés, cast-ellenőrzés, null-ellenőrzés) megoldják a biztonsági jellegű problémáid egy jelentős részét. A teljesítmény-problémákról nem esett szó.

    Annyiban ér össze a két dolog, hogy a GC megakadályozza a memory leak, double free és use-after-free jellegű problémákat. Ezeket a problémákat viszont könnyű belátni, hogy tényleg megoldja, ez nem csak feltételezés.
    Mutasd a teljes hozzászólást!
  • Unity3d-ben kiszedtek, pontosabban fuggvenyekbol valtozokat csinaltak, nyilvan a szandek ugyanaz. Amugy a getter, es setter ellen rengeteg erv szol, lehet veluk csinalni szep loopkoat. En szeretem, ha valami az aminek latszik, de mondjuk ezzel MO-n biztos, hogy kisebbsegben vagyok ;)
    Mutasd a teljes hozzászólást!
  • Van ahol gettert, es settert sem hasznlanak

    Ha van ilyen, az szerintem inkább babona mint tényekkel alátámasztott döntés. (Vagy esetleg a teljesítménytől független indoka van.) A triviális gettert és settert semmibe nem kerül inline-olni, ezt simán meg fogja csinálni a JIT fordító amikor a bájtkódból natív kódot fordít. Plusz ezzel elvesztik a lehetőséget hogy később esetleg nem triviálisra tudják átírni azt a gettert és settert.
    Mutasd a teljes hozzászólást!
  • Alapvetoen a GPU-t nem kevernem ide, de amugy tud C++ kodot futtani, plane, hogy az egy nyelv, es nem kod. GC-vel semmi bajom, sok helyen nagyon jo, de azt feltetelezni, hogy megoldja a problemaid, mar ha vannak, szerintem tulzas. Nagyteljesitmenyu rendszereknel, mar terevzesnel is figyelembe vesszuk, hogy optimalizalod a TLB-t, vagy eppen huge paget haznalsz, milyen lesz az eloszlasa a cachenak (pl. CPU-k kozott, mar ha tamogat ilyet). Memoria busz allokaciok szinten pinnelve vannak. Ha van OP akkor nagyon nem mindegy, hogy van kiosztva a memoria, es CPU-k, a lenyeg, hogy ez itt egy nagyon hosszu felsorolas lenne, ami vegen siman nyersz 100%, vagy akar tobbet performanicaban, ahelyett, hogy azt mondjuk a GC az ugy is jo. Csak, hogy lassuk a GC mennyire nem jo, mind az MS, mind az Apple, vagy a JVM mar a sokadik generacios GC-nel tart, adott esetben teljesen szakitva a korabbi memoria modellel (Objectuive-C -> Swift), ha olyan jok lennenek, nyilvan nem kellene ennyit faragni rajta, persze eset fuggo. De, hogy emlitsek valami jot is,  egy egyszeru programozo valoszinu GC-vel jobb eredmeny kap JAVA-ban, mint C-ben GC nelkul, mert nagyon sok trukkot tud, pl. stackra pakol dolgokat heap helyett ha ugy latja jonak.
    Mutasd a teljes hozzászólást!
  • Azt hiszem kezdem nem érteni pontosan mivel is akarsz érvelni, és mi mellett. A TFLOPS nem tudom mennyire értelmes azokon a területeken, ahol van értelme összehasonlítani két általános programozási nyelv teljesítményét. Ahol tényleg a FLOPS a fontos, ott GPU-t fognak úgyis használni, ott meg igazán egyik se játszik, mert a GPU nem fog C++ kódot se futtatni. A CPU is tud persze lebegőpontos számításokat végezni, de nem erre van alapvetően kitalálva. IPS se túl hasznos egyébként, tekintve, hogy abba beleszámít a VM is.

    A realtime rendszerekben nem az eszközök válaszideje a fontos, hanem hogy tudod-e garantálni egy realtime prioritású feladat számára, hogy megkapja az időszeletét, amikor szüksége van rá. Ezt alapvetően egy GC agyonlőné, de egy deteminiszikus GC mellett ez tud működni. Ilyen szempontból van értelme GC-ről beszélni, meg hogy mennyi erőforrást vesz el a tényleges feladat elől, mekkora késleltetést képes belerakni a rendszerbe. De akik ilyen érvek mentén kritizálják a GC-t úgy általában, teljesen figyelmen kívül hagynak egy csomó mindent. Pl egy young ParallelGC (ami egy throughout GC algoritmus) a HotSpot JVM-ben bőven <10ms alatt végez. A scheduler viszont ennél simán képes nagyobb ideig pihentetni a szálat, én láttam bőven 10+ milliseces scheduler latencyt egyébként nem agyonloadolt gépen (igaz az nem globális, a safepoint pedig többnyire az). Egy low-latency (concurrent) GC, mint a ZGC mikromásodperces nagyságrendű akasztásokat okoznak, tüskék se látszanak a benchmarkokon, bár cserébe kell nekik több memória, és szabad CPU erőforrás, meg barriereket kell használjanak.

    Ha VB alatt ott a CLR, ami a tárgykódból hatékony natív kódot fog fordítani, akkor igen, meg lehet csinálni nagy teljesítményigényű feladatokat abban is, és az is tudni fogja azt a teljesítményt, mint a C#. JS, Python stb szintén. Mert ugyebár nem forráskód fut a gépen, hanem az a natív kód, amit a fordító fordít.
    Mutasd a teljes hozzászólást!
  • Megint attol fugg, hogy mennyi az annyi. Van ahol gettert, es settert sem hasznlanak, az itt vazolt peldakat meg tovabbra is ugy gondolom, hogy faszan meg lehet csinalni VB-ben. Mennyi is egy Pratt & Whitney JT9D reakcio ideje,  vagy egy ABS module ? Nagyjabol vegtelen egy korszeru xPU frekvenciajahoz kepest.
    Mutasd a teljes hozzászólást!
  • [Törölve]
    Mutasd a teljes hozzászólást!
  • Akkor most szerinted arra nem jó a GC ahol a válaszidő számít, vagy ahol a througput? Csak mert BlaZember már leírta, hogy ahol a válaszidő számít ott használhatsz determinisztikus GC-t. Ahol meg a throughput számít, ott akár nagyobb GC pause is belefér (már nem mintha a modern GC-k komolyan blokkolnák a szálakat, de ha blokkolnák se lenne gond). Ha a throughputot akarod maximalizálni, akkor azt kéne bizonyítanod hogy a GC overhead nagyobb, mint a kézi memóriakezelés overheadje. Mert ugye a malloc és a free sincsen ingyen, ők csak másfajta algoritmust implementálnak mint egy GC.
    Mutasd a teljes hozzászólást!
  • " De a valódi sebesség előnyük ezeknek a nyelveknek már néhány specifikus feladattól eltekintve olyan picire olvadt, vagy teljesen eltűnt, hogy csak emiatt már jellemzően nem választják őket."

    Pici barmi ami 10Tflops alatt van, ami nagyjabol egy bevezeto szintu desktop teljesitmenye. Ettol meg big data-t nem csak c++/rust-ban szamolnak az igaz, de megfigyelheto egy ilyen trend, plane, ahogy az energia egyre dragabb.

    Igi
    Mutasd a teljes hozzászólást!
  • A GC nelkuli Java az kb. olyan mint komplex obejktum strukturahoz memory safe programot irni C++-ban, lehet, de akkor nem a feladathoz valasztjuk a szerszamot.

    Már miért lenne ez így? A GC nélküliség csupán azt jelenti, hogy a program futása alatt nem volt szükség a GC futására, mert nem fogytak el alatta az erőforrások. A nyelv és környezet összes előnye attól még megmarad. Beleértve a memory safetyt is, amiről az ajánlás szól. Pont hogy a feladathoz választják.

    Amit te irsz idozitesek, ott egyreszt a GC nagyon be tud utni

    Meg kismillió más dolog a priority inversiontől kezdve az időzítőn át sokminden. Ahol ez nem megengedett, lásd az említett realtime garanciákat igénylő repülési és vezetéstámogató,  rendszerek pl, még ott is lehet GC-t használni, csak nem olyat, amit egy átlagos Java/C#/JS/Python stb program használ. Használnak is ilyeneket, determinisztikus GC algoritmusoknak hívják őket. 

    itt annyira pici szamolsrol beszelunk, hogy akar visual basicban is irhatnad.

    Nem tudom mi a pici számolás, meg a nagy számolás a te definíciód szerint. De egy C/C++-t, vagy most már Rust-ot nem a számítási képessége miatt érdemes választani egy C#, vagy Javaval szemben, mert azok is tudnak számolni igen hatékony natív kóddal, és a valódi programokban észre se fogod venni, hogy ezekben írták. Az előbbiek előnye ott jelentkezik, hogy egyrészt kisebb a memory footprintjük, másrészt a nyelvi elemek a programozás modelljét közelebb tartják a gépéhez, így alkalmasak low-level programozásra. De a valódi sebesség előnyük ezeknek a nyelveknek már néhány specifikus feladattól eltekintve olyan picire olvadt, vagy teljesen eltűnt, hogy csak emiatt már jellemzően nem választják őket.
    Mutasd a teljes hozzászólást!
  • Hello

       A GC nelkuli Java az kb. olyan mint komplex obejktum strukturahoz memory safe programot irni C++-ban, lehet, de akkor nem a feladathoz valasztjuk a szerszamot.
      Amit te irsz idozitesek, ott egyreszt a GC nagyon be tud utni, de itt annyira pici szamolsrol beszelunk, hogy akar visual basicban is irhatnad.

    Igi
    Mutasd a teljes hozzászólást!
  • Ez olyan, hogy ismerni kell a nyelv koncepcióját 'you do not pay for what you don't use' és a hardver működését..
    Megoldható C++-ban is a safe_pointer, kizárólagosan const és immutable objektumok használata, stb.. Igen.

    Az STL nem ennek a szellemében lett kitalálva és mindenhol ahol egy memóriafolytonos konténerbe tetszőleges konténer módosítások után bátran lehet referálni az elemeket, ott bizony 'varázslat' van a háttérben és nem HW szinten.
    Ugyanez a varázslat megoldható C++-ban is? Igen

    A nyelv valóban nem kényszeríti ránk, ezért nagyobb szabadságunk van hülyeséget csinálni, ez tény. Ez a sok évtizedes visszafelé kompatbilitás ára, viszont ez nem mentség arra, ha valaki helytelenül használja a nyelvet 2022-ben.
    Mutasd a teljes hozzászólást!
  • Akkor ha jól értem, a megfejtés az, hogy ahol sokat kell gyorsan számolni és folyamatosan új memóriát kell allokálni, ott használjunk Rustot hogy ne lőjük lábon magunkat. 

    Sőt, ha sokat kell allokálni, de gyorsan (GC frekveciához képest gyorsan) fel is lehet szabadítani (pici a live set), egy GC simán lehet, hogy nagyobb throughputot fog tudni biztosítani, mint egy malloc implementáció. A GC-nek nem csak azzal nincs dolga, amit nem allokáltak, de azzal sincs, amit allokáltak, de nincs már rá referencia. Persze ez GC algoritmustól függően igaz, de a compacting GC algoritmusok erre épülnek. Szemben egy akármilyen malloc implementációval, ami azért free listeket kell karban tartson, adott esetben splitelnie/mergelnie kell tudni blokkokat stb, ami közel sincs ingyen, csak jobban eloszlik időben, és emiatt kevésbé látványos költség. Amellett, hogy léteznek ráadásul konkurens GC algoritmusok, amik aztán tényleg minimálisan szólnak bele a számolásba (amíg nem 100%-on pörgeti a CPU-t az alkalmazás maga, és van memória is).
    Mutasd a teljes hozzászólást!
  • A szigorú SLA azt jelenti, hogy szigorú határok vannak egy feladat végrehajtási idejének percentiliseire. Az ismert tények pedig azt jelentik, hogy GC, objektumok, VM stb mellett is lehet ilyen SLA-kat tartani.

    Az autóiparban nem a nagy számítási teljesítmény a lényeg, hanem a hard realtime garanciák. De azért ott is kell számolgatni. Nem biztos, hogy örülnél egy lassan számoló menetstabilizátornak pl, amikor megcsúszik az autód a vizes úton. És ott azért másodpercenként párszor meg kell nézni mit csinál a 4 kerék...

    Az objektumnak, GC-nek meg pont nem ahhoz van köze, hogy mennyire fog gyorsan számolni a program. Sokkal inkább ahhoz, hogy a CPU időszeleteiből mennyit tud számolással tölteni, mert mennyi ideig fog futni a GC, milyen gyakran, mennyit kell reference chasinggel tölteni az objektumok miatt, mennyire lehet kontrollálni az adatok layoutját, amivel dolgozni kell vs mennyibe fáj a dinamikus memóriakezelés (nem biztos, hogy ezzel jobban jössz ki, mint a GC-vel) pl egy C programban stb. Ezeket figyelembe lehet venni egy GC-s OO program esetében is, és alá lehet dolgozni a processzornak. 

    Nekem volt szerencsém olyan Java programot írni, ahol pontosan 0 idő ment el nemhogy GC-re, de safepointokra is (warmup után). Ha nem adsz munkát a VM-nek, akkor nem fog dolgozni. 

    Ahol a fentiek nem elegendőek, arra meg ott a Rust.
    Mutasd a teljes hozzászólást!
  • Akkor ha jól értem, a megfejtés az, hogy ahol sokat kell gyorsan számolni és folyamatosan új memóriát kell allokálni, ott használjunk Rustot hogy ne lőjük lábon magunkat. Minden másra jó a GC-t használó környezet is. (Ha gyorsan kell számolni de újrahasznosítjuk ugyanazt a lefoglalt puffert vagy egyéb objektumot, akkor megint csak jó lehet a GC-s környezet, hiszen ha nincs memóriafoglalás akkor a GC-nek sincsen semmi dolga.)

    Vagy lehet ragaszkodni a C-hez annak minden hátrányával együtt.
    Mutasd a teljes hozzászólást!
  • A szigoru rendszer pont nem a GC mellozesere mutat. A nagy szamitasi teljesitmeny inakbb. Hol van az autoiparban nagy szamitas (AI-s vezetes tamogatast nem szamolva) ?
    Mutasd a teljes hozzászólást!
  • Elég komoly teljesítményigényű, és szigorú SLA-kkal rendelkező rendszerek használnak mind GC-t, mind objektumokat. Úgy amúgy beleértve akár realtime rendszereket is. Pl a Boeing a repülőkön csomó mindenre (realtime) Java-t használ, de az biztos, hogy használt. És ott azért nem feltétlenül olyan ráérős a dolog :) Autókban szintén. Pont a cikkben elmondottak miatt választják ezeket szemben a C-vel, C++-szal (már ahol így döntenek).
    Mutasd a teljes hozzászólást!
  • Szóval ha hulye vagy és nem tudsz vezetni, akkor bekötöd a biztonsági övet. :)
    Mutasd a teljes hozzászólást!
  • Rust valoban, igazad van. GC-t hasznalni nem baj, ha olyanok a korulmenyek, ahogy objektumot sem, ha raeros a dolog.
    Mutasd a teljes hozzászólást!
  • Szoval ha hulye vagy es nem tudsz programozni akkor ugrasz valami ujabb hype nyelvbe. :)

    50 évvel ezelőtt valószínűleg ugyanezt mondták a C-re.
    Szerintem 20 év múlva ezt fogják mondani a Rust utódjára.
    Mutasd a teljes hozzászólást!
  • Mindig a memóriabiztonsággal jönnek...

    Mindeközben a CVE-k 70%-a ezzel kapcsolatos. Kíváncsi lennék, hogy ezek fixálására mennyi pénz megy el, és hogy megéri-e úgy fenntartani a C/C++-t, hogy gyakorlatilag nem éri meg köztük a sebesség miatt választani.
    Mutasd a teljes hozzászólást!
  • C++ esetében nem nehéz new/delete helyett smart pointereket használni memóriakezelésre, de ilyen hibákat már jóval nehezebb észrevenni:

    std::vector<std::string> v{"foo"}; auto& a = v.front(); v.emplace_back("bar"); // use 'a' // vagy std::map<int, std::string> map{{0, "foo"}, {1, "bar"}}; for(const std::pair<int, std::string>& p : map) { // ... }
    Esetleg valaki úgy gondolja, hogy az unordered_map interfésze ugyan az, mint a map-nek, mit árthat kicserélni
    Mutasd a teljes hozzászólást!
  • Ahogy egy bölcs ember mondta:
    "Nothing is better than C."
    Ez az ember történetesen Linus Torvalds és szerintem ehhez neki is lenne pár szava.
    És én előbb hiszek egy olyan embernek akinek 30 év kemény low-level programozási tapasztalata van, mint aki pár éve "bohóckodik" valamit valamelyik felkapott nyelvben.

    Ennek a 30 éve low-level bölcs embernek volt hozzá pár szava: hozzájárult, hogy a Linux kernel egy részét Rustban írják (és megelőlegezem, hogy idővel ez a kis rész nem kis rész lesz). Egyébként mellesleg pont olyan szubjektív véleménye van, mint neked, vagy nekem.

    nem cserélhető ki teljes egészében a C a Rust-al

    Hosszabb távon miért nem?
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd