Rust - hype vagy egyes területeken megoldás?
2020-08-27T06:11:04+02:00
2020-09-01T00:54:52+02:00
2022-07-20T13:46:46+02:00
  • Esetleg tudja valaki, hogy melyik kernelverziótól lesz hivatalosan Rust interfész a Linux kernelhez?

    Vannak még nyitott kérdések. Pont ma volt egy erről szóló miniconf:
    Supporting Linux kernel development in Rust [LWN.net]
    Mutasd a teljes hozzászólást!
  • Persze, csak míg ez C/C++ esetén teljesen logikus, az alapelvek része, addig a figyelmettlen C# programozó (vagyis nem profi) számára csak annyi ragadt meg, hogy "a GC majd magától megoldja",... de nem fogja :)
    [ezért a mániám, hogy nem csak a hogyant kellene tanítani, hanem a miértet is, hogy értse is a tanonc mi történik]

    Mindensetre hiányolom a C#-tól (C++ beidegződésekkel), hogy megpróbálja egzaktabbul követni a destruktor futtatás igényét. Mert hogy jelenleg semmi köze a hatáskörökhöz-láthatósághoz hanem csakis a GC felszabadításhoz kapcsolódik ez komoly fék, mégha bevezették is az IDisposable-t, akkor is, hiszen abban semmi automatizmus nincs, teljesen kézzel kezelt (mégha syntax sugar segít is a using képében. (Ezzel párhuzamosan az IDisposable kezelésébe a fordítót is bevonni, hogy ha megvalósított, akkor a destruktor (vagy default destruktor) automatikusan meghívja azt (még akár a dupla hívásra is figyelve).
    Mutasd a teljes hozzászólást!
  • Kicsit is profikat nem zavarja:ha feliratkozol valamire, akkor iratkozz is le róla.

    A manuális mem kezelés is ilyen. Amit egyszer lefoglaltál azt szabadítsd is fel. Csak a kicsit is profik ezen már rég túlléptek még C++ alatt is.
    Mutasd a teljes hozzászólást!
  • A Rust ezeket az OS-eket támogatja x86_64 platformon + wasm platfomokat:

    $ rustup target list | egrep 'wasm|x86_64'
    wasm32-unknown-emscripten
    wasm32-unknown-unknown
    wasm32-wasi
    x86_64-apple-darwin
    x86_64-apple-ios
    x86_64-fortanix-unknown-sgx
    x86_64-fuchsia
    x86_64-linux-android
    x86_64-pc-windows-gnu
    x86_64-pc-windows-msvc
    x86_64-rumprun-netbsd
    x86_64-sun-solaris
    x86_64-unknown-freebsd
    x86_64-unknown-illumos
    x86_64-unknown-linux-gnu
    x86_64-unknown-linux-gnux32
    x86_64-unknown-linux-musl
    x86_64-unknown-netbsd
    x86_64-unknown-redox

    Továbbá kisebb eszközökben valami RTOS klón (pl. tockos) feletti programozás és a nagyon kicsi feladatokra bare metal programming játszik még.
    Mutasd a teljes hozzászólást!
  • Mobilon ugye volt egy csomó az android előtt

    Én a mai helyzetről beszélek. Ma mobilon van a BSD alapú IOS és a linux alapú droid.

    De ezen kívül vannak még routerek, okoseszközök, tévék, meg ezer egyéb eszköz, ahol kimondottan rossz választás lehet egy windows, vagy macos.

    Ezek nagy részén általában linux van. Talán az okosórák az a piac ami még viszonylag el van terjedve, és van egy nagy rétegük amiken custom OS van (olcsó kínai "okosórák").
    Mutasd a teljes hozzászólást!
  • Értsd alacsony szintű nyelven megírt.

    És akkor te a C-t ide sorolod, de a C++-t és a Rustot nem?

    Ahogy én nézem a programnyelvek fejlődését, nekem úgy tűnik, hogy kifejezőerőben egyre csökkennek a különbségek.

    nemigen várom hogy túl sok új mainstream adatbázisszerver, kernel, 3D motor, stb. tör be már a piacra. 

    Ugye mit értünk betörés alatt. Szerintem továbbra is készülni fognak újak, és ha egy termék valamilyen területen fel tud mutatni valami újat, az megtalálja a piaci szegmensét.

    A lecserélés persze más kérdés, szerintem minél régebb óta fut egy rendszer komoly hiba nélkül, annál kockázatosabb hozzányúlni.

    Mainstream max. három,

    Hát desktopon. Mobilon ugye volt egy csomó az android előtt, illetve az android kernel sem teljesen egyenlő a desktopos linuxokéival. De ezen kívül vannak még routerek, okoseszközök, tévék, meg ezer egyéb eszköz, ahol kimondottan rossz választás lehet egy windows, vagy macos.
    Mutasd a teljes hozzászólást!
  • Hát ha valahol feliratkozott, ott lesz rá egy hivatkozás. Innentől szerintem ugyanaz a helyzet.

    Hogy C#-ban ennek picit más a szintaxisa, azt szerintem a C#-osoknak illik tudni.
    Mutasd a teljes hozzászólást!
  • Kicsit többtényezős dolog ez, semmint hogy ezt így ki lehetne jelenteni. Csomó olyan eszköz van ezen a területen, ami mostanában kezdett népszerű lenni, és 5-10 éve még sehol nem volt. Cockroach, Yugabyte, Influx, Aerospike, Scylla stb. És egyáltalán nem csak cloudban van értelme. És akkor ismét leírom, hogy az új hardware technológiák új belső architektúrát kívánnak, amikre az alapokról épített rendszereknek nagyobb esélye lesz jó választ adni. NVMe, persistent memory, egyre több core stb...

    És a topic szempontjából a DB is csak egy pici szelete a lehetséges alkalmazási területeknek.
    Mutasd a teljes hozzászólást!
  • NoSQL-es területen talán. Bár ott is egyre inkább le van osztva a piac, ráadásul  ez leginkább a felhőszolgáltatók játéktere (Firebase, Cosmos). On-premise kevésbé van ennek értelme.
    Mutasd a teljes hozzászólást!
  • Az a gond, hogy ha elengedsz egy objektumot (pl. az általad használt egyetlen referencia változód nullázod és ezzel gondolatban végeztél is vele), ami feliratkozott valakinél valamilyen eseményre, de nem iratkozott le róla, akkor csak a te gondolatodban szabadul fel az objektum, a valóságban maradt rá hivatkozás.

    Ezt egy kicsit azért konkretizálni kell szerintem.
    Ha az osztály házon belül le tudja játszani, akkor ott nem marad hivatkozás. (mondjuk ezt most azért ki kéne próbálnom, de szerintem a szemétgyűjtő ezt lerendezi - nekem ez logikusnak tűnik)
    A gond akkor kezdődik, ha injektálva lett egy osztály és annak valami eseményére iratkoztak fel, és az injektált osztály továbbra is él.

    Kicsit is profikat nem zavarja:ha feliratkozol valamire, akkor iratkozz is le róla.

    biza. Sőt félprofik (najó kezdők) minden feliratkozást elött leiratkoznak. :)
    Mutasd a teljes hozzászólást!
  • De milyen forrásra vezetné vissza az IDE? Az allokálás forrása lényegtelen. Az a lényeg, hogy milyen nem törölt referencia van. Azt meg nem tudná megmondani úgyse, hogy hol kellett volna törölni egy referenciát.

    Heap dumpot gondolom .NET esetében is bármikor tudsz készíteni, abból meg le kell tudnod kérdezni az aktuális élő objektumokat és a rájuk hivatkozó referenciákat is. Illetve a gond jellemzően az, hogy ezek a problémák prodban állnak elő ilyen-olyan csillagegyüttállás esetén, nem fejlesztés közben.
    Mutasd a teljes hozzászólást!
  • egy aktív eseménykezelőt nyilván nem lehet felszabadítani. Én ebben nem látok hibát.

    A probléma nem az aktív eseménykezelőkkel van :)

    Az a gond, hogy ha elengedsz egy objektumot (pl. az általad használt egyetlen referencia változód nullázod és ezzel gondolatban végeztél is vele), ami feliratkozott valakinél valamilyen eseményre, de nem iratkozott le róla, akkor csak a te gondolatodban szabadul fel az objektum, a valóságban maradt rá hivatkozás.

    Kicsit is profikat nem zavarja:ha feliratkozol valamire, akkor iratkozz is le róla.
    Ezért (is) találták ki a using/ IDisposable okosságot.
    Mutasd a teljes hozzászólást!
  • Annyi lenne az "okosság" ha a programból kilépéskor (pl. debughoz kötve) csinálna egy "végső felszabadítást" és a még így is megmaradt foglalásokról naplót készítene (amit pl. az IDE csodásan forrásra is visszavezetne).
    Mutasd a teljes hozzászólást!
  •  Pl trading rendszerekhez is használják már a C++ helyett

    Jut eszembe, mikrovezérlőkre is jó.
    Mutasd a teljes hozzászólást!
  • Őszintén szólva én nemigen várom hogy túl sok új mainstream adatbázisszerver, kernel, 3D motor, stb. tör be már a piacra.

    Az adatbázis piacon pedig elég komoly változások vannak. A mai igények, és technológiák közül sok olyan, amikre nincs, vagy nincs elég jó válasza a klasszikus RDBMS-eknek. Elosztott, AP/CP, skálázódó, fault-tolerant, in-memory, non-volatile memory stb. Ezek egy részére már van nem RDBMS, de nagyon változik a hardware is, és pl az új NVMe, PMEM eszközök más belső architektúrát kívánnak, mint a sok esetben disk alapokra tervezett régi RDBMS-ek. Születnek a specializált megoldások, és sok új DB jön ki, amikből lesznek jelentősek is. Én nem lennék olyan nagyon meglepve, ha a most épp fejlesztés alatt állók közül pár Rustban lenne írva. Illetve ha a friss, Rustban írt DB projectek egy része beérne mainstreamnek: Database implementations — list of Rust libraries/crates // Lib.rs
    Mutasd a teljes hozzászólást!
  • Én ezt olyan nagyon értelmezni sem tudom. Komplex alacsony szintű progi?

    Értsd alacsony szintű nyelven megírt. Lásd linux kernel, postgresql, stb. Őszintén szólva én nemigen várom hogy túl sok új mainstream adatbázisszerver, kernel, 3D motor, stb. tör be már a piacra. Ráadásul ami igen, az sem feltétlenül alacsony szintű programnyelvben lesz megírva.

    Kernelből sem kettő van

    Mainstream max. három, legalábbis ha az Apple által használt BSD-t is beleszámolod. Jó, persze minden Pistike azzal kezdi a pályafutását az assembly alapok megtanulása után, hogy kernelt ír, de ezek leginkább csak az osnews.com-ig jutnak, de odáig is csak elvétve. Még az eredetileg kimondottan ledvillogtatásra szánt Rabsberry-k is linux kernellel mennek.
    Mutasd a teljes hozzászólást!
  • Milyen előnye van Rust esetén alkalmazott GC-t mellőző automatikus memóriafelszabadításnak, illetve milyen hátránya?

    Már mihez képest? A manuális memóriamenedzsmenthez képest előnye, hogy nem kell a programozónak az allokációval és a felszabadítással foglalkoznia (illetve hogy egyértelmű az ownership), és egy elfelejtett felszabadítás nem jár leakkel, nincs dangling pointer. Ez ugyanaz, mint a GC esetében.

    A GC-hez képest előnye, hogy futásidőben nem jelent overheadet, mert a fordító a lifetime ismeretében el tudja helyezni a felszabadítást végző kódot, és nem kell az objektumgráf (live részének) bejárásával, vagy referenciaszámlálással megvizsgálja, hogy mit lehet felszabadítani. Illetve a felszabadítás nem jár másolással, mint ahogy a GC algoritmusoknál tipikusan azzal jár (evacuation, compacting). Ezért alkalmas rendszerprogramozási nyelvnek, mert a GC-vel szemben ugyanazokat az időbeliségi garanciákat adja, mint a manuális memóriamenedzsment. Ez nem feltétlenül jelenti azt, hogy kevesebb időt tölt memóriakezeléssel, mint egy GC-t használó app, viszont ahhoz képest ennek költsége fix. Szintén könnyen jár nagyobb töredezettséggel, mint egy GC heap. Vagyis a GC-vel összehasonlítva ugyanazok az előnyei és hátrányai, mint a manuális memóriamenedzsmentnek.

    Mindkettőhöz képest előnye viszont, hogy fordítási időben kizárja a data race-eket, és egyéb tipikus memóriakezeléssel kapcsolatos hibákat. Ezek nagyon erős fordítási idejű garanciák. Viszont nagyon a rendszerprogramozási képességein keresztül vizsgálja mindenki a nyelvet ebben a szálban, holott nem kizárólag rendszerprogramozásra szánt nyelv, csak arra is jó. Ráadásul azon keresztül várni a halálát, vagy felemelkedését, hogy a Linux, vagy a Windows kernel fejlesztése mennyire aktívan fog támaszkodni rá, eléggé pointless szerintem. Rendszerprogramozás != kernel fejlesztés. És sok egyéb területen kibontakozhat még. Pl trading rendszerekhez is használják már a C++ helyett. 

    Mely programozási nyelvek rendelkeznek GC nélküli automatikus memóriafelszabadítással?

    Tudomásom szerint ez az ownership alapú megközelítéssel járó felszabadítás a Rust vívmánya, és jelenleg más nyelv ezt nem alkalmazza. Fontos szerintem azt is látni, hogy a Rust, mint nyelv gyakorlatilag az ownership/lifetime koncepció köré van szervezve, vagyis a memóriakezelés és az azzal kapcsolatos összes megfontolás nyelvi szintre van benne emelve, nem pedig a runtime-ra van tolva. Ez szöges ellentétben áll a C/C++, Java, C# stb mainstream nyelvekkel, amik inkább a nyelvi szerkezetekre fókuszálnak, és a runtime-ra bízzák ezeket a feladatokat. Ezért szerintem a Rust egy nagyon érdekes alternatíva. Hogy mennyire fog elterjedni, majd meglátjuk. Az én tippem az, hogy nagyon. Ha esetleg nem is Rust nyelvként marad itt velünk, de a memóriakezelési koncepciója biztos vagyok benne, hogy sokkal nagyobb teret fog kapni, és más jövőben megalkotott nyelvek azt át fogják venni tőle.
    Mutasd a teljes hozzászólást!
  • a legtöbb igazán komplex alacsony szintű progit már megírták

    Én ezt olyan nagyon értelmezni sem tudom. Komplex alacsony szintű progi?

    Kernelből sem kettő van, (Comparison of operating system kernels - Wikipedia, sőt: Comparison of operating systems - Wikipedia), és szerintem minden évben készülnek újak különböző nyelveken. Böngészőből meg pláne rengeteg van.
    Más kérdés, hogy ezek mennyire terjednek el. 

    Abban egyetértek egyébként, hogy számtalan olyan gyakran használt könyvtár van, amiket nem nagyon szoktak újraírni (zlib, iconv, curl, xml, png). Azt hiszem, ezeknél nagy bukkanót okozna mind a fejlesztésben, mind a felhasználásban, ha hirtelen rust-ból, vagy más nyelvből kellene őket fordítani. Különösen, ha a más nyelv az egyes könyvtáraknál eltérő lenne.

    Ennek ellenére én látom értelmét, pl. épp az ilyen memóriahibák miatt. Gyakorlatban azt tudom elképzelni, hogy egy rust környezetben szépen lassan megjelennek az ilyen nem túl nagy könyvtárak rust-os alternatívái is.
    Mutasd a teljes hozzászólást!
  • Ha erre a példára gondolunk:

    5 Techniques to avoid Memory Leaks by Events in C# .NET you should know - Michael's Coding Spot

    , akkor egy aktív eseménykezelőt nyilván nem lehet felszabadítani. Én ebben nem látok hibát.
    Mutasd a teljes hozzászólást!
  • Milyen előnye van Rust esetén alkalmazott GC-t mellőző automatikus memóriafelszabadításnak, illetve milyen hátránya?

    Mely programozási nyelvek rendelkeznek GC nélküli automatikus memóriafelszabadítással?
    Mutasd a teljes hozzászólást!
  • A linux kernel is többé-kevésbé készen van. És kb. 28 millió sorból áll. Ráadásul messze nem nő már olyan gyorsan mint régen. Őszintén szólva, picit kétlem hogy ennek a 28 millió sornak túl nagy része lenne Rust-ban a következő pár évben.
    Mutasd a teljes hozzászólást!
  • Egy normálisabb gc meg tudná mondani, ha akarná, mi maradt kapcsolódva, és mi nem (építesz tree-t a root application-től, végig flagelsz mindent a generation 2 heap-ben, és azonnal kiderül, ha valamik egymáshoz láncolva maradtak, de a működő programnak többé nem részei).

    A CLR GC -je egy mark-compact GC algoritmus (vagyis tudja, amit ide leírtál). A probléma pont az, ha egy adott objektum továbbra is része az objektumgráf egy olyan komponensének, amiben van root (=vezet rootból az objektumba út). Ha egy olyan komponensének része, amiben nincs root, akkor minden további nélkül fel lehet szabadítani. Ez nem GC hiba, hanem programozói.
    Mutasd a teljes hozzászólást!
  • Egy normálisabb gc meg tudná mondani, ha akarná, mi maradt kapcsolódva, és mi nem (építesz tree-t a root application-től, végig flagelsz mindent a generation 2 heap-ben, és azonnal kiderül, ha valamik egymáshoz láncolva maradtak, de a működő programnak többé nem részei). Persze ahhoz rendesen kellene megírni a gc-t. Lévén az MS-nél mára már inkább csak jogászok vannak, mint programozók, én sem számítanék rá, hogy a dotnet és összes cókmókja nem lefelé fog úszni a csatornában. Elvégre már józan paraszti eszük sem maradt, a fene sem bízik bennük többé. De azért még ne legyünk annyira elvakultak, hogy azt állítjuk, kötelezően van úgy. Egyszerűen csak fejétől bűzlik a hal, és annyi az objektív probléma.
    Mutasd a teljes hozzászólást!
  • Ahogy pl. Java-ban sem tudsz felszabadítatlanul hagyni objektumot.

    Egy GC-s nyelvben is lehet simán memory leak. C#-ban például elég csak annyi, hogy nem iratkozik le valami egy event-ről és máris beragadt a memóriában. Ezt ráadásul sokkal nehezebb is kideríteni, míg C++ ban ezt amemory managerem simán megmondja, hogy milyen obj és hol keletkezett, ami beragadt.
    Mutasd a teljes hozzászólást!
  • Esetleg tudja valaki, hogy melyik kernelverziótól lesz hivatalosan Rust interfész a Linux kernelhez?
    Mutasd a teljes hozzászólást!
  • A Linux kernel egyes részeit Rustban tervezik írni.
    Mutasd a teljes hozzászólást!
  • a könyvtárak esetén még mindig nagyon erős a C/C++ (és főleg a C) vonal.

    Az egyik jól eltalált része a Rust-nak, hogy egyszerűen fel tud használni C könyvtárakat, és fordítva, Rust is tud olyan kódot generálni, amit bármilyen nyelvből tudsz hívni, ami tud C-t hívni.

    Emiatt új projecthez fel tudod használni a meglevő C könyvtárakat, illetve ha C-ről Rust-ra konvertálsz, azt meg lehet tenni kis lépésekben.
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Azt viszont fontosnak tartom megemlíteni, hogy a komoly programok ma már nem úgy íródnak, hogy egy nyelven nulláról, hanem sokkal inkább több tucat kész programkönyvtárt használva.

    Másrészt, szerintem a legtöbb igazán komplex alacsony szintű progit már megírták. Kétlem, hogy lesz újabb böngészőmotor, vagy a linux/windows kernelt felváltja majd egy harmadik. Inkább már létező dolgok esnek ki (lásd Pl. Internet Explorer).
    Mutasd a teljes hozzászólást!
  • Ezek a kódrészek milyen nyelven lettek írva?

    Konkrétan nem tudom, általánosságban nagyon sok kód íródik C/C++-ban, ahol nem olyan nehéz memóriaelérési/buffer overflow hibákat ejteni. A böngészők wiki oldalán ott szokott lenni, hogy milyen nyelven íródtak, illetve hát a chromium / firefox nyílt forrású, meg is győződhetsz róla.

    Miért azt a programozási nyelvet használták a böngészőíráshoz és mi lett volna célszerű?

    Amikor azokat írták, arra találtak szakembert. A chrome a wiki szerint 2008-ban született, a firefox 2002-ben, ezeket nem kezdhették el egy 2010-ben bemutatott nyelven.

    Rust programozási nyelv alkalmazása esetén kivédhető vagy egyáltalán csökkenthető-e a memóriahozzáféréssel kapcsolatos sérülékenység?

    Igen. Én nem vagyok Rust szakértő, de úgy tudom, hogy a memóriabiztonság fontos tervezési szempont volt. A tipikus C-s pointeres hibákat (null, invalid pointer dereference) alapesetben nem tudod elkövetni. Ahogy pl. Java-ban sem tudsz felszabadítatlanul hagyni objektumot.

    Azaz a Mozilla ezirányú törekvése kifizetődő lesz-e?

    Biztos kiderül majd. Személyes véleményem szerint a böngészők fő biztonsági kockázata nem abban van, hogy a megvalósításukba hibák csúsznak be. Ez többé-kevésbé minden programnál előfordul. Szerintem a fő kockázat abban van, hogy ma már túl sok feladatot akarnak böngészővel megoldani. Amiből általában csak három-négy fajta jön számításba.

    Egyéb natív internetes alkalmazásoknál (például streaming szerver írása) jó választás-e a Rust vagy van más, erre a célra praktikus nyelv is, amely az ilyen jellegű hibázástól megvéd?

    Attól függ, mi a célod. Szervereknél ahogy én látom, egyre kevésbé divat a natív. A natív ott érdekes, ahol hatékonyság miatt rá akarsz közelíteni a hardverre.

    Továbbá milyen egyéb szempontokat érdemes figyelembe venni a programozási nyelv választásnál?

    Ha magadnak készítesz valamit, akkor azt, hogy jól érts hozzá, és gördülékenyen tudj vele haladni. Ha csapatban fejlesztesz, akkor ugyanez, csak csapatra. (Ahol persze már üzleti szempontok is megjelennek).

    Mennyi energiát érdemes fektetni a Rust programozási nyelvbe? Egyáltalán érdemes-e, vagy tényleg elenyésző lesz az élettere a C++ mellett?

    Én úgy látom, hogy most felszálló ágban van.

    Azt viszont fontosnak tartom megemlíteni, hogy a komoly programok ma már nem úgy íródnak, hogy egy nyelven nulláról, hanem sokkal inkább több tucat kész programkönyvtárt használva. És a könyvtárak esetén még mindig nagyon erős a C/C++ (és főleg a C) vonal. Ha pl. a chromiumot nézed, akkor a debian csomag oldalán vagy 20-30 olyan külső csomagot látsz (asound, atk, cairo, cups, dbus, expat, stb...), aminek a nagy részét bizony C-ben írták. Ezeket nem fogják egyik napról a másikra átírni. Aki próbált már kész programot más nyelvre átírni, az tudja, miért. Könyvtáraknál egyéb okok is vannak.
    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