3 ms·

* I find it hard to believe anyone with experience on the JVM would choose Java over Scala or Kotlin. The latter actually addresses most of your concerns. The e

* I find it hard to believe anyone with experience on the JVM would choose Java over Scala or Kotlin. The latter actually addresses most of your concerns. The existence of Lombok is a strong argument in favor of a more modern language. * I'd violently disagree with anyone grouping gradle and maven together. One of them is declarative the other is a mess surpassed only by SBT. * I don't get why nulls are so hated by people who are not real FP purists. How are they different from ", err := .. if err != nil .." in golang which people do a lot and seem to enjoy (in comparison with exceptions and even Optionals)? NPEs are not common in development and very unusual in prod. I'm not sure I like how much ceremony there's in Kotlin to keep track of nullable things. * I hate to break the news but log4j was dropped in favor of slf4J&Co a decade ago. There are better restful frameworks such as akka-http and sparkjava.

shepherdjerred 4y ago
* I'd prefer Java (with Lombok) over Scala or Kotlin * How often do you see both Gradle and Maven in a project? Not often. They're similar tools. * [0] * This is completely untrue. log4j is still widely used, even in new projects. sl4j is simply a universal API that allows applications to choose their logging backend. sl4j and log4j aren't mutually exclusive. * I was going to say that spark hasn't been updated in years, but it looks like they posted a release [1]! [0]: https://hackernoon.com/null-the-billion-dollar-mistake-8t5z32d6 https://hackernoon.com/null-the-billion-dollar-mistake-8t5z3... [1]: https://mvnrepository.com/artifact/com.sparkjava/spark-core/2.9.4 https://mvnrepository.com/artifact/com.sparkjava/spark-core/...
Tainnor 4y ago
> I don't get why nulls are so hated by people who are not real FP purists. How are they different from ", err := .. if err != nil .." in golang which people do a lot and seem to enjoy (in comparison with exceptions and even Optionals)? NPEs are not common in development and very unusual in prod. I'm not sure I like how much ceremony there's in Kotlin to keep track of nullable things. Disagree that NPEs are a rare occurrence, that Go-style error handling is universally enjoyed (I would say it's one of the top complaints people have about Go) and that Kotlin null handling uses too much ceremony. And as for that last point, idiomatic Kotlin code (or, indeed, code in any language that has null-safety) will tend to eliminate nullability from types as much as possible, it's not really the case that most function arguments, return values, etc. really need to be nullable.

shepherdjerred 4y ago

* I'd prefer Java (with Lombok) over Scala or Kotlin * How often do you see both Gradle and Maven in a project? Not often. They're similar tools. * [0] * This is completely untrue. log4j is still widely used, even in new projects. sl4j is simply a universal API that allows applications to choose their logging backend. sl4j and log4j aren't mutually exclusive. * I was going to say that spark hasn't been updated in years, but it looks like they posted a release [1]! [0]: https://hackernoon.com/null-the-billion-dollar-mistake-8t5z32d6 https://hackernoon.com/null-the-billion-dollar-mistake-8t5z3... [1]: https://mvnrepository.com/artifact/com.sparkjava/spark-core/2.9.4 https://mvnrepository.com/artifact/com.sparkjava/spark-core/...

Tainnor 4y ago

> I don't get why nulls are so hated by people who are not real FP purists. How are they different from ", err := .. if err != nil .." in golang which people do a lot and seem to enjoy (in comparison with exceptions and even Optionals)? NPEs are not common in development and very unusual in prod. I'm not sure I like how much ceremony there's in Kotlin to keep track of nullable things. Disagree that NPEs are a rare occurrence, that Go-style error handling is universally enjoyed (I would say it's one of the top complaints people have about Go) and that Kotlin null handling uses too much ceremony. And as for that last point, idiomatic Kotlin code (or, indeed, code in any language that has null-safety) will tend to eliminate nullability from types as much as possible, it's not really the case that most function arguments, return values, etc. really need to be nullable.