Let's compare and contrast these programming languages in terms of features, best use cases for each, and perhaps which is "better" than the other depending on context.
Let's compare and contrast these programming languages in terms of features, best use cases for each, and perhaps which is "better" than the other depending on context.
Top comments (92)
I use both languages. Let's compare the two languages:
Cross platform support:
jarfile. It is also possible to generate a binary using GraalVM and other ahead of time compilers.Concurrency and Parallelism
java.util.concurrentpackage is a great for different types of abstractions like threadpools, atomic primitives, concurrent hashmaps. Futures and CompleteableFutures provide library support for async functions (no syntactic sugar).Type safety
Python's built-ins are very expressive (list, set, dict, tuples) and most are sufficient or most simple programs. This allows you to quickly prototype your projects.
Performance
Expressiveness
Ecosystem
Both Java and Python have extensive ecosystems. You will generally find libraries doing what you need in either of these languages.
The JVM ecosystem also has other languages which avoid the short-comings of Java e.g Scala, Kotlin, Clojure. These languages are much less verbose and can also leverage the extensive Java libraries.
Summary
At the end of the day, choosing Java or Python boils down to your preferences.
Here are a few niches where one can be better than the other (just my opinion):
One clarification: usually Java performs very close to C (no 3x slowdown). In some cases (heavy allocation/deallocation) it may outperform C due to much lower overhead for such operations in Java runtime.
Thank you, Raunak!
I know that the question was Java vs. Python.
But I think that for web development, at least from my end, JavaScript is the top.
I don't know many people who still develop frontend with Java and Python.
Another point regarding Expressiveness, there are many languages that are built on top of the JVM and with a goal to reduce verboseness from the code.
What do you see from your end?
which JVM language do you use? ( if any :) )
In web development, I feel that familiarity with a framework (its strong points and pitfalls) often tops any language feature. I use Flask in Python for quick prototyping and Dropwizard in Java for production ready applications. I have heard good things about Express in Node.
Re JVM languages I am getting familiar with Kotlin. It has many good features like data classes, Sum types, pattern matching and coroutines.
In nearly any development, familiarity is king! If someone understands general principles of good software design, they can make good software in any language or framework they know well, whether that be Java, Python, C++, Haskell, or COBOL.
And one comment: yes, Java is verbose. But Java verbosity is not a bug, but feature. It allows Java code to explicitly provide context. This context significantly reduces mental overhead and navigation back and forth between usage and definition.
Minor typo: that's Clojure, not Closure.
Thanks!
Additional info: there's a version of Python (stuck at Python 2 unfortunately) which runs on the JVM: jython.org/
Yes, it is unfortunate that JPython never took off as much as JRuby did.
I really like the accuracy and neutrality of your comment. However, I would like to add two more aspects to it.
Learning curve
Java: requires more overhead to get started, has more concepts to grasp (proper OO, == vs equals, hashcodes, ...) and lower "expressivity"
Python: trivial to pick up, very intuitive, easier to learn and get something done quickly
Culture
Java: many libs tends to over-engineer stuff, perhaps because their tooling is so good. But this leads to a large slow paced ecosystem. The JDK itself has also a poor "stewardship" (you still need a signed Oracle Agreement to even suggest a bugfix to the *Open*JDK)
Python: embraces simplicity and intuitiveness as its core philosophy. Fast paced ecosystem. Contributions and evolution of Python itself is also very open and community driven.
My own opinion: I find python very pleasant to work with. It's easy, it's intuitive, it has lots of "batteries included" and my usual choice for small projects. However, for bigger projects, I still tend to Java. The typing system, the tooling and good multithreading just beats it at some point when the project grows.
New java versions can create custom small jre images within applications so the need for a user to have a jre installed is no longer needed. Also jpackager can create installers. Overall java experience to deliver a full application as a whole has gotten a lot better.
Java has such an enormous eco-system built around itself, it's hard to even compare it to any other language. It probably can do almost anything, setting aside the age-old topic of "if we can do it, should we?".
Pythons ecosystem on the other hand is rather small in comparison, but it got a nice niche in AI/Big Data it dominates handily.
To be honest, it's not the language java itself, that I love. It's what Maven and Gradle make out of it that really eases the process of developing with java. Once you get used to your build-tool of choice, it's just copy-pasting dependencies and bam, you get everything you may need, including the appropriate build plugins for your workload.
Fire up a simple build command and you get a nice deliverable artifact. How amazing is that?
While Java is heavily restricted by it's conventions, you get a lot out of it for free. Getting back to maven, for example. Add your pom.xml with the typical boilerplate stuff and you essentially get the whole build-chain for free.
Python doesn't have as many conventions, but that freedom costs you the effort of doing most things yourself.
Edit: I'll refrain from editing out my wrong statements, but absolutely recommend reading the answers to my comment that correct them!
I hear about this purported "niche" a lot, but in nearly a decade of Python coding, I've never observed it. Python has a fairly broad ecosystem when you factor in libraries (installable via pip or poetry in one line): it handles not only AI and data, but is excellent at GUI, networking, system interoperability, and just about anything you can throw at it. The only area Python really doesn't excel at is true multiprocessing, thanks to the Global Interpreter Lock (GIL), but there's work being done to resolve that too.
Uhm, this is most certainly not true. Python has a greater emphasis on convention and The One Obvious Way (as we put it) than most other languages, Java included. We have no fear of boilerplate — cargo cult programming, as Guido calls it — but we do avoid mindless boilerplate when we can (except, perhaps, in
setup.py). Testing, packaging, deployment, all of these work well once you know where a couple of pieces fit, to the same degree as Java and Maven.Interesting, I never really observed Python like that, though judging by your comments, it's absolutely certain you are far more knowledgeable with Python than I am.
With eco-system I meant more the tooling around the languages, like CI/CD, Security Scanning, Lifecycle-Management and the likes.
I would assume a big portion of that is probably not even necessary for Python. What would your take be on that?
So thank you for your input and correcting my wrong statements.
It seems I have to do more Research next time
CI/CD: There are a number of robust testing frameworks, including PyTest, Nose, and the newer Ward. Python also integrates beautifully into most CI/CD frameworks, especially given the relative ease of deploying a package. (On that note, many Python projects even automate publishing their package to the Python Package Index using GitHub Actions or the like.)
Security Scanning: Bandit is one prominent example, and I know there are others.
I don't know about Lifecycle-Management, as I haven't used it, but a casual glance through the Python Package Index, or PyPI, it looks like there are plenty of options.
It's a common myth that Python isn't suitable for large projects. In fact, there are a number of very large applications and libraries built entirely in Python. It has its flaws, but Python is often excellent for software architecture and deployment because it "just works" in most situations, and aims to be intuitive while staying out of your way.
Thank you for your take, you never stop learning!
I guess I'll spend this weekend on Python and taking a look at the tools you mentioned.
The last time I had any python on my screen was when I wrote custom ansible filters and a few shallow dips into Django, which confused the hell out of me.
It's about time for a refresher :)
You may appreciate this, then:
Introducing "Dead Simple Python"
Jason C. McDonald ・ Jan 13 '19 ・ 3 min read
It turned out that many java limitations are very useful in long run. For example, quite strict linking between class and it's file name and location allows to keep at least some level of order in project codebase. Once this restriction is removed (Kotlin) maintaining order became a sensible effort, since devs tend to make shortcuts.
I absolutely agree.
Though I am more focused on the conventions part that comes with Java, since that is probably the first thing a Newcomer encounters.
Most frameworks, especially in the EE Version are convention over configuration. Conventions are just that, they can be ignored.
Which you absolutely shouldn't, but hey, you could even use pointers and allocate memory yourself if you want, so theres that.
The conventions are, mostly, of intelligent design and as a bonus it saves you a lot of time you would otherwise spend on cumbersome configuration, by having sensible defaults.
CDI/JPA (especially compared to their initial/earlier versions) would be a great example of convention over configuration and how much is done in the background for you.
So ... the better part of Java is Kotlin.
Groovy if you want same frameworks, or Scala if you just need JVM. Kotlin has suspend. That's all it has. I had more troubles with data classes and null safety than help. If you write code differently than get/set or using lombock, data class usefullness goes away. Still don't understand why did people jump so much on it except that I see constant comparison with lombock stuff. I only use it to make rector/rxjava look pretty
I've never hit an issue with Kotlin's null safety when using it properly, I'd be curious what problems you ran into with it.
As for data classes, the only place I had issues with this was with Spring but this was years ago when their Kotlin integration was very immature.
Lombok can be problematic as it does a lot of code generation and requires an IDE plugin to even use it with IntelliJ. The excessive amount of annotations gets noisy very quickly too.
Using it properly? Theres just one way to use it, either it's nullable or not. And many cases demand nulls when it came to implementing different domains which I realised once started to work with Kotlin. This was unknown fact to me until I refactored code many times and saw it look like this? that? other? In data classes and calles looked 1000 cahrs long because I waz suggested by IDE to put = if..else with?.?. or ?: throws etc. Then I stared noticing how much time I need Groovy trait and not an interface. I ended up writting double the code in comparison to Java or Groovy because of restrictions which sounded good at a time. And there's no "properly" argument that makes any sense here. I basically hit the domain which has no benefit from Kotlins way of doing things. The only valid thing was suspend works with RxJava/Reactor so it looks more clean without .map().map Mono<> and so.
Your initial post didn't have much context and I don't know your familiarity with Kotlin so I was just checking it wasn't a common mistake someone coming from Java can make like using double bang (!!) all over the place.
That happens to. However null safety has no need for context, by default you have non-nullable stuff. Then you add ?. Then you know some things will be 100% there like val id? will not be null when getting it from DB and there you go with !! . So null safety is not having things nullable but rather the opposite - the Kotlin way of not having anything by default as nullable. At least this is how I make things shorter an easier for myself when using no context.
Kotlin is too much concerned about brevity (which is mostly irrelevant) and freedom to make chaos in codebase.
Freedom to make chaos. So that's what I'm looking at when I see my API now
Java - well hated language used by many still growing and in my subjective opinion has best tools and frameworks for many stuff. JVM still has huge performance gains regardless of biased benchmarks. You can calculate big numbers with precision and still have a nice framework for Web/APIs and so. Maybe not best at anything but good enough for a lot. We have Scala if we need to to more with JVM but still go to language for it is Java. And it still delivers solutions and they work. Hate it all you want.
Python - looks nice, I personally don't care about AI and such hype but give the fact that I can write integration scripts in it to use Apache Pulsar I wrote couple of things. I'm prefer type safety as in Java but I do use Groovy (which makes you "def" everything because your lazy and treat everything as hashmap because you can) so I cannot say I need it too much. I'm used to Spring and Micronaut also, so it might be hard to switch to alternatives on Python.
I hate it for its patterns, but regardless...if the tool works, the tool works! If it makes sense to someone, and they can ship working software for it, it has a reason to exist.
I did once too, and still like type safety when doing more manual stuff in C++, but I've come to appreciate that Python really doesn't need type safety once you understand how to make full use of duck typing. It's not worse, or objectively better, than type safety...it's just a different way of problem solving, like OOP and FP are different.
Yeah I like Scala in the sens it combines OOP, FP and has many nice ways and good picks for a certain problem in a given time. Like either use pattern matching with case classes or some other stuff but your choice, aaaand this is why I love Groovy - it's almost type safe. If you want you put in types for you to read but under the hood it's just object :D. Also you can have everything as HashMap and use like object in terms of someMap.keyNameAsDotAnnotation.
But for patterns I don't get it? Patterns enforced previously by Java tools? Or some language specific things? There's too much patterns nowadays and I hate them all equally as most people treat me like idiot for using my head instead of learning 3000 of them for each possible problem
Aaaaaaaand you've hit the nail on the head right there! I concur.
The trouble is, almost all Java-related documentation, courses, guides, tutorials, and answers I see advocate certain design patterns, code snippets, and habits (a la "always use double no matter what!"...and yes, I've heard that multiple times). In that context, you really are not invited to think, much less to challenge, the Great Java Way Of Doing Things™.
I think Java has some neat features and ideas — it also has some horrifically terrible things, like boxing/unboxing and generics (a mal-implementation of C++'s templates) — but it all comes down to how you use it. Great software can be written in any language, Java notwithstanding!
And I've heard good things about Scala.
I think my main issue with Java, and the main reason I love Python, is the overarching culture surrounding the language. With Python, we're always in pursuit of the One Obvious Way, which is not necessarily known for any given problem, but is discoverable through careful consideration. Pythonistas welcome challenges to the known One Obvious Way for anything, so long as you can prove why your way is better. If you can, then that is gradually shared and accepted as the new One Obvious Way. (In other words, we're always looking for the optimal solution, but recognizing we'll never really get there.)
I don't see that attitude in Java. Most Java code, documentation, and courses I've seen are reminiscent to me of "eh, it works because I used the special magic patterns I was taught. Truuuuuuust meeeeeeee." Perhaps that's not the Java culture as a whole, but it's been my rather discouraging experience over the past ten years. Maybe if I used it more...but then, after that experience, I really don't want to have to use Java. Give me C++ or Python instead any day.
Yeah I know. However I do admit that I switched to Groovy and Kotlin so I'm mainly using those two not actually Java and I can say Kotlin community is not that different from Java just that they prefer to brag Kotlin is better and mostly love FP instead of OOP which is the reason I will stop using it soon probably :D. I just liked the idea to use suspend and extensions for RxJava/Reactor where you simply say .await on reactive methods and use it like impertive/procedural. That's basically the only reason I switched from it. Data classes made no difference in many ways for me except ability to use .copy.
So I would say "pattern" is not Java thing, it probably started to be a hype with C++ and the GoF through EIP and so on. Now I just heard about EIP when I started to do a lot of integrations and using Apache Camel. But I learnt quite soon I just need a lot of easy to use libraries and EIP made my life worse. So thus I'll try in free time to investigate possibility of building AEIP (anti eip) solution in Python in sense that I need nice integration but mainly from Pulsar to Pulsar in mean time enriching with extra http calls and transforming. So if anyone knows nice tool like Apache Camel but for Python and easier to use please do let me know.
It started with Gang of Four, to be sure, but that book was published in 1994, one year before the initial release of Java. Design Patterns and Java have been taught concurrently in universities for a very long time, and (perhaps resultant of that,) every Java dev I've ever known is usually the first person to utter the word "pattern" in a technical conversation.
P.S. What in they hey is EIP? Search isn't being useful, and I hate acronyms. I may know the term, but haven't yet acronymized it in my head.
Sorry about that. EIP - Enterprise Integration Patterns. So Apache Camel and Spring integrations or even Red Hat Fuse. Looks nice then you realise enrich doesn't work as you need it today so I might consider pythonizing integrations with Pulsar. Maybe do it more dynamically and present it as AEIP as in anti enterprise integrations pattern just for fun. I thought like I only need Python to trigger certain stuff on new input from Pulsar and give it back once done with enriching and transformations so why have any other restrictions from patterns?
Patterns are supposed to be tools, rather than set-in-stone regulations. You can implement any (or all) of the Gang of Four patterns in Python, mix-and-match, and use however you need...or use no patterns if none of them are helpful.
Well as soon as you try your own thing with certain opinionated tools that enforce them you get my result: they look like bad guys keeping you in thin circle :D. You can, but you can see how much restrictions are in place so your better of starting from 0 and implementing them partially.
Ergo, one reason I'm choosy about what opinionated tools I use. ;)
Java is fast!
...as long as you don't follow their particular flavor of best practice, yes, decently so.
As long as you don't use Spring. Real Java best practices are perfectly fine.
Spring Boot is quite fast, thank you. Does a ton of work for me, I can pick and choose my favourite server/serialization library/application metric source/templating engine/whatever, and it's still fast, and doesn't need that much of configuration because most defaults work just right.
Spring is a resource hog and is extremely slow. Just take a look at Techempower benchmark. Note that fastest Spring results in this benchmark - Spring Flux, which is not exactly the same thing which usually meant under "Spring".
And for the record, I was not referring to anything but core Java in terms of performance hits from "best practices". Unless all the courses, guides, and tutorials I've encountered over the years have not been using "best practice", but then I have grievances with the official documentation. I listed several of these bad habits in another comment, won't waste everyone's time repeating it here.
(P.S. "Best practice" is a mythological beast in any language. "Good practice" exists, but it requires application of thought, discernment, and tailoring to the situation.)
Unfortunately most courses, guides and books are teaching not best practices. In most cases they are repeating the same bad habits that you're don't like. Fortunately really used practices are much better (although far from ideal).
That's fair. Sounds like someone needs to write a book on how to do Java well.
Hum, possible project for me in another few years?
@siy :
Spring being a "resource hog" may have been accurate some years ago (the Spring 2.5 app I was writing in 2008 wasn't light for sure) but I have small Boot applications in production that are really fast and relatively "small". And I'm looking at Quarkus and similar projects to make that even smaller.
It's not because Spring got better, it's because hardware significantly improved since then. Anyway, I'd highly recommend to take a look at Micronaut. It's kinda Spring done better in some aspects. It doesn't avoid Spring conceptual flaws like shifting errors to runtime and use of exceptions in business logic. But it performs a lot of things at compile time where Spring uses runtime reflection. This significantly reduces memory footprint and improves performance. In Techempower benchmark Micronaut in average about twice as fast comparing to Spring. It's still quite bad comparing to what actually Java can do though.
I'm more of a Micronaut fan instead of Quarkus but in any ways I had enough performance with Boot and WebFlux now not to switch to one of those. Reason is I need some stuff not yet written for them. I may try to do it myself but I doubt it will be soon so, if you don't need to shutdown those services and start up many times Spring is still fine
From my experience, Spring is quite bad in regard to application long term support and maintenance. If this is not an issue, then yes, Spring is fine.
Well yeah for Monoliths never being able to shut down because of states, no replicas and such. For stateless service not too big and getting restarted frequentliy due to updates and so it's good. Different days different purposes different quality
It's not about restarts. It's about practices promoted by Spring. So yes, if quality and long term maintenance is not an issue, then Spring is fine.
The only thing I dislike in Spring practices is reflection which is a part of a lot of things in Java so can't say that Spring would dominate here. However, don't know what your aiming at. Restarts solve some issues that require JVM tuning (maintenance in other words) and these thing were mainly caused by reflection in cases I've seen so far. And that's what I though about when I saw maintenance. However with removing of XML I had no issues of maintaining most of the code. Maybe Advices were a bit ugly.