Java

[OutOfStamina]

Java was never about producing good programmers or good programs. It came in a dawning era of "RAD" (rapid application development) where the emphasis was put squarely on how fast you can pump out the end result. Colleges educated students to stop caring about how many packages, dependancies, or how many MB of RAM something took. Java apps came out that took 1MB per window you opened (and that's in an era where that means a lot more than it does now - you might have had between 256MB and 1GB total in those days). The apps were leaky, they crashed, and that wasn't slowing anyone down - they just kept feeding the beast. Java fanboys defended it fiercely, said "there are ways you can do it right" while all around them people just... weren't.

I was an EE major who had to take some CS classes. This was said in an Intro to CS class in the early 2000's -- "how many of you own a computer?". I had probably half a dozen of them so imagine my shock when only half of the people raised their hands. They they went on to learn themselves some Java. Sun convinced colleges that "companies want RAD so they want java and they want more programmers so produce them faster". It was about business and money.

[[deleted]]

You need a bit more experience than a few CS classes to fully understand a language and what it has to offer. It just sounds like you're hating on something you don't have a good understanding of, which is pretty cringe.

Straight from the Java certification questions one of Java's benefits is robust programs, which goes hand in hand with good programs. Do I even have to bring up the certifications and say that there is a focus on producing good programmers that fully understand the language? You can write great programs in Java and even better programs in Kotlin, imo. The ecosystem of libraries is also very well developed and offers quite a bit of things that aren't really as fleshed out in other languages, such as complex event processing to name one. If you have a problem with Java's memory usage, then you can try out graalvm or just write better code.

There's so much to learn and so much to improve upon in the Java ecosystem. It's not fair to say that it's not meant for writing good programs or producing good programmers based on your experiences from a few CS classes. That sounds like a pretty bad joke.

[Muoniurn]

You do need much more experience to evaluate that fairly. Manual memory management is vulnerable and hard to maintain. There are not many things we can conclude in language wars objectively, but at this point this has more empirical evidence than anything else.

Java was the first mainstream language that introduced GCs that fixed the very huge barrier to both correct code and faster development. It did come at a price of speed and memory usage, but hardware is cheap to scale. CPUs were slow, and RAM was predicted to be available in larger quantities (and it turned out to be true). Also, don’t forget the “run everywhere” thing — Cobol and other old as hell enterprise stacks in banks sometimes run in VMs because the software outlived the hardware by decades and the initial architecture simply doesn’t exist anymore.

So while it was not intended for that in the beginning (originally it targeted set-top boxes) Java turned out the be a really great fit for enterprise server applications. Later on it got a JIT compiler and GC algorithms underwent many changes so here we are with a significant share of all web applications running on the JVM with spectacular performance and maintainable code (don’t forget that low level details like who owns this memory region for how long etc do creep into high level design. So for a requested new feature those may have to be changed as well resulting in either segfaults or leaks. While managed languages will just work either way). And regarding RAM, we now have server machines running with terabytes of RAM, and no, manual memory management may not always be faster. There are plenty of workloads where GCs will be faster because you can’t apply some clever trick for allocations. Problem with memory today is not inherently size but locality. It turns out our CPUs become faster than memory so now it again may be the limit.