5 ms·

Cringely predicts the second coming of Java

169 points by keveman 15y ago

bluekeybox 15y ago
His argument is basically that slower dynamic languages like Ruby are popular because databases are slow, and databases are slow because disks are slow. But databases are not slow because of disk speeds. Disk access is pretty fast compared to network speeds. Databases are slow because of the join algorithms they use, because of the way data are structured, etc.
- joshhart 15y ago
  In a modern datacenter, network is significantly faster than disk. See Jeff Dean's numbers everyone should know. http://www.google.com/imgres?q=google+numbers+everyone+should+know&um=1&hl=en&sa=N&biw=1862&bih=1083&tbm=isch&tbnid=Z-o-Fiwd8NGEMM:&imgrefurl=http://doubleclix.wordpress.com/2010/11/11/google-a-study-in-scalability-and-a-little-systems-horse-sense/&docid=h6N4kIPchU34oM&imgurl=http://doubleclix.files.wordpress.com/2010/11/numberseveryoneshouldknow.png&w=595&h=444&ei=jeGVTrtJrdSIAsmhuMQN&zoom=1&iact=rc&dur=313&sig=107667830273554061378&page=1&tbnh=135&tbnw=181&start=0&ndsp=56&ved=1t:429,r:0,s:0&tx=143&ty=81 http://www.google.com/imgres?q=google+numbers+everyone+shoul... Databases are slow for many reasons. The most common is that your dataset doesn't fit into memory.
mindstab 15y ago
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.
- teh 15y ago
  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.
- deleted 15y ago
  [deleted]
- equalarrow 15y ago
  Yah, his arguments are silly. Sure, Java is faster, but people left for/use Ruby (mostly Rails) because making a web app in Java became horribly inefficient. I know, I did this for years and left for that exact reason. Spring, Hibernate, jars that all used different logging that leaked memory in different ways, deploying, verbose syntax - it all became too much for me. I'm sure Scala will address some of these things, but if anything, I think what will materialize is the opposite of his argument. If anything, faster 'disks' and databases will just allow people to use Ruby or Python even more. I'm not sure Ruby will ever be as fast as Java, but again, that's never the reason why I left the Java world for Ruby/Rails. Productivity was.
micheljansen 15y ago
The whole argument is flawed. First of all, Java never left. It is still used widely in "Enterprise" environments where it powers complex architectures with a lot of XML. Secondly, Ruby on Rails and other dynamic frameworks are not popular because their performance issues can easily be discarded compared to Java. They are popular because they make a tradeoff between development speed and execution speed. Better hardware may change that tradeoff slightly, but human labor will likely still be more expensive than the servers running the applications, so this changes nothing. I don't think Java will disappear from the web any time soon. It is way too pervasive for that. I see it more like the new COBOL: in 100 years, people will still be interfacing with ancient Java apps, only to move on as soon as possible to more modern environments (that may or may not still use the JVM for their execution.)
- tsotha 15y ago
  >Secondly, Ruby on Rails and other dynamic frameworks are not popular because their performance issues can easily be discarded compared to Java. They are popular because they make a tradeoff between development speed and execution speed. But that's the crux of his argument. If storage speed improves by leaps and bounds it becomes comparatively more expensive (from a performance standpoint) to use these other languages. The terms of the tradeoff change.
  - micheljansen 15y ago
    Yes, but hardware will actually become cheaper and faster, not more expensive and slower and therefore hardware resources also become less relevant. The terms of the tradeoff actually change in favour of "easy" development frameworks. It is true that Java will benefit from this more than Ruby and friends will, but that doesn't really change the reasons people choose these anyway (because it is not about performance, it is about labour).
    - nupark2 15y ago
      This is the same argument made when claiming that JS will catch up with native app development. It's a flawed argument: any solution that relies on 'hardware will get faster' will only ever be able to catch up to yesterday's state of the art. Meanwhile, the state of the art will move forward as it takes advantage of increased resources or lower operational costs.
