Referencia: Este artículo es una tradución al español de Which language has the brightest future in replacement of C between D, Go and Rust? And Why? respondido en Quora en Inglés por Andrei Alexandrescu, uno de los creadores del lenguaje de programación D.

La respuesta original en Inglés puede verse en https://archive.is/hbBte

Introducción#

A pesar de mi estatus y mi obvio sesgo como co-creador de D, haré todo lo posible para responder con franqueza; sigo Go y Rust, y también sé definitivamente dónde están los trapos sucios de D. Me gustaría animar a las personas con posiciones similares en las comunidades de Rust y Go a compartir su opinión honesta también. Así que aquí va.

En primer lugar, C++ tiene que estar en algún lugar de la cuestión. Ya sea para ser sustituido junto a C, o para ser uno de los candidatos que se supone que sustituirán a C, el lenguaje C++ es una parte clave de la ecuación. Es el lenguaje más cercano a C y el paso obvio a partir de él. Dada la antigüedad de C++, asumiré en lo que sigue que la pregunta también sitúa a C++ junto a C como objetivo de sustitución.

Cada lenguaje tiene una serie de ventajas fundamentales (las llamo “ventajas 10x” porque están cualitativamente en una liga diferente en comparación con al menos ciertas líneas de base) y una serie de desafíos. El futuro de estos lenguajes, y su éxito a la hora de suplantar a C, depende de cómo puedan utilizar sus ventajas 10x de forma estratégica, y de cómo superen sus desafíos.

Permítanme dispensar primero D#

