Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
Win a copy of Serverless Applications with Node.js this week in the NodeJS 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
  • Liutauras Vilda
  • Bear Bibeault
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Junilu Lacar
  • Paul Clapham
  • Knute Snortum
Saloon Keepers:
  • Stephan van Hulst
  • Ron McLeod
  • Tim Moores
  • salvin francis
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Vijitha Kumara

Head First Go: Sys Admin or More  RSS feed

 
Greenhorn
Posts: 24
Redhat Scala 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
Chrome Mac Ruby
  • 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: 24
Redhat Scala 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
Chrome Mac Ruby
  • 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! ;-)
 
Maybe he went home and went to bed. And took this tiny ad with him:
global solutions you can do at home or in your backyard
https://www.kickstarter.com/projects/paulwheaton/better-world-boo
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!