Kotlin 1.1 Released with JavaScript Support, Coroutines and more

Members of our community have translated this blog post into several languages:

Today we release Kotlin 1.1. It’s a big step forward enabling the use of Kotlin in many new scenarios, and we hope that you’ll enjoy it.

Our vision for Kotlin is to enable the use of a single expressive, performant, strongly typed language across all components of a modern application. Kotlin 1.1 makes two major steps towards this goal.

First, the JavaScript target is no longer experimental, and supports all Kotlin language features, a large part of the standard library, as well as JavaScript interoperability. This allows you to migrate the browser frontend of your applications to Kotlin, while continuing to use modern JavaScript development frameworks such as React.

Second, we’re introducing support for coroutines. As a lightweight alternative to threads, coroutines enable much more scalable application backends, supporting massive workloads on a single JVM instance. In addition to that, coroutines are a very expressive tool for implementing asynchronous behavior, which is important for building responsive user interfaces on all platforms.

Coroutines

Coroutines in Kotlin make non-blocking asynchronous code as straightforward as plain synchronous code.

Asynchronous programming is taking over the world, and the only thing that is holding us back is that non-blocking code adds considerable complexity to our systems. Kotlin now offers means to tame this complexity by making coroutines first-class citizens in the language through the single primitive: suspending functions. Such a function (or lambda) represents a computation that can be suspended (without blocking any threads) and resumed later.

Technically, coroutines are light-weight means of cooperative multi-tasking (very similar to fibers). In other words, they are just much better threads: almost free to start and keep around, extremely cheap to suspend (suspension is for coroutines what blocking is for threads), very easy to compose and customize.

We designed coroutines for maximum flexibility: very little is fixed in the language, and very much can be done as a library. The kotlinx.coroutines project features libraries on top of Rx, CompletableFuture, NIO, JavaFx and Swing. Similar libraries can be written for Android and JavaScript. Even many built-in constructs available in other languages can now be expressed as Kotlin libraries. This includes generators/yield from Python, channels/select from Go and async/await from C#:

An important note. With all the benefits that they bring, Kotlin coroutines are a fairly new design that needs extensive battle-testing before we can be sure it’s 100% right and complete. This is why we will release it under an “experimental” opt-in flag. We do not expect the language rules to change, but APIs may require some adjustments in Kotlin 1.2.

JavaScript support

As mentioned above, all language features in Kotlin 1.1, including coroutines, work on both JVM/Android and JavaScript. (Reflection for JavaScript is not available, but we’re looking into it.) This means that a web application can be written entirely in Kotlin, and we already have some experience doing that inside JetBrains. We will publish tutorials and other materials about this soon.

Kotlin for JavaScript has dynamic types to interoperate with “native” JavaScript code. To use well-known libraries through typed APIs, you can use the ts2kt converter together with headers from DefinitelyTyped.

We support both Node.js and the browser. The Kotlin Standard Library is available for use through npm.

Tooling

Kotlin 1.1 is not a major release for Kotlin tooling: we prefer shipping tooling features that do not affect the language itself as soon as they are ready, so you’ve seen many such improvements in Kotlin 1.0.x versions. To highlight a few:

Kotlin plugins for all the major IDEs: IntelliJ IDEA, Android Studio, Eclipse and NetBeans

We’ll keep working to make our tooling even better and deliver the updates in 1.1.x versions.

First year of Kotlin: Adoption and Community

In short, Kotlin is growing. We’ve seen over 160’000 people using it during the last year. OSS projects on Github grew from 2.4M to 10M lines of Kotlin code (about 4x). Our Slack community has grown from 1’400 to over 5’700 people (over 4x). Numerous meet-ups and user groups are organized by the community around the world. We are seeing more and more Kotlin books and online courses published.

We are grateful to all our users, contributors and advocates in all parts of the world. Your support is very important to us!

Organize your own Kotlin 1.1 Event

Kotlin 1.1 is a good reason to meet up with your local user group and friends. We have prepared some materials to help you organize such an event. On March 23 we’ll stream live sessions featuring the Kotlin team members, plus there’s an organizers pack that includes some swag and a Future Features Survey. Get more info and register your event here.

What’s next

To make Kotlin a truly full-stack language, we are going to provide tooling and language support for compiling the same code for multiple platforms. This will facilitate sharing modules between client and server. We will keep working on improving the JavaScript tooling and library support. Among other things, incremental compilation for the JavaScript platform is in the works already. Stay tuned for 1.1.x updates.

Java 9 is coming soon, and we will provide support for its new features before it ships.

We expect a lot of feedback on coroutines in the upcoming months, and improving this area of the language (in terms of both performance and functionality) is among our priorities.

Apart from this, our next release will be mostly focused on maintenance, performance improvements, infrastructure and bugfixing.

P.S. Running on multiple platforms is a strategic direction for Kotlin. With 1.1 we can run on servers, desktops, Android devices and browsers, but in the future we are going to compile Kotlin to native code and run on many more platforms (including, for example, iOS and embedded devices). A great team here at JetBrains is working on this project, and we are expecting to show something interesting fairly soon. This does not target any particular release yet, though.

