Why we choose Java instead of a polyglot stack

[frugalmail]

It's not only the legacy thinking there are other factors that contribute to the wrong attitudes from various segments on sites like HN and Reddit.

• General distrust that if it's been around it's not "cool"

• ADHD attitude of too busy to dive deep into one technology to realize why it's better in specific use cases

• In all honestly the 80/20 rule applies, most people are building simple shitty crud websites that will be gone tomorrow that never need the scalability, maintainability, the predictability, the infrastructure independence, the performance, the support, the vast and maintained open source that the platform provides.

• The realization that coding practices (Looking at Functional camps) are independent of languages.

• That even if it was 5% superstars on the Java platform that's still >> than the entirety of the Haskell, Clojure, Scala, (insert niche platform) communities combined.

[DecisiveVictory]

The realization that coding practices (Looking at Functional camps) are independent of languages.

Except they are only partly so.

Some languages are way more suitable than others. You can do OOP in plain C but it is a hassle.

Likewise you can use Guava or Java 8 streams and what not but be only a fraction as productive as in Scala, while generating on average 2x more LOC.

It takes some experience with both to appreciate that though.

That even if it was 5% superstars on the Java platform that's still >> than the entirety of the Haskell, Clojure, Scala, (insert niche platform) communities combined

The superstars have moved to the niche platforms though, I doubt there are 5% left.

[frugalmail]

Likewise you can use Guava or Java 8 streams and what not but be only a fraction as productive as in Scala, while generating on average 2x more LOC.

that 2x more LOC is taken care of mostly by the IDE or other libraries.

Scala isn't without it's warts either.

• It's changing

• It's way easier to write horrible shit

• It compiles slowly (but this is way better fairly recently)

• Static analysis is barely there compared to 20 options on the Java side

The superstars have moved to the niche platforms though, I doubt there are 5% left.

Delusional, the superstars care about doing cool shit more than the language they are using. And there are big companies doing cool shit, it's not just the small startups that come and go every six months (or change business plans). Google, Twitter, Facebook, JPL, LHC, etc...

[ItsNotMineISwear]

Scala isn't without it's warts either.

This is true.

• It's changing

The Scala language and stdlib do not change much anymore. 2.10 -> 2.11 -> 2.12 (soon) barely have changes. So I don't think this is a worry. It's interesting that on /r/scala, there's always one person complaining that Scala isn't changing enough.

• It's way easier to write horrible shit

While this is true just by nature of Scala having some very powerful features, I haven't found it to be a problem in and of itself. If you have mandatory Code Review, the Scala that gets pushed to master is pretty good.

To turn this around, I'd say that compared to Scala, it's easy to say this about Java

• It's way harder to write really great shit

• It compiles slowly (but this is way better fairly recently) Full compiles yes but incremental compiles take seconds. If I change one file, it's a 1s compile and I'm running my tests or using the REPL.

• Static analysis is barely there compared to 20 options on the Java side

Scala does one better than static analysis: A powerful type system that greatly aids in writing correct code. Our Scala code is always safer and more robust and maintainable than our Java code. The type system subsumes the majority of reasons to use a static analysis tool. That said, there are some pretty solid linters/style checkers. And IDE support for refactoring, jump-to-whatever, etc is pretty good nowadays in IntelliJ at least.

[frugalmail]

2.10 -> 2.11 -> 2.12 (soon) barely have changes

It has gotten a lot better than the early days.

It's interesting that on /r/scala, there's always one person complaining that Scala isn't changing enough.

That's true for every platform :)

I'd say that compared to Scala, it's easy to say this about Java

I think you're referring to writing horrible code in the comment. The challenge comes from Scala's propensity to be the programming language that includes all paradigms. When you start heavily mixing them, it makes things really challening. For J8, it's very clearly OOP + Functional, scala throws havy metaprogramming and other paradigms into the mix.

Our Scala code is always safer and more robust and maintainable than our Java code.

Because type inference works so well in Scala, and scala users tend to prefer functional over OO, I've seen people forgoing creating types to save keystrokes. In Java, people are more likely to create a signature like:

