4 ms·
Yes, but that's my point. If I don't need performance, Python is ok. If I do, I won't go Java, I will choose something that is built for performance. Python i
by BiteCode_dev 6y ago
Yes, but that's my point.
If I don't need performance, Python is ok.
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.
I won't use go for the ecosystem, but it's unique characteristics: easy concurrency, dead simple binary production. Java can't beat that. IF I need an huge ecosystem, I'll go Python.
For the need for Java, I would need this very specific sweet spot where I need just enough speed, and just a rich ecosystem enough to justify it, and nothing that is a killer feature in alternatives. And a situation where compromise over this is not possible.
It never happens to me, that's all.
- _pmf_ 6y ago> The last 1%, jumping to java is not a big difference That's where you're wrong, kiddo.
- BiteCode_dev 6y agoOh, 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.
- bjourne 6y agoBut you are not going to get higher performance in Rust/Go.
- BiteCode_dev 6y agoRust 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.
- jvolkman 6y agoI wouldn't say Google is really "moving" to Go. It's an option, but plenty of projects new and old continue to choose Java.
- kaba0 6y agoWell, 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.
- adrianN 6y agoJava 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.
- BiteCode_dev 6y agoBut 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.
- pjmlp 6y agoWhere is Rust AWT? Not to mention Swing, JavaFX, or even an whole mobile ecosystem.
- BiteCode_dev 6y agoWell, 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.
- pjmlp 6y agoSo 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.
- BiteCode_dev 6y agoIt'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.
- chriswarbo 6y ago> 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).
- BiteCode_dev 6y agoAgreed, it's just a general overview, I skipped a lot of nuances for the purpose of conveying my main message.
- wing-_-nuts 6y agoJava 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.