
About PayPal's Node vs Java “fight” - stephenconnolly
http://developer-blog.cloudbees.com/2013/12/about-paypal-node-vs-java-fight.html
======
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.

~~~
radicalbyte
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.

~~~
mattgreenrocks
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.

~~~
ebiester
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.

~~~
mattgreenrocks
Do you know of any shops that use Uncle Bob's approach (besides 8th Light, of
course)? I don't; I wish I did. I agree that isn't something you'd use every
time, but I feel there isn't a whole lot of data out there when people have
used it. All I see online are devs whining about the extra work.

I don't know what it is about the web, but it's as if we decided all of
software architecture didn't mean anything and threw it out. My theory: it's
harder to feel coupling in a dynamic language, thus it's just an academic
concern!

~~~
ebiester
I have plans to try it in a side project. I too am skeptical about the rewards
of setting up a CRUD system like that.

It isn't that we've decided that software architecture meant nothing; rather,
we settled on one architecture that is Good Enough. The View/Controller/Domain
paradigm of Rails works for many projects.

~~~
mattgreenrocks
It won't be great for CRUD. It's really meant for applications that have a
bunch of business logic to them...you know, the interesting apps.

Aside: "good enough" seems to summarize the web as a whole. This is both
discouraging and a fact of life.

~~~
ebiester
You can still have an interesting business logic system that is CRUD at its
core. A case management system, as an example, is CRUD at its basis but filled
with business logic.

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

~~~
ariq
Whose Java SDK would you rate at the top 10%? I'm curious.

~~~
bhauer
Just to compare apples to apples—by which I mean credit card payment
APIs—Stripe's Java API is superior. I'd not say it's a thing of beauty, but
then, I don't want a credit card payment API to be anything but immediately
approachable and obvious. And it is precisely that. Easy to understand.