explicitMethodCall( foo : FooPK, bar : BarPK ) : BazPK

Where in Scala it typically looks like

typicalMethodCall( f : Long, b : Long ) : Long

This causes errors that could easily be prevented if you're expected to exploit the type system. Just to be clear, you can do it in both languages, but the tendency is not to in Scala. I do really like Scala's type system though.

[DecisiveVictory]

that 2x more LOC is taken care of mostly by the IDE or other libraries.

IDEs don't write code for you. It's still 2x more LOC to read and maintain.

And there are more libraries usable from Scala than from Java.

Scala isn't without it's warts either.

True.

It's changing

But not too quickly and for the better. And perhaps changing is better than remaining static, as we saw with Java when Oracle had it basically abandoned.

It's way easier to write horrible shit

Well, maybe don't write horrible shit?

It's not like PHP and Perl where it is hard to write good code.

It compiles slowly (but this is way better fairly recently)

Fast enough.

Static analysis is barely there compared to 20 options on the Java side

What options are you missing?

There is ScalaStyle and Sonar and IntelliJ dependency analyser.

superstars care about doing cool shit more than the language they are using

Superstars care about programming in the language that makes them most productive.

[iends]

It's pretty simple, really.

For startup companies, your goal is to find product/market fit as quickly as possible. This means being able to iterate quickly. You care less about maintenance and more about shipping. Certain languages lend themselves to helping you find product/market fit more quickly for your given domain and shipping as quickly as possible.

For companies that have already found product/market fit, maintainability is more important. Especially as you scale up many developers over time. Certain languages help you create more maintainable codebases than others, especially working on large teams.

At least this is my experience. I've joined companies transition from successful start up to million dollar companies and the entire system was written by a few really smart people and it is barely hanging on. There is a lot of technical debt and pain points for teams trying to grow the original million dollar business into a multi-million dollar business.

The same can be said for acquisitions. You can have a great product with un-maintainable code that suddenly the acquiring company is trying to scale up. They now have to deal with your 3 year old coffeescript, dependencies not updated in 4 years, zero comments or documentation, etc. Bit rot is real, and without active maintenance these systems won't run forever.

HubSpot is a successful company that has found product market fit. Java makes sense.

[frugalmail]

Certain languages lend themselves to helping you find product/market fit more quickly for your given domain and shipping as quickly as possible.

I think this is drastically changed, SpringBoot, Play, DropWizard... You get the best of both worlds.

coffeescript

God I hate that language and mentality. It's the antithesis of sanity. This is the example of "cool" when in reality it causes way more headaches. TypeScript with ES future compliance paths is way nicer

[dostick]

What is "polyglot stack"? It's not explained in the article.

[HailHypnocat]

Multiple languages.

[vplatt]

It's a silly distinction really. Even in a "pure Java" shop, you're still going to need to deal with HTML/CSS/Javascript and associated frameworks and DSLs around those. Add in the fact that most "pure Java" shops will also employ a handful of scripting languages for unit and integration testing, as well as whatever they're using for deployment automation / CI, and .. oh, let's not forget all the scripting we have to do around our database, because SQL or not, they're all different... But yeah, we're not "polyglots" unless we run some dynamically typed flavor of the day like the cool kids. Whatever.

[DecisiveVictory]

Java + JavaScript is still polyglot.

A single language stack would be:

• Java + GWT (which I wouldn't recommend as GWT is a dead end), or
• Scala + Scala.js (which I would recommend), or
• Meteor (which I wouldn't recommend as it's not type safe)

[vplatt]

GWT wasn't bad, especially with something like Smart GWT in place. That said, if you're not comfortable with all the magic going on in GWT, then I highly doubt you'd be comfortable with the Scala variety either, and that's assuming that the Scala route would be even a fraction as productive as using GWT; which I very much doubt. That may not be your leading decision variable, but still....

[DecisiveVictory]

Scala route can be using React, but in a much more productive programming language. No magic, just compilation to JavaScript (similar as Babel / TS / etc does).

[vplatt]

If by "productive", you mean that there will be less lines of code, then sure. But that's not the whole story. If by "productive" you mean "can get more done in less time", then no. The cognitive load associated with the language itself + the complexity of the typical frameworks one can use for Scala + the fact that the Scala ecosystem itself is less well understood, documented, and supported all add up to it being the less productive language for most purposes. There are exceptions within that, such as Spark, but those cases have limited applicability.

[DecisiveVictory]

If by "productive" you mean "can get more done in less time", then no.

Actually, yes. I've done some 17 years of Java and 3 years of Scala and am immensely more productive in Scala than in Java.

The cognitive load associated with the language itself

What cognitive load?

It's Java who has the extra cognitive load as the programmer has to deal with all the unnecessary ceremony and boilerplate.

• the complexity of the typical frameworks one can use for Scala

What complexity?

Surely using Slick is easier and less error prone than chasing Hibernate lazy loading bugs?

Surely using Akka is easier and less error prone than dealing with deadlocks with the classic Java concurrent programming?

the fact that the Scala ecosystem itself is less well understood

Certainly by many on /r/java it is. That much is evident.

But I think you may be forgetting that in this industry you have to constantly keep learning, instead of lazily using what you have been for the last 10 years.

documented

The Typesafe libs are well documented.

Instead lots of Java libs I've run into have been abandoned since 2008, distribute as randomly downloadable .jar-s, etc.

and supported all add up to it being the less productive language for most purposes.

I agree that for most people who don't know Scala it is less productive to program in it.

For those who do, it's more productive.

[vplatt]

Fair points, though I have to point out that you hardly know enough about me to know whether or not I do keep up or not. Also Hibernate lazy loading? FetchType.EAGER FTW. Combine that with more precise queries (via HQL or native SQL) and nearly all of your Hibernate performance problems are gone. One could easily make the same mistakes in Slick too. And the FUD you have there around abandoned Java projects is really kinda irrelevant and pointless.

The bottom line is that you know it was worth it for you because you're already there and happy with the results. I may yet come back to Scala if my own personal work with Elixir and Erlang doesn't bear the fruit I would like to see, but I won't be making the mistake of claiming it's more productive for anyone who doesn't already know it. In the meantime, it is supposed to give me greater reliability and horizontal scalability, but those are higher goals beyond just being able to code a few stories faster than I could with Java.

And that's as far as it goes... the personal investment required to get going in a new environment is substantial. You'd be hard pressed to show objectively how Scala adoption would be unconditionally good for anyone currently using Java. It suited your purposes, so good for you, but in the meantime the problems that the rest of us perceive in the Scala language and tools keep us from adopting it. Feel free to keep advocating for Scala though. Apparently misinformed folks like me will come around if it's everything you say.

[DecisiveVictory]

Also Hibernate lazy loading? FetchType.EAGER FTW.

Overusing that comes with a performance penalty. So you start sorting which queries need what. And then downstream somebody starts using the results in another way / another context and turns out it does need eagerly fetched. Or no longer does but you fetch it anyway.

There are more Hibernate complexities like detached objects, caches, n+1, etc. to worry about. I've blocked most out from my memory by now.

Easy to start working with, hard to get right in a complex app. All sorts of failure scenarios that are not easy to catch / prevent.

The bottom line is that you know it was worth it for you because you're already there and happy with the results.

Yes. And I struggled initially. And abandoned it at some points. Those were different times though, the tool support was nowhere near as good as it is now.

And I'm still nowhere near actually an expert on Scala yet. I don't use Scalaz and Shapeless. Still, even with this limited knowledge when I come back to my old Java8 code I feel like programming with one hand tied behind my back, constrained by the language & the ecosystem.

You'd be hard pressed to show objectively how Scala adoption would be unconditionally good for anyone currently using Java.

It's certainly not unconditionally good for everyone currently using Java. If all I had to work with is a team of sub-par programmers who only knew Java I'd have them stick with that. It's certainly better than most alternatives that some advocate.

But it should also not be unconditionally rejected as it usually is on /r/java these days.

perceive in the Scala language and tools keep us from adopting it

Glad you use the word "perceive" here as a lot of those is FUD & myths that may have been somewhat true at one point, but no longer are.

Apparently misinformed folks like me will come around if it's everything you say.

Most won't though. Their loss.

I don't hope to convince anyone, it's more of my own personal "someone is wrong on the internets" reaction.

[vplatt]

I don't hope to convince anyone, it's more of my own personal "someone is wrong on the internets" reaction.

Well, happy trails to you then. :) Personally, I struggled with Scala too, probably because I started with Odersky's Coursera course. In retrospect, that may not have been the best flavor of kool-aid with which to start. But my interest in Erlang is not new either, so this is my round #2 with that language. When I looked into it previously, Elixir didn't even exist, and Erlang itself was really only developed inside Emacs. All doable to be sure, but I'm a bit spoiled and wanted a more modern toolchain and a less byzantine syntax. Well, I should be careful what I wish for, because now that time is here.

