Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: Any web startups using Java?
119 points by Veera on Nov 23, 2010 | hide | past | favorite | 160 comments
Based on my observation, most of the web startups are using either PHP or RoR or some other platform, but not Java. I haven't come across a single startup which is using Java for web app development.

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?



IMO there is neither lack of hosting support (just use EC2 or a vserver) nor any serious performance issues.

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.


"It just works - exactly as documented." -- I guess that's the one thing that Java is really good at.

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


"It just works" might be huge, though. After > 10 years I hate Java with a passion, yet I still can not say with confidence that coding in other, dynamically typed languages is really better.

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.


My first reaction: your Django app was deployed / configured wrong and you should have tried …

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.


I'm working for a startup that uses a mix of PHP for serving web requests, and Java for backend processing. Our use of Java has definitely been successful.

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.


We are a London Startup, mainly building products off the back of web crawling & data mining, using Java for all our development, whether web or server-side. As our web framework we use Tapestry5, which is a great framework, with fast development times & minimal coding (Howard Lewis Ship has really put a lot of thought into the development of the T5 framework). Server side our crawl infrastructure, and other application processes are all Java. We use hundreds of Java open source libraries, including HBase, Lucene & OpenJPA. Addressing your issues 1) Lack of hosting support - we hire VPS, cloud or dedicated server infra on which we can deploy whatever we want - I don't see how this could be an issue. Even a cheap $10/month VPS gives you root these days 2) Performance issues? I won't get into a performance discussion but unless you've got google levels of traffic it's not worth worrying too much whatever platform/language you choose, a bigger challenge early on is attracting customers ;-) I used to work in banking & Java was performant enough for our high frequency trading infrastructure, where performance really does matter. 3) We have been going 2.5 years now, a lot of what we do is server-side processing and data munching and the open source Java libraries we leveraged along the way really helped us get going, things like HBase, Lucence, Bdb, Natural Language Processing (OpenNLP), Neural Nets (Encog), Stats packages, HTML processing (Jericho, JTidy). I know there are API's and ports of these in other languages, but the Java open source community is enormous, just because it's been around for so long, so it's always easy to find someone who'se done it before.

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.


Funny that you mention Tapestry 5 and Howard Lewis Ship. I was recently looking for a fast, stateless, Java based web framework (I liked Stripes, but eventually had to settle for Spring). I came across this SO question: http://stackoverflow.com/questions/1303438/why-did-you-stop-...

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.


Yes, I am explicitly talking about T5. The SO post refers to T4 and below, although I gather the upgrade path 3 -> 4 -> 5 was non-existant and so pissed some people off (understandably). I guess Howard was trying to just create something better...


I've done apps both in php and in Java and if the app is small it's much more difficult to deploy a Java application than php application. Most Java deployments are persistent (there is an application in memory which answers requests) and it is prone to memory (or other resource) leaks, while php is widely adopted in shared hosting environment because of its statelessness, even if there is a possible memory leak - in most cases it's not important, only long processing queries might bring it up in php, and it is solved by hosting providers with putting limits to http time.


How times change - when we started in '95 the fact that we were doing a server side application in Java was seen as a very cool thing.

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.


Reminds me of this fellow who was starting his little web crawler project using Java:

http://groups.google.com/group/comp.lang.java/browse_thread/...


We're using Java (and Google Web Toolkit) on thingloop.com, and it's working out great for us.

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.


We're using Java/GWT also on Envolve (http://www.envolve.com)

It's been pretty spectacular so far.


I used Java until 2002, then used Ruby until 2009, then switched to Javascript (server side). 3 months ago I decided to switch back to Java and I really feel I lost a decade with experiments.

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.


Enterprise developer using Jersey to make RESTful apps here. I've come from a Django background in my own time, and while it's pretty verbose you can get a lot done with Jersey and spring-wiring things.

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.


It turns out, I am really a static-typing ...type after all.

Have you tried Scala?


What did you use for server-side JS? It's not a common option for app development.


I did my lonely venture in java. I think the main problem of java for startups is that it's uncool. They're trying to rationalize, but they are wrong, you avoid wearing a tie to express that you're not a number, I don't know why you wouldn't avoid java as a statement that you're not an IBM consultant.

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.


You seem to be implying that the default is to wear a tie and use Java. When I decide what clothes to put on in the morning, I don't even think about whether I want to wear a tie. I would only think about wearing a tie under exceptional circumstances. Similarly, when I start a new project, the thought of using Java has only entered my mind once: when an applet seemed like the only solution to the problem.

