Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Reliability of Go

andrewwdeane.blogspot.com

Post reply on HN
Print view View original

21–30 of 144 posts

Re: The Reliability of Go

#21

Post by CountHackulus »

raverbashing wrote: post #10

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.

Re: The Reliability of Go

#22

Post by _ak »

tezza wrote: post #12

If I had been at that conference, I would have asked the same question. Thanks for the data point (Yes, fine for production AFAYCT). What does Go do when it segfaults ? Simply saying it has not-yet-segfaulted is but one factor of production-readiness. Does Go leave just a coredump ? One thing I like about java in a production sense is that if the JVM exits unexpectedly it writes an hs_err_pid file that has a dump of…

Go doesn't segfault. If a Go program panics it prints stack traces of all goroutines (including the information which goroutine caused the panic) and then exits.

Re: The Reliability of Go

#23

Post by codonaut »

kenkam wrote: post #2

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

Re: The Reliability of Go

#24

Post by reinhardt »

Somewhat 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

Re: The Reliability of Go

#25

Post by rubinelli »

kenkam wrote: post #11
elithrar wrote: post #8

Earlier quoted context omitted.

> He implemented it in Go, but he could have implemented it in any other language I assume he used Go's concurrency features, although he could have articulated on that. > Where did he find the programmers I don't think you explicitly need to hire new programmers. If you have capable, existing programmers, the learning curve is pretty minimal for something like Go.

I agree with not needing to hire new devs, but convincing management and the business to move to a new, untried system with current devs is no trivial feat. It would be nice if he could expand on how that came about.

Go has the advantage of being "Google's language." This may sound stupid, but this credibility-by-association is a very important factor for a non-technical manager.

Re: The Reliability of Go

#26

Post by shocks »

reinhardt wrote: post #24

Somewhat 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. :)

Re: The Reliability of Go

#27

Post by j_s »

Stephen_C wrote: post #17
kenkam wrote: post #11

Earlier quoted context omitted.

I agree with not needing to hire new devs, but convincing management and the business to move to a new, untried system with current devs is no trivial feat. It would be nice if he could expand on how that came about.

Andy convinced management by spending a lot of personal development time creating and testing the Go components before demonstrating in a peer review process that they were an appropriate solution. There's no special method - the introduction of Go was incremental. If I remember correctly the monitoring collection component (mentioned in the blog post) was the first. It was small, easy to swap in and easy to demonstr…

Would be interesting to hear the details on management's side of the story: 'This guy re-wrote all our stuff in the new hotness then left the company'

Re: The Reliability of Go

#28

Post by rubinelli »

raverbashing wrote: post #10

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…

IIRC, Go tries to allocate a contiguous portion of virtual memory. This isn't a problem in 64-bit, because the addressable space is so big, but a 32-bit system that has been running for a while may have enough memory fragmentation that you can't allocate a large enough block.

I have to agree about libraries. You don't realize how great it is to have finely-tuned JDBC drivers for every database on Earth until you can't use them.

Re: The Reliability of Go

#29

Post by pcwalton »

4ad wrote: post #19
tezza wrote: post #12

If I had been at that conference, I would have asked the same question. Thanks for the data point (Yes, fine for production AFAYCT). What does Go do when it segfaults ? Simply saying it has not-yet-segfaulted is but one factor of production-readiness. Does Go leave just a coredump ? One thing I like about java in a production sense is that if the JVM exits unexpectedly it writes an hs_err_pid file that has a dump of…

Go programs don't segfault because Go is a memory safe language (unless you use unsafe). They can segfault in the runtime, but that never happened to me. Nevertheless, what happens when you segfault is a property of the system, not of the language implementation. It will happen whatever happens to C programs that segfault. Go programs can panic but that doesn't produce a core dump, only a stacktrace.

I've heard conflicting things here. I was under the impression that Go was not memory safe while mutating maps without synchronization.

For example, these articles allude to possible memory corruption:

http://golang.org/doc/articles/race_detector.html "memory corruption"

http://golang.org/doc/faq#atomic_maps

http://talks.golang.org/2012/splash.article "Go is not purely memory safe in the presence of concurrency."

Re: The Reliability of Go

#30

Post by swah »

Stephen_C wrote: post #17
kenkam wrote: post #11

Earlier quoted context omitted.

I agree with not needing to hire new devs, but convincing management and the business to move to a new, untried system with current devs is no trivial feat. It would be nice if he could expand on how that came about.

Andy convinced management by spending a lot of personal development time creating and testing the Go components before demonstrating in a peer review process that they were an appropriate solution. There's no special method - the introduction of Go was incremental. If I remember correctly the monitoring collection component (mentioned in the blog post) was the first. It was small, easy to swap in and easy to demonstr…

BTW, by component you mean program, right?
Post reply on HN