Hej, pa to je nedostajalo svetu, jos jedan programski jezik. Nije vazno sto ljudi ne umeju da koriste ni ove koje imaju, daj da dodamo jos jedan svejedno.


Ovo izgleda kao neka monstruozna mesavina pascala i C-a namerno stripovana na osnove da apeluje na ljude kojima su jezici kao C++ kompleksni, ali ocigledno na ustrb gomile stvari koje ti jezici pruzaju. Veci deo FAQ za Go su pitanja "Zasto GO ne podrzava ovo ili ono" sa odovorima "bice, ako ne poveca kompleksnost", to je ko da krenes na more kolima al ostavis sve stvari kuci da bi ti auto bio laksi i brze isao .
Jedino sto ovde vidim kao neki novi benefit (a i to je diskutabilno) je ugradjeni paralelizam. Ali hej, napravio ga je google, mora da je naravljen od zlata sa puno ljubavi.

C++ je komplikovan pre svega u praksi, a C zna da bude u praksi još komplikovaniji, mada je na papiru, tj. konceptualno daleko prostiji. Java i C# su prostiji u praksi. Alternativa C++ jeziku je potrebna. Šta je gugl uradio, ne znam.

Svaka nova alternativa koja se pojavi se uglavnom svodi na isto :
1.) Daj mi GC da ne brinem o memoriji
2.) Makni mi pointere i reference jer necu da znam da postoje

Ovo meni deluje zanimljivo u svakom slučaju i izgleda da puca na isti segment tržišta kao i D.

Svako rešenje koje se kompajlira u mašinske instrukcije, ima GC i nema fakin' iteratore je napredak u odnosu na C++. Native podrška za konkurentnost je veliki plus.

Sve te "alternative" nisu native, pa nisu alternative za C++, naročito ako GC ne možeš da isključiš. Jedina prava alternativa za C++ je objektni paskal, ali je on jako slabo podržan.

D podržava manuelno upravljanje memorijom C-style. GC je opcionalan.

Od jave na ovamo je sve duvanje u istu tikvu. Jedino f# donosi funkcionalno programiranje, tj. u nekom elementu je drugačiji od drugih (mada to ima lisp).

Ako Go bude adekvatna alternativa C++ jeziku, super. Bio bih ja prezadovoljan C# jezikom da ima native port. Ako je ovo pokušaj uletanja u prazan prostor, onda od toga može nešto dobro da ispadne. Nisam ništa radio u objektnom paskalu, pa ne znam kakav je, ali je slabo podržan.

@mmix

Rekao si da si radio neku simulaciju u C# jeziku i da ste delove koji arče FPU morali da radite u jeziku C++. Zašto smradovi iz MS-a nisu bar to rešili da ide brzo? Postoji li neki način, tipa unsafe code, pa da ne proverava prekoračenja, ili otkud znam zbog čega tako sporo računa?

nismo sami radili matematicke biblioteke, koristili smo nMath (koji je u principu managed wrapper oko BLAS/LAPACK) pa smo oko toga izgradili model.

Da ne ponavljam celu pricu C# na kraju zavrsi kao native code i izvrsava se na metalu, ali je kod takav da sadrzi puno poziva u CLR radi odrzavanja managed konteksta, to je ono sto generalno usporava C# u odnosu na c++. Mozes ti da pravis unsafe kod u c#-u (uz dosta ogranicenja, naravno), ali managed kontekst ne moze da se izbegne. odrzavanje GC tabela btw je jedan od vecih delova tog pozadinskog koda, zato mi je i malo sumnjiv ovaj njihov Go sa GC-em, al ne mogu da lupam napamet morao bih da vidim nasta lici proizvedeni native code i na koji nacin radi GoGC.

Gde mogu više da se informišem o ovome? Šta od toga važi za Mono?

Moze link do te teme gde je pisano o toj simulaciji?

Imas gomilu tekstova na netu o Common Language Infrastructure (CLI), Common Language Runtime (CLR) i Common Type System. Evo kreni od ovih wiki strana pa drilluj. Za malo dublju analizu ces morati da sidjes korak nize, napravi neki managed code pa ga debaguj i predji u dissassmbler i onda mozes videti te pozive o kojima ti pricam.

Sve isto vazi za Mono. Problem sa monom i platform portability je .NET Framework, ne CLI, .NET Framework sadrzi managed klase koje sadrze ili unsafe Windows specific pozive (preko DllImport) ili sadrze unamanged delove koda koji je windows-specific. Mono je u osnovi projekat da se .NET Framework managed API pojavi kao cross-platform resenje tako da aplikacije mogu da rade cross-platform oslanjajuci se na identican API. Da bi to uopste radilo Mono tim je prvo morao da napise CLI implementaciju za svaku target platformu.
Istina to slabo radi u praksi jer kaskaju, ali ako ti je portabilnost cilj uvek mozes da se fokusiras na GTK# biblioteku iz mono-a koja je alternativa za winforms (koji je u principu najveciu problem za portabilnost u .netu)


