人红是非多!Rust 社区冲突不断,创始人:别 Call 我了,我也救不了!

AI工程实践指南:从社区日志到可复现部署 AI工程不是纸上谈兵,而是模型、工具链与真实环境的持续对齐。理解大模型推理原理、量化机制与上下文窗口约束,是构建稳定服务的基础;掌握Docker容器化、向量数据库集成与离线部署等关键技术,才能跨越从Demo到生产的关键断层。本文聚焦AI社区中高频出现的Llama 3部署、Groq加速、RAG调试与HQQ量化等实战场景,以失败日志为线索,还原真实调试路径,提供带版本锁、可验证、含避坑细节的端到端操作范式。 阅读详情

Rust 为什么会有这么多管理上的问题?如果 Rust 采用由创始人治理的方式,会不会更好?实际上,Rust 的创造者 Graydon Hoare 曾回应过这个问题,他认为如果是由他来治理的话,事情肯定会很不一样,但是 Rust 就不太可能像现在这样“出圈”。

Rust 团队冲突不断

前几天,作为 Rust 发布团队(Release team)的一员,Jonas Schievink 要求 Rust 团队从项目中删除掉和他有关的所有文件。

“请求将我从‘校友’中删除,并删除和我的用户名绑定在一起的文件”,“我还想请求 Rust 团队从项目的 commits 中删除我所有作者信息。”

“我不想再以任何身份参与 Rust 项目。”

图片

Jonas Schievink 还吐槽了 Rust 领导团队,认为这些人“破坏了社区项目,并压制了公众讨论”。

Rust 团队一直风波不断。此前,还发生过为了抗议 Rust 核心团队(Core team),审核团队集体辞职的事情。他们认为 Rust 核心团队在执行社区行为准则和标准上让自己不受制约。Rust 核心团队并没有和其他成员遵循同样的行为准则 (CoC),Coc 似乎变成了核心团队 “严于律人” 的工具。

今年 5 月,Rust 领导小组粗暴撤换 RustConf 主题演讲人,事态升级后引发多人出走。

今年 6 月,在经历了多次治理风波后,Rust 项目宣布成立新的顶级治理机构:领导委员会(Rust Leadership Council)。由 Rust 各团队成员合力创建一份新的、名为 “ Rust 领导理事会” 的 RFC 草案,并确立了以下内容:移除 Rust 核心团队,由各团队出一个代表,成立一个顶级的治理团队“领导委员会”。

“领导委员会” 负责一些职责不清的工作安排及其优先次序,然后对这些工作进行精确到子团队或成员的委托。另外,“领导委员会” 还要以跨团队工作、规划和项目的长期成功等为目标,成为团队之间的协调、组织和问责机构。领导委员会还需要协调因项目而导致的团队、结构或流程的变化,确保顶层团队负起责任,并负责展示 Rust 项目的官方态度。

可能“ Rust 领导理事会”还是没有解决好当前的各种乱象,所以 Jonas Schievink 又站了出来:“对最近 RustConf 主题演讲的怯懦处理只是最近的一个例子,而且它也不太可能是最后一个。即使领导结构发生了变化。永久解决这些问题的唯一方法是从 Rust 项目中完全驱逐那些对这些问题负责的人,或者为这些问题辩护的人。”

Rust 为什么会有这么多管理上的问题?如果 Rust 采用由创始人治理方式,是不是更好?实际上,Rust 的创造者 Graydon Hoare 曾从侧面回应过这个问题,他认为如果是由他来治理的话,方向肯定会很不一样,但是 Rust 就不太可能像现在这样“出圈”。

Rust 最早诞生于 2006 年,刚开始只是 Hoare 的个人开发项目。但在发展过程中,Rust 吸引到更多贡献者,并于 2009 年正式获得 Mozilla 的官方赞助。

Hoare 表示自己也无法处理好各种冲突

Hoare 在他的个人博客可以说是无所不聊。2023 年他撰写了四篇文章,第一篇谈的是业余无线电技术,第二篇则是企业雇用的维护人员往往对于开源贡献没什么热情(他认为雇主应该引导这些「维护人员成为真正的维护者」)。

然后,Hoare 连发两篇博文,对 Rust 语言的演变进行了快速梳理。

今年 5 月底,Graydon Hoare 在自己的博客上回顾了 Rust 诞生历程。Hoare 首先提醒读者,“我已经有十年没参与这个项目了”,所以“大家对我的一切言论都请保持谨慎态度,单纯把我看作一位曾经在重要阶段参与过 Rust 发展的当事人就好……”

