6 ms·

Performance. There's a very good reason why low-latency and high performance computing crowd don't use inventions like Scala or Kotlin but they do use Java. Y

Performance. There's a very good reason why low-latency and high performance computing crowd don't use inventions like Scala or Kotlin but they do use Java. Yes, they all run on the same JVM but most of the nice features and syntactic sugar comes at a price of generating huge amounts of garbage. It's possible to achieve zero- or low-allocating code with almost fully idiomatic Java but not so much with the alternatives.

weego 5y ago
Those people are a frankly unimportant niche in the JVM world. Even in areas where its relevant (banking etc) 99%+ of the codebase is not coded for those tolerances.
- bitcharmer 5y ago
  Not sure what gave you that idea; it seems you have never been part of that crowd so just throwing unsubstantiated claims around. Performance has always been one of the major drivers in the JVM development. Just read the JEPs and see for yourself.
jcadam 5y ago
I'd argue that Java is a poor choice for this use case as well.
- Pet_Ant 5y ago
  There is a GC specifically for this use case: https://openjdk.java.net/jeps/318 https://openjdk.java.net/jeps/318
  - lolinder 5y ago
    An experimental one. There are still many far better choices for low-latency programming.
    - pjmlp 5y ago
      "Choosing Java instead of C++ for low-latency systems" https://stackoverflow.blog/2021/02/22/choosing-java-instead-of-c-for-low-latency-systems/ https://stackoverflow.blog/2021/02/22/choosing-java-instead-...
- bitcharmer 5y ago
  Well, 90% of this field relies heavily on Java so someone's wrong here. I guess that's not you, right?
throwaway894345 5y ago
Is the idea with Scala and Kotlin just that they encourage an immutable-first programming style, and that's why they create more garbage (as opposed to "nice features and syntax sugar")? Also, I thought idiomatic Java allocated all over the place as well (everything that isn't a primitive is an object which is allocated)? Maybe escape analysis is just fine-tuned for idiomatic Java (side question: is escape analysis a property of the JVM or the Java->JVM-bytecode compiler)? EDIT: I'm getting downvotes, so to be quite clear my questions are genuine; I'm very curious about how JVM languages work, and my intent is not to disparage JVM or its languages! :)
- saurik 5y ago
  So, the stereotype (mostly negative ;P) of "fully idiomatic Java" involves using factories (themselves managed by factory factories via dependency injection through factory factory factories... see "the hammer factory" post mirrored at https://danstroot.com/2018/10/03/hammer-factories/ https://danstroot.com/2018/10/03/hammer-factories/ or, to a lesser extent, Execution in the Kingdom of Nouns at http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom... for more information) to obtain objects, and most APIs simply don't need temporary arrays or large composites, so it tends to be pretty easy to take the high-performance parts of your code and modify them to never allocate anything at all (instead reusing existing objects from free lists, as the goal is to remove as much of--if not all of--the garbage collection pressure as possible, not to avoid the heap), in no small part because there is a pretty 1:1 mapping between the source code and the byte code... essentially, it is the same argument people use for why they love C (even more than C++, which I maintain has almost the same property): there are never any "hidden" allocations.
  - throwaway894345 5y ago
    I guess I wasn't thinking about the stereotype of idiomatic Java, but rather I'm assuming that--barring escape analysis--every `new` corresponds to an allocation and idiomatic Java (again, not the stereotype) has lots of `new`s. So I'm asking if escape analysis is eliding most of those allocations, or if I'm misunderstanding something and there is some other mechanism for reducing those allocs?
Quekid5 5y ago
I you really want the best possible performance you absolutely can program in Scala with little to no performance penalty over Java. In fact, in exactly the same way you can program in Java and still remain competitive with code written in C/C++ (except the typical differential isn't as drastic). You still have access to "raw" JVM arrays, mutability, etc. The difference is that you can choose to just restrict the 'ugly' code to your performance bottlenecks and code everything else at a higher level. This gets even better in Scala 3 with opaque types, etc.
- bitcharmer 5y ago
  Somehow the landscape of low-latency Java doesn't include other JVM languages so I don't think it's easy to achieve with Scala or Kotlin.
  - Quekid5 5y ago
    It's not some great mystery: Very few people are doing low-latency in Java in the first place, and all of the people who are have probably been doing it for a long time (in Java) already so there's a non-trivial cost to switching from Java to $OTHER_LANG. It has nothing to do with how easy it is to achieve the performance if you really want to. Well, OK, I might grant that there are a couple of very minor things that kind of work against you in e.g. Scala, namely lack of a native 'for-which-is-a-thinly-veiled-while-loop' and such, but that can be worked around with e.g. spire's cfor or just using while loops. Compared to the amount of effort to get anything-on-JVM working well in a low-latency environment in the first place, these obstacles are all trivial.

weego 5y ago

Those people are a frankly unimportant niche in the JVM world. Even in areas where its relevant (banking etc) 99%+ of the codebase is not coded for those tolerances.

bitcharmer 5y ago
Not sure what gave you that idea; it seems you have never been part of that crowd so just throwing unsubstantiated claims around. Performance has always been one of the major drivers in the JVM development. Just read the JEPs and see for yourself.

jcadam 5y ago

I'd argue that Java is a poor choice for this use case as well.

Pet_Ant 5y ago
There is a GC specifically for this use case: https://openjdk.java.net/jeps/318 https://openjdk.java.net/jeps/318
- lolinder 5y ago
  An experimental one. There are still many far better choices for low-latency programming.
  - pjmlp 5y ago
    "Choosing Java instead of C++ for low-latency systems" https://stackoverflow.blog/2021/02/22/choosing-java-instead-of-c-for-low-latency-systems/ https://stackoverflow.blog/2021/02/22/choosing-java-instead-...
bitcharmer 5y ago
Well, 90% of this field relies heavily on Java so someone's wrong here. I guess that's not you, right?

throwaway894345 5y ago

Is the idea with Scala and Kotlin just that they encourage an immutable-first programming style, and that's why they create more garbage (as opposed to "nice features and syntax sugar")? Also, I thought idiomatic Java allocated all over the place as well (everything that isn't a primitive is an object which is allocated)? Maybe escape analysis is just fine-tuned for idiomatic Java (side question: is escape analysis a property of the JVM or the Java->JVM-bytecode compiler)? EDIT: I'm getting downvotes, so to be quite clear my questions are genuine; I'm very curious about how JVM languages work, and my intent is not to disparage JVM or its languages! :)

