Komerčné projekty v golang?

[gl]

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

[Reklama]

[Radek Miček]

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?.

[zboj]

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...).

[MartinBeran]

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.

[MartinBeran]

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.

[Reklama]

[zboj]

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.

[MartinBeran]

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.

[zboj]

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.

[MartinBeran]

Š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é?

[zboj]

Š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.

[MartinBeran]

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.

[gl]

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?.

Děkuji za opravu. V Go neprogramuji. Špatně jsem to pochopil.

[Jozef]

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...

[Radek Miček]

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í.

[čumil]

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.