> Python is good enough for 99% of my performances need. The last 1%, jumping to java is not a big difference, I'll use rust or go.

Whilst I roughly agree, that's still a bit too simplistic.

In particular, we might prefer something like Rust to write a performance-critical algorithm, but that forces us to make a decision:

- Do we stick with Rust for everything else (networking, data plumbing, etc.)? This forces us to confront the ecosystem problem.

- Do we wrap our algorithm as a library for other languages (like Python)? This forces us to confront interoperability (ABIs, FFIs, cross-language dependency management, etc.).

There's lots of room in between these extremes for other pareto-optima, like Java.

Also, we often need to consider latency and throughput separately, rather than just "performance". Java is a pretty stark example, since it's pretty slow to start but reasonably fast when left running (compared to native binaries like Rust, which are low latency and high throughput, or scripting languages like Python which are high latency and low throughput).

Agreed, it's just a general overview, I skipped a lot of nuances for the purpose of conveying my main message.

Java is orders of magnitude faster than Python for code that doesn't spend all of its time waiting for IO. Java perf and Go perf are about the same.

But not Rust.

And Go is better if you do I/O.

That's my points. Compromises.

I'm not saying "Java is bad". I'm saying, "I have no use case where I, personally, would use Java over something else."

I do know other people have use cases for it.

I just don't, because those compromises don't make sense for me.

Where is Rust AWT? Not to mention Swing, JavaFX, or even an whole mobile ecosystem.

To be fair, even people deep in the Java ecosystem don't like its desktop application/GUI support.

Its only saving grace is that all other cross-platform GUI systems also suck, and if you're doing everything else in Java it might be the path of least resistance.

Only the people that are too lazy to actually learn how to do it properly,

"Filthy Rich Clients" by the nowadays Android UI architects

http://filthyrichclients.org/

"Swing Hacks: Tips and Tools for Killer GUIs" by Joshua Marinacci, well know in the UI research community

https://www.amazon.de/dp/0596009070

And then commercial libraries like

http://www.jgoodies.com/

For ordinary desktop apps, javafx is quite good. It’s a hidden gem in the ecosystem.

(Though I haven’t tried its mobile “backend”)

Well, if we create a desktop app, the Python + C bindings will be a better choice for my own project. Easier to dev, equivalent perfs, equivalent libs (and the QT Rad is excellent).

Java does have android right now, although it has to share with ReactNative, Xamarin and flutter. Again, for different compromises.

So apparently Rust isn't that better than.

Java also has the IDE ecosystem between Netbeans, Eclipse and all JetBrains offerings, with exception of Apple and Microsoft offerings.

It's not a matter of better. The original comment is all about what compromises work for me, and why I don't have a use case for Java.

You are trying to move the debate toward the quality of java, which is was never my point.

Not at all, I though your point was how Rust and Go are a much better option.

> If I do, I won't go Java, I will choose something that is built for performance. Python is good enough for 99% of my performances need. The last 1%, jumping to java is not a big difference, I'll use rust or go.

So given that, I am curious where are those GUI alternatives with the required perfomance in Go and Rust.

So you are in the very niche use case where:

- you need a GUI

- you need perf beyond what Python is capable and you identified it clearly in advance

- you can't use numpy / multiprocessing / cython, pypy or they won't give you the perf you need

- you can't find a main hotpath you can optimize with a 5 lines c or rust extension and write 99.99% of your app in python. Or you don't want to bother.

If you ever find yourself in this very use case, then yes, use Java.

But I never found myself in this very precise use case.

> multiprocessing

Please.... That's literally the worst option for python on this planet. For all "just do multiprocessing" the tooling is horrible garbage. Then we get to Twisted and Gunicorn the Spring Framework of Python world.

No, he is in need of writing production quality software together with his medium to big sized dev team and he doesn't want to introduce maintenance burden into his project 10 years from now. Software will get improved during it's lifetime and not overwritten from scratch every 2 years.

With external contractors arriving to work on a foreign code base just for a couple of Jira tickets as per department budget.

> Java is orders of magnitude faster than Python for code that doesn't spend all of its time waiting for IO.

It's hard to separate the absolute performance of Java the language from Java the culture where inefficient patterns or attempts to implement dynamic behaviors in some framework code defeat the JIT (not to mention the benefits of type-checking). If you have a team which cares, it should be faster but the average business app I see does not have that team and will, if lucky, perform within the same order of magnitude as Python.

Having got back into Java a bit recently I was surprised how fast it was (coming from python/Perl and php).

Speed doesn’t matter always, but when it does it Java feels snappy. Our programs our command line based so our framework use is limited. Also the built in data structures are nice. I still find getting Java’s set up painful, which is a huge impediment for us using it more.

Well, that same team would have trouble even writing complex python apps as well, without types

(yeah I know it has type hints now)

Even IO heavy code, it is much easier to write multithreaded async code for the jvm than it is for python

If it's just about I/O, then no, threads in Python are super easy:

    import random
    import time
    from concurrent.futures import ThreadPoolExecutor, as_completed


    def hello(seconds):
        print(f"Starting hello in {seconds}s")
        time.sleep(seconds)
        print(f"End of hello in {seconds}s")
        return seconds


    # At the end of this blocks, it automatically join() and clean
    with ThreadPoolExecutor(max_workers=2) as executor: # 2 tasks in parallel max

        # this send jobs to threads via safe queues
        a = executor.submit(hello, random.randint(0, 5))
        b = executor.submit(hello, random.randint(0, 5))

        # this collect results from queues in order of completion
        # sync is automatic
        for future in as_completed((a, b)):  
            print(future.result())

And if about network I/O only, you can get even more perfs using asyncio.

Threads in Python are only inferior to Java threads when it's about using several CPU.

Are python threads still limited to one core? That’s always been a nasty limitation.

I do enjoy in python that it is quite easy to utilise multiple processes in a code-light fashion, but some things are more natural as threads.

Java and Go are roughly equal in performance (seriously, look up the benchmarks). If you're using go for it's concurrency primitives, kotlin has equivalents.

I got into Go for a while, but if I'm honest, it's a kludgey language. Half the reason it has taken off as it has is simply down to the fact that it's backed by google.

> The last 1%, jumping to java is not a big difference

That's where you're wrong, kiddo.

Oh, I'm afraid I can't claim that sobriquet anymore unfortunately.

But that's not the point. The point is that, for the 99%, staying on a slower language is ok. For the last 1%, I'll skip Java and go to Rust/Go. If I have to do a rewrite for perf sake, I'm not going to go half way.

But you are not going to get higher performance in Rust/Go.

Rust can literally contain inline asm so yes, you will. But even without that, the startup time is always going to be faster.

And for IO, you will get faster perf in Go more easily. Sure, you can finely tune your Java code to get there, but it's a lot harder.

It in both cases it will eat up way more memory.

There is a reason Google, that did use heavily Java internally, is now moving to Go, a language they custom designed for concurrency.

Well, project loom will make the JVM arguably a better platform for concurrency.

Basically every language is more expressive there (even Java), GC is much much better - in benchmarks it is not as obvious only because Go avoids creating garbage most of the time, but it can’t always be avoided; and the platform is incomparably richer on the JVM side.

I wouldn't say Google is really "moving" to Go. It's an option, but plenty of projects new and old continue to choose Java.