[andrewvc]

And herein lies the issue. As engineers we long to solve 'special' problems, and fool ourselves into thinking we need to do something novel and hard when something simple will do.

We fool ourselves into thinking we NEED a faster language, and Hindley-Milner type checking, and everything else under the sun.

It's actually really hard to discover, whether you're fooling yourself or not here.

We're building our startup on Ruby/Rails with a clojure component for the speed sensitive stuff (which is actually a CPU bound number crunching affair). So far we're been very happy with the tradeoff. We tried building stuff in node, but the ecosystem is just so damn immature.

One of the nicest things about the Ruby community, that I haven't seen in any other language, is the cultural emphasis on good documentation. Java libs have very complete docs, that take forever and a day to read when you just want to use one damn feature, node.js projects have very pragmatic, but very incomplete docs, (same with clojure), and really, that's the case with most languages. Ruby on the other hand, seems to have instilled in its community that docs count, and its wonderful.

Rails testing and tooling is just ahead of the pack, and in the specific case of node, dealing with the irritation of async (inscrutable stacktraces, even when 'long' stacktraces are enabled, inconsistent uses of promises across libs, etc.), is a huge drag on productivity. If I needed a small highly concurrent component I'd consider it, but for general business logic Rails just kills it.

[dasil003]

Re: Hindley-Milner, this one is really really tough and I am not convinced either way yet. The problem is that it's so easy to whip something up in Ruby and then write a slick rspec suite that ostensibly shows that it does what its supposed to. At the time you launch this there is no value in strict type safety because it's easily testable and self-evident that it works.

The value of type safety comes in tiny increments over time. Week after week, month after month, year after year. If your project survives 10 years I am quite confident that the effort of implementing in a strictly typed language would have paid for itself by the number of bugs prevented and the number of wiring tests that didn't have to be written/maintained. Of course if it's just a solo project and you keep the code under control it's possible this is not true, but with developer and code churn I'd say this is practically impossible. The more important question is will this code base even need to live for 10 years in the first place?

[SkyMarshal]

Completely agree. There's a continuum of, to simplify - dynamic typing -> static weak typing (C, C++, Java) -> static strong typing (Hindley-Milner, Haskell, etc).

Hard to go back to dynamic or static weak after grokking the power of static strong, as you describe. Algrebra Driven Development > Test Driven Development.

[andrewvc]

Totally agree! FWIW, I'm betting on Hindley-Milner in the long run. The thing is, is it as important as something like library availability, good docs, etc.? Often times the answer is no.

[grndn]

Hindley-Milner + library availability + good docs => F#

[purephase]

If I could upvote you twice, I would. The number of times I've had to argue with developers over how unique their situation is and why they've had to go and re-invent the wheel for situation X is disconcerting.

I think it's a pride issue and a difficult one to manage correctly if you want to keep active/engaged developers who believe they're tackling difficult/unique issues.

I personally think Rails is great but, frequently, it is not a sentiment that is shared amongst the people I regularly work with and they see it as too elementary (for some bizarre reason).

If Rails were a for-profit with marketing dollars I would suggest that there is a perception issue with the framework among developers, but I don't know how you handle that in the OSS world.

[speleding]

There can actually be business value in novelty for novelty's sake. For a startup there are two markets: those of customers and those of employees.

The market for new hires is critical to success too, and using the latest and greatest tools can really help there. This is also a reason for Google X, Facebook buying Oculus, etc.