Názory k článku
Go 1.17 je o 5 % rychlejší

Jo, jednou to určitě zalepí. Ale zrovna tohle mě moc netrápí, jsou horší věci.

No právě, jednou zalepí něco co i konzervativní Java lepila někdy v roce 2014. Příležitost udělat to pořádně už nemají. Měnit věci na opt-in se zpětně moc nedá.

Mně jde hlavně o to, že tenhle problém není nějaká horká novinka. O téhle chybě se mluví spoustu let, jsou známá řešení a ... a nic. :( Prostě se vztyčenou hlavou nakráčeli do totálně provalené pasti.

Mají jiné priority. Kdyby mělo Go být super bezpečné, muselo by mít taky readonly proměnné, private na úrovni struktur a spoustu dalších věcí. Pak by to byl Rust :)

Jasně, kdyby mělo být Go super bezpečné, tak by bylo potřeba spoustu dalších věcí. Ale já nemluvím o dokazatelné bezpečnosti ve stylu Rustu, ale o blbých nullable referencích jako opt-in. Tady je poměr cena/výkon trochu jinde, ne? A taky to není žádný state of the art výzkum v programovacích jazycích.

Pro doplnění - v Go 1.18 jsou "non-nullable" ukazatele (implementace ve smyslu rustovského "zero cost abstraction"). Hejtři teď musí přejít od "Go to nemá" ke "Go to donedávna nemělo" :)

Na jednu stranu máte pravdu, ale na stranu druhou je v Go zvykem (= prakticky všichni to dodržují) používat více návratových hodnot a minimálně tak řešit typ Result (Optional je v tomto kontextu asi míň zapotřebí). V praxi se fakt na NPE v Go narazí málokdy, už jen proto, že se zde reference používají míň, než například v Javě a když už je nějaký objekt inicializován, tak je prakticky hned po volání konstruktoru jasné, že nebude nil (protože tady se error check v praxi vyžaduje).

PS: to je z praxe, kde v Go píšeme servicy. Asi u nějakého SW s hodně "rozmáchlými" datovými typy to bude jinak, ale u víceméně jednoduchých servis je toto asi ta nejméně problematická část Go.

K tomuto kdysi byl návrh ("Go syntax proposal") - probublávání chyb z návratových hodnot jako v Rustu. Ale neprošel hlasováním. Pokud se pamatuju dobře, tak rustovskému "call(...)?" odpovídalo "try(call(...))".

Co teraz lepia v Jave som nepochopil?

To "teď" ber s rezervou :) Měl jsem na mysli NotNull anotace. Prostě hlídání nulových referencí už při kompilaci, protože na spoustě míst vůbec nedávají smysl a díky tomu to tam nikdo nekontroluje a vyhozenou výjimku pak taky nikdo nečeká. Přidávat něco takového do jazyka zpětně má své mouchy.

Go má jen ukazatele, ne reference. Viz vysvětlení P. Tišnovského. Tato výhrada by dávala smysl u rozhraní, ta jsou ekvivalentem javovských referencí. Nicméně typová kontrola v překladači Go pracuje s nil kreativně, standardní knihovna je plná výrazů typu “*(*T)(nil)”.

Ony ty ukazatele a reference jsou dost neostré kategorie. Potkal jsem c++aře, co tvrdili že reference v Javě jsou vlastně ukazatele (a svým způsobem je to i pravda). :) Ono není až tak důležité jak se tomu říká, ale jestli je to "nullable".

Zrovna v C++ reference nullable nejsou, jen pointry. V Go je naopak několik typů nil, třeba “x == nil” může být false, i když odkaz na instanci je nil. Holt špecifiká… :)

IMHO myslel asembler v Go, až tam je ten zmíněný “unicode znak”.

Blbost je používat něco, co je nedokumentované a potenciálně nestabilní.

Já se tu s tebou nebudu hádat. Ten assembler tam je z nějakého důvodu, a kdo ho umí využít má prostě výhodu. Já jsem dokázal zrychlit něco 8x aniž by se komplikoval deployment té služby a linkovalo něco k C knihovnám. Možná to nevidíš, ale ten assembler se fakt používá.

Problém celé té věci je v tom, že autoři go prostě nechcou nic udělat kompatibilní. Všechno musí být jinak. Ale jak říkám, to jsem si zvykl, a určitě bych nepřepisoval v go něco co už funguje do jiného jazyka jen kvůli tomu, že má debilní assembler. Člověk si zvykne, když za to dostane dobré peníze :)

A teď tu o trpaslících... ;)