6 ms·

The better question is why use Java for anything these days. If you really need to run something with JVM, use Kotlin.

by ActorNightly 1y ago

ackfoobar 1y ago
As a Kotlin enjoyer, I find these comments counterproductive. Maybe they like the lack of extension functions?
- kachapopopow 1y ago
  Kotlin is fatter, compiler is slower, code completion is slow as hell on large projects, but other than building small applications - there's really no reason to not use kotlin except for the fact that you need to actually learn the language or else you're going to end up with very very slow codebase where opening a file and waiting for syntax highlighting takes 2-3 seconds and typing autocomplete is just painfully slow.
  - switchbak 1y ago
    "fatter, compiler is slower, code completion is slow as hell" - if that's all you want out of your programming language, then Java is probably a good choice for you. For others that value the things that Kotlin brings over Java (even modern Java), and for the ways in which it delivers a simpler experience than Scala - I think it's a pragmatic and sensible decision.
- vips7L 1y ago
  I do like the lack of extension functions. I find them confusing, especially when you can use them on things that are null.
  - simon_void 1y ago
    I wonder if that confusion is due to the fact that you haven't yet wrapped your head around the fact that extension functions are "just" syntactic sugar for static functions. The implicit "this" becomes the the first parameter of the static function and function parameters can be null. Now you might ask "why not use static (/first class) functions then? Because those "feel" like less ideomatic to use then extension functions or methods that are defined on the object (hirachy) itself. But understanding why the extension type can be nullable is not the same is using it on nullable types. I restrict my extension functions to non-nullable types most of the time as well. The best exception to this preference -just to see where it makes sense- is the build-in function [toString](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/to-string.html https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/to-stri...), since you want it to return "null" if you invoke it on null.
    - vips7L 1y ago
      I have wrapped my head around it. I think it's confusing to the reader and creates awkward semantics.
      - vips7L 1y ago
        What I mean by that is this: val a: SomeType? = null // I’m forced to null check here if (a != null) { a.someMethodOnIt() } // But I don’t have to null check here a.someExtensionFn() It’s weird.
      - izacus 1y ago
        Yeah, extension functions are one of those features that went from 'oh, this is nice' to "this is so overused it's counterproductive". It makes reading a lot of Kotlin source quite terrible. Lately they've been shoveling a lot of similar magical "code comes from somewhere" features into a language, slowly giving it a C++ clutter type feel.
AdieuToLogic 1y ago
> The better question is why use Java for anything these days. Java (the language) is pretty much "C for the JVM." By that, I mean frameworks/libraries intended for maximum potential use in languages running on the JVM (such as Kotlin, Scala, and of course Java) all support Java (the language) interoperability. Many written in alternate languages targeting the JVM, such as Akka[0], typically have some degree of Java (the language) support as well. While I prefer to program in one of the alternate programming languages targeting the JVM, I understand why many OSS projects are implemented in Java (the language) for the reasons outlined above. 0 - https://github.com/akka/akka https://github.com/akka/akka
- ActorNightly 1y ago
  The problem is, if you are trying to optimize for the JVM, you are already down the wrong path. The JVM is useful in a very small niche when you want something that is faster than Python/Node , but still want cross platform support and somewhat rapid development. The cases where this applies are very niche. It may allow closer to JVM access, however the entire ecosystem is a colossal mess. The main() implementation in having a class that wraps it is pretty dumb, standard stuff like Lombok hacks the AST (not to mention in general the annotation preprocessors work by printing code strings to file), and the whole dependency injection frameworks are very much separated from actual processing with how much stuff they do in the background. And then there is the whole Apache foundation with its software being used widely as standard. The same foundation where someone wrote the code that allows log statements to pull arbitrary code from the internet and execute it, and that change made its way past multiple eyes before being merged to production without a single person realizing how crazy it is. If you want speed, write stuff in C/Rust/Clean C++ (without templates, no C style memory access, e.t.c). If you want to be efficient, write stuff in Python/Node.
  - selimco 1y ago
    You don’t really need any of the apache commons libraries with modern java versions, if that’s what you were referring to. Also I think that most people who are considering doing jvm development would consider kotlin as an alternative language or maybe c# and dotnet as an alternative ecosystem. I believe rust, c or cpp are rarely going to be considerations for most people in that situation.
