The second coming of Java
There’s a continuous revolution taking place in web development as platforms and tools evolved first to handle dynamic pages and now cloud services. But sometimes what goes around comes around so I’m predicting a resurgence of Java and Java-like languages as rotating storage goes into decline. Here’s why.
In the beginning of the web we wrote web apps with Perl and C++ because that’s all we had. This sucked.
C++ is awesome for anything requiring intense performance but because it operates at a comparatively low level (closer to the silicon) C++ is very hard for dopes like me to use. And in a way it’s an insult to the language, which gets bored waiting for databases and network requests.
To avoid the complexities of C++ we turned to Perl which was fast to write in but wasn’t ready to be a web server. And Perl had no frameworks to help write web apps so we wrote a lot of boiler plate crap every time just to get started. Sure CPAN eventually brought libraries to help but it was still fragmented.
When Java arrived it wasn’t so interesting that we had Java, it was interesting that we had the Java Virtual Machine. JVM’s took care of cleaning up memory and automatically profiling and optimizing our programs — tasks that had to be done by hand back in C++.
Java also had threading really well integrated from the start so we could handle many requests at once which was starting to become a problem by 2005 or so. Multicore’s introduction hit just at the right time for Java, too. Compiled Java is a very high-level machine code but is a standard that JVM engineers have had more than a decade to tune so it works very well.
.NET was really just another Java for Windows. Nothing is fundamentally awesome about it over Java except that the engineers got to learn from Java’s mistakes.
Java’s performance was no C++ but it was way better than perl’s and again, we didn’t need all that much. What we needed was faster development and we got it.
Yet in the last few years since, say, 2007 we’ve been moving away from Java and .NET for web development and back to interpreted dynamic languages like Ruby. These are slow as molasses (though now our CPUs are much faster) but easy to program for a broader, younger, and maybe less experienced crowd of developers. Prototyping new websites and apps has become very easy, which is why there are so many bad ones out there.
The difference between the old days of Perl and today is that we’ve made the real web server in C++. So performance in Ruby is helped by a lot of work done in C++. Since every app needs to do that work, we can write it once and lay Ruby on top to make connections, talk HTTP, etc.
Under Ruby, we put C++. On top of Ruby we put the Rails web framework. It’s not very common to actually code anything in Ruby. You pretty much only see people coding Ruby while using the Rails framework which governs the whole thing.
You can replace Ruby here with Python, Django or Groovy and it is still correct.
Notice the transition? We started with Perl, went to Java, then came back to Perl! The reason we didn’t literally do that (actually go back to writing in Perl) is because the kids who wrote Rails were too cool for Perl, which they saw as old school. But Ruby has nothing on Perl. What’s brilliant is the Rails web framework, which came about because of what people learned writing web apps in Java. There are lots of web frameworks in Java, but that was part of the problem — knowing which of the many Java web frameworks were any good.
Ruby is easier than Java. It runs something like seven times slower but who cares? We’re still waiting for the database. And if you are a new developer you can learn Rails and be one of the cool kids.
Java has all the fantastic data structures you learn about in school while Ruby has only hashtables and arrays. But if you don’t give a rat’s ass about performance you can shoehorn anything into hashtables and arrays. That’s why prototyping is so fast in Ruby.
Yeah, but there’s a problem looming for Ruby and Rails (Python, Groovy, etc.) and it is that web frameworks based on interpreted, dynamic languages only exist at all because disks are just so damned slow. What happens to these frameworks when disks get faster or disappear entirely?
A modern disk seek is around five milliseconds. That means we can get only about 200 disk seeks per second. Every non-cached database access will do several seeks (BTree datastructure, Mr. Smartypants) and every web page usually requires several database accesses to construct the page. In other words, its not uncommon to take half a second in just doing disk seeks for your local database! And of course it gets worse, much worse, if seeks across the network are involved.
But if you replace spinning disks and moving read/write heads with Solid State Disks (SSDs) and no heads at all, local seek times drop to zero. That’s why Ruby and its surrogate languages will eventually disappear.
When SSDs gain enough capacity there will be a shift from the Ruby world back to the Java world. Not for prototyping, because, well, it’s prototyping. But simply because the statement “Ruby is incredibly slow but I don’t care because my database is slower” will no longer be true. At that point Ruby (Python, Groovy, you name it) becomes the bottleneck.
damn…I wish these things had grammar check on them!
that’s Bob not Bot (sorry Bob!) and “Yep, you’re right, Bob…”
…as far as I can remember, this has been a hot topic for the past 20 years seems it is still a great conversational hook!
I also share the opinion of the original post and agree that Java maybe on it’s way back – one example I like is Google GWT (a Java based tool compiling into Javascript) presenting the benefits of high level languages with the lightness & speed of javascript. Out of all the comments I miss mention of one programming language.. one that should be high at the top in terms of it’s time proven rules & concepts: Eiffel.
The fact that thousands of languages emerge and disappear shows me one thing: software development has still not matured into a true engineering discipline.
In a perfect world speed should be compiler optimization issue and focus should be on the ESSENCE of programming / software design rather than all the ACCIDENTS of language issues, OS bugs and optimization tricks…
That is an interesting point but it ignores the constraints of the hardware. If the hardware was truly reconfigurable on-the-fly to optimally process the computing task in the way the programmer has expressed it, then you might get somewhere. But until then we’re stuck with a relatively rigid piece of hardware (I’m thinking in terms of buses, registers, arithmetic logic units, floating point units and so on) and so naturally programs written with those constraints in mind (and relatively low-level programming languages that facilitate this) are going to have an efficiency advantage.
I definitely agree with the general thrust of Cringely’s point though (even if not explicitly expressed in such a general way) that evolution in hardware design has the potential to shake up the relative advantages of different programming languages compared to each other.
Grosch’s Law still applies.
To be clear, I was referring to what Herb Grosch said in the 1960′s, “Anything the hardware boys come up with, the software boys will piss away.”, not the Wikipedia listed, “There is a fundamental rule, which I modestly call Grosch’s law, giving added economy only as the square root of the increase in speed — that is, to do a calculation 10 times as cheaply you must do it 100 times as fast.” version.
If true, then C should replace C++ which is always larger, and hence slower than well constructed C programs. C is more difficult for many things, but is faster.
Also, Python compiles directly into Java for many runtimes. It can also be compiled directly into C. This is somewhat true for Ruby as well.
It will soon be possible to compile Python directly into Javascript as well. With the last couple of years, all major browser manufacturers concentrating on faster JavaScript execution, a well crafted JavaScript application already runs faster than a mediocre C++ application especially if you include a lot of cruft in compiling the C++app. I wonder if this will affect the transition Bob is predicting?
People smarter than me observe that dynamic languages like Python are going to get *much* faster over the next few years – to the extent that they will maybe be faster than Java.
We’re seeing the beginnings of this in last year’s improved Javascript engines, and projects like PyPy (the Python interpreter, rewritten in Python) which is already faster than the original C version, and still has plenty of work yet to be done which will make it faster still.
Optimising static typed language compilers has benefited from intense research for decades, hand-in-hand with assistance from CPU designers. As an industry, we are now very good at this – the downside of which is that we’ve probably discovered most of the clever tricks, and it isn’t going to improve much in the future. On the other hand, dynamic language optimisation has languished for decades, is only recently starting to take off, and has much untapped potential.
That is complete and utter rubbish.
What exactly are you disputing? Or are you just throwing hand grenades? PyPy has published benchmarks showing 4.8 X performance improvements. Any serious critique would have to dispute these published results but to date these quantified performance improvements remain unchallenged.
The comment that PyPy is written in Python is incorrect, it is written *for* Python. But the PyPy project is to improve JIT bytecode compilers for all dynamically typed languages, not just Python.
Whether dynamically typed languages will perform as well as Java remains to be seen. But the point that gains are being made is valid. Single sentence to the contrary reflect a lack of objectivity.
People smarter than you might not like that you are talking out of your ass.
people have been arguing about whether Python is faster than Java or not. It seems to depend on the C extension used by both. Yes, both are getting faster, but JavaScript seems to be getting faster faster.
We may see all of them getting recompiled into JavaScript. Let the compiler optimize.
Although I was cringing my way through this entire article, I think Bob is somewhat correct.
Various interpreted languages have made it easy for any high school kid to pick up web development and start writing terrible half-assed code for profit. As long as it’s developed cheaply and quickly, nobody has cared about performance.
I don’t think that has anything to do with technical considerations like rotational disk speed. Lots of non-technical folks just want to quickly get online. If they find success, they will scale by ordering more servers, more bandwidth, more of everything except development time.
With the right approach and foundation, server-side apps could easily be built in nearly the same time with lower-level languages. The efficiency of the specific language probably will be beneficial, but not nearly as much as having a proper developer applying skilled and thoughtful design concepts.
Better scalability means less fixed costs. Products or developers who differentiate themselves in this way, while still providing modern web apps with quick turnaround, will obviously have a huge edge against the multitude of lazy/amateur developers out there.
I read Cringe’s blog on occasion for the entertainment value. Nowhere else will you find someone more willing to embarrass himself on a regular basis. Rarely am I disappointed. And this time the old guy has outdone himself. Way to go, Bob!
Cringe ignores the trends and new capabilities of JavaScript (NOT JAVA) and HTML5. He ignores the fact that Java failed not because the language itself, nor even the runtime, but the incompatible libraties and absurd complexities that such monstrosities such as enterprise java brought to the table.
Cringe ignores the fact that Java is owned by, and slowly being strangled to death by Oracle. Cringe ignores that modern cloud development is based on one of the big datacenter-centric API sets. My preferred solution is MS Azure (aka .NET), although Amazon, & Google aren’t far behind.
And none of these have anything to do with Java.
Thanks for the laugh, Boob.
Bob, I agree that Java will have a resurgence, but disagree on the reasons why.
What Apple figured out (and let’s all remember that they originally had no intention of releasing a native API) is that you can get much more performance out of a native (Objective C/C++) application than any of the ultra-high level development environments (i.e. web apps, scripting languages, JVM/JIT-style languages).
Java is becoming fast because the JVM’s are becoming really good at JIT compilation to native code. However, in a mobile environment, compilation eats many processor cycles, which burns battery ilk crazy. Apple has found that battery life is more important than how much RAM you have. Your mobile device has to LAST.
Microsoft’s .Net/CLR has advantages because they tried to stay somewhat close to C (with C#) and are trying to have rich C/C++ libraries for everything that would take more CPU time if you had to do in CLR.
Apple is trying to stay even closer to the wire, by adding memory pointer management and other infrastructure that keeps inexperienced developers from making too many fatal mistakes. Objective C is as close to plain old C as you can get, but still have object-oriented constructs. This is why they have invested so heavily in the LLVM, Clang and related projects.
Apple realizes that they have a good number of app developers, but that most of them aren’t heavily trained software engineering experts. Those are the guys who know Perl 6 inside and out, as well as C, C++ and even assembly. They also think of things like Ruby and Java as great PROTOTYPING languages, but not languages for production applications. Most Java developers have no clue what’s really going on underneath the hood. As such, they are very likely to code inefficient applications.
Apple will win because a routine that takes 100 clock cycles in Objective C, that may even be parallelized and run on the GPU is far more energy and resource efficient than the hundreds of thousands of clock cycles it takes to fire up the JIT compiler and pass the resultant code to the JVM. That’s also why an original iPad1 still seems snappy compared to a dual-core Android-based iPad imitator that has a 60% clock speed advantage, and the battery life still doesn’t even compare.
One last thing…have you seen Microsoft’s security report regarding Java being a leading attack vector for Windows?
Anything with the ability to save a file and then run it can be used as an attack vector. Yes, that includes Java. It also includes Basic, ASP, .Net (Which as Bob noted is really Microsofts version of Java), and most other scripted languages. Even JavaScript is a potential window of attack.
Windows may be the primary target, but ANY operating system can be attacked. That definitely includes Apple.
Nice read and an interesting perspective but I think it is a oversimplification.
I don’t know if Java will get a second chance in the field of web programming but execution speed is already an important factor when choosing a language for cloud hosted services. The reason for this is often the pricing model and not disk speed. But you don’t have to care about pricing when you are not one of the big players and if you don’t have a lot of traffic. But big players don’t start revolutions and already use Java all the time in the application layer and even in the persistency layer.
Before the masses need faster languages for building web apps or services, the hosters need data structures that are optimized for SSDs and better distribution mechanisms for our persistency layers. Current databases (and file systems) are mostly based on B-tree indexes. For databases, the CAP-theorem is still the result of observation and not a proven fact. I guess that this will be the sector we will see some revolutions first because cloud hosters increase profits if customers use slow languages and decreases costs if the persistency layer is highly optimized. And those cloud companies will be the driving force behind the next generation internet in the same sense that operating system companies were the driving force behind personal computing.
I taught myself assembler when I was nine. But I was living in a time (1981) and a place (not near any early computing epicenter; in 1989 we still had Apple IIe computers in the high school computer lab, and one solitary Mac) and around people, when, where, and to whom such things mattered little. And I was way to content to go outside and play, fancying myself the next Reggie Jackson, albeit smaller and whiter.
So I forgot about computers a couple years later.
I briefly got back into them in the early 90s, writing a little SED and awk in a Unix environment, but basically stayed away – during the Gold Rush years, no less.
When I finally got back into the computer industry, time had passed me by, and as a matter of expediency, I took up web development.
Now, all of that was to say that the only thing I am sure of is that web developers will go the way of the Moa. We’re too slow and too dumb. It doesn’t matter that we can talk equally to real software developers and artsy web designers; what matters is what people pay for: rapid, cross-browser development.
With the IE backlash known as the W3C pushing standards (and I thank them for it, though I now realize it was to my own demise), and the actual device and platform – and browser – soon to be irrelevant, the world will only need two kinds of people: web designers, who speak in Pantone colors and user-experience jargon, and real software developers who write the framework that allows the designers to fire the web dev because they can do it themselves. Maybe the reemergence will be some version of Frontpage or Netscape Designer.
I am now a C# developer, and still I am several layers abstracted from writing “real” code. And it would take only a small-ish change in my company’s vision or the industry in which we work to move my layer entirely into configuration tables.
I think I’d rather play outside.
The rotating disk vs SSD discussion is over-simplified, but the revolution will be real.
On the one hand, JavaScript will take over the world because we all have to learn it anyway in order to do the web part of our work. Qt has JavaScript, the JavaScriptMVC system is just one way to write apps in JavaScript. Node.js is another.
And, of all things, C++ is making a resurgence. The new C++ is easier to use and the libraries have swallowed up the job of memory management.
JavaScript and Ruby and Python are all getting faster. So maybe the SSDs will permit yet another layer of interpretation, instead of running byte code.
Or maybe embedded-or-mobile Go, from Google, will have the combination of expressiveness and the long battery life (from running just machine code) that will conquer the planet. Who knows what’s cooking in the labs?
The mobile world is taking over (sort of) and the ARM processor (which is conquering the mobile world) will permit things that today seem impractical.
Seriously, don’t give up your day job, because you have absolutely no idea what you’re talking about.
No, Arm is gaining. It’s a simpler system to program for, and uses less power. Intel’s days may be numbered.
Javascript is much faster than it used to be.
C++ (and old style C) are gaining ground again.
It doesn’t sound like the original poster is ignorant of the current state of affairs.
But, the current state of affairs can change at any time. Who knows what will be in two months?
I’m the guy who asked for a tl;dr last time. I think I maybe get what you’re saying, now – that sites are going to get faster so people will remove the /new/ slow spots (like always pulling the tallest weed in your yard – oh, now there’s a new tallest one). I suppose that’s a fair thought. However, the pioneer in massive SSD storage is PayPal (biggest in the world I’ve heard, don’t recall the size though), and their code is C++. That’s not to say it won’t go JVM elsewhere. I’ll just drag out the old generic point though, that C++ performs better and consumes less energy than Java / JVM languages, so that’s something in /its/ favor.
As for multi-core friendliness, actor-style (a la Erlang) is the ultimate, but I don’t know of any well-developed libraries for C++ or Java except I guess Microsoft’s C++ one. I’m sure they’re coming though, for all languages, so I personally don’t see that as being a point of distinction either way (I don’t think Java supports multi-threaded / multi-core better than C++; especially not with the new, C++-2011). I don’t know any reason to choose a side in the developer time vs energy consumption tradeoff though.
I was in web development and then analysis for a while at a company doing a fully web-based app (.NET, MS throughout, but multibrowser).
Over time, we learned that disk speed, CPU speed or even memory was not the biggest problem. Component selection, database design, query design, even page design were all huge contributors to poor performance. Yes, it’s obvious, but there is more.
We were rolling out a new large-scale version of the project where overall page response time and thus database speed was now very very important. What we learned from MS was that SQL server (and I would imagine many other SQL database engines) will try and fit the entire database into RAM if there is enough available. If not, THEN your disk speed becomes important. So, if you are fairly small-scale, why won’t your database fit into RAM ?
if you aren’t small-scale, why are you still trying to run some big important database on a single disk ? Or on a single PC?
Surely any half-decent outfit with a lot of queries to handle, especially on a really big database is going to be using RAID for storage at least, if not a SAN where seek times and data throughput are really not the problem.
Quite possibly a developer/team needs to do some careful thinking about why their page is running query after query just to load itself, and optimise that instead of bemoaning disk speed like more power is the only solution. But then if the whole project is geared around spending the smallest amount of money today, maybe nobody is asking why the project was written in a very slow language is running inefficient queries on a poorly designed database running on a badly configured system…
Is switching from rotating storage to SSD’s really the answer to all those problems? I don’t think so. There is no magic bullet, and SSD’s have their own disadvantages when it comes to lots and lots of write operations going on.
If you have a big system with a lot of different pricessors and large memory requirements, why are you running on SQL server? Google, yahoo, eBay, all the big stock brokerages and exchanges, all the biggest banks, even Microsoft for the large server requirements run some Unix like system for big loads.
You should be doing what the really big boys do. Windows doesn’t handle thousands of threads shared among hundreds or thousands of processors well at all. It’s an architectural question. Linux or Unix would be a better choice.
Yes, run the data base in RAM if possible. An optical bus seems to be the current best choice.
Of course we may have different definitions of what constitutes a big system. How many acres or hectares is you server room? (I don’t use a big system myself, but have interacted with and helped prep some big ones.)
I’ve always found the TIOBE index ( http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html ) an interesting measure of the new development being done, as it uses a number of search engines to scour the interwebz to locate how much people are talking about a particular language.
One thing to note is that Java is and has been #1 on the index for quite a while, or a large share second if you group C and C++ together as a single language (even further if you group Objective-C, C and C++ as a single language).
This ignores the larger issue in that most everything ever owned by Oracle has had the blood sucked from it until it’s at best a zombie continuing its existence.
Seriously though, I did a little look-see at the state of Java, and here’s what I got:
*Spring/Struts/JEE is extremely expert-friendly. Looking into web frameworks, that’s what I surmised. Why can’t it be like asp.net MVC? Model. View. Controller. That’s all. Instead there’s ActiveBeans, JohnnyBeans, StatefulBeans…. so very very many language constructs to learn and you don’t even use half of them.
*No one likes using JSP.
*J2ME is dead. Compared to tinyclr, its cost and systems requirements are just insane for the 1.4.2 functionality—no wonder no one uses it. Take a look for the j2ME jobs on dice.com
*J2SE embedded requires a ‘nominal licensing fee’ which from the android lawsuit looks to be about 10% commission, ontop of their requried 32 megs of ram.
*Google is getting sued by Oracle right now for damages in the billions from android—the best thing to happen to Java since Java 5.
* getting new features such as Lambda expressions into the Java language is a snails-pace endeavor. They’re 2 years behind many good .net features, and only getting further behind.
* Most of the good open-source java additions have found themselves kicked-off of Oracle’s servers. (swingx, opencable)
Which leads quite a few folks to this sentiment: We *LOVE* Java as a language. As a platform though…not so much. As a platform, all I see is JavaFX 2.0 in terms of any direction Oracle is taking things….and I’m not impressed with the development and nurturing its getting compared to Flash 11 and Silverlight.
They’ve been less than helpful to their open-source community, and they have no sense of direction with Java as a company. Compiled PHP, asp, accelerated python…. but Java is soon to be in the same academia graveyard as its Smalltalk ancestry.
Like, where’s Linq or entity framework equivalents in Java?
http://stackoverflow.com/questions/1083080/what-are-the-java-equivalents-to-linq-and-entity-framework
[...] of RSS delivered to me this morning a link to a new blog post by Robert X Cringeley. The post, The second coming of Java got me [...]
My organization uses Asp.Net and C#. C# is maturing into a very interesting language (lambda expressions, linkq, etc.) But what makes web development less painful is the rich framework. The code can be precompiled into byte code before loading on the server and then compiled at execution into native code. The native code compiler uses knowledge of the server (memory size, number of CPUs, etc.) to optimize the code.
As a previous writer noted, writing efficient code speeds up the page to page response time and a rich framework takes a lot of the work out of writing the code.
For many developers in enterprise organizations (banks, hospitals, large corporations), they have been developing in Java and/or Asp.Net since about 2000; so it is not coming around for them again.
[...] of RSS delivered to me this morning a couple to a new blog post by Robert X Cringeley. The post, The second entrance of Java got me [...]
[...] of RSS delivered to me this morning a couple to a new blog post by Robert X Cringeley. The post, The second entrance of Java got me [...]
[...] of RSS delivered to me this morning a link to a new blog post by Robert X Cringeley. The post, The second coming of Java got me [...]
Cringely,
Accoridng to Steve Souders, even if your server time was 0 to process a request, the average user wouldn’t notice. Most of the time time for websites is transportation and rendering.
http://hanselminutes.com/288/googles-steve-souders-creator-of-yslow-on-web-site-optimization
Best,
Alex
I doubt the next fronier will be auto-directed flight the same as I doubt the value or likelyhood of a return to java.
Computers were a luxury but costs dropped and now computers are common. Memory was a luxury, now one uupgrades to as much as is available. Disk space cost a fortune, now google and others give it away. So what we need is a new cost reduction that makes something disposable. What? Computer programs. Except that all the Java, Javascript, C++ and other “experts” in programming have an interest in preserving the status quo. A return to java just continues to conserve the existing devlopment paradigm instead of geTting rid of it – after all, the existing programming paradigm has existed since programming first began – making dinosaurs of programmers and their methods. Time for a change but, just like using petroleum products for motor engines, there are too many vested interests who will prevent the possible!
So how do you program a computer without a programming language?
He’s talking about using an AI assisted natural language programming system, probably coupled with a visual system for interfaces. It would be optimized by the system.
This would allow ANY domain expert to create a program off the cuff to solve any type of problem, ala Star Trek. Then, specialist programmers would become an endangered species very quickly. Computer Scientists yes, Programmers no. Perhaps that’s why it hasn’t happened.
But, system administrators would still be needed.
This is possibly the most ill-informed turd of an article that I have read in a long time. There is no reason that you, or anyone else is forced to choose one language over another when they both clearly have different uses. Perhaps Bob, you would be better served spending your valuable time finally slogging through that copy of ‘Teach Yourself Visual Basic in 24 Hours’ and then true productivity can begin!
I think everyone here is missing a point
Read through some 140+ posts and the big assumption is the need to generate this thing called a ‘web page’. Great thing about that is anything less than 500ms is probably ok. You can optimise your cache between Db and service layer. Optimise each in turn and scale to Facebook, google or beyond. Who cares if the final app server taking all this runs a scripted language.
But what about the need to respond in 100ms, 10ms even 1ms? What if in 2 year time interfaces are 3d real and bugger all to do with web pages? When html5 fulfils it’s ambition and becomes an app language that consumes high speed data feeds is persistent.
Bob, As a great fan of books and column, all give you the benefit of the doubt, but I’m not buying this post. First, Ruby and Java are two separate things, not just that Java is a platform, but Java is now the old, staid, conservative, slow moving, Oracle-owned behemoth that you can’t go wrong with (like IBM). Ruby is a whole separate path, a different branch, and never the twain shall meet. Sort of. In other words, the Perl hackers moved to Ruby, and started slinging out apps 7x faster than their corporate Java counterparts. I talk from experience, having this very day spent most of my time restarting the @##$$$$ web server due to a huge refactoring effort. Now I have dabbled in RubyOnRails, but I see the light. With Java, the hut/platform, you need a hack upon a hack to get stuff to work, i.e. Spring, EJB, what have you. What a nightmare. So you fix all your bugs in using the bytecode compiler, then have to fix all the bugs in Spring config. This is why programmers cast an appreciative i.e. at clean architectures, though new, like RubyOnRails. And maybe that’s a good thing, because it’s new, it doesn’t have all the years of “cruft” that Java frameworks like Spring have. “Let’s do everything in XML config files because that’s the hype of the day. ” Yes, this is why Java is called J-Cobol.
So to make the point. Java, Ruby, Ruby on Rails, very different things. Nobody is going back to Java, it will just slowly plateau, like Cobol. Is oracle going to create excitement? Give us closures, that, for crying out loud, Javascript has? Doubtful.
The disk drive? Where are we Cringeley? 1996? Faster disks make dynamic languages more appealing, if anything , to Rubyists. Restarting my appserver is CPU bound, crunching through thousands of lines of code, of logic. Sure, faster disk will help. But this is a bandaid.
Signed,
Very grouchy Java programmer saying “C’mon kids, get on the grass! Take it! I’m moving to an island. Have fun!”
[...] 2011 at 10:02 am and is filed under 2011. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own [...]
First of all, you are wrong that “we’ve been moving away from Java and .NET for web development and back to interpreted dynamic languages like Ruby.” Forrester data shows that Java and .NET are used consistently. I haven’t seen data to support that claim. Ruby on Rails and the productivity of other frameworks is overhyped and underdelivers. Heck. I could write a simple Web form database application in 3 minutes with Java struts. The time consuming part of Web development is tinkering with the messy combination of HTML, Javascript, and CSS. I am not defending Java. I wrote a post that Java Is A Dead-End For Enterprise Application Development last year. http://blogs.forrester.com/mike_gualtieri/10-11-23-java_is_a_dead_end_for_enterprise_app_development
These new scripting languages and frameworks are only incrementally superior to Java or .NET directly – not enough to be a breakthrough.
The right direction was the late 80′s and early 90′s with 4GL’s. 20 years later we now have the technology to make visual development and model-based approaches work. However, the new generation of developers says whoop-de-do when they see a grungy framework can take a html text field and push back into a database.
So, an optimization of scripting languages and frameworks is not even close to Java’s second coming. Rather, it is a sign of it’s final fall.
As an old-Java hand and a current flash devotee, I confess the rationale that faster storage motivates higher-performance programming languages hadn’t occurred to me. I can tell you that in the early WebLogic days (when folks argued we were nuts to have written our middleware infrastructure in Java), we did use the argument that latency and throughput were generally dominated by network, database, and storage costs rather than the application server and app logic.
Storage is definitely going to get ~10X faster as we break the cost barrier to broader flash deployment (Pure Storage’s raison d’etre), but I suspect that for most app’s, the execution speed of the app code itself will remain relatively insignificant when compared to what the app is doing (web service invocations, database access, and so on).
Better IMHO to focus on languages that make it as easy as possible to craft _and_ maintain your applications. More important than the language itself is the craftsmanship of the programmer, but I confess I am intrigued with more functional approaches as an easier path to more highly parallel applications (e.g., Scala, Clojure) and the ever higher-level frameworks for simplifying app. construction. Very nice to see the breadth of language innovation going on today, and again as an old Java hand, also to see new programming languages written on top of the JVM.
Just my $.02
[...] X Cringely’s column is always worth reading. Recently he wrote about The Second Coming of Java, in which he asks if database servers switch to SSDs and disk I/O latency is a thing of the past, [...]
[...] to Robert Cringely (http://www.cringely.com/2011/10/the-second-coming-of-java/), this is bound to change once solid state storage becomes pervasive enough. With their access [...]
Well I’m just catching back up, but I’d say you’re wrong.
Java used for webpages has always been slow as molasses as well. I have yet to come across a performan ASP or JSP page that is any where near the performance as the average Ruby/PHP/Python websites, and that has nothing to do with disk speeds or database accesses, though they probably don’t help anything either. (And yes, I’ve written some pretty big database web apps in PHP.)
Another reason you are wrong is that at least Python has at least as much functionality as Java and much better performance in every aspect. So don’t expect Java to ever really make a comeback; but another tool to take over that meets the performance needs if there becomes an issue.
Java was just a pothole in the road. One that will eventually be filled in so that we don’t ever hit that bump again.
Plus, Python/Ruby/PHP can each use the parts written in the other language as part of their own program. It’s just a question of the amount of memory you have available. And, unless you are an expert, the Python/ruby parts will run faster than the Java, and nearly as fast as a C++ program. Faster if the C++ programmer isn’t well optimized.
Gotta love those shell abilities. every program is a command in your language.
The main face of the cards is young and trendy women. As long as you like the bag, as long as you worship trends.
Generally, most apps still don’t care about performance … almost everyone I know about is looking to get great cutting-edge features without having the cutting-edge knowledge and experience necessary to brew it up from scratch.
I can tell you, it’s a delicate balance … the more a framework does, the more it walls the users off from doing the one exceptional edge case the way they want it to work.
People moved from Java to Rails (and Ruby) to get productivity and a more expressive language. Wide use of SSDs isn’t going to make Java any more productive.
Meanwhile, the same ethic that moved people from Java to Ruby is present in the “no SQL” database approaches, which often bypass the performance issues your are talking about by keeping data quickly available in just the format its needed in … without doing multi-way database joins and all the rest of data mangling that occurs in a traditional multi-tier enterprisey app.
The best thing those of us in the Java world can do is look to see how we can improve productivity without sacrificing performance. That’s a large part of what Tapestry is all about.
Hat tip to Howard about the ethic of the new NoSQL movement (which Cringely apparently has no experience let alone much knowledge about). Also someone else here in comments made some good points about languages such as how easy it is to maintain code (readability, writeability, etc.). I find value in Ruby for its succinctness (it doesn’t requires as many lines of code to get something done). Java is too verbose and heavy.
I agree that with SSD slower scripting languages may disappear but perhaps Java is going to be replaced by .Net on Windows and Objective-C on MacOS/iOS anyway.
They are fast enough, dynamic and reflective and the frameworks based on them powerful and complete…
[...] Cringely has an interesting article predicting the return of Java as a core language for the web: The second coming of Java. The flow of his argument is that Java is much faster than interpreted languages (such as Ruby, [...]
Very good and insightful read.
Though, how can you not name PHP in your story.
Ok, the new kids came with fancy stuff but the real stuff running half of the web is still PHP…
I would also say that the need for threading came way before 2005!
Just a finer point: Groovy actually runs in the JVM — it doesn’t have its own runtime. Since it’s essentially Java, it’s a bit off to lump that in with Perl/Python/Ruby/PHP when arguing in favor of Java. Also, I think all these higher level languages will continue on their growth track anyway since CPUs continue to get faster along with storage, and developers like easier ways of solving problems. The tower of babel will keep on rising as Moore’s Law trudges forward.
Yeah, sure: given better, faster technology (SSD), developers then drop Ruby and choose a lower level language (Java). That makes a whole lot of sense, Mr. Cringely.
One thing I have noticed working with other programmers is that the above average programmers have a toolset. They use Emacs/Vim/Others for editing, Java/Ruby/Python/Others as their programming language of choice and SVN/Git/Mercurial for source control. They invest a lot of time in mastering their tools and don’t like to give up using them easily. So if SSDs become commonplace then these guys will invest their time in adapting their tools to new conditions and not the other way round.
If jordan top heels atramentous and purple,in Milan jordan for sale, was actually able to acknowledgment to the 80s, again it is actually Donatella Versace – a huge accept design, beaming dye, disco fever, etc. nike jordan with top heels, is the best description. Her family, like her own, never went ahead. Today she showed us a faculty of vertical abatement is still actual abounding band of acid the breeze ambit of clothing , with Gianni accomplished in his time commensurable to the absolute height, but it seems that any admiration to anamnesis the acceptable times accomplished accept been evaporated out. yilai?louis vuitton outlet.
I’ve been away for awhile and am catching up on Cringely articles but this one really made me laugh, it’s so totally missing the point.
Moving away from disks really only means people can do bad things at somewhat larger scale. That means your startup can get bigger before you get to redesign your software in order to remove bottlenecks. It doesn’t mean you’re not going to hit the same problem at some point. This extra breathing space is likely as much of a curse as a benefit: The bigger you are when you decide to redesign the harder — more expensive — it becomes to change things. It’s better to run into scaling problems early so you fix the architecture when it’s still cheap to do so. More on that in a minute.
Slow code execution hasn’t really been the problem for a long time. It has (at least in the Age of the Internet) been a lot less expensive to throw hardware at the problem than developers. The trick is making sure you can continue to throw hardware at the problem indefinitely.
Faster storage (especially databases) will improve single-instance scalability, no question about it. But it’s a matter of degree, and not even that great a degree. You’re still not going to be able to run the likes of Amazon.com on top of a single MySql server even if you’re running on RAM, to say nothing of SSDs. Faster page rendering runtimes aren’t even interesting in that context.
And here I will point out an example of both the limits of single-instance scalability and the problems with single-instance optimization: eBay. Those of you who have been around awhile may recall a time when eBay suffered a series of multi-day total outages. This happened because they were running their entire business on what was effectively One Big System. As they grew they took the easy way out: Upgrade the system to a bigger, faster system whenever the old one was no longer up to snuff. It was not very long before they were running on what was literally the biggest, fastest system anyone could build.
This was easy to do, and it was relatively cheap. It was disastrous in the long term. Even if they had not had a system failure that took out their entire business for days at a time, they had already run out of headroom for further expansion and performance was clearly suffering. There were simply no bigger systems they could possibly buy. What’s more, they were at that point so big that migrating to a new system was going to be very, very tricky. It ended up being obscenely expensive.
If they’d hit the limit when they had a few tens of thousands of customers, instead of tens or hundreds of millions, it would have been a lot easier to fix. If they’d hit the limit earlier they would have had redundant systems already in place and could have weathered an outage by shifting load, impacting a relatively small number of customers. They did eventually do this, but it cost a hell of a lot more than it would have if they’d hit the limit early.
So there’s an example of why migration to SSDs might be bad for you, rather than good for you. But let’s get back to web page rendering.
Few here may recall it, but in 1997 when companies like the one I worked for (ATG) were starting to use Java to build big systems Java was dog slow. This was before JIT, or HotSpot, or even modern garbage collection. C++ was on the order of ten times faster than Java. Many people thought we were crazy to use Java, that you needed C or C++ to get the performance you needed. (Cerf even claimed at one point that dynamic page generation in general was going to be impossible at scale, pretty much at the same time that many people were already doing it. D’oh!)
My company did what computer scientists do to deal with that: We made it as easy as possible to throw more hardware at the problem. If we were going to be ten times slower in raw execution speed, then if it was possible to throw ten times the hardware at it we were going to be just as good, and Moore’s Law makes that more and more practical every day. Even by the mid-1990s big clusters of cheap machines were becoming popular (reference Hotmail before Microsoft bought it, built on top of thousands of little BSD PCs).
Page rendering per se was the easy part, of course; it was always pretty easy to just parallelize the renderers. The hard part was the database because it’s so hard to build coherent applications without a single consistent database. But it was — and is — pretty darn easy to remove the database from almost all page renders via caching if you tweak your architecture a bit.
Web page rendering data requirements almost always fall into one of two categories: User-specific data, and shared data. Shared data is always easy, you just make a cache that all the rendering processes can pull from. You load the cache from the database once per application server instance and then the database is out of the question. User data is harder, but it becomes a routing problem; as long as you can get at the user data at memory speeds rather than network or database speeds you’ve got no problem. So you make your server infrastructure route page rendering requests to the same application server instance every time, allowing you to cache user data in that instance. You load once per user session, rather than once per page render. And since all of this stuff is in RAM, exactly where you want it, it’s very fast to access.
Voila, you reduce database overhead for rendering operations by orders of magnitude and your page rendering is lightning fast.
It was designs like this that made the web scale on Java, it wasn’t faster JVMs. C++ was much faster out the door but over the long term algorithms beat optimization, and the Java folk had more reason to work on algorithms early. Java eventually got faster but that only made the designs work all that much better.
So when you talk about using Java versus C++ versus Perl or Python or Ruby or whatever the performance of the core runtime is largely immaterial when it comes to building a big, performant website. Faster databases are really not going to make the difference between page rendering languages, we can already scale those easily.
The trick in using any of them at scale is not optimization; you’ll get degrees of improvement if the hardware is faster, if the database is faster, if the language runtime is faster, but they will all be limits again fairly shortly. When you want to scale you want to eliminate bottlenecks and you can do that with almost any language.
This is why Google and Amazon have put so much effort into distributed databases, and those distributed databases have a whole lot to do with why they are winning.
jim frost
jimf@frostbytes.com
รายได้เสริมทางเน็ต…
[...]I, Cringely » Blog Archive » The second coming of Java – Cringely on technology[...]…
Unsure…
Novices might be confused about the details however…
Android makes this prediction a no-brainer, but nice flame-bait anyway champ.
reformas de pisos…
[...]I, Cringely » Blog Archive » The second coming of Java – Cringely on technology[...]…
Design…
[...]I, Cringely » Blog Archive » The second coming of Java – Cringely on technology[...]…
trend fashion|trend fashion market|trend fashion online|trend fashion outlet…
[...]I, Cringely » Blog Archive » The second coming of Java – Cringely on technology[...]…
Program 4681…
[...]I, Cringely » Blog Archive » The second coming of Java – Cringely on technology[...]…
autoblogs seller…
[...]I, Cringely » Blog Archive » The second coming of Java – Cringely on technology[...]…