Hacker News

今天在Hacker New上看到了一篇称赞Raisl的文章Why Rails Still Matters。 原文用黑胶唱片做为引子,说明以rails为代表的老旧web技术是ok的,不比 新的Next.js之类差很多,大家的应用场景不同而已. 个人顾个人的场子,井水不犯河水就好. 我的想法 我是从Rails入行的软件开发,入职了在一个很小的微型企业. 从Rails开始,我慢慢接触并且使用了Vim, Linux, Ruby, ORM, SQL, Postgresql, Python(在大学只是理论学习), Lua, Javascript, CSS, Markdown, Docker, Go, Kubernetes, Rust等等各种各样的技术. 可以说Rails是我从事IT行业的引路人. 最后从事和Ruby相关的工作是2016年的时候,负责给一个稍微大一点的 初创公司运维那些web服务器,数据库之类的. 时间过得很快,我很久没接触Rails或者Ruby了. 记不清是哪一个时间段,我非常喜欢静态强类型的编程语言. 估计是被Ruby的 method call chian链路搞烦了,也可能是被class搞烦了. 现在我也不喜欢Python的class 和所有的oop编程语言(java为代表, C++也不喜欢). web/http 整个web开发说白了基本上是面向浏览器开发,包含前后端技术. 前端不多多说,html/css/javascript三个加起来本质上就是浏览器的DSL. 最新的wasm稍微可以说自己脱离了浏览器的控制,但也没脱离多少. Node.js/deno也不敢完全说自己和浏览器没少关系 后端方面,屁股决定脑袋,也受到了浏览器不小的制约,看看Nginx和Header相关配置有多少就知道我在说什么了. HTTP协议这么多年了,也是受到浏览器的控制的,毕竟协议谁都可以写. 市场支持不支持,支持的多不多,是和协议本身的各项指标关系不大的. 浏览器本身是一个很复杂而软件,复杂程度不输操作系统. 越是靠近用户层就越复杂,因为用户/人类是变数最多的. 相反,越靠近物理硬件,软件就可以设计的越简单. 比如网络传输的物理层,网络层,传输层,是一层复杂过一层,一层包一层, 像俄罗斯套娃一样. 操作系统,管好4大件,处理好中断,调度就好了. 浏览器光是html的渲染(想象一下一个动态的window size)就够复杂了, 别提那些音/视频API、网络请求、安全策略了 Gemini 最后用gemini总结一下这篇文章，并介绍一下Rails和Next.js的背景，以及现在的web开发趋势。 我基本认同gmini的说法。 文章主要思想 这篇文章的核心观点是，虽然像Next.js这样的新兴前端框架提供了更高级的功能和更精美的界面，但Ruby on Rails仍然是一个有价值的web开发工具，尤其是在注重简单性、开发速度和可维护性的项目上。作者认为，现代JavaScript框架的复杂性实际上会增加开发难度，而Rails的抽象和对web基础的关注使其成为许多应用程序的强大选择，即使在AI和动态web体验的时代也是如此。他用黑胶唱片类比，说明了为什么旧技术在新的创新出现后仍然存在并有价值。本质上，这篇文章推崇Rails是一种实用、高效且具有成本效益的解决方案，即使它不是“最新潮”的技术。 Rails 和 Next.js 的背景 Ruby on Rails (Rails)：是一个基于Ruby语言的web应用开发框架。它由David Heinemeier Hansson于2003年创建，旨在提高开发效率和简化web应用开发过程。Rails遵循“约定优于配置”的原则，提供了一系列工具和约定，帮助开发者快速构建功能丰富的web应用。它在过去二十年中一直是流行的后端框架，许多知名公司如Airbnb、Shopify、Github等都使用Rails构建。 ...

今天在Hacker New上看到了一篇称赞rust的文章Writing New Code in Rust Is a Win for All of Us。 原文内容就不贴出来了，maillist的内容一般都可以活的很久，随时可以去阅读。 虽然我很喜欢rust, 甚至从golang转了rust开发。 但是我没有过任何内核开发的经验，而且具体到C/C++语言我也只有大学的理论，没有实际的工作经验。 我只是一个一般的linux用户，和内核的交集只有内核升级以及编译裁剪内核，所以我没有和这篇文章产生强烈共鸣。 Gemini 我使用gemini总结了一下，存挡，看什么时候能和这篇文章共鸣。 这封邮件来自 rust-for-linux 邮件列表，讨论了在 Linux 内核中使用 Rust 语言的可能性。 Greg KH (Greg Kroah-Hartman) 是一位著名的 Linux 内核开发者和维护者。 他以在 staging 子系统、USB 子系统和驱动核心方面的工作而闻名。 他是内核社区中非常有影响力的人物，也是稳定内核版本的维护者。他的意见非常重要。 在这封邮件中，他强烈主张在新内核代码/驱动程序中采用 Rust 语言。 他指出，Rust 可以防止常见的 C 语言错误，例如内存覆盖、释放后使用错误以及错误处理问题。 他认为，使用 Rust 编写新代码将使开发人员能够专注于更复杂的错误，并创建更安全、更强大的 API。 Boqun Feng: 一位内核开发人员，他发起了这个特定的讨论主题，他对 Rust 内核策略提出了担忧。 他最初的电子邮件（未显示）可能质疑了采用 Rust 的明智性或可行性。 H. Peter Anvin (hpa): 另一位长期从事内核开发的开发人员，以其在 x86 架构和启动过程方面的工作而闻名。 他参与了关于底层内核细节的讨论。在显示的片段中，他提出 C++ 可能比 Rust 更渐进的方法，因为它可能更直接地改进现有的 C 代码。 Miguel Ojeda: 他似乎是 Rust for Linux 项目中最活跃的开发人员之一。他很可能完成了 Rust 绑定的很多工作。 Christoph Hellwig: 一位以其在存储和内存管理方面的工作而闻名的内核开发人员。他参与了关于性能和核心内核基础设施的讨论。 邮件还强调： 不断努力改进现有 C 代码的重要性。 Rust 在改进 API 设计和安全性方面的潜力。 开发人员为 Rust 集成做出贡献的意愿。 总的来说，这封邮件提出了一个令人信服的理由， 说明为什么应该在 Linux 内核中采用 Rust，强调了它在提高代码质量、安全性和可维护性方面的潜力。Greg KH 的支持是这次讨论中的一个重要因素。 ...