[翻译] 为什么 Tracebit 用 C# 开发
原文: [Why Tracebit is written in C#]
作者: [Sam Cox (Tracebit联合创始人兼CTO)]
译者: [六六]
(译注:Tracebit成立于2022年,是一家提供云威胁检测服务的公司。其平台采用轻触式基础设施,企业可以在短短30分钟内在云网络上设置和打开威胁欺骗。目前,Tracebit已经保护了超过250个云账户和1500个云金丝雀资源,每周处理超过24亿个安全事件。)
当我们开始构建 Tracebit 时,我面临的首个决策是个很常见的问题 -- 选择什么样的技术栈?其中一些选择相当容易(例如AWS、Postgres),但让我犹豫的是选择哪种编程语言?我最终的选择可能出乎你的意料,甚至在我最初评估选项时,也未曾预料到自己会做出这个决定。
Tracebit 是一款面向企业的 SaaS 安全产品。如果向工程师(尤其是某橙色技术网站的读者[译注: hacker news网站])发起调查,询问此类系统的“最佳”语言,常见的答案可能是Python、TypeScript、Golang、Rust、JVM系语言,或是Elixir。显然这里没有“标准答案”,但经过深思熟虑,我们选择了一条不同的道路:用 C# 开发 Tracebit。
为什么选择C#?
关于创业公司技术栈选择的常见建议是“坚持你熟悉的技术” -- 尤其是已验证有效的技术。这无疑是真理,也使得大多数决策变得容易。
在我的职业生涯中,我曾用 Python 和 TypeScript 开发过大型且至关重要的代码库。我见证过它们的优势(生态系统、招聘便利性、工程师上手速度),但也亲历过明显的短板(动态类型、包管理与依赖项维护、大型代码库的维护)。
因此,在选择语言时,我希望探索包括未曾使用过的语言。
选择标准
开发效率
如果要定义我对编程语言的核心诉求,那便是开发效率。总的来说,我认为能让开发者把时间花在重要工作的技术栈,才是良好开发体验的本质。
效率的维度众多,且在产品或公司生命周期的不同阶段有不同的相对重要性。
早期阶段:快速迭代和验证想法的能力至关重要,因为你很可能在错误的方向上投入。这种验证应在编码前开始,但编码时需选择能快速表达想法并实现产品的语言。
维护阶段:所有软件都需要维护。随着对问题域的理解加深和功能扩展,需能安全高效地重构代码,同时尽量减少无益于产品或工程师的维护时间。
规模化阶段:当产品、代码库和团队扩大时,该语言能否保持生产力和软件的可持续性?
截至目前,.NET展现出惊人的生产力,我们相信它是未来发展的坚实基础。
免费与开源
我们希望在开源(且免费)的平台上构建产品。无法查看实现细节会增加开发难度,而早期阶段我们希望避免不必要的开支。
几乎所有候选技术栈都满足这些条件[1]。但此前我未意识到,.NET 如今已是 MIT 协议的开源免费框架。微软可能意识到真正的利润来自 Azure 的算力销售,而更多 .NET 开发者意味着更可能选择 Azure 部署。当然,部署 .NET 并非必须使用 Azure -- 我们目前就没有!微软从我们这赚到的钱,单一个 Teams 许可证就超过整个技术栈的费用。
跨平台支持
我已 15 年未使用 Windows,也绝无兴趣在其上部署生产系统!提到这点是因为我很惊讶地发现,C#/.NET 是真正的跨平台框架 -- Tracebit 的首行代码就是在 Arch Linux 上毫无困难地编写的。现在我们用 MacBook 开发,部署于 ARM 架构的 Linux 服务器。
微软甚至与 Ubuntu 合作提供“精简化”的Docker基础镜像,以最大限度地减少攻击面和补丁管理,同时从可信且广泛兼容的上游直接获取安全更新。
流行度
语言流行度虽不直接代表质量,但至关重要:
业务扩张时需要快速招聘工程师,若人才池不足将限制企业发展速度。对初创公司而言,团队扩容往往是工程侧的最大瓶颈。同样重要的是,工程师获得的技能应具备行业通用性,助力其职业发展。
流行语言的优势还包括:
- 丰富的SDK/库资源
- 海量文档和在线示例(及LLM训练数据)
- 更少成为语言特性或核心库缺陷的首个踩雷者。
所有这些都有助于工程师提高工作效率。
所以我们只考虑 TIOBE 前 20 和 Stack Overflow 开发者调查中的语言。其中 C# 相当稳定地排在第 5 位(对于通用语言而言)。
(Stack Overflow开发者调查截图)
看到它如此受欢迎,我有点惊讶,但我不得不提醒自己,流行度并不等同于时髦度 -- C# 与时髦不沾边。C# 很少登上 Hacker News 头条(我认为相对于用户群而言,它可能是讨论最少的语言),就像你不会经常看到人们赞美在 Linux 主机上部署软件或使用关系数据库的优点 -- 但这并不意味着这些不是受欢迎的选择,而是意味着有很多人只是默默地使用它。
内存安全
内存安全是完全没有商量余地的 -- 这感觉毫无争议,我觉得不值得多讨论。当CISA都在呼吁《软件产品内存安全的迫切需求》时,用 C 语言开发安全创业产品简直是行为艺术。
垃圾回收
为何需要GC?或者说“为何不选Rust”?因为我们不做实时/系统/嵌入式编程,可以承受GC暂停。我不想冒这样的风险,选择 Rust 后,我会花更多的时间与借用检查器搏斗,而不是迭代产品。
静态类型
静态类型至关重要。基于动态和静态类型语言的双重经验,我认为静态类型在编码时引入的“开销”,会通过代码可读性和可维护性获得超额回报。尽管存在争议,但静态类型确实能减少错误,还能提升性能。
对我而言,核心价值在于提升代码阅读和维护效率。静态类型帮助我快速理解记忆模糊或陌生的代码意图与实现。更不用说 IDE 中 "查找所有引用"/"跳转定义" 的精准性,以及更自信的重构能力。
如果把类型系统视为从 'true + true == "2"' 到 ' A monad is a monoid in the category of endofunctors '(译注: 函数式编程的梗) 的光谱,C# 恰好处于中间位置。它拥有我欣赏的实用特性(泛型、record类型、运行时支持、合理推断)。我唯一真正怀念的是联合类型,目前仍处于提案阶段。
至于渐进式类型?我曾用此类语言构建重要生产系统,但最终心态变成 "逐步将动态类型代码转为静态类型",而非 "太好了,新代码不用考虑类型"。既然如此,何不从一开始就选择目标方案?尤其当整个生态的同行和依赖项都如此实践时[2]。
稳定性
这是 C#/.NET 真正闪耀的领域:每年同一时间发布主版本,LTS(长期支持)和STS(短期支持)交替。LTS获得3年补丁支持,STS为18个月支持。变更文档完善、测试充分且向后兼容。生态系统中的大部分都遵循此发布节奏,因此核心依赖项能立即受益于新语言特性、数据类型和性能改进,并经过协同测试。
(.NET发布周期截图)
如果你来自不支持或较少使用访问修饰符(public/private/internal 等)的语言,初期可能觉得冗长或受限。但在主版本升级时,这些设计会带来回报,因为你只需关注依赖项公开的 API 接口。
自 Tracebit 启动以来,我们已完成三次主版本升级,每次都非常顺利(耗时均不足一天)。
开箱即用
NET 平台包含大量优质库、API 和框架。你想要实现任何功能,很可能会在 .NET 团队 / Microsoft 维护的库中找到解决方案 [3]。无论是通用集合、日期 / 时间函数、大 JSON 文件流式反序列化、加密函数、结构化日志、测试框架、世界级 HTTP 服务器、OpenIdConnect 实现、ORM、WASM 编译器、OpenAPI 规范生成,还是分布式 Actor 框架 -- 应有尽有。
这点对我们价值难以估量。在某些生态系统中,你可能会陷入选择困难,耗费大量时间评估 n 个依赖项:
- 其许可协议是否合规?会变更吗?
- 维护者是谁?可信度如何?
- 会引入多少传递依赖?
- 性能 / 测试 / 文档是否达标?
- 会导致多少 Dependabot 警报?补丁发布速度?
- 是否应该自行实现?
Tracebit 作为需要客户环境特权的安全产品,我们必须严格把控这些因素。明确回答 "如何实现这个问题?" 能为初始开发和持续维护节省大量时间。某些使用 node 实现的简单 CSS 的构建,其依赖项数量甚至超过我们整个 C# 产品!
工具链
成熟生态系统带来的丰富高质量工具是另一大优势。我们使用 Rider -- 这是一款出色的 IDE,非商业用途免费 - 我强烈推荐它。它具备所有预期功能(调试、测试、重构等),还支持动态程序分析等高级特性,能自动检测低效数据库访问模式、过度内存分配、缓慢 HTTP 处理程序等问题。交互式调试无缝且强大,内存分析、快照对比、堆检查、泄漏检测等功能一应俱全。
(动态程序分析检测高行数查询的截图)
还有大量的静态分析器可用,它们可以提供很好的防护,通常内置自动修复功能。
(JetBrains dotMemory工具截图)
还有可轻松集成到 docker 镜像中的运行时诊断工具,能收集海量诊断数据直达问题核心。例如,我们曾通过收集预发环境的跟踪和堆转储,快速解决本地未复现的性能问题 -- 否则需要繁琐地添加日志埋点、跨度指标等来定位问题根源。
性能
性能很少是选择语言的主因,但无疑是锦上添花。从这个角度看,C# 表现优异。观察最具代表性的 TechEmpower 基准测试 "fortunes"(使用 ORM 和完整框架),主流的 .NET 技术栈位列第 10(共 80 个)。可以公平地说,排名再靠前的框架多数较为小众,并非你会随意采用的技术。
虽然我不太看重基准测试,但明显性能是 .NET 团队的重点关注方向。每个新版本发布时,我都期待阅读那些详述最新性能优化的深度文章,以及升级带来的显著改进。有些问题难以水平扩展,节省下来的优化和排障时间可以投入其他领域。
TechEmpower 'Fortunes' 基准测试前 15 名(ORM & 完整框架)
功能特性
.NET 有许多令人印象深刻的技术特性和高效工具:LINQ、Entity Framework、TPL Dataflow、ASP.NET、F# 等等。这些绝对值得深入研究 -- 我真诚认为某些功能在其他技术栈中无可匹敌。
实践效果如何?
启动 Tracebit 时我们面临许多需要快速决策的事项。语言选择只是其中之一,虽然当时感觉存在风险,但我对选择 C# 感到满意。至今我们已提交数千次 commit,发布超 10 万行代码,包括从未接触过 C# 的工程师。所有人都能快速上手(否则我们早就弃用了!)。C# 是我们取得当前成就的关键要素,从未出现意外状况。在许多方面,它甚至超出了我的预期。
语言选择没有银弹,终究是主观决策。很可能其他选择同样能带来满意结果。
本文某种程度上是写给曾经持有偏见的自己(完全不会考虑 C# 的那个自己):值得重新审视。对于任何认真考虑 C# 的读者:希望你们也能享受它!
脚注
虽然对 Java 的情况不太确定。如果说我对微软存在某些成见,那我对 Oracle 的成见更深!OpenJDK 似乎是 GPL 许可,不确定能否在自己的项目中借用或改编其标准库代码。鉴于 Java 的广泛使用,我的理解可能有误。 ↩︎
严格来说 C# 支持动态类型,但仅限特定场景且非常用写法。静态类型是 "默认选择" 而非 "可选添加"。这类似于 Rust 的unsafe或 Haskell 的unsafePerformIO -- 例外反证了规则。 ↩︎
并非否定优秀第三方开源库的存在 -- 确实有很多。当这些库获得广泛关注时,.NET 团队乐于接纳并扩展它们以惠及所有用户。例如提供广泛兼容的日志和指标接口,只需 "启用"OpenTelemetry 就能以统一方式输出日志、指标和跨度(包括依赖项的数据)。 ↩︎
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· .NET 使用 DeepSeek R1 开发智能 AI 客户端
· 10亿数据,如何做迁移?
· 推荐几款开源且免费的 .NET MAUI 组件库
· c# 半导体/led行业 晶圆片WaferMap实现 map图实现入门篇
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!