Go - új, nyílt forrású, kísérleti programozási nyelv a Google-től

Programozás

A Google egy új, nyílt forrású, BSD licences programozási nyelvet jelentett be Go néven. Ahogy leírják: new, experimental, concurrent, garbage-collected systems language. Hangsúlyozzák a gyorsaságát:

A következő majd' egy órás videón Rob Pike beszél a Go-ról a Google Tech Talks keretén belül:

További részletek a Go-ról itt, itt és a projekt honlapján.

Én nem érzem a veszélyt. Kereső van sok, mégis a legtöbben ezt használják. Azért jó, hogy vannak versenytársak, mert a verseny kell!
A többi szolgáltatása közül is több elérhető másoktól is, ami meg nem, az nem lenne, ha a Google nem nyújtaná.
Ráadásul egyiket sem kötelező használni. Nyomás sincs, hogy használd, nem úgy mint az egyik másik monopol cég termékeire, amit még a magyar közbeszerzésben is nevesítenek.
Amíg a reklámokból él és nem is túl agresszívan tolja azokat az arcomba, addig nekem megfelel.
--
http://pc.rulz.hu
не закурить! (Ne gyújts rá!) не куриться! (Ne dohányozz! Ne füstölögj!)

ééértem! Esetünkben a fordító minden vele fordított kódba beletesz egy kiskaput, amit úgy rejtettek el a BSD kódban, hogy a kódrészlet Whitespace programnyelven van írva a BSD licencszöveg után! :)
People, beware of the Google!!!111 :)

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

értettem. Orwell 1984-re utaltál, és esetedben a Google a mindenhol ott lévő Nagy Testvér. Azt nem értettem, hogy jön ez egy programnyelvhez.
Az Orwellre való utalások lassan méltó kiegészítőjévé válnak Godwin törvényének :)
!s!s!s!

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

mégse biztos, hogy értetted, mert nem a programozáshoz van köze orwellnek. hanem ahhoz, amire írtam. és annak meg van köze az azt indukáló íráshoz. annak meg a fentebbihez. így viszont előbb utóbb el fogsz jutni ahhoz, hogy mégis csak kapcsolódik a programozáshoz. csak nem direkt úton.

--
xterm

kellő mélységig erőltetve az asszociácókat az is kihozható, hogy eme hozzászólásoddal az anyámat szidod, de ennek semmi értelme.
Tulajdonképpen pepo hozzászólása már offtopic volt, minthogy az, hogy a Google bejelent egy – kisebb vagy nagyobb innovációként ható – programnyelvet, annak semmi köze nincs ahhoz, hogy jobban a nyakunkra telepedne. Ami szintén igaz, csak a topictól független.

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

hol fáj?? amúgy azt hozol ki amit akarsz, nem akarlak meggyőzni semmiről. ha megfigyeled, a kérdéses hozzászólásom se neked ment ;)

