[pas]

> what makes someone go such a great length to bash ...

"""

Inherent complexity does not go away if you close your eyes.

When you choose not to care about complexity, you're merely pushing it onto other developers in your org, ops people, your customers, someone. Now they have to work around your assumptions to make sure everything keeps running smoothly.

And nowadays, I'm often that someone, and I'm tired of it.

"""

> [Go] works brilliantly for the projects I've encountered.

Of course, C, C++, PHP and JavaScript works too! Of course many many many things "work" in our world. Of course just adding one more lane works too, of course police states work too!

Yet something else would work even more brilliantly?

[eikenberry]

That quote sounds like an argument against Rust, not GO. Rust is a complex language and that complexity doesn't go away if you close your eyes to it either. All complexity adds to project complexity.

[pas]

The implicit argument is that there's some irreducible non-negotiable project complexity in real-world software, and the explicit argument in the post is that you can either put it into the language/compiler or keep it in wetware.

The supporting argument in the text is that even simple things like downloading a file can get hairy very fast. Networks are complex, HTTP, IPv4/v6, DNS - it's always DNS! - filesystems, permissions, running out of space, computer runs out of battery, etc.

Probably a better argument would be to focus only on application logic (type system, error handling, syntactic-semantic ergonomics) and show that a complex piece of Go [like the k8s persistent volume controller] can be written in a nicer, more maintainable, safer way in Rust.

Of course not all Go code achieves Kubernetes-level complexity. And I think it makes sense to pick the right tool for the job, which is whatever the team/programmer is productive with. (And here productivity is measured based on how well the resulting code/software solves the business case. And basically if there's no need for Rust-level safety/quality/maintainability, or if there's an explicit need for Go-level cheaper hackability, then that's a great result business-wise.)

The important corollary of this is that business requirements tend to change, yet software has inertia and that's roughly how we ended up with insert famously bad software that got wildly popular unexpectedly (for example Windows, Macromedia/Adobe Flash and the infamous plugin, random low-level crap in appliances, and adjacent to that the Bluetooth stack that got rewritten in Rust for Android).

So - of course - for society it would be amazing if software would be better from the start. (Duh!)

Also, one more thing I think worth mentioning, is that the argument about the lack of information in code at callsites in Go (is something passed by reference or by value), how hard it is to keep boundaries (immutability) is basically an argument for making this complexity up-front and visible. Hence Rust looks complex. (And again, the argument is that it's there even if Go hides it.)

https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html

https://github.com/kubernetes/kubernetes/blob/60c4c2b2521fb4...