Why 2 languages, Swift and Kotlin, not 1?


(Eben Up) #1

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.

Comparison of Swift and Kotlin:
http://nilhcem.com/swift-is-like-kotlin/


(Tomáš Znamenáček) #2

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.


(Jordan Rose) #3

…and the Kotlin contributors probably feel the same way about ObjC compatibility.


(Kirill Titov) #4

This reminds me of an xkcd comic :)


(Eben Up) #5

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.


(Eben Up) #6

From a few months ago:

Here's a list of supported platforms:
https://kotlinlang.org/docs/reference/native-overview.html


#7

You are in for a shock when you find out that there are actually way more than 2 of them.


(Steven Van Impe) #8

Because getting people to agree on things is harder than creating a new language ;)


#9

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.


(Eben Up) #10

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:

http://nilhcem.com/swift-is-like-kotlin/


(Eben Up) #11

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?


#12

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.


(Jean-Daniel) #13

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.


(Stern) #14

Next you'll be asking why we all aren't using Xamarin...


(Karl) #15

Or JavaScript (shudders)


(Saleem Abdulrasool) #16

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.


(David Sweeris) #17

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).


(Daniel Berger) #18

Keep in mind though that engineering isn't just about the language, you also need access to underlying frameworks.


(Howard Lovatt) #19

I use both. I would say main adantages of Korlin are:

  1. Truely cross platform including IDE.

  2. Generic interfaces as opposed to associated type protocols.


(Fabian) #20

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.