
Cringely predicts the second coming of Java - keveman
http://www.cringely.com/2011/10/the-second-coming-of-java/
======
Spyro7
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.)

An entire article about web development past, present, and future without a
single mention of PHP....

All snark aside, I strongly disagree with several things in this article.

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.

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.

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.

And finally:

<http://www.paulgraham.com/avg.html>

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.

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.

 _Edit: When I say Java, I refer to the language - just as Cringely does in
this article._

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

~~~
mattmanser
What's odd is that here in the UK it's C# dominating the enterprise landscape.
Or at least that's the impression I've always got from the jobs mentioned to
me and the developers I've met. I've met PHP, C#, Python, Rails devs but never
a Java developer.

The thing about .Net not being awesome compared to Java, it wasn't but that's
not true any more, .Net _is_ awesome compared to Java. There's a hell of a
team behind the C# language at the moment and they're about 3-4 years ahead of
Java in terms of new language features.

Not that I've any delusions about .Net coming to dominate in the web space,
but it's more likely than Java imo which looks old now when I read it, though
admittedly I don't keep up on it that well.

~~~
jcromartie
C# is in demand, because C# developers are rarer. Also it's a more interesting
language to work in and has features that attract smart developers.

Java developers are abundant, and mostly employed in the dark corners of big
enterprise software shops you've never heard of.

~~~
rbanffy
I have seen some very dark corners reserved for C# programmers around
Sharepoint deployments...

~~~
rjd
I worked on a major financial application that had a consumer front end
written in share point... it was horrific... easily the worst thing I had seen
in 15 years of developing.

The guys that put it together created a situation where there multiple front
ends to one database. Each front end generated GUIDs and rammed them into the
shared database. My work was to fix the sync'ing problem derived from this.

Most poeple I know refer to it as scare point now, as it scares most
developers ;)

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

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.

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.

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!

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.

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.

~~~
ArbitraryLimits
The last time I paid attention to the Java vs Lisp vs C++ discussion, the
shibboleth about JVM memory usage was that the JVM pre-allocated lots of
memory to optimize for the case where the application was going to be big and
long lived, at the cost of longer start up times and bad memory usage
benchmarks for toy programs. I was under the impression that huge JVM
footprints were mostly because of this pre-allocation behavior, not because
the JVM itself uses lots of memory to maintain itself - am I wrong?

~~~
angelbob
Both. JVM also allocates a lot of memory (relatively) for even its smallest
objects (round sizes up, frequent boxing and copying of primitives, everybody
gets an automatic mutex), and fragments significantly because it has good
garbage collectors that deal fine with that.

A _lot_ of Java is optimized for this, and it would take a fair bit of work to
make a JVM (and compiler!) implementation that changed the behavior
pervasively.

Java assumes memory is cheap at many levels. And usually, it's right.

~~~
jshen
"Java assumes memory is cheap at many levels. And usually, it's right."

I would say it's usually wrong. Imagine how much ram you'd need if all of your
GUI apps were on the JVM. Imagine how much ram you'd need if '$ cat blah.txt |
grep "something" | uniq | sort' were all JVM processes. Etc, etc, etc.

It seems to only be right for long lived server side processes that have
enough load to make it a benefit.

~~~
angelbob
You wouldn't architect that in that way in JVM. Instead, you'd use threads
rather than processes, use heavier-weight but more capable tools and so on.

The JVM is not The Unix Way. You have to do things differently - and in Java-
land, they do.

It's not really my thing either, but it's not as bad as you'd think if you
just pretend we're mapping all our existing Unix stuff, unchanged, into Java.

~~~
jshen
Right, and my point is that the JVM way only fits a narrow range of use cases.
Primarily long running server side processes.

------
Zak
I think Cringley is setting up a false dilemma here: that you can have fast or
high-level but not both.

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

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.

~~~
ArbitraryLimits
> Lua is a lot like Ruby or Python but about an order of magnitude faster

