4 ms·

> - After Docker and Kubernetes explosion, all Cloud Native Foundation projects start using the same language, thus adoption This take sounds highly unrealisti

> - After Docker and Kubernetes explosion, all Cloud Native Foundation projects start using the same language, thus adoption This take sounds highly unrealistic. No one in their right mind would ever say "well Docker/Kubernetes were developed in Go, thus that means it's a good idea to develop a totally unrelated application that bares no resemblance or shares any use case in Go as well". Also, migrating away from an interpreted language to a compiled one to develop performance-minded applications does not mean that the compiled language is suddenly spectacular. It just means the initial proof of concept ran it's course.

mountainriver 4y ago
That is very much what happened. Go became the de facto language in the cloud native community, which to this day is its biggest crowd
- anthk 4y ago
  Well, Plan9 was the cloud (networked) OS simplyfing C and making Unix even more ubiquitous, so it has sense. Go is the legacy of Plan9 "ported" back to Unixlikes and C.
  - pjmlp 4y ago
    Go is the legacy of Limbo (Inferno), not Plan 9.
    - anthk 4y ago
      Limbo was built around Plan9, and the static binary (cross) compiling comes from plan9's C.
      - pjmlp 4y ago
        Inferno isn't Plan 9. As for that cross compiling feature, Amsterdam Compiler toolkit did it before Plan 9 was even an idea.
pjmlp 4y ago
The amount of Go projects in Cloud Native Foundation shows otherwise. Most people pick languages based on platforms, not a language in isolation and go hunting for projects. As for the point migrated to a compiled language from Python, if it wasn't for the shinny thing, the migration would have been to a compiled language with proven record in prodution like C and C++, as it is common on the ecosystem. And regarding Java, everyone that actually knows the ecosystem is aware of AOT compilers since 20 years now, even if they have been available as commercial only for the most part.
- arinlen 4y ago
  > The amount of Go projects in Cloud Native Foundation shows otherwise. That says nothing at all, actually. Beyond the transparent appeal to authority, why would anyone take decisions seriously when they are made without any technical merit in mind and just follow a mix of cargo curlting and pushing in-house tools, such as the case of the kubernetes migration to Go? > Most people pick languages based on platforms, not a language in isolation and go hunting for projects. The whole point of this discussion is that people don't, and make decisions without any technical merit in mind. > As for the point migrated to a compiled language from Python, if it wasn't for the shinny thing, the migration would have been to a compiled language with proven record in prodution like C and C++, as it is common on the ecosystem. This personal assertion ignores the fact that there are plenty of alternatives that considerably improve over C++, let alone C (?!), not to mention that it reiterates again the mindless cargo cult mentality behind Go. > And regarding Java, everyone that actually knows the ecosystem is aware of AOT compilers since 20 years now, even if they have been available as commercial only for the most part. I don't understand what point you tried to make with regards to Java, specially as the Kubernetes migration from Java to Go was pushed by people who worked on Go, and thus it had an unavoidable self-serving "eat your own dogfood" aspect to it.
  - lelanthran 4y ago
    > This personal assertion ignores the fact that there are plenty of alternatives that considerably improve over C++, let alone C (?!) While it is easy to improve on C++ it's proven difficult to improve on C[1]. C++ is an exceptionally large language, with lots of features that interact in subtle ways which trip-up even experienced programmers from time to time. It includes all the footguns from C, and adds an order of magnitude more. C is a dead-simple language with only a few really dangerous footguns (which are also present in C++), mostly related to memory errors (corruption, leaks, races, etc). I view C++ as "C with more footguns". I view Go as "C without the memory error issues". It's not really comparable to C++ because it is a better C, not a better C++. [1] I think that only Go has managed to improve on C.
bakuninsbart 4y ago
There's a number of things at work in these situations, but I people who start out and/or want to work for Docker are highly incentivised to learn Go, and have a Job with Go in the description. In the current job market, if developers want to use a specific language, it is often times a good idea for companies to just go with that language, even if it isn't the perfect fit for the project... And then again, project leads aren't immune to hype either, a new, popular language will be used more, simply through being hip and attractive.
- arinlen 4y ago
  > And then again, project leads aren't immune to hype either, a new, popular language will be used more, simply through being hip and attractive. Resume-driven development does sound like a key factor, even in the decision by Go advocates in Google that pushed for Kubernetes to be rewritten in Go. But somewhere along the line people are forced to consider technical aspects.
slyall 4y ago
There is a well known article (which I am totally blanking on) arguing that many successful programming languages are the Native/System Languages of a major platform. So C is the System Language of Unix, Javascript is the Native Language of the Browser, C++ for most operating systems. Kubernetes and containers are a major platform. You could say the System language for it and related projects is Go.
dcchambers 4y ago
> This take sounds highly unrealistic. > No one in their right mind would ever say "well Docker/Kubernetes were developed in Go, thus that means it's a good idea to develop a totally unrelated application that bares no resemblance or shares any use case in Go as well". I agree that this take sounds silly, but in practice I've seen it play out just like that. So many projects centered around CloudNative seemed to have picked Go simply because it's the language used by many other leading CloudNative tools. GoLang == the cloud native language according to many folks.
eweise 4y ago
"No one in their right mind would ever say "well Docker/Kubernetes were developed in Go, thus that means it's a good idea to develop a totally unrelated application that bares no resemblance or shares any use case in Go as well"." I guess there are a lot of crazy people out there because I've heard this mentioned numerous times.
marcosdumay 4y ago
Yeah, I do agree that it's not a smart thing to say. But nearly all the times I saw somebody picking a platform to standardize on, they have a similar rationale. I guess there are just no good reasons for choosing one platform over another to standardize a team. Or people that insist on standardizing tend not to act on good reasons.

