Miért a Go lett 2020 legjobban vágyott programozási nyelve?

Címkék

A HackerRank 2020-as, 116.000 fejlesztő válaszaiból készült kutatása szerint a legtöbbjük a Go-t szeretné megtanulni következőleg, amely eredménynek az okait most ebben a cikkben szedtük össze.

A Go első publikus verziója 2009-ben jelent meg, azonban a népszerűsége csak az elmúlt években nőtt meg, köszönhetően a felhős rendszerek és a Docker tömeges elterjedésének. A nyelvet a Google-nél fejlesztették ki, a fejlesztést olyan szakemberek vezették, akik korábban a Unix operációs rendszer, a Java HotSpot JVM vagy az UTF-8 karakterkódolás fejlesztésében is kulcsszerepet játszottak.

A cél az volt, hogy régebbi általános célú nyelvek hiányosságait kiküszöböljék, hiszen a megváltozott üzleti és technológiai körülmények között ezek a nyelvek nem bizonyultak elég hatékonynak. A felhőben való futtatásra olyan alkalmazások készítésére volt igény, amelyek nagy hatékonysággal futnak és kiválóan skálázódnak.

A Go általános célú, könnyen tanulható, kevesebb nyelvi elemet tartalmazó, letisztult programnyelv, éppen ezért kiválóan alkalmazható ott, ahol a kódbázishoz nagyszámú, gyakran cserélődő, változó összetételű programozói gárda fér hozzá, időben és földrajzi elhelyezkedésben is megosztva.

A Go alkalmazás jól skálázódik, remekül képes kihasználni a többmagos processzorok és konkurens futtatás adta számítási kapacitást, ráadásul kiválóan konténerizálható, akár nagyságrendekkel kisebb image mérettel, mint a Java alkalmazások. Nem véletlenül mondják, hogy a Go egy igazi 21. századi, Cloud Native programnyelv!

Beszédes, hogy a Linux Foundation által létrehozott Cloud Native Computing Foundation (CNCF) berkein belül támogatott projektek nagy része Go-ban íródott, többek között a Kubernetes, a Prometheus, az Istio, de ebben írták a Dockert is.

Go körül nincs az állandóan változó informatikai trendekhez hosszú évek alatt igazított, hajlítgatott, ennek megfelelően bonyolult ökoszisztéma, ami az igazi nehézségét adja a hagyományos nyelveknek. Ennek megfelelően elérhető cél, hogy elsajátítsuk a teljes nyelvet és a legnépszerűbb könyvtárak használatát akár egy év alatt, ami például Java-ban nem reális célkitűzés.

A szokásos pár éves késéssel a Go vonat Magyarországra is kezd befutni, olyan milliárdos befektetések vonzó hazai vállalkozások, mint a Bitrise vagy Shapr3D is Go alapokon építkezik. Hamarosan a Go kereslet gyors felfutása várható, míg a kínálati oldal a nullához közelít. Éppen ezért a Go esetében egy junior szintű tudás is felértékelődik, és teljesen más az optikája ha valaki egy éves Go tapasztalatot ír be a CV-jébe, mintha ugyanezt Java-ból írná be.

Éppen ezen okokból a HWSW egy 10 alkalmas, 30 órás online képzést indít, amely az alapoktól indulva mutatja be a Go programozást. A tanfolyam oktatópartnere a LeanNet - Adabit, munkatársai kiváló szakemberek és oktatók, amiről magad is meggyőződhetsz, Szabó Dávid "Miért és mikor érdemes Go-ban programozni?" című rövid előadását megtekintve.

A november 9-én induló képzéshez mindössze alapszintű programozási ismeretek szükségesek. A 10 alkalmas tanfolyam online követhető élőben és az órákról felvétel is készül, melyet a résztvevők utólag bármikor és bármennyiszer visszanézhetnek, így senki nem maradhat le egy óráról sem. A képzés részletei a HWSW oldalán találhatóak, ahol a regisztrációs felület is elérhető.

Hozzászólások

"Go körül nincs az állandóan változó informatikai trendekhez hosszú évek alatt igazított, hajlítgatott, ennek megfelelően bonyolult ökoszisztéma, ami az igazi nehézségét adja a hagyományos nyelveknek. Ennek megfelelően elérhető cél, hogy elsajátítsuk a teljes nyelvet és a legnépszerűbb könyvtárak használatát akár egy év alatt, ami például Java-ban nem reális célkitűzés."

Ez a mondat ugyanúgy igaz Python-ra, ami a második helyezett a listán, és valószínűleg a Google által is kedvelt Kotlin-ra is, amelyik a harmadik. Nem ezért akarnak az emberek Go-t tanulni.

Amúgy az egész felmérést kicsit kétkedve fogadom. Valahogy nehéz elhinnem, hogy általában a Pascal népszerűbb lenne, mint a C. A válaszadók többsége valószínűleg már ismeri a C-t, így második, vagy sokadik nyelvként már nem azt akarják megtanulni.

Mások ezt hozzák ki a nyelvek népszerűségére: https://www.tiobe.com/tiobe-index/

