7 ms·

Gosu – A pragmatic language for the JVM

70 points by Kelet 12y ago

Kelet 12y ago
I'm fairly new to the language, as it hasn't been mentioned much since it's public release several years ago. The language takes many queues from Ruby; for example, "enhancements" are similar to monkey patching in Ruby. The syntax, semantics, and standard library (especially in collections) are also familiar. e.g.: Ruby [1, 2, 3].map { |x| 2 * x } Gosu {1, 2, 3}.map (\x -> 2 * x) Unlike Ruby, Gosu provides a static type system which includes type inference and structural typing (similar to Go's interfaces). It also includes an open type system (http://devblog.guidewire.com/2010/11/18/gosus-secret-sauce-the-open-type-system/ http://devblog.guidewire.com/2010/11/18/gosus-secret-sauce-t...), which allows first-class representations of user created types at compile time – no code generation is needed. F# programmers would find many similarities between Gosu's open type system and F#'s type providers. Like most JVM languages, you can leverage Java compatibility to use all of the third-party libraries you want. Compared to Scala, Gosu tends to eschew complexity for simplicity and pragmatism. Their implementation of generics is a good example of this. And of course, Gosu just has a lot of features that make it enjoyable to work with. Such as the null-safe invocation operator (?.), elvis operator (?:), type variable reification, terse syntax, etc.
- Justsignedup 12y ago
  I'm sorry... My only thought is "yet another JVM language that I won't ever get to use". Because if I have a project that is new, I'm using Ruby until I need a clojure/go back-end or something. If I have an old project in java, I doubt I'll adopt a new language. Hell it's already hard enough to get people to use Scala, and it has tons of benefits over vanilla Java. Clojure, Scala, Klotlin, Groovy, JRuby, and now Gosu... I don't know... I'd love to at least see these sites compare themselves to other languages. Like why Gosu vs Klotlin when Klotlin was already worked on by JetBrains and afaik used for the development of their IDEs...
  - carsongross 12y ago
    Yeah, the JVM alternative language space is pretty crowded. Gosu does have a few advantages, though. One big one is that it is in commercial use at many of the largest companies in the world thanks to its Guidewire heritage. That means that it is going to be continually developed and that its success isn't dependent on immediate uptake. Another is that most other alternative JVM languages are either dynamic or more complicated than Java, whereas Gosu is still statically typed but is (arguably) simpler than Java in many ways. But, yes, it's a crowded space and I can understand skepticism.
  - vorg 12y ago
    > Clojure, Scala, Klotlin, Groovy, JRuby, and now Gosu Gosu is older than those others, except JRuby. That should be Kotlin without an L. And you left out Jython, and Ceylon from JBoss. The recent Nashorn from Oracle will probably take over from Rhino, which you also omitted, and maybe from one or two other JVM languages. Then there's Beanshell, the original "inspiration" for Groovy.
- Kelet 12y ago
  s/queues/cues/
perlgeek 12y ago
From 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", "using" and all the other standard constructs use curly braces around the code - why not lambdas too? Hey, they even call them "Blocks" in the documentation (http://gosu-lang.github.io/docs.html#blocks http://gosu-lang.github.io/docs.html#blocks)
- tredontho 12y ago
  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).
  - lboasso 12y ago
    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.
    - perlgeek 12y ago
      OK, thank you both for the explanation. That does sound sane :-).
tedunangst 12y ago
How is this different than groovy?
- oweiler 12y ago
  It's statically typed.
  - guymcarthur 12y ago
    Groovy allows you statically typed variables also (if you want it).
    - zmmmmm 12y ago
      So the answer would be, it's statically typed by default, whereas Groovy is optionally statically typed. Groovy's static typing can be a little finicky as well, you sort of really need to only use it optionally because using it everywhere gets kind of painful (although it might be better in the most recent versions, type inference is quite hit and miss). But then I would say there are a lot of other advantages that Groovy brings - just a wider usage and knowledge base in general mainly. Edit: Gosu also seems to offer reified generics, I'm not sure how that is implemented, esp. while maintaining the seamless Java interop people speak of, but it could be pretty powerful.
