About PayPal's Node vs Java “fight” • Hacker News Board

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

#31

Post by jkrems » Fri, Dec 13, 2013, 6:25 PM UTC

edwinnathaniel wrote: post #26

pron wrote: post #21

Earlier quoted context omitted.

My experience is similar: Java will get you 80% of super-optimized-compiled C++ speed for the cost of more memory (although you may choose to give Java less memory and pay in speed), and will get much closer to C++ speed with some work (off-heap memory, etc.). However, Java has the upper hand in two scenarios: 1) long-running applications that are developed by a large team – those usually make heavy use of virtual in…

Don't forget the tools and infrastructure that support good engineering (dependency management, build, javadoc, findbugs, checkstyle, PMD, cobertura for code-coverage, better unit-testing frameworks, the list goes on). I'm sure C++ ecosystem has some of those but whether people are using them or not seem quite obvious: how many C++ projects do that out there? Not as many as the Java counterpart.

Almost agree, but minor nitpick: the tools and infrastructure (at least most of them) exist on other platforms in the same or better quality as well. Especially dependency management is not necessarily a strong side of Java (one global namespace for types etc.).

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

#32

Post by pron » Fri, Dec 13, 2013, 6:25 PM UTC

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-started/

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

#33

Post by Helianthus » Fri, Dec 13, 2013, 6:30 PM UTC

camus2 wrote: post #15

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'm pretty sure the paypal node app does not directly access the db , the node app talks to a private api.

That doesn't really change the point, it just wraps it with a layer of abstraction.

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

#34

Post by pron » Fri, Dec 13, 2013, 6:32 PM UTC

jkrems wrote: post #31

edwinnathaniel wrote: post #26

Earlier quoted context omitted.

Don't forget the tools and infrastructure that support good engineering (dependency management, build, javadoc, findbugs, checkstyle, PMD, cobertura for code-coverage, better unit-testing frameworks, the list goes on). I'm sure C++ ecosystem has some of those but whether people are using them or not seem quite obvious: how many C++ projects do that out there? Not as many as the Java counterpart.

Almost agree, but minor nitpick: the tools and infrastructure (at least most of them) exist on other platforms in the same or better quality as well. Especially dependency management is not necessarily a strong side of Java (one global namespace for types etc.).

> one global namespace for types

I am not entirely sure what you mean by that, but in Java, a runtime type is determined as a combination of its name and its class-loader. You can (and do) have two versions of the same class running alongside one another in different modules of your code.

Granted, supporting this stuff is not easy, but hopefully the long awaited module system planned (currently...) for Java 9 is supposed to make this all both powerful and easy.

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

#35

Post by lampe3 » Fri, Dec 13, 2013, 6:34 PM UTC

I stopped reading at the part with the "Type information". Or better i should have stopped... Another post about(and the from paypal too) about my language X vs language Y...

It's the same flameware like Facebook started with its we can't get HTML5 as fast as native... then some people who know what they where doing did it...

No don't use java No don't use javascript

For god sake learn one language or two and learn it very well! i mean very well! and you will write good code and performant code...

EDIT: Why do i get down voted? Jesus HN gets worse and worse...

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

#36

Post by ExpiredLink » Fri, Dec 13, 2013, 6:36 PM UTC

> Spring brings a lot of functionality to the table. Likely far too much functionality. Most people are moving away from the monolithic application and moving towards smaller more lightweight frameworks…

It's high time to debunk Spring. In the name of 'Dependency Injection' many Java developers still create complex, monolithic and - first of all - untestable applications with this framework. In fact, Spring adds another layer of complexity on top of Java EE without real benefit. It fosters Anti-Patterns like 'Dependency Injection' that give you the illusion of modularity but instead create dependencies within the application ('Dependency Injection' needs to be taken literally).

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

#37

Post by iamleppert » Fri, Dec 13, 2013, 6:37 PM UTC

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 trade a little performance for a scripting language anyday.

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

#38

Post by rossjudson » Fri, Dec 13, 2013, 6:38 PM UTC

stephenconnolly wrote: post #17

srean wrote: post #14

This was a good read. Minor nitpick, given the author's stress of not comparing apples to oranges I think the motivating anecdote on protein folding struck a dissonant cord. A fair comparison would have been a profile guided optimization with comparably aggressive compile optimization flags. For these types of problems the profile characteristic is fairly static, so there is hardly ever a need to pay for the warm up…

I debated including that example, but at the end the point I was making is that the JVM can be faster than native code in some cases... this case had static allocation of data and the calculations could benefit from MMX instructions when available, plus there was a logical unrolling that I think it was able to infer from code path analysis

And superword optimization, when possible...

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

#39

Post by cgh » Fri, Dec 13, 2013, 6:39 PM UTC

pron wrote: post #34

jkrems wrote: post #31

Earlier quoted context omitted.

Almost agree, but minor nitpick: the tools and infrastructure (at least most of them) exist on other platforms in the same or better quality as well. Especially dependency management is not necessarily a strong side of Java (one global namespace for types etc.).

> one global namespace for types I am not entirely sure what you mean by that, but in Java, a runtime type is determined as a combination of its name and its class-loader. You can (and do) have two versions of the same class running alongside one another in different modules of your code. Granted, supporting this stuff is not easy, but hopefully the long awaited module system planned (currently...) for Java 9 is supp…

Well, the OSGi module system supports this now and is quite powerful. Oh wait, you also said easy.

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

#40

Post by fat0wl » Fri, Dec 13, 2013, 6:45 PM UTC

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…

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" language) if the app does anything substantially complex. A ton of the hip web tech is basically for building front-end and cobbling together relatively inefficient backends.

I was an RoR guy myself but moved to Java & I see the correct hipster tech here but just lacking unanimity. I bet if the RoR community decided "Clojure hell yea" or "Scala hell yea" and contributed lots of plug-ins to those ecosystems, they would generally have similar development times with a lot of performance gain for free. I'm thinking about trying Play framework on Heroku just to see what the monthly bills & New Relic readouts look like in comparison.