Hacker News Reader

Comment by hamandcheese | Hacker News Reader

I remember being surprised at how hard it was to read the source code for grpc Java. There's an incredible amount of indirection at every turn.

This made it extremely hard to get answers to questions that were undocumented.

It's a shame because I know Google can put out easy to read code (see: the go standard library).

View on HN

> It's a shame because I know Google can put out easy to read code (see: the go standard library).

My guess is that the difference is that go is managed by a small group of engineers that have strong opinions, really care about it, and they have reached "fuck you level", so they can prioritize what they think is important instead of what would look good on a promo packet.

Sass was the first code generator I ever met that produced decent output. I’d been coding for 15 years at that point. Less is the second one.

That’s the end of this story. There are basically two people in the world who have demonstrated that they can be trusted to generate code that isn’t an impenetrable quagmire of pain and confusion.

I doubt it’s an accident that both emitted declarative output rather than imperative, but I would be happy to be proven wrong.

Some of the details inside protobuf in Java can be very convoluted, but they are also the result of intense benchmarking, years of experiences and a long tail with deep legacy support for old java.

Honestly I found the Java bindings to be way better designed and thought out than Golang. On a consumer level, the immutable message builders are fantastic, the one-ofs are decent compared to what Java can offer, and the service bindings actually provide a beautiful abstraction with their 0-1-many model. In Golang, if you only have to deal with Unary rpc they are OK I guess, but I really miss the immutable messages.

To be clear, I'm not talking about generated code or anything touching protobuf serde. Just grpc-the-library. Interceptors, retry policies, channels, etc.

The generated C++ interfaces to gRPC are also filled with an incredible amount of indirection and unnecessary concepts. I'd say it's a "bad at writing complex things simply" culture rather than being Java-specific.

Autogenerated code in general tends to be unreadable. It's not easy and/or not a priority.

I think it's partly a culture thing. Java developers love indirection, and they're used to an ecosystem that doesn't want to be understood. An ecosystem that wants you to google whatever obtuse error message it decides to spit out, and paste whatever half thought out annotation some blog post spits back, into your code to make it work.

I've worked with people who considered anything that wasn't programmed with annotations to be "too advanced" for their use-case.

Java is on life support as a language, but the ecosystem is strong, that's why it has all these weird features via annotations. And people who use Java are just trying to get stuff done like everyone else.

Java is doing quite well.

How is it on life support, when it’s by far the biggest server-side language, running basically every top companies’ business critical infrastructure?

Also, annotations are just metaprogramming, which can be tastefully applied.

Like I said, the ecosystem is strong. The language's design hasn't aged well, so nowadays any Java code I see in prod has 1-4 annotations above every class and method to get around the limitations of the language. Similar to how some C code will rely heavily on macros.

That’s not due to the language, but due to the business domain (I assume web development). In this domain almost every framework, regardless of language, will heavily use metaprogramming, see django, etc.

Javascript and Golang didn't need metaprogramming for this. Some of this has to do with not adhering to the OOP-everywhere model. Where's the metaprogramming in Django?

What an idiotic comment.

Reply on news.ycombinator.com