[wriq]

Existing expertise

If the goal is to get to a minimum viable product quickly (like most startups) then existing knowledge is a pretty good reason to go with a certain stack. He even mentions having the main algorithm already implemented in C# so at that point it's pretty much no contest. He can always go the route similar to StackExchange in using Linux & Open Source on utility servers (Caching/Load Balancing) and keeping the MS-centric App/Database server.

[latch]

How far do you take it though? What if someone knows c+cgi? I forget the exact quote, but something along the lines of 30 years experience doesn't mean much if it's the same year 30 times.

[Chris_Newton]

> 30 years experience doesn't mean much if it's the same year 30 times.

Your quote is apt, but it cuts both ways. Using the same old tool indefinitely, even when newer tools can do the job better and much faster, might be foolish. On the other hand, learning to do the same task over and over again using different tools, each only a modest improvement on the last, might also be foolish.

In the case of your C+CGI example, I would agree that it makes sense to prefer any of the more modern "scripting" languages, which typically have both good library support for networking protocols and much more powerful integrated string handling than C.

On the other hand, there is little offered by any mainstream language ecosystem today that can't be achieved at least reasonably proficiently using tools from the .Net world as well (ignoring the obvious limitation of having to run on a .Net platform).

[NetMonkey]

Everything in life is a trade-off. And the 30 x 1 years quote nicely illustrates why you should always strive to learn new things.

However, if you already know how to do something well in one particular stack, then you should just stick with that if the objective is to ship.

The operative word is of course that you know you can do it well in that stack. If you start thinking "there has to be a better way" then you should seriously look into alternative stacks or whether you are using your current one correctly.

[eneveu]

That's an interesting dilemna. I'm a Java web developer, I know the platform / libraries / tools really well, and know how to get things done with it. I've dabbled with more powerful languages in my spare time, but I've been using Java 8+ hours a day for the last 3 years.

If I were to launch a startup, should I go with the "cool shiny powerful" language, or should I stay with the boring verbose language that I know well? Would the fun factor of using Clojure / Scala / Ruby / Python / Blub++ be worth it? Would the language "power" offset the time "lost" gaining experience with a new platform? What about hiring? Hackers love powerful languages.

So many tradeoffs.

[Chris_Newton]

> If I were to launch a startup, should I go with the "cool shiny powerful" language, or should I stay with the boring verbose language that I know well?

I think the danger with this decision is that we tend to get a "grass is always greener across the street" mentality. I have yet to find a programming language that has no serious warts.

Certainly different languages have different warts, and thus suit different jobs better. However, just because we haven't used a language enough to appreciate its warts, that does not mean we will not discover them to our cost at exactly the wrong moment in our new project.

Moreover, with newer or more recently popularised languages, there is sometimes a tendency for the community to bury its head in the sand. Some defenders might claim that we "just don't understand" if we identify a serious shortcoming. Sometimes the individual or group that defines/specifies a language will have a blind spot and make seemingly arbitrary decisions that we don't agree with. In contrast, with longer-established languages, the shortcomings tend to be well-known and acknowledged, and the emphasis in the community is often on sharing the most effective workarounds or alternative techniques.

Obviously these generalisations aren't necessarily universal. We find helpful people in otherwise intransigent communities and awkward people in otherwise helpful communities. Still, I have seen the pattern repeat over the years for many different languages as they evolve from the Newer And Better Thing to a mainstream tool and ultimately to an older tool that is superceded by the next newer and better thing.

When I'm choosing the tools for a project, I usually favour the middle of that spectrum over either extreme. Out-of-date and underpowered is bad, but tried-and-tested is good. YMMV.

[eneveu]

Very good points.

In contrast, with longer-established languages, the shortcomings tend to be well-known and acknowledged, and the emphasis in the community is often on sharing the most effective workarounds or alternative techniques.

