Unfortunately, sources tell The Next Web that Google’s current mindset is that Kotlin is a bit too slow when compiling.
Is there any communication between JetBrains and Google on this issue? Do you plan to fix performance in near future? It would be very disappointing to see this battle lost.
Also, it seems Kotlin lacks audible marketing. Apparently Swift captures more attention for some reason. I think you need bold marketing strategy because it’s so bad that IBM already prefers rejecting Java ecosystem for Swift:
IBM is also working to make Swift ready for server-side functions.
Kotlin really needs to win one of the big players to get widely noticed. Does JetBrains have any solid plan beyond technical roadmap?
First of all, how do you know that there is an actual battle? The article in The Next Web lacks any sources. At the same time, it’s clear that adopting Swift for Android as a replacement for Java would require a complete rewrite of the entire application framework, which is extremely unlikely to happen.
(Also, the article was published before Google I/O. If Google indeed had specific plans to move away from Java in a reasonable time frame, they would have announced those plans at I/O.)
Second, of course we’re working to improve compilation performance. The incremental compilation support for Grade that we released in Kotlin 1.0.2 is a large part of that work.
Third, where did you get the information that IBM prefers rejecting the Java ecosystem? IBM has a huge amount of resources, and a huge amount of investment in Java. They can allocate a small percentage of those resources to improve the Swift support on the server side without any impact to their Java-related efforts.
Finally, with announcements from Spring and more recently Gradle, I think it’s quite clear that Kotlin does get noticed by fairly major players in the ecosystem.
Of course, if you have specific suggestions for what we should be doing in addition to our current efforts, you’re welcome to share your ideas.
If compile time is the only issue then the jack/jill and incremental compilation work should resolve that. Kotlin isn’t really much slower to compile than Java when used in a plain old project.
That’s good to hear. One could say about Swift that it is a language that is promoted by Apple but not used by them. That is something you can’t say about JetBrains.
It already has: JetBrains. They probably are the largest vendor of Java desktop applications (sold through retail, besides maybe JDownloader). From my observation, they are always putting their money where their mouth is: they were unhappy with JBuilder, thus they created IDEA. They needed to build their products, thus they created TeamCity. They were unhappy with how JIRA handles things, thus they created YouTrack. They were sitting on millions of lines of production Java code, thus they started working on Kotlin.
they have improved documentation a lot (thank you guys)
this forum is very nice (great people and great usability)
the slack channel is very active with new people coming in every day.
But for the sake of completeness, let’s check which other major players could be there to address:
Oracle: Unlikely that they switch JEE and their highly priced products over to a technology they don’t control. That’s just not going to happen. Not even if JetBrains sponsors one or multiple yachts to certain people. Currently they are scared as hell that nobody needs their overpriced application servers anymore. Besides that Kotlin is not happening for them: they have a lot bigger fish to fry.
Google: Is currently fighting against Oracle. I guess, that’s why they are careful about their strategy in regard to Java. I’m also not seeing how you could seamlessly integrate existing Android applications with frameworks written in a native language (e.g. Go). I was hoping that they would embrace Kotlin (instead of Java 8 for Android, though). But let’s see how that turns out.
Spring: Spring boot supports Kotlin. As long as it runs with their frameworks on the JVM, it’s fine with them.
IBM: Not even IBM knows what IBM does.
Lightbend: Even though they are a Scala shop they are now marketing a framework strongly targeted at Java developers. I just don’t think Kotlin really is going to happen for them. They are are loud on marketing and collected a lot of venture capital funding, though.
RedHat: I suppose they make a lot of money from the maintenance contracts of their application servers (JBoss). Thus they probably are more interested in mingling with Oracles’ corporate customers than they care about a new JVM language.
SAP: not sure. Not even if this were a good thing.
cloud providers (Amazon, *Microsoft) are more about locking people into their platform. As Kotlin runs seamlessly on the JVM, it’s fine with them.
I’m sure there are more companies that I could mention. But the future of Kotlin probably is not any of them. But developers like you and me are.
I’ve read the speculations about Google planning to switch to Swift several times now and all this is based on a poor article based on a random discussion of some guys from Google and Apple on a conference. There is absolutely no substance in all this speculation.
From an economic point of view it doesn’t make sense to throw all the Android code just to use a somewhat popular new language.
Now, I might become unpopular… Not meant to be rude, but I think there is some truth to it that JetBrains also could have picked Groovy. Again, just my personal thought ;-).
Coming back to the discussion itself I don’t think Google would choose a language from Apple where they would have to take everything the way Apple things it suits best >their< needs. They would chose something they can influence. If I were Google I would just buy JetBrains if I had an interest in Kotlin.
Other than that I think Swift is not considered as it doesn’t have a GC. A language for application development without a GC stands absolutely no chance. The fact that Apple can afford Objective-C/Swift not having a GC is only because them being the manufacturer can dictate what language people are bound to use.
[quote=“Oliver_Plohmann, post:6, topic:1707”]
A language for application development without a GC stands absolutely no chance.
[/quote]
I’d say there are plenty of applications developed in C++. What is the problem with having no GC? Also Swift has reference counting and Rust has a semantic to simplify safe memory management.
Red Hat’s JBoss team is actually working on Ceylon, another language with a proper type system and good Java interoperability. Probably for much the same reasons that JetBrains decided to develop Kotlin.
I actually discovered Kotlin when looking for something like Ceylon but with proper Android support.
Thanks for pointing that out. I missed Ceylon in my post.
But: has anyone ever seen Ceylon being used in a project? There hardly seem to be any Github repositories. Thus, I’m wondering whether Ceylon really exists…
BTW: I have very rarely heard iOS developers complaining about the missing garbage collector. They seem to be mostly happy with what ARC has to offer.
BTW: I have very rarely heard iOS developers complaining about the
missing garbage collector. They seem to be mostly happy with what ARC
has to offer.
Well, that might be true. But when people using a language that has a GC such as Java, C#, Python, Ruby, Go, etc. have to change to disposing off objects themselves manually, they feel the difference in productivity.
I’ve not seen it used much in the wild myself - I suppose the JBoss team should be dogfooding it, the same way JetBrains is gradually rewriting IntelliJ in Kotlin?
Funnily enough one of the Ceylon core developer wrote a feature article about it in the latest issue of Java Magazine. The typing system (union and intersection types, nullable is just a syntactic sugar of Actual|Null) and module system (module dependency and versioning is baked into the source code) are interesting - but Kotlin looks like the more practical language at this point.
Regarding lack of garbage collector – for systems code where not having a GC is important Rust does look quite nice.
For those complaining about Kotlin compilation times, Ceylon compiles to Java source code which then has to be compiled so is always going to be slow.
Though I have never looked at Swift (and never will) I can say from when I used to do Objective-C the lack of GC was not as big of an issue as you would think. They do have reference counting and autorelease so it wasn’t like you had to free everything yourself. But I must say I did have to debug my share of leaks and access to objects that had already been freed.
The problem is that many developers aren’t good at doing their own garbage collection. Hence Java was invented after decades of developers struggling with C++.