However, the sheer overhead of Java is insane (not to mention dealing with dependencies...). I have a 10-year-old server with a quad-processor and 16GB of RAM which has reasonable performance, so long as it runs anything that was compiled (perhaps with the notable exception of PHP, which is a lightweight language, also with just-in-time compilation). Launch anything that uses a JVM, and bye-bye server — it will basically only run that single Java application and nothing else (granted, Ruby on Rails is almost as bad as Java).
That is absolute nonsense. I don't know what Java software you ran. But I've run enterprise java software processing thousands of complex orders from an eretailer an hour with less resources than that. That software wasn't even optimized for that process.
If there is anything these days which assumes infinite CPU and RAM, then it's the whole Node/JS world. You can't even "compile" a basic Angular application on a dual core node with 1GB RAM.
All the terrible things you mention about Java... they are worse in JavaScript. Managing dependencies in Java has been bliss since Maven was created in 2004. Dealing with dependencies in JS/TS is quite a nightmare, especially with the rather unreliable compatibility with used node versions. And then there's the nightmare of trying to correct "vulnerable" packages.
Java carries around a lot of baggage from the early years, which they cannot really get rid of unless they want to break compatibility. But JS (and thereby by extension TS) carries around an absolute nightmare of legacy. A legacy which is unfixable. TS might have been able to fix it, but you simply can't have a pure TS application as there is still of JS-isms used by various packages (and even JS dependencies you cannot get rid of.)
PHP was given a horrible reputation because of bad language decisions. JS as most of the same issues, and more.
Well, to be honest, and as I've mentioned, I'm not that fond of JS myself. A language that implements closures simultaneously with classes without encapsulation has very serious conceptual errors. I read somewhere that encapsulation in JS classes is on the list of upcoming capabilities; but I'd also bet that closures won't disappear, since that will break a lot of JS code, and, on top of that, they're a bit more efficient than classes for singletons... anyway, that's just one of the many, many details of the kind of baggage that JS carries as legacy which will plague developers for decades. I just mentioned that JS has a reasonable chance to 'replace' Java mostly because you can have both JS on the front end (a Web browser) and on the back end as well: you just need to be proficient in a single language, use a single toolset, and so forth. Ironically, it was during those days when Java applets on browsers were popular that Java showed its biggest promise — a way to close the gap between the front end development and the back end. But that came at the cost of an utter waste of resources on the browser side of things... while JS seems to be better positioned to deal with that.
Still, I concede that JS does, indeed, carry around way too much legacy, and very likely because of that I was wrong in my belief that it would ever replace Java at some point. After reflection, I think you're right: JS does way too many things wrongly, and the future will bring more complexity while dealing with legacy, not simplification that might get a compiler to produce more efficient code.
Legacy, indeed, is a nightmare to manage. I'm personally fond of PHP, after hating it with a vengeance for a few years — way before we even had classes in PHP, much less the plethora of goodies that are available today. However, I totally agree that there were lots of bad language decisions; and now the core developers are effectively forcing developers to start tidying up their code, or it simply won't run under PHP 8.0. I think that PHP 5.6 was a turning point: a clear message telling PHP developers that the days of sloppiness were over, and a 'last chance' to read all those warnings in the logs before moving on to PHP 7 and beyond...
But the truth is that I started to appreciate PHP because of lazy programming! Here was a language that allowed you to write code very quickly, without even bothering with boring details such as declaring variables. This approach works well while a language's syntax is very simple — which was true for PHP in the early days. I mean, if you have just a handful of types, all of which can be converted into each other, well, then you can allow lazy programming. The problem came only when the PHP core developers wanted to add all those nifty features that were available on other programming languages. And I agree that JS followed the same path (thus, TS). Actually, we ought to have 'Typed PHP' at some point in time, too; on the other hand, it looks like PHP is moving in that direction by leaps and bounds...
As for Java, I'm still sticking to my first point: I certainly believe that some people can get good enough performance out of it, and possibly keep all their dependencies in order (using Maven or whatever tool is popular today), therefore combining the advantages of a complex language designed to tackle complex problems with a predictable development pipeline ('predictable' in the sense that you can rely that, during, say, a five-year project, you will still be able to run the code you started writing, while still keeping all those hundreds or thousands of dependencies up-to-date with the latest security and performance patches).
But my comments were based on the assumption that it's next-to-impossible to accomplish that — an assumption grounded on my own experience, which, granted, is extremely limited, and was uniformally bad. My worst nightmares actually came from Java applications that people specified as the 'best' choice because, well, Java works universally on any device that implements a JVM, right?... That's what it says on the box (see the comment by @greenroommate
below: the selling point of Java has always been 'compile once, run everywhere'). In practice, there hasn't been a single Java project that I had to deploy which hadn't some impossible-to-resolve dependency issues (Maven or no Maven...); and when complaining to the developers that their application didn't run under, say, FreeBSD, they would just shrug and comment that they never recommended deployment on anything outside the Windows or Linux worlds...
I certainly understand that there are many reasons for such choices; if 99% of your market runs their Java applications in a very strict and controlled environment — a very specific platform, with precisely defined characteristics such as the kind of system libraries that have been installed — it's reasonable to assume that if you're attempting to run it on anything else will not work. But that defeats the whole purpose of using Java in the first place.
Now you can argue that the same is true for all the other languages (and especially so for the natively compiled ones), at least to a degree, and I would certainly agree with you on that, but that's not really the point. The point is that a regular human being will be always hard-pressed to get a Java application to run efficiently and with adequate performance on whatever platform they happen to have. In other words, the time eventually saved by Java developers in producing cross-platform code in the first place (not needing to worry about eventual differences between systems, since they write code to be compiled and run under a JVM) is then spent by those who need to deploy such code on a platform that is theoretically supported (in the sense that there is an available JVM for it) but in practice never works, or only works by taking up a huge amount of resources, or requires a complex setup which will only work for any Java application running on that particular system to the exclusion of anything else; my 'bad' experience with Java comes from all those cases, happening over and over again, and which even seem to get worse over time (but I admit that this can be just my perception).
By contrast, other developers do not even bother with 'cross-platform code' — they just ship a Docker container. I have my issues with the whole Docker concept, but that's another story. The point is that if you 'need' a very specific instance of a virtual machine to run your application, then why bother with using a so-called cross-platform language, when all you need is to develop your application in whatever language and environment you prefer and simply put it inside some sort of virtual machine (such as Docker) instead?
On one hand, I never benchmarked such a trade-off, between writing something in Java and expecting it to run everywhere, or writing it in whatever language you prefer, and get it running under a Docker container instead. Maybe a Java application will beat anything else that requires a virtual machine (or, if you prefer, perhaps the JVM is the most performant of all VMs out there). I simply don't know, I just have personal (and therefore subjective) perceptions based on my (limited) experience.
Some years back, there was a discussion around a specific application I've used which had been painfully ported from Windows to macOS, running natively on both, at the cost of thousands of development hours, plus the extra hours of ongoing maintenance to keep the code in sync. This was not a simple application using, say, Qt, or some similar cross-platform toolset/framework. Rather, everything had been done from scratch, in both platforms. There was a small contigent of Linux users who argued that they would also like to be able to run that application as well; and if it had been succesfully ported to macOS, then it would be very likely much easier to port it to Linux as well. It wasn't, and for many years, the developers refused to even consider to 'waste' more development time just to create from scratch a third codebase. Ironically, or perhaps not, at some point they actually did release a Linux version... but this was 2007 or 2008, and the iPhone (and the first Android phones) had just been launched, and, consequently, people were asking when they would have a native version of the application on their iPhones as well, even with limited functionality... we're still waiting for that in 2021!
It might be argued that if the application had been developed in Java (and not C#/Objective-C), it might have been much easier to port it to whatever technology becomes fashionable. It's not as if that company's developers did not know how to develop in Java — they most certainly did! — but rather because they were afraid of whatever performance hits they'd get from that approach, and, more importantly, they knew it would be a very hard task to give reasonable tech support to next-to-clueless new users, teaching them how to properly configure their Java environment just to run that single instance of the application.
Back then, all I could remember was the hard lesson given by Triple-A game developers: if you wish to avoid performance issues, just statically compile everything in C/C++...
Now I can see that many issues you had where history related. You mention docker but then also not working on FreeBSD or such. Most of these things are not there anymore given docker, fatJars and recent movement towards using less reflection but mainly new versions of Java and JVM. I don't really understand people dragging old issues. It's like saying C# is bad because you need Windows yet here we are in 2021. So yes there was a lot of bad things in Java libraries, for example I personally can mention writting desktop app in Java but for usage with MS SQL Server 2008. Yeah, .jar libs had DLLs inside of them as a driver which meant Windows only. So is that JVM not running or people doing dumb stuff? Why, write, put a DLL and do a call to native driver? That's what was wrong.
But to put it in perspective, node modules are heavier than the black hole and Node sucks up way more resources on big processing where data is not 2KB JSON but 1GB and such. It's simply incorrect that it drains nore resources than Node or such. Maybe true in simple cases with smaller data. There's a use case for everything. They also, as I said have way too many ports from rust and c. So does Python, so does PHP. So bashing Java for it you bash those languages as well. As to why it's hard to accept that this is the case with others but easy to hate Java beats me.
I have enormous amount of porting problems today with PHP apps and as a solution we're rewiring it into something that can be put in docker easily. And yes some of it is Java. And first thing to notice is usage of 1.8 while we're in te year od 17 being stable soon. Why do people do this beats me.
Overall, there is a lot of porting issues with some Java libs as I explained, and even Go might be better here, it's really unrealistic to ignore same problems you mentioned with other languages. Again I had those with Python, PHP, and Node. Java's main selling point might have been "write once run anywhere" but it's 2021 and we need to compare todays version and point of view.
I really like that someone is able to have a discussion of it and I'm not defending Java as I have a lot of complaints about it as well but JVM is at the bottom of it and it's resource consumption. I just don't like being too unrealistic and ignoring that a lot of things have same problems so I comment.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That is absolute nonsense. I don't know what Java software you ran. But I've run enterprise java software processing thousands of complex orders from an eretailer an hour with less resources than that. That software wasn't even optimized for that process.
If there is anything these days which assumes infinite CPU and RAM, then it's the whole Node/JS world. You can't even "compile" a basic Angular application on a dual core node with 1GB RAM.
All the terrible things you mention about Java... they are worse in JavaScript. Managing dependencies in Java has been bliss since Maven was created in 2004. Dealing with dependencies in JS/TS is quite a nightmare, especially with the rather unreliable compatibility with used node versions. And then there's the nightmare of trying to correct "vulnerable" packages.
Java carries around a lot of baggage from the early years, which they cannot really get rid of unless they want to break compatibility. But JS (and thereby by extension TS) carries around an absolute nightmare of legacy. A legacy which is unfixable. TS might have been able to fix it, but you simply can't have a pure TS application as there is still of JS-isms used by various packages (and even JS dependencies you cannot get rid of.)
PHP was given a horrible reputation because of bad language decisions. JS as most of the same issues, and more.
Well, to be honest, and as I've mentioned, I'm not that fond of JS myself. A language that implements closures simultaneously with classes without encapsulation has very serious conceptual errors. I read somewhere that encapsulation in JS classes is on the list of upcoming capabilities; but I'd also bet that closures won't disappear, since that will break a lot of JS code, and, on top of that, they're a bit more efficient than classes for singletons... anyway, that's just one of the many, many details of the kind of baggage that JS carries as legacy which will plague developers for decades. I just mentioned that JS has a reasonable chance to 'replace' Java mostly because you can have both JS on the front end (a Web browser) and on the back end as well: you just need to be proficient in a single language, use a single toolset, and so forth. Ironically, it was during those days when Java applets on browsers were popular that Java showed its biggest promise — a way to close the gap between the front end development and the back end. But that came at the cost of an utter waste of resources on the browser side of things... while JS seems to be better positioned to deal with that.
Still, I concede that JS does, indeed, carry around way too much legacy, and very likely because of that I was wrong in my belief that it would ever replace Java at some point. After reflection, I think you're right: JS does way too many things wrongly, and the future will bring more complexity while dealing with legacy, not simplification that might get a compiler to produce more efficient code.
Legacy, indeed, is a nightmare to manage. I'm personally fond of PHP, after hating it with a vengeance for a few years — way before we even had classes in PHP, much less the plethora of goodies that are available today. However, I totally agree that there were lots of bad language decisions; and now the core developers are effectively forcing developers to start tidying up their code, or it simply won't run under PHP 8.0. I think that PHP 5.6 was a turning point: a clear message telling PHP developers that the days of sloppiness were over, and a 'last chance' to read all those warnings in the logs before moving on to PHP 7 and beyond...
But the truth is that I started to appreciate PHP because of lazy programming! Here was a language that allowed you to write code very quickly, without even bothering with boring details such as declaring variables. This approach works well while a language's syntax is very simple — which was true for PHP in the early days. I mean, if you have just a handful of types, all of which can be converted into each other, well, then you can allow lazy programming. The problem came only when the PHP core developers wanted to add all those nifty features that were available on other programming languages. And I agree that JS followed the same path (thus, TS). Actually, we ought to have 'Typed PHP' at some point in time, too; on the other hand, it looks like PHP is moving in that direction by leaps and bounds...
As for Java, I'm still sticking to my first point: I certainly believe that some people can get good enough performance out of it, and possibly keep all their dependencies in order (using Maven or whatever tool is popular today), therefore combining the advantages of a complex language designed to tackle complex problems with a predictable development pipeline ('predictable' in the sense that you can rely that, during, say, a five-year project, you will still be able to run the code you started writing, while still keeping all those hundreds or thousands of dependencies up-to-date with the latest security and performance patches).
But my comments were based on the assumption that it's next-to-impossible to accomplish that — an assumption grounded on my own experience, which, granted, is extremely limited, and was uniformally bad. My worst nightmares actually came from Java applications that people specified as the 'best' choice because, well, Java works universally on any device that implements a JVM, right?... That's what it says on the box (see the comment by @greenroommate below: the selling point of Java has always been 'compile once, run everywhere'). In practice, there hasn't been a single Java project that I had to deploy which hadn't some impossible-to-resolve dependency issues (Maven or no Maven...); and when complaining to the developers that their application didn't run under, say, FreeBSD, they would just shrug and comment that they never recommended deployment on anything outside the Windows or Linux worlds...
I certainly understand that there are many reasons for such choices; if 99% of your market runs their Java applications in a very strict and controlled environment — a very specific platform, with precisely defined characteristics such as the kind of system libraries that have been installed — it's reasonable to assume that if you're attempting to run it on anything else will not work. But that defeats the whole purpose of using Java in the first place.
Now you can argue that the same is true for all the other languages (and especially so for the natively compiled ones), at least to a degree, and I would certainly agree with you on that, but that's not really the point. The point is that a regular human being will be always hard-pressed to get a Java application to run efficiently and with adequate performance on whatever platform they happen to have. In other words, the time eventually saved by Java developers in producing cross-platform code in the first place (not needing to worry about eventual differences between systems, since they write code to be compiled and run under a JVM) is then spent by those who need to deploy such code on a platform that is theoretically supported (in the sense that there is an available JVM for it) but in practice never works, or only works by taking up a huge amount of resources, or requires a complex setup which will only work for any Java application running on that particular system to the exclusion of anything else; my 'bad' experience with Java comes from all those cases, happening over and over again, and which even seem to get worse over time (but I admit that this can be just my perception).
By contrast, other developers do not even bother with 'cross-platform code' — they just ship a Docker container. I have my issues with the whole Docker concept, but that's another story. The point is that if you 'need' a very specific instance of a virtual machine to run your application, then why bother with using a so-called cross-platform language, when all you need is to develop your application in whatever language and environment you prefer and simply put it inside some sort of virtual machine (such as Docker) instead?
On one hand, I never benchmarked such a trade-off, between writing something in Java and expecting it to run everywhere, or writing it in whatever language you prefer, and get it running under a Docker container instead. Maybe a Java application will beat anything else that requires a virtual machine (or, if you prefer, perhaps the JVM is the most performant of all VMs out there). I simply don't know, I just have personal (and therefore subjective) perceptions based on my (limited) experience.
Some years back, there was a discussion around a specific application I've used which had been painfully ported from Windows to macOS, running natively on both, at the cost of thousands of development hours, plus the extra hours of ongoing maintenance to keep the code in sync. This was not a simple application using, say, Qt, or some similar cross-platform toolset/framework. Rather, everything had been done from scratch, in both platforms. There was a small contigent of Linux users who argued that they would also like to be able to run that application as well; and if it had been succesfully ported to macOS, then it would be very likely much easier to port it to Linux as well. It wasn't, and for many years, the developers refused to even consider to 'waste' more development time just to create from scratch a third codebase. Ironically, or perhaps not, at some point they actually did release a Linux version... but this was 2007 or 2008, and the iPhone (and the first Android phones) had just been launched, and, consequently, people were asking when they would have a native version of the application on their iPhones as well, even with limited functionality... we're still waiting for that in 2021!
It might be argued that if the application had been developed in Java (and not C#/Objective-C), it might have been much easier to port it to whatever technology becomes fashionable. It's not as if that company's developers did not know how to develop in Java — they most certainly did! — but rather because they were afraid of whatever performance hits they'd get from that approach, and, more importantly, they knew it would be a very hard task to give reasonable tech support to next-to-clueless new users, teaching them how to properly configure their Java environment just to run that single instance of the application.
Back then, all I could remember was the hard lesson given by Triple-A game developers: if you wish to avoid performance issues, just statically compile everything in C/C++...
Now I can see that many issues you had where history related. You mention docker but then also not working on FreeBSD or such. Most of these things are not there anymore given docker, fatJars and recent movement towards using less reflection but mainly new versions of Java and JVM. I don't really understand people dragging old issues. It's like saying C# is bad because you need Windows yet here we are in 2021. So yes there was a lot of bad things in Java libraries, for example I personally can mention writting desktop app in Java but for usage with MS SQL Server 2008. Yeah, .jar libs had DLLs inside of them as a driver which meant Windows only. So is that JVM not running or people doing dumb stuff? Why, write, put a DLL and do a call to native driver? That's what was wrong.
But to put it in perspective, node modules are heavier than the black hole and Node sucks up way more resources on big processing where data is not 2KB JSON but 1GB and such. It's simply incorrect that it drains nore resources than Node or such. Maybe true in simple cases with smaller data. There's a use case for everything. They also, as I said have way too many ports from rust and c. So does Python, so does PHP. So bashing Java for it you bash those languages as well. As to why it's hard to accept that this is the case with others but easy to hate Java beats me.
I have enormous amount of porting problems today with PHP apps and as a solution we're rewiring it into something that can be put in docker easily. And yes some of it is Java. And first thing to notice is usage of 1.8 while we're in te year od 17 being stable soon. Why do people do this beats me.
Overall, there is a lot of porting issues with some Java libs as I explained, and even Go might be better here, it's really unrealistic to ignore same problems you mentioned with other languages. Again I had those with Python, PHP, and Node. Java's main selling point might have been "write once run anywhere" but it's 2021 and we need to compare todays version and point of view.
I really like that someone is able to have a discussion of it and I'm not defending Java as I have a lot of complaints about it as well but JVM is at the bottom of it and it's resource consumption. I just don't like being too unrealistic and ignoring that a lot of things have same problems so I comment.