amúgy pepó hozzászólása egyáltalán nem offtopic (mivel arra utalt, hogy "ezzel is". ebben a kontextusban az "ezzel" azt célozza, amiről a cikk szólt. ha a cikkre való reagálás offtopic, akkor baj van a fogalmakkal.

--
xterm

szerintem irracionális volna azt gondolni, hogy ha a Google egy mindenki által szabadon, online szolgáltatásainak igénybevétele nélkül használható dolgot dob piacra, akkor ezt saját aljas céljainak elérése érdekében teszi.
Tehát kénytelen voltam azt gondolni, hogy pepo úgy általában véve reagált a Google-re, ami épp annyira out of scope lenne, mint ha azt mondanám, hogy az internet jó dolog. Persze, lehet fújni rá a Nagy Testvér-komplexus meg hasonlók ürügyén, akár még megalapozott is lehetne – de jelen esethez szvsz semmi köze. 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Hát sztem pár év mulva a csapból is G fog folyni (vagy már most is ? ), a G lesz a fikázások célpontja mert visszaél a helyzetével, a G legújabb operációs rendszerét vesézik ki hívek és ellenhívek, még a kaputelefon is a G által fejlesztett és felügyelt szoftverrel fog működni, és csak akkor enged be, ha a cloudban tárolt életemben nem találtak semmi kivetnivalót (ha véletlen meg meghal a net, akkor ÍJ. -másszak be valahogyan) :D, a Microsoft meg elkezd terjedni underground berkekben :D :D

( saxus | 2009. 11. 11., sze – 15:26 )

Nem néztem meg az egy órás videót, mert dolgom van, de ezt átfutva már csak egy kérdésem van: miért?

----------------
Lvl86 Troll

Miért van 600 féle Linux terjesztés?
Az egyik ember miért bécsi keringőt táncol a másik meg miért breaket, a harmadik meg egyáltalán nem táncol. Nem ragozom tovább.
A java sem úgy indult, hogy világszerte elterjedt és sikeres lesz.
--
http://pc.rulz.hu
не закурить! (Ne gyújts rá!) не куриться! (Ne dohányozz! Ne füstölögj!)

En sem ertem hogy miert faj egyeseknek az, ha valaki csinal valamit. En sokkal tobbre ertekelem ezt, mintha forumon trollkodasra forditottak volna ugyanezt az idot.

Raadasul ugy vettem eszre, hogy a hozzaszolok tobbsege nem igazan vette figyelembe, hogy kik allnak a nyelv mogott.

Felteszem nem programfejlesztéssel keresed a napi betevőt.

A fordításra várás a fejlesztő szempontjából elvesztegetett idő. Minél gyorsabban fordul a cucc, annál hamarabb jön a visszajelzés, hogy van-e szintaktikai hiba, illetve annál hamarabb futtathatja a teszteket, és láthatja, hogy van-e egyéb hiba.

Kapcsolódó xkcd rajz, a techtalkban is szerepel.

Hat annyiban igazad van, hogy nem programozasbol elek csak neha amikor kell heggesztek ossze egy kis C kodot/modositok dolgokat amiknek tenyleg nem tobb mint 2M a forrassa de azoknal make egesz korrekten kitalalta, hogy mit kellett ujraforditani es mit nem. Bar lehet, hogy en csinaltam valamit rosszul.

Módosíts valami olyan headert, amit a fél világ beincludeol ;)

Ettől függetlenül azért nem mondanám, hogy egy kész program normál használata mellett olyan nagy érv lenne.

Másik: azt ugye látta mindenki, hogy a videón ~20 kisebb fájlt fordított le az emberke és nem egy linux kernel méretű dolgot? :)

----------------
Lvl86 Troll

Megszámoltam :-)
0,2 mp alatt fordította le a 21 fájlt és 8,5 mp alatt a 459 állományt.

Egyébként kipróbáltam én is a saját gépemen. 4 maggal Ondemand módban 8,7 mp, 4 maggal Performance módban 5,7mp alatt fordította a 459 állományt.

Szerk.: és ebben benne van körülbelül 50 könyvtárváltás (oda-vissza) és 50 make futtatás is + konzolra írás :-)

Ez tök igaz, viszont ez manapság már nem olyan nagy szám, mint ahogy azt itt előadták. Ok, a C, C++ kódokkal tényleg van ilyen gond, viszont Java-ban mivel nem kell az egészet lefordítani mindig egyszerre nincs ilyen gond, C# szintén, script nyelveket meg egyébként sem kell fordítani, ráadásul manapság eléggé elterjedtek(js, php, ruby, pyhton, perl...).
Szóval ez még nem egy killer feature.

Kedves "enpassant", azt írtad az imént, hogy "azoknál a nyelveknél a futás egy nagyságrenddel (Java, C# ?), a script nyelveknél két nagyságrenddel lassabb.

Ami a Java-t és .NET futási sebsségét illeti attól tartok, hogy némileg árnyaltabb a helyzet.

Régóta ádáz vita folyik arról, hogy vajon a menedzselt (pl.: Java, .NET) vagy a natív (pl.: C/C++) kód az, amelyik gyorsabban fut? Voltak, akik az egyikre, mások a másikra esküdtek, illetve számos mérési eredmény is közszemlére került. Főleg a C/C++ fejlesztők voltak azok, akik jókat röhögtek azokon az állításokon, hogy egy menedzselt kód gyorsabb, mint a születésénél fogva natív kód. Szerintem ez a vita mára eldőlni látszik, mégpedig a menedzselt, JIT fordító által generált kódok javára. Vagyis ez azt jelenti, hogy igen, az esetek többségében az úgynevezett "jittelt" kód a gyorsabb (ja igen, a kernel módú kódok nem szerepelnek ebben a futamban). Ez igaz a Java és .NET kódra egyaránt.

