Příspěvky

241

Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?

« kdy: 11. 09. 2018, 19:19:25 »

....

Spousta programatoru pouziva databaze jen jako hloupe uloziste dat, na zacatku select * from, a na konci update/insert. A  k vykonu asi toliko, ze vypocet mezd pro cca 100 lidi na i386 s nejakou tou lokalni databazi na lokalnim disku aplikaci bezici v DOSu ... byl velmi casto rychlejsi ( i radove) nez vypocet tehoz dnes, na HW disponujicim desitkami jader, stovkami GB ram a daty na na poli se stovkami tisic IOps.

Nejaka ta foxka by na soudobem HW musela doslova litat.

BTW: foxpro/dbase umoznovalo dotazovani do databaze uplne stejne (byt v jinem provedeni) jako libovolny SQL, zadny kod na ziskavani dat nebyl treba, ale z pohledu uzivatele je to uplne totez, bezny uzivatel nedostane data z foxpro, uplne stejne jako je nedostane z SQL. Proste proto, ze netusi jak by to mel udelat.

Dobrá tak, ten report se tam nekódoval, ale nějak parametrizoval. Už je to přez 20 let, co jsem dělal s Foxkou.

Pochybuji, že by Foxka byla na soudobém hw rychlejší - všechny optimalizace a figle, co uměla mají dnes všechny pokročilejší SQL servery. Spíš tehdejší slabší železo a i jednodušší interface neumožnili být moc kreativní. Interface musel být jednoduchý, bo se Vám na obrazovku moc toho nevešlo. Tehdy se nedaly moc stavět vzdušné zámky. Když si uživatel, nebo programátor vymyšlel blbosti, tak to prostě nefungovalo.

242

Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?

« kdy: 11. 09. 2018, 18:26:36 »

Popsaný způsob programování je v podstatě klasický procedurální, imperativní, vhodný pro počítače s von-Neumannovskou architekturou (nebo podobnou). Jak se ale během času ukázalo, to je pro relační databáze (a pravděpodobně pro databáze obecně) velmi nevhodná architektura, a proto všechny dnešní SQL databáze (a mnohé noSQL, záleží na typu a kusu) obsahují VM fungující na zcela jiném principu. Teoreticky by se daly programovat přímo (assembler == "query plan"), ale bylo by to velmi nepraktické, programátoři jsou prostě vycepovaní von Neumannem. Už takhle je pro začátečníka docela záhul query plan přečíst, instinktivně tam hledá tok programu :-)

zde tak nějak nechápu, co jste chtěl sdělit. Jsou rel. databáze zlo, protože se musel hledat nějaký jiný způsob jejich programováni, aby to alespoň trochu fungovalo?

Se starými souborovými databázemi jako byla FoxPro, DBase se pracovalo velice podobně - v podstatě za každým reportem byl nějaký kód. SQL je ale mnohem dynamičtější - můžete vytvořit reporty, které by se v 80tých, 90tých letech možná ani udělat nedaly. Do toho pak ještě vstupuje optimalizace - ať už je to automatická volba indexu, volba pořadí JOINování, volba typů JOINování, typů agregací, atd. Moderní systémy berou v potaz velikost paměti, velikosti tabulek, efekt filtrů, efekt agregace.

Nic z toho u síťových databází nebylo - tam jste jen iteroval nad grafem - a všechno ostatní jste si zadrátoval do kódu, a co jste si nenapsal, to jste neměl.

243

Vývoj / Re:C nebo Rust?

« kdy: 11. 09. 2018, 14:04:43 »

Dost možná, že Cčko, C++ se bude chovat podobně. Namapovaná paměť zůstává procesu do konce procesu - to je vlastnost glibc.

244

Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?

« kdy: 11. 09. 2018, 06:06:51 »

Ta výhoda spočívá v tom, že ty datové funkce jsou primitivní (rychleji už to nejde) a mají očekávanou odezvu, ať už jsou nasazeny v aplikačním programu kdekoliv. Programátor postupuje tedy tak, že vytváří primitivní aplikační funkce (kdy každá z nich si může obstarat potřebná data s max. možnou rychlostí), které kombinuje do komplexnějších celků. Změna v aplikaci se provádí záměnou jednoduchých aplikačních funkcí -říkejme tomu modularita.

