and I’m sure I’m not the only one

They are such fundamental operations I was surprised not to find them in the stdlib

esp given the richness of extension methods for collections, Iterable<T> etc

well, we want to keep stdlib very small. Collections are used by 100% of people, but functional composition probably not. Most people use functional types in a very limited way simple smile

I agree with Ilya, a small stdlib is an important selling point.

Why try to keep it so very small?

Android.

But in android development the code is proguarded, so unused methods get removed

Not in debug mode, for example, it would take too much time to round-trip. It is already very slow…

What we found was that we were writing more methods when we didn’t have funKtional than when we could just compose functions

And the bigger the APK the longer it takes to transfer to the device and install it

Also you can bookmark this page: https://kotlinlang.org/docs/resources.html We are often updating it.

natpryce: Proguard is not a panacea, you often have to write exception rules. Small libraries are essential on Android

Sure. We used proguard for JVMs with much smaller heaps than Android apps.

I really don't see any downside to leaving this in external libraries

Besides, scalaz started very small too and these days, it's as big as Spring to the point that competitive libraries are emerging with the value proposition of being much smaller

Hah!

Maybe Kotlin’s type system being less expressive than Scala's will stop that happening!

Well, there is another aspect of this. By having multiple libraries doing similar things, e.g. for functional things, promises and futures, etc it is making ecosystem a little bit fragmented. So that each project may select different combination of libraries, and projects build with Kotlin become slightly different. It’s not very bad, but makes it harder to jump projects, makes job market fragmented, harder to understand OSS projects, etc.

Yes. That was my assumption… that very fundamental things (like function composition) would be in stdlib, and higher level things or more domain specific things would be in libraries I pull in from Maven Central

But a lib is fine.

We have intention to review various libs a little bit later, and suggest authors to promote them to koltinx.* family. It is intended to be a collection of somewhat endorsed libs for various aspects. Right now we don’t have enough time to do it, unfortunately, but we’ll do it pretty soon after v1, I think. E.g. funKTionaly could become kotlinx.functional, and Kovenant could become kotlinx.promises. Of course, if their authors and maintainers will not be against this simple smile

That would be great

For now we are trying to keep resources page more or less up-to-date, but include everyone there, without much review.

Hi, While wring some code that I wanted to compile for both the JVM and js I noticed some java.lang. and java.util.* classes are defined in the js stdlib. This strikes me as a bit odd as I wouldn't expect to have references to java in code that would compile to javascript

most of those classes are very important (Exception, ArrayList, HashMap, etc.), wouldn't it be better to have them as part of kotlin.util.* and then have them mapped to their java counterparts (if that is possible)?

or maybe have kotlin specific implementations

my main issue with this is that if I want to target both the JVM and on javascript it's not very clear what classes I can use and what I cannot, knowing that anything in java.* is off limits would make things simpler

JavaScript is still very experimental so no documentation actually for that. There are only few minimal

java.*

classes declared in kotlinjs and it is planned to fix it in the future

you can eliminate some of such dependencies by the functions

arrayListOf

,

hashMapOf

and so on and types `MutableList`/

MutableMap