CapNemo

通过网络连接 USB => 使用 USB/IP 项目 https://usbip.sourceforge.net/
通过网络连接硬盘柜 => 使用 NAS

理论上存在直接在主板上魔改，把网卡到 CPU 之间的连接替换的方案，不过

1. 不知道网卡和 CPU 之间是 PCIE 还是 USB
2. 信号完整性很难保证

@yanqiyu 是这样的，如果在内存里就坏了是无可奈何的。我想表达的意思是由于写入占比较低+视频文件对位错误的容忍度，因此 ECC 的必要性会降低一些。

试了一下，快是确实快，准确性就不太行了

@kxg3030 我记得在 CCPC/ICPC 等算法竞赛中，java 自带的大整数有时候挺有用的

没毛病，魔力即是能源

@lesismal 大部分人是能够做到根据实际情况做出技术栈的选择的。但是问题在于一部分用语言圣战掩盖自身无知和懒惰的人发出了巨大的噪音。

这部分人无限拥护自己所支持的语言的目的不是为了使某个项目变得更好，而是为了通过语言斗兽棋强行体现自身优越。

内存安全的 rust 是很好，但是如果没有在延迟上有特定的要求，我可能更倾向于支持 GC 的语言。

GO 无脑堆逻辑确实快，但是占一多半的 if err != nil return nil,errr 也确实碍眼。

我赞同你的 curd 是为这个世界服务的观点，在兼具高性能和安全要求的地方推广 rust 无可厚非。

语言的特性是一个事实，没有一个功能或语法就是没有。至于是否属于功能缺失，我觉得判断标准确实要落在是否影响实际工程应用上。

在我看来，不管是将 GO 的"功能缺失"强行解释为"哲学优越性"，还是以内存安全为由在各种项目上强行推广 rust ，这些行为都属于忽略实际条件去强行套用解决方法，本质上是编程领域的唯心主义。这种工具崇拜不仅引发争论污染公共讨论空间，也无助于提高自身水平。
必须认识到，编程的价值在于解决实际问题。脱离工程背景无限拔高某些设计取舍只能暴露自身视野之狭隘。
保持对技术本质的清醒认知，才能在快速迭代的生态系统中构建可持续的工程能力。
我最多只能说：在我遇到的某个特定场景下，使用某些语言/工具是合适的。但是绝对无法断言，这些语言/工具能满足任意场景的需要。
不过我倒是不反对在工程上的约束较为宽松时（比如不涉及合作开发的项目、性能不关键的项目等等）使用自己最熟悉/最喜欢的工具。