At a previous job I did manage to put a chip in that when I demonstrated replacing one of our Java services with a Python implementation. It was a fraction of the code, and achieved much better latency and throughput. Obviously not every Python program is going to do that. But my point isn't that Python is better, it's that these kinds of things are never so cut-and-dried. Many non-trivial Python programs are just thin shells around a large core of very well-optimized and battle-tested C/C++/Rust code. And Java, for its part, can also accumulate a lot of dynamic language-style performance losses to pointer chasing and run-time type lookups (and GC churn) if you're not careful about how you use generics. As always, the devil's in the details. It's also less able to pull the "actually I'm a C++" trick because using a compacting garbage collector makes it difficult to interop with native code without paying a hefty marshaling tax.
Still I believe Java is a better application language. Python is a better scripting language (replacement for Bash). Small apps tend to be easier on Python, but large apps are way easier on Java, both for syntax (types) and ecosystem (libs).
Seen plenty of coding horrors in both ecosystems...
class IWantToBeABean:
def init(self, arg1: int, arg2: str, arg4: str) -> None:
self._field1: int = arg1
self._field2: str = arg2
self._field3: str = arg3
def get_field1(self) -> int:
return self._field1
def set_field1(self, value: int) -> None:
self._field1 = value
def get_field2(self) -> str:
return self._field2
def set_field2(self, value: str) -> None:
self._field2 = value
def get_field3(self) -> str:
return self._field3
def set_field3(self, value: str) -> None:
self._field3 = value
@dataclass
class IDontWantToBeABean:
field1: int
field2: str
field3: str
The reason why large Python codebases are particularly scary isn't necessarily the size itself. It's that for a codebase to even get that large in the first place it's very likely to have been around so long that the probability of it having had at least one major contributor who likes to do cute tricks like this is close to 1. And I'd take overly verbose like the Java example above over that kind of thing any day.
get_field1(self) -> int:
"""
Gets Field1.
@rtype: int
@return: the field1
"""
self._field1
Seriously though, in Java you don't need get*() either. Typically you either:
1. use `record` types (since Java14, 2020), or
2. use Lombok that auto-generates them [1], or
3. use Kotlin `data class`, or
4. just raw field access. I don't buy the encapsulation thing if my code is not a library for wide internet to use.
I wouldn't call it a new language, for me it's just a syntactic sugar over Java, but for any problem you would google "how to do X in Java", not "how to do X in Kotlin".
But there you can do way simpler syntax, like:
0..100 meters with -45..45 deg within 3 seconds
(0..100) is a built-in IntRange type, that you can extend:
data class MyDistanceRange(val meters: ClosedRange<Double>)
val IntRange.meters: MyDistanceRange
get() = MyDistanceRange(first.toDouble()..last.toDouble())
The worst thing about Java is the average quality of Java programmer.The same could probably be said about Python. However I think that there are fewer Python programmers trying to write AbstractFactoryFactory than in Java. Java has a terrible culture of overly verbose, deep inheritance trees that make debugging and development worse, with worse performance.
Java programmers may not blog as much, and Java doesn't show up on Hacker News as much, but not being Extremely Online does not mean that it isn't extremely widely used by real people whose experiences are just as valid.
I recall things like updating packages/code on the fly, recompiling fast paths on the fly. Maybe that's not necessary in a borg/kubernetes world where you can just restart things and have your load balancer infra take care, or just run slower code because compute isn't that expensive once you accelerate your CPU-heavy libraries, but cool anyways.
The comment I was replying to seems to believe Java is a tiny backwater, which is anything but true.
Considering that as recently as 4 years ago I was working on a project where we still had a hard requirement to support running in Java 7, and this kind of thing was not considered unusual, I can't really disagree too strongly with that. Yes, that was still inside of Java 7's extended support period, so there was really nothing unusual or surprising about this, from a Java developer perspective. But that's kind of the point.
It's also not really a bad thing, considering what kinds of things run on Java. Mainframe developers have a similar thing going on, for a similar and similarly good reason.
Edit more succinct
No, you could not. You could say it about maybe four others: PHP, C, C++, and C#.
No other languages have anywhere near the userbase size while being fairly quiet when it comes to online tech discussion.
I agree there are crusty old Java devs (as well as crusty old C, C++, PHP, etc. devs). In a decade or two, there will be crusty old TypeScript devs. It's just the nature of technology lifecycles and career paths. Some people get relatively tired of learning when they get older and just want to capitalize on what they already know for their remaining earning years.
Most of those rarely make to the top of HN, and other generalized forums. If anything, Java and Python are together at the popular kids table and we forget about the silent heros keeping the ship afloat.
The Log4shell incident is the perfect demonstrator of what kind of people are in Java world.
To what? Java is still a very efficient, productive language. Updating a legacy codebase to use newer Java features would probably be good, but migrating to another language is unlikely to significantly move the needle in terms of runtime performance or developer velocity.
When you work with a codebase that doesn't need compilation, the development velocity is quite fast. You don't need to compile, you can prototype features on the fly, you can even write real time updates while the web server is running.
And standard compilation in Java is done in a VERY inefficient manner with groovy - you have groovy that gets compiled to bytecode, which then gets JIT compiled to native, which then actually runs the compilation of the source code to bytecode, and then you have a first startup latency as it gets JIT compiled to native.
All you really need to write any modern app is Python + C. Anything that needs to go fast, just encapsulate in a small C program, and launch that from Python.
In fact, a lot of the most interesting plt and compiler r&d going into real world applications is on the jvm (project loom, graal etc), and the features of modern Java (pattern matching, records, etc) make it a great choice for lots of projects that aren’t legacy enterprise apps.
I don’t think Java makes anyone unambitious, I think it’s that Java is taught in schools and unambitious people don’t feel the need to learn anything else, and they get jobs at unambitious corporations. It selection-biases towards unambitious people who don’t want to learn more than they have to.
Compare this to something like Clojure or Haskell or something, which isn’t routinely taught at schools and is not very employable. People who learn these languages generally seek out these things because they’re interested in it. This selection-biases towards intellectually ambitious people.
As a result, Java people can be insufferable for people like me.
The people who make Java have actually made the platform and language pretty ok in the last two decades, but I had to fight at a previous job to use NIO, which I think was introduced in Java 4, but none of my coworkers had really heard of it or used it because the regular Java blocking IO has been “good enough”.
I think one comment I saw here on HN that Java is better if written in Pythonic way. I agree completely with that stance.
but yeah within Java you've 'merchants of complexity' people who wanna do things in the most abstract way rather than the simple way.
btw Java can be as simple as Go.
And the slides are available here: [url-redacted]
I'm afraid that my humor isn't really reflected in the slides, but imagine everything here is said kind of snarkily.
Java can be mostly as nice as Go, the BlockingQueues and Virtual Threads can get you pretty far, though they're not quite as nice as Go channels because there's no real way to select across multiple BlockingQueues like you can with Go channels.
Overall though, I think Java 21 is actually not too bad. Shockingly, I even sometimes have fun writing it.
Should be fixed now. Sorry about that.
Given fact that Lombok is still pretty much widely used, with its under the hood functionality of essentially hacking the AST, or the fact that annotation processors write out Java code to files, or the fact that you could be using a standard library like Log4j and have a massive vulnerability on your system because someone decided that it would be a good idea if log statements could execute code and nobody said anything otherwise, or the fact that Kotlin and Groovy were literally made to address inefficiencies in Java, amongst other things....
Yeah not really sure how you came to that conclusion.
Kotlin and Groovy did come and address problems with Java, you should use use them if your employer allows it. I'm just saying that Java 21 is actually kind of fun to write.
Yes, some of the libraries have been unsafe, but that's one example of the 30 years of Java.
I just feel like Java has improved in the last twenty years. It's the engineers that haven't.
Other than being ageist, it’s wrong; or misattributed to Java. I work with Python every day, and what’s missing is static typing and IDEs that make use of it to greatly reduce the amount of code and context I have to store in my head. Python (a dynamically typed language obviously) is exhausting to maintain. But easy to write. Java/C#/whatever statically typed language with great IDE is easy to write and maintain by comparison.
Of course there are IDE for Python and dynamically typed languages, but everyone I’ve tried has fallen short compared to the best Java/c# IDEs.
Static vs dynamic used to be a huge flame war on the internet, but over the past few years I’ve encountered people who’ve never heard of it. This is it.