4 ms·

The reason Java has been so successful is that avoiding memory errors is far more important than being fast. Once you have removed the possibility of those erro

by ynniv 8y ago

The reason Java has been so successful is that avoiding memory errors is far more important than being fast. Once you have removed the possibility of those errors, being fast is still valuable, which is how we end up with people spending so much time optimizing their Java instead of switching to C. It's more likely that people will switch to OCaml or Rust than ever go back to unmanaged memory. First secure, then correct, then fast.

pron 8y ago
In case you haven't watched the talk, people don't spend so much time optimizing Java; on the contrary, Java is often faster than C/C++ without optimization effort. It does have a lower ceiling, but as he says, if you need to be faster than Java (for the uses he talks about), then you're better off going FPGA than another language, because that's the only way to gain a very significant boost.
- deleted 8y ago
  [deleted]
- jplayer01 8y ago
  Huh? People don't have to put in that effort because there are companies who have invested crazy amounts of man hours and time and money into engineering the JVM to be what it is today. Java is only as fast as it is because there are people who've put in that effort. Java's reputation for being slow isn't unwarranted - it just isn't true anymore.
  - projectileboy 8y ago
    I think what s/he meant is that app developers don’t have to spend time on optimization (because - as you point out - so many smart people have spent so much time making the JVM as fast as possible).
- smolder 8y ago
  Most developers of Java I've encountered don't know the first thing about optimization and manage to make some really suboptimal stuff despite the supposed ease of achieving near-best performance. I spent a fair amount of time actually benchmarking and iterating on code to make java programs perform better in college, because thankfully they considered that a useful skill. What I see in practice in industry is architectural patterns that supposedly support maintainability at a great cost to performance, with the concrete parts being written by people who don't have any idea what the performance characteristics of the code they're writing are and why. I think Java has a lot of merit, but it also has an "ecosystem" rife with bloated, dogmatic, hyper-abstracted code that was never really given a thought about optimality and requires purchasing big servers with lots of RAM. As good at it is, and yes, it was and is good in the grand scheme; I'm disappointed that Java still has so much inertia, and that development and adoption of alternatives is so slow going. I feel as if there is a "it's good enough, why change anything" attitude that stems from lack of understanding that there are still big juicy low hanging fruit to be found and incorporated into our tools, to ultimately make software better AND easier to write/maintain. The line about "lots of smart people have been optimizing the JVM for a long time" seems like a go-to defense of what I see as stagnation.
  - pron 8y ago
    > Most developers of Java I've encountered Java has about 10M developers, who do everything from developing banking systems, GMail, Netflix, to people writing avionics, air-trafic and weapons control, and manufacturing control. Even 1% of Java developers is more than many language's entire ecosystems. > I think Java has a lot of merit, but it also has an "ecosystem" rife with bloated, dogmatic, hyper-abstracted code that was never really given a thought about optimality and requires purchasing big servers with lots of RAM. Again, it's really hard to generalize with such a diverse ecosystem. 1% of Java developers is still ~100K developers. > that stems from lack of understanding that there are still big juicy low hanging fruit to be found and incorporated into our tools I'm not sure there are, but if so -- go ahead and prove it. > The line about "lots of smart people have been optimizing the JVM for a long time" seems like a go-to defense of what I see as stagnation. Well, as one of the many people working on OpenJDK, I won't comment on that :)
- willtim 8y ago
  Getting good performance out of Java is not always easy. One often has to structure code imperfectly to get efficient branching (Java offers only vtable dispatch or switch on integers/enums). It also boxes nearly all values leading to cache inefficient pointer chasing. These problems can be avoided, but you'll be working against the language.
  - pron 8y ago
    I am not sure where you're getting these things. Unlike C++, Java can and does inline virtual calls. Also, it boxes nearly all values?
    - willtim 8y ago
      I am "getting these things" from over a decade of working with Java. There are many good things about Java, especially when compared to C++. But the bad things will never get fixed if we pretend everything is perfect. I did say vtable dispatch was efficient, but I might not want to split my logic across classes. A chain of if-else is a linear scan and not efficient. Switch in its current form is too limited. It is well known that Java has no value types (there is a JSR). Even for a primitive type, the collection libraries need to box all values in order to abstract the element type. Every HFT user on Wall Street has had to write their own collections library using custom code generation to work around this.
  - atulatul 8y ago
    -- switch on integers/enums Strings in switch Statements: https://docs.oracle.com/javase/7/docs/technotes/guides/language/strings-switch.html https://docs.oracle.com/javase/7/docs/technotes/guides/langu...
    - willtim 8y ago
      Not sure that really makes up for the lack of sum types! Supporting a switch on static final references would be a good first step.
  - imtringued 8y ago
antisthenes 8y ago
> It's more likely that people will switch to OCaml or Rust than ever go back to unmanaged memory. First secure, then correct, then fast. Interestingly enough, that's a philosophy that's valuable and applicable in other skill sets as well. Woodworking/machining comes to mind and other trades. Safety/security first, then precision, then speed once you got the other 2 working.
- jacques_chester 8y ago
  It's the Vitruvian Triad: firmitatis, utilitatis, venustatis. Make it safe, make it useful, make it beautiful, in that order.