Az újonnan választott nyelvek között pedig általában a Python az első: https://www.slant.co/topics/25/~best-programming-language-to-learn-first

"Go körül nincs az állandóan változó informatikai trendekhez hosszú évek alatt igazított, hajlítgatott, ennek megfelelően bonyolult ökoszisztéma, ami az igazi nehézségét adja a hagyományos nyelveknek."

Ergo vagy nekiállhatsz megírni mindent ami neked kell, vagy böngészheted a netet hogy hátha valaki csinált már valahol egy ilyen libet ami azt tudja ami neked kellene, és reménykedsz hogy az illető nem hagyta már régen ott a fenébe az egészet mint eb a szaharát.

Anno ezt én is eljátszottam a C++-szal a régi szép időkben (2000 előtt). Tök izgalmas volt, hogy a legapróbb funkcióhoz is lehetett vadászni a libeket, és kezelni a külöféle függőségeket...

Nyilvan lehet igy is ertelmezni. Itt inkabb a hajlitgatott kifejezesen van a hangsuly. Itt van pl a cloud, a kontenerek, meg a szalkezeles, ill a tobbmagos procik vilaga, melybe pl a java be lett hajtogatva, es ennek megfeleloen rohadt korulmenyes egy csomo dolog ezen a palyan. olyan ez mint amikor benzines verdak alvazara akarnak elektromos autot epiteni, az akksi meg kis tulzassal megy a csomagtartoba :)

A cloud support alatt nem igazan ertem mit ertesz, ezt ki tudnad fejteni bovebbeen? Szerintem a nyelvnek ehhez nem sok koze van de lehet valamit en nezek be.

Container support van Java 8-tol felfele, jelenleg 15-nel jarunk. :)

Szolj mar az Oracle-nek, hogy hibas a Javadoc es a Javaban valojaban nincs 25 eve szalkezeles. :)
https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/…
(Since 1.0)

Epp ez a baja, hogy, oreg es takolt. Na nem minthat nem volna revsit idonkent, es par eve is jottek uj konkurrent modellek a nyelvbe. Meg amugy rakas high level lib van, ami elfedi a tenyleges szal kezelest. Gyakolatilag a mai Java alkalmazasok 99.99% valamilyen multi threading cucc.

Nekem Java, Go vonalon van tapasztalatom masszip tobbszalas rendszerekkel, es a) mindkettot ki kellett tanulni, mert anelkul nehez. b) A Go sokkal egszerubb, de cserebe pl nem lehet benne parhuzamos vegrehajtast implementalni. A Java meg bonyolultabb, cserebe meg os threadekkel lehet dolgozni, es kismillio fele megoldasbol lehet valasztani.

Ezek az altalad idezett kutatasok vagy a jelenlegi nyelvek nepszeruseget mutatjak vagy a kulcsszo learn first, a hackerrank vagy a stackoverflow kutatasanak hivatkozott resze pedig arrol szol, hogy minek ugranal neki most a legszivesebben. A stackoverflow loved es wanted kulcsszavak menten valassza szet az alabbi ket szempontot. Mivel ez a 2 legnagyobb mintavetelu kutatas es ezek korul vannak a legnagyobb kozossegek is, illetve elegge hasonlo eredmenyre jutnak, hajlamos vagyok hinni nekik.

Én anno néztem a go szintaktikáját, és valahogy nem keltett bennem a dolog olthatatlan vágyat. Egy újabb, a szokottnál még sokkal bénább C alapú nyelv.

A helyes válasz ott van azért elrejtve: "Go-ban íródott, többek között a Kubernetes, a Prometheus, az Istio, de ebben írták a Dockert is."

A Kubernetes a rajta dolgozók számát tekintve már nagyobb project, mint a Linux maga. Vagyis aki ezekben akar dolgozni, annak Go-t kell tanulnia.

Mint feljebb írtad (meg mások is), manapság a libek megléte, használhatósága és  multiplatformossága a kérdés, mintsem a nyelv.

Úgy érzem, a magasabb szintű nyelv a magasabb szintű libekkel sokszor feleslegesen bonyolult, tehát az a baj. Az alacsonyabb szintűnél meg az a baj.

Így aztán marad a gazdaságossági számítása...

Ez addig a percig van így, amíg nem jön szembe egy éles projekt, valódi követelményekkel. És akkor mindjárt jól jön a magasabb szintű nyelv, amiben jobban ki tudod fejezni a dolgokat, illetve a komplexebb framework amiben megbízhatóan benne van egy rakás, számodra szükséges funkcionalitás, és nem neked kell szálanként összevadászni ami aztán vagy megvan vagy nincs, vagy bugos vagy nem, vagy fejlesztik vagy azóta a kitalálója elment a tibeti hegyek közé buddhista szerzetesnek.

Vagy mondjuk a nyelvben van beepitett memory management, es mondjuk millios nagysagrandben tud user mode szalakat kezelni, es a sajat utemezojenek hala egesz jol eltalalja mikor melyiknek kell futni raadasul legtobbszor kernel szintu context switchek nelkul. De amugyt tiszta C a Go ;)

Engem a Go vs Rust terén az elérhető futástempó is befolyásolt a furmányos nyelvi képességein túl.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rus…

