Gosu Programming Language Released To Public

llamafirst writes "Guidewire Software released the Gosu programming language for public availability. Gosu is a general-purpose programming language built on top of the Java Virtual Machine (JVM). It is object-oriented, static typed, imperative, and 100% Java compatible (use/extend Java types, implement Java interfaces, compile to Java bytecode). It has type inference (very readable code yet static typing!), in-line functions that you can pass as objects (closures / lambda expressions / blocks), enhancements (inject methods + properties, even on Java types!), and simplified generics. Gosu is provided via the Apache License v2.0. The language itself is not yet open source, although that is planned for a future community release. You can read a complete introduction to the Gosu language, a comparison to other languages, and syntax differences from Java."

Comments

Re:Sounds like Scala

[NightWhistler]

OK, replying to myself because I obviously didn't have enough coffee yet:

They list as the benefits over Scala
  - Extensible type system
  - Easy transition from Java
  - Reified Generics

From those 3 points, only the last one sounds useful...

Equivalent to ABAP or Peoplecode

[Anonymous Coward]

Guidewire is an enterprise software company, and this is the language they most likely code most of their business logic in.

Similar to SAP or Peoplesoft (now owned by Oracle), to keep developer mindshare and promote maintainability and exclusivity, they layer on top of the J2EE stack in some way; in this case it's a bytecode compatible Java replacement (Peoplecode, in comparison, was an interpreter invoked by server calls in the J2EE stack - at least in v8.x).

I think the main reason they're exposing the language widely (as opposed to the above examples) is directly related to the recent Java news by Oracle... bytecode compatible is a key selling point here.

Epic type system fail - universal covariance

[shutdown -p now]

The introduction has this gem:

Gosu supports a simplified version of generics. Generics are a way to abstract the behavior of a class to work with different types of objects, but to still retain type safety. There are no wildcards, and generic types are covariant, like Java arrays, which is usually what you want.

And here's how to make the type system bite the dust with this flaw:

uses java.util.*;
var xs : List<Object> = null;
var ys = new ArrayList<String>();
xs = ys; // type system allows this blatant LSP violation
xs.add(123); // we just added an integer to a list of strings - great
print(xs.get(0)); // yeah, this prints 123 - just to be sure
ys.get(0).length(); // finally, a ClassCastException which should've happened 3 lines earlier

What's funny is that Eiffel has already fallen into the very same trap, and is still trying to dig itself out of it.

Re:Epic type system fail - universal covariance

[shutdown -p now]

Talking about initial null references and all, I don't know about your Java compiler, but mine refuses to compile a program where an initially unassigned reference is attempted to be used. That's what it's all about isn't it - if the initial use of a unassigned (null) reference is prohibited at compile-time, then surely nothing will propagate anywhere and make a mess?

No, that's not it. The initial value of an unassigned local variable is "unassigned", not null, which is why the compiler won't let you use it unless all code paths leading to the current point assign or initialize it. But you can still explicitly initialize with null, and then everything I said applies.

Unassigned fields are initialized to null, and can be used as such with no explicit assignment/initialization.

Additionally, and regardless of how smart/strict a compiler is, are you saying that you would prefer another constant such as say 'unassigned' (which in fact cannot be assigned explicitly) as a value for unassigned references? Then, if an 'unassigned' value pops up from nowhere at runtime after your program has aborted with a thrown exception, you at least know that it was not a null pointer but that you're using a compiler that cannot tell where an unassigned reference is being used? Just thinking aloud...

No. The point is that the type system should ensure that a reference that is possibly null cannot be used without first explicitly checking for null. This generally means that references should be non-nullable by default, and if you want null as a valid value, you have to indicate it as part of the type.

E.g. to borrow C# value type syntax for this - "Foo x" would be a non-nullable local variable, while "Foo? y" would be a nullable one. You shouldn't be able to write "x = null"; nor, for that matter, "x = y", without some check first that "y" is not null. Then, if your program compiles at all, you know that the code does perform all the explicit null checks that need to be done, and, therefore, a NullPointerException is impossible (there's no guarantee that it does what it should in the branches where the value is null, of course, but that's another matter).

Re:Epic type system fail - universal covariance

[shutdown -p now]

Which makes me wonder, what do all these language-design people have against contravariance?

It depends on which of the two we're talking about: variance of method argument and return types, or variance of generics.

For generics, the logic goes roughly like this:

1. Generics are mostly used for collections.
2. Intuitively, people expect a collection of objects of derived class to be substitutable for a collecton of objects of base class, even if it is not sound.
3. In practice, most uses of collections per #2 are sound (i.e. only use the covariant methods, not contravariant ones).
4. So, just default to covariant to make things mostly "just work", at the expense of late error reporting when the use is actually incorrect.

For contravariance of method arguments, the only argument I've seen about the lack of it is that it is very rarely useful in practice (unlike contravariance for generics), so it's simply not worth implementing. I think that it should still be there as a matter of consistency, but it is a valid argument, especially when resources are always limited in practice. As Eric Lippert (of C# fame) once put it, "whenever someone asks me why C# doesn't have feature X, I ask him why C# should have feature X rather than Y, Z or any other that are on the ever-growing backlog".

For Eiffel specifically, which uses covariance, it is because it lets you write stuff such as:

class Foo
  feature equals(other: like Current)
end

which Meyer believes is more correct from OOD point of view than:

class Foo
  feature equals(other: Foo)
end

Because you really want "equals" to be of the same type - it's part of the contract of the type. He goes into more detail on his reasoning here (search for "Unfortunately, the combination of static typing with other requirements of the object-oriented method makes the issues more difficult than they appear at first").

Re:stop posting obvious untruths in stories.

[Anonymous Coward]

You missed out on the whole concept, and you're being aggressively dumb about it. Inferred types are derived from the code, which is, surprise, static. Type inference isn't heuristic at all, go and read about Hindley-Milner.

Re:stop posting obvious untruths in stories.

[shutdown -p now]

if a type is EVER inferred, then the language is NOT statically typed. just because some preprocessor interpreter assigned a static type heuristically doesn't mean the language has anything to do with static typing... in fact, if the language ever infers type, that has EVERYTHING to do with DYNAMIC typing.

You might want to go tell the authors and users of ML (incl. OCaml) and Haskell that they're using dynamically typed languages. Somehow I'm sure they will be very open to this idea.

Re:Why bother? There are better alternatives

[icebraining]

The JVM runs in more systems than the CLR. Assuming it's not too big, you could possibly use it on Android in the near future.

Re:Alright!

[carsongross]

We aren't trying to sell anything to anyone. Well, unless you happen to be an insurance carrier. I assume not.

We just released our language, and are excited about it.

Re:Wonder how this turns out...

[psyclone]

Stop spreading the old Java FUD. Please do some research if you feel so strongly about how someone else chooses to do their work. I don't care what languages you use, why should you care what I use?

This is a mature 3D library + engine:

http://www.jmonkeyengine.com/engine-core/