¿Cuáles son las desventajas de Go en comparación con Node.js?

Como otra respuesta mencionada, esta no es exactamente una comparación de manzanas con manzanas.

Sin embargo, después de haber usado ambos ampliamente, encuentro que puede ser más fácil enumerar las ventajas que tiene Node / JS (específicamente en comparación con Golang) en comparación con las desventajas de usar Go :

• npm : uno de los mejores gestores de paquetes que encontrarás en cualquier idioma. Actualmente, Golang depende de la comunidad para abordar este problema y, como resultado, es probable que nunca se integre en las herramientas del lenguaje en sí (que, por lo que vale, es parte de lo que hace que Go sea genial). Vale la pena señalar que el favorito actual es Godep. Aunque en cierto modo aborda el problema, en mi opinión sigue siendo subóptimo y se deriva de problemas inherentes con go get .

• Soporte de JSON de primera clase : mientras que Golang tiene soporte en la biblioteca estándar (codificación / json) para ordenar y deshacer JSON, sigue siendo un paso explícito. Con JavaScript, es una parte central del lenguaje a partir de ECMAScript 5 (y altamente optimizado para eso), por lo que encuentro que es mucho más fácil trabajar con él.

• Programación funcional: aunque Golang tiene funciones de primera clase, carece de soporte para iterar sobre colecciones de tipo arbitrario (por ejemplo, “genéricos”), por lo que tiene una sensación de procedimiento. Por otro lado, JavaScript tiene soporte para construcciones de programación funcional como map y reduce , así como excelentes bibliotecas de contenedor como underscore.js (o es el primo Lodash ). Vale la pena señalar que, en teoría, podría hacer uso de las capacidades de reflexión de Go para lograr algo similar, pero tiende a derrotar / negar tanto el rendimiento como los aspectos de seguridad de escritura del lenguaje en sí y, en general, es una idea terrible.

Una pregunta más informativa podría ser (y quizás lo que pretendía):

“ ¿En qué situación elegiría Node.js sobre Go?”

Gran pregunta, ¡me alegra que lo hayas preguntado! 🙂

• Aplicaciones vinculadas a E / S : para algo en que los ciclos de CPU se ven reducidos por E / S, Golang no será mucho (si es que lo es) más útil. Aquí, ambos tienen primitivas de concurrencia para poder manejar un estilo de programación más asíncrono (por ejemplo, devoluciones de llamada y promesas, gorutinas). Por lo tanto, para atender solicitudes de red o interactuar con una base de datos, es probable que la diferencia en el rendimiento solo no influya en la decisión.

• Creación de prototipos : aunque me encuentro muy productivo en Go, aún así (o incluso más) elegí JavaScript / Node.js para crear un nuevo servicio (por ejemplo, una API) antes de haber especificado completamente los requisitos de ingeniería o cómo debe comportarse. Esto es menos un cumplido para Node específicamente y más una característica de los idiomas interpretados en general.

• Aplicaciones web : si bien han surgido varios marcos en los últimos años al servicio de poder lograr técnicamente lo mismo en Go, elegiría JavaScript / Node cada vez para una aplicación web dinámica (por ejemplo, cualquier cosa donde Rails pueda ser tradicionalmente usado). Últimamente, he estado usando Node.js localmente como un entorno de desarrollo (por ejemplo, herramientas de compilación) para compilar activos estáticos de JavaScript que pueden ser implementados y servidos por un servidor web como Nginx, mientras que uso Golang como una capa RESTful API que interactúa con fuentes de datos y servicios de solicitudes de front-end. Personalmente, estoy muy contento con este enfoque.

Finalmente, vale la pena mencionar que últimamente está surgiendo una clase de aplicaciones web (denominadas “isomórficas”) que unifican los beneficios de la representación tradicional del lado del servidor con los de las aplicaciones más modernas de una sola página, que requieren un entorno JavaScript del lado del servidor ( usando algo como un DOM virtual) y para el cual Node.js es perfectamente adecuado. Existen numerosos beneficios para este enfoque y, aunque todavía es bastante difícil en lo que respecta a la implementación a principios de 2015 (hablando por experiencia), vale la pena vigilarlo. Tanto React como Ember han avanzado mucho en este aspecto en los últimos tiempos.

Para el desarrollo web, una de las grandes fortalezas de Node es la capacidad de usar algunas de las mismas bibliotecas y códigos tanto en el front-end como en el back-end. Un ejemplo realista de esto es renderizar plantillas.

Supongamos que tiene una plantilla que representa html para una tarjeta en algún tipo de feed social. En algunos casos, es posible que desee que esas plantillas se representen en el cliente porque es mucho más rápido enviar los datos y generar nuevos bloques. En otros casos, es posible que desee renderizarlos en el servidor (por ejemplo, para fines de SEO o para compartir en redes sociales).

¿No sería bueno poder usar el mismo motor exacto de representación de plantillas de JavaScript en ambos casos? Eso, en teoría, ahorraría tiempo de implementación y generaría menos errores debido a inconsistencias. No hay problema, solo tome el paquete de npm e instálelo, y sí, algunas personas incluso están usando npm para administrar paquetes front-end (aunque prefiero Bower).

