Five Years Later, Google is Still All-in on Kotlin (techcrunch.com) 40
An anonymous reader shares a report: It's been just over five years since Google announced at Google I/O 2017 that it would make Kotlin, the statically typed language for the Java Virtual Machine first developed by JetBrains, a first-class language for writing Android apps. Since then, Google took this a step further by making Kotlin its preferred language for writing Android apps in 2019 -- and while plenty of developers still use Java, Kotlin is quickly becoming the default way to build apps for Google's mobile operating system. Back in 2018, Google and JetBrains also teamed up to launch the Kotlin Foundation.
Earlier this week, I sat down with Google's James Ward, the company's product manager for Kotlin, to talk about the language's role in the Android ecosystem and beyond, as well as the company's future plans for it. It's no surprise that Google's hope is that over time, all Android developers will switch over to Kotlin. "There is still quite a bit of Java still happening on Android," Ward said. "We know that developers are generally more satisfied with Kotlin than with Java. We know that they're more productive, the quality of applications is higher and so getting more of those people to move more of their code over has been a focus for us. The interoperability of Kotlin ... with Java has made it that people can kind of progressively move code bases over and it would be great to get to the point down the road, where just everything is all Kotlin."
Earlier this week, I sat down with Google's James Ward, the company's product manager for Kotlin, to talk about the language's role in the Android ecosystem and beyond, as well as the company's future plans for it. It's no surprise that Google's hope is that over time, all Android developers will switch over to Kotlin. "There is still quite a bit of Java still happening on Android," Ward said. "We know that developers are generally more satisfied with Kotlin than with Java. We know that they're more productive, the quality of applications is higher and so getting more of those people to move more of their code over has been a focus for us. The interoperability of Kotlin ... with Java has made it that people can kind of progressively move code bases over and it would be great to get to the point down the road, where just everything is all Kotlin."
What about dart? (Score:2)
What about dart/flutter?
Re: What about dart? (Score:4, Informative)
Dart and flutter are Google creations. And, they are cross-platform. But, their viability, like other Google ventures is questionable.
Kotlin is a Jetbrains creation and a better alternative to Java. Google recognized this adopted it for Android. I do not see Apple moving towards Java given their support for Swift and SwiftUI.
Re: (Score:2, Interesting)
I do not see Apple moving towards Java given their support for Swift and SwiftUI.
It's worth noting that Kotlin and Swift have a lot of similarities [raywenderlich.com]. Also, both of them were adopted/created for mobile app development for the explicit reason that the previous languages (Java/ObjC) were legacy languages that carried a lot of old baggage and could be messy and error-prone.
Re: (Score:1)
Which is an ironic statement given the biggest problem with Kotlin over many other languages is that it suffers from being born from the JVM and so inherits it's countless legacy issues.
I'm not much of a Microsoft fan, but .NET's CLR and C# are still far, far nicer than Kotlin (and in fact, any JVM language) because they don't suffer from the JVM's now brutally obvious cruft when it comes to things like constraints, late binding, introspection and so forth. It's a demonstration of what Google should've done
Re: What about dart? (Score:5, Informative)
Which is an ironic statement given the biggest problem with Kotlin over many other languages is that it suffers from being born from the JVM and so inherits it's countless legacy issues.
I hope MS is paying you well for your trolling. I know of no real issues with the JVM related to any of the points you raised. Those are all issues with Java and its syntax. Let's take them one at a time. Constraints are quite easy to implement on the JVM using bytecode libraries like Spoon or using aspects. The JVM has no issues with Late binding because it uses dynamic dispatch so I have no idea what you are talking about here. Only languages compiled to assembler would have issues with late binding. Introspection again I really don't know where you are getting the idea that you can't introspect class files. There are multiple bytecode libraries like Spoon or ASM that are perfectly capable of doing inline translation which provides introspection capabilities that .NET could only dream of.
Of course, the JVM also gives big advantages, mostly from the fact that HotSpot is an excellent JIT and produces really fast assembler at runtime. .NET also has a JIT but nobody has claimed it is the equal of HotSpot and provided any evidence to support that claim. And since the measure of a good JIT is the speed of the produced code, creating such evidence isn't difficult if the .NET JIT was as good as HotSpot. Finally, that you don't bring up Scala shows your ignorance. Look at all the things that language can do and your argument becomes absurd very quickly. If the Scala compiler can do complex typing and support things like implicits, sophisticated introspection and complex language level macros (not the same as the C precompiler) shows that the JVM is a really great platform for building other languages. With .NET on the other hand, you are married to Windows and all the horrors that entails.
Re: (Score:2)
One of the things I don't like about Java is that all the containers require that the things being contained by Object instances. I want to avoid excessive levels or indirect pointers. This doesn't seem, to me, inherent in the JVM, and it's a way that I assume Kotlin is similar to Java, since a big part of the promotion is the way it can interact with Java code. If Kotlin is friendlier to long (vs Long) variable, and allows declared package constant values, then I'd be interested in it.
Re: What about dart? (Score:3)
Oh, in that regard, Kotlin isn't "that bad"... it's much... Much... WORSE.
Case in point: Kotlin officially has no such thing as a simple C-like for/next loop... on paper, at least, the Kotlin equivalent of 'for (int x=0; x<100; x++){}' literally instantiates a hundred ephemeral immutable Integer objects just so it can use them once & throw them away.
When I read how Kotlin officially does for/next, I had to re-read it just to confirm it wasn't just a crazy nightmare.
Even GOOGLE had enough sense to "p
Re: What about dart? (Score:2)
Disclaimer: this is a hot, volatile topic in Kotlin-land. Any info more than a year old, and/or more than one-degree removed from Kotlin's "official" documentation, should be viewed with a healthy bit of skepticism. Nevertheless, here's how I understand the evolution of Kotlin's lack of "lightweight" (non-object-spawning) loops:
* prior to Android 5 (lollipop): say it's "not a problem", but quietly optimize SOME specific cases of array-iteration for the sake of Android. As I understand it, the only scenerio
Re: (Score:2)
Another clarification, for anyone who's not intimately familiar with the internals of Java and Android:
Java "kind of" has a limited concept of "stack" (as in, a place to store variables of purely local scope that instantly vanish when you fall out of that scope)... but unlike C++, Java's stack is *extremely* small (unless you explicitly tell the JVM to make it larger at the time the program gets launched), and it's used only for storing "primitive" variables (eg, int, long, byte, float, short, etc).
In C++,
Re: (Score:2)
^^^ Ugh, embarrassing (and very significant) typo.
The penultimate sentence of the penultimate paragraph SHOULD end with, "it's still going to create and throw away an ephemeral Iterator instance on the heap every time you rip through the loop."
Re: (Score:1)
Re: (Score:1)
With .NET on the other hand, you are married to Windows and all the horrors that entails.
Ah, I see you just arrived in a time machine from 2005. https://dotnet.microsoft.com/e... [microsoft.com]
Re: (Score:2)
Kotlin code quality has definitely been better (Score:5, Interesting)
Re: (Score:2)
I've looked at it a few times over the years as an alternative to Java, but still running on the JVM. Maybe it's time to give it another peek.
Re:Kotlin code quality has definitely been better (Score:5, Insightful)
Newer languages without much of a community or support base are going to be used by people who are more capable. Once a language gets popular and random idiots use it as part of their full time job you can expect the quality to decline like any other mainstream language.
I convinced our Android team to move to Kotlin, and we've never had a null pointer crash since then
I've not had that particular bug in C writing driver code in 10 years. Better compiler warnings, static analysis, and most discipline when writing tests has closed the gap. It's just software development the language is the least important part.
Re:Kotlin code quality has definitely been better (Score:5, Interesting)
I've not had that particular bug in C writing driver code in 10 years. Better compiler warnings, static analysis, and most discipline when writing tests has closed the gap. It's just software development the language is the least important part.
Then you are fortunate to be working all on your own or only with people as good as you are. Unfortunately, some of us still have to work with idiots, and we welcome language features that make it more difficult for those people to make stupid mistakes.
Re: (Score:2)
I work with team of 10 on a project that has contributions from 100's. We keep metrics on bug causes and null pointer is not on the top 10, and not one I've ran into personally in a long time. Which is a real shame because they're one of the easiest issues to find and fix. Our mature codebase has bugs that are difficult to reproduce, and too subtle to find in a code review.
Re:Kotlin code quality has definitely been better (Score:5, Interesting)
Java begs for it, because it's normal practice to string together 57 objects with un-checked derefs: 'obj1.obj2.obj3.obj4()'
It's of course safe to do within a try{} block, but people aren't always vigilant about that because they assume all objects fully initialized correctly, and you're not going to wrap every single method call into a try{} block.
But I do agree, it's a matter of laziness, either way.
Re: (Score:2)
Java begs for it, because it's normal practice to string together 57 objects with un-checked derefs: 'obj1.obj2.obj3.obj4()'
I thought the "normal practice" in Java was to follow the Law of Demeter which absolutely prohibits such things?
Re: (Score:2)
Java is popular enough that anything you can get away with doing, is done, leading to lots of very, very bad code.
LoD requires you to impose significant overhead on a program, and everyone*, eventually, at one point or another, will abandon it.
*obviously not everyone everyone.
Re: (Score:3)
Better languages allow better static analysis.
Re: (Score:2)
If you put the time into it, you can formally verify C/C++ [spinroot.com]. Formal verif is a hassle for anything real world complex application, but at least you can make small libraries that are formally verified. Most of the time static analysis, while incomplete, can help you track down a lot of issues. Java is theoretically easier to SA than C, but I've used static analysis and both C and Java and it felt like it missed a similar amount of things. Maybe there was a bunch of Java stuff that passed that I wouldn't norma
Re: (Score:2)
Nope, instead you have "strange, it all seems to be working, but nothing is happening".
Nulls are a total non issue when you know what data you want to handle, and reject anything that is not within expected parameters. Apps crashing on null will crash on unexpected empty strings, negative values, values not conforming to some pattern, empty lists, etc. Kotlin seems to eliminate the null problem, but in actuality, it will now function like code that silently skips null values or replaces them with some defau
Re: (Score:1)
Sorry, no language can save you from NPEs (Score:2)
I know this is anecdotal, but I suspect it's true for a lot of people. At my work, we use Sentry to log app crashes, and the vast majority of our Android app crashes were due to null pointers. In 2019, I convinced our Android team to move to Kotlin, and we've never had a null pointer crash since then.
Sorry, career Java programmer here...NullPointerException or NPEs are programmer mistakes and you can make them in any language. It's not a Java vs non-Java thing. It's an "oops, I made a mistake" thing. No language will protect you from it. Any NPE is either due to someone having a brain-fart or using a class differently than the author intended it to be used.
I like Kotlin, but I need to call BS. Kotlin didn't reduce your NPEs in any direct way. Most likely, you had legacy code written by shitty
Re: (Score:2)
Most likely, you had legacy code written by shitty programmers and you hired a better Kotlin team.
Nope. It's the same idiots.
Also, in my experience, most rewrites tend to produce a better product for human engineering reasons, not software engineering ones.
[snip]
I suspect something similar happened to you. Had you just changed your Java frameworks or did any architecture, you probably would have had a similar result.
This wasn't a rewrite at all. The errors were uncovered simply by using the "Convert to Kotlin" menu option in Android Studio. After the conversion, the code failed to compile because nullable parameters were being passed to functions that had non-null arguments. In Java, nothing stops you from doing that. (In Java, I would put `Nullable` and `NonNull` annotations anywhere that I could, but the other developers did not understand how or why that was needed.)
The same bad developers
Java & lombok support BeanValidation annotatio (Score:2)
For me, personally, most of this can be avoided by smart class design (design classes and params to be immutable) as well as standard Validatio
First-class language is baloney (Score:5, Interesting)
For Google's claim to making Kotlin a first-class language for Android, half of the useful libraries from Google that they have ported to Kotlin are labeled "experimental" and don't receive updates unlike their Java counterparts (Google protobuf, I'm looking at you...) AND Android Studio blows up regularly when loading Kotlin projects by entering an infinite loading phase (forcing you to close the project, kill .idea directories, and then re-import the project until it breaks again) and Kotlin projects tend to use a lot more system resources than Java projects to the point that the system itself can become unusable. If Kotlin were truly a first-class citizen, Google would fully support their own stuff they've written in Kotlin and fix the associated performance and stability problems in Android Studio.
Re: (Score:2)
Six years later, Google cancels Kotlin... (Score:3, Insightful)
It's coming, you knows it.
Re: (Score:2)
Re:Six years later, Google cancels Kotlin... (Score:4, Informative)
Preparing to abandon it? (Score:2)
What about Dart, Go, and Carbon? Sounds like another language du jour.
Native (Score:2)
Y'all are making some big assumptions (Score:1)
Keep Java first citizen too (Score:1)
Google's main reason to move away from Java towards Kotlin was because Oracle was suing Google for copyright and patent infringement.
The main reason of using Java in the first place was because Java was already very popular in mobile development prior Android.
Since Google won the case, I would expect to resume business as usual with Java.
At least, I'll expect Google not to force Kotlin over Java and still support Java as a first class citizen.