...great, Kotlin for Android, Dart for Flutter, on the ML side they're starting to adopt Swift, for networking infra code Go.
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...
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.
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.
* 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.
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.
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++?
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.
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.
> ...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.
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.
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.
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.
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.
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’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.
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?"
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.
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.
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.
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.
[+] [-] nnq|7 years ago|reply
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...
[+] [-] mcv|7 years ago|reply
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.
[+] [-] bad_user|7 years ago|reply
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.
[+] [-] nine_k|7 years ago|reply
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.
[+] [-] IshKebab|7 years ago|reply
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.
[+] [-] sliken|7 years ago|reply
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++?
[+] [-] PunksATawnyFill|7 years ago|reply
[+] [-] Communitivity|7 years ago|reply
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.
[+] [-] stareatgoats|7 years ago|reply
The hallmark of a fragmented corporation, with internal competition between divisions.
[+] [-] ksec|7 years ago|reply
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.
[+] [-] pjmlp|7 years ago|reply
Once upon a time, the OS of choice would dictate which languages were tier 1.
Nowadays the platform has taken up that role.
[+] [-] amanzi|7 years ago|reply
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.
[+] [-] thsealienbstrds|7 years ago|reply
[+] [-] skybrian|7 years ago|reply
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.
[+] [-] innagadadavida|7 years ago|reply
[+] [-] daef|7 years ago|reply
[+] [-] maga_2020|7 years ago|reply
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 )
[+] [-] EdwardDiego|7 years ago|reply
[+] [-] tracer4201|7 years ago|reply
[+] [-] threeseed|7 years ago|reply
But they didn't. And have in fact continued to invest in the ecosystem e.g. GraalVM, OpenJDK.
[+] [-] BossingAround|7 years ago|reply
If Oracle is 'poisoning Java', Kotlin's not the answer. Surely, it'd be a language totally independent of Oracle, wouldn't it?
[+] [-] bad_user|7 years ago|reply
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.
[+] [-] vitoreiji|7 years ago|reply
[+] [-] jpz|7 years ago|reply
[+] [-] pjmlp|7 years ago|reply
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.
[+] [-] sonnyblarney|7 years ago|reply
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.
[+] [-] eatonphil|7 years ago|reply
> If you’re starting a new project, you should write it in Kotlin
[0] https://android-developers.googleblog.com/2019/05/google-io-...
[+] [-] pjmlp|7 years ago|reply
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.
[+] [-] benjymo|7 years ago|reply
[+] [-] stunt|7 years ago|reply
[+] [-] _Codemonkeyism|7 years ago|reply
[+] [-] fithisux|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]