10 ms·

I was introduced to the Kubernetes source code by an Redhat Kubernetes Core Contributor. He showed me the nasty parts how they solved the lack of generics. Actu

I was introduced to the Kubernetes source code by an Redhat Kubernetes Core Contributor. He showed me the nasty parts how they solved the lack of generics. Actually they use strings to concat valid go source code based on reflections. A little tedious but given the constraints for language choice they had (fast, compiled binary, close to the metal) I think Go is still a decent choice for Kubernetes.

nikon 9y ago
Could you link to that area? Would be interesting to see.
- Vendan 9y ago
  Here's one example file: https://github.com/kubernetes/kubernetes/blob/master/cmd/libs/go2idl/client-gen/generators/generator_for_clientset.go https://github.com/kubernetes/kubernetes/blob/master/cmd/lib... It all seems to be using https://github.com/kubernetes/gengo https://github.com/kubernetes/gengo
  - smarterclayton 9y ago
    As one of the perpetrators of gengo, we focused on simple, fast, and dirty. We wanted something a little higher level than Go AST to deal with types (for gen), and we knew we wanted to gen a ton of code. Some of the Kube code generation would not be solved by generics (or at least, not obviously) such as our API conversion logic which defines arbitrary transforms between structs and generates the rest. The others (proto, defaulting, etc) would.
secure 9y ago
Could that Core Contributor possibly contribute a report to https://github.com/golang/go/wiki/ExperienceReports#generics https://github.com/golang/go/wiki/ExperienceReports#generics? :)
lmm 9y ago
Go isn't particularly fast or close to the metal as compiled languages go - I feel like a lot of people compare it against scripting languages but those aren't the only alternatives. If GC is acceptable you have a wealth of mature languages available with a proper type system, e.g. OCaml.
- ice109 9y ago
  what's another compiled gc language with a strong type system? I only know D and ocaml (let's not even mention Haskell).
  - msla 9y ago
    Does Go have a strong type system, or does it have an Algol-style type system? I'm pretty sure it's the latter, unlike OCaml and Haskell. It's competing with C++, in other words, so there's your basis for comparison.
    - burntsushi 9y ago
      Go's type system is "strong," as far as that goes. In comparison to OCaml and Haskell, Go's type system is less expressive. That is, OCaml and Haskell will let you express more invariants in the type system more easily.
      - msla 9y ago
        The point of a type system is to make it easier to reason about your programs, so a type system like C's, where almost all of the types are size specifications, like the difference between short and int and long, is almost orthogonal to the purpose of having a type system in the first place: It doesn't matter if someone's height in centimeters is an int or a long, it matters that it can't be added to their age in days, and if someone tries it, the compiler catches it and alerts the programmer to nonsense in the codebase. Being able to represent both their height in centimeters and their age in days in a 32-bit integer is pointless trivia unless you're designing a bits-on-the-wire network protocol specification, or interfacing with hardware registers, or designing a binary file format, in which case C's type system still doesn't give you enough information, because endianness is not specified. Object systems are an attempt at solving the "Foogols don't have real type systems" problem, but they drag in notions of hierarchy which don't always fit outside of toy problems, and not even then. Plus, Smalltalk-style object systems which mandate that everything must work via message-passing drags in even more complexity orthogonal to the idea of finally having a semantic type system. And as long as there are still size specification pseduo-types, boxed or unboxed, the type system still has an inherent hole in it, because you can still say nonsense which type-checks perfectly cleanly. So saying Go has a strong type system and comparing it to OCaml or Haskell is meaningless, because the two kinds of type systems (that is, real, semantic type systems versus size specifications) aren't trying to do the same thing.
