> I run a service that uses 4 threads in Python and it's horribly slow and unreliable. I worked on a service in Go that used hundreds of concurrent go routines and it was reliable as hell.
That is very anecdotal to the point where I’m not sure it is all that useful. Go is supposedly good at parallelism, yet it has plenty of warts to the point where it is not at all more stable than any other mainstream language out there, so other than its pragmatism on channels, it really is not better than what you can do in Java or C#.
If parallelism is truly important for you than the actor model will be hard to beat in terms of reliability.
Java didn't have a comparable thread/worker model to Go until this year, and arguably added it because of the success of Go routines for highly parallel services.
Also, go accomplishes the same with much less verbosity because it's the default operating mode.
So yes, you can do everything with Java that you can with Go (not true with Python) but it's a bit like using a semi-truck to commute.
Let’s not mix up virtual threads with the overall paradigm used for parallelism. Sure, on the former front Go was ahead for a time, but both are still pretty prone to race conditions and all the usual problems associated with parallel code.
That is very anecdotal to the point where I’m not sure it is all that useful. Go is supposedly good at parallelism, yet it has plenty of warts to the point where it is not at all more stable than any other mainstream language out there, so other than its pragmatism on channels, it really is not better than what you can do in Java or C#.
If parallelism is truly important for you than the actor model will be hard to beat in terms of reliability.