Discussion:
Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
(too old to reply)
Carlos Catucci
2015-07-10 14:19:58 UTC
Permalink
Riporto quanto espresso sulla lista XPUG-BO dal prof. Marcello "Piffy"
Missiroli.

"Un mio commento a freddo sulla serata (che Ú stata molto carina, anche nel
post-evento)

Dato che ignoro il ramo applicativo di Go e di quali e quante libreria
siano disponibili, mi limiterò a valutare il linguaggio in sÚ e le sue
caratteristiche.

In sintesi, non Ú che mi abbia molto convinto.


- La sintassi Ú presa "parzialmente" dal C, ma con strane modifiche che
lo rendono soggetto a errori inconsci. Per esempio la scelta di avere il
tipo di dato DOPO la variabile. Il che crea costrutti particolamente poco
chiari come x := float32(y) che non Ú solo un'assegnazione.
- I controlli (if, then, else, switch) sono abbastanza carini, ma anche
qui l'idea di poter preporre un'assegnazione prima del controllo ne fa
perdere un po la leggibilità. Carini anche se non immediati i vari range,
map, un po' presi da python e ruby.
- La gestione degli array multidimensionali fa rabbrividire, a momenti Ú
meglio quella di Javascript che pure Ú atroce. :-)
- Interessante la gestione dei canali per lo scambio dei dati tra thread
- defer Ú un'innovazione, ma che serve in soldoni?
- NOn abbiamo approfondito la questione degli oggetti, ma sempra
un'aggiunta alla fine, più object-based che object-oriented.