Exactly. A good example of this is dependency injection. In Java, it was hard to mock dependencies, like you would do in a dynamic language. This forced the Java community to look into dependency injection / interface programming, to make the code testable. Dependency injection then lead to better componentization / modularity (some could say that one shouldn't have to use dependency injection if one were using a "better" language, though ;) ).

I also like established languages, because there are also established best practices. You don't have to reinvent the wheel.

Certainly different languages have different warts, and thus suit different jobs better. However, just because we haven't used a language enough to appreciate its warts, that does not mean we will not discover them to our cost at exactly the wrong moment in our new project.

That's the reason why I'm leaning on using a JVM language. I know the platform and the tools, and I can always "fall back" to Java if needed (for performance critical code or whatever).

Maturity is important, but I don't want to miss out on the power and expressiveness of higher level languages ( http://www.paulgraham.com/avg.html ). Using powerful languages is also useful when hiring good hackers ( http://www.paulgraham.com/pypar.html ).

[beagle3]

This is not actually an "either-or" question.

For a minimum viable product, you need to do the minimal amount of work, whatever that turns out to be for the startup you are building.

Is it something like DropBox? In that case, you need to write at least part of your product as a Win32 Shell Extension, and regardless of how well you know Java, it is MORE work doing that in Java than in C++

Is it the new GoogleDocs/ZohoOffice? In that case, about 90% of your work is in JavaScript or a language that compiles cleanly to JavaScript. This might be Java (by way of GWT), but probably isn't.

Is it a new "enterprise software system"? Java is probably a good choice, even if Java wasn't your strongest point.

And if it HAS to be java for some reason, there's Clojure, Jython, Mira, LinJ and a few others that let you switch slowly and incrementally, without having to decide or make a tradeoff.

[mgkimsal]

Have you done anything with Grails or Groovy yet? My experience is that it's probably the easiest transition for Java devs, because Groovy is something that can be interchanged in each file with "plain old Java".

[eneveu]

I haven't mentioned Grails / Groovy, because it always seemed to me like some kind of a "hack" to improve Java with some nice syntactical sugar / DSLs / dynamic programming. Scala / Clojure seemed more interesting, and I focused on them.

I've only tried a small "create-your-blog-in-15-minutes" Grails tutorial, and it was actually quite effective. I haven't revisited it since then. Thinking about it, my Groovy avoidance is absurd, and I WILL look at it again with an open mind. I remember "dismissing" Groovy a while ago, after reading a few articles raving about Scala being the next JVM language. I think it was quite dumb of me actually.

A colleague of mine used Grails to build a small issue tracker for a client, and he loved it. The only drawback, according to him, were some of the plugins: when the default plugin configuration wasn't what he needed, it was sometimes hard to change it. Since they were open source, he simply forked them / hacked at the code / submitted patches to improve them. These drawbacks are expected, though, since the language is still young, and plugins will mature.

Spring Roo also looks interesting, for those who want to keep using Java. It's inspired by Rails / Grails, and uses code generation to speed up development: http://www.infoq.com/interviews/roo-ben-alex

[mgkimsal]

I've been a bit annoyed at Roo - more precisely, Spring, because they seem to give Roo more love/attention than Grails.

Personally, yes, I think perhaps it was a bit 'dumb' of you to dismiss Groovy. ;) Yes, it's 'syntactical sugar', but having that in Java is great. You can say 'hack' or whatever, but it's still effective and bringing productivity and reduced boilerplate to otherwise plain-old Java.

Scala and Clojure - I've nothing against them, except that they do seem to split the attention on 'alternative JVM' languages. That dilution hurts the chances of any one platform taking hold as the 'next thing' in the Java world, and personally, right now, most of my eggs are in the GR8 world, for many reasons.

I do think Scala is different enough from traditional Java development that broad migration from existing Java developers won't happen, whereas Groovy is so potentially similar that there's little reason for an existing Java dev to have trouble adding Groovy as they learn it. It's not an 'all or nothing' proposition.

If you have any further interest in Groovy/Grails and have any questions, I'd be happy to help if I can - email me directly if you want.

[eneveu]

That's interesting. I definitely need to check Groovy out. Plus, the lead developer is a fellow French, so there is one more reason to try it ;)

I agree with your views regarding Scala. It's a really interesting language with a ton of cool concepts, but I fear it might be "too powerful" for the "standard entreprise Java programmers". Java is good, because it is simple. With Scala, you use different paradigms, which might be harder to grasp. It's easier to shoot yourself in the foot / write complicated code. But I guess that's the price to pay for using a high level programming language?

Here is Martin Odersky's take on this debate: http://lamp.epfl.ch/~odersky/blogs/isscalacomplex.html

Gosu also looks interesting as a Groovy contender, though you won't like it, since it dilutes the alternative JVM languages even more ;) http://gosu-lang.org/ http://news.ycombinator.com/item?id=1881924

[mattmanser]

Personally I would say do not make your first big project in a new language your startup, it'll take a lot longer. It's hard enough just getting the thing out the door without having to also deal with the pain of learning new paradigms, new dev tools, constantly having to look stuff up and wondering if you're doing something fundamentally wrong.

Force yourself to start writing other things with the language you want to use TODAY. I would start writing utility stuff in something else until you're comfortable with it.

It's also a little funny to see Python and Ruby described as more powerful that Java! I guess powerful is a mutable word, but personally I'd consider them less powerful but faster to develop in (for a dev at the same skill level in both languages).

[eneveu]

It's hard enough just getting the thing out the door without having to also deal with the pain of learning new paradigms, new dev tools, constantly having to look stuff up and wondering if you're doing something fundamentally wrong.

Yes, but it's also more fun :) I think fun and passion are important for a startup. But I agree that one needs to strike the right balance, and pragmatism is good when you want to ship.

Force yourself to start writing other things with the language you want to use TODAY. I would start writing utility stuff in something else until you're comfortable with it.

I think that's indeed the best course of action. I've read about people who started using Groovy for unit testing at first. Another good example is my colleague who built a small customized issue tracker in Grails for the Java project they were working on.

"It's also a little funny to see Python and Ruby described as more powerful that Java! I guess powerful is a mutable word, but personally I'd consider them less powerful but faster to develop in (for a dev at the same skill level in both languages)." By "powerful", I didn't mean "performant". Due to the JVM, Java is faster than Python / Ruby. I used the word "powerful" in the same sense as Paul Graham did in his essay on Lisp ( http://www.paulgraham.com/avg.html ), that is, a higher level, more expressive language. With today's hardware, using a high-level, slower language is not a problem anymore: we now optimize for human time (development time) instead of machine time.