Vlákno názorů k článku Nechte Go plavat, teď sviští Java od kakihara - Je mi lito, ale clanek je ryzi demagogie. Snazi...

Je mi lito, ale clanek je ryzi demagogie.
Snazi se postavit argument, ze hlavni hype go je jeho rychlost a moznost staticke kompilace.

Ve skutecnosti hlavni vyhodou go oproti jave je, ze je to proste lepsi jazyk. I kdyby bylo 5x pomalejsi, porad stoji za to.
Pochopil bych, kdyby se autor snazil srovnat go treba s kotlinem, ale java je opravdu mimo.

Go je trivialni jazyk (syntakticky jednodussi nez cecko), coz vam umoznuje prijit defacto k jakemukoliv projektu a okamzite vidite, co se deje. Nepouzivaji se zadne silene frameworky, zadne builder patterny. Zadne desitky trid a interfacu jen proto, ze nekdo v nejake knize napsal ze to tak ma byt.

V go mate moznost predavat hodnoty ...hmm...hodnotou. Ze zacatku to cloveku uplne nedojde, ale vlastne to supluje imutabilitu, protoze volana funkce nema sanci zmenit strukturu(aka tridu), kterou si drzi volajici. Zaroven to umoznuje kompilatoru drzet si hodnotu na stacku a tim omezit garbage.
Nemusite resit null pointery.
Ne vazne, kolik jste v zivote videl zbytecneho kodu a padu programu kvuli null pointerum? Kolik nevysvetlitelnych chovani programu, protoze nekde nejaka funkce zmenila neco v objektu co dostala, co menit nemela? Kolik popasnych stranek vymyslejicich, jak udelat objekt immutable, jen proto, ze samotny jazyk na neco takoveho nepamatuje?

Porovnavat vlakna v jave s go a kanalama je spatny vtip (uznavam, ze jsem javu od sedmicky nepouzival). V zadnem z mainsteamovych programovacich jazyku jsem nevidel nic tak elegantniho a efektivniho, jako moznost si v go vzit normalni snadno testovatelnou synchronni funkci, na trech radcich ji obalit anonymni funkci a spustit v jine subrutine a pozdeji jednoduse a bezpecne v selectu vyhodnotit jeji navratovou hodnotu nactenou z kanalu.

System balicku go nedovoluje cyklicke zavislosti, coz, jakkoliv pro javisty neintuitivni, cloveku zarucuje, ze kdyz se nori hloubeji a hloubeji do projektu, tak se mu zuzuje pohled. Nestane se, ze nekde na konci toho tunelu je pointer zase zpatky na zacatek. Vyrazne to usnadnuje orientaci.

Je toho vic, co se mi na go libi a taky dost, co se mi nelibi, ale verte mi, vsechny ty projekty jako docker, kubernetes, cockroachdb etc nejsou v go napsane jen proto, ze je celkem rychle a kompiluje se do jedne binarky.

Ma osobni zkusenost je, ze go mi umoznuje daleko vic se soustredit na navrh projektu a neresit nesmyslne framewroky a sofistikovane navrhove vzory. Ve finale si myslim, ze jsem o dost efektivnejsi a rozhodne napisu pro stejnou funkcionalitu min kodu a vygeneruju jen zlomek souboru, coz hodne prispiva k prehlednosti.
a hlavne: najednou je to programovani zase desne zabavny

Děkuji a respektuji Váš názor. To poslední, do čeho bych však chtěl zabřednout, je diskuze o tom, který jazyk je ten nejlepší. OracleLabs zastávají následující postoj: "Pište si v čem chcete, my se postaráme, aby to běželo rychle!"

Pokud Vám Go vyhovuje, držte se ho! Mým cílem není konvertovat Vás k Javě, ale vysvětlit Javistům, že pokud hledají něco, co běží podobně jako Go, tak je to blíže než by se mohlo zdát. Určitě kvůli tomu nemusí měnit jazyk.

Je fajn, že si "diskuzi užíváte". Článek o native-image jsem jednoznačně uvítal, ale raději bych se z něj dozvěděl proč je GraalVM a native-image skvělý, nikoliv proč je Go špatný. V článku mi chybělo, co všechno (zatím) native-image neumí správně přeložit, jak je to s podporou běžně používaných knihoven třetích stran, zda jste zkusili aplikovat na nějaké reálné projekty (byť třeba jen v testovacím režimu a ne v produkci), čeho se tedy mám při psaní programu vyvarovat abych nebyl nepříjemně překvapen... Místo porovnání s Go bych uvítal porovnání s "plnotučným" JRE.

Pokud bude někdy další článek zabývající se možnostmi native-image do větší hloubky, velmi rád si jej přečtu...

> Ve skutecnosti hlavni vyhodou go oproti jave je, ze je to proste lepsi jazyk. I
> kdyby bylo 5x pomalejsi, porad stoji za to.

Lepší na co? Na vysokoúrovňovou logiku nebo zpracování dat totiž rozhodně ne. Ano, if a for strojově vyjádří všechno, ale vývojář z toho nepozná záměr.

Naopak funkce jako třeba map, filter, reduce zcela jasně deklarují co se má dít, aniž by čtenáře zatěžovaly tím jak je to implementované. Obzvláště viditelné je to u paralelních variant. Případně kolekce a funkce typu getOrDefault, putIfAbsent.. vše napíšete i s pomocí ifu. Ale nebude to tak čitelné.

A pokud se prosadí generika dle https://go.googlesource.com/proposal/+/master/design/go2draft.md tak věřte, že ty kolekce podobného typu brzy vzniknou i pro Go.

Alternativa k NumPy v go ale asi nikdy nebude (stejně jako není v Javě). Pro tvorbu DSL se ten jazyk prostě nehodí a matematici nechtějí psát V.dot(V2).

> V go mate moznost predavat hodnoty ...hmm...hodnotou.

To v C++ taky :) V Pythonu jak co. V Javě jen primitiva.. ale máte final.

> V zadnem z mainsteamovych programovacich jazyku jsem nevidel nic tak
> elegantniho a efektivniho, jako moznost si v go vzit normalni snadno
> testovatelnou synchronni funkci, na trech radcich ji obalit anonymni funkci a
> spustit v jine subrutine

await, async v Pythonu 3 [1]
Futures a ExecutorService v Javě nejsou taky o nic horší [2]

> Ma osobni zkusenost je, ze go mi umoznuje daleko vic se soustredit na
> navrh projektu a neresit nesmyslne framewroky a sofistikovane navrhove
> vzory.

Moje je zase přesně opačná, Go importy z githubu, knihovny různé kvality a třeba neexistence explicitního seznamu chyb (throws v Javě) mě dost brzdí.

Ty frameworky jsou v Go taky a naopak v Javě Vás nikdo EE nebo Spring používat nenutí (moje blbinky v čistém Java 8 SE + pippo [3] by mohly vyprávět).

Chce to příště trošku větší rozhled než se pustíte do srovnávání jazyků. Každý se totiž hodí na něco malinko jiného a dá se používat různě.

[1] https://docs.python.org/3/library/asyncio-task.html
[2] třeba https://www.callicoder.com/java-callable-and-future-tutorial/ ale nemusí to být ani lambda, Java 8 umí method reference
[3] http://www.pippo.ro/