5 puntos por GN⁺ 2026-02-24 | 1 comentarios | Compartir por WhatsApp
  • El proyecto del navegador Ladybird adoptó Rust como lenguaje con seguridad de memoria para reemplazar C++ y aprovecha herramientas de IA en el proceso de transición
  • Antes evaluó Swift, pero cambió de rumbo hacia Rust por sus limitaciones de interoperabilidad con C++ y restricciones de plataforma
  • El primer objetivo de portabilidad fue LibJS, el motor de JavaScript, y se realizó una traducción dirigida manualmente con cientos de prompts usando Claude Code y Codex
  • En aproximadamente dos semanas se completaron 25 mil líneas de código Rust, y se verificó que tanto la salida como el rendimiento son completamente idénticos a la versión en C++
  • Por ahora, el proyecto mantendrá un esquema de desarrollo paralelo entre C++ y Rust, con planes de reforzar a largo plazo la seguridad y la mantenibilidad

Antecedentes de la adopción de Rust

  • Ladybird evaluó varios lenguajes para encontrar un lenguaje con seguridad de memoria que reemplace a C++
    • Swift fue descartado por la falta de interoperabilidad con C++ y por las limitaciones de soporte de plataforma fuera del ecosistema de Apple
  • Rust fue considerado un lenguaje con un ecosistema maduro para programación de sistemas y ya familiar para muchos de los contribuidores
  • En 2024 se había pospuesto su adopción por la falta de encaje de Rust con un modelo de OOP al estilo C++, pero después se decidió reintroducirlo por motivos de seguridad y madurez del ecosistema
  • Tomando como referencia los casos de Firefox y Chromium, se concluyó que Rust también era adecuado para Ladybird

Proceso de portabilidad de LibJS

  • El primer objetivo de la transición fue LibJS, el motor de JavaScript de Ladybird
    • Sus componentes independientes como lexer, parser, AST y bytecode generator, junto con la cobertura de pruebas basada en test262, lo hacían un buen punto de partida
  • Para la portabilidad se usaron Claude Code y OpenAI Codex
    • No fue una generación automática, sino una traducción guiada por humanos, decidiendo directamente el orden de la portabilidad y la estructura del código
    • Se dieron instrucciones detalladas mediante cientos de prompts, y después se realizó validación de código y detección de errores con distintos modelos

Resultados y verificación

  • El objetivo era que la salida de los pipelines de C++ y Rust fuera idéntica byte por byte
  • Se completaron unas 25,000 líneas de código Rust en dos semanas, acortando un trabajo que habría tomado varios meses
  • El AST y el bytecode son completamente idénticos, y no hubo degradación de rendimiento en pruebas ni en benchmarks de JS
  • Se verificó la coincidencia de resultados durante la navegación web con pruebas lockstep que ejecutan simultáneamente los pipelines de C++ y Rust
  • El código actual mantiene la forma traducida desde C++ y hasta imita exactamente los patrones de asignación de registros
    • Esto se debe a que la prioridad absoluta es garantizar compatibilidad con el pipeline de C++
    • Más adelante, cuando llegue el momento de retirar el pipeline de C++, se planea simplificar y depurar el código Rust

Planes a futuro

  • La transición a Rust avanzará como un trabajo paralelo, no como la dirección principal del desarrollo del proyecto
  • El código en C++ y Rust coexistirá, manteniendo límites claros de interoperabilidad
  • El orden y el alcance de la portabilidad serán gestionados por el equipo central, y los contribuidores externos necesitarán coordinación previa
  • A largo plazo, se impulsará una transición gradual con el objetivo de mejorar la seguridad y la mantenibilidad
  • Aunque reconocen que la decisión puede ser polémica, la evalúan como la elección correcta para el futuro de Ladybird

