
Why we choose Java instead of a polyglot stack - wsorenson
http://product.hubspot.com/blog/modern-java-at-hubspot
======
meddlepal
If you're not picking the JVM in 2016 to build your core services and web
applications then you're making a mistake that is going to cost you time and
money either upfront in building things that already exist or later down the
road when you start to need more performance and your RoR application isn't
cutting it anymore.

Say what you will about Java the language (I agree it's not particularly
"sexy") but the JVM is a performance beast. You can write Java or pick from
one of several other languages that range across different paradigms from
static functional to dynamic (current gen: Scala, Groovy, JRuby, Jython, next-
gen: Kotlin, Ceylon). Integration is usually painless between these languages.
It's also highly configurable and can be tuned to virtually any workload.

You get the huge benefit of a very mature and common shared infrastructure and
tooling environment. Your operations team will thank you for solidifying on a
single runtime environment.

Java is great. The whole ecosystem is really really solid in general and it's
truly a pick what you want platform at this point. The JVM is magical for web
applications and services.

~~~
seivan
Does Kotlin offer anything Rails like with batteries included? I'm steering
away from Ruby. I love Rails but ruby becomes a monster when a project gets
larger. I've looked at TypeScript and Express.js but I'm worried I gotta deal
with type definitions a lot.

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

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

~~~
sotojuan
Yeah that's what I meant. The Node ecosystem doesn't really care for Rails-
like frameworks so they stagnate. Most Ruby companies run Rails. Most Node
companies run Express, Hapi, or Koa. Not Sails.

------
champion
I work at HubSpot, and was among the initially skeptical from having had bad
experiences in Java in the distant past and spent more time in Ruby in the
years prior which I mostly enjoyed.

The Java ecosystem truly saved itself from its own enterprise madness.
Libraries and frameworks today look nothing like they did in the past. I think
that is somewhat due to language features (annotations, lambdas, etc) but also
due to a cultural shift in what is valued.

One of the things I've appreciated more than I would have expected is by
having a single back-end language we have very strong community of developers.
There is no split among different factions. (I hear rumors of sharp divides
between python and node camps at Uber, for example.) Even though technically
we have a platform capable of running languages in many languages, the value
of the community focused on a single back-end language toolchain is extremely
valuable.

~~~
preordained
Yep. I've used a variety of different languages, and it always struck me as
odd that Java was considered some uncool cumbersome language, and enterprise-y
in some sort of bad way. It's not a dream to code in, but it is highly
practical and in no way limits what you can do or makes anything particularly
hard. I see now that I joined the Java party in better days.

~~~
mercurial
I've done a lot of Java, and I'd say the stereotypes didn't come from nowhere
(XML is great! Enjoy using XML for dependency injection and configuration!).
Not to mention the lack of expressivity of the language causing the
proliferation of FactoryBeans.

The other issue is that the "IE effect": the language stopped evolving for
years. In the meantime, Microsoft launched C#, and Java is only catching up
now in terms of convenience. But even with Java 8, as far as I know, a lot of
things are still strictly worse than in many other languages (no import
aliases in 2016, no shorthand for getters/setters...). To a large extent, it's
still a language that forces you to live in a IDE even for trivial things, due
to the amount of boilerplate you need for even simple things.

Of course, compared to C#, it still benefits from a considerably larger and
IMHO higher-quality ecosystem, as well as working very well with some non-Java
open-source solutions (eg, Postgres), though it's generally poorly integrated
on all platforms it runs on.

~~~
mike_hearn
That's why I think Kotlin is going to clean up. It's a language specifically
designed to be commercially successful by providing you with a better Java.
For instance this line of code:

    
    
      data class Person(var name: String, val age: Int)
    

compiles down to a JavaBean with getName/setName type methods, a getAge but no
setAge (val is immutable), an equals, a hashCode, a toString and a few other
useful methods as well like copy() which lets you create clones of the object
with any fields modified.

So with Kotlin you get many of the benefits of C# and some features that C# is
only just introducing now, or in its next versions, but it all interops
seamlessly with Java.

~~~
lmm
I think it will fail in the same way as Xtend or (to a certain extent) perl.
It puts too much focus on one-off productivity features which results in an
inconsistent language with loads of edge cases, and it doesn't have any
compelling "you _can 't_ do this in Java" selling points, just a bunch of
minor syntax sugar.

Ceylon has all the advantages of Kotlin, but put together a lot more
coherently, and with a really compelling fundamental feature (union types).

------
brianpgordon
I agree that Java is the best programming language to write web services in
right now.

