While I agree with most arguments, I think there a two major objections:
Do you really want to replace some well-proven C library by some rewrite that possibly introduces many new bugs?
Go has a relatively simple compiler backend that does not do a lot of optimization, let alone auto-vectorization (because compile times). So, often the choice is between: being slow, writing everything in Go assembler, or just linking to optimized C code.
I also think that the problem of compile time is overstated, since Go only recompiles a package or one of its dependencies has changed. E.g. my liblinear bindings compile in 1.1 seconds on a Intel Core M-5Y31 and this overhead is only present when I change the bindings.
While I agree with most arguments, I think there a two major objections:
I also think that the problem of compile time is overstated, since Go only recompiles a package or one of its dependencies has changed. E.g. my liblinear bindings compile in 1.1 seconds on a Intel Core M-5Y31 and this overhead is only present when I change the bindings.