Hirdetés
Új hozzászólás Aktív témák
-
buherton
őstag
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.
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
Mr Dini
addikt
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
saveImagealatt 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.
-
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.
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 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. 
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. Új hozzászólás Aktív témák
lo Az utóbbi pár hónapban rengeteg versenyen vettem részt. No nem azért, mert ennyire ügyes lennék/hajtana a...
Állásajánlatok
Cég: Axon Labs Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest