Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Znie to zaujimavo ale tvrdit ze nejaky novy jazyk zvysi bezpecnost a nedovoli utoky na danu aplikaciu a jej stabilitu je s prepacenim demagogia a blbost. Akonahle ta aplikacia robi kriticke pristupy, poziva systemove prostriedky vzdy je sanca ze to bude mat niekde dieru. Skor je mozne ze ten jazyk znizuje sancu na preklepy a chyby v kode koli zlej semantike a podobne, aj ked taketo veci uz dost dobre dnes riesi staticka analyza pri c++. A dalsia vec je aka bude udrzovatelnost takehoto kodu ked nebude ten jazyk moc rozsireny.
"A dalsia vec je aka bude udrzovatelnost takehoto kodu ked nebude ten jazyk moc rozsireny."
Kdyz to bude aplikacne specificky jazyk pro psani layout enginu, jako je napr. SQL pro pristup datum, tak bych se odlisnosti nebal. Vzdy vitezi efektivita zapisu a celkovy vykon, nez to, ze umite nejaky jazyk. Taky k DB nepristupujete po radcich v C/C++.. todle muze treba umet pracovat vyborne se stromovou strukturou (xhtml) dat.
Tak som si len tak zbezne pozrel o com ten Rust je a nieje to specificky jazyk pisany pre layouty alebo cisto iba na spracovanie povedzme textovych dat, parsovanie a podobne. Priamo na wiki je - Rust is a general purpose, multi-paradigm, compiled programming language , takze to asi kompletne nahradi c++ a napisu v tom, asi, cele Servo, teda cely browser.
Oplati sa o tom jazyku nieco nastudovat. Ja osobne velmi silno dufam ze raz rozsireny bude. Nie je to vobec aplikacne specificky jazyk ale skor nahrada za C++. To ze jazyk moze zvysit bezpecnost nie je vobec demagogia a blbost. Ked ti jazyky ako C/C++ dovolia robit priamo s pointermi hocikam do pamate, vytvara to jednoducho vacsi priestor na buffer overflow utoky a podobne. Vzhladom na vykon sme ale zatial nic lepsie ako C++ nemali, browser v Jave by bol vtipny :). Rust je zalozeny na prepracovanom kompilatore, ktory staticky skontroluje spravne pouzivanie pointrov. V ruste jednoducho nespravis ze niekde uvolnis pamat a potom tam cez pointer znova citas/zapisujes. Je tam sice moznost unsafe blokov kde mozes prakticky to iste ako v C++, ale tie by mali byt pouzivane len minimalne. Ked mas v programe len par potencialne nebezpecnych miest, tak lahsie si ich odsledujes ako ked mozu byt hocikde. 100% bezpecne to nebude nikdy, ale k vyssej bezpecnosti to urcite prispeje.
Jazyků, které měly nahradit C++, už tady bylo...
A to co prave pisete je blbost. Respektive to co som pisal to vobec nevyracia. Ano c/c++ je nachylne k chybam a tym aj k bezpecnostnym rizikam a podla vsetkeho Rust by sa mal tomu vyhybat syntakticky a aj kompiler sa bude snazit dost veci riesit. Len to stale nevyvracia to ze ked niekto chce prasit tak bude prasit v hocijakom jazyku. Ta filozofia ze nemusim sa starat, kompiler to za mna vyriesi je mylna a mozu na to dost doplatit. Mne osobne sa moc nepaci ze koli tomu vznika x novych jazykov ktore to nakoniec aj tak 100% nevyriesia a len sa zbytocne vytvara chaos. Radsej mohli spravit kvalitnejsi staticky analyzer prave na c++, napisat si nejaku runtime kniznicu na sledovanie napriklad pointerov (aj ked toto je uz tiez poriesene) a hlavne tlacit na vyvojarov nech dodrzuju stabnu kulturu. Ostatne ak by sa jednalo len o pointery tak tie kontroloval uz stary Pascal, na to nemuseli vymyslat novy jazyk.
To je pravda, ale předpokládám, že Mozilla to prasit nechce, právě naopak. Pokud chcete vytvořit novou a bezpečně napsanou aplikaci, tak to může hodně pomoci.
Když bych tvoji logiku dovedl do extrému, tak lze rovnou použít assembler...
Tak urcite asi ziaden programator nechce cielene prasit, len mi to pride ako docela mrhanie ludskymi zdrojmi na tvorenie niecoho z coho prinos bude docela diskutabilny. Treba si uvedomit kolko prace je prave napriklad v c/c++ kompileroch a optimalizacii kodu ktory generuju. Silne pochybujem ze Mozilla dosiahne takej urovne. Hmm je sice mozne ze ten svoj jazyk napisu nad LLVM, a tym vyuziju aj kvalitu kompileru ale stale by mi prislo rozumnejsie tvorit lepsie nastroje pre uz existujuce jazyky. Je fakt ze zasa prave c/c++ je opacny extrem a docela nechapem tu potrebu do neho tlacit kazdu novinku ktora sa objavi, ci uz sablony, lambda vyrazy a kopec dalsich veci. Uz sa zacina stavat z toho pomaly Perl a citanie takehoto cudzieho kodu je fakt utrpenie.
Je to nad LLVM. Pokial viem tak to vyuziva aj veci z CLangu (linker) a z rustu sa vies priamo linkovat na hocijaku C kniznicu.
Cela tato diskusia ide trochu zlym smerom. Ta "bezpecnost" je len jedna z feature. Tasky (green thready), Pattern matching a algebraicke typy, bezpecna a rychla "zero-copy" komunikacia medzi taskami su myslim este dolezitejsie. Rust tiez nepouziva klasicke OOP.
"potrebu do neho tlacit kazdu novinku ktora sa objavi, ci uz sablony, lambda vyrazy" - Tak praveze sabolny a lambda su velmi uzitocne veci. Evolucia musi pokracovat, aj v programovaich jazykoch. C++ tu bude este dlho, ale to neznamena ze nema zmysel hladat ine cesty. Inak by sme fakt este boli na assembleroch.
Tak je jasne kde topia prachy ze potrebuju novy reklamny priestor.
Vzhledem k tomu, jak dlouho Mozille trvá jen úprava vzhledu prohlížeče (Australis), tak náhrada za Gecko bude možná za 10 let.
Vzhladom k tomu ze Mozilla nie je jeden tím ktory robi prehliadac od podlahy po strechu, ale rozdeleny podla zamerania a oblasti na viacero, tak sa o to bat nemusis. Za to ze Australis ide tak pomaly je vyzitka UI developerov. Vykreslovaci engine maju na starosti uplne iny ludia.
Takze teraz, ked mam 4jadro preto, aby ked mi zozerie browser zdroje, mohol nieco robit , mi nova verzia pre istotu zozerie jadra vsetky a som tam, kde predtym. Krasa.
Vzdy bude moznost si sam nastavit sprazeni na jeden procesor pak se radovat jak ostatni nedelaji nic a to jedno se poti a flash zase nebude stihat, tak jako na jednojadrovych cpu. Kazdyho volba.
Asi nikdo si nekupuje hardware pokud ho nechce využít. Jestli někomu nevyhovuje defaultní přerozdělení procesorového času, tak není problém (jak psal kolega přede mnou) nastavit jinou afinitu nebo prioritu procesu. Mě naopak zdržují aplikace, které na něco čekají a stroj se "nudí". Nový jazyk tomu může pomoct. Microsoft třeba do C# 5 implementoval syntaktickou podporu asynchronního kódu, který se ale dá psát sekvenčně. Čte se to pak daleko lépe než vnořené callbacky a vývojář nemá takový odpor psát některé části asynchronně.
To zni dobre, a ted jeste jestli v tom prohlizeci bude nastaveni "nech X jader na pokoji" nebo si to clovek bude muset resit sam?
U dvoujadroveho procesoru se dalo tvrdit, ze aplikace by mela vyuzit obe jadra rovnomerne, ale s rostoucim poctem jader je mnohem logictejsi vyhradit alespon jedno jadro na OS a aplikace na pozadi. O variante, ze nekdo skutecne pracuje ve dvou aplikacich zaroven nemluve.
Co znamená podpora "sandobingu"?
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.