I think we see a lot of Ruby and Python in startups lately because they're a good blend of productive and well-known.


1) No, you can have a Java webapp up and running in < 1 hour for < $10/month on an EC2 micro instance. 2) Compared to the other popular languages right now, Java will solve far more performance problems than it adds. And yes, performance matters, and hardware doesn't solve everything. 3) We use Java at StyleFeeder, and reached profitability before being acquired. I credit our ability to pivot/refactor/scale quickly and cheaply enough to get to that point to many things, not the least of which is our decision to use Java.


I'm involved in multiple startups using Java - both the language and more broadly the JVM (Groovy, Scala).

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.


//bloated enterprise stuff//

by this you mean the frameworks like Spring, Struts or the buzzwords like JMS, EJBs?


JMS and EJBs aren't buzz words. They're specifications implemented by the Java EE reference implementation - allowing one to develop JMS and EJB components for their applications which are deployable in glassfish application server (and any other Java EE application server platform).

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.


i guess stuff like EJB, JMS. Spring is kinda lightweight compared to those frameworks/platforms.


I would totally disagree with you on that. If you use only the IOC controller for injecting your classes, maybe, Spring is not bloated, but also, its usefulness is not that great. But as soon as you begin to enter the wonderful spring-mvc world (which is the standard way to handle web apps using Spring), bloat is all around.

Take a look for example at the family of spring MVC controllers (http://static.springsource.org/spring/docs/2.5.x/api/org/spr...) : before doing any development, should you have to study such a family to know which controller should fit everyone of your use cases ? That, for me is the very definition of bloat.

Furthermore, the documentation is terrible, IMHO. That said, I have been spoiled by months of Django development, maybe it is not that bad according to Java Standards.

More generally, the main problem with Java is the emphasis on architecture astronautism, not the language itself, which is ok, if not very powerful (no function as first class objects, really ? ).


I don't mind the core of spring but the full spring stack is nearly as bad as Java EE - I was reading through what was suppose to be a simple minimalist tutorial on how to implement CRUD operations in spring the other day and my jaw dropped at the amount of duplication, verbosity & incomprehensible config involved:

http://www.adobocode.com/spring/adding-crud-capability-to-sp...

I'm personally into much simpler stuff like Stripes & Guice.


I'm no fan of Spring, but I do want to echo your sentiment. There are a lot of really good Java libraries and frameworks that are often lumped together in people's view with the more verbose "enterprisey" concepts.

There are two things I really like about Java in the broad sense: the excellent Eclipse environment, and the multitude of quality open source libraries.


EJB hasn't been any more bloated than Spring (quite possibly less) since Java EE 5. Welcome to 2006.


possibly, but Spring makes some things simple as possible :)


avoid XML

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


Java will be definitely an option when we consider developing a web application. However at the moment we are not exactly web startup (developing android application).

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.



Java/MySQL was right choice for Bazaarvoice 5 years ago, when we started. CouchDB will be my choice in today world.


care to share why?


Because CouchDB implements about 80% of what we need. I can reimplement core engine of Bazaarvoice engine after first year of development in few days using CouchDB. (About 5% of our work).


It is not performance or hosting concerns. Java performs good enough and you can host it on things like EC2.

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.


I've heard this "more productive" refrain countless times, but I have yet to see it in reality. I would love to be made aware of how exactly Java doesn't allow one to pivot easily.

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.


I sold a Java-based program for about four years and have a previous background in Big Freaking Enterprise Java Web Development.

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.


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.

