5 ms·

>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 proje

>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.

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.