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

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

#111

Post by ebiester » Fri, Dec 13, 2013, 9:24 PM UTC

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.

Has the Mono story gotten better? How feasible is it to develop without thousands of dollars of Microsoft software these days?

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

#112

Post by WildUtah » Fri, Dec 13, 2013, 9:32 PM UTC

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.

"You've basically described C#"

Unfortunately the CLR doesn't run on any useful platforms.

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

#113

Post by curun1r » Fri, Dec 13, 2013, 9:34 PM UTC

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.

The biggest contributor to performance issues these days, from what I've seen, is synchronous code. The JVM can be blindingly fast at running your code, but when it hits a point where you make a database call or web services call that's implemented synchronously, it sits there, waiting, doing nothing. No amount of VM optimizations can increase of the speed of idling code.

This is why Node apps often out-perform Java apps despite running on a VM that's significantly slower. Node is pervasively asynchronous...it's baked into the DNA of the platform and almost all libraries follow that philosophy. And as organizations move to a micro-services architecture where one external call can result in multiple internal calls between systems, the need for reactive, asynchronous programming becomes all the more glaring.

That's where this critique, for me, fell down. It's spent too much time comparing the JVM to V8 and not enough time talking about how the applications being run were designed. Because CPUs are fast enough these days that any of the VMs will give you decent performance for workloads that aren't CPU-bound as long as you, the application designer, do the right thing. It's just that some environments, Node in particular, make it easier to do the right thing. This will get easier in Java with the introduction of lambdas in Java 8 and the inevitable asynchronous community frameworks and libraries, but right now it's still harder to write reactive applications in Java than it is in Node.

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

#114

Post by UK-AL » Fri, Dec 13, 2013, 9:39 PM UTC

ExpiredLink wrote: post #36

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

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

What? Any system with separated modules is going to have dependencies. At least with DI, classes are written to a interface and different versions easily be swapped in and out.

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

#115

Post by ebiester » Fri, Dec 13, 2013, 9:40 PM UTC

mattgreenrocks wrote: post #71

radicalbyte wrote: post #44

Earlier quoted context omitted.

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.

The "libraries over frameworks" notion is something I keep noticing in communities that seem to be more engineering-minded than rock-star-ninja-dev-minded. Where do you think this comes from? I think it's a mix of maturity on the part of the community members along with how often the language is used to do things that are harder than CRUD.

In my case, I'm speaking of a reaction to Spring and Struts. I personally use Grails on my recent projects, which is as close to batteries-included as it gets, but I occasionally have problems with square peg round hole problems, and fighting against a framework is more painful than a library.

The problem with the framework is that we run into a steep hill when we must diverge off the path. A good framework gives a great story. Unit tests, integration tests, consistent layers, convenient and powerful ways to access the database without writing a giant SQL generator (if x return "and b.id = c.id" else return "b.name = "%" + name + "%")...

But then, you hit the use case that the framework didn't consider. And suddenly, you either need to extend the framework (never pleasant) or go outside the framework for one portion, which means building all of the tools from the ground up.

Or, more often, ignore testing, hack in the best way you know how, and hope nothing breaks.

The library approach means that you have to build the integration pieces yourself. This is painful, but it means that when you reach a new use case, it isn't as large a jump to keep going.

Each has tradeoffs. There are times when each is superior. Someone like Bob Martin would suggest that you build your system independent of frameworks and treat the web as a client/compatibility layer, and that you build your system of small composable parts so that the framework/library question is a minor one. (This has its own tradeoff with an abhorrent amount of plumbing code that comes along.)

It all comes back to the problem at hand and how we judge the tradeoffs, like most engineering problems.

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

#116

Post by UK-AL » Fri, Dec 13, 2013, 9:43 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…

Would really prefer java over php and JavaScript.

Closure, python, c#, f# over Java. But I quite like the java ecosystem. There's normally library for anything.

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

#117

Post by ebiester » Fri, Dec 13, 2013, 9:47 PM UTC

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 a bit heavy by Node standards. The health checks, in the NPM-style system, would be its own package. The configuration class would be its own package. Resources would be their own package. Liquibase or Freemarker wouldn't be built in, nor would JDBI.

I think of Dropwizard much like express for node, and most of the "cool kids" in the node community think that that's just too much for a single library.

I like Dropwizard, don't get me wrong, but it isn't quite a micro-framework by other standards.

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

#118

Post by ebiester » Fri, Dec 13, 2013, 9:53 PM UTC

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.

Implicits, SBT being anything but simple, and compile times. :) People have suggested sticking to a subset of Scala for most purposes, but what happens when you run into a problem with a library? Suddenly, you're diving into Slick (from a friend's example) or Play (from a personal, painful example) and can't make heads or tails of the code because of how different the paradigm is.

Frankly, I'd rather just go to Erlang and skip all the compromises needed to stay with the JVM if I want that kind of language.

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

#119

Post by ebiester » Fri, Dec 13, 2013, 9:57 PM UTC

astral303 wrote: post #72

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…

Groovy with Gradle is a pretty good answer that is there today. Gradle way way way easier to work with than with Maven for your build system, publishes packages with dependency info, so you still get your dependencies sorted OK. Groovy has automatic setters/getters, a ton of functional-style helpers (closures, etc), dynamic & static mixins, delegates, etc.

My day job is in grails. :) However, some shops still have an aversion to other JVM languages.

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

#120

Post by bhauer » Fri, Dec 13, 2013, 9:58 PM UTC

I've had the misfortune of using the PayPal Java SDK to integrate PayPal credit card and Express payment into a web application. Based on that experience, I find it especially difficult to digest any opinion that PayPal has on Java. They may be experts on handling money, processing credit card payments, fraud prevention, and the like. (Or maybe not, given their reputation.) But their opinion on Java is about as meaningful to me as Microsoft's opinion on Java. Or more on point, a Rails developer's opinion on Java. Both are characteristically stale. And not "whew, that bread is really ripe, throw it out" stale. Rather, "what we have here is a new form of fungal life" stale.

I've worked with a fair number of Java APIs. I would put the quality of their Java SDK in the bottom 10%. It has the stench of really old Java. Remember how the first Java APIs reeked of C? The fact that the PayPal Java SDK still looked like hastily ported C code in 2011 when I last worked with it makes me worry that their entire manner of using Java is stuck in the early 2000s. That's being generous. It's the kind of Java you'd expect to see written by a company that still thinks about "applets" and "beans" and tries to come up with clever coffee double-entendres for their package names.

My theory: PayPal is big but they know they are vulnerable. They've acquired BrainTree and that helps. I suspect they want to improve their technical chops and felt a need to migrate away from Java in order to break free of their organizational quagmire. PayPal is from 1998 and if their Java SDK is any indicator, they probably have a Subversion commit log for their core systems going all the way back.

This sort of move is the kind of thing I could see myself doing if I were in a decision-making position at PayPal. Attempting to invigorate sensible modern Java practices within that organization would seem hopeless. I would have to start anew with an approach that is free of poisonous legacy.

As others have pointed out, the fact that a rewrite yielded so little performance gain is decidedly troubling. At least they got a fun and well-linked blog entry out of it. If I had just gone through that effort and reaped such a modest improvement, I'd be crestfallen.