What Differentiates Gosu From Other Languages?Posted: February 27, 2012
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.