Otro buen aspecto de esta forma de trabajar es que los desarrolladores de Node que se vuelven expertos en escribir javascript “bueno” ahora son más útiles en toda la pila y pueden flotar más fácilmente entre el desarrollo de back-end y front-end. Y, a menudo pueden mejorar en gran medida la calidad del código escrito para el front-end.

Incluso si está escribiendo código separado para el back-end, es muy bueno no tener que cambiar su cerebro a una sintaxis y un kit de herramientas diferentes.

Y ahora, debido a la popularidad de JavaScript y Node, también puede aprovechar esas mismas habilidades para crear prototipos de hardware con Tessel o jugar con robots (The Rise of JS Robotics).

Independientemente de las fortalezas de las debilidades de Javascript en comparación con otros idiomas, existen grandes beneficios al aceptar su ubicuidad emergente.

Gracias por A2A

Sí hay. Siempre encontrará ventajas y desventajas. En el caso de Go vs JS con Node, puede usar el código JS para el lado del servidor y del cliente. Esto puede reducir la complejidad. Luego también hay pensamientos que personalmente no me gustan con go. Difícilmente puede reutilizar fragmentos de código, ya que no hay genéricos en marcha. Siempre debe convertir sus datos en las interfaces correspondientes primero, lo que puede generar un código repetitivo. Por otro lado, ir es más rápido. Por lo tanto, debe elegir su idioma relacionado con sus tareas. Un patrón útil son los microservicios que se comunican entre sí. Con un diseño de este tipo, puede elegir los idiomas directamente relacionados con los diferentes componentes.

@tjholowaychuk, el creador del framework Express más famoso de NodeJs, lenguaje de programación Luna, Koa, Stylus, Cluster, Mocha, Jade, node-canvas y más de otros 300 proyectos de código abierto, dejó nodeJs para Go, mencionó las razones de dejar Node y voy a ir en esta publicación. Esto puede explicar qué idioma tiene desventajas sobre cuáles.

Una comunidad más pequeña y JSON no es nativa de Go. Originalmente, Go era un lenguaje de programación de sistemas, lo que podría disuadir a las personas (eso personalmente me gusta bastante). Sin embargo, Go está compilado y tiene capacidades de subprocesamiento más potentes (y MUCHO mejor depuración sin usar bibliotecas para eso). Ambos tienen razones para existir, y ambos tienen casos de uso específicos.

Hola,

Aquí he descrito las ventajas y desventajas de Go.

Ventajas:

• Ir compila muy rápidamente.
• Go admite concurrencia a nivel de idioma.
• Las funciones son objetos de primera clase en Go.
• Go tiene recolección de basura.
• Las cadenas y los mapas están integrados en el lenguaje.

Desventajas

• Go sigue siendo un lenguaje experimental sujeto a cambios. (Supongo que esto podría ser una ventaja dependiendo de cómo lo veas. Para la mayoría es probablemente una desventaja).
• Go aún no es muy usable en Windows.
• Los paquetes distribuidos con Go son bastante útiles, pero aún faltan algunas bibliotecas. Lo más notable es un kit de herramientas de interfaz de usuario.
• No hay soporte para genéricos en Go, aunque hay muchas discusiones al respecto.

Otros puntos de nota que podrían ser ventajas o desventajas:

• Ir compila al código de máquina.
• Go está muy fuertemente escrito.
• Go no está orientado a objetos en el sentido tradicional.

Estás comparando naranjas con manzanas.
Go es un lenguaje de programación. Node es un entorno para ejecutar JavaScript fuera de su lugar natural, el navegador. Por lo tanto, puede usar Node para escribir el código del lado del servidor para aplicaciones web.

La comparación debe ser entre Go y el motor V8 JavaScript.

Go está compilado, mucho más rápido y con excelentes capacidades de concurrencia.
JavaScript tiene miles de bibliotecas y marcos, y una gran comunidad alrededor. Es el lenguaje de facto de la web (al menos en el lado del cliente).

Entonces, dependiendo de lo que quieras hacer, la respuesta puede ser diferente.
JavaScript es para la web, Go es más un lenguaje de sistemas, por lo que tiene un propósito más general.

Manejo de paquetes.

Todavía no está maduro en Go, ni siquiera puede extraer versiones pasadas o ramas, por defecto solo puede extraer master.

Sin embargo, para hacer cosas avanzadas hay muchos gestores de paquetes no oficiales.

Para mí personalmente, Go es un misterio. Sin embargo, sé que Go es bueno cuando tienes una infraestructura basada en la nube. NodeJS es ideal para todo lo demás (incluida la nube). Si tuviera que elegir entre los dos, elegiría NodeJS, porque puede ejecutarse en cualquier lugar. Go, por otro lado, está vinculado a Google, y no hay demasiados proveedores de hosting que admitan go. La situación, por supuesto, es probable que cambie. De nuevo, sabiendo cómo Google hace las cosas, probablemente mantendrá Go para ellos y sus granjas de servidores.