Tipoval bych, že Vám ani nevadí relační model, jako SQL. Existovaly knihovny, kde se i s relačními databázemi pracovalo podobně - v 90 letech existovalo několik knihoven, minimálně jedna od Borlandu, a co jsem se díval, tak na GitHubu jsou desítky. Tohle je věčná diskuze trvající od konce éry COBOLu, a argumenty jedné i druhé strany jsou stejné. Doporučoval bych diskuzi, obhajobu SQL od Joe Celka (což je dneska už pán v letech, který hodně hezky popsal přechod od COBOLu k SQL).

S SQL určitě ztrácíte nad procesem zpracování dat kontrolu, což pro některé vývojáře může být nepříjemné. Podobně jako je pro mne např. nepříjemné použití ORM. Zas těch přecitlivělých vývojářů je relativně málo, což dokazuje rozšíření SQL i ORM. Určitě s použitím generické databáze ztrácíte v limitních případech až řád výkonu - zvlášť pokud dokážete efektivně využít paměť - což není o SQL, ale o tom, že se používá obecné uložiště a neustále se musí mapovat na zadaný záznam, který ale není zadrátovaný do kódu.

Na stranu druhou - tento hard code přístup měl hodně strmou křivku učení, což nemuselo být zřejmé před 40 lety, kdy nebyly alternativy, a bez programátorů jste se k datům nedostal, což zase omezovalo práci s daty a prodlužovalo reálný čas dostupnosti databáze. Tehdejší databáze byly relativně efektivní (na tehdejším HW), ale musel jste počkat 2-3 dny, možná týden, než Vám programátor napsal report. To je jeden z důvodů proč vzniklo SQL - efektivitu nikdo až tak moc neřešil, ale uživatelé přes terminál mohli mít data během několika minut.

Navíc i ty staré relační databáze některé úlohy z principu řešily lépe než staré síťové - a ve chvíli, kdy šla CPU výkonnostně nahoru (90 léta), tak ten direktivní přístup k datům ztratil význam. Za posledních deset let jsem u dvou uživatelů Postgresu konstatoval, že by to měli přepsat do Cčka, a databázi použít jen jako storage nebo nepoužít. Ono to SQL funguje docela hezky.

245

Vývoj / Re:Mají tabulkové databáze v dnešní době smysl?

« kdy: 10. 09. 2018, 19:11:46 »

Tak se chci zeptat:
Maji tabulkove databaze na novych projektech smysl?
Migroval nekdo z vas existujici reseni z oraclu nebo jine tabulkove databaze na neco jineho?
Souhlasite, ze rychlost/pomalost rotacnich disku je jediny duvod proc takove databaze existuji?
Diky za nazory

Protoze jsem tu videl jen skepticke reakce a pak offtopic diskuzi, zkusim neco jineho:

Radu let jsem pouzival pro male projekty MySQL. Funkcni, hezke nastroje k organizaci, interface do ruznych jazyku. Co pul roku mam zvyk se jen tak podivat na neco noveho. Tehdy to bylo MongoDB. Slozita neintuitivni instalace a zprovoznovani (2016), ale nakonec zafungovalo. Napsal jsem si skript na zapis/cteni. A nedavno jsem (hard) preinstaloval na Ubu1804 a mel zasadni problem s prevodem dat.

Vysledne dojmy?  : Uz bych nemenil.

• Zalozeni nove tabulky (tady collection) nevyzaduje zadnou specialni akci
• V pythonu je pymongo: ovladani se neda s mysql srovnavat, vsechno je jako DICT 
•   Pouzivam 100x intenzivneji nez kdysi mysql, takze mam kolem milionu zaznamu, zapisuji kazdych 10 sec. a nevidim latenci 
•   Menim tabulku za behu, proste zacnu pridavat dalsi parametr. 
•   Mam dost ridkou tabulku, vetsina parametru je Nan, navazujici pymongo a pyplot jsou v pohode. 
•   Clovek muze nechat bezet stejne MongoDB na vice strojich najednou, cimz ma duplicitu a pojisteni proti vypadku (ale nezkousel jsem) 
•   ... a nakonec - MongoDB neni ta nejrychlejsi a nejlepsi NoSQL databaze na trhu.....   

Takze tak. Minusy? Nenasel jsem zadnej skvelej program na udrzbu (jako mysql-workbench apod). Ale nechybi mi, na vsechno mam jeden skript.

1M zaznamů máte celkem nebo za těch 10 sec?

246

Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?

« kdy: 10. 09. 2018, 15:29:23 »

Jednou z uplne prvnich databazi bylo IMS (a obcas se jeste pouziva), a ta uklada data (zaznamy) prave ve stromove strukture podle klice.

