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.
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.
Yes to this and the other comment mentioning joins being slow. If your $DYNAMIC-LANGUAGE is too slow - something that is kind of hard to achieve on today's servers - you just add another one (your frontend is running something like nginx anyway, right?).
Development speed is much more important. Some people are fast in Java, I am not.
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.
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.)
>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.
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).
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.
When application-server performance becomes the bottleneck, you'll see increased adoption of things like caching, JIT'ed languages and asynchronous approaches to distributing work across different threads.
I have experimented a lot with in-memory databases and, most of the time, they are still the bottleneck.
Even if all your databases are running at LUDICROUS SPEED thanks to SSDs, his argument is still irrelevant. That same LUDICROUS SPEED can be applied to technologies which can be used to mitigate the computational times of slower languages (e.g. caching)
Faster permanent storage will only help to close the ENROMOUS GAP between disk access latency, RAM access latency, and CPU cache access latency, which has continued to grow over time.
As Cliff Click said: RAM is the new disk. The real place languages like Ruby are suffering is through excessive object creation and mutation which blows the CPU cache. That would be a cogent argument. SSDs = LUDICROUS SPEED does not.
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.
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.
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.
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.
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.
>> knowing how oracle is doing everything possible to alienate java
I'm an optimist, I think I'm seeing indications that Oracle might back off and give this thing the room it needs to grow. Larry Ellison is growing older and though it's not always the case, he may be growing a bit wiser.
On top of Ruby we put the Rails web framework. It’s not very common to actually code anything in Ruby.
Is he really confusing programming languages with frameworks? I can't take anything serious that he writes anyways but that's pretty ignorant.
Even if it weren't an absurd statement you could say the same thing about Java, "on top of Java we put the Struts web framework. It's not very common to code anything in Java."
Easy code is easy, but intricate Ruby code is way way more complex and hard to write and understand than intricate Java code is. I reject the notion that Ruby, is in any way easier than Java.
Actually, I think the ease with which you can learn and code Java is one of the reasons for its success. The idea that Java programmers, by and large, are more experienced and skilled than those who use dynamic languages is preposterous, imho.
For years now, Java has been the first language you learn in academic settings. It's certainly isn't true that Java is something you only learn a few years into your career.
Cringely simply doesn't know his ass from his face on this topic. Who would'a thunk it.
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.
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.
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.
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.
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.
His basic argument is that slow languages (sure, I'll concede that) are only useful when you spend a lot of time blocking on disk seeks. This isn't true at all. Many Rails applications that are at scale (e.g. Twitter) don't have to hit disks to process requests and serve the bulk of the data for their requests out of in-memory systems such as memcached or Redis.
SSDs are fast, but they aren't going to be faster than the in-memory systems which are already in widespread usage among Ruby developers.
(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.
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.
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.
Please don't take what Cringely has to say as an accurate barometer of the Ruby community.
While I'll freely admit that Rails (and web applications in general) is an enormous part of what people are using Ruby for, it's used for many non-web things as well (although perhaps not to the same degree as Python)
Ever seen one of those satellite maps of the US at night that NOAA produces? That was made with Ruby. Just another off-the-cuff example: JRuby powers the HBase console.
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.
We could say that, but since LuaJIT isn't the default implementation, it's important to specify or people doing fact-checking might reasonably point out the claim as an error.
Edit: the deleted post said, essentially "Why not just say that Lua is as fast as Java?".
I would counter by pointing out that while that is true, the sorts of programmers who might use Node.js are dwarfed by the armies of incompetent untrained PHP developers out there. The HN crowd doesn't really give you a good window into reality in this case.
I also don't think that languages should worry about becoming "mainstream" for exactly that reason...
Of the languages I mentioned, only Haskell is functional, though I'll concede that Common Lisp isn't very likely to become mainstream either.
Lua, on the other hand is a relatively procedural scripting language. It can support functional programming if you want (it has closures and tail-call elimination), but that isn't the default. It doesn't even have map/reduce/filter in the standard library (I think it should).
I also dispute your claim fundamentally. Research-oriented languages like Haskell probably won't go mainstream, but a mostly-functional paradigm is very natural for web development. A GET request is naturally a pure function (it takes an HTTP request and returns a page). A POST can often be purely functional except for the bit at the end where it creates, updates or deletes a value. Languages and frameworks that encourage that style of thinking make it much easier to avoid creating a complex monstrosity.
This is an unusual statement to make, because in practice in the last decade, Java-based solutions are nowhere near 100x as fast as Perl/Python/Ruby based solutions; in fact I've found them generally to be slower.
The difficulty lies in defining what 'fast' means. It's possible that the JVM is more highly optimized than, e.g., the perl bytecode engine, but the highly abstracted Java libraries (FactoryFactories etc.) tend to be far less efficient and have larger memory footprints and significantly more stack-passing than the equivalent ruby/python/perl equivalents.
The JVM is fast, and the Java language is usually the fastest language on the JVM when code is written with speed in mind. The fact that people often do slow things with Java because it's hard to write extensible Java any other way (or because they just like overengineering) doesn't mean the language isn't fast.
Personally, I think using Clojure is a great way to get speed in practice. Inner loops can be as fast as they are in Java (with ugly optimizations), and extensible idiomatic code is a light lighter weight.
Unfortunately while the language matters, the ecosystem matters even more.
It isn't enough that Java is fast -- if all the libraries you're using are slow. And if the libraries you're using are slow, maybe you're measuring the wrong thing ;)
My biggest gripe with Java is that it is basically useless for anything other than big-scale web applications. And for those kinds of apps, many companies still go for C++.
I mean really, for scripting the startup time makes you want to puke. For desktop apps, I've never seen a Java application that I liked because the GUI toolkits available are brain-dead, and because Java apps have this nasty habit of freezing the interface in response to user events. Also, all Java apps are freakishly huge in regards to memory usage. I've seen Python apps that are tolerable, but nerver Java. Eclipse, the golden example, makes me want to hurt myself.
For small web apps you can get decent performance out of Python/Ruby/PHP on a 512MB VPS -- 200 reqs/sec at least is really not a problem. If you need more than that, it means you're successful, so why not throw money at it?
What else? Android is using its own VM that's not-Java. This means you cannot use libraries that do bytecode manipulation, and is essentially what http://www.ikvm.net/ is doing on top of .NET or Mono.
So in what cases does Java really bring value?
Don't get me wrong; I would love to see Mono being popular for web apps for instance -- it's a kick-ass open-source VM, with performance mostly on par with Java, but using less resources and being a better citizen on Unix (kind of ironic if you think about the roots of Java).
> 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.)
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.
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
I just looked at the Alioth benchmarks and found that Lua (not JIT) is around three times faster than Python 3. I remember the differences being larger with Python 2.x, but I'm not going to take the time to look for those benchmarks. On one benchmark, Lua was much slower.
I barely know Python, though I've found it fairly easy to pick up and use when I've needed to. I know Ruby pretty well though, and I find Lua about as easy to use as Ruby.
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.
> 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.
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...
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.
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.
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.
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.
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.
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.)
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.
However, the JVM doesn't necessarily mean 'Java'. If you get free performance and more efficient development, there's no advantage to using a poorly architected inefficient runtime.
You've pretty much nailed why JRuby catches on so well. It's still not fast for a JVM language, but it's blazing for Ruby - plus you can call through to Java where you need/want it.
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.
Not from what I've seen. There are tons of Java jobs. There's good reason for that. I can run Java apps on any OS. That's pretty important. It runs fast these days. Eclipse totally rocks and most if not all of what you need is totally free in the Eclipse world.
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 ;)
That depends on the country. In the Balkans for example, there are more .NET than Java developers, though both of them are in high numbers. The thing is, a lot of students after graduating are trying to get a job as a .NET developer thinking that it's easier, and after that they stick to that job.
And the second sentence, I have to disagree with you. I can't find the link right now (when I find i'll give you another reply), but there was report on USA's most wanted ICT jobs for 2010, and it was sorted per regions in Top 5 format, and the common 3 out of 5 everywhere were: Java, SAP, Oracle. .NET was 4rd or 5th almost on all of them. Second, there are more big companies with Java departments than with .NET departments (and some of them have both).
I think the actual reason is not because of .NET awesomeness, Companies in UK have always invested in Microsoft technologies. I remember back in early 2000s, UK was the only place with a great demand for VB developers. and majority of the current work being advertised, involve rewriting the existing VB applications in C#.
In my experience C# the language is much better than Java the language, but the .NET ecosystem doesn't even close to Java's ecosystem of both open source and proprietary libraries and frameworks. There's been too many times where I had to write my own stuff for C#, where in Java it'd already be mature, fully tested, and free to use right away.
138 comments
[ 5.4 ms ] story [ 188 ms ] threadDatabases are slow for many reasons. The most common is that your dataset doesn't fit into memory.
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.
Development speed is much more important. Some people are fast in Java, I am not.
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.
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.)
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.
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.
Javascript is a front-end technology and therefore it is really different and not really suitable for comparison in this case.
I have experimented a lot with in-memory databases and, most of the time, they are still the bottleneck.
If anything it could mean the end of in-memory key/value stores (ie: memcached)
Faster permanent storage will only help to close the ENROMOUS GAP between disk access latency, RAM access latency, and CPU cache access latency, which has continued to grow over time.
As Cliff Click said: RAM is the new disk. The real place languages like Ruby are suffering is through excessive object creation and mutation which blows the CPU cache. That would be a cogent argument. SSDs = LUDICROUS SPEED does not.
Unless you outsource.
I hope you're not trying to say those are equivalent.
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.
...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.
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.
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.
I'm an optimist, I think I'm seeing indications that Oracle might back off and give this thing the room it needs to grow. Larry Ellison is growing older and though it's not always the case, he may be growing a bit wiser.
Is he really confusing programming languages with frameworks? I can't take anything serious that he writes anyways but that's pretty ignorant.
Even if it weren't an absurd statement you could say the same thing about Java, "on top of Java we put the Struts web framework. It's not very common to code anything in Java."
Actually, I think the ease with which you can learn and code Java is one of the reasons for its success. The idea that Java programmers, by and large, are more experienced and skilled than those who use dynamic languages is preposterous, imho.
For years now, Java has been the first language you learn in academic settings. It's certainly isn't true that Java is something you only learn a few years into your career.
Cringely simply doesn't know his ass from his face on this topic. Who would'a thunk it.
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.
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.
Rails is cool, though. But it's not what feeds the kids out here in Sacramento. At least not yet.
SSDs are fast, but they aren't going to be faster than the in-memory systems which are already in widespread usage among Ruby developers.
tl;dr: his argument is fucking bullshit
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.
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.
Your local average is better than my local average
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.
While I'll freely admit that Rails (and web applications in general) is an enormous part of what people are using Ruby for, it's used for many non-web things as well (although perhaps not to the same degree as Python)
Ever seen one of those satellite maps of the US at night that NOAA produces? That was made with Ruby. Just another off-the-cuff example: JRuby powers the HBase console.
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.
Edit: the deleted post said, essentially "Why not just say that Lua is as fast as Java?".
I also don't think that languages should worry about becoming "mainstream" for exactly that reason...
Lua, on the other hand is a relatively procedural scripting language. It can support functional programming if you want (it has closures and tail-call elimination), but that isn't the default. It doesn't even have map/reduce/filter in the standard library (I think it should).
I also dispute your claim fundamentally. Research-oriented languages like Haskell probably won't go mainstream, but a mostly-functional paradigm is very natural for web development. A GET request is naturally a pure function (it takes an HTTP request and returns a page). A POST can often be purely functional except for the bit at the end where it creates, updates or deletes a value. Languages and frameworks that encourage that style of thinking make it much easier to avoid creating a complex monstrosity.
The difficulty lies in defining what 'fast' means. It's possible that the JVM is more highly optimized than, e.g., the perl bytecode engine, but the highly abstracted Java libraries (FactoryFactories etc.) tend to be far less efficient and have larger memory footprints and significantly more stack-passing than the equivalent ruby/python/perl equivalents.
Personally, I think using Clojure is a great way to get speed in practice. Inner loops can be as fast as they are in Java (with ugly optimizations), and extensible idiomatic code is a light lighter weight.
It isn't enough that Java is fast -- if all the libraries you're using are slow. And if the libraries you're using are slow, maybe you're measuring the wrong thing ;)
My biggest gripe with Java is that it is basically useless for anything other than big-scale web applications. And for those kinds of apps, many companies still go for C++.
I mean really, for scripting the startup time makes you want to puke. For desktop apps, I've never seen a Java application that I liked because the GUI toolkits available are brain-dead, and because Java apps have this nasty habit of freezing the interface in response to user events. Also, all Java apps are freakishly huge in regards to memory usage. I've seen Python apps that are tolerable, but nerver Java. Eclipse, the golden example, makes me want to hurt myself.
For small web apps you can get decent performance out of Python/Ruby/PHP on a 512MB VPS -- 200 reqs/sec at least is really not a problem. If you need more than that, it means you're successful, so why not throw money at it?
What else? Android is using its own VM that's not-Java. This means you cannot use libraries that do bytecode manipulation, and is essentially what http://www.ikvm.net/ is doing on top of .NET or Mono.
So in what cases does Java really bring value?
Don't get me wrong; I would love to see Mono being popular for web apps for instance -- it's a kick-ass open-source VM, with performance mostly on par with Java, but using less resources and being a better citizen on Unix (kind of ironic if you think about the roots of Java).
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
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.)
[1]: http://shootout.alioth.debian.org/
EDIT: Converted some tabs to spaces. (Nitpicky, I know.)
That said, startup times are often not as important as other metrics.
I barely know Python, though I've found it fairly easy to pick up and use when I've needed to. I know Ruby pretty well though, and I find Lua about as easy to use as Ruby.
http://luajit.org/performance_x86.html
http://luajit.org/performance.html
That said, I do agree that Lua can be more cumbersome than Python or Ruby.
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.
I have heard this and I agree with the other posters here who are skeptical on this core point.
For read performance you cache databases in RAM.
For write performance you have writes to log structured storage system.
And either way if you care about your data, you replicate it to multiple datacenters and kill performance.
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...
Do you prefer "public static void main" ?
What about the JIT projects? LuaJIT, Rubinius, PyPy and V8? All of these are close enough to Java to not matter.
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.
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.)
However, the JVM doesn't necessarily mean 'Java'. If you get free performance and more efficient development, there's no advantage to using a poorly architected inefficient runtime.
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.
Java developers are abundant, and mostly employed in the dark corners of big enterprise software shops you've never heard of.
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 ;)
And the second sentence, I have to disagree with you. I can't find the link right now (when I find i'll give you another reply), but there was report on USA's most wanted ICT jobs for 2010, and it was sorted per regions in Top 5 format, and the common 3 out of 5 everywhere were: Java, SAP, Oracle. .NET was 4rd or 5th almost on all of them. Second, there are more big companies with Java departments than with .NET departments (and some of them have both).
God, what a flashback. Seems like yesterday people were saying left and right that java has no chance because it's an interpreted language.