Alfonso Maruccia

Mozilla, il nuovo engine Ŕ quasi pronto. Per 4 siti Web

La fondazione fornisce aggiornamenti sullo stato dello sviluppo di Servo, engine di nuova generazione che presto si potrÓ testare pubblicamente. Su quattro siti diversi, nientemeno. Col tempo, Servo ingloberÓ Gecko con Rust a mezzo Oxidation

Roma - Da qui a giugno, svela Mozilla, gli sviluppatori e gli utenti appassionati potranno cominciare a mettere le mani su Servo, layout engine di nuova generazione pensato per catapultare Firefox nel mondo contemporaneo con pieno supporto alle tecnologie informatiche più recenti.

Servo è scritto in Rust, ennesimo progetto di modernizzazione che Mozilla dedica al codice sorgente con un linguaggio di programmazione progettato per essere sicuro e (quasi) a prova di bug; l'engine è multi-piattaforma, con supporto sia ad architettura per computer a 64-bit (x64) che per dispositivi mobile (ARM), sfruttamento ottimizzato delle CPU multi-core e tutto quanto.

Al momento, lo stadio di sviluppo di Servo permette all'engine di supportare il caricamento di appena quattro siti Web (GitHub, Duckduckgo, Hackernews e Reddit) - o almeno li supporterà a giugno quando alcuni bug funzionali e di rendering attualmente presenti nel codice saranno corretti.
Il destino di Servo è quello di sostituire l'engine Gecko all'interno del browser Firefox, mentre la prima dimostrazione pubblica del nuovo motore sfrutterà un browser scritto interamente in HTML (Browser.html).

Un ulteriore componente, chiamato Graphene, si incarica dell'esecuzione di applicazioni Web native in HTML. L'engine JavaScript di Servo è sempre lo stesso SpiderMonkey già usato sulle versioni attuali di Firefox, mentre il progetto di implementazione dei componenti di Servo scritti in Rust su Geko è nota come Oxidation. Gli sviluppatori Mozilla hanno una certa passione per i nomi in codice, evidentemente.