... Ale hlavni nevyhoda je, ze si musite vytvorit vlastni funkci (program), ktera ty zaznamy prochazi ...

ale to je také ta největší výhoda

Můžete to vysvětlit?

247

Vývoj / Re:Mají tabulkové databáze v dnešní době smysl?

« kdy: 08. 09. 2018, 21:10:05 »

Kde? Dáš link prosím?

https://www.meetup.com/Prague-PostgreSQL-Meetup/

248

Vývoj / Re:Mají tabulkové databáze v dnešní době smysl?

« kdy: 08. 09. 2018, 20:11:06 »

už leta připravuji článek o tom, jaký je SQL ( tabulkové databáze) nesmysl, ale ještě jsem se neodvážil to panu Krčmářovi nabídnout, neb se obávam, že by to redakca nevzala z oprávněné obavy z urážlivých komentářů pod článkem a z toho vyplývajícího popotahování s úřady.

Ten článek bych si rád přečetl - klidně mi jej můžete poslat privátně, jestli máte obavy o redakci roota. Mail na mne se válí na netu - nebo někde u piva můžeme podiskutovat a výhodách a nevýhodách RDBMS.

Je to technologie jako každá jiná, i když je hodně šikovně vymyšlená, tak to není stříbrná kulka, a jako u všeho, záleží jestli ji používá někdo, kdo je v obraze nebo není. Než jsem se dostal k vývoji Postgresu, a chca nechca přičichl k databázím víc a zevnitř, tak jsem databáze voral jako všichni ostatní. Nicméně, když člověk pochopí základy a souvislosti, tak pak to všechno začne dostávat smysl.

24.9. bude Postgres meetup - u piva můžeme dát řeč.

249

Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?

« kdy: 08. 09. 2018, 07:14:55 »

Ano,ale tady mi na prvni pohled prislo, ze by davalo smysl vyuzit databazi prave kvuli konzistenci dat a transakcim.
A zajimala by me motivace architekta k takovemu reseni. A protoze jsem videl toho Boba povidat o necem podobnem tak mi to vrta v hlave a snazim se prijit na to co bud ja nebo Bob a ty dva architekti nevidime. (BTW. jsou fakt dva ruzni, kazdy jina narodnost a kazdy v jine bance)

Nikde netvrdím, že nemůžete najít aplikaci, kde by se nerelační model, nerelační db nepoužil šikovně, nebo naopak, kde by se relační databáze použila dobře. Pro SQL existuje celá řada antipatternů, poznaných praxí, což znamená, že na velkém množství projektů se SQL relační databáze používají nevhodně. Viděl jsem hrůzné modernizace aplikací do SQL, které byly postavené na tom, že do relační databáze se uložily bloby obsahující data a databáze se zneužila jako storage.

SQL relační databáze se existují od 80 let, v masovějším nasazení od začátku devadesátých let. Doporučení na základě praxe, jak s těmito databázemi pracovat jsou k dispozici spíš tak od druhé poloviny devadesátých let. Dá se setkat s lidmi, s aplikacemi, které sice používají SQL relační databáze, ale jsou ukotvení v COBOLu, v IMS, .. Ani s jedním z těch zmíněných systémů bych dělat fakt nechtěl, ale sloužily, dodnes slouží někde přes 50 let, a vůči tomu, co bylo před těmito systémy představovaly neskutečný pokrok.

250

Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?

« kdy: 08. 09. 2018, 06:47:25 »

Vlastnosti rotačních disků (rychlé sekvenční čtení, pomalé čtení s náhodným přístupem) byl asi jen jeden z faktorů proč se rozšířily relační SQL databáze.

1. Relace (tabulky) jsou vlastně množiny, což je jednodušší abstrakce než stromy (grafy). 1D tabulka má tu výhodu, že se s ní dobře jednoduše mentálně pracuje. Když pracujete s fakturou, zajímají vás položky faktury a už vás nezajímají složky, kde je faktura zařazena. Pokud pracuji s fakturami, tak mne nezajímají položky faktur, atd. Relační model není tak obecný jako síťový, ale je dostatečně silný, a velice jednoduchý.

2. Relační databáze byly navrženy pro uživatele - umožňují neprogramátorům pracovat s daty. Tuto vlastnost konkurenční systémy nikdy ve větším měřítku nenabídly - a je to dáno možnostmi a názorností a jednoduchostí relačního modelu. Ono ručně pracovat se stromy pro laika není to pravé ořechové.

