Perché utilizzare Java come linguaggio lato server su una lingua interpretata?

C'è il titolo della tua domanda che è valido e poi c'è il contenuto della domanda che contiene alcune ipotesi scarse e / o affermazioni errate. Prima parlerò del corpo:

You have to recompile every time you modify any line of code and pass the built EAR or WAR to the application server...

Non è vero. Prima di tutto, esiste la tecnologia per Java che consente di modificare il codice e farlo modificare un'applicazione in esecuzione senza nemmeno riavviare l'applicazione. Link al prodotto per non sostenerlo ma piuttosto come prova. L'ho usato e posso verificare che funzioni. In secondo luogo, deve essere compilato anche python. È solo quando avviene la compilazione. In java lo fai in anticipo. In python succede a runtime (i dettagli possono variare a seconda della variante di Python)

Per quanto riguarda il motivo per cui si dovrebbe usare un linguaggio precompilato, ecco alcuni motivi per non pensarci più

• i file bytecode sono più piccoli dei file di origine e i server (non essendo umani) non hanno bisogno di fonte.
• La compilazione anticipata consente di rilevare errori sintattici. Perché aspettare di aver caricato il file sul server per scoprire che hai dimenticato i due punti?

Il resto dei motivi per cui sceglieresti l'uno rispetto all'altro non riguardano il momento in cui compili. Tendono a centrare il codice dinamico rispetto a quello statico e i vantaggi e gli svantaggi tra i due approcci. Mi aspetterei che un codice Java ben scritto sia più veloce di Python ben scritto, anche se questo è un fattore che può cambiare nel tempo sia in termini di velocità effettiva sia di importanza.

In primo luogo, l'iperbole è un po 'spenta:

You have to recompile every time you modify any line of code and pass the built EAR or WAR to the application server...

Questo dipende interamente se si utilizza JSP o qualche altra libreria di template per creare la propria applicazione. I JSP e la maggior parte dei modelli alternativi ti consentono di modificare sul posto e di ricaricare semplicemente la pagina. Devi solo ricordarti di copiare queste modifiche nel tuo repository. Ma c'è di più, vedi sotto.

Perché Java?

Il più grande vantaggio che Java ha su diverse altre lingue è l'ecosistema che lo circonda. Sia che tu stia costruendo un'applicazione basata su Spring o facendo le tue cose, di solito ci sono alcune API là fuori che sono pronte per supportare ciò che vuoi fare. L'ecosistema Java si è ampiamente specializzato sul lato server. Sapere che non devi reinventare la ruota è un grande vantaggio.

Java ha i suoi aspetti negativi? Assolutamente, ma questo vale per ogni linguaggio informatico inventato. Se non la pensi così, probabilmente non hai costruito nulla di sostanziale con quel linguaggio.

Incolpare Java per una build lenta è ingiusto. Prenditi del tempo per vedere se uno strumento di costruzione migliore può migliorare i tempi di costruzione. Se il tuo server di build è anemico, prenditi del tempo per capire come migliorare come si costruisce. Ad esempio, ho un progetto che impiega 2,5 minuti per creare sul mio computer locale per compilare e creare un pacchetto di distribuzione da tutti i pezzi Java, C # e Python. Lo stesso processo sul server di build richiede 14 minuti. Molto di ciò ha a che fare con la velocità del disco e si tratta di un vecchio server. Correggere la build.

Perché non una lingua interpretata?

Dipende molto dalla piattaforma che stai costruendo e dalla squadra che hai. Una cosa è dire che stai usando Ruby on Rails o PHP, ecc. E un'altra per trovare sviluppatori competenti che supportino la tua app. Per essere onesti, il problema del personale è l'unica ragione per cui siamo riusciti a migrare da Ruby on Rails in un progetto.

Detto questo, ci sono pochissime ragioni tecniche per non usare un linguaggio interpretato. In genere dipende da se è possibile trovare tutte le librerie di supporto necessarie per il proprio dominio specifico.

• Scegli la lingua più adatta alle tue esigenze, inclusa la ricerca di persone
• Fai attenzione a lavorare in un modo in cui puoi impegnare il codice funzionante nel controllo della versione
• Sii obiettivo quando selezioni la tua piattaforma. Un'app è più grande del framework o del linguaggio in cui è integrata.

Non si escludono a vicenda

Per i team che utilizzano Java per i servizi Web e creano app per pagina singola in JavaScript, hanno il meglio di entrambi i mondi. L'interfaccia utente è costruita utilizzando una delle tante piattaforme di applicazioni per pagina singola con il vantaggio di poter sperimentare rapidamente. Nel frattempo, la parte del servizio web che in genere non cambia molto può essere utilizzata.

In questo mondo di microservizi, sta diventando sempre più comune disporre di un insieme eterogeneo di tecnologie. Ad esempio, potresti avere un servizio basato su Python per sfruttare le librerie di supporto del linguaggio naturale per una parte della tua app mescolata con pezzi di infrastruttura basati su Java.

Le risposte esistenti non hanno toccato la vera ragione per cui Java è diventato popolare come linguaggio lato server.

Quando i miglioramenti nelle prestazioni della CPU iniziarono a provenire da core aggiuntivi anziché aumentare la velocità di clock, le applicazioni dovevano diventare multi-thread per realizzare quei miglioramenti di prestazioni. Java è stata una delle prime lingue di uso comune a introdurre costrutti di multithreading di alto livello che rendevano la scrittura di applicazioni altamente concorrenti relativamente facile. Nonostante la reputazione di Java (non più meritata) per essere lenta, era evidente che si potevano scrivere applicazioni server multithread in modo più veloce e semplice in Java di quanto si potesse in quasi qualsiasi altra lingua. Ecco cosa fanno le persone.

You have to recompile every time you modify any line of code and pass the built EAR or WAR to the application server

Questo è un problema di processo e non ho visto risposte sopra (inclusi i commenti voluminosi).

Sì, per una distribuzione di produzione o QA, è necessario creare un artefatto deployable. Questa è una buona cosa, se non altro perché impedisce agli sviluppatori benintenzionati di accedere al server per apportare modifiche al codice.

Ma per lo sviluppo, dovresti usare un IDE (come Eclipse o IntelliJ) per eseguire il server localmente. È possibile modificare una singola riga di codice e l'IDE compila in modo incrementale e sostituisce a caldo la classe nel server in esecuzione. Ci sono alcuni casi in cui dovrai ridistribuire WAR / EAR, ma non dovresti mai aver bisogno di una build completa per farlo.

Se non ti piacciono gli IDE, puoi ottenere lo stesso effetto lavorando con file WAR / EAR "esplosi". Questo è doloroso, quindi non lo consiglio, ma funziona sicuramente: Java ti permetterà di ricompilare una singola classe (che era una delle cose che mi piacevano di Java vs C ++ alla fine degli anni '90), e sia Tomcat che Jetty rileverà automaticamente le modifiche ai JSP.