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

171–180 of 216 posts

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

#171

Post by bhauer »

ariq wrote: post #164
bhauer wrote: post #120

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

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

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

As for something I am happy with in recent memory, the Undertow builder model is appealing: 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.

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

#172

Post by katbyte »

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?

just guessing but if all statements are terminated with a ; instead of a newline it allows statements to be split up into multiple lines?

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

#173

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

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

#175

Post by vorg »

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.

> Groovy with Gradle is a pretty good answer that is there today

I've heard many good things about Gradle's functionality, but not so many about Groovy. Only yesterday ( https://news.ycombinator.com/item?id=6884355 ) I asked if Gradle will ever expose an API so developers can use the same language for the build scripts as they do for the projects they're building, i.e. Groovy with Gradle for Groovy projects, and Scala with Gradle for Scala projects?

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

#176

Post by keypusher »

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…

Have you looked at Groovy/Grails/Gradle? You can use the existing Java code and ecosystem or you can choose to do things the new way, you have access to a web framework similar to Rails, it's pretty nice.

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

#177

Post by xandoid »

crypto5 wrote: post #153
camus2 wrote: post #46

Earlier quoted context omitted.

> 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

I believe the core of VoltDB (the in memory storage engine) is written in C++. See here: https://github.com/VoltDB/voltdb/blob/master/src/frontend/or...

"VoltDB mainly consists of Java modules for easier development. However, the core EE and its underlying on-memory storage system is implemented in C++. Nowadays Java and C++ have almost same performance for many cases, but C++ still outperforms Java on low-level memory accesses. This is why we have EE and its storage system written in C++."

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

#178

Post by keypusher »

barrkel wrote: post #158
_random_ wrote: post #149

Earlier quoted context omitted.

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.

That's not true, at least with Python. It uses duck typing, there is no type check before execution. It just runs the code you give it, if you try to call a method that doesn't exist (split on a integer), it will just give an error.

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

#179

Post by Ygg2 »

frowaway001 wrote: post #138
ebiester wrote: post #118

Earlier quoted context omitted.

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

What's wrong with implicits?

Magic.
Post reply on HN