Amikor egy C/C++ fordítóprogram előállít egy natív, futtatható fájlt, akkor különböző feltételezésekkel él atekintetben, hogy a generálandó kódot majd milyen működési környezetre optimalizálja. Igyekszik mindenkivel jót tenni, vagyis az architektúra szerinti legkisebb közös többszörösnek megfelelő futattható kódot előállítani (ami később ugye a már említett feltételezések szerint mindenkinek jó lesz). Azt azonban nem tudhatja, hacsak a programozó előre meg nem mondja neki, hogy ahol az a kód majd ténylegesen futni fog, hány processzor van, milyen a processzor és/vagy az adott hardver környezete, architektúrája, utasításkészlete, jellemző tulajdonságai, stb. Elképzelhető, hogy a programozó gépének tulajdonságai (ahol a futattható kód előáll) gyökeresen eltérnek attól, ahol végül is a program majd futni fog.

Egy menedzselt kódnál a programozó, pontosabban fordítóprogram egy gép és architektúrafüggetlen, köztes kódot állít elő (.NET IL, illetve Java bájtkód) még akkor is, ha a programozó fordítási időben ezt valamelyest befolyásolhatja. Később ezt a már említett .NET vagy Java szerinti gépfüggetlen kódot az adott számítógépen, ahol a futattás történik a JIT fordító fogja röptében végrehajtható, natív, gépi kódra fordítani (tudom, hogy a Java-ban van interpretált futattás is, de ez most nem az az eset).

A kutya ott van elásva, hogy miközben a JIT fordító sorra veszi a köztes kód utasításait azt is megnézi, hogy az a gép, ahol ő éppen működik, milyen architektúrával, utasításkészlettel, szomszéddal, sógorral , komával, akármivel rendelkezik, és ennek megfelelően képes az általa generált gépi kódot fordítás - vagy "jittelés" - közben optimalizálni. Másképp mondva az adott végrehajtási környezetnek leginkább tetsző futattható kódot állít elő, ami testvérek között is gyorsabb lehet, mint egy adott környezetben (pl.: C/C++ fordítóval) már előre legenerált, futtatható kód.

Ezen kívül a JIT fordító a natív kód generálása előtt képes kiszűrni és eltávolítani az olyan felesleges kódokat is, mint pl.: if (numberOfCPU > 1)... vagyis a processzorok számának vizsgálatát akkor, ha az adott gépen csak 1 processzor van. Ha pedig a gépbe mégis beletesznek egy újabb processzort, akkor a követező futtatásnál a "jitter" ezt már észleli, és a gépi kód előállításakor ennek megfelelően cselekszik.

Persze egy menedzselt kódnak nem csak előnyei, hanem hátrányai is vannak. Az egyik az, hogy a futtatható program első indulása meglehetősen lassú, hiszen a JIT fordítónak a köztes kódból le kell generálnia natív, futtatható, gépi kódot. Természetesen ez a művelet csak egyetlen egyszer hajtódik végre, hiszen amíg a program a maga natív, gépi kódú állapotában a memóriában van, addíg azt többször már nem kell natív kóddá varázsolni. A másik hátrány, hogy a program futása alatt a JIT által előállított natív kódot tárolni kell a memóriában, emiatt a fizikai memória helyfoglalása lényegesen nagyobb lehet, mint amit egy eleve natív, futattható program esetén tapasztalunk.

Hát, röviden csak ennyit szerettem volna mondani arról, hogy a Java vagy .NET kód lassúbb-e, mint a natív kód.

Köszönöm a figyelmet.

Jó munkát, jó egészséget!

Üdv,
PutAbout

Annyit érdemes még ehhez hozzátenni, hogy a legmodernebb Java JIT compilerek már indulási időben sem lassúak (a Hotspot JIT bevezetése óta), mivel induláskor nem az egész alkalmazást fordítják, hanem csak a futó részeket. Az eső néhány kódrafutáskor a Hotspot compiler lefordítja natív kódra a cuccost és utána már majdnem natív sebességgel hasít. Mi csinálunk Swing-es GUI programozást és kemény, hatalmas objektumszámú kötegelt feldolgozást is és néha komolyan elcsodálkozom rajta, hogy egy kis odafigyeléssel micsoda sebességet lehet kihozni a Java-s cuccokból.

Ma már a lassú Java / .Net indulást a futtatókörnyezet felállása adja. Persze ez is folyamatosan javul és a Java-hoz állítólag nemsokára lesz normális pre-loader is (mint anno az MS Office-hoz).