pashields 15y ago
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.
mark_l_watson 15y ago
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.
typicalrunt 15y ago
I get the feeling he is making the common mistake of comparing Java with JVM. Java, as a language, is fine but many other languages (Ruby, Python) run on top of the JVM and have very good execution times (plus multi-core support). ...languages like Ruby. These are slow as molasses (though now our CPUs are much faster) but easy to program for a broader, younger, and maybe less experienced crowd of developers. Something about this rubs me the wrong way, and smacks of elitism. I've seen some amazing code from the Ruby community yet I feel he is confusing a language's learning curve with the experience of its development community. Under Ruby, we put C++. On top of Ruby we put the Rails web framework. It’s not very common to actually code anything in Ruby. Wow. I completely disagree with this. I stopped reading after that.
- dlikhten 15y ago
  I have to correct a few other things in his post. a) There are shittons of frameworks for Ruby. Rails is definitely not the only one, its just most popular. Most good libraries are framework indepenedent and have plugins into that framework. One example is Guard or CarrierWave. The elegance of it all is what separates it from java. b) Much easier and faster to develop for. allows for rapid prototyping and mutations. Writing front-end servers in ruby > writing front-end servers in java as ruby can do things in 1 line that take 50 in java. c) As we see with facebook, sometimes a "slow" front-end written in a prototyping language is better, but the back-end is written in a performant language. d) The power of ruby/rails is the community. That is it's number one source of power and without it, rails is crap. There is a lot of Java developers, yet the awesome java frameworks are things like hadoop, meant for data processing. I don't think there will be a "second coming" of java. I think Java will die, but the JVM (will probably) live on. Either that or the JVM will die to be replaced by something the community makes, if oracle has any say in the matter, knowing how oracle is doing everything possible to alienate java. However there will be no second coming of java because it never left. Java is still going strong within the rails community as most are fully aware that you write your application in ruby, and anything important that has to be performant will be written in java. There's just no alternative.
  - umjames 15y ago
TelmoMenezes 15y ago
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.
KirinDave 15y ago
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.
jsnk 15y ago
The writer's argument pretty much boils down to the claim that java will be faster than ruby on rails even more than now. For technical reasons why he claims this, read the article. I don't know enough to know if his technical claim is true or not, but here is why I won't be switching from rails to java anytime soon. I previously worked with c# and asp.net which may be comparable to java in many regards. I currently work with rails. In my experience, the ability to build rapid prototypes with rails simply trumps marginal gain you might get out of performance improvement with .net or java frameworks. I think the writer also agrees with this statement. Pretty much anything you build with java, you can build faster with ruby on rails. So I'll probably stick with rails for a while. Things might certainly be different for larger firms that have exhaustive developer resources to close the gap of developing time between java and ruby.
- Roboprog 15y ago
  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.
petercooper 15y ago
I'm a Rubyist and I actually buy his basic argument, but the technical details are out of date/wrong and it reduces his credibility. I don't know if Cringely is a developer but it doesn't read as if he is and his point would have been better made from a higher level rather than playing the trendy dynamic language-bashing card.
- stonemetal 15y ago
  He is a tech journalist, who has worked for infoworld and PBS. So far as I know he hasn't written a line of code in his life.
- deleted 15y ago
  [deleted]
- bascule 15y ago
  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. tl;dr: his argument is fucking bullshit
