脚本应使用项目的主语言编写

关于“使用主语言编写脚本”的总体立场

• 讨论在“适合时很不错”和“危险的泛化”之间分裂。
• 许多人坚持这高度取决于语言、项目类型、部署环境和团队技能。
• 有些人认为文章比标题看起来更温和；另一些人仍然把这个想法视为锤子看钉子。

支持使用主语言的论点

• 共享语言可减少上下文切换，并可复用领域逻辑和 API。
• 之后更容易把临时脚本迁移为定时任务或生产工具。
• 对某些语言（Go、Kotlin、C#、JVM 整体而言），脚本支持或快速 run 工具使这很实用。
• 单语言二进制文件（尤其是 Go）简化跨平台分发，并避免 Python 式的依赖问题。

反对 / “用合适的工具”

• 许多语言（C、C++、Rust、Java 配合完整工具链）并不适合快速的文件系统/操作系统自动化。
• 对于基础设施和部署，专用工具（Ansible、Fabric、Terraform、Nix、Docker/Compose、Helm 等）往往比应用语言里的定制“部署代码”更好。
• 将部署逻辑嵌入主二进制会模糊职责，变成脆弱的定制 DevOps 系统，并把非语言专家挡在外面。
• 脚本通常是一次性调查；使用重量级语言/工具链属于大材小用。

Shell 与更高层脚本语言

• bash/sh 的坚定支持者强调其无处不在、与操作系统工具紧密集成，以及用于小脚本时的简洁性。
• 其他人强调 bash 的坑、引用规则、可移植性问题（macOS vs Linux、非 GNU 工具）以及“在我机器上能跑”的失败。
• shellcheck 等工具可缓解部分 shell 风险；风格指南建议把冗长/复杂的 shell 重写为结构化语言。

特定生态中的经验

• Go 因小型 CLI 或 go run 被赞为出色的“脚本”语言，尤其适合异构开发环境。
• Kotlin 脚本和自定义 shell 展示了静态类型主语言也能提供令人愉快的脚本体验。
• C++ 和 Rust 的例子则显示出痛点：重建耗时、平台特定二进制，以及几乎普遍依赖外部脚本语言（通常是 Python）。

团队、可维护性与学习

• 额外语言会增加入职、测试和工具链开销，但很多人认为工程师应当掌握一两种常见脚本语言。
• 过于复杂、未经测试的脚本才是更大的问题，而不是语言选择；评论强调测试、文档、清晰的假设和职责分离。
• LLM 略微降低了使用不熟悉语言的门槛，但不足以消除语义和安全方面的陷阱。