I'm surprised to hear either of those statements, both that Lua is a lot like
Python and that it's an order of magnitude faster. Now, the last time I
seriously looked at Lua was for my master's thesis work about four years ago,
so I'm willing to believe that my impression of Lua is out of date. However,
my experience on using it for a medium-sized project was that it is nothing
like Python. My procedure for programming is

    
    
      1) think of semantic construct,
    
      2) think of how to express this construct in this language
    
      3) type it in
    

My experience with Python is that step (2) is almost automatic - for whatever
reason, every construct I'm used to using has a clear, terse expression in
Python. And I've never spent an extended period writing Python, so I don't
think it's because Python has really shaped the way I think. (The closest
analogue to Python programming is using the STL in C++, in my experience.)

With Lua I had exactly the opposite experience. Every time it came to step
(2), it felt like what I wanted to say was _almost_ expressible in idiomatic
Lua, but not quite. It just felt like I was running a race with a 50 pound
backpack the whole time. Every time I tried to write a Lua script, I'd
eventually throw up my hands and write my program in Python instead.

Now, it's certainly possible that I just never really understood Lua's
paradigm that well, and that if I'd kept going I would eventually have reached
enlightenment. I don't think so, though - tables just aren't that hard,
oonceptually. However, the point is that, out of the box, Python gives me by
far the least cognitive friction and Lua by far the most of any programming
language I've ever used. I therefore have to strongly disagree that Python and
Lua have much in common other than a small overlap in the niche they each
fill.

And as for the order of magnitude speed difference, I find that hard to
believe. Again, my information may be out of date, but when I looked at it Lua
converted all numbers to double precision floating point numbers internally,
which dragged its integer benchmarks down quite a bit. (In fairness, I think
that was the same time frame where Python could only use primitive integers
for the numbers 0-99, and had to box everything else.)

~~~
andolanra
Lua is much faster than Ruby/Python/Perl/&c. It still doesn't get close even
to the higher-level compiled languages like Common Lisp and Haskell, but e.g.
the programming language shootout [1] makes it pretty clear that Lua is still
a league above the other dynamic languages. For just a quick result, I tried
timing just the Hello World program in Python, Ruby, and Lua, and while
startup time isn't going to be the bottleneck of the world of modern web
development, it's still a telling result:

    
    
        $ time python2.7 -c "print 'Hello, world'"
        
        real        0m0.107s
        user        0m0.080s
        sys         0m0.023s
        $ time ruby -e "puts 'Hello, world'"
        Hello, world
        
        real        0m0.338s
        user        0m0.030s
        sys	        0m0.013s
        $ time lua -e "print('Hello, world')"
        Hello, world
        
        real        0m0.008s
        user        0m0.000s
        sys         0m0.003s
    

That said, I kneejerk-ly agree with you about Lua being an awkward medium for
expressing programs. I personally haven't ever gotten to the status where Lua
was as natural as Python, but I have also used Python a great deal more, so I
don't know if my attitude is attributable to Lua's design, or Python's
plenitude of libraries, or merely the experience differential between the two.

[1]: <http://shootout.alioth.debian.org/>

EDIT: Converted some tabs to spaces. (Nitpicky, I know.)

~~~
jebblue
My timings where different on my 6 yr old Pentium D dual core, Ubuntu 64 bit:

    
    
      time python2.7 -c "print 'Hello, world'" && time ruby -e     
      "puts 'Hello, world'" && time lua -e "print('Hello, 
      world')"
    
      Hello, world
    
       real	0m0.056s
       user	0m0.040s
       sys	0m0.000s
    
      Hello, world
    
       real	0m0.008s
       user	0m0.000s
       sys	0m0.000s
     
      Hello, world
    
       real	0m0.061s
       user	0m0.000s
       sys	0m0.010s

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

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

In other words, if you eliminated the Django community there would still be a
large Python community.

~~~
StuffMaster
Perhaps he's never heard of Google or Red Hat or science. Maybe he should
google Google on...google.

