The second coming of Java(blog.jelastic.com)
blog.jelastic.com
The second coming of Java
http://blog.jelastic.com/2012/12/11/the-second-coming-of-java/
Has this prediction come true? What do you think?
18 comments
What is this, a troll? The ruby bashing in this article is terribly juvenile, and the talk of disk seeks is so off the mark it reeks of incompetence.
Let's talk about the disk seek issue, because that's the most embarrassingly wrong thing here. Firstly, for many sites disk-seeks haven't mattered in ages because many data-sets fit into RAM these days. Buying 64GB of ram isn't that expensive. If that were really a motivator we would have seen shifts years ago.
Secondly speed doesn't matter when you have low traffic and expensive developers (and with CPUs today, almost all traffic seems low). In fact, since app servers tend to scale horizontally with zero issues (until you get to truly ginormous sizes), it's far more efficient to optimize the most expensive part of your budget, your developer salaries, by giving them the most efficient to program in tools available. The main exception really would be optimizing SQL queries, which this article doesn't address.
That being said, for some people that stuff does matter, but they weren't using ruby/python/perl anyway, they were already on Java.
This article is written by a guy who thinks he understands some kind of new reality in the market, unfortunately he only understands a very small part of it.
Let's talk about the disk seek issue, because that's the most embarrassingly wrong thing here. Firstly, for many sites disk-seeks haven't mattered in ages because many data-sets fit into RAM these days. Buying 64GB of ram isn't that expensive. If that were really a motivator we would have seen shifts years ago.
Secondly speed doesn't matter when you have low traffic and expensive developers (and with CPUs today, almost all traffic seems low). In fact, since app servers tend to scale horizontally with zero issues (until you get to truly ginormous sizes), it's far more efficient to optimize the most expensive part of your budget, your developer salaries, by giving them the most efficient to program in tools available. The main exception really would be optimizing SQL queries, which this article doesn't address.
That being said, for some people that stuff does matter, but they weren't using ruby/python/perl anyway, they were already on Java.
This article is written by a guy who thinks he understands some kind of new reality in the market, unfortunately he only understands a very small part of it.
It is frustrating when people look at the complex trade-offs between developer time efficiency and software performance and see only a dichotomy between good and bad programmers. Better programmers are just that much more efficient with the more efficient tools.
The author and OP are the same person (MarinaSprava).
They did a good job of getting traffic for their site. We should stop rewarding them for this tripe.
They did a good job of getting traffic for their site. We should stop rewarding them for this tripe.
> To avoid the complexities of C++ we turned to Perl which was fast to write in but wasn’t ready to be a web server.
In earlier days, people were writing perl first using CGI, and then using mod_perl. Where are you getting the idea about perl being a web server?
> And Perl had no frameworks to help write web apps so we wrote a lot of boiler plate crap every time just to get started.
If we are talking about earlier times(say 1996), "perl had no frameworks" compared to what? Web related libraries and frameworks were in their infancy at that time for all languages, and perl wasn't a special case. If anything, perl had more vibrant ecosystem owing to CPAN and people actually using it for web programming.
> Java also had threading really well integrated from the start so we could handle many requests at once which was starting to become a problem by 2005 or so
Threads, non blocking io, processes with copy on write predate Java.
> .NET was really just another Java for Windows. Nothing is fundamentally awesome about it over Java except that the engineers got to learn from Java’s mistakes.
And learning from mistakes and not making those mistakes doesn't make it better? Current C# is a much cleaner language.
> The difference between the old days of Perl and today is that we’ve made the real web server in C++.
Apache was released in 1995. And what is this real web server you talk about?
> That’s why Ruby and its surrogate languages will eventually disappear
No, they won't. They will just be selectively replaced with services written in more performant language, which isn't any different from how it is today. Non cpu intensive tasks doesn't gain anything from being written in a more performant, but less expressive language.
In earlier days, people were writing perl first using CGI, and then using mod_perl. Where are you getting the idea about perl being a web server?
> And Perl had no frameworks to help write web apps so we wrote a lot of boiler plate crap every time just to get started.
If we are talking about earlier times(say 1996), "perl had no frameworks" compared to what? Web related libraries and frameworks were in their infancy at that time for all languages, and perl wasn't a special case. If anything, perl had more vibrant ecosystem owing to CPAN and people actually using it for web programming.
> Java also had threading really well integrated from the start so we could handle many requests at once which was starting to become a problem by 2005 or so
Threads, non blocking io, processes with copy on write predate Java.
> .NET was really just another Java for Windows. Nothing is fundamentally awesome about it over Java except that the engineers got to learn from Java’s mistakes.
And learning from mistakes and not making those mistakes doesn't make it better? Current C# is a much cleaner language.
> The difference between the old days of Perl and today is that we’ve made the real web server in C++.
Apache was released in 1995. And what is this real web server you talk about?
> That’s why Ruby and its surrogate languages will eventually disappear
No, they won't. They will just be selectively replaced with services written in more performant language, which isn't any different from how it is today. Non cpu intensive tasks doesn't gain anything from being written in a more performant, but less expressive language.
No, I don't think so. I use Java/Spring in my day job, Python/Django for my own projects, and I don't think the use case for each is changed significantly by faster disks.
Ruby/Python aren't only best for 'prototyping', they're best for building your MVP and launching your product. If and when you get a bazillion users and your app starts creaking around the edges, then sure, rewrite some components in Java as necessary, as Twitter did; until then it's a premature optimization IMHO.
Note that speed isn't the only consideration: the other place where Java (and C#) shines is readability and ease of refactoring. If you're a stage one startup where all your developers are rockstars, this doesn't matter so much, but if half your dev team are grads or journeymen, it's a major factor.
So I can't see Java going away any time soon, but equally I can't see the resurgence that Cringely talks about.
Ruby/Python aren't only best for 'prototyping', they're best for building your MVP and launching your product. If and when you get a bazillion users and your app starts creaking around the edges, then sure, rewrite some components in Java as necessary, as Twitter did; until then it's a premature optimization IMHO.
Note that speed isn't the only consideration: the other place where Java (and C#) shines is readability and ease of refactoring. If you're a stage one startup where all your developers are rockstars, this doesn't matter so much, but if half your dev team are grads or journeymen, it's a major factor.
So I can't see Java going away any time soon, but equally I can't see the resurgence that Cringely talks about.
First, it may not be in fashion but Java never went away.
Second, I like Cringely but his conclusion is just extremely flawed. When hardware like storage get even faster (and cheaper), it means that dynamic languages have even more reason to stay. With the given environment in the US (limited H1Bs, the majority of the populace's lack of interest and even disdain for working with tech), carbon is still way more expensive than silicon. Anything that reduces developer effort and resources, like dynamic programming languages, is here to stay.
Second, I like Cringely but his conclusion is just extremely flawed. When hardware like storage get even faster (and cheaper), it means that dynamic languages have even more reason to stay. With the given environment in the US (limited H1Bs, the majority of the populace's lack of interest and even disdain for working with tech), carbon is still way more expensive than silicon. Anything that reduces developer effort and resources, like dynamic programming languages, is here to stay.
Sorry to put it like this, but this is simply bullshit.
It seems to me that you have never tried to code any Rails app, which by the way, is lately less Rails and more Ruby.
Here you are some data structures in Ruby: http://www.brpreiss.com/books/opus8/
In the article you say: "Yet in the last few years since, say, 2007 we’ve been moving away from Java and .NET for web development and back to interpreted dynamic 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"
This is hilarious. Have you ever heard of Martin Fowler? Robert Martin? Jim Weirich? They are definitely not in their twenties. And that is just for Ruby. In my experience, from the people I've met in the last 10 years, the average Java programmer is way less skilled than the Ruby one. And I've worked as a Java programmer as well, so I know a bunch of them.
It seems to me that you have never tried to code any Rails app, which by the way, is lately less Rails and more Ruby.
Here you are some data structures in Ruby: http://www.brpreiss.com/books/opus8/
In the article you say: "Yet in the last few years since, say, 2007 we’ve been moving away from Java and .NET for web development and back to interpreted dynamic 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"
This is hilarious. Have you ever heard of Martin Fowler? Robert Martin? Jim Weirich? They are definitely not in their twenties. And that is just for Ruby. In my experience, from the people I've met in the last 10 years, the average Java programmer is way less skilled than the Ruby one. And I've worked as a Java programmer as well, so I know a bunch of them.
What a patronising and illinformed article, I would like to be more constructive but I really cant.
The premise of this article is that we'll all move back to the JVM because database access on spinning disks is slow, and when we all get SSDs then the speed difference between interpreted, dynamic languages (Ruby/Python) compared to anything on the JVM will become significant. Before it was insignificant because database access time dominated the duration of a request.
I completely disagree.
If equally slow database access makes the language comparison useless, then equally fast database access will be similarly pointless. The slow, dynamic language gets the same speedup, and now can return a page in 50ms instead of 300ms; the static language on the JVM returns the page in 30ms instead of 250ms -- that doesn't matter for serving pages to people.
Ruby and Python have become popular to use for writing web applications because the development process is pleasant and forgiving to newbies.
If you need to scale a site and really squeeze out performance, then you're already going to employ smart caching strategies and maybe move off the dynamic language as well (e.g. Twitter). If you get a "free" speedup from SSDs, you have even less need to switch off the slow, dynamic language.
I completely disagree.
If equally slow database access makes the language comparison useless, then equally fast database access will be similarly pointless. The slow, dynamic language gets the same speedup, and now can return a page in 50ms instead of 300ms; the static language on the JVM returns the page in 30ms instead of 250ms -- that doesn't matter for serving pages to people.
Ruby and Python have become popular to use for writing web applications because the development process is pleasant and forgiving to newbies.
If you need to scale a site and really squeeze out performance, then you're already going to employ smart caching strategies and maybe move off the dynamic language as well (e.g. Twitter). If you get a "free" speedup from SSDs, you have even less need to switch off the slow, dynamic language.
I wonder if Jelastic being a Java cloud platform has something to do with the amount of bullshit this article is full of.
Seems like an attempt to drive traffic to the Jelastic site through content farming (blog posts targeting keywords, etc.). As least they could use authors who know what they are writing about. Doesn't cast Jelastic in a good light...
Java Pro's:
* Extremely Fast (load times matter)
* Gives you the ability to deploy self-contained cloud ready packages
* It's really not that complex (_IAOI_ you use the damned Tooling and reject J2EE)
* Massive library of existing open source projects
* Ability to refactor quickly is unmatched even by c++
* "Productive"-enough in the hands of competent developers
* Boatload of options to profile/tune/debug
* Bytecode engineering allows for really awesome things to be done with reflection, AOP, instrumentation
* Used by most everyone
Cons:
* Hard to find lean Java developers
* Most Java developers want to build SOA/ESB monsters
* Loathed by the startup culture
* J2EE is insane (alternatives like CDI/Spring should be used)
* Portion of the SDK really sucks (ex: IOException is checked)
* Oracle not concerned with startup culture, head stuck up ass
Honestly, I think the startup culture needs to just let the war on Java go. I'd rather see this said instead: It's a valid language that has a lot of advantages, but only if you have people that know how to run lean.
* Extremely Fast (load times matter)
* Gives you the ability to deploy self-contained cloud ready packages
* It's really not that complex (_IAOI_ you use the damned Tooling and reject J2EE)
* Massive library of existing open source projects
* Ability to refactor quickly is unmatched even by c++
* "Productive"-enough in the hands of competent developers
* Boatload of options to profile/tune/debug
* Bytecode engineering allows for really awesome things to be done with reflection, AOP, instrumentation
* Used by most everyone
Cons:
* Hard to find lean Java developers
* Most Java developers want to build SOA/ESB monsters
* Loathed by the startup culture
* J2EE is insane (alternatives like CDI/Spring should be used)
* Portion of the SDK really sucks (ex: IOException is checked)
* Oracle not concerned with startup culture, head stuck up ass
Honestly, I think the startup culture needs to just let the war on Java go. I'd rather see this said instead: It's a valid language that has a lot of advantages, but only if you have people that know how to run lean.
As a fairly experienced Java developer, I don't agree with this article. It reads more like a desperate fantasy, than a reasoned argument.
The rapidity with which you can get started with other languages and frameworks has very little to do with the runtime performance, and a lot more to do with language flexibility and the 'sweet spot' which frameworks choose to occupy. I don't think Java is a bad language, but there's problems which I would not choose to solve in it.
The looming presence of Java 8 is likely to catalyze a new set of libraries, as people adjust to writing with lambdas, and the new power provided by the expanded type system and runtime. I'm anticipating a tsunami of lambda enabled crap, and some gems of design to emerge glistening from the initial torrent.
I don't think this will dramatically alter people's perceptions of Java as a language for rapid web development, though.
The rapidity with which you can get started with other languages and frameworks has very little to do with the runtime performance, and a lot more to do with language flexibility and the 'sweet spot' which frameworks choose to occupy. I don't think Java is a bad language, but there's problems which I would not choose to solve in it.
The looming presence of Java 8 is likely to catalyze a new set of libraries, as people adjust to writing with lambdas, and the new power provided by the expanded type system and runtime. I'm anticipating a tsunami of lambda enabled crap, and some gems of design to emerge glistening from the initial torrent.
I don't think this will dramatically alter people's perceptions of Java as a language for rapid web development, though.
This account only posts articles about jelastic.com. Wonder if it should be flagged.
Zero comments too, which is especially damning since they aren't reacting or interacting with the community regarding any of their material.
This ignores the fact that most web applications are developer-bound well before they became IO bound, and much much before they became CPU bound.
Anyway, Java EE is alive and strong in the enterprise isn't it?
Anyway, Java EE is alive and strong in the enterprise isn't it?
Not a very well written article. But if you only read the title (which you should really) then Java the language => no, but the JVM I would say yes. I think the JVM is being used (and abused) more and more.
Thank you, but we (let's say naive believers) just began to suffer the consequences of its first coming..))
No. Just simply wrong article.
Biased article.