cvshepherd

I don't see what I've supposedly missed. And my remark about the cat was just an example of things not necessarily being what they look like.

See my comment on the other summary.

"The treated larvae grew to become large headed and jawed ants resembling supersoldiers."

If you gave a normal cat growth hormones, it might resemble a tiger. That doesn't mean it is one. That was the basis of my summary. I don't want to ridicule the research, and agree that this could have beneficial applications.

Summary: Treating ant larvae with growth hormones, produces big ants.

> Caching is suggested far too often and too frequently in the Rails world. The solution to "the default tools for template abstraction are too slow to use" is not "use a difficult-to-get-correct system with concerns that cut across the entire project."

I'm not selling caching as a silver bullet (and I'm not saying it's trivial to implement, either). It's just something a lot of people either don't use at all, or just get wrong. And surely, if something can be cached, it should be.

> As someone else mentioned, Rails is much slower than other frameworks. It does an order of magnitude less than 5000 req/s

With Metal endpoints, proper configuration and lot's of resources, this is very possible.

When you use Metal endpoints, as i mentioned in my comment, 6000 requests per second is actually very possible. Yes, you need a lot of resources, but I didn't suggest otherwise. And yes, on this hardware other frameworks will manage even more requests.

EDIT: My low budget netbook just gave me 327 req/s with an out of the box Rails config, and running the benchmarking tool on the same machine.

> For just one particular example, I have found rendering partials in Rails are such a point of poor performance that I have often found myself avoiding it.

A good caching plan obviously helps with these kinds of issues.

> There's this red herring (and a pet peeve) that making the framework 'less bloated' by dropping components or making them optional equals performance.

In the case of Controllers, inheriting from ActionController::Metal and not including unnecessary modules, speeds things up a lot.

In general Rails may be slow in comparison to other frameworks. But that doesn't mean it's too slow. I don't really care if my app only manages 5000 requests per second, versus framework x's 6000 or more on the same hardware.

> The simple solution is to either add a nonlocal keyword like Python has or to introduce a := parameter that works like = but explicitly overrides a higher level variable.

I disagree. The simple solution to this is to write tests.

"From my experience, generating a good UI (V) takes orders of magnitude more than implementing M and C."

yeah, because picking the right font has always been way more of a task than domain modeling.. (yes, i know that ui / ux isn't a breeze, but this depiction is just insane.)