Is there a focus project for kotlin?


#1

Hi,

Do we have a focus project that drives the development and enhancement of the language, is sponsored by the dev team, and letting people to come and contribute?

Rust is driven by a browser, Nodejs and Go focus on the server side, Scala has Akka and related projects, what is the focus of kotlin?

I’ve seen the kool project and a HTTP server going on, but they seem to have not been quite active.


#2

We don't have any special focus project for Kotlin, instead we have lots of different projects that we develop in Kotlin at JetBrains and there are number of people all over the world doing things with Kotlin. They are a little scattered, some are close-sourced, some are abandoned, but ecosystem is slowly growing.

Some projects are listed here: http://kotlinlang.org/docs/resources.html
More than 200 projects are found on GitHub: https://github.com/search?utf8=%E2%9C%93&q=kotlin
People are evaluating Kotlin for Android development, for iOS development with RoboVM or defrac, server-side development with Kara and Wasabi, desktop applications with KotlinFX, various applications using RxJava bindings and a lot more. We receive really good feedback from all kinds of application developers and that helps us shape language and ecosystem.

We don’t think it is really good to have single framework/application/project and proceed with language based mostly on feedback from it. It would likely cause adding syntax and features to language which are mostly suitable for this particular application and hardly useful in many other places. We want to have truly general-purpose language, which is well-suited for a variaty of problems to solve.

At JetBrains we are using Kotlin to develop Kotlin, parts of IntelliJ, internal web applications, and so on. Due to some reasons not all of them are Open Source yet, but many of them will be eventually. Stay tuned :slight_smile:


#3

Will you use kotlin to replace Java as your main language in JetBrains? Will you port IDEA source code to kotlin? That would be a huge code base.

Talking about internal web applications, what web frame work do you use with kotlin? I was interested in Alex Tkatchman’s kotlin-vert.x project , but the it was abandoned seemingly. I see there is Hariri’s wasabi framework, but not sure whether that is gonna take off. What are your opinion about it? In the server side, a focused project recognized officially (like Play framework in Scala) would be great.

Another topic is cloud computing. Do you plan to make cloud frameworks in kotlin (such as Spark in scala and Storm in clojure)?


#4

Would you mind sharing which of the JetBrains products are using Kotlin?


#5

It is unlikely to port the whole IntelliJ code base to Kotlin. We are currently investigating how it works in such a big project. Compiling, performance, CI, debugging, exception processing, cross-language refactorings and quick fixes - there are lots of things to verify besides bytecode compatibility and interoperability. Here we focus on as smooth Java interop as possible. Of course, this also helps us understand how it will work for other projects gradually introducing Kotlin into code base.


#6

For web applications, we have a fork of Kara (MVC-style), and couple of internal applications (like internal portal) are running on that, but we are looking into modern server side frameworks, with APIs, reactive, scalable, you name it :) It's really hard to balance between DIY solution, Not-Invented-Here syndrome, using existing frameworks with Java API, adding thin Kotlin layer on top, and doing other fancy stuff to do as little as possible but still have awesome Kotlin experience and not just boring interop.

For cloud, I cannot really say anything meaningful right now, we didn’t investigate much in this area. In terms of frameworks, we are expanding research area from “local” frameworks that don’t depend much on execution environment (like standard library collections), to some bigger scale like server framework, and then we’ll move to cloud. Or to the Internet of Things, wichever will be bigger in couple of months.


#7

There are IntelliJ plugins in Kotlin, few internal web sites, some number of home-brew tools, Kotlin itself of course. Not much of products in use and tonns of experiements here and there.


#8

What library do you use for internal websites? Tomcat/Spring? Wasabi? Kara?


#9

Fork of Kara on Tomcat.


#10

abandoned seemingly. I see there is Hariri's wasabi framework, but not sure whether that is gonna take off. What are your opinion about it? In the server side, a

Is there anything specific that has led you to think that? Not saying you're necessarily wrong but interested to know your opinion if you've looked at it. It still needs quite a bit of work, has to be said.


#11

Sorry if I have used wrong words, what I meant was that I didn't know about:

  • whether wasabi is officially maintained by the company
  • whether there is an active community
  • is it collaborating with kara (similar to scala’s spray/play)
  • is it performance oriented

I cared about performance especially. I’am using vert.x in our company as a high performance httpserver, but as time goes vert.x turned to be more application oriented and became a quite huge framework, losing the focus on performance tuning, so we are on the way to turning back to a netty based sulotion, which means we still gotta write the routers and the like.

I like how kotlin provides inline and datatype and the expressiveness without losing performance, so got quite interested in your wasabi project, which looks quite like what I would like to use.
However, I found that the activity seems low on google groups.

