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

• #17 UnA Korrektor buherton #11

  Új Válasz 2023-12-02 00:03:45 #17

  Ú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

  

  UnA

  Korrektor

  válasz buherton #11 üzenetére

  A Python vs Go (stb) egy hibás kérdésfelvetés ebben a formában Az eszközt a feladathoz érdemes választani, éppen ezért a Python még a "minimumra törekvés" kategóriában is versenyképes, mert ma nincs Linux Python nélkül. Vagyis egy bizonyos kód méret alatt egy scripting nyelv egyértelmű előnyben van azzal az erőfeszítéssel, amit egy extra compiler + libek megkívánnak.

  A vim pedig ... hát lehet, hogy kisebb erőforrás, de nagyobb mazochizmus Mondom ezt úgy, hogy nálam terminálos szerkesztés esetén mindig ez a default, de a kényelmes nem egyenlő a megszokással.

• #13 Mr Dini addikt buherton #11

  Új Válasz 2023-12-01 11:29:28 #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. 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. 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.

• #12 buherton őstag buherton #11

  Új Válasz 2023-12-01 09:10:40 #12

  Ú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

  

  buherton

  őstag

  válasz buherton #11 üzenetére

  Jah, igen és a vscode. Nagyon-nagyon jó IDE, de a fenéért kell felzabálnia a gép erőforrásait?! Erősen javaslom a váltást emacs-ra vagy vim-re. Ezek a kávédarálón is elfutnak és nagyon jó feature paritást lehet elérni.

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