1 comentarios

 
GN⁺ 2026-02-24
Opiniones en Hacker News
  • La parte más inteligente de este proyecto fue exigir una salida idéntica byte por byte
    Gracias a eso pudieron ejecutar en paralelo el pipeline viejo y el nuevo, comparar el diff y detectar de inmediato los bugs introducidos durante la traducción
    Muchas reescrituras fracasan porque la gente intenta “mejorar” cosas durante el port, y termina persiguiendo bugs fantasma causados por diferencias entre la versión vieja, la nueva, o simplemente por cambios de comportamiento
    Aunque al principio la versión traducida de C++ a Rust se vea rara, no pasa nada. Más adelante, cuando retiren por completo la parte en C++, podrán volverla gradualmente más idiomatic

    • Hacer un port es un buen momento para mejorar muchas cosas, pero no para agregar funcionalidades nuevas
      Se puede refactorizar, optimizar y documentar siempre que la salida se mantenga igual
      Creo que leer el código y documentarlo al mismo tiempo es el mejor momento para hacerlo. En un proyecto popular como Ladybird, documentar es una forma directa de acelerar el desarrollo
    • Ojalá hubiera más ports puros hechos de esta manera
      Antes el costo de migración era tan alto que se justificaba con el típico “ya que estamos, aprovechemos para mejorar”, pero al final eso solo llevaba a perseguir más bugs fantasma
    • Me gusta muchísimo este enfoque. Hace unos días vi un artículo escrito desde la perspectiva de pruebas y validación, y sorprende verlo aplicado a un proyecto tan complejo
    • Yo también convertí varias veces frameworks web de esta forma. Primero hacía que la nueva implementación reprodujera exactamente la cadena de salida HTTP, y luego borraba por completo la versión anterior
    • Si tienes una buena suite de pruebas, este enfoque funciona muchísimo mejor. Supongo que Ladybird también la tiene
  • Usaron Claude Code y Codex para traducir código C++ a Rust
    No fue algo totalmente automático; hubo dirección humana y ajustes mediante cientos de prompts pequeños
    Desde el principio impusieron el requisito de que la salida de ambos pipelines fuera idéntica byte por byte, y al final completaron 25,000 líneas de código Rust en solo dos semanas
    Tanto el AST como el bytecode coincidieron, y lograron 0 regresiones
    Creo que esta sí es la forma correcta de usar IA para ports entre lenguajes

    • Yo antes migré con Claude un script de Perl roto a Rust
      En 80 minutos analizó la estructura de Drupal, restauró el diseño original y la organización modular tal cual, e incluso implementó plugins personalizados
      Ahora se rumora que ese sitio ya pasó por WordPress, ProcessWire, Node.js y ahora hasta Next.js
    • Es una lástima que las empresas de IA no se enfoquen más en este tipo de uso colaborativo
      Yo no quiero “código terminado con un solo prompt”, sino una herramienta que, a lo largo de sesiones largas con IA, amplifique la inteligencia humana (IA)
      Pero probablemente el mercado sea pequeño porque este tipo de herramientas solo las puede aprovechar gente con conocimientos de desarrollo
    • Yo también estoy aprendiendo Rust y uso en Claude una habilidad llamada “teach”
      Claude no escribe el código directamente; solo da pistas y hace review
      Por las características del lenguaje, Rust no se presta tanto a improvisar, y este enfoque me resulta muy satisfactorio
    • Yo también uso Claude así. No como “la IA lo hace todo”, sino como socio para diseño, review y pruebas
    • Antes migré con Claude un script bash complejo a golang, y la velocidad y la estabilidad mejoraron muchísimo
      Ahora incluso tiene una versión wasm que corre en el navegador
      No implementé yo mismo la parte de criptografía, así que no hay de qué preocuparse
  • La noticia del cambio a Rust es interesante, pero sorprende porque antes el equipo de Ladybird tenía una postura bastante marcada de “anti-Rust hype”
    Aun así, si se pasan a Rust, probablemente me será mucho más fácil contribuir

    • A mí también me gusta Rust, pero a veces el entusiasmo excesivo por el lenguaje me cansa
      Un lenguaje no deja de ser una herramienta, y no creo que haga falta construir una identidad alrededor de uno en particular
    • No me gusta Rust, pero a veces pragmáticamente es la mejor opción
    • Hay un enlace que muestra que Ladybird ya no está centrado en C++/Swift
    • Me inquieta un poco que la dirección del lenguaje cambie tan seguido. Eso puede afectar la continuidad del proyecto
  • Andreas es un gran ingeniero y alguien con instinto empresarial
    Impresiona cómo llevó un proyecto hobby a algo con perfil industrial
    Aun así, un cambio de lenguaje tan rápido da un poco de inquietud

    • Andreas no es solo un hombre de negocios, sino el ingeniero que creó Serenity OS prácticamente solo durante años
      Yo lo veo como el resultado natural del crecimiento del proyecto
    • Según él, la decisión de Swift también fue una elección racional tomada después de probar directamente varios lenguajes
    • Como referencia, antes trabajó en el equipo del motor Safari de Apple
    • Aun así, todavía queda la duda de si esto realmente llevará a un navegador nuevo de verdad
    • Dijiste que te da “inquietud”; me da curiosidad saber exactamente qué aspecto te preocupa
  • Me preocupa que eso de “es código Rust poco idiomático, pero luego lo vamos a limpiar” insinúe otra reescritura más
    Cuando una startup cambia de lenguaje, muchas veces se ve como una señal de alerta

    • Aun así, C++ y Rust son ambos lenguajes multiparadigma, así que se puede trasladar una estructura parecida
    • Esto me recuerda la “trampa de la reescritura” de Joel on Software
      Si el desarrollo de la nueva versión y el de las funciones existentes avanzan en paralelo, aparece una competencia por la velocidad, y la nueva versión puede no alcanzar a la anterior
    • Pero Ladybird no es una startup sino un proyecto abierto, así que la comparación no es exacta
      Linux, PHP y musl libc también han pasado por reescrituras completas varias veces
    • Yo, en una situación así, probablemente seguiría usando Firefox
    • Pasarse semanas haciendo un port con LLM sí parece una decisión algo extraña
  • Ahora que la IA ya es algo generalizado, el cálculo de “reescribir todo en otro lenguaje” cambió por completo
    Sobre todo si tienes una suite de pruebas, el riesgo baja muchísimo
    Estamos en una época en la que la importancia de las pruebas es 10 veces mayor

    • Yo también hice una librería CLI en Python para un proyecto personal usando IA
      Como pude probar rápido distintas UI con Streamlit, Shiny y Dash, el prototipado se volvió muy entretenido
    • A largo plazo, a medida que la IA mejore, creo que el significado mismo de los lenguajes de programación va a perder peso
      Ya hay proyectos donde una combinación de low-code + agent alcanza perfectamente
  • La parte de “dejamos la revisión de código en manos de la IA” suena inquietante
    Los modelos tienen límites para detectar errores lógicos

    • Aun así, si al final lograron 0 regresiones + salida idéntica en 65 mil pruebas, tampoco se puede descartar del todo
      Pero la clave será si después esa “limpieza (cleanup)” realmente ocurre
    • Los revisores humanos tampoco son perfectos. Si revisas desde varias perspectivas, tanto la IA como las personas pueden detectar errores distintos
    • Esa es precisamente un área que debería validar la suite de pruebas
    • Pero también hay gente que no quiere lidiar con código Rust no idiomático generado por IA
      Si dependes del código hecho por IA, puede formarse un círculo vicioso de dependencia de la IA cada vez mayor
  • Que el proyecto desarrolle en paralelo C++ y Rust parece ineficiente
    Me pregunto si no sería mejor unificarlo todo en un solo lenguaje con seguridad de memoria

    • Pero una base de código mixta como la de Firefox también es perfectamente viable
      Mientras cada componente esté escrito en un solo lenguaje, no hay problema
    • Si intentan una transición completa, la pérdida de momentum puede ser tan grande que el proyecto se detenga
    • También se puede lograr seguridad de memoria usando un subconjunto estricto de C++
  • Cuando adoptaron Swift en 2024, Andreas publicó unos tuits sobre Rust
    Dijo que Rust es excelente para programas de ejecución corta, pero que resulta incómodo para programas de larga ejecución que mantienen grafos de objetos complejos
    También agregó que la comunidad le parecía tóxica
    Enlace al tuit relacionado

    • ¿Habrá cambiado de opinión? Tal vez ni siquiera hacía falta reemplazar C++ desde el principio
    • Comparto la percepción de una atmósfera excluyente en la comunidad de Rust
    • Quizá la transición a Rust impulsada por IA se hizo por exigencia de patrocinadores
  • Me pregunto si ese código Rust no idiomático podría terminar como deuda técnica en el futuro

    • El riesgo está sobre todo en la etapa de limpieza. Los patrones de punteros al estilo C++ pueden chocar con las reglas de ownership de Rust
      El proyecto Servo también pasó por problemas así, aunque en el proceso logró detectar bugs potenciales
    • No es que C++ fuera el problema en sí, sino que se pasaron a Rust por seguridad de memoria
    • Andreas ya había mencionado antes problemas de seguridad del GC en el runtime de JS y que quería un lenguaje más seguro
      El cambio a Rust parece una decisión madura alineada con esa filosofía