Programozási nyelveket tesztel a Google

A társaság érdeklődése a Rust és a C++ felé fordult.

A Rust programozási nyelvet a Mozilla fejlesztette ki, majd a Firefox böngészőbe is integrálta. A szervezet példáját előbb a Microsoft, majd az Amazon követte, utóbbi cég ráadásul egyre nagyobb mértékben támaszkodik a Rustra. Idén februárban pedig bejelentették a Rust Alapítvány létrehozását.

A Chrome fejlesztőcsapata jelenleg azt vizsgálja, hogy miként akadályozhatja meg a szoftverben a memóriahibák bekövetkezését. A Chrome súlyos biztonsági hiányosságainak 70 százaléka ilyen jellegű probléma. A csoport ezért a Rust programozási nyelvet és a C++ néhány saját kiegészítését teszteli. A cél annak biztosítása, hogy ne csupán a memóriahibák száma csökkenjen jelentős mértékben, hanem ezzel párhuzamosan a program teljesítménye se essen vissza.

A Rust gyakorlatilag az utolsó szalmaszálat jelentheti, azonban vannak bizonyos tényezők, amelyeket nem lehet figyelmen kívül hagyni. A fejlesztők többek között azt írták, hogy ha holnap reggeltől a Rust segítségével kezdenék elkészíteni az új nagy komponenseket, akkor is több évre lenne szükség a biztonsági hiányosságok többségének a befoltozására. Viszont a legnagyobb körültekintés ellenére sem garantálná senki és semmi sem azt, hogy nem keletkeznek újabb biztonsági rések.

