Forse ho frainteso questo concetto. Ma è comune, quando si sviluppa il back-end a un'app, un cellulare o un web. Per prima cosa scriverlo in un linguaggio di programmazione di alto livello come php, python, javascript per sviluppare rapidamente un prototipo funzionante con meno righe di codice. E poi se le prestazioni diventano una priorità riscrivendo l'app in un linguaggio di basso livello come C o C ++?
Se un'applicazione deve essere ottimizzata per le prestazioni, non si riscrive il tutto in un linguaggio di programmazione diverso. Invece, profili l'applicazione, trovi i suoi "punti caldi" (il codice in cui il programma sta trascorrendo la maggior parte dei suoi cicli di clock) e riscrivi solo il codice in quei punti caldi. Generalmente, questi hot spot comprenderanno il 10 percento o meno del codice complessivo.
In pratica, è raro cambiare i linguaggi di programmazione a metà progetto, perché le lingue vengono comunemente scelte per la loro applicabilità al dominio problematico. Le applicazioni Web sono scritte in linguaggi Web perché vengono eseguite nei browser e nei server Web e poiché la maggior parte del tempo viene impiegata per l'attesa di reti e database, non di numeri di scricchiolio. I giochi non sono sempre scritti in tali lingue, perché ci sono lingue che sono più adatte al dominio di gioco.
Non è raro che scriva un'implementazione di un prototipo in una fase esplorativa. Scommetterei che la maggior parte di questi prototipi sono scritti nella stessa lingua del linguaggio usato per una riscrittura (che spesso non viene mai). Allo stesso modo, la lingua utilizzata per ciascuna parte è probabilmente determinata dalla cultura locale della società che implementa il codice piuttosto che dalla "performance". Nessuno userà un linguaggio con cui non hanno familiarità per scrivere un prototipo solo perché qualcuno dice che è "bravo a prototipare", almeno non per funzionalità critiche. Le scelte linguistiche sono quasi sempre basate sulla familiarità.
Come afferma Robert Harvey, di solito i programmi (o davvero i sistemi) vengono riscritti a pranzo, non tutti in una volta. Di solito ci sono "hot spot" che possono essere riscritti nella stessa lingua o potenzialmente in una lingua diversa che fornirà i necessari guadagni in termini di prestazioni. Un'intera riscrittura per motivi di prestazioni sarebbe in genere dopo che sono stati affrontati tutti gli ovvi "punti caldi" e un tentativo di ottimizzare il codice corrente. Riscrivi possono anche verificarsi a causa di cambiamenti nella cultura del progetto.
Ci sono sicuramente stati diversi progetti pubblici che sono stati riscritti da lingue "di alto livello" alle lingue "di basso livello", ma non è spesso chiaro quali sono le motivazioni sono e raramente sono essi esclusivamente prestazioni. Non possono nemmeno includere le prestazioni. Non è chiaro quanto spesso ciò avvenga nel complesso però. Ancora una volta, la cultura probabilmente ha un'influenza dominante. Ad esempio, uno di questi esempi è un progetto di Paul Graham ha scritto in Common Lisp che è stato utilizzato da Yahoo per anni, ma alla fine è stato riscritto in C ++ e Perl in un punto in cui Paul Graham non è stato coinvolto nel progetto.
Se una riscrittura doveva essere fatto con prestazioni come uno degli obiettivi principali e la lingua corrente è un linguaggio la cui attuazione primario è un interprete, poi assumendo un nuovo linguaggio viene scelto per le prestazioni, è probabile che sia qualsiasi lingua la cui l'implementazione primaria è un compilatore (potenzialmente JIT), non solo C o C ++. Ciò include Java, C #, Go, Rust, O'Caml, Haskell, anche JavaScript al giorno d'oggi. Ancora una volta, è probabile che tale scelta sia maggiormente guidata dalla familiarità e dalla cultura rispetto a qualsiasi metrica obiettivo.
Leggi altre domande sui tag application-design applications high-performance