http://www.elitesecurity.org/p2417619
al ne znam koliko vise detalja ces naci, ne znam sta te interesuje tacno...

Postoje li indicije kada će Go(wno) moći da se preuzme i isproba?

http://golang.org/

Uh, ispala za ime

I gde je tamo link za preuzimanje?

Nema linka za preuzimanje. Koristi se Mercurial.


BTW: To je za linux. Win distribucija ne postoji.

Postoji li paket za offline instalaciju za Linux?

Mislim da je ključna stavka za širenje ovog jezika to što nema Windows port.

Biće ga sigurno, ali jezik je još uvek nije završen.

Naredni C++ standard (valda najavljen za 2010, ako se dobro sećam) će imati GC.

Jel će to STL biti proširen nekim GC-om ili će sam jezik direktno biti proširen? Nešto sam bistrio boost ovih dana i tamo nisam video nijednu biblioteku koja bi ličila na neku GC implementaciju. A ako u boostu nema kandidata, ne znam gde bi ih bilo, pogotovu kada je tako blizak datum u pitanju.

Čitam nešto Alexandrescua i D počinje sve više da mi se sviđa.

Meni se D ne sviđa zbog slabe podržanosti (kao i paskal). U tom slučaju ne ulazim u dalja razmatranja. Iza goa ipak stoji gugl, tako da može nešto i da bude.

Ja bih voleo kada bi C# imao klasičan native port (pored ovoga). Ako ne C#, onda nešto što sličnije njemu.

Biće lakše implementirati svoj GC, ali nativno on neće biti podržan u sledećem Std-u. Verovatno će biti u okviru nekog TR-a u nekom trenutku. Mada, iskreno, ne znam što večito ljudi pate za GC-om kad god se govori o novom jeziku ili o novom Std-u nekog postojećeg jezika...

Zato sto ljudi nikad ne umeju da pociste za sobom i uvek im je lakse kad neko drugi to uradi za njih

Složićeš se da čak i ako umeš nešto da uradiš, brže & lakše je ne misliti o tome i ne raditi to.

Its human nature ! :D

Slazem se, ima toliko topica u c++ za unapredjenje al se svi vataju za gc , kao da ce ih to resiti nekih muka kao da ce poleteti .
Lakse malo jeste.

Npr. class member function - pointeri su skroz zaostala stvar izvornog c++ koju retko danas neko koristi u ozbiljnije svrhe takodje u izvornom obliku) ,
pa postoji citav niz 3-party resenja koja opet nisu bas portabilna sa stanovista standradnog c++.
1.) QT-ov SIGNAL/SLOT mehanizam .Ovo resenje jeste portabilno al samo uz prisustvo meta-object compilera.
2.) U mfc-u je bio __event, __signal , __raise modifieri na member funkcije. Sada je vec deprecated ...
3.) U KDevelopu cini mi se da je postojao isto SIGNAL/SLOT mehanizam ..

Sta je sa tim ? Jel bolje imati ovo kao deo nekog standarda ili GC?
Da ne pricam koliko je bitan ovaj topic ili cinioc u design-pattern ima (Observer,State) pri projektovanju softvera.

To već imaš kao deo Standarda, a i generalizaciju toga u boost-u. STL mem_fun i boost::mem_fn

@mmix
Možda grešim, ali nikako mi ne ulazi u glavu zašto je nekom RAII komplikovana stvar, pogotovu što već postoje implementacije, dakle nema izmišljanja tople vode.

>> To već imaš kao deo Standarda, a i generalizaciju toga u boost-u. STL mem_fun i boost::mem_fn

Znam, ima ih jos dosta nabrojao sam samo prvih par kojih sam se setion ,
ali hocu da kazem da ga nema kao deo jezika i dalje , da mi ne treba externa biblioteka za takve stvari
koje se podrazumevaju u c# ili javi ...

Jedini element c++ za takve stvari su templejti i njihova specijalizacija,
a pogledaj kako to izgleda :
http://www.codeproject.com/KB/cpp/FastDelegate.aspx

Video sam taj članak pre jedno dve god... u principu je odlična stvar, ali teško da može najtransparentnije da radi sa STL-om i boost-om. Tačno je da skoro nema overhead-a kod ovih delegata kad nije upleteno višestruko i virtuelno nasleđivanje, ali sam zarad boljeg poštovanja Std-a i integracije spreman da žrtvujem malo performansi.

