¿La seguridad de la memoria beneficiaría enormemente a la plataforma?
El rendimiento también podría mejorar.
También creo que los errores interminables de discourse podrían reducirse con Rust.
¿Sobrevivirá discourse como plataforma moderna sin ser reescrita en Rust?
Con la facilidad y eficiencia de la mano de obra de desarrollo de Rust, el trabajo no debería ser un problema.
¿Opiniones?
¿Te ofreces a portarlo? 
Jeff escribió un artículo de blog sobre por qué Ruby:
Probablemente escrito antes que Rust (sí), pero seguramente proporcionará alguna justificación.
Claro, pero Microsoft también está adoptando Rust.
Jeff seguramente ya sabe que Rust es superior.
Podría hacerse en 12-16 días con sangre, sudor y lágrimas. Todavía es un poco joven para jubilarse.
Estoy bastante seguro de que se necesitan al menos 12 a 16 días para actualizar a una nueva versión de Ruby o postgres. Hay alrededor de 60.000 líneas de Ruby.
¿Qué reemplazaría a Rails?
Microsoft tiene bolsillos y recursos muy profundos.
Uno requeriría reescribir el núcleo y también todos los plugins.
Esto también significaría que el roadmap tendría que ponerse en pausa.
¿Se podría hacer? Claro. Pero también necesitas probar y depurar.
Los clientes actuales de Discourse probablemente verían sus sitios fallar.
En mi opinión, si el equipo fuera a trabajar en esto, tendría que hacerse como un fork con beta testers durante un largo período de tiempo. Crear forks de plugins para, por ejemplo, Discourse2 Meta.
Así que no es probable que sea razonable en este momento dividir los recursos para mantener el ruby actual y la portabilidad.
¿Disculpa, es un error tipográfico, quisiste decir meses?
¿Puedes señalar un solo proyecto de tamaño y alcance similar a Discourse donde se haya logrado un puerto de este tipo en un período de tiempo tan corto?
Creo que el proceso que describe David Megginson le sonará muy familiar:
Los desarrolladores de élite (gurús) notan que demasiada gente mediocre usa su lenguaje de programación actual y comienzan a buscar algo que los distinga mejor de sus colegas mediocres.
Los desarrolladores de élite toman su lista de compras de las molestias actuales y buscan un lenguaje nuevo y poco conocido que aparentemente tenga menos de ellas.
Los desarrolladores de élite comienzan a impulsar el desarrollo del nuevo lenguaje, contribuyendo con código, escribiendo bibliotecas, etc., y luego evangelizan el nuevo lenguaje. Los desarrolladores sub-élite (senior) siguen a los desarrolladores de élite hacia el nuevo lenguaje, creando un mercado de libros, capacitación, etc., y también acelerando el desarrollo y las pruebas del lenguaje.
Los desarrolladores sub-élite, que tienen una gran influencia (los desarrolladores de élite tienden a trabajar de forma aislada en proyectos de investigación en lugar de en equipos de desarrollo de producción), comienzan a impulsar el nuevo lenguaje en el lugar de trabajo.
La gran masa de desarrolladores regulares se da cuenta de que tienen que empezar a comprar libros y tomar cursos para aprender un nuevo lenguaje.
Los desarrolladores de élite notan que demasiada gente mediocre usa su lenguaje de programación actual y comienzan a buscar algo que los distinga mejor de sus colegas mediocres.
¿A quién le importa qué tecnología uses, siempre y cuando funcione, y tanto tú como tus usuarios estén contentos con ella?
Esa es la belleza de las cosas nuevas: siempre hay una nueva que viene. No dejes que la búsqueda de cosas nuevas y brillantes se convierta accidentalmente en tu objetivo. Evita convertirte en un desarrollador urraca. Sé selectivo en tu búsqueda de lo brillante y nuevo, y puede que te encuentres siendo un mejor desarrollador por ello.
Vaya. Espero que solo estuvieras bromeando.
Siempre se puede preguntar aquí, ¡quizás sepan! 
No, ¿por qué lo dices?
¿Quizás porque los entusiastas de Rust usan Discourse? ¿O tal vez si la portabilidad solo llevara dos días hábiles ya lo habrían hecho, solo por deporte y diversión?
Estoy tan atónito con este hilo que hoy no necesitaré mi medicación diaria 
Discourse es seguro en cuanto a memoria. Ruby es un lenguaje seguro en cuanto a memoria; todos los lenguajes con recolección de basura lo son. La principal diferencia con Rust a este respecto es cuándo se realizan las comprobaciones de seguridad; Rust las realiza en tiempo de compilación, Ruby las realiza en tiempo de ejecución.
Rust aborda solo unas pocas clases de errores, principalmente aquellos causados por la falta de recolección de basura de C++. Ciertamente es genial que hayan encontrado una manera de hacerlo manteniendo los beneficios de rendimiento teóricamente posibles con punteros, pero de ninguna manera previene el tipo de errores que verías como usuario. Por ejemplo, si uso < cuando quise <=, y como resultado obtengo un error de “off-by-one”, Rust no me salvará. Si olvido generar un mensaje de éxito después de que una acción se completa, Rust no me salvará.
Lo que realmente previene los errores es el tipo de desarrollo impulsado por pruebas que Discourse ya implementa. Hay muy pocos proyectos que puedas implementar directamente desde master y esperar que sean estables, pero Discourse es uno de ellos.
Las “plataformas modernas” aparecen a diestra y siniestra usando JavaScript para backend y frontend. Ruby está 2 lugares detrás de Rust en popularidad (Kotlin está entre los dos), por lo que apenas es un lenguaje raro en este momento. Claro, en otros 10 años las cosas pueden verse diferentes, pero incluso una reescritura a Rust sería deuda técnica en 10 años.
Es difícil transmitir cuán ingenua es esa afirmación, por eso todo el mundo se ríe de la idea. He visto a mis desarrolladores refactorizar código durante 3 años, y apenas están listos para comenzar a migrar de wxWidgets/ShuttleGUI a Qt/QML, lo que, para contextualizar, es una migración de C++ a C++, solo que con un kit de herramientas de interfaz de usuario diferente. Es simplemente difícil transformar código y al mismo tiempo garantizar que el comportamiento siga siendo idéntico. 12-16 días es el tiempo que probablemente necesitarías solo para la planificación antes de que alguien empiece.
Puede que no sea el desarrollador más productivo, pero tardé 3 semanas solo en migrar el plugin Poll a Glimmer Components (¡lo que ni siquiera es un cambio de idioma!).
No sé sobre Rust o Ruby, pero siento que durante el último año el equipo de CDCK hizo un trabajo increíble con la reescritura del frontend a Ember 5 y componentes Glimmer. De hecho, fue junto con una reconstrucción del frontend con componentes y estilos estandarizados. Estoy impresionado por el esfuerzo coordinado y el propósito que se puso detrás de esto 
Así que, para mí, tomaron una gran decisión sobre qué modernizar porque marcó una gran diferencia en mantener Discourse moderno y agradable de usar.
Manuel, con respecto a los estilos (CSS), ¿está documentado en alguna parte? ¿Qué consideras que son los cambios principales? ¿Crees que la estructura del código CSS de Discourse es ahora menos fácil de manejar?
Con respecto a los estilos, los principales cambios que veo son que
Para mí, esto hace que personalizar Discourse sea mucho más fácil y preciso. Pero supongo que depende de tu conocimiento práctico. Me imagino que ahora hay una curva de aprendizaje más pronunciada para las personas que solo quieren hacer algunos ajustes y no están tan familiarizadas con CSS.
Sobre la documentación, puedes consultar la Guía de estilos y supongo que la forma más fácil de escanear qué propiedades personalizadas están disponibles es usando las herramientas de desarrollador de tu navegador. Documentation también está siendo rediseñada. Ahora hay dos secciones en Documentation developer-guides, Temas y componentes e Interfaz. Pero hay una gran diferencia entre simplemente querer declarar algunos estilos personalizados y crear un componente. Es probable que parte de esto esté demasiado enterrado entre los temas de desarrollador. 
si vas a portarlo a otro idioma, creo que Go podría ser una mejor opción. Una de las ventajas que creo que los administradores web apreciarían es la falta de reconstrucciones, ya que envía binarios estáticos. Eso también hace que los contenedores sean en su mayoría innecesarios. De hecho, una característica que parece ser muy necesaria con Discourse es la capacidad de compilar la aplicación en una máquina diferente a tu servidor web. Ahora mismo, con el VPS mínimo y más barato, se tarda casi 10 minutos en compilar. Esto probablemente sería una fracción del tiempo si pudiera compilar localmente en mi estación de trabajo y luego enviar los binarios finales al servidor web para ejecutarlos. Ten en cuenta que lenguajes como Go te permiten compilar de forma cruzada de manera trivial, por lo que podrías compilar en tu Mac M1 y luego desplegar en un servidor web x86 (o incluso simplemente compilar, enviar y desplegar ARM).
Sospecho que actualmente el mayor tiempo empleado durante la compilación es la compilación del front-end, por lo que “Ir o no ir” es irrelevante con respecto al tiempo de compilación.
Ni Rust ni Go reemplazarían el front-end…
(PD: También me encanta Go…)