Persze kellő ismeret és tapasztalat nélkül Rust-ban is lehet borzasztó lassú kódot írni.

A "tobb szalon vagy hogyan fut" kérdésedre a megoldást az into_par_iter() adja, amely a rayon és általa berántott rayon_core -ban található.
Hogy mi az implementációbeli eltérés a Go és a Rust esetében, az jó kérdés. Az biztos, hogy ez a példa main-ból párhuzamosít (into_par_iter) és a párhuzamosan futó inner() ismét párhuzamosít.
Az eredményeket a végén egy inner-beli sum() illetve egy sorrendhelyesen eredményvektorrá való gyúrás adja.

Nem a synceles viszi el az idot, hanem a

Showing top 5 nodes out of 81
      flat  flat%   sum%        cum   cum%
     0.02s  0.06%  0.06%     22.50s 67.93%  runtime.systemstack
         0     0%  0.06%     21.45s 64.76%  runtime.gcBgMarkWorker.func2
     2.97s  8.97%  9.03%     21.45s 64.76%  runtime.gcDrain
     0.03s 0.091%  9.12%     14.47s 43.69%  runtime.gcBgMarkWorker
     0.04s  0.12%  9.24%      9.59s 28.96%  runtime.(*gcWork).balance

A Garbage collection. Leven a benchmark app-nak tok felelsleges a GC, ezert ki kell kapcsolni

#time ./main 20
stretch tree of depth 21         check: 4194303
./main 20  35.30s user 2.44s system 363% cpu 10.394 total

#time GOGC=off ./main 20
stretch tree of depth 21         check: 4194303
GOGC=off ./main 20  8.76s user 1.58s system 98% cpu 10.453 total

:D

Én végigcsináltam egy Go traininget, és emiatt már nem tudok rá C-szerű nyelvként gondolni. Teljesen más a kettő, teljesen más felfogás kell hozzá. C-hez kb annyi köze van, hogy mindkettőben vannak változók.

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Szerintem sokszor nem azert tanulnak az emberek egy uj nyelvet mert jo vagy trendi, hanem mert csak abban lehet megcsinalni amit kell. Mert go kell a kubernetres-hez meg docker-hez, helm-hez, mert python kell a behave-hez, robot-hoz, vagy groovy kell a Jenkins-hez. stb ... Ami nem jelenti azt, hogy barmi mashoz is azt hasznalnam.

A Go a Tiobe indexen úgy ér el sikereket, hogy azt nem támasztja alá semmi. Ezzel a vélelemmell és úgy általában a Tiobe index tisztaságával kapcsolatban már született egy-két szösszenet. Az index tehát -feltételezhetően- manipulált.  Ebből következően én hajlamos vagyok úgy tekinteni a Google Go-jára, ahogy a Microsoft C sharpjára. Ez is az is egy erőltetett, túlhype-olt nyelv. 

Csupán annyi a probléma, hogy nincs olyan, hogy legjobb nyelv, meg szar nyelv. Problémák vannak és annak megoldására egyik vagy másik nyelv mennyire jó. A maga idejében, arra amire kitalálták a Pascal is jó volt. Másra meg nagyon rossz. Eljárt felette az idő, és azok amikre tervezve lett, ma már nem szempont. Ezért nem húzhatsz le egy szakembert, mert annó nagyon régen csinált egy nyelvet, ami mára már nem népszerű a fentebb említett okoknál fogva.

Anno a Borland Turbo Pascal-ja a DOS-os időkben az egyik legelterjedtebb programozási nyelv volt. És a maga idejében a legjobb. Kb. ugyanolyan kódot tudott csinálni mint egy C++ (sebességben), viszont a fordítási ideje töredéke volt a korabeli C++ fordítóknak. És ez még egy 40Mhz-es 386SX-en sem volt mindegy, nem egy 8 Mhz-es XT-n, 20 megás MFM winchesterrel.

Ugyanez igaz a Delphire is: anno amire kitalálták zseniális cucc volt. Windows desktopra fejleszteni nem volt jobb: egy a maga korában kiváló RAD tool, amivel tizedannyi idő alatt meg tudtál csinálni egy UI-t mint mondjuk C++-ban MFC-vel, ráadásul a Visual Basic-kel ellentétben e mögött egy átgondolt, fasza kis programnyelv volt, nem egy tákolmány.

Alapvetően csak két baj volt vele: egyrészt a Borland menedzsmentje nagyjából a Delphi megjelenése óta egy nagy rakás idióta volt, másrészt kezdők oktatására használták, ami miatt sok kezdőt elriasztottak vele. A Pascal-t ugyan eredetileg oktatási célra szánták, de alapvetően programozók oktatására. Ma viszont lassan már a vízvezeték szerelőt is programozni tanítják, arra viszont már az eredeti Pascal sem lett volna túl jó, nem egy Object Pascal.

Anno a Borland Turbo Pascal-ja a DOS-os időkben az egyik legelterjedtebb programozási nyelv volt.

Nosztalgikus könnycsepp a szemem sarkában :)

 

másrészt kezdők oktatására használták, ami miatt sok kezdőt elriasztottak vele