ehartsuyker 12y ago
To me this just looks like uglier Scala. What's the advantage here?
- tredontho 12y ago
  I don't know that I'd compare it to Scala at all, I feel like they have very different capabilities, each of which have their pros and cons. Whether it's uglier... I guess I haven't written enough Scala to know, but my Scala is pretty ugly :(.
  - tormeh 12y ago
    Scala is at it's prettiest when you use a mostly-functional style, but use imperative style when it's substantially easier/shorter/more readable, in my opinion. The most important thing is to have your functions be as pure as possible and their return objects be immutable. What happens inside them is less important. It's worth noting that few, if any, modern languages let you write as ugly code as Scala does. Take mutable objects with inscrutable loops and couple it with spaghetti recursion? Scala doesn't mind....
cven714 12y ago
Something seems amiss with their 'Play' page (http://gosu-lang.github.io/play.html http://gosu-lang.github.io/play.html). The Hello World template printed 'gosu' hundreds of times.
- carsongross 12y ago
  I saw that. The site isn't 100% ready for primetime (we are mid-reboot of the open source effort) so, yeah... pardon our dust. :)
  - carsongross 12y ago
    Nothing a `heroku restart` can't fix. :)
    - cven714 12y ago
      Yep, working great now!
carsongross 12y ago
Hey Everyone, I'm a developer on the project. We are going through an open-source reboot with Gosu, moving all development out onto Github, and the current site and release isn't 100% ready for prime time, but I guess it's too late for that now... I'm happy to answer any questions anyone has. Also, we are working on a web micro-framework called SparkGS: http://sparkgs.github.io/ which is a wrapper around the excellent SparkJava library.
- Kelet 12y ago
  My apologies for the preemptive publicity then, I didn't realize the state of the project. I just found it on Wikipedia when looking at JVM languages and thought it had some interesting aspects.
  - carsongross 12y ago
    Not at all! Stuff like this just makes it easier for the Gosu group at Guidewire to advocate for more open source resources, so thank you!
esgeh 12y ago
I'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.
- lboasso 12y ago
  Mainly because of the Open Type System: http://devblog.guidewire.com/2010/11/18/gosus-secret-sauce-the-open-type-system/ http://devblog.guidewire.com/2010/11/18/gosus-secret-sauce-t...
  - jimbokun 12y ago
    That's really brilliant, and should probably headline the list of Gosu features.
ionforce 12y ago
What is the origin of the name?
- carsongross 12y ago
  It was originally called "GScript" but that was too generic so the lead eventually came up with "Gosu" which let us keep our ".gs" extension.
  - vutekst 12y ago
    I associate the word "Gosu" with the Korean/International StarCraft scene, where the word describes a very skilled player. I wonder the project lead was also thinking of that.
    - ionforce 12y ago
      This is exactly what I was thinking.
    - scottmck 12y ago
      Heh. Well, although the lead is probably several degrees removed from the StarCraft gaming world, the Korean meaning of the word did play a part. But, honestly, there are only so many 4 or 5 letter words that start with G and also have an S.
- gosu 12y ago
  I suppose it was bound to happen.
Goranek 12y ago
I hate whitespaces here. join( ", " ) print( aFile.read() )
- carsongross 12y ago
  Good news: the code compiles even without it!
dothething 12y ago
Why Gosu over Groovy or Kotlin?
- hugh4life 12y ago
  Gosu actually went public before Kotlin and I think Gosu helped inspire Kotlin in a couple of ways. While I'm glad Gosu keeps chugging along, I can't see myself choosing it over Kotlin.
- vorg 12y ago
  Gosu, like Scala, Kotlin and Ceylon, was built to be statically typed from the ground up and thoroughly tested and documented by many developers, with dynamic typing added to some of them as an afterthought, like the Dynamic type in Scala. Groovy, like Clojure, Beanshell, Jython, JRuby, Rhino and Nashorn, was built to be dynamically typed from the ground up, with static typing added opportunistically in version 2.0 by a single developer and requiring klunky annotation syntax.
ape4 12y ago
I'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.
- carsongross 12y ago
  You can do that the way you'd expect: var strings = new ArrayList<String>() { "red", "green", "blue" }
  - ape4 12y ago
    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.
    - lboasso 12y ago
      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<String> = { "red", "green", "blue" }
      - ape4 12y ago
        thanks
cmiller1 12y ago
Not to be confused with the Gosu 2D game dev library http://www.libgosu.org http://www.libgosu.org
alexnewman 12y ago
These languages, such as Scala are the main reason why Java 8 is so good.
generalpf 12y ago
Some 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.
- lboasso 12y ago
  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.
  - mark_mcs 12y ago
    They are real lambdas. They're not real closures.
  - deleted 12y ago
    [deleted]
- carsongross 12y ago
  That's probably true today, but we are aiming to get to a spot where you could choose to use Gosu alongside Java, rather than replace it wholesale. Gosu does have some features that make it very nice in some contexts when contrasted with Java. A very simple, but amazingly useful example is properties, which have the useful behavior of being both l-values and r-values. Easy to implement, but Java doesn't have them. Another useful differentiator are feature references: var methodRef = someInstance#someMethod() which have all sorts of interesting applications as a sort of type-safe reflection syntax. And so on.
heavenlyhash 12y ago
Oh man. Nice string interpolation. Can shell script with a shebang. All those little niceties like the `.?` operator. Map literal definitions. Type inferring declarations (like golang: strongly typed, but not wearing out your keyboard). "enhancements"... very interesting, deserve a full paragraph. And I'm just cherrypicking my favorite features; there's so many more. "enhancements" feel like monkeypatching in that they let you attach things to existing classes for pretty code. This left me sweating at first -- implementations of features like this in ruby seems to be a large part of why the language is both challenging as you add devs (I recently saw one class spanning 4 files and 3 gems, I don't even) and frankly slow, and scala has similar performance barriers brought on by 'implicits' [1] and their ilk. But in gosu, enhancements appear to be defined in an statically disbatchable way so there's zero runtime timewasting, and they're also only valid for your syntactical convenience, they don't complicated inheritance or interface fitting. Looks like all the beauty, none of the sticky mess. Very interesting. Compatibility looks like a better story than some of the alternatives -- both groovy and scala always felt to me like their mechanics encouraged an extend+extinguish feeling to their libraries because of the radical overhaul or complete dismissing of types, whereas gosu looks like you could sanely call it from java. I (as a purely personal observation; others may disagree) found I could never write a groovy or scala library and ask a java developer to use it with a straight face, and with gosu, it looks like maybe I can! I'm speaking as someone who's just seeing the language for the first time today, so perhaps my enthusiasm will be modified by practical experience later... but I'm seeing a lot to love both in the examples and in the general philosophy of pragmatism. A language that lets me do more with fewer characters while not giving up ground on compile-time checks and performance is exactly what I want to see more of. I look forward to playing with this! If any gosu developers are here, my biggest single beef right now is I can't instantly see from your docs what my process is like if I'm going to ship a jar. I assume it can be done and it's not hard to script, but it would be great to see up front, because if that isn't smooth, then my impressions of using it to ship a library usable from other java projects (or feed it into cross compilers, etc) is impacted. I found some docs at [2], but it appears to mostly talk about shell script style usage; ctrl-f for "jar" hit nothing. Perhaps I just haven't looked hard enough yet :) (Also, that help site is one of those annoying things where there's no content without javascript, and even after allowing it, middle click gives me some sad snippet of javascript instead of opening the page I wanted. The rest of your site looks great; I hope the wave of design refresh is going to wash over here soon too.) [1] https://stackoverflow.com/questions/3606591/why-does-intellij-idea-compile-scala-so-slowly/3612212#3612212 https://stackoverflow.com/questions/3606591/why-does-intelli... [2] https://gosu-lang.github.io/doc/wwhelp/wwhimpl/js/html/wwhelp.htm#href=Gosu%20Reference%20Guide/getting-started-gosu-opensource.04.3.html#1496914 https://gosu-lang.github.io/doc/wwhelp/wwhimpl/js/html/wwhel... Edited: to note that my spate of points-to-love at the top is by no means exhaustive.
neilellis 12y ago
At (insert swear word here) last! "The classpath can also include Maven coordinates, and Gosu will automatically resolve and download them at runtime: #! /path/to/gosu classpath "../src,org.gosu-lang.gosu:sparkgs:0.1.0" print( "Here is a library object: ${new SweetLibraryObject()}") " Been writing java for 14 years and I've never had a nice way to run scripts. Now if you can work natively (tougher than folk think) with JSON I'd be very happy indeed. That would include supporting fully de-typed data not nasty schema based data binding. I've switched to NodeJS/JS because they speak the language of the web (not JS, but JSON). But I can't see why other languages can't learn to.
- carsongross 12y ago
  :) It's the little things, isn't it? Regarding JSON support, Gosu has map literal syntax and integrates easily enough with Google's GSON library. Not great, but not terrible. More speculatively, I put together a type-loader to work with JSON content specified using JSchema: https://github.com/gosu-lang/Goson But I'm not sure it works with the current release. (This HN post caught us mid-rework...)
- benjiweber 12y ago
  In Java8 you can #!/bin/jjs to start a Nashorn (JavaScript) script running on the JVM. Nashorn has shell extensions that helps you write shell scripts https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extens... It's also a great way to bootstrap your Java app with some JSON config http://benjiweber.co.uk/blog/2014/05/08/json-to-java-interfaces-with-nashorn/ http://benjiweber.co.uk/blog/2014/05/08/json-to-java-interfa...
- zmmmmm 12y ago
  Well, Groovy has done it for a long time ... #!/usr/local/bin/groovy @Grab(group='org.springframework',module='spring',version='2.5.6') import org.springframework.jdbc.core.JdbcTemplate println "..." Actually Groovy looks really similar to Gosu and one would argue has a lot wider recognition and support. But then, I do like that Gosu feels much "cleaner" in some way that Groovy doesn't.
alexdowad 12y ago
Mildly interesting. Gosu definitely has some features that would be nice in Java, and would have been impressive 10 years ago, but here and now, it just looks like a slightly different spin on a dozen other languages I have seen before. It would be very helpful if the creators made a page (linked to right from the home page) explaining their philosophy and guiding principles, and how their design differs from other languages in the same space. Don't tell us fluffy things like "we choose simplicity over complexity". #1, that is not a trade-off. #2, "simplicity" is such a vague and overused word that it's hard to know what you mean. (What I think they mean by "choosing simplicity" is: keeping the feature set and number of syntactic constructs small.) Another point: "For the JVM" is a 2-edged sword. If I see a programming language described as "for the JVM", it would make me think twice about investing the time to learn it. The JVM is good technology and I do make use of it, but for reasons I won't detail here, I don't want to be locked in to it. "Can run on the JVM" is a different matter. "The compiler has a JVM backend, among others" is great. "Currently runs only on the JVM, other backends are coming" is OK. If Gosu was specifically designed for very tight integration with Java, such that it wouldn't make sense to separate it from the JVM, that is a design trade-off and should be explained on the "design rationale" page I suggested above.
- lboasso 12y ago
  Gosu is more than 10 years old. For some historical background/design decisions please have a look at this article: http://www.drdobbs.com/open-source/language-of-the-month-gosu/231001429# http://www.drdobbs.com/open-source/language-of-the-month-gos...
maelstrom2 12y ago
Another in the long line of languages that are created to solve a problem that doesn't exist. Even worse, created as a way to force P&C carriers to be tightly coupled to a proprietary piece of software. With one industry being the only relevance for the language and that industry with usually the worst IT technical talent available. I get it, Guidewire has some very talented engineers. Probably at least a few of the best in the valley. However, you're pushing it out to the dregs of the IT world and hoping to make it fly and gain adoption when those using it are generally just drawing a paycheck for the pulse their body maintains.
- dventimi 12y ago
  > Another in the long line of languages that are created to solve a problem that doesn't exist. I assure you that the problems Gosu was created to solve did indeed exist at the time that it was created. > Even worse, created as a way to force P&C carriers to be tightly coupled to a proprietary piece of software. I assure you this also is not true. For evidence, I encourage you to notice the fact that Gosu is not a proprietary piece of software. > With one industry being the only relevance for the language Put another way. "Number of heavily-capitalized industries where Gosu is heavily used: At least 1." Would you rather it be 0? > and that industry with usually the worst IT technical talent available. Please. There's fierce competition for that distinction.
  - maelstrom2 12y ago
    I didn't say Gosu was proprietary. They've taken this whole "open-source" catchphrase and made some CIO's, that generally don't know anything other than budgets and bodies, feel better. It does, however, tie you completely to the Guidewire platform/products. A very smart move by the company. It will be decades before these slow-moving behemoths will rip out this language that was a blip on the radar. That doesn't mean it was needed or is as historically important as the devs seem to think.
    - dventimi 12y ago
      Oh, God. Trust me, the swiftness or tardiness with which insurance companies replace their Guidewire stack will have nothing whatsoever to with Gosu.
heuakr 12y ago
This language is only used by GuideWire people. And whoever talks about it positively are GuideWire employees. It was called GScript before. The creators of the language did it because they could, but then some consultant dude gave them the idea to write an insurance application on it. They wrote Guidewire claims center, plus a bunch of proprietary development tools to support the language. Do I have to say what went wrong? Anyway, eventually they found it was too hard to maintain the language and keep any traction on it, so they open sourced it and called it Gosu. I spent a lot of time with this thing. My best advice is: stay away from it.
- carsongross 12y ago
  That's certainly one perspective. Here's another one: Gosu is the life's work of some talented developers at a successful startup, who have tried hard to build a pragmatic successor to Java. It is not perfect, and of course you should be skeptical of any new technology, but it has some promise, and here are some interesting features of the language: * Type-safe reflection with feature literals * Embedded classpaths in programs, including maven coordinates * Integrated type-safe templates * Pragmatic extension methods on the core java data structures via enhancements * Null-safe operators * Mixin support via the delegate keyword And so on...
- ternaryoperator 12y ago
  If you're going to piss all over someone's work, how about providing details about what you didn't like? Supposedly rhetorical questions like "Do I have to say what went wrong?" are just character assassination. Yes, of course, you do have to say what went wrong if you're going to advise devs to stay away from it with no other information.
carsongross 12y ago
One fair comment that comes up frequently is that, with Java 8 out, Gosu's closure support is less of a win. Certainly true, so let me mention some other high-level features Gosu has that contrast favorably with Java: * Type-safe reflection with feature literals * Embedded classpaths in programs, including maven coordinates * Integrated type-safe templates * Pragmatic extension methods on the core java data structures via enhancements * Null-safe operators * Mixin support via the delegate keyword * Implicit interfaces, like Go * Type-safe templates built into the langauge * Properties support (seems small, but it makes a big difference in day to day coding.) And, of course, the Open Type System, which is essentially an API for introducing new types to the gosu compiler: http://devblog.guidewire.com/2010/11/18/gosus-secret-sauce-the-open-type-system/ http://devblog.guidewire.com/2010/11/18/gosus-secret-sauce-t... All at least interesting, if not compelling.
deleted 12y ago
[deleted]
icambron 12y ago
Very cool. I'm starting a JVM-based project, and I'd love to use this in the places where I was planning to use JRuby. Besides being impressed overall, two pieces of feedback: * On enhancements, I very much like C# extensions design, partially because I do have to import them explicitly. One of the things I dislike in Ruby is that you don't know where your methods come from, and that gets more complicated when they're actually from third-party gems. If a jar is giving me an enhancement, how does that work? How do I handle name conflicts? * I'd love to have some built-in support for shell commands, a la Ruby's tick marks.
- carsongross 12y ago
  On enhancements: yeah, that's reasonable, but we also wanted to be able to add some obviously missing methods to things like List, globally available. We've toyed around with a scope declaration on the enhancement, e.g. global, module, or explicit but haven't settled on anything. Back-tick has been on the list forever and wouldn't be hard to add. Open a ticket. :)
  - icambron 12y ago
    Ticket submitted.
dutchrapley 12y ago
It's interesting to see that Gosu was announced here two years ago without a single comment. https://news.ycombinator.com/item?id=3671054 https://news.ycombinator.com/item?id=3671054

70 points by Kelet 12y ago

Kelet 12y ago

I'm fairly new to the language, as it hasn't been mentioned much since it's public release several years ago. The language takes many queues from Ruby; for example, "enhancements" are similar to monkey patching in Ruby. The syntax, semantics, and standard library (especially in collections) are also familiar. e.g.: Ruby [1, 2, 3].map { |x| 2 * x } Gosu {1, 2, 3}.map (\x -> 2 * x) Unlike Ruby, Gosu provides a static type system which includes type inference and structural typing (similar to Go's interfaces). It also includes an open type system (http://devblog.guidewire.com/2010/11/18/gosus-secret-sauce-the-open-type-system/ http://devblog.guidewire.com/2010/11/18/gosus-secret-sauce-t...), which allows first-class representations of user created types at compile time – no code generation is needed. F# programmers would find many similarities between Gosu's open type system and F#'s type providers. Like most JVM languages, you can leverage Java compatibility to use all of the third-party libraries you want. Compared to Scala, Gosu tends to eschew complexity for simplicity and pragmatism. Their implementation of generics is a good example of this. And of course, Gosu just has a lot of features that make it enjoyable to work with. Such as the null-safe invocation operator (?.), elvis operator (?:), type variable reification, terse syntax, etc.

Justsignedup 12y ago
I'm sorry... My only thought is "yet another JVM language that I won't ever get to use". Because if I have a project that is new, I'm using Ruby until I need a clojure/go back-end or something. If I have an old project in java, I doubt I'll adopt a new language. Hell it's already hard enough to get people to use Scala, and it has tons of benefits over vanilla Java. Clojure, Scala, Klotlin, Groovy, JRuby, and now Gosu... I don't know... I'd love to at least see these sites compare themselves to other languages. Like why Gosu vs Klotlin when Klotlin was already worked on by JetBrains and afaik used for the development of their IDEs...
- carsongross 12y ago
  Yeah, the JVM alternative language space is pretty crowded. Gosu does have a few advantages, though. One big one is that it is in commercial use at many of the largest companies in the world thanks to its Guidewire heritage. That means that it is going to be continually developed and that its success isn't dependent on immediate uptake. Another is that most other alternative JVM languages are either dynamic or more complicated than Java, whereas Gosu is still statically typed but is (arguably) simpler than Java in many ways. But, yes, it's a crowded space and I can understand skepticism.
- vorg 12y ago
  > Clojure, Scala, Klotlin, Groovy, JRuby, and now Gosu Gosu is older than those others, except JRuby. That should be Kotlin without an L. And you left out Jython, and Ceylon from JBoss. The recent Nashorn from Oracle will probably take over from Rhino, which you also omitted, and maybe from one or two other JVM languages. Then there's Beanshell, the original "inspiration" for Groovy.
Kelet 12y ago
s/queues/cues/

perlgeek 12y ago

From 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", "using" and all the other standard constructs use curly braces around the code - why not lambdas too? Hey, they even call them "Blocks" in the documentation (http://gosu-lang.github.io/docs.html#blocks http://gosu-lang.github.io/docs.html#blocks)

tredontho 12y ago
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).
- lboasso 12y ago
  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.
  - perlgeek 12y ago
    OK, thank you both for the explanation. That does sound sane :-).