3. Relační model byl doplněný o SQL - opět jednoduchý, ale dostatečně silný nástroj. A standardizace, byť ne vždy dokonalá je neskutečně silný nástroj. Pokud umíte pracovat s Mongem, umíte pracovat s Mongem, ale už nikoliv s čímkoliv jiným. Pokud umíte SQL, tak vytvoříte tabulky a dotazy na Oracle, MSSQL, MySQL, Postgresu, SQLite. Na určité úrovni nemusíte řešit detaily a základy jsou stejné. Univerzální dotazovací jazyk nabídly pouze relační SQL databáze. Resp. byly pokusy i u dalších modelů, ale bez výraznějšího rozšíření.

4. Tabulka je implementačně halda. Struktura, která se jednoduše implementuje. Navíc v kombinaci s indexy, kterých můžete mít k haldě tolik kolik potřebujete můžete mít rychlý přístup přes různé atributy. Halda (případně pole) je velice efektivní struktura. Na uložení stromu potřebuje výrazně více paměti.

Ve výsledku je důležitá abstrakce a SQL. Obojí umožňuje pracovat s daty komukoliv. Jestli v reálu data budou uložená na SSD nebo v RAMce, jestli budou uložená v poli, v hash mapě nebo v nějaké stromové struktuře je úplně jedno .. v momentě, kdy bude dost RAM, abych data uložil na disk. Co vždy ale bude důležité, že kdokoliv, kdo má práva a trochu znalostí se může na data podívat z Excelu, z libovolné aplikace a není omezen programátorem.

Hmm tak ted nevim... :-)
Na jednu stranu jsem rad, ze se ozval odbornik.
Na druhou stranu prave kvuli tvemu hobby muze byt tvuj nazor zkresleny.

Neuvedomuju si, ze bych potkal uzivaka kterej by umel aspon zaklad SQL, nebo si napojit excel na databazi.
Mozna mam jen smulu.

Já takových uživatelů potkávám desítky ročně. Nově jsem se dozvěděl, že např. s databázemi přímo pracují intenzivně testeři. Jinak, kdekoliv, kde je databáze dostupná, a jsou v ní zajímavá data, tak se data vytěžují. U jednodušších aplikací přímo. Je to otázkou oboru, velikosti firmy, kde je několik lidí, případně celé týmy v roli datových analytiků. Většina programátorů využívá možnosti dívat se na svá data, aniž by ještě měli připravenou svou aplikaci a mohli se dívat na data skrze svůj interface.

Věřím, že se můžete pohybovat v doméně, kde přímý přístup není realizovatelný (nebo snadno realizovatelný), a pak samozřejmě, takovou zkušenost nemůžete mít. Pokud Vám někde běží databáze v hostingu, tak z venku se k ní většinou nedostanete - a v momentě, kdy ztratíte svobodu, a data analyzujete jenom prostřednictvím vyexportovaným naimportovaných csv, tak Vás to rychle přestane bavit.

Alespoň okrajově sleduji výzkum v oboru databází, a už možná déle než 20 let se čeká, až se zbavíme omezení IO. První paměťové databáze jsou tu od devadesátých let. Pak se storage části databází budou přepisovat. Ale že by se opustil relační model - k tomu není důvod. Ve výzkumu to není tak vyhrocené - a je vidět prolínání některých konceptů nebo vzájemné obohacování - praxe ukázala, že držet se dogmaticky čistoty jednoho modelu není praktické (což neznamená, že je praktické dělat opičárny). SQL dnes už není čistě relační jazyk - podporuje rekurzi, analytické funkce, neatomické typy, a k nim příslušné dotazovací jazyky XPath a JSONPath. ANSI SQL 2020 by mělo integrovat GraphQL.

251

Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?

« kdy: 07. 09. 2018, 20:45:06 »

Vlastnosti rotačních disků (rychlé sekvenční čtení, pomalé čtení s náhodným přístupem) byl asi jen jeden z faktorů proč se rozšířily relační SQL databáze.

1. Relace (tabulky) jsou vlastně množiny, což je jednodušší abstrakce než stromy (grafy). 1D tabulka má tu výhodu, že se s ní dobře jednoduše mentálně pracuje. Když pracujete s fakturou, zajímají vás položky faktury a už vás nezajímají složky, kde je faktura zařazena. Pokud pracuji s fakturami, tak mne nezajímají položky faktur, atd. Relační model není tak obecný jako síťový, ale je dostatečně silný, a velice jednoduchý.

