Proč je Go tak pomalý?

[UF]

https://en.wikipedia.org/wiki/Limbo

[Reklama]

[Kit]

Souhlasím. Ale nevidím to tak příkře jako ty. Kdybych chtěl propagovat opak: přílišná volnost v úrovni abstrakce a přílišný důraz na DRY vede k sice kratšímu, ale o to nečitelnějšímu kódu. Navíc otrocká implementace DRY může taky způsobit, že všechno centralizuješ/abstrahuješ a pak máš velké problémy jednu část přizpůsobit/poupravit. Mám s tímhle konkrétní špatnou zkušenost z jednoho projektu - všechno bylo vyřešeno tak abstraktně/jednotně/DRY, že se kdokoli pak bál na cokoli šáhnout, aby nerozbil něco úplně jinde...

Naopak, bez DRY musíš měnit jednu věc na více místech, snadno něco přehlédneš.

Při aplikaci DRY musí vývojář přemýšlet, zda při požadavku na změnu ji skutečně bude moct uplatnit jednotně ve všech užitích. Jedna implementace pro různé typy dat může vypadat výhodně, ale pokud se budoucí požadavek na změnu týká pouze jednoho typu dat, na průšvih je zaděláno.

[Mirek Prýmek]

Naopak, bez DRY musíš měnit jednu věc na více místech, snadno něco přehlédneš.

Mám komponenty A a B. Jsou dvě možnosti, co se v budoucnu může stát: buď chci něco změnit v obou komponentách, nebo chci naopak něčím jednu od druhé odlišit. V prvním případě je lepší, když je ten dotčený kód v nějakém společném "rodiči" (ať už to znamená cokoli, ne nutně dědičnost), ve druhém případě je lepší, když je v obou ten stejný kód zkopírovaný.

Navíc otrocké používání DRY spojené s OOP megalomanií vede k vytváření superobecných komponent, které jsou zbytečně komplikované a stejně nejsou nikdy znovupoužité, takže vůbec nic nepřináší, jenom komplikují a znepřehledňují kód, tj. zdražují budoucí úpravy (viz https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition )

Protože člověk nemá křišťálovou kouli, neví, jestli pro něj do budoucna bude lepší složitější abstraktnější nebo naopak konkrétnější přímočařejší kód. Neexistuje pro to žádné obecné pravidlo. Proto nemám rád, když někdo DRY principem příliš šermuje.

Na této sránce https://appliedgo.net/generics/ doporučují copy pastovat nebo generovat kód nějakými externími nástroji. Takový projekt bych nechtěl udržovat.

Ano, to je dobrá stránka, mám ji v Pocketu A taky je to tam dobře vysvětleno, proč to není taková blbost, jak si spousta lidí myslí:

Every time you think that you need to create a generic object, do a quick Litmus test: Ask yourself, “How many times would I ever have to instantiate this generic object in my application or library?” In other words, is it worth to construct a generic object when there may only be one or two actual implementations of it? In this case, creating a generic object would just be an over-abstraction.

Máš nějaký příklad lepší úlohy? Souhlasím, že ty výsledky nejsou moc objektivní. Nepoužívají dostupné knihovny.

Nemám žádný příklad úlohy. Každé zadání je jiné. Z principu nemůže existovat žádný benchmark, který by určoval, který jazyk je obecně nejlepší.

[gll]

Naopak, bez DRY musíš měnit jednu věc na více místech, snadno něco přehlédneš.

Mám komponenty A a B. Jsou dvě možnosti, co se v budoucnu může stát: buď chci něco změnit v obou komponentách, nebo chci naopak něčím jednu od druhé odlišit. V prvním případě je lepší, když je ten dotčený kód v nějakém společném "rodiči" (ať už to znamená cokoli, ne nutně dědičnost), ve druhém případě je lepší, když je v obou ten stejný kód zkopírovaný.

Navíc otrocké používání DRY spojené s OOP megalomanií vede k vytváření superobecných komponent, které jsou zbytečně komplikované a stejně nejsou nikdy znovupoužité, takže vůbec nic nepřináší, jenom komplikují a znepřehledňují kód, tj. zdražují budoucí úpravy (viz https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition )

Protože člověk nemá křišťálovou kouli, neví, jestli pro něj do budoucna bude lepší složitější abstraktnější nebo naopak konkrétnější přímočařejší kód. Neexistuje pro to žádné obecné pravidlo. Proto nemám rád, když někdo DRY principem příliš šermuje.

DRY a OOP megalomanie jsou dvě různé věci. Používání OOP návrhových vzorů jde často proti DRY a naopak prodlužuje kód.

[Kit]

DRY a OOP megalomanie jsou dvě různé věci. Používání OOP návrhových vzorů jde často proti DRY a naopak prodlužuje kód.

Chybné používání návrhových vzorů opravdu jde často proti DRY a prodlužuje kód.

Většinou však vadí, že se návrhové vzory nepoužívají v dostatečné míře a místo nich se jen lepí špagety.

[Reklama]

[Inkvizitor]

