Agreed. It's one thing if the Cool Tech actually gives you a competitive advantage by solving the problem better, easier, with lower costs, faster, more personalized, etc.

Outside of that...it's all about the business. That's why so many successful businesses are built with Ruby and not "benchmark winner of the week" because Ruby tends to deliver on almost all of the business cases around solving problems and growth.

If you're a larger business and planning to deploy at scale to an existing customer base, the business problems tend to change more towards performance and Right Tool for the Job.

I remember when ruby was the hot tech a few years ago, frowned upon by conservative developers. I learnt ruby back then. I'm glad ruby is now recognized as a more mature ecosystem that does things well, even though it is one of the boring technologies now.

Is Ruby/Rails faster now? I built a few simple sites on Rails 2.3 via Passenger, and my God, it was such a performance hog compared to every other web stack I'd ever used. Probably mostly a function of how heavyweight RoR was, but I never got deep enough to figure out what was so slow about it. It may also have been user error, but it seemed like others were bragging about getting it to levels of performance that would be frankly embarrassing on most stacks.

One thing Rails has over, say, Laravel or Django is the JRuby option which has made significant strides in performance in the last 6 months. There's also Truffle Ruby, Graal and Oracle's Substrate VM which all target Ruby performance so my money is on a significant Ruby resurgence later this year by which time Oracle will likely have open-sourced Substrate VM.

It is. Come a long way since Rails 2.

There are still much faster options out there but it's nowhere near the beast that it used to be.

Great to hear, I might revisit it in a future project then - the experience was generally really nice, but the performance was really painful.

Don't get me wrong, I'm a huge Elixir advocate largely because you get the performance and scaling perks of other languages with very close to the development perks of Ruby.

I just get tired of hearing the "but Ruby is slow" drum beats when it's so consistently successful. Scaling web servers is easy. Scaling the database is hard.

Yeah, I was just asking if it had improved. Scaling web servers might be easy, but it adds administrative overhead, and if you don't have big piles of VC money to burn, it bites into budgets that would be better used hiring more people and working on product. And it makes it so you have to waste your time reworking your server structure earlier than you would have to otherwise - suddenly you need a load balancer, a shared session store, etc. When I ran a company, these were very real concerns.

It being successful doesn't excuse its slowness, in my opinion. There are lots of bad products out there that are successful by many metrics. Speed is an important part of making something good, and RoR added significant hurdles to making very fast sites. There are other stacks that don't have that issue that are also successful, but have other downsides.

Anyway, not worth rehashing these old arguments, I just wanted to know if it had improved. Sounds like it has.

There was a time when Ruby was "the cool exotic and unproductive technology". A lot of wheels had to be reinvented (and new ones added) before it became what it is today, there is nothing special about it.

All mature technology will come with a known set of tools and processes to tackle almost any problem very quickly, as long as you're familiar enough with the stack.

> there is nothing special about it.

One thing that's especially productive about it that helped to grow the 3rd party ecosystem is that the options you have for dependency injection in Ruby due to monkey patching give you an experience much closer to Aspect Oriented Programming.

It also makes it easier when you need to add functionality somewhere high up the inheritance chain without having to rebuild the entire chain around your new object base, or fork the library, use your fork as the dependency and make the change directly.

In the world of object oriented web development, Ruby was close to a miracle in time-reduction in WORKING with an ecosystem.

At that same flexibility in monkey patching makes the codebase rubbish in a year when it's time to upgrade dependencies.

It really depends on the interaction between the discipline of your team and the failure modes of the tool. A culture of code review which puts a high bar of justification and documentation-for-new-contributors on monkey patching can counteract this failure mode.

Do you code review what each new library does? It doesn't have to be code you wrote to cause problems. And most people treat a library as a black box with inputs and outputs. Which works well in a sane language, but often not ruby.

I would like to add that Excel macros are excellent; If Google Docs spreadsheet functionality were exportable I reckon that many existing startups could be built as a mere UI change on top of that backend.

What do you mean by exportable?

> Your cool tech startup is not about the tech.

In some cases it is about the tech.

Instead the suggestion should be to apply the concepts of a minimum viable product relevant to your business problem.