views:

860

answers:

5

Hi,

Has anyone here given the Fan programming language a whirl? (pun intended).

My first impression:

  • I like the ability to have the code run on either the .NET or Java VM.
  • The syntax is nice and clean and does not try anything fancy.
  • I have a belief that "the library is the language" and the developers of Fan believe that their USP is their APIs:

But getting a language to run on both Java and .NET is the easy part - in fact there are many solutions to this problem. The hard part is getting portable APIs. Fan provides a set of APIs which abstract away the Java and .NET APIs. We actually consider this one of Fan's primary benefits, because it gives us a chance to develop a suite of system APIs that are elegant and easy to use compared to the Java and .NET counter parts.

Any other thoughts, first impressions, pros and cons?

+1  A: 

It looks very inspired by Ruby. It says that it's RESTful but I don't see how exactly. Compare with boo, which is more mature yet similar in many ways (its syntax is Python inspired, though).

The design decisions to keep generics and namespaces very limited are questionable.

Mark Cidade
Boo can really swtich between Java and .Net like Fan??
Daok
No, but it can switch between Mono and .NET : )Switching between Java and .NET isn't a good enough reason. IKVMM is a JVM implemented in .NET!
Mark Cidade
A: 

This is very interesting.

Java (or C#) was created in order to eliminate Platform dependency by creating a JVM (or CLR) that will compile the code into a specific machine code at run time.

Now , There is a languege which is Virtual Machine independent? umm .... what the hell?!?!

Again , this is a very interesting topic , That might be the future...:) going to one universal single languege

Yo dawg, I heard you like machine independence!
Ken
+2  A: 

I think their explanation sums it up:

"The primary reason we created Fan is to write software that can seamlessly run on both the Java VM and the .NET CLR. The reality is that many software organizations are committed to one or the other of these platforms."

It doesn't look better than all other non-JVM/.NET languages. In the absence of any information about them (their blog is just an error page), I see no reason why they would necessarily get this righter than others. Every language starts out fairly elegant for the set of things it was designed for (though I see some awkwardness in the little Fan code I looked at just now) -- the real question is how well it scales to completely new things, and we simply don't know that yet.

But if your organization has a rule that "everything must run on our VM", then it may be an acceptable compromise for you.

You're giving up an awful lot just for VM independence. For example, yours is the first Fan question here on SO -- a couple orders of magnitude fewer than Lisp.

For what problem is Fan the best solution? Python and Ruby can already run on both VMs (or neither), have big communities and big libraries, and seem to be about the same level of abstraction, but are far more mature.

Ken
+1 - clever way to observe that this is a pretty obscure language ("orders of magnitude fewer than Lisp"). I agree with your observations RE: regarding Python and Ruby: they are new enough and already have a diversity of VM support options.
Mark Brittingham
A: 

I think it looks like a great language feature-wise, but I'm not sure how useful it is. I don't think it is all that useful to target .NET and JVM. Java is already cross-platform, and .NET is too, with Mono. By targeting two VMs, you have to use only the APIs that are available on both. You can't use any of the great native APIs that are available for Java and .NET. I can't imagine that their API is anywhere near as complete as either Java's of .NET's.

Zifre
+1  A: 

I have never heard of Fan until a couple of weeks ago. From the web site, it is about one year old so still pretty young and unproven. There are a couple of interesting points however: First the language is tackling the problem of concurrency by providing an actor model (similar to erlang) and by supporting immutable objects. Second, the object follows the example of Scala with type inference. Type inference allows the programmer to omit type declarations but have it computed by the compiler providing the advantage of short and cleaner code as in a dynamically type language while preserving the efficiency of a statically type language. And last, it seems like a very fast language, nearly as fast as Java and really close or beating the second fastest language on the JM: scala. Benchmark showing the performance can be found at http://www.slideshare.net/michael.galpin/performance-comparisons-of-dynamic-languages-on-the-java-virtual-machine?type=powerpoint.

Robert Monnet