I remember some time ago a complaint about Go having some bugs on 32-bit machines (something related to the GC) So yes, if you have control over your environment it may be a better choice But the biggest issue with 'less than mainstream' languages are libraries. Things like DB connectors, protocol libraries (SOAP for example - yes, unfortunately this is necessary for some 3rd part services), etc Heck, even for Python…
Every compiler has bugs. All of them, even ICC, xlC, and other heavyweight ones. The fact that Go has a bug in the GC on a 32-bit machine is hardly surprising.
The Reliability of Go
31–40 of 144 posts
Re: The Reliability of Go
#32Somewhat off-topic but are there any data on the penetration of Go outside Google, a few other companies [1] and weekend hack projects on Github? Thanks to its unfortunate name, even searching for Go developer positions is challenging [2]. [1] http://go-lang.cat-v.org/organizations-using-go [2] http://www.indeed.com/jobs?q=go+developer
Use the keyword 'golang' instead. :)
This could have been a better name in my opinion. One should stay away from frequently used English words.
Re: The Reliability of Go
#33I would like to hear more about the technical implementations from the author on how he managed to improve performance. He mentions: "Due to the complex nature of the system this script could take up to three minutes to scan nodes and process the results" but how does Go solve this complex system that Python couldn't? 3 minutes to 1 second is a superb improvement. The second paragraph reads like: replacing a relation…
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…
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.
Re: The Reliability of Go
#34I would like to hear more about the technical implementations from the author on how he managed to improve performance. He mentions: "Due to the complex nature of the system this script could take up to three minutes to scan nodes and process the results" but how does Go solve this complex system that Python couldn't? 3 minutes to 1 second is a superb improvement. The second paragraph reads like: replacing a relation…
Can anyone explain why exactly a script written in one language would stall, while the same script in another wouldn't? Is there that much inherent instability in Python? Can it be assumed that the scripts in this case aren't comparable?
> Can anyone explain why exactly a script written in one language would stall, while the same script in another wouldn't?
It stalls in Python because the author is not acquainted with non-blocking system programming (the select()-call, which has been around since at least the eighties and has been a part of core Python since a very long time).
As to why a software developer who did not invest some minimal time into learning basic system programming feels qualified to write a blog post about this topic is another question.
Re: The Reliability of Go
#35Earlier quoted context omitted.
>I assume he used Go's concurrency features, although he could have articulated on that. I've yet to find a good explanation of what is so special about them, why I'd choose it over F# or C# Async/Await. In the case of pinging servers, I would have prefered to use a 'cheaper' to develop language, which has a boatload of libraries that are widely used. Anyone got any links or stories about why you would want to use Go…
This is a good overview of Go concurrency: http://www.slideshare.net/jgrahamc/go-oncurrency As a Java developer I personally don't find it that impressive compared to something like the LMAX Disruptor or even Vert.x but I can appreciate that it is simple and that always counts for a lot.
As an Ada 95 developer, I like that Go seems to have an Adalite concurrency-related syntax.
Re: The Reliability of Go
#36I remember some time ago a complaint about Go having some bugs on 32-bit machines (something related to the GC) So yes, if you have control over your environment it may be a better choice But the biggest issue with 'less than mainstream' languages are libraries. Things like DB connectors, protocol libraries (SOAP for example - yes, unfortunately this is necessary for some 3rd part services), etc Heck, even for Python…
Every compiler has bugs. All of them, even ICC, xlC, and other heavyweight ones. The fact that Go has a bug in the GC on a 32-bit machine is hardly surprising.
No need to split hairs.
Go had an easy to run into and not obvious to fix bug on 32bit. That's a bigger problem than most gcc/ICC/whatever bugs, which tend to be happen in obscure corner cases (because the most obvious bugs are long gone).
Re: The Reliability of Go
#37I would like to hear more about the technical implementations from the author on how he managed to improve performance. He mentions: "Due to the complex nature of the system this script could take up to three minutes to scan nodes and process the results" but how does Go solve this complex system that Python couldn't? 3 minutes to 1 second is a superb improvement. The second paragraph reads like: replacing a relation…
Can anyone explain why exactly a script written in one language would stall, while the same script in another wouldn't? Is there that much inherent instability in Python? Can it be assumed that the scripts in this case aren't comparable?
Without actually be able to see either script, I would assume that his Go implementation took advantage of some of Go's more natural concurrency features.
The only reason I'd assume the Go version was concurrent and the Python one wasn't is that concurrent processing in Python can be very prickly. That is by design. Guido has talked about how adding too much support for concurrency at the language level would complicate things and probably end up with a language that was very non-Pythonic.
Re: The Reliability of Go
#38Earlier quoted context omitted.
This is a good overview of Go concurrency: http://www.slideshare.net/jgrahamc/go-oncurrency As a Java developer I personally don't find it that impressive compared to something like the LMAX Disruptor or even Vert.x but I can appreciate that it is simple and that always counts for a lot.
As an Ada 95 developer, I like that Go seems to have an Adalite concurrency-related syntax.
Both systems have a CSP design, right? Golang is pretty up front about having lifted its design from Hoare.
Re: The Reliability of Go
#39I'm sorry, but the world does not need another company-controlled, corporate programming language. .Net (Microsoft), Java (Oracle) and now Go (google).
All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards).
It bothers me to no end to see corporations taking control of the fundamental building blocks (programming languages) of technology and then to see technologists and developers go on and on about how wonderful and better these corporate languages are.
With C and C++ and Python and Ruby and Perl we have freedom. With Go, .Net and Java, etc. we do not.
Google already control your search, your browser, your phone, your email and in some cases your OS (Chrome) why would you want them to control you programming language as well? The idea boggles my mind.
I wish others felt as strongly about this as I do. If you want to control your future, then use C or C++ or some other ISO standardized language with lot's of free compilers available, do not use a corporate controlled programming language.
There is a reason go compilers are C and C++.
Re: The Reliability of Go
#40Earlier quoted context omitted.
Can anyone explain why exactly a script written in one language would stall, while the same script in another wouldn't? Is there that much inherent instability in Python? Can it be assumed that the scripts in this case aren't comparable?
> Can anyone explain why exactly a script written in one language would stall, while the same script in another wouldn't? It stalls in Python because the author is not acquainted with non-blocking system programming (the select()-call, which has been around since at least the eighties and has been a part of core Python since a very long time). As to why a software developer who did not invest some minimal time into l…
It's funny how people who learn evented programming in scripting languages like Python feel like they've discovered some new hidden concept. No competent systems developer fails to understand what select() does. Suggesting that the author was't "acquainted" with select says more about this comment than about the author of the post it comments on.