16 ms·
Google scored points with its community by supporting Kotlin
- Ralfp 9y ago> In the early 1700s, Peter the Great, the czar of Russia, was busy nabbing land from his western neighbor, the Swedish Empire. He seized the tip of the Gulf of Finland, and began building his beloved city of Saint Petersburg there. He also secured a small island just off its coast as a naval defense: Kotlin. > Peter couldn’t have known that more than three centuries and 5,500 miles removed... However, if you are from eastern Europe, chances are you've ran into large brand of tomato products known by same name: https://maspex.com/files/pl/news_spotlight/file_57502ce3e53816450428143.jpg https://maspex.com/files/pl/news_spotlight/file_57502ce3e538... ;)
- alexandros 9y agoTL;DR -- because developers love it. I clicked the article hoping there was some strategic background, some connection to the Oracle lawsuit, etc. Nop, the answer to "why" is "because of its merits". Also in this article, some backstory about the name "Kotlin".
- darwhy 9y agoI wonder if the hn gods will change the title from "Why supporting Kotlin is genius move for Android" to something less sensationalist. Maybe not, as it's being posted by Steven Levy himself.
- giancarlostoro 9y agoThey will likely change it to what the article's title is.
- steven 9y agoIt's not genius?
- giancarlostoro 9y agoI also came to the conclusion that it's because: * Developers are adopting it to begin with, without the announcement, locally to Orlando it's a rising language for Android developers, nobody's forcing the language on them, they try it, like it and bam. * Oracle lawsuit makes it a no brainer to accept other languages into the Android stack that could get them off their back. * Kotlin native would allow Android to maybe someday ditch the Java based VM altogetherm potentially. The tooling is also great and the language seems to be rather healthy.
- jbuzbee 9y agoNote that Android does not use the Java VM. It never has. Initially code was compiled for the Dalvik VM, but more recently code is compiled for Art: https://en.wikipedia.org/wiki/Android_Runtime https://en.wikipedia.org/wiki/Android_Runtime
- johncolanduoni 9y agoThere is no single Java VM. There's a specification with a significant number of different implementations, and the OpenJDK-based one is far from the only one in use today. Also code is still compiled to the same format that the Dalvik VM consumed. ART is just a different system for getting from Java bytecode to something executable.
- bitmapbrother 9y agoThey aren't even architecturally similar. The ART VM is register based while the JVM is stack based.
- giancarlostoro 9y agoTo be fair I did say Java based VM.
- deleted 9y ago[deleted]
- appleflaxen 9y agoyes: this is a terrible title for this post. even the primary article doesn't use this wording. mods: can we get this changed to the original title? "The Language that Stole Android Developers’ Hearts" i don't know if it's fair or not, but it feels like there is somebody making a really concerted effort to astroturf kotlin.
- dom0 9y agoA slightly less sweaty variation on https://www.youtube.com/watch?v=Vhh_GeBPOhs https://www.youtube.com/watch?v=Vhh_GeBPOhs
- fooker 9y agoWhy is Kotlin a better language for Android dev? Won't the platform APIs designed for Java look and feel very non-idiomatic in Kotlin?
- jackmott 9y agoapparently you can actually make the api feel better, per Yegge. Probably due to extension methods.
- naasking 9y agohttps://kotlinlang.org/docs/reference/java-interop.html https://kotlinlang.org/docs/reference/java-interop.html Android is stuck on older Java versions. Kotlin brings Java 8 improvements, and more, without all the Java baggage.
- 2bitencryption 9y agoso if kotlin can bring java 8 features/improvements to a platform that is stuck on an older JVM (and not even the "true" JVM, but another implementation of it), then does that mean these features are not dependent on the runtime? If that's the case, these "java 8" features could be implemented into the Java language without needing to change the runtime? If that is true, why are these changes not being brought to Java itself, if they can be done without a change to the runtime?
- TylerE 9y agoI'm not sure if this is the case, but often it is _possible_ to implement something in, e.g., the stdlib, in a way that is _functional_, but with the right VM support it might be much more performant.
- deleted 9y ago[deleted]
- kuschku 9y agoTake for example Lambdas. Android has no invokedynamic, so every lambda has to be compiled to a class with a method. Android only allows 65k methods overall per linked unit, so that quickly becomes an issue. Kotlin, on the other hand, can do much more intelligent transformations (look at its inline functions).
- dep_b 9y agoSo how is Kotlin's interop with native code? I heard it was still pretty bad with Java despite some updates in that department. Swift can handle some API's but for real interop you can go back to Objective-C(++) wrappers with zero penalty.
- guelo 9y agoIt has very smooth interop, both languages can call each other's methods with no fuss. You can mix and match kotlin and Java files in the same directory. There are one-click tools for auto converting Java to kotlin. It is probably the main reason it beat out Scala on Android, along with the small runtime and superior IDE support.
- klodolph 9y agoI think the question was about e.g. Kotlin <-> C, not Kotlin <-> Java.
- agibsonccc 9y agoI see scala and tons of JNI. I see enough clojure as well. I am not experienced at all with kotlin. JVM languages in general tend to "ignore" making Java native interface "work". Usually you're stuck writing java there.
- nostrademons 9y agoYou mean Kotlin <-> Java or Kotlin <-> C? Kotlin Native (Kotlin <-> C & Objective C) just came out this month, is still a technology preview, and AFAIK is really rough around the edges. Haven't tried it. Kotlin has always had a very good Java interop story, in both directions. I've been using it for a year with Hadoop, AWS, JSoup, Rome, Jackson, DropWizard, Jetty, Apache Commons, ElasticSearch, Weka, and many other standard Java libraries and never had a problem. You basically drop in a library and go. Several of those libraries are either really old (eg. Weka was written in the last millenium) or pretty complex (Jackson is all annotation/reflection based), and I've never really had a problem. You do need to keep track of nulls yourself when crossing the Java boundary, and you need to understand what code Kotlin generates if you're implementing an interface or placing annotations, but both of those are well-documented and pretty typical tasks for any FFI work.
- victornomad 9y agoI'm sure Kotlin is a good language but as a developer with a big codebase I find it difficult to migrate my Java code to Kotlin or mix both languages in the same project. I think I will be confused all the time! If I would be starting with the platform now I'd start with it but now I dont see any reason!
- hn_throwaway_99 9y agoHit this on an iOS project moving from Objective C to Swift, and it wasn't that hard. We just made the decision that whenever we were doing substantial work in a class, we'd move that class to Swift. It had the side benefit of getting ahead on some tech debt/refactorings because moving to a different language was the right time to make those kinds of investments.
- jernfrost 9y agoAnother iOS developer here. Maintained both swift and Objective-C code in multiple apps. Never felt that was a big issue. Perhaps different for us iOs developers as we knew/know it is just a question of time before everybody had migrated to Swift.
- Zak 9y agoIt looks to me like Kotlin is enough like enhanced Java that it's pretty painless to extend an existing Java codebase with it. IntelliJ even has automatic translation of Java source files to Kotlin, though I'm sure there are edge cases where that doesn't go well. The benefit is not having to write Java anymore. If you don't mind writing Java then I think you might benefit from exposure to a wider variety of languages. As for getting confused between languages, most of us work in heterogeneous environments these days, even if it's just something like using Python server-side and Javascript client-side. I don't find confusion over the languages to be a significant difficulty there and I don't think it would be with a mixed Java/Kotlin project.
- xaduha 9y ago> I find it difficult to migrate my Java code to Kotlin or mix both languages in the same project. I think I will be confused all the time! Have you actually tried it or you just think you will be confused?
- grzm 9y agoActual title "The Language that Stole Android Developers’ Hearts"
- m3kw9 9y agoTo summarize, is genius because it keeps devs happy. It's an apple move
- sangnoir 9y agoApple keeps users happy, not devs. Just take a look at Xcode.
- slackingoff2017 9y agoKotlin is exactly what Google needed to light a fire under Oracle's ass. They've been dragging their feet on new Java features for years. That, and the constant threat of Oracle closing Java back up as they're doing to MySQL. The backlash against jigsaw may turn out to be justified. "Modularizing" the JVM would be exactly what you would expect as a first step to making some parts proprietary. If Oracle can wall off parts of the JVM completely they can claim GPL exemption for these parts and start closed source development of "enterprise" level features. Kotlin will do a lot to derail attempts to make Java proprietary. Since it works fine on Java6 JVM's it sends a strong signal to Oracle that "we don't need you, if you piss us off we'll just fork the language".
- 0x0 9y agoAha, so Jigsaw is the JVM equivalent of Android's Google Play Services! :)
- slackingoff2017 9y agoI have no hard evidence of this but it seemed like the most logical explanation. Oracle won't let Jigsaw die after many years of debate, it's really important to them for some reason. On the other end, some people in the community seem willing to sacrifice their position on the community board to stop Jigsaw. There doesn't seem to be any consensus on exactly what makes Jigsaw bad and everyone seems to have their own laundry list of reasons. Even stranger, the use cases and utility of Jigsaw seem limited to just about everyone as the existing package system is quite good. So why is there so much pushing from both ends? Maybe something isn't being said because it would damage the relationships between Oracle and Java sponsors. It's one thing to say "I don't like this module system for these technical reasons". It's another thing entirely to say "I don't trust your company to keep important parts of the JVM on the GPL". A large java partner company accusing Oracle of closing off Java would make big waves in the community that would hurt both parties. Much better to just cause these initiatives to fail by political means.
- threeseed 9y ago
- zzalpha 9y agoYou know, I gotta admit, as someone who rather likes Kotlin, even I'm getting a little exhausted with all the breathless Kotlin articles...
- hoodoof 9y agoNew languages need alot of fuel to reach escape veolcity.
- zzalpha 9y agoEh, with Google's backing, I'd say it has reached liftoff. So far these feel like articles to attract page clicks... The substance has been seriously lacking.
- Larrikin 9y agoLately few haven't been worth reading but it's nice seeing the language get recognition, hopefully there will be more job postings calling for Kotlin
- jacques_chester 9y ago> Eh, with Google's backing, I'd say it has reached liftoff. Like Dart?
- zzalpha 9y agoHah, touche!
- Cthulhu_ 9y agoDart really deflated after it was announced it wouldn't get native support in browsers (next to JS), and energy was instead diverted to WebAssembly. It might still get a revival some years down the road with Fucsia, but we're a long way away from that - plus it would still have an Android compatibility layer I'm sure.
- tkubacki 9y ago
- awaisraad 9y agoAndroid will eventually adopt Swift. It is not a matter of "if" but "when". Who knows 5 year from now, you all will be coding in Swift (for servers, iOS and Android).
- PeterisP 9y agoCan you list arguments why do you believe this to be likely? Interoperability of Swift with the existing APIs and JVM is not impossible, but it is a significant barrier that needs to be overcome and needs very, very significant advantages to justify that.
- awaisraad 9y agoWatch: https://news.realm.io/news/tryswift-chris-robert-end-to-end-application-development-swift-backend/ https://news.realm.io/news/tryswift-chris-robert-end-to-end-...
- PeterisP 9y agoIt doesn't seem to be particularly relevant; potential for server-side usage of Swift is one thing, but Swift apps for Android devices have quite different challenges and reasons for (non)adoption.
- swsieber 9y agoIMO, kotlin makes a much better candidate to be "the" cross platform language for server / client since it supports typescript as a first class citizen, and a native target is coming. You could use the same arguments in the article you posted to posit that everyone will be developing on a Mac. It's not very convincing to me.
- y_u_no_rust 9y agoSwift isn't even a stable language I can't even build projects from github that are only a few months old without doing some wank-tastic manual syntax conversion or using an old version of xcode no one wants to be held hostage to apples nuttery if it's avoidable even .net core and it's associated languages and frameworks are in much better positions
- jarym 9y agoThe language is indeed very nice but really key things that make it so nice are also: 1. The IDE support (without it, it would be somewhat more painful) 2. The fact JetBrains have built a really great new syntax and still have it compile down to regular java bytecode - and bytecode that isn't a total nightmare (I'm looking at you Scala!) 3. JetBrains use it themselves for their own suite of commercial products (mostly code editors) - this made me feel like it was less likely to become a toy language. 4. The fact that coming from Java it is absolutely painless - familiar syntax, automatic code conversion that works well for the most part, and full interop with Java.
- smt88 9y agoCan you say more about what you dislike about compiled Scala?
- jarym 9y agoIn order to implement all the Scala language magic the generated byte code is sometimes far away from what the equivalent Java code byte code would look like. This isn't a problem for most people but it is an issue for anyone who uses stuff like byte code instrumentation - take a look at this issue for example: https://github.com/puniverse/quasar/issues/45 https://github.com/puniverse/quasar/issues/45 It's not a criticism of Scala (the language is just a LOT richer so has to cater for more sophistication). But the difference matters to me which is why I prefer Kotlin over Scala and I'm prepared to miss out on some of that sweet Scala magic.
- edzo 9y agodude, wheres my dart/go android support?
- smt88 9y agoDart: https://flutter.io https://flutter.io Go: https://github.com/xlab/android-go https://github.com/xlab/android-go and maybe https://github.com/gonativeio/gonative-android https://github.com/gonativeio/gonative-android
- base698 9y agoWhen they have a repl maybe they can be considered.
- korm 9y agopub global activate dart_repl pub global run dart_repl And I'm sure Go has a repl too.
- mdasen 9y agoKotlin was an easy win for Google. They didn't really add support for it, but merely bless the support that already existed (and with that blessing comes some assurance that things won't break for Kotlin in future versions of Android). JetBrains was already targeting Android as a big selling point for Kotlin because Android was still on Java 6 and lacked lambdas and streams and all cool new things Java has gained. Kotlin is also very close to Java. It adds some niceties for sure, but they worked hard to make Kotlin very close to Java. Data classes are great, but you could easily turn a data class into a POJO by generating the getters/setters/equals/hashCode/toString. The lambdas are great, but you could easily turn that into a Java 8 lambda or a Java 6 anonymous function. You might lose some elegance in the conversion to Java, but there isn't a lot of ambiguity in the conversion. Kotlin support is relatively easy for Google. It already existed via the normal Java support. Supporting Go and Dart means supporting an entirely parallel set of things.
- yawaramin 9y agoHow is Kotlin compile speed relative to Scala? I imagine a little faster, anyone have experience on mid-size projects?
- deleted 9y ago[deleted]
- lokedhs 9y agoSeems to be about the same as Java. The main source of slowness when compiling is, as always, Gradle and not the compilation itself. Kotlin doesn't fix that.
- yawaramin 9y agoJava-level compile speed sounds amazing. My build system experience is with sbt, which is mostly slow on startup because it checks the versions of every library, every time. The rest of the slowness is from the Scala compiler. A fast Kotlin compile plus a fast command-line build resolution would be a killer combo.
- appleflaxen 9y ago> Standing on stage on Wednesday morning at Google I/O, > Android PM Director Stephanie Saad Cuthbertson broke the > news that Kotlin, which was first released in 2012, is now > officially supported as a “first class” language for > Android... > developers whooped freely when told that they no longer had > to worry that Kotlin fever was just a phase, to be > abandoned like dozens of other cult favorites before it. Nothing that google says about Kotlin could possibly mean that it's not a phase, to be abandoned like other cult favorites before it. Is Kotlin more official than Wave? Reader? Fiber? Loon? Boston Dynamics? Picasa? Titan? Glass? Google+? Labs? Gears? Code Search? Health? Knol? Orkut? Answers? Deskbar? Page Creator? Sites? Google has the right to stop supporting whatever they want, but there is a hard-to-measure cost in developer trust (and goodwill). edit: formatting
- bognition 9y agoNearly all the no defunct things you list were not central to Google's mission. Android is, the move to kotlin was not some Willy nilly experiment it was a strategic move.
- appleflaxen 9y agoyou make a good point, but I would argue that the existence of java means that there is absolutely no more necessity for kotlin, per se, than anything on the list. having it is great insurance for google against oracle, but it shouldn't give any assurance to developers.
- bognition 9y agoThere is definitely pressure from the community to use something other than java to develop Android apps. Add on the pressure from Apple with Swift/iOS it only makes sense that google would invest in ways to make app development easier and faster.
- _pmf_ 9y ago> There is definitely pressure from the community to use something other than java to develop Android apps. People mainly want sane APIs and a retained-mode graphics stack that does not suck. Instead, we got lipstick on our pig (and even here, Google has never been the driving force, but merely reacted to the community).
- deleted 9y ago[deleted]
- tanilama 9y agoExactly this. So tired of these self-entitled feeling-smart conspiracist unnecessary interpolation of unrelated events, e.g. Oracle lawsuit, Google's agenda blahblah. Kotlin is already popular in Android dev crowd. That is the one and foremost factor that why Google would support it. Because there is already a community and a robust toolchain(Thanks to Jetbrain) over there. It is a low-hanging effort for Google to claim by simply signaling a gesture with very little to commit really.
- maxsavin 9y agoGenius is a strong word here
- rtpg 9y agoI'm glad to see Kotlin support (would love Python support but you can't win them all) The Android APIs are still a major problem for me. In web front-ends we've basically gone full FRP and I'm sitting here with my resource files and 10 line invocations to make a notification. This is partly because it's necessary for Java, but I'd love to see a first party API that tries out something a bit more fluent
- BoorishBears 9y agoIt's not necessary for Java, the Android APIs are just horribly written, and the notification is a lot more involved than you'd think because it ties into how the OOM treats your app and the intent system
- rtpg 9y agoI think I get why the notification stuff is so complicated (there's a lot of stuff going on, after all!) It always feels like Android shipped with the low-level API but forgot to provider a higher-level API for the 95% case
- deleted 9y ago[deleted]
- zghst 9y agofrp on the front end varies widely. it's trending towards a true vision but something like Cycle hasn't completely enveloped the mainstream's mind. IMHO, Microsoft and FB need to lead the way on this complete transition on the web
- krschultz 9y agoCheck out Litho, it's built around the principles of declarative APIs and one way data flow with immutable props. Definitely taking inspiration from React.
- umren 9y agoThere is an Anko for Kotlin, that is much more mature and was before Litho
- wolco 9y agoNot sure if swooned is the right word.
- geodel 9y agoNow more I think about It is genius move by Google. With this low effort work Google generated lot of buzz. Android remain same. Tooling and language is developed by Jetbrains for Kotlin. If Kotlin brings in new developer to Android, great for Google, if not, dependable Java is always there.
- xaduha 9y agoThe way I see it - the fact that alternative JVM languages are so underused is a damn shame. And if it becomes more acceptable to not use Java, then all such languages will benefit. For many reasons Kotlin is better as a champion of such a change.
- xaduha 9y agoBTW for those who say that Scala interop with Java is as easy, can you demonstrate how to use this from Java? https://github.com/tumblr/colossus https://github.com/tumblr/colossus
- rjeli 9y agoor even something like Spark which has an explicit Java API is pretty hellish to use in Java...
- emodendroket 9y agoI think the claim there is more like "you can already use the huge amount libraries/your existing code with Java and, with care, you can make your Scala code work the other way" than "interop is seamless back and forth."
- xaduha 9y agoWell Kotlin does indeed claim that interop is seamless back and forth AFAIK.
- emodendroket 9y agoWhich is neat, but unless you are a library designer it's probably not that much of a selling point.
- xaduha 9y agoMajor selling point is the ability to mix Kotlin and Java freely. I just find it funny how Scala guys are saying "me too" at every opportunity. But that always comes with an asterisk, if you look closely. IDE support is as good, Java interop is as good, etc.
- emodendroket 9y agoSorry, I didn't realize you were personally invested.
- zmix 9y agoSuch a misleading title!
- sidcool 9y agoMy question, which I also posted as Ask HN, was that why not Scala?
- simplehuman 9y agoIde integration
- brad0 9y agoI believe there's a runtime issue with Scala. Something about the memory usage? I can't remember the details.
- romanovcode 9y agoBecause Scala doesn't give a !@#$ about backwards-compatibility. It's too unstable for huge project as Android.
- bogidon 9y agoProbably a silly question, but since Android is OSS, what specifically prevents parties other than Google from adding "first class" language support? Does Google not accept (major) external contributions to the build toolchains? Is it the official documentation that's getting rewritten for Kotlin? Or is Google releasing Kotlin-ified wrappers for the Android APIs? Maybe I don't fully understand what new privileges Kotlin is getting.
- zanny 9y agoThe Android APIs are all pretty much Java, so you need a JVM langauge to use them. The NDK requires a Java shim layer, and then you end up writing Java anyway to use most platform features. Google obviously won't support competing first class toolkits on Android. You can already use most JVM languages on Android as is, especially since the switch to OpenJDK. Giving Kotlin first class support is just adding it to their own in house tools. You can already use Scala, for example, if you want. Qt is a great example of how hard it is to bring a 3rd party language to Android. Qt app on Android cannot use native theme, cannot interact with most other apps, don't behave like other apps perfectly, and can be a mess to deploy because of how many Qt libraries you need to bundle in. Google doesn't actively stop you from shipping a Qt app on Android, but it took the Qt company a lot of work to get support where it is now, and its still far from seamless (if you want an example of a great Qt on Android app, try Subsurface Mobile that uses the Kirigami widget set).
- izacus 9y agoKotlin was supported way before this announcement. Scala, Clojure, etc. worked to some extent as well. This is more of a political thing.
- pas 9y agoKotlin is getting Google's blessing. Mentioned in Google's Android development docs and tutorials. That's the magic sauce. Since Kotlin is veeery close to Java, it was already working well on Android. It targets the JVM of Java6, so if you compile your Kotlin android app, it looks like a regular thing compiled from Android Studio. Regular bytecode, that then gets recompiled by dx (dalvik compiler into .dex bytecode - see also https://softwareengineering.stackexchange.com/questions/285235/is-art-an-installation-process-or-an-os-or-a-virtual-machine https://softwareengineering.stackexchange.com/questions/2852... ) And yes, adding new things to Android is ... problematic, because Google doesn't accept pull requests. (It accepts bug reports, and sometimes patches of bugs.) And of course you can propose a big patch adding [see https://source.android.com/source/life-of-a-patch https://source.android.com/source/life-of-a-patch ] .. let's say Swift to the Android Platform, but the project owners are Google employees, and the community cannot really influence what gets accepted. [ https://source.android.com/source/roles https://source.android.com/source/roles ]
- wheelerwj 9y agoalright, wtf is kotlin, why is it suddenly such a big deal, and how big of a deal is it? edit: so i checked this out myself. i have no idea why this is a big deal. another app language? i thought reactnative was all the jazz?
- a_imho 9y agoJudging by your downvotes I guess it is just Google PR out in full force the last couple of days.
- mikespikey 9y agoIt's jetbrains' PR now added with Google. Google employees can destroy any post on reddit. Jetbrains copied that model. Anything about Jetbrains will have tons of artificial posts at the top, their crew upvoting it. It's useless this sort of thing is killing social media completely. WTF is kotlin and why would anyone in their right minds use a language from a text editor company. Beats me.
- mikespikey 9y agoIt's a language created by Jetbrains and they have all their employees heavily brigade promote stuff about Jetbrains on social media. They also probably have an enormous team manipulating Reddit and hackernews votes (perhaps they run a internal email for everyone to vote and comment). Kotlin is an unneeded solution to an inexistent problem. A language in no way comparable to Scala or Java. If you adopt it in your project you'll be in deep shit a couple years from now.
- mikespikey 9y agoBy the way, prepare for downvotes. This is a throwaway account. Jetbrains has all their employees and maybe even external marketing firms in these promotional posts. Especially on Reddit /r/programming my goodness they are obnoxious with their downvote brigades.
- kuschku 9y agoReactNative isn’t exactly native, and the patent situation isn’t ideal either. Kotlin is a language that is like a "better Java", just like C# is a better Java. It happens to provide extension methods, it allows easy creation of domain specific languages, it fixes the Billion Dollar Mistake (no more problems with null!), etc. It’s basically Java, without all the boilerplate, and a lot more modern. Which means any Android dev can easily use it, and be more productive, and create less bugs.
- sandGorgon 9y agoKotlin is already quite popular in the Android community. I would actually point out that it is the engineers at Square (like Jake Wharton) that gave Kotlin it's early legitimacy. The Google announcement excites me for reasons beyond Android - I'm hoping that Google's huge investments in machine learning, play off along with the amount of investment it is going to do in Kotlin. I would love to see a whole bunch of server side infrastructural components built out in Kotlin ... including things like Tensorflow, Spark, etc More than Oracle, I think this is pretty much the death knell for Scala. When you have a far more pleasant language, with IDE integration that is mind blowing, and is supported by one of the largest companies in the world ... And probably is ALREADY MUCH MUCH more popular than Scala at this point
- manojlds 9y agoSpark will save Scala.
- sandGorgon 9y agono too sure about that ;) https://kotlin.link/articles/Using-the-Kotlin-Language-with-Apache-Spark.html https://kotlin.link/articles/Using-the-Kotlin-Language-with-... but I know what you are talking about - Spark is written in Scala.
- geodel 9y agoI noticed last week or so that Apache Kafka deprecated large amount of Scala API and put new Java API in its place. This can't be good for languages which already generate so much news but so little software.
- sandGorgon 9y agoKotlin does not have a "kotlin API", because it was designed ground up for 100% Java compatibility. In fact that's their single biggest invariant. So this is good news for kotlin...And bad for scala ;)
- 9y ago
- vbezhenar 9y agoI wonder if Kotlin could compile to Dalvik bytecode in the future? It might be pointless with Java, because Oracle owns Java compiler and maintaining separate fork might prove hard to do. But with Kotlin it should be somewhat easier. I've heard that the whole Android development is very slow because of those intermediate steps. Also it might help to develop or improve live update features. If I'm developing server applications, I'm usually using JRebel which allows live reloads of bytecode and that's tremendous productivity gain. Same with React Native. I'm not sure about pure Android development.
- ptx 9y agoGoogle already tried compiling Java source code directly to Dalvik bytecode (the "Jack" compiler) but they recently abandoned that approach in favour of improving the regular Java-bytecode-based toolchain. Perhaps because of the new focus on Kotlin? The Android toolchain used to be horrendously slow but has gotten a lot better since they switched from Eclipse and Ant to IntelliJ and Gradle – assuming you have enough RAM to dedicate a few GB to the persistent Gradle process. It now has incremental compilation (of Kotlin and Java), incremental dexing (i.e. converting the compiled Java bytecode to Dalvik bytecode) and incremental reloading ("Instant Run"). And the emulator can run the x86 version of Android nowadays, so it's no longer slowed down by emulating ARM. It's pretty nice.
- throwaway47861 9y agoWhen I see quotes like "Oh my God this is awesome" my sensors go to red flag mode full-time. Devs are people like everybody else and can be hyped. Let's give it time. Not sure what's the big fuss about. Yes I've read about GUI toolkits that reduce the development time. This still doesn't mean much IMO. The business owners will simply become more greedy and will demand more work for less money. I really don't see how the devs will win.
- deleted 9y ago[deleted]