It's gotta be a slow day on hacker news when this is at the top page. (Or, is this being upvoted because it is Cringely.)<p>An entire article about web development past, present, and future without a single mention of PHP....<p>All snark aside, I strongly disagree with several things in this article.<p>Java never left, so it can hardly arrive again. Anyone that has ever worked in a corporate environment problably knows what I am talking about. Java dominates the Enterprise landscape.<p>Disk speed limitations on database access times can be and has already been overcome by in-memory caching. This is not new. Advancing SSD tech will not suddenly lead to Java's total ascendance as a web development platform.<p>The characterization of dynamic languages as "easy to program for a broader, younger, and maybe less experienced crowd of developers" is a rather unfortunate blanket generalization. This is especially the case because most people that I know that use dynamic languages usually have some experience in things like Java, C, C++ that Cringlely seems to hold in high regard.<p>And finally:<p><a href="http://www.paulgraham.com/avg.html" rel="nofollow">http://www.paulgraham.com/avg.html</a><p>The real problem that the vast majority of web developers face is not trying to cope with overwhleming amounts of daily traffic. The real problem is how do you build a product that is compelling enough to get signups, and how do you continue to develop this product to attract new signups.<p>Java is fast, and that is lovely. However, speed of execution does not matter when your development speed drags. When you are developing a product, you need to be able to move fast. If you get substantial traffic, then you can always rewrite backend services in Java (or whatever floats your boat) at that time.<p><i>Edit: When I say Java, I refer to the language - just as Cringely does in this article.</i><p><i>Of course a number of excellent languages have developed that combine the advantages of the JVM with the benefits of a more powerful language. (My personal favorite being Clojure.)</i>
First, Cringley is simply wrong on many of his points. I don't think he's kept up with this stuff very closely, but that isn't the main point I want to make.<p>I think everyone is missing a major point in these sort of debates. The JVM uses a shit ton of memory, and this makes it expensive to host. If someone is a poor student that is trying out different ideas for websites, then they can do it much cheaper if they don't use the JVM.<p>There is a reason there aren't a bunch of shared hosting providers offering jvm support, and if you look at VPN prices I'll bet money that the two things you look at are the memory allocated to your VPS and the price.<p>Even on the development front, I just had to order a new laptop at work because we're using the JVM and I need to run 3 JVM web services at a time every now and then, plus an IDE and I simply can't do that with 4 gigs of ram which is the max for my current laptop. The JVM process for a hello world servlet, after being hit by a number of requests, will need about 100MB of ram, for a hello world string response!<p>The JVM is great in certain circumstances, but it's terrible as a cheap platform for people trying to bootstrap and test the viability of ideas. I can run 3 or more ruby, python, or php sites on a $20/month VPS. I can't do that with the JVM, and I'll always bet on the bottom up technologies.<p>Also, he's assuming that modern times are like the past, and that you can't easily mix interpreted and compiled languages, but on the JVM this isn't so. You can use JRuby and rails, and code the hotspots in java. Hell, you can even code some of the urls in pure java and leave the less significant bits in rails. To make the situation even better, you can start off with C ruby on a cheap vps and if you're idea takes off convert it to JRuby and then start replacing the bottlenecks in java, scala, or whatever.
I think Cringley is setting up a false dilemma here: that you can have fast or high-level but not both.<p>Lisp has been fast for decades, and modern Common Lisps are roughly the same speed as Java. Lua is a lot like Ruby or Python but about an order of magnitude faster. LuaJIT is <i>another</i> order of magnitude faster, putting it on the same level as Lisp and Java. Haskell is a very different sort of high-level language, but it's fast too.<p>I think he's right that we'll see more people caring about the speed of the implementation language's runtime, but I suspect we'll see more startups picking fast high-level languages or fast runtimes for already-popular high-level languages than going for Java.
<i>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.</i><p>This is certainly not the case with Python. Python has a huge community outside of Django and is used in the scientific, academic, and financial communities (see NumPy, NLTK, Bazaar).<p>In other words, if you eliminated the Django community there would still be a large Python community.
I get the feeling he is making the common mistake of comparing Java with JVM. Java, as a language, is fine but many other languages (Ruby, Python) run on top of the JVM and have very good execution times (plus multi-core support).<p><i>...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.</i><p>Something about this rubs me the wrong way, and smacks of elitism. I've seen some amazing code from the Ruby community yet I feel he is confusing a language's learning curve with the experience of its development community.<p><i>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.</i><p>Wow. I completely disagree with this. I stopped reading after that.
The whole argument is flawed. First of all, Java never left. It is still used widely in "Enterprise" environments where it powers complex architectures with a lot of XML.<p>Secondly, Ruby on Rails and other dynamic frameworks are not popular because their performance issues can easily be discarded compared to Java. They are popular because they make a tradeoff between development speed and execution speed. Better hardware may change that tradeoff slightly, but human labor will likely still be more expensive than the servers running the applications, so this changes nothing.<p>I don't think Java will disappear from the web any time soon. It is way too pervasive for that. I see it more like the new COBOL: in 100 years, people will still be interfacing with ancient Java apps, only to move on as soon as possible to more modern environments (that may or may not still use the JVM for their execution.)
Wow, this guys knowledge is wrong.<p>Dynamic languages can be faster than C now, and are only improving. Implementations like pypy, and luajit2 really are rocking. JavaScript implementations are also getting real fast.<p>C++ doesn't need to use manual memory management, and hasn't for ages. You can use it, but it is optional. Perl was often mixed with C/C++ libraries, including mod_perl with apache - the real webserver written in C.<p>With WebGL there is coming a massive amount of GPU power available to apps from JavaScript. Which also has available WebWorkers, which allow multi core use. As well, as vector instructions. The speed available for processing is truly amazing.<p>There's just too much wrong in this article, so I'll just stop writing about it now. Usually I enjoy his articles, but this one is way off. On the other hand, maybe it is just a really good troll?
This article is indeed cringe-worthy. Not because he's defending Java, but because of all the strong opinions clearly based on a weak understanding of what he's talking about.
I'm a Rubyist and I actually buy his basic argument, but the technical <i>details</i> are out of date/wrong and it reduces his credibility. I don't know if Cringely is a developer but it doesn't read as if he is and his point would have been better made from a higher level rather than playing the trendy dynamic language-bashing card.
This article is nonsense. It deserves nothing but ridicule.<p>The popularity of dynamic scripting languages had nothing to do with databases, and everything to do with prevailing fashion, compiler technology, and industry priorities. We've had fast databases for decades now, and good freely available databases for about half as long.<p>Even if you take this point as a charity, the timelines don't match up. There just isn't a link between Java and all this. Technology has advanced a lot since the early 90's and we're dealing with a lot of new languages, VMs, and language design.<p>There simply aren't causal links anywhere in this chain of argument.<p>"Ridicule is the only weapon which can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them..." -- It doesn't matter who said it, it is correct.
His argument is that slow languages are acceptable now because databases are slow due to slow hard drives.
But this seems not right to me. Most databases eat as much RAM as they can get their hands on, and in any reasonable sized setup, the frontend and database will be on different servers so you still have to factor in internet work transit time. What this boils down to is that harddrive speed increases won't make as much of a difference as he is counting on because<p>a) They aren't necessarily the biggest bottleneck now<p>b) Even if they were a bottleneck, we still often have network transit time to account for, making DB access still relatively dog slow.<p>This doesn't even take into account the entirely different set of arguments that other languages like php and python are an order of magnitude faster than ruby 1.8 (and ruby 1.9 is faster too) and that Java is considered by many a horrible language, and no speed increase in the world would make them willingly use it.
(as a full-time Java and occasional wannabe Rail programmer)<p>I think there will always be a huge % of website where raw performance doesn't matter. I don't recall PHP being a high performing language either. But, for those websites that are constrained by disk access perhaps they will prefer a fast performing language. I'm not convinced it will be Java though, just because speed of development is still going to be important. Perhaps it will be a JVM language or perhaps it will be something new like Go, Node.js or Scala.
A rising tide raises all boats. Increased hardware and database speed will not make Rails less attractive it will make it more so. Far from exposing Ruby's sluggishness (which itself will be less and less of an issue), it will expose how easy it always was to solve most (I said <i>most</i>) scaling issues horizontally.<p>The majority of the old "Rails doesn't Scale" canard was based on perception and CPU benchmarking that had little if anything to do with actual scaling issues in the real world.<p>If -- if! -- SSD and other hardware advances remove the classic bottleneck for performance -- the Database -- then 1) the question of performance will become less of a political issue for departments, and there will be far less incentive to look for a scapegoat ("let's get rid of Rails then, it's slow, right??") and 2) in the majority of situations where latency is a problem for a Rails (or Django, etc.) deployment, then horizontal scaling becomes the simple solution, which in fact it always was.<p>But the biggest reason to use a framework like Django/Rails, etc. will not go away with better hardware: time to market. Use of these frameworks has enabled a number of high-profile sites to get to market quickly recently and handle some heavy-duty traffic by any standards. Can you imagine a Groupon rolling out on top of a J2EE stack?
I was surprised he didn't mention more agile Java web frameworks like Play! (fairly much awesome) and GWT and/or SmartGWT (I use them a lot for customer work, but prefer Play! for my own projects).<p>I am also surprised he didn't talk about alternative JVM languages like Clojure and JRuby, which are great languages for the JVM for some types of applications.
My best guess is that, as the bottleneck goes back into the application (and out of external dependencies like databases, disk, network), there will be an increasing pressure towards better multi-processor support (we are not going back to single cores anytime soon) and, of course, faster executable code. Unlike Cringely, my bet goes toward using more and more JIT'ed code (as in PyPy and v8) and better use of asynchronous APIs instead of lower-level languages. Of course, better integration with native code (as in "compiled from a reasonable language") will also be highly prized and a tool worth looking into.
This is an unbelievable post. We're going to move back to <i>Java</i>, because.....<i>file access will suddenly be an order of magnitude faster</i>, therefore dynamic languages will suddenly be <i>too slow</i>?<p>what form of crack is this ?
The JVM is going to be around for a long time. I'm thoroughly enjoying myself writing rails apps on jruby, bundling them as a WAR file, and then sticking them in tomcat. Too easy.
This article appears to make the following argument:<p>1. Ruby/Rails developers use Ruby/Rails even though it is slow because storage access is slower (and thus the bottleneck).<p>2. Storage access is about to get much faster as people switch from spinning disks to SSDs.<p>3. Therefore, people will start using faster performing languages because app server language will become the bottleneck.<p>However, there are two questions I have about this argument:<p>1. How much faster are SSDs in common database scenarios? Presumably, they are much faster for point queries? But is it 2x, 10x, or 100x? How much faster are they per dollar (e.g., how do SSDs compare to tons of spinning disks in RAID)? Will they impact common caching scenarios (e.g., memcache)?<p>2. Are app servers ever the bottleneck? Modern web development seems designed for stateless, horizontal scaling ("scale out") at the app server layer. Further, this stateless, horizontal scale out requires no effort for even the smallest shops, through things like Heroku, App Engine, EC2, and similar services. Will it ever make sense to trade off expensive programmer time (by coding in a lower level language) for less app servers at all but the most extremely popular websites? Is there some compelling reason the app server layer should not be stateless?
When someone says things like this, I have to ask if they <i>really</i> understand the difference between a language and a framework:<p><i>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.</i><p><i>You can replace Ruby here with Python, Django or Groovy and it is still correct.</i>
His argument is basically that slower dynamic languages like Ruby are popular because databases are slow, and databases are slow because disks are slow. But databases are not slow because of disk speeds. Disk access is pretty fast compared to network speeds. Databases are slow because of the join algorithms they use, because of the way data are structured, etc.
The writer's argument pretty much boils down to the claim that java will be faster than ruby on rails even more than now. For technical reasons why he claims this, read the article. I don't know enough to know if his technical claim is true or not, but here is why I won't be switching from rails to java anytime soon.<p>I previously worked with c# and asp.net which may be comparable to java in many regards. I currently work with rails. In my experience, the ability to build rapid prototypes with rails simply trumps marginal gain you might get out of performance improvement with .net or java frameworks. I think the writer also agrees with this statement. Pretty much anything you build with java, you can build faster with ruby on rails. So I'll probably stick with rails for a while.<p>Things might certainly be different for larger firms that have exhaustive developer resources to close the gap of developing time between java and ruby.
This doesn't make any sense. It's relatively easy to horizontally scale web servers. Perhaps at huge scale this would an issue, but I would imagine it's relatively easy for most developers to line up servers/instances behind a load balancer and have at it. The database is always going to be harder to scale because it holds state.
He makes an interesting point about disk latency; but network latency remains, and seems to be getting far worse due to assembling services to render a page.<p>Although his implicit point that users care about latency is correct, it may be that they care even more about other things - such as the information richness from combining those services; and indirectly, the entirely new webapps made possible by the flexibility of this modular approach. After all, they've put up with slowness for a long time. e..g historically, each time desktop became faster, users happily allowed it to be absorbed in to GUIs, layers and layers of modules, including C# and... Java.<p>Even if he's right, we might go back to Java the same way we went back to Perl...
I think he's correct in pointing out the trend of faster disk seeks and database accesses. But I don't think he's right in his assessment about Java (the language) coming back. Java's not the only game in town on the JVM anymore. Clojure and Scala are options.<p>Developers would do away with databases if they could, and just use data structures since objects don't map well to relational (ORM problem). So I think as disk access gets faster, either languages will move away from objects, or storage will move away from relational. And the techniques of ORM will only be reserved for really big data.
I will agree with what he says about Ruby. When you think of Ruby you think of Rails, an amazing framework with amazing things that I wish was in Django. As Javascript becomes more powerful I feel like we won't need server-side frameworks anymore. Everything will shift to the clientside, only requesting the server once with other requests for the database.<p>This becomes especially true with the existence of frameworks like backbone and new languages like Coffeescript that make Javascript exponentially easier.
> These are slow as molasses<p>Not really, with stuff like Python, your bottleneck is most likely going to be I/O and data reading/writing.<p>> You can replace Ruby here with Python, Django or Groovy and it is still correct.<p>Nope, with Python, unless you're using Django, most of your stuff is done with Python - there are frameworks like Flask but they provide a minimal set of tools to work with web concepts like routing and sessions.<p>CPU won't be the bottleneck until storage is as fast as CPUs. SSDs close the gap a tiny bit, but nowhere near enough.
<i>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.</i><p>This seems like an unfair generalization. I have come across many large non-Rails Ruby projects, e.g. Homebrew, CloudFoundry, Fog. A lot of reasons why Ruby and the like are good for web development also extend to other types of development.
SSDs really are going to change the game. As a Ruby developer, I'm hoping to see a new language created that is inspired by Ruby but is optimized for speed. Java will remain insufficiently aesthetic, but a new language could be both fast and pleasant to use. I know there are options out there, but none have appealed to me enough yet to consider leaving Ruby.
It is time like this that me more certain why frameworks like RingoJS or Helma.org is way way ahead of it's time. It use a dynamic scripting language (javascript), but sitting on top of JVM. The code are compile to byecode.<p>It has the best of both worlds. (Dynamic language and speed of java).
Ruby may seem easier to pick up than java, but it gets pretty complicated when you actually try to understand its power.<p>Try explaining eigenclasses to some java-only developers sometime.
The JVM is already seeing a resurgence with Scala/Clojure/etc.<p>What about the JIT projects? LuaJIT, Rubinius, PyPy and V8? All of these are close enough to Java to not matter.
Maybe Java not so much, but languages and frameworks that run in the JVM and are regarded as equals in the mind of the average CTO will definitely benefit over those languages that do not.<p>Keep in mind that Cringely provided no stats to compare and his ideas of what goes on in Rubyland are similar to those of a Luddite newspaper columnist refusing to upgrade his iPhone because of the kids on the Facebooks.<p>Mr. Cringely, the cool kids have grown up.
I'm really tired of language debates when 90% of effort goes into libraries, APIs, and IDE/editor integration, not the language itself. I'd take modern C++ over, say, PHP, as long as I get to use some really awesome, common, standardized web server library.<p>If Java becomes the new hotness again, it will be only marginally due to performance, and primarily due to the endless cycles of "new hotness" and obsessiveness in the industry.
I never pay much attention to anything that John Dvorak says. He doesn't seem to have much knowledge or insight into the industry, especially at a technical level. But he sure gets a lot of press when he says anything because he knows how to craft articles that have the sheen of seeming technical cluefulness and sophistication and contain just enough of a troublesome morsel of conflict to raise eyebrows and draw attention. But ultimately it tends to be little more than questionably founded pablum.