Live data from Hacker News

Gosu – A pragmatic language for the JVM

gosu-lang.github.io

61–70 of 79 posts

Re: Gosu – A pragmatic language for the JVM

#61

Earlier quoted context omitted.

For the record, the only performance problem that Scala implicits give is just extra compile time, but there's no runtime overhead of using it. (as compared to explicitly call the function)

It depends on what you mean by implicits. If you are talking about implicit parameters then yes you are right. If on the other hand you are talking about implicit conversions, depending on their implementation they can impact performance by generating garbage etc.

I think that's a problem with the conversion itself, not the implicits. How can an implicit generate garbage that could be avoided by explicitly calling the conversion?

Re: Gosu – A pragmatic language for the JVM

#62
post #61

Earlier quoted context omitted.

It depends on what you mean by implicits. If you are talking about implicit parameters then yes you are right. If on the other hand you are talking about implicit conversions, depending on their implementation they can impact performance by generating garbage etc.

I think that's a problem with the conversion itself, not the implicits. How can an implicit generate garbage that could be avoided by explicitly calling the conversion?

No, you are right. But I've encountered people that did not understand this. Implicit classes make it when less obvious especially as they were introduced at the same time as value classes.

Re: Gosu – A pragmatic language for the JVM

#63

Earlier quoted context omitted.

> 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 pr…

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 mea…

Oh, God. Trust me, the swiftness or tardiness with which insurance companies replace their Guidewire stack will have nothing whatsoever to with Gosu.

Re: Gosu – A pragmatic language for the JVM

#64

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…

Why so bitter? Gosu's a decent language that makes up (and continues to make up) for Java's deficiencies. Yet Gosu's syntax is very close to Java's, keeping the learning curve comparatively low. Basically, if you're proficient in Java, you'll have no trouble moving over to Gosu and, in contrast with say Scala, you'll also have no trouble reading other people's Gosu. But unlike Java, Gosu is designed to be both an embedded scripting language and a general purpose programming language.

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 :)

Re: Gosu – A pragmatic language for the JVM

#65
post #18

Earlier quoted context omitted.

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.

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.

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.

Re: Gosu – A pragmatic language for the JVM

#66
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.

Re: Gosu – A pragmatic language for the JVM

#67
post #66

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…

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

Re: Gosu – A pragmatic language for the JVM

#68
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-t...

All at least interesting, if not compelling.

Re: Gosu – A pragmatic language for the JVM

#69
post #66

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…

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.

Re: Gosu – A pragmatic language for the JVM

#70
post #2

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 t…

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…

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

Post reply on HN