Obviamente, este es el tour de mi casa, así que sé dónde llevarlos a todos para mostrar/esconder apropiadamente los rincones limpios y sucios. También tendré probablemente más que decir sobre D que sobre las otras dos por las simples razones de que sé más sobre D que sobre las otras dos. Hablando con brutal honestidad, los principales retos de D son:

  • Escasa adopción tras muchos años nominales de existencia. Los conocedores de la comunidad D podrían matizar esta afirmación (D en su forma actual es relativamente nueva, la adopción crece, etc). Sin embargo, la percepción se mantiene, y la adopción es impulsada por la percepción y se convierte en un hecho. Por ello, los directivos e ingenieros se muestran nerviosos ante la adopción de un lenguaje que lleva tanto tiempo funcionando sin éxito. Además, el tiempo juega en contra de D a no ser que sea evidente un aumento importante de la adopción.
  • Historia débil sobre la relación de D con la recolección de basura. El GC es un gran invento, pero la decisión de usarla para D ha alienado instantáneamente a un mercado principal: los programadores de C y C++ existentes. Para ellos, la línea del partido ha sido históricamente "¿No quieres GC? ¡No hay problema! ¡Puedes usar D con RAII o al estilo de gestión manual también!" Aunque es cierto, eso es casi inútil porque hay poco soporte en la biblioteca estándar para estilos alternativos de gestión de memoria, lo que significa que el usuario putativo tendría que empezar con el lenguaje despojado hasta los topes y crear toda la infraestructura central. Además, para aquellos que están de acuerdo con el uso de un GC, la calidad de su implementación es mediocre. En general, podría decirse que D tiene los inconvenientes de la GC, pero no disfruta de sus ventajas.
  • Una histórica falta de visión. A falta de apoyo corporativo, D ha sido impulsada por la comunidad, donde la perspicacia de la ingeniería es más fácil de encontrar que la visión a largo plazo, el carisma y el liderazgo. Durante un buen tiempo, la estridencia de los intentos de promoción y relaciones públicas de D ha tenido un valor negativo. El primer documento de visión (https://wiki.dlang.org/Vision/2015H1) está fechado el 1 de Enero de 2015, y la siguiente iteración (Vision/2015H2 - D Wiki) ha llegado con cuatro meses de retraso en un ciclo de seis meses, lo que resulta cuanto menos irónico.

Habría, por supuesto, otras cuestiones, pero se derivan de lo anterior o tienen un impacto mucho menor.

Las ventajas 10x de D son, creo, las siguientes (cuando digo “10x” en lo que sigue me refiero coloquialmente a la “un orden de magnitud”):

  • 10x más rápido de compilar que C++ para un código de producción comparable. Esta diferencia es esencialmente imposible de superar para C++ y prohibitivamente difícil para cualquier otro lenguaje. (Go compila un poco más rápido que D, pero produce un código más lento). La experiencia de utilizar un lenguaje de sistema que construye este código tan rápido es transformadora y de gran alcance. Combinado con el poder de abstracción de D, esencialmente hace que D sea una buena opción para escribir código altamente optimizado por la simple razón de que la experimentación tiene un bajo coste.
  • 10x más rápido que los lenguajes scripting en comparación a comodidad. Un buen uso de D es como un lenguaje scripting conveniente para una variedad de tareas casuales. El ciclo de construcción/ejecución es igual de rápido, y la ganancia en velocidad es enorme. Además, no hay un efecto de “golpear la pared” - si un script crece, D siempre tiene más potencia y mecanismos modulares que ofrecer. Por supuesto, esto debe tomarse con un grano de sal porque, por ejemplo, Python tiene muchas más bibliotecas disponibles. Pero la diferencia de 10x es fundamental: los lenguajes de sistemas tendrían dificultades para llegar al nivel de convivencia de D, mientras que los lenguajes de scripting tendrían dificultades para cerrar la brecha de velocidad.
  • 10x más fácil interactuar con C y C++ que con cualquier otro lenguaje. D utiliza la misma disposición de memoria que C y C++; todo lo que hace es construir una estructura sobre ella, pero las capas inferiores son fácilmente accesibles sin coste alguno. Toda la biblioteca estándar de C es fácilmente accesible sin coste sintáctico o de velocidad, se está trabajando para permitir lo mismo para la biblioteca estándar de C++, y muchas bibliotecas de C son fáciles de interconectar (https://github.com/D-Programming-Deimos). Se podría afirmar que literalmente ningún otro lenguaje puede alcanzar ese nivel de integración.
  • 10x mejor que cualquier otro lenguaje de sistema en la programación genérica y generativa. La introspección estática de D, la evaluación en tiempo de compilación y la generación de código basada en mixins se combinan en un poderoso cóctel que es muy difícil de mezclar bien en otros lenguajes, ya sean nuevos o existentes; en este juego, Go está tan fuera de profundidad que ni siquiera entiende el punto; C++17 está irremediablemente perdido en el bosque; y Rust sólo está tratando de incursionar.

Sobre Go#

Debo reforzar aquí que esto es únicamente mi opinión, vale lo que se paga por ella. Los desafíos de Go son los siguientes:

  • Ralentización fundamental debido a las llamadas indirectas y la recolección de basura. Prácticamente no se puede escribir Go con sentido sin recurrir a las llamadas indirectas a funciones y a la recolección de basura, que son fundamentales para sus características centrales. Estos son los principales impedimentos para lograr el rendimiento en el núcleo. La respuesta del equipo de Go ha sido táctica, por ejemplo, trabajar en un mejor recolector de basura. Sin embargo, es poco probable que el reto de sustituir a C pueda ganarse tácticamente.
  • Política. La línea de partido de Go ha sido desproporcionadamente fuerte y rígida en una serie de cuestiones, pequeñas y grandes. Entre los temas más importantes, el enfoque sobre los genéricos (generics) ha sido lo suficientemente duro y degradante como para hacer de los genéricos la palabra N de Go; todo el tema se ha convertido en un estigma suficiente como para desalentar cualquier intento de diálogo significativo. Creo que la politización de los asuntos técnicos es un patrón extremadamente dañino a largo plazo, y espero que Go encuentre una manera de reparar esto.
  • Simple-simplista. Go es famoso por su sencillez: hay anécdotas de gente que lo aprende rápidamente. Sin embargo, esto se vuelve problemático con el paso del tiempo; el código Go es irremediablemente pedestre - los codificadores de Go se encuentran escribiendo una y otra vez las mismas cosas desde un punto de vista de hormiga porque Go no puede abstraer ni siquiera las nociones o algoritmos más simples. Los dominios que no están ya servidos por bibliotecas fáciles de pegar son difíciles de introducir. Hay una reacción de los programadores que han usado Go para un proyecto y no querrían volver a usarlo. Sería estupendo que Go mejorara la vida de los clientes habituales.

Las ventajas 10x de Go son, en mi opinión, las siguientes:

  • Una estrategia 10x mejor. Tras un breve periodo en el que Go pretendía ser un lenguaje de programación de sistemas, se ha comprometido plenamente con el nicho de los servicios de red. Ha sido un movimiento de marketing brillante, que ha aprovechado los puntos fuertes del equipo de Go (algunos de los mejores ingenieros del mundo en servicios de red - networking). Ese mercado está en alza, y Go era un soplo de aire fresco en un mundo dominado por la burocracia de Java EE y los lentos lenguajes scripting. Ahora Go es un actor importante en ese ámbito, y sería difícil desplazarlo.
  • Ingeniería 10x. Go tiene un sólido equipo de ingeniería detrás, y eso influye mucho en la calidad del lenguaje y, en particular, en la biblioteca de redes y las herramientas. Hasta ahora, la buena ingeniería ha compensado muy bien la falta de potencia del lenguaje.
  • Branding 10x. Muchos de nosotros estamos dispuestos a admitir que uno de los principales motivos de Go es su conexión con Google. Eso le da un peso de profesionalidad, calidad y estabilidad. Por supuesto, la marca no lo es todo, pero lo que significa es que todo lo que tiene que hacer Go es ser un lenguaje decente; no tiene que ser un lenguaje fantástico. La marca se encarga del resto.

Por último, pero no menos importante, Rust#

Permítanme recordar de nuevo que esto es sólo mi opinión. Creo que Rust se enfrenta a algunos desafíos interesantes:

  • Una personalidad desarmónica. La lectura de cualquier cantidad de código Rust evoca el chiste “los amigos no dejan que los amigos se salten el día de la pierna” y las imágenes cómicas de hombres con torsos corpulentos descansando sobre piernas flacas. Rust pone la gestión segura y precisa de la memoria al frente y en el centro de todo. Desafortunadamente, ese es raramente el dominio del problema, lo que significa que una gran fracción del pensamiento y la codificación se dedican esencialmente a un trabajo de oficina (que los lenguajes GC realmente automatizan fuera de la vista). La recuperación de memoria segura y determinista es un problema difícil, pero no es el único problema, ni siquiera el más importante, de un programa. Por lo tanto, Rust acaba gastando una cantidad desproporcionada de espacio de diseño del lenguaje en este asunto. Será interesante ver cómo Rust empieza a abultar otros aspectos del lenguaje; la única solución es hacer crecer el lenguaje, pero entonces queda la pregunta de si la abstracción puede ayudar a la molesta necesidad de tratar los recursos a todos los niveles.
  • Sintaxis extraña. La sintaxis de Rust es diferente, y no hay ninguna ventaja aparente en la diferencia. Esto es irritante para la gente que viene de lenguajes de estilo Algol, que tiene que lidiar con una sintaxis gratuitamente diferente además de conseguir que la contabilización de los recursos sea correcta.

Las ventajas 10x de Rust son:

  • 10x mejores teóricos. De los tres, Rust es el único lenguaje que cuenta con teóricos de PL de talla mundial. Esto se puede ver en la definición precisa del lenguaje y en la profundidad de su enfoque técnico.
  • 10x mejor seguridad que otros lenguajes de programación de sistemas. Por supuesto que tenía que estar aquí, acabamos de discutir el costo de eso.
  • 10x mejor PR. Ha habido un largo periodo antes de la 1.0 en el que Rust era el favorito de la comunidad y no podía hacer nada mal: cualquier problema que hubiera, o bien Rust tenía una solución para él, o la tendría para la 1.0. Las realidades de la 1.0 acabaron con esa luna de miel y marcaron (según mis mediciones y estimaciones) un marcado descenso del interés general, pero estos efectos tienen una forma de perdurar. Además, después de todo, Rust es un lenguaje decente con cosas reales a su favor, y está bien posicionado para convertir este bombo persistente en un marketing sólido.

En resumen#

Que alguno de estos lenguajes esté bien posicionado para sustituir progresivamente a C, C++ o ambos en las bases de código existentes; y que alguno de estos lenguajes se convierta en la opción preferida para proyectos que hoy elegirían C o C++ por defecto… todo depende de la capacidad de estos lenguajes para aprovechar sus respectivos puntos fuertes y encontrar soluciones creativas a sus respectivos desafíos.