hopeless 15y ago
(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.
jsavimbi 15y ago
Maybe Java not so much, but languages and frameworks that run in the JVM and are regarded as equals in the mind of the average CTO will definitely benefit over those languages that do not. Keep in mind that Cringely provided no stats to compare and his ideas of what goes on in Rubyland are similar to those of a Luddite newspaper columnist refusing to upgrade his iPhone because of the kids on the Facebooks. Mr. Cringely, the cool kids have grown up.
- rbanffy 15y ago
  > regarded as equals in the mind of the average CTO Your local average is better than my local average
chr15 15y ago
You pretty much only see people coding Ruby while using the Rails framework which governs the whole thing. You can replace Ruby here with Python, Django or Groovy and it is still correct. This is certainly not the case with Python. Python has a huge community outside of Django and is used in the scientific, academic, and financial communities (see NumPy, NLTK, Bazaar). In other words, if you eliminated the Django community there would still be a large Python community.
- StuffMaster 15y ago
  Perhaps he's never heard of Google or Red Hat or science. Maybe he should google Google on...google.
  - Locke1689 15y ago
    Hmm... aside from the SketchUp scripts, I don't remember a whole lot of Google projects written in Ruby. Do you have a source for that?
- Fluxx 15y ago
  As does Ruby. Rails certainly is the biggest and most famous Ruby project, but there are tons of other great projects in Ruby.
- bascule 15y ago
  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.
lukifer 15y ago
Does Cringely ever actually write code? And if not, why would we consider that he has any degree of credibility on this topic?
- Semiapies 15y ago
  I remember when Cringely was interesting; sadly, he's gone the John C. Dvorak route of pulling stupid, provocative assertions out of his ass.
Zak 15y ago
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.
- deleted 15y ago
  [deleted]
  - Zak 15y ago
    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?".
  - tomjen3 15y ago
    One of the things Lua was designed to do was to be easy to embed. You don't necessarily want to embed a JIT compiler too.
- mattmanser 15y ago
  Let's be honest though, there's 0% chance of functional languages becoming mainstream in web development.
  - rbanffy 15y ago
    The canonical way to program for Node.js is very functional.
    - burgerbrain 15y ago
joelmichael 15y ago
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.
- onenine 15y ago
  I'd recommend you checkout mirah (ruby inspired but compiles to jvm bytecode).
- rbanffy 15y ago
  > 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.
- artsrc 15y ago
  > SSDs really are going to change the game. 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.
6ren 15y ago
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...
rbanffy 15y ago
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.
mark242 15y ago
The second coming of Java is already here. It's called Scala.
- jebblue 15y ago
  If this is better then I guess I'll stick with Java: object HelloWorld { def main(args: Array[String]) { println("Hello, world!") } } Different is != better, not in my view.
  - Ingaz 15y ago
    What's wrong in your example? Do you prefer "public static void main" ?
deleted 15y ago
[deleted]
mberning 15y ago
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.
WALoeIII 15y ago
The JVM is already seeing a resurgence with Scala/Clojure/etc. What about the JIT projects? LuaJIT, Rubinius, PyPy and V8? All of these are close enough to Java to not matter.
iamwil 15y ago
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.
InclinedPlane 15y ago
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.
Spyro7 15y ago
It's gotta be a slow day on hacker news when this is at the top page. (Or, is this being upvoted because it is Cringely.) An entire article about web development past, present, and future without a single mention of PHP.... All snark aside, I strongly disagree with several things in this article. Java never left, so it can hardly arrive again. Anyone that has ever worked in a corporate environment problably knows what I am talking about. Java dominates the Enterprise landscape. Disk speed limitations on database access times can be and has already been overcome by in-memory caching. This is not new. Advancing SSD tech will not suddenly lead to Java's total ascendance as a web development platform. The characterization of dynamic languages as "easy to program for a broader, younger, and maybe less experienced crowd of developers" is a rather unfortunate blanket generalization. This is especially the case because most people that I know that use dynamic languages usually have some experience in things like Java, C, C++ that Cringlely seems to hold in high regard. And finally: http://www.paulgraham.com/avg.html 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.)
- nupark2 15y ago
  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.
  - angelbob 15y ago
oacgnol 15y ago
The second coming of Java isn't Java, it's the JVM. Look at the rise of Clojure, Scala, and other JVM-based languages.
jshen 15y ago
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.
- bodski 15y ago
  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.
- malbs 15y ago
treenyc 15y ago
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).
davesims 15y ago
A rising tide raises all boats. Increased hardware and database speed will not make Rails less attractive it will make it more so. Far from exposing Ruby's sluggishness (which itself will be less and less of an issue), it will expose how easy it always was to solve most (I said most) scaling issues horizontally. The majority of the old "Rails doesn't Scale" canard was based on perception and CPU benchmarking that had little if anything to do with actual scaling issues in the real world. If -- if! -- SSD and other hardware advances remove the classic bottleneck for performance -- the Database -- then 1) the question of performance will become less of a political issue for departments, and there will be far less incentive to look for a scapegoat ("let's get rid of Rails then, it's slow, right??") and 2) in the majority of situations where latency is a problem for a Rails (or Django, etc.) deployment, then horizontal scaling becomes the simple solution, which in fact it always was. But the biggest reason to use a framework like Django/Rails, etc. will not go away with better hardware: time to market. Use of these frameworks has enabled a number of high-profile sites to get to market quickly recently and handle some heavy-duty traffic by any standards. Can you imagine a Groupon rolling out on top of a J2EE stack?
- alttab 15y ago
  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.
