Kotlin is now Google’s preferred language for Android app development(techcrunch.com)
techcrunch.com
Kotlin is now Google’s preferred language for Android app development
https://techcrunch.com/2019/05/07/kotlin-is-now-googles-preferred-language-for-android-app-development/
98 comments
This is nothing new. People were constantly introducing new languages back in the 1990s too. Of your preferred languages, Rust and Typescript are fairly new. They are among the success stories of this tower of Babel.
There's a constant churn of replacing and improving languages. Nobody is using Algol, Pascal or Smalltalk anymore, and even COBOL is losing ground. (Only Lisp and C seem to survive everything.) There's a constant process of learning and improving, that resulted in this latest generation.
And every language is good at something that no other language is good at. There are good reasons why some people prefer Perl, Python, Javascript or C for some tasks. Kotlin is rising in popularity because it's turning out to be the better Java that Groovy and Scala weren't.
Expecting everybody to use the same programming language for everything is like expecting a carpenter to choose a single tool to use for everything. And maybe a Swiss army knife really can do it all, but still not as well as a more dedicated tool.
There's a constant churn of replacing and improving languages. Nobody is using Algol, Pascal or Smalltalk anymore, and even COBOL is losing ground. (Only Lisp and C seem to survive everything.) There's a constant process of learning and improving, that resulted in this latest generation.
And every language is good at something that no other language is good at. There are good reasons why some people prefer Perl, Python, Javascript or C for some tasks. Kotlin is rising in popularity because it's turning out to be the better Java that Groovy and Scala weren't.
Expecting everybody to use the same programming language for everything is like expecting a carpenter to choose a single tool to use for everything. And maybe a Swiss army knife really can do it all, but still not as well as a more dedicated tool.
> Kotlin is rising in popularity because it's turning out to be the better Java that Groovy and Scala weren't.
I'd say Kotlin is rising in popularity mainly because it's a Java alternative backed up by Google.
I'd say Kotlin is rising in popularity mainly because it's a Java alternative backed up by Google.
Backing by Google has helped, but I honestly think the two main reasons its succeeding are the same two reasons Typescript is succeeding: A "better" language that's "pragmmatic". What i mean is, they both provide the features people want (types, inference, less verbose than Java) and have quality out of the box tooling (because Jetbrains and vs-code). The moment I saw and tested either, I knew they would be a smashing success because they solved the problems people wanted solved, and "just worked".
The rise-and-fall adoption of Scala and Apache Groovy is because their whole rationale for existing was to be a better something. Groovy (2003) tried to be a better Beanshell (1998) by adding closures to it. Beanshell tried to be a better Java (1995) by adding dynamic typing to it. Scala (2003) tried to be a better Java by adding definable operators to it. But when something even better comes along, their rationale for existing disappears. They will try to catch up by adding features later (e.g. Groovy 2's inferred typing to compete with Scala, or its more recent macros to compete with Clojure) but by then the newer language has made a foothold, and it's too late.
> Scala (2003) tried to be a better Java by adding definable operators to it.
That's totally wrong. The reason d'etre of Scala is merging FP and OOP in a simple and elegant way. And actually there was no "fall" in rise-and-fall adoption of Scala. The adoption is growing.
That's totally wrong. The reason d'etre of Scala is merging FP and OOP in a simple and elegant way. And actually there was no "fall" in rise-and-fall adoption of Scala. The adoption is growing.
I think it's not just that Groovy and Scala were temporarily a better Java that was eventually overtaken by the next even better Java, I think they were not sufficiently better. Better at some things, but with a cost not everybody wanted to pay. Groovy doesn't perform the way Java does, Scala is fast, but is a lot more complex and occasionally hard to read.
I haven't really tried Kotlin yet, but my impression is that it improves a lot on Java without any real downsides. It might not have all the improvements that Groovy and Scala offer, but it has the most important ones.
And it's a clean slate that leaves some of the poorer decisions in Java behind it.
I haven't really tried Kotlin yet, but my impression is that it improves a lot on Java without any real downsides. It might not have all the improvements that Groovy and Scala offer, but it has the most important ones.
And it's a clean slate that leaves some of the poorer decisions in Java behind it.
> Groovy doesn't perform the way Java does, Scala is fast, but is a lot more complex
That's not quite how it seems for me. Groovy is faster than Scala in my hands (using CompileStatic) but its main challenge is complexity. It introduces a thousand quirks that have to be learned and then managed. There are some terrible legacy choices that can't be changed (eg: implicit coercion to Strings). I think this is behind the antipathy you see with people like Gradle users and Jenkins users that are incidentally exposed to it. But it applies also when you use it as a "replacement for Java". It has so many useful built in features but the price of that is all the implicit behavior of all of those need to be learned, along with actually learning Java really well, and with that along with less than perfect IDE support, and it's a steep steep curve.
That's not quite how it seems for me. Groovy is faster than Scala in my hands (using CompileStatic) but its main challenge is complexity. It introduces a thousand quirks that have to be learned and then managed. There are some terrible legacy choices that can't be changed (eg: implicit coercion to Strings). I think this is behind the antipathy you see with people like Gradle users and Jenkins users that are incidentally exposed to it. But it applies also when you use it as a "replacement for Java". It has so many useful built in features but the price of that is all the implicit behavior of all of those need to be learned, along with actually learning Java really well, and with that along with less than perfect IDE support, and it's a steep steep curve.
Kotlin's main improvement on Java is its seamless integration with the most popular IDE on the JVM. Of course, it helps that IntelliJ and Kotlin are put out by the same company, but Jetbrains did emphasize when they first announced Kotlin that its integration with IntelliJ would be top priority. Groovy and Scala never had this improvement.
Yet, Scala has much better and broader IDE support than Kotlin these days. There is first-class support in IntelliJ IDEA, Eclipse and VS-Code, and with advent of Scala 3 the IDE story is going to be even better with full LSP support, so any IDE or editor could get accurate type-aware highlighting and autocomplete for virtually free.
Kotlin has good support only in IDEA and JetBrains said they wouldn't support other IDEs. They seem to make exactly the same mistake as Scala 2 did with supporting only one IDE initially (Eclipse).
Kotlin has good support only in IDEA and JetBrains said they wouldn't support other IDEs. They seem to make exactly the same mistake as Scala 2 did with supporting only one IDE initially (Eclipse).
If that's true, then Kotlin is successful despite its lesser IDE support.
Main reason for Kotlin uptake is Android. Kotlin is successful due to smaller footprint of its runtime lib and just-slightly-better Java philosophy, because it uses Java collections instead of bringing its own like Scala did. A big runtime library and problems caused by high method count hitting limits of Android runtime slowed down adoption of Scala on Android and allowed Kotlin to take that niche. Later the official support from Google reinforced its position.
> Kotlin's main improvement on Java is its seamless integration with the most popular IDE on the JVM.
Did Java not have seamless integration? I thought several IDEs (Eclipse, Netbeans and IntelliJ) were designed specifically around Java.
Did Java not have seamless integration? I thought several IDEs (Eclipse, Netbeans and IntelliJ) were designed specifically around Java.
Without the "tower of babel" that exists you wouldn't get Rust or TypeScript, D, Swift or Julia.
Given that you mentioned them, I'm assuming you have some preference for them. So the world you'd live in would be a world in which your preferred languages wouldn't exist.
I guess that would be fine for some people, but not me or people like me. So there you have your answer.
Given that you mentioned them, I'm assuming you have some preference for them. So the world you'd live in would be a world in which your preferred languages wouldn't exist.
I guess that would be fine for some people, but not me or people like me. So there you have your answer.
You could get all the features of Rust by just taking features from an ML-family language and adding some low level memory manipulation capabilities, plus the theoretical work on lifetimes and all. It wouldn't "look like C" but it would be the same things.
You could get to any modern dynamic optionally typed language by just starting from Common Lisp, dropping the s-expressions and macros, and replacing default datatypes with something saner and easier to learn/teach.
There's a huuuuge bunch of intermediate steps that could've just been skipped. Maybe C isn't one of them, it was inevitable - of you wanted a portable higher assembler usable on 80s computers you could've only invented something like C. But Go, D, Julia etc. only repackaged existing knowledge...
You could get to any modern dynamic optionally typed language by just starting from Common Lisp, dropping the s-expressions and macros, and replacing default datatypes with something saner and easier to learn/teach.
There's a huuuuge bunch of intermediate steps that could've just been skipped. Maybe C isn't one of them, it was inevitable - of you wanted a portable higher assembler usable on 80s computers you could've only invented something like C. But Go, D, Julia etc. only repackaged existing knowledge...
> But Go, D, Julia etc. only repackaged existing knowledge...
Sure but you could also say that Google (the search engine) only repackages existing knowledge. Not much different from that famous HN comment [1] which says yould could use FTP & CVS instead of dropbox.
If we take Go as an example, sure code style guidelines were old news when Go came out, yet gofmt is still considered one of the best features of the language, because it removes bikeshedding and dictates the one true standard.
In other words, like in cooking, it's not so much about the ingredients but how you package them.
--
[1] https://news.ycombinator.com/item?id=9224
Sure but you could also say that Google (the search engine) only repackages existing knowledge. Not much different from that famous HN comment [1] which says yould could use FTP & CVS instead of dropbox.
If we take Go as an example, sure code style guidelines were old news when Go came out, yet gofmt is still considered one of the best features of the language, because it removes bikeshedding and dictates the one true standard.
In other words, like in cooking, it's not so much about the ingredients but how you package them.
--
[1] https://news.ycombinator.com/item?id=9224
I don't know if any language can exist solely as repackaged knowledge. Sure, a language can very well start that way, but you now have n features that need to be integrated with each other in a still unknown way, which brings new challenges and new knowledge. And no language is static and no technique is completely generic, so any complex software will have issues that will need custom solutions that will again lead to the creation of new knowledge.
For example Julia didn't invent multiple dispatch, but it's intention to use it to high performance numeric computing meant different constraints from Dylan or CL, which led to the creation of it's own unique paradigm around type specialization and promotion to make it work. But eventually people had troubles with extremely complex dispatch rules, so, thanks to the language also having repackaged the Lisp knowledge in itself, the language designers were able to create a unique macro to make dispatch rules turing complete (generated functions). And then people realized it could be used for source to source manipulation, for example in the state of the art ML project Zygote.
You'll certainly find many examples like that in any minimally ambitious language.
For example Julia didn't invent multiple dispatch, but it's intention to use it to high performance numeric computing meant different constraints from Dylan or CL, which led to the creation of it's own unique paradigm around type specialization and promotion to make it work. But eventually people had troubles with extremely complex dispatch rules, so, thanks to the language also having repackaged the Lisp knowledge in itself, the language designers were able to create a unique macro to make dispatch rules turing complete (generated functions). And then people realized it could be used for source to source manipulation, for example in the state of the art ML project Zygote.
You'll certainly find many examples like that in any minimally ambitious language.
"There's a huuuuge bunch of intermediate steps that could've just been skipped."
Except they couldn't have just been skipped. In retrospect? Maybe. But I suspect we'll see another several thousand languages in the next 20-30 years, most of which will be very, very much like what came before, and a very few that ultimately matter. I don't think there's any way around that except in hindsight.
Except they couldn't have just been skipped. In retrospect? Maybe. But I suspect we'll see another several thousand languages in the next 20-30 years, most of which will be very, very much like what came before, and a very few that ultimately matter. I don't think there's any way around that except in hindsight.
Okay, let's go to 1989 and apply this mentality.
Three languages to suffice all needs:
* Low-level systems language: C.
* Highly expressive, high-performance industrial language: C++.
* Interactive interpreted language for doing easy casual things: Basic! Everybody knows Basic already.
Halt the language research, stop trying to develop Python, Lua, Java, OCaml, Haskell, Smalltalk, etc. Who ever needs them?
In plain words: diversity is how evolution works. You cannot build a perfect thing from the start (no, not even Lisp, apparently). You have to try and reality-check. Standardizing on One True Tech is how you end up with reams of despicable legacy code 15 years later, and with no way out.
Three languages to suffice all needs:
* Low-level systems language: C.
* Highly expressive, high-performance industrial language: C++.
* Interactive interpreted language for doing easy casual things: Basic! Everybody knows Basic already.
Halt the language research, stop trying to develop Python, Lua, Java, OCaml, Haskell, Smalltalk, etc. Who ever needs them?
In plain words: diversity is how evolution works. You cannot build a perfect thing from the start (no, not even Lisp, apparently). You have to try and reality-check. Standardizing on One True Tech is how you end up with reams of despicable legacy code 15 years later, and with no way out.
Good point, but Smalltalk was basically fully baked in 1980. That's why they called it Smalltalk-80.
The languages are quite different though and there are good reasons for using different ones in different places:
1. Kotlin is basically modern Java, and is therefore an obvious choice for Android which still runs everything in a JVM.
2. Go was basically designed to run network services and it is very good at it. The standard library is excellent (probably the best of any language) and concurrency is pretty easy too.
3. The Flutter team have published their reasoning for using Dart. Can't say I fully agree with all of them but it is a reasonably nice language (way better than Javascript anyway - although I know that doesn't take much) and developing with it is really pleasant.
I don't know why TF chose Swift though. It looks like a nice enough language though.
There are definitely significant differences between all of those languages. It's not like they're using a mixture of Javascript, Typescript, Flow and Dart. That would be silly.
1. Kotlin is basically modern Java, and is therefore an obvious choice for Android which still runs everything in a JVM.
2. Go was basically designed to run network services and it is very good at it. The standard library is excellent (probably the best of any language) and concurrency is pretty easy too.
3. The Flutter team have published their reasoning for using Dart. Can't say I fully agree with all of them but it is a reasonably nice language (way better than Javascript anyway - although I know that doesn't take much) and developing with it is really pleasant.
I don't know why TF chose Swift though. It looks like a nice enough language though.
There are definitely significant differences between all of those languages. It's not like they're using a mixture of Javascript, Typescript, Flow and Dart. That would be silly.
I suspect that TF "chose" Swift because Chris Lattner (the creator of Swift) joined Google, and he managed to convince people that it would be a good idea.
To what extend, is Swift being used for ML or DL by Google or others? Is it a new TensorFlow core? Or just just another binding?
It's an alternative interface for Tensorflow (the existing one is Python). The core of Tensorflow is still written in C++.
I kind of get your point.
But I have to say after spending a fair amount of time writing C, C++, and Java, I found go quite refreshing. The simplicity of syntax, design, and implementation of go does reward using it for what it's good at.
So simple in fact that I'd happily pick up another simple language or two for things that Go is not good at.
I'd much rather have a few somewhat narrow language like go, instead of the ugly mess that is C++. Can anyone normal serious C++ programmer understand all of C++?
But I have to say after spending a fair amount of time writing C, C++, and Java, I found go quite refreshing. The simplicity of syntax, design, and implementation of go does reward using it for what it's good at.
So simple in fact that I'd happily pick up another simple language or two for things that Go is not good at.
I'd much rather have a few somewhat narrow language like go, instead of the ugly mess that is C++. Can anyone normal serious C++ programmer understand all of C++?
Yep. Swift is open-source and pretty decent. Google should clean house and go with the language that would attract the most developers.
They should invest into making it pleasant to use in Linux and Windows too if they want adoption...
ML devs (using mostly Linux) will not bother to build a useful rich ecosystem of general purpose libraries. And amongst the other devs, Windows matters a lot, macOS is a small and shrinking niche outside US.
ML devs (using mostly Linux) will not bother to build a useful rich ecosystem of general purpose libraries. And amongst the other devs, Windows matters a lot, macOS is a small and shrinking niche outside US.
Swift doesn't work natively on Windows which is a massive downer for many people.
It doesn't yet, but good progress has been made recently on that front:
https://forums.swift.org/t/swift-windows/22458
Cygwin could be an option.
1. Why would swift attract most developers?? It's a fairly small language outside the iOS bubble.
2. Google has invested tons of money in 3 different languages and each works _extremely_ well in it's intended domain.
3. Even as open source, remember Apple has a history of crippling software on competing platforms.
2. Google has invested tons of money in 3 different languages and each works _extremely_ well in it's intended domain.
3. Even as open source, remember Apple has a history of crippling software on competing platforms.
The specialized languages are a pain, but a single language that tries to be everything to everyone tends to be more of a pain. That's because it can't specialize, it has to adopt the lowest common denominator approach. As a result it's unlikely to be the best in any given area (sometimes it happens, but rare in my experience).
Where this hurts the most is in hiring. To get a job with Google you'll either learn one of these really well and so only be able to apply to one area of Google, or you'll learn several of them but not go in depth as much in the same amount of time and be able to apply to many different areas of Google.
Your idea of a limited language ecosystem (a languages for each of system, web, and metal-to-abstraction) is a good idea, but I think it still invokes the LCD problem. Though nowhere near as much. It would not surprise me that much if we hit the extreme of specialization, with a specialized language for each slot of the {mobile, server, desktop UI, IoT} x {each of the seven layers of the OSI stack}. As I wrote that I was thinking you could create Karnaugh map like depictions of languages to show what areas they cover.
I think a very varied programming language ecosystem is a good thing, and we're never going to get a one size fits all language, but there's a balance needed. The jury is still out and I'll have to see if it turns out well.
Where this hurts the most is in hiring. To get a job with Google you'll either learn one of these really well and so only be able to apply to one area of Google, or you'll learn several of them but not go in depth as much in the same amount of time and be able to apply to many different areas of Google.
Your idea of a limited language ecosystem (a languages for each of system, web, and metal-to-abstraction) is a good idea, but I think it still invokes the LCD problem. Though nowhere near as much. It would not surprise me that much if we hit the extreme of specialization, with a specialized language for each slot of the {mobile, server, desktop UI, IoT} x {each of the seven layers of the OSI stack}. As I wrote that I was thinking you could create Karnaugh map like depictions of languages to show what areas they cover.
I think a very varied programming language ecosystem is a good thing, and we're never going to get a one size fits all language, but there's a balance needed. The jury is still out and I'll have to see if it turns out well.
> "tower of babel"
The hallmark of a fragmented corporation, with internal competition between divisions.
The hallmark of a fragmented corporation, with internal competition between divisions.
Which, if you're the size of Google, is probably the way you want it. At least then great new ideas have a chance to survive when they threaten the current product line.
I agree to a certain extent, ( And the list is missing Elixir / Erlang )
But if we look at it from a very high level, I see this sort of happening already because Kotlin and Swift are very similar. They have both taken all of their ancestors's good idea and repackaged it within their own constrain. ( JVM and Objective-C ).
And combatively speaking, Rust is new. It hasn't been tested by millions of developers and production usage. Where they may find edge case in its concept and design, before we reach a conscious to replace C or C++, if that is even needed.
CoffeScript died ( in terms of Development, not usage ), because JS evolved, someday TypeScript may died too, as it itself might become the future of JS.
So over time these PL and idea converge, and consolidate. And through Natural evolution we will reach that point you described, with few languages that all look similar. And I would not be surprised if 5 - 7 years down the road C# ( Microsoft ) , Kotlin ( Google ) , Swift ( Apple ) all looked similar.
As to why it shouldn't be just one languages, well I doubt M$, Google, Apple will ever play along well with each other.
But if we look at it from a very high level, I see this sort of happening already because Kotlin and Swift are very similar. They have both taken all of their ancestors's good idea and repackaged it within their own constrain. ( JVM and Objective-C ).
And combatively speaking, Rust is new. It hasn't been tested by millions of developers and production usage. Where they may find edge case in its concept and design, before we reach a conscious to replace C or C++, if that is even needed.
CoffeScript died ( in terms of Development, not usage ), because JS evolved, someday TypeScript may died too, as it itself might become the future of JS.
So over time these PL and idea converge, and consolidate. And through Natural evolution we will reach that point you described, with few languages that all look similar. And I would not be surprised if 5 - 7 years down the road C# ( Microsoft ) , Kotlin ( Google ) , Swift ( Apple ) all looked similar.
As to why it shouldn't be just one languages, well I doubt M$, Google, Apple will ever play along well with each other.
Programming languages are products.
Once upon a time, the OS of choice would dictate which languages were tier 1.
Nowadays the platform has taken up that role.
Once upon a time, the OS of choice would dictate which languages were tier 1.
Nowadays the platform has taken up that role.
> ...great, Kotlin for Android, Dart for Flutter, on the ML side they're starting to adopt Swift, for networking infra code Go.
Don't forget HTML+JS+CSS for websites and PWAs. And given that web technologies work across all platforms, perhaps that's the area for developers to keep focusing on.
Don't forget HTML+JS+CSS for websites and PWAs. And given that web technologies work across all platforms, perhaps that's the area for developers to keep focusing on.
> And given that web technologies work across all platforms...
This is a myth. Web technology is more "Write Once, Debug Everywhere(tm)" than Java ever was. The real value is in deployment, bypassing all the platform bullshit. It's still a severely limited platform and will probably remain so, because Apple has no interest in giving up its walled garden.
This is a myth. Web technology is more "Write Once, Debug Everywhere(tm)" than Java ever was. The real value is in deployment, bypassing all the platform bullshit. It's still a severely limited platform and will probably remain so, because Apple has no interest in giving up its walled garden.
After experiencing Android development with Kotlin, I will choose Kotlin again by default. Admittedly, my experience with the most recent version of Java is not there, but Kotlin has some things I never found in Java. It statically checks for possible null pointer errors, and you can define free functions (without a class definition). Another nice thing is being able to declare constructor parameters as fields at once, and also automatic generation of getters / setters with data classes. This saves a ton of boilerplate. Maybe Java has some or all of these things now, but last time I used it, it didn't. I don't see it as a tower of Babel, but you have to keep on learning.
If you ever hop back into the realm of Java, take a look at Project Lombok [1]. It adds a list of helpful annotations for those sort of features.
—
[1] https://projectlombok.org
—
[1] https://projectlombok.org
It's only from a very high-level view that these languages might look all the same. If you look at how the languages actually evolved, there are crucial differences.
Swift basically exists due to Apple's need for Objective C compatibility. What other language would serve that need? Similarly, Kotlin was easy to adopt for Android due to Java compatibility. Rust is designed to interoperate well with C++, which is useful within Firefox. Go was designed for fast compilation and easier library evolution for server-side code in a Google-scale monorepo. Dart was designed as a browser scripting language (though this didn't work out).
There was nobody in a position to prevent all this evolution from happening.
Swift basically exists due to Apple's need for Objective C compatibility. What other language would serve that need? Similarly, Kotlin was easy to adopt for Android due to Java compatibility. Rust is designed to interoperate well with C++, which is useful within Firefox. Go was designed for fast compilation and easier library evolution for server-side code in a Google-scale monorepo. Dart was designed as a browser scripting language (though this didn't work out).
There was nobody in a position to prevent all this evolution from happening.
> Rust is designed to interoperate well with C++, which is useful within Firefox.
Mild nitpick, but from my understanding Rust interoperates well with C but is quite a pain to interoperate with C++. At least calling C++ libraries from Rust is painful, the other way around can be easy in the same way that calling C code is easy from C++.
Mild nitpick, but from my understanding Rust interoperates well with C but is quite a pain to interoperate with C++. At least calling C++ libraries from Rust is painful, the other way around can be easy in the same way that calling C code is easy from C++.
This debate can get out of hand, but the Android eco system and its developers will benefit immensely if Swift is adopted instead of Kotlin - it enables devs to share code.
thinking about nim(rod) I'm quite happy that there are still ppl trying out stuff.
I feel good and bad about this.
I invested several years at coming up to speed with Java 8+ (using templates, rx, streams, the new time APIs). It was not hard, but difficult to unlearn some C++ idioms around templates, consts, reference model and object lifecycle management.
Clearly this driven by Oracle's continuous poisoning of Java ecosystem (eg https://headcrashing.wordpress.com/2019/05/03/negotiations-f... )
And I think Kotlin is a solid step forward from the Java without the baggage of pre JDK 1.7 idioms.
But for a small (often single dev) shops trying to compete in Android marketspace, it is quite hard to maintain this rate of change (plus incorporating all the new (and better ways) of doing android with androidx )
I invested several years at coming up to speed with Java 8+ (using templates, rx, streams, the new time APIs). It was not hard, but difficult to unlearn some C++ idioms around templates, consts, reference model and object lifecycle management.
Clearly this driven by Oracle's continuous poisoning of Java ecosystem (eg https://headcrashing.wordpress.com/2019/05/03/negotiations-f... )
And I think Kotlin is a solid step forward from the Java without the baggage of pre JDK 1.7 idioms.
But for a small (often single dev) shops trying to compete in Android marketspace, it is quite hard to maintain this rate of change (plus incorporating all the new (and better ways) of doing android with androidx )
Not sure what you mean by templates, but you can still use Rx, streams and java.time.* in Kotlin. It's pretty much just a nicer Java.
Kotlin has its own (much better IMO) alternative to streams: Sequence. I see absolutely no reason to use streams in Kotlin.
The Java 8 streams library can auto parallelize things. That's the main reason it was created in fact!
One simple reason: you already know streams and don't have time to learn sequence.
Streams is mostly just Java's version of what many languages already had, so the concept was something new to learn for Java developers, but once they know it they shouldn't have much trouble with Kotlin's sequences – or with Python's list comprehensions, Lisp's mapcar, and so on.
Sure, but the point is, you can.
I’ve seen that article you linked to before. Is the solution to working around Oracle not OpenJDK? I’m not completely informed on the topic. Would appreciate some more context.
Usually FUD against Oracle, that always ignores that Oracle is also the major company behind OpenJDK.
Until there are other companies actually implementing JEPs into OpenJDK in the same volume as Oracle, OpenJDK == Oracle.
Until there are other companies actually implementing JEPs into OpenJDK in the same volume as Oracle, OpenJDK == Oracle.
Didn't Red Hat take over recently?
Red Hat has taken over the maintainance of the already released Java 8 and Java 11, LTS versions, not development of new features.
This is a now somewhat outdated report of contributions per company to OpenJDK.
https://blogs.oracle.com/java-platform-group/building-jdk-11...
This is a now somewhat outdated report of contributions per company to OpenJDK.
https://blogs.oracle.com/java-platform-group/building-jdk-11...
If Oracle was really intent on poisoning Java then they would've stopped investing in it and fired all of the core engineers.
But they didn't. And have in fact continued to invest in the ecosystem e.g. GraalVM, OpenJDK.
But they didn't. And have in fact continued to invest in the ecosystem e.g. GraalVM, OpenJDK.
'Poisoning' is not 'getting rid of'.
'Poisoning' is taking full control and monetizing everything, making everything closed source.
GraalVM is in their eyes, going to be a money-making investment. The only extent to which it might be partly OSS is a function of how much they really had to give away.
Oracle's objective with Java is to take a huge bite out of the Enterprise and do with Java what they did with their DB.
Imagine if we all needed to talk to an Oracle sales person to make our app :)
'Poisoning' is taking full control and monetizing everything, making everything closed source.
GraalVM is in their eyes, going to be a money-making investment. The only extent to which it might be partly OSS is a function of how much they really had to give away.
Oracle's objective with Java is to take a huge bite out of the Enterprise and do with Java what they did with their DB.
Imagine if we all needed to talk to an Oracle sales person to make our app :)
You mean like you have to be a registered Apple developer to sell your iOS app in their app store which captures 99.99% of the market? Java is, fortnately, out of Oracle’s reach unless your company is actively looking at “enterprisey” solutions, but in that case it probably makes more money from that sort of deals than it is paying to Oracle, so it’s all good...
> making everything closed source.
Except the JDK is now fully open source. Even previously closed source JDK projects are now open source.
Except the JDK is now fully open source. Even previously closed source JDK projects are now open source.
It seems to me that a lot of people seem to think prefering Kotlin signifies a move away from Java. But I simply don't understand how using a JVM language signifies a move away from Java. After all, it all gets compiled into the same bytecode, and Kotlin heavily depends on the Java ecosystem.
If Oracle is 'poisoning Java', Kotlin's not the answer. Surely, it'd be a language totally independent of Oracle, wouldn't it?
If Oracle is 'poisoning Java', Kotlin's not the answer. Surely, it'd be a language totally independent of Oracle, wouldn't it?
> "If Oracle is 'poisoning Java', Kotlin's not the answer. Surely, it'd be a language totally independent of Oracle, wouldn't it?"
No, the answer lies in companies that want to invest in OpenJDK, like Red Hat / IBM, to take away the stewardship of Java from Oracle and for us to move to distributions maintained by the community and not by Oracle. See: https://adoptopenjdk.net/
OpenJDK being GPLv2, the genie can't be put back in the bottle. This situation is precisely what Open Source is for: the ability to fork if you're not happy with the maintainers. Without that ability you're not talking about open source.
Also languages like Kotlin and Scala are a step in the right direction, because it means that the ecosystem is not dependent on Oracle for language improvements.
But yes, I agree with the sentiment. Kotlin isn't a breakup with Java, only a breakup with Oracle.
No, the answer lies in companies that want to invest in OpenJDK, like Red Hat / IBM, to take away the stewardship of Java from Oracle and for us to move to distributions maintained by the community and not by Oracle. See: https://adoptopenjdk.net/
OpenJDK being GPLv2, the genie can't be put back in the bottle. This situation is precisely what Open Source is for: the ability to fork if you're not happy with the maintainers. Without that ability you're not talking about open source.
Also languages like Kotlin and Scala are a step in the right direction, because it means that the ecosystem is not dependent on Oracle for language improvements.
But yes, I agree with the sentiment. Kotlin isn't a breakup with Java, only a breakup with Oracle.
I bet they have plans to make a different VM for Kotlin and move away from JVM, should be coming in the next couple of years.
Kotlin already has one in the form of Kotlin Native. So far no involvement from Google on that front, but things could change.
Kotlin already has a native compiler (targeting iOS and so forth).
Yes, especially that Kotlin already targets various architectures.
Why bother? Being on the JVM has many advantages and building some new VM (and compiler?) would be extra hassle and expense for not much gain.
moving away from oracle is `not much gain`?
There's already at least two big-name alternatives to Oracle Java: The OpenJDK and Amazon's Corretto. If you're suggesting Google might make their own "supported" OpenJDK build, then sure, that might be worth something. That's different than moving away from JVM entirely to a different compiler target, as suggested by the parent comment.
OpenJDK is like 90% developed by Oracle with smaller contributions from other partners in the Java community, including the JEPs that bring Java forward.
Oracle v Google
Android has been using OpenJDK for a while with no problems.
Google vs Oracle isn't "no problems"
https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google....
https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google....
As far as I can tell, Oracle vs Google was due to Google not using OpenJDK, but their own implementation.
Moreover, their implementation didn’t work on standard compliand JVMs, and was called Java, despite being only similar to Java. Even Microsoft’s J++ worked on different JVMs if you didn’d use Windows specific classes...
Type erasure on the JVM is still awful. Advocates and defenders have a variety of intellectual arguments to defend its awesomeness, but it doesn't "erase" its painfulness.
Kotlin on Android ultimately runs on Google's ART, not a JVM implementation, think MS J++.
Also JetBrains is betting on moving Kotlin beyond the JVM, to all platforms it can reach.
The latest version of kotlinc is now built with Kotlin/Native.
Also JetBrains is betting on moving Kotlin beyond the JVM, to all platforms it can reach.
The latest version of kotlinc is now built with Kotlin/Native.
Which one reason if I'd chose a JVM language I'd go with Kotlin and no longer Scala. The JetBrains people understand and care deeply about developers. Scala compilation of my current project takes ages with the newest Scala/SBT on an iMac Pro 16 core / 32 gb.
I have a side project in Go, compilation, startup and execution is so fast that you don't think it's compiling at all.
I wish language designers would use a fast language for the designer and not the 'see we can bootstrap our own language' approach. Kotlin/Native is at least a good compromise.
I have a side project in Go, compilation, startup and execution is so fast that you don't think it's compiling at all.
I wish language designers would use a fast language for the designer and not the 'see we can bootstrap our own language' approach. Kotlin/Native is at least a good compromise.
The performance difference between Scala compiler and Kotlin compiler is not as huge as advertised by Kotlin promoters:
https://stackoverflow.com/questions/34615947/why-does-kotlin...
Also worth noting that that answer is quite old and Scala compiler got over 2x faster since that time and now has a much improved incremental compiler, so it may be on par with Kotlin, which added more features since that time and got slower. So both languages seem to be in the same league.
There are many people complaining on Kotlin's performance as well:
https://discuss.kotlinlang.org/t/kotlin-compile-so-slowly/16...
Of course there are Scala idioms that can yield poor compile times, like code using implicits or macros a lot, but Kotlin doesn't even have these features, so instead you'd have to write lot of additional boilerplate code by hand. How can we call writing code by hand fast vs not writing code at all? That's comparing apples and oranges.
https://stackoverflow.com/questions/34615947/why-does-kotlin...
Also worth noting that that answer is quite old and Scala compiler got over 2x faster since that time and now has a much improved incremental compiler, so it may be on par with Kotlin, which added more features since that time and got slower. So both languages seem to be in the same league.
There are many people complaining on Kotlin's performance as well:
https://discuss.kotlinlang.org/t/kotlin-compile-so-slowly/16...
Of course there are Scala idioms that can yield poor compile times, like code using implicits or macros a lot, but Kotlin doesn't even have these features, so instead you'd have to write lot of additional boilerplate code by hand. How can we call writing code by hand fast vs not writing code at all? That's comparing apples and oranges.
Hopefully dotty solves some of those problems.
Compared to Scala, I personally find Kotlin inexpressive and ugly.
Compared to Scala, I personally find Kotlin inexpressive and ugly.
Recent 2.12 and 2.13 are plenty fast. Incremental compilation on the project I do takes about 1-3 seconds for me from hitting run to running the unit test after modifying the code. I get similar times in Kotlin.
The Kotlin compiler still runs on the JVM. The native compiler is actually built with Excelsior JET, not with Kotlin/Native. (I think Nikolay Igotti, the Kotlin/Native lead, mentioned somewhere that the JVM is often faster for the kind of graph manipulation that the compiler does a lot of.)
Fair enough, although I imagine it is only a matter of Kotlin/Native maturity.
ART?
Android Runtime
https://source.android.com/devices/tech/dalvik
https://source.android.com/devices/tech/dalvik
Thanks. Not easily findable.
"If Oracle is 'poisoning Java', Kotlin's not the answer."
It's not Java, and at the same time it is.
It's 'far enough away' to protect them legally, but close enough to leverage the ecosystem.
Without that, it'd be very hard to attract new devs, Also, Android uses a kind of JVM, they've invested a lot.
Oracle can only poison Java they'll have a harder time poisoning the JVM etc. - there's just too much dependent there.
If Oracle goes nuclear with Java, Google has the wherewithal to fork their own version of the JVM.
It the right move, pragmatically.
Remember, Java is a very useful thing and especially the JVM.
It's not Java, and at the same time it is.
It's 'far enough away' to protect them legally, but close enough to leverage the ecosystem.
Without that, it'd be very hard to attract new devs, Also, Android uses a kind of JVM, they've invested a lot.
Oracle can only poison Java they'll have a harder time poisoning the JVM etc. - there's just too much dependent there.
If Oracle goes nuclear with Java, Google has the wherewithal to fork their own version of the JVM.
It the right move, pragmatically.
Remember, Java is a very useful thing and especially the JVM.
Not sure why they don't link to a source on this. Here's what I found [0]. It says:
> If you’re starting a new project, you should write it in Kotlin
[0] https://android-developers.googleblog.com/2019/05/google-io-...
> If you’re starting a new project, you should write it in Kotlin
[0] https://android-developers.googleblog.com/2019/05/google-io-...
Good that they cleared that out.
Lets see what is the roadmap to use Java 9+ libraries in Android, or if they are supposed to be all rewritten in Kotlin.
Secondly, will they also replace NDK with Kotlin/Native? Given that several APIs are NDK only, and naturally should be accessible to the prefered language as well, without manual boilerplate.
Lets see what is the roadmap to use Java 9+ libraries in Android, or if they are supposed to be all rewritten in Kotlin.
Secondly, will they also replace NDK with Kotlin/Native? Given that several APIs are NDK only, and naturally should be accessible to the prefered language as well, without manual boilerplate.
I don't think they should be rewritten in Kotlin. That would force everyone to use Kotlin with minimal benefits for Kotlin users.
Java 9+ is not supported on Android, so if you want to link to a Java 9+ library for an Android application, your only path is to rewrite it in Kotlin, as it is clear from this announcement that Google won't bother to add the required machinery to ART to support Java 9+ class files and new libraries.
Naturally the other alternative would be to downgrade the code back to Java 8, but then the question remains for how long they will keep it around.
Naturally the other alternative would be to downgrade the code back to Java 8, but then the question remains for how long they will keep it around.
Might have less to do with users and more to do with Oracle v Google
I am fine with Google having their own ".NET", at least it isn't Google J++ anylonger.
I thought it was already Google's preferred language. I remember they announced that some time ago.
Love the JetBrains people, thanks for all their work and putting their IDE language knowledge into a programming language - that's also I assume easy to parse and support in an IDE.
So, now we should all start using Kotlin because Google uses it. Great!
(Pun intended of course).
[deleted]
What the heck is with this "tower of babel"?!
Are other people not bothered by the overlapping features of all these languages? At this point I thin most would prefer a slightly-frankensteinian monster-language that you'd get by taking either Kotlin or Swift and bolting all the other features on top of it.
There should be an estimate about the cost of all this useless diversity that we're all invisibly paying. Some tech/languages have really unique features, and have a reason/right to exist, eg. Rust. But most would've been better as extra features bolted on top another language.
Basically all programming in the world could be done with 3 languages: a secure system language (Rust?), a dynamic but optionally typed dynamic one (Typescript?), a full-spectrum metal-to-abstraction language with flexible compiler/infra for things like heterogeneous (CPU+GPU+TPU+whatever) code generation (C++? D? Swift? Julia? maybe also Rust?).
Plus the hidden cost of security issues created by people coding in languages they are not experts in because they need to always switch...