A pesar de mi estatus y obvio sesgo como uno de los creadores de D, intentaré responder con franqueza; Seguí los caminos de Go and Rust, y sé absolutamente dónde se lava la ropa sucia en D. Aliento a las personas en posiciones similares en las comunidades de Rust and Go a compartir sus opiniones. Entonces aquí.
Para empezar, en algún lugar de la pregunta debería aparecer C ++. Si debe reemplazarse por C o si es uno de los candidatos para reemplazar C, pero en cualquier caso, C ++ es un elemento clave de la ecuación. Este es el lenguaje más cercano a C y un obvio paso adelante. Dada la edad de C ++, supongo además en este asunto que C ++, junto con C, es el objetivo del reemplazo.
Cada idioma tiene una serie de ventajas fundamentales (las llamo "una ventaja de orden de magnitud", en lo sucesivo denominada "bonificación 10x", ya que califican para la liga mayor con respecto a los enfoques típicos), y una serie de problemas. El futuro de estos lenguajes y su éxito en desplazar a C depende de cómo despliegan estratégicamente sus bonos 10x y cómo superar sus problemas.
Déjame deshacerme de D primero
Obviamente, esta es una demostración de mi propia casa, así que sé a dónde ir para mostrar correctamente solo lo que se necesita y ocultar los lugares sucios. También puedo hablar más sobre D que el resto de la pareja, por la sencilla razón de que lo conozco mucho mejor. Hablando con franqueza directa, los principales problemas de D son:
- Mala recepción por parte del público después de muchos años de existencia nominal. Los hígados largos de la comunidad pueden criticar tal afirmación (D en su forma actual es relativamente joven, la popularidad está creciendo, etc.). Pero esta actitud persiste y afecta el mayor crecimiento de la popularidad y esto es un hecho. Como resultado, los gerentes e ingenieros son escépticos sobre la popularización de un lenguaje que ha sido un perdedor durante tanto tiempo. Además, el tiempo funciona en contra de D hasta que no haya un aumento obvio en popularidad.
- La triste historia de D relacionada con la recolección de basura (GC). GC es un gran invento, pero la decisión de usarlo en D lo aisló instantáneamente del público objetivo principal: los programadores C y C ++. Para ellos, la línea de la fiesta parecía "¿No quieres un GC? No hay problema! ¡También puedes usar D con RAII o con control manual! ” A pesar de que, en general, esto es cierto, este enfoque fue prácticamente inútil debido a la falta de soporte para una biblioteca estándar de este tipo, lo que significaba que el usuario previsto sería despojado y comenzaría con la creación de una infraestructura básica. Incluso para aquellos a quienes no les importó el GC, la calidad de su implementación fue bastante discreta. En general, podemos decir que D obtuvo todas las deficiencias de la GC, pero no aprovechó.
- La prevalencia histórica de la falta de visionarios. Privado del apoyo corporativo, D condujo a la comunidad hacia adelante, en la cual es más fácil encontrar un ingeniero astuto que un gerente de proyecto o un líder carismático. Con el tiempo, el éxito de los esfuerzos de D en la promoción y autopromoción ha tenido un resultado negativo. El primer documento de planificación está fechado el 1 de enero de 2015, y la siguiente iteración (Vision / 2015H2 - D Wiki) salió cuatro meses después de lo planeado, lo cual es un gran ejemplo de auto-ironía en términos de planificación
Hubo, por supuesto, otros problemas, pero fueron consecuencia de lo anterior o tuvieron consecuencias mucho más pequeñas.
Creo que las bonificaciones de 10x para D son las siguientes (una vez más, cuando digo 10 veces, esto es coloquial "mejor por orden"):
- En 10x, la compilación es más rápida que C ++ para un código comparable. Este agujero no puede cerrarse fundamentalmente en C ++, y es extremadamente difícil saltar en cualquier otro lenguaje. (Ir compila un poco más rápido que D, pero el código resultante es más lento) La experiencia de usar un lenguaje de sistema que compila tan rápidamente en código rápido transforma las prácticas antiguas y es muy prometedora. Combinado con el poder de las abstracciones en D, esto esencialmente hace que D sea una buena opción para escribir código altamente optimizado por la sencilla razón de que experimentar es barato.
- 10 veces más rápido que los lenguajes de script con servicios comparables. D es muy adecuado para escribir cómodamente las tareas cotidianas. El ciclo de compilación / lanzamiento sigue siendo igual de rápido, y los beneficios en velocidad son inmensos. Además, no hay ningún problema "toparse con los límites": si el script se hace grande, en D siempre hay suficientes herramientas de lenguaje y modularidad. Por supuesto, hay una mosca en la pomada, por ejemplo, en Python hay muchas más bibliotecas listas para usar. Pero la bonificación 10x es fundamental aquí: los lenguajes del sistema no tienen tanta azúcar sintáctica y los lenguajes de secuencias de comandos están irremediablemente atrasados en velocidad.
- 10x es más fácil de integrar con C y C ++ que cualquier otro lenguaje. D usa las mismas estructuras en memoria que C y C ++; y se construye encima de ellos, pero leer las capas subyacentes permanece libre en términos de velocidad. La biblioteca C estándar es totalmente accesible sin penalizaciones, ni en términos de velocidad ni de sintaxis, y aunque se necesitan algunas mejoras para una simplicidad similar en términos de la biblioteca C ++, muchas bibliotecas C ya están disponibles (https://github.com/D- Programación ...). Se puede afirmar literalmente que ningún otro idioma puede lograr este nivel de integración.
- 10 veces mejor que cualquier otro lenguaje de sistema en genéricos y metaprogramación. En D, la introspección estática, la computación en tiempo de compilación (CTFE) y la generación de código basada en mixin (mezcla de código) forman el cóctel Molotov, que es muy difícil de mezclar correctamente en otros idiomas, ni nuevos ni sobrevivientes; en este juego Go es tan loco que ni siquiera corta un chip; C ++ 17 se pierde irremediablemente en un bosque oscuro; y Rust solo está tratando de balbucear.
Ir a ir
Debo enfatizar que esta es solo mi opinión, sin embargo, merece su atención. Los problemas de Go son los siguientes:
- Desaceleración fundamental debido a llamadas indirectas y al recolector de basura (GC). Casi no se puede escribir una aplicación Go significativa sin recurrir a llamadas indirectas y GC, que son la funcionalidad del centro. Estas son las principales barreras para el rendimiento central de Go. La respuesta de Go fue principalmente táctica, por ejemplo, mejorar el rendimiento del GC. Sin embargo, es poco probable que gane el desafío de reemplazar C tácticamente.
- Política La línea de partido en Go es desproporcionadamente fuerte y dura en una serie de cuestiones, tanto pequeñas como grandes. Un ejemplo de un gran problema es que el enfoque de los genéricos era tan sin sentido y despiadado que hizo que los genéricos fueran la palabra con la letra "G"; Todo el tema se convirtió en lágrimas sangrientas, obstaculizando cualquier intento de establecer un diálogo constructivo. Creo que politizar los problemas técnicos a largo plazo es un modelo extremadamente perjudicial, y espero que Go encuentre una manera de solucionarlo.
- La simplicidad es peor que el robo. Ir es muy simple (juego de palabras, Ir, caminar, nota), incluso hay bromas al respecto. Sin embargo, con el tiempo esto se vuelve problemático; El código de Go es irremediablemente peatonal: los codificadores de Go se encuentran escribiendo las mismas cosas una y otra vez desde el punto de vista de una hormiga, porque Go no puede abstraer incluso los conceptos o algoritmos más simples. Los conceptos que las bibliotecas de integración aún no implementan son difíciles de implementar. Hay una reacción negativa de los programadores que usaron Go para un proyecto y ya no quieren volver a usarlo. Sería bueno si Go mejorara la vida de los clientes habituales.
Los bonos Go 10x en mi percepción son los siguientes:
- 10x en habilidad Estrategia. Después de un breve período en el que Go se posicionó como un lenguaje de sistema, se decidió posicionarlo para servicios de red. Fue un gran movimiento de marketing que aprovechó las fortalezas del equipo Go (algunos de los mejores ingenieros de servicios de red del mundo). Este es un mercado muy candente y Go se convirtió en un soplo de aire fresco para el mundo, que anteriormente estaba dominado por Java EE con su burocracia y lenguajes de secuencias de comandos lentos. Ahora Go es el jugador principal en esta área y será difícil de mover.
- 10x en la habilidad Ingeniería. Go tiene un sólido equipo de ingenieros detrás, y este es el factor principal que influye en la calidad del lenguaje, y en particular la biblioteca de red y el conjunto de herramientas. Hasta ahora, la buena ingeniería ha compensado completamente la debilidad del lenguaje.
- 10x en habilidades de marca. Muchos de nosotros estamos listos para admitir que el principal motivador para usar Go es su conexión con Google. Esto le da la autoridad de profesionalismo, calidad y estabilidad. Por supuesto, una marca no lo es todo, pero ya hace de Go un lenguaje digno; No debería ser fantásticamente bueno. Brand hará el resto.
Por último, pero no menos importante, Rust
Déjame recordarte nuevamente que esta es solo mi opinión. Creo que Rust enfrenta algunos problemas interesantes:
- Personalidad desarmoniosa. Después de leer una cierta cantidad de código de Rust, aparecen anécdotas como "Dude perdió días de piernas balanceándose", ilustradas por cómics con personas con el torso y las piernas cruzadas (traducción aprox. En ruso, "Coloso en pies de barro", pero inexacto) Rust pone La administración de memoria precisa y segura es lo primero y representa el centro del mundo. De repente, esto rara vez es un área problemática, lo que lleva al hecho de que una gran parte de la planificación y la codificación se dedica, de hecho, al trabajo administrativo (que los idiomas con GC se automatizan sin mirar). La reutilización segura y predefinida de la memoria es una tarea seria, pero no la única, o al menos no la más importante del programa. Como resultado, Rust gasta una cantidad desproporcionada de recursos de diseño de lenguaje solo en eso. Sería interesante ver cómo Rust se hincha por otros aspectos del lenguaje; la única opción es expandir el lenguaje, pero la pregunta es cuánta abstracción puede ayudar con la desagradable necesidad de controlar los recursos en todos los niveles.
- Sintaxis ajena. La sintaxis de Rust es diferente [de todas], pero no existe una ventaja obvia en tal exotismo. Esto molesta a las personas que provienen de idiomas de la familia Algol, que tienen que lidiar con una sintaxis radicalmente diferente, además de la necesidad de administrar manualmente toda la contabilidad con recursos.
Las bonificaciones 10x de Rust son:
- 10 veces los mejores teóricos. De estos tres, solo Rust tiene teóricos de clase mundial en el desarrollo de un lenguaje de codificación. Esto se puede ver en la precisión de la descripción técnica del lenguaje y en la profundidad del enfoque técnico.
- 10 veces más seguridad que otros idiomas del sistema. Por supuesto, esto debería estar aquí, solo podemos debatir el costo de este enfoque.
- 10 veces el mejor PR (PR, publicidad, aprox. Por persona) Hubo un período bastante largo en que Rust era el favorito de la comunidad, lo que no podía confundirse: para cualquier problema, Rust tenía una solución o tenía que obtenerla con el lanzamiento de 1.0. La realidad del lanzamiento de 1.0 interrumpió esta luna de miel y estuvo marcada (en mis mediciones y expectativas) por una fuerte disminución en el interés general, aunque estos factores tienden a prolongarse. Además, al final, Rust es un lenguaje decente con logros reales, y está bien posicionado para convertir esta exageración prolongada en un mercado estable.
Brevemente
Si uno de estos lenguajes es capaz de reemplazar gradualmente C, C ++ o ambos lenguajes en los sistemas de software existentes, y si estos lenguajes se convertirán en prioridad para proyectos que hoy eligen C o C ++ por defecto, todo depende de la capacidad de estos lenguajes para usar sus ventajas y encuentre soluciones creativas a sus respectivos problemas.
Nota traductor.Perdón por el artículo anterior, acabo de encontrarlo al final de mi serie sobre programación confiable, y me pareció lo suficientemente divertido como para citarlo. En RuNet, sin embargo, no se encontró una traducción, y de hecho una discusión completa.