Core Insights - The article illustrates the paradox of success in technology, where a highly efficient system can lead to the perception that fewer developers are needed, ultimately jeopardizing the use of that technology [1][29]. Group 1: Technical Debt - The company had a traditional tech stack and needed to develop a real-time service to support 100,000 concurrent users, displaying user activity information [2]. - The initial choice of Ruby was deemed inadequate, prompting discussions on technology selection [3]. Group 2: Technology Selection Battle - The development team proposed using Rust, but management was cautious and requested comparisons with other languages [4][5]. - Concept validation versions were created using Elixir, Rust, Ruby, and Node.js, with Rust being developed by a novice [5][6]. Group 3: Performance Results - The performance results showed Rust as the fastest and most memory-efficient option, followed by Elixir, Node.js, and Ruby [8][10]. - The final decision favored Rust not only for its performance but also for its versatility in future applications [10]. Group 4: Rapid Development - Due to time constraints, a single developer with Rust experience was tasked to lead the project, collaborating closely with the team [11][13]. - The architecture was designed to handle 100,000 connections efficiently, utilizing a WebSocket-based API and in-memory data storage [14]. Group 5: Performance Challenges - The service performed stably under the expected load, but management later decided to shift it to maintenance mode, leading to a lack of oversight [16]. - The service was initially successful, but as the company expanded, management questioned the need for Rust developers due to the service's stability [19][20]. Group 6: Management Decisions - The new director's perspective led to the departure of experienced Rust developers, as they were deemed unnecessary due to the service's lack of issues [22]. - The decision to abandon Rust in favor of more mainstream technologies raised concerns about the existing Rust service's future [23]. Group 7: Node.js Rewrite Attempt - The attempt to rewrite the service in Node.js failed due to its single-threaded nature, which could not handle the required load [24][25]. - The company resorted to using a third-party service, which also proved inadequate [26]. Group 8: Lessons Learned - The Rust service continued to operate effectively but without a dedicated maintenance team, highlighting the risks of having a highly efficient system [28][29]. - The article concludes that sometimes, a less-than-perfect system may be perceived as safer, emphasizing the impact of management changes on technical decisions [29].

Core Viewpoint - The article discusses the paradox of a successful Rust project leading to its eventual abandonment within a company due to management changes and a lack of understanding of its value [2][12][15]. Group 1: Project Background and Development - The project took place in a rapidly growing unicorn startup that primarily used Ruby on Rails and Node.js, with no initial use of high-performance languages like Rust or Go [3]. - The team decided to develop a real-time service to support 100,000 concurrent users, leading to a comparison of different programming languages including Rust, Elixir, Ruby, and Node.js [4][10]. - Rust was ultimately chosen for its flexibility and performance, despite initial bugs, and the team completed the MVP in just two weeks [8][9][10]. Group 2: Performance and Stability - The Rust version outperformed others in speed and memory usage, successfully supporting 100,000 concurrent users without issues [10][11]. - After a month of stable operation, the service was put into maintenance mode as company strategy shifted, leading to the disbanding of the Rust development team [12][13]. Group 3: Management Changes and Consequences - A new management team, unsatisfied with the perceived lack of activity from the Rust service, decided to phase out Rust in favor of more familiar technologies like Ruby and Node.js [13][14]. - The decision resulted in the departure of three experienced Rust engineers, which was seen as a missed opportunity for the company to leverage Rust's capabilities further [15]. - Ultimately, the management's decision to rewrite the Rust service in Node.js led to complications and performance issues, highlighting the challenges of maintaining high concurrency with Node.js [16][17]. Group 4: Industry Insights and Reactions - The article sparked discussions among developers who shared similar experiences of successful projects being undervalued or abandoned due to management decisions [17][18]. - Many industry professionals noted that such occurrences are common in companies as they grow and management changes, often stifling innovation [18].

还记得不久前的那篇《"因为一次成功重写，我们 CTO 彻底封杀了 Rust！"》吗？ 当时，许多读者留言称这故事"离谱"得像是由 AI 杜撰的，其中就包括了本文的主人公——一位 Reddit ID 名为 Drogus 的开发者："一篇用 AI 生成的帖子"、"明显是假的"。 话虽如此，Drogus 却不由得联想到了一段他自己的真实经历，与其中某些情节有几分相似："Rust 项目 做得太成功，反而导致这门语言在公司内部被「判了死刑」"。 项目背景：一个快速成长的独角兽初创公司 Elixir 次之； Node.js 表现还可以，但受限于单线程运行时； Ruby 最慢。 值得注意的是，Rust 版本最初存在也一个小 bug：开发者用 async futures 给客户端发消息时，会遍历所 有客户端来获取发送通道列表，这在高负载下会阻塞运行时几秒。不过这个问题属于实现细节，对熟悉 Rust 的人来说并不难修复。 这件事发生在几年前。那时，Drogus 刚加入了一家在疫情期间快速成长的独角兽初创公司，其主力应 用采用 Ruby on Rails 编写，一些视频处理相关工具则用 Node.js 实现。当时，这家公司并没有 ...