7 ms·

In my opinion, Java as a web language is good when you don't need to really understand what's happening (like in low-traffic situations). If concurrency isn't a

In my opinion, Java as a web language is good when you don't need to really understand what's happening (like in low-traffic situations). If concurrency isn't an issue, then the massive amount of libraries can help you a lot. In high-traffic environments, that ignorance punishes you. I've always felt Java and the JVM are of the mindset that you need a Ph.D. to even understand how it works or how to configure it, and if you can't get it, then you're just a bad programmer. You need to know if you're blocking threads, if there's memory contention, and if libraries you pull in are using the forkjoin common pool (which you're likely using as a default threadpool). And when something blows up, finding the reason (even for any of the above issues) is really tough. You can use flight recorder, heap dumps and gc logs all day, but good luck navigating it all unless you're a genius. I've seen too many devs end up shrugging and hoping the issues are transient. Even figuring out proper threadpool usage isn't straightforward. Look at the number of concurrency abstractions just to model concurrency in your system: https://www.youtube.com/watch?v=yhguOt863nw https://www.youtube.com/watch?v=yhguOt863nw. It's ridiculous. Lots of large tech companies "seem" to "make it work." But if my experience is at all similar, they're just relying on a handful of Ph.D.'s to hold the hands of the rest of the company when it comes to troubleshooting. Part of the reason I fell in love with Elixir/Erlang and the BEAM is that it provides a simple (actor) concurrency model (with a single concurrency primitive, a process) and guardrails (time-slice scheduling) to prevent libraries from shooting you in the foot. OTP's observer makes finding bottlenecks a breeze. For the web, taming concurrency feels way more important than any cpu-crunching perf gains the JVM can give you. I'm too stupid for the JVM; I'll stick to tools that take away numerous categories of complexity and get me closer to mastering my system.

MaxBarraclough 6y ago
In defence of Java, I read somewhere it's 25 years old ;-) Part of the reason for its success has been its strong commitment to backward compatibility, so it's to be expected that it might accumulate many ways of doing things. Python wisdom tells us this is often a Bad Thing. [0] I imagine Java's approach to concurrency and parallelism might be quite different if it were designed today. [0] https://wiki.python.org/moin/TOOWTDI https://wiki.python.org/moin/TOOWTDI
- bandris 6y ago
  Actually BEAM and Erlang pre-dates Java. ;-) As for compatibility: why is Java 8 market share so high in 2020?
  - deleted 6y ago
    [deleted]
  - pjmlp 6y ago
    Shitty Android.
    - cesarb 6y ago
      Isn't Android mostly based on Java 7 (for instance, the Guava artifact you need for Android is the Java 7 one)? It can't be the reason why Java 8 is popular. I believe that the reason why Java 8 is so popular is because there were a lot of backward compatibility problems with Java 9, compounded by the fact that Java 11 (the next LTS after Java 8; both Java 9 and Java 10 had very a very short life) removed many APIs deprecated by Java 9.
      - pjmlp 6y ago
        Nope, Java 8 nowadays. https://developer.android.com/studio/write/java8-support https://developer.android.com/studio/write/java8-support All libraries that matter on the Java eco-system are already on Java 11.
        saagarjha 6y ago
        Android's Java is like half of Java 8 :/
        pjmlp 6y ago
        Yeah, Android Java has turned into Google's own version of J++. Worse is that Kotlin fanboys don't get it, that without access to modern Java their Java FFI is worthless, as all Java 8+ libraries on Maven Central will slowly become useless on Android no matter what. Additionally the language cannot expose JVM capabilities, unless they had even another backend. So it will be stuff like value types, JNI replacement, proper generics, customized JIT and SIMD on the JVM, and plain old Java 8 on ART.
kbrisso 6y ago
I work on a lot of legacy systems in financial services, the biggest issues related to threads is variable scope regarding servlet design patterns. I just migrated a 18 year old app off Weblogic to TomEE and we had issues with struts tags. The main app I work on has around 350 concurrent users. I have JMX on all the time and monitor it for long running threads and tune it when needed. The problem I have with Java is the massive amount of libraries that can be used and developers who copy and paste code and don't think about what the code does. The verbosity kills me too, it's so over done. I've decided to learn Go just because I'm tired of reading Java code, especially legacy code. But yes you are correct there is a lot of settings in the JVM and a lot to read to understand it. It's a powerful language with a lot of features.
- The_rationalist 6y ago
  Regarding the verbosity you would be better off with Kotlin
