Why Gosu?

The most common question we’ve gotten following the release of Gosu as a programming language is pretty simple: Why? Why did you create your own language? Why not use an existing language like Scala, Groovy, Javascript, Clojure, Ruby, Python, C#, or basically anything else at all? Why does the world need yet-another programming language, especially one that doesn’t seem to have any ground-breaking features? Why should anyone care?

There are kind of two sides to the answer. The first is the Guidewire-specific, historical part of the story: we needed a language with particular characteristics to use for configuring our applications (statically typed, dynamically compilable, some metaprogramming capabilities, fairly simple syntax and easy learning-curve for people familiar with Java or other similar imperative languages), and at the time that we started working on Gosu (back in 2002) there wasn’t really anything close to what we needed. We ended up creating it almost accidentally out of necessity.

But of course, that reasoning applies only to us, at Guidewire, and why we need something that we couldn’t find off-the-shelf. Why should you, if you’re someone outside Guidewire, care about Gosu?

As we worked on Gosu, we started to realize that we could actually turn it into a language that we, the language authors, liked, and that there’s currently a vacuum in the programming language landscape for the sort of thing that we were creating: a fairly “simple” (I realize that’s a massively loaded term, but bear with me) language that’s statically typed, dynamically compilable, with some metaprogramming capabilities, syntactic sugar in the most needed places, and with language features like closures, type inference, and enhancements that address some of the most glaring deficiencies and pain points in Java. We want to build something that, at least eventually, is unequivocally better than Java: a language that retains all the strengths of Java but has strictly fewer weaknesses.

Why target Java as the baseline? Because Java is, these days, essentially the lowest common denominator language for a lot of people, especially within the business community. It’s also the first language a lot of people learn in school these days. I have plenty of issues with Java myself, but it does a lot of things right as well, in my opinion: it’s statically typed, that static typing enables a huge array of tools for working with the Java language (i.e. excellent IDEs with refactoring support and error highlight as-you go), it can perform basically as fast as C or C++ for long-enough-running processes, it has garbage collection and a reasonable object-passing model (as compared to, say, worrying about pass-by-reference versus pass-by-value semantics) and a reasonable scoping model, the syntax is familiar enough to most other imperative languages that it’s not too much of a shock to transition from C or C++ or similar, and the lack of “powerful” language features also means that most people’s Java code looks pretty similar, so once you learn to read Java and understand the idioms you’re rarely thrown for a loop (with the glaring exception of generics).

Basically, Java manages to be a lowest common denominator language at this point that, while it’s lack of language features is really annoying, largely manages to avoid any absolute deal-breakers like poor performance, a lack of tools, or an inability to find (or train) people to program in it.

Now, that’s all speculation/opinion on my part as to why Java is where it is currently. You, the reader, are free to disagree with it. If you do agree in large part with that, though, it becomes clear what the imperative is for the next lowest-common-denominator language: it can’t screw up any of the things that Java got right, but it needs to improve on all the places where Java is weak.

So what are the deal-breakers to be avoided? The first is dynamic typing, in my opinion. Saying that is essentially flame-bait, I know, so I’m not trying to say that static typing is strictly better than dynamic typing, but merely that static typing enables certain things that people actually like about Java. Static typing enables all kinds of static verification, of course, which a lot of people find useful, especially on larger projects. When moving people between projects and forcing them to get up to speed on a new code base, for example, static typing can help make it obvious if you’re using a library even remotely correctly, or if your changes are going to clearly break someone else’s code. More important at this point, I think, is that static analysis enables amazing tooling: automatic error-detection as you type, auto-completion that actually lets you usefully understand and explore the code you’re working with (instead of, say, suggesting all functions anywhere with that name), automated refactoring, the ability to quickly navigate through the code base (for example by quickly going to the right definition of the “getName()” function you’re looking at, rather than one of the other 50 functions with that name somewhere in your code base).

Static typing also tends to be an important factor in execution speed, though dynamic languages are catching up there; you might argue that execution speed doesn’t matter anymore, but I’d argue that there’s always the possibility that it might matter in the future even if it doesn’t matter now, so at least in the business world people doing core systems work are often scared away by anything that they think has a performance disadvantage that might, at some point in the future, require them to purchase a bunch more hardware. You might disagree and attribute it to a failure of imagination on my part, but I find it hard to imagine the next LCD language being dynamically typed.

