> If you are not working in a domain like that, you need to measure to even know whether the language is even a significant bottleneck. Or, if one is confident

> If you are not working in a domain like that, you need to measure to even know whether the language is even a significant bottleneck. Or, if one is confident that the project can be done in Go, and that existing performance measurements of alternatives are accurate and show much worse performance, and the alternatives aren't much easier to use anyway, use Go and don't look back. Why optimize with FFI or extension modules when one can scrap that idea at little expense? As an analogy if I wanted a faster car I'd probably be better off switching cars than tweaking my existing car's engine.