Is java dead for startups? | Hacker News Reader

Is java dead for startups?

59 pointslean_startup98 comments

It seems that RoR, PHP & scala are the "hot" languages for startups. I know that java is old, but it lends itself to better engineering IMO. Especially in NYC, where there is a robust market for high- paying java jobs at investment banks, it is hard to find lean startupers.

Are there theoretical or practical reasons to avoid java in lean startups? Any ideas where to find folks at the intersection of java + lean startups + NYC or is it hopeless?

Many thanks!

Cheers, Mike

PS Here is the job description. Applicants and feedback on the description are welcome too: http://www.socialfeet.com/2010/05/got-java-chops/

View on HN

It's funny, one initial selling point for Java was as a rapid prototyping language. Because back then it was, relatively speaking.

I think in the big picture of a increasing speed supply (courtesy Mr Moore, for cheap cycle farms and cache; but also JIT compilation techniques), and comparatively fixed user speed demand (a gui only needs to be fast enough; network latency swamps many other delays), Java is now much faster than it needs to be (faster meaning performance, not development time).

Back then, you had compiled languages (C, C++) that were fast, and scripting languages, like python, that were not. Python was touted as a glue language. Anyway, Java was mid-way in terms of speed (being partly compiled and partly interpreted), and mid-way in terms of dynamic benefits (eg. garbage collected and runtime array bounds checked - but requiring static typing). That combination of ease of use and performance was a good fit for some tasks, at that time. As the speed supply moved up, Java became usable for more tasks. But as speed kept increasing, Python and Ruby and even PHP also became fast enough - and they had the ease of use of being fully dynamic.

To give a direct answer your question: agile/iterative prototyping is how startups compete these days (not on performance), and ruby, php etc are better than Java on this particular attribute. Another aspect is that many cool new things are happening in languages other than Java - they have more interesting tools (eg. Sinatra), and more interesting energy in the community, because they attract those crazy, eager, young, passionate, enthusiastic early adopters.

