What's the point of rhetoric that convinces folks who want to improve developer ergonomics that their goals are in conflict with performance? What do you think will happen over the long haul if performance-minded folks act like the tradeoff is zero-sum?
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
-
-
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.
-
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/ …
-
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
-
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.
-
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.
-
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 …
End of conversation
New conversation -
-
-
Reducing pointless configuration quite offers offers opportunities for optimizations that are harder in more configuration-heavy environments. Linux can optimize socket buffer sharing by sharply nudging people towards higher level APIs.
-
Rust iterators work better than hand-rolled loops because the higher-level abstraction can amortize or eliminate the bounds check. Modern web frameworks are faster than Backbone at scale because they can guarantee render() is only called once.
-
Glimmer was able to take Ember's declarative templating layer and drastically improve performance with few semantic changes. Ergonomics often *enables* performance optimization by making developer intent clearer and more declarative. They aren't in conflict.
-
Glimmer alone wasn't a fix, to my recollection. We had to wait for Glimmer 2.https://meta.discourse.org/t/upgrading-ember-to-2-10/52724 …
-
I was using Glimmer as a shorthand to mean "various improvements we've made that leveraged the declarative nature of the syntax" My argument is that ergonomic APIs often have latent fast paths you can identify and optimize (and downplay or deprecate the slow paths)
-
JavaScript got fast in part by turning with() into an aggressive deopt and turning direct eval() into a super-slow operation. The rest of the language was much more optimizable and the results shocked the pundits of the time.
-
JavaScript is in billions of devices, with 4-5 major corporations pouring zillions of dollars into it. I agree there's a ton of low hanging perf fruit here, but who is there to harvest it? And factoring for anti-perf culture..
-
it's like you're trying to solve world hunger on Twitter though.
End of conversation
New conversation -
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.