But I have to admit that the most threatening counter-argument to using Java
in 2016 is that Scala is, to all appearances, a strictly better language. It's
similar to Java and does everything Java does, but better- it has type
inference, it does away with primitive types and arrays, it has compiler-
checked string interpolation, it has declaration site variance, it has a
richer collections library, powerful syntactic sugar, robust mechanisms for
dealing with asynchronous programming... I could go on and on. And it's deeply
interoperable with Java so it should be a no-brainer to use it wherever
possible.

Java's saving grace in my opinion is, ironically given Java's history, its
culture. When you find that you need to use a small class from a library, you
pray that it's written in Java, because _most_ of the time you can just go to
its source in your IDE and see painstakingly detailed Javadoc describing
exactly what each public method does and common pitfalls. And Java isn't very
expressive so all code looks the same- you just have to understand how the
components interact with each other. If, on the other hand, the class is
written in Scala, you're vastly more likely to crash into a brick wall of
undocumented one-liners that are complicated greatly by uses of the downright
tricky bits of Scala's type system. Using typesafe's libraries (akka/akka-
stream/slick) is an exercise in poking your code experimentally until it
magically compiles, usually due to some random undocumented import. And scala
culture's love of DSLs and lifted types is downright hostile to ease of
debugging. It's hard to overstate how much of an impact these factors make
throughout a workweek.

And yes, lots of Scala code is good and lots of Java code is bad. But I think
the stereotype generally holds true.

~~~
edem
On the contrary Scala is baroque, its syntax is not following any known
pattern. For example if I want to write a recursive function I have to
indicate my return parameter type otherwise not. It doesn't matter whether you
come from a C background or a Java background...or any background because of
this:

> def addInt( a:Int, b:Int ) : Int = {

> var sum:Int = 0

> sum = a + b

> return sum

> }

You have to relearn how a function looks like in the first place. Return types
are at the end, parameter types are after the parameter name separated by a
colon.

If you want a language which runs on the JVM Clojure is a way better option.
You don't have to learn its syntax since there is hardly anything you can call
one. It is binary compatible with itself which is not true with Scala, you can
choose whether you want a type system or not since it is optional (look at
clojure/core.typed). It is also interoperable with java but it has a much
better functional approach to programming compared to Scala since everything
is immutable but it is not wasteful because of persistent data structures and
for concurrency you have the STM which IMHO is a strict upgrade to the Actor
model. Writing DSLs with the powerful macros Clojure has is more usable than
any non-lisp language and the result is more expressive.

