Every time someone uses rhetoric that makes the two seem at odds, we are set back years of community consensus building, as people entrench into tribes that accept the false dichotomy. I love the Rust ecosystem for making a rejection of the conflict a core value.
-
-
I'd much rather see Rails reject the conflict and embrace win-win solutions in the Doctrine than bludgeoning people who care about ergonomics to get them to agree that their concerns are subordinate to performance.
2 replies 0 retweets 1 like -
for that to even begin, there has to be top-level Doctrine acknowledgement that performance maybe.. kinda.. matters.. even a little? a smidge? a dash?
1 reply 0 retweets 0 likes -
Replying to @codinghorror @wycats and
otherwise it looks a lot like Doctrine level DevHappy bludgeoning. Your users will have so much time in between requests to think about how ecstatically happy they are! Oh wait.. you mean users should be happy too?
1 reply 0 retweets 0 likes -
Replying to @codinghorror @sgrif and
I don't read the Doctrine the way you do, even on its own terms. It's saying that we focus more on dev hapiness because it's harder. It doesn't say performance doesn't matter, and the amount of aggregate time spent on performance really doesn't match this claim.pic.twitter.com/odN6zzkV0H
2 replies 0 retweets 1 like -
dev happiness is pretty easy these days, in a way it was not in 2004. So many choices, so many mature frameworks. Performance, on the other hand, has hit a brick wall in terms of hardware advancing.
1 reply 0 retweets 1 like -
Replying to @codinghorror @wycats and
Beyond that, what if I told you I could reduce your cloud server hosting costs by 50 percent.. with *free performance*? https://blog.wikimedia.org/2014/12/29/how-we-made-editing-wikipedia-twice-as-fast/ …
2 replies 0 retweets 0 likes -
Replying to @codinghorror @sgrif and
This is what DHH usually says to that. I think we can do better than that, but DHH has never ever rejected free speed, and has welcomed work to make it happen in my experience.pic.twitter.com/Xcwh0ILJkw
1 reply 0 retweets 3 likes -
All that reflects the Basecamp View, which is that "as long as we can host it the way we want, we don't care about anyone else". It's an internal biz, closed source centric view. A big reason why there are so few large ruby / rails open source projects.
1 reply 0 retweets 1 like -
Replying to @codinghorror @sgrif and
The mitigating factor is that DHH embraces non-conflicting improvements made by other people who want to do work on Rails. "Work on what you use and share the rest" is the watchword. True conflicts are rare.
1 reply 0 retweets 3 likes
Worth re-reading, because I believe the sentiments in here are even truer now: http://david.heinemeierhansson.com/posts/36-work-on-what-you-use-and-share-the-rest …
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.