Earlier quoted context omitted.
Each does different things, and Rust also has plenty of them. and_then(), or(), or_else(), then(), the list goes on. Kotlin just implements them more widely. Actually, Kotlin's with() and apply() are more powerful than what Rust can provide. Then again, Rust isn't designed with OO in mind, so you probably shouldn't use those patterns in Rust anyway.
I think you've misunderstood the point they were making by addressing the number as if it was the only concern and then only mentioning the actual point they were trying to make as if it were an incidental afterthought. I don't think it's likely they're criticizing five functions in the standard library is too many, but that having five special functions with certain semantics that only apply to them is too many. The…
also: https://github.com/JetBrains/kotlin/blob/2.3.0/libraries/std...
apply: https://github.com/JetBrains/kotlin/blob/2.3.0/libraries/std...
let: https://github.com/JetBrains/kotlin/blob/2.3.0/libraries/std...
with: https://github.com/JetBrains/kotlin/blob/2.3.0/libraries/std...
run (two overloads): https://github.com/JetBrains/kotlin/blob/2.3.0/libraries/std... and https://github.com/JetBrains/kotlin/blob/2.3.0/libraries/std...
These all heavily rely on Kotlin's ability to write an extension function for any class. When you write `with(x) { something() }` you're extending the type of `x` (be that int, List, or SomeObject) with an anonymous method, and passing that as a second parameter.
Consider the signature here:
public inline fun with(receiver: T, block: T.() -> R): R
Let does it kind of diferently:
public inline fun T.let(block: (T) -> R): R
So for instance:
val x = makeFoo()
with (x) {
bar = 4
}
fun Foo.anonymous() {
this.bar = 4
}
val x = makeFoo()
with(x, Foo::anonymous)
The type inference is doing a lot of heavy lifting, i.e. taking a lambda and automatically turning it into an anonymous extension function, but it's nothing that you cannot do yourself. In fact, a wide range of libraries write what might look like macros in Kotlin by leveraging this and the fact you can define your own inline operators (i.e. https://pl.kotl.in/TZB0zA1Jr).
This isn't possible in many other languages because taking a generic type definition and letting it possibly apply to every single existing type is not exactly popular. Combined with Kotlin's ability to extend nullable types (i.e. this = null) as well makes for a language system that wouldn't work in many other flexible languages.