Существенно ли улучшит безопасность памяти платформа?
Производительность также может возрасти.
Я также считаю, что бесконечные споры в Discourse можно было бы сократить с помощью Rust.
Сможет ли Discourse как современная платформа выжить без переписывания на Rust?
Благодаря простоте и эффективности разработки на Rust, трудозатраты не должны стать проблемой.
Что думаете?
Ты вызываешься перенести его? 
Джеф написал статью в блоге о том, почему Ruby:
Скорее всего, она была написана до появления Rust (да), но, безусловно, даст некоторые обоснования.
Конечно, но Microsoft тоже движется в сторону Rust.
Джефф, несомненно, уже знает, что Rust превосходит остальные.
Это можно было бы сделать за 12–16 дней, ценой больших усилий и нервов. Он ещё слишком молод, чтобы уходить на пенсию.
Я почти уверен, что обновление до новой версии Ruby или PostgreSQL займёт как минимум 12–16 дней. В коде около 60 тысяч строк на Ruby.
Чем можно заменить Rails?
У Microsoft очень глубокие карманы и огромные ресурсы.
Вам пришлось бы переписать ядро и все плагины.
Это также означало бы, что дорожную карту пришлось бы отложить.
Конечно, это можно сделать. Но также потребуется тестирование и отладка.
У текущих клиентов Discourse, скорее всего, сайты перестанут работать.
На мой взгляд, если команда возьмется за это, то работать над этим нужно как над форком с бета-тестированием в течение длительного периода времени. Форк плагинов, например, для Discourse2 Meta.
Поэтому в настоящее время маловероятно, что разумно разделять ресурсы для поддержки текущего Ruby и портирования.
Извините, это опечатка? Вы не имели в виду месяцы?
Можете указать хотя бы один проект аналогичного масштаба и сложности, что и Discourse, где такой перенос был выполнен в столь сжатые сроки?
Я уверен, что процесс, описанный Дэвидом Меггинсоном, кажется вам очень знакомым:
Элитные (гуру) разработчики замечают, что их текущий язык программирования используют слишком много «пёстрых» людей, и начинают искать что-то, что лучше отличит их от посредственных коллег.
Элитные разработчики берут свой список текущих раздражителей и ищут новый, малоизвестный язык, который, по их мнению, лишён большей части этих недостатков.
Элитные разработчики начинают активно развивать новый язык: пишут код, создают библиотеки и т. д., а затем активно продвигают его. Субэлитные (старшие) разработчики следуют за элитными к новому языку, создавая рынок для книг, обучения и т. п., а также ускоряя развитие и тестирование языка.
Субэлитные разработчики, обладающие огромным влиянием (элитные разработчики обычно работают изолированно над исследовательскими проектами, а не в производственных командах), начинают продвигать новый язык на рабочих местах.
Огромная масса обычных разработчиков понимает, что им нужно начать покупать книги и проходить курсы, чтобы освоить новый язык.
Элитные разработчики замечают, что их текущий язык программирования используют слишком много «пёстрых» людей, и начинают искать что-то, что лучше отличит их от посредственных коллег.
Кому какое дело, какую технологию вы используете, если она работает и вы, и ваши пользователи довольны?
В этом и прелесть новых вещей: всегда найдётся что-то новенькое. Не позволяйте погоне за новым и блестящим случайно стать вашей главной целью. Избегайте превращения в разработчика-сороку. Будьте избирательны в погоне за новизной и блеском, и, возможно, это сделает вас лучшим разработчиком.
Вау. Надеюсь, ты просто шутил.
Всегда можно спросить здесь, возможно, они знают 
Нет, почему ты так говоришь?
Возможно, потому что энтузиасты Rust используют Discourse? Или, может быть, если бы перенос занял всего два рабочих дня, они бы уже сделали это просто ради спорта и удовольствия?
Я так ошеломлен этой темой, что сегодня мне не понадобится моя обычная доза лекарств 
Discourse уже безопасен с точки зрения памяти. Ruby — язык с безопасной памятью; все языки с автоматическим управлением памятью (сборкой мусора) таковы. Главное отличие от Rust в этом аспекте — момент выполнения проверок безопасности: Rust выполняет их на этапе компиляции, а Ruby — во время выполнения.
Rust решает лишь несколько классов ошибок, в основном тех, что вызваны отсутствием сборки мусора в C++. Безусловно, круто, что они нашли способ сделать это, сохранив теоретически возможные преимущества производительности при использовании указателей, но это никоим образом не предотвращает те виды ошибок, с которыми сталкивается пользователь. Например, если я использую < вместо <= и в результате получаю ошибку off-by-one, Rust меня не спасёт. Если я забуду вывести сообщение об успехе после завершения действия, Rust тоже не поможет.
Что на самом деле предотвращает ошибки, так это подход разработки, основанный на тестировании (TDD), который Discourse уже использует. Очень мало проектов, которые можно развернуть напрямую из ветки master и ожидать их стабильности, но Discourse — один из них.
«Современные платформы» появляются повсюду, используя JavaScript как для бэкенда, так и для фронтенда. Ruby занимает второе место после Rust по популярности (между ними находится Kotlin), так что в данный момент это отнюдь не редкий язык. Конечно, через 10 лет ситуация может измениться, но даже переписывание на Rust станет техническим долгом уже через 10 лет.
Трудно передать, насколько наивным является это утверждение, именно поэтому все смеются над этой идеей. Я наблюдаю, как мои разработчики рефакторят код уже 3 года, и только сейчас они готовы начать перенос с wxWidgets/ShuttleGUI на Qt/QML — что, для контекста, является миграцией с C++ на C++, просто с другим инструментарием пользовательского интерфейса. Просто трудно трансформировать код, одновременно гарантируя, что поведение останется идентичным. 12–16 дней — это, вероятно, время, которое потребуется только на планирование, прежде чем кто-либо приступит к работе.
Я, возможно, не самый продуктивный разработчик, но мне потребовалось три недели, чтобы просто мигрировать плагин Poll на компоненты Glimmer (и это даже не смена языка!)
Я не знаю ни Rust, ни Ruby, но за последний год команда CDCK проделала потрясающую работу по переписыванию фронтенда на Ember 5 и использованию компонентов Glimmer. Это шло рука об руку с перестройкой фронтенда на основе стандартизированных компонентов и стилей. Меня впечатляет скоординированность усилий и цель, стоящая за этим 
Поэтому я считаю, что они приняли отличное решение о том, что нужно модернизировать, ведь это существенно помогло сохранить Discourse современным и приятным в использовании!
Мануэль, касательно стилей (CSS), задокументировано ли это где-либо? Какие изменения вы считаете основными? Считаете ли вы, что структура CSS-кода Discourse теперь стала менее удобной для работы?
Что касается стилей, основные изменения, которые я вижу, заключаются в следующем:
Для меня это делает кастомизацию Discourse намного проще и точнее. Но, думаю, это зависит от вашего уровня знаний. Я могу представить, что теперь кривая обучения будет круче для тех, кто просто хочет внести некоторые правки и не очень знаком с CSS.
Что касается документации, вы можете ознакомиться со стиль-гайдом, и, думаю, самый простой способ проверить доступные кастомные свойства — использовать инструменты разработчика в вашем браузере. Documentation также перерабатывается. Сейчас в Documentation > Developer Guides есть два раздела: Темы и компоненты и Интерфейс. Но существует огромный разрыв между желанием просто объявить некоторые кастомные стили и созданием компонента. Часть этой информации, вероятно, слишком глубоко скрыта среди тем для разработчиков? 
Если вы планируете портировать его на другой язык, Go, вероятно, будет лучшим вариантом. Одним из преимуществ, которое, как я ожидаю, оценят веб-администраторы, является отсутствие необходимости в пересборке, поскольку приложение поставляется в виде статических бинарных файлов. Это также делает контейнеры в значительной степени ненужными. На самом деле одной из функций, которая, как представляется, остро необходима в Discourse, является возможность «сборки» приложения на машине, отличной от вашего веб-сервера. В настоящее время на минимальном и самом дешёвом VPS процесс сборки занимает почти 10 минут. Это, скорее всего, займёт лишь долю времени, если бы я мог собирать приложение локально на своей рабочей станции, а затем передавать готовые бинарные файлы на веб-сервер для запуска. Имейте в виду, что такие языки, как Go, позволяют тривиально выполнять кросс-компиляцию, так что вы можете собрать приложение на Mac с процессором M1, а затем развернуть его на x86-сервере (или даже просто собрать, передать и развернуть версию для ARM).
Я подозреваю, что сейчас самое большое время при сборке занимает компиляция фронтенда, поэтому вопрос «Go или нет» неактуален в отношении времени сборки.
Ни Rust, ни Go не заменят фронтенд…
(PS Я тоже люблю Go…)