C helyett Rust-ban fejleszthetik tovább a Linux kernelt
2020-07-14T14:31:17+02:00
2020-07-27T10:46:41+02:00
2022-07-20T14:11:50+02:00
  • A linuxot lehetségesen egyáltalán nem kell újraírni. Eléggé darabokból van ahhoz, hogy darabokban javítgatni lehessen. És ha ahhoz kellene több ember, akkor egy dokumentációs project kellene inkább a jelenlegi kernelnek, mert már annyira fényévekre van a 2.x-es időktől, hogy az összes releváns dokumentáció "nézd meg a forrást" (kotorászhatsz a millió soros áradatban, aminek a miértjeiről sehol egy árva szó sincs).

    Apropó az igazi kulimász bőven 2007 után érkezett a linuxra. Az a levél már alaposan régi. Mostanra Linusnak sok egyéb másról is kiábrándult véleménye van
    Mutasd a teljes hozzászólást!
  • Évek óta módszeresen cserélgették le a komponenseket, többféle okból (licensz, bloat, bonyolultság). Nem találom a referenciát, de többször előjött a C++ bonyolultsága és a fordítás lassúsága, szóval ez egy hosszú folyamat része.
    Mutasd a teljes hozzászólást!
  • project kiemelten figyeal a kódminőségre és hordozhatóságra, szintén szabadult a C++-tól


    Kicsit utána olvastam. Ez számukra teljesen logikus döntés volt. A 'groff' tool, amit lecseréltek egy 30 éve hegesztett nagyon komplex szoftver. Sok helyen tele legacy gányolt megoldásokkal, stb..
    Lecserélték egy modernebb, fiatalabb, célirányos tool-ra 'mandoc'-ra, ami jóval egyszerűbb, kisebb (kevesebbet is tud) mint a 'groff'.
    A tool lecserélése által elérték azt is, hogy az egész forrásuk egy nyelvű (pure C only), aminek megvannak a maga előnyei.

    Kódminőség, vagy biztonság szempontjából 2020-ban nem biztos (véleményem szerint biztos hogy nem), hogy a C a legmegfelelőbb nyelv egy ilyen tool implementálására, de ez már más téma.
    Mutasd a teljes hozzászólást!
  • Az OpenBSD project kiemelten figyeal a kódminőségre és hordozhatóságra, szintén szabadult a C++-tól: groff deleted from tree
    Mutasd a teljes hozzászólást!
  • Z=r30*256+r31

    Rust esetén amire oda kell figyelned, ha gyors kódot akarsz, hogy futásidőben kell-e ellenőrizni a vektor elégséges hosszát, vagy fordításkor ez megtehető?

    Lásd: Compiler Explorer
    Mutasd a teljes hozzászólást!
  • Elég markáns vélemény, vitaindítónak jó. Mondjuk a 1992-es C++-os tapasztalatai alapján nem biztos hogy érdemes messzemenő következtetést levonni 2007-ben, főleg nem 2020-ban..

    Az absztrakció zero overhead-el véleményem szerint hasznos, C-ben ugyanúgy lehet hibás kódot írni, mint bármilyen nyelven, a nyelvi elemek korlátozása egy projektben egyáltalán nem rossz dolog és teszi értelmetlenné magának a nyelvnek a használatát.. De ez is csak egy vélemény, pont mint az övé :)
    Mutasd a teljes hozzászólást!
  • Linus-nak megvolt a véleménye arról, hogy a C++ nyelvet beengedje-e a Linux kernelbe: Linus Torvalds on C++
    A Rust ellen nincs kifogása.
    Mutasd a teljes hozzászólást!
  • Másfajta humort kedvelek (Monty PythonDouglas Adams, stb.). 

    Szerintem amugy Woody Allen humora (amig volt neki) nem all ezektol annyira tavol.
    Mutasd a teljes hozzászólást!
  • Hali!

    Hát ha neked a humor "szegényes szórakozás"…

    Nem tudom, hogy ezt miből vontad le – habár, ha a „szórakozásodat” tekintjük…

    … nem ajánlom neked sem az "Airplane!" című filmet, sem Woody Allen novelláit.

    Ne is (az Airplane-t különösen)! Másfajta humort kedvelek (Monty Python, Douglas Adams, stb.).

    Mutasd a teljes hozzászólást!
  • Hát ha neked a humor "szegényes szórakozás", akkor nem ajánlom neked sem az "Airplane!" című filmet, sem Woody Allen novelláit.
    Mutasd a teljes hozzászólást!
  • // így rövidebb template<typename T> using optref = std::optional<std::reference_wrapper<T>>; optref<some_large_type> find_by_name... // így mégrövidebb boost::optional<some_large_type&> find_by_name... if(auto a = find_by_name("foo")) a->bar();
    Mutasd a teljes hozzászólást!
  • a) unsafe nélkül kézzel rakjuk össze az értéküket (kb. Z=r30*256+r31). Ennek van egy kicsi overheadje a számolgatás miatt.

    Majdnem biztos lehetsz benne, hogy ez a helyes megoldás. Ahogy egy kortárs C/C++ fordító már abszolút nem szolgaian fordítja a kódodat, a Rust is ebbe az irányba halad. Sőt, pont a szigorú memória/élettartam-menedzsment kapcsán lehet, hogy már túl is haladta kódanalízisben a C/C++ vonalat. És közben a processzor sem azt a programot futtatja, ami a memóriában van, hanem annak egy átfogalmazott változatát.
    Nem érdemes assembly kódot írni natívra forduló magas szintű nyelven, mert rossz esetben még lassabb is lesz az eredmény, mint amit egy modern fordító készítene magától.
    Mutasd a teljes hozzászólást!
  • Egyébként van arról egy lista, hogy mely programozási nyelvek fordítóprogramjai azok, amelyeknek az új verziója az ugyanazon fordító előző verziójával fordítják?

    A tulajdonságot "self-hosting"-nak hívják, de vicces módon a Wikipédián nem a vonatkozó szócikk (Self-hosting (compilers) - Wikipedia ), hanem egy kapcsolódó tartalmaz ilyen listát: Bootstrapping (compilers) - Wikipedia
    Arra nyilván nem érdemes számítani, hogy a lista tényleg teljes legyen, de a kb. 40 nyelv már mutatja, hogy ez nem ritkaság. Illetve az is látható, hogy ez nem-natív nyelveknél is működhet, lásd a .NET-es és JVM-es nyelveket, de persze más köztes kódú nyelv is van a listában.
    Mutasd a teljes hozzászólást!
  • Hali!

    … jól szórakoztam

    Eléggé „szegényes” módon.

    Mutasd a teljes hozzászólást!
  • Nem történt energiabefektetés, jól szórakoztam
    Mutasd a teljes hozzászólást!
  • A típusdefiníció hátradobásának egyetlen logikus okát ismerem, ez pedig az, hogy jobban átlátható a kód, ha a változónév/függvénynév a sor elejére kerül és nem tűnik el a sor közepén (bár ebben egy jó syntax highlighting sokat segíthet).
    Mutasd a teljes hozzászólást!
  • Végül ezt a projektet nem csináltam végig a Rust-tal, de ennek ellenére megtetszett. Tény, hogy van learning curve-je, de érdemes vele ismerkedni. Ezek ellenére azért megkedveltem, szerintem még elő fog kerülni nálam .

    Igazából csak türelmetlen voltam, és hamarabb akartam belőle látni valami eredményt. Lehet érdemes lett volna végigcsinálni Rustban.

    Pointerezést még C++17/20-as környezetben sem lehet mindig elkerülni.
    Botlottam bele olyanba, hogy kellett egy "keresőfüggvény", de nem akartam kivételkezelést használni:

    struct some_large_type { ... }; // 1) - kivételt dob ha nem talál semmit some_large_type& find_by_name(const std::string& name_); // 2) - nem jó, mert másol std::optional<some_large_type> find_by_name(const std::string& name_); if(auto opt_obj = find_by_name("foo"); opt_obj.has_value()) { opt_obj->do_some_work(); }
    Szóval nem biztos, hogy bármilyen sztringre vissza lehet adni valami objektumot ezért is az optional, viszont ennek van egy olyan hátránya, hogy az "opcionális típust" értékként tárolja el magában az optional, tehát annak másholhatónak is kell lennie, ami nem biztos, hogy szerencsés.

    Ezután próbálkozni lehet reference_wrapperrel meg esetleg iterátorral, de egyikkel sem lesz igazán szebb és könnyebben használható:

    // 3) túl hosszú std::optional<std::reference_wrapper<some_large_type>> find_by_name(const std::string& name_) ... obj->get().do_some_work(); // '-_- // 4) és a jó öreg pointer... some_large_type* find_by_name(const std::string& name_); if(auto ptr = find_by_name("foo"); ptr) { ptr->do_some_work(); }
    És ez az ami ezek közül a legegyszerűbb, nem másol feleslegesen, nem kell 2 indirekciós rétegen keresztülvágni mint a reference_wrapper+optional kombinációnál, és a függvény szignatúrája sem bonyolult.
    Mutasd a teljes hozzászólást!
  • Könnyebben parsolható: no de a mai processzorok mellett ez kit érdekel?

    A gép "érdekei" nem érdekelnek, a forráskód emberi ergonómia szempontjai az egyetlenek, amik fontosak.
    Mutasd a teljes hozzászólást!
  • Vajon mozaikszó vagy csak egy kezdetek-kezdetén a toldozgatott "rozsdás" ráragadása lehet a háttérben?

    Egy gomba neve. Ma is tanultam valamit...

    Forrás: r/rust - Internet archaeology: the definitive, end-all source for why Rust is named "Rust"

    TL;DR: Rust is named after a fungus that is robust, distributed, and parallel. And, Graydon is a biology nerd.
    Mutasd a teljes hozzászólást!
  • Hát azt mondanám, hogy meg lehet, de most megnéztem meg azt a kódot amit írtam és hát volt benne pár unsafe blokk:

    Ott használtam unsafe-et amikor olyan parancsokkal foglalkoztam amik 16bites index-regisztereket használnak (X, Y és Z). Ezek nem igazi regiszterek, hanem valójában regiszter párosokat jelölnek, például a 'Z' az a r30:r31-es párost amik egy byte-osak, az AVR programok pedig szoktak olyat csinálni, hogy byte-onként beállítják ezeket, és utánna hívnak például egy "ST Z+, r1"-et aminek egyben kell látnia azt a 2x8bitet, hogy 16bites címként tudja értelmezni. És itt két lehetőség van:

    a) unsafe nélkül kézzel rakjuk össze az értéküket (kb. Z=r30*256+r31). Ennek van egy kicsi overheadje a számolgatás miatt.

    b) mivel az r0-r31-es regiszterek is a munkamemóriában helyezkednek el (a 0x00-0x1f címen) ezért meg lehet csinálni, hogy a "&memory[30]"-at ami "uint8*" tipusú átcastoljuk uint16*-ra, így nem kell számolgatni és egyből megvan a kívánt érték (de ezt amiatt tudtam megcsinálni mert az x86-os is és az AVR is little-endian-ok, máskülönben ez nem ment volna).

    Máshol pedig ott kellett amikor például egy u8-as memóriablokkban lévő értékből kellett i8-at varázsolni, mert az adott opcode-nak éppen az kellett (pl.: "brne" relatív címzést használ akár negatív offsettel), ott is volt unsafe:

    // brne .<OFFSET> if opcode & 0xfc07 == 0xf401 { let k = (opcode >> 3 & 0x7f | 0x80) as u8; let sk = unsafe { std::mem::transmute::<u8, i8>(k) } as i16 * 2; println!("brne .{}", sk);


    Deee, ezt is meg lehet csinálni végül is unsafe nélkül, csak hát ugye megint "kézzel" kell számolgatni, aminek van valamekkora ára.
    Mutasd a teljes hozzászólást!
  • Igen, ez a lényeg, a "kódgyártás" része gyorsabban lement ugyan, de cserébe többet kellett utána foltozgatni.
    Mutasd a teljes hozzászólást!
  • Ekkora energiabefektetéssel akár meg is nézhetted volna, hogy honnan a Rust név :)
    Mutasd a teljes hozzászólást!
  • Az OCaml az még valamikor a "történelem homályában" a 0.1-es Rust idején játszott. Ahogy beindult a fordító, abban a pillanatban már Rust fordítóval fordítják az új Rust fordítót. Szóval az OCaml még bő évtizede a kezdetek kezdetén játszott.

    Ugye megkérdezhetnénk ennyi erővel, hogy az első C fordítót mivel fordították? A következőt már C fordítóval.

    Egyébként van arról egy lista, hogy mely programozási nyelvek fordítóprogramjai azok, amelyeknek az új verziója az ugyanazon fordító előző verziójával fordítják?

    A névadás érdekes lehet. Vajon mozaikszó vagy csak egy kezdetek-kezdetén a toldozgatott "rozsdás" ráragadása lehet a háttérben?

    A Mozilla tény hogy nagyon tolja. Itt van, hogy mely Firefox verzióhoz melyik a minimális Rust verzió, amivel biztosan lefordítható: Rust Update Policy for Firefox - MozillaWiki
    Mutasd a teljes hozzászólást!
  • Ja mint a klasszik kódban lévő komment egy klasszik gányoló mestertől akivel régebben együtt dolgoztam:
    "Bocs xxxx (ahol xxxx a vezető fejlesztő volt)" - és jött kb 20 darab friend class.
    Mutasd a teljes hozzászólást!
  • Bámulatos! Nem tudom milyen az az OCaml, de el tudom képzelni. Már csak azt kellene tudni, hogy miben írták az OCaml-t? Nyilván C-ben...

    És már csak arra kellene választ találni, hogyan tudott egy nyelv kitalálója ilyen elfaragott (itt egy más szó állna, de azt nem írhatom le) nevet adni a nyelvnek, mint "Rozsda". Az amerikai haditengerészet sem ad a repülőgép hordozóinak olyan nevet, hogy "USS Horpadt Lukas Mézesköcsög". Bár mondjuk a legutóbbi Ubuntu a "Focal Fossa" nevet viseli, ami nyilvánvalóvá teszi, hogy magyar fejlesztője sincs, vagy ha volt, betegre röhögte magát, és hazaküldték.

    De őszintén, Usain Bolt-on nem csodálkozom (Olympia Lightning Bolt a lánya neve), de egy programnyelv alkotótól azért többet vártam volna, felüt egy Quenya, vagy egy Sindarin szótárat, aztán rábök egy névre.
    Mutasd a teljes hozzászólást!
  • Egyébként ilyen téma a változó is hátravetett opcionális típussal is.

    let a: i32 = 4;
    let b = 6;

    A let helyett C-ben

    int a = 4;
    auto b = 6; // mai C++

    sajat c; // strutúra typedef-fel
    struct valami = d;

    Ez utóbbiak (saját típusok) így kevésbé észlelhetőek. Rust esetén minden

    let  .... // változókra
    fn  ....  // függvényekre
    pub fn
    pub <láthatóság> fn      // Lásd: Visibility and Privacy - The Rust Reference

    Visszatérő érték  függvényt leíró sor végén egész összetett is lehet a C egyparaméteresével ellentétben. Hiszen a Rust akár egy sokváltozós tuple-val is visszatérhet: Multiple return values, in Rust

    Végülis szerintem átláthatóbb. Tény, hogy elsőre szokni kell.
    Mutasd a teljes hozzászólást!
  • Pl azért, mert a void-ot nem kell kiírni (ha nincsen -> típus megadva, akkor az voidnak minősül)
    Mutasd a teljes hozzászólást!
  • C++ terén nekem főleg olyasmikkal van bajom, hogy a C örökségére épít és nincs a fordítónak egy bekapcsolható "strict" módja, aholis például a C++ -féle vektor mellett kimondottan tiltja a malloc-os, pointeres alágányolást. Sok kódban az látszik, hogy elkezdi szépen a fejlesztője, majd ha éppen nem megy, akkor alágányol. És még sorolhatnám a nyelvi védelem történelmi elemekkel való kijátszhatóságait.

    Rust esetén unsafe { ... } mondhatjuk elsőre, de valójában az unsafe-témának külön kézikönyve van, mert nem adja könnyebben magát a gányolás a normális kódírással összevetve.
    Az biztos, hogy amíg nem kapcsolod ki a kontrollt, addig nehéz alacsony szinten rejtett hibával rendelkező kódot írni. Így már csak az algoritmus helyes leprogramozására kell odafigyelned.

    IWolf88: hol aladtál el a Rust-ban írt emulátoroddal? Mi okozott nehézséget?
    Mutasd a teljes hozzászólást!
  • Amugy egy ilyesmi feladat megoldhato jelenleg Rust-ban unsafe blokkok hasznalata nelkul?
    Mutasd a teljes hozzászólást!
  • A Rust mögött tuti nagyobb a hype.
    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