[Python] Che ne dite di RUST?

Gio 28 Maggio 2015 12:20:29 CEST

2015-05-27 13:45 GMT+01:00 Carlos Catucci <carlos.catucci a gmail.com>:

>
> On 27 May 2015 at 14:26, Marco De Paoli <depaolim a gmail.com> wrote:
>
>> http://lucumr.pocoo.org/2015/5/27/rust-for-pythonistas/
>
>
> Me lo leggo bene appena ho un attimo, ma da una passata veloce devo dire
> che tra i C like Rust mi sembra il meno lontano da Python
>

A me sembra che mettere Rust fra i "C like" e' gia' uno stretch forte. Nel
senso che si, la sintassi ha preso alcune cose da C [in realta', passando
molto piu' da C++ che dal "plain" C] (ma tutto sommato ne ha prese
altrettante da ML e famiglia).

Per il resto, mi sembra parecchio lontano da Python sotto tantissimi punti
di vista. Prendiamo alcuni assi:

1. Tipizzazione statica vs. dinamica: Python e' interamente sul side della
tipizzazione dinamica. La tipizzazione statica non solo non e' presente, ma
anche le features che ci si avvicinano sono esplicitamente risolte a
runtime e viene suggerito di non usarle per fare typing "static-like".
2. Binding dinamico vs. statico: Python e' completamente dinamico. Java
pure. Go in generale usa il binding dinamico (quando usi le interfacce --
ovvero quando astrai) e usa il binding statico solo quando non ha senso
altrimenti; C++ usa il binding statico di default, quello dinamico quando
richiesto (virtual); Rust usa il binding statico tutte le volte che e'
possibile ed e' una best practice. Supporta anche binding dinamico (grosso
modo negli stessi casi in cui lo hai in Go).
3. Il modello ad oggetti di Rust e' marcatamente diverso da quello dei
classici linguaggi imperativi OOP (quali Java, Python e C++). I traits a
prima vista assomigliano a delle base-classes/interfacce/whatever, ma le
differenze sono profonde. Davvero, bisogna pensarli in termini di
type-classes alla Haskell o moduli alla ML.
4. Python cerca di tenere le cose semplici e di astrarre i dettagli di
basso livello. Rust nasce con l'idea di darti controllo esplicito di
*tutti* i dettagli di basso livello. Se non vuoi farlo, quasi non ha senso
usare Rust.
5. Python ha un runtime estremamente ricco: talmente ricco che per
specifica impedisce ottimizzazioni mediamente ragionevoli. Rust nasce con
l'idea di *non* avere in pratica un runtime (ovvero, il runtime e'
completamente minimale e praticamente inesistente)

Se proprio devo esprimermi, fra i "C like" trovo che Go sia quello piu'
filosoficamente vicino a Python. Tende ad astrarre i dettagli
apparentemente irrilevanti e il sistema (in un caso la VM, nell'altro il
compilatore+runtime) fa la cosa migliore. Entrambi hanno il problema che
per fare certe cose, quando si ha bisogno di piu' controllo, bisogna in
qualche modo uscire dal modello (FFI/cython e compagnia in Python, low
level API/C extension in Go -- con poi tutti i problemi che ne derivano).
Rust invece e' relativamente piu' vicino a C++/OCaml: linguaggio complesso
per permetterti il massimo controllo su qualunque cosa, controllo che non
puoi facilmente ignorare: in alcuni casi Rust ti viene incontro piu' di C++
perche' di da un modello piu' facile con cui ragionare, ma la filosofia e'
molto piu' quella.

L'altra differenza e' che sia in Python che in Go (anzi, piu' in Go che in
Python) dopo poche settimane che ci si lavora si riesce a leggere e capire
piu' o meno tutto il codice che gira la fuori. Se non lo si capisce, e'
perche' mancano fondamenti sul dominio specifico, ma non c'e' ambiguita' o
magia del linguaggio che maschera tutto. In questo, Go e' perfino piu'
semplice di Python. Ci sono features elementari di Python che molti
programmatori non usano e non conoscono (o non sanno usare): metaclassi,
descriptor protocol, generatori per fare coroutine, per alcuni perfino
decoratori... in Go non ci sono features "complicate": ti danno tutti i
mattoncini che sono semplici. Poi magari il novizio non sa come comporli
nel modo giusto, ma quando li vede composti e' abbastanza immediato capire
cosa fanno e perche'.

Altri linguaggi (C++, OCaml, Haskell e ci metterei dentro anche Rust) hanno
bisogno di una comprensione molto piu' approfondita per poter coprire la
stessa quantita' di codice. Insomma... io Haskell lo guardo e ci
giochicchio da una decina di anni, ma regolarmente mi capita di leggere
codice scritto dai "pro" che non mi e' immediatamente chiaro e che devo
davvero smontare pezzo pezzo prima di capire come e perche' funziona.

> Cioe' poniamo che insegno a programmare in Python a qualcuno, cosa che
> aiuta il novello operator a fare analisi senza dover incorrere in mal di
> testa epici per trasgformare il metacodice in qualcosa di intellegibile dal
> compilatore. Se dopo deve passare ad un linguaggio C like, direi che con
> rust il passaggio sia meno doloroso rispetto a C++ o C#, per citarne due
> (quella roba di plastlina che si attacca ovunque e ha il nome di un ottimo
> caffe' manco la considero).
>

Non sono d'accordo. Secondo me suddetto novizio non saprebbe da che parte
prendere Rust. Quasi tutto il linguaggio e' creato per potere risolvere in
modo efficiente problemi che il novizio non ha nemmeno idea che esistono.
Tipicamente molte delle scelte di Rust si capiscono solo se uno ha
un'esperienza notevole in sistemi, programmazione di basso livello,
architetture di computer etc etc etc. Altrimenti e' davvero pura e semplice
magia.

Viceversa, Java e' parecchio semplice da capire: e' sufficiente avere
compreso per bene il modello ad oggetti. Se non si sa scrivere ad oggetti,
e' completamente impossibile scrivere del Java decente. Se si sa scrivere
ad oggetti, il Java che esce e' grosso modo sensato. La libreria standard
e' ricca e ben documentata e ci sono librerie di largo uso che semplificano
gli spigoli rimanenti. Non ho esperienza su C#, ma mi aspetto che grosso
modo siamo li sotto molti punti di vista. C++ e' una bestia completamente
diversa da entrambi.

 L'impressione che mi sono fatto e' che Rust e' un C++ fatto con piu'
senso, se proprio vogliamo forzare un paragone, uscendo dalla cattiva
implementazione del modello ad oggetti di C++ e importando quanto possibile
dal mondo funzionale, tanto che alla fine Rust non si "sente" veramente
come un linguaggio ad oggetti. Certo, e' molto agile per un linguaggio con
quel livello di dettaglio sulle operazioni di basso livello, ma siamo li.

Viceversa, Go e' esattamente a meta' strada fra C e Python: puoi vederlo
come un C svecchiato, ma puoi anche vederlo come un Python ottimizzato.

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