Někdy může být copy&paste lepší než DRY, ale až příliš často se děje to, že z původních dvou kopií kódu jsou tři, pak pět a nakonec patnáct. A pak se to musí měnit všude. Jsem pro DRY, pokud to jenom trochu dává smysl.

[gohome]

Zatím zde napadla pro tazatele krutá pravda: go je pomalý, protože je genderově vyvážený.

Prolítněte jak go prezentovali v ranné fázi a co bylo cílem, já si to pamatuji dost dobře.

[. (jiná) :)]

Zatím zde nepadlo odpověď, proč si tazatel myslí, že je Go pomalejší než Java nebo C#, ačkoliv i z těch benchmarků jednoznačně vyplývá, že to není pravda.

[zboj]

Zatím zde nepadlo odpověď, proč si tazatel myslí, že je Go pomalejší než Java nebo C#, ačkoliv i z těch benchmarků jednoznačně vyplývá, že to není pravda.

Pokud se ve VM nikdy nespustí GC, tak u některých typů úloh bude Go "pomalejší", protože má nedeterministický alokátor. To je ovšem značně nerealistická situace, v praxi je Go výrazně rychlejší (minimálně v porovnání s Javou, .NET má komplikovanější VM). Takový "benchmark" se dá napsat levou zadní (jen nebude o ničem vypovídat).

[Ivan Nový]

Zatím zde napadla pro tazatele krutá pravda: go je pomalý, protože je genderově vyvážený.

Prolítněte jak go prezentovali v ranné fázi a co bylo cílem, já si to pamatuji dost dobře.

Původně to vycházelo z Plan-9, tedy měl to být jazyk pro multiprocesorový distribuovaný systém.

[Kiwi]

Je prča sledovat, jak lidi vítězoslavně přicházejí na dávno známé věci. Ale proč číst počítačovou literaturu ze 70. a 80. let, že... To je přece doba kamenná.

Chybné používání návrhových vzorů opravdu jde často proti DRY a prodlužuje kód. Většinou však vadí, že se návrhové vzory nepoužívají v dostatečné míře a místo nich se jen lepí špagety.

Kdyby všichni programovali dokonale, žádných paradigmat ani návrhových vzorů by nebylo třeba. Bezmyšlenkovité používání návrhových vzorů jen proto, že to "bylo v tej brožuře", je ale snad ještě větší zlo, než kdyby to dotyčný nějak spatlal, jak mu to přišlo na mysli. Protože to vede jen k tomu, že se jeden problém vynásobí problémem druhým: nešikovné řešení krát nesprávně aplikovaný vzor.

[zboj]

Je prča sledovat, jak lidi vítězoslavně přicházejí na dávno známé věci. Ale proč číst počítačovou literaturu ze 70. a 80. let, že... To je přece doba kamenná.

Běžný Pepa (nebo Míra) programátor nečte akademické články, a možná to je dobře, rozvoj a inovace by se měly přenechat těm kreativnějším (ne nutně akademikům).

[zboj]

Chybné používání návrhových vzorů opravdu jde často proti DRY a prodlužuje kód. Většinou však vadí, že se návrhové vzory nepoužívají v dostatečné míře a místo nich se jen lepí špagety.

Kdyby všichni programovali dokonale, žádných paradigmat ani návrhových vzorů by nebylo třeba. Bezmyšlenkovité používání návrhových vzorů jen proto, že to "bylo v tej brožuře", je ale snad ještě větší zlo, než kdyby to dotyčný nějak spatlal, jak mu to přišlo na mysli. Protože to vede jen k tomu, že se jeden problém vynásobí problémem druhým: nešikovné řešení krát nesprávně aplikovaný vzor.

Ano, tomu se říká "cargo cult programming" a obávám se, že mnozí, ne-li většina, takto programují a ještě si na tom zakládají.

[Kit]

Chybné používání návrhových vzorů opravdu jde často proti DRY a prodlužuje kód. Většinou však vadí, že se návrhové vzory nepoužívají v dostatečné míře a místo nich se jen lepí špagety.

Kdyby všichni programovali dokonale, žádných paradigmat ani návrhových vzorů by nebylo třeba. Bezmyšlenkovité používání návrhových vzorů jen proto, že to "bylo v tej brožuře", je ale snad ještě větší zlo, než kdyby to dotyčný nějak spatlal, jak mu to přišlo na mysli. Protože to vede jen k tomu, že se jeden problém vynásobí problémem druhým: nešikovné řešení krát nesprávně aplikovaný vzor.

Často potkávám nesprávně použitý vzor Flyweight nebo Singleton. Těmi se opravdu musí šetřit, protože dokáží zaneřádit aplikaci. Ovšem logování přes Observer je podle mne docela sympatické a vzor Factory má také časté uplatnění.

[Mirek Prýmek]

Je prča sledovat, jak lidi vítězoslavně přicházejí na dávno známé věci. Ale proč číst počítačovou literaturu ze 70. a 80. let, že... To je přece doba kamenná.

Co konkrétně máš namysli tady u toho, o čem jsme se bavili? To je spíš o zkušenosti než o nějaké teorii imho.

Běžný Pepa (nebo Míra)

Já ti dám Míru, ty darebáku!