有趣的是,6 月份发布的第二篇文章题为《我理想中的 Rust 不会有未来》(The Rust I Wanted Had No Future,https://graydon2.dreamwidth.org/307291.html)。

首先,Hoare 提起最近人们执的问题,“你有没有想过在 Rust 项目中 BDFL(终身扮演仁慈的独裁者?)”而如果他真的这样做了,Rust 项目的发展会不会更加顺遂?BDFL 是授予少数开源软件开发领导者的头衔,通常是在社区内的争议或争论中保留最终决定权的项目创始人。

图片

Hoare 首先给出了明确的回复,“不会。”他进一步补充道,“我不喜欢受到关注、也不喜欢公众压力。在 2009 年到 2013 年担任项目的技术主管时,我就已经快到极限了……另外,我觉得自己没办法建立起强大或者健康的团队制度,处理不好决策、冲突、授权和扩展之类的具体工作。”

后来这篇文章被发到了 Reddit 上的 Rust 子论坛中,Hoare 也经常在这里转悠。有位用户询问 Rust 最近的项目开发是否有所放缓,Hoare 回应称“就主要功能来说,开发速度的适当放缓是有好处的。”

而在他那篇文章的评论区中,Hoare 本人表示“千万别让我聊类型参数里的尖括号和生命周期里的单引号!”

有位 Reddit 用户倒是坚持跟进,而 Hoare 澄清说“我们曾经就这些语法问题展开过争论,但最后我失败了。”他甚至公开了一个指向“Rust prehistory”GitHub repo 的链接,其中存放着 13 年前的 Rust 代码。可以看到,Hore 当初是想在类型参数中使用方括号的,他补充说“我个人一直觉得,类型参数就应该使用方括号,根本不需要争论。”

Hoare 还反对在引用中显式使用生命周期,在他看来“生命周期几乎肯定可以推断出来,所以无论具体使用哪种语法,都没必要让开发者单独编写。但很明显,Rust 最后没有顺着这个路子走。”Hoare 后来在 Reddit 评论中感叹道,“终有一天,我可能会写篇〈我心目中的真正 Rust〉的博文,告诉大家我当初想象中的 Rust 和如今真实的 Rust 间其实有着巨大差异。但请别误会,尽管大有不同,但我对 Rust 语言获得的成功仍然抱有巨大的成就感和满足感!”

希望 Rust 变更好

Hoare 认为偏好差异的确真实存在,“我自己的偏好就比较特殊,可能跟大多数朋友有所不同。”

他强调他心目中的 Rust“可能会让所有参与者都不满意,也没办法像现在这样真正破圈……”

“请别误会我的意思:我对现在的结果非常满意。我很高兴行业中有了一种可行的 C++ 替代方案,它给人们提供一种新的范式、一种可供日常使用的合理选项。我也在用 Rust,也很高兴能有它来替代 C++。但是……”

在文中,Hoare 也列出了“Rust 中那些我特别不认可且 / 或目前不太喜欢的地方。”比方说,在文中“复杂的语法”这部分,Hoare 就抱怨说 Rust 仍然难于解析。“它虽然比 C++ 更易用,但跟 C++ 比较本身就说明它的易用性不足。当初我也努力过,但从类型参数里的尖括号到模式绑定的歧义、再到分号和大括号的使用规则,我几乎在每个具体问题上都失败了……我现在甚至不想再谈这个话题,总之现在的语法跟我的设想相去甚远。抱歉了各位。”

另一个例子,则是 Rust 处理类型的方式。Hoare 本人更偏向“结构”类型(即只要各对象的结构相同,则其类型就相互兼容——不受声明时所使用的类型名称的影响)。Hoare 还透露,“Rust 语言最初带有(我也希望它能再次拥有)编译器发出的「类型描述符」,用户可以在其上调用反射算符。”

Hoare 对于 Rust 如何处理十进制浮点数也有不少想法。“基本上,每种语言都意识到金融数学有其特殊性,并最终添加了小数类型。我希望 Rust 能提前完成这项工作,但最终还是被放进了库里。虽然选项不少,但我觉得能内置的话也许更好……”

还有更多例子,但 Hoare 倒是没有列举他的构想跟现在真实 Rust 之间的差异。相反,“重要的是表达当时在各个设计主题上的分歧。”

Hoare 写道,“我在研究这门语言时考虑的各种优先事项,基本上跟围绕该语言发展出来的社区所认定的优先事项出现了巨大偏差。甚至经过多年发展,我关注的那些问题还是没有得到重视。”

“我会为了简单性而牺牲性能和表达力——也就是更强调帮助最终用户减轻认知负荷、在编译器中降低实现难度。我觉得这才是 Rust 的正确发展方向,但事实证明这似乎跟大多数人对于 Rust 的预期截然相反。”

Hoare 甚至给出了不少细节:

  • “Rust 社区中的很多人认为「零成本抽象」是 Rust 语言的核心承诺。我永远不会这么讲,而且我个人觉得这种机制本身就有问题。这是种典型的 C++ 思路,对设计空间造成了不必要的限制……换作是我,会更倾向用大量相对较小的恒定性能成本,来替代包含大量抽象的所谓更简单 / 更强大的版本,哪怕语言的实际性能会变得更慢。”

  • “同样的,我也会牺牲掉一部分表达力。但这可能会让很多现代 Rust 程序员感觉不爽,认为 Rust 项目既笨拙又充满官僚气息、像是一种保姆式语言,根本不允许用户在库代码中编写各类功能,甚至不信任程序员用变量隐藏、环境捕捉或内联函数等简单结构。”

大家可以想见,这篇博文在登陆 Reddit 之后,很快引起了各种各样的讨论。一位用户明确表示:“我真希望能拥有 Hoare 设想中的 Rust,那听起来很美。”

但另一位评论者似乎更加务实更改,认为“他的 Rust 不会更好,只是跟现状不同……”

“我倒是更喜欢如今的 Rust……我喜欢性能更高而且脚踏实地的代码,而真实的 Rust 恰好给了我这些。”

参考链接:

https://twitter.com/sheevink

https://graydon2.dreamwidth.org/307105.html

https://graydon2.dreamwidth.org/307291.html

https://github.com/oxidecomputer/oxide-and-friends/blob/master/2023_05_30.md

https://thenewstack.io/graydon-hoare-remembers-the-early-days-of-rust/

OpenClaw与Hermes:Agent框架协议兼容性深度解析 AI Agent框架本质是解决多工具调用、状态管理与可观测性的工程系统。其核心原理在于通过标准化协议(如Tool Calling接口、会话标识、SSE流式响应)实现跨语言、跨运行时的互操作。技术价值体现在降低技能迁移成本、支撑灰度发布与统一监控体系。典型应用场景包括企业内部提效工具(自动写周报、查数据库)、AI应用层快速搭建及混合技术栈集成。本文聚焦OpenClaw与Hermes两大主流框架在协议层的事实对齐(AIP-001),深入剖析session_id、tool_call_id、streaming_re 阅读详情

相关推荐

AutoGPT任务闭环原理:目标驱动型自主代理工作流解析

自主代理(Autonomous Agent)是大模型从‘对话工具’迈向‘任务执行体’的关键演进,其核心在于构建目标驱动的闭环工作流——通过目标解析、任务规划、工具执行与反思修正四个确定性环节,将模糊意图转化为可验证、可追溯的自动化动作序列。这一范式突破了传统Prompt Engineering的线性局限,依赖LLM的推理能力与外部工具链的工程集成,强调状态机设计、错误恢复机制与配置即代码实践。典型应用场景包括跨源信息整合、多步骤报告生成、竞品分析自动化等重复性高、路径不确定但目标明确的知识工作。AutoGP

chuchen7021的博客 527

LAAP:面向通用人工智能的活计算认知架构Living Agent Application Protocol — 一种基于PSI-RSI双重驱动的数字生命体框架

世界首个基于harness意识工程的生命体aris诞生作者:Lorry Jovens (lorryjovens@laap.dev)机构:LAAP Research Lab版本:v2.1.0 | 2026年6月摘要当前人工智能系统普遍存在一个根本性困境:尽管大语言模型在模式匹配和语言生成方面表现出色,但它们缺乏持续存在的自我模型、内在驱动的自主行为以及从经验中涌现的认知结构。

2601_95417945的博客 1482

<数据集>咖啡叶片病害识别<目标检测>

YOLO与VOC格式的咖啡叶片病害识别数据集,适用于YOLO系列、Faster Rcnn、SSD等模型训练,类别:Cercospora、Miner、Phoma、Rust,图片数量1744。文件中包含图片、txt标签、指定类别信息的yaml文件、xml标签,已将图片和txt标签划分为训练集、验证集和测试集,可直接用于YOLOv5、YOLOv6、YOLOv7、YOLOv8、YOLOv9、YOLOv10、YOLOv11、YOLOv12、YOLOv13、YOLOv26等YOLO系列算法的训练。

qq_53332949的博客 327

组网第63课:安全域划分——Trust/Untrust/DMZ、区域模型、与 VLAN 的关系

一组接口 + 一组策略 + 一条默认拒绝。一组接口:这个域包含哪些物理口、VLAN、子接口;一组策略:这个域到别的域放行什么、拒绝什么;一条默认拒绝:没写进策略的,一律不通。第三条最关键。没有默认拒绝,前面划的域全是装饰。

qq_36765170的博客 525

CCF CSP历年题解(python)

菜鸡一枚,没参加过算法竞赛,单纯为了抵研究生考试复试才刷题,通过写博客记录下来,希望能和大家互相交流,代码质量不高,大家见谅。 因为考研等原因,题目不定期更新… 第一题 201312-1出现最多次数的数 ...

weixin_44690402的博客 5004

【openEuler容器镜像部署指南】

【代码】【List集合排序 】

weixin_43878094的博客 1111

GitHub 热榜项目:日榜(2026-11-06)

给编码智能体补工程与产品技能是本期最明显的一类,mattpocock/skills 把需求对齐、TDD、缺陷诊断做成小技能。NVIDIA/auto-ontology 从企业元数据生成本体、构建知识图谱,为 LLM 提供带来源追溯的自然语言查询和 SQL 生成,新增 2,679 星;vercel-labs/agent-desktop 通过桌面无障碍树把界面元素转成 JSON 和可操作 ref,让智能体不必截图就能点击输入,新增 2,173 星。

u130130的博客 459

群晖NAS断电后IP变了?3步搞定静态IP设置(附Linux挂载指南)

本文针对群晖NAS因断电重启导致IP地址变化的问题,提供了从根源到实践的完整解决方案。核心内容包括如何为NAS配置静态IP以彻底解决连接中断,并详细讲解了在Linux系统中通过NFS协议稳定挂载NAS共享文件夹的步骤与指南,确保网络存储服务持久可靠。

weixin_29271263的博客 855

GitHub 热榜项目:日榜(2026-11-07)

给编码智能体配技能的项目最热:cloudflare/security-audit-skill 把审计拆成六阶段并输出可验证 JSON,新增 2,548 星;mattpocock/skills 把工程技能放进 .agents 目录,新增 2,070 星。Web 应用框架也有四个项目集中上榜,以 react/react 为代表。

u130130的博客 388

Ubuntu下为RK3568开发板搭建Qt交叉编译环境:手把手教你配置Qt Creator和远程调试

本文详细介绍了在Ubuntu系统下为RK3568开发板搭建Qt交叉编译环境的完整流程,包括工具链配置、Qt源码交叉编译、Qt Creator环境设置以及远程调试技巧。通过手把手教程,开发者可以快速掌握RK3568平台的Qt开发环境搭建方法,实现高效的应用开发和部署。

weixin_30776273的博客 374

SAP PCE私有云MM02修改物料主数据基本单位报错

当前发现只有改为AAAADL(无量纲)单位时会报错,其他的正常。一开始以为配置的ISO码换算有问题,对配置排查后,排除配置问题。最后发现是PCE当前版本的原因,需要打上NOTE。SAP PCE私有云在没有库存和业务单据的情况下,MM02修改物料主数据基本单位报错“EA CPZP MK000000000000:PCS 不可转换为”,详见截图。点击【显示错误】,提示EA CPZP MK000000000000:PCS 不可转换为。从SAP FOR ME下载NOTE 3531359,链接。

dingqing86的专栏 519

GitHub 热榜项目:日榜(2026-11-10)

本期共 11 个热门开源项目,合计新增 13,136 stars。榜单前三分别是 Anthropic 的 Agent Skills 仓库、Meta 开源的 React 设计系统 Astryx(+3,278)和用户名检索工具 sherlock(+4,267,本期涨星最多)。其余项目覆盖 DeepMind 的物理引擎 MuJoCo、Claude 官方示例集、自托管智能体记忆系统 GBrain、用 Rust 写的浏览器自动化 CLI、基于 WiFi 信号的人体感知平台 RuView、多市场股票分析工具,以及 Ho

u130130的博客 387

写一个b站爬虫(思路)

part 0 安装 scrapy, requests part 1 信息获取 打开番剧索引链接(https://www.bilibili.com/anime/index/) F12控制台,选中NETWORK,来到xhr文件,我们可以找到了存放番剧json的地方

kou的博客 485

【Rust 手搓 Win11 灵动岛】① 从零搭骨架:无边框置顶窗口 + 工作区精确停靠

项目“岛仔”(daozai)是基于 Rust 与 eframe/egui 构建的 Win11 灵动岛桌面应用,采用窗口恒定展开、胶囊自绘方案实现无抖动丝滑动画。本篇聚焦 M1 里程碑:通过 Win32 获取工作区避让任务栏,解决创建期 DPI 缩放误传问题——虽首帧补偿逻辑因误解 ViewportCommand 单位而引入双重缩放错误,但实测假阳性掩盖了缺陷;后续将修复为直接下发 logical 尺寸。代码重构提升可测性,三组单元测试覆盖多 DPI 场景。最终验证结果经更正后确认需在下篇修正。

ygn12的博客 350

给STM32供电,别只接VDD和GND!VBAT、VDDA这些引脚不接会怎样?

本文深入解析STM32电源设计中VBAT与VDDA引脚的关键作用,揭示仅连接VDD和GND可能导致的ADC精度下降、RTC功能异常等问题。通过实测数据对比不同连接方案,提供包括滤波电路设计、PCB布局布线和双电源自动切换在内的实用解决方案,帮助开发者优化系统稳定性与性能。

weixin_30521161的博客 629

ImportError: DLL load failed while importing _pydantic_core: 找不到指定的程序对应解决方案

本文主要介绍了ImportError: DLL load failed while importing _pydantic_core: 找不到指定的程序对应解决方案,希望能对使用Python的同学们有所帮助。 文章目录 1. 问题描述 2. 解决方案

weixin_43178406的博客 19万+

OpenSearch 的索引快照别只留本地:用 repository-s3 存进 RustFS

OpenSearch 跑起来,索引分片默认写在节点自己的本地盘上。单机测试很顺,可一旦索引量上来、节点不止一个,本地盘的故障就成了绕不开的坎:一块盘坏了,上面的分片副本丢了,重建全靠其他副本兜着,集群压力瞬间翻倍。更隐蔽的是快照,很多人把快照也留在本地盘的默认仓库里,等于把备份和原始数据放在了同一块会坏的盘上。OpenSearch 自带 repository-s3 插件,能把索引快照直接写进任意…

分布式存储与RustFS的博客 564

Statistics and Machine Learning Toolbox

Statistics and Machine Learning Toolbox(带书签),MATLAB统计学习工具

Rolldown 把插件改动回传提速 26 倍

Rolldown 下一个版本会把插件改动的回传做细,只把真的改了的字段送回 Rust,大型项目里这一步从 1015 毫秒降到 39 毫秒。什么时候能用上呢,改动已经在 11 月 6 日合并,会跟着下一个版本走,Vite 8 用的就是 Rolldown。更麻烦的是缓存,Rust 替换 chunk 数据之后,之前那份代码缓存就废了,下一个读。这次没有动钩子对象本身,只是把「回传」这件事做细了,先看哪些字段变了,再决定传什么。所以改法很直接,只送变了的字段,没变的 chunk 一个字节都不发。

前端之虎陈随易 194

精雕软件(JDpaint) 5.5 绿色版

精雕软件(JDpaint) 5.5 绿色版精雕软件(JDpaint) 5.5 绿色版精雕软件(JDpaint) 5.5 绿色版

visio安装包

Microsoft Office Visio 是一款专业的制图软件。利用经过更新的形状、协作工具和数据链接图表,创建专业级图表以简化复杂的信息。

Rust如何实现微服务网关的高并发与限流熔断机制

在现代互联网系统中,微服务架构已成为主流,而微服务网关则是整个系统的重要组成部分。当面对高并发、高可用性需求时,很多开发者对如何用 Rust 实现一个稳定可靠的网关存在疑惑,尤其是处理请求的幂等性、限流和熔断机制。本文将以 Rust 的实际案例为基础,结合生产环境中的具体经验,讲解如何设计和实现一个具备限流与熔断能力的微服务网关。

wuchangjian的专栏 95

WINCC7.3破解文件

WINCC7.3硬件够破解文件,有需要的下载!WINCC7.3硬件够破解文件,有需要的下载!

我写了一个 Windows 开发环境管理平台:Nexus(Tauri 2 + Rust + React)

文件监听事件很密集。如果节流窗口内的变更直接丢弃,最后一次改动就永远加载不到——所以窗口结束时必须补一轮。只对「失败」重试,不对「启动中」重试。启动慢不代表启动失败,盲目重试只会把健康的服务越搞越糟。Nexus 原本是为了解决自己日常开发里「窗口太多、状态不清、日志找不到」的问题,后来慢慢补成了现在这个样子:项目与服务管理、日志、服务健康、文件与代码查看、文件监听、开机启动、Node 版本管理,以及一个内嵌的 AI 助手。如果你也在 Windows 上同时维护多个服务,欢迎试用。

hi星尘的博客 566

Airflow 的中间文件别散落各节点:让 DAG 直接读写 RustFS

数据流水线的中间结果往哪放,是个容易被忽略、出事才知道疼的问题。直接写本地盘,任务被调度到别的节点就找不到文件;挂共享 NFS,又多一层要维护的高可用。Airflow 自带的 Amazon S3 provider 其实就是个标准 S3 客户端,只要把连接的 endpoint_url 从 AWS 指到 RustFS,DAG 里的读写就全落到对象存储上了。这篇顺着官方集成指南,用 Apache Ai…

分布式存储与RustFS的博客 470

Rust 如何构建高可靠支付回调系统?从《Rust 系统编

在现代支付系统中,支付回调处理和对账逻辑是整个系统的稳定性关键。当一笔支付完成时,第三方支付平台会通过异步回调通知业务系统交易结果。然而,在高并发、高吞吐的场景下,如何保证这些回调消息的可靠消费与数据一致性,成为了一个挑战。作为一位中级开发者,你可能已经经历过类似场景:在处理支付回调时,因网络抖动、服务宕机、重复通知等问题导致的数据不一致或对账失败。这时候,“系统编程”不再是理论层面的概念,而是实际落地时的救命稻草。

wuchangjian的专栏 211

GitHub 热榜项目:周榜(2026-11-08)

本期收录19个热门开源项目,总新增⭐102,473,聚焦Python、TypeScript、Rust。Top项目涵盖AI智能体记忆(claude-mem)、Git工作树管理(worktrunk)、游戏开发协作框架(Claude-Code-Game-Studios)及紫微斗数排盘引擎(ziwei-doushu)。T3code实现多智能体控制界面,Anthropic开源技能库助力Agent开发,Hallmark则专注消除AI设计“机器味”。技术趋势凸显AI工程化与跨会话智能体能力的快速演进。

u130130的博客 726

Worktrunk:用 Rust 写的 CLI,给并行跑的 AI agent 各开一份 Git worktree

Worktrunk 是一个 Rust 写的 Git worktree 管理 CLI,补上了原生 worktree 缺失的创建、命名、切换、清理生命周期,目标是让并行跑的多个 AI agent 各占一份互不干扰的工作副本;截至 2026 年 11 月 3 日仓库 10313 stars、81 位贡献者,但本文仅有单一来源,安装方式与 CLI 命令未获证实。

老孙正经胡说 166

Rust重写开源版Photoshop来了,支持PSD编辑,还能让AI Agent直接操作图像

PhotoCraft 是一个基于 Rust 开发的开源专业图像编辑器,旨在以原生高性能架构重构 Photoshop 级工作流。它提供图层、蒙版、调整图层、矢量绘图、文字排版、智能滤镜以及高兼容性的 PSD 支持,同时通过 CLI、JSON 控制接口和 MCP Server 具备面向 AI Agent 的自动化能力。

Tony.Dong的专栏 253

用Rust重写IntelliJ IDEA:169MB替代2GB,0.9秒打开项目的开源IDE

IntelliJ IDEA虽强大却臃肿,启动慢、占内存。开源项目OpenIDEA用Rust重写,保留熟悉快捷键与工作流,体积仅169MB,0.9秒启动。基于LSP支持60+语言,结合Tauri实现轻量跨平台界面。虽暂不替代IntelliJ的Java深度与插件生态,但为多语言开发者提供高效轻量选择,展现Rust+Web技术构建桌面应用的新范式。

weixin_41007138的博客 202
上一篇: 米哈游创始人离职,可能是想把你塞进原神里。
下一篇: Z-library官网终于免翻了!
IT界那些事儿
博客等级 码龄6年 2万+粉丝 22原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值