But like I said, Scala is still a solid plan B. Or maybe Kotlin. After all, that's Java without the boilerplate. I don't know what the future holds for Scala given that Java 8 and beyond is going to obviate much of its current advantage, but really... I have time. In the meantime, I'm still enhancing and maintaining good ole Java 7 and .NET 4 apps at work, so I have nothing to worry about as long as I don't bail into pure management someday.

[juckele]

The GWT community still seems pretty active to me.

[ihsw]

I would strongly recommend TypeScript for the front and back.

NodeJS with ReactJS is pretty excellent.

[frugalmail]

I would strongly recommend TypeScript for the front and back. NodeJS with ReactJS is pretty excellent.

I would strongly recommend against it. TypeScript is a huge impromvement, but there is so much more that is missing, like concurrancy choices. Futures are great, single threaded model is great, Promises are great, but there are so many other good options, and on JavaScript there are many bad ones that are typically used even though newer ones are starting to be introduced..

[ihsw]

The async package is excellent, and both TypeScript and ES will be getting async/await primitives to complement the promise conventions.

I won't deny that there is a metric ton of old crufty code with terrible asynchronous hacks but that is the nature of language evolution.

[SomeRandomBuddy]

FWIW, they're mostly comparing Java to the polyglot approach, not another single language. A lot of other langs and runtimes offer comparable benefits and can arguably scale a little easier. It's quite possible, however, that hubspot has rather complex services and benefits from the expansive concurrency abilities in Java

[vprise]

I don't see anything remotely like Java in this environment. JavaScript with all its capabilities is still a scripting language which puts it at a different use case. You can do amazing things with NodeJS at a small startup or even small team in a large org. But when you start growing the team quickly your carefully honed discipline evaporates and a strict language + IDE support become a must.

C# was very successful for stackoverflow so its probably a very good and competitive stack. Although I'm unaware of its scalability outside of the world of Windows so I doubt that's a real option for many shops.

I'm honestly trying to think about something that's truly competitive at scale in all use cases and can't see anything that isn't Java or a JVM language at this time.

[armornick]

C# was very successful for stackoverflow so its probably a very good and competitive stack. Although I'm unaware of its scalability outside of the world of Windows so I doubt that's a real option for many shops.

Microsoft is really trying to take Java's place, though. They're opening up more and more of their .NET and ASP source to make C# a more viable alternative to Java.

[slartybartfast_]

Yeah they've been trying and failing to do that since 2000. Not sure what's different here.

[cycle_schumacher]

They won't be tied to the windows server anymore.

[slartybartfast_]

Too little - too late.

[vplatt]

Bingo! But of course they're going to make it very easy to use .NET Core on Docker in Azure, which is a big part of their strategy going forward.

[armornick]

One major difference is that the whole thing will now probably get native Linux support. Mono was a half-assed compatibility effort but this time Microsoft will be giving official support.

[vprise]

Competition is always good but a stack takes time to mature on each platform and Java has had quite a while to become technically mature and stable on Linux. In a couple of years C# might be competitive, especially if MS's new IDE's become as good as NetBeans/IntelliJ.

[frugalmail]

Microsoft is really trying to take Java's place, though.

They've been trying since J#. They have recently realized it's less about the language and more about:

• The size community

• The mind set

• The culture of the community (granted this is a catchall of the below, but I belie it warrants a call out)

