Haciendo eco de los últimos dos años de evangelismo de Rust y hastío de C/C++, Google informa que Rust brilla en producción, hasta el punto de que sus desarrolladores son dos veces más productivos usando el lenguaje en comparación con C++. Hablando en la Conferencia Rust Nation UK en Londres esta semana, Lars Bergstrom, director de ingeniería de Google, que trabaja en bibliotecas y herramientas de la plataforma Android, describió la experiencia del titán web al migrar proyectos escritos en Go o C++ al lenguaje de programación Rust. Bergstrom dijo que si bien Dropbox en 2016 y Figma en 2018 ofrecieron los primeros relatos de reescritura de código en Rust seguro para la memoria (y las dudas sobre la productividad y el lenguaje han disminuido), persisten las preocupaciones sobre su confiabilidad y seguridad. «Incluso hace seis meses, ésta fue una conversación realmente difícil», dijo. «Iría y hablaría con la gente y me dirían: ‘Espera, espera, tienes una palabra clave ‘insegura’. Eso significa que todos deberíamos escribir C++ hasta que el Universo muera por calor'». Pero ha habido un cambio en Bergstrom argumentó que existe conciencia en todo el ecosistema de desarrollo de software sobre los desafíos que plantea el uso de lenguajes que no son seguros para la memoria. Estos mensajes provienen ahora de autoridades gubernamentales de EE. UU. y otras naciones que comprenden el papel que desempeña el software en la infraestructura crítica. La razón es que la mayoría de las vulnerabilidades de seguridad en grandes bases de código pueden atribuirse a errores de seguridad de la memoria. Y dado que el código Rust puede evitar en gran medida, si no totalmente, tales problemas cuando se implementa correctamente, la seguridad de la memoria ahora se parece mucho a una cuestión de seguridad nacional. En septiembre de 2022, el CTO de Microsoft Azure, Mark Russinovich, argumentó que los proyectos de software que podrían haberse iniciado en C/C++ deberían usar Rust en su lugar. Esa recomendación ahora se extiende más allá de los proyectos nuevos y exige reelaborar el código antiguo escrito en lenguajes que no son seguros para la memoria. A principios de este año, Microsoft hizo un llamado a los desarrolladores para que lo ayudaran a portar su propio código C# a Rust. Y el proyecto Prossimo del Internet Security Research Group (ISRG) ha estado reescribiendo elementos centrales de código abierto de bibliotecas críticas (por ejemplo, NTP, DNS, TLS) en Rust por el bien de la seguridad de la memoria. Ha habido oposición por parte del creador de C++, Bjarne Stroustrup, y otros. En respuesta a un memorando de la NSA de noviembre de 2022 [PDF] instando a la seguridad de la memoria, argumentó Stroustrup [PDF] que C++, con las herramientas adecuadas, puede igualar las garantías de seguridad de la memoria de Rust «a una fracción del costo de un cambio a una variedad de lenguajes novedosos ‘seguros'». Y en febrero, cuando la Oficina del Director Nacional Cibernético de EE. UU. publicó un informe [PDF] En cuanto al software de seguridad, algunos de los que dejaron comentarios públicos observaron que la seguridad de la memoria es un subconjunto de desafíos más amplios de seguridad del software y no debe verse como una respuesta a todo. El Instituto de Ingeniería de Software de Carnegie Mellon, por ejemplo, enfatizó que todos los lenguajes de programación tienen compensaciones y la elección del lenguaje de programación debe depender de si es adecuado para su propósito. «La mayoría de los lenguajes seguros para la memoria no priorizan el rendimiento de la sincronización y, por lo tanto, no son apropiados para casos de uso que tienen requisitos estrictos de rendimiento y sincronización», afirmó el grupo de software. «Además, como ocurre con cualquier lenguaje de programación, los desarrolladores deben aprender la mecánica correcta del lenguaje, como la sintaxis, la semántica, las construcciones, los modismos y las herramientas. De lo contrario, el resultado podría ser una compensación involuntaria de menos vulnerabilidades relacionadas con la memoria por más vulnerabilidades. o defectos de otro tipo.» Si bien la seguridad del software es más que la seguridad de la memoria, la ventaja de costos que Stroustrup afirma que se puede lograr si se mantiene la infraestructura C++ existente ahora enfrenta ejemplos contrarios de los que adoptan Rust como Google. Sin pérdida de productividad, todo lo contrario. En Chocolate Factory, convertir el código Go, que se considera seguro para la memoria pero no tan eficaz, en Rust ha mostrado beneficios notables. «Cuando reescribimos los sistemas de Go into Rust, descubrimos que se necesita aproximadamente la misma cantidad de tiempo para construirlo», dijo Bergstrom. «Es decir, no hay pérdida de productividad al pasar de Go a Rust. Y lo interesante es que sí vemos algunos beneficios. «Así que vemos un uso reducido de memoria en los servicios que hemos movido de Go… y «Vemos una disminución en la tasa de defectos con el tiempo en aquellos servicios que han sido reescritos en Rust, lo que aumenta la corrección». Más significativa, dijo Bergstrom, es la comparación de las reescrituras de código C++ en Rust. «En todos los casos hemos visto una disminución en más del doble de la cantidad de esfuerzo requerido tanto para construir los servicios en Rust como para mantener y actualizar esos servicios escritos en Rust», dijo. «Y eso es algo realmente enorme para nosotros porque el código C++ es muy costoso. Estos son equipos grandes. Es mucho trabajo. Hay mucho riesgo». Bergstrom dijo que Google tiene una migración similar en marcha para trasladar a los desarrolladores de Java a Kotlin y que el tiempo que lleva volver a capacitar a los desarrolladores en ambos casos (de Java a Kotlin y de C++ a Rust) ha sido similar. Es decir, en En dos meses, alrededor de un tercio de los desarrolladores sienten que son tan productivos en su nuevo lenguaje como en el antiguo. Y en aproximadamente cuatro meses, la mitad de los desarrolladores dice lo mismo, según encuestas internas anónimas. Un poco más de la mitad de sus desarrolladores dicen que Rust es más fácil de revisar, según Bergstrom.»Cuando analizamos por qué es así», dijo, «llegamos a la pregunta más increíble de la encuesta, la que nos dejó a todos boquiabiertos». , que es la confianza que las personas tienen en la exactitud del código Rust que están viendo, entonces, en comparación con el código en otros lenguajes, ¿qué tan seguro se siente de que el código Rust de su equipo es correcto?» La respuesta, dijo Bergstrom. «Es un número enorme», dijo. «No pude lograr que el 85 por ciento de esta sala estuviera de acuerdo en que nos gustan los M&M’s. El ocho y cinco por ciento de las personas cree que es más probable que su código Rust sea correcto que el otro código dentro de su sistema. … He pasado por más de una encuesta de idiomas en mi vida y nunca antes había visto ese tipo de números.» ®

Source link