The Reliability of Go

Re:The Reliability of Go by brown9-2 on Tuesday May 14, 2013 @09:18AM (#5704605)

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.

[ Parent | on HN ]

Re:The Reliability of Go by coldtea on Tuesday May 14, 2013 @10:17AM (#5704974)

>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").

[ Parent | on HN ]

Re:The Reliability of Go by Roboprog on Tuesday May 14, 2013 @10:46AM (#5705172)

It's been a while, but I remember that Python threads run into a global interpreter lock quite often, yes?

[ Parent | on HN ]

Re:The Reliability of Go by bvdbijl on Tuesday May 14, 2013 @01:08PM (#5706294)

Yes, unless your code is very I/O bound using threads won't speed up your Python application

[ Parent | on HN ]

Re:The Reliability of Go by Stephen_C on Tuesday May 14, 2013 @09:43AM (#5704736)

I 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.

[ Parent | on HN ]