Hacker News Reader

Hacker News

Comment by tester756 | Hacker News Reader

Parent Full thread

tester756

You guys were creating Java?

> ~1,000 classes in 1.1, ~10K in 1.2 the next year.

9K classes in a year sounds crazy as hell

View on HN

A typical well-designed class will usually be a few hundred lines of code, tops. Often less than 100 lines.

9k classes * 100-300 == 900k-2.7m LOC

Not TOO crazy for the most complete standard library ever developed, for a language meant from the beginning to take over enterprise business computing.

How many LOC are in whatever meme language is hype this year? Hell, I feel like I see nearly that many lines of console output, when I run NPM to pull in dependencies, lol.

This is the kind of comment I come to HN for. That's a powerful insight on work estimation.

That's 36 classes per *day* (900/250 workdays)

I don't know how many people were working on that

but when developing standard library you do not really want to rush designs. You want to be very, very careful about it.

Here's a book about it from one of the most experienced people in API/Standard lib design on the planet

https://www.amazon.com/Framework-Design-Guidelines-Conventio...

I can't speak for grandparent commenter. However, I can point out that the standard library for Java 17 has a TOTAL of 4,388 classes. TODAY. A quarter-century after the timeframe that they're talking about:

https://docs.oracle.com/en/java/javase/17/docs/api/allclasse...

So if ~10k classes were really written in a year, then I can only assume that most of that was the compiler or virtual machine runtime (i.e. C++ code) rather than the standard library Java code.

Regardless of how anyone feels about "verbosity" or "design patterns" in Java application code, the underlying JDK is pretty inarguably one of the most solid and impressive pieces of tech ever developed. I'm not throwing any rocks at that codebase.

>the underlying JDK is pretty inarguably one of the most solid and impressive pieces of tech ever developed.

I agree, JVM is impressive.

I think the first part of a standard lib is pretty straightforward to design. String operations, math, standard protocols, I/O are petty well understood. It gets more tricky once you get to higher levels abstraction like UI.

Nio and streams API show that even those were not evident from the beginning of java.

> ... pretty straightforward to design. String operations ...

Tell that to Haskell.

Also, I've seen some pretty gnarly use of String in Java.

I think much of the maligning Java gets is either due to people looking at badly written Java (2k LOC classes, factories of factories of factories, 15 arg methods, import * everywhere, etc.), or claims in error because they are not based on modern Java (claiming bad parallelism a la Hensen, citing a lack of modules, noting no functional support).

I think Java is a good language if your problem space is ok with the GC and some other quirks.

The problem space I've been in has issues with GC, so C++ or Rust are the main choices there (Go too, but not my preference).

Java has long been crippled beyond the regular GC limitations by lack of value types, but that’s finally, finally going away.

Explains why there are no production Java applications...

FTFY...

Explains why there are no high performance production Java applications...

Yeah, other than Kafka, Spark, Cassandra, Flink, Hadoop, Elasticsearch what has Java ever done for us!

Given there are hft firms built on Java…

I read comments like this all the time on HN and Reddit. But it's hard for me to separate real professional experience at day jobs, from hobbyist wishful thinking in personal side projects.

All I know is that I attend a lot of Java conferences and meetups, and I'm STILL waiting to encounter a flesh-and-blood human in real life whose employer really wavers between Java and Rust. That's like choosing between a Humvee and a submarine, their optimal problem spaces barely overlap.

>That's like choosing between a Humvee and a submarine, their optimal problem spaces barely overlap.

You'd be surprised. For a lot of stuff Rust is a good fit, aside drivers and OSes, Java is too.

There are succesful full text search engines written in Java (Lucene, and Elasticsearch on top of it), there are succesful event streaming platforms written in Java (Kafka), there are succesful distributed data processing tools written in Java (Hadoop, Spark), databases (Cassandra), and very very high performance trading engines (LMAX), very high performing servers (rapidoid, smart-servlet), and other such things besides, all categories of which have been quite big domains for C/C++ (and thus something like Rust).

Seeing a company (as opposed to a person) choose between Java and Rust would paint a very bleak picture for their future.

To me it's an indication that programmers are getting to run wild past the technical domain, after all trying to hire for a Java codebase vs a Rust codebase is enough to kill a company depending on the space due to salary expectations and availability alone.

