3 ms·

> Kubernetes moved when some Go advocates joined the team and pushed for a rewrite Frankly, that hardly says anything about the technical merits of that switch

> Kubernetes moved when some Go advocates joined the team and pushed for a rewrite Frankly, that hardly says anything about the technical merits of that switch. In fact, it reads like a poorly-though tautology.

pjmlp 4y ago
Just paraphrasing the FOSDEM talk in one sentence, so....
0des 4y ago
Zababa 4y ago
But nobody is talking about the technical merits of that switch or of Go, we're talking about the popularity of Go. If tomorrow I create a language called "Gorilla" that is a worse language than Go, that Kubernetes switches to Gorilla and that Gorilla gets popular, there's a good chance that the switch will help the popularity of Gorilla. If instead I create a language called "Whale" that is a better language than Go, and the same thing happens, again the switch will have helped the popularity of Whale. The exact same thing will happen with a language exactly the equal of Go. All of that to say, technical merit has nothing to do with it, it was never the subject.
Thaxll 4y ago
Well it's pretty clear 10 years ago than Java would have been a disaster, imagine all the controle planes + pods + side cars etc ... running on the JVM, you would have needed 20x more memory. Even to this day JVM memory consumption is way way higher than Go and it would make no sense to use it in Kubernetes. It's resources than workload could not use meaning higher overhead for Kubernetes which would reduce adoption.
- arinlen 4y ago
  > Well it's pretty clear 10 years ago than Java would have been a disaster, imagine all the controle planes + pods + side cars etc ... running on the JVM, you would have needed 20x more memory. I'm not sure if you are aware, but the web runs on Java. Android is also Java, thus even the people in charge of developing one of the most popular resource-constrained devices in history disagree with you. Beyond desktop (specially games, except Minecraft), front-end and embedded devices, you'd be hard-pressed to find any class of applications whose bread and butter does not involve the JVM. Even desktop, Microsoft is heavily invested in C#, which was the company's answer to Java and dubbed "an imitation" and described as "(..) sort of Java with reliability, productivity and security deleted." https://en.wikipedia.org/wiki/C_Sharp_(programming_language)#History https://en.wikipedia.org/wiki/C_Sharp_(programming_language)... Frankly, I'd question the competency and technical background of anyone who throws that sort of uninformed and detached criticism at Java.
  - Thaxll 4y ago
    Android is C/C++, or maybe you mean the app that you deploy on Android are built in Java right? I stand my point, the JVM is not the right tool to build components for Kubernetes because Kubernetes needs lots of small service running everywhere, running those in the JVM would have resulted in large memory consumption. You can try yourself, build a very simple hellow world web app with the most popular JVM ( Oracle one ) on version 8 for example, you'll see how much memory it uses by default.
    - pjmlp 4y ago
      Try to develop Android apps with the NDK alone and see how far you get, unless you're doing a game without networking. Outside the Linux kernel, Treble drivers (which also suports Java alongside C++), ART infrastructure, most of the Android code is written in Java.
    - arinlen 4y ago
      > Android is C/C++ It really isn't, and frankly this sort of comment makes it quite clear how uninformed you need to be to make this sort of claim. I mean, even the Android NDK specifies quite clearly in its own description that it's only designed to offload parts of an Android app to C++. https://developer.android.com/ndk https://developer.android.com/ndk In the Android projects I worked, the Android NDK was only used to implement small performant components that sat on the hot path, such as image processing work. Even so, the experience was not exactly on the happy path. > I stand my point, the JVM is not the right tool to build components for Kubernetes because Kubernetes needs lots of small service running everywhere, running those in the JVM would have resulted in large memory consumption. This personal assertion has no bearing in the real world. Not only do we have high frequency trading apps developed in Java but you're also succumbing to absurd beliefs that you get architectural wins for free by switching the programming language. Also, it's absurd to make clams about the needs of running "lots of small services" when the web is already served by "lots of small services" developed in Java with non-performant web app frameworks, which are subsequently ran by the likes of Kubernetes.

pjmlp 4y ago

Just paraphrasing the FOSDEM talk in one sentence, so....

0des 4y ago

Zababa 4y ago

But nobody is talking about the technical merits of that switch or of Go, we're talking about the popularity of Go. If tomorrow I create a language called "Gorilla" that is a worse language than Go, that Kubernetes switches to Gorilla and that Gorilla gets popular, there's a good chance that the switch will help the popularity of Gorilla. If instead I create a language called "Whale" that is a better language than Go, and the same thing happens, again the switch will have helped the popularity of Whale. The exact same thing will happen with a language exactly the equal of Go. All of that to say, technical merit has nothing to do with it, it was never the subject.

Thaxll 4y ago

Well it's pretty clear 10 years ago than Java would have been a disaster, imagine all the controle planes + pods + side cars etc ... running on the JVM, you would have needed 20x more memory. Even to this day JVM memory consumption is way way higher than Go and it would make no sense to use it in Kubernetes. It's resources than workload could not use meaning higher overhead for Kubernetes which would reduce adoption.

arinlen 4y ago
> Well it's pretty clear 10 years ago than Java would have been a disaster, imagine all the controle planes + pods + side cars etc ... running on the JVM, you would have needed 20x more memory. I'm not sure if you are aware, but the web runs on Java. Android is also Java, thus even the people in charge of developing one of the most popular resource-constrained devices in history disagree with you. Beyond desktop (specially games, except Minecraft), front-end and embedded devices, you'd be hard-pressed to find any class of applications whose bread and butter does not involve the JVM. Even desktop, Microsoft is heavily invested in C#, which was the company's answer to Java and dubbed "an imitation" and described as "(..) sort of Java with reliability, productivity and security deleted." https://en.wikipedia.org/wiki/C_Sharp_(programming_language)#History https://en.wikipedia.org/wiki/C_Sharp_(programming_language)... Frankly, I'd question the competency and technical background of anyone who throws that sort of uninformed and detached criticism at Java.
- Thaxll 4y ago
  Android is C/C++, or maybe you mean the app that you deploy on Android are built in Java right? I stand my point, the JVM is not the right tool to build components for Kubernetes because Kubernetes needs lots of small service running everywhere, running those in the JVM would have resulted in large memory consumption. You can try yourself, build a very simple hellow world web app with the most popular JVM ( Oracle one ) on version 8 for example, you'll see how much memory it uses by default.
  - pjmlp 4y ago
    Try to develop Android apps with the NDK alone and see how far you get, unless you're doing a game without networking. Outside the Linux kernel, Treble drivers (which also suports Java alongside C++), ART infrastructure, most of the Android code is written in Java.
  - arinlen 4y ago
    > Android is C/C++ It really isn't, and frankly this sort of comment makes it quite clear how uninformed you need to be to make this sort of claim. I mean, even the Android NDK specifies quite clearly in its own description that it's only designed to offload parts of an Android app to C++. https://developer.android.com/ndk https://developer.android.com/ndk In the Android projects I worked, the Android NDK was only used to implement small performant components that sat on the hot path, such as image processing work. Even so, the experience was not exactly on the happy path. > I stand my point, the JVM is not the right tool to build components for Kubernetes because Kubernetes needs lots of small service running everywhere, running those in the JVM would have resulted in large memory consumption. This personal assertion has no bearing in the real world. Not only do we have high frequency trading apps developed in Java but you're also succumbing to absurd beliefs that you get architectural wins for free by switching the programming language. Also, it's absurd to make clams about the needs of running "lots of small services" when the web is already served by "lots of small services" developed in Java with non-performant web app frameworks, which are subsequently ran by the likes of Kubernetes.