Nella mia prospettiva da docente e/o curioso, non vedo un grande appeal su
questo linguaggio che prende un po' dal C classico, python, ruby, java, C#
e node/javascript ma non ottiene nÚ codice di facile lettura (tutt'altro)
nÚ codice più stringato. Qual Ú quindi la "mission" del linguaggio? Forse Ú
quella della massima portabilità e velocità di esecuzione, ma questo non
abbiamo potuto provarlo - forse in futuro?"

Attendo risposte (che con il vostro permesso riportero' all'esimio prof,
nonche' amico di vecchia data)

Carlos
--
EZLN ... Para Todos Todo ... Nada para nosotros
Nicola Larosa
2015-07-10 14:47:41 UTC
Permalink
Post by Carlos Catucci
Attendo risposte (che con il vostro permesso riportero' all'esimio
prof, nonche' amico di vecchia data)
Quanto avrei da dire è piuttosto negativo, sia sulla valutazione che sul
metodo usato per arrivarci, quindi non dirò nulla per non offendere
l'esimio prof nonché amico di vecchia data. :-P
--
Nicola 'tekNico' Larosa <http://www.tekNico.net/>
Simone Federici
2015-07-10 15:09:22 UTC
Permalink
Quanto avrei da dire Ú piuttosto negativo, sia sulla valutazione che sul
metodo usato per arrivarci, quindi non dirò nulla per non offendere
l'esimio prof nonché amico di vecchia data. :-P
dai dai.. illuminaci
:-)
Riccardo Magliocchetti
2015-07-10 15:09:43 UTC
Permalink
Post by Nicola Larosa
Post by Carlos Catucci
Attendo risposte (che con il vostro permesso riportero' all'esimio
prof, nonche' amico di vecchia data)
Quanto avrei da dire è piuttosto negativo, sia sulla valutazione che sul
metodo usato per arrivarci, quindi non dirò nulla per non offendere
l'esimio prof nonché amico di vecchia data. :-P
Già. Il fatto che abbiano messo nei parametri delle funzioni i tipi dopo ai nomi
delle variabili ha spiazzato anche me.
Con gli occhi del pythonista probabilmente go non sembra granchè (forse fa anche
un pò male agli occhi) ma con gli occhi da sviluppatore C dici: ah le slice mica
male, e il defer mi aiuta a non dover usare goto e label per gestione errori, etc...
--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it
enrico franchi
2015-07-10 16:49:57 UTC
Permalink
2015-07-10 15:19 GMT+01:00 Carlos Catucci <***@gmail.com>:

Riporto quanto espresso sulla lista XPUG-BO dal prof. Marcello "Piffy"
Post by Carlos Catucci
Missiroli.
"Un mio commento a freddo sulla serata (che Ú stata molto carina, anche
nel post-evento)
Dato che ignoro il ramo applicativo di Go e di quali e quante libreria
siano disponibili, mi limiterò a valutare il linguaggio in sÚ e le sue
caratteristiche.
Mi sembra che la premessa chiarifichi tutto: ovvero, non ci ho scritto 3
righe di fila. E da molti dei commenti che fa sotto, e' parecchio chiaro.
In particolare parecchie delle questioni che segnala sono cose che si
chiariscono affrontando un progettino giocattolo. Sono li e hanno senso.
Post by Carlos Catucci
In sintesi, non Ú che mi abbia molto convinto.
- La sintassi Ú presa "parzialmente" dal C, ma con strane modifiche
che lo rendono soggetto a errori inconsci. Per esempio la scelta di avere
il tipo di dato DOPO la variabile. Il che crea costrutti particolamente
poco chiari come x := float32(y) che non Ú solo un'assegnazione.
E qui, per dire, fa come esempio una questione relata al tipo, ma che
*non* e' un problema di dichiarazione. Ovvero, in Go *tutte* le
dichiarazioni hanno il tipo in coda (o non hanno tipo esplicito in quanto
inferito dal compilatore). Che e' strano se vieni da C, certo. Che e' anche
uno dei motivi per cui si evitano molte ambiguita' nel parsing che hanno C
e C++. Nota a margine: le ambiguita' non sono solo per il compilatore, ma
per chi legge.

a * b in C puo' essere, per dire, una dichiarazione di una variabile
puntatore ad a oppure una moltiplicazione. In go e' solo una
moltiplicazione.
Ci sono un po' di spiegazioni di queste problematiche sulle faq.

Ora, queste cose ad occhio non e' che mi aspetti che le veda.

E quella li *non* e' una dichiarazione. Cioe', si, formalmente e' una
dichiarazione. Ma la parte di dichiarazione e' semplicemente

x := <expr>

il fatto che expr sia un type cast... beh, vabbe'. ma non e'
particolarmente diverso da fare x = int(y) in Python.
Post by Carlos Catucci
- I controlli (if, then, else, switch) sono abbastanza carini, ma
anche qui l'idea di poter preporre un'assegnazione prima del controllo ne
fa perdere un po la leggibilità.
if a, err := build_a(...); err != null {
defer clean_a(a)
}
Post by Carlos Catucci
- Carini anche se non immediati i vari range, map, un po' presi da
python e ruby.
Anche qui... cosa non abbia di immediato range non lo so. Ricordiamoci che
esplicito e' bello. Vogliamo iterare su un array?

for el := arr {

}

ecco... questo dovrebbe volere dire cosa? che voglio iterare su un array?
Pero' attenzione... quell el := arr all'inizio sembra molto un assegnamento
"semplice" (per inciso, il codice non compila, ma solo per intenderci.

Questo invece compila:
for el := a;; {

fmt.Println(el)
}

e ovviamente e' un loop infinito. etc etc etc. io trovo che usare range sia
piuttosto carino sia come sintassi che come semantica. Non a caso Python
usa una keyword apposta per indicare che un "assegnamento" prende valori da
un iterabile (for el in a). In Go hanno scelto una cosa diversa... a me
piace. anche perche' non "rompe" la sintasi. Nota che range funziona con
tutto quello che go considera in qualche modo "iterabile".

map... map non capisco cosa ci sia da non capire.
Post by Carlos Catucci
- La gestione degli array multidimensionali fa rabbrividire, a momenti
Ú meglio quella di Javascript che pure Ú atroce. :-)
?
Go (come C e parecchi linguaggi la fuori) *non* ha array multidimensionali.
Non ce li ha e basta.
Quello che Go (come C e parecchi linguaggi la fuori) ha, sono *array di
array*.
E' un problema? In generale si. Per dire che vuole fare hpc lo e' in modo
indubbio. Verrebbe anche da dire che le ovvie estensioni probabilmente non
funzionerebbero troppo bene se si vuole mantenere l'attuale semantica di
Go. Pero' la differenza built-in fra array e slice potrebbe proprio essere
chiave per farci cose interessanti. Non so... ci devo pensare.
Post by Carlos Catucci
- Interessante la gestione dei canali per lo scambio dei dati tra thread
E io scommetto che, come a tutti quanti finche' non ci sbattono il muso,
non gli sono *davvero* chiari. E non gli e' davvero chiaro perche' e'
facile usarli. La differnza fra uno con buffer e uno senza buffer, per
dire... etc etc etc.
Post by Carlos Catucci
- defer Ú un'innovazione, ma che serve in soldoni?
Esticazzi pero'... come a che serve? Dico ma sono l'unico che ha
l'abitudine di pulire le cose che alloca? Lo facevo in C, lo facevo in C++,
lo faccio in Python e in Java... big surprise: voglio farlo anche in Go.
Visto che RAII e' out of the picture... posso usare goto, certo. Ma
veramente... defer e' chiaramente una soluzione superiore.
Post by Carlos Catucci
- NOn abbiamo approfondito la questione degli oggetti, ma sempra
un'aggiunta alla fine, più object-based che object-oriented.
O dannazione ancora? Quanto male hanno fatto alle comunita' la propaganda
spietata di chi voleva vendere gli oggetti a partire dagli anni 80 e'
smodato.
Tanto per dire... tutt'ora la maggior parte degli sviluppatori in linguaggi
ad oggetti non hanno capito la programmazione ad oggetti (che e' un
problema). Che e' un formalismo matematicamente mal definito *e* piuttosto
complicato da capire. Almeno le typeclasses alla haskell sono si complicate
da capire ma sono molto facili da usare. Poi su tutto... chiedi a 10
persone "competenti" e hai 10 definizioni di OOP tutte leggermente diverse.

E no.. non sono d'accordo che il sistema di tipi di Go sia "un'aggiunta
alla fine". Mi sembra anzi qualcosa di molto organico che ha interazioni
eccellenti con le altre feature del linguaggio e che e' completamente
chiave nel progetto complessivo. Tra l'altro quello che mi piace e' che e'
*semplicissimo* da capire tutto quanto. E' proprio facile. Ed e'
relativamente difficile da cannare.
Post by Carlos Catucci
Nella mia prospettiva da docente e/o curioso, non vedo un grande appeal su
questo linguaggio che prende un po' dal C classico, python, ruby, java, C#
e node/javascript ma non ottiene nÚ codice di facile lettura (tutt'altro)
nÚ codice più stringato.
Boh? "Stringato" non mi sembra un vantaggio... e si, Go non ha come
obiettivo battere Perl sui golf. Facile lettura? Non ho *mai* e dico *mai*
incontrato un linguaggio piu' facile di Go da leggere. No, nemmeno Python.
Cioe', Python 2.2 in un certo punto era altrettanto facile da leggere. Dopo
di che e' stato un continuo feature creep che rendono Python tutt'altro che
facile da leggere.

Tutti quelli che considerano Python facile da leggere non devono solo
considerare il problema "riesco a rileggere il codice che ho scritto"
(problema non banale, certi linguaggi falliscono malamente anche questo).
Ma devono considerare anche il problema: riesco a leggere facilmente il
codice che un altra persona (che potrebbe essere il Franchi in vena di
metaprogramming) scrive? La mia esperienza e' *no*. Tanto e' vero che, per
dire, sul lavoro mi contengo.

Per esempio chi ha *assolutamente* chiaro come funzionano e come
interagiscono fra di loro:

* decoratori (specialmente carina l'interazione con l'ereditarieta' --
consiglio spassionato: se usate dei decoratori, assicuratevi di non avere
mai overriding)
* generatori (e specialmente farci .send -- il tutto anche in presenza di
eccezioni)
* __new__ (e specialmente come si va avanti quando si sottoclassa)
* metaclassi (differenze e similitudini con __new__... e cosa succede
quando si definisce __new__ su qualcosa che ha una metaclasse)
* __new__ definito *sulla* metaclasse
* similitudini e differenze fra un classmethod di una classe con una
metaclasse e un metodo normale della metaclasse
* descrittori (e specialmente come interagiscono fra oggetti classe e
classi)
* buffer protocol
* funzionamento reale delle abc.

Ora a me la maggior parte della roba la sopra e' "abbastanza" chiara. Ma
davvero, ci sono una serie di interazioni sorprendenti tutt'ora. Se sentite
di dare il suggerimento: si ma non usare feature x, forse dovrebbe essere
chiaro che Python non e' cosi' leggibile come sembra. Poi certo, se avessi
fatto una lista per altri linguaggi sarebbe stata molto piu' lunga.

D'altra parte Go non ha (al momento) *nessuna* feature complicata. Non ce
l'ha. Quando il codice Go e' complicato, e' perche' il problema che si sta
risolvendo e' complicato.
Post by Carlos Catucci
Qual Ú quindi la "mission" del linguaggio? Forse Ú quella della massima
portabilità e velocità di esecuzione, ma questo non abbiamo potuto provarlo
- forse in futuro?"
Davvero? Cioe' quale e' la mission?

"""
Go is an open source programming language that makes it easy to build
simple, reliable, and efficient software.
"""

Ma diciamo che e' uno slogan e uno non ha aperto la homepage del sito.
Diciamo anche che effettivamente non vuole dire una fava: concordo. Visto
che nessuno direbbe che ha fatto un linguaggio che dichiara avere scritto
per creare "overly complicated, unreliable and inefficient software".
Sebbene, per intenderci, PHP matcha abbastanza la definizione.

Ecco... diciamo che e' complicato non accorgersi che Go nasce con l'idea di
rendere umano risolvere problemi di concorrenza. Ora, siccome *tutto* il
software a venire dovra' risolvere problemi di concorrenza... fate voi.
--
.
..: -enrico-
Carlos Catucci
2015-07-10 19:16:58 UTC
Permalink
Post by enrico franchi
Tutti quelli che considerano Python facile da leggere non devono solo
considerare il problema "riesco a rileggere il codice che ho scritto"
(problema non banale, certi linguaggi falliscono malamente anche questo).
Ma devono considerare anche il problema: riesco a leggere facilmente il
codice che un altra persona (che potrebbe essere il Franchi in vena di
metaprogramming) scrive? La mia esperienza e' *no*. Tanto e' vero che, per
dire, sul lavoro mi contengo.
Una persona normale, intendo dire un vdeveloper, fa fatica anche a capire
la meta' delle cose che dice il Franchi, ovvio che se si mette a
programmare ad alto livello, seguendo fili logici che un comune mortale (o
una comune mortadella come me) neppure riesce a immaginare nei suoi viaggi
dopo avere "tagliato una punta di acido", non capisca una cippa del codice.
Pero' codice del Franchi a parte io sono sempre riuscito a leggere e capire
piu' o meno al volo codice Python scritto da altri. Non conosco Go (ma
voglio studiarlo se solo ho un poco di respiro) per cui non posso dire se
sarei capace di leggerlo altrettanto semplicemente. Con Python, nella
stessa situazione pero', non ho avuto problemi a leggere il rpimo listato
(e non era un fibonacci o simili ma una applicazione complessa).
Poi abbi pazienza, lui e' un prof delle superiori, ha come target ragazzi
di 14/18 anni che si avvicinano alla programmazione, non un tale che lavora
per una non meglio specificata $bigcompany.
Pero' come sempre leggere le tue considerazioni aiuta a aprirsi la mente.
Aggiungo che ci contavo un poco di leggere cose rispondevi, una benevola
provocazione da parte mia girare qui quella mail.

Carlos
--
EZLN ... Para Todos Todo ... Nada para nosotros
enrico franchi
2015-07-12 16:58:33 UTC
Permalink
Post by enrico franchi
Tutti quelli che considerano Python facile da leggere non devono solo
Post by enrico franchi
considerare il problema "riesco a rileggere il codice che ho scritto"
(problema non banale, certi linguaggi falliscono malamente anche questo).
Ma devono considerare anche il problema: riesco a leggere facilmente il
codice che un altra persona (che potrebbe essere il Franchi in vena di
metaprogramming) scrive? La mia esperienza e' *no*. Tanto e' vero che, per
dire, sul lavoro mi contengo.
Una persona normale, intendo dire un vdeveloper, fa fatica anche a capire
la meta' delle cose che dice il Franchi, ovvio che se si mette a
programmare ad alto livello, seguendo fili logici che un comune mortale (o
una comune mortadella come me) neppure riesce a immaginare nei suoi viaggi
dopo avere "tagliato una punta di acido", non capisca una cippa del codice.
Pero' codice del Franchi a parte io sono sempre riuscito a leggere e capire
piu' o meno al volo codice Python scritto da altri. Non conosco Go (ma
voglio studiarlo se solo ho un poco di respiro) per cui non posso dire se
sarei capace di leggerlo altrettanto semplicemente. Con Python, nella
stessa situazione pero', non ho avuto problemi a leggere il rpimo listato
(e non era un fibonacci o simili ma una applicazione complessa).
Si, in realta' buona parte del mio codice *non* usa (o fa un uso molto
limitato) di suddette features, e non faccio passare codice che ne abusa.
Il discorso non e' quanto avanzato e' il mio python rispetto a quello del
"programmatore medio".

