Win a copy of Transfer Learning for Natural Language Processing (MEAP) this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Paul Clapham
  • Devaka Cooray
  • Bear Bibeault
Sheriffs:
  • Junilu Lacar
  • Knute Snortum
  • Liutauras Vilda
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Piet Souris
Bartenders:
  • salvin francis
  • Carey Brown
  • Frits Walraven

Head First Go: Sys Admin or More

 
Greenhorn
Posts: 26
Scala Redhat Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Thanks for the QA, one big question I have after hearing so my talk about GO. Where can it take me? What would my end goal be? As a System Administrator is it worth moving basic scripting to GO? Typically for me BASH scripts will do some basic work across the environment. One example pull data from HPE server ILO API's to get health status or firmware versions. Anything more repetitive gets pushed into a CHEF cookbook.

I would love to jump in deeper, but would like to have some end goal in site. Maybe creating a GUI interface for triggering different scripts or providing input to scripts? BTW I love the Head First series, I'm so glad to see GO in the catalog!


Thanks!!!
Pete
 
Author
Posts: 22
5
Mac Ruby Chrome
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Peter Azurahc wrote:As a System Administrator is it worth moving basic scripting to GO? Typically for me BASH scripts will do some basic work across the environment. One example pull data from HPE server ILO API's to get health status or firmware versions. Anything more repetitive gets pushed into a CHEF cookbook.



I wouldn't recommend moving everything to Go, no. Scripting languages (like Bash and Ruby) are perfect for tasks like provisioning, where you perform an action once on a server and you're done. Performance isn't a primary concern in those situations, so slower-executing languages are fine.

But if you need a generic system utility that you'll run over and over in a variety of situations, you'd be wise to look at writing it in Go. Go programs are fast. And you don't have to install an interpreter on the system where you're going to run it; all you need is the compiled executable. If I were implementing find or curl today, I would do it in Go.

Peter Azurahc wrote:BTW I love the Head First series, I'm so glad to see GO in the catalog!



Awesome, thanks! And be sure to recommend Head First Ruby to your colleagues that use Chef!
 
Peter Azurahc
Greenhorn
Posts: 26
Scala Redhat Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
wow Jay, thank you for the detailed response. Find and Curl can be horribly time consuming, I have a handful of scripts that are regularly run that could really use improving.

One example I curl 900 servers to extract API info in JSON, and then perform various logic based on the data retrieved. Server count varies of course, but this script can easily take over 24 hours to complete. And good luck if I tweaked it and messed up one of the logic points!! Learned about testing in small sets very quickly.
Does GO have good inter-operability with JSON? I read Ruby is good in this area, but with Bash getting the libraries to work without issues is difficult. Primary issue being that our server environment is locked down tight I can't easily use libraries in some environments so I have to perform the extract and analysis portions separately... fun fun. Having a one stop shop in GO coupled with faster run times, you're speaking my language!
The speed increase in find and curl, is that based on the language alone or breaking out work in GO routines? Or better yet, both?


How cool is that you wrote the Head First Ruby book too, that one has been on my todo list.

For those reading along, check out Jay's twitter account. I really like the articles you post and topics you cover. When I saw you were also speaking at Emerging Technology for the Enterprise in Philly I was disappointed to see tickets were already sold out. Looks like a fantastic conference.
 
Jay McGavren
Author
Posts: 22
5
Mac Ruby Chrome
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Peter Azurahc wrote:wow Jay, thank you for the detailed response. Find and Curl can be horribly time consuming, I have a handful of scripts that are regularly run that could really use improving.

One example I curl 900 servers to extract API info in JSON, and then perform various logic based on the data retrieved.



I actually meant re-implementing the curl or find utilities themselves, not re-implementing scripts that rely on them. But yes, Go can totally do that too. I'm assuming, though, that there are some patterns to the logic you follow for the JSON from those 900 servers. If you're having to code special functionality for each feed, then you'd probably be better off managing that in a Bash or Ruby script rather than hard-coding that logic in a Go program.

Peter Azurahc wrote:Does GO have good inter-operability with JSON? I read Ruby is good in this area, but with Bash getting the libraries to work without issues is difficult.



Nothing compares to the ease of Ruby's JSON marshaling and unmarshaling; it's amazing (if slow). But Go has the best JSON handling of any statically-typed language I've seen, and it's all done via the standard library. As long as your JSON feed formats are pretty stable, I think you'll find it's pleasant to work with.

Peter Azurahc wrote:The speed increase in find and curl, is that based on the language alone or breaking out work in GO routines? Or better yet, both?



Note that I didn't say they'd be faster than the current implementations (although they might be for all I know). I'm suggesting they'd be easier to write, though. Goroutines would definitely help with that.

Peter Azurahc wrote:For those reading along, check out Jay's twitter account. I really like the articles you post and topics you cover.



Aww, thanks! And you're right, they totally should! ;-)
 
I think she's lovely. It's this tiny ad that called her crazy:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic