I'm new here but I've skimmed past blog posts and I get the impression that:
- Originally it was planned to have a standard library, and there was one
- At some point there was agreement/realization that "rebuilding the world" was both too ambitious and it made the cost of moving from Java to Kotlin unecessarily high
From the blog posts it seemed like there was a lot of declarations in the early days of "no, we absolutely won't do that" and "we're definitely doing this," but somehow that softened as time passed and a more pragmatic approach was taken.
My current perception is that Kotlin is now a language replacement for Java. It gives you a much better programming experience without replacing the Java ecosystem (and requiring you to learn a new ecosystem). If I understand this correctly, then this is one of the reasons I continue to be attracted to Kotlin – such an approach is very similar to what made C++ successful, by allowing C programmers to move to C++ without suddenly changing their whole world. By focusing on the language only, you make the project much more practical AND more accessible for Java programmers considering the switch (“I don’t have to change/relearn all the libraries and frameworks I’ve gotten used to!”).
So, I hope I have that right. If so, that explains the disappearance of the standard library. Unfortunately there are numerous dead links now, and the new user is left to sleuth out possible reasons, as I have. So I suggest/ask for (A) some kind of description of these design decisions someplace (apologies if it already exists; would love a link to said description) and (B) Mentions and links to the standard library and similar items, if not removed/fixed outright, could just be lined to the description in (A).
For example, in https://github.com/JetBrains/kotlin, under the subhead “Contributing”, there’s a link in the first paragraph to “the standard library” which takes you to a place that makes that library appear to be dead.
Another idea that might help make things clearer to potential adopters and new users is a “Kotlin Manifesto”-type list, similar to “The Zen of Python” that you get when you start Python and type “import this.” This is similar to the “mission statement” of a company (yes, these are usually a joke but that’s because management doesn’t take it seriously) which, when used right not only gives everyone a sense of “what we are about” but also helps make decisions (for example, Zen of Python’s “one obvious way to do it” vs. Perl’s “always more than one way to do it” – which Scala seems to have unconsciously inherited).
Please correct my misperceptions here and direct me to documents that might clarify my understanding. Thanks!
– Bruce Eckel
There seems to be some misunderstanding going on.
I can’t remember us planning to “rebuild the world”. Compatibility with Java libraries was among our highest priorities from day one. Which blog post made this impression?
Nor has the standard library ever disappeared: it’s still there (https://github.com/JetBrains/kotlin/tree/master/libraries/stdlib, http://jetbrains.github.io/kotlin/versions/snapshot/apidocs/index.html), currently it mostly provides convenience methods for collections and such, but we will probably add some important data structures that are missing from the JDK, such as MultiMap etc. so the goal of the standard library is not to replace anything from Java, but to add what’s missing.
Thanks for the report on the broken link to the issue tracker, I’ve fixed it in the ReadMe, and here’s the correct link: https://youtrack.jetbrains.com/issues/KT?q=Subtask+of%3A+KT-2554+%23Unresolved
1 Like
but we will probably add some important data structures that are missing from the JDK, such as MultiMap etc. so the goal of the standard library is not to replace anything from Java, but to add what's missing.
Concerning MultiMap: There are already
org.springframework.util.MultiValueMap,
org.apache.commons.collections4.MultiMap,
com.google.common.collect.Multimap.
and this alone is two too many. It’s a pitty, that it’s not in the JDK, but the JDK evolves slowly and could unprobably keep up. Guava’s Multimap seems to offer everything (4 kinds of keys combined with 5 kinds of values, plus some immutable versions, see MultimapBuilder).
So I’d bet, that adding another one is a bad idea, but could you somehow use an existing implementation?
There were a lot of early posts and I was skimming -- sorry for the wrong impression, but that's one reason I'd like to see some kind of summary/overview/manifesto. Anyway, thanks for the clarification and as I gain further understanding I should be able to ask better questions.
We'll consider all possible options. Implementing data structures is fun, but if we can use something existing, we will )
No need to apologize. I'd love to fix this impression, we'll think of something like "manifesto". Thanks!
One thing I'd like to do is come up with a list of "best libraries" for the new user to install. When I wrote "Thinking in Java," the idea that "the standard library is the best" was still extant -- and indeed the standard libraries for both C and C++ were typically the best and most reliable. So I only talked about the standard library (which is all there was at the time) and never changed when the spotty design and implementation was "fixed" using external libraries. Now I've kind of woken up and seen that it's really important to tell people to select other libraries to replace/compensate for the Java standard library. No one should have to suffer with the Java standard library anymore, just because it happens to have been written by the Java creators.
Any idea where the best forum would be to start creating the ideal list of libraries (such as Guava, Joda-time, Commons math, SLF4J, etc.) might be? I think first of StackOverflow, but they don’t always like questions that ask “what’s the best”, for example: http://stackoverflow.com/questions/1046597/java-good-libraries-and-what-they-are
Also, what build tool is commonly used for Kotlin? Has there been any progress in that arena?
And what about testing? JUnit seems like it has way too much code overhead for a succinct language like Kotlin.
Unfortunately, I can't think of a decent place to ask for "the best" library set. There are reports on libraries' popularity though (e.g. http://www.takipiblog.com/githubs-10000-most-popular-java-projects-here-are-the-top-libraries-they-use/, http://www.77dev.com/2014/05/java-trends-top-100-mostly-used.html).
As for build systems: both Maven and Gradle work well with Kotlin, Ant is also supported.
Testing: there’s Spek (http://jetbrains.github.io/spek/)