2. Relační databáze byly navrženy pro uživatele - umožňují neprogramátorům pracovat s daty. Tuto vlastnost konkurenční systémy nikdy ve větším měřítku nenabídly - a je to dáno možnostmi a názorností a jednoduchostí relačního modelu. Ono ručně pracovat se stromy pro laika není to pravé ořechové.

3. Relační model byl doplněný o SQL - opět jednoduchý, ale dostatečně silný nástroj. A standardizace, byť ne vždy dokonalá je neskutečně silný nástroj. Pokud umíte pracovat s Mongem, umíte pracovat s Mongem, ale už nikoliv s čímkoliv jiným. Pokud umíte SQL, tak vytvoříte tabulky a dotazy na Oracle, MSSQL, MySQL, Postgresu, SQLite. Na určité úrovni nemusíte řešit detaily a základy jsou stejné. Univerzální dotazovací jazyk nabídly pouze relační SQL databáze. Resp. byly pokusy i u dalších modelů, ale bez výraznějšího rozšíření.

4. Tabulka je implementačně halda. Struktura, která se jednoduše implementuje. Navíc v kombinaci s indexy, kterých můžete mít k haldě tolik kolik potřebujete můžete mít rychlý přístup přes různé atributy. Halda (případně pole) je velice efektivní struktura. Na uložení stromu potřebuje výrazně více paměti.

Ve výsledku je důležitá abstrakce a SQL. Obojí umožňuje pracovat s daty komukoliv. Jestli v reálu data budou uložená na SSD nebo v RAMce, jestli budou uložená v poli, v hash mapě nebo v nějaké stromové struktuře je úplně jedno .. v momentě, kdy bude dost RAM, abych data uložil na disk. Co vždy ale bude důležité, že kdokoliv, kdo má práva a trochu znalostí se může na data podívat z Excelu, z libovolné aplikace a není omezen programátorem.
 

252

Software / Re:Child-prvek

« kdy: 03. 09. 2018, 18:59:30 »

Mám prosbu: existuje rodičovský prvek. Jak se nazývá jemu podřazený prvek? Mám to v textu jako child-prvek (jedná se o vzdálenost mezi child-prvky uvnitř rodičovského pole). Dětský prvek? Google mi nějak nic nenachází...

V češtině se používá termín "potomek"

253

Vývoj / Re:Jak se efektivně učit programovat?

« kdy: 03. 09. 2018, 06:43:31 »

Ako ste sa zacali ucit programovat a postupne sa vtom rozvijali? Uz som sa skusal ucit HTML a CSS, C++ a Python. No moj problem je ze vzdy sa naucim zaklady skusam nejake jednoduche priklady. A postupne stratim motivaciu. V podstate to mam takto vo vsetkom. Ked nepracujem na nejakom vyuzitelnom projekte. Zadat si ako novacik nejaky zlozitejsi projekt mi pride nerealne. Nejake napady? Popripade postupy ako ste zacinali?

Začínal jsem tak, že jsem opisoval programy z VTM, Abíčka, elektroniky. Pak jsem si koupil knížku o assembleru, a přepsal a pochopil příklady. A pak jsem napsal jednu knihovnu v assembleru. Pak na výšce už člověk musel napsat kód pro semestrálky, a diplomky. Zápočet je docela dobrá motivace. Nicméně relativně rychle jsem se dostal do praxe a napřed psal prográmky (makra) ve VBA pro lidi, co potřebovali automatizovat office (většinou pár set řádek). Pak jsem do jednoho většího projektu nastoupil jako junior a tak jsem se dostal k reálnému programování.

Žádný učený z nebe nepadá, a psát si doma do šuplíku větší projekty je nesmysl. Navíc doma se sám člověk až tak toho nenaučí - může to být dost velká nuda, a navíc si člověk může zafixovat špatné návyky. Ale od toho jsou juniorské pozice - dají se najít firmy, které vezmou juniora bez praxe, co chce programovat. Samozřejmě, že pokud si řekne o nereálný plat, tak neprojde pohovorem. Musíte to brát tak, že junior (bez zkušeností na reálných projektech) je pro firmu ekonomicky spíš zátěž. Nicméně jsou už firmy, které chápou, že bez juniorů nejsou senioři.

Moje první roky v IT jsem si vydělával tak na nájem a na pivko. Ale dostal jsem se k technologiím, k reálným projektům. Něco jiného dnes mají studenti z VŠ. Tam si je odchytávají už ve škole firmy a samy usazují na juniorské pozice.

