Skip to content

Comment on The secret guild of Silicon Valleyparent

Comments

It's not a question of what's "unfashionable" for me to be caught using [However: I write C and Assembly, thank you very much]. The question is "what languages do the neckbeards use?" In my experience, writing Java is a shaving offense. They might even make you wear a suit.

Java isn't "cool", and I agree that the language itself is frustratingly verbose and kind of lame, but the frameworks built around it are solid. And believe me, many of the Apache Foundation contributors are unquestionably full-on neckbeards.

I'm being overly glib, sorry for that.

I've seen a lot of cool things done in Java. I don't mean to imply otherwise. I've also seen a lot of really cool things done in Fortran and COBOL, many of them by unquestionably full-on neckbeards.

That said, within the population of people I know well, the experts who really understand low-level details of computing do not chose to write Java.

For systems-level apps and so forth, I 100% agree (I have done a lot of systems stuff in C and C++ in my life).

For web apps that scale out to a certain level, Java + Spring + Hibernate + Tomcat works boringly well. That is Java's niche. As you inferred, I wouldn't use it for much else.

Above a certain scale, you're back to C++, of course.

Hibernate works entertainingly bad. If you don't have a very fancy data model (lots of different entities but relative small tables), you better stick to bare spring jdbc-templates.

That just sounds like an attitude straight out of 1998 to me. I'm sure there are people who still operate that way, but I'm not convinced that they're the elite programmers. Scaling an app used to be about squeezing cycles from a single-core machine, now it's about maintaining correctness across dozens/hundreds of 16-core machines.

It's about both. Thinking about scaling on multicore systems doesn't replace thinking about low-level in-core performance details. It's something that an expert needs to be able to handle as well as everything that they already needed to know before multi-core systems became common.

Sure, I recently wrote a program in C to process a lot of data and consciously made the decision not to go multicore because I figured extra cache misses and mutexing/spinlocking while data was passed across queues wouldn't justify the additional CPU cycles I was getting for that particular problem.

I'm primarily a Java guy but am capable of switching to C, writing decent code there, and making decisions like that. Someone who refuses to use Java because it's too "corporate" might be a better C programmer than me but they're not a better programmer.

Take a look at the code in java.util.concurrent sometime, specifically the inner Sync classes. If that's insufficiently "hardcore" for you, I don't know what to say.

Leveraging Java doesn't somehow make it impossible for someone to think about "low-level in-core performance details".

No one has suggested that it does (at least, no one in this thread).

Look, I get that there are people who really like Java, and that you've had to defend it for years against (often bogus) claims that it can't be used for x and y. I am not making any claims of the sort. Here is what I claim, put absolutely precisely so we can stop this nonsense:

The intersection of the following sets

  1. engineers who I know
  2. engineers who think deeply about performance
  3. engineers who choose to write Java
is empty.

That's it. I haven't claimed that writing Java makes you uncool. I haven't claimed that it's impossible to do anything in Java. I haven't claimed that Java is unsuitable for any task. It's entirely possible that I simply don't know the right people, and that even though the intersection of the first two sets is large, it's not large enough. I certainly don't know everyone.

> writing Java is a shaving offense

This is spectacular in its depth and brevity.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.