Scripts should be written using the project main language

Original Article ↗ Hacker News Discussion ↗

Whether automation scripts should be written in a project’s primary language or in classic tools like Bash, Python, or dedicated build systems is highly contested. Commenters weigh consistency, type safety, and reuse of internal APIs against factors like shell ergonomics, cross-platform portability, CI/CD needs, team skill sets, and the risk of turning simple tasks into complex, hard-to-maintain mini-projects, with many concluding that language choice should be driven pragmatically by the task and environment rather than a blanket rule.

Overall stance on “scripts in the main language”

  • Thread splits between “nice when it fits” and “dangerous generalization.”
  • Many insist it heavily depends on language, project type, deployment context, and team skills.
  • Some see the article as more moderate than the title suggests; others still view the idea as hammer‑nail thinking.

Arguments in favor of using the main language

  • Shared language reduces context switching and can reuse domain logic and APIs.
  • Easier to later migrate ad‑hoc scripts into scheduled jobs or production tools.
  • For some languages (Go, Kotlin, C#, JVM in general), scripting support or fast run tools make this practical.
  • Single‑language binaries (notably Go) simplify cross‑platform distribution and avoid Python‑style dependency headaches.

Arguments against / “use the right tool”

  • Many languages (C, C++, Rust, Java with full toolchains) are poor fits for quick filesystem/OS automation.
  • For infra and deployment, specialized tools (Ansible, Fabric, Terraform, Nix, Docker/Compose, Helm, etc.) often beat bespoke “deployment code” in the app language.
  • Embedding deployment logic into the main binary can blur concerns, become a fragile custom DevOps system, and lock non‑language experts out.
  • Scripts are often one‑off investigations; using a heavyweight language/toolchain is overkill.

Shell vs higher‑level scripting

  • Strong defenders of bash/sh emphasize ubiquity, tight integration with OS tools, and simplicity for small scripts.
  • Others highlight bash’s footguns, quoting rules, portability problems (macOS vs Linux, non‑GNU utils), and “works on my machine” failures.
  • Tools like shellcheck mitigate some shell risks; style guides suggest rewriting long/complex shell to a structured language.

Ecosystem‑specific experiences

  • Go is praised as an excellent “scripting” language via small CLIs or go run, especially for heterogeneous dev environments.
  • Kotlin scripting and custom shells show that a typed main language can provide a pleasant scripting experience.
  • C++ and Rust examples show pain: heavy rebuilds, platform‑specific binaries, and near‑universal reliance on external scripting languages (often Python).

Team, maintainability, and learning

  • Extra languages add onboarding, testing, and tooling overhead, but many argue engineers should handle a couple of common scripting languages.
  • Over‑complex, untested scripts are a bigger problem than language choice; comments stress testing, documentation, clear assumptions, and separation of concerns.
  • LLMs slightly lower the barrier to working in unfamiliar languages, but not enough to remove semantic and safety pitfalls.