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.)
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.
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).
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.
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#.
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.
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.
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.
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?
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.
"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.
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.
Maintaining a garbage collector requires overhead, hence why C++ does not implement one as part of the language.
From my experience at University, the JVM uses an indirect method of accessing and storing objects. So each reference to an object is effectively a handle, hence as big as a pointer. It points to a table that contains the actual pointer to the object in memory (or something to that effect), so that the garbage collector can move the object in memory.
Therefore an object that just has a single integer will require 2 pointers and an integers worth of memory (at least). Any less than that and it would be garbage collected since there are no live references in the code to the object.
While that’s one way to do it, I believe that current JVMs use an index directly to the target object in the Java heap. Since the garbage collector is following all the references anyway, it can eventually update all the old references to point directly to an object after moving it.
In 64-bit VMs without a very large maximum heap size, the JVM usually uses "compressed" pointers, too, so 32-bit values can, in practice, address 32GB of data. Intel CPUs have addressing modes that work quite well with this. See: http://wikis.sun.com/display/HotSpotInternals/CompressedOops
Garbage collection isn’t free, but it’s getting pretty good.
I'm not sure where all the memory goes. My 'hello world' test app used around 30MB heap and 25+MB for permgen. It had a fair number of threads running, not sure what the overhead is there, but the process as a whole was using about 100MB. I couldn't make the heap any small without getting out of memory errors if I hit it with a light load.
edit: keep in mind this memory includes your app server, in my case I was using jetty.
Likely, most of those threads are HTTP request handlers. Try to let ab loose on your application and watch it's memory usage. I'm pretty sure you won't see any significant increase.
I agree that the JVM memory usage is a problem, but also because we are running out of memory bandwidth on modern architectures for many use cases.
While switching to immutable state and using things like STM can help in many ways in order to program all these cores that we are getting thrown at us, we pay with the memory bandwidth costs. Doing this stuff on the JVM surely makes the problem worse.
As VMs as well as multi-core and functional style become more popular I can't help feeling we need typical memory bandwidth of new systems to grow a bit faster.
I was going to start a new post but I think you covered most of the points I would have made anyway.
Reading that article just irritated me, how can someone make so many factual errors in one blog post?
He's never worked with Java to write a web application. Deployment xml configuration files can DIAFF.
He also completely missed the point why all of those Perl++ languages became popular, and it wasn't because disk speed slow/database slow so language being slow didn't matter, it was because you can genuinely get more out the door and tune your way out of performance issues (arguably :))
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.
> 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.
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?".
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.
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...
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).
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 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.
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.
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."
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.
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.
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.
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?
> 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.
Yes, for many workloads C/C++ is faster, and often lots faster. However, we are now close with dynamic languages for some workloads.
Dynamically typed languages are doing AOT compilation and also starting to get very good type inference, such that code is getting similar to C++ speeds. See the 'shedskin' rpython to C++ compiler, and the latest firefox JavaScript type inference work. PyPy has shown faster than C speeds for certain workloads. Also, the luajit2 project has shown faster than C speeds for certain workloads. This comes from being able to do full program optimisations at runtime over module boundaries which is not possible in C/C++.
C/C++ compilation is still much more advanced and faster in certain areas. Especially with auto vectorising, and a vast array of research and resources put into it that is far ahead of dynamic language developments.
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.
One of the things that hampers C is its string processing. By using a nul terminator, rather than an out of band length indicator (a la Pascal, Perl, Java) many string operations become a O(n) operation, where n = length of string, rather than a O(1). When running things such as cobbling up HTML templates and prepared SQL statements or evaluating DSLs, sucky string handling really starts to matter. Some would argue that it matters more than how fast you can calculate prime numbers or fibonacci sequences.
Big difference here between these two, check out a copy of "Deep C Secrets" by Peter van der Linden.
This is ok, safe, complete, reliable:
memset( s, '\0', sizeof( s) );
This yields the perception that it works, depending on what is going to make use of s later on, it could fail to do what you intended depending on how you use s:
This article is indeed cringe-worthy. Not because he's defending Java, but because of all the strong opinions clearly based on a weak understanding of what he's talking about.
I'm a Rubyist and I actually buy his basic argument, but the technical 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.
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.
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.
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.
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.
(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.
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?
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.
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.
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.
My best guess is that, as the bottleneck goes back into the application (and out of external dependencies like databases, disk, network), there will be an increasing pressure towards better multi-processor support (we are not going back to single cores anytime soon) and, of course, faster executable code. Unlike Cringely, my bet goes toward using more and more JIT'ed code (as in PyPy and v8) and better use of asynchronous APIs instead of lower-level languages. Of course, better integration with native code (as in "compiled from a reasonable language") will also be highly prized and a tool worth looking into.
This is an unbelievable post. We're going to move back to Java, because.....file access will suddenly be an order of magnitude faster, therefore dynamic languages will suddenly be too slow?
The JVM is going to be around for a long time. I'm thoroughly enjoying myself writing rails apps on jruby, bundling them as a WAR file, and then sticking them in tomcat. Too easy.
This article appears to make the following argument:
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?
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.
His argument is basically that slower dynamic languages like Ruby are popular because databases are slow, and databases are slow because disks are slow. But databases are not slow because of disk speeds. Disk access is pretty fast compared to network speeds. Databases are slow because of the join algorithms they use, because of the way data are structured, etc.
The writer's argument pretty much boils down to the claim that java will be faster than ruby on rails even more than now. For technical reasons why he claims this, read the article. I don't know enough to know if his technical claim is true or not, but here is why I won't be switching from rails to java anytime soon.
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.
This doesn't make any sense. It's relatively easy to horizontally scale web servers. Perhaps at huge scale this would an issue, but I would imagine it's relatively easy for most developers to line up servers/instances behind a load balancer and have at it. The database is always going to be harder to scale because it holds state.
He makes an interesting point about disk latency; but network latency remains, and seems to be getting far worse due to assembling services to render a page.
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...
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.)