The second deal-breaker is what I’ll call “unfamiliarity.” There are lots and lots of people out there who know Java, or C, or C++, or C#, or even VisualBasic, and they’re so used to the standard imperative language syntax of those languages that something too foreign to that simply isn’t going to fly. It doesn’t matter how good the language is, or how expressive it is, something that doesn’t fit roughly into that mold simply won’t become the next LCD language, at least not any time soon.

The last deal-breaker is what I’ll call “complexity,” another obvious flame-bait term. Everyone’s got a different definition of the term, but here I’m equating it to roughly two related things: first of all, how hard is to fully learn and understand all features of a language, and secondly, for any two programmers A and B how different is their code likely to look/how easy is it for them to write code that the other one doesn’t understand. Again, I’m not trying to start a flame war, and opinions seems to very greatly on the relative complexity of languages, so hopefully we can all at least agree that if a language includes monads, a concept which historically many people have struggled to understand, that ups the complexity bar a fair bit, while a language like Ruby that doesn’t have them is probably a bit “simpler.” Likewise, languages like C and C++ with explicit pointers and memory management are more complex than languages that abstract out those details. Languages like Python where there’s one standard way to do things are also less “complex” by this metric than languages like Perl, where there are multiple ways to do everything, not so much because the individual features of Perl are complex but simply because it’s generally easier for Python Programmer A to read Python Programmer B’s code than it is for Perl Programmer A to read Perl Programmer B’s code. (Again, that doesn’t mean you can’t write readable, awesome code in Perl, I’m just talking about the presumed statistical average difference between two people’s coding styles.)

So to sum that all up: my theory (and I think I speak for the other Gosu designers as well) is that the next LCD language will be statically typed, imperative with a familiar syntax, and will avoid shall we say, “more advanced” language features.

So what can we add to Java to make it better? Well to start with we can add simple type inference with simple rules to make the language less verbose and make static typing impose less of a tax on your code. We can add in simple closures to make data structure manipulation or basic FP coding possible. We can add in enhancement methods so that people can improve APIs that they have to use without resorting to un-discoverable, ugly static util classes. We can add in first-class properties to avoid all the ugly get/set calls. We can add in syntactic sugar around things like creating lists and maps. We can add in dynamic compilation and first-class programs so that the language can scale down to be suitable for scripting. We can simplify the Java generics model and undo the travesty of wildcards. We can kill off the more-or-less failed concept of checked exceptions. And we can add in some metaprogramming capabilities, ideally in a way that’s relatively transparent to the clients of said capabilities so it doesn’t bump up the complexity factor too much.

If we do that, what we’re left with is a language that’s pretty good for most things, without too many (in my opinion, of course) glaring weaknesses: something fast, that allows for good tools, that scales down to small projects or up to big ones, that has enough expressiveness that you only have to write a little code to solve a little problem, that’s easy for programmers familiar with the existing LCD language to pick up, and that has enough metaprogramming capabilities to let you build good frameworks (because good frameworks, in my opinion, require metaprogramming . . . but that’s a different argument).

So that brings us full-circle back to our original question. Why Gosu instead of some existing language? Well, Java has all the flaws everyone knows and is annoyed about. C# is still controlled by Microsoft and isn’t truly cross-platform. C++ is too complex and easy to screw up, which is why so many people moved to Java. Python, Ruby, and Javascript are all dynamically typed and don’t really have good tools around them. (Frameworks and libraries? Definitely. IDEs that let you navigate and refactor? Not so much). Clojure is dynamically typed, lacks good tools, and any kind of Lisp is a bridge way too far for the LCD crowd. At this point any new language that’s not on the JVM or the CLR will have a massive uphill battle in terms of trying to get library adoption. Scala is statically typed and solves a lot of the problems with Java, but it’s also in my opinion a pretty “complex” language that many Java programmers would have a hard time fully understanding or leveraging. Groovy is perhaps the closest thing to what Gosu is, but it’s dynamically typed (with optional type annotations).

So merely in that sense, we think that Gosu fills a vacuum for a statically-typed JVM language that has a familiar syntax, doesn’t add too much complexity to Java, and which improves on Java in the most critical ways.

