Discourse è memory-safe. Ruby è un linguaggio memory-safe; tutti i linguaggi con garbage collection lo sono. La differenza principale rispetto a Rust, a questo riguardo, è quando vengono eseguiti i controlli di sicurezza; Rust li esegue in fase di compilazione, Ruby li esegue in fase di runtime.
Rust affronta solo poche classi di errori, principalmente quelli causati dalla mancanza di garbage collection in C++. È certamente fico che abbiano trovato un modo per farlo mantenendo i benefici prestazionali teoricamente possibili con i puntatori, ma ciò non impedisce affatto il tipo di bug che vedresti come utente. Ad esempio, se uso < quando intendevo <=, e di conseguenza ottengo un errore di off-by-one, Rust non mi salverà. Se dimentico di generare un messaggio di successo dopo che un’azione è stata completata, Rust non mi salverà.
Ciò che in realtà previene i bug è il tipo di sviluppo guidato dai test che Discourse già implementa. Ci sono pochissimi progetti che puoi distribuire direttamente da master e aspettarti che siano stabili, ma Discourse è uno di questi.
Le “piattaforme moderne” stanno spuntando ovunque, a destra e a sinistra, usando JavaScript sia per il backend che per il frontend. Ruby è 2 posizioni dietro Rust in popolarità (Kotlin è tra le due), quindi al momento non è affatto un linguaggio raro. Certo, tra 10 anni le cose potrebbero essere diverse, ma anche una riscrittura in Rust sarebbe debito tecnico tra 10 anni.
È difficile trasmettere quanto sia ingenua questa affermazione, motivo per cui tutti ridono all’idea. Ho visto i miei sviluppatori refactorizzare codice per 3 anni ormai, e sono appena pronti per iniziare la migrazione da wxWidgets/ShuttleGUI a Qt/QML - che, per contesto, è una migrazione da C++ a C++, solo un diverso toolkit UI. È semplicemente difficile trasformare il codice garantendo al contempo che il comportamento rimanga identico. 12-16 giorni è il tempo che probabilmente servirebbe solo per la pianificazione prima che chiunque inizi.