~~~
Locke1689
Hmm... aside from the SketchUp scripts, I don't remember a whole lot of Google
projects written in Ruby. Do you have a source for that?

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

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

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.

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

Wow. I completely disagree with this. I stopped reading after that.

~~~
dlikhten
I have to correct a few other things in his post.

a) There are shittons of frameworks for Ruby. Rails is definitely not the only
one, its just most popular. Most good libraries are framework indepenedent and
have plugins into that framework. One example is Guard or CarrierWave. The
elegance of it all is what separates it from java.

b) Much easier and faster to develop for. allows for rapid prototyping and
mutations. Writing front-end servers in ruby > writing front-end servers in
java as ruby can do things in 1 line that take 50 in java.

c) As we see with facebook, sometimes a "slow" front-end written in a
prototyping language is better, but the back-end is written in a performant
language.

d) The power of ruby/rails is the community. That is it's number one source of
power and without it, rails is crap. There is a lot of Java developers, yet
the awesome java frameworks are things like hadoop, meant for data processing.

I don't think there will be a "second coming" of java. I think Java will die,
but the JVM (will probably) live on. Either that or the JVM will die to be
replaced by something the community makes, if oracle has any say in the
matter, knowing how oracle is doing everything possible to alienate java.

However there will be no second coming of java because it never left. Java is
still going strong within the rails community as most are fully aware that you
write your application in ruby, and anything important that has to be
performant will be written in java. There's just no alternative.

~~~
umjames
Who says the performant code has to be written in Java? It could be another
JVM language (Twitter is using Scala for this), or it could be some other non-
JVM language if that language better fits the situation's needs.

Cringely's post is pure link bait (or even flame bait). I feel sorry for those
who read the post as if the author is knowledgable about this subject matter.
Picture the IT manager or CIO who reads that and thinks their continued
investment in Java as the "one language to rule them all" was a good decision.
That person would be better served reading Steve Yegge's platform rant from
earlier today.

No one language is equally great at solving every foreseeable problem. The
only good answer is not to be afraid of using multiple languages/technology
stacks and be prepared to replace existing pieces with ones that are better
when the time comes.

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

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.

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

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

But that's the crux of his argument. If storage speed improves by leaps and
bounds it becomes comparatively more expensive (from a performance standpoint)
to use these other languages. The terms of the tradeoff change.

~~~
micheljansen
Yes, but hardware will actually become cheaper and faster, not more expensive
and slower and therefore hardware resources also become less relevant. The
terms of the tradeoff actually change in favour of "easy" development
frameworks. It is true that Java will benefit from this more than Ruby and
friends will, but that doesn't really change the reasons people choose these
anyway (because it is not about performance, it is about labour).

~~~
nupark2
This is the same argument made when claiming that JS will catch up with native
app development.

It's a flawed argument: any solution that relies on 'hardware will get faster'
will only ever be able to catch up to yesterday's state of the art.

Meanwhile, the state of the art will move forward as it takes advantage of
increased resources or lower operational costs.

~~~
micheljansen
Yes, but what is the state of the art of most server-side web apps, really.
Even the most successful web apps don't do all that exciting stuff. Most are
just pushing data around and perform well enough with whatever tools you throw
at it. In many cases performance is simply not that much of an issue compared
to other factors such as development speed.

Javascript is a front-end technology and therefore it is really different and
not really suitable for comparison in this case.

------
illumen
Wow, this guys knowledge is wrong.

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.

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.

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.

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?

~~~
cygx
> Dynamic languages can be faster than C now, and are only improving.

You're a bit too enthusiastic here, imo. JIT compiled code can in theory
outperform AOT compiled code because of dynamic recompilation of hot code
paths. However, you can get some of the benefits of runtime code generation
via profile-guided and link-time optimizations without any runtime overhead.

In practice, no dynamic language is faster than C (AOT compilation), and they
rarely approach Java (AOT compilation to bytecode + JIT compilation to native
code) where raw performance is concerned.

