The Groovy project is looking for a new home • Hacker News Board

Re: The Groovy project is looking for a new home

#61

Post by Gurkenmaster » Tue, Jan 20, 2015, 12:14 PM UTC

cowardlydragon wrote: post #17

revscat wrote: post #5

Props to what Guillaume has accomplished, but the original raison d'etre for Groovy existing has largely been supplanted by the rise of JRuby and Scala. When Groovy was initially developed JRuby was (arguably) not yet mature enough for production, so developers wanting to use Rails under the JVM were basically out of luck. Grails was developed in response to this need. Now that JRuby is more mature (and, as of today,…

NOPE. Ruby doesn't offer one of Groovy's killer features: optional static typing. And Scala... far too alien and complex. There was some talk out there by one of the original Scala dudes talking about how there are something like 30 different fundamental types in Scala. Groovy offers the most accessible functional programming paradigms to Java programmers. It is a sweet spot.

I haven't tried Groovy but in my opinion Ceylon strikes a nice balance between Scala and Java.

Re: The Groovy project is looking for a new home

#62

Post by pjmlp » Tue, Jan 20, 2015, 1:06 PM UTC

Edmond wrote: post #36

Love Groovy's static+dynamic typing. I developed HiveMind (www.crudzilla.com) and the IDE backend is written entirely in Groovy primarily because I am a Java developer and could use Groovy without having to learn a new syntax.

Interesting. Specially that you decided to make use of JSR-223.

Good luck for the business.

Re: The Groovy project is looking for a new home

#63

Post by bjfish » Tue, Jan 20, 2015, 1:52 PM UTC

prophetjohn wrote: post #42

bjfish wrote: post #12

I know and use both Ruby/Rails and Groovy/Grails and wanted to debunk a myth here: "Interest in Grails/Groovy is diminishing" - I won't comment on trends but there is still a large, active user base and community I won't list the benefits of Ruby/Rails over Groovy/Grails because I will assume the audience here is familiar with Ruby/Rails. Specifically here are some benefits of Groovy over Ruby: - Very good JVM toolin…

I haven't used Groovy much, so I may be completely missing something here, but how is the elvis operator different from a simple guard in Ruby? Based on the docs for elvis, it looks like potentiallyFalsyValue ?: safeDefault is exactly equivalent to potentially_falsy_value || safe_default in Ruby Further, the null-safe operator seems to be the same as #try in Rails and overuse of either is probably a bit of a smell th…

Yes, I see || as a wart or crufty. Think about the type signature of || in ruby:

   ||(Type1 arg1, Type2 arg2)

but in how many other languages is this?

  boolean ||(arg1, arg2)

C, Java, Objective-C, C++, C#, PHP vs Ruby, Perl, Javascript

If || is used more frequently as a logical operator returning true(1) or false(0) to test logical or (not to be used for assignment), why overload this operator?

Having a separate operator like ?: better shows the intention of the usage. It also resembles the ternary function which has similar functionality.

Re: The Groovy project is looking for a new home

#64

Post by bjfish » Tue, Jan 20, 2015, 1:53 PM UTC

sytse wrote: post #46

mbell wrote: post #35

Earlier quoted context omitted.

I've also used both languages a fair bit, but I've never used Grails (although I've played with it). Couple things to add to the pros/cons: > Developer friendly (Ruby has a number of syntax warts, e.g. elvis operator, null safe operator - just to start) syntax I would love to see the elvis operator and the null safe operator in Ruby, but I'd also like to see blocks in Groovy. An addition to the pros of Groovy: Intera…

Isn't the elvis operator || in ruby? see http://stackoverflow.com/a/7816041/613240

Yes, but I think that syntax is a little ugly, see https://news.ycombinator.com/item?id=8916893

Re: The Groovy project is looking for a new home

#65

Post by vorg » Tue, Jan 20, 2015, 5:40 PM UTC

olavgg wrote: post #56

vorg wrote: post #50

Earlier quoted context omitted.

Static typing (both type-checking and compilation) was added to Groovy for version 2.0 released in June 2012.

No, that is annotations that assists the compiler. In Groovy 1.X I could still write public List mylist = new ArrayList () and it would behave exactly as you would expect.

By static typing, I meant compile-time type checking, and statically-typed compilation. You describe run-time type checking in dynamically-typed compiled code which was in Groovy (without generics) from the beginning but makes the code run even slower than the already slow dynamically-typed compiled code without such run-time type checking. Run-time type checking with generics was added to Groovy from version 1.5.

Perhaps I should've used the expressions "compile-time ..." and "run-time ..." to be more accurate, but virtually everyone uses "statically-typed" and "dynamically-typed" in their place.

Re: The Groovy project is looking for a new home

#66

Post by rufugee » Tue, Jan 20, 2015, 6:25 PM UTC

emsy wrote: post #53

rufugee wrote: post #20

Earlier quoted context omitted.

It's also extremely good in Intellij (at least, in Ultimate...which is what I'm using daily).

