> What are the usual cgo issues? I've used it a fair bit and haven't had any general problems.
1. cgo calls have much higher overhead than regular function calls, so for small documents you'd likely lose performance rather than gain, and even for large ones depending how you read from the parser it might also be terrible, callback-based libraries are even worse as calling Go from C is even slower
2. concurrency can suffer a lot as a Ccall will prevent switching out the corresponding goroutine, locking out a scheduler thread
3. cgo complicates builds, especially cross-compilation
4. it also makes deployments more complicated if you were relying on just synching a statically linked binary
5. might have improved since, but used to be most of the built-in Go development tools couldn't cross the cgo barrier, and non-go devtools generally don't support go
1. cgo calls have much higher overhead than regular function calls, so for small documents you'd likely lose performance rather than gain, and even for large ones depending how you read from the parser it might also be terrible, callback-based libraries are even worse as calling Go from C is even slower
2. concurrency can suffer a lot as a Ccall will prevent switching out the corresponding goroutine, locking out a scheduler thread
3. cgo complicates builds, especially cross-compilation
4. it also makes deployments more complicated if you were relying on just synching a statically linked binary
5. might have improved since, but used to be most of the built-in Go development tools couldn't cross the cgo barrier, and non-go devtools generally don't support go