Ezt a Delphi-re írtad, de a Pascalra is igaz olyan tekintetben, hogy "illett" továbblépni róla C-re, "mert a Pascal a kezdők nyelve" és onnantól kínos volt. (Elég sok életrajzot olvastam, hogy "C fejlesztői gyakorlat" de pofára kb. egy void main() -t se tudna nagy biztonsággal leírni.)

Legalábbis oprendszer felett van visszatérő érték.

$ cat /etc/fstab >/dev/null; echo $?
0

$ cat /etc/nincsilyen >/dev/null; echo $?
cat: /etc/nincsilyen: Nincs ilyen fájl vagy könyvtár
1

Tehát a return alapból fontos, hiszen a program jelzi a szkriptnek, hogy normálisan lefutott vagy bármit. Érdekesség, hogy a shell csak 8 bitet vesz át.

// teszt.c 
int main() {
   return 0x7ffffffe;
}

$ ./teszt; echo $?
254

Viszont mikrovezérlős környezetben, ahol nincs oprendszer, gyakori a void main(), hiszen nincs hova visszatérő értékkel visszatérjen.

Nem nagyon kell azt eroltetni, egyszeruen rakas szempontbol idealis a nyelv. Pl Jol olvashato, sztandardizalt nyelv. Pl az automatikus interface implementalasnak koszonhetoen baromi konnyu a solid elveket kovetni. Vagy emllithetnem a defer-t, vagy hogy functions are first class citizens, statikusan es erosen tipusos. Azaz konnyen karbantarthato kodot lehet benne irni. Pofon egyszeruen lehet benne cross compileolni, es az a single binaryt be lehet mondjuk tenni egy scratch kontenerbe. A konkurrencia modelljevel eleg egyszeru benne tobb szalon vegezni muveleteket. Managed nyelv, ami szinten gyorsitja es egyszerusiti a fejlesztest es tesztelest. A beepitett utemezo egyszeruen zsenialis, millios szamokkal is mukodik, sokkal kevesebb context switch, es kevesebb felelsleges felebresztes. A bepitett parancssori eszkozok baromi kenyelmesse teszik a hasznalatat (a modulest szokni kell, a rossz ertelemben), formazas, refactor. Beepitett race condition detektor van benne ami nagyban csokkenti a tesztelesi idot.

Szoval nem ertem miert kene ezt eroltetni? Itt van ez a devops meg microservices vilag ami 1000-el duborog, es keves masik nyelv van, amivel ennyire hatekonyan lehet rendszer-kozeli es multi platformos kodot irni es karbantartani. Most nezzuk miben kene devops, network meg ms-t fejleszteni (azert ezt hozom fel peldanak, mert itt durva az elterjedese):

Most erted C? Hat rendszer kozelit oke, de enterprise microservicet?

Python, meg talan a legeselyesebb.

Kotlin, Java, C# meg a rendszer-kozeliseg, na hagyjuk.

Typescript :) meg az R :D

Rust, nincs kodolasi tapasztalatom nem tudok nyilatkozni, tippre eselyes.

Haskell? Akkor mar Brainfuck wagy whitspace is lehetne :D

Netan Swift?

Tudom szamtalan nyelv van meg, es azt sem mondom, hogy mindenre jo megoldas a Go. De tortenetesen amire tulnyomo reszt hasznaljak arra pont rohadt jo es hatekony.

Sokat hallom ezeket a buzzwordöket, de pl Java-ban lehet használni primitív változókat, azért se teszik a fejéhez a pisztolyt ha nem teljesen OO a kód és nem hiszem el, hogy egy új programnyelvvel biztos jobb lesz a kód, bármilyen új paradigmát támogat/követel, miközben egy már az adott ember által jól kiismeri eszközt hatékonyan tud használni. Pont az a baj, hogy nincs már idő kiismerni egy nyelvet és hatékonyan megtanulni használni, hanem menni kell a divat után.

Amúgy a Rust nekem is szimpi, mert drága GC nélkül megoldja azt, amit a Java csak drágán. Ugyanakkor ha nem felejtjük el, hogy a JVM valódi vason fut, akkor sokmindenhez nyújt stabil és gyors alapokat.

"Sokat hallom ezeket a buzzwordöket" Pontosan melyiket tartod annak, es miert?

"pl Java-ban lehet használni primitív változókat" ezt oszinten nm ertem hogy jon ide. 

"új programnyelvvel biztos jobb lesz a kód, bármilyen új paradigmát támogat/követel" nem az ujsaga miatt lesz jobb (bar en olvashatobb es karbantarthatobbat irtam), hanem a Go azert lesz olvashatobb, mert letisztultabb, egyszerubb, es nincs agyonnyomva featurrel, raadasu legy kutya kozonseges proceduralis nyelv