I tried to install the Groovy plugins on a default Eclipse installation and never got the same result I got on the bloated default GGTS installation. But even with GGTS I had a mediocre experience at best. I tried the commercial version of IntelliJ two years ago and it was okay, but still lacking compared to the Java autocompletition. I'm really happy that the situation is better now. As I use Groovy more of a host f…

Auto-completion is excellent now. I'd suggest you give it another try.

Re: The Groovy project is looking for a new home

#67

Post by tmarthal » Tue, Jan 20, 2015, 8:19 PM UTC

olavgg wrote: post #56

vorg wrote: post #50

Earlier quoted context omitted.

Static typing (both type-checking and compilation) was added to Groovy for version 2.0 released in June 2012.

No, that is annotations that assists the compiler. In Groovy 1.X I could still write public List mylist = new ArrayList () and it would behave exactly as you would expect.

The other poster is right. That is typing, that is not static type checking.

You can write code like:

List mylist = new HashSet() {{ add("string"); add(1L); }}

You will get groovy.lang.GroovyRuntimeException with constructor issues.

Re: The Groovy project is looking for a new home

#68

Post by olavgg » Tue, Jan 20, 2015, 9:05 PM UTC

vorg wrote: post #65

olavgg wrote: post #56

Earlier quoted context omitted.

No, that is annotations that assists the compiler. In Groovy 1.X I could still write public List mylist = new ArrayList () and it would behave exactly as you would expect.

By static typing, I meant compile-time type checking, and statically-typed compilation. You describe run-time type checking in dynamically-typed compiled code which was in Groovy (without generics) from the beginning but makes the code run even slower than the already slow dynamically-typed compiled code without such run-time type checking. Run-time type checking with generics was added to Groovy from version 1.5. Pe…

Correct.

Actually the Groovy developers call it optional typing, not static typing. And it has always been confusing.

Still though, if you really really need static typing at compile time, Groovy never stopped you. You have always had the possibility to call Java code from Groovy and Groovy code from Java as Groovy compiles to valid Java byte code.

Re: The Groovy project is looking for a new home

#69

Post by zmmmmm » Tue, Jan 20, 2015, 11:01 PM UTC

johnkpush wrote: post #60

mcv wrote: post #57

Earlier quoted context omitted.

Agreed. Groovy is in my opinion absolutely the nicest and friendliest language to read or write. Scala has some really cool features that I would love to see in other languages, but it also has a tendency to become somewhat unreadable and is a lot harder to get into when you're new to it.

Groovy is gaining popularity among scientists and researchers because of it's ease of use and performance.

Really? I've been using it but I feel pretty lonely. I ended up creating my own Groovy based version of R / pandas data frames because there is simply nothing out there. I'm curious in what ways you're seeing it used.

Re: The Groovy project is looking for a new home

#70

Post by vorg » Wed, Jan 21, 2015, 2:08 AM UTC

stickfigure wrote: post #59

Understanding this decision requires understanding Pivotal more broadly. EMC (which owns VMWare, which owned Spring) bought Pivotal Labs (primarily a Ruby consultancy) and used the brand for a new spinoff company (Pivotal Software, Inc). That spinoff company received as its founding endowment a hodge-podge of enterprise software technologies they had acquired over the years - Spring, RabbitMQ, CloudFoundry, Greenplum…

You'd also need to understand that not all full-time Groovy and Grails developers make equal contributions. Funding the 2 technical workers on Groovy might make sense for a business, but due to ownership problems related to the brand, codebase, support, channels, and what not, disentangling these 2 workers from the whole mess is a legal nightmare. Perhaps there's something similar with Grails, but I don't know much about that one. Pivotal obviously decided simply terminating funding was more profitable than trying to split off a separate business and sell it all to someone else.