jacques_chester 6y ago
> You need to know if you're blocking threads, if there's memory contention, and if libraries you pull in are using the forkjoin common pool (which you're likely using as a default threadpool). And when something blows up, finding the reason (even for any of the above issues) is really tough. You can use flight recorder, heap dumps and gc logs all day, but good luck navigating it all unless you're a genius. I've seen the same troubles with alternatives, just without the amazing tools, featuresome standard library or widely-accepted conventions. Erlang is amazing and is places concurrency in a more central position. I'm hopeful Project Loom will greatly diminish the gap while carrying legacy code forward unchanged.
- The_rationalist 6y ago
  There's tooling such as Blockhound
miskin 6y ago
I believe there are few runtimes out there that have such a good monitoring and profiling tools for free and out of the box as Java. Java Flight Recorder, remote debugging and monitoring can be really useful for rare production performance issues.
- lostcolony 6y ago
  It's funny you should mention that in response to a post talking about Erlang. :P Because, yes, there are few. The BEAM happens to be one that definitely beats the JVM on that front.
  - The_rationalist 6y ago
    In which précise aspect does it outperform jvm tooling?
    - lostcolony 6y ago
      So monitoring and profiling are pretty similar in what sort of things they tell you, but the meaningfulness tends to feel higher due to the programming model. Here's a fairly recent blog post giving an example from someone trying the BEAM for the first time, coming from the JVM - https://medium.com/@mrjoelkemp/jvm-struggles-and-the-beam-4d9c58547410 https://medium.com/@mrjoelkemp/jvm-struggles-and-the-beam-4d... But when it comes to remote debugging, and more specifically, a general "I want to understand what is happening in production", the ability to attach a REPL, alongside your tools, is amazing. I can insert a breakpoint, sure (if I for some reason built my production instance with debug info), but just as easily (without any debug info compiled in!), and more usefully, I can query actor state, mailboxes, etc, fire a message to a process to see what happens, etc...all the things you'd get with a REPL running locally in your dev environment, basically. Do stuff like query for internal state for a process, then call a function with it to see what happens to the data, all in isolation from the normal execution flow (since immutable data gives you a degree of safety to actually run that live code, with copies of the live data, and see what happens). I can even remotely load new code, if I want, effectively allowing me to deploy a hotfix without taking the node down. And I can do all of this in prod. All of this is, of course, super dangerous, but with great power etc etc.
apta 6y ago
> If concurrency isn't an issue, then the massive amount of libraries can help you a lot. Can you point to another language that has anything remotely comparable to `java.util.concurrent`? Also, Java is getting green threads by means of Project Loom.
coldtea 6y ago
>In my opinion, Java as a web language is good when you don't need to really understand what's happening (like in low-traffic situations) Huh? Java is used in huge traffic backends, including HFT with minimal latencies acceptable all the way to Google and Twitter scale. If anything, Java is much more fast and low level than the typical languages used for huge high-traffic services -- Rails, Python, etc - never mind about what's used in "low-traffic situations".
- lostcolony 6y ago
  OP isn't comparing it to Rails, Python, etc. He's comparing it to Erlang. ANd, to that, I'd agree. I've built high traffic stuff in Java. We built it, load tested it, it was terrible. After multiple rounds of profiling, tweaking GC settings, tweaking threadpool sizes, rewriting things to be async, finding out that a client library wasn't reusing connections properly, etc, we finally had acceptable performance...that still was less than I'd gotten out of the box in similar, IO bound services, written as unoptimized Erlang.
matsemann 6y ago
I hardly know anything about those things, and write java backends powering one of the most used services in my country. So I disagree with it being that complicated. If you write the service stateless it's incredible what you can achieve with a couple small instances of a default spring boot container.
deepakarora3 6y ago
There are a lot of points which I simply cannot agree with. 1) concurrency as an issue - you make it sound as if doing concurrent programming in Java is hard. Its not if you read through the documentation. In todays world of spinning up small servers, when done right, it scales to massive levels. 2) Blocking threads, memory contention etc. - i think you may be comparing against the likes of single thread programming models like Vert.x or Node.js etc. The flip side which in my opinion is more severe is that if you get even a small thing wrong on the other side, it blows up even more which is more difficult to isolate and debug. Plus the need to learn a whole new programming paradigm which is not easy to wrap your head around. 3) Lot of tech companies seem to make it work - while I agree that corporates will pretty much make everything seem to work, it requires a few engineers who understand software design principles to create design and abstractions that work well. You imply that only PhDs understand that kind of stuff whereas I am sayin that there are many other who understand and who are genuinely making things work in the Java world. I can tell you, when concurrency done right in Java, it is so performance that many will simply not believe. Just my thoughts and happy to differ.
- dnautics 6y ago
  Just try playing around with the other vm for a bit. It's just crazy easy.
