JuJu átirat - A Go nyelv sikertörténete a Canonical-nél

Google

Dave Cheney, a Canonical egyik programozója egy, a Go nyelvvel kapcsolatos sikertörténetet osztott meg a Go programnyelv általános hírcsoportjában. Az elmúlt évben a Canonical programozói szorgosan dolgoztak azon, hogy portolják a JuJu-t (fenti videó) Python-ról Go-ra. A múlt héten megszületett az első nem kísérleti kiadás a Go-ba átírt JuJu-ból. Ez eddig körülbelül 109 000 sornyi Go kódot jelent eddig. A részletek itt.

Igen, csak a nem megfelelő eszköz és a nem tökéletes eszköz között hatalmas szakadék van. A Python egy elég jó nyelv ilyen feladatokra, és ebbe ölni rengeteg emberórát valahogy feleslegesnek tűnik, amikor annyi megoldadndó feladat van még.
----
India delenda est.
Hülye pelikán

az erősen tipusos nyelvek generics nélkül is jó ellenőrizhetőek forditási időben. generics csak egy pluszt ad.

pl. 1.5 előtti Java egy erősen tipusos nyelv, forditási időben sok tipushibára fény derül, komoly biztonságkritikus rendszereket épitettek rá, és nem volt benne generics.

mellesleg amég a generics kifejezetten a tipusellenőrzésről szól, a C++ template-ek ennél sokkal többek, nem csak a tipusbiztonságról szól.

Dave Cheney megválaszolta miért jó Go-ra váltaniuk, címszavakban:

* Statikus telepítés. Egy önálló binárisként telepíthető.
* Csatornák használata.
* Statikus típusozás.
* Fordítás sebessége.
* Multi platform.
* Szuper stabil Go 1.0 API

Részletek továbbra is itt.

( ispanov | 2013. 02. 12., k – 13:36 )

A Go talán legrosszabb nyelv ami a Google-től jött valaha. Még talán a Dart-nál is rosszabb, pedig ez nem kis szó! Elég jól ismerem a nyelvet, hogy tudjam milyen tervezési hibák vannak benne és mindig is reméltem, hogy hamar kihal. Eddig azt hittem ez így is lesz, mivel a TIOBE index top 50-ből is már kiesett egy ideje. Szomorú azt látni, hogy egy nagyobb projektet ebben készítenek.

Sajnos a Go nem fejlődik olyan ütemben mint kéne. Még mindig látszik rajta, hogy egy garázsprojektként kezdte. A kezdeti hiányosságokat még most sem foltozták be teljesen, például még mindig nincs rendes hibakezelés. A channelek és a jól integrált coroutionok viszont nagyon tetszenek benne és a típusrendszerben is van fantázia.

Most nincs időm részletesen kifejtenem mindent, de néhány dolgot azért összeszedtem ami szerintem rossz a nyelvben. Lehet, hogy pár dolog azóta már megváltozott, mert majdnem egy éve foglalkoztam vele utoljára.

1,
Nincsenek kivételek, helyette hagyományos C-szerű hibakezelés van. Lehet szeretni vagy nem szeretni a kivételeket, de az tény, hogy hibakezelésre sokkal inkább alkalmasak mint a visszatérési értékek. Főként a hatékonyság fokozása miatt hagyták ki, legalábbis ez a marketing szöveg. A hibakezelés másik módja a "defer - panic - recover" használata amit itt most nem fejtenék ki. Ez szerintem sokkal átláthatatlanabb mint a kivételek.

2,
Nincsenek templatek vagy genericek. Helyette vannak interfészek, de sokszor az implementáció algoritmusa azonos (csak a típusok különböznek) és azért copy-paste "technikával" íródnak, ami sérti az újrafelhasználhatóság elvét (vagy inkább a DRY (Don't repeat yourself) elvet). Arra nem nagyon van lehetőség, hogy egy generikus függvény írjál.

3,
A nyelvet eredetileg úgy reklámozták, hogy egy új rendszernyelv. Ennek ellenére rengeteg olyan NYELVI elemet tartalmaz, amely alkalmatlanná teszi ebből a szempontból. Például a nyelvbe integrálták a konkurenciát és az ehhez passzoló memóriamodellt ami jó akkor ha tényleg magas szintű dolgokat akarsz írni, de rossz ha alacsonyat, mert ezt nem lehet kikapcsolni. A másik a GC. Egy rendszernyelvbe egyszerűen nem való a GC. Ha lenne lehetőség a GC kikapcsolására akkor ezzel sem lenne gond, de sajnos nincs. Persze azon el lehetne vitatkozni, hogy mit is értünk rendszernyelv alatt, de általában a viszonylag alacsony szintű programozást támogató nyelveket szokták idesorolni mint például a C-t.

1) a hibakezelés tényleg nem az igazi

2) ezt nem teljesen értettem, nem igazán tudok hozzászólni

3) nekem inkább úgy tűnt, hogy middleware-jellegű szoftverek fejlesztéséhez ajánlották, és ehhez szerintem helyénvaló a beépített concurrency ill. GC megközelítés. De lehet, hogy félreértettem.

Egyébként nekem tetszik a Go (bár nincs komoly tapasztalatom benne), a duck typing jellegű interface-ek pl. nagyon hasznosak.

--
CyclonePHP

2,

Template vagy generic. Képzelj el egy olyan osztályt, ami listát reprezentál. Ha nincs
generic, akkor minden egyes típusra meg kell írnod (hozzáadás, törlés, keresés, stb.), vagy pedig egy közös őssel kell dolgoznod. Ha közös őssel dolgozol, akkor elveszik a fordítási szintű hibakezelés, mert ha mondjuk van B és C osztályom, mely A-ból származik, akkor mi van, ha egy olyan listát akarok, amiben csak B van, de véletlenül belerakok egy C-t. Ez csak futási időben fog kiderülni, ami pedig nagyon nem jó, mert akkor elcrash-el a programom.

ez tiszta, nekem inkább a "Helyette vannak interfészek, de sokszor az implementáció algoritmusa azonos (csak a típusok különböznek) és azért copy-paste "technikával" íródnak, ami sérti az újrafelhasználhatóság elvét (vagy inkább a DRY (Don't repeat yourself) elvet)." rész nem világos, hogy az interfészeknek mi közük a generikus hiányához.

amúgy köszi a választ :)

--
CyclonePHP