> Why is startup time relevant if you're doing backend server stuff? It's pretty much the ideal use case for Java.
Even on "backend server stuff" I pretty much prefer the FastCGI model, with multiple processes handling requests, as I don't have to worry about memory-leaks or about a rogue thread that can take out my whole server.
With the JVM, this is impossible ... you need a monolithic process that takes care of everything (no support for forking, long startup time, high resource usage). And having multiple apps running in their own JVM (so they don't interfere with one another) is no panacea.
You can also look at the problems Google's App Engine has with Java apps ... as resources are elastic, extra servers / VMs are loaded on demand, and the first requests hitting such a cold VM almost always ends up with a timeout error (although they are working to fix this, the magnitude of this issue is not the same with Python on GAE).
And this is solely because of the slow warm-up time.
> People will marvel over your great fashion sense, but will it solve the problem even as well as a less fashionable approach?
I have ideas that I can prototype over a single weekend, which wouldn't be possible without the help of those people with "great fashion sense".
> The amount of man hours wasted on reinventing the wheel in programming languages is staggering
Why don't you teach people then how to spend their time better with constructive arguments?
The easiest thing in the world is to dismiss / critique.
GAE has a lot more at play than standard JVM startup/warmup. JRuby on a desktop "client" Hotspot Java 6 starts up in around 0.5 seconds. On App Engine it can take as much as 10-15 seconds. Why? Because App Engine has a very different environment with a virtual filesystem, heavily-locked-down security, and (probably) quite different memory and CPU resource allocation. GAE does have issues with startup, but they're largely due to design decisions the GAE team has made, and not due to flaws in the JVM itself.
That said, I appreciate what GAE is: the first fully-sandboxed, elastically-scaling Java webapp environment. The decisions they've made seem to be good ones, ignoring the overhead they introduce.
Hey hedius, forgot to say in this thread ... thanks for your work on JRuby. It works great.
One small suggestion ... would you consider adding extra-extensions (breaking backward compatibility with Ruby)? You've already done it here and there, like for threads or for string processing (although I guess it wouldn't have made sense otherwise).
What I'd like is for some way to get the AST of a anonymous code block ... as I'm dreaming of something like Linq in a JVM language.
I'm not opposed to anything that seems like it might help bring more people to JRuby (and by extension, to Ruby). You can already access most of JRuby's internals via our Java integration layer, and that includes the AST, various core types, class structures and method tables, and so on. So much of this you could probably prototype without us adding anything. Beyond that, I'm interested in possible enhancements in JRuby to "over-optimize" code (like opting out of certain Ruby behaviors in a limited scope if they're just overhead for your app), and we're obviously always trying to improve how JRuby integrates with Java itself.
So yes, there are many great plans...and user demand (especially paid users!) can make anything happen.
> "Why don't you teach people then how to spend their time better with constructive arguments?"
Yeah but it's like trying to tell people "Hey don't buy that prada coat for £500 that doesn't actually cover you properly from the rain, buy this old fashioned raincoat instead that actually functions well as a raincoat."
I just wish people would spend more time becoming good programmers than chasing the new shiny things.
I'm not sure the argument about rapid prototyping is a good one. Maybe it's just you can get it done in a weekend because you enjoy playing with new shiny thing, so are more productive. The old-established-stuff has a multitude of libraries that have been war tested to ultimate reliability though...
I'm just getting old. Ignore me. Every generation has to reinvent the wheel for some reason anyway :)
I thought this thread might benefit from my response as a self-admitted shiny-thing-chaser.
Your Prada coat analogy is fairly silly, as I'm sure you are aware. First of all, when it comes to programming languages/frameworks, both the new-hawtness Prada and the "old fashioned" raincoat tend to be free, so there is no financial rationality argument to be made. Even if you (correctly) account time-to-learn as a type of cost, that cost is roughly equivalent to the time it took to learn the alternative you already know. I think a better analogy would be an old raincoat versus a new, similarly priced raincoat. Perhaps the new raincoat doesn't actually cover you properly from the rain though; unfortunately programming languages and tools are a lot more difficult to analyze than raincoats.
Do we agree, at least, that some chasing of shiny things has been very beneficial to our field? That our current crop of languages are better raincoats than architecture specific assembly language? That assembly language was itself a better raincoat than machine language? If you will stipulate this, then is it your position that we have reached the pinnacle? That no more advances in productivity or correctness can be made? If this is your belief, then OK, that's fine, you are entitled to it, but I do not believe such a pinnacle even exists, much less that we have made it there. And if we indeed have not reached the pinnacle, then we need people who are early adopters, who are willing to try out and write for technologies that are immature and untested. Maybe most or all of them fail to be even as good as what we already have, and the whole thrust turns out to be fruitless, but with no thrust at all, success is not even a possibility. Everything old was once new, and all the old-fashioned technology once had early adopters being made fun of for their impracticality.
Plus, learning new things is a great way to improve as a programmer and it's a lot more fun; all that other stuff is just incidental.
Even on "backend server stuff" I pretty much prefer the FastCGI model, with multiple processes handling requests, as I don't have to worry about memory-leaks or about a rogue thread that can take out my whole server.
With the JVM, this is impossible ... you need a monolithic process that takes care of everything (no support for forking, long startup time, high resource usage). And having multiple apps running in their own JVM (so they don't interfere with one another) is no panacea.
You can also look at the problems Google's App Engine has with Java apps ... as resources are elastic, extra servers / VMs are loaded on demand, and the first requests hitting such a cold VM almost always ends up with a timeout error (although they are working to fix this, the magnitude of this issue is not the same with Python on GAE).
And this is solely because of the slow warm-up time.
> People will marvel over your great fashion sense, but will it solve the problem even as well as a less fashionable approach?
I have ideas that I can prototype over a single weekend, which wouldn't be possible without the help of those people with "great fashion sense".
> The amount of man hours wasted on reinventing the wheel in programming languages is staggering
Why don't you teach people then how to spend their time better with constructive arguments?
The easiest thing in the world is to dismiss / critique.