"自带电池"的生态系统是解决包管理器问题的唯一持久方案。如果你的首方工具包含你通常需要的所有功能，那么你有可能在没有任何第三方依赖的情况下进行高效开发。实际上你可能会有一些依赖，但你不会外包关键的东西，比如HTTP、TCP、JSON、字符串清理、加密。这些都是攻击者的诱饵。所有东西都依赖这些东西，因此攻击这些常见表面的动机很高。我可以说出在过去一年中我使用的第三方依赖数量，可以一只手数过来。Dapper是我经常使用的东西。有时会用ScottPlot。我两个SQL提供程序（MSSQL和SQLite）都是首方的。这也是为什么我只使用这两个SQL提供程序的原因。也许我只是因为在受监管的软件业务中经历过合规性和审计的创伤，但这种方式让我感觉构建软件更愉快。我的工具往往还停留在我前一天离开的地方。…
源讨论Axios在NPM上被入侵 - 恶意版本会下载远程访问木马原帖 807 条评论 · 导入时统计把你的经验，加入这段讨论。
这是一种相当夸张和目光短浅的「一切皆为钉子，因为我是锤子」的方法。事实是，这是一个极其困难的问题，至今没有人能妥善解决。
完整原文完全同意这个观点！我认为如今.NET可能是你能得到的最“自带电池”的平台。这意味着即使你使用第三方库，这些库通常只依赖于第一方依赖项，从而大大降低了有可疑内容潜入的可能性。
完整原文> 实际上，你可能会有一些，但你不会对像HTTP、TCP、JSON、字符串清理、加密这样的关键东西进行依赖管理。 除非你是Python，它的标准库包含了多个HTTP库，而每个人 anyway 都会安装requests包。 很少有语言有很好的模型来演进其标准库，因此你会发现自己长期保留很多糟糕的设计。库则更容易演进，在开发者体验和性能方面具有优势。
完整原文对于很多代码，我转向生成代码而不是使用第三方库。 像PEG解析器、路径查找算法、字符串清理器、数据类型转换等都可以很方便地由LLM生成。这很快，减少了依赖项，对我来说感觉更安全。
完整原文有哪些“自带电池”的语言，让这里的人们真正感到高效和/或喜爱？在你看来，它们为什么这么好？ （暂且不考虑语言语法、编译时间、工具等想法——只是对人们在健康标准库方面的体验和想法感兴趣）
完整原文或者你不用包管理器，任何人均可发布包（即使用你的系统包管理器）。仍然存在一些风险，但要小得多。比如，如果xz是通过PyPI或NPM分发的，那么所有人都会被入侵，但事实是（勉强）发现了这个问题。 确实系统仓库不会包含所有内容，但如果你真的需要，可以创建自己的仓库。实际上，对于我的需求来说，Fedora/EPEL基本上已经足够了。我现在正在用yocto部署一些东西，这在选择上稍微有限，但添加自己的包还是很简单的，而且它至少有哈希值，这样东西不会在我不知情的情况下被替换（坦白说，我不确定open-embedded的recipe的安全实践是否和Fedora一样强）。
完整原文“自带电池”的生态系统才是唯一的持久解决方案 或者自己写代码。没错，我说的就是这个。即使HTTP，甚至加密，也是如此。即使别人之前搞砸过一次，也不意味着没人应该去做。专业质量的软件应该进行定制。专业开发人员完全可以也应该这么做，并且做到正确。当你使用第三方HTTP实现时（比如），你不可避免地会引入比你需要的更多功能。如果你只是查询一个REST服务，你不需要MIME编码，但HTTP库中仍然包含它，因为有些客户端确实需要它。这个库（它会引入自己的所有库）只是不必要的臃肿，而这些东西其实并不难正确实现。
完整原文“自带电池”生态系统（如Python、C#/.NET和Java）有几个问题： 1. 它们不会包含所有内容。这包括一些新的文件格式。 2. 当标准发生变化时（如HTML等），应用发生变化时（例如SQL/ORM绑定的SQLite/PostgreSQL等），或者API发生变化时（DirectX、Vulkan等），它们会变得过时。 3. 像数据结构、图形API等，它们的性能特征可能与你的使用场景不同。 4. 它们无法涵盖所有好的使用场景，例如不同类型的游戏中使用的不同库和框架。 例如，Python的XML DOM实现只实现了部分XPath，并且不支持解析HTML。 Python、Java和.NET拥有庞大的库生态系统这一事实证明，即使你采用“自带电池”的方法，总会存在其他东西。…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。