tedunangst 12y ago

How is this different than groovy?

oweiler 12y ago
It's statically typed.
- guymcarthur 12y ago
  Groovy allows you statically typed variables also (if you want it).
  - zmmmmm 12y ago
    So the answer would be, it's statically typed by default, whereas Groovy is optionally statically typed. Groovy's static typing can be a little finicky as well, you sort of really need to only use it optionally because using it everywhere gets kind of painful (although it might be better in the most recent versions, type inference is quite hit and miss). But then I would say there are a lot of other advantages that Groovy brings - just a wider usage and knowledge base in general mainly. Edit: Gosu also seems to offer reified generics, I'm not sure how that is implemented, esp. while maintaining the seamless Java interop people speak of, but it could be pretty powerful.

ehartsuyker 12y ago

To me this just looks like uglier Scala. What's the advantage here?

tredontho 12y ago
I don't know that I'd compare it to Scala at all, I feel like they have very different capabilities, each of which have their pros and cons. Whether it's uglier... I guess I haven't written enough Scala to know, but my Scala is pretty ugly :(.
- tormeh 12y ago
  Scala is at it's prettiest when you use a mostly-functional style, but use imperative style when it's substantially easier/shorter/more readable, in my opinion. The most important thing is to have your functions be as pure as possible and their return objects be immutable. What happens inside them is less important. It's worth noting that few, if any, modern languages let you write as ugly code as Scala does. Take mutable objects with inscrutable loops and couple it with spaghetti recursion? Scala doesn't mind....

cven714 12y ago

Something seems amiss with their 'Play' page (http://gosu-lang.github.io/play.html http://gosu-lang.github.io/play.html). The Hello World template printed 'gosu' hundreds of times.

carsongross 12y ago
I saw that. The site isn't 100% ready for primetime (we are mid-reboot of the open source effort) so, yeah... pardon our dust. :)
- carsongross 12y ago
  Nothing a `heroku restart` can't fix. :)
  - cven714 12y ago
    Yep, working great now!

carsongross 12y ago

Hey Everyone, I'm a developer on the project. We are going through an open-source reboot with Gosu, moving all development out onto Github, and the current site and release isn't 100% ready for prime time, but I guess it's too late for that now... I'm happy to answer any questions anyone has. Also, we are working on a web micro-framework called SparkGS: http://sparkgs.github.io/ which is a wrapper around the excellent SparkJava library.

Kelet 12y ago
My apologies for the preemptive publicity then, I didn't realize the state of the project. I just found it on Wikipedia when looking at JVM languages and thought it had some interesting aspects.
- carsongross 12y ago
  Not at all! Stuff like this just makes it easier for the Gosu group at Guidewire to advocate for more open source resources, so thank you!

esgeh 12y ago

I'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.

lboasso 12y ago
Mainly because of the Open Type System: http://devblog.guidewire.com/2010/11/18/gosus-secret-sauce-the-open-type-system/ http://devblog.guidewire.com/2010/11/18/gosus-secret-sauce-t...
- jimbokun 12y ago
  That's really brilliant, and should probably headline the list of Gosu features.

ionforce 12y ago

What is the origin of the name?

carsongross 12y ago
It was originally called "GScript" but that was too generic so the lead eventually came up with "Gosu" which let us keep our ".gs" extension.
- vutekst 12y ago
  I associate the word "Gosu" with the Korean/International StarCraft scene, where the word describes a very skilled player. I wonder the project lead was also thinking of that.
  - ionforce 12y ago
    This is exactly what I was thinking.
  - scottmck 12y ago
    Heh. Well, although the lead is probably several degrees removed from the StarCraft gaming world, the Korean meaning of the word did play a part. But, honestly, there are only so many 4 or 5 letter words that start with G and also have an S.
gosu 12y ago
I suppose it was bound to happen.

Goranek 12y ago

I hate whitespaces here. join( ", " ) print( aFile.read() )

carsongross 12y ago
Good news: the code compiles even without it!

dothething 12y ago

Why Gosu over Groovy or Kotlin?

hugh4life 12y ago
Gosu actually went public before Kotlin and I think Gosu helped inspire Kotlin in a couple of ways. While I'm glad Gosu keeps chugging along, I can't see myself choosing it over Kotlin.
vorg 12y ago
Gosu, like Scala, Kotlin and Ceylon, was built to be statically typed from the ground up and thoroughly tested and documented by many developers, with dynamic typing added to some of them as an afterthought, like the Dynamic type in Scala. Groovy, like Clojure, Beanshell, Jython, JRuby, Rhino and Nashorn, was built to be dynamically typed from the ground up, with static typing added opportunistically in version 2.0 by a single developer and requiring klunky annotation syntax.

ape4 12y ago

I'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.

carsongross 12y ago
You can do that the way you'd expect: var strings = new ArrayList<String>() { "red", "green", "blue" }
- ape4 12y ago
  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.
  - lboasso 12y ago
    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<String> = { "red", "green", "blue" }
    - ape4 12y ago
      thanks

cmiller1 12y ago

Not to be confused with the Gosu 2D game dev library http://www.libgosu.org http://www.libgosu.org

alexnewman 12y ago

These languages, such as Scala are the main reason why Java 8 is so good.

generalpf 12y ago

Some 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.

lboasso 12y ago
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.
- mark_mcs 12y ago
  They are real lambdas. They're not real closures.
- deleted 12y ago
  [deleted]
carsongross 12y ago
That's probably true today, but we are aiming to get to a spot where you could choose to use Gosu alongside Java, rather than replace it wholesale. Gosu does have some features that make it very nice in some contexts when contrasted with Java. A very simple, but amazingly useful example is properties, which have the useful behavior of being both l-values and r-values. Easy to implement, but Java doesn't have them. Another useful differentiator are feature references: var methodRef = someInstance#someMethod() which have all sorts of interesting applications as a sort of type-safe reflection syntax. And so on.

heavenlyhash 12y ago

Oh man. Nice string interpolation. Can shell script with a shebang. All those little niceties like the `.?` operator. Map literal definitions. Type inferring declarations (like golang: strongly typed, but not wearing out your keyboard). "enhancements"... very interesting, deserve a full paragraph. And I'm just cherrypicking my favorite features; there's so many more. "enhancements" feel like monkeypatching in that they let you attach things to existing classes for pretty code. This left me sweating at first -- implementations of features like this in ruby seems to be a large part of why the language is both challenging as you add devs (I recently saw one class spanning 4 files and 3 gems, I don't even) and frankly slow, and scala has similar performance barriers brought on by 'implicits' [1] and their ilk. But in gosu, enhancements appear to be defined in an statically disbatchable way so there's zero runtime timewasting, and they're also only valid for your syntactical convenience, they don't complicated inheritance or interface fitting. Looks like all the beauty, none of the sticky mess. Very interesting. Compatibility looks like a better story than some of the alternatives -- both groovy and scala always felt to me like their mechanics encouraged an extend+extinguish feeling to their libraries because of the radical overhaul or complete dismissing of types, whereas gosu looks like you could sanely call it from java. I (as a purely personal observation; others may disagree) found I could never write a groovy or scala library and ask a java developer to use it with a straight face, and with gosu, it looks like maybe I can! I'm speaking as someone who's just seeing the language for the first time today, so perhaps my enthusiasm will be modified by practical experience later... but I'm seeing a lot to love both in the examples and in the general philosophy of pragmatism. A language that lets me do more with fewer characters while not giving up ground on compile-time checks and performance is exactly what I want to see more of. I look forward to playing with this! If any gosu developers are here, my biggest single beef right now is I can't instantly see from your docs what my process is like if I'm going to ship a jar. I assume it can be done and it's not hard to script, but it would be great to see up front, because if that isn't smooth, then my impressions of using it to ship a library usable from other java projects (or feed it into cross compilers, etc) is impacted. I found some docs at [2], but it appears to mostly talk about shell script style usage; ctrl-f for "jar" hit nothing. Perhaps I just haven't looked hard enough yet :) (Also, that help site is one of those annoying things where there's no content without javascript, and even after allowing it, middle click gives me some sad snippet of javascript instead of opening the page I wanted. The rest of your site looks great; I hope the wave of design refresh is going to wash over here soon too.) [1] https://stackoverflow.com/questions/3606591/why-does-intellij-idea-compile-scala-so-slowly/3612212#3612212 https://stackoverflow.com/questions/3606591/why-does-intelli... [2] https://gosu-lang.github.io/doc/wwhelp/wwhimpl/js/html/wwhelp.htm#href=Gosu%20Reference%20Guide/getting-started-gosu-opensource.04.3.html#1496914 https://gosu-lang.github.io/doc/wwhelp/wwhimpl/js/html/wwhel... Edited: to note that my spate of points-to-love at the top is by no means exhaustive.

neilellis 12y ago

At (insert swear word here) last! "The classpath can also include Maven coordinates, and Gosu will automatically resolve and download them at runtime: #! /path/to/gosu classpath "../src,org.gosu-lang.gosu:sparkgs:0.1.0" print( "Here is a library object: ${new SweetLibraryObject()}") " Been writing java for 14 years and I've never had a nice way to run scripts. Now if you can work natively (tougher than folk think) with JSON I'd be very happy indeed. That would include supporting fully de-typed data not nasty schema based data binding. I've switched to NodeJS/JS because they speak the language of the web (not JS, but JSON). But I can't see why other languages can't learn to.

carsongross 12y ago
:) It's the little things, isn't it? Regarding JSON support, Gosu has map literal syntax and integrates easily enough with Google's GSON library. Not great, but not terrible. More speculatively, I put together a type-loader to work with JSON content specified using JSchema: https://github.com/gosu-lang/Goson But I'm not sure it works with the current release. (This HN post caught us mid-rework...)
benjiweber 12y ago
In Java8 you can #!/bin/jjs to start a Nashorn (JavaScript) script running on the JVM. Nashorn has shell extensions that helps you write shell scripts https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extens... It's also a great way to bootstrap your Java app with some JSON config http://benjiweber.co.uk/blog/2014/05/08/json-to-java-interfaces-with-nashorn/ http://benjiweber.co.uk/blog/2014/05/08/json-to-java-interfa...
zmmmmm 12y ago
Well, Groovy has done it for a long time ... #!/usr/local/bin/groovy @Grab(group='org.springframework',module='spring',version='2.5.6') import org.springframework.jdbc.core.JdbcTemplate println "..." Actually Groovy looks really similar to Gosu and one would argue has a lot wider recognition and support. But then, I do like that Gosu feels much "cleaner" in some way that Groovy doesn't.

alexdowad 12y ago

Mildly interesting. Gosu definitely has some features that would be nice in Java, and would have been impressive 10 years ago, but here and now, it just looks like a slightly different spin on a dozen other languages I have seen before. It would be very helpful if the creators made a page (linked to right from the home page) explaining their philosophy and guiding principles, and how their design differs from other languages in the same space. Don't tell us fluffy things like "we choose simplicity over complexity". #1, that is not a trade-off. #2, "simplicity" is such a vague and overused word that it's hard to know what you mean. (What I think they mean by "choosing simplicity" is: keeping the feature set and number of syntactic constructs small.) Another point: "For the JVM" is a 2-edged sword. If I see a programming language described as "for the JVM", it would make me think twice about investing the time to learn it. The JVM is good technology and I do make use of it, but for reasons I won't detail here, I don't want to be locked in to it. "Can run on the JVM" is a different matter. "The compiler has a JVM backend, among others" is great. "Currently runs only on the JVM, other backends are coming" is OK. If Gosu was specifically designed for very tight integration with Java, such that it wouldn't make sense to separate it from the JVM, that is a design trade-off and should be explained on the "design rationale" page I suggested above.

lboasso 12y ago
Gosu is more than 10 years old. For some historical background/design decisions please have a look at this article: http://www.drdobbs.com/open-source/language-of-the-month-gosu/231001429# http://www.drdobbs.com/open-source/language-of-the-month-gos...

maelstrom2 12y ago

Another in the long line of languages that are created to solve a problem that doesn't exist. Even worse, created as a way to force P&C carriers to be tightly coupled to a proprietary piece of software. With one industry being the only relevance for the language and that industry with usually the worst IT technical talent available. I get it, Guidewire has some very talented engineers. Probably at least a few of the best in the valley. However, you're pushing it out to the dregs of the IT world and hoping to make it fly and gain adoption when those using it are generally just drawing a paycheck for the pulse their body maintains.

dventimi 12y ago
> Another in the long line of languages that are created to solve a problem that doesn't exist. I assure you that the problems Gosu was created to solve did indeed exist at the time that it was created. > Even worse, created as a way to force P&C carriers to be tightly coupled to a proprietary piece of software. I assure you this also is not true. For evidence, I encourage you to notice the fact that Gosu is not a proprietary piece of software. > With one industry being the only relevance for the language Put another way. "Number of heavily-capitalized industries where Gosu is heavily used: At least 1." Would you rather it be 0? > and that industry with usually the worst IT technical talent available. Please. There's fierce competition for that distinction.
- maelstrom2 12y ago
  I didn't say Gosu was proprietary. They've taken this whole "open-source" catchphrase and made some CIO's, that generally don't know anything other than budgets and bodies, feel better. It does, however, tie you completely to the Guidewire platform/products. A very smart move by the company. It will be decades before these slow-moving behemoths will rip out this language that was a blip on the radar. That doesn't mean it was needed or is as historically important as the devs seem to think.
  - dventimi 12y ago
    Oh, God. Trust me, the swiftness or tardiness with which insurance companies replace their Guidewire stack will have nothing whatsoever to with Gosu.

heuakr 12y ago

This language is only used by GuideWire people. And whoever talks about it positively are GuideWire employees. It was called GScript before. The creators of the language did it because they could, but then some consultant dude gave them the idea to write an insurance application on it. They wrote Guidewire claims center, plus a bunch of proprietary development tools to support the language. Do I have to say what went wrong? Anyway, eventually they found it was too hard to maintain the language and keep any traction on it, so they open sourced it and called it Gosu. I spent a lot of time with this thing. My best advice is: stay away from it.

carsongross 12y ago
That's certainly one perspective. Here's another one: Gosu is the life's work of some talented developers at a successful startup, who have tried hard to build a pragmatic successor to Java. It is not perfect, and of course you should be skeptical of any new technology, but it has some promise, and here are some interesting features of the language: * Type-safe reflection with feature literals * Embedded classpaths in programs, including maven coordinates * Integrated type-safe templates * Pragmatic extension methods on the core java data structures via enhancements * Null-safe operators * Mixin support via the delegate keyword And so on...
ternaryoperator 12y ago
If you're going to piss all over someone's work, how about providing details about what you didn't like? Supposedly rhetorical questions like "Do I have to say what went wrong?" are just character assassination. Yes, of course, you do have to say what went wrong if you're going to advise devs to stay away from it with no other information.

carsongross 12y ago

One fair comment that comes up frequently is that, with Java 8 out, Gosu's closure support is less of a win. Certainly true, so let me mention some other high-level features Gosu has that contrast favorably with Java: * Type-safe reflection with feature literals * Embedded classpaths in programs, including maven coordinates * Integrated type-safe templates * Pragmatic extension methods on the core java data structures via enhancements * Null-safe operators * Mixin support via the delegate keyword * Implicit interfaces, like Go * Type-safe templates built into the langauge * Properties support (seems small, but it makes a big difference in day to day coding.) And, of course, the Open Type System, which is essentially an API for introducing new types to the gosu compiler: http://devblog.guidewire.com/2010/11/18/gosus-secret-sauce-the-open-type-system/ http://devblog.guidewire.com/2010/11/18/gosus-secret-sauce-t... All at least interesting, if not compelling.

deleted 12y ago

[deleted]

icambron 12y ago

Very cool. I'm starting a JVM-based project, and I'd love to use this in the places where I was planning to use JRuby. Besides being impressed overall, two pieces of feedback: * On enhancements, I very much like C# extensions design, partially because I do have to import them explicitly. One of the things I dislike in Ruby is that you don't know where your methods come from, and that gets more complicated when they're actually from third-party gems. If a jar is giving me an enhancement, how does that work? How do I handle name conflicts? * I'd love to have some built-in support for shell commands, a la Ruby's tick marks.

carsongross 12y ago
On enhancements: yeah, that's reasonable, but we also wanted to be able to add some obviously missing methods to things like List, globally available. We've toyed around with a scope declaration on the enhancement, e.g. global, module, or explicit but haven't settled on anything. Back-tick has been on the list forever and wouldn't be hard to add. Open a ticket. :)
- icambron 12y ago
  Ticket submitted.

dutchrapley 12y ago

It's interesting to see that Gosu was announced here two years ago without a single comment. https://news.ycombinator.com/item?id=3671054 https://news.ycombinator.com/item?id=3671054