dillon 15y ago
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.
jroseattle 15y ago
Good grief, please move this off the front page. The guy obviously doesn't know what he's talking about.
- Roboprog 15y ago
  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.
socratic 15y ago
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?
illumen 15y ago
Wow, this guys knowledge is wrong. Dynamic languages can be faster than C now, and are only improving. Implementations like pypy, and luajit2 really are rocking. JavaScript implementations are also getting real fast. C++ doesn't need to use manual memory management, and hasn't for ages. You can use it, but it is optional. Perl was often mixed with C/C++ libraries, including mod_perl with apache - the real webserver written in C. With WebGL there is coming a massive amount of GPU power available to apps from JavaScript. Which also has available WebWorkers, which allow multi core use. As well, as vector instructions. The speed available for processing is truly amazing. There's just too much wrong in this article, so I'll just stop writing about it now. Usually I enjoy his articles, but this one is way off. On the other hand, maybe it is just a really good troll?
- cygx 15y ago
  > Dynamic languages can be faster than C now, and are only improving. You're a bit too enthusiastic here, imo. JIT compiled code can in theory outperform AOT compiled code because of dynamic recompilation of hot code paths. However, you can get some of the benefits of runtime code generation via profile-guided and link-time optimizations without any runtime overhead. In practice, no dynamic language is faster than C (AOT compilation), and they rarely approach Java (AOT compilation to bytecode + JIT compilation to native code) where raw performance is concerned.
  - artsrc 15y ago
    That was my view yesterday. Then I benchmarked some JavaScript (CoffeeScript) code, and the same algo in C code and my world changed. I know that I could have optimized my C code better (I don't think I even turned optimization on), but I could have optimized my JavaScript better too.
    - supersillyus 15y ago
      That seems like a very small and somewhat flawed data point to be drawing any conclusions from.
  - 15y ago
mike55 15y ago
I don't understand. Now Ruby and database are slow, so it's OK to use Rails. When a database is fast in future, I will stop using Rails, LOL.
JonnieCache 15y ago
Ruby may seem easier to pick up than java, but it gets pretty complicated when you actually try to understand its power. Try explaining eigenclasses to some java-only developers sometime.
- wycats 15y ago
  Every Ruby object is an instance of a singleton class that inherits from its declared class. # o is an instance of its singleton class, # which inherits from Object o = Object.new It is like saying: class Object def self.new(*args, &block) # Class.new(Object) creates an anonymous # subclass of Object Class.new(Object).new(*args, &block) end end except with built-in language support. Instead of having to do this manually, every object gets a singleton.
- hamidpalo 15y ago
  I have a hard time believing that Java developers would fail to understand the concept of a singleton, the most pervasive anti-pattern in Java code.
  - JonnieCache 15y ago
    It isn't the same thing, despite the same name occasionally being used. It also gets a lot more complex than expanded upon in the other comment. Eg. what is the eigenclass of an eigenclass?
georgieporgie 15y ago
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.
antihero 15y ago
> These are slow as molasses Not really, with stuff like Python, your bottleneck is most likely going to be I/O and data reading/writing. > You can replace Ruby here with Python, Django or Groovy and it is still correct. Nope, with Python, unless you're using Django, most of your stuff is done with Python - there are frameworks like Flask but they provide a minimal set of tools to work with web concepts like routing and sessions. CPU won't be the bottleneck until storage is as fast as CPUs. SSDs close the gap a tiny bit, but nowhere near enough.
va_coder 15y ago
Oracle's control over Java has seriously dampened my enthusiasm for it.
- dsulli 15y ago
  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.
zzzeek 15y ago
This is an unbelievable post. We're going to move back to Java, because.....file access will suddenly be an order of magnitude faster, therefore dynamic languages will suddenly be too slow? what form of crack is this ?
- angelbob 15y ago
  Yeah. He's also assuming that fast file access equals fast databases, which is partly true and partly utterly wrong.
nikcub 15y ago
Tough prediction to make considering it never went anywhere and Android is everywhere now
j_baker 15y ago
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.
ByteMuse 15y ago
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.

169 points by keveman 15y ago

His argument is basically that slower dynamic languages like Ruby are popular because databases are slow, and databases are slow because disks are slow. But databases are not slow because of disk speeds. Disk access is pretty fast compared to network speeds. Databases are slow because of the join algorithms they use, because of the way data are structured, etc.

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

mindstab 15y ago

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.

teh 15y ago
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.
deleted 15y ago
[deleted]
equalarrow 15y ago
Yah, his arguments are silly. Sure, Java is faster, but people left for/use Ruby (mostly Rails) because making a web app in Java became horribly inefficient. I know, I did this for years and left for that exact reason. Spring, Hibernate, jars that all used different logging that leaked memory in different ways, deploying, verbose syntax - it all became too much for me. I'm sure Scala will address some of these things, but if anything, I think what will materialize is the opposite of his argument. If anything, faster 'disks' and databases will just allow people to use Ruby or Python even more. I'm not sure Ruby will ever be as fast as Java, but again, that's never the reason why I left the Java world for Ruby/Rails. Productivity was.

micheljansen 15y ago

The whole argument is flawed. First of all, Java never left. It is still used widely in "Enterprise" environments where it powers complex architectures with a lot of XML. Secondly, Ruby on Rails and other dynamic frameworks are not popular because their performance issues can easily be discarded compared to Java. They are popular because they make a tradeoff between development speed and execution speed. Better hardware may change that tradeoff slightly, but human labor will likely still be more expensive than the servers running the applications, so this changes nothing. I don't think Java will disappear from the web any time soon. It is way too pervasive for that. I see it more like the new COBOL: in 100 years, people will still be interfacing with ancient Java apps, only to move on as soon as possible to more modern environments (that may or may not still use the JVM for their execution.)

tsotha 15y ago
>Secondly, Ruby on Rails and other dynamic frameworks are not popular because their performance issues can easily be discarded compared to Java. They are popular because they make a tradeoff between development speed and execution speed. But that's the crux of his argument. If storage speed improves by leaps and bounds it becomes comparatively more expensive (from a performance standpoint) to use these other languages. The terms of the tradeoff change.
- micheljansen 15y ago
  Yes, but hardware will actually become cheaper and faster, not more expensive and slower and therefore hardware resources also become less relevant. The terms of the tradeoff actually change in favour of "easy" development frameworks. It is true that Java will benefit from this more than Ruby and friends will, but that doesn't really change the reasons people choose these anyway (because it is not about performance, it is about labour).
  - nupark2 15y ago
    This is the same argument made when claiming that JS will catch up with native app development. It's a flawed argument: any solution that relies on 'hardware will get faster' will only ever be able to catch up to yesterday's state of the art. Meanwhile, the state of the art will move forward as it takes advantage of increased resources or lower operational costs.

pashields 15y ago

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.

mark_l_watson 15y ago

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.

typicalrunt 15y ago

I get the feeling he is making the common mistake of comparing Java with JVM. Java, as a language, is fine but many other languages (Ruby, Python) run on top of the JVM and have very good execution times (plus multi-core support). ...languages like Ruby. These are slow as molasses (though now our CPUs are much faster) but easy to program for a broader, younger, and maybe less experienced crowd of developers. Something about this rubs me the wrong way, and smacks of elitism. I've seen some amazing code from the Ruby community yet I feel he is confusing a language's learning curve with the experience of its development community. Under Ruby, we put C++. On top of Ruby we put the Rails web framework. It’s not very common to actually code anything in Ruby. Wow. I completely disagree with this. I stopped reading after that.

dlikhten 15y ago
I have to correct a few other things in his post. a) There are shittons of frameworks for Ruby. Rails is definitely not the only one, its just most popular. Most good libraries are framework indepenedent and have plugins into that framework. One example is Guard or CarrierWave. The elegance of it all is what separates it from java. b) Much easier and faster to develop for. allows for rapid prototyping and mutations. Writing front-end servers in ruby > writing front-end servers in java as ruby can do things in 1 line that take 50 in java. c) As we see with facebook, sometimes a "slow" front-end written in a prototyping language is better, but the back-end is written in a performant language. d) The power of ruby/rails is the community. That is it's number one source of power and without it, rails is crap. There is a lot of Java developers, yet the awesome java frameworks are things like hadoop, meant for data processing. I don't think there will be a "second coming" of java. I think Java will die, but the JVM (will probably) live on. Either that or the JVM will die to be replaced by something the community makes, if oracle has any say in the matter, knowing how oracle is doing everything possible to alienate java. However there will be no second coming of java because it never left. Java is still going strong within the rails community as most are fully aware that you write your application in ruby, and anything important that has to be performant will be written in java. There's just no alternative.
- umjames 15y ago