jjav 6y ago
> In my opinion, Java as a web language is good when you don't need to really understand what's happening (like in low-traffic situations). If concurrency isn't an issue, then the massive amount of libraries can help you a lot. Not sure how to interpret this comment.. If high concurrency and high performance matter, that is precisely where Java shines. The only other reasonable option would be C++ but it brings so much pain with it that Java is the way to go. If traffic is low and performance doesn't matter (which is most sites), then sure, use whatever favorite scripting language.

MaxBarraclough 6y ago

In defence of Java, I read somewhere it's 25 years old ;-) Part of the reason for its success has been its strong commitment to backward compatibility, so it's to be expected that it might accumulate many ways of doing things. Python wisdom tells us this is often a Bad Thing. [0] I imagine Java's approach to concurrency and parallelism might be quite different if it were designed today. [0] https://wiki.python.org/moin/TOOWTDI https://wiki.python.org/moin/TOOWTDI

bandris 6y ago
Actually BEAM and Erlang pre-dates Java. ;-) As for compatibility: why is Java 8 market share so high in 2020?
- deleted 6y ago
  [deleted]
- pjmlp 6y ago
  Shitty Android.
  - cesarb 6y ago
    Isn't Android mostly based on Java 7 (for instance, the Guava artifact you need for Android is the Java 7 one)? It can't be the reason why Java 8 is popular. I believe that the reason why Java 8 is so popular is because there were a lot of backward compatibility problems with Java 9, compounded by the fact that Java 11 (the next LTS after Java 8; both Java 9 and Java 10 had very a very short life) removed many APIs deprecated by Java 9.
    - pjmlp 6y ago
      Nope, Java 8 nowadays. https://developer.android.com/studio/write/java8-support https://developer.android.com/studio/write/java8-support All libraries that matter on the Java eco-system are already on Java 11.
      - saagarjha 6y ago
        Android's Java is like half of Java 8 :/
        pjmlp 6y ago
        Yeah, Android Java has turned into Google's own version of J++. Worse is that Kotlin fanboys don't get it, that without access to modern Java their Java FFI is worthless, as all Java 8+ libraries on Maven Central will slowly become useless on Android no matter what. Additionally the language cannot expose JVM capabilities, unless they had even another backend. So it will be stuff like value types, JNI replacement, proper generics, customized JIT and SIMD on the JVM, and plain old Java 8 on ART.

kbrisso 6y ago

I work on a lot of legacy systems in financial services, the biggest issues related to threads is variable scope regarding servlet design patterns. I just migrated a 18 year old app off Weblogic to TomEE and we had issues with struts tags. The main app I work on has around 350 concurrent users. I have JMX on all the time and monitor it for long running threads and tune it when needed. The problem I have with Java is the massive amount of libraries that can be used and developers who copy and paste code and don't think about what the code does. The verbosity kills me too, it's so over done. I've decided to learn Go just because I'm tired of reading Java code, especially legacy code. But yes you are correct there is a lot of settings in the JVM and a lot to read to understand it. It's a powerful language with a lot of features.

The_rationalist 6y ago
Regarding the verbosity you would be better off with Kotlin

jacques_chester 6y ago