"Pont az a baj, hogy nincs már idő kiismerni egy nyelvet és hatékonyan megtanulni használni, hanem menni kell a divat után" Hat nem tudom en 8-9 evet fejlesztettem Javaban, es idestova 6 eve lattam meg a Goban a lehetoseget. Felkeltette az erdeklodesem, megszerettem a fent felsorolt dolgok miatt pl. Mikozben az is latszott, hogy hamarosan elterjedt lesz ez a nyelv mint az allat. Szoval eleg jol kiismertem (nyilvan mindig lehet fejlodni), sehova nem hajtott a tatar, es koszi jol el vagyok vele, es nem mellesleg jol is hoz a konyhara. Meg amit irtam, azokat valos projekteken szerzett tapasztalatbol mondom, meg lassan 20 ev tapasztalattal a hatam mogott.

Amiket írtál, kijön egy új nyelv, ugyanazt, vagy kicsit mást új névvel látnak el, vagy pl defer, azt is meg lehet oldani Java-ban is. A rendszerközeliségen akkor mást értettem. Csak azt akartam írni, hogy nem kell mindenhez pl objektum.

6 éve megjelent egy halom másik nyelv is, viszont a Java is sokat fejlődött, amit le is követek, még ha hákolásnak is tartod, de mivel egyszemélyes csapatként nincs időm nulláról indulni egy divatos új nyelvvel, inkább kívárok, melyik lesz tényleg kiforrott és még szimpatikus is, minthogy én bétateszteljem a nyelvet. A GC-n is lehet vitatkozni, de az a fő, hogy nem mindig szerencsés, ha miatta megáll a világ. Látom, hogy a Java leáldozóban, azt is tudom, nincs ingyenebéd, Ha most váltani kellene még ott a C#, ha később és nem hal el, akkor meg a Rust.

"defer, azt is meg lehet oldani Java-ban is" hirtelen az jutna eszembe, hogy finallyval meg lehetne csinálni.

"még ha hákolásnak is tartod" nem en tartom hakolasnak, valamit félreértettel.

"nincs időm nulláról indulni egy divatos új nyelvve" kevesen tanulnak uj programozási nyelvet munkaidőben (velem konkrétan egyszer fordult elo, objective-c-t egy tanultam), erdeklodesbol tanuljak legtöbben, es amikor mar van használható tudás (a Go tanulási gorbeje elég lapos, leven kutya kozonseges proceduralis nyelv), akkor bevetik élesben. Amúgy is pár évente érdemes uj nyelvet tanulni. En poénból is szoktam nyelvet tanulni.

"melyik lesz tényleg kiforrott" define kiforrott, azért Go-ban egész komoly rendszerek is vannak, mint referencia project. Szóval nem mondanám kiforratlannak, nyilván nem csillio eves nyelv mint a java, de ott meg pl pont az ellenkezője folyik. Kiforrott volt, most meg toljak bele a featuret 1000el

"minthogy én bétateszteljem a nyelvet" Ez jogos, de ezen a Go mar túllépett asszem. 

"nem mindig szerencsés, ha miatta megáll a világ" ott nem érdemes hasznalni ;)

"most váltani kellene még ott a C#" en tuti nem esnek csoborbol vodorbe :D

"mert drága GC nélkül megoldja azt, amit a Java csak drágán" Az gondolom megvan, hogy a Rustos program sem ingyen kezeli a memoriat, csak nem batchekben csinalja, hanem folyamatosan, ezert nincs pause time. Altalaban nem a GC a draga, hanem a stop the world.

De en is tudok ilyennel vagdalkozni: Funkcio hivasnal vagy lemondasz az ownershiprol, es a valtozodat nem hasznalhatod tovabb az eredeti funkcioban, ami egy eleg nagy limitacio, vagy beindul a memoria masolgatas nagy uzemben. Na az milyen draga, ha sok az adat!

Egy microservice-nek ami tipikusan egy VM tetején futó konténerben fut, nem tudom mi a fenéért kellene rendszer-közelinek lenni. Az a kernel driver amihez ez kell. Nem mellesleg nem tudom miért gondolod a pythont rendszerközelebbinek mint a C#-ot, a javát, vagy a typescriptet.

Ami pedig az átláthatóságot illeti, a Go-ban pont a legkevésbé átlátható C-s indentation style van a szintaxis szintjére emelve. Ráadásul kimondottan agyhalott  logikával: ha egy nyelv sor alapú, mint mondjuk a python akkor rendben van hogy megmondja hogy mi kerüljön egy sorba - de akkor mi a fenének kell neki kapcsos zárójel ? Ha meg blokk alapú mint a C alapú nyelvek vagy a Pascal, akkor mi köze van neki ahhoz, hogy hova teszem a blokk határolókat ?

"mi a fenéért kellene rendszer-közelinek lenni" nem kell. De ha megtanulod a Go-t, akkor abban tudsz rendszerkozeli fejleszteseket csinalni, meg tudsz kontener orchestrationt is irni, mint ahogy a pelda is mutatja, es akkor mar akar a microserviceidet is megtudod benne irni, esetleg CLI toolt, es na bumm. Egy szem programozasi nyelvvel tudod az egesz platformot fejleszteni, hagy ne reszletezzem ez miert jo mind munkavallalo mind munkaado oldalrol.

"a pythont rendszerközelebbinek" mert abban szoktak ilyen problemakat megoldani, ellentetben a nyelvekkel, amiket emlitettel.

