So, if Scala is the top contender for the "new Java", and it's a convenient yet statically-typed language, why bother to consider Fan? Both target the JVM, both have static typing, type inference, closures, and so on. Well, I personally think Fan is a better choice for me.
Here are some of my own top reasons to choose Fan:
1. Fan has a core goal to support Java, .NET, and JavaScript platforms.
2. In Fan, you don't have to figure out existential types or other complex typing. Fan will even do your casting for you in many cases.
3. Fan doesn't encourage or even support global variables. It has an almost Erlang level of attention to concurrency. (Hopefully, people don't abuse 'object' in Scala for global vars, but I fear it's an easy trap, at least for newbies.)
4. In Fan, you can't invent your own <**==!!! operator. (I haven't double-checked this particular one in Scala, but I've seen some doozies.)
5. Fan types are not-nullable by default, with the concept built into the core of the language, instead of being "Option"al.
6. The Fan core library is simple and straightforward. It has functional features but doesn't try to shove complexity down your throat.
7. In Fan, building and modifying nested objects is straightforward.
8. Fan package (or rather pod) namespacing is simple.
9. For Fan, I only have to follow one group on a single lovely site to keep up with the core language happenings.
10. In Fan, all the Ints and Floats are 64-bit. So you don't have to worry about choosing something smaller. And chars are just Ints (using 32-bit code points which fit easily and without worrying about sign bits in that 64-bit space). Breath easy. Oh, and you do still have easy (Big)Decimal support, too, so don't worry about that.
I'm going to be biased and omit my reasons for not choosing Fan, except one. They haven't yet hit 1.0. (Don't let the version numbering scheme fool you.) There are still some backwards-incompatible changes to be made. But the goal is to stabilize things soon.
Poe's Law? Are you serious or parodying?
ReplyDeleteI concur, this must be fun because reading his reasons would clearly made me choose Scala over Fan.
ReplyDelete;)
I think the stated reasons are quite valid: Familiarity, readability and simplicity.
ReplyDeleteAnother drawback is lack of IDE support, though Scala has a few years advantage over Fan.
Thanks for the summary, Casper. And yes, I'm totally serious.
ReplyDeleteMaybe those concerned read it backwards? In my list, "they" means "Fan".
ReplyDeleteOr. to such folks, do you really want to invent your own "<**==!!!" operator???
>> Or. to such folks, do you really want to invent your own "<**==!!!" operator???
ReplyDeleteAt least, i'm pleased to have the option to choose if i'm in need to / adds to conciseness without compromising readability ...
Greetings
Mario
Mario, thanks for clarifying that my list was readable. Understood that different folks have different preferences. This list is definitely me-centric, but I think I'm not the only one who thinks this way.
ReplyDeleteSide note, Fan does have operator support, but only for common operators, and like Python and Groovy, it uses method names for operators to discourage semantic abuse.
But if I can't invent my own operator, I can't write (a Λ b) V ¬(a Λ c) ) Λ ((c V d) Λ ¬(b) as just method calls (shameless plug).
ReplyDeleteI think is pretty powerful
And in case I was unclear, my claim is that Fan has stronger concurrency support than does Scala.
ReplyDeleteI'm probably too late, but I modified the list to clarify better the references to Fan vs. Scala.
ReplyDeleteI'm still positing Poe's Law. Surely you cannot be serious? Do you have any evidence for your claims? You know they are bullshit right? I can't bring myself to believe otherwise.
ReplyDeleteI guess different people have different opinions. And that's okay. I do currently plan to go into more detail in future posts, however.
ReplyDeletefristname, I don't agree! Only 8 of those are reasons to choose Scala over Fan! (All except 3 and 5).
ReplyDelete> 1. Fan has a core goal to support Java, .NET, and JavaScript platforms.
Scala tried this. Clojure tried this. This is _hard_. The main reason to do this is using libraries available for these platforms, but it looks like .NET library access is not working at the moment: no .NET FFI, no mention of events or delegates, etc. in [docLang](http://fandev.org/doc/docLang/Slots.html)
> 2. In Fan, you don't have to figure out existential types or other complex typing.
That is, Fan has a weak static type system.
> Fan will even do your casting for you in many cases.
Scala has implicits, which are a well-designed way to do this. Fan's [implicit casts](http://fandev.org/doc/docLang/TypeSystem.html#implicitCasts) look absolutely horrible. Better just get rid of the static type system if they don't like it so much.
> 3. Fan doesn't encourage or even support global variables. It has an almost Erlang level of attention to concurrency. (Hopefully, people don't abuse 'object' in Scala for global vars, but I fear it's an easy trap, at least for newbies.)
People who would abuse it in this way are unlikely to bother to learn Scala. Erlang also has globals: registered process names, public ETS and DETS tables.
> 4. In Fan, you can't invent your own <**==!!! operator. (I haven't double-checked this particular one in Scala, but I've seen some doozies.)
That is, no support for custom operators at all.
Even <**==!!! is good to have as a possible name: if you ever see it, you know you shouldn't use this library!
> 5. Fan types are not-nullable by default, with the concept built into the core of the language, instead of being "Option"al.
A good thing.
> 6. The Fan core library is simple and straightforward. It has functional features but doesn't try to shove complexity down your throat.
Neither does Scala's core library.
> 7. In Fan, building and modifying nested objects is straightforward.
> 8. Fan package (or rather pod) namespacing is simple.
What is the difference with Scala here? After looking at http://fandev.org/doc/docLang/Namespaces.html, it seems that namespaces in Fan are very different from Java and C# and the name should probably be changed.
> 9. For Fan, I only have to follow one group on a single lovely site to keep up with the core language happenings.
What do you miss when he follows www.scalalang.org?
> 10. In Fan, all the Ints and Floats are 64-bit. So you don't have to worry about choosing something smaller. And chars are just Ints (using 32-bit code points which fit easily and without worrying about sign bits in that 64-bit space). Breath easy. Oh, and you do still have easy (Big)Decimal support, too, so don't worry about that.
Goodbye, decent interoperation with Java/C# libraries. We hardly knew ye.
And if you have a mostly dynamic type system after all, why not go all the way and have BigNums by default?
alexey_rom, thanks for the detailed rebuttal.
ReplyDeleteTotally agree.
ReplyDeleteScala is nice, but i've seen enough completely unreadable example to not want to even bother.
Fan has as much a clean and simple syntax as i've seen.
To me simple syntax = more readable = easier to understand = more maintainable = less bugs.