Have you tried Phusion Passenger (http://www.modrails.com/)? It is trivial to install and makes Rails deployment a snap.


Or you can do what heroku does, and use thin. Just gem install it, and start it. Java has a similar approach with jetty. Both solutions are inadequate, at least standalone, as you get a few more users or require more security/performance. But for starting, it is simple and easy.


Also Capistrano (http://www.capify.org/) for deploy new changes is really easy.


I had Java project that was deployed using Capistrano. Great thing. :)


I'm curious as to why you would call Java easier to deploy than Rails.

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.


Java for most startups won't be Java EE. My best experience with Java recently has been with Jetty as an application server. It's fast and it's lightweight.

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.


++Jetty. It's also great for development as it handles hot swapping of code changes, so they can be tested immediately without a container restart.


what version of jetty are you using? Last I looked, hot swapping code was a huge PITA and not an out-of-box config.


Jetty 6 (with Tapestry5).


I think one major difference/hurdle of java web development and deployment is the fact that you HAVE to setup something like nginx in front of the app server or else you're working on port 8080 for everything. Or you have to know how to configure the app server for port 80 directly and mitigate the security concerns of doing so. By comparison, apache defaults to port 80, no tricks required.


If one is unable to change the port from its default, one doesn't have any business in developing web apps in any technology. Just sayin'.


Apache forks a child process with lower rights than root. App servers that run on port 80 do not without a native JNI lancher. The solution is native launcher, a router rule or iptables.

I think the parent is talking about living in a chmod 777 world. Or maybe he is tired of crazy symlink hacks so that sftp becomes an option. Some appservers put class cache in WEB-INF by default, etc.


See my post below: a non-priv'd user can't start the java app server on a port sub-1024 unless you mess with the OS to allow it. I just double checked with my jetty install and I got a "java.net.SocketException: Permission denied".


changing the port of an app/web server z no big deal..if u really wanna deploy something.


Actually it isn't trivial for java webservers. Only root processes are allowed to use a port <=1024 by default, so you can't just change a config line in tomcat/jboss/jetty and have it work automatically. You would have to then start/run the app as root, which is a Bad Idea, or mess with getting the OS to allow you to use a lower port. The safest solution then is to have something in front that is allowed on port 80 and setup forwarding to 8080.


There is play framework, which is very good and comparable to RoR.


We're a Java house and just launched http://www.jigsawbox.com using the Play Framework (http://www.playframework.org/).

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.


I'm an experienced Java developer, but a bit of a novice when it comes to webapps on Java. I've tried Java EE, Spring, Hibernate, etc and hated all of them with a passion. For writing simple apps it was a mountain of configuration and framework.

I've got to agree that Play is a breath of fresh air. It doesn't hide/automate as much as RoR, which I appreciate. It's really easy to get going with and it's made writing web apps feel quite natural.


Not sure Play will scale using Excepitons for flow management.


It does scale, believe me. In order to scale you have to be able to load balance to accommodate a higher load.

Using exceptions for flow management doesn't prevent you from adding more boxes. If you're thinking it can cause performances problems, I have an app in prod; here are some numbers: * With a single box, we can do about 500 req/s for a dynamic page, accessing the database * It appears that the bottleneck is the template engine. If we cache the result (thus serving a "pseudo static" page) the exceptions-based control flow is still there but we serve up to 1000 req/s. (That's more than Apache can do to serve static content on the same machine).

So yes, Play does scale!


(str "There is" "an easier route")


Sort of. I absolutely love Clojure myself and use it anytime I have the slightest excuse to, but I really feel one of its major shortcomings is the lack of a good templating library. Hiccup is really clean and concise, but it's just not a practical real-world way to handle presentation of a website unless you want everyone writing html to know Clojure.

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.


I have been part of building a web startup using Java technologies. Our stack was - 1. Apache + Jetty 2. Java 3. GWT 4. Rules engine (drools) 5. Solr/Lucene for searching 6. Mysql (InnoDB) 7. Amazon web services (EC2, S3)

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.


The Mibbit backend is Java. It gives us massive advantages over any competition.

The JVM is extremely fast and optimized. We handle many thousands of requests a second on a few VPSes.


Hi you application is great , can you please give more info about how your servers are configured and how many VPS , are you using ?


I've used java since 1995. I agree that some EE projects are overly-complicated (EJB, etc.) and make simple tasks seem difficult. ...However, there's usually a reason - and, the bottom line is that you probably don't need to use those projects anyway.

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


I work at a startup that uses Java. When it started, the CTO knew java so thats what they picked. Now, the company has grown to around 10 people with over a million users. They're monetizing pretty well and are well on their way to being very successful.

As (almost) always, performance issues are with the db. And, as always, you should think about the data structure that you're using.


We decided to use Java and especially Wicket for our startup tasqade.com last year. I must say, I am still more than happy with this decision. Wicket is an awesome, growing framework, which made our lives so much easier. The clear seperation of code and html is just wonderful.

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.


Follow up question: Any startups using Scala?

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 learning curve with Scala would properly be higher but I really, really like the Lift framework.

And I think Twitter is using Scala.


FourSquare uses Scala.


Java has a strong background in enterprise solutions. So, e.g., if you need to build some sort of high performance distributed system then it's not an entirely wrong choice to go with Java. Java is good at that stuff.

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


That's the choice I made: http://bens.me.uk/2010/jruby-in-practice

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.


Yes, web startups are using Java, like mine. What I can't figure out is why the other startups need so many developers. :)


Java EE is an excellent development platform for any kind of web application. Its just a shame that everyone seems to assume its very difficult to implement.

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.


Check out www.playframework.org they have a successstories site that shows successful startups for their bundle. I'm working on a site right now using it, it's really neat. Scales really good, and is totally lightweight.


You can do some really awesome stuff with GWT+Java, although GWT is like that girlfriend that always wants to be exclusive.


I was in a startup that built a MySQL/Spring/Wicket app, and I'm building a Mongo/Play one right now. So, point by point:

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


I'll give you my take on this as a Java programmer of 10+ years experience.

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.


Just want to mention that long-running applications written in 1. (e.g., C) can be slower than languages in 2. (e.g., Java) because the VM can optimize hot operations.

Other than that, I agree with your post!


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.

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?


It's not a strict either/or. Even those who are using more dynamic languages/frameworks for their web-facing services may use Java for deeper infrastructure: Lucene/SOLR for search, Hadoop/HDFS for large data-mining, HBase/Cassandra for big-NoSQL tables.


I've just developed a website using Java, for the HN November "Launch an App Month." It's a Javascript-heavy frontend plus Java backend app, with a whole separate background processing pipeline done in Java. I'll do a show and tell in couple days once it's ready.

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.


I'm not on the development team, so don't know the rational behind it, but I know we're using GWT and Java at Rypple. I can connect you with one of our developers if you're interested. My email is in my profile.


Our main product isn't a web application, but we're the oddball startup that's using Java/Swing to build a desktop application which is a visual designer for creating both Flash and most recently, iOS games.

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


Sure they are using Java, through languages like Scala and Clojure both of which runs on the JVM, neither of which forces you to actually write in Java.

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


linkedin, hulu, rapleaf, flixster, zillow


mint.com is/was another one


hulu uses rails...do they use jruby?


videoegg


My startup http://www.onmydoorstep.com.au/ is Java/Wicket/Guice/Lucene based.

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.


I think you meant a wealth of open-source libraries. There certainly isn't a shortage.


Damn, you're right. I must have been thinking about Star Wars.


A Plethera might be a better one.


4) Hiring is a slog as most Java people you come across will only know the "Enterprise" way of doing something and seem oblivious to any of the web frameworks out there or any pragmatic and quick solution to something that they already know an "Enterprise" solution for.


That's hardly their fault though is it? Most enterprise shops won't use the latest and greatest technology because it's 'unknown', unproven' and so on. Heck, a lot of places haven't even bothered upgrading from java 1.4.2


IMO, web startups choose Java when:

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.


We use a lot of Java at media6degrees, entirely for performance/integration reasons. There's a reason Cassandra, Hadoop, HBase, etc are all written in Java. I'm still trying to figure out what that reason is but my guess is that Java's the least bad language for what they're accomplishing, maybe that'll be Go in the future.

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


At Viddler (http://www.viddler.com), we're using Java for the core parts of the site, including an API, which we build on top of using a combination of Ruby and PHP.


Generalization ahead

Java is mostly snubbed in web startup land and associated with boring corporate work.

More discussion here: http://news.ycombinator.com/item?id=1378815


There is a good chance that the more 'boring corporate' people tend to keep to themselves more. I don't imagine serious startups are always glaring things in your face about the technologies they use, which comes off as 'web startup land' to people who are willing to read that kind of stuff. (not that I'm any different)

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.


There is. For example, all tier 1 investment banks use Java for their trading infrastructure (as well as C++).


There's a website out there called InfoQ, I think that's where all the enterprise folk hide


I believe that one of the reason is lack of good web-applications framework for quick development. There is nothing like django or rails, so if you need to have non-trivial application created in minimum time java is not the best platform. In case when your team consists of plenty different skill level developers java is much safer platform. Performance of the application and hosting is not a problem. Hosting of java application usually is much easier than everything else and performance of jvm very good comparing to other platforms.


I used to think so as well but now there is a great framework called Play:

http://www.playframework.org/


JRebel is worth a look for a similar experience. It reloads classes when they change so no server restarts required.

http://www.zeroturnaround.com/jrebel/


As long as it costs money and is not open source, this will never become hip amongst the cool guys.


IDEA costs money, is not fully open source but is still hip. What gives?


The problem with frameworks like Play, or Symfony in PHP world is that they only play catchup to frameworks like ROR and Django and since they started way later, they still lack the polish.


Or alternatively, they learn from the problems of older frameworks, and can bring a fresh approach without having to worry so much about backward compatibility.


Why is this a problem? They will tend to choose to implement only the best practices. For example my (I'll admit biased) experience with play framework was better than with RoR and with Django.


It would be nice if this framework get more traction


Yes there is: grails.


I believe that Veera means java as a language but not jvm as a platform because a lot of startups use jruby and closure for their applications.


There are lots of great frameworks for ColdFusion/Railo.


ColdFusion is not associated with fun development, may be I'm wrong, but for me it is associated with plenty of config xmls and other enterpricy stuff.


Been using CF for 10 years, Java for 5. CF is a great bridge from the functionality and performance of Java with the ease and natural fit of a loosely typed language when building for the web.

CF and it's community is not the same beast it used to be, I would encourage you and others to take a second look.


Maybe it's been a while? Check out http://www.coldboxframework.com/ or http://fw1.riaforge.org/ as examples of the state of things these days.


Yep, Coldfusion is overly underestimated. It now supports script based syntax (similar to Java) and has a tonne of built-in useful functionality like Ehcache and more...


Another perspective is that Salary and competition for Java programmers are way beyond affordable for most start ups who have not made it big.

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.


You can get top level Java programmers for $95K?! Where are you based??

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.


The startup that I used to work for was recently sold to a popular silicon valley based company for 30 million usd. Full Java. Running on own servers and EC2. Highly scaleable service based architecture.

It happens.


We use Java, MongoDB, Hadoop and embedded Jetty at MetaBroadcast, we try to keep it simple: no enterprise bloat etc. We've not had any performance issues.


2 main reasons i can say about this are:

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.


DOmedia (http://domedia.com) in Columbus, Ohio uses Java/JSP.


There are many big web companies that use Hadoop, which is a Java based distributed computing platform (based on Map Reduce). These include Facebook, Yahoo and Last.fm.

Theres an ever growing list at http://wiki.apache.org/hadoop/PoweredBy


I've seen a lot of startups using Java for web application development. Its not not that they are unaware of the other dynamic languages or the new rapid prototyping web app framework. But I guess its due to their reluctance to move to the new setup.


I built Klicktrack based on Java and it's a great platform for a startup especially for larger teams. The only drawback I can think of is the compile deploy cycle which can be a bit annoying compared to scripting languages but it can be mitigated.


We used JBoss SEAM when we built the infrastructure for our startup back in 07. It worked very nice, it was much faster to work with than other frameworks I've used. In the end we failed but it wasn't because of Java. I think...


We're a startup here in Australia and we use Java extensively. It has been trickier to use than PHP but the extra effort has allowed us to produce a very sophisticated system.


I'm building an app in OfBiz, but its a little bit overkill for what I need. My partner is also really enthusiastic about Tapestry but I haven't really looked into it.


1) We use dedicated hosting, it is still best on terms of reliability and security.

2) Not at all. But you need seasoned developers.

3) Our platform runs mostly in Java. So far good performance.


