I use Ruby everyday and while I definitely don't hate it, there are many things I dislike. For example, functions are not first class citizens (despite the "functional" slant to the standard library). You have to jump through hoops to do any real functional programming (and it's ugly).

The syntax has waaaay too many options. This leads to a language where 3rd party tools are really hard to write. Even at this late date, refactoring tools are mostly absent (or awful). Not only that, but it leads to serious religious wars about how to format your code (I'm sick to death of it, even though I try to stay out of it).

Modules are slightly strange. You can't really use them for namespacing without writing pretty non-standard code. They are really only useful for mixins -- which normally isn't a great plan.

And as popular as meta programming is, it's incredibly awkward. The underlying design seems completely arbitrary and is hard to reason about. Despite the many syntactic options for frivolous things, there are very few syntactic tools for meta programming -- just super long function names.

People are going to laugh, but I actually prefer Javascript to Ruby because the design is much more logical and flexible (despite the poor syntax and really terrible standard library). There are lots more things that bug me about Ruby, but I think those are the main ones. I still enjoy writing code in it, but it wouldn't be my first choice these days.

Poor performance, and Ruby likes magic. Magic methods and macros scare off a huge audience of programmers in the mainstream world. Rubyists tend to wholeheartedly embrace them, however.

Magic is exactly why I stayed away from Ruby. You have to learn some for every environment but Ruby was too much for me. Perhaps because I first saw it with RoR - which adds even more magic.

Both above and above one's parent comment is about rails, not about ruby. It's understandable that most people got familiarized with ruby because of the popularity of rails, but confusing between the two?

I've written Ruby, not Rails. In fact, most of my Ruby work hasn't had anything to do with the technologies associated with the web, they've been desktop GUI applications and server applications (like dealing with ActiveDirectory). I'm not confusing anything, I'm speaking from experience.

The Ruby community likes things that think for you, and insert methods unexpectedly, change the meaning of semantics, and all sorts of other magic designed to think for the programmer.

Ruby doesn't have macros and all the magic in its ecosystem is confined to Rails and the gems related to it. But most Rubyists are such because of Rails so that's understandable. Examples of the magic like features of Rails are ActiveRecord's auto discovery of db schema and auto creation of queries, or callbacks on the changes of status of db records. It's where programming in Rails becomes somewhat declarative.

But macros? A language with macros I'm working with is Elixir. Even the seldom used if then else is a macro there. Do people dislike Elixir because macros change the code at compile time? I don't think so.

> Ruby doesn't have macros and all the magic in its ecosystem is confined to Rails

Then what would you call the method_missing method?

> a b c

> = Name Error

> def method_missing(*args); args.join(" "); end

> a b c

> = "a b c"

That looks exactly like a macro to me.

---

> But macros?

Not macros as such, we all like having them. But Ruby likes using them constantly, and that culture is hardly restricted to Rails.

I see your point but Matz was clear about adding macros to Ruby:

> Macro is a great power, but at the same time, it makes the languagesyntax different for each application. You will have hard time to read the program without knowledge of the application/framework macros.

> So I am not going to add macro to Ruby.

> matz.

https://www.ruby-forum.com/topic/215212

The funny thing is that this is what happens when we use method_missing or other Ruby features to create DLSes: unless you know the application/framework DLS you can't understand the program. They must be used wisely.

But to be fair: how can one understand a program without the knowledge of the non standard libraries it uses? This applies to every program and language, macros or not.

Macros and meta-programming aren't necessarily the same.

Contrast with Lua: equally possible to do monkey-patching, but it's considered unclean and confusing to do it in Lua, at least among the community. Generally, there is a thing we could call the 'magic budget' and it's important not to blow it too quickly.

I think this quote from Metalua's frontpage, an extended Lua for better metaprogramming, sums up that feeling perfectly:

> Don't bother developers with macros when they aren't writing one: the language's syntax and semantics should be best suited for those 95% of the time when we aren't writing macros.

An extended language to add more magic, says we don't need it most of the time.

And to be honest, it's one of the things about the Lua community I find really attractive.

Does that scare off a lot of programmers from Lisp as well? It's interesting, because Elixir, Julia and Crystal, all newish languages, include macros.

The combination of the lack of a type system and magical metaprogramming that relies on mutating classes at runtime leads to maintenance nightmares. Probably one of the more frustrating languages I've used.

I love both Ruby and Coffescript and I love magic. When you've embraced pure happiness and productivity everything else is depressing.