Il problema e' che "Python e' leggibile" se e solo se non si usano (o
abusano) determinate features. Altrimenti e' leggibile per un sottoinsieme
ristretto di persone e *soprattutto* non e' il codice che vuoi guardare
alle 3 di mattina quando sei stato svegliato perche' l'applicazione e'
rotta. Non vuoi farlo se il codice e' tuo, non vuoi farlo se il codice e'
di qualcun altro.

Ma se cominci a dire che "il linguaggio e' leggibile se non usi feature x e
y" comincia ad indebolirsi molto il fatto che il linguaggio sia leggibile.
Perche' restringendo arbitrariamente il sottoinsieme di linguaggio
leggibile, tutto sommato parecchi linguaggi non patologicamente illeggibili
diventano "leggibili". E anche alcuni linguaggi patologici.

Io posso dire che Python sufficientemente vecchio era molto leggibile.
Leggibile perche' aveva meno features e soprattutto meno features
"complesse". Piano piano le hanno aggiunte, e' tutta roba molto potente e
interessante, ma alla fine dei conti e' anche tutta roba che rende il
codice relativamente troppo complicato da capire per essere considerato
leggibile.

Il motivo per cui tutto sommato la maggior parte del codice Python la fuori
e' sempre considerato leggibile e' che la maggior parte dei programmatori
non abusano troppo di queste features (per scelta o per ignoranza). Ma di
per se, il problema e' presente.
Post by enrico franchi
Poi abbi pazienza, lui e' un prof delle superiori, ha come target ragazzi
di 14/18 anni che si avvicinano alla programmazione, non un tale che lavora
per una non meglio specificata $bigcompany.
Si, ma niente da dire su di *lui*. Quello che io sto dicendo e' che *a mio
avviso* Go e' piu' leggibile di Python. Almeno per ora. Poi certo, se e
quando cominceranno a farcirlo di features fichissime (ma complicate) anche
lui sara' molto meno leggibile.

Insomma, per fare un altro paragone... Haskell e' un linguaggio
*estremamente* leggibile. Ha regole piuttosto rigorose sulla formattazione,
etc etc etc. Pero'... diciamo che se uno non mastica alcuni concetti
relativamente poco intuitivi non si va troppo lontano. Non ho vergogna ad
ammettere che spesso e volentieri quando leggo codice scritto da gente che
fa Haskell duro non capisco davvero un accidente, ma e' un modo diverso di
non capire che cavolo fa rispetto a quando mi danno il classico blobbone da
2000 righe di Perl da riscrivere in qualcos'altro.
--
.
..: -enrico-
Alessandro Re
2015-07-12 22:24:58 UTC
Permalink
Post by enrico franchi
Io posso dire che Python sufficientemente vecchio era molto leggibile.
Leggibile perche' aveva meno features e soprattutto meno features
"complesse". Piano piano le hanno aggiunte, e' tutta roba molto potente e
interessante, ma alla fine dei conti e' anche tutta roba che rende il
codice relativamente troppo complicato da capire per essere considerato
leggibile.

Intervengo per un piccolo commento: credo di aver capito cosa intendi, ma
secondo me la complessità e la leggibilità di un linguaggio non sono legate
in quel senso. Un linguaggio leggibile Ú leggibile sempre, anche se trovare
bachi alle 3 di notte può essere complesso. La leggibilità penso che sia
legata anche alla capacità del linguaggio di presentarsi in modo
"familiare" e "intuitivo", anche attraverso della complessità che nasconde
dettagli non rilevanti alla comprensione generale.

Faccio un esempio scemo: il costrutto with Ú molto utile e potente. Ciò che
ci sta dietro Ú relativamente complesso (NB Ú un esempio scemo!) e di fatto
la complessità viene mascherata dal costrutto e dalle "magie" che ci son
dietro. Ora, se uno nasconde una cosa molto complessa dietro with, magari
debuggers alle 3 di notte Ú una menata perché tu *sai* che c'Ú dietro della
complessità e che magari il baco sta lì. Però guardare il codice Ú capire
che with ti crea un contesto che viene aperto e chiuso Ú un concetto
piuttosto immediato, quindi quando leggi il codice capisci in fretta cosa
si cerca di fare.

Forse tu parli di "leggibile" ma vuoi dire "palese" o "esplicito" mentre io
dico "veloce farsi un'idea". Però questo non vuol dire che non ci possa
essere dietro della complessità che viene nascosta per rendere, appunto,
tutti leggibile.

Se ho fatto typos Ú perché son dal cellulare, abbiate pazienza :p
~Ale
Davide Muzzarelli
2015-07-10 18:21:23 UTC
Permalink
Post by Carlos Catucci
Attendo risposte (che con il vostro permesso riportero' all'esimio prof,
nonche' amico di vecchia data)
Uso Go in produzione da un anno e mezzo circa, in poco tempo ho
sviluppato un software per gestire i prodotti di un eCommerce più
qualche altro tool per me (server SMPP, websocket e altre cose più piccole).

Il programma ha diverse funzioni sia come server web che da linea di
comando, lavora su 3 database diversi contemporaneamente (Postgresql,
MSSQL e MySQL) per gestire dati tra Microsoft Navision, Magento e dati
aggiuntivi suoi. Ha interfacce web e CLI, non ho dovuto usare alcun
framework, è estremamente veloce rispetto a Python, consuma un decimo
della memoria che consuma Python e non ha i problemi di GIL.
Post by Carlos Catucci
* La sintassi è presa "parzialmente" dal C, ma con strane modifiche
che lo rendono soggetto a errori inconsci. Per esempio la scelta di
avere il tipo di dato DOPO la variabile. Il che crea costrutti
particolamente poco chiari come x := float32(y) che non è solo
un'assegnazione.
La sintassi è presa a piene mani dal C. L'obiettivo era permettere ai
neo-laureati, che solitamente hanno studiato C a scuola, di essere
subito produttivi in pochi giorni.

In pratica è come un C fatto per chi viene da linguaggi di scripting.
Post by Carlos Catucci
* I controlli (if, then, else, switch) sono abbastanza carini, ma
anche qui l'idea di poter preporre un'assegnazione prima del
controllo ne fa perdere un po la leggibilità. Carini anche se non
immediati i vari range, map, un po' presi da python e ruby.
then non esiste in Go.

if è identico agli altri linguaggi tranne la possibilità opzionale di
creare un'assegnazione con scopo privato, e mi pare molto chiara come
espressione dato che la logica sarebbe prima di creare una variabile e
poi di usarla:

if err := eseguiQualcosa(); err != nil {
...
}

switch/case è simile ad altri linguaggi, molto facile da leggere:

switch valore {
case "vero":
return true
case "falso":
return false
default:
return nil
}

map è un semplice hash:

numeri := map[string]int{
"uno": 1,
"due": 2,
"tre": 3,
}
print(numeri["uno"])

range è completamente diverso da Python.
Python: for x in tupla
Go: for k, v := range tupla
Post by Carlos Catucci
* La gestione degli array multidimensionali fa rabbrividire, a momenti
è meglio quella di Javascript che pure è atroce. :-)
In Go puoi solo avere array di array.
Post by Carlos Catucci
* Interessante la gestione dei canali per lo scambio dei dati tra thread
E' un pattern e lo hanno implementato in maniera molto comoda da usare e
prevenendo i soliti errori comuni, in effetti ha semplificato
notevolmente l'uso di parallelismo e concorrenza.
Post by Carlos Catucci
* defer è un'innovazione, ma che serve in soldoni?
defer è estremamente utile per scrivere software stabile, serve quando
vuoi essere sicuro che venga eseguita una funzione anche in caso di errore.

Un esempio banale è quando vuoi essere sicuro che venga chiuso un
descrittore di un file o una connessione dopo averlo aperta.

In questo esempio, il file verrebbe chiuso correttamente anche nel caso
in cui f.Write() restituisse un errore:

f, _ := os.Open("nome del file")
defer f.Close()
n, err := f.Write("foobar")
if err != nil {
return "Errore, spazio su disco esaurito"
}

Inoltre aiuta nella lettura del programma perché in questo modo le
operazioni di apertura sono vicine alle funzioni di pulizia e chiusura.
Se le funzioni fossero lontane, tipo le prime all'inizio della funzione
e le altre alla fine, diventerebbe più facile commettere errori o
dimenticarsi qualcosa inoltre si dovrebbe scrivere il codice per pulire
e chiudere anche in caso di errore.
Post by Carlos Catucci
* NOn abbiamo approfondito la questione degli oggetti, ma sempra
un'aggiunta alla fine, più object-based che object-oriented.
Go è decisamente object-oriented e non object-based e lo è usando il
pattern dell'aggregazione al posto di quello dell'editarietà.

