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

21–30 of 216 posts

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

#21

Post by pron »

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…

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 inheritance for the sake of good engineering, and the execution profile is not static, so the program can greatly benefit from JIT optimization; and 2) fairly complex multithreaded code – Java's incredibly useful and well-implemented blocking and lock-free data structures, as well as an incredible work-stealing scheduler (all expertly programmed by Doug Lea) make great use of a general purpose GC, plus Java usually gets them about 5 years before C++ (if C++ gets them at all).

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

#22

Post by kcmarshall »

auvi wrote: post #3

TL;DR from the post: """ My take-home for you, the persistent reader who has read all my ramblings in this post... Don’t build your app on top of a pile of crap in-house framework. """

Which suggests that take-home #0 should be: Don't build a pile of crap in-house framework.

Sniffing that out before too late is the tricky part...

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

#24

Post by tunesmith »

I wonder if a lot of headway could have been made simply by doing some constraint analysis on the Spring framework and figuring out how to improve the performance. I have a hard time believing that Spring itself was completely topped out. It might have been an architectural choice, or some bloat that could have been taken out incrementally.

Instead they seem to be going the route of "the unicorns will solve it". The overall cost of that approach seems higher - finding unicorns is rare. Finding unicorns that are very good at all areas is even harder. I know there are a lot of unicorns on this board, but there sure aren't a lot of unicorn resumes on a hirer's desk.

I think the value of Spring has always been not that it's super-high-performance out of the box, but that it does a lot for you, and that as you learn more and more of it, you can develop solutions fairly quickly. It's built to make it easier on the developer, not the servers - but it is still easy to improve performance by focusing on constraints.

I think it's easy to blame what's between the keyboard and the chair, but the availability of said unicorns is the one ingredient of the system that is not in an employer's control. What is in control is sponsoring more education, and focusing on simplicity and constraint analysis.

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

#25

Post by pron »

Xorlev wrote: post #5

Well-reasoned. I've always found framework overhead and especially tech debt to be the largest contributors to performance issues. Especially when said frameworks have lots of ways to do things and they're not all the best way to do it. Modern JVM development starts to look a lot like Sinatra -- you don't get a lot baked in, but you probably didn't need it anyways.

Yes. JAX-RS (the standard implemented by Jersey), which is part of the often maligned Java EE, is a (surprisingly?) well designed REST "microframework". Java EE in general has come a long way from the monster it used to be, and is becoming quite pleasant.

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

#26

Post by edwinnathaniel »

pron wrote: post #21
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…

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.

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

#27

Post by pron »

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.

Actually, my favorite bits are runtime linking, JMX, VisualVM and, most recently, FlightRecorder + Java Mission Control, which has to be one of the coolest profilers I've seen. But I was just talking about performance.

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

#28

Post by ebiester »

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 java's poor implementation of OOP ignored.

Heck, fork Spark, split out the individual pieces as modules, and start there.

All "JPM" packages expected to be under 100 lines, a la NPM. Frameworks are discouraged. Take what you need a la carte.

I'd argue that java is a better back end language than javascript in and of itself, but that the community norms have led to the pain we see.

Have an extreme preference for 1.8 code (IE, the new java.time system) and away from anything bloated. Rethink for the common use cases, rather than trying to support everything under the sun. Spring still exists for that, after all. :)

The problem with java isn't that it's a BLUB language anymore, but that it's a BLUB ecosystem. I'm not saying the language is perfect, but Java 8 as good as ruby or javascript for web development if the ecosystem is ignored.

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

#29

Post by cgh »

zabraxias wrote: post #18
cgh wrote: post #12

Earlier quoted context omitted.

Spring is open source. From the sounds of things, they replaced Spring with a closed in-house framework.

"Based on Spring" is not Spring. I worked there for a bit, they called it Sparta, and its appeal to the top tech brass was they could restrict which objects are available for use in the library they provided for you. The subtle message behind it was, we can hire anyone as long as we limit what they can do.

Thanks, I stand corrected. Sounds heinous.

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

#30

Post by zaphar »

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…

Java has always been a good language if you ignored the ecosystem. The ecosystem is a large part of what defines a language though. You have to take care in how you define that ecosystem.

I sometimes wonder if Node.js is making mistakes in the opposite direction as Java with their ecosystem these days.

Post reply on HN