La sicurezza della memoria andrebbe a grande beneficio della piattaforma?
Anche le prestazioni potrebbero vedere un miglioramento.
Penso anche che i bug infiniti di discourse potrebbero essere ridotti con Rust.
Discourse, come piattaforma moderna, sopravvivrà senza essere riscritto in Rust?
Con la facilità e l’efficienza del lavoro di sviluppo in Rust, il personale non dovrebbe essere un problema.
Opinioni?
Ti stai offrendo volontario per portarlo? 
Jeff ha scritto un articolo del blog sul perché Ruby:
Probabilmente scritto prima di Rust (sì), ma fornirà sicuramente qualche giustificazione.
Certo, ma anche Microsoft sta andando nella direzione di Rust.
Jeff sicuramente sa ormai che Rust è superiore.
Potrebbe essere fatto in 12-16 giorni con un po’ di sangue, sudore e lacrime. È un po’ troppo giovane per andare in pensione.
Sono abbastanza sicuro che ci vogliano almeno 12-16 giorni per l’aggiornamento a una nuova versione di Ruby o postgres. Ci sono circa 60.000 righe di Ruby.
Cosa sostituirebbe Rails?
Microsoft ha tasche e risorse molto profonde.
Uno richiederebbe la riscrittura del core e anche di tutti i plugin.
Ciò significherebbe anche che la roadmap dovrebbe essere messa in attesa.
Potrebbe essere fatto, certo. Ma è anche necessario testare e fare il debug.
I clienti attuali di Discourse probabilmente vedrebbero i loro siti bloccarsi.
IMHO se il team dovesse lavorare su questo. Dovrebbe essere lavorato come un fork con beta tester per un lungo periodo di tempo. Forking di plugin per, diciamo, Discourse2 Meta.
Quindi, non è probabile che sia ragionevole in questo momento dividere le risorse per mantenere il ruby corrente e il porting.
Scusa, è un errore di battitura, intendevi mesi?
Puoi indicare un singolo progetto di dimensioni e portata simili a Discourse in cui tale porting è stato realizzato in un lasso di tempo così breve?
Scommetto che il processo descritto da David Megginson suona terribilmente familiare:
Gli sviluppatori d’élite (guru) notano troppi scarti che usano il loro attuale linguaggio di programmazione e iniziano a cercare qualcosa che li distingua meglio dai loro colleghi mediocri.
Gli sviluppatori d’élite prendono la loro lista della spesa di fastidi attuali e cercano un nuovo linguaggio poco conosciuto che apparentemente ne abbia meno.
Gli sviluppatori d’élite iniziano a guidare lo sviluppo del nuovo linguaggio, contribuendo con codice, scrivendo librerie, ecc., quindi evangelizzano il nuovo linguaggio. Gli sviluppatori sub-élite (senior) seguono gli sviluppatori d’élite nel nuovo linguaggio, creando un mercato per libri, formazione, ecc., e accelerando anche lo sviluppo e il test del linguaggio.
Gli sviluppatori sub-élite, che hanno un’enorme influenza (gli sviluppatori d’élite tendono a lavorare in isolamento su progetti di ricerca piuttosto che su team di sviluppo di produzione), iniziano a spingere per il nuovo linguaggio sul posto di lavoro.
L’enorme massa di sviluppatori regolari si rende conto che devono iniziare a comprare libri e seguire corsi per imparare un nuovo linguaggio.
Gli sviluppatori d’élite notano troppi scarti che usano il loro attuale linguaggio di programmazione e iniziano a cercare qualcosa che li distingua meglio dai loro colleghi mediocri.
Chi se ne frega di quale tecnologia usi, purché funzioni, e sia tu che i tuoi utenti siate contenti?
Questa è la bellezza delle cose nuove: ce n’è sempre una nuova in arrivo. Non lasciare che la ricerca di cose nuove e scintillanti diventi accidentalmente il tuo obiettivo. Evita di diventare uno sviluppatore gazza ladra. Sii selettivo nella tua ricerca di ciò che è scintillante e nuovo, e potresti ritrovarti uno sviluppatore migliore per questo.
Wow. Spero tu stessi solo scherzando.
Potresti sempre chiedere qui, potrebbero saperlo 
No, perché lo dici?
Forse perché gli appassionati di Rust usano Discourse? O forse se il porting richiedesse solo due giorni lavorativi lo avrebbero già fatto, solo per sport e divertimento?
Sono così sbalordito da questo thread che oggi non avrò bisogno della mia medicina quotidiana :cuore:
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.
Potrei non essere lo sviluppatore più produttivo, ma mi ci sono volute 3 settimane solo per migrare il plugin Poll ai Glimmer Components (che non è nemmeno un cambio di linguaggio!)
Non so nulla di Rust o Ruby, ma sento che nell’ultimo anno il team di CDCK ha fatto un lavoro incredibile con la riscrittura del frontend in Ember 5 e Glimmer components. In realtà, è andato insieme a una ricostruzione del frontend con componenti e stili standardizzati. Sono impressionato dallo sforzo coordinato e dallo scopo che è stato messo dietro questo 
Quindi, per me, hanno preso un’ottima decisione su cosa modernizzare perché ha fatto un’enorme differenza nel mantenere Discourse moderno e piacevole da usare!
Manuel, per quanto riguarda gli stili (CSS), è documentato da qualche parte? Quali consideri le principali modifiche? Ritieni che la struttura del codice CSS di Discourse sia ora meno facile da usare?
Per quanto riguarda gli stili, le principali modifiche che vedo sono che
Per me questo rende la personalizzazione di Discourse molto più semplice e accurata. Ma immagino che dipenda dalla tua conoscenza pratica. Potrei immaginare che ora ci sia una curva di apprendimento più ripida per le persone che vogliono solo apportare alcune modifiche e non hanno molta familiarità con CSS.
Per quanto riguarda la documentazione, puoi consultare la Styleguide e immagino che il modo più semplice per scansionare quali proprietà personalizzate sono disponibili sia utilizzare gli strumenti per sviluppatori del tuo browser. Anche Documentation è in fase di rielaborazione. Al momento ci sono due sezioni in Documentation developer-guides, Themes & Components e Interface. Ma c’è un’enorme differenza tra voler semplicemente dichiarare alcuni stili personalizzati e creare un componente. Alcune di queste cose sono probabilmente sepolte troppo in profondità tra gli argomenti per sviluppatori? 
se hai intenzione di portarlo in un’altra lingua, mi aspetto che Go possa essere un’opzione migliore. Uno dei vantaggi che mi aspetto gli amministratori web potrebbero apprezzare è la mancanza di ricompilazioni, poiché distribuisce binari statici. Questo rende anche i container per lo più non necessari. Infatti, una funzionalità che sembra essere molto necessaria con Discourse è la capacità di costruire l’app su una macchina diversa dal tuo web server. Al momento, con il VPS minimo ed economico, ci vogliono quasi 10 minuti per costruire. Questo sarebbe probabilmente una frazione del tempo se fossi in grado di costruire localmente sulla mia workstation, quindi spedire i binari finali al web server per eseguirli. Tieni presente che linguaggi come Go ti permettono di cross-compilare in modo banale, quindi potresti costruire sul tuo Mac M1 e poi distribuire su un web server x86 (o anche solo costruire, spedire e distribuire ARM).
Sospetto che attualmente il tempo maggiore impiegato durante la build sia la compilazione del front-end, quindi “Go o no” è irrilevante per quanto riguarda il tempo di build.
Né Rust né Go sostituirebbero il front-end…
(PS Amo anche Go…)