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

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

#41

Post by wpietri » Fri, Dec 13, 2013, 6:48 PM UTC

smoyer wrote: post #6

Management won't take the blame but ... who allowed the architects/engineers to build two systems that failed the same way?

I agree that management is likely a problem here, but disagree with the framing.

If you're in a structure where management's job is to allow/deny, then I think the code is already doomed. Software development is work that can't be effectively micromanaged.

In software, I think management's job is to support and challenge. All the people coding should be professionals, thoughtful and aware of issues like tech debt, second-system effects, reinventing the wheel, and so on. Management's job isn't to be more professional than the pros; it's to support the pros and make sure they're living up to (and sometimes advancing) their professional standards.

I'm sure there are plenty of people who work with these frameworks that know that they're crap. Management didn't fail by allowing these to get built. They failed by creating power relationships that allowed the people who couldn't see the problems to control the building of the frameworks, and to suppress criticism and improvement.

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

#42

Post by cloverich » Fri, Dec 13, 2013, 6:51 PM UTC

fat0wl wrote: post #40

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" 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...

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

#43

Post by dangrossman » Fri, Dec 13, 2013, 6:51 PM UTC

lampe3 wrote: post #35

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 i…

You're getting downvoted because this isn't a "language X vs language Y" article at all. Its point is that the language choice doesn't matter when you're building on top of crap, and jumping from one language to another probably won't solve platform problems. It's an article about the politics of being a software developer in enterprise where management is entrenched in legacy codebases, not about language features.

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

#44

Post by radicalbyte » Fri, Dec 13, 2013, 6:56 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…

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.

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

#45

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

dangrossman wrote: post #43

lampe3 wrote: post #35

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 i…

You're getting downvoted because this isn't a "language X vs language Y" article at all. Its point is that the language choice doesn't matter when you're building on top of crap, and jumping from one language to another probably won't solve platform problems. It's an article about the politics of being a software developer in enterprise where management is entrenched in legacy codebases, not about language features.

What? the first part is exactly that... for example: "So which is the faster virtual machine, V8 or JVM? My belief is that when you are coding in the most basic building blocks of either virtual machine (i.e JavaScript vs JVM Byte Code) that the JVM will win out every time. If you start to compare higher up, you may end up comparing apples with oranges and see false comparisons. For example, if we consider this comparison of V8 vs JVM performance at mathematical calculations. This blog post tells us that if we relax our specifications we can calculate things faster. Here is the specification that V8 must use for Math.pow and here is the specification that the JVM must use for Math.pow notice that the JavaScript specification allows for an “implementation-dependent approximation” (of unspecified accuracy) while the JVM version has the addition that"

and at the second part too: "... a limit of Node.js itself when used with the backing APIs that they have to call through to."

It's just hidden better... to me it reads like a java fan boy is crying why a company switched to language X from his language Y...

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

#46

Post by camus2 » Fri, Dec 13, 2013, 7:01 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.

> how many C++ projects do that out there? Not as many as the Java counterpart.

I'm not sure this is a good argument.

Projects where performance is critical are coded in C/C++ , not in java ( browsers , AAA games , databases , servers , micro-controllers , oses... ). C/C++ programming is not about writing 'elegant' code with FactoryFactories , but performances. Even if it means using very basic data structures instead of classes or inlining functions everywhere.

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

#47

Post by cloverich » Fri, Dec 13, 2013, 7:02 PM UTC

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…

I wonder if someone has written up comparisons on their productivity between the languages / frameworks. My previous job had me on the python stack (Pyramid / Mako / Sqlalchemy), which I loved, but have been on Java / Play! framework for the last 10 months. The one thing that has consistently surprised me is how productive I feel writing Java. Mainly, I notice I make far fewer mistakes / typos while coding; the IDE does a great deal of the work for me, and as the application grows, having static types has (for me) improved the readability of code I haven't looked at for a while.

No doubt a large part of any language choice is subjective, but I'm starting to believe that developer productivity has more to do with the tools and frameworks than the language itself. As these continue to improve in Java-land, I'm willing to bet that the disparity in productivity will continue to decrease.

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

#48

Post by [deleted] » Fri, Dec 13, 2013, 7:04 PM UTC

fat0wl wrote: post #40

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" languag…

[deleted]

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

#49

Post by runT1ME » Fri, Dec 13, 2013, 7:04 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…

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

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

#50

Post by dangrossman » Fri, Dec 13, 2013, 7:05 PM UTC

lampe3 wrote: post #45

dangrossman wrote: post #43

Earlier quoted context omitted.

You're getting downvoted because this isn't a "language X vs language Y" article at all. Its point is that the language choice doesn't matter when you're building on top of crap, and jumping from one language to another probably won't solve platform problems. It's an article about the politics of being a software developer in enterprise where management is entrenched in legacy codebases, not about language features.

What? the first part is exactly that... for example: "So which is the faster virtual machine, V8 or JVM? My belief is that when you are coding in the most basic building blocks of either virtual machine (i.e JavaScript vs JVM Byte Code) that the JVM will win out every time. If you start to compare higher up, you may end up comparing apples with oranges and see false comparisons. For example, if we consider this compa…

Your analysis is too shallow. The only reason he attempts to compare node.js to Java at all is to reach his point: that the decision was probably more about company politics than tech benefits. The team used a different language not because it's better or worse, but because it'd allow them to avoid building on top of the existing framework -- a chance to get rid of technical debt and start a fresh code base, even if just a seed.