I am stuggling with helm/kubernetes and the new company's ecosystem where everybody is new in the team. We are expected to deliver according to a plan while we keep hunting for relevant info.
I would say the second point is a lot more nuanced than stated.
This _could_ be true for some, but it directly conflicts with the stated goals of the language. Most people (that I've spoken to) would consider Go to be a simpler language, with fewer features, than other comparable languages.
The issue with Go is the implicit footguns you will inevitably hit. Starting out with Go sure feels like a super power because of the simplicity and productivity, until the code base has grown and you now meticulously inspect every single line to understand the entire context a change is bringing, because you do not trust it in isolation to be correct.
Python is also an easy to learn language, and you'll likely make correct programs quickly. Idiomatic Python, though, is a longer road. You won't feel confident to open source your code for months.
Saw a company fail because all developers were expected to master k8/helm etc. A couple of us got the hang of it well enough to get by. But almost everyone failed too.
Even those of that had it working, it was a huge time sink.
In what way were the developers expected to "master" k8/helm? In the sense of actually making contributions to the k8/helm setup, or simply using an existing k8/helm setup to provide a development environment? Was there any "expert" person on the team that everyone could ask about k8, or was everyone simply supposed to pick things up on their own?
(asking because my own team is currently moving in this direction, and I'm curious about the pedagogical challenges we might face)
Ima be facetious here and suggest that the above is meant in the sense that K8 is the ultimate leaky abstraction and you have to "master" it first before even starting starting to achieve anything with it.
And Helm is just closing the cycle of Samsara - if you really want to base your operations on string templating, just use bash lol. Or hand-written forms on paper, still faster and you still get a better idea of what's going on.
There's also the problem of many developers nowadays just not having the hacker mindset/actual high-level abstract thinking/attention span, so instead of seeing the whole of K8S as the pointless kludge it is, they only see the interface - yay, YAML, I know that language! (usually they know it from everyone's favourite "dead" tool, docker-compose; which is a gem) - and they go on to fight with it tooth and nail, with corresponding feelings of "achievement" and "mastery".
I think the "10 years PHP/Java -> 3 days Go" thing from granduncle's cousin post is meant to point out this particular paradoxical situations.
But it could hurt people's feels to say it like that so let's just let Google do all our thinking for us instead. We truly live in a gilded age of computing.
Anyone who is either insecure about their own skills, or so proud of their skills in their area that they can't face being a beginner in another area, will struggle and come up with reasons not to learn it. And they'll tell their nontechnical colleagues or managers that the idea is overengineered, or they'd add more value elsewhere, until it happens or they leave.
That's why I'm a huge fan of server-less. Let Amazon or Google handle the tough parts until your company is big enough to have to optimize for server costs.
> I am stuggling with helm/kubernetes and the new company's ecosystem where everybody is new in the team.
I can't speak for Helm, but working with Kubernetes in Go is almost uniquely difficult. Kubernetes modules are designed to be dynamic, and Go's type system doesn't make that easy, which leads to some cludge-y code out of necessity.
Plus the API is vast, and it's sometimes not clear what package you need for a particular use.
golang is a language designed for fresh graduates to write fast code without much thinking. It isn't tough at all. For engineers that never worked with CSP paradigm, or rather for engineers who only ever work with Java style OOP and concurrency, it might be weird to adjust, and they will spend 3/4 of their time bitching about how much it is easier in language X.
I am stuggling with helm/kubernetes and the new company's ecosystem where everybody is new in the team. We are expected to deliver according to a plan while we keep hunting for relevant info.
I would say the second point is a lot more nuanced than stated.