Exceptions: where more performance is required (eg. Google uses a lot of Java; and it's the basis of the Android platform and others); and for the Enterprise; and also where type-safety (for reliability) is more important than agility (though ML-based languages have some of this market).

Note: a startup can tackle any problem, not just consumer-facing webapps. I think webapps get disproportionate publicity (because they're on the web); and web forums (like this one) favour them.

btw: I remember Java's younger years, I'm still a fan, and I'm using it in my product development. Java... some one still loves you.

I was under the impression that much of googles code base is python.

Most of the core code is C++ or Java, though there is plenty of Python.

I mentioned Java to a high level googler friend and his instant response was: Java == Slow.

By the standards of a high level googler, probably all languages but C and Ocaml are slow.

Indeed. Most of the server-side code for youtube is written in python.

> Another aspect is that many cool new things are happening

> in languages other than Java - they have more interesting

> tools (eg. Sinatra), and more interesting energy in the

> community, because they attract those crazy, eager,

> young, passionate, enthusiastic early adopters.

Of all the comparisons I've heard, this is one I'd say I'm dubious about. There is still a LOT of activity in the Java space, and lots of cool and interesting tools and libraries continue to be written in Java.

Off the top of my head, I'd mention Lucene, Hadoop, Weka, Mahout, Tika, HornetQ, UIMA, GATE, Camel, Jackrabbit, DERI Pipes, etc., etc. This isn't too say that other languages don't also have lots of activity in tools and libraries and frameworks, but I think Java is still in pretty solid shape in this regard.

Most of the projects you just listed are several years old, and some go back more than five years. That's not exactly "new" when it comes to computing.

Yeah, but they're all being actively developed, so I'm not sure how much it matters when the project was originated. And that was just "off the cuff" of stuff I use or am interested in. There's other stuff out there as well.

Anyway, I'm not arguing that Java is the most active in this regard, just that this particular criticism - of all the ones one could level - is, in my humble opinion, relatively weak.

Don't confuse "development" with "maintenance". They are very different things. We see most of those projects merely being maintained, not radically improved.

True development is happening within the Haskell community, for instance, where they're taking concepts from various fields of mathematics and applying them to software development in ways that haven't really been done before.

Most Java-based projects are merely reimplementing something that somebody else has already done, or they're making minor, incremental improvements to a well-aged piece of software.

5 years ago was probably Java's sweet spot, in terms of cycles being used to help the developer, while still giving adequate performance.

It would be interesting to graph the average ages of the users of the popular languages; youth being a proxy for the (perceived) current best thing. When you're starting out, why wouldn't you choose that?

Java is an avowedly corporate language. It isn't built to be fun or elegant or beautiful or especially powerful - it's built to be robust, idiot-proof and flexible.

For startups, it just seems very poorly suited for the task. I think most of us would agree that the main advantage any startup has is speed and agility. Java isn't that well suited to rapid development, at least not compared to Python or Ruby. It doesn't offer any potentially game-changing technical advantages over the mainstream like Scala, erlang of JavaScript might. Java is a sturdy, reliable language that is very well suited to fairly boring corporate work. It's just not rock and roll though, is it?

Think about the standard startup rhetoric - do one thing and do it well, start small and iterate rapidly, split the market with something unique. If you're going into battle against an incumbent, you need to change the rules of the game - you don't want an AK47, you want an IED. If you're trying to build disruptive technology, it seems obvious that you'll be better off using tools that are themselves disruptive.

> If you're trying to build disruptive technology, it seems obvious that you'll be better off using tools that are themselves disruptive.

OTOH, tools themselves don't how disruptive your product is. The iPhone and Android are disruptive, even though Java and Objective-C are as boring as tools get (although the Dalvik VM is quite wicked).

Find the best developers you've worked with and let them choose whichever tools they like. That being said, some of today's best Java developers will likely end up choosing Scala for a project they're building from scratch.

Remember to separate the JVM from the Java language. Java the language is getting old - its not that Java is bad, its that languages like Ruby & Scala are better - programming languages have evolved since the early 90s.

A startup has to do all that you said, plus one more thing: dont reinvent the wheel. With languages like JRuby and Scala built on the JVM you can reap the benefits of the agile philosophy and still make use of the available solid java libs (Apache Commons comes to mind), and not have to reinvent the wheel, saving the startup a ton of time.

If you're a web shop, IMO, none of the Java web frameworks are ideal for the fast prototyping that most startups need to do on a regular basis. I've hated every Java web framework I've ever worked with and I've used most of the popular ones. Always felt like I was fighting the framework for one reason or another; too verbose, not expressive enough or too tightly structured.

There are some decent platforms for the JVM though.

The play framework sounds like something you'd be interested in. It abandons the Java conventions for a more rails like experience. http://www.playframework.org/

playframework is way better than rails in my opinion

No comments about the Lift framework ? FourSquare uses it

Watched the screencast. First thought when I saw 'SomeClass extends Controller': this will be hard to evolve.

Tapestry 5 has done away with this and does not require interfaces or superclasses anymore in order to avoid breaking the API in future releases, they should have learned from that.

Yeah, never heard of it until now. If I ever venture out into Java land again, I'll have to give it a better look. How does it compare to Grails?

I've never looked at grails so I can't offer an opinion but I have some links that may be helpful to you. The first is a HN discussion on the play framework and the second a discussion on google groups about the differences between the two frameworks.

http://news.ycombinator.com/item?id=898738

http://groups.google.com/group/play-framework/browse_thread/...

You can use Play! with scala as well, so you get a good framework AND a more interesting language at the same time ;)

I think Anatari is right on the money. It seems like a lot of startups are web shops, which means Java may not be the best fit. But on the back-end, it's great. I would imagine that a lot of back-ends are initially written in some other language and then rewritten in Java (or another JVM language) when performance really counts.

Writing your own web framework in Java isn't rocket science ;)

Without exception this sentiment should not be reserved for just Java web frameworks, but rather the whole lot of server side web-frameworks. with the JavaScript/RIA tool-kits now maturing, there is no need to use a server side web framework for UI concerns.

With the clean separation of discipline that this creates, Java and a multitude of other languages are fine for providing the data and business services that said UI application communicates with.

Given Java's plethora of libraries available in the middleware layer, I do not know why someone would not consider it as a potential candidate for their service layer.

To be clear though, it is not only Java but the entire concept of assemble a screen on the server, push it to the client and then every action on the client requires a trip to the server to make a decision, was just plain bad design. All of these server frameworks are designed to write applications in that manner.

The web started as some people putting up pages, HTML forms where bolted on and then someone backed it with CGI/POST and the web application was born. Unfortunately, until the JavaScript/RIA frameworks came along, we had not moved the needle much past CGI/POST we just put some window dressing on it.

The decoupled JavaScript / HTML5 / CSS UI is now breaking the constraints of the old page-post model and the reality is the server side frameworks are rooted in the page-post model and are no longer a necessity.

did you try Tapestry 5?

I use Java primarily in my day job, but usually RoR in my side projects (unless I'm using something else just to pick up the language/skill).

I think the reason you don't see Java in startups as much anymore is that it's neither rapid nor enjoyable to code in. It's also more difficult to deploy in production and more expensive (it requires more RAM to run well in my experience). Continuous deployment is more difficult with Java. Ruby and PHP you can just push code and restart the server almost instantly, Java takes longer.

Java is getting better, but not fast enough, and it's still not a fun language to write in. If I'm going to spend 12 hours coding, I'd like to enjoy it. I can think faster than I can write Java. I'm just able to get more done with other languages.

You should look at the Play Framework (www.playframework.org) if you'd like to see rapid Java.

Agree that Java is verbose though. Java7 will improve things only slightly.

I've seen that before. Interesting technology. Spring Roo shows some improvement in that regard too (although not the compiling after changes part).

I've actually gotten to use groovy/grails for a lot of new projects/enhancements and that is making my job much nicer.

Born again Java fan here. I took a diversion into languages like Python (which I still heavily use), but now I wish I had just used Java in the first place. Once you turn a program from a 2 hour long run-time down to < 10 minutes (my Lucene vs PyLucene experience), you don't really see the benefit of using Python anymore. Plus I've realized that I prefer static typing.

I usually throw the search engine up as a rest service, and keep the web app in ruby on rails. Best of both worlds.

The benefits of dynamic languages are not their speed, its the rapid prototyping and interactivity they provide once the prototype has been designed it can be implemented for speed in any lanuage providing the features you need.

Well, then I disagree that after two years of really using Python for everything, that I've been much more productive than with Java. I bet I spent a good chunk of that time debugging errors at run time which would have been caught at compile time with Java.

Of course that is a non-scientific anecdote and there are times that the REPL is just awesome (especially for web app development).

This has been my experience too. Currently I like Python for quickly banging out web apps, and Java for building the back end stuff.

Sure, Java has some baggage, but it has a lot of benefits too, such as much better tools for deployment, performance profiling, libraries galore, the JVM, and more. I find it's often the best tool for the job when there's heavy lifting to be done.

Speed is a bad reason to choose Java or other less expressive languages. There are many more expressive languages with speed comparable to Java, including but not limited to Haskell, Common Lisp, Scheme, Clojure, Scala and several ML variants. Some of these run on the JVM and some offer static typing. It looks as though Psyco and LuaJIT compare well to Java in microbenchmarks as well.

>* including but not limited to Haskell, Common Lisp, Scheme, Clojure, Scala and several ML variants *

Any non-FP languages?

Most languages that I would designate as "expressive" allow FP, but not all require it. Common Lisp isn't very functional; it doesn't even do tail-call elimination by default. It's idiomatic to use a fairly imperative style in CL. Scala allows FP, but also has OO that's fairly similar to Java with less boilerplate. Lua allows FP, but an imperative style is idiomatic (it doesn't even have map/reduce/filter built-in).

Edit: BigForth is an implementation of Forth that seems to be pretty close to Java in speed. Forth is not a functional language. D is a fast language intended as a C++ replacement. Despite looking a bit like C++ or Java, it can be quite a bit more terse than either. D 2.0 adds quite a bit of FP support to make concurrency and parallelism easier, but you can still write C in D if you so choose.

I was not aware that D and Lua had the JVM as targets.

You only asked for non-FP languages, not non-FP languages with the JVM as a target. There's a Lua implementation for the JVM called kahlua. It appears to be in a fairly early stage of development and may not be fast or suitable for production use. As far as I know, there is not a D compiler for the JVM.

Groovy appears to be potentially as fast as Java. It can call Java easily, which means you always have the option to rewrite something that's too slow in Java itself.

Thanks again. Apologies if my terseness meant a loss in clarity. I thought the JVM was implicit in the thread and that you were listing languages with the JVM as targets (also my mistake as I see that you were not exclusively listing those, guess I should refrain from posting till I've had more sleep).

I guess this is the reason why Scala gets a lot of attention: same speed as Java (on JVM), fully compatible with Java, it has static typing, and it's productive like RoR or Python.

BTW, both the Java (javac) and Scala compilers were written by the same person.

I have not read where Scala is the same speed, citation?

its not real "proof", but check out the Computer Language Benchmarks Game: http://shootout.alioth.debian.org/

So if that isn't 'real "proof"' what would be 'real "proof"' ?

Implementation + problem specific.

Languages aren't fast, code + data + implementation combinations are.

The language and its implementation will limit the efficiency of the end-result (the running code).

The current Google Go compiler implementation produces slow code, but there's a potential to make it as fast as C. The JavaScript implementation can be made better, but it will never be close to C.

Scala running on JVM will produce similar efficiency to Java. On multicore the Scala compiler will likely produce a faster code by default, but that advantage can be matched in Java with extra work.

Scala running on .NET will likely perform similar to C#.

Now it's up to the developer to create efficient source code for the given language. It is possible to write slower code in C than in JavaScript, but the focus should be on "normally".

Normally Scala gives you the same end-result with less work than Java. There are exceptions.

More: http://www.scala-lang.org/node/25 (Look for "Scala Compiler Performance")

An older measurement: http://fupeg.blogspot.com/2008/06/scala-vs-java-performance....

You seem to have encrypted your comment - please decrypt so we can understand and evaluate the point you wish to make.

Scala is as fast as Java because similar code in both languages compile to the exact same bytecode.

With type specialization in Scala 2.8 it will be even faster than Java in some cases.

I once wrote some blogposts [1] titled "Why do Startups still use Java? ". I would have thought people who wanted the Java libraries/JVM would have used Scala or Clojure. I understand why people would choose Java over say Python (the need for specific libraries like say Hadoop which have no direct equivalent in Python/C land), but I've not yet understood why they won't use Clojure or Scala once they choose the JVM.

I wasn't (and am not) running a startup so I asked some friends who were (and were using Java). I never got a satisfactory answer (but I got some surprising answers including "If I were 5 years younger I would be using Scala or Clojure but I am very productive in Java and don't have the energy to learn new languages"(!!)). Another interesting answer I got was that their startup focused on business value but needed only average programmers (I am just reporting what people said) and could very well work in Java. All answers tended to "Sure Java is inferior but there are mitigating factors."

Fwiw, If I were to ever start a business where software was a differentiator I would use (a) Scala (if JVM/libraries were important) (b) Haskell + C or (c) use a custom Scheme variant I've been hacking on for many years + C.

I personally think the fears of not getting good programmers if you build in unusual languages is overblown. Even in Bangalore, good programmers would jump at an opportunity to work on interesting systems and interesting languages. I am not looking for work but I would still consider a job offer from a startup using interesting languages very seriously.

[1] I was trying to figure out stuff by writing and so these posts are not polished, but if anyone wants to read, here they are

http://pindancing.blogspot.com/2009/07/why-do-startups-still...

Almost all of the best Java developers that I know (including many who ran Java user groups, podcasts, started well known projects) would choose to use Scala on a new project rather than Java. Given Scala's present state (many performance problems were ironed out in 2.8.0), I simply don't see a single reason not to do so.

It's quite puzzling why the author of the parent article lumps it in with Ruby as the two aren't very similar.

On the other hand, I've seen a friend who's a good (but not great - and he's well aware of it) developer, but is rather entrepreneurial (quit a very well paying job to work on his own project with no external funding) was very surprised after I told him Scala is statically typed. Apparently Java developers almost develop a sort of a Stockholm syndrome that leads them to believe that "if it isn't verbose and limiting, it must be dynamically typed and slow".

But you are forgetting that its much easier to hire experienced Java programmers than experienced Scala programmers, simply because there are not that many of the latter.

If a Java, C#, C++ (or F# or OCaml) programmer isn't able to pick up Scala (or any other typed object oriented language) quickly on the job, they aren't that great of a programmer (even if they are experienced).

Same for knowing any of {Perl, Python, Ruby} and being able to easily pick up the other. Some of the more advanced idioms may take longer to learn, but it's a fact of life that you'll have to learn new languages as you go.

On the other hand, if you need to hire average but experienced programmers (e.g., if you're doing outsourced CRUD app development) then you might have an argument.

I dont want to pay people to 'pick things up on the job'. I want people with a proven track record in the language we use.

> I dont want to pay people to 'pick things up on the job'.

Google would disagree. As would Microsoft (they were very interested in interviewing me, even though I've never done Windows or C# programming and made that clear on my resume), Facebook, Amazon (http://groups.google.com/group/mi.jobs/msg/d81b6c1fa8f361fc) and other serious software successes.

Sounds like you want coders, not developers. What reason would talented developers (the ones with offers from all of the above, plus start-ups competing with you) to join you?

As a startup we evaluated using Scala for parts of our development but found the development tooling support to be very limited.

Eclipse is a great IDE that has been an awesome productivity booster, but the Scala Eclipse plugin kept throwing Exception.

If it worked for me, then I would have tried it out, and then I would have gotten my teams feedback, then we would have considered switching. i.e. I do see non Java languages running on the JVM to be the future, but they are not the present yet.

"As a startup we evaluated using Scala for parts of our development but found the development tooling support to be very limited."

Twitter seems to manage fine with the "limited tooling" for Scala and is the existence proof that Scala works fine in startup/production environments. I suppose they must be using ancient editors like Emacs or Vim and unix command lines? Sure, "tooling" like that existing for Java would be nice to have, but if that stops you from using Scala in a startup, you are not the target audience for it.

That said, I concede that your startup/developers may have had special needs that the folks Twitter didn't and so you shouldn't use Scala - or Clojure. Or Haskell. Or even Ruby or Python- all of these have "limited tooling" as compared to Java.

> Or even Ruby or Python- all of these have "limited tooling" as compared to Java.

The reason for the IDE argument is again, a continuation of the "Stockholm syndrome" argument. The whole reason the IDEs are considered "required" for Java developers is because the language is verbose. You don't need an IDE to write Scala: type inference means less typing (pun intended), having a REPL means you can evaluate code before compiling.

I haven't seen CDT and PyDev Eclipse plugins (which are reportedly well written, supported by large companies) get very much traction as you simply don't need Eclipse to program in C or Python: the languages are terse, the APIs (Python's standard library, C's stdlib and UNIX network APIs) are easy to keep in your head.

That being said, as Scala is more statically typed than Java (but at the same time supports a REPL) it's theoretically possible to have better IDE support for it then Java. IntelliJ's Scala mode works very well (and is free) and ensime (for Emacs) is simply incredible: http://www.youtube.com/watch?v=A2Lai8IjLoY

On the other hand, the sort of tooling that actually solves difficult problems is just as available to Scala as it to Java: YourKit profiler, JVisualVM (and other JMX consoles), etc... In some cases there tools available (e.g., sbt, ScalaSpec/ScalaTest, Slime for Clojure) that are superior to the ones for Java.

I'm going to go against the grain by saying I have created a startup in Java. Why Java? Mostly because it's what I'm competent in, not because it's the best "startup" material.

But what I have done is built a framework for a website which I can easily extend. The framework is robust and easy to adapt, so once I get my first startup up and running, I can punch out more in a much quicker turn-around.

I refrained from using a bunch of existing java frameworks/technology to speed up development because I didn't know what the end product would look like and don't like the way frameworks railroad you into a particular solution and prevent you from "thinking outside the box".

So it's very old school - Servlets and JSP.

I achieve agility by now just focussing on delivering new services, and calling those services from either JSP or AJAX calls. This gives me some flexibility in the UX.

I prototype very rapidly to prove that I can do what I want to do, then round off the edges if I'm happy that it's functionality that I want to include in the pool.

I can turn around new functionality in a matter of hours for the most part.

Pete.

Java the language is stagnating, but the JVM ecosystem is stronger than ever. Attract some smart folk with Scala or Clojure, chances are good that they know Java as well.

Agree that the JVM has a huge future.

Being a Java programmer, I find Scala a great language. In my opinion Scala is what Java was supposed to be. Indeed, there is a great future for the JVM out there.

If you lure people in with Scala or Clojure, then mostly make them program in Java, there's a decent chance they'll feel betrayed and leave sooner.

At least, that's been my experience in places that lure with something glamorous and then do only a very small amount of it.

Right, the idea is to transition newer JVM languages in. A lot of legacy code would be in Java, so the Scala or Clojure interop would let them build on top of all that. Maybe start with a more or less self-contained component, like a web services API or something could demonstrate the advantages of developing with newer languages.

Maybe, as others have said, it's due to the nature of most startups talked about here are web-centric. I had to write something in Java two days ago (not web related, but image processing) - it was my first real intro to java, sort of a crash and burn intro.

Not only did I write the stuff, it worked, it was FAST (unlike I expected, because you know "java is slow" - I found out it isn't)... and I was damn fast in changing code around, toying with it basically. All of that from zero to hero in a single day (not even an 8hr session).

I'm impressed, and I'll probably look into prototyping work with java in the future. I especially like zillion of libraries out there - great stuff if you are trying to make something fast, prototyping for example.

I've been driving python for the last couple of years for prototyping (I develop in C later), but I found out that python code of any reasonable scale is really REALLY hard to manage (at least for me), not to mention speed issues (which I sometimes need in prototypes due to the nature of image processing).

Can we please get over all this and just go with the one mantra: use the tools you're productive and comfortable with. End of story.

I'm a Java developer, but I also recognize the amazing influence that more dynamic languages have had on my way of thinking. I'm hugely indebted to the SICP train of thought. That makes me a better Java programmer too, to get around some of the stupid practices many other use.

IMHO, Java lends itself to overengineering. I am not sure why, but Java makes it very tempting to try to nail the design right before you know what you are designing.

Maybe the static typing - harder to change, so you try to get it right.

Not sure if it's only that - the static typing is more or less cared for by the IDEs and their refactoring tools.

I would like some Java developer to chime in on this.

I think it comes from a too-literal understanding of design patterns. E.g., for the factory pattern the common practice (outside of some well designed APIs e.g., google collections) the common practice is:

  public class Image {
    public Image(byte[] data) {
      // create the image from byte array 
    }
  }
 
  public class ImageFactory {
    public Image createImage(File file) throws IOException {
      // read data then create an image
    }
  }

vs.

  public Image {
    // the same constructor, but then ...
    public static Image open(File file) throws IOException {
      // Do the same thing as factory would do
    }
  }

What's the advantage of the first approach, provided there's no per-instance state (and thus reason not to just use a static factory method) within the ImageFactory class?

At runtime you can provide a different implementation of ImageFactory. For example, a unit test can define MockImageFactory which ignores the filesystem and just returns a canned Image object. If code everywhere calls the static Image.open method, there is no way to redefine it short of editing the source or the bytecode.

Good answer. That actually makes sense with the Image example, but OTOH there's still cases where a separate factory class is used where a static method would work.

I think that's one of the reasons.

It's so nice to be able to provide a different GadgetFactory during tests or at different moments that some developers decide it would be cool to have the possibility to provide different factory implementations for every class, just in case they need it afterwards.

To which the counter-argument is YAGNI (the different implementations). There are other ways to do the equivalent of mocking, though the interface / factory approach is popular at the cost of doubling the number of identifiers in play and probably having a geometric effect on complexity.

Sir, I find your dismissal of my comment rather cavalier. I am some java developer.

My experience is that static typing makes things harder to change, and therefore you try to avoid change by getting it right in the first place. Refactoring tools are not magic pixie dust (wish they were).

Though I use vi + homegrown tools, so I guess I'm not the IDE java developer you were looking for.

I am sorry. That's not what I meant.

But you got exactly what I was going for: a typical Java IDE user would be able to add a lot to the discussion.

While I use Python more than any other language, I write some Java, but can't call me typical either - I use emacs for that.

I think Java's pretty popular at startups that focus on things other than the web. For example, pretty much everything at Palantir is in Java.

Exactly. Unfortunately, since Palantir is in the enterprise space, few people on HN immediately know of the how 1) cool and 2) difficult the problems and solutions in the space are. And of course, this post hast immediately degenerated into Java vs. X as to be expected.

I agree with what a number of others have said here: Java isn't ideal for front-end web stuff, but it still has a lot of uses for low level data processing and back-end work. Also, the JVM is a great platform, and you can target it with any number of languages: Groovy, Clojure, Scala, Nice, JRuby, Jython, etc.

Personally I'm using Groovy on Grails for the web front-end part(s) of my current project, and even using Groovy for some of the "backend'ish" parts just to get through the initial prototype. Grails and Groovy are amazing in terms of developer speed - compared to Java anyway. But since it's all still on the JVM, I can just drop in existing Java libraries and - if, or when - I need to, it'll be fairly easy to transition bits to Java. For my money, it's the best of both worlds at the moment.

Then again, the stuff I'm doing is somewhat "enterprisey" so being on the JVM will probably actually be a selling point down the road.

another groovy on grails fan here... I wish more people would give it a try.. its surprisingly expressive like ruby or python , scales with the JVM, backing of all currently java libs, and great web framework like rails.

This may sound ignorant, but if you're going to use another JVM language, why not use JRuby (if you want to stick with a Smalltalk/Modula-3 derivative), Clojure (if you like Lisp and want STM) or Scala (if you want the static type checking, speed, built in support in IntelliJ)?

This is a serious question: several people I respect (who are smarter than me and thus well capable of learning new languages) are using Groovy for their projects and I am wondering why?

Of those languages you mention, Groovy has the most java-like syntax. So maybe since its easy to pick up and does what they need, there is no need to learn/use those other languages.

well the main reason I wouldn't use JRuby is because .. by programming in just Ruby, you get benefit of all the c extensions that you aren't able to use in JRuby and not sure about rails support on jruby. I would just use it without jvm. The other reason to go with groovy/grails is the grails plugins community is very active.

Well, Groovy has been around longer than Clojure, IIRC, and maybe longer than Scala, or about as long. So I'd guess that quite a few Java people who were interested in alternatives got exposed to Groovy before Scala and Clojure started gaining traction. And since there are only so many hours in the day... at some point you have to start building stuff instead of just learning new languages.

Also, Groovy's syntax is very Java like. In fact, Groovy is pretty close to a superset of Java, so you can often - if not always - rename a .java file to .groovy, and compile it with groovyc and run it. This makes it easy to leverage your existing knowledge of Java, while slowly working in the idiomatic Groovy.

All of that said, I personally plan to learn both Scala and Clojure as well; and will probably take my Scala book to the Triangle JVM Hack Night meeting tomorrow night and spend a couple of hours poking at Scala.

It seems to me the big benefit of Java is interoperability with other JVM languages like Scala and Clojure (or Jython or JRuby). This is much like the benefit you get from learning C when you work in a language with a good C-based foreign function interface (Python, Ruby, OCaml, etc). You can build most of your application in the more dynamic language, but fall back on the static language for the elements it works better for (high-performance, system-related, or interfacing with a library designed for the other language).

The advantage Java has over C is that, in that comparison, Java is really nice to work with.

Bug Labs primarily uses Java for their product and Ruby on Rails for their web stuff.

If you are assuming startup == web app, then sure Java is probably dead, in other contexts not so much. Using Java was advantageous for Bug Labs for a number or reasons - among them available open source libraries, widest adoption among customers (their business almost requires customers to touch source code and while Python would have brought in more enthusiasts, Java brings in more enterprise customers and thats where the money is), performance of the JVM, and portability across both the ARM platform and x86 stuff.

(Oh and BL is in NYC)

I work at a startup that's 5 years old and the main app is written in java, but smaller utility pages and apps are written in different languages. I think that the language should fit the problem.

Plenty of startups in silicon valley use java. If you want to talk about text editor coding performance, yeah java is the worst language of all time. However, when you have eclipse which features super efficient source code generation, code navigation and autocomplete tools? It's actually nice to have a verbose language. imho this facilitates merging documentation with code, whereas a more mathematical programming style tends to be more cryptic.

If you want a java-based framework coupled with Rails' productivity, go through the play framework's screencast and documentation (http://www.playframework.org/documentation/1.0.2.1/home). It's the only java framework I've found that excites me about development, and if you know Rails, you really know play. It's that similar.

Edit: oh, and also many, many times faster.

Just a minor nitpick: you can use Java the runtime without using Java the language. There is plenty reason to go with Clojure (I am personally dying to try it), Jython, JRuby, Scala and so on.

"... Are there theoretical or practical reasons to avoid java in lean startups? ..."

good programmers can probably program in java but given the choice would they use it at home or on side projects?

I'm well aware I'm in the minority, but I consider myself a good programmer and I frequently write Java in my free time. It's flexible, fast, and available on a wide variety of interesting platforms- I'm considering picking up a Kindle to fiddle with the Java-based SDK. It has a rock-solid (if occasionally rather baroque) set of standard libraries that make it suitable for competitive programming ala TopCoder and JoGL provides a delightful way to experiment with OpenGL. Really, if you're the sort of detail-oriented coder who enjoys the sturdy feeling of Java's explicit typing and interface-based modularity idioms, what's not to like?

Java is dead for front-end heavy web apps, but it's (along with other JVM languages) a good option for other parts of a product.

Much of the site is frequently focused on web development. Keep in mind, however, that the web is just a UI layer. What is the UI _for_? It really irks me to see Ruby mentioned _only_ with Rails next to it, as if it wasn't an a very interesting language even without it (the combination of ideas from Perl and Smalltalk).

Statically typed languages feel awkward for web development (but then again, I haven't done much web development, so perhaps I am missing some of the better options e.g., Lift), but there's all sorts of interesting libraries for Java/JVM when it comes to:

* Middleware/services (Jersey/JAX-RS, Grizzly)

* Socket communications (Netty, Mina, Grizzly)

* Distributed coordination and communication (JGroups, ZooKeeper)

* Search and data processing (several "NoSQL" systems, Hadoop, Lucene and Katta for search)

* Threading and concurrency: actor libraries like Killim and Jetlang, java.util.concurrent and jsr166y/fork-join framework.

It should be noted that you could also use them with Scala. If liked using Java, you'll like Scala even more. Unless, of course, you've already got a predominantly Java project and have a specific reason against mixing/matching Scala (e.g., don't want to have a require having another jar in a servlet container which may be incompatible with the existing Scala jar in that container).

Clojure is yet another example of something very interesting that's happening on the JVM, but to me the big pull of Clojure isn't related to it being on the JVM: I like the fact it's a Lisp-1, its STM approach, first-order data structures - with syntactic sugar - beyond lists. Even if you viscerally hate Java and the JVM, you should give Clojure a try.

Of course there are a couple of JVM specific issues that are annoying and knee-cap all the JVM languages (in comparison to C, C++, Scheme/CLisp, OCaml and Haskell): lack of unsigned types, lack of ability to create user defined "primitive types", erasure with generics (mitigated through work arounds like Scala's implicit) and other artifacts of the JVM imposing a type system on you.

Personally I was dismayed by Java's smell (associated with the enterprise CRUD web development that went on in Java in the late 90s/early 2000s, Java's design by committee, etc...) and didn't even touch it until a few years ago; I squarely believed that all _real_ programming could only be done in C or C++ (while Lisp could be used for prototyping algorithms). I found that despite Java's _many_ annoyances, it's a language that could be practical for many non-trivial programs (rather than the usual "enterprise" apps which crash when you click the wrong button). Subsequently, I also discovered the same about Erlang, OCaml, Scheme, Common Lisp and languages I previously ignored as toys/glue languages (Python, Ruby, Perl).

Is there really an aversion to using Java in a lean startup, or is this just an example of Voluntary Response Bias?

That is, are you simply observing that startups who make a big deal about the language they're using are more likely to be using one of the "hot" languages than a stodgy old language like Java?

I raised this issue because I am currently having trouble attracting java engineers, and when I queried the developers in my social network, they raised this potential issue as a source of my problem. From the tenor of most of the comments here, it sounds like there may be a bit of a cultural issue as well as some substantive reasons why java is not more prevalent in startups.

Uh, how is java better at 'engineering' than scala. Do you know what Scala is?

I agree with a couple of the posters, I think the JVM is the core piece of technology to take away from the Java ecosystem. Especially as more languages can compile byte code to run on it.

That being said Java still plays a very big role in backend systems and don't forget that some important backend tools i.e. Hadoop and Cassandra are written in java. So I wouldn't write it off just yet.

Derek

http://nosqldatabases.com

I frown upon your drive-by self promotion

I'm sorry it was bad form and I apologize, I would remove it but I can't edit the original message anymore. However, my point was still legitimate, even if the link was not.

Reply on news.ycombinator.com