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

• #15 buherton őstag Mr Dini #13

  Új Válasz 2023-12-01 13:09:51 #15

  Ú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 Mr Dini #13 üzenetére

  A Rust eddig teljesen kimaradt az életemből. Azon kívül, hogy gyorsaságban a C-vel veteszik, tudtommal a Linux is nyitott rá és hogy jól kezeli a memory leak veszélyes helyzeteket, nem tudok semmit. Se szintaktika, se principle, semmit se.

  Azt nyugodtan ki lehet jelenti, hogy az OOP elavult lett (a Java-val együtt, csak hogy borzoljam a kedélyeket). Pontosan én is így gondolom: [The Flaws of Inheritance]. A go nem is támogatja az OOP-t.

  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:

  Most már erősen a tudásom határán mozgok, de szerintem a Decompile ablak csak annyit mond, hogy az egyes sor milyen symbolt használ. A bal oldali ablak meg "csak" annyit, hogy az fmt-ben milyen symbolok vannak. Az hogy a linker mit fog a binárisba tenni az egy harmadik kérdés. Szerintem egyébként a teljes static libet. Közben megnéztem és a symbolokat a go tool nm-al lehet kilistázni. A binárisban benne van az összes fmt symbol vagyis a teljes static lib bekerül. A lényegen egyébként nem változtat, hogy a go binárisok nagyok.

  Még egy picit a Rust vs Go-nál maradva. Amennyire tudom a Rust a zászlajára tűzte a performanciát és e köré épített fel mindent: a principle, memória menedzsment, build, stb. És ez így van jól, mert sok helyen nem engedhető meg, hogy pl. garbage collector fusson a háttérben. Addig a go más megközelítést alkalmazott: [Miért és mikor érdemes Go-ban programozni? - Szabó Dávid (LeanNet)] abszolút egyetértek a meglátásaival. Ez persze nem jelenti, hogy a go-ban ne figyeltek volna a performanciára, mert a goroutine önmagában megtestesíti ezt. És a garbage collector is elég penge lett: [Go versus Rust fastest performance]. De pl. a bináris mérete már nem erről árulkodik. Egyébként a _teljes_ footprintet nézve ide a rozsdás bökőt, hogy a go még ígyis odaver a Java, C#, Python és társaiknak. Az pedig a non plusz ultra, hogy a dockerimage készítés álom egyszerű a go-val. A cross compiling is egyszerű. A legutóbbi nagy go-s feature az volt, hogy most már a binárisok az utolsó bitig reprodukálhatóak. Szóval egy adott kódra a go 10 év múlva, sok verzió után is bitre ugyanazt a binárist fogja generálni. Most fejezem be a go "dicsőítést", mert itt ragadok még egy darabig. Még annyit (reflektálva a buildre), hogy a rengeteg makefile és CMake (több millió soros C/C++ projektet írtam át Makefileról CMakere, de úgy hogy a projektnek több féle Linux disztrón, többféle CPU archictectúrán (armle/be/64, ppc, x86) kellett futnia. Külön production és unit teszt kód. Kellett binárisokat, shared és static libeket, sima 3pp-ket, framework 3pp-ket, kernel modulokat, illetve magát a kernelt is fordítani) után álom az, hogy a go-ban a build annyi, hogy go build.

  Volt kollégám aki C++ phd hallgató volt és olyan csuda kódot írt, hogy a csapatból senki nem értette, hogyan működik, amit írt. Ez pedig szerintem abszolút a nyelvhibája, hogy ilyet megenged. A csuda kód alatt nem valami alattomosan kesze-kuszán írt kódot kell érteni, hanem olyat, ami kihasználja a nyelv featureit. Talán egy jó példa, hogy a C++ template magicre külön kb 1000 oldalas könyvet írtak. WTF?! Ki az aki ezt elolvassa és végül használja?! És a template magic csak egy a sok C++ featurei közül.

  Humor ON:
  A Rust-ról ennyit tudok: [Interview with Senior Rust Developer in 2023]
  Ez pedig jól mutatja be az emacs-t: [Interview with an Emacs Enthusiast in 2023 [Colorized]] (btw, nagy emacs fan vagyok)

  (#14) Mr Dini: a vscode tényleg jó. Amikor vacilláltam, hogy milyen toolt használjak és akkoriban lett volna vscode, akkor könnyen lehet, hogy ott kötök ki én is.

  Úgy gondolom, hogy a vim és az emacs egy kutya csak más a megközelítést használtak. Teljesen mást: [Editor war].

  Szerintem bold claim a részedről, hogy nem tartod magad programozónak. A megnyilvánulásaid alapján nekem az jön le, hogy mélyebben tisztában vagy a dolgok mikéntjével

  Szerintem ez egy fontos önismeret, hogy valaki tudja magáról, hogy kicsoda. Persze azt fontos leszögezni, hogy ez nem mérvadója a tudásnak, hanem inkább a gondolkodást írja le, hogy hogyan áll hozzá a problémához.

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