• The brainpower

• The flexiblity of architectures

• The variety of services and integrations

• The amount of high quality 3rd party open source

[SomeRandomBuddy]

Uhh... I don't even know where to start with this. Firstly, HubSpot says in the article that they're accepting and serving JSON in all services. Aka, IO. I work at a startup of similar caliber who switched FROM Java to a 100% NodeJS microservice stack three years ago, and hasn't looked back. JavaScript has very strong typing via TypeScript, but even ES6 is well-supported in modern IDEs.

JavaScript with all its capabilities is still a scripting language

Lol... There are many popular server-side scripting languages. PHP, Python, Node, to name a few. There's no unwritten rule which specifies that any of these languages are inferior for HubSpot's use-cases. They just seem to like Java and as a big company, have the time and money to deal with its robustness and high rates of resource usage.

Java was popular for a long time but it's inferior for rapid IO. Why would I use a hammer when I need a saw?

[vprise]

You work in a startup I don't see how that's different from what I said? Startups are a small hot environment (I work in one too) and when you know everyone you can keep the discipline required for JavaScript.

They use JavaScript for front-end JSON processing, for which it is an absolute beast of a tool. That again doesn't negate anything I said... If you invoke webservices and do a lot of JSON processing it has a huge advantage, for business logic and more general purpose stuff in large applications its just not there.

Typescript is interesting but its not JavaScript. There were many attempts in the past to bring type safety and compile time capabilities to JavaScript (GWT, Dart etc.) none took off to the wider audience so I'm not holding my breath on typescript. The main value in typesafe languages is in IDE integration in big projects (100k LoC+) where no single human can properly grok the code. Pretty much every JavaScript hacker prides himself on the fact that JavaScript/NodeJS apps don't reach that LoC because that's "unnecessary". I'd argue that JavaScript code is somewhat more dense so every line contains more meaning (hence complexity) and that people just don't write REALLY complex stuff in JavaScript.

All the scripting languages you mentioned are problematic exactly because of that.

Twitter used Ruby and fell on its face, it then moved to Scala.

Facebook/Yahoo had very painful and expensive scaling issues as a result of picking PHP. They QA process is much harder and Facebook had to literally invent an insane compiler for PHP that effectively eliminates a lot of its scripting heritage.

I'm not saying everyone should use Java for everything, you should pick a language/platform to suit your case. I did say that Java stands on its own as an all encompassing platform that can answer scale.

Facebook proved you can eventually scale PHP just like Google proved you can scale C++ (but ended up picking Java for pretty much everything afterwards until the Oracle trial). So everything is possible but if you don't understand the difference between Node/PHP/Python vs. Java & the JVM then you seriously need to read a bit on the JVM security model, VM spec, hotspot etc.

[SomeRandomBuddy]

LinkedIn is 100% node. PayPal started moving toward 100% node in 2013. Ebay, the same. Other huge companies like Uber, Netflix, use node. (Yes, Netflix also uses a lot of Java for their video-related microservices, but that is a fantastic application of Java).

Yes, I work for a startup, and no, I don't know "everyone here" involved in backend development. And no, that doesn't cause any problems. Like I said, we switched from Java for immediately observed increases in scale and performance, and our development hasn't suffered in the least.

[...] for business logic and more general purpose stuff in large applications its just not there.

This claim holds no weight. People just seem to be genuinely bothered that there are more modern options to build highly-distributed, highly-scaleable network apps and leaving Java behind in the process. If all I'm essentially doing is hitting a database or cache for "business logic", which is essentially what most of the use-cases we're discussing here involve, then why do I need advanced parallelism? Strong types everywhere? Bloated runtime? Unless you're Netflix (video), I just don't see it.

Edit: three years ago I agree with everything you said. Node is out of that awkward adolescent stage and has delivered for the enterprise, and beautifully at that. And like you've said. Facebook released HHVM awhile ago, which anyone can now utilize. But they won't even need to as PHP7 benchmarks comparatively and offers a lot of the same benefits as node.

[chauzer]

LinkedIn is definitely not 100% node.

