Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

About PayPal's Node vs Java “fight”

developer-blog.cloudbees.com

Post reply on HN
Print view View original

51–60 of 216 posts

Re: About PayPal's Node vs Java “fight”

#51

Post by fat0wl »

cloverich wrote: post #42
fat0wl wrote: post #40

Earlier quoted context omitted.

Hear hear. When I read about JVM performance issues I usually immediately think "team of 20+ complacent corporate devs who don't care if this succeeds or not because they can get a new job insanely easily at a moment's notice". The issue with these other frameworks/languages is that even when modern frameworks are used there are usually some Java backend services (or another "powerful-outside-of-the-web-also" languag…

Here's[1] a comparison of the two from an RoR guy who used Play! (with Scala) for 16 months. I found the ensuing discussion pretty informative with minimal FUD / bashing. [1]: https://groups.google.com/forum/#!searchin/play-framework/pl...

Thanks but I've seen a lot of similar comparisons and they seem to focus on trivial things :/

For example the portion about "Asynchronicity" is a brief paraphrase like "Play is good in Rails its awful or doesn't exist". Performance isn't even mentioned really.

I find that with Rails apps a lot of development effort is put toward optimizing for scaling rather than complex logic, where Play could potentially be stronger. A lot of the comparisons seem to be posted by RoR devs who are looking at Play as a potential new framework for a CRUD app with a very fancy UI. In my mind that's not what it is... I read a few articles about corps using it for big distributed apps with a lot of eventing.

So I guess it's a bit of my personal taste but I just don't see "Rails has HAML", for example, as a reason why it's better given that HAML would be pretty trivial to implement in Play if the community wanted it. Full-featured CRUD frameworks vs. enterprise-ready app frameworks are very different ideals. They each have their place but if one tech were to emerge as really superior I think it could easily integrate all the bells & whistles that rapid CRUD devs like.

Re: About PayPal's Node vs Java “fight”

#52

Post by karlmdavis »

iamleppert wrote: post #37

He forgets to mention one critical fact: developer productivity. Most applications (sans his terrible example of protein folding) are not that performance critical. Most of the code you write as a developer will do-away with any platform or language advantages itself. It is not productive to write web applications in Java. Everyone hates it, which is why we have ruby, php, and now javascript (node). I'd much rather t…

>Everyone hates it ...

I don't; that's a bit of a sweeping generalization. I happen to enjoy writing webapps in JAX-RS and Wicket, and I know a number of folks who enjoy writing them in other frameworks.

Re: About PayPal's Node vs Java “fight”

#53

Post by nogridbag »

pron wrote: post #32
ebiester wrote: post #28

I fantasize about rebuilding the java ecosystem. Create "JPM", don't allow anything from the old Maven system in it. Create a new "hip" minimalist framework that ignores everything about java and its notions of OOP. Basic dependency management handled NPM-style. Developers encourage to put everything in the same package for their own stuff, and everything is package level. Getters and setters and encapsulation and ja…

I think that much of your fantasy is already a reality. For example, look at how Dropwizard[1] assembled a best-of-breed collection of modern Java libraries into a small, yet very powerful, REST micro-framework. So the bits and pieces are certainly there, and even the JCP does good work sometimes (JAX-RS) that becomes good standard APIs with many different implementations. [1]: http://dropwizard.codahale.com/getting-…

Ninja web framework [1] is also worth a look. It's similar to Dropwizard in that it's less of a framework and more like a well thought out archetype building upon the best Java libraries. Two main differences I see are Ninja uses Guice for DI whereas dropwizard is manual DI. Dropwizard uses JAX-RS while Ninja has its own Play 1 style routing system.

While I really like JAX-RS, the reference impl Jersey uses HK2 for dependency injection, which makes it odd to integrate into a Guice application (in fact Guice support is still lacking with Jersey 2.x).

[1]: http://www.ninjaframework.org

Re: About PayPal's Node vs Java “fight”

#54

Post by mynames »

radicalbyte wrote: post #44
ebiester wrote: post #28

I fantasize about rebuilding the java ecosystem. Create "JPM", don't allow anything from the old Maven system in it. Create a new "hip" minimalist framework that ignores everything about java and its notions of OOP. Basic dependency management handled NPM-style. Developers encourage to put everything in the same package for their own stuff, and everything is package level. Getters and setters and encapsulation and ja…

You've basically described C#: Getters, setters fixed? Check. Functional features? Check. Most crappy OO features fixed? Check. Trendy package system inspired by npm/apt-get/gems? Check. Healthy community with libraries replacing frameworks? Check. I'd recommend checking it out if you haven't already.

Could you expand on "crappy OO features"?

Re: About PayPal's Node vs Java “fight”

#55

Post by kalleboo »

sehrope wrote: post #7

Regarding the JVM performance: > Under minimum load the best page rendering time was 233ms Regarding the node.js performance: > Under minimum load the best page rendering time was 249ms What the heck are they doing that takes 250ms that could possibly be app code related? That's a lot of CPU usage if its actually doing CPU-bound work. Since these are web apps that's obviously not the case. The request time is going t…

> Language choice is no where near as important as your DB-access patterns (and more generally DB performance, caching, etc).

I bet they have a really crappy backend storage system for account history/data.

We have a PayPal transaction history with a low 6 digits record count. Searching for a specific email address, name, or transaction ID can take literally minutes. Exporting a transaction history CSV takes hours.

Re: About PayPal's Node vs Java “fight”

#56

Post by candl »

pron wrote: post #32
ebiester wrote: post #28

I fantasize about rebuilding the java ecosystem. Create "JPM", don't allow anything from the old Maven system in it. Create a new "hip" minimalist framework that ignores everything about java and its notions of OOP. Basic dependency management handled NPM-style. Developers encourage to put everything in the same package for their own stuff, and everything is package level. Getters and setters and encapsulation and ja…

I think that much of your fantasy is already a reality. For example, look at how Dropwizard[1] assembled a best-of-breed collection of modern Java libraries into a small, yet very powerful, REST micro-framework. So the bits and pieces are certainly there, and even the JCP does good work sometimes (JAX-RS) that becomes good standard APIs with many different implementations. [1]: http://dropwizard.codahale.com/getting-…

Dropwizard is pretty great, but one unfortunate aspect is that it's stuck with Jersey 1.x for JAX-RS and as a result is missing some nice features, like async responses, etc.

Re: About PayPal's Node vs Java “fight”

#58

Post by fat0wl »

[deleted] wrote: post #48
fat0wl wrote: post #40

Earlier quoted context omitted.

Hear hear. When I read about JVM performance issues I usually immediately think "team of 20+ complacent corporate devs who don't care if this succeeds or not because they can get a new job insanely easily at a moment's notice". The issue with these other frameworks/languages is that even when modern frameworks are used there are usually some Java backend services (or another "powerful-outside-of-the-web-also" languag…

[deleted]

Hah I am the wrooooong guy to get angry at. I'm just speaking from experience and observation of others -- personally I greatly prefer the open source world.

I'm sure there are tons of crummy Java devs out there but there are also some brilliant ones delivering "corporate solutions" (fancy term for myriad proprietary frameworks) or just coding for Google. And there are talented/talentless in almost every community.

Why would you assume I'm snubbing my nose at open source when I'm advocating for Clojure? The JVM is a sick platform for web dev and it gives you the opportunity to use a variety of languages and open source tools in a single high-performance project.

I don't know if this is personally what you're getting at but it seems like a lot of the attraction to the scripting languages is sorta convention over configuration rather than some major shift in the web dev paradigm -- the same design patterns are possible in every language for the most part.

My point was merely that judging a single implementation is a straw-man approach. You don't know how motivated or talented those devs were in the first place.

EDIT: well, the comment was deleted so I guess the writer realized my position maybe(?). Well, Let the record show that open source exists all over the JVM... I don't know why it has the rep of looking down upon open source movements...

Re: About PayPal's Node vs Java “fight”

#59

Post by gprasanth »

I was reminded that self deceit is the worst of its kind on reading the article. seeing a benchmark and deciding what to write your next application in kinda like that. you browse until you find the benchmark that aligns with what works out best for the lazy you and not works out best for the faithful app. this was just an observation of mine and not necessarily true or applicable to you.

Re: About PayPal's Node vs Java “fight”

#60

Post by pron »

runT1ME wrote: post #49
ebiester wrote: post #28

I fantasize about rebuilding the java ecosystem. Create "JPM", don't allow anything from the old Maven system in it. Create a new "hip" minimalist framework that ignores everything about java and its notions of OOP. Basic dependency management handled NPM-style. Developers encourage to put everything in the same package for their own stuff, and everything is package level. Getters and setters and encapsulation and ja…

So why not scala? Scala 8 years ago is where java 8 is now, and you can ignore most of the java frameworks.

Even putting aside my great dislike for Scala (which I discussed on HN ad nauseam :)), I think everyone would agree that Scala has a very different philosophy from Java. Java has been designed as a "blue-collar" language, with maintenance of a large project with possibly hundreds of developers as a central guiding principle. C#, Go, Dart, Kotlin, Fantom etc., have a similar philosophy. But Scala is a different beast altogether. You can love it or hate it, but even its most enthusiastic fans would concede that it is most certainly not appropriate as a replacement for Java in some/many/most (depending on your view) circumstances.

Also, Java is extremely popular, and some of its most painful points have been addressed in Java 8. Even an arguably better language (regardless of its name) will not easily replace Java. Hey, look across the browser at JavaScript. There are arguably better languages there; are they replacing JavaScript?

If you look just at GitHub – which is greatly skewed towards new languages – you see that all other JVM languages put together make about 10% of the JVM ecosystem, with Java being the 90%. Outside of GitHub, in "the real world", the situation is even more strongly in favor of Java. I don't know if this is going to change much in the next few years.

I don't mean that you shouldn't use an alternative JVM language if it makes your work better, and there are many viable and very useful alternate JVM languages – personally, I like Clojure and Kotlin – but you can't just "replace" Java so easily. I think efforts to reform the Java ecosystem are more likely to succeed – at least in the short term – than efforts that require switching to a different JVM language.

Post reply on HN