Hacker News Reader

Comment by kirse | Hacker News Reader

Would you say Kotlin is still experimental though? Scala appears to have a 10-year headstart, but time isn't everything.

I use F# and found Scala to be a breath of fresh air after getting sick of Enterprise-y Java, but haven't had the time to venture into Kotlin.

View on HN

Scala has been around longer, sure--but it's also a bunch of stuff that doesn't really work well together and I'm still not sure that most (not all, by any stretch) Scala programmers really know how to write a program in Scala that's there to be maintained over the long haul. It can be done, but the pull of the super-broad feature set seems so strong that most of the developers I know personally, including me, write code that's awful to read two months down the line because it's dense and featureful and so very clever (note: very, very pejorative; the line about needing to be twice as smart to debug code as you need to be to write it applies here).

Kotlin is literally Java plus sugar. That's all it is. It encourages doing the right thing through stuff you could totally do in Java but nobody does because it's awful to write in Java. And, TBH, for the 90% case that's pretty great. There's no Shapeless in Kotlin--but that's a good thing, because Shapeless encourages developers with skill but no taste to do awful things and inflict them on, say, me. ;)

So, no, Kotlin's not experimental. Because experimental is a mindset, not an alpha/beta release stage.

This is so very true. I find Scala tends toward the classic "read-only" joke. You can write very powerful code, but it's often hard to debug and it tends to be quite difficult to read down the line. We have a Scala application that is being slowly replaced, but which I maintain in the meantime, and it is by far my least favorite job duty, despite that I theoretically like Scala more than, say, Java.

Probably my biggest disappointment with Scala is really the type system. It's incredibly powerful, but it's unwieldy to use, and it's still full of footguns. "object" is great and useful until someone accidentally turns it into a giant race condition (true story). Traits can easily turn into a maintenance nightmare (ever seen an 8-way multiple inheritance scheme that fans out into 23 separate ancestor classes? I have!) Exceptions end up in a strange territory. There's ways to handle all of this (much of it involves "don't do that!"), but the point is that for all the type system's powers, it's not actually buying you that much except in comparison to Java 6/7. If I want powerful type magic, I can use Rust or Haskell or similar and get stronger guarantees from my compiler. If you're writing "better Java", which is traditionally one of the more common Scala uses, it's harder to justify over Java 8 or Kotlin these days.

All of which is to say, Scala is a really cool language, but I wouldn't write new projects in it if I didn't have to.

Bonus round: We had a Scala iOS app via RoboVM before RoboVM support was yanked. It still gives me nightmares.

Yeah, all that pretty much tracks for me. I think the best way I've heard it described is thus: you can write Perl in any language, but it's really hard to write Scala in anything else.

I wrote an Android Scala app once. I regret the experience.

Seems like you could make the same argument about modern C++ or other kitchen sink languages - lots of features, lots of ways to write unreadable code.

I've worked in Scala for the last 3 years and I've found implicits to be the biggest issue. They're hard to debug, it's not easy to tell which implicits are in scope. Things like that.

Being clever is a problem with the developer and not the language. Scala code is dense, sure, but that's not inherently a bad thing.

I would also say that most people should not write C++. To be clear, I like (Modern) C++ a great deal. I also like Scala a great deal. I don't think most programmers should write it.

I also like C++ a lot, but in what concerns the current OS trends from Apple, Google and Microsoft, even Qt Company, it appears its use is being shifted down the OS layers to pushing pixels, audio frames and driver data around.

With everything else built on top of it with safer languages.

This is quite clear with the set of APIs that are being made available to C++ on those OSes.

Yea, implicits were definitely confusing at first. That and picking a thread pool required a lot of reading. There seemed to be some other outset issues like "avoid this seemingly innocuous operation since it actually has a huge perf hit", but those usually manifest quickly and get eliminated with any sort of application tuning.

Reply on news.ycombinator.com