TelmoMenezes 15y ago

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.

KirinDave 15y ago

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.

jsnk 15y ago

The writer's argument pretty much boils down to the claim that java will be faster than ruby on rails even more than now. For technical reasons why he claims this, read the article. I don't know enough to know if his technical claim is true or not, but here is why I won't be switching from rails to java anytime soon. I previously worked with c# and asp.net which may be comparable to java in many regards. I currently work with rails. In my experience, the ability to build rapid prototypes with rails simply trumps marginal gain you might get out of performance improvement with .net or java frameworks. I think the writer also agrees with this statement. Pretty much anything you build with java, you can build faster with ruby on rails. So I'll probably stick with rails for a while. Things might certainly be different for larger firms that have exhaustive developer resources to close the gap of developing time between java and ruby.

Roboprog 15y ago
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.

petercooper 15y ago

I'm a Rubyist and I actually buy his basic argument, but the technical details are out of date/wrong and it reduces his credibility. I don't know if Cringely is a developer but it doesn't read as if he is and his point would have been better made from a higher level rather than playing the trendy dynamic language-bashing card.

stonemetal 15y ago
He is a tech journalist, who has worked for infoworld and PBS. So far as I know he hasn't written a line of code in his life.
deleted 15y ago
[deleted]
bascule 15y ago
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. tl;dr: his argument is fucking bullshit