Sok mindennel egyetértek, amit írsz de nem mindennel.
Azt elismerem, hogy lehetnek olyan helyzetek, amikor a menedzselt kód a gyorsabb, pl. a Java sokkal gyorsabban hoz létre egy objektumot, mint a C++, de általánosságban nem ez a helyzet.
Sok évi Java és C++-os tapasztalat után írtam a sebességekről.
Volt olyan program, amit Javaban kezdtünk el, majd át kellett írni C++-ra, és érződött a különbség.
Egy-két példát még hoznák:
Prím szám generátor Javaban még talán kicsit gyorsabb is volt, mint C++-ban.
Genetikai algoritmus már 3-5-ször lassabb (és talán ez a jellemző).
XSLT algoritmust natív Javaban máig sem láttam, ami a C++-os sebességét meg tudná akárcsak közelíteni is (10-szeres különbség).

A processzor számos példa nagyon nem jó, mert, ha nem úgy van megírva a program, akkor azzal a fordító már nem sokat tud kezdeni.

"Igyekszik mindenkivel jót tenni, vagyis az architektúra szerinti legkisebb közös többszörösnek megfelelő futtatható kódot előállítani."
A fordítás során elég jól lehet a cél eszközökre optimalizálni, és ahol ez kardinális, ott akár több verziót lehet fordítani a programból (32bit, 64bit, SSE2, SSE3, ...).

"Elképzelhető, hogy a programozó gépének tulajdonságai (ahol a futtatható kód előáll) gyökeresen eltérnek attól, ahol végül is a program majd futni fog."
El is térhetnek, attól függően még lehet a cél hardverre (op. rendszerre) optimalizálni. pl. Akár Linux alatt is le lehet fordítani a programot natív Windows-osra, és fordítva.

Azért nem véletlen, hogy az összes teljesítményre kihegyezett program (nem az elosztott rendszerekre gondolok) C++-ban íródik, nem Javaban vagy .Netben.
Amellett, hogy a menedzselt kódot lassabbnak gondolom, én is a menedzselt kód híve vagyok a sok egyéb jó tulajdonsága miatt.

Másrészt milyen elméleti előnye lehet a JIT fordításnak teljesítmény szempontból, ahhoz képest ha ismert környezetre fordítasz nem menedzselt kódot.
Mert az érveid alapján semmi. Szóval nyertek a gentoosok... :)

(egyébként én is managelt környezetek híve vagyok, szerintem nagyon sok esetben remek a kényelem/futási idő értékük...)

Ez így oké, sok esetben így is van (Enterprise cuccok gondolom nem véletlenül ilyen népszerűek, gyanítom a gyorsasággal nincs gond).

Én, mint deszktop felhasználó, viszont azt látom, hogy a JAVA-s programok: lassan indulnak, kevésbé reszponzívak, sok memóriát esznek.

Kérdem én: miért van így, hogy lehet, hogy az állításaid - amik valószínűleg tények - ellenére nem látszanak az előnyök? Minden deszktop-Java programozó hozzá nem értő? Rossz minőségűek a kódok?

Tudom, thinkpad t61, mar mas topikban megbeszeltuk, hogy fos.

A developer gepem viszont eleg jo, a Netbeans 0-24 fut rajta, de nem merek 10 lapnal tobbet megnyitni. Eclipse laptopomon ugyanilyen boszmeteg. Firefoxban appletes oldalak betoltese vagy fel perc, es igy tovabb. A jAlbum meg jo kis Java projekt lehet, de annal nagyobbol meg nem lattam tul furgeket...

Hehe :-)

Ez egy szép elmélet. Pár - megfelelően bonyolult - feladatnál igaz is lehet, ahol az idő amúgy is passzív várakozással telik.

Azonban próbálj meg pl. egy beágyazott rendszeren bármire Java-t használni!

Ha nem mindegy, hogy egy tömböt index-elve címzel vagy pointer artimetikával, akkor nincs az tekintély, akinek elhiszem, hogy a Java gyorsabb tudna lenni...

"hogy a futtatható program első indulása meglehetősen lassú,"
Masodik "inditaskor" mit csinal ?
Bizonyara arra gondoltal, hogy amikor egy futas alatt elsonek fut egy bizonyos kod reszeletre.

