How is this different than groovy?
It's statically typed.
Gosu – A pragmatic language for the JVM
31–40 of 79 posts
Re: Gosu – A pragmatic language for the JVM
#32These languages, such as Scala are the main reason why Java 8 is so good.
Re: Gosu – A pragmatic language for the JVM
#33What is the origin of the name?
I suppose it was bound to happen.
Re: Gosu – A pragmatic language for the JVM
#34Some of my old co-workers are working with this language because of Guidewire products. Initially the benefit was that you could write code with lambdas that would share a JVM with the product itself, but now that Java 8 has them, the only reason to keep Gosu around is that all that legacy code.
You would never choose Gosu unless you were working with Guidewire products.
Re: Gosu – A pragmatic language for the JVM
#35Re: Gosu – A pragmatic language for the JVM
#36I've tried to figure out for a while why the creators think this language is more practical than, say, Java. They don't seem to answer that directly. To me, it looks too much like other languages I already know. I'm not that impressed with their feature laundry list. That makes me wonder, why I should care about Gosu.
Mainly because of the Open Type System:
http://devblog.guidewire.com/2010/11/18/gosus-secret-sauce-t...
Re: Gosu – A pragmatic language for the JVM
#37Some of my old co-workers are working with this language because of Guidewire products. Initially the benefit was that you could write code with lambdas that would share a JVM with the product itself, but now that Java 8 has them, the only reason to keep Gosu around is that all that legacy code. You would never choose Gosu unless you were working with Guidewire products.
Java 8 lambdas are not real lambdas, they capture only effectively final local variables.
In Gosu you can modify the value of a captured variable.
Re: Gosu – A pragmatic language for the JVM
#38From a quick glance, this looks very nice and well thought-out. The only thing that I didn't like at first glance was that closures aren't explicitly delimited: print( strings.where( \ s -> s.length() > 3 ).sort() ) This looks like it could get ugly very fast if you want to write any kind of non-trivial closures. (Which is some of the same criticism that python often gets, and from which one could learn). "if", "for"…
We use a bit of a dated version of Gosu where I work (something I never thought I'd get to claim on HN...), but I believe that curly braces are perfectly fine to use, and actually required if you have a multi-statement block (essentially starting to look like anonymous functions in Javascript).
Exactly if you want to return just an expression you can avoid them, otherwise if you use statements in the body of the lambda you need curly braces.
Re: Gosu – A pragmatic language for the JVM
#39I'd like it you could set what class this var strings = { "red", "green", "blue" } uses. In some clean way. eg I don't want List, I want ArrayList.
You can do that the way you'd expect: var strings = new ArrayList () { "red", "green", "blue" }
Thanks. That's interesting. Is there a global setting to always use ArrayList instead of List? Actually maybe global is too much... per file setting.
Re: Gosu – A pragmatic language for the JVM
#40Earlier quoted context omitted.
You can do that the way you'd expect: var strings = new ArrayList () { "red", "green", "blue" }
Thanks. That's interesting. Is there a global setting to always use ArrayList instead of List? Actually maybe global is too much... per file setting.
So by default the type inferred is ArrayList, if you want a different type you just specify it.
ex. var strings = { "red", "green", "blue" } //ArrayList
var strings2 : LinkedList = { "red", "green", "blue" }