"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-intelli...
[2] 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.
I think what you'll find if you use Gosu, today, is that it has a lot of interesting features and is fun to play around with, but that you will run into trouble when you start trying to use it for larger projects. This is mainly because:
* It doesn't integrate cleanly with Maven in a mixed language project. It can be done, but it requires some hacks.
* There isn't a huge community around it outside of Guidewire, the classic bootstrapping problem.
* The IDE support is in IntelliJ only and can be a bit of a bear to set up initially.
We do have a (very alpha) web microframework that you can use to play around with the language:
http://sparkgs.github.io/
Edit: Just tried it, doesn't seem to work yet. Hope this is coming down the pipeline soon.
[1] https://github.com/sparkgs/sparkgs/blob/master/pom.xml [2] http://sparkgs.github.io/
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/
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-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.
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...
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.
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.
You would never choose Gosu unless you were working with Guidewire products.
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()
And so on.
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() )
"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)
* 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-t...
All at least interesting, if not compelling.
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.
"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.
Nashorn has shell extensions that helps you write shell scripts 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-interfa...
#!/usr/local/bin/groovy
@Grab(group='org.springframework',module='spring',version='2.5.6')
import org.springframework.jdbc.core.JdbcTemplate
println "..."
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
* 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.
Back-tick has been on the list forever and wouldn't be hard to add. Open a ticket. :)
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.
As an enterprise software company Guidewire needed a statically typed scripting language directly compatible with the JVM, one a Java programmer could easily pick up, and one that could blend powerful features like type inference, closures, enhancements, properties, open types, structural and dynamic types, built-in templating, etc. Guidewire also wanted to directly and seamlessly use the power and flexibility of the scripting language directly in application source code. Why distinguish between a scripting language and a general purpose language? Why force your customers to juggle two separate languages? 12 years later it's still difficult to argue against Gosu. Sure, Java 8 is catching up in some core feature areas, and that's great news for JVM languages, but Java as a language is still not appropriate or even usable as an embedded scripting language, nor is it suitable for many of the other use-cases a very large scale web application requires.
Can Java 8 dynamically compile and load classes from source at runtime? Yeah, that's important too :)
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.
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.
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.
While I'm glad Gosu keeps chugging along, I can't see myself choosing it over Kotlin.
var strings = { "red", "green", "blue" }
uses. In some clean way. eg I don't want List, I want ArrayList.
var strings = new ArrayList<String>() { "red", "green", "blue" }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.
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...
join( ", " )
print( aFile.read() )Whether it's uglier... I guess I haven't written enough Scala to know, but my Scala is pretty ugly :(.
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....