语言与选型
语言不是「流行度排行榜」，而是问题域 + 团队能力 + 运行时约束的折中。本篇整理选型维度、常见语言族谱，以及评审时该问的问题。
选型维度
| 维度 | 要问什么 | 典型信号 |
|---|---|---|
| 问题域 | 延迟、吞吐、安全、交付形态 | 嵌入式 / 服务端 / 客户端 / 脚本 |
| 类型系统 | 编译期能拦住多少错误 | 静态强类型 vs 动态 + 测试兜底 |
| 运行时 | GC、所有权、VM、解释器 | 停顿、确定性、启动时间 |
| 生态 | 库、工具链、招聘与文档 | 包管理、LSP、官方指南质量 |
| 互操作 | 与现有代码、FFI、平台 API | C ABI、JNI、Wasm、Objective-C/Swift |
| 可维护性 | 团队已有经验、迁移成本 | 模块边界、重构工具、格式化约定 |
提示
默认策略：新服务优先选团队已精通且生态成熟的语言；仅在指标证明瓶颈（延迟、内存、部署体积）时再引入第二语言。
类型系统速览
| 风格 | 代表 | 优势 | 代价 |
|---|---|---|---|
| 静态强类型 | Rust, Swift, Go, Java, TypeScript (strict) | 接口契约清晰，重构安全 | 样板、泛型学习曲线 |
| 渐进类型 | TypeScript, Python + type hints | 迁移友好 | 严格度不一致时需 lint |
| 动态 | Ruby, Python (无检) | 原型快 | 回归靠测试与约定 |
实践：在 TypeScript / Python 项目里开启严格模式；把「边界类型」（API DTO、配置）集中定义，避免 any 扩散。
语言族与适用场景（笔记）
| 语言 | 我常用来解决 | 慎用场景 |
|---|---|---|
| Swift | Apple 平台 UI、系统 API、并发安全默认值 | 纯 Linux 服务端（除非已有 Swift 团队） |
| TypeScript | Web 全栈、工具链、与 JSON/API 紧耦合 | CPU 密集且无 Wasm/原生扩展 |
| Python | 数据脚本、胶水、快速内部工具 | 高并发长连接核心（应用 asyncio + 压测） |
| Go | 简单并发服务、CLI、容器侧车 | 复杂领域模型（缺少表达力时需纪律） |
| Rust | 性能/安全关键组件、FFI、基础设施 | 业务 CRUD 首版（迭代成本） |
以上为个人知识库视角，非排名；具体项目以度量为准。
评审清单（PR / 设计）
- 新依赖是否引入第二种内存模型或异步风格？
- 公共 API 是否有明确类型与错误枚举？
- 是否复用现有格式化、lint、测试框架？
- 脚本语言是否限制在边界层（构建、迁移、运维）？
性能与语言
语言 rarely 是首要瓶颈。在换语言前：
- Profile：CPU 火焰图、分配、锁等待。
- 算法与 I/O：N+1 查询、序列化、同步阻塞。
- 边界：热路径用原生扩展 / Rust / C，其余保持业务语言。