3 ms·
On the Python script, it sounds like the performance problems were more likely than not caused by inadequate use of any concurrency features rather than an inhe
by brown9-2 13y ago
On the Python script, it sounds like the performance problems were more likely than not caused by inadequate use of any concurrency features rather than an inherent problem with Python The Language. As exciting as Go is it sounds like replacing the old script with a sufficiently concurrent and well-written application in any language should have worked well.
More details would be really helpful. Also the author seems to be responding to a question of reliability by talking about performance which is not the same thing.
- Stephen_C 13y agoI doubt Andy would disagree with you, it's no slight or bad commentary against Python (Andy was the cheerleader for introducing Python into our infrastructure where it is blossoming nicely). With sufficient development time Andy could have introduced more concurrency and optimisation into the Python monitoring component (I'm thinking Gevent might have been a nice fit)...but without introducing additional frameworks or libraries Go had these features as a core component. The offhand performance comment aside, Andy was noting that a component written in Go is depended on to handle VERY high volumes of message throughput in a financial services firm. While no proof of reliability it is merely anecdotal support that Go is being used in production environments.
- coldtea 13y ago>On the Python script, it sounds like the performance problems were more likely than not caused by inadequate use of any concurrency features rather than an inherent problem with Python The Language. "Inadequate concurrency features" IS an inherent problem with Python The Language. (Notice I didn't say "inadequate use of concurrency features", I said "inadequate concurrency features").