So to add it all up with Scala you add a lot of complexity and a lot of
pitfalls you can fall into while with Clojure you take away complexity while
retaining the vast Java ecosystem for interoperability. Don't take my word for
it but take a look at Uncle Bob's talk "Clojure is the new C" :
[http://www.infoq.com/presentations/clojure-c](http://www.infoq.com/presentations/clojure-c)

~~~
scott_s
Function declaration syntax where the return type is last is very common in
functional languages. It's even allowed in C++11, because it allows one to
define return types that depend on parameter types. An example taken from
[http://en.cppreference.com/w/cpp/language/auto](http://en.cppreference.com/w/cpp/language/auto),

    
    
      template<class T, class U>
      auto add(T t, U u) -> decltype(t + u) // return type is type of operator+(T, U)
      {
        return t + u;
      }
    

It's quite a sensible approach, and hardly an impediment to understanding. A
more valid concern is that Scala introduces a lot more _concepts_. I don't
necessarily agree with it, but I think it's a potential issue, whereas a
simple syntax difference that a lot of languages have is not a big deal.

~~~
autoreleasepool
I agree the syntax is sensible. I quite like it in Swift:

    
    
        protocol Numeric {
            func +(lhs: Self, rhs: Self) -> Self
        }
    
        func<T: Numeric>(a: T, b: T) -> T {
            return a + b
        }

~~~
autoreleasepool
_Correction:_ Function name.

    
    
        func add<T: Numeric>(a: T, b: T) -> T {
            return a + b
        }

------
zeveb
Has anything happened in Java to correct the fundamental issues raised in
Steve Yegge's 2006 opus Execution in the Kingdom of Nouns[1]?

I last used Java two years ago, writing an Android app, and at the time I
think Yegge's critique still stood. Not to mention the fact that it was a
colossal amount of typing and boilerplate in order to do _anything_.

We're using Go at the current place, and I'm loving it. Android development in
Go would be a sheer joy.

[1] [http://steve-yegge.blogspot.com/2006/03/execution-in-
kingdom...](http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-
nouns.html)

------
mschuster91
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 especially the more difficult it will be to get a new
developer up to speed.

~~~
jcrites
This sounds like unjustified FUD. It's not been my experience. A large amount
of infrastructure at companies like Google, Amazon, Facebook, Ebay, etc. is
written in Java and the code I've seen from those companies is well-
engineered. Google Guava stands out as an example of extremely strong style.
Apache Hive and Avro (from Facebook) are also clear and not overly complex.

I believe you that there are ineffective programmers of any language who over
engineer, but I haven't seen that from personal experience with Java
programmers. To the extent that it's a problem, it sounds like a hiring
problem rather than a Java problem.

~~~
skybrian
Guava is _much_ better than average Java, even written at Google by
experienced engineers. There are few who have the luxury of polishing to the
extent they do.

------
nemik
I also advocate for Java, but mostly because I invested in companies that
manufacture RAM.

~~~
exabrial
the 90s called and they want their comment back

~~~
Bjartr
Tell that to the 4.5GB of RAM my Eclipse instance is sucking down at the
moment.

~~~
paulddraper
Try Atom.

~~~
Bjartr
I prefer VIM, but I still need Eclipse to do my job effectively due to
circumstance.

Like Eclipse only plugins whose functionality I would have to take time I
can't justify to duplicate. Plus the additional maintenance cost of the dev
team no longer having a homogeneous environment. All to allow me to be able
to... do what I already do.

Don't get me wrong, I'd really enjoy taking a week to explore the options and
put together a better development environment for myself and my team. I do
make improvements where I can already. But we're already an effective team
despite Eclipse's flaws, the RoI just isn't there from a business perspective.

------
davidw
So, Java guys, what do you recommend if someone wants to have a Rails-like
experience where programmer time is more valuable than 'web scale'
performance? Say, also that I don't want to have to pay oodles of money for
some server with a terabyte of memory to hold the application. Honest question
- I haven't kept up with what's happening in Java land, and am curious what
you'd recommend for that kind of side-project thing.

~~~
edem
There is [Grails]([https://grails.org/](https://grails.org/)) which I honestly
did not use so I can't comment on it but people seem to like it. It is Groovy
based though. The most common framework nowadays is Spring and its ilk
(including Spring MVC and its friends). BUT there is Spring Boot which is
basically a meta framework which takes an opinionated "sensible defaults for
all the stuff" approach and you can get a project working with 5 clicks
basically. Try out the [Spring Boot
initializr]([https://start.spring.io/](https://start.spring.io/)). The biggest
problem with these frameworks is the magic. While you are fine with the
defaults it works. You can check the config files and tinker with them but
there are a lot of layers to peel away if you are presented with some exotic
Exception which will happen sooner or later. I'm also interested in what other
options I have in Javaland currently because I'm steering away from it to
Clojure islands and even the Node archipelago...

~~~
ccoggins
I'll put a second vote for Spring Boot. You're right that when the magic fails
it can get a little complicated. However, I've found Spring documentation to
be very good. Also, once you understand a little of how it's put together it
becomes pretty easy to selectively replace whatever piece of the magic with
your own custom version.

~~~
edem
I know but I'm not sure I want to do it every time the magic breaks. In
clojure for example I only have to dig into compojure and ring 4-5 layers deep
involving 20 files. With spring with all the reflection, indirection
(annotation processing) and such it is common to have a call stack 30-40
levels deep. Much more time consuming to debug imho.

------
throwaway437812
Much of this makes sense, but the main thing that keeps me from using Java is
the dark cloud hanging over it, called Oracle.

~~~
Freak_NL
Could you elaborate on that? With OpenJDK at least the software side of things
is pretty much stable and open (in a FOSS sense), so I take you are referring
to possible legal ramifications of Oracle's actions?

~~~
throwaway437812
I never really managed to figure out the OpenJDK story apart from that it is
what gets included in Linux distros and it sort of works. Read not too great
stories about its performance in the past, am not exactly sure about its
compatibility (it seems to lag behind a bit), Windows support is a whole
complicated story of its own... Call me ignorant, but at first glance it
doesn't look attractive. On top of all that, indeed Oracle being involved with
development at all, together with their reputation of being a legal hothead.

Not mentioned in my initial post, but I also like to keep my code portable
between server and client. Firstly, there's no way I'm going to require
clients to have Java installed. Secondly, a truly native GUI is practically
impossible, so I would already corner myself into needing a second language
anyway.

~~~
mike_hearn
OpenJDK performance has been closing the gap with the Oracle JRE over time.
One big gap was different graphics renderers but this is being fixed in Java 9
(possibly earlier).

Java 8+ has a "javapackager" tool that makes native installers/packages for
each platform which contain a bundled JRE. So your users no longer need one
installed themselves. And finally SWT lets you use native widgets if you want
them.

------
zmmmmm
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 and get the benefits of a dynamic
language for parts of the code where that is suitable, without losing many of
the other benefits. Groovy, in particular, is 100% bidirectionally compatible
with Java and has close enough syntax that a developer team well versed in
Java will pick it up quickly. Perhaps Kotlin qualifies in this regard as well.
To me the optimal setup is a strong Java core defining the APIs and core
services, while the less core code can benefit from using more expressive
dynamic languages. For example, the drudgery of writing unit tests is hugely
alleviated by doing in something like Groovy rather than straight Java.

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

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

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

------
vbezhenar
Java platform and libraries are very mature and good. Java as a language is
not. I suggest to take a look at Kotlin. It uses JVM, it uses Java standard
library, but it provides much better language, while keeping simplicity and
it's close enough to Java to be a drop-in replacement. And IDE support is
excellent, if we are talking about Intellij Idea. Kotlin is really Java++. No
reason to choose Java over it.

Another option is Scala, but Kotlin is superior for most projects IMO.

~~~
Consultant32452
I have two good reasons not to choose Kotlin. The first is until I started
reading this thread on HN I had never heard of Kotlin. The second is I
attempted to find kotlin in a job listing on Monster.com in several major
cities and managed to only find one single listing in Los Angeles. The job
listing says they are transitioning to Java. My argument of course is from the
greater view of the business and not a laser focus on Kotlin as a technical
decision, but for _most_ projects you should choose a much safer option with
insane amounts of support and developers on the market by the boat loads.

------
Mikeb85
I will say, Java performance always impresses me. Trying a few benchmarks
relating to economics, OpenJDK 1.8 somehow beats C++ and Fortran on my machine
(!!!). And of course, there's plenty of nice, high performance JVM languages
(Kotlin, Scala, Clojure), and you can tune the JVM a number of ways.

I can certainly imagine a future where Java is the top performing language for
any application.

------
jkot
My choice is Kotlin. Java8 is a bit strange, and does not have many features:
type inference, named and default arguments... Scala is too heavy and
sometimes complex.

Kotlin is best of both worlds, highly expressive, good compatibility and
pretty simple.

------
michaelvkpdx
The dream of the 90's is alive and not just here in Portland!

I'm still writing Java to make money to buy music. Just like the 90's.

------
vfc1
Maybe for the backend, but for the frontend Java has messed up really bad.
Some of the worst aberrations ever created in the history of software
development are Java frontend frameworks: think JSF to start.

There is nothing like Javascript for the frontend, and if its for developing
micro-services and not monoliths I think Javascript is also a pretty good
choice for the backend as well. There are some good solid libraries like
express, sequelize, passport.js that be used to build solid micro-service
backends, in every way comparable in functionality and performance to Java.

~~~
edwinnathaniel
> I think Javascript is also a pretty good choice for the backend as well.

Definitely not for me and for a few of my buddies who happened to use NodeJS
already. NodeJS is a good "glue" appserver for gateway to other microservices
I give kudos that far but not more.

------
stevehiehn
Its nice to see articles like this. JAVA seems to be the butt of many jokes on
Hacker News. It seriously makes me worry that i'm a bad developer or something
because i actually like JAVA + Spring.

------
melted
To me it's not so much Java that's the problem, it's the kind of programmer it
seems to foster. The language itself is simple enough, so people invent all
kinds of architectural bullshit and overengineer everything to hell to appear
smart. As a result you get code that replaces compile time errors with run-
time errors, and it's fucking impossible to debug or understand because
everything needs three dozen libraries and five hundred classes before you can
even start doing anything worthwhile.

This is not Java's fault, per se. You can write simple, performant, sane code
in it. It's just that 95% of people choose not to.

I have a feeling that this is part of the reason why Go is gaining popularity
(even though I dislike Go as well, for different reasons): much of this
garbage (such as DI frameworks, AOP/runtime bytecode modification out the
wazoo) are either impossible or deliberately inconvenient there, and writing
overly complicated code is socially unacceptable.

------
ajainy
It's interesting to see shift towards. Always remind of 2005, when everyone
was blogging about RoR.. Then 2010, everyone was blogging about scala.
Personally, I could never find any good reason to move away from JAVA. Yes,
learning multiple languages might give you better perspective on software
development but when we talk about some serious enterprise software
development (it's not only language but cost of development too), JAVA is good
enough.

-=-= Another thing I am realizing, over the period, specially shift in architecture style because spring (aka IOC pattern), it has made programmers better. We can't blame everything on EJBs etc any more. Early JAVA programmers were treating java as magic bean instead of putting good effort on learning & writing programs right away.

Oracle should thank Apache & Spring.. in my opinion.

------
mobiuscog
Developers use the right tool for the job.

Java / JVM is the right tool for some jobs, and not the right tool for many
others.

It's definitely not an essential for core services and web applications, but
is a valid option.

------
DigitalJack
I'm a Clojure fan, but I always have this niggling concern in the back of my
mind that Oracle is going to do something catastrophic and fracturing to the
JVM and Java.

------
x3n0ph3n3
Another language fight full of hyperbolic claims. Fun.

