31–40 of 69 posts
Interesting. All this time I have a perception that Java app is slow as hell. What a terribly wrong assumption. Color me impressed.
While I don't necessarily agree with everything in it (like Gradle builds), it's interesting to look at.
Interesting. All this time I have a perception that Java app is slow as hell. What a terribly wrong assumption. Color me impressed.
Once you heat up the JVM, Java can run like a bat out of hell. And, if you don't run into GC problems, it's as fast as anything out there.
Go has a significantly smaller memory usage in all of the benchmarks, often by a factor of 10x. For most workloads, this can have a huge impact on when you need to spend more money to support your business.
It also has a large impact on how often the GC is run. Less memory used, less GC performed.
Earlier quoted context omitted.
Well, a lot of Java web apps ARE slow as hell, but one can't really blame Java-the-language (or the JVM) for it. Two examples from my experience: JSF is doing lots of "magic" trying to keep state. It isn't exactly quick to render a simple hello world page, but if you mess up the state on a somewhat complex page, JSF spends ages in it's six (yes, six!) lifecycle stages [0]. Hibernate is probably the worst offender. We…
What's wrong with having six lifecycle stages? I don't use JSF (or Java) but I can understand the usefulness of having several lifecycle methods assuming you can hook into them and add your own custom logic. The more lifecycle stages the more precisely you can choose when during the request processing your custom logic should be invoked.
I find these benchmarks slightly dubious because everytime I look into the actual code I find that is written some obscure manner. For example - here is the code of the Java "knucleotide" benchmark: http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... (If I understand the website correctly.) Look at the way data is read (scanPastHeader, readRestIntoByteArray, fullSequence). Or how the result of calculateHa…
This benchmark is out of date almost immediately because of the patch level of the Java runtime and the Golang compilers change frequently. I was half thinking of creating a VB6 module for LLVM just as a tongue in cheek joke of taking a language with a slow runtime and effectively strapping a V8 engine to it, but I saw someone already did most of the work: https://github.com/microcai/llvm-qbasic
1) Changing patchlevels causing huge performance differences. 2) Those "patchlevels" being immediately deployable to production in the real world.
Neither is true, so you don't have an argument.
Interesting. All this time I have a perception that Java app is slow as hell. What a terribly wrong assumption. Color me impressed.
Well, a lot of Java web apps ARE slow as hell, but one can't really blame Java-the-language (or the JVM) for it. Two examples from my experience: JSF is doing lots of "magic" trying to keep state. It isn't exactly quick to render a simple hello world page, but if you mess up the state on a somewhat complex page, JSF spends ages in it's six (yes, six!) lifecycle stages [0]. Hibernate is probably the worst offender. We…
[1]: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/p...
Look, Java is my right hand language, and I've never written a single line of Go in my life. But this is kind of unfair I think... the OpenJDK JVM has 20 years of development behind it, and has probably had mountains of money sunk into tuning f* out of it by the biggest most enterprisy players in the game. I'm sure that there is a lot of low hanging fruit for Go to grab at to improve performance, and most likely will…
"Fair" to companies considering Go right now? Absolutely. If you're deploying a production system, you go to war with the army you have.
Earlier quoted context omitted.
Probably part of it, but for me, the somewhat uncanny valley-ish non-standard look and behaviour of Swing UIs (and AWT before that) is the biggest turn off. Using java apps on the desktop feels a little like using a keyboard with mittens.
This is an issue of unskilled devs using ancient UI design approach, usually not even bothering with skinning it. Things like bitTorrent were done in Java (correct me if I'm wrong), and you have no clue which language they are done in when looking at UI. But this a bit of extra effort, and for intranet apps, nobody usually bothers. Another reason for oh-not-so-windows-look of UI is something microsoft finally begun d…
Kind of an unfair comparison - the Python one just calls native Qt or Tk whereas the Java UI is actually written in Java - but it does colour the perception.
Look, Java is my right hand language, and I've never written a single line of Go in my life. But this is kind of unfair I think... the OpenJDK JVM has 20 years of development behind it, and has probably had mountains of money sunk into tuning f* out of it by the biggest most enterprisy players in the game. I'm sure that there is a lot of low hanging fruit for Go to grab at to improve performance, and most likely will…
I don't think it is that unfair. From my perspective the JVM hasn't seen major performance changes since the early days e.g. Java 4. All of the major improvements have come in the library space e.g. LMAX Disruptor, OpenHFT, Javolution.
They ship new optimisations in more or less every release. I'm not sure what workload you do that you've never seen performance improvements.
For example in Java 9 they're going to ship auto-vectorisation for certain kinds of functional / parallel stream construct.