It seems to mostly be compared to Java. Sure, if you don't like functional languages or dynamic languages (Jython, Groovy, JRuby) then I guess it's the best high profile JVM language.
Kotlin Is Better
51–60 of 229 posts
Re: Kotlin Is Better
#52It seems to mostly be compared to Java. Sure, if you don't like functional languages or dynamic languages (Jython, Groovy, JRuby) then I guess it's the best high profile JVM language.
Re: Kotlin Is Better
#53It seems to mostly be compared to Java. Sure, if you don't like functional languages or dynamic languages (Jython, Groovy, JRuby) then I guess it's the best high profile JVM language.
Scala?
Re: Kotlin Is Better
#54The "ew gross weird" reaction to Scala and Clojure is tremendously disappointing (especially coming from someone whose thesis is basically "give this new language a chance")
I worked on a commercial project that used Scala. Never again. Compiles were slow, IDE support was terrible, everyone had their own subset they used. I'm sure it's improved since 2010.
Re: Kotlin Is Better
#55The "ew gross weird" reaction to Scala and Clojure is tremendously disappointing (especially coming from someone whose thesis is basically "give this new language a chance")
I worked on a commercial project that used Scala. Never again. Compiles were slow, IDE support was terrible, everyone had their own subset they used. I'm sure it's improved since 2010.
Two million line scala codebase -> 2 hour clean and rebuild with a top of the line workstation. IDE support has improved, compile times not so much.
Re: Kotlin Is Better
#56Other language built around IDE support: Delphi. The compiler was built with callbacks to provide code completion; it runs in process, as a DLL, as part of the IDE. No accident that Hejlsberg also design C#, and innovated further with TypeScript's language server. He wrote the original Turbo Pascal (IDE + Compiler in the same executable) in assembler, so he's been building IDE + language combos all his life.
and smalltalk is perhaps the ultimate example
Re: Kotlin Is Better
#57The biggest news is: Yegge is blogging again! Glad to see it!
Re: Kotlin Is Better
#58The "ew gross weird" reaction to Scala and Clojure is tremendously disappointing (especially coming from someone whose thesis is basically "give this new language a chance")
Clojure startup times are brutal, and simply not workable in the mobile environment where Android lives.
Re: Kotlin Is Better
#59The "ew gross weird" reaction to Scala and Clojure is tremendously disappointing (especially coming from someone whose thesis is basically "give this new language a chance")
He was initially excited about Clojure, as a Lisp enthusiast, but as I recall he had a clash with the community about the direction of the language.
https://groups.google.com/d/msg/clojure/JiK-WLFT65M/spBka_gs...
Re: Kotlin Is Better
#60The only problem with Steve's rant is that he starts out describing his experience with APIs, but then it turns into an issue of better languages. Presumably Kotlin doesn't wrap the entire Android API with some kind of better API, but most Android API calls would be direct Kotlin->Java calls, so how does Kotlin solve the nasty API issue? Really, this seems to be another Java critique by Steve. He's also written criti…
Extension functions as mentioned are extremely useful. There's just some functionality you need on different types of Android classes (especially views, activites, and fragments) very often but it really isn't worth it to subclass it since not all views or activites need all of the functionality.
The improvement to findViewById was met with tepid applause today because its hardly used anymore due to there being a lot of better options. Kotlin's Android Extensions for the most part has completely eliminated one of big use cases I had for the data binding library, which was refactoring a view where an id and/or the type of view changes and also not needing to constantly have the xml open to directly compare which ID I need to use. I assume its also true for people using a tool like Butterknife. The autocomplete in the IDE could use a little help but its still great.
Anko makes the awfulness of dealing with SQLite on Android almost bearable, although I've only briefly experimented with it. Creating views in code also seems like it is a much more pleasant experience with Anko, although I also have only briefly experimented with it. My day job had me creating fairly complicated views where a preview was absolutely needed, but a lot of apps don't have that complicated a view hierarchy and would probably benefit.
This is just off the top of my head without even looking through the codebase or at my experiments.
Edit: Forgot to mention being able to write an async task like
async() {
val thing = ...
uiThread {
method(thing)
}
}