Live data from Hacker News

Why we choose Java instead of a polyglot stack

product.hubspot.com

151–155 of 155 posts

Re: Why we choose Java instead of a polyglot stack

#151
post #141
post #66

It did not seem to really address the issue of polyglot very much (given it is in the HN title) rather than just promoting the virtues of Java. One of the strengths of the JVM is the ecosystem of JVM languages that has evolved. You can stick with the JVM and get many of the benefits mentioned while still being polyglot. In particular you can throw in a dynamic language (Groovy, JRuby, Jython) alongside the Java core…

Groovy feels like it's dying as far as I can see - partly because you can write almost word-for-word the same code in Scala and not have to sacrifice type safety.

I think the problem is more that development has really slowed since they lost the sponsorship of the company that was funding development (which employed almost the entire dev team). It's not clear to me what the future of Groovy is. However it's about 1000x more accessible to Java developers than Scala is. Scala reinvents the whole type system and uses custom collections etc. That makes reverse interoperability (I write a class in Scala and then use it from Java) significantly more challenging than Groovy where Groovy code looks identical to native Java in most respects.

Re: Why we choose Java instead of a polyglot stack

#152
post #151
post #141

Earlier quoted context omitted.

Groovy feels like it's dying as far as I can see - partly because you can write almost word-for-word the same code in Scala and not have to sacrifice type safety.

I think the problem is more that development has really slowed since they lost the sponsorship of the company that was funding development (which employed almost the entire dev team). It's not clear to me what the future of Groovy is. However it's about 1000x more accessible to Java developers than Scala is. Scala reinvents the whole type system and uses custom collections etc. That makes reverse interoperability (I…

You can use Scala like that if you want to though - you can stick to the Java collections (even implement the scalaz typeclasses for them), or one effective technique is to write a Java interface and then have a Scala class implement it. Most Scala users do find it worth moving beyond Groovy-like code, but you don't have to.

Re: Why we choose Java instead of a polyglot stack

#153
post #151
post #141

Earlier quoted context omitted.

Groovy feels like it's dying as far as I can see - partly because you can write almost word-for-word the same code in Scala and not have to sacrifice type safety.

I think the problem is more that development has really slowed since they lost the sponsorship of the company that was funding development (which employed almost the entire dev team). It's not clear to me what the future of Groovy is. However it's about 1000x more accessible to Java developers than Scala is. Scala reinvents the whole type system and uses custom collections etc. That makes reverse interoperability (I…

> Groovy code looks identical to native Java in most respects

Maybe your definition of "most respects" doesn't include the Gradle DSL or Java 8 lambdas.

Nowadays I use Clojure for those quick'n'dirties testing Java code. A well-placed macro eliminates plenty of boiler-plate specific to the test at hand.

Re: Why we choose Java instead of a polyglot stack

#154

Earlier quoted context omitted.

Express isn't like Rails. It's more like Sinatra, but has probably even less stuff. There's no official or popular Rails for Node yet. People have made stuff like Sails but not many use it.

Keep in mind Sails has stagnated and there's a fork called TrailJS now. The NodeJS 3rd-party ecosystem is really really fragile at the moment.

For anyone who's interested, the github repo: https://github.com/trailsjs/trails

Re: Why we choose Java instead of a polyglot stack

#155

When you try to use Java you will need new, young programmers. Experienced Java programmers will most often be indoctrinated/trained/used to over-engineering and wrapping everything in layers upon layers of abstractions. And the existing Java learning books, tutorials and examples still tend to follow that mindset. The more abstracted your code is, the slower it will run, the more memory it will consume and most espe…

utter rubbish.
Post reply on HN