> You need to know if you're blocking threads, if there's memory contention, and if libraries you pull in are using the forkjoin common pool (which you're likely using as a default threadpool). And when something blows up, finding the reason (even for any of the above issues) is really tough. You can use flight recorder, heap dumps and gc logs all day, but good luck navigating it all unless you're a genius. I've seen the same troubles with alternatives, just without the amazing tools, featuresome standard library or widely-accepted conventions. Erlang is amazing and is places concurrency in a more central position. I'm hopeful Project Loom will greatly diminish the gap while carrying legacy code forward unchanged.

The_rationalist 6y ago
There's tooling such as Blockhound

miskin 6y ago

I believe there are few runtimes out there that have such a good monitoring and profiling tools for free and out of the box as Java. Java Flight Recorder, remote debugging and monitoring can be really useful for rare production performance issues.

lostcolony 6y ago
It's funny you should mention that in response to a post talking about Erlang. :P Because, yes, there are few. The BEAM happens to be one that definitely beats the JVM on that front.
- The_rationalist 6y ago
  In which précise aspect does it outperform jvm tooling?
  - lostcolony 6y ago
    So monitoring and profiling are pretty similar in what sort of things they tell you, but the meaningfulness tends to feel higher due to the programming model. Here's a fairly recent blog post giving an example from someone trying the BEAM for the first time, coming from the JVM - https://medium.com/@mrjoelkemp/jvm-struggles-and-the-beam-4d9c58547410 https://medium.com/@mrjoelkemp/jvm-struggles-and-the-beam-4d... But when it comes to remote debugging, and more specifically, a general "I want to understand what is happening in production", the ability to attach a REPL, alongside your tools, is amazing. I can insert a breakpoint, sure (if I for some reason built my production instance with debug info), but just as easily (without any debug info compiled in!), and more usefully, I can query actor state, mailboxes, etc, fire a message to a process to see what happens, etc...all the things you'd get with a REPL running locally in your dev environment, basically. Do stuff like query for internal state for a process, then call a function with it to see what happens to the data, all in isolation from the normal execution flow (since immutable data gives you a degree of safety to actually run that live code, with copies of the live data, and see what happens). I can even remotely load new code, if I want, effectively allowing me to deploy a hotfix without taking the node down. And I can do all of this in prod. All of this is, of course, super dangerous, but with great power etc etc.

apta 6y ago

> If concurrency isn't an issue, then the massive amount of libraries can help you a lot. Can you point to another language that has anything remotely comparable to `java.util.concurrent`? Also, Java is getting green threads by means of Project Loom.

coldtea 6y ago

>In my opinion, Java as a web language is good when you don't need to really understand what's happening (like in low-traffic situations) Huh? Java is used in huge traffic backends, including HFT with minimal latencies acceptable all the way to Google and Twitter scale. If anything, Java is much more fast and low level than the typical languages used for huge high-traffic services -- Rails, Python, etc - never mind about what's used in "low-traffic situations".

lostcolony 6y ago
OP isn't comparing it to Rails, Python, etc. He's comparing it to Erlang. ANd, to that, I'd agree. I've built high traffic stuff in Java. We built it, load tested it, it was terrible. After multiple rounds of profiling, tweaking GC settings, tweaking threadpool sizes, rewriting things to be async, finding out that a client library wasn't reusing connections properly, etc, we finally had acceptable performance...that still was less than I'd gotten out of the box in similar, IO bound services, written as unoptimized Erlang.

matsemann 6y ago

I hardly know anything about those things, and write java backends powering one of the most used services in my country. So I disagree with it being that complicated. If you write the service stateless it's incredible what you can achieve with a couple small instances of a default spring boot container.

deepakarora3 6y ago

There are a lot of points which I simply cannot agree with. 1) concurrency as an issue - you make it sound as if doing concurrent programming in Java is hard. Its not if you read through the documentation. In todays world of spinning up small servers, when done right, it scales to massive levels. 2) Blocking threads, memory contention etc. - i think you may be comparing against the likes of single thread programming models like Vert.x or Node.js etc. The flip side which in my opinion is more severe is that if you get even a small thing wrong on the other side, it blows up even more which is more difficult to isolate and debug. Plus the need to learn a whole new programming paradigm which is not easy to wrap your head around. 3) Lot of tech companies seem to make it work - while I agree that corporates will pretty much make everything seem to work, it requires a few engineers who understand software design principles to create design and abstractions that work well. You imply that only PhDs understand that kind of stuff whereas I am sayin that there are many other who understand and who are genuinely making things work in the Java world. I can tell you, when concurrency done right in Java, it is so performance that many will simply not believe. Just my thoughts and happy to differ.

dnautics 6y ago
Just try playing around with the other vm for a bit. It's just crazy easy.

jjav 6y ago

> In my opinion, Java as a web language is good when you don't need to really understand what's happening (like in low-traffic situations). If concurrency isn't an issue, then the massive amount of libraries can help you a lot. Not sure how to interpret this comment.. If high concurrency and high performance matter, that is precisely where Java shines. The only other reasonable option would be C++ but it brings so much pain with it that Java is the way to go. If traffic is low and performance doesn't matter (which is most sites), then sure, use whatever favorite scripting language.