x86_64 prociknal mar nincs sok kulonbseg, ha egy masik proceszornak kedvezel.

C/C++ -forditok kepesek profilingra, ami eleg macerans, de azzal igen jo teljesitmenyt lehet elerni.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az erveles szepen hangzik, de a gyakorlat sjanos azt mutatja, hogy a vegrehajtasi sebesseg nem feltetlenul a meghatarozo kerdes egy program futasa soran. A memoriahsznalat es a betoltodesi sebessegek, a valaszidok a legtobb programnal sokkal inkabb lenyegesek, mint az algoritmusok futasi sebessege.

a gyakorlat azt mutatja, hogy amit allitasz, az sajnos kemeny bullshit. lenyegeben az elmult fel evet olyan rendszer tervezesevel toltottem (tabla+filc, igen...), aminek a komponensei valaszidejere volt kemeny megkotes [ezt emlited is].

namost, nem tudom Te hogy vagy vele, de a hasznalt adatszerkezetek minosege (es igy indirekt az algoritmusok futasi sebessege) meglehetosen kenyes kerdes. ha egy read>>write rendszerben a write koltseges, a read meg O(1), akkor siman jobblehet ,mint egy mindenre O(nlogn) -et ado rendszer.

a betoltodesi sebessegek le vannak tojva. elindul, fut. kiszolgal.

ps: a fenti gondolatmenet altalanos ervenyu, vannak helyek, ahol tenyleg az szamit, amit a parent irt, viszont ez elhanyagolhato resz (embedded rendszerek, pl).

Azert mert te eppen egy bizonyos feladatban mas kovetelmenyekkel dolgoztal, attol meg amit allitok legkevesbe sem bullshit. En nem szeretem a kinek az apukaja erosebb tipusu kemenykedeseket, ezert nem mennek bele abba, hogy en milyen feladatokon szoktam dolgozni. Nyilvan a kovetelmenyeket feladata valogatja. Desktop applikaciok eseteben, ami a managelt nyelvek elsodleges felhasznalasi terulete, amit leritam az megallja a helyet. Itt lehet kozvetlen felhasznaloi tapasztalatokat szerezni a valaszidok, toltodesi sebessegek, memorihasznalat teruleten. Es amit irtam annak a lenyege, hogy az osszbenyomas szamit. Tehat mit tapasztal a felhasznalo abbol, amit en hude gyorsnak nevezek, mert az algoritmusaim gyorsan hajtodnak vegre. Na es aztan. (Pelda: a repulo nagyon gyors Bp-Debrecen viszonylatban is csak ha eppen 2 oras a check-in meg 1 oras a check-out, akkor ugy kb. erdektelen, hogy milyen gyorsan szallt a repulo.)

Szerver applikaciok eseten nyilvan mas a helyzet (ld. meg Hunger Googles hozzaszolasa), de itt mas a hardver hatter is. Ezert ott valoban eltolodhat a dolog a vegrehajtasi sebessegek fele, de potnosan azert mert az applikacio nem altalanos celu, igy a hardvert lehet ala illeszteni.

Beagyazott es kulonosen real-time rendszereken meg nem jellemzoek a managelt nyelvek, ami meg nem veletlen.

Ezzel a desktop kijelentéssel óvatosan bánj, mert asztali környezet egy bank is, ahol az ügyfélszolgálatosok reggel 8-kor elindítják a klienst és délután négykor kilépnek. Szóval desktopon sem mindig csak az rendszer indulási idő számít. Szerintem olyan dologról vitáztok, ami minden esetben változik, hisz feladat függő.

C#-nál meg ugye ott van a VS-ben az "edit & run" vagy milyen néven marketingelt funkció is, amikor menet közben átírhatod többé-kevésbé a kódot. Igaz, egyelőre csak 32 bitesekhez van hozzá támogatás, állítólag 2010-es VS-ben lesz 64 bithez is.

----------------
Lvl86 Troll

( sz332 v | 2009. 11. 11., sze – 15:48 )

"Fantasztikus" ... gratulálok az újabb, 21. féle szintaxishoz,
ami még véletlenül sem hasonlít a többihez.

néhány apróság:

func, :=, ; hiánya, "érdekes" függvény szintaxis, var, () hiánya,
nil <-> null, függvények kis és nagybetűs keverése, stb...

van néhány érdekes része, de az ilyen "fejlesztésekkel" kergetik az embert a
halálba...

