Keresés: - Megint több ezer embert küld el a Cisco

Legfrissebb anyagok

Mobilarena témák

PROHARDVER! témák

IT café témák

GAMEPOD témák

LOGOUT témák

Keresés

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

#35 buherton őstag cucka #34

Új Válasz 2024-08-16 13:22:51 #35
Ú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 cucka #34 üzenetére

A programozási nyelvek nem avulnak el attól, hogy régiek. Egy nyelv akkor avul el, amikor már nem használják az emberek.
A C egy óriási mérföldkő volt, amikor kijött '72-ben. Nyelveken átívelő a hatása. A mai napig az alacsonyszintű programozás és a beágyazott rendszerek meghatározó nyelve. Statisztikától függően még mindig 10-30%-os részesedéssel rendelkezik. Ennek ellenére a C szerintem elavult lett. Az, hogy a karaktertömbök esetén - mert ugye nincs benne string - külön odakell figyelni a \0-ra, a compiler simán engedi a syntax hibás kódot lefordulni, irtó nehéz értelmes unit tesztet írni benne, vagy éppen mockolni a függvényeket, szinte minden C-ben írt program memory leakel, stb. nem egyezik meg a kor elvárásaival, aka elavult. Ha tetézni akarom a problémát, akkor a C-hez sorosan kötőd make is elavult.
Arra is érdemes szerintem gondolni, hogy oké lehet egy nyelvet új elemekkel frissíteni, de az végül egy csillagromboló nyelvet fog eredményezni, lásd C++ (~6 millió karakteres a standradje), Java (~1 millió karakteres specifikáció), stb., ami pont ellene megy a karbantarthatóságnak vagy éppen annak, hogy az embereket könnyedén lehessen mozgatni a projektek között. Fun fact a Go-nak kb 350.000 karakteres a specifikációja.
#33 bijesz aktív tag cucka #32

Új Válasz 2024-08-15 20:12:39 #33
Ú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

bijesz

aktív tag

válasz cucka #32 üzenetére

Van ahol a jelen van ahol a jövő.
Én arra reflektáltam, hogy az idézett gondolotad alapján nekem az jött le úgy képzeled nagy rendszernél csak a javaban érdemes gondolkodni, erre írtam, hogy szerintem ez már nem igaz.
SOA meg ESB idejében nem voltak jellemzők az elosztott rendszerek.
Az ssadm nyílván más de az is visszaszorult ez csak egy párhuzam ami szakmába vág, írhattam volna fényképezőgépet vagy karórát is.
Monolitok nem tűnnek el, de ahogy egyre jobban kiforr a dc oda tolódik az nagyvállalati fejlesztés szerintem.
#30 bijesz aktív tag cucka #26

Új Válasz 2024-08-14 19:17:48 #30
Ú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

bijesz

aktív tag

válasz cucka #26 üzenetére

Java-t akkor veszed elő, ha meg kell írni egy több tízmillió soros enterprise rendszert, amit több évtizeden keresztül kell tudni karban tartani és üzemeltetni
A jövő elvileg az, hogy nem lesz több tízmillió soros enterprise rendszer hanem kisebb komponensek kompozíciójából áll össze.
És nem is kell feltétlenül egy nyelven/technológiában gondolkodni.
Nem azonnal és és mindenhol, de ahogy pl az ssadm is kikopott lassan ez az architektúra/nyelv is visszaszorul.
Szerintem erre gondolnak, a go csak egy manifesztációja ennek mert hatékonyabb erőforráskihasználást tesz lehetővé a hiperscalerekben.
#28 buherton őstag cucka #26

Új Válasz 2024-08-13 21:17:39 #28
Ú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 cucka #26 üzenetére

