Vlákno názorů k článku
Go 1.17 je o 5 % rychlejší
od cc - Člověk nikdy nepochopí, proč to původně navrhli tak,...
-
Tím závanem jsem nemyslel starý toolchain, který vlastně nikdo jiný moc nepoužívá. Spíš jak je navržený samotný jazyk.
Krásný příklad je třeba Hoareho miliardový omyl. Jazyky s vousy až k zemi flíkují svoje reference anotacemi a přidávají Optional typy. A relativně nové Go si spokojeně inicializuje reference na nil a možná to budou za X let lepit stejně jako teď třeba Java.
-
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.
-
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.
-
Pavel TišnovskýZlatý podporovatelNa 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.
-
Ten assembler jsem musel používat v jednom projektu, a abych byl upřímný, tak to byla moje nejhorší zkušenost vůbec. Nezdokumentovaný kočkopes, kde je všechno jinak, instrukce mají jiné názvy, jiné pořadí argumentů, názvy funkcí musí obsahovat nějaký zvláštní unicode znak, atd... už to nikdy nechci vidět.
Na druhou stranu v go je všechno tak nějak naopak, takže se nedivím, že i ten assembler je vlastně naopak.
-
Já ho pochopil tak že mluvil o Plan 9 assembleru a ne o Go assembleru. Mimochodem sám jste napsal že celý ten toolchain existoval ještě před vznikem Go.
Ne assembler v Go není mizerně zdokumentovaný, protože je určený pro interní použití. Autoři jednoduše použili svůj assembler, který byl prostě mizerně zdokumentovaný už v dobách kdy žádné Go neexistovalo. -
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 :)
ČLÁNKY DO MAILU