1) Is it because of the lack of hosting support for Java based web applications?
2) Or, are there any serious performance issues when Java is used to develop web2.0 apps?
3) Any startups that already successfully using Java?
You can certainly write web applications in Java. They're harder to deploy than PHP but easier to deploy than Rails, in my experience, depending heavily on how experienced you are at administering systems and how much Java enterprise coffee you want to drink.
Java is a mature language. Libraries exist for almost any task you reasonably want to accomplish. There are skilled Java-speaking programmers in your area. Whatever you doing has almost certainly been done in Java already, and it has probably already been documented extensively. Java is an opinionated language: it is of the opinion that your workflow should resemble IBM's more than it does 37Signals', and if that is true, you and Java will get along nicely together.
There, mandatory praise out of the way. Java is horrifically maladapted to certain classes of problems and certain classes of users. One class of problem is expressively operating on strings to produce other strings. One class of users is anybody with a team size less than ten. Many web startups have a small team which is primarily interested in turning strings into other strings: if this is you, Java is going to fight you every step of the way.
99% of web application development for a certain type of business is turning strings into other strings. Many web development languages/frameworks popular with startups give you very expressive options for churning out certain types of strings quickly and with little cognitive load. For example, in Rails, there is very vanishingly little work in taking a bunch of strings from the blog_posts table and turning them into strings which encode a blog post into HTML. And if you want to add special strings that cause comments to be loaded in an AJAXy fashion, that is quick, too. Want to make sure that the strings the user is commenting with include certain strings which look like email addresses? Add one line to your program, and bam, if someone puts in a bad string they get a red string telling them how to make it a good string. It is all string rainbows and string unicorns. If you fat-finger your one line, it is very possible that large portions of your site will instantly break, but that is OK because if you program like everyone else using Rails programs, your magic guardian angel strings will get your attention before you deploy, and after you fix your typo everything is rainbows and unicorns again.
There are many Java frameworks. They can all operate on strings and produce other strings. However, the experience of actually doing this is maddening: pulling off the above you-give-me-bad-strings-I-give-you-red-strings can be a matter of touching six files or more, often written in painstaking configuration formats. The frameworks assume you are guilty of incompetence and force you to repeatedly prove you are otherwise, the better to prevent idiots like you from taking the site down.
This is a problem for startups because web startups are not about turning strings into other strings: that is just what they do. Web startups are about finding a problem people will pay money to solve. That is where they ideally spend most of their efforts. Sometimes, those explorations require code to be written, and when code gets written it should be quick to write, quick to test, quick to deploy, and quick to rip out when you discover your users don't respond the way you thought they would.
Java as it is practiced in the real world looks at that list of requirements and sees Very Scary Things.
Have you tried Phusion Passenger (http://www.modrails.com/)? It is trivial to install and makes Rails deployment a snap.
Having developed both Java EE applications and Rails applications, Rails to me was much more easier to deploy, without having to deal with installing Tomcat and going through the extensive server configurations.
I usually run Jetty behind nginx and don't generally need to configure Jetty to do anything.
The whole Tomcat and connectors for apache configuration from a few years ago is well and truly behind me.
Play is seriously, seriously good. We used to build on top of a fairly heavy but powerful stack of Spring, Hibernate and Struts2/Wicket (depending on the app). Although there's a lot of power there there's also a lot of tangled XML and you need to do a fair amount of gymnastics to get through it all. Server restarts are common and painful. Getting exception stacks that run 200 classes deep are IMHO a bad sign.
Play is a total breath of fresh air. REALLY well thought out, clean, simple, fast:
- almost no server restarts needed, - runs very very quickly in production - stateless, so zero downtime deployments are trivial - great community - extendable with modules
Then there are all the little things. Libraries to do things like encryption and image resizing are built in and just work. Everything just works.
I can't recommend it enough. It really does liberate Java from the Enterprise shackles.
Enlive and Fleet are other options and I've briefly explored both at certain points, but I personally just found them both unwieldy and unnatural, with other disadvantages as well. I'm sure they suit the needs of some people but I dismissed them before I got past the minimal learning curve.
The same goes for StringTemplate. It seems really cool and everything, but I just don't want to have to learn (and use half the time) a whole new different syntax just to stick dynamic strings in a page.
PHP just makes it so damn easy that it's hard for me to pass up when it comes to churning out webpages.
which is not to say it's bad. it's actually really good, with lots of great qualities.
but compared to PHP, Ruby and Python, it's rather verbose. As a general rule you can pound out way more feature points per hour in a less verbose language than a more verbose one.
there are other factors, sure, but I think this is the biggest one.
Verbosity doesn't equal less productivity. I would be really surprised if anyone here said their bottleneck in programming was the speed they can type.
Also, all languages have their needless verbosity - look at 'end' vs '}' (ruby vs java). Which is the more verbose?
Java doesn't abstract very well beyond objects and classes. This becomes pretty irritating in stuff like event handlers, where you'd really like to use something like a lambda/delegate, but the only option you have is an inner class. This might change in the future, but right now some minor language features would make it much easier, and you'd avoid hard to track down annotations and reflection.
Also, Java library design often tends towards the obfuscated. [...]Adapters, [...]Implementations and [...]Factories, the usually bloated read/write beans, checked exceptions…
Having said that, there are lots of really good libraries and frameworks who don't fall into those traps (well, at last not too deeply). And maybe Oracle will bestow onto us some sparkly new bits that will cut down on some boiler plate and will alleviate the need for IDE wizards/code generators or stuff like lombok[1]. In some areas, languages like Perl, Python (or even Lisp) will still have advantages, but it would be nice if Java programmers could at least catch up a little to C#.
Disagree. And not based on myth. Based on direct experience over 25 years doing programming. Verbosity -- holding all other things equal -- does equal less productivity.
To put the argument in thumbnail form: it takes about the same amount of time for me to devise a programming design for something in Python as in Java. But to type in, run and test that design? Much less time with Python than Java. The human is the bottleneck at development time, in general, not the computer, not the runtime execution speed. I also only have a finite amount of display screen real estate, so with a more concise language I can "see" more feature points on the screen, all at once, when looking at source code. And since there are less LOC if I ever have to do code surgery or cut-and-paste things around I can do that faster too, in general, with a more concise language. But all arguments aside -- because they are irrelevant in the face of direct experience -- I can say that I now personally avoid choosing Java in all the personal projects I've initiated, and I also bias to advising startups to avoid it (in general) in favor of a lighter language. The issue is more complex when you're dealing with an external client and somebody else's business, however, because sometimes the benefits of Java outweigh it's verbosity -- and there's nothing wrong with choosing it if those factors are critical and pertinent to any particular project.
But when a design is clear, and my implementation choices are clear and fresh in my head, and I know almost exactly what LOC I'm going to write next, then yes I've found that "new line creation speed" does impact the overall time it's going to take to finish a particular feature or change. Years and years of observations backing this up.
def some_method { ... }
def some_method do ... endI'm just working on my web startup using Groovy and Grails and many things I need are provided out of the box or through plugins (security, search) that are easy to install, configure and use.
I think you should consider platforms as a whole and not just the languages.
The downside is that Jython throws more runtime exceptions. OTOH it has incentivized a ramp-up in unit testing (Maven, Selenium).
Despite all the bad news you might hear, as long as you stay clear of the bloated enterprise stuff it's a great platform and environment for a startup.
Hosting used to be an impediment but these days VPS make it dead easy to run Java stuff.
by this you mean the frameworks like Spring, Struts or the buzzwords like JMS, EJBs?
And it is easy to use Java EE components like these without the need for frameworks like Spring - if anything I think they just obscure what's really going on. Again I'd like to re-iterate I'm not a highly experienced developer but I've learnt how to use most of the Java EE technologies in my applications rather quickly.
avoid IDE's -- or at least, anything that causes your team to need an IDE just to counter-act some other linguistic or procedural vomit you often encounter in the typical Enterprise Java shop
avoid abstraction-for-the-sake-of-abstraction -- the Java ecosystem, not necessarily the language, is notorious for this
I'm a long term Python developer (since the 1.5.2 days). I've used a lot of different languages so far (from C to Haskell), and I've always avoided Java in the past (at the beginning because it was slow, later because everyone was telling me how bloated it is).
But using Java EE (!) instead of Python for a project a few months ago was really an enlightenment. Yes, it is somewhat bloated (although much less in the recent versions where you can use annotations instead of all those XML files). But on the other hand: It just works - exactly as documented.
With all other frameworks (based on Python, Ruby, etc.) that I've used so far I had to hack around in the framework or in the libraries to make it work the way I want. This starts with simple issues such as Unicode support, where the authors of a library obviously just didn't care if it works, and continues with distributed transactions, where you have to hack up the whole logic inside your application because the framework doesn't support them. Compared to this, with Java (EE) this just works rock stable and has most of the features you'll ever need.
From a performance perspective Java isn't that bad as either. For a project I've compared the performance of two simple (comparable) Web apps that I've wrote: One with Python on Django, the other one with Java on Glassfish). Once you increase the concurrency, the requests to the Django app just return error codes or take a long time to complete. In comparison, the Glassfish app just chucks happily along.
This does not mean that Java is appropriate for all use cases. But just don't believe the majority and try out yourself, if it works for you.
I would even say you could go as far as saying it one end of the spectrum. Where you have frontend web apps (html/js/css) on a variety of platforms[1] on the one end and the big corporate backed languages and frameworks on the other end.
[1]: This can be a real pita. Though it's being mitigated more and more by adding compatibility layers on top (jQuery et al).
Usually the solution in the dynamic language is far more elegant and satisfying than the Java version, but there might have been a lot more trial and error involved in arriving at the solution in the dynamic language.
More correct, second reaction: deploying Java apps can be more enterprisey (depending on how much of the J2EE stack you're laboring under) but at least has well-known production-quality deployment options. This is an area where the community could use some serious consolidation.
EDIT (Summary): We knew Java well early on and so used it to prove a market, leveraging open source libraries along the way. Do I think Java the language was a particular competitive advantage to us? No. But do I think any of PHP, Ruby or Python would have been either? No. (Lisp - probably yes! but we don't know it well enough to use professionally). To be honest, our main concern early on is to release early and prove the market, with whatever tools we can use.
Why did you stop using Tapestry? Because Howard Lewis Ship is a liar. Lots of reasons but the main one was breaking compatibility between v3 and v4. Just when we solved all those issues v5 came out and broke backwards compatibility again! Just couldn't go through that again.
Ideally, I would like to have a lean version of maven+jetty+spring to implement a web framework.. which should also be deployable to more heavyweight containers like JBoss. I havent figured this part out. Maybe Stripes is the way.
It turns out, I am really a static-typing ...type after all.
With utilities like Spring Roo, frameworks like Jersey (JAX-RS), IDEs like Eclipse and platforms like GAE, Java can be really productive.
Are there any complementary tools out there for things like templating and form validation? We're currently using Apache Velocity for templating and manually doing this stuff feels a bit alien to me when Django gives you this stuff for free.
Have you tried Scala?
Java's greatest strength is it's speed, a dearth of open-source libraries for pretty much anything you'd need. It's very possible to write light-weight simple code, if you shift out of the enterprise mind-set.
Java is mostly snubbed in web startup land and associated with boring corporate work.
More discussion here: http://news.ycombinator.com/item?id=1378815
I bet there's a whole other demographic of serious business people who are busy getting things done instead of discussing unrelated matters, or in other words, doing things that aren't work-related.
Based on my observation, some heavy hitters are using Scala in production, but the learning curve is high and development time is slower that PHP, RoR or Python.
The problem you will have with Java in a startup is that Java's frameworks are by and large built for "enterprises". I put that in quotes because in one sense it doesn't really mean anything. In another, it's more of an idea of what governments and large companies want.
Even when using Spring (which, in my opinion, is a "must have" for pretty much any Java Web project), the amount of boilerplate required to set up an endpoint, map form data to objects, map those "presentation objects" into "business objects", map those "business objects" into a DAO (data access object), etc is pure torture.
Now this isn't completely the fault of the language. The language certainly doesn't help matters by being statically typed. This just doesn't gel well with how "fast" Web development works. Compare that to PHP (as just one example), where form data is just a map (hash or simply "array" in PHP parlance). Add a new field? Not a problem.
Add a new field in Java and you'll be making class modifications in about eight different places.
The bigger part of the problem is not the static typing though, it's the philosophies that dominate the Java landscape. There is a joke about the Java programmer's response to any problem is "just add one more layer and it'll be OK". It's funny because it's true.
It's fair to say that Fowleresque division of responsibility based layering is pervasive.
Of course the dynamic languages can have other problems (eg no error when misspelling a form field) and Java's static typing has, in my opinion, made Java's IDEs the best of any language or platform bar none (IntelliJ in particular). IDEs seem less able with dynamic languages because it's much harder (if not downright impossible) for an IDE to, for example, derive the members (let alone the types of those members, if that concept has meaning) on the fly.
Weirdly some in the PHP world have tried to mimic Java's deep layering with these horrific (imho) MVC frameworks that (again imho) simply combine the worst of both worlds. Dynamic class loading, bootstrappers, magic (and sometimes unpredictable) file loading, enforced directory structures and so on are just the wrong approach most of the time.
Java does have some benefits though. There are basically three tiers of languages in terms of performance (from best to worst):
1. C/C++/Assembler: the true compiled languages;
2. Java, C# (and the other .Net languages): the bytecode or virtual machine "semi-compiled" languages; and
3. Python, Perl, Ruby, PHP, etc: the scripted languages.
I qualify this by saying: most of the time (particularly for Web apps and especially if you don't have Google-level scale problems) performance doesn't matter. What matters is productivity and productivity is similarly tiered from worst to best in that above list. Hardware is now so cheap that it's far more effective to throw hardware at most problems than it is to write things in C. This is almost universally true when it comes to the Web where network latency and the speed at which the browser can process your page (and Javascript) will dwarf serverside performance most of the time.
I did a bunch of the Facebook puzzles awhile ago. The breathazlyer one was quite interesting. I started doing that in Python but it is somewhat difficult to get a solution to pass in that. Java is an order of magnitude faster. C is one or more orders of magnitude faster yet again.
So back to your original question (now that my answer has some context): I would say that using Java may make sense if everyone knows it and is comfortable with it. If not you will find many speed barriers along the way of learning a new language that may just slow you down or (worse) may create huge problems (eg security issues you weren't aware of because something didn't work the way you simply assumed that it did).
None of these problems are insurmountable but the way I figure it is this: when writing something new, chances are that within a year you'll be best off throwing it out and starting again anyway as the problem changes, you identify your bottlenecks (often not what you thought they'd be to begin with) and your scale changes.
So don't try and find the perfect language or platform or framework. Write something now and don't try and solve every problem you may ever have today.
Other than that, I agree with your post!
Sorry, I have to call you out on this. In your list above PHP is really interchangable with Python, Ruby, etc (the scripted languages). The MVC architecture you mention above perfectly describes Rails. So I have to ask, are you seriously saying that Rails is horrific? Seriously?
However, at some point about '99 or so Java seemed to endure a culture change where Java became popular as an "enterprise" platform and the values associated with that culture started to dominate a lot of discussions about how to do things. Suddenly everyone wanted to use every feature of J2EE in every project (largely for CV padding as far as I could see) - with predictably awful results.
However, Java has always been a pretty decent platform - we wrote search engines in it and things like Lucene continue to work pretty well. There are a lot of fascinating libraries for Java and performance can be excellent - it could be pretty fast in 2001/2002 and I assume it hasn't got slower....
If you can use Java and focus on "Keep Things Simple Stupid" then I can't think of many reasons not to use it - it might not be fashionable any more (those days are long gone) but it sure is capable.
http://groups.google.com/group/comp.lang.java/browse_thread/...
In answer to your questions:
1) Yeah, good cheap Java hosting doesn't seem to exist. That said, I think the Rackspace Cloud and Amazon EC2 are great solutions and great value for money.
2) Java is a high performance language, if you get performance issues it'll be your design/archiecture.
3) thingloop.com, successful from a technical standpoint, business-wise, the jury is still out!
On the whole question of which language, I'd say:
a) avoid religious arguments - my language is better than yours! They all have advantages and disadvantages.
b) a lot of it is down to what's cool. Ten years ago Java was the coolest kid on the block, now it's RoR. Thinking longer term, you might want to consider what the most available skillset is in your area for recruitment purposes.
c) if you've got a bunch of guys who already know a platform inside out, then stick with that. They'll almost certainly be way faster.
It's been pretty spectacular so far.
When I started my project, I tried ruby, but after 2 months of fighting, I just went back to java. But somehow I'm gifted, I never did java at bigco, I did it at another (desktop) startup before and have a critical eye on the java current trends. I don't use Spring and all the famous bigco frameworks, I use a simple setup (PicoStuff, jetty, Webworks).
But in think most "objective arguments agains java in a startup" are plain wrong. The real problem of java is that all people know about it is eclipse and spring and the EJB2.
edit: BTW, today I do PHP, and we're integrating with drupal, and what I see in drupal is far worse than the EJB spec. It's tangled and static so you can't test anything in isolation, and there is no spec. The core code is really difficult to read because everything is passing maps of string around.
I think we see a lot of Ruby and Python in startups lately because they're a good blend of productive and well-known.
The problem is that web startups tend to want to develop things quickly and be able to pivot quickly and easily. Java is not best at those things.
I know Java and worked with it for years. I do all of my startup coding in Lisp. Java forces you to do a lot of things that may make your code more reliable and easier for others to use, but it comes at the cost of being less productive, and in startups, being able to develop quickly is extremely important. That is why languages like Lisp or Ruby or Python are much more popular in the startup world.
That said, we have been at it for 5 years now, so it would be a stretch to call us a startup, but we use Java for 90% of our platform codebase, with Ruby acting as a glue.
The JVM is extremely fast and optimized. We handle many thousands of requests a second on a few VPSes.
A web application is often more than the choice web framework. When you choose Java as your fundamental technology you could build your business logic e.g. in Java/Scala and your web tier in Ruby on Rails which you can run on JRuby.
At least, that's probably the choice I'd make... :)
It works very well. You get close to the performance of C code in a 'safe' language, but can write the non-performance-critical code in a less verbose language of your choice.
Java is widely used in Financial, Insurance sectors. (There are several others as well but I speak of these from personal experience) I can offer up to $95k for a top level Java programmer. I do not think start up salaries can go that high. Of course there are no big stock options pay day like in a start-up but it is easy to see why some programmers would rather work in a bank than at your start up.
Round here (Adelaide, Australia - not exactly a center of big business) $95K is a base Senior Java salary. Most people are doing contracts though, and rates start at $65/hour (roughly $110K/year) and go way up. I know some pretty average programmers on 6+ month contracts at $80/hour, and $100/hour isn't unknown.
If your observation is based on reading HN, likely it's a bit skewed. Paul Graham has bashed Java and Java programmers quite a bit in his writings: "The programmers you'll be able to hire to work on a Java project won't be as smart as the ones you could get to work on a project written in Python."
That said, I would have to agree that Java is not the language of choice for small startups. There is a lot of overhead involved in setting up a Java project compared to other languages/platforms, and the problems that Java is best at solving aren't usually the problems you run into in a small web app (unless you're dealing with a lot of data).
Java isn't as fun to use as newer languages, and doesn't have the vibrant community that Ruby and Python do (even if you include JVM based languages like Scala and Groovy). Java doesn't attract creative types. A web designer looking to pick up a first backend programming language is probably not going to choose Java, and thus they aren't going to create beautiful documentation repositories, fun open source projects, organize meetups, or create the next revolutionary social app.
However, there is a reason that so many large startups start to lean on Java once they reach scale. Java is fast, encourages good design, and is great for large development teams.
Since we come from enterprise environment Java is the second mother tongue to us and I have got accustomed to mighty autocomplete and refactoring features of eclipse. The main reason for diverting from Java would be purely of taking intelectual pleasure in learning new things and checking if python/ruby frameworks live to the expectations.
We did some contract work on french social startup using a very lightweight web framework called Stripes (http://www.stripesframework.org). It was much better experience that using component based UI frameworks like JSF.
Needless to say - for quick web hacking I still fall back to PHP.
Experience was good. I generally try staying away from frameworks like Struts, JSF for a consumer facing web app. They make sense in enterprise domain, but not so much in web.
I am right now building a product on my own using GWT (Java to JS cross compiler), Scala and Mongodb as my stack. Experience is again pretty good.
On the backend I chose Scala over Java mainly because I require lot of parallel processing to crunch data.
However, when u write a non-trivial app (more than a web front-end or REST API), java starts to shine: there are soooooo many open source projects available with friendly commercial licensing, good tools for debugging, etc.etc., that you save a lot of time by just incorporating things rather than writing things.
This is not to say other languages don't provide these features - rails has some nice momentum (growing list of projects), python too, and say what u will about msft, c#/asp.net is a good combo (VS.NET is a great dev environment, and there is a relatively small but growing open-source movement - and Mono is fantastic for cross-platform work).
...but i'd say that the massive amount of effort and open source projects in java have been a godsend for my work - especially recently - and saved me enormous amounts of time.
...also, I've found that recent groovy and grails versions have made web dev super simple...and u can call all your java code ease. (And groovy++ (statically typed groovy extension) makes groovy performance for a lot of thing as fast as java.)
But the bottom line is that u should choose what u r most comfortable with.
Java would be a fine choice. Especially java / groovy / grails...and ignore the java projects u don't need (EJB, etc.).
On another note, I think the one language that startups should avoid (again for more than a simple web app talking directly to a DB) is PHP. Just try to extend it...or talk to an external service. yes, you can wrap your services with REST APIs...or use something like thrift...and i know there are several successful companies that use it (facebook, etc.etc.) - and i've been part of companies that use it too...but i think PHP puts yourself in handcuffs that a startup shouldn't really need. ...and it creates a "silo" around web development - not a good way to get going.
my $0.02. ;-)
As (almost) always, performance issues are with the db. And, as always, you should think about the data structure that you're using.
Secondly, we are Berlin based. Security and stability is such a big issue in German companies. You might agree or disagree if it is really true for Java software to be safer or more reliable, but just mentioning "Java" helps to sell to those companies.
I'm by no means a hugely experienced developer but after spending a short time working for an organisation that use Java EE extensively I now have learnt how to use and deploy pretty much the whole EE spectrum - Servlets, JSPs, Web Services, EJBs, JMS etc. That provides a huge arsenal for scalable web application development.
I think the reasons Java tends not to be used in the web app world and PHP / RoR not in the corporate world is down to the backgrounds of the developers. Web developers who come from a freelance web site building background are more familiar with PHP - its a very consumable technology for people that haven't got a lot of time to invest in learning technologies. Career software developers often are trained in Java development on the job once they graduate (from a degree which will likely have had a large Java component).
I personally don't know much about PHP, but I see the most likely platform to be future proof as Ruby on Rails. But for now I'm sticking with Java, it still has a fairly substantial future.
1) Java isn't amenable to pre-installed hosting like PHP is. You usually deal with machine images that you have to prepare yourself. Jetty 7 + Nginx is the going coin, it's quick and easy
2) Java is outright the best performing language of the ones currently used for web development with any degree of frequency (PHP, Python and Ruby being the other ones I'd mention). There's 10+ years of optimization and garbage collection research in those VM's, and language is statically typed, which increases verbosity yes, but also performance
3) If you extend the view beyond start-ups, Java isn't just getting used - the world runs on it. If it's a web app of any meaningful size, there's a 90%+ it's written or getting written in Java. The only other language that has this wide an acceptance level is PHP, which is a different animal entirely. Not to disrespect RoR or Django, but their overall share of the web development market is negligible
Keeping in mind the bias that comes from 12+ years of dealing in Java, here's a quick pro-con for what it's worth:
pro => - Java is fast. Very fast - Tool support is unrivaled. It's hard to appreciate what an IDE can do to speed up your work until you've gotten your first couple dozen IntelliJ keystrokes in the muscle memory. RoR is not faster to write than Java (a frequent claim) - Library support is unrivaled as well. Whatever it is, there's already a library for it, usually quite well-documented, and most questions that come up are googlable on the spot (something I sorely miss when I have to work Rails on occasion) - with the entry of Play, speed and ease of web development is approaching dynamic languages: write, hit reload, be done - knowledge and people to hire are available widely - the JVM is also home to Scala and Clojure. Starting in Java and moving to Scala is a pattern these days
con => - it's wordy and, compared to, say, Ruby or Scala, downright ugly. Not a big deal as far as start-up success is concerned, mostly a hacker bragging right. Nothing wrong with bragging as long as it doesn't get in the way of getting stuff done - generics and collection syntax is unwieldy. IDE support takes care of some of that, but not all - there's arcane stuff one needs to get used to - a learning curve of sorts. Again, mitigated by the widely available documentation and Google support
hope this helps.
- z
Java is great for rapid development once the development process is set up correctly. I've actually ported the app to Google App Engine in the middle of development once I learned of its generous hosting plan. Java is one of the two languages supported by GAE. I did use Python for quick scripts in import/export and building up data sets from dev environment to production servers.
Our ability to deploy to Windows and Mac is giving us a leg over some competition that's unable to serve the larger Windows market. Being able to knock out new features very rapidly (within minutes/hours) is another advantage.
Reminds me of PG's essay about how Viaweb was able to implement a competitor's feature the same day it came out...
These days there is basically no reason to do webdevelopment in Java - even if you have legacy stuff lying around, JRuby or Scala will serve you much better and neither is that hard to learn and both will get you over Javas sever limitations (really, no anonymous functions? No Closures?)
1) founders are most familiar with Java
2) founders are more comfortable with top-down engineering practices and not with bottom-up, release-early release-often approach.
3) core technology depends heavily on non-trivial open source Java libraries.
Of course, we aren't doing content management or anything, the front-facing stuff is a tiny minority of what we do, so that makes Java an even better choice. If I was writing a CMS or an app that was primarily webby in nature, I'd take a look at a more dynamic language (possibly still on the JVM).
It happens.
1. creating application in PHP is quite easy. no servlet , no configuration and just start writing the application. 2. PHP hosting are cheaper. But now a days Google apps are providing free hosting for Java apps.
BTW I am quite in favor of Java web apps. Java web apps are more stable and maintainable.
Theres an ever growing list at http://wiki.apache.org/hadoop/PoweredBy
2) Not at all. But you need seasoned developers.
3) Our platform runs mostly in Java. So far good performance.
1 - we self host
2 - the relevant performance issue when using java to develop web apps is it's slower to build. I'd be pretty surprised if there were many cases where java / tomcat is slower to execute than rails or django. Now obviously all three are smoked by cached pages, but since a lot of our data needs to be updated daily, that isn't the easiest design for us.