"style van a szintaxis szintjére emelve" rohadtul nincs a szintaxis szintjere emelve, te valami masik mozit nezel. Van beepitett formazo, ami egyseges formara hozza az egesz forras kodot, ha ugy akarod, de egyaltalan nem kotelezo hasznalni. Persze erdemes, es akkor jobban hasonlitanak a kodok egymasra, es a minta kereso emberi agy konnyebben megerti.

De ha megtanulod a Go-t, akkor abban tudsz rendszerkozeli fejleszteseket csinalni, meg tudsz kontener orchestrationt is irni, mint ahogy a pelda is mutatja, es akkor mar akar a microserviceidet is megtudod benne irni, esetleg CLI toolt, es na bumm. Egy szem programozasi nyelvvel tudod az egesz platformot fejleszteni, hagy ne reszletezzem ez miert jo mind munkavallalo mind munkaado oldalrol.

Akkor a sima C a legjobb programnyelv a világon, mert abban akár kernelt is tudsz írni. Csodálom, hogy a bankok és a webfejlesztők még nem cuppantak rá...

rohadtul nincs a szintaxis szintjere emelve, te valami masik mozit nezel.

Jó, akkor próbáld meg ezt lefordítani. A lényeg a main() után új sorba tett nyitó kapcsos zárójel...

package main
import "fmt"

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

"Akkor a sima C a legjobb programnyelv a világon, mert abban akár kernelt is tudsz írni." (Go-ban is lehet pont most publikalt valaki valami microkernelt.) Igen C-ben meg kernelt is lehet. De akkor mar jobb az Assembly nem? Amit abban nem lehet megirni azt nem lehet megirni :D De itt jon kepbe az a rakas tulajdonsag, amit felsoroltam, ami miatt sokkal hatekonyabban lehet benne fejleszteni mint C-ben. Es tuti van egy rakas dolog, amit C-ben meg lehet csinlani (vagy jobban csinalni), pl parhuzamos feldolgozas. Goban nem lehet. De ezek a ritkabb kivetel, De cserebe meg olcsobb fejleszteni es karbantartani. Es vannak limitaciok, nem is tudom melyik ceg rajott, hogzy GC van benne es pause timeok vannak. Es mennyivel jobb a Rust, mert abban meg tudtak oldani. De ez nem a nyelv hibaja, az a GC ott volt benne akkor is amikor elkezdtek fejleszteni. De van az a terulet, ahol meg fenyevekkel jobb mint mas nyelvek, es ez most tortenetesen az a terulet, ami a csapbol is folyik, devops, sw defined network, kontenerizacio, sidecar-ok meg microservicek.

Es egyaltalan nem kotelezo hasznalni. Ez benne a jo! En ezen a teruleten mozgok; kube operatorokat fargok, halozat konfiguraciot automatizalok, ms-eket irok. Es baromi kenyelmes, Egyszeruen meg tudom benne foglalmazni a problemaimat, konnyebben tudom reviewzni. A vegeredmenyt konnyen tudom kontenerizalni, es eleg hatekony kodot general a fordito. Az a baj, hogy nehezen vagyok meggyozheto az ellenkezojerol, mert evek ota nemzetkozi csapatokban dolgozom, es tudom, hogy mier szeretjuk. (es azt is miert nem, pl a gomudules-tol nagyjabol mindeki kivan)

Jah es nem a Go az egyetlen nyelv, amit kiprobaltam. Ezekkel a nyelvekkel szallitottam projekteket: Java, Go, PHP, Bash, Javascript, Groovy, Python, Action Script, Laszlo Script, Objective-C

 

"Jó, akkor próbáld meg ezt lefordítani"ok, i see. Bevallom eszembe sem jutott igy irni, soha, semilyen nyelven, szoval ez nem tunt fel. Vannak meg ilyenek, mert az altalam felsorolt ervek sulyahoz kepest, azthiszem ezt nehez ertelmeznem komoly ellenervkent. De ertem, hogy teged ez zavar. Komolydolog, es most nem szarkazmusbol, engem is rohadtul zavarna, ha sortoressel kene irnom ;)

Arra, hogy semilyen kontrolod nincs, hogy mikor melyik go rutin fut, mert a runtime befoglal maganak valamennyi os threadet fixen, es arra elkezdi utemezni a rutinokat. Szoval nem igazan tusz garantaltan parhuzamos szalakat futtatni. (Ugy mondanam "labor" korulmenyek kozott eloidezheto, nem tul rugalmas raadasul a runtime configot is az alkalmazas melle kell csomagolni). Ahogy a Rob fogalmaz "Parallelism is about doing lots of things at once". A Go inkabb konkurrens vegrehajtasra van kitalalva (nem parhuzamos feldolgozasra), ahol az egyes feladatok "triggerelik" a kovetkezot. Channeleken hallgatoznak jobbra-balra (van mutex de erosen kerulendo). Ezert is nagyon hatekony az utemezoje, es kivalo pl Kubernetes fejlesztesre, ahol kismillio dolog tortenik egyszerre, vagy microservicenek, ahol szazezer szam jonnek a keresek.

"akkor próbáld meg ezt lefordítani"

