2. Fórumok
  3. LOGOUT reakciók
  4. 24 órán keresztül programoztam

Új hozzászólás Aktív témák

  • #13 Mr Dini addikt buherton #11
    Új Válasz #13
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Mr Dini

    addikt

    válasz buherton #11 üzenetére

    Húú, na pontosan ezekért az elképesztő hasznos szakmai kommentekért, illetve pl. a lajosdani2 féle élménybeszámolók miatt éri meg vezetni ezt a blogot. Köszönöm a meglátásokat!

    Én nem szeretem a Go-t, hogy őszinte legyek, bár piszok kényelmes. De lehet azért, mert rustról váltottam vissza, ami elég erősen kikényszeríti a programozótól, hogy szép kódot írjon. Nem rossz amúgy, de kb az a kód le is fog fordulni, amire nem panaszkodik az IDE. Találkoztam egyszer egy érdekes problémával, hogy adott volt egy Go backend. Ez egy websocketet nyitott a kliensek felé és eventeket küldött, majd kapott válaszokat a kliensektől. Ha sok kliens volt, egyszer csak pánikolt. Pedig látszólag mindenhol rendesen figyeltem a lock-ra. Később rájöttem, hogy maga a library volt a hibás, mivel a pingek küldésnél elfelejtettek lockolni és ha pont akkor olvastam a streamről, mint amikor ezek pingeltek, akkor meghalt a processz. Újraírtam rustban, ami le se engedte fordítani úgy a kódot, hogy nem lockoltam valamit. És még ki is oktatott informatívan, hogy ez meg ez nem jó és nesze, old meg így. Az lehet, hogy több effort volt a végén a kód és sokkal hosszabb lett, mint a Go megoldás, de a nem létező mérnöki szememmel sokkal precízebb lett a végeredmény.

    Lehet ez egy senior Go devnek nem hátrány, hiszen ő már eleve gondol mindenre is, de én ettől sajnos messze vagyok.

    sync.Map-et meg ismerem és használtam is máskor. Csak ez is egy extra faktor, amire figyelni kell.

    A C++t én sem szeretem, de úgy általában az OOP nyelveket sem igazán. Egy két valid use-case-t tudok elképzelni, amúgy szerintem a funkcionális nyelveknél nincs gyorsabb. :U Az lehet, hogy áttekinthetőbb, meg a polimorfizmusnak köszönhetően könnyebb kiegészíteni, így pikk-pakk lehet vele haladni, de nem feltétlen lesz az optimális. Meg sokszor jár vele a tömény absztrakció is, ami szerintem egy szint után már felesleges overhead. Egyetemen nálunk nagyon nyomják a C#-ot, de C és társai sosem voltak terítéken. Az OOP-ra esküsznek. De ezzel most egy háborút fogok elindítani. :B Nem akarok persze senkinek a lelkébe gázolni.

    Az alábbi kód maximum a szerencsének köszönhetően menti el a fájlt.

    Köszönöm az észrevételt, teljesen jogos! Bevallom, a kész kódból másoltam ki részleteket és a saveImage alatt bőven van blocking call, ami miatt nem fog kilépni a program, csak a copy-pastenél azt pont nem írtam át. A példa kedvéért most kiszedtem a go kulcsszót.

    A linkelésről pedig. Úgy néz ki én tudtam rosszul, vagy azóta változtak a dolgok. Lefordítottam az alábbi kódot:

    package main

    import "fmt"

    func main() {
    fmt.Println("Hello, World!")
    }

    Az volt az elvárásom, hogy az fmt egyetlen függvénye miatt bekerül a binárisba az fmt összes szimbóluma. A szemléltetés kedvéért nem strippeltem a kész binárist. Ghidrában megtekintve az eredményt, jól látható, hogy rosszul tudtam:

    Általában mindennek utánanézek, amikor állítok valamit, de úgy néz ki, itt hibáztam. A cikket majd frissítem egy update formájában, hogy I stand corrected és nem is olyan vészes a helyzet. Köszönöm!

    A linker meg... Az világos, hogy statikus ELF fájl lesz például linuxon. De itt most a Hello World kedvéért simán elegendőnek kéne legyen egy libc linking. Rusttal megcsinálod ugyanezt egy musl toolchainnel buildelve és kapsz egy pár száz KiB-os optimalizált, teljesen static binary-t. Macerásabb, mint Go-t buildelni, de ég és föld a végeredménybeli különbség.

    Minden egér szereti a sajtot... Kivéve a Logitech G305.

Új hozzászólás Aktív témák