'Performance' is not a bullet point. Please do not wave hands about 'performance' without thinking about the actual benefit in the actual domain you are programming in.
If you need to write fine-grained embedded, DSP or graphics code you are probably going to use a true low level language like C or C++ anyway, not a gc language.
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. By the time you have measured you can often find a targeted place to optimize with FFI or extension modules.
If you are using a language just because you think it is faster at everything, you are optimizing prematurely and in a somewhat naive way.
Performance is a huge bullet point for me. A language such as Python or Ruby requires you to make considerations (writing performance-sensitive code by shelling out to a native C extension, for example) that don't crop up in a natively compiled language such as Go.
In fact, for performance-sensitive things the difference is often staggering, even for things that scripting languages were originally invented for, such as text processing. Performance-sensitive doesn't always mean "DSP or graphics code". If you want to process huge log files in Ruby, for example, you can start as many threads you like to attempt to parallelize it without getting anywhere because of the global interpreter lock, and will find yourself resorting to things like forking off child processes. Ruby would be a bad fit because it does not perform well. I often end up writing such processing code in Lua (using LuaJIT) because of the dramatic difference in performance.
One must always consider the domain, but performance is one important facet of Go: Go gives you high performance without sacrificing much of the expressiveness of dynamic languages such as Python and Ruby. (Conversely, C/C++ gives you high performance without the same expressiveness.) If Go had the same VM as Ruby I would probably never consider using it for anything, as I don't see any language-level benefits that outweigh the performance aspect.
> 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.
If you need to write fine-grained embedded, DSP or graphics code you are probably going to use a true low level language like C or C++ anyway, not a gc language.
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. By the time you have measured you can often find a targeted place to optimize with FFI or extension modules.
If you are using a language just because you think it is faster at everything, you are optimizing prematurely and in a somewhat naive way.