4 ms·

Seriously, people. K8s is a container orchestration system. Yes, it's written in Go, like Docker itself. DevOps tooling is a niche area where Go has been ver

Seriously, people. K8s is a container orchestration system. Yes, it's written in Go, like Docker itself. DevOps tooling is a niche area where Go has been very successful. But k8s runs whatever you put into your Docker containers. I've seen no indication of it changing which languages people choose to containerize (Node containers probably being way more common than Go ones). If anything, easy containerization negates one of Go's strongest selling points (i.e. standalone executables with no need for a runtime environment).

stephenhuey 7y ago
Exactly! In the enterprise world, there is a lot of Java and .NET code that isn’t going away for a while especially since K8s makes it easier to port to the cloud. In my enterprise, the only other language that comes close in usage numbers is Python, so I think a lot of enterprise folks will opt for that over Go.
- smarterclayton 7y ago
  As someone who works on Kubernetes in the enterprise I would agree - there’s lots of go, but it’s newer and organized around the teams who were early adopters. And even the early adopters have massive Java, .NET, and increasingly Node footprints. However I think the rule of enterprise software is that it’s increasingly fragmented and diverse - that’s partially why Kubernetes and containers were so attractive because it allows operations to unify footprint on prem and have a path to cloud. Nobody in an enterprise ever stopped using a piece of technology. It lives on forever (and public cloud just gives it new places to live).
yebyen 7y ago
> If anything, easy containerization negates one of Go's strongest selling points (i.e. standalone executables with no need for a runtime environment). I don't know about that, I think that is still a strong selling point for Go, even in a containerized environment. Somewhere I saw a statistic that says over 90% of container images in the wild contain unpatched CVE vulnerabilities and (searching...) [1] here's an article that shows just how bad the problem is, according to this article in just the top 10 docker images, there are over 8000 known vulnerable paths. The reason is probably not because those 10 products are simply nightmarish from a security perspective and expose the lions share of the vulnerabilities in their own code paths, it's because of unchecked dependencies. If someone took a tree shaker to those images and removed all of the unnecessary packages that aren't real dependencies, you see that number going down by probably about 30% if not more. Even then, you're still seeing lots of potential issues caused by far-away dependencies that we do actually need, but don't really care about. There's something to be said for a development stack that is geared toward automatically pruning out packages you've included when the compiler can prove you're not even using them, and helping you reduce the scope and size of your external, far-away dependencies. From an InfoSec perspective that's the biggest problem I see in containerized environments, (and true that just not using containers won't really make it much better) so correct me if I'm wrong, but I think that Go does all of that for us. [1]: https://snyk.io/blog/top-ten-docker-images-contain-over-8000-vulnerable-paths/ https://snyk.io/blog/top-ten-docker-images-contain-over-8000...
kerng 7y ago
Go is really not a language to recommend for enterprise business applications. It's a niche and will likely stay this way unless they add tons of features, which they have been reluctant to do. Because otherwise they'll end up with Java, or something very similar, is what you end up with.

stephenhuey 7y ago

Exactly! In the enterprise world, there is a lot of Java and .NET code that isn’t going away for a while especially since K8s makes it easier to port to the cloud. In my enterprise, the only other language that comes close in usage numbers is Python, so I think a lot of enterprise folks will opt for that over Go.

smarterclayton 7y ago
As someone who works on Kubernetes in the enterprise I would agree - there’s lots of go, but it’s newer and organized around the teams who were early adopters. And even the early adopters have massive Java, .NET, and increasingly Node footprints. However I think the rule of enterprise software is that it’s increasingly fragmented and diverse - that’s partially why Kubernetes and containers were so attractive because it allows operations to unify footprint on prem and have a path to cloud. Nobody in an enterprise ever stopped using a piece of technology. It lives on forever (and public cloud just gives it new places to live).

yebyen 7y ago

> If anything, easy containerization negates one of Go's strongest selling points (i.e. standalone executables with no need for a runtime environment). I don't know about that, I think that is still a strong selling point for Go, even in a containerized environment. Somewhere I saw a statistic that says over 90% of container images in the wild contain unpatched CVE vulnerabilities and (searching...) [1] here's an article that shows just how bad the problem is, according to this article in just the top 10 docker images, there are over 8000 known vulnerable paths. The reason is probably not because those 10 products are simply nightmarish from a security perspective and expose the lions share of the vulnerabilities in their own code paths, it's because of unchecked dependencies. If someone took a tree shaker to those images and removed all of the unnecessary packages that aren't real dependencies, you see that number going down by probably about 30% if not more. Even then, you're still seeing lots of potential issues caused by far-away dependencies that we do actually need, but don't really care about. There's something to be said for a development stack that is geared toward automatically pruning out packages you've included when the compiler can prove you're not even using them, and helping you reduce the scope and size of your external, far-away dependencies. From an InfoSec perspective that's the biggest problem I see in containerized environments, (and true that just not using containers won't really make it much better) so correct me if I'm wrong, but I think that Go does all of that for us. [1]: https://snyk.io/blog/top-ten-docker-images-contain-over-8000-vulnerable-paths/ https://snyk.io/blog/top-ten-docker-images-contain-over-8000...

kerng 7y ago

Go is really not a language to recommend for enterprise business applications. It's a niche and will likely stay this way unless they add tons of features, which they have been reluctant to do. Because otherwise they'll end up with Java, or something very similar, is what you end up with.