61–70 of 102 posts
Earlier quoted context omitted.
Build times are supposed to be comparable to Java.
It's slower.
At the moment the gradle plugin doesn't do incremental compilation. If you use it for Android, that's an issue because of the Android build system.
I use Kotlin for free standing programs that run on my laptop/desktop. In these cases it's about as fast as Java, but that's because IntelliJ controls the compilation itself and gradle/maven is used only rarely.
I'm disappointed with the people who are down-voting this comment, as it's, in my opinion, informative and provides a reasonable summation of the differences between Kotlin and Scala. I'd ask people who disagree to put their disagreement into words.
Somehow he feels like he still needs to recycle his nonsense in every thread regardless of how remotely related it is to the topic.
Looking at the syntax briefly it seems very similar to Scala. Is there any major differences between Scala and Kotlin?
Kotlin has a much simpler syntax, and much simpler semantics, than Scala. Specifically, it's largely a very, very good syntax, and small class library extension, for otherwise-vanilla alternative syntax to Java. This is the whole reason for its existence: Kotlin code cleanly interoperates, in both directions, with existing Java code. From my own experience, this means that it's very easy compared to Scala to introduc…
• Mutable vs immutable views (List is read only, MutableList is read/write)
• Safer generics: map[key] which is translated to map.get() has the type bound you would expect rather than Java's much weaker Object type.
• Lots and lots of extension functions to do things like functional programming with them
However, behind the scenes they are still JDK collections, so you can call to and from existing Java with no problems and ... you know, actually, JDK collections library is pretty good. Especially once you get into the scalable concurrent collections.
Earlier quoted context omitted.
Kotlin does have lazy map/reduce/filter: those are available through the Sequence interface.
It's very limited. Many of the functions you use when operating with collections also return lists, not sequences.
I did a tutorial a week or so ago (it's not online yet, unfortunately) on FP in Kotlin. We wrote a little app to do IntelliSense style autocompletion on an n-gram model. The core code was purely functional and used lazyness as well.
I suspect "does Kotlin support FP" is one of those questions that's doomed to turn into a no-true-scotsman thing: whatever support is available will be considered insufficient by true FP fans :-) But it's good enough to let you write code in a typical functional style in many cases, with little cost.
Earlier quoted context omitted.
I'd say the syntax is halfway in between Java and Scala. That makes it much more approachable for Java developers (you can learn the basics in an afternoon), but also less flexible than Scala sometimes.
Yeah, Kotlin looks largely like a simpler, stripped down version of Scala. It's a lot closer to Scala than it is to Java, but it's close enough to Java devs to not have to put in much effort to learn vs learning Scala. I prefer Scala, but not everyone wants to invest the time to learn it in order to gain maybe 25% more expressiveness. Kotlin also seems like a better fit for Android than Scala (and Java for that matte…
Earlier quoted context omitted.
How does it affect built time and the feedback cycle?
Build times are supposed to be comparable to Java.
I personally use Kotlin on a daily basis for Android development and build time is comparable to the one of Java. May I also recommend Anvil framework (https://github.com/zserge/anvil)? It brings declarative layouts and data bindings, which works best with the immutable data types of Kotlin (much like React does in the web).
Earlier quoted context omitted.
It's an error only when the 'when'-expression is used as a value, like assigned to a property, passed as an argument or returned from a function. Otherwise it's not an error. There's also a warning for matching enum values over an incomplete set of enum entries, but otherwise non-exhaustive 'when'-expression is green code. You can basically consider 'when'-expressions to be syntax sugar over Java's if-else or ternary…
> non-exhaustive pattern matches So there are no non-exhaustive pattern matches, is what you are saying? i.e. they all must be exhaustive. Except for your enum example
More info in the official reference: https://kotlinlang.org/docs/reference/control-flow.html#when...
Earlier quoted context omitted.
Yeah, Kotlin looks largely like a simpler, stripped down version of Scala. It's a lot closer to Scala than it is to Java, but it's close enough to Java devs to not have to put in much effort to learn vs learning Scala. I prefer Scala, but not everyone wants to invest the time to learn it in order to gain maybe 25% more expressiveness. Kotlin also seems like a better fit for Android than Scala (and Java for that matte…
In what sense is it closer to Scala? It's more like a slightly nicer Java: All Kotlin code can be translated back to Java (with some boilerplate), but almost no Scala code could be expressed gracefully in Kotlin (or Java).
I'm disappointed with the people who are down-voting this comment, as it's, in my opinion, informative and provides a reasonable summation of the differences between Kotlin and Scala. I'd ask people who disagree to put their disagreement into words.
He has been told by both Scala _AND_ Ceylon language developers that his large walls-of-texts are wrong and are largely made-up stuff which sounds plausible to him. Somehow he feels like he still needs to recycle his nonsense in every thread regardless of how remotely related it is to the topic.