What Differentiates Gosu From Other Languages?

A recent question posed on our forum at gosu-lang:

What is that differentiates Gosu from other ‘similar’ languages and that makes Gosu unique?

I couldn’t agree more regarding the importance of differentiating the language.  In fact there isn’t much point in producing a new language if it can’t set itself apart in a significant way.  And I mean measurable significance in terms of us day-job programmers who are looking to get stuff done faster, better, and cheaper for our customers.

Many of the newer JVM languages offer only grammatical improvements over Java.  Sure, Java is a dated language still without properties, closures, composition, extensions, etc., but we can still build the same systems using Java with only marginally more effort than with most of the other newer languages.  And I mean total effort including the impact of the language on design, testing, refactoring, and general ease of understanding, not just the insignificant effort in the number of characters you have to type.  In fact most of the newer languages, I’ll argue, make our lives harder in ways that trump whatever modern features they offer.  For instance, newer dynamic languages leave us in the dark ages of pre-IDE wisdom — no parser feedback to speak of, no deterministic code completion, limited navigation, almost no discoverability, no trustworthy refactoring, etc.  Not to mention no basic static analysis and type checking from the compiler.  Not that bad if you’re writing something smallish in a text editor.  Otherwise, over time I’ll wager a net loss in productivity for most development teams heavily invested in a dynamic language, not that they’ll ever know it. I can make this claim from experience here at Guidewire.  Our success in developing a huge stack of technology, including Gosu, can lend itself in part to state-of-the-art tooling.  Further I’ll say rather confidently that we would have likely failed as a company without it.

What’s striking is what lures a budding development team away from Java isn’t the dynamic languages per se, but the systems atop the languages.  For instance, Rails is the primary reason for the spike in Ruby usage.  Before this phenomenon dynamic languages were pretty much left for dead or a sideshow at best.  Like functional languages they had several opportunities to overtake the imperative OOP ones, but have always failed to gain lasting traction as general purpose languages. My observation is that most red-blooded programmers prefer imperative OOP because it makes sense to them.  That’s really all there is to it, it just makes plain sense to human beings because that’s how we naturally model the world around us.  But Java has given us such a horrible experience with building web applications that we are looking outside the marriage so to speak.  It’s that bad.  I blame the hodgepodge of half-baked tools that are the result of EJB and the JCP fiasco — the same bureaucracy that has delayed basic language features like properties, closures, etc.  The point I’m making is that it’s not the dynamic languages so much that are drawing folks from Java as it is the systems built around these languages.  They, at least in the fledgling stage of a project, provide real, measurable productivity gains, which is what matters.  As you’ll see this is the point I’m working toward with Gosu.

Before we move on to Gosu, though, I’d also like to share my disappointment with some statically typed JVM languages.  Of the few newer ones none significantly helps us programmers advance the ball.  Take Scala.  It’s probably the most popular new kid on the block, yet it’s feature-set and type system are so overwhelmingly complicated most salary paying companies rightly keep it out of their code bases.  Don’t get me wrong, in many ways I like and respect Scala; It’s designer understands the advantage of static typing and it has quite a bit in common with Gosu, but its roots are functional and its feature-set is academically driven (read, hard for us nut crackin, hard workin OO programmers to understand so we can get stuff done and keep it done).  A web search exposes more than enough rants on Scala’s complexity, basically the same reasons functional programming on the whole remains a niche – a lot of simple ideas combined in ways to form overwhelming complexity.

If complexity isn’t enough to deter you, Scala’s flexibility should.  Most language grammars leave wiggle room for expression resulting in mini-dialects, but successful languages thus far tend not to vary too much in dialect.  Java’s success, for instance, is due in part to this characteristic — if you’re an experienced Java programmer, you won’t have much trouble reading and understanding Java, no matter where you go.  Not so with Scala.  If you’re a Java programmer experimenting with Scala, you’ll tend to write Java-like OO code in it.  If you’re a “clever” programmer, guess what?  You can pretty much write Haskell in Scala… Type classes? Monads? Implicit parameters? No problem.  The point is that Scala, beyond its horrifyingly complicated set of features, or perhaps because of them, is also a Tower of Babel.  Again I’m more concerned with the 99-percenter OO programmers who’re paid to impress customers than with the 1-percenter programmers who’d rather impress their peers.  So if you can somehow hire yourself a steady stream of green-blooded Haskell hackers, maybe Scala is for you, but probably Haskell is more for you.