~~~
artsrc
That was my view yesterday. Then I benchmarked some JavaScript (CoffeeScript)
code, and the same algo in C code and my world changed. I know that I could
have optimized my C code better (I don't think I even turned optimization on),
but I could have optimized my JavaScript better too.

~~~
supersillyus
That seems like a very small and somewhat flawed data point to be drawing any
conclusions from.

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

------
petercooper
I'm a Rubyist and I actually buy his basic argument, but the technical
_details_ 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.

~~~
stonemetal
He is a tech journalist, who has worked for infoworld and PBS. So far as I
know he hasn't written a line of code in his life.

------
KirinDave
This article is nonsense. It deserves nothing but ridicule.

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.

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.

There simply aren't causal links anywhere in this chain of argument.

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

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

a) They aren't necessarily the biggest bottleneck now

b) Even if they were a bottleneck, we still often have network transit time to
account for, making DB access still relatively dog slow.

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.

~~~
equalarrow
Yah, his arguments are silly.

Sure, Java is faster, but people left for/use Ruby (mostly Rails) because
making a web app in Java became horribly inefficient. I know, I did this for
years and left for that exact reason. Spring, Hibernate, jars that all used
different logging that leaked memory in different ways, _deploying_ , verbose
syntax - it all became too much for me.

I'm sure Scala will address some of these things, but if anything, I think
what will materialize is the _opposite_ of his argument. If anything, faster
'disks' and databases will just allow people to use Ruby or Python even more.
I'm not sure Ruby will ever be as fast as Java, but again, that's never the
reason why I left the Java world for Ruby/Rails. Productivity was.

------
lukifer
Does Cringely ever actually write code? And if not, why would we consider that
he has any degree of credibility on this topic?

~~~
Semiapies
I remember when Cringely was interesting; sadly, he's gone the John C. Dvorak
route of pulling stupid, provocative assertions out of his ass.

------
hopeless
(as a full-time Java and occasional wannabe Rail programmer)

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.

------
davesims
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 _most_ ) scaling issues
horizontally.

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.

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.

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?

~~~
alttab
This is why large web applications written in Ruby/Rails could easily port to
JRuby. In fact, we are looking at doing this for our server platform as the
initial performance numbers CRUSHED passenger/Rails. Our infrastructure guys
even suggested we may be able to decommission some of our servers based on
initial performance numbers.

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

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.

------
jroseattle
Good grief, please move this off the front page. The guy obviously doesn't
know what he's talking about.

~~~
Roboprog
Yes, but he's a popular journalist, who frequently makes some interesting
observations about the IT/tech industry _business_.

The entertainment and discussion value today, though, is that he is indeed
full of crap this time. Not saying you're wrong about his subject knowledge,
just why people are reading it.

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

------
zzzeek
This is an unbelievable post. We're going to move back to _Java_ ,
because..... _file access will suddenly be an order of magnitude faster_ ,
therefore dynamic languages will suddenly be _too slow_?

what form of crack is this ?

~~~
angelbob
Yeah. He's also assuming that fast file access equals fast databases, which is
partly true and partly utterly wrong.

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

------
socratic
This article appears to make the following argument:

1\. Ruby/Rails developers use Ruby/Rails even though it is slow because
storage access is slower (and thus the bottleneck).

2\. Storage access is about to get much faster as people switch from spinning
disks to SSDs.

3\. Therefore, people will start using faster performing languages because app
server language will become the bottleneck.

However, there are two questions I have about this argument:

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)?

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?

------
j_baker
When someone says things like this, I have to ask if they _really_ understand
the difference between a language and a framework:

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

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