Elso blikkre ez egy C-sitett Pascal nyelv. (Na ezert most majd mindjart leugatnak, hogy nemis.) A fordito sebessege is hasonlo a Free Pascalehoz. Ennek is csak annyi ertelme van, hogy "nem Pascal, mert az elavult" de ertelmes erv vajon van-e mellette? (Azon kivul, hogy a Google all mogotte, tehat el fog terjedni, ha tetszik ha nem.)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Először nekem is ilyennek tűnt, de megnézve az egy órás videót elég alaposan megváltozott a véleményem.
Hasonlóan voltam a Scala-val is.
Ahogy a Scala a Java mellé (helyett) jó, addig ez a C/C++ kiegészítésére (kiváltására).
Már csak a jó támogatás hiányzik mellőlük.
Go Scala, go Go! :-)

( vargad | 2009. 11. 11., sze – 15:55 )

Nem értem, hogy lehet valami több nagyságrenddel gyorsabb mint a jeleneleg elérhető kereskedelmi és nem kereskedelmi termékek.

nem a függvények törzse, a lényegi kód a fontos ebben az esetben, hanem a *.h fájlokban levő deklarációs rész. Ez az, amit bináris formában rántanak be a felhasználó modulok, nem kell nekik újra és újra és újra lefordítani. Ez az, ami a Pascal compilerekben is igazán ütős (unit használat, nincsenek headerek).

A runtime optimalizáció erre merőleges kérdés, ettől éppenséggel még lehetne header fájl nélkül - runtime optimalizációval kombo.

( jabuci v | 2009. 11. 11., sze – 18:02 )

Azert azt is vegyuk figyelembe, hogy Rob Pike is reszt vett a nyelv letrehozasaban. Szoval annyira rossz nem lehet...

Csak annyi, hogy Ők már bizonyítottak. Gondolom hasonló múlt áll mögötted is, különben ez csak egy szánalmas fikázás.

Egyébként nem kell valaminek szépnek lennie ahhoz, hogy erőteljes, jól használható legyen (lásd tex/latex, vagy perl, ezeknél kevés csúnyább van, bár ízlés kérdése).
Ha elolvasod a preferenciáikat, akkor láthatod, hogy a szép nem volt köztük :-) , csak ilyen apróságok, hogy
egyszerű, gyors, biztonságos, könnyen párhuzamosítható, élvezet használni és nyílt legyen.

Igen, bizonyítottak, köszönjük ... leülhet.

A nyelv SZINTAXISÁNAK nem feltétlenül van köze ahhoz, hogy milyen gyors, biztonságos,
párhuzamosítható, stb. a nyelv.

Sokkal inkább ahhoz, hogy mennyire logikusan épül fel, ezáltal mennyire könnyen
tanulható, segíti-e a munkát, vagy inkább gátolja (szükségtelen, felesleges megkötések,
"varázslási" lehetőségek).

Mennyire támogatja a kód olvashatóságot (latex/tex pl. teljesen olvasható, ellentétben a perl-lel, ami erősen write only), ezáltal a több ember együttműködését, satöbbi...

ez a script nyelvet (var) kombináljuk a pascal-lal (:=) és a c-vel, de hagyjunk el random dolgokat ( () -k a for ciklusban) megspékelve némi random okossággal (;-t rakunk is, meg nem is), eléggé nem szép megoldás.

Nagyon szívesen apró darabokra szedem a nyelv leirását, de szerintem ennyi példa elég lesz.

és miért fáj neked az, hogy ezt is meg kell tanulni, és nem elég kopipésztelni egy C kódot?
Szerintem akkor meg a C a szar, mert a Pascal előbb volt, és mégse követi. :P (eljátszható bármely két különböző nyelvvel ízlés szerint :))

A latex nem feltétlenül olvashatóbb, mint a perl, ahogy mondani szokás, minden nyelven lehet obfuscated kódot írni, csak a perlre mindenki rászáll. A python by design igencsak olvasható, de ott is lehet obfuszkálni.

Szerintem szedd csak darabokra a nyelv leírását, ha ennyi fölös időd van. A szintaxison lovagolni általában zabhegyezés :-/
Sajnálom, hogy neked nem tetszik, írj róla egy jó blogot ;) 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Az a gond vele, hogy az égadta világon semmi értelmes indokot nem lehet felhozni arra, hogy miért kell megkeverni az egyébként már N nyelven alkalmazott szintaxis-t. A fogjuk 2 nyelvet, rakjunk belőle össze egy harmadikat megoldást elég elcseszettnek érzem.

