[Python] Julia (Was: Walks like Python. Runs like C).

[enrico franchi]

2015-01-29 15:25 GMT+00:00 Carlos Catucci <carlos.catucci a gmail.com>:

>
> 2015-01-29 16:21 GMT+01:00 enrico franchi <enrico.franchi a gmail.com>:
>
>> Non concordi sul fatto che sia un delirio, sul fatto che sia creato da
>> sviluppatori per sviluppatori o su entrambe?
>>
>
> Sulla seconda direi che non sia un male.
> In fondo e' uno strumento che serve agli sviluppatori. Quando fai una cosa
> che possono usare i bimbominkia (chi ha detto PHP?) poi non ti lamentare se
> lo usano sopratutto loro.
>

Il problema e' che poi i servizi vanno mantenuti e ci vanno fatte sopra le
operations.
C'e' parecchia esperienza in tutto questo. E al di la della buzzword
"devops", tipicamente ci sono persone che sono molto brave a scrivere
codice, progettare interfacce e compagnia... e persone che sono molto brave
a mettere in piedi servizi. Quando hai gli sviluppatori che pensano un tool
senza molto input da parte della seconda categoria di persone, hai disastri
in attesa di accadere.

I tizi di node.js ti suggeriscono come buona pratica di prendere il
webserver che hai nella standard library (e fin qui poco male, ma adesso ci
arriviamo) e usare quello. In pratica l'applicazione e il webserver vivono
nello stesso mondo. Che sembra bello, si. Solo che e' anche una forma
piuttosto estrema di violazione di separations of concerns e di unnecessary
tight coupling.

Tipicamente nella maggior parte dei contesti hai un webserver (che parla
HTTP), hai un qualche tipo di application server (che smazza da HTTP alla
tua applicazione) e hai appunto la tua applicazione. Entro certi limiti, i
tre pezzi sono intercambiabili (e si parlano in modo standard). Per esempio
in Python puoi partire con Apache e quando hai un problema di scalabilita'
sulle richieste sostituirlo con NGINX. Ora l'effort di sviluppo che hai
fatto e' stato nell'applicazione, che tipicamente non sa un accidenti di
chi chi sta davanti. E sempre tipicamente non e' particolarmente
influenzato dal fatto che giri Apache o NGINX o LightHTTPd o chi per loro.
Se domani qualcuno scrive un web server che fa i giri intorno ad NGINX,
puoi metterlo su senza grossi problemi.

Se tieni tutto quanto integrato diventa tutto molto piu' complicato. In
questo ci sono una serie di problemi accessori, come per esempio... chi fa
la terminazione SSL? Avere tutto in un unico blocco monolitico vuole dire
cercare guai quando fai le operations.

Poi certo... davanti a node.js ci si mette spesso nginx a fare da *load
balancer* o da proxy... ma stavano cosi' bene separati per i fatti loro,
voglio dire. E allora... perche' forzarmi questa architettura quando
semplicemente potevo scegliermi i componenti come mi pareva, lasciando
chiaro quello che e' il mestiere del webserver e quello dell'applicazione.

Poi per inciso, non prendo troppo sul serio nel 2015 chi mi suggerisce che
semplicemente node.js "non blocca", quando e' evidente che non blocca
*sull'IO* e ignorare il fatto che si... a volte si blocca sulla CPU (tipo
perche' ci sono da fare dei conti). E questo te lo dovrebbero scrivere a
caratteri cubitali sulla home-page: "E' tutto magico finche'
improvvisamente qualche front-end developer che si e' riciclato backend
engineer non deve fare qualcosa piu' che smazzare un po' di rest API e fare
qualcosa con la CPU. A questo punto buttate tutto e usate qualcosa di
diverso oppure divertitevi a scrivervi uno scheduler cooperativo e
spezzatevi a mano i task CPU bound per funzionare. O passate per un sistema
di worker; e divertitevi a fare tutto questo in javafuckinscript."





-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150129/129b7a56/attachment.html>