4 ms·

At this point I think the more relevant question is: is there any point to using kotlin if you are not doing android dev?

• afavour 3y ago
  Personally I find it more enjoyable to code in than Java. There’s also maybe an argument to be made around Kotlin Native, KotlinJS too.
  • robertlagrant 3y ago
    Also Kotlin Multiplatform.
  • kaba0 3y ago
    GraalVM, TeaVM, Google’s Closure compiler. Java is an insanely big language, so if a tiny language has something, you can bet Java also has it in a much more ready form.
• xwowsersx 3y ago
  Sure, assuming you are happy with most of the language constructs and it feels ergonomic to you, Kotlin can make sense for backend/APIs, while still having access to all the Java libs/packages. I'm starting several new largeish projects now and have decided on using Kotlin.
• mdaniel 3y ago
  Having `@Nullable`/`@Nonnull` (or its dumb `Optional<T>` friend) is nothing compared to NPE being a compilation failure Also, all hail `val`; `final var` is objectively worse
  • iraqmtpizza 3y ago
    var is write-only and won't catch type errors
    • mdaniel 3y ago
      Sorry, I don't understand your concern. My observation is that having a variable declaration that is single-assigment in Java requires the "final" keyword, which in the most charitable case is "final var" where the caller and/or the IDE know the type (e.g. "final var foo = new ArrayList<Bar>()") and in the degenerate case is "final ApplicationEvent<Map<String, List<String>>> thing = doSomething()" In Kotlin one can get finality via the much nicer "val" keyword, and seems to be idiomatically the default, versus Java's mutable-by-default stance Saying either language "won't catch type errors" is not something I can agree with
      • iraqmtpizza 3y ago
        Normally, declaring a variable offers type safety. var matches anything and thus it's never a compile-time error. If someone accidentally changes the return type of getAddresses from Map to List, there is no compile-time error. There is nothing to check the return type against except Object in this case because Tuple.of takes Objects. final var addressMap = getAddresses(); final Tuple args = Tuple.of("a", 200L, x); So you may as well inline the method call and give up on any type checking. Another example: final long limit = getLimit(); for (var i = 0; i < limit; i++) {} The wrapping behavior is determined by whether there is an L (or lowercase, l) after the 0. If limit happens to be greater than Integer.MAX_VALUE, that L is the difference between an infinite loop and a well-behaved routine. Some junior programmer could easily remove the L accidentally. And you wouldn't run into the bug until limit gets big enough. Which could happen at runtime in production. All because you wanted to save one character by using var instead of long. This is just what I could think of off the top of my head. I'm sure there are other examples. You are absolutely giving up some compile-time sanity checks with var. If it's just some throwaway script, then fine. But if so why use Java in the first place?
        • kaba0 3y ago
          I’m sorry, but you gravely misunderstand type inference. Sure, there is no compile-error if all you have is a single assignment, why would there be? But that’s a completely useless code. Here is a real example: var list = getSomeFancyLongAssNestedGenericTypedList(); list.append(new HashMap<…>()); If I change the return type of that function to something that doesn’t have a compatible append method, your method will fail. In fact, you implicitly encode all its usage in that var, so it will be maximally safe, while not being more restrictive than needed (e.g. changing to another object that has append may be fine). Also, var is not a must-use, there are useful cases where it gives more clear code and the type is not important (say, when the right side is a constructor call), and there are cases where you really should be annotating your types. But it will be type safe either way.
• cutler 3y ago
  Spring Boot has full Kotlin support.