hopeless 15y ago

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

jsavimbi 15y ago

Maybe Java not so much, but languages and frameworks that run in the JVM and are regarded as equals in the mind of the average CTO will definitely benefit over those languages that do not. Keep in mind that Cringely provided no stats to compare and his ideas of what goes on in Rubyland are similar to those of a Luddite newspaper columnist refusing to upgrade his iPhone because of the kids on the Facebooks. Mr. Cringely, the cool kids have grown up.

rbanffy 15y ago
> regarded as equals in the mind of the average CTO Your local average is better than my local average

chr15 15y ago

You pretty much only see people coding Ruby while using the Rails framework which governs the whole thing. You can replace Ruby here with Python, Django or Groovy and it is still correct. This is certainly not the case with Python. Python has a huge community outside of Django and is used in the scientific, academic, and financial communities (see NumPy, NLTK, Bazaar). In other words, if you eliminated the Django community there would still be a large Python community.

StuffMaster 15y ago
Perhaps he's never heard of Google or Red Hat or science. Maybe he should google Google on...google.
- Locke1689 15y ago
  Hmm... aside from the SketchUp scripts, I don't remember a whole lot of Google projects written in Ruby. Do you have a source for that?
Fluxx 15y ago
As does Ruby. Rails certainly is the biggest and most famous Ruby project, but there are tons of other great projects in Ruby.
bascule 15y ago
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.