Still think maybe Scala could be in your future?  Witness Kotlin.  Scala is so danged complicated the wizards at JetBrains invented a new language to take its place, namely Kotlin.  I was there when its authors introduced the language at the JVM Language Summit last year where they proclaimed it a Scala-lite of sorts because they basically began with Scala and removed a lot of stuff until they were satisfied (I’m paraphrasing, but that’s the gist).  On the whole Kotlin feels like a reasonable language, but like most Java alternatives, it doesn’t really offer much beyond some grammatical improvements, some of which are difficult to argue as improvements, like multiple inheritance and operator overloading.  Have we not learned from our errors with C++?  Language designers should be made to fix at least one good hard bug in an ancient C++ MFC application before they form an opinion on multiple inheritance, operator overloading, or macros.  I’ve seen some things, man.  In any case it’s hard to argue Kotlin isn’t a net improvement over Scala.  But as I’ll explain, it doesn’t matter.

The intention here is to talk about Gosu and what it has to offer not only in terms of what sets it apart from other languages, but also, and more importantly, why Gosu can help normal development teams become significantly more productive.  As I pointed out earlier the other new languages provide only marginal gains via typical grammatical changes.  I know that’s rather bold of me to say, but consider any of the Java challengers.  None of them offer anything more than an improved Java and/or functional programming to a degree.  There really isn’t much there that warrants a massive shift from Java – a closure here and there reduces some typing and may (or may not) improve readability, properties in the architecture can help relieve some pain, class extensions are a breath of fresh air, but really these are just improvements on Java’s base OO design.  And Java’s going to have most of that stuff sooner or later; Java 8 is just around the corner.  Please don’t misunderstand.  I loathe Java’s slow progress.  No properties?  Really guys?  Wait for Java 8 for closures?  Ugh!  Defender methods?  Sigh.  So for now there’s a niche market for JVM languages to offer features at a faster pace and Gosu does not hold back in that department.  We think we have a nice balance of features, so if it’s closures or properties or enhancements or delegates or what have you, Gosu will not disappoint.  But that’s not important. The features are there because Gosu should have them, but they are not the raison d’être.  Why the language then?  We are so explosively enthusiastic about Gosu because of one giant, game changing idea: Gosu’s Open Type System.

I’ve written extensively on the subject as have others at Guidewire.  To my surprise it has been challenging to convey the idea.  So far it’s a technology you have to experience for yourself to realize its benefits.  Evangelizing it is akin to demonstrating the qualities of Blu-ray on DVD, but harder.  It demos so naturally that most people miss what just happened, even after we say, “Look! We just had an intelligent conversation with a toad!”  In programming we tend to concentrate on the conversation and not the participants (the types), because who cares, they’re just types and of course they can talk.  It’s difficult to get across that the types involved in our demonstrations are really just raw data with which you normally can’t communicate, let alone have the compiler tell you whether or not your conversation makes sense.

The idea itself is simple: programmatic expansion of the type system.  The general idea isn’t new, some call it meta-programming.  But meta-programming as it exists is reserved for dynamic languages where there’s little benefit for development since it exists only at runtime; the dynamic language parser can’t help me discover anything about the new type or the fact that the type even exists.  The unique and enormous achievement with Gosu is that we’ve unified two otherwise discrete concepts –data and static types.  Programmers can now work directly with raw data as first-class types and do it statically leveraging all the productivity features offered by modern, high quality IDEs.  But there’s a key piece of information missing in that last marketing slogan of a sentence – the batteries are not included.  Worse, we have to manufacture the batteries in the form of IDE plugins.

Deep down I’ve always felt the key to Gosu’s success as an open source language was to have a strong presence in one or more IDEs. After all that is where static languages really shine; tooling rules.  Our first foray into the IDE world took us through the gauntlet and ultimate dead-end for languages other than Java, namely Eclipse.  I won’t get into the details other than the JDT was designed exclusively for one thing, the Java language.  To those other static language providers who dare to build a truly useful and competitive plugin in Eclipse, I bid you well; make the best of your orgy with the JDT classes and AspectJ weaving.

