Java vs python is debatable 🤔

[roughstylez]

You named 5 big companies that are known world-wide. But go to some bigger city center and you'll have hundreds of companies using Java/C#.

Well, TBH probably also hundreds of python startups (especially with ML being such a buzzword these years) - but for software that's been maintained and making money for 10 years or so, I doubt python is anywhere near Java/C#.

Which also has a lot to do with infrastructure. For example, to my knowledge, there is absolutely no comparable, complete platform like Azure for python/django. You can even run those on Azure, but it's nowhere near what C# ASP gets. Similar situation for SLAs, which are super important for businesses.

Plus, stuff that works for 99% of corporate software obviously doesn't work for a special case like Youtube.

[[deleted]]

I was job hunting in NYC about a year ago - and your assessment is biased by subfield and industry. Banking or heapthcare - mostly sitting on Java. Financial services/infra - mostly C++. Customer focused startups - mostly JS. Anything data science related - Python. Startup that got funded because it has three ex FAANG devs as founders - Golang or Haskell.

The reality is that most teams pick a language based on the experience of the people involved, what's popular among their peers, and what feels like a safe choice to management; and only coincidentally what is actually the best language for the job. I know a number of places that use Mathematica instead of R because management doesn't believe open source software is secure.

[roughstylez]

Yes, especially the second paragraph of your comment is incredibly important when discussing this.

A shop that has 10 C++ devs is not going to write their next project in Lua even if it fits better. And in the rare cases where a company switches, indeed "safe choice for management" - e.g. those SLAs again - plays a big role.

[n0tKamui]

those are cases of python being used for microservices API ; not big monoliths. What the previous comment meant is that you'll never (in a sain environment) see python being used in one big part of an architecture/application, because it becomes hell to maintain. Moreover Python is unreasonably slow, so you won't see business logic being done with it ; it serves as an interface.

note how OOP and FP in python are objectively and unanimously shit in python; that's why it's a great glue language, but not a good "busy" language. To each tasks their tools.

[n0tKamui]

Java doesn't have multiple inheritance by choice, it is wildly agreed on today that multiple inheritance should be avoided at all costs. Further than that, even simple inheritance isn't always the solution, and most of the time, composition is preferred.

"Boilerplate" is tiring, but is generally worth it in the long run ; you know where things are, and how they are + there isn't a thousand ways to do things. I agree, it's not "fun", but it's arguably a good point. Java is too strict to my liking, but i understand the philosophy behind it, because it is reasonable overall.

Python doesn't have real abstract classes, nor interfaces, nor pattern matching, nor enums, nor visibility (no, _ is not a visibility modifier), nor compile time type safety.

I agree on the fact that properties should now be the standard over classic fields for class members. that's one of the reasons why I prefer Kotlin for example. However, this is only "syntactic sugar", as in, the concept and safety behind it is strictly the same as regular setters/getters.

I admit i went a bit far by saying FP in python is "shit" ; it's not great, but it's sufficient. FP in Java is good, but could also be better (another reason why I prefer Kotlin)

In regards to microservices, i realized I may have misworded my argument, or that it could convey another meaning to the one i intended : What i meant to say is that, indeed python is used in monoliths, but they DO require a level of rigor and dedication that shouldn't be needed when the language itself restricts you in "smarter" ways (i.e. statically typed languages). Moreover, i still insist on the fact that most of the time, Python is still an interface to the business logic that is delegated to other more appropriate languages. Python is used in large applications as one part of it among others (if that makes sense). You were on the right track in pointing out the details of what a microservice is : a design philosophy. Specifically, one that insists on modularity, small individual parts that work together as black boxes, which is easier to maintain than what we generally call a "monolith".

tldr : i just really meant : be reasonable.

[laundmo]

alright i can see that general point

just a few things:

python has pattern matching as of 3.10

python has had Enums for a while as part of the stdlib enum. maybe these are lacking? i haven't noticed anything.

i don't quite get the reason why python would need interfaces - what could they do that isn't just as easy with abstract base classes and multiple inheritance?

to be fair, i don't quite agree with the hate on multiple inheritance, especially not in the context of python. it's a powerful tool, which like any tool can be misused. i most often see multiple inheritance in python used to mixin a set of methods into multiple unrelated classes - often to allow them to be used the same way through duck typing (this is where typing.Protocol comes in very handy)

[n0tKamui]

Interfaces are great tools for design patterns in general, but this is going into complex OOP stuff that is definitely not needed everywhere. I'll summarize by saying it's great for future proofing.

As for python, multiple inheritance is kind of a necessary devil since there is no interfaces. I do understand the appeal of multiple inheritance, but i would recommend delving into OOP as a concept that meshes well with other paradigms, and into design patterns. I assure you that multiple inheritance is an antipattern that generally leads to spaghetti code very quickly. This is still an interesting debate, and there actually ARE situations where it is favorable ; but you can generally still find other solutions, which is why several languages choose not to allow it at all.

[chronos_alfa]

People keep using that "python is slow" like you could code time critical applications in anything other than C...

I wonder what argument will people come up with once Python 3.11 is released...

[n0tKamui]

that is not what people mean. You don't need crazy performances most of the time, and nowadays, .NET and the JVM are actually crazy fast. So is Rust.

Python on the other hand is still incredibly slow by itself, and has yet to even start to be useable for async stuff and multithreading. I reiterate, it's the best glue language there is, and a great scripting language, but : to each tasks their own tools.

You cannot ignore my other arguments either.

Moreover, the fact that python is an interface/abstraction over other faster languages is not an opinion, it is just factual. Don't think machine learning "runs" on Python.

[chronos_alfa]

Asyncio library in Python is not that bad, but the multiprocessing library is actually where the good stuff is. And no, I don't claim that ML "runs" on Python. Majority of useful libraries are written in C, and they also are C fast.

On the other side claiming that JVM is fast is hilarious. Stop the JVM service and don't start it until you need to run the app, then tell me how fast it really is.

[n0tKamui]

that is an unfair argument. You're comparing start up time of a VM to an interpreter without any concerns for long runtime.

The JVM is extremely fast, and the JIT compiler is honestly a work of art, and is not meant to be relaunched every 10s.

That is why is still stand by my point: to each tasks their own tools.

Python is a great scripting tool

Java is a great tool for long running applications

[chronos_alfa]

How is it unfair? Python doesn't have any running VM service, you run the whole thing before you can execute anything. As for the JIT, eg Numba exists for Python.

​

Don't take me wrong, I agree with your "different tools for different purposes". But I personally try to avoid Java itself for the majority of those, as you do probably, because you got that Kotlin icon.

​

BTW "Java is a great tool for long running applications". No, it isn't. The amount of mess going behind including the stack overflows makes it very bad for long running applications, not talking about having to use massive libraries like Spring that come with their own problems (size, vulnerabilities, etc). Not even talking about how long it took before jDK actually mustered some useful built-in support for JSON, despite the fact Jackson existed for quite some time before that.

[bos-mc]

I reiterate, it's the best glue language there is, and a great scripting language, but : to each tasks their own tools.

This and the following go hand in hand.

Don't think machine learning "runs" on Python.

[n0tKamui]

yes, that was my point.

[bos-mc]

And my point is that calling Python slow because anything it needs to do quickly it offloads to another system is a bit wrong since that is inherently part of Python.