Go ha array, scalari ecc. che non sono per niente oggetti.
Post by Carlos Catucci
Nella mia prospettiva da docente e/o curioso, non vedo un grande appeal
su questo linguaggio che prende un po' dal C classico, python, ruby,
java, C# e node/javascript ma non ottiene nè codice di facile lettura
(tutt'altro) nè codice più stringato. Qual è quindi la "mission" del
linguaggio? Forse è quella della massima portabilità e velocità di
esecuzione, ma questo non abbiamo potuto provarlo - forse in futuro?"
Go prende direttamente dal C, ben poco da altri linguaggi.

Ancora non è pronto per applicazioni GUI per scarsità di librerie oppure
per applicazioni web nella maniera classica perché la tipizzazione
statica diventa scomoda da usare rispetto a Python/Ruby.

Go è una via di mezzo tra il C e il Python, attrae molti più
programmatori da Python che da C/C++.

La sintassi è semplice con pochi costrutti, molto chiara, il codice
viene pulito e identato direttamente dai tool forniti col compilatore
(avere uno standard di questo genere è una manna dal cielo per i
software scritti da molte persone), la compilazione semplifica
notevolmente i deploy, la tipizzazione statica previene numerosi bug, il
garbage collector e le interfacce generiche aiutano a guadagnare un
sacco di tempo evitando nel contempo stack overflow e compagnia bella,
il ridotto uso di memoria è fondamentale quando si scalano le
applicazioni (ci sono team che hanno ridotto i server di un ordine di
potenza rispetto a Python/Ruby), le performance sono molto vicine a
quelle del C (e continuano a migliorare).

La filosofia di base è molto simile a quella di Python e di Unix:
- Piccoli componenti altamente specializzati
- Esplicito è meglio che implicito
- Piatto è meglio che annidato
- Sparso è meglio che denso
- La leggibilità conta (per questo Go ha un tool per pulire il codice)
- Grande praticità al posto di grandi filosofie
- Gli errori dovrebbero essere sempre espliciti (infatti gli errori sono
passati come valore, se si vuole vanno esplicitamente ignorati al
contrario che con Python)
- Aggregazione
- Namespace
- Semplicità (Python 3 non mi pare abbia ormai perso questa caratteristica)
- Un solo modo di fare le cose

Per rispondere alla domanda sulla mission, ecco un elenco delle cose
dove Go eccelle:
- API (sia client che server)
- Applicazioni ad alta parallelizzazione e concorrenza
- Applicazioni server di elaborazione dati da molti utenti (es.
map-reduce, elaborazione di immagini, parsing di testi, conversione di
dati ecc.)
- Programmi a linea di comando
- Sistemi in genere (vedi Docker, Reborn, Doozer, Juju, Vitess, Dropbox,
CloudFlare e tanti altri) tranne i sistemi operativi e le applicazioni
in real-time (presto sarà possibile fare del soft-real-time)
- Database distribuiti

La community è in forte crescita ed è decisamente facile leggere il
codice scritto da un'altra persona. Python ha una sintassi ancora più
leggibile ma i programmi scritti in Python non sono altrettanto facili
da comprendere come quelli in Go.

In pratica sostituisce bene Python in tutte quelle situazioni dove sono
richieste performance, basso consumo di risorse, stabilità e
manutenzione di medi o grossi sorgenti. Lo scotto da pagare sono i tempi
di sviluppo maggiori di circa il 50%.

Sostituisce bene C in tutte quelle situazioni dove la velocità di
sviluppo è importante quanto le performance e dove il progetto è di
grandezza media o alta.

Go è un linguaggio che ha i suoi difetti ma sono veramente pochi, anche
Python e C hanno i loro difetti eh.

Detto questo continuerò a scrivere siti web in Python e applicazioni web
in Go ;)

Buona serata,
Davide Muzzarelli
Carlos Catucci
2015-07-10 19:27:09 UTC
Permalink
In questo esempio, il file verrebbe chiuso correttamente anche nel caso in
f, _ := os.Open("nome del file")
defer f.Close()
n, err := f.Write("foobar")
if err != nil {
return "Errore, spazio su disco esaurito"
}
Scusa solo per capire, dov'e' la differenza con try except? E comunque tu
indich defer (non lo conosco bene) subito dopo avere aperto. Implica che
verra' eseguito COMUNQUE (tipo finally per capirci) alla fine della
funzione? Se si e' davvero una cosa buona.
Go Ú un linguaggio che ha i suoi difetti ma sono veramente pochi, anche
Python e C hanno i loro difetti eh.

Beh nessuno e' perfetto (tranne Andy ;P). Comunque si penso che per certe
cose sia interessante. Gia' intendevo riscrivere con Flask i web services
del progetto. Se i boss non mi farranno girare le palle al punto da essere
sfanculati, potrei pensare di ricriverene una buona parte in Go. In
particolair quelli che gestiranno le connessioni/disconnessioni degli
utenti sui router. (*)

* Trattasi di rete wifi free dove chi entra si connette come se fosse la
rete di casa. Questo comporta che io debba far registrare dati provenienti
dai vari router (si conta a progetto avviato di averne qualche decina di
milgiaia) tutti i casi di connessione/disconnessione che potrebbe essere un
problema non da poco con Python (ce la fara' a reggere? Potrebbero arrivare
in pochi secondi un numero elevatissimo di segnalazioni).

Carlos
--
EZLN ... Para Todos Todo ... Nada para nosotros
Manlio Perillo
2015-07-11 10:13:00 UTC
Permalink
Post by Carlos Catucci
Post by Davide Muzzarelli
In questo esempio, il file verrebbe chiuso correttamente anche nel caso
f, _ := os.Open("nome del file")
defer f.Close()
n, err := f.Write("foobar")
if err != nil {
return "Errore, spazio su disco esaurito"
}
Scusa solo per capire, dov'e' la differenza con try except?
Che try/except aggiungono un ulteriore livello di nidificazione che rende
la lettura del codice meno lineare.

Ad esempio:

try:
makedirs(path)
except OSError, err
if err.errno == errno.EEXISTS:
return

raise

Il maggiore problema con le eccezione Ú semplicemente che tu *non puoi
sapere* se e quale eccezione può lanciare una funzione.
In C++ e Java ci hanno provato [1], ma non funziona.

In Go lo sai semplicemente vedendo cosa restituisce la funzione.
Post by Carlos Catucci
[...]
[1] https://en.wikipedia.org/wiki/Exception_handling#Checked_exceptions


Ciao Manlio
Davide Muzzarelli
2015-07-11 10:40:07 UTC
Permalink
Post by Carlos Catucci
Scusa solo per capire, dov'e' la differenza con try except? E comunque
tu indich defer (non lo conosco bene) subito dopo avere aperto. Implica
che verra' eseguito COMUNQUE (tipo finally per capirci) alla fine della
funzione? Se si e' davvero una cosa buona.
E' come in finally, con la differenza che puoi metterli nel punto dove
preferisci e non devi creare dei livelli d'identazione quando ne devi
creare più di uno. In sostanza sono più comodi e semplici da utilizzare
rispetto ai finally.
Post by Carlos Catucci
Post by Davide Muzzarelli
Go è un linguaggio che ha i suoi difetti ma sono veramente pochi,
anche Python e C hanno i loro difetti eh.
Beh nessuno e' perfetto (tranne Andy ;P).
:)
Post by Carlos Catucci
Comunque si penso che per
certe cose sia interessante. Gia' intendevo riscrivere con Flask i web
services del progetto. Se i boss non mi farranno girare le palle al
punto da essere sfanculati, potrei pensare di ricriverene una buona
parte in Go. In particolair quelli che gestiranno le
connessioni/disconnessioni degli utenti sui router. (*)
* Trattasi di rete wifi free dove chi entra si connette come se fosse la
rete di casa. Questo comporta che io debba far registrare dati
provenienti dai vari router (si conta a progetto avviato di averne
qualche decina di milgiaia) tutti i casi di connessione/disconnessione
che potrebbe essere un problema non da poco con Python (ce la fara' a
reggere? Potrebbero arrivare in pochi secondi un numero elevatissimo di
segnalazioni).
Go sarebbe adatto per quel progetto.

Ogni gorutine (simile ai thread) occupa 4kb. In 350MB di RAM puoi
gestire circa 90.000 connessioni aperte simultaneamente. Puoi usare
tutte le CPU a disposizione fin da subito senza scrivere codice aggiuntivo.

Sicuramente farai prima a scriverlo in Python che in Go, anche perché
dovresti imparare ad usarlo. Valuta tu se hai bisogno di quelle performance.

