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

151–160 of 216 posts

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

#151

Post by sanderjd »

Iftheshoefits wrote: post #142
sanderjd wrote: post #135

Earlier quoted context omitted.

Alternate theory: "lousy" is a subjective measure, and those languages are popular because in many other peoples' subjective reality, they are not lousy. Just a theory though, by all means, keep thinking that languages are objectively ranked identically to your subjective ranking and anybody using ones at the bottom are just dumb dumbs who are incapable of using the ones at the top.

I didn't rank any languages. I made an observation that it is easier for non-technical people to pick up dynamically typed languages and be productive enough for use in many business cases than to pick up statically typed ones. That doesn't mean the dynamically typed ones are "easier" or "worse" than statically typed ones. It doesn't mean people who prefer them or learn programming with them are "dumb dumbs," either.…

Hmmm, I re-read your comment and its parent a couple times, and maybe I didn't give proper credence to your sarcasm quotes. I do think that your comment strongly implies agreement with the non-sarcasm-quote-using parent comment, but hey, maybe that's really just my reading of it. Your edit also confusingly says that you don't think the "lousy" languages are really any easier than the static languages you prefer, despite your second paragraph seeming to say the opposite. So maybe I'll just bow out of trying to interpret what you think :)

I'll freely admit that it peeves me to no end when people make value judgments based on what programming languages people do and don't like and use, on both sides of the static/dynamic divide, so maybe I do have that chip on my shoulder.

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

#152

Post by Negitivefrags »

kalleboo wrote: post #55
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 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.

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.

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

#153

Post by crypto5 »

camus2 wrote: post #46
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.

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

> Projects where performance is critical are coded in C/C++ , not in java (databases)

HBase, Cassandra, VoltDB

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

#154

Post by devdas »

olavgg wrote: post #146
barrkel wrote: post #104

Earlier quoted context omitted.

C# is Java with perhaps 200% syntax improvement. The things I use most often with e.g. Ruby - monadic collection operations like map, select, etc. - is there in the form of Linq, with select, where, etc. A concise, type-inferred lambda expression goes a long, long way. The .net ecosystem isn't as evolved as Java, for sure. But I don't think maven is a good implementation of a dependency management system either, nor…

Any language today that still requires to mark end of line with a semi colon, has in my opinion outdated syntax. Most people put one statement per line, so why is it required and not optional?

What about the counter case of one statement needing more than one line?

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

#155

Post by yareally »

saryant wrote: post #127
yareally wrote: post #122

Earlier quoted context omitted.

Scala with all of its symbolic notation would be more like Perl than C# is. Scala also can run on .net[1]. [1] http://www.scala-lang.org/old/node/10299

The Scala .NET backend is being deprecated in 2.11.

Hmm, that's too bad. I haven't found a use case myself for needing it on .net, but I can understand it's probably a pain for TypeSafe to maintain it for both the JVM and the CLR.

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

#157

Post by runT1ME »

barrkel wrote: post #104
edwinnathaniel wrote: post #68

Earlier quoted context omitted.

Your package system is inspired by Maven, minus a good build system and other functionalities. Try building a large C# projects with running unit-tests, integration-tests, packaging, code-coverage, code style baked into it, and a bunch of other plugins for your build systems without pulling your hair. Your DateTime library ain't there yet sir so you're pretty much at the same situation with Java (although both ecosys…

C# is Java with perhaps 200% syntax improvement. The things I use most often with e.g. Ruby - monadic collection operations like map, select, etc. - is there in the form of Linq, with select, where, etc. A concise, type-inferred lambda expression goes a long, long way. The .net ecosystem isn't as evolved as Java, for sure. But I don't think maven is a good implementation of a dependency management system either, nor…

>monadic collection operations like map, select, etc

There is nothing 'monadic' about select. SelectMany yes, but not Select. That's equivalent to map in other languages.

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

#158

Post by barrkel »

_random_ wrote: post #149
barrkel wrote: post #104

Earlier quoted context omitted.

C# is Java with perhaps 200% syntax improvement. The things I use most often with e.g. Ruby - monadic collection operations like map, select, etc. - is there in the form of Linq, with select, where, etc. A concise, type-inferred lambda expression goes a long, long way. The .net ecosystem isn't as evolved as Java, for sure. But I don't think maven is a good implementation of a dependency management system either, nor…

And some languages don't check types for you before running the code and it's almost 2014 now, can you imagine?

Ruby, Python, even PHP checks the types of values before executing operations on the values.

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

#159

Post by kylequest »

eddflrs wrote: post #93

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/

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.

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

#160

Post by fat0wl »

fat0wl wrote: post #133
porker wrote: post #128

Earlier quoted context omitted.

> looking at Play as a potential new framework for a CRUD app with a very fancy UI. Do you know of any frameworks that are good for that (but let you easily reach down for complex logic, e.g. where data processing or AI is needed)? Every project I do needs some form of CRUD, and making it work AND be pleasing to interact with takes a lot of time. I don't mind the language, just someone, somewhere must have solved thi…

Hmmm I don't know. I think the conventional wisdom is to use a service-oriented architecture with the best front-end tools you can find. The advantage of JVM in my opinion is that a lot of their toolchains have this approach in mind and simplify integration of the stack. Java can be used for a lot, when you add in other JVM languages that is a lot of possibility. Then again, if you design proper web services you can…

(In fact, for heavy processing stuff I'm pretty sure it's architecturally preferred to have it on a separate machine than the web-app server)
Post reply on HN