Scala è pronta per la prima serata? [chiuso]

Ora che ho fatto alcune cose insignificanti con Scala (che adoro per il "ciao mondo" e le applicazioni artificiose!), Mi sono lasciato chiedere ... parte sulla maturità degli strumenti per supportare lo sviluppo e parte sull'applicabilità generale. I set di strumenti sono pronti? Scala è adatto all'uso su applicazioni aziendali / aziendali? Lo "useresti" su un progetto non banale?

Alcune delle mie preoccupazioni (probabilmente infondate) sarebbero:

• l'IDE e i set di strumenti sono ricchi quanto quello che dobbiamo sviluppare applicazioni .net e java (eclipse per Scala sembra limitato rispetto a eclipse per java)?
• i set di strumenti build / CI / testing sono in grado di gestire efficacemente Scala?
• quanto è gestibile il codice conciso che può essere (incoraggiato?) scritto nella lingua?
• è possibile trovare sviluppatori con esperienza Scala?
• c'è abbastanza massa critica per ottenere aiuto attraverso riferimenti online e libri che sono più che "introduzione" alla lingua?

Quindi, in sostanza: l'ecosistema è abbastanza maturo per essere utilizzato ora, o meglio aspettare in attesa di vedere come si evolve?

EDIT: diciamo che "non banale" è un progetto di sviluppatori pluriennale, multi-release, 10-20.

Mentre è vero che Scala è stato utilizzato in natura presso il Guardian e su Twitter, c'è una preoccupazione fondamentale.

Gran parte della popolarità di Java deriva dal fatto che è relativamente facile da leggere e mantenere. Scala ha qui un problema in quanto può essere scritto in molti stili diversi. Lo stile OO vs lo stile funzionale è la divisione ovvia qui, ma diventa più complicato quando parli dei 3 livelli di Scala .

Devi assicurarti che il tuo team e tutti i potenziali nuovi assunti possano seguire lo stesso stile e che lo stile sia abbastanza semplice da poter effettivamente assumere sviluppatori che possano essere efficaci (non tutti possono assumere il 2% superiore) .

Anche il supporto degli utensili non è ancora del tutto presente, sebbene mi aspetto che questo divario venga colmato abbastanza rapidamente. Puoi anche ottenere supporto per l'intero stack Scala dalla folla TypeSafe . Penso che Scala riuscirà a ritagliarsi la sua nicchia, ma fino a quando i livelli non saranno effettivamente integrati nel linguaggio / compilatore / qualunque cosa, vedrò un mal di testa di manutenzione che si abbatte sui team dopo i primi 1-2 anni di entusiasmante produttività.

Vedi questa risposta correlata per maggiori dettagli.

Scala è attualmente utilizzato da Twitter e da The Gaurdian, quindi è sicuramente pronto per applicazioni non banali.

I programmatori di Scala saranno molto motivati ​​e probabilmente molto bravi. Scegliere una nuova lingua è un ottimo modo per attirare talenti.

Naturalmente, i programmatori di Scala spesso non avranno esperienza professionale di Scala, e potrebbero esserci alcune varietà nei modi di dire che usano. Alcuni possono lottare per la purezza simile a Haskell, mentre altri possono vederlo come Java con chiusure. Quindi probabilmente ci vorrà del tempo per sviluppare standard e convenzioni di codifica coerenti.

Molti strumenti Java funzioneranno bene, anche se IntelliJ Idea probabilmente varrà l'investimento su Eclipse.

Nel complesso, potrebbe essere una buona scelta se si ha il controllo sul progetto. Se questo fa parte di una grande compagnia assicurativa, potresti incorrere in problemi se ci sono linee guida sull'architettura come: "Tutti i progetti devono essere realizzati da Maven e distribuiti in WebSphere". (Non ho motivo di pensare che questa particolare regola sarebbe un problema, ma una proliferazione di tali regole potrebbe farti inciampare ad un certo punto.)

La mia impressione è che gran parte dell'ecosistema che viene fornito con linguaggi "convenzionali" (come Java) è inteso a compensare la loro goffaggine.

La domanda non è: quanti strumenti ci sono per una determinata lingua (Scala), ma se gli strumenti esistenti per quella lingua sono migliori degli strumenti esistenti per la lingua di riferimento (Java). Poiché 100 strumenti mediocri non ti daranno, ciò che un buon strumento può darti. E una cosa da non dimenticare è che il linguaggio stesso fa parte di quegli strumenti.

La dichiaratività di una lingua

• è inversamente proporzionale alla quantità e alla gravità dei bug che produci con esso, motivo per cui Java è così bravo a produrre bug e hai bisogno di molti strumenti per evitarli e tracciarli
• è proporzionale alla tua produttività, motivo per cui Java è così estremamente dettagliato e hai bisogno di molti generatori di codice e strumenti simili

