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.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (91)
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.
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.
Minor typo: that's Clojure, not Closure.
Thanks!
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.
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.
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.
Java is niche? I disagree strongly. It might be (falsely so) considered legacy by some, but it is by no means niche.
Java is now, with microservices and containers, facing a huge demand and second wind once again.
I usually don't defend any language, because it's mostly flavour and opinions, but Java is definitely a language we can call full-stack.
Javascript may be much larger in it's userbase, but even so it's ecosystem is smaller.
With Java you get full fledged and battletested CI/CD (Jenkins), package and artifact Management (Nexus, artifactory), security scanning (NexusIQ, Sonar), observability (built into JVM), deployment Management (AppServers of different flavours) and much much more.
Everything managed by commonly accepted and well-defined Standards.
Thats not something you can get with Javascript as of now.
Libraries, of which Java has more than enough for every possible use-case, aren't everything I'm afraid.
I'm not denying Javascript it's deserved glory, far from it. The improvements it made over the last 10 years are astonishing!
But the tooling changes so rapidly and often, getting something as proven and tested as the Java World Counterparts will take a lot more time.
I would also like to add Quarkus. I am not very experienced but It looks really awesome to me. with graalVM and quarkus, we can now make native java executable and size of these executable are very small compared to JAR. It's performance will also be better since it is machine code instead of byte code. The startup time is also very fast, which is important for microservices in some cases.
Best of all, we can use same API's like JPA, CDI etc. so an experienced java developer can get easily started with quarkus.
Do check it out - quarkus.io/
Absolutely true.
In one of my clients projects we are using Quarkus and migrate quite a few webservices to it currently.
The performance and minimal overhead of the resulting native binaries is amazing.
It takes quite a bit of modification to the typical CI-Chain, but if you get it to run smoothly, the results are astonishing.
If you want, I could write up a little article about it here
yeah, I would love it.
It will be very helpful as there is relatively less material available on quarkus.
Consider it in the works :)
It is done :)
I want all schools teaching Java to complete beginners to stop and change to Python. The amount of boilerplate to start up a Java project hinders understanding of the essence of computing.
Below is hearsay.
Reserve Python for utility scripts and data exploration. For production, pick Julia if you are doing data analysis and AI, and Java if you are writing a service. The extra speed can keep your monolith fast enough longer so your scale wouldn't force you to split it up.
Yes Julia for data analysis an AI for speed (apparently, still not found the time to play with it properly yet), but with the tradeoff being that Julia is still far from an 'accepted' language.
A significant proportion of the data-science field that I interact with I would doubt have heard of it. FWIW when asked about why Jupyter notebooks are called Jupyter, I would give it 50:50 that a user would be able to state it stands for Julia-Python-R notebooks. Looking at AWS as a major example, their docs for their data science services talk about python first, R sometimes, and Julia extremely rarely.
That said, I am not embedded in the Julia community at all, so there is significant bias in my understanding. Is Julia something you have put into prod? What were your experiences, would you mind descirbing a high level over view of the tasks and the stack? I'm always keen to learn.
Sorry I have to disappoint you, but as I wrote, it was hearsay -- I am not involved in prod system with Julia. TIL that Jupyter is Julia-Python-R! I've read a few cases of unintentionally running loops in Python instead of numpy, which is slow. I hope you have better luck exploring Julia further elsewhere!
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 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.
Spring really shines in how poorly it uses reflection. Must admit, I didn't know that it's possible to perform as poorly in this regard as Spring does. But this is another story (please let me know if you're interesting). Reflection is not bad practice per se, although it is a significant obstacle for switching to more recent Java versions. Instead, I mean other things. You already mentioned advice and there are other examples of using string constants in code, for example profiles. The shift of some errors from compile time to run time. Almost every Spring application has a "context loads successfully" test because it's pretty common when a Spring application can be compiled but can't be started. Then there is the use of exceptions as part of the business logic. Then there is Spring "magic" which results in subtle, difficult to nail down issues. All of the above are examples of bad (or awful) practices which are used by Spring and encouraged to use by developers.
Under maintenance, I mean not restarting the app from time to time. Instead, I mean adding/changing functionality as business requirements evolve over the time. Here you can meet things like breaking an application just by adding (not using!) yet another Spring dependency or floating bugs caused by conflicting dependencies. It is also worth mentioning that long-living apps often updated/maintained by different people and Spring "magic" (in particular, autowiring) makes code much harder to understand and navigate.
OK, can't argue with some of those but Autowired for me is not bad at all and I quite like to have it. Anyways as I said maintaining Spring app in most cases was quite easy for me when not using too much advices, or such. However I do use Autowire in Controllers, Services, Facades.. such to wire those same things together, but not in domain models (which I did see were made in some cases) or any other part of the code as I never had desire to do so. Once I wanted to provide quick small fix for some prototype and made
Map<String,Objec> cachewhich made me realise what can actually happen when you have too many components and autowires for them (for those that may read this and don't get it, it will inject spring application context cache :D somehow). I guess I just didn't program in that way that I had to worry about those things. I know framework magic can be really bad but I avoid such things and never even think about them as solution.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. ;)
My 2 cents. different beasts. Java is still strong in Big Data. Python is going strong in AI/ML.
For anything else there always be a more efficient solution:
This said, unless you want to become a patchwork shop you have to limit the type and number of technologies you employ, at least if you have a certain amount of junior devs unable to keep the pace with code writing a new tech learning.
In this sense, if you are in the IT/Web industry, Typescript with Node is a killer! same lang on both front end and backend.
If you need a lot of computational intensive stuff forget Java it is the shittiest thing I've ever seen both semantically and from a dev-time-vs-perf balance stand point. I've written computationally intensive code with C++ and Python (with binds) and they are great. I've started maintaining a code base in Java with mid level computational stuff: has BigDecimal... BigDecimal... BIG DECIMAL!!!!
If you need a good memory footprint and a good perf go for net core or node (the former IMHO better with SQL and sync stuff, the latter with NoSQL and async)
If maintain a ton of legacy stuff is a requirement while writing new stuff, or if your junior devs simply can't handle SQL at all, then Java (with JPA) is the solution to go.
Anyway seriously, can't compare Python with Java unless you are doing mid sized web projects. then yes one or the other are the same.
BTW: Python has static types , abstract interfaces and similar stuff if needed.
"C# with net core is more efficient performance-wise" might be but not that much in case of standard REST/CRUD. Worked with both, not noticeable to the end user, never tested the actual milliseconds and once browsed pages like link I'm quite sure opposite is true. And I mainly focus on Cloud and multiple DB access as those are usually most use cases.
However it's awful in many ways with it's horrible EF Core and it's disgusting approach of instantiating services, controllers and so. Creating and using Singletons because of the way it's dependency injection works was so horrible for me that I just gave up. And reason I tried it is because - Why would I create new controller, services, whatever, each request? Does that sound efficient for you? To me no and sorry but I really don't buy Microsoft way of doing things. It's not PHP, it's not interpreted language and I don't need that "singletons are bad" excuse. So in the end as developer who did both I would never go back to C# even if it's more performant in these cases.
From a user perspective there are tons of things which impact so yes I agree. But I'm still impressed (in the wrong way) how much RAM java requires even for silly things.
About EF Core.. I don't feel so bad if I compare it with JPA but I suppose it is a matter of taste.
Constant reinstatiation is a bad thing I agree. I also dislike controller based aproaches BTW. This is why I prefer a funtional approach to REST (like in Vert.x web: no objects at all), while a persistent CRUD layer is ok of course.
Do not stop at the pure benches: if you dig in the repos of the tests you will discover that the fastest solutions (regardless of the tech/lang) do not really use an ORM at all. I've found code in the past where the ORM logic was passed by native queries mapped on DTOs.
Well I didn't use JPA lately at all but I didn't compare it to EF because it's not the same thing. Maybe Spring Data or Hibernate itself but JPA no. I mainly hated tracking no tracking thing. The way it works with save and update and mainly things not related to modeling
Why (JPA != EF) ? From my point of view JPA == EF == SQLAlchemy.
Btw I've recently apreciated micronaut-data-jdbc. Unfortunately I've not found a way to mix in with Vert.x Web :/
JPA is convention while EF is full framework implemented. I used Spring Data without using JPA myself in some cases. So I dissliked some calls via functions or LINQ which are part of EF
I see. My mistake: with JPA I meant any of its implementations like Hibernate JPA or Eclipselink.
Your negative comments on EF Core have lead me to open a new spare time project to re-evaluate it! Shame on you :P
Ahahaha, good, if I'm wrong you'll reply to tell me I wasted your time, if not then nice proof of concept
Theyβre meant for completely different purposes. Python is good for when you need to get a script written quickly, or you wanna deal with data or AI. Java is good if you wanna build a more fully-fledged application or need something that focuses more on OOP.
I find OOP, and application design in general, to be far more intuitive in Python than in Java. (And this coming from a C++ dev.)
Makes sense. What I was referring to was how Java is mainly an OOP language while Python is more diverse in how you structure your code.
I lost count of how many times I've had to help interns ditch bad OOP habits that Java's "best practice" taught them, and which were harming them when working in literally any other language, including C++. Here's six of the most important things that Java practice does not teach:
Not everything needs to be a class. If a single class can't be justified as a data type, it isn't worthy of being a class at all. Use other namespacing tools for organizing functions and/or arbitrary (static) data together.
If all your getters and setters are doing is blindly relaying the contents of a member, expose the variable as public. (IntelliJ literally gives you this anti-pattern in a snippet. Stop it.)
Side-effects are evil. Write pure functions as much as possible, even for class members. The only thing that a member function should mutate is its own instance.
Creating a workaround to a poorly designed API does not justify writing a class. (Looking at you, Integer class!)
Never, never, never blindly trust abstractions. If you don't have any idea what's going on under the hood, you lack a proper understanding of your code, and likely of the problem you're solving. (Modern C++ std library is often guilty of this too, though to a lesser extent.)
Use the right data type for storing your data, based on what you actually need, not what gives you the most arbitrary freedom. (Using
doubleevery time you need a floating-point number to two decimal places is an obscene waste of memory. "I might need to eventually store up to nineteen places!" Great. Refactor when you get there.)I could go on like this for some time, but you get the picture. ;)
Java has great 'final' keyword and once you make field final, even Idea does not propose to create setter for it.
You missed the whole point of Integer and other relevant classes. They are immutable by design. And, frankly, boxing/unboxing works transparently so nobody actually cares. All cases where difference is sensible (for example, large collections), already covered by various libraries.
Java "best practices" described in "Effective Java" and they are quite close to what you're promoting. Unfortunately for Java there also Spring, which definitely promotes a number of very bad practices, including mutable beans and using exceptions as part of business logic.
Or, to put that another way, "stay out of my living room because I ask you, not because I have a rifle."
I actually find the entire concept of "data hiding" to be funny any more. It gives us an illusion of some sort of security, but it's really fairly meaningless fencing that we trip over more often than not. (Mind you, I'll still make some C++ members private in accordance with good practice, but not with the same verbose fervor that Java patterns imply necessary.)