Well, there are almost no real vectorizable primitives or functions in the core library so I&#x27;m not surprised that you don&#x27;t run into people vectorizing much. And, go dev team compiler focus has been elsewhere the last year.<p>And, so far the go team hasn&#x27;t seemed to be able to interest Intel in doing the heavy lifting that they might do for some other compilers..<p>So, branch predictions and faster sync primitives would be great, not least because they would speed up channels in many cases, which would be cool; it would be nice to widen the use cases for channel-based communication significantly, but they&#x27;re just VERY slow if you want to use them at scale in a large application.<p>I am using go for some large scale numerical processing, although it&#x27;s the sort with lots of logic attached, not just a giant matrix with some glue around it. It&#x27;s kind of a PITA. We are picking and choosing some outside libraries, and spend a lot of time massaging the go code for speed and bitching about the garbage collector. (Did you know that for i, _ := range is often 3 to 4x faster than for _, v := range? Do you know how awful code written down four or five nested loops that uses indices looks?)<p>But, the size codebase our team can manage with go is pretty great. We wouldn&#x27;t be nearly so productive in many other cool (or .. experienced) languages when you add up the full life cycle costs including innovation, enhancement, bug fixes, maintenance and deployment. It&#x27;s a win. I&#x27;d do it again in a heartbeat.