It's a foot gun (incoming strong opinion)

The single most difficult thing in software development is the fact that the system doesn't exist, it is defined by mystical incantations, and we work on that invisible system by changing the instructions to build it.

Anything that makes the understanding or "building" that system mentally is no-go.

Flashback to one of my favorite debugging stories where an entire java code-base was meta-programmed into existance at runtime and would constantly throw errors to lines of files that didn't exist.

And yet without it we wouldn’t have Rails.

Broad proscriptions such as this almost always set my teeth in edge. Sure, meta programming can be a foot gun. But it can also be a way to cleanly achieve specific goals. Metaprogramming should by no means be the first tool reached for, but throwing out the baby with the bath water is an overcorrection.

It also means you are losing out on a significant portion of what makes Ruby Ruby.

> And yet without it we wouldn’t have Rails

Oh no anyway.

Yes, throw shade at the stack used to build over 75% of the value captured by the top 50 YC funded companies.

Pretending Rails sucks never gets old, I guess.

If you're going to give rails the credit for the successes, you should probably give it the blame for the failures, too.

I've worked for large companies and startups, and seen rails several times, along with .net, java, scala, php, node and other backbends.

The only thing that mattered in any of their technical successes was the quality of the engineers working on them.

There were certainly minor differences- irritations like compile times or dynamic typing- but the trade offs were 90% of the time personal preference, when compared to the difference made by the strengths of the actual people writing code.

I don't agree with your logic.

That >75% value created by companies which used Ruby did not create an equivalent debt in another column.

If Ruby-first companies that aren't AirBnb (for example) fail, it's not because AirBnb succeeded. (Perhaps unless your company was called Couch Surfing.)

To protest on the grounds that for some teams, Ruby might be the wrong choice is to willfully ignore the key detail about the whole outlier-degree success thing.

> Flashback to one of my favorite debugging stories where an entire java code-base was meta-programmed into existance at runtime and would constantly throw errors to lines of files that didn't exist.

Lombok?

If an error is thrown from Lombok code, you’re misusing Lombok. It gets way more hate than it actually deserves. Spring does 100000000x more in terms of making code based confusing to navigate and confusing errors yet receives very little criticism from the Java community. If we want to talk about misuing metaprogramming and code generation, Spring is the biggest offender IMO.

> If an error is thrown from Lombok code, you’re misusing Lombok.

I mean, that's fair, but if you're using it in a team based environment, eventually someone's going to misuse it and you'll have to figure out what happened. I think how bad things go when you misuse it is a valid consideration, even if it shouldn't dominate everything else.

> It gets way more hate than it actually deserves. Spring does 100000000x more in terms of making code based confusing to navigate and confusing errors yet receives very little criticism from the Java community.

I mean, I don't think you're wrong, but I'm also not in the java community. The few times I've forayed into there, it seemed more like a dynamically-typed (or more accurately, stringly-typed using only the names of config) annotation language rather than java. And if I wanted string-based typing and confusing semantics, I'd just write my whole project in bash.

My team uses both Spring and Lombok.

Spring may be the larger monstrosity, but they are both horrible ideas.

Lombok does kind of hacky things with Java byte code and classloaders. Definition of "undefined behavior" of JDK.

The ideas, however, are solid. They are just implemented better in other frameworks such as https://immutables.github.io/, using officially supposed JVM tools like annotation processors.