If I'm being honest with myself, I too have serious reservations about the extent to which Go is suited for scientific computation.
> I recommend jumping in the deep end and learning Haskell for what strong type systems can guarantee.
I'm superficially familiar with Haskell's typeclass system, but respectfully, this misses my point. What use is such a system in the context of scientific computing, or in the context of Go's mission?
I understand that there are type systems with stronger guarantees, but again, Go is not Haskell. Go is not Rust. Go is not solving these problems. My question is, in practice, what features of a type system are "these people" (the ones complaining about Go's type system -- I don't presume to label you, jerf, as one of them) pining for?
My (respectful) exasperation stems from the fact that these arguments usually compile down to something roughly equivalent to "Rust exists so why is Go not Rust? (Or Haskell)".
>I take the tradeoff because in the context I'm working, the simplicity of code tends to win out even so.
But this is exactly my point. At some point, adding features to the type-system is going to reduce the simplicity you enjoy in the context of problems for which Go was engineered. I appreciate that (to quote your linked comment) "the further away from a 'network server' you get, the less appealing Go gets", and that every success story you encounter with Go involves network servers. Moreover, I agree. Go nails this particular problem space, and I contend that this is in part because of the fast-and-loose design of its type system. We are in agreement with respect to Go's problem domain, and we are in agreement with respect to the fact that Go should not be viewed as a general-purpose concurrency language. These points, however, do not address the question of its type system.
So again: what more do you want this type system to do in the context of writing network servers? Which specific features from Haskell do you find yourself wanting, and what guarantee do we have that this would not undermine the simplicity and dynamic-i-ness that has made Go successful as a plumbing language?
>That said, I tend to consider scientific programming one of those, and a burgeoning community seems intent on proving me wrong, so shrug.
I'm inclined to agree with the caveat that certain disciplines (molecular bio and genetics for instance) increasingly rely on high-throughput streams of data. Perhaps Go is well-suited to the pipework, and perhaps it's advantageous to perform simple data transforms natively prior to doing the heavy lifting in Python or Julia ... I nevertheless remain unconvinced.