
Groovy – An Open Source Success Story - Lunatic666
https://www.sitepoint.com/groovy-open-source-success-story/
======
SOLAR_FIELDS
I have had the opportunity to work with Groovy quite a bit and I will share a
few of my thoughts on things that work well with the language and things that
are a bit questionable.

Works well:

Extensible type checking. Groovy can do quite a bit of things with type
checking and you can turn it into "pretty much Java" if you need to and even
take it a step further and enforce even stricter typing than Java with
relative ease

Closures. The Groovy built in closures are quite extensive and allow you to
build some really beautifully expressive pieces of code that would be 5 to 10
times longer in Java. The implementation lends itself well to a functional
approach.

Questionable:

Not defining a variable with a type or the def keyword creates a variable in
the global scope, just like JavaScript. This creates problems, as you can
imagine. One of the more infamous bugs we ran into was when someone had named
a variable "id" in the global scope of a script and the identifier of its
parent, the script runner, was modified. Brought the whole runner down.

Groovy doesn't respect privacy. You can literally declare something as private
variable in a Java or Groovy class and Groovy will happily access it with no
qualms. The only thing that private helps you for is preventing the variable
from showing up in a decent IDE's autocomplete alongside your getters and
setters

~~~
vorg
> code that would be 5 to 10 times longer in Java

I wonder if that's Java 8 with its lambdas? Most sites just use Apache Groovy
for the scripty dynamically-typed stuff only (e.g. testing, build config,
grails MOP) and leave the statically-typed stuff for Java or some other JVM
language. Of course, those variables in global scope will still be a problem.

~~~
SOLAR_FIELDS
I was speaking specifically to Java 7 but can offer the Java 8 perspective as
well. Java 8 with lambdas makes it better - but you still have to bake your
own on top of the system in a lot of cases. The real joy of Groovy is having
the powerful manipulation functions just there for you without any external
library.

A good analogy would be anonymous functions in Vanilla JS being like Java 8
lambdas vs the expressive power the baked in goodness Lodash offers being like
what Groovy closures supplement to the JVM environment. You don't always need
it, but the general purpose tooling makes your life a lot easier in certain
specific cases.

With that being said in our use case Groovy was very pointed - serving a
specific, directed purpose in a monitored environment. When developers were
left to their own devices to design general scripting and tooling that they
were comfortable with, nearly everyone chose Python and to a lesser extent
Ruby.

I think Groovy is great to create some JVM specific glue and support for an
enterprise system - but as a general purpose language it still has a long way
to go. As an example, try and make a tool in Groovy for interacting with a
REST API and compare your effort for doing so to Python - One of these is
significantly less painful than the other.

------
geooooooooobox
it probably has the open source success as the only thing going for it,
probably the ugliest non-intuitive language I've ever come across

