First public release of the Gosu programming language for the JVM

And it's good advertising for them.

I contacted Guidewire thanks to their blog posts here: http://guidewiredevelopment.wordpress.com/ and AKeefer's posts here at HN.

Unfortunately for them (and me) my higher-ups at the insurance company I work for are clueless and stubborn and decided to go for a reinvent-the-wheel approach at three times the cost (our current insurance solution is based on Sun's Forte4GL http://en.wikipedia.org/wiki/Forte_4GL which, while good at the time, has been abandoned many years ago, and has no support or good IDE) .

bhahaha. came to post that. I laughed out loud.

At least they're honest enough to admit deficiencies. :-)

I found it a subtle admission of fault, because: 1) It's impossible for people who know Lisp to design a language that isn't Lisp(y). 2) You can't be a serious language designer without knowing Lisp, well.

Because of #1 and #2, the author wants to align himself with the amateur school of successful language design (the people responsible for most stuff that comes pre-installed in your Redhat box.) and distances himself from egg-heads and language purists, and their potential criticism.

i'm surprised their comparison matrix omitted fantom (nee fan), which would seem closest in spirit to this sort of java/c# cross

Agreed. All interesting languages.

Not a groovy fan, but groovy++ and compile-time AST transformations sounds like fun.

Speaking of stab, an Eclipse plugin commit just hit svn:

http://code.google.com/p/stab-language/source/detail?r=280

Gosu is gunning for Groovy and Beanshell, not Scala or Clojure.

The later two are bonafide programming languages, not improvements on Java.

Indeed . . . to be fair, back when we decided to rename the language internally, we looked for any existing projects using the name, and we actually contacted the Gosu library guys to make sure they didn't mind us using the name Gosu for our language.

Does this extract from the Reference Guide answer your question?

"Gosu types preserve generic type information at run time. This Gosu feature is called reified generics. This means that in complex cases you could check the exact type of an object at run time, including any parameterization. In contrast, Java discards this information completely after compilation, so it is unavailable at run time.

"Note: Even in Gosu, parameterization information is unavailable for all native Java types because Java does not preserve this information beyond compile time. For example the run time type of java.util.List<Address> in Gosu returns the unparameterized type java.util.List."

From http://gosu-lang.org/doc/wwhelp/wwhimpl/js/html/wwhelp.htm#h...

Here are a few hints in the manual:

"you can add objects to a collection, but not primitives".

Why not?

"The collection and list classes used frequently in Gosu rely on the Java language’s collection classes. However, there are important differences because of built-in enhancements to these classes that use Gosu blocks, anonymous in-line defined functions that are not directly supported in the Java language."

It also has some type-inference that converts:

  var str = {"foo", "bar", "baz"}

To

  ArrayList<String> str = new ArrayList<String>();
  str.add("foo").add("bar").add("baz");

Or some such.

LtU wont be going wild over this any time soon.

We don't work around Java type erasure: if you create some object in Java and pass it off to Gosu, then that information is lost. For Gosu classes that are reified, we actually store the type parameter on the object itself, and it becomes an implicit constructor argument. For generified functions, we pass the type parameter through that's determined statically by the parser. For enhancements on generified Java classes, we also pass through the statically-determined type parameter. I.e. if you have a Gosu class Foo generified on T, when you construct Foo with type param String we'll pass the String type through to the constructor and store it on the object instance so we can retrieve it later. If you have something the compiler thinks is a List of Objects, and you call an enhancement method on List, we'll pass through Object as the type parameter, even if at runtime it's actually a List of Strings. So it's not perfect in its interaction with Java code, but it's usually good enough (and better than losing it entirely). As far as the Java classes we generate go, your generic type Foo has only one class, but as far as Gosu's type system goes, Foo parameterized on Object is a separate type instance from Foo parameterized on String.

No joke. http://www.guidewire.com/our_customers lists some companies that are using the Guidewire insurance products in production. These products are all built in a combination of Java and Gosu (or GScript, as it used to be called).

[I don't work for Guidewire - I worked for an insurance company that evaluated several insurance claims packages, including Guidewire's.]

" I'm not sure it has enough of an advantage over Scala to take a look at."

I can grok Gosu easily... Scala gives me a headache...

Funny you mention that; the original syntax was actually based on ECMAScript, so the syntactic similarities with ActionScript are not accidental.

If you're referring to type notation, I'd argue postfix works much better for languages that are mostly type inferred, as then there is a consistent way of declaring things.