Ad esempio, una volta ho letto un orribile post sul blog di un ragazzo di Ruby, che sosteneva che la digitazione statica fosse inutile, perché i tuoi test copriranno la sicurezza dei tipi. Questo chiaramente proveniva da qualcuno, che non aveva ancora lavorato con un sistema di tipo statico espressivo. Supponendo che io possa rappresentare tutte le relazioni di tipo in una semantica linguistica e non c'è molto lavoro da fare (e non lo è, poiché la maggior parte delle lingue moderne supporta l'inferenza di tipo), ottengo tutto questo gratuitamente.

Per far avanzare un pensiero un po 'più avanti: i test unitari assicurano che un'unità agisca come specificato, o per riformularla, i test unitari sono specifiche eseguibili. Tuttavia, attraverso la programmazione dichiarativa, le unità stesse sono specifiche eseguibili. Ancora una volta, ottieni qualcosa gratis.

Quello che sto cercando di dire è che non dovresti sottovalutare ciò che le funzionalità linguistiche possono fare per te. E se non li provi davvero sul campo, non capirai mai.

Quindi, per tornare alla domanda originale: gli strumenti esistenti per Scala sono migliori di quelli per Java? Difficile da dire. Dipende da cosa vuoi fare. Penso che saremmo tutti d'accordo sul fatto che la lingua sia significativamente migliore, ora la domanda è: quanto è buono un ecosistema che troverai nella tua area di business.
Per il web, Lift è davvero una valida opzione. Non so desktop o mobile.

diciamo che "non banale" è un progetto di sviluppatori pluriennale, multi-release, 10-20.

Sono molti rischi. Le ricompense dovrebbero valerne la pena. Nel mondo delle app aziendali e dei progetti di medie e grandi dimensioni, l'assunzione di rischi è generalmente limitata. O meglio, c'è già abbastanza rischio da affrontare ... La prevedibilità è più importante.

Dubito che l'adozione funzionerà in questo modo.

È più probabile che inizi come una manciata di persone che lavorano su una parte in cui è contenuto il rischio come POC, componenti non critici, test o parti in cui il problema sembra essere affrontato molto meglio da Scala rispetto alle alternative (forse se qualcosa comporta attore per esempio) ... Quindi man mano che gli strumenti maturano, la comunità cresce, il know-how cresce nell'azienda, quindi potrebbe espandersi.

Sfruttando il runtime Java, Scala è sicuramente pronta per la prima serata. Se è possibile distribuire un'applicazione Scala, una volta generato il bytecode, dovrebbe sempre funzionare con quella particolare versione del runtime Java. La libreria basata su Scala funzionerà come qualsiasi altra libreria Java di terze parti che conosci.

In termini di IDE, strumenti di costruzione e tutto il resto, Scala non ha lo stesso livello di proliferazione di Java. Quindi non hai molti framework basati su Scala o strumenti basati su Scala. Ciò ha più a che vedere con la popolarità di Java che con la crescente popolarità di Scala. Scala ha strumenti funzionali tra cui l'IDE Scala e sbt, strumento di creazione. Ma non sono così sofisticati come alcuni degli altri strumenti di supporto Java in circolazione.

Punti di raccolta delle ciliegie da @huynhjl e @FarmBoy:

• Trovare un numero sufficiente di programmatori Scala esperti potrebbe essere difficile.

• Il dogma delle "migliori pratiche" per Scala è ancora in evoluzione (*).

• Guide di stile, convenzioni, ecc. Sono ancora in evoluzione (*).

• Il supporto degli strumenti è ancora in evoluzione (*).

Mettendoli insieme, forse una domanda migliore da farti (se stessi) è se la tua organizzazione è pronta per usare Scala su un progetto "non banale"? Hai le persone che riescono a far fronte a un grande progetto con così tante cose "ancora in evoluzione"? Al contrario, sarebbe meglio fare prima un progetto più piccolo?

(* In effetti, la maggior parte delle lingue si sta ancora evolvendo in uno o più di questi aspetti. Il problema qui è il tasso di cambiamento / flusso ... e se la tua squadra può farcela.)

David Pollak di Good Stuff ha un eccellente post sul blog intitolato Functional Languages ​​Rule (ma non quest'anno) che si addentra nella nitidezza dei linguaggi funzionali in generale, e Scala in dettaglio che consiglio vivamente di leggere per capire meglio se Scala è pronta per la prima serata.

Non ho mai capito la distinzione tra enterprisee non enterpriseprogrammi.

Uso gli stessi programmi sul lavoro come a casa. Non userei un programma mediocre nel mio tempo libero - perché dovrei?

Che cos'è un programma non professionale? Ho visto che sono state utilizzate applicazioni scadenti, perché l'utente non lo sapeva meglio, a causa di problemi di compatibilità, o l'utente si è rifiutato di leggere qualcosa di nuovo.

Ma è un problema di software obsoleto e di obiettivi, pensava lo sviluppatore, non la lingua, il programma era scritto. Se inizi a pensare, in quale lingua è scritto un programma, è già finita: fallire.

Enterprise-applicare è un termine esagerato, che non è utile per discussioni serie.

E quale cliente sa in quale lingua hai svolto il tuo lavoro? A volte a loro importa, a volte no.

Potresti avere domande relative alla maturità di una lingua, ma non puoi rispondere alla domanda per tutti i tipi di imprese e tutte le applicazioni.