Da giorni non si parla d’altro nei forum, nei blog e nei siti che in generale sono legati al mondo della programmazione. Considerato il nome della rubrica e la sete di conoscenza che caratterizza tipicamente i coder smanettoni, l’occasione, come si…

Sulla questione leggibilità del codice vorrei aggiungere solo una cosa: molte volte non dipende solamente dal linguaggio di programmazione usato, ma da chi scrive il codice….

Attualmente la differenza fra le goroutine di Go e le tasklet di Stackless sta nel fatto che il primo distribuisce le sue coroutine (perché sono coroutine a tutti gli effetti, come puoi leggere nei diversi documenti, di cui ho fornito i link in cui se ne parla) su più thread, mentre Stackless no (sfrutta quello principale).

Nulla a toglie che quest’ultimo in futuro possa fare lo stesso, visto che le enormi similitudini (e se vedi anche gli esempi a confronto fra Go e Stackless, è lampante di come sia l’approccio sia la stesura stessa del codice abbiano più di qualche somiglianza).

Per quanto riguarda i risultati in termini puramente prestazionali, è chiaro che dipendono dall’implementazione. Non potrebbe essere altrimenti, perché i linguaggi non si possono confrontare soltanto sulla carta. E il confronto rimane lecito, com’è stato fatto.

Se non li ritieni scientifico, io la penso in maniera diversa, perché è stato Pike a vantarsi per primo di creare 100mila “microthread” e macinare dati, con Go a processare il tutto in scioltezza (rispetto ad altri linguaggi, s’intende).

Gli autori del benchmark l’hanno preso in parola ed effettuato dei test, col suo stesso esempio e con un linguaggio che forniva un concetto molto simile, sebbene girasse su una VM. Fornendo sorgenti e dettagli sui test, in modo che siano riproducibili anche da altri. Come poi tu stesso hai fatto e hai appurato. ;)

Sulla velocità di compilazione mi sono già espresso nell’articolo. :P

@Giogio: linguaggi che siano semplici, multitasking e sicuri esistono già da tempo. ;)

Sul resto concordo.

Sarà più veloce programmare in go? Ci sarà meno necessità di tempo speso in debugging e in controlli?
Vedremo, molto dipenderà anche dall’ambiente di sviluppo e dalle librerie.
Personalmente mi piacciono la tipizzazione, i package, le interfacce, meno la garbage collection ma ne capisco l’esigenza.

Il concetto di coroutine e’, per l’appunto, un concetto, una astrazione.

Dire che l’implementazione non conta e’ come dire che compilare del codice senza ottimizzazioni e’ la stessa cosa che compilarlo con: non conta dal punto di vista della validita’ del risultato finale, ma conta molto dal punto di vista del tempo di esecuzione… ed e’ proprio il tempo di esecuzione che veniva messo in discussione nell’articolo.

Poi, a parte i vari echo, devo ancora trovare un server che sia leggero tanto quanto l’esempio riportato nel Google talk. Continuo a ritenere le affermazioni fatte su Dalke Scientific molto poco scientifiche.

“Why then does Pike sound so proud about the performance of Go on this timing test? I don’t know.”

Io lo so e mi appare evidente: era un esempio volutamente minimale teso a mostrare la semplicita’ del linguaggio ed una relativa velocita’ di esecuzione.

Bisogna comunque ricordandosi che il punto forte di Go rimane la velocita’ di compilazione, non di esecuzione, e, come ho dimostrato, con un carico di lavoro solo vagamente importante, Stackless le prende di brutto.

E seconda cosa, Go ha una forma di coroutine (goroutine) e Stackless pure (tasklet), e sono state semplicemente messe a confronto.

Attualmente il primo le implementa facendo uso i thread di sistema e il secondo coi suoi green thread. In futuro potrebbero anche cambiare, chi lo sa, ma rimane un dettaglio dell’attuale implementazione, non del linguaggio di per sé. ;)

Mi fanno solo sorridere determinate affermazioni che non vengono commentate a dovere da chi fa i test (come a voler provare chissa’ cosa): se si usassero Thread invece che Tasklet, penso che i tempi di esecuzione sarebbero simili (per il semplice caso mostrato).

Se Go supportasse i Green Thread (ma ci vorrebbe una VM, o comunque una libreria piuttosto pesante), le prestazioni sarebbero simili.

La mia considerazione e’ che: paragonare un tizio che va in motorino in autostrada (ammesso che possa), con uno che va con un CBR-1000 in statale non ha molto senso.

Comunque è destinato a migliorare anche dal punto di vista prestazionale. Io ho sviluppato una versione di Python che è mediamente più veloce di quella ufficiale ( http://code.google.com/p/wpython/ ) e c’è la stessa Google che sta lavorando su questo fronte ( http://code.google.com/p/unladen-swallow/wiki/ProjectPlan ).

Tra l’altro è anche molto veloce nella compilazione del codice, ma la cosa interessante è che può anche ricaricare al volo un modulo senza far ripartire l’applicazione. Per chi sviluppa server è una preziosa funzionalità.

Grazie per i consigli: ho provato sia con xrange che con psyco, ma i risultati sono paragonabili (psyco taglia il tempo di esecuzione di un paio di secondi).

Python e’ uno splendido linguaggio, ma per determinati codepath non esiste che una VM riesca a star dietro a del compilato.

Per altro il punto di forza di Go, riguardo alla riduzione dei tempi, e’ proprio in compilazione, non tanto in esecuzione (che comunque e’ veloce).