3 ms·
> It is a vague claim. How do you decide what is “important”? Java is so clearly ahead and by so much that it doesn't really matter, but generally, "important"
by pron 2y ago
> It is a vague claim. How do you decide what is “important”?
Java is so clearly ahead and by so much that it doesn't really matter, but generally, "important" can mean size, expected lifetime, criticality for business or some combination of them.
> Which I note has both JavaScript/TypeScript and Python ahead of Java.
Python is about on par or slightly ahead but given that the vast majority of the uses of Java are for server side applications, while the vast majority of Python uses are for data analysis etc., so clearly Java is much more favoured for serious applications (not to mention Python's serious scaling issue). JS is indeed significantly ahead, but again, clearly the vast majority of JS use is for web client programming. Node.js was very big for a while, but it isn't as big anymore. Again, ask any market analyst. Perhaps in 2035 some new language is going to show up and unseat Java, but in 2024, Java is the language of choice for serious server-side apps -- not the majority choice (i.e. all other languages combined may make up more than 50%), perhaps, but the first choice nonetheless.
- skissane 2y agoI’ve been spending the last few months reimplementing Java backend code in Python. I’m sure I’m not the only one. It actually wasn’t originally my idea - I fought the decision and was initially upset about it, but now I’ve been living with it I’m actually glad they forced it on me :) Yes it is true that Python can have limitations with high scale. But there are solutions to that (multi-process Python app servers for example). And the Python core performance story is improving (GIL removal is finally happening, JIT is moving into the core.) Plus there are a massive number of Java/Spring/etc business apps/microservices which aren’t actually high scale (I’ve written some myself) and could just as easily be done in Django/Flask/etc The thing with saying that most Python is for data analysis, is what starts out as some ad hoc data analysis or data science prototype sooner or later morphs into a production service. And maintaining the same language from prototype to production makes life a lot easier-especially when the data science team decides they have to fundamentally change algorithms to improve performance leading them to rewrite half of it in the middle of the project. It is much easier to teach a backend developer Python (many of whom already know it anyway) than try to get a data scientist to learn Java. Python is the de facto standard language of AI, and AI initiatives are driving a lot of Python adoption. But once you are using it for AI, why not consider it for non-AI use cases too? There isn’t a hard boundary between the two anyway - a lot of the Python code I’ve been writing recently has been related to getting OAuth tokens to talk to various pre-existing microservices (mostly Java with some node.js) and although I wrote that code for AI use cases it is obviously very applicable to non-AI use cases too.
- vips7L 2y ago> I’ve been spending the last few months reimplementing Java backend code in Python. Lots of people are doing the opposite once they hit scale. DoorDash went from Python to Kotlin/JVM for their backend: https://doordash.engineering/2021/05/04/migrating-from-python-to-kotlin-for-our-backend-services/ https://doordash.engineering/2021/05/04/migrating-from-pytho...
- skissane 2y agoFrom the article you linked: > our monolith was built on old versions of Python 2 and Django, which were rapidly entering end-of-life for security support That doesn't seem to be an issue with Python scalability per se. There are massive creaking monolithic Java apps out there, stuck on old versions of the JDK and various Java libraries, which are just as brittle. Also, if the discussion is about defending the design choices of the Java language, this blog post doesn't really support that defence, given that while they did choose the JVM as a platform, they also selected Kotlin over Java
- vips7L 2y agoI think you're selectively reading that to fit your narrative. The design choices of the Java language are the design choices of the Java Platform and that's exactly why they chose it: > CPU-efficient and scalable to multiple cores > Easy to monitor > Supported by a strong library ecosystem, allowing us to focus on business problems > Able to ensure good developer productivity > Reliable at scale > Future-proofed, able to support our business growth
- skissane 2y ago> I think you're selectively reading that to fit your narrative. Please don’t tell people they are selectively reading things, because if you are going to do that, I can do the same right back to you. You will note up-thread I’m complaining about gaps in the Java language (not platform) which are why Lombok exists, and the Java language maintainers’ unwillingness to provide official solutions within the language to address that - which is something Kotlin handles much better (it has some Lombok-like features, plus its DSL support). So, just as you accuse me of selectively reading that blog post to fit my narrative, I can accuse you of selectively reading this thread to fit yours - but mutual accusations of “selective reading” aren’t really adding anything useful to the conversation, are they? > The design choices of the Java language are the design choices of the Java Platform and that's exactly why they chose it: No. As I said, the design choices of the Java language not to provide many Lombok-style features, whereas Kotlin does, has nothing to do with the JVM as a platform