3 ms·

What relation does golang have with docker for devops use? I'm also wondering the same about k8s, other than the go templating language used by helm charts. And

What relation does golang have with docker for devops use? I'm also wondering the same about k8s, other than the go templating language used by helm charts. And if it's the development of docker itself which is written in go, I wouldn't consider that devops (same as I wouldn't say editing images in photoshop is C++ development). I'm curious, because I've used k8s and docker extensively for devops, and aside from templating, which is arguably not so much golang as, well, just a templating engine. And I've thankfully not have had to use golang for anything serious.

pjmlp 5y ago
Plugins and other software that one might feel like customising. https://landscape.cncf.io/ https://landscape.cncf.io/ As always, using the platform language is the best road to avoid additional development costs dealing with interoperability and tier 2 compatibility issues. Although some stuff is now happening in Rust as well, https://deislabs.io/ https://deislabs.io/
- okamiueru 5y ago
  I see. I think what confused me was the statement "Anyone that has DevOps on their daily tasks is now bound to deal with Go code", since I've not found it to be true. And, I've yet to find a single need to customize any plugin/tool. The bar to do something like that is also exceedingly high, as the added maintenance cost is immense, since you now have to build and maintain your changes towards a living project. So, I think we might just have different interpretation of what DevOps entails. In addition, even if writing infrastructure plugins were to considered necessary as part of DevOps (though I consider this a stretch), writing golang is again not a requirement. The CNFC isn't exclusively filled with golang plugins either. I'd argue most are something else C/C++/Java/web-langs though I haven't made the effort to check. I'd venture a guess at one in four being golang, at most. I agree however that language evangelism benefits no one, and especially agree on the sentiment of using the platform language to avoid additional development cost. That said, and this is probably a bit more subjective, this does not follow from/to the original statement I took issue with.

pjmlp 5y ago

Plugins and other software that one might feel like customising. https://landscape.cncf.io/ https://landscape.cncf.io/ As always, using the platform language is the best road to avoid additional development costs dealing with interoperability and tier 2 compatibility issues. Although some stuff is now happening in Rust as well, https://deislabs.io/ https://deislabs.io/

okamiueru 5y ago
I see. I think what confused me was the statement "Anyone that has DevOps on their daily tasks is now bound to deal with Go code", since I've not found it to be true. And, I've yet to find a single need to customize any plugin/tool. The bar to do something like that is also exceedingly high, as the added maintenance cost is immense, since you now have to build and maintain your changes towards a living project. So, I think we might just have different interpretation of what DevOps entails. In addition, even if writing infrastructure plugins were to considered necessary as part of DevOps (though I consider this a stretch), writing golang is again not a requirement. The CNFC isn't exclusively filled with golang plugins either. I'd argue most are something else C/C++/Java/web-langs though I haven't made the effort to check. I'd venture a guess at one in four being golang, at most. I agree however that language evangelism benefits no one, and especially agree on the sentiment of using the platform language to avoid additional development cost. That said, and this is probably a bit more subjective, this does not follow from/to the original statement I took issue with.