I understand your points and mostly agree with them, but there are valid situational counter-arguments for them too:
1) Except when you don't have the money. Not everyone trying to build a business goes the funded startup route...
2) Except when it does. There are (a small percentage of) businesses where speed does matter and caching everything is not an option. Think exchanges, ticket sales, real-time analytics off the top of my head.
3) Yes, you want to quickly iterate. Sometimes this means using readily implemented libraries for the non-core parts of your businesses. Sometimes it means avoiding readily implemented libraries that do not fit your requirements and/or overcomplicate what you are trying to do. Sometimes it means avoiding the cognitive overhead of all that cruft a framework has and you don't need. Sometimes it means using a typed language and letting a compiler do the most basic testing for you...
4) To me, this is a classical exploration/exploitation tradeoff. You will be less productive using anything new. New language, new framework, new ideas drag your productivity right now. But they may increase it in the long term, even if you end up going back to whatever you were using before. Find some budget to explore and make the most out of what you learned, but don't overspend on it.
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.
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?
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.
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.
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.
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.
To answer your criticism to the original criticism:
1) Rails is not really THAT expensive, especially when you're just trying to build a small business website. The people who complain are actually the ones who are exactly working on those "funded startup" you mentioned.
2) There are tons of huge apps out there that run on rails just fine. You hear about stuff like Twitter switching to other language because rails is "too slow", but Twitter is like the rarest exceptional case you'll ever find. I mean, do you know of any other web app where realtime is as important as Twitter AND is at such a huge scale? Most websites don't.
3) It's actually more like "Most of the times you use readily implemented libraries and in rare cases you need to use your own". You can't iterate fast when you have the mindset of trying to fix everything. You need to pick the most important problem you're trying to solve and do whatever it takes to reach product market fit as quickly as possible. I have played around with node, express, etc. to build webapps and was at first very intrigued. I did that for a while, and then got frustrated with the lack of convention i can just mindlessly follow as well as all the convenient tools rails provide. So I came back and couldn't be happier.
> There are (a small percentage of) businesses where speed does matter and caching everything is not an option. Think exchanges, ticket sales, real-time analytics off the top of my head.
True. But even in those cases, there are likely parts of the system where speed of execution is less important than speed of iteration. So you could (if it made sense for you) use a Ruby app for the user-facing app, backed by a service written in something else.
Point being, just because you need a critical processing bit to be written in screaming-fast C doesn't mean you need to write your own HTTP router in C.
1) Except when you don't have the money. Not everyone trying to build a business goes the funded startup route...
2) Except when it does. There are (a small percentage of) businesses where speed does matter and caching everything is not an option. Think exchanges, ticket sales, real-time analytics off the top of my head.
3) Yes, you want to quickly iterate. Sometimes this means using readily implemented libraries for the non-core parts of your businesses. Sometimes it means avoiding readily implemented libraries that do not fit your requirements and/or overcomplicate what you are trying to do. Sometimes it means avoiding the cognitive overhead of all that cruft a framework has and you don't need. Sometimes it means using a typed language and letting a compiler do the most basic testing for you...
4) To me, this is a classical exploration/exploitation tradeoff. You will be less productive using anything new. New language, new framework, new ideas drag your productivity right now. But they may increase it in the long term, even if you end up going back to whatever you were using before. Find some budget to explore and make the most out of what you learned, but don't overspend on it.