Nem az a bajom, hogy meg kell tanulni, hanem az, hogy nem látom a mögötte
lévő igényes mérnöki tervezést, hanem a "majd belerakjuk, mert az jó lesz" című mutatványt.

miért nem látod azt a mögötte lévő igényes mérnöki tervezést, hisz annyira fontos gnek ez a nyelv hogy még a jogászait* is elküldte a saját feladatától hogy ennek a nyelvnek a megalkotásával foglalkozzon

*: meg mit tudom én kit még akinek a feladata lett volna megnézni legalább programnyelv van-e ezen a néven :D

Abszolút.
Olyan ez, mintha programozási nyelvet írtak volna a fogyatékosoknak:

Why is there no pointer arithmetic?
Safety. Without pointer arithmetic it's possible to create a language that can never derive an illegal address that succeeds incorrectly.

Ne pointerezzünk, nehogy véletlenül kicímezzünk a lefoglalt területről...mintha egy 4 éves gyereknek adnék valamit ami majd megadja az alapokat egy későbbi igazi programozáshoz.
Arról nem is beszélve, hogy pointerek nélkül sokminden megvalósítása vagy sokkal nehezebb, vagy pedig teljesítményben lesz sokkal rosszabb.

Why does Go not support overloading of methods and operators?
Method dispatch is simplified if it doesn't need to do type matching as well. Experience with other languages told us that having a variety of methods with the same name but different signatures was occasionally useful but that it could also be confusing and fragile in practice.

Ne csináljunk overloadokat mert zavaró lehet...Istenem...tényleg ilyen szintre kerülnek a jövő programozói...? Nem szeretném megvárni azt az oprendszert, amit ők írnak egy ilyen nyelvvel...

Értem én, hogy "a nagyok" alkották ezt is, de azt nem értem, hogy gondolhatták ezt komolyan. Mintha csak azt mondták volna, hogy "Csináljunk már még egy nyelvet, mert unatkozunk, de nehogy azt mondják, hogy ez tiszta C, ezért itt-ott írogassuk át a szintaxist, meg 1-2 feature-t vegyünk ki."

"A nyelv SZINTAXISÁNAK nem feltétlenül van köze ahhoz, hogy milyen gyors, biztonságos,
párhuzamosítható, stb. a nyelv."
Nagyon is van köze hozzá, pl. a C a pointer aritmetikájával nagyon nem biztonságos.
Párhuzamosítás:
go fv() Elég egyszerű, nem?
Ez a rész tetszik benne leginkább. Nagyon egyszerű és biztonságos. Még a Scala párhuzamosítás kezelése teszik. Ez a rész egyébként a jövőben egyre fontosabb lesz, lásd egyre több magú processzorok.

Szerintem ez is jól olvasható és könnyen tanulható, de hát nem vagyunk egyformák.

Azt remélem, hogy a Google tényleg mellé fog állni (mert egyelőre még szabadidős projekt), és esetleg az Android hatására közeledni fog a JVM felé. pl. egy JVM fordító vagy szorosabb kapcsolat a jvm-hez nem volna rossz.

( florariz | 2009. 11. 11., sze – 18:40 )

Az előadást hallgatóknak mind röviderevágott, egyen frizurája van.
Az ilyen dolgokoknál nem szoktam fennakadni, de most valamiért mégis. :o

szerk.: najó, nem is igaz, hátul ül két hosszabbhajú. Megyek aludni.

( marcika | 2009. 11. 11., sze – 19:46 )

Csak Mac-re és Linux-ra érhető el jelenleg. A Windows lassan mellékes platform lesz a Google számára^^

Talán az lehet az oka, hogy a Plan9 is ugyanezen emberek munkája? Gondolom az egyikük a "művész", vagy aki eldönti, hogy milyen legyen a logó. :)

"Plan 9 from Bell Labs is a research system developed at Bell Labs starting in the late 1980s. Its original designers and authors were Ken Thompson, Rob Pike, Dave Presotto, and Phil Winterbottom."

( lzskiss | 2009. 11. 11., sze – 20:29 )

szerintem ideje elkezdeni ezt a nyelvet tanulni.
jobb a hullam tetejen lovagolni, mint a vizet nyelni.
csok

