Hacker News Reader

Comment by gnur | Hacker News Reader

A language that young professionals can use right away and can even support complex projects like kubernetes, Prometheus, consul etc. sounds like an excellent choice for companies to adopt. It might not be as elitist as rust or clojure but if collaboration is important for your project I'd rather have simple without foot guns rather then amazing with dragons all over.

View on HN

> It might not be as elitist as rust or clojure but if collaboration is important for your project I'd rather have simple

I'm not a rust fanboy, but I wonder why people have the assumption that programming should _not_ be elitist. Where did we get the idea that programming should not be a skilled trade, but rather something the everyman can do?

> without foot guns rather then amazing with dragons all over.

Ironically, Rust and Clojure have less "footguns" if we're talking about concurrency and parallelism.

It’s a good aspiration to eliminate needless complexity from a language so people can spend their cognitive resources (be they great or few) on solving real problems. If you can lower the barrier such that a layman can do it, then a genius specialist can do that much more.

The problems don't go away. If the language refuses to handle them and refuses extensibility, every end user now needs to handle those problems without standard tools.

This hasn’t been my experience. I’ve been involved in the language and community for nearly a decade and I’ve never seen an incident where the grievances against the language weren’t seriously overblown. The most credible one has been dependency management. There’s still plenty of room for improvement of course, but the idea that Go’s flaws make it anything short of one of the most productive languages is generally nonsense.

Also, go is an elitist language as well, in its own way. Its creators and many of the first proponets were big Unix/C/Bell Labs names. Quite opinionated people.

The Kubernetes codebase would probably be a lot less complicated, if Go the language itself were not so simple: https://medium.com/@arschles/go-experience-report-generics-i...

If anything, Kubernetes is a good example of where Go should not be used.

They were going to use Java, but it was deemed too complex and there was strong pro-Go advocacy to move the prototype away from Java into Go.

https://changelog.com/gotime/105

https://archive.fosdem.org/2019/schedule/event/kubernetesclu...

Kubernetes beat Mesos/Marathon, which is written on Scala. I don't think that's just a coincidence.

Failure of a project's adoption usually traces back to people and management, not technology.

I think that has more to do with the fact the k8s devs had a complete implementation of the the same product (Google's Borg) as reference. Mesos/Marathon only had a couple 10 page journal articles to look at and a ton of on the ground decisions to make and quantify the choices of.

I’ve heard the statements that the Go stdlib and Kubernetes are not good examples of Go code, but I’ve never seen someone say that it’s not a good use case for Go. Would you mind elaborating on that assessment?

There's a real analogy to be made here with mass production and it's impact on labor. We quickly went from a society that valued individual craftsmanship to one that valued the ability to treat people like cogs at the factory. I'm not even mad, mass production is a great thing that enabled access to goods that many people would never have otherwise had. But eventually there was a backlash, and handcrafted, high quality goods are preferred by many who can afford them.

I'm not saying Go programmed products are lower quality, just that we've enabled certain types of organizations with the advent of greater process and rigor in languages. Someday the pendulum will likely swing again.

we even treat education like this. children are educated as mass produced laborers for the future

> I'm not saying Go programmed products are lower quality

I've met plenty of good developers that complain at how Go ties their hands and creativity. Unsurprisingly, the language has been designed for "cogs":

---

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike

---

Reply on news.ycombinator.com