As for portability between Scala.Net and Scala.JVM programs, it was never the goal of the programs. Of cource, programs using only Scala API should be source portable, but if one ues Java or .Net classes it will not be.
As for portability between Scala.Net and Scala.JVM programs, it was never the goal of the programs. Of cource, programs using only Scala API should be source portable, but if one ues Java or .Net classes it will not be.
C# in the .Net 1.0 era was very similar to Java. However, most of the domain-specific knowledge is not in the language, but in the associated class library and runtime. Usage patterns evolve with them.
So, under the assumption that Scala.Net will get traction, in three years, people will be hiring Scala.Net and Scala(JVM) programmers. Educational programs will teaching two different flavors. Books will describe two different flavors.
How does this help Scala or the Scala programmer?
(Then there are more questions, such as: what does Scala.Net offer over C# (which is incorporating functional constructs) and F#?)
We have the same situation right now with C/C++, where people are hiring Windows C++ programmers and Linux C++ programmers. It doesn't seem to hurt that much C++ as a language. And C++ has even smaller "standard library" than Scala.
I see your point, but I do think it hurts C++ and C++ programmers. Programming C++ in Windows or programming C++ in a gtkmm context are very different. Even the most basic things are not standardized (unicode string handling, etc.). Middle ground does exist (Qt), but it does replace most of the STL and has some very basic weaknesses, like vectors that are limited to 2^31 − 1 elements on common platforms.
So, again, I am seriously interested in what fragmentation buys you when porting to a platform that already has 1 1/2 functional languages, supported by its developer?
Things in the Java standard library will work on .NET. Scala, too. If Scala uses .NET classes, this will also work. What's the problem?