So, back to my foolishness, in my original post, I claimed this as an advantage for Fan:
1. Fan has a core goal to support Java, .NET, and JavaScript platforms.
Scala has great support for Java, and it claims support for .NET, too. I've never used Scala nor Fan on .NET nor Mono, so I can't say which handles the platform better. So I'll just pretend they are equal on this subject (lacking time to gather evidence either way).
Still, I think JavaScript is just important a platform as either Java or .NET. I don't see any reference to JavaScript on the recent poll at scala-lang.org. I have seen references to past efforts, and it seems David Pollak of Lift fame is working on some kind of Scala to JS compiler. (Another reference here.)
On the other hand, here's an example of upcoming Fan JavaScript support. And they list JavaScript as a core focus on their home page. I find that important.
Side note, obviously GWT is more mature than either of these efforts, and for serious cross-platform support (though without Java or .NET so far), see haXe.
I got a good comment on my original post emphasizing the current lack of FFI support for .NET in Fan. Therefore, it presumably exists for Scala already, and that would mean Scala's support for .NET is definitely ahead of Fan's.
ReplyDeleteTo be fair, Scala support in .NET is a couple of versions behind the JVM and (according some blogs) not ready for production yet, but I heard that Microsoft gave a grant to EPFL to remedy that (allowing to dedicate developers to the port).
ReplyDeleteOn the other hand, is not FFI support: Scala compiler generates CLR bytecode, becoming a native .NET application.
> Scala compiler generates CLR bytecode, becoming a native .NET application.
ReplyDeleteUnderstood. Fan will do the same.
By FFI, I mean easy calling directly from Fan or Scala (or whatever) to native .NET or Java (or whatever). In Fan today, you have to use "native" methods to interoperate with native .NET code. In Java, they have FFI support, so you can just call it directly.