[anamitra-]

I disagree. Go's main plus point is concurrency, whereas the irony is it lacks thread safety—something languages such as Java have had from, let's say, day one. You can fix that issue by manually managing sync.Pool objects for performance and, on top of that, use channels, but this completely defeats the purpose of Go's simplicity. Even if you want a top-of-the-line performance with some convenience, there exists an open-source framework called Netty. It is an absolute beast for network I/O, beating out Rust in some cases and sitting just behind C. And it's all in Java.

[pjmlp]

My point was not about Go vs Java.

[anamitra-]

You missed a bit of my point. The point am trying to convey is that what it was made for that is efficiency and networking it fails somehow and somewhere in both. As i was surprised when i came across the thread safety issue of go which for me was diabolical, because go was meant to be lean at least on threads while maintaining thread safety by default.

The next point would be gc,maybe it can be improved and its being improved the recent being mark sweep algorithm was made a bit efficient by addition of more meta data about the total object structure, not going into it more.

Thing is it breaks the fundamental promise it was suppose to keep and yes its better than rust for network applications(am talking of getting things done in default way). It's stdlib is the strongest among all languages.

That summarises my point go needs severely improve it's issue of thread safety by default provision and gc efficiency.