~~~
joshhart
In a modern datacenter, network is significantly faster than disk. See Jeff
Dean's numbers everyone should know.
[http://www.google.com/imgres?q=google+numbers+everyone+shoul...](http://www.google.com/imgres?q=google+numbers+everyone+should+know&um=1&hl=en&sa=N&biw=1862&bih=1083&tbm=isch&tbnid=Z-o-
Fiwd8NGEMM:&imgrefurl=http://doubleclix.wordpress.com/2010/11/11/google-a-
study-in-scalability-and-a-little-systems-horse-
sense/&docid=h6N4kIPchU34oM&imgurl=http://doubleclix.files.wordpress.com/2010/11/numberseveryoneshouldknow.png&w=595&h=444&ei=jeGVTrtJrdSIAsmhuMQN&zoom=1&iact=rc&dur=313&sig=107667830273554061378&page=1&tbnh=135&tbnw=181&start=0&ndsp=56&ved=1t:429,r:0,s:0&tx=143&ty=81)

Databases are slow for many reasons. The most common is that your dataset
doesn't fit into memory.

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

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.

Things might certainly be different for larger firms that have exhaustive
developer resources to close the gap of developing time between java and ruby.

~~~
Roboprog
It's been 2005 since I worked on ASPX.NET & C#, but this was a different kind
of Evil than stuff like Struts. JSP/servlet setup isn't _too_ bad, but even
more clumsy slow stuff typically gets piled on top.

Rails is cool, though. But it's not what feeds the kids out here in
Sacramento. At least not yet.

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

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

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.

Even if he's right, we might go back to Java the same way we went back to
Perl...

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

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.

------
va_coder
Oracle's control over Java has seriously dampened my enthusiasm for it.

~~~
dsulli
Right. If someone builds something interesting enough to get on Oracle's
radar, then they become an obvious target for litigation. Doesn't make sense
to build anything with Java, when there are so many other free alternatives
available.

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

This becomes especially true with the existence of frameworks like backbone
and new languages like Coffeescript that make Javascript exponentially easier.

------
antihero
> These are slow as molasses

Not really, with stuff like Python, your bottleneck is most likely going to be
I/O and data reading/writing.

> You can replace Ruby here with Python, Django or Groovy and it is still
> correct.

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.

CPU won't be the bottleneck until storage is as fast as CPUs. SSDs close the
gap a tiny bit, but nowhere near enough.

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

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.

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

~~~
rbanffy
> As a Ruby developer, I'm hoping to see a new language created that is
> inspired by Ruby but is optimized for speed.

You don't need a new language - all you need is a better runtime. See what
PyPy does for Python. A good JIT also goes a long way - people forget how
terrible Java performance was in the late 90's.

------
oacgnol
The second coming of Java isn't Java, it's the JVM. Look at the rise of
Clojure, Scala, and other JVM-based languages.

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

It has the best of both worlds. (Dynamic language and speed of java).

------
JonnieCache
Ruby may seem easier to pick up than java, but it gets pretty complicated when
you actually try to understand its power.

Try explaining eigenclasses to some java-only developers sometime.

~~~
hamidpalo
I have a hard time believing that Java developers would fail to understand the
concept of a singleton, the most pervasive anti-pattern in Java code.

~~~
JonnieCache
It isn't the same thing, despite the same name occasionally being used. It
also gets a lot more complex than expanded upon in the other comment.

Eg. what is the eigenclass of an eigenclass?

------
WALoeIII
The JVM is already seeing a resurgence with Scala/Clojure/etc.

What about the JIT projects? LuaJIT, Rubinius, PyPy and V8? All of these are
close enough to Java to not matter.

------
nikcub
Tough prediction to make considering it never went anywhere and Android is
everywhere now

------
mark242
The second coming of Java is already here. It's called Scala.

~~~
jebblue
If this is better then I guess I'll stick with Java:

    
    
      object HelloWorld {
        def main(args: Array[String]) {
          println("Hello, world!")
        }
      }
    

Different is != better, not in my view.

~~~
Ingaz
What's wrong in your example?

Do you prefer "public static void main" ?

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

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.

Mr. Cringely, the cool kids have grown up.

~~~
rbanffy
> regarded as equals in the mind of the average CTO

Your local average is better than my local average

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

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.

------
mike55
I don't understand. Now Ruby and database are slow, so it's OK to use Rails.
When a database is fast in future, I will stop using Rails, LOL.

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

