Hacker News Reader

Comment by steno132 | Hacker News Reader

[flagged]

I strongly disagree with this view for applications, and mildly disagree for infrastructure projects.

There is one thing I believe Go is by far and away the leader at: keeping codebases maintainable over time.

Go is designed very clearly with this goal and it's excellent at it. The verbosity you complain about makes it much, much clearer what something is doing. That coupled with some of the baked in opinions means it is significantly more straightforward to pick up code that you or someone else wrote a few years ago and modify it.

See, this is a problem I see many junior engineers struggle with: Excessive desire to make one's own life easier at the cost of customers.

Yes, your codebase is nice and elegant and maintainable. But you haven't shipped as many features as the Python or Java developer, haven't delivered as much value to customers. Ultimately, the users suffer. It's a form of selfishness.

I've never seen teams as efficient at shipping stuff as when they switched to Go. At multiple companies. Complete fallacy on your part.

To follow your logic: if I pump out a lot of features but others find my code difficult to maintain I'm not being selfish.

If I write code more slowly that others find easier to maintain, that is selfish?

I’ve observed the exact opposite. Python teams are much slower to ship features than Go teams once the codebase grows to a nontrivial size.

Never saw a Java developer ship things fast.

I have extensive experience with Go, Python, Java, and Scala. I write Scala and Java at my day job, and find I am far more productive in Go than either of these.

Your framing of the issue in terms of infrastructure projects vs. applications seems bizarre and simplistic. For example, one of the areas where Go shines is in highly concurrent, io-bound, networked services. Many examples of good use cases for Go in the wild: Kubernetes, CockroachDB, TiDB, etc.

https://www.cockroachlabs.com/blog/why-go-was-the-right-choi...

SIMD is possible in Go, see: https://github.com/bytedance/sonic

Between Go and Rust for infra, let's say that Go is the #1, Rust if far far behind. Most recent infra tools are built in Go, Kubernetes, Docker, Prometheus, Grafana, Terraform etc ...

Yes, SIMD is possible. But what about the other more obscure hardware features there's no nice library for? It's much easier to use those in Rust than Go.

Author of the blog here: I'm a huge proponent of Rust, but in this project while interfacing with BigQuery and Snowflake go proved to be the right choice. There weren't official drivers for these in Rust and also generally onboarding new devs in Go was easier. I also personally think async in rust has a few more releases to go before I would consider it stable.

> For applications, use Java or Python.

What’s the deployment story like ? Here’s a hot take of mine: we should treat our users as master and make their lives easier, not ours.

Agreed. We should make life easier for our users. That's why a language like Python or Java, with a faster development time, where we can fix bugs faster and ship features faster, is vastly preferable.

How do you deliver your python package ? How does the end user fetch dependencies ? A proxy ? Pip ? Jfrog ? System packages ? Is he root ? Or behind a corporate proxy / firewall ?

That’s a hot mess to manage.

The parent probably doesn't understand what you're talking about. Case in point.

Java more productive than go?

If you judge productivity by lines of code, absolutely.

https://github.com/Hello-World-EE/Java-Hello-World-Enterpris... is an excellent demonstration of this.

Java developers tend to produce more value since they can write the code in a more concise way using Lambdas, functional interfaces, record classes, etc. Overengineering like in your example above can be done in any language, but shouldn't.

If only go had lambdas, functional interfaces and record classes...

Reply on news.ycombinator.com