News for hackers. Stuff that matters.
Re:About PayPal's Node vs Java “fight” by edwinnathaniel on Friday December 13, 2013 @01:15PM (#6901960)
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.

Re:About PayPal's Node vs Java “fight” by camus2 on Friday December 13, 2013 @02:01PM (#6902207)
> 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.

Re:About PayPal's Node vs Java “fight” by pron on Friday December 13, 2013 @02:57PM (#6902560)
> 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” by camus2 on Friday December 13, 2013 @09:10PM (#6904228)
> 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.

Re:About PayPal's Node vs Java “fight” by edwinnathaniel on Friday December 13, 2013 @02:35PM (#6902420)
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” by crypto5 on Friday December 13, 2013 @07:15PM (#6903721)
> 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” by xandoid on Saturday December 14, 2013 @03:37AM (#6905147)
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” by pron on Friday December 13, 2013 @01:17PM (#6901973)
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.
Re:About PayPal's Node vs Java “fight” by edwinnathaniel on Friday December 13, 2013 @02:37PM (#6902434)
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” by pron on Friday December 13, 2013 @03:07PM (#6902623)
How could I forget? I personally use runtime instrumentation all the time: https://github.com/puniverse/quasar
Re:About PayPal's Node vs Java “fight” by edwinnathaniel on Friday December 13, 2013 @05:03PM (#6903167)
Sorry I don't mean to hijack thread or anything like that but I work for AppNeta and we're on the APM field instrumenting various platforms. If you ever need an instrumentation tools for your full-stack infrastructure, check us out :).
Re:About PayPal's Node vs Java “fight” by jkrems on Friday December 13, 2013 @01:25PM (#6902012)
Almost agree, but minor nitpick: the tools and infrastructure (at least most of them) exist on other platforms in the same or better quality as well. Especially dependency management is not necessarily a strong side of Java (one global namespace for types etc.).
Re:About PayPal's Node vs Java “fight” by pron on Friday December 13, 2013 @01:32PM (#6902041)
> one global namespace for types

I am not entirely sure what you mean by that, but in Java, a runtime type is determined as a combination of its name and its class-loader. You can (and do) have two versions of the same class running alongside one another in different modules of your code.

Granted, supporting this stuff is not easy, but hopefully the long awaited module system planned (currently...) for Java 9 is supposed to make this all both powerful and easy.

Re:About PayPal's Node vs Java “fight” by cgh on Friday December 13, 2013 @01:39PM (#6902087)
Well, the OSGi module system supports this now and is quite powerful. Oh wait, you also said easy.