Amugy a Go egyebkent is tele van megszoritasokkal, nem hasznalt valtozo, import, vagy, hogy utolso elem utan kotelezo a vesszo. Ezen az elven az is minek? A nyelv egyik elonye, hogy minden Go kod a leheto legegysegesebben nez ki. Es formazas utan a bajusz ugyis felkerul a helyere, ahova a Goban kell neki lennie. Pont. ... pont, annak ott van a helye.

Rohadtul nincs ott. A C++-ban egy rakás kódolási konvenció van. Ez az egyik legelterjedtebb, de egyben a leglogikátlanabb, és legkevésbé átlátható. Ráadásul maga a dolog is logikátlan, mert ennyi erővel elhagyható is lenne. Ha valóban ennyire kötött formázást akartak, akkor csinálhatták volna tab-bal a blokkokat mint a pythonban, és akkor legalább gépelni is kevesebbet kell. Ez egy amatőr csóka hobbiprojektje amit a guglinál felkaptak, aztán jól el is engedtek mert végül a darts lett náluk a nyerő (lásd flutter).

Elegge parttalan ez a vita. En probalok szakmai szinten ervelni mi a jo a Goban, hogy miert alkalmas ilyen-olyan jellegu problemak megoldasara. Te pedig rudozol egy felelsleges bajusz irason. Elmondom, ha elkezded komolyan hasznalni lesz meg 10 olyan dolog, amire azt mondod, hogy agyfasz. Tovabbmegyek, ha hasznalsz egy nyelvet es nem tudsz kapasbol 5 olyan dolgot mondani, ami egy kalap szar, akkor nagy valoszinuseggel kezdo vagy, vagy nem szakmai alapon szereted azt a nyelvet, hanem valami fanboy/girl vagy. Szoval en ertem amit mondasz (meg ha a gyakorlatban ez nem egy letezo problema is, hiszen a Go standard az az, hogy sor vegen van), de jo lenne ha azokra is reflektalnal, amiket en is leirtam, mert ez igy nem egy beszelgetes, hanem te is szajkozod a magad dolgat, meg en is. A kettonk kozott az a kulonbseg, hogy te egy durcas kisgyerek szintjen, aki nem kapott a szines nyalokabol. Koszike

o oregem, ez eljutott a beka segge ala.

nagyjabol ez harmadik website az elmult 2 hetben, ahol nekiugrasz ennek a threadet. a forgatokonyv mindig ua, nagyon nagy lendulettel nekiugrasz a gonak, jon par tobb nyelveben is jartas, goban is aktivan fejleszto kompetens arc, aztan a vegen laikusok szamara is jol lathatoan kiutkozik a hozza nem ertesed. nem vitatom, lehet, hogy te amugy mas nyelvben igazi guru vagy, de itt errol nem sikerult meggyoznod senkit, es a stilust meg figyelmen kivul is hagytam. a vegen, az ervek elfogyasa utan pedig rob pike egy amator csoka lett - szenzacios ervrendszer. :)

ez az uccso mondtad viszont az, ahol a hozza nem ertest kiterjesztetted a go-n kivulre is. egyreszt got nagyon ne engette el a google (forrast inkabb nem kerek toled, nem akarlak zavarba hozni), masreszt sokkal inkabb a dart volt amit elengedtek, es hosszu evekig tetszhalott allapotban tartottak, hogy aztan egy jol dokumentalt veletlen folytan a flutterben ujra feltamasszak, teljesen ujrapozicionalva azt. a dart fejlodesenek immar az elsodleges iranya a flutter, annak van alarendelve, igy az semmilyen formaban nem osszehasonlithato a goval, nem hogy mint a go konkurenciaja. az mar csak hab a tortan, hogy erre "amator hobbi projectre" eputkezik egy tonna dolog a linux foundation egisze alatt, a teljes cloud native vilag erre epul. es a teljes nem tulzas, egyszer nezd meg az okoszisztemat a kubernetestol, a dockerig, hogy csak a zaszlos hajokat emlitsem.

szerintem kar elvinni a nyelvi elfogultsag iranyaba a temat. nem tortenik mas, mint fragmentalodik a nyelvi terkep, az egyes celteruletekre keszult es ezaltal ott jobb nyelvek pedig kannibalizaljak a nagy svajcibicska nyelveket, aka java.

Vágyik rá a fene.

Lógok a szeren (K. Frigyes)

Lógok az ereszen (Sz. József)

Nekem mindig egy kérdés jut eszembe ezekről az új nyelvekről: Mi a helyzet a 3rd party library-kel? Nem hiszem, hogy lenne annyi belőlük, mint mondjuk C/C++-hoz vagy Java-hoz. Vagy ezek is olyanok, mint mondjuk egy shell script, elég egyszerűek ahhoz, hogy ne kelljen külső könyvtárakat használni?

Igen, meg lehet csinálni akár C-ben, sőt akár assembly-ben is. Kérdés hogy mennyi energia befektetéssel (= jelentős plusz fejleszői költség) és milyen arányban maradnak benne hibák (segfault, nem kívánt strukrúra túlírás és internetes alkalmazásnál biztonsági rés). Ezért próbálunk sokan menekülni a C-től ahol lehet, csak nem volt rendszerprogramozás terén 10 éve még hova. A C++ pedig a C-s öröksége miatt áldás és átok is.

