Yeah, I think your view here is pretty close to the way I feel. It's unfortunate, because I think Go generally gets a lot of stuff really right. But it too oft

Yeah, I think your view here is pretty close to the way I feel. It's unfortunate, because I think Go generally gets a lot of stuff really right. But it too often feels that it prizes simplicity in implementation or specification over simplicity of how code is read and written. Writing Go feels like having a little rock in my shoe. I think it comes from that situation where you know some property of the code you are writing (e.g. "this thing cannot be null"), but there is no method to assert this to the computer. And so instead of my very fast and logical computer with lots of memory enforcing this for me, I have to carry that knowledge around in my own lossy memory as a little bit of baggage and hope I never put it down and forget about it. And I find that this comes up in Go all the time. That sucks because Go is still—despite all this—probably the best overall solution for the kind of apps I end up writing a lot. I really do think that there's still a space in there for a language sitting on the complexity scale between Go and others around the level of Java/Swift/Typescript, which can benefit from both some excellent design decisions of the former, and some of the expressiveness- and correctness-enhancing features of the latter.