Hacker News Reader

Comment by viach | Hacker News Reader

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

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

The IDE support is pretty good these days, as least in IntelliJ.

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.

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

Not sure why you were downvoted. IntelliJ’s Scala plugin is top-notch in my experience.

True, nor do I understand your downvote.

+1 works great

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

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

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.

Apart the fact that I would disagree on intellij support, what about the other ides? Eclipse? Visual studio (not code)?

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.

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.

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?

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.

Reply on news.ycombinator.com