4 ms·

Try Kotlin. It's what modern Java should be, and might eventually slowly (slowly) develop into. It's a joy, and can use the entire JVM ecosystem (frameworks, li

by Alupis 2y ago

Try Kotlin. It's what modern Java should be, and might eventually slowly (slowly) develop into. It's a joy, and can use the entire JVM ecosystem (frameworks, libraries, tooling, etc). The C# folks can't even knock it... it's less verbose and more functional. Kotlin + Spring Boot for backend work is the way...

jimbokun 2y ago
Sprint Boot is the part of the Java ecosystem I most want to escape from.
- Alupis 2y ago
  Fair - good thing there's like a dozen web frameworks you can choose from. Find one you like and run with it.
  - jimbokun 2y ago
    I love Javalin for new projects! But have too much code in Spring Boot to ever justify rewriting all of it.
    - Alupis 2y ago
      Thanks for naming Javalin - I had not previously heard of it and it appears quite nice. I will say though, I vastly prefer pushing configuration out of my code and into config files/text. Things like `Javalin.create { config -> config.useVirtualThreads = true }` in my opinion should live in a config file. But, to each their own - that's the beauty of the JVM ecosystem - lots of choice and lots of ideas.
      - jimbokun 2y ago
        Spring Boot pushes EVERYTHING into config. Whether annotations, or YAML files or property files or Gradle or Maven files or something else. And those things are very very hard to debug. Java tools do not have an easy way to step through the code that gets executed due to you having an annotation in your source. Or the code paths that get executed to create beans and run code and generate entirely new classes with no source code...just by adding a dependency to your project. For the things that really should be configuration, environment variables are perfectly fine.
- kdtsh 2y ago
  Why? Having come from OSGi it’s a godsend. What’s wrong with it and what’s better?
bcrosby95 2y ago
> what modern Java should be They just have different philosophies. I'm not much of a fan of Kotlin or C#. I prefer Go, Java, and Clojure.
lye 2y ago
For boring line of business and crud applications there is almost no difference with latest versions of Java, and the feature gap closes with every release. I recently finished (however much you can "finish" software) a project in Kotlin and probably won't be using it in the future. Compilation time, although much improved by recent releases, is still twice as slow as Java, you only get decent support for the language in IDEA (which makes sense since the officially stated goal of releasing Kotlin was to drive sales of their IDEs), and feature-wise the only thing it really has over Java is null safety, which is solvable through other means. You get all the other problems of using a "guest" language (of which there have been many before — most of them long dead) like the disconnect between read-only data classes and records, which necessitates the use of @JvmRecord when you need specifically a record. This disconnect between the language and the JVM too will continue to widen.
- Alupis 2y ago
  > there is almost no difference with latest versions of Java, and the feature gap closes with every release Java may be implementing features that Kotlin has had since day 1 (or close-to), but Java's syntax will always be what it is due to it's legacy. It's not "modern" syntax, and the way it handles fluent expressions will always be kludgey. There is nothing special about Kotlin that required IDEA, other than it's convenient. Kotlin is a bundle of libraries and gradle plugins - so it can work on any IDE, including Eclipse or whatever you prefer. Java's Optional is also much more kludgey than Kotlin's nullable types Also, generally when writing Kotlin you don't need to make sure your code is interoperable with Java code - usually you are consuming Java code in your Kotlin code... so things like the suite of `@JVMxxx` annotations are not used. If you are writing a library or framework - then obviously concerns are different.
  - lye 2y ago
    I really don't think a slightly different syntax is enough of an argument to bring a separate language, introduce another massive dependency (and another vendor) into your supply chain, and create additional problems with hiring people, but to each their own. I don't mean Optional, it was never intended for widespread use, according to its own author. It's solvable by using annotations; uber has a solution that allows you to only annotate nullable fields, and the rest is assumed to be (and checked at runtime) as not null. There are never that many nullable fields in sanely designed applications. Writing Kotlin in other IDEs is about as good as writing it in vim. Java experience is closer to the same level regardless of which of the big three (or two…) you prefer.

by Alupis 2y ago

jimbokun 2y ago

Sprint Boot is the part of the Java ecosystem I most want to escape from.

Alupis 2y ago
Fair - good thing there's like a dozen web frameworks you can choose from. Find one you like and run with it.
- jimbokun 2y ago
  I love Javalin for new projects! But have too much code in Spring Boot to ever justify rewriting all of it.
  - Alupis 2y ago
    Thanks for naming Javalin - I had not previously heard of it and it appears quite nice. I will say though, I vastly prefer pushing configuration out of my code and into config files/text. Things like `Javalin.create { config -> config.useVirtualThreads = true }` in my opinion should live in a config file. But, to each their own - that's the beauty of the JVM ecosystem - lots of choice and lots of ideas.
    - jimbokun 2y ago
      Spring Boot pushes EVERYTHING into config. Whether annotations, or YAML files or property files or Gradle or Maven files or something else. And those things are very very hard to debug. Java tools do not have an easy way to step through the code that gets executed due to you having an annotation in your source. Or the code paths that get executed to create beans and run code and generate entirely new classes with no source code...just by adding a dependency to your project. For the things that really should be configuration, environment variables are perfectly fine.
kdtsh 2y ago
Why? Having come from OSGi it’s a godsend. What’s wrong with it and what’s better?

bcrosby95 2y ago

> what modern Java should be They just have different philosophies. I'm not much of a fan of Kotlin or C#. I prefer Go, Java, and Clojure.

lye 2y ago

For boring line of business and crud applications there is almost no difference with latest versions of Java, and the feature gap closes with every release. I recently finished (however much you can "finish" software) a project in Kotlin and probably won't be using it in the future. Compilation time, although much improved by recent releases, is still twice as slow as Java, you only get decent support for the language in IDEA (which makes sense since the officially stated goal of releasing Kotlin was to drive sales of their IDEs), and feature-wise the only thing it really has over Java is null safety, which is solvable through other means. You get all the other problems of using a "guest" language (of which there have been many before — most of them long dead) like the disconnect between read-only data classes and records, which necessitates the use of @JvmRecord when you need specifically a record. This disconnect between the language and the JVM too will continue to widen.

Alupis 2y ago
> there is almost no difference with latest versions of Java, and the feature gap closes with every release Java may be implementing features that Kotlin has had since day 1 (or close-to), but Java's syntax will always be what it is due to it's legacy. It's not "modern" syntax, and the way it handles fluent expressions will always be kludgey. There is nothing special about Kotlin that required IDEA, other than it's convenient. Kotlin is a bundle of libraries and gradle plugins - so it can work on any IDE, including Eclipse or whatever you prefer. Java's Optional is also much more kludgey than Kotlin's nullable types Also, generally when writing Kotlin you don't need to make sure your code is interoperable with Java code - usually you are consuming Java code in your Kotlin code... so things like the suite of `@JVMxxx` annotations are not used. If you are writing a library or framework - then obviously concerns are different.
- lye 2y ago
  I really don't think a slightly different syntax is enough of an argument to bring a separate language, introduce another massive dependency (and another vendor) into your supply chain, and create additional problems with hiring people, but to each their own. I don't mean Optional, it was never intended for widespread use, according to its own author. It's solvable by using annotations; uber has a solution that allows you to only annotate nullable fields, and the rest is assumed to be (and checked at runtime) as not null. There are never that many nullable fields in sanely designed applications. Writing Kotlin in other IDEs is about as good as writing it in vim. Java experience is closer to the same level regardless of which of the big three (or two…) you prefer.