61–70 of 122 posts
Earlier quoted context omitted.
Have you ever seen how many GCC has for plain old C?
Yeah, that’s a mistake too, and a big reason for why compiling C projects is such a pain. Notice how I did not compare to C, but modern alternatives.
All of that configuration and it will always be less efficient than Rust, or even Golang. This is why lots of engineers waste time fiddling with options to tune the JVM and still require hundreds of replicated micro-services to "scale" their backends and losing money on AWS and when they will never admit the issue is the technology they have chosen (Java) and why AWS loves their customers using inefficient and expens…
I was a diehard java fanboy but using Rust in the last 5 years more and more I have to agree, but sadly huge Java corporate codebases keep my bills paid still, so I have to deal with it. It is what it is. Also agree the pipeline etc. they love all the waste of the compute in their pocket.
Development velocity is way greater in Java.
Earlier quoted context omitted.
Wasn't it Joel Spolsky who said every option is a cop out? Or maybe Steve Yegge? I forget. It's something I agree with. I often have this thought when going through the options of something conceptually fairly simple: "who is this for? who actually uses this option?" I kinda feel the same way with C/C++ warnings. Different code bases decide if different warnings are errors. That was a mistake (IMHO). The other though…
Joe Spolsky also never created anything as popular and widely deployed as Java. It's easy to bloviate about pure software when it doesn't need to literally run the whole world as you know it.
Earlier quoted context omitted.
GC threads are generally often useful on multi-tenant systems or machines with many cores, as Java will default-size its thread pools according to the number of logical cores. If the server has 16 or more cores, that's very rarely something you want, especially if you run multiple JVMs on the same host. Not JVM options, but these are often also good to tune: -Djdk.virtualThreadScheduler.parallelism -Djdk.virtualThrea…
You can get into difficulty with kubernetes here, as your jvm will detect all cores on the node but you may have set a resources limit on the pod/whatever, so it’ll assume it can spend more time doing stuff than it actually can, so often times it’s quite necessary to tune some things to prevent excessive switching etc.
Earlier quoted context omitted.
Joe Spolsky also never created anything as popular and widely deployed as Java. It's easy to bloviate about pure software when it doesn't need to literally run the whole world as you know it.
Er. IIRC, Spolsky was involved in creating VBA for Excel. Which was arguably orders of magnitude more popular (and still more widely deployed and world-supporting) than Java.
Earlier quoted context omitted.
Have you ever seen how many GCC has for plain old C?
Yeah, that’s a mistake too, and a big reason for why compiling C projects is such a pain. Notice how I did not compare to C, but modern alternatives.
Earlier quoted context omitted.
gofmt isn’t really comparable to the JVM, but it is a really strong expression of the opinionated tooling GoLang has. While gofmt is “just” a formatting tool. The interesting part is that go code that doesn’t follow the go formatting standard is rejected by the go compiler. So not only does gofmt not have knobs, you can’t even fork it to add knobs, because the rest of the go ecosystem will outright reject code format…
That's all well and good, but entirely irrelevant to the number of options a JVM should reasonably have.
(I know many conflict and there is not a shell buffer long enough to handle all that)
Kidding aside, I actually said "ugh, seriously" when I saw that there were literally thousands of options. Is there a public program with more options?
Earlier quoted context omitted.
All of that tooling and Rust will always be less efficient than Assembler.
I… didn’t think this makes sense :)
Earlier quoted context omitted.
It's a result of Java being required to run on many different OS environments (Oracle, Redhat, Windows, RISC/ARM/x86), along with user constraints and also business requirements. In a way you can use this list of JVM options to illustrate how successful Java has become, that everyone needs an option to get it to work how they like it. As a Java dev, I have maybe used about 10-15 of them in my career. The weirdest/fun…
> As a Java dev, I have maybe used about 10-15 of them in my career. So do we really need multiple thousand? Having all of them also makes finding the few you actually need much more difficult.