--

Iskreno, ne volim preterano dodavanje novih stvari kada je u pitanju sam jezik, pre sam za to da se sve to nalazi u okviru Std biblioteke. Ruku na srce, ovog puta su dodali prave stvari kao deo jezika, a najviše mi smeta što su odložili dodavanje Koncepata, jer bi onda jezik bio prava bomba i mislim da tek onda ne bi imao konkurenciju kad je u pitanju neko ozbiljnije generičko programiranje.

E da, kad je Go u pitanju, sve mi se čini da će to na kraju biti yet another language u masi nekih drugih skrndelj jezika i da je to više potreba Google-a da zvanično polako pokriva i taj segment u nekom procentu... Bolje da su se ponudili da podrže nešto što već postoji i relativno je dobro, a to je recimo D, kome držim palčeve (iako se ne nadam previše) da postane mainstream jezik...

Ovde tema nije C++, već go! Oladite malo sa raspravama koje su van okvira teme.

Šteta što Gugl pravi jezik za nas, a ne za sebe. Kad bi napravili nešto za sebe zato što ih svrbe postojeća rešenja, onda bi to valjalo i nama. Nijedan jezik koji nije strogo teorijski zasnovan nije ušao u širu industrijsku upotrebu. Svi uspeli jezici imaju teorijsku podlogu iza sebe - i C i C++ i C# i Java i erlang, pa i Prolog, koji je itekako uspeo u svom području. Čuo sam kritike da je go Frankenštajn, a ne dobro dizajniran jezik.

@Nedeljko ,
Svako polazi od svoje pocetne pozicije u programiranju trazeci alternative .
Nisam zaljubljen ni u jedan jezik, ali ako je u pitanju alternativa uvek ces traziti nesto sto ti u toj pocetnoj poziciji tj. jeziku najvise smeta .
Ako je go native onda polazim od toga sta mi u native jezicima najvise smeta , a vi ste prvi konkretno naveli GC za koji ne marim mnogo.


Meni se cini da ce na kraju ispasti da su ga pravili za sebe ,
tj. za njihove developere , i kao neka podrska skript jezicima za one koje vec koriste guglove api-je (youtube , picassa, maps,docs itd ...)
i neke buduce njihove "cloud" servise , a ne kao prava alternativa postojecim jezicima .

Ja bih voleo da postoji neka free open native implementacija jezika C#, ili nečeg sličnog njemu, ali stipse iz Mono projekta se drže trčanja na .NET-u i džaba.

A koliko je to tačka-govedo upotrebljivo? Zar on ne zaostaje značajno za Mono projektom, koji značajno zaostaje za MS-om?

Za frameworkom ogromno zakasnjenje, tj nikad ga nece ni imati jer hoce kompletnu otvorenost, ailza jezik i runtime da. Moras da odlucis sta ti ustvari hoces portabilno, .net framework ili c# jezik? c# i CLI su ECMA, od skoro su i MS patenti za c# i CLI pod onim njihovim "community promisom" pa moze implementaciju da radi ko hoce i za koju platformu hoce. Framework medjutim je druga prica.

Čekaj, ja imam osnovne biblioteke kao native, a mogu da koristim i sve ostale native biblioteke (npr. Qt pisan za C++)?

.GNU sa baznim klasama pokriva samo System.Xml i System.Windows.Forms namespace ,
i jedan deo za web servise ,sto u principu nije dovoljno bas za razvoj neceg ozbiljnijeg .

Ali kao sto rece @mmix mozes uzeti CLI i na njega zidati ostale namespace-ove
System.Collections za kolekcije i nizove i System.Data sa rad sa bazama itd .. .

@Nedeljko
Koliko te shvatam tebi je QT dobar ali te svrbi sto nema GC ,
pa zbog toga hoces i da ga sastavljas sa .GNU-om ?

Qt ima GC

A gde je GC u Qt-u? On definitivno ne čisti ono što ja napravim van Qt-a, a svoje đubre šisti kao svaka lepo vaspitana klasa.

Qt je dobar za takav C++ kakav jeste, ali me C++ svrbi.

1. Nema GC.
2. Nema pravilo jasne dodele.
3. Nema interfejse, jer ima višestruko nasleđivanje.
4. Ima eksplicitne pokazivače.
5. Ima prljave funkcije sa proizvoljnim brojem parametara.
6. Prljav je u poređenju sa jezicima C# i Java.

