4 ms·

That would depend a lot on what kind of large project you are building. As an example, Java is unusable for any project that requires high speed processing or h

That would depend a lot on what kind of large project you are building. As an example, Java is unusable for any project that requires high speed processing or highly accurate timing. Also, there's a HUGE overhead that comes from wiring together and maintaining the runtime environment. The extra hours that you need to spend to find the exact combination of frameworks, servers, JDK version, etc to just get the project to run is something quite unique to Java. And then you need to keep it all up to date and secure. Sometimes those hours are justified, but they can definitely be a factor when you are determining the best language for some particular project.

mrkeen 4y ago
> Also, there's a HUGE overhead that comes from wiring together and maintaining the runtime environment. Yes the runtime bugs me too, but I think your complaints are about dependencies in general, not just Java dependencies.
- thaanpaa 4y ago
  In theory, yes, but in practice Java EE is more complex than anything else by orders of magnitude. (We were talking about large projects, I believe.)
kaba0 4y ago
> As an example, Java is unusable for any project that requires high speed processing or highly accurate timing. That is absolutely false. There is a huge list of already existing high-performance projects written in Java, used from HFT to distributed computations. Code using primitives (and thus actually comparing apples to apples) JIT compile down to just as efficient and performant code as what you would get with C. Applications reliant on dynamic allocations may very well come out ahead low-level languages due to its killer GCs vs mallocing left and right. (And no, not everything is replaceable with strict nested lifetimes a la Rust, and (atomic) reference counting is slow as hell. Nor is everything replaceable with arenas). > Also, there's a HUGE overhead that comes from wiring together and maintaining the runtime environment Do you even talk about Java? You literally just download a jdk and run the program. That works for 90% of the time (you can literally download 20 years old jars from some long-dead university professor’s website and it will just work). There are minor nits, but if you use the same jdk version it was meant to be used with it is literally dirt-easy. I don’t see how dynamic libs dependency hell is any easier to manage.
- thaanpaa 4y ago
  Nice condesending tone you have there. Where Java will never be seen: - equipment in hospital operating rooms - aircraft flight control systems - anywhere where you need clock cycle level precision (e.g. scientific measurement) - any system where there can be inopportune moments when garbage collection absolutely can't start You mentioned speed of dynamic allocation. First of all, there are standards which prohibit any kind of dynamic memory allocation. Car computers are a popular example. Second of all, what do you think JVM uses under the hood? Magic? That last paragraph kind of suggests to me that you have never needed to develop any kind of large Java EE project. For any team that I've worked with, it has usually taken from weeks to months to first research and then configure an acceptable stack that actually plays well together. Think Apache Web Server, JBoss (that shipped with some version of Hibernate), DB connection pooling, all kind of caching, dependency injection, interfacing with the outside world, web frontend tech, socket connections; and whatever build tools happened to be in fashion at that time (mvn, gradle and there plugin ecosystems). And then the truckload of XML that goes with getting it all to work together. And then you have to sort out all the "The server JVM has run out of PermGen space", and "totally getting crushed under CPU load when the garbage collector decided to fire away at the worst possible instant", and the "weird exceptions under the hood that give you absolutely no clue why they are happening", and the "JNDI DB pool isn't releasing connections", and the "requests aren't getting distributed to workers correctly" and all the other fun stuff to work out. Usually when there are 10000 users hitting your service all at once, and after 3 hours of googling you find out that you needed to put ncvd:if="cfrog" instead of ncvd:fi="frogc" in mfnbooblah.xml, which by the way since version 47 or gobbldygook needs to be put in the app folder instead of the resources folder. Because that's obviously more betterer and enterprisier. Do you even talk about Java?

mrkeen 4y ago

> Also, there's a HUGE overhead that comes from wiring together and maintaining the runtime environment. Yes the runtime bugs me too, but I think your complaints are about dependencies in general, not just Java dependencies.

thaanpaa 4y ago
In theory, yes, but in practice Java EE is more complex than anything else by orders of magnitude. (We were talking about large projects, I believe.)

kaba0 4y ago

> As an example, Java is unusable for any project that requires high speed processing or highly accurate timing. That is absolutely false. There is a huge list of already existing high-performance projects written in Java, used from HFT to distributed computations. Code using primitives (and thus actually comparing apples to apples) JIT compile down to just as efficient and performant code as what you would get with C. Applications reliant on dynamic allocations may very well come out ahead low-level languages due to its killer GCs vs mallocing left and right. (And no, not everything is replaceable with strict nested lifetimes a la Rust, and (atomic) reference counting is slow as hell. Nor is everything replaceable with arenas). > Also, there's a HUGE overhead that comes from wiring together and maintaining the runtime environment Do you even talk about Java? You literally just download a jdk and run the program. That works for 90% of the time (you can literally download 20 years old jars from some long-dead university professor’s website and it will just work). There are minor nits, but if you use the same jdk version it was meant to be used with it is literally dirt-easy. I don’t see how dynamic libs dependency hell is any easier to manage.

thaanpaa 4y ago
Nice condesending tone you have there. Where Java will never be seen: - equipment in hospital operating rooms - aircraft flight control systems - anywhere where you need clock cycle level precision (e.g. scientific measurement) - any system where there can be inopportune moments when garbage collection absolutely can't start You mentioned speed of dynamic allocation. First of all, there are standards which prohibit any kind of dynamic memory allocation. Car computers are a popular example. Second of all, what do you think JVM uses under the hood? Magic? That last paragraph kind of suggests to me that you have never needed to develop any kind of large Java EE project. For any team that I've worked with, it has usually taken from weeks to months to first research and then configure an acceptable stack that actually plays well together. Think Apache Web Server, JBoss (that shipped with some version of Hibernate), DB connection pooling, all kind of caching, dependency injection, interfacing with the outside world, web frontend tech, socket connections; and whatever build tools happened to be in fashion at that time (mvn, gradle and there plugin ecosystems). And then the truckload of XML that goes with getting it all to work together. And then you have to sort out all the "The server JVM has run out of PermGen space", and "totally getting crushed under CPU load when the garbage collector decided to fire away at the worst possible instant", and the "weird exceptions under the hood that give you absolutely no clue why they are happening", and the "JNDI DB pool isn't releasing connections", and the "requests aren't getting distributed to workers correctly" and all the other fun stuff to work out. Usually when there are 10000 users hitting your service all at once, and after 3 hours of googling you find out that you needed to put ncvd:if="cfrog" instead of ncvd:fi="frogc" in mfnbooblah.xml, which by the way since version 47 or gobbldygook needs to be put in the app folder instead of the resources folder. Because that's obviously more betterer and enterprisier. Do you even talk about Java?