Well, perhaps not perfect we did address some of more painful aspects of both. For instance, via Gosu enhancements we've added methods and properties directly on Date that make it much more useful and via Gosu interval types and expressions e.g., (date1..date2), you can easily navigate between two dates in either direction using the time granularity of your choice.
We've also spent quite a bit of time in an attempt to make generics worth while. First, unlike Java, Gosu generic types are fully reified at runtime. So the pitfalls of type erasure are non-existent in Gosu. This is especially helpful in combination with Gosu enhancements to Java collections. Next, and probably most important, there are no wildcards in Gosu. Wildcards, more specifically use-site variance, is the bane of Java generics, in our opinion. Basically, use-site variance puts the onus on the *user* of a library regarding variance wrt type parameters, which, even if applied correctly, spreads confusion throughout a codebase. I designed and implemented generics in Gosu and I still have a hard time reading and understanding Java code with wildcards.
Essentially, wildcards are an attempt at making Java's static type system "sound", which is a noble goal. But soundness alone isn't useful to us programmers. After all static typing is there for *us*; it's supposed to help *us*. If it's not helping most of the time, what good is it? That is the rationale behind Gosu generics and why we chose to apply array-style variance, which everyone seems to understand. True, it's a trade-off; our type system is not completely sound, but it's a trade-off we've been happy with so far.
Static typing is only useful when it *helps* us. In our view use-site variance via wildcards and the complexities that come with it confuse programmers -- no *help* from static typing there. Declaration site variance is less confusing to users, but has an impact on API design in terms of "in" / "out" data. In other words the degree to which one has to change and understand code is typically not worth the trouble, hence array-style variance. It tends to *help* users of libraries, not hinder, which is what static typing is all about. It's definitely a trade-off, but one we think is worth it.
Slashdot Mirror
We've also spent quite a bit of time in an attempt to make generics worth while. First, unlike Java, Gosu generic types are fully reified at runtime. So the pitfalls of type erasure are non-existent in Gosu. This is especially helpful in combination with Gosu enhancements to Java collections. Next, and probably most important, there are no wildcards in Gosu. Wildcards, more specifically use-site variance, is the bane of Java generics, in our opinion. Basically, use-site variance puts the onus on the *user* of a library regarding variance wrt type parameters, which, even if applied correctly, spreads confusion throughout a codebase. I designed and implemented generics in Gosu and I still have a hard time reading and understanding Java code with wildcards.
Essentially, wildcards are an attempt at making Java's static type system "sound", which is a noble goal. But soundness alone isn't useful to us programmers. After all static typing is there for *us*; it's supposed to help *us*. If it's not helping most of the time, what good is it? That is the rationale behind Gosu generics and why we chose to apply array-style variance, which everyone seems to understand. True, it's a trade-off; our type system is not completely sound, but it's a trade-off we've been happy with so far.
Static typing is only useful when it *helps* us. In our view use-site variance via wildcards and the complexities that come with it confuse programmers -- no *help* from static typing there. Declaration site variance is less confusing to users, but has an impact on API design in terms of "in" / "out" data. In other words the degree to which one has to change and understand code is typically not worth the trouble, hence array-style variance. It tends to *help* users of libraries, not hinder, which is what static typing is all about. It's definitely a trade-off, but one we think is worth it.