I think a lot of the problems with Ruby are really problems with the nature of Rails jobs over the past 5 years. Lots of juniors (which is great) in a field where people change jobs every year or two (which is okay, but horrible from a codebase standpoint). Giant monorails applications grow strata of different generations of code/teams/opinions; and each new generation of engineer on the project adds their own stamp on top. It leads to situations where you have enormous applications that are so deeply entagled within themselves that it becomes nearly impossible to refactor out poor performing bits of the app.

It reminds me of the Kowloon Walled City[1] -- originally a (likely cleanly built) fort that took on more and more people until it became a morass of people and buildings with no consistency or strong structural concerns.

Then Rails (and Ruby) get this reputation for being a Kowloon rather than the Fort.

Not that ruby is not slow compared to other languages, but it's not as slow as perceived.

[1](https://en.wikipedia.org/wiki/Kowloon_Walled_City)

I've found Ruby to be faster than Python these days; it's node.js that beats it, for obvious reasons. I don't think JS has fewer problems around mutability and and monkey patching though.

Are you talking about CPython or PyPy? MRI, Rubinius, JRuby?

Perf characteristics differ wildly between those.

On Walled City

It wasn't really cleanly built. And there are lots of stories in there. And the Japanese seems to love it.

I always wonder if someday we could rebuilt the whole thing as Hotel, resort and tourist attraction.

As usual, it's all about tradeoffs. I use other languages too (Elixir, a bit of Rust, Go, Javascript etc). When the tradeoffs match your needs, Ruby is excellent.

But then addressing your points:

- Raw performance is improving (see my other post)

- Monkey patching is less and less frequent (I'm maintaining pure Ruby, but also Rails app since 2005), is generally considered a bad practice

- Rails-centrism is gradually becoming a thing of the past (see gems like Hanami, Roda, Sequel, Kiba, dry-rb etc)

- Runtime metaprogramming brings a lot of benefits when properly used!

- Threadsafety (I'm the first to mention that) has gradually gotten much better

So well - we're getting somewhere!

As I often note when this comes up, I've never actually written a Rails app. I've been writing Ruby for about five years now.

A huge chunk of the devops world is written in Ruby (probably about the same in Go, much less in Python). It's still the "Perl of the future" and you'll find it all over the place. Rails is still big, especially in America--but there's a lot of other very influential stuff to it. If you're doing web there are other (I would say better, unless you're making Basecamp) libraries that do very well, too. Hanami is cool, Grape is good, and I'm in the process of building a Rack framework called `Modern` that's intended to be a turn-key, OpenAPI3-compatible framework to make the creation of API clients on the other hand a trivial experience.

"Refinements" are the "cleaner" version of monkey-patching.

These are (AFAIK) a big part of the magic in Ruby testing frameworks.

Apologies if I'm wrong here, but I don't believe any of the major ruby test frameworks use refinements at all. Since they are lexically scoped they end up being too verbose to be useful for this purpose. In other words, you would need to have a series of `using MyRefiningModule` statements in every single test file.

Perhaps you were thinking of rspec's changes in the last few years. They have been moving away from monkeypatching with some changes to their syntax. Previously they defined `Object#should` and handled assertions using syntax like `my_var.should eq(1)`. The new approach, which does not use refinements, is to handle assertions using a wrapper method that works like `expect(my_var).to eq(1)`. No refinements necessary for that though.

The Rails-centrism is only a western phenomenon, in Japan the focus for using Ruby is a very different one. http://engineering.appfolio.com/appfolio-engineering/2017/5/...

Ruby developer in the west here. Stopped using Rails in my professional and personal work pretty much immediately on starting my career (not saying that I wouldn't use it). My last web projects were all Jekyll.

99.9% my work involved (past tense, I'm a Systems Engineer now) ETL processes and Ruby is a serious workhorse there. I've done extremely complex jobs in plain Ruby, the Kiba DSL or just using Ruby to augment/encapsulate shell commands (ruby script in crontab->curl wrapper[typhoeus] to fetch data & write to file->%x(some grep/sed/awk stuff)->do more work with output in ruby).

I've never found better tools for doing this kind of work. I've seen some _nightmarish_ Node or Python projects to do similar. It's very, very rare that Ruby and its performance are my bottleneck doing this kind of work. Usually it's platform (ahem...Salesforce) or database limitations. GNU Parallel fills in the gaps usually.

Ruby is the only language I've found where I can consistently hand off my work to others. They comment on the code being clean and they keep it clean with their changes.

Just to add a funny story:

The place I just got hired by is pretty much all Python. They half-joke about hating Ruby. I did all of my challenges/problem walkthroughs in Ruby because I felt like it best communicated the problem and problem solution in code.

The number of times I heard "that solution is so clean" or "this solution would be way more involved in Python" from my interviewers would take more fingers to count than I have hands.

An example of a problem where Ruby significantly outshines Python would be welcome.

> - Little to no real innovation in the last years

You are sooooooooooo wrong it isn't even funny. I'm stuck coding to Ruby 2.2 and Ruby 2.5 is looking more and more like a totally different world.

> - Mutability

Never understood this complaint from people. I just recently started playing with a language that supports immutability (Kotlin) and it is weird to me that you guys seem to be asking for constants, rebranded. Even weirder is if I write my vars' names in CONSTANT_CASE I get yelled at by the code formatter!

Plus, in immutable languages, are there cases where immutability extends to nonscalar values like arrays or hashes or objects? That distinction just feels so...arbitrary.

Is data changing that big of a problem?

> Is data changing that big of a problem?

Yes, but it is hard to recognize it as such until you've experienced the alternative.

I don't know much about Kotlin, but the fact that it relies heavily on Java libraries is sufficient to tell me that it is a particularly poor example of the power of immutability. You see the usefulness of immutability when you have objects that are deeply immutable - when you pass them around, you know those functions haven't changed them. It is much easier to reason about deeply immutable objects than mutable ones.

> in immutable languages, are there cases where immutability extends to nonscalar values like arrays or hashes or objects

Yes, this is largely the point. Although, you will rarely see an immutable array or hashtable - more likely it will be a linked list or balanced binary search tree.

Kotlin runs on JVM but it's closer.to Scala, not Java. You can sure have immutable structures all the way down in it, as if it were Haskell. It doesn't enforce this style, though.

You're probably right, Kotlin's version of immutability is perhaps not the best example -- pretty sure the whole var/val thing is language sugar which explains why it doesn't work for nonscalars.

Makes sense, I can see the appeal now. Thanks

> Plus, in immutable languages, are there cases where immutability extends to nonscalar values like arrays or hashes or objects?

Yes, see (among others) Erlang or, if you like static typing with your immutable values, Haskell, both of which are pervasively immutable.

This is why the `deep_dup` and `ice_nine` gems live in most of my projects.

The last 3 years of development to the language have been...momentous, to say the least.

Even if you just look at what's been done in garbage collection alone, it's leaps and bounds.

The "why immutable" question usually attracts zealots that throw around terms like "easy to reason about" and detractors that mention "slows code down and is harder to write"--as if those statements were inherently true, universally understood, and defined in an agreed-upon way. None of those are the case.

The usual argument in favor of immutability is not that mutability is a big problem in general, but that when unexpected mutation occurs, it's a really hard to find (debug) type of problem.

If you have a well behaved codebase that does "a = { :foo => 'bar' }; render_hash_to_browser(a); store_hash_to_database(a);", you're fine: you can assume the same data ends up in the browser and in the database.

However, if that assumption ever fails ("users are seeing data that isn't in the database!") it's often a debugging nightmare, because you have to dig down into any code that might possibly ever touch the hash to see if it's accidentally mutating it. This includes utility functions, totally unrelated areas, et cetera.

If you have a good debugger to assist you, and an easy way to attach your code to a harness that follows bug-reproducing paths, you're set. But those things are a) never as present as we want them to be ("just don't write bugs, duh!") and b) tend to be harder to get working in old, large, monolithic projects--just the kind of projects where sneaky mutation can become a frequent issue.

Now, all debugging is hard. And a lot of it involves delving into code you've never seen/touched before to find a bug. But sneaky-mutability issues typically expose a much wider variety and volume of code as suspect. Because of that, mutability issues often tend to be, if not objectively more difficult, at least objectively more frustrating to debug.

With this as in all things, there's a spectrum. Some folks are fine with ultra-dynamic languages that let you mutate/bind anything, and protect against that with convention and tooling. Hell, some folks are fine with languages that mutate their data structures when you do nothing but read from them (https://perlmaven.com/autovivification). For others, they just want control over what you can bind to names (a type system, or "const"--the Java/etc kind--which prevents rebinding). Still more folks want the ability to opt into truly immutable deep data structures. And others want everything in their platform to be immutable when they use it, and have all the mutability (which you nearly always need, if only for performance alone) handled behind the abstractions of their runtime.

However, past a certain criticality or size (of code/complexity/age/number of developers threshold) of a project, it often becomes necessary to move "up" that ladder to something that provides more programmatic/automatic assurances about "what is happening to my data as it passes through all this code?"

* Raw performance

Last time I checked I think that Ruby is faster than Python, and people generally seem to be okay with Pythons speed so I don't really think Rubys speed is as huge an issue as people make it out to be. Also, if this project that the OP mentions eventually realizes it's potential Ruby could become substantially faster than it is today. It will never approach JavaScript or Lua speeds, but faster is always better.

* Runtime metaprogramming from hell, * Monkey patching

Isn't this really the users fault though, just because the language allows bad stuff to happen doesn't mean we should ever do bad stuff.

* Little presence outside web development

Do yo consider NetSec to be web development? Because I've noticed Ruby is fairly active in NetSec but it doesn't get talked about a lot. I've also heard that Ruby is used extensively in embeded devices in Japan but due to the language issue it isn't known or discussed anywhere else. I'm sure there are other weird little corners as well that Ruby is active in but that just aren't really know.

> Last time I checked I think that Ruby is faster than Python

Really? When did you look? PyPy has gotten pretty stinking fast.

The stack traces suck sometimes with the metaprogramming. I have never chased down exactly what causes it, but sometimes you'll have lots of library code calls mentioned, and nothing from the application.

I agree with every point here except for clean syntax. You can make Ruby's syntax almost as nasty as you want to. I think syntax flexibility is simultaneously one of Ruby's best and worst features.

All those positives sound like python.

That is something to be proud of. I've always considered Python one of the most mature and powerful languages out there. If Ruby has reached that level, I'm honestly very happy.