[https://stripe.com/docs/api/java](https://stripe.com/docs/api/java)

As for something I am happy with in recent memory, the Undertow builder model
is appealing: [http://undertow.io/](http://undertow.io/)

But you ask a tough question. I've not spent much time thinking about the best
of the best. I suppose part of it is that a great API gets out of its own way
and lets you get to work. So I suppose citing Stripe's first may have been the
right thing.

------
sehrope
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 to be mostly waiting for external resources (DB, message queue, etc).

Without knowing how much time is spent on those external requests these
numbers are meaningless.

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

If every request you process involves serially accessing a 50-100ms external
resource four or five times then it will always take 250ms ( _though you could
increase parallelism of multiple requests if done right_ ).

~~~
kalleboo
> 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.

~~~
Negitivefrags
It only gets worse from there.

When we exported a CSV of our transaction history there were entries missing.
We knew this because each line has a running balance and it wasn't adding up
with the line before it.

When we told our paypal account manager about this it triggered an
investigation. They claimed they had never seen it before and they sounded
very worried about it.

They then told us that they have multiple different databases with transaction
histories and that they were not consistent. They said that they had
investigated the problem and found that it affected only a small percentage of
customers.

They then pointed us to another CSV export form that doesn't seem to be able
to be accessed via the normal UI and were told that this one would give us
correct results. Unfortunately we were unable to export an entire year at once
with this form as it seems to have some kind of time limit.

We had to export our history in little chunks that would take hours each. We
asked our paypal account manager to prepare the CSV for us after finding this
out, but she refused.

Having a large number of transactions in paypal sucks very bad.

Compare this to Stripe that proactively emailed us saying that they had
noticed that queries for filtered transaction sets were taking a very long
time so they had done some optimizations and were asking us to see if it had
improved.

------
srean
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 time.

Java can indeed be very fast, and in my opinion JVM is the one of the most
optimized VMs that we have now. That said Java code beating a C or a C++ code
on a CPU bound task raised an eyebrow. In my experience Java usually gets to
the 80% speed of C++ quite easily but at a cost of 2.5 to 3.5 the memory. For
these types of applications memory tends to be an expensive resource. For our
number crunching server, 80% of its cost is sunk in the RAM.

~~~
pron
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).

~~~
edwinnathaniel
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.

~~~
camus2
> 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.

~~~
pron
> Projects where performance is critical are coded in C/C++ , not in java (
> browsers , AAA games , databases , servers , micro-controllers , oses... ).

This is not true. C++ beats Java performance _in constrained environments_. On
servers the situation is not so clear-cut. You see some really fast Java
databases.

And BTW, Java is better at inlining functions than C++, but C++ handily beats
Java when it comes to controlling memory layout (though that, too, is
changing).

~~~
camus2
> This is not true. C++ beats Java performance in constrained environments

Every environment is constrained. Devs just got lazy and scaling now means
buying more machines instead of performance optimisation.

> You see some really fast Java database

That eat up way to much memory for little.

When you see popular java based os , tell me.

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

~~~
curun1r
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.

~~~
bad_user
> _Node is pervasively asynchronous_

Personally I view that as a drawback. It's all fine, until you end up with
CPU-bound tasks or until you end up talking with backend servers that don't
support many concurrent requests.

The JVM support for multi-threading is absolutely stellar. You've got true 1:1
kernel-level threading, with no GILs and you've got access to the best
primitives available for dealing with multi-threading issues, atomic
references, re-entrant read-write locks, fork-join thread-pools, non-blocking
data-structures, asynchronous I/O guaranteed to work well cross-platform, all
of them backed by a guaranteed memory model that also works well cross-
platform, plus garbage-collectors that are the most advanced garbage
collectors in mainstream usage. G1/CMS are amazing for servers and if you've
got cash to spend, Azure's pauseless GC is probably as close to real-time as
you can get with a GC.

And on top of these you can build whatever concurrency handling architecture
you want. Including Erlang-style Actors (e.g. Quasar, Akka), STM (Clojure,
Scala-STM), persistent data-structures (Clojure, Scala), asynchronous streams
(Play2's Iteratees, RxJava Observables, Scalaz Machines, Scalaz Streams).

Even when speaking of Node.js's strengths, like asynchronous I/O, I still
think Java is better because of the foundations (e.g. NIO, Netty, Mina). The
only reason people don't work much with asynchronous workflows is because the
language is so freaking painful for that. But that will change with Java 8 and
people are doing wonders in Scala/Clojure.

I've personally built an entire web-service, designed to handle thousands of
requests per second per frontend instance, with responses generated in under
30ms, with a completely asynchronous workflow, on top of Scala/Akka/Play2.
Node.js people don't know what they are missing.

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

~~~
mtrimpe
I'm pretty good with Spring and have even given trainings on it and I'd argue
that Spring's main problem is that it needs to be seen in the right context: a
poor man's DSL for declarative system configuration (it _is_ last 10 years old
after all.)

That it creates untestable applications seems like completely nonsensical FUD
however since the _entire_ point of Spring is to keep code easily testable.
Spring is an almost direct response to the lack of testability of the
ServiceLocator anti-pattern.

I'm not saying you can't make untestable code in Spring, but if you do the
problem is most likely more with the people than with Spring.

~~~
penland
I've done a lot of Spring side work and your first paragraph is the best
explanation I've ever read for the framework.

I also agree that if you can't test Spring code you are doing something wrong.
I get the frustration with having to create test harnesses for some things,
and the SpringJ4Unit stuff oftentimes feels a bit too magical, but I've never
seen well written Spring code that wasn't easily testable at the both the
class and module functionality layer.

~~~
ExpiredLink
With Spring you can easily test your empty mocked-out shells. Great!

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

~~~
kcmarshall
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...

------
nswanberg
This reads like someone reading a 1995 article about a company switching from
writing Netscape Enterprise Server code in C++ on a Windows machine to Apache
code in perl on a Sun server, and then writing a defense of the x86 processor
against SPARC.

I might have missed something but I don't recall the original PayPal article
arguing that the switch was motivated by moving from a slow virtual machine to
a faster one.

But just as switching from C++ to perl would trade some computing power for
productivity in getting a site built, I don't see it as controversial for an
organization to say they achieved the same productivity gains going from java
to javascript.

------
spullara
Two poorly written apps compared with blame for each placed on the underlying
virtual machine rather than the part between the chair and the keyboard. I'd
much rather compare VMs and systems with something a little more structured
and open like the TechEmpower benchmarks. They still have their flaws and
simplifications, but at least the source for all apps is open and you can see
and contribute to them.

------
_random_
That is a refreshingly sober point of view. Blaming frameworks is easy.
Speaking of technical debt is hard.

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

~~~
dangrossman
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.

~~~
lampe3
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...

~~~
dangrossman
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.

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

------
kylequest
What a shocker... a Java guy says that you shouldn't abandon Java :-)

Lots of wild speculations... especially about the reasons PayPal picked
node.js/JavaScript instead of a Ruby stack. He says that Ruby wasn't chosen
because you can run it on JVM ignoring the fact that you can run JavaScript on
JVM too using DynJS (he actually mentions DynJS earlier in his blog post).

------
peter_mcrae
First post on HN. I'm not entirely sure how the PayPal Node vs. Java message
has been packaged, but I think there is a lot of confusion. From my
understanding (via blogs and conferences), Node was used to replace Java on
the front-end. Meaning, the Node front-end is still calling Java + other
stacks upstream -- which likely explains the performance benchmarks (the
front-end wasn't the bottle neck). That said, even with similar performance
benchmarks, I can see how Node might result in higher developer productivity
for the front-end components of PayPal -- hence the enthusiasm they are
showing. Lot's of negativity and blame on this thread, but I think it's
because people are making assumptions.

------
jroseattle
This is more about PayPal's dirty laundry than an comparative evaluation of
technologies. If a collective set of tools are used improperly, comparisons
beyond the context of those walls means very little.

------
tn13
In our first lecture at graduate college, the prof told us how to read
research papers.

Rule 1 : Louder the guest shouts of his honor, faster you should count your
spoons.

Similarly if someone tells you about 50% savings just because you switched to
some other technology you should be extremely skeptical. Besides those people
who engage in `Node vs X` debate every now and then should spend some time
educating themselves about compilers and interpreters to understand what makes
some programming languages faster than others in certain circumstances.

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

~~~
cloverich
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.

~~~
goostavos
>The one thing that has consistently surprised me is how productive I feel
writing Java.

I know exactly how you feel. I recently moved from a Java project to a Python
one and felt a little amiss without the power that an IDE gives a statically
typed language. The tooling for Python flat out sucks. And it pains me to say,
as I love the language to death, but I do feel more productive in other
languages. Whether or not that's true is another thing entirely, but it does
feel like a lot of time is wasted calling `dir` on objects to figure out what
the hell the name was of the function you need.

As of about a week ago I switched from my text editor + console to Eclipse +
PyDev. It's not perfect -- intellisense functionality is really hit or miss,
but it _does_ make me feel a lot more productive. The background linting is
pretty good at catching basic errors as you type them, which is _really_ nice.

It's also does an OK job at renaming things -- which is generally a nightmare
to do on a big project in Python.

So, point being, while I miss a lot of the other tooling that an IDE affords a
statically typed language, PyDev gets you, like, 80% of the way there. Worth
checking out if you move back to Python.

~~~
andybak
Pycharm>Pydev by many accounts.

------
neakor
Application based comparisons are usually flawed, because the writer will
never and cannot release enough info to reveal the real problem. Just because
your bad-performing application runs faster on one platform doesn't
necessarily mean that platform is superior to the old one. It simply means
whatever problems you have in your bad-performing application manifests less
in the new platform. In the end, fix your application!

------
api
TL;DR:

* Micro-benchmarks don't provide a good picture of real system performance and can be skewed to make almost anything look better/worse than anything else.

* Much of Java's "slowness," clunkiness, large amounts of boilerplate code, etc. is the fault of the Java ecosystem and libraries rather than the language itself or the JVM.

* The inverse is true for Node: the quality of its ecosystem helps make up for language and runtime shortcomings.

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

------
Joeri
Maybe we should assume the best instead of the worst. We could assume that
paypal has capable developers who are knowledgeable about both the jvm and
node.js, and who have concluded that their specific featureset can best be
built using node. That is not a value judgment of the jvm vs node in general,
as their situation is theirs and theirs alone.

------
coolsunglasses
Lots of people trying to unblub blub.

I'd venture a guess that mimicking Node.js isn't going to fix the deeper
problems with Java.

------
pkolaczk
So far I tried compiling some of my numeric Scala code to JS with Scala.JS and
unfortunately running that code in Chrome is much, much slower (~10-20 times)
than running the original version on Java 7. :( Not sure if it is because
Scala.JS creates poor code, or just JS is still not as fast as they claim.

~~~
virtualwhys
Current version of Scala.JS is an alpha release, don't expect miracles.

------
puppetmaster3
I think it comes to this: Java > JavaScript. But Java programmer < JavaScript
programmer, due to culture. (ex: Spring, Maven, EJB light).

If Java programmer is true polyglot, then whatever tool you are using wins.
That's why C programmers are the best.

------
eddflrs
Does anyone know how vertx[1] fits into this picture? It gives you the JVM,
JavaScript, and non-blocking I/O.

[1]: [http://vertx.io/](http://vertx.io/)

~~~
kylequest
Nodyn is an effort to run node.js apps on top of Vert.x. JavaScript alone is
not enough to make Vert.x popular for node.js people. You need to be able to
leverage the node.js module echosystem. Hopefully Nodyn will do that, so you
can use your favorite node modules on Vert.x. It's still a work in progress
though.

~~~
eddflrs
Cool, Nodyn looks interesting. Thanks for the info.

------
exabrial
Incredible insight... Here's the TLDR: Everything is faster when you engineer
it a second time. Rewriting in a different language is not an apples to apples
comparison.

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

~~~
wpietri
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.

------
abritishguy
Damn, paypal really suck at making fast sites.

------
puppetmaster3
Summary: Most frameworks sux.

~~~
zabraxias
Wrong. PayPal refuses to use open source frameworks because of an internal
culture (and self preservation interest) of some very old "architects" who
really only care about being in charge of the next internal framework. The
best part is they later get to showcase how much better the new one is
compared to the old framework, even though it's multiples slower than the
slowest open-source counterpart.

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

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

~~~
mattgreenrocks
That's atrocious.

One thing I'll never understand is how companies get so hungry for developers
that they subconsciously admit to hiring amateurs: "well, Joe _can 't_ do too
much damage!"

