Proč ten hype okolo Go?

[Kit]

Jen se neboj, já ji chápu. Myslel jsem to zcela vážně, kdybys javu používal, věděl bys, čeho se vyvarovat. A rozhodně bys tu netlačil mapu/dokonce kolekci pro předávání parametrů. I když ve vimu by to asi vyšlo nastejno...

To je právě nevýhoda IDE, že podporuje jen "jeden správný" styl programování, což způsobuje příliš velkou provázanost mezi komponentami a tím zvyšuje složitost. Ve Vimu mě ani nenapadne používat čtyřnásobnou dědičnost a protected atributy. IDE tyto nežádoucí postupy podporuje.

[Reklama]

[dustin]

Nechám tě při tom, hodně štěstí...

[bakakaika]

Jen se neboj, já ji chápu. Myslel jsem to zcela vážně, kdybys javu používal, věděl bys, čeho se vyvarovat. A rozhodně bys tu netlačil mapu/dokonce kolekci pro předávání parametrů. I když ve vimu by to asi vyšlo nastejno...

To je právě nevýhoda IDE, že podporuje jen "jeden správný" styl programování, což způsobuje příliš velkou provázanost mezi komponentami a tím zvyšuje složitost. Ve Vimu mě ani nenapadne používat čtyřnásobnou dědičnost a protected atributy. IDE tyto nežádoucí postupy podporuje.

Plácáte s prominutím nesmysly

[Ondra Satai Nekola]

Jen se neboj, já ji chápu. Myslel jsem to zcela vážně, kdybys javu používal, věděl bys, čeho se vyvarovat. A rozhodně bys tu netlačil mapu/dokonce kolekci pro předávání parametrů. I když ve vimu by to asi vyšlo nastejno...

To je právě nevýhoda IDE, že podporuje jen "jeden správný" styl programování, což způsobuje příliš velkou provázanost mezi komponentami a tím zvyšuje složitost. Ve Vimu mě ani nenapadne používat čtyřnásobnou dědičnost a protected atributy. IDE tyto nežádoucí postupy podporuje.

Neblabol.

[Zlatovlaska]

Jen se neboj, já ji chápu. Myslel jsem to zcela vážně, kdybys javu používal, věděl bys, čeho se vyvarovat. A rozhodně bys tu netlačil mapu/dokonce kolekci pro předávání parametrů. I když ve vimu by to asi vyšlo nastejno...

To je právě nevýhoda IDE, že podporuje jen "jeden správný" styl programování, což způsobuje příliš velkou provázanost mezi komponentami a tím zvyšuje složitost. Ve Vimu mě ani nenapadne používat čtyřnásobnou dědičnost a protected atributy. IDE tyto nežádoucí postupy podporuje.

Neblabol.

Blabol

[Reklama]

[BoneFlute]

Kód: [Vybrat]

file, _ := os.Open("/path/to/file.txt")
No a když tedy tento kód použijeme a funkce open() vrátí chybový stav, co se stane? Já v go nikdy nic nepsal, ale naprvní pohled mi tento přístup přijde pozadu oproti tomu jak to dělá Rust nebo i oproti klasickým vyjimkam,

vrati chybu kterou zahodis a v ty promenny file bude nil, s cim nekde dal musis pocitat

Nevýhodou tohoto přístupu je, že se už nedozví, proč se ten soubor nepodařilo otevřít.

Neřešíme tu skutečnost, že když chybu zahodíš, tak se nedozvíš, proč se nepodařilo soubor otevřít.

Bavíme se tu o tom, že způsob, jak s chybou pracuje Go a jak třeba Java je v určitých ohledech stejný.

[BoneFlute]

Je to psuedokod, ale aby ste boli spokojni

Kód: [Vybrat]

file, _ := os.Open("/path/to/file.txt")

Proste ide o to, ze pri vynimkach musite pre ignoraciu chyby nieco aktivne urobit

To podtržítko považuji právě za tu aktivní snahu ignorovat chybu.

Bloky try-catch jsou spíše k seskupení chyb, aby si nemusel odchytávat každou jednu. Nepolemizuji nad tím, zda je to dobře nebo špatně.

No a když tedy tento kód použijeme a funkce open() vrátí chybový stav, co se stane?

To samé, jako když v java-like napíšeš:

Kód: [Vybrat]

try {
   file = os.Open("/path/to/file.txt")
}
catch (Exception e) {}


Já v go nikdy nic nepsal, ale naprvní pohled mi tento přístup přijde pozadu oproti tomu jak to dělá Rust nebo i oproti klasickým vyjimkam,

Co konkrétně by si tomu vytknul?

[oss]

Je to psuedokod, ale aby ste boli spokojni

Kód: [Vybrat]

file, _ := os.Open("/path/to/file.txt")

Proste ide o to, ze pri vynimkach musite pre ignoraciu chyby nieco aktivne urobit

To podtržítko považuji právě za tu aktivní snahu ignorovat chybu.

Bloky try-catch jsou spíše k seskupení chyb, aby si nemusel odchytávat každou jednu. Nepolemizuji nad tím, zda je to dobře nebo špatně.

No a když tedy tento kód použijeme a funkce open() vrátí chybový stav, co se stane?

To samé, jako když v java-like napíšeš:

Kód: [Vybrat]

try {
   file = os.Open("/path/to/file.txt")
}
catch (Exception e) {}


Já v go nikdy nic nepsal, ale naprvní pohled mi tento přístup přijde pozadu oproti tomu jak to dělá Rust nebo i oproti klasickým vyjimkam,

Co konkrétně by si tomu vytknul?

Je to psuedokod, ale aby ste boli spokojni

Kód: [Vybrat]

file, _ := os.Open("/path/to/file.txt")

Proste ide o to, ze pri vynimkach musite pre ignoraciu chyby nieco aktivne urobit

[BoneFlute]

Je to psuedokod, ale aby ste boli spokojni

Kód: [Vybrat]

file, _ := os.Open("/path/to/file.txt")

Proste ide o to, ze pri vynimkach musite pre ignoraciu chyby nieco aktivne urobit

To podtržítko považuji právě za tu aktivní snahu ignorovat chybu.

Bloky try-catch jsou spíše k seskupení chyb, aby si nemusel odchytávat každou jednu. Nepolemizuji nad tím, zda je to dobře nebo špatně.

No a když tedy tento kód použijeme a funkce open() vrátí chybový stav, co se stane?

To samé, jako když v java-like napíšeš:

Kód: [Vybrat]

try {
   file = os.Open("/path/to/file.txt")
}
catch (Exception e) {}


Já v go nikdy nic nepsal, ale naprvní pohled mi tento přístup přijde pozadu oproti tomu jak to dělá Rust nebo i oproti klasickým vyjimkam,

Co konkrétně by si tomu vytknul?

Je to psuedokod, ale aby ste boli spokojni

Kód: [Vybrat]

file, _ := os.Open("/path/to/file.txt")

Proste ide o to, ze pri vynimkach musite pre ignoraciu chyby nieco aktivne urobit

Takže to podtržítko není dostatečný projev aktivity? OK, pro někoho může být.