Questions on features


#1

Can you please honestly tell me what the pros and cons of Kotlin are? Not just the marketing stuff. Can I just write a part of my code in javascript and it will execute in the same thread, then it will continue with "java"? How would that work, I think you are blocking java, then starting up a new thread/(fiber, whatever) in V8 right? How exactly did you implement it? Can I write javascript, then have Kotlin call it seamlessly, use javascript objects, send them around, instantiate with Kotlin and vice versa? What about C interop, did you improve on JNI? Golang has very good C interop. What about performance, does it have Java performance? Can I write functions outside of classes in Kotlin? That's actually pretty important to me, I hate(!) forced object orientation. When is it production ready?


#2

Can you please honestly tell me what the pros and cons of Kotlin are? Not just the marketing stuff.

Have we already been dishonest with you?

Can I just write a part of my code in javascript and it will execute in the same thread, then it will continue with "java"?

No, and I can't see a sensible use case for it. We compile to JS to run it in the browser.

Can I write javascript, then have Kotlin call it seamlessly, use javascript objects, send them around, instantiate with Kotlin and vice versa?

Today you can use jQuery seamleassly from Kotlin, native JS interop will be improved over time.
What about C interop, did you improve on JNI? Golang has very good C interop.

JNA improves over JNI. We are experimenting with Objective-C interop now.

What about performance, does it have Java performance?
Yes
Can I write functions outside of classes in Kotlin?
Yes, have a look at the examples.
When is it production ready?
There's no fixed release date

#3

> Have we already been dishonest with you?

Implied dishonesty, you or the website have not mentioned any temporary or permanent drawbacks of your language.

> No, and I can’t see a sensible use case for it. We compile to JS to run it in the browser.

But then why wouldn’t I just use Dart? What does Kotlin have over Dart? I suppose Java is going to be faster than the Dartvm on the server.

> JNA improves over JNI. We are experimenting with Objective-C interop now.

But JNA sucks and nobody needs Objective-C interop except people who build apps for Apple. There's already a billion solutions out there to build apps for Apple cross-platform.

> Does it have Java performance?
> Yes

Why are you lying, clearly Kotlin will make use of the dynamic language runtime in Java, therefore slower than normal java.

> There’s no fixed release date

But you must have a guess on when you think it can be used on real applications.


#4

Kotlin and Dart both compile to JS. But on the server, Kotlin's Java integration means that you can leverage the maturity and large amount of existing libraries. Dart has pretty much nothing right now and will take a very long time to build up that level of support, if it ever does. Kotlin on the other hand is relatively risk free in the sense that there's going to be VMs on server platforms for any reasonable timeframe. Even if Kotlin is abandoned, you wouldn't have to kill you code base, and you could slowly move code over to Java or Scala or whatever other language you want.

nobody needs Objective-C interop except people who build apps for Apple”

This is a fairly silly statement. I could just as easily say “nobody needs JS interop except for people whoe build web apps”. iOS is a massive customer base, and big enough that it’s worth trying to improve the state of app development. Whether it’s the right thing to be spending time on is of course up for debate (I’m more of a server developer, so I’d prefer to see the VM progress), but using Kotlin for iOS app development would be pretty awesome.

But you must have a guess on when you think it can be used on real applications.”

While not in production, I’ve got a pretty involved web application built with Kotlin that I’ve been developing for a few months and I don’t see any issues that would prevent it from going into production. Yes, there have been some bumps in the road, but those issues come up most at compile time. It usually just means using slightly different code. And even that hasn’t happened too much lately. There’s still stuff that’s not that that I’d love to have sooner rather than later (modules), but nothing has really gotten in my way.


#5

The biggest risk for a new language such as Kotlin is sustainability. It is whether five years from now the community will stay active and the language will continue to evolve. In the .Net world, we see a promising language such as Boo (http://boo.codehaus.org/) stuck in stagnancy.

I decided to invest in Kotlin because I like Android and Java is simply not an acceptable language to program in it. The good thing is that Kotlin is a slender language and you can pick it up in a day or so. So why not dip your toes in the water and see what’s it about (beyond the marketing).


#6

The Kotlin site have sections comparing it with others languages (Java, Scala) some people will extract drawbacks from it, But you could share your own experiences with the language in this forum, this will  help a lot the community

At this moment I don’t see any Kotlin features that use dynamic runtime (“Dynamic” features are discused but not implemented yet, altough JDK 7 will improve greatly the performance). The better way to know is trying the language be yourself. The kotlin plugin for IntelliJ have a nice feature, a bytecode viewer; so, you’re always aware of the possible runtime penalties that your code will have, a very honest feature if you ask me. In the praxis I found that Kotlin performance is comparable with Java.

And a less agressive attitude will be totally OK


#7

Well, I can see that Kotlin uses backticks for escaping. I don't know american keyboards, but on a german keyboard this is hell. Then another thing I saw is that you removed the normal for() loop and replaced it with the for-in. I don't know why designers make this decision, but I suspect it's a cultural thing. Clearly the normal for loop is as concise and efficient as possible. The for-in loop saves is a tiny, tiny typing effort, but in 80-90% of the cases you need the control of an actual for loop later on, forcing you to add counters for the loop yourself, adding conditions yourself... it just doesn't make sense to have a for-in and discard the for. Then you require me to write "fun" in front of every function. It's redundant, where's the return type? And how much typing does it really save to go from "function" -> "fun". I mean, c'mon. Yeah, apparently the return type is after the function signature. Okay, well most of the time I know the return type of my function when I start writing. There's a reason java / c / whatever syntax is so popular, it's not just circumstance and random.


#8

Check out Ceylon (http://ceylon-lang.org/). You might be happier with that language.


#9

Just to comment on the for-loop. The standard 'for-loop' is anything but concise, and loads up all kinds of extra stuff that is almost never used. 99.999% of all the for loops I have ever written can be expressed in Kotlin as:

for (v in someCollection) {
}

or

for (i in 0…someValue) {
}

Especially in the first case, I’m not sure how it is worse than:

for (var i = 0; i < someCollection.size; i++) {
  val v = someCollection.get(i)
  …
}

For-loops in C and Java aren’t really iterators… they’re just ‘goto’ macros. I for one appreciate the attempt to make iterating more semantic.

That said, I would love the option of having the language automatically include an index parameter. Maybe use the ‘it’ value that is elsewhere that represents the state of the iterator:

for (v in someCollection) {
  val index = it.index
  val isFirst = it.first
  val isLast = it.last
}


#10

Well, I can see that Kotlin uses backticks for escaping. I don't know american keyboards, but on a german keyboard this is hell.

The same problem exists on German keyboards with {, }, |, , [, ] and other special chars and on keyboard layouts of other countries in the same way. { and } you use in absolutely every method whereas backticks are used very rarely.