Java's the primary language here at Meetup, as well as at the previous company I worked at (Webs.com). To be honest it hasn't been that bad.


At Demdex, we use Java very heavily on both the back-end (e.g., Hadoop) and the front-end (e.g., Struts, etc.)


I met someone from Lockerz who said they have a PHP fron end and a Java service layer.


We are just using Java for teaching porpuses.


Squarespace is a lot of Java.


Quantcast is -- a huge amount of hadoop and performance sensitive code, and the majority of our external website.

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.


#1 reason: Java is a verbose language with a rather verbose design philosophy/ecosystem

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.


You're perpetuating a myth.

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?


Verbosity and increased complexity in Java comes mainly for two reasons, none of which is about minor syntactical issues.

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

[1]: http://projectlombok.org/


>> Also, Java library design often tends towards the obfuscated. [...]Adapters, [...]Implementations and [...]Factories, the usually bloated read/write beans, checked exceptions…

I've been using Java for 10 years+, and never used any of that.


You never used checked exceptions?


You're right, those are the only thing I do use, where appropriate.

If you just avoid all the enterprisey crap, Java is a very nice place to be.


Ruby can use both "{...}" and "do ... end", with a slight difference between the two (precedence):

    def some_method { ... }
    def some_method do ... end


I don't believe the second one works. Usually you'd define a method using:

  def some_method
    # do something
  end
