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

 ( trey | 2013. február 11., hétfő - 19:45 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

miért ez az átírás?

Canenical szokás
---
Ubuntu one tárhely: https://one.ubuntu.com/referrals/referee/1503/
Dropbox: http://db.tt/XMk0ssk

Nem szégyen váltani!
Ha valaki egyre képzettebb és rájön, hogy addig nem a megfelelő eszközt használta, vagy időközben lett egy jobb eszköz az adott problémára, akkor lehet és akár érdemes is váltani a jobb eszközre.

Persze, aztán ebből születnek az olyan szép sikertörténetek, mint a Duke Nukem Forever :D

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

py és go között egy lényeges különbség, hogy a go programban a tipushibák forditási időben kibuknak. ilyen alrendszernél elsorendű a magas szinvonalu megbizhatóság

py pont abban gyenge alapszinten, amire a go-t tervezték

Ennek ellenemond, h. nincsennek template-ek, nem?

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.

Talán a teljesítmény különbségek miatt lehet, esetleg a konkurrens programozás jobb támogatása miatt.
Remélhetőleg majd kiderül, hogy ténylegesen miért váltottak és mik a tapasztalataik!

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.

Pythonhoz képest ezek közül néhánynak nincs értelme, de biztos megérte.
----
India delenda est.
Hülye pelikán

A szuper stabil API-ra célzol? :)

--
Ingyenes Ubuntu One tárhely:
https://one.ubuntu.com/referrals/referee/170278/

Azt nem tudom, hogy a Go apija mennyire stabil, de az önálló bináris könnyen megoldható Python esetén is, a fordítás sebessége értelmezhetetlen, a multiplatform meg hát adott.
----
India delenda est.
Hülye pelikán

subscribe

És most Go! vagy Go nyelven írják újra? :)


Normális HUP-ot használok!

És mikor fog végre sapkákat árulni a Canonical?
http://store.teamfortress.com/itemdetails/92538067

+1 :D

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.

Fel tudnál sorolni pár hiányosságot? Sajnos nekem nem volt időm foglalkozni vele :-(
Pedig azt gondoltam, a Google-nál van pénz új technológiákat fejleszteni.

Fuszenecker_Róbert

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.

Hibakezeléshez: http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html

Ne vitatkozzon velem senki, még nem olvastam el, mert remélem, hogy valaki rávilágít a lényegére :D
----
India delenda est.
Hülye pelikán

Világos. Köszönöm.

Fuszenecker_Róbert

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.

Jaja. Plusz közös ős esetén bizonyos memóriamodellek ki vannak zárva: pl. az stl::vector memóriafoglalási design-ja.

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