I want to yell BINGO! because my buzzword bingo card just got a full row. No, I’m not sure what you’re trying to say and I’m guessing at what “Cloud Native” implies.

Go, Java, C++ all share the status of being OO/imperative mutable languages. You’ve got a “Cloud Native” environment optimized for that type of language, yet you’re surprised why languages that do not fit that category do not fit in well? Do you also ask why Haskell, Ocaml, Prolog, Forth, etc. are not well represented in your environment? Interoperability and reuse all require some common denominator of assumptions to work smoothly - the lowest common denominator. They discriminate against languages whose strength is something they never considered.

The Erlang VM and programming model, which Elixir adopts, was first developed in the late 80’s, and is effectively a progenitor to “Cloud Native”. They did it 30 years ago. Each GenServer is a microservice. Instead of JSON, they speak in the shared vocabulary of Erlang terms. They can be distributed among multiple physical servers or live within a single server with no change to the programming model. Instead of coding in YAML (via k8s) to manage restart policies, you use Elixir/Erlang – the same language as your primary business logic.

Elixir/Erlang represents a “cloud” within a single OS-level process. To wrap a single GenServer as a “microservice” managed by others is a step backward, IMHO.

Right, so why would those big tech companies invest so much money in something that has been solved since the 80s?

Well also don’t forget that Sun literally spent billions of dollars marketing Java, which overshadowed any technical advantage that erlang could have brought to the scene in the 90s. Google was originally a Java shop, and kubernetes, while written in go, is built on top of java technology (https://youtu.be/4VNDjwzzKPo), and even if it weren’t, cargo culting google is totally a thing in tech.

There was a similar discussion here on the forums, where I tldr’ed the likely reason: