I disagree, but they do take some effort to use effectively. Isaac (or someone) has spent a lot of time segregating out idiomatic simple, and overoptimized solu

I disagree, but they do take some effort to use effectively. Isaac (or someone) has spent a lot of time segregating out idiomatic simple, and overoptimized solutions. I have looked at the programs, and within the idiomatic programs similar to the types of stuff I do (not a lot of allocation) go varies between 30% and 300% more CPU time. And I have used it as I said. Because go is compiled to native people keep suggesting it is a systems language. Fortran is compiled to native too, but I don't want to write a kernel driver in it. Go has a huge niche, back-end. I think it has plenty of competition there with java and c#, but I reach for go because it makes things quick and easy. I might learn c# if back-end was my day to day, but it isn't. Using c++17 (don't know 20 yet) for very small embedded targets works fine, easy FFI into the BSP, small to no runtime depending on usage. Trying to target that with go would add a lot of extra challenge. I think something like rust or preferably a subset of it for c++ ise cases makes sense. My next project without a GPU I have penciled in rust on the plan. The other developers are excited. Still too hard to use gpu with it. Or rather too immature. The other developers like go too, but throughput will be critical without the gpu, and every little bit will count. And for numeric code it wouldn't just be a little bit of a hit. I wouldn't even suggest julia, and that is as close to a do-it-all language as I have seen.