Apparently the author used to be a Java person. I have this feeling - or prejudice - that people still in the Java World are a bit out of tune with the tech industry, working on huge legacy projects on big retail or US banking. These people tend to be conservative and resistant to change, so maybe that's where these types of articles are coming from.
Java shops are certainly where I've witnessed the most disdain for Python. IME the strongest feelings tend to come from people who didn't actually have any significant experience with Python, and perhaps don't even have much practical experience with any language that isn't Java. So they tended to consider it to be objectively inferior purely because it's interpreted and dynamically typed.
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.
I have way more experience with Python than Java. In at least 4 companies (including Google that I wouldn't call a javashop) we used mainly Python.
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).
Mostly agreed, though I would add that I'm generally happier with Python as a default for reasonably sized services that don't have a lot of (non-numpy-friendly) compute load and therefore don't have a pressing need for multithreading. Which is a lot of what happens now that we're all trapped in the cloud. Like you say, small apps tend to be easier in Python.
That is general take as well. A lot of small apps/simulators are in python. Ops scripts tend to be python. Java for the core/data. Refactoring/tooling is easier in Java when you are dealing with a 100k codebase imo. Typescript always.
Seen plenty of coding horrors in both ecosystems...
Algorithms are a lot easier to understand when they are written in Python.
I'm actually right now documenting medium size Java codebase by writing pseudocode, which looks like Python.
Just by doing that, I've already discovered multiple bugs, which I didn't catch by looking at the Java code.
That might be the big thing that I think gets glossed over in a lot of these discussions. I agree that I wouldn't want to maintain 100kloc of Python. But, I don't really view that as a realistic hypothetical for a business application. Idiomatic Python tends to require a fraction as much code as idiomatic Java to accomplish the same task. The only time it even gets close is when you have code written by people who go out of their way to make things look like old-school enterprisey Java. So it ends up accumulating a bunch of stuff like
@dataclass
class IDontWantToBeABean:
field1: int
field2: str
field3: str
The worse case for Python is when you get people doing the oldschool Python thing of acting like dynamic and duck typing means it's OK to be a type anarchist. Scikit-learn's a good one to put on blast here, with the way that the type and structure of various functions' return values, or even the type and structure of data they can handle, can vary quite a bit depending on the function's arguments. And often in ways that are not clearly documented. Sometimes the rules even change without fanfare on minor version upgrades.
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.
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
Because "0..100 meters ..." is equivalent to "(0..100).meters(...)"
(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())
IMO Kotlin has some features that take it way beyond just being syntactic sugar over Java. Like, I know you could probably use some eye-watering gang-of-four pattern to achieve the same effect as extension methods. But it's going to be such a PITA to maintain that calling the Kotlin feature syntactic sugar for the same thing is about as useful as saying that function definitions are just syntactic sugar over assembly language calling conventions.
I've played with it for a bit but it doesn't excite me enough to spend time learning it properly. I also don't care about Python beyond using it for learning algorithms and maybe some smaller Pyside UIs.
However, together with Mojo it might become more interesting again.
> 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.
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.
I certainly think so but wasn’t sure if it was just my unfamiliarity or lack of advanced programming knowledge but I attempted what seemed like a very simple patch to a Java project (guacamole) and it was insane how I ended up having to add the new function to like a base and abstract class and interface etc. it was crazy. All the same boilerplate too.
I have a related feeling or prejudice that people not in the Java World view their corner as "the tech industry" without realizing that they are living in a village compared to the giant metropolis that is the Java World.
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.
you could say the same thing about a dozen other languages, but there is definitely a stereotypical cranky java dev that is frustrated writing corporate crud apps that should in theory be blazingly fast, but never quite are for reasons. They revel in the verbosity, and look down on anyone they feel is taking the easy path. If you've never met one you're lucky, but they've been at every company I ever worked for.
> you could say the same thing about a dozen other languages
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.
I think I made a conscious effort in my 30s not to become a crusty old Python dev. But I predict that in another decade or two, I (now in my 40s) will be a crusty old Rust dev.
ok I may have exaggerated, but there are quite a bit of people silently writing and maintaining mission critical code in Fortran, Lisp, Cobal, Perl, Pascal, R, Assembly, the different BASICs, Lua, TCL, Erlang, and the list goes on. Plus those are just the ones off the top of my head where I have personally met people doing it in the last decade. I am always shocked by how much
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.
I read it less as "Java is tiny" and more as "Java developers can be peculiarly insular and conservative, by the standards of other communities."
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.
I'm not sure if they refer to how large the language's reach is, but more about how advanced Java is once you stop looking at syntax bloat. The JVM can do stuff that's not easy to do in other environments.
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.
This is absolutely correct as someone who has worked in a few Java shops. Although, the same thing is Java's failing, as it is well nigh impossible for people external to the Java ecosystem to learn what's inside it without having work-related exposure.
You may know all this and are just singling out the Hacker News crowd. But I read your comment and thought "surely he doesn’t think Java is much bigger than Python?" I’m not even sort of sure Python is smaller.
The reason that people still code in Java (or derivative) is because legacy code that they are working on is in Java, and nobody has either the skill or time to go through and translate it. Which means that the jobs where its used are basically just big enterprise, low tech software that just been around for a while.
The Log4shell incident is the perfect demonstrator of what kind of people are in Java world.
> nobody has either the skill or time to go through and translate it.
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.
Most of the use cases for java are in places where network latency dominates. If Python is fast enough for Uber and Youtube, its fast enough for your service.
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.
I feel like the opposite is also true. People view Java as enterprise Java from 2008; a clunky outdated language for bad, verbose spaghetti code.
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 gave a talk recently at a conference about how modern Java doesn’t suck very much, and that the worst part of Java is Java developers, who seem to be completely intellectually unambitious.
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”.
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.
That gets to my point though. For example, Lombok isn't really necessary for a lot of stuff now, because Records give you a lot of what you would use with Lombok.
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.
I don't think that the talk has been released on public YouTube yet (and they made it clear to not share the unlisted links publicly), but here is the posting: [url-redacted]
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.
> I have this feeling - or prejudice - that people still in the Java World are a bit out of tune with the tech industry
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.