Programování má dost dimenzí - od vlastního kódování (což je docela jednoduché), zvládnutí API (což může trvat), po sociální dimenzi (komunikace se zákazníkem, uživatelem, zaměstnavatelem) až po psychologickou dimenzi (je to kreativní práce, ale ne vždy člověk píše kód, který ho baví, ne vždy je v pohodě, ale termíny se musí plnit, a kód se musí napsat, ať se člověku chce nebo nechce).

Jakmile člověk zvládne příklady, tak je nejlepší jít rovnou do praxe (brigáda, částečný úvazek, ...). Samozřejmě, že se člověk musí adekvátně ocenit, by si rovnou nezavřel vrátka. V juniorské pozici by člověk měl zůstat rok, dva, a pak se vše restartuje, takže to není o vyjednávání do konce života.

254

Vývoj / Re:Proč ten hype okolo Go?

« kdy: 02. 09. 2018, 18:52:58 »

Rozumím tomu, co píšete ale nerozumím tomu "Proč". Pokud má být GO náhradou za C, tak je moc pomalé, protože GC. Pokud to má být jazyk na složité backendy (myslím, že i v GO dokumenatci se píše, že je to na backend), tak potom nedosahuje kvalit Javy, protože možnost nechat handling errorru na vyšší vrstvě  programu pomoci "throws" je killer feature exception systému. Mám pocit, ze vkládali moc velké naděje do gorutines, které se ukázaly jako mylné. Jednoduchý backend je tak nějak protimluv. Od backendu se očekává, že bude robustní a promyšlený a budou se k němu připojovat klienti, už z hlediska bezpečnosti a konzistence je většina zodpovědnosti na backendu.

A go je o dost pomalejší než Java a než C.

Takže se vlastně točíme v kruhu...

Vy řeknete : Go je nízkoúrovňový jazyk.
Já řeknu: Oproti C je to (strašně moc)pomalé.

Vy řeknete: Go je jazyk na bakcend s garbage collectorem.
Já řeknu: Java je kvalitnější, ozkoušená, rychlejší a má lepší garbage collector.

Vy řeknete: Go je pro "začínající" programátory.
Já řeknu: Má to pointery a pokud správně nastavíte prostředí a donutíte všechny "juniory" používat pouze throws místo try{}catch{} tak je i ta java vlastně jednodušší.

Vy řeknete (to už fabuluju): je to pro začínající osamělé autistické programátory bez kamarádů, co by jim nastavili prostředí.
Já řeknu: Freepascal + Lazarus IDE. Pascal byl vyvinut někdy dávno, když jsem byl ještě malé trollítko právě na učení se programovat.

Prostě mám pocit, že se snazíte zastrčit (minimálně argumentačně) příliš tlustou štangly do příliš malého otvoru. Může se to procpat penězi od google, možná, já osobně tomu nevěřím. viz https://www.youtube.com/watch?v=H9ZAPab3kpA

Dokud se na Go budete dívat optikou Javy, tak to nepochopíte. Go je reakce na Javu a C++, dělat věci jednoduše a jinak. Můžete s tím souhlasit nebo nesouhlasit.

255

Vývoj / Re:Proč ten hype okolo Go?

« kdy: 02. 09. 2018, 17:17:17 »

Ty si fakt kaspar. Java tu bude davno po tom, co ty uz davno budes prdet do hliny. A co takhle neco k GO bys tam nemel? Ja si muzu vysilovat nebo nevysilovat jak se mi zachce, ty potouchlej, zakomplexovanej, nekonstruktivni paznechte:) napis neco o Go a jak si ho zkousel, dej nejakej zajimavej odkaz. Jak resis ty error handling? v cem vidis plusy a minusy.

A ted vyskoc.

https://github.com/search?l=Go&q=golang&type=Repositories

článků o error handling najdete tunu - oblíbené téma. Plusy jsou zřejmé, chyby ošetřujete explicitně velice blízko vzniku nebo explicitně ignorujete. je tím vynucený hodně defenzivní styl programu - což někomu může vyhovovat, jelikož je ošetření chyb zdůrazněné, nebo zase někomu vyhovovat nemusí - bo se může ztrácet původní myšlenka - nicméně by se nemělo stávat, že by neošetřená chyba probublala někam výš, což se u výjimek stát může a bere se i jako záměr. Tím se fixuje kód - nemáte tam tolik stupňů volnosti. Go je nízkoúrovňový jazyk - styl programování je jiný než u Javy. Berte to jako pohodlnější verzi Cčka - a většina kódu, který vzniká v Go by se programoval v C nebo v C++.