[Videó] Milyen buktatói lehetnek a Go programozási nyelvnek? - Sági-Kazár Márk (Banzai Cloud)

Címkék

Sági-Kazár Márk, a Banzai Cloud szoftvermérnökének a HWSW free! meetup sorozaton elhangzott előadásának felvétele.

A Go programozási nyelv - ígérete szerint - könnyen megtanulható és a nyelv sajátosságainak köszönhetően könnyen használható. Sajnos azonban a szép külső alatt találunk olyan buktatókat, ami nem csak a kezdőket tántoríthatja el a nyelv szeretetétől, hanem akár szolgáltatáskiesést is okozhatnak. Az előadás során erre nézünk pár példát.

(A videó a HWSW free! meetup-sorozat 2020. október 15-i Go-fejlesztői állomásán készült.)

Hozzászólások

Jó ez a kép :) Tükrözi azt hogy fogalma sincs mi az a Go meg mi az a programozás. De persze ez egy fizetett reklám ^^ így maradhat. Csak ez kissé sz.r

Esetleg valami azoknak, akik tudnak olvasni? Tudom, hogy rétegigény, de azért...

Kendnek is már a B oldal forog?

Egyetemista diákjaimnak a könyvbe kötött, lépésről-lépésre feladatmegoldások már nem megfelelőek, helyette oktatóvideókat akarnak mindenről. Legyen videófelvétel az összes előadásról, "táblás" gyakorlatról. Ha online teszt van, akkor ilyenekkel gyakorolnak. A tankönyv elolvasása helyett a tesztek eredményeiből próbálnak általánosítani. (Igen, a deep learning is így működik, de milliónyi példára, és ötre-tízre.) Ha pedig papíron írják a dolgozatot, az online teszt környékére sem szagolnak, hiába ugyanarról a témakörről szól mindkettő.

Most szerencséjük volt, a távolléti oktatásnál csak a felvétel gombot kellett valakinek megnyomnia, és annyi oktatóvideó volt, hogy nem is bírták végignézni. Viszont az infrastruktúra nem adott, hogy igényes anyagok készüljenek és a tábla helyett a képernyőre írt szöveg, rajzolt ábra helyett vállalható animáció kerüljön. (Persze a segédanyagok készítését továbbra is vatikáni valutában jutalmazzák.)

AL

Szerkesztve: 2021. 01. 09., szo - 10:32

Nem tudom, nekem jobban olvasható egy Java kód és annak a marhaságait már megszoktam. Igaz váltani kell, de akkor már inkább a C#, azt jobban is ismerem, meg a másik csapat, akikhez mostanában alkalmazkodnom kell, ők is ebben viszik a projektjeiket.

A sráccal nincs gond, a videó valóban kicsit nyögvenyelős, ha szereti a Go-t és abban dolgozhat, had csinálja.

Örülök hogy nem csak az adott programozási nyelv szépségeit, hanem árnyoldalait is bemutatja valaki. Bár osztom a véleményt, hogy egy jó leírás gyakran többet ér a szakmában.
Egyúttal megragadom az alkalmat, én a Go-Rust kérdésben a Rust mellett kötöttem ki, ennek megtanulása után most már a Rust árnyoldalait gyűjtögetem. Ha valaki tud segíteni, akár privátban is örülnék.

A párhuzamos futtatás téma és buktatója is tanulságos. Egyúttal kontrasztként bemutatom a Rust iterátoros trükkjét az ilyesmire:
    https://play.golang.org/p/xtH51Vwsci-
    https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gi…
 

> a Rust árnyoldalait gyűjtögetem. Ha valaki tud segíteni [...]

Ezekkel találkoztam:

  - Noha sokszor mutat olyan fordítási hibát, amit könnyen javíthatok, pedig ha fordulna, nehezen reprodukálható lenne, elszállást vagy adatvesztést okozhatna... Máskor viszont pontosan látom, hogy C++-ban leírhatnám, működne, a Rust viszont nem fogadja el.  Két példa: az élettartam-annotációkat generikus kódnál néha nehéz megérteni (exisztenciális kvantor: where for<'a> T: T2<'a, ...>, és társai), illetve az "adat vagy írható, vagy megosztható" szabály.  Utóbbi azért lehet bosszantó, mert ha fordításkor nem mondható meg, hogy valami helyes-e vagy nem, csak futásidőben derül ki, akkor a fordító megtiltja, és csak pl. RefCell vagy ilyesmi hozzáadása után fogadja el.  Pedig egy egyszerűbb helyzet C-ben is átlátható lenne, extrák nélkül.

