Forum libero

> Non ci capisco un cazzo, lo faccio solo per il Dio Del Trolling

Bravo!

> > Vedi cosa intendo per "acerbo"?
> > Questo sta facendo il percorso a scossoni di Linoleum.
> >
> > Classes were also removed, replaced by a combination of implementations and structured types.
> >
> > Cioe`, ha cambiato interamente object model tra una versione e l'altra.
> > Che cavolo ci vorresti fare finche` la sua impostazione e` cosi` volatile?
>
> Stai usando nodejs che è anche lui alla versione 0.10.x

Colpa tua!
Comunque la tentazione era troppo forte.

> Rust nasce come sostituto del c++, aggiungendo strati di verifiche statiche che intercettano a compile time un sacco di errori con messaggi significativi (hai mai visto un errore di compilazione c++ con i templates? io si ) e alcuni vantaggi come multithreading efficiente (threading m:n), type system forte (se non sbaglio è il modello di scala a sua volta ispirato a haskell),

La wiki dice che e` anche "inferred"?
Mi sono chiesto en passand come faccia ad essere forte ed inferred insieme...

> l'ownership dei puntatori (che ne determina il lifetime, e di conseguenza intercetta i memory leak a compile time), costrutti sintattici utili (pattern matching, return implicito dell'ultima espressione, oltre agli ormai immancabili closures, for-each, ...).

In pratica un C antisdrucciolo. Mah, la roba troppo managed mi rende perplesso: piu` cose si lasciano fare al compilatore, piu` cose vengono fatte in maniera non ponderata perche` il compilatore non capisce qual'e` il ruolo, in pratica, di quel che sta compilando. Per come l'ho sempre vista io, piu` aspetti del run-time allontani dal controllo del programmatore, piu` colpisci la performance. Molti, oggi, forse non si rendono conto del problema perche` evitano il basso livello come la peste, confrontano performances di linguaggi diversi ma tutti piu` o meno molto al di sopra dell'assembly, e non vedono, in pratica, quel che perdono.

> Lo sto osservando da almeno un annetto, (leggo spesso i This week in Rust che trovi qui ) ho seguito il tutorial sul sito per la versione 0.8 e mi sono promesso di riaffrontarlo di nuovo per vedere come sta cambiando; quello che stanno affrontando ora è l'ultimo set di modifiche alla sintassi prima di andare verso la stabilizzazione e il rilascio della versione 1.0 di linguaggio e runtime library prevista per l'inizio del prossimo anno.

Hmmmmrrr... dicono tutti cosi`. Aspetterei che ci arrivino e poi lascerei comunque passare un po' di tempo affinche` dia prova di essersi davvero stabilizzato.

> I suoi principali concorrenti sono D della digital mars e Go di google, entrambi garbage collected; mi interessa capire se può diventare il linguaggio general purpouse che copre più use-case senza troppa fatica da aggiungere al mio bagaglio di conoscenze; mi sembra un linguaggio con buone performances, sintassi e compilatore amichevoli, un buon seguito di persone, nessuna pressione o interessi concorrenti alla realizzazione del linguaggio.

Per le buone performances, nella mia idea, bisogna quanto meno avere accesso diretto ai registri, tanto per dirne una.

e di certo costrutti come il ritorno implicito, che impacchettano l'operazione di ritorno di un valore e ne passano la gestione al compilatore, non aiutano. Fai conto che tra Lino 2 e Lino 3 l'istruzione di ritorno e` stata PERSA in favore della performance. Ti faccio un esempio:

a = b;
a + c;
return [register] a;

Somma B e C e poi ritorna il registro A.
Il compilatore pero` la tradurrebbe in:

mov eax, ebx
add eax, ecx
mov ebp, eax
ret

Ma se in Lino 3 scrivi:

% = b;
% + c;
leave;

ottieni:

mov ebp, ebx
add ebp, ecx
ret

che sono tre istruzioni, non quattro. Questo perche` come programmatore SAI che ritornerai B + C e usi direttamente il registro dedicato al valore di ritorno come accumulatore. Ovviamente un caso del genere puo` essere considerato da un compilatore sofisticato, ma quando cominci a prendere in considerazione fattori un po' piu` complessi, il compilatore dovrebbe capire cosa sta facendo in relazione a tutto il resto del codice di una funzione da ottimizzare. Piu` roba implicita hai, piu` perdi occasioni (o le complichi a dismisura) per ottimizzare. Per questo penso che linguaggi come Rust possano diventare piu` comodi del C++, ma non significativamente piu` performanti. Pero` se valuti la comodita` e una velocita` decente senza cercare il massimo, fai bene a seguirlo, io non ti seguo e non lo seguo perche` sono un vecchio che vive nel passato e che e` fissato con gli estremi: o vado in javascript e me ne frego della performance ma favorisco qualcosa che esegue out of the box vista l'onnipresenza dei browser, oppure il mio ideale rimane qualcosa come Linoleum. Qualcosa che si mette in mezzo il meno possibile tra te e il bare metal.