Hadi, what is your vision on wasabi? what is your main focus of it? how important is performance here?


#12

It's not officially maintained, beyond that I work on it and a few PR's from others at JetBrains (a couple of people have used it on some prototype projects). All the socket support for instance is being done by Dale Anderson (community member).

Currently there’s not really any community let alone active :). I’ve not really announced it or give any talks about it because there’s still work left to do on it also.

The goals of Wasabi are:

  1. Performance, which is why I’ve used Netty under the covers.
  2. Leveraging HTTP and automating as much as possible

I’ve worked for many years writing web applications and HTTP endpoints and know exactly what is I’ve had to do over and over again manually, and what things can be automated. Having worked previously with ASP.NET MVC and then moving to Express.js, Wasabi was born out of my preference for a static language and also improvements on what these frameworks have offered.

On the roadmap, apart from fixing some issues and doing more performance tests and ironing out any bottlenecks is potential integration with vert.x (have to see if that would be beyond the service bus).

Right now, I'm using it myself (as is Dale) for a project and shape and fix things as needed, so early adopters more than welcome :).


#13

As for vert.x integration, do you mean wasabi can switch it's backend from netty to vert.x? that sounds interesting.

But for highperformance servers, I think vert.x has chosen a wrong direction: Polygot and dynamic. Even if it has netty backed, the dynamic nature of the framework makes things slower than expected.

By using vert.x, I’ve learned some things that we want for a performant http server:

  1. copy as little as possible. Vert.x, especially it’s eventbus, is based on JSON, which is a mutable datastructure, so in order to avoid race conditions and multithread problems, it copies the message on every access, which creates a lot of memory waste. For kotlin we have immutable data, which natually avoids multithread problems, so no need to copy locally.
  2. Don’t use mutable JSON as internal data message format. It is too dynamic, takes a lot of space, and serialization is slow. Also, a static data class is always better than a variable JSON document-wise and helps the readability of the code. When I look at a function/method that accepts a JSON parameter, and not knowing what fields are in it (possibly five levels deep), it feels horrible. I think kotlin has this potential.
  3. need a RequestLocal data storage. Similar to Threadlocal, but is only accessible for each HTTPRequest. In this way you can get some ‘Global’ data but won’t need to worry about syncronization problems.
  4. manage request connections. When there are tens of thousands of connections hanging around, the server should be careful about keep-alive connections, it should have a mechanism to kill some connections for the sake of newer incoming requests.
  5. string/request param/other kind of object pooling. I haven’t looked into this too much, but currently GC burden is very heavy on our servers.
  6. lazy/partial parsing for incoming request parameters. For certain requests we know the pattern beforehand, and don’t need to parse all of its long request text to get our parameters.

And for another non-java related issue, does kotlin support Go style CSP? Or fibers? Those things will make the callback hell that node.js and vert.x introduces go away without losing performance.

So what we really want is:

  • static data scheme
  • lazy
  • immutable messaging without copy
  • mutable RequestLocal data/ or other solution that makes multiple computation units share data easily
  • CSP stayl or fiber based blocking async I/O instead of callbacks
  • memory management
  • connection management

#14

zhaopuming wrote:

As for vert.x integration, do you mean wasabi can switch it’s backend from netty to vert.x? that sounds interesting.

Potentially. That's one avenue I'm looking at it. But the flip side being is I don't want to re-invent Yoke.

2. Don't use mutable JSON as internal data message format. It is too dynamic, takes a lot of space, and serialization is slow. Also, a static data class is always better than a variable JSON document-wise and helps the readability of the code. When I look at a function/method that accepts a JSON parameter, and not knowing what fields are in it (possibly five levels deep), it feels horrible. I think kotlin has this potential.

Right now in Wasabi JSON can be deserialized on incoming requests and serialized for outgoing. There is currently no static binding on incoming but that's on the roadmap.

2. need a RequestLocal data storage. Similar to Threadlocal, but is only accessible for each HTTPRequest. In this way you can get some 'Global' data but won't need to worry about syncronization problems.

Not built-in yet. But I've created Wasabi in a way so that pretty much every piece of functionality is an interceptor (i.e. middleware), and all the functionality you see in it right now is via interceptors. I'm guessing this would be possible too, much like some of the other points you mention.  

We could discuss some of the other topics in more detail if you like. It definitely seems that you know what you need and have experience, so I’d be happy to have further discussions and even have you collaborate on many of these if you’re interested. Feel free to ping me offline or on the discussion group (albeit it’s quite dormant there).


#15

Hi Hadi,

Thanks for the reply.

I’ll take a look into your code and also learn kotlin on the way :slight_smile:

I have to learn more about kotlin and netty(!) before really contributing to the project, in the meantime I’ll try to use it in some little projects.