Re[3]: The Go Programming Language :: Something smarter than us is going to emerge


node:	Re[3]: The Go Programming Language
template:	4
parent:	Re[2]: The Go Programming Language
owner:	vl4kn0
viewed by:
created:	11.11.2009 - 21:02:57

cwbe coordinatez:
101
63540
2111157
5047497
2000633
5006551
5007271
5007286
5007406

ABSOLUT
KYBERIA

permissions
you:	r,
system:	public
net:	yes

rychlost kompilovania mna ako koncoveho uzivatela vobec nezaujima, skor by ma zaujimalo aky tvar ma vysledna binarka, ak je to bordel + skok sem skok tam tak to nema zmysel aj ked to skompiluje za sekundu. Ale cital som ze kompilovanim gc vznikne o 20% pomalsi program ako program pisany v C. dalej mi vazne prekaza spagetova syntax ktoru by som sa vobec nechcel ucit :D a jedine goals celeho projektu sa zdaju byt multithreading, to ze nevznikaju pametove chyby a rychlost kompilacie. proste bordel

00000101000635400211115705047497020006330500655105007271050072860500740605010690

skoky su uplne legitimna sucast strojoveho kodu a instrukcnej sady. preco ta to trapi?

garbage collected vyssie programovacie jazyky maju vzdy nejaky overhead, otazka je ci to je vobec relevantne. maju ine obrovske prednosti a naozaj kriticke veci je mozne vzdy optimalizovat nejakou kniznicou v C.

vyssi jazyk nemusi hned znamenat 20% overhead, prikladom moze byt CL-PPCRE kniznica implementujuca Perl regular expressions, ktora je porovnatelna so samotnym perlom (niekedy az vyrazne rychlejsia)
http://cl-debian.alioth.debian.org/repository/rvb/cl-ppcre-sarge/doc/#bench

programovat vsetky nekriticke veci v nizkourovnovom jazyku je neudrzatelne a ma to dopad na kvalitu programov (obzvlast vie nastvat taky segfault so stratou udajov)

0000010100063540021111570504749702000633050065510500727105007286050074060501069005011319

nevravim ze nema mat skoky, samozrejme skoky mat musi inak by sa nezmohol na nic vacsie ako hello world. ja vravim ze to nesmie byt bordel a skakat far skoky boh vie kde. Debuggovat potom taky kod je nocnou morou. samozrejme tiez netvrdim ze nekriticke veci sa nemaju pisat vo vyssich programovacich jazykoch. ale GO bolo vytvorene na kodenie aplikacii obsluhujuce servery a tam tych 20 percent zavazi. vyhodou je lahsia implementacia multithreadingu co na serveroch je velka vyhoda avsak problem pisat to nieje ani v C a je to len velmi specificky problem mimo ktoreho ostatne jazyky rozhodne GO tromfnu.

000001010006354002111157050474970200063305006551050072710500728605007406050106900501131905011341

si netrufam povedat naco ten jazyk vyvijaju, ale ja pre neho nemam ziadne pouzitie :)

ty hovoris o debuggovani assembleru, to vobec neznamena, ze debugger pre go nebude vediet citat go kod. aj vyssie jazyky sa predsa daju debuggovat

20 percent je vycucane cislo, pozri sa na ten link, cl-ppcre sa da povazovat za celkovo vykonnejsie. garbage collector ma aj vyhodu, ze dlho beziace procesy bezia rovnako:

performance will not degrade over time like a C or C++ program that performs comparable storage allocation (typically 25 to 50 percent degradation for a C or C++ program, depending upon heap size, malloc/free implementation, and allocation/deallocation patterns).

a samozrejme standardne vyhody, ze netreba nic alokovat, ziadne leaky, ziadne mrtve pointery, "jump to hyperspace", ani nic podobne.

pokial neexistuje zasadny problem v jazyku, tak sa da program optimalizovat az k zanedbatelnemu rozdielu oproti C (casto je I/O wait vacsi problem). a tam kde su zasadne problemy, vzdy je moznost spravit externu kniznicu.

v konecnom dosledku aj mne sa zda, ze chcu C s korutinami a lepsou pracou s vlaknami, ale nac im to bude nemam predstavu

00000101000635400211115705047497020006330500655105007271050072860500740605010690050113190501134105011373

To ze v tom chcu kodit serverove aplikacie som cital niekde na internete, neviem ci nie na oficialnej stranke. No a co sa tika debuggovania, vychadzal som z toho ze zatial ziadny debugger nieje ani som nevidel napisane zeby vobec nejaky pripravovali tak som vychadzal z debuggovania gdb ked sa uz ako kompiler pouziva gccgo. A samozrejme vyhody co si popisal to skutocne su. Problem je ale napriklad absencia OOP bez ktoreho sa dnes vela programatorov nezaobide alebo pre nich nieje az taky atraktivny. Ale aky ten jazyk skutocne je, ake prinasa vyhody a nevyhody ukaze cas ked v nom budu naprogramovane realne projekty. Zatial mozme iba hadat.

0000010100063540021111570504749702000633050065510500727105007286050074060501069005011319050113410501137305011510

pravda. aj v tom videu spominali, ze je to exoticky jazyk, takze mozno z toho ani nic nebude...