Apart from the 'easy to sandbox' (also debatable, as that depends way more on the functionality of the application than on what it is written in, but let's ignore that) does that matter much? pledge isn't only, or even primarily, a defense against you accidentally making syscalls you don't want to make, but a defense against malware that, having invaded your application's process, attempts to make such syscalls pretending to be you. That's code you didn't write, making the programming language choice moot.
Not really. An effective sandbox is restrictive. Managed languages tend to use a more limited set of system calls than non-managed languages because most libraries don't make any system calls of their own. The Go runtime and standard library use a more limited set of system calls than most alternatives, so a more limited set of sandbox filters are required.
Injected instructions are more likely to invoke their own system calls, so you are more likely to catch it if you have a more restrictive set of filters.
"Managed languages tend to use a more limited set of system calls than non-managed languages because most libraries don't make any system calls of their own"
I have a hard time understanding how that could be true. A library either needs to use OS functionality, or it doesn't. If it needs to, managed languages cannot avoid doing so, and if it doesn't, why would non-managed languages make them, more so since a major argument for the most popular of them, C, is performance?
The only argument I can see is that managed language libraries could use (fewer) other libraries or the runtime to make such calls. Neither decreases the number of system calls made by any program.
