5 ms·

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

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

TheAnimus 13y ago
>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 for something like that? I don't find this blog story remotely useful in the whole 'why Go' thing.
- threeseed 13y ago
  This is a good overview of Go concurrency: http://www.slideshare.net/jgrahamc/go-oncurrency 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.
  - randomsearch 13y ago
    As an Ada 95 developer, I like that Go seems to have an Adalite concurrency-related syntax.
    - tptacek 13y ago
      Both systems have a CSP design, right? Golang is pretty up front about having lifted its design from Hoare.
      - randomsearch 13y ago
        Yes, you're right - the design comes from CSP. The syntax looks nicely Adalike.
- kenkam 13y ago
  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-javascript-promises/ http://blog.parse.com/2013/01/29/whats-so-great-about-javasc... [2] http://www.codeproject.com/Articles/535635/Async-Await-and-the-Generated-StateMachine http://www.codeproject.com/Articles/535635/Async-Await-and-t...
  - TheAnimus 13y ago
    Thanks for replying. But I'm not trying to say that async/await are superior to the actor paradigm (which is what my understanding Go subroutine, don't call em threads things are). Just that I would have hazarded a guess for pinging a bunch of servers, the TPL stuff is a better choice, than actor? I feel there is a lot of buzz around Go, though I'm not seeing why. I guess my only option is to find something suitable enough for it, and give it whirl. But of course I am lazy, so trying to find someone elses suitable experiences would be great.
kenkam 13y ago
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.
- Ecio78 13y ago
  Probably that would be the most interesting part of the story...
- Stephen_C 13y ago
  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)
  - j_s 13y ago
    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'
    - Stephen_C 13y ago
      Well what sort of story are you expecting to hear? Without going into detail it's not really that exciting. There was a requirement for high volume/through put messaging component in our infrastructure. That technological requirement (along with non functional requirements e.g. development time/costs) was more than adequately met by a program(s) written by a team member written in Go. Was it an opportunity to further explore the "new hotness" that is/was Go…absolutely but the solution could have been implemented in one of the other supported technologies C/C++/Java with appropriate advantages/disadvantages associated with each. It will stay in use for as long as it provides the best solution, if that changes a more appropriate solution will be investigated. > 'This guy re-wrote all our stuff in the new hotness then left the company' The Go dataStore is "a" component within a large infrastructure, it is supportable by more than one member of the development team (a core requirement when deploying any new technology to production). I'll also note that before Andy left, being a professional and thoughtful colleague, he put a lot of effort into ensuring appropriate training and knowledge was given to team members that had not been part of the deployment. As Andy is a very well regarded former colleague, it helps that we could easily get in touch for a query, even when we're out for a beer or five* :) (*five might not be a maximum in that scenario)

TheAnimus 13y ago

>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 for something like that? I don't find this blog story remotely useful in the whole 'why Go' thing.

threeseed 13y ago
This is a good overview of Go concurrency: http://www.slideshare.net/jgrahamc/go-oncurrency 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.
- randomsearch 13y ago
  As an Ada 95 developer, I like that Go seems to have an Adalite concurrency-related syntax.
  - tptacek 13y ago
    Both systems have a CSP design, right? Golang is pretty up front about having lifted its design from Hoare.
    - randomsearch 13y ago
      Yes, you're right - the design comes from CSP. The syntax looks nicely Adalike.
kenkam 13y ago
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-javascript-promises/ http://blog.parse.com/2013/01/29/whats-so-great-about-javasc... [2] http://www.codeproject.com/Articles/535635/Async-Await-and-the-Generated-StateMachine http://www.codeproject.com/Articles/535635/Async-Await-and-t...
- TheAnimus 13y ago
  Thanks for replying. But I'm not trying to say that async/await are superior to the actor paradigm (which is what my understanding Go subroutine, don't call em threads things are). Just that I would have hazarded a guess for pinging a bunch of servers, the TPL stuff is a better choice, than actor? I feel there is a lot of buzz around Go, though I'm not seeing why. I guess my only option is to find something suitable enough for it, and give it whirl. But of course I am lazy, so trying to find someone elses suitable experiences would be great.

kenkam 13y ago

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.

Ecio78 13y ago
Probably that would be the most interesting part of the story...
Stephen_C 13y ago
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)
- j_s 13y ago
  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'
  - Stephen_C 13y ago
    Well what sort of story are you expecting to hear? Without going into detail it's not really that exciting. There was a requirement for high volume/through put messaging component in our infrastructure. That technological requirement (along with non functional requirements e.g. development time/costs) was more than adequately met by a program(s) written by a team member written in Go. Was it an opportunity to further explore the "new hotness" that is/was Go…absolutely but the solution could have been implemented in one of the other supported technologies C/C++/Java with appropriate advantages/disadvantages associated with each. It will stay in use for as long as it provides the best solution, if that changes a more appropriate solution will be investigated. > 'This guy re-wrote all our stuff in the new hotness then left the company' The Go dataStore is "a" component within a large infrastructure, it is supportable by more than one member of the development team (a core requirement when deploying any new technology to production). I'll also note that before Andy left, being a professional and thoughtful colleague, he put a lot of effort into ensuring appropriate training and knowledge was given to team members that had not been part of the deployment. As Andy is a very well regarded former colleague, it helps that we could easily get in touch for a query, even when we're out for a beer or five* :) (*five might not be a maximum in that scenario)