mountainriver 4y ago

That is very much what happened. Go became the de facto language in the cloud native community, which to this day is its biggest crowd

anthk 4y ago
Well, Plan9 was the cloud (networked) OS simplyfing C and making Unix even more ubiquitous, so it has sense. Go is the legacy of Plan9 "ported" back to Unixlikes and C.
- pjmlp 4y ago
  Go is the legacy of Limbo (Inferno), not Plan 9.
  - anthk 4y ago
    Limbo was built around Plan9, and the static binary (cross) compiling comes from plan9's C.
    - pjmlp 4y ago
      Inferno isn't Plan 9. As for that cross compiling feature, Amsterdam Compiler toolkit did it before Plan 9 was even an idea.

pjmlp 4y ago

The amount of Go projects in Cloud Native Foundation shows otherwise. Most people pick languages based on platforms, not a language in isolation and go hunting for projects. As for the point migrated to a compiled language from Python, if it wasn't for the shinny thing, the migration would have been to a compiled language with proven record in prodution like C and C++, as it is common on the ecosystem. And regarding Java, everyone that actually knows the ecosystem is aware of AOT compilers since 20 years now, even if they have been available as commercial only for the most part.

arinlen 4y ago
> The amount of Go projects in Cloud Native Foundation shows otherwise. That says nothing at all, actually. Beyond the transparent appeal to authority, why would anyone take decisions seriously when they are made without any technical merit in mind and just follow a mix of cargo curlting and pushing in-house tools, such as the case of the kubernetes migration to Go? > Most people pick languages based on platforms, not a language in isolation and go hunting for projects. The whole point of this discussion is that people don't, and make decisions without any technical merit in mind. > As for the point migrated to a compiled language from Python, if it wasn't for the shinny thing, the migration would have been to a compiled language with proven record in prodution like C and C++, as it is common on the ecosystem. This personal assertion ignores the fact that there are plenty of alternatives that considerably improve over C++, let alone C (?!), not to mention that it reiterates again the mindless cargo cult mentality behind Go. > And regarding Java, everyone that actually knows the ecosystem is aware of AOT compilers since 20 years now, even if they have been available as commercial only for the most part. I don't understand what point you tried to make with regards to Java, specially as the Kubernetes migration from Java to Go was pushed by people who worked on Go, and thus it had an unavoidable self-serving "eat your own dogfood" aspect to it.
- lelanthran 4y ago
  > This personal assertion ignores the fact that there are plenty of alternatives that considerably improve over C++, let alone C (?!) While it is easy to improve on C++ it's proven difficult to improve on C[1]. C++ is an exceptionally large language, with lots of features that interact in subtle ways which trip-up even experienced programmers from time to time. It includes all the footguns from C, and adds an order of magnitude more. C is a dead-simple language with only a few really dangerous footguns (which are also present in C++), mostly related to memory errors (corruption, leaks, races, etc). I view C++ as "C with more footguns". I view Go as "C without the memory error issues". It's not really comparable to C++ because it is a better C, not a better C++. [1] I think that only Go has managed to improve on C.

bakuninsbart 4y ago

There's a number of things at work in these situations, but I people who start out and/or want to work for Docker are highly incentivised to learn Go, and have a Job with Go in the description. In the current job market, if developers want to use a specific language, it is often times a good idea for companies to just go with that language, even if it isn't the perfect fit for the project... And then again, project leads aren't immune to hype either, a new, popular language will be used more, simply through being hip and attractive.

arinlen 4y ago
> And then again, project leads aren't immune to hype either, a new, popular language will be used more, simply through being hip and attractive. Resume-driven development does sound like a key factor, even in the decision by Go advocates in Google that pushed for Kubernetes to be rewritten in Go. But somewhere along the line people are forced to consider technical aspects.

slyall 4y ago

There is a well known article (which I am totally blanking on) arguing that many successful programming languages are the Native/System Languages of a major platform. So C is the System Language of Unix, Javascript is the Native Language of the Browser, C++ for most operating systems. Kubernetes and containers are a major platform. You could say the System language for it and related projects is Go.

dcchambers 4y ago

> This take sounds highly unrealistic. > No one in their right mind would ever say "well Docker/Kubernetes were developed in Go, thus that means it's a good idea to develop a totally unrelated application that bares no resemblance or shares any use case in Go as well". I agree that this take sounds silly, but in practice I've seen it play out just like that. So many projects centered around CloudNative seemed to have picked Go simply because it's the language used by many other leading CloudNative tools. GoLang == the cloud native language according to many folks.

eweise 4y ago

"No one in their right mind would ever say "well Docker/Kubernetes were developed in Go, thus that means it's a good idea to develop a totally unrelated application that bares no resemblance or shares any use case in Go as well"." I guess there are a lot of crazy people out there because I've heard this mentioned numerous times.

marcosdumay 4y ago

Yeah, I do agree that it's not a smart thing to say. But nearly all the times I saw somebody picking a platform to standardize on, they have a similar rationale. I guess there are just no good reasons for choosing one platform over another to standardize a team. Or people that insist on standardizing tend not to act on good reasons.