Item — HN Reader

I completely agree with their pragmatic approach to Scala. Scala is a very powerful language, and you can do super crazy stuff. My approach to writing Scala code is similar:

1. Write the code like a better-Java/typesafe-Python (that is, imperative style).

2. Glance through the code. For collections, usually there's a more concise approach.

3. Read the code again. If you think what you did in #2 is making the code _too_ concise, you might need to think twice (or add comments).

3 comments

Regarding 1, wouldn't Kotlin be a better choice?

I don't think so. Kotlin is an unmaintainable soup of features: it can match all the selling-point examples of Scala but only by adding ad-hoc special cases for each one. (For example, Kotlin has null safety and it lets you write code using errors-as-values style "either" types - but it has two completely separate syntaxes for these things, and so it's impossible to interoperate or reuse code between those two approaches). In practice Kotlin codebases still use magical incomprehensible reflection (Spring Boot) and magical compile-time manipulation (Kapt), so you have the worst of both Java and Scala worlds.

> Kotlin is an unmaintainable soup of features

Are you sure you're not confusing Kotlin with Scala?

> For example, Kotlin has null safety and it lets you write code using errors-as-values style "either" types - but it has two completely separate syntaxes for these things, and so it's impossible to interoperate or reuse code between those two approaches

And that is a problem how? Stick to one style.

> In practice Kotlin codebases still use magical incomprehensible reflection (Spring Boot)

https://github.com/spring-projects-experimental/spring-fu/tr...

> and magical compile-time manipulation (Kapt)

There's nothing magical about it.

> And that is a problem how? Stick to one style.

Switching an API from "a result or nothing" to "a result or an error message" happens all the time, and switching in the other direction is only slightly less frequent. And of course most programs have some APIs where one is appropriate and some where the other is. So consistency is valuable.

> https://github.com/spring-projects-experimental/spring-fu/tr...

Still reflection-based.

> There's nothing magical about it.

It's magical to anyone thinking in the language - it breaks the rules of the language, so you can't reason about what it does.

This is a poor straw man argument. Spring boot is an option, but so is Ktor, or Dropwizard. You are arguing you preference as fact.

I'm arguing my lived experience of working on Kotlin codebases. It's not about the specific framework, it's that people always use a framework that breaks the rules of the language, just like in Java, because the language itself isn't expressive enough. Whereas the thing that makes all those complex Scala libraries worthwhile is that they enable you to make a whole enterprise-scale codebase using just plain functions and values.

I think no, because, IMO, Kotlin doesn't have a good pattern matching like Scala.

4. Switch to Kotlin or Java

> that is, imperative style

Yikes. Just switch to Java already.