Would memory safety greatly benefit the platform?
Performance could also see an improvement.
I also think the never ending discourse bugs could be reduced with Rust.
Will discourse as a modern platform survive without being rewritten in Rust?
With the ease and efficiency of Rust development labour shouldn’t be an issue.
Thoughts?
Are you volunteering to port it? 
Jeff wrote a blog article about why Ruby:
Probably written prior to Rust (yes), but will surely provide some justification.
Sure but Microsoft is also going the way of rust.
Jeff surely knows by now Rust is superior.
It could be done in 12-16 days with some blood sweat and tears. He’s a bit young to retire yet.
I’m pretty sure that it takes at least 12-16 days to upgrade to a new version of Ruby or postgres. There are about 60K lines of Ruby.
What would replace Rails?
Microsoft has very deep pockets and resources.
One you would need to rewrite core and also all plugins.
This would also mean the road map would need to be put on hold.
Could it be done sure. But you also need to test and debug.
Current customers of discourse would likely have their sites break.
Imho if the team were to work on this. It would need to be worked on as a fork with beta testers over a long period of time. Forking plugins for say Discourse2 Meta.
So not likely reasonable at this time to divide resources to maintain current ruby & porting.
Sorry is that a typo, did you mean months?
Can you point to a single project of similar size and scope to Discourse where such a port has been achieved in such a short timeframe?
I bet the process David Megginson outlines sounds awfully familiar:
Elite (guru) developers notice too many riff-raff using their current programming language, and start looking for something that will distinguish them better from their mediocre colleagues.
Elite developers take their shopping list of current annoyances and look for a new, little-known language that apparently has fewer of them.
Elite developers start to drive the development of the new language, contributing code, writing libraries, etc., then evangelize the new language. Sub-elite (senior) developers follow the elite developers to the new language, creating a market for books, training, etc., and also accelerating the development and testing of the language.
Sub-elite developers, who have huge influence (elite developers tend to work in isolation on research projects rather than on production development teams), begin pushing for the new language in the workplace.
The huge mass of regular developers realize that they have to start buying books and taking courses to learn a new language.
Elite developers notice too many riff-raff using their current programming language, and start looking for something that will distinguish them better from their mediocre colleagues.
Who cares what technology you use, as long as it works, and both you and your users are happy with it?
That’s the beauty of new things: there’s always a new one coming along. Don’t let the pursuit of new, shiny things accidentally become your goal. Avoid becoming a magpie developer. Be selective in your pursuit of the shiny and new, and you may find yourself a better developer for it.
Wow. Hope you were just being humorous.
Could always ask here, they might know 
No, why do you say that?
Perhaps because Rust enthusiasts are using Discourse? Or maybe if porting would take only two workingdays they would already done it, just for sport and fun?
I am so stunned by this thread that I won’t need my daily medication today 
Discourse is memory-safe. Ruby is a memory safe language; all garbage collected languages are. The main difference to Rust in this regard is when the safety checks are performed; Rust does them at compile time, Ruby does them at runtime.
Rust tackles only a few classes of errors, mainly those caused by C++'s lack of garbage collection. It certainly is cool that they found a way to do that while maintaining the performance benefits theoretically possible with pointers, but it by no means prevents the sort of bugs you’d see as a user. For example, if I use < when I meant <=, and get an off-by-one error as a result, Rust won’t save me. If I forget to spawn a success message after an action is complete, Rust won’t save me.
What actually does prevent bugs is the sort of test-driven development Discourse already deploys. There are very few projects which you can just deploy straight from master and expect them to be stable, but Discourse is one of them.
“modern platforms” are popping up left, right and center using JavaScript for backend and frontend. Ruby is 2 places behind Rust in popularity (Kotlin is between the two), so it’s hardly a rare language at the moment. Sure, in another 10 years things may look differently, but even a rewrite to Rust would be tech debt in 10 years.
It’s hard to convey just how naive that statement is, which is why everyone is laughing at the idea. I’ve seen my devs refactor code for 3 years now, and they’re only just ready to start porting from wxWidgets/ShuttleGUI to Qt/QML - which, for context, is a migration from C++ to C++, just a different UI toolkit. It’s just hard to transform code while also ensuring that the behavior stays identical. 12-16 days is the time you’d need just for planning before anyone gets started probably.
I may not be the most productive developer but it took me 3 weeks just to migrate the Poll plugin to Glimmer Components (which isn’t even a language change!)
I don’t know about Rust or Ruby but I feel that over the last year the team at CDCK did an amazing job with the frontend rewrite to Ember 5 and Glimmer components. It actually went together with a re-build of the frontend with standardized components and styles. I’m impressed about the coordinated effort and purpose that was put behind this 
So to me they made a great decision about what to modernize because it made a huge difference in keeping Discourse modern and a joy to use!
Manuel, with respect to styles (CSS), is this documented anywhere? What do you consider as the main changes? Do you feel the structure of discourse CSS code is less easier to work with now ?
With respect to styles the main changes I see are that
To me this makes customizing Discourse so much easier and accurate. But I guess it depends on your working knowledge. I could imagine there’s a steeper learning curve now for folks that just want to make some adjustments and are not that familiar with CSS.
About documentation, you can check out the Styleguide and I guess the easiest way to scan which custom properties are available is using the dev tools of your browser. Documentation is also being re-worked. Right now there’s two sections in Developer Guides, Themes & Components and Interface. But there’s a huge range between just wanting to declare some custom styles and authoring a component. Some of this is probably buried too deep between developer topics? 
if you are going to port it to another language, I expect Go might be a better option. One of the advantages that I expect web admins might appreciate is the lack of rebuilds, since it ships static binaries. That also makes containers mostly unnecessary as well. In fact one feature that appears to be sorely needed with Discourse, is the ability to build the app on a machine different from your web server. Right now with the minimal, cheapest VPS, it takes nearly 10 minutes to build. This would likely be a fraction of the time if I was able to build locally on my workstation then ship the final binaries over to the web server to run. Keep in mind that languages such as Go allow you to trivially cross-compile, so you could build on your M1 Mac and then deploy on an x86 web server (or even just build, ship, and deploy ARM)
I suspect currently the greatest time taken during build is the front end compilation, so “Go or no” is moot wrt build time.
Neither Rust nor Go would be replacing the front end …
(PS I love Go too … )