Usually you'll only use do after a method that's already defined, in order to pass a block of code to it.


You are correct:

    ruby-1.9.2-p0 > def something; "hey" end
     => nil 
    ruby-1.9.2-p0 > something
     => "hey" 
Adding the do makes it not work. def doesn't have a do.


That would totally be on individual comfort wont it? i would love to type END instead of '}'with a shift


> Verbosity doesn't equal less productivity.

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.


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

Well, around 20 years here.

If you look at the extreme. Regular expressions. They're concise to the extreme. That has distinct disadvantages.

  * It's hard to parse
  * Easy to create errors
So clearly verbosity!=bad.

I started with basic but quickly moved on to creating large programs in assembly. I think once you've done that for a few years you start to look past the lines of code and more into general program structure and flow.

'public static final' isn't verbose. They're keywords. They're flags. They're not meaningful program structure, so your brain skips over them unless it needs to check what the flags are.

People often mistake keywords like the above for verbosity. The actual syntax of java code, eg {}(). etc is very concise.


I've be very scared of a web startup that chose Java over Python or Ruby. Why subject yourself to Java? RoR and Django are both solid platforms (among others).


Given the choice to develop in the Java, Python or Ruby language, I'd choose Python and Ruby over Java. But given the choice to develop on the Java, Python or Ruby platform, I'd choose the Java platform over the 2 others any day because with the Java platform I can choose to develop in Java, Groovy, Scala etc. and have many useful OS libraries at my disposal.

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