IntelliJ IDEA is our IDE of choice here at Guidewire and has been for ten years.  As an experienced user of both IDEs I feel confident in my view that IntelliJ is notches above Eclipse in every way: features, quality, and architecture.  We didn’t integrate Gosu with IntelliJ at first for a couple of reasons: it wasn’t free and it wasn’t the market leader.  Well I suppose the main reason was that I had started the initial development of the Eclipse plugin to get the ball rolling in advance of our open sourcing Gosu; it seemed like the right direction at the time.  Live and learn.  As a company up until nearly a year ago we were still kidding ourselves that we could build our tooling around Eclipse.  Then after talking with our IDE team about the full-retard scenario they were facing with weaving etc. I became convinced we had to punch out, and quick.  As it happened shortly before that time I was also exploring IntelliJ’s plugin architecture as an alternative.  I had developed a simple Gosu plugin to provide debugging and basic highlighting for our internal devs.  It was a smallish project, but I learned enough to know that JetBrains designed a truly open architecture for custom language plugins.  Fast forward six months… without getting into details I began exploring a proof of concept project on fully integrating Gosu into the world of IntelliJ.  It wasn’t long before I was convinced that not only should I continue down this path, but also that Guidewire should redirect its Eclipse effort toward IntelliJ.  This was the IDE for Gosu and, therefore, at least to my caveman brain, for Guidewire.  It wasn’t an easily won battle, but it was well worth the fight.

Now Gosu is well on its way to achieving professional quality tooling in IntelliJ, which I have to say given JetBrains’ high bar is quite an achievement.  So thanks to our hard working IDE team we’ve finally released our first preview of the plugin.  As the “preview” qualifier suggests it ain’t perfect, but it’s at a stage now where you can be productive with it, which is a huge milestone for us.  Because until now Gosu’s powerful type system was not demonstrable to the outside world.  Now that it is I’m optimistic about Gosu’s future in the wide world of open source.  But as I pointed out earlier regarding Ruby’s success with Rails, Gosu’s success also depends on contributing systems such as web frameworks, OR layers, and the like.  But unlike Ruby on Rails, due to Gosu’s static typing and full IDE support it has quite a bit more potential to scale both in terms of performance and project size.  And to make matters worse for the other new languages (let’s not pretend we don’t keep score in this game), Gosu has an unfair advantage with its open type system.  And some smart people have been busy bees building impressive frameworks and systems leveraging every ounce of it.  This is where the rubber really meets the road.

Now with Ronin, the web framework for Gosu created by Gus Prevas, and Tosa, the SQL-focused OR layer for Gosu authored by Alan Keefer and Carson Gross, programmers can be extremely productive building hardcore web applications in Gosu with IntelliJ.  Where else can you build web applications where the links are statically verified?  Where else can you directly reference your SQL DDL and access queries with static types using code completion, all with no code generation? What other static language lets you modify types corresponding with your web content, even the structure of the types, and immediately see the results in the browser?  (I’m going to keep going with this.)  Can your JVM language directly expose arbitrary XML schemas where elements are types and attributes are properties with no code generation?  Unless you have Dana Lank’s XSD/XML framework and your language is Gosu, it can’t.  And even if it could, it couldn’t dream of having an IDE like IntelliJ refactor the name of an XML element and automatically rename all references to it in your code.

This is the kind of differentiation I’m talking about.  Sure, base language features like closures and properties enhance the experience for programmers on many levels, but they don’t increase overall productivity anywhere near the scale of the open type system.  With it Gosu offers something entirely new to programming; another dimension if you will.  The open type system breathes life into the otherwise dead world of raw data.  This is the world we struggle with as programmers.  This is where we waste precious time and resources reading and deciphering and parsing and mapping and reinventing, and we do this over and over. The cracks and crevices between data and our world of objects is where the bad bugs lie. With Gosu suddenly data has the potential to be directly accessible as typed objects, be it XML, WSDL, properties, SQL, data markets, business rules, or you name it.  As the list of data domains supported by Gosu’s type system grows, so does the potential for new and interesting applications to leverage them.  But most importantly, the potential for real productivity gains is available to everyone right now with Gosu, Ronin, Tosa and XML on IntelliJ.  I invite you to take a test drive and let us know what you think on our forum.  We’re always more than happy to help with questions and are excxited to respond to any feedback you might have.

