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

11–20 of 144 posts

Re: The Reliability of Go

#11

Post by kenkam »

elithrar wrote: post #8
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…

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

Re: The Reliability of Go

#12

Post by tezza »

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 what the threads are doing at the point of failure.

Re: The Reliability of Go

#13

Post by Ecio78 »

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.

Probably that would be the most interesting part of the story...

Re: The Reliability of Go

#14

Post by threeseed »

TheAnimus wrote: post #9
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 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.

Re: The Reliability of Go

#15

Post by [deleted] »

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…

[deleted]

Re: The Reliability of Go

#16

Post by kenkam »

TheAnimus wrote: post #9
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 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…

I think async/await is semantically similar to the promises pattern [1] but different to the Go concurrent models using channels. What the compiler does with await/async is quite interesting [2]. Essentially it takes your await/async code and turns the related code into a state machine which keeps track of how control should be switched between the callee and the await keyword (and uses Task for the async bit).

[1] http://blog.parse.com/2013/01/29/whats-so-great-about-javasc...

[2] http://www.codeproject.com/Articles/535635/Async-Await-and-t...

Re: The Reliability of Go

#17

Post by Stephen_C »

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.

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 demonstrate the improvements.

You build trust in the technology and work flow before moving on to larger more critical/risky projects.

(Andy is very much missed by his former colleagues)

Re: The Reliability of Go

#19

Post by 4ad »

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.

Re: The Reliability of Go

#20

Post by brown9-2 »

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…

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.

Post reply on HN