¿Cuál es el mejor lenguaje de programación y arquitectura para construir una aplicación escalable?

Del lado del servidor, usaría Go language (o golang) todo el tiempo. Es un lenguaje muy simple y fácil de aprender que fue diseñado para la ingeniería de software a gran escala. Es perfecto para servidores web, servidores de bases de datos, servidores de aplicaciones, cualquier cosa que necesite en el lado del servidor. Go sobresale en concurrencia, por lo que podrá manejar cualquier carga de transacción.

Para la aplicación front-end, use Java para Android y Swift para iOS. Utilice un lenguaje transpilado para la web front-end. Utilice Java (JavaFX) para escritorio de Linux y Windows. Decida lo que decida, aléjese de JavaScript si es posible.

Puede usar Java para todo el front-end si codifica la aplicación web con GWT y la aplicación iOS con Codename One o Multi-OS Engine. Esta es la mejor manera de aprovechar un lenguaje para todo, ya que realmente no desea tener demasiados lenguajes de programación en su proyecto.

Incluso podría usar Java del lado del servidor, pero sigo pensando que el lenguaje Go sería la mejor opción. Ir es realmente asombroso.

Buena suerte.

Su “aplicación” implicaría muchos tipos diferentes de programas que se ejecutan en muchas máquinas. Como regla general, tendrá al menos lo siguiente:

• Servidores de bases de datos.
• Servidores web
• Muchos tipos de servidores de aplicaciones y programas de aplicaciones.
• Dispositivos y aplicaciones de red.
• Supervisar y alertar aplicaciones, que tendrán su propia “pila” de cosas, a menudo incluyendo bases de datos, etc.
• Grandes cantidades de otras cosas, incluyendo minería de datos y análisis, seguridad, probablemente varios tipos de facturación, informes, análisis de tendencias, etc.

Esto no sería una “aplicación”, sino una empresa completa. Y, como regla, no se molestaría demasiado con la portabilidad de cualquier cosa que no sea la parte superior de la pila que interactúa con el usuario final, e incluso si solo está instalando algún tipo de interfaz de usuario que no sea web en computadoras de escritorio / portátiles.

No hay razón para molestarse en hacer que las partes más profundas de la pila sean portátiles a menos que esté planeando comercializar toda esta pila como un producto de software en las instalaciones.

F # (o Clojure).

En realidad, no hay una “respuesta correcta” para dicha pregunta sin MUCHO más contexto, pero si todo lo que supiera fuera lo que había escrito anteriormente y se me REQUIERE que haga una elección de inmediato sin posibilidad de cambiarla más tarde, entonces sería así.

F#

(Casi dije Clojure debido al requisito de Linux, pero F # ahora es de código abierto y también está disponible en Linux e iOS).

Si dijiste que podría cambiar la respuesta más tarde, estas serían mi elección porque los posibles sustitutos serían similares a estos lenguajes en filosofía (lenguajes de “programación funcional”).

Alguna pequeña evidencia: Jet.com (el competidor relativamente nuevo de Amazon / SamsClub) apostó su negocio en F # en gran medida y lo está haciendo bastante bien.

Para ser claros, ambos lenguajes tienen “versiones web”: F # tiene Fable, Clojure tiene ClojureScript. Ambos pueden funcionar para dispositivos móviles debido a React y React Native, pero F # probablemente gane esto debido a la elección de Xamarin.

Esto trae otro enfoque: React y ReactNative como una estrategia y luego elige el lenguaje del programa que se ajuste. (Es probable que termine en F # / Fable o Clojure / ClojureScript).

Lo que está sucediendo aquí es que la mayoría de las tecnologías implican USAR Javascript (sí, sé que apesta) como la MÁQUINA VIRTUAL, mientras que pocos quieren trabajar realmente en Javascript (porque apesta como un lenguaje de programación a gran escala).

Con la velocidad de las computadoras modernas y la naturaleza de las aplicaciones distribuidas (cada teléfono celular es una computadora para el navegador del cliente, etc.) Javascript es esa “máquina” con la que podemos compilar.

Esto significa programar en lenguaje de alta calidad como F # para nuestro servidor y COMPILAR F # (con Fable) para el cliente web (Javascript).

React es una biblioteca (inventada específicamente por Facebook) para ejecutar aplicaciones de nivel empresarial en un navegador; ReactNative va un paso más allá.

ReactNative permite ejecutar la “aplicación” en una máquina virtual que es esencialmente el “navegador” de Chrome sin todas las características “específicas del navegador”.

Estas cosas se ejecutan prácticamente EN CUALQUIER LUGAR que Chrome puede ejecutar, que es prácticamente EN TODAS PARTES.

Y funciona como una “aplicación nativa”, lo que significa que, a diferencia del Javascript DENTRO del navegador, la aplicación tiene acceso a las funciones externas normales del sistema operativo host, ya sea Windows, Linux, iOS, iOS móvil o Android, etc.

F #: esa es mi respuesta y me estoy aferrando a ella.

… Hasta que aparezca algo mejor, pero será la Programación Funcional (hasta que aparezca algo mejor).

Recientemente me he hecho fanático de las arquitecturas llamadas de “micro servicio”.

Es decir, en lugar de tener una base de código de servidor que se ocupe de una base de datos, tiene muchos pequeños “servidores” diferentes a cargo de diferentes cosas. Es posible que solo tenga un servidor CouchBase que sirva como API REST para algunos datos. Es posible que obtenga una API de terceros para toda su administración de usuarios. Podría activar un servidor de chat con algún nodo JS + socket IO.

Por supuesto, puede que no le guste esa respuesta porque eso significa que tendrá que aprender muchas cosas diferentes.

Sin embargo, tengo buenas noticias en el front-end. Alguien afirmó haber lanzado con éxito una aplicación en 6 plataformas diferentes con una base de código usando React Native + React Native Web + Electron.

Tenga en cuenta que estas obviamente no son sugerencias serias ya que hay falta de contexto. Estoy tirando cosas por ahí.

Si está tratando de construir un servicio de Internet grande y escalable, le sugiero que intente encajar en una arquitectura de nube disponible si es posible. Los proveedores de la nube emplearon una gran cantidad de ingeniería para hacer servicios eficientes, escalables y tolerantes a fallas. No creerías la ciencia espacial que entra en algo tan conceptualmente simple como una tienda de valor clave. Desea dedicar su tiempo a su aplicación y lógica empresarial, no a un trabajo pesado a nivel de sistema no diferenciado.

(Divulgación: trabajo para AWS)

No he estado involucrado en ingeniería del lado del cliente durante 15 años, por lo que no me considero calificado para dar consejos sobre qué hacer allí.

OCaml será una mejor opción.

Es multiplataforma, rápido y seguro.