tonyhb 9y ago
Kubernetes is literally the Angular of orchestration systems. SwarmMode is so much cleaner and less complex to use, dive into, and hack on. I'm unsure why the community rallies behind Kube considering it's insecure, horribly complex, and a PITA to configure. I guess because google lied and said they use it internally, even though they're still using Borg?
- andrewstuart2 9y ago
  If by "the Angular of orchestration systems" (I'm going to assume Angular 1 because Angular 2 gives me headaches still) you mean that it's really easy to do what should be easy, and feasible to accomplish really complex things, then I would agree. But I don't think that's what you meant. As far as security, that's now purely a property of the way you deploy it. Secrets can be encrypted (feature in alpha), RBAC is fully supported, TSL client certs are preferred for AuthN, and HTTPS is supported across the API endpoints. I'm not sure what more you could ask for on the security side. I don't know that Google says they're using K8s internally, either. It's always been sold by Google as a ground-up rewrite of what the authors wish Borg would have been. Not only that, but it's supported (developed) by dozens of small companies, as well as Google, Red Hat, and an increasing number of large companies interested in its growth. Finally, it's governed by the Linux Foundation. If there's another org that can help scale and properly govern one of the most popular modern OSS projects, I'm drawing a blank.
- macNchz 9y ago
  Well for one Swarm was released a year ago and Kubernetes went 1.0 two years ago, so there has just been more time for people to get familiar with k8s. I myself dug into kube before Swarm arrived and have put off getting into Swarm because constant framework hopping kind of defeats the purpose of getting familiar with a new framework in the first place. While I agree to some extent re complexity, I'd be interested as to what you're referring to when you say kubernetes is insecure.
  - thinbeige 9y ago
    Framework hopping? With your knowledge in k8s you should be able to learn Docker Swarm and getting a swarm deployed in less than 60 minutes.
harlanji 9y ago
Just getting back into Go (was Clojure), missing generics were annoying indeed. Though doing things with strings in source isn't fundamentally different from type erasure in the JVM (can wiki the term). Ie. Generics in Java are strings in the source code that don't make it through compilation either, Java just has explicit syntax for it and IIRC C++ templates generate a collection class for each type.
- scalatohaskell 9y ago
  Are you serious? Thats like saying that Haskell or C++ compiles to assembler so its same.
GenericsMotors 9y ago
> close to the metal Yeah...no GC'd language is really close to the metal. > I think Go is still a decent choice for Kubernetes. After what you described, it sounds like the authors decided to double down on their choice and dig a deeper hole rather than use the right tool for the job.

nikon 9y ago

Could you link to that area? Would be interesting to see.

Vendan 9y ago
Here's one example file: https://github.com/kubernetes/kubernetes/blob/master/cmd/libs/go2idl/client-gen/generators/generator_for_clientset.go https://github.com/kubernetes/kubernetes/blob/master/cmd/lib... It all seems to be using https://github.com/kubernetes/gengo https://github.com/kubernetes/gengo
- smarterclayton 9y ago
  As one of the perpetrators of gengo, we focused on simple, fast, and dirty. We wanted something a little higher level than Go AST to deal with types (for gen), and we knew we wanted to gen a ton of code. Some of the Kube code generation would not be solved by generics (or at least, not obviously) such as our API conversion logic which defines arbitrary transforms between structs and generates the rest. The others (proto, defaulting, etc) would.

secure 9y ago

Could that Core Contributor possibly contribute a report to https://github.com/golang/go/wiki/ExperienceReports#generics https://github.com/golang/go/wiki/ExperienceReports#generics? :)

lmm 9y ago

Go isn't particularly fast or close to the metal as compiled languages go - I feel like a lot of people compare it against scripting languages but those aren't the only alternatives. If GC is acceptable you have a wealth of mature languages available with a proper type system, e.g. OCaml.

ice109 9y ago
what's another compiled gc language with a strong type system? I only know D and ocaml (let's not even mention Haskell).
- msla 9y ago
  Does Go have a strong type system, or does it have an Algol-style type system? I'm pretty sure it's the latter, unlike OCaml and Haskell. It's competing with C++, in other words, so there's your basis for comparison.
  - burntsushi 9y ago
    Go's type system is "strong," as far as that goes. In comparison to OCaml and Haskell, Go's type system is less expressive. That is, OCaml and Haskell will let you express more invariants in the type system more easily.
    - msla 9y ago
      The point of a type system is to make it easier to reason about your programs, so a type system like C's, where almost all of the types are size specifications, like the difference between short and int and long, is almost orthogonal to the purpose of having a type system in the first place: It doesn't matter if someone's height in centimeters is an int or a long, it matters that it can't be added to their age in days, and if someone tries it, the compiler catches it and alerts the programmer to nonsense in the codebase. Being able to represent both their height in centimeters and their age in days in a 32-bit integer is pointless trivia unless you're designing a bits-on-the-wire network protocol specification, or interfacing with hardware registers, or designing a binary file format, in which case C's type system still doesn't give you enough information, because endianness is not specified. Object systems are an attempt at solving the "Foogols don't have real type systems" problem, but they drag in notions of hierarchy which don't always fit outside of toy problems, and not even then. Plus, Smalltalk-style object systems which mandate that everything must work via message-passing drags in even more complexity orthogonal to the idea of finally having a semantic type system. And as long as there are still size specification pseduo-types, boxed or unboxed, the type system still has an inherent hole in it, because you can still say nonsense which type-checks perfectly cleanly. So saying Go has a strong type system and comparing it to OCaml or Haskell is meaningless, because the two kinds of type systems (that is, real, semantic type systems versus size specifications) aren't trying to do the same thing.

