Kotlin/Native Tech Preview: Kotlin without a VM
blog.jetbrains.com
blog.jetbrains.com
Same issue with Scala Native[1]. Both projects are a long way from being production ready wrt to targeting ios, android and desktop.
Probably at least a couple of years before either project delivers the one-language-to-rule-them-all.
I wanted to read 'The Swift Programming Language (Swift 3.1 Edition)'. It is just an epub, just distributed via Apple iBooks, right?
When trying to open in on an Android tablet, I found out that it is DRM-ed. Why on earth would you put DRM on a publication you want to circulate as widely as possible? Why would anyone have to read reference docs for multi platform language on a single platform?
That certainly dampened my enthusiasm for Swift.
> This ePub document is made available under a Creative Commons Attribution 4.0 International (CC BY 4.0) License.
They should make PDF/html available to all.
The (non-DRM) epub is fine too, it is just a bunch of of html files, zipped.
https://swift.org/documentation/TheSwiftProgrammingLanguage(...
https://swift.org/documentation/
I never had any issue reading it on Aldiko, even the Apple versions.
Yesterday I took a look at their tools and they are all absolutely great but I didn't download a single one since they are all 30-day trial and I am as poor as fuck.
So tease me, convert me, let me use your tools for years and when the time comes I am ready for an enterprise I'd take my knowledge with me, and my tools.
JetBrains are you listening?
You can certainly do commercial applications using Intellij IDEA CE, if you don't need Java EE, Spring, GWT, Grails, etc deep integration in the IDE.
They just do not promote the community edition for commercial development.
I, for instance, could choose to use PyCharm community since I rarely use any of the tooling that comes with the 'pro edition', but when I do need something---like Cython debugging---its damned useful.
I believe it includes Kotlin Support.
Throw in the fact that their IDE software is open source only until you need the most advanced features, and I can imagine Kotlin never picking up as much steam as Rust or Swift with their comparably inferior tooling ecosystems. I can imagine C# taking over java before Kotlin does.
With Scala being more than a decade old, its most popular usage is Apache Spark project which is not saying much. Kotlin would first have to reach beyond Scala which itself is small percentage point of Java.
Many companies mandate that you use Visual Studio to develop with because their entire toolchain is setup to build the project via VS tools. Deviating from that means that no one can help you, and you're probably polluting the repo with your own ad-hoc tooling.
Actually that is how many enterprise companies work.
I usually get to use what the IT department from our customers has decided as IDE for a specific project.
Anything else usually requires a change request with the necessary approvals at all levels, which means very few people ever bother to go through that pain, assuming that it will be approved in the end, because "I don't like X" won't work as reason.
How well does "else I quit, my code, my tools" works as a reason?
We are talking about enterprise here, there are plenty of people for that position, specially external consultants, no one would be stopping you from leaving.
In fact they might even help you taking your things out.
Well, if you're an external consultant, it's they that called you to get them out of some mess in the first place.
You didn't knock on their door to ask for work.
The only time I had some kind of freedom, away from what IT says how things should be, was at a few startups.
Once those startups grew, the big boys from IT started to create a standard development environment.
Emacs does sponsor a language (elisp), and it's most people's reason for using it.
Intellij Idea as IDE is a great choice. Android developers were forced to move from Eclipse to Idea and I haven't seen any resistance to avoid it. I have heard iOS developers complaning about tooling around swift. So, I think it is a strong point.
I think you've missed something here...
I am not sure it can be be concluded from any data. They have come up with just a tech preview. Doing better job than Rust/Swift/Java or Go to have high perf on native platforms is going to be a huge effort. Just having a binding via LLVM is a small start.
Hope they do better but for now it seems to me that hype around it is about 2-3 magnitudes higher than the actual amount of software written in it.
The tech preview is about kotlin compiling directly to machine code. They already said they haven't done any optimization into that code. I guess they use some intermediate language for the compiler to translate it to machine code. (note that all the compilers translate the original input file into this intermediate language before compiling it to the final code, so they can do a lot of optimization and checks in this code which are shared among all languages)
In contrast to Scala, Kotlin has a much stronger focus on Java interop so its able to much better leverage the JVM ecosystem. In particular, Kotlin hits a really good sweet spot for Android development, where it can still be compatible with older JVM versions, the language features can really increase readability and reduce bugs, and the overhead isn't too dramatic.
The network effects also amplify its usefulness; JetBrains continues improving the language and its tooling; Android Studio is based on IntelliJ so the integration is also strong; more developers use the language and produce more libraries, frameworks, and ensure compatibility is excellent.
By design you can begin using Kotlin in a Java project slowly (there's even a Java->Kotlin converter), so if you are developing on a Java stack, Kotlin is worth investigating!
Kotlin to LLVM is amazing idea and risky if it will break in Android. Only time will tell.
They talk about modules and I am curious about their syntax (if any). If we are to support a new multi-platform ecosystem, we should make sure it is built on a stable foundation.
For example, I really like scala, but I can't convince myself to try scala-js due to the unsoundness of the platform. Some scala libraries work, some libraries compile but won't work as expected and some libraries need porting. And you don't really know which is which.
The compiler wouldn't compile to native code using LLVM, but would produce Objective-C source code, to be compiled with Apple's clang compiler. That way, no matter what crazy requirements Apple throws at us tomorrow (similar to 64-bit and bitcode), we don't have to wait on JetBrains.
Kotlin's Any type should be synonymous with NSObject.
Kotlin's String type should be synonymous with NSString.
Kotlin shouldn't define its own concrete collection classes on this platform, but should use NSArray, NSDictionary, NSSet, and their mutable counterparts.
The standard library should be the intersection of the Kotlin JVM and JS standard libraries. Nothing more, at least at first.
Any reflection facilities should be in a separate, optional library. I want to be able to ship an app without the slightest hint of run-time dynamism, to keep Apple happy.
Memory management should be ARC. Period. This means we'll need a Weak annotation.
Edit:
The ability to export Kotlin classes to ObjC, with control over the names of classes and methods, and support for ObjC properties.
Basically, I want J2ObjC for Kotlin, but with no concrete collection classes of its own, and generally much less of a runtime library.
Kotlin could however be awesome for cross-platform mobile dev, targeting both iOS and Android with a lot of shared code and truly native apps on both.
I wouldn't use kotlin for cross-platform mobile dev. There are few things Android and iOS share, you end up having to codebases in the same language (which it is good in its way). If you want to do truly native apps, just avoid sharing code because you will use different patterns and different libraries and apis. You could share the business logic but that is something I think should be on the server not in the app. The app is only the frontend.
- data structures for your domain objects
- network code (just plug in an appropriate platform-specific driver)
- like you said, business logic - especially if the app has to work offline
- if you're using something like https://realm.io/, you could avoid a lot of duplication
Anything to do with the UI then has to be platform-specific of course.
not sure there are a problem since you have data classes in kotlin. I bet swift provides something similar.
> - network code
In Android you must use okhttp, and I guess there are similar powerful libraries in swift for this.
> - if you're using something like https://realm.io/
Last time I checked it I decided to keep using SQLite as it allows me to do everything I want. Realm doesn't support "complex" SQL queries.
Again, just business logic. But there is no too much apart from field validation or simplex operations to show the data (or it should be much more). Complex things must be in the server, that is the best way to share business logic among all your apps in all the platforms.
isn't this what people are doing with JavaScript?
Kotlin could offer better performance and certainly offers strong type safety throughout the stack, which I at least certainly believe gives a better programming experience.
For example this compiles without warnings:
const foo: Promise<string|null> = Promise.resolve(null);
const bar: Promise<string> = foo;
bar.then((value) => value.toString()); // runtime null errorWhich is the same thing as in Java and plenty of other languages.
Although using the same language in different environments obviously feels a bit different.
Kotlin could run on all supported platforms and reuse Java libraries.
Which is even awesome for Microsoft to adopt LLVM.
(Real question)
Hyperbolic much? At worst, it will fail to gain much traction.
Whereas it's just one of the things the company does, not even a profitable one, and at worst it will just fail to catch.
Sure, that "wont be nice either". But hardly the kind of "not nice" to be really concerned with...