Where I work some teams are using Java, and some are just starting to use Rust. Different problem spaces entirely though, as you said. I've seen Java used here for ETL work, Modeling & Sim work, web apps, and Android. I've seen Rust on two projects, both were real-time or near-real-time efforts.

The competition I am starting to see is between C++ and Rust, with the few teams looking at Rust loving it. I did recently help write a RFP response that noted software will be written in C++ and Rust, and the RFP was awarded to us.

I am in a different world though, as I am a contractor for the DOD. It's more like a lot of small to medium sized companies than one big company, which is why some groups can use Java and others C++ and others Rust.

I have the same problem of differentiating between hobbyists and professional experience, both on HN and when interviewing. I had someone tell me they knew Java, then found out they had done maybe 5 months of Java work and didn't know some of the most basic things.

As for myself, in terms of writing professional software for clients, I've done the following, in order of amounts worked: Java, C++, Python, Javascript, Erlang, R, Ruby, Clojure, C, Scala, and C#. I've done Rust and Elixir in personal projects, but not yet for clients. I plan to transition to a full-time Rust project in the coming years.

You can make a very good case for any organization to replace

Java => Go

C++ => Rust

The Database and System software that was created in 2000s very much was based on Java. But modern, performant Database and System software is written in Go/C++.

https://landscape.cncf.io/

I'd definitely take Kotlin over Go. That you can reuse the java codebase is a huge win, but even apart from that the language is a breath of fresh air.

> A typical well-designed class will usually be a few hundred lines of code, tops. Often less than 100 lines.

It’s not the lines that take time; it’s getting the code to the “well-designed” state, double so (if not more) for an API.

Complete maybe, but it was not fun learning or using swing in college.

Creating new classes is easy. Keeping the number down while still restricting them to a well-defined responsibility each is actually hard.

Sounds about right for Java..

I disagree with what I call Java's OOP obsession, but I have to admire the drive behind that ecosystem.

I'm disgusted by it, but admire the ability for the system to run in spite of the mess that the pattern generate.

At least with lambdas and `var`, they yielded a bit on the old ways.

How many classes do you think it should have, ballpark, given the same feature set? GUI toolkits alone can produce thousands of classes because there are thousands of concepts that make sense to model, then add on security, collections, many utilities, XML handling, multiple RPC systems and so on. It's hard to over-state how large the Java standard library is.

And it's not like other ecosystems do better. The standard complaint about JS is that you try to do something basic in that ecosystem and discover you have 10,000 modules in node_modules. Not so different, really, except that the Java stuff comes from a single team with a relatively coherent design philosophy.

If it is necessary to have that many classes, then there should be so many classes.

but in Java everything is a class, main function? in a class. a library of static functions? in a class.

Sure, classes act as namespaces in that case. What pain point does it cause?

With an alternative design you'd need to have some other code container concept, but it'd be almost exactly the same as a class file. If the JVM also had a separate notion of a non-class file, just hold to hold static methods, then it'd boil down to duplicating the format. Most languages decide to make the source file the first-class container concept, or in native languages, the DLL/.so, but this isn't obviously better and comes with its own downsides. Orienting the VM around classes has a bunch of upsides that contribute to Java being successful.

The real complaint here is more about the syntax boilerplate involved in writing top level functions in Java that map to classes with static methods. Kotlin shows there's no deep reason why the Java language has to be written this way, it's just notation. They picked it to avoid complicating the language with special cases, but I can easily agree that smarter syntax is more important than the Java guys have historically believed. Kotlin is proving this at the moment.

Sounds like a typical enterprise Java hello world type application.

Does the AbstractFactoryFactoryInterface and AbstractFactoryFactoryImpl count as two different classes...?

Kidding aside, I always found Java as a core language (and the basic standard library for it) to be mostly fine, but the weird architecture astronaut cult that hovered around it and infected many of the commonly used libraries to be a real problem.

Maybe things are different now for the language, I haven't touched it in many years at this point.

Yeah it was never the language or the core libs which were the problem, it was mostly some of the frameworks which had the FactoryFactory problem

The 90’s were a weird time.

Reply on news.ycombinator.com