11 Comments on “What Differentiates Gosu From Other Languages?”

  1. Jesse Wilson says:

    First off, I’ve become a bit enamored with Gosu since the company I work for invested in Guidewire’s suite of applications. While I’m not in love with a lot about those applications, Gosu as a language choice has made things a lot nicer to deal with.

    With that said, I’m more interested in using Gosu elsewhere, specifically for a lot of the one-off standalone applications/utilities that I write make my life easier. Are there any reference materials or the like for doing this out there?

    • Scott McKinney says:

      Hi Jesse. Thanks for the nice comments! I’m not sure what you’re looking to do specifically, but I a great place to start is gosu-lang.org and then head on over to http://lazygosu.org/ for excellent docs. As for creating distrubutions for simple utilities and applications you can do that directly in the IntelliJ plugin via the Build menu’s Create Executable Jar… command. We’ll answer any questions on our forum: http://groups.google.com/group/gosu-lang

  2. David Vydra says:

    Scott, I’ve been doing Groovy for he last 2 months and boy do I miss a static language! However, for my particular task I was able to find lots of examples on the web. The moral of this is that the community and the publicly searchable artifacts of the community are a huge part of the success of the language on a real world project.

    What can we do to help grow the Gosu community?

    Are there plans to open-source Gosu compiler and IntelliJ plugin? My worry is that unless the alpha-geeks can get their hands on the core code, it will be difficult to achieve escape velocity?

    Will classes be written to the file system? Will you generate Java-compatible wrappers so I can incrementally rewrite a legacy system with Gosu? Support for standalone web apps is nice, but it is a small part of the overall development market.

    Regarding the open-type system, I agree that it is a fantastic idea, but I have been using generative programming with Java for years and it was not that difficult, so I am not sure its such a huge differentiator. A full-featured IntelliJ plugin for a modern language is much more exciting to me.


    • Scott McKinney says:

      Hi David… long time!

      Yes, we have plans to open source the whole shebang. As you know the core Gosu API is available in the release. The core internals will follow soon, nothing much left to do, but maybe scrub some of the more offensive potty mouth language, or maybe we’ll leave it in.

      Funny you ask… One of my next projects is in fact to persist class files. There are several ways to skin the cat. Serializing the bytecode is the easy part. The challenge is what to do about parse trees and our type information, because those parts of the system are not serializable and never will be. Usually parsing comes first, then compiling to bytecode, but in the class file case I think we’ll just modify the class loader a bit so that we don’t bother parsing at all if the class file is there and then parse lazily, which normally won’t happen since we only need our parse trees for Gosu-specific reflection and odd cases where the parse tree is needed. In any case I think class files are in Gosu’s near future.

      Code gen is for suckers 😉 Seriously, it’s our experience that code gen whether for Xml or entities or whatever impacts the dev process on so many levels, but few see it as a problem because they haven’t experienced anything better. Ugh. This is what I’m talking about when I say how difficult it is to get the message across. I feel a screencast coming on with lots of demos… or maybe I can trick Carson into doing it…

      I appreciate your thoughtful comments! Let us know what else we can do and where you might like to contribute.

    • James says:

      Your Groovy 2.0 has the ability to compile with statically type.

  3. Former Java Programmer says:

    You are deluded with NIH.

    Scala is very easy for *almost* any Java programmer to get started with, and grows with you. A Java programmer can become productive after just a couple hours, and even if it is imperative OO style code only, they are on their way to greater and greater levels of productivity as they incrementally grow in knowledge.


    Extremely Satisfied Scala Programmer Who Really Impresses Customers With It

    • Scott McKinney says:


      Well, maybe you misunderstood my assessment of Scala. I agree with everything you’ve just said. I also agree the same can be said for Haskell programmers; swap the words “Haskell” and “Functional” for “Java” and “imperative OO”. That’s the problem; Scala’s sophistication is, I think anyway, a curse. Maybe another way to look at it: An accomplished Java programmer probably won’t be productive with an existing Scala code base, which is different from being productive starting from the Java perspective as you point out. That’s really the key. Think about starting a software company. You want to scale in terms of hiring and replacing talented programmers as your company grows and adapts. It’s difficult enough to hire good Java people. Scala people virtually don’t exist, so hiring Java people with their heads screwed on extra tight for Scala is going to be significantly harder, which is why Scala people virtually don’t exist.

      In any case, what I attempted to convey in the post is that none of this matters. Scala, even if used carefully as a primarily imperative OO language with modern features, say Java++, it would still not effect overall productivity significantly more than if the project were based on plain old Java. It just wouldn’t matter that much in any measurable dimension: time, cost, quality, etc. This is the case, I argue, for all of the other new JVM languages.

      At Guidewire we make use of Gosu’s base language features every day, they’re a breath of fresh air, but they aren’t selling more products or shortening our development time in any significant way. As developers we probably spend 10x more time just studying broken tests than all the time saved by using closures or properties or enhancements or whatever, which is good. On the contrary, Gosu’s open type system has saved us oodles of time if we could somehow measure the savings inherent in directly binding our entity model, web components, etc. to our language as first-class types. Gosu unifies dozens of configuration points in our very large scale applications and testing framework. One language, one type system, zillions of domains, all consistently represented and dynamically modifiable. The amount of overhead that we would otherwise assume as a company by not having this capability is staggering, albeit difficult to gauge with any precision. We can, however, gauge the success of our company, which is quite a thing and a lot of it can be attributed to the configurability and agility of our applications.

      So don’t get me wrong. Make Scala your language; I don’t like Java either. Just don’t expect it to make any real difference in the type of application you can develop or to somehow get your products to market faster or to give you some advantage over your competitors. But if you’re looking for an edge, I think Gosu might have something to offer.

      • erik says:

        It seems like you’re laying it on a bit thick:

        “So don’t get me wrong. Make Scala your language; I don’t like Java either. Just don’t expect it to make any real difference in the type of application you can develop or to somehow get your products to market faster or to give you some advantage over your competitors.”

        Your original point seemed to be that you thought Scala was too hard, or out of control or something. But now you’re saying that no matter what you are certain that it won’t make any difference or help anyone get products to market faster. That is pretty hyperbolic and I don’t see any evidence to support the claim.

        I get the argument you made that it might be hard to hire good Scala/Haskell people (even if I don’t necessarily agree) but that seems to imply that if you *could* hire those people you *would* see a difference. Now you’re saying that the difference doesn’t exist at all?

        Relatedly, your remark “Of the few newer ones none significantly helps us programmers advance the ball” really undermines your article, or at least your credibility. Lots of people claim to have found exactly this in Clojure, Scala, JRuby, etc. I can’t tell whether you deny the existence of these people or think they are lying or hallucinating.

        Finally, you say “It [imperative style Scala] just wouldn’t matter that much in any measurable dimension: time, cost, quality, etc. [when compared to Java]. This is the case, I argue, for all of the other new JVM languages.” More hyperbole, again without a serious argument.

        Making a case for Gosu shouldn’t require arguing that no other JVM language provides any tangible benefit. And if Gosu’s success does depends on that argument then I am not optimistic about its future.

  4. Muthu Lalapet says:

    Are you guys planning to have an eclipse based plugins for GOSU and Claim Center development anywhere in the near future?

  5. Mark says:

    Scott, I like and agree with a lot of what you said. We (I?) have only used Groovy for scripting for the reasons you stated. I cannot see building a large scale application with it. Not at this point. The same thing is true for JavaScript. While I have used it for minor browser client side things (and for minor things in BIRT – for major things I use Java Data Script classes), I dread creating a whole client out of it. I keep looking for a tool that allows me to create mobile apps but without resorting to JavaScript or Native (Something like Eclipse RAP Mobile)

    While, have created many ground apps from the ground up, I have had the joy of maintaining other peoples code too. That gives me a totally different perspective on “productivity”. People don’t seem to understand that “dynamic” languages are nothing new. They existed on the mainframe (QuickJob anyone?). They also seem to forget that code maintenance is the largest part of what we do. And they forget that test code is code (which languages like Groovy require more of). Anyway, things like QuickJob were mean for short term and/or small things. Long term, they were not [very] maintainable.

    So, while I am very interested in Gosu, 2 things concern me.

    1. This is not that big of deal but – There is only an IntelliJ plugin. The good news is that it works with the community edition. Too bad you couldn’t get the Eclipse Plugin working. So for those who do a lot of Eclipse development (i.e. RCP) that will be limiting. And of course there are those who don’t get to choose their tool and thus can only use Eclipse.

    2. Gosu is case-insensitive (if this is not the case – awesome). I’ve used VB (and variants) for years. It is case-insensitive. It causes weird name clashes and also forces you to use bad naming conventions (i.e. oCustomer or cust). This is one reason we have “outlawed” VB.NET.

    So why did you all choose to make Gosu case-insensitive? How does this affect intermingling it with Java?

  6. ftsan says:

    I’m found Gosu interesting, but I have a question that I hope to be useful.
    Grails use Groovy, and it was the main reason I’ve found to study Groovy, and well, I liked it. I read just little about Gosu, and I’ve been thinking what would I answer if a manager asks me: “Why Gosu and not Groovy?”

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s