(A videó a HWSW free! meetup-sorozat 2020. október 15-i Go-fejlesztői állomásán készült.)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Esetleg valami azoknak, akik tudnak olvasni? Tudom, hogy rétegigény, de azért...
- A hozzászóláshoz be kell jelentkezni
Elég retek ez a mindenről videót készítünk. Egy szöveget könnyen átfutok és kevesebb idő jóval mint egy videó. Nem is szoktam megnézni ilyesmiket hírportálokon sem.
- A hozzászóláshoz be kell jelentkezni
ezeket a videokat nem irott tartalom helyett gyartjuk, hanem ha mar eloadnak nalunk emberek, akkor felvesszuk. ha mar felvesszuk akkor publikaljuk. a dontes a tied, fogyasztod e vagy sem.
- A hozzászóláshoz be kell jelentkezni
Van az a pénz, amiért legépelem neked. Keress az elérhetőségeken!
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
+1
"A fejlesztők és a Jóisten versenyben vannak. Az előbbiek egyre hülyebiztosabb szerkezeteket csinálnak, a Jóisten meg egyre hülyébb embereket. És hát a Jóisten áll nyerésre." By:nalaca001 valahol máshol
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Vagy akkor már Kotlin ha mindenképp be kell újítani. Az még közelebb van a Java-hoz.
- A hozzászóláshoz be kell jelentkezni
Ö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 hozzászóláshoz be kell jelentkezni
> 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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Azon kivul forditott nyelvben is kevesebb hibat tudsz elkoveni, mint ami csak runtime robban.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Na, ez most kapóra jön hajbazernek, mutogathatja a Micro text editor fejlesztőinek.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni