5 ms·

As a guy who has written a lot of modern JS but was working in a JVM-only shop (all tooling etc assumed services were running on the JVM), Kotlin was like a bre

by kevsim 6y ago

As a guy who has written a lot of modern JS but was working in a JVM-only shop (all tooling etc assumed services were running on the JVM), Kotlin was like a breath of fresh air. Doesn’t go as FP as Scala (which is a plus for me) but still has all the nice collection APIs etc that I use frequently in JS. Really looking forward to seeing what happens with Kotlin native. Compile times were pretty bad last I tried it but I’d give it another go if they improved those.

throwaway8941 6y ago
>Doesn’t go as FP as Scala (which is a plus for me) If anyone reading this thinks about using Kotlin and has more positive views towards FP, there's this project to bridge the gap somewhat https://arrow-kt.io/ https://arrow-kt.io/
- The_rationalist 6y ago
  Arrow meta is a compiler extension that will bridge the gap even more e.g by bringing union types https://github.com/arrow-kt/arrow-meta https://github.com/arrow-kt/arrow-meta
  - valenterry 6y ago
    Unfortunately, the gap will stay huge due to the lack of capabilities the type-system, e.g. in higher kinded types and implicits. However, most people who choose Kotlin probably don't want to do "fully fledged" FP anyways and prefer to take the faster compile times etc. over it. I like the Scala side better though. ;)
    - WkndTriathlete 6y ago
      I'd argue that more day-to-day problems are solved with extremely usable record types (data class) than are solved with natively-supported HKTs.
      - valenterry 6y ago
        That's true, but a fallacy. Because HKTs prevent a certain class of problems from even coming to existence. What they predominantly do is help library author's to easily re-use and combine other libraries and provide them to their users while allowing for much greater flexibility than without them. So yeah, that's not a day-to-day problem of a system engineer (which I and most developers are) but they prevent a lot of these problems from even existing in the beginning. In the end, both are very useful in a different way and I don't like to work in languages that are missing either of them.
- mumblemumble 6y ago
  FWIW, I have positive views toward FP, but also ultimately decided, after a few years working in Scala, that it goes too far on the FP front. The problem isn't that the language features Scala introduces are objectively bad. It's that they're in constant tension with the underlying platform. On the one side, you have Scala's FP features harming interop with other JVM languages. On the other hand, you have Scala's dependencies on the Java APIs and type system hindering its efforts to be more functional, and making a lot of things feel way more complicated and tricky to use properly than they do in, say, Haskell. Kotlin isn't everything I'd want in an ideal world, but it's everything I'm comfortable asking for in the real world.
- dionian 6y ago
  Since scala gives you the option to not be FP, is this a criticism of the scala community?
- ragnese 6y ago
  Doesn't this require a plugin, though? So it's basically an extension of Kotlin-the-language. To those who are using Arrow- why not Scala? Is it just because Scala has too much cruft? The only thing Kotlin has over Scala (AFAIK) is coroutines, which, honestly- I don't even love. They're very awkward to use and require unchecked exceptions for control-flow (and therefore have convention-based rules around using them).
  - deleted 6y ago
    [deleted]
  - valenterry 6y ago
    I think the answer is quite simple. You might start out with Kotlin and get familiar with it. But when you get thirsty for more, arrow is the logical next step. Going for Scala would require learning a lot of new stuff and once or even rewrite your things. It's the same for Scala and Haskell, which is why Scala is sometimes called Haskellator - I still would start a project in Scala because I'm more familiar with it.
thu2111 6y ago
Kotlin/Native is LLVM based. Judging from the Rust experience compilation times won't ever be excellent. But Kotlin is multi-platform, so if you're not calling into Java APIs then you could prototype suitable modules on the JVM where compile times are much better, then bring it to the native world later. Or use GraalVM native-image to AOT compile Kotlin/JVM to a standalone binary. That gets you same user-visible outcomes more or less, but you can then use all JVM libs, not just Kotlin libs.
x87678r 6y ago
Its amazing to me that Javascript used to be the ugly stepchild that no one wanted to play with but had to, and now is so popular that it influences mainstream compiled languages.
- MiroF 6y ago
  To me, Javascript objects are gross, but TS has done away with a lot of that mess.
