scalabilità di Scala su Java

Beh, certo che lo è. E Java riutilizza tutta l'infrastruttura fornita dalla JVM, che è stata scritta in C, e alla fine funziona in codice macchina!

Il punto di consentire agli sviluppatori di far scalare le proprie applicazioni non è quello di fornire più potenza. Assembler ha già tutta la potenza che il tuo hardware consente e nessuna lingua può fornire di più. In effetti, l'intero punto delle lingue di ordine superiore è quello di limitare ciò che i programmatori possono fare in loro. Sembra orribile, ma il collo di bottiglia nello scrivere codice ottimo, corretto ed efficiente non è il modello di calcolo. È il cervello delle persone che devono capire i programmi scritti per la macchina. L'esperienza ha dimostrato che non siamo abbastanza intelligenti per comprendere la soluzione teoricamente ottimale di un complesso problema di calcolo; probabilmente non lo riconosceremo nemmeno se lo vedessimo.

Nell'esempio concreto, l'articolo presumibilmente significa che Scala fornisce librerie e concetti di livello superiore che rendono più facile per gli sviluppatori comprendere i loro problemi dal punto di vista della concorrenza, e quindi il risultato finale è migliore e più scalabile rispetto alla codifica direttamente in Java (o C o Assembler) sarebbe stato. Ciò non contraddice il fatto che Scala funzioni interamente su una macchina virtuale Java. La JVM è una bellissima invenzione che consente di scrivere tutti i tipi di materiale ordinato più facilmente di quanto sarebbe possibile senza di esso - inclusi framework e librerie che rendono le cose ancora più complesse facili. Incredibile, vero?

È una questione di supporto alla biblioteca. Java usa il costrutto Thread di basso livello per rappresentare la concorrenza (questo è come il linguaggio assembly del mondo della concorrenza). Esistono molte librerie e tecniche che è possibile utilizzare per creare soluzioni scalabili in aggiunta a queste, ad esempio utilizzando il supporto fornito dal pacchetto java.util.concurrent e seguendo le tecniche di Brian's Goetz nel suo libro Java Concurrency in Practice. Scala ha aiutato a introdurre elementi come il framework Akka (anch'esso utilizzabile da Java ora) che utilizza alcune di queste migliori pratiche e il supporto della libreria. Questo non vuol dire che Java il linguaggio non possa raggiungere (collezioni parallele, ecc.), Come afferma Kilian, funziona tutto sulla JVM e quindi sul JMM.

Inoltre, gli oggetti Java sono anche mutabili per impostazione predefinita e richiede alcune conoscenze non banali per renderli effettivamente immutabili. Scala reputato rende più facile la creazione di oggetti immutabili

Doesn't Scala use Java's core libraries which brings all the threading and locking issues from Java to Scala?

Bene, sì, e se lo fai chiudendo in Scala dovrai affrontare gli stessi problemi. Il punto, tuttavia, è che non dovresti, dato che Scala ti fornisce astrazioni che gestiscono questo problema in maniera più sicura.

Ora, Scala fa due cose che aiutano davvero. Uno di questi è il modello dell'attore, che può essere considerato come uno schema di concorrenza, fornito da Scala come una libreria. Se sei un programmatore Java, ti suggerisco di andare al sito Akka e guardare le loro cose Java. Questa è la libreria che sostituirà l'attuale libreria degli attori di Scala, e puoi usarla da Java.

La seconda cosa che Scala aiuta è l'uso di strutture di dati immutabili. Non c'è nulla che impedisca a Java di utilizzare strutture dati immutabili - String , per esempio, è esso stesso immutabile! Le strutture di dati immutabili non soffrono di problemi di concorrenza poiché i thread non possono modificarle.

Ci sono altre cose che si aggiungono a queste, per creare soluzioni complete, come agenti e stm (entrambi disponibili da Akka), o latch (da Java).

Ora, le due cose sopra possono essere fatte in Java, come ho detto io stesso. È possibile utilizzare Akka in Java e scrivere strutture di dati immutabili in Java (o utilizzare dalle librerie che li forniscono). Tuttavia, Java rende doloroso utilizzare questa roba, perché non supporta né tipi di ordini più alti, né chiusure e funzioni di prima classe.

Quindi, mentre puoi farlo, i programmatori di solito non lo faranno perché, in Java, scrivere questo codice è molto prolisso (intendo, molto più dello standard per Java).

Il pensiero principale dell'articolo di riferimento è:

the scalability limitation is confined specifically to the Java programming language itself, but it is not a limitation of the Java platform as a whole. In fact, when programs are written to properly take advantage of the underlying Java platform, linear scalability isn't an issue.

If massive scalability is what you need, you can always take advantage of peripheral JVM languages like Scala and Clojure

Non posso essere d'accordo con questo. Usare linguaggi JVM come Scala implica:

1. utilizzando il supporto di runtime specifico. È possibile accedere a questo supporto direttamente dai programmi Java.

2. sintassi specifica, che consente alle espressioni concise di rendere l'accesso al supporto di runtime facile e meno soggetto a errori. Questo è vero, e scrivere in puro Java è più prolisso e richiede più disciplina, ma il divario non è così drammatico.

In breve, Scala gestisce la concorrenza meglio di Java a causa dell'uso del modello di attore. Il modello di attore può essere impiegato in Java. Ci sono diverse librerie di attori per Java, incluso Akka (usato da Scala), quindi passare a Scala non è un imperativo.

L'uso del modello di attore tramite puro Java ha i suoi vantaggi:

• semplificazione del debug
• possibilità di personalizzare la libreria degli attori utilizzata. Ciò è particolarmente vero quando la libreria è compatta e quindi comprensibile, come questa mia: df4j