Byez,
Davide Muzzarelli
Carlos Catucci
2015-07-11 11:18:29 UTC
Permalink
Post by Davide Muzzarelli
E' come in finally, con la differenza che puoi metterli nel punto dove
preferisci e non devi creare dei livelli d'identazione quando ne devi
creare più di uno. In sostanza sono più comodi e semplici da utilizzare
rispetto ai finally.
Verdad, la gestione e' semplficata, ma la leggibilita' lo diventa solo
quando hai capito come funzionano. Il Try Except Finally Else di Python e'
immediato. Tranen forse Else ecco. Che comunque trovo comodissimo da avere.
Post by Davide Muzzarelli
Go sarebbe adatto per quel progetto.
Ogni gorutine (simile ai thread) occupa 4kb. In 350MB di RAM puoi gestire
circa 90.000 connessioni aperte >simultaneamente. Puoi usare tutte le CPU a
disposizione fin da subito senza scrivere codice aggiuntivo.
Post by Davide Muzzarelli
Sicuramente farai prima a scriverlo in Python che in Go, anche perché
dovresti imparare ad usarlo. Valuta tu se hai >bisogno di quelle
performance.

Forse non ne avro' bisogno, ma e' una ottima occasione per poterlo studiare
e usare su un progetto reale.
In fondo essendo una serie di Web Services che in comune hanno solamente la
base dati, posso benissimo lasciare in Python (sempre riscrivendo per
Flask) le parti piu' incasinate come logiche ma che hanno meno richieste di
performance (esempio la registrazione dell'utente che si ha solo la prima
volta che installa la app) e scrivere in Go quelle dove invece performance
etc. sono vitali.

Ma un wrapper per codice Go da Python non lo hanno mai pensato? Io non so
se sariei capace di scriverlo, ma lo troverei utile.

Carlos
--
EZLN ... Para Todos Todo ... Nada para nosotros
Nicola Larosa
2015-07-11 12:26:56 UTC
Permalink
Post by Carlos Catucci
Ma un wrapper per codice Go da Python non lo hanno mai pensato?
Io non so se sarei capace di scriverlo, ma lo troverei utile.
La v.1.5 di Go, che esce il mese prossimo, è la prima che supporta la
scrittura di librerie dinamiche: prima era quasi impossibile.

Non so se qualcuno sta già scrivendo un wrapper Python, ma non credo
passerà molto tempo prima che ne spunti uno. :-)
--
Nicola 'tekNico' Larosa <http://www.tekNico.net/>
Carlo Miron
2015-08-26 09:58:51 UTC
Permalink
Post by Nicola Larosa
Post by Carlos Catucci
Ma un wrapper per codice Go da Python non lo hanno mai pensato?
Io non so se sarei capace di scriverlo, ma lo troverei utile.
La v.1.5 di Go, che esce il mese prossimo, è la prima che supporta la
scrittura di librerie dinamiche: prima era quasi impossibile.
Non so se qualcuno sta già scrivendo un wrapper Python, ma non credo
passerà molto tempo prima che ne spunti uno. :-)
Per esempio da un post del buon filosottile:
<https://blog.filippo.io/building-python-modules-with-go-1-5/>

©
--
|:**THE BEER-WARE LICENSE** (Revision 42):
| <***@golang.it> wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
| --Carlo Miron :
Carlos Catucci
2015-08-26 10:05:26 UTC
Permalink
Post by Carlo Miron
<https://blog.filippo.io/building-python-modules-with-go-1-5/>
Ecco che Go mi sta piu' simpatico di prima ;)

Trovo che per certe cose (eg. concorrenzialita', parallelismo etc.) sia
ovviamente una scelta migliore di Python. Ma se posso wrappare la parte
scritta in Go all'interno di una applicazione Python, con tutti i suoi
vantaggi (eg. un ORM, un Template engine, un framework robusto) davvero il
binomio e' vincente.

Carlos
--
EZLN ... Para Todos Todo ... Nada para nosotros
enrico franchi
2015-08-26 13:18:34 UTC
Permalink
Post by Carlos Catucci
Trovo che per certe cose (eg. concorrenzialita', parallelismo etc.) sia
ovviamente una scelta migliore di Python. Ma se posso wrappare la parte
scritta in Go all'interno di una applicazione Python, con tutti i suoi
vantaggi (eg. un ORM, un Template engine, un framework robusto) davvero il
binomio e' vincente.
A me sembra interessante che si possa fare, ma mi sembra piu' un proof of
concept che altro. Se il problema e' scrivere un'estensione a Python che
vada veloce, direi che ci sono gia' vari metodi. Avere anche Go e'
chiaramente meglio che non averlo, ma credo che sia inevitabilmente piu'
scomodo di qualcosa come, per dire cython.

Per inciso, i "vantaggi" che elenchi per Python non sono qualcosa che Go
non abbia. Tipo un sistema di templating e' presente perfino nella libreria
standard. Ci sono vari sistemi per fare web app, parecchio buoni e
vincenti. Che per inciso, spesso risolvono parecchi problemi che si hanno
facendo le stesse cose in Python (e.g., deploy).

Aggiungo che c'e' anche il rischio che per usare Go per scrivere un modulo
per Python, molte delle cose piu' interessanti di Go si possono usare solo
in modo molto limitato e raramente per dare la spina dorsale
dell'applicazione (il che e' ovvio, visto che si sta creando un modulo).
Che e' invece una cosa che sarebbe proprio interessante.

Visto e considerato che la situazione della gestione della concorrenza in
Python e' relativamente penosa e imbarazzante, semmai sarebbe molto piu'
interessante scrivere componenti limitati in Python all'interno di
un'applicazione in Go.
--
.
..: -enrico-
Carlos Catucci
2015-08-26 13:39:25 UTC
Permalink
Post by enrico franchi
A me sembra interessante che si possa fare, ma mi sembra piu' un proof of
concept che altro. Se il problema e' scrivere un'estensione a Python che
vada veloce, direi che ci sono gia' vari metodi. Avere anche Go e'
chiaramente meglio che non averlo, ma credo che sia inevitabilmente piu'
scomodo di qualcosa come, per dire cython.
Per inciso, i "vantaggi" che elenchi per Python non sono qualcosa che Go
non abbia. Tipo un sistema di templating e' presente perfino nella libreria
standard. Ci sono vari sistemi per fare web app, parecchio buoni e
vincenti. Che per inciso, spesso risolvono parecchi problemi che si hanno
facendo le stesse cose in Python (e.g., deploy).
Enrico il problema e' sempre di unita' di misura. Il progetto piu' piccolo
a cui lavori tu e di qualche "anno luce" piu' grande del piu' grande a cui
lavoro io. Per me impiegare tempo ad apprendere come fare in Go le cose che
faccio con Python e Django/Flask e' una "spesa" che non posso affrontare
ora. Pero' se mi trovo (come potrei se il progetto a cui sto lavorando vede
la luce) a dover fare cose che in Python non "vengono bene", esempio
gestire qualche migliaio di messaggi "conteporanei" provenienti da
altrettanti router sparsi qua e la, ecco che una routine Go, meglio se
wrappabile, mi puo' risolvere la cosa senza che io debba impazzire.
Post by enrico franchi
Aggiungo che c'e' anche il rischio che per usare Go per scrivere un modulo
per Python, molte delle cose piu' interessanti di Go si possono usare solo
in modo molto limitato e raramente per dare la spina dorsale
dell'applicazione (il che e' ovvio, visto che si sta creando un modulo).
Che e' invece una cosa che sarebbe proprio interessante.
A me servono moduli che fanno cose elementari ma bene. Non e' un problema
prestazionale puro, piu' di concorrenzialita' di dati in arrivo. Postgres
mi regge 10K scritture al secondo, non so se Djabngo pero' riesce a
maneggiarle. Ecco che Go potrebbe risolvermi il problema. Se avro',
speriamo, tempo, in futuro affrontero' anche altri aspetti di Go.
Post by enrico franchi
Visto e considerato che la situazione della gestione della concorrenza in
Python e' relativamente penosa e imbarazzante, semmai sarebbe molto piu'
interessante scrivere componenti limitati in Python all'interno di
un'applicazione in Go.
A me serve solo un piccolo caso di concorrenza, la gran parte della roba
sono webservice che rispondono a chiamate ajax e un poco di roba diciamo
"gestionale". Per i primi potrei anche farli con Go, ma poi perdo i
vantaggi dell'ORM di Django (o di SqlAlchemy) visto che i webservice
gerstiscono basi dati spesso sparse su diverse tabelle.

