On Wed, 11 Nov 2009 15:15:04 +0100, luigi scarso <luigi.sca...@gmail.com> wrote: > 2009/11/11 Manlio Perillo <manlio.peri...@gmail.com>: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Daniele Varrazzo ha scritto: >>> [...] >>> A te capita spesso di operare "a google scale"? >>> >>> A me no, ma di sicuro i limiti del Python li ho incontrati spesso. Solo >>> che non credo che "se fai il botto" allora ti basterebbe riscrivere la >>> stessa applicazione in un linguaggio più performante (Java o C) per >>> aver >>> risolto tutti i problemi. >> >> >> Io in un progetto che sto sviluppando mi sto appunto scontrando con >> l'inefficienza di Python [1], ma riscrivere in C non mi sembra proprio >> la soluzione. > >> >> Purtroppo sono ancora alla ricerca di un linguaggio tra C e Python, e ne >> Haskell, ne OCaml ne Erlang non mi sembrano adeguati. > lua+C ? > Groovy + Java ?
Cosa c'è in queste soluzioni che non sia già "tutto quello che un singolo processo può fare, solo un po' più veloce di quanto l'implementazione cPython non faccia)? A occhio e croce mi sembra "processo singolo, multi-thread forse, un misto di un linguaggio di sviluppo rapido con uno di livello inferiore e prestazioni superiori". Insomma, questo si fa anche con Python+C (magari Pyrex|Cython, entrambi fantastici, ma sono solo un aiuto), ma non risolve il problema di fondo: "il pasto gratis è finito" e Moore, che ci ha concesso decine di anni di generoso raddoppio di prestazioni ogni 18 mesi, non aiuta più a meno di non farsi trovare pronti ad andare oltre il singolo core. >> Erlang non mi piace proprio, e non lo ritengo general purpose. > Si, non credo che lo sia. > A me piace perchè "stacca" da python ie "qualcosa di completamente > differente" ; > non ci sono tanti modi per fare le cose. Chi mi conosce sa che non ho mai negato che Erlang sia un linguaggio sintatticamente bruttino e con una stdlib favolosamente incoerente: penso che nessun linguaggio come Erlang abbia bisogno di un "progetto 3K", altro che Python nel quale si considera brutto avere sia dict.items() che dict.iteritems(). Ma questo non fa che confermarmi che il problema non è nel linguaggio: Erlang è diverso e buono nel suo modello runtime, e il motivo per cui sceglierlo non è "il mio linguaggio non è più di moda", ma "il mio runtime non mi permette di scalare". Erlang è la prima alternativa abbordabile a una tecnologia che permetta di andare oltre i limiti del singolo processo Unix. -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python