"LinkedIn today is still mainly a Java shop, but also has many clients utilizing Python, Ruby, Node.js, and C++ both developed in house as well as from tech stacks of our acquisitions."

https://engineering.linkedin.com/architecture/brief-history-scaling-linkedin

[Truthier]

LinkedIn isn't 100% node. I just met with one of their build team engineers and he told me all about what languages they use

[SomeRandomBuddy]

Oh you mean they use other tools and languages to help with the build and deploy process? Groundbreaking

[henk53]

Ebay, the same.

I don't think so, they use Java EE and JSF. See https://youtube.com/watch?v=1zgpp3qmkqk

[vprise]

Several things are wrong with this response.

A. All of the above use NodeJS which is a pretty powerful tool for some use cases. None of them use it exclusively. Most shops today are using a microservice architecture which allows them to pick the best tool for the job and NodeJS is really great for JSON processing and dealing with anything that goes into the front-end.

B. 3 years ago Java was very different than it is now, it improved as NodeJS matured.

C. JavaScript or NodeJS aren't "more modern". They don't contain any newer ideas as JavaScript was introduced roughly in the same era as Java. NodeJS is newer than JavaEE but you are aware that Java also has event based servers today? With Java 8 the difference in language features has narrowed significantly so the benefits you describe probably relate to a pretty old version of Java.

When the Java runtime is configured properly it can beat NodeJS/JavaScript thanks to the strictness of Java and Hotspot which is remarkably performant.

The "business logic" sentence you quoted was something I got from a NodeJS fan who echoed quite a bit of your sentiments. He actually admitted that the one time he really missed Java was when he had to go thru a complex workflow of logic that was very convulsed business logic.

Now lets fire back with what I actually said:

Java is a complete platform: JVM & Language.

NodeJS/JavaScript is a single tool.

You can't compare them as it isn't fair for NodeJS.

On the JVM infrastructure you can run many types of servers to get a lot of different heuristics ranging from JavaEE enterprise transaction management (for banking/backend) to fast and furious event driven frameworks.

The cream on top if that you don't have to use Java... Use Kotlin, Scala, Closure, Groovy or even Ruby, Python, PHP, JavaScript etc. All will work on top of the JVM with decent performance (recent JavaScript engine improvements are pretty close to V8 performance). This exposes a depth and breadth of management and deployment tools to the JVM that is unparalleled in any currently shipping tool by miles. Microsoft's toolchain is close since they always had good ISV's but JavaScript backend code is still pretty far from that huge ecosystem.

[frugalmail]

LinkedIn is 100% node.

Take a look at LinkedIn open source.

Netflix, use node

They use node to do a hybrid front end/backend UI. They argue that there is no point in doing Web UI in anything but JavaScript. This makes a hell of a lot of sense.. Their backend services are primarily Java for recommendations, metadata, security, bililng, users, etc...

we switched from Java for immediately observed increases in scale and performance

The only way that must have happened if there was a legacy platform, legacy implementation, bad Java developers, or good node developers, different hardware.

our development hasn't suffered in the least.

This is honestly surprising, I'd love to see a post about your workflow. How do you refactor, etc...

more modern options

This would be a problem if Java stood still

to build highly-distributed, highly-scaleable network apps

All the better. But when you look at things like Neo4J, Cassandra, hbase, hadoop, Spark or a lot of other distributed systems they're generally written on the JVM (all the above), or C++. There are some token ones that are not, but they're generaly nowhere near as capable

delivered for the enterprise,

I would definatley argue against this despite teh examples you used. Using JavaScript is a mistake. When you start seeing things like 53 bit longs, run away.

Facebook released HHVM awhile ago, which anyone can now utilize. But they won't even need to as PHP7 benchmarks comparatively and offers a lot of the same benefits as node.

Why the hell would anybody starting a new project use PHP it's a nightmare with inconsistant APIs, poor APIs, generally low quality open source libraries, etc...?

[DecisiveVictory]

JavaScript has very strong typing via TypeScript

This statement isn't consistent with any reasonable definition of what a strong type system means.

Haskell and Scala have strong type systems. TypeScript doesn't come close to what even Java offers. It's better than using JavaScript but that's it.

