我认为一个便携式Clojure CLI包装器的想法听起来不错，但就大多数平台而言：Linux、BSD、OSX，可能是bash更好的选择，因为它既高效又快，无需编译到不同的目标，也不需要32位和64位版本，也不需要为你的平台下载适当的版本。
如果Windows上GraalVM的原生镜像已脱离预览阶段，我会个人倾向于使用它。基于这个基准：https://github.com/chocolateboy/startup-time 显示，它的速度与bash相当，甚至更快。
基于以上基准和这个基准： https://github.com/bdrung/startup-time，似乎 Pascal 实际上拥有最小的启动时间，其次是 C。这表明 Nim 几乎和 C 一样快，比 Go 和 Bash 快。
依赖于另一种语言似乎有点奇怪，但另一方面，bash 也是一种语言，虽然出于某种原因，它似乎不那么奇怪。不过，Windows 不支持正常的 Bash 真是件遗憾的事。
如果 GraalVM 原生镜像的状态足够良好，以便在 Windows 上运行，我仍然会投票支持它。随着 Oracle 对其的积极研究，它应该会随着时间的推移而不断提高。我不认为 Clojure CLI 启动脚本所做的一切与 Graal 不兼容。而且一切都是在 Clojure 中。
否则，选择 Nim、C、Pascal 或 Go 而不是 bash，我认为这是维护者应该做出的决定。bash 的管道是最简单的，只需打包脚本，不需要为不同的目标编译它，也不需要发布不同的安装程序。这比 Graal 要简单得多。我理解为什么做出了这样的选择。但是，Windows 的情况确实可以作为一个论据来支持选择其他东西。
无论如何，我只是想在这里添加一些基准测试信息，特别是 Graal 原生镜像在启动时间上应该与 bash 竞争。
要使这更像一个答案，我想我是在回答 bash 提供了所有选项中最简单的打包方式，这使得它最初是一个明智的选择，但与 Windows 结合使用后，我们发现 bash 不够便携，因此我们可能需要两个实现，在这种情况下，一个是 bash，一个是 powershell，或者选择一个更便携的语言，如 Java，使用 GraalVM 编译，Nim 或 C，这将允许单个代码库跨平台运行，但这会带来更复杂的编译和打包流程。