lukifer 15y ago

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

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

Zak 15y ago

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.

deleted 15y ago
[deleted]
- Zak 15y ago
  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?".
- tomjen3 15y ago
  One of the things Lua was designed to do was to be easy to embed. You don't necessarily want to embed a JIT compiler too.
mattmanser 15y ago
Let's be honest though, there's 0% chance of functional languages becoming mainstream in web development.
- rbanffy 15y ago
  The canonical way to program for Node.js is very functional.
  - burgerbrain 15y ago

joelmichael 15y ago

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.

onenine 15y ago
I'd recommend you checkout mirah (ruby inspired but compiles to jvm bytecode).
rbanffy 15y ago
> 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.
artsrc 15y ago
> SSDs really are going to change the game. 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.

6ren 15y ago

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

rbanffy 15y ago

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.

mark242 15y ago

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

jebblue 15y ago
If this is better then I guess I'll stick with Java: object HelloWorld { def main(args: Array[String]) { println("Hello, world!") } } Different is != better, not in my view.
- Ingaz 15y ago
  What's wrong in your example? Do you prefer "public static void main" ?

deleted 15y ago

[deleted]

mberning 15y ago

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.

WALoeIII 15y ago

The JVM is already seeing a resurgence with Scala/Clojure/etc. What about the JIT projects? LuaJIT, Rubinius, PyPy and V8? All of these are close enough to Java to not matter.

iamwil 15y ago

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.

InclinedPlane 15y ago

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.

Spyro7 15y ago

It's gotta be a slow day on hacker news when this is at the top page. (Or, is this being upvoted because it is Cringely.) An entire article about web development past, present, and future without a single mention of PHP.... All snark aside, I strongly disagree with several things in this article. Java never left, so it can hardly arrive again. Anyone that has ever worked in a corporate environment problably knows what I am talking about. Java dominates the Enterprise landscape. Disk speed limitations on database access times can be and has already been overcome by in-memory caching. This is not new. Advancing SSD tech will not suddenly lead to Java's total ascendance as a web development platform. The characterization of dynamic languages as "easy to program for a broader, younger, and maybe less experienced crowd of developers" is a rather unfortunate blanket generalization. This is especially the case because most people that I know that use dynamic languages usually have some experience in things like Java, C, C++ that Cringlely seems to hold in high regard. And finally: http://www.paulgraham.com/avg.html 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.)

nupark2 15y ago
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.
- angelbob 15y ago

oacgnol 15y ago

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

jshen 15y ago

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.

bodski 15y ago
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.
malbs 15y ago

treenyc 15y ago

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

davesims 15y ago

A rising tide raises all boats. Increased hardware and database speed will not make Rails less attractive it will make it more so. Far from exposing Ruby's sluggishness (which itself will be less and less of an issue), it will expose how easy it always was to solve most (I said most) scaling issues horizontally. The majority of the old "Rails doesn't Scale" canard was based on perception and CPU benchmarking that had little if anything to do with actual scaling issues in the real world. If -- if! -- SSD and other hardware advances remove the classic bottleneck for performance -- the Database -- then 1) the question of performance will become less of a political issue for departments, and there will be far less incentive to look for a scapegoat ("let's get rid of Rails then, it's slow, right??") and 2) in the majority of situations where latency is a problem for a Rails (or Django, etc.) deployment, then horizontal scaling becomes the simple solution, which in fact it always was. But the biggest reason to use a framework like Django/Rails, etc. will not go away with better hardware: time to market. Use of these frameworks has enabled a number of high-profile sites to get to market quickly recently and handle some heavy-duty traffic by any standards. Can you imagine a Groupon rolling out on top of a J2EE stack?

