4 ms·

There's a natural progression from Bash to Perl to Python, each more powerful than the previous. If you haven't made it to Python yet, you're stuck in the past.

by vorg 9y ago

There's a natural progression from Bash to Perl to Python, each more powerful than the previous. If you haven't made it to Python yet, you're stuck in the past. Again with Ant and Maven, the progression is on to Gradle. Gradle, like Jenkins pipelines, uses Apache Groovy (minus its collections API), but Kotlin and IntelliJ are fast replacing it. As for Go, its http server API is top of the line. If you use it instead of PHP or Rails, your app will scale seamlessly.

shermanyo 9y ago
> There's a natural progression from Bash to Perl to Python, each more powerful than the previous. As someone who moved in the opposite direction, I can't disagree more strongly. Python is great if you want to write programs, but that adds a huge overhead over time, even in a simple language. When I started using Perl, I feel like I really became a DevOps engineer. I built an automated test framework, deployment and monitoring tooling. I wrote scripts to automate processes large and small. It was the perfect scratchpad for getting an idea down with a working implementation, it was as free form or structured as I wanted it to be at any time. Over time, my familiarity with Bash started to cover a lot of the smaller Perl tasks I was used to. To automate some simple testing of a REST API, is Python / Perl _really_ needed? A simple bash script could read data from a text file, then run curl commands in parallel while logging failures. Hell, use jq and you can process the JSON responses trivially too. If Bash lacks power, I haven't ran into many situations where this was my issue.
manyxcxi 9y ago
I guess I just naturally skipped over Python because I use it for many things- it just didn't stick out in my brain as a tool I use when solving Ops problems, but I certainly do. That being said, Python isn't necessarily available on all platforms, and for the vast majority of typical ops problems Python is way overkill. I prefer to reach for the least moving parts and most widely available first. I have an entire library of simplistic solutions to the vast majority of my issues that have evolved and stabilized over time, they're as battle tested and ready to go as anything I'm going to encounter heading up the complexity chain. You're not a full time Java developer who has to work with many clients and projects if you believe Gradle is taking over from Maven. I like Gradle, and I use Gradle for most things, but I have seen it used MAYBE twice in the last 5 years by projects that have come through my company. Most CI/CD tools, if they support Gradle natively, don't have near the level of integration as Maven. Don't assume I'm knocking Gradle, I much prefer it to Maven for simple projects, but good freaking luck if you've got a complicated project layout and you're importing it into IntelliJ. Even the latest 2017 update still has major issues with Gradle resolution that require me to blast my cache and restart. I fail to see how using Go as your HTTP web application is using it for ops in the way you describe, unless you're using it as a request router of sorts. You're talking about building a web service/app in Go, which is great- but not what I was thinking of in the context of building tools to build, deploy, version, and release your applications and source code.

by vorg 9y ago

shermanyo 9y ago

> There's a natural progression from Bash to Perl to Python, each more powerful than the previous. As someone who moved in the opposite direction, I can't disagree more strongly. Python is great if you want to write programs, but that adds a huge overhead over time, even in a simple language. When I started using Perl, I feel like I really became a DevOps engineer. I built an automated test framework, deployment and monitoring tooling. I wrote scripts to automate processes large and small. It was the perfect scratchpad for getting an idea down with a working implementation, it was as free form or structured as I wanted it to be at any time. Over time, my familiarity with Bash started to cover a lot of the smaller Perl tasks I was used to. To automate some simple testing of a REST API, is Python / Perl _really_ needed? A simple bash script could read data from a text file, then run curl commands in parallel while logging failures. Hell, use jq and you can process the JSON responses trivially too. If Bash lacks power, I haven't ran into many situations where this was my issue.

manyxcxi 9y ago

I guess I just naturally skipped over Python because I use it for many things- it just didn't stick out in my brain as a tool I use when solving Ops problems, but I certainly do. That being said, Python isn't necessarily available on all platforms, and for the vast majority of typical ops problems Python is way overkill. I prefer to reach for the least moving parts and most widely available first. I have an entire library of simplistic solutions to the vast majority of my issues that have evolved and stabilized over time, they're as battle tested and ready to go as anything I'm going to encounter heading up the complexity chain. You're not a full time Java developer who has to work with many clients and projects if you believe Gradle is taking over from Maven. I like Gradle, and I use Gradle for most things, but I have seen it used MAYBE twice in the last 5 years by projects that have come through my company. Most CI/CD tools, if they support Gradle natively, don't have near the level of integration as Maven. Don't assume I'm knocking Gradle, I much prefer it to Maven for simple projects, but good freaking luck if you've got a complicated project layout and you're importing it into IntelliJ. Even the latest 2017 update still has major issues with Gradle resolution that require me to blast my cache and restart. I fail to see how using Go as your HTTP web application is using it for ops in the way you describe, unless you're using it as a request router of sorts. You're talking about building a web service/app in Go, which is great- but not what I was thinking of in the context of building tools to build, deploy, version, and release your applications and source code.