¿Qué opinas del anuncio de TJ de abandonar el desarrollo de Node.js y cambiar a Go?

Cambié de un lenguaje estático fuertemente tipado (15 años) a un lenguaje dinámico como Node.js JS (3 años). TJ pasó a Go desde un lenguaje dinámico (comenzando con ActionScript de Flash). Se puede decir que ambos mundos tienen sus propias ventajas y desventajas.

Se puede decir que Node.js JS se utiliza para adaptarse a varias posibilidades. Cuando lo usé, copié los conceptos anteriores de OO y luego pasé a la programación funcional y la programación de flujo (que debe considerarse un tipo especial de programación funcional y descubrí que realmente no existe una solución óptima para los problemas del mundo). Cada año se descubren nuevas posibilidades en la comunidad node.js que subvierten la inercia del pensamiento. Por ejemplo, escriba código que realmente reutilice el front-end y el back-end, y luego reutilícelo en el cliente a través de Browserify; conecte varios componentes de la aplicación a través de Stream;

Superé Callback Hell a través de los siguientes aspectos:

1. CoffeeScript: Reducir visualmente la interferencia de anidamiento.

2. La filosofía de npm es abstraer su código en una parte reutilizable lo más pequeña posible, cubrirla con pruebas unitarias y dividir y conquistar.

3. Nueva arquitectura de conexión, como: stream o un mecanismo de complemento similar a express

Después de aproximadamente un año, ya no creo que esto sea un problema, sino el la ganancia es el rendimiento. Actualmente, la lógica de devolución de llamada garantiza un rendimiento de concurrencia mejor que cualquier otro método. TJ mencionó esto, ya sea que desee "rendimiento" o "usabilidad", su elección es "usabilidad", después de todo, está pasando de JS a escritura fuerte, no al revés.

Pero hay que decir que cuantas más posibilidades haya, mayores serán los requisitos de calidad para los desarrolladores. Si los miembros del equipo carecen de esos "verdaderos veteranos", elegiré un sistema de tipos sólido como Go, Java o .NET. Después de todo, puede haber un paradigma de programación estricto para restringir a todos y evitar cometer errores de bajo nivel.

Nadie pensó que los logros de JS en realidad provenían de sus propias deficiencias (gramática muy vaga), y aquí chocaron varias metodologías de software. Esto es completamente diferente de Go.

Además, la administración de paquetes Go no admite referencias de paquetes en paralelo (es una limitación de los lenguajes estáticos), por lo que es difícil para la comunidad de paquetes Go (ya sea que haya almacenamiento centralizado o no). ) para formar una imagen. El efecto de explosión de productividad del módulo npm.

Mira atentamente su blog, está muy claro. Su interés está en la informática distribuida y Go es el más adecuado para este campo. Continuará manteniendo koajs y está buscando a alguien que se haga cargo de otros proyectos.

Se mencionaron algunas deficiencias de nodejs, facilidad de uso, herramientas, depuración y mensajes de error. Estos son problemas objetivos de nodejs. Las deficiencias inherentes del lenguaje JS se amplifican en el contexto del servidor.

Zed Shaw, el autor de mogorel, anunció de manera abusiva que abandonaría Ruby Circle y se cambiaría a Python. Este hermano actuó con sensatez, puramente por decisiones técnicas, no por complacencia. odiar a la comunidad (por supuesto, hay algunas personas que odian a la comunidad) Insatisfacción porque el equipo de Joyent no se centra en la facilidad de uso).

No creo que sea necesario exagerar el impacto del asunto, pero sería bueno si los fanáticos de nodejs pudieran ser más objetivos y posicionar a nodejs con mayor precisión.

Aunque el lenguaje es sólo una herramienta, para lo que estás haciendo, la "herramienta" correcta a menudo logrará el doble de resultado con la mitad de esfuerzo. En este punto, siempre he pensado que unificar el front-end y el back-end es una broma.

Incluso si no hablamos de las desventajas inherentes al nivel del lenguaje JS, como los enormes costos de mantenimiento de ingeniería causados ​​por la sintaxis demasiado flexible y confusa, la estabilidad de V8 en sí es un gran beneficio para el desafío de fondo. Google V8 se originó en Chome. La búsqueda de velocidad y la práctica de intercambiar espacio por tiempo no son tan defectuosas en la era actual de gran memoria, y una estabilidad ligeramente pobre no es algo fatal. Pero en el servidor, cada centímetro de memoria vale cada centímetro de sangre, y nadie es como OOM o crash.

La velocidad no es tan importante. El servidor busca la escalabilidad. El rendimiento final de un solo servidor a menudo no es tan importante, del orden de cientos, miles o incluso decenas de miles. Sobre esta base, la estabilidad y la disponibilidad determinan en última instancia la calidad de su servicio, y estas son las deficiencias actuales del V8 o nodo.

Al mismo tiempo, el servidor requiere suficiente control sobre la tecnología utilizada. La gran cantidad de magia negra en node o js debilita la confianza de los ingenieros de sistemas a este respecto. No hay forma de solucionarlo. Si no se puede encontrar el error y el tiempo de inactividad aumenta, ¿quién es el responsable?

¿Por qué Java sigue ocupando una proporción tan grande a pesar de ser criticado por otros? ¿Por qué C es tan antiguo y sigue siendo la base para los programadores del lado del servidor? ¿Por qué Python es tan lento que muchas empresas todavía lo prefieren? Nada más, simplemente porque han pasado por muchas pruebas y han demostrado ser fiables y controlables. Además, incluso Python, después de la última serie de bendiciones técnicas, en realidad no es lento en comparación con Node...

¿En cuanto a por qué recurriste a Go? Personalmente, creo que Go ha abordado varias necesidades importantes del desarrollo del lado del servidor. La primera es suavizar las diferencias entre servidores, lo que comúnmente se conoce como multiplataforma. Entonces la biblioteca estándar es relativamente poderosa y los detalles del sistema están bien protegidos. Además, el nivel del idioma no solo satisface la dinámica y la eficiencia de desarrollo requeridas por los script kiddies, sino que también satisface las necesidades estáticas de los ingenieros de sistemas para mantener el orden del proyecto y la eficiencia de los resultados finales.

Al mismo tiempo, se adapta a las tendencias futuras de desarrollo del lado del servidor, como la Coroutine nativa, y optimiza en gran medida su consumo de memoria y otras características. Para el desarrollo del lado del servidor, mejora en gran medida la productividad y también genera código. La lógica y la legibilidad han mejorado enormemente. Según los puntos anteriores, Go es de hecho una mejor opción como lenguaje de desarrollo del lado del servidor orientado al rendimiento en este momento.

Como proyecto de escritorio, el núcleo V8 de Node tiene fallas demasiado obvias en estos aspectos. Hacer demostraciones es bueno, pero WTF llega al nivel de ingeniería. Al menos para mí, lua/python/go, e incluso Rust en el futuro, son mejores opciones.