Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: andy 03. 06. 2016, 13:14:06
-
Ahoj. Casto sa tu preberaju rozne alternativne jazyky. Da sa to vobec pred klientom nejako obhajit (a aj na mensie projekty)? Napr by som velmi chcel skusit urobit web v golang, ale ako na to? Nehovorim, ze web kde navstevnost 1 za tyzden, tam skor php a zdielany hosting, ale nieco co ma realnu navstevnost a generuje zisk.
-
Ne. GO je špatný jazyk a nikdy se nerozšíří.
Nepřináší nic extra navíc oproti ostatním jazykům.
Kdysi jsem si o něm přečetl hezký článek v kterém bylo víc kritiky než chváli a díky němu jsem s ním neztrácel čas.
Bylo pro mne překvapením že jazyk od tvůrců plan 9 je tak fádní.
-
klidne casem vymeni python za go.
paralelizace v go se mi libi.
-
Go je uz celkom rozsireny, mozno aj viac ako D. Ako python asi nie, ale je to kompilovany jazyk s celkom slusnou std kniznicou a co som si tak skusal, tak vykon a pamatova narocnost su ok (na gc jazyk). Je to trochu iny pristup, ale vyslovene spatne sa mi to teda nezda. Jedine coho by som sa obaval, ze google si zajtra povie, ze go je deprecated (ako pri inych ich projektoch).
Keby som si robil sluzbu typu zdielanie suborov, tak volba je jasna.
-
Ahoj. Casto sa tu preberaju rozne alternativne jazyky. Da sa to vobec pred klientom nejako obhajit (a aj na mensie projekty)? Napr by som velmi chcel skusit urobit web v golang, ale ako na to? Nehovorim, ze web kde navstevnost 1 za tyzden, tam skor php a zdielany hosting, ale nieco co ma realnu navstevnost a generuje zisk.
Go je dost dobrý jazyk s kvalitní implementací, nicméně poněkud jednoduchý (záměrně). Má kvalitní GC a hodí se na jednodušší aplikační servery, ale z hlediska řekněme elegance a estetičnosti je mnohem zajímavější Swift. Je možné, že časem budou tyto dva jazyky konvergovat.
-
Go je dost dobrý jazyk s kvalitní implementací, nicméně poněkud jednoduchý (záměrně). Má kvalitní GC a hodí se na jednodušší aplikační servery, ale z hlediska řekněme elegance a estetičnosti je mnohem zajímavější Swift. Je možné, že časem budou tyto dva jazyky konvergovat.
Pekne, ale otazka nestala, ze aky jazyk je ako dobry.. Da sa proste dajme tomu freelancovat s niecim menej rozsirenym?
-
Ahoj. Casto sa tu preberaju rozne alternativne jazyky. Da sa to vobec pred klientom nejako obhajit (a aj na mensie projekty)? Napr by som velmi chcel skusit urobit web v golang, ale ako na to? Nehovorim, ze web kde navstevnost 1 za tyzden, tam skor php a zdielany hosting, ale nieco co ma realnu navstevnost a generuje zisk.
Jaky ma smysl delat web v Go? Misto v necem v cem byl web stvoren?
http://learnbchs.org/ (http://learnbchs.org/)
-
Go je dost dobrý jazyk s kvalitní implementací, nicméně poněkud jednoduchý (záměrně). Má kvalitní GC a hodí se na jednodušší aplikační servery, ale z hlediska řekněme elegance a estetičnosti je mnohem zajímavější Swift. Je možné, že časem budou tyto dva jazyky konvergovat.
Pekne, ale otazka nestala, ze aky jazyk je ako dobry.. Da sa proste dajme tomu freelancovat s niecim menej rozsirenym?
Určitě dá, jen nebudeš mít žádné zakázky.
-
Bez problémů... Momentálně do něj přepisuji 2 projekty z node.js. Produktivita není o moc nižší než Python/Ruby/Node.js, počet řádků kódu je skoro 1:1, stabilita daná typováním, paralelizace bezkonkurenční, výborná standardní knihovna, slušná komunita. To vše jednoduché, snadno pochopitelné, extrémně rychlá kompilace, kroskompilace nastavením proměné prostředí. Díky statickému linkování a kroskompilaci ultra jednoduchá distribuce. Na server a systémovější věci asi momentálně těžko budeš hledat něco lepšího. Když v poslední době narazím na něco zajímavého, v zápětí zjistím, že je to zpravidla napsáno v go.
-
... by som velmi chcel skusit urobit web v golang ...
...Da sa to vobec pred klientom nejako obhajit ... ?
Pozeram teraz na ten GOlang s otvorenou hubou :D
Chel som si len jednoducho spravit standardny priklad: ako sa conectnem na databazu a zacat v tom pracovat a ono to nejde...
Narazil som pritom na to, aky je to hrozny hybrid:
Na prvy pohlad C syntax {..}, ale ... deklaracie premennych ako v Pascale: var foo int
raz premennu deklaruju inokedy nie ...
var i int
var k = 0
Potom = vs :=
Nazvy funkcii/metod zacinaju velkymi pismenami ako v C# i tie tradicne, ktore pozname 30+ rokov z C: Println, Printf, Sprintf
Tie importy vypadaju tiez hnusne:
import (
"fmt"
"database/sql"
_ "github.com/mattn/go-adodb"
"os"
)
To co je github..com ? to musim byt online, aby som to mohol importovat ?
Vypada to vsecko jako raketova veda ..
Dokumentacia je o hovne ... mozes sa obratit akurat na StackOverflow ...
Dozadeke co to ma byt ? ved C++ je oproti tomu rajska zahradka.
Pripada mi to o moc horsi navrh, ako kedysi PL/I ktore malo ambicie nahtradit COBOL a Fortran a preto to skapalo.
Ak to niekto chce pouzivat musi mat na to naozaj dobry zaludok a byt pripraveny na riesenie nestandardnych problemov... asi tak ako si kupit namiesto benzinu alebo diesla hybrid.
Golang je totalne UGLY ! Toto sa nikdy nemoze ujat v praxi. Toto nikdy nemoze konkurovat Jave, Perlu, alebo Pythonu co tu niektori stale zatracuju.
GOlang mazem a uz nechcem o nom pocut !
-
Go je uz celkom rozsireny, mozno aj viac ako D. Ako python asi nie, ale je to kompilovany jazyk s celkom slusnou std kniznicou a co som si tak skusal, tak vykon a pamatova narocnost su ok (na gc jazyk). Je to trochu iny pristup, ale vyslovene spatne sa mi to teda nezda. Jedine coho by som sa obaval, ze google si zajtra povie, ze go je deprecated (ako pri inych ich projektoch).
Keby som si robil sluzbu typu zdielanie suborov, tak volba je jasna.
Rozsirenejsi ako D? no tak to je celkom uspech... dajte mi vediet ked sa go dostane aspon na 0,5%
-
D ma celkom zaujal, ale GO ma znechutilo !
-
Ohladom toho D - je tu o hodne dlhsie a najvacsi jeho uspech bol, ze v tom facebook urobil nejaky tool..
Mikrom - prejdi si tutorial. A dokumentacia je strucna, ale mne staci.
Bez problémů... Momentálně do něj přepisuji 2 projekty z node.js. Produktivita není o moc nižší než Python/Ruby/Node.js, počet řádků kódu je skoro 1:1, stabilita daná typováním, paralelizace bezkonkurenční, výborná standardní knihovna, slušná komunita. To vše jednoduché, snadno pochopitelné, extrémně rychlá kompilace, kroskompilace nastavením proměné prostředí. Díky statickému linkování a kroskompilaci ultra jednoduchá distribuce. Na server a systémovější věci asi momentálně těžko budeš hledat něco lepšího. Když v poslední době narazím na něco zajímavého, v zápětí zjistím, že je to zpravidla napsáno v go.
Ako freelancer?
-
Mikrom - prejdi si tutorial. A dokumentacia je strucna, ale mne staci.
To som si uz presiel.
Jazyk je tazkopadny a neponuka nic extra, co by nebolo v inom slusnom jazyku.
Pokusy s GO som definitivne ukoncil.
-
No cloveka ktory dokaze pouzit c++ v spojeni rajska zahradka asi tazko presvedcim a vlastne ma tvoj pohlad na ten jazyk nezaujima. Navyse toto vlakno nie je o tom, ci je to dobry jazyk.
-
No cloveka ktory dokaze pouzit c++ v spojeni rajska zahradka asi tazko presvedcim a vlastne ma tvoj pohlad na ten jazyk nezaujima. Navyse toto vlakno nie je o tom, ci je to dobry jazyk.
Tento thread ma inspiroval si ten jazyk vcera vyskusat. A ked som v tom zacal pisat, rozculilo ma to tak, ze som sa tu musel trochu vyventilovat. Je lespie dat to zo seba von, ako nosit to v sebe.
Diky za nastartovanie threadu ;D
-
No cloveka ktory dokaze pouzit c++ v spojeni rajska zahradka asi tazko presvedcim a vlastne ma tvoj pohlad na ten jazyk nezaujima. Navyse toto vlakno nie je o tom, ci je to dobry jazyk.
Tento thread ma inspiroval si ten jazyk vcera vyskusat. A ked som v tom zacal pisat, rozculilo ma to tak, ze som sa tu musel trochu vyventilovat. Je lespie dat to zo seba von, ako nosit to v sebe.
Diky za nastartovanie threadu ;D
Tak furt to je lepší než Java ;)
-
Co je na Javě špatného? Nejpopulárnější jazyk s nejlepšími knihovnami. Podle mě nemá cenu ztrácet čas s čímkoli jiným.
-
Co je na Javě špatného? Nejpopulárnější jazyk s nejlepšími knihovnami. Podle mě nemá cenu ztrácet čas s čímkoli jiným.
Oproti GO pomalá kompilace a pomalý start aplikací. To je problém všech JVM jazyků.
-
No cloveka ktory dokaze pouzit c++ v spojeni rajska zahradka asi tazko presvedcim a vlastne ma tvoj pohlad na ten jazyk nezaujima. Navyse toto vlakno nie je o tom, ci je to dobry jazyk.
Tento thread ma inspiroval si ten jazyk vcera vyskusat. A ked som v tom zacal pisat, rozculilo ma to tak, ze som sa tu musel trochu vyventilovat. Je lespie dat to zo seba von, ako nosit to v sebe.
Diky za nastartovanie threadu ;D
Tak furt to je lepší než Java ;)
Go nemá generika pro uživatelsky definované typy, což ho IMO činí v podstatě nepoužitelným.
-
No cloveka ktory dokaze pouzit c++ v spojeni rajska zahradka asi tazko presvedcim a vlastne ma tvoj pohlad na ten jazyk nezaujima. Navyse toto vlakno nie je o tom, ci je to dobry jazyk.
Tento thread ma inspiroval si ten jazyk vcera vyskusat. A ked som v tom zacal pisat, rozculilo ma to tak, ze som sa tu musel trochu vyventilovat. Je lespie dat to zo seba von, ako nosit to v sebe.
Diky za nastartovanie threadu ;D
Tak furt to je lepší než Java ;)
Go nemá generika pro uživatelsky definované typy, což ho IMO činí v podstatě nepoužitelným.
Pravda, nemá. Go je záměrně co nejjednodušší.
-
Ne. GO je špatný jazyk a nikdy se nerozšíří.
Nepřináší nic extra navíc oproti ostatním jazykům.
Kdysi jsem si o něm přečetl hezký článek v kterém bylo víc kritiky než chváli a díky němu jsem s ním neztrácel čas.
Bylo pro mne překvapením že jazyk od tvůrců plan 9 je tak fádní.
Souhlasím se vším, kromě toho, že se nerozšíří. Go z technického pohledu nedává moc smysl. Řeší problémy, které C++ vyřešilo lépe nejpozději ve standardu C++11, nebo které by se daly v C/C++ vyřešit lépe a s menším úsilím, než vytvořením nového jazyka. K tomu přidává svoje nové problémy, které se autoři a propagátoři jazyka pokouší zamaskovat. To ale bohužel neznamená, že se nerozšíří z jiných důvodů, např. marketingových.
-
Ne. GO je špatný jazyk a nikdy se nerozšíří.
Nepřináší nic extra navíc oproti ostatním jazykům.
Kdysi jsem si o něm přečetl hezký článek v kterém bylo víc kritiky než chváli a díky němu jsem s ním neztrácel čas.
Bylo pro mne překvapením že jazyk od tvůrců plan 9 je tak fádní.
Souhlasím se vším, kromě toho, že se nerozšíří. Go z technického pohledu nedává moc smysl. Řeší problémy, které C++ vyřešilo lépe nejpozději ve standardu C++11, nebo které by se daly v C/C++ vyřešit lépe a s menším úsilím, než vytvořením nového jazyka. K tomu přidává svoje nové problémy, které se autoři a propagátoři jazyka pokouší zamaskovat. To ale bohužel neznamená, že se nerozšíří z jiných důvodů, např. marketingových.
Tak C++ má taky určité problémy. Go je na něco příliš jednoduchý (zmíněná generika) a používám ho jen pro jednodušší servery, ale své výhody má. Nicméně nejlepší je z nativně překládaných jazyků Swift.
-
Go nema take naroky, je kompilovany a ma precizny gc, ktory ma pauzy v radoch ms aj pri GB heapoch. Vacsinou je cela apka jeden exac. Uz na prve osahanie je to fakt rychle, kludne mozes mat apku prevadzkovanu na raspberry pi (teda nie ze by som to chcel robit). Aj vdaka tejto efektivnosti sa to podla mna dost hodi na microservices, ktore su ale micro nie len funkcnostou. Vlastne je to robene na web. Nie je to uplne univerzalny jazyk.
Go nemá generika pro uživatelsky definované typy, což ho IMO činí v podstatě nepoužitelným.
prakticky je velmi pouzitelny https://github.com/golang/go/wiki/GoUsers
-
Souhlasím se vším, kromě toho, že se nerozšíří. Go z technického pohledu nedává moc smysl. Řeší problémy, které C++ vyřešilo lépe nejpozději ve standardu C++11, nebo které by se daly v C/C++ vyřešit lépe a s menším úsilím, než vytvořením nového jazyka. K tomu přidává svoje nové problémy, které se autoři a propagátoři jazyka pokouší zamaskovat. To ale bohužel neznamená, že se nerozšíří z jiných důvodů, např. marketingových.
O nahrazení C++ se snaží například Rust. Na Go přechází lidi od skriptovacích jazyků a od Javy. Třeba pro vývoj AAA her se IMO Go nikdy nerozšíří. Tam asi bude vadit garbage collector. Rust vypadá nadějně.
-
Tak Go je asi nejvhodnější na síťové věci a opravdu zatížené weby (což u nás takových asi moc není). Ale vzhledem k tomu, že pracnost psaní není o moc vyšší než v těch zmiňovaných Ruby/Python/Node, tak je to asi celkem jedno. Když ale v rámci učení se přepíšete 200 řádkový Perlovský skript a místo doby běhu několika minut to díky triviální masivní paralelizaci v síťovém prostředí běží necelých 6sekund, tak je to celkem ohromující.
-
Tak C++ má taky určité problémy. Go je na něco příliš jednoduchý (zmíněná generika) a používám ho jen pro jednodušší servery, ale své výhody má. Nicméně nejlepší je z nativně překládaných jazyků Swift.
Máte na mysli nějaké konkrétní problémy C++, které by řešily Go nebo Swift? Snad každý jazyk má své výhody (a nevýhody). Ale je otázka, jestli ty výhody stojí za tu námahu se dotyčným jazykem zabývat. Tvrzení, že Swift je nejlepší, nemá bez uvedení hodnotících kritérií vůbec žádný smysl.
-
Tak C++ má taky určité problémy. Go je na něco příliš jednoduchý (zmíněná generika) a používám ho jen pro jednodušší servery, ale své výhody má. Nicméně nejlepší je z nativně překládaných jazyků Swift.
Máte na mysli nějaké konkrétní problémy C++, které by řešily Go nebo Swift? Snad každý jazyk má své výhody (a nevýhody). Ale je otázka, jestli ty výhody stojí za tu námahu se dotyčným jazykem zabývat. Tvrzení, že Swift je nejlepší, nemá bez uvedení hodnotících kritérií vůbec žádný smysl.
Jistě. C++ má poněkud omezený polymorfismus. Go sice také, ale úplně jinak (nemá dědičnost, jen rozhraní). Swift má rozhraní, dědičnost (trvá-li na ní někdo) i hodnotové typy, z pohledu OOP je nejflexibilnější. K tomu má ještě mnoho funkcionálních rysů. Prostě v ničem podstatném neomezuje, kdežto v C++ i Go člověk dříve či později narazí a musí začít různá omezení obcházet, což je opruz.
-
Jistě. C++ má poněkud omezený polymorfismus. Go sice také, ale úplně jinak (nemá dědičnost, jen rozhraní). Swift má rozhraní, dědičnost (trvá-li na ní někdo) i hodnotové typy, z pohledu OOP je nejflexibilnější. K tomu má ještě mnoho funkcionálních rysů. Prostě v ničem podstatném neomezuje, kdežto v C++ i Go člověk dříve či později narazí a musí začít různá omezení obcházet, což je opruz.
Asi OOP moc nerozumím... V čem je v C++ omezený polymorfismus nebo méně funkcionálních rysů, ať už obecně, nebo v porovnání se Swift? C++ má rozhraní (vícenásobnou dědičnost), dědičnost, i hodnotové typy, k tomu i trochu reflexe. Taky má lambdy, std::function, std::bind a template metaprogramming. Myslím, že turingovsky úplnému (možná jenom skoro) čistě funkcionálnímu compile-time templatovému jazyku v C++ se generické typy ve stylu Swiftu nebo Javy funkčností ani nepřibližují.
-
Nie ze by to malo nejake prakticke uplatnenie (zatial), ale https://www.reddit.com/r/programming/comments/4l5is8/java_generics_are_turing_complete/
-
Jistě. C++ má poněkud omezený polymorfismus. Go sice také, ale úplně jinak (nemá dědičnost, jen rozhraní). Swift má rozhraní, dědičnost (trvá-li na ní někdo) i hodnotové typy, z pohledu OOP je nejflexibilnější. K tomu má ještě mnoho funkcionálních rysů. Prostě v ničem podstatném neomezuje, kdežto v C++ i Go člověk dříve či později narazí a musí začít různá omezení obcházet, což je opruz.
Asi OOP moc nerozumím... V čem je v C++ omezený polymorfismus nebo méně funkcionálních rysů, ať už obecně, nebo v porovnání se Swift? C++ má rozhraní (vícenásobnou dědičnost), dědičnost, i hodnotové typy, k tomu i trochu reflexe. Taky má lambdy, std::function, std::bind a template metaprogramming. Myslím, že turingovsky úplnému (možná jenom skoro) čistě funkcionálnímu compile-time templatovému jazyku v C++ se generické typy ve stylu Swiftu nebo Javy funkčností ani nepřibližují.
V Go můžete třídě implentovat rozhraní bez toho, abyste měnil její definici nebo vytvářel odvozenou třídu. https://medium.com/@matryer/golang-advent-calendar-day-one-duck-typing-a513aaed544d#.18cse2sme
-
Jistě. C++ má poněkud omezený polymorfismus. Go sice také, ale úplně jinak (nemá dědičnost, jen rozhraní). Swift má rozhraní, dědičnost (trvá-li na ní někdo) i hodnotové typy, z pohledu OOP je nejflexibilnější. K tomu má ještě mnoho funkcionálních rysů. Prostě v ničem podstatném neomezuje, kdežto v C++ i Go člověk dříve či později narazí a musí začít různá omezení obcházet, což je opruz.
Asi OOP moc nerozumím... V čem je v C++ omezený polymorfismus nebo méně funkcionálních rysů, ať už obecně, nebo v porovnání se Swift? C++ má rozhraní (vícenásobnou dědičnost), dědičnost, i hodnotové typy, k tomu i trochu reflexe. Taky má lambdy, std::function, std::bind a template metaprogramming. Myslím, že turingovsky úplnému (možná jenom skoro) čistě funkcionálnímu compile-time templatovému jazyku v C++ se generické typy ve stylu Swiftu nebo Javy funkčností ani nepřibližují.
V Go můžete třídě implentovat rozhraní bez toho, abyste měnil její definici nebo vytvářel odvozenou třídu. https://medium.com/@matryer/golang-advent-calendar-day-one-duck-typing-a513aaed544d#.18cse2sme
To platí pouze, pokud daná třída má potřebné metody - obecně však metody nejde do třídy přidávat - viz How to add new methods to an existing type in go? (http://stackoverflow.com/questions/28800672/how-to-add-new-methods-to-an-existing-type-in-go).
-
Jistě. C++ má poněkud omezený polymorfismus. Go sice také, ale úplně jinak (nemá dědičnost, jen rozhraní). Swift má rozhraní, dědičnost (trvá-li na ní někdo) i hodnotové typy, z pohledu OOP je nejflexibilnější. K tomu má ještě mnoho funkcionálních rysů. Prostě v ničem podstatném neomezuje, kdežto v C++ i Go člověk dříve či později narazí a musí začít různá omezení obcházet, což je opruz.
Asi OOP moc nerozumím... V čem je v C++ omezený polymorfismus nebo méně funkcionálních rysů, ať už obecně, nebo v porovnání se Swift? C++ má rozhraní (vícenásobnou dědičnost), dědičnost, i hodnotové typy, k tomu i trochu reflexe. Taky má lambdy, std::function, std::bind a template metaprogramming. Myslím, že turingovsky úplnému (možná jenom skoro) čistě funkcionálnímu compile-time templatovému jazyku v C++ se generické typy ve stylu Swiftu nebo Javy funkčností ani nepřibližují.
Například nemá varianci typů nebo pattern matching. Taky nemá možnost omezovat generické parametry podle protokolů. O správě paměti se ani nezmiňuju - bez chytrých ukazatelů ani ránu. Reflexe je taky z těchto jazyků nejomezenější (to ovšem neberu jako nevýhodu, ale když už byla zmíněna...).
-
Nie ze by to malo nejake prakticke uplatnenie (zatial), ale https://www.reddit.com/r/programming/comments/4l5is8/java_generics_are_turing_complete/
Dík za odkaz, to je zajímavé a nevěděl jsem to. Ale já jsem zmínku o turingovské úplnosti myslel spíš z praktického hlediska. Tedy že v C++ lze při překladu pomocí šablon (a taky constexpr funkcí) něco netriviálního a užitečného rozhodnout nebo spočítat.
-
V Go můžete třídě implentovat rozhraní bez toho, abyste měnil její definici nebo vytvářel odvozenou třídu. https://medium.com/@matryer/golang-advent-calendar-day-one-duck-typing-a513aaed544d#.18cse2sme
V C++ obdobně fungují šablony, koncepty a popř. specializace šablon.
-
Nie ze by to malo nejake prakticke uplatnenie (zatial), ale https://www.reddit.com/r/programming/comments/4l5is8/java_generics_are_turing_complete/
Dík za odkaz, to je zajímavé a nevěděl jsem to. Ale já jsem zmínku o turingovské úplnosti myslel spíš z praktického hlediska. Tedy že v C++ lze při překladu pomocí šablon (a taky constexpr funkcí) něco netriviálního a užitečného rozhodnout nebo spočítat.
Šablonové metaprogramování je na dvě věci. Mnohem užitečnější by byla variance typů nebo extenzivní protokoly.
-
Například nemá varianci typů nebo pattern matching. Taky nemá možnost omezovat generické parametry podle protokolů. O správě paměti se ani nezmiňuju - bez chytrých ukazatelů ani ránu. Reflexe je taky z těchto jazyků nejomezenější (to ovšem neberu jako nevýhodu, ale když už byla zmíněna...).
Variance typů v C++ je docela zamotaný problém kvůli obecnosti mechanismu šablon, kdy se mohou specializace tmplt<B> a tmplt<D> zásadně lišit, i když D je třída odvozená z B. Uznávám, že pattern matching je šikovný syntaktický cukr, ale asi bych ho nepovažoval za zásadní argument pro volbu jazyka. Ohledně správy paměti: v C++ si můžu vybrat z různých mechanismů nebo si implementovat vlastní. Swift mi pro třídy nutí alokaci na haldě a reference counting.
-
Například nemá varianci typů nebo pattern matching. Taky nemá možnost omezovat generické parametry podle protokolů. O správě paměti se ani nezmiňuju - bez chytrých ukazatelů ani ránu. Reflexe je taky z těchto jazyků nejomezenější (to ovšem neberu jako nevýhodu, ale když už byla zmíněna...).
Variance typů v C++ je docela zamotaný problém kvůli obecnosti mechanismu šablon, kdy se mohou specializace tmplt<B> a tmplt<D> zásadně lišit, i když D je třída odvozená z B. Uznávám, že pattern matching je šikovný syntaktický cukr, ale asi bych ho nepovažoval za zásadní argument pro volbu jazyka. Ohledně správy paměti: v C++ si můžu vybrat z různých mechanismů nebo si implementovat vlastní. Swift mi pro třídy nutí alokaci na haldě a reference counting.
Reference counting je užitečný. Nicméně zásadní je právě flexibilní typový systém a lepší polymorfismus.
-
Šablonové metaprogramování je na dvě věci. Mnohem užitečnější by byla variance typů nebo extenzivní protokoly.
Možná byste měl tento názor prezentovat autorům standardní knihovny C++ nebo takových chuťovek, jako je boost::msm :) Trochu odbočím - zajímalo by mě, jestli je někde jednoduše vysvětlené, jak jsou všechny tyhle objektové a funkcionální vychytávky Swiftu implementované?
-
Šablonové metaprogramování je na dvě věci. Mnohem užitečnější by byla variance typů nebo extenzivní protokoly.
Možná byste měl tento názor prezentovat autorům standardní knihovny C++ nebo takových chuťovek, jako je boost::msm :) Trochu odbočím - zajímalo by mě, jestli je někde jednoduše vysvětlené, jak jsou všechny tyhle objektové a funkcionální vychytávky Swiftu implementované?
Je to v oficiální dokumentaci a kód je open source.
-
Trochu odbočím - zajímalo by mě, jestli je někde jednoduše vysvětlené, jak jsou všechny tyhle objektové a funkcionální vychytávky Swiftu implementované?
Je to v oficiální dokumentaci a kód je open source.
Můžete být trochu konkrétnější? Kde konkrétně najdu popis, jak jsou objekty uložené v paměti, co se děje při vytvoření/rušení objektu, jak se řeší volání metod, generické typy, protokoly, atd.? Studovat kód se mi fakt, nechce, to se radši bez těchto znalostí obejdu.
-
Jistě. C++ má poněkud omezený polymorfismus. Go sice také, ale úplně jinak (nemá dědičnost, jen rozhraní). Swift má rozhraní, dědičnost (trvá-li na ní někdo) i hodnotové typy, z pohledu OOP je nejflexibilnější. K tomu má ještě mnoho funkcionálních rysů. Prostě v ničem podstatném neomezuje, kdežto v C++ i Go člověk dříve či později narazí a musí začít různá omezení obcházet, což je opruz.
Asi OOP moc nerozumím... V čem je v C++ omezený polymorfismus nebo méně funkcionálních rysů, ať už obecně, nebo v porovnání se Swift? C++ má rozhraní (vícenásobnou dědičnost), dědičnost, i hodnotové typy, k tomu i trochu reflexe. Taky má lambdy, std::function, std::bind a template metaprogramming. Myslím, že turingovsky úplnému (možná jenom skoro) čistě funkcionálnímu compile-time templatovému jazyku v C++ se generické typy ve stylu Swiftu nebo Javy funkčností ani nepřibližují.
V Go můžete třídě implentovat rozhraní bez toho, abyste měnil její definici nebo vytvářel odvozenou třídu. https://medium.com/@matryer/golang-advent-calendar-day-one-duck-typing-a513aaed544d#.18cse2sme
To platí pouze, pokud daná třída má potřebné metody - obecně však metody nejde do třídy přidávat - viz How to add new methods to an existing type in go? (http://stackoverflow.com/questions/28800672/how-to-add-new-methods-to-an-existing-type-in-go).
Děkuji za opravu. V Go neprogramuji. Špatně jsem to pochopil.
-
Ne. GO je špatný jazyk a nikdy se nerozšíří.
Nepřináší nic extra navíc oproti ostatním jazykům.
Kdysi jsem si o něm přečetl hezký článek v kterém bylo víc kritiky než chváli a díky němu jsem s ním neztrácel čas.
Bylo pro mne překvapením že jazyk od tvůrců plan 9 je tak fádní.
GO ma buducnost. Su dva hlavne dovody:
1.) Vlakna maju 2kb footprint a ma podporu tzv channel-ov co robi medziprocesovu komunikaciu az skoro trivialnou
2.) Kompilacia je neskutocne rychla. Cela std lib da kompiluje do cca 20 sek!!!
Zvysok je viac-menej podobny inym jazykom...
-
1.) Vlakna maju 2kb footprint a ma podporu tzv channel-ov co robi medziprocesovu komunikaciu az skoro trivialnou
Tohle dovede celá řada jiných jazyků pomocí knihoven (pro JVM například Akka).
2.) Kompilacia je neskutocne rychla. Cela std lib da kompiluje do cca 20 sek!!!
To je hezké, ale je to za cenu více práce na straně programátora kvůli absenci řady užitečných vlastností.
-
Ne. GO je špatný jazyk a nikdy se nerozšíří.
Nepřináší nic extra navíc oproti ostatním jazykům.
Kdysi jsem si o něm přečetl hezký článek v kterém bylo víc kritiky než chváli a díky němu jsem s ním neztrácel čas.
Bylo pro mne překvapením že jazyk od tvůrců plan 9 je tak fádní.
GO ma buducnost. Su dva hlavne dovody:
1.) Vlakna maju 2kb footprint a ma podporu tzv channel-ov co robi medziprocesovu komunikaciu az skoro trivialnou
2.) Kompilacia je neskutocne rychla. Cela std lib da kompiluje do cca 20 sek!!!
Zvysok je viac-menej podobny inym jazykom...
1) Nic extra, jde ještě míň se správnou knihovnou (mapující green threads na OS threads).
2) Rychlost kompilace není všechno.
-
Bavime sa o komercnom pouziti. Prerataj si tie kompilacie na peniaze..
-
OMG, ty snad máš placenou kompilaci? Kvalitnější jazyk je samozřejmě daleko důležitější. Kompilaci dělají stroje, takže je skoro zadarmo. Na kód zatím stroje nemáš.
-
Plateny je cas vyvojara. Kompilacia je proste zabity cas, ktory ti ubera na produktivite (a ako freelancerovi na konkurencieschopnosti). Ci ty si natahujes iny projekt, aby si efektivne vyuzil cas, ked ti kompilacia trva 5 minut?
-
Proč bych to dělal? Vývojář píše jen pár procent času. Hlavně pokud nějaký kód píšu, tak ho přece nemusím kompilovat každou chvíli. Prostě čas kompilace je u velkých javových projektů docela nepodstatný. A pokud chceš mít rychlé změny hned k dispozici, tak samozřejmě měníš věci za chodu aplikace, aby ses právě vyhnul opakované kompilaci.
-
Ale rec nie je o velkych javovych projektoch kde sa to nejako utopi..
-
Ne. GO je špatný jazyk a nikdy se nerozšíří.
Nepřináší nic extra navíc oproti ostatním jazykům.
Kdysi jsem si o něm přečetl hezký článek v kterém bylo víc kritiky než chváli a díky němu jsem s ním neztrácel čas.
Bylo pro mne překvapením že jazyk od tvůrců plan 9 je tak fádní.
GO ma buducnost. Su dva hlavne dovody:
1.) Vlakna maju 2kb footprint a ma podporu tzv channel-ov co robi medziprocesovu komunikaciu az skoro trivialnou
2.) Kompilacia je neskutocne rychla. Cela std lib da kompiluje do cca 20 sek!!!
Zvysok je viac-menej podobny inym jazykom...
1) Nic extra, jde ještě míň se správnou knihovnou (mapující green threads na OS threads).
2) Rychlost kompilace není všechno.
Nemám potřebu javistům vyvracet jejich pravou víru. Mně se v Go píše dobře, vývoj je rychlý a efektivní. Jen upozorním na to,že na jazyk, který se nikdy nerozšíří, je v něm napsáno docela dost věcí, namátkou: Grafana, OpenShift, Docker, Kubernetes, Etcd, Influxdb, Prometheus, Syncthing,...
Pokud tady někdo hodí stejnou řadu programů tak široce přijatých jako jsem uvedl já, které jsou napsány v nějakém jiném jazyce, co se nikdy nerozšířil (třeba D, J#, ...), rád se poučím. Zajímavých projektů o kterých nevím, není nikdy dost.
-
Je v Jave napsany klient nejake kryptomeny ?
V golangu ano :
https://github.com/ethereum/go-ethereum
Kapitalizace pres miliardu dolaru
http://coinmarketcap.com/currencies/ethereum/
-
Ale rec nie je o velkych javovych projektoch kde sa to nejako utopi..
Tak jsi měl říct, že se bavíš o nějakém domácím hraní, kde tě kompilace zajímá. Normálně je kompilace skoro nepodstatná, ale i tak Java ji má poměrně rychlou.
-
"(a aj na mensie projekty)"
Si aspon precitaj temu pred tym nez tu zacnes machrovat. Si myslis, ze si tu jediny co robil projekty za miliony?
-
Moze mi niekto vysvetlit co mi go prinesie oproti modernym jazykom ako Swift, F#, Rust, Scala?
V com je Go taky uzasny a revolucny?
-
go jazyk je najlepsie zhrnut high level C-cko s threadmi na trenovacich koleckach.
co sa tyka kompilacie, je fakt rychla a typovu kontrolu je dobre mat, clovek pise kod bez akychkolvek testov,
ak prejde kompilacia program je dobry -> rovno deploynut do produkcie
tie thready dnes nie su samozrejmost, su fakt rychle.. nevyhoda, treba to ocekovat mutexami.. ako hovorim, high level Ccko
tie trenovacie kolecka to sa tyka toho ze urcite veci sa z jazyka rozhodli "filozofi" vynechat, clovek co vie co robi si to prida naspet pomocou tych unsafe pointrov, ten co nevie, ten nech sa pekne hra v ohradenej zahradke
vysledny produkt binarka, webserver, alebo cez gopherjs do javascriptu na vysokej urovni kvality ( ano tie thready idu aj vo vyslednom js)
-
co sa tyka kompilacie, je fakt rychla a typovu kontrolu je dobre mat, clovek pise kod bez akychkolvek testov,
ak prejde kompilacia program je dobry -> rovno deploynut do produkcie
To je nejaky humor tohle?
-
Moze mi niekto vysvetlit co mi go prinesie oproti modernym jazykom ako Swift, F#, Rust, Scala?
V com je Go taky uzasny a revolucny?
Go není úžasné ani revoluční, oproti C(++), Swiftu a Rustu má navíc jen GC, což by ani nebyla výhoda, kdyby ten GC nebyl tak efektivní, jak ho Go od verze 1.5 má. Pokud se člověk smíří s některými omezeními (např. absence dědičnosti a generických typů), tak je to prostě jen relativně jednoduchý a rychlý jazyk pro nízkoúrovňové věci. Má také poměrně rozsáhlou standardní knihovnu.
-
Keby stacila typova kontrola na otestovanie, to by nam bolo sveta zit :D. Nie, testy sa nepisu iba na syntakticku kontrolu..
Moze mi niekto vysvetlit co mi go prinesie oproti modernym jazykom ako Swift, F#, Rust, Scala?
V com je Go taky uzasny a revolucny?
Go je iny v tom, ze implementuje nejaky teoreticky model (aj ked pre mna to ma minimalny vyznam). Mna ale zaujalo, ze je to kompilovane, ale pritom celkom komfortne, precizny a rychly gc (uz to tu spominam asi tretikrat..), celkom nizka pamatova narocnost, pre pouzitie na rpi je to podla idealne. Proste je to efektivne. Mozes mat pamatovu cache v ramci procesu bez nejakych hackov a gigantickych (poloprazdnych) heapov ako napr v jave.
Spominas rust, ale go je pritom viac 'proven'. Kym nebude v tom finalna verzia firefoxu, tak ruky prec..
-
typova kontrola je len zaciatok, ja pouzivam gometalinter, ten pusta asi 15 nastrojov na kontrolu kodu
-
typova kontrola je len zaciatok, ja pouzivam gometalinter, ten pusta asi 15 nastrojov na kontrolu kodu
Statická analýza kódů ti pořád, notabene v jazyce jako go, řeší jenom omezené množství problémů.
Pro seriózní práci potřebuješ testy, typicky alespoň jednotkové a integrační.
-
Keby stacila typova kontrola na otestovanie, to by nam bolo sveta zit :D. Nie, testy sa nepisu iba na syntakticku kontrolu..
Typová kontrola nemá se syntaxí vůbec nic společného.
-
Go je iny v tom, ze implementuje nejaky teoreticky model
Jaký model máte na mysli?
Šlo by říci, že F# implementuje lambda kalkulus s DM typovým systémem (nebo alespoň z něho vychází) a Dotty (nová verze Scaly) implementuje DOT calculus?
Keby stacila typova kontrola na otestovanie, to by nam bolo sveta zit
V některých typových systémech stačí.
-
Keby stacila typova kontrola na otestovanie, to by nam bolo sveta zit :D. Nie, testy sa nepisu iba na syntakticku kontrolu..
Mas sice pravdu ze typova kontrola na odhlaenie chyb nie vzdy staci, ale v praxi pri kvalitnom typovom systeme ti velmi urychli pracu. Clovek ktory neprogramnoval v silne typovom jazyku toto asi nepochopi... skus Haskell alebo F# a sam uvidis. Druha vec je ze silny typovy system casto aj veci strasne kompikuje a castokrat je otravne furt nieco konvertovat. Lenze ten vysledny kod je potom nepriestrelny.
pozn. C++ C# ani Java nie su silne typove jazyky, GO nepoznam.
-
Keby stacila typova kontrola na otestovanie, to by nam bolo sveta zit :D. Nie, testy sa nepisu iba na syntakticku kontrolu..
Typová kontrola nemá se syntaxí vůbec nic společného.
Ak mas premennu a typu int a volas a.f(), tak kazdy tomu nadava syntakticka chyba, ale gramaticky je to spravne. Rovnako preklepy v premennych a pod. To uz je take slovickarenie, ale zatial tu boli mozno 4 prispevky k veci..
-
Keby stacila typova kontrola na otestovanie, to by nam bolo sveta zit :D. Nie, testy sa nepisu iba na syntakticku kontrolu..
Typová kontrola nemá se syntaxí vůbec nic společného.
Ak mas premennu a typu int a volas a.f(), tak kazdy tomu nadava syntakticka chyba, ale gramaticky je to spravne. Rovnako preklepy v premennych a pod. To uz je take slovickarenie, ale zatial tu boli mozno 4 prispevky k veci..
Je dobré se vyjadřovat jasně. Syntax je o skladbě, typová kontrola je sémantika.
-
Clovek ktory neprogramnoval v silne typovom jazyku toto asi nepochopi... skus Haskell alebo F# a sam uvidis. Druha vec je ze silny typovy system casto aj veci strasne kompikuje a castokrat je otravne furt nieco konvertovat.
Mate v tom trochu zmatek. Silne typovy je treba i Python a Ruby. Asi myslite staticky typovy system.
-
Clovek ktory neprogramnoval v silne typovom jazyku toto asi nepochopi... skus Haskell alebo F# a sam uvidis. Druha vec je ze silny typovy system casto aj veci strasne kompikuje a castokrat je otravne furt nieco konvertovat.
Mate v tom trochu zmatek. Silne typovy je treba i Python a Ruby. Asi myslite staticky typovy system.
Myslím, že xxar3s měl na mysli to, jaké invarianty jde v typovém systému vyjádřit (např. v některých jazycích je typový systém tak silný, že můžete v rámci typové kontroly provádět testy - typ může říkat, že určité volání funkce vrátí určitou hodnotu).
Asi myslite staticky typovy system.
Někteří lidé si myslí, že jiný ani neexistuje - viz Does “untyped” also mean “dynamically typed” in the academic CS world? (http://stackoverflow.com/questions/9154388/does-untyped-also-mean-dynamically-typed-in-the-academic-cs-world) - dynamicky typovaný jazyk je speciálním případem staticky typovaného jazyka s jedním typem:
Bob Harper is fond of saying that languages like Scheme, Javascript, and so on should be considered typed languages with just a single type: value. I lean to this view, as it makes it possible to construct a consistent worldview using just one type formalism.
-
Myslím, že xxar3s měl na mysli to, jaké invarianty jde v typovém systému vyjádřit (např. v některých jazycích je typový systém tak silný, že můžete v rámci typové kontroly provádět testy - typ může říkat, že určité volání funkce vrátí určitou hodnotu).
Mohl byste mi ukázat, jak v nějakém šikovném typovém systému vyjádřím/definuji typ Date ? Tedy typ, který říká, že únor může mět pouze 28dní a každej přestupnej 29, etc.
Matně tuším, jak bych to dělal já. Ale zajímal by mě příklad jiných.
Dík.
-
Mohl byste mi ukázat, jak v nějakém šikovném typovém systému vyjádřím/definuji typ Date ? Tedy typ, který říká, že únor může mět pouze 28dní a každej přestupnej 29, etc.
Například v Idrisu:
import Data.Fin
%default total
prestupnyRok : Nat -> Bool
prestupnyRok rok = delitelny 400 SIsNotZ || (delitelny 4 SIsNotZ && not (delitelny 100 SIsNotZ))
where
delitelny : (x:Nat) -> Not (x = 0) -> Bool
delitelny x nz = (modNatNZ rok x nz) == Z
pocetDnuVMesici : Nat -> Fin 12 -> Nat
pocetDnuVMesici rok mesic =
case finToInteger mesic of
0 => 31
1 => 28 + (if prestupnyRok rok then 1 else 0)
2 => 31
3 => 30
4 => 31
5 => 30
6 => 31
7 => 31
8 => 30
9 => 31
10 => 30
_ => 31
-- Mesice a dny jsou cislovany od nuly.
-- Napriklad 29. unora 2004 se zapise jako MkDatum 2004 28 1.
data Datum : Type where
MkDatum : (rok:Nat) -> (mesic:Fin 12) -> (den:Fin (pocetDnuVMesici rok mesic)) -> Datum
Výstup pro chybné datum MkDatum 2003 1 28 (dny i měsíce jsou číslovány od 0) je
(input):1:18:When checking argument prf to function Data.Fin.fromInteger:
When using 28 as a literal for a Fin 28
28 is not strictly less than 28
pro správné datum MkDatum 2004 1 28
MkDatum (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (S (fromIntegerNat 1903))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
(FS FZ)
(FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS (FS FZ)))))))))))))))))))))))))))) : Datum
-
Na HN byl dnes odkaz na prezentaci o Go od Googlu. Doporučuji přečíst komentáře: https://news.ycombinator.com/item?id=11855775
-
Mohl byste mi ukázat, jak v nějakém šikovném typovém systému vyjádřím/definuji typ Date ? Tedy typ, který říká, že únor může mět pouze 28dní a každej přestupnej 29, etc.
Například v Idrisu:
Zajímavé. Díky! Budu trávit.
-
Moc hezký článek o GO :)
http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/
Dokonce i tvůrce řekl že GO je jazyk pro !začátečníky! protože potřebují v googlu s těma začátečníkama odvést práci.
To nemaj v googlu soudruzi samí elitní opice ? Někde se stala chyba ...
-
To nemaj v googlu soudruzi samí elitní opice ? Někde se stala chyba ...
vsak hovorim, C na trenovacich koleckach
-
To nemaj v googlu soudruzi samí elitní opice ? Někde se stala chyba ...
vsak hovorim, C na trenovacich koleckach
je to tak
jen tak ze zvědavosti jsem se kouknul jak se v "GO stylu" řeší reverze pole
potichu jsem zaklapl laptop a odplížil se do kouta ...
-
jen tak ze zvědavosti jsem se kouknul jak se v "GO stylu" řeší reverze pole
potichu jsem zaklapl laptop a odplížil se do kouta ...
Mas link? ;)
-
jen tak ze zvědavosti jsem se kouknul jak se v "GO stylu" řeší reverze pole
potichu jsem zaklapl laptop a odplížil se do kouta ...
Mas link? ;)
Hej pokusil sem se najít link na to vlákno (reddit) kde sem zřel tu hrůzu ale nenašel.
Bylo to nějaký čarování s interfejsama plus tam někdo doporučoval vyhnout se volání funkce pro reverzi a místo toho všude tu operaci ručně otrocky vkládat...
Jen jsem si představil jak by asi vypadala implementace (generická) něčeho složitejšího než reverze pole a měl sem dost ...
Už jen ten princip "interface" mi přijde divnej v procedurálním jazyce. U OOP lze interface chápat jako množinu protokolů které implementuje objekt. V procedurálním jazyce tak maximálně fieldy v struktuře. A co když de o číslo? String? Bool? Ty pak nemaj nic co by šlo považovat za interface.
Asi si přečtu nějakej tutoriál na GO, ať můžu kritizovat trefněji ...
-
Myslim, ze kazdy typ implementuje prazdny interface automaticky. Asi nepomohlo ;)
-
Už jen ten princip "interface" mi přijde divnej v procedurálním jazyce. U OOP lze interface chápat jako množinu protokolů které implementuje objekt. V procedurálním jazyce tak maximálně fieldy v struktuře. A co když de o číslo? String? Bool? Ty pak nemaj nic co by šlo považovat za interface.
Jakto že číslo nemá interface? A co jsou operátory +, -, *, / ? Vzduch?
-
Tak jsem to tu trochu prolitnul a koukam, ze tu je spousta negativnich nazoru od lidi co si prosli tutorial a tim skoncili. Za me je GO pomerne uspesny jazyk, ve kterem lze napsat v podstate cokoliv od utlity na bazi scriptu po pomerne komplexni aplikace...profesne jsem Javista coz me zivi, ale pokud si mam momentalne vybrat v cem budu psat nejakou utiliu nebo hobby projekt, tak volim GO. Muj pocit asi po necelem roce hobby projektu v Go je ten, ze Go vam dovoli pomerne dobre nahlednout pod poklicku vecem, ktere jsou v jave pomerne dost abstraktni a programator je muze povazovat za pomerne MAAGIC co se deje, kdesi v knihovne. :)
Rozhodne pocity nejsou negativni a GO se pro me stalo takovym pohodlnym hnizdeckem :). Jednoduche, pochopitelne a jak uz tu nekdo zminoval, myslim ze na to ze se mu nepredikovala moc zarna budoucnost, je pomerne rozsirene nemluve o mnozstvi uspesneho softu co je v nem napsane.
-
Už jen ten princip "interface" mi přijde divnej v procedurálním jazyce. U OOP lze interface chápat jako množinu protokolů které implementuje objekt. V procedurálním jazyce tak maximálně fieldy v struktuře. A co když de o číslo? String? Bool? Ty pak nemaj nic co by šlo považovat za interface.
Jakto že číslo nemá interface? A co jsou operátory +, -, *, / ? Vzduch?
V procedurálním jazyce jo.
-
Už jen ten princip "interface" mi přijde divnej v procedurálním jazyce. U OOP lze interface chápat jako množinu protokolů které implementuje objekt. V procedurálním jazyce tak maximálně fieldy v struktuře. A co když de o číslo? String? Bool? Ty pak nemaj nic co by šlo považovat za interface.
Jakto že číslo nemá interface? A co jsou operátory +, -, *, / ? Vzduch?
V procedurálním jazyce jo.
OK, dejme tomu.
Vzhledem k tomu, že interface jsou záležitost typového systému, a nikoliv paradigmatu (OOP vs Procedural vs Functional), tak bych v tom principielně problém neviděl. Pokud je GO silně typované, tak interface může sloužit k tomu, aby se hlídalo co kam teče, a co na co voláš. Jestli voláše metodu na objektu (OOP), nebo funkci předáváš objekt (FP), zda držíš stav uvnitř, nebo s ním magicky šašíš (Procedural) to už máš fuk.
-
Už jen ten princip "interface" mi přijde divnej v procedurálním jazyce. U OOP lze interface chápat jako množinu protokolů které implementuje objekt. V procedurálním jazyce tak maximálně fieldy v struktuře. A co když de o číslo? String? Bool? Ty pak nemaj nic co by šlo považovat za interface.
Jakto že číslo nemá interface? A co jsou operátory +, -, *, / ? Vzduch?
V procedurálním jazyce jo.
OK, dejme tomu.
Vzhledem k tomu, že interface jsou záležitost typového systému, a nikoliv paradigmatu (OOP vs Procedural vs Functional), tak bych v tom principielně problém neviděl. Pokud je GO silně typované, tak interface může sloužit k tomu, aby se hlídalo co kam teče, a co na co voláš. Jestli voláše metodu na objektu (OOP), nebo funkci předáváš objekt (FP), zda držíš stav uvnitř, nebo s ním magicky šašíš (Procedural) to už máš fuk.
Tak samozřejmě. V GO jsou interfejsi defakto explicitní dynamické typování. Kdyby je GO nemělo, tak by jazyk bez se statickým typováním bez něčeho na způsob šablon nemohl fungovat (dobře, mohl, ale Cčko to řeší zase trošku jinak a děsivěji).
-
Tak jsem to tu trochu prolitnul a koukam, ze tu je spousta negativnich nazoru od lidi co si prosli tutorial a tim skoncili. Za me je GO pomerne uspesny jazyk, ve kterem lze napsat v podstate cokoliv od utlity na bazi scriptu po pomerne komplexni aplikace...profesne jsem Javista coz me zivi, ale pokud si mam momentalne vybrat v cem budu psat nejakou utiliu nebo hobby projekt, tak volim GO. Muj pocit asi po necelem roce hobby projektu v Go je ten, ze Go vam dovoli pomerne dobre nahlednout pod poklicku vecem, ktere jsou v jave pomerne dost abstraktni a programator je muze povazovat za pomerne MAAGIC co se deje, kdesi v knihovne. :)
Rozhodne pocity nejsou negativni a GO se pro me stalo takovym pohodlnym hnizdeckem :). Jednoduche, pochopitelne a jak uz tu nekdo zminoval, myslim ze na to ze se mu nepredikovala moc zarna budoucnost, je pomerne rozsirene nemluve o mnozstvi uspesneho softu co je v nem napsane.
Ked je go take rozsirene preco ma podla statistik take nizke cisla? Preco sa o nom viac nepise a preco je tak malo pracovnych pozicii na go programatora? Popravde o go som pocul naposledy pred par rokmi ked ho Google s velkou pompou vypustil. Hovorilo sa o nom ako o jazyku buducnosti, ale mam pocit ze dopadol rovnako ako dart, closure, GWT a dalsie neuspesne projekty Googlu.
-
... ale mam pocit ze dopadol rovnako ako dart, closure, GWT a dalsie neuspesne projekty Googlu.
Closure používám, mám ho rád, a plánuju ho nasazovat na další a další věci.
-
Tak jsem to tu trochu prolitnul a koukam, ze tu je spousta negativnich nazoru od lidi co si prosli tutorial a tim skoncili. Za me je GO pomerne uspesny jazyk, ve kterem lze napsat v podstate cokoliv od utlity na bazi scriptu po pomerne komplexni aplikace...profesne jsem Javista coz me zivi, ale pokud si mam momentalne vybrat v cem budu psat nejakou utiliu nebo hobby projekt, tak volim GO. Muj pocit asi po necelem roce hobby projektu v Go je ten, ze Go vam dovoli pomerne dobre nahlednout pod poklicku vecem, ktere jsou v jave pomerne dost abstraktni a programator je muze povazovat za pomerne MAAGIC co se deje, kdesi v knihovne. :)
Rozhodne pocity nejsou negativni a GO se pro me stalo takovym pohodlnym hnizdeckem :). Jednoduche, pochopitelne a jak uz tu nekdo zminoval, myslim ze na to ze se mu nepredikovala moc zarna budoucnost, je pomerne rozsirene nemluve o mnozstvi uspesneho softu co je v nem napsane.
Ked je go take rozsirene preco ma podla statistik take nizke cisla? Preco sa o nom viac nepise a preco je tak malo pracovnych pozicii na go programatora? Popravde o go som pocul naposledy pred par rokmi ked ho Google s velkou pompou vypustil. Hovorilo sa o nom ako o jazyku buducnosti, ale mam pocit ze dopadol rovnako ako dart, closure, GWT a dalsie neuspesne projekty Googlu.
Docela by mne zajímalo, jaké statistiky máte na mysli? Doufám, že nejste další, co za statistiku považuje TIOBE index.
Když se podívám na statistiku repository na Githubu (http://githut.info/) - novější bohužel pokud vím není k dispozici a statistika Githubu ukazuje jen prvních 10 míst - tak je Go na 14 místě a to jsou v první desítce i pseudojazyky jako CSS nebo Shell, které asi z velké většiny nebudou mít vlastní repositáře, ale jsou součástí repositářů jiných jazyků. Za Go jsou například Perl, Swift, Haskell, Scala, Lua, Clojure, Groovy, ... Navíc na rozdíl od jazyků jako Perl, PHP, C a další má počet repozitářů (procentuálně) stoupající tendenci. Takže proto by mne zajímalo, odkud berete ty své data.
P.S.: Abych zabránil zbytečné diskusi, jsem si vědom toho, že množství repozitářů na Githubu není klíčové měřítko, ale pokud je nějaký jazyk na 14. místě, asi nejde označit za neúspěšný projekt. Co by za to někteří dali.
Jinak české prostředí je hodně konzervativní a Go je velmi vhodné na systémové programování s vysokou mírou paralelizace, nic z toho se tady (s vyjímkou RedHatu) příliš neprovozuje.
-
Go (Golang) je celkom v kurze hlavne co sa tyka Dockerizovanych aplikacii (BTW aj Docker je Go https://github.com/docker/docker/). Nakodis v tom mikroservice, staticky skompiluje a urobis 5MB Docker image. Naproti tomu Dockerizovana Java/Python(flask)/Nodejs/.... app ma radovo 200MB+ Docker image. Priklad na komercnu implementaciu je napr. https://sudo.hailoapp.com/ - maju sofistikovanu microservice architekturu nakodenu v Go. Na druhej strane su aj aplikacie, kde Go nie je vhodne - vid Dropbox http://www.wired.com/2016/03/epic-story-dropboxs-exodus-amazon-cloud-empire/. Podla mna kodit web v Go asi nie je najlepsie riesenie, pokial nie je kriterium performance. Prakticky priklad Golang web performance - dockerizovany https://github.com/prometheus/prometheus na mojej lokalnej masine ma response time 1ms - porovnatelna PHP app (nginx/php-fpm) 100ms+.