- ragnese 6y ago
  In this case, it didn't. That's just the reference-frame of the person who you replied to. Map, reduce, filter, etc existed long before JavaScript. I assume that's what they're talking about.
  - kevsim 6y ago
    Exactly what I meant. I never claimed JS invented these things, merely that I use them a lot.

by kevsim 6y ago

throwaway8941 6y ago

>Doesn’t go as FP as Scala (which is a plus for me) If anyone reading this thinks about using Kotlin and has more positive views towards FP, there's this project to bridge the gap somewhat https://arrow-kt.io/ https://arrow-kt.io/

The_rationalist 6y ago
Arrow meta is a compiler extension that will bridge the gap even more e.g by bringing union types https://github.com/arrow-kt/arrow-meta https://github.com/arrow-kt/arrow-meta
- valenterry 6y ago
  Unfortunately, the gap will stay huge due to the lack of capabilities the type-system, e.g. in higher kinded types and implicits. However, most people who choose Kotlin probably don't want to do "fully fledged" FP anyways and prefer to take the faster compile times etc. over it. I like the Scala side better though. ;)
  - WkndTriathlete 6y ago
    I'd argue that more day-to-day problems are solved with extremely usable record types (data class) than are solved with natively-supported HKTs.
    - valenterry 6y ago
      That's true, but a fallacy. Because HKTs prevent a certain class of problems from even coming to existence. What they predominantly do is help library author's to easily re-use and combine other libraries and provide them to their users while allowing for much greater flexibility than without them. So yeah, that's not a day-to-day problem of a system engineer (which I and most developers are) but they prevent a lot of these problems from even existing in the beginning. In the end, both are very useful in a different way and I don't like to work in languages that are missing either of them.
mumblemumble 6y ago
FWIW, I have positive views toward FP, but also ultimately decided, after a few years working in Scala, that it goes too far on the FP front. The problem isn't that the language features Scala introduces are objectively bad. It's that they're in constant tension with the underlying platform. On the one side, you have Scala's FP features harming interop with other JVM languages. On the other hand, you have Scala's dependencies on the Java APIs and type system hindering its efforts to be more functional, and making a lot of things feel way more complicated and tricky to use properly than they do in, say, Haskell. Kotlin isn't everything I'd want in an ideal world, but it's everything I'm comfortable asking for in the real world.
dionian 6y ago
Since scala gives you the option to not be FP, is this a criticism of the scala community?
ragnese 6y ago
Doesn't this require a plugin, though? So it's basically an extension of Kotlin-the-language. To those who are using Arrow- why not Scala? Is it just because Scala has too much cruft? The only thing Kotlin has over Scala (AFAIK) is coroutines, which, honestly- I don't even love. They're very awkward to use and require unchecked exceptions for control-flow (and therefore have convention-based rules around using them).
- deleted 6y ago
  [deleted]
- valenterry 6y ago
  I think the answer is quite simple. You might start out with Kotlin and get familiar with it. But when you get thirsty for more, arrow is the logical next step. Going for Scala would require learning a lot of new stuff and once or even rewrite your things. It's the same for Scala and Haskell, which is why Scala is sometimes called Haskellator - I still would start a project in Scala because I'm more familiar with it.

thu2111 6y ago

Kotlin/Native is LLVM based. Judging from the Rust experience compilation times won't ever be excellent. But Kotlin is multi-platform, so if you're not calling into Java APIs then you could prototype suitable modules on the JVM where compile times are much better, then bring it to the native world later. Or use GraalVM native-image to AOT compile Kotlin/JVM to a standalone binary. That gets you same user-visible outcomes more or less, but you can then use all JVM libs, not just Kotlin libs.

x87678r 6y ago

Its amazing to me that Javascript used to be the ugly stepchild that no one wanted to play with but had to, and now is so popular that it influences mainstream compiled languages.

MiroF 6y ago
To me, Javascript objects are gross, but TS has done away with a lot of that mess.
ragnese 6y ago
In this case, it didn't. That's just the reference-frame of the person who you replied to. Map, reduce, filter, etc existed long before JavaScript. I assume that's what they're talking about.
- kevsim 6y ago
  Exactly what I meant. I never claimed JS invented these things, merely that I use them a lot.