For our webapp the sweet spot has been Java/Tomcat for it's stability and security with python methods compiled into Java bytecode for regex and other methods that are cumbersome in Java.

The downside is that Jython throws more runtime exceptions. OTOH it has incentivized a ramp-up in unit testing (Maven, Selenium).


J2EE and J2SE are also solid platforms...


but only the enterprise developers seems to be caring about Java platforms. Freelancers / hackers rarely use Java.


Depends on what you mean by freelancers.

There's an impression that RoR is the language of choice for hackers because so many web-apps are built by it.

Web consulting firms use Java all the time because it's a proven technology with tons of flexibility. In RoR, the moment you step outside of the conventional MVC model; you are pretty much hosed, you have to write from scratch a lot of stuff that folks in Java have already enterprise platforms for. Specifically, if you want to do crazy data modeling with custom lazy-loading/cascading; or if you want to integrate some kind of high performance message system client-side; or have some kind of custom encoding/decoding of data objects from server-side to client-side (e.g., Rails to Flex/Silverlight). You pretty much have to rip up the whole rails framework.

RoR/Python is programmer's proverbial hipsterism to show how hip you are. But I would rather use Java when I need to deliver in actuality since you can't get laid anyways by impressing programmers.


Java tools are often for-enterprise, and the best of them are often for-purchase.

Tweaking a Java library is huge PITA, because Java is soooo code-heavy. I estimate Java leads to ~10x as many lines of code when compared to Ruby or Python for basic libraries like API clients. The IDE-reliance inherent in that culture removes many of the immediate incentives of code minimalism, and as such, you often find insanely convoluted libraries that literally have more classes than pieces of functionality.

Java's great if you're not in a hurry, or if your organization is infected with enough bureaucracy that the added bureaucracy in the code won't even make a dent in your already-dismal efficiency, or if you need to "get fat" (i.e. "hire a bunch of college grads and burn them out") and you don't mind dropping your talent density to near-zero figures.

With all talent being equal, give me a Python or Ruby shop over a Java shop any day, and I'm certain they will be significantly more productive, day in and day out.


Without getting all programming language religious on you, I have to disagree with you. Most Java tools are open-source, e.g. Eclipse IDE, JBoss application server, Tomcat app server, etc, all market leaders, or near the top.

We've deployed a reasonable sized startup codebase for our project without paying a dime for tools and libraries.

Plus, we were also able to carry our Java coding skills across into our Android mobile app development.

I think there are pros and cons to most languages.


I take it you never heard of a little thing called the Apache Software Foundation?


RoR isn't a language. It's an MVC framework that's good for websites (that is, web applications that have a lot of pages). It's overkill for APIs, transaction-heavy stuff, one-page apps, etc.

It's a baloney-ass straw man to set up Rails as weak when compared to Java. Rails is a limited web framework, and Java is a programming language.

Instead, you should compare Ruby or Python to Java for web development. If it's still your position that there aren't enough good open-source tools in Ruby or Python to do what you need, then I believe you're either looking very hard, or you're looking in the wrong places.


And using anything tained with the "enterprise" label would completely kill your street cred in the freelance / hacker / startup world, darling!


Scalability for one.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: