The question that Matthew Kaufman proposed was specifically asking about app architecture deployments, so what Facebook is choosing to do is entirely germane.
I'd lean more on the "ipv6 evangelism" side of the discussion, but:
Facebook controls the whole stack and can require buy-in from their apps people to push IPv6 first. If that costs them dev time to patch some OSS to handle it gracefully, that's their business decision. In the "cloud host" domain, you're dealing with a much more heterogeneous environment where the provider doesn't control the whole stack up to the apps. Making the platform as frictionless as possible for customers is key; customer X is not going like your platform much if widget Y doesn't run properly "because IPv6". Sure, widget Y should get its excrement together and handle it, but all customer X sees is "widget Y fails on provider A, but runs fine on provider B" where provider A was v6-only internal but provider B is either v4-only or dual stack. Guess where customer X spends their dollars now?
I'm on your side, here: I run my own stuff v6-first wherever possible and have filed bug reports, submitted workarounds/patches, etc. We need people doing that to push things forward.
On this given point, though: Facebook -ne generic hosting platform -- Hugo
signature.asc
Description: Digital signature
