5 ms·

If the JVM magically got rid of nulls and Scala cleaned up some of the slightly wartier bits (implicits come to mind, although they are useful and no clue how I

If the JVM magically got rid of nulls and Scala cleaned up some of the slightly wartier bits (implicits come to mind, although they are useful and no clue how I'd fix em...) then Scala would be my favorite language around by quite a bit. Besides maybe Rust. Really different usecases though.

pjmlp 9y ago
Slow and steady, we don't want to have a Python 3. When minimal value types get implemented, there will be a way to slowly fix those issues. Likewise with the ongoing work with Dotty.
bunderbunder 9y ago
I don't think many of Scala's wartier bits will go away without Java getting its act together re: things like type erasure and a bifurcated type system, because a lot of the odder things in Scala are basically workarounds for deficiencies in the underlying platform. And I just don't see much political momentum behind either of those.
- willtim 9y ago
  Why would type erasure affect the front end language? I'm generally interested.
  - lmm 9y ago
    One of the earliest use cases for implicits is that in Java most types are erased but Arrays aren't, so you can't instantiate an Array in a generic method without having some way to pass the concrete type through.
    - willtim 9y ago
      I do not see why this problem cannot be solved by a compiler rather than a language feature. The type is statically known. It may require additional metadata alongside class files for separate compilation, but I don't see this as a big issue.
      - lmm 9y ago
        The type within a generic method can't be statically known. Consider a generic library method that creates an array somewhere deep in its internals, and is called from an application compiled separately. Now of course you can say that library method requires some extra information from its caller - but how do you reflect that in the method signature in such a way that the binary compatibility constraints are clear and it remains intelligible what the signature is when invoking that method from Java?
        willtim 9y ago
        If it creates a specialised concrete array at runtime, then it can't be a truly "generic" method (whereby I assume generic here means parametric polymorphism?). If you want to specialise object arrays to primitive arrays for efficiency, then I do not see why this cannot be a compiler optimization, since the types are statically known at the use sites. Perhaps Java interoperability is the reason for the choices Scala made, but it doesn't appear that e.g. Scala collections can be used from Java?
        lmm 9y ago
        > If it creates a specialised concrete array at runtime, then it can't be a truly "generic" method (whereby I assume generic here means parametric polymorphism?). I'd argue it is, because the semantics of an array are the same whatever that array contains. In any case, there's no nice alternatives: a lot of Java APIs use Arrays, so not being able to work with them would be unpleasant, while having contexts in which you could work with existing arrays but not instantiate new ones would be weird and not a good fit for an immutability-oriented language like Scala (it would match what Java does, but Java is a lot more mutation-oriented). > not see why this cannot be a compiler optimization, since the types are statically known at the use sites. The use site for the generics could be arbitrarily many compilation units away from the code that instantiates the array. If it were just primitives then we could use @specialized and generate multiple copies, sure, the issue is that Java arrays are unboxed for any type including custom ones. > Perhaps Java interoperability is the reason for the choices Scala made, but it doesn't appear that e.g. Scala collections can be used from Java? They can be used, though in practice it's cumbersome enough that you probably wouldn't want to. The current collections API was created after Scala was relatively well-established and so had different priorities from early language design.
Cyph0n 9y ago
Dotty, Scala Native, and Scala.js are all interesting projects that may just end up improving Scala in the long run. I actually love Scala as it is, so I can't imagine how great it will become when the compile times improve and the warts are cleaned up.
cageface 9y ago
Kotlin is a great middle ground IMO. It has a lot of the expressive power of Scala but is a much simpler language.
ben940830298432 9y ago
So if it became Kotlin?
- sushisource 9y ago
  To be fair I haven't really used Kotlin yet, but from my brief understanding the type system isn't quite as powerful, which is something I really like about Scala.
djsumdog 9y ago
I've gotten to work two jobs with large Scala projects, plus one of my big OSS projects is in Scala and I really would hate to go back to a Java job. Scala does have a lot of issues, I agree (implicits. Bleh! I know it makes DSLs easier, but I could be totally fine without DSLs. Python's Zen has it right: explicit is better than implicit), and some libraries can get into crazy insane syntax for those unfamiliar/just starting out with functional languages. Overall I agree though. I hope the future of the JVM branches away from Java itself and more into the other JVM languages like Scala and Kotlin.

pjmlp 9y ago

Slow and steady, we don't want to have a Python 3. When minimal value types get implemented, there will be a way to slowly fix those issues. Likewise with the ongoing work with Dotty.

bunderbunder 9y ago

I don't think many of Scala's wartier bits will go away without Java getting its act together re: things like type erasure and a bifurcated type system, because a lot of the odder things in Scala are basically workarounds for deficiencies in the underlying platform. And I just don't see much political momentum behind either of those.

willtim 9y ago
Why would type erasure affect the front end language? I'm generally interested.
- lmm 9y ago
  One of the earliest use cases for implicits is that in Java most types are erased but Arrays aren't, so you can't instantiate an Array in a generic method without having some way to pass the concrete type through.
  - willtim 9y ago
    I do not see why this problem cannot be solved by a compiler rather than a language feature. The type is statically known. It may require additional metadata alongside class files for separate compilation, but I don't see this as a big issue.
    - lmm 9y ago
      The type within a generic method can't be statically known. Consider a generic library method that creates an array somewhere deep in its internals, and is called from an application compiled separately. Now of course you can say that library method requires some extra information from its caller - but how do you reflect that in the method signature in such a way that the binary compatibility constraints are clear and it remains intelligible what the signature is when invoking that method from Java?
      - willtim 9y ago
        If it creates a specialised concrete array at runtime, then it can't be a truly "generic" method (whereby I assume generic here means parametric polymorphism?). If you want to specialise object arrays to primitive arrays for efficiency, then I do not see why this cannot be a compiler optimization, since the types are statically known at the use sites. Perhaps Java interoperability is the reason for the choices Scala made, but it doesn't appear that e.g. Scala collections can be used from Java?
        lmm 9y ago
        > If it creates a specialised concrete array at runtime, then it can't be a truly "generic" method (whereby I assume generic here means parametric polymorphism?). I'd argue it is, because the semantics of an array are the same whatever that array contains. In any case, there's no nice alternatives: a lot of Java APIs use Arrays, so not being able to work with them would be unpleasant, while having contexts in which you could work with existing arrays but not instantiate new ones would be weird and not a good fit for an immutability-oriented language like Scala (it would match what Java does, but Java is a lot more mutation-oriented). > not see why this cannot be a compiler optimization, since the types are statically known at the use sites. The use site for the generics could be arbitrarily many compilation units away from the code that instantiates the array. If it were just primitives then we could use @specialized and generate multiple copies, sure, the issue is that Java arrays are unboxed for any type including custom ones. > Perhaps Java interoperability is the reason for the choices Scala made, but it doesn't appear that e.g. Scala collections can be used from Java? They can be used, though in practice it's cumbersome enough that you probably wouldn't want to. The current collections API was created after Scala was relatively well-established and so had different priorities from early language design.

Cyph0n 9y ago

Dotty, Scala Native, and Scala.js are all interesting projects that may just end up improving Scala in the long run. I actually love Scala as it is, so I can't imagine how great it will become when the compile times improve and the warts are cleaned up.

cageface 9y ago

Kotlin is a great middle ground IMO. It has a lot of the expressive power of Scala but is a much simpler language.

ben940830298432 9y ago

So if it became Kotlin?

sushisource 9y ago
To be fair I haven't really used Kotlin yet, but from my brief understanding the type system isn't quite as powerful, which is something I really like about Scala.

djsumdog 9y ago

I've gotten to work two jobs with large Scala projects, plus one of my big OSS projects is in Scala and I really would hate to go back to a Java job. Scala does have a lot of issues, I agree (implicits. Bleh! I know it makes DSLs easier, but I could be totally fine without DSLs. Python's Zen has it right: explicit is better than implicit), and some libraries can get into crazy insane syntax for those unfamiliar/just starting out with functional languages. Overall I agree though. I hope the future of the JVM branches away from Java itself and more into the other JVM languages like Scala and Kotlin.