by ynniv 8y ago

pron 8y ago

In case you haven't watched the talk, people don't spend so much time optimizing Java; on the contrary, Java is often faster than C/C++ without optimization effort. It does have a lower ceiling, but as he says, if you need to be faster than Java (for the uses he talks about), then you're better off going FPGA than another language, because that's the only way to gain a very significant boost.

deleted 8y ago
[deleted]
jplayer01 8y ago
Huh? People don't have to put in that effort because there are companies who have invested crazy amounts of man hours and time and money into engineering the JVM to be what it is today. Java is only as fast as it is because there are people who've put in that effort. Java's reputation for being slow isn't unwarranted - it just isn't true anymore.
- projectileboy 8y ago
  I think what s/he meant is that app developers don’t have to spend time on optimization (because - as you point out - so many smart people have spent so much time making the JVM as fast as possible).
smolder 8y ago
Most developers of Java I've encountered don't know the first thing about optimization and manage to make some really suboptimal stuff despite the supposed ease of achieving near-best performance. I spent a fair amount of time actually benchmarking and iterating on code to make java programs perform better in college, because thankfully they considered that a useful skill. What I see in practice in industry is architectural patterns that supposedly support maintainability at a great cost to performance, with the concrete parts being written by people who don't have any idea what the performance characteristics of the code they're writing are and why. I think Java has a lot of merit, but it also has an "ecosystem" rife with bloated, dogmatic, hyper-abstracted code that was never really given a thought about optimality and requires purchasing big servers with lots of RAM. As good at it is, and yes, it was and is good in the grand scheme; I'm disappointed that Java still has so much inertia, and that development and adoption of alternatives is so slow going. I feel as if there is a "it's good enough, why change anything" attitude that stems from lack of understanding that there are still big juicy low hanging fruit to be found and incorporated into our tools, to ultimately make software better AND easier to write/maintain. The line about "lots of smart people have been optimizing the JVM for a long time" seems like a go-to defense of what I see as stagnation.
- pron 8y ago
  > Most developers of Java I've encountered Java has about 10M developers, who do everything from developing banking systems, GMail, Netflix, to people writing avionics, air-trafic and weapons control, and manufacturing control. Even 1% of Java developers is more than many language's entire ecosystems. > I think Java has a lot of merit, but it also has an "ecosystem" rife with bloated, dogmatic, hyper-abstracted code that was never really given a thought about optimality and requires purchasing big servers with lots of RAM. Again, it's really hard to generalize with such a diverse ecosystem. 1% of Java developers is still ~100K developers. > that stems from lack of understanding that there are still big juicy low hanging fruit to be found and incorporated into our tools I'm not sure there are, but if so -- go ahead and prove it. > The line about "lots of smart people have been optimizing the JVM for a long time" seems like a go-to defense of what I see as stagnation. Well, as one of the many people working on OpenJDK, I won't comment on that :)
willtim 8y ago
Getting good performance out of Java is not always easy. One often has to structure code imperfectly to get efficient branching (Java offers only vtable dispatch or switch on integers/enums). It also boxes nearly all values leading to cache inefficient pointer chasing. These problems can be avoided, but you'll be working against the language.
- pron 8y ago
  I am not sure where you're getting these things. Unlike C++, Java can and does inline virtual calls. Also, it boxes nearly all values?
  - willtim 8y ago
    I am "getting these things" from over a decade of working with Java. There are many good things about Java, especially when compared to C++. But the bad things will never get fixed if we pretend everything is perfect. I did say vtable dispatch was efficient, but I might not want to split my logic across classes. A chain of if-else is a linear scan and not efficient. Switch in its current form is too limited. It is well known that Java has no value types (there is a JSR). Even for a primitive type, the collection libraries need to box all values in order to abstract the element type. Every HFT user on Wall Street has had to write their own collections library using custom code generation to work around this.
- atulatul 8y ago
  -- switch on integers/enums Strings in switch Statements: https://docs.oracle.com/javase/7/docs/technotes/guides/language/strings-switch.html https://docs.oracle.com/javase/7/docs/technotes/guides/langu...
  - willtim 8y ago
    Not sure that really makes up for the lack of sum types! Supporting a switch on static final references would be a good first step.
- imtringued 8y ago

antisthenes 8y ago

> It's more likely that people will switch to OCaml or Rust than ever go back to unmanaged memory. First secure, then correct, then fast. Interestingly enough, that's a philosophy that's valuable and applicable in other skill sets as well. Woodworking/machining comes to mind and other trades. Safety/security first, then precision, then speed once you got the other 2 working.

jacques_chester 8y ago
It's the Vitruvian Triad: firmitatis, utilitatis, venustatis. Make it safe, make it useful, make it beautiful, in that order.