Scripts should be written using the project main language

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.