alttab 15y ago
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.

dillon 15y ago

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.

jroseattle 15y ago

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

Roboprog 15y ago
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.

socratic 15y ago

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?

illumen 15y ago

Wow, this guys knowledge is wrong. Dynamic languages can be faster than C now, and are only improving. Implementations like pypy, and luajit2 really are rocking. JavaScript implementations are also getting real fast. C++ doesn't need to use manual memory management, and hasn't for ages. You can use it, but it is optional. Perl was often mixed with C/C++ libraries, including mod_perl with apache - the real webserver written in C. With WebGL there is coming a massive amount of GPU power available to apps from JavaScript. Which also has available WebWorkers, which allow multi core use. As well, as vector instructions. The speed available for processing is truly amazing. There's just too much wrong in this article, so I'll just stop writing about it now. Usually I enjoy his articles, but this one is way off. On the other hand, maybe it is just a really good troll?

cygx 15y ago
> Dynamic languages can be faster than C now, and are only improving. You're a bit too enthusiastic here, imo. JIT compiled code can in theory outperform AOT compiled code because of dynamic recompilation of hot code paths. However, you can get some of the benefits of runtime code generation via profile-guided and link-time optimizations without any runtime overhead. In practice, no dynamic language is faster than C (AOT compilation), and they rarely approach Java (AOT compilation to bytecode + JIT compilation to native code) where raw performance is concerned.
- artsrc 15y ago
  That was my view yesterday. Then I benchmarked some JavaScript (CoffeeScript) code, and the same algo in C code and my world changed. I know that I could have optimized my C code better (I don't think I even turned optimization on), but I could have optimized my JavaScript better too.
  - supersillyus 15y ago
    That seems like a very small and somewhat flawed data point to be drawing any conclusions from.
- 15y ago

mike55 15y ago

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

JonnieCache 15y ago

Ruby may seem easier to pick up than java, but it gets pretty complicated when you actually try to understand its power. Try explaining eigenclasses to some java-only developers sometime.

wycats 15y ago
Every Ruby object is an instance of a singleton class that inherits from its declared class. # o is an instance of its singleton class, # which inherits from Object o = Object.new It is like saying: class Object def self.new(*args, &block) # Class.new(Object) creates an anonymous # subclass of Object Class.new(Object).new(*args, &block) end end except with built-in language support. Instead of having to do this manually, every object gets a singleton.
hamidpalo 15y ago
I have a hard time believing that Java developers would fail to understand the concept of a singleton, the most pervasive anti-pattern in Java code.
- JonnieCache 15y ago
  It isn't the same thing, despite the same name occasionally being used. It also gets a lot more complex than expanded upon in the other comment. Eg. what is the eigenclass of an eigenclass?

georgieporgie 15y ago

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.

antihero 15y ago

> These are slow as molasses Not really, with stuff like Python, your bottleneck is most likely going to be I/O and data reading/writing. > You can replace Ruby here with Python, Django or Groovy and it is still correct. Nope, with Python, unless you're using Django, most of your stuff is done with Python - there are frameworks like Flask but they provide a minimal set of tools to work with web concepts like routing and sessions. CPU won't be the bottleneck until storage is as fast as CPUs. SSDs close the gap a tiny bit, but nowhere near enough.

va_coder 15y ago

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

dsulli 15y ago
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.

zzzeek 15y ago

This is an unbelievable post. We're going to move back to Java, because.....file access will suddenly be an order of magnitude faster, therefore dynamic languages will suddenly be too slow? what form of crack is this ?

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

nikcub 15y ago

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

j_baker 15y ago

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.

ByteMuse 15y ago

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.