The last topic, which I haven’t really touched on at all, is around the metaprogramming allowed by Gosu’s type system. That’s worth another blog post simply in itself; the short version is that since the type system in Gosu is pluggable, that types can be generated or modified “on the fly” (i.e. really up front at parse time) to let you do things like take a WSDL and turn it into usable types that can be invoked just like any normal Gosu or Java class, but without having to do code generation. It’s the sort of thing that dynamic languages are incredibly good at but which, in a statically-typed language, has historically required reams of ugly code generation. There are other neat framework tricks you can do given that more runtime type information is available in Gosu than in Java or most other statically-typed languages. That’s what we really think will emerge, over time, as the killer feature of Gosu. For now, though, that’s less apparent, because it will only become a killer feature if people leverage it to create frameworks that other people want to use; it’s not the sort of thing you yourself will want to use every day, it’s something that you want other people to use when building the libraries and frameworks that you use every day.

So there you have it. That’s my (overly-verbose, as usual) explanation for why we think Gosu has a place in a world that already has so many existing language options; you most certainly don’t have to agree with my reasoning or my arguments, but hopefully it’s at least now clear what they are and what we’re trying to do. We’re not trying to push the language envelope in new directions, or to come out with language features no one’s ever thought of before; we’re trying to pick from the best ideas already out there, wrap them up in a pragmatic language that we’ve tried to keep simple and easy to pick up, and create something that will be appealing and useful to the very large number of programmers in this world who just want something relatively familiar that makes their programs easier to write and maintain without having to give up too many of the things that they’re already used to and have come to rely on.


