I think that the Kotlin creators did a great job creating a readable language. I’m thinking of things like
for (item in collection)
or if as expression (instead of <condition> ? <true value> : <false value>)
val color = if (message.contains("error")) Color.RED else Color.GREEN
Another thing I find very readable is the range syntax: 12..18
What do you consider especially readable in Kotlin?
Lambdas! This is in contrast to other languages that include them with somewhat clunky syntax. I like that any naked {} blocks are automatically considered lambdas. I like that everything related to the lambda (i.e its body and params) is included within the {}. Of course with trailing lambdas and receivers, this makes it really easy to create syntactic scopes that make sense intuitively IMO (and hence function like very safe macros).
Data classes are my favorite. Not needing to define a bunch of getters and setters, toString and equals just makes for cleaner code.
I agree with OP that Kotlin is an exceptionally-readable* language** — as I’m sure I’ve said before. But for me, it’s not just specific features: they must have paid great attention to readability throughout the language.
This shows in countless little ways. For example, OP has already mentioned for (a in b), which is (unusually) more verbose than Java’s : (by 1 character!), but clearer as a result. This is in direct contrast with the class definition syntax which uses a simple : instead of Java’s implements and extends — the more concise form being justified as it’s merely sharing the syntax already used to give types of parameters, properties, and variables.
Another little improvement is the in operator. That’s just syntactic sugar: a in b translates to b.contains(a) — but it brings many improvements. First, it’s shorter, so less to read. Second, it puts the element first and the collection second, which is usually a much more natural order as it’s the element which is the ‘subject’. Third, it has a nice symmetry with the for (a in b) loop. And fourth, it allows a similar !in operator, which is much clearer and more natural to read than having to negate an entire expression.
Kotlin’s scoping functions (with(), let(), apply(), run(), and also()) can be a bit confusing, but I can’t imagine better names for them: they’re short and readable, and you’d have to add quite a few more words to make their exact function any clearer.
And I think the same applies to the by keyword for giving a delegate, the as and as? casting operators, and the is type-checking operator — all of which read so naturally.
Implicitly naming the parameter of a single-param lambda it makes some short lambdas far more straightforward than having to explicitly declare and name the param.
The use of fun for defining functions seems so much more natural to me than def, which has been traditional in functional languages but always confuses me — after all, functions aren’t the only things you can define…
In the standard library, there are a few method-naming conventions which I’ve not seen documented, nor used in any other languages, and yet help to make the meaning clear without taking many words. For example, in general:
verb() mutates its object in-place, without returning anything. Example: reverse()verbed() returns a mutated copy of the object, leaving the original unchanged. Example: reversed().toType() converts to the required type, independent of the original. Example: toString()asSomething() returns a view onto the original object (which will reflect changes to the original, and vice versa). Example: asReversed()orSomething in a method name tells you what it returns if the result would be invalid/null/missing. Example: toIntOrNull(),Of course, there’s a lot of overlap between readability and general language design. For example, one of the good things about Kotlin is that it tends to make the most-used and/or safest choices the default (closed classes, public methods and properties, etc.), so you don’t need to add qualifiers unless you’re doing something uncommon. This shortens code on average, and shorter code tends to be more readable (all else being equal).
But these are merely individual examples — as I said, it seems to me that a lot of care must have been taken across the whole language (and library) to make it all as readable as possible. That’s one of the things that makes it such a pleasure to use!
(* I found this very surprising, considering that as far as I know, English isn’t the first language of any of the original development team. Or maybe that gives them a fresh perspective? In any case, the standard of English in both the Kotlin language and its documentation is excellent. As someone who speaks only English — and is very fussy about it — I have a lot of respect for anyone who can use a second language so well!)
(** For languages of its type, anyway. Both COBOL and Applescript are also exceptionally readable, but have very different features, platforms, and mindsets. Well worth seeing, if only to to show what’s possible.
Kotlin straight up fixed java, i was starting to hate programming and considering to give it up, but changed my mind after finding kotlin back in the beta days (when android folk didnt even know it existed). To this day i see 0 reasons to use java the language… sure i use latest jvm or may use later version of jdk but kotlin alone was enough to be able to write readable code any time. It has very reasonable tools that work in various situation, but never forces you how to do things… unlike some overrated languages.