OpenBSD 4.6/i386 theo for the prezident:D

nem erre gondoltam. marmint a gugli hullamtermekre.
hanem break point cimu film oreg kenauval, meg a meg oregebb piszkostancos elhunyttal.
kivancsi vagyok milyen iranyban befolyasolja ez a tortenet a toketlenfecske fejlesztesuket.
elkepzelheto hogy meguntak a kigyonyelvet.
csok

OpenBSD 4.6/i386 theo for the prezident:D

( foxpaw | 2009. 11. 12., cs – 09:49 )

A Google világuralomra tör! Meneküljetek! :-D
(Nekem úgy tűnik hogy szintaxisában megalkották a tökéletes Pascal/C hibridet.)

Úgy várom már a Google Cola-t, meg a GooDonald's gyorsétteremláncot, illetve Gooil olajvállalatot. Meg képzeljétek el, hogy minden Tesco felirat helyett egy Google logó van.... :-D

---------------
Értelmezési hiba! Elolvassa újra? I/N

( tomaza | 2009. 11. 12., cs – 10:03 )

csak nem akar eszembe/találatba jutni hogy mit tegeltem be fejembe régebben google programnyelvvel (sőt mintha több is lett volna, és készített, nem használt)

nincs ötletetek?

( leviske | 2009. 11. 12., cs – 11:15 )

BSD? Eddig nem arról volt szó, hogy a Linux-ot veszik kezelésbe?

Vagy hülye vagyok és attól, hogy BSD licences, még nem egyenlő azzal, hogy nem Linux-ra gyúrják a ChromeOS-t?

hajhaj.
A BSD az csak egy licenc, ugyanúgy, mint az MIT, Apache, GPL, MPL, CC-BY-SA, miegyebek.
A GPL-hez képest nagyságrendekkel engedékenyebb abban a tekintetben, hogy mit csinálsz a kóddal. Én pl. sokkal jobban kedvelem a GPL-nél.

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Ez attól függ milyen sorsot szánsz a kódnak.
Ha pl. azt akarod, hogy egy általad megvalósított technológia terjedjen, és nem számít, ki mire használja a jövőben, akkor a BSD jó választás.
Ha azt akarod, hogy bárki aki hozzányúl, az garantáltan visszakerüljön a közösségi ágba is, akkor a GPL a jobb.
--
http://pc.rulz.hu
не закурить! (Ne gyújts rá!) не куриться! (Ne dohányozz! Ne füstölögj!)

Ezt könnyű volt kijelenteni. Sejtettem is hogy valaki nem állja meg szó nélkül.
Én nem akartam tanulmányt írni a dologról, megpróbáltam a lényegét sommázni. (Ezek szerint nem sikerült.)
Akkor kérlek pontosítsd!
--
http://pc.rulz.hu
не закурить! (Ne gyújts rá!) не куриться! (Ne dohányozz! Ne füstölögj!)

( turul16 v | 2009. 11. 12., cs – 16:29 )

Hihetetlen csupa off-topic baromsag.
Nekem meg nem volt idom atnezni, pedig latok benne fantaziat, gondoltam majd itt lesznek ertelmes dolgok, de nem.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

nagy köszi a linkért!

jéé vannak a Go-ról zömében konstruktív, szakmai hozzászólásokat tartalmazó fórumok is... :P

Ez például különösen érdekes.

-----------
"Generally, Russian technology assumes dumb machines and smart humans, not the other way around." -- The Russian Tea HOWTO

( xbit | 2009. 11. 12., cs – 21:33 )

ezekkel is egyetertek. az eloadas elejen pedig elkezdte ecsetelni, milyen klassz ficsorok vannak benne, konkurencia pl.
Az a vicces hogy ezek a dolgok mar regen benne vannak funkcionalis nyelvekben. Ugyanakkor pl ugy vettem ki, polymorfizmus nincs, egyszerre megengedi a konkurenciat state-el, magyaran atlathatatlan kodok tomgele fog keszulni...
Szoval elso latasra, eleg gany, haszontalan, es egyaltalan nem innovativ.

zsolt

( zortutay | 2010. 01. 17., v – 15:38 )

Érdekes ötlet. Bár a videó nem igazán győzött meg arról, hogy milyen dolgokhoz lenne érdemes ezt a nyelvet használni, a már létezők helyett.

Rajzaim
Blogom