A csapat mindenesetre kiadott egy dokumentumot, amelyben a Rust használatát mutatja be a Chrome böngészőben. Emellett vannak nem nyilvános kiadások, amelyek tartalmazzák a módosításokat, ezek azonban kísérleti verziók. Az tehát egyelőre kérdéses, hogy a Rusttal kiegészített Chrome-változatok mikortól lesznek elérhetők.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • MerlinW #11
    Mindig jót röhögök, mikor egy mondatban látom a gyors és Java szavakat :DD
  • Sydra #10
    Ja mert a reference counting meg a dinamikus típus ellenőrzés ingyen van. A statikus fordítók meg megragadtak az előző évszázadban. Nem lehet ám ugyanazt a lefoglalt memóriát többször felhasználni.
    Látom nálad ez is ilyen vallási téma. Azt hiszed a kedvenc nyelved jó mindenre. Feladathoz választunk nyelvet a nyelv sajátosságait mérlegelve. A Java pont nem jó sebesség kritikus problémák megoldásához. Ha ezt nem érted, akkor kezdő kis nudli vagy akinek csak nagy a szája.
  • Sequoyah #9
    Tudod hogy mukodik a Java garbage collection?
    Garbage collection nelkuli nyevlekben minden egyes objetkumot kulon le kell foglalni a memoriaban, amihez keresni kell egy megfelelo meretu helyet. Majd a vegen fel kell szabaditani a helyet MINDEN EGYES objektum eseten.

    Java fele garbage collection eseten a memoriafoglalas idoigenye a 0-val hataros, es a memoria felszabaditasanak az ideje az objektumok tulnyomo tobbsegenel is a 0-val hataros, es ezzel throughputot merve a Java memoriakezelese magasan veri a C++-ot.
    Latencyvel mar lehetnek problemak mert ha pont akkor fut a garbage collection amikor erkezik egy request, akkor megakadhat egy picit, de erre vannak mar eleg regota pauseless garbage collectorok.
  • Sydra #8
    "Viszont a memoriakezeles sokkal gyorsabb Javaban (garbage collection), es sok a runtime optimalizacio"
    A garbage collection nem a gyorsaságot, hanem a kényelmet és a biztonságot szolgálja (bár Java-ban ezeket is próbálták elszabotálni default mutability-vel meg default nullability-vel). Ha gyors szoftvert akarsz akkor nem használsz garbage collector-t, vagy csak a nagy méretű és kis számú objektumokra.
    Szoftvertervezésben meg eleve nincsenek általánosan tökéletes megoldások. Az általános, automatizált memóriakezelőd soha nem lesz olyan gyors mint az adott feladathoz illesztett speciális megoldás (amiknek a nagy részét Java-ban nem is tudod megvalósítani csak C++-ban). A runtime optimalizáció meg fabatkát sem ér a static type introspection-höz képest.
    Akárhogy is nézzük a Java egy erősen specializált nyelv, a C++ meg egy általános célú nyelv. Bizonyos feladatkörökre a Java tartalmaz rengeteg automatizációt és ezeken a területeken jóval gyorsabban is lehet benne fejleszteni, mint C++-ban. Minden másra a C++ jobb.
  • Sequoyah #7
    Viszont a memoriakezeles sokkal gyorsabb Javaban (garbage collection), es sok a runtime optimalizacio ami szinten nem elerheto C++-ban, mert az build timeban fordul nativ kodra.

    Egyebkent meglepoen sok mindenhez hozza lehet ferni direktben, bar akkor mar nem feltetlenul egyszerubb hasznalni mint a C++-t. De ha csak egy limitalt kisebb kodreszletet kell nagyon optimalizalni, akkor ez is egy opcio.
  • Sydra #6
    Java-ban nem férsz hozzá direktben semmihez ami sebesség szempontból igazán számít. Meglehetősen korlátozott az eszközkészleted C++-hoz képest.
  • Sequoyah #5
    Nagyon sok sebessegigenyes dolgot csinalnak Javaban, pl low latency/high frequency trading rendszereket, amik tobb millio tranzakciot dolgoznak fel masodpercenkent.

    A Java azt csinalja amit szeretnel. A kulonbseg az az, hogy a Java egyszerubb, ezert tobb amator kezdo programozo van akik osszebarmolnak benne valamit, mig aki elkezd C++-ozni az altalaban elhivatott annyira hogy rendesen megtanulja. Tudom, interjuztatok ilyeneket, es latom hogz aki C++ hatterrel erkezik, az jo esellyel nem amator...

    De ha a programozo rendesen erti a Javat, annyira mint amennyit a C++-hoz kell erteni hogy barmi eletkepes dolgot osszerakjon, onnantol a Java egy nagyon hatekony programnyelv.
    Persze ha valaki azt sem tudja hogy hogy mukodik a garbage collector, es milyen alternativak vannak, attol nem fogom elvarni hogy gyors programot irjon...:)
  • Sydra #4
    Ez nagyon esetleges és ritka, hogy pont azt csinálja, amit szeretnél.
    Nem hiába csinálnak minden sebesség igényes dolgot C++-ban.
  • Sequoyah #3
    Azt azert igy nem jelentenem ki hogy gyorsabb mint pl a Java. Helyzettol fugg, es sokesetben a Java a gyorsabb a nativ gepkozelibb nyelveknel, mert runtime tud optimalizalni, es sokkal gyorsabb a memoriakezelese mint pl a c++.

    De mint mondtam helyzetfuggo, attol fugg konkretan mi is az algoritmus amit programozol.
  • kvp #2
    A rust az olyan, mint amikor a c-t egy 1970-es evekbeli makro assemblerrel keresztezik. A hasznalatarol valahogy egy rozsdas sajtreszelo jut eszembe.

    Ettol fuggetlenul elvileg biztonsagosabb nyelv mint a c, ellenben statikus, igy elvileg gyorsabb mint a nativ kodra forditott java. A belinkelt irasban olyanokrol irnak, hogy egy c++-os stringet nem igazan lehet elerni nativ modon rust alol, de egy c++-os string-et tartalmazo strukturat meg annyir sem. Na most a legtobb rendszer szintu api es kulso programkonyvtar az vagy c vagy c++ strukturakat hasznal. A rust direkt ugy lett megirva, hogy ezeket a feluleteket fajdalmasan nehez legyen biztonsagos (szabalyos) modon elerni.

    "We think the hardest part of this is imagining a safe way to pass types between Rust and C++. That requires auto-generated shim code on both the Rust and C++ side. That’s already achieved by cxx with terrific emergent safety properties. And so that’s our basic model.
    But, we don’t want to specify a cxx::bridge section for every API. We therefore need the cxx::bridge to be generated using a bindgen-like tool.
    We don’t believe Rust language changes are needed. Some C++ types can’t be owned by value in Rust — for example std::string with its self-referential pointer — but we believe that good C++ interoperability can be achieved even if Rust can only own such objects by pointer. We may be wrong here as well!"

    Tehat vagy generalnak egy rakat folosleges kodot, ami oda-vissza konvertalja az adatokat vagy meg egy string-et (sima szoveget) tartalmazo valtozot sem fognak tudni elerni. Egy jo programnyelvnek nem kell generalt kod ahhoz, hogy egy olyan alap funkciot elerjen, ami mar 40 eve a Commodore-ok idejen is magatol ertetodo volt. Ertem, hogy biztonsagos, csak nekem tovabbra is egy nagyon biztonsagosra tervezett rozsdas sajtreszelonek tunik. Ehhez kepest meg az Ada is egy felhasznalobarat nyelv.