<story><title>Gonum – Numerical Computing for Go</title><url>http://www.gonum.org/post/introtogonum/</url></story><parent_chain></parent_chain><comment><author>openasocket</author><text>How does this play with Go&amp;#x27;s scheduler? My understanding is that the Go scheduler is not preemptive, and goroutines are switched out at yield point, like the start of a function body. So tight loops that don&amp;#x27;t call other functions can effectively hog the OS thread until it leaves that loop body (No idea what happens when doing FFI, maybe that&amp;#x27;s done in a separate thread pool?). For most cases where you would use Go you aren&amp;#x27;t generally doing a bunch of CPU-bound work so that doesn&amp;#x27;t matter, but here you might run into some hiccups. I&amp;#x27;m specifically thinking of a case where you use this library to do some heavy matrix operations as part of a web service, and those tight loops hog the OS threads and hurt your bandwidth and p90 latency.&lt;p&gt;My question to the developer: is that issue something you&amp;#x27;ve encountered with this library? If not, did you design the library to periodically yield in tight loops, or am I just completely wrong about the Go scheduler?</text></comment>
<story><title>Gonum – Numerical Computing for Go</title><url>http://www.gonum.org/post/introtogonum/</url></story><parent_chain></parent_chain><comment><author>paultopia</author><text>A solid, featureful &amp;amp; performant numerics library seems like a really good match for Go---if it can match numpy but also provide benefits like the safety of types, binary compilation, and better performance in non-numeric code, that&amp;#x27;s a really exciting case for sliding away from python?</text></comment>