In 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
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.
That is different than the fragile bytecode problem scala appears to have though. Go's issue is that the API's are changing fast so source code has to be modified frequently.
Scala's issue seems to be that even when the API's haven't changed and there is no need for a sourcecode change a compiler change could break you.
Try to use Scala from Java to see how those bytecodes look like.
It is another layer exactly because you need to translate back those bytecodes into Scala semantics when debugging, when everyone wraps Java libraries into Scala idiomatic wrappers.
> Scala needs to add a runtime when compiling to bytecode
Last time I checked you needed like 500kb of libraries for any scala program compiled to Android. Kotlin is a few kb. Kotlin is a small addition to the java API, Scala needs much more things.
> it is not fully compatible with java as kotlin.
As far as I know, the way scala treats types and functions make it that sometimes you cannot call scala code from java. Well, you can most times but requieres a lot of wrappers. This doesn't happen in kotlin.
I learn scala few years ago, my memory is weak and things may change. But I wanted to use it for android and give up quite quickly because of lot of issues. For kotlin was like love at first sight. No problems at all.
The bytecode is the same but not the standard library of classes. Scala uses different collection classes, Option instead of Optional, companion objects instead of static classes, etc...
In my experience mixing scala and java in a single codebase is inelegant, with plenty of conversion code at the boundaries.
It's also a real pain to call Scala code from Java, which makes blending Java and Scala code in a project, or adding Scala code to an existing Java project, much less attractive.
Unfortunately it doesn't. Even though Scala and Java output the same kind of bytecode, these languages have different language specifications. We currently only support what's in the JLS.
That makes sense. Library compatibility is a tough issue to deal with. Scala.js faces the same issue when it comes to libraries that depend on the Java stdlib. I believe their goal is to port the entire stdlib, but I'm not sure tbh. It might just be an insurmountable problem.
but scala's cousin kotlin doesn't seem to suffer from this a lot... kotlin library-packages don't have kotlin-version to their download link... maybe I'm missing something?
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
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.
reply