Hacker News Reader

Comment by mumblemumble | Hacker News Reader

I also rewrote a Python service in Java in an attempt to control for that. The results came out similarly in terms of development & maintenance effort. Unfortunately it wasn't a thing where a performance comparison made sense, though, so I didn't really do one.

My sense was that the big benefit was actually down to the libraries and syntactic sugar. Dataclasses, comprehensions, and generator functions all have a big impact, but so do things like Python just generally having more ergonomic libraries for talking to databases, producting/consuming REST APIs, and reading/writing data files.

View on HN

You mentioned NumPy. NumPy is great, and there is basically no Java equivalent. So if you are doing the kind of work which NumPy can help with, it's going to be very hard work to beat it with Java, either in development speed or execution speed.

To put it another way, perhaps what you tested here was having a great array library vs not having a great array library! It would be interesting to test Python vs Java on a more generic task, where there isn't a huge advantage from a particular library or set of libraries.

It would also be great if someone would write a NumPy-style library for Java. My team would use that a lot!

There is also no Django for Java, no Fast API for Java, no Typer for Java, etc.

Why ? Because it's easier to write great frameworks in Python.

It compounds.

Equally, there's no Hibernate for Python, no Spring for Python. And FastAPI looks basically like JAX-RS to me.

I don't think the lack of any of these things is because they're impossible, or even particularly hard. It's because the community did or did not have the need and energy to build them.

Remember that Java had Java EE forced on it quite early. That defined web development for a long time. Eventually Spring overthrew it, and became the new tyrant. Neither of those are quite like Django, or Rails, but they occupied the space that would have had to have been empty for a Django or Rails to emerge. I think this is rather unfortunate; it would be really useful to have a vibrant Django- or Rails-like framework in Java.

There's no Typer because there isn't much of a culture of building command-line tools in Java. There are some good command-line parsing libraries, but nothing with all the bells and whistles and extensions that Typer has, as far as i know.

> Equally, there's no Hibernate for Python, no Spring for Python. And FastAPI looks basically like JAX-RS to me.

Of course there is. In fact, SQLA is easier to use than Hibernate, and the ecosystem around is as rich. As for Spring, crossbar fits the bill.

> I don't think the lack of any of these things is because they're impossible, or even particularly hard. It's because the community did or did not have the need and energy to build them.

I've never say they are impossible. I've said they require less energy to build them in python :)

No one who writes Python has ever said to themselves, "I wish I had Spring." It's not necessary, and it wouldn't even be beneficial. The kind of dynamism that Spring brings to Java, Python already has.

Also Hibernate is terrible and should be erased from the Earth.

Numpy was not a factor in the Python->Java PoC; it was a service that did no number crunching whatsoever. There, the specific library advantages were the psycopg, flask, requests, json, and csv packages. All of the (mainstream) Java equivalents are just kind of verbose and fiddly to work with compared to those.

I don't think this is entirely down to the language itself. A lot of it is cultural. The Java community tends to favor a more "enterprisey" style of programming and API design that, at least to my tastes, tends to be rather overwrought. That could change, in principle. I'm just not optimistic about it happening any time soon.

There is a lot of enterprisey crap, but there are also many decent libraries. In particular, i am pretty happy with the Java options for the things you mention - the PostgreSQL JDBC driver, JDBC itself, and HikariCP for pooling, the JDK HttpServer (no templating though, don't know if you need that here), the JDK HttpClient, Jakarta JSON with Joy as an implementation, and SimpleFlatMapper for CSV. None of them are perfect, but i am pretty happy churning out generic business service type things with them.

I wish there was some way i could take a sabbatical from my job and come and try to rewrite your service in what i consider effective modern Java. I am pretty optimistic it would be competitive with Python in effort and maintainability, but i have no way to prove it!

> You mentioned NumPy. NumPy is great, and there is basically no Java equivalent.

Things like this are the greatest disappointment to me after fifty years of writing software. It should not be necessary that Java equivalent exists. It really ought to be possible to connect to libraries from any language by now.

After fifty years of writing software, i would have thought you would understand why that wasn't possible.

Perhaps you could enlighten me as to why it isn't possible? I do understand that it would be difficult.

What do you mean? JBlas exists. Colt exists. There's probably others but I'm not super up to date on Java things.

Numpy is just wrappers for BLAS and LAPACK.

> Numpy is just wrappers for BLAS and LAPACK.

Certainly not. I encourage you to have a look at the API of BLAS/LAPACK to perform basic operationa. And that just scratches the surface.

https://numpy.org/doc/stable/user/building.html

It is. Maybe it's a very fancy wrapper.

I would argue that numpy is a fancy wrapper for BLAS in the same way that a Spitfire is a fancy wrapper for a Rolls-Royce Merlin 61.

WinRT is an interesting thing on that front, though I am not aware of a non-Windows equivalent, and so it's never really going to see much open source adoption, let alone support on other platforms.

Back in the '90s, when we still remembered how to dream, we had CORBA.

CORBA got a lot of bad press, but towards the end, it was actually pretty decent. Certainly the best way to do the thing it was trying to do!

I suspect there's some algorithmic choice hidden in a library in this comparison, where the Python library has the right choice for the job and the Java library has the wrong one.

Are you as familiar with Java as you are Python?

I'm much more familiar with Java. It's mostly what I get paid to write. Python's relegated to times when I can get away with it, which are relatively uncommon.

Reply on news.ycombinator.com