tonyhb 9y ago

Kubernetes is literally the Angular of orchestration systems. SwarmMode is so much cleaner and less complex to use, dive into, and hack on. I'm unsure why the community rallies behind Kube considering it's insecure, horribly complex, and a PITA to configure. I guess because google lied and said they use it internally, even though they're still using Borg?

andrewstuart2 9y ago
If by "the Angular of orchestration systems" (I'm going to assume Angular 1 because Angular 2 gives me headaches still) you mean that it's really easy to do what should be easy, and feasible to accomplish really complex things, then I would agree. But I don't think that's what you meant. As far as security, that's now purely a property of the way you deploy it. Secrets can be encrypted (feature in alpha), RBAC is fully supported, TSL client certs are preferred for AuthN, and HTTPS is supported across the API endpoints. I'm not sure what more you could ask for on the security side. I don't know that Google says they're using K8s internally, either. It's always been sold by Google as a ground-up rewrite of what the authors wish Borg would have been. Not only that, but it's supported (developed) by dozens of small companies, as well as Google, Red Hat, and an increasing number of large companies interested in its growth. Finally, it's governed by the Linux Foundation. If there's another org that can help scale and properly govern one of the most popular modern OSS projects, I'm drawing a blank.
macNchz 9y ago
Well for one Swarm was released a year ago and Kubernetes went 1.0 two years ago, so there has just been more time for people to get familiar with k8s. I myself dug into kube before Swarm arrived and have put off getting into Swarm because constant framework hopping kind of defeats the purpose of getting familiar with a new framework in the first place. While I agree to some extent re complexity, I'd be interested as to what you're referring to when you say kubernetes is insecure.
- thinbeige 9y ago
  Framework hopping? With your knowledge in k8s you should be able to learn Docker Swarm and getting a swarm deployed in less than 60 minutes.

harlanji 9y ago

Just getting back into Go (was Clojure), missing generics were annoying indeed. Though doing things with strings in source isn't fundamentally different from type erasure in the JVM (can wiki the term). Ie. Generics in Java are strings in the source code that don't make it through compilation either, Java just has explicit syntax for it and IIRC C++ templates generate a collection class for each type.

scalatohaskell 9y ago
Are you serious? Thats like saying that Haskell or C++ compiles to assembler so its same.

GenericsMotors 9y ago

> close to the metal Yeah...no GC'd language is really close to the metal. > I think Go is still a decent choice for Kubernetes. After what you described, it sounds like the authors decided to double down on their choice and dig a deeper hole rather than use the right tool for the job.