As mentioned in #76, fork() isn't native to Windows and requires a expensive hack to emulate. While the go-script-bash framework itself avoids subshells and pipelines pretty thoroughly and itself runs fairly quickly everywhere, Bats is written in more traditional Bash that doesn't shy away from either. This makes the current suite of tests on Windows take on the order of 30min, when they take on the order of five or less on Linux and macOS systems. This is consistent across Git for Windows, Cygwin, MSYS2 (which is the basis for Git for Windows), and even the Windows Subsystem for Linux now included in Windows 10.

Also, knowing from experience that folks often won't write tests if they're slow to run—especially if it's too slow to experiment effectively and achieve the flow state necessary for deep learning—the inherent slowness of the Bats framework may turn off devs on Windows in particular. Since I'm hoping go-script-bash will prove not only useful for writing ./go scripts and other Bash apps, but also for encouraging thorough and effective Bats testing as well (with the lib/bats library helping out), the slowness may become a significant obstacle to this goal, especially for Windows users.

And there's a huge opportunity here, given the prevalence of Git for Windows and the Windows Subsystem for Linux! See also:

• Windows Subsystem for Linux installation guide
• The "WSL syscall examples" section of WSL System Calls for notes on emulating fork()
• Windows Subsystem for Linux Frequently Asked Questions
• Windows Subsystem for Linux Wikipedia page
• Fun with the Windows Subsystem for Linux

Consequently, I'm considering forking sstephenson/bats and seeing if there are any significant performance wins to be had without substantially complicating the code. On top of being a potentially huge positive factor for Windows, it will likely reap benefits for the other platforms as well.