I think saying something it's simple because it's based on simple rules can be slightly misleading. This is why I like to distinguish the ideas of "complication" and "complexity".

To me "complicated" means that the rules of a system require a lot of information to describe, i.e. it has a lot of special cases and caveats to learn. Whereas "complex" is more about the variety of emergent patterns in a system which are necessary to understand it and interact with it effectively.

As an example, rules of Go are very simple, but we probably wouldn't call it a simple game. In contrast, the rules of Chess are rather more involved, with quite a few special cases. Both games can be called "complex", but I'd also say that Chess is more complicated.

So using these terms, it sounds like you're saying Scala is less complicated than Kotlin, whereas the parent is perhaps saying that Kotlin is less complex?

Interesting perspective, thanks. I'm not proficient with scala, and most of my attempts to learn more of it were to be able to read some bit of code in a tool or library that was giving me trouble. So... grains of salt and a that.

That being said, having gone through at least one book, and have read lots of code - I still find it very difficult to parse in my brain.

It feels more complex to me, because there seems like there are so many implicit things going on, where something like Kotlin makes efforts to be explicit (yet still strikes a nice level of conciseness). But that could also be my inexperience with scala.

Definitely read using an IDE rather than a text editor if you weren't already. Scala is the first language I've seen to really make intelligent use of the GUI - not in a dragging-boxes-and-arrows way, but with implicits that are visible subtly (green underline, expandable by mousing over) but not there by default. The way I see it, it's a novel middle ground for things that you don't want to be completely invisible, but don't want taking up a lot of space either, e.g. error handling (exceptions are completely invisible, go-style explicit error handling is too verbose) or access to mutable state, or async operations, or... (the for/yield sugar is similar, with a lightweight "<-"/"=" distinction between effectful operations and not, and then you mouseover to see what the specific effect is). Working with inferred types is also easier when you can mouseover or hit a hotkey to get the type of any expression.

Having different syntax for different kinds of effect as Kotlin does could be seen as more explicit I guess, but I find it actually makes it harder to work with - you have a lot more syntax to keep in your head, and you can't write generic code that works with multiple different effects. Other than that I don't think there's anything more explicit in Kotlin, and some things - error handling in particular - are definitely less explicit.