内存安全是否能极大地惠及该平台？
性能也可能得到提升。
我认为使用 Rust 还可以减少永无止境的 Bug。
作为一个现代平台，Discourse 在不重写成 Rust 的情况下能否生存下去？
Rust 开发的便捷性和高效性应该不成问题。
有什么想法？
您是自愿移植它吗？
8 个赞
Jeff 写了一篇关于为什么选择 Ruby 的博客文章：
可能写于 Rust (是) 之前，但肯定会提供一些理由。
8 个赞
当然，但微软也在走向 Rust 的道路。
杰夫肯定现在知道 Rust 更胜一筹。
只要付出一些心血，12-16 天就能完成。他还没到退休的年纪。
3 个赞
我几乎可以肯定，升级到新版本的 Ruby 或 postgres 需要至少 12-16 天。大约有 60,000 行 Ruby 代码。
什么可以取代 Rails？
9 个赞
微软拥有非常雄厚的财力和资源。
你需要重写核心以及所有插件。
这也意味着路线图需要搁置。
能做到吗？当然可以。但你也需要进行测试和调试。
Discourse 的现有客户可能会导致他们的站点崩溃。
在我看来，如果团队要致力于此。就需要将其作为一个分支，并让 Beta 测试人员在很长一段时间内进行测试。为 Discourse2 Meta 等分支插件。
因此，目前将资源分配给维护当前的 Ruby 和移植是不太合理的。
7 个赞
抱歉，这是笔误吗？您是指几个月吗？
您能指出一个与 Discourse 规模和范围相似的项目，并且能在如此短的时间内完成移植吗？
15 个赞
我敢打赌，David Megginson 概述的流程听起来非常熟悉：
精英（大师级）开发者注意到太多普通人使用他们当前的编程语言，并开始寻找一种能让他们与平庸的同事区分开来的东西。
精英开发者带着他们当前的不满清单，寻找一种新的、鲜为人知的语言，这种语言显然有更少的不满。
精英开发者开始推动新语言的发展，贡献代码、编写库等，然后宣传新语言。次精英（高级）开发者跟随精英开发者转向新语言，为书籍、培训等创造市场，并加速语言的开发和测试。
次精英开发者（精英开发者倾向于独立从事研究项目，而不是生产开发团队，因此拥有巨大的影响力）开始在工作场所推广新语言。
大量普通开发者意识到他们必须开始购买书籍并参加课程来学习一门新语言。
精英开发者注意到太多普通人使用他们当前的编程语言，并开始寻找一种能让他们与平庸的同事区分开来的东西。
你使用什么技术并不重要，只要它有效，并且你和你的用户都对它满意？
这就是新事物的魅力：总有新的东西出现。不要让对新、闪亮事物的追求意外地成为你的目标。避免成为一个喜鹊开发者。在追求闪亮和新事物时要有选择性，你可能会因此成为一个更好的开发者。
5 个赞
哇。希望你只是在开玩笑。
9 个赞
也可以在这里问问，他们可能知道 
12 个赞
不，你为什么这么说？
2 个赞
也许是因为 Rust 爱好者正在使用 Discourse？或者，如果移植只需要两个工作日，他们就已经完成了，只是为了好玩和乐趣？
3 个赞
我被这个帖子震惊得今天都不需要吃药了 
12 个赞
Discourse 是内存安全的。Ruby 是一种内存安全语言；所有垃圾回收语言都是如此。在这方面与 Rust 的主要区别在于安全检查的执行时间；Rust 在编译时执行，Ruby 在运行时执行。
Rust 只解决少数几类错误，主要是 C++ 缺乏垃圾回收所导致的错误。当然，他们找到了在保持指针理论上可能实现的性能优势的同时做到这一点的方法，这很酷，但这绝不能防止您作为用户会看到的那些错误。例如，如果我使用 < 而不是 <=，并因此导致了差一错误，Rust 也救不了我。如果我忘记在操作完成后生成一个成功消息，Rust 也救不了我。
真正能防止错误的是 Discourse 已经部署的测试驱动开发。很少有项目可以直接从 master 部署并期望它们是稳定的，但 Discourse 就是其中之一。
“现代平台”如雨后春笋般涌现，前后端都使用 JavaScript。Ruby 在流行度上仅落后 Rust 两位（Kotlin 居于两者之间），所以它目前并不是一种罕见的语言。当然，10 年后情况可能会有所不同，但即使重写成 Rust，10 年后也会变成技术债务。
很难传达这句话有多么天真，这就是为什么每个人都在嘲笑这个想法。我见过我的开发人员花了 3 年时间重构代码，他们才刚刚准备好从 wxWidgets/ShuttleGUI 移植到 Qt/QML——就背景而言，这是从 C++ 到 C++ 的迁移，只是使用了不同的 UI 工具包。在确保行为完全相同的同时转换代码是非常困难的。12-16 天可能只是在任何人开始之前所需的规划时间。
15 个赞
我可能不是最高产的开发者，但仅仅是将 Poll 插件迁移到 Glimmer Components 就花了整整三周时间 （这甚至都不是语言的改变！）。
6 个赞
我不知道 Rust 或 Ruby，但我感觉在过去的一年里，CDCK 的团队在前端重写成 Ember 5 和 Glimmer 组件方面做得非常出色。这实际上伴随着前端的重建，采用了标准化的组件和样式。我对这项工作背后协调一致的努力和目标印象深刻 
所以对我来说，他们做出了一个关于现代化什么的好决定，因为它在保持 Discourse 现代化和易用性方面发挥了巨大作用！
21 个赞
Manuel Kostka, post:16, topic:316333, username:manuel]
实际上，它与使用标准化组件和样式的重构前端一起完成的。
[/quote]
Manuel，关于样式（CSS），这有任何文档记录吗？您认为主要的改动是什么？您觉得 Discourse 的 CSS 代码结构现在是否更难使用了？
在样式方面，我看到的主要变化是：
对我来说，这使得自定义 Discourse 更加轻松和准确。但我想这取决于你的工作知识。我可以想象，对于那些只想做一些调整但又不太熟悉 CSS 的人来说，现在的学习曲线更陡峭了。
关于文档，你可以查看 Styleguide，我认为使用浏览器的开发者工具是查看可用自定义属性的最简单方法。Documentation 也在重新制作中。目前 Documentation 中有两个部分：“developer-guides”中的“Themes & Components”和“Interface”。但仅仅是声明一些自定义样式和编写组件之间存在巨大的差异。其中一些可能在开发者主题中埋得太深了？
9 个赞
如果您要将其移植到另一种语言，我认为 Go 可能是更好的选择。我认为 Web 管理员可能会欣赏的一个优点是无需重新构建，因为它会分发静态二进制文件。这使得容器也基本不必要。事实上，Discourse 似乎急需的一项功能是能够在与 Web 服务器不同的机器上“构建”应用程序。目前，使用最基本、最便宜的 VPS，构建需要近 10 分钟。如果我能在本地工作站上构建，然后将最终的二进制文件发送到 Web 服务器上运行，这可能只需要很短的时间。请记住，像 Go 这样的语言允许您轻松地交叉编译，因此您可以在 M1 Mac 上构建，然后在 x86 Web 服务器上部署（甚至可以只构建、发送和部署 ARM）。
我怀疑目前构建过程中最耗时的是前端编译，所以“是否可行”与构建时间无关。
Rust 和 Go 都不会取代前端……
（附言：我也喜欢 Go……）
3 个赞