Live data from Hacker News

About PayPal's Node vs Java “fight”

developer-blog.cloudbees.com

101–110 of 216 posts

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

#101

Earlier quoted context omitted.

I take a very cynical view of these things, and from that perspective it doesn't surprise me at all, really. My cynical view is that the "lousy" ones are popular because they are easy even for non-technical people to learn well enough to be useful in the majority of business settings. This sets up a kind of feedback loop: there is an abundant supply of "cheap" labor who can use these languages, which companies love,…

I think its more of the realization that types are actually freaking useful for determining "provability" of a system. C++ perhaps takes it too far with Const, but it allows the compiler to prove that certain functions will not attempt to modify certain variables. Compared to Python or Ruby, you're pretty much relying entirely on culture and good habits to ensure the proper rules of encapsulation. Any code may modify…

I think its more of the realization that types are actually freaking useful for determining "provability" of a system. C++ perhaps takes it too far with Const, but it allows the compiler to prove that certain functions will not attempt to modify certain variables.

There is very little in terms of "provability" that either C++ or its types give you. Proving anything really interesting (for example, the absence of race conditions in concurrent code) still seems like pretty much an arduous process in languages not explicitly designed for such things.

Compared to Python or Ruby, you're pretty much relying entirely on culture and good habits to ensure the proper rules of encapsulation. Any code may modify the private members of your objects. (Granted, C++ has "mutable", Java has the whole "Reflection" loophole as well. But you can search for those edge cases rather easily).

That didn't seem very comprehensible to me, but if you're claiming that in Ruby, you can modify member variables of someone's objects, well, you can't, unless you use reflection as well (not only that, but the access to member variables is object-based, rather than class-based, so you can't access the member variables of an object from any other object, even if they are of the same class, unlike in C++ - so much for the "objects communicate by passing messages" in C++!). More to the point, in C++, you can always cast a pointer into something that makes the raw data accessible. There's enough stuff in C++ for you to blow your whole leg off instead of just shooting yourself into the foot.

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

#102
post #77

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

Except that there is implicit dependency management.

It would be like saying that all SKUs need to be comprised of other SKUs and less than 2kg of screws, nuts, bolts and custom components.

In your analogy the Spring might be an entire engine, spark plugs and all, built as a single unit. Want to use your own spark plugs? Tough luck. You get the whole engine or none at all, or you could just build your own from scratch.

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

#103
post #30

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…

Java has always been a good language if you ignored the ecosystem. The ecosystem is a large part of what defines a language though. You have to take care in how you define that ecosystem. I sometimes wonder if Node.js is making mistakes in the opposite direction as Java with their ecosystem these days.

Java has always been a good language if you ignored the ecosystem.

You mean "no unsigned types (even though the language is essentially machine-level when it comes to integers), no compact memory layouts for aggregate data, no useful function values without jumping through hoops etc." is an approach that leads to good languages?

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

#104

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.

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 is it particularly good as a build system.

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

#105
post #96
post #60

Earlier quoted context omitted.

Even putting aside my great dislike for Scala (which I discussed on HN ad nauseam :)), I think everyone would agree that Scala has a very different philosophy from Java. Java has been designed as a "blue-collar" language, with maintenance of a large project with possibly hundreds of developers as a central guiding principle. C#, Go, Dart, Kotlin, Fantom etc., have a similar philosophy. But Scala is a different beast…

On what do you base your assumption when you say nobody would recommend Scala as a replacement for Java? Scala has actually taken great pains to maintain seemless Java interop for this very reason. It IS an improvement on/replacement for Java in most situations.

That's not what I said. I said that no one would say that Scala can replace Java in all circumstances. Opinions vary greatly on what percentage the appropriate circumstances are (I think Scala is rarely a good replacement and never given the alternatives, while others, like you, say it's a good replacement in most circumstances - but not all).

In short, no one (who knows the software development landscape well, that is) can say Scala (or some other JVM languages) makes Java redundant.

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

#106

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 first saw this in clojure, and thought it came for the builtin immutability of most types. Meaning you can't have order problems with libraries functions, unlike in the mutable world where a framework will shield you a bit.

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

#107
post #96
post #60

Earlier quoted context omitted.

Even putting aside my great dislike for Scala (which I discussed on HN ad nauseam :)), I think everyone would agree that Scala has a very different philosophy from Java. Java has been designed as a "blue-collar" language, with maintenance of a large project with possibly hundreds of developers as a central guiding principle. C#, Go, Dart, Kotlin, Fantom etc., have a similar philosophy. But Scala is a different beast…

On what do you base your assumption when you say nobody would recommend Scala as a replacement for Java? Scala has actually taken great pains to maintain seemless Java interop for this very reason. It IS an improvement on/replacement for Java in most situations.

I strongly contest that assertion. I'd say an honest variation would be the dream of scala is an improvement.

Maybe when some of these new fancy tools like Graal become more polished and ready the dream that was scala can start to happen vs reality you get when using it. I'd be happy to see that happen.

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

#108
post #88

Earlier quoted context omitted.

Except that of all the things you've named, dynamically typed languages are hardly "a fad". It's surprising (?), though, that the lousy ones are the most popular ones.

I take a very cynical view of these things, and from that perspective it doesn't surprise me at all, really. My cynical view is that the "lousy" ones are popular because they are easy even for non-technical people to learn well enough to be useful in the majority of business settings. This sets up a kind of feedback loop: there is an abundant supply of "cheap" labor who can use these languages, which companies love,…

The commoditization of web devs will occur, it's just a matter of when. Consider it the collateral damage from ever-more-powerful frameworks, a de-emphasis on SOLID-type software architecture, and businesses wanting to pay less for developers.

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

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

[deleted]

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

#110
post #98

Earlier quoted context omitted.

I don't think he means java is popular in the "cool" sense. He means it is popular because it is so widely deployed and still in use everywhere.

I agree that Java is widely adopted (thus my 'ubiquitous' comment). The fact that the commenter followed-up immediately with "some of its most painful points have been addressed in Java 8" led me to believe it was referring to being liked and not necessarily to being adopted.

I meant adoption, but mentioned that some of the issues that make it less well liked are being addressed.

I think it possible (though far from inevitable) that another JVM language will achieve dominance on the JVM, and it is very possible that Java will fall below the 60% or even 50% on the JVM (with the rest being taken by several, though not one dominant, languages). But this is still some years in the future.

Post reply on HN