> So your argument is basically that if you keep adding users, at a certain point my system will break? I think that is a strawman argument. That's only part o

> So your argument is basically that if you keep adding users, at a certain point my system will break? I think that is a strawman argument. That's only part of my argument, and I don't think it is a strawman argument. > In my opinion, it is perfectly legitimate to have the requirement of low latency, while running lengthy operations in the background Ironically, this is a straw-man argument - I never said nor insinuated it wasn't a valid requirement. All I am saying is for the kind of scalability Go was designed for (1000s-100,000s connections), if you are doing lengthy operations, you will never be just thinking about multi-core, you will be scaling across servers. > then I guess it should not be branded as a general purpose, mainstream language Well I honestly am not sure it was. It was branded very early on as a language that is good for writing highly concurrent, highly scalable network servers. For example, integrating with C/C++ libraries is a pain, and slow. I would say most general purpose languages would have good C integration as a basic feature. And the lack of good C integration is a direct result of specializing Go at running millions of little Goroutines concurrently (segmented stack and all that).