If the holy grail of computing is 1 perfect language to unite them all, why are there two rather similar languages, Swift and Kotlin [/native], and not an industry consortium to produce a common language? Even if APIs between OSes may be drastically different, a typical multi-platform app written in a common language could allow for some shared code and tests across platforms. Shall this industry, which has the mantra Don't reinvent the wheel, do just that? I hope the reason for repeated efforts and bifurcation isn't patents.
It’s not. Different languages have different tradeoffs. There’s a lot of value in running a modern language such as Kotlin in the Java ecosystem, side by side with older Java code. But this choice affects the language in ways that would be hard to reconcile with Swift, given its different legacy. I think the job of Swift’s language designers is tough as it is, with the current constraints we have. Having to think about Java interoperability all the time would be a nightmare I guess.
The Kotlin/native project is already working on iOS/macOS compatibility. Might it be that multiplatform Kotlin is already ahead of Swift's multiplatform support? I wonder what the status of Swift on Android is.
Seems to me that the answer is in the premise. A single language to rule all the platforms, from the perspective of the people who make the languages, isn’t necessarily the holy grail.
Google acquired the developers of Kotlin. That wasn’t just to reward them with a wad of money for their hard work. It’s because in this world of imperfect languages and engineering trade offs, as a platform owner, there is value in controlling the language that you would like your developers to use.
Are you alleging that Swift is just like BASIC and C or Erlang? I'm not sure what your point is.
For anyone else, please note that many people have made side by side comparisons of Swift and Kotlin like this one and found them to be remarkably similar:
How do you feel Swift and/or Kotlin are imperfect? Maybe too much of an emphasis on optionals?
Like discouraging programmers from leaving their platform by making them invest in learning arbitrary knowledge that can't be used on other possibly better platforms?
I used to try Kotlin as well, since they do look like Swift and I needed to develop on Android. In the end I couldn’t wrap my head around the way they handle generic. They are remnant from Java and, not to say they don’t have merit, but I’m glad Swift’s generic is easier to understand than that.
Point is, Kotlin does look like Swift, that I agree, but there are nuances here and there that seems to set them apart enough for reconciliation.
P.S. I can’t really put my finger on it, but Kotlin does still feel like Java rather than a new, polished, language. These are of course just my opinion.
Not just an impression. The JVM constraints are part of the language design. This is especially visible in the way they designed Generic and error handling (which they simply ignore as they don't like the JVM model).
While this language introduces modern paradigms, most of the existing one are simply based on the java, because they have to remain compatible with it. They don't have first class value type for instance.
swift on android is already viable. There are projects already that bridge the Java side of things into swift, which is needed for the UI layer (unless you intend to just grab a surface from the Java side and render to that directly which is possible). The core libraries are already usable on Android. That is not to say that there are no issues left to solve - packaging and distribution issues are still areas for improvement.
As others have pointed out, the premise is likely incorrect. That said, assuming it is correct, I think the answer might be that a language which encompasses all possible programming idioms and ideas would probably have such a complex syntax and so many subtle semantic corner cases that it wouldn’t be practical for normal use. (Not for a human, anyway. Such a language might make an interesting “high-level IR” for compilers, but I suspect we’d have done it by now if there was much merit to the idea.)
Now, AFAIK, there is the possibility that we merely haven’t found the right abstractions yet to make a “universal programming language” practical. I hope that if we do find them, Swift can become that language, but I’m not holding my breath (for several reasons).
I would forget about the Kotlin Native iOS integration. It uses the ObjC compatibility layer, which means you cannot bridge all the cool Swift-only features like structs, enums with associated values, protocol extensions etc. E.g. Kotlin value types will translate to NSObject subclasses.