3 ms·
Having two similar languages on different platforms isn't as useful as having the same language on both platforms, though. So, you can have Kotlin on iOS via R
by mwcampbell 11y ago
Having two similar languages on different platforms isn't as useful as having the same language on both platforms, though.
So, you can have Kotlin on iOS via RoboVM. But that's kind of expensive. Also, RoboVM brings its own heavy runtime environment with its own class hierarchy, garbage collector, and the need to bridge between that world and the ObjC runtime.
Or you can have RemObjects's almost-Swift (http://www.elementscompiler.com/elements/silver/ http://www.elementscompiler.com/elements/silver/) on Apple platforms, Android/JVM, and .NET as well. I call Silver almost-Swift because some permanent differences from real Swift are documented here: http://docs.elementscompiler.com/Silver/DifferencesAndLimitations/ http://docs.elementscompiler.com/Silver/DifferencesAndLimita... For that reason, though I like the Elements compiler's approach of targeting each platform in the most native possible way, I'd recommend using their C# front-end or even their Oxygene language (a Pascal derivative) instead.
- cwyers 11y ago> Having two similar languages on different platforms isn't as useful as having the same language on both platforms, though. Sure, but as we've seen from the WebKit/Blink fork, Google and Apple aren't capable of sharing stewardship of something that central to both of their platforms in the long run. So it's not going to happen. iOS and Android both disappoint me as being one-language-dominates platforms; I much prefer the paradigm of Windows, Linux or OS X, where you can have apps in Python, apps in C, apps in VB or Lisp or FORTRAN or Brainfuck, all running as first-class citizens. It feels like a real step back for me.
- leppr 11y agoIt's a step back just as the walled garden ecosystem is in general, but it did make it easier to find documentation and hire developers, and thus grow the platform.