Carlos
--
EZLN ... Para Todos Todo ... Nada para nosotros
enrico franchi
2015-08-26 14:20:45 UTC
Permalink
Post by Carlos Catucci
Enrico il problema e' sempre di unita' di misura. Il progetto piu' piccolo
a cui lavori tu e di qualche "anno luce" piu' grande del piu' grande a cui
lavoro io.
Ma non e' questo il problema... spiego meglio.
Post by Carlos Catucci
Per me impiegare tempo ad apprendere come fare in Go le cose che faccio
con Python e Django/Flask e' una "spesa" che non posso affrontare ora.
E questo e' chiaro (in realta' lo e' per tutti).
Post by Carlos Catucci
Pero' se mi trovo (come potrei se il progetto a cui sto lavorando vede la
luce) a dover fare cose che in Python non "vengono bene", esempio gestire
qualche migliaio di messaggi "conteporanei" provenienti da altrettanti
router sparsi qua e la, ecco che una routine Go, meglio se wrappabile, mi
puo' risolvere la cosa senza che io debba impazzire.
E io quello che ti sto dicendo e' che a fare questo il "supermetodo"
ficcato nell'infrastruttura Python esistente non e' una buona idea.

Allora, parliamo della tua infrastruttura attuale. Hai un db in cui scrivi
e da cui leggi. Avrai una webapp che legge dal db per "vedere cose". Dopo
di che hai bisogno di un coso che riesca a ricevere molte scritture e le
metta nel db. Da quello che ho capito, la lettura non e' un problema
veramente critico (relativamente pochi operatori dovranno leggere i dati,
immagino tramite pagine web). Il problema e' l'ingestion dei dati.

Quindi lasciamo completamente perdere la webapp per leggere (che stara' in
Python e tanti saluti). Tu devi progettare un coso veloce che prende,
immagino delle gran POST (o PUT) e ficca dati corrispondenti nel DB. Ora,
cosa succede ad una put?

Avrai immagino un loadbalancer di qualche tipo (o reverse proxy che dir si
voglia) che prende una chiamata HTTP. Questa chiamata verra' mandata ad un
webserver che la deve processare. Il webserver dovra' capire che la deve
passare attraverso qualche trasporto alla webapp che la processera' (e.g.,
wsgi) -- questo tipicamente coinvolge anche copiare dei buffer dal
webserver al worker della webapp --, il tuo coso dietro poi prende la
richiesta, la smonta (che so, parsa del json), pesca i dati che servono e
li passa al driver del db che a sua volta scrive sul db. Verosimilmente
questa operazione e' bloccante. Il che vuole dire che se hai troppa
concorrenza finisci i worker e cominci a tirare dei 503. E perdi dati. Male.

La tua idea di "riscrivere il magic method in Go" probabilmente rende un
po' piu' veloce il processamento dei dati (ma in compenso hai eventualmente
il problema di convertire gli stessi dal formato pythonoso che ricevi in
input e che quando il tuo handler viene chiamato sono gia' stati macinati e
li passi al metodo in Go, che poi parlera' con il db. Ora si pone il
problema di come fare in modo asincrono la richiesta al db (questo e' il
pezzo piu' interessante). Hai diversi approcci... e scegliere quello giusto
(per come funziona Go) e' il punto chiave del successo.

In tutto questo dal punto di vista delle ops, non ho idea di cosa cavolo
succeda. Per esempio non ho idea come un worker django si senta quando gli
crei sotto dei thread sotto le chiappe (questo fa il runtime di Go). Non ho
idea di *quando* li crei. Per esempio, se venissero creati appena carichi
la libreria condivisa, che verosimilmente potrebbe accadere *prima* che i
worker vengano forkati, ti troveresti potenzialmente con un runtime rotto
(i thread non sono copiati su una fork). Non so se il runtime di Go
gestisce questa cosa quando la fork la fa Python "da fuori". Nota che
proprio il problema delle interazioni fra fork e posix non e' banale ed e'
uno dei motivi per cui in Go non hai una vera e propria fork (ma solo un
"subprocess") e in Python rischi di brutto quando fai fork + thread (con
risultati disastrosi garantiti se hai la pretesa di fare anche logging).

Quello che voglio dirti e' che vai a mettere su un sistema
significativamente complesso, in cui devi capire molto di piu' di diverse
parti in movimento, con alcuni pezzi specialmente immaturi (non credo che
ci siano molti sistemi in produzione che servono Go tramite una libreria
condivisa da Python). Secondo me e' una situazione in cui prima o poi
qualcosa si spacca e non e' chiaro perche'.

Se il tuo problema e' "devo gestire tante scritture concorrenti"... beh,
vai su una situazione Go pura.

Intanto... dimenticati un ORM (mi sembra di avere capito che hai problemi
di performance, e un use case relativamente semplice: input in tabelle ben
definite). Se proprio lo vuoi, ce lo hai anche in Go. Ma potrebbe finire
per essere un collo di bottiglia (in Python come in Go).

La webapp la puoi scrivere in Go puro. Ci sono parecchie librerie di alto
livello per fare sta roba: ti trovi con un binarietto che devi tenere
eseguito che ascolta sulla porta che vuoi e ti prende tutte le post del
mondo. Non devi copiare dati avanti e indietro dal webserver al worker (o
usare qualunque tecnica "smart" che i webserver usano oggi). Gestisci la
concorrenza come vuoi: tipicamente una goroutine per richiesta e tanti
saluti: il tuo modello e' sufficientemente semplice che anche una tecnica
del genere dovrebbe funzionare.

E' roba *semplice*. E' piu' semplice che imparare abbastanza Go da fare il
super-metodo e poi imparare come fare parlare Python e Go.
--
.
..: -enrico-
Davide Muzzarelli
2015-08-26 19:36:46 UTC
Permalink
Post by Carlos Catucci
A me serve solo un piccolo caso di concorrenza, la gran parte della roba
sono webservice che rispondono a chiamate ajax e un poco di roba diciamo
"gestionale". Per i primi potrei anche farli con Go, ma poi perdo i
vantaggi dell'ORM di Django (o di SqlAlchemy) visto che i webservice
gerstiscono basi dati spesso sparse su diverse tabelle.
Dubito che tu riesca a risolvere il problema in maniera efficace usando
Go come libreria.

IMO fai prima ad usare Python scrivendo SQL diretto per le poche query
che necessitano veramente di prestazioni.

Se devi distribuire il carico probabilmente è meglio usare RabbitMQ
invece che utilizzare i thread di Python o di Go, così puoi anche
sfruttare la potenza di altri server.

In questo modo hai buone prestazioni e niente di nuovo da dover studiare.

Davide Muzzarelli
Marco Ippolito
2015-08-26 15:45:40 UTC
Permalink
Post by enrico franchi
Visto e considerato che la situazione della gestione della concorrenza in
Python e' relativamente penosa e imbarazzante, semmai sarebbe molto piu'
interessante scrivere componenti limitati in Python all'interno di
un'applicazione in Go.
Praticamente quello che sto facendo io con Node.js e Python))))

PS: spero di aver rispettato tutte le regole della mailing list
Gian Mario Tagliaretti
2015-08-26 20:01:14 UTC
Permalink
Post by Marco Ippolito
PS: spero di aver rispettato tutte le regole della mailing list
No, non hai tenuto l'attribuzione della frase che hai quotato.

https://en.wikipedia.org/wiki/Posting_style#Attribution_lines

ciao
--
Gian Mario Tagliaretti
GNOME Foundation member
***@gnome.org
Gollum1
2015-09-01 15:20:07 UTC
Permalink
Post by Nicola Larosa
Post by Carlos Catucci
Ma un wrapper per codice Go da Python non lo hanno mai pensato?
Io non so se sarei capace di scriverlo, ma lo troverei utile.
La v.1.5 di Go, che esce il mese prossimo, è la prima che supporta la
scrittura di librerie dinamiche: prima era quasi impossibile.
Non so se qualcuno sta già scrivendo un wrapper Python, ma non credo
passerà molto tempo prima che ne spunti uno. :-)
Ma perché continuare ad imperversare su un vecchio thread, che non ha
attinenza reale con il nuovo? non basta il was:

CREATE UN THREAD NUOVO SE CAMBIATE ARGOMENTO...
porca puzzola... poi mi perdo le cose interessanti...

Byez
--
Gollum1 - http://www.gollumone.it
Tesssssoro, dov'é il mio tessssoro...
Simone Federici
2015-07-11 17:02:42 UTC
Permalink
Post by Carlos Catucci
Post by Davide Muzzarelli
Ogni gorutine (simile ai thread) occupa 4kb. In 350MB di RAM puoi gestire
circa 90.000 connessioni aperte >simultaneamente. Puoi usare tutte le CPU a
disposizione fin da subito senza scrivere codice aggiuntivo.
molto molto fico, lo compro :-)
--
Simone Federici
------------------------
Software Craftsman
XP, Agile, Scrum, Kanban
Quality, performance & security

Explicit is better than implicit.
Davide Muzzarelli
2015-07-11 19:38:26 UTC
Permalink
Post by Simone Federici
molto molto fico, lo compro :-)
LOL :D


