Kotlin vs. Scala
codementor.io
codementor.io
This feels like a trad-off between ease-of-use/adoption. It's effectively undefined behavior to reference a nullable type from Java. Another way to consider this is that it's not necessarily worse than working natively in Java, but it can over time be better. This trade-off seems reasonable, as there is no great answer to this problem, but it's almost identical to Java's auto-unboxing of Integer types to int.
Another advantage over Scala is that Kotlin compiler puts null checks on boundaries between Java and Scala, so even if your code pretending to be safe breaks in runtime, you'll catch error as soon as possible, this null won't leak into your internals to bite you tomorrow.
But that's certainly a thing that could be improved. Majority of Java parameters/return values nullability could be automatically inferred by analyzing bytecode.
Methods marked `nonnull` can still be nil sometimes, it's just a promise. Hard bugs to fix. Found one in an Apple framework where I could not think of anything else than comparing the address with 0x00000000 to see if it was nil.
With scala the NPE could appear after the null crossed the java/scala boundary deep into scala code where you'd assume it should be impossible to get an NPE. It can sometimes be hard to fix because the problem is far away from the cause.
[1] https://kotlinlang.org/docs/reference/java-interop.html#null...
>If we choose a non-null type, the compiler will emit an assertion upon assignment. This prevents Kotlin's non-null variables from holding nulls. Assertions are also emitted when we pass platform values to Kotlin functions expecting non-null values etc. Overall, the compiler does its best to prevent nulls from propagating far through the program (although sometimes this is impossible to eliminate entirely, because of generics).
So for JPA entities, each field is marked as nullable, because in Java it is. If we need a null checked version we map it from the nullable fields object to a object that has been null checked and has non-nullable fields (where appropriate).
Wrappers can be written to interact with more traditional Java libraries that do a similar null check and mapper, keeping platform types from propergating intro other layers of the system.
Platform types make interopt way easier, but if you are concerned with null safety you have to write some code to deal with them.
Kotlin is a language that is designed very much in accordance with the "Java philosophy"[1], which states:
Java is a blue collar language. It’s not PhD thesis material but a language for a job. Java feels very familiar to many different programmers because I had a very strong tendency to prefer things that had been used a lot over things that just sounded like a good idea.
Scala has a diametrically opposed design philosophy. It is very much PhD thesis material (multiple PhD theses), was built to study and experiment with novel ideas in language design, which are very unfamiliar, and happy to adopt things that are untried because they sound like a good idea and may be worth a try; it is decidedly adventurous, as opposed to the mostly conservative Kotlin.
So the choice between the two should be first and foremost be about which of these very different philosophies is the right one for your project and team. Comparing them feature by feature (even if a feature is a generally broad one, like "how easy it is to learn", is ultimately misleading) is misleading. Comparing a car and a tank feature by feature may give the impression that there is a wide overlap between them, and that they may be largely interchangeable, while, in fact, they are very different beasts, and rarely interchangeable.
We've had a lot of success bringing people unfamiliar with the language (even with heavy usage of Scalaz) because we try to maintain the right ratio of "Scala experts" to "new to Scala". We end up with 1 to 7 more or less, and it seems to work well.
As long as there's enough resources to steer people away from writing ugly code, the payoff can be quite nice. I have never seen a null pointer exception, almost all of the issues we see in staging/dev are related to JSON/REST,and the only issues we've seen in production have been performance/latency related. Scala really allows us to narrow down the type of bugs we get.
There will be programmers that want to use every feature all the time, and while this happens with every language, the most featureful ones suffer the most from this.
Scala actually has a very consistent and simple syntax which after some initial learning phase is very easy to follow.
The standard library on the other hand, like many APIs which are written in idiomatic Scala, can be difficult to understand, especially at first. I don't admit to understanding it anywhere near as well as I do the Java standard library.
But the issues with Scala in this area is more akin to finding issues with the Java standard library (there are tons!), rather than Java as a language or a VM (two other things which are also correctly referred to as 'Java')
One of the biggest humps I had when getting into Scala full time was getting my head around the fact that many of the features of Scala actually occur at compile time, which as a Java veteran was something that took getting used to.
Well, a language that enables unreadable cleverness can be said to be at fault. This is why languages, like Kotlin, that follow the Java philosophy, intentionally try to avoid introducing primitive constructs (regardless of whether you believe they are "intrinsically" "simple") that give rise to such cleverness, even at the cost of what others may call expressiveness. Valuing expressiveness over readability (which I here define to be no-cleverness) or vice versa is ultimately a matter of personal preference, but it is a value judgment that's made by the language, and languages that differ in the priorities of their values are very different from one another. Just as the difference between a pure language that guarantees (for the most part) immutability vs. a language that doesn't (even though no one is stopping library designers from writing only pure functions) is big, so is the difference between a language that guarantees (for the most part) readability vs. one that doesn't.
I'm always a bit wary of this. Its difficult to write a big code base in two different styles, I prefer a language that is mainly in one style. am I wrong?
In a situation like that, the ability to combine two styles with a relatively low impedance mismatch is very valuable.
Not all problems are amenable to a single paradigm. Functional idioms are well suited to composing small systems, object-like abstraction is well suited to composing large systems and services. Note, object-like, not necessarily object-oriented in the Java sense.
Kotlin being a bit more of a "Java done right", a bit less radical, maybe generates less confusion.
It might also be a sign of Kotlin's documentation being better.
I thought the article was pretty weak, it doesn't really go into much detail into how things like higher-kinded types actually affect Scala programming and why you might miss them (or not) in Kotlin, but does take the time to note that Kotlin needs an extra keyword on the constructor arguments for data classes, something which is almost completely irrelevant (and, IIRC, comes from Kotlin's primary constructor syntax so is a reuse of a more widely applicable pattern).
I don't think I could come away from this with an idea of which one I should learn and use, as it claims.
I didn't quite understand this part. If the code is being inlined on compilation does it matter? I'm assuming the comment meant the output jar file?
(just in case he writes a new article)
> In addition, Scala includes features that you won’t find in either Kotlin or Java, such as full support for pattern matching, macros, and higher-kinded types, which makes Scala ideal for big data processing tasks such as: graph analysis, aggregation computations, and complex, mathematically-focused modelling (e.g. medical modelling.)
This statement is unfortunately not backed by any explanation.
Kotlin has less Stackoverflow questions, but there is also less need for explanation.
Limited operator overloading in Kotlin is a good thing! I've seen way to many Scala with completely absurd and unreadable opertors.
Having worked with both Kotlin and Scala, I see Kotlin as much more pragmatic, what means real world suitable. While Scala was engineered with programming language research in mind (not an ivory tower language like Haskell, though), Kotlin considers more practical aspects like tool support or long-term maintainability. The Scala compiler is, for example, relatively slow. And what about binary (in)compatility in Scala? No word in the article. What about the imminent breaking change with Scala 3 (aka Dotty)?
Scala macros are problematic for tool support. Kotlin will probably get some kind of tool friendly meta-programming, but deliberately not macros.
> Kotlin may be widely considered the easier language to learn, but if it doesn’t have all the features you need, then those few hours spent familiarizing yourself with the Kotlin syntax was time that you could have spent starting to learning a language that does give you the functionality you need.
That may be true for some features, but Scala is a pretty complex beast with many advanced features, which are not only hard to learn, but which also make the code hard to understand or modify. Think of implicit conversions, implicit parameters, which can make it hard to understand what is going on by looking at the code.
Kotlin is much more readable in general: constructos are just named `cunstructor`, init blocks are called `init`, variadic argument are called `vararg`, annotations for co- and contravariance are called `in` and `out`. Scala has to offer method signatures like the following:
flatten[U](implicit ev: <:<[T, Try[U]]): Try[U]
https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hi...