saurik 5y ago
So, the stereotype (mostly negative ;P) of "fully idiomatic Java" involves using factories (themselves managed by factory factories via dependency injection through factory factory factories... see "the hammer factory" post mirrored at https://danstroot.com/2018/10/03/hammer-factories/ https://danstroot.com/2018/10/03/hammer-factories/ or, to a lesser extent, Execution in the Kingdom of Nouns at http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom... for more information) to obtain objects, and most APIs simply don't need temporary arrays or large composites, so it tends to be pretty easy to take the high-performance parts of your code and modify them to never allocate anything at all (instead reusing existing objects from free lists, as the goal is to remove as much of--if not all of--the garbage collection pressure as possible, not to avoid the heap), in no small part because there is a pretty 1:1 mapping between the source code and the byte code... essentially, it is the same argument people use for why they love C (even more than C++, which I maintain has almost the same property): there are never any "hidden" allocations.
- throwaway894345 5y ago
  I guess I wasn't thinking about the stereotype of idiomatic Java, but rather I'm assuming that--barring escape analysis--every `new` corresponds to an allocation and idiomatic Java (again, not the stereotype) has lots of `new`s. So I'm asking if escape analysis is eliding most of those allocations, or if I'm misunderstanding something and there is some other mechanism for reducing those allocs?

Quekid5 5y ago

I you really want the best possible performance you absolutely can program in Scala with little to no performance penalty over Java. In fact, in exactly the same way you can program in Java and still remain competitive with code written in C/C++ (except the typical differential isn't as drastic). You still have access to "raw" JVM arrays, mutability, etc. The difference is that you can choose to just restrict the 'ugly' code to your performance bottlenecks and code everything else at a higher level. This gets even better in Scala 3 with opaque types, etc.

bitcharmer 5y ago
Somehow the landscape of low-latency Java doesn't include other JVM languages so I don't think it's easy to achieve with Scala or Kotlin.
- Quekid5 5y ago
  It's not some great mystery: Very few people are doing low-latency in Java in the first place, and all of the people who are have probably been doing it for a long time (in Java) already so there's a non-trivial cost to switching from Java to $OTHER_LANG. It has nothing to do with how easy it is to achieve the performance if you really want to. Well, OK, I might grant that there are a couple of very minor things that kind of work against you in e.g. Scala, namely lack of a native 'for-which-is-a-thinly-veiled-while-loop' and such, but that can be worked around with e.g. spire's cfor or just using while loops. Compared to the amount of effort to get anything-on-JVM working well in a low-latency environment in the first place, these obstacles are all trivial.