Live data from Hacker News

About PayPal's Node vs Java “fight”

developer-blog.cloudbees.com

61–70 of 216 posts

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

#61
post #56
post #32

Earlier quoted context omitted.

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 pretty great, but one unfortunate aspect is that it's stuck with Jersey 1.x for JAX-RS and as a result is missing some nice features, like async responses, etc.

I only used it as an example to the fact that modern Java libraries bear little resemblance to those of yesteryear.

I do, however, think that standard JSR APIs are still really nice to have, if they're good.

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

#62
post #46

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…

I'm referring to the tools that ensure the code quality, not the performance critical aspect of it.

Besides, all of the projects I've worked for has no FactoryFactories so let's cut that song right here right now.

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

#63
post #27

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.

Actually, my favorite bits are runtime linking, JMX, VisualVM and, most recently, FlightRecorder + Java Mission Control, which has to be one of the coolest profilers I've seen. But I was just talking about performance.

Don't forget the javaagent and the ability to instrument JVM. Event .NET/CLR doesn't have that (They have some low-level COM/Profiler API but boy that takes a lot of effort to work with).

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

#64
post #12

Earlier quoted context omitted.

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

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

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

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

#65

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

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

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

#66
post #25
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.

Yes. JAX-RS (the standard implemented by Jersey), which is part of the often maligned Java EE, is a (surprisingly?) well designed REST "microframework". Java EE in general has come a long way from the monster it used to be, and is becoming quite pleasant.

You can use Servlet + Jersey. It's just one dependency away and minimal web.xml config (or spring-jersey...whichever). It's not necessarily tied to Java EE albeit Java EE app-server _must_ implement JAX-RS properly.

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

#67

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.

I also like to know more about this C# package system you mentioned.

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

#68

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.

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 ecosystems have NODA/JODA lib).

C# is just Java with 10% syntax improvement and -30% to -40% productivity lost when it comes to everything else.

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

#69
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…

[deleted]

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

#70

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.

I also like to know more about this C# package system you mentioned.

I would imagine he's talking about NuGet. Unless I've missed something dramatic in the past half year in the .net ecosystem.
Post reply on HN