Nemam ja problem sa C++ jezikom. Čak smatram da je bio izvanredan pogodak za vreme kada se pojavio, samo mislim da ga je malo vreme pregazilo. Eto, ima falinke koje su u drugim jezicima odavno prevaziđene.

Bez neke preterane potrebe da se udje u bilo kakvu raspravu sta je bolje,
licno smatram da je C++ tata svim ostalim jezicima.

Stoga me interesuje sledece, ako bi neko mogao da mi objasni.

- Prednost interface-a u odnosu na abstraktne klase (ako postoji).
- Zasto je GC toliko vazna stavka? (osim pogodnosti da se ne mora razmisljati o alokaciji memorije)

I konkretno @Nedeljko:

(sta se podrazumeva pod)

2. Nema pravilo jasne dodele.

(ako mozes da pojasnis zasto ti smeta sledece)

4. Ima eksplicitne pokazivače.
5. Ima prljave funkcije sa proizvoljnim brojem parametara.

Kako nema interfejse ? Zovu se abstraktne klase ...
U cemu je ovde razlika ?





Ni jedan ni drugi primer klase tj. interfejsa se ne moze instancirati,
a klasa koja nasledjuje je obavezna da implementira metode u potpisu abstraktne klase ili interfejsa ...
Razlika je samo u sintaksi ..

@deerbeer

Razlika je u tome što je koncept interfejsa redukovan - ne može sadržati atribute niti implementaciju ni jedne jedine metode. Uvedeni su zbog redukovanja pojma višestrukog nasleđivanja, koji inače u punoj snazi ume da pravi probleme. Java, C# i Python nemaju virtuelno nasleđivanje, jer kod jednostrukog nalseđivanja klasa i višestrukog nasleđivanja interfejsa to nije potrebno.

@vlaiv

Pravilo jasne dodele nije zadovoljeno u kodu



Znači, čita se vrednost promenljive x na mestu na kome nije garantovano da joj je dodeljena vrednost. To je u jezicima C# i Java sintaksna greška. Dakle, bag te vrste ne možeš napraviti, a da uspeš da iskompajliraš program.

Prednost GC-a je upravo to što si naveo - nemogućnost curenja (mada i tu može doći do curenja ako imaš niz pokazivača na nekorišćene objekte).

4. Izričiti pokazivači boluju od problema zbog kojih su izmišljani razni pokazivački paterni i GC.
5. Pa, valjda je bolje da postoji nezaobilazna, tj. obavezujuća kontrola da slučajno ne čitaš đubre u listi argumenata.

Uzgred budi rečeno, zna li neko za neki jezik sa integrisanom formalnom verifikacijom koda, kao što je P(erfect) L(anguage)?

Ne uspevam više da izguglam PL, ali mislim na ovako nešto

http://en.wikipedia.org/wiki/Formal_verification
http://www.cl.cam.ac.uk/~jrh13/slides/types-04sep99/slides1.pdf

To se slazem , ali opet tebe nista ne sprecava da se u c++ drzis manira i koncepta koje postoje u c# ili javi ,
tj. da izbegnes klasicno visestruko nasledjivanje.



Visestruko nasledjivanje u C++ uglavnom razbija koncept enkapsulacije u slozenijim slucajevima ,
dok provalis cija se metoda poziva ili ciji se atribut objekata menja .
Zato je u vecini novijih jezika i izbacen .

Ne bih rekao je to isto. Recimo ako imam dve klase koje sadrže metodu write(), koja nije nasleđena iz neke treće klase, pa izvedem klasu iz te dve, imaću dva primerka metode write(). Čak i ako je nasleđena iz neke klase Writeble, svaka od tih izvedenih klasa ima svoju tabvelu virtuelnih metoda, bez obzira što mogu da vršim virtuelno nasleđivanje.

Da li očekuješ da GC neke biblioteke automatski preuzme kompletan menadžment memorije cele aplikacije?
Ovo je zamena teza jer svaki GC ima svoj domen u okviru koga je aktivan.

Da, ali se tu onda postavlja pitanje sta je zapravo GC. Ako to nije deo runtime-a vec deo specificne biblioteke koji cisti djubre te biblioteke, sledeci korak je povratak na stari dobri malloc/free, ako znas sta si alocirao znas kako i da pocistis, osim ako nemas leak. Sustina GCa, bar koliko je ja vidim je dynamic discovery i lifecycle management alociranih blokova, tj neka visa apstraktna operacija nego sto je pracenje potrosnje unutar sopstvenog frameworka. Realno ako kontrolises sve alloc operacije ti onda ne moras ni da koristis GC, mozes da napravis svoj linearni heap koji ces alocirati jednim allocom i onda interno koristiti kroz neki offset.