Google Go – pokročilejší témata (diskuse)

[alblaho]

Ten jazyk je fakt zajímavý. Myslel jsem, že v kategorii imperativních jazyků už nemá cenu se učit nic nového, ale tohle nevypadá marně.

[Ladicek]

Mně to nepřijde nijak úchvatné. Mají pár zajímavých nápadů (defer se mi docela líbí), odvážili se zrušit dědičnost (tleskám!) a zavést určitou formu strukturální typové ekvivalence (u rozhraní)… no, na gorutiny s posíláním zpráv se budu muset ještě trochu podívat, ale žádné velké nadšení nepozoruju.

Lambdy jsou syntakticky hrozně roztahané, skoro jako v Javě A proč autoři mluví o uzávěrech jako o uzávěrách?

[Sten]

Taky mi přijde, že je to akorát jinak zapsaný libovolný jiný imperativní jazyk, který má pár věcí navíc řešených přímo ve specifikaci místo v knihovně (což je IMO velmi omezující), např. korutiny (nazvané gorutiny ), lambdy či uzávěry (v C++ to umí třeba Boost.Coroutine (zatím není součástí Boostu) a Boost.Lambda).

[Lukáš Zapletal]

Snad každý imperativní jazyk bude jinak zapsaným imperativním jazykem, ne?

Go se mi líbí, ale mírným favoritem na podobném poli je u mě Vala.

[Sten]

To byla spíš narážka na to, že většina dnes používaných imperativních jazyků se zapisuje podobně jako Céčko

[alblaho]

Vala mi přijde jako velmi vhodná alternativa pro programování pro GNOME. Čisté C je zatrest, Python zas prostě nemá tu efektivitu nativního kódu, Mono je... Mono

Plusem je, že nějaký kvalitní soft už je v tom napsaný, třeba Shotwell. Ale detailně jsem to nezkoumal, teď koukám, že mají i výjimky, takže to není jen blbý preprocesor pro C.

Ale mimo GNOME nevím nevím.

[----]

čisté C je perfektní, ale je třeba si dát pozor. Ono to programování pro GNOME je to, co stojí za hovno .. :D

[__dark__]

Ty bys začal velký projekt v C?

[----]

Zrovna jeden začínám :-P Pořád mnohem lepší, než se srát s C++, D ještě není pořádně rozvinutý a když je třeba přenositelnost a možnost nabindovat API z mnoha jiných jazyků, tak Cčko je perfektní volba.

[__dark__]

Já osobně nevidím rozdíl v bindování C nebo C++. Ve většině případů se píšou wrappery u obou stejné. Podle mě je největší problém v tom, že těch jazyků je milion, a každý má pro ty bindingy jiné API.

Jinak k tomu projektu dej link, pokud je open, rád se podívám, čemu říkáš větší projekt

[petr_p]

Když děláte binding na kód C++ (obecně jakýkoliv jazyk se jmennými prostory), tak musíte řešit mapování identifikátorů na symboly v objektových souborech. A zrovna C++ výslovně varuje, že se liší překladač od překladače (a často i mezi verzemi téhož překladače).

[__dark__]

To ovšem pouze v případě, že ten jazyk, do kterého dělám binding, umí načíst sdílenou knihovnu a volat C funkce (toto umí hlavně kompilované jazyky). Na druhou stranu, někde stejně musí být seznam těch funkcí, parametry, atd, takže ten "wrapper" je sice jinde, ale stále je tam.

Takže abych to shrnul, pokud mám malou knihovnu, která má do 20 funkcí, které chci nabindovat, opravdu nevidím rozdíl v tom, jestli je v C nebo C++. Pokud je knihovna větší (dejme tomu tisíce funkcí), je bindování podle mě komplikované jak v C, tak i v C++.

Nakonec i v C++ je možné používat pro externí API C symboly, takže bych se toho zase tak nebál.

[----]

pracuju na herním enginu s integrací master/asset serveru pro storage dat na serveru a automatické stažení klientem; s jednoduchým skriptováním v jazyce Lua a tím pádem možností tvořit velkou škálu her bez zásahů do core enginu. V současnosti je venku první pre-alpha, ale používá se existující engine Cube 2, který je v C++ (no, spíš takový Cčkovitý C++) a vzhledem k tomu, že jeho kód není moc flexibilní, začaly práce na úplně novém enginu from-scratch v čistým C99 a modulární architekturou založenou na runtime načítání modulů (renderery, zvukové subsystémy, skriptování, formáty map apod.) s důrazem na velkou flexibilitu a efektivitu. Vývoj bude trvat asi dlouhou dobu i s týmem několika programátorů, takže vývoj probíhá vedle aktuální codebase a postupně proběhne přechod. Také je momentálně problém s managementem, takže tam bude probíhat hodně změn - bude se forkovat, takže pokud chceš sledovat stav, tak ti můžu poslat link až po forku - klidně mě kontaktuj na IM (quaker66 AT gmail DOT com nebo quaker AT jabbim DOT cz)

Původní záměr bylo použití D pro nový engine, ale vzhledem k nepodpoře několika věcí ve všech kompilátorech (momentálně chybějící linkování shared knihoven a podpora pro málo architektur / OS) jsem se rozhodl pro Cčko, se kterým nemám problém.

V Cčku se dá psát velice přehledný kód i pro velké projekty - ale je třeba si dát pozor na paměť a pečlivě kód strukturovat, aby se z toho nestala špagetovitá změť a vše rozdělit přehledně do částí.

Jiný projekt, ve kterým jsem zapojen a je psaný v Cčku, je Enlightenment a jeho knihovny.

[alblaho]

Já to vidím jako konkurenci pro céčko. Javisti Go moc řešit nemusí.

- jednodušší než C++ (doufám)

- jakás takás podpora pro moderní vícejádrové procesory

- kompaktní nativní kód (doufám)

- rychlý překlad

- moderní serepetičky typu typová inference a uzávěry

Déčko se moc nechytlo, třeba prorazí tohle. Nezlobil bych se.

[----]

"Déčko se moc nechytlo" .. nemůžeš říct o jazyce, který měl první stabilní specifikaci v roce 2007 a druhá ještě ani není.

[__dark__]

Specifikace možná, ale ten jazyk je tu už pěkně dlouho a stejnou dobu je i ignorován. Na druhou stranu programovat pod D bych si zvykl, ale v tom Go paskvilu ne

[----]

Nojo, jenže ten jazyk NENÍ ještě pořádně vyvinutý pro produktivní použití - D2 už celkem jo, ale ideální to není - není ignorován, prostě ještě není "ready".

[__dark__]

V tom případě je otázka, bude v dohledné době vyvinutý, když se nevyvinul ani během deseti let?

[Luboš Doležel (Doli)]

Do D bych docela vkládal naděje, ale myslím si, že je pro jeho budoucnost zásadní plná kompatibilita s C++ (ve smyslu linkování vůči knihovnám).

[----]

No, zatím se dá C++ knihovna wrapnout pod Cčkem a to pak použít v D, ale ideální to není, samozřejmě.