4 ms·

Kubernetes is a complex project with a large codebase. Writing it in bash would be a nightmare to maintain. Go makes sense as an implementation language for a

Kubernetes is a complex project with a large codebase. Writing it in bash would be a nightmare to maintain. Go makes sense as an implementation language for a system like this for many reasons: - it doesn't require a VM (goodbye Java) - it is a memory safe language (goodbye c++) - it has strong types to improve reliability - it does a good job of handling complex, multi-module code efficiently (these two say goodbye to python) So of the Google friendly languages you end up with Go. And I don't know if it was planned, but Go has turned out to be a boon for contribution. A surprising number of devops engineers are willing to dip their toes in Go waters and I highly doubt they would've done so with Erlang. I think you'd end up going the chef route, writing the control plane in Erlang and expecting users to interact in Ruby or something like it. Also this whole conversation seems a bit off because Kubernetes is a multi-service architecture with many components. You can absolutely write operators in other languages since Kubernetes exposes an API. It's kind of the whole point to be able to take an existing application and run it in k8s rather than a regular VM with minimal changes. Expecting developers to rewrite everything in Erlang is nuts.

pm90 8y ago
> And I don't know if it was planned, but Go has turned out to be a boon for contribution. A surprising number of devops engineers are willing to dip their toes in Go waters and I highly doubt they would've done so with Erlang. > I think you'd end up going the chef route, writing the control plane in Erlang and expecting users to interact in Ruby or something like it. DevOps engineers have learned to be comfortable with Ruby (Chef) and Python (Ansible) so this certainly makes sense.
pdimitar 8y ago
> Expecting developers to rewrite everything in Erlang is nuts. ...But I never said that? You are correct on your points and I don't disagree. Golang is certainly a much better choice than Bash indeed. You are also correct on developer willingness to work with Golang. I am aware that K8s and Erlang/OTP are apples to oranges comparison; they serve different needs. Whereas Erlang's runtime (the BEAM VM) can give you fault-tolerance, K8s tries to do roughly the same on a higher level - it tries to give you throwaway containers that can be switched off and on at any time. As I mentioned in my parent comment, I admire their work. What my point was that if you squint your eyes hard, it kind of looks like K8s wants to invent Erlang/OTP for infrastructure (as opposed to Erlang/OTP which gives its guarantees per node).
- BraveNewCurency 8y ago
  > which gives its guarantees per node There is no such thing, because Nodes (and even entire datacenters) can fail. In other words, node failure is an infrastructure problem that is best NOT handled by your bespoke application code. Replacing failed nodes should NOT be custom code in your app, that way lies madness. > kind of looks like K8s wants to invent Erlang/OTP for infrastructure You can say "K8s and Erlang implement similar ideas implemented at different levels." But you can't pretend one is a substitute for the other, nor that "Erlang has done everything that K8s can do." E.g. Writing in Erlang doesn't magically get you: - deploy/upgrade of the Erlang runtime, including rollback + multiple versions co-existing, including any compiled foreign code (which is required in the article). - ability to log, monitor, probe and reroute the connections between services -- In a standard way such that the application doesn't have to be modified.("service mesh") - Ability for an entire ecosystem of tools to inspect the versions of your application services that are deployed, because it's exposed as an API. - A standard ecosystem of plug-ins for operators (autoscale, autoscale to EC2 spot instances, capacity planning, "best practices" of running a MySQL cluster, etc.) None of these should ever be mixed with the application. (Unless you are Kelsey Hightower: https://github.com/kelseyhightower/hello-universe https://github.com/kelseyhightower/hello-universe )
  - pdimitar 8y ago
    > There is no such thing, because Nodes (and even entire datacenters) can fail. Gross over-simplification that I'd also call a strawman. In the face of lack of electricity, of course no computer language matters at all. What's your point?
pjmlp 8y ago
> it doesn't require a VM (goodbye Java) - Neither does Java, only devs clueless about Java world aren't aware of AOT compilers to native code. Also sorry to spoil your fun, Kubernetes was originally written in Java, it was later rewritten in Go as other team took over.
- cdoxsey 8y ago
  Apparently a prototype was written in Java. Borg was written in c++. AFAIK Kubernetes was always a Go project, but maybe I'm wrong. Why do you think Go was chosen? Your comment about my experience with Java was needlessly provocative so I'm going to ignore it.
  - pjmlp 8y ago
    It was mentioned at the FOSDEM 2019 talk about K8S. Nowhere in my commented I addressed the Java remark to your specific person. It was targeted to all of those that bash Java without actually knowing how the rich the eco-system actually is.
    - cdoxsey 8y ago
      You called me a "clueless dev".
      - pjmlp 8y ago
        No I did not, nowhere on my sentence is the direct mention of your person. On my previous comment I explicitly mention it was targeted to developers that bash Java, without having any clue what they are bashing about, cargo cult if you wish. So either you feel offended, because you are indeed attacking Java without having any clue about the Java eco-system, or are deciding to play victim here, when I never mentioned you directly. This is a public forum, so I leave to everyone else and HN moderators to judge my comments, and won't reply to anything else on this thread.

pm90 8y ago

> And I don't know if it was planned, but Go has turned out to be a boon for contribution. A surprising number of devops engineers are willing to dip their toes in Go waters and I highly doubt they would've done so with Erlang. > I think you'd end up going the chef route, writing the control plane in Erlang and expecting users to interact in Ruby or something like it. DevOps engineers have learned to be comfortable with Ruby (Chef) and Python (Ansible) so this certainly makes sense.

pdimitar 8y ago

> Expecting developers to rewrite everything in Erlang is nuts. ...But I never said that? You are correct on your points and I don't disagree. Golang is certainly a much better choice than Bash indeed. You are also correct on developer willingness to work with Golang. I am aware that K8s and Erlang/OTP are apples to oranges comparison; they serve different needs. Whereas Erlang's runtime (the BEAM VM) can give you fault-tolerance, K8s tries to do roughly the same on a higher level - it tries to give you throwaway containers that can be switched off and on at any time. As I mentioned in my parent comment, I admire their work. What my point was that if you squint your eyes hard, it kind of looks like K8s wants to invent Erlang/OTP for infrastructure (as opposed to Erlang/OTP which gives its guarantees per node).

BraveNewCurency 8y ago
> which gives its guarantees per node There is no such thing, because Nodes (and even entire datacenters) can fail. In other words, node failure is an infrastructure problem that is best NOT handled by your bespoke application code. Replacing failed nodes should NOT be custom code in your app, that way lies madness. > kind of looks like K8s wants to invent Erlang/OTP for infrastructure You can say "K8s and Erlang implement similar ideas implemented at different levels." But you can't pretend one is a substitute for the other, nor that "Erlang has done everything that K8s can do." E.g. Writing in Erlang doesn't magically get you: - deploy/upgrade of the Erlang runtime, including rollback + multiple versions co-existing, including any compiled foreign code (which is required in the article). - ability to log, monitor, probe and reroute the connections between services -- In a standard way such that the application doesn't have to be modified.("service mesh") - Ability for an entire ecosystem of tools to inspect the versions of your application services that are deployed, because it's exposed as an API. - A standard ecosystem of plug-ins for operators (autoscale, autoscale to EC2 spot instances, capacity planning, "best practices" of running a MySQL cluster, etc.) None of these should ever be mixed with the application. (Unless you are Kelsey Hightower: https://github.com/kelseyhightower/hello-universe https://github.com/kelseyhightower/hello-universe )
- pdimitar 8y ago
  > There is no such thing, because Nodes (and even entire datacenters) can fail. Gross over-simplification that I'd also call a strawman. In the face of lack of electricity, of course no computer language matters at all. What's your point?

pjmlp 8y ago

> it doesn't require a VM (goodbye Java) - Neither does Java, only devs clueless about Java world aren't aware of AOT compilers to native code. Also sorry to spoil your fun, Kubernetes was originally written in Java, it was later rewritten in Go as other team took over.

cdoxsey 8y ago
Apparently a prototype was written in Java. Borg was written in c++. AFAIK Kubernetes was always a Go project, but maybe I'm wrong. Why do you think Go was chosen? Your comment about my experience with Java was needlessly provocative so I'm going to ignore it.
- pjmlp 8y ago
  It was mentioned at the FOSDEM 2019 talk about K8S. Nowhere in my commented I addressed the Java remark to your specific person. It was targeted to all of those that bash Java without actually knowing how the rich the eco-system actually is.
  - cdoxsey 8y ago
    You called me a "clueless dev".
    - pjmlp 8y ago
      No I did not, nowhere on my sentence is the direct mention of your person. On my previous comment I explicitly mention it was targeted to developers that bash Java, without having any clue what they are bashing about, cargo cult if you wish. So either you feel offended, because you are indeed attacking Java without having any clue about the Java eco-system, or are deciding to play victim here, when I never mentioned you directly. This is a public forum, so I leave to everyone else and HN moderators to judge my comments, and won't reply to anything else on this thread.