26 Comments on “Why Gosu?”

  1. Stephen Coleboune says:

    I’m pretty sure you’ll have seen it, but Fantom is another language targetting a similar space. In terms of basic concept of what to add and what to leave out they are pretty similar. The key difference is that Gosu is focussing on keeping the same Java libraries but with a better syntax from what I see, whereas Fantom is as much interested in better libraries. Personally, I prefer that Fantom stuck with “String str” as I hate “str : String”, particularly on method results.

    http://fantom.org

    • Alan Keefer says:

      Yeah, Fantom is a fairly nice language from what I’ve seen, though I haven’t really had a chance to play around with it; their design sensibilities seem to be pretty similar to ours. Since Fantom is cross-platform, they by necessity kind of need to create their own libraries so that people can write code in Fantom that’s portable between VMs. That’s both a blessing and a curse of languages trying to target multiple VMs: you get a more native feeling set of libraries and you have a choice of VMs (useful these days, with the way Oracle seems to be intent on handling the JVM), but if you as an author actually want to take advantage of the portability you can’t really use the existing Java/C# libraries, which is a huge reason to choose an existing VM. So for better or worse we’ve chosen to just target the JVM and leverage the existing Java stuff while trying to make it better.

      As to the syntax around pre-fix or post-fix type notation, I originally liked the Java style better, but after years of using Gosu I’ve come to prefer post-fix notation for method declarations. Especially when combined with generics, it reads more naturally (no confusion about where the generic type variable declarations go relative to the method return type declaration, which gets confusing when you have public T foo(T arg) in Java), and it lets you leave off “: void” for methods that have no return value, which I also find more aesthetically pleasing. void isn’t a type, it’s the absence of a type, so the less I have to read it in code the better.

  2. Carson Gross says:

    To make the case for the “name : Type” pattern, consider Java:

    <T> T someGenericFunction() { … }

    String x = this.<String>someGenericFunction()

    Where, in Gosu you have:

    function someGenericFunction<T>() : T { … }

    var x = someGenericFunction<String>()

    It’s more symmetric with the way that type parameterization works, you don’t have the ‘ <T> T’ hieroglyphics at the start, and you don’t have to prefix the call with a ‘this.’ to make the syntax understandable.

    I also think that it ends up reading better:

    “Function foo takes an argument bar which is a String and returns a List”

    vs.

    “This returns a List, it is called ‘foo’ and it takes a String named bar.”

    It took me a bit to flip over to preferring it, but now I vastly prefer it, even though I spend most of my time coding in Java.

    Edit: wp swallowed my <T>’s, corrected

  3. JP Camara says:

    For many people, I think it’s natural to feel skeptical until there is something pretty compelling to lure them in. It would help if Gosu had that “killer app” that people recognized and were drawn to. Technically Gosu has a killer app – the guidewire products – but unless you’re an insurance company it’s a pretty high barrier to entry :D.

    For most of the (popular) JVM languages, they have a draw. JRuby inherited Rails. Groovy has Grails, a vibrant community, and plenty of integration with existing products / frameworks. Scala/Clojure arguably do not have killer apps, but their concurrency support makes them stick out and once people are there they sometimes stay around.

    Doesn’t help either that even though it’s pretty syntactically stable (I think?), Gosu is currently labeled a 0.7 release. Seems like the 0.7 relates more to releasing it than to the language itself, but 0.7 for most languages means lots of changes – and potentially breaking changes (LCD lovers tend to hate that). Doesn’t mean major languages/platforms don’t do it – .NET throws curveballs at its developers all the time, and Scala just released 2.8 with breaking changes – but you certainly expect it from a language at a release of less than 1.

    I think this article helps, and has definitely increased my interest in Gosu, so i’m interested to give it a try outside of work (we use some of the Guidewire products). I’m especially interested in the typeloading, though the documentation is pretty sparse right now – hint hint :)

  4. Kevin says:

    This comment (made by someone else) http://developers.slashdot.org/comments.pl?sid=1859796&cid=34171164 explains my biggest complaint about Gosu. Otherwise, in my experience, it is a rather pleasurable language to work with.

    On a side note, you should allow apostrophes in your email addresses on this blog.

    • Carson Gross says:

      It’s a tradeoff. Covariance is typically what you want, and it is simple to understand an use.

      There wasn’t a holocaust of ClassCastExceptions when we didn’t have generics, nor is there a huge problem with ArrayStoreExceptions. We’d rather people spend their limited mental energy elsewhere.

      In practice, this problem appears to not be a major concern. It certainly annoys the theory guys, though.

      Cheers,
      Carson

  5. Patrick says:

    I still think that GOSU needs good tooling and an IDE that scales. This is a deal breaker for many folks in adopting any new tech. What’s the roadmap for porting all the parts of GW Studio into eclipse and opening up the tooling part of the language?

    • Alan Keefer says:

      There are lots of internal Guidewire-specific tools that relate to our application platform, and we’re not planning to open source much (if any) of it. As to Gosu needing good tooling and an IDE that scales, have you taken a look at the Eclipse plugin we included in the open source release and found it lacking, or have you not had a chance to try it out yet?

      • Patrick says:

        I can’t get to the eclipse plug-in due to firewall issues where I work and it’s not available as a download. From my experience, Guidewire studio does not scale… the UI thread is continually blocked by “something” the editor is doing in the background… it’s painful.

  6. Pat Niemeyer says:

    No credit given to beanshell?

    • Doug says:

      I don’t know about the main Gosu authors, but I had never heard of beanshell before you mentioned it. I don’t know what if any influence beanshell would have been likely to have on Gosu.

      • Alan Keefer says:

        We were/are aware of BeanShell. I personally don’t really consider it a first-class language, though: it piggy-backs on Java syntax and adds some things on top of that, but for the most part it’s a way to write simple scripts that execute existing Java code and not necessarily something you’d want to use to write a whole lot of code. I haven’t dug into the internals, so I can’t say how amenable they are to tooling. We actually used JavaBean-related classes (like BeanInfo, PropertyInfo, etc.) for the type system for early versions of GScript, which required custom BeanInfo classes for anything that didn’t have backing Java types (things that we use pluggable type loaders for now). Since BeanShell is essentially dynamically typed at parse time, though, I’m not sure how it could be used to do the sorts of static verification we do.

  7. Pat Niemeyer says:

    The beanshell jars are in some pretty recent GW distros… Isn’t that what early versions of ‘Gosu’ were based on?

    • Alan Keefer says:

      No, Gosu was never based on beanshell: GScript as it was then called relied on a hand-coded recursive descent parser from day one, though it did use the Java introspector and other JavaBean classes for method and property description/invocation. My recollection is a little hazy, but I believe that beanshell itself was used by some other third-party libraries we were using and that’s why it was included in the past.

  8. Peter says:

    @Patrick, I’ll look into zipping up the Eclipse plugin and posting a link to that, but if your IT dept doesn’t let you download the jar files, will they really let you download a zip file?

    You could download the jar files from home and throw them on a key drive, or do they stop you from plugging in key drives on your development desktop too?

  9. Patrick says:

    It’s an issue with NTML proxy and eclipse… general internet access work’s fine via a browser. I could get them from home, but I’m not that motivated to see this plug-in to be honest. From what I can see, it’s only a replacement for the gs editing part of GW studio (ie. PCF parsing is not part of the eclipse plug-in?). If we have an existing project set-up in GW studio – would it be possible to simply load this up in the Eclipse with GOSU plugin and do development (along with break points and step debugging)? Thanks for answering my questions btw!

  10. Taras says:

    Yeah studio is a shocker, although there are ways to make it more or less tolerable…

    Alan, with regards to Eclipse plugin, does it mater which version of Guidewire products we use it with? Does the language differ much between say CC5 and CC6 or PC4? And does the open source version of the language differ much from what is bundled with products (as far as the plugin is concerned)?

    • Carson Gross says:

      Taras,

      Yes, there are major differences between Gosu in those releases. The Eclipse plugin, right now, only handles Gosu resources. It doesn’t understand things like PCF files yet. As you can imagine, the porting effort from Studio to Eclipse is massive, and it’s just going to take time.

      Cheers,
      Carson

  11. Christian says:

    What do you think is “too complex” about Scala? I hear it again and again, but Scala is simply more powerful than most other languages, what implies that you have to learn workarounds in those languages. And workarounds can become really ugly. But if you use Scala only on a level like Java you would have at least a more concise language.

    If you don’t like Scala, why did you not consider http://fantom.org/ ?

    • Alan Keefer says:

      I personally find Scala complex on two dimensions. First of all, the type system is a pretty complex beast: there’s a lot going on there that you might potentially need to understand, and for people that already have a hard time really understanding Java’s wildcarding and variance model around generic types, Scala is even more involved and nuanced. Secondly, Scala just has a lot of language features in the same way that C++ does. Even if you don’t use them yourself, you have to understand them so you can read other people’s code. So even if you hate operator overloading, you still have to understand what the various operators used in each library mean. (Check out the terrifying list at http://jim-mcbeath.blogspot.com/2008/12/scala-operator-cheat-sheet.html. Do you really need to have an operator for the foldRight operation? Will anyone remember that it’s :\ or will you constantly have to look that up if you see it?). You have to understand pattern matching. You have to understand implicit function arguments (yikes).

      As to fantom, it looks like a perfectly nice language. It doesn’t look as well-integrated with the JVM, since it’s intended to be cross-platform, which has pluses and minuses, and the tooling seems like it’s not really there yet. It also doesn’t have the sort of pluggable type system that we use in Gosu to develop our application frameworks, and I’m not sure how amenable it would be to that sort of metaprogramming. There’s also simply a timing issue: Gosu was started in 2002, and as near as I can tell Fan (as it was originally called) was created around 2007.

  12. opensas says:

    I also think that any new JVM language needs a “killer app” to let everybody sees its virtues… where would ruby nowdays be without rails? perhaps you should take something like http://www.playframework.org and use it to showCase the language…

    • Alan Keefer says:

      That’s definitely something we’re working on. Our “killer app” is currently our the application platform we use to build Guidewire’s apps, which we’re not going to open source, so we need something else to demonstrate the power. Our first step was really to get the language itself out there, so in the future we’ll be looking at what sort of projects we can do (or at least encourage) that will serve as that sort of killer app and that will really demonstrate the power of the language.

  13. rdeman says:

    Any feedback on the status of this GOSU “killer app” ?
    Thank you in advance

    • Alan Keefer says:

      We’re definitely not there yet; I’m also not sure any of us really know what it looks like. Currently, we’re working hard on making the IDE support for Gosu much better (the Eclipse plugin that’s out there right now is for an older version of Gosu, and isn’t all that great), which is kind of a pre-requisite to any sort of real usability. In our time outside of work, some of us are also working on web/ORM frameworks (Ronin and Tosa, see http://ronin-web.org/) to make it easy to write simple webapps using Gosu, and we’ve also got a build system (Aardvark) that uses Gosu as the scripting layer and that we’ll hopefully build solid support for into the IDE tooling. There’s also a lot of room for improvement in the language itself, in terms of performance, Java integration, and general polishing. So while I think Ronin/Tosa/Aardvark all have promise, the main thing for us to focus on right now is to get the basics, and especially the tooling, as solid as we can.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 39 other followers