symbolicAGI 1y ago
A recent good reason for using Java is that frontier LLMs are trained with very large amounts of high quality enterprise Java source code. Claude Code for example loves Java and its static type system. I constrain my LLM-generated Java code to only static methods of 20 LOC or less, and limit data types to those that are JSON compatible. Both of these lead to more reliable code and data that Claude Code fully understands and generates. I am preparing to auto-generate an agent-based application that might reach 1.5 million Java LOC. Hard to imagine accomplishing that with Javascript or Python or C++.
- wvenable 1y ago
  > A recent good reason for using Java is that frontier LLMs are trained with very large amounts of high quality enterprise Java source code. Where did it get it from?
  - symbolicAGI 1y ago
    GitHub public repositories mostly.
    - wvenable 1y ago
      I don't think Github is necessarily full of high quality enterprise Java software, is it?
      - symbolicAGI 1y ago
        Grok says you are right (https://grok.com/share/c2hhcmQtMg%3D%3D_ddbace62-c299-4b7b-921c-c5188e9cac50 https://grok.com/share/c2hhcmQtMg%3D%3D_ddbace62-c299-4b7b-9...) however... https://github.com/iluwatar/java-design-patterns https://github.com/iluwatar/java-design-patterns https://github.com/spring-projects/spring-framework https://github.com/spring-projects/spring-framework https://github.com/apache/kafka https://github.com/apache/kafka https://github.com/neo4j https://github.com/neo4j https://github.com/inforkgodara/store-poshttps://github.com/inforkgodara/store-pos https://github.com/inforkgodara/store-poshttps://github.com/...
peterashford 1y ago
I've worked in both and I prefer Java

The better question is why use Java for anything these days. If you really need to run something with JVM, use Kotlin.

ackfoobar 1y ago

As a Kotlin enjoyer, I find these comments counterproductive. Maybe they like the lack of extension functions?

kachapopopow 1y ago
Kotlin is fatter, compiler is slower, code completion is slow as hell on large projects, but other than building small applications - there's really no reason to not use kotlin except for the fact that you need to actually learn the language or else you're going to end up with very very slow codebase where opening a file and waiting for syntax highlighting takes 2-3 seconds and typing autocomplete is just painfully slow.
- switchbak 1y ago
  "fatter, compiler is slower, code completion is slow as hell" - if that's all you want out of your programming language, then Java is probably a good choice for you. For others that value the things that Kotlin brings over Java (even modern Java), and for the ways in which it delivers a simpler experience than Scala - I think it's a pragmatic and sensible decision.
vips7L 1y ago
I do like the lack of extension functions. I find them confusing, especially when you can use them on things that are null.
- simon_void 1y ago
  I wonder if that confusion is due to the fact that you haven't yet wrapped your head around the fact that extension functions are "just" syntactic sugar for static functions. The implicit "this" becomes the the first parameter of the static function and function parameters can be null. Now you might ask "why not use static (/first class) functions then? Because those "feel" like less ideomatic to use then extension functions or methods that are defined on the object (hirachy) itself. But understanding why the extension type can be nullable is not the same is using it on nullable types. I restrict my extension functions to non-nullable types most of the time as well. The best exception to this preference -just to see where it makes sense- is the build-in function [toString](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/to-string.html https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/to-stri...), since you want it to return "null" if you invoke it on null.
  - vips7L 1y ago
    I have wrapped my head around it. I think it's confusing to the reader and creates awkward semantics.
    - vips7L 1y ago
      What I mean by that is this: val a: SomeType? = null // I’m forced to null check here if (a != null) { a.someMethodOnIt() } // But I don’t have to null check here a.someExtensionFn() It’s weird.
    - izacus 1y ago
      Yeah, extension functions are one of those features that went from 'oh, this is nice' to "this is so overused it's counterproductive". It makes reading a lot of Kotlin source quite terrible. Lately they've been shoveling a lot of similar magical "code comes from somewhere" features into a language, slowly giving it a C++ clutter type feel.

AdieuToLogic 1y ago

> The better question is why use Java for anything these days. Java (the language) is pretty much "C for the JVM." By that, I mean frameworks/libraries intended for maximum potential use in languages running on the JVM (such as Kotlin, Scala, and of course Java) all support Java (the language) interoperability. Many written in alternate languages targeting the JVM, such as Akka[0], typically have some degree of Java (the language) support as well. While I prefer to program in one of the alternate programming languages targeting the JVM, I understand why many OSS projects are implemented in Java (the language) for the reasons outlined above. 0 - https://github.com/akka/akka https://github.com/akka/akka

ActorNightly 1y ago
The problem is, if you are trying to optimize for the JVM, you are already down the wrong path. The JVM is useful in a very small niche when you want something that is faster than Python/Node , but still want cross platform support and somewhat rapid development. The cases where this applies are very niche. It may allow closer to JVM access, however the entire ecosystem is a colossal mess. The main() implementation in having a class that wraps it is pretty dumb, standard stuff like Lombok hacks the AST (not to mention in general the annotation preprocessors work by printing code strings to file), and the whole dependency injection frameworks are very much separated from actual processing with how much stuff they do in the background. And then there is the whole Apache foundation with its software being used widely as standard. The same foundation where someone wrote the code that allows log statements to pull arbitrary code from the internet and execute it, and that change made its way past multiple eyes before being merged to production without a single person realizing how crazy it is. If you want speed, write stuff in C/Rust/Clean C++ (without templates, no C style memory access, e.t.c). If you want to be efficient, write stuff in Python/Node.
- selimco 1y ago
  You don’t really need any of the apache commons libraries with modern java versions, if that’s what you were referring to. Also I think that most people who are considering doing jvm development would consider kotlin as an alternative language or maybe c# and dotnet as an alternative ecosystem. I believe rust, c or cpp are rarely going to be considerations for most people in that situation.

symbolicAGI 1y ago

A recent good reason for using Java is that frontier LLMs are trained with very large amounts of high quality enterprise Java source code. Claude Code for example loves Java and its static type system. I constrain my LLM-generated Java code to only static methods of 20 LOC or less, and limit data types to those that are JSON compatible. Both of these lead to more reliable code and data that Claude Code fully understands and generates. I am preparing to auto-generate an agent-based application that might reach 1.5 million Java LOC. Hard to imagine accomplishing that with Javascript or Python or C++.

wvenable 1y ago
> A recent good reason for using Java is that frontier LLMs are trained with very large amounts of high quality enterprise Java source code. Where did it get it from?
- symbolicAGI 1y ago
  GitHub public repositories mostly.
  - wvenable 1y ago
    I don't think Github is necessarily full of high quality enterprise Java software, is it?
    - symbolicAGI 1y ago
      Grok says you are right (https://grok.com/share/c2hhcmQtMg%3D%3D_ddbace62-c299-4b7b-921c-c5188e9cac50 https://grok.com/share/c2hhcmQtMg%3D%3D_ddbace62-c299-4b7b-9...) however... https://github.com/iluwatar/java-design-patterns https://github.com/iluwatar/java-design-patterns https://github.com/spring-projects/spring-framework https://github.com/spring-projects/spring-framework https://github.com/apache/kafka https://github.com/apache/kafka https://github.com/neo4j https://github.com/neo4j https://github.com/inforkgodara/store-poshttps://github.com/inforkgodara/store-pos https://github.com/inforkgodara/store-poshttps://github.com/...

peterashford 1y ago

I've worked in both and I prefer Java