A FreshTracks.io a Cloud Native Computing Foundation számos nagyszerű eszközét használja, aminek köszönhetően elkezdtem olvasni és írni a go code-ot. Ez a cikk a nyelvi és fejlesztői környezettel kapcsolatos első benyomásaimat írja le.
Tucatnyi gyártási kódot írtam a C-től a Javascript-ig, így jó mennyiségű összehasonlító anyagom van, de viszonylag újonc vagyok, szóval figyelem, talán hiányzik néhány részlet. Ez lefedi azokat a kiemeléseket és gyenge pontokat, amelyekkel eddig találkoztam.
A szép részek
A zsíros binárisok nagyszerűek. Szeretnéd futtatni a go programomat? Töltse le egyetlen fájlt, és futtassa. Nincs futásidejű letöltés, env-beállítás vagy függőségek, amelyeket meg kell ragadni, és nincsenek verzióproblémák.
Golang gyors. A „benchmarkok” azt mutatják, hogy a legtöbb feladat esetében a sebesség megközelíti a C++-t, és sokkal gyorsabb, mint a magasabb szintű dinamikus nyelvek.
Golang biztonságosabb. Nincs szüksége minden bőbeszédű és törékeny határellenőrző és érvényesítő kódra, mint például a C/C++, és a különböző párhuzamossági minták csökkenthetik a többszálas bonyolultságot (talán).
A fejlesztői eszközök egyszerűek és a dobozból kivehetőek. Az egységtesztelés beépített, és a tesztek szabványos kódot használnak az assert könyvtár helyett. A fordító szupergyors, amit addig alul kell értékelni, amíg vissza nem tér egy lassabb felépítési folyamatú platformhoz.
A kód formázása, szöszmélése és hibakeresése a vscode-ban fájdalommentes. Nem próbáltam más IDE-t, mert a vscode nagyszerűen működik, és egyetlen bővítmény telepítésével konfigurálható.
A Golang olyan magas szintű funkciókat támogat, mint a lezárások és a szelet szintaxis. Ezek a funkciók a Javascript és a Python fejlesztői számára második természetűek, jó, hogy itt vannak.
Az objektumok egyszerűek. Ahelyett, hogy támogatná az osztályokat vagy az öröklődést, a fájdalom forrását sok nyelvben, a golang csak a függvények struktúrákhoz való kötését teszi lehetővé. Mindkét világ legjobbja, egyszerű és szemantikus.
Van egy csomó hasznos kis rög, mint például az "automatikus hivatkozás a választó kifejezésekben", a "többszöri visszatérési érték" és a "struct beágyazás", amelyek kevésbé bőbeszédűvé teszik a kódot.
A típusrendszer
A golang típusú rendszer egyszerűsége üdítő. Jól működik és pontosan úgy, ahogy elvárnád. Az általánosságok hiánya megnehezíti az egyéni adatstruktúrák kódolását, de a golang beépített adattípusai elegendőek a legtöbb feladathoz.
Hiányolom a magasabb rendű funkciókat, mint a map és a redukció, amiket nem lehet könnyen definiálni generikumok nélkül, de úgy gondolom, hogy a fejlesztőcsapat jól döntött, amikor az egyszerűséget és a biztonságot választotta a típusrendszer fő céljaként.
Memóriakezelés
A memóriakezelés a golangban rendkívül rugalmas. A fejlesztők szeleteket és térképeket hozhatnak létre, valamint dinamikusan adhatnak hozzá és távolíthatnak el elemeket, és a golang kitalálja, mint egy magasabb szintű nyelvet, de a fejlesztők választhatnak fix méretű tömbök és struktúrák használatát is a memória gondosabb kezeléséhez, ha szükséges.
Olvastam néhány memóriarészletről, amelyek hibakeresése bonyolult lehet a memóriaoptimalizálás során, mint például a „menekülési elemzés, amely a változókat váratlanul lefoglalja a kupacban”, de úgy tűnik, hogy a memóriakezelés a legtöbb használati esetre elegendő. Fokozott odafigyelésre lehet szükség, ha a memória szűk keresztmetszetű alkalmazásához C szintű vezérlést vár, de a golang tonna vezérlést kínál a magasabb szintű nyelvekhez, például a Java-hoz képest.
Jellemzők, amiket hiányolok
Határozottan hiányolom a tartós megváltoztathatatlan adatstruktúrákat, mint amilyenek a Clojure-ban és az Immutable.js-ben találhatók. A Golang kód általában mutációdús, sok tisztátalan funkcióval, és ez megnehezíti a hibakeresést és a mutációk helyének nyomon követését. Sajnos az általános típusok hiánya megnehezíti egy 3rd party megváltoztathatatlan lib megírását.
Golangból hiányzik a tisztességes függőségkezelés. Még mindig nem jöttem rá teljesen a mechanikára, de ha go get egy függőséget, azt hiszem, az letölti master és beilleszti a GOPATH-ba, tehát minden go projektje ennek a függőségnek ugyanazt, nem nyilvánvalóan meghatározott verzióját használja. Vannak harmadik féltől származó megoldások, de a közösség még nem hozott határozott döntéseket a legjobb megoldást illetően.
A harmadik féltől származó könyvtárak választéka nem olyan nagy, mint más platformokon. A talált libek mennyisége sokkal kisebb, mint a Java, a Python vagy a Javascript. Például a Google még nem támogatja a teljes funkcionalitású "TensorFlow" könyvtárat, és nehezen találtam egy jól támogatott és aktívan karbantartott "GraphQL" implementációt.
Szeretném, ha a Golang fájlszintű változó hatókört használna. A Golang ehelyett „csomag” változó hatókört használ, amely több fájlra is kiterjedhet. Látja, hogy a változókat egy fájlban éri el, de deklarációjuk és/vagy példányosításuk el van rejtve egy másik fájlban ugyanazon a csomagon belül. Az IDE-k segíthetnek itt, de továbbra is nehezen tudom elolvasni az ezt a mintát használó go kódot, különösen akkor, ha a változó több fájlban mutált, és double-extra-special amikor a változó hozzáférést szinkronizálni kell a go rutinok között több fájl között.
Amit még tanulok
A Golang hibakezelés zavaró. A dokumentumok azt javasolják, hogy a C stílusú hibakód a hasznos error típussal tér vissza, de a nyelv támogatja a panic-et is, ami egy kicsit kivétel, de valahogy más. Nem vagyok benne biztos, hogy mikor használjam az egyiket a másikkal szemben, de úgy gondolom, hogy a szokásos kivételek könnyebbek lennének a legtöbb használati esetre.
A Golang többféle módon is támogatja az adatok szinkronizálását a párhuzamos go-rutinok között. A Golang-dokumentumok azt állítják, hogy a channels a "legnagyobb dolog a szeletelt kenyér óta", de "egyesek nem értenek egyet". A valós go kód csatornák, megosztott memória + mutexek és bezárási visszahívások keverékét használja az adatok szinkronizálására a go-rutinok között. Még nem csináltam túl sok párhuzamos kódolást a go-val, de úgy tűnik, alaposan meg kell értened mindhárom paradigmát, azok teljesítménybeli vonatkozásait és kompromisszumait, mielőtt nekivágnál, különösen, ha olyan harmadik féltől származó libeket használsz, amelyek keverednek és illeszkednek. ezeket a stílusokat.
Még nem végeztem honosítást a go segítségével, de észrevettem, hogy a karakterláncok egyszerű bájttömbök, amelyek hasonlóak a Python 2x karakterláncaihoz, nem pedig olyan kódolt karaktersorozatok, mint a Python 3x, a Java vagy a Javascript. Ez megnehezítheti a lokalizáció megvalósítását, és kicsit jobban bele kell ásnom a problémába.
Következtetés
A Golangnak vannak kompromisszumai, mint minden kódoló platformnak. Az általam kedvelt darabok általában az „egyszerűbb, mint a többi platform” részei, a zavaró részek pedig általában olyan darabokhoz kapcsolódnak, amelyek úgy tűnik, mintha belesütötték volna a platformba, mielőtt teljesen kigondolták volna.
Összességében a golangot akkor ajánlom, ha biztonságosabb, barátságosabb C/C++-ra vagy egy egyszerűbb és gyorsabb, magas szintű alternatívára van szüksége, de fontolja meg más lehetőségek vizsgálatát, ha nagy, harmadik féltől származó könyvtárválasztékot szeretne, vagy olyan adatstruktúrákra van szüksége, amelyek nem állnak rendelkezésre a go szabványos könyvtárában. Remélem, hogy a hamarosan megjelenő golang v2 a fent említett alapvető területek fejlesztésére összpontosít, ahelyett, hogy egyszerűen új funkciókat adna hozzá, mert szeretném, ha a platform még jobban használható és használhatóbbá válna, miközben megtartja egyszerűségét és teljesítményét.
