A number of threads have arisen where choices are being made with syntax etc. This keeps on reminding me to question the basic item of Fan's joint Java/C# heritage, and who the developers are that Fan is targeting.

Although Java and C# share some common themes there are specific differences between them. I have the sense that Fan has followed more C# conventions rather than Java ones (using vs import, internal vs module, etc.).

The basic question I am raising is who is Fan trying to reach? Java developers or C# developers?

It seems to me that trying to get C# developers to use a non Microsoft language is going to be a really uphill battle. Those developers and shops that use Microsoft know and understand the restrictions of the single vendor - and often embrace them.

Java developers and shops are, IMHO, far more open to the possibility of trying something new, investigation and exploration. All of these are key features needed to try a new language. The concept of polyglot programming is much more of a Java world view.

Finally, there is also far more of a need for a follow on language to Java than there is for a follow on language to C# (as C# is still under heavy development as a language).

All these factors come together to suggest in my mind that Fan needs to follow Java conventions rather than C# ones whenever possible. At least in part this is just a practical recognition of the kind of people in each community (eg. try a straw poll of those subscribed to this forum as to their background).

The ability to run on the CLR is neat, but not the key feature here. What matters is attracting developers, and familiar concepts and syntax matter here, particularly when transitioning developers from Java/Groovy/Scala.

It would be interesting to hear opinions on this. using vs import and other C# vs Java syntax pieces.

Hi Stephen,

I agree with your overall assessment, but to me, the slight C# bias is really not that much of a concern because it happens mostly at the keyword level, which I can deal with. For example, Fan would look a lot less comfortable to me if it enforced the fact that methods need to start with an uppercase letter.

Also, as you say, I think Java developers are more flexible and will therefore adjust better to an alternate syntax/philosophy than C# developers would, so from that respect, the current approach is probably the best way to attract both audiences (I'm not even sure Brian and Andy did this on purpose, maybe it "just happened").

-- Cedric

C# adopted those things like using, virtual, etc. from C++.

Professionally I currently mostly use C#, so I'm unflexible and not open to polyglotism? Cool.

Any Java programmer who is too dumb to learn that import now is called using will be way to dumb to ever get the other more "complex" differences from Java.

Fan seeks to be its own platform, so I don't mind it taking coherent ideas from multiple sources.

But being its own platform does carry risks beyond that of language. For instance, a lot of people are starting to learn OSGi in Javaland. Sure you could make Fan interact with OSGi, but more likely pods need to pick up any needed missing features, and that's a new system to learn. A new platform provides learning curves all over the place.

So it needs to be compelling. And I think another "hey, I've got a Rails-like framework!" won't do it.

From Javaland, there are lots of people interested in a better language, but many don't want to learn a new platform, even if it's cleaner. And mostly, Java folks want good IDE support. They might be willing to learn a new platform if they get super IDE.

I'm not sure what would drive .NET folks, because I don't know that community as well.

I think its a challenging question, based around how should Fan grow. The thrust of my point is really that Java has more of a need for a successor than C# right now, so perhaps easing the transition from Java is the right way to go.

I think it is important to note that the reason for Fan's existence is portability between the JVM and CLR. For the past decade my business has been selling infrastructure software to other software developers - and from that experience I've seen that there is a very, very big business need for something like Fan to solve this problem. Especially in big companies there is typically a large body of legacy code in both Java and .NET. In fact I've seen companies maintain two completely separate products, one in Java and one in C#. Predicting the future is a crap shoot, but I wouldn't be surprised if this is Fan's most important feature for adoption. It is certainly one of the more important features to me and my business.

Although I don't necessarily derive syntax from C# instead of Java. I pick the syntax which I think is best:

• I picked using because I didn't like having import taken as a keyword, there are a lot of APIs which naturally have methods called import/export. I also like using because it does dual duty as an implicit finally/cleanup block (in C#, I haven't done that in Fan yet)
• I picked internal because Java didn't have the concept and it was close to C# meaning - plus as an adjective is unlike to cause naming conflicts like a noun or verb would
• I picked is/as because they are much shorter then instanceof and Java doesn't have the notion of as. Plus I was thinking that we may eventually want an isnot keyword (which doesn't work well for instanceof)
• I picked virtual/override because I think overrides need to be explicitly designed, not something assumed by default
• I picked C++/C# super ctor calls because they work better with named constructors

So it is not really like I choose C# syntax over Java - for each feature I choose what I consider the best syntax. In fact between a Java and C# keyword, I typically choose the Java keyword because Java doesn't have an escape mechanism to use a keyword as an identifier and C# does.