91–100 of 185 posts
We're in 2016 and Swift is the new rage. In no time it will be the new multiplatform mobile default option.
So it will end as iOS only.
Earlier quoted context omitted.
I address this problem by checking the type at run-time via an assertion. Depending on where you are in the security vs efficiency spectrum, you may opt to ignore those assertions in production. Writing specific tests for that looks very inefficient to me but maybe I am missing something.
I don't see how this reduces the need for a test that the wrong type is handled correctly.
If some function A calls function B with a wrong type, the problem is with function A. So basically, there should be only type tests after IO functions (probably after parsing), the rest can be assertions.
Features: ========= * compiles to Java and Javascript * null safety (optionality) * Lean syntax * Exceptions are unchecked. * Extension functions let you add methods to classes without modifying their source code. * Operator overloading * No macros * Markdown instead of HTML for your API docs * Better Java generics. * Delegation (forwarding methods) * String interpolation Seriously underwhelming....
I initially used Kotlin for a project at work, and I would agree that it is underwhelming. Pivotal had announced official support for Kotlin with Spring Boot, which is what motivated me to give it a try. However, there was no support for the @Transactional annotation in Kotlin at the time, so I ended up writing a decent amount of Java anyways. Then there was a compatibility issue with one of our internal libraries, a…
Earlier quoted context omitted.
I address this problem by checking the type at run-time via an assertion. Depending on where you are in the security vs efficiency spectrum, you may opt to ignore those assertions in production. Writing specific tests for that looks very inefficient to me but maybe I am missing something.
Yes, you are missing a statically typed language. Tests or assertions? Neither. Security or efficiency? Both.
Your comment just solved the problem by ignoring the latter, not much of a contribution to say the least.
For me Kotlin is almost a perfect replacement for Java. It has very few drawbacks, but generally it's much better and it's a pleasure to use it. Not to mention solid IDE support. I've used Kotlin in two small projects. One project was completed year ago and now I'm improving it. Kotlin is just awesome when it comes to refactoring or generalising. Much better than Java. I don't want to compare it to Scala, they target…
That being said scala is not for one who wants to plateau quickly. It takes years.
Earlier quoted context omitted.
Scala is still there, still growing, and a much better language. Kotlin is founded on this anti-intellectual rejection of Scala's advanced features... only to then add them back in piecemeal. So rather than a single powerful general feature like implicits or higher-kinded types you have language-level special cases like extension methods and specific nullness operators. (Don't get me wrong, there are plenty of things…
> Scala is still there, still growing, and a much better language. Kotlin is founded on this anti-intellectual rejection of Scala's advanced features... Each time someone brings up Scala there comes this weird "people who don't like it are anti-intellectual" - well no, people don't like it because it looks weird, had for the longest time abyssimal IDE support, tries to do things which have been solved in production b…
You don't need Scalaz to write Scala code. You can even ignore most of the standard library while you're starting out, and use the Java equivalents.
SBT might seem pointless at first, but the same thing applies there. You don't need to use it, plugins for Maven and Gradle are available. But once you do switch, you'll see how much nicer it is.
ABCL - Armed Bear Common Lisp is another, but Lisp on the JVM instead of Haskell. It's been around for a while, and has become fast for a Lisp on the JVM, though it's not SBCL in speed. It does however support full 32 bit integers on 32 bits sytems compared with SBCL's 29 bits on 32 bit systems due to boxing. Again, not used much in production, although, there are some great testimonials of some cool implementations [2]. I particularly like the Keck telescope code written in Lisp in 1994, ported to ABCL and using Java for some image work and display.
[1] https://github.com/frege/frege
[2] https://common-lisp.net/project/armedbear/testimonials.shtml
I see the biggest market for Kotlin being Android. It manages to provide features that Java will likely never have while still having a fairly small impact on run time, deploy, and APK size. The conversion tool is really great too. It makes it much easier to migrate a project to kotlin, especially when trying to figure out more complex stuff like annotations. I see Kotlin being Android's Swift in the future.
I would love to see that happen (or something similar, like Swift). I fear that it will be hard to move in that direction as long as Google does not push in that direction though. The official word is that we don't need their support in order to write Android apps in Kotlin, which is true and that the gap between objC and Swift was large enough to justify the change but that Java is not that old, which is debatable.…
I don't understand the logic behind this sentence? Why do you need Google to push you somewhere instead of you youself choosing a more productive option?
Kotlin is designed to be easy to integrate into existing Java codebase and our introduction to a largeish Android codebase has been a great success.
Kotlin is getting rapid adoption in the Android community and is quickly getting the same status as Swift has in the iOS world.
The main reasons for the rapid adoption are:
- It's designed to easily integrate into existing Java codebases. This means that starting to use Kotlin is pretty much a case of adding two Gradle dependencies and source files into `src/kotlin`. Interop with Java is painless and doesn't require any special boxing as opposed to some other languages.
- It's standard library is small (~700KB), which is a stark contrast to Scala and some other JVM languages, which pretty much demand usage of ProGuard while developing due to large method count.
- It's performance characteristics are close to Java and doesn't cause catastrophic GC collection issues like some Clojure code does.
- It has pretty much all the features expected from a modern language (nullability, const values, concise syntax) while still keeping code very readable for people who already know Java. The adoption in our Java codebase has thus been rather painless, since code doesn't do any additional magic you wouldn't expect.
- It compiles code to Java bytecode which runs on Java 6 JVM, which is critical for Android.
- It has first-party support in IntelliJ IDEs, which includes Android Studio itself. The IDE experience is significantly better than Scala or Clojure one and almost on par with Java.
So in short, we got a modern language, which is easy to transition to from Java 6, gives seamless interoperability with existing Java code (you can just start writing Kotlin classes in your Java code base), doesn't add overhead to your Android application and doesn't behave strangely performance-wise. There are still some warts to fix (mostly related to static checkers), but Kotlin has been a huge win for Android world.