Davide Muzzarelli
enrico franchi
2015-07-12 17:34:49 UTC
Permalink
Post by Carlos Catucci
Verdad, la gestione e' semplficata, ma la leggibilita' lo diventa solo
quando hai capito come funzionano. Il Try Except Finally Else di Python e'
immediato. Tranen forse Else ecco. Che comunque trovo comodissimo da avere.
Dici? Non so... statisticamente parecchia gente ci mette un bel po' di
tempo prima a capire cosa siano le eccezioni e ancora di piu' per usarle
come si deve. Poi certo, se hai capito le eccezioni in Python probabilmente
ti adatti facilmente alle eccezioni in Java o C++ (e viceversa), ma non e'
che sia un concetto "naturalmente semplice". E' solo un concetto che spesso
si ha gia'.

Per inciso, pensa a tutto il tempo che i niubbi spendono scrivendo *male*
il codice che usa le eccezioni (variando da: ricondurle appena possibile a
gestione con valori di ritorno -- oppure la variante: cercare di evitarle
facendo [male] LBYL; grosso modo ignorarle quando non dovrebbero; catturare
troppa roba e mascherare bachi logici con gestione dell'errore troppo
generica). Generalmente io trovo che capire il punto nel call stack in cui
e' ottimale gestire un'eccezione non e' affatto banale. Anche perche' ci
sono due aspetti distinti che sono riuniti nella variante castrata di
eccezioni che ha Python, che sono appunto gestire l'errore "essenzialmente
lato utente" e pulire lo stato dell'applicazione. E queste due cose sono
legate in modo indissolubile e spesso bisogna o usare contorsioni logiche
oppure accettare codice inutilmente inefficiente.

Ma un wrapper per codice Go da Python non lo hanno mai pensato? Io non so
Post by Carlos Catucci
se sariei capace di scriverlo, ma lo troverei utile.
Cosa intendi? Vuoi chiamare Go da Python o Python da Go? O cosa altro
avevi in mente?
--
.
..: -enrico-
Carlos Catucci
2015-07-12 17:42:20 UTC
Permalink
Post by enrico franchi
Cosa intendi? Vuoi chiamare Go da Python o Python da Go? O cosa altro
avevi in mente?
Chiamare Go da Python. Cosi' le parti critiche potrebbero essere gestite da
Go e le cose che faccio meglio in Python le faccio in Python appunto.

Carlos
--
EZLN ... Para Todos Todo ... Nada para nosotros
Davide Muzzarelli
2015-07-12 23:35:51 UTC
Permalink
Post by Carlos Catucci
Chiamare Go da Python. Cosi' le parti critiche potrebbero essere gestite
da Go e le cose che faccio meglio in Python le faccio in Python appunto.
Si perderebbero molte performance convertendo i dati da un ambiente
all'altro. Dubito che convenga farlo.

Puoi comunque mettere in piedi una queue con RabbitMQ, oppure in maniera
più leggera con Redis, e creare dei worker in Go.

Byez,
Davide Muzzarelli
Carlos Catucci
2015-07-13 05:40:26 UTC
Permalink
Post by Davide Muzzarelli
Si perderebbero molte performance convertendo i dati da un ambiente
all'altro. Dubito che convenga farlo.
Allora perhe' sio wrappano programmi C/C++?

Puoi comunque mettere in piedi una queue con RabbitMQ, oppure in maniera
Post by Davide Muzzarelli
più leggera con Redis, e creare dei worker in Go.
Interesante ma sono tecnologie di cui per ora non so nulla. Appena avro'
tempo (mai se non cambia qualcosa) ci guardo

Carlos
--
EZLN ... Para Todos Todo ... Nada para nosotros
enrico franchi
2015-07-13 15:49:08 UTC
Permalink
Post by Carlos Catucci
Chiamare Go da Python. Cosi' le parti critiche potrebbero essere gestite
da Go e le cose che faccio meglio in Python le faccio in Python appunto.
Mah, dipende cosa vuoi fare, davvero. Allora... in Go 1.5 sara' piuttosto
facile chiamare Go da C (e non solo C da Go), il che fa pensare che
chiamarlo da Python non sara' un gran sbattimento.
La questione e' l'opportunita': non ho ancora guardato la draft dell'1.5 in
questo dettaglio... ma in generale Go e' concepito come linguaggio per
sviluppare sistemi piuttosto che come linguaggio per implementare librerie
per altri sistemi. Molti dei punti di forza di Go non hanno facili map 1:1
in altri linguaggi e di conseguenza non mi e' chiaro quale sia il punto di
fare esattamente quello.

Io credo che quello che puoi facilmente fare e' invece separare a livello
di architettura invece che a livello di codice. E.g., hai un set di API
rest servite da Go e un layer sottile in Python che chiama le API. Poi,
detto fra noi... sta roba viene fatta meglio ammazzando suddetto layer e
facendo tutto con opportuno javascript.

Diciamo che il problema e' che non ho identificato molti problemi che
Python risolve meglio di Go, con alcune eccezioni, e se guardi la lista
delle eccezioni non e' che si presti molto a fare quello che vuoi fare:
* calcolo scientifico (a la notebook + pandas + roba sottostante): diciamo
prototipi di da data scientist
* gui apps

Il resto per me lo fa oggettivamente meglio Go. Hai un hit relativamente
piccolo in termini di produttivita' sul codice, piu' che compensato da
tutto quello che riguarda le operations (dal deploy in su). Per il resto...
--
.
..: -enrico-
Carlos Catucci
2015-07-13 17:24:41 UTC
Permalink
Post by enrico franchi
Io credo che quello che puoi facilmente fare e' invece separare a livello
di architettura invece che a livello di codice. E.g., hai un set di API
rest servite da Go e un layer sottile in Python che chiama le API. Poi,
detto fra noi... sta roba viene fatta meglio ammazzando suddetto layer e
facendo tutto con opportuno javascript.
Infatti none ra quello il motivo del wrapping. Per il progetto attuale le
cose pesanti sul piano concorrenzialita' ma piccole sul piano di cosa fanno
(esempio registrare che l'utente con il mac address xxxx si e' collegato
sul router con uuid yyyy sul db PG dove ho una tabella a 4 (oltre id) campi
di cui uno e' automatico (timestamp registrazione record aka inizioo
connessione) e un'altro lo devo updatare (da altra chiamata) quando la
connessione termina) le valutavo in Go, mentre per cose piu' impegnative
sul fronte di carico ma complesse come elaborazioni, Python.
Il wrap era riferito a casi come quelli in cui si wrappa tipo wxwidgets


Carlos
--
EZLN ... Para Todos Todo ... Nada para nosotros
Simone Federici
2015-07-11 17:09:20 UTC
Permalink
Post by Davide Muzzarelli
E' come in finally, con la differenza che puoi metterli nel punto dove
preferisci e non devi creare dei livelli d'identazione quando ne devi
creare più di uno.
ok capito
Post by Davide Muzzarelli
In sostanza sono più comodi e semplici da utilizzare rispetto ai finally.
per te, che lo scrivi ma il codice Ú letto in media 50 volte in piú a
quanto viene scritto.

e avere un try finally che puoi mettere a caso nel codice non mi sembra una
buona pratica

ps: io sono più x i context manager che supportano un unico punto di
indentazione anche usati multipli
--
Simone Federici
------------------------
Software Craftsman
XP, Agile, Scrum, Kanban
Quality, performance & security

Explicit is better than implicit.
Davide Muzzarelli
2015-07-11 19:42:04 UTC
Permalink
per te, che lo scrivi ma il codice è letto in media 50 volte in piú a
quanto viene scritto.
Il fatto è che scrivendo metti il defer nel posto migliore a livello
logico proprio dove te lo aspetteresti. Le funzioni in Go tendono ad
essere piuttosto corte e bisogna tenere conto anche di questo.
e avere un try finally che puoi mettere a caso nel codice non mi sembra
una buona pratica
La maniera più naturale è mettere il defer nel posto giusto, per
scriverlo in un posto a caso bisogna proprio farlo apposta.
ps: io sono più x i context manager che supportano un unico punto di
indentazione anche usati multipli
Concordo che context manager sono una gran cosa! :)

Byez,
Davide Muzzarelli
Carlos Catucci
2015-07-12 07:10:58 UTC
Permalink
Un interessante quesito che e' alla fine e' venuto fuori dalla lista CPYG-BO
Che voi sappiate qualcuno sta usando Go per scrivere software di sistema
"famosi" (o noti, con buone prospettive) ?

Qualcuno ha risposte? La domanda scaturisce dal discorso C vs Go, con il
primo usatissimo ancora per scrivere OS o sistemi embedded.

