Ask HN: Ruby or Python for 2018?

I'm personally not someone that likes to look at new languages and compare them for the sake of it. There are folks that like to compare compilers or interpreters and the internals of how those work and debate them.

I'm more interested if something new can help me in delivery of working software. Having moved from a Java world to Ruby/Rails, I find it not just helps me deliver, it pretty much gets out of my way (most of the time) compared to Java.

I haven't done much more than read about Python/Django/Flask. If they are mostly similar to Ruby/Rails it doesn't sound like there would be benefit to learning them outside of curiosity (and an affinity to Monty Python).

I suspect that big name bloggers and people that talk a lot about things may find a need to keep viewers coming to their blogs/channels. If there isn't a lot of new stuff to write about but it is still a solid delivery platform, that isn't too exciting to draw viewers.

https://www.reddit.com/r/ruby/comments/7jiq6k/what_worries_y...

I will post my answer here, but it basically sums up a lot of things that were said in the replies here as well. If you want to be happy, just use what you are happy with, if you want a career out of it, choose sensibly.

We need to define a few things up front.

When people say Ruby is dying or dead, what dying or dead actually means is Ruby is not growing. Lot of people left Ruby, even the prominent ones, but there are also lots of new faces, as DHH likes to mention.

Languages dont die, especially when they are open sourced. Perl is still not dead, nor PHP. But consider if a languages is slowly moving towards irrelevant, then it is certainly considered dead. In this case Perl is an example, while PHP still has vast majority of the Web programming. In any case, the Job Pool is an easy indication, and no matter how you spin it, the Job Pool for Ruby Rails is definitely shrinking.

The problem is Ruby at its 1-2% low level of usage, should really be growing a lot. You dont see large web scale company using it, Python has Google, Dropbox, for example, using it as well as contributing to its development. Ruby doesn't have any of that, and it isn;t trying to get being used for large corporate either. Its whole ecosystem is bond to Rails. Even the Release note of Ruby often mention Rails and nothing else. It seems at the moment Ruby is an Rails languages rather then vice versa.

When people say Ruby Rails dont scale, what they really meant was Ruby Rails dont scale cheaply compared to all others. Cookpad does close to 20,000 RPS, Shopify manage 80,000 RPS, and there were once information about China's Railway ticketing system using Rails that does 400,000+ RPS, it was basically the whole China DDOSing the system. So Ruby Rails scales, but at what cost?

The Web is largely divided into two camp, one is the pay by user and SaaS model, much like Basecamp which Rails originate from, the other is Ads to user which needs to reach a critical mass before it starts to paid itself. The latter is the one much more popular and which Ruby Rails is having problem, because scaling to that critical mass requires substantial investment into infrastructure, and its cost structure is not very attractive. DHH used to say Moores law is helping them to grow, but that has no longer be true for recent few years, not to mention the Goal post of sustainable advert or per user revenue on a freemium model is getting larger then the speed of Hardware improvement. For example, on Stackoverflow Engineering blog, shows a fully optimize ASP.NET could do 10x more then Ruby at 10x Faster Speed while using 1/10 of Servers.

There was a talk sometime ago about Go Vs Ruby, where Ruby was likely 30%+ more productive up front, it was 10x slower, 300% more maintenance work afterwards.

To put this simply, the maths and scale of economy doesn't work very well for Ruby And Rails on many applications.

If you watched some Conf Video, Matz has went from Ruby is fast enough, good enough, to Ruby needs to be faster, Ruby needs concurrency. From Ruby is my languages, to Ruby is communities languages. The closed development circle of Ruby means it has seen much less contribution from outsider compared to Python. When Ruby needs all the help it gets, not having the conversation and development in open and easy to follow doesn't really help. Although I understand the resistance to GitHub, but certainly GitLab is an alternative.

I also dont believe backward compatibility is the most important factor for 3.0. Ruby has quirks and in some cases far too many choices, and if MJIT is really faster, it should be used as an incentive to move the ecosystem forward. Making breaking changes at the MJIT support level. Taking the chance at changes to fix and improve things. While Matz have said they dont want another Perl 5 / 6 and Python 2 / 3 problem, but i believe this is different. Perl 5 / 6 is literally a completely different languages they might as well call Perl 6 something else. While Python 3 offer changes while giving no immediate benefits to its users. JIT is a very good chance to use as bait and rethink what Ruby in the future should be.

The biggest problem often is Ruby as a communities dont see any of these as problem until it is too late. People flock to Go not only because of its performance, but because it can be easily deployed, and deployment isn't something even on Ruby's Roadmap. Ruby on Windows still isn't as easy as any other counterparts. And it is too late to join the Data Science race. Sidekiq developers gained their success using Ruby has has now moved to Go, the same as Hashicorp.

I know this may be a little harsh, of course Ruby dont owe us anything, you are free to use and move on as you like, but it is sad that Ruby doesn't grow bigger, it doesn't need to take over the world, but it should have a slightly larger presence and usage across different domain. Luckily Ruby will always live on in the form of Elixir and Crystal.

with so many supported libraries available i keep finding that adding more functions to Python code does not actually add much to the amount of code.