A Go arra van, hogy a Java/C++-t le lehessen váltani. Egyébként pedig cloud, de aztán egy picit több lett. A Canonical elég sok CLI-t már Go ír csak hogy egy példát mondjak.
Hirtelenjében csak a k8s kódjára kerestem rá, az már 2 millió sor kód. Oké, ez még nem több tízmillió soros kód, de nem olyan régóta elérhető, mint a Java. Szóval, ez még a jövő zenéje, hogy mivé fog válni. Annyi biztos, hogy a Go évről-évre nagyobb részesedést szerez.
Valaha olyan pozícióba kerülök, hogy erről dönthessek, akkor egy ilyen kaliberű projektre biztosan nem a Java-t választanám - most tegyük félre, hogy melyik nyelvre lehet találni embert -, hanem Go-ra.
Lebecsülni nagy projektnél a build időt nem szerencsés. És akkor még a mavenre elpazarolt időt ne is számoljuk ide, ami nincs a Go-nál.
Ok, pontosabban kellene fogalmaznom. Az öröklést tette elavulttá a kompozíció. Még ha a kettő nem pontosan ugyanarra van.
#27 Cassi
Ugyan már, a Java továbbra is alap a vállalati informatikában.
Sok Cobolban írt program fut még, de attól még a Cobol elavult. A kettő nem zárja ki egymást. Nézd meg, hogy a szálkezelés milyen bonyolult a Javaban és ugyanaz Go-ban.
#25 buherton őstag cucka #24

Új Válasz 2024-08-13 19:25:40 #25
Ú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 cucka #24 üzenetére

Húú, ez így elég véres lesz.
Hogy miért korszerű a Go?
High level:
- A Google érzékelte, hogy az emberek 1-2 évig vannak a projekten és utána váltanak. Ezért kell egy olyan nyelv, ami egyszerű, gyorsan megtanulható és nagyon hamar effektív lehet benne az ember. Emiatt a Go-ban csak olyan nyelvi elemek kerültek be, amik egyszerűvé, de hatékonnyá teszik a programot.
- A Google azt is érzékelte, hogy a technikai körülmények is megváltoztak. Ma már a több CPU-s, illetve több szálon való programozás az alap. Ezért két irányból oldották meg ezt a problémát: 1. CSP stílusú konkurencia, 2. goroutine. Könnyen belátható, hogy a processzek létrehozása "őrült" erőforrásigényes, de a thread is jelentős erőforrást igényel, ezzel szemben a goroutine "szinte" semmi kategória. [Go Routines vs. Java Threads: Unleashing Efficiency and Simplicity].
Nyelvi elemek:
- kevés olyan nyelvi elem van, aminek a használata egy kezdő számára nem egyértelmű és könnyen hibára vezethet. Az egyiket - és praktikusan az egyetlen számottevőt - épp nem rég javították ki: [Fixing For Loops in Go 1.22]
- nincs benne OOP (OOP-t a kompozíció tette elavulttá, és a Go csak a kompozíciót támogatja)
- nincs exception
- nincs function/operator overloading
- nincs metaprogramming
- stb.
Performance:
- [Go vs Java] -> CPU-ban kb egyezik, de a memória fogyasztás jóval kisebb.
- [Go vs C++] -> A Go és C++ programok szinte ugyanannyi memórián futnak. Azt azért hozzáteszem, hogy egy átlag Go-ban írt programra ez nem igaz, de vélelmezhetően a Java-tól még ígyis messze van.
Building:
- Megírod a kódot, kiadod hogy go build . és ennyi. Ez a parancs leszedi a 3PP-ket, lefordít mindent és összelinkeli a binárist.
- A binárisnak nincsen dependenciája és semmit nem kell előtte telepíteni. Letöltöd és futtatod. Ennyi. Például, ha kind-t (local k8s clustert lehet benne csinálni) szeretnél telepíteni, akkor: [link]
- Cross compilation annyiból áll, hogy GOOS=linux GOARCH=arm64 go build . a GOOS-t és GOARCH-t kb. tetszőlegesen lehet állítani.
- A Go programok nagyon gyorsan megépülnek.
#23 buherton őstag cucka #22

Új Válasz 2024-08-13 18:11:28 #23
Ú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 cucka #22 üzenetére

Nekem azt jelenti az elavult, hogy az adott problémára/problémakörre van már egy korszerűbb megoldás. A szerver oldalon egyértelműen a Go a korszerű.
Ahogy az IPv6-ra is kb lehetetlen, de attól még szeretem szűkíteni a fals pozitív eseteket, amennyire lehet.