4 ms·

I see Kotlin as a great choice for these who don't want Java verbosity but can't really get used to read Scala.

by viach 8y ago

jamougha 8y ago
I can read Scala fine but I'd like fast compilation and good IDE support.
- jacobn 8y ago
  The IDE support is pretty good these days, as least in IntelliJ.
  - dominotw 8y ago
    Intellij still can't figure out how to handle implicits. At this point i have an intuition about the errors that idea reports as errors but actually aren't'.
    - threeseed 8y ago
      Are you using the latest version of IntelliJ ? Because it does a pretty good job with implicits now: https://blog.jetbrains.com/scala/2018/07/25/intellij-scala-plugin-2018-2-advanced-implicit-support-improved-patterns-autocompletion-semantic-highlighting-scalafmt-and-more/ https://blog.jetbrains.com/scala/2018/07/25/intellij-scala-p...
  - Cyph0n 8y ago
    Not sure why you were downvoted. IntelliJ’s Scala plugin is top-notch in my experience.
    - edejong 8y ago
      True, nor do I understand your downvote.
    - IBalic 8y ago
      +1 works great
  - _ZeD_ 8y ago
    Apart the fact that I would disagree on intellij support, what about the other ides? Eclipse? Visual studio (not code)?
  - cryptos 8y ago
    Scala support in IntelliJ is ok, but still not great. There are some Akka constructs IntelliJ underlines in red for years and JetBrains doesn't fix it. I've never seen something like that with Kotlin. The hard truth is that Scala was not designed with tool support in mind and it probably never will be. For example hierarchical implicit conversions, while powerful, are terrible for tooling.
    - hocuspocus 8y ago
      > Scala was not designed with tool support in mind and it probably never will be You should pay attention to what's going on in the ecosystem. Dotty comes with LSP support. The Scala Center's main focus is tooling. JetBrains has been pretty committed and cooperating as of late. And several projects are building serious alternatives to SBT.
  - dikei 8y ago
    Agree. In fact, we have a rule in our team that if a feature is not supported by IntelliJ, then it's probably too arcane and should not be used.
Cyph0n 8y ago
Scala syntax is decent tbh, unless you decide to go overboard with operator overloading. Most libraries — SBT is one example — have shifted away from the use of excessive overloading.
- profalseidol 8y ago
  That time when my boss started using "implicit" on everything. We were even using a new "Functional Relational Mapping" framework from Lightbend/Typesafe called Slick which was a mess.
- viach 8y ago
  Tend to agree. But if you work in a team, there will be someone who just loves implicits and overloading and you won't be able to change his mind. Strong code style policies help, but they are really rare in real processes.
  - aphexairlines 8y ago
    Your team can make a decision as a group to not allow defining operators in the team's codebase. As you mentioned you can then enforce that with scalastyle (set FieldNamesChecker and MethodNamesChecker regexes to ^[a-z][A-Za-z0-9_]*$). Is that not enough to handle the one person who loves overloading?

I see Kotlin as a great choice for these who don't want Java verbosity but can't really get used to read Scala.

by viach 8y ago

I see Kotlin as a great choice for these who don't want Java verbosity but can't really get used to read Scala.

jamougha 8y ago

I can read Scala fine but I'd like fast compilation and good IDE support.

jacobn 8y ago
The IDE support is pretty good these days, as least in IntelliJ.
- dominotw 8y ago
  Intellij still can't figure out how to handle implicits. At this point i have an intuition about the errors that idea reports as errors but actually aren't'.
  - threeseed 8y ago
    Are you using the latest version of IntelliJ ? Because it does a pretty good job with implicits now: https://blog.jetbrains.com/scala/2018/07/25/intellij-scala-plugin-2018-2-advanced-implicit-support-improved-patterns-autocompletion-semantic-highlighting-scalafmt-and-more/ https://blog.jetbrains.com/scala/2018/07/25/intellij-scala-p...
- Cyph0n 8y ago
  Not sure why you were downvoted. IntelliJ’s Scala plugin is top-notch in my experience.
  - edejong 8y ago
    True, nor do I understand your downvote.
  - IBalic 8y ago
    +1 works great
- _ZeD_ 8y ago
  Apart the fact that I would disagree on intellij support, what about the other ides? Eclipse? Visual studio (not code)?
- cryptos 8y ago
  Scala support in IntelliJ is ok, but still not great. There are some Akka constructs IntelliJ underlines in red for years and JetBrains doesn't fix it. I've never seen something like that with Kotlin. The hard truth is that Scala was not designed with tool support in mind and it probably never will be. For example hierarchical implicit conversions, while powerful, are terrible for tooling.
  - hocuspocus 8y ago
    > Scala was not designed with tool support in mind and it probably never will be You should pay attention to what's going on in the ecosystem. Dotty comes with LSP support. The Scala Center's main focus is tooling. JetBrains has been pretty committed and cooperating as of late. And several projects are building serious alternatives to SBT.
- dikei 8y ago
  Agree. In fact, we have a rule in our team that if a feature is not supported by IntelliJ, then it's probably too arcane and should not be used.

Cyph0n 8y ago

Scala syntax is decent tbh, unless you decide to go overboard with operator overloading. Most libraries — SBT is one example — have shifted away from the use of excessive overloading.

profalseidol 8y ago
That time when my boss started using "implicit" on everything. We were even using a new "Functional Relational Mapping" framework from Lightbend/Typesafe called Slick which was a mess.
viach 8y ago
Tend to agree. But if you work in a team, there will be someone who just loves implicits and overloading and you won't be able to change his mind. Strong code style policies help, but they are really rare in real processes.
- aphexairlines 8y ago
  Your team can make a decision as a group to not allow defining operators in the team's codebase. As you mentioned you can then enforce that with scalastyle (set FieldNamesChecker and MethodNamesChecker regexes to ^[a-z][A-Za-z0-9_]*$). Is that not enough to handle the one person who loves overloading?