Hozzáteszem, ezekért a nehézségekért cserébe jövőbiztosabb kódot kapok, azaz valaki nem tudja fél év múlva új feature fejlesztésekor egykönnyen elrontani, még ha komplex is a kód.

  - Ugyan más nyelvekhez képest még világosabb, hogy mikor kell sima referenciát használni, mikor másolni-mozgatni, mikor Rc-t, mikor RefCell-t, stb., közben ez a sok lehetőség nehezebben refaktorálhatóvá teszi a kódot.  Én legalábbis így érzem.  Először is több lehetőség van, pl. RefCell nincs máshol, ezért Rc<RefCell> sincs.

Szóval pl. ha egy API valamiről Rc<RefCell<T>>-t ad ki, azt már nem tudom konkurrensen használni.  Akkor sem, ha az API alatti kóddal nem akarom párhuzamosan használni, csak máshol.  Persze átmozgathatom az adatot Mutex-be, ha rászánom ezt a plusz lépést.  Másik megoldás, ha minden kód nálam van: mindenhol refaktorálom, az API és az az alatti réteg Rc<RefCell<T>> helyett Arc<Mutex<T>>-s lesz.  Akkor viszont ez a megoldás lesz bedrótozva.

Vagy &T-t kapok, de Rc<RefCell<T>>-t kellene használnom.  Vagy pont fordítva - ez esetben működni fog minden, csak tegyük föl, lespórolnám ezeket a runtime ellenőrzéseket, amikor nem kellenek.

Amikor készen van a projekt, akkor mindez már nem gond, de refaktorálni általában azért kell, mert még nincs kész.

Csináltam generikus "hivatkozhatót" olyanokon, mint T, Box<T>, RefCell<T>, Rc<T>, Rc<RefCell<T>>, Arc<Mutex<T>>.  Lényegében sikerrel jártam, bár egyrészt nagyon-nagyon kínlódós volt, :)  másrészt nem minden vonatkozás tehető generikussá (részben elvi okokból).

  - (Az említett generikus cuccom miatt) nekem tetszene, ha lenne referenciákra generikus "mut".  Azaz pl.

fn valami(&mut_by<valtozo> self);

... amit úgy értek, hogy ha egy változó mutable, akkor itt a self is az legyen;  ha az nem, akkor ez se.  Persze ezt így formai okokból sem lehet, változó nem lehet generikus paraméter.

  - Szintén az előbbi miatt örülnék, ha modulnak lehetne típusparamétert adni.  Most cfg direktívával oldom meg, így kicsit körülményesebb.  Lehet, hogy a most készülő GAT (generikus társított típus), meg a tetszőleges self-típus majd megoldja ezeket a fajta problémákat.

  - A static változók használata körülményes.  Néha segítene, ha !Sync-ké lehetne őket tenni, ezt nem engedi.  Igazából minden jól működik enélkül is, pl. a lazy_static az egyik jó megoldás.  És láttam mozgolódást e téren, lehet, hogy változtatnak még rajta.

  - Hiányoznak a timeout-oló IO-hívások.

  - Aszinkron megoldásból több is van, de már kialakult az irány, csak még lendületben vannak a korábbiak.  Ezekről saját élményem nincs.  A mio-t és a tokio-t annó megnéztem, de örülök, hogy még nem kellett, mert most már az async-await-tel dolgozhatok, ha majd kell.

Szóval a go régen azért volt jó, mert kevesebb hibát tudsz benne elkövetni pl egy c/c++ -hoz képest. Azt is megtudtuk régen, hogy a c/c++ azért szar, mert vannak benne pointerek. Ebben a videóban megtudtuk, hogy a go azért szar, mert vannak benne pointerek.

rly?

// Happy debugging, suckers
#define true (rand() > 10)

Na, ez most kapóra jön hajbazernek, mutogathatja a Micro text editor fejlesztőinek.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