Én inkább a még alaposabb védőhálót kínáló Rust-ról tudok nyilatkozni, de a nagy része a Go-ra is érvényes. Amit ad a C-hez képest:
    - https://prataprc.github.io/media/rust-over-c/rustvsc.png
    - kiemelném a memóriabiztonságot (Go esetén is). Elég egyszer kevesebb RAM-ot allokálni vagy a felszabadítást korán elvégezni és készen van a biztonsági rés. Ha meg elfelejted a ciklusban valahol felszabadítani, akkor a folyamatos futása felzabálja a memóriát. És ha te nem is hibázól, az utcáról felvett másik 10 csapattag által bele fog kerülni legalább 1 biztonsági rés. Viszont ha van védőháló, akkor ZÉRÓ allokációs hiba.
    - kész modulok saját közösségi repóból. Megbízhatóbbak egy noname internetes oldalnál. Sőt:

$ cargo check
  Downloaded itertools v0.9.0
  Downloaded 1 crate (96.4 KB) in 1.15s
    Finished dev [unoptimized + debuginfo] target(s) in 1.19s

Ellenőrzi, hogy éppen ebben a projektben felhasznált külső "itertools" csomagból az itt éppen használt 0.9-es verzióra van-e bugreport.

Visszatérve a C és Rust (vagy Go) integrációra. Itt nem csak kész lib-be tudsz belehívni, hanem C forráskódot is egybe tudsz hozzáfordítani. Végülis a Firefox is így íródik jelenleg. A meglevő kódbázisba szivárog be egyre nagyobb arányú Rust kód. A Linux kernel esetén is ilyen tervek vannak. A C++-t Linus nem engedte, a Rust-ra viszont nyitottságot mutat.

Ezt nem tudtam, hogy a C++-t nem engedte Linus, de nagyon jól tette. Be is dőlt volna a Linux project, ha abba beteszi a lábát a C++.

Mondjuk az említett memory leak elleni védelmen biztosan kell lennie másnak is a Rust-ban, ami hasznos. (Nem tudom, nem ismerem, csak tippelek.) Ugyanis pont a kernelben nincs malloc.

Igen, a kernelnél nem támaszkodhatunk a userspace-beli frankó libc függvényekre. Viszont van a kernelnek saját kmalloc/kfree megoldása: https://www.kernel.org/doc/htmldocs/kernel-api/mm.html
Rust esetén a standard memory allocator-t le kell cserélni hogy ezekkel operáljon, de szerencsére engedi: https://doc.rust-lang.org/std/alloc/

Megjegyzem, mikrovezérlő programozásnál szintén nincs lehetőség a Linux userspace-ben alkalmazott megoldásra, hiszen se Linux se userspace. Szerencsére például a cortex_m_rt csomag gondoskodik erről.

_z kérdésére, miszerint C-ben is meg lehet mindent írni, álljon itt egy rögtönzött Rust példa: jelszó teszt adathalmaz generálás.
C-ben feltételezem hogy jól tudsz programozni. Átgondolva megérted, mennyivel több munka (~fejlesztői költség) C-ben ugyanez.

Köszi. A Go-ról még én nem tudok sokat, jól jön nekem ez a példa.
Látom a C-hez képest sok védőháló van ebben is. Alaposan odafigyel a típushelyességre, így az alábbi C hiba sem marad rejtve:

#include <stdio.h>

int main() {
    float a = 1./3.;

    int b = 4./a;
    printf("4 / (1/3) = %d\n", b);
}

Tizedes pont nélkül 4/a -ként jó eredményt ad. Viszont se a Go, se a Rust nem engedi ezt ilyen rejtőzködően megbújni.

Rust esetén a másik nagy húzás szerintem az iterátorok (láthattál közüle az előző példában is): https://doc.rust-lang.org/std/iter/trait.Iterator.html
Az iterátorokat én a Pythonban szerettem meg és nagyon megörültem, hogy itt is van.
Erre is dobok egy alap példát: https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gi…

Az túlzás, hogy vágynék rá, de a Go engem is érdekelne, lehet egyszer rávesz a lélek, hogy megtanuljam. Sose néztem még rá magára a nyelvre, pedig sokan dicsérik, igaz ez lehet csak szimpla hájp is.

A listáról még a Haskell érdekelne, ezzel próbálkoztam, de képtelen vagyok felfogni ezt a funkcionális programozást, valahogy nem áll rá az agyam. Meg esetleg a Lua lenne hasznos, mert elég sok minden használja, de erre sem vitt még rá a lélek, hogy megtanuljam. A listában lévő többi nyelv viszont nem is izgat, még egy kicsit se, vagy azért, mert már ismerem, vagy mert csak egyszerűen nem érdekel. Jó, talán még a Pythonban merülhetnék el jobban, igaz azt már ismerem, elkezdtem matekozáshoz használni, de csak szimpla számításokra, nem fejlesztek benne semmi komolyat, maga a nyelv sem nagyon tetszik.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)