Compatibility. In Kotlin 1.1 the language and the standard library are backwards compatible (modulo bugs): if something compiled and ran in 1.0, it will keep working in 1.1. To aid big teams that update gradually, we provide a compiler switch that disables new features. Here is a document covering possible pitfalls.

Is absence of webpack loader is a show-stopper for you? What about building JS files from Gradle and then feeding these files to webpack? It’s not very convenient, but at least makes it possible to develop apps for browser.

Thanks for info. I’m really looking forward to this. We’re using Webpack + Maven currently but I’d be happy to test KotlinJS for frontend code since we now use Kotlin on the backend part of the application with great success.

The project has a fairly large JavaScript code base (ES6 via Babel). Migrating all the code to Kotlin wouldn’t be an option but it would be really nice if we could use KotlinJS for new modules and integrate them into the existing Webpack bundle.

Cobertura works by analyzing .class files and should work with Kotlin without any special support from our side. For SonarQube, we don’t have any short-term plans to create a plugin, but it doesn’t have to be us – anyone from the community can build one.

Are you using ts2kt converter or use custom lib in this React project?

Right now we are using handwritten declarations.

When I tried to apply it to DefinetilyTyped/react, there were a lot of unresolved references.

Thank you, I see some bugs in converter with it and I’ll take a look to it.
Unfortunately, not all TS declarations can be converted to Kotlin fully automatically, sometimes it requires some manual works. We’ll continue working on the converter to minimize the number of manual works.

In general, right now ts2kt works better with declarations from types branch since master branch heavily use futures from TS 2.0+

Thanks, it would be interesting to have — at least a reference — to an explanation how your Actors approach is different to Scala’s Actors implemented in Akka. And in case you create something similar to Akka, please don’t call it “KAkka” 😉

For one key difference, actor with coroutines is just one particular code pattern (a coroutine that receives on its inbox channel). You are not limited in combining channels with coroutines in this particular way that an actor model prescribes. Look at other examples. You can have coroutines that produce streams of elements (they don’t have an inbox at all) or ones that receive from multiple channels simultaneously.

The other difference is that Akka is a pretty big framework, while coroutines and channels (that you can combine to write actors) are just small library utilities.

CSP and actors are a very different approach to concurrency. Go from Google is entirely based on CSP (well, the Go-variant of CSP). There is this very famous presentation about CSP in Go by Robert Pike (the Go language development lead) with the title: “Concurrency is not parallelism”. This will give you some idea about it, see https://blog.golang.org/concurrency-is-not-parallelism.

Actually, CSP makes concurrent programming a lot easier than actors as you don’t have actors that send messages asynchronously to other actors. Asynchronous programming is inherently difficult and Akka makes no difference to this (although the marketing slogans are sometimes different …). In CSP you have coroutines that do blocking takes from channels. So you can see exactly how the message flow is taking place in your application, because you can see who puts what into which channel and who takes from them. A blocking take means that the thread is waiting on the channel and cannot be reused till the channel receives some items. This is not a problem in CSP, because there can be many many coroutines (think fibers instead of threads). This is because coroutines have a reduced context and therefore do not use up that much memory. The downside of this is that coroutines in CSP are not pre-emptive.

I suggest you have a look at CSP in Go and CSP in general. This will give you some pretty good idea of this approach.

Is Kotlin going to be a viable alternative to TypeScript and Dart? Do you guys have an Angular application example written in Kotlin? What is the development process like? Is it tedious or as simple as hitting refresh on the browser?

I got the plugin notification in IntelliJ (2016.3.4) about 1.1.0 being released so I let it update and then I restarted. Then in my maven pom file I updated it to 1.1.0 but it says 1.1.0 can’t be found. 1.0.6 is found but not 1.1.0… I get this error:
Plugin ”’org.jetbrains.kotlin:kotlin-maven-plugin:1.1.0”’ not found

WebAssembly is a very new technology. Browser still provide it as experimental feauture, which is disabled by default. There’s no debugging support, no good interop with JavaScript APIs. WebAssembly does not provide support for GC and exception handling (and it’s very hard to implement own GC and exceptions, since WebAssembly does not provide access to stack). So I don’t see why it’s a better target than JavaScript. In long term prospect (I believe, not even this year) it might be.

Compiler to WebAssembly is quite easy to get. There’s LLVM backend that produces WebAssembly binary file, so when Kotlin Native team releases LLVM version of Kotlin compiler, we’ll get WebAssembly support almost for free.

In regard to “Running on multiple platforms is a strategic direction for Kotlin…”, are there any current plans/initiatives for making Kotlin run on .NET (or .NET Core in particular)? Similar to what RemObjects is doing with Swift – allowing it to run on both .NET and Java/Android (https://docs.elementscompiler.com/Silver/)?

This would open up a huge direction for working on top of a mature, battle-tested web stack (ASP.NET and Entity Framework) which is CENTRALIZED unlike the fragmented and ill-supported Java alternatives. .NET is really one of the only centralized server stacks that provides a model similar to iOS/Android on the server-side, and is mature/scalable/enterprise-grade.

I think this would be a huge advantage for Kotlin and open up a new phase for our industry.

(To be sure, I am not asking for .NET Kotlin support as I noticed you have said above you do not plan to do, but rather, to create something similar for .NET whereby you could run a .NET application any and everywhere, including — and especially — the browser process.)