Is Gosu C# for the JVM?

Question

From what I gather, Gosu is simply C# for the JVM (which is a good thing). Is it true? What are some difference between Gosu and C# (Except the class library and the fact it runs on JVM) ?

Answer 1

We didn't build Gosu to be one language or the other for the JVM. Rather we built Gosu to be a useful language for the JVM. In addition, we recognized that Gosu needed to be familiar to the multitudes of existing programmers who are most comfortable with the imperative, object-oriented model. To achieve that we borrowed heavily from several languages e.g., Java, C#, EcmaScript, Ruby, and some others. The result, we think, is a language that is uniquely positioned on the JVM.

What is entirely unique about Gosu, however, is it's open type system.

Gosu's type system consists of a configurable number of type loaders. A type loader's primary responsibility is to resolve a type name in its domain and return an implementation of Gosu's IType interface. This is what is most unique about Gosu -- its type system is open to other domains to participate with first-class representation. I frequently use the term, DST (Domain Specific Type), to get across the idea. For instance, Gosu does not discriminate between a Gosu Class a Java Class or XML Type or what have you; they're all just types to Gosu's compiler. Check out the DynamicType example in the download to get a glimpse of the power and breadth the open type system provides. Essentially, the example demonstrates that C#'s "dynamic types where required" can simply be a new type loader domain in Gosu. Or check out the Ronin framework to see how easily the web and database domains can map seamlessly into Gosu.

It is important to understand that not all type loader domains in Gosu are required to produce bytecode. Those that do implement an interface for getting at the corresponding Java class. Those that don't provide call handlers and property accessors for reflective MethodInfo and PropertyInfo evaluation, respectively. Note all types provide TypeInfo, see IType.getTypeInfo(). For instance, the parser works against the TypeInfo, MethodInfo, etc. abstractions as the means for a level playing field between disparate types. At runtime, however, unless a type provides a Java bytecode class the MethodInfos and PropertyInfos also are responsible for handling calls.