Carlos
--
EZLN ... Para Todos Todo ... Nada para nosotros
Davide Muzzarelli
2015-07-12 12:30:51 UTC
Permalink
Che voi sappiate qualcuno sta usando Go per scrivere software di
sistema "famosi" (o noti, con buone prospettive) ?
Qualcuno ha risposte? La domanda scaturisce dal discorso C vs Go, con il
primo usatissimo ancora per scrivere OS o sistemi embedded.
Go non è adatto a scrivere sistemi operativi.

Ecco qui di seguito una lista non ordinata. Alcune sono molto famose nei
loro settori specifici quindi è probabile che quei ragazzi non ne
abbiano mai sentito parlare.

- Baidu: il famoso motore di ricerca cinese
- Qihoo 360: ~1.1 miliardi di utenti in Cina
- Docker, Etcd, Fleet e altri sistemi correlati
- Database come Bolt, InfluxDB, RebornDB ecc.
- Canonical: JuJu
- CloudFlare: Railgun
- SoundCloud
- Dropbox: le parti critiche della loro infrastruttura, continuano ad
usare Python per tutto il resto altrimenti Guido si arrabbia :D
- Google: download server, alcuni sistemi di gestione del cloud e chissà
quali altri progetti segretissimi ;)
- Youtube: Vitess
- BBC World News: vari servizi come crawler, web services e backend per
i giochi
- Heroku: Doozer e altri loro sistemi sia interni che open source
- Iron.io
- Splice
- Nokia: si sa solo di tool interno per testare l'hardware
- Pivotal: CloudFoundry
- Apcera: il 95% dei loro sorgenti è scritto in Go
- Twitch: 45 milioni di giocatori al mese
- StatHat
- Square (POS virtuale)
- Cloud66
- Rackspace: Airbrake
- 99designs
- Digital Ocean
- Disqus
- Tumblr
- DNSSimple
- dotCloud
- SendGrid: hanno migrato dal Perl
- GitHub
- Zynga
- gov.uk
- Mozilla: alcuni tool e servizi
- New York Times: servizi di backend e API web
- Percona: agente per monitorare i database in cloud
- Bitbucker: in sperimentazione
- VividCortex

La maggioranza di questi sono migrati da Python e Ruby, altri hanno
evitato di dover riscrivere grosse parti in C grazie a Go.

Byez,
Davide Muzzarelli
Massimiliano Pippi
2015-07-12 18:16:27 UTC
Permalink
Post by Davide Muzzarelli
Ecco qui di seguito una lista non ordinata.
Mi permetto di aggiungere uno dei progetti con la codebase Go più estesa in
circolazione:

https://github.com/golang/go

Ciao
M.
enrico franchi
2015-07-12 17:26:44 UTC
Permalink
Post by Davide Muzzarelli
Ogni gorutine (simile ai thread) occupa 4kb. In 350MB di RAM puoi gestire
circa 90.000 connessioni aperte simultaneamente.
Come dire... occhio pero'. Tutte le volte nella storia dell'informatica che
qualcuno ha convinto qualcun altro che qualcosa fosse essenzialmente
gratuito, ci sono stati tanti ingegneri a correrre la notte e tanti sistemi
riscritti.

Tipo... 90.000 connessioni aperte simultaneamente? Ma dai, diciamo proprio
di no. Non e' che non *puoi* farlo. E' che e' proprio una cattiva idea
farlo *a meno che non devi proprio farlo*. Tipicamente tutte le volte che
assumi che qualcosa sia gratuito e illimitato, prima o poi qualcuno ti
fara' scoprire che non e' cosi' (corollario: di solito questa cosa accade
in un'altra time-zone, quando uno avrebbe preferito dormire invece di
scoprire nuove cose).

Vuoi tenere 90K connessioni aperte? Metti conto che: TCP ha bisogno di
bookeeping nel kernel. 90K descrittori sono proprio tanti. A questo punto
devi tenere traccia di quali connessioni sono buone e quali non sono buone
(cosa non banale... TCP Keepalive offre qualcosa di diverso e farlo a mano
e' noioso... HTTP keepalive e' una cosa diversa ancora, ma e' piuttosto
delicata e spesso si spacca... in pratica non e' un caso come funzionano i
vari pool di connessioni http -- che per dire, Go stesso offre senza dirlo
in modo troppo esplicito). In generale e' davvero molto piu' semplice usare
logiche di pool rispetto che fare 90.000 goroutine. Tipicamente se uno fa
ste cose a cuor leggero la prima cosa che scopre e' che ha un problema con
il garbage collector, per dire.
Post by Davide Muzzarelli
Puoi usare tutte le CPU a disposizione fin da subito senza scrivere
codice aggiuntivo.


Ora... il codice aggiuntivo e' piccolo, ma di per se Go 1.4 se non gli dici
altrimenti usa *una* CPU.
--
.
..: -enrico-
Davide Muzzarelli
2015-07-12 23:33:01 UTC
Permalink
Post by enrico franchi
Tipo... 90.000 connessioni aperte simultaneamente? Ma dai, diciamo
proprio di no. Non e' che non *puoi* farlo. E' che e' proprio una
cattiva idea farlo *a meno che non devi proprio farlo*. Tipicamente
tutte le volte che assumi che qualcosa sia gratuito e illimitato, prima
o poi qualcuno ti fara' scoprire che non e' cosi' (corollario: di solito
questa cosa accade in un'altra time-zone, quando uno avrebbe preferito
dormire invece di scoprire nuove cose).
Non c'è alcuna spiegazione su come deve funzionare il sistema di Carlos
per cui sono stato molto generico. Ho giusto scritto cosa Go può
raggiungere senza troppo sbattimento, chiaramente a scopo di paragone
con Python.

Dipende da quale è il suo bisogno, ha parlato di alcune decine di
migliaia di router da gestire. Se è un progetto serio avrà un budget e
l'aiuto di colleghi, eventualmente un sistemista. Ovvio che si può fare
distribuendo il carico su più server, che è probabilmente la soluzione
migliore sotto diversi punti di vista, non c'è bisogno di correre di notte.

Questo tizio ha raggiunto 600.000 connessioni per processo con 16GB di
RAM e il vecchio Go 1.0.3, che è molto più di 90.000 connessioni. Il GC
da allora è migliorato sensibilmente:
https://groups.google.com/forum/#!searchin/golang-nuts/Garbage$20collecting/golang-nuts/S9goEGuoMRM/FZyd2M6uiVMJ
Post by enrico franchi
In generale e'
davvero molto piu' semplice usare logiche di pool rispetto che fare
90.000 goroutine.
Sono d'accordo. A Qihoo 360 hanno comunque raggiunto 1 milione di
connessioni/server prima di passare ai pool, sempre con Go 1.0.3.

Dubito che Carlos debba creare un sistemone del genere, probabilmente
gli basta molto ma molto meno.
Post by enrico franchi
Tipicamente se uno fa ste cose a cuor leggero la prima
cosa che scopre e' che ha un problema con il garbage collector, per dire.
Basta fare una spike solution per vedere quali numeri ottiene. Python mi
pare meno adatto per queste cose, se lo deve fare con quello
probabilmente si trova con limiti ancora maggiori.
Post by enrico franchi
Post by Davide Muzzarelli
Puoi usare tutte le CPU a disposizione fin da subito senza
scrivere codice aggiuntivo.
Ora... il codice aggiuntivo e' piccolo, ma di per se Go 1.4 se non gli
dici altrimenti usa *una* CPU.
Hai ragione, è una riga di codice all'inizio del programma per dire
quante CPU usare. Quello che intendo è che non deve modificare come
funziona il proprio codice, tipo per usare il multiprocessing in Python.

Byez,
Davide Muzzarelli
Enrico Bianchi
2015-07-11 13:50:18 UTC
Permalink
Post by Davide Muzzarelli
- Piatto è meglio che annidato
- Sparso è meglio che denso
Per capire, cosa intendi?

Enrico
Davide Muzzarelli
2015-07-11 19:37:37 UTC
Permalink
Post by Enrico Bianchi
Per capire, cosa intendi?
Una traduzione sommaria e imprecisa dello zen di Python, che avrei
potuto fare meglio :p

I "metodi" in Go sono alla stessa indentazione delle "classi", in
effetti si tratta di funzioni collegate a strutture.

Lo stile idiomatico di Go incoraggia l'uso di funzioni piccole, moduli
altrettanto piccoli molto specializzati e aggregazione. Le interfacce,
come sono pensate in Go, aiutano molto il riuso di codice in grandi
progetti.

Alla fine ci si ritrova in maniera naturale ad avere pochi livelli
d'indentazione, funzioni con pochi argomenti e moduli con poche strutture.

Davide Muzzarelli
Continue reading on narkive:
Loading...