←back to thread

177 points chhum | 4 comments | | HN request time: 0.004s | source
Show context
exabrial ◴[] No.44006194[source]
Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby.

Java syntax isn't perfect, but it is consistent, and predictable. And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), it's just pressing control-space all day and you're fine.

Java memory management seems weird from a Unix Philosophy POV, till you understand whats happening. Again, not perfect, but a good tradeoff.

What do you get for all of these tradeoffs? Speed, memory safety. But with that you still still have dynamic invocation capabilities (making things like interception possible) and hotswap/live redefinition (things that C/CPP cannot do).

Perfect? No, but very practical for the real world use case.

replies(14): >>44006269 #>>44006358 #>>44006411 #>>44006567 #>>44006570 #>>44006865 #>>44007100 #>>44007464 #>>44007662 #>>44007666 #>>44009121 #>>44009861 #>>44011219 #>>44011642 #
1. tootie ◴[] No.44006865[source]
The language has/had some rough edges that have been improved over the years, but the developer experience of using a strongly-typed, object-oriented language within a sturdy IDE like Idea is just second to none. The debugging process is so very straightforward. Java became synonymous with enterprisey bloated systems for good reason, but there is no pile of mud Java system that can't be stepped through cleanly with a debugger.

I'd also throw in what was possibly their greatest idea that sped adoption and that's javadoc. I'm not sure it was a 100% original idea, but having inline docs baked into the compiler and generating HTML documentation automatically was a real godsend for building libraries and making them usable very quickly. Strong typing also lined up nicely with making the documents hyper-linkable.

Java was really made to solve problems for large engineering teams moreso than a single developer at a keyboard.

replies(2): >>44009419 #>>44012231 #
2. Terr_ ◴[] No.44009419[source]
I find these discussions have an interior split between the folks who are more concerned with getting the feature out now versus the folks who have had to keep a thousand ancient features running.
replies(1): >>44011776 #
3. tootie ◴[] No.44011776[source]
True, but it's also true that code spends 99% of it's lifetime in maintenance. That's the reason I am never impressed by tools that make it fast and easy to bootstrap.
4. topspin ◴[] No.44012231[source]
> javadoc

Indeed. Many languages have something similar to Javadoc, yet somehow I haven't encountered anything quite as good as Javadoc, and I can't explain why or exactly how it's better. I admit I haven't tried that hard either. But I suspect it's down to the nature of the language and how, with well designed libraries at least (and not all are, certainly,) there is a nice decomposition of modules, packages, classes/interfaces and methods that leads to everything somehow having a correct place, and the Javadoc just follows. The strong typing is another contributor, where 90% of the time you can just look and the signature and imply what is intended. Finally, the old-fashioned frames based HTML typically used with Javadoc is a great benefit.

Also, I've found I experience less reluctance to author Javadoc for some reason. Again, part of this is due to strong types, and much of the legwork being correctly generated in nearly every case.

Lombok, when used with moderation, is wonderful. Mockito is magic, of a good kind. Maven still gets it done for me; I've yet to care about any problems Gradle purports to solve, and I think that's down to not creating the problems that Gradle is designed to paper over in the first place.

Today, if I had my choice of one thing I'd like to see in Java that doesn't presently exist it's Python's "yield". Yes, there are several ways to achieve this in Java. I want the totally frictionless generators of Python in Java.