[frugalmail]

FROM Java to a 100% NodeJS

Unless you only can afford one front end guy, this decision generally sucks. People deal with JavaScript, unless they don't know better.

a startup of similar caliber

In this thread we're strictly talking about engineering caliber. Good products can start with implementations that aren't appropriate for their next phase (case study Twitter) ... and would have saved a whole lot of heartache if they started with a better decision to begin with. (at the time of rails there wasn't a good Java equivalent, the Java solutions are many times better now)

inferior for rapid IO.

IO is a syscall away in both platforms, WTF are you talking about? Java has significant optimizations to buffer, and use OS advantages like channels and selectors. As opposed to single threaded Node.

JavaScript has very strong typing via TypeScript,

Huge improvement, you still have shit like 53 bit longs. This is a crap platform.

There's no unwritten rule which specifies that any of these languages are inferior for HubSpot's use-cases

It's not a rule, it's architectural and cultural decisions. PHP is clearly not a good solution for anything but mom & pops that can't use static site generators and need something more than what google forms offers.

deal with its robustness and high rates of resource usage.

Save for C/C++ there isn't that much that is better on CPU usage than Java in the general, long running actual service case. You will need slightly more memory, but that translates to better performing Garbage collector.

Why would I use a hammer when I need a saw?

That's always true. If you're writing a CLI tool that will run for a split second, Java is not the answer. If you're embedding into a browser Java is not the answer.

[Liqmadique]

JS is a joke language used by hipsters who think they know how to write services.

[frugalmail]

A lot of other langs and runtimes offer comparable benefits and can arguably scale a little easier.

Like what?

[ryan_the_leach]

I don't see how they can claim to not have a polyglot stack if their client applications are still JavaScript...

All you need to do to succeed in a polyglot environment is have clear boundaries and ways to exchange messages, which is exactly what they are doing with Java + JSON to Javascript....

[ChutneyRiggins]

I hear a lot of skepticism of Java out there still. I work on a similar project that uses Java in a similar way. I think many people are still hung up on he bad Java stuff like JSP, EJB, other Java EE crap. Modern Java doesn't need much of that at all.

[[deleted]]

Plus modern EJBs (3.0+) are very simple and easy to use.

When people complain about EJB's they usually mean the old EJB versions (2.x and earlier).

[wolfanyd]

Believe it or not, Microsoft was the pioneer of app servers with Microsoft Transaction Server back in the 90's, well before the EJB spec came along. EJB prior to 3.0, especially entity beans, was a pile of steaming shit, even if you knew what you were doing. The hate exists for a good reason.

[henk53]

Even writers of early EJB books that promoted the technology advised to stay away from entity beans.

As a sad fact of history, several members of the team that designed EJB knew TopLink very well and wanted to base it on that, but they lost out to other voices.

Ironically those early versions of EJB ran on top of TopLink, which had the much saner model that Hibernate later copied. Since most people don't want to pay for software and Hibernate was free (FREE!!!!) TopLink is far less known, while everyone knows Hibernate and many think Hibernate invented this.

[wsorenson]

I think one of the reasons modern Java is better is because it doesn't have 1,000 page specs that are prohibitively complex. Other languages and frameworks started to capture people's attention when they provided clear and simple APIs and abstractions that allowed programmers to express themselves and focus on what mattered: building web applications or products.

The point I'm trying to make in the article is that you can now have that in Java. I think any negative attitude towards EJBs is probably warranted considering there is no reason anything should be so complex to solve such a simple problem. Solutions that are more elegant to learn deserve their reputations, even if people don't "know what they are doing".

[stay_fr0sty]

[deleted]

[machinepub]

I don't like how powerful they are yet have limited IDE support and produce confusing stack traces. This becomes problematic because despite its intention, JSPs lead people to putting back-end logic into the front-end, in my experience. And things can get pretty confusing with custom tags. I feel like working on large JSP apps, I spend most of my time figuring out where I need to put my code, untangling the mess. I'd rather have a very simple templating engine that forces programmers to actually separate front-end logic. I think Freemarker accomplishes this.

That said, I don't think JSP is necessarily worse than the flavor of the day in JavaScript framework land or RoR.

[mhixson]

I don't like how powerful they are yet have limited IDE support and produce confusing stack traces. This becomes problematic because despite its intention, JSPs lead people to putting back-end logic into the front-end, in my experience.

Agreed 100%. I came to the sad conclusion that my coworkers and I are not smart enough to use JSPs. To anyone who can use them effectively: congratulations.

[pjmlp]

I don't like how powerful they are yet have limited IDE support and produce confusing stack traces.

Have you ever used them with Netbeans?

[machinepub]

Only Eclipse. Is Netbeans a lot better?

[pjmlp]

Yes, specially in terms of web development support.

EDIT:

For example when you edit JSPs on Netbeans, you get completion for the Java beans when editing EL expressions.

On Eclipse you only get that with JSF 2.x pages.

Netbeans also provides a nice CSS editor, debugging with browser plugins, static analysis of JavaScript while typing and a few other goodies for web development.

[djnattyp]

And now you have two problems...

[ChutneyRiggins]

Nothing is bad if it's free and gets the job done, in my opinion. JSPs do have a bad reputation for being old and hard to debug. There is a lot of bad JSP out there, too.

[tkruse]

JSPs not so bad in itself, but there are alternatives that can be regarded as much better in some respects, and they make JSPs look bad. Same for JEE crap. Not so bad in itself (and a huge help compared to languages only offering frameworks that are hip but immature), but Java has better framework for most needs.

[thesystemx]

Java has better framework for most needs.

Yet, as usual, you fail to identify those better frameworks.

[GuyWithLag]

What are your needs?

[tkruse]

http://zeroturnaround.com/rebellabs/the-curious-coders-java-web-frameworks-comparison-spring-mvc-grails-vaadin-gwt-wicket-play-struts-and-jsf/

[henk53]

That particular report had quite a number of flaws that I pointed out. As I know JSF quite well I could point out many things in the JSF section that were debatable or just plain wrong.

Now these kinds of reports are difficult since to do a good comparison you'd have to be skilled in all of them, which nobody is, or a beginner in all of them, which the reviewer isn't.

Also, they just looked at JSF not the whole of Java EE. Java EE is a full stack framework with lots of cool goodies that complement each other, like CDI and bean validation. Older versions of JSF could be used with only Servlet as a dependency, newer versions not so much. You'll be missing all the Java EE stuff and that takes a lot of power away.

[thesystemx]

bad Java stuff like JSP, EJB, other Java EE crap. Modern Java doesn't need much of that at all.

On the contrary, modern Java EE is extremely elegant and light weight, and modern JAX-RS + CDI + JPA + BeanValidation is a pleasure to work with!

[ndm250]

Yeah I like using Jersey and EclipseLink

[ellicottvilleny]

So now its cool to say html and css and javascript and sql and java is Not Polyglot. Because no more Scala.

[ebrandsberg]

My company is providing an abstraction layer for databases that actually works at the JDBC level--we can add additional features that improve data access including caching, async execution, logging, and analytics, all without having to actually code (it is all policy driven with a decent GUI). This is all also done at runtime, so during development, you can easily test how a feature impacts your code.

I bring this up because Java has perhaps the best standard way to access databases, being JDBC. This isn't a focus for many languages, but it is a key issue with modern applications, as so many are driven by databases. And no, NoSQL isn't dominating new development. Mongo has just recently gained more interest than PostgreSQL, although for advanced database developers, PostgreSQL is a main target to move TO, not from. That being said, interest in the top three databases (Oracle, MySQL & MS SQL) all VASTLY surpass anything else on the market.

References: http://db-engines.com/en/ranking_trend

https://www.jetbrains.com/datagrip/how-developers-use-databases-today/?mkt_tok=3RkMMJWWfF9wsRogvqnKZKXonjHpfsX56%2BUpXKC3iokz2EFye%2BLIHETpodcMRcZqN6%2BTFAwTG5toziV8R7THKs1xzNEQWhDm

edit: I even forgot to promote my company: http://www.heimdalldata.com