Community Building

I've noticed that the Kotlin community is pretty silent. You hardly ever see blog posts about it on Hacker News or Reddit, the Kotlin sub reddit has only ~ 400 members (compare this to ~ 12k in Rust, ~ 9k in Scala, ~ 17k in Go, 46k in Java). There are only 314 Kotlin questions on Stackoverflow (41k Scala, 3k Rust, 11K Go). This forum, you're just reading, has not much traffic, too. Maybe the Kotlin community is indeed very small (wouldn't that surprising in the pre 1.0 stadium) or it is simply a silent community.

However, I think that the community is a very important aspect for a language to succeed. I’m particular impressed how Rust built a community even before Rust 1.0. The Rust community is not only pretty big for such a new language but also described as friendly and helpful.

One problem I see for Kotlin is that it doesn’t have such a strong identification potential as Scala, because it is much closer to Java than Scala. In the Scala world everything is reinvented to be Scala like, whereas in Kotlin in most cases Java libs do their job. The actual problem with this is, that the Kotlin developers could get lost in the crowd of Java developers.

I’m not sure how the Kotlin community could be boosted, but I think that it is necessary.

  • Would it be possible that JetBrains dedicates more ressource on community building? I think of something like a community manager / builder or author. The Rust team, for example, hired a full time author.
  • make it easier to share code examples
  • create a tour of Kotlin like the Tour of Go
  • add a "recent postings" streams of this forum to the kotlinlang.org front page

Maybe we could use this discussion to collect further ideas.

Regards
Christian

medium wrote:

There is: http://try.kotlinlang.org/ & https://github.com/JetBrains/workshop-jb

I noticed this too, but I don't think it's a big deal.

The reason the communities for Go, Rust etc are so noisy is that they have to be in order to survive. These languages don’t interop all that well with others, and because libraries are THE biggest productivity booster and programmer can have (way more important than any language feature), they need lots and lots of attention to attract developers to their ecosystem. So we see endless posts on programming forums like “Check out this sudoku solver I made in Rust”,  “we rewrote our web stack from Ruby to Go and it got faster”, and other fairly ridiculous things.

As you note, Kotlin doesn’t have this problem due to the focus on Java interop and seamless upgrades of Java interfaces/codebases. Kotlin is useful immediately for all kinds of problems, even though there are very few Kotlin libraries out there. So there’s less incentive to be noisy as network effects are much less pronounced.

Anyway:

  • Kotlin does have a community guy (I think it's Hadi)
  • There is already a tour of the language, in the try.kotlinlang.org site

But in the long run I think what will attract the most attention by far, is developers converting their Java libraries to Kotlin using the J2K tool. If a developer sees a library they use start converting to Kotlin that will make a much bigger impression than any blog post or news article.

However for that to really start happening in a big way you need Kotlin 1.0. I maintain the most widely used Java Bitcoin library and I’m a big fan of Kotlin, but so far I’ve only used it for my own programs. I wouldn’t want to convert bitcoinj to use Kotlin until the language is completely stable, as it’d harm the libraries credibility to be written in a language that changes with every release.

I noticed this too, but I don't think it's a big deal.

But look at Groovy: it is much more concise than Java and engineered towards compatibility. So despite the fact that it is a dynamically typed language the goals are similar to Kotlin. And it seems like Groovy never built a solid community. There a very few (important) Groovy based tools or librarys around. Almost nobody talks about Groovy these days, there are very few books. So all in all it seems like the language failed to get traction on a sustainable level!

You say it, that there is not much need to pull developers in the Kotlin world because it is essentailly the same as the Java world. But Kotlin needs to attract deverlopers anyway. And I think you know how management works: they often only look what the others are doing and doing the same. Management in general is very risk averse.The more other companies and (potential) employees are using a certain technology, the more likely it is that a certain technology will be used. So the network effect is relevant for Kotlin.

There is already a tour of the language, in the try.kotlinlang.org site

I’m aware of it, but I think that the explanation part is a bit underrepresented. Compare Rust by Example or the already mentioned Tour of Go or Scala Tour (although I find the animation really annoying) with try.kotlinlang.org …

Kotlin has very little “lock-in” since you can use Kotlin from Java without thinking about it (and that is a good thing). In Scala you will most likely stay in the Scala world and try to convert as much code from Java to Scala as possible. This is good for forming a community and holding its members together.

One of the reasons, I think, is that Kotlin is not a community built language, nor is it a language built with a community. I don't think that's an issue but we have to recognize that Jetbrains maintains the language in the direction they want and that most request for comment on the blog are about decisions they already have made. I haven't seen a request for comment about a decision they made that finally ended up making them rethink that decision. Their request for comment process is mainly about warning the community and last checking if the decision they made is not a huge mistake.

Mainly we maintain some kotlin code and wait for Jetbrain to tell us what’s new and how to update the code at each new version.

Once again, I don’t think that it’s an issue : Kotlin is a very fast evolving language and I don’t think that a discussing and having a community board at that point would be benefficial. What kotlin needs first is a 1.0 stable version and because it is internally developped, they can work toward that goal a lot faster and easier.

So, I believe the Kotlin community is mainly a silent community because we are a user community, not an empowered community.

Note that kotlin is by far my favourite language, that I struggle each day at office to have it adopted by our developpers. So please, don’t take the above as a criticism :wink:

Go, Rust, etc are all pretty similar in that regard. The Go guys do what they want and seem to largely ignore feedback ("where are my generics" etc). I don't know if you can have a community designed language, really.

That ist a good possible explanation. However I think that diversity in the designer team is very beneficial for a language. Many developers don't like Go because it doesn't have generics. From my point of view it was a mistake in the language design to not include them, and maybe a "language design community" would have avoided it. Another benefit of letting others participate is that they will become proponents and multiplicators for the technology.

Sure, and JB do. I don't see them as being resistant to feedback. Nullable types have gone through several rounds of major changes, largely based on feedback gathered both externally and internally. They've always responded quickly to any bug reports filed, Andrey is happy to spend time explaining their reasonings to the userbase etc.

I don’t worry too much about this.

1 Like

But look at Groovy: it is much more concise than Java and engineered towards compatibility. So despite the fact that it is a dynamically typed language the goals are similar to Kotlin. And it seems like Groovy never built a solid community. There a very few (important) Groovy based tools or librarys around. Almost nobody talks about Groovy these days, there are very few books. So all in all it seems like the language failed to get traction on a sustainable level!

You seem to be confusing “level of buzz” with “level of usage/success”. Groovy has a great community, several multi-day conferences per year, massive download numbers, and a number of good books. It is one of the most successful alternative languages on the JVM (probably no. 1 besides Scala). Some reasons why there is less buzz around Groovy these days:

  • It’s a mature language
  • It’s very easy to learn for Java devs, hence it generates fewer questions than other languages
  • It’s mostly used for applications (e.g. Grails apps), tools (e.g. Gradle builds), scripting and testing (e.g. Spock tests), not so much for general-purpose libraries (which is what gives the most visibility)

To expand on the last point: With Groovy being a Java companion, there is less incentive to build a “Groovy universe” of libraries that can only be used from Groovy. And for language agnostic JVM libraries, Java is (sadly) the best choice.

-Peter

It's not always the case that we request feedback on decisions that have already been made. Just as a very specific example, the class object -> default object -> companion object rename was entirely driven by community feedback. The recent decision to require @ for annotations was also heavily influenced by external feedback (there are quite a few people on the team who really liked @-less annotations).

There was a nice start by @orangy to write a cookbook on how to use Kotlin in a complex example, how jb guys see it should be used. https://quip.com/JeEAA1OuMg5u It was much more clear for me why each particular feature was designed in that way. That would be great if that cookbook would be finished.

Hi Christian,

Just some insight into what we’re doing from our side. Currently on my team (Developer Advocacy), the only person that’s really covering Kotlin is myself. Unfortunately, my time is limited so I can’t get to write and do as much as I’d like. However, hopefully come the new year that will change as someone else might be joining my team to cover Kotlin pretty much exclusively.

We’ve also created as someone responded below, the Kotlin workshop, the try.kotlinlang.org site and of course the tutorials on our site, which was also aimed at making it easy for external contributors from the communitty and we really hope others will contribute. In addition to this, Svetlana and Dmitry from the team are working on the Manning book on Kotlin.

Also as a side note, just a couple of days ago we created an “unofficial” (for now) Slack channel for Kotlin, and you’re all welcome to join (kotlinlang.slack.com). Right now you need to ping me (hadi@jetbrains.com) to get invited but we’ll automate it soon.

pniederw wrote:

…

And for language agnostic JVM libraries, Java is (sadly) the best choice.

-Peter


Interesting point Peter.

How do the Kotlin guys see this issue?

Will Kotlin be the best language for writing language agnostic JVM libraries?

That would strongly encourage Kotlin adoption.

Neil

Once again, I don't think that it's an issue : Kotlin is a very fast evolving language and I don't think that a discussing and having a community board at that point would be benefficial. What kotlin needs first is a 1.0 stable version and because it is internally developped, they can work toward that goal a lot faster and easier.

For me, it’s not so much about having a 1.0 release. I’d rather stick with milestone releases than to make language design decisions without enough community feedback.

One  thing is really bothering me, though: nothing creates exceptions faster than the IDEA Kotlin plugin (and I’ve seen quite a few EAPs). It would be really nice if there were more frequent releases for the plugin that fixed the most important causes for exceptions before the next Milestone release. Switching to CI builds isn’t really an option because then you’ll get language changes before they are fully implemented.

As already mentioned, an author working full time is very much required to convince more people that this project really is alive.

About Groovy: if worked on a Groovy project for the last 2+ years. One thing that always bothered the whole team was that there are so many (sometimes magic) ways to achieve a goal. At best, online documentation was missing on how to do something, at worst it was plain wrong, incomprehensible or misleading. Yes, XmlSlurper and AST transformations, I am looking at you…

Please ensure that something like that does not happen for Kotlin. We should always know how an API/language was meant to be used…

On a side note: writing that response sucked the battery of my iPad dry. The forum software really needs attention…

I see no reason why it would not be. Kotlin classes export a conventional Java ABI. You should be able to convert an existing Java library to Kotlin and start using the new features without your users even noticing, in theory.

mikehearn wrote:

I see no reason why it would not be. Kotlin classes export a conventional Java ABI. You should be able to convert an existing Java library to Kotlin and start using the new features without your users even noticing, in theory.


Unfortunately, things aren’t that simple.

The biggest problem is that every library written in an alternative language will drag along dependencies (runtime, standard library) that can result in code bloat and/or nasty versioning problems for end users. Keeping binary backwards compabitility for class files and language runtime while continuing to improve the language is particularly tricky, but necessary in order to be able to use libraries produced using an older version of the language.

Another problem is that a non-Java library implementation will invariably leak into the user experience (stack traces, debugging, etc.), thereby complicating users’ lives.

So far, no language has solved these problems well enough to make it a compelling choice for libraries targeting a wide audience. I’d love to see Kotlin succeed in this (and its conservative approach will certainly help), but I don’t expect miracles.

I don't see why the Kotlin stdlib would be different to any other widely used dependency, like Guava.

The Kotlin ABI is basically Java+annotations. I guess for many types of class, the Kotlin ABI can break whilst the less-featured Java ABI of a class remains the same.

mikehearn wrote:

I don’t see why the Kotlin stdlib would be different to any other widely used dependency, like Guava.


That’s why I didn’t include the standard library under “particularly tricky”. However, the fact that the Kotlin standard library is written in Kotlin will likely complicate matters.

The Kotlin ABI is basically Java+annotations. I guess for many types of class, the Kotlin ABI can break whilst the less-featured Java ABI of a class remains the same.

This won't solve the problem for Kotlin consumers. Also, the Java->Kotlin interop guarantees seem fairly extensive (http://kotlinlang.org/docs/reference/java-interop.html#calling-kotlin-code-from-java).

Um, Groovy is huge, I saw a tweet recently with a really, really high user count for Groovy.  Bad example.

I don't worry about it either.  Make a strong case for feedback, and have a good discussion with Kotlin committers.  It works.  If you don't reach out to them, or show up unprepared, you are less effective.  Or if you show up late to the game, it'll take time for it to have an affect.  Plus, they need 1.0 more than they need big language changes right now.  So let's get to 1.0 then worry if we have a problem going forward.  I personally don't think so.  I'm glad that Kotlin is conservative and keeping the language small, it is analysis based decisions, not emotional (mostly), and is trying to set a base that we can add to later.  No sense adding everything early, then finding out we hate things and having resistance to removal.