loading...

re: Python vs Java VIEW POST

FULL DISCUSSION
 

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:

  • standard REST/CRUD?! C# with net core is more efficient performance-wise than both Java and Python, while on par with dev time with java/Python
  • graphQL/async stuff: this is the native domain of Node. Yes, Java and Python have similar stuff but they simply don't fit well as Node does. Also 99% Java is Spring MVC and not Vert.x Web so it is a resource hog.
  • very limited resources (embedded or functions/containers ) ? Rust and Go.

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.

 

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

 

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.

Code of Conduct Report abuse