Cosa pensano generalmente gli ingegneri del software del linguaggio di programmazione Kotlin?

Kotlin non è rivoluzionario (con la possibile eccezione del suo null-handling) ma sembra un'amalgama molto attenta di alcune delle migliori caratteristiche di altri linguaggi. Il suo approccio è molto pragmatico ed enfatizza l'interoperabilità con Java e la mancanza di sorprese.

Sintatticamente assomiglia molto a Scala, ma non ha le capacità di pattern matching più avanzate (ancora?Come Scala è staticamente tipizzato, permette l'overloading degli operatori, enfatizza l'immutabilità e fornisce un supporto di prima classe per i tipi di valore immutabili, è buono per scrivere DSL staticamente compilati e ha un sistema di tipi molto robusto.

Alcune decisioni peccano di pragmatismo e interoperabilità. Per esempio, laddove Scala fornisce la propria libreria di collezioni che funziona eccezionalmente bene e ha un'immutabilità predefinita, ma richiede l'uso di funzioni di conversione o implicazioni ogni volta che si vuole interagire con le API Java, Kotlin's collection API avvolge le normali collezioni Java, fornendo una facciata immutabile ma permettendo un'interoperabilità Java trasparente. Questo potrebbe piacervi o no. A me sì.

Kotlin inoltre non ha implicazioni, che trovo comode ed eleganti in Scala, ma non migliorano la leggibilità o la comprensibilità del codice. Le funzioni di estensione con scoped di Kotlin soddisfano alcuni usi delle implicazioni.

Le funzioni di estensione si sentono come la parte buona della metaprogrammazione di Groovy senza alcun dolore considerevole. Le funzioni di estensione sono compilate staticamente e distribuite. Sono strettamente limitate dove il patching delle metaclassi ha la tendenza a fuoriuscire dal contesto in cui è necessario con risultati sorprendenti.

Confrontando Kotlin con Java le cose principali che trovo migliorate includono:

• Eccellente inferenza dei tipi che rimuove un sacco di disordine e ridondanza dal codice.
• Tipo sensibile al flusso, il che significa che non c'è quasi mai bisogno di fare il cast.
• Tipi di valore immutabili di prima classe. Doloroso e noioso in Java a meno che non si usi l'annotazione @Value di Lombok's.
• Immutabilità di default per le collezioni.
• Interpolazione delle stringhe.

L'interpolazione delle stringhe evita di creare un nuovo tipo di stringa come Groovy's GString, il che significa che non ci sono strani inconvenienti come una GString che finisce come chiave della mappa che poi non si può'recuperare usando una String.

Poi c'è la più grande innovazione di Kotlin (almeno credo che sia un'innovazione - non ho familiarità con un altro linguaggio oltre a Ceylon che ce l'abbia) - la sicurezza dei null. Kotlin tratta i tipi annullabili come i tipi di opzione, ma senza l'overhead del wrapping e unwrapping. Questo evita così tanti problemi ed è completamente compatibile all'indietro con le API di Java, così non si ha nessuno dei dibattiti "dovremmo o non dovremmo adottare Optional" che si fanno con Java 8.

Anche se sei un purista questo può sembrare sbagliato ma è pratico come l'inferno. Lo preferisco di gran lunga all'uso dei tipi di opzione.

In generale non posso pensare ad un altro linguaggio JVM che preferirei usare. Java 8 è un miglioramento significativo rispetto alle versioni precedenti e insieme a Lombok è tollerabile, ma ha ancora una serie di cose che mi frustrano. Mi piace Scala, ma non mi piace tutto di esso. Scala è un linguaggio così grande che le idee di due persone su ciò che conta come idiomatico possono essere totalmente diverse. Se potessi scegliere un linguaggio JVM per lavorare giorno per giorno in questo momento sarebbe Kotlin.