2) Check out the number of dependencies. This looks almost like NPM hell.
3) Lack of standardization and consistency. This project is so big, and there are so many contributors with their coding styles that the project looks untidy.
4) A lot of import renaming is a symptom of package name clashing or simply poor package naming. You usually do not need to rename import, and this is simply not required if your package structure was carefully thought about.
Again, k8s is great. K8s solves a lot of problems. I love it, but it is not a great example of Go code.
Actually, k8s was written in Java originally. Then basically verbatim copied to golang. That’s why you have this ObjectMeta stuff - it was trying to implement an OO system in golang. Lots of weirdness can be traced back to the Java origin.
That’s not true, because I’m the original author of ObjectMeta and I did it in golang. :)
Half of the point of Kube is that every object looks similar enough that you can deal with them generically. ObjectMeta is what enforces that, so yes it’s OO, if there was only one base class possible and no inheritance. The ObjectMeta as an interface construct exists for performance reasons in Kube vs the reflection we used early on (which was mostly due to people learning Go and dealing with limitations of the language as we rapidly prototyped new ways of building out our object patterns).
A prototype of kube was done at google in Java, none of that survived translation to the open source project (edit: or was rewritten prior to v1 as we matured the subsystems that replaced the basic concepts in the day 1 project, like clients writing directly to etcd). Many of the early authors had lots of Java experience, but there was never any attempt to bring Javaisms into Kube or any Java to be converted, just conventions.
EDIT: actually, metadata/spec/status is more a repudiation of Rails and the active record style “hundreds of properties with no organization” JSON apis. We wanted to clearly separate metadata (common), spec (desired intent), and status (actual state). That led naturally in go to an embedded struct for ObjectMeta and then the interface for getting access to the generic properties on any object.
This. This is why I read hacker news. As someone who interacts with your code on a daily basis and whose livelihood was catapulted due to said familiarity, thank you!
My comment was based on watching this talk: https://archive.fosdem.org/2019/schedule/event/kubernetesclu.... Kris Nova quotes Joe Beda saying they "rewrote Brendan's prototype (in Java), to go". And then goes on to discuss how this led to many of the patterns in Kubernetes.
There are a few disturbing things:
1) Usage of `utils` package. Points against it were made in:
https://dave.cheney.net/2019/01/08/avoid-package-names-like-...
https://github.com/golang/go/wiki/CodeReviewComments#package...
2) Check out the number of dependencies. This looks almost like NPM hell.
3) Lack of standardization and consistency. This project is so big, and there are so many contributors with their coding styles that the project looks untidy.
4) A lot of import renaming is a symptom of package name clashing or simply poor package naming. You usually do not need to rename import, and this is simply not required if your package structure was carefully thought about.
Again, k8s is great. K8s solves a lot of problems. I love it, but it is not a great example of Go code.