Alfonso Maruccia
Notizie collegate
7 Commenti alla Notizia Mozilla, il nuovo engine Ŕ quasi pronto. Per 4 siti Web
Ordina
  • Rust non nasce per essere "esente da bug": cosa vorrebbe dire poi?
    Lo scopo invece è rendere difficile scrivere codice insicuro, almeno a livello di allocazione di memoria.

    Mi rendo conto che per i "vecchi" programmatori risulti ostico (mi ci metto dentro anche io), ma da questo a dire che programmare in linguaggio macchina sia la scelta migliore, direi che ce ne corre! In grossi progetti è necessario un linguaggio che sia al contempo molto espressivo, ma anche molto rigoroso e che possa andare a basso livello: Rust ha questo obbiettivo, scrollandosi di dosso l'eredità di retro-compatibilità che rende il C++ molto ostico da imparare e da programmare con buon livello di sicurezza.

    ╚ perfetto? Certamente no, ma vi ricordo che la versione 1.0 è del 2015!
    non+autenticato
  • Benchè trovi giusto riscrivere l'engine da zero per adattarlo al multithreading massivo e pensando da subito alla sicurezza, trovo alquanto discutibile aver inventanto un nuovo linguaggio di programmazione (RUST) per farlo. In particolare perchè ho provato molto rapidamente a dare un'occhiata a RUST e lo trovo veramente "ostile" (o magari sono troppo vecchio per apprezzarlo).
  • - Scritto da: bradipao
    > Benchè trovi giusto riscrivere l'engine da zero
    > per adattarlo al multithreading massivo e
    > pensando da subito alla sicurezza, trovo alquanto
    > discutibile aver inventanto un nuovo linguaggio
    > di programmazione (RUST) per farlo. In
    > particolare perchè ho provato molto rapidamente a
    > dare un'occhiata a RUST e lo trovo veramente
    > "ostile" (o magari sono troppo vecchio per
    > apprezzarlo).

    E' l'effetto che mi fanno un po' tutti i linguaggi di adesso: sei/siamo troppo vecchi per farci attrarre da linguaggi che ci legano in costrutti e vincoli che ci paiono inutili (e lo sono, a ben vedere) e non premiamo l'immediatezza, la sintesi e la semplicità logica che vorremmo.

    In fin dei conti in macchina gira del codice assoluto, alla faccia della programmazione strutturata o ad oggetti ovvero non procedurale con tanto do classi e dipendenze e altre amenità che proprio nulla hanno a che fare coll'oggetto eseguibile che, poche balle, deve girare al meglio, e non essere afflitto da malintese esigenze di produttività e ipotetica leggibilità del source, che alla fine produce un tanto al chilo con precotti inseriti dovunque e bug a volontà che si annidano nelle contorsioni sintattiche indotte gratuitamente!

    Si, sono vecchio anche io, ma col cavolo da "giovane" avrei potuto produrre SW di base efficiente con le contorsioni dei linguaggi attuali!

    E poi dicono che l'Assembler è difficile; ma per lo meno è logico, e se hai il tuo bagaglio di macro e routines fai quello che vuoi in tempi accettabili.
  • - Scritto da: rockroll
    > E poi dicono che l'Assembler è difficile

    Basta leggere il manuale di poche paginette per imparare ad usare un Assembler come GAS http://linux.die.net/man/1/as
    Spesso chi vuol fare l'espertone poi si scopre non conoscere nemmeno la differenza tra l'Assembly (un linguaggio mnemonico per una CPU) e un Assembler (un programma).
    non+autenticato
  • > E poi dicono che l'Assembler è difficile; ma per
    > lo meno è logico, e se hai il tuo bagaglio di
    > macro e routines fai quello che vuoi in tempi
    > accettabili.

    A mozilla sono veramente dei pivelli: chissa` perche` non hanno pensato a usare l'assembly per riscrivere il browser! Occhiolino
    non+autenticato
  • - Scritto da: rockroll
    > E' l'effetto che mi fanno un po' tutti i
    > linguaggi di adesso: sei/siamo troppo vecchi per
    > farci attrarre da linguaggi che ci legano in
    > costrutti e vincoli che ci paiono inutili (e lo
    > sono, a ben vedere) e non premiamo
    > l'immediatezza, la sintesi e la semplicità logica
    > che vorremmo.

    Certo, programmare senza pensare minimamente alla sicurezza è molto più facile: gli effetti li vediamo in decenni di buchi più o meno gravi sparsi in tutti gli ambiti software e tutt'ora spesso dovuti a buffer overflow, allocazione/de-allocazioni errate della memoria e via dicendo.

    Rust cerca di risolvere almeno questa fascia di problemi, *obbligando* il programmatore a non fare sbagli di questo tipo.
    non+autenticato
  • - Scritto da: rockroll
    > E' l'effetto che mi fanno un po' tutti i
    > linguaggi di adesso: sei/siamo troppo vecchi per
    > farci attrarre da linguaggi che ci legano in
    > costrutti e vincoli che ci paiono inutili (e lo
    > sono, a ben vedere) e non premiamo
    > l'immediatezza, la sintesi e la semplicità logica
    > che
    > vorremmo.
    >
    > In fin dei conti in macchina gira del codice
    > assoluto, alla faccia della programmazione
    > strutturata o ad oggetti ovvero non procedurale
    > con tanto do classi e dipendenze e altre amenità
    > che proprio nulla hanno a che fare coll'oggetto
    > eseguibile che, poche balle, deve girare al
    > meglio, e non essere afflitto da malintese
    > esigenze di produttività e ipotetica leggibilità
    > del source, che alla fine produce un tanto al
    > chilo con precotti inseriti dovunque e bug a
    > volontà che si annidano nelle contorsioni
    > sintattiche indotte
    > gratuitamente!
    >
    > Si, sono vecchio anche io, ma col cavolo da
    > "giovane" avrei potuto produrre SW di base
    > efficiente con le contorsioni dei linguaggi
    > attuali!
    >
    > E poi dicono che l'Assembler è difficile; ma per
    > lo meno è logico, e se hai il tuo bagaglio di
    > macro e routines fai quello che vuoi in tempi
    > accettabili.
    Tu sei un vero genio, guarda.
    Se sei vecchio al punto tale da scrivere queste stupidaggini allora devi essere uno dei quei programmatori pr0 che nella vita il massimo che è riuscito a scrivere è il calcolo del determinante di una matrice.

    I software di oggi hanno sull'ordine delle centinaia di volte la complessità di quelli della tua epoca, sveglione.
    Di conseguenza aumentare l'astrazione è un passo *NECESSARIO* se si vogliono sviluppare soluzioni robuste in tempi *UMANI*.

    E comunque, come ti hanno già fatto notare: si chiama ASSEMBLY, non ASSEMBLER.
    Volete fare i pr0 ma non sapete nemmeno di cosa state parlando.
    non+autenticato