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

71–80 of 216 posts

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

#71

Post by mattgreenrocks »

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.

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.

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

#72

Post by astral303 »

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.

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

#73

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

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

#74

Post by pron »

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

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

#75

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

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

#76

Post by moomin »

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 you want Clojure and leiningen.

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

#77

Post by al2o3cr »

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…

"All "JPM" packages expected to be under 100 lines, a la NPM. Frameworks are discouraged. Take what you need a la carte."

LOL, I'm trying to imagine anything else in life being run like this. For instance, you go to the "car package manager" and are told that all parts must be less than 2kg and that you need to choose which ones you need...

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

#78

Post by Iftheshoefits »

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.

I'd say it's exactly about "maturity" not in the emotional sense, but the "breadth and depth of professional experience" sense.

A lot of the 'glamour' in the Bay Area is around web apps that 20-somethings use. As a consequence a lot of the headlines and centers of discussion are going to be around languages, platforms and paradigms that reflect that. And, these days, that would be dynamically typed languages, frameworks or framework-like 'libraries' and fad-following (which is where the "rock-star-ninja" meme comes from). I just try to filter the noise as best I can to glean the useful and interesting bits of articles and comments I read.

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

#79

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

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

#80

Post by pron »

edwinnathaniel wrote: post #63
pron wrote: post #27

Earlier quoted context omitted.

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

How could I forget? I personally use runtime instrumentation all the time: https://github.com/puniverse/quasar
Post reply on HN