@wolf480pl@mstdn.io I do data engineering with a side of making and improving the systems that help us deploy and run our code.
My problem is that when I do work with common devops tools, I tend to go fairly deep with them, and often end up hitting problems that either require me to write golang, or are deeply rooted in problems with golang. I like abstracting shit, and golang fights against it even if it gets wrapped around in a bunch of other languages. I filled https://github.com/hashicorp/terraform-provider-kubernetes/pull/1723 as I was working with CDKTF to parametrize a system, even though everything I wrote for that system was written in Pyhton. I'm now thinking of using Pulumi just because it doesn't basically require me to use golang to write providers. I will sooner rewrite Kubernetes then I ever will make a YAML template for it.
A lot of the shit that annoys me in DevOps tools is there because they were built with golang, and as such the design was done with limitations of golang in mind. But when I go to approach solutions, I don't have the limitations of golang in mind, and they always end up slowing me down.
I understand that maybe some things I want to do aren't really required for most dayjob things, but I think they are hurting the ease of use for software. Like, there is a bunch of software that is essentially made to be deployed on Kubernetes, but doesn't have anything better than a Helm package for it, which is fucking terrible. But the design limits golang imposes hardly allow for anything better than templating for software reusability. Reusable components are almost a pipe dream. You don't need them when you're only thinking about your what your company deploys, because you're not running a ton of different deployments of a single software package. But every company writing their own deployment for the same software with mostly the same operating constraints in all cases is fucking wasteful, and just sucks on the industry as a whole. There's businesses that just deploy some open source software in the cloud for you without you needing to worry without that much additional functionality and that's worth paying double the price of raw compute it's getting deployed on because the deployment and operational experience of said software is abysmal, purely because everyone needs to cook up their own deployment from scratch.
I know that it's possible to do basically anything without touching golang, but I find it very annoying when I have stoop down to the level of golang to do things when they so easily could be done in a much better way.
@ignaloidas hmm what do you mean devops side / what is your current role?
IME, anything from "make Jenkins notify people that their docker image is built" to "develop a way to shrink persistent volumes on k8s" to "automate removing permissions in 15 different systems when offboarding an employee" can be done with python and shell (and a bit of groovy in case of Jenkins).
And while many of the tools I use are written in golang, I rarely have to write any golang code.
I kinda want to transition into more devops side of work, but all of the popular tools in that space nowadays are golang and I can't work with golang for more than a week straight without getting too angry to work
@wolf480pl@mstdn.io I have zero clue, but because golang seems to almost always pick the stupidest option available, it's gotta be the error message one