Che voi sappiate Go e Rust soffrono anche loro il problema di tante dipendenze? La mia unica esperienza con Rust è su Linux quando mi capita di compilare qualche applicativo (tipo greetd), vedo che Rust le dipendenze le scarica e non mi sembrano poche. Go non saprei proprio.
Beh almeno le gestiscono, a differenza di altri linguaggi. C++ è un grande linguaggio, ma soffre proprio della mancanza di una soluzione per gestire le dipendenze.
Questo per dire, che gli altri due, che invece offrono una soluzione e molto buona direi, sono una spanna sopra gli altri.
Poi è naturale, per un programma medio-grande, avere centinaia di dipendenze. Tanto per dire, che senso ha costruirsi un parser JSON se puoi usare Serde ( Rust )? E lo stesso discorso vale per Go.
I crate ( quelli più grossi e importanti almeno ) sono il naturale completamento di Rust. E il team di sviluppo mantiene volutamente alcune funzionalità fuori dalla standard library.
Ma a chi importa? Alla fine il codice o lo scrivi tu o usi quello scritto da qualcun'altro. C'è poco da fare. E se è contenuto nella standard library, t'ingrossa le dimensioni della prima installazione. Insomma, non si sfugge!
Riguardo il discorso su Javascript. Capisco che abbia preso piede e ormai ce lo dobbiamo sorbire. Ma lo stesso inventore ( Brendan Eich ) lo definì un "hack realizzato in un fine settimana". E infatti la comunità si è smazzata per migliorarlo. Esistono una dozzina di alternative ( tra cui il famoso Typescript e il neo-famoso Dart, anche se quest'ultimo è diventato famoso per lo sviluppo mobile ).
Soffre del limite di tutti i linguaggi della sua classe, ovvero l'essere single thread. In un mondo con 8-16 core su pc e workstation ( figuriamoci sui server ), mi pare un grosso limite.
E' il tipico linguaggio "fat", che arriva alla folle soluzione di wrappare pure i tipi integrali come int, bool, ecc... in oggetti ( come fa Python ). E' un miracolo che V8 performi in quel modo ( unwrappa i tipi integrali, tra le altre cose )!!
Per cui, Nodejs è una buona soluzione lato server, perchè in genere si tratta di servire file. Il grosso dell'attività è centrata sull'I/O. Ma per quei casi in cui bisogna fare tanti calcoli, non è proprio una brillante idea usarlo.
E vale, in parte, pure per Go, che pasticcia coi numeri e le prestazioni vanno giù. Però Go c'ha dalla sua un'implementazione del meccanismo CSP ( per la concorrenza ) favoloso. Realizzare in poco tempo e con pochi bug un programma che spawna migliaia di goroutine, che comunicano senza race condition grazie ai canali...non ha prezzo! E non lo paghi nemmeno in termini di consumi stellari di memoria. Cosa rara per i linguaggi basati su garbage collector.
Rust è un discorso a parte, perchè introduce parecchie innovazioni ( molte prese dal mondo della programmazione funzionale ). Aldilà della difficoltà di apprendimento, rimane il fatto che spezza le gambe ad intere classi di bug.
Possiamo far finta di niente? Se io dovessi, oggi, progettare un dispositivo edge per l'IoT, potrei scegliere tra C++ e Rust. E, a meno di una seria e mostruosa mancanza di librerie lato Rust, non ritengo saggio scegliere C++, rinunciando ai vantaggi di Rust. E l'elemento poco notato ma importantissimo, è la disciplina che la comunità di è data. Cioè, da un lato il modello di programmazione del linguaggio elimina certe classi di bug. Dall'altro, pure i crate esterni seguono le best practises del linguaggio, tra cui quella di eliminare qualsiasi tipo di comportamento non definito. Per esempio, non è una cosa che può gestire il borrow checker, ma il tipo String controlla che il suo buffer contenga solo sequenze UTF-8 valide. Perchè? Perchè altrimenti quel contenuto potrebbe produrre comportamenti non definiti ( i famigerati undefined behaviour del C e figli ).
Oppure, esite il tipo OsStr, stringa fatta per contenere i nomi dei file. Uh!?! Embè, Unix ( e non solo ) ha il brutto vizio di accettare qualsiasi sequenza Unicode come nome dei file, anche quelle che contengono simboli che riservati o che non rappresentano nessun carattere. Usare direttamente String per simili oggetti, implicherebbe avere delle stringhe contenenti caratteri non validi, violando quella best practice di sopra.
Altra cosa sono le differenze tra le piattaforme. Che fa una funzione/metodo che setta i permessi su un file, sotto Windows? Niente. Windows non supporta i permessi Unix. Go, per esempio, te la fa eseguire e, di nascosto, non fa niente. COMPORTAMENTO NON DEFINITO!!! Male!!!
A Rust non piace nascondere la polvere sotto il tappeto. E imho, è meglio, per il programmatore, se la polvere è ben visibile in fase di progettazione e compilazione. Cioè Rust è tutto questo. Mica pizza e fichi!
Ma lo stesso discorso si può fare per i web services. Non è che siano meno importanti, per cui possiamo lasciarli agli hacker.
Imho la situazione è questa: Go ( sost: Java/Kotlin e C# ), Python, Rust ( sost: C/C++ ), Javascript/Typescript, Dart.
Go lo metto sullo stesso piano di Java, Kotlin e tutta la roba che gira intorno a JVM e C#/CLR. A parte la quantità di librerie, che ovviamente pende a favore di Java e C#, ma a Go non manca niente. Anzi, sulla concorrenza se la cava molto meglio.
Python è il linguaggio della prototipazione e del deep learning. E se non si ha a che fare con machine learning, data science in generale, big data e compagnia, non è sicuramente obbligatorio conoscerlo.
Rust è imho fondamentale per la sicurezza. E sta sullo stesso piano di C e C++. Ma è agli esordi e c'è tempo per studiarlo.
Javascript e fratelli/cugini sono purtroppo lo standard de facto in certi ambiti e hanno dalla loro legioni di programmatori. Puoi ovviamente restare fuori dal giro e puntare a lavori di "più alto livello". C'è gente che stracampa realizzando software embedded in C++ ( e talvolta in C ). E non toccherebbe Javascript nemmeno con un bastone.
E c'è Dart, il linguaggio del mobile cross-platform. Visto il boom di Flutter, far finta che non esista è sciocco. Voglio dire, Flutter è quasi arrivato ai livelli di popolarità di React Native ( che spadroneggia in ambito cross-platform ) e l'ha fatto in meno di 5 anni. E poi il team ha lavorato tantissimo alle prestazioni, tant'è che Dart si comporta molto bene pure su carichi cpu-bound e, in generale, sta sempre sopra Nodejs/V8.
