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 java's poor implementation of OOP ignored.
Heck, fork Spark, split out the individual pieces as modules, and start there.
All "JPM" packages expected to be under 100 lines, a la NPM. Frameworks are discouraged. Take what you need a la carte.
I'd argue that java is a better back end language than javascript in and of itself, but that the community norms have led to the pain we see.
Have an extreme preference for 1.8 code (IE, the new java.time system) and away from anything bloated. Rethink for the common use cases, rather than trying to support everything under the sun. Spring still exists for that, after all. :)
The problem with java isn't that it's a BLUB language anymore, but that it's a BLUB ecosystem. I'm not saying the language is perfect, but Java 8 as good as ruby or javascript for web development if the ecosystem is ignored.
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.
Unfortunately the CLR doesn't run on any useful platforms.
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.
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.
While I really like JAX-RS, the reference impl Jersey uses HK2 for dependency injection, which makes it odd to integrate into a Guice application (in fact Guice support is still lacking with Jersey 2.x).
I think of Dropwizard much like express for node, and most of the "cool kids" in the node community think that that's just too much for a single library.
I like Dropwizard, don't get me wrong, but it isn't quite a micro-framework by other standards.
I sometimes wonder if Node.js is making mistakes in the opposite direction as Java with their ecosystem these days.
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?
The issue with these other frameworks/languages is that even when modern frameworks are used there are usually some Java backend services (or another "powerful-outside-of-the-web-also" language) if the app does anything substantially complex. A ton of the hip web tech is basically for building front-end and cobbling together relatively inefficient backends.
I was an RoR guy myself but moved to Java & I see the correct hipster tech here but just lacking unanimity. I bet if the RoR community decided "Clojure hell yea" or "Scala hell yea" and contributed lots of plug-ins to those ecosystems, they would generally have similar development times with a lot of performance gain for free. I'm thinking about trying Play framework on Heroku just to see what the monthly bills & New Relic readouts look like in comparison.
[1]: https://groups.google.com/forum/#!searchin/play-framework/pl...
Also, Java is extremely popular, and some of its most painful points have been addressed in Java 8. Even an arguably better language (regardless of its name) will not easily replace Java. Hey, look across the browser at JavaScript. There are arguably better languages there; are they replacing JavaScript?
If you look just at GitHub – which is greatly skewed towards new languages – you see that all other JVM languages put together make about 10% of the JVM ecosystem, with Java being the 90%. Outside of GitHub, in "the real world", the situation is even more strongly in favor of Java. I don't know if this is going to change much in the next few years.
I don't mean that you shouldn't use an alternative JVM language if it makes your work better, and there are many viable and very useful alternate JVM languages – personally, I like Clojure and Kotlin – but you can't just "replace" Java so easily. I think efforts to reform the Java ecosystem are more likely to succeed – at least in the short term – than efforts that require switching to a different JVM language.
Frankly, I'd rather just go to Erlang and skip all the compromises needed to stay with the JVM if I want that kind of language.
I'd rather work with a language that _i_ don't fully understand (modersky seems to provide me with an infinite supply of intellecutal challenges) than with a language that gives me reason to doubt that it is fully understood by the people who made it.
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?
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...
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.
Then why not just use Rails for Java, i.e. JRuby ?
> 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 to be mostly waiting for external resources (DB, message queue, etc).
Without knowing how much time is spent on those external requests these numbers are meaningless.
Language choice is no where near as important as your DB-access patterns (and more generally DB performance, caching, etc).
If every request you process involves serially accessing a 50-100ms external resource four or five times then it will always take 250ms (though you could increase parallelism of multiple requests if done right).
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.
When we exported a CSV of our transaction history there were entries missing. We knew this because each line has a running balance and it wasn't adding up with the line before it.
When we told our paypal account manager about this it triggered an investigation. They claimed they had never seen it before and they sounded very worried about it.
They then told us that they have multiple different databases with transaction histories and that they were not consistent. They said that they had investigated the problem and found that it affected only a small percentage of customers.
They then pointed us to another CSV export form that doesn't seem to be able to be accessed via the normal UI and were told that this one would give us correct results. Unfortunately we were unable to export an entire year at once with this form as it seems to have some kind of time limit.
We had to export our history in little chunks that would take hours each. We asked our paypal account manager to prepare the CSV for us after finding this out, but she refused.
Having a large number of transactions in paypal sucks very bad.
Compare this to Stripe that proactively emailed us saying that they had noticed that queries for filtered transaction sets were taking a very long time so they had done some optimizations and were asking us to see if it had improved.
i'm pretty sure the paypal node app does not directly access the db , the node app talks to a private api.
I've worked with a fair number of Java APIs. I would put the quality of their Java SDK in the bottom 10%. It has the stench of really old Java. Remember how the first Java APIs reeked of C? The fact that the PayPal Java SDK still looked like hastily ported C code in 2011 when I last worked with it makes me worry that their entire manner of using Java is stuck in the early 2000s. That's being generous. It's the kind of Java you'd expect to see written by a company that still thinks about "applets" and "beans" and tries to come up with clever coffee double-entendres for their package names.
My theory: PayPal is big but they know they are vulnerable. They've acquired BrainTree and that helps. I suspect they want to improve their technical chops and felt a need to migrate away from Java in order to break free of their organizational quagmire. PayPal is from 1998 and if their Java SDK is any indicator, they probably have a Subversion commit log for their core systems going all the way back.
This sort of move is the kind of thing I could see myself doing if I were in a decision-making position at PayPal. Attempting to invigorate sensible modern Java practices within that organization would seem hopeless. I would have to start anew with an approach that is free of poisonous legacy.
As others have pointed out, the fact that a rewrite yielded so little performance gain is decidedly troubling. At least they got a fun and well-linked blog entry out of it. If I had just gone through that effort and reaped such a modest improvement, I'd be crestfallen.
I spent some time at PayPal and, one thing I think is being lost in all of these discussions is exactly what was "fixed."
All your points on introducing new practices to an older, establish (in the company) framework and technology are spot on. I see this as more a way to shake things up and improve things under the guise of new tech.
Also, this is in the top-most bit of their stack. All of the underlying services are the same. That's where the majority of the latency exists and a lot of it comes from old-school PayPal. But you can't shift a company by trying to tackle a deeply integrated bit of architecture first. The easiest place to demonstrate that change is feasible and actually quite beneficial (to a company that has been change-averse in the past) is your app tier. Get them on your side with an easy (easier?) win, then tackle the harder problems.
In the very unlikely event that the developer has any influence in the choice of payment processor (i.e. you are a startup that intends to trade in only one country) they still do not care, because they still need to do the usual due diligence to check whether your company is a fraud/ML risk, but they earn little in fees from you. They would rather let a smaller payment processor deal with you, then try to take over later after your product is established.
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.
For these types of problems the profile characteristic is fairly static, so there is hardly ever a need to pay for the warm up time.
Java can indeed be very fast, and in my opinion JVM is the one of the most optimized VMs that we have now. That said Java code beating a C or a C++ code on a CPU bound task raised an eyebrow. In my experience Java usually gets to the 80% speed of C++ quite easily but at a cost of 2.5 to 3.5 the memory. For these types of applications memory tends to be an expensive resource. For our number crunching server, 80% of its cost is sunk in the RAM.
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.
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.
This is why Node apps often out-perform Java apps despite running on a VM that's significantly slower. Node is pervasively asynchronous...it's baked into the DNA of the platform and almost all libraries follow that philosophy. And as organizations move to a micro-services architecture where one external call can result in multiple internal calls between systems, the need for reactive, asynchronous programming becomes all the more glaring.
That's where this critique, for me, fell down. It's spent too much time comparing the JVM to V8 and not enough time talking about how the applications being run were designed. Because CPUs are fast enough these days that any of the VMs will give you decent performance for workloads that aren't CPU-bound as long as you, the application designer, do the right thing. It's just that some environments, Node in particular, make it easier to do the right thing. This will get easier in Java with the introduction of lambdas in Java 8 and the inevitable asynchronous community frameworks and libraries, but right now it's still harder to write reactive applications in Java than it is in Node.
Personally I view that as a drawback. It's all fine, until you end up with CPU-bound tasks or until you end up talking with backend servers that don't support many concurrent requests.
The JVM support for multi-threading is absolutely stellar. You've got true 1:1 kernel-level threading, with no GILs and you've got access to the best primitives available for dealing with multi-threading issues, atomic references, re-entrant read-write locks, fork-join thread-pools, non-blocking data-structures, asynchronous I/O guaranteed to work well cross-platform, all of them backed by a guaranteed memory model that also works well cross-platform, plus garbage-collectors that are the most advanced garbage collectors in mainstream usage. G1/CMS are amazing for servers and if you've got cash to spend, Azure's pauseless GC is probably as close to real-time as you can get with a GC.
And on top of these you can build whatever concurrency handling architecture you want. Including Erlang-style Actors (e.g. Quasar, Akka), STM (Clojure, Scala-STM), persistent data-structures (Clojure, Scala), asynchronous streams (Play2's Iteratees, RxJava Observables, Scalaz Machines, Scalaz Streams).
Even when speaking of Node.js's strengths, like asynchronous I/O, I still think Java is better because of the foundations (e.g. NIO, Netty, Mina). The only reason people don't work much with asynchronous workflows is because the language is so freaking painful for that. But that will change with Java 8 and people are doing wonders in Scala/Clojure.
I've personally built an entire web-service, designed to handle thousands of requests per second per frontend instance, with responses generated in under 30ms, with a completely asynchronous workflow, on top of Scala/Akka/Play2. Node.js people don't know what they are missing.
It's high time to debunk Spring. In the name of 'Dependency Injection' many Java developers still create complex, monolithic and - first of all - untestable applications with this framework. In fact, Spring adds another layer of complexity on top of Java EE without real benefit. It fosters Anti-Patterns like 'Dependency Injection' that give you the illusion of modularity but instead create dependencies within the application ('Dependency Injection' needs to be taken literally).
That it creates untestable applications seems like completely nonsensical FUD however since the entire point of Spring is to keep code easily testable. Spring is an almost direct response to the lack of testability of the ServiceLocator anti-pattern.
I'm not saying you can't make untestable code in Spring, but if you do the problem is most likely more with the people than with Spring.
I also agree that if you can't test Spring code you are doing something wrong. I get the frustration with having to create test harnesses for some things, and the SpringJ4Unit stuff oftentimes feels a bit too magical, but I've never seen well written Spring code that wasn't easily testable at the both the class and module functionality layer.
What? Any system with separated modules is going to have dependencies. At least with DI, classes are written to a interface and different versions easily be swapped in and out.
Thank you. I thought I was the only doing my nut in over "I've done DI, now I have all the same dependencies" ... adds DIC ... "Now I have all the same dependencies but higher up, and.. oh I need to add logging to 80% of the objects" [Goes to kill myself]
I have OCD about writing beautiful code. The more I try, it seems to real world prevents it from happening.
Eager to learn so if good demo code, resources, books or I'm missing something (obvious or not) I'm all ears.
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 trade a little performance for a scripting language anyday.
No doubt a large part of any language choice is subjective, but I'm starting to believe that developer productivity has more to do with the tools and frameworks than the language itself. As these continue to improve in Java-land, I'm willing to bet that the disparity in productivity will continue to decrease.
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.
I don't; that's a bit of a sweeping generalization. I happen to enjoy writing webapps in JAX-RS and Wicket, and I know a number of folks who enjoy writing them in other frameworks.
Closure, python, c#, f# over Java. But I quite like the java ecosystem. There's normally library for anything.
It's the same flameware like Facebook started with its we can't get HTML5 as fast as native... then some people who know what they where doing did it...
No don't use java No don't use javascript
For god sake learn one language or two and learn it very well! i mean very well! and you will write good code and performant code...
EDIT: Why do i get down voted? Jesus HN gets worse and worse...
and at the second part too: "... a limit of Node.js itself when used with the backing APIs that they have to call through to."
It's just hidden better... to me it reads like a java fan boy is crying why a company switched to language X from his language Y...
[1]: http://vertx.io/
Don’t build your app on top of a pile of crap in-house framework. """
Sniffing that out before too late is the tricky part...
If you're in a structure where management's job is to allow/deny, then I think the code is already doomed. Software development is work that can't be effectively micromanaged.
In software, I think management's job is to support and challenge. All the people coding should be professionals, thoughtful and aware of issues like tech debt, second-system effects, reinventing the wheel, and so on. Management's job isn't to be more professional than the pros; it's to support the pros and make sure they're living up to (and sometimes advancing) their professional standards.
I'm sure there are plenty of people who work with these frameworks that know that they're crap. Management didn't fail by allowing these to get built. They failed by creating power relationships that allowed the people who couldn't see the problems to control the building of the frameworks, and to suppress criticism and improvement.
I might have missed something but I don't recall the original PayPal article arguing that the switch was motivated by moving from a slow virtual machine to a faster one.
But just as switching from C++ to perl would trade some computing power for productivity in getting a site built, I don't see it as controversial for an organization to say they achieved the same productivity gains going from java to javascript.
Instead they seem to be going the route of "the unicorns will solve it". The overall cost of that approach seems higher - finding unicorns is rare. Finding unicorns that are very good at all areas is even harder. I know there are a lot of unicorns on this board, but there sure aren't a lot of unicorn resumes on a hirer's desk.
I think the value of Spring has always been not that it's super-high-performance out of the box, but that it does a lot for you, and that as you learn more and more of it, you can develop solutions fairly quickly. It's built to make it easier on the developer, not the servers - but it is still easy to improve performance by focusing on constraints.
I think it's easy to blame what's between the keyboard and the chair, but the availability of said unicorns is the one ingredient of the system that is not in an employer's control. What is in control is sponsoring more education, and focusing on simplicity and constraint analysis.
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).
Rule 1 : Louder the guest shouts of his honor, faster you should count your spoons.
Similarly if someone tells you about 50% savings just because you switched to some other technology you should be extremely skeptical. Besides those people who engage in `Node vs X` debate every now and then should spend some time educating themselves about compilers and interpreters to understand what makes some programming languages faster than others in certain circumstances.
* Micro-benchmarks don't provide a good picture of real system performance and can be skewed to make almost anything look better/worse than anything else.
* Much of Java's "slowness," clunkiness, large amounts of boilerplate code, etc. is the fault of the Java ecosystem and libraries rather than the language itself or the JVM.
* The inverse is true for Node: the quality of its ecosystem helps make up for language and runtime shortcomings.
I'd